well considering that you might have some fun with my old mrtools project http://sourceforge.net/projects/mrtools/ P.S. I havens abandoned it I just haven't written a new version in a while because I keep tinkering with the design for the 2.x series which will primarily be written using OO Perl modules.
On Fri, Feb 22, 2013 at 12:51 PM, Yasha Karant <ykar...@csusb.edu> wrote: > We too used to use components written in perl under a distributed > environment. As this is a new installation, and as we need to find a more > maintainable and scalable solution, I posed the query for comments from > those with actual field experience. > > The fact that puppet does not seem to scale well is bothersome -- ruby is no > problem as various members of the group have (some) fluency in many > languages, including ruby, perl, python, java, and the incarnations of sh > (sh, bash, ksh, etc. -- with current emphasis upon bash). > > Our leaning now is to use cfengine. > > Yasha Karant > > > On 02/22/2013 08:39 AM, Paul Robert Marino wrote: >> >> The only problem I ever had with cfengine is the documentation was >> never all that great but it is stable and scales well. >> That being said puppet is not perfect many of the stock recipes for it >> you find on the web don't scale well and to get it to scale you really >> need to be a ruby programer. My other issue with puppet is it doesn't >> provide you with a great amount of control over the timing of the >> deployment of changes unless you go to significant lengths. >> Essentially its good for a "Agile development model" environment which >> is popular with many web companies; however its a nightmare for >> mission critical 24x7x365 environments which require changes to be >> scheduled in advance. >> >> These days I'm using Spacewalk for most of what I would have used >> cfengine or puppet for in the past the only thing that it doesn't do >> out of the box is make sure that particular services are running or >> not running at boot, but there are a myriad of other simple ways to do >> that which require very little work, and if I really wanted to I could >> get spacewalk to do that as well via the soap APIs. >> >> >> On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan <al...@physics.umn.edu> >> wrote: >>> >>> On 2/21/2013 4:13 PM, Natxo Asenjo wrote: >>>> >>>> >>>> On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan <al...@physics.umn.edu> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Also cfengine, though that seems to be getting less fashionable... We >>>>> still use it, no compelling reasons to change so far! >>>> >>>> >>>> >>>> we take our decisions based on functionality, not fashion. >>>> >>>> Cfengine is just fine. Good performance, little dependencies, good >>>> security record (not unimportant for your infrastructure management >>>> tool and oh what a start of the year for ruby it was), and it has in >>>> place editing instead of requiring you to use yet another tool >>>> (augeas). >>>> >>>> But puppet/chef are good products too, just not good enough to justify >>>> a downgrade from the better one ;-) >>> >>> >>> >>> Totally agree, I just meant that puppet does have more mindshare these >>> days >>> and you'll probably find more people familiar with it. We have used >>> cfengine >>> for 10+ years, not that we haven't discovered flaws over time but I'm >>> certainly very happy with it and see no reason to change. We have had >>> student sysadmins come in, have to learn cfengine, they also look at >>> puppet, >>> and comment that cfengine was a good choice. >>> >>> Just as we here still write most of our support scripts etc in perl, that >>> is >>> also unfashionable now, doesn't mean it's not the best tool for the job >>> (fx: >>> throws bomb and runs away... :-) >>> >>> Graham