DHCP Help Again

[Robert G. Brown]

On Wed, 10 Apr 2002 tegner at nada.kth.se wrote:

> Very helpful! Thanks!
> 
> But I'm still curious about how you make - automagically - the hardware ethernet
> line in dhcpd.conf initially. Say you have 100 machines. One way I would think
> of would be to use kickstart and:
> 
> Install the machines and boot them up in sequence and using the range statement
> in dhcpd.conf (so that the first machine gets 192.168.1.101, the second
> 192.168.1.102 ...)
> 
> Once all nodes are up use some script to extract the mac addresses for all the
> nodes and either modify dhcpd.conf - or - discard of dhcp completely and
> hardwire the ip-addresses to each node.
> 
> But I'm sure there are better ways to do this?

Not a whole lot better.  Since our installations tend to be O(10)
systems at a time (10-30, not hundreds) and since we've gotten our local
vendor to label each node with the MAC address before delivery (they've
gotta boot up and burn in each node anyway) we just pop the nodes in a
rack and use a script to insert a static entry for each one in an order
that corresponds to rack order.  After all, even though yes we label the
nodes, it would be a bit silly to have g01 next to g22 next to g13 in
rack order, and since we use the same dhcp server for nodes that we use
for the general department, we cannot guarantee that some other host
won't request and be granted a floating IP number that breaks the
ordered sequence.

The alternative (which would work fine for a cluster with a dedicated,
in-the-local-isolated-net, and hence predictable dhcpd server) is to
write the scriptset you describe, which we've actually considered doing.
Boot the nodes in rack order, with floating addresses hopefully assigned
in strict order from the address range, let them install themselves, and
in the meantime write a script that parses e.g. /var/log/messages for
the DHCP request and offer messages or /var/lib/dhpc/dhcpd.leases for
the MAC and IP mapping and creates the required host and dhcpd.conf
tables.  

We haven't gone this way partly out of laziness -- with tens of systems
at a time to install it will only save work (relative to the time
required to write the scripts) after we've used the scriptset for years
-- and partly because to our direct observation at least one node
install in twenty or thirty will screw up and occur in the wrong order.
This, of course, will screw up EVERYTHING -- either one physically
rearranges the rack or hand edits the tables, either of which costs one
far more than the labor saved in the first place.

There may be a better solution (probably smarter, more complex scripts
that can perform e.g. node insert and delete operations and hence manage
a reordering of the tables without having to hand edit everything) but
more complex scripts require a signficant investment in time and one
needs a very clear conceptualization of the design to have a good chance
at ending up with something really usable.  This in turn requires
experience with the simpler scripts and a time living with their
frustrations.  We just don't have enough nodes to do all this except for
the fun of it -- maybe a really big DOE site does but we don't.  So
we'll likely continue to use simple-building block scripts that require
the entry of the MAC address and desired hostname/IP mapping as
parameters (possibly augmented by a script that extracts MAC addresses
from the log files, since even with help for the vendor we often have
nodes or workstations to install with unknown MAC addresses and have to
boot once, get the MAC address, and boot again to do the install).

Not to beat dead horses or anything, but (IMHO) a lot of this management
scriptset development is retarded by the fact that every single system
tool has a configuration file with its own unique format and structure.
I am well on the way to becoming downright religious about using xml as
THE basis for the formatting of this sort of thing, at least where one
can choose to do so in future applications.  If dhcpd.conf and
dhcpd.leases were written in an xml-compliant way, it would both make
much better logical sense and it would be easier to both parse and write
tools to manipulate them.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu