Hack20.Quick and Easy DHCP Setup

Hack 20. Quick and Easy DHCP Setup

Take control of DHCP services to better integrate with other tools in your environment.

There are lots of places where clients are running Linux-based services infrastructures in SOHO environments. I do this myself at home. When you're in a smaller environment, there are lots of black-box appliances and all-in-one software packages that will take care of automatically assigning IP addresses to all the hosts on your network. Some will even let your DNS server know about dynamically assigned addresses, which is great. However, as the environment grows and more services and machines are added, this can get to be somewhat cumbersome.

The first time I realized that I might not want my wireless router giving out IP addresses was when I got a visit from a friend of mine who has a wireless laptop (which happened to be in his truck). While we were talking, he wanted to show me a web site, but he couldn't remember what it was called. He had it bookmarked on the laptop, so I told him to go get it, and I'd put his MAC address into my wireless router's "OK" table. Problem was, I had forgotten the password to my router. I had set it up months ago, and none of my formula-derived passwords were working. He wound up saying never mind, and I was really disappointed in that piece of my infrastructure.

After thinking more about that scenario, I realized I shouldn't even need to touch a black-box appliance to allow a guest to get an IP address in my environment. If I just ran a normal DHCP server on my Linux box, I could let the wireless router do what it's supposed to do (route wireless traffic), and leave the rest to my Linux server, which is good at doing most other things (heck, if I had wireless PCI cards, it could route the wireless traffic as well!).

Another benefit to using your own DHCP server is that you can add in DHCP options that may not be supported by the appliance. For example, my wireless router will not deliver the IP addresses of NTP servers or NIS servers to my clients, and it won't tell my PXE-booted clients a filename to go grab from a DHCP server. In fact, it doesn't even support a "next-server" directive to use for NFS kickstarts of my Red Hat machines. DHCP really can open up a lot of doors to making a SOHO environment less about maintaining technology and more about getting business done!

Of course, before I could do any of these really cool things, I had to set up my own DHCP server. I've only ever used the Internet Systems Consortium's DHCP server, which is the one that comes with just about all Linux distributions, so that's what I decided to go with. It's also the one I've maintained in much larger production environments, so I know for sure it's up to whatever task I can throw at it in a SOHO setting.

3.2.1. Installing a DHCP Server

The first step in this hack is to get the DHCP daemon, dhcpd, installed on your system. On Red Hat Enterprise Linux systems, the up2date utility can be used to install the server and any dependencies, with the following command:

 # up2date -i dhcp 

On Fedora systems, use yum to do the same thing:

 # yum install dhcp 

On Debian systems, use the apt-get utility:

 # apt-get install dhcp 

Debian stable, at the time of writing, provides a somewhat older version of the DHCP daemon, which does not contain support for dynamic DNS updates. Nor does it supply a BIND DNS server that is capable of accepting such updates. If you need this capability, it is suggested that you use the DHCP server in the unstable Debian branch or build from source.

For those building from source, you can grab a source tarball from the ISC web site at http://www.isc.org/index.pl?/sw/dhcp/. To build, the old magic three-command incantation still works:

 $ ./configure $ make # make install 

3.2.2. Configuring Simple DHCP Services

DHCP is not difficult to configure. We'll start with simple requirements, and leave more hardcore stuff to the next hack. The configuration file for this service is /etc/dhcpd.conf. The first few lines of this file set up global parameters that apply to all hosts served by this DHCP server:

 option domain-name "linuxlaboratory.org"; option subnet-mask 255.255.255.0; deny unknown-clients; option domain-name-servers 192.168.198.50; default-lease-time 600; max-lease-time 7200; 

The first line assigns a domain name to our environment, which is fairly arbitrary in a small environment that's not supporting a registered Internet domain. The subnet-mask option ensures that everyone has the same subnet mask on your network. This may not be the case at your site, in which case you can specify this parameter in different places in the config file to get the desired effect.

The deny unknown-clients option keeps the server from providing IP addresses to hosts that are not specified in the configuration file. The default, for some reason, is to allow this activity.

I have but a single host right now in my budding DMZ: my domain name server, which all of my internal hosts use. Rather than configuring its address manually on each host (and having to manually update it if a change is made), I just deliver its address to the clients via DHCP, using the domain-name-servers directive.

Finally, the lease times are set up such that the default-lease-time is 600 seconds (10 minutes) and the maximum time a host can go without renewing a lease is 7,200 seconds (2 hours).

Unlike the first section, the next section of the file is not global, but is specific to a subnet. It is befittingly called a "subnet statement," and you can have as many of these as you have subnets (or more, but hopefully you see that that would hardly make sense). Here's an entry for my internal network's subnet:

 subnet 192.168.42.0 netmask 255.255.255.0 {   range 192.168.42.85 192.168.42.99;   option broadcast-address 192.168.42.255;   option routers 192.168.42.1; }  

Every subnet statement is required to have a netmask specified, regardless of what's in the global section of the config file. Inside the braces, the first thing you see is that I've set things up so that hosts that are to receive dynamic addresses on this subnet can receive only IP node numbers between 85 and 99. This allows me to have 15 dynamically assigned hosts on my net-worka good-sized pool for now.

Next, I specify the broadcast-address for the domain, which is the address for "all hosts" on the subnet. And finally, I always specify a router for each subnet, because every subnet must have its own gateway address. I suppose I could've made this a global option in this case, since all of my internal hosts are on the same subnet, but if I then added a subnet (which I will when I break wireless hosts out to their own subnet), I'd have to make changes to different parts of the configuration instead of just adding a new subnet statement.

We're not done yet, though! You still need to tell the DHCP server about the hosts on your network. This can be a bit of drudgery, as it requires you to know or find out the MAC addresses of all the hosts on your network. When DHCP clients start up, they broadcast to request DHCP service, and you only want your DHCP server to respond to those hosts whose MAC addresses are listed in the configuration file. This beats by a mile the old default wireless gateway configuration of handing out addresses to the entire neighborhood! Here's a simple, yet fairly typical, host entry in dhcpd.conf:

 host gala {    hardware ethernet 00:30:65:0f:d8:52;    fixed-address 192.168.42.58; } 

The host gala happens to be my Apple G4. The two pieces of information I've provided are the Ethernet address of the machine and a fixed-address, which is optional but ensures that gala will always get the exact same IP address every time it renews its lease.

Why the heck would I do that? Doesn't it defeat the "Dynamic" part of DHCP? Well, in some ways, maybe it does, but there are various reasons why you might do this. First, if you don't use DNS, you're likely still using /etc/hosts to resolve other hosts on the network. It would be nice not to have to change these files on each host because a host's IP address has been changed. Forgetting to do so would be especially bad if that host was, say, the file server where all your important data lives. Likewise, if it's your desktop IP address that's changed and you don't update the hosts file, the file server won't resolve your hostname correctly and could export your data to someone else!

Even if you are running a DNS server, you still might want DHCP to assign fixed addresses. For example, you may not be able to use dynamic DNS updates for one reason or another. It also helps with troubleshooting: if a host can get different IP addresses at any given time, IP addresses that are not resolved to hostnames in your logs or tcpdump output become meaningless until and unless you track down which host had which address at the time specified in the logs.

That said, it's completely optional, and you certainly aren't forced to assign fixed addresses to your hosts. You can mix and match as wellfor example, when I add my buddy's laptop to my new DHCP configuration, I don't care what IP address he gets, because he's not going to use any of my in-house services; he's just going to have Internet access. Here's the entry for his laptop:

 host appio-wireless { hardware ethernet 00:90:4B:6D:97:59; } host appio-wired { hardware ethernet 00:90:3D:93:AD:3E; } 

Now he'll get a randomly assigned address, which of course will be from the 15-address pool specified in my earlier subnet statement. Notice that I added separate entries for his wired and wireless interfaces. You can enter as many "one-liner" entries like this as you wantthose entries represent the simplest form of "host" entry. Keep in mind one important tip, though, which is to remember not to assign fixed addresses that overlap with the pool you've configured in your subnet statement. For example, if I had configured host gala with a fixed address of 192.168.42.88, the server would fail to start at all! It's a basic, common-sense effect when you stop to think about it, but I've actually tripped up on that more than once. Save yourself!

3.2.3. Fire It Up!

Now, start up the DHCP service by running /etc/init.d/dhcp start on your Debian system, or service dhcpd start on Red Hat/Fedora machines. Once you configure your hosts to actually use DHCP instead of statically assigned addresses, restart their network services, and they should be assigned addresses from your shiny new server!

3.2.4. See Also

• "Integrate DHCP and DNS with Dynamic DNS Updates" [Hack #21]