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.
The following IPS features and characteristics facilitate software self-assembly.
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 device 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. A live image is the image mounted at / of the active, running boot environment of the current zone.
Actions are discussed in more detail in Package Content: Actions.
Rather than using scripting to update configuration files during packaging operations, IPS encourages delivering fragments of configuration files. The fragments can be used in the following ways:
The packaged application can be written to be aware of the file fragments. The application can access the configuration file fragments directly when reading its configuration, or the application can assemble the fragments into the complete configuration file before reading the file.
An SMF service can reassemble the configuration file whenever fragments of the configuration are installed, removed, or updated.
See Assembling a Custom File from Fragment Files for an example of creating a package that delivers a service that assembles configuration files.
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. See Automating System Change as Part of Package Installation for more information about actuators.
SMF services can configure software directly, or SMF services can construct configuration files using data delivered in the SMF manifest or in files installed on the system.
SMF services have a rich syntax to express dependencies. Each service runs only when all of its required dependencies have been satisfied. See Managing System Services in Oracle Solaris 11.3 for more information about SMF services.
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, as described in the -W and -w options of the zoneadm boot command in the zoneadm (1M) man page. After the self-assembly-complete SMF milestone is online, the zone is automatically booted to the required file-mac-profile setting.
The following examples describe packages that are delivered as part of Oracle Solaris.
The Oracle Solaris package for Apache Web Server, pkg:/web/server/apache-22, delivers an httpd.conf file that contains the following Include directive referencing configuration files in the /etc/apache2/2.2/conf.d directory:
To apply custom configuration, you can create one or more packages that deliver custom .conf files to that conf.d directory and use a refresh_fmri actuator to automatically refresh the Apache instance whenever a package that delivers a new .conf file is installed, updated, or removed.
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 Automating System Change as Part of Package Installation for information about how to use the refresh_fmri actuator.
Refreshing the Apache service instance causes the web server to rebuild its configuration. To verify this, use the following command to show the name of the method that runs when the Apache service instance is refreshed:
$ svcprop -p refresh/exec http:apache22 /lib/svc/method/http-apache22\ refresh
A look at the method shows that refreshing the http:apache22 instance restarts the Apache httpd daemon by invoking apachectl with the graceful command.
User attributes are configured in /etc/user_attr and in additional configuration files in /etc/user_attr.d.
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. For example, /etc/user_attr.d/core-os is delivered by the system/core-os package, and /etc/user_attr.d/ikev2-daemon is delivered by the system/network/ike package.
No services are restarted or refreshed as a result of installing these configuration files. No scripting is needed when these files are installed, uninstalled, or updated. The files in /etc/user_attr.d are composed by the name service cache daemon, nscd. The behavior of the nscd daemon is managed by the svc:/system/name-service/cache service.
$ svcs -p cache STATE STIME FMRI online 15:54:24 svc:/system/name-service/cache:default 15:54:24 100698 nscd
The name service cache daemon provides configuration composition for most name service requests in the same way as described for user_attr. See the nscd(1M) man page.
The /etc/security/exec_attr.d/ directory stores security configuration files.
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 Oracle Solaris 11, functions in the security attributes database library, libsecdb, read the fragments in exec_attr.d directly, eliminating the need for a service to perform the merge.
Other directories in /etc/security that contain fragments of configuration, such as auth_attr.d and prof_attr.d, are handled in a similar way.