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, which is a supplement to the System V Interface Definition. Solaris 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:

• The pkgadd and pkgrm commands
• Admintool

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 browser 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 17-1 suggests some of the relative merits of using Admintool as opposed to using the pkgadd and pkgrm commands to manage software.

Table 17-1

Software Management Tasks	Performed with Admintool?
Add and remove packages on standalone or server systems, diskless or dataless clients	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 Solaris 2.5, Software Manager (accessed with the swmtool command) was the graphical tool for adding and removing software. With the release of Solaris 2.5, Admintool provides that capability. If you use the swmtool command on a Solaris 2.5 system, it will start Admintool.

What Happens When You Add or Remove a Package

When you add a package, the pkgadd software uncompresses and copies files from the installation media to a local system's disk. When you remove a package, pkgrm deletes all files associated with that package, unless those files are also shared with other packages. (This is true whether you use the pkgadd and pkgrm commands or Admintool to add and remove software, because Admintool is a graphical front-end to the pkgadd and pkgrm commands.)

Package files 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. pkgadd and pkgrm 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, SUNWabe. Third-party packages usually begin with a prefix that corresponds to the company's stock symbol.
• Software already installed - You can use the pkginfo command to determine the software already installed on a system or you can use Admintool to view already installed software.
• How servers and clients share software - Clients may 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. ("Guidelines for Client Software Administration" 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 diskless and dataless clients 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, Solstice AutoClient systems, and dataless clients. On diskless clients 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 client'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. Software resides on a server. (See the Solstice AutoClient 1.0 Administration Guide for more information.)

Dataless clients have their own disk storage, but do not have the /usr file system installed locally. Instead, a dataless client mounts the /usr file system from a server.

Because diskless and dataless clients 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 dataless clients, 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" on page 317.

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" on page 290 for more information.)

When installing Sun packages on diskless or dataless clients, follow the general guidelines in Table 17-2.

Table 17-2

If The 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 17-2. However, if you want 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 dataless clients:

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 the same a hardware platform: for example, either both x86 systems or both SPARC systems.)

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:

• When the server is running a different Solaris release than the client: for example, the server is running Solaris 2.5 and it is serving Solaris 2.3 diskless and dataless clients.

• When the server and the clients are different hardware platforms: for example, the server is a SPARC system serving diskless and dataless clients that are x86 systems.

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, "Adding and Maintaining Server and Client Support.

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

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 rm 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 rm 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 the removef(1M) man page 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 basedir, and you can manipulate the basedir by setting the basedir keyword in a special file called an administration file. See "Avoiding User Interaction When Adding Packages" on page 295 and the admin(4) man page 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.

---