IBM Books

Administration Guide


Managing configuration files with Configuration File Manager

Configuration File Manager (CFM) provides a file repository for the configuration files that are common the among nodes in a cluster. It allows a system administrator to control a cluster's configuration files in an easy and efficient manner. In general, all the configuration files that need to be shared are stored in one location on the management server, and changes to these files are propagated throughout the cluster. The system administrator's main responsibility will be to maintain the configuration files stored on the management server.

As an administrator, you have a certain amount of control over your configuration files. Though the files are common, there are mechanisms to allow for variations based on groups, IP address, and host name. You have flexibility in the amount of detail that you include in your configuration files, and you can specify one version of the configuration file for all the nodes of your cluster, while specifying different versions for CSM-defined node groups.

The parts of CFM that you need to know about are the Server File Repository, the cfmupdatenode command, the cfmupdatenode cron job, ERRM conditions and responses, and the CFM log files. All of these components work together to provide the administrator with control over the configuration files for the cluster.

Server File Repository

The Server File Repository is a directory on the management server called /cfmroot, which contains the cluster's configuration files. By default, the management server distributes the configuration files to each node in your cluster every 24 hours via the cfmupdatenode cron job. Note, however, that when a configuration file in /cfmroot is updated, the changes can be automatically distributed to the nodes at that time.

Note that the pathname of the configuration file on the node is the same as the same file on the server file repository, without /cfmroot. For example, the final destination of a configuration file on the management server called /cfmroot/etc/securetty is /etc/securetty on the node.

If a configuration file is deleted from /cfmroot, it will not be deleted from the nodes. Say you delete a configuration file called /cfmroot/etc/services from your management server. The /etc/services file will remain. To delete the remaining /etc/services file, you would use the dsh command as follows:

dsh -n host[,host] rm -f /etc/securetty

In the example above, host represents the hostname of the machines from which the file should be removed.

cfmupdatenode command

The cfmupdatenode command is used to prompt the management server to immediately redistribute the configuration files in /cfmroot to the nodes. However, the system administrator does not need to run this command if the ERRM condition and response pair (CFMRootModTimeChanged and CFMModResp) is running.

Checking the status of configuration files

System administrators can use the cfmupdatenode command to check the status of the configuration files on the cluster. cfmupdatenode can output the node names and configuration files that are backlevel, which helps the administrator understand what will be changed the next time the files get distributed to the nodes. To use cfmupdatenode to check the status of the configuration files in the cluster, use the -q flag:

cfmupdatenode -q

See the man page or CSM Commands for details on the cfmupdatenode command.

cfmupdatenode cron job

The cfmupdatenode cron job is created when you install CSM. By default, the cron job runs the cfmupdatenode command every night, at midnight, but you can set it to run the command at any time interval that you wish. You do this by editing the cfmupdatenode cron job with the crontab command. For information on using the crontab command, see the Linux crontab man page.

All errors that are reported by the cron job are e-mailed to root.

CFM log files

As a system administrator, you will be concerned with two log files; the error log and the change log. Both of these logs are located on the management server.

Error log

CFM uses the error log to record the errors that are encountered by the cfmupdatenode script. It is located on the management server in /var/log/csm/cfmerror.log. Once the size of the error log file (cfmerror.log) exceeds 100,000 bytes, it is copied to a back log named cfmerror.log1. When the size of the new cfmerror.log exceeds 10,000 bytes, cfmerror.log1 is renamed to cfmerror.log2 and the current cfmerror.log is renamed to cfmerror.log1. CFM retains a maximum of four backlogs, so at any give time, you could have cfmerror.log, cfmerror.log1, cfmerror.log2, cfmerror.log3, and cfmerror.log4 in the /var/log/csm directory, with cfmerror.log as the most recent.

Change log

CFM uses the change log to record details about the configuration files, such as when they are updated in /cfmroot, on the management server, and when they are distributed to the nodes. The change log is located on the management server in /var/log/csm/cfmchange.log. It uses the following format:

File server modification time | updated nodes [date stamp] | non-updated nodes [date stamp -- attempted update]


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]