Tuesday Nov 08, 2011

Solaris 11 released, 2 days early

Today, we launch Solaris 11 in New York City.

Work on Solaris 11 started 7 years ago, as soon as Solaris 10 reached "code freeze".

About 6 years ago in a Solaris P-Team (Product Team) meeting, someone raised the repeatedly asked question as to when we planned to release Solaris 11.

A slightly exasperated Jeff Jackson said 11/11/11, half jokingly, half seriously.  It made sense.  It was in the right ballpark considering all the radical changes the architects wanted to make in Solaris 11.  And what better date to launch Solaris 11 ?

175 bi-weekly builds and two release candidate respins later, and we're releasing Solaris "Nevada" build snv_175b, officially known as Solaris 11.  But 2 days early.  Ooops!  I must admit to having been tempted to file a "Stopper" bug to cause enough of a smoke screeen to delay the release by two days.  But early is good.  So 11/9/2011 it is.

The Solaris 11 Tech Lead, David Comay, has posted some excuses - er, I mean "reasons" - on his blog as to why we're releasing 2 days early.  See http://blogs.oracle.com/solaris for further information.

Having arrived in New York Tuesday afternoon, I went to the 9/11 memorial to pay my respects. 

May I just say, well done New York!  Well done America! 

It's a truly excellent and moving memorial.  The sound of the water falling and the patterns it makes as it falls into the abyss in the center of the very footprint where the twin towers stood is poignant symbolism.  It's impossible not to be moved.

And the fact that all around the memorial is still a construction site, with all the sounds of rebuilding what was destroyed, is very apt indeed.

Evil will not triumph.  Good will overcome.

It puts our humble efforts in stark perspective.

I hope you enjoy Solaris 11.  It's our most radical Solaris release since SunOS 2.0.  Virtualization built in.  Cloud built in.  Architected for maintainability.  Scalability beyond your imagination (and mine!). 

I'll be presenting an updated version of my Solaris 11 Customer Maintenance Lifecycle presentation at the DOAG (Deutsche Oracle Anwender Gruppe) Conference in Nuremberg, Germany, next week.  I hope to meet some of you there.

I'll then post the presentation here on my blog.

Let the fun begin!  Enjoy!

Best Wishes,

Gerry.

Saturday Jul 02, 2011

A Solaris Recommended Patchset to bind them all

I've long been of the opinion that there should be a single generic set of Solaris recommended patches which customers are consistently recommended to install in proactive maintenance windows for issue prevention. It's something I've been working towards for quite a while.

A collaborative effort between the Software Patch Services, Enterprise Installation Standards (EIS), Sun Risk Analysis System (SRAS) - now renamed Oracle Risk Analysis Services (ORAS) - and the Explominer team in the Oracle Solaris Technical Center (TSC), has achieved this goal with the creation of the Recommended Patchset for Solaris.  

Up until now, while the Solaris OS Recommended Patch Cluster was the core basis for Solaris patch recommendations, various teams tended to recommend their own favorite patches on top of this core set.  This wasn't just by whim.  Each team was looking at patching from a slightly different angle - for example various angles of proactive patching (issue prevention) versus reactive patching (issue correction).

The Recommended Patchset for Solaris is the result of the combined wisdom of the various teams.  It is designed for proactive patching (issue prevention).  The contents are generic and should be suitable for most customer configurations.  You should still read the README file and follow its instructions to ensure all of the patches included are appropriate to your specific environment.  You should test the patchset on a test system which closely mimics your production systems prior to deployment. 

You may still legitimately be asked by support to install additional patches to fix issues specific to your environment in reactive maintenance situations (issue correction).  But this should only be after due diligence to ensure that such patches are likely to fix the specific issue encountered.

The Recommended Patchset for Solaris is the new name for the Solaris OS Recommended Patch Cluster.  It's available from MOS (including 'wget'), EIS, Ops Center, etc.  We've changed the name to use the Oracle standard terminology "patchset".  I never liked the name Solaris Patch Cluster as there was a risk of it being confused with the Solaris Cluster product to which it bears no relation.  In due course other patch "clusters" and patch "bundles" are likely to transition to the name "patchset". 

The install script and code word needed to invoke it (which is contained in the README file) have been renamed to reflect the name change from "cluster" to "patchset". 

Customers who have installed the Solaris OS Recommended Patch Cluster may notice the additional patches included in the Recommended Patchset for Solaris the first time they install it.  After that, it'll be business as usual.  Many of these additional patches are already pre-applied into Solaris Update releases, so customers on later update releases should see little difference.

As before, the Recommended Patchset for Solaris will continue to be updated whenever a patch matching its inclusion criteria is released.  This can happen several times a month.  Just take the latest which matches your proactive maintenance window schedule. 

And as before, once a quarter, the Recommended Patchset for Solaris will be archived and renamed as the Critical Patch Update in line with standard Oracle practice.  (See previous blog postings.)

To create the Recommended Patchset for Solaris, we took the Solaris OS Recommended Patch Cluster and analyzed the additional Solaris patches which the Explominer team recommend be added on top of it for the monthly EIS patch baselines. Where those additional patches added real value - i.e. were of significant benefit to many customers - we added them to the recommended patch set.  Where they didn't add real value, we discarded them.  We then made sure that a system on which the resultant Recommended Patchset for Solaris was installed passed with a clean bill of health from the ORAS risk analysis audits.

So now, the Solaris OS patches in the EIS patch baselines will be the Recommended Patchset for Solaris with input from the Explominer and other teams included, and will be tested with ORAS.  These are the patch baselines available in Ops Center.  We have set up a panel of patch experts from the teams mentioned above to adjudicate on future potential additions to the Recommended Patchset for Solaris.

Previously, the criteria for including a patch in the Solaris OS Recommended Patch Cluster was quite strict: a patch had to address a Security, Data Corruption, or System Availability issue; be a patch utilities patch, or be required by the above.  In future, other patches which add real value for many customers may be included - for example, a patch for a commonly used driver which delivers significant performance improvements.  The goal remains the same - to include the most critical generic patches which we recommend customers install in proactive maintenance windows for issue prevention.

Additional patches outside of the patchset may still be required:

  • For other Oracle products - the Recommended Patchset for Solaris only includes Solaris Operating System patches.  Other products such as Oracle Solaris Cluster, Oracle Solaris Studio, Oracle Database, etc., may have their own patch recommendations.  The monthly EIS update includes patch sets for Oracle Solaris Cluster, SAMFS, QFS, and SunVTS in addition to the Recommended Patchset for Solaris.
  • For specific platforms - for example a Solaris driver patch if a particular network card is installed or where firmware updates are required
  • For specific configurations - for example if the system is connected to 3rd party storage solutions such as EMC Powerpath or Veritas
  • For specific issues in your configuration - for example, break/fix situations where an additional patch fixes the issue encountered

You can download the patchsets or view their Readmes directly, using the following links:

To downloads the patchsets (you must be logged into MOS):

https://updates.oracle.com/patch_cluster/10_Recommended.zip
https://updates.oracle.com/patch_cluster/10_x86_Recommended.zip

To download the patchset Readme files (no need to be logged into MOS):

https://updates.oracle.com/patch_cluster/10_Recommended.README
https://updates.oracle.com/patch_cluster/10_x86_Recommended.README

The above works for both flash and non-flash (html) MOS users.   Just substitute "9" for "10" to get the Solaris 9 Recommended patchsets and Readmes.

You can also download the patchsets using 'wget' for scripted access as normal.  (See previous blog postings.)  For example, the download filename for Recommended Patchset for Solaris 10 SPARC is still 10_Recommended.zip.

If, like me, you like to know how to do things from first principles, here's the way to construct the search on My Oracle Support:

For Flash compatible systems (full function MOS version):

  1. Login to My Oracle Support (MOS), https://support.oracle.com
  2. Click on the "Patches&Updates" tab
  3. Click on "Product or Family (Advanced Search)
  4. Type "Solaris Operating System" into the product search box
  5. Select the Releases you are interested in - e.g. Solaris 10 Operating System and Solaris 9 Operating System
  6. Select the Platforms you are interested in - e.g. Oracle Solaris on SPARC (64-bit) and Oracle Solaris on x86-64 (64-bit)
  7. Click on the "+" sign next at the end of the "Platforms" line to add additional search criteria
  8. Click of "Select Filter" and select "Type" from the drop-down menu
  9. Select "Patchset"
  10. Click "Search" 

For non-Flash users (html MOS version):

  1. Login to the html version of My Oracle Support, https://supporthtml.oracle.com
  2. Click on the "Patches & Updates" tab
  3. Click on the Advanced Search tab in the search box
  4. Type "Solaris Operating System" in the product search box 
  5. Select the Releases you are interested in - e.g. Solaris 10 Operating System and Solaris 9 Operating System
  6. Select the Platforms you are interested in - e.g. Oracle Solaris on SPARC (64-bit) and Oracle Solaris on x86-64 (64-bit)
  7. For Type, select "Patchset"
  8. Click Search

MOS remembers your previous selections and they'll be shown top of each drop down menu on subsequent invocations.  You can also save searches for future re-use.

I want to thank Don O'Malley, Ed Clark, Howard Mills and the EIS team, Juergen Schleich and the Explominer team, Dr. Rex Martin and the ORAS team, and Rob Hulme and Walter Fisch from the Oracle Technical Support Center (TSC) for all their work in making a single consistent Recommended Patchset for Solaris a reality.

As always, I'm interested to hear your feedback.

Best Wishes,

Gerry.

Tuesday Oct 12, 2010

Oct 2010 Solaris OS CPU now available

The October 2010 Solaris OS CPU (Critical Patch Updates) containing all available Security, Data Corruption, and System Availability fixes are now available from My Oracle Support (MOS) and SunSolve.

See http://www.oracle.com/technetwork/topics/security/alerts-086861.html and in particular Document 1446032.1 on My Oracle Support (MOS), http://support.oracle.com, which includes CVE mappings for Oracle Sun products. 

To access the Solaris OS CPUs on MOS, login, select the "Patches & Updates" tab and in the "Patch Search" box, click on "Product or Family (Advanced Search)".  Select "Solaris Operating System" from the product drop down menu, select the Release(s) you are interested in, e.g. "Solaris 10 Operating System", select "Type" and "Patchset" from the drop down menus on the next line, and click "Search".  This will show all the available patch clusters and bundles for your search criteria.  The October 2010 CPUs have titles of the form "CPU OS Cluster 2010/10".

The Solaris OS CPUs are archived copies of the Solaris OS Recommended Patch Clusters.  See http://blogs.sun.com/patch/entry/solaris_critical_patch_updates_cpus for further details.

Best Wishes,

Gerry Haskins
Director, Software Patch Services

Thursday May 20, 2010

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.

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