www.delorie.com/gnu/docs/cfengine/cfengine-Reference_144.html   search  
Buy GNU books!

GNU cfengine

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.3 cfrun

The general syntactic form of the cfrun command is

  cfrun -option --longoption class1 class2 ...

Since cfrun addresses remote hosts, there is an ambiguity in whether options are intended for the cfrun command itself, on the local host, or whether they are to be passed on to the agent on the remote hosts. To clarify this distinction, the arguments are organized as follows:

  cfrun -local options -- remote options -- remote classes

Local options are processed by cfrun on the local host; remote options are passed on as options to the remote cfagent (actually to the command defined in cfrunCommand in the file `cfservd.conf'; remote classes are processed by the remote cfservd service, and specifiy classes which must be satisfied by the remote host in order to invoke the remote command.

The `-q' and `-I' options are always assumed when executing cfengine remotely, so that SplayTime is effectively zero when polling hosts serially, and the output always shows what is happening on the remote hosts.

Each host evaluates the classes sent by cfrun and decides whether cfengine should be invoked. Only hosts which belong to the classes defined on the cfrun command line are executed. This allows you to single out groups of hosts which should execute cfengine, based on the very classes which you have defined for your configuration. If no classes are sent on the command line, then all hosts are run.

cfrun uses a configuration file which is located under the CFINPUTS directory in order to determine which hosts and in which order it should try to connect. Because cfengine always uses a reliable TCP protocol for connections, it verifies each connection rather than simply broadcasting openly. Using this file you can even simulate broadcasting to hosts outside your subnet.

This file should contain every host name you ever want to configure remotely, because you can still select subsets of the file by specifying classes which the remote host will understand. If the remote host is not in one of the classes you specify when you run cfrun, then it will simply ignore the request. Conversely, if you do not place a host in this file, it will never be contacted when you use the cfrun command. The format of the file is as follows

 # Comment ..
 maxchild=number limit

 hostname1            options
 hostname2:port options

If the option outputdir is present, cfrun forks a separate process for each host and passes the output to files in a named directory. The maxchild line limits the number of forked processes.

It is important to add the domain-name to this file. The options you specifiy in this file, per host, are added to those you might specify on the command line when invoking cfengine remotely. For instance, you might know of a bug on one host and decide not to perform interface configuration on that one machine. You would write a line like this:

  funny.domain -- -i  # problem host

You could use cfrun inside one of your cfengine configuration files in order to remotely execute cfengine on all of the other network machines, by setting up a host list. The disadvantage however is that cfengine has to poll the systems on the network, which means that cfengine cannot be working in parallel on all hosts.

Some other examples:

e.g.  cfrun -- -- linux          Run on all linux machines
      cfrun -- -p                Ping and parse on all hosts
      cfrun -v -- -p             Ping all, local verbose
      cfrun -v -- -k -- solaris  Local verbose, all solaris, but no copy

Amongst the local options, one may specify a subset of the hosts which are to be contacted by cfrun, i.e. to avoid processing the entire list of hosts. For example, to contact only host1 and host2, given that they are already in the list of hosts.

cfrun -v host1 host2
cfrun -v host1 host2 -- -p 

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003