Patch Corner: Patch news and best practice

Internetnews.com has an interesting article on IBM's X-Force Report which praises Sun for fast fixes and being best for patching the highest percentage of reported security vulnerabilities:  http://www.internetnews.com/security/article.php/3836436/IBMs+XForce+Report+Praises+Sun+for+Fast+Fixes.htm

My colleague, Ed Clark, has made significant improvements to the Solaris 10 Recommended and Sun Alert patch clusters.  These improvements have just been released and are in the current clusters available to contract customers from the Patch Cluster & Patch Bundle Downloads on SunSolve.

Ed's improvements include:

• Filtering out "false negatives" from the patch utility return codes, so that if the cluster install script returns "1", you know you've got a real problem which needs investigating.   As you may know, the Solaris patch utility, 'patchadd', can return errors for some acceptable situations - for example, if the patch is already applied to the system, or a later revision of the patch or a patch which obsoletes it is already applied to the system, or none of the packages in the patch are on the target system (e.g. because a reduced Install Metacluster was used to install it or the system has been security hardened by package removal), etc.   Such conditions are acceptable "errors" which do not usually require further investigation by the user.  By filtering these conditions out, if the 'installcluster' script returns "1", you know it isn't because of one of these acceptable "errors", and therefore you need to look at the logfiles to find out what's gone wrong.  For further information, please see the cluster README and Analyzing a patchadd or patchrm Failure in the Solaris OS.

• The new 'installcluster' script will exit as soon as it encounters an unexpected failure - i.e. not one of the acceptable "errors" mentioned above.  This prevents potentially compounding issues by attempting to apply further patches.
  

• The new 'installcluster' script includes context intelligence for patching operations.   It informs the user when zones need to be halted, and it provides phased installation to handle patches which absolutely require an immediate reboot before further patches can be applied.  Such interim reboots are only needed when patching a live boot environment on a system below Kernel patch 118833-36 (SPARC) / 118855-36 (x86) and well as the earlier interim reboot required on x86 related to 'libc.so' patches and Kernel patch 118844-14.  On systems below these patch levels, the 'installcluster' will stop at the appropriate point when patching the live boot environment, and inform the user to reboot and re-invoke the 'installcluster' script.  (In the old cluster install script, it simply tried to carry on blindly past such interim reboots, spewing out error messages, although code in the relevant patches prevented any harm from being done).  These interim reboots, when required, are dealt with relatively early in the cluster install sequence so that once completed, the Sys Admin can leave the rest of the installation to finish unattended and move onto other systems.

• The new 'installcluster' script provides better integration with Solaris Live Upgrade as the user can now specify the Live Upgrade alternate boot environment to patch by name.

• The new 'installcluster' script performs space checking prior to installing each patch, and will halt if it believes there is insufficient space to complete the installation successfully.  For example, this helps avoid non-global zones getting out of sync regarding patch levels with respect to the global zone.  This is an important enhancement as running out of space during patching can potentially leave the system in an inconsistent state and is to be avoided.  Even removing a patch requires space, so immediate removal of a patch which has failed to apply correctly due to space issues should be avoided until sufficient space is freed up and potential issues caused by its partial installation investigated - for example, was the undo.Z file successfully created to enable backout ? (Tip: It may be better to retry the patch installation once space has been freed up rather than patch removal in such circumstances.  Contact Sun Support for instructions if you encounter such issues.).   The space checking enhancements in the 'installcluster' script are designed to prevent such problems occurring.
  

• The messages and log files produced by the 'installcluster' script are clear and well structured.  For example, a "failed" log is created if a patch fails to apply.  See the Cluster README for further information.
  

• The 'patch_order' places patches in an optimal order for installation to avoid known issues - for example, the patch utilities patches are installed as early in the sequence as possible to avoid hitting patch installation bugs which are fixed in the patch utility patches, and the Kernel patch procedural script override patch, 125555 (SPARC) / 125556 (x86), is ordered prior to 137137-09 (SPARC) / 137138-09 (x86) to resolve some known issues.  When patching an alternate boot environment (which is recommended), a small sub-set of pre-requisite patches, primarily the patch utility patches, need to be applied to the live boot environment to ensure correct patching operation.  The 'installcluster' script will check for these pre-requisite patches are halt installation if they are not present, advising the user of the 'installcluster' script option to use to install these pre-requisite patches.   Further patches may need to be installed on the live boot environment to support Live Upgrade.  See the cluster README for further information.
  

• The patches have been moved to a 'patches' sub-directory, to de-clutter the top level directory of the unzipped cluster.
  

• Please see the cluster README file for further information.  Customers should read the cluster README file and look at the Special Install Instructions in the patches within the cluster prior to installation.
  

I really want to thank Ed Clark for the enormous amount of thought and effort he has put into improving the cluster installation experience.   The work he's done on the Solaris 10 Recommended and Sun Alert patch cluster is a continuation of his previous work on the Solaris Update Patch Bundles and the Solaris 10 Live Upgrade Zones Starter Patch Bundle.  Nice work, Ed!

While the 'installcluster' script is copyrighted, I am happy for customers to use it, and the 'patch_order' file, as a starting point for their own customized patch bundles, so long as it is for their own use and is not to be given to a 3rd party or used for commercial gain (e.g. by a 3rd party maintainer or 3rd party commercial automation tool).

We have also made significant improvements to the back end processes to ensure higher and more consistent cluster quality. 

Originally, the clusters were created by the Patch Operations and Distribution (POD) team after patch release.  The POD Cluster QA process left a lot to be desired, resulting in inconsistent cluster quality.   To plug this gap, my Patch System Test team have been testing the clusters for several years, but the old process only allowed us to test them in parallel with their release, which meant that we found issues at the same time that early downloaders of the cluster encountered them.  Although we ensured such issues were fixed as quickly as possible, it still obviously compromised our customers' experience.

In the new process, the clusters are routed to Patch System Test (PST) prior to release.  PST run a transformation script on them to optimize the patch installation order, etc.  The clusters will only be released once they have passed PST testing.  This should ensure higher and more consistent quality for customers.  Work is continuing to move the entire patch cluster generation process to PST, although these future backend enhancements in this regard should be invisible to customers.

Sun Learning Services are in the process of creating a number of patch related training lessons.

They've launched a blog, which contains the initial introductory videos.

Future lessons will be much more detailed, concentrating for example on Live Upgrade.   These lessons will be available on the Sun Open Learning Center (SOLC) website: https://learning.sun.com/solc/smartstart.

The Zones Parallel Patching enhancement for the Solaris 10 patch utilities was released this week giving customers a choice of how to improve zones patching performance.

In the Zones "Update On Attach" section of a previous blog posting, I mentioned that the Zones "Update On Attach" feature could also be used to improve Zones patching perfomance.

Zones Parallel Patching is a true patching solution utilizing the 'patchadd' utility.  

Whereas Zones "Update On Attach" uses zones functionality similar to that used during zones creation to provide a pseudo-patching solution that does not utilize 'patchadd'. 

So which one to choose ?

Let's look at the two options in more detail:

Zones Parallel Patching

Zones Parallel Patching is an enhancement to the standard Solaris 10 patch utilities and is delivered in the patch utilities patch, 119254-66 (SPARC) and 119255-66 (x86).

Simply install this patch, set the maximum number of non-global zones to be patched in parallel in the config file /etc/patch/pdo.conf, and away you go.

It works for all Solaris 10 systems. 

It also works well in conjunction with higher level patch automation tools such as xVM Ops Center. 

It can dramatically improve zones patching performance by patching non-global zones in parallel.  The global zone is still patched first.

While the performance gain is dependent on a number of factors, including the number of non-global zones, the number of on-line CPUs, the speed of the system, the I/O configuration of the system, etc., a performance gain of ca. 300% can typically be expected for patching the non-global zones - e.g. On a T2000 with 5 sparse root non-global zones.

See my previous Zones Parallel Patching blog entry for further information.

Since it's a pure enhancement to 'patchadd', it's normal 'patchadd' functionality.  You can subsequently remove patches using 'patchrm', etc.  Nothing has changed except that it's now much faster to patch non global Zones with Zones Parallel Patching invoked.

Zones "Update On Attach"

The primary purpose of Zones "Update on Attach" is Zones migration from one server to another.  

For example, a database instance in a non-global zone hosted on a server has grown to the extent that the Sys Admin wants to transfer it to a better spec'd server which can better handle the workload.   The Sys Admin can detach it from the old server (e.g. a Sun4u) and reattach it to the new server (e.g. a Sun4v) using Zones "Update On Attach".   This will bring the OS Software level on the non-global zone up to the same level as the new server's global zone.

Zones "Update On Attach" can certainly be used for patching but there are limitations you need to be aware of as outlined below.

For example, detach the non-global zones from a system, apply a bunch of patches to the global zone, reattach the non-global zones using "Update On Attach" and viola, the non-global zones will be brought up to the same software level as the global zone (for OS type packages), effectively patching the non-global zones without using 'patchadd' at all.   This is typically even faster than using Zones Parallel Patching.  But there are limitations to this approach which users must be aware of (see below).

My senior engineer, Enda O'Connor, has just published an interesting article on The Zones Update on Attach Feature and Patching in the Solaris 10 OS. 

Zones "Update On Attach" limitations as a patching aid

Zones "Update On Attach" only works for packages which are SUNW_PKG_ALLZONES=true - i.e. typically OS level packages, and not application packages.

So when to use Zones Parallel Patching in 'patchadd' and when to use Zones "Update On Attach" ?

Here's what my senior engineer, Enda O'Connor, says:

"The Zones Update on Attach Feature and Patching in the Solaris 10 OS document may help customers understand how the technology works, applying a cluster via patching and via zones Update On Attach is not quite the same really.

It really depends on the patches being applied, i.e. applying a firefox patch via Update On Attach would not work if you wanted it to apply to the global zone and all non-global zones as well.

One has to understand how Update On Attach works and then apply that to the list of patches to see if it gets them to a desirable state.

There is no black or white answer here.

I'd recommend Zones Parallel Patching using 'patchadd' as it has a known outcome all the time, whereas Update On Attach makes it's own internal determination based on a number of things, that can vary from system to system ( e.g. inherited directories ).

But if time to patch is critical then if the customer does proper testing to validate things, and are happy with the results, then by all means use Update On Attach.

But using Update On Attach without:

1. Understanding how it determines what packages to update

2. Not inspecting the patches being applied.

...will most likely lead to grief at some point."

And my other senior engineer, Ed Clark, says:

"In terms of giving guidance on which technology to use, there are a number of considerations -- two of these considerations are:

1. Using Update On Attach to update sparse zones can require significantly more disk storage space than would be needed by applying patches with 'patchadd' (3-4 times as much space would not be uncommon i think), due to Update On Attach copying fully populated global zone 'undo' files into the non-global zones, as opposed to having patchadd build sparsely populated 'undo' files in the non-global zones.

2. If a customer is really concerned about the ability to back out patches reliably, then 'patchadd' is a lower risk option than Update On Attach -- 'patchrm' of a patch from a non-global zone that has a copy of the global zones 'undo' pkg data (as is the case after Update On Attach) may potentially have unexpected side effects." [although we have yet to see any actual cases of negative results from this.]

Conclusion

In general, we recommend using the Zones Parallel Patching enhancement in the patch utilities rather than the Zones "Update On Attach" feature as Zones Parallel Patching is standard patching functionality, only faster, whereas Zones "Update On Attach" is really designed for migrating zones from one server as another and was not primarily designed to speed up patching.  

Because Zones "Update On Attach" uses Zones functionality similar to the zone creation functionality, rather than 'patchadd' functionality, limitations exist on what will be patched (typically the OS but not applications) and there's the potential for anomalies around things like the "undo" files which would be used by 'patchrm' if patches applied using Zones "Update On Attach" were subsequently removed from the non-global zones using 'patchrm' (although we have yet to see any actual cases of serious issues resulting from this).

So in patching situations where time is absolutely critical, Zones "Update On Attach" may provide a good option, as long as it's well tested in the customer environment prior to deployment on production systems.

Remember too, Live Upgrade is also your friend in such situations, enabling you to patch an inactive boot environment while the system is still in production.   So a combination of Live Upgrade and Zones Parallel Patching would be ideal.

I hope you find this helpful!

Best Wishes,

Gerry.

The Solaris 10 5/09 (Update 7) patch bundle is now available for download from the SunSolve Patch Cluster & Patch Bundle Download Page.  Click on the "Solaris Update Patch Bundles" link.

As with previous patch bundles, it contains the patches which are included in the corresponding Solaris Update, in this case Solaris 10 5/09 (Update 7).

This is useful for Sys Admins who wish to bring all their systems up to the same patch level as the Solaris Update without wanting to upgrade to the release - for example, due to change control policy restrictions in their organizations.

See previous blog entries for previous Solaris Update patch bundles for further information.

My colleague, Enda O'Connor, has published 3 more patching articles on Big Admin which I hope you will find useful:

• Analyzing a patchadd or patchrm Failure in the Solaris OS

  How to gather and analyze the necessary information to determine why a 'patchadd' or 'patchrm' session failed.
  

• How to Split a Root Mirrored With Solaris Volume Manager Prior to Updating Software

  How to split a Solaris Volume Manager mirror prior to updating the software through upgrades or patches.

• How to Remove a Solaris Patch While Booted From a Network or CD-ROM

  How to run 'patchrm' from a network or CD-ROM against a non-live system that is mounted from such media, and how to mount file systems under the mount point after the system is booted from the media.

I think the first article is particularly useful to help customers and support engineers understand what data to gather to enable analysis of a patching issue.  Even if you are not able to analysis the issue yourself, providing this data to Sun Support when you log a call will help speed up the issue analysis by Sun.

My team and I have been working with the SunSolve team on improvements to the Patch Cluster pages on SunSolve.  These improvements went live on April 20, 2009.

The old "Recommended Patch Clusters" and "Recommended and Security Patches" pages have been combined into a single Patch Cluster & Patch Bundle Downloads page.

A Notice Board section at the top of the page will be used to alert customers to current issues.

Click on the cluster headings to see a brief description of the purpose of the cluster, with links to view the cluster README as well as a download link.   The date the cluster was last updated and the size of the cluster are also shown.

No change has been made to the underlying cluster file names, so scripts using 'wget' to access the patch clusters should be unaffected.

This is part of an ongoing effort to improve our patch presentation to customers.

As before, customers need a valid support contract in order to be able to access patch clusters. 

If you are not registered in Member Support Center, simply log into SunSolve and associated one or more support contracts with your Sun Online Account using the "Change Contract" option in the top right hand menu.

If you are registered in Member Support Center, your contracts will be automatically associated with your account (and the "Change Contract" option will not be shown when you log into SunSolve).

A fix to the unzip utility is available in recent patch utility patch revisions.  This fix is required in order to be able to successfully unzip very large files such as the Solaris 10 Recommended and Sun Alert Patch Clusters.

Please download the latest revision of the patch utilities patch first and install it, before attempting to unzip the Solaris 10 Recommended or Sun Alert Patch Clusters.

The fix was incorporated in the putback to CRs 6344676 and 6464056.

The following are the earliest revisions of the patch utilities containing the fix:

• Solaris 10 SPARC: 119254-46 or above
• Solaris 10 x86:        119255-46 or above
• Solaris 9 SPARC:   112951-14 or above
  
• Solaris 9 x86:          114194-11 or above
  
• Solaris 8 SPARC:   108987-19 or above
  
• Solaris 8 x86:          108988-19 or above
  

Without the fix to unzip provided by the above patches, the following error will be seen when attempting to unzip the Solaris 10 Patch Clusters:

# unzip -q 10_Recommended.zip

note:  didn't find end-of-central-dir signature at end of central dir.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly) 

In addition, do not unzip Solaris patch clusters on Windows. Solaris patch clusters, and solaris patches more generally, can contain case-sensitive file names. Consequently clusters and patches must be unzipped on a case-sensitive filesystem (corruption can occur if unzipping on filesystems that are not case-sensitive). 

The above information is now published in Infodoc http://sunsolve.sun.com/search/document.do?assetkey=1-62-252447-1

You can sign up to receive a weekly notification advising of new and updated SunAlerts .

Sun Alerts inform customers of the most critical issues affecting Sun's hardware and software.

They cover Security, Data Corruption, and System Availability issues.

Customers with a valid support contract will be able to access all Sun Alerts and patches which fix Sun Alert issues, including the Sun Alert patch clusters available on SunSolve which contain all Solaris OS patches which address Sun Alert issues.

Customer without a valid support contract will be able to access Sun Alerts and Patches only for Security related issues when they log onto SunSolve.

First of all, let me say that my personnel experience of Sun's patch automation tools is limited.  I work upstream from the SysNet and Services groups who produce most of Sun's patch automation tools, so I and my team mostly patch from first principles using the basic Solaris patch utilities, patchadd and patchrm.

My team does have some experience of working with some of the patch automation tools.  I've supplemented this with information from SysNet and Services folk.

Sun Connection 1.1.1 Satellite (a.k.a. UCE) and xVM Ops Center 1.0

The official Sun patching tool of choice is now xVM Ops Center, which contains an enhanced version of Sun Connection 1.1.1 Satellite Edition.

Sun acquired Aduva a couple of years ago.  Aduva has a track record of providing patch and update automation tools for multiple Operating Systems.

The next-generation Aduva-based tools are coming on stream. Sun Connection 1.1.1 Satellite is based on Aduva.  Note, "Satellite" has a completely different back end to the Sun Update Connection Hosted edition and Solaris Update Manager, which are based on PatchPro (see below).

I'm hearing good things about the Satellite.  I understand that its initial target market is customers with 50+ systems.

Sun Connection 1.1.1 Satellite Edition is based on Aduva Onstage and Update Connection Enterprise.   A central server (Satellite) at the customer site is used to analyze and update all attached client systems in a fully automated manner.  It builds upon a central Knowledge Database fed by Sun.  It covers the provisioning of patches, packages, config files and scripts.  It is available to customers who pay for it.

Sun Connection 1.1.1 Satellite provides a solution for customers primarily interested in patch and package provisioning.  There is a 10 minute demo introducing you to some of the key features of Sun Connection Satellite at http://frsun.downloads.edgesuite.net/sun/07D01031/SunConnectSatellite.html, or alternatively there is a more detailed 32 minute demo at http://frsun.downloads.edgesuite.net/sun/07D01032/SunConnect.html

Sun Connection Satellite is a component of the xVM Ops Center. 

xVM Ops Center is a merge of Sun Connection and N1SM.  Here's a BigAdmin article on Patching Solaris using Sun xVM Ops Center.  The monthly patch baselines referred to are the patch sets in the monthly EIS DVD release (see below).

For further information, please see the Sun Connection hub's Product Tour page on BigAdmin.

EIS

EIS stands for Enterprise Installation Standards and originated from Sun field personnel wanting to develop best practice installation standards for systems installed on customer sites.

EIS has proved extremely popular with Sun field personnel and approved partners.  It's widespread adoption was due to it successfully addressing a real need.  I view it's widespread adoption among field personnel and OEMs as proof positive of its efficacy.

The EIS patch baseline goes through QA testing prior to release.  The images installed by Sun's manufacturers on servers are also based upon the EIS patch baseline.  Additional testing by Sun's manufacturers plus feedback from the EIS user community raises confidence in the EIS patch baseline content further.  Since many system installations world-wide use the EIS methodology, any inherent problems will quickly appear and can be dealt with.  In the event of there being issues with the EIS patch baseline recommendations are communicated to the EIS community.

This same EIS set of patches which are considered by Sun Field Engineers as best practice to install on a new system, can also be used to patch existing systems to the same patch level.  The EIS set of patches is based on the Recommended Patch Cluster for the Solaris OS with additional patches included by the Field Engineers for additional products and to address irritating issues which do not meet the criteria for inclusion in the Recommended Patch Cluster.

The EIS patch baseline covers Solaris and other products such as SunCluster, SunVTS, SSP, SMS, QFS, SAM-FS, and includes patches which provide firmware updates.

EIS has traditionally only been available via Sun Services personnel but is now available direct to customers via Sun Connection Satellite.  This provides a good option to customers to patch to a defined and tested patch baseline.  See the Sun Connection blog for further information.

pca

pca is a popular 3rd party tool developed by Martin Paul.  I've only ever heard positive feedback about pca.

pca is available from http://www.par.univie.ac.at/solaris/pca/

To try out pca, just run this on any Solaris machine:

  $ wget http://www.par.univie.ac.at/solaris/pca/pca
  $ chmod +x pca
  $ ./pca

pca is a good solution for customers interested in a simple, easy to use, patch automation tool.

smpatch, Update Manager, and Sun Connection Hosted Edition

smpatch is a command line tool and part of Solaris.   It allows customers to analyze and update Solaris with current patches.  For customers without a valid support contract,  only security and driver patches are available.  For customers with a valid support contract, all patches are available.

updatemanager is a GUI wrapper around smpatch and is also part of Solaris.  It can be used to see what patches/updates are available and to easily select the patches, which the customer wants to install. Again, for customers without a valid support contract,  only security and driver patches are available.  For customers with a valid support contract,  all patches are available.

Sun Connection - Hosted Edition is the internet portal version of  updatemanager.  The customer can register all their servers and  can schedule and review the installation of patches from a central portal.  This is only available to customers who pay for it.

The above tools rely on the "PatchPro" analysis engine to recommend patches to customers.

PatchPro utilizes what are called "Realizations".  These are listed in the patchinfo file in the top directory of a patch.  This allows the patch developer to associate a patch with one or more "Realization Detectors", which determines whether or not it is appropriate to apply a patch to a particular customer environment.  For example, a Realization Detector might only recommend a particular patch if the target system utilizes a particular piece of hardware or software, or if a particular service is enabled.  This provides fine-grained control on patch recommendations.

The vast majority of Realizations simply associate a patch to packages installed on the target system, in the same way patchadd determines whether or not to apply a patch.  That is, if the package name, package version, and platform architecture in the pkginfo file(s) in the patch match at least one package name, package version, and platform architecture on the target system, the patch can be applied, else not.

Errors in writing Realization Detectors cause patch automation tools which utilize the PatchPro analysis engine to occasionally recommend inappropriate patches.  This has impacted the reliability of PatchPro based tools.

Work is underway to write a generic realization detector to match patches to packages.  This will save patch creators from writing their own realization detectors for the common case, simplifying the process and reducing error opportunity.  Patch creators will still be able to write specific Realization Detectors where necessary.

See Instructions for Getting Started with Sun Connection's Update Manager and Sun Hosted solutions and Patch Manager 2.0 FAQs for further information.

TLP

TLP stands for Traffic Light Patching, and is another tool which was developed by Sun Service folk for Sun Service folk to address the need for Patch Automation.

TLP is not directly available to customers.  It's used by Sun Service personnel to determine the appropriate patches to be installed on a customer's system, including things like firmware patches.

TLP has a modular design.   It utilizes the concept of a "baseline" of patches chosen by the user, from the Recommended Patch Set, to the EIS patch set, to a user defined set of patches.  TLP allows a number of different patch analysis engines to be used to determine which patches from the "baseline" to apply to a particular target system.

TLP is popular with customers who use it, as it's reliable and works well. 

TLP was End-Of-Lifed (EOL'd) in September of 2006 and reached End-Of-Service-Life (EOSL) in December 2007.  However, a number of customers have been given extensions on TLP support for transition purposes. 

Sun Services Patch Recommendations 

Most European countries provide a service where customers can submit Explorer logs and the local Sun office provides back a patch bundle.  These services may use SRAS and TLP in the background.

Please contact your local Sun Services office for further details.

I believe the plan will be to consolidate these services into a consistent official worldwide service.