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 the design goals and concepts behind IPS, and
2585N/Alays out some of the implications of those choices.
2585N/AWe designed IPS to resolve some long-standing issues with existing
2585N/ASolaris mechanisms for software delivery, installation and maintenance
2585N/Athat had caused significant problems for both Solaris customers and
2585N/A* Minimize planned downtime by making software update possible while
2585N/A in production; minimize unplanned downtime by making it simple and
2585N/A quick to revert to known working software configurations.
2585N/A* Automate, as much as possible, the installation of new software, or
2585N/A updates to existing software.
2585N/A* Resolve the difficulties with ever-increasing software size and
2525N/A limited distribution media space.
2525N/A* Provide means for cryptographic verification of correct software
2585N/A* Incorporate mechanisms to allow easy virtualization of Solaris at a
2585N/A variety of levels - and zones in particular.
2525N/A* Allow other software publishers (ISVs) to publish packages using
2525N/AThese requirements led fairly directly to the following ideas and
2585N/A* Leverage ZFS directly to very quickly create new filesystems that
2585N/A are clones of existing ones. This meant that Solaris 11 requires
2585N/A ZFS as the root filesystem, and allowed us to create as many boot
2525N/A environments as the user desired. The same mechanism would be used
2585N/A* As much as possible, we wanted to eliminate duplicated mechanisms
2585N/A and code used to install, patch and update Solaris. We decided to
2585N/A make the packaging system responsible for the whole software
2585N/A lifecycle - publication, installation, updating and removal.
2585N/A* The requirement to verify the installation of a package had several
2585N/A * If a package could be correctly installed in multiple ways, those ways
2585N/A should be specified by the developer, so the verification process could
2585N/A * Scripting is inherently unverifiable since we cannot determine the
2585N/A intent of the script writer. This, along with other issues mentioned
2585N/A later, led to the elimination of scripting during packaging operations.
2585N/A * If the administrator wishes to install a package in a manner
2585N/A incompatible with the original publisher's definition, we should
2525N/A enable the administrator to easily republish the package he wishes
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
2585N/A* Avoiding size restrictions led to a software repository model,
2525N/A accessed using several different methods. Different repository
2525N/A sources can be composited to provide a complete set of packages, and
2585N/A repositories can be distributed as a single file. In this manner,
2585N/A no single media was ever required to contain all the available
2585N/A tools are provided to copy and merge repositories.
2525N/A* Supporting multiple (possibly competing) software publishers led us
2525N/A to driving all the packaging metadata into the packages themselves,
2525N/A so no master database of all packages, dependencies, etc. exists. A
2585N/A catalog of available packages from a software publisher is part of
2585N/A the repository for performance reasons, but it can be regenerated
2585N/A from the data contained in the packages at will.
2585N/AGiven the goals and ideas we have discussed, IPS introduces the general concept
2585N/Aof *software self-assembly*.
2585N/AThat is, any collection of installed software on a system should be able to
2585N/Abuild itself into a working configuration when that system is booted or by the
2585N/Atime the packaging operation completes, or at software runtime.
2585N/AThis obviates the need for install-time scripting in IPS, making the
2585N/Asoftware responsible for its own configuration, rather than relying on the
2585N/Apackaging system to perform that configuration on behalf of the software. It
2525N/Aalso allows the packaging system to safely operate on alternate images, such as
2585N/Aspare boot environments, or offline zone roots.
2585N/ASeveral idioms are employed to facilitate software self-assembly:
2573N/A *Actions* are the atomic units of software delivery in IPS. Each action
2573N/A delivers a single software object - either a filesystem object, such as a
2573N/A *file*, *directory* or *link*, or a more complex software construct, such as a
2573N/A *user*, *group* or *driver*. These more complex action types, previously
2585N/A handled by SVR4 class action scripts in older Solaris releases no longer
2573N/A Actions, grouped together into *packages*, can be installed, updated and
2573N/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 Solaris.
2585N/A It is not expected that package developers will need to create new action
2585N/A We will discuss actions in more detail in *Chapter 3*.
2573N/A Rather than maintaining complex configuration files, requiring extensive
2573N/A scripting in order to update each configuration file during packaging
2573N/A operations, IPS encourages package authors to deliver fragments of the
2585N/A complete configuration file.
2585N/A The packaged application either accesses those fragments directly when reading
2585N/A its configuration, or the fragments can be assembled into the complete
2585N/A configuration file before reading it.
2585N/A Solaris to configure extended attributes for roles and users on the system.
2585N/A This file is now used for local changes only, and Solaris has been modified
2585N/A to read its complete configuration from the separate files delivered into the
2585N/A fragments of the complete configuration, with no additional scripting
2585N/A needed when fragments are installed, removed or updated.
2585N/A Obviously this requires that the software is written with composition in mind,
2585N/A which isn't always possible.
2585N/A An alternative way to support the concept of composition, is for a service to
2573N/A treat the configuration file as volatile, and re-assemble it when when
2573N/A fragments of the configuration are installed, removed, or updated. Typically,
2585N/A this assembly is performed by an SMF service. We will discuss this idiom in
2585N/A An *actuator* is a tag applied to any *action* delivered by the packaging
2585N/A system that causes a side effect to happen when that action is installed,
2585N/A These side-effects are typically implemented as SMF services.
2585N/A We can create SMF services that are responsible for configuring software
2573N/A directly, or constructing configuration files using data delivered in the SMF
2585N/A manifest, or sourced from files installed on the system.
2585N/A Since SMF services have a rich syntax to express dependencies, we can ensure
2585N/A that each service only runs when all of its dependencies have been met.
2573N/A Solaris includes an SMF milestone,
2585N/A can add itself as a dependency. The intention being, that once the booting
2573N/A operating system has reached this milestone, all self-assembly operations
2585N/A have completed and application-services can start.
2585N/A *Actuators* are covered in more detail in *Chapter 9*.
2585N/AXXX This section is lifted from the guide that sch started. It's not quite
2585N/Acomplete yet, but I wanted to include some of the same sort of material we
2585N/Aused to have in the Application Packaging Developer's Guide, chpt 1.
2585N/AMany of the good packaging criteria present trade-offs among themselves. It
2585N/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
2585N/Aflexible guide depending on the circumstances. Although each of these criteria
2585N/Ais important, it is up to you to optimize these requirements to produce a good
2585N/AOptimize for Client-Server Configurations
2585N/A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2573N/AYou should consider the various patterns of software use
2585N/A(client and server) when laying out packages. Good packaging
2585N/Adesign divides the affected files to optimize installation of each
2585N/Aconfiguration type. For example, for a network protocol implementation,
2585N/Ait should be possible to install the client without necessarily
2585N/APackage by Functional Boundaries
2585N/A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2585N/APackages should be self-contained and distinctly identified with a set of
2573N/Afunctionality. For example, a package containing UFS should contain all UFS
2585N/Autilities and be limited to only UFS binaries.
2585N/APackages should be organized from a customer's point of view into functional
2585N/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
2573N/Aof packages. Do not to disperse the code into more packages than
2585N/AWhen constructing the packages, ensure that duplicate files are eliminated when
2585N/Apossible. Unnecessary duplication of files results in support and version
2585N/Adifficulties. If your product has multiple packages, constantly compare the
2585N/Acontents of these packages for redundancies.
2573N/ASize is package-specific and depends on other criteria. For example, the
2573N/Amaximum size of /opt should be considered. When possible, a good package should
2573N/Anot contain only one or two files or contain extremely large numbers of files.
2585N/AThere are cases where a smaller or larger package might be appropriate to
2585N/ALicensing Considerations for Packages
2585N/A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2585N/AIf you are distributing software that uses licensing, there are several things
2573N/ABefore you begin distributing licensed software, set up
2573N/Ayour business operations to distribute, price, and track licenses. There are a
2573N/Avariety of ways to distribute licenses, such as fax, electronic mail, or an 800
2573N/Atelephone number. You need to choose a method of distribution and set up all
2573N/Athe necessary processes. You also need to consider whether licenses need to be
2573N/Aupgraded with the software and how this will be done.
2585N/APricing policy and types of licenses must also be considered. You must consider
2573N/Ahow the product is used and what kinds of licenses your users will need to use
2573N/Athe product effectively. Single user licenses may not be appropriate for many
2585N/ABefore you implement licensing, you need to inform
2585N/Ayour users, particularly if the product has not been licensed in the past.
2585N/AWhen you do implement licensing, you may want to consider implementing it
2585N/Agradually. The first step would be monitoring the use of licenses, followed by
2585N/Awarning that the software is being used without a license, and finally, denying
2585N/AIf you are going to use a commercial product for licensing, there
2585N/Aare many things to consider when making your choice. You need to decide what
2585N/Ayour priorities are. For example, is ease of administration and use most
2585N/Aimportant? Or is enforcing the licensing policy more important?
You also need to consider whether the software will be used in a heterogeneous
or homogeneous environment and whether standards are important. You may also
want to look at the security provided by the product. Is it easy to get around
the enforcement of licenses?
The issues involved in choosing a commercial product will vary depending on
the kind of application and your reasons for implementing licensing.