Hi,

I recently tried to move my dhcpd.conf from a kludgy to a more generic
version. I want to provide a single "NetBSD" class which hands out root
paths automatically based on the host-decl-name that was used and the
provided vendor identifier. I have 6 possible archs to toy around with.

While I'm really glad that NetBSD - as opposed to any other system I
tried - uses a _helpful_ vendor identifier of the form

"NetBSD:<arch>:[libsa|kernel]:<version>"

I'm still missing something. First, the string manipulation functions
of dhcpd are really archaic. My current class definition checks for
NetBSD like this:

match if substring(option vendor-class-identifier, 0, 6) = "NetBSD";

I then go on dissecting the string with the unflexible substring() to
divert processing based on the arch and whether it is the boot loader or
the kernel that requests a lease. Obviously, I can't just use a single
snippet that extracts the arch and puts it into the root path, because
the arch names are not of fixed lengths.

As a side note, I noticed that the sparc64 ofwboot doesn't even use
DHCP but BOOTP. Kinda spoiled my plan to have a uniform config.

While playing with PXELINUX - AFAIK the only loader that can load the
BSD's PXE boot loaders - I noticed they use an option space "pxelinux"
with several options beneath, like pxelinux.configfile. While this is
used on the server to pass options to clients, would this also work
the other way around - a client passing such options to the server? We
could have netbsd.arch, netbsd.version, netbsd.loader and netbsd.kernel
or similar. The names are rather arbitrary, what matters are the numeric
option codes.

This would massively ease the creation of compact and powerful dhcpd
configs. Although the current drawbacks are more the result of dhcpd
lacking some sophisticated string processing like regexes, I like the
idea of having separate data snippets instead of a single string with
data glued together by ':'.

Is this a worthwhile idea?

Regards,

ND