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…