Chapter 21 Managing Solaris Patches by Using the patchadd Command (Tasks)

Patch management involves applying Solaris patches and software updates to a system. Patch management might also involve removing unwanted or faulty patches. Removing patches is also called backing out patches.

This chapter provides step-by-step instructions on how to manage Solaris patches by using the patchadd command. For additional information, see the patchadd(1M) man page.

The following overview information is in this chapter:

• Types of Patches

• Accessing Solaris Patches

• Managing Patches in the Solaris Operating System

• Solaris Patch Management Terms and Definitions

• Managing Solaris Patches by Using the patchadd Command (Task Map)

For information about applying patches to diskless client systems, see Patching Diskless Client OS Services.

For information about recommended strategies and practices for using Solaris patches, see Solaris Patch Management: Recommended Strategies.

Types of Patches

A patch is an accumulation of fixes for a known or potential problem within the Solaris OS or other supported software. A patch can also provide a new feature or an enhancement to a particular software release. A patch consists of files and directories that replace or update existing files and directories. Most Solaris patches are delivered as a set of sparse packages. For details about packages, see Chapter 18, Managing Software (Overview).

A software update is a change that you apply to software that corrects an existing problem or that introduces a feature. To update is also the process of applying software updates to a system.

You can manage patches on your Solaris system by using the patchadd command.

Signed and Unsigned Patches

A signed patch is one that has a digital signature applied to it. A patch that has its digital signature verified has not been modified since the signature was applied. The digital signature of a signed patch is verified after the patch is downloaded to your system.

Patches for the Solaris OS, starting with the Solaris 2.6 release, are available as signed patches and as unsigned patches. Unsigned patches do not have a digital signature.

Signed patches are stored in Java archive format (JAR) files and are available from the SunSolve Online^SM web site. Unsigned patches are stored in directory format and are also available from the SunSolve Online web site as .zip files.

For information about applying patches to your system by using the patchadd command, see Managing Solaris Patches by Using the patchadd Command (Task Map).

For additional overview information about signed patches, see Signed Packages, Patches, and Software Updates.

Accessing Solaris Patches

Sun customers can access patches from the SunSolve Patch Portal web site. Although, some patches might only be accessible to customers with a service plan, such as a SunSpectrum^SM or a Solaris Service Plan customer. In all cases, you must be registered with Sun and have a Sun online ID to enter the SunSolve Patch Portal. These patches are updated nightly.

You can obtain Solaris patches from the http://sunsolve.sun.com web site. To access patches from the SunSolve Patch Portal web site, your system must be connected to the Internet and be capable of running a web browser, such as the Firefox browser.

You can access individual patches or a set of patches from a patch cluster, or refer to patch reports.

Each patch is associated with a README file that has information about the patch.

Solaris Patch Numbering

Patches are identified by unique patch IDs. A patch ID is an alphanumeric string that is a patch base code and a number that represents the patch revision number joined with a hyphen. For example, patch 118833-10 is the patch ID for the SunOS 5.10 kernel update patch, 10th revision.

Managing Solaris Patches

This section describes how to manage Solaris patches with the Solaris patch tools that are available.

The patch tools do the following:

• Determine the Solaris version number of the managing host and the target host

• Update the patch package's pkginfo file with this information:

  • Patches that have been obsoleted by the patch being applied

  • Other patches that are required by this patch

  • Patches that are incompatible with this patch

While you apply patches, the patchadd command logs information in the /var/sadm/patch/patch-id/log file.

In this Solaris release, improvements have been made to the patchadd -M command. When you use this command to apply patches to your system, you are no longer required to specify patch IDs in numeric order. If you use the patchadd -M command without specifying a patch ID, all patches in the directory are installed on the system. For more information about these changes, see the patchadd(1M) man page.

The patchadd command cannot apply a patch or software update under the following conditions:

• The package is not fully installed on the system.

• The patch package's architecture differs from the system's architecture.

• The patch package's version does not match the installed package's version.

• A patch with the same base code and a higher revision number has already been applied.

• A patch that obsoletes this patch has already been applied.

• The patch is incompatible with a patch that has already been applied to the system. Each patch that has been applied keeps this information in its pkginfo file.

• The patch being applied depends on another patch that has not yet been applied.

Managing Patches in the Solaris Operating System

Use the following information to identify tasks for managing Solaris patches. Each task points to additional tasks, such as managing signed or unsigned patches.

Determining Whether to Apply Signed or Unsigned Patches to Your System

The key factor when determining whether to apply signed or unsigned patches to your system is whether you trust the source of patches.

If you trust the source of patches, for example, a patch CD from a known distributor or an HTTPS connection to a trusted web site, you can use unsigned patches. However, if you do not trust the source, use signed patches.

If you are unsure about whether to trust the source of patches, use signed patches.

Solaris Patch Management Terms and Definitions

The following terms are used throughout the patch management chapters.

apply

To install a patch on a system.

back out

To remove a patch from a system.

backout data

Data that is created when a patch is applied to enable the system to return to its previous state if the patch is removed (backed out).

backout directory

Directory in which backout data is stored. By default, this is the save directory of each package that was installed by the patch.

dependency

See patch dependency.

digital signature

An electronic signature that can be used to ensure that a document has not been modified since the signature was applied.

download

To copy one or more patches from a source of patches, such as the Sun patch server, to the system where the patches are to be applied.

download directory

Directory in which patches are stored when they are downloaded from the patch source. This is also the directory from which patches are applied. The default location is /var/sadm/spool.

keystore

A repository of certificates and keys that is queried when you attempt to apply a signed patch.

nonstandard patch

Nonstandard patches cannot be installed using the patchadd command. Nonstandard patches, those that are typically used to deliver firmware or software application fixes that are not delivered in package format, must be installed by using the instructions that are specified in the patch README file.

order

To sort a set of patches in an order suitable for applying patches.

package

The form in which software products are delivered for installation on a system. The package contains a collection of files and directories in a defined format.

patch

An update to software that corrects an existing problem or that introduces a feature.

patch analysis

A method of checking a system to determine which patches are appropriate for the system.

patch dependency

An instance where a patch depends on the existence of another patch on a system. A patch that depends on one or more patches can only be applied to a system when those other patches have already been applied.

patch ID

A unique alphanumeric string, with the patch base code first, a hyphen, and a number that represents the patch revision number.

patch incompatibility

A rare situation where two patches cannot be on the same system. Each patch in the relationship is incompatible with the other. If you want to apply a patch that is incompatible with a patch already on the system, you must first remove the patch that is already on the system. Then, you can apply the new patch.

patch list

A file that contains a list of patches, one patch ID per line. Such a list can be used to perform patch operations. The list can be generated based on the analysis of a system or on user input.

Each line in a patch list has two columns. The first column is the patch ID, and the second column is a synopsis of that patch.

patch obsolescence

An instance where a patch replaces another patch, even if it has not already been applied to a system. A patch that obsoletes one or more patches replaces those patches entirely and does not require that the obsolete patches be applied before the replacement patch is applied.

patch server

A source of Solaris patches that can be used by your systems to perform patch analyses and from which to obtain the appropriate patches.

signed patch

A patch that is signed with a valid digital signature. A signed patch offers greater security than an unsigned patch. The digital signature of the patch can be verified before the patch is applied to your system. A valid digital signature ensures that the signed patch has not been modified since the signature was applied. Signed patches are stored in Java Archive (JAR) format files.

software update

A change to software that you apply that corrects an existing problem or that introduces a feature.

special handling

Patches with properties that indicate they must be installed in single-user mode. Also, patches that require you to restart the system after the patch has been applied are referred to as having special handling requirements.

standard patch

Standard patches are those that adhere to the Solaris patch specification and are installable by using the patchadd command. Note that nonstandard patches cannot be installed by using the patchadd command

Sun Alert

A notification to customers of a known product issue that might negatively impact customers' computing environments or productivity. A problem that warrants a Sun Alert notification meets the criteria for issues that are related to at least one of these concerns: availability, security, and data loss.

SunSolve Online

The Sun Microsystems patch portal web site that provides access to patch, patch information, and patch clusters. See http://sunsolve.sun.com for more information.

unsigned patch

A patch that is not signed with a digital signature.

web proxy

A system that is used to connect your system to the Internet. Your system cannot connect directly to the Internet, but must use the web proxy to establish the connection.

Managing Solaris Patches by Using the patchadd Command (Task Map)

How to Import a Trusted Certificate to Your Package Keystore

To apply signed patches to your system by using the patchadd command, you must add Sun's Root CA certificate, at the very least, to verify the signature of your signed patch. You can import this certificate from the Java keystore to the package keystore.

1. Become superuser or assume an equivalent role.

2. If you are using the patchadd command to install signed patches, add the new trusted Verisign certificate to the keystore.

   1. Download the Class 2 Public Primary Certification Authority - G2 trusted Verisign certificate from http://www.sun.com/pki/certs/ca/.

      The Subject Name of this certificate is:

      C=US, O=VeriSign, Inc., OU=Class 2 Public Primary Certification
      Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only,
      OU=VeriSign Trust Network

   2. Select the binary format (DER encoded).

   3. Copy the certificate to the file, /tmp/root.crt.

   ---

   Note –

   In the event you are unable to download the trusted Verisign certificate, see Exporting the Root CA Certificate From the Java Keystore for alternate instructions.

   ---

3. Import the Root CA certificate from the temporary file to the package keystore.

   Unless changed by the system administrator, the default Java keystore password is changeit.

   For example:

   # pkgadm addcert -t -f der /tmp/root.crt Keystore Alias: /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O Common Name: /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O Certificate Type: Trusted Certificate Issuer Common Name: /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O Validity Dates: <May 18 00:00:00 1998 GMT> - <Aug 1 23:59:59 2028 GMT> MD5 Fingerprint: 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1 SHA1 Fingerprint: B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D Are you sure you want to trust this certificate? yes Trusting certificate </C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O> Type a Keystore protection Password. changeit Press ENTER for no protection password (not recommended): For Verification: Type a Keystore protection Password. Press ENTER for no protection password (not recommended): Certificate(s) from </tmp/root.crt> are now trusted

   -t

   Indicates that the certificate is a trusted CA certificate. The command output includes the certificate details, which you are asked to verify.

   -f format

   Specifies the format of the certificate or private key. When importing a certificate, it must be encoded using either the PEM (pem) or binary DER (der) format.

   certfile

   Specifies the file that contains the certificate.

4. Display the certificate information.

   # pkgadm listcert Enter Keystore Password: storepass Keystore Alias: /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O Common Name: /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O Certificate Type: Trusted Certificate Issuer Common Name: /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O Validity Dates: <May 18 00:00:00 1998 GMT> - <Aug 1 23:59:59 2028 GMT> MD5 Fingerprint: 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1 SHA1 Fingerprint: B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D

5. Remove the temporary file.

   # rm /tmp/root.crt

Exporting the Root CA Certificate From the Java Keystore

If you are unable to download the trusted Verisign certificate from http://www.sun.com/pki/certs/ca/, as described in Step 2 of How to Import a Trusted Certificate to Your Package Keystore, you can export the Root CA certificate from the Java keystore to a temporary file.

For example:

# keytool -export -storepass changeit -alias verisignclass2g2ca \
-keystore /usr/java/jre/lib/security/cacerts -file /tmp/root.crt
Certificate stored in file </tmp/root.crt>

-export

Exports the trusted certificate.

-storepass storepass

Specifies the password that protects the integrity of the Java keystore.

-alias verisignclass2g2ca

Identifies the alias of the trusted certificate.

-keystore certfile

Specifies the name and location of the keystore file.

-file filename

Identifies the file in which to hold the exported certificate.

You are now ready to import the Root CA certificate from the temporary file to the package keystore. See the remaining steps in the section, How to Import a Trusted Certificate to Your Package Keystore, for instructions.

How to Specify a Web Proxy

If your system is behind a firewall with a web proxy, you must specify the web proxy to use patchadd to apply a patch.

1. Become superuser or assume an equivalent role.

2. Use one of the following methods to specify a web proxy:

   • Specify the web proxy by using the http_proxy, HTTPPROXY, or HTTPPROXYPORT environment variable.

     For example:

     # setenv http_proxy http://mycache.domain:8080

     Or, specify one of the following:

     # setenv HTTPPROXY mycache.domain # setenv HTTPPROXYPORT 8080

   • Specify the web proxy on the patchadd command line.

     For example:

     # patchadd -x mycache.domain:8080 \ -M http://www.sun.com/solaris/patches/latest 101223-02 102323-02

Restrictions on Using patchadd -R to Create an Alternate root Path

On systems that are running a Solaris release that is not zones aware, using the patchadd command, or any command that accepts the -R option to specify an alternate root path for a global zone that has non-global zones installed, does not work.

You can use of the -R option to add and remove software packages and patches, if the alternate boot environment has configured non-global zones, but no installed non-global zones.

To avoid a potential problem, restrict the use of the -R option for the creation of an alternate root path.

If you are running this Solaris release, you can alternately choose one of the following methods:

• Upgrade any systems that are not running the current Solaris release.

• Boot an alternate root as the active OS.

If you are running the Solaris 10 OS, you can alternately choose one of the following methods:

• Upgrade any systems that are not running at least the Solaris 10 1/06 OS to the Solaris 10 1/06 release.

• If you are running the Solaris 10 initial 3/05 release, you can install the following patch to enable the use of commands that accept the -R option for creation of an alternate root path.

  • For SPARC based systems – Install at least revision 19 of patch 119254.

  • For x86 based systems – Install at least revision 19 patch 119255.

• Boot an alternate root, for example the Solaris 10 release, as the active OS. You can then install and uninstall packages and patches without using the -R option.

For more information, see the patchadd(1M), patchrm(1M), pkgadd(1M), and pkgrm(1M) man pages.

How to Download and Apply a Solaris Patch

Use this procedure to download either a signed or an unsigned Solaris patch and then apply it to your system.

If you want to apply signed patches, you must first set up the package keystore.

1. Gain access to the system in one of the following ways:

   • Log in to the system where you want to apply the patch.

   • Download the patch and use the ftp command to copy the patch to the target system.

2. Start a web browser and go to the SunSolve Online Patch Portal at http://sunsolve.Sun.COM.

3. Determine whether to download a specific patch or a patch cluster, then do one of the following:

   • Type the patch number (patch-id) in the Find Patch search field, then click Find Patch.

     Entering patch-id downloads the latest patch revision.

     If this patch is freely available, the patch README appears. If this patch is not freely available, an ACCESS DENIED message appears.

     Note that patch numbers for SPARC based and x86 based systems are different. The patch IDs are listed in the patch README. Ensure that you apply the patch that matches your system architecture.

   • Select the Recommended Patch Cluster that matches the Solaris release that is running on the system that you want to patch.

4. Download the patch by following these instructions:

   • To download a copy of the signed patch, click the Download Signed Patch (n bytes) button.

   • To download an unsigned patch, click the Download Patch (n bytes) button.

   When the patch or patches are successfully downloaded, close the web browser.

5. Change to the directory that contains the downloaded patch.

6. Become superuser or assume an equivalent role.

7. (Unsigned patch) If you downloaded an unsigned patch, unzip the patch.

   # unzip patch-id

8. Apply the signed or unsigned patch.

   • If you downloaded a signed patch, apply it.

     For example:

     # patchadd /tmp/111879-01.jar

   • If you downloaded an unsigned patch, apply it.

     For example:

     # patchadd /tmp/111879-01

9. Verify that the patch has been successfully applied.

   For example:

   # patchadd -p | grep 111879 Patch: 111879-01 Obsoletes: Requires: Incompatibles: Packages: SUNWwsr

How to Display Information About Solaris Patches

Before applying patches, you might want to know more about patches that have been previously applied.

The following commands provide useful information about patches that are already applied to a system.

• patchadd -p or showrev -p

  Shows all patches that have been applied to the system.

• pkgparam pkgid PATCHLIST

  Shows all patches that have been applied to the package identified by pkgid, for example, SUNWadmap.

• patchadd -S Solaris-OS -p

  Shows all the /usr patches that have been applied to an OS server.

1. Use one of the following patchadd command lines to display information about patches that have been applied to your system.

   • To obtain information about all patches that have been applied to your system, type:

     $ patchadd -p

   • To verify whether a particular patch has been applied to your system, type, for example:

     $ patchadd -p | grep 111879

How to Remove a Solaris Patch by Using the patchrm Command

1. Become superuser.

2. Remove the patch.

   # patchrm 111879-01 Checking installed patches... Backing out patch 111879-01... Patch 111879-01 has been backed out.

3. Verify that the patch was removed.

   # patchadd -p | grep 111879 #