synctool 5.3

synctool is an administrative tool for working with clusters of computers.

synctool copies configuration files to groups of machines in your cluster based on what groups (or classes) they are in. By doing so, it keeps the configuration on that group of machines synchronized (or, "in sync").

If needed, synctool will restart or reload any daemons, as you wish. synctool can be easily extended to do other administrative tasks, such as checking daemons, checking free disk space, installing packages, etc. or any other task you want it to do.

synctool was developed by Walter de Jong from 2003 to 2006.

synctool simplyfies system administration by working with the following concepts:

· a host can be part of one or more groups, or classes
· files are designated a class by means of filename extension
· the 'overlay' directory tree contains the files and directories that should be copied (or 'synced') to the target host
· when certain files are updated, you will want to execute a script (eg, /etc/init.d/daemon restart)
· simplicity. It uses the power of rsync and ssh to distribute the files.
· extendibility. Make synctool more powerful by writing plugin scripts.

Installation:

· copy the contents of the bin/ directory to your local software directory, like /usr/local/bin/

These executables should be available on every node in your cluster. It is easy to use a shared filesystem for this, or use rcp, scp, rsync, or whatever file distribution mechanism you already have.

· setup a synctool repository on the master node:

mkdir /var/lib/synctool

· usually the masterdir is only accessible by root:

chown root.root /var/lib/synctool
chmod 700 /var/lib/synctool

· setup initial synctool repository directories:

mkdir /var/lib/synctool/overlay
mkdir /var/lib/synctool/delete
mkdir /var/lib/synctool/tasks
mkdir /var/lib/synctool/scripts

· edit the configuration file

cp synctool.conf.example /var/lib/synctool/synctool.conf
vi /var/lib/synctool/synctool.conf

· edit the .sh scripts to contain the correct path names

vi /usr/local/bin/synctool-local.sh
vi /usr/local/bin/synctool.sh

You should decide whether or not you want to administrate your master node with synctool as well. This is a personal preference; sometimes it is easier to apply synctool to the master node as well, sometimes it is wiser not to. The hosts that are under synctool's control are listed in synctool.conf, so if you want to exclude it, leave it out of the config file.

As stated in the README, the synctool python program does not do any network communication (like, for example, cfengine does). This means you have to synchronize the repository to all nodes in the cluster by other means; rsync is perfectly suited to do this job. It is also possible to put the synctool repository on a shared filesystem. This is not recommended for large clusters for performance reasons. By default, synctool is deployed together with a wrapper script synctool.sh
that does the following:

* rsync the repository to all nodes
* run synctool on all nodes via ssh

synctool uses rsync with ssh to copy files to all nodes. This means you will need to set up ssh with passwordless login for root from the masternode to the cluster nodes. This has some security implications. Be sure you understand every security aspect before bluntly opening up the nodes. See the SSH documentation (for OpenSSH, see http://www.openssh.org ) on possible ways to achieve this.

For sites with extra tight security, it is possible to configure ssh to run only specific (synctool) commands, or maybe you want to adapt the synctool.sh wrapper script so that it suits your security needs.

Product's homepage

Requirements:

· Python
· rsync

What's New in This Release: [ read full changelog ]

· This version fixed a number of small issues and notably two larger ones: the PATH environment variable is now searched for the configured commands.
· This helps on multi-platform setups.
· The --erased-saved option now is an action by itself.
· Using --erased-saved will no longer trigger other updates to occur inadvertently.

View the original article here