Managing HP Serviceguard for Linux Ninth Edition, April 2009

Plan the cluster’s roles and validate them as soon as possible. If your organization’s
security policies allow it, you may find it easiest to create group logins. For example,
you could create a MONITOR role for user operator1 from CLUSTER_MEMBER_NODE
(that is, from any node in the cluster). Then you could give this login name and
password to everyone who will need to monitor your clusters.
Role Conflicts
Do not configure different roles for the same user and host; Serviceguard treats this as
a conflict and will fail with an error when applying the configuration. “Wildcards”,
such as ANY_USER and ANY_SERVICEGUARD_NODE, are an exception: it is acceptable
for ANY_USER and john to be given different roles.
IMPORTANT: Wildcards do not degrade higher-level roles that have been granted to
individual members of the class specified by the wildcard. For example, you might set
up the following policy to allow root users on remote systems access to the cluster:
USER_NAME root
USER_HOST ANY_SERVICEGUARD_NODE
USER_ROLE MONITOR
This does not reduce the access level of users who are logged in as root on nodes in this
cluster; they will always have full Serviceguard root-access capabilities.
Consider what would happen if these entries were in the cluster configuration file:
# Policy 1:
USER_NAME john
USER_HOST bit
USER_ROLE PACKAGE_ADMIN
# Policy 2:
USER_NAME john
USER_HOST bit
USER_ROLE MONITOR
# Policy 3:
USER_NAME ANY_USER
USER_HOST ANY_SERVICEGUARD_NODE
USER_ROLE MONITOR
In the above example, the configuration would fail because user john is assigned two
roles. (In any case, Policy 2 is unnecessary, because PACKAGE_ADMIN includes the role
of MONITOR.)
Policy 3 does not conflict with any other policies, even though the wildcard ANY_USER
includes the individual user john.
Configuring the Cluster 181