Solaris Express Installation Guide: Solaris Live Upgrade and Upgrade Planning

Appendix B Additional SVR4 Packaging Requirements (Reference)

This appendix is for system administrators who install or remove packages, especially third-party packages. Following these packaging requirements enables the following:

This chapter contains the following sections:

Preventing Modification of the Current OS

Following the requirements in this section keeps the currently running OS unaltered.

Using Absolute Paths

For an installation of an operating system to be successful, packages must recognize and correctly respect alternate root (/) file systems, such as a Solaris Live Upgrade inactive boot environment.

Packages can include absolute paths in their pkgmap file (package map). If these files exist, they are written relative to the -R option of the pkgadd command. Packages that contain both absolute and relative (relocatable) paths can be installed to an alternative root (/) file system as well. $PKG_INSTALL_ROOT is prepended to both absolute and relocatable files so all paths are resolved properly when being installed by pkgadd.

Using the pkgadd -R Command

Packages being installed by using the pkgadd -R option or being removed using the pkgrm -R option must not alter the currently running system. This feature is used by custom JumpStart, Solaris Live Upgrade, non-global zones and diskless client.

Any procedure scripts that are included in the packages being installed with the pkgadd command -R option or being removed by using the pkgrm command -R option must not alter the currently running system. Any installation scripts that you provide must reference any directory or file that is prefixed with the $PKG_INSTALL_ROOT variable. The package must write all directories and files with the $PKG_INSTALL_ROOT prefix. The package must not remove directories without a $PKG_INSTALL_ROOT prefix.

Table B–1 provides examples of script syntax.

Table B–1 Examples of Installation Script Syntax

Script Type 

Correct Syntax 

Incorrect Syntax 

Bourne shell “if” statement fragments 

if [ -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf ] ; then
if [ -f /etc/myproduct.conf ] ; \
 then

Removing a file 

/bin/rm -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf
/bin/rm -f /etc/myproduct.conf 

Changing a file 

echo "test=no" > ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf
echo "test=no" > \
/etc/myproduct.conf

Differences Between $PKG_INSTALL_ROOT and $BASEDIR Overview

$PKG_INSTALL_ROOT is the location of the root (/) file system of the machine to which you are adding the package. The location is set to the -R argument of the pkgadd command. For example, if the following command is invoked, then $PKG_INSTALL_ROOT becomes /a during the installation of the package.


# pkgadd -R /a SUNWvxvm

$BASEDIR points to the relocatable base directory into which relocatable package objects are installed. Only relocatable objects are installed here. Nonrelocatable objects (those that have absolute paths in the pkgmap file) are always installed relative to the inactive boot environment, but not relative to the $BASEDIR in effect. If a package has no relocatable objects, then the package is said to be an absolute package (or nonrelocatable), and $BASEDIR is undefined and not available to package procedure scripts.

For example, suppose a package's pkgmap file has two entries:


1 f none sbin/ls 0555 root sys 3541 12322 1002918510
1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332

The pkginfo file has a specification for $BASEDIR:


BASEDIR=/opt

If this package is installed with the following command, then ls is installed in /a/opt/sbin/ls, but ls2 is installed as /a/sbin/ls2.


# pkgadd -R /a SUNWtest

Guidelines for Writing Scripts

Your package procedure scripts must be independent of the currently running OS to prevent modifying the OS. Procedure scripts define actions that occur at particular points during package installation and removal. Four procedure scripts can be created with these predefined names: preinstall, postinstall, preremove, and postremove.

Table B–2 Guidelines For Creating Scripts

Guidelines 

Affects Solaris Live Upgrade 

Affects non-global zones 

Scripts must be written in Bourne shell (/bin/sh). Bourne shell is the interpreter that is used by the pkgadd command to execute the procedure scripts.

Scripts must not start or stop any processes or depend on the output of commands such as ps or truss, which are operating system dependent and report information about the currently running system.

Scripts are free to use other standard UNIX commands such as expr, cp, and ls and other commands that facilitate shell scripting.

Any commands that a script invokes must be available in all supported releases, since a package must run on all of those releases. Therefore, you cannot use commands that were added or removed after the Solaris 8 release.  

To verify that a specific command or option is supported in a Solaris 8, 9, or 10 release, see the specific version of Solaris Reference Manual AnswerBook on http://docs.sun.com.

 

Maintaining Diskless Client Compatibility

Packages must not execute commands delivered by the package itself. This is to maintain diskless client compatibility and avoids running commands that might require shared libraries that are not installed yet.

Verifying Packages

All packages must pass pkgchk validation. After a package is created and before it is installed, it must be checked with the following command.


# pkgchk -d dir_name pkg_name
dir_name

Specifies the name of the directory where the package resides

pkg_name

Specifies the name of the package


Example B–1 Testing a Package

After a package is created, it must be tested by installing it in an alternate root (/) file system location by using the -R dir_name option to pkgadd. After the package is installed, it must be checked for correctness by using pkgchk, as in this example.


# pkgadd -d . -R /a SUNWvxvm
# pkgchk -R /a SUNWvxvm

No errors should be displayed.



Example B–2 Testing a Package on /export/SUNWvxvm

If a package exists at /export/SUNWvxvm, then you would issue the following command.


# pkgchk -d /export SUNWvxvm

No errors should be displayed.


Other commands can check the package when you are creating, modifying, and deleting files. The following commands are some examples.


# TEMPDIR=/a; export TEMPDIR
# truss -t open /usr/sbin/pkgadd -R ${TEMPDIR} SUNWvxvm \
2>&1 > /dev/null | grep -v O_RDONLY | grep -v \
'open("'${TEMPDIR}

Preventing User Interaction When Installing or Upgrading

Packages must be added or removed without the user being prompted for information when using the following standard Solaris utilities.

To test a package to ensure that it will install with no user interaction, a new administration file can be set up with the pkgadd command -a option. The -a option defines an installation administration file to be used in place of the default administration file. Using the default file might result in the user being prompted for more information. You can create an administration file that indicates to pkgadd that it should bypass these checks and install the package without user confirmation. For details, see the man page admin(4) or pkgadd(1M).

The following examples show how the pkgadd command uses the administration file.


Example B–3 Installation Administration File

The following is an example of an installation administration file that requires very little user interaction with the pkgadd utility. Unless the package requires more space than is available on the system, the pkgadd utility uses this file and installs the package without prompting the user for more information.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
space=ask
setuid=nocheck
confiict=nocheck
action=nocheck
basedir=default

Setting Package Parameters For Zones

Packages have parameters that control how their content is distributed and made visible on a system with non-global zones installed. The SUNW_PKG_ALLZONES, SUNW_PKG_HOLLOW, and SUNW_PKG_THISZONE package parameters define the characteristics of packages on a system with zones installed. These parameters must be set so that packages can be administered in a system with non-global zones.

The following table lists the four valid combinations for setting package parameters. If you choose setting combinations that are not listed in the following table, those settings are invalid and result in the package failing to install.


Note –

Ensure that you have set all three package parameters. You can leave all three package parameters blank. The package tools interpret a missing zone package parameter as if the setting were “false,” but not setting the parameters is strongly discouraged. By setting all three package parameters, you specify the exact behavior the package tools should exhibit when installing or removing the package.


Table B–3 Valid Package Parameter Settings For Zones

SUNW_PKG_ALLZONES Setting

SUNW_PKG_HOLLOW Setting

SUNW_PKG_THISZONE Setting

Package Description 

false 

false 

false 

This is the default setting for packages that do not specify values for all the zone package parameters. 

A package with these settings can be installed in either the global zone or a non-global zone.  

  • If the pkgadd command is run in the global zone, the package is installed in the global zone and in all non-global zones.

  • If the pkgadd command is run in a non-global zone, the package is installed in the non-global zone only.

In both cases, the entire contents of the package is visible in all zones where the package is installed. 

false 

false 

true 

A package with these settings can be installed in either the global zone or a non-global zone. If new non-global zones are created after the installation, the package is not propagated to these new non-global zones. 

  • If the pkgadd command is run in the global zone, the package is installed in the global zone only.

  • If the pkgadd command is run in a non-global zone, the package is installed in the non-global zone only.

In both cases, the entire contents of the package is visible in the zone where the package is installed. 

true 

false 

false 

A package with these settings can be installed in the global zone only. When the pkgadd command is run, the package is installed in the global zone and in all non-global zones. The entire contents of the package is visible in all zones.


Note –

Any attempt to install the package in a non-global zone fails.


true 

true 

false 

A package with these settings can only be installed in the global zone, by the global administrator. When the pkgadd command is run, the contents of the package is fully installed in the global zone. If a package has the package parameters set to these values, the package content itself is not delivered on any non-global zone. Only the package installation information necessary to make the package appear to be installed is installed on all non-global zones. This enables the installation of other packages to be installed that depend on this package. For more information on “hollow” packages, see Chapter 24, About Packages and Patches on a Solaris System With Zones Installed (Overview), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

For package dependency checking purposes, the package appears to be installed in all zones. 

  • In the global zone, the entire contents of the package is visible.

  • In whole root non-global zones, the entire contents of the package is not visible.

  • When a non-global zone inherits a file system from the global zone, a package installed in this file system is visible in a non-global zone. All other files delivered by the package are not visible within the non-global zone.

    For example, a sparse root non-global zone shares certain directories with the global zone. These directories are read-only. Sparse root non-global zones share the /platform file system among others. Another example is packages that deliver files relevant only to booting hardware.


Note –

Any attempt to install the package in a non-global zone fails.


Description 

For More Information 

For more details on packages and zones 

Chapter 24, About Packages and Patches on a Solaris System With Zones Installed (Overview), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones

For an overview of sparse and whole root zones 

Chapter 16, Introduction to Solaris Zones, in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones

For information about package characteristics and parameters 

pkginfo(4)

For information about displaying package parameter values 

pkgparam(1)

For Background Information

The following references provide background information about packaging requirements and specific command syntax.

For more specific information about packaging requirements and definitions of terminology 

Chapter 6, Advanced Techniques for Creating Packages, in Application Packaging Developer’s Guide

For basic information about adding and removing packages and the installation administration file 

Chapter 17, Managing Software (Overview), in System Administration Guide: Basic Administration

For detailed information about specific commands that are referenced in this appendix, see these man pages 

dircmp(1), fssnap(1M), ps(1), or truss(1) pkgadd(1M), pkgchk(1M), or pkgrm(1M)

For an overview of Solaris Live Upgrade 

Chapter 2, Solaris Live Upgrade (Overview)

For an overview of custom JumpStart 

Chapter 2, Custom JumpStart (Overview), in Solaris Express Installation Guide: Custom JumpStart and Advanced Installations

For an overview of Solaris Zones 

Chapter 16, Introduction to Solaris Zones, in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones