DHCP Help Again

[tegner at nada.kth.se]

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?

Thanks again,

/jon

Quoting "Robert G. Brown" <rgb at phy.duke.edu>:

> 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
> 
>