I haven't seen much mentioned about puppet and though I am not a puppet master (yet) and am really just now getting into using it, I will provide my reason for selecting puppet. Not having much experience with configuration management tools and after seeing a relatively new service it made sense for me to investigate puppet, thinking that puppet might have learned from the short comings that plagued earlier tools. I liked the large amount of active development that was happening with the project and after I caught Luke Kanies the original author of puppet on an episode of TLLTS discussing it my interest was peeked even further. It has the ability to integrate with cobbler; something I do currently use, though I haven't gotten that far yet, and even though I am sure other configuration management services could do this as well, the mention of puppet on the cobbler website and documentation on how to use the two together reinforced my continued efforts to explore it. I am not familiar with cfengine, though I have read some high level discussions regarding it, so I imagine that it supports SSL, but I really liked the fact that puppet supports SSL out of the box with no configuration required. I installed the puppet server on a Fedora 13 box (I tend to install actively developed services on Fedora), I will be managing CentOS 5.5 and it was installed and up and running in less then 5 min. Installing the puppet client on my CentOS boxes was even quicker. I suppose some dislike having to learn the ruby syntax that is required for the puppet configuration files, but like any other new venture it is what it is, you just have to learn it. The documentation on the puppet labs website is decent and has helped me through several configurations I have needed, this plus the few things I mentioned have me content with my decision to use puppet to manage my environment. Hope this helps a little. David On 08/27/2010 02:35 PM, Les Mikesell wrote: > On 8/27/2010 2:17 PM, James Hogarth wrote: > >> Fair enough - it didn't meet your requirements and you found something >> better that did :) >> >> My experience is that when managers/VPs start specifying a tech to use >> as opposed to a problem to solve things tend to get irritating >> quickly. >> >> I feel very fortunate to be in a company that looks to the future >> rather than hacking away to hang on to the past... >> > Keep in mind that next year the work you are doing now will be in the > past and they may want to toss it (and the people who did it) for the > next new thing. Let us know how that works out for everyone. My > experience has been that the companies that hang on to the past do so > because they have something worth keeping. > >