[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kickstart and roles

On 4/19/06, Shane Stixrud <shane geeklords org> 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

> 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 redhat com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Stephen J Smoogen.
CSIRT/Linux System Administrator

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]