DHCP plays the pivotal role for using OF as a network controlled boot manager.
We want to run our own DHCP server for many of the same arguments as already outlined in privatenet.html.
Essentially so we have timely and complete control. Most reference material, and indeed the documentation that comes with ISC's DHCP server implores administrators not to run more than one DHCP server on a network at the same time. In truth, savvy administrators can find plenty of examples where this is done. One example is Apple, who not use a custom/extended DHCP daemon to implement their MacOS netboot server, but also provide us with a "default-gateway-ip" setting in the OF.
With the right configuration and planning it presents no problems. This is the topic of this document.
Our "rouge" DHCP server should only serve OF, and linux but should completely ignore ignoring MacOS. OF should not be subject to race conditions between the two DHCP servers (our "rogue", and the "official" one), but should always use our server.
Setting "default-gateway-ip" in OF accomplishes this latter task perfectly. In the event our DHCP server is non responsive for any reason, after an adjustable timeout, OF will boot MacOS.
Applying a one line patch to ISC's DHCP server (version 2) to implement a more useful handling of the "vendor class" parameter gives us the ability to ignore MacOS based on the vendor identification string of the DCHP:DISCOVER packet.
Lastly, we need to be sure our DHCP server handles only known hosts. This means we have to collect MAC addresses, for each node in our cluster and add them to the /etc/dhcpd.conf file.
The above measures ensure that the addition of our "rogue" DHCP server to the network will cause no interference whatsoever with the normal(daytime) operation of the network and G4 machines.
The only thing we need to watch out for, is that we don't leave the cluster boot settings on the "master" server set to boot linux during the day. This can be automated using /etc/crontab.
To ensure our linux clients use our DHCP server and not the "official" one, we use a bit of trickery. We configure their /etc/dhclient.conf files to request a specific option which of course only our DHCP server provides. Thus they reject any DHCP:OFFERS from the "official" DHCP server.
NOTE: add links to the DHCP RFC.