Advanced Packaging Topics

The topics discussed in this section are for those who have a firm understanding of the SD packaging process and who want to have more control over it. Included are:

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:

You can see the depot in the swinstall / swcopy GUI and see it in swlist depot-level listings.
You can read products from the depot (for example, to install).

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 9 “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 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 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:

Can you create a new depot?
Status Permission
Superuser
Yes
Non-superuser
Yes, if the ACL for the local host grants the user "insert" permission, i.e. permission to insert a new depot into the host.
If the proper permissions are not in place and the depot is a new one, swpackage terminates with an error.
Can you create a new product?
Status Permission
Superuser
Yes
Non-superuser
Yes, if the depot is new and you passed check #1 above or if the ACL for an existing depot grants you insert permission, i.e. permission to change the contents of the depot (by adding a new product).
If you are denied authorization to create a new product, swpackage generates an error message and excludes the product from the session.
Can you modify an existing product?
Status Permission
Superuser
Yes
Non-superuser
Yes, if the ACL for the existing product grants you write permission, i.e. permission to overwrite/change the contents of the product. If you are denied authorization to change an existing product, swpackage generates an error message and excludes the product from the session.
If you are denied insert and write permission for all selected products, swpackage terminates with an error.
Can you change the depot-level attributes?
Status Permission
Superuser
Yes
Non-superuser
Yes, if the depot is a new one and you passed check #1 above or if the ACL for an existing depot grants you write permission, i.e. permission to write/change the contents of the depot (same as #2 above).
If you are denied authorization to change an existing depot, and if the PSF specifies some depot-level attributes, then swpackage produces a warning message and does not change the depot attributes.

ACL Creation

When swpackage creates a new depot or a new product, it also creates an ACL for it:

Object ACL

New depot

swpackage creates an ACL for the depot and a template ACL for all the products that will be packaged into it.

The depot ACL is generated from the host's global_soc_template ACL (that is, the template ACL established for new depots and new root file systems).

The depot's product_template ACL is generated from the host's global_product_template ACL (that is, the host's template ACL for new products).

The user running swpackage is established as the owner of the new depot and is granted permissions as defined in the depot ACL (which come from the global_soc_template).

New product

swpackage creates an ACL for the product; the ACL is generated from the depot's product_template ACL.

ACL creation can be disabled with the command:

-x create_target_acls=false

When no ACL exists for a depot, only the superuser can create new products or add/modify depot attributes. When no ACL exists for a product, only the superuser can modify it.

Repackaging or Modifying a Software Package




	NOTE: For more information on repackaging, refer to the details on modifying an existing product found in “Repackaging or Modifying a Software Package ”.

There are two types of repackaging:

Adding to or modifying a fileset in an existing product.
- Editing the PSF by adding a new fileset definition or changing an existing fileset's definition.
- Running swpackage on the edited PSF, specifying the new/changed fileset on the command line:
  swpackage -s psf <other options> product.fileset @ depot
  This invocation works regardless of whether subproducts are defined in the product.
- If you change a fileset by changing its tag attribute, swpackage cannot correlate the existing, obsolete fileset with the new fileset. Both become part of the changed product. To get rid of the obsolete (renamed) fileset, use swremove:
  swremove -d product.old_fileset @ depot
Modifying an entire existing product.
- Editing the PSF by adding new fileset definitions, changing existing fileset definitions, deleting existing fileset definitions or changing the product's definition (product-level attributes).
- Running swpackage on the PSF, specifying the product on the command line:
  swpackage -s psf <other options> product @ depot
- If you have deleted some fileset definitions in the PSF or modified a fileset by changing it's tag attribute, swpackage will produce warning messages about the existing filesets that are not part of the modified product's definition (in the PSF). The existing filesets plus the new filesets in the product's definition (in the PSF) will all be contained in the modified product.
  The warnings are produced during analysis phase, and are only produced when the whole product is being repackaged (as opposed to subsets of the product).
- To get rid of the obsolete (renamed) filesets, use swremove:
  swremove -d product.old_fileset @ depot
- You may want to swremove the product entirely before repackaging the changes:
  swremove -d product @ depot
  swpackage -s psf <other options> product @ depot

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, 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 systems 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:

Response Meaning

Return: Use the same device.
pathname: Use the new device/file "pathname".
quit: Terminate the write-to-tape operation.

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:

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 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:

it may result in too-restrictive permissions on the CD-ROM depot.
you could have too many user-specific ACLs on the CD-ROM.

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, 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 specify the option -x write_remote_files=true, 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:

Set the write_remote_files option to true and
Make sure the superuser can write to the NFS file system to package a depot on an NFS-mounted file system.

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

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 8 “Managing Patches”