# cfengine3 vs puppet vs chef vs bcfg2



## jake (Dec 21, 2011)

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.


----------



## akripo (Jan 3, 2012)

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


----------



## vermaden (Jan 4, 2012)

Thanks for interesting comparision in PDF.


----------



## toddnni (Jan 4, 2012)

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.


----------



## jake (Jan 7, 2012)

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.


----------



## toddnni (Jan 8, 2012)

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



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.



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.


----------



## akripo (Jan 8, 2012)

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




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

```
portsnap fetch update
```
2. Install cfengine

```
cd /usr/ports/sysutils/cfengine3/ && make install clean
```
3. Run cf-key

```
cf-key
```
4. Copy cfengine binaries to /var/cfengine/bin:

```
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

```
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:

```
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.


----------



## jake (Jan 9, 2012)

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.



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.


----------



## jake (Jan 9, 2012)

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?


----------

