Wow, I'm glad this generated some discussion. I had almost given up on my post/thread.
Thanks for the replies, everyone. Jordan, for context, we've been using Cfengine 2.x for 12 years now on ~180 boxes (nowadays) which I was wholly responsible for and continue to be (for lame reasons I won't get into) the person who administers/drives it. We hook a cfengine run into the end of our network installs (kickstart and Jumpstart) which does its thing, where one of those things is to add our cfengine_run wrapper script to root's crontab (nightly at 3AM + random(100secs)). We're a "thinktanky" place, not a public-facing web product company. SW and HW devs, researchers doing NLP stuff, etc. For more context, I'm extremely averse to shoddy-seeming architectures or software, especially for something as important as configuration management. To that topic, I had some choice words toward my screen when I came to understand the bogusness that is WEBrick+Rubythreads, and that most do the Mongrel/proxy or Passenger dance. I'm not going to do that. It's BS to me, and I'm sure there plenty of people here who will take issue with that. I'm actually pretty amazed at Puppet's adoption in agent+master form. So I'm either going masterless Puppet + git repo or something else entirely (Cfengine 3), and I'm just trying to gain a clear picture of the masterless list of cons. Going from Cfengine 2 to Cfengine 3 is almost as much effort as learning Puppet, so I figured I'd poke around with Puppet. I've read the Loggly slide deck, but don't quite know enough about Puppet terms yet to extract real meaning from most of the masterless info slides. Right now, thanks to our existing cfengine 2 setup, I've built and pushed Cfengine 3, Facter 1.5.8, Puppet 2.4.6, Ruby 1.8.7 + rubyssl, and the ruby-shadow module to all of our boxes' local disk. For Solaris 10, I tweaked ruby-shadow (patch submitted and accepted) and also include the Cfengine 3 dependencies not commonly found: PCRE and Oracle Berkeley DB. I'm not sure how relevant this is to the topic, but I'll mention it as well in case. There are two goals to this next-gen CM plan. The first is to serve our managed machine needs in way that is saner than a gigantic Cfengine 2 config file. The second is to provide a way for other ad-hoc UNIX/Linux boxes in the organization to benefit from using our tool tree + manifests/configs. There's no reason for Jim Smith to need to hand-configure the 12 things on his Ubuntu 10.x box to make it worthwhile on the corp. network... etc. This second goal is largely marketing for our group's capabilities and worth. At any rate, I think the only thing for me to do is retreat into masterless-Puppet-test-rollout-land until I understand clearly what the limitations (mentioned in the thread here) mean to our goals. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
