Hide Forgot
When you have a box without FQDN: [lzap@ox ~]$ hostname --fqdn localhost [lzap@ox ~]$ hostname --short ox Ruby "facter" thing tries to determine the FQDN from /etc/resolv.conf. See this: [root@ibm-x3620m3-01 ~]# vim /usr/lib/ruby/site_ruby/1.8/facter/hostname.rb [root@ibm-x3620m3-01 ~]# vim /usr/lib/ruby/site_ruby/1.8/facter/fqdn.rb [root@ibm-x3620m3-01 ~]# vim /usr/lib/ruby/site_ruby/1.8/facter/domain.rb We should not "guess" it, but only use the proper value using the "hostname" call. We should also modify our resolv checker to check for both short and long names.
@Ohad I think the best way would be to "override" the Puppet fqdn and domainname variables with `hostname --fqdn` call, what you think? If FQDN was not set, it should not be "guessed". Any idea where to put such an override statement? ;-)
I'm not 100% sure its guessed, afair the flow is: 1. hostname 2. dnsdomainanme 3. domain statement in /etc/resolv 4. search statement in /etc/resolv I think the only unpredictable part is #4, and ideally most systems should have #1 set correctly. you can override it with a simple environment variable: export FACTER_fqdn="boo.foo.bar" $ facter fqdn boo.foo.bar
Commiting 9935218 760265 - Puppet guesses the FQDN from /etc/resolv.conf I will commit the same for :domain but we do not use this variable. This should fix it. Tagging:
katello-configure-0.1.26-1 should fix this
After installing katello-configure-0.1.26-1, running katello-configure on a system used to trigger this original failure, I'm unable to reproduce this problem. translation ... katello-configure-0.1.26-1 seems to FIX the problem for me.
This is cool, I will add the same for :domain tomorrow. Thanks James!
I have been playing with hostnames yesterday and I had to stop for a while today doing a little research. Setting up a hostname is not a hard task, in Fedora and Red Hat it's a matter of editing one file: # grep HOSTNAME /etc/sysconfig/network HOSTNAME=test.lan Here you set the whole FQDN. If you ever seen entries like DOMAINNAME in this file, they are wrong for Fedora or RHEL. If you want to change hostname without rebooting few steps are necessary: # hostname test.lan # service network restart I skipped one simple, yet important step - setting _/etc/hosts_. It differs for situations when you use DHCP or not. **Clients with DHCP** With properly configured DHCP server, hostname should be propagated or defined by network administrator, there is no need of adding hostname to the _/etc/hosts_. For clients, it is really not necessary. Trust me. Keep only localhost there, walk your dog, enjoy life. **Servers with static IP** This is totally different scenario - server with static IP address must have entry in the _/etc/hosts_ file in the following format (assuming a random class C address): # grep test /etc/hosts 192.168.1.1 test.lan test Please note the order matters. You must keep the following order: _ipaddress fqdn hostname_. I recommend to do a check-up after adding entries: # hostname test.lan # hostname -s test # hostname -f test.lan With the incorrect order you will see _hostname -f_ returning non-fully qualified response: # grep test /etc/hosts 192.168.1.1 test test.lan # incorrect order # hostname -f test The key for this behavior is in the manual page of hostname command: The function gethostname(2) is used to get the hostname. When the hostname -a, -d, -f or -i is called will gethostbyname(3) be called. The difference in gethostname(2) and gethostbyname(3) is that gethostbyname(3) is network aware, so it consults /etc/nsswitch.conf and /etc/host.conf to decide whether to read information in /etc/sysconfig/network or /etc/hosts. **Servers with DHCP** Wait a minute! A server without static IP address? Does it make sense? Well, in the cloud it is not unusual to provision servers configured with DHCP. If this is your case, I recommend to stick with the _servers with static IP_ rule. If the IP address changes rapidly, I would recomment _clients with DHCP_ rule, but make sure hostname command returns correct answers for both -s and -f options, as seen above. In the latter case, contact your cloud provider asking how to set up hostname properly. Sometimes in testing environments servers with IPs delivered by DHCP servers do not have proper DNS setup. And you can have a service that insists on having hostname resolved. In this case, only in this case, I would recommend adding loop back hostname entry: # grep test /etc/hosts 127.0.0.1 test.lan test Again, keep the right order and make sure it does not mess up services on that box. Be prepared to see "Cannot determine hostname" warning when starting Apache for example.
QA Verified. I have installed using authoritative static hostnames and dynamic hostnames -- properly configured per comment #7 above -- and things seem to 'just work' -- I don't seem to have any warnings during install, nor any problems with agents connecting to server, etc. Consider this one QA Verified.