A: An SVR4 package would consist of:

• Required components:
  • Package objects: These consist of files (executables or data), directories, named pipes, links, and devices.
  • pkginfo file: This is a required package information file defining parameter values like package abbreviation, full package name, package architecture, and so on.
  • prototype file: A required package information file that lists the component of the package with location, attributes, and file type for each component within a package.
• Optional package components:
  • compver file: Defines previous versions of the package that are compatible with this version.
  • depend file: Indicates other packages that this package depends upon.
  • space file: Defines disk space requirements for the target environment.
  • copyright file: Defines the text for a copyright message displayed at the time of package installation.
• Optional installation scripts: These scripts perform customized actions during the installation of the package. Different installation scripts include:
  • request scripts: Request input from the administrator installing the package.
  • checkinstall scripts: Perform special file system verification.
  • Procedure scripts: Define actions that occur at particular points during package installation and removal. There are four procedure scripts that you can create with these predefined names: preinstall, postinstall, preremove, and postremove.
  • Class action scripts: Define a set of actions to be performed on a group of objects.

A: A patch contains one or more sparse packages, delivering binaries that accommodate new bug fixes and/or new features.

Patches usually do not contain all the binaries that had been shipped with the package. Patches may contain scripts to provide fine-grained installation control or to update/correct configuration files. Examples of patch procedural scripts are prepatch and postpatch. Examples of patch class action scripts are i.<class>, u.<class>, and so on.

A: SUNW_REQUIRES identifies patch dependencies. The functionality delivered in a patch might have a code dependency on the changes or functionality delivered in other patches. That is, one patch requires one or more other patches to function correctly. If a patch depends on one or more patches, the patch specifies the required patches in the SUNW_REQUIRES field in the pkginfo file of the patch's packages.

A: A package database consists of:

• /var/sadm/pkg: This is a directory containing one directory entry for every package installed on the system.
• /var/sadm/pkg/<packagename>/pkginfo
• /var/sadm/pkg/<packagename>/save/<patchid>/undo.Z for the backout packages.
• /var/sadm/pkg/<packagename>/save/pspool/<packagename>: A sparse package that is used for non-global zone install.
• /var/sadm/install/contents: This file has an entry for every file in the system that has been installed through a package. Entries are added or removed automatically using the binaries installf and removef.

A: Here's the way patching works in servers using the Solaris 10 OS running non-global zones: For every patchadd command, patching would first occur for the global zone followed by patching in the non-global zone. This time increases linearly with the number of non-global zones running in the system. Also, the time consumed to patch a whole root zone is more compared to a sparse root zone.

You commented that a server with 10 zones can take 6 (or more) hours to patch while patching 10 individual servers in parallel may only take 2 hours.

This is because you're patching 10 individual servers in parallel, however patching the Solaris 10 OS running non-global zones would happen sequentially. What that means is that if you had 'A', 'B' as the patches to patch a system running two non-global zones, then the following sequence would apply. I am assuming here that A needs to be applied before B, meaning patch 'A' is a dependency for patch 'B'.

Note: All the steps below would run sequentially.

patch A in global zone
patch A in non-global zone #1
patch A in non-global zone #2

patch B in global zone
patch B in non-global zone #1
patch B in non-global zone #2

smm - November 26, 2007

A: You can use Sun Connection to ease patch administration.

Brad Isbell - November 26, 2007

A: I believe you're asking about patch clusters (i.e., recommended patch clusters). If so, yes, Sun recommends the use of Recommended Patch Clusters and Sun Alert Packs. The recommended Patch Clusters reflect the current version of all the patches required to address the Sun Alert issues. Some customers have adopted a policy of periodically applying the current Recommended Patch cluster to a system. While this strategy does address all Sun Alert issues, it also introduces more changes to the system than is necessary. Note that reapplying the current Recommended Patch Cluster on a scheduled basis is not necessary.

Brad Isbell - November 26, 2007

A: Patches for kernel binaries and low-level libraries like libc et al need to be patched in single-user mode. This and several other restrictions are provided in the README file of that patch. Sun always recommends that you install a patch in single-user mode whenever it is noted in the README file, as well as following the rest of the instructions, like reconfigure, reboot et al.

The reason that Sun recommends "single user" is that when we go into single-user mode, we kill all the user processes. Of course, some daemons and system processes are still running, but we greatly reduce the likelihood of the running processes loading the new bits for the binaries that have been patched.

Matthew Robinson - November 26, 2007

A: The SUNW_OBSOLETES field identifies patch accumulation and obsolescence. Sometimes bug fixes or new features cause two or more existing patches to become closely intertwined. For example, a bidirectional, hard-code dependency might exist between two patches. In such cases, it might be necessary to accumulate the functionality of two or more patches into one patch, thereby rendering the other patch or patches obsolete. The patch into which the other patch's functionality is accumulated specifies the patch ID or IDs of the patch or patches that it has obsoleted. This information is in the SUNW_OBSOLETES field in the pkginfo files delivered in the patch's sparse packages. This declaration is called explicit obsolescence.

The patch accumulation can only work one way. That is, if Patch A accumulates Patch B, Patch A now contains all of Patch B's functionality. Patch B is now obsolete. No further revisions of Patch B will be generated.

Due to the accumulation of patches, a later revision of a patch "implicitly" obsoletes earlier revisions of the same patch. Patches that are implicitly obsoleted are not flagged in the SUNW_OBSOLETES field. For example, Patch A-Revision xx does not need to explicitly obsolete Patch A-Revision x-1 with a SUNW_OBSOLETES entry in the pkginfo file.

Note: For the Solaris 10 OS (releases after August 2007), a patch might be released that contains no new changes. This patch might state that it obsoletes another patch that was released some months earlier. This is a consequence of the Solaris Update patch creation process. If you have the obsoleted patch installed, and the new patch does not list any new changes, you do not need to install this new patch.

For example, the Solaris 10 timezones patch 122032-05 was obsoleted by patch 125378-02. If you already have 122032-05 installed, there is no need to install 125378-02, because patch 125378-02 does not deliver any new changes.

For more information, see the BigAdmin article Overview of Solaris Patch Types and Dependencies.

Jerome Daudin - November 26, 2007