The OS provisioning plug-in uses the features provided through the JumpStartTM Enterprise Toolkit (JET) technology to provision the Solaris Operating System (OS). JET is an enhancement to the Sun-developed JumpStart technology that automates the installation of the Solaris OS over a network. The OS provisioning plug-in through JET enhances this capability further, while hiding some of the complexity.
JET technology provides the JumpStart server with product-specific modules that install the Solaris OS and other products in a structured way. This structure enhances the features that you can implement through “ad-hoc” scripting of the JumpStart finish script.
The OS provisioning plug-in supplies three JET modules:
base_config – Installs and configures the Solaris OS. For information about base_config variables, see Basic Solaris OS Configuration Variables.
spsra – Installs and configures the N1 SPS Remote Agent (RA) on a Solaris system. For information about spsra variables, see Component Variables for Solaris Remote Agents.
custom – Installs arbitrary lists of Solaris packages, patches, and files, and can run arbitrary collections of scripts. For information about custom modules, see Using the custom Module.
The JET functionality that is provided with the OS Provisioning Plug-In is Solaris zone-aware and can be installed on a global zone without affecting any non–global zones. Because non–global zones do not currently support NFS share exports, JET is not supported on non–global zones
The build sequence of the JumpStart Enterprise Toolkit is as follows:
Standard Solaris installation phase
Call standard JumpStart finish script
Call individual module “install” scripts
Reboot target server
(Optional) Platform related installation tasks; reboot after each level
(Optional) Application related installation tasks; reboot after each level
(Optional) Final installation tasks (no reboot)
login prompt appears on the console
The optional steps after the initial reboot depend on the individual modules configured within the target server template. Modules can be written in such a way that they request that the toolkit perform additional work after the first reboot. In this request, the modules can identify whether the work should be in the platform-related area, the application-related area, or whether the work needs to be done at the end, when no more reboots are planned.