Advanced Packaging Topics

Changing Options in the Defaults File

You can change several swpackage behaviors and policy options by editing option values found in the SD defaults file or by specifying them on the command line with the -x option.

The SD defaults file ($HOME/.sw/defaults or /var/adm/sw/defaults) contains the values for all the options (behaviors), defaults and operands (target hosts and software selections) you have chosen to modify. These values can be added to, changed, or overwritten from the command-line.

The options and defaults are described in Appendix A “Default Options and Keywords ”.

Registering Depots Created by swpackage

When a new depot is created by swpackage, it is NOT automatically registered with the local host's swagentd daemon.

To verify that the depot is registered, type:

swlist -l depot [@ host:depot]

To register the depot, you must execute the swreg command:

swreg  -l depot depot_to_register

Registering a depot makes it generally available as a source for swinstall and swcopy tasks.

In general, a depot that is not registered can be used as a source depot only by the superuser or the local user who created the depot. The depot is also not available for remote operations (for example, SPA or "pull"). This SD restriction prevents someone from creating a "Trojan Horse" depot with a process other than swpackage. If this depot was then used as the source for a swinstall operation, it would cause the "Trojan Horse" to be installed on every target system and potentially activated.

Registration provides a type of "public recognition" for the packaged depot:

If the only uses of a depot created with swpackage are local accesses by the packaging user, depot registration is not required.

Packaging Security

SD provides Access Control Lists (ACLs) to authorize who has permission to perform specific operations on depots. Because the swpackage command creates and modifies local depots only, the SD security provisions for remote operations do not apply to swpackage. See Chapter 8 “Controlling Access to Software Objects” for more information on ACLs.

The swpackage command is setuid root, that is, the Package Selection phase operates as the invoking user, the Analysis and Packaging phases operate as the superuser. The superuser owns and manages depots and therefore has all permissions for all operations on a depot. (If the depot happens to be on an NFS volume, access problems will not arise from SD ACLs, but will arise if the local superuser does not have NFS root access on the NFS mounted file system.)

If you are not the local superuser, you will not have permission to create or modify a depot unless the local superuser grants you permission.

swpackage checks and enforces the following permissions:

Repackaging or Modifying a Software Package

	NOTE: For more information on repackaging, refer to the details on modifying an existing product found in an earlier section of this chapter.

There are two types of repackaging:

Packaging In Place

If you specify the option -x package_in_place=true, swpackage will package each of the specified products such that the source files are not copied into the target depot. Instead, swpackage inserts references to the source files that make up the contents of each fileset. Control scripts are always copied.

This feature lets you package products in a development or test environment without consuming the full disk space of copying all the source files into the target depot. Disk space analysis is skipped when the package_in_place option is true.

The source files must remain in existence — if some are deleted, then any operations that use the depot as a source (for example, installing the product with swinstall) will fail when they try to access the missing source file(s).

If a source file changes and the product is not repackaged, the information that describes the source file will be incorrect (for example, the file checksum). This incorrect information will not prevent the use of that target depot as a source (for example, installing with swinstall). However, the incorrect information will be propagated along each time the product is copied or installed from the depot. The result will be that a swverify of the installed product will always flag the inconsistencies with an ERROR (unless you disable the check of file contents).

Following Symbolic Links in the Source

If you specify the option -x follow_symlinks=true, swpackage will follow every source file that is a symbolic link and include the file it points to in the packaged fileset.

swpackage will also follow each source directory that is a symbolic link — which will affect the behavior of the file * keyword (recursive file specification). Instead of including just the symbolic link in the packaged fileset, the directory it points to and all files contained below it will be included in the packaged fileset.

The default value for this option is false, which causes symbolic links that are encountered in the source to be packaged as symbolic links. The symbolic link can point to a file that is also part of the fileset, or to a file that is not.

Generating File Revisions

If you specify the option -x include_file_revisions=true, swpackage will examine each source file using the what and ident commands to extract an SCCS or RCS revision value and assign it as the file's revision attribute.

Because a file can have multiple revision strings embedded within it, swpackage uses the first one returned. It extracts the revision value from the full revision string and stores it.

This option is time consuming, especially when a what search fails and the ident command is then executed.

The default value for this option is false, which causes swpackage to skip the examination. No value for the revision attribute is assigned to the files being packaged.

Overriding Disk Space Analysis Errors

The swpackage command performs a Disk Space Analysis (DSA) during the analysis phase. If the file system(s) that contain the target depot do not have enough free space to store the products being packaged, swpackage will print an error message and then terminate the session. It checks both the absolute free space threshold, and the minimum free threshold (minfree). Crossing either threshold will generate the error condition.

If you specify the option -x enforce_dsa=false, swpackage will change the error to a warning and continue. This flexibility lets you cross into the minfree space to complete a packaging operation.

Writing to Multiple Tapes

When you package products to a distribution tape, the media_capacity option defines the size of the tape media (in one million byte units). The default value for this option is media_capacity=1330, which is the size of an HP DDS tape. If the target tape is not a DDS tape, you must specify the media_capacity value.

	NOTE: The capacity of the DDS tape is in one million byte units (1,000,000 bytes), NOT Mbyte units (1,048,576 bytes). Most tape drive manufacturers specify capacity in one-million byte units.

If the products being packaged require more space than the specified media capacity, swpackage will partition the products across multiple tapes.

To find out if multiple tapes will be required, swpackage will calculate the tape blocks required to store the depot catalog and each product's contents.

When multiple tapes are necessary, swpackage will write the entire catalog on to the first tape plus any product contents that will also fit. For each subsequent tape, swpackage will prompt you for a "tape is ready" response before continuing.

To continue with the next tape, enter one of the following responses:

Partitioning is done at the fileset level, so a given product can span multiple tapes. A single fileset's contents cannot span multiple tapes. If any single fileset has a size that exceeds the media capacity, swpackage generates an error and terminates. It also generates an error if the catalog will not fit on the first tape.

Making Tapes from an Existing Depot

You can copy one or more products from an existing depot to a tape using swpackage. Instead of specifying a Product Specification File as the source for a packaging session, just specify an existing depot. For example:

swpackage -s /var/spool/sw  ...

To copy all of the products in a depot to a tape:

swpackage -s depot -d tape -x target_type=tape

To copy only some of the products in a depot to a tape, specify the products as software selections:

swpackage -s depot -d tape -x target_type=tape  product
product ...

You can also use the -f file option can be used to specify several software selections instead of listing them on the command line.

When products are copied from a depot to a tape, the ACLs within the depot are NOT copied. (The swpackage command never creates ACLs when software is packaged onto a tape.)

swpackage cannot compress files when writing to a tape.

Creating a Depot and Mastering It to CD-ROM

When swpackage creates a new depot or packages a new product, it always creates an ACL for the depot/product. If you were to to create a depot and then master it onto a CD-ROM, the CD-ROM would contain all those ACLs which could cause the following problems:

To solve these problems, you can tell swpackage to NOT create ACLs in the depot by setting the create_target_acls option to false.

This feature is provided only for the superuser because only the local superuser can change, delete, or add ACLs to a depot that has no ACLs. The local superuser always has all permissions.

The -x create_target_acls=false option causes swpackage to skip the creation of ACLs for each new product being packaged (and for the depot, if it is new). This option has no impact on the ACLs that already exist in the depot.

When a depot is used as a source for other SD operations, its ACLs (or lack thereof) have no bearing on the ACLs created for the targets of the operation. Source ACLs are not related to target ACLs.

The swpackage command never creates ACLs when software is packaged onto a tape.

Depots on Remote File Systems

Because the swpackage analysis and build phases operate as the superuser, there are constraints on how swpackage creates, adds to, or modifies products on a depot that exists in an NFS-mounted file system.

If the superuser DOES NOT have write permission on the remote file system, then swpackage will be unable to create a new depot - it will terminate before the analysis phase begins.

If the superuser DOES have write permission on the remote file system but the option write_remote_files is false, then swpackage will be unable to create a new depot - it will terminate before the analysis phase begins.

If the superuser DOES have write permission on the remote file system and you specify the option -x write_remote_files=true, then swpackage will create the new depot and package products into it.

The constraints for an existing NFS mounted depot are the same as when creating a new depot.

So, you must:

When these constraints are satisfied, the SD ACL protection mechanism will control operations on NFS mounted depots the same way it controls operations on local depots.