I've used all 3 to varying degrees.<div><br></div><div>CFEngine - I started out with this one quite a while ago, say 2005. Puppet was just starting up and Chef didn't exist. It's good if you have never used anything else but every so often you get to a point where you start swearing at it. At $job[-1] we used it too, though I wasn't the main guy on it, I just got called in for a second set of eyes when things weren't working correctly.</div>
<div><br></div><div>The main problems with CFEngine are that it treats the whole thing as a series of phases. First you copy files. Then you modify files. Then you look at services. Sometimes you'll get into a dependency problem where your system is set up to copy files then modify files, but you need to copy a file after modifying a file, and you end up with a bunch of hacks. The other problem is probably also an advantage in that CFEngine gives you tools to modify configuration files on the fly so you can support any application out of the gate. The problem with this is that it ends up causing problems in the long run. The idea is to describe a system configuration (postfix should be configured not to relay), not to describe a configuration file (if a line with "relay_all_spam_ftw" exists then comment it out)</div>
<div><br></div><div>On the plus side, CFEngine is ultra fast and the agent is lightweight. It also has integrated performance monitoring so you can flag alerts or do stuff under certain load conditions. </div><div><br></div>
<div>I also presented at MUUG about my setup at the time: <a href="http://muug.mb.ca/meetings/lamp_tuning_seanwalberg.pdf">http://muug.mb.ca/meetings/lamp_tuning_seanwalberg.pdf</a></div><div><br></div><div>Puppet: I've been following this project for a while and off and on use it at home. At $current_job we have a managed service that uses puppet, so we don't see the manifests themselves but have a good exposure to what's going on.</div>
<div><br></div><div>The idea behind puppet is that you use modules that understand a particular service and then describe the configuration of the service. The module takes care of what needs to be done to configure the files or whatever. If you've got modules available to manage the service then you're off to the races. If not, you have to write your own. Writing the module is a bit more complex than the equivalent in CFEngine, but it gives you a lot more flexibility since you're doing it in a combination of puppet and ruby (for the templates)</div>
<div><br></div><div><a href="https://gist.github.com/3738489">https://gist.github.com/3738489</a> is an example of my firewall's configuration that sets up two ruby environments and Postfix.</div><div><br></div><div>We use Chef at work to build our development boxes. It's like Puppet - lite. It's easier to do basic stuff but gets uglier the more complex you go. The puppet community seems to pride itself on making its modules work across various systems, while almost anything you find out there for Chef seems to only run on Debian.</div>
<div><br></div><div>Chef seems like what you get if you got a developer to spec out a Config management system and had a systems administrator write it. Puppet seems to be specced by a systems administrator and written by a developer.</div>
<div><br></div><div>If I were doing it all again I'd use puppet. CFengine just seems antiquated and once you run into the problems with it, and Chef doesn't seem robust enough.<br><br>Also, as some notes because this topic has been on my mind...</div>
<div><br></div><div>- If you're starting out, I found it easier to tackle it service by service rather than server by server. And do go slowly. Pick something like ntpd and sudo and get those working across your environment before continuing.</div>
<div>- I've started a podcast. On the first episode I reviewed a book that's made for developers and systems administrators and uses puppet extensively. I'd highly recommend the book if you want to get started with Puppet. See <a href="http://linuxadminshow.com/">http://linuxadminshow.com/</a> for the links to the podcast, my written review, and a link to the book</div>
<div>- On the podcast note, on my list of show topics is to talk about automated configuration management with Cfengine and puppet. If you get into it in any great detail, and would like to be a guest, let me know.</div><div>
<br></div><div>Sean</div><div><br><div class="gmail_quote">On Mon, Sep 17, 2012 at 11:47 AM, Robert Keizer <span dir="ltr"><<a href="mailto:robert@keizer.ca" target="_blank">robert@keizer.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings Greetings,<br>
<br>
I'm looking for personal experiences from people on this list who have dealt with either CFEngine or Puppet. What do you think are the pros / cons? Did you have a horrible experience with one? Are you a Chef junky instead?<br>
<br>
A little bit of background: I've been working for a company who asked me to design and implement a complete infrastructure solution - internal, external, testing, production, etc. Things are now stable, redundant, and tested ( 90% anyways .. always more to do ). I won't go into too much detail about the system as I know just how searchable this email will be as soon as it hits the muug server. Suffice to say that there are about 10 Windows and Unix systems that I'd like to be able to manage a little easier.<br>
<br>
I haven't done anything more than read documentation on the two products mentioned above over the last few years. As I'm trying to decide which / if any of these systems would be a good solution for management of a stable production system that _won't_ have too many major changes in the coming months/years, and I'd like some input.<br>
<br>
It's worth noting that I'm a guy that decided to ( before hearing of these frameworks ~4 years ago ) build my own custom framework for managing the system ( I'd like to apply the bus principle now that I have some sense ) - so scripts and a steeper learning curve aren't my biggest concern.<br>
<br>
Any thoughts / advice / personal experiences would be most appreciated.<br>
<br>
All the best,<br>
Rob Keizer<br>
______________________________<u></u>_________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca" target="_blank">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/<u></u>listinfo/roundtable</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Sean Walberg <<a href="mailto:sean@ertw.com" target="_blank">sean@ertw.com</a>> <a href="http://ertw.com/" target="_blank">http://ertw.com/</a><br>
</div>