Your message dated Sun, 23 Oct 2011 12:29:15 -0400
with message-id
<CANTw=mntt_2nzyiq6r-xs9rjyrhi3jzvjjurkglypwahqsw...@mail.gmail.com>
and subject line fixed
has caused the Debian Bug report #609851,
regarding incorrect variables used to set hostname in dhclient-script
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
609851: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609851
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: isc-dhcp-client
Version: 4.1.1-P1-15
The logic to set the hostname on boot when that hostname is supplied via
dhcp is not working. Looking at the code in dhclient-script, it appears
flawed. Testing reveals unexpected content in the variables.
My environment: the dhcp server is sending 'option host-name' to send the
hostname to the client. Examining /var/lib/dhcp/dhclient.eth0.leases shows
that the hostname is present. The same environment successfully hands out a
hostname when the system is booted with Lenny; it fails when the system is
booted with Squeeze. Note that I removed /etc/hostname to force it to get
the hostname from dhcp. The hostname is being handed out by a system
running Debian Etch and dhcp3-server 3.0.4-13+etch2
The code that sets the hostname on lenny is as follows:
/sbin/dhclient-script from dhcp3-client version 3.1.1-6+lenny4, lines 102 to
107
set_hostname() {
local current_hostname=$(hostname)
if [ -z "$current_hostname" -o "$current_hostname" = "(none)" ]; then
hostname "$new_host_name"
fi
}
The code that sets the hostname on squeeze is as follows:
/sbin/dhclient-script from isc-dhcp-client version 4.1.1-P1-15, lines 155 to
158
if [ -n "$old_host_name" -a -n "$host_name" -a \
"$host_name" != "$old_host_name" ]; then
hostname "$new_host_name"
fi
The first thing that I believe is a bug is that the if clause tests against
$old_host_name and $host_name, but the hostname is set to $new_host_name.
I put some print statements around this clause to show the contents of the
three variables.
On boot, $old_host_name is empty, $host_name is empty, and $new_host_name
has the hostname given to the machine from dhcp. Since this if clause tests
that both $old_host_name and $host_name are non-empty, the statement to set
the hostname is not executed.
If, after the system has booted, I run '/etc/init.d/networking restart', the
contents of the variables are $old_host_name = the host name assigned by
dhcp, $host_name is empty, and $new_host_name is the hostname assigned by
dhcp. Since $host_name is empty, the statement to set the hostname is not
executed. Note that even though $old_host_name contains the hostname given
out by dhcp, the hosts' name (as shown by running 'hostname') is "(none)".
$old_host_name seems to be incorrectly populated.
I believe the previous behavior of setting current_hostname=$(hostname) and
testing it against "(none)" will cause the system to behave as I expect. I
don't understand why the previous hostname must have content in order for
the new hostname to be set, and it seems as though testing $host_name
instead of $new_host_name is a typo.
Thank you,
-ben
--- End Message ---
--- Begin Message ---
version: 4.1.1-P1-17
--- End Message ---
