[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Controlled Change Management
From: |
Wipf, Stefan |
Subject: |
Re: Controlled Change Management |
Date: |
Fri, 31 Jan 2003 17:13:39 -0600 |
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