Serviceguard Manager Version A.05.02 Release Notes, Third Edition, July 2009

Setting up Serviceguard Manager
Security, Logins, and Access Policies
In version A.11.16.xx, Serviceguard changed its method of controlling and assigning logins, and
roles. Therefore, the way you open Serviceguard Manager sessions and discover Serviceguard
objects is quite different in versions A.11.16.xx and later than it is in earlier versions of
Serviceguard.
Logins and roles, Version A.11.16.xx and A.11.17.xx:
Creating or modifying configuration still requires Root access (UID=0) on a cluster's nodes.
Starting in Serviceguard version A.11.16.xx, a root user can configure clusters and packages using
Serviceguard Manager as well as the command line. If you log in to a Session Server's COM as
root, you have full access to the cluster and its nodes.
In addition, there are four possible non-root roles that can be defined in the cluster's configuration
files. These are specified as Access Control Policies in the cluster and package configuration files.
Each Access Policy has three parts:
• User: A username from the host's /etc/passwd file
• Host: Where the user will issue the command. For Serviceguard Manager, this is the Session
Server node
• Role: Which commands the user may issue on the cluster where the policy is configured.
There are 4 non-root roles:
— monitor (view, read-only), defined in the cluster configuration file.
This is the only role that does not require the Host node to have version A.11.16.xx or
A.11.17.xx of Serviceguard.
— (single package) package admin, defined in that package's configuration file
— (all cluster packages) package admin, defined in the cluster configuration file
— full admin (cluster and all of its packages), defined in the cluster configuration file
For more information about access control policies, see the online help for Configuring Clusters:
Roles.
If you upgraded a cluster to Serviceguard A.11.16.xx or A.11.17.xx, its cmclnodelist has been
migrated into Access Control Policies. With A.11.16.xx and A.11.17.xx,cmclnodelist is gone.
If your previous cmclnodelist file listed the pair <sess.server> <user>, your cluster
configuration now has an Access Control Policy that lists this triplet:
• USER_NAME <user>
• USER_HOST <sess.server>
• USER_ROLE Monitor (All migrated pairs are signed the role of Monitor, view-only.)
If your old cmclnodelist had the wildcard +, the configuration file now has an Access Control
Policy with wildcards in triplet:
• USER_NAME ANY_USER
• USER_HOST ANY_SERVICEGUARD_NODE
• USER_ROLE MONITOR (All migrated pairs area assigned the role of Monitor, view-only.)
Only a root user can modify configuration to change Access Control Policies. You do not have
to halt the cluster or any packages, to add, modify, or delete an Access Control Policy.
If you have a cluster on an A.11.16.xx or A.11.17.xx node, be sure to configure at least one Access
Control Policy so your COM has permission to discover the cluster and its nodes in Serviceguard
Manager. Once a cluster is configured on an A.11.16.xx or A.11.17.xx node, Serviceguard will
only check access in the cluster's configuration files. It will ignore the .rhosts file and the
cmclnodelist file.
32 Serviceguard Manager Version A.05.02 Release Notes