On 4/19/06, Shane Stixrud <shane@xxxxxxxxxxxxx> wrote: > On Wed, 19 Apr 2006, Michael DeHaan wrote: > > > > > Seeing I'm the one writing this puppy, I'll chime in briefly. > [snip] > > Advanced configuration of services though things like puppet is something I'm > > excited about, as it's a step beyond kickstarts. Ultimately I'd like to see > > kickstart creation and system setup demystified as much as possible. > > Handrolling of custom boot/provision solutions is always going to occur, but > > it needs to be easier. Minimal kickstarts followed up by "make it so, > > number 1" orders ultimately make it less work for SA's for automated > > deployments/rollouts. Some integration with or evolution of yam is also > > likely a good add. In general, I like the minimal install ideas Mike points > > out as well. > > The main problem I see with configuration engines like cfengine (I assume > puppet has this same issue?) is admins must either make all changes from > the central server or be forced to remember to go back and write policies > on the central server after the fact. > > Sadly doing the Right Thing (tm) isn't always an option due to real life > circumstances (cough cough management) and performing a "quick fix" to the > managed device without taking the time to write centralized policies is There is no technical solution to a management issue. You can hack as much at it but the managers will come up with a completely new way to be stupid. I found that getting management to buy off on how change control works was a better cost solution. [Getting them to sign the timesheet for the extra work/pay got them to cut down on last minute changes.] > the result. Writing these policies after the fact is of course desirable > but in many cases this would require another change control and testing > cycle. In short these type of tools really need the ability to detect what > has changed and let the admin easily integrate/pull these changes and > sign off on them as part of the devices new recipe/state. This would be useful in a different manner.. when the hacker breaks in and fixes your broken server. > > Cheers, > Shane > > > > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
