Skip Navigation Links | |
Exit Print View | |
Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. IPS Design Goals, Concepts, and Terminology
2. Packaging Software With IPS
3. Installing, Removing, and Updating Software Packages
4. Specifying Package Dependencies
6. Modifying Package Manifests Programmatically
7. Automating System Change as Part of Package Installation
8. Advanced Topics For Package Updating
Avoiding Conflicting Package Content
Renaming, Merging and Splitting Packages
Preserving Editable Files that Migrate
Moving Unpackaged Contents on Directory Removal or Rename
Delivering Multiple Implementations of an Application
Some files delivered to a boot environments (BE) must be shared across BEs to preserve normal system operation in an environment with multiple BEs. In general, IPS does not support delivery of content that is shared across BEs. Such shared content updated in one BE might not meet the requirements of other BEs. This section describes how you can deliver content that is shared across BEs.
The following directories are already shared across BEs by IPS:
/var/audit /var/cores /var/crash /var/mail
Within each BE, these directories are symbolic links to the following shared directories:
/var/share/audit /var/share/cores /var/share/crash /var/share/mail
These shared directories are in the VARSHARE dataset, which is a shared dataset mounted at /var/share.
If other data needs to be shared across BEs but is delivered in an IPS package as unshared, administrators are likely to place such data on separate datasets or on remote file servers. However, creating per-directory datasets means creating many datasets per zone, which is not desirable.
Instead, use the following procedure to create a package that delivers a shared dataset, or to modify a package to share content that was previously delivered as unshared. IPS supports update from an older version of a package that did not share content to a newer version of the same package that does share content across BEs.
This procedure describes how to design a package that must deliver content that is shared across BEs.
To share data across BEs, use a shared dataset, mounted into the BE during boot, with symbolic links from locations inside the BE pointing into that shared dataset. Inside the BE, deliver basic directory structure to a staging directory. Provide an SMF service that moves the content staged inside the BE to the shared dataset during boot, and provide an actuator to require a reboot.
In your package, deliver a staging area for shared content. For example, you might deliver a directory named .migrate.
Deliver subdirectories into the .migrate directory that provide the directory structure you want in the shared dataset.
Deliver files to the directory structure in the staging area as needed. Other file system objects such as links cannot be shared.
If the content delivered to the staging area was previously delivered as unshared content, use a salvage-from attribute on the new dir or file action. In the following example, content that was previously delivered to /opt/myapplication/logs will now be delivered to a dataset that is shared across BEs. The staging area for this shared dataset is /opt/.migrate.
The following action was previously delivered:
dir path=opt/myapplication/logs owner=daemon group=daemon mode=0755
The following action is the new action for the directory that will be shared:
dir path=opt/.migrate/myapplication/logs owner=daemon group=daemon \ mode=0755 reboot-needed=true salvage-from=/opt/myapplication/logs
The salvage-from attribute is also discussed in Moving Unpackaged Contents on Directory Removal or Rename.
During boot, a script can be run as part of an SMF method script to move file content from the staging directory into the shared dataset. This script must do the following steps:
The following command in the SMF method script creates the dataset rpool/OPTSHARE mounted at /opt/share. This dataset could also be used by other shared content from /opt. The script should use zfs list to test whether the dataset already exists.
zfs create -o mountpoint=/opt/share rpool/OPTSHARE
In the shared dataset, recreate any parts of the directory structure defined under the staging directory in the BE that do not already exist.
Move the file content from the staging directory to the shared dataset.
The following action creates a symbolic link from the previously packaged directory to the shared directory in /opt/share that will be created by the script when the system reboots:
link path=opt/myapplication/logs target=../../opt/share/myapplication/logs
A reboot-needed actuator is required for these directory entries in order to properly support updates of Immutable Zones mentioned in Software Self-Assembly. Immutable Zones boot as far as the svc:/milestone/self-assembly-complete:default milestone in read/write mode if self-assembly is required, before rebooting read-only. See the file-mac-profile property in the zonecfg(1M) man page for more information.
On reboot, the SMF service moves any new and salvaged directory content into the shared dataset. The symbolic links from /opt/myapplication point into that shared dataset.