Do not apply packages from one Update onto a system installed with a different Update

I'd just like to make the following clear to customers:

Customers who install packages from one Update release (e.g. S10U6) on a system installed with another release (e.g. S10U3) risk corrupting their system.

You must not install packages from one Update release onto a system installed with any other Update release.

The reason for this is that all available patches are pre-applied into all packages for each Update release.   Patches and packages have a many-to-many relationship.  That is, one patch can patch many packages.   One package can be patched by many patches.

If you install a package from an Update release onto a system installed with a different Update release, you completely compromise future patch dependency checking as you've introduced patch metadata from a later Update release.   This is likely to lead to system corruption as further patches are applied.

'patchadd' checks that dependencies are satisfied when installing a patch.  If 'patchadd' finds any installed package patched with a patch which satisfies the dependency, it assumes the patch is applied to all packages.  This is done for performance reasons.  Hence, if a package from a later release is installed on the system, it's pre-applied patches may fool subsequent 'patchadd' invocations into thinking that a hard code dependency has been satisfied for all packages on the system when this is not the case.   The patch application will be allowed to continue, potentially corrupting the system.

The converse is also true.   If a package from an earlier Update is applied to a system, the patch delta from that Update to the Update installed on the system plus any additional patches installed on the system would need to be applied to the package to avoid a mismatch in software levels between the packages on this system, which could lead to incorrect patch dependency resolution and hence to system corruption.  Since this is difficult to get right, adding packages from a different Update release onto an installed system is, in general, unsupported. 

There are two exceptions to the above rules, for Live Upgrade and encryption packages.

  • Live Upgrade: If you are upgrading from Solaris 8 or Solaris 9 to Solaris 10, you need to apply the Live Upgrade packages from the Solaris 10 system to your Solaris 8 or Solaris 9 system.  See document 1004881.1 on My Oracle Support (MOS), http://support.oracle.com, for details.
  • SUNWcry\* encryption packages: These weren't included in the Solaris distribution prior to Solaris 10 8/07 (Update 4).  For pre-Update4 systems, the recommended way to get these packages is to upgrade to a later Update release.  For the reasons outlined above, while not recommended, a possible alternative is to download the packages from the Sun Download Center (SDLC), install them, and then re-apply any patches that patch the SUNWcry\* packages which you have already applied to the system (\*\*). Also, for the reasons outlined above, it is not recommended to apply the packages from the media of a later Update release, as you would need to ensure that all the other packages installed on the system are patched to the same or higher patch level  (e.g. by installing the appropriate Solaris Update Patch Bundle available from My Oracle Support, http://support.oracle.com) to avoid completely compromising future patch dependency checking on the system.

\*\* A way to check which patches need to be re-applied in this scenario is as follows:

cd /var/sadm/patch
egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u

as in:

# cd /var/sadm/patch
# egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u
127127-11
137137-09
139555-08
141444-09
#

The above example is on a system installed with Soalris 10 11/06 (Update 3).  The user would need to re-apply the patches listed above and be extremely careful to ensure they are applied in the correct dependency order as 'patchadd' will not be able to ensure the correct dependency order as it's dependency checking remains compromised until the added packages are brought up to the same patch level.

Please note that if a package from the same Update is applied to a system, then any additional patches already installed on the system that patch the added package must be re-applied to bring that package up to the same software level as the rest of the system.  This is called "incremental patching".   This is supported, but care must be taken.  The easiest way to do this is to reapply all patches installed on the system (as listed by 'patchadd -p').  This will bring the added package(s) up to the same software level as the rest of the system.  Again, you need to be extremely careful to ensure they are applied in the correct dependency order as 'patchadd' will not be able to ensure the correct dependency order as it's dependency checking remains compromised until the added packages are brought up to the same patch level as the rest of the system.

Best Wishes,

Gerry Haskins,
Director, Software Patch Services

Comments:

Hi Gerry:

If it's unsupported, it ought not be allowed by the system :-)

Posted by Pete Hartman on November 24, 2009 at 08:14 AM GMT #

Hi Pete!

Not an unreasonable point. Image Packaging System (IPS), which will replace the current SVR4 packaging architecture in future Solaris releases, will be a lot more rigorous in this type of area.

But we don't intend to "fix" this in the SVR4 architecture.

IPS is the strategic solution to a lot of the patch/packaging issues we have with SVR4.

Best Wishes,

Gerry.

Posted by Gerry Haskins on November 24, 2009 at 08:48 AM GMT #

Gerry, what about SUNWcry\* in S10U4? Sun changed the context of these crypto plugins from not-for-export add-ons in U3, to a normal part of ON in U4.

I discovered (the hard way) that I needed to install these U4 packages onto my U3 systems, in order to apply security patches without breaking SunSSH.

Don't get me wrong, I'm glad that these ciphers are now a part of Solaris; but doesn't this sort of thing reduce the coherency within an update?

Yes I could have hacked on my sshd_config as a workaround, but the doesn't diminish the consequences of starting to depend upon SUNWcry\*.

References:

http://hub.opensolaris.org/bin/view/Project+crypto/sunwcry
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6850734
http://forums.sun.com/thread.jspa?messageID=10780120#10780120
http://blogs.sun.com/bubbva/entry/ssh_with_aes256ctr_support_not

Thanks... -cheers, CSB

Posted by Craig S. Bell on November 24, 2009 at 10:55 AM GMT #

I should add that one could download and install the standalone external crypto kit on U3, as well. That avoids mixing updates, instead it mixes ON plus add-ons.

So it would be more accurate to frame this issue as one of suddenly relying upon something other than a patch, in order to be able to continue patching safely.

In this case, the needful bits are packages that weren't part of update 3, even if you used SUNWCXall. Patching worked as expected, until I came across 141742.

Thanks again. -c

Posted by Craig S. Bell on November 24, 2009 at 02:47 PM GMT #

I think I am misunderstanding something here. I have a machine which I built with 10/08 and I have installed the 05/09 patch cluster on this server and is this now not supported? I am confused about that statement.

V

Posted by veltror on November 27, 2009 at 06:03 AM GMT #

Hi "Veltror"!

This entry talks about adding \*packages\* from one Update onto a system installed with a different Update.

There's absolutely no problem installing \*patches\* from one Update onto a system installed with a different Update.

So, yes, you are fully supported.

Best Wishes,

Gerry.

BTW: Craig: I'm still looking into your crypt issue. (LU pkgs are another special case exception when upgrading from S8 or s9 to S10).

Posted by Gerry Haskins on November 27, 2009 at 06:37 AM GMT #

Hi Craig!

I've updated the posting with reference to the SUNWcry\* and Live Upgrade package cases.

Best Wishes,

Gerry.

Posted by Gerry Haskins on November 27, 2009 at 08:22 AM GMT #

Hi Craig!

A further update on the SUNWcry\* packages from my contact in Encryption:

"Actually, what an S10 FCS -> S10 U3 customer is supposed
to do is install the FCS versions of SUNWcry and SUNWcryr
onto their system [from https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewFilteredProducts-SingleVariationTypeFilter], then patch up. (\*NOT\* the S10U4 versions of the packages).

Also, if I have followed that issue with SSH correctly, it doesn't
break SSH - but if you don't have the stronger ciphers installed,
it can't use them - and will complain. (I believe the bug is that
SSH now assumes they are always there)."

Best Wishes,

Gerry.

Posted by Gerry Haskins on December 01, 2009 at 04:30 AM GMT #

Gerry, thanks , i must have been in a wormhole or something when i confused packages and patches, I suppose they sound the same

Thanks again

V

Posted by Veltror on December 01, 2009 at 12:40 PM GMT #

Thank you Gerry. Actually the problem I ran across was a bit more involved -- I was unable to connect remotely from SSH clients that try to use the strong ciphers.

SunSSH daemon didn't change ciphers when the packages are missing, but are defined in sshd_config. Fortunately it wasn't too hard to debug and fix.

Again, a simple workaround is to edit sshd_config, or install the crypto packages as you suggested. But if you don't do that first, then you might get shut out.

Fortunately this is a somewhat rare sort of problem for us, and it's correctable -- a newer patch could add dependencies on those packages, or fix the conf file.

Anyways, it's the only example I could find where patching an otherwise-coherent Solaris 10 system wasn't enough maintenance to stay proper. Thx... -c

Posted by Craig S. Bell on December 05, 2009 at 04:09 PM GMT #

Hi Craig -

I wrote a blog on this, you can read here:
http://blogs.sun.com/bubbva/entry/ssh_with_aes256ctr_support_not

and there is a bug filed against S10 to make this so people like you do not hit this problem in the future.
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6850734

There is an IDR available, if you have a support contract. It will additionally be in a patch soon.

Valerie

Posted by Valerie Fenwick on December 08, 2009 at 12:49 PM GMT #

Hi Craig!

The fix for CR 6850734 will be contained in patches 143140-02 for S10 SPARC and 141525-07 for S10 x86. They are currently undergoing testing and should release shortly before or after the Christmas break.

Best Wishes,

Gerry.

Posted by Gerry Haskins on December 09, 2009 at 08:45 AM GMT #

Thanks Valerie -- as it turns out, I referenced your post in my original reply above. That's what helped set me straight. =-)

Thanks Gerry, I'll be sure to test that revision when it emerges. =-)

Posted by Craig S. Bell on December 15, 2009 at 01:47 PM GMT #

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