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