Bug 1129463 - Foreman creates duplicate hosts based on incorrect facter 'fqdn' resolution
Summary: Foreman creates duplicate hosts based on incorrect facter 'fqdn' resolution
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Provisioning
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: Unspecified
Assignee: Stephen Benjamin
QA Contact: Katello QA List
URL: http://projects.theforeman.org/issues...
: 1129306 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-12 20:00 UTC by Stephen Benjamin
Modified: 2017-01-06 19:18 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2017-01-06 19:18:43 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Foreman Issue Tracker 7384 None None None 2016-04-22 16:49:24 UTC

Description Stephen Benjamin 2014-08-12 20:00:07 UTC
Description of problem:
When facter 'fqdn' fact resorts to resolving the domain name from resolv.conf (hostname -f fails), and resolv.conf searches a different domain, a duplicate host will be created, and the host will be stuck in a build loop because the token becomes associated to the new host created by the fact importer.

Version-Release number of selected component (if applicable):
6.0.4 Snap 4

How reproducible:

Steps to Reproduce:
1. Create a new host in Satellite with a different domain than what the DHCP server returns for resolv.conf search/domain

2. Let the host build - when puppet reports for the first time, it will create a new host based on the report upload

3. foreman_built URL call fails

Actual results:

Given newhost123.unicorns.com, with resolv.conf containing:

  search rainbows.net

And hostname -f returning (no DNS, no /etc/hosts record)

  hostname: Unknown host

Foreman will create **newhost123.rainbows.net**, due to Facter's poor FQDN resolution techniques.

You will have newhost123.rainbows.net (dupe) and newhost123.unicorns.com (original).  Foreman_built call will fail.

Expected results:
Foreman report upload relies on certname first.  This seems to be a regression from upstream bug http://projects.theforeman.org/issues/1938

Additional info:

Possible fix ideas:

* Report uploading relies on certname first - why is believing facter FQDN?

* Default templates create a record in /etc/hosts (fixhosts snippet used for image providers)

Comment 1 RHEL Product and Program Management 2014-08-12 20:03:09 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 3 Kedar Bidarkar 2014-08-13 08:28:58 UTC
Workaround for now.

I had to use fix_hosts to over come this issue and slightly modify it as below.

1) The below step 2) is required for REALM/IPA  Integration as ipa-client-install checks for <hostname>.<domainname> and clearly states that FQDN is preferred.
2) Modified few instances of s/@host.shortname/@host/  in fix_hosts 
3) Added:
  <%= snippet 'fix_hosts' %> before                                      
  <%= snippet "subscription_manager_registration" %> in
 'Satellite Kickstart Default' template.

Below is the modified fix_hosts template which helped solve this issue for now.

kind: snippet
name: fix_hosts1
echo "<%= @host %>" > /etc/hostname
hostname <%= @host %>
cat > /etc/hosts << EOF
<%# simple snippet to generate /etc/hosts when provisioning image based systems -%>   <%= @host %> <%= @host.shortname %> localhost localhost.localdomain
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Comment 4 Kedar Bidarkar 2014-08-13 14:41:15 UTC
*** Bug 1129306 has been marked as a duplicate of this bug. ***

Comment 5 Kedar Bidarkar 2014-08-18 14:38:27 UTC
This could be a blocker, as the vm's provisioning would go in an infinite loop, due to the above metioned reason. When Sat6 is integrated with IPA Server.

Comment 6 Stephen Benjamin 2014-08-18 20:45:09 UTC
Do you only see the problem with IPA realm enabled?  Or even with no realm, but
Satellite in one domain, VM in another?

Comment 7 Kedar Bidarkar 2014-08-19 10:12:06 UTC
Let me check, as per what you have asked.

Comment 8 Kedar Bidarkar 2014-08-26 13:44:29 UTC
Updating what was said on comment5.

Seeing this for both with or without sat6 integrated with IPA Server.

Comment 9 Stephen Benjamin 2014-08-26 13:58:11 UTC
The underlying issue is fact exepcts that `hostname -f` will return a correct value.  That fails if you don't have working DNS (or an entry in /etc/hosts).

I would say it's not really a blocker issue for GA, since the problem only happens in those 2 scenarios, which I think are sane requirements.

Two solutions are:
1) Have working DNS
2) Use the fix_hosts snippet with the modifications above

If it really becomes an issue for users, maybe then we consider including fix_hosts by default in the template.

Comment 10 Stephen Benjamin 2014-08-26 13:59:17 UTC
s/fact exepcts/facter expects/

Comment 11 Stephen Benjamin 2014-09-09 09:34:22 UTC
Created redmine issue http://projects.theforeman.org/issues/7384 from this bug

Comment 12 Bryan Kearney 2016-08-10 19:02:33 UTC
Upstream bug component is Other

Comment 13 Bryan Kearney 2016-08-10 19:51:18 UTC
Upstream bug component is Provisioning

Comment 14 Stephen Benjamin 2016-11-18 15:15:53 UTC
I think it's probably already fixed, will confirm.

Comment 15 Bryan Kearney 2017-01-06 19:18:43 UTC
This is an older bug which has been reported upstream. We are not going to track this bug downstream. When the upstream issue is resolved, the next build will contain the fix. Thank you.

Note You need to log in before you can comment on or make changes to this bug.