may2004.tar

Migrating to DHCP Jumpstart

Ralf van Dooren

With the introduction of Jumpstart technology, the automated installation of Solaris OE over a network became fairly easy. However, for a successful install, a boot server was required in every network segment. Since Sun Microsystems made it possible to provide the necessary information by DHCP, the elimination of a boot server in each segment has become reality.

This article describes a way to migrate a conventional Jumpstart environment to a DHCP Jumpstart environment. Although this migration may not seem too difficult, there are a few caveats worth mentioning.

The environment I was asked to migrate had some requirements, as follows:

RARP and DHCP Jumpstart service must co-exist on the same server.
We must be able to jumpstart different versions of Solaris. (The product developed by the company needs to run on several flavors of Solaris; therefore, employees frequently reinstall their workstations with another flavor.)
The new procedure must involve minimal change of working procedures for helpdesk and customers.

In this article, I'll demonstrate ways of meeting these three requirements. You can adopt them as needed.

My client didn't advocate the change to DHCP Jumpstart; they were happy with the RARP Jumpstart environment. However, a change was necessary because the network was changing, and one of the consequences was that no servers could be active on a workstation's network segment. A RARP Jumpstart environment needs a boot server in each network segment. However, it is possible to configure network devices to allow DHCP packets cross network boundaries and thereby reduce the number of servers required (see the sidebar, "Why DHCP?"). Thus, I chose DHCP Jumpstart as the solution.

DHCP Jumpstart has been a feature of the OpenBootProm (OBP) since version 3.25. To implement this solution, you must make sure all workstations have that version. You can check this with the prtconf -V command. If not, upgrade the OBP with the appropriate patch.

Some changes are necessary to the Jumpstart server. The sysidcfg file for a DHCP jumpstarted client is different, and you might need to change some scripting in the "finish" script, to make the client run DHCP upon booting after installation.

I use this sysidcfg file for Solaris 8:

system_locale=en_US
security_policy=NONE
network_interface=primary {dhcp protocol_ipv6=no}
name_service=NIS {domain_name=NIS-domain name_server=nis-server(10.8.9.1)}
terminal=sun-cmd

This configuration differs from the RARP sysidcfg file. As the installation parameters only provide the directory where sysidcfg can be found for that specific installation, put the DHCP sysidcfg file in a separate directory on your boot server and define this directory in SUNW.sysid-config-file-server in dhcpd.conf (more on this later). Then, go through your "finish" script to check for items to be changed. If you are already using DHCP during normal boot, changes are probably not necessary.

The next step is to give the DHCP server the correct information for Jumpstart. I used the ISC DHCP server for my proof of concept and will use its configuration as a guideline in this article. However, if your DHCP server can define "vendor-specific options" (Option 43, see RFC2132 for further details), you should be fine with your choice of DHCP software. In the pilot phase and production, I used a commercially available DHCP server.

We must define the Jumpstart options. Add the following to your dhcpd.conf:

option space SUNW;
option SUNW.JumpStart-server code 14 = text;
option SUNW.boot-file-path code 7 = text;
option SUNW.boot-read-size code 9 = unsigned integer 16;
option SUNW.install-path code 12 = text;
option SUNW.install-server-hostname code 11 = text;
option SUNW.install-server-ip-address code 10 = ip-address;
option SUNW.posix-timezone-string code 8 = text;
option SUNW.root-mount-options code 1 = text;
option SUNW.root-path-name code 4 = text;
option SUNW.root-server-hostname code 3 = text;
option SUNW.root-server-ip-address code 2 = ip-address;
option SUNW.swap-file-path code 6 = text;
option SUNW.swap-server-ip-address code 5 = ip-address;
option SUNW.sysid-config-file-server code 13 = text;
option SUNW.terminal-name code 15 = text;

Although not all options will be used with the Jumpstart process, it is best to define the whole set of options.

Note that Sun workstations ask for the boot image by submitting their vendor identification (the one you would see when you issue the command uname -i). In this case (where we need workstations to be able to jumpstart different Solaris releases), this isn't very helpful. For example, if we have two Ultra-1 workstations, we cannot uniquely identify them by their vendor identification, so they will request the same image.

The solution is to let the DHCP server push this information to the workstation. The unique identifier is the MAC address of the workstation. The easiest way to configure this is to create classes and subclasses. For each type of Jumpstart installation, define a class in the dhcpd.conf. For example:

class "jumpstart-solaris-8" {
    match pick-first-value (option dhcp-client-identifier, hardware);
        filename "inetboot.SUN4U.Solaris_2.8-1";
        server-name "tftp-server";
        vendor-option-space SUNW;
        option SUNW.install-server-hostname "install-server";
        option SUNW.install-server-ip-address 10.1.2.3;
        option SUNW.install-path "/jumpstart/install/Solaris_8_hw02.02";
        option SUNW.root-server-hostname "root-server";
        option SUNW.root-server-ip-address 10.4.5.6;
        option SUNW.root-path-name
          "/export/install/Solaris_8_hw02.02/Solaris_8/Tools/Boot";
        option SUNW.sysid-config-file-server
        "install-server:/jumpstart/Customize.8_DHCP";
        option SUNW.JumpStart-server "install-server:/jumpstart/Profiles";
}

class "jumpstart-solaris-9" {
    match pick-first-value (option dhcp-client-identifier, hardware);
    << same options as in 8, only then with the Solaris 9 information >>
}

subclass "jumpstart-solaris-9" <mac-address-1>;
subclass "jumpstart-solaris-8" <mac-address-2>;
subclass "jumpstart-solaris-8" <mac-address-3>;
etc.

This makes maintenance easy. You can just change the subclass for a specific MAC address and let dhcpd re-read its config file. Of course, you can do this by a script and incorporate it into your current procedures. Be sure to let dhcpd re-read its config file, which can be done with kill -HUP <pid>.

You can use your existing bootparams file to fill the classes-configuration in the dhcpd.conf. The only difference is the SUNW.sysid-config-file-server as explained above; it needs a different sysidcfg located in a separate directory.

A DHCP Jumpstart can then be started from the OK prompt with the command boot net:dhcp - w install. The w flag suppresses a graphical installation. The workstation requests information via DHCP; it requests the bootfile from the tftp server and starts the installation. If everything goes as planned, installation should be automatic. If the installation goes into interactive mode, check your sysidcfg file; it probably contains an error. At this point, you'll have a working DHCP Jumpstart environment happily co-existing with the current RARP Jumpstart.

Fine-Tuning Your Setup

Once your DHCP Jumpstart environment works, you can fine-tune the configuration. As stated previously, you can make a script that the helpdesk can use to assign a MAC address to a different subclass. Remember to restart the DHCP daemon to make the configuration changes active and check whether restarting was successful. I leave this script as an exercise for the reader. I incorporated this script into the existing tool available for RARP Jumpstart. This way, the helpdesk doesn't need to know if the client is DHCP jumpstarted or not.

It's also a good idea to make this change transparent for users. Normally, a user could type boot net - w install to get a client jumpstarted. With DHCP, this would be boot net:dhcp - w install. You can include the following shell script in your finish script:

#!/bin/sh
IFACE='/sbin/ifconfig -a | grep "flags" | awk -F":" ' { print $1 }' | grep -v
+"lo"'

STIF='echo ${IFACE} | sed -e 's/0$//g''

SBUS='grep "\"${STIF}\"" /etc/path_to_inst | awk -F"\"" ' { print $2 }' '

/usr/sbin/eeprom "nvramrc=devalias net ${SBUS}:dhcp"
/usr/sbin/eeprom "use-nvramrc?=true"

This script will determine the interface (hme0, le0, etc.) and the path to that interface. It then uses that path to contsruct a new "net" alias and sets use-nvramrc?=true to let OBP use this alias. Then, when a user does boot net - w install, OBP will use DHCP to retrieve the information. If a user moves back to a RARP environment, just set use-nvramrc? to "false".

Note that if you are trying this setup with Solaris 2.6, the procedure described here will work only partially. The system's mini-kernel (inetboot-file) doesn't use DHCP to determine the installation parameters needed for the rest of the Jumpstart process. So, in addition to the Jumpstart information via DHCP, you need to keep Solaris 2.6 install parameters for this client in the /etc/bootparams or bootparams NIS table. You can enter the Solaris 2.6 parameters for every client in the bootparams file. If a client is jumpstarted for versions that use DHCP for its installation parameters, the bootparams file will not be used and thus will not interfere.

The client for whom I implemented this setup now uses RARP and DHCP Jumpstart in the same campus environment. This allows them to migrate to DHCP at their choice of time, without blocking the business process (testing applications on different Solaris releases). Because their boot server no longer needs to be present in every network segment, this solution is far more scalable than the old RARP Jumpstart environment. Also, implementing DHCP Jumpstart as described here didn't change procedures for helpdesk and employees.

Ralf van Dooren works as a consultant for Snow (http://snow.nl), a leading Unix consultancy company based in the Netherlands. He holds various certifications for Unix (SCSA, LPIC2) and networking (CCNP) and is challenged by clients to find the right answer (42) for their problems. He can be reached at: r.vdooren@snow.nl.