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
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
Given newhost123.unicorns.com, with resolv.conf containing:
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.
Foreman report upload relies on certname first. This seems to be a regression from upstream bug http://projects.theforeman.org/issues/1938
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)
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.
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 email@example.com/@host/ in fix_hosts
<%= 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.
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
*** Bug 1129306 has been marked as a duplicate of this bug. ***
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.
Do you only see the problem with IPA realm enabled? Or even with no realm, but
Satellite in one domain, VM in another?
Let me check, as per what you have asked.
Updating what was said on comment5.
Seeing this for both with or without sat6 integrated with IPA Server.
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.
s/fact exepcts/facter expects/
Created redmine issue http://projects.theforeman.org/issues/7384 from this bug
Upstream bug component is Other
Upstream bug component is Provisioning
I think it's probably already fixed, will confirm.
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.