Choosing Package Modules

Any name, up to a maximum of 39 characters, that:

The module name (for example, failover, service, etc.) Do not change it. Used in the form of a relative path (for example sg/failover) as a parameter to cmmakepkg to specify modules to be used in configuring the package. (The files reside in the $SGCONF/modules directory; see “Learning Where Serviceguard Files Are Kept” for an explanation of Serviceguard directories.)

New for modular packages.

The module version. Do not change it.

New for modular packages.

The type can be failover, multi_node, or system_multi_node. Default is failover. You can configure only failover or multi-node packages; see “Types of Package: Failover, Multi-Node, System Multi-Node”.

The node on which this package can run, or a list of nodes in order of priority, or an asterisk (*) to indicate all nodes. The default is *.

For system multi-node packages, you must specify *.

If you use a list, specify each node on a new line, preceded by the literal node_name, for example:

The order in which you specify the node names is important. First list the primary node name (the node where you normally want the package to start), then the first adoptive node name (the best candidate for failover), then the second adoptive node name, followed by additional node names in order of preference.

In case of a failover, control of the package will be transferred to the next adoptive node name listed in the package configuration file, or (if that node is not available or cannot run the package at that time) to the next node in the list, and so on.

	IMPORTANT: See “Cluster Configuration Parameters ” for important information about node names. See “About Cross-Subnet Failover” for considerations when configuring cross-subnet packages, which are further explained under “Cross-Subnet Configurations”.

Can be set to yes or no. The default is yes.

For failover packages, yes allows Serviceguard to start the package (on the first available node listed under node_name) on cluster start-up, and to automatically restart it on an adoptive node if it fails. no prevents Serviceguard from automatically starting the package, and from restarting it on another node.

This is also referred to as package switching, and can be enabled or disabled while the package is running, by means of the cmmodpkg (1m) command.

auto_run should be set to yes if the package depends on another package, or is depended on; see “About Package Dependencies”.

For system multi-node packages, auto_run must be set to yes. In the case of a multi-node package, setting auto_run to yes allows an instance to start on a new node joining the cluster; no means it will not.

Can be set to yes or no. The default is no.

yes means the node on which the package is running will be halted (HP-UX system reset) if the package fails; no means Serviceguard will not halt the system.

If this parameter is set to yes and one of the following events occurs, Serviceguard will halt the system (HP-UX system reset) on the node where the control script fails:

	NOTE: If the package halt function fails with “exit 1”, Serviceguard does not halt the node, but sets no_restart for the package, which disables package switching (auto_run), thereby preventing the package from starting on any adoptive node.

Setting node_fail_fast_enabled to yes prevents Serviceguard from repeatedly trying (and failing) to start the package on the same node.

For system multi-node packages, node_fail_fast_enabled must be set to yes.

The amount of time, in seconds, allowed for the package to start; or no_timeout. The default is no_timeout. The maximum is 4294.

If the package does not complete its startup in the time specified by run_script_timeout, Serviceguard will terminate it and prevent it from switching to another node. In this case, if node_fail_fast_enabled is set to yes, the node will be halted (HP-UX system reset).

If no timeout is specified (no_timeout), Serviceguard will wait indefinitely for the package to start.

If a timeout occurs:

The amount of time, in seconds, allowed for the package to halt; or no_timeout. The default is no_timeout. The maximum is 4294.

If the package’s halt process does not complete in the time specified by halt_script_timeout, Serviceguard will terminate the package and prevent it from switching to another node. In this case, if “node_fail_fast_enabled” is set to yes, the node will be halted (HP-UX system reset).

If a halt_script_timeout is specified, it should be greater than the sum of all the values set for “service_halt_timeout” for this package.

If a timeout occurs:

If a halt-script timeout occurs, you may need to perform manual cleanup. See “Package Control Script Hangs or Failures” in Chapter 8. See also the note about VxVM under “run_script_timeout”.

Specifies how long, in seconds, Serviceguard will wait for packages that depend on this package to halt, before halting this package. Can be 0 through 4294, or no_timeout. The default is no_timeout.

New as of A.11.18 (for both modular and legacy packages). See also “About Package Dependencies”.

The full pathname of the package’s log file. The default is $SGRUN/log/<package_name>.log. (See “Learning Where Serviceguard Files Are Kept” for more information about Serviceguard pathnames.) See also “log_level”.

Defines the order in which the scripts defined by the package’s component modules will start up. See the package configuration file for details.

This parameter is not configurable; do not change the entries in the configuration file.

New for modular packages.

Determines the amount of information printed to stdout when the package is validated, and to the “script_log_file” when the package is started and halted. Valid values are 0 through 5:

New for modular packages.

Specifies how Serviceguard decides where to restart the package if it fails. Can be set to configured_node or min_package_node. The default is configured_node.

This parameter can be set for failover packages only. For a package that will depend on another package or vice versa, see also “About Package Dependencies”.

Specifies what action the package manager should take when a failover package is not running on its primary node (the first node on its node_name list) and the primary node is once again available. Can be set to automatic or manual. The default is manual.

This parameter can be set for failover packages only. If this package will depend on another package or vice versa, see also “About Package Dependencies”.

Assigns a priority to a failover package whose “failover_policy” is configured_node. Valid values are 1 through 3000, or no_priority. The default is no_priority. See also the dependency_ parameter descriptions, starting on “dependency_name”.

priority can be used to satisfy dependencies when a package starts, or needs to fail over or fail back: a package with a higher priority than the packages it depends on can drag those packages, forcing them to start or restart on the node it chooses, so that its dependencies are met.

If you assign a priority, it must be unique in this cluster. HP recommends assigning values in increments of 20 so as to leave gaps in the sequence; otherwise you may have to shuffle all the existing priorities when assigning priority to a new package.

	IMPORTANT: Because priority is a matter of ranking, a lower number indicates a higher priority (20 is a higher priority than 40). A numerical priority is higher than no_priority.

New A.11.18 (for both modular and legacy packages). See “About Package Dependencies” for more information.

A unique identifier for a particular dependency that must be met in order for this package to run (or keep running). The length and formal restrictions for the name are the same as for “package_name”.

	IMPORTANT: Restrictions on dependency names in previous Serviceguard releases were less stringent. Packages that specify dependency_names that do not conform to the above rules will continue to run, but if you reconfigure them, you will need to change the dependency_name; cmcheckconf and cmapplyconf will enforce the new rules.

Configure this parameter, along with dependency_condition and dependency_location, if this package depends on another package; for example, if this package depends on a package named pkg2:

For more information about package dependencies, see “About Package Dependencies”.

The condition that must be met for this dependency to be satisfied. As of Serviceguard A.11.18, the only condition that can be set is that another package must be running.

The syntax is: <package_name> = UP, where <package_name> is the name of the package depended on. The type and characteristics of the current package (the one we are configuring) impose the following restrictions on the type of package it can depend on:

See also “About Package Dependencies”.

Specifies where the “dependency_condition” must be met. The only legal value is same_node.

Specifies whether or not Serviceguard can transfer the package IP address to a standby LAN card in the event of a LAN card failure on a cluster node.

Legal values are yes and no. Default is yes.

A LAN subnet that is to be monitored for this package. Replaces legacy SUBNET which is still supported in the package configuration file for legacy packages; see “Configuring a Legacy Package”.

You can specify multiple subnets; use a separate line for each.

If you specify a subnet as a monitored_subnet the package will not run on any node not reachable via that subnet. This normally means that if the subnet is not up, the package will not run. (For cross-subnet configurations, in which a subnet may be configured on some nodes and not on others, see monitored_subnet_access below, “ip_subnet_node ”, and “About Cross-Subnet Failover”.)

Typically you would monitor the ip_subnet, specifying it here as well as in the ip_subnet parameter (see below), but you may want to monitor other subnets as well; you can monitor any subnet that is configured into the cluster (via the STATIONARY_IP or HEARTBEAT_IP parameter in the cluster configuration file).

If any monitored_subnet fails, Serviceguard will switch the package to any other node specified by node_name which can communicate on the monitored_subnets defined for this package. See the comments in the configuration file for more information and examples.

In cross-subnet configurations, specifies whether each monitored_subnet is accessible on all nodes in the package’s node list (see “node_name”), or only some. Valid values are PARTIAL, meaning that at least one of the nodes has access to the subnet, but not all; and FULL, meaning that all nodes have access to the subnet. The default is FULL, and it is in effect if monitored_subnet_access is not specified.

See also “ip_subnet_node ” and “About Cross-Subnet Failover”.

New for modular packages. For legacy packages, see “Configuring Cross-Subnet Failover”.

Specifies an IPv4 address. Can be configured only for a multi-node package in a Serviceguard Extension for Real Application Cluster (SGeRAC) installation.

(See the latest version of Using Serviceguard Extension for RAC at http://www.docs.hp.com -> High Availability - > Serviceguard Extension for Real Application Cluster (ServiceGuard OPS Edition) for more information.)

New for A.11.18 (for both modular and legacy packages).

Specifies an IP subnet used by the package. Replaces SUBNET, which is still supported in the package control script for legacy packages.

For each subnet used, specify the subnet address on one line and, on the following lines, the relocatable IP addresses that the package uses on that subnet. These will be configured when the package starts and unconfigured when it halts. If you want the subnet to be monitored, specify it in the monitored_subnet parameter as well.

For example, if this package uses subnet 192.10.25.0 and the relocatable IP addresses 192.10.25.12 and 192.10.25.13, enter:

ip_subnet 192.10.25.0

ip_address 192.10.25.12

ip_address 192.10.25.13

If you want the subnet to be monitored, specify it in the monitored_subnet parameter as well.

In a cross-subnet configuration, you also need to specify which nodes the subnet is configured on; see ip_subnet_node below. See also “monitored_subnet_access” and “About Cross-Subnet Failover”.

This parameter can be set for failover packages only.

In a cross-subnet configuration, specifies which nodes an ip_subnet is configured on. If no nodes are listed under an ip_subnet, it is assumed to be configured on all nodes in this package’s node_name list (see “node_name”).

Can be added or deleted while the package is running, with these restrictions:

See also “monitored_subnet_access” and “About Cross-Subnet Failover”.

New for modular packages. For legacy packages, see “Configuring Cross-Subnet Failover”.

A relocatable IP address on a specified “ip_subnet”. Replaces IP, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

For more information about relocatable IP addresses, see “Stationary and Relocatable IP Addresses ”.

This parameter can be set for failover packages only.

A service is a program or function which Serviceguard monitors as long as the package is up. service_name identifies this function and is used by the cmrunserv and cmhaltserv commands. You can configure a maximum of 30 services per package and 900 services per cluster.

The length and formal restrictions for the name are the same as for “package_name”. service_name must be unique among all packages in the cluster.

	IMPORTANT: Restrictions on service names in previous Serviceguard releases were less stringent. Packages that specify services whose names do not conform to the above rules will continue to run, but if you reconfigure them, you will need to change the name; cmcheckconf and cmapplyconf will enforce the new rules.

Each service is defined by five parameters: service_name, service_cmd, service_restart, service_fail_fast_enabled, and service_halt_timeout. See the descriptions that follow.

The following is an example of fully defined service:

service_name patricks-package4-pingservice_cmd "/usr/sbin/ping hasupt22"service_restart unlimitedservice_fail_fast_enabled no service_halt_timeout 300

See the package configuration file for more examples.

For legacy packages, this parameter is in the package control script as well as the package configuration file.

The command that runs the application or service for this service_name, for example,

/usr/bin/X11/xclock -display 15.244.58.208:0

An absolute pathname is required; neither the PATH variable nor any other environment variable is passed to the command. The default shell is /usr/bin/sh.

	NOTE: Be careful when defining service run commands. Each run command is executed in the following way: The cmrunserv command executes the run command. Serviceguard monitors the process ID (PID) of the process the run command creates. When the command exits, Serviceguard determines that a failure has occurred and takes appropriate action, which may include transferring the package to an adoptive node. If a run command is a shell script that runs some other command and then exits, Serviceguard will consider this normal exit as a failure. To avoid problems in the execution of service commands, ensure that each run command is the name of an actual service and that its process remains alive until the actual service stops.

This parameter is in the package control script for legacy packages.

The number of times Serviceguard will attempt to re-run the service_cmd. Valid values are unlimited, none or any positive integer value. Default is none.

If the value is unlimited, the service will be restarted an infinite number of times. If the value is none, the service will not be restarted.

This parameter is in the package control script for legacy packages.

Specifies whether or not Serviceguard will halt the node (system reset) on which the package is running if the service identified by service_name fails. Valid values are yes and no. Default is no, meaning that failure of this service will not cause the node to halt. yes is not meaningful if service_restart is set to unlimited.

The length of time, in seconds, Serviceguard will wait for the service to halt before forcing termination of the service’s process.

The value should be large enough to allow any cleanup required by the service to complete.

Legal values are none, unlimited, or any number greater than zero. unlimited means Serviceguard will never force the process to terminate. The default is none, meaning that Serviceguard will not wait any time before forcing the process to terminate.

The name of a resource to be monitored.

resource_name, in conjunction with resource_polling_interval, resource_start and resource_up_value, defines an Event Monitoring Service (EMS) dependency.

In legacy packages, RESOURCE_NAME in the package configuration file requires a corresponding DEFERRED_RESOURCE_NAME in the package control script.

You can find a list of resources in Serviceguard Manager (Configuration -> Create Package -> Monitored Resources -> Available EMS resources), or in the documentation supplied with the resource monitor.

A maximum of 60 EMS resources can be defined per cluster. Note also the limit on resource_up_value (see below).

The maximum length of the resource_name string is 1024 characters.

See “Parameters for Configuring EMS Resources” for more information and example.

How often, in seconds, the resource identified by “resource_name” is to be monitored. Default is 60 seconds. The minimum value is 1. (There is no practical maximum.)

Specifies when Serviceguard will begin monitoring the resource identified by resource_name. Valid values are automatic and deferred.

automatic means Serviceguard will begin monitoring the resource as soon as the node joins the cluster. deferred means Serviceguard will begin monitoring the resource when the package starts.

Defines a criterion used to determine whether the resource identified by resource_name is up.

Requires an operator and a value. Values can be string or numeric.The legal operators are =, !=, >, <, >=, or <=, depending on the type of value. If the type is string, then only = and != are valid. If the string contains white space, it must be enclosed in quotes. String values are case-sensitive.

The maximum length of the entire resource_up_value string is 1024 characters.

You can configure a total of 15 resource_up_values per package. For example, if there is only one resource (resource_name) in the package, then a maximum of 15 resource_up_values can be defined. If two resource_names are defined and one of them has 10 resource_up_values, then the other resource_name can have only 5 resource_up_values.

Specifies the number of concurrent volume group activations or deactivations allowed during package startup or shutdown.

Legal value is any number greater than zero. The default is 1.

If a package activates a large number of volume groups, you can improve the package’s start-up and shutdown performance by carefully tuning this parameter.Tune performance by increasing the number a little at a time and monitoring the effect on performance at each step; stop increasing it, or reset it to a lower level, as soon as performance starts to level off or decline.Factors you need to take into account include the number of CPUs, the amount of available memory, the HP-UX kernel settings for nfile and nproc, and the number and characteristics of other packages that will be running on the node.

	NOTE: If you set concurrent_vgchange_operations to a value greater than 1, you may see messages such as this in the package log file: Cannot lock “/etc/lvmconf//lvm_lock” still trying...” This is an informational message that can be safely ignored.

Indicates whether multi-threaded activation of volume groups (vgchange -T) is enabled. New for modular packages. Available on HP-UX 11i v3 only.

Legal values are zero (disabled) or 1 (enabled). The default is zero.

Set enable_threaded_vgchange to 1 to enable vgchange -T for all of a package’s volume groups. This means that when each volume group is activated, physical volumes (disks or LUNs) are attached to the volume group in parallel, and mirror copies of logical volumes are synchronized in parallel, rather than serially. That can improve a package’s startup performance if its volume groups contain a large number of physical volumes.

Note that, in the context of a Serviceguard package, this affects the way physical volumes are activated within a volume group; “concurrent_vgchange_operations” controls how many volume groups the package can activate simultaneously.

	IMPORTANT: Make sure you read the configuration file comments for both concurrent_vgchange_operations and enable_threaded_vgchange before configuring these options, as well as the vgchange (1m) manpage.

Specifies the method of activation for each HP-UX Logical Volume Manager (LVM) volume group identified by a vg entry (see “vg”). Replaces VGCHANGE which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

The default is vgchange -a e.

The configuration file contains several other vgchange command variants; either uncomment one of these and comment out the default, or use the default. For more information, see the explanations in the configuration file, “LVM Planning ”, and “Creating the Storage Infrastructure and Filesystems with LVM and VxVM”.

	IMPORTANT: Volume groups for multi-node and system multi-node packages must be activated in shared mode: vgchange -a s, which is only available if the add-on product Serviceguard Extension for Real Application Cluster (SGeRAC) is installed. (See the latest version of Using Serviceguard Extension for RAC at http://www.docs.hp.com -> High Availability -> Serviceguard Extension for Real Application Cluster (ServiceGuard OPS Edition) for more information.) Shared LVM volume groups must not contain a file system.

(For more information about LVM, see the Logical Volume Management volume of the HP-UX System Administrator’s Guide under System Administration in the HP-UX 11i v3 Operating Environments section of docs.hp.com, or Managing Systems and Workgroups under System Administration in the HP-UX 11i v2 section, depending which version of HP-UX you are running.)

	NOTE: A given package can use LVM volume groups, VxVM volume groups, CVM volume groups, or any combination.

Specifies the method of activation for Veritas Cluster Volume Manager (CVM) disk groups. The default is

vxdg -g \${DiskGroup} set activation=readonly

The configuration file contains several other vxdg command variants; either uncomment one of these and comment out the default, or use the default. For more information, see the explanations in the configuration file, “CVM and VxVM Planning ”, and “Creating the Storage Infrastructure and Filesystems with Veritas Cluster Volume Manager (CVM)”.

Specifies the method of recovery for mirrored VxVM volumes. Replaces VXVOL, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

If recovery is found to be necessary during package startup, by default the script will pause until the recovery is complete. To change this behavior, comment out the line

vxvol_cmd "vxvol -g \${DiskGroup} startall"

in the configuration file, and uncomment the line

vxvol_cmd "vxvol -g \${DiskGroup} -o bg startall"

This allows package startup to continue while mirror re-synchronization is in progress.

Specifies an LVM volume group (one per vg, each on a new line) on which a file system needs to be mounted. A corresponding “vgchange_cmd” specifies how the volume group is to be activated. The package script generates the necessary filesystem commands on the basis of the fs_ parameters (see “fs_name”).

Specifies a CVM disk group (one per cvm_dg, each on a new line) used by this package. CVM disk groups must be specified whether file systems need to be mounted on them or not. A corresponding “cvm_activation_cmd” specifies how the disk group is to be activated.

Any package using a CVM disk group must declare a dependency (see the entries for dependency_name and related parameters starting on “dependency_name”) on the CVM system multi-node package. See “Preparing the Cluster for Use with CVM ”.

Specifies a VxVM disk group (one per vxvm_dg, each on a new line) on which a file system needs to be mounted. See the comments in the package configuration file, and “Creating the Storage Infrastructure and Filesystems with LVM and VxVM”, for more information.

Specifies how many times the package shutdown script will repeat an attempt to deactivate a volume group (LVM) or disk group (VxVM, CVM) before failing.

Legal value is zero or any greater number. Default is zero.

Specifies whether or not to kill processes that are using raw devices (for example, database applications) when the package shuts down. Default is no. See the comments in the package configuration file for more information.

A package can activate one or more storage groups on startup, and to mount logical volumes to file systems. At halt time, the package script unmounts the file systems and deactivates each storage group. All storage groups must be accessible on each target node. (CVM disk groups must be accessible on all nodes in the cluster).

For each file system you specify in the package configuration file (see “fs_name”), you must identify a logical volume, the mount point, the mount, umount and fsck options and type of the file system; for example:

fs_name /dev/vg01/lvol1

fs_directory /pkg01aa

fs_mount_opt "-o rw"

fs_umount_opt "-s"

fs_fsck_opt "-s"

fs_type "vxfs"

A logical volume can be created in an LVM volume group, a Veritas VxVM disk group, or a Veritas CVM disk group. Logical volumes can be entered in any order, regardless of the type of storage group.

The parameter explanations that follow provide more detail

The number of concurrent fsck operations allowed on file systems being mounted during package startup.

Legal value is any number greater than zero. The default is 1.

If the package needs to run fsck on a large number of filesystems, you can improve performance by carefully tuning this parameter during testing (increase it a little at time and monitor performance each time).

The number of concurrent mounts and umounts to allow during package startup or shutdown.

Legal value is any number greater than zero. The default is 1.

If the package needs to mount and unmount a large number of filesystems, you can improve performance by carefully tuning this parameter during testing (increase it a little at time and monitor performance each time).

The number of mount retries for each file system. Legal value is zero or any greater number. The default is zero.

If the mount point is busy at package startup and fs_mount_retry_count is set to zero, package startup will fail.

If the mount point is busy and fs_mount_retry_count is greater than zero, the startup script will attempt to kill the user process responsible for the busy mount point (fuser -ku) and then try to mount the file system again. It will do this the number of times specified by fs_mount_retry_count.

If the mount still fails after the number of attempts specified by fs_mount_retry_count, package startup will fail.

This parameter is in the package control script for legacy packages. See “Configuring a Legacy Package”.

The number of umount retries for each file system. Replaces FS_UMOUNT_COUNT, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

Legal value is any greater number greater than zero. The default is 1. Operates in the same way as “fs_mount_retry_count”.

This parameter, in conjunction with fs_directory, fs_type, fs_mount_opt, fs_umount_opt, and fs_fsck_opt, specifies a filesystem that is to be mounted by the package. Replaces LV, which is still supported in the package control script for legacy packages.

fs_name must specify the block devicefile for a logical volume.

Filesystems are mounted in the order specified in this file, and unmounted in the reverse order.

	NOTE: A volume group must be defined in this file (using vg; see “vg”) for each logical volume specified by an fs_name entry.

See “File system parameters”, and the comments in the FILESYSTEMS section of the configuration file, for more information and examples. See also “Logical Volume and File System Planning ”, and the mount (1m) manpage.

The root of the file system specified by fs_name. Replaces FS, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”. See the mount (1m) manpage for more information.

The type of the file system specified by fs_name. This parameter is in the package control script for legacy packages.

See the mount (1m) and fstyp (1m) manpages for more information.

The mount options for the file system specified by fs_name. This parameter is in the package control script for legacy packages.

See the mount (1m) manpage for more information.

The umount options for the file system specified by fs_name. This parameter is in the package control script for legacy packages.

Using the -s option of umount will improve startup performance if the package uses a large number of file systems. See the mount (1m) manpage for more information.

The fsck options for the file system specified by fs_name. Using the -s (safe performance mode) option of fsck will improve startup performance if the package uses a large number of file systems. This parameter is in the package control script for legacy packages.

See the fsck (1m) manpage for more information.

Specifies a package environment variable that can be passed to an external_pre_script, external_script, or both, by means of the cmgetpkgenv (1m) command. New for modular packages.

The variable name must be in the form pev_<variable_name> and contain only alphanumeric characters and underscores. The letters pev (upper-case or lower-case) followed by the underscore (_) are required.

The variable name and value can each consist of a maximum of MAXPATHLEN characters (1024 on HP-UX systems).

You can define more than one variable. See “About External Scripts”, as well as the comments in the configuration file, for more information.

The full pathname of an external script to be executed before volume groups and disk groups are activated during package startup, and after they have been deactivated during package shutdown (that is, effectively the first step in package startup and last step in package shutdown). New for modular packages.

If more than one external_pre_script is specified, the scripts will be executed on package startup in the order they are entered into this file, and in the reverse order during package shutdown.

See “About External Scripts”, and the comments in the configuration file, for more information and examples.

The full pathname of an external script. This script is often the means of launching and halting the application that constitutes the main function of the package. New for modular packages.

The script is executed on package startup after volume groups and file systems are activated and IP addresses are assigned, but before services are started; and during package shutdown after services are halted but before IP addresses are removed and volume groups and file systems deactivated.

If more than one external_script is specified, the scripts will be executed on package startup in the order they are entered into this file, and in the reverse order during package shutdown.

See “About External Scripts”, and the comments in the configuration file, for more information and examples.

Specifies the name of a user who has permission to administer this package. See also user_host and user_role; these three parameters together define the access-control policy for this package (see “Controlling Access to the Cluster”). These parameters must be defined in this order: user_name, user_host, user_role.

Legal values for user_name are any_user or a maximum of eight login names from /etc/passwd on user_host.

	NOTE: Be careful to spell any_user exactly as given; otherwise Serviceguard will interpret it as a user name.

Note that the only user_role that can be granted in the package configuration file is package_admin for this particular package; you grant other roles in the cluster configuration file. See “Setting up Access-Control Policies” for further discussion and examples.

The system from which a user specified by user_name can execute package-administration commands.

Legal values are any_serviceguard_node, or cluster_member_node, or a specific cluster node. If you specify a specific node it must be the official hostname (the hostname portion, and only the hostname portion, of the fully qualified domain name). As with user_name, be careful to spell the keywords exactly as given.

Must be package_admin, allowing the user access to the cmrunpkg, cmhaltpkg, and cmmodpkg commands (and the equivalent functions in Serviceguard Manager) for this package, and to the Monitor role for the cluster. See “Controlling Access to the Cluster” for more information.