cmmakepkg(1m)cmmakepkg(1m)NAMEcmmakepkg - create a high availability package configuration file
SYNOPSIScmmakepkg [-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]]...] [out‐
put_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]
DESCRIPTIONcmmakepkg 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 packages
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 speci‐
fied modules to generate a specific package configuration template.
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 aggre‐
gate.
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 sup‐
ported 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 defini‐
tion. 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 appearing
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 mod‐
ule 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 inclusive; 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 configuration
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 out‐
put_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 con‐
figuration file.
-i pkg_ascii_file
This option is used to add additional modules to an exist‐
ing package configuration. cmmakepkg uses the specified
package configuration 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 out‐
put 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 gener‐
ated 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/system_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 pack‐
age 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 configuration
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 modi‐
fied values for module_name/module_version, opera‐
tion_sequence, as well as any changes made to the new ver‐
sion of the modules as reflected in the package configura‐
tion file output, such as additions of new package configu‐
ration 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 com‐
mand 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
configuration file as is.
-l If used by itself, this option lists the available package
module files and their versions along with a brief descrip‐
tion 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 for‐
mat. 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 addi‐
tional information not available in the table output
format.
-p This parameter will be obsolete in a future release of Ser‐
viceguard. Create a legacy template of the package config‐
uration file. Each package should have a separate configu‐
ration 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 pack‐
age 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
specifies 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
package, 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 over‐
written 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 custom‐
ized 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 compo‐
nents 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 SER‐
VICE_FAIL_FAST_ENABLED set to YES.
Packages which have a PACKAGE_TYPE of SYS‐
TEM_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 fail‐
ure. 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
package 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 com‐
plete. 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 com‐
plete. 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 Ser‐
viceguard 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 sec‐
onds. 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 pack‐
ages 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 loca‐
tion 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 informa‐
tive 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 num‐
ber 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 with‐
out 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
configured. 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 package (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 CONFIG‐
URED_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 Ser‐
viceguard selects the node. An alternate policy is
SITE_PREFERRED 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_PRE‐
FRRED behaves the same as CONFIGURED_NODE MIN_PACK‐
AGE_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 num‐
ber of other packages at the time the package needs
to start. This option cannot be specified if any
packages 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 pri‐
mary 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 infi‐
nite number of times. If the value is NONE, the
service will not be restarted. If value is a posi‐
tive 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 SER‐
VICE_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 clus‐
ter 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 soft‐
ware 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 appli‐
cations 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. MONI‐
TORED_SUBNET replaces SUBNET.
MONITORED_SUBNET_ACCESS
This value defines whether access to a MONI‐
TORED_SUBNET is configured on all of the package
nodes, or only on some. The value for MONI‐
TORED_SUBNET_ACCESS can be PARTIAL or FULL. PAR‐
TIAL 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 MONITORED_SUBNET is configured on all of the
nodes that can run this package. FULL is equiva‐
lent 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 configured only for multi-node
packages in Serviceguard Extension for RAC configu‐
rations. 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 inter‐
connect subnet on all nodes where the multi
instance application is running is handled by
bringing down all but one instance. CLUSTER_INTER‐
CONNECT_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 parame‐
ter 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_SUBNET configured on it.
IP_ADDRESS This is the IP address which is used by this pack‐
age. 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 config‐
ured 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 pos‐
sible 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 seconds.
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 AUTOMATIC 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 pack‐
age 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 maxi‐
mum of 15 RESOURCE_UP_VALUE's per package. 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 spec‐
ify a priority.
DEPENDENCY_LOCATION This describes where the condition must be satis‐
fied.
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 "DIFFER‐
ENT_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 sat‐
isfied 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 exam‐
ple, 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 DIFFER‐
ENT_NODE, the priority 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 insensi‐
tive.
A package can use this mechanism to define up to
four arbitrary weight names with corresponding val‐
ues 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 float‐
ing 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 par‐
ticular weight name is defined in both the cluster
and package configuration files, the value speci‐
fied in the package configuration file takes prece‐
dence. 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 configura‐
tion 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 pack‐
age 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 configu‐
ration 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: CONCUR‐
RENT_VGCHANGE_OPERATIONS , DEACTIVATION_RETRY_COUNT
, VGCHANGE_CMD , CVM_ACTIVATION_CMD , VXVOL_CMD ,
VG , CVM_DG , VXVM_DG , VXVM_DG_RETRY and STOR‐
AGE_GROUP (legacy package only).
The following attributes are defined in the Linux version of sg/vol‐
ume_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 <vari‐
able_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 cmgetp‐
kgenv (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 halting, 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 speci‐
fied, the one specified first in this file will be
run first at package start time, and last at pack‐
age 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_MEM‐
BER_NODE, or a specific hostname. If hostname is
specified, it cannot contain the full domain name
or an IP address. If you misspell keywords CLUS‐
TER_MEMBER_NODE or ANY_SERVICEGUARD_NODE, it will
be interpreted as the name of a specific node, and
the resultant access policy 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 con‐
figuration file; the others are set in the cluster
configuration file.
PACKAGE_ADMIN
This role grants permission to view informa‐
tion about the entire cluster, and to use
administrative commands on the package.
The attrbiutes that are not defined by Serviceguard appear in the tem‐
plate 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 VALUEcmmakepkg returns the following values:
0 Successful completion.
1 Command failed.
EXAMPLES
This command is part of the cluster configuration process. The follow‐
ing is an example of configuring a cluster with two nodes and two pack‐
ages - 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/cmclus‐
ter/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/cmclus‐
ter/pkg/pkgapache.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/toolkit/apache/hattp.conf.
If pkg.conf contains ecm/apcache then the attribute values are update
with the values in /opt/toolkit/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
AUTHORcmmakepkg was developed by HP.
SEE ALSOcmapplyconf(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)
