cmmakepkg(1m) cmmakepkg(1m)
NAME
cmmakepkg - create a high availability package configuration file
SYNOPSIS
cmmakepkg [-v {0 | 1 | 2}] [-f format] -l [[-m module_file_name]...]
cmmakepkg [-v {0 | 1 | 2}] [-n package_name]
[-i pkg_ascii_file] [[-m module_file_name[-tfile_name]]...] [output_file_name]
cmmakepkg [-v {0 | 1 | 2}] -u pkg_ascii_file [[-m module_file_name]...] [output_file_name]
cmmakepkg [-v {0 | 1 | 2}] {-s | -p} [output_file_name]
DESCRIPTION
cmmakepkg creates a template package configuration file based on the specified module(s).
Package modules contain a collection of related attributes that are used as building blocks to generate the template package configuration
file. In addition, the modules supply start/stop scripts which, based on attribute values, perform the start and stop action of the pack-
ages components.
In the first form, cmmakepkg provides a list of available modules that may be used to build the package template configuration file; or
list the contents of the specified module files. cmmakepkg uses the specified modules to generate a specific package configuration tem-
plate. Only package attributes defined within the specified modules can be configured in a particular package configuration file.
There are three types of package modules - base, optional and aggregate.
A base module contains all the common attributes that are required for all packages. It is a required module to build any package. There
are three base modules:
sg/failover defines the failover package, which runs on a node at a time.
sg/multi_node defines the multi-node package, which is a special-purpose package that can run on more than one node at the
same time.
sg/system_multi_node defines the system multi-node package, which runs on all nodes in the cluster. System multi-node packages are
only supported for use by applications provided by Hewlett-Packard.
They are mutually exclusive of each other; only one can be used to build a given package. In order to create a minimal package configura-
tion file one of the base modules must be specified directly, or included in a specifed module on the command line. If no base module is
specified, the sg/default module will be used as the default, which is linked to sg/all, so the package template will include failover and
all optional modules.
An optional module defines a specific optional feature that can be used in a package. For example: sg/package_ip defines the attributes
needed to configure package IP addresses; sg/service defines the attributes needed to configure package services; and sg/dependency defines
the attributes needed to configure package dependencies... etc.
An aggregate module is one that includes other modules in its definition. If an aggregate module specified on the command line is one that
already includes a base module, the same base module doesn't need to be specified on the command line again. Duplicate module names appear-
ing in either aggregate modules or command line or both will not cause an error. Serviceguard provides two aggregate modules that include
all relavant Serviceguard parameters - sg/all which includes the base module sg/failover and therefore can be used to create a failover
package, and sg/multi_node_all which uses the base module sg/multi_node and can be used to create a multi-node package.
Base and optional types are mutually exclusive; a module cannot be both base and optional. Aggregate types on the other hand are inclu-
sive; a module can be both aggregate and base, or aggregate and optional.
The second form of cmmakepkg generates a template package configuration file based on the modules and an optional input package configura-
tion file from an existing package.
The third form of cmmakepkg re-generates the package configuration file based on an existing package configuration file, and the most
recent available version of modules that are being used in the package, which may contain new features and capabilities.
The fourth form of cmmakepkg creates a legacy package configuration file, or package control script as specified by the selected option.
This form will be obsolete in a future release of Serviceguard.
For the second, third and fourth form of cmmakepkg, The output_file_name should be customized for a specific cluster environment. After
customization, these files should be verified by the cmcheckconf command. If output_file_name is not provided, output will be directed to
stdout.
Options
cmmakepkg supports the following options:
-v {0 | 1 | 2}
Specifies the verbosity level of the output. If -v is used without a verbosity level the default is 2.
0 (machine_parsable mode)
The package configuration will be created with required attributes only. The optional attributes will not be included.
1 (headline mode)
The package configuration file will be created with headline description and the legal values of each attribute that
needs to be configured. Both the required and optional attributes are included.
2 (verbose mode)
The package configuration file will be created with full description and the legal values of each attribute that needs to
be configured. This is the default.
-n package_name
Configures the package name in the generated package configuration file.
-i pkg_ascii_file
This option is used to add additional modules to an existing package configuration. cmmakepkg uses the specified package con-
figuration file as input, and creates the new package configuration file based on the modules used in the input file, as well
as any additional modules specified with the -m option. Existing configured package parameters from the input file are carried
over to the output package configuration file. If the module specified with the -m option is one that's not already being used
within the package, any pre-configured values contained in the module file will be used in the output package configuration
file instead of or in addition to the configured value in the input package configuration file, depending on if the attribute
allows more than one value to be configured. If the module specified with the -m option is one that's already being used within
the package, a warning message will be issued, and any pre-configured value within the module will be ignored. -n option will
be used in the output package configuration file in preference to any name from the input package configuration file or module
files. A configuration file for an existing package can be generated by using the cmgetconf command. See cmgetconf(1m).
-m module_file_name...
Name of the package module files to be used to generate the package configuration file. To see a list of available modules,
use the -l option of the cmmakepkg by itself. One of the following base modules needs to be specified either on the command
line or as an included module among the specified modules on the command line: sg/failover , sg/multi_node and sg/sys-
tem_multi_node . If a base module is not specified, the default is the sg/default module which is linked to sg/all . In order
to configure a package attribute, you must specify the module defining the attribute in the package configuration file.
cmcheckconf and cmapplyconf will fail if the module that defines the package attribute is missing from the package configura-
tion file, that is if the module_name has been inadvertently removed from the package configuration file.
-u pkg_ascii_file
This option is used to upgrade a package to use the most recent available verison of the modules. When it is used with the -m
option, only the specified module will be upgraded to the most recent version.
The re-generated package configuration file will have modified values for module_name/module_version, operation_sequence, as
well as any changes made to the new version of the modules as reflected in the package configuration file output, such as addi-
tions of new package configuration parameters.
If the specified module name is not already part of the existing package configuration, or the specified module file does not
exist on all nodes of the cluster, the command will return an error.
It's not considered an error if there are no newer modules to upgrade to, the command will re-generate the package configura-
tion file as is.
-l If used by itself, this option lists the available package module files and their versions along with a brief description for
each module. When -l is used with the -f format -m option, the attributes defined within each specified module files will be
listed.
-f format
Select the output format to display. The format parameter may have one of the following values:
table this option displays a human readable tabular output format. This is the default output format if no -f is specified on
the command line.
line This option displays a machine parsable output format. Data items are displayed, one per line, in a way that makes them
easy to manipulate with tools such as grep(1) and awk(1). This option also shows additional information not available in
the table output format.
-p This parameter will be obsolete in a future release of Serviceguard. Create a legacy template of the package configuration
file. Each package should have a separate configuration file.
-s This parameter will be obsoleted in a future release of Serviceguard. Create a legacy template package control script used to
run and halt the package. Each legacy package should have a separate control script.
-t file_name
This option takes a toolkit configuration file in the POSIX shell format. The -t option must follow the -m option that speci-
fies the name of the module that defines the toolkit parameters in the file_name.
If you are creating a new package using the toolkit module, or incrementally adding a new toolkit module to an existing pack-
age, cmmakepkg uses the values from the file specified by file_name as package attribute values.
NOTE: If you are sourcing the file specified by file_name into an existing package that already has values defined for toolkit
attributes, the existing values will be overwritten by those in the file.
Package configuration file values
cmmakepkg will create a package configuration file which can be used by the cmcheckconf and cmapplyconf commands. All package attribute
names are case insensitive unless otherwise noted. This file must be customized by providing specific package information for the following
attributes:
The following attributes are defined in the sg/basic module
PACKAGE_NAME Name of the package. This name will be used to identify the package when viewing or manipulating it. Each
package must have a unique package name.
PACKAGE_TYPE Possible values are:
FAILOVER
package runs on one node at a time and if a failure occurs it can switch to an alternate node.
MULTI_NODE
package runs on multiple nodes at the same time and can be independently started and halted on individual
nodes. Failures of package components such as services, EMS resources or subnets, will cause the package
to be halted only on the node on which the failure occurred. Relocatable IP addresses cannot be assigned
to MULTI_NODE packages.
SYSTEM_MULTI_NODE
package runs on all cluster nodes at the same time. It can not be started and halted on individual nodes.
Both NODE_FAIL_FAST_ENABLED and AUTO_RUN must be set to YES for this type of package. All SERVICES must
have SERVICE_FAIL_FAST_ENABLED set to YES.
Packages which have a PACKAGE_TYPE of SYSTEM_MULTI_NODE are not failover packages and are only supported for use
by applications provided by Hewlett-Packard.
PACKAGE_DESCRIPTION
Specifies the application that the package runs. This is a descriptive parameter that can be set to any value you choose, up to a
maximum of 80 characters. Default value is Serviceguard Package.
NODE_NAME
The name of a node where this package can run on. This name must match the names configured in the cluster configuration. Multiple
NODE_NAME entries can be specified. The first NODE_NAME is the primary node and the following nodes specified will be treated as
alternate nodes.
AUTO_RUN
This can be either YES or NO. Default is YES YES, the package is allowed to move to the first available node in case of failure.
This option can also be specified dynamically using the cmmodpkg command. AUTO_RUN replaces PKG_SWITCHING_ENABLED.
NODE_FAIL_FAST_ENABLED
This can be set to either YES or NO. Default is NO. If YES, the node where the package is running will be halted in case of pack-
age failure and the package will be restarted on another node.
RUN_SCRIPT (legacy package only)
Full path location of the run script for the package. This must be a full path, located in a directory with "cmcluster" in the
pathname, and the script must be executable. If the SCRIPT_LOG_FILE attribute is not set, output from the script will go to the
file <script_path>.log . A package can be started dynamically by using the cmrunpkg command.
RUN_SCRIPT_TIMEOUT
Amount of time in seconds to wait for the run script to complete. Default is NO_TIMEOUT which means to wait forever for the run
script to complete. If RUN_SCRIPT_TIMEOUT is specified and the script has not completed within the specified value, the cluster
software will terminate the script and the package will be disabled from switching; therefore it will not be moved to another node.
In addition, if NODE_FAIL_FAST_ENABLED is set to YES, the node will be halted.
HALT_SCRIPT (legacy package only)
Full path location of the halt script for the package. This must be a full path, located in a directory with "cmcluster" in the
pathname, and the script must be executable. If the SCRIPT_LOG_FILE attribute is not set, output from the script will go to the file
<script_path>.log. Package can be halted dynamically by using the cmhaltpkg command.
HALT_SCRIPT_TIMEOUT
Amount of time in seconds to wait for the halt script to complete. Default is NO_TIMEOUT which means to wait forever until the halt
script completes. If HALT_SCRIPT_TIMEOUT is specified and the script has not completed within the specified value, the cluster
software will terminate the script and the package will be disabled from switching; therefore it will not be moved to another node.
In addition, if NODE_FAIL_FAST_ENABLED is set to YES, the node will be halted. This value should be greater than the sum of all
SERVICE_HALT_TIMEOUT values specified for this package.
SUCCESSOR_HALT_TIMEOUT
SUCCESSOR_HALT_TIMEOUT parameter limits the amount of time Serviceguard waits for the packages which depend upon this package to
halt before running the halt script of this package. This is an optional parameter. The timeout value is specified in seconds.
The minimum value is 0, the maximum is 4294. The default value is NO_TIMEOUT, meaning that the package will wait as long as it
takes for the successor packages to halt. A timeout of 0 indicates that the package will not wait for the successor packages to
halt, but will halt immediately.
SCRIPT_LOG_FILE
The full path name of the package control script log file. This is an optional parameter. If it is not set, the default location
is $SGRUN/log/<package_name>.log. Or if RUN_SCRIPT and HALT_SCRIPT are configured, the default location for each script will be
<script_path>.log.
LOG_LEVEL
This controls the amount of information printed to stdout when the package configuration is validated, and to the SCRIPT_LOG_FILE
when the package starts up and shuts down. Legal values are 0 through 5, where 0 is the least amount of logging and 5 is the most.
LOG_LEVEL 5 includes all information from level 0 to 5. The default value for LOG_LEVEL is 0.
Level 0 user visible informative messages
Level 1 slightly more detail user visible informative messages
Level 2 messages provide logic flow
Level 3 messages provide detailed data structure information
Level 4 debugging information that provides detailed data
Level 5 function call flow
The following attributes are defined in the sg/priority module
PRIORITY
The PRIORITY parameter specifies the priority of the package. This is an optional parameter. Valid values are from 1 to 3000 or
NO_PRIORITY. Default value is NO_PRIORITY. Smaller number indicates higher priority. A package with a numerical priority has
higher priority than a package with NO_PRIORITY. If a number is specified, it must be unique in the cluster. To help assign unique
priorities, HP recommends you use priorities in increments of 10. This will allow you to add new packages without having to reassign
priorities.
Multi-node and System multi-node packages cannot be assigned a priority.
This parameter is used only when a weight has been defined for a package, a package depends on other packages or other packages
depend on this package. The PRIORITY attribute may be specified for a package even when no weights or dependencies have been config-
ured. If priority is not configured, the package is assigned the default priority value, NO_PRIORITY.
Serviceguard gives preference to running the higher priority package. This means that, if necessary, Serviceguard will halt a pack-
age (or halt and restart on anther node) in order to run a higher priority package. The reason may be:
* the node's capacity would otherwise be exceeded
* there is a direct or indirect dependency between the
lower and higher priority packages.
For example, suppose a package (pkg1) depends on package (pkg2) to be up on the same node, both have package switching enabled, and
both are currently running on a node named node1. If pkg1 needs to fail over to node2, it will also need pkg2 to move to node2. If
pkg1 has higher-priority than pkg2, it can force pkg2 to move to node2. Otherwise, pkg1 cannot fail over because pkg2 is running on
node1.
The following attributes are defined in the sg/failover module
FAILOVER_POLICY The policy to be used to select a node, whenever a package needs to be started. Default is CONFIGURED_NODE which means
that if a node has not been specified, select the next available node from the list of NODE_NAME entries. The order of
NODE_NAME entries dictates the order of preference when Serviceguard selects the node. An alternate policy is SITE_PRE-
FERRED which means that if a node has not been specified, Serviceguard will prefer the next available node from the
list of NODE_NAME entries belonging to the last SITE the package ran on. If Serviceguard is unable to find an available
node from the last SITE the package ran on, SITE_PREFRRED behaves the same as CONFIGURED_NODE MIN_PACKAGE_NODE which
means that if a node has not been specified, select the node, from the list of NODE_NAME entries, which is running the
fewest number of other packages at the time the package needs to start. This option cannot be specified if any pack-
ages with weight, or nodes with capacity, has been defined.
FAILBACK_POLICY The policy used to determine what action to take when a package is not running on its primary node and its primary node
is capable of running the package. Default is MANUAL which means no attempt will be made to move the package back to
its primary node when it is running on an alternate node. The alternate policy is AUTOMATIC which means the package
will be moved back to its primary node whenever the primary node is capable of running the package. This option cannot
be specified if there are any packages with weight or nodes with capacity defined.
The following attributes are defined in the sg/service module.
SERVICE_NAME This is a logical name and is used only to identify a service as defined in run and halt scripts for the package. This
name corresponds to the service name used by the cmrunserv and cmhaltserv commands. The SERVICE_NAME must be unique
across all packages in the cluster.
SERVICE_CMD This is the command line to be executed to start the service.
SERVICE_RESTART The value for SERVICE_RESTART can be UNLIMITED, NONE or any positive integer value. If value is UNLIMITED, the service
will be restarted an infinite number of times. If the value is NONE, the service will not be restarted. If value is a
positive integer, the service will be restarted the specified number of times before failing.
SERVICE_FAIL_FAST_ENABLED
This can be either YES or NO. Default is NO. If set to YES, the cluster software will terminate the node immediately
in case of failure. This variable provides additional control at the service level within a package. Some services
may have the SERVICE_FAIL_FAST_ENABLED set and some services in the same package may not.
SERVICE_HALT_TIMEOUT
Amount of time in seconds to wait for the service to halt. In the event of a service halt, the cluster software will
first send out a SIGTERM signal to halt the process associated with the service. If the process does not halt, the
cluster software will wait for the specified timeout before sending out a SIGKILL signal to terminate the process. If
the SERVICE_HALT_TIMEOUT is not specified, the default is ZERO second, meaning the cluster software will not wait at
all before sending the SIGKILL signal to halt the service.
The following attributes are defined in the sg/monitor_subnet module
LOCAL_LAN_FAILOVER_ALLOWED (HP-UX Only)
This can be either YES or NO. Default is YES. If YES , when a network interface fails, the network components of the
package will be switched to another network interface on the local node. If NO , the package will be switched to
another node regardless of the availability of another local network interface. This is useful for those applications
whose network resources cannot be moved locally. LOCAL_LAN_FAILOVER_ALLOWED replaces NET_SWITCHING_ENABLED.
MONITORED_SUBNET Name of the network subnet that is to be monitored for this package. This name must be unique. MONITORED_SUBNET
replaces SUBNET.
MONITORED_SUBNET_ACCESS
This value defines whether access to a MONITORED_SUBNET is configured on all of the package nodes, or only on some.
The value for MONITORED_SUBNET_ACCESS can be PARTIAL or FULL. PARTIAL means that access to the MONITORED_SUBNET is
configured on one or more of the nodes that can run this package, but not all. FULL means that access to the MONI-
TORED_SUBNET is configured on all of the nodes that can run this package. FULL is equivalent to not specifying the
MONITORED_SUBNET_ACCESS at all.
CLUSTER_INTERCONNECT_SUBNET (HP-UX only)
Name of the network cluster interconnect subnet that is to be monitored for this package. This parameter is to be con-
figured only for multi-node packages in Serviceguard Extension for RAC configurations. Cluster interconnect subnet
refers to the subnet used by multi instance applications running on the various nodes of the cluster to communicate
among themselves. A failure of the cluster interconnect subnet on all nodes where the multi instance application is
running is handled by bringing down all but one instance. CLUSTER_INTERCONNECT_SUBNET and MONITORED_SUBNET must not be
configured to monitor the same subnet in a multi-node package.
The following attributes are defined in the sg/package_ip module. This module can not be used with the sg/multi_node or the sg/sys-
tem_multi_node modules within the same package.
IP_SUBNET Name of the network subnet that is associated with one of the IP address used by this package. There must be at least
one configured IP_ADDRESS entry corresponding to a configured IP_SUBNET. IP_SUBNET replaces the legacy package control
script parameter SUBNET.
IP_SUBNET_NODE Name of the node on which this subnet is available. The IP_SUBNET_NODE must be a package node and must have the IP_SUB-
NET configured on it.
IP_ADDRESS This is the IP address which is used by this package. There must be a corresponding IP_SUBNET entry for any configured
IP_ADDRESS that it belongs to. There may be more than one IP_ADDRESS per configured IP_SUBNET. IP_ADDRESS replaces
the legacy package control script parameter IP.
The following attributes are defined in the sg/resource module (HP-UX only)
RESOURCE_NAME (HP-UX only)
Name of a resource upon which a package is dependent. RESOURCE_NAME entries are optional for a package, but multiple entries may be
specified. Each name is a full path name, and must be unique within a package. A maximum of 60 resources per cluster may be
defined. However, since there is also a limit of 15 RESOURCE_UP_VALUE's per package (see below), it is possible to reach this limit
before the 60 resources per cluster limit, if a lot of the resources are all on the same package. For example, if each package has
3 resources, then it would be possible to have a maximum of 20 of these packages. Or if each package has 10 resources, then it
would be possible to have a maximum of 6 of these packages.
RESOURCE_POLLING_INTERVAL (HP-UX only)
If a RESOURCE_NAME is defined, then a RESOURCE_POLLING_INTERVAL may also be specified. It is the frequency, in seconds, that the
resource should be checked to determine its status (up or down). The RESOURCE_POLLING_INTERVAL is optional and defaults to 60 sec-
onds.
RESOURCE_START (HP-UX only)
The RESOURCE_START option can be set to either AUTOMATIC or DEFERRED The default setting for RESOURCE_START is AUTOMATIC. If AUTO-
MATIC is specified, Serviceguard will start up resource monitoring for these AUTOMATIC resources automatically when the node starts
up. If DEFERRED is selected, Serviceguard will not attempt to start resource monitoring for these resources during node start up.
Specify all the DEFERRED resources in the package run script so that these DEFERRED resources will be started up from the package
run script at package run time.
RESOURCE_UP_VALUE (HP-UX only)
If a RESOURCE_NAME is defined, then RESOURCE_UP_VALUE must be specified. An operator and a value are used with RESOURCE_UP_VALUE to
specify the values that the resource must have, in order to be considered up. The operators are =, !=, >, <, >=, and <=. The value
can be a string or a numeric value. If the type is string, then only = and != are valid operators. If a string contains white
space, it must be enclosed in quotes. String values are case sensitive. If the type is numeric, then all operators are valid. A
numeric may define a single value, a threshold, or a range to specify a resource up condition. RESOURCE_UP_VALUE may be repeated
within a RESOURCE_NAME block, and logically, are inclusively OR'd together. There is a maximum of 15 RESOURCE_UP_VALUE's per pack-
age. For example, if there is only one RESOURCE_NAME, then a maximum of 15 RESOURCE_UP_VALUE's can be defined. If there are two
RESOURCE_NAME's, defined in the same package, and one of them has 10 RESOURCE_UP_VALUE's, then the other RESOURCE_NAME can only have
5.
The following attributes are defined in the sg/dependency module
DEPENDENCY_NAME A name or an identifier for the dependency. It must be unique among this package's dependency names. DEPENDENCY_NAME
entries are optional for a package, but multiple entries may be specified.
DEPENDENCY_CONDITION
This is an expression describing what must be true for the dependency to be satisfied.
The syntax is: <package name> = <package status>
The valid values for <package status> are "UP" or "DOWN".
"UP" means that this package requires the package identified by "package_name" to be up (status reported by cmviewcl
is "UP").
If "UP" is specified, the dependency rules are as follows:
* A multi-node package can depend only on another
multi-node or system multi-node package.
* A failover package whose failover_policy is
min_package_node can depend only on a multi-node
or system multi-node package.
* A failover package whose failover_policy is
configured_node can depend on a multi-node or
system multi-node package, or another failover
package whose failover_policy is
configured_node.
"DOWN" means that this package requires the package identified by "package name" to be down (status reported by
cmviewcl is "DOWN"). This is known as an exclusion dependency.
This means that only one of these packages can be running at any given time.
If the "DOWN" value is specified, the exclusion dependency must be mutual; that is, if pkgA depends on pkgB to be down,
pkgB must also depend on pkgA to be down.
This means that in order to create an exclusion dependency between two packages, you must apply both packages to the
cluster configuration at the same time.
An exclusion dependency is allowed only between failover packages with configured_node as failover policy, and at least
one of the packages must specify a priority.
DEPENDENCY_LOCATION This describes where the condition must be satisfied.
This parameter is optional. If it is not specified, the default value "SAME_NODE" will be used.
The possible values for this attribute depend on the dependency condition.
If an "UP" dependency is specified, the possible values are "SAME_NODE", "ANY_NODE", and "DIFFERENT_NODE".
"SAME_NODE" means the dependency must be satisifed on the same node.
"ANY_NODE" means the dependency can be satisified on any node in the cluster.
"DIFFERENT_NODE" means the dependency must be satisfied on a node other than the dependent package's node.
If a "DOWN" dependency is specified, the possible values are "SAME_NODE" and "ALL_NODES".
"SAME_NODE" means the package depended on must be down on the same node.
"ALL_NODES" means the package depended on must be down on all nodes in the cluster.
NOTE: Within a package, you cannot specifiy more than one dependency on the same package. For example, pkg1 cannot have
one SAME_NODE and one ANY_NODE dependency on pkg2.
When a package requires that another package be up and the DEPENDENCY_LOCATION is ANY_NODE or DIFFERENT_NODE, the pri-
ority of the the package depended on must be higher or equal to the dependent package and its dependents. For example,
if pkg1 has a SAME_NODE dependency on pkg2 and pkg2 has an ANY_NODE dependency on pkg3, the priority of pkg3 must be
higher or equal to the priority of pkg1 and pkg2.
The following attributes are defined in the sg/weight module
WEIGHT_NAME
WEIGHT_VALUE The "WEIGHT_NAME" and "WEIGHT_VALUE" parameters are used to define package weight.
These optional attributes provide additional data which the Serviceguard package manager uses when selecting a node on
which to place the package. As with all attribute names, they are case insensitive.
A package can use this mechanism to define up to four arbitrary weight names with corresponding values that are meant
to represent the runtime resource consumption of the package. In the cluster configuration file, you configure capacity
limits for the named weights on the cluster nodes. During package placement, the package manager will ensure the total
value of any given named weight does not exceed the capacity limit configured for the node.
The "WEIGHT_NAME" is string of up to 39 characters. The "WEIGHT_VALUE" specifies a value for the named weight that
precedes it. This is an unsigned floating point value between 0 and 1000000 with at most three digits after the decimal
point.
If "WEIGHT_NAME" is specified, "WEIGHT_VALUE" must also be specified and "WEIGHT_NAME" must come first. To specifiy
more than one weight, repeat this process.
You can define weights either individually within each package configuration file, or by means of a default value in
the cluster configuration file that applies to all configured packages. If a particular weight name is defined in both
the cluster and package configuration files, the value specified in the package configuration file takes precedence.
This allows you to set an overall default, but to override it for a particular package.
For example, if you specify WEIGHT_NAME "memory" with WEIGHT_DEFAULT 1000 in the cluster configuration file, and you do
not specify a weight value for "memory" in the package configuration file for pkgA, pkgA's "memory" weight will be
1000. If you define a weight value of 2000 for "memory" in the configuration file for pkgA, the default value of 1000
will be overriden and pkgA's "memory" weight will be 2000.
If no WEIGHT_NAME/WEIGHT_DEFAULT value is specified in the cluster configuration file for a given CAPACITY, and
WEIGHT_NAME and WEIGHT_VALUE are not specified in this package configuration file for that CAPACITY, then the
WEIGHT_VALUE for this package is set to zero or one depending on the capacity name. If the capacity name is the
reserved capacity "package_limit", the WEIGHT_VALUE for this package is set to one; otherwise, the WEIGHT_VALUE is set
to zero. For example, if you specify CAPACITY "memory" and do not specify a WEIGHT_DEFAULT for "memory" in the cluster
configuration file, and do not specify weight "memory" in the package configuration file for pkgA, then pkgA's "memory"
weight will be zero.
Note that cmapplyconf will fail if you define a weight in the package configuration file and you do not specify a
capacity of the same name (in the cluster configuration file) for at least one node in the package's node_name list.
Weight can be assigned only to multi-node packages, and failover packages with CONFIGURED_NODE as the FAILOVER_POLICY
and MANUAL as the FAILBACK POLICY.
For more information on how to configure default weights and node capacities, see the cmquerycl man page, the cluster
configuration template file, and the Managing Serviceguard Manual.
Example :
WEIGHT_NAME package_limit
WEIGHT_VALUE 10.0
This overrides the default value of 1 and sets the weight for this package to 10.
Legal values for WEIGHT_NAME:
Any string that starts and ends with an
alphanumeric character, and contains only
alphanumeric characters, dot(.), dash(-),
or underscore(_) in the middle.
Maximum string length is 39 characters.
Legal values for WEIGHT_VALUE:
Any unsigned floating point string. Only
3 digits after the decimal point are
significant. Maximum string length
is 11 characters.
The following attributes are defined in the HP-UX version of the sg/volume_group module
RAW_DEVICES (HP-UX Only)
KILL_PROCESSES_ACCESSING_RAW_DEVICES allows the users to specify whether the processes accessing raw devices should be
killed at package halt time.
VOLUME_GROUPS and DISK_GROUP (HP-UX Only)
The following attributes are for configuring volume groups and disk groups on HP-UX: CONCURRENT_VGCHANGE_OPERATIONS ,
DEACTIVATION_RETRY_COUNT , VGCHANGE_CMD , CVM_ACTIVATION_CMD , VXVOL_CMD , VG , CVM_DG , VXVM_DG , VXVM_DG_RETRY and
STORAGE_GROUP (legacy package only).
The following attributes are defined in the Linux version of sg/volume_group module
VOLUME_GROUPS (Linux Only)
The following attributes are for configuring volume groups on Linux: VGCHANGE_CMD and VG
The following attributes are defined in the sg/filesystem module
FILESYSTEMS The following attributes are for configuring filesystems: CONCURRENT_FSCK_OPERATIONS , CONCUR-
RENT_MOUNT_AND_UMOUNT_OPERATIONS , FS_UMOUNT_RETRY_COUNT , FS_MOUNT_RETRY_COUNT , FS_NAME , FS_DIRECTORY , FS_MOUNT_OPT
, FS_UMOUNT_OPT , FS_FSCK_OPT and FS_TYPE
The following attribute is defined in the sg/pev module
PACKAGE_ENVIRONMENT_VARIABLE
Prefixed attribute pev_<variable_name> defines an environment variable for the package. The <variable_name> is a
string of 39 characters or less that has the prefix pev_ . The prefix must be pev_ (the letters pev followed by an
underscore). The value is a string of 1023 characters or less to which the shell variable is set. This is an optional
parameter. The user can define one or more variables which will be included as part of the output in the cmgetpkgenv
command. See cmgetpkgenv(1m). EXTERNAL_SCRIPT program can use these variables through the cmgetpkgenv command.
The following attributes are defined in the sg/external module
EXTERNAL_SCRIPT Specifies the complete path to an external script, or any other format of executables.
When the executable is run, the first argument "$1" will be set to "start" when starting a package, "stop" when halt-
ing, and "validate" when doing a cmapplyconf or cmcheckconf on the package.
The EXTERNAL_SCRIPT program will be executed after IP addresses are assigned but before services are started at package
validation and start time. It will be executed after services are halted but before removing IP addresses at package
halt time.
If more than one EXTERNAL_SCRIPT program is specified, the one specified first in this file will be run first at pack-
age start time, and last at package halt time.
The following three entries set the access control policies for the package.
They are defined in the sg/acp module. First line must be USER_NAME, second USER_HOST, and third USER_ROLE.
USER_NAME Specifies the name of the user to whom the access needs to be granted. The value can either be ANY_USER, or a maximum
of 8 login names from the /etc/passwd file on USER_HOST. If you misspell keyword ANY_USER, it will be interpreted as
the name of a specific user, and the resultant access policy will not be what you expect.
USER_HOST Specifies the hostname from where the user can issue Serviceguard commands. If using Serviceguard Manager, it is the
COM server's hostname. It can be set to ANY_SERVICEGUARD_NODE, or CLUSTER_MEMBER_NODE, or a specific hostname. If
hostname is specified, it cannot contain the full domain name or an IP address. If you misspell keywords CLUSTER_MEM-
BER_NODE or ANY_SERVICEGUARD_NODE, it will be interpreted as the name of a specific node, and the resultant access pol-
icy will not be what you expect.
USER_ROLE Specifies the access granted to the user. Only one role, PACKAGE_ADMIN can be set in the package configuration file;
the others are set in the cluster configuration file.
PACKAGE_ADMIN
This role grants permission to view information about the entire cluster, and to use administrative commands on
the package.
The attrbiutes that are not defined by Serviceguard appear in the template package configuration file with the module name as prefix. For
example, the MONITOR_INTERVAL attribute in the apache toolkit appears as "ecmt/apache/apache/monitor_interval" in the template package con-
figuration file. You can remove the prefix if you have made sure that this will not result in any name conflict within the package.
RETURN VALUE
cmmakepkg returns the following values:
0 Successful completion.
1 Command failed.
EXAMPLES
This command is part of the cluster configuration process. The following is an example of configuring a cluster with two nodes and two
packages - one failover package and one multi_node package named "pkg2":
cmquerycl -C /etc/cmcluster/clusterA.conf -n node1 -n node2
cmmakepkg -m sg/failover -m sg/package_ip -m sg/service /etc/cmcluster/pkg1/pkg1.conf
cmmakepkg -n pkg2 -m sg/multi_node -m sg/service /etc/cmcluster/pkg2/pkg2.conf
< customize clusterA.conf (optional)>
< customize pkg1.conf >
< customize pkg2.conf >
cmcheckconf -C clusterA.conf
cmapplyconf -C clusterA.conf
cmcheckconf -P pkg1.conf -P pkg2.conf
cmapplyconf -P pkg1.conf -P pkg2.conf
To modify package "pkg2" to configure package dependency:
cmgetconf -p pkg2 /etc/cmcluster/pkg2/pkg2.conf
cmmakepkg -i /etc/cmcluster/pkg2/pkg2.conf -m sg/dependency
<customize pkg2.conf>
cmcheckconf -P pkg2.conf
cmapplyconf -P pkg2.conf
To create a package and use a file with defined attributes:
cmmakepkg -v 0 -n pkgapache -m sg/all -m ecm/apache -t /opt/toolkit/apache/hattp.conf -m ecm/apache /etc/cmcluster/pkg/pkga-
pache.conf"
To modify a package adding a module and a file:
cmmakepkg -i /etc/cmcluster/pkg/pkg.conf -m ecm/apache -t /opt/toolkit/apache/hattp.conf /etc/cmcluster/pkg/newpkg.conf"
If pkg.conf does not contain ecm/apache attributes they are added to the newpkg.conf file with the values in /opt/tool-
kit/apache/hattp.conf. If pkg.conf contains ecm/apcache then the attribute values are update with the values in /opt/tool-
kit/apache/hattp.conf.
To list all modules available to be used for building a package:
cmmakepkg -l
To list the content of a module:
cmmakepkg -l -f line -m sg/service
AUTHOR
cmmakepkg was developed by HP.
SEE ALSO
cmapplyconf(1m), cmcheckconf(1m), cmgetpkgenv(1m), cmhaltpkg(1m), cmhaltserv(1m), cmmodnet(1m), cmmodpkg(1m), cmquerycl(1m), cmrunpkg(1m),
cmrunserv(1m).
Requires Optional Serviceguard Software cmmakepkg(1m)