> [snip]
> > There are two non-mutually-exclusive (but independent ways) to run
> > svnserve:
> >
> > 1. have a daemon listening on port 3690, clients connected
> > unauthenticated.
>
> Or have (x)inetd start it as Guido has done, of course, which is
> equivalent.
Right.
> > 2. have clients use their own ssh binaries to spawn "private"
> > svnserve processes on the server. They authenticate via ssh,
> > and the svnserve process runs as their own UID.
> >
> > So it sounds like you want case #2, in which case, there was no need
> > to set up case #1, unless you want to provide anonymous read-access to
> > people someday.
I did it this way initially because I needed write access from a
Windows box and I hadn't figured out how to tunnel through SSH from
there (in a way that I felt comfortable explaining to the other
developers). I am now happily using PLINK (see below).
> > > But no matter what I try, I get the following error messages:
> > >
> > > svn: Couldn't find a repository
> > > svn: No repository found in 'svn+ssh://<host>/home/subversion/<repos>'
> >
> > svn+ssh:// requires that you use an *absolute* path after the
> > hostname. Is that what you're doing?
Yes.
> To get around this, you can use the "-r" switch to svnserve. Just bare
> in mind that in "tunnel" mode (i.e. when using the svnserve protocol
> over SSH etc.) svnserve must be run with the -t switch. Otherwise
> everything will still be anonymous. You can do this by using SSH keys
> and then putting something like this in the authorized_keys file:
>
> command="svnserve -t -r /home/svn" ssh-dss AAAAB3...
>
> (see the ssh docs for more details.)
I don't understand this, but it's irrelevant.
> This is not necessary if you do not want to use the "-r" switch.
Right.
> > (Also, a future warning: because a bunch of users will be
> > reading/writing the berkeley-db repository files, be careful about
> > permissions and umasks. Many people make the 'svnserve' process on
> > the server into a wrapper-script which 1) sets a sane umask, 2) runs
> > the real svnserve.)
> [snip]
>
> Yes. To be slightly more explicit about this, all users need *write*
> access to the Berkeley DB files even for apparently readonly operations.
> If one user runs some svn command with the wrong umask, it will cause
> problems for other people.
>
> Your wrapper could be:
> #!/bin/sh
> umask 0007
> exec /path/to/real/svnserve "$@"
>
> As long as everyone is in the same group.
This was my problem. I *thought* I was in the subversion group (my
umask was correct and I had added myself to the subversion group in
/etc/group) but I wasn't; I didn't know about /etc/gshadow. Once I
was *really* in the subversion group, it worked.
Request to the svnserve developers: try to distinguish between
permission problems on the repository and "no repository found". I
had to add logging statements to the svnserve source to figure out
that the problem had something to do with permissions on the database.
But then ANOTHER issue came up, once the second developer used ssh
tunneling: THE <repos>/db DIRECTORY NEEDS TO HAVE THE SETGID BIT SET!
(I don't know about other directories under <repos>, or <repos>
itself.) Without this, files created by user x will have owner and
group set to x, and that defeats the group writability for other
members of the subversion group. (Our setup lets everyone log in via
ssh as themselves, and has a separate subversion group that you must
be in before you can use svnserve. The subversion group is nobody's
primary group.)
You may want to add this to the svnserve docs if it's not already
there. I got everything I know from the INSTALL (?) file in the svn
source tree, it's a bit sparse on details.
> By the way, svn+ssh://blah works fine on Windows too. At least I've
> tried it out with a Windows client connecting to a Linux server. I
> think other people on the dev@subversion.tigris.org list have it working
> with a Windows SSH server too, but I could be wrong.
>
> You can use plink.exe as the ssh client. Get it from the Putty download
> page.
Right, I already got it.
> One funny thing when setting this up under Windows is that you seem to
> have to use double backslashes or single forward slashes in the config
> file to specify the path to the SSH executable if it's not in your PATH.
>
> e.g.:
> [tunnels]
> ssh = C:/blah/plink.exe
> # or ssh = C:\\blah\\plink.exe
Right; I presume something is doing an extra pass of backslash
interpolation. I ended up avoiding either and copying plink.exe into
the \WINDOWS directory. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 22 17:28:30 2003