I attempted this myself a few years ago, and also ran into a lot of problems. One of the biggest problems is SVN itself -- it dumps .svn directories and internal files all over the place, which wreaked havoc on directories like modprobe.d which didn't properly ignore dot files. You'd probably have better luck from the start using a tool that doesn't crap all over everything in the directory tree.
We wound up writing our own tool that creates a copy of every file we want to watch in a separate location, and keeps that location under revision control. A script runs every night and emails out the diffs before auto-committing them to the local repo. I think etckeeper probably works in a similar way, and since it's a real package instead of a home-grown script, it's probably a better way to go (plus it tracks file metadata). We also have this combined with tools like AIDE that will tell us that something changed (though not what exact change was made), even if it's not specifically tracked in revision control. We are also moving to use Puppet, but it's a different tool that solves a different problem. Puppet is used to push out configs, and a tool like this is used to verify that the changes were made correctly. You can't rely on the same tool to do both jobs (execute and audit changes), if you want to maximize the amount of confidence you put into your systems. It's always better to have some kind of independent audit going on. ❧ Brian Mathis On Sat, Apr 20, 2013 at 9:28 AM, Edward Ned Harvey (lopser) < lop...@nedharvey.com> wrote: > I recently thought it would be a good idea to version control the /etc > directory. Using subversion, I added and committed ... and all hell broke > loose.**** > > ** ** > > It seems, for some god unforsaken reason, during a commit, svn will copy > (or link?) the file being committed, read the temp copy, and then move that > file back into place, clobbering the original file. This is so obscure, > I've never noticed it before - but it has the net effect of clobbering > whatever file permissions happened to be there before. Naturally, in the > /etc directory, that destroys the world. The first thing after commit, > sudo wouldn't work anymore (permissions should be 444, are 644, abort) > which effectively meant the machine got bricked. (It's an amazon machine, > so by default you can't become root; you must rely on sudo). Fortunately I > had just created a snapshot, so it was easy to revert... But still. This > behavior caught me *very* much by surprise.**** > > ** ** > > Question is: What do you use to version control permission sensitive > files? Subversion doesn't give a damn about permissions, so even after I > clean up this mess, I think I should probably avoid it. **** > > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
