Ubuntu
dhcp3 package

Lucid dhclient can't set hostname

Bug #537978 reported by Valentijn Sessink
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
dhcp3 (Ubuntu)
Fix Released
Medium
Thierry Carrez
Lucid
Fix Released
Medium
Thierry Carrez

Bug Description

Until recently (up to and including Karmic), there was a "set_hostname()" function in /sbin/dhclient-script, that said:
set_hostname() {
    local current_hostname=$(hostname)
    if [ -z "$current_hostname" -o "$current_hostname" = "(none)" ]; then
        hostname "$new_host_name"
    fi
}

Up to 9.04, this would work when there was no /etc/hostname. With 9.10 (Karmic), this changed: a missing /etc/hostname sets the hostname to "localhost" and the dhclient-script will no longer set the hostname: this bug is reported as bug #482313 and bug #523188 - see bug #482313 for the fix we have been using for years.

Now with Lucid, the whole thing goes wrong, as the set_hostname() function is missing. There's only:
    BOUND|RENEW|REBIND|REBOOT)
        if [ -n "$old_host_name" -a -n "$host_name" -a \
             "$host_name" != "$old_host_name" ]; then
            hostname "$new_host_name"
        fi

This is plain wrong for two reasons:
1) as far as I can see, the $host_name variable does not exist at all; there's only an "old_host_name" and a "new_host_name", but "host_name" does not exist - which means the test will never be true.
2) if the test would be true at all, it would still only change the hostname if there is a change in the *dhcp-server supplied hostname*, i.e. if the hostname used to be "foo" and suddenly, the dhcp-server sends a hostname "bar", then the hostname will change.

This is also against the dhclient documentation, see "man dhcp-options":
option host-name string;
          This option specifies the name of the client. The name may or may
          not be qualified with the local domain name (it is preferable to use
          the domain-name option to specify the domain name). See RFC 1035
          for character set restrictions. This option is only honored by
          dhclient-script(8) if the hostname for the client machine is not
          set.

This is no longer true: under Lucid, the hostname will not be set at all, no matter what you try to do.

See original description

Related branches

lp:ubuntu/lucid/dhcp3
Valentijn Sessink (valentijn)
description: updated
Revision history for this message
Chuck Short (zulcss) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Lucid Lynx. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

Changed in dhcp3 (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Valentijn Sessink (valentijn) wrote :

The live-CD has an /etc/hostname set to "ubuntu", so what do you want me to check? Apart from that, the /sbin/dhclient-script file is the same as above, so the logic to change the hostname does not work and is not conforming to the dhclient-documentation.

Revision history for this message
Thierry Carrez (ttx) wrote :

Regression was introduced by the fix to:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508804

It could be fixed by fixing the obviously wrong patch, and support two cases:
 * Set hostname if new_host_name provided and hostname is not set
 * Set hostname if new_host_name provided and old_host_name matches the current hostname

Something like

local current_hostname=$(hostname)
if [ -z "$current_hostname" -o "$current_hostname" = "(none)" -o "$current_hostname" = "localhost" -o "$current_hostname" = "$old_host_name" ]; then
  if [ -n "$new_host_name" ]; then
    hostname "$new_host_name"
  fi
fi

However I am not so sure we should support the use case of the debian bug since option host-name should only be "honored by dhclient-script(8) if the hostname for the client machine is not set"...

Bug 482313 would be fixed in the same run (by adding "localhost" to the set of hostnames considered "unset").

Changed in dhcp3 (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Chuck Short (zulcss) wrote :

Thierry,

hostname is set by upstart so the point is moot I think.

Regards
chuck

Revision history for this message
Thierry Carrez (ttx) wrote :

The upstart task sets the system hostname from /etc/hostname (falling back to "localhost" if that file is not readable or is empty and no hostname has yet been set).

The idea here would be honor new_host_name for the same use cases (if the /etc/hostname file is non-empty). That would support both the first case (honor DHCP new_host_name if no hostname=localhost) and the case the debian bug tries to cover (honor further DHCP new_host_name if hostname was previously set by DHCP)

Something like:

if [ -n "$new_host_name" ]; then
  if [ ! -s /etc/hostname ]; then
     hostname "$new_host_name"
  fi
fi

Changed in dhcp3 (Ubuntu Lucid):
assignee: nobody → Thierry Carrez (ttx)
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dhcp3 - 3.1.3-2ubuntu3

---------------
dhcp3 (3.1.3-2ubuntu3) lucid; urgency=low

  * debian/dhclient-script.linux: Fix regression in host_name option
    handling, so that it's always honored when /etc/hostname is not set,
    fixes LP: #537978, #482313, #90388, #476491
 -- Thierry Carrez <email address hidden> Thu, 01 Apr 2010 16:52:36 +0200

Changed in dhcp3 (Ubuntu Lucid):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.