David Lutterkort wrote:
That's the primary goal of cft for now: lend the sysadmin a hand in
capturing changes in a useful format.
If you are trying to put these results back
into a large scale configuration description, you need to understand
"why" each change was made to attach it to the right "machine class"
- is this something that has too happen on all "web servers?" or only
specific ones? On all FC5 machines?
Agreed, though I think we need to capture 'how' before we can move on to
'why' - there is certainly need for a tool that helps in folding changes
made on one machine into the sitewide config.
One critical thing that I think needs to be captured is _who_ made the
changes. Preferably demanding the "why" in the process (e.g. mandatory
commit message). Something akin to visudo with some extra bits for
example. In existing deployments where there is little or no discipline
in how changes are made to machine configurations this is possibly the
next thing to try and introduce after the "what/how". Even things like
RCS/CVS/SVN can be seen as too complex or too intrusive :-(
I do like the principle behind cft though. It sure beats using rpm -V
and diffing against stock config files to reverse engineer machines
you've never seen before.
Carwyn
_______________________________________________
lssconf-discuss mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
