Red Hat Bugzilla – Bug 70883
laptop not getting a hostname via dhclient
Last modified: 2015-01-07 18:58:43 EST
Description of Problem:
With the Milan-re0806.nightly tree, for some reason, my laptop is not getting a
hostname assigned via dhclient. I've traced it down to the fact that for a
pcmcia NIC, we are writing "onboot=no" to the ifcfg-eth0 file. Changing this to
'yes' allows the machine to get a hostname at network initialization. What
appears to be happening is that the hostname is set in ifup-post only if ifup
was called with the 'boot' option . . . but if ifup is called with the 'boot'
option and onboot is no, then the initialization will just abort.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Oh, *ick*. PCMCIA interfaces are done with hotplug, which really has little
concept of ONBOOT.
FWIW, dhclient now should set the hostname based only on the need_hostname
function - the problem may have been #68650 in dhclient-script rather than
something in initscripts.
jay, can you re-verify this problem?
Yes, I can still verify and just did on a fresh Milan-re0829.nightly installation.
Elliot, the problem here is that new_host_name is generally not set, because the
dhcp server generally doesn't send a hostname with it.
We could ignore new_host_name, or calculate it ourselves.
I would argue that if the DHCP server doesn't send a hostname, then it's not correct to set
Our previous behavior is that we set the hostname if need_hostname said to, and
it was a 'boot' configuration.
There are three cases when using DHCP:
1. User has a hostname set in /etc/sysconfig/network
2. User has no hostname in /etc/sysconfig/network, and the DHCP server sends a
hostname to the client.
3. User has no hostname in /etc/sysconfig/network, and the DHCP server does not send a
hostname to the client.
I don't think there is any disagreement about what should be done in the first two cases -
hostname should be set to whatever the configured value is. In the 3rd case, the old
behaviour was to do DNS lookups to set the hostname, and the new behaviour that I think
we should continue with is to leave the hostname as localhost. The main advantage with
not changing the hostname is to avoid confusing X (it's more likely that in the 3rd case,
they are on a dynamic IP pool and could get their IP address changed).
If the bug report concerns behaviour in the first two cases, then I've misread and am on
crack and can fix.
Presumably, Jay is using our DHCP server, which does not send a hostname, so
he'd fall into the third category.
Actually, if it's the last case, then by Sopwith's determination, it's not a bug.