[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: William Uther <will+_at_cs.cmu.edu>
Date: 2002-04-18 19:02:02 CEST

On 18/4/02 12:31 PM, "Mark Benedetto King" <bking@answerfriend.com> wrote:

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

I had the same thoughts. I started looking at apache as that harness not
because it was a great idea, but because it was already there. It would
allow you to get something up and running quickly. It would be great to
write a more minimal harness for mod_dav_svn - but it should be done last,
not first.

[snip implementation details]

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

Knowing what these two sessions are for would be useful. Can ra_dav be
modified to use a single session? Again, this is a nice improvement, but
technically optional. It could be left till other stuff is finished.

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

Well, you're running apache for the proof of concept. Once it is running
with apache, another harness could be written for mod_dav_svn. Yes, this
would require a modification to neon. It wouldn't require a huge mod to
neon - just a new, more flexible, API for creating a session.

I don't think you need huge mods to ra_dav. You'd just create ra_pipe that
shared code with ra_dav. Shared code is good - less work to do, fewer
hiding places for bugs.

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

It used to be discouraged, but the docs now say: (in red) "Inetd mode is no
longer recommended and does not always work properly. Avoid it if at all

The "does not always work properly" worries me a little.

> 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* :-).

I'm not sure that one of xml or http-over-a-socket is necessarily likely to
do more harm than the other. They simply attach in different places.
You're going to have to make the attachment clean in either case.

> It does seem rather inelegant to have two protocols when
> really what is needed is transport abstraction, though.
> What do you think?

I don't think. It hurts.

I'm not going to have time to implement this, so I'm going to stop wasting
bandwidth now.

\x/ill :-}

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 18 19:03:05 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.