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

Re: Problem connecting to svnserve - not sure about protocols?

From: Jon Koerber <cryogen_at_mac.com>
Date: 2006-12-18 21:36:22 CET

Thanks Ryan, Saul, and Erik...

On Dec 18, 2006, at 11:52 AM, Ryan Schmidt wrote:

>
> On Dec 18, 2006, at 13:39, Jon Koerber wrote:
>
>> On Dec 18, 2006, at 11:23 AM, Ryan Schmidt wrote:
>>
>>> On Dec 18, 2006, at 13:12, Jon Koerber wrote:
>>>
>>>> I do have a firewall running on my server, but it looks like SSH
>>>> runs on port 22 on Mac OS X Tiger. Just in case, I added an
>>>> allow rule for port 3690 and tried the command again with no
>>>> luck. I then turned off the server's firewall entirely to test
>>>> the connection and still get the same error as above. Hmm, this
>>>> is perplexing. Did I miss something in the build?
>>>
>>> When using svn+ssh://, yes, you'd be using port 22. But when
>>> using the svn:// protocol, you'd be using the svnserve port 3690.
>>>
>>> svn:// and svn+ssh:// work differently. svn:// connects over 3690
>>> to a running svnserve daemon on the server. svn+ssh:// does not
>>> make use of any running daemon; rather, it starts svnserve itself
>>> every time you connect, and stops it when you're done. So
>>> svnserve needs to be in the path of the connecting user. It
>>> isn't, hence the error that it can't find the command svnserve.
>>
>> I thought the same thing when I first ran into this problem, as it
>> seemed to be a path issue. The user account, "jkoerber", on the
>> server that I am using in the connect has the correct $PATH for
>> Subversion: /usr/local/bin.
>>
>> I checked the value of the $PATH env variable by connecting
>> directly via SSH to the server from my client and it does indeed
>> have the correct path to the /usr/local/bin directory where
>> svnserve lives. Is it somehow not picking up the $PATH at the
>> time I issue the svn+ssh connection protocol? It "seems" to be
>> set up correctly?
>
> ssh uses of different environment variables depending on whether
> you ssh in to an interactive shell or whether you ssh in and
> directly run a program like svnserve.
>
> To demonstrate this, ssh to the server and run printenv to see the
> environment variables (including PATH).
>
> $ ssh 192.168.1.101
> Password:
> $ printenv
>
> Now exit out, and compare this with the environment variables used
> when you directly run a program without an interactive shell:
>
> $ ssh 192.168.1.101 printenv
> Password:
>
Yep, you nailed it. Since svn does not invoke the shell, my $PATH
isn't populated with the correct path to the subversion binaries (it
only has usr/bin:/bin:/usr/sbin:/sbin).

> You should see that in the latter case, which is the case in effect
> when it's trying to run svnserve, the PATH is different, and
> doesn't contain /usr/local/bin.
>
>
> I'm not sure of the solution because I do not use svnserve or svn
> +ssh, but I find it hard to believe that one would be required to
> symlink svnserve somewhere or recompile ssh with special options,
> as someone else suggested. Does the book not address the situation
> of having svnserve in a nonstandard location? If special setup is
> required for this case, it should address it.
>
A symlink will do fine for now (suggested by Saulius in his reply).
That should also solve the "svn:// protocol too".

I'll look back at the book to see if the nonstandard install location
is mentioned and I missed it. I'll also look to see if there is a
way to set up a path for an SSH client that is executing a program
directly, although that may be bad form for security reasons.

Thanks again for the help!

Jon
>
> --
>
> To reply to the mailing list, please use your mailer's Reply To All
> function
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 18 21:37:27 2006

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

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