Thursday Jan 13, 2011

List of new and up'rev'd packages in each Solaris 10 Update

Here are lists in .pdf (SPARC / x86) and OpenOffice (SPARC / x86) format of new and up'rev'd packages in each Solaris 10 Update release.

As you may know from my previous blog postings, Oracle Sun recommends customers to install or upgrade to the latest Solaris 10 Update in major maintenance windows. Based on a request from customers whose change control policies prevent them from upgrading, we've been producing Solaris Update Patch Bundles which bring pre-existing packages up to the same software level as the corresponding Solaris Update.  The difference is that the Patch Bundles don't provide new or up'rev'd packages introduced in the corresponding Solaris Update.

For customers considering use of the Solaris Update Patch Bundles, that raises the obvious question as to which packages are introduced or up'rev'd in each Solaris Update release.  The lists above answer that question.

Aside: As discussed in previous blog postings, all core Solaris OS packages are updated via patches.  The up'rev'd packages above refer to some 3rd party and community based apps included in Solaris (e.g. Mozilla Firefox, Thunderbird, etc.) which are updated via package updates (i.e. where one package version is removed and replaced with a later version).  This is to tie in better with the release strategy for such apps.

Many thanks to my colleague, Roisin Doran, for all her work in putting this together.

I'll ask Roisin to work with the Technical Writers to include updated versions of these lists in future Solaris 10 Update release documentation.

Tuesday Nov 24, 2009

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

Monday Nov 16, 2009

Which patch patches which Object ? Which package ? Security and other stuff

Here's some interesting tricks-of-the-trade and security related resources which I saw in a couple of email threads last week, which you may find useful:

What patches patch a specific object ?

We'll soon be enhancing the PatchFinder tool further to enable you to search for patches which patch a specified object.  So, if you're experiencing a problem with an object, you'll be able to see what patches exist for that object and look at the Bug fix synopses to see if any look like the issue you are experiencing.

But what patches on an installed system patch a specific object ?

The question which sparked the thread was: "What's the easiest way to determine what patch a binary (e.g. mpt(7D) driver) is tied to on a system?"

Option 1:  What patches installed on the system patch a specific object (e.g. /kernel/drv/mpt) ?

# cd /var/sadm/patch

# for x in `ls -rt` ; do grep "\^/kernel/drv/mpt \*$" $x/README.$x > /dev/null && echo $x; done

118855-36

127128-11

137138-09

139556-08

141445-09

Option 2: What patches installed on the system patch a specific object (e.g. /kernel/drv/sparcv9/mpt) ?  (This output is from a different system at a different patch level to the previous example.)

# /usr/ccs/bin/mcs  -p /kernel/drv/sparcv9/mpt
/kernel/drv/sparcv9/mpt:

@(#)SunOS 5.10 Generic 143128-01 Nov 2009

Option 3: What patches installed on the system patch a specific object (e.g. /usr/bin/ls) ?  (See Sun Blueprint on the SunSolve fingerprint DB: http://www.sun.com/blueprints/0306/816-1148.pdf )

# digest -a md5 /usr/bin/ls
6f20408d15ddfce2261436a27e33c0bd
#
and from http://sunsolve.sun.com/fileFingerprints.do
{
Results of Last Search

6f20408d15ddfce2261436a27e33c0bd - - 1 match(es)

        \* canonical-path: /usr/bin/ls
        \* package: SUNWcsu
        \* version: 11.10.0,REV=2005.01.21.15.53
        \* architecture: sparc
        \* source: Solaris 10/SPARC
        \* patch: 138377-01
}

Security Resources

Here are some excellent resources from Sun Distinguished Engineer, Glenn Brunette:

Everything you ever wanted to know about Solaris security...
http://mediacast.sun.com/users/gbrunette/media/s10-security-dive-20091021.pdf/details

The Solaris Package Companion is a small Korn shell script that allows you to ask quite a number of interesting questions about the relationships between Solaris metaclusters, clusters and packages as well as their respective dependencies.  Useful for system hardening, etc.: http://hub.opensolaris.org/bin/view/Project+svr4_packaging/package_companion

A Sun Blueprint on the SunSolve fingerprint DB: http://www.sun.com/blueprints/0306/816-1148.pdf

Enjoy!

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