Monday 7 May 2007

One rule to bind them - part I

One of the major developments in my jumpstart system's life was the move from having a jumpstart rule per client to a single rule for all clients. Up until then when a user was building a new system they had to:
  1. Login to the jumpstart server.
  2. Obtain root privileges.
  3. Edit /etc/hosts and add an entry for their client.
  4. Edit /etc/ethers and add an entry for their client.
  5. Run JASS add-client script to add the client configuration to /etc/bootparams.
  6. Edit the rules file and add the client to it with the appropriate Begin and Driver scripts for the system build they wanted installed.
  7. Regenerate the rules.ok file with the check script.
  8. Connect to the client system's console and type 'boot net - install'.
  9. Come back and hour or so later to a fully installed system.
This worked well for a few people but handing out root privileges to the growing number of users was not really desirable. Also, if any of the required steps was not done or an error/typo was made then the build would fail and possibly cause other users builds to fail as well. I needed to reduce this to at most 3 steps including steps 8 & 9.

My first attempt resulted in a more sophisticated begin script that eliminated steps 6 & 7. The user would perform steps 1 through 5, then step 8, wait a few minutes while the system booted from the network miniroot, then they would be presented a menu with a selection of different systems builds (firewall, DNS, web server etc) to choose from. The new menu system allowed a great deal of flexibility for our users and our system build developers.

The main advantage was that the jumpstart rules file needn't be maintained on a per host basis, instead a single rule like this was used:
any - Begin/begin = Drivers/driver
What this says is that for any client run Begin/begin script, which will generate (=) the jumpstart profile for installation. Then after installation run the Drivers/driver finish script to perform post-installation tasks such as the standard JASS hardening.

The majority of the magic lies in the Begin/begin script. This script determines which OS version is being installed, presents a menu to the user with the list of builds for that OS, then based on the user's selection generates the jumpstart profile for that build to include the base Solaris installation cluster (Core, User, Developer, Entire, or Entire plus OEM), additional SUNW clusters and packages, and the root file system layout and swap allocation.

The begin script also stores the user selection in a file which is read by the Driver/driver script to determine which build specific driver to execute post-install.

If you look at what I achieved above you'll see I only reduced the number of steps to build a system by two (from 9 to 7) but I laid the groundwork for much more extensive automation. In part II of this article I'll discuss how I developed the system to further reduce the work required by the user and issues caused by human error.

No comments: