Chapter 18 Managing Software (Overview)

Software management involves adding and removing software from stand-alone systems, servers, and their clients. This chapter describes the various tools that are available for installing and managing software.

This chapter does not describe installing the Solaris Operating System (Solaris OS) on a new system, nor does it describe installing or upgrading a new version of the Solaris OS. For information about installing or upgrading the Solaris OS, see Solaris Express Installation Guide: Basic Installations.

This is a list of the overview information in this chapter.

• What's New in Software Management in the Solaris Operating System?

• Where to Find Software Management Tasks

• Overview of Software Packages

• Tools for Managing Software Packages

• Adding or Removing a Software Package (pkgadd)

• Key Points for Adding Software Packages (pkgadd)

• Guidelines for Removing Packages (pkgrm)

• Restrictions on Adding and Removing Software Packages and Patches for Solaris Releases That are Not Zones Aware

• Avoiding User Interaction When Adding Packages (pkgadd)

For the most up-to-date information for managing packages and patches in the Solaris OS, see http://www.sun.com/bigadmin/patches/.

For step-by-step instructions on managing software, see Chapter 19, Managing Software With Solaris System Administration Tools (Tasks) and Chapter 20, Managing Software by Using Package Commands (Tasks).

For information about managing software on Solaris systems with zones installed, see Chapter 25, Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks), in System Administration Guide: Virtualization Using the Solaris Operating System.

What's New in Software Management in the Solaris Operating System?

This section describes the new software management features in this Solaris release.

Deferred-Activation Patching

Patching tools have changed to handle larger patches. Starting with patch 119254-42 and 119255-42, the patch installation commands, patchadd and patchrm, have been modified to change the way in which certain patches that deliver new features are handled. This modification affects the installation of these patches on any Solaris 10 release. These deferred-activation patches are better equipped to handle the large scope of changes that are delivered in feature patches.

For more details, see http://www.sun.com/bigadmin/sundocs/articles/patch-wn.jsp.

Common Agent Container Included in the Solaris OS

The Common Agent Container is a stand-alone Java program that implements a container for Java management applications. This program provides a management infrastructure that is designed for Java Management Extensions (JMX) and Java Dynamic Management Kit (Java DMK) based management functionality. The software is installed by the SUNWcacaort package and resides in the /usr/lib/cacao directory.

Typically, the container is not visible.

However, there are two instances when you might need to interact with the container daemon:

• In the event that another application attempts to use a network port that is reserved for the Common Agent Container.

• In the event that a certificate store is compromised. If this conflict occurs, you might have to regenerate the Common Agent Container certificate keys.

For information about how to troubleshoot these problems, see Troubleshooting Common Agent Container Problems in the Solaris OS in System Administration Guide: Advanced Administration.

Improvements to How patchadd -M Command Handles Multiple Patches

Solaris 10: Starting with the Solaris 10 release, the functionality of the patchadd -M command is improved to enable more effective and efficient handling of multiple patches and dependencies between patches. As a result, you no longer have to specify patch IDs in numerical order when using this command.

Note that if you use the patchadd -M command without specifying a patch ID or patch IDs, all the patches in the directory are automatically installed on the system. To install a specific patch or patches, you must specify the patch ID when using the patchadd -M command.

For more information, see the patchadd(1M) man page.

Package and Patch Tool Enhancements

Solaris 10: The Solaris package and patch tools were enhanced in the Solaris 10 initial 3/05 release to provide improved performance and extended functionality.

As a part of these enhancements, the pkgchk command now provides a new option to assist you in mapping files to packages. To map files to packages, use the pkgchk -P option instead of grep pattern/var/sadm/install/contents. The -P option enables you to use a partial path. Use this option with the -l option to list the information about the files that contain the partial path. For more information see How to Check the Integrity of Installed Objects (pkgchk -p, pkgchk -P) and the pkgchk(1M) man page.

Where to Find Software Management Tasks

Use this table to find step-by-step instructions for managing software.

Overview of Software Packages

Software management involves installing or removing software products. Sun and its third-party ISVs deliver software as a collection of one or more packages.

The term packaging generically refers to the method for distributing and installing software products to systems where the products will be used. A package is a collection of files and directories in a defined format. This format conforms to the application binary interface (ABI), which is a supplement to the System V Interface Definition. The Solaris OS provides a set of utilities that interpret this format and provide the means to install a package, to remove a package, or to verify a package installation.

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.

A sparse package contains only those objects that have been altered since the packages were first delivered as part of the Solaris distribution. Sparse packages accommodate patches that are smaller than if they were redistributed as complete packages to provide software updates. Delivering sparse packages also minimizes the changes that are made to the customer's environment. For more information about patches, see Managing Patches in the Solaris Operating System.

Signed Packages, Patches, and Software Updates

Packages can include a digital signature. A package with a valid digital signature ensures that the package has not been modified since the signature was applied to the package. Using signed packages is a secure method of downloading or adding packages because the digital signature can be verified before the package is added to your system.

The same holds true for signed patches. A patch with a valid digital signature ensures that the patch has not been modified since the signature was applied to the patch. Using signed patches is a secure method of downloading or applying patches because the digital signature can be verified before the patch is applied to your system.

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

For information about creating signed packages, see Application Packaging Developer’s Guide.

A signed package is identical to an unsigned package, except for the digital signature. The package can be installed, queried, or removed with existing Solaris packaging tools. A signed package is also binary-compatible with an unsigned package.

Before you can use pkgadd and patchadd to add a package or patch with a digital signature to your system, you must set up a package keystore with trusted certificates. These certificates are used to identify that the digital signature on the package or patch is valid.

The following describes the general terms associated with signed packages and patches.

Keystore

A repository of certificates and keys that is queried when needed.

• Java keystore – A repository of certificates that is installed by default with the Solaris release. The Java keystore is usually stored in the /usr/j2se/jre/lib/security directory.

• Package keystore – A repository of certificates that you import when adding signed packages and patches to your system.

  The package keystore is stored in the /var/sadm/security directory by default.

Trusted certificate

A certificate that holds a public key that belongs to another entity. The trusted certificate is named as such because the keystore owner trusts that the public key in the certificate indeed belongs to the identity identified by the subject or owner of the certificate. The issuer of the certificate vouches for this trust by signing the certificate.

Trusted certificates are used when verifying signatures, and when initiating a connection to a secure (SSL) server.

User key

Holds sensitive cryptographic key information. This information is stored in a protected format to prevent unauthorized access. A user key consists of both the user's private key and the public key certificate that corresponds to the private key.

The process of using the pkgadd or patchadd command to add a signed package or patch to your system involves three basic steps:

1. Adding the certificates to your system's package keystore by using the pkgadm command

2. (Optional) Listing the certificates by using the pkgadm command

3. Adding the package with the pkgadd command or applying the patch by using the patchadd command

For step-by-step instructions on adding signed packages to your system, see Adding and Removing Signed Packages by Using the pkgadd Command (Task Map).

For step-by-step instructions on applying signed patches to your system with the patchadd command, see Managing Solaris Patches by Using the patchadd Command (Task Map).

Using Sun's Certificates to Verify Signed Packages and Patches

Access to a package keystore is protected by a special password that you specify when you import the Sun certificates into your system's package keystore.

If you use the pkgadm listcert command, you can view information about your locally stored certificates in the package keystore. For example:

# pkgadm listcert -P pass:store-pass
    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 

The following describes the output of the pkgadm listcert command.

Keystore Alias

When you retrieve certificates for printing, signing, or removing, this name must be used to reference the certificate.

Command Name

The common name of the certificate. For trusted certificates, this name is the same as the keystore alias.

Certificate Type

Can be one of two types:

• Trusted certificate – A certificate that can be used as a trust anchor when verifying other certificates. No private key is associated with a trusted certificate.

• Signing certificate – A certificate that can be used when signing a package or patch. A private key is associated with a signing certificate.

Issuer Command Name

The name of the entity that issued, and therefore signed, this certificate. For trusted certificate authority (CA) certificates, the issuer common name and common name are the same.

Validity Dates

A date range that identifies when the certificate is valid.

MD5 Fingerprint

An MD5 digest of the certificate. This digest can be used to verify that the certificate has not been altered during transmission from the source of the certificate.

SHA1 Fingerprint

Similar to an MD5 fingerprint, except that it is calculated using a different algorithm.

Each certificate is authenticated by comparing its MD5 and SHA1 hashes, also called fingerprints, against the known correct fingerprints published by the issuer.

Importing Sun's Trusted Certificates

You can obtain Sun's trusted certificates for adding signed packages and patches in the following ways:

• Java keystore – Import Sun's Root CA certificate that is included by default in the Java keystore when you install the Solaris release.

• Sun's Public Key Infrastructure (PKI) site – If you do not have a Java keystore available on your system, you can import the certificates from this site.

Setting Up a Package Keystore

If your system already has a populated Java keystore, you can now export the Sun Microsystems root CA certificate from the Java keystore with the keytool command. Then, use the pkgadm command to import this certificate into the package keystore.

After the Root CA certificate is imported into the package keystore, you can use the pkgadd and patchadd commands to add signed packages and patches to your system.

The Sun Microsystems root-level certificates are only required when adding Sun-signed patches and packages.

For step-by-step instructions on importing certificates into the package keystore, see How to Import a Trusted Certificate From the Java Keystore (pkgadm addcert).

For complete instructions on adding signed packages with the pkgadd command, see How to Add a Signed Package (pkgadd).

Tools for Managing Software Packages

The following table describes the tools for adding and removing software packages from a system after the Solaris release is installed on a system.

For more information about these commands, see Chapter 19, Managing Software With Solaris System Administration Tools (Tasks) and Chapter 20, Managing Software by Using Package Commands (Tasks).

Adding or Removing a Software Package (pkgadd)

All the software management tools that are listed in Table 18–1 are used to add, remove, or query information about installed software. The Solaris Product Registry prodreg viewer and the Solaris installation GUI both access install data that is stored in the Solaris Product Registry. The package tools, such as the pkgadd and pkgrm commands, also access or modify install data.

When you add a package, the pkgadd command uncompresses and copies files from the installation media to a local system's disk. When you remove a package, the pkgrm command deletes all files associated with that package, unless those files are also shared with other packages.

Package files are delivered in package format and are unusable as they are delivered. The pkgadd command interprets the software package's control files, and then uncompresses and installs the product files onto the system's local disk.

Although the pkgadd and pkgrm commands do not log their output to a standard location, they do keep track of the package that is installed or removed. The pkgadd and pkgrm commands store information about a package that has been installed or removed in a software product database.

By updating this database, the pkgadd and pkgrm commands keep a record of all software products installed on the system.

Key Points for Adding Software Packages (pkgadd)

Keep the following key points in mind before you install or remove packages on your system:

• Package naming conventions – Sun packages always begin with the prefix SUNW, as in SUNWaccr, SUNWadmap, and SUNWcsu. Third-party packages usually begin with a prefix that corresponds to the company's stock symbol.

• What software is already installed – You can use the Solaris installation GUI, Solaris Product Registry prodreg viewer (either GUI or CLI) or the pkginfo command to determine the software that is already installed on a system.

• How servers and clients share software – Clients might have software that resides partially on a server and partially on the client. In such cases, adding software for the client requires that you add packages to both the server and the client.

Guidelines for Removing Packages (pkgrm)

You should use one of the tools listed in Table 18–1 to remove a package, even though you might be tempted to use the rm command instead. For example, you could use the rm command to remove a binary executable file. However, doing so is not the same as using the pkgrm command to remove the software package that includes that binary executable. Using the rm command to remove a package's files will corrupt the software products database. If you really only want to remove one file, you can use the removef command. This command will update the software product database correctly so that the file is no longer a part of the package. For more information, see the removef(1M) man page.

If you intend to keep multiple versions of a package, install new versions into a different directory than the already installed package by using the pkgadd command. For example, if you intended to keep multiple versions of a document processing application. The directory where a package is installed is referred to as the base directory. You can manipulate the base directory by setting the basedir keyword in a special file called an administration file. For more information on using an administration file and on setting the base directory, see Avoiding User Interaction When Adding Packages (pkgadd) and the admin(4) man page.

If you use the upgrade option when installing Solaris software, the Solaris installation software checks the software product database to determine the products that are already installed on the system.

Restrictions on Adding and Removing Software Packages and Patches for Solaris Releases That are Not Zones Aware

On systems that are running a Solaris release that is not zones aware, using 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.

These commands include:

• pkgadd

• pkgrm

• patchadd

• patchrm

See the pkgadd(1M), pkgrm(1M), patchadd(1M), and patchrm(1M) man pages.

For additional information, see Restrictions on Using patchadd -R to Create an Alternate root Path.

Avoiding User Interaction When Adding Packages (pkgadd)

This section provides information about avoiding user interaction when adding packages with the pkgadd command.

Using an Administration File

When you use the pkgadd -a command, the command consults a special administration file for information about how the installation should proceed. Normally, the pkgadd command performs several checks and prompts the user for confirmation before it actually adds the specified package. You can, however, create an administration file that indicates to the pkgadd command that it should bypass these checks and install the package without user confirmation.

The pkgadd command, by default, checks the current working directory for an administration file. If the pkgadd command doesn't find an administration file in the current working directory, it checks the /var/sadm/install/admin directory for the specified administration file. The pkgadd command also accepts an absolute path to the administration file.

Use administration files judiciously. You should know where a package's files are installed and how a package's installation scripts run before using an administration file to avoid the checks and prompts that the pkgadd command normally provides.

The following example shows an administration file that prevents the pkgadd command from prompting the user for confirmation before installing the package.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
networktimeout=60
networkretries=3
authentication=quit
keystore=/var/sadm/security
proxy=
basedir=default

Besides using administration files to avoid user interaction when you add packages, you can use them in several other ways. For example, you can use an administration file to quit a package installation (without user interaction) if there's an error or to avoid interaction when you remove packages by using the pkgrm command.

You can also assign a special installation directory for a package, which you might do if you wanted to maintain multiple versions of a package on a system. To do so, set an alternate base directory in the administration file by using the basedir keyword. The keyword specifies where the package will be installed. For more information, see the admin(4) man page.

Using a Response File (pkgadd)

A response file contains your answers to specific questions that are asked by an interactive package. An interactive package includes a request script that asks you questions prior to package installation, such as whether optional pieces of the package should be installed.

If you know prior to installation that the package is an interactive package, and you want to store your answers to prevent user interaction during future installations, use the pkgask command to save your response. For more information on this command, see pkgask(1M).

Once you have stored your responses to the questions asked by the request script, you can use the pkgadd -r command to install the package without user interaction.