hostname from dhcp STILL not set, despite multiple ubuntu fixes and bug reports

[perpetualrabbit]

Despite multiple bug reports and attempts at fixes, ubuntu versions maverick and natty do NOT set their hostname from dhcp. See: #537978, #482313, #90388, #476491

Releases:
---------------
   maverick: lsb_release -rd
        Description: Ubuntu 10.10
        Release: 10.10
   natty: lsb_release -rd
        Description: Ubuntu 11.04
        Release: 11.04

Versions of dhcp and hostname packages:
-------------------------------------------------------------------
    maverick:dpkg -l | grep -E dhcp\|hostname
       ii dhcp3-client 3.1.3-2ubuntu6.3 DHCP client
       ii dhcp3-common 3.1.3-2ubuntu6.3 common files used by all the dhcp3* packages
       ii hostname 3.04ubuntu1 utility to set/show the host name or domain name

    natty: dpkg -l | grep -E dhcp\|hostname
       ii hostname 3.05ubuntu1 utility to set/show the host name or domain name
       ii isc-dhcp-client 4.1.1-P1-15ubuntu9.1 ISC DHCP client
       ii isc-dhcp-common 4.1.1-P1-15ubuntu9.1 common files used by all the isc-dhcp* packages

What I expect to happen:
---------------------------------------
     With client configured with empty /etc/hostname, and main network interface configured for dhcp, I expect the hostname to be set during boot.

What happened instead:
---------------------------------------
    With empty /etc/hostname, the machine comes up with (none) as hostname, with /etc/hostname missing entirily, the hostname is set to `localhost´

Elaboration:
-------------------
In networks with lots (dozens or hundreds) of linux workstations I keep the /etc/hostname on each of them empty. They get the hostname from dhcp at boot-time and set it. Managing lots of clients or a HPC cluster becomes impractical if I have to set all hostnames on them by hand. Installation in such a situation typically happens from an imaging host, where one or maybe a few images is used to install on hundreds of clients.
So there must be NO host-specific configuration in these images. Hostnames are set by the dhcp client with information provided by the dhcp server. UUID's are NOT used in /etc/fstab, /boot/grub/grub.cfg, /etc/grub.d/*, or within the initrd.img file. Instead device files are used: /dev/sda for instance. The kernel commandline
root=UUID=db662660-94f7-4e94-8ed4-785fa9938ad0 ro quiet may be correct for the _image_ but not for the client it is copied to! Yes, I could figure out with blkid and script it so that the UUID for the client will be correct in various places, but that is not what I want, it is too error-prone.

I want to be able to configure in /etc/default/dhclient that I want to set the hostname as provided by the dhcp server, and in /etc/default/grub that I want to use device files, not UUIDs.

Unfortunately Canonical gives me no such configuration options at this time, and this is not good for sysadmins like me who need tools to administrate lots of workstations.

Also note that dhcp clients can push a client side provided hostname to a dhcp or dns server, which is useful if you have a laptop that the user has root-access to. My situation is the other way around: the users have NO root-access on the workstations or the HPC cluster, and hostnames are centrally pushed to the clients.

For this latest dhcp host-setting regression I suspect two reasons.
I suspect two reasons:
    1) upstart sets the hostname in recent ubuntu distros, and it simply does:
        exec hostname -b -F /etc/hostname
        This will not work if /etc/hostname is empty!
    2) dhclient does not set the hostname despite being so configured in /etc/dhcp3/dhclient.conf
        Apparantly it is possible to write an exit hook script that sets the hostname like this:
# ===== /etc/dhcp/dhclient-exit-hooks.d/hostname ======
if [[ -n $new_host_name ]]
then
    echo "$new_host_name" > /etc/hostname
    /bin/hostname $new_host_name
fi

Apparantly $new_host_name is the internal variable that dhclient uses for the hostname info that it got from the dhcp server.

The correctly configured dhcp server has stanzas for the clients like this:

  host maris007 {
    fixed-address 10.0.0.7;
    hardware ethernet 00:30:48:58:df:14;
    option host-name "maris007";}

[perpetualrabbit (perpetualrabbit)]

So, adding a file `hostname´ to /etc/dhcp/dhclient-exit-hooks.d/ with this in it:
# ===== begin /etc/dhcp/dhclient-exit-hooks.d/hostname ======
if [ -n $new_host_name ]
then
    echo "$new_host_name" > /etc/hostname
    /bin/hostname $new_host_name
fi
# ===== end /etc/dhcp/dhclient-exit-hooks.d/hostname ======

_kind of_ works to fix this problem. But on text consoles it still reads `localhost login´,
and only after actually login is the hostname there on the prompt. Ugly. So it is not a
complete fix.

Why is it that the hostname gets set so late when I set it up like this? Is the upstart /etc/init/hostname.conf script executed _before_ the upbringing of the network? That could explain this.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[andrew bezella (abezella)]

it appears that this is resolved in xenial/16.04. booting with both an empty /etc/hostname and no /etc/hostname result in the system picking up its dhcp-assigned hostname.

[Robie Basak (racb)]

Thanks andrew. I'll mark this Fix Released accordingly. If this is wrong, please comment and change the bug status back to Confirmed.