You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Locke <ma...@freelock.com> on 2003/08/12 18:28:57 UTC
Best practices: managing configuration files
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.
Any other solution, or preferred way of doing this? Is there any
security considerations I should be thinking about here, storing
sensitive files like /etc/passwd & /etc/shadow, private keys, etc. in a
repository, as long as I lock it down? Any issues running svn as root in
the /etc directory?
Finally, I'm finding managing branches to be a bit confusing. When I add
a second server, with most configuration files identical, but a few
different, what's the best way to manage the common files so that I can
commit a change to something like a PAM module on one server, and update
the other servers? I'm thinking it involves checking out specific files
that vary from server to server from the correct branch for the server,
and then checking out the common files from the main branch--but how do
I do this without bringing the server down in the process?
If anybody is using Subversion to manage these types of files, I'd
appreciate your comments...
Thanks
John Locke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best practices: managing configuration files
Posted by Jack Repenning <jr...@collab.net>.
At 11:28 AM -0700 8/12/03, John Locke wrote:
>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?
Well, doing this directly in such a critical place as /etc gives me
the willies, but it's your neck, I suppose. I can, anyway, help with
the "check it back out on top of itself" problem. Do this one time;
after that, svn will work directly on the files:
svn co http://host/wherever/whatever/etc /tmp/etc # check out temp copy
cd /tmp/etc
find . | cpio -pdlmuv /etc
I'm assuming here that /etc and /tmp are on the same partition; in
that case, the "-l" makes cpio merely link the files, not copy them.
If your /tmp and /etc are not on the same partition (my, you *are*
adventurous, aren't you?), then put the one-time checkout somewhere
on the same ptn as /etc. It could be, say /etc/svn-etc-tmp.
And, of course, you'll need to do all this as root, since it *is* /etc and all.
You might want to pause between that "svn co" and that "find|cpio" to
compare the two directories vewy, VEEEEWY cawfully, checking that all
the expected files and directories exist, that their contents are
identical, and that their permissions are identical. If that ain't
so, don't proceed!
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best practices: managing configuration files
Posted by Ross Mark <ro...@controllingedge.com.au>.
Jack Repenning wrote:
> At 3:02 PM -0700 8/13/03, John Locke wrote:
>
>>
>> So, aside from the security issues surrounding the repository, and as
>> long as I get it set up correctly, does anyone see any major
>> drawbacks to making /etc a working copy?
>
>
> I don't think SVN is in the business of preserving file ownership. If
> you do this stuff as root, they'll all come out owned by root.
> Depending on your system, there might be some that would rather be
> owned by some other user, like "mail" or "httpd" or something. Same
> observation about group. I even wonder about the more exotic
> permissions, like set-uid and sticky and such.
>
>> I haven't dug around in the private .svn directory all that much--is
>> there a security risk involved in having these files in the /etc
>> filesystem?
>
>
> There's a good question. Looks like the text-base files are always
> world-readable. There are a few files in /etc that should not be
> world-readable. I think that's a killer for you right there.
I posted a wrapper script a few days ago
http://www.contactor.se/~dast/svnusers/archive-2003-08/0255.shtml
<http://www.contactor.se/%7Edast/svnusers/archive-2003-08/0255.shtml>
which would handle the file permission's ownerships plus the symlinks
that /etc is full of. I've been using it for a few months to maintain
and version entire filesystems (not just /etc) be-it small ones for
embedded system :-) The only problem I find is if you place /lib/modules
under svn depmod has problems as it tries to resolve the dependencies of
the text-base files aswell.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best practices: managing configuration files
Posted by Jack Repenning <jr...@collab.net>.
At 3:02 PM -0700 8/13/03, John Locke wrote:
>
>So, aside from the security issues surrounding the repository, and
>as long as I get it set up correctly, does anyone see any major
>drawbacks to making /etc a working copy?
I don't think SVN is in the business of preserving file ownership.
If you do this stuff as root, they'll all come out owned by root.
Depending on your system, there might be some that would rather be
owned by some other user, like "mail" or "httpd" or something. Same
observation about group. I even wonder about the more exotic
permissions, like set-uid and sticky and such.
>I haven't dug around in the private .svn directory all that much--is
>there a security risk involved in having these files in the /etc
>filesystem?
There's a good question. Looks like the text-base files are always
world-readable. There are a few files in /etc that should not be
world-readable. I think that's a killer for you right there.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best practices: managing configuration files
Posted by John Locke <ma...@freelock.com>.
Thanks for the tips, all. Yes, I'm nervous about doing this sort of
thing as root, right where a mistake could do the most damage. The thing
is, I'm setting up all kinds of systems right now, and being able to
back up a revision or two when I screw up would be invaluable.
So, aside from the security issues surrounding the repository, and as
long as I get it set up correctly, does anyone see any major drawbacks
to making /etc a working copy? I haven't dug around in the private .svn
directory all that much--is there a security risk involved in having
these files in the /etc filesystem?
A couple other questions and comments below.
Scott Lamb wrote:
> 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.
>
>
> 3. Set up symlinks. Most stuff should follow them happily.
Not sure what you mean here--you mean replace the real files in /etc
with symlinks to a wc in /root? Or vice versa?
> 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:
>
>
> 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.
... but you can svn revert httpd.conf... how many times would that have
been handy!
Finally, Dan Mercer dropped me a line about a Collab.net project for
managing Linux/Solaris configurations that sounds intriguing.
Cheers,
John Locke
Owner, Freelock, LLC
Small Business Computing with Open Source
http://www.freelock.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best practices: managing configuration files
Posted by Scott Lamb <sl...@slamb.org>.
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