I would totally recommend Puppet Commander in place of that, if you have the time to get it running:
http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/ToolPuppetcommander It uses mcollective and is pretty much awesome. Daniel On Thu, Dec 8, 2011 at 21:22, Brian Gallew <g...@gallew.org> wrote: > Let me emphasize the beauty of running Puppet out of cron. Not only do you > not end up with resource leaks (or just simple consumption when you don't > need it), but you also get much more reliable load on your puppet masters. > Further, if you are wiling to make a trivial effort to write a > site-specific fqdn_rand() work-alike function, you can even arrange to be > sure that updates roll across related servers in a reliable way. > > > On Thu, Dec 8, 2011 at 6:08 PM, Jeffrey Watts <jeffrey.w.wa...@gmail.com> > wrote: >> >> I've found Puppet to be unreliable running as a daemon - I suspect due to >> older versions of ruby floating around. So I switched to running it from >> cron, and it works a lot better. Memory usage doesn't seem to be an issue, >> and the agent only runs for a few seconds. Use Puppet Dasboard (or >> something like it) and/or use Nagios to make sure those cron jobs run. I >> use both. >> >> The main thing is to have Puppet managing itself and the cron job. I have >> ours set up to run the cron job twice an hour, using the concatenated IP >> address modulo 30 and modulo 30 + 30 as the times (to keep the clients from >> hammering the Puppetmaster all at once). Let me know if you go with Puppet >> and I'll show you how I did it. >> >> Part of the reason we chose Puppet was the quantity of documentation and >> working examples and the helpfulness of the community. I support (and >> implement) our Puppet environment here at my job. I would highly recommend >> Mr Turnbull's Pro Puppet book. It is VERY sysadmin focused and will save you >> a lot of time. The sections on environments, modules, and Dashboard were >> really helpful. >> >> Jeffrey >> Sent from my iPad >> >> On Dec 8, 2011, at 2:59 PM, Luke <lutay...@gmail.com> wrote: >> >> > This tool will be used by primarily system admins to automate server >> > builds app installs, configurations etc. The devs will use it in their >> > own environment to help automate some of their tasks. I don't think we >> > have too much Ruby expertise since we are mostly a Java shop. >> > >> > In terms of performance I have read that CFengine uses much less >> > memory and can be faster than puppet. Can anyone comment on the agent >> > and server memory usage? I have read that the puppet agent can use >> > 85mb and the server upwards to 1GB after 20-30agents. Is that >> > accurate? >> > >> > I guess which tool would you consider to be the quickest, easy to >> > implement etc? From what I am seeing the community here seems to be >> > much more active than the others. I have yet to get a response on the >> > other forums. >> > >> > On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: >> >> I should also add that a very important consideration is to take in >> >> mind >> >> _who_ will be working with this. Are they developers, sysadmins, QA? >> >> Will >> >> the people working on it be spending a lot of time with >> >> Puppet/Chef/CFengine, or just a little? Are you planning on writing a >> >> bunch of custom modules, or relying on the community? What languages >> >> does >> >> your team work on primarily? For example, folks that work with Ruby a >> >> lot >> >> would probably do better with Puppet and Chef. >> >> >> >> As a sysadmin, I often see developers get distracted by arguments about >> >> what's "best" or the most technically advanced. Often they forget that >> >> in >> >> the end the real answer is often which tool gets the job done the >> >> quickest, >> >> with the least amount of labor, and is the most supportable. >> >> >> >> Jeffrey. >> >> >> >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman >> >> <dan...@puppetlabs.com>wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> Instead, I suggest you focus on your ability to learn the concrete use >> >>> of the tool, and on how effectively you can solve problems with them; >> >>> doing a small trial of each - solve the same mid-sized problem three >> >>> times, giving each a day or two - and see what you think works best >> >>> for your company and culture. >> >> >> >>> There is no silver bullet. >> > >> > -- >> > 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. >> > >> >> -- >> 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. >> > > -- > 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. -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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.
