Red Hat Bugzilla – Full Text Bug Listing
|Summary:||The next-server option does not get a default value|
|Product:||[Fedora] Fedora||Reporter:||Russell Coker <rcoker>|
|Component:||dhcp||Assignee:||David Cantrell <dcantrell>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-09-26 15:29:59 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Russell Coker 2006-03-09 02:37:27 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.1 (like Gecko) Description of problem: The next-server statement is used to specify the host address of the server from which the initial boot file (specified in the filename statement) is to be loaded. Server-name should be a numeric IP address or a domain name. If no next-server parameter applies to a given client, the DHCP serverâs IP address is used. The relevant section of dhcpd.conf(5) is above. The version of dhcpd in RHEL4 acts in accordance with the man page, but the version in rawhide does not. The impact of this bug is that a dhcpd.conf that works well on RHEL4 for Kickstart installs will fail when used on a rawhide server. Version-Release number of selected component (if applicable): 3.0.3-26 How reproducible: Always Steps to Reproduce: Configure a dhcpd.conf file which has no next-server directive. Run it on RHEL4 and observe that it works with kickstart installs. Run it on a Rawhide server and observe that it fails to operate and gives the following on VC3: ERROR: bootp: no bootfile received INFO: url is 0.0.0.0:/kickstart INFO: file location: nfs://0.0.0.0:/kickstart/X.X.X.X-kickstart Where X.X.X.X is the IP address assigned to the kickstart install. Additional info:
Comment 1 Jason Vas Dias 2006-03-09 09:26:46 EST
Yes, that is correct - the upstream ISC DHCP 3.0.2+ removed the defaulting of next-server to the DHCP server's address, to be in compliance with the RFCs : From /usr/share/doc/dhcp-3.0.2/RELNOTES: ' - The siaddr field was being improperly set to the server-identifier when responding to DHCP messages. RFC2131 clarified the siaddr field as meaning the 'next server in the bootstrap process', eg a tftp server. The siaddr field is now left zeroed unless next-server is configured. ' I mentioned this issue to David Hankins, the upstream DHCP maintainer, who responded as follows: my question: > 1. dhcpd now defaults to a tftp boot file server > ip address of 0.0.0.0 unless the 'next-server' > option is specified - this breaks our default > PXE boot configurations. > > I saw this entry in the change-log: > " > - The siaddr field was being improperly set to the server-identifier when > responding to DHCP messages. RFC2131 clarified the siaddr field as > meaning the 'next server in the bootstrap process', eg a tftp server. > The siaddr field is now left zeroed unless next-server is configured. > " > My question is : what problems did defaulting to the server > identifier cause ? David Hankins replied: --- siaddr is only one of three ways of configuring a tftp server address. There is also a DHCP option, and the 'sname' field. If you preferred one of these "other" two methods (say because it required a DNS resolution, and you could then do DNS round robin on several TFTP servers, or have a number of servers to retry through (if your bootloaders support that)), then your clients would not operate at all - the presence of a non-zero siaddr field prohibits this, they'll try that address and most will not think to also check siaddr or the DHCP option. There's of course the third case that you didn't want to specify a TFTP server address at all. A client may not have the ability to load from TFTP, or if it tried to, it might also be unable to continue down the process of finding a bootable device. If a next-server is specified, that's seen as an all-stop...go load that image and execute it. The system may never try its internal hard drives (or even if it does, the timeout may be lengthy and painful). Most importantly tho, it's against the wording of the RFC, and we try to be a reference implementation. The reference says that's not our server identifier...we should zero it unless explicitly instructed to provide a TFTP boot server. I would like to encourage you towards configuring next-server in the config, as I believe you have to include a chunk of dhcpd.conf space stuff to provide PXE options anyway? next-server = config-option dhcp-server-identifier; I believe that will do what you want, since the config-option space for the server-id is constructed (if that option is not specified) a few lines above where next-server is evaluated. I haven't tried this, I trust you will test it. If it doesn't work out, we should really look at a special case config for next-server as meaning "the calculated server id". Something like "next-server self;". --- So, in short, the dhcpd.conf of 3.0.2+ must specify an explicit value for next server, or a default such as David suggested above: ' next-server = config-option dhcp-server-identifier; ' We should keep our dhcpd implementation in line with the upstream implementation, and also be compliant with the RFCs - if we want to do so, using an explicit next-server setting in dhcpd.conf is the only way to go.
Comment 2 Jason Vas Dias 2006-03-09 09:29:46 EST
(Sorry, replace '3.0.2' with '3.0.3' above).
Comment 3 Russell Coker 2006-03-09 17:32:12 EST
In that case please change dhcpd.conf(5) to correctly describe what is happening. Instead of saying "If no next-server parameter applies to a given client, the DHCP serverâs IP address is used" it should say "If no next-server parameter applies to a given client, the address 0.0.0.0 is used".
Comment 4 Red Hat Bugzilla 2007-02-05 13:55:55 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 5 David Cantrell 2007-09-26 15:29:59 EDT
Patched in dhcp-3.0.6-7.fc8.