by Gerry Haskins
This article describes the pace of the following cycles: Oracle Solaris releases, Oracle Solaris updates, support repository updates (SRUs), critical patch updates (CPUs), Interim Diagnostics or Relief (IDR) updates, and firmware updates. It also describes the Oracle Solaris Binary Application Guarantee and the Oracle Solaris Source Code Guarantee.
Product releases provide significant feature enhancements.
Product releases are the boundaries at which the most significant new features are introduced and deprecated interfaces tend to be removed.
|Oracle Solaris Release||Release Date|
|Oracle Solaris 10||March 2005|
|Oracle Solaris 11||November 2011|
Oracle Solaris 11 introduced support for the following significant features, among others:
- Oracle Solaris Image Packaging System (IPS), which replaced the System V Release 4 (SVR4)–based two-tier package and patch model used in Oracle Solaris 10 and earlier releases
- Mandatory ZFS root file systems, deprecating UFS root file systems
- The boot environment (BE) administration command, beadm, which is based on ZFS snapshots
- Significant networking enhancements including
- Network virtualization and resource management
- Significant InfiniBand improvements
- Critical threads
For further information, see the Oracle Solaris 11 information library.
Oracle Solaris is moving to a continuous delivery model using more-frequent updates to deliver the latest features faster, while fully preserving customer and ISV qualification investment in the vast array of ISV applications available for Oracle Solaris 11 today.
New features and functionality will be delivered in Oracle Solaris 11 through "dot" update releases instead of through major releases. See Oracle's SPARC and Oracle Solaris roadmap.
This delivery model is consistent with industry trends and addresses customer requirements for a smooth transition path between versions, providing ongoing innovation with assured investment protection.
By moving to a continuous delivery model based on Oracle Solaris 11, customers will have a seamless update experience to better fit their move to agile deployment models. See "Oracle Solaris Moving to a Continuous Delivery Model" for more information.
Consequently, the Oracle Solaris 11 and Oracle Solaris Cluster 4 Premier and Extended Support dates have been extended to January 2031 and January 2034, respectively. Support dates are evaluated annually, and will be provided until at least these dates. See page 34 (page 37 in the PDF) of "Oracle Lifetime Support Policy: Oracle and Sun Systems Software."
Product updates (or "dot" releases) are typically released approximately every 12 to 18 months, while the next release is under active development.
|Oracle Solaris Update||Release Date|
|Oracle Solaris 11.1||October 2012|
|Oracle Solaris 11.2||April 2014|
|Oracle Solaris 11.3||October 2015|
|Oracle Solaris 11.4 Beta||January 2018|
Updates contain compatible feature enhancements, free and open source software (FOSS) updates, new hardware support, and a significant number of additional bug fixes.
Oracle Solaris 11.1 introduced support for the following features, among others:
- Oracle Database performance improvements including:
- 8x faster database startup and shutdown and online resizing of the system global area (SGA)
- Kernel mode acceleration for Oracle Real Application clusters (Oracle RAC)
- Oracle Solaris Zones on shared storage and 4x faster Oracle Solaris Zones updates
For further information, see "Oracle Solaris 11.1—What's New."
Oracle Solaris 11.2 introduced support for the following features, among others:
- OpenStack and Puppet
- Oracle Solaris Kernel Zones
- Compliance checking and reporting
- Immutable Zones
- Java SE 8
For further information, see "What's New in Oracle Solaris 11.2."
Oracle Solaris 11.3 introduced support for the following features, among others:
- Software in Silicon (part of Oracle's SPARC M7 processor)
- Secure live migration and InfiniBand support for Kernel Zones. Oracle Solaris Zones on shared storage (ZOSS) support for NFS
- OpenStack updates including Heat and Ironic
For further information, see "What's New in Oracle Solaris 11.3."
Oracle Solaris 11.4 Beta introduced support for the following features, among others:
- Application Sandboxing and File and Process Labeling
- ZFS Device Removal and Send Stream improvements
- Networking and Zones integration into SMF, the Zones Delegated Restarter, 1-step Host Evacuation
- Dehydrate and Rehydrate for Unified Archives
- StatsStore and Amdin Webb Dashboard for performance analysis
For further information, see "What's New in Oracle Solaris 11.4."
This innovation is planned to continue in Oracle Solaris 11 updates, per Oracle's SPARC and Oracle Solaris roadmap.
Oracle will continue to produce Support Repository Updates (SRUs) for Oracle Solaris 11 and patches for Oracle Solaris 10 per the Oracle Support timeframes specified in "Oracle Lifetime Support Policy: Oracle and Sun System Software."
SRUs are available to customers who have a valid support contract.
SRUs are the primary support vehicle, typically containing bug fixes, minor feature enhancements, and platform support.
SRUs are typically released on a monthly cadence. (Oracle reserves the right to modify the release cadence and content of updates, SRUs, and so on.)
Each release of a product has a single SRU train that spans update releases.
Once a product update is released, the next SRU will be based upon that update.
Therefore, using Oracle Solaris 11 as an example, the contiguous support stream is:
11 11.1 11.2 11.3 11.4
11 SRU1...SRU13 11.1 SRU1...SRU21 11.2 SRU1...SRU15 11.3 SRU1... 11.4 SRU1...
In the above example, the current SRU for any Oracle Solaris 11 system will be the current SRU based on Oracle Solaris 11.3 irrespective of which Oracle Solaris 11 version was originally installed on the system.
This ensures all Oracle Solaris 11 installations benefit from all the critical bug fixes, performance enhancements, and security fixes contained in the latest Oracle Solaris 11 update and SRU.
Oracle Solaris Development Process Summary
A superset relationship is maintained between releases, updates, and SRUs. For example, the content of the next update is a superset of the current update, and the first SRU for next update is a superset of the SRUs for the current update.
This enables customers to move forward with confidence that they are unlikely to experience regressions to existing functionality and bug fixes.
New features are typically integrated into a development code branch and only after passing testing there, may they be approved for inclusion in the next update release and/or an SRU train, as appropriate.
This cascading of code change is designed to ensure quality and minimize regressions.
The Oracle Solaris Binary and Source Guarantee Program ensures that Oracle Solaris can be updated with confidence—without the need for ISV requalification—on systems running applications using published interfaces. See My Oracle Support document 1391762.1 and "The Oracle Solaris Binary and Source Guarantee Program" section below.
Functionality does occasionally need to be deprecated, for example, for security concerns where ciphers such as MD5 or protocols such as older OpenSSL versions are no longer considered secure, or due to the end of community support for particular FOSS versions.
Deprecated functionality will typically be flagged in advance, for example, in the release notes of the previous update release, if feasible, or in the End of Feature Notice on the Oracle Technology Network, in service alerts, or in security documentation.
My Oracle Support and other Oracle tools, such as BugDB, typically use a five-digit release taxonomy. For example, Oracle Solaris 11.3 SRU1.5 will typically be referred to in My Oracle Support documents as 18.104.22.168.0, which is a truncation of the key fields in the full version string of the Oracle Solaris entire incorporation:
email@example.com. Note: with the introduction of Oracle Solaris 11.4 the full version string has been simplified. For example:
firstname.lastname@example.org, which indicates it's Oracle Solaris 11.4 SRU2.5.
This five-digit SRU version abbreviation is also used in My Oracle Support documentation, for example, in document 1448883.1, and in the Solution Record section of Oracle bug IDs, for example:
---------- Solution Record ----------
Solution Type: SRU
Product: Solaris Operating System
Release: Solaris 11
Architecture: sparc, i386
Reference ID: 22450505
Solution Description: Fix delivered in Oracle Solaris 22.214.171.124.0 (or greater)
This Solution Record shows the bug is fixed in Oracle Solaris 11.3 SRU4.5.
Every third SRU is targeted to release on the Oracle standard Critical Patch Update (CPU) date. The CPU date is currently the third Tuesday of January, April, July, and October.
This is the date when Oracle publishes information on security vulnerability fixes.
See the CPU documentation and follow the links. For example, see the July 2018 CPU document for Oracle and Sun System Product Suite (which includes Oracle Solaris), which is My Oracle Support document 2419155.1.
SRUs released on the CPU date are the same as any other Oracle Solaris SRUs.
For Oracle Solaris 10, the Recommended OS patch set is copied and renamed as the CPU patch set on the CPU date. The latest Oracle Solaris 10 Recommended OS patch set is always a superset of the latest CPU patch set.
Security vulnerabilities are fixed as soon as possible in Oracle Solaris. Applying the latest available Oracle Solaris 11 SRU and Oracle Solaris 10 Recommended OS patch set provides the maximum protection against security vulnerabilities, even if information on the vulnerability won't be published until the next CPU date.
Common Vulnerabilities and Exposures (CVEs) Mappings
Public security vulnerabilities are given unique CVE IDs to identify them, and their severities are scored on a scale up to 10.0 using the Common Vulnerability Scoring System (CVSS).
My Oracle Support document 1448883.1 maps CVEs to available Oracle Solaris 11 SRUs and Oracle Solaris 10 patches.
See also the Third Party Bulletin for information on free and open source software (FOSS) vulnerabilities.
solaris-11-cpu package was introduced in November 2014 to aid customers with security compliance.
This is an optional package that contains metadata about CVEs addressed in Oracle Solaris 11. It also contains dependencies on the packages that provide fixes for such vulnerabilities.
Installing the optional
solaris-11-cpu package, and updating it regularly, will ensure that all available Oracle Solaris 11 security fixes are applied to the system, including fixes for packages that have been unlocked from their incorporations.
For further information, see My Oracle Support document 1948847.1, Darren Moffat's blog, and the section "Querying CVE Metadata" in "Overview of Image Packaging System in Oracle Solaris."
A diagnostic code for the root cause an issue or code that provides interim relief for an issue may be provided by means of an Interim Diagnostic or Relief (IDR).
An IDR delivers a temporary code branch for a specific issue or set of issues. For Oracle Solaris 11, IDRs are delivered in IPS format. For Oracle Solaris 10, they are delivered in System V Release 4 (SVR4) package format.
Note: For more information on using IPS to apply IDRs, see "Overview of Image Packaging System in Oracle Solaris."
The bug IDs of the issue(s) addressed are contained in the IDR metadata.
Any final fix will typically be integrated into a subsequent release, update, and SRU, as appropriate.
IDRs can provide interim relief until the final fix becomes available.
An IDR is typically created for a specific customer as a result of a service request for that customer being associated with a bug and the customer indicating that they wish to receive an IDR before a final fix is available.
When all bug IDs addressed by an IDR are fixed in an Oracle Solaris 11 release, update, or SRU, that release, update, or SRU will automatically supersede the IDR. This means that it can be applied on top of the IDR without first having to manually remove the IDR.
FOSS components, in particular, can be subject to "zero-day vulnerabilities," where little or no notice is given about a security vulnerability.
Examples of FOSS security vulnerabilities include Poodle, Heartbleed, and Shellshock.
For such high-profile vulnerabilities, a security IDR might be published for Oracle Solaris to provide relief for the vulnerability while the final fix is being integrated into a forthcoming SRU.
Because security IDRs have widespread applicability, they are made available for customers with a valid support contract from My Oracle Support. They can be downloaded as follows:
- Log in to My Oracle Support.
- Click the Patches & Updates tab.
- Select the Product or Family (Advanced) search option.
solarisinto the Product field and select Solaris Operating System from the drop-down menu.
- Select the release(s) you are interested in, for example, "Oracle Solaris 11 Operating System."
- Select the platform(s) you are interested in, for example, "Oracle Solaris on SPARC (64-bit)."
- Click Search.
- In the results returned, click Description to order the results alphabetically; the security IDRs will typically be listed first. For example here is some truncated output:
|19687094||idr1400.5 addresses bash vulnerabilities CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278 for Solaris 11.1 to Solaris 11.1 SRU12.5 (Patch)|
|19686997||idr1401.3 addresses bash vulnerabilities CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278 for Solaris 11.1 SRU13.6 to 11.1 SRU21.4.1 (Patch)|
|21791356||idr2058.1 to address BIND vulnerability cve-2015-5722 for Solaris 11.2 SRU13.6 (Patch)|
Also see the section "Querying CVE Metadata" in "Overview of Image Packaging System in Oracle Solaris."
Time Zone Package
Some governments make time zone changes at short notice, such as changes to Daylight Saving Time (DST).
Relief for such changes may be published in a time zone package before the change becomes available in an SRU.
The time zone package can be updated independently of the rest of Oracle Solaris by using IPS' facet-unlock functionality to unlock the package from the Oracle Solaris Incorporation.
See My Oracle Support document 2135137.1, "Timezone Data File Package for Oracle Solaris 11."
When considering security fixes, remember to consider all components of the stack, including system firmware, switch firmware, card firmware, database versions, and so on, per the CPU documentation referenced above, and the rest of your application stack.
Keeping systems firmware up to date is a vital component of proactive maintenance for security and for other fixes and should not be overlooked.
Systems firmware must be manually installed because it sits underneath the Oracle Solaris operating system and, hence, does not use the IPS
pkg command for installation. For convenience, systems firmware for selected SPARC platforms is delivered in the Oracle Solaris Support Repository, as shown below.
user@system:~$ pkg list -af 'firmware/system/*'
NAME (PUBLISHER) VERSION IFO
firmware/system/M5-32 126.96.36.199.0 ---
firmware/system/T7-4 188.8.131.52.0 ---
firmware/system/T7-4 184.108.40.206.0 ---
firmware/system/T7-4/sysfw9-5 220.127.116.11 ---
firmware/system/T7-4/sysfw9-5 18.104.22.168 ---
Systems firmware for other platforms should be downloaded for My Oracle Support, as usual. The appropriate systems firmware package(s) can be installed on the target system. Follow the installation instructions in the README file contained therein.
Firmware for cards such as I/O cards is typically delivered and installed alongside the driver updates in the relevant IPS packages in Oracle Solaris 11.
Oracle Solaris is designed for continuity of binary interfaces, so applications developed on earlier releases can continue to run.
This enables customers to purchase new systems or upgrade Oracle Solaris on older systems and continue to run their existing applications.
The Oracle Solaris Binary Application Guarantee reflects Oracle's confidence in the compatibility of applications from one release of Oracle Solaris to the next and is designed to make requalification a thing of the past.
If a binary application using published APIs runs on a release of Oracle Solaris 2.6 or later, it will run on the latest releases of Oracle Solaris, even if the application has not been recompiled for those latest releases.
Binary compatibility between releases of Oracle Solaris helps protect long-term investment in the development and maintenance of applications.
When there is a need to deprecate an outdated interface, Oracle strives to provide a minimum of six months warning, via an End of Feature Notice on the Oracle Technology Network website, before deprecating the interface.
The key exception is FOSS code, for which the community might decide to deprecate interfaces at short notice, typically in order to address security vulnerabilities, for example, to deprecate ciphers such as MD5 that are no longer considered secure.
When this occurs, Oracle strives to introduce the change in a manner that will cause minimum disruption. For example, if appropriate, the pre-existing version might remain available for some time alongside the new more-secure version with a recommendation that customers migrate their applications to the secure version before the secure version is made the default.
Tools are provided to enable customers to check that applications are compatible with current versions of Oracle Solaris.
Oracle Solaris supports both SPARC and x86 architectures. Oracle Solaris is compiled from common source code for both SPARC and x86, leveraging architecture-neutral APIs and Oracle Solaris Studio tools.
Oracle Solaris provides the Oracle Solaris Source Code Guarantee to customers, which ensures that a C or C++ application successfully compiled and run on one architecture will compile and run on either architecture using the same version of Oracle Solaris Studio.
For further information, see the Oracle Solaris Guarantee Program.
The expiration dates are updated periodically. (Oracle reserves the right to modify the programs.)
These popular blogs by the author:
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 2.1, 07/25/2017|
|Revision 2.0, 01/30/2017|