Packaging Tasks and Examples

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 @ MyDepot

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.

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

For more information about registering depots, see “Registering and Unregistering Depots (swreg) ”.

	NOTE: If the only use of a depot created with swpackage is local access by the packaging user, depot registration is not required.

Creating and Mastering a CD-ROM Depot

When swpackage creates a new depot or packages a new product, it always creates an ACL for the depot/product. If you were 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.

Setting the create_target_acls to false 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-UX operations, its ACLs (or lack of ACLs) 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.

Compressing Files to Increase Performance

The packaging process may pass large amounts of data back and forth over the network and might slow down network performance. The compress_files option can improve performance by first compressing files that are to be transferred. This performance gained depends on the type of files transferred. Binary files compress less than 50%, text files generally compress more. Improvements are best when transfers are across a slow network (approximately 50Kbytes/second or less).

If set to true, compress_files compresses files (if they have not been compressed previously by SD-UX) before transfer from a source. You may also specify a compression type with the compression_type option or specify a compression command with the compression_command option.

This option should be set to true only when network bandwidth is clearly restricting total throughput. If it is not clear that this option will help, compare packaging operations both with and without compression before consistently using this option. See Appendix A for more information on using command options.

	NOTE: swpackage cannot compress files when writing to a tape.

Packaging Security

SD-UX 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-UX security provisions for remote operations do not apply to swpackage. See Chapter 9: “SD-UX Security ” for more information on ACLs.

The swpackage command operates as 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 all 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 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

There are two types of repackaging:

Packaging In Place

If you set the package_in_place option to true, swpackage packages 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, 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 files.

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 is that a swverify operation on the installed product always flags the inconsistencies with an error unless you disable the check of file contents.

Following Symbolic Links in the Source

If you set the follow_symlinks option to true, swpackage follows every source file that is a symbolic link and include the file it points to in the packaged fileset.

swpackage also follows each source directory that is a symbolic link, which affects 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 set the include_file_revisions option to true, swpackage examines 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.

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, 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, 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 set the write_remote_files to true, swpackage creates 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 ACL protection mechanism controls operations on NFS mounted depots the same way it controls operations on local depots.

Verifying the Software Package

If swpackage created a depot rather than storing the package in an existing registered depot, you must register the depot with the swreg command. (See “Registering Depots Created by swpackage ”.)

After the depot is registered, you can verify it with the swverify command. For example, to verify the integrity of the product Pascal in the local default depot:

swverify -d Pascal

For more information about verifying depots, see “Verifying a Depot (swverify -d) ”.

You can also test the package by installing it on a system. For example, to install the package named Pascal, located on the default depot /var/spool/sw in the host svrhost, onto the primary root of a host named myhost:

swinstall -s svrhost Pascal @ myhost

(This example does not specify the depot location because it is assumed that the software is located in the default /var/spool/sw on svrhost.)

For more information about verifying installed software, see “Verifying Your Installation (swverify)”

Packaging Patch Software

A number of software attributes are available to all software levels (bundles, products, subproducts, and filesets) that permit packaging of patch software. For complete information on patch attributes and a sample PSF, see Chapter 5: “HP-UX Patching and Patch Management”.

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 writes the entire catalog onto the first tape plus any product contents that also fit. For each subsequent tape, swpackage prompts 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 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 PSF as the source for a packaging session, just specify an existing depot. For example:

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:

You can also use the -f file option 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.