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