DHCP, DHCP, DHCP everywhere!

Most everyone is used to using DHCP. It’s used at coffee shops and wireless networks to acquaint traveling laptops with their DNS and router settings as well as, of course, to provide the machines an IP address too. However, corporate and enterprise use of DHCP is often reasonable too. One can use dynamic DNS updates to handle having a static reference for a machine traveling on various networks. When network migrations are necessary (i.e. say your Fortune 500 gets bought by another) and you need to move thousands of machines, it’s much easier to simply tell your DHCP server to migrate the machines than have to log on to each and every machine and change network settings.

How does DHCP apply to the OpenSolaris Automated Installer?

The OpenSolaris Auto Installer uses DHCP to allow administrators to perform hands-off installations. The Auto Installer client (machine to be installed) receives its IP address, subnet mask, router, DNS server and boot image all though DHCP. The installadm(1M) tool which one uses to configure an Auto Installer server provides the commands for a Solaris DHCP server but below are the steps for an ISC DHCP server as is common on Linux and even Solaris shops which are simply more comfortable with ISC’s DHCP implementation.

Where to get ISC DHCP for Solaris?

Software from ISC is usually very stable and well maintained to be easy to compile. However, Solaris seems to have changed a bit from the expectations of ISC DHCP. In my testing, on build 132, I found that ISC DHCP 4.0.0 from Sun Freeware, the ISC DHCP 4.1.0 from pkg.opensolaris.org/contrib and the ISC DHCP 4.1.1 off ISC’s download page would all not respond to DHCPDISCOVER’s on the wire (but it would report a DHCPOFFER in the logs still just to confuse things). I suspect a compilation issue I saw while compiling 4.1.1 (but I have no actual knowledge why responses are not getting on the wire):

ld: warning: symbol `MD5_version' has differing sizes:
(file ../dst/libdst.a(md5_dgst.o) value=0x4; file /lib/libcrypto.so valu
e=0x76);
../dst/libdst.a(md5_dgst.o) definition taken

However, ISC’s 4.2.0a1 worked flawlessly! You can get their 4.2.0 alpha from their download page and easily compile it with pfexec pkg install SUNWhea SUNWgcc; ./configure; make; make install.

Great, I have ISC DHCP compiled and installed, but how do I Configure this thing?

Normally the issue is not installation and compilation but configuration. For the OpenSolaris Auto Installer there are a number of things to think about:

• IP addresses
• Subnet mask
• Router address
• DNS server and search domain
• Boot server
• Boot file
• The Auto Installer client’s architecture

Networking primitives (IP address, subnet, router, DNS)

Without some vital information, even fully functional networks seem useless. The use of an IP address, the subnet mask for the network and a router to get off the network all fit this bill. For most intents and purposes DNS is also in this same boat — though some administrators may not find DNS as necessary. To get ISC DHCP to serve these pieces of information require certain directives.

A basic network

In one’s dhcpd.conf a basic network is very easy to define, it looks like the following, here defining for the 192.168.0.0/24 network to serve out IP addresses between 2-100 and with a router of 192.168.0.1:

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.2 192.168.0.100;
option routers 192.168.0.1;
}

DNS

To add DNS information to one’s dhcpd.conf is similarly easy. If one wants each subnet served to get different DNS info one may put the lines in the subnet block or else the directives can go at the beginning of the file and apply to all subnets served:

option domain-name "example.com";
option domain-name-servers 192.168.0.1;

Boot server and boot file

Now, for the Auto Installer specific pieces: to boot a machine, one needs a machine to download a boot file from and the name of such a boot file. These pieces of information will be given by the installadm create-service [...] command when setting up a Auto Installer service. For example:

Boot server IP (BootSrvA) : 192.168.0.1
Boot file      (BootFile) : install_test_ai_x86
GRUB Menu      (GrubMenu) : menu.lst.install_test_ai_x86

The boot server in ISC DHCP terms is the next-sever directive and the boot file is the filename directive. To make it simple, just add these to your subnet group:

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.2 192.168.0.100;
option routers 192.168.0.1;
filename "install_test_ai_x86";
next-server 192.168.0.1;
}

If you’re using a SPARC Auto Installer service, you can use the same directives for the BootFile object. What about the GrubMenu entry you ask? Well, that’s unnecessary and will be removed (see bug 7481) so do not worry about it; similarly, SPARC does not need a next-server (BootSvrA) directive.

What if you have both SPARC and X86 architectures?

If you have both SPARC and X86 machines in your Auto Installer environment then there are are some simple ways to define classes to provide your SPARC machines their correct boot-file and X86 machines their boot-file and boot-server. This allows one to have a default service for each architecture on the network.

A PXE boot class?

If you want a specific way to separate out your SPARC and X86 clients, then one uses ISC DHCP’s class directive and applies all boot specific information there. To create a class for X86 hardware booting, then you can use the following class definition:

class "PXEBoot" {
option dhcp-class-identifier "PXEClient";
filename "install_test_ai_x86";
next-server 192.168.0.1;
}

SPARC class

To define a class to match SPARC clients, one uses ISC DHCP’s class directive and applies all boot specific information there. Note, you do not need a next-server directive for SPARC:

class "SPARC" {
match if ( substring (option vendor-class-identifier, 0, 5) = "SUNW." ) and not
( option vendor-class-identifier = "SUNW.i86pc" );
filename "http://192.168.0.1:5555/cgi-bin/wanboot-cgi";
}

Now, SPARC clients will request a lease and get SPARC specific information, while X86 clients will request and get information specific to an X86.

The entire dhcpd.conf looks like:

# option definitions common to all supported networks...
option domain-name "example.com";
option domain-name-servers 192.168.0.1;
default-lease-time 600;
max-lease-time 7200;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
# This is an easy way to discriminate on SPARC clients
class "SPARC" {
match if ( substring (option vendor-class-identifier, 0, 5) = "SUNW." ) and not
( option vendor-class-identifier = "SUNW.i86pc" );
filename "http://192.168.0.1:5555/cgi-bin/wanboot-cgi";
}
# This is a class to discriminate on PXE booting X86 clients
class "PXEBoot" {
option dhcp-class-identifier "PXEClient";
filename "install_test_ai_x86";
next-server 192.168.0.1;
}
# This is a very basic subnet declaration
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.8.2 192.168.0.100;
option routers 192.168.0.1;
}