JavaScript is required to for searching.
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
search filter icon
search icon

Document Information


1.  IPS Design Goals, Concepts, and Terminology

IPS Design Goals

Software Self-Assembly

Tools for Software Self-Assembly

Atomic Software Objects

Configuration Composition

Actuators and SMF Services

Examples of Software Self-Assembly in Oracle Solaris

Apache Web Server

Multiple Packages Delivering Configuration Fragments

IPS Package Lifecycle

IPS Terminology and Components

Installable Image

Package Identifier: FMRI

Package Publisher

Package Name

Package Version

Package Content: Actions

File Actions

Directory Actions

Link Actions

Hardlink Actions

Set Actions

Driver Actions

Depend Actions

License Actions

Legacy Actions

Signature Actions

User Actions

Group Actions

Package Repository

2.  Packaging Software With IPS

3.  Installing, Removing, and Updating Software Packages

4.  Specifying Package Dependencies

5.  Allowing Variations

6.  Modifying Package Manifests Programmatically

7.  Automating System Change as Part of Package Installation

8.  Advanced Topics For Package Updating

9.  Signing IPS Packages

10.  Handling Non-Global Zones

11.  Modifying Published Packages

A.  Classifying Packages

B.  How IPS Is Used To Package the Oracle Solaris OS

IPS Design Goals

IPS is designed to eliminate some long-standing issues with previous software distribution, installation, and maintenance mechanisms that have caused significant problems for Oracle Solaris customers, developers, maintainers, and ISVs.

Principle IPS design goals include:

Minimize downtime.

Minimize planned downtime by making software update possible while machines are in production.

Minimize unplanned downtime by supporting quick reboot to known working software configurations.

Automate installation and update.

Automate, as much as possible, the installation of new software and updates to existing software.

Reduce media requirement.

Resolve the difficulties with ever-increasing software size and limited distribution media space.

Verify correct software installation.

Ensure that it is possible to determine whether a package is correctly installed as defined by the author (publisher) of the package. Such a check should not be spoofable.

Enable easy virtualization.

Incorporate mechanisms to allow for the easy virtualization of Oracle Solaris at a variety of levels, in particular using zones.

Simplify upgrade.

Reduce the effort required to generate patches or upgrades for existing systems.

Enable easy package creation.

Enable other software publishers (ISVs and end-users themselves) to easily create and publish packages for Oracle Solaris.

These goals led to the following ideas:

Create boot environments as needed.

Leverage ZFS snapshot and clone facilities to dynamically create boot environments on an as-needed basis.

  • Since Oracle Solaris 11 requires ZFS as the root file system, zone file systems need to be on ZFS as well.

  • Users can create as many boot environments as desired.

  • IPS can automatically create boot environments on an as-needed basis, either for backup purposes prior to modifying the running system, or for installation of a new version of the OS.

Unify installation, patch, and update.

Eliminate duplicated mechanisms and code used to install, patch, and update.

This idea results in several significant changes to the way Oracle Solaris is maintained, including the following important examples:

  • All OS software updates and patching are done directly with IPS.

  • Any time a new package is installed, it is already exactly at the correct version.

Minimize opportunities to install incorrectly.

The requirement for unspoofable verification of package installation has the following consequences:

  • If a package needs to support installation in multiple ways, those ways must be specified by the developer so that the verification process can take this into account.

  • Scripting is inherently unverifiable since the packaging system cannot determine the intent of the script writer. This, along with other issues discussed later, led to the elimination of scripting during packaging operations.

  • A package cannot have any mechanism to edit its own manifest, since verification is then impossible.

  • If the administrator wants to install a package in a manner incompatible with the original publisher's definition, the packaging system should enable the administrator to easily republish the package he wants to alter so that the scope of his changes is clear, not lost across upgrades, and can be verified in the same manner as the original package.

Provide software repositories.

The need to avoid size restrictions led to a software repository model, accessed using several different methods. Different repository sources can be composited to provide a complete set of packages, and repositories can be distributed as a single file. In this manner, no single media is ever required to contain all the available software. To support disconnected or firewalled operations, tools are provided to copy and merge repositories.

Include metadata as part of the software package.

The desire to enable multiple (possibly competing) software publishers led to the decision to store all the packaging metadata in the packages themselves: No master database exists for information such as all packages and dependencies. A catalog of available packages from a software publisher is part of the repository for performance reasons, but the catalog can also be regenerated from the data contained in the packages.