Adding Packages Packages are installed using the pkgadd command. This is usually an interactive procedure, but we will also look at how packages can be installed without requiring any operator input. This can be useful if you need to install the same package on many servers. Once you are happy with the installation process for that package on a test server, you can automate the process for your remaining systems. Packages can be stored in either of two possible formats. They can be held within a single package file or they can be in an exploded (or directory) format. If a package is being installed from tape it will be in single-file format; if it is being installed from CD it could be in either. Packages can be freely transferred between these two formats (using the pkgtrans command). The pkgadd command can install exploded packages in much the same way as the single-file versions. The most common method of installing a package manually is to use pkgadd with the "-d" option. The "-d" should be followed by the name of the device containing the package. If the package is on tape, the device specified would be the tape device (e.g., /dev/rmt/0); if it is a single file on disk, then the filename would follow the "-d." If the package is in exploded format, then the directory containing the package directory is supplied as the argument following the "-d." Examples of using pkgadd are as follows: hydrogen# pkgadd -d /dev/rmt/0 hydrogen# pkgadd -d package.pkg hydrogen# pkgadd -d /export/package_dir Each of the above examples will result in pkgadd listing all the available packages on that device, so you can select which you actually want to install. This is because each of them may contain more than one package. If you know the package name(s) you wish to install, you can supply it/them at the end of any of the above commands. Alternatively, if you know you wish to install all the packages, you can use the keyword "all" instead. We will now look at the full process of installing an actual package. Rather than using a third-party package that you may not be able to get hold of easily, we will use one that is on the Solaris CD that wasn't installed because we didn't choose the SUNCall cluster (which installs everything) at install time. The package we will install contains the System Activity Reporting (sar) tool, which can be useful for helping diagnose performance problems on the system. We will use this as a way of getting used to adding and removing packages, and then we will examine it in detail so we understand how a package is made up. The sar program is contained in the System Accounting package, which has two parts: a root package and a user package. These two packages can be found on your Solaris CD in the directory /cdrom/cdrom0/s0/Solaris_2.7/Product (assuming you have the Solaris 7 CD). The packages are called SUNWaccr (the root part) and SUNWaccu (the user part). Since they live in a directory with several hundred other packages, we will copy them onto the hard disk and install them from there to make things simpler. We could have installed them directly from their directory on the CD if we wished. All the Solaris packages that live on the CD are in exploded format but we will be converting them into a single file when we transfer them. This can be achieved with the pkgtrans command (which is used specifically for converting packages between file and directory formats). The following commands will do this for us: hydrogen# mkdir /export/packages hydrogen# cd /cdrom/cdrom0/s0/Solaris_2.7/Product hydrogen# pkgtrans . /export/packages/sar.pkg SUNWaccr SUNWaccu hydrogen# cd /export/packages hydrogen# ls -l hydrogen# -rw-r--r-- 1 root other 150016 Mar 14 18:15 sar.pkg hydrogen# pkginfo -d sar.pkg system SUNWaccr System Accounting, (Root) system SUNWaccu System Accounting, (Usr) hydrogen# The pkginfo command allows us to double-check that the file created does in fact contain the two packages we expect, so that we can go ahead and install them with the following pkgadd command: hydrogen# pkgadd d sar.pkg The following packages are available: 1 SUNWaccr System Accounting, (Root) (sparc) 11.7.0,REV=1998.09.01.04.16 2 SUNWaccu System Accounting, (Usr) (sparc) 11.7.0,REV=1998.09.01.04.16 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: This is informing us that the file (or device) sar.pkg contains two packages and is asking us what we want to do with them. Hitting <return> will select the default action and cause all packages to be installed, so we'll do that. The pkgadd command now installs each of the packages in turn. We are presented with some information about the first package (SUNWaccr) before being asked one of a number of questions we need to respond to. We will look at how we can skip the interactive bits later. Processing package instance <SUNWaccr> from </export/sar.pkg> System Accounting, (Root) (sparc) 11.7.0,REV=1998.09.01.04.16 Copyright 1998 Sun Microsystems, Inc. All rights reserved. Using </> as the package base directory. ## Processing package information. ## Processing system information. 10 package pathnames are already properly installed. ## Verifying package dependencies. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. This package contains scripts which will be executed with super-user permission during the process of installing this package. Do you want to continue with the installation of <SUNWaccr> [y,n,?] The first question is warning us that the package contains scripts that need to perform an action that only root is able to do. These scripts are not being installed by the package, but will actually be executed during the installation procedure and will perform a specific task, such as creating a user. As we know that this package came straight from the Solaris CD, we can trust that it is not going to do anything untoward. Consequently, we can say, "Yes, we do want to continue." However, we need to be aware that, although unlikely, this is a way that unscrupulous individuals could get to run anything they wanted as root! Installing System Accounting, (Root) as <SUNWaccr> ## Installing part 1 of 1. [ verifying class <preserve> ] [ verifying class <initd> ] /etc/rc2.d/S21perf <linked pathname> Installation of <SUNWaccr> was successful. Processing package instance <SUNWaccu> from </export/sar.pkg> System Accounting, (Usr) (sparc) 11.7.0,REV=1998.09.01.04.16 Copyright 1998 Sun Microsystems, Inc. All rights reserved. Using </> as the package base directory. ## Processing package information. ## Processing system information. 4 package pathnames are already properly installed. ## Verifying package dependencies. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. The following files are being installed with setuid and/or setgid permissions: /usr/lib/acct/accton <setuid root> Do you want to install these as setuid/setgid files [y,n,?,q] The package installation has completed the root part of the package and moved onto the user part. The next pause is to warn us that the SUNWaccu package contains a program that has its setuid bit set to run as root. This message is different from the warning we saw earlier. This doesn't mean that the installation procedure will do something with root privileges; it means that it will actually install a program on the system that will have root privileges whenever it is run. This type of program is usually referred to as setuid or setgid (see Chapter 4, "Permissions and All That"). Again, since this is an official Sun package, we can safely continue. This package contains scripts which will be executed with super-user permission during the process of installing this package. Do you want to continue with the installation of <SUNWaccu> [y,n,?] We now have the same warning about scripts running as root, but this time for the second of the two packages. Answer "y" to this question and the installation will complete: Installing System Accounting, (Usr) as <SUNWaccu> ## Installing part 1 of 1. Installation of <SUNWaccu> was successful. We can now check that the new package is installed correctly using the pkginfo command: hydrogen# pkginfo -l SUNWaccr SUNWaccu PKGINST: SUNWaccr NAME: System Accounting, (Root) CATEGORY: system ARCH: sparc VERSION: 11.7.0,REV=1998.09.01.04.16 BASEDIR: / VENDOR: Sun Microsystems, Inc. DESC: utilities for accounting and reporting of system activity PSTAMP: on99819980901043848 INSTDATE: Mar 17 2001 18:49 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 22 installed pathnames 10 shared pathnames 1 linked files 16 directories 2 executables 7 blocks used (approx) PKGINST: SUNWaccu NAME: System Accounting, (Usr) CATEGORY: system ARCH: sparc VERSION: 11.7.0,REV=1998.09.01.04.16 BASEDIR: / VENDOR: Sun Microsystems, Inc. DESC: utilities for accounting and reporting of system activity PSTAMP: on99819980901043848 INSTDATE: Mar 17 2001 19:12 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 47 installed pathnames 4 shared pathnames 6 directories 39 executables 1 setuid/setgid executables 507 blocks used (approx) hydrogen# The status of both packages is "completely installed." We now have the sar tool installed should we need to use it later. hydrogen# which sar /bin/sar hydrogen# Not all packages are split into two parts as this one was; some will contain only one part and others may contain many more. Those that have root and user parts tend to be SUNW packages that form part of Solaris itself. They are split in this way to give you an idea of where the files in each package will be installed. The files in the root package will be installed in the root filesystem and the files from the user package will be installed in the /usr filesystem. Third-party packages vary depending on the size and structure of the package. You may find that some third-party packages are split into separate packages so you can easily choose which features of the package you actually want to install. Removing Packages Package removal is achieved by using the pkgrm command. If you type pkgrm on its own, it will display a list which includes every package installed on the system and allow you to choose which package you wish to remove. A far easier way to remove packages is to specify them by name as arguments to pkgrm. If you are not sure of the correct package name you can use pkginfo to display it for you: hydrogen# pkginfo | grep acc system SUNWaccr System Accounting, (Root) system SUNWaccu System Accounting, (Usr) hydrogen# Once you have the names, you can remove the package or packages as follows: hydrogen# pkgrm SUNWaccr SUNWaccu The following package is currently installed: SUNWaccr System Accounting, (Root) (sparc) 11.7.0,REV=1998.09.01.04.16 Do you want to remove this package? pkgrm will deal with each package supplied in turn, so we will answer "y" here to remove the SUNWaccr package: ## Removing installed package instance <SUNWaccr> ## Verifying package dependencies. ## Processing package information. ## Removing pathnames in class <initd> /etc/rc2.d/S21perf /etc/init.d/perf /etc/init.d/acct ## Removing pathnames in class <preserve> /var/spool/cron/crontabs/sys /etc/acct/holidays ## Removing pathnames in class <none> /var/spool/cron/crontabs <shared pathname not removed> /var/spool/cron <shared pathname not removed> /var/spool <shared pathname not removed> /var/adm/sa /var/adm/acct/sum /var/adm/acct/nite /var/adm/acct/fiscal /var/adm/acct /var/adm <shared pathname not removed> /var <shared pathname not removed> /etc/rc2.d <shared pathname not removed> /etc/rc1.d <shared pathname not removed> /etc/rc0.d <shared pathname not removed> /etc/init.d <shared pathname not removed> /etc/datemsk /etc/acct /etc <shared pathname not removed> ## Updating system information. Removal of <SUNWaccr> was successful. The following package is currently installed: SUNWaccu System Accounting, (Usr) (sparc) 11.7.0,REV=1998.09.01.04.16 Do you want to remove this package? <remainder of output removed for clarity> hydrogen# Removing a package is not simply a matter of deleting all the files that were installed in that package. Some packages have dependencies on other packages being installed. When you install a package with dependencies, pkgadd performs a check that the packages it is dependent upon exist during the installation process. If they are not already installed, pkgadd will not install the new package. This means that after the package has been installed we know all its prerequisites have been met. But if someone were to remove one of the packages it was dependent on, then it may no longer function correctly. This is clearly not a good situation to get into. Consequently, package dependencies are not simply checked when a new package is installedthey also need to be checked every time a package is removed. When pkgrm is happy that the removal of the package will not cause dependency issues, it will begin to remove the files and directories that were installed with the package. It does this by class. In the above output extract, we can see that the SUNWaccr package has three classesinitd, preserve, and none. For each path that belongs to the package, pkgrm will first check that it is not also used by another package before actually removing it. When a package is being installed, all the information that pkgadd needs is held as part of the package (whether on tape, CD, or another medium). However, it is not practical to expect the original package media to be available when removing packages. This problem is resolved by storing all the information about the package in a central location at install time. This means that pkgrm can make use of this information when a package is removed, but the information can also be used to check that the packages you have installed are still in a consistent state. Checking Packages The command pkgchk has been provided to check that packages are in a consistent state. You might think there is not much reason for having a command to check packages, since once they are installed they are unlikely to change and should just keep on working. Unfortunately, because packages can place files in any part of the filesystem and the system administrator has full access to all directories, it is possible that over time items that are part of a package could change. This could be the outcome of housekeeping a filesystem, changing the permissions of a file, or removing a file you think is no longer needed. It is therefore a good idea to run pkgchk on a regular basis so you can become aware of any inconsistencies that may have crept into the system. You can also use pkgchk to fix some of the problems it may find. By default, pkgchk will check each file contained in the package specified and report if any of the file's attributes and contents are different from when it was installed. In situations where a configuration file has been delivered by a package, it may not be a problem if the contents are reported as incorrect because you may have updated it. If you just want to check the attributes, you can use a "-a" flag; if you just want to check file contents, you can use a "-c" flag. If you do not supply a package name to check, pkgchk will check all packages for attributes and contents. The following example will check the files contained in the SUNWpsr and SUNWpsu packages. These are the root and user parts of the SunSoft Print Server package: hydrogen# pkgchk SUNWpsr SUNWpsu ERROR: /var/spool/lp permissions <0755> expected <0775> actual group name <tty> expected <lp> actual hydrogen# This tells us that the directory /var/spool/lp has incorrect permissions and an incorrect group. This is probably not something to get too worried about, but we can attempt to fix things by using the "-f" flag: hydrogen# pkgchk -f SUNWpsr SUNWpsu hydrogen# pkgchk SUNWpsr SUNWpsu hydrogen# Neither command produced any output so we know the problem is now resolved. The "-f" will only attempt to fix problems associated with the file's attributes; it will never alter the contents of a file. You can also use pkgchk to find out which package a file belongs to: hydrogen# pkgchk -l -p /usr/bin/ls Pathname: /usr/bin/ls Type: regular file Expected mode: 0555 Expected owner: bin Expected group: bin Expected file size (bytes): 18120 Expected sum(1) of contents: 53113 Expected last modification: Oct 06 08:43:05 AM 1998 Referenced by the following packages: SUNWcsu Current status: installed hydrogen# This tells us that the ls program belongs to the SUNWcsu package; we can find out the full package name using pkginfo: hydrogen# pkginfo SUNWcsu system SUNWcsu Core Solaris, (Usr) hydrogen# As well as telling us which package ls belongs to, pkgchk will also tell us what the attributes and check sum of the file should be. However, pkgchk can only tell us this information if it was held within the package control files (which we will look at in detail when we dissect a package). | 
