Chapter 22 Managing Software (Overview)

The management of software involves adding and removing software from standalone systems, servers, and their clients. This chapter describes background and other information about the various tools available for installing and managing software.

This chapter does not describe installing the Solaris software on a new system, nor does it describe installing or upgrading a new version of the Solaris software. For information on installing or upgrading Solaris software, see Solaris 9 12/03 Installation Guide.

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

• What's New in Software Management in the Solaris 9 Update Releases

• What's New in Software Management in the Solaris 9 Release?

• 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)

• Avoiding User Interaction When Adding Packages (pkgadd)

For step-by-step instructions on managing software, see Chapter 23, Managing Software (Tasks).

What's New in Software Management in the Solaris 9 Update Releases

This section describes a new software management feature in this Solaris release.

pkgadd and patchadd Support for Signed Packages and Patches

Solaris 9 12/03 –This Solaris release enables you to securely download Solaris packages and patches that include a digital signature by using the updated pkgadd and patchadd commands.

In previous Solaris releases, you could download the Solaris patch management tools and use the smpatch command with PatchPro to manage signed patches. For step-by-step instructions on using the smpatch command to manage signed patches, see Preparation for Managing Signed Patches with smpatch Command (Task Map).

For step-by-step instructions on using the patchadd command to add signed patches, see Adding Signed Patches With patchadd Command (Task Map).

For step-by-step instructions on using the pkgadd command to add signed packages, see Adding and Removing Signed Packages (Task Map).

prodreg Command Enhancements

Solaris 9 4/03 –You can now use several options to the prodreg command to access and manage the Solaris Product Registry from the command line.

For information on using the prodreg command to administer software packages, see Managing Software With the Solaris Product Registry Command-Line Interface (Task Map).

What's New in Software Management in the Solaris 9 Release?

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

Signed Patches

All patches that are available for the Solaris 2.6, 7, 8, and 9 releases include a digital signature. A valid digital signature ensures that the patch has not been modified since the signature was applied.

Using signed patches is a secure method of downloading or applying patches because the patches include a digital signature that can be verified before the patch is applied to your system.

Signed patches are stored in Java^TM archive format files (abc.jar) and are available from the SunSolve Online^SM Web site.

For information about adding signed patches with the smpatch command, see Preparation for Managing Signed Patches with smpatch Command (Task Map). For troubleshooting problems with the smpatch command, go to http:sunsolve.Sun.COM/pub-cgi/show.pl?target=patches/spfaq.

Solaris Product Registry 3.0

The Solaris Product Registry 3.0 is a GUI tool that enables you to install and uninstall software packages.

For information on using this product to manage software packages, see Managing Software With the Solaris Product Registry GUI (Task Map).

Patch Analyzer

When you use the Solaris^TM Web Start program to upgrade to a Solaris 9 Update Release, the patch analyzer performs an analysis on your system to determine which (if any) patches will be removed or downgraded by upgrading to the Solaris Update Release. You do not need to use the Patch Analyzer when you upgrade to the Solaris 9 release.

For information on using this tool when you are upgrading to a Solaris 9 update release, see “Upgrading to a Solaris Update Release (Tasks)” in Solaris 9 12/03 Installation Guide.

Solaris Management Console Patch Manager

The Solaris Management Console provides a new Patches Tool for managing patches. You can only use the Patches Tool to add patches to a system running the Solaris 9 release.

For information on starting the Solaris Management Console, see How to Start the Console as Superuser or as a Role.

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 vendors deliver software products in a form called a package.

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 operating environment 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 a collection of files and directories that replace or update existing files and directories that are preventing proper execution of the existing software. For more information about patches, see Chapter 24, Managing Solaris Patches (Overview).

Signed Packages and Patches

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 adding patches because the digital signature can be verified before the patch is added to your system.

For more information about adding signed patches to your system, see Adding Signed Patches With 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 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 table describes the general terms associated with signed packages and patches.

The process of adding a signed package or patch to your system involves three basic steps:

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

2. (Optional) Listing the certificates with the pkgadm command

3. Adding the package with the pkgadd command or adding the patch with the patchadd command

For step-by-step instructions on adding signed packages to your system, see Adding and Removing Signed Packages (Task Map). For step-by-step instructions on adding signed patches to your system, see Adding Signed Patches With patchadd Command (Task Map).

Using Sun's Certificates to Verify Signed Packages and Patches

A stream-formatted SVR4–signed package or patch contains an embedded PEM-encoded PKCS7 signature. This signature contains at a minimum the encrypted digest of the package or patch, along with the signer's X.509 public key certificate. The package or patch can also contain a certificate chain that is used to form a chain of trust from the signer's certificate to a locally stored trusted certificate.

The PEM-encoded PKCS7 signature is used to verify the following:

• The package came from the entity that signed it.

• The entity indeed signed it.

• The package hasn't been modified since the entity signed it.

• The entity that signed it is a trusted entity.

The following table describes the encryption terminology associated with signed packages and patches.

Digital certificates, issued and authenticated by Sun Microsystems, are used to verify that the downloaded package or patch with the digital signature has not been compromised. These certificates are imported into your system's keystore.

All Sun certificates are issued by Baltimore Technologies, which recently bought GTE CyberTrust.

Access to a keystore is protected by a special password that you specify when you import the Sun certificates into your system's 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: GTE CyberTrust Root
       Common Name: GTE CyberTrust Root
  Certificate Type: Trusted Certificate
Issuer Common Name: GTE CyberTrust Root
    Validity Dates: <Feb 23 23:01:00 1996 GMT> - <Feb 23 23:59:00 2006 GMT>
   MD5 Fingerprint: C4:D7:F0:B2:A3:C5:7D:61:67:F0:04:CD:43:D3:BA:58
  SHA1 Fingerprint: 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6...

The following table describes the output of the pkgadm listcert command.

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

SunSolve Online's Trusted Certificates

SunSolve Online uses the following certificates to verify the digital signatures on signed patches with the previous Solaris patch management tools (smpatch command), including PatchPro:

• Top-level certificate, called the Root Certificate Authority (CA)

• A subordinate CA, which is the Sun Microsystems Inc., CA Class B certificate.

• An additional certificate issued by Sun Enterprise^TM Services, called the patch management certificate

A certificate authority certifies the relationship between public keys that are used to decrypt the digital signature with the patch and the owner of the public keys.

The Sun Root CA, Sun Class B CA, and the patch signing certificate are included with the Solaris patch management tools, including PatchPro. These three certificates provide a certificate chain of trust in the patch verification process whereby the Sun Root CA trusts the Class B CA, and the Class B CA trusts the patch management certificate. And, ultimately, the GTE CyberTrust CA trusts the Sun Root CA.

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.

  https://ra.sun.com:11005/

• PatchPro's keystore – If you have installed PatchPro for adding signed patches with the smpatch command, you can import Sun's Root CA certificate from the Java keystore.

Setting Up a Package Keystore

In previous Solaris releases, you could download the patch management tools and create a Java keystore, for use by PatchPro, by importing the certificates with the keytool command.

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 into the Package Keystore (pkgadm addcert).

For complete instructions on adding signed packages with the pkgadd command, see Adding and Removing Signed Packages (Task Map).

Tools for Managing Software Packages

The tools for adding and removing software packages from a system after the Solaris release is installed on a system are the following:

Adding or Removing a Software Package (pkgadd)

All the software management tools that are listed in Table 22–1 are used to add, remove, or query information about installed software. Admintool, the Solaris Product Registry prodreg viewer, and the Web Start program all 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 product 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 Web Start program, Solaris Product Registry prodreg viewer (either GUI or CLI), Admintool, 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 these tools 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, but that 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, which will update the software product database correctly so that the file is no longer a part of the package. For more information, see removef(1M).

If you intend to keep multiple versions of a package (for example, multiple versions of a document processing application), install new versions into a different directory than the already installed package with the pkgadd command. 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 admin(4).

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

Avoiding User Interaction When Adding Packages (pkgadd)

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 will prevent 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
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 with 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), which specifies where the package will be installed. For more information, see admin(4).

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 or not optional pieces of the package should be installed.

If prior to installation, you know that the package you want to install is an interactive package, and you want to store your answers to prevent user interaction during future installations of this package, you can 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.