Package: etckeeper Version: 0.45 Severity: wishlist User: debian-edu@lists.debian.org UserTags: debian-edu When several system administrators work on the same machine, and when changes in /etc/ can happen automatically based on cfengine runs or cron jobs, it is very useful to be able to see when in the day a change was introduced in /etc/ without depending on manual commits. With etcinsvk, a cron job was set up to run every hour to automatically commit all changes in /etc/, and this has been very valuable to me when trying to figure out what caused a configuration problem. I notice etckeeper support daily autocommits, but would it be possible to add support for an hourly autocommit too? Happy hacking,
Petter Reinholdtsen wrote: All you need is to symlink /etc/cron.daily/etckeeper to cron.hourly, if you want that.
[Joey Hess] Sure, that is possible. But I need a solution that allowed hourly autocommits to be enabled by preseeding the package, to get it working out of the box after installation without any editing in /etc/ after the installation. In Debian Edu, we try to avoid post-installation editing of configuration, and etckeeper is on our wishlist for the next release. Happy hacking,
May I ask why you do not want hourly autocommits, when you find daily autocommits OK? Here at the university it is a lot easier to figure out who did a specific change when we are able to ask "who changed file X on machine Y between 13 and 14 yesterday", than when we ask "who changed file X on machine Y yesterday". Making it easier to figure out who did a specific change is my motivation for asking for hourly autocommits. More than hourly resolution is not really needed, as people in my experience do not recollect exactly which minute of the hour they did something in the past, but migth have some idea about what period of the day they worked on something. Happy hacking,
Petter Reinholdtsen wrote: There are a few reasons. One is that it's not uncommon for files like /etc/resolv.conf to change automatically, and easy to forget to add those files to .gitignore (or not want to), so hourly autocommits would be a lot more commits to wade through in the log. Another reason is that the daily cron job tends to run when the system is quiesent, so the admin is probably not in the middle of configuring something in /etc. It could be unexpected for /etc to commit itself if you're preparing a change and actively using etckeeper at the time.
Petter Reinholdtsen wrote: Also, in most cases to find out when a file was changed, ls is sufficient.
Control: tags -1 +wontfix overkill, and I think the daily policy is a fine default. Besides, it's policy: if we change it to hourly, someone will yell that we should change it back to daily. :) Since you use cfengine, you should be able to easily change that configuration, and it will be retained on upgrades. Furthermore, I encourage you to install pre/post hooks in your configuration management engine instead of relying on cron jobs. For example, at work, we have the following hooks in our puppet client configuration: prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post both hooks basically call "etckeeper commit" after ensuring the environment is sane. A.