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:
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.
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.
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 OnlineSM 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.
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 SunSpectrumSM 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.
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.
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.
Use the following information to identify tasks for managing Solaris patches. Each task points to additional tasks, such as managing signed or unsigned patches.
Task |
Description |
For Instructions |
---|---|---|
Determine whether to apply signed or unsigned patches. |
Determine whether applying signed or unsigned patches is best for your environment. |
Determining Whether to Apply Signed or Unsigned Patches to Your System |
Apply a patch to your system. |
Use the patchadd command on Solaris 2.6, Solaris 7, Solaris 8, Solaris 9, Solaris 10 or Solaris Express systems to apply unsigned Solaris patches. |
Managing Solaris Patches by Using the patchadd Command (Task Map) |
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.
The following terms are used throughout the patch management chapters.
To install a patch on a system.
To remove a patch from a system.
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).
Directory in which backout data is stored. By default, this is the save directory of each package that was installed by the patch.
See patch dependency.
An electronic signature that can be used to ensure that a document has not been modified since the signature was applied.
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.
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.
A repository of certificates and keys that is queried when you attempt to apply a signed 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.
To sort a set of patches in an order suitable for applying patches.
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.
An update to software that corrects an existing problem or that introduces a feature.
A method of checking a system to determine which patches are appropriate for the system.
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.
A unique alphanumeric string, with the patch base code first, a hyphen, and a number that represents the patch revision number.
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.
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.
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.
A source of Solaris patches that can be used by your systems to perform patch analyses and from which to obtain the appropriate patches.
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.
A change to software that you apply that corrects an existing problem or that introduces a feature.
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 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
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.
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.
A patch that is not signed with a digital signature.
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.
Task |
Description |
For Instructions |
---|---|---|
1. (Optional) Set up the package keystore. |
If you plan to apply signed patches to your system, you must first import Sun's Root CA certificate into your package keystore. |
How to Import a Trusted Certificate to Your Package Keystore |
2. (Optional) Specify a web proxy. |
If your system is behind a firewall with a web proxy, you must specify the web proxy to obtain patches from the Sun patch server. | |
3. Download and apply a patch. |
You can download and apply a patch to your system by using the patchadd command. | |
4. (Optional) Display information about patches that have been applied to your system. |
If you want information about the patches that have already been applied to your system, use the patchadd, showrev, or pkgparam command. | |
5. (Optional) Remove a patch from your system. |
If necessary, remove a patch from your system by using the patchrm command. |
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.
Become superuser or assume an equivalent role.
If you are using the patchadd command to install signed patches, add the new trusted Verisign certificate to the keystore.
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
Select the binary format (DER encoded).
Copy the certificate to the file, /tmp/root.crt.
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.
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 |
Indicates that the certificate is a trusted CA certificate. The command output includes the certificate details, which you are asked to verify.
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.
Specifies the file that contains the certificate.
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 |
Remove the temporary file.
# rm /tmp/root.crt |
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> |
Exports the trusted certificate.
Specifies the password that protects the integrity of the Java keystore.
Identifies the alias of the trusted certificate.
Specifies the name and location of the keystore file.
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.
If your system is behind a firewall with a web proxy, you must specify the web proxy to use patchadd to apply a patch.
Become superuser or assume an equivalent role.
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 |
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.
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.
Gain access to the system in one of the following ways:
Start a web browser and go to the SunSolve Online Patch Portal at http://sunsolve.Sun.COM.
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.
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.
Change to the directory that contains the downloaded patch.
Become superuser or assume an equivalent role.
(Unsigned patch) If you downloaded an unsigned patch, unzip the patch.
# unzip patch-id |
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 |
Verify that the patch has been successfully applied.
For example:
# patchadd -p | grep 111879 Patch: 111879-01 Obsoletes: Requires: Incompatibles: Packages: SUNWwsr |
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.
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 |