The etckeeper chronicles, part 2

In the previous episode, we’ve covered installation and basic usage of etckeeper. One common argument against having /etc under revision control is that it’s rather tedious to commit changes every time you change the configuration. While this is indeed desirable (in order to get a change history that makes sense), etckeeper on Jaunty has a few features that really help in that area.

Autocommitting changes due to package installation/upgrade

Whenever you install, remove or upgrade packages, /etc contents may change. Rather than forcing you to commit those changes manually, etckeeper has a cool APT integration feature that does it for you. It even automatically commits any uncommitted change before the apt run so that you can really tell what changed. Let’s try that:

$ sudo apt-get upgrade
[...]
Committing to: /etc/                          
modified lsb-base-logging.sh
Committed revision 3.
$ sudo bzr log /etc
------------------------------------------------------------
revno: 3
committer: thc 
branch nick: jaunty-test /etc repository
timestamp: Sun 2009-02-22 11:36:29 +0000
message:
  committing changes in /etc after apt run
  
  Package changes:
  -lsb-base 3.2-20ubuntu2
  -lsb-release 3.2-20ubuntu2
  +lsb-base 3.2-20ubuntu3
  +lsb-release 3.2-20ubuntu3
[...]
 

No more cold sweat during upgrades !

Daily autocommits

Some lazy folks forget to commit their changes. Or they just don’t want to care about it. How about being able to get a day-by-day history of configuration file changes without ever manually committing anything ? That’s where the recently-added daily autocommit saves the day. It will catch uncommitted changes every night and autocommit them for you:

$ sudo bzr log --line /etc
4: root 2009-02-23 daily autocommit
3: thc 2009-02-22 committing changes in /etc after apt run
2: thc 2009-02-22 Change domain name to mycompany.com
1: thc 2009-02-22 Initial commit
 

Don’t want those autocommits to potentially mess up your well-maintained commit history ? You can easily disable them in /etc/etckeeper/etckeeper.conf.

etckeeper by default ?

With these two options enabled by default, without any specific user interaction, you can automatically build a nice history of the changes made by package installs or day-by-day by the user. You don’t really need to care about it, and this history will be ready for you the day you need it.

That makes etckeeper something that could be installed by default, for example on server installs. The user could completely ignore it until the day he needs it, and discover that during all that time etckeeper automatically logged everything.

In next episode

In part 3 of the etckeeper chronicles we’ll expose the current limitations of etckeeper and the future work planned to overcome them. Stay tuned !