Re: Controlled Change Management

[Wipf, Stefan]

Scott Walters wrote:
> 
> Hello All,
> 
>         For quite some time I have believed that cfengine is the 'right
> tool' for managing a diverse collection of computers.  I've only just know
> got things going in a development environment, and have things working
> from a fuctional point of view.
> 
>         I am now to the, "OK, now what" part of implementation.  Besides
> architectural and config layout concerns which will only be resolved by
> doing, I am very concerned about how to implement cfengine, where
> controlling changes is imperative.
> 
>         Over the years as a computer professional, I've learned that
> reliability is more important than performance.  And to acheive
> reliability, you need to have devel, test, and production environments.
> The production environment is then only changed when changes have been
> applied and validated in the devel and test environment.
> 
>         In my small amount of QA experience, I've learned that before you
> change something, you need to confirm it currently is working/broken,
> change, then reconfirm it is now working/broken.  So audit-change-audit
> should be the entire 'change' procedure.
> 
>         I'd like to have cfengine be an audit tool that is capable of
> change, WHEN I WANT IT TO.  In a true production environment, I can't have
> cfgengine constantly massaging systems to keep them running.  If they are
> deviating from a norm, I need to be able to determing why, since all
> changes should be scheduled.
> 
>         I just get the feeling that cfengine is a tool that is being used
> in environments where 'getting it to work' is good enough, and there are
> not rigid change management policies/procedures in place.
> 

To the contrary, cfengine enforces our rigid change management policies
by immediately reverting to the last 'blessed' state.

>         My first thought is that the modules I write should all be capable
> of running in an audit only mode, and a fix (audit-change-audit) mode,
> based on a variable defintion.  I realize that cfagent can be directed to
> 'not copy', 'don't edit', but depending on the audit (he might need to
> copy a script to run), some of those things may need to happen.
> 
>         A large motivating factor is that I need to know I can install
> cfengine on any host, do an audit and not break anything that is currently
> working.
> 
>         So my question to the group is, how have others implemented and
> architected cfengine rollouts where controlling and scheduling change is a
> requirement?
> 

Very briefly:

- without exception, everything is checked into a CVS repository and
propagates out from there automatically.

- every admin has a sandbox in which to make and test changes before
they are approved and committed.

- Since cvs allows you to run any script upon checkin, you can perform
any type of sanity or syntax check as files are committed.

- to control the rollout of cfengine, we introduced 'run modes' using
classes that can be turned on/off.  For example, 'cfagent -D
hostsonlymode'
will do nothing but check /etc/hosts and report back any differences it
finds without updating the file.  'cfagent -D hostsonlymode.dohostsmode'
will check and update /etc/hosts but will do nothing else.  We have
dedicated one of our cfengine config files to setting defaults for all
the different modes.

- all cfengine output is collected and compiled into an easily readable
report


>         Also, is their a repository, or plans for a repository of 'useful'
> cfengine scripts.  I am thinking initially that CERTs would be a great
> place to start, and the idea of going through the last 5 years of CERTs a
> little daunting.
> 
> --
> Scott Walters
> -PacketPusher
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine

-- 
Stefan Wipf
swipf@htc.com