Improvements to Solaris 10 Recommended and Sun Alert Patch Clusters released

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.

Comments:

[Trackback] At Sunsolve you will find two large files with assorted patches. One of them is the recommended Patchcluster which contains all patches Sun recommends for operation at a certain point of time and the SunAlert Cluster, which contains patches to fix SunA...

Posted by c0t0d0s0.org on August 14, 2009 at 09:47 AM IST #

These sound like good improvements.
As of several years ago, when patching all of my systems (sol 8, 9, 10), I have skipped trying to install patches that are already installed. I do this my removing patches from the patch_order that show up in a 'showrev -p'. I understand that zones make these checks more complicated. (Yes, I run this script on each server individually.)
Could this also be added to the install_cluster script for all versions of Solaris?

Posted by Warren on August 14, 2009 at 02:03 PM IST #

It would also be nice if the team that posts the patch clusters could make sure the online md5 checksums are updated at the same time. There is often (and I mean OFTEN) a mismatch between the posted checksums and the patch clusters.

Posted by slac on August 14, 2009 at 05:01 PM IST #

Hi "slac"!

Thanks for the heads-up. I'll take this up with the relevant team.

Best Wishes,

Gerry.

Posted by Gerry Haskins on August 17, 2009 at 05:01 AM IST #

Hi Warren!

'pdo', which is the C-code front end to 'patchadd.ksh' on Solaris 10 is efficient at processing patches which have already been applied to a system, so there is really no need to manually filter out patches from the 'patch_order' file, even in a Zones environment. So effectively, 'pdo' is already performing the enhancement you are suggesting.

You can time the installations using the unmodified 'patch_order' file and your modified 'patch_order' file to check.

On Solaris 8 and 9, 'patchadd.ksh' will also correctly deal with patches which have been already applied, although perhaps not as efficiently as 'pdo' on Solaris 10.

Best Wishes,

Gerry.

Posted by Gerry Haskins on August 17, 2009 at 05:13 AM IST #

Hi Warren,

further to Gerry's comments

the new cluster install script attempts application of every patch in the cluster specifically to handle situations where 'incremental patching' is required (suppose a system has been patched to a certain level, and \*unpatched\* packages from install media are then installed to the system - these newly installed packages will need to be patched up to the same patch level as other packages on the system, this known as 'incremental patching'). Simply filtering patch_order against patches identified as installed by 'patchadd -p' would lead to those patches which need to be incrementally applied being bypassed. Instead, filtering of a more complex form is required, where packages in a patch are compared against packages on the system, with the identification of any unpatched packages being the cue for a patch needing to be incrementally applied. The Solaris is 10 patchadd front end (pdo) is reasonably efficient at determining when a patch needs to be incrementally applied, and the new cluster install script is making use of this in the course of attempting to apply every patch in the cluster (using pdo to determine if a patch needs to be incrementally applied is probably more efficient than if a piece of logic which accomplished the same were added to the new cluster install script).

Best,
Ed

Posted by Ed Clark on August 17, 2009 at 05:53 AM IST #

I'm in Sun OS support and these questions are on behalf of a customer:

7 QUESTIONS

Please answer the following questions with answers, documentation, and
relevant discussion:

1 - What was the rationale for changing the patch cluster structure?

2 - How do we use the new structure if we do not use alternate environments?

3 - Is it just: boot to single user as before and issue:

# installcluster --s10cluster

4 - Can we feed the new installcluster script the passcode via a file
(as input)?

5 - Is there anything we can do to use the old structure? i.e. A CLI
switch to “installcluster”?

6 - Will Sun also issue the patches using the old script,
install_cluster and the old structure for those who do not use alternate
environments and for those who patch regularly – as we do?

7 - Are there any plans to modify this structure further?

Please send the relevant documentation regarding the new files:
patchcluster.conf, installcluster, etc.

BACKGROUND INFO

My concern over the major changes to the Solaris 10 Sun Recommended
Patch Cluster are multi-fold. The old structure has been in place for (4
or more) years and has served us very well. We have developed an
automated method of jumpstarting, customizing, AND patching a system in
one shot. Since we do not use alternate-boot environments and do not use
alternate root environments, I feel the patch structure should not have
changed because for us:

1. We must patch monthly. Therefore, any changes to the patch cluster
structure are significant.

2. My jumpstart scripts are sophisticated and contain patching
information – including directory structure for patch clusters. Sun has
just significantly changed it. Any changes to the patch clusters force
me to modify my jumpstart procedures and several complex scripts. – I am
wondering how many more times this may change.

3. Our primary LDOMs are setup going forward as jumpstart servers – and
so any change will therefore multiply itself.

4. We are currently building out new environments for the fall/winter
2009. We will end up with 170 or so Solaris installations which we will
have to patch monthly. This process needs to be as automated and as
simple as possible. The introduction of pass codes concerns me and may
slow us down.

This is an example of the structure as it was:

root vsx004:/data1/Patches/NEWER # ls –F 10_Recommended
118666-22/ 120061-02/ 121975-01/ 125731-04/ 138322-03/ 140455-01/
119764-06/ 121118-16/ 125279-05/ 137080-03/ 139969-02/ CLUSTER_README
119783-12/ 121133-02/ 125332-06/ 137093-01/ 139982-02/ copyright
119810-05/ 121136-02/ 125503-02/ 137137-09/ 139986-01/ install_cluster\*
119812-06/ 121181-04/ 125539-06/ 137321-01/ 140074-08/ patch_order
119900-08/ 121211-02/ 125541-04/ 137871-02/ 140171-03/

This is an example of the new structure:

root vsx004:/data1/Patches/NEW # ls -F 10_Recommended
Copyright README patch_order patches/
LEGAL_LICENSE.TXT installcluster patchcluster.conf

Posted by Brian P. Henchey, OS Group on August 19, 2009 at 02:40 PM IST #

It is a real shame your Patch System Test and new and improved QA processes didn't pick up on the following jumpstart profile use case failing!

patch patch_order nfs://myserver/export/patches/10_Recommended

Which now fails silently when I try and jumpstart my systems and patch them because the patch_order file is no longer in the same directory as the patches themselves.

Great idea restructuring the patch bundle guys!

/var/sadm/install_data/install_log finishes with:

Installing patches now
Installing patch(es) from x.x.x.x of location type "nfs"
Validating patches...

Loading patches installed on the system...

Done!

Loading patches requested to install.

Done!

No patches to dependency check.

Is this a known issue? I'll be opening a support call for this shortly.

Posted by Matthew Flanagan on August 24, 2009 at 04:30 AM IST #

Apologies Matthew!

Yes, this looks like a bug. The patches were put into a sub-directory to tidy up the top level directory, but I believe jumpstart is using 'patchadd -M' under the hood which expects to see the patch_order file in the same directory as the patches.

We'll work on a fix. In the meantime, copy the patch_order file to the patches sub-directory which should workaround the issue.

I apologize for the issue.

Best Wishes,

Gerry.

Posted by Gerry Haskins on August 24, 2009 at 05:14 AM IST #

Just want to join to complaints about the jumpstart installations. I am using JET for instance. Even when I change the patch dir location in the configuration of the JET, it just doesn't patch the client. So I presume I have to manually go to the profile of each client and specify the patch NFS location manually obviously after I copy the patch_order to 10_Recommended/patches directory.
Is it possible you focus on the fixing these issues? Thanks a lot guys.

Posted by Andy on August 26, 2009 at 03:06 AM IST #

Hi Matthew, Brian,

the new format clusters can be installed from a jumpstart finish script, ie.

<cluster-path>/installcluster -R /a --s10cluster

this approach has an advantage over the jumpstart profile 'patch' directive, in that the installcluster script generates and logs more concise information about the patching session (the pass/fail status of the patching session can be deduced easily from log files, and even programatically in the finish script from exit status of installcluster if so desired)

an alternative workaround would be to unzip the new format cluster and nudge it back into the legacy format (three or four commands are all that are required), this would avoid the need to update paths in jumpstart profiles

we will look into a formal fix shortly

best,
Ed

Posted by Ed Clark on August 26, 2009 at 06:59 AM IST #

Hi Brian,

see comments from Gerry and myself inline

1 - What was the rationale for changing the patch cluster structure?

GH> See the blog entry. It explains the enhancements and why they were done.

EC> the new structure was converged on through the course of field testing the previous three Solaris 10 Maintenance Update Bundles -- it made sense to adopt this same structure for the overhaul of the Solaris 10 patch clusters

2 - How do we use the new structure if we do not use alternate environments?

GH> This is fully explained in the cluster README.

3 - Is it just: boot to single user as before and issue:

# installcluster --s10cluster

GH> This is fully explained in the cluster README.

4 - Can we feed the new installcluster script the passcode via a file
(as input)?

EC> no, the passcode must be provided as a command line option. The passcode will only be changed when the README is updated with important new information regarding the cluster, and this won't be a frequent occurrence (note that the x86 clusters have utilised a similar passcode mechanism for years now)

5 - Is there anything we can do to use the old structure? i.e. A CLI
switch to “installcluster”?

EC> no, however a user way wish to write their own wrapper around installcluster to effect this. Alternatively, there is nothing to stop a user from transforming a cluster back into legacy format if they so desire, however we wouldn't support or recommend doing this.

6 - Will Sun also issue the patches using the old script,
install_cluster and the old structure for those who do not use alternate
environments and for those who patch regularly – as we do?

GH> No. Patching the Live boot environment is still supported as can be seen by reading the cluster README.

7 - Are there any plans to modify this structure further?

EC> we are relatively happy with the new cluster format so don't plan on making unnecessary changes to this format or the install script interface ; see other planned changes in Gerry's comment below

GH> No concrete plans to change the structure as such but we are planning to:
GH> 1. Chunk or split the clusters into 2 or more sections to make them easier to download
GH> 2. Merge the Recommended and Sun Alert patch clusters as their contents are very similar. See earlier blog postings.

Please send the relevant documentation regarding the new files:
patchcluster.conf, installcluster, etc.

EC> patchcluster.conf is documented in the file itself, usage information for installcluster can be found in the README

BACKGROUND INFO

My concern over the major changes to the Solaris 10 Sun Recommended
Patch Cluster are multi-fold. The old structure has been in place for (4
or more) years and has served us very well. We have developed an
automated method of jumpstarting, customizing, AND patching a system in
one shot. Since we do not use alternate-boot environments and do not use
alternate root environments, I feel the patch structure should not have
changed because for us:

1. We must patch monthly. Therefore, any changes to the patch cluster
structure are significant.

2. My jumpstart scripts are sophisticated and contain patching
information – including directory structure for patch clusters. Sun has
just significantly changed it. Any changes to the patch clusters force
me to modify my jumpstart procedures and several complex scripts. – I am
wondering how many more times this may change.

EC> as above, we won't be making unnecessary changes to the cluster structure ; the new format patch clusters can easily be installed from a jumpstart finish script

3. Our primary LDOMs are setup going forward as jumpstart servers – and
so any change will therefore multiply itself.

4. We are currently building out new environments for the fall/winter
2009. We will end up with 170 or so Solaris installations which we will
have to patch monthly. This process needs to be as automated and as
simple as possible. The introduction of pass codes concerns me and may
slow us down.

EC> the legacy format clusters had shortcomings which significantly detracted from the ability to safely and reliability automated their installation -- the new format clusters will provide a much improved and more reliable patching experience in this regard

best,
Ed

Posted by Edward Clark on August 26, 2009 at 01:26 PM IST #

Hi "slac"!

I've been looking into the checksum issue you raised. The problem arises due to the synchronization between backend systems. When the systems sync up, the Checksum file is updated pretty instantaneously, but it takes considerably longer to transfer the large patch Clusters, resulting in a time gap between the Checksums being updated and the Clusters being updated. I'm looking into ways to resolve this with the various teams involved.

Best Wishes,

Gerry.

Posted by Gerry Haskins on August 27, 2009 at 04:24 AM IST #

Ed, on behalf of my customer, thanks for your previous responses.

The customer has a some more questions:
=====
After using the new patch clusters for a short time I find they are better than the old ones.

In addition, my jumpstart script can now distinguish between the two cluster types and can use either.

One more question (in several parts), please.

If they are planning on splitting the clusters into 2 parts:
1. What will be the degree of difficulty for re-combining the 2 parts?
a. Any degree of difficulty will magnify for 170 servers being patched once a month because we’ll have to
Copy 2 zip files to each server, unzip each, and then carefully combine the sub-directories, etc.
It would be better and much more efficient for us to have ONE zip file for each server unless –
There is a proven, efficient script that can do it for us.

2. Will we be given a choice as to if we want to download the 2 parts or the one large whole?
a. I would appreciate being given a choice – like the choice given for OpenSolaris (b. 121), ex.:

Solaris Express Community Edition – DVD | DVD (Single Image)

Thanks,
=====

Posted by Brian Henchey on September 02, 2009 at 03:19 PM IST #

Hi Brian!

I'm really interested in getting customer feedback on whether to split the current patch clusters and, if so, how to split them.

We could split them into a pre Solaris 10 Update 4 (or 5) and post Solaris 10 Update 4 (or 5) clusters, so that customers on U4 (or U5) or later don't have to bother with the earlier part of the split cluster. To clarify what I mean here, all available Solaris patches are pre-applied to each Solaris Update when it is being built. Therefore U4 (or U5) already has a lot of the patches which are contained in the clusters pre-applied in its release image. So downloading these patches each time you want to get the latest cluster contents is a waste of time, bandwidth, and storage. The downside is that if you have any very old systems which have not been patched to the U4 (or U5) patch level, then the later part of the split cluster may not be able to resolve it's dependencies until the earlier part of the split cluster is downloaded and applied. This is potentially confusing.

Alternatively, we could "chunk" the Solaris 10 clusters, similar to what we do for the Solaris 10 Update Patch Bundles on http://sunsolve.sun.com/show.do?target=patches/patch-access. That way, customers still have access to all patches in a single cluster when the "chunks" are concatenated, and that single cluster can be applied to all Solaris 10 systems, irrespective which Update release it is. The advantage of "chunking" compared to the current single large download file is that is helps make downloads more reliable, especially for customers with lower bandwidth and less reliable internet connections.

I've kicked off a discussion thread on this topic on the new Patch Forum (see http://blogs.sun.com/patch/entry/patch_forums_now_available_for). The thread is http://forums.sun.com/thread.jspa?threadID=5403524&tstart=0

I do think that we'll implement one solution and one solution only, based on customer feedback.

Best Wishes,

Gerry.

Posted by Gerry Haskins on September 03, 2009 at 06:00 AM IST #

Indeed, copying patch_order file to the patches sub-directory "patches" and changing patching line in jumpstart profile to

patch patch_order nfs://myserver/export/patches/10_Recommended/patches retry 5

works for me. So I think it is a good idea to deliver patch_order file also in sub-directory "patches".

Posted by MartinB on September 23, 2009 at 01:09 AM IST #

Hi Martin,

after some discussion, it was decided for the patches directory to include a symlink to the patch_order file

s10 patch clusters released from next week will include this change

best,
Ed

Posted by Ed on September 25, 2009 at 09:34 AM IST #

Hi,

After being bitten by it twice in recent months I'd recommend NOT using 'patch patch_order ...' in your jumpstart profile as it tends to fail silently. I've gone back to running installcluster in a finish script.

regards

Matthew

Posted by Matthew Flanagan on September 27, 2009 at 06:02 PM IST #

Hi Matthew,

we agree with your statement, to avoid silent failures and get the benefits and improved logging and better control of the patching session, we too recommend installing the patch cluster from a jumpstart finish script in preference to use of the jumpstart profile 'patch' directive

however we elected to make the patch_order file visible from the patch cluster patches directory as a convenience for those who may have particular reasons for using the jumpstart profile 'patch' directive

best,
Ed

Posted by Ed on September 29, 2009 at 05:36 AM IST #

Hi Ed,

you wrote: "after some discussion, it was decided for the patches directory to include a symlink to the patch_order file"

Did you test this solution successfully with using patch directive in jumpstart profile? In my opinion delivering a symlink as

patch_order -> ../patch_order

still fails for jumpstart because patches-subdirectory is nfs mounted and ".." therefor not seen. As I stated, a copy (or a hard link) will do the job.

greetings
Martin

Posted by MartinB on October 02, 2009 at 08:33 AM IST #

Hi,

I want to get past recommended cluster binay include solaris 10 KJP/141414-08.
Does anyone know the location where old recommended patch cluster binaries are
stored ?

Best regards,
kenji

Posted by Kenji on October 05, 2009 at 07:07 AM IST #

Hi Martin,

you are correct, the symlinking of patch_order doesn't resolve the problem for installing a patch cluster on nfs

the testing that was done unfortunately involved installing a cluster from a local device, and in this context the symlinking of patch_order does work (in retrospect, having a cluster available on a local device is admittedly not the most practical use case)

going forward, the problem will need to be addressed by having a copy of the patch_order file in the patches directory

just to reiterate an earlier statement : we strongly recommend installing the cluster from the jumpstart finish script, and discourage use of the jumpstart profile 'patch' directive

thanks,
Ed

Posted by Ed on October 05, 2009 at 08:59 AM IST #

Hi Kenji!

Older versions of the Recommended Cluster are not available. Only the latest version is available.

Can you please clarify the specific reason you are looking for an older version of the Recommended Cluster as I don't understand your comments above ? Are you trying to avoid 141414-08 ? If so, why ?

Best Wishes,

Gerry.

Posted by Gerry Haskins on October 05, 2009 at 12:47 PM IST #

Hi Gerry,

Thank you for your comment.
The reason why my customer request me the old patch cluster that include -08 was the SunAlert#268728.
268728 is affected by -09 and -10.

kenji

Posted by Kenji on October 07, 2009 at 07:23 PM IST #

Hi Kenji!

The fix for SunAlert#268728 will be in Kernel patch 141444-09 (SPARC) / 141445-09 (x86) which is due to release 19th October.

The customer can file a customer Escalation against the relevant CR, CR6872520, which will entitlement the customer to early access to the patch which is available today to Escalating Customers as a T-Patch.

The T-Patch designation signifies that the patch is still undergoing testing, but as long as no serious issues are found in the remainder of the testing, it will be the identical patch which will be released on October 19th.

IDRs are also available, but I'd recommend the 14144[45]-09 T-Patch over the IDRs as the T-patch will be the final fix, unless late breaking issues are discovered.

Alternatively, you can edit the Recommended Cluster contents yourself to replace 141414-19 (SPARC) / 141415-10 (x86) with the older rev-08 version, which is still available to download from SunSolve.

Best Wishes,

Gerry.

Posted by Gerry Haskins on October 08, 2009 at 03:25 AM IST #

Dear Gerry,

I like to suggest a very simple improvement to Solaris 10 Recommended Patch Cluster: remove all obsoleted patches, which are included as of today (I ran a simple script to figure them out):

obsoleted patch: 118731-01 ,date: Jun/02/05, synopsis: Obsoleted by: 120011-14 SunOS 5.10: /usr/sbin/zonecfg patch
obsoleted patch: 122658-03 ,date: Oct/17/06, synopsis: Obsoleted by: 122660-07 SunOS 5.10: zonecfg patch
obsoleted patch: 122660-10 ,date: Jul/31/07, synopsis: Obsoleted by: 120011-14 SunOS 5.10: zones patch
obsoleted patch: 122662-02 ,date: Jul/24/06, synopsis: Obsoleted by: 122660-07 SunOS 5.10: libzonecfg patch
obsoleted patch: 124204-04 ,date: Feb/21/07, synopsis: Obsoleted by: 120473-05 SunOS 5.10: zfs patch
obsoleted patch: 142286-01 ,date: Sep/09/09, synopsis: Obsoleted by: 142529-01 SunOS 5.10: w and whodo patch

Best greetings
Martin

Posted by MartinB on November 03, 2009 at 11:38 PM GMT #

Hi Martin!

I'm checking with Ed, but I think these are here for a reason. If you are applying the cluster to the live boot environment of a very old system, some interim (obsolete) patches are required to get you from A to B without getting into a circulate patch dependency problem.

Best Wishes,

Gerry.

Posted by Gerry Haskins on November 04, 2009 at 12:30 AM GMT #

hi Martin,

122660-10, 124204-04, and 118731-01 are required patches, see cluster README
122658-03 and 122662-02 have never been included in a new format cluster
142286-01 was last included in the 2009.10.22 cluster, it is replaced by 142529-01 in subsequent clusters

best,
Ed

Posted by Ed on November 04, 2009 at 04:42 AM GMT #

Hello,

I was directed to this blog by Sun Tech Support. I have a question related to the new Solaris 10 Recommended Clusters. Prior to the change to the cluster (new install script, new directory structure, new config file) I was removing the individual patch directories and updating the patch order file according, to effectively remove patches from the cluster, that had already been applied to our Solaris 10 systems. These reduced clusters have been applied to our servers that have been patched up to the previous Reccommended cluster we had applied. Of course any additional server setup, or with one with additional packages installed since the last cycle of patching would have the current complete (unmodified) recommended cluster applied.

I need to know if, after the structure change, there are any additional risks, compared to the previous Solaris 10 Recommended Cluster structure, if I were to remove individual patch directories (from their new location) and update both of the "patch order" files that exist now. (I don't really know if this would cause issues related to the new "config" file).

I understand this is NOT a SUN recommended action to take, but the 10 Rec cluster is becoming so large it causes us problems, I need to continue to remove patches we have already applied. We are working toward getting xVMOC in place to manage our Solaris patching, but it will not be in place for a few more of our patch cycles.

I'm not looking for official "blessing" to do this. I just need to know if it is more dangerous to do than before the format change.

Thanks,

Darrell

Posted by Darrell Morgan on November 10, 2009 at 12:35 PM GMT #

hi Darrell,

in general there is no danger resulting from removal of patches from the cluster (by deleting the patch directory and modification of patch_order), however the installcluster script will emit an error message and abort if a removed patch is one of those listed in the prereq_order parameter of the patchcluster.conf file. Note also the installcluster script is reliant in particular on the presence of patchutils patches 119254/119255 in the cluster, so these patches must not be removed under any circumstances.

the bundle can be installed from an nfs share if local space on a system is an issue, it that not an option in your configuration ?

best,
Ed

Posted by Edward Clark on November 11, 2009 at 03:45 PM GMT #

Ed,

Thanks so much for the reply. This is exactly the scope of information I was looking for. Hopefully I will not need to do this much longer. In the near future we hope to be using Ops Center 2.5 to manage our Solaris 9 & 10 patching. We are actually scheduled for the OC 2.5 install next Monday. It will take some work on our systems to get them meeting the Ops Center agent requirements.

So, your response is GREATLY appreciated and that information will serve us well in the interim period until we get Ops Center implemented in our environment.

Thanks,

Darrell

Posted by Darrell Morgan on November 12, 2009 at 05:43 AM GMT #

Hi,

I am pretty new to patching, can anyone tell me how to get a recommanded patch cluster 142901-09 from sun?

thanks,

Walter

Posted by Walter on September 28, 2010 at 01:34 AM IST #

Hi Walter,

142901-09 isn't a patch cluster (i.e. a collection of patches), it's simply a single patch.

Login to SunSolve, http://sunsolve.sun.com, ensure a valid support contract is associated with your Sun Online Account (see the "Update Account" link near the top of the right hand menu), go to http://sunsolve.sun.com/patchfinder/ and enter the PatchID 142901-09, hit return and viola, it'll return the patch which you can now download (assuming you have a valid support contract).

You can also download the patch from My Oracle Support (MOS), http://support.oracle.com. Follow the links on SunSolve to get started.

Best Wishes,

Gerry.

Posted by Gerry Haskins on October 12, 2010 at 09:35 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