cfengine3 vs puppet vs chef vs bcfg2

jake

jake

Most of these have been mentioned at some point, in some context on the forums. I have done some googleing and started a lab for a few of these.

Does any one have any recommendations or advice for any of these, (maybe even other ones)? I am planning on deploying something like this in a pure FreeBSD environment (300+ servers), needs to have a small footprint, minimal dependencies, open source and be a stable as possible. Learning new syntax is not an issue.

What do FreeBSD users think of these, any one got them/happy with them in production?

Thank you for your comments.
 
  • Thanks
Reactions: Oko
I recommend you using Cfengine3.

Pros:
+ It is by far the fastest and the lightest compared to the others (it is written in C and not on scripting languages such as python or rubby that the other depends on)
+ it has minimal dependencies (berkeleydb, openssl)
+ more secure and stable
+ has commercial versions available with tons of features

Cons:
- cfengine3 configuration syntax is more difficult than the other three

edit:
I also find this interesting document:
http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf
 
I pondered the same question about year ago. Cfengine3 was the only one I tried and I am pleased with it. My main priorities were the same you mentioned.

However I predict that implementation of the new system will be a challenging process regardless of the technology you choose. Start with the simple things and proceed step by step. I made a mistake in the beginning by trying to create a too broad and generic system.

If you choose Cfengine feel free to ask advice, there are quite competent people in the Cfengine forums. I'm also pleased to share ideas.
 
Thanks you all your input, your comments back up what I was thinking, cfengine3 is the way to go. I really don't like the idea of having to maintain ruby all over the place, as I would if puppet was used (plus seems very linuxy). So I'm going to set up a small lab with cfengine3 and get to grips with it, looks like it's going to be a lot of config. Would be nice if there was a way to generate configs/promises based on an exiting running system, but I have a feeling that can't be done :)

The FreeBSD port for cfengine3 seems to require a lot of things to be manually linked to /var/cfengine post install just to get it to run. Is this because cfengine3 runs chrooted or something? Normally I'd expect to see it all under ${LOCALBASE}, with the port sorting most of this stuff out on install.
 
jake said:
Would be nice if there was a way to generate configs/promises based on an exiting running system, but I have a feeling that can't be done :)
Click to expand...

As a first step you could simply make copy promises to copy all relevant config files from the old configuration. However the promises need to be done by hand.

jake said:
The FreeBSD port for cfengine3 seems to require a lot of things to be manually linked to /var/cfengine post install just to get it to run. Is this because cfengine3 runs chrooted or something? Normally I'd expect to see it all under ${LOCALBASE}, with the port sorting most of this stuff out on install.
Click to expand...

You can find the reasoning for /var/cfengine for example from the the cfengine reference manual. In my opinion you can do it in a way you want, but default $WORKDIR /var/cfengine is compiled in (it can be changed). Previously it was advised to copy cfengine binaries from /usr/local/sbin to /var/cfengine/bin, but nowadays cfengine is split to binaries and libraries and the old reasoning doesn't wholly apply. Personally I compile binaries and libraries (also the dependencies) to /var/cfengine. This way cfengine is independent from ports.

However it is easy to get started with ports version.
 
jake said:
So I'm going to set up a small lab with cfengine3 and get to grips with it, looks like it's going to be a lot of config. Would be nice if there was a way to generate configs/promises based on an exiting running system, but I have a feeling that can't be done :)
Click to expand...


This is a 5-minute initial cfengine3 environment setup on two hosts: the one as policy/managed host <10.1.1.10> and the other as managed host <10.1.1.11>.
It uses the sample config files that installed by default on /usr/local/share/cfengine/ directory.

Perform exactly the same steps on both the nodes <10.1.1.10> and <10.1.1.11>:

1. Update ports tree to get the latest 3.2.3 version
Code: 
portsnap fetch update
2. Install cfengine
Code: 
cd /usr/ports/sysutils/cfengine3/ && make install clean
3. Run cf-key
Code: 
cf-key
4. Copy cfengine binaries to /var/cfengine/bin:
Code: 
cp /usr/local/sbin/cf-* /var/cfengine/bin

Perform the below step on policy/managed host <10.1.1.10>:

5. Copy sample configuration files
Code: 
cp /usr/local/share/cfengine/masterfiles/* /var/cfengine/masterfiles

Perform exactly the same command on both the hosts, first the policy/managed <10.1.1.10> and second the managed <10.1.1.11>:

6. Exchange public keys and startup the cfengine daemons:
Code: 
cf-agent -I -B -s 10.1.1.10

Now you have a workable two-nodes environment to play for your FreeBSD machines.
Left for you to do: Make some 'promises' for managing the cfengine daemons at startup.

Additionally I have to say that the jails infrastructure is a superb environment for experimenting and training purposes with the cfengine.
 
Very useful quick start guide, thank you :) was a bit suck until I realised that the policy server needed to self bootstrap first. One thing is a little confusing for me, you say:

Left for you to do: Make some 'promises' for managing the cfengine daemons at startup.
Click to expand...

Should I not use the rc files /usr/local/etc/rc.d/cf-serverd and /usr/local/etc/rc.d/cf-execd created by the port? Maybe I'm confused because I've not read enough yet, when I start these daemons via the rc files ps ax shows they run from /usr/local/sbin/cf-* not from /var/cfengine/bin/cf-*. I have decided to stick with the default work dir of /var/cfengine and copied my binaries to there, should all daemons be invoked from this location; Is ${LOCALBASE} basically a "staging area" for the port before I copy things to /var/cfengine?

Something tells me it would be a whole lot easier to set ${PREFIX} = /var/cfengine when compiling.
 
Just found a pretty useful resource for cfengine3 on FreeBSD + git http://unix-heaven.org/node/52 looks like a pretty good guide to get started with, (though not fully read it all yet). Doesn't really explain the rc scripts path question that I mentioned above, is it ok to have a mix of binaries running from both /usr/local/sbin and /var/cfengine, I imagine not?
 
You must log in or register to reply here.
Back
Top