Serviceguard Manager Version A.05.02 Release Notes, March 2009

Bootstrapping a new A.11.16.xx or A.11.17.xx node
If no cluster is configured, you can create a cmclnodelist file to act as a "bootstrap" for non-root access.
Then other session server nodes have Monitor permission to access the node. Then you will be able to see
it on the map and tree, and read its status and properties. If it is not a part of a cluster now, it will still show
up in the Unused Nodes list. To configure it later, you can connect to a Session Server with Serviceguard
version A.11.16.xx or A.11.17.xx and select the node from Unused Nodes. If you give a root password,
you can configure the node into a cluster from the Actions menu.
To create a bootstrap file:
1. Create the file /etc/cmcluster/cmclnodeliston the node.
2. Using any ASCII editor, add a comment like this one:
####################################################
# Do not try to configure access in this file.
# This is only for bootstrapping, before a cluster is configured.
# Once a cluster exists, Serviceguard will ignore this file.
######################################################
3. Below the comment, create monitor access so Serviceguard can discover and display the node as an
unused node.
It may be easiest to add a wildcard + (plus) below the comment. This is equivalent to granting the
view-only Monitor role to Any User from Any Serviceguard Node. It will allow any session on the node's
subnet to query the cluster and display its information in any session of Serviceguard Manager.
Alternately, you can list any number of <hostname> <username> pairs. Hostname can be any
Session Server's name, and user can be any name in that Session Server's /etc/passwd file.
Now you will be able to see your new A.11.16.xx or A.11.17.xx node in a Serviceguard Manager session.
If the Session Server also has version A.11.16.xx or A.11.17.xx, you can configure this node into a cluster.
You will be prompted for the node's root password.
Logins, roles and security, Version A.11.15.xx and earlier:
If you are an experienced Serviceguard user, you may think there is a similarity between the command-line
user's cmviewcl command and the way Serviceguard Manager user gets information about remote clusters
with Serviceguard version A.11.15.xx and earlier. Using Serviceguard Manager, certain users can also
relay the most common administrative commands to these Serviceguard clusters, and the effect seems the
same as logging into the node and issuing the command on the command line.
Please notice, however, that the permissions and access mechanisms are actually not the same. In version
A.11.15.xx and earlier, the Serviceguard Manager user's permissions depend on his login to the Session
Server , not the cluster node . It is the Session Server that interacts with the cluster nodes on the user's behalf,
through the Cluster Object Manager, a Serviceguard API.
A Serviceguard Manager user does not need to directly access target nodes to do configuration of
Serviceguard version A.11.16.xx or A.11.17.xx. Users can log into a Session Server as any user. However,
before the user can configure any object they see in the map or tree they must give a root password for at
least one of the cluster nodes.
If the target node has version A.11.15.xx or earlier, the Session Server node must always use user= root to
access it. The recommended access mechanism is to include the Session Server name or IP address in the
target nodes' cmclnodelist file. A less secure way is to include the Session Server node in a target node's
.rhosts file. Listing in cmclnodelist allows contact to Serviceguard alone; a listing in .rhosts grants
wider access.
If the user is logged in as root to a Session Server node with version A.11.15.xx or earlier, the Session
Server node will also display certain common administrative commands in the menu. The Session Server
relays these commands to the clusters in the session for the users.
If you are updating from an earlier version, think about permissions on your HP-UX nodes with Serviceguard
Version A.11.13.xx, A.11.14.xx, and A.11.15.xx. Any person who can log in to that node as root may
be able to do administrative commands on any cluster objects on that node's subnets. If you do not want
access, you can limit the root logins on that node, or limit that node's access to particular clusters on its
subnets.
Installing and Running Serviceguard Manager 31