Bug 1129463

Summary: Foreman creates duplicate hosts based on incorrect facter 'fqdn' resolution
Product: Red Hat Satellite Reporter: Stephen Benjamin <stbenjam>
Component: ProvisioningAssignee: Stephen Benjamin <stbenjam>
Status: CLOSED WONTFIX QA Contact: Katello QA List <katello-qa-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0.4CC: bkearney, jhutar, kbidarka, mmello, riehecky
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
URL: http://projects.theforeman.org/issues/7384
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-06 19:18:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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:
Always

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
  nameserver 1.2.3.4
  nameserver 1.2.3.4

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 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.

NOTE: 
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 -%>
127.0.0.1   <%= @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
EOF

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.