Re: Server port

Re: Server port

[Stefan Monnier]

> 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?


        Stefan

Re: Server port

[Stefan Monnier]

>>> 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

Re: Server port

[Peter Oliver]

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

Re: Server port

[Leo]

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
@@ -112,6 +112,14 @@ 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/")
   "Directory for server authentication files.
 
@@ -561,7 +569,7 @@ server or call `M-x server-force-delete' to forcibly disconnect it.")
 		       ;; The other args depend on the kind of socket used.
 		       (if server-use-tcp
 			   (list :family 'ipv4  ;; We're not ready for IPv6 yet
-				 :service t
+				 :service server-port
 				 :host (or server-host "127.0.0.1") ;; See bug#6781
 				 :plist '(:authenticated nil))
 			 (list :family 'local


Leo

Re: Server port

[Juanma Barranquero]

On Sat, Oct 23, 2010 at 21:29, Leo <sdl.web@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

Re: Server port

[Leo]

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

Re: Server port

[Stefan Monnier]

> 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

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

[Lluís]

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@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):
  http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html


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

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

[Ken Raeburn]

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@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.)

> client$ emacsclient -f /tmp/server -nw
> *ERROR*: Could not open file: /dev/pts/5

This can't work.  Emacs running on the server can't access the local tty device on your client machine.

> 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):
>  http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html

It's a bit misleading, yeah... evaluating an expression or editing a file in shared NFS space might make sense to trigger remotely like this, and the documentation was probably fine when multi-tty and daemon support hadn't come along, but now it probably needs to highlight these problems.

Please file a bug report (M-x report-emacs-bug RET) and/or submit a fix...

(And of course the Emacs driving the new window will be running on the server, so it can't access files on the client machine without jumping through hoops.  If you really want to be able to do something on the local machine that triggers editing of files that are on the server machine, you might also look at the Tramp package, which will let you use your local Emacs, which may be faster.  But if you want to run subprocesses and such over there, or share an Emacs session there across multiple clients, yeah, getting a window popped up remotely may be best.)

Ken

Re: Remote TCP server through ssh tunnel

[Lluís]

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@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.

The objective is to have a local X window but doing everything on the
server. I know I could just "ssh -X" to the server and start a client
there, but insteractivity is too sloppy then due to network delay.

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.


> 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.)

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 suppose that's not an easy task, as emacs is still relying on a lot of
global variables, so client interaction still needs to send a lot of
information back and forth to the server.

This would probably require modifications to the core VM in order to
provide a true client-server model with client-side caching.


>> 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):
>> http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html

> It's a bit misleading, yeah... evaluating an expression or editing a
> file in shared NFS space might make sense to trigger remotely like
> this, and the documentation was probably fine when multi-tty and
> daemon support hadn't come along, but now it probably needs to
> highlight these problems.

> Please file a bug report (M-x report-emacs-bug RET) and/or submit a fix...

You mean a bug report to the paragraph that misled me?


> (And of course the Emacs driving the new window will be running on the
> server, so it can't access files on the client machine without jumping
> through hoops.  If you really want to be able to do something on the
> local machine that triggers editing of files that are on the server
> machine, you might also look at the Tramp package, which will let you
> use your local Emacs, which may be faster.  But if you want to run
> subprocesses and such over there, or share an Emacs session there
> across multiple clients, yeah, getting a window popped up remotely may
> be best.)

As said, I did expect everything to run on the server, but without
sending "canvas diffs" of the X11 frames through the network.


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

Re: Remote TCP server through ssh tunnel

[Chad Brown]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]


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


[-- Attachment #2: Type: text/html, Size: 1891 bytes --]

Re: Remote TCP server through ssh tunnel

[Stefan Monnier]

>> ":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

Re: Remote TCP server through ssh tunnel

[Peter Oliver]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2229 bytes --]

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@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@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@%h:%p
to your ~/.ssh/config, this is all perfectly speedy.

-- 
Peter Oliver

Re: Remote TCP server through ssh tunnel

[Lluís]

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@%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

Re: Remote TCP server through ssh tunnel

[Ken Raeburn]

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