This one time, at band camp, Gavin Carr wrote: >Except that that assumes describing the goal state is about the same complexity >(or easier) as making the changes directly. In my playing around with cfengine >I've found the learning curve and the extra layer of indirection mostly >annoying, rather than helpful. Usually I know the changes I want to make in >/etc; it's faster just to go ahead and do it than figure out how to convince >cfengine to do the same thing.
There's certainly a tough learning curve; I've been using it now for 5 years and it's only the last one where I've had enough power to use it effectively. I find the power comes from reduction of human error, though... >True enough - where cfengine really seems to shine is in large heterogenous >networks (e.g. >= 25 machines). OTOH, most of the server environments I >encounter are much smaller than that; typically 5-15 machines, and usually >mostly or all Linux. In this kind of environment I've found cfengine to be >overkill - the learning curve for the local admins is just too much to >justify the benefits. I find it's an advantage even in smaller homogenous networks; 2 or more :-) I'd certainly use cfengine on a network of 5 machines if I was to start administering it -- there'll come a point where the network will grow and you'll want a tool that'll help you cope with the size increase. I know there's a lack of beginners guides on cfengine; perhaps there's an opportunity for a recap on Gus' talk a few years ago at the meetings. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
