Some people would like etckeeper to be able to track multiple directories,
not just /etc.
There have been 2 patches proposed:
Personally, this seems unnecessary complication and unnecessary widening
of scope to me.
Allright, here's my use case.
I have some applications i develop, where others now and then update its configurations. These applications may be installed using the packaging system in use on that machine (we make RPM and DEB packages), and that the accompaning "configuration files" might include templates, customer configuration files, documentation, and lots of other things that are deemed safe by $bosses to be "safe for editing". Some of these files are in /etc, most are not. The important thing is that they are regular text files.I'
I also have some other regular services that have all their important/useful files outside /etc (e.g. our BIND installation, which has their zone files deep in some directory in /usr/local/etc somewhere). I'd like to track changes in those files too, with the useful features etckeeper do so well.
For me, the important thing is to make sure that when someone does something stupid (as people sometimes do, myself included), that we have an easy undo facility to rely on. I think etckeeper would fit this role nicely, because etckeeper helps checking for uncommitted files in lots of useful situations, and does the committing if some of us happen to forget to do it. This means we get to have an "undo button" that actually WORKS (since stuff is actually committed!). I like that.
Now, how would this actually be managed by etckeeper? No idea, but I'm happy to help and have a conversation around this. Maybe the best way is to allow for several etckeeper "instances" to run independently. Maybe it's a simple feature for defining a list of directories to check...
Hope this gives you an idea of what I tried to do with my pull request at https://github.com/joeyh/etckeeper/pull/2
Yes, it's easy to put everything in /etc. But sometimes it's also wrong to do so (eg. for templates, some application-specific config, app localization files, etc.). And sometimes it's not possible to do so (eg. for 3rd party applications where we need to keep track of changes). Sometimes I (the dev/admin) have full control of the workflow, other times I don't. There's a LOT of crazy stuff out there (not all in /etc), and having something like etckeeper help keep track of changes would make life a lot easier for people.
But perhaps more importantly, there are people out there (myself included) who would love to use etckeeper in this way, but who would prefer this feature was committed to "upstream" (your git repo) instead of having to manage a fork of the project in order to get things done.
I hope you understand.
It seems to me that this would be particularly useful for narrowly scoped intrusion detection.
For example, if I have an installed instance of a popular web app (Wordpress, Django, what have you) that is compromised (SQL injection, brute force, etcetera), every part of that app may become suspect even after the initial vulnerability is patched...in which case, a versioned log of what files were changed within the app directory(s) would be extremely useful.
This is very much needed!
Example of some folders in debian/ubuntu that people want to keep track of:
/var/spool/cron/crontabs - user crontabs, yes you can use /etc/cron.d but not everyone does.
/lib/ufw/ - If you use ufw, the rules will be saved here
/usr/local/bin - for your own shellscripts and stuff
Please take a look:
I tried to add support for multiple dirs for all commands, and leave it compatible with default old config and cli.
This feature may be useful when you want to have more control on your system. There are other locations which do contain config/code that may be changed, and affects system, e.g.:
python code at /usr/lib/python2.7/dist-packages/
pacemaker scripts at /usr/lib/ocf/resource.d/fuel
libvirt vms xmls at /var/lib/nova/instances//.xml
You already have -d support, now can you do, please, another step to track multiple dirs by adding cycle into /etc/cron.daily/etckeeper which would commit from multiple dirs. This could be variable in /etc/etckeeper/etckeeper.conf, for example ADD_DIRS="/usr/local/etc /boot/grub", and cron.daily script could just for dir in $ADD_DIRS and commit -d $dir them all. This requires just few lines to acquire such great functionality.
for dir in $ADD_DIRS
commit -d $dir
For example, /etc/grub2.cfg is very important for the health of a system and it's never tracked by etckeeper by default because it's symlink to /boot/grub2/grub.cfg. We just have another server not survive reboot after simple yum update because grub.conf got wrong lvm parameters, and we unable to track when this change was happened first time.