VersionControlledEtc

Differences between revisions 8 and 9
Revision 8 as of 2006-05-17 15:48:00
Size: 1979
Editor: zender
Comment: changed my name
Revision 9 as of 2006-05-18 11:01:46
Size: 2198
Editor: zender
Comment: added a use case.
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
# 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 # 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.

# 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.

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

# 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.

# 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.

# 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

Data preservation and migration

Outstanding issues

* Depending on implimentation files modified by a user could fail to be updated in VCS BR* Automating this process at the dpkg level would be highly intrusive. BR* is bzr the right choice? I think it is, but what do I know?!

BoF agenda and discussion


CategorySpec

VersionControlledEtc (last edited 2010-09-23 04:17:25 by dhcp198-158)