Cover V10, I10



Introduction to SolarisTM Web Start Flash

John S. Howard

The Solaris 8 Operating Environment (OE) 4/01 release introduced the Solaris Web Start Flash extensions to the JumpStart framework. Web Start Flash extends the JumpStart framework by adding the mechanism to create a Flash archive, a system snapshot of the Solaris OE and all installed software, from a master machine. This archive can then be used to rapidly install client systems; this installation client may be any hardware platform capable of running the Solaris OE, including those hardware platforms typically referred to as "servers".

This article will explain how to identify the master machine as well as provide recommendations and examples of creating and administering Flash archives. This article assumes the reader has an understanding of basic Solaris OE or UNIX systems administration skills and a basic understanding of JumpStart technology and the Solaris OE installation procedure.

The JumpStart Framework

JumpStart technology is Sun Microsystems' mechanism for controlling, performing, and automating network-based installations of the Solaris OE. The JumpStart framework provides a mechanism to help automate and control installation of the Solaris OE. By automating installation of the Solaris OE, the chances for human error or configuration errors during installation may be greatly reduced. This also helps ensure the consistency of system installation and adherence to site-standards throughout your data center, as well as providing documentation as to exactly how the system was installed.

The Flash facility extends the traditional JumpStart installation framework by adding the mechanism to create a system archive, a snapshot of an installed system, and install the Solaris OE from that archive.

A traditional JumpStart software installation is performed by using the JumpStart profile to specify individual software packages or software package clusters (a predefined set of software packages) to be installed. The suninstall program, using the pkgadd mechanism, then installs the specified packages sequentially. As the pkgadd mechanism needs to update the installed package database as well as relocate files, this may become a time-consuming operation.

The Flash Archive

Flash provides a mechanism by which a specific or reference installation of the Solaris OE is archived. That Flash archive can then be used to install the Solaris OE. The reference installation is created from the on-disk Solaris OE and includes all installed software. This system on which the archive is created is designated as the master machine. The reference installation can be a Solaris OE installed by any means such as a JumpStart software installation, installation from CD, an interactive installation, etc.

After identifying the master machine, the reference installation is captured in a Flash archive. This archive (a central feature of Flash) is essentially a point-in-time snapshot of the Solaris OE, software patches, and applications on the master machine. The Flash extensions add the ability to install the archive from an NFS server or an HTTP server, in addition to installation from a traditional JumpStart server. The archive also can be accessed from a disk device (including CD-ROM) or tape device, local to the installation client. The Flash archive is transmitted over the network to the installation client and written to the disk. After the archive is written to the installation client's disk, any necessary archive modifications are performed. For example, configuration files such as /etc/nsswitch.conf on the installation client may need to vary from the master machine. The Flash mechanism enables automation of modifications, allowing for differences in kernel architecture or device differences between the master machine and the installation client to be automatically resolved.

Additionally, Flash allows for partitioning differences between the master machine and the installation client to be resolved automatically. For example, if the Flash archive was created on a system with a single root (/) partition and the installation client has separate / and /var partitions, the Flash archive automatically customizes itself to the installation client. However, the installation client partitioning must be correctly specified in the JumpStart profile.

It is important to note that, unless explicitly excluded, the Flash archive will contain all software installed on the master machine. For example, if a flash archive is created from a database server, that archive contains all software that was installed on that database server -- including the database server software. This feature makes Flash a powerful tool for deploying complex server configurations. A complex system architecture only needs to be implemented and configured once and then a Flash archive created; all subsequent system installations from that Flash archive will be identical. For systems such as database servers, the Flash archive should be created before the system goes into production. For example, a database server or LDAP server should have its archive created after the database management software has been installed, but before the databases have been created and populated.

Software that stores configuration information outside of a UNIX filesystem may not be correctly configured on the Flash installed client. For example, logical volume management software such as Veritas Volume Manager (VxVM) or Solstice DiskSuite software store meta-information (such as logical volume layout and RAID configuration information) in raw partitions, outside of a filesystem. Installing a system from a Flash archive created on a master machine that was using VxVM with an encapsulated and mirrored boot disk is not possible. Since the flash archive creation does not (and can not) access the meta-information in the VxVM private regions, any subsequent installation from that Flash archive would be incomplete and unbootable.

To incorporate such software in a Flash archive, the archive must be created on the master machine after all software has been installed, but before the software has been configured. Again using the example of a master machine with a VxVM encapsulated and mirrored boot disk, the Flash archive should be created after the Solaris OE is installed and VxVM packages have been added and before executing vxinstall to configure the VxVM software. The VxVM configuration of the installation client, including encapsulation and mirroring of the boot disk, can be performed from a finish script after the Flash archive is installed.

The Flash archive is a snapshot of a system and as such, all specified files on that system are included in the archive. If a Flash archive is created from a system in use, some files need to be cleaned up or zeroed out after the Flash archive is installed. Examples of these types of files include log files, such as those found in /var/adm, and any files in the /var/tmp directory. Log files can be easily zeroed out from a finish script after installation. In the case of temporary directories, such as the /var/tmp directory, it is recommend to exclude those directories when the Flash archive is created.

It is important to note that an initial installation must be specified when performing a Flash installation. Flash cannot be used to upgrade a system.

Installation of the Solaris OE via a Flash archive can be dramatically faster than with other mechanisms, depending on factors such as network traffic and disk speeds. This is partly because Flash does not need to individually install each software package and update the installed package database. Since the Flash archive contains the installed packages and an accurate package database, the archive is essentially written to the installation disk as fast as the data can be taken off the network.

Identifying the Master Machine

Before performing a Flash installation, a master machine must be identified. The master machine is the system that serves as the template to be copied onto the installation clients. All software and files on the master machine, unless specifically excluded, become a part of the Flash archive and are installed on the client.

Usually, the master machine is not the JumpStart server. However, the JumpStart server is an ideal system to act as a repository for Flash archives.

Each system type in your data center should have a corresponding Flash archive created to install additional systems of that type. For example, identify a reference configuration for each class of database server, Web server, backup server, etc., then create Flash archives of those systems to use when the new systems need to be deployed.

Store Flash archives offsite, on tape or on CD-ROM, to prepare for business continuity in the event of a disaster. You can then use these Flash archives at a remote site or disaster recovery site to rapidly deploy software-identical, but not necessarily hardware-identical, replacement systems.

Creating and Administering Archives

The following flarcreate command creates an archive, named S8-web.archive, of a Solaris 8 OE 4/01 production Web server (excluding the /var/tmp directory) with an archive creator string of j.s.howard@Sun.COM:

www06# pwd
www06#  flarcreate -n "Solaris 8 web server image" \
> -a "j.s.howard@Sun.COM" \
> -R / \
> -x /var/tmp \
> /var/tmp/FlashArchives/S8-web.archive
Determining which filesystems will be included in the archive...
Determining the size of the archive...
The archive will be approximately 446.45MB.
Creating the archive...
Archive creation complete.
The -R option specifies to recursively descend from the specified directory, and the -x option excludes the specified directory. See the flarcreate(1M) man page for details on these and other options.

Flash archives can be accessed via NFS or HTTP. Additionally, Flash archives can be written to disk, CD, or tape and subsequently accessed from the disk, CD, or tape drive local to the client, during installation.

Flash archives can be compressed by specifying the -c option to the flarcreate command. Compressed archives are automatically uncompressed after being transferred to the installation client, prior to installation. See the flarcreate(1M) man page for additional details.

Use the flar command to extract information from a specified archive. For example, to determine how an archive was created:

www06# flar -i S8-web.archive
content_name=Solaris 8 workgroup server image
The flar command also provides options to split or combine archives. Consult the flar(1M) man page for additional details on archive usage.

The JumpStart Profile

The JumpStart profile in the configuration file is used to specify software configuration information to the installation client as well as the type of installation to be performed. When using Flash, only the following profile keywords are valid:

  • install_type
  • partitioning -- Only the keyword values of explicit or existing must be used.
  • filesys -- The keyword value of auto must not be used.
  • fdisk -- This is valid for Intel Architecture only.

The following example profile specifies that Flash is used as the installation type, flash_install. Additionally, the profile instructs that the Flash archive is accessed via NFS, from the location specified by the archive_location keyword:

install_type    flash_install
archive_location nfs:// \
partitioning    explicit
# 4GB / and 1GB swap on a 18GB disk
filesys         rootdisk.s0     450:1786        /
filesys         rootdisk.s1     1:449           swap
Since name_service=NONE is specified in the following sysidcfg file, an IP address is used for the archive_location in the profile.

The rules entry used for this example is:

model SUNW,UltraSPARC-IIi-cEngine \
        - \
        Profiles/S8-webserver-Flash.profile \
The sysidcfg file used is:

network_interface=primary {netmask=
A root password is specified in the sysidcfg file. This specification overrides the root password contained in /etc/shadow within the Flash archive.

After you have created or edited the above files, verify the rules file. Be certain to use the check script from the Solaris 8 OE 4/01 CD-ROM and verify the rules file:

server01# cd /jumpstart
server01# ./check
Validating rules...
Validating profile Profiles/S8-webserver-Flash.profile...
The custom JumpStart configuration is ok.
The finish script used for this example is:

# EE_Lab-Flash.fin
# Finish script for default EE_Lab setup, Jumpstart Flash
# clean up after flash archive install
for i in /a/var/adm/messages* /a/var/adm/utmpx \
         /a/var/adm/wtmpx /a/var/adm/lastlog
    cp /dev/null ${i}
mkdir /a/var/tmp
chown root:sys /a/var/tmp
chmod 1777 /a/var/tmp
The /var/tmp directory needs to be created by the finish script because it was excluded when the archive was created with the flarcreate command.

To perform the installation, the OpenBoot Prom (OBP) command is executed on the installation client:

{3} ok boot net - install

This article has introduced the Solaris Web Start Flash facility, available with Solaris 8 OE 4/01. A Flash overview, the concepts of a Flash archive, and a master machine were presented. The use of Flash archives for business continuity was also recommended.

This article also presented the use of the flarcreate command to create Flash archives and the flar command to administer Flash archives. Additionally, the changes to the JumpStart profile necessary to support Flash installations were presented. Those changes include the ability to use NFS, HTTP, or devices local to the installation client as locations of the Flash archive during installation. Finally, an example of creating a Flash archive and finish script for a Web server was detailed.

Portions of this article may have been excerpted from the author's book JumpStart Technology: Effective Use in the Solaris Operating Environment.

2001 Sun Microsystems, Inc. All rights reserved.

Sun, Sun Microsystems, the Sun Logo, Solaris, JumpStart, and Solstice DiskSuite are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd.

John S. Howard is a Senior Staff Engineer with Sun's Enterprise Engineering group. John joined Sun in 1995 and has 19 years experience in high-end datacenter implementations, including developing tools and procedures to minimize mean time to repair (MTTR) and recovery for Sun Clusters and StarFireTM systems. John may be reached by email at j.s.howard@Sun.COM.