Software Self-Assembly

Given the goals and ideas described above, IPS introduces the general concept of software self-assembly: Any collection of installed software on a system should be able to build itself into a working configuration when that system is booted, by the time the packaging operation completes, or at software runtime.

Software self-assembly eliminates the need for install-time scripting in IPS. The software is responsible for its own configuration, rather than relying on the packaging system to perform that configuration on behalf of the software. Software self-assembly also enables the packaging system to safely operate on alternate images, such as boot environments that are not currently booted, or offline zone roots. In addition, since the self-assembly is performed only on the running image, the package developer does not need to cope with cross-version or cross-architecture runtime contexts.

Some operating system image preparation must be done before boot, and IPS manages this transparently. Image preparation includes updating boot blocks, preparing a boot archive (ramdisk), and, on some architectures, managing the menu of boot choices.

Tools for Software Self-Assembly

The following IPS features and characteristics facilitate software self-assembly.

Atomic Software Objects

An action is the atomic unit of software delivery in IPS. Each action delivers a single software object. That software object can be a file system object such as a file, directory, or link, or a more complex software construct such as a user, group, or driver. In the SVR4 packaging system, these more complex action types are handled by using class action scripts. In IPS, no scripting is required.

Actions, grouped together into packages, can be installed, updated, and removed from both live images and offline images.

Actions are discussed in more detail in Package Content: Actions.

Configuration Composition

Rather than maintaining complex configuration files that require extensive scripting to update each configuration file during packaging operations, IPS encourages delivering fragments of configuration files. The packaged application can access those fragments directly when reading its configuration, or the fragments can be assembled into the complete configuration file before reading the file.

The Oracle Solaris 11 user attributes database is a good example of fragmented configuration files. The /etc/user_attr configuration file is used to configure extended attributes for roles and users on the system. In Oracle Solaris 11, the /etc/user_attr file is used for local changes only. Complete configuration is read from the separate files delivered into the /etc/user_attr.d directory. Multiple packages deliver fragments of the complete configuration. No scripting is needed when fragments are installed, removed, or updated.

This method of composing configuration files requires that the software is written with composition in mind, which is not always possible.

An alternative way to support composition is for a service to treat the configuration file as volatile, and reassemble the configuration file when fragments of the configuration are installed, removed, or updated. Typically, this assembly is performed by an SMF service. Assembly by an SMF service is discussed further in the next item.

Actuators and SMF Services

An actuator is a tag applied to any action delivered by the packaging system that causes a system change when that action is installed, removed, or updated. These changes are typically implemented as SMF services.

SMF services can configure software directly, or SMF services can construct configuration files using data delivered in the SMF manifest or sourced from files installed on the system.

SMF services have a rich syntax to express dependencies. Each service runs only when all of its dependencies have been met.

Any service can add itself as a dependency on the svc:/milestone/self-assembly-complete:default SMF milestone. Once the booting operating system has reached this milestone, all self-assembly operations should be completed.

A special type of zone called an Immutable Zone is a zone that can be configured to have restricted write access to portions of its file system. See the discussion of file-mac-profile in the zonecfg(1M) man page. To complete self-assembly in this type of zone, boot the zone read/write. After the self-assembly-complete SMF milestone, the zone is automatically booted to the required file-mac-profile setting.

Examples of Software Self-Assembly in Oracle Solaris

The following examples describe packages that are delivered as part of Oracle Solaris.

Apache Web Server

A good example of self-assembly is in the Oracle Solaris package for Apache Web Server: pkg:/web/server/apache-22. This package ships with a default httpd.conf file that has an Include directive that references /etc/apache2/2.2/conf.d:

Include /etc/apache2/2.2/conf.d/*.conf

Another package can deliver a new .conf file to that directory and use a refresh_fmri actuator to automatically refresh the Apache instance whenever the package that delivers this new .conf file is installed, updated, or removed. Refreshing the Apache instance causes the web server to rebuild its configuration.

file etc/apache2/2.2/conf.d/custom.conf path=etc/apache2/2.2/conf.d/custom.conf \
    owner=root group=bin mode=0644 refresh_fmri=svc:/network/http:apache22

See Add Any Facets or Actuators That Are Needed and Chapter 7, Automating System Change as Part of Package Installation for information about how to use the refresh_fmri actuator.

Multiple Packages Delivering Configuration Fragments

Another example of self-assembly in the Oracle Solaris OS is shown in several packages that deliver content to the /etc/security/exec_attr.d/ directory.

In earlier Oracle Solaris releases, an SMF service merged the files delivered in exec_attr.d into a single database, /etc/security/exec_attr. In the Oracle Solaris 11 OS, libsecdb reads the fragments in exec_attr.d directly, eliminating the need for a separate service to perform the merge.

Other directories containing fragments of configuration in /etc/security are handled in a similar way.