test

System Administration Guide, Volume I

Chapter 16 Software Administration (Overview)

Software administration involves installing 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

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

Software Packages

For the purpose of this discussion, 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 two tools for adding and removing software from a system:

Although either of these are appropriate to use, each has its merits.

Using the pkgadd and pkgrm commands offers flexibility. For example, you can incorporate these commands into scripts, set up optional files to avoid user interaction or perform special checks, and copy software packages to spool directories. If you're already familiar with adding and removing packages with the pkgadd and pkgrm commands, it's probably easiest for you to continue using them.

Using Admintool to add and remove software offers ease of use, because it is a graphical interface to the pkgadd and pkgrm commands and it includes online help that provides general information on using the tool. Using the Admintool graphical interface is an especially nice way to view software already installed on a system or the software that resides on the installation media. If you're unfamiliar with software package naming conventions, you're uncomfortable using command line options, and you're managing software only on one system at time, it's probably easiest for you to use Admintool to add and remove software.

Table 16-1 suggests some of the relative merits of using Admintool as opposed to using the pkgadd and pkgrm commands to manage software.

Table 16-1 Admintool Software Management Capabilities

Software Management Tasks 

Performed With Admintool? 

Add and remove packages on standalone, server, or diskless systems 

Yes 

Easily view all installed software 

Yes  

Easily view and select packages from an installation media 

Yes 

Add packages to a spool directory 

No 

Eliminate user interaction by using an administration file 

No 

Note that prior to the Solaris 2.5 release, Software Manager (accessed with the swmtool command) was the graphical tool for adding and removing software. With the Solaris 2.5 release and compatible versions, Admintool (accessed with the admintool command) provides that capability. 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:

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

Solaris supports diskless clients and Solstice AutoClient systems. On diskless and AutoClient systems, all software resides on the server. For example, when you add a software package to a diskless client, you don't actually install the package on the client, because it doesn't have any local disk storage device. Instead, you add the package either to the server or to the client's root file system (which resides on the server), or both. A diskless or AutoClient system's root file system is typically in /export/root/hostname on the server.

AutoClient systems have their own disk storage, but it is only used for caching. The software resides on a server. (See the Solstice AutoClient 2.1 Administration Guide for more information.)

Because diskless and AutoClient systems may have software partially installed on their root file system and partially installed on a server's /usr (or some other shared file system), adding software packages to these clients requires that you know where (in what file systems) a software package is supposed to be installed.

Installing Sun Packages on Servers and Clients

When adding packages for diskless and AutoClient systems, it is important to know where those packages' files are installed--in the client's root file system or in a server's /usr file system (or any other file system shared with the client).

Many Sun software packages are named to indicate where they are installed. For example, the SUNWvolr package is installed in the root file system and the SUNWvolu package is installed in the /usr file system. The "r" suffix stands for root, and the "u" suffix stands for /usr. However, the surest way to determine where a Sun package's files are installed is to examine the SUNW_PKGTYPE parameter, which is set in the package's pkginfo file. An interface for examining the pkginfo file is described in the procedure "How to Determine Where a Package's Files Will Be Installed".

Some Sun packages do not have a SUNW_PKGTYPE parameter associated with them. These packages are usually set up to be installed in /opt. If a Sun package does not have a SUNW_PKGTYPE parameter value, treat it as a third-party package when installing it. (See "Installing Third-Party Packages on Servers and Clients" for more information.)

When installing Sun packages on diskless or AutoClient systems, follow the general guidelines in Table 16-2.

Table 16-2 Installing Sun Packages on Clients

If Package's Files Are Installed in The ... 

Then Install the Package on The ... 

root (/) file system

Client or the client's root file system 

/usr (or any other shared file system)

Server

Installing Third-Party Packages on Servers and Clients

Third-party packages do not use the SUNW_PKGTYPE parameter. As a result, there is no convenient way to determine where the package's files are installed. The surest way is to examine the package's pkgmap file. Based on that information, you can install according to the guidelines in Table 16-2. However, if you want to avoid having to examine a package's pkgmap file, you can use the following two-step process, which is the safest way to install third-party packages on diskless and AutoClient systems:

  1. Install software on the server. Everything the server shares with clients is updated. (This assumes the server and clients are running the same version of Solaris software and are running on the same hardware platform: for example, either both x86 platforms or both SPARC platforms.)

  2. Install the software on the client. The pkgadd command or Admintool, whichever you're using, will install only those files appropriate for the client. The pkgadd command or Admintool will not install software already available from file systems that are mounted from a server, because that software is already available to the client.

Installing Packages in Heterogeneous Environments

There are two cases in which software management on clients/servers is further complicated:

These are generically referred to as heterogeneous environments. When managing software in heterogeneous environments, you must first add the proper Solaris and architecture services appropriate for the server's clients. To do this, you use Host Manager to "add services" to the server (for detailed information, see Chapter 4, Managing Server and Client Support (Tasks).

For detailed information about how to add packages in a heterogeneous environment, see "Adding Packages in a Heterogeneous Client/Server Environment".

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.

Note -

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.

Caution - Caution -

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.