Less Known Solaris features: Jumpstart Enterprise Toolkit - Part 13: Deep dive to post installation
As i told you before much of the configuration takes place after the installation executed by the orignal Jumpstart mechanism. We used several modules of the JET toolkit so far, thus this is a good moment to do a deep dive into the process that takes place after the normal Jumpstart installation.
The concept of this further installations steps relies pretty much completly on the concept of a so called finish script. Do you remember the
rules.ok file? There was a finish script specified in that file for all installations:
The installation of the Solaris Operating Environment is equal to the normal Jumpstart process, as it relies on the same functions. But then JET comes into the game. After the installation has completed, the script
Utils/finish is executed. But where is this file. It´s relative to an directory we´ve specified before. Or to be exact, JET did that for is.
This is a snippet from the
menu.lst for our system.
Utils/finish is relativ to
install_config, thus the executed finish script
192.168.10.1:/opt/SUNWjet/Utils/finish. The NFS mount specified in
install_config is one of the first mounts done on the new system and we can use the content of this directory throughout the installation process. By the way: This is the reason, why the
rules.ok is located at this strange position.
We can study the further process in logfile of the installation. The complete log is located at
/var/opt/sun/jet/ in the file
jumpstart_install.log. Let´s start. At first the finish script starts to take copy some components from the Jumpstart server to the local disk.
As you you see, the JET copies over part of the toolkit as well as configuration files to the new position. But why are all those directories relative to
/a. Well this is easy. In the netbooted mini root, the local disks are mounted relative to
/a. The reasoning behind this copy is relatively simple. In the next boots the contents of
/opt/SUNWjet/ aren´t available any longer, as the system doesn´t mount it in the next steps. The post installation scripts rely on some helper function. The simplest way to ensure their availability under all circumstances (even when your installation disables the network) is a simple copy.
The next step is the mounting of the directories with patches and product.
Now it get´s a little bit complicated, but i will simplify it as far as i can. Depending on the complexity of the setup your configuration may use one or more so called products. A product in JET-speak is a JET module for the installation and configuration of a certain area of the operating system. In any case you will use the product
base_config but there may be several ones. Our example uses the products
jass. The JET framework gathers this information from the configuration template. It´s stored in this line:
The framework takes this information and to execute the
install script in any of this directories. For example it starts at first the
install script in
/opt/SUNWjet/Products/base_config/solaris as this is default for every installation, after this it will step forward by executing the
install script in any of the product directories. The
install script has two important roles. At first it installs packages, patches and files according to the configuration in the templates. At second it registers so called
Post installation scripts
post_install scripts are executed at the next boots. You can order this scripts by specifing a certain boot level. After the execution of all scripts in a boot level, the system reboots. For example all scripts with boot level 1 are executed after the first reboot, all
post_install scripts with the boot level 2 are executed after the second reboot and so on. These scripts are installed in
But how get this scripts to execution at the following reboots. JET copies a
init.d script to the new system. On Solaris 10 it creates a matching SMF service. The function of this script is quite simple: Gather the actual boot level by reading the file
/var/opt/sun/jet/post_install/Platform, execute all scripts in the boot level, increment the bootlevel by one and reboot the system.
An example for boot levels and postinstall scripts
We´ve done the first boot. It booted from the network. The installation of the Solaris Operating Environment succeeded, thus the script from the
finish column is executed by the netbooted installation system. After some configuration tasks the system starts to register
You see, that the SDS product registered some scripts for boot level 1 and some for boot level z. Let´s look further into the installation log. This happens after the first reboot:
Later on you you will recognize the scripts for boot level z
With this mechanism, you can implement installation processes with package or programm installations that need several boots to fullfil.
The end of the post installation
At the very end the init.d script is deleted together with the matching SMF service. The logfiles and the post intallation scripts stay on the local disk.