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.
>
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
