svn+ssh://... shouldn't assume svnserve in user's PATH

[Will Partain <wi...@verilab.com>]

The code that sets up for an svn+ssh connection (I believe
it is
./subversion/libsvn_ra_svn/client.c:320:  (*argv)[n++] = "svnserve";
in 0.28.1) assumes that svnserve will be in the user's PATH
on the far side.  There is no reason that should necessarily
be so (especially in these early-adopter try-in-a-home-dir
days).

Could we have something the equivalent of the CVS_SERVER env
var.?  Or compile-time option; or config file thing; or ...

Keep up the good work,

Will


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

Re: svn+ssh://... shouldn't assume svnserve in user's PATH

[Michael Wood <mw...@its.uct.ac.za>]

On Sun, Aug 31, 2003 at 05:53:07PM -0400, Greg Hudson wrote:
> On Sat, 2003-08-30 at 15:30, Will Partain wrote:
> > Could we have something the equivalent of the CVS_SERVER env
> > var.?  Or compile-time option; or config file thing; or ...
> 
[snip]
> I'm afraid of implementing hackish, short-term solutions because we'll
> have to support them forever.  It really seems simplest to mandate that
> people set up your path correctly on the server.  Unfortunately, I've
> heard (though I haven't verified) that modern openssh makes that
> impossible for some users who don't have root access, by disabling
> .ssh/environment by default and bypassing .profile when a command line
> is specified.
[snip]

Well it's not impossible, because the user can still set up a public key
with corresponding entry in .ssh/authorized_keys looking like this:

command="/path/to/svnserve -r /some/path -t" ssh-dss AAAAB3...

It's just not as convenient, perhaps, but it also allows you to use the
"-r" switch, which just using .ssh/environment isn't enough for.

-- 
Michael Wood <mw...@its.uct.ac.za>

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

Re: svn+ssh://... shouldn't assume svnserve in user's PATH

[Greg Hudson <gh...@MIT.EDU>]

On Mon, 2003-09-01 at 06:35, Will Partain wrote:
> > ... .  It really seems simplest to mandate that
> > people set up your path correctly on the server.
> 
> (Wearing my sysadmin hat:) I try to run things so that users
> *never* have to fiddle with their .<shell>rc files.

Then you'd install svnserve in the default user path and be done with
it.

No piece of Subversion server-side configuration could help the ssh
tunnel command find the svnserve binary, because Subversion doesn't get
a chance to run any code until svnserve starts.  What we are talking
about is a piece of client-side configuration to specify the path to
svnserve.  Since you, the sysadmin, most likely cannot "add a line to
the global config file" for all clients, such a thing wouldn't help you,
and you wouldn't need help anyway since you have power over both the
default user path and the contents of the directories within it.

The use case we're really worried about here is a user setting up
Subversion in his or her homedir and accessing it from elsewhere.  If
the default user path does not include anything in the user's homedir,
and openssh makes it difficult to change that path when a command is
specified, then the current state of affairs makes life inconvenient for
such a user.


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

Re: svn+ssh://... shouldn't assume svnserve in user's PATH

[Will Partain <wi...@verilab.com>]

Greg Hudson <gh...@MIT.EDU> writes:

> On Sat, 2003-08-30 at 15:30, Will Partain wrote:
>> Could we have something the equivalent of the CVS_SERVER env
>> var.?  Or compile-time option; or config file thing; or ...
>
> ... .  It really seems simplest to mandate that
> people set up your path correctly on the server.

(Wearing my sysadmin hat:) I try to run things so that users
*never* have to fiddle with their .<shell>rc files.  As soon
as you get into "Ah, just add <mumble> to your <blah>rc",
then you're DOOMED.  They start blindly copying each other's
files, or fragments thereof, and five years later, you've
got random programs doing weird and wacky stuff because of
some inherited five-times-over .bashrc junk that's
Completely Wrong (TM).  If I can add a line to a global
config file and They Never Know, I am much happier.

But I'm pretty easy about the whole thing -- I don't want to
be blamed for any hackish code in Subversion.  I spent all
my karma on The Mangler [*] in Glasgow Haskell :-)

Will

[*] The Perl script, perhaps now replaced, which takes GCC
.s output and *mangles* it to produce reasonably zippy
Haskell code, with particular crimes reserved for the x86
lack of registers -- "see that memory reference? replace it
with %eax; trust me..."


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

Re: svn+ssh://... shouldn't assume svnserve in user's PATH

[Greg Hudson <gh...@MIT.EDU>]

On Sat, 2003-08-30 at 15:30, Will Partain wrote:
> Could we have something the equivalent of the CVS_SERVER env
> var.?  Or compile-time option; or config file thing; or ...

It would be easy enough to set up a CVS_SERVER equivalent, but that kind
of breaks down for people who access more than one repository via
svn+ssh.

A compile-time option is right out.

There are certainly ways to get config options to work, but my thought
process usually goes something like this:

  * We could have a server-dependent option in .subversion/servers.  But
that's confusing, because it fragments tunnel configuration.

  * Tunnel configuration could be changed to have a whole section for
each scheme.  (Perhaps instead of a [tunnels] section, we would have a
[tunnel-scheme-FOO] section for scheme foo.)  Then the environment
variable, the default command, and the server path for each scheme could
be specified independently.  And it makes some sense for the server path
to be scheme-dependent, since it's an implementation detail getting
exposed as part of the tunneling "protocol."

  * But maybe it would be even nicer if the tunnel agent command could
specify the entire command line (instead of "ssh", it would be something
like "ssh -h %{HOST} svnserve -t").

  * But the most obvious implementation of that kind of parameterization
introduces quoting issues, unless we choose to ignore them.  And by the
way, isn't it icky that apr_tokenize_to_argv() doesn't cooperate with
backslash-separated pathnames on Windows?

  * And if we have a parameterized command line, wouldn't it be nice to
be able to make the --username option work?  (Or the "username@hostname"
URL syntax, or both.)  But that requires more complex parameterization,
since you want to pass "-u username" if a username was specified, and
nothing if not.

  * This is all very complicated; maybe I'll play video games instead.

So, clearly, the best is becoming the enemy of the good inside my head;
I'm afraid of implementing hackish, short-term solutions because we'll
have to support them forever.  It really seems simplest to mandate that
people set up your path correctly on the server.  Unfortunately, I've
heard (though I haven't verified) that modern openssh makes that
impossible for some users who don't have root access, by disabling
.ssh/environment by default and bypassing .profile when a command line
is specified.


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