Home > Ubuntu, Ubuntu Server > The etckeeper chronicles, part 4

The etckeeper chronicles, part 4

In the previous episodes of the etckeeper chronicles, we saw how useful etckeeper can (and could) be in its current form. For this last episode, let’s project ourselves in the future and imagine new use cases etckeeper could cover. While reading this braindump, please keep in mind some of these ideas are pretty close, some others would certainly require lots of work, and some others are probably plain stupid.

Pristine configuration branch

It’s interesting to be able to see what the original configuration files for a package looks like and be able to compare them to what you’re currently running. This is especially true once you start updating the package and keep using the same configuration file. This could be done by maintaining a specific branch of /etc containing the pristine configuration files as they would be installed by the package. All configuration merges could then be handled using branch merging features…

Configuration file integrity

Since we are tracking file differences, we are not that far away from what Tripwire does. We could have etckeeper “lock” and “unlock” commands that would prevent commits and notify you if files were modified while the lock was in place. That would certainly involve some bzr repository encryption. Being limited to /etc, this wouldn’t make sense as an intrusion detection system, but it might make sense as a policy compliance tool (no configuration change between 6am and 8pm ?). All in all, that’s an interesting area I want to investigate.

Showing installed package changes

When autocommitting APT changes, etckeeper currently shows (in the commit message) what packages were changed. This works as long as there is some /etc file change in the process. But it could maintain, in the same way it maintains the .etckeeper file, a list of packages installed. That way, any package changes would appear in the history. Comparing etckeeper branches would then also clearly show differences in package installed between two systems, making it more relevant.

One step farther, imagine if etckeeper (through more bzr integration) would also adjust packages installed whenever a revision gets restored to /etc. You could roll back your system (seen as packages installed + configuration applied) to a previous point in time. You could “branch” the configuration from an existing server and get everything but raw data in place.

Pushing your etckeeper branches on a management server

Once your complete system configuration is represented as a bzr branch, why not take advantage of more DVCS capabilities ? Pushing all your etckeeper bzr branches to a central location allows to keep a global picture of your systems configuration and to compare how they diverge in time. You could apply the same change to several servers. Imagine testing by branching your servers, and rolling back to production by merging the changes…

Other ideas ?

If you have another interesting, innovative way we could use etckeeper for (even if it implies some development), please add a comment to this article ! I’d love to hear from you and get new ideas from the community. I’ll keep you posted on this blog about any new etckeeper development in the future. Thank you for following these chronicles !

About these ads
Categories: Ubuntu, Ubuntu Server
  1. Eetu
    March 5, 2009 at 12:41 | #1

    Is it already possible to use etckeeper to control versions of configuration files under other directories than /etc? If not, that’s a feature which would make it a lot more interesting.

  2. T0m
    March 5, 2009 at 12:46 | #3

    Maybe etckeeper should be standard in Ubuntu?

  3. March 5, 2009 at 19:40 | #4

    I had developed something akin your #3 request, I just put it online at http://www.0d.be/vrac/bzr-apt

    It makes entries like this:

    revno: 232
    committer: …
    branch nick: etc
    timestamp: Wed 2009-01-21 15:38:17 +0100
    message:
    – upgrade of login from 1:4.0.18.1-7 to 1:4.0.18.1-7+etch1
    – upgrade of passwd from 1:4.0.18.1-7 to 1:4.0.18.1-7+etch1

    As I started upgrading my servers to lenny, I switched to etckeeper and didn’t have the time yet to integrate my script.

  4. March 6, 2009 at 00:35 | #5

    Seconding tracking of extra directories.

    Examples of interesting (mostly configuration) files outside /etc:

    /var/lib/buildbot/masters/$somename/master.cfg
    /opt/some-trac-instance/etc
    /srv/svn-repos/some-repo/hooks
    /usr/local/sbin/script-I-run-from-cron

    The first three could be handled via symlinks to some place under /etc, but I don’t know what to do about custom sysadmin scripts.

  5. Thierry Carrez
    March 6, 2009 at 08:24 | #6

    @TOm: yes, I tend to think it would make a good default. It needs to be made a little more foolproof and user-friendly (see part 3), but that’s something I’d like.

    @Frederic Peters: Sounds great ! I’ll have a look very soon. You could submit it directly to Joey Hess through the Debian bts, he is very open to new features !

  6. eythian
    March 7, 2009 at 10:42 | #7

    One I think would be useful for machines with multiple admins would be an easy way of having a daily email of the changes on the machine. A summary at the top with the commit messages, and below that the diffs.

  7. Lolz
    March 16, 2009 at 22:06 | #8

    +1 for etckeeper

    Why not git instead of bzr?

  8. June 11, 2009 at 12:47 | #9

    fsvs is a similar package to etckeeper (http://fsvs.tigris.org/) unfortunately built on top of subversion.

    I’ve used it to handle /var/www and other parts of a filesystem (as well as bits of my home directory) with relative ease

  9. September 28, 2009 at 23:32 | #10

    @Thierry, Frederic: re: “Showing installed package changes” item…

    I use http://wajig.togaware.com/ for most Ubuntu sysadmin tasks (incl. package installation/removal/etc). Its “listlog” subcommand produces output similar to what you’re discussing:

    —snip
    2005-04-24 08:05 upgrade usbutils 0.70-8
    2005-04-24 08:05 upgrade xwine 1.0.1-1
    2005-04-24 08:22 install libstatgrab5 0.11.1-2
    2005-04-24 08:22 install saidar 0.11.1-2
    2005-04-27 06:42 install python-pychart 1.37-1
    2005-04-27 06:42 install python2.3-pychart 1.37-1
    —snip

    - http://linux.togaware.com/survivor/Logging_Installation.html

    Thanks for the helpful series of articles :]

    -Tyler

  1. May 13, 2009 at 19:43 | #1
  2. May 14, 2009 at 07:15 | #2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 33 other followers