You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brian Mathis <bm...@directedge.com> on 2004/03/04 20:40:49 UTC
bad access methods (was: 100% repeatable repo wedging)
What you are seeing is 100%, without a doubt, a permissions problem.
You were accessing the repo using your account, and when you tried a
different account it blew up.
Having everyone in the svn group is not enough. The repo directory must
also be g+s, and also owned by the svn group. All files must be g+w,
and also umask for everyone must be 002. Even with all that, it might
not work right.
This brings me to the question of why are you using svn+ssh? Out of the
4 access methods you have to choose from, you've chosen (IMO), the 3rd
most desirable one. They are, in order of desireability:
1. http
2. svnserve daemon
3. svn+ssh
4. file
I can understand people who don't want to go through
installing/reinstalling apache. Instead of that, you should use
svnserve as a daemon. It ensures that every access is done on the repo
using the same user and group. The only time svn+ssh and file should be
used is if the repo is for a single user project.
This isn't really aimed at you, but everyone using svn+ssh or file
access methods :)
It really makes no sense to me that you could have so many different
ways to access the repo. If you look at any other multiuser database,
they all have 1 frontend that is the interface to the disk files.
Mysql, postgres, ldap, etc... Why is svn different?
Jarod Wilson wrote:
>Hi all, first post, be gentle...
>
>A little history: I work for a mixed Windows and Linux shop (mostly
>Windows). We've been using CVS for quite some time, but several
>developers complain about its shortcoming, especially with the recent
>restructuring of our source tree, which of course blew away all the
>history on many files. Said developers are partial to Perforce, but we
>are on a bit of a budget. I've done some homework, and Subversion looks
>like the ticket for us.
>
>However, what looks good on paper isn't translating to production very
>well. I've got Subversion 1.0 up and running from David Summer's rpms on
>a Red Hat Linux 7.2 box (which is also our CVS server), with the
>intention of using predominantly svn+ssh for access, since everyone
>already has a shell account on the machine. I was able to import our
>source tree just fine from the local machine after creating the repo,
>check out, check in, etc. When we moved over to a Windows box using
>TortoiseSVN, all hell broke loose. Basically, at least one in every two
>actions taken resulted in db errors, with a message telling us to run
>DB_RUNRECOVERY.
>
>Fast forward a bit, I nuked the repo, recreated it, then did an import
>from a Windows box via TortoiseSVN. Everything looked fine. I even got
>two machines set up, both checking in, checking out, diffing, repo
>browsing, etc., simultaneously and everything (one box running Windows
>2003 Server, one running Windows 2000 Pro). Excellent, I thought.
>However, note that both machines were using my login. Then I went over
>to another developer's machine, tried his login, and got db errors
>(can't recall if they were immediate, or after a number of files had
>been checked out). Running svnadmin recover on our repo isn't even
>recovering it now. (I haven't tried using db_runrecovery directly yet).
>
>Now, I do have both a primary user and group defined for Subversion (u/g
>svn/svn), and all developers are members of the svn group, so I don't
>think I have any permissions issues, but I've been fighting this thing
>for more than a week... I'm about to try a newer BerkeleyDB (4.2, versus
>4.0 on our RHL7.2 machine) and Subversion on a Fedora Core 2 machine to
>see if it is any better, but if anyone has any insight into what my
>problem might be, I'd appreciate the help! I know everyone will REALLY
>like Subversion over CVS, once we get it running in a stable fashion.
>
>TIA,
>
>
>
--
Brian Mathis
http://directedge.com/b/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by "C.A.T.Magic" <c....@gmx.at>.
----- Original Message -----
From: "Brian Mathis" <bm...@directedge.com>
To: <us...@subversion.tigris.org>
Sent: Thursday, March 04, 2004 21:40
Subject: bad access methods (was: 100% repeatable repo wedging)
[...]
> This brings me to the question of why are you using svn+ssh? Out of the
> 4 access methods you have to choose from, you've chosen (IMO), the 3rd
> most desirable one. They are, in order of desireability:
> 1. http
> 2. svnserve daemon
> 3. svn+ssh
> 4. file
not to forget https://
> The only time svn+ssh and file should be
> used is if the repo is for a single user project.
think about data/transfer security when using
svnserve without ssh.
> This isn't really aimed at you, but everyone using svn+ssh or file
> access methods :)
i think "apache 2" is a "monster application"
( setup, dependencies, memory usage, security issues )
and probably a lot of ppl do not want that extra overhead.
> It really makes no sense to me that you could have so many different
> ways to access the repo. If you look at any other multiuser database,
> they all have 1 frontend that is the interface to the disk files.
> Mysql, postgres, ldap, etc... Why is svn different?
sounds like 'comparing apples and pears' ;-)
svn is more like a filesystem/file manager, sql etc is a database.
and there are usually many ways to access a filesystem:
http, ftp, shell, ssh/shell, windows-explorer, konquerer, tortoise, ...
and i think svn offers the best functionality for all of them.
>
>
>
> Jarod Wilson wrote:
>
> >Hi all, first post, be gentle...
> >
> >A little history: I work for a mixed Windows and Linux shop (mostly
> >Windows). We've been using CVS for quite some time, but several
> >developers complain about its shortcoming, especially with the recent
> >restructuring of our source tree, which of course blew away all the
> >history on many files. Said developers are partial to Perforce, but we
> >are on a bit of a budget. I've done some homework, and Subversion looks
> >like the ticket for us.
> >
> >However, what looks good on paper isn't translating to production very
> >well. I've got Subversion 1.0 up and running from David Summer's rpms on
> >a Red Hat Linux 7.2 box (which is also our CVS server), with the
> >intention of using predominantly svn+ssh for access, since everyone
> >already has a shell account on the machine. I was able to import our
> >source tree just fine from the local machine after creating the repo,
> >check out, check in, etc. When we moved over to a Windows box using
> >TortoiseSVN, all hell broke loose. Basically, at least one in every two
> >actions taken resulted in db errors, with a message telling us to run
> >DB_RUNRECOVERY.
> >
> >Fast forward a bit, I nuked the repo, recreated it, then did an import
> >from a Windows box via TortoiseSVN. Everything looked fine. I even got
> >two machines set up, both checking in, checking out, diffing, repo
> >browsing, etc., simultaneously and everything (one box running Windows
> >2003 Server, one running Windows 2000 Pro). Excellent, I thought.
> >However, note that both machines were using my login. Then I went over
> >to another developer's machine, tried his login, and got db errors
> >(can't recall if they were immediate, or after a number of files had
> >been checked out). Running svnadmin recover on our repo isn't even
> >recovering it now. (I haven't tried using db_runrecovery directly yet).
> >
> >Now, I do have both a primary user and group defined for Subversion (u/g
> >svn/svn), and all developers are members of the svn group, so I don't
> >think I have any permissions issues, but I've been fighting this thing
> >for more than a week... I'm about to try a newer BerkeleyDB (4.2, versus
> >4.0 on our RHL7.2 machine) and Subversion on a Fedora Core 2 machine to
> >see if it is any better, but if anyone has any insight into what my
> >problem might be, I'd appreciate the help! I know everyone will REALLY
> >like Subversion over CVS, once we get it running in a stable fashion.
> >
> >TIA,
> >
> >
> >
>
> --
> Brian Mathis
> http://directedge.com/b/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by Adrian Howard <ad...@quietstars.com>.
On 4 Mar 2004, at 20:40, Brian Mathis wrote:
[snip]
> Having everyone in the svn group is not enough. The repo directory
> must also be g+s, and also owned by the svn group. All files must be
> g+w, and also umask for everyone must be 002.
Which is what I do.
> Even with all that, it might not work right.
[snip]
Why?
[snip]
> The only time svn+ssh and file should be used is if the repo is for a
> single user project.
> This isn't really aimed at you, but everyone using svn+ssh or file
> access methods :)
[snip]
I use svn+ssh all the time for group projects. Had an existing setup
where the developers have ssh logins to the dev box to leverage. Far
easier to install and configure than Apache 2/DAV. Seems a sensible
choice to me ;-)
After setting up the permissions properly haven't had a problem since.
Is there some potential danger I'm missing that's going to bite me when
I least expect it?
Cheers,
Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by Matthew Gregan <ki...@orcon.net.nz>.
On Thu, Mar 04, 2004 at 04:22:27PM -0500, Jim Nutt wrote:
> On Fri, 5 Mar 2004 10:12:29 +1300
> Matthew Gregan <ki...@orcon.net.nz> wrote:
> > So spend an extra five minutes during the initial svnserve
> > configuration and wrap svnserve up with stunnel. I can write up and
> > post some documentation on how to do this if anybody would find it
> > useful.
> And spend the next week trying to get network ops to open yet another
> port through the firewall? I don't think so.
It was a solution to your "svnserve sans ssh isn't secure" comment.
Obviously it's not a solution for everyone-but if the reason _you_ can't
use that particular solution is because of company policy, why even
argue the point with me?
-mjg
--
Matthew Gregan |/
/| kinetik@orcon.net.nz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by Jim Nutt <ji...@nuttz.org>.
On Fri, 5 Mar 2004 10:12:29 +1300
Matthew Gregan <ki...@orcon.net.nz> wrote:
> On Thu, Mar 04, 2004 at 03:56:41PM -0500, Jim Nutt wrote:
> > That's easy. Security. svnserve sans ssh isn't secure. https is, or
> > can be, anyway, but it's not always an option.
>
> So spend an extra five minutes during the initial svnserve
> configuration and wrap svnserve up with stunnel. I can write up and
> post some documentation on how to do this if anybody would find it
> useful.
And spend the next week trying to get network ops to open yet another
port through the firewall? I don't think so.
--
jim nutt
home: jim@nuttz.org jabber: jimnutt@jabber.com
work: jimnutt@vestek.com ms msg: jim@nuttz.org
pgp id: 1ECBCC78
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by Matthew Gregan <ki...@orcon.net.nz>.
On Thu, Mar 04, 2004 at 03:56:41PM -0500, Jim Nutt wrote:
> On Thu, 04 Mar 2004 15:40:49 -0500
> Brian Mathis <bm...@directedge.com> wrote:
> > This brings me to the question of why are you using svn+ssh? Out of
> > the 4 access methods you have to choose from, you've chosen (IMO), the
> > 3rd most desirable one. They are, in order of desireability:
> > 1. http
> > 2. svnserve daemon
> > 3. svn+ssh
> > 4. file
> That's easy. Security. svnserve sans ssh isn't secure. https is, or
> can be, anyway, but it's not always an option.
So spend an extra five minutes during the initial svnserve configuration
and wrap svnserve up with stunnel. I can write up and post some
documentation on how to do this if anybody would find it useful.
-mjg
--
Matthew Gregan |/
/| kinetik@orcon.net.nz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by Adam Gibson <ag...@ptm.com>.
Why not use ssh+svnserve instead. Use the --listen-host option to
svnserve so that it only listens on the loopback interface(127.0.0.1) so
that remote users can not connect to the daemon unless they use the
forwarding ability of ssh (-L option).
That would seem to make configuration of the server easy(no permission
problems since only the user account that you use to launch svnserve
will need permissions to the files) and only allow ssh access remotely.
On Thu, 2004-03-04 at 15:56, Jim Nutt wrote:
> On Thu, 04 Mar 2004 15:40:49 -0500
> Brian Mathis <bm...@directedge.com> wrote:
>
> > This brings me to the question of why are you using svn+ssh? Out of
> > the 4 access methods you have to choose from, you've chosen (IMO), the
> > 3rd most desirable one. They are, in order of desireability:
> > 1. http
> > 2. svnserve daemon
> > 3. svn+ssh
> > 4. file
> >
> > I can understand people who don't want to go through
> > installing/reinstalling apache. Instead of that, you should use
> > svnserve as a daemon. It ensures that every access is done on the
> > repo using the same user and group. The only time svn+ssh and file
> > should be used is if the repo is for a single user project.
>
> That's easy. Security. svnserve sans ssh isn't secure. https is, or can
> be, anyway, but it's not always an option.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by Jim Nutt <ji...@nuttz.org>.
On Thu, 04 Mar 2004 15:40:49 -0500
Brian Mathis <bm...@directedge.com> wrote:
> This brings me to the question of why are you using svn+ssh? Out of
> the 4 access methods you have to choose from, you've chosen (IMO), the
> 3rd most desirable one. They are, in order of desireability:
> 1. http
> 2. svnserve daemon
> 3. svn+ssh
> 4. file
>
> I can understand people who don't want to go through
> installing/reinstalling apache. Instead of that, you should use
> svnserve as a daemon. It ensures that every access is done on the
> repo using the same user and group. The only time svn+ssh and file
> should be used is if the repo is for a single user project.
That's easy. Security. svnserve sans ssh isn't secure. https is, or can
be, anyway, but it's not always an option.
--
jim nutt
home: jim@nuttz.org jabber: jimnutt@jabber.com
work: jimnutt@vestek.com ms msg: jim@nuttz.org
pgp id: 1ECBCC78
Re: bad access methods (was: 100% repeatable repo wedging)
Posted by te...@eatoni.com.
>>>>> "Brian" == Brian Mathis <bm...@directedge.com> writes:
Brian> This brings me to the question of why are you using svn+ssh?
Brian> Out of the 4 access methods you have to choose from, you've
Brian> chosen (IMO), the 3rd most desirable one. They are, in order
Brian> of desireability:
Brian> 1. http
Brian> 2. svnserve daemon
Brian> 3. svn+ssh
Brian> 4. file
Brian> I can understand people who don't want to go through
Brian> installing/reinstalling apache. Instead of that, you should
Brian> use svnserve as a daemon. It ensures that every access is done
Brian> on the repo using the same user and group. The only time
Brian> svn+ssh and file should be used is if the repo is for a single
Brian> user project.
One reason (this is the reason I am using svn+ssh) is to minimize the
number of processes I have listening to ports on the internet at
large. This reduces risk and also means there's one less thing to
monitor bugtraq for for the latest buffer overflow.
For that reason (and because I get to a repository from outside a
company intranet) I'd rather use ssh and port forwarding to get to the
machine with the repository than just have it sitting naked on the
net. Yes, I could add more firewall rules to ensure that only known
IP ranges can connect to the svn port. I may do that in the future but
right now it's a hassle. Using svn+ssh there's literally nothing to
do and my network's security is no less than it was before.
In the case of source code control, I think people will (or at least
should) tend to be _very_ careful about what they expose to the net.
If I couldn't ssh tunnel one way or another to svnserve, I wouldn't
even consider using it at this point. The major advantage of using
httpd (from my POV) is finer control over read/write access. It
happens that I don't need that, so
building/installing/maintaining/monitoring another httpd plus SSL is
much more of a pain than simply typing svn+ssh at the start of a URL.
Anyway, that's my reason. I am very interested to hear other opinions
one way or another. That section was the very first thing I went to
in the book.
Terry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org