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