I faced this issue down with CVS -- not SVN, but I would probably do the
same if/when I start using SVN. So anyway, the following is written as
though I do it with svn even though I haven't switched over to svn.
Yes, .svn (CVS) dirs will mess up a variety of things. Not always, but
enough to keep me from trying to control things in the OS. Well, I did
try it once, and ran away from that approach very quickly.
I chose to script a front-end... Call it os2svn for grins. The concept
is that whenever I want to control something in the OS configuration
files, I use os2svn instead of svn to do the management.
A special admin user is set up to be a member of group root to reduce
permission issues.
I side-step permissions issues by making os2svn only runnable by a
particular admin user, then I carefully configure sudo so that os2svn
is allowed to copy "unreadable" files. The admin user's home directory
has the sand box. Once copied, os2svn resets the permissions so that it
can own the file for purposes of using svn on the file, while also making
sure that the permissions are "safe" and will not allow other system users
to access the sand box. The sand box is a sparse mirror image of the OS
file space that is being version controlled. Only files that are actively
controlled are mirrored.
Very rarely I may have to add group execute permissions to root on certain
directories, and even more rarely a package will not allow this, so I have
to fudge permissions temporarily to get the file in svn - and put the
permissions back after version control operations so the server process
will not fail because it thinks I have set the permissions unsafely. I live
with this because it occurs so infrequently.
I only do a sparse version control on my OS, because I figure all I care
about is what I change. I do not bother version controlling everything.
I record how I install, what I install and that is my "baseline" that I
do not have to control because it comes straight off the CD, and I let the
package management system do its job without attempting to control the
packages. I only add a file to the svn OS mirror if I change it from the
original installed default.
I never let svn update directly to my copy... I use os2svn primarily to
document my changes. If I have to reinstall, upgrade, etc. Many, many
times I _have_ to look at the diffs to see what I want to change and
what should not be merged because of package changes. I make the OS
edits by hand by referring to os2svn diff commands and such. I can
patch or whatever, but it is up to me to have total control of the
editing of the real OS file. (I often have to stop/start server processes
anyway... so for me this is not a big deal.)
To improve my installation, I set up a secured apache site (firewalled,
localhost only access, user controlled access) so the special admin user
has access to it, but nobody else does. (I never control my shadow file,
or other files that could severely hurt my security.)
I LOVE this arrangement. I am not bothered by a little manual labor needed.
The first thing I always do when I load a new server is set up sudo/os2svn
once my base install is done. I have been controlling my OS this way on
multiple machines through multiple version upgrades, for several years
now.
All that said, os2svn does not exist. It exists as os2cvs on my systems.
It is a messy (but elegant) hack. If I were to release it, I would want to
simplify it a lot. I basically reparse all the CVS options, and I would be
"embarassed" for someone to see my hack as it is awful to maintain. For all
the scripting I've done, I must have been have asleep to do it the way I did
it. I never rewrote my "proof" of concept, but it still works and is the
best thing for me "since sliced bread".
Typical use is something like this.
$ cd /etc/httpd/conf
$ os2cvs status httpdcommon.conf
(Hmm. no status. ok, need to add the file)
$ os2cvs add httpdcommon.conf
$ sudo vi httpdcommon.conf
$ os2cvs diff httpdcommon.conf
$ os2cvs commit httpdcommon.conf
I am hardly every root when I work so that sudo logs whatever I do that
needs permission.
os2cvs does not let me specify directories (on purpose). I force myself to
do things a file at a time, but maybe one day I will change it to let me do
a mass check for modified files... shrug... hasn't been important up to
this point. It does let me glob multiple files if I want to. If there is
a command that CVS (svn) allows, os2cvs allows it, unless I have decided to
block it for some reason.
Anyway, maybe this will help you in your decision about what to do.
> -----Original Message-----
> From: Steve Seremeth [mailto:subversion@seremeth.com]
> Sent: Thursday, December 02, 2004 4:21 PM
> To: users@subversion.tigris.org
> Subject: Best Practices: SVN for configuration files - round 2
>
>
> Hello -
>
> I've been researching using Subversion for system files (*nix boxes,
> primarily) and I'm having a hard time deciding the best
> approach. What
> is everyone else doing? I have been through the archives and seen a
> number of threads about this and a lot of the same questions
> have been
> discussed with no clear solution that fills the need (some are pretty
> close).
>
> Here's one of several previous threads on this issue:
> http://subversion.tigris.org/servlets/ReadMsg?list=users&msgId=279816
>
> 2 Primary Techniques:
> 1. Your filesystem is your working copy
> 2. You clone the filesystem in the repository and use a
> different local
> directory to store your working copy other than /
>
> Both methods require that you find a way to maintain file
> ownership and
> permissions. Ross Mark's "asvn" script does a nice job of
> this (if you
> want every file in the fs checked into your repository) by
> storing this
> data in the properties of the files/dirs with pre and post svn shell
> wrappers.
>
> Option 1:
> * You have .svn dirs in your filesystem.
> - Problematic if you care at all about security because the
> "text-base" files are world readable.
> - .svn dirs may cause issues with some daemons and/or rc dirs
> * You don't have to worry about moving files around and reverting
> becomes an easy task
>
> Option 2:
> * You _do_ have to worry about moving files around (not a big deal)
> * Doesn't solve the security issue. If you place the working
> copy in a
> place where only root can read it, everyone else can't check files in
> and out of the repository
>
> I'm probably going to just write something similar to Ross'
> script that
> stores the permissions/ownership in the file properties, but the
> remaining issues are:
> * Where do I locate the working copy? Do I end up doing a
> working copy
> for root-owned files and another for everything else? That
> seems pretty
> gross.
> * Is there a way to handle security in such a way that
> everyone can see
> what they need to see and only that?
>
> The handful of admins who would be using this all login as themselves
> and then su, so capturing their usernames for repository
> authentication
> (as themselves for auditing) shouldn't be a big deal. I know
> subversion
> wasn't designed for this, but if I get it working correctly,
> it's going
> to solve a big problem.
>
> Thanks for any advice -
>
> Steve
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
> CONFIDENTIAL/PROPRIETARY
>
> Unless otherwise indicated, all information (including
> attachments) contained in this e-mail communication is
> confidential and proprietary information exclusively owned by
> the sender and/or its related or affiliated companies and
> shall not, without the prior written consent of the sender,
> be used, disclosed, distributed or reproduced, in whole or in
> part, by anyone other than the individual or entity to whom
> this communication is addressed exclusively for the purpose
> expressly indicated in this communication.
>
> This e-mail communication is intended for the use of the
> individual or entity to whom it is addressed. If you are not
> the intended recipient of this communication, you are hereby
> notified that any use, dissemination, distribution or copying
> of this communication is strictly prohibited. If you have
> received this communication in error, please destroy any
> copies, electronic, paper or otherwise that you may have.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 3 00:13:05 2004