Re: [pca] Wrong patches downloaded

[Don O'Malley]

Hi Ron, Martin Paul wrote: Ron, Sorry for the delay .. As you can see, they are for Solaris 2.6 and 7. not Solaris 8. How did this happen? Mike already explained how this can happen; it's wrong or incomplete information in the patchdiag.xref file which causes this. It's actually wrong (by Sun) to use the same package on all versions of Solaris, but later produce different patches, one for each Solaris release. If the package is the same, the same patch could be used as well. You've touched on a pretty messy example of something which appears wrong initially, but as you peel back the layers you can see why it has happened... :) Some history: Sun release "unbundled" products; "unbundled" is simply a historic term used to indicate that the particular patch/product is NOT a part of the core Solaris Operating System. So, as you have probably guessed by now "unbundled" products are typically applications which run on top of Solaris. It is quite common, primarily due to Sun's binary compatibility between Solaris Releases (i.e. a binary which runs on Solaris 8, will also run on Solaris 9 & 10), to release unbundled products that run on more than one Solaris Release (i.e. on Solaris 8, 9 & 10). Sun's middleware product set are a good example of such products. Look at the Messaging Server 6.3 patch 120228-32 (http://sunsolve.sun.com/search/document.do?assetkey=1-21-120228-32-1) for example and you will see that the patch applies to both Solaris 9 & Solaris 10. This approach does have the advantage that customers with these products can use a single set of patches to support the products regardless of the underlying OS on which they run. To re-iterate what Martin has said above - if an unbundled product is not designed to run on more than one Solaris Release, then Sun will typically release a set of pkgs (and patch(es)) per Solaris Release. The pkgs which apply to a particular Solaris Release will usually use different pkg VERSION strings to those which apply to other releases. (Note: In your example this process has not been strictly followed, as we will see...) Using differing VERSION strings per Solaris Release prevents patches being applied to the wrong pkgs accidentally as, in order for a patch to apply via patchadd the PKG, ARCH and VERSION strings of at least one of the patch's packages must match that on the target system. So, to come around to your example - you reported seeing: 110936 -- < 22 -S- 999 Sun Management Center 3.0: (GA) Patch for Solaris 2.6 110937 -- < 22 -S- 999 Sun Management Center 3.0: (GA) Patch for Solaris 7 110971 -- < 22 -S- 999 Sun Management Center 3.0: (RR) Patch for Solaris 2.6 110972 -- < 22 -S- 999 Sun Management Center 3.0: (RR) Patch for Solaris 7 Looking at the patches 110936, 110937 & 110938 in the patchdiag.xref file, they all ship some common packages for Solaris 2.6, 7 & 8 in patches. I've highlighted a couple of examples below: 110936|22|Apr/07/05| |S| | |Unbundled|sparc;|SUNWed:1.1,REV=41.2000.12.14,OE=S2.6;...;SUNWedcom:1.1,REV=41.2000.12.14,OE=S2.6;...;SUNWesasc:3.0_Build41,REV=2.6.2000.12.19;SUNWescaa:3.0_Build41,REV=2.6.2000.12.19;SUNWescam:3.0_Build41,REV=2.6.2000.12.19;SUNWescix:3.0_Build41,REV=2.6.2000.12.19;SUNWescli:3.0_Build41,REV=2.6.2000.12.19;SUNWesclt:3.0_Build41,REV=2.6.2000.12.19;...|Sun Management Center 3.0: (GA) Patch for Solaris 2.6 110937|22|Apr/07/05| |S| | |Unbundled|sparc;|SUNWed:1.1,REV=41.2000.12.14,OE=S2.6;...;SUNWedcom:1.1,REV=41.2000.12.14,OE=S2.6;...;SUNWesasc:3.0_Build41,REV=2.6.2000.12.19;SUNWescaa:3.0_Build41,REV=2.6.2000.12.19;SUNWescam:3.0_Build41,REV=2.6.2000.12.19;SUNWescix:3.0_Build41,REV=2.6.2000.12.19;SUNWescli:3.0_Build41,REV=2.6.2000.12.19;SUNWesclt:3.0_Build41,REV=2.6.2000.12.19;...|Sun Management Center 3.0: (GA) Patch for Solaris 7 110938|22|Apr/07/05| |S| | |Unbundled|sparc;|SUNWed:1.1,REV=41.2000.12.14,OE=S2.6;...;SUNWedcom:1.1,REV=41.2000.12.14,OE=S2.6;...;SUNWesasc:3.0_Build41,REV=2.6.2000.12.19;SUNWescaa:3.0_Build41,REV=2.6.2000.12.19;SUNWescam:3.0_Build41,REV=2.6.2000.12.19;SUNWescix:3.0_Build41,REV=2.6.2000.12.19;SUNWescli:3.0_Build41,REV=2.6.2000.12.19;SUNWesclt:3.0_Build41,REV=2.6.2000.12.19;...|Sun Management Center 3.0: (GA) Patch for Solaris 8 and Solaris 9 So, if you were to have the Sun Management Center 3.0 for Solaris 8 installed on your system (which I assume you do), then you will also have some of the common pkgs from the Sun Management Center 3.0 for Solaris 2.6 & 7 installed on your system too. This in turn means that when pca analyzes your Solaris 8 system with the Sun Management Center 3.0 installed, that it will also recommend the patches for the Sun Management Center 3.0 on Solaris 2.6 & 7, due to matching PKG, VERSION, ARCH on some pkgs. Patches such as these will typically contain code in the patch's prepatch script in order to prevent the patches being applied on top of the wrong OS. Looking at patch 110936-22 we can see that this is the case: # cat 110936-22/prepatch #!/bin/sh . .. ... OS_V=`uname -r` if [ 5.6 != $OS_V ] ; then echo "This patch is for SunOS 2.6. Please install the correct patch" exit 1 fi . .. ... There is similar logic included in the prepatch scripts for 110937 & 110938, so even though pca might recommend these patches for installation patchadd will actually fail to apply them as the prepatch script will detect the correct Solaris Release and exit. HTH, -Don Anyway - in such a case I add a workaround for the affected patches to pca so that these patches are handled correctly. I've done that for those you showed (and at the same time I've checked and corrected all "Sun Management Center" patches). Please get the "develop" version of pca from http://www.par.univie.ac.at/solaris/pca/installation.html and let me know if it works correctly now. In order to use my pca wrapper scripts in production, I must prove to > management that pca is "perfect". I believe I can convince my boss that this is so, but I would like to know the cause. Look for perfection in any piece of software which is more complicated than "Hello, world!" will be an interesting task :) The explanation for pca's behaviour is simple. When looking for patches which (might) apply to a system pca always chooses a safe approach of better listing a patch that doesn't apply (false positive) than not listing a patch which might apply (false negative). False positives are easy to handle - when trying to install them, patchadd will fail. You can then report the problem to me, I'll add a workaround to pca and the issue is fixed not only for you but for *all* users of pca. A false negative is a thing which IMHO must not happen with any patch tool. It means that a patch which is needed for a system is not shown to you, so you never find out that a problem hasn't been fixed if you trust the tool. This was one the main issues why I didn't rely in Sun's tools anymore and wrote my own. I've done multiple comparisons of pca vs. smpatch in the past, and always found false negatives in smpatch. I heard that it got better recently, but when trust is gone, it's gone and hard to regain. So what you *can* tell to your boss is not that it's perfect, but that it's safe and if a problem shows up, it gets fixed immediately. Hope that helps, Martin.