Serviceguard Manager Version A.05.02 Release Notes, March 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.
30 Serviceguard Manager Version A.05.02 Release Notes