Bug 70883 - laptop not getting a hostname via dhclient
Summary: laptop not getting a hostname via dhclient
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: dhcp (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-08-06 14:57 UTC by Jay Turner
Modified: 2015-01-07 23:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-06 01:09:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jay Turner 2002-08-06 14:57:29 UTC
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):


How Reproducible:


Steps to Reproduce:
1. 
2. 
3. 

Actual Results:


Expected Results:


Additional Information:

Comment 1 Bill Nottingham 2002-08-12 20:06:48 UTC
Oh, *ick*. PCMCIA interfaces are done with hotplug, which really has little
concept of ONBOOT.

Comment 2 Elliot Lee 2002-08-27 13:19:18 UTC
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.

Comment 3 Preston Brown 2002-08-29 13:46:21 UTC
jay, can you re-verify this problem?

Comment 4 Jay Turner 2002-08-29 17:03:06 UTC
Yes, I can still verify and just did on a fresh Milan-re0829.nightly installation.

Comment 5 Bill Nottingham 2002-09-03 05:56:12 UTC
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.


Comment 6 Elliot Lee 2002-09-03 13:17:25 UTC
I would argue that if the DHCP server doesn't send a hostname, then it's not correct to set 
one...

Comment 7 Bill Nottingham 2002-09-03 17:50:15 UTC
Our previous behavior is that we set the hostname if need_hostname said to, and
it was a 'boot' configuration.



Comment 8 Elliot Lee 2002-09-03 18:02:27 UTC
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.

Comment 9 Bill Nottingham 2002-09-03 18:05:11 UTC
Presumably, Jay is using our DHCP server, which does not send a hostname, so
he'd fall into the third category.

Comment 10 Bill Nottingham 2003-02-06 01:09:24 UTC
Actually, if it's the last case, then by Sopwith's determination, it's not a bug.


Note You need to log in before you can comment on or make changes to this bug.