Introduction
JumpStart was developed by Sun Microsystems to automate the installation of the Solaris Operating Environment over a network. JumpStart makes use of a client- server architecture, where an install server is created that is able to deliver the Solaris Operating Environment packages to a target machine (a client) over a local network
Functionality was also coded so that an administrator could fine tune the configuration and add additional packages through the use of a post-installation script, but this often involved quite complex scripting and in depth product knowledge, to the extent that getting it to work correctly often took far longer than a comparable install by hand.
Sun Professional Services UK recognised the benefits of JumpStart but also saw the need to automate the installation and configuration of common applications such as volume manager software and third party or unbundled packages.
The result was the creation of the JumpStart Enterprise Toolkit, which was developed to be;
- Flexible: The toolkit must be flexible enough to support a variety of target server types. The toolkit should allow multiple identical target servers to be configured as well as many different configurations within the same framework.
- Modular: There should be a separation between the toolkit itself, the installable products, and the target server configurations. This provides a variety of benefits such as the ability to update single products or add new ones without impacting the existing configurations.
- Intuitive: The configuration of a target server should require the minimum effort on the part of the installer. Detailed product knowledge of JumpStart or additional products should not be required to automate the build of servers; this does not however preclude the concept of understanding a product in order to configure it properly; only that the installer does not need to know all the installation commands for every product.
The toolkit provides a set of utilities which are used in the following areas:
- Configure the JumpStart server and populate the server with media and patches.
- Set up a target server configuration by specifying the products to be installed and the installation parameters for each of them.
- Provide a library of common functions which are used by both the scripts within the toolkit and any additional product modules, in order to reduce code repetition.
JumpStart Walkthrough
Although the aim of this document is not to provide an in depth description of the JumpStart technology, this section aims to refresh the reader with the most pertinent points about JumpStart.
When a target server is being jumpstarted, the following steps are performed:
When a 'boot net' command is issued at the target servers OBP prompt, the target server starts to broadcast on the network, firstly through the RARP protocol, so it can establish its IP address and then for a boot server from which to boot the Solaris Operating Environment. The Solaris supplied script 'add_install_client' performs the function of defining the boot server, the location and type of the operating system image, and adds the target servers ethernet address to the local '/etc/ethers' file for the rarpd daemon to use. The main boot information is stored in the /etc/bootparams file on the JumpStart server. In the case of a non-interactive install, the bootparams file also contains information about the location of the JumpStart scripts, and the sysidcfg file for that particular target server.
Jumpstart also supports the use of dhcp for the initial boot. Instead of using RARP as above, it relies on DHCP requests to supply the information provided by the combination of RARP and BOOTP. The DHCP macro is sometimes used to store ALL the configuration details, but when using grub based boot methods, the menu.lst will hold that information instead.
As the kernel is booting on the target server, it tries to obtain its system identification parameters from a variety of sources; NIS, NIS+, dhcp, and a sysidcfg file. This information is used to plumb up the interfaces, along with setting locales and timezones properly prior to starting the actual installation routine. If it is unable to locate this information, the install will go interactive at this point.
Once the installation script starts, it searches for a configuration directory and for the rules.ok file within that location. If an entry within the rules.ok file matches the target server, it runs the 'begin' script if it has been defined.
Once the 'begin' script has been executed, the 'profile' defined in the rules.ok files is used to set the configuration details of the installation. The profile contains the information required to install Solaris on the machine, the boot disk and its partition information as well as what Solaris cluster/packages to install.
The system then proceeds to partition the boot disk/disks, install Solaris, and apply any bundled Solaris patches. Depending on the cluster selected, the network speed and the speeds of the respective servers, the time taken to install could range from minutes to hours.
N.B. The rules.ok file can indicate that the profile will be generated/provided by the 'begin' script, allowing the automatic generation of profiles as required.
Post Installation Configuration
After the installation phase, the target server then proceeds to run the 'finish' script as defined in the profile file. At this point, the target server operating system is running an NFS mounted version of the kernel, with volatile files in /tmp, which is held in memory. The freshly installed real operating system is mounted on "$ROOTDIR" (typically /a). The configuration directory (where the rules.ok file is found, and where the begin, profile and finish files are placed relative to) is mounted on "$SI_CONFIG_DIR".
Typically, a finish script will install the recommended patch cluster and any other hardware specific patch clusters defined, along with whatever else the author has decided to put into the script. It is however, up to the system administrator to write this script and test it thoroughly.
Once the finish script has completed, the system will reboot off the freshly installed disks and become a standalone machine, with no further dependency on the installation server.
Some packages do not install cleanly when the new root disks are available through "$ROOTDIR", even though pkgadd and patchadd have a -R flag to cope with this situation. In most cases, the problem lies with the package or patch postinstall scripts, which try to directly change items under /, i.e. /kernel/drv rather than $PKG_INSTALL_ROOT/kernel/drv.
To overcome this limitation, the most common workaround, is to drop an additional 'rc' script into the newly installed system, so that it is executed on the first boot, and additional configuration can be performed. This does have the added benefit of not requiring any special options to pkgadd/patchadd, since root really is on / at this point.
Traditional Weaknesses
The majority of the weaknesses in the traditional method of automating installs using JumpStart are time based. By the time an administrator has worked out how to install the application in an automated fashion and has crafted the scripts to be executed through the finish mechanism, the problem of debugging the final work is hindered by the fact you need to do a full Solaris installation before getting to the actual script under test.
In many cases, the only time JumpStart is beneficial, is if there are a huge number of nearly identical machines to build.
This problem is often compounded by the fact that the scripts themselves are often hard-coded with configuration information. Normally this information is constant across the builds at that point in time, but when approached in the future, the values often need changing. At this point, the new system administrator makes the decision to change the script, therefore breaking builds of older machines which still reference it, or making a copy of the script and changing the new version. This code forking of the script leads to problems when bugs are located in the original or indeed one of the derivatives: where else has the code been copied? If we change the other version(s), how do we satisfy ourselves that the change doesn't break their functionality?
The Jumpstart Enterprise Toolkit was created in a modular fashion to separate individual client configuration details from the installation scripts, so that scripts can be easily re-used for many varying client configurations.