Patch Management Best Practices

Please see the Patch Management Best Practices guide which my colleague, Enda O'Connor, has published on the BigAdmin Patching Hub.  I hope you'll find it useful.

Enda is a senior engineer in Patch System Test and he is far more technical than I am.

Enda has more practical experience of patching Solaris 10 Zones environments than anyone else in Sun.

Enjoy!

Comments:

Quoth the article:
"Note: It is strongly advised that you read the Special Install Instructions for all patches prior to installing them."

Hmmm.

Nearly 400 patches are required to get an early Solaris 10 release fully patched. It's probably a worst case, but there are 80 notes attached to the 118833-36 kernel patch; notes which reference over 110 other patches.

I used to be part of the smpatch support team (flame on, people!) and one of the most-heard complaints was that it didn't install 'interactive' patches automatically. Explaining that the reason for this was usually because there was an important note in the patch description was invariably met with something along the lines of "We don't care about the install instructions, we just want the patches installed."

In summary, nobody reads the patch install instructions. Well, they might when something breaks badly, but that's about it.

Posted by Dave on April 29, 2008 at 03:34 PM IST #

Special Install Instructions are not added just for the hell of it.

Often, they describe workarounds to issues found during patch testing. Some of these issues may be critical in specific customer environments.

Unfortunately, at the moment, too much is dumped into this section of the README.

Many of the entries simply describe "soft" dependencies. These are where other patch(es) are required to deliver particularly functionality, either a bug fix or feature, but the system is still in a consistent state if the other patch(es) are not applied. These entries typically have the form: "To get the full fix for CR xxxxxxx, please apply the following patches:". Such entries inform customers of optional patches which they may wish to install. In "smpatch" (PatchPro) terminology, these are the human readable equivalent of the "PATCH_PREFERS" entry in a patch's patchinfo file.

However, as I've described in previous postings, patching a live Solaris 10 boot environment, particularly a Zones environment, has been problematic, up to and including Kernel patch 118833-36 (SPARC) and 118855-36 (x86). Therefore, it is imperative that customers carefully review the Special Install Instructions in such patches to avoid ending up with a warm brick, particularly when patching the live boot environment of a Zones system.

Strategies covered in this blog, such as using Live Upgrade, go a long way to help prevent such scenarios.

Enhancements made, such as the SplitGate process and Deferred Activation Patching, have significantly improved the situation and reduced the need for critical Special Install Instructions in patches created since spring 2007.

And customers running Solaris 10 8/07 (Update 4) or Solaris 10 5/08 (Update 5) or who are on earlier Solaris 10 releases but have already successfully installed Kernel patch 118833-36 (SPARC) or 118855-36 (x86) should experience a lot less difficultly and should encounter much fewer critical Special Install Instructions.

Going forward, we do want to split out "soft" dependencies into a separate section in the patch README, so that there will be a lot less Special Install Instructions, and the ones that remain should be the critical ones which customers need to watch out for.

Posted by Gerry Haskins on May 13, 2008 at 04:19 AM IST #

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