Dissecting a Package

Team-Fly    

Solaris™ Operating Environment Boot Camp
By David Rhodes, Dominic Butler
Table of Contents
Chapter 8.  Administering Packages


As discussed previously, packages can be in either of two possible formats. The package we installed earlier was stored on the Solaris CD in exploded (or directory) format, but we converted it into a single file on the hard disk before installing it. To examine the files and installation scripts within a package, it needs to be in the exploded form. Packages can be freely transferred between these two formats (using pkgtrans). The pkgadd command can install exploded packages in much the same way as we have seen it install the single-file versions.

To create an exploded package from a single file, we use the pkgtrans as follows:

 hydrogen# cd /export/packages hydrogen# pkgtrans sar.pkg /export/pkgdir 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]:all Transferring <SUNWaccr> package instance Transferring <SUNWaccu> package instance hydrogen# 

Here, we were presented with the same initial dialogue as when we installed the packages. If we had specified the package names on the command line (or the keyword "all"), this would not have been displayed (this is also true when installing packages).

 hydrogen# pkgtrans sar.pkg /export/pkgdir all Transferring <SUNWaccr> package instance Transferring <SUNWaccu> package instance hydrogen# 

This will create a directory in /export/pkgdir for each of the packages transferred. Not surprisingly, each directory is named after the package. Each of these package directories will contain some standard files and directories that are used to manage the installation and removal of the package along with the files and directories that the package delivers.

To understand how a package fits together, we will now look at the SUNWaccr package in detail. It is rare to find a package that makes use of all the available features of the Solaris package management system, so reference will be made here to scripts and features even though they are not specifically used within this package:

 hydrogen# cd /export/pkgdir/SUNWaccr hydrogen# ls l # ls -l total 12 drwxr-xr-x  2 root   staff      512 Mar 18 13:37 archive drwxr-xr-x  2 root   staff      512 Mar 18 13:37 install -rw-r--r--  1 root   other      516 Oct 15  1999 pkginfo -rw-r--r--  1 root   other     1084 Oct 15  1999 pkgmap drwxr-xr-x  4 root   staff      512 Mar 18 13:37 reloc hydrogen# 

All packages must have a pkginfo and pkgmap file, and most will also have the install and reloc directories. The archive directory is used within most packages on the Solaris CD, but it is not compulsory and, in fact, it is not usually considered part of the standard package format.

Pkginfo

The pkginfo file, as you may guess, contains information about the package. You may see a similarity between the contents of this file and the output from the pkginfo -l command, because this is where pkginfo gets its information.

 PKG=SUNWaccr NAME=System Accounting, (Root) ARCH=sparc VERSION=11.7.0,REV=1998.09.01.04.16 SUNW_PRODNAME=SunOS SUNW_PRODVERS=5.7/Generic SUNW_PKGTYPE=root MAXINST=1000 CATEGORY=system DESC=utilities for accounting and reporting of system activity VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= CLASSES=none preserve initd BASEDIR=/ SUNW_PKGVERS=1.0 PSTAMP=on99819980901043848 PKG_SRC_NOVERIFY= none PKG_DST_QKVERIFY= none PKG_CAS_PASSRELATIVE= none #FASPACD= none PATCHLIST= 

You will notice that the file contains a collection of variable assignments. Some of the variables contain information about the package and the company that produced it, but the file may also contain variables that are used by the scripts that manage the package installation and removal. The pkginfo file is created by the package developer and does not need to contain all the variables described here, though certain of them must exist. Table 8.2 describes the ones you are most likely to see. (If you are interested in seeing a full list, run man -s 4 pkginfo, though of course they don't have to be on this list to be used here.)

Table 8.2. Pkginfo Contents

Variable Name

Description

PKG

This is the name of the package that is used with the package manipulation commands (e.g., pkgadd and pkgrm). It is customary to make the first four letters represent your company name, so all Sun package names begin "SUNW."

NAME

This is the more human-friendly version of the package name.

CATEGORY

This holds the category (or categories) to which the package belongs. Every package must belong to at least the system or application category.

ARCH

This is the architecture the package is designed for. Solaris is available for SPARC and INTEL architectures.

VERSION

This one speaks for itself. Solaris practice for version numbers is <major revision>.<minor revision[.<micro revision>], where each revision is an integer.

BASEDIR

This is the default directory under which the package files will be installed. This exists because some packages can be installed in a location of your choice, rather than a location forced upon you. If this is not set, then the package is not relocatable.

VENDOR

This should be set to the name of the company that holds the copyright to the package.

DESC

This is a long description of the package (up to 256 characters).

CLASSES

If this exists, it will contain a space-separated list of classes that have been defined for this package.

ISTATES

If this exists, it will be set to a list of init states (or run levels) that the system must be in to install the package.

RSTATES

This is the same as ISTATES, but it is for removing rather than installing packages.

HOTLINE

This should contain an address or phone number that can be used for support, bug reports, and so forth.

INTONLY

If this is set, it means the package may only be installed interactively.

MAXINST

This tells you the maximum number of instances of a package you may install on one server. If it is not set, you may only install the package once.

Note: Variables that are compulsory are underlined.

Pkgmap

The other file in this directory, pkgmap, is likely to be much larger than pkginfo as it usually contains an entry for every file contained in the package. The entries hold information about file ownership and permissions along with some checksum information, which is used at install time to verify that the package is complete and not corrupt in any way.

Here we have the pkgmap file for the SUNWaccr package:

 : 1 58 1 i copyright 59 5234 904648577 1 i depend 875 7018 904648578 1 d none etc 0755 root sys 1 d none etc/acct 0775 adm adm 1 e preserve etc/acct/holidays 0664 bin bin 289 22090 904647603 1 f none etc/datemsk 0444 root sys 446 24974 904647726 1 d none etc/init.d 0775 root sys 1 e initd etc/init.d/acct 0744 root sys 833 62528 904647604 1 e initd etc/init.d/perf 0744 root sys 989 10168 904647868 1 d none etc/rc0.d 0775 root sys 1 d none etc/rc1.d 0775 root sys 1 d none etc/rc2.d 0775 root sys 1 l initd etc/rc2.d/S21perf=../../etc/init.d/perf 1 i i.initd 6368 3209 904648578 1 i i.preserve 186 13489 904648578 1 i pkginfo 516 41176 904649950 1 d none var 0755 root sys 1 d none var/adm 0775 root sys 1 d none var/adm/acct 0775 adm adm 1 d none var/adm/acct/fiscal 0775 adm adm 1 d none var/adm/acct/nite 0775 adm adm 1 d none var/adm/acct/sum 0775 adm adm 1 d none var/adm/sa 0775 adm sys 1 d none var/spool 0755 root bin 1 d none var/spool/cron 0755 root sys 1 d none var/spool/cron/crontabs 0755 root sys 1 e preserve var/spool/cron/crontabs/sys 0644 root sys 308 22063 28800 

The first line of the file is required and contains two pieces of information. The first is the number of parts to the package and the second is the maximum part size (which is shown in 512-byte blocks).

The remaining lines describe each file that the package contains, including those that are only used during the installation or removal processes. The fields are described in Table 8.3.

Table 8.3. Pkgmap Contents

Field Name

Description

part

This optional field holds the part of the package that the file belongs to. If no part is specified, part 1 is implied.

file type

This field contains a single character to represent the type of the specified file. This could be any of the following:

 

b:

block special device

 

c:

character special device

 

d:

directory

 

e:

file that will be edited upon installation or removal

 

f:

standard executable or data file

 

i:

installation script or information file

 

l:

linked file (the path of the link is also shown)

 

p:

named pipe

 

s:

symbolic link

 

v:

file whose contents will change (e.g., a logfile)

 

x:

directory that will only be accessed by the package

class

This is the class to which the file belongs. This package has defined three classes: none, preserve, and initd. Files of type "i" do not belong to a classjust the files that are actually being delivered.

pathname

This contains the path name of the file. It will usually be a relative path name, which means the package is installable in a location of the operator's choosing.

major

This will only be included for device files and represents the device's major number.

minor

This field is also for devices only and represents the minor device number.

mode

This value represents the permissions of the file in octal format.

owner

The owner of the file is specified in this field. If there is a question mark here, it means the file ownership will not get changed when the file is installed.

group

This is the group to which the file belongs. Again, if it contains a question mark, the group will be left alone.

size

This is the size of the file in bytes. This will not be specified for certain file types (e.g., devices and directories).

checksum

This is the checksum for the file. It will not be specified for devices, directories, or other special files (as with the size field).

modification time

The number here represents the time the file was last modified. As with the previous two fields, it will only exist for ordinary files.

Reloc

The fact that a directory called reloc exists means that this package is relocatable. Therefore, the system administrator is able to install the package in a directory other than its default if required. Most application packages are relocatable and so can be installed in a location of your choosing. Relocatable packages have a default location; this is set in the BASEDIR variable in the pkginfo file.

The following extract shows the files and directories stored under the reloc directory for the SUNWaccr package. Each file or directory must also have an entry in the pkgmap file:

 hydrogen# cd reloc hydrogen# ls -lR .: total 4 drwxr-xr-x 4 root   staff     512 Mar 18 13:37 etc drwxr-xr-x 3 root   staff     512 Mar 18 13:37 var ./etc: total 4 drwxr-xr-x 2 root   staff     512 Mar 18 13:37 acct drwxr-xr-x 2 root   staff     512 Mar 18 13:37 init.d ./etc/acct: total 2 -rw-r--r-- 1 root   staff     289 Sep  1  1998 holidays ./etc/init.d: total 4 -rwxr--r-- 1 root   staff     833 Sep  1  1998 acct -rwxr--r-- 1 root   staff     989 Sep  1  1998 perf ./var: total 2 drwxr-xr-x 3 root   staff     512 Mar 18 13:37 spool ./var/spool: total 2 drwxr-xr-x 3 root   staff     512 Mar 18 13:37 cron ./var/spool/cron: total 2 drwxr-xr-x 2 root   staff     512 Mar 18 13:37 crontabs ./var/spool/cron/crontabs: total 2 -rw-r--r-- 1 root   staff     308 Jan  1  1970 sys hydrogen# 

The reloc directory contains two subdirectories: etc and var. Because the package BASEDIR is set to the root directory, all files and directories contained here will be created under /etc or /var. If the BASEDIR was changed, then the files would be installed relative to the new BASEDIR. Each file under reloc must have an entry in the pkgmap file with matching attributes, otherwise the pkgadd command will refuse to install the package as it will assume it is corrupt.

Install

The install directory contains files and scripts that are used during the installation process.

A package may contain any, all, or none of these files within its install directory:

 hydrogen# ls -l total 24 -rw-r--r-- 1 root   staff      59 Sep  1  1998 copyright -rw-r--r-- 1 root   staff     875 Sep  1  1998 depend -rw-r--r-- 1 root   staff    6368 Sep  1  1998 i.initd -rw-r--r-- 1 root   staff    1935 Jul 28  1999 i.none -rw-r--r-- 1 root   staff     186 Sep  1  1998 i.preserve hydrogen# 

The copyright file is not compulsory. If is exists, it will be a text file containing a copyright message. Its contents are displayed by pkgadd during the installation process.

The depend file, if it has any contents, will contain a list of packages that this package is dependent on (i.e., they must be installed prior to this one). However, it could also contain packages that are incompatible with the one you are installing, or even ones with a reverse dependency. The depend file for SUNWsccr contains the following entries:

 P SUNWcar       Core Architecture, (Root) P SUNWkvm       Core Architecture, (Kvm) P SUNWcsr       Core Solaris, (Root) P SUNWcsu       Core Solaris, (Usr) P SUNWcsd       Core Solaris Devices P SUNWcsl       Core Solaris Libraries 

The "P" in the first column indicates that the six packages listed are prerequisites of SUNWaccr, so it will not be installed unless those six are already fully installed. Instead of a "P" the first column could have an "I" to indicate an incompatible package or an "R" to indicate a reverse dependency. If an incompatible package had been specified in the depend file, its existence on the server would prevent this package from being installed. It is rare to see a package with a reverse dependency. This would only happen to identify that another package had a dependency on this package, and would only be used where the other package was an older one created before dependency files were introduced.

The remaining three files (i.initd, i.none, and i.preserve) are called "class action scripts." There is one for each of the classes defined in the pkginfo file, and these scripts are executed in the order that the classes are defined. The pkgadd program will pass each file listed in the pkgmap file, that is a member of that class, to its class action script. It is up to the class action script to install the file (or do whatever else it wants with it). This will be done for the none class first, and the process will then be repeated for the classes preserve and initd.

The i.none class action script runs first. This is the script that installs most of the files contained in the package. The files installed by this script are in a zip file called none in the archive directory (see below). The i.none script changes the directory to the package base directory and then simply unzips the files into this location.

Next, the i.preserve script runs. This simple script copies the System Accounting holidays file and the sys crontab file (which are supplied as arguments by pkgadd) into their appropriate destination directories.

Finally, the i.initd script runs. This script creates the correct links in the rc directories for the files acct and perf which, if you look in the pkgmap file above, you will see are delivered into /etc/init.d.

The files mentioned below do not exist in this package but have standard names and do exist in many third-party packages. You are likely to use some of them if you create any packages of your own. They are all shell scripts whose names, hopefully, describe their functions. They are executed by the pkgadd command in the following order (assuming they exist):

The checkinstall script is executed first. It should contain code to verify that the system is in a position to have the package installed. These checks could include making sure that particular filesystems exist, that there is enough disk space, and that a suitable version of Solaris is installed.

The preinstall script should perform any actions that need to be run before the package's files are copied into place. This might include creating specific filesystems and users. It may also involve backing up some existing files that may get overwritten by the package, so they can be restored if the package is subsequently removed.

The postinstall script runs after the package contents are put in place. It is likely to perform such tasks as checking that the package is installed correctly and setting up any final configurations that may be required.

The preremove and postremove scripts will not be run during a package install. They are placed in the software product database (under /var/sadm/pkg/pkg_name) for use by the pkgrm command when the package is removed.

Archive

This directory will not always exist within packages. In this case, it contains a single zip file called none. The file contains the vast majority of the files and scripts that make up this package, and they are installed from the i.none script in the install directory.

This way of delivering files is not the only way of doing so and might even be considered nonstandard. Normally the files that a package delivers will be stored under the reloc directory and will be listed in the pkgmap file. A number of packages on the Solaris CD are stored and delivered with the files zipped instead. The advantage of creating packages like this is that because the files are zipped they take up less space on the CD. The disadvantage is that you may not be able to find a file if you want to browse the CD to see which package it belongs to.


    Team-Fly    
    Top
     



    Solaris Operating Environment Boot Camp
    Solaris Operating Environment Boot Camp
    ISBN: 0130342874
    EAN: 2147483647
    Year: 2002
    Pages: 301

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net