Jumpstart Enterprise Toolkit

Jumpstart Enterprise Toolkit

Automated Installation

As wrote at several occasions in my tutorials, Solaris was designed with the enterprise customer in mind. It’s quite common, that a company has dozens of servers and you have to put your customized operating system on all of them. A special management tool, some special admin tools, a certain configuration of the volume manager.

The problem: Let’s assume, you have 50 system, all of them will have a slightly different configuration. This is normal, when you install your systems manually. Humans aren’t machines, and human work introduces variances in every instance of work. While this is nice for furniture or apparel, this can lead to long searches for needles in haystacks.

On some occasions I had strange problems with systems: One system worked just fine, another made problems. Both were installed with a cookbook. At the end we’ve used something similar to BART. We’ve compared both system and found slight differences. On the problematic system, the admin made an typo. I was curious and looked after the working system. Even this system wasn’t exactly like demanded by the cookbook.

So: How can you prevent this subtle variances between your systems? The most obvious way is the automation of the installation. Let do the computer, what a computer can do at best: Repetitive tasks with the same quality over and over again. Jumpstart and Jet have several ways and means to do automatic installation, thus making the admins live much easier, after you’ve done the final setup. And in this tutorial I want to show you, that this setup is really easy.

About Jumpstart

One basic problem of automated installation is the provisioning of the operating system on the bare metal. Without OS any further configuration is obviously senseless. For several releases Solaris contains a feature called Jumpstart. The basic idea of Jumpstart is the installation of a system by using the network.

The Jumpstart mechanism for PXE based x86

The process of jumpstarting is relatively simple.

  1. The system comes. It tries to gather informations about the network

    • Its own IP, netmask and network address

    • the boot server

  2. It connects to the boot server via tftp, loads the network boot program (in this case pxegrub) and the menu.lst.

  3. The pxegrub boots the an Solaris environment on the client. The menu.lst contains the locations of important sources:

    • config server

    • location of the sysid_config file

    • location of the installation media

    • location of the boot environment

  4. The mini root starts. From now on,you have a Solaris Kernel running on your systems.

  5. It gathers the rules.ok from the installation server.

  6. It tries to find a matching profile based on the rules in the rules.ok file.

  7. Based on the jumpstart profile it formats the disks, it mounts all filesystems like on the final system relative to the directory /a

  8. The installer starts to install the packages relatively to the directory /a

  9. After all, it writes the boot loader to the disks

  10. Now you can reboot the system.

Jumpstart Server

Albeit the Jumpstart Server is an important part in the process of installing the operating system on the server, it’s a passive part. The Jumpstart process itself is executed on the client, not on the server. The server is only necessary to provide information and the installation media. It uses existing protocols for this task as RARP or DHCP for assigning informations about the network or NFS and HTTP for providing access to the installation files.

Development

At the beginning Jumpstart was just able to do the installation. Recent versions[^47] include functions to automatically create boot mirrors.

Control Files for the automatic installation

I will not describe the exact process of native Jumpstart in its multitude of configurations as the Jumpstart Enterprise Toolkit does this job for us, but it’s important to know some of the important internals of Jumpstart. I will describe the most important files. There are various others like /etc/ethers or the DHCP server configuration, but as you don’t touch them manually even with the native configuration of Jumpstart I won’t describe them here.

rules

The first important file for the automatic installation is the rules file. This files associates system with a installation profile.

# rule keywords and rule values       begin script       profile       finish script
# -----------------------------       ------------       --------      -------------
hostname aramaki	setup	webserver		completion 
any   -                              -                  genericprofile  -

The first rule can be divided in parts like this: When the hostname of the new server is aramaki, start the script begin on the client before starting the installation. For the installation use the profile file webserver. After the installation execute the script completion

The second line is a catch-all condition. The file is used top down and the process of matching a system to a profile stops at the first match. Thus an installation for aramaki would reach the second line. This line can be translated like this. For any other host, use the profile genericprofile. There is no begin or finish script.

You can’t use the rules file directly. The Jumpstart server provides a script to do a syntax check on the rules. When the file is correct, the script adds it gets renamed to rules.ok

profile

The profile file controls what we install on the system and how we partition the disks for the installation.

# profile keywords        profile values
# -----------------       -----------------
  install_type            initial_install
  system_type             standalone
  partitioning            default
  filesys                 any 512 swap 
  cluster                 SUNWCprog
  package                 SUNWman delete
  cluster                 SUNWCacc

You can have a multitude of profiles in your system. A profile for system with large disks, a profile for system with small disks, a profile with a selection of packages customized for a webserver, a profile customized for a developer workstation. The jumpstart framework will choose the correct one on the basis of the rules.ok set

The profile is capable to control almost any important parameter for the installation on the disk. You can define pa

The sysidcfg file

Installing the packages on the system isn’t enough to get the operating system up an running. You have to give the system a unique identity. Parameters for this identity are:

  • configuration of network interfaces

  • locales

  • initial root password

  • time zone

  • etc.

You can type in such information manually, but that wouldn’t be a hands-off installation. The installation process of Solaris has a solution for this problem. You can set all the parameters in a file called sysidcfg. The Solaris installer will use this file to configure the system accordingly.

keyboard=US-English
timezone=US/Central
timeserver=timehost1
terminal=ibm-pc
service_profile=limited_net

name_service=NIS {domain_name=marquee.central.example.com
                  name_server=nmsvr2(172.25.112.3)}
nfs4_domain=example.com
root_password=URFUni9

But: Whenever some essential information is missing, the installer will go interactive and ask for the missing information. This obviously is against our objective of an automated installation.

Jumpstart FLASH

Sometimes you don’t to do a new install of a system. You just want to clone a system. For example think about a webserver farm. Let’s assume you have thirty of them. You’ve configured one and now you want to distribute this config to all of your system. You’ve tuned the system extensively, you changed configurations throughout all components. And you don’t want to do this 29 times again.

Full Flash Archives

Solaris Jumpstart knows a special mode of operation for this task: It’s called Jumpstart FLASH. The trick of Jumpstart flash is quite easy. At first a normal Jumpstart install and the FLASH install are identical. But when it comes to the installation of the Don’t install the packages one by one. Instead jumpstart flash unpacks a archive of a running system on a new system. This archive is called FLASH archive. Technically speaking it’s not much more than cpio archive of a running system.

Differential Flash Archives

There is an interesting mode of operation for flash archives. You can create differential flash archives. Let’s assume you created a basic flash archive and installed all your systems with it: your webserver, your mailserver, your database server. Most parts of the system are identical. Just a few additional binaries and configuration files differentiate your server from each other.

Let’s assume you want to create flash archives from all systems. Of course you could create a full flash archive for each system, but this would be waste of disk space. The differential flash archive creation works relatively simple. It compares the content of a flash archive with the actual state of an installed system and just archives the changed parts. The next time you want to install the system, you use both archives. At first the full archive will be installed on the system, after this you use one or more differential flash archives to complete your installation.

::: center
[old]{.smallcaps} [new]{.smallcaps} [Action]{.smallcaps}
——————- ———————- —————————————————————–
exists not exists File is included in archive
exists exists but different The file from the new state is included in archive
exists exists not File will be deleted, when the diff archive is used on a server

differential archive behavior :::

flar creation is just a big wrapper around cpio, thus it’s possible to some nifty tricks with it. The current states of the system doesn’t have be the active one, and the old states doesn’t have to be flar archives.

It’s possible to compare an old boot environment and the actual boot environment from Liveupgrade to generate a differential flash archive. This differential can be used to update other servers. You could even compare a remote system via NFS, when don’t squash root.[^48]

Challenges of Jumpstart Flash for System Recovery

Flash was designed with the task of system cloning in mind. So it removes the identity of the system after the installation by using the sysidunconfig command. The need for such a step at system cloning is obvious: One part of the systems identity is the networking configuration. You can’t clone the network configuration. TCP/IP duplicates

sysunconfig deletes the entire configuration, that makes the installation an unique instance:

  • saves a copy of /etc/hosts and substitute it with a default one.

  • removes any NFS mount from /etc/vfstab

  • deletes NIS, NIS+,LDAP and DNS name service configuration

  • removes the interface configuration of all configured interfaces.

  • removes the root password

  • removes /etc/sysidcfg

  • removes /etc/defaultrouter

  • removes /etc/ined/netmasks

  • regenerates the ssh-keys

  • sets the timezones in /etc/timezone to PST8PDT

Albeit it’s not designed for system recovery, there is a trick you can use to recover the removed information. The knowledge about the removed part is important for the trick, thus I’ve included a list of them in this tutorial. You will find a script at the end of this tutorial.

About the Jumpstart Enterprise Toolkit

The basic idea behind JET

The Jumpstart Enterprise Toolkit (JET) was designed as an add-on to the normal Jumpstart process. It solves two major challenges:

  • Jumpstart works exceptionally well to install the operating system and to do configurations in conjunction to the operating system, but misses some easy to configure features to execute further configurations of higher-level configuration besides of having hooks for finish scripts.

  • Some people find it a little bit complex to configure. While I strongly believe, this isn’t the case, I have to admit, thats hard to remember the commands when this is not your everyday task

With both issues in mind, some Sun Engineers start to develop the Jumpstart Enterprise Toolkit. Basically it’s a bunch of clever shell scripts.

  • The Jumpstart Enterprise Toolkit configures the Jumpstart Server accordingly to the configuration in a template.

  • Furthermore it provides a framework for application specific modules to install and configure them.

When using JET you don’t have to hassle around with all this files explained before, making the installation easier.

Additional features of JET

JET isn’t just a config generator for Jumpstart. You can configure JET in a way to fully customize your system. Much of this capability comes from a link called S99jumpstart or the respective SMF service. This script has an important role: It executes further actions on the system on following boots. For example, the mirroring of harddisks isn’t done by integrated functionalities of Solaris Jumpstart[^49]. It’s done by a script located on the server and made available by NFS, but executed on the server. This concept makes the JET a very flexible tool.

Prerequisites

Systems

For these tests, I need quite a few systems. I’ve used VirtualBox in the preparation of this tutorial.

I’ve populated my /etc/hosts with the following hostnames[^50]:

192.168.10.1 aramaki
192.168.10.10	togusa
192.168.10.11	ishikawa

In my tutorial aramaki will serve as the Jumpstart server, togusa and ishikawa are the installation targets.

Packages

For this tutorial I’ve used the following packages and ISOs:

Solaris 10 Update 5

This is the operating environment I will use to demonstrate automated patching

OpenSolaris Community Edition Build 87

aramaki runs with this operating environment and it’s no problem to jumpstart OpenSolaris CE or DE with JET.

Recommended Patch Cluster

To demonstrate automated patching, I’ve used the recommended patch cluster. You can gather it at http://sunsolve.sun.com

SUNWjet

The Jumpstart Enterprise Toolkit. You can get it at http://www.sun.com/download/index.jsp?tab=2#J

SUNWjass

The Solaris Security Toolkit. You can get it from http://www.sun.com/download/index.jsp?tab=2#S

Installation of JET

Preparation of the system

A jumpstart server doesn’t have to be a big server. But it’s good practice to take the following into consideration:

  • You have to copy your installation media onto the server. A Solaris version needs up to 4 Gigabyte on disk. Additionally you need space for further products (like other applications) and patches[^51].Depending on the amount of Solaris versions you want to provide, it’s a good idea not to spend the rest of an existing partition to your Jumpstart server.

  • It’s a wise choice to have a fast network. As the system isn’t hardened and unconfigured at the first install, the paranoid prefer to use a free Gigabit-Ethernet port at my jumpstart server and use a separated VLAN for initial configuration. Or you use your admin LAN for this purpose. Either ways, for an fast installation gigabit ethernet is nice.

The installation

After copying the JET package on our new Jumpstart server, we have to install the package:

# pkgadd -d jet.pkg 

The following packages are available:
  1  JetEXPLO       jet explo product
                    (sparc) 3.1.11
  2  JetFLASH       JET flash product
                    (sparc) 3.1.8
  3  JetJASS        JASS product
                    (sparc) 3.0.14
  4  JetRBAC        JET RBAC product
                    (sparc) 1.1.5
  5  JetSAN         JET san product
                    (sparc) 3.1.7
  6  JetSBD         Secure By Default product
                    (sparc) 1.0.2
  7  JetSDS         JET sds product
                    (sparc,i386) 3.4.4
  8  JetVTS         JET VTS product
                    (sparc) 3.0.11
  9  JetWanBoot     JET WanBoot support
                    (sparc) 1.1.1
 10  JetZONES       JET Zones module
                    (sparc) 1.1.12

... 2 more menu choices to follow;
<RETURN> for more choices, <CTRL-D> to stop display:

 11  SUNWjet        Sun JumpStart Enterprise Toolkit
                    (sparc,i386) 4.4
 12  SUNWjetd       JET Documentation
                    (sparc) 3.3.1

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: all
JetEXPLO

Installs and configures the Sun Explorer

JetFLASH

Module to control Jumpstart Flash installed

JetJASS

executes the Solaris Security Toolkit on the new host

JetRBAC

configures the Role Based Access Control

JetSAN

configures the SAN framework of Solaris

JetSBD

configures the Secure-by-default setting

JetSDS

configures the Solaris Volume Management

JetVTS

installs the Sun Validation Test Suite. It tests and validates Sun hardware by verifying the connectivity and functionality of hardware devices, controllers and peripherals.

JetWANboot

configures the Jumpstart facilities for installation over the WAN

JetZONES

configures Solaris Zones on the newly installed zones.

As the package is quite small with half a megabyte, I always install all packages on a jumpstart server.

Processing package instance <SUNWjet> from </root/jet.pkg>

Sun JumpStart Enterprise Toolkit(sparc,i386) 4.4
Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.

The selected base directory </opt/SUNWjet> must exist before
installation is attempted.

Do you want this directory created now [y,n,?,q] y
Using </opt/SUNWjet> as the package base directory.

[...]

Processing package instance <JetSBD> from </root/jet.pkg>

Secure By Default product(sparc) 1.0.2

#

This is all we have to do for the installation.

Preparations for out first installation

Now you have to copy your Solaris install media. You can do this on two ways.

From a mounted DVD media

When you already have burned media, you can use it for the copy process. Just put it into the drive, the volume management mounts it and you can copy it from there.

# /opt/SUNWjet/bin/copy_solaris_media -d /export/install/media/solaris/x86/nv87 -n nv87 /cdrom/sol_11_x86
Copying Solaris image....
Verifying target directory...
Calculating the required disk space for the Solaris_11 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Copying /boot netboot hierarchy...
Install Server setup complete
 
Added Solaris image nv87 at the following location:
        Media:          /export/install/media/solaris/x86/nv87
 
removing directory /export/install/media/solaris/x86/911
#

Let’s dissect the command: -d specifies the target, where you copy the operating system. -n specifies a name for this media. From now on you refer this solaris media as nv87 in the templates for JET. At the end you specify the location, where the media is located at the moment.

From a .iso file

Okay, you’ve downloaded your Solaris media. You don’t have to burn it, you can use the .iso files directly:

# ./copy_solaris_media -d /export/install/media/solaris/x86/sol10u5 -n sol10u5 -i /export/home/jmoekamp sol-10-u5-ga-x86-dvd.iso 
Created loopback device /dev/lofi/1 for /export/home/jmoekamp/sol-10-u5-ga-x86-dvd.iso
mounted /export/home/jmoekamp/sol-10-u5-ga-x86-dvd.iso at /export/install/media/solaris/x86/790/slices/s0 (of type hsfs)
Copying Solaris image....
Verifying target directory...
Calculating the required disk space for the Solaris_10 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Copying /boot x86 netboot hierarchy...
Install Server setup complete
 
Added Solaris image sol10u5 at the following location:
        Media:          /export/install/media/solaris/x86/sol10u5
 
Unmounting /export/install/media/solaris/x86/790/slices/s0
removing device /dev/lofi/1
removing directory /export/install/media/solaris/x86/790

The command line for using a .iso file is quite similar. You just specify with the -i that an =.iso= file has to be used and in which directory it should search for it. The last parameter is the name of the .iso file itself. The system mounts the dvd image by using the loopback facility of Solaris and copies the media to its target location afterwards.

Looking up the existing Solaris versions

JET provides script to lookup the versions of Solaris you’ve copied to your Jumpstart Server. With the list_solaris_locations script you look up the version and the location of your solaris medias.

# ./list_solaris_locations 
Version         Location
-------         --------
nv87            /export/install/media/solaris/x86/nv87
sol10u5         /export/install/media/solaris/x86/sol10u5

A basic automated installation

At first we will do a really basic install. No tricks, just the pure operating system. Nevertheless this part will be a little bit longer as I will do a technical deep-dive into the process of installation in this example to show you the inner workings of JET with this installation as an example.

The template for the install

At first we have to create a template for the system. This is really easy.

# make_template togusa
Adding product configuration information for 
        + base_config
        + custom
        + sds
        + vts
        + explo
        + flash
        + san
        + jass
        + zones
        + sbd
Updating base_config template specifics
Client template created in /opt/SUNWjet/Templates

Okay, this is too much ... at start we don’t want all this modules right now. We can add them later, without loosing the configuration. Let’s just use the module for the basic configuration:

# make_template -f togusa base_config
Adding product configuration information for 
        + base_config
Updating base_config template specifics
Client template created in /opt/SUNWjet/Templates

Even the basic template is quite long. I’ve reduced it for this tutorial by deleting all comments, all empty lines and all variables without a value.

base_config_ClientArch=i86pc
base_config_ClientEther=08:00:27:97:29:1E
base_config_ClientOS=nv87
base_config_client_allocation="grub"
base_config_sysidcfg_nameservice=NONE
base_config_sysidcfg_network_interface=PRIMARY 
base_config_sysidcfg_ip_address=192.168.10.10
base_config_sysidcfg_netmask=255.255.255.0
base_config_sysidcfg_root_password="boajrOmU7GFmY"
base_config_sysidcfg_system_locale="C"
base_config_sysidcfg_timeserver=localhost
base_config_sysidcfg_timezone="Europe/Berlin"
base_config_sysidcfg_terminal=vt100
base_config_sysidcfg_security_policy=NONE
base_config_sysidcfg_protocol_ipv6=no
base_config_sysidcfg_default_route=192.168.10.1
base_config_x86_nowin="yes"
base_config_label_disks="all"
base_config_profile_cluster=SUNWCuser
base_config_profile_usedisk=rootdisk.
base_config_profile_root=free 
base_config_profile_swap=256
base_config_ufs_logging_filesys="all"
base_config_profile_del_clusters="SUNWCpm SUNWCpmx SUNWCdial SUNWCdialx"
base_config_dns_disableforbuild="yes"
base_config_update_terminal="yes"
base_config_enable_savecore="yes"
base_config_dumpadm_minfree="20000k"
base_config_noautoshutdown="pm_disabled"

Let’s dissect this template.

Line 1-3

This lines are the most basic ones. The first line defines the architecture of the system. The next line is the Ethernet-Address of the new system. The third one specifies the new operating system.

Line 4

This line specifies, how the new system gathers the most basic informations like its own IP.

Line 5-16

Do you remember the part about sysidcfg. The values for this files are defined in this part of the template.

Line 17

This line tells the system to suppress the start of the windowing system.

Line 18

Solaris needs a disk label on the disks for the system. This directive tells the system to write this label to all disks.

Line 19-22

Another known phrase ... profile. Here you specify the partitioning for the system and what packages will be installed on it.

Line 23-end

There are several further statements. Please the original file for an explanation.

Okay after this step, we have to generate the configuration for the Jumpstart mechanism. This is really easy:

# make_client -f togusa
Gathering network information..
        Client: 192.168.10.10 (192.168.10.0/255.255.255.0)
        Server: 192.168.10.1 (192.168.10.0/255.255.255.0, SunOS)
Solaris: client_prevalidate
Solaris: client_build
Creating sysidcfg
Creating profile
Adding base_config specifics to client configuration
Solaris: Configuring JumpStart boot for togusa
         Starting SMF services for JumpStart
Solaris: Configure PXE/grub build
         Adding install client
        Doing a TEXT based install
         Leaving the graphical device as the primary console
         Configuring togusa macro
         Using local dhcp server
         PXE/grub configuration complete
Running '/opt/SUNWjet/bin/check_client  togusa'
        Client: 192.168.10.10 (192.168.10.0/255.255.255.0)
        Server: 192.168.10.1 (192.168.10.0/255.255.255.0, SunOS)
Checking product base_config/solaris
--------------------------------------------------------------
Check of client togusa 
-> Passed....

The nice thing about the make_client command: It doesn’t just generate the Jumpstart configuration. It checks for the most dumb errors like forget to share the directory of your Solaris media with NFS. So you can detect many problems at an early stage. You don’t have to wait until the jumpstart client comes up just to detect, that there is no NFS or no DHCP config.

The generated Jumpstart configuration files

Okay, let’s look into the /tftpboot directory at first. As the system uses pxegrub we need a menu.lst

-bash-3.2$ cat /tftpboot/menu.lst.0108002797291E 
default=0
timeout=2
title Solaris_11 Jumpstart
        kernel /I86PC.Solaris_11-1/platform/i86pc/kernel/unix  - install nowin -B install_config=192.168.10.1:/opt/SUNWjet,sysid_config=192.168.10.1:/opt/SUNWjet/Clients/togusa,install_media=192.168.10.1:/export/install/media/solaris/x86/nv87,install_boot=192.168.10.1:/export/install/media/solaris/x86/nv87/boot
        module /I86PC.Solaris_11-1/x86.miniroot
-bash-3.2$

In the GRUB configuration we not only load the Kernel, we additionally name the location of the Jumpstart server, the exact location and name of the sysidconfig file, the position of our installation media and at last the location of the miniroot. In our example all locations are NFS locations.

Okay, the install_config directory is the first important location. We find the rules.ok file there.

-bash-3.2$ cat /opt/SUNWjet/rules.ok 
any any                 Utils/begin     =       Utils/finish
# version=2 checksum=3114

Okay, now let’s have a look in the specified profile file:

-bash-3.2$ cat /opt/SUNWjet/Clients/togusa/profile             
#
# This is an automatically generated profile. Please modify the template.
#
# Created:      Mon May 19 21:47:50 CEST 2008
#
install_type    initial_install
system_type     server
cluster         SUNWCuser
partitioning    explicit
#
# Disk layouts
#
filesys         rootdisk.s0     free    /
filesys         rootdisk.s1     256     swap
cluster SUNWCpm delete
cluster SUNWCpmx delete
cluster SUNWCdial delete
cluster SUNWCdialx delete

As I wrote before, we have to give the system an identity. The sysidcfg is responsible for this task, thus we find such a file in our directory. Our new system will use it when the installation has completed.

-bash-3.2$ cat /opt/SUNWjet/Clients/togusa/sysidcfg 
name_service=NONE
root_password=boajrOmU7GFmY
system_locale=C
timeserver=localhost
timezone=Europe/Berlin
terminal=vt100
security_policy=NONE
nfs4_domain=dynamic
network_interface=PRIMARY {hostname=togusa ip_address=192.168.10.10 netmask=255.255.255.0 protocol_ipv6=no default_route=192.168.10.1}

The installation boot

This leaves you to do one thing. Configure the system to start with PXE in the BIOS of your system. And the system will boot via network and starts to install a system.

After a while the installation will be complete. You can look for the logfile of the installation at /var/sadm/system/logs:

Configuring disk (c0d0)
        - Creating Fdisk partition table

Fdisk partition table for disk c0d0 (input file for fdisk(1M))
          type: 130  active:  128  offset: 16065   size: 33527655
          type: 100  active:  0    offset: 0       size: 0      
          type: 100  active:  0    offset: 0       size: 0      
          type: 100  active:  0    offset: 0       size: 0      
        - Creating Solaris disk label (VTOC)
        - Processing the alternate sector slice

Creating and checking UFS file systems
        - Creating / (c0d0s0)
Warning: 1608 sector(s) in last cylinder unallocated
/dev/rdsk/c0d0s0:       31744440 sectors in 5167 cylinders of 48 tracks, 128 sectors
        15500.2MB in 323 cyl groups (16 c/g, 48.00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
......
super-block backups for last 10 cylinder groups at:
 30776480, 30874912, 30973344, 31071776, 31170208, 31268640, 31367072,
 31457312, 31555744, 31654176

Beginning Solaris software installation

Installation of <SUNWkvm> was successful.
[...]
Installation of <SUNWsolnm> was successful.

Solaris 11 software installation succeeded

Solaris 11 packages fully installed
                SUNWkvm
[...]
                SUNWsolnm

Customizing system files
        - Mount points table (/etc/vfstab)
          fd    -       /dev/fd fd      -       no      -
          /proc -       /proc   proc    -       no      -
          /dev/dsk/c0d0s1       -       -       swap    -       no      -
          /dev/dsk/c0d0s0       /dev/rdsk/c0d0s0        /       ufs     1       no      -
          /devices      -       /devices        devfs   -       no      -
          sharefs       -       /etc/dfs/sharetab       sharefs -       no      -
          ctfs  -       /system/contract        ctfs    -       no      -
          objfs -       /system/object  objfs   -       no      -
          swap  -       /tmp    tmpfs   -       yes     -
        - Network host addresses (/etc/hosts)
        - Environment variables (/etc/default/init)

Cleaning devices

Customizing system devices
        - Physical devices (/devices)
        - Logical devices (/dev)

Installing boot information
        - Updating boot environment configuration file
        - Installing boot blocks (c0d0)
        - Installing boot blocks (/dev/rdsk/c0d0s0)
Creating boot_archive for /a
updating /a/platform/i86pc/boot_archive
updating /a/platform/i86pc/amd64/boot_archive

A basic automated installation - more polished

Okay, now we’ve done a basic installation. But mostly we do a standard set of customizations on every system we touch, like installing a few essential tools or integrating the actual recommended patch cluster. So we want to polish the standard installation a little bit. We will extend a basic Solaris 10 Update 5 installation with the following items:

  • installing the SUNWstar script

  • installing the recommended Patch Cluster

  • configuring the Secure-by-default mechanism to limited

Okay, at first we have to copy the patches into the jumpstart. JET provides the copy_solaris_patches command to do so.

# copy_solaris_patches 10_x86 /export/home/jmoekamp/10_x86_Recommended
Copied....

You don’t have to configure anything in the templates. Every new Solaris 10 installation on x86 will be installed with the matching recommended patch cluster.

Adding custom packages

Okay, almost everybody installs some customer packages on his/her system. For example, one of the first things i«m installing on new systems is joe to have an WordStar compatible editor:

# pkgtrans joe-3.5-sol10-x86-local /tmp all
Transferring <SMCjoe> package instance
# copy_custom_packages /tmp x86 SMCjoe                 
Transferring <SMCjoe> package instance
Packages copied

joe depends on the ncurses library. So we copy this package as well to our JET server.

# pkgtrans ncurses-5.6-sol10-x86-local /tmp all
Transferring <SMCncurs> package instance
# copy_custom_packages /tmp x86 SMCncurs
Transferring <SMCncurs> package instance
Packages copied

Extending the template

Okay, we need more modules to fulfill this tasks. You don’t need to delete the old one and retype all the data in the template. The make_template script can use an old template to create a new one with while retaining all the old values. Basically you use the same name for the old and new template.

# ./make_template -f  -T togusa togusa base_config custom sbd
Adding product configuration information for 
        + custom
        + sbd
Updating base_config template specifics
Client template created in /opt/SUNWjet/Templates

When you look into /opt/SUNWjet/Templates/togusa you will recognize your old configuration, with a large amount of new lines. But we have to change only a few ones:

At first we change the operation system. We’ve used OpenSolaris in the last example, but there are no patches. But we’ve copied a Solaris 10 media with the name sol10u5 earlier.

base_config_ClientOS=sol10u5

Okay, now we want to install the additional packages. You have to add the names of the packages in the line custom_packages.

custom_packages="SMCncurs SMCjoe"

You don’t have to configure the Secure by default module, as this module configures the limited service set when it’s used in the template. Patching of the Solaris OE doesn’t need configuration as well. So we have to change only this two lines.

The installation

Okay, you can start the installation by starting a network boot. This time the installation takes a little bit longer. First the system starts to install the recommended patch cluster. As I’ve used a quite actual update, most patches are already installed. but a few ones will find their way into the installation.

BASE_CONFIG: Installing base_config....
BASE_CONFIG: Product base_config started
BASE_CONFIG: Installing additional patches from : 10_x86_Recommended
BASE_CONFIG: Using patch_order file for patch installation sequence
BASE_CONFIG: 
BASE_CONFIG: ------ Installing patches for product: 10_x86_Recommended ------
BASE_CONFIG: 
BASE_CONFIG: Patch 120720-02 is already installed.
BASE_CONFIG: Patch 124458-01 is already installed.
[...]
BASE_CONFIG: <<< 120273-20 (25 of 98) >>>
[...]
BASE_CONFIG: Patch 122175-03 is already installed.
BASE_CONFIG: Patch installation completed.
BASE_CONFIG: No HW specific packages for platform i86pc
BASE_CONFIG: No HW specific patches for platform i86pc

Okay, now the system starts to install the additional packages.

CUSTOM: Installing custom....
CUSTOM: Installing SMCncurs from: /a/var/opt/sun/jet/js_media/pkg/custom/i386
Installation of <SMCncurs> was successful.
CUSTOM: SMCncurs installation complete
CUSTOM: Installing SMCjoe from: /a/var/opt/sun/jet/js_media/pkg/custom/i386
Installation of <SMCjoe> was successful.
CUSTOM: SMCjoe installation complete

The following module doesn’t do really much, as the configuration of the service profile is activated by the sysidcfg file.

SBD: Installing sbd....
SBD: configured

Effects of the new modules

Let’s check the results of the installation. At first, we look for the custom packages:

# pkginfo | grep "SMC"
application SMCjoe                           joe
application SMCncurs                         ncurses

When we look for one of the installed patches, we will see its successful installation to the system:

# showrev -p | grep "120273-20"
Patch: 120273-20 Obsoletes:  Requires: 119043-09, 121902-01, 122532-04 Incompatibles:  Packages: SUNWbzip, SUNWsmagt, SUNWsmcmd, SUNWsmmgr

Automatic mirroring of harddisks

Okay, in enterprise computing you wouldn’t use a system without redundant boot disks (at least, when you haven’t an application that can survive a loss of computing nodes without a problem). So it would be nice to automatically configure a mirror of the boot disks with the Solaris Volume Manager. I assume in the following part, that you have a working knowledge with the . When this not the case, it isn’t really a problem, as this part it somewhat self-explanatory.

# make_template -f -M -T togusa togusa sds
Adding product configuration information for 
        + sds

Configuration in the template

As in the last example I will just include the interesting parts of the configuration:

base_config_products=" custom sbd sds"
sds_product_version="default"
sds_root_mirror="c1d1"
sds_use_fmthard="yes"
sds_database_locations="rootdisk.s7:3"
sds_database_partition="s7:32"
sds_metadb_size=""
sds_root_alias="rootdisk"
sds_root_mirror_devalias_name="rootmirror"
sds_mirrored_root_flag="yes"

At first you have to include the sds module to the base_config_product line. Then choose the disk you want to use for mirroring, in my case it’s /dev/dsk/c1d1. Line 4 orders the sds module to copy the vtoc of the first mirror to the second one. When there are only two disks in your system you have to specify the sds_mirror_root_flag with yes in line 10. want to see the metadb replica copies on at least three disks[^52]. You have to tell the system that it shouldn’t obey this rule.

Effects of the configuration

Okay, after the installation we can log into the system. You may notice after the installation a vast amount of accesses to the harddisk. The devices for / and the swap are not longer referenced by an device name. Instead of this you will find the names of the logical devices of the .

-bash-3.2$ cat vfstab 
#device         device          mount           FS      fsck    mount   mount
#to mount       to fsck         point           type    pass    at boot options
#
fd      -       /dev/fd fd      -       no      -
/proc   -       /proc   proc    -       no      -
/dev/md/dsk/d20 -       -       swap    -       no      -
/dev/md/dsk/d10 /dev/md/rdsk/d10        /       ufs     1       no      logging
/devices        -       /devices        devfs   -       no      -
ctfs    -       /system/contract        ctfs    -       no      -
objfs   -       /system/object  objfs   -       no      -
swap    -       /tmp    tmpfs   -       yes     -

Let’s look after the exact configuration of the volume manager.

-bash-3.2$ metastat
d20: Mirror
    Submirror 0: d21
      State: Okay         
    Submirror 1: d22
      State: Okay         
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 530145 blocks (258 MB)

d21: Submirror of d20
    State: Okay         
    Size: 530145 blocks (258 MB)
    Stripe 0:
        Device   Start Block  Dbase        State Reloc Hot Spare
        c0d0s1          0     No            Okay   Yes 


d22: Submirror of d20
    State: Okay         
    Size: 530145 blocks (258 MB)
    Stripe 0:
        Device   Start Block  Dbase        State Reloc Hot Spare
        c1d1s1          0     No            Okay   Yes 


d10: Mirror
    Submirror 0: d11
      State: Okay         
    Submirror 1: d12
      State: Okay         
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 32836860 blocks (15 GB)

d11: Submirror of d10
    State: Okay         
    Size: 32836860 blocks (15 GB)
    Stripe 0:
        Device   Start Block  Dbase        State Reloc Hot Spare
        c0d0s0          0     No            Okay   Yes 


d12: Submirror of d10
    State: Okay         
    Size: 32836860 blocks (15 GB)
    Stripe 0:
        Device   Start Block  Dbase        State Reloc Hot Spare
        c1d1s0          0     No            Okay   Yes 


Device Relocation Information:
Device   Reloc  Device ID
c1d1   Yes      id1,cmdk@AVBOX_HARDDISK=VB37711a7b-00576cc9
c0d0   Yes      id1,cmdk@AVBOX_HARDDISK=VB97a90791-9d191449

The default numbering scheme for the Solaris volume manager is quite simple: The mirror is designated with the first number in a decade (e.g. 10,20,30), the parts of a mirror are numbered with the next free numbers in the decade. For example: The first mirror half of the first mirror get the number 11, the second number gets the number 12.

It takes a while until the mirrors are in sync, but after this you have a automatically installed, patched, customized and mirrored system.

Automatic hardening

Preparing the Jumpstart for installation

At fist you uncompress and untar the distribution.

# copy_product_media jass 4.2.0 /export/home/jmoekamp i386
Transferring <SUNWjass> package instance
 
Packages copied.

Okay, but we have to do another step. There is a patch for the version 4.2.0 of the : 122608-xx. At first we have to tell JET that there is a patch for this product and version. We have to modify the file patch.matrix in /opt/SUNWjet/Products/jass.

#
# Patch matrix for Solaris Security Toolkit (JASS)
#
# <os>:<arch>:<version>:<patchlist>
#
10:i386:4.2.0:122608

Now it’s easy to integrate the patch. I’ve unpacked the patch in the directory /export/home/jmoekamp/patch_jass before:

# copy_product_patches jass 4.2.0 /export/home/jmoekamp/patch_jass i386         
 
Patches copied.

Configuring the template

Okay, you have to configure only a few basic variables to trigger the automatic hardening of your new installation.

base_config_products=" custom sbd sds jass"
jass_product_version="4.2.0"
jass_execute="secure.driver"

After Jumpstarting

Okay, it’s time to reboot the machine we want to install again. At first, all is like at the runs before. But then we see some further lines in the logfile.

JASS: Installing jass....
JASS: Installing Solaris Security Toolkit (JASS) 4.2.0...
JASS: Installing SUNWjass from: /a/var/opt/sun/jet/js_media/pkg/jass/4.2.0/i386

Installation of <SUNWjass> was successful.
JASS: SUNWjass installation complete
JASS: Register postinstall script 'postinstall' for boot z

It’s important to know, that the above configuration installed the SUNWjass package on the system, patches it there and then run runs the toolkit installed on the system.

The hardening of the system is started in the background.After a while you will recognize the work of the script. The backup files of the Solaris Security Toolkit are dispersed all over the directories.

bash-3.00$ ls -l /etc/*.JASS*
-rw-r--r--   1 root     other        372 May 23 19:48 /etc/coreadm.conf.JASS.20080523195314
[...]
-rw-r--r--   1 root     sys          362 May 23 19:43 /etc/vfstab.JASS.20080523195420
bash-3.00$

After the completion of the background JASS run, you have a automatically installed, patched, customized, mirrored and hardened system.

Deep Dive to the installation with JET

As I told you before much of the configuration takes place after the installation executed by the 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 installation.

The concept of this further installs pretty much relies 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:

bash-3.2$ cat rules.ok
any any                 Utils/begin     =       Utils/finish
# version=2 checksum=3114

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.

title Solaris_11 Jumpstart
        kernel /I86PC.Solaris_11-1/platform/i86pc/kernel/unix  - install nowin -
B install_config=192.168.10.1:/opt/SUNWjet,sysid_config=192.168.10.1:/opt/SUNWje
t/Clients/togusa,install_media=192.168.10.1:/export/install/media/solaris/x86/nv
87,install_boot=192.168.10.1:/export/install/media/solaris/x86/nv87/boot
        module /I86PC.Solaris_11-1/x86.miniroot

The 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.

Creating directory: /a/var/opt/sun/jet/post_install
Creating directory: /a/var/opt/sun/jet/Utils
Creating directory: /a/var/opt/sun/jet/config
Creating directory: /a/var/opt/sun/jet/js_media/patch
Creating directory: /a/var/opt/sun/jet/js_media/pkg
Copying file Clients/togusa/sysidcfg to /a/var/opt/sun/jet/config/sysidcfg
Copying file Clients/togusa/profile to /a/var/opt/sun/jet/config/profile
Copying file Clients/togusa/host.config to /a/var/opt/sun/jet/config/host.config
Copying file Utils/solaris/releaseinfo to /a/var/opt/sun/jet/config/releaseinfo
Copying functions to /a/var/opt/sun/jet/Utils/lib
Copying file Clients/togusa/module_hints to /a/var/opt/sun/jet/config/module_hints

As 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 [^53] is a simple copy.

The next step is the mounting of the directories with patches and product.

Mounting nfs://192.168.10.1/export/install/patches on /var/opt/sun/jet/js_media/patch
Mounting nfs://192.168.10.1/export/install/pkgs on /var/opt/sun/jet/js_media/pkg

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 base_config, custom, sds and jass. The JET framework gathers this information from the configuration template. It’s stored in this line:

base_config_products=" custom sbd sds jass"

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_install scripts.

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 /var/opt/sun/jet/post_install

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 postinstall scripts.

SDS: Installing sds....
SDS: Copying file sds_functions to /a/var/opt/sun/jet/Utils/sds_functions
SDS: Creating directory: /a/var/opt/sun/jet/post_install/Platform/1
SDS: Register postinstall script 'create_fmthard' for boot 1
SDS: Register postinstall script 'set_boot_device' for boot 1
SDS: Register postinstall script 'create_metadb' for boot 1
SDS: Register postinstall script 'create_root_mirror' for boot 1
SDS: Register postinstall script 'attach_mirrors' for boot z
SDS: Register postinstall script 'create_user_devices' for boot 1
SDS: Register postinstall script 'attach_user_mirrors' for boot z
SDS: WARNING: unable to locate specified md.tab for SDS.
SDS: Enable md:mirrored_root_flag in /etc/system

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:

SDS: Running 001.sds.001.create_fmthard
fmthard:  New volume table of contents now in place.
SDS: Running 001.sds.001.set_boot_device
SDS: Setting OBP nvramrc rootdisk path
[...]
SDS: Create 3 copies on c1d1s7
metadb: waiting on /etc/lvm/lock
SDS: Running 001.sds.003.create_root_mirror
SDS: Setting OBP nvramrc rootmirror path
[...]
SDS: Installing GRUB on Alternate Boot Disk.
SDS: Running 001.sds.007.create_user_devices

Later on you will recognize the scripts for boot level z

Running additional install files for reboot z
SDS: Running 003.sds.001.attach_mirrors
SDS: Attach d12 to d10
SDS: Attach d22 to d20
SDS: Attach d12 to d10
d10: submirror d12 is attached
SDS: Attach d22 to d20
d20: submirror d22 is attached
SDS: Running 003.sds.002.attach_user_mirrors

With this mechanism, you can implement installation processes, that needs package or programm installations that need several boots to fullfill.

The end of the post installation

At the very end the init.d script is deleted together with the matching SMF service.

Using Jumpstart Flash

As I stated before, the installation mechanism of Jumpstart Flash is quite different from a normal installation. So I will start with a new template on a new server to demonstrate Jumpstart Flash.

Creating a flash archive

The first step to do a flash based install is the creation of a flash archive. Obviously you need an already installed system to create such an archive. To do so, I create a directory for the flar image at first:

bash-3.00# mkdir /flardir     
bash-3.00# flarcreate -S -n "togusa" -x /flardir -R / /flardir/togusa.flar
Full Flash
Checking integrity...
Integrity OK.
Running precreation scripts...
Precreation scripts done.
Creating the archive...
5144848 blocks
Archive creation complete.
Running postcreation scripts...
Postcreation scripts done.

Running pre-exit scripts...
Pre-exit scripts done.
bash-3.00#

The second command generates the flar image itself. With this command, I generate the flash archive togusa.flar in the directory /flar. The -x option excludes the directory /flardir from the flasharchive. The \verb-R= specifies that the flash archive should contain all filesystems descending to /. The -S flag bypasses the size checks.

# scp togusa.flar jmoekamp@192.168.10.1:/export/flar/togusa/togusa.flar

After the creation of the flash archive, you have to transmit it to a server. It doesn’t have to be the jumpstart server. it doesn’t even have to be an NFS server. It just have to be reachable with HTTP or NFS by the server you plan to install. In this example we will use the Jumpstart Server for this task, thus we will use a share on this system.

Don’t forget to share this directory via NFS:

# echo "share -F nfs -o anon=0,sec=sys,ro -d \"Installation Images\" /export/install" >> /etc/dfs/dfstab
# shareall

Preparing the template

Okay, we want to install our node ishikawa with the flash image of togusa. At first like with all jet installation we add a hostname to our /etc/hosts

# echo "192.168.10.11 ishikawa" >> /etc/hosts
\end|lstlisting}
Now we generate the template. We need only a small template for the basic installation.
\begin{lstlisting}
# make_template ishikawa flash
Adding product configuration information for 
        + base_config
        + flash
Updating base_config template specifics
Client template created in /opt/SUNWjet/Templates

Okay, we have to fill the templates with standard settings.

base_config_ClientArch=i86pc
base_config_ClientEther=08:00:27:DE:91:AB
base_config_ClientOS=sol10u5

The use operating system here isn’t important. You will not install this operating system. You will install the operating system contained in the flash archive.

Fill out the sysidsection of the system like with a normal system, you just need to fill the data to prevent the system from going interactive.

Now we get to the configuration of the flash install. You just define one or more locations of flash archives. When the installation in your flash archive contains all recommended patches you can save some time at the installation and skip the installation by using yes for the flash_skip_recommended_patches parameter.

flash_archive_locations="nfs://192.168.10.1/export/flar/togusa/togusa.flar"
flash_skip_recommended_patches="yes"

Now we have to create the Jumpstart environment for this client.

# /opt/SUNWjet/bin/make_client -f ishikawa
Gathering network information..
        Client: 192.168.10.11 (192.168.10.0/255.255.255.0)
        Server: 192.168.10.1 (192.168.10.0/255.255.255.0, SunOS)
Solaris: client_prevalidate
Creating Client directory for ishikawa
Solaris: client_build
Creating sysidcfg
Creating profile
Adding base_config specifics to client configuration
Adding flash specifics to client configuration
FLASH: Modifying client profile for flash install
FLASH: Removing package/cluster/usedisk entries from profile
Solaris: Configuring JumpStart boot for ishikawa
         Starting SMF services for JumpStart
Solaris: Configure PXE/grub build
         Adding install client
        Doing a TEXT based install
         Leaving the graphical device as the primary console
         Configuring ishikawa macro
         Using local dhcp server
         PXE/grub configuration complete
Running '/opt/SUNWjet/bin/check_client  ishikawa'
        Client: 192.168.10.11 (192.168.10.0/255.255.255.0)
        Server: 192.168.10.1 (192.168.10.0/255.255.255.0, SunOS)
Checking product base_config/solaris
Checking product flash
FLASH: Checking nfs://192.168.10.1/export/flar/togusa/togusa.flar
--------------------------------------------------------------
Check of client ishikawa 
-> Passed....

Please note the single line with FLASH: at the beginning. The JET framework checks for the availability of the flash archive. This prevents one of the most occurring problems with flash... a unaccessible flash archive at the installation.

When we look into the profile for ishikawa you will recognize, that all statements regarding cluster to install or similar stuff is removed. But there is a new statement. archive_location specifies the location of the flar image and install_type tells the system to do a flash install.

# cat profile 
#
# This is an automatically generated profile. Please modify the template.
#
# Created:      Sat May 24 12:50:20 CEST 2008
#
install_type    flash_install
archive_location        nfs://192.168.10.1/export/flar/togusa/togusa.flar
partitioning    explicit
#
# Disk layouts
#
filesys         rootdisk.s0     free    /
filesys         rootdisk.s1     256     swap
# pwd
/opt/SUNWjet/Clients/ishikawa
#

While Jumpstarting

When you look into the logfiles of your system, you will notice a big change. You won’t see a large amount of messages from the package installation. Instead of this you will just see the progress notifications of the extraction of the flar archive.

You will find this information in the middle of: /var/sadm/system/logs/install_log

[...]
Beginning Flash archive processing

Extracting archive: togusa
        Extracted    0.00 MB (  0% of 2512.13 MB archive)
[...]
        Extracted 2512.13 MB (100% of 2512.13 MB archive)
        Extraction complete
[...]

The JET framework augments this with some housekeeping tasks like deleting the Solaris Volume Manager configuration. As usual you can look into the /var/opt/sun/jet/finish.log logfile to find the related messages:

FLASH: Installing flash....
FLASH: Disabling /a/etc/lvm/mddb.cf -> /a/etc/lvm/mddb.cf.disabled
FLASH: Purging entries from /a/etc/lvm/md.tab
FLASH: Disabling mirrored_root_flag in /etc/system
FLASH: Cleanout crash dump area
FLASH: Clear out devfsadm files

Using Jumpstart Flash for System Recovery

The basic trick

My colleague Mario Beck showed it to me several years ago. The problem is the sysunconfig as it deletes the configuration information. The basic trick is simple. Before you create the flash archive, just do a backup of those files in one of the directories covered by the archive creation. Later on you can use this data to recover the configuration by copying those files in their original location.

Using an augmented Flash archive

The flash archive is just a cpio copy of the complete system minus explicitly excluded parts. Everything on the system is included in the flash archive, not just the OS[^54]. So we can easily rescue the personality of the system into the flash archive.

To ease up this task, I use the following script:

#!/bin/sh
mkdir -p /var/opt/recovery
mkdir -p /var/opt/recovery/etc
cp -p /etc/hosts /var/opt/recovery/etc
cp -p /etc/shadow /var/opt/recovery/etc
cp -p /etc/passwd /var/opt/recovery/etc
cp -p /etc/vfstab /var/opt/recovery/etc
cp -p /etc/nodename /var/opt/recovery/etc
cp -p /etc/hostname.* /var/opt/recovery/etc
cp -p /etc/dhcp.* /var/opt/recovery/etc
cp -p /etc/defaultdomain /var/opt/recovery/etc
cp -p /etc/TIMEZONE /var/opt/recovery/etc
mkdir -p /var/opt/recovery/etc/inet
cp -p /etc/inet/netmasks /var/opt/recovery/etc/inet/netmasks
cp -p /etc/defaultrouter /var/opt/recovery/etc/defaultrouter
mkdir -p /var/opt/recovery/var/ldap
cp -p /etc/.rootkey /var/opt/recovery/etc
cp -p /etc/resolv.conf /var/opt/recovery/etc
cp -p /etc/sysidcfg /var/opt/recovery/etc
cp -p /var/ldap/ldap_client_cache /var/opt/recovery/var/ldap/ldap_client_cache
cp -p /var/ldap/ldap_client_file /var/opt/recovery/var/ldap/ldap_client_file
cp -p /var/ldap/ldap_client_cred /var/opt/recovery/var/ldap/ldap_client_cred
cp -p /var/ldap/cachemgr.log /var/opt/recovery/var/ldap/cachemgr.log
mkdir -p /var/opt/recovery/var/nis
cp -p /var/nis/NIS_COLD_START /var/opt/recovery/var/nis
mkdir -p /var/opt/recovery/var/yp
cp -R -p /var/yp/* /var/opt/recovery/var/yp

When you create a flar archive after running this script, it will include this directory in the archive, thus a newly installed machine with this flash archive will have this directory as well. So you can use it to recover the old status of the system. The process is simple. Just do a cp -R /var/opt/recovery/* /. The process of jumpstarting the server is identical of doing a normal flash install.

Conclusion

JET and Jumpstart are incredible powerful tools to ease the installation of your Solaris systems. You can install your systems via network, configure and customize them. With tools like Jumpstart FLASH it’s easy to clone systems for large computing cluster.

Even when you have only a few systems, it’s a good practice to install you systems by a Jumpstart server. A bare metal recovery of your system is much easier, you can use a common template to setup your system and beside the hard disk space the jumpstart server needs only resources at the moment of the installation.

Do you want to learn more?

Documentation

Solaris 10 5/08 Installation Guide: Solaris Flash Archives (Creation and Installation)[^55]

Misc.

wikis.sun.com: JET Homepage[^56]

jet.maui.co.uk: JET resources [^57]