swask(1M)

NAME

swask — ask for user response

SYNOPSIS

swask [-v] [-c catalog] [-C session_file] [-f software_file] [-J jobid] [-Q date] [-s source] [-S session_file] [-t target_file] [-x option=value] [-X options_file] [software_selections] [@ target_selections]

Remarks

This command supports operation on remote systems. See Remote Operation below.
For an overview of all SD commands, see the sd(5) man page by typing man 5 sd on the command line.

DESCRIPTION

The swask command runs interactive software request scripts for the software objects selected to one or more targets specified by target_selections. These scripts store the responses in a response file (named response) for later use by the swinstall and swconfig commands. The swinstall and swconfig commands can also run the interactive request scripts directly, using the ask option.

If the -s option is specified, software is selected from the distribution source. If the -s option is not specified, software installed on the target systems is selected. For each selected software that has a request script, executing that script generates a response file. By specifying the -c catalog option, swask stores a copy of the response file to that catalog for later use by swinstall or swconfig.

Remote Operation

You can enable SD to manage software on remote systems. To let the root user from a central SD controller (also called the central management server or IR "manager node" ) perform operations on a remote target (also called the host or agent):

1)

Set up the root, host, and template Access Control Lists (ACLs) on the remote machines to permit root access from the controller system. To do this, run the following command on each remote system:

/usr/lib/sw/mx/setaccess controller

NOTES:

controller is the name of the central management server.
If remote system is 11.00, make sure SD patch PHCO_22526 or a superseding patch is installed on remote system before running setaccess.
If remote system is older than 11.00 or for some other reason does not have setaccess in place, copy setaccess script from an 11.11 or higher system to the remote system.

2)

swinstall, swcopy, and swremove have enhanced GUI interfaces for remote operations. Enable the enhanced GUIs by creating the .sdkey file on the controller. Use this command:

touch /var/adm/sw/.sdkey

See sd(5), swinstall(1M), swcopy(1M), swjob(1M), swlist(1M), or swremove(1M) for more information on interactive operations.

NOTE: You can also set up remote access by using swacl directly on the remote machines to grant root or non-root access to users from the controller system.

Options

The swask command supports the following options:

-v

Turns on verbose output to stdout.

-c catalog

Specifies the pathname of an exported catalog which stores the response files created by the request script. swask creates the catalog if it does not already exist.

If the -c catalog option is omitted and the source is local, swask copies the response files into the source depot, <distribution.path>/ catalog.

-C session_file

Saves the current options and operands to session_file. You can enter a relative or absolute path with the file name. The default directory for session files is $HOME/.sw/sessions/. You can recall a session file with the -S option.

-f software_file

Reads the list of software_selections from software_file instead of (or in addition to) the command line.

-s source

Specifies the source depot (or tape) from which software is selected for the ask operation. (SD can read both tar and cpio tape depots.)

-S session_file

Executes swask based on the options and operands saved from a previous session, as defined in session_file. You can save session information from a command-line session with the -C session_file option.

-t targetfile

Specifies a default set of targets for swask.

-x option=value

Sets the session option to value and overrides the default value (or a value in an alternate option_file specified with the -X option). Multiple -x options can be specified.

-X option_file

Reads the session options and behaviors from option_file.

Operands

swask supports two types of operands: software selections followed by target selections. These operands are separated by the "at" (@) character. This syntax implies that the command operates on "software selections at targets".

Software Selections

The selections operands consist of software_selections.

swask supports the following syntax for each software_selection:

bundle[.product[.subproduct][.fileset]][,version] 

product[.subproduct][.fileset][,version] 

The = (equals) relational operator lets you specify selections with the following shell wildcard and pattern-matching notations:
- [ ], *, ?
Bundles and subproducts are recursive. Bundles can contain other bundles and subproducts can contain other subproducts.
The \* software specification selects all products. Use this specification with caution.

The version component has the form:

[,r <op> revision][,a <op> arch][,v <op> vendor] 
[,c <op> category][,q=qualifier][,l=location] 
[,fr <op> revision][,fa <op> arch] 

location applies only to installed software and refers to software installed to a location other than the default product directory.
fr and fa apply only to filesets.
r , a , v , c , and l apply only to bundles and products. They are applied to the leftmost bundle or product in a software specification.
The <op> (relational operator) component can be of the form:
- =, ==, >=, <=, <, >, or !=
which performs individual comparisons on dot-separated fields. For example, r>=B.10.00 chooses all revisions greater than or equal to B.10.00. The system compares each dot-separated field to find matches.
The = (equals) relational operator lets you specify selections with the shell wildcard and pattern-matching notations:
- [ ], *, ?, !
For example, the expression r=1[01].* returns any revision in version 10 or version 11.
All version components are repeatable within a single specification (e.g. r>=AA.12, r<AA.20). If multiple components are used, the selection must match all components.
Fully qualified software specs include the r=, a=, and v= version components even if they contain empty strings. For installed software, l=, is also included.
No space or tab characters are allowed in a software selection.
The software instance_id can take the place of the version component. It has the form:
- [instance_id]
within the context of an exported catalog, where instance_id is an integer that distinguishes versions of products and bundles with the same tag.

Target Selections

swask supports the following syntax for each target_selection.

[host][:][/directory]

The colon (:) is required if both a host and directory are specified.

EXTERNAL INFLUENCES

Default Options

In addition to the standard options, several SD behaviors and policy options can be changed by editing the default values found in:

/var/adm/sw/defaults: the system-wide default values.
$HOME/.swdefaults: the user-specific default values.

Values must be specified in the defaults file using this syntax:

[command_name.]option=value 

The optional command_name prefix denotes one of the SD commands. Using the prefix limits the change in the default value to that command. If you leave the prefix off, the change applies to all commands.

You can also override default values from the command line with the -x or -X options:

command -x option=value

command -X option_file

The following section lists all of the keywords supported by the swask commands. If a default value exists, it is listed after the "=".

admin_directory=/var/adm/sw (for normal mode)

admin_directory=/var/home/LOGNAME/sw (for nonprivileged mode)

The location for SD logfiles and the default parent directory for the installed software catalog. The default value is /var/adm/sw for normal SD operations. When SD operates in nonprivileged mode (that is, when the run_as_superuser default option is set to true):

The default value is forced to /var/home/LOGNAME/sw.
The path element LOGNAME is replaced with the name of the invoking user, which SD reads from the system password file.
If you set the value of this option to HOME/path, SD replaces HOME with the invoking user's home directory (from the system password file) and resolves path relative to that directory. For example, HOME/my_admin resolves to the my_admin directory in your home directory.
If you set the value of the installed_software_catalog default option to a relative path, that path is resolved relative to the value of this option.

SD's nonprivileged mode is intended only for managing applications that are specially designed and packaged. This mode cannot be used to manage the HP-UX operating system or patches to it. For a full explanation of nonprivileged SD, see the Software Distributor Administration Guide, available at the http://docs.hp.com web site.

See also the installed_software_catalog and run_as_superuser options.

ask=true

Executes the request script, if one is associated with the selected software, and stores the user response in a file named response.

If ask=as_needed, the swask command first determines if a response file already exists in the catalog and executes the request script only when a response file is absent.

autoselect_dependencies=true

Controls the automatic selection of prerequisite and corequisite software that is not explicitly selected by the user. When set to true, requisite software will be automatically selected for configuration. When set to false, requisite software which is not explicitly selected will not be automatically selected for configuration.

autoselect_patches=true

Automatically selects the latest patches (based on superseding and ancestor attributes) for a software object that a user selects. The patch_filter option can be used in conjunction with autoselect_patches to limit which patches will be selected. Requires patches that are in an enhanced SD format. Patches not in enhanced format will not respond to autoselect_patches.

enforce_scripts=true

Controls the handling of errors generated by scripts. If true, swask stops and an error message appears. The message gives the script location and says execution cannot proceed until the problem is fixed. If false, all script errors are treated as warnings, and swask attempts to continue operation. A message appears giving the script location and saying that execution will proceed.

installed_software_catalog=products

Defines the directory path where the Installed Products Database (IPD) is stored. This information describes installed software. When set to an absolute path, this option defines the location of the IPD. When this option contains a relative path, the SD controller appends the value to the value specified by the admin_directory option to determine the path to the IPD. For alternate roots, this path is resolved relative to the location of the alternate root. This option does not affect where software is installed, only the IPD location.

This option permits the simultaneous installation and removal of multiple software applications by multiple users or multiple processes, with each application or group of applications using a different IPD.

Caution: use a specific installed_software_catalog to manage a specific application. SD does not support multiple descriptions of the same application in multiple IPDs.

See also the admin_directory and run_as_superuser options, which control SD's nonprivileged mode. (This mode is intended only for managing applications that are specially designed and packaged. This mode cannot be used to manage the HP-UX operating system or patches to it. For a full explanation of nonprivileged SD, see the Software Distributor Administration Guide, available at the http://docs.hp.com web site.)

log_msgid=0

Controls the log level for the events logged to the command log file, the target agent log file, and the source agent log file by prepending identification numbers to log file messages:

0: No such identifiers are prepended (default).
1: Applies to ERROR messages only.
2: Applies to ERROR and WARNING messages.
3: Applies to ERROR, WARNING, and NOTE messages.
4: Applies to ERROR, WARNING, NOTE, and certain other log file messages.

logdetail=false

Controls the amount of detail written to the logfile. When set to true, this option adds detailed task information (such as options specified, progress statements, and additional summary information) to the logfile. This information is in addition to log information controlled by the loglevel option.

See loglevel below and the sd(5) manual page, by typing man 5 sd, for more information.

logfile=/var/adm/sw/swask.log

Defines the default log file for swask.

loglevel=1

Controls the log level for the events logged to the command logfile and the target agent logfile. A value of

0: provides no information to the logfile.
1: enables verbose logging of key events to the log files.
2: enables very verbose logging, including per-file messages, to the log files.

patch_filter=*.*

Used in conjunction with the autoselect_patches or patch_match_target options to filter the available patches to meet the criteria specified by the filter. A key use is to allow filtering by the "category" attribute. Requires patches that are in an enhanced SD patch format.

run_as_superuser=true

This option controls SD's nonprivileged mode. This option is ignored (treated as true) when the invoking user is super-user.

When set to the default value of true, SD operations are performed normally, with permissions for operations either granted to a local super-user or set by SD ACLs. (See swacl(1M) for details on ACLs.)

When set to false and the invoking user is local and is not super-user, nonprivileged mode is invoked:

Permissions for operations are based on the user's file system permissions.
SD ACLs are ignored.
Files created by SD have the uid and gid of the invoking user, and the mode of created files is set according to the invoking user's umask.

See also the admin_directory and installed_software_catalog options.

verbose=1

Controls the verbosity of the output (stdout):

0: disables output to stdout. (Error and warning messages are always written to stderr).
1: enables verbose messaging to stdout.

Session Files

Each invocation of swask defines a task session. The invocation options, source information, software selections, and target hosts are saved before the task actually commences. This lets you re-execute the command even if the session ends before proper completion.

Each session is saved to the file $HOME/.sw/sessions/swask.last. This file is overwritten by each invocation of swask.

To save session information in a different location, execute swask with the -C session__file option.

A session file uses the same syntax as the defaults files. You can specify an absolute path for a session file. If you do not specify a directory, the default location for a session file is $HOME/.sw/sessions/.

To re-execute a session, specify the session file as the argument for the -S session__file option.

When you re-execute a session file, the values in the session file take precedence over values in the system defaults file. Likewise, any command line options or parameters that you specify when you invoke swask take precedence over the values in the session file.

Software and Target Lists

You can use files containing software and target selections as input to the swask command. See the -f and -t options for more information.

Environment Variables

The environment variables that affect the swask command are:

LANG

Determines the language in which messages are displayed. If LANG is not specified or is set to the empty string, a default value of C is used. See lang(5) for more information.

NOTE: The language in which the SD agent and daemon log messages are displayed is set by the system configuration variable script, /etc/rc.config.d/LANG. For example, /etc/rc.config.d/LANG, must be set to LANG=ja_JP.SJIS or LANG=ja_JP.eucJP to make the agent and daemon log messages display in Japanese.

LC_ALL

Determines the locale to be used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

LC_CTYPE

Determines the interpretation of sequences of bytes of text data as characters (e.g., single-versus multibyte characters in values for vendor-defined attributes).

LC_MESSAGES

Determines the language in which messages should be written.

LC_TIME

Determines the format of dates (create_date and mod_date) when displayed by swlist. Used by all utilities when displaying dates and times in stdout, stderr, and logging.

TZ

Determines the time zone for use when displaying dates and times.

Environment variables that affect scripts:

SW_CATALOG: Holds the path to the Installed Products Database (IPD), relative to the path in the SW_ROOT_DIRECTORY environment variable. Note that you can specify a path for the IPD using the installed_software_catalog default option.
SW_CONTROL_DIRECTORY: Defines the current directory of the script being executed, either a temporary catalog directory, or a directory within in the Installed Products Database (IPD). This variable tells scripts where other control scripts for the software are located (e.g. subscripts).
SW_CONTROL_TAG: Holds the tag name of the control_file being executed. When packaging software, you can define a physical name and path for a control file in a depot. This lets you define the control_file with a name other than its tag and lets you use multiple control file definitions to point to the same file. A control_file can query the SW_CONTROL_TAG variable to determine which tag is being executed.
SW_LOCATION: Defines the location of the product, which may have been changed from the default product directory. When combined with the SW_ROOT_DIRECTORY, this variable tells scripts where the product files are located.
SW_PATH: A PATH variable which defines a minimum set of commands available for use in a control script (e.g. /sbin:/usr/bin).
SW_ROOT_DIRECTORY: Defines the root directory in which the session is operating, either "/" or an alternate root directory. This variable tells control scripts the root directory in which the products are installed. A script must use this directory as a prefix to SW_LOCATION to locate the product's installed files. The configure script is only run when SW_ROOT_DIRECTORY is /.
SW_SESSION_OPTIONS: Contains the pathname of a file containing the value of every option for a particular command, including software and target selections. This lets scripts retrieve any command options and values other than the ones provided explicitly by other environment variables. For example, when the file pointed to by SW_SESSIONS_OPTIONS is made available to a request script, the targets option contains a list of software_collection_specs for all targets specified for the command. When the file pointed to by SW_SESSIONS_OPTIONS is made available to other scripts, the targets option contains the single software_collection_spec for the targets on which the script is being executed.
SW_SOFTWARE_SPEC: This variable contains the fully qualified software specification of the current product or fileset. The software specification allows the product or fileset to be uniquely identified.

RETURN VALUES

swask returns one of these codes:

0: Command successful on all targets
1: Command failed on all targets
2: Command failed on some targets

DIAGNOSTICS

The swask command writes to stdout, stderr, and to the swask logfile.

Standard Output

An interactive swask session does not write to stdout. A non-interactive swask session writes messages for significant events. These include:

a begin and end session message,
selection, analysis, and execution task messages for each target_selection.

Standard Error

An interactive swask session does not write to stderr. A non-interactive swask session writes messages for all WARNING and ERROR conditions to stderr.

Logging

Both interactive and non-interactive swask sessions log summary events at the host where the command was invoked. They log detailed events to the swask.log logfile associated with each target_selection.

Command Log: The swask command logs all stdout and stderr messages to the the logfile /var/adm/sw/swask.log. Similar messages are logged by an interactive swask session. You can specify a different logfile by modifying the logfile option.

swagentd Disabled

If the swagentd daemon has been disabled on the host, it can be enabled by the host's system administrator by setting the SW_ENABLE_SWAGENTD entry in /etc/rc.config.d/swconfig to 1 and executing /usr/sbin/swagentd -r.

EXAMPLES

Run all request scripts from the default depot (/var/spool/sw) depot and write the response file (named response) back to the same depot:

swask -s /var/spool/sw \* 

Run the request script for Product1 from depot /tmp/sample.depot.1 on remote host swposix, create the catalog /tmp/test1.depot on the local controller machine, and place the response file (named response) in the catalog:

swask -s swposix:/tmp/sample.depot.1 -c /tmp/test1.depot Product1 

Run request scripts from remote depot /tmp/sample.depot.1 on host swposix only when a response file is absent, create the catalog /tmp/test1.depot on the local controller machine, and place the response file (named response) in the catalog:

swask -s swposix:/tmp/sample.depot.1 -c /tmp/test1.depot 
-x ask=as_needed \* 

FILES

$HOME/.swdefaults: Contains the user-specific default values for some or all SD options. If this file does not exist, SD looks for user-specific defaults in $HOME/.sw/defaults.
$HOME/.sw/sessions/: Contains session files automatically saved by the SD commands or explicitly saved by the user.
/usr/lib/sw/sys.defaults: Contains the master list of current SD options, with their default values, for documentation purposes only.
/var/adm/sw/: The directory which contains all of the configurable (and non-configurable) data for SD. This directory is also the default location of log files.
/var/adm/sw/defaults: Contains the active system-wide default values for some or all SD options.
/var/adm/sw/products/: The Installed Products Database (IPD), a catalog of all products installed on a system.
/var/adm/sw/swask.log: Contains all stdout and stderr messages generated by swask.

AUTHOR

swask was developed by the Hewlett-Packard Company.