#format wiki
#language english

<<Include(A:style)>>

== Computer System Configuration Change Management ==

Every computer systems got deployed has a life similar to software source codes, they need to face changes. Once the system is built and delivered into production by OS CD or netinstall server, it assume its decentralized life in an IT system or your home. Processes and procedures are not executed all the time. Configuration changes over time without proper tracking often make the system unmanageable.

Changes are done by system administrators daily and those configuration changes are rarely recorded or documented. 
It is a costly process to dig out what got changed without a SCM solution. 

There are many solutions exists to tackle this area of challenge(see references).

This howto is an attempt to use hg and Trac to tackle group system administration.



=== Model of IT Systems administration ===

  * GSA (group system administration) :  A group of system administrators administrate a group of machines. 
  * CSA (centralized system administration): One or two administrators centrally administrate a group of machines.

=== Requirements ===
 1. We want to have a check in/out mechanism on every computer system without dependency of central SCM server being online.
 1. We want to push the changes to central SCM when SA feel guilty. ''please clarify the use of "guilty" ''
 1. We want to be able to find out a machine's configuration got changed by web browsing.


=== Bill of Materials ===
 1. hg client/server on every system.
    hg is a distributed SCM solution that fit very well with current IT GSA model.  TBC
    1. python interpreter.
 1. Trac server.
    {{{
     The use of Trac in this case is not to track source codes changes on a computer system.
     It is used to track system configuration files like NIS maps,/etc/hosts,/etc/nodes,/etc/mail/aliases etc. 
     files to got changed by system administrator or software program.
     }}}

=== Using CFengine + hg ===
 1. A comment from Will Maier.
  {{{ 
Why don't you centralize the configuration management? Nobody (in
their right mind) _loves_ CFengine, but it seems like the right
class of tool for the job you describe. I'd use Hg to version
CFengine input files, and use CFengine to manage the nodes. The
central approach will scale much better, too: you needn't manage Hg
repos on each machine, via cron or otherwise. Recovery from system
or disk failures is also much simpler. You merely run your automated
install system and then use CFengine bring the base configuration in
line.

I've used similar setups to manage small clusters of ~500 CPUs, and
small grids of up to several thousand CPUs. I couldn't imagine
managing one repo per node...
 }}}
=== References ===
 1. [[http://www.cfengine.org/|cfengine]]