By Gerry Haskins-Oracle on May 20, 2010
The Solaris "Recommended" and Sun Alert Patch Clusters have been merged (June 4th 2010).
The merged clusters are called the "Recommended OS Cluster Solaris <release> <architecture>", for example "Recommended OS Cluster Solaris 10 SPARC".
The old "Recommended" and Sun Alert Patch Clusters only ever contained Solaris OS patches (with rare exceptions), so we've added "OS" to the new merged cluster name to make this a little clearer.
The merged Recommended OS Clusters have the same access entitlement as the old clusters - namely, you need a support contract which covers Solaris to access them.
The old "Recommended" patch cluster contains the latest revision of Solaris OS patches which fix Sun Alert issues (i.e. Security, Data Corruption, or System Availability issues). That is, the top-of-tree patches which fix Sun Alert issues.
The Sun Alert patch cluster contains the minimum revision of Solaris OS patches which fix Sun Alert issues. Thus, the Sun Alert patch cluster provides the minimum amount of change required to get all available Solaris OS fixes for Security, Data Corruption, and System Availability issues.
The contents for the two clusters are very similar, which causes unnecessary confusion as to which one to use. When the Sun Alert Cluster was released several years ago, it should have replaced the older "Recommended" Cluster, and this merging of the Clusters is to correct that omission.
The inclusion criteria for the Sun Alert cluster is more logically correct, as in the Recommended Cluster there's no more value in adding the latest revision of a patch whose earlier revision provided a fix to a Sun Alert issue than in adding any other random patch. Many folks assume "latest is greatest", and Oracle Sun wouldn't release a patch unless it is important, but this is slightly simplistic. Change implies risk, and as many patches address issues which are only seen in very specific configurations, and while Oracle Sun patches are thoroughly tested prior to release, there is little advantage in taking more change than is necessary in minor maintenance windows or reactive patching situations. Therefore, providing a minimal patch cluster which provides all available fixes for Solaris OS Sun Alert issues for use in minor maintenance windows makes sense.
The old "Recommended" Clusters were often updated several time a week, simply because a later revision of a patch whose earlier revision fixed a Sun Alert issue was released, even though the later revision didn't fix any additional Sun Alert issues. Since the "Recommended" flag on SunSolve and in the patchdiag.xref metadata file matches the contents of the old "Recommended" Cluster, we were releasing many more patches which were flagged as "Recommended" than customers really needed to apply.
After the merge, new patches added to the Recommended OS Cluster and hence the "Recommended" flag on SunSolve and in the patchdiag.xref metadata file will be the specific revision of patches which address Sun Alert issues. Only when an obsoleting patch provides a new fix to a Sun Alert issue will it be included and the obsolete patch removed. The merged Recommended OS Clusters will update on the same cadence as the old Sun Alert clusters, which is typically about once a week for Solaris 10 (5.5 times a month, on average). We will continue to update the merged Recommended OS Cluster whenever a patch matching the inclusion criteria is released.
To avoid the potential confusion which may be caused if we were to remove the "Recommended" flag from any patches, we will take the "Recommended" Cluster at the beginning of June 2010 as the basis for the merged cluster and then apply the Sun Alert Cluster inclusion criteria going forward.
The merged Recommended OS Cluster was initially released on June 4th, 2010. The download link (target) file name of the merged cluster will be the same as the old "Recommended" Cluster, e.g. 10_Recommended.zip, to minimize the changes users need to make to automated download scripts.
Customers who have traditionally downloaded the Sun Alert cluster will need to update download scripts to use the merged cluster file download names as the old Sun Alert cluster are no longer available.
In major maintenance windows, the Best Practice recommendation is
to upgrade to the latest available Solaris Update release or at least to apply the
equivalent Solaris Update Patch Bundle available from the patch cluster download page.
In both cases, the latest Recommended OS Cluster should also be applied as it will contain any additional Solaris OS Security, Data Corruption, and System Availability fixes released since the Solaris Update contents were finalized. Solaris Updates are intensely tested, and hence this strategy provides a well tested, stable, and feature rich baseline for production systems.
In between major maintenance windows, the Best Practice recommendation is to try to keep as up to date as
possible with the contents of the merged Recommended OS Cluster during
minor maintenance windows.
Let's look at an example, to make the rationale for the change clearer:
In the old model, if a security vulnerability in /usr/bin/ls is fixed in patch 123456-03, then both the old Recommended and Sun Alert clusters will initially include it. If code interdependencies caused by subsequent code putbacks - e.g. the major Trusted Solaris Extensions feature - result in the contents of the "/usr/bin/ls" patch 123456-07 being accumulated into a feature Kernel patch associated with a Solaris 10 Update, e.g. 234567-14, then the old "Recommended" Cluster would include 234567-14 instead of 123456-03, even if 234567-14 contained no additional fixes for Sun Alert issues (i.e. Security, Data Corruption, or System Availability issues) compared to 123456-03. The "Recommended" flag on SunSolve, in patchdiag.xref, and elsewhere would be updated every time a patch revision obsoletes the original patch, even though these later patch revisions contain no additional fixes to Sun Alert issues. This can lead to customers who try to stay up to date with "Recommended" patches patching more content and potentially more often than is really necessary. In contrast, 123456-03 would remain in the Sun Alert cluster for as long as no additional fixes for Sun Alert issues are contained in obsoleting patches.
In the new merged Recommended OS patch cluster model, while the starting point will be the old "Recommended" Cluster as of the start of June 2010 (to avoid dropping the "Recommended" from any patches, which might cause confusion), further changes to the cluster will follow the old Sun Alert cluster inclusion criteria - that is, the merged Recommended OS patch cluster contents and corresponding Recommended flag in SunSolve and patchdiag.xref will only be updated if a new patch delivers a new fix for a Sun Alert issue. This means that only patches which we really recommend will be included in the Recommended OS patch cluster and flagged as Recommended in SunSolve and patchdiag.xref. Since the rate of change will be less, it'll be easier for customers to see what's really recommended and allow more informed decisions regarding when to apply such patches.
Please note that this change has nothing whatsoever to do with the integration into Oracle. This is an enhancement I've been looking to do for some time to avoid the confusion caused by having two very similar patch clusters and a corresponding "Recommended" flag which was updated much more frequently than was necessary.
My team has been working with known consumers of the "Recommended" patch flag such as TLP, Ops Center, 'smpatch', Update Manager, SRAS, EIS, and 'pca' to ensure that the transition goes smoothly.
For example, TLP and 'pca' consume the patchdiag.xref file which up to now typically only contained entries for top-of-tree (latest) patch revisions. From June 4th 2010, patchdiag.xref will contain whatever revision of a patch is flagged as "Recommended" as well as the top-of-tree patch revision. Hence, a single base PatchID, e.g. 123456, may have two entries in the file, e.g. 123456-03 marked "R" for Recommended and "O" for Obsolete and 123456-08 which is the latest revision of that patch but which won't carry the "R" flag as it contains no additional Sun Alert fixes over rev-03.
From my discussion with Martin Paul, author of 'pca', my understanding is that initially, he plans to propagate the "R" flag forward to the latest patch revision in his 'pca' metadata as currently 'pca' only handles the latest revision of patches, but he'll look at some stage in the future to leverage the more precise "Recommended" flag data we'll be providing with this change.