2573N/A.. The contents of this file are subject to the terms of the
2573N/A Common Development and Distribution License (the "License").
2573N/A You may not use this file except in compliance with the License.
2573N/A See the License for the specific language governing permissions
2573N/A and limitations under the License.
2573N/A.. When distributing Covered Code, include this CDDL HEADER in each
2573N/A If applicable, add the following below this CDDL HEADER, with the
2573N/A fields enclosed by brackets "[]" replaced with your own identifying
2573N/A information: Portions Copyright [yyyy] [name of copyright owner]
2573N/A.. Copyright (c) 2011, Oracle
and/or its affiliates. All rights reserved.
2585N/AThis chapter discusses IPS design goals and concepts, and discusses
2585N/Asome of the implications of those choices.
2585N/AIPS is designed to eliminate some long-standing issues with previous
2585N/Asoftware distribution, installation and maintenance mechanisms
2585N/Athat have caused significant problems for Oracle Solaris customers,
2585N/APrinciple IPS design concepts and goals include:
2585N/A* Minimize planned downtime by making software update possible
2585N/A while machines are in production.
2585N/A* Minimize unplanned downtime by supporting quick reboot to
2585N/A known working software configurations.
2585N/A* Automate, as much as possible, the installation of new software or
2525N/A updates to existing software.
2525N/A* Resolve the difficulties with ever-increasing software size and
2525N/A limited distribution media space.
2585N/A* Ensure that it is possible to determine whether or not a package is
2585N/A correctly installed as defined by the author (publisher) of the
2585N/A package; such a check should not be spoofable.
2585N/A* Incorporate mechanisms to allow for the easy virtualization of Oracle Solaris
2585N/A at a variety of levels - and zones in particular.
2585N/A* Allow other software publishers (ISVs and end-users themselves) to
2585N/A create and publish packages using IPS.
2585N/AThese goals led fairly directly to the following ideas:
2585N/A* Leverage ZFS snapshot and clone facilities to dynamically create
2585N/A boot environments on an as-needed basis.
2585N/A * Oracle Solaris 11 requires ZFS as the root file system; zone
2585N/A file systems need to be on ZFS as well.
2585N/A * Users can create as many boot environments as desired.
2585N/A * The packaging system can automatically create boot environments
2585N/A on an as-needed basis, either for backup purposes prior to
2585N/A modifying the running system, or for installation of a new
2585N/A* Eliminate duplicated mechanisms and code used to install, patch
2585N/A This results in several significant changes to the way Oracle Solaris
2585N/A is maintained. In particular:
2585N/A * All OS software updates and patching are done directly with
2585N/A * Any time a new package is installed, it is already exactly
2585N/A* The requirement for unspoofable verification of package installation
2585N/A has interesting consequences:
2585N/A * If a package needs to support installation in multiple ways, those ways
2585N/A must be specified by the developer, so the verification process could
2525N/A * Scripting is inherently unverifiable since we cannot determine the
2585N/A intent of the script writer. This, along with other issues
2585N/A mentioned later, led to the elimination of scripting during
2585N/A * There can be no mechanism for the package to edit its own manifest,
2585N/A since verification is then impossible.
2585N/A * If the administrator wants to install a package in a manner
2525N/A incompatible with the original publisher's definition, we should
2585N/A enable the administrator to easily republish the package he wants
2585N/A to alter so that the scope of his changes are clear, not lost
2585N/A across upgrades, and can be verified in the same manner as the
2585N/A* The need to avoid size restrictions led to a software repository
2585N/A model, accessed using several different methods. Different
2585N/A repository sources can be composited to provide a complete set of
2585N/A packages, and repositories can be distributed as a single file. In
2585N/A this manner, no single media is ever required to contain all the
2585N/A operations, tools are provided to copy and merge repositories.
2585N/A* The desire to enable multiple (possibly competing) software
2585N/A publishers led us to driving all the packaging metadata into the
2585N/A packages themselves, so no master database of all packages,
2585N/A dependencies, etc. exists. A catalog of available packages from a
2585N/A software publisher is part of the repository for performance
2585N/A reasons, but it can be regenerated from the data contained in the
2585N/AGiven the goals and ideas above, IPS introduces the general concept of *software
2585N/Aself-assembly*: Any collection of installed software on a system should be able
2585N/Ato build itself into a working configuration when that system is booted, by the
2573N/Atime the packaging operation completes, or at software runtime.
2585N/ASoftware self-assembly eliminates the need for install-time scripting in IPS. The
2585N/Asoftware is responsible for its own configuration rather than relying on the
2585N/Apackaging system to perform that configuration on behalf of the software.
2585N/ASoftware self-assembly also enables the packaging system to safely operate on
2585N/Aalternate images, such as boot environments that are not currently booted, or
2585N/Aoffline zone roots. In addition, since the self-assembly is performed only on
2585N/Athe running image, the package developer does not need to cope with
2585N/Across-version or cross-architecture run-time contexts.
2585N/AThere are obviously some aspects of preparing an operating system image that
2585N/Amust be done before boot, and IPS manages this transparently. These items
2585N/Ainclude updating boot blocks, preparing a boot archive (ramdisk), and on some
2585N/Aarchitectures, managing the menu of boot choices.
2573N/ASeveral idioms are employed to facilitate software self-assembly:
2585N/A *Actions* are the atomic units of software delivery in IPS. Each action
2585N/A delivers a single software object - either a file system object, such as a
2585N/A *file*, *directory* or *link*, or a more complex software construct, such
2585N/A as a *user*, *group* or *driver*. These more complex action types,
2585N/A previously handled by SVR4 class action scripts in older Oracle Solaris
2585N/A releases no longer require scripting.
2585N/A Actions, grouped together into *packages*, can be installed, updated and
2585N/A removed from both live images as well as offline images.
2585N/A While IPS allows for the set of known action types to be extended in the
2585N/A packaging system, during development we have found that the action types
2585N/A delivered at present are sufficient for all packaged software in
2585N/A Oracle Solaris. It is not expected that package developers will need to
2585N/A Actions are discussed in more detail in *Chapter 3*.
2585N/A Rather than maintaining complex configuration files, that require
2585N/A extensive scripting in order to update each configuration file during
2585N/A packaging operations, IPS encourages package authors to deliver fragments
2585N/A of the complete configuration file.
2585N/A The packaged application either accesses those fragments directly when
2585N/A reading its configuration, or the fragments can be assembled into the
2585N/A complete configuration file before reading it.
2585N/A by Oracle Solaris to configure extended attributes for roles and users on
2585N/A This file is now used for local changes only, and Oracle Solaris has been
2585N/A modified to read its complete configuration from the separate files
2585N/A deliver fragments of the complete configuration, with no additional
2585N/A scripting needed when fragments are installed, removed or updated.
2585N/A Obviously this requires that the software is written with composition in
2585N/A mind, which isn't always possible.
2585N/A An alternative way to support the concept of composition, is for a service
2585N/A to treat the configuration file as volatile, and re-assemble it when when
2585N/A fragments of the configuration are installed, removed, or updated.
2585N/A Typically, this assembly is performed by an SMF service. We will discuss
2585N/A this idiom in the next item.
2585N/A * **Actuators & SMF services**
2585N/A An *actuator* is a tag applied to any *action* delivered by the packaging
2585N/A system that causes a system change when that action is installed, removed,
2585N/A These changes are typically implemented as SMF services.
2585N/A We can create SMF services that are responsible for configuring software
2585N/A directly, or constructing configuration files using data delivered in the
2585N/A SMF manifest or sourced from files installed on the system.
2585N/A Since SMF services have a rich syntax to express dependencies, we can
2585N/A ensure that each service only runs when all of its dependencies have been
2585N/A Oracle Solaris includes an SMF milestone,
2585N/A service can add itself as a dependency. The intention is that once the
2585N/A booting operating system has reached this milestone, all self-assembly
2585N/A Oracle Solaris supports a special type of zone called an |Immutable Zone|,
2585N/A where the zone can be configured to have restricted write-access to
2585N/A portions of it's file system (see the discussion of ``file-mac-profile``
2585N/A in the |zonecfg| manual page)
2585N/A In these types of zones, to complete self-assembly, they are first booted
2585N/A which they are automatically booted to the required ``file-mac-profile``
2573N/AMany of the good packaging criteria present trade-offs among themselves. It
2573N/Awill often be difficult to satisfy all requirements equally. These criteria are
2573N/Apresented in order of importance; however, this sequence is meant to serve as a
2573N/Aflexible guide depending on the circumstances. Although each of these criteria
2585N/Ais important, it is up to you to optimize these requirements to
2585N/Aproduce a good set of packages.
2585N/AOracle Solaris uses a hierarchical naming strategy for IPS packages. Wherever
2585N/Apossible, design your package names to fit into the same scheme. Try to keep the
2585N/Alast part of your package name reasonably unique such that ``pkg install
2585N/A<name>`` doesn't report conflicts.
2573N/AOptimize for Client-Server Configurations
2573N/A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2585N/AYou should consider the various patterns of software use (client and
2585N/Aserver) when laying out packages. Good packaging design divides the
2585N/Aaffected files to optimize installation of each configuration
2585N/Atype. For example, for a network protocol implementation, it should be
2585N/Apossible to install the client without necessarily installing the
2585N/Aserver. Note that if client and server share implementation
2585N/Acomponents, a base package containing the shared bits is necessary.
2573N/APackage by Functional Boundaries
2573N/A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2573N/APackages should be self-contained and distinctly identified with a set of
2585N/Afunctionality. For example, a package containing ZFS should contain all ZFS
2585N/Autilities and be limited to only ZFS binaries.
2573N/APackages should be organized from a customer's point of view into functional
2573N/APackage Along License or Royalty Boundaries
2573N/A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2573N/APut code that requires royalty payments due to contractual agreements or
2573N/Athat has distinct software license terms in a dedicated package or group
2585N/Aof packages. Do not disperse the code into more packages than
2585N/APackages that overlap (deliver differing content to the same
2585N/Afile system locations, for example) cannot be installed at the same
2585N/Atime. Since this error might not be caught until final planning for
2585N/Ainstallation, it can provide a poor user experience, though
2585N/A|pkglint| can help to detect this during the package authoring process.
2585N/AIf the package content must differ, declare an exclude dependency so that
2585N/AIPS will understand that these packages are not to be installed together.
2585N/AA package represents (modulo *facets*, discussed later) a single unit
2585N/Aof software, and is either installed or not installed. Packages that are
2585N/Aalways installed together should be combined. Since IPS downloads only
2585N/Achanged files on update, even large packages update quickly if change is