Jumpstart mechanism, provided by Sun, can be referred to as a basic toolkit with examples. Taken as it is, it only provides basic functionality, allowing to easily automate only OS installation. Even making basic Jumpstart to install OS without any questions, involves some handcrafting and trouble-shooting of configuration files or services. Any additional action requiring automation (like installation of patches), needs a script. This is normal and obvious. Not so obvious is the necessity to modify the configuration files and services for every new jumpstart client, new OS release, etc. For instance, adding a host requires changes in ethers, hosts, bootparams, tftp, rules, and sometimes in profiles, begin and finish scripts. Changing the client's target OS release, as minimum, requires changes in bootparams and tftp. The "add_install_client" script, in fact, does not make the maintenance much easier, than by editing the ethers/hosts/bootparams/rules and adding the links in /tftpboot by hand, because requires annoying long argument lines, and breaks more often, than works properly.

The first group of Jumpstart extentions described herein, intends to minimise the maintenance effort by offering a more structured directory hierarchy with a rich and flexible multi-level defaults.

This Jumpstart can install any of Solaris 2.6, 7, 8, 9, 10, 11, and has provision for future OS release additions. Such functionality is achieved by smart Begin script that mounts the necessary OS media image over the existing media image link in Jumpstart media directory (/cdrom).  The target OS version can be specified in OBP boot command, like "boot net - install 2.7". Default release is the same as booted OS release, i.e. release of diskless client. Diskless client normally boots the latest OS release available, and is capable of installing the SUNW* packages of any previous Solaris releases.  Thus,  changes in bootparams or tftpboot are unnecessary, as the diskless client always boots the same OSREL.

Significant effort has been spent for keeping all host-specific changes in one place. In this Jumpstart, all client individualities can be maintained in Jumpstart profiles only. There is only one rule in rules.ok, only one default Begin and one default Finish script. Some extentions to Jumpstart profile syntax, allow to parse the profile from within default begin and finish scripts, and execute shell commands, specific for Begin, or Finish, and/or host/site only. Such profile is generated dynamically from Jumpstart-wide defaults, as well as from Site- and Host-specific overwrites, if any are defined. The algorithm of profile generation is quitelogical, straightforward, and extendable.

Next group of additional features is related to extra packages, installed into diskless client root image. Such packages include VRTSvxvm, VRTSvxfs, NetBackup and are added for both installation automation and crash recovery. VRTSvxvm in the root imagehas  made it possible to encapsulate and mirror root disk before the very first reboot from the hard disk. Other VxVM activities like creation of mirrored/striped/RAID5 application volumes is also possible (although not yet tested). Some typical crash/recovery scenarios are described in Crash Recovery Cookbooks

More detailed understanding of different parts functionality can be obtained by reading theREADME files, comments in the shell code and config files,

Please feel free to email me for questions or suggestions.