VersionControlledEtc

Revision 25 as of 2006-05-27 08:53:30

Clear message

Summary

The specification describes an enhancement to keep automated versioned history of files under /etc.

Rationale

Over time, configuration changes occur and it is easy to forget why changes were made, or what was in a config file prior to the change. It becomes even more difficult when there are multiple administrators working on a machine over a period of time.

Use cases

  1. Andrew is a systems administrator and his mail server has stopped working. Richard, another administrator, made some changes a week ago but has now gone on holiday to his residence in France. Andrew is unsure what changes Richard made to the mail configuration, but he can use the automated version history to look at the changes made before Richard went away.

  2. Karl has a box which was working and set up the way he likes. After a failed dist-upgrade his system is left in a half configured state. He would find it benefical to be able to roll back to just before the upgrade.

  3. Igor has a few servers upon which he has made identical bespoke modifications to /etc. He would like to be able to store these modifications centrally and then distribute them to his servers when he changes them.

Scope

Design

Implementation

So far I have tried out the following;

in /etc/; 

bzr init
bzr add *
bzr commit -m "Initial Import"

then I added the following to roots crontab; 

0 * * * * cd /etc; bzr commit -v -m "Automated update at `date`" >& /dev/null

Code

Some proof of concept code is avaialable via bzr from http://www.cs1ajb.staff.shef.ac.uk/bzr/auto-bzr/. You can download it using bzr using 

bzr branch http://www.cs1ajb.staff.shef.ac.uk/bzr/auto-bzr/

Data preservation and migration

Outstanding issues

  • Depending on implementation, files modified by a user could fail to be updated in VCS.
  • Automating this process at the dpkg level would be highly intrusive.
  • is bzr the right choice? I think it is, but what do I know?!
  • Is it useful to get dpkg to update the bzr tree when it does things in /etc?
  • Can we use DPkg::Pre-Invoke and DPkg::Post-Invoke in apt to integrate with package management better?

BoF agenda and discussion

  • I'd say it's very useful to integrate this with dpkg, so that items changed due to package upgrades are shown as being done by a different user in the logs.

  • It would be useful to make this tool as generic as possible - such that other directories can be configured to be tracked and even results of applications, such as dpkg --get-selections

Comments

AchimBohnet:

  • poluting /etc/ with version info files/dirs is a no-no IMHO. FWIW, I use svk because it does not add .<whatever> to every dir like svn (I have not tried bzr yet)

  • Pkg tracking _including version_ is important. dpkg --get-selections does contain this info

  • support for at least 1 commit per apt-get install/(dist-)upgrade is IMO very important (ala apt-listchanges), One commit for each installed or upgraded pkg level would be nice to have. At least one has to check that before pkg changes /etc is in a clean state so user and pkg changes don't mix.

    • AndrewBeresford: a) I rewrote above item. Better? b) I even don't like one .bzr per managed tree. find and locate don't like the duplicates too (at least in the svn case Wink ;) That's of course IMHO.

AndrewBeresford:

  • AchimBohnet, I agree with your comment about polluting /etc. bzr does place files in a .bzr directory, but only in the top level of the repository. That seems a reasonable trade off to me.

  • dpkg --get-selections doesn't seem to contain any version numbers when I run it. I'm not sure that using version management to log the output of dpkg --get-selections is the based way to do things anyway. Would it not be better to get dpkg to log its actions to a file (/var/log/dpkg.log?).

  • I'm not sure I'm clear on your idea about 1 commit per multiple installed/removed package. What I'd thought up was running the bzr commit at the very end of a dpkg action and logging with a commit message like "<name of package> <version> installed". You could also run the bzr commit at the beginning of dpkg, but my concern would be the performance decrease. Does dpkg have a mechanism for running arbitrary commands at the beginning/end of a session? Something, like a global preinst/postinst script that gets run for every package installed/removed? Update: This can be done through apt hooks - not quite as good as going through dpkg, but much more straightforward/less invasive than modifying dpkg to do it.

PaulSchulz:

  • Would 'git' also be a possible candidate? Needs to be packaged.. but in /etc/; 

git init-db
git add .
git commit -m "Initial Import"
  • Other features:

    • gitk can be used to quickly search for the suspected changes.

    • The 'repository' can be put under '/var/git/etc' (for example) using the GIT_DIR environment variable.
    • Commits can be signed.
    • Entire directory state can be stored and restored (Igor), and branching also supported, eg. Igor has to support multiple machines which generally are the same but have a few minor differences.

CategorySpec