Using Version Control For Your /etc Directory With etckeeper And Bazaar On Debian Squeeze

Want to support HowtoForge? Become a subscriber!
 
Submitted by falko (Contact Author) (Forums) on Wed, 2011-07-13 16:19. :: Debian

Using Version Control For Your /etc Directory With etckeeper And Bazaar On Debian Squeeze

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Follow me on Twitter
Last edited 07/12/2011

This tutorial explains how you can store the contents of your /etc directory in a version control system (VCS) with the help of etckeeper on Debian Squeeze. etckeeper hooks into Debian's package manager apt so that whenever you install/remove a package with apt, etckeeper will commit all changes to the /etc directory to your VCS; it also tracks file metadata such as permissions which is important for files such as /etc/shadow. Using etckeeper, you can go back to a previous version of /etc if an update has overwritten valuable configuration files. Not only will etckeeper track apt's changes to /etc, it will also do a daily auto-commit so that your manual changes go to VCS as well; in addition to that, you can do commits at any time manually.

I do not issue any guarantee that this will work for you!

 

1 Preliminary Note

I will use Bazaar (bzr) as the VCS in this tutorial, although git, hg, and darcs are supported as well. You can read up on Bazaar in this tutorial: Using The Bazaar Version Control System (VCS) On Debian Etch

 

2 Installing And Configuring etckeeper

etckeeper and Bazaar can be installed as follows:

apt-get install etckeeper bzr

Next open /etc/etckeeper/etckeeper.conf...

vi /etc/etckeeper/etckeeper.conf

... and uncomment the line VCS="bzr" (make sure all other VCS lines are commented out):

# The VCS to use.
#VCS="hg"
#VCS="git"
VCS="bzr"
#VCS="darcs"

# Options passed to git commit when run by etckeeper.
GIT_COMMIT_OPTIONS=""

# Options passed to hg commit when run by etckeeper.
HG_COMMIT_OPTIONS=""

# Options passed to bzr commit when run by etckeeper.
BZR_COMMIT_OPTIONS=""

# Options passed to darcs record when run by etckeeper.
DARCS_COMMIT_OPTIONS="-a"

# Uncomment to avoid etckeeper committing existing changes
# to /etc automatically once per day.
#AVOID_DAILY_AUTOCOMMITS=1

# Uncomment to avoid etckeeper committing existing changes to
# /etc before installation. It will cancel the installation,
# so you can commit the changes by hand.
#AVOID_COMMIT_BEFORE_INSTALL=1

# The high-level package manager that's being used.
# (apt, pacman-g2, yum etc)
HIGHLEVEL_PACKAGE_MANAGER=apt

# The low-level package manager that's being used.
# (dpkg, rpm, pacman-g2, etc)
LOWLEVEL_PACKAGE_MANAGER=dpkg

Please leave all other lines in their original state - havving the line AVOID_DAILY_AUTOCOMMITS=1 commented out will etckeeper make a daily autocommit of /etc, and having the line AVOID_COMMIT_BEFORE_INSTALL=1 commented out will etckeeper make commit existing changes to /etc before you install packages with apt.

To initialize etckeeper, simply run:

etckeeper init

(You can undo this by running

etckeeper uninit

but this will remove VCS information and etckeeper's own bookkeeping information. A typical use case would be to run etckeeper uninit, then modify /etc/etckeeper/etckeeper.conf - for example, because you want to use another VCS system - and finally run etckeeper init again. Please keep in mind that all VCS information will be lost when you run etckeeper uninit!)

etckeeper will do the first commit automatically when you install a package with apt that modifies the /etc directory, but it is also possible to do the first commit manually:

etckeeper commit "Initial commit"

You can always do commits manually with the etckeeper commit command, followed by a log message ("Initial commit" in this case).

 

3 Using etckeeper

Now let's assume we use apt to install a package that modifies the /etc directory (such as fail2ban):

apt-get install fail2ban

If you take a look at the output, you will see that etckeeper does commits before and at the end of the installation:

[...]
added logrotate.d/fail2ban
added rc0.d/K01fail2ban
added rc1.d/K01fail2ban
added rc2.d/S18fail2ban
added rc3.d/S18fail2ban
added rc4.d/S18fail2ban
added rc5.d/S18fail2ban
added rc6.d/K01fail2ban
Committed revision 2.
root@server1:~#

We can also do manual commits with etckeeper, e.g. after we have modified a file manually. Let's assume we have modified /etc/hosts. Using the command

bzr status /etc/

we can see what files have changed since the last commit:

root@server1:~# bzr status /etc/
modified:
  hosts
root@server1:~#

As shown at the end of chapter 2, we can commit changes using the etckeeper commit command, e.g.:

etckeeper commit "Changed /etc/hosts"

root@server1:~# etckeeper commit "Changed /etc/hosts"
Committing to: /etc/
modified hosts
Committed revision 3.
root@server1:~#

 

4 Reverting Changes

Using Bazaar, it is possible to go back to a previous version (revision) of the /etc directory, for example if a package installation has overwritten a configuration file that you had edited manually before.

To go back to a previous revision, we need to know its revision number. We can find it out with the bzr log command followed by a file or directory name, for example

bzr log /etc/hosts

will show all revisions where /etc/hosts is affected (revno 1, 3, 4, 5):

root@server1:~# bzr log /etc/hosts
------------------------------------------------------------
revno: 5
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 17:00:22 +0200
message:
  Changed /etc/hosts
------------------------------------------------------------
revno: 4
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 16:59:03 +0200
message:
  Changed /etc/hosts
------------------------------------------------------------
revno: 3
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 16:45:21 +0200
message:
  Changed /etc/hosts
------------------------------------------------------------
revno: 1
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 16:43:39 +0200
message:
  saving uncommitted changes in /etc prior to apt run
root@server1:~#

bzr log /etc

will show all revisions for the /etc directory:

root@server1:~# bzr log /etc
------------------------------------------------------------
revno: 5
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 17:00:22 +0200
message:
  Changed /etc/hosts
------------------------------------------------------------
revno: 4
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 16:59:03 +0200
message:
  Changed /etc/hosts
------------------------------------------------------------
revno: 3
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 16:45:21 +0200
message:
  Changed /etc/hosts
------------------------------------------------------------
revno: 2
committer: root <root@server1.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 16:43:50 +0200
message:
  committing changes in /etc after apt run

  Package changes:
  +fail2ban 0.8.4-3
------------------------------------------------------------
revno: 1
committer: root <root@server1.example.com.example.com>
branch nick: server1.example.com /etc repository
timestamp: Tue 2011-07-12 16:43:39 +0200
message:
  saving uncommitted changes in /etc prior to apt run
root@server1:~#

Let's say we want to revert /etc/hosts to revision 3, we can do it as follows:

bzr revert --revision 3 /etc/hosts

If you want to revert the whole /etc directory, e.g. to revision 2, this can be achieved as follows:

bzr revert --revision 2 /etc

 

5 Links


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Senthil (not registered) on Sat, 2013-07-06 15:25.

Below is a link to the same topic that might be useful:

http://tech.snathan.org/tech/svn/using_subversion_to_version_control_etc

It has a script at the end to automate most of the tasks for accomplish this.

Submitted by Markus Gattol (not registered) on Thu, 2011-07-14 04:23.
Good article, I've written the same with git as etckeeper's backend: http://www.markus-gattol.name/ws/scm.html#etckeeper