Bug 184484
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: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | urorzm+bugzilla.redhat.com |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-09-26 19:29:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Russell Coker
2006-03-09 07:37:27 UTC
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.
(Sorry, replace '3.0.2' with '3.0.3' above). 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". REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred. Patched in dhcp-3.0.6-7.fc8. |