|
Setting up a DHCP server on FreeBSD
Setting up a DHCP server for FreeBSD is pretty straightforward, though not as simple as installing a port.
If you need more assistance with the ISC DHCP client or server you should probably visit http://www.fugue.com/dhcp/lists and subscribe to one or more of the support mailing lists and post your question there. They have a lot of knowledgeable people there who are willing to help.
1. Make sure that you have BPF in your kernel
The DHCP server depends on the existence of the Berkely Packet Filter (BPF) in your kernel. If you are using the GENERIC kernel that was originally installed with FreeBSD you do not have BPF. First, visit the kernel configuration page for the basic information on how to compile a custom kernel. While you are working on the configuration file make sure that you add the option for BPF:
pseudo-device bpfilter 4
After you have recompiled the kernel and rebooted you will probably need to make your devices. As root type:
# cd /dev
# /bin/sh MAKEDEV bpf0 bpf1 bpf2 bpf3
2. Download and install the source
Normally one would do this by using the FreeBSD ports collection. This is a good general solution for adding software to any FreeBSD installation. Unfortunately, as of this writing, the dhcp2 port is "marked as broken." To get around this, I downloaded the source from the ISC and compiled it myself. Newbie that I am, I found their online instructions and documentation to be very thorough, and more than adequate for me to get a server up and running.
3. Make some links
The reason the port is "marked as broken" is because the source distribution insists on installing the binary and config files in the "wrong" places. The Makefile puts the config file, dhcpd.conf, in /etc, whereas FreeBSD would like it to be in /usr/local/etc. Similarly, the binary ends up in /usr/sbin when it "should" be in /usr/local/sbin. Here's how to fix it, after installing per the ISC instructions. Note that you should be root when doing this.
a) Move dhcpd.conf to the place where FreeBSD wants it, then make a link in /etc:
# mv /etc/dhcpd.conf /usr/local/etc/dhcpd.conf
# ln -s /usr/local/etc/dhcpd.conf /etc/dhcpd.conf
b) Treat the binary in a similar fashion:
# mv /usr/sbin/dhcpd /usr/local/sbin/dhcpd
# ln -s /usr/local/sbin/dhcpd /usr/sbin/dhcpd
4. Configure the server
Now that it's installed, you must set up the configuration file. You should find it in /usr/local/etc, or you can go to /etc and use the link you just made. The source comes with a sample config file which can be edited to suit your needs. Here is my config file for home, verbatim:
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
# Modified for home NATnet - jch - 29 July 1999
#
# option definitions common to all supported networks...
option domain-name "gueuze.dgsys.com";
option domain-name-servers ns1.dgsys.com, ns2.dgsys.com;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.0.0 netmask 255.255.0.0 {
range 192.168.0.100 192.168.0.115;
option routers gueuze.dgsys.com;
option domain-name-servers gueuze.dgsys.com, ns1.dgsys.com,
}
The config file above represents a somewhat special case; as implied by the comments, I am running an RFC1918 network at home. In my case this means that all my internal machines have IP addresses in the 192.168.x.x space, and that is where I'm distributing IPs. I'm running the Network Address Translation daemon to make this happen, but that's beyond the scope of this article.
If you have a legitimate block of routable addresses, it's simple enough to find a range that your server may hand out to clients. I have also set up DHCP at my office - where we do have a real Class C - using ''real'' IP addresses, and it has worked just fine. Here is the config file that I use at work:
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
# Modified/butchered by jch for RGB Technology, Inc. 29 July 1999
#
# option definitions common to all supported networks...
option domain-name "rgbtec.com";
option domain-name-servers 206.43.192.76, 206.197.81.10, 206.197.81.11;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;
subnet 206.43.205.0 netmask 255.255.255.0 {
range 206.43.205.220 206.43.205.235;
option routers 206.43.205.2;
}
Your configuration should be determined by your local needs of course. Your ISP should be able to give you the information you need. If you already have networking up and running, you should have all the info already. The options I have in the config files are pretty much normal and required. A great deal of additional information is available from man dhcpd and man dhcpd.conf.
5. Test it
Now that you think you have it configured properly, let's try it out. As root, type
# cd /usr/local/sbin
# ./dhcpd
...and the daemon starts up, printing several lines of text on your screen. To test functionality, I use a second computer which is configured to look for a DHCP server. For the test clients, I've always used a "consumer" OS. Here's a brief overview of how to configure them:
MacOS 8.x: Control Panels -> TCP/IP -> Configure: Using DHCP Server
Windows 9x: Control Panel -> Network -> TCP/IP -> IP address -> "Obtain an IP address automatically."
After configuring your test client, shut it down. Then connect it to the ethernet, boot it up, and attempt to do something TCP/IP related - surf the net, telnet somewhere, or just ping microsoft.com :-) If you are able to get out to the world, your DHCP server works.
6. Make a startup script
To make the daemon start automagically upon system boot-up, you'll need to add a startup file. I call mine dhcpd.sh, and it lives in usr/local/etc/rc.d. Here is my startup script file in its entirety:
# Home brewed script to start the dhcp daemon
/usr/sbin/dhcpd -q
echo -n ' dhcpd'
Note that I have used the -q command line option in the script. This starts dhcpd in "quiet" mode, which simply means that it won't echo all that stuff when it starts. This is not strictly necessary, just an aesthetic consideration.
The best way to make sure the startup script runs properly is to reboot the FreeBSD machine on which it is running. I realize this is not always an option, but if you can stand a few minutes of downtime, go for it. Whether or not it's feasible to reboot, you need to make sure the script has the right permissions. It should be world-readable and -executable. To make it so, go to the directory where the script resides and, as root, type
# chmod 555 dhcpd.sh
# ls -l | grep dhcp
...and you should see
-r-xr-xr-x 1 (owner) (group) (size) (date time) dhcpd.sh
Given that, it should run OK at boot time.
7. Just one more thing...
One potential problem I have heard of, but not (yet) encountered, is that Win95 clients have a habit of not relinquishing their assigned IPs when the lease expires. If this becomes a problem, I would probably write a script - to be invoked by cron - which would periodically blow away, then touch, the /var/db/dhcpd.leases file. The touch is necessary, because the dhcpd.leases file needs to exist in order for the daemon to work properly.
So far this has not been an issue, so I haven't written the script yet.
|
|
