Decided to play around with this a little more, as proof of concept, since
the manpage examples didn't *exactly* match the desired usage here.
Here is a slice of dhcpd.conf that does the right thing (with dhcp3):
group {
next-server 192.168.1.3;
host tftpclient {
# tftp client hardware address
hardware ethernet 00:10:DC:27:6C:15;
filename "/tftpboot/pxelinux.0";
}
}
class "vendor-classes" {
match option vendor-class-identifier;
}
subclass "vendor-classes" "D-I" {
next-server 192.168.1.3;
filename "preseed-gunk";
}
With a dhcp2 server, it appears the last two stanzas should be replaced
with this:
vendor-class "D-I" {
next-server 192.168.1.3;
filename "preseed-gunk";
}
On the client side, I've set
send dhcp-class-identifier "D-I";
in dhclient.conf.
--
Steve Langasek
postmodern programmer
On Tue, Nov 30, 2004 at 01:41:19AM -0800, Steve Langasek wrote:
> On Tue, Nov 30, 2004 at 03:12:04AM -0500, Joey Hess wrote:
> > Next I looked at the dhcp rfcs. The dhcp options seemed like the obvious
> > way to get an url passed from dhcp to d-i. I looked at using option 43,
> > the vendor defined option, since its use is quite close to how d-i would
> > work. However, at least the debian dhcp package does not allow option-43
> > in dhcpd.conf.
> > We could pick an option in the 128-254 range and use it, but we might be
> > violating rfc2939 by doing so, since it requires that these "MUST NOT be
> > defined for use by any publicly distributed DHCP server, client or relay
> > agent implementations". I'm not sure how much wiggle room there is in
> > "client" -- it's not like d-i's dhcp client would know about the option,
> > though d-i would, and we'd have to put something like "request option-nnn" in
> > dhclient.conf. There's always the potential that whatever private use
> > option number we choose will be used at some installation site for
> > something else.
> > We could add a boot option to make d-i look at a particular dhcp option
> > for preseeding, and leave it up to the admin. preseed/dhcp_opt=128. This
> > might still run out of kernel command line space on hppa (it's very
> > small) and it's a lot of layers of indirection to get to the preseed
> > file.
> > We could go through the process to get an option numer assigned by iana.
> > I don't have the time or the patience, but if someone does this is
> > probably the best way.
> dhcpd.conf(5):
> CLIENT CLASSING
> Clients can be separated into classes, and treated differently depend‐
> ing on what class they are in. This separation can be done either
> with a conditional statement, or with a match statement within the
> class declaration. It is possible to specify a limit on the total
> number of clients within a particular class or subclass that may hold
> leases at one time, and it is possible to specify automatic subclassing
> based on the contents of the client packet.
>
> To add clients to classes based on conditional evaluation, you can
> specify a matching expression in the class statement:
>
> class "ras‐clients" {
> match if substring (option dhcp‐client‐identifier, 1, 3) = "RAS";
> }
>
> Note that whether you use matching expressions or add statements (or
> both) to classify clients, you must always write a class declaration
> for any class that you use. If there will be no match statement and
> no in‐scope statements for a class, the declaration should look like
> this:
>
>
> This provides the means to distinguish PXE boot requests from other DHCP
> requests sent by d-i systems looking for preseed information, so that you
> can overload next-server/filename for both steps of the install using
> different DHCP class configurations.
Attachment:
signature.asc
Description: Digital signature