Administration Guide
Name
cfmupdatenode - Distributes configuration files across the
cluster. The cfmupdatenode command is called by the
updatenode command.
Synopsis
cfmupdatenode [-h]
[-v | -V] [-a | -N
node_group[,node_group...]]
[-b] [[-y] |
[-c]] [-q
[-s]] [-r
remote_shell_path] [-t
timeout] [-M
max_child_process] [-d
distfile_location] [-f
filename] [host[,
host...]]
Description
The cfmupdatenode command provides the major function of the
Configuration File Manager (CFM) application. CFM provides a file repository on the management server (/cfmroot) to contain all the
files that are shared among CFM managed nodes. The system administrator
builds /cfmroot directory to be the repository of files or links to
files of interest, in particular, configuration files.
The cfmupdatenode command is run on the management server and
causes immediate distribution of the configuration files located in the server
file repository (/cfmroot). The target nodes must be supplied to the cfmupdatenode
command through the use of the -a, -N, or
positional arguments.
Symbolic links can be placed in the \cfmroot directory, but
cfmupdatenode will transfer the target of the symbolic link. If
symbolic links need to be maintained throughout the cluster, they should be
created with filename.post files.
A file in the server file repository can either be sent to all nodes, or to
a defined node group. To associate a file with a specific group add a
._GroupName extension to the file name. This file
will now only be distributed to nodes in this CSM node group. During
file transfer this ._GroupName extension is removed.
The ._GroupName extension must come at the end of the
directory or filename. In addition it cannot contain the "/"
character.
- Note:
- Adding a ._GroupName extension to a file creates a
persistent association between a CSM node group and the file. Please
keep this in mind when you change node group definitions.
The default remote transfer protocol for cfmupdatenode is
rsh. CFM can use any remote shell whose usage follows the
syntax of rsh and allows remote automated login. The remote
shell can be specified with the -r flag. If not specified,
cfmupdatenode checks the DSH_REMOTE_CMD environment
variable for a remote shell path, and if that fails, uses the default,
rsh.
There is a query option on cfmupdatenode that displays which CFM
files are out of date across the cluster. This can be invoked with the
-q command line option. The query can also compare the last
time CFM updated a node to the last modification time in
/cfmroot. This quickly displays which nodes are out of date
and can be invoked through the combination of the -q and
-s command line options.
CFM allows file preprocessing and postprocessing; for example, to
start and stop daemons. In cases where a
filename.pre or
filename.post script exists, the
filename.pre script or executable is run on the
destination node before the configuration file is copied, and
filename.post script is run after the
configuration file is copied. The scripts are run under the same user
as cfmupdatenode. All stdout and stderr from these scripts
is redirected by cfmupdatenode to both stdout and stderr on the
management server (stdout is only displayed if cfmupdatenode is run
with the -v verbose option). These scripts may be written in
any shell-based scripting language.
- Note:
- The filename.pre and
filename.post scripts are retained on each node
in the /var/opt/csm/cfmlocal/ directory. File permissions
should be set so that these are not accessed by unauthorized users. The
file permissions should be set in /cfmroot so they will be maintained
throughout the cluster.
Files transferred by CFM retain their original modification time stamp from
the management server. While the cluster does not need to have
synchronized time clocks for the successful operation of CFM, the
administrator should exercise caution when operating CFM in younger
(-y) mode.
CFM is designed to facilitate in the distribution of individual
configuration files across a cluster. It should not be used to
distribute or maintain copies of entire file systems as this could result in
extremely slow performance. CFM can transfer both text and binary
files. However, it should be noted that CFM provides no support for
Endian byte conversion between architectures.
Options
- -a
- Files are distributed to all the nodes in the ManagedNode class.
This option cannot be used with the -N or host positional
arguments.
- -h
- Writes the command's usage statement to standard output.
- -v | -V
- Verbose mode.
- -b
- Backup. Preserve existing configuration files (on nodes) as
filename.OLD.
- -y
- Younger mode. Files are normally updated if their modification
times and sizes disagree with those of the master copy (located in
/cfmroot). This option causes cfmupdatenode not
to update files that are younger than the master copy. This option
should only be used if the administrator is confidant that the time clocks on
the client nodes are in sync with the time clock on the management
server. A warning message is printed for files which are newer than the
master copy.
- -c
- Perform binary comparison on files and transfer them if they
differ.
- -q
- Queries which CFM files are out of date across the cluster. These
files will be updated by the next normal execution of
cfmupdatenode. If all files are current, nothing is
reported.
- -r remote shell path
- Path to use for remote commands. Can either point to rshell or secure remote command executable.
- -s
- Reports which ManagedNodes are up-to-date by comparing the last CFM update
time with the modification time of files in the /cfmroot
directory. Only for use with the -q flag.
- -t timeout
- Set the timeout period (in seconds) for waiting for responses from a
remote process. The default is 900 seconds.
- -M max_child_processes
- Set the number of nodes to update concurrently. The default is
32. Please note that depending on the number of files that
need to be transferred, cfmupdatenode can take a while to update a
node and that this number should be set accordingly.
- -d distfile location
- Generates a distfile but does not call Rdist (the open source
utility used for file transfer). This way the administrator can run
Rdist with whatever options she chooses.
- -f filename
- Only updates the given filename. The filename should contain the
absolute path name of the file and the file must reside in the
/cfmroot directory.
- -N node_group[,node_group...]
- Resolves one or more node groups (separated by spaces or commas) and sends
the resulting nodes their configuration files.
- host[,host...]
- Specify hostnames (separated by spaces or commas) to which files should be
distributed.
Exit Status
Exit codes 1-4 mean that cfmupdatenode aborted file transfer
when it received this error. Exit codes 10+ mean that
cfmupdatenode tried to distribute as many files as possible.
- 0
- All files transferred successfully.
- 1
- Usage error.
- 2
- Could not write distfile at /tmp/cfm_distfile (on management
server).
- 3
- Another executing of cfmupdatenode is currently running.
- 4
- Could not run lsnodes or nodegrp. CTRMC
down.
- 10
- Rdist returned a non zero exit code. Some file
distribution probably failed.
- 11
- Clocal reported an error on a remote node.
- 21
- Hostname or node group name resolution error. The administrator
should consider running the CTRMC probe and checking the input to the CFM
command.
- 22
- One or more nodes experienced severe errors (they probably did not receive
any configuration files). This includes unreachable (Fping status = 0)
nodes.
- 23
- There were errors concerning filenames in /cfmroot. Some
files may not have been distributed.
Examples
- To force cfm to run on all nodes, enter:
cfmupdatenode -a
- To run cfm on one particular managed node, in this case, a node
with the host name of puppy, enter:
cfmupdatenode puppy
Files
- /cfmroot
- The directory on the management server that contains the cluster's
configuration files.
- /opt/csm/bin/cfmupdatenode
- Location of the cfmupdatenode command.
- /tmp/cfm_distfile
- Location of the file that is created with the -d option of
cfmupdatenode and contains instructions on how and where to transfer
files.
- /var/log/csm/cfmerror.log
- Location of CFM error logs.
- /var/log/csm/cfmchange.log
- Location of the log, on the management server, that contains updates to
files.
See Also
The updatenode man page.
Author
Jennifer Cranfill- cluster@us.ibm.com
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]