Hi.
Browsing the kickstart list I found that I am not the only one who might
have a use for specifying a custom DHCP vendor class identifier, which,
in RFC 2131, is a "SHOULD" requirement for clients. Both dhcpd and
dhcpcd already support it; what is missing is the little bit of
infrastructure necessary to have dhcpcd (and anaconda's built-in pump
client) easily configured to use it.
https://listman.redhat.com/archives/kickstart-list/2003-June/msg00125.html
Also hoping that the feature could make it for the next beta, I quickly
created some patches for ifup, libpump.a and anaconda's kickstart. To be
honest, not only I haven't tested them, I haven't even had the chance to
compile them yet -- no access to my main system right now.
I bet there are problems with the code as it is and I must have missed
something, but I thought it could be worth starting to discuss whether
or not the idea has merit. Somebody with more anaconda/pump experience
might be able to quickly point out any flaws. I should be able to test
the patches later today; in the meantime you can give them a look at
http://uberh4x0r.org/~yax/dhcp_classid/
One shortcoming that I can see so far, if I understood the anaconda code
correctly, is how to pick up the class ID while in rescue mode. In that
case, though, you can still restart dhcpcd manually with the appropriate
-i switch.
The patches add a new "ksclass" boot loader option and a "--class"
switch to kickstart's "network" option. Which reminds me I need to
update the documentation as well.
The use of the two new keywords is orthogonal; e.g. in some cluster
setups you might want to use the former, but not the latter -- or
viceversa. For the time being, no changes are applied to any user
interfaces, as this is a feature that is hardly going to be needed by
anyone but power users. I.e., if you require it, you are likely using
kickstart installs already.
I did not file a Bugzilla report because I wasn't sure which component
it applies mainly to. I can create one -- or three, for each of the
components -- if deemed more appropriate.
Rudi