On Wed, 2004-05-26 at 16:35, Paul Oppenheim wrote:
> regarding the last line of your message -
>
> Then why doesn't it work that way?
>
> I would have no problem keeping the svnserve daemon running as user
> 'svn' and have clients connect to it. That's actually how I expected it
> to run the first time I tried to bring it up. Here's me: "why isn't
> svnserve -t working? svnserve -d does, i don't get it"
>
> My problem is keeping an open port other than ssh. I was under the
> impression that "tunnelling" was exactly that. So we return to the last
> line of your message -- then why doesn't it work that way?
Have you read the book? Specifically chapter 6?
svn+ssh:// doesn't "create an ssh tunnel and connect to an svnserve
daemon that's already running." It uses ssh as if it were the 'rsh'
command. It launches a temporary, private 'svnserve' process running as
*you*, which then opens the database. Thus it's no different than using
a file:/// URL on the server box. And if your umask and group
membership isn't just right, you risk messing up permissions for
everyone else.
That said, you *could* use ssh port-forwarding, which is what I think
you're imagining. You could set 'svnserve -d' running as single user on
a machine behind a firewall, then set up ssh to do port-forwarding.
Just forward local port 3690 to remotehost port 3690, and connect to
svn://localhost/. That creates a permanent ssh "tunnel" between the two
boxes, over which you connect to the svnserve daemon.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 26 23:43:13 2004