You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by se...@dimensionalrift.com on 2003/02/26 03:24:50 UTC

on svnserve (was Re: pitiful dav performance)

> 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.

Re: on svnserve (was Re: pitiful dav performance)

Posted by se...@dimensionalrift.com.
> On Tue, 2003-02-25 at 22:24, seanc@dimensionalrift.com wrote:
>> localhost tunnel svnserve with ssh (ssh2 protocol) : 13s
>> remote tunneled svnserve with plink (ssh2 protocol) : 1m 48s
>
> Can you measure the latency of your ssh link?

Any suggestions on how to do this?  Right now my plan is to just throwing
as many ssh clients as I can find at it and compare.  I just completed
openssh and it checks out the code in 63s, which is nearly twice as fast
as plink, but still 5 times slower than the svnserve daemon.  I have some
obscure/old ssh clients I want to try but, need pass a few of them custom
arguments since they don't read config files like openssh or plink can.

>
> The operation you describe (checkout of 326 files totalling 2MB) doesn't
> seem like it should involve a huge number of round trips, even though
> ra_svn isn't very pipelined.  But if your latency is very high, it could
> be an issue.

As for my network connection, its a 100 megabit link going through a
10/100 switch.  Your basic home LAN with only 2 computers on it.  The
switch does have a 10 megabit uplink to a DSL connection, but I've ruled
it out by unplugging it for a variety of tests.  Ping times between the
machines are < 1ms.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-02-25 at 22:24, seanc@dimensionalrift.com wrote:
> localhost tunnel svnserve with ssh (ssh2 protocol) : 13s
> remote tunneled svnserve with plink (ssh2 protocol) : 1m 48s

Can you measure the latency of your ssh link?

The operation you describe (checkout of 326 files totalling 2MB) doesn't
seem like it should involve a huge number of round trips, even though
ra_svn isn't very pipelined.  But if your latency is very high, it could
be an issue.

(As I have mentioned in a previous thread, if we want to pipeline ra_svn
more, we need to modify the error-return behavior of the editor and
reporter interfaces.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by se...@dimensionalrift.com.
I also want to play with the command line switches (compression, forcing
ssh1 vs ssh2, alternate identity files for various machines).  Its also an
exercise in getting my own copy of this thing compiled, which has proven
to be a lot of work in getting right (esp on 2 OS's).

> On Wed, 26 Feb 2003 seanc@dimensionalrift.com wrote:
>
>> I can coax plink/putty to fudge my user name with a
>> session (which is not the same between the two machines), but openssh in
>> cygwin requires "-l username" on the command line.
>>
>
> Doesn't ssh user@host work for cygwin?
>
> BR, jani
>
> --
> Jani Averbach                 jaa@iki.fi              +358 40 759 0984
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by Ben Collins-Sussman <su...@collab.net>.
Timothee Besset <tt...@idsoftware.com> writes:

> Interesting (and freaking ugly).
> 
> Where can I find dummy examples in perl/python/C whatever to do the
> svnserver wrapping and umask set?

We're talking about something really simple here:

$ mv /usr/local/bin/svnserve /usr/local/bin/svnserve-real
$ cat > /usr/local/bin/svnserve
#!/bin/sh
umask 002
/usr/local/bin/svnserve-real $*
^D
$ chmod +x /usr/local/bin/svnserve

...catch my drift?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-02-26 at 12:48, Philip Martin wrote:
> I don't understand.  The directory sticky bit controls who can delete
> a directory entry, with +s only the entry owner can delete it (and it
> only works on some systems).  How does that help?

g+s is the setgid bit, not the sticky bit.  Making a directory setgid
ensures that group ownership is inherited from that directory when new
files and directories are created inside it.  (On some systems, notably
the *BSDs, this inheritance is the default regardless of the setgid bit;
on others, notably Linux, group ownership of new inodes defaults to the
primary group of the creator unless the setgid bit is present on the
parent directory.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:

> It would be more social of us if we could remove the umask requirement. 
> Unfortunately, that means hacking (or discarding) Berkeley DB.  BDB
> needs to chmod logfiles after creating them to match the permissions of
> the database.

If BDB can be modified in some reasonable way we should submit a patch
to Sleepycat Software.  Then we wait for the next release and the
problem is solved :)

> As long as the parent directory is g+s, everything should
> work out.

I don't understand.  The directory sticky bit controls who can delete
a directory entry, with +s only the entry owner can delete it (and it
only works on some systems).  How does that help?

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-02-26 at 09:03, Timothee Besset wrote:
> I think it would be better if those umaks things could be configured in 
> httpd conf and in svnserve directly though. A configuration line is 
> easier that wrappers everywhere..

Well, sure.  And when svnserve gets a config file (anyone can feel free
to jump in with that, see issue #1143), a umask option would be fine
there.

Apache is a tougher issue.  An httpd might be performing many tasks,
each with their own umask requirements.  But Apache has a plugin model
(a single httpd process may perform many different functions, possibly
even at the same time, as I understand it), and the umask is
process-global state, so the first conflict between umask requirements
is a dead end for the administrator.  Or worse, a security hole.

It would be more social of us if we could remove the umask requirement. 
Unfortunately, that means hacking (or discarding) Berkeley DB.  BDB
needs to chmod logfiles after creating them to match the permissions of
the database.  As long as the parent directory is g+s, everything should
work out.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by Timothee Besset <tt...@idsoftware.com>.
Interesting (and freaking ugly).

Where can I find dummy examples in perl/python/C whatever to do the 
svnserver wrapping and umask set?

I think it would be better if those umaks things could be configured in 
httpd conf and in svnserve directly though. A configuration line is 
easier that wrappers everywhere..

TTimo

Ben Collins-Sussman wrote:

>Timothee Besset <tt...@idsoftware.com> writes:
>
>  
>
>>Now if I try ra_svn over ssh:
>>
>>I add my user to the svn group. When I run anything svn:// onto the
>>repository, permissions and ownership go crazy, usually ending up in a DB
>>error, and need to run svnadmin recovery + go through the repository to
>>set all ownerships and perms right again.
>>
>>Do you have any suggestions on how I should proceed?
>>    
>>
>
>We just added a section on this in the svn book, take a look:
>
>   http://svnbook.red-bean.com/book.html#svn-ch-5-sect-5
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by Ben Collins-Sussman <su...@collab.net>.
Timothee Besset <tt...@idsoftware.com> writes:

> Now if I try ra_svn over ssh:
> 
> I add my user to the svn group. When I run anything svn:// onto the
> repository, permissions and ownership go crazy, usually ending up in a DB
> error, and need to run svnadmin recovery + go through the repository to
> set all ownerships and perms right again.
> 
> Do you have any suggestions on how I should proceed?

We just added a section on this in the svn book, take a look:

   http://svnbook.red-bean.com/book.html#svn-ch-5-sect-5


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by Timothee Besset <tt...@idsoftware.com>.
Yeah that's my setup, everything owned by svn:svn, all files 660 (i.e.
user and group rw), + chmod g+s. But yet things go completely nuts when I
attempt an ra_svn operation

TTimo

On Wed, 26 Feb 2003 03:42:47 -0600 (CST)
seanc@dimensionalrift.com wrote:

> I noticed I had to chmod -R g+w the repositoru as well as doing a g+s on
> it, and this is described a bit in one of my earlier posts.  It seems the
> Berkeley DB is a bit wimpy when it comes to ignoring attribute bits on
> files it actually has ownership of.
> 
> > As far as I'm concerned, I've aborted my attempts to move from ra_dav to
> > ra_svn. ra_svn may be faster, but I ran into too many permission issues.
> >
> > The way I run ra_dav:
> >
> > There is a system user and a group 'svn'. All the repository is owned rw
> > by svn:svn, directories are chmod g+s svn. Apache runs as svn/svn
> > obviously, and all is good.
> >
> > Now if I try ra_svn over ssh:
> >
> > I add my user to the svn group. When I run anything svn:// onto the
> > repository, permissions and ownership go crazy, usually ending up in a DB
> > error, and need to run svnadmin recovery + go through the repository to
> > set all ownerships and perms right again.
> >
> > Do you have any suggestions on how I should proceed?
> >
> > TTimo
> >
> > On Wed, 26 Feb 2003 09:10:28 +0000
> > Colin Watson <cj...@flatline.org.uk> wrote:
> >
> >> On Wed, Feb 26, 2003 at 01:40:28AM -0600, seanc@dimensionalrift.com
> >> wrote:
> >> > Would anyone be traumatized if I worked on a patch to ra_svn to allow
> >> > user-defined additional command line options to the svn-tunnel-agent
> >> as
> >> > used in ra_svn_open?  I can coax plink/putty to fudge my user name
> >> with a
> >> > session (which is not the same between the two machines), but openssh
> >> in
> >> > cygwin requires "-l username" on the command line.
> >>
> >> While additional options would be a useful thing to have, I'm surprised
> >> you don't have ~/.ssh/config or some equivalent in cygwin ...
> >>
> >> --
> >> Colin Watson                                  [cjwatson@flatline.org.uk]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> >> For additional commands, e-mail: dev-help@subversion.tigris.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_svn permissions

Posted by se...@dimensionalrift.com.
I noticed I had to chmod -R g+w the repositoru as well as doing a g+s on
it, and this is described a bit in one of my earlier posts.  It seems the
Berkeley DB is a bit wimpy when it comes to ignoring attribute bits on
files it actually has ownership of.

> As far as I'm concerned, I've aborted my attempts to move from ra_dav to
> ra_svn. ra_svn may be faster, but I ran into too many permission issues.
>
> The way I run ra_dav:
>
> There is a system user and a group 'svn'. All the repository is owned rw
> by svn:svn, directories are chmod g+s svn. Apache runs as svn/svn
> obviously, and all is good.
>
> Now if I try ra_svn over ssh:
>
> I add my user to the svn group. When I run anything svn:// onto the
> repository, permissions and ownership go crazy, usually ending up in a DB
> error, and need to run svnadmin recovery + go through the repository to
> set all ownerships and perms right again.
>
> Do you have any suggestions on how I should proceed?
>
> TTimo
>
> On Wed, 26 Feb 2003 09:10:28 +0000
> Colin Watson <cj...@flatline.org.uk> wrote:
>
>> On Wed, Feb 26, 2003 at 01:40:28AM -0600, seanc@dimensionalrift.com
>> wrote:
>> > Would anyone be traumatized if I worked on a patch to ra_svn to allow
>> > user-defined additional command line options to the svn-tunnel-agent
>> as
>> > used in ra_svn_open?  I can coax plink/putty to fudge my user name
>> with a
>> > session (which is not the same between the two machines), but openssh
>> in
>> > cygwin requires "-l username" on the command line.
>>
>> While additional options would be a useful thing to have, I'm surprised
>> you don't have ~/.ssh/config or some equivalent in cygwin ...
>>
>> --
>> Colin Watson                                  [cjwatson@flatline.org.uk]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

ra_svn permissions

Posted by Timothee Besset <tt...@idsoftware.com>.
As far as I'm concerned, I've aborted my attempts to move from ra_dav to
ra_svn. ra_svn may be faster, but I ran into too many permission issues.

The way I run ra_dav:

There is a system user and a group 'svn'. All the repository is owned rw
by svn:svn, directories are chmod g+s svn. Apache runs as svn/svn
obviously, and all is good.

Now if I try ra_svn over ssh:

I add my user to the svn group. When I run anything svn:// onto the
repository, permissions and ownership go crazy, usually ending up in a DB
error, and need to run svnadmin recovery + go through the repository to
set all ownerships and perms right again.

Do you have any suggestions on how I should proceed?

TTimo

On Wed, 26 Feb 2003 09:10:28 +0000
Colin Watson <cj...@flatline.org.uk> wrote:

> On Wed, Feb 26, 2003 at 01:40:28AM -0600, seanc@dimensionalrift.com wrote:
> > Would anyone be traumatized if I worked on a patch to ra_svn to allow
> > user-defined additional command line options to the svn-tunnel-agent as
> > used in ra_svn_open?  I can coax plink/putty to fudge my user name with a
> > session (which is not the same between the two machines), but openssh in
> > cygwin requires "-l username" on the command line.
> 
> While additional options would be a useful thing to have, I'm surprised
> you don't have ~/.ssh/config or some equivalent in cygwin ...
> 
> -- 
> Colin Watson                                  [cjwatson@flatline.org.uk]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by se...@dimensionalrift.com.
Just trying to keep the amount of work for a new-user setup down to a
minimum (thats one less file to deal with . . .)  And as I said earlier,
this is mostly an exercise in getting the thing built since I'm interested
in hacking on it a bit.  As far as openssh, the command line switches
override the config files, which is useful to do sometimes.


> On Wed, Feb 26, 2003 at 01:40:28AM -0600, seanc@dimensionalrift.com wrote:
>> Would anyone be traumatized if I worked on a patch to ra_svn to allow
>> user-defined additional command line options to the svn-tunnel-agent as
>> used in ra_svn_open?  I can coax plink/putty to fudge my user name with
>> a
>> session (which is not the same between the two machines), but openssh in
>> cygwin requires "-l username" on the command line.
>
> While additional options would be a useful thing to have, I'm surprised
> you don't have ~/.ssh/config or some equivalent in cygwin ...
>
> --
> Colin Watson                                  [cjwatson@flatline.org.uk]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, Feb 26, 2003 at 01:40:28AM -0600, seanc@dimensionalrift.com wrote:
> Would anyone be traumatized if I worked on a patch to ra_svn to allow
> user-defined additional command line options to the svn-tunnel-agent as
> used in ra_svn_open?  I can coax plink/putty to fudge my user name with a
> session (which is not the same between the two machines), but openssh in
> cygwin requires "-l username" on the command line.

While additional options would be a useful thing to have, I'm surprised
you don't have ~/.ssh/config or some equivalent in cygwin ...

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-02-26 at 02:40, seanc@dimensionalrift.com wrote:
> Would anyone be traumatized if I worked on a patch to ra_svn to allow
> user-defined additional command line options to the svn-tunnel-agent as
> used in ra_svn_open?

As people have pointed out, ~/.ssh/config may be an easier option for
you.  But I'm certainly willing to review patches of this nature.

I'm a little dissatisfied in general with the way tunnel agents are
configured.  I implemented it based on a conversation on the list which
led to a very rough consensus, and I'm thinking of (when I have a little
time) switching to a different idea from that conversation, where
tunneled URLs would look like svn+ssh://hostname/path.  The tunnel
scheme could be defined in .subversion/servers, but there would be a
sane default such that you could use svn+ssh or svn+rsh without
configuring anything.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by se...@dimensionalrift.com.
No problem.

Would anyone be traumatized if I worked on a patch to ra_svn to allow
user-defined additional command line options to the svn-tunnel-agent as
used in ra_svn_open?  I can coax plink/putty to fudge my user name with a
session (which is not the same between the two machines), but openssh in
cygwin requires "-l username" on the command line.

> seanc@dimensionalrift.com writes:
>
>> > 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.
>
> Errr...that's my fault.
>
> I accidentally blew away Ben's documentation (and coincidentally,
> that's what I'm working on fixing right now).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by cm...@collab.net.
seanc@dimensionalrift.com writes:

> > 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.

Errr...that's my fault.

I accidentally blew away Ben's documentation (and coincidentally,
that's what I'm working on fixing right now).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: on svnserve (was Re: pitiful dav performance)

Posted by Ben Collins-Sussman <su...@collab.net>.
seanc@dimensionalrift.com writes:

> 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.

Calm down...  the book is still a work in progress, and svnserve is
relatively new.  By coincidence, we just documented all these very
things over the weekend, and you'll see it all revealed when we post
new PDF/HTML versions of the book tomorrow.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org