Sidebar: UNIX System V Release 4 Software Packages

The setup script discussed in the article does not install software. The setup script makes links from wherever the software is actually installed (the "package") so that the software appears to be installed in a set of directories under /opt. Before you can run the setup script against a package, you must have installed the package, or must have configured the software to look like an installed package.

We install packages on "local" disks, which are NFS-mounted on workstations and other servers as /home/server/l00, where the last two digits indicate the lab or domain. We normally install no software directly on workstations, other than that included as part of the initial operating system installation. All software "packages" are forced into the configuration required by our setup script, as described in the article.

Software packages are defined by the UNIX System V Application Binary Interface (ABI) to ensure that software can be packaged for installation on any compliant platform. This sidebar is a brief overview of software packages. For practical details and examples, see your OS documentation, for example, Sun's Application Packaging and Installation Guide.

The software packages scheme defines a standard format for a package on the distribution media (tape or CD-ROM), and a standard set of tools for installing and removing packages. A package may contain operating system or application software. (Sun also uses this scheme for packaging all its Solaris software patches.)

On the distribution medium, a package contains a certain minimum set of files that define how the package is to be installed. Every "object" (file, directory, pipe, socket) in the package is listed, along with where it goes, what its permissions should be, and so on. When a package is installed (the pkgadd command under Solaris), the package information is kept in a database under /var/sadm so that the package can later be verified or removed.

The SVR4 ABI says nothing about the installed content of a package or how users are to access the installed package. For example, if you install ten packages, each of which has executables in a /bin subdirectory, your OS manual likely suggests adding each /bin subdirectory to your search path. With a few packages and infrequent changes, this will work. With close to one hundred packages and frequent changes, it does not work for us. Hence the setup script.

Another subtle problem with software packages is that they seem to have been defined without reference to the problems of administering a large network of workstations. Under Solaris, it is assumed that you will install packages on each and every machine (with the exception of diskless and dataless clients). This is impractical, even if we had the disk space.

There is a particular problem applying patches. The installpatch utility will not follow the symbolic links in our /opt tree. If the patch affects only an /opt/SUNW* package, a copy can be temporarily installed on /opt, patched, and then moved to a local disk and set up. Crude and painful, but it gets the job done.

But if the patch affects objects outside the /opt tree (not unusual), and so must be applied on every workstation, this solution does not work. The /var/sadm database on each workstation does not show that the patch is installed, but the package as linked through /opt is already patched, so the attempt to apply the patch dies horribly. We have resorted to modifying the installpatch script, or just hacking away by hand, in these cases. Very painful. Sun needs a more flexible way of applying patches -- a way that is network-smart.

Installpatch also keeps under /var/sadm a complete copy of all files patched, so that a patch may be backed out. This is a great idea. However, it seems rather wasteful to store this data on every one of perhaps a hundred identically installed and patched workstations! I don't even want to think about how many hundreds of megabytes of space we have devoted to this. Again, it looks as though no thought went into the problems of administering large numbers of workstations on a network.

We're working on a more elegant solution to these problems, just in case the vendors take years to do it themselves. Perhaps that will be the subject of a future article.