Scott McNealy hates the word patch. It has negative connotations, like a cloth patch used to repair worn out clothing. Scott prefers the term update as it's more positive, suggesting the provision of positive change, not just repairs.
I wholeheartedly agree with him as patches deliver positive change (feature enhancements, performance enhancements, hardware support, etc.) as well as bug fixes. Also, many bug fixes delivered in patches address issues found during internal Sun testing rather than issues found by customers, and hence patches often provide proactive preventative change rather than just reactionary change.
Unfortunately, "update" is an overloaded term, as the periodic releases of the current Solaris[TM] OS are often referred to as Solaris Update Releases, such as Solaris 10 Update 4 (offical name, Solaris 10 8/07). Solaris Update Releases are complete Solaris install images and are therefore quite different from patches which provide discreet change to be installed on top of an existing Solaris install image.
To avoid confusion, I'll use the politically incorrect term patch in this blog.
Most of the information which follows is available on the new BigAdmin Patching Hub. The information on the BigAdmin Patching Hub will be added to over time, so it should provide a useful resource to anyone involved in patching Sun software.
This blog concentrates on "standard" patches for the Solaris platform.
Aside: The term Solaris patch is frequently used in documentation. This is ambiguous, as it can mean either a patch specifically for the Solaris OS product itself, or it can mean any patch, including an application patch, which can be applied to a system running the Solaris OS. Typically, such application patches behave the same as patches for Solaris itself and so most documentation on "Solaris patches" also applies to application patches for products such as Java Enterprise System, SunCluster, SunStudio, etc., for installation on the Solaris platform.
So, what is a "standard" patch for the Solaris platform ?
Almost all Sun software, and some 3rd party software, for the Solaris platform are delivered as Sun SVR4 packages. For example, SUNWcsr and SUNWcsu.
A "standard" patch for the Solaris platform is a patch which provides updates to existing Sun SVR4 packages. For further information on packages, see the Application Packaging Developer's Guide on docs.sun.com. Note, the section on Patching Packages is out of date, as patches can and do deliver new features and functionality.
"Standard" patches for the Solaris platform have the following attributes:
The key attributes of a package from a patching perspective are the
package name, package version, and architecture (SPARC or x86). These attributes are specified in each package's pkginfo file.
When patching, the Solaris patchadd utility checks whether the name, version, and architecture of the package(s) in a patch match the name, version, and architecture of the package(s) on the target system. If they match, then the matching packages will be updated. Each object in that package which is delivered in the patch will be updated.
If a patch patches several packages and only some of them are present on the target system, only the packages which are present will be patched. If, at a later date, the other packages are added to the target system, the patch will need to be reapplied in order to patch the new packages. This is called incremental patching.
How an object is updated depends on its file type and associated Class Action Script, as specified in the pkgmap file in each package. Type "f" (executable file) objects will typically simply be replaced and will typically have a Class Action Script of i.none associated with it.
If the default "save" option is used when patching, the
replaced objects will be archived (typically in
enables the patch to be backed out at a later date and the original
files restored. Such archiving is cumulative, allowing the previous patched state to be restored.
Special handling may be required for other file types, such as type "e" (editable files), for example, in cases where configuration files need to be updated. Patching configuration files which contain a mixture of "system" data (i.e. data which should only be changed by Sun) and "user" data (i.e. data which can be safely altered by customers) can be problematic from a patching perspective. For example, it may be risky to try to pattern match a "system" entry in the configuration file which should be modified or deleted as there may be a danger of accidentally pattern matching a "user" entry added by the customer. In the worst case, the patch may simply either replace the configuration file, save off the old version, and ask the customer to manually merge the two versions, or else leave the configuration file alone, add the ".new" version alongside it, and ask the customer to manually merge the two versions. This is clearly a less than ideal experience but is largely a property of poor configuration file design (often inherited from legacy or 3rd party code).
For more information on installing patches, see the How To page on the BigAdmin Patching Hub.
Sun patches typically have a 6-2 digit PatchID, such as
127111-05. The first 6 digits are the base PatchID. 127111 is a Solaris 10 Kernel patch for SPARC. The last 2 digits
are the revision number of the patch, starting at revision -01. As
further changes are incorporated in the patch, the revision number is
incremented. This PatchID format is used for almost all Sun patches,
including patches for Linux, IBM mainframes, HP-UX, Windows, etc., as
well as for patches for the Solaris platform.
for the Solaris platform start life as a "T-Patch" or Test Patch. They are prefixed with the
letter "T", such as T127111-07. T-Patches may be given to customers to
verify that they fix an issue. T-Patches are also verified by the
engineers who coded the changes and tested by the Patch System Test
team. See the Overview of Solaris[tm] Patch System Testing and Performance QA Testing for further details.
If appropriate, the contents of a T-Patch may be ported by an
OEM such as Fujitsu and the ported code is merged into the T-Patch. (This merging adds ported objects for OEM supported platforms such as Fujitsu servers, it does not change any objects for Sun supported platforms.)
Once a patch has been fully verified and tested, the "T" prefix is
removed and the patch is released to SunSolve. Note: The "T-Patch" is
functionally identical to the patch which is eventually released. No
material changes are allowed to a T-Patch, other than the addition of OEM ported code, if any. If a serious issue is found with a T-Patch, it will
simply not be released. This is why customers may notice gaps in the
revision numbers of released patches. For example, 127111-04 was not
released due to an issue, CR 6627976, found during testing by Sun's Patch System Test team.
Even before a T-Patch is created, customers who are experiencing a problem may be provided with an IDR (Interim Diagnostic and Relief). The IDR uses a patch-like structure, but it does not attempt to provide a final fix to an issue. Rather, IDRs are used to help diagnose complex issues and provide customers with prototype solutions to test. Once a fix has been identified, the process of creating a real patch will begin. IDRs should be replaced with the real patch as soon as it becomes available as a T-Patch.
For an overview on the Life Cycle of a bug, IDR, and Patch, see A Bug's Lifecycle.
For further information on IDRs, see the Interim Relief/Diagnostics page.
Now that I've covered the basics, my next posting will concentrate on the specific issues around patching Solaris 10, and the process and tool improvements which have been made to address them.