reading IP addresses given via DHCP
ddavidegli at gmail.com
Fri Sep 27 05:39:57 MDT 2013
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
As to the rest, that's already in place. Here's the logic I have
* New workstation A boots into the network for the first time (diskless PXE
* 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! :)
More information about the PLUG