apr2005.tar

Portable Jumpstart Environment

Michael R. Sbailo Jr.

Automating system builds has greatly increased systems administrators' ability to build and recover environments in a more uniform manner. Each platform has its own method of accomplishing this, such as Jumpstart (Solaris), Autoyast (SUSE), Kickstart (Red Hat), etc. In this article, I'll focus on running Solaris's Jumpstart technology from a Linux-based laptop. Because of the need to support sites in the field that are scaled down and thus cannot support a full-blown boot environment, I wanted to combine all the components of Jumpstart into one.

These components are the profile server, boot server, and install server. Once I combined these components, the next step was to make it all portable. That's where the laptop comes in. I chose Linux mainly because of how easy it is to install on almost any type of hardware. The other reason for going with Linux is because of the increase of use in the workplace. Environments are becoming more heterogeneous with a mixture of different operating systems and hardware. Also, by using Linux, I can take advantage of the distribution's method of automating system builds as well as Jumpstart. So, now I have a "portable" boot/build environment with the capability to build both Solaris and Linux machines from a single source.

Overview

The basic requirements to get this configuration working are fairly simple, with the most important component being DHCP. By using DHCP, you also decrease the number of files that must be configured. The Jumpstart functions of the /etc/hosts, /etc/ethers, and /etc/bootparams files will now be executed by the DHCP service. Additionally, the contents of the /tftpboot directory no longer needs a hex interpretation of your client's IP linked to the appropriate inetboot file within that directory.

To begin the Jumpstart process via DHCP, your client must make the request using DHCP instead of BOOTP. You do this from the OK prompt by typing the command boot net:dhcp - install as opposed to the usual boot net - install. Note that to use DHCP, the OpenBootProm level of your client must be at least version 3.25.

Once the request is received by DHCP from your client, the server assigns an IP address and passes all other information needed to continue the process. This includes the client's hostname, the inetboot file, and the root path from which to boot. Information defining the TFTP, Install, Root, Sysidcfg, and Jumpstart servers is transmitted through the DHCP service as well.

Assuming your network incorporates the use of IP helper addresses or DHCP request forwarding on its switches, these installations can be performed across subnets. The traditional BOOTP Jumpstart environment needs at least one boot server per subnet to function.

Also, with straight BOOTP you would need to alter the actual Jumpstart scripts to get this setup to work from an Intel/Linux platform. Figure 1 shows how this configuration can simplify the environment. It decreases not only the amount of hardware needed but the number of files and services as well.

Hardware and Software Requirements

Let's start with hardware. Your main concern will probably be space, and you'll need anywhere from 1 to 2 GB of space for each release of software you want to be able to build. For example, if you need to accommodate an environment running Solaris 7, 8, and 9, you'll most likely need at least 6 GB of space for all the releases. The memory and CPU requirements may vary depending on your distribution. I used a fairly powerful laptop for my setup, because one just happened to be available. As I previously stated, the main issue will be space because the primary function of the laptop will be the DHCP, TFTP, and NFS services. The distribution should not matter, but I built everything on Novell's SUSE 9.2.

Disk Layout and Copying Software

Something to consider as you build your laptop is to set aside a partition for all of the build software and configuration files that are required for Jumpstart to work. This includes all configuration files for the needed services, which are DHCP, NFS, and TFTP. You don't need a separate partition for this to work, but it may save you time later if you ever need to re-install or upgrade the operating system on the laptop. Once that is done, you'll want to break out the directory structure under your new file system so it makes sense to you; here is an example of what I did.

Because /home is its own partition on my laptop, I just used that as a starting point:

mkdir -p /home/BUILD/SOLARIS

Then under /home/BUILD/SOLARIS, I broke out all of the functions of the Jumpstart environment:

mkdir -p /home/BUILD/SOLARIS/jumpstart

The "jumpstart" directory is where you'll define your rules file and any profile types you may have. This essentially takes on the "Profile" server function of Jumpstart.

Next, you'll need an "install" directory where you'll copy all of the software for your release. This will double as both the "Install" server portion as well as the "Boot" server portion. This is because it contains not only all of the Solaris packages that can be loaded but also the Boot directory containing the scripts necessary to perform a Jumpstart install:

mkdir -p /home/BUILD/SOLARIS/install

A "flash" directory is only needed if you utilize the flash archive component of Jumpstart, and this is basically where you store your flash archives:

mkdir -p /home/BUILD/SOLARIS/flash

"Check" Script Issues

I had some problems executing the Solaris shell script "check" on Linux. This script is responsible for creating the "rules.ok" file by validating the "rules" file under your Jumpstart directory. This file is needed for the Jumpstart process to complete. It appears there are some shell built-in differences between the two operating systems. These differences resulted in unexpected errors while performing certain functions within the script and caused the script to fail without creating the "rules.ok" file.

To resolve this problem, you'll need to make a few changes to the "check" script and install an additional package. The package you need to install is pdksh (Public Domain Korn Shell). This will get you closer to how the shell would behave on a Solaris machine. This shell still has differences from the Solaris version of ksh, so not all functions will work. However, the specific functions needed for this configuration will work. Once you have installed pdksh and updated your /etc/shells file, you can make the changes to the "check" script.

At the very top of "check", substitute the "#!/bin/sh" with the path to pdksh "#!/usr/bin/pdksh". The "check" script itself makes a call to another program called "chkprobe". This program lives under /usr/sbin/install.d on a standard Sun machine. However, since you're running this script from a Linux machine, you need to tell it where to look. To achieve this, you can add the following line to the top of "check":

CDIMG=/home/BUILD/SOLARIS/install/Solaris_2.9-0404/Solaris_9/ \
  Tools/Boot

From there, you will need to prefix that variable to all references for "chkprobe". Here's an example:

CHECK_PROBE=${CDIMG}/usr/sbin/install.d/chkprobe

The last change involves a global search and replace of the egrep -s command to egrep -q. Again, this is done because of differences between the two platforms. The Solaris implementation of "egrep" uses different options from the GNU version. However, by changing the flag from "s" to "q" you achieve the same result. Once you've made these changes and additions, the "check" script will work as expected. If you don't want to go through these steps, you can copy your existing "rules" file to "rules.ok" manually as long as it contains valid syntax and accepted rules. See the Solaris documentation for Jumpstart for valid rules and options.

Installing the Solaris Software

Once you have the disk layout the way you want, you will need to copy the Solaris software to the laptop. The problem with copying this data in the traditional way according to Sun's directions is that the Solaris CDs have multiple slices and are not all iso9660 type file systems. This means when your Linux laptop attempts to automount the CD-ROM, it may only recognize slice 0 on it.

Once slice 0 is mounted, you will notice that some of the directories and files exist on slice 0, while others are symbolic links to data on other slices of the CD. So, when Sun's setup_install_server script is invoked, it attempts (and fails) to copy data that resides on unmounted slices of the CD. Note that I have read that people have been able to mount the other UFS slices to their Linux machines, but I was unable to do so. This may be because the file system type is not recognized or supported by my operating system.

One solution is to use a Sun machine to do the software install onto the laptop. On the Solaris machine, mount the Solaris CD from the system's CD-ROM device, and mount the installation directory on your Linux laptop via NFS. Then you can use the normal setup_install_server script after making a slight modification. This script expects that the destination directory to which it copies will be a local file system. This is so it can export the file system for you automatically. Commenting out the below "if" statement in the script will prohibit this check:

# if [ ! -b ${dfout} ] ; then
#   echo "ERROR: ${dfout} is not a local file system, cannot export $
#   1 for install clients"
#   cleanup_and_exit 1
# fi

Once this is done, you can proceed with the copy of the CD image by running the modified script with the following flags:

setup_install_server-modified -p /mnt/cdrom/s0/Solaris_9/Tools \
  /mnt2/Linux

Here "/mnt2/Linux" is the NFS mount-point of the installation directory from the laptop.

In my case, I had a pre-existing Jumpstart environment on a Sun machine, so I could NFS-mount each component from the Solaris box to my Linux machine and copy the data to its associated place in the following way:

mount "jump-server":/jumpstart /mnt
cd /mnt
find . -depth -print | cpio -pdumv /home/BUILD/SOLARIS/jumpstart

mount "install-server":/Solaris_2.9-0404 /mnt2
cd /mnt2
find . -depth -print | cpio -pdumv /home/BUILD/SOLARIS/install

mount "flash-server":/flash-archives /mnt3
cd /mnt3
find . -depth -print | cpio -pdumv /home/BUILD/SOLARIS/flash

Depending on your current setup, the servers technically can all be the same machine. You don't need to copy anything from the boot server because the data there is really a subset of the data from the install server. The data copied to a boot server when using the setup_install_server -b option is just the information needed to boot a client and allow it to mount the rest of the software that it needs from the install server. It is essentially the boot directory that resides in the following path on the CD:

CD:/Solaris_9/Tools/Boot

TFTP

You will need TFTP available so the client can download the kernel and mini-root to start the build process. The process of enabling this service may vary depending on your distribution. In SUSE 9.2, I had to enable it under /etc/xinetd.d/tftp first and then create the /tftpboot directory. After this, you will need to copy the inetboot file for each release of Solaris software you want to load, this is the mini-kernel that will be downloaded to your client. Here is where to find it:

cd /home/BUILD/SOLARIS/install/Solaris_2.9-0404/Solaris_9/Tools/ \
   Boot/usr/platform/'uname -m'/lib/fs/nfs
cp inetboot /tftpboot/inetboot.Solaris_2.9

It's a good idea to name the inetboot file the same as the release, because the files do vary, just as the complete kernel varies between releases.

NFS

The next service you need to configure is NFS. Again, the syntax used is slightly different from Solaris. There are a few more options you'll need to add for dealing with root permissions and file access over NFS. Here is the /etc/exports file that I used:

/home/BUILD/SOLARIS *(ro,anonuid=0,anongid=0)

The one entry will allow you to mount everything necessary to perform an install with read-only permissions. This includes everything under the install, jumpstart, and flash directories. It will also set the anonymous uid and gid to 0 instead of the 65534 "nobody" uid/gid, which can cause problems with file access. You also get the flexibility to add new releases under "/home/BUILD/SOLARIS/install" without having to adjust the exports file.

DHCP

The /etc/dhcpd.conf file is where you'll specify all the parameters that would otherwise be defined in the /etc/bootparams, /etc/hosts, and /etc/ethers files. Things like the TFTP server, root server, boot file, and install path are all defined here. Because DHCP is a superset of BOOTP, it has the functionality to accept options outside the scope of BOOTP. As you can see in the example, there are even vendor-specific options that may need to be defined before the OS will install properly on specific hardware, such as Sun Workstations. Below is the dhcpd.conf file I used in my proof of concept, most of which I found in the "Migrating to DHCP Jumpstart" article in the May 2004 issue of Sys Admin:

## Vendor Specific Options for SUN

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-server-ip-address code 5 = ip-address;
option SUNW.sysid-config-file-server code 13 = text;
option SUNW.terminal-name code 15 = text;

## Range and Parameters for machines to be Jumped

subnet 10.128.196.0 netmask 255.255.255.0 {
  range 10.128.196.30 10.128.196.40;
  option domain-name-servers nameserver, nameserver;
  option domain-name "foo.com";
  option routers gateway;
  option broadcast-address 10.128.196.255;
  option subnet-mask 255.255.255.0;
  default-lease-time 600;
  max-lease-time 7200;
  option host-name "client-name";
  server-name "linux-svr";
  filename "inetboot.Solaris_2.9-0404";
  vendor-option-space SUNW;
  option SUNW.boot-file-path "/tftpboot";
  option SUNW.install-server-hostname "linux-svr";
  option SUNW.install-server-ip-address linux-svr-IP;
  option SUNW.install-path "/home/BUILD/SOLARIS/install/Solaris_2.9-0404";
  option SUNW.root-server-hostname "linux-svr";
  option SUNW.root-server-ip-address linux-svr-IP;
  option SUNW.root-path-name
"/home/BUILD/SOLARIS/install/Solaris_2.9-0404/Solaris_9/Tools/Boot";
  option SUNW.sysid-config-file-server
"linux-svr:/home/BUILD/SOLARIS/jumpstart/Types/Profile-Name";
  option SUNW.JumpStart-server
        "linux-svr:/home/BUILD/SOLARIS/jumpstart";
}

At this point, you are ready to jumpstart a Solaris machine from your Linux laptop. There are many more options and ways to structure this file based on your needs and preferences in grouping clients.

Other Uses

Some other practical uses for this configuration are to allow for diskless booting in the case of a drive failure. You would add something like this to your /etc/dhcpd.conf file:

## Emergency Booting
## Uncomment only if system has failed
#
#group {
#  filename /tftpboot/inetboot.Solaris_2.X
#  host hostname1 { hardware ethernet macaddress; }
#  host hostname2 { hardware ethernet macaddress; }
#}

Previously, I mentioned that doing this from a Linux-based laptop also gives you the capability to automate a Linux system build from the same source. You can achieve this with your current distribution by adding the necessary PXE or Etherboot options in DHCP. (PXE and EtherBoot are network booting alternatives for machines without an OpenBoot PROM.) You could even restore a Windows machine by using a Ghost boot floppy and storing the Ghost image on the laptop.

Conclusion

This type of configuration gives you the flexibility to accomplish tasks that would otherwise require several machines. The benefit of building it from a laptop allows you to turn a traditionally non-movable infrastructure into a portable one.

References

Droms, Ralph, and Ted Lemon. 2002. The DHCP Handbook. SAMS.

Kasper, Paul Anthony, and Alan L. McClellan. 1995. Automating Solaris Installations: A Custom JumpStart Guide. Prentice Hall PTR.

Van Dooren, Ralf. 2004. "Migrating to DHCP Jumpstart". Sys Admin 13(5):47-50.

Other contributing parties were co-workers: James K. McGlashan Jr. and Rory W. Britt.

Michael Sbailo is part of a Systems Integration team for a telecommunications company. His responsibilities include design and maintenance of the systems build infrastructure as well as daily operations tasks.