monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] db kill_rev_locally


From: Daniel Carrera
Subject: Re: [Monotone-devel] db kill_rev_locally
Date: Sun, 12 Oct 2008 02:34:53 +0200
User-agent: Thunderbird 2.0.0.17 (Macintosh/20080914)

Ethan Blanton wrote:
Simply start mtn serve on the hosted server as 'mtn serve
localhost:4691' (or whatever port -- any port over 1024 is available
to non-root users, 4691 is the default monotone port).  This will
start a monotone netsync server which can be connected to *only* by
processes on the local machine, over loopback.

Then, to connect to the server, run something like the following on
your workstation:

    ssh -L4691:localhost:4691 <server>

This somewhat confusing command line says "Forward port 4691 (the
leading 4691:) on the local host (-L) to port 4691 on the remote
machine (localhost:4691)".  See 'man ssh' for more on -L (and its
closely-related cousin, -R).  If you used a server port other than
4691 for 'mtn serve', replace the *final* 4691 in the above command
with the port the server is using.

And allowing this does not require giving developers the ability to SSH into the server through the terminal? How do you do this?


Having done this, on your workstation again, run:

    mtn sync localhost <pattern>

If you used a port other than 4691 as the first argument to ssh -L,
provide it as localhost:<port> in the above command.  This will
connect to your workstation on a port which SSH tunnels through its
own connection to the remote host and connects to the remote monotone
server.

Interesting. I'm still confuse about whether this requires giving developers SSH login access or not. How can you tunnel through SSH without a login?


As far as drawbacks, they are what you would expect; you have to have
the SSH tunnel running to access monotone, the encrypted stream is
overhead, etc.  However, you pay all those penalties to use monotone
via SSH in any fashion.

Yeah, that's fine. Like you said, it's no worse than the standard SSH solution.


Daniel.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]