Wednesday Oct 12, 2011

Live Upgrade document updated and simplified

I forgot to let you know, but a couple of months ago, my colleagues, Don O'Malley and Ed Clark updated the Oracle Solaris Live Upgrade (LU) document describing the pre-requisites for Live Upgrade.

The original document was pretty convoluted and required several cups of strong coffee to parse.  The updated version is a little easier to understand, even without caffeine.

Thanks also to Beth Barrett, Rick Ramsey, and Jon Bowman who helped make this happen.

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.

Wednesday Nov 04, 2009

Solaris 10 10/09 Patch Bundle now available

I'm delighted to announce that the Solaris 10 10/09 (Update 8) Patch Bundle is now available for download by customers with a Solaris support contract.

Each Solaris Update Patch Bundle contains the equivalent set of patches which are pre-applied into the corresponding Solaris Update release image.

It is provided to enable customers who cannot upgrade for whatever reason to be able to patch systems up to the same patch level as the Update release.

Each Solaris Update is intensely tested as a unit by myriad QA teams across Sun.  Therefore, Solaris Updates and their corresponding Solaris Update Patch Bundles provide good quality "baselines" on which customers can standardize their deployments.

Standardizing deployments on such "baselines" also provides customers with a "safety in numbers" effect, as any pervasive issues are likely to be found and fixed quickly, so each customer benefits from the experience of others.

The Solaris Update Patch Bundle brings all existing packages up to the same software level as the Update release.   Any features which are entirely contained in pre-existing packages, such as Zones and ZFS functionality, are entirely available in patches and hence applying the Solaris Update Patch Bundle brings them up to the same functional level as the Update release.

However, installing the Patch Bundle is not completely equivalent to upgrading to the corresponding Solaris Update as the Patch Bundles do not include any new packages introduced in the Solaris Update release image.  Therefore, any new features which are dependent upon new packages will not be available by applying the Solaris Update Patch Bundle.

Here's a summary of the new packages in Solaris 10 10/09 (Update 8) which are not available in the Solaris 10 10/09 Patch Bundle:

SUNWhxge: SUN 10Gb hxge Ethernet Network Adapter Driver
SUNWio-tools: Administrative tools to modify the pci/pcie fabric
SUNWmrsas: LSI MegaRAID SAS2.0 HBA driver
SUNWpixman: Pixman Library
SUNWntp4r: NTPv4 (root)
SUNWntp4u: NTPv4 (usr)
SUNWntp4S: NTPv4 (source)
SUNWmptsas: LSI MPT SAS2.0 HBA driver

Please remember to apply the latest Sun Alert Cluster on top of the Solaris Update Patch Bundle in order to get all Solaris OS security, data corruption, and system availability fixes released since the final build of the Update release.

Please see previous blog entries for further details on Solaris Update Patch Bundles.

Top Tip: If you are installing in a zones environment, make sure you have the latest patch utility patches installed and Zones Parallel Patching configured before you apply a Solaris Update Patch Bundle as Zones Parallel Patching will improve non-global zone patching performance by ~300%.   See this blog entry for details.

BTW: There is no need to take any action to enable "Turbo-Charging SVR4 Package Installation" as the necessary patches are installed early on when installing the Solaris 10 10/09 Patch Bundle and will be automatically enabled for subsequent patch application when the bundle is applied to the live boot environment.  While "Turbo-Charging" has little affect when installing most patches, it does significantly speed up the application of a small number of older patches with non-optimized deletes file processing install scripts and so does speed up the Solaris 10 10/09 Patch Bundle installation somewhat.

Best Wishes,

Gerry.

Thursday Oct 22, 2009

Major PatchFinder enhancements available now!

I'm delighted to announce the release of the 2nd phase of our PatchFinder tool enhancements, which include:

  • The ability to see the "Entitlement Classes" of patches and get information on the support contracts necessary to access and use them.  
  • A "Patch Basket", into which you can add selected patches from multiple search results.
  • When you click on the "Go To Patch Basket" link, the patch dependencies for all the patches you have in your Patch Basket will be dynamically resolved, including filtering out redundant dependencies.   This saves you having to manually transfer patch dependency trees!   If you already have some of these installed, you can de-select them.
  • You can then click the "Download Selected" button to download a 'wget' script and instructions which you can use to download all of the selected patches from SunSolve.   Once you make sure you install the latest version of the patch utilities patch first, you can then use "patchadd -M" to install all the patches in the correct order on your target system.

Sample Searches

Let's assume you applied the Solaris 10 SPARC Recommended Patch Cluster on August 15th 2009.  So what Solaris 10 SPARC Recommended Cluster patches have been released since then ?   To find out, for "OS Release" select "Solaris 10", for "Architecture" select SPARC", select "Recommended Only", and select August 15th 2009 from the calendar beside the "Released After" box.   (Select view 50, 100, or 200 to see the entire list in one page.)   You can then decide if you want to download some of all of these patches to add to your system.  Coupled with the dynamic dependency resolution and 'wget' download capability, this effectively enables you to create customized patch clusters for yourself with just the patches you need, rather than having to download the entire Recommended Cluster each time.

Or you could bookmark a search to show you all the patches released in the last day: Simply enter the number "1" into the "Released After" box and select any other selection criteria you are interested in and click "Search".  Depending on timezone differences with respect to California and your local time of day, you may need to enter the number "2" in the "Released After" box.

You can also use PatchFinder to see what Solaris 8 Vintage patches Sun has released since Solaris 8 entered End-Of-Service-Life (EOSL) Phase 2 on April 1, 2009.   Simply select "Solaris 8" for "OS Release", select "OS Patches Only" and click "Search".  Since the patches are listed in date order, most of the patches with a release date after April 1, 2009, including patches delivering security fixes, will have the "Solaris8VintageSoftwareUpdate" Entitlement Class associated with them if you mouse-over the red padlock symbol shown for them (assuming you don't have a Solaris 8 Vintage Patch Service Plan associated with your Sun Online Account).   You will see a couple of non-Vintage patches released after April 1, 2009.  This is a transition phase and these patches address issues escalated by customers prior to April 1, 2009.

Some other sample searches to satisfy your curiosity:

Ever wondered how many patches Sun has ever released ?   To find out, simply select "Show Obsolete" and then click "Search".

How many current "active" patches does Sun have ?   De-select "Show Obsolete" and then click "Search".

How many patches can be installed on Solaris 10, including application product patches ?   For "OS Release" select "Solaris 10" (and optionally "Show Obsolete" ) and then click "Search".

How many current "active" Solaris 10 OS patches there are for SPARC ?  For "OS Release" select "Solaris 10", for "Architecture" select "SPARC" and then select "OS Patches Only" and then click "Search".

Patch Access Entitlement Classes

You need a support contract or have hardware under warranty in order to access and use patches.

When you look at the list of patches returned from a search, a green open padlock symbol shows the patches you have access to thanks to the support contracts which you currently have associated with your Sun Online Account (SOA).  A red closed padlock shows the patches which you are not currently entitled to access or use with the support contracts you currently have associated with your Sun Online Aaccout.

You can mouse-over these symbols for any patch and it will show you the "Entitlement Classes" associated with the patch. 

Read the "What is it?" help link and the SunSolve "How Entitlement Works" wiki to find out about the support contracts which you need to buy in order to access and use these patches.

Feedback

I hope you'll find the new PatchFinder enhancements useful.

We are really interested in your feedback as to what further enhancements you would like to see, so feel free to post your comments here or else use the feedback link on the PatchFinder page.

Many thanks to Brian Kidney and Julien Colomb for all their work on this - nice work guys!

Wednesday Sep 09, 2009

Patches for "Turbo-Charging SVR4 Package Install" are now available

I am delighted to announce that Casper Dik's "Turbo-Charging SVR4 Package Install" feature enhancement is now available by downloading and installing the following patches:

119254-70 (SPARC) / 119255-70 (x86): Patch utilites patch
121428-13 (SPARC) / 121429-13 (x86): Live Upgrade Zones Support Patch
121430-40 (SPARC) / 121431-41 (x86): Live Upgrade Patch
124630-28 (SPARC) / 124631-29 (x86): System Administration Applications, Network, and Core Libraries Patch

It is important to apply 119254-70 (SPARC) / 119255-70 (x86) and 121428-13 (SPARC) / 121428-13 (x86) if the system is running non-global zones.  Otherwise booting newly installed zones will fail until the pkgserv daemon exits, about 5 minutes after zoneadm install finished.  Zones which were already installed can be booted as expected.

"Turbo Packaging" is designed to dramatically improve the performance of install, upgrade, Live Upgrade, and zone creation on Solaris 10.  It delivers only a small improvement for patching performance.   (See my Zones Parallel Patching blog entry for information on dramatic patching performance improvements.)

For background reading on the "Turbo Packaging" feature, please see
http://www.opensolaris.org/jive/thread.jspa?messageID=358081 and http://arc.opensolaris.org/caselog/PSARC/2009/173/

The "Turbo-charging SVR4 Package Install" feature will also be included in the forthcoming Solaris 10 Update 8 release and will be documented in the Release Notes for that release.

Great work, Casper - well done!

Wednesday Feb 18, 2009

Cannot patch Solaris 10 from Solaris 8 or 9

I've been asked to post a clarification: 

You cannot patch Solaris 10 from Solaris 8 or 9 as the version of 'patchadd' in Solaris 8 and 9 is totally unaware of how to handle Zones and other Solaris 10 specific features.

If using Live Upgrade to upgrade an inactive boot environment from Solaris 8 or 9 to Solaris 10, you must activate and boot into the Solaris 10 boot environment before patching it.  For example, activate and boot into the Solaris 10 boot environment, and either patch the live boot environment or create another inactive boot environment, and then apply patches to the inactive boot environment.

See http://www.sun.com/bigadmin/features/articles/live_upgrade_patch.jsp for further information.

Wednesday Feb 11, 2009

Now possible to upgrade directly from Solaris 8 SPARC to latest Solaris 10 release

Thanks to my colleague Enda O'Connor, who has made p7zip available for Solaris 8 SPARC, it's now possible to upgrade directly from Solaris 8 SPARC to the latest Solaris 10 Update releases such as Solaris 10 5/08 and Solaris 10 10/08. 

See document 1019995.1 on My Oracle Support (MOS), http://support.oracle.com

Previously, due to the lack of p7zip on Solaris 8, customers needed to perform an interim upgrade to Solaris 9 or an earlier Solaris 10 release before upgrading to the latest Solaris 10 release.

Monday Jan 05, 2009

Stricter Solaris patch entitlement implementation roll-out commencing this week

I've updated this blog entry to avoid causing unnecessary confusion with the current patch entitlement policy now that Oracle has acquired Sun.  

The Solaris patch entitlement policy is available on http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1

BTW: It's important to remember that hardware warranties only provide access to Firmware and hardware driver patches.   Hardware warranties do not cover software support or access to other Solaris patches.

Thursday Jun 19, 2008

More info on patching using Live Upgrade

My colleague, Enda O'Connor, has written another useful article on Big Admin about patching using Live Upgrade, restrictions, and how-to use Live Upgrade to upgrade/patch from Solaris 8 or Solaris 9 to Solaris 10.  See Doc ID 1019995.1 on MOS.

BTW: Searching "Live Upgrade" under 'Search Knowledge Base' on MOS brings up some other good LU articles too.

Tuesday May 13, 2008

Solaris 8 and Solaris 9 Kernel PatchID Sequence

As mentioned in a previous posting, the practice of patch "rejuvenation" to break out large complex patches (typically Kernel patches) into smaller, simpler components going forward has a side effect of making it difficult to follow the sequence of PatchIDs.  If you have the parent patch (e.g. an old Kernel patch), it's not obvious which child patches supercede the parent (e.g. what's the latest Kernel PatchID) as the parent isn't obsoleted by rejuvenation.  Instead, the children of the rejuvenation each specify a Requirement on the parent patch from which they were rejuvenated.

I've listed the Solaris 10 Kernel PatchID Sequence in a previous posting.  For the sake of completeness, here's the Solaris 8 and Solaris 9 Kernel PatchID Sequences (with the most current PatchID top of the list):

Solaris 8 Kernel PatchID Sequence

 SPARCx86
117350-01 to -xx
117351-01 to -xx
requires
requires
117000-01 to -05
117001-01 to -05
requires
requires
108528-01 to -29
108529-01 to 29

Solaris 9 Kernel PatchID Sequence

 

 SPARCx86
122300-02 to -xx
122301-02 to -xx
requires
requires
118558-01 to -39
118559-01 to -39
requires
requires
117171-01 to -17
117172-17 only
requires
obsoletes
112233-01 to -12
112234-04 to -11

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