--On Wednesday, November 03, 2010 06:18:52 PM -0400 Daniel Feenberg
<feenberg at nber.org> wrote:
> I have 2 groups of machines, and within each group the pxelinux menu
> configuration is standard. It would be great to have 2 configuration
> files rather than one for each machine.
>
> I found the pxelinux magic option configfile (209) in
>
> http://syslinux.zytor.com/wiki/index.php/PXELINUX
>
> and it suggests for ISC dhcpd:
>
> site-option-space "pxelinux";
> option pxelinux.magic f1:00:74:7e;
> option pxelinux.configfile "common";
>
> however version 4.1.1-P1 rejects this syntax, claiming not to recognize
> "pxelinux" in the first line. The wiki suggests this is good for
ISC
> dhcpd version 3 - is it possible 4.1.1-P1 does not support it?
It works fine, but you failed to copy the block above which defines the
"pxelinux" option space. Without that, the DHCP server doesn't
know what
you're talking about.
> In looking for an answer, I found http://tools.ietf.org/html/rfc5071
> which states that "The option code 208 will be adopted for this
purpose
> and immediately deprecated." It also states "The magic option MAY
NOT be
> implemented, as it has been deprecated." This leaves me quite
confused.
Not surprising, if you haven't followed all of the references and perhaps
also read some of the mailing list traffic leading up to RFC3942.
Particularly, consider these points...
Option codes 128..254 were previously classified as "site options",
intended to be defined by local administrators in cases where the DHCP
servers and all relevant clients are explicitly known to agree on their
meaning. Unfortunately, DHCP option codes are scarce, and this range
represented fully half of the available option codes. To make things more
complicated, quite a few hardware and software vendors designed their
products to respond to site-specific options rather than vendor-specific
options (the latter are encoded in a different way, which identifies the
vendor and does not conflict with non-vendor options). To address these
issues, RFC3942 reclassified codes 128..223 to make them available for
public assignment, essentially cutting the number of site-specific options
in half. It also specified means for documenting existing vendor-specific
use of options in this range.
What RFC5071 does is document the four options in use by PXELINUX, and
adopt the three which actually carry configuration (the config file, path
prefix, and reboot timeout options). The text you quote pertains to the
fourth option, "MAGIC", which was intended to allow PXELINUX to detect
cases where the same option codes were used for data intended for another
purpose. Since the three useful codes are now actually registered, the
MAGIC option is not actually needed. The first sentence you quote
describes what was done with that option code: it was added to the
registry, to document its purpose, but immediately marked deprecated,
because it is no longer needed and can safely be reallocated.
The second sentence you quote describes how implementations of RFC5071 are
expected to behave with respect to the MAGIC option, code 208. It applies
only to that option and not to the config file, path prefix, or reboot
timeout options. Further, it must be read in the context of RFC2119, which
defines the uppercase requirements keywords. "MAY" means that a
compliant
implementation is permitted, but not required, to do something. "MAY
NOT"
means that a compliant implementation is permitted, but not required, to
NOT do something. That is, they mean the same thing. "MAY NOT" does
not
mean the same as "MUST NOT".
In any case, PXELINUX does implement option codes 209..211. I don't recall
whether it still implements option 208, but as long as you provide it with
the correct value or not at all, it doesn't matter.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Carnegie Mellon University - Pittsburgh, PA