John Locke wrote:
> Okay. I'm trying to figure out the best way to manage configuration
> files in a couple of Linux servers. I'd like to be able to roll back
> configuration changes if I do something that breaks the configuration.
>
> I was able to import the whole /etc directory into Subversion, but I
> can't seem to easily check it back out in place. In other words, I can't
> make the original directory a working copy using Subversion. Am I
> overlooking something?
>
> So it seems my alternatives are:
>
> 1. Maintain a mirrored working copy of the /etc directory somewhere
> else, and sync any changes to that.
>
> 2. Check out a working copy, then copy that to /etc to add version control.
3. Set up symlinks. Most stuff should follow them happily.
You have to be a bit careful with how you manage the permissions and how
you commit as root. Cut'n'pasted from an earlier email of mine on this
subject:
- root's homedir (or wherever the working copy is) needs traverse
permissions for whatever users/groups the servers run as; you might not
like that.
- you need to be careful about a few config files.
/etc/openldap/slapd.conf can have the root DN password in it. In a
one-way hash, but still, crackers exist.
- root needs to be able to access the Subversion repository through some
ra_XXX mechanism.
You can use ra_dav...but not if you want the Apache config files in
there, because if you screw them up, you can't just "svn up" to get a
fresh version.
You can use ra_file...but root's default umask is restrictive enough
that other users can't mess with it, even if you put the repository in a
setgid directory (no group write). The umask shouldn't really be messed
with; it's there for a reason.
You can use ra_svn+ssh, sshing to a normal user. This is probably the
best solution, but it's kind of annoying to set up. You can still
version your Apache files without problem, and you don't have to screw
around with permissions a lot.
If you figure out good ways around these problems, I'd like to know. I'm
keeping config files in Subversion, too.
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 13 04:00:45 2003