Emacs development

Stefan Monnier | 1 Sep 2008 05:02

Re: Server port

>>> I wanted to force the Emacs server to listen on a particular port.
>>> Here is a patch that allows this by adding a customisation option.
>> Why?
> So that it would be simple to set up a firewall rule or port forwarding to
> allow incoming connections from remote emacsclients.

Makes sense.
Can you post your patch to bug-gnu-emacs so that we can save it for when
we reopen the trunk for new features?

        Stefan

headers

Peter Oliver | 23 Oct 2010 20:44

Re: Server port

On Sun, 31 Aug 2008, Stefan Monnier wrote:

> On Sun, 31 Aug 2008, Peter Oliver wrote:
>>>> I wanted to force the Emacs server to listen on a particular port.
>>>> Here is a patch that allows this by adding a customisation option.
>>>
>>> Why?
>>
>> So that it would be simple to set up a firewall rule or port forwarding to
>> allow incoming connections from remote emacsclients.
>
> Makes sense.
> Can you post your patch to bug-gnu-emacs so that we can save it for when
> we reopen the trunk for new features?

Can this now be applied?  I have posted an updated patch to 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854

--

-- 
Peter Oliver

headers

Leo | 23 Oct 2010 21:29

Re: Server port

On 2010-10-24 02:44 +0800, Peter Oliver wrote:
> Can this now be applied?  I have posted an updated patch to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854

I also proposed this in private email to Juanma but was turned down due
to security concern. This is what I used locally:

commit 014a288ac84b11453334397c77f439071fa138f2
Date:   Fri Aug 20 16:47:03 2010 +0100

    Make port number of emacs server customisable

	Modified lisp/server.el
diff --git a/lisp/server.el b/lisp/server.el
index 7e2c35a..50d08b0 100644
--- a/lisp/server.el
+++ b/lisp/server.el
 <at>  <at>  -112,6 +112,14  <at>  <at>  If set, the server accepts remote connections; otherwise it is local."
   :version "22.1")
 (put 'server-host 'risky-local-variable t)

+(defcustom server-port t
+  "TCP socket port for the server process.
+If t use a random port number."
+  :group 'server
+  :type '(choice (const :tag "Random" t)
+		 (integer :tag "Port" 10007))
+  :version "24.1")
+
 (defcustom server-auth-dir (locate-user-emacs-file "server/")

(Continue reading)

headers

Juanma Barranquero | 23 Oct 2010 21:38

Re: Server port

On Sat, Oct 23, 2010 at 21:29, Leo <sdl.web <at> gmail.com> wrote:

> I also proposed this in private email to Juanma but was turned down due
> to security concern.

Just for clarification, I didn't "turn down" anything, because the
decision is not mine to make. I likely pointed out that a similar idea
was initially turned down because of security concerns.

Stefan's (couple of years old) message in this thread seems to
indicate that the proposed patch is acceptable.

    Juanma

headers

Leo | 23 Oct 2010 22:01

Re: Server port

On 2010-10-24 03:38 +0800, Juanma Barranquero wrote:
>> I also proposed this in private email to Juanma but was turned down due
>> to security concern.
>
> Just for clarification, I didn't "turn down" anything, because the
> decision is not mine to make. I likely pointed out that a similar idea
> was initially turned down because of security concerns.

That's what I meant ;) Sorry for my English.

Leo

headers

Stefan Monnier | 24 Oct 2010 03:11

Re: Server port

> Can this now be applied?  I have posted an updated patch to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854

Yes, people, feel free to install it, thank you,

        Stefan

headers

Lluís | 24 Oct 2010 18:48

Remote TCP server through ssh tunnel [Was: Re: Server port]

Stefan Monnier writes:

>> Can this now be applied?  I have posted an updated patch to
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854

> Yes, people, feel free to install it, thank you,

Which reminds me... can I use emacsclient to connect to a server behind
a firewall?

I've tried with this:

server$ emacs --daemon --eval '(setq server-use-tcp t server-host "0.0.0.0")'
server$ netstat -nap | grep emacs
tcp        0      0 0.0.0.0:13501           0.0.0.0:*               LISTEN      12078/emacs     
server$ ssh -R 13502:localhost:13501 firewall
client$ ssh -L 13501:localhost:13502 vilanova <at> gso.ac.upc.edu
# I already have an existing tunnel for ssh connections to server
client$ scp server:.emacs.d/server/server /tmp/server
client$ sed -i -e s/0.0.0.0/127.0.0.1/ /tmp/server
client$ emacsclient -f /tmp/server -c
Waiting for Emacs...
*ERROR*: Display :0.0 can't be opened
[Exit 1 ]
client$ emacsclient -f /tmp/server -nw
*ERROR*: Could not open file: /dev/pts/5

Do you have any clue of why is this happenning? According to the
documentation, this should work flawlessly (at least with hosts on the
same network):

(Continue reading)

headers

Ken Raeburn | 24 Oct 2010 23:50

Re: Remote TCP server through ssh tunnel [Was: Re: Server port]

On Oct 24, 2010, at 12:48, Lluís wrote:
> Which reminds me... can I use emacsclient to connect to a server behind
> a firewall?

This would probably be a more appropriate question for emacs-help, but....

> I've tried with this:
> 
> server$ emacs --daemon --eval '(setq server-use-tcp t server-host "0.0.0.0")'
> server$ netstat -nap | grep emacs
> tcp        0      0 0.0.0.0:13501           0.0.0.0:*               LISTEN      12078/emacs     
> server$ ssh -R 13502:localhost:13501 firewall
> client$ ssh -L 13501:localhost:13502 vilanova <at> gso.ac.upc.edu
> # I already have an existing tunnel for ssh connections to server
> client$ scp server:.emacs.d/server/server /tmp/server
> client$ sed -i -e s/0.0.0.0/127.0.0.1/ /tmp/server
> client$ emacsclient -f /tmp/server -c
> Waiting for Emacs...
> *ERROR*: Display :0.0 can't be opened
> [Exit 1 ]

":0.0" is the name you generally use for connecting to the local X11 display on the machine running the X
program.  That's what you've got on the client, and what emacsclient passes over to the emacs server
process.  Unfortunately since that's running on a different machine, the local X display *there* -- if
there even is one -- is not the one on your client machine.

If your SSH path through is forwarding X11 as well as TCP connections, you need to find the server-side name
for that forwarded "display" and give it to emacsclient to pass through.  I think that'll work; I haven't
tried it.  (I usually just run emacsclient on the server machine, over an SSH session, and let it pop up a
window over that same SSH session.)

(Continue reading)

headers

Lluís | 25 Oct 2010 14:50

Re: Remote TCP server through ssh tunnel

Ken Raeburn writes:

> On Oct 24, 2010, at 12:48, Lluís wrote:
>> I've tried with this:
>> 
>> server$ emacs --daemon --eval '(setq server-use-tcp t server-host "0.0.0.0")'
>> server$ netstat -nap | grep emacs
>> tcp        0      0 0.0.0.0:13501           0.0.0.0:*               LISTEN      12078/emacs     
>> server$ ssh -R 13502:localhost:13501 firewall
>> client$ ssh -L 13501:localhost:13502 vilanova <at> gso.ac.upc.edu
>> # I already have an existing tunnel for ssh connections to server
>> client$ scp server:.emacs.d/server/server /tmp/server
>> client$ sed -i -e s/0.0.0.0/127.0.0.1/ /tmp/server
>> client$ emacsclient -f /tmp/server -c
>> Waiting for Emacs...
>> *ERROR*: Display :0.0 can't be opened
>> [Exit 1 ]

> ":0.0" is the name you generally use for connecting to the local X11
> display on the machine running the X program.  That's what you've got
> on the client, and what emacsclient passes over to the emacs server
> process.  Unfortunately since that's running on a different machine,
> the local X display *there* -- if there even is one -- is not the one
> on your client machine.

Right. That's what I found out after trying it. The emacs server is
expecting everything to be run on the server machine.

What I expected was to run emacsclient as a sort of UI client
interacting with a remote server.

(Continue reading)

headers

Chad Brown | 25 Oct 2010 17:33

Re: Remote TCP server through ssh tunnel

On Oct 25, 2010, at 5:50 AM, Lluís wrote:

What I expected was to run emacsclient as a sort of UI client
interacting with a remote server.

[...]

In any case, I suppose emacs is not ready for such a client-server
interaction, although I don't really know if that would be hard to
achieve.

For your idea, emacsclient would have to have some way of transmitting every change from either the server or client) over the communications channel. Someone would have to figure out the set of all interactions between the client along with an efficient marshaling/unmarshaling protocol (more efficient than just using something like lbX). For emacs, this would mean breaking in two the redisplay engine, which is probably the most complicated part of the program.

There are a few editors that have tried this experiment (notably, sam/samterm, by Rob Pike http://en.wikipedia.org/wiki/Sam_%28text_editor%29). When last I followed that community, the split usage had proven to be less and less valuable over time, and I suspect that the specific functionality might have bit-rotted away.

I would suggest that you look into something like low-bandwith X (http://en.wikipedia.org/wiki/Low_Bandwidth_X) as an alternative.

I hope that helps,

*Chad

headers

Stefan Monnier | 25 Oct 2010 18:28

Re: Remote TCP server through ssh tunnel

>> ":0.0" is the name you generally use for connecting to the local X11
>> display on the machine running the X program.  That's what you've got
>> on the client, and what emacsclient passes over to the emacs server
>> process.  Unfortunately since that's running on a different machine,
>> the local X display *there* -- if there even is one -- is not the one
>> on your client machine.
> What I expected was to run emacsclient as a sort of UI client
> interacting with a remote server.

emacsclient, as it is implemented currently, is an application that just
sends some commands to the Emacs server and then exits (in the most
complex case it will wait for Emacs to send a reply before exiting).

We could try to make it more complex and have emacsclient to care of
doing the display: that would make it more "robust" in the sense that it
would work in more circumstances, but that would mean designing and
implementing an ad-hoc protocol.  Tho maybe we could do it by reusing an
existing system: e.g. we could have emacsclient create something like an
lbx tunnel.  And of course we'd want to do the same for ttys.

> In any case, I suppose emacs is not ready for such a client-server
> interaction, although I don't really know if that would be hard to
> achieve.

I think that if we reuse something like lbx, it might not be too difficult.

> That's what I do, but is not comfortable for high delay network
> connections. As I said, I expected to run locally "as much as possible",
> but modify everything remotely.

If you want to do as much as possible locally, I think that Tramp is
your friend.

        Stefan

headers

Peter Oliver | 25 Oct 2010 19:28

Re: Remote TCP server through ssh tunnel

On Mon, 25 Oct 2010, Lluís wrote:

> Ken Raeburn writes:
>
>> On Oct 24, 2010, at 12:48, Lluís wrote:
>>> I've tried with this:
>>>
>>> server$ emacs --daemon --eval '(setq server-use-tcp t server-host "0.0.0.0")'
>>> server$ netstat -nap | grep emacs
>>> tcp        0      0 0.0.0.0:13501           0.0.0.0:*               LISTEN      12078/emacs
>>> server$ ssh -R 13502:localhost:13501 firewall
>>> client$ ssh -L 13501:localhost:13502 vilanova <at> gso.ac.upc.edu
>>> # I already have an existing tunnel for ssh connections to server
>>> client$ scp server:.emacs.d/server/server /tmp/server
>>> client$ sed -i -e s/0.0.0.0/127.0.0.1/ /tmp/server
>>> client$ emacsclient -f /tmp/server -c
>>> Waiting for Emacs...
>>> *ERROR*: Display :0.0 can't be opened
>>> [Exit 1 ]
>>
>> If your SSH path through is forwarding X11 as well as TCP connections,
>> you need to find the server-side name for that forwarded "display" and
>> give it to emacsclient to pass through.  I think that'll work; I
>> haven't tried it.

I've tried it, and can confirm that it does work.

> That's what I do, but is not comfortable for high delay network
> connections. As I said, I expected to run locally "as much as possible",
> but modify everything remotely.

I think you misunderstand.  The suggestion here isn't that you should 
run emacs over X11.  The other person is pointing out that SSH arranges 
this for you in a way that confuses emacsclient.  All this talk of 
"servers" is rather confusing when your X11 server is at the opposite 
end of the connection to your SSH server 

Try the following:

server$ echo $DISPLAY
# Confirm that you can connect to this display by running, e.g.,
server$ xdpyinfo
# Then:
client$ export DISPLAY="<value from echo, above>"

Anyway, as people have mentioned, I think you should look into Tramp.

I call emacsclient with a simple shell wrapper that prefixes 
"/ssh:login <at> host:" to the file name.  Emacs then fetches the 
file for me for local editing.

If you re-use your existing SSH connections by adding, e.g.,
 	ControlMaster   auto
 	ControlPath     ~/.ssh/mux/%r <at> %h:%p
to your ~/.ssh/config, this is all perfectly speedy.

--

-- 
Peter Oliver

headers

Lluís | 25 Oct 2010 22:22

Re: Remote TCP server through ssh tunnel

Peter Oliver writes:
> I think you misunderstand.  The suggestion here isn't that you should run emacs
> over X11.  The other person is pointing out that SSH arranges this for you in a
> way that confuses emacsclient.

Yup, but the net effect is equivalent to going into the server machine
and executing a graphical emacs that is transported through X11 back to
my client machine (where the X11 server resides :)).

That's exactly what I was trying to avoid, and what I was expecting was
the split model that Chad and Stefan were describing.

In any case, thanks a lot for your answers, at least now I can tell my
work mate that this is one of the few things that his shiny new emacs
cannot do :)

> Anyway, as people have mentioned, I think you should look into Tramp.

Well, he told me that tramp was just "too slow" when saving files. I
don't know if this can be optimized.

> If you re-use your existing SSH connections by adding, e.g.,
> 	ControlMaster   auto
> 	ControlPath     ~/.ssh/mux/%r <at> %h:%p
> to your ~/.ssh/config, this is all perfectly speedy.

Which I already do :)

Thanks,
  Lluis

--

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

headers

Ken Raeburn | 26 Oct 2010 06:05

Re: Remote TCP server through ssh tunnel

On Oct 25, 2010, at 16:22, Lluís wrote:
> In any case, thanks a lot for your answers, at least now I can tell my
> work mate that this is one of the few things that his shiny new emacs
> cannot do :)

Blasphemy! 

If you're interested in speeding up X11 sessions, I was pretty happy with dxpc years ago (and implemented an
option to have it forcibly set the "backing store" option of all visible windows, to reduce refreshes); NX
looks like an interesting option too.

>> Anyway, as people have mentioned, I think you should look into Tramp.
> 
> Well, he told me that tramp was just "too slow" when saving files. I
> don't know if this can be optimized.

It's slower than operating on local files, certainly, but I haven't been annoyed with it enough to look much
into speeding it up.  It does appears that Tramp supports using rsync; that may be faster for sending back
large files to which you've made small changes, especially combined with the SSH connection
multiplexing you've already got.  In my experience, the default seems to be to use scp, so explicitly
selecting rsync may be necessary.

Ken