> seanc@dimensionalrift.com wrote:
>
>>I would be willing to go with the ra_svn approach but it doesnt seem
>>possible to secure it in a meaningful manner for a multi-user
>>configuration. Perhaps if svnserve were to run exclusively on 127.0.0.1
>>and a proxy program (say, svnproxy) could be executed via rsh or plink
>>from my clients I could at least secure it in the same way as CVS.
>>
>
> uh, you can already tunnel ra_svn over ssh, just as one normally does
> with CVS. there's no reason to run svnserve in daemon mode if you don't
> want to.
>
This was not obvious at all from the documentation.
From the docs:
svnserve, a Custom Subversion Server
As an alternative to Apache, Subversion also provides a stand-alone server
program, svnserve. This program is considerably more lightweight than
Apache, and easier to configure. However, these benefits come at the cost
of flexibility. You can setup svnserve to run in one of a couple of
different ways. You can run svnserve as a daemon—a process that executes
indefinitely, listening for input and then handling that input when it
arrives. Or, it can run as a sort of “one-off” server process—initiated by
the inetd daemon on Unix systems.
There is no mention a tunnel mode vs the daemon or inetd way of doing
things. This way of running a server is so different it should have its
own section. It just happens the program is the same between these
(vastly different) connection methods. This missing section should also
explain having to edit ~/.subversion/servers (as well as its system-wide
or Windows versions), and possibly give a brief mention of setting up
cygwin ssh or plink/putty.
Searching on google for svnserve is sad. On google groups, there is only
1 hit, though it was enough to get me working:
http://groups.google.com/groups?q=svnserve&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=20030131200016%24726c%40gated-at.bofh.it&rnum=1
And back to the performance: I now have new timings checkout out my test
code project with tunneled svnserve:
localhost tunnel svnserve with ssh (ssh2 protocol) : 13s
remote tunneled svnserve with plink (ssh2 protocol) : 1m 48s
Considering these machines can talk at least 3 megabytes per second over
an ssh2 link (as measued by zmodem'ing a huge file with SecureCRT), there
still appears to be a strange bottleneck somewhere. I did play with
putty's compression option but it had no effect. I'm getting closer . . .
As for my other problems, they are probably also worth mentioning in some
kind of FAQ:
What I did to setup a database (incorrectly):
(root) created a svnusers group in /etc/group, added my non-root login to it.
(root) created /usr/local/svn
(root) chown -R root:svnusers /usr/local/svn
(root) chmod g+s /usr/local/svn <-- this is incomplete, and a mistake
(noted below)
(non-root) cd /usr/local/svn
(non-root) svnadmin create testdb
(non-root) checked out testdb in my home directory with file://
(non-root) added 2 megs worth of real-world source code, in 326 files, and
commited it
(non-root) nuked my local copy and checked it out (ok) with file://
(root) added www-data user to svnusers group
(root) configured apache2 for bare-bones public access to svn (no SSL or
Auth etc)
(remote-user) http access failed due to permission problems accessing the
BerkelyDB from www-data user.
(root) chown'd /usr/local/svn/testdb to www-data:www-data
(remote-user) http access still failed, searched google for a while
(www-data user) ran db4.1_recover on the database
(remote-user) http access verified working, but slow.
... configured SSL, AuthType Basic, etc all working
(remote-user) https access verified working, but also slow.
... tested svnserve as daemon
(root) su'd to www-data and ran svnserve -d
(remote-user) verified very public unauthed/unencrypted svnserve working
... discovered you could run tunnel svnserve like CVS with ssh
(root) chown'd /usr/local/svn back to root:svnusers
(root) chmod'd -R g+w /usr/local/svn (this fixes the early mistake
mentioned above)
(non-root) verified svn:// access with svn-tunnel-agent working via localhost
(remote-user) verified svn:// access with svn-tunnel-agent working via
LAN, slow but faster than with ra_dav.
Interesting Side Notes:
BerkeleyDB will not operate on files if it doesnt have write flags
enabled on the file for the GROUP, even though the process has full
access to the file. Its afraid to change the flags or ignore them . . .
This included the inital svnadmin create from within a directory that
had the group sticky bit enabled on it.
Although I had the permissions perfect for apache after chown'ing
everything to www-data:www-data, it was necessary to run recover on my
database, probably due to the abuse I was putting on it troubleshooting
things (many steps not listed above :)
- Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 26 04:25:28 2003