This section describes how you can set up cfd as a remote file
server which can result in the distrubution of files to client hosts in
a more democratic way than with programs like rdist.
An important difference between cfengine and other systems has to do
with the way files are distributed. Cfengine uses a `pull' rather than a
`push' model for distributing network files. The rdist command,
for instance, works by forcing an image of the files on one server
machine onto all clients. Files get changed when the server wishes it
and the clients have no choice but to live with the consequences.
Cfengine cannot force its will onto other hosts in this way, it can only
signal them and ask them to collect files if they want to. In other
words, cfengine simulates a `push' model by polling each client and
running the local cfengine configuration script giving the host the
chance to `pull' any updated files from the remote server, but
leaving it up to the client machine to decide whether or not it
wants to update.
Also, in contrast to programs like rdist which distribute files
over many hosts, cfengine does not require any general root
access to a system using the `.rhosts' file or the
`/etc/hosts.equiv' file. It is sufficient to run the daemon as
root. You can not run it by adding it to the `/etc/inetd.conf'
file on your system however.
The restricted functionality of the daemon protects your system from
attempts to execute general commands as the root user using rsh.
To remotely access files on a server, you add the keywork server=host
to a copy command. Consider the following example
which illustrates how you might distribute a password file from a masterhost
to some clients.
copy:
PasswdClients::
/etc/passwd dest=/etc/passwd owner=root group=0 server=server-host
Given that the cfd daemon is running on server-host, cfengine
will make contact with the daemon and attempt to obtain information
about the file. During this process, cfengine verifies that the system
clocks of the two hosts are reasonably synchronized. If they are not,
it will not permit remote copying.
If cfengine determines that a file needs to be updated from a remote
server it begins copying the remote file to a new file on the same
filesystem as the destination-file. This file has the suffix `.cfnew'.
Only when the file has been successfully collected will cfengine make
a copy of the old file, See section Repository and rename the new file
into place. This behaviour is designed to avoid race-conditions which
can occur during network connections and indeed any operations which
take some time. If files were simply copied directly to their new
destinations it is conceivable that a network error could interrupt
the transfer leaving a corrupted file in place.
Cfengine places a timeout of a few seconds on network connections to avoid hanging processes.
Normally the daemon sleeps, waiting for connections from the network.
Such a connection may be initiated by a request for remote files from a
running cfengine program on another host, or it might be initiated by
the program cfrun which simply asks the
host running the daemon to run the cfengine program locally.
Make sure that you are running cfengine from a shell which has sensible limits set. The error `too many open files' can occur in long recursions if you only have a small number of valid descriptors per shell. It is probably a good idea to set the number of descriptors to 1024.
Go to the first, previous, next, last section, table of contents.