custom(ADM)

custom -- install, remove, or list software products and components

Command syntax

/etc/custom [ -h machine ]

/etc/custom [ -h machine ] -G all | index | last | summary

/etc/custom [ -h machine ] -p product -b | -d | -e | -l | -r |-t | -w
[ package ... ]

/etc/custom [ -h machine ] [ -p product ] -D | -E | -R [ package ]

/etc/custom [ -h machine ] [ -p product ] -D | -E | -R package

/etc/custom [ -h machine ] [ -p product ] [ -v type [ package ... ] ] [ -x ]

/etc/custom [ -h machine ] -V [ -x ]

The syntax above covers all the new features of custom, and should be used for all new custom products. However, custom also recognizes the following syntax, so that old-format custom command lines (for example, in existing programs or scripts) continue to work:

/etc/custom -a package ... [ -m device ]
/etc/custom -s prd -i [ package ... ] [ -m device ]
/etc/custom -s prd -l | -r [ package ... ]

Desktop syntax

Double-click on the Software Manager icon.

(The default location of the Software Manager icon is in the System Administration window.)

Description

With the custom utility, you can selectively install or remove portions of the UNIX system or other products, list the files of a product, and verify file permissions, ownership, size, and other details. You can manage the software on both local and remote machines.

You can use the standard custom command line to install single-volume products (such as drivers) from DOS-format floppies.

The custom utility presents SCO OpenServer products in the following hierarchy:

The product itself, composed of one or more parcels, packages, or components.
The components, each one a unit of software that cannot be split into smaller units for distribution. A component is organized into a hierarchical tree of packages.
The packages, each one a unit of software that can be installed or removed. A package can contain other packages, and each package is ultimately composed of files.

Each product and component has its own version number. A package inherits the version number of its parent component.

An example of a product is the SCO OpenServer (TM) Enterprise System, which consists of many components. One of these components is the TCP/IP runtime system, which in turn consists of packages such as the PPP runtime utilities, the TCP administration package, and several others.

SCO products may also contain parcels, which are groups of related packages pulled together from several different components. For example, the manual pages for all the components of the SCO OpenServer system might be gathered into a parcel called Online Man Pages.

Only root can run custom. custom runs either interactively or non-interactively.

Command options

This section describes the command line for the new custom format. For information on the old-format command line (retained for backwards compatibility), see the ``Old-format command options'' section in this manual page. Do not use the old command-line options in new programs or scripts.

Each command line in the new custom format must specify exactly one action using one of these options: -A, -b, -d, -D, -e, -E -G, -i, -l, -L, -r, -R, -t, -u, -v, -V, or -w.

You can specify packages (or whole components) with the -A, -d, -D, -e, -E, -i, -l, -L, -r, -R, -u, and -v options. Use spaces to separate package names (for example, SCO:Unix:BASE SCO:Unix:CSH). If you list package names, custom acts on just those packages. If you list component names, custom acts on all the packages in each component.

When you use -p product followed by an option without any packages, the specified action affects the entire product. When you list packages, the specified action affects the listed packages only.

Note that if you use -D, -E, or -R without -p product, a package or component must be specified.

custom accepts the following options:

-A [ package ... ]

apply a software patch to a product. The patch can come from distribution media or from a server. package must be the name of the patch, and -p product must name the product with which the patch is distributed, not the product to which the patch is applied.

-b [ package ... ]

export the listed packages.

-d [ package ... ]

disable part or all of a product. (Disabled software cannot be run locally, but is still available for networked installation.) Follow this option with a list of packages to disable part of a product. If you do not specify a package list, custom disables the entire product.

-D [ package ]

disable an applied software patch. (Disable rolls back a patch from the client-side configuration files, but not from the shared-side binary files.)

-e [ package ... ]

enable part or all of a loaded product. (Enabling completes the final phases of installation, so that the software can be used.) Follow this option with a list of packages to enable part of a product. If you do not specify a package list, custom enables the entire product.

-E [ package ]

enable an applied software patch. (Enable re-applies a patch to the client-side configuration files, after the patch has been disabled.)

-G all

display the details of all tasks in the custom logfile. custom logs a procedure each time you invoke one of these options: -A, -b, -d, -D, -e, -E, -i, -l, -L, -r, -R, -t, -u, -v, -V,-w.

-G index

display the details of a specific task in the custom logfile, where index is the index of the task, as shown in the summary.

-G last

display the details of the last (most recent) task in the custom logfile.

-G summary

list a summary of all tasks (such as installations and removals) in the custom logfile.

-i [ package ... ]

install or re-install part or all of a product. Follow this option with a list of packages to install part of a product. If you do not specify a package list, custom installs the entire product.

-l [ package ... ]

list some or all of the files in a product. Follow this option with a list of packages to list part of a product. If you do not specify a package list, custom lists the entire product.

-L [ package ... ]

install part or all of a product through the load phase only, making it available for enabling or fully installing on another machine across the network. (Loaded software is not configured for use.) Follow this option with a list of packages to load part of a product. If you do not specify a package list, custom loads the entire product.

If package is the name of a software patch, then -p product must name the product with which the patch is distributed, not the product to which the patch is applied.

-p product

specify the product or parcel on which custom acts. The product name consists of a vendor part and a product code part separated by a colon (for example, SCO:odtps). You can also specify multiple products for installation.

-r [ package ... ]

remove part or all of a product. Follow this option with a list of packages to remove part of a product. If you do not specify a package list, custom removes the entire product.

If package is the name of a loaded software patch, custom unloads that patch. In this case, -p product must name the product with which the patch is distributed, not the product to which the patch is applied.

-R [ package ]

roll back an applied software patch. (Rollback reverses the -A apply option, but does not unload a patch that is actually loaded on the system.) package must name the software component that contains the patch.

You can only roll back the most-recently applied patch. Run custom -R several times in succession to roll back more than one patch.

-t [ package ... ]

unexport the listed packages.

-u [ package ... ]

upgrade part or all of a currently installed product. Use this option without an argument to upgrade only the currently installed packages. Follow the option with a list of packages to install additional packages of the same product.

-v type [ package ... ]

verify system software, where type is quick, thorough, config, symlinks, or strict. Depending on the type specified, -v and -V check for broken or missing symbolic links, and incorrect file permissions, owner, group, and number of hard links. (To fix these discrepancies automatically, include the -x.) The verification can also check for missing files and for incorrect file type, checksum, and size. (These discrepancies cannot be fixed with the -x option -- these must be fixed manually after exiting custom.) You can use your backups or the customextract(ADM) utility to restore missing files.

quick: check for broken or missing symbolic links, incorrect file permissions, owner, group, and number of hard links. Does not report on size or checksum changes for configuration (non-shared) files, because these often change as part of normal operation. It does not verify checksums for shared files, nor does it remove a ``corrupt'' setting in the custom database.
thorough: verify the checksums for shared files in the selected packages, in addition to the checks made during the quick option. This option removes a ``corrupt'' setting from the custom database.
config: report checksum changes for configuration (non-shared) files, showing which configuration files have changed since installation. Also verifies permissions, owner, group, number of hard links, symbolic link target, export location, file type, and size for each configuration file in the selected packages.
symlinks: report symbolic links that should link a file from /opt or /var/opt to an external directory, but are broken or missing. A weekly cron job runs this option on the entire system and mails the report to root.
strict: report all discrepancies, including expected discrepancies such as changed configuration files and missing optional files. This option can take a long time.

-V

same as -v, except it verifies the entire product.

-x

fix file permissions, ownership, and other details.

Use -x with the -v and -V options.

-w [ package ... ]

change product or component database(s) to match how the files currently appear on the system. This is a very dangerous procedure.

Follow this option with a list of packages to change just the part of the database covering specific packages. If you do not specify a package list, custom changes the entire product or component database.

These options specify an installation source other than the default media device:

-F image_file ...: specify a list of image files to use in place of removable media. Use full pathnames for the image files.
You can use -F with the -i, -L, and -u options.
-m device: specify an installation media device other than the default device, /dev/rinstall. (/dev/rinstall is also called the 0 device, as in /dev/fd0.) The device argument must be a valid block or character device name.
You can use -m with the -i, -L, and -u options.
-z image_directory: specify a directory of image files to use in place of removable media. Use the directory's full pathname.
You can use -z with the -i, -L, and -u options.

These options let you manage software on another machine or install software from another machine:

-h machine: execute custom on the specified machine (or ``host''), for networked software management.
-N machine: specify a machine on the network serving as the source of the software to be installed. The software can be installed or loaded on the named machine or can reside on removable media or in image files on the named machine.
You must supply a password when prompted.

These options are used by the Installation Query Manager (IQM):

-g: display the (post-IQM) progress messages of the initial system load in graphical mode.
-n: prevent custom from prompting the user to insert media.
-Q: specify that custom is being executed from the IQM.

Desktop options

Entering:

custom [ -h machine ]

without any other options or arguments runs a completely interactive custom session. The -h option executes the session on the specified machine.

The custom Software Manager window appears with a list of the software products currently installed on your local host. Each line gives the product name and release number, a symbol indicating the installation state of the product, and a symbol indicating whether you can view the packages of the product.

From this window, you can:

Access a remote system (from the Host menu)
Exit custom (from the Host menu)
Run the installation task (from the Software menu)
The installation procedure takes you through several windows, which prompt you to name the type of media (or the source machine) you are installing from, choose a full or partial installation, and (if choosing a partial installation) select the packages to install.
Remove products or packages (from the Software menu)
After you select the packages for removal from the Software Manager window, additional windows prompt you to confirm the removal and remind you of any dependencies.
Verify (and optionally fix) file permissions, ownership, and other details (from the Software menu)
The verify procedure prepares a report of any discrepancies found between the files on the system and the corresponding product or component database. The procedure then offers any or all of the following choices: print the report, save the report to a file, and correct discrepancies.
Examine the files, dependencies, applied patches, PRD value, version number, size, and installation state of products or packages (from the Software menu)
Load software (from the Software menu, under Advanced Options)
The load procedure resembles the installation procedure, but the software is only copied from the media, and is not configured for use.
Update a product or component database (from the Software menu, under Advanced Options)
This is a very dangerous procedure.
Apply, roll back, load, unload, or view patches on installed software (from the Software menu)
View the components and packages in a product (by double-clicking on a list item, or from the View menu)

Old-format command options

The information in this section should only be used to administer programs or scripts that were written under an old version of custom.

Each old custom command line must specify a set and an action (unless it uses the -a action option, which does not require a set).

The set determines which component custom acts on. The set option is:

-s prd: specify the prd value (short product code) of the product you want custom to act on.

Include only one action option on each command line. For action options that accept a package list, list the package names as they appear on the package definition lines (marked by #@) in the component perms list (for example, BASE CSH). Separate the package names with spaces.

The action options are:

-a package ...: install part or all of a new product. -a does not require an accompanying set specifier, but you must specify a package list following the option. To install the entire new product, specify the ALL package.
-i [ package ... ]: install or re-install part or all of a set. Follow this option with a list of packages to install part of a set. If you do not specify a package list, custom installs the entire set.
-l [ package ... ]: list some or all of the files in a set. Follow this option with a list of packages to list part of a set. If you do not specify a package list, custom lists the entire set.
-r [ package ... ]: remove part or all of a set. Follow this option with a list of packages to remove part of a set. If you do not specify a package list, custom removes the entire set.

You can also specify an alternative media device:

-m device: specify an installation media device other than the default device, /dev/rinstall. (/dev/rinstall is also called the 0 device, as in /dev/fd0.) The device argument must be a valid block or character device name.
You can use -m with the -i and -a options.

Examples

To install the CORE and XDEV packages of the UNIX Development System component (unixds) of the Open Desktop Development System product (ods), enter:

custom -p SCO:ods -i SCO:unixds:CORE SCO:unixds:XDEV

To upgrade the previously installed packages of the ods product, using the /dev/rinstall1 drive, enter:

custom -p SCO:ods -u -m /dev/rinstall1

To install the entire ods product from the remote machine mcgee, enter:

custom -N mcgee -p SCO:ods -i

To install the entire ods product from the image directory /u/user1/ods/archives/TAPE, enter:

custom -p SCO:ods -i -z /u/user1/ods/archives/TAPE

To install the entire ods product from a list of image files, enter:

custom -p SCO:ods -i -F /u/user1/product1/file1 /u/user1/product1/file2

To remove the CORE and XDEV packages of the unixds component of the ods product, enter:

custom -p SCO:ods -r SCO:unixds:CORE SCO:unixds:XDEV

Examples in the old format

To install the CORE and XDEV packages of the Development System component (unixds) of the Open Desktop Development System product (odtds), enter:

custom -s unixds -i CORE XDEV

To install the TCPSRC package of whatever new product is in the /dev/rinstall1 drive, enter:

custom -a TCPSRC -m /dev/rinstall1

Warning

The product database and component databases define what files exist in a product, where they reside, what their permissions are, and everything else that determines the product's behavior. Therefore, if you change a product or component database with the -w option (or the Update database graphical option), you change the product itself. You no longer have the same product you installed, and the only way to return to the original product is to reinstall.

Limitations

custom does not let you manipulate individual files. If, for example, a file becomes damaged or destroyed, you must use customextract(ADM) to install individual files. When using custom on the console to install a new package, if you select CD-ROM for the media without a CD in the CD-ROM driver, an error message prints on top of the screen, garbling the custom display. You should be able to correct this problem by forcing the screen to redraw with <Ctrl>R.

Files

/var/opt/K/SCO/SoftMgr/*/custom/custom.log: custom log file

History

The main changes to custom (new command line options, new syntax, and a new graphical interface) are detailed in the ``Description'' and ``Options'' sections of this manual page. Read those sections carefully.

Some of the specific changes to watch for include:

custom now accepts single-volume products (such as drivers) on DOS-format floppies.
custom no longer uses ``Services'' or ``Service Components.''
The command line for old-format custom no longer includes these options: -d (specifying the Development System set), -o (specifying the Operating System set), -b (enforcing dependencies specified in bundled products), or -v (specifying verbose output).

Standards conformance

custom is conformant with Intel386 Binary Compatibility Specification, Edition 2 (iBCSe2); it is an extension to AT&T System V developed by The Santa Cruz Operation, Inc.