Chapter 20 Software Administration (Overview)

Software administration involves adding and removing software from standalone systems, servers, and their clients. This chapter describes background and other useful information about installing and managing software. This chapter does not describe installing the Solaris software, which has its own installation and setup procedures.

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

• "Where to Find Software Administration Tasks"

• "Overview of Software Packages"

• "Tools for Managing Software"

• "What Happens When You Add or Remove a Package"

• "What You Should Know Before Adding or Removing Packages"

• "Guidelines for Client Software Administration"

• "Guidelines for Removing Packages"

• "Avoiding User Interaction When Adding Packages"

Where to Find Software Administration Tasks

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

What's New in Software Management?

This Solaris release includes a new software management tool, Solaris Product Registry. Once the Solaris 8 release is installed, Product Registry provides a list of all software installed using Solaris Web Start 3.0 or the Solaris package management commands. To view the Product Registry, type /usr/bin/prodreg at the command line.

See "Adding and Removing Software With the Product Registry" in Solaris 8 (SPARC Platform Edition) Installation Guide or "Adding and Removing Software After Installing Solaris 8" in Solaris 8 (Intel Platform Edition) Installation Guide for more information.

Overview of Software Packages

Software administration involves installing or removing software products. Sun and its third-party vendors deliver products in a form called a software package. (The term packaging generically refers to the method for distributing and installing software products to systems where the products will be used.) In its simplest form, you can think of a package as 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 or remove a package or to verify its installation.

Tools for Managing Software

There are three tools for adding and removing software from a system after the Solaris release is installed on a system:

The table below describes the advantages of using Admintool rather than the pkgadd and pkgrm commands to manage software.

In previous Solaris releases, Software Manager (accessed with the swmtool command) was the graphical tool for adding and removing software. If you use the swmtool command on a Solaris 2.5 or compatible system, it will start Admintool.

What Happens When You Add or Remove a Package

The pkgadd and pkgrm commands or Admintool are used to add and remove software. Admintool is a graphical front-end to the pkgadd and pkgrm commands.

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 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.

What You Should Know Before Adding or Removing Packages

Before installing or removing packages on your system, you should know:

• Package naming conventions - Sun packages always begin with the prefix SUNW, as in SUNWvolr, SUNWadmap, and SUNWab2m. 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 product registry, Admintool, or the pkginfo command to determine the software 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. If this is the case, adding software for the client requires adding packages to both the server and the client. (The section below describes in more detail how to manage client software.)

Guidelines for Client Software Administration

Managing software on a standalone system is fairly straightforward, after you're familiar with the package installation tools and conventions. You install the software package on a system's local disk and that software is then available for use. However, managing software on client systems can be more difficult--especially when the software resides partially on the server and partially on the client. (For example, a piece of software might have a package with files that are installed on the client's root file system and a package with files that are installed on the /usr file system, which the client typically mounts from a server.)

Guidelines for Removing Packages

Because the pkgadd and pkgrm commands update information in a software products database, it is important when you remove a package to use the pkgrm command--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 pkgrm 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. See removef(1M) for more information.)

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. The directory where a package is installed is referred to as the base directory, and you can manipulate the base directory by setting the basedir keyword in a special file called an administration file. See "Avoiding User Interaction When Adding Packages" and admin(4) for more information on use of an administration file and setting the base directory.

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

Avoiding User Interaction When Adding Packages

Using an Administration File

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

The pkgadd command, by default, looks in the current working directory for an administration file. If pkgadd doesn't find an administration file in the current working directory, pkgadd looks in 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 pkgadd normally provides.

This is an example of an administration file that will prevent pkgadd 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 adding 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 removing packages with the pkgrm command.

You can also assign a special installation directory for a package. (It would make sense to do this if you wanted to maintain multiple versions of a package on a system.) To do this, set an alternate base directory in the administration file (using the basedir keyword), which specifies where the package will be installed. See admin(4) for more information.

Using a Response File

A response file contains your answers to specific questions 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 you know that the package you want to install is an interactive package, prior to installation, 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. See pkgask(1M) for more information on this command.

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.