Configuring cfengine

To configure a synchronization server for a standalone system, run the csync_wizard(1) on the standalone system you wish to configure as the master synchronization server:

# /opt/dsau/sbin/csync_wizard

The wizard displays the following introductory screen:

Press Enter to continue; choose item 1 from the menu below to configure a master server:

The wizard then asks if you would like to additionally configure managed clients immediately after configuring the server. For this example, answer no. Managed clients will be added later.

The wizard proceeds to configure the system as a master server:

When the configuration is completed, the wizard displays the following summary screens which direct the administrator to the main policy file, /var/opt/dsau/cfengine_master/inputs/cf.main, and the recorded answer file for this run of the wizard.

       local_hostname

Managed clients:

Note that when configuring a master server but not adding any managed clients during the server configuration, the members entry (list of managed clients), is empty, as shown in the above example.

To configure a synchronization server for a Serviceguard cluster, there are two configuration choices:

This section focuses on using the wizard to configure a highly available configuration synchronization service.

	NOTE: Before starting the wizard, all the current cluster members should be up and running in the cluster. Make sure that this cluster’s MAX_CONFIGURED_PACKAGES value can accommodate the additional package. For more information on this setting, refer to the Managing Serviceguard manual that is part of the Serviceguard documentation set.

Start by running the Configuration Synchronization Wizard, csync_wizard(1) by issuing the following command:

Press Enter to continue and choose item 1 from the menu below to configure a master server:

After you choose 1 and press Enter, the wizard displays the following text:

The wizard names the package name “csync” for configuration synchronization. This specific package name is required. The LVM storage configuration and network configuration for the package must be set up before continuing or before running the wizard. All the cluster members should also be up and available. For details, refer to the Managing Serviceguard manual, under “Building an HA Cluster Configuration”, “Creating a Storage Infrastructure with LVM.”

	NOTE: The wizard only supports creating packages based on LVM volume groups. When using CFS or VxVM, manual configuration is required. See the section on “Manually Configuring a Serviceguard Cluster Synchronization Server” for details on manually configuring the csync package.

The wizard prompts for the following, all of which should have already been configured:

Once the storage infrastructure is configured and the IP address obtained, press return to access the default answer of ‘yes’ and proceed with creating the package. The wizard now prompts for the package information:

Configuring the csync Serviceguard package for a
highly available cfengine master.

The cfengine master server is being configured as a
HA Serviceguard Package on this cluster.

Please provide the following information for the package:

Enter the Volume group [/dev/vgcsync]: 

Enter the Logical Volume [/dev/vgcsync/lvol1]: 

Enter the Filesystem (Mount Point) [/csync]: 

Enter the Mount Options [-o rw, largefiles]:

Enter the Filesystem Type [vxfs]: 

Enter the IP address [192.10.25.12]: 

Enter the Subnet [192.10.25.0]: 

The wizard now asks if you would like to manage additional remote clients, that is, systems outside the cluster. The wizard automatically configures the current members of the cluster. This is why all members must be up and accessible when running the wizard. In the example shown below, the administrator chose ‘no’ so only cluster members are configured as clients initially.

Additional remote clients can easily be added later using the wizard. When adding members to the cluster, it is not necessary to run the wizard to specify the new members as new client systems. They are automatically configured to participate in the current cfengine configuration. Refer to “Serviceguard Automation Features” for details.

The wizard now has all the data it needs to configure the cluster and proceeds to do so:

When the configuration is done, the wizard displays the following summary screens which direct the administrator to the main policy file, /mount_point/cfengine_master/inputs/cf.main, and the recorded answer file for this run of the wizard. The policy file is located on the newly configured filesystem associated with the package. In our example, the administrator chose to mount the filesystem for the package as /csync.

If the administrator had previously configured cfengine, before overwriting any existing configuration files, the wizard creates backups in the directory:

The top level files in this directory are the most recent backup files. Any configurations before that are saved in timestamped subdirectories named v_timestamp.

This section describes the details of a high availability configuration of cfengine in a Serviceguard cluster. For more information on the role of the various cfengine daemons and commands, refer to “cfengine Daemons and Commands”. The Serviceguard package ensures that cfengine's cfservd daemon remains highly available. The cfengine configuration files update.conf and cfagent.conf define the master configuration synchronization server to be the registered DNS name for the relocatable IP address of the package. When managed clients run cfagent (see cfagent(8)), cfagent connects to cfservd on the package’s adoptive node. Thus the cluster members themselves are all managed clients. The member hosting the package additionally acts as the master server for the policy files.

When booting the cluster, each member will start a client cfservd. This is the cfservd that responds to cfrun requests. When the package starts on a member, that cfservd now has access to the filesystem of the package and becomes the master cfservd that serves the policy files to all managed clients. This cfservd is monitored by the package. If cfservd fails, the package will attempt to restart on another member. That member’s cfservd will then become the master cfservd.

Halting the package does not stop the cfservd daemon on the adoptive member since the expectation is that the daemon is present to respond to future cfrun requests. Also, unlike some other high availability services, if the csync package is down or unavailable, remote clients are not adversely impacted. The clients continue to run with their currently defined configurations. The administrator would need to make sure the package is up and running in order to distribute any new configuration instructions to the managed clients.

The wizard automates cfengine key distribution to all cluster members. For a detailed description of key distribution steps performed, refer to “Security Notes”.

The Distributed Systems Administration Utilities require Serviceguard 11.17 or later. With Serviceguard 11.17 or later, when members are added to or deleted from the cluster, the configuration synchronization tools automatically take the appropriate configuration actions. Specifically:

	NOTE: When adding members to a cluster, consider the following: When adding a member to a cluster that is configured as a highly available master server, the csync package must be running when the member is added. The add member processing task copies the configuration data from the package’s mounted filesystem to the new member’s /var/opt/dsau/cfengine directories. If the package is not running, the filesystem will not be accessible and the new member will not be properly configured. In that case, the administrator can manually configure the new member as follows: Make sure that the csync package is running. If not, start it. Log in to the member running the package. Execute the following command exactly as shown: /opt/dsau/bin/csync_dispatcher MEMBER_ADDED: member_hostname For example, if the new member’s unqualified hostname is newhost, use the following command: /opt/dsau/bin/csync_dispatcher MEMBER_ADDED: newhost When adding a member to the cluster that is configured as a highly available master server, the cfengine security key of the new member is distributed cluster-wide. This enables the new member to operate as an adoptive node. If the csync package fails over to the new member, the new member will correctly handle cfagent requests from all managed clients. However, a cfrun executed from the new member will fail when contacting the managed clients. For cfrun to work properly, each managed client must have a copy of each cluster member’s key. (This is unlike cfagent on the managed client which needs only the key that corresponds to the IP address of the csync package.) For the new member to issue cfrun requests, its key must be manually created on each managed client. There are two ways to distribute the key: Use the csync_wizard “Manage keys for cfengine clients” function, which regenerates keys for all systems. All managed clients must be reachable for the regeneration to complete. Copy existing member keys to the new member. This approach takes advantage of the fact that the new member’s key is identical to the keys for the other cluster members. On the managed client, any of the existing cluster member’s keys can be copied to the proper name for the newly added member. For example, # cd /var/opt/dsau/cfengine/ppkeys # cp root-existing_member_IP_address.pub \ root-new_member_IP_address.pub

You can use the Configuration Synchronization Wizard to add managed clients to an existing cfengine configuration. Run the wizard on the master server, not the client system. When a Serviceguard cluster is the master server, run the wizard on the adoptive node for the csync package. When a Serviceguard cluster is configured as a highly available master server, adding new members to the cluster does not require using the wizard to configure those new members. They will be configured automatically. For more information, see “Serviceguard Automation Features”.

If the client is not a cluster member, to distribute cfengine keys securely, the client must be configured for non-interactive ssh access by the root account of the master server. The csshsetup tool (see csshsetup(1)) makes it easy to configure ssh access to a remote system. The csshsetup tool is used in the examples below.

A remote Serviceguard cluster can be configured as a managed client. However, each member must be configured individually. Repeat the configuration tasks described below for each member of the cluster.

Start by logging in as root on the master server and configure ssh access to the remote system:

# csshsetup hostname_of_managed_client

csshsetup first tests ssh access to the remote system. If it is not configured, ssh prompts for the managed client’s password.

Run the Configuration Synchronization Wizard and choose option 2 to add a new client:

When prompted, enter the name of the client to add:

The wizard then proceeds to configure the client and report on its progress:

The wizard configures each new client to run cfservd so it can respond to cfrun requests and adds the client to the master’s cfrun.hosts file.

Perform the following one-time steps to configure a standalone system as a cfengine master server:

Configuring cfengine for high availability in a Serviceguard cluster is similar to configuring it for a standalone machine, which is described in the section “Using the Wizard to Configure a Standalone Synchronization Server”. The primary differences are the creation of the Serviceguard package and the mechanism used to distribute cfengine’s security keys. Follow all the steps described below.

When manually configuring managed clients, the basic steps are:

For a Serviceguard cluster, each member must be individually configured as a cfengine client. After configuring each member, if you add new members to the cluster, you must manually configure each new member as well. Repeat the configuration tasks described below on each cluster member.

For all other newly managed clients, start by configuring the trust relationship between the client and the master server. The master and client systems exchange security keys to authenticate each other. The master server’s public key needs to be copied to the client and the client’s public key is copied to the master server:

To allow this client to accept cfrun requests, do the following:

For additional troubleshooting information, refer to the section “cfengine Troubleshooting”.

As the administrator, you can push changes out to managed clients by using the cfrun command (see cfrun(8)). cfrun contacts the cfservd daemon on each managed client and cfservd invokes cfagent which does the actual synchronization work. You can also choose to have cfagent run at intervals on the client. There are two approaches: