Initialize Solaris 11 Software Update Library

понедельник 06 апреля

by Peter Dennis
Published May 2012, updated July 2018

A BE is a bootable instance of an Oracle Solaris 11 operating system plus any other application software packages installed into that image. System administrators can maintain multiple BEs on their systems, and each BE can have different software versions installed.

For Oracle Solaris 11 administrators with access to Oracle support, maintaining systems correctly and efficiently is paramount to data center operations. This article explores Support Repository Updates (SRUs) and how best to maintain systems with the latest updates or a selected set of updates from Oracle.

The Oracle Support Repository contains a number of bug fixes and critical security fixes that can be applied to existing Oracle Solaris 11 installations helping to ensure that systems run without a hitch in the data center. The Support Repository is updated on a monthly basis, and these updates are called Support Repository Updates (SRU). Unlike Oracle Solaris Update releases, which include a wide range of new operating system features, the Oracle Support Repository is available only to systems under a support contract and includes a smaller set of critical changes.

This article explores more advanced use of the Image Packaging System (IPS) and assumes a basic knowledge of the update process using the pkg(1) command-line utility. If you would like to get up to speed with IPS, read 'How to Update Oracle Solaris 11 Systems From the Oracle Support Repository.'

Structure of Oracle Solaris 11 Software

The Oracle Solaris 11 software is delivered by a set of packages, with each group of packages constrained by incorporations, which ensure that package versions are consistent (and tested) with each other. Note that an incorporation does not deliver the packages but rather it defines the versions of the packages that can be installed on the system.

Each incorporation broadly represents the functional components for the system. An example is gnome-incorporation, which represents the GNOME desktop. You can find a complete list of the incorporations in the Packaging and Delivering Software with the Image Packaging System developer's guide. All the incorporations are in turn constrained by an incorporation called entire.

You can upgrade from one version of an incorporation to another. When you update an incorporation, all the packages it constrains will be updated to the versions specified in the new version of the incorporation.

Support Repository Updates

The Support Repository requires SSL certificates to be configured on the relevant client systems. You can obtain the SSL certificates by using the registration application here.

After you install the SSL certificates, you can access the Support Repository using the pkg(1) command-line utility or the Package Manager graphical utility.

Bug fixes are delivered via updates to software packages. When a package is updated in an SRU, the package's version string is also incremented. You can find details about the version string in the Packaging and Delivering Software with the Image Packaging System developer's guide.

Because each package is part of an incorporation, the incorporation will be updated to include the new version of the package. This in turn means the entire incorporation is updated to use these new incorporations.

Updating Your System

There are several ways to update your system:

Updating your system with the latest set of all changes that are in the Support Repository
Updating your system with a subset of an SRU, for example, updating an individual package, updating an individual incorporation, or updating multiple packages

Updating Your System with the Latest Set of All Changes

It is recommended that you regularly update your system with the latest set of changes held within the Support Repository. To do this, use the following command on a system:

# pkg update

Updating Your System to a Particular SRU

If you need to update to only a particular SRU, when you run the pkg update command, identify the SRU via the entire Fault Managed Resource Identifier (FMRI) string. For example, here is the command to update to SRU#34:

# pkg update entire@0.5.11-0.175.3.34

To list all the available SRUs, use the following command:

# pkg list -af entire

Information about the bugs fixed in each SRU is available at the My Oracle Support SRU information page (requires login).

Updating Your System with a Subset of an SRU

You can update a particular package or set of packages to address issues fixed by an SRU when updating to the whole SRU is not feasible. This is not the preferred or recommended approach, but it is possible to update specific packages and incorporations.

This method utilizes the version unlocking mechanism that is documented in the Chapter 6 and Chapter 13 of the developer's guide. Playboy magazine in the philippines.

Setting the appropriate version-lock facet to false removes the constraint applied to the corresponding package by an incorporation.

Because interdependent packages must have consistent versions, not all packages can have their constraints relaxed and, if that is the case, they do not have a version-lock facet. An example of this is the indivisible core, which consists of the kernel, drivers, system libraries, and associated utilities.

It is possible that other installed components have require or optional dependencies on the packages that have the version-lock facet. In this instance, it is possible that you can unset the facet but not be able to modify the version of the package on the system. If this is the case, the package system will indicate why the package cannot be changed.

At this time, setting version-lock facets might potentially take a long time. This issue is being addressed.

Version-lock facets exist on individual component packages, as well as on incorporations. Setting the latter allows you to unlock an incorporation from the rest of the system, while the packages it itself incorporates continue to be synchronized.

The following is the general form of a version-lock facet name, where <package-name> is the name of the package to which the facet applies:

version-lock.<package-name>

This convention might change in the future so that a single version-lock facet can be modified for a particular component that is delivered via several packages.

Updating an Individual Package

Some packages can be individually updated if required. Generally, these packages are ones that can be updated independently of the operating system. This approach is recommended for updating a particular package in an SRU that contains a security fix when is it not possible to update to the whole SRU.

To relax the constraint on the package, use this command:

# pkg change-facet facet.version-lock.library/security/openssl=false

It is also possible to specify the required version:

# pkg update library/security/openssl@1.0.2.15-0.175.3.32

Note that the pkg update command above uses a subset of the full FMRI string (only enough to uniquely identify it).

Additionally, in order to prevent accidental changes to a package, you can freeze a package at the desired level:

# pkg freeze library/security/openssl

It is recommended that the reason for freezing be recorded using the -c option.

# pkg freeze -c 'Update prior to SRU#34 install' library/security/openssl

Note that if the package is to be modified (moved to a different version), the freeze needs to be undone:

# pkg unfreeze library/security/openssl

There are two methods for bringing packages back in sync with the SRUs.

If the package has been held back, simply resetting the appropriate version-lock facet will cause the package to be updated to the current SRU level.
# pkg change-facet facet.version-lock.library/security/openssl=true
If the package has been moved forward, there are two options:
- You can update the complete system (which might require a reboot) and then reset the version-lock facet:
- Or you can downgrade the relevant package to the required version and apply the constraint back to the package. The important point is identifying the correct version of the package to downgrade to. You can achieved this by searching for the constraint that applies to the package based on the software installed on the system:
  Then update to that version and reset the version-lock facet:
  Again note that the complete FMRI string of the package was not used.

Updating an Individual Incorporation

As mentioned before, it is possible to relax the constraints enforced by an incorporation. Once the constraints are relaxed, the package can be updated independently of the rest of the system. The package can then be frozen using pkg freeze to prevent it from being updated in the future.

For example, you can avoid a system reboot by updating the desktop and kernel incorporations independently:

# pkg change-facet facet.version-lock.consolidation/desktop/desktop-incorporation=false

Then you can update the desktop incorporation independently of the rest of the system:

# pkg update desktop-incorporation

Additionally, it might be possible to update to a particular revision of the incorporation:

# pkg update desktop-incorporation@0.5.11-0.175.3.33.0.2.0

Note: If the incorporation was unlocked and a pkg update was performed on the system, the unlocked incorporation would be updated. This might not be desired, so you could freeze the incorporation to prevent further updates using pkg freeze desktop-incorporation.

It is recommended that you record the reason for freezing using the -c option:

# pkg freeze -c 'Standard environment 07/18' desktop-incorporation

If the incorporation needs to be changed in the future, you will need to unfreeze it:

# pkg unfreeze desktop-incorporation

There are two methods for bringing an incorporation back in sync with the SRUs:

If the incorporation has been held back, simply resetting the version-lock facet will cause the incorporation to be updated to the current SRU level on the system:
# pkg change-facet facet.version-lock.consolidation/desktop/desktop-incorporation=true
If the incorporation has been moved forward, there are two options:
- You can update the complete system (which might require a reboot) and then reset the version-lock facet:
- Or you can downgrade the incorporation and all the packages that are incorporated by the incorporation. This requires explicitly naming all packages and their associated versions:

Updating Multiple Packages

Packages might have cross-dependencies and, thus, require updating at the same time. The packaging software will enforce a consistent image on the system: If it cannot satisfy the dependencies, the packages will not be modified. If such a dependency exists, you need to relax the constraints of the affected packages.

The message reported by the packaging software will be of the following form:

You will also need to relax the constraints of the dependent package.

Additional `pkg` Commands

To see what packages have been frozen on a system, use this command:

# pkg freeze

To see what facets have been set on a system, run this command:

# pkg facet

About the Author

Peter Dennis is a Principle Engineer within the Oracle Solaris Revenue Product Engineering team. He has worked on a wide variety of technologies: file systems, volume management and backup, cluster and general end-user utilities. He is currently the technical lead for the Oracle Solaris 11 Update release.

Revision 1.1, 07/24/2018
Revision 1.0, 05/14/2012