Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

Setting up Security
With Continentalclusters version prior to A.08.00, setting up security involves preparing the security
files, and ensuring that the network security requirements are met. Starting with Continentalclusters
A.08.00, a secure communication using SSH must be set up for inter-cluster operations.
Issue the following command to retrieve the Continentalclusters version from a node:
swlist -l product | grep -i Continentalclusters
ContClusters A.08.00.00. The Continentalclusters SD product for Disaster
Recovery
Following topics are discussed in this section:
“Setting up Security with versions prior than A.08.00” (page 59)
“Setting up Security with Continentalclusters Version A.08.00” (page 60)
Setting up Security with versions prior than A.08.00
Preparing Security Files
Running a Continentalclusters command requires root access to cluster information on all the nodes
of the participating Serviceguard clusters in the configuration. Before doing the Continentalclusters
configuration, edit the /etc/cmcluster/cmclnodelist file on each node of all the participating
clusters to include entries that will allow access by all nodes in the Continentalclusters. Here is a
sample entry in the /etc/cmcluster/cmclnodelist file for Continentalclusters configured
with two, two-node Serviceguard clusters:
lanode1.myco.com root
lanode2.myco.com root
nynode1.myco.com root
nynode2.myco.com root
Also, be sure to create the /etc/opt/cmom/cmomhosts file on all nodes. This file allows nodes
that are running monitor packages and Continentalclusters commands to obtain information from
other nodes about the health of each cluster. The file must contain entries that allow access to all
nodes in the Continentalclusters by the nodes where monitors and Continentalclusters commands
are running.
Define the order of security checking by creating entries of the following types:
order deny,allow If deny is first, the deny list is checked first to see if the node is there,
then the allow list is checked.
deny from lists all the nodes that are denied access. Permissible entries are:
all All hosts are denied access.
domain Hosts whose names match, or end in, this string
are denied access, for example, hp.com.
hostname The named host (for example, kitcat.myco.com)
is denied access.
IP address Either a full IP address, or a partial IP address
of 1 to 3 bytes for subnet restriction is denied.
network/netmask This pair of addresses allows more precise
restriction of hosts, (for example,
10.163.121.23/225.225.0.0).
network/nnnCIDR This specification is like the network/netmask
specification, except the netmask consists of
nnn high-order 1 bits. “CIDR” stands for
Classless Interdomain Routing, a type of routing
Building the Continentalclusters Configuration 59