DHCP Help Again
Robert G. Brown
rgb at phy.duke.edu
Thu Apr 11 10:17:51 PDT 2002
On Wed, 10 Apr 2002 tegner at nada.kth.se wrote:
> 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?
Not that I know of. Maybe somebody else knows of one. I'd just use
perl or bash (either would probably work, although parsing is generally
easier in perl), parse e.g.
Apr 11 08:18:09 lucifer dhcpd: DHCPREQUEST for 192.168.1.140 from 00:20:e0:6d:a0:05 via eth0
Apr 11 08:18:09 lucifer dhcpd: DHCPACK on 192.168.1.140 to 00:20:e0:6d:a0:05 via eth0
from /var/log/messages on the dhcp server, and write an output routine
to generate
# golem (Linux/Windows laptop lilith, second/100BT interface)
host golem {
hardware ethernet 00:20:e0:6d:a0:05;
fixed-address 192.168.1.140;
next-server 192.168.1.131;
option routers 192.168.1.1;
option domain-name "rgb.private.net";
option host-name "golem";
}
and
192.168.1.140 golem.rgb.private.net golem
and append them to /etc/dhcpd.conf and /etc/hosts respectively, and then
distribute copies of the resulting /etc/hosts -- as Josip made
eloquently clear your private internal network should resolve
consistently on all PIN hosts and probably should have SOME sort of
domainname defined so that software the might include a
getdomainbyname() call and might not include an adequate check and
handle of a null value can cope. It's hard to know what assumptions
were made by the designer of every single piece of network software you
might want to run...
Of coures you'll probably want to do the b01, b02, b03... hostname
iteration -- I'm just pulling an example at random out of my own log
tables.
rgb
>
> 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
> >
> >
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
More information about the Beowulf
mailing list