I've used cfengine in a production environment, and found it to be very useful and powerful. I'll just list the features (pro and con) below.
PROS ---- * Distributed operations * Well-supported and open-source leader in its field * Widely-used * Supports many "selection critera" such as hour of day, hostname, IP address, network, cfengine version, operating system, kernel version" * Battle-tested with environments numbering in thousands (including that most hostile of environments, the college campus) * Integrates well with other systems such as CVS, RCS, et al * Works well in isolation as well in distributed fashion - and can keep system protected while server is offline * Extremely flexible * Comprehensive documentation * Can replace cron entirely (if one has a notion to...) * Can keep excess files from cluttering up /tmp or /var/tmp * Can keep unwanted files or processes from appearing at all (such as .rhosts, etc). * Can "edit" files as well as maintain complete files * Utilizes public-key encryption to identify clients (encrypted links available) * "Selection criteria" (classes) can be set programmatically by scripts * Can be used in place of samhain or tripwire (and *reacts*!) * Works well with NFS-mounted home directories * Works under Windows as well * Can manage processes - including "must be present" and "must *not* be present" and more * Active mailing list for support * Can be used to configure new systems from startup (using a minimal configuration)
CONS ---- * Documentation - comprehensive but can be hard to know where to start with new installations * Configuration is unlike anything you've ever seen * The "editfiles" section of the configuration is also unlike anything you've ever seen - and is different than any other configuration section (looks a lot like a computer language without reasonable syntax) * The customizability of the configuration can be overwhelming * Doesn't necessarily "play nice" with file integrity checkers like samhain or tripwire - i.e., if cfengine restores a file to its original state or changes the permissions samhain may flag it as being changed. * Inclusion in configuration files ("include file") is counter-intuitive: "included files" are actually concatenated to currently scanned file * "Regexes" in the EditFiles configuration section match the entire line, not a substring (unless using proper EditFiles command)
Most of the down-side to cfengine revolves around the unique configuration file syntax (and the EditFiles section most of all) and the comprehensive documentation (which does not provide for an oft-requested 1-2-3 steps to get started).
The latter problem will be solved with an upcoming book ;-)
On 12/22/06, David Douthitt ssrat@ticon.net wrote:
I've used cfengine in a production environment, and found it to be very useful and powerful. I'll just list the features (pro and con) below.
PROS
- Distributed operations
* Self contained binary.
CONS
- Documentation - comprehensive but can be hard to know where to start
with new installations
- Configuration is unlike anything you've ever seen
- The "editfiles" section of the configuration is also unlike anything
you've ever seen - and is different than any other configuration section
Actually almost every section has its own variants of the syntax.
The second con is that this is a research project for the author and not much else.. this can make dealing with problems a bit of a headache when he has completely theoretical issues he wants to try out.
Stephen John Smoogen wrote:
On 12/22/06, David Douthitt ssrat@ticon.net wrote:
I've used cfengine in a production environment, and found it to be very useful and powerful. I'll just list the features (pro and con) below. CONS
- Documentation - comprehensive but can be hard to know where to start
with new installations
- Configuration is unlike anything you've ever seen
- The "editfiles" section of the configuration is also unlike anything
you've ever seen - and is different than any other configuration section
Actually almost every section has its own variants of the syntax.
The syntax is at least visually and apparently similar and nearly consistent, though EditFiles is completely unusual.
The second con is that this is a research project for the author and not much else.. this can make dealing with problems a bit of a headache when he has completely theoretical issues he wants to try out.
I've heard this mentioned before, but I don't really see it. As one reads the documentation it also becomes apparent that the author is a campus system administrator (in some fashion), and has to deal with system administration problems as well as anyone.
My thought was that the EditFiles sections begs for a complete miniature language of its own (like awk or lua or guile) but provides nothing of the sort, and does not provide a consistent language at all.
The other mentioned "one-off" pro for puppet is a cfengine FAQ, but the usual answer is: don't create "one-off" syntax settings; define the *state* to be attained and let the system maintain the state.
On Sat, 2006-12-23 at 21:45 -0600, David Douthitt wrote:
The other mentioned "one-off" pro for puppet is a cfengine FAQ, but the usual answer is: don't create "one-off" syntax settings; define the *state* to be attained and let the system maintain the state.
I don't understand ... is that in reference to my remark about overrides and how they are useful to modify a standard set of configs ? When you override, you still specify the desired state; and syntactically it's not 'one-off' - it's just useful when you have to deal with sth that is the same across most machines, and you need a way to tweak that config for a few machines that need some small changes.
David
infrastructure@lists.fedoraproject.org
-
David Douthitt -
David Lutterkort -
Stephen John Smoogen