On Sept. 25, 2013, at 10:23 PM, Lonnie Olsen wrote:
> I understand lazy. It's not a bad thing for a sysadmin either. But > maybe you should consider it as well. :) Believe me, I have. Unless my understanding of the dynamic update functionality of ddns is wrong, it won't quite do what I was looking for. Maybe I'm wrong. If so, please tell me, and preferably show me an example somewhere that shows the implementation, but my understanding of ddns is that it wouldn't quite work for this instance. See, the problem is that the different IP ranges for the different physical locations are different SIZES (one is a simple class C, the other is a subnet'ed class B). Therefore, the only way I could maintain the reverse pointers was to either define one in-addr.arpa zone for the whole 192.168.X.Y class B subnet, or to define multiple Class C in-addr.arpa zones. Now my understanding (and again, this could be wrong, so if it is please tell me!) is that DHCPd's ddns updates can't do that. If it even supports updating the in-addr.arpa PTR records at all (which I can't tell if that is doable or not), it's going to expect one security key per zone. That would be fine if I had, for example, zone upper.rec (bogus name, but gets the idea across) in the file upper.zone, and had a ddns update key for it and it's in-addr.arpa zone, then another for lower.rec and it's in-addr.arpa zone. The problem is that in this instance I either have one in-addr.arpa zone for upper AND lower, or I have multiple zone files for lower since lower is the subnet'ed class B range. As to the rest, that's already in place. Here's the logic I have implemented: * New workstation A boots into the network for the first time (diskless PXE boot) * As there is no PXE config file matching it's MAC address the file pulled is the "default" file. * Default indicates that NFS root is 192.168.0.1:/nfsroot/newboxroot, with a basic kernel. * This kernel boots, pulls the specified NFS root, and then, during boot, extracts the 3rd and 4th octets of the IP (192.168.X.Y) * Client script now asks user for a host name to reserve for this computer. User enters hostname. * Client script now writes a notification file to the nfs root, and waits. * On the server, an automated script (via crontab) runs and sees the notification file exists (no file = immediately exit) * Server script now pulls from the notification file the new PXE information, creates a symlink to "upper" or "lower" pxe file based on the 3rd octet (if 192.168.0.X address, link to upper, else link to lower). * Server script now updates the dhcpd.conf file with a new reservation for that box with the IP it was assigned, and updates the DNS zones also, then removes the notify file, restarts dhcpd/named, and exits * Client script sees notify file disappear, then reboots the computer. * Upon reboot the PXE server now delivers the contents of the "upper" or "lower" file instead of the "default" file, which contain the proper NFS root directives for the box's location. If you can think of a easier way, I'm all ears! :) --- Dan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
