Bug 78843 - Have Anaconda's DHCP client send a Vendor Client Identifier
Have Anaconda's DHCP client send a Vendor Client Identifier
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pump (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eido Inoue
: FutureFeature
Depends On: 107946
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-01 18:32 EST by Dax Kelson
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-24 15:37:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dax Kelson 2002-12-01 18:32:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
I would be EXTREMELY helpful if Anaconda's dhcp client (pump for now) sent a VCI
(Vendor Client Identifier).

For example:

Anaconda-7.3
Anaconda-8.0
Anaconda-8.1 

etc, etc.

The ISC DHCP server shipped with RHL 8.0 includes conditional behavior support,
so you could do stuff on the DHCP server like:

cat /etc/dhcpd.conf

if substring (option vendor-class-identifier , 0, 12 ) = "Anaconda-8.1" {
   filename "kickstart-8.1.ks";
} elsif substring (option vendor-class-identifier , 0, 12 ) = "Anaconda-8.0" {
   filename "kickstart-8.0.ks";
} elsif substring (option vendor-class-identifier , 0, 12 ) = "Anaconda-7.3" {
   filename "kickstart-7.3.ks";
} elsif substring ( option vendor-class-identifier , 0, 9 ) = "Etherboot" {
   filename "eboot.nbi" ;
} elsif substring (option vendor-class-identifier , 0, 10 ) = "PXEClient:" {
   filename "eepro100.pxe" ;
} elsif substring (option vendor-class-identifier , 0, 4 ) = "MSFT" {
   option netbios-name-servers     10.100.0.254;
} else {
   stuff;
}
[snip rest of dhcpd.conf]
Comment 3 rudi 2003-10-07 01:25:02 EDT
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.
Comment 4 Eido Inoue 2003-10-07 14:54:10 EDT
this looks pretty good. will integrate. thanks for the patch
Comment 5 Dax Kelson 2003-10-07 15:42:42 EDT
Cool! What will the VCI look like?
Comment 6 rudi 2003-10-07 19:51:26 EDT
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. :(
Comment 7 rudi 2003-10-23 14:03:38 EDT
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.
Comment 8 Eido Inoue 2003-10-24 15:37:37 EDT
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)
Comment 9 Dax Kelson 2003-12-09 00:08:01 EST
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)
Comment 10 Rudi Chiarito 2004-10-03 23:21:40 EDT
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

Note You need to log in before you can comment on or make changes to this bug.