Part V Managing Software

This part provides instructions for managing Solaris software packages and patches. This part contains these chapters.

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"

• "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 reference to find step-by-step instructions for administering software.

• Chapter 17, Software Administration (Tasks)

• Chapter 18, Patch Administration (Overview)

• "Troubleshooting Software Administration Problems" in System Administration Guide, Volume II for information on troubleshooting software administration problems.

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:

• The pkgadd and pkgrm commands

• Admintool^TM

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.

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:

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

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:

• When the server is running a different Solaris release than the client - For example, the server is running the Solaris 7 release and it is serving Solaris 2.5 diskless clients.

• When the server and the clients are different hardware platforms - For example, the server is a SPARC system serving diskless 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, 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.

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.

Chapter 17 Software Administration (Tasks)

This chapter describes how to install, remove, and administer software packages with Solaris commands and the Admintool graphical interface.

This is a list of step-by-step instructions in this chapter.

• "How to Add Packages to a Standalone System"

• "How to Add a Package to a Spool Directory"

• "How to Determine Where a Package's Files Will Be Installed"

• "How to Add a Package to a Diskless or AutoClient System's root (/) File System"

• "How to Add Packages to a Server"

• "How to Check the Integrity of an Installed Package"

• "How to List Information About All Installed Packages"

• "How to Display Detailed Information About a Package"

• "How to Remove a Package"

• "How to Remove a Spooled Package"

• "How to Remove a Diskless or AutoClient System's Package"

• "How to Add Packages With Admintool"

• "How to Remove Packages With Admintool"

Commands for Handling Software Packages

Table 17-1 shows commands to use for adding, removing, and checking the installation of software packages.

Known Problem With Adding and Removing Packages

There is a known problem with adding or removing some packages developed before the Solaris 2.5 release. If adding or removing a package fails during user interaction, or if you are prompted for user interaction and your responses are ignored, set the following environment variable:

NONABI_SCRIPTS=TRUE

Adding Packages

How to Add Packages to a Standalone System

1. Log in as superuser.

2. Remove any already installed packages with the same names as the ones you are adding.

   This ensures that the system keeps a proper record of software that has been added and removed. There may be times when you want to maintain multiple versions of the same application on the system. For strategies on how to do this, see "Guidelines for Removing Packages", and for task information, see "How to Remove a Package".

3. Add a software package to the system.

   # pkgadd -a admin-file -d device-name pkgid ...

   -a admin-file	(Optional) Specifies an administration file pkgadd should consult during the installation. (For details about using an administration file, see "Using an Administration File" in the previous chapter.)
   -d device-name	Specifies the absolute path to the software packages. device-name can be a the path to a device, a directory, or a spool directory. If you do not specify the path where the package resides, the pkgadd command checks the default spool directory (/var/spool/pkg). If the package is not there, the package installation fails.
   pkgid	(Optional) Is the name of one or more packages (separated by spaces) to be installed. If omitted, the pkgadd command installs all available packages.

   If pkgadd encounters a problem during installation of the package, it displays a message related to the problem, followed by this prompt:

   Do you want to continue with this installation?

   Respond with yes, no, or quit. If more than one package has been specified, type no to stop the installation of the package being installed. pkgadd continues to install the other packages. Type quit to stop the installation.

4. Verify that the package has been installed successfully, using the pkgchk command.

   # pkgchk -v pkgid

   If pkgchk determines there are no errors, it returns a list of installed files. Otherwise, it reports the error.

Example--Installing Software From a Mounted CD

The name of this release is Solaris 7 but code and path or package path names may use Solaris 2.7 or SunOS 5.7. Always follow the code or path as it is written.

The following example shows a command to install the SUNWaudio package from a mounted Solaris 7 CD. The example also shows use of the pkgchk command to verify that the packages files were installed properly.

# pkgadd -d /cdrom/cdrom0/s0/Solaris_2.7/Product SUNWaudio
	.
	.
	.
Installation of <SUNWaudio> complete.
# pkgchk -v SUNWaudio
/usr
/usr/bin
/usr/bin/audioconvert
/usr/bin/audioplay
/usr/bin/audiorecord

Example--Installing Software From a Remote Package Server

If the packages you want to install are available from a remote system, you can manually mount the directory containing the packages (in package format) and install packages on the local system. The following example shows the commands to do this. In this example, assume the remote system named package-server has software packages in the /latest-packages directory. The mount command mounts the packages locally on /mnt, and the pkgadd command installs the SUNWaudio package.

# mount -F nfs -o ro package-server:/latest-packages /mnt
# pkgadd -d /mnt SUNWaudio
	.
	.
	.
Installation of <SUNWaudio> was successful.
 

If the automounter is running at your site, you do not need to mount the remote package server manually. Instead, use the automounter path (in this case, /net/package-server/latest-packages) as the argument to the -d option.

# pkgadd -d /net/package-server/latest-packages SUNWaudio
	.
	.
	.
Installation of <SUNWaudio> was successful.

The following example is similar to the previous one, except it uses the -a option and specifies an administration file named noask-pkgadd, which is illustrated in "Avoiding User Interaction When Adding Packages". In this example, assume the noask-pkgadd administration file is in the default location, /var/sadm/install/admin.

# pkgadd -a noask-pkgadd -d /net/package-server/latest-packages SUNWaudio
	.
	.
	.
Installation of <SUNWaudio> was successful.

Using a Spool Directory

For convenience, you can copy frequently installed packages to a spool directory. If you copy packages to the default spool directory, /var/spool/pkg, you do not need to specify the source location of the package (-d device-name argument) when using the pkgadd command. The pkgadd command, by default, looks in the /var/spool/pkg directory for any packages specified on the command line. Note that copying packages to a spool directory is not the same as installing the packages on a system.

How to Add a Package to a Spool Directory

1. Log in as superuser to the server or standalone system.

2. Remove any already spooled packages with the same names as the ones you are adding.

   For information on removing spooled packages, see "How to Remove a Spooled Package".

3. Add a software package to a spool directory.

   # pkgadd -d device-name -s spooldir pkgid ...

   -d device-name	Specifies the absolute path to the software packages. device-name can be the path to a device, a directory, or a spool directory.
   -s spooldir	Specifies the name of the spool directory where the package will be spooled. You must specify a spooldir.
   pkgid	(Optional) Is the name of one or more packages (separated by spaces) to be added to the spool directory. If omitted, pkgadd copies all available packages.

4. Verify that the package has been copied successfully to the spool directory, using the pkginfo command.

   $ pkginfo -d spooldir| grep pkgid

   If pkgid is copied correctly, the pkginfo command returns a line of information about it. Otherwise, pkginfo returns the system prompt.

Example--Setting Up a Spool Directory From a Mounted CD

The following example shows a command to copy the SUNWaudio and SUNWab2m packages from a mounted SPARC Solaris 7 CD to the default spool directory (/var/spool/pkg).

# pkgadd -d /cdrom/cdrom0/s0/Solaris_2.7/Product -s /var/spool/pkg  
SUNWaudio SUNWab2m
Transferring <SUNWaudio> package instance
Transferring <SUNWab2m> package instance

Example--Setting Up a Spool Directory From a Remote Package Server

If packages you want to copy are available from a remote system, you can manually mount the directory containing the packages (in package format) and copy them to a local spool directory. The following example shows the commands to do this. In the following example, assume the remote system named package-server has software packages in the /latest-packages directory. The mount command mounts the package directory locally on /mnt, and the pkgadd command copies the SUNWman package from /mnt to the default spool directory (/var/spool/pkg).

# mount -F nfs -o ro package-server:/latest-packages /mnt
# pkgadd -d /mnt -s /var/spool/pkg SUNWman
Transferring <SUNWman> package instance

If the automounter is running at your site, you do not have to mount the remote package server manually. Instead, use the automounter path (in this case, /net/package-server/latest-packages) as the argument to the -d option.

# pkgadd -d /net/package-server/latest-packages -s /var/spool/pkg SUNWman
Transferring <SUNWman> package instance

Example--Installing a Package From the Default Spool Directory

The following example shows a command to install the SUNWman package from the default spool directory. (When no options are used with pkgadd, it searches /var/spool/pkg for the named packages.)

# pkgadd SUNWman
	.
	.
	.
Installation of <SUNWman> was successful.

Adding Packages in a Homogeneous Client/Server Environment

For the purposes of this discussion, a homogeneous client/server means the clients and servers are running the same version of the Solaris operating environment and are the same hardware platform (either all SPARC or all x86 platforms).

This section describes how to install packages that place files in a client's root file system. If you are installing a package for clients, and that package does not place files on the client's root file system, the package can be installed directly on the server and shared. (This assumes that the package is installed to a file system such as /usr on the server.)

Use the pkgadd command with the -R option to specify the location of the client's root file system for the client installation. (There's a common misconception that you can use the -R option to specify an alternate base directory for a package installation. That is not the case. The -R option is specifically for defining the client's root file system. To specify an alternate base directory, use pkgadd with the -a option and provide an administration file that has the basedir keyword set to the new installation directory.)

Packages installed on the server for diskless and AutoClient systems are read-only to the client and are shared with other clients.

Although there are several ways to install and maintain packages in a client/server environment, this section provides instructions on how to do this from a server. This is a centralized software administration model. Note, however, that you can log in to clients and install software directly on them.

Adding Sun Packages on Clients

In general, when installing Sun packages on clients in a homogeneous environment, follow the guidelines in Table 17-2.

You can determine where a Sun package's files are installed by using the procedure "How to Determine Where a Package's Files Will Be Installed".

Adding Third-Party Packages on Clients

When installing third-party packages on clients, follow these guidelines:

1. Install the package on the server using the procedure "How to Add Packages to a Standalone System".

2. Install the package on the client using the procedure "How to Add a Package to a Diskless or AutoClient System's root (/) File System".

Adding Packages in a Heterogeneous Client/Server Environment

For the purposes of this discussion, a heterogeneous client/server environment means the clients and servers are either running different versions of the Solaris operating environment or are different hardware platforms (for example, a Solaris 2.3 server of Solaris 7 clients, or an x86 server with SPARC clients). Adding packages in a heterogeneous client/server environment presents its own difficulties. The server will have multiple /usr file systems for the heterogeneous clients it supports. For example, it might have an x86 /usr file system for its x86 clients, a Solaris 2.4 /usr file system for its Solaris 2.4 clients, and so on. In general, when installing packages in a heterogeneous client/server environment, follow the guidelines in Table 17-3.

How to Determine Where a Package's Files Will Be Installed

This procedure is valid only for Sun software packages. For third-party software products, the surest way to determine where the package's files will be installed is to look in the package's directory in the pkgmap file.

1. Log in to any system.

   You must be able to access the directory where the packages reside.

2. Determine where a Sun package's files will be installed.

   $ pkgparam -d device-name pkgid SUNW_PKGTYPE

   -d device-name	Specifies the absolute path to the software packages. device-name can be the path to a device, a directory, or a spool directory. If you do not use the -d option, the pkgparam command will return the default installation directory of the specified pkgid installed on the local system.
   pkgid	Is the name of a software package.
   SUNW_PKGTYPE	Is a special parameter that reports where a Solaris software package will be installed. If the package does not have the SUNW_PKGTYPE parameter set, the pkgparam command returns an empty string. For Sun packages, this usually means the package will be installed in /opt.

Example--Determining Where a Package's Files Will Be Installed

$ pkgparam -d /cdrom/cdrom0/s0/Solaris_2.7
/Product SUNWvolr SUNW_PKGTYPE
root
$ pkgparam -d /cdrom/cdrom0/s0/Solaris_2.7/Product SUNWvolu  SUNW_PKGTYPE
usr

How to Add a Package to a Diskless or AutoClient System's root (/) File System

When you add a package to a diskless or AutoClient system, you don't actually install the package on the client. Instead, you add the package to the client's root file system, which resides on a server. A diskless or AutoClient system's root file system is typically in /export/root/hostname on the server.

If the package's files are installed into the /usr file system, you need to install the package on the server. If you are working in a homogeneous client/server environment, use Table 17-2 to determine how to install the package. If you are working in a heterogeneous client/server environment, use Table 17-3 to determine how to install the package.

1. Log in to the server as superuser.

2. Remove any already installed packages with the same names as the ones you are adding.

   This ensures that the system keeps a proper record of software that has been added and removed. There may be times when you want to maintain multiple versions of the same application on the system. For strategies on how to do this, see "Guidelines for Removing Packages", and for task information, see "How to Remove a Diskless or AutoClient System's Package".

3. Add a software package to the client system's root (/) file system.

   server# pkgadd -R rootpath -d device-name pkgid ...

   -R rootpath	Specifies the path name of the client's root file system.
   -d device-name	Specifies the absolute path to the software packages. device-name can be the path to a device, a directory, or a spool directory. If you do not specify the path where the package resides, the pkgadd command checks the default spool directory (/var/spool/pkg). If the package is not there, the package installation fails.
   pkgid	(Optional) Is the name of one or more packages (separated by spaces) to be installed. If omitted, pkgadd installs all available packages.

   ---

   Caution -

   During the installation, you may see the following message: WARNING: filename <not present on Read Only file system>

   This indicates that not all of the package's files have been installed. The client may not have access to all files necessary for the software to work correctly. If you see this warning message, you must also install the package on the server as well as the client's root file system.

   ---

4. Verify the package has been installed by logging in to the server as superuser and using the pkginfo command.

   server# pkginfo -R rootpath | egrep pkgid

   The pkginfo command returns a line of information about the installed pkgid. If pkgid is not installed, pkginfo returns the system prompt.

5. Verify that the package has been installed successfully using the pkgchk command.

   server# pkgchk -R rootpath -v pkgid

   If pkgchk determines there are no errors, it returns a list of installed files. Otherwise, it reports the error.

Example--Installing a Package From a Mounted CD to a Diskless Client's Root File System

The name of this release is Solaris 7 but code and path or package path names may use Solaris 2.7 or SunOS 5.7. Always follow the code or path as it is written.

The following example shows a command to install the SUNWadmr (software to support system and network administration) package from a server onto a diskless client's root file system. In this case, the diskless client's root file system is /export/root/client-1. This example assumes the SUNWadmr package is available from a mounted SPARC 2.7 Solaris CD (/cdrom/cdrom0/s0/Solaris_2.7/Product). The example also shows use of pkginfo and pkgchk to verify that the package's files were installed properly.

server# pkgadd -R /export/root/client-1 
-d /cdrom/cdrom0/s0/Solaris_2.7/Product SUNWadmr
			.
			.
			.
Installation of <SUNWadmr> complete.
server# pkginfo -R /export/root/client-1 | egrep SUNWadmr
system			SUNWadmr			System & Network Administration Root
server# pkgchk -v -R /export/root/client-1 SUNWadmr
/etc
/etc/init.d
/etc/init.d/autoinstall
/etc/init.d/sysid.net
/etc/init.d/sysid.sys
/etc/rc2.d
/etc/rc2.d/S30sysid.net
/etc/rc2.d/S71sysid.sys
/etc/rc2.d/S72autoinstall
/sbin
/sbin/bpgetfile

Example--Installing a Package From a Package Server to a Diskless Client's Root File System

The following example shows a command to install the SUNWcg6 package from a server onto a diskless client's root file system. In this case, the diskless client's root file system is /export/root/client-2. This example assumes the SUNWcg6 package is available from a package server on the network (/net/package-server/latest-packages).

server# pkgadd -R /export/root/client-2
-d /net/package-server/latest-packages SUNWcg6
		.
		.
		.
Installation of <SUNWcg6> complete.

How to Add Packages to a Server

1. Log in to the server as superuser.

2. Make sure the server has the OS services necessary for its diskless and AutoClient systems.

   Use Host Manager to verify the OS services available on the server. If you need to add OS services, you can do that using the "Add Services" capability of Host Manager. For detailed information, see Chapter 4, Managing Server and Client Support (Tasks).

3. Determine your next step based on whether the server and the diskless or AutoClient systems are the same Solaris release and the same hardware platform.

   If the Diskless or AutoClient Systems and Server Are ...	Then ...
   The same Solaris release and the same hardware architecture	Do not use this procedure. Instead, use the procedure "How to Add Packages to a Standalone System".
   Either different Solaris releases or different hardware platforms (for example, a Solaris 2.5 server of Solaris 7 diskless clients, or an x86 server of SPARC diskless clients)	Go to Step 4.

4. Make a copy of the default administration file.

   # cp /var/sadm/install/admin/default /var/sadm/install/admin/admin-file

5. Edit the new administration file and set the basedir keyword.

   Use a text editor to edit the new administration file and set the basedir keyword to the correct path for the OS services supporting the client.

   basedir=/export/exec/Solaris_2.7_platform.all/usr

   Solaris_2.7	Is the Solaris version number: for example, Solaris_2.7
   platform	Is the hardware architecture of the client: for example, i386or sparc, as in Solaris_2.7_i386.all or Solaris_2.7_sparc.all.

6. Add a software package to the server.

   The administration file will specify to install the package into the /usr file system appropriate for the client.

   # pkgadd -a admin-file -d device-name pkgid ...

   -a admin-file	(Optional) Specifies an administration file pkgadd should consult during the installation. By default, pkgadd looks in the /var/sadm/install/admin directory for the specified administration file. You can also specify an absolute path to an administration file.
   -d device-name	Specifies the absolute path to the software packages. device-name can be the path to a device, a directory, or a spool directory. If you do not specify the path where the package resides, pkgadd checks the default spool directory (/var/spool/pkg). If the package is not there, the package installation fails.
   pkgid	(Optional) Is the name of one or more packages (separated by spaces) to be installed. If omitted, pkgadd installs all available packages.

   If the pkgadd command encounters a problem during installation of the package, it displays a message related to the problem, followed by this prompt:

   Do you want to continue with this installation?

   Respond with yes, no, or quit. If more than one package has been specified, type no to stop the installation of the package being installed. pkgadd continues to install the other packages. Type quit to stop the installation.

7. Verify that the package has been installed, using the pkginfo command.

   # pkginfo pkgid*

   The pkginfo command will return all instances of the installed package. Typically, pkgadd installs duplicate versions of an already installed package as pkgid.1, pkgid.2, and so on.

8. Verify that the package has been installed successfully, using the pkgchk command.

   # pkgchk -v pkgid

   If the pkgchk command determines there are no errors for the specified package instance, it returns a list of installed files. Otherwise, it reports the error.

Example--Installing Software From a Mounted CD

The following example shows a command to install a fictitious package SUNWtoolu, which will install files into a /usr file system. Assume that the package resides on a mounted product CD, which is mounted on /cdrom/cdrom0 by default. The pkgadd command uses an administration file named new-basedir, which specifies a new installation directory for the package. The example also shows use of pkgchk to verify that the package's files were installed properly.

# pkgadd -a new-basedir /cdrom/cdrom0 SUNWtoolu
	.
	.
	.
Installation of <SUNWtoolu> complete.
# pkgchk -v SUNWtoolu
/usr
/usr/bin
/usr/bin/toolconvert
/usr/bin/toolplay
/usr/bin/toolrecord

Checking the Installation of Packages

You use the pkgchk command to check installation completeness, path name, file contents, and file attributes of a package. See pkgchk(1M) for more information on all the options.

Use the pkginfo command to display information about the packages that are installed on the system.

How to List Information About All Installed Packages

List information about installed packages with the pkginfo command.

$ pkginfo

Example--Listing All Packages Installed

The following example shows the pkginfo command to list all packages installed on a local system, whether that system is a standalone, server, diskless client, or AutoClient system. The output shows the primary category, package name, and a description of the package.

$ pkginfo
system      SUNWab2m       Solaris Documentation Server Lookup
system      SUNWaccr       System Accounting, (Root)
system      SUNWaccu       System Accounting, (Usr)
system      SUNWadmap      System administration applications
system      SUNWadmc       System administration core libraries

Example--Listing All Packages Installed on a Diskless or AutoClient System

In a diskless or AutoClient system client/server setup, you may want to manage software from a central location. Since the server is the place to do this, you would need to use a variation of the pkginfo command. The following example shows the pkginfo -R command to list all packages installed on a diskless client named io. This command is executed from the diskless client's server.

server$ pkginfo -R /export/root/io
system			SUNWaccr			System Accounting, (Root)
system			SUNWaccu			System Accounting, (Usr)
system			SUNWadmap		System & Network Administration Applications
system			SUNWadmfw		System & Network Administration Framework
	.
	.
	.

How to Check the Integrity of an Installed Package

1. Log in to a system as superuser.

2. Check the status of an installed package with the pkgchk command.

   # pkgchk -a | -c -v pkgid ... # pkgchk -d spooldir pkgid ...

   -a	Specifies to audit only the file attributes (that is, the permissions), rather than the file attributes and contents, which is the default for pkgchk.
   -c	Specifies to audit only the file contents, rather than the file contents and attributes, which is the default for pkgchk.
   -v	Specifies verbose mode, which displays file names as pkgchk processes them.
   -d spooldir	Specifies the absolute path of the spool directory.
   pkgid	(Optional) Is the name of one or more packages (separated by spaces). If you do not specify a pkgid, pkgchk checks all the software packages installed on the system. If omitted, pkgchk displays all available packages.

Example--Checking the Contents of an Installed Package

The following example shows how to check the contents of a package.

# pkgchk -c SUNWadmfw

If pkgchk determines there are no errors, it returns the system prompt. Otherwise, it reports the error.

Example--Checking the File Attributes of an Installed Package

The following example shows how to check the file attributes of a package.

# pkgchk -a SUNWadmfw

If pkgchk determines there are no errors, it returns the system prompt. Otherwise, it reports the error.

Example--Checking Packages Installed in a Spool Directory

The following example shows how to check a software package copied to a spool directory (/export/install/packages).

# pkgchk -d /export/install/packages
## checking spooled package <SUNWadmap>
## checking spooled package <SUNWadmfw>
## checking spooled package <SUNWadmc>
## checking spooled package <SUNWsadml>

The checks made on a spooled package are limited because not all information can be audited until a package is installed.

How to Display Detailed Information About a Package

List information about installed packages with the pkginfo -l command.

$ pkginfo -l pkgid ...

Example--Displaying Detailed Information About a Package

$ pkginfo -l SUNWcar
     PKGINST:  SUNWcar
      NAME:  Core Architecture, (Root)
  CATEGORY:  system
      ARCH:  sparc.sun4m
   VERSION:  11.6.0,REV=1998.05.06.20.36
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  core software for a specific hardware platform group
    PSTAMP:  on99819980507193137
  INSTDATE:  Jun 02 1998 11:43
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:     48 installed pathnames
                 5 shared pathnames
                 7 directories
                20 executables
              3299 blocks used (approx)

Removing Packages From Servers and Standalone Systems

Always use the pkgrm command to remove installed packages. Do not use the rm command, which will corrupt the system's record-keeping of installed packages.

How to Remove a Package

1. Log in to the system as superuser.

2. Remove an installed package.

   # pkgrm pkgid ...

   pkgid

   (Optional) Is the name of one or more packages (separated by spaces). If omitted, pkgrm removes all available packages.

How to Remove a Spooled Package

1. Log in as superuser.

2. Remove a package from a spool directory with the pkgrm -s command.

   # pkgrm -s spooldir pkgid ...

   -s spooldir	Specifies the name of the spool directory where the package was spooled.
   pkgid	(Optional) Is the name of one or more packages (separated by spaces). If no pkgid is supplied, pkgrm prompts the user to remove each package listed in the spool directory. If omitted, pkgrm removes all available packages.

How to Remove a Diskless or AutoClient System's Package

1. Log in to the server and become superuser.

2. Remove a software package from a diskless client's OS server with the pkgrm -R command.

   server# pkgrm -R rootpath pkgid ...

   -R rootpath	Specifies the mount point of the client's root file system.
   pkgid	(Optional) Is the name of one or more packages (separated by spaces) to be removed. If omitted, pkgrm removes all available packages.

   Files in the client's package database that are marked shared are not removed from the server, but are removed from the client's database. If all clients have removed the package, you can remove the shared files from the server by using a separate invocation of pkgrm on the server.

3. Verify that the package has been removed successfully by using the pkginfo command.

   server# pkginfo -R rootpath | egrep pkgid

   If pkgid is installed, the pkginfo command returns a line of information about it. Otherwise, pkginfo returns the system prompt.

Example--Removing a Diskless Client's Package

In the following example, assume the client's root file system is shared. Also, assume these commands are executed on the client's server.

server# pkgrm -R /export/root/client-1 SUNWaudio
The following package is currently installed.
SUNWaudio
Do you want to remove this package? y/n/q?
 
y
	.
	.
	.

Adding and Removing Packages Using Admintool

The Solaris 7 operating environment includes Admintool, which is a graphical user interface for performing several administration tasks, including adding and removing software packages. Specifically, you can use Admintool to:

• Add software packages to a local system

• Remove software packages from a local system

• View software already installed on the local system

• Customize software packages to be installed

• Specify an alternate installation directory for a software package

How to Add Packages With Admintool

1. Log in to the installed system and become superuser.

   At the shell prompt, type:

   $ su

   Unless you are a member of the UNIX sysadmin group (group 14), you must become superuser on your system to add or remove software packages with Admintool.

2. Load a CD into the CD-ROM drive.

   Volume Manager will automatically mount the CD.

3. Start Admintool.

   # admintool &

   The Users window is displayed.

4. Choose Software from the Browse menu.

   The Software window is displayed.

5. Choose Add from the Edit menu.

   The Set Source Media window may appear. If so, specify the path to the installation media and click on OK. The default path is a mounted SPARC Solaris CD.

   The Add Software window is displayed.

   

6. Select the software you want to install on the local system.

   In the Software portion of the window, click on the check boxes corresponding to the software you want to install.

7. Click on Add.

   A Command Tool window appears for each package being installed, displaying the installation output.

   The Software window refreshes to display the packages just added.

How to Remove Packages With Admintool

1. Log in to the installed system and become superuser.

   At the shell prompt, type:

   $ su

   Unless you are a member of the UNIX sysadmin group (group 14), you must become superuser on your system to add or remove software packages with Admintool.

2. Start Admintool.

   # admintool &

3. Choose Software from the Browse menu.

   The Software window is displayed.

   

4. Select the software you want to remove from the local system.

5. Choose Delete from the Edit menu.

   A warning pop-up window is displayed to confirm whether you really want to delete the software.

6. Click on Delete to confirm that you want to remove the software.

   For each package that is being deleted, a Command Tool window is displayed that asks for confirmation, again, before deleting the software. Type y, n, or q. If you choose to delete the software, the output from the removal process is displayed.

Chapter 18 Patch Administration (Overview)

For the purpose of this discussion, patch administration involves installing or removing Solaris patches from a running Solaris system. It may also involve removing (called backing out) unwanted or faulty patches.

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

• "What Is a Patch"

• "Tools For Managing Patches"

• "Patch Distribution"

• "Patch Numbering"

• "What Happens When You Install a Patch"

• "What Happens When You Remove a Patch"

What Is a Patch

In its simplest form, you can think of a patch as a collection of files and directories that replace or update existing files and directories that are preventing proper execution of the software. The existing software is derived from a specified package format, which conforms to the Application Binary Interface. (For details about packages, see Chapter 16, Software Administration (Overview).)

Tools For Managing Patches

There are two utilities for managing patches:

• patchadd - use to install directory-format patches to a Solaris 7 system.

• patchrm - use to remove patches installed on a Solaris 7 system. This command restores the file system to its state before a patch was applied.

Detailed information about how to install and back out a patch is provided in the Install.info file with each patch. Each patch also contains a README file that contains specific information about the patch.

Before installing patches, you might want to know more about patches that have previously been installed. Table 18-1 shows commands that provide useful information about patches already installed on a system.

Patch Distribution

All Sun customers can access security patches and other recommended patches via the World Wide Web or anonymous ftp. Sun customers who have purchased a service contract can access an extended set of patches and a complete database of patch information. This information is available via the World Wide Web, anonymous ftp, and it is regularly distributed on a CD-ROM (See Table 18-2).

What You Need to Access Sun Patches

You can access Sun patches via the World Wide Web or anonymous ftp. If you have purchased a Sun service contract, you will also be able to get patches from the patch CD-ROM that is regularly distributed.

To access patches on the World Wide Web, you need a machine that is:

• Connected to the Internet

• Capable of running Web browsing software such as Mosaic or Netscape

To access patches via anonymous ftp, you need a machine that is:

• Connected to the Internet

• Capable of running the ftp program

Patch Access Via the World Wide Web

To access patches via the World Wide Web, use this uniform resource locator (URL):

http://www.sun.com/

After reaching the Sun home page, click on the Sales and Service button and navigate your way to the SunSolve patch database.

The patch database for publicly available patches are labeled "Public patch access." The patch database for the comprehensive set of patches and patch information available to contract customers is labeled "Contract customer patch access." You will be prompted for a password to access this contract customer database.

You can also access publicly available patches using this URL:

http://sunsite.unc.edu/

Patch Access Via ftp

To access patches via ftp, you can use the ftp command to connect to either the sunsolve1.sun.com (provided by Sun Service) or sunsite.unc.edu (maintained by the University of North Carolina). When ftp prompts you for a login, enter anonymous as the login name. Use your complete email address when prompted for a password. After the connection is complete, you can find publicly available patches in the /pubs/patches directory.

To transfer patches, you will need to change the ftp transfer mode to binary. To do this, enter bin at the ftp prompt.

Patch Numbering

Patches are identified by unique alphanumeric strings, with the patch base code first, a hyphen, and a number that represents the patch revision number. For example, patch 101977-02 is a Solaris 2.4 patch to correct the lockd daemon.

What Happens When You Install a Patch

When you install a patch, the patchadd command copies files from the patch directory to a local system's disk. More specifically, patchadd:

• Determines the Solaris version number of the managing host and the target host

• Updates the patch package's pkginfo file with information about patches obsoleted by the patch being installed, other patches required by this patch, and patches incompatible with this patch

During the patch installation, patchadd keeps a log of the patch installation in /var/sadm/patch/patch-number/log for the Solaris 2.4 release and compatible versions. The Solaris 2.5 release and compatible versions also store log files in this location, but only if installation errors occurred.

The patchadd command will not install a patch under the following conditions:

• The package is not fully installed on the host

• The patch's architecture differs from the system's architecture

• The patch's version does not match the installed package's version

• There is already an installed patch with the same base code and a higher version number

• The patch is incompatible with another, already installed patch. (Each installed patch keeps this information in its pkginfo file)

• The patch being installed requires another patch that is not installed

What Happens When You Remove a Patch

When you back out a patch, the patchrm command restores all files modified by that patch, unless:

• The patch was installed with patchadd -d (which instructs patchadd not to save copies of files being updated or replaced)

• The patch has been obsoleted by a later patch

• The patch is required by another patch

The patchrm command calls pkgadd to restore packages that were saved from the initial patch installation.

During the patch installation, patchrm keeps a log of the patch installation in /tmp/backoutlog.process_id. This log file is removed if the patch backs out successfully.