Merging the Solaris Recommended and Sun Alert Patch Clusters

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.

Comments:

On 05/21/10 10:24, Martin Paul wrote:
> Hi Gerry,
>
> I see that you have published a blog entry already, explaining the planned changes to
> the clusters. It's well written and complete, including the part about PCA.
>
> There's just one thing I find a little bit contradicting:
>
> The merged Recommended OS Clusters will update on the same cadence as
> the old Sun Alert clusters, which is typically about twice a month.
>
> We will continue to update the merged Recommended OS Cluster whenever
> a patch matching the inclusion criteria is released.

Both statements are correct. We will continue to update the merged cluster whenever a patch matching the inclusion criteria is released, which in practice works out at about twice a month.

> So will it be updated only in a certain cadence, no matter whether a new recommended
> patch appears in the meantime, or will any new patch trigger creation of a new cluster
> immediately?

Any patch meeting the inclusion criteria will immediately trigger the creation of a new cluster. This is the same as the current process.

> [Sending this by e-mail, but you can edit and publish it as a comment on the blog as
> well, if you like]

Sure, I'll add it as a comment to the blog entry. Thanks Martin!

> Martin.

Posted by Gerry Haskins on May 21, 2010 at 04:34 AM IST #

PCA users which use the current stable release (20100607-01) have two options:

"pca -l missingr" will show the \*latest\* revision of each "Recommended" patch, similar to the old Recommended Patch Cluster.

"pca --minimal -l missingr" will show the \*minimum\* revision of each "Recommended" patch. This command should return a list of all patches from the new cluster which are not installed. Be aware that "--minimal" is only experimental at this point, and its behavior might be altered or integrated into some other option in the future.

Overall, joining the clusters was a good idea, and using the minimum revision for all patches should reduce the amount of patches installed during a regular patch cycle with the "Recommended" set. Including the necessary information was crucial for a tool like PCA, and very welcome. Thanks!

Martin.

Posted by Martin Paul on June 11, 2010 at 07:55 AM IST #

Hi Gerry,

Hows things? been a while, hope all is well.

quick question about the Recommend Cluster, I have recently started using OPs Centre
and have been told when patching systems it is better to use EIS baseline patches rather than the download Recommended clusters, is there a big difference between the two?

cheers,
Paul

Posted by Paul Tsang on June 18, 2010 at 02:29 AM IST #

Can this be updated to reflect the new Oracle CPU updates? Thanks.

Posted by Warwick Brown on July 15, 2010 at 03:14 AM IST #

Hi Paul,

Good to hear from you!

As in mentioned in previous postings, the Recommended Cluster and the EIS (Enterprise Installation Standards) and OpsCenter patch baselines are closely related. The OpsCenter patch baselines are the EIS patch baselines. The EIS patch baseline is a superset of the Recommended Cluster.

The EIS team take the Recommended Cluster at the end of each month and then add extra patches to it which address issues which are support call generators but which do not meet the Sun Alert criteria for inclusion in the Recommended Cluster.

My team is currently evaluating these additional patches with a view to including them in the Recommended Cluster going forward as I believe there should be a single set of patches which Oracle consistently recommends for Solaris, rather than multiple variations on a theme which causes confusion as to which one to use.

The EIS team also includes patches for some additional products, including Sun Cluster, SunVTS, SAMFS, and QFS.

Posted by Gerry Haskins on July 16, 2010 at 10:43 AM IST #

Thank you

Posted by park cheon duck on August 05, 2010 at 08:10 AM IST #

Hi Gerry Haskins,

It is noticed that some obsoleted patch's still included in the latest Recommend Patch Cluster for Solaris 10 as shown below:

....
141874-09 Obsoleted by: 141874-10 SunOS 5.10: fp patch
142436-05 Obsoleted by: 142436-06 SunOS 5.10: mail, sendmail and passwd patch
142900-13 Obsoleted by: 142900-14 SunOS 5.10: kernel patch
143128-04 Obsoleted by: 143128-05 SunOS 5.10: mpt patch
....

So, is that any reason for such arrangement?

Thanks & Regards
Paul

Posted by Paul Liong on August 17, 2010 at 07:46 PM IST #

Hi Gerry,

Thanks for this article. You have mentioned that "The EIS patch baseline is a superset of the Recommended Cluster." but you also mentioned that "going forward as I believe there should be a single set of patches which Oracle consistently recommends for Solaris".

So:

- May we know what is the time line on this?
- Am I correct to say that once we have that we no longer have to look forward to a Sun/Oracle partner for EIS patch CD?

Thanks n Regds,
Nitin

Posted by Unix Group on August 22, 2010 at 09:36 PM IST #

We have been using xVM Ops Center to apply the latest Baseline patches to our dev and test servers, then to production the following month. We found that the latest Solaris 10 JKP 142900-xx did not get installed with the July Baseline. Looking back through some of the older baselines I do see some revisions of this patch in some of the baselines but not others. Shouldn't the latest baseline include the minimum revision of this patch which addresses a Sun Alert? I would assume one of the 15 revisions would address an Alert. I also note the following statement in an earlier entry which would indicate that it should be included.

"The EIS team take the Recommended Cluster at the end of each month and then add extra patches to it which address issues which are support call generators but which do not meet the Sun Alert criteria for inclusion in the Recommended Cluster."

But then I've also seen that the Recommended Baselines do not include the Security Baseline patches from the Oracle Document "Patching the Solaris OS Using Sun Ops Center 2.5"

"Solaris Baselines

A baseline is a dated collection of patches, patch meta data, and tools. Sun releases baselines for the Solaris OS on a monthly basis. When you install the patches of a baseline on a host, the host is considered compliant with that baseline. Using baselines enables you to easily check the patch level of your hosts. For example, to easily learn the patch level of your hosts, install some test hosts with a particular baseline. Test these hosts for a period of time to check if the patches in the baseline are stable enough to be used on your production hosts. If the testing reveals that the baseline is stable, you can install the same baseline that you tested on your production hosts.

Each dated baseline contains these three patch sets:

\*

Full: Includes the recommended patches for the specific Solaris version and the selected patches for other unbundled Sun products, such as Java 2 Platform, Standard Edition (J2SE platform), Sun Cluster software, and Solaris Volume Manager software.
\*

Recommended: Includes the Solaris OS recommended patches for the specific OS version.
\*

Security: Includes all the security patches, including the platform-specific patches and patches for other Sun products, such as J2SE platform and Sun Cluster software. The Security baseline is not a subset of the Recommended baseline."

Posted by David Delano on September 14, 2010 at 03:23 PM IST #

Hi David,

Apologies for my delay in responding.

Yes, the Recommended Patch Cluster will always contain all available patches which address Sun Alert issues (i.e. Security, Data Corruption, and System Availability issues). If you enter "142900" into PatchFinder, http://sunsolve.sun.com/patchfinder, you'll see revisions -07, -08, and -12 deliver new security fixes, and hence these revisions would have been included in the Recommended Patch Clusters at that time. (These have since been superseded by 142909-17, see http://blogs.sun.com/patch/entry/solaris_10_kernel_patchid_progression.)

Since EIS and the Ops Center baselines (they're one and the same thing) are a superset of the Recommended Patch Cluster, they too should have included these patch revisions (or later).

Regarding Full, Recommended, Security - Full is a superset of the Recommended Patch Cluster, Recommended is the Recommended Patch Cluster, and Security is the security sub-set - i.e. excluding Data Corruption, System Availability fixes, etc.

Please let me know if I'm missing the point of your questions/comment.

Best Wishes,

Gerry.

Posted by Gerry Haskins on October 12, 2010 at 09:56 AM IST #

Hi Nitin,

Apologies for my delay in responding.

Initially, we are working to have a common set of Solaris OS patches which will be delivered by the Recommended Patch Cluster, EIS (Enterprise Installation Standards), and by extension, Ops Center. I'm not going to publish a timeline for this, but we're actively working on it.

We may or may not expand this beyond OS patches (e.g. SAMFS, QFS, Solaris Cluster) at some point in the future. (EIS contains these today.)

Remember EIS is far more than just a patch set. It's a whole installation methodology. But if you are just interested in the patch set for Solaris OS patches, then yes, the Recommended Cluster should provide you with the same thing once we're finished.

Best Wishes,

Gerry.

Posted by Gerry Haskins on October 12, 2010 at 11:50 AM IST #

Hi Paul,

Apologies for my delay in responding.

As detailed in the posting above, we are now including the specific revisions of patches which fix SunAlert issues in the Recommended Cluster, rather than simply taking the latest available revision of such patches.

Since by definition, a patch is obsolete if it isn't the latest revision, you see the "obsoleted by" verbiage in some of the patch synopses.

Note, this is using the Sun terminology for "obsolete", which equates to the Oracle term "superseded".

Posted by Gerry Haskins on October 12, 2010 at 12:00 PM IST #

Hi David,

I've been following up with my colleagues in EIS and Ops Center regarding your comment that some Kernel patches went AWOL from the EIS and Ops Center baselines in July. Apparently there was a temporary issue in July and you are correct that the Kernel patch was accidentally dropped. I haven't been able to determine the root cause yet as some of the players are on vacation at the moment, but it looks probably it was human error and seems unlikely to be repeated.

Best Wishes,

Gerry.

Posted by Gerry Haskins on October 14, 2010 at 08:25 AM IST #

Hi David,

My colleague has returned from vacation and the explanation for the Kernel patch being accidentally dropped from the July Baselines was that it was a knock-on effect of the changes I made to the Recommended Cluster in May (see http://blogs.sun.com/patch/entry/merging_the_solaris_recommended_and), whereby a script used to create the EIS patch set baselines malfunctioned.

From my colleague:

"Because that's the root cause: The lower revs with a path 10/10_Recommended got filtered out, so they did not appear in the Recommended Subset of the July Baseline.

Customer[s] which followed the recommendation by the field to use the Full Baseline, were not effected. Only Customers selecting the "Recommended" named subset did not get all patches, the kernel patch was just one patch out of a longer list ...

Workaround to recommend to Customer: Always use the \*Full\* Baseline not one of the subsets !"

The faulty script has since been corrected.

Best Wishes,

Gerry.

Posted by Gerry Haskins on October 15, 2010 at 08:00 AM IST #

Gerry,

Thanks for following up on my questions. I still have a concern about the statement from the Oracle Document "Patching the Solaris OS Using Sun Ops Center 2.5", that states "The Security baseline is not a subset of the Recommended baseline." as I mentioned in my Sept. 14 posting. We do want to be installing the latest security patches. But your followups do explain why the kernel patch was missing.

Also, we generally do not apply the Full Baseline, as it patches/updates some things that we might not want updated, (i.e. java 5 to 6).

Posted by David Delano on October 20, 2010 at 08:07 AM IST #

Gerry,

I tried to instal 4Q2010 Patch bundle on a Solaris 10 server.
All patches installed OK, except just the Kernel patch 142909-07.
The log says:

Validating patches...

Loading patches installed on the system...

Done!

Loading patches requested to install.

Version of package SUNWkvm from directory SUNWkvm.us in patch 142909-17 differs from the package installed on the system.
Version of package SUNWcakr from directory SUNWcakr.v in patch 142909-17 differs from the package installed on the system.
Version of package SUNWcpc from directory SUNWcpc.v in patch 142909-17 differs from the package installed on the system.
Version of package SUNWkvm from directory SUNWkvm.v in patch 142909-17 differs from the package installed on the system.
Version of package SUNWdrr from directory SUNWdrr.us in patch 142909-17 differs from the package installed on the system.
Version of package SUNWefc from directory SUNWefc.us in patch 142909-17 differs from the package installed on the system.
Architecture for package SUNWiopc from directory SUNWiopc.v in patch 142909-17 differs from the package installed on the system.
Version of package SUNWcakr from directory SUNWcakr.us in patch 142909-17 differs from the package installed on the system.
Version of package SUNWcpc from directory SUNWcpc.us in patch 142909-17 differs from the package installed on the system.
Done!

The following requested patches have packages not installed on the system
Package SUNWust1 from directory SUNWust1.v in patch 142909-17 is not installed on the system. Changes for package SUNWust1 will not be applied to the system.
Package SUNWhxge from directory SUNWhxge in patch 142909-17 is not installed on the system. Changes for package SUNWhxge will not be applied to the system.
Package SUNWniumx from directory SUNWniumx.v in patch 142909-17 is not installed on the system. Changes for package SUNWniumx will not be applied to the system.
Package SUNWnxge from directory SUNWnxge.u in patch 142909-17 is not installed on the system. Changes for package SUNWnxge will not be applied to the system.
Package SUNWaac from directory SUNWaac in patch 142909-17 is not installed on the system. Changes for package SUNWaac will not be applied to the system.
Package SUNWust2 from directory SUNWust2.v in patch 142909-17 is not installed on the system. Changes for package SUNWust2 will not be applied to the system.
Package SUNWrds from directory SUNWrds in patch 142909-17 is not installed on the system. Changes for package SUNWrds will not be applied to the system.
Package SUNWnxge from directory SUNWnxge.v in patch 142909-17 is not installed on the system. Changes for package SUNWnxge will not be applied to the system.
Package SUNWldomr from directory SUNWldomr.v in patch 142909-17 is not installed on the system. Changes for package SUNWldomr will not be applied to the system.
Package SUNWdcar from directory SUNWdcar in patch 142909-17 is not installed on the system. Changes for package SUNWdcar will not be applied to the system.
Package SUNWio-tools from directory SUNWio-tools in patch 142909-17 is not installed on the system. Changes for package SUNWio-tools will not be applied to the system.
Package SUNWpsm-ipp from directory SUNWpsm-ipp in patch 142909-17 is not installed on the system. Changes for package SUNWpsm-ipp will not be applied to the system.
Package SUNWigb from directory SUNWigb in patch 142909-17 is not installed on the system. Changes for package SUNWigb will not be applied to the system.
Package SUNWs8brandu from directory SUNWs8brandu in patch 142909-17 is not installed on the system. Changes for package SUNWs8brandu will not be applied to the system.
Package SUNWixgbe from directory SUNWixgbe in patch 142909-17 is not installed on the system. Changes for package SUNWixgbe will not be applied to the system.
Package SUNWhermon from directory SUNWhermon in patch 142909-17 is not installed on the system. Changes for package SUNWhermon will not be applied to the system.
Package SUNWs9brandr from directory SUNWs9brandr in patch 142909-17 is not installed on the system. Changes for package SUNWs9brandr will not be applied to the system.
Package SUNWn2cp from directory SUNWn2cp.v in patch 142909-17 is not installed on the system. Changes for package SUNWn2cp will not be applied to the system.
Package SUNWmrsas from directory SUNWmrsas in patch 142909-17 is not installed on the system. Changes for package SUNWmrsas will not be applied to the system.
Package SUNWippcore from directory SUNWippcore in patch 142909-17 is not installed on the system. Changes for package SUNWippcore will not be applied to the system.
Package SUNWldomu from directory SUNWldomu.v in patch 142909-17 is not installed on the system. Changes for package SUNWldomu will not be applied to the system.
Package SUNWs9brandu from directory SUNWs9brandu in patch 142909-17 is not installed on the system. Changes for package SUNWs9brandu will not be applied to the system.
Package SUNWs8brandr from directory SUNWs8brandr in patch 142909-17 is not installed on the system. Changes for package SUNWs8brandr will not be applied to the system.
Package SUNWcry from directory SUNWcry in patch 142909-17 is not installed on the system. Changes for package SUNWcry will not be applied to the system.
Package SUNWmptsas from directory SUNWmptsas in patch 142909-17 is not installed on the system. Changes for package SUNWmptsas will not be applied to the system.

Checking patches that you specified for installation.

Done!

Do you have any ideas about this issue?

Thanks in advance.

Tony, from Argentina.

Posted by Tony on December 18, 2010 at 02:07 PM GMT #

Hi Tony,

There's insufficient information there to debug the issue.

Please email me, gerry.haskins@oracle.com, the the complete verbose install log from under /var/sadm/<install_date> and I'll look into it for you.

Best Wishes,

Gerry.

Posted by Gerry Haskins on January 06, 2011 at 09:30 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today