{i} This page does not meet our wiki style guidelines. Please help improve this page by cleaning up its formatting.

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


  1. We want to have a check in/out mechanism on every computer system without dependency of central SCM server being online.
  2. We want to push the changes to central SCM when SA feel guilty. please clarify the use of "guilty"

  3. 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
    • python interpreter.
  2. 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
      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...


  1. cfengine

HgSysTrac (last edited 2012-05-13 09:39:35 by 62)