by Gerry Haskins
This article describes the Oracle Solaris Image Packaging System (IPS)—a modern, open, repository-based packaging system—and how to use it to apply support repository updates (SRUs) and Interim Diagnostics or Relief (IDR) updates. It also discusses troubleshooting and querying metadata.
Note: For more information on SRUs and IDRs, see "Overview of Oracle Solaris Release Cadence."
IPS is used in products such as Oracle Solaris 11 and Oracle Solaris Cluster 4.
IPS is a single-tier packaging system, where the same commands are used for both installation and applying maintenance updates. For more information, see man pkg on an Oracle Solaris 11 system.
In IPS, software can be organized into installation groups for different use cases, for example, a desktop deployment or a server deployment. The installation group defines the packages that get installed on the target system. The following example shows an Oracle Solaris 11 desktop installation (denoted by i):
user@system:/usr/bin$ pkg list solaris-desktopgroup/system/solaris-desktop 0.5.11-0.175.3.1.0.5.0 i--
In IPS, software versions can be organized into incorporations, which define a set of software versions (a "surface") that are designed to work together. Incorporations can include other incorporations. The incorporations define the versions of packages that get installed on the target system. For example, the Oracle Solaris entire incorporation defines the Oracle Solaris version:
user@system:~$ pkg list entireNAME (PUBLISHER) VERSION IFOentire 0.5.11-0.175.3.1.0.5.0 i--
The Fault Management Resource Identifier (FMRI) version string above shows this system has Oracle Solaris 11.3 SRU1.5 installed.
Note that with the introduction of Oracle Solaris 11.4 the output has been updated to make it simpler to deduce the version:
user@system:~$ pkg list entireNAME (PUBLISHER) VERSION IFOentire 11.4-11.4.2.0.1.5.0 i--
The FMRI version string above shows the system has Oracle Solaris 11.4 SRU2.5 installed.
For more information see "IPS Design Goals, Concepts and Terminology."
For Oracle Solaris IPS specifics, see:
How Does IPS Differ from Sun's SVR4-Based Packaging System?
IPS replaces Sun's System V Release 4 (SVR4) packaging system used in products such as Oracle Solaris 10 and earlier releases and in Oracle Solaris Cluster 3.2 and earlier releases.
IPS is designed to be much simpler and much more powerful than the two-tier SVR4-based packaging system, which had separate but related commands for installation and patching such as pkgadd and patchadd, the latter calling the former under the hood.
IPS is designed for simplicity, with repository-based updates eliminating the need to download myriad separate patches or patch sets. This eliminates a lot of the maintenance work customers needed to perform for Oracle Solaris 10 and earlier releases to determine which patches need to be installed.
Instead, in IPS, software is updated as a unit. A system will typically be updated to a later SRU.
Oracle Solaris 11 Installation Groups
The use case for the target system determines which installation group is appropriate.
Installation groups include the following:
user@system:~$ pkg list -n 'group*'NAME (PUBLISHER) VERSION IFO group/feature/amp 0.5.11-0.175.3.0.0.30.0 --- group/feature/developer-gnu 0.5.11-0.175.3.0.0.30.0 --- group/feature/developer-studio-utilities 0.5.11-0.175.3.3.0.2.0 --- group/feature/multi-user-desktop 0.5.11-0.175.3.0.0.30.0 --- group/feature/storage-avs 0.5.11-0.175.3.0.0.30.0 --- group/feature/storage-nas 0.5.11-0.175.3.0.0.30.0 --- group/feature/storage-server 0.5.11-0.175.3.0.0.30.0 --- group/feature/trusted-desktop 0.5.11-0.175.3.0.0.30.0 --- group/prerequisite/oracle/oracle-ebs-server-R12-preinstall 0.5.11-0.175.3.1.0.5.0 --- group/prerequisite/oracle/oracle-rdbms-server-12-1-preinstall 0.5.11-0.175.3.1.0.5.0 --- group/system/management/rad/rad-client-interfaces 0.5.11-0.175.3.0.0.30.0 --- group/system/management/rad/rad-server-interfaces 0.5.11-0.175.3.0.0.30.0 i-- group/system/solaris-auto-install 0.5.11-0.175.3.1.0.5.0 --- group/system/solaris-core-platform 0.5.11-0.175.3.0.0.30.0 i-- group/system/solaris-desktop 0.5.11-0.175.3.1.0.5.0 i-- group/system/solaris-large-server 0.5.11-0.175.3.1.0.5.0 --- group/system/solaris-minimal-server 0.5.11-0.175.3.1.0.5.0 --- group/system/solaris-small-server 0.5.11-0.175.3.1.0.5.0 ---
The common installation groups highlighted above are described in the following four sections.
solaris-minimal-server
solaris-minimal-server is designed to be used as the basis for a secure install. This installation group installs the bare-minimum packages required to have a functioning system that is capable of administrator login and zone creation, and provides a basic editor for editing configuration files.
The idea is that you then install only the additional packages required for the applications you wish to install in this environment. Consider the packages required for the entire lifecycle of the environment, including monitoring, updating, backups, debugging, and so on.
For example, if the applications to be installed in the environment need the gunzip utility, the corresponding package that needs to be installed on top of solaris-minimal-server can be found as follows:
user@system:~$ pkg search -p gunzipPACKAGE PUBLISHER pkg:/compress/gzip@1.5-0.175.3.0.0.30.0 solaris
To install the package, run the following command as a privileged user:
root@system:~$ pkg install gzip
The advantage of this approach is that it minimizes the attack surface of the installed environment. This reduces the need to patch the environment because if the vulnerable software isn't installed, it doesn't need to be patched.
FOSS software—such as OpenSSL, BIND, NTP, and so on—is particularly prone to security vulnerabilities. If these packages are not needed, then not installing them avoids the need to patch them, for example, to address zero-day vulnerabilities. This increases security compliance and reduces total cost of ownership (TCO) because it reduces the maintenance burden.
solaris-small-server and solaris-large-server
The difference between the solaris-small-server and solaris-large-server installation groups has nothing to do with the size of the server being installed. Rather it refers to the number of packages that will be installed on the target system. solaris-large-server provides a number of additional utilities that system administrators might find useful. solaris-small-server provides a slightly smaller attack surface, but nowhere near as minimized as solaris-minimal-server.
solaris-desktop
Use the solaris-desktop installation group for desktop/workstation installations where the user needs the full palette of desktop utilities. solaris-desktop is not appropriate for most server installations because the additional desktop packages are unlikely to be needed and increase the attack surface for hackers and malware.
oracle-rdbms-server-12-1-preinstall and oracle-ebs-server-R12-preinstall
Other installation groups include groups designed to simplify the installation of common applications such as an Oracle Database 12_c_ single-instance database or Oracle E-Business Suite 12.
These install groups install the prerequisite packages required by these applications.
Oracle Solaris 11 Incorporations
Incorporations define a "surface," that is, the versions of packages that can be installed and have been tested to work together.
The entire incorporation defines the Oracle Solaris 11 version. It defines which versions of individual packages comprise an Oracle Solaris release.
Removing the entire incorporation package from an installed system is unsupported, because it would leave the system vulnerable to updates of inconsistent and untested package combinations.
IPS and Applying SRUs
SRUs provide package deltas based on the preceding update release, so the update release itself must also be added to your repository, if the system doesn't already have that update release, in order to apply subsequent SRUs.
IPS dynamically resolves dependencies, for example, when executing a pkg update command. To avoid IPS dependency resolution issues, it is recommended that if you set up a local package repository, it includes all update releases and SRUs from the oldest version installed on any system in your environment through to the latest SRU.
See "How to Update Oracle Solaris 11 Systems From Oracle Support Repositories. "
If the default internet-facing support repository has been configured, it will be shown as follows:
user@system:~# pkg publisherPUBLISHER TYPE STATUS P LOCATION solaris origin online F https://pkg.oracle.com/solaris/support/
Many customers will wish to set up a local repository behind their firewall to mirror the support repository content; see the relevant "how to" document referenced above and also see Creating Package Repositories in Oracle Solaris 11.4 and "Best Practices for Creating and Using Local IPS Package Repositories." As noted earlier, the Oracle Solaris entire incorporation currently installed on the system is Oracle Solaris 11.3 SRU1.5:
user@system:~$ pkg list entireNAME (PUBLISHER) VERSION IFOentire 0.5.11-0.175.3.1.0.5.0 i--
To get more verbose information, type the following:
user@system:~$ pkg info entire Name: entire Summary: Incorporation to lock all system packages to the same build Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.1.5.0) Build Release: 5.11 Branch: 0.175.3.1.0.5.0 Packaging Date: October 6, 2015 02:00:51 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.1.0.5.0:20151006T140051Z
To check whether a later version is available from the repository, which was set up as a publisher, type the following:
user@system:~$ pkg search solaris/entireINDEX ACTION VALUE PACKAGE pkg.fmri set solaris/entire pkg:/entire@0.5.11-0.175.3.1.0.5.0 pkg.fmri set solaris/entire pkg:/entire@0.5.11-0.175.3.2.0.4.0 pkg.fmri set solaris/entire pkg:/entire@0.5.11-0.175.3.3.0.6.0 pkg.fmri set solaris/entire pkg:/entire@0.5.11-0.175.3.4.0.5.0
From the above, you can see that the latest available SRU in the repository is Oracle Solaris 11.3 SRU4.5. Only the SRUs from the version installed on the system from which you run the command are returned: currently, Oracle Solaris 11.3 SRU1.5.
If we run an unconstrained pkg update command as a privileged user, IPS will update the system to the latest software version contained in the repository for which dependencies can be resolved. This might or might not be the latest available version.
Always check that pkg update has updated to the version expected, because if there is a constraint that prevents updating to the latest version, it might update to an intermediate version.
You can explicitly specify the version to update to in order to avoid IPS updating past the intended version if a later version is available in the repository.
Let's do a dry run first using the pkg command with the -nv option to see what will be updated:
root@system:~# pkg update -nv entire@0.5.11-0.175.3.4 Packages to update: 140 Estimated space available: 889.16 GB Estimated space to be consumed: 1.61 GB Create boot environment: Yes Activate boot environment: Yes Create backup boot environment: No Rebuild boot archive: Yes Changed packages: solaris consolidation/SunVTS/SunVTS-incorporation 7.19.2,5.11-0.175.3.0.0.26.3:20150705T213238Z -> 8.0.0,5.11-0.175.3.4.0.2.21:20151211T223018Z consolidation/X/X-incorporation 0.5.11,5.11-0.175.3.1.0.2.1489:20150921T191842Z -> 0.5.11,5.11-0.175.3.2.0.2.1493:20151020T015528Z consolidation/desktop/desktop-incorporation 0.5.11,5.11-0.175.3.0.0.28.0:20150802T213249Z -> 0.5.11,5.11-0.175.3.4.0.3.0:20151222T185437Z : x11/session/sessreg 1.0.8,5.11-0.175.3.0.0.30.1483:20150821T173739Z -> 1.1.0,5.11-0.175.3.2.0.2.1493:20151020T015534Z Editable files to change: Install: etc/ssm/hmp/host_profile.xml Update: etc/motd var/log/ssm/fwupdate.log var/log/ssm/raidconfig.log
The above command specifies a dry run of updating the entire Oracle Solaris incorporation to the latest released build of Oracle Solaris 11.3 SRU4. We can see 140 packages will be updated between Oracle Solaris 11.3 SRU1 and Oracle Solaris 11.3 SRU4, and that a new boot environment (BE) will be created and activated so it will become active upon the next reboot. Until the next reboot, the system will continue to run the existing version, Oracle Solaris 11.3 SRU1, because we're updating an alternate boot environment rather than the live BE.
We simply specified updating to entire@0.5.11-0.175.3.4. By including the remainder of the FMRI string, we could further restrict the update to a unique build, but typically we want the latest build for a particular SRU, because more than one build will typically be released only if a critical issue is addressed in the later build, such as a build to fix a late-breaking FOSS security vulnerability.
Let's do the actual update now, specifying the name 11.3.4 for the new BE:
root@system:~# pkg update --be-name 11.3.4 entire@0.5.11-0.175.3.4 Packages to update: 140 Create boot environment: Yes Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 140/140 5150/5150 289.3/289.3 574k/s PHASE ITEMS Removing old actions 841/841 Installing new actions 1017/1017 Updating modified actions 5591/5591 Updating package state database Done Updating package cache 140/140 Updating image state Done Creating fast lookup database Done Reading search index Done Building new search index 948/948 Updating package cache 1/1 A clone of solaris exists and has been updated and activated. On the next boot the Boot Environment 11.3.4 will be mounted on '/'. Reboot when ready to switch to this updated BE. Updating package cache 1/1
We can see the new BE we've just created, as follows:
user@system:~$ beadm listBE Flags Mountpoint Space Policy Created --- ------- -------------- ------- ------- ---------- solaris N / 8.79M static 2016-01-05 12:37 11.3.4 R - 9.32G static 2016-01-22 15:51
man beadm states: "The Flags field indicates whether the boot environment is active now, represented by N; active on reboot, represented by R; or both, represented by NR." So our new BE (11.3.4) will be activated on the next reboot.
Let's reboot into the alternate BE. Use shutdown -i6 -g0 -y to allow applications to shut down gracefully:
root@system:~$ shutdown -i6 -g0 -y
And once we log in, after it reboots, we can see that the new BE is now active:
user@system:~$ beadm listBE Flags Mountpoint Space Policy Created ---- ------- -------------- ------- ------- ----------- solaris - - 70.79M static 2016-01-05 12:37 11.3.4 NR / 9.46G static 2016-01-22 15:51
Notice how little space is used to preserve the old BE. This is a key advantage of the mandatory ZFS root file system in Oracle Solaris 11.
Note: Not only is this document, which I was authoring while creating this new BE, available in the new BE, even the changes I saved to it since creating the new BE have been propagated to it. Indeed, upon opening Firefox, it offers to restore all the browser windows I had open in the old BE. That might seem like magic, but it actually has to do with which directories are and are not shared between BEs.
We can check that we are indeed now running Oracle Solaris 11.3 SRU4:
user@system:~$ pkg list entireNAME (PUBLISHER) VERSION IFO entire 0.5.11-0.175.3.4.0.5.0 i--
As a privileged user, let's rename the original BE to something more descriptive. We can rename only nonactivated alternate BEs, so in this case, we can rename solaris but not 11.3.4:
root@system:~# beadm rename solaris 11.3.1root@system:~# beadm listBE Flags Mountpoint Space Policy Created ---- ------- ---------- ------ -------- ------- 11.3.1 - - 70.79M static 2016-01-05 12:37 11.3.4 NR / 9.46G static 2016-01-22 15:51
If for any reason, we don't like the 11.3.4 boot environment, we can simply and quickly boot back into the old 11.3.1 boot environment by activating it for the next reboot (see man beadm):
root@system:~# beadm activate 11.3.1root@system:~# beadm listBE Flags Mountpoint Space Policy Created ---- ----- ------------- ------- -------- ---------- 11.3.1 R - 7.86G static 2016-01-05 12:37 11.3.4 N / 1.45G static 2016-01-22 15:51
A reboot will now bring the system back to running the old 11.3.1 boot environment.
For further information, see the Oracle Solaris 11 how-to articles, in particular:
Also see:
IPS and Applying IDRs
See "Installing IDRs."
As mentioned in the "Interim Diagnostics or Relief (IDR) Updates" section of "Overview of Oracle Solaris Release Cadence," IDRs provide a diagnostic code or code that provides interim relief for issues encountered by customers, until a final fix becomes available.
To prevent such relief from being accidentally overwritten, a pkg update command performed to a later SRU will fail unless the bug IDs referenced in the IDR metadata are fixed in that SRU.
If you have an IDR installed, see the "Querying Bug Metadata" section below for information about how to check whether the bug IDs are fixed in the SRU to which you plan to update.
You can manually remove the IDR to enable the update to a later SRU, but presuming the relief provided by the IDR is still needed, you need to file a new service request (SR) requesting that a new IDR containing relief for the specified bug IDs be created for the later SRU.
Several weeks of advance notice need to be given to allow time for the creation of the new IDRs for the later SRU. The metadata in the new IDRs should enable an upgrade from the old SRU and IDRs to the later SRU and IDRs without the need to manually remove the old IDRs first.
For example, assume you have been given idr2293.1 for Oracle Solaris 11.3 SRU1 to provide relief for a ZFS issue:
user@system:~/Downloads$ pkgrepo list -s idr2293.1.p5pPUBLISHER NAME O VERSION solaris idr2293 1,5.11:20160209T200853Z solaris system/trusted 0.5.11,5.11-0.175.3.0.0.30.0.2293.1:20160209T200855Z
You can add IDRs to a local repository and ensure that repository is listed as a publisher (see pkg publisher). You might wish to keep IDRs local to the environment in which they are required rather than in your main repository to avoid propagating the IDRs unnecessarily to other environments.
Alternatively, as a privileged user, you can use the .p5p file directly, adding it to your list of publishers:
root@system:# pkg set-publisher -g idr2293.1.p5p solarisroot@system:# pkg publisherPUBLISHER TYPE STATUS P LOCATION solaris origin online F file:///user/Downloads/idr2293.1.p5p/ solaris origin online F https://pkg.oracle.com/solaris/support/
As usual, let's do a -nv dry run of the installation first to see what it will do. Note that we specify only the base ID of the IDR, namely idr2293, rather than idr2293.1 or idr2293.1.p5p:
root@system:/user/Downloads# pkg install -nvr idr2293 Packages to install: 1 Estimated space available: 870.45 GB Estimated space to be consumed: 13.87 MB Create boot environment: No Create backup boot environment: No Rebuild boot archive: No Changed packages: solaris idr2293 None -> 1,5.11:20160209T200853Z Release Notes: # Release Notes for IDR : idr2293 # -------------------------------- Release : Solaris 11.3 SRU # 1.5.0 Platform : i386 Bug(s) addressed : 22304187 : labeld can't keep up with the number of setflabel(3TSOL) requests Package(s) included : pkg:/system/trusted Removal instruction : # /usr/bin/pkg uninstall -r idr2293 Generic Instructions : 1) If system is configured with 'Zones', ensure that IDR is available in a configured repository. Special Instructions for : idr2293 None.
The Release Notes metadata displayed above indicates what bug(s) the IDR addresses and how to remove the IDR. It also shows that, by default, no backup BE will be created.
But we can explicitly ask for a backup BE to be created so that we have a BE to revert to in case we're not happy with the IDR and we want to be super cautious in case it doesn't back out cleanly:
root@system:/user/Downloads# pkg install --backup-be-name 11.3.1-vanilla idr2293 Packages to install: 1 Create boot environment: No Create backup boot environment: YesRelease Notes: # Release Notes for IDR : idr2293 # -------------------------------- Release : Solaris 11.3 SRU # 1.5.0 Platform : i386 Bug(s) addressed : 22304187 : labeld can't keep up with the number of setflabel(3TSOL) requests Package(s) included : pkg:/system/trusted Removal instruction : # /usr/bin/pkg uninstall -r idr2293 Generic Instructions : 1) If system is configured with 'Zones', ensure that IDR is available in a configured repository. Special Instructions for : idr2293 None. DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 1/1 5/5 0.0/0.0 1.2M/s PHASE ITEMS Installing new actions 13/13 Updating package state database Done Updating package cache 0/0 Updating image state Done Creating fast lookup database Done Reading search index Done Updating search index 1/1 Updating package cache 1/1
We can see it has been installed as follows:
user@system:~/Downloads$ pkg list idr2293NAME (PUBLISHER) VERSION IFO idr2293 1 i--
And we can see that the specified backup BE was created (and takes up minimal space):
user@system:~/Downloads$ beadm listBE Flags Mountpoint Space Policy Created --- ----- ---------- ----- ------ ------- 11.3.1 NR / 8.88G static 2016-01-05 12:37 11.3.1-vanilla - - 57.48M static 2016-02-23 14:33 11.3.4 - - 1.46G static 2016-01-22 15:51
To remove the IDR for any reason, as a privileged user, we simply do the following:
root@system:/user/Downloads# pkg uninstall -r idr2293 Packages to remove: 1 Create boot environment: No Create backup boot environment: No PHASE ITEMS Removing old actions 12/12 Updating package state database Done Updating package cache 1/1 Updating image state Done Creating fast lookup database Done Reading search index Done Updating search index 1/1 Updating package cache 1/1
When removing IDRs, the update and SRU to which the IDR applies must be available from a configured publisher. For example, if the IDR is for Oracle Solaris 11.3 SRU4, both Oracle Solaris 11.3 SRU1 (which is the update release) and Oracle Solaris 11.3 SRU4 need to be available from a configured publisher to enable IPS to uninstall the IDR. This is because IPS is effectively rolling back the package versions to the update level (if the package wasn't modified in any SRU) or to the SRU level (if it was modified in any SRU and, hence, needs those package versions to be available to it). SRUs are cumulative but don't contain packages that haven't been modified since the last update was released.
We can confirm the IDR is no longer installed, as follows:
user@system:~/Downloads$ pkg list idr2293pkg list: No packages matching 'idr2293' installed
Enhancements to IPS IDR functionality in successive Oracle Solaris 11 updates have made it easier to manage IDRs, including IDRs in Oracle Solaris Zones.
For example, when manually removing an IDR, in the initial Oracle Solaris 11 release, you needed to run pkg reject for the IDR, cutting and pasting the list of packages affected from the IDR's metadata. Furthermore, if some of those packages weren't installed on the system, the package list needed to be edited to reflect the set of packages that were actually installed.
In a subsequent Oracle Solaris 11 update, the addition of the -ignore-missing flag removed the need to edit the package list.
In Oracle Solaris 11.3, a simple pkg uninstall -r <idr> suffices. The -r recursively removes the IDR from non-global zones.
See "Removing IDRs."
Troubleshooting Package Installation and Update Issues
See "Troubleshooting Package Installation and Update."
A common cause of issues is an incomplete local repository, which is missing interim updates or SRUs required by IPS to dynamically resolve dependencies.
Another common issue is missing or incorrect publishers or publishers specified in the wrong order if more than one publisher contains a particular package.
Querying CVE Metadata
Even without installing the optional solaris-11-cpu package on a system, you can determine whether a particular CVE that is fixed in an Oracle Solaris SRU might be later than the SRU currently installed on the system, for example:
user@system:~$ pkg search :CVE-2015-8000:INDEX ACTION VALUE PACKAGECVE-2015-8000 set pkg://solaris/network/dns/bind@9.6.3.11.4,5.11-0.175.3.3.0.6.0 pkg:/support/critical-patch-update/solaris-11-cpu@2015.12-1CVE-2015-8000 set pkg://solaris/network/dns/bind@9.6.3.11.4,5.11-0.175.3.3.0.6.0 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 CVE-2015-8000 set pkg://solaris/network/dns/bind@9.6.3.11.4,5.11-0.175.3.4.0.3.0 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1CVE-2015-8000 set pkg://solaris/service/network/dns/bind@9.6.3.11.4,5.11-0.175.3.3.0.6.0 pkg:/support/critical-patch-update/solaris-11-cpu@2015.12-1CVE-2015-8000 set pkg://solaris/service/network/dns/bind@9.6.3.11.4,5.11-0.175.3.3.0.6.0 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 CVE-2015-8000 set pkg://solaris/service/network/dns/bind@9.6.3.11.4,5.11-0.175.3.4.0.3.0 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1
The output above tells us that the DNS BIND security vulnerability, CVE-2015-8000, is fixed in Oracle Solaris 11.3 SRU3.6 and later. So we can install this fix by either updating the system directly to Oracle Solaris 11.3 SRU3.6 (pkg update entire@**0.5.11-0.175.3.3.0.6**) or indirectly via the optional solaris-11-cpu package if it has been installed (pkg update **solaris-11-cpu@2015.12-1**), which will also update entire to at least Oracle Solaris 11.3 SRU3.6 via its dependencies. Indeed, updating the solaris-11-cpu package will update the system to the latest SRU that contains new security fixes which it references.
Furthermore, as SRUs are added to the support repository, you can check to see which CVEs are fixed in them, for example:
user@system:~$ pkg search -r info.cve:|grep 2016.1info.cve set CVE-1999-0103 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2002-2443 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2003-0001 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2004-0230 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 : info.cve set CVE-2016-0419 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0426 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0428 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0431 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0440 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0458 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0493 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0535 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0618 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0777 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve set CVE-2016-0778 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1
Installing solaris-11-cpu from your repository is easy. As always, it is a good idea to use the pkg command option -nv to specify a dry run first so you can see what the command will do:
root@system:~# pkg install -nv solaris-11-cpu Packages to install: 1 Estimated space available: 889.40 GB Estimated space to be consumed: 147.59 MB Create boot environment: No Create backup boot environment: No Rebuild boot archive: No Changed packages: solaris support/critical-patch-update/solaris-11-cpu None -> 2015.10,5.11-2:20151009T231515Z
Note also that no new BE will be created, because we're just installing an additional metadata package rather than changing the underlying operating system.
As in previous examples, the system currently has Oracle Solaris 11.3 SRU1.5 installed. The command above shows that the corresponding version of the solaris-11-cpu package will be installed, namely that from 2015.10:
user@system:~$ pkg contents -m solaris-11-cpu@2015.10 | grep entiredepend fmri=pkg://solaris/entire@0.5.11,5.11-0.175.3.1.0.5.0 type=require
Installing solaris-11-cpu will not update the SRU installed on the system unless and until we subsequently update the solaris-11-cpu package to the latest available version, for example, to 2016.1.
Rerunning the command above without the -nv option will install the package:
root@system:~# pkg install solaris-11-cpu Packages to install: 1 Create boot environment: No Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 1/1 3/3 0.0/0.0 7.1k/s PHASE ITEMS Installing new actions 6063/6063 Updating package state database Done Updating package cache 0/0 Updating image state Done Creating fast lookup database Done Reading search index Done Updating search index 1/1 Updating package cache 1/1
The version installed can be confirmed as follows:
root@system:~# pkg list solaris-11-cpuNAME (PUBLISHER) VERSION IFO support/critical-patch-update/solaris-11-cpu 2015.10-2 i--
See the SRU documentation on My Oracle Support, document 1559480.2, for further information on SRU releases, release dates, links to different install images, READMEs, and so on. The READMEs referenced include a summary of why you should consider installing the particular SRU as well as details about the bugs fixed, packages updated, IDRs that are automatically superseded by the SRU, and so on.
Querying Bug Metadata
By convention, Oracle products use the "base" bug ID of a bug tree to provide a common bug fix reference across releases.
For example, bug 22611845, "Backport 21241934 to 11.3-SRU - ZFSSA driver should return free (versus available) space," is the Oracle Solaris 11.3 sub-bug for the backport of the "base" bug ID, 21241934, "ZFSSA driver should return free (versus available) space."
It is the "base" bug ID, not the sub-bug, which will be referenced in the IPS metadata for the Oracle Solaris 11.3 SRU that fixes the issue:
user@system:~$ pkg search -f 21241934INDEX ACTION VALUE PACKAGE com.oracle.service.bugid set 21241934 pkg:/cloud/openstack/cinder@0.2014.2.2-0.175.3.5.0.5.0
The output above tells us the bug is fixed in Oracle Solaris 11.3 SRU5.
Note that the -f option in pkg search is important in order to see whether the bug is fixed in all circumstances:
-f Show all results, regardless of package version. By default, search prunes results from packages older than the currently installed version and from package versions excluded by current incorporations.
If the same command is run without -f, we get the following:
user@system:~$ pkg search 21241934user@system:~$
This is because, although the bug is fixed in a later SRU than the one applied to the system, the incorporation containing the fix is not installed and, hence, the fix is not applicable to this system:
user@system:~$ pkg list cloud/openstack/cinderpkg list: No packages matching 'cloud/openstack/cinder' installed
Using pkg search -f <BugID> followed by pkg search <BugID> is useful to determine that a bug fix is available but is not applicable to the system. That is, no action is required because the system is not impacted by the bug.
There is one caveat: bug ID metadata is not included in Oracle Solaris 11 updates, so pkg search -f <BugID> will return information only on bugs fixed in SRUs, not in releases or updates. Oracle plans to look into including bug ID metadata in Oracle Solaris 12 updates. (This is subject to change.)
Details about security vulnerabilities and many other bugs are not visible to customers. For security vulnerabilities, see the section "Querying CVE Metadata" and reference the critical patch update documentation.
See Also
And here are some additional Oracle Solaris resources:
About the Author
As the Software Lifecycle Engineering Director for Oracle's Systems group, Gerry Haskins is responsible for Oracle Solaris patching and best practices and well as Oracle SuperCluster installation and configuration utilities and quarterly full-stack download patches (QFSDPs).
| Revision 1.1, 07/25/2018 |
| Revision 1.0, 04/18/2016 |
Follow us:
Blog | Facebook | Twitter | YouTube