[Infrastructures] Re: Why cfengine over rsync?

[Luke A. Kanies]

On Mon, 24 Feb 2003, Paul Holbrook wrote:

> Can you elaborate on this?  Why would you prefer cfengine over rsync for
> distributing files?

It's not so much cfengine vs. rsync, it's cfengine vs rsync + fileset
tools.  From what I understand, there are legitimate functional reasons to
use cfengine instead of rsync -- such as the fact that you are guaranteed
never to get an incomplete file, you can base the decision to copy on
multiple things including checksum, and you can assign ownership and modes
during the copy -- but what it largely amounts to is that it takes a
minimum of three tools (in ISconf 3, they are rsync, fileset, and modechk)
to come close to equaling the functionality in cfengine, and each of those
tools is lacking in functionality compared to cfengine.

The fileset tool in ISconf 3 works with two config files:  A global
config, defining each fileset, and a local config, defining which filesets
are configured to be pulled down on the local host.  This local config is
modified using ISconf, of course.

What I will likely do soon is rewrite this tool so that the global config
is maintained in cfengine, and cfengine is used as the transport, and the
fileset tool will become a cfengine module, which activates a class for
every fileset that needs to be copied down.  It could alternately generate
the cfengine config file, but that seems unnecessary.

The modechk script in ISconf 3 has far fewer features than cfengine; for
instance, it has no classing, so any assignments in it are global to your
network.  I plan on retiring this script entirely, as it is easily
replaced by cfengine.

The one benefit to using rsync vs. cfengine is that it can easily be
unauthenticated, but you can configure cfengine to trust keys initially,
so that works fine.

It's not so much why should you do it, but why shouldn't you?  Like most
people I've spoken to, I've got problems with cfengine, but it still does
a bunch of stuff better than anything else out there.

Luke

-- 
"But these [serious NT security flaws] are not inherent flaws in the
operating system -- they don't happen by accident. They are the result
of deliberate and well-thought-out efforts." --Mike Nash, Microsoft.
The _flaws_ are deliberate?