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

The etckeeper chronicles, part 3

In the previous episodes of the etckeeper chronicles, we have covered basic usage and features of etckeeper in Jaunty, which hopefully showed how great it can be. In today’s episode though, we’ll have a look on its shortcomings, and how we can improve the solution to solve them in the future.

File permissions and ownership

One of the features etckeeper provides is tracking changes to file permissions and user/group ownership metadata. Revision control systems usually only consider changes in file contents. bzr additionally tracks the executable bit. So etckeeper covers the rest by maintaining a /etc/.etckeeper text file that lists files with unusual values. That way, you can tell the changes in metadata by looking at the changes in .etckeeper. This is, however, not really integrated in the output of the tools.

A confusing diff, an incomplete revert

Let’s take an example. If you change permissions to a file, the diff will not tell you that this precise file has changed, but that the .etckeeper file changed:

$ ls -l /etc/default/tomcat6
-rw-r--r-- 1 root root 1269 2009-02-27 18:50 /etc/default/tomcat6
$ sudo chgrp tomcat6 /etc/default/tomcat6
$ sudo chmod g+w /etc/default/tomcat6
$ sudo etckeeper commit "Make tomcat6 init config group-writeable"
$ sudo bzr diff -c-1 /etc | lsdiff
.etckeeper
 

This can be confusing. And if you revert the change, you won’t really come back to the previous state…

$ sudo bzr revert -r-2 /etc/default/tomcat6
$ ls -l /etc/default/tomcat6
-rw-rw-r-- 1 root tomcat6 1269 2009-02-27 18:50 /etc/default/tomcat6
 

This is incomplete. You restore the file contents alright, but you need to manually check the permissions in .etckeeper and restore them appropriately…

bzr integration to the rescue

So the problem is that the VCS used basically ignores the .etckeeper file contents. We need to make it aware of it. That’s where the bzr etckeeper plugin, which currently only ensures that the .etckeeper file contents is refreshed before every commit, can be improved. It could also extend the “bzr diff” and “bzr revert” commands so that they integrate metadata changes by taking into account .etckeeper changes. That’s the next step, something I plan to work on in the next months and that should be ready for Karmic Koala !

Want to help ?

Please test, file bugs, ask for new interesting features ! Blog about it ! If you want to participate in development, join the etckeeper hackers group on Launchpad, follow the bugs filed on etckeeper

In next episode

In the last part of the etckeeper chronicles, we’ll imagine new features and uses for etckeeper in the future…

Categories: Ubuntu, Ubuntu Server
  1. eythian
    March 2, 2009 at 12:35

    Where would I find the bzr etckeeper plugin? It doesn’t seem to be mentioned in the etckeeper LP project, and google is no help either.

    • Thierry Carrez
      March 2, 2009 at 12:51

      @eythian: it’s installed by “etckeeper” itself, no need to install another package.

  2. March 2, 2009 at 15:00

    Great articles, etckeeper is a very handy tool.

    I went to an Ottawa/Carelton LUG meeting recently where there was a talk about etckeeper: http://oclug.on.ca/meeting/37/

    Unfortunately, I can’t find slides from the talk, but much of the talk was about using the distributed version control to clone configs for new machines, create remote backups etc.

    It would be good to see an article on these aspects of etckeeper.

  3. Matt Mossholder
    March 6, 2009 at 04:36

    Wouldn’t the “more sane” method of handling the permissions/ownership issue be to add the capability to bzr/git/etc? It is great that there are workarounds, but it kind of seems like the root cause is being overlooked…

  4. Thierry Carrez
    March 6, 2009 at 08:33

    @Matt: that was my original line of thought. It would have been cleaner that way. But pushing new features into a VCS mainline is difficult. Also wrapping the VCS calls inside etckeeper allows to do extra stuff as well. “etckeeper commit” for example adds all missing files (does bzr add + bzr commit). And as we continue adding features (see part 4), we can continue to improve the plugin with functionality that wouldn’t make sense at all in bzr mainline. So it’s more open-ended.

  5. June 11, 2009 at 12:47

    fsvs is a similar package to etckeeper (http://fsvs.tigris.org/) unfortunately built on top of subversion. But it seems to handle file properties in a better way i.e. without patching some strange file…

  1. No trackbacks yet.

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