I have some patches available at http://uberh4x0r.org/~yax/dhcp_classid/

They change pump's ABI, but after a brief look Jeremy Katz didn't seem to
think it was something unreasonable.

I should have a newer, tested patch set up by tomorrow.

this looks pretty good. will integrate. thanks for the patch

Cool! What will the VCI look like?

My patches add a new boot keyword, ksclass. If you don't specify it, the old
behaviour - not sending any vendor class identifier - is preserved. There is
also a new "--class" switch for the "network" option, in case you want to use
the same ID (or a different one!) on subsequent boots. I am not sure if Red
Hat is going to go for a non-null default in any case.

I have just uploaded a new version of the patches, adding a description of the
new boot keyword to command-line.txt and making sure pump doesn't break. I have
managed to build new anaconda and pump-devel packages by patching those in Raw
Hide, so I know that at least my changes compile now, but I am not able at the
moment to create new boot images to test. :(

I'm sorry to ask, but is there any chance my patch might make it for tomorrow's
Fedora code freeze?

I just uploaded a new version of my patch set. Two major changes: it no longer
breaks the old pump ABI and it makes sure it sends the class ID on the first
DHCPDISCOVER request as well. For some reason, pump sends a minimal DHCPDISCOVER
first; then, after a DHCPOFFER has been received, sends another one with more
details (list of parameters requested, etc.). The source claims this is done to
be RFC-compliant, but it's not clear to me which RFC (and which section thereof)
that would be. BOOTP? DHCP?

I have managed to test the patches in a production environment (a cluster),
using patched boot images (built from RawHide and from fudging the latest
boot floppy from Fedora). It works for me.

the pump changes have been made. however, in order for them to be used, anaconda
needs to be changed to use it.

(the bug report says RAWHIDE, but the pump code is actually available from CVS
and from a seperate subdir)

Rudi, a couple comments on the VCI patch.

Isn't the main goal here so that the DHCP can return conditional
responses (aka paths to unique kickstart files) based on the VCI?IMO,
it should send a VCI by default. 

If it doesn't and it requires specifying the ksclass option, I might
as well type the explicit path to the kickstart file (ala
ks=http://server/foo.ks).

The default VCI should identify:
* The distro (RHEL, Fedora, Debian, etc)
* The version of the distro (version of Anaconda?)
* The CPU architecture (ia32, ia64, amd64, etc)

Hi Dax.
It looks as if I get to work on a new cluster (and have fun with DHCP
magic) every time a Fedora release is imminent.

Yes, DHCP can return conditional responses based on the VCI, but at
least in my case the important thing to vary was the IP address, not
the kickstart file.

A bit of background: I needed to add nodes to the cluster, one by one.
I needed to give them static IPs and hostnames. And I needed them to be
assigned pretty much in order (the box with the sticker '1' gets
node001, etc.). And I needed to support several clusters, too.

The obvious way to do this was to write down manually the Ethernet MAC
addresses and generate DHCP/DNS configuration files through a script.

But I am too lazy for that, so I created a floppy that booted with a
custom VCI. The VCI changes for each cluster. There's a DHCP range for
each cluster, for "fresh" nodes that haven't been seen before. The
kickstart file is served by a shell CGI (which does not tie a cluster
to a given distribution or viceversa), which also checks the remote
IP, gets the MAC address from the ARP cache and adds it to the list
of members of the cluster. Then another script is run, regenerating
the DHCP and DNS files from scratch. With all of this in place, all
I needed to do was to boot the nodes one by one with a special
floppy.

So you'll still ask: sure, that's great, but why tie a VCI to an IP
range? You can still get to the KS file you need with the KS keyword
and the shell CGI doesn't care about the IP you happen to be using,
because all it records is the MAC address.

Well, the latter is actually incorrect. The shell CGI won't serve
you any Kickstart files, unless you are in one of the 'blessed' ranges
for registering nodes. I did this because I was asked the 1 million
dollar question: what happens if someone swaps cables and the internal
NIC (meant to talk to the cluster) ends up on the intranet? The person
who asked me the question wasn't likely to make such a mistake, but
we couldn't discount that at some point, someone might have ended up
connecting and disconnecting stuff without full knowledge of what they
were doing.

The solution was to have DHCPD hand out addresses only to

a) registered MACs or
b) fresh MACs which are using one of the special VCIs (which act like
a simple password)

Does that make sense now?

Back to your proposal of sending a VCI by default... yes, that makes a
lot of sense. What I remember doing last year was hunting down what
dhclient does and replicate it in pump. I seem to recall that it
sent some of the uname information. I'll try to locate the code tomorrow.

Does it make sense for Anaconda to send the same VCI that dhclient
sends? Or should we differentiate the two? That could be done by
either sending a totally different VCI or, maybe, appending some extra
text.

Do you know what's the current behaviour of Anaconda and dhclient?
What do they send at the moment? We have a new cluster coming this
week and, with the excuse of triaging stuff on it, I might try working
on this issue once for all - hopefully in time for FC3.

Rudi