DHCP Help Again
Robert Konecny
rok at ucsd.edu
Thu Apr 11 11:31:23 PDT 2002
that's pretty much how insert-ethers from Rocks clustering software works
(rocks.npaci.edu). You fire it up on frontend and it starts parsing
/var/log/messages in real time. Then you kick start a node and when
insert-ethers sees a request for a lease with unknown MAC it updates
Rocks MySQL database, generates new dhcpd.conf and restarts dhcpd. Works
like charm.
robert
On Thu, Apr 11, 2002 at 01:17:51PM -0400, Robert G. Brown wrote:
>
> 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
>
>
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
More information about the Beowulf
mailing list