[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ssh based access?

From: Mark Benedetto King <bking_at_answerfriend.com>
Date: 2002-04-18 18:31:18 CEST

On Thu, Apr 18, 2002 at 11:38:44AM -0400, William Uther wrote:
> Hi,
> Was wandering home in an inebriated haze last night thinking about this...

Well, I was sober, but I still had many of the same ideas.

> People have been talking about ra_pipe. Someone mentioned putting a
> wrapper around the xml parts of svn to make it. Someone else mentioned they
> thought this would be pretty easy, but there were a few details to work out.
> BUT, doesn't svn already have a pipe protocol - it's called http/webdav. We
> want to replace the transport layer, not the protocol layer.


> I don't know apache/neon that well. Does the following make any sense?
> I believe Apache can be run using inetd (although it is deprecated?). See
> <http://httpd.apache.org/docs/mod/core.html#servertype>. This will be our
> version of the cvs server.

The "please don't make me install apache-2.0 in order to use svn" request
seems reasonable enough to me. If that's the case, apache is right out,
run as-if-from-inetd or not. But does that mean *any* harness for mod_dav_svn
would be unacceptable? I'm not sure. It might not be *too* hard to slap
together a minimal harness for mod_dav_svn, for those that refuse to install

> Then you need to modify neon to create an ne_session from an already open
> socket.

Or modify neon to be able to create the connection via a callback mechanism,
instead of through socket()/connect(). I'm not sure this is an option,
and if it isn't, this approach would require an overhaul to ra_dav to
use neon via an abstraction.

> Finally, you define a new URI type:
> pipe:/rsh-cmd:user,password/host/rest/of/path/. When you get one of these

Because of the need for very rich syntax, and because of the frailty of
the URL validators, I've been thinking:

Where "pipe-name" is looked up in the user's config to map to the relevant
stuff, of which there could be quite a bit, for certain pipe technologies.
One thing that is necessary is the actual repos-URL to use on the remote
side of the house.

> you use the supplied rsh-cmd and auth info to start up apache on the remote
> host in the same way inetd used to. This gives you a connection to apache
> over ssh. You make a new ne_session from your socket and the path in the
> URI.

As it stands ra_dav likes to open two sessions. This might be a lose
once you start talking about two SSHs and two mod_dav_svn harnesses.
I'm not sure what it uses those two sessions for, but it might need
to be turned off.

> You now have a secure http connection to the remote machine. ssh is the
> only aperture - this is not the same as running your own instance of apache
> on an unprivileged port. You do what ra_dav currently does over the http
> connection using the ne_session.

Yes, but you are still running apache, and you've gone and modified ra_dav
and/or neon.

> It is kinda ugly. It relies upon deprecated features in apache. It

I'm not sure that feature is so much deprecated as discouraged because of
apache's startup overhead. I could easily be wrong about that, though.

> assumes that svn can use "keep alive" stuff to do the entire transation over
> one ne_session. It doesn't require defining a new wire protocol.

AFAICT, svn already uses keep-alive, but it also uses more than one
session, as mentioned above. You're right that we wouldn't need a new
wire protocol, and that might be a big enough win to argue that the
changes to neon and/or ra_dav in order to take this approach would
be worth it.

Because of the "Hippocratic Principle" mentioned in HACKING, I had
planned on going ahead and implementing a new wire protocol. They're
really not that hard, and this one is simple. Or would be simple, if
not for the callbacks *shudder* :-).

It does seem rather inelegant to have two protocols when
really what is needed is transport abstraction, though.

What do you think?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 18 18:34:38 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.