DHCP Help Again

[Robert G. Brown]

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

> Quoting "Robert G. Brown" <rgb at phy.duke.edu>:
> Is there a convenient way to obtain static ip-addresses using dhcp without
> having to explicitly write down the mac-addresses in dhcpd.conf?
> 
> Regards,
> 
> /jon

Static?  As in each machine gets a single IP number that remains its own
"forever" through all reboots and which can be identified by a fixed
name in host tables?

Following the time-honored tradition of actually reading the man pages
for dhcpd, we see that the answer is "sort of".  As in in principle yes,
but only in a wierd way and would you really want to?

First of all, let us consider, how COULD it do this?  All dhcp knows of
a host is its mac address.  System needs IP number.  System broadcasts a
DHCP request.  What can the daemon do?

It can assign the address out of a range without looking at the MAC
address (beyond ensuring that isn't one that it recognizes already) or
it can look at the MAC address, do a table lookup and find it in the
table, and assign an IP address based on the table that maps MAC->IP.
This is pretty much what actually happens, and of course the lookup
table CAN ensure a static MAC->IP matchup.

The only question is how the lookup table is constructed.

The obvious way is by making explict per-host entries in the dhcpd.conf
file.  dhcpd reads the file and builds the table from what it finds
there.  You make the dhcpd.conf entries by hand or automagically by
means of a clever script.  In general this isn't a real problem.  You
have to make a per-host entry into e.g. /etc/hosts as well, or you won't
know the NAME the host is going to have to correspond to the IP number
the daemon happened to give it the first time it saw it.  The same
script can do both, given e.g. the MAC address and hostname you wish to
assign as arguments.

Now there is nothing to PREVENT the daemon from assigning IP numbers out
of the free range, creating a MAC->IP mapping, and saving the mapping
itself so that it is automagically reloaded after, say, a crash (which
tends to wipe out the table it builds in memory.  By strange chance,
this is pretty much exactly what dhcpd does.  It views IP's assigned out
of a given subnet range as "leases", to be given to hosts for a certain
amount of time and then recovered for reuse.  It saves its current lease
table in /var/lib/dhcp/dhcpd.leases.  Periodically it goes through this
table and "grooms" it, cleaning out expired leases so the IP numbers are
reused.  In many/most cases where range addresses are used, this is just
fine.  Remember, dhcp was "invented" at least in part to simplify
address assignment to rooms full of PC's running WinXX, a well-known
stupid operating system that wouldn't know what to do with a remote
login attempt if it saw one.  Heck, it doesn't know what to do with a
LOCAL login a lot of the time.  The IP<->name map is pretty unimportant
in this case, because you tend never to address the system by its
internet name.  So it's no big deal to let IP addresses for dumb WinXX
clients recycle.

Of course this isn't always true even for WinXX, especially if XX is 2K
or XP or NT.  Sometimes systems people really like to know that log
traces by IP number can be mapped into specific machines just so they
can go around with a sucker rod (see "man syslogd" and do a search on
"sucker") to administer correction, for example, even if they cannot
remotely login to the host in question.

dhcpd allows you to pretty much totally control the lease time used for
any given subnet or range.  You can set it from very short to "very
large", probably 4 billion or so seconds, which is (practically)
"infinity".  Infinity would be your coveted static IP address
assignment.

Once again I'd argue that although you CAN do this, you probably don't
want to in just about any unixoid context including LAN management and
cluster engineering.  There is something so satisfying, so USEFUL, about
the hostname<->IP map, and in order for this map to correspond to some
SPECIFIC box, you really are building the hostname<->IP<->MAC map,
piecewise.  And of course you need to leave the NIC's in the boxes,
since yes the map follows the NIC and not the actual box.  Although it
likely isn't the "only" way to control the complete chain,
simultaneously and explicity building /etc/hosts (or the NIS, LDAP,
rsync exported versions thereof), the various hostname-related
permissions (e.g. netgroups) and /etc/dhpcd.conf static entries is
arguably the best way.

To emphasize this last point, note that there is additional information
that can be specified in the dhcp static table entries, such as the name
of a per-host kickstart file to be used in installing it and more.  dhcp
is at least an approximation to a centralized configuration data server
and can perform lots of useful services in this arena, not just handing
out IP addresses.  Unfortunately (perhaps? as far as I know?) dhcp's
options can only be passed from it's own internal list, so one can't
QUITE use it as a way of globally synchronizing whole tables of
important data (like /etc/hosts,netgroups,passwd) across a subnet as
systems automatically and periodically renew their leases.  The list of
options it supports as it stands now is quite large, though.

I also don't know how susceptible it is to spoofing -- one problem with
daemon-based services like this is that if they aren't uniquely bound at
both ends to an authorized server and somebody puts a faster server on
the same physical network, one can sometimes do something like
dynamically change a systems "identity" in real time and gain access
privileges you otherwise might not have had.  Obviously, sending files
like /etc/passwd around in this way would be a very dangerous thing to
do unless the daemon were re-engineered to use something like ssl to
simultaneously certify the server and encrypt the traffic.

Hope this helps.  BTW, in addition to the always useful man pages for
dhcpd and dhcpd.conf (e.g.) you can and should look at the linux
documentation project site and the various RFCs that specify dhcp's
behavior and option spread.

   rgb