Using Emacs server and emacsclient on other machines as other users

Paul Whittaker picture Paul Whittaker · Sep 22, 2012 · Viewed 23.5k times · Source

I know that after I call (start-server) inside an existing Emacs session I can then use emacsclient -c (on the same computer) to create new frames that connect into that server, so that each new frame created by emacsclient has access to the same set of shared state (e.g. buffers).

Most of the documentation I've found focuses on the "give me fast access to my local Emacs" use case, and so there are two things that I haven't seen any details of yet:

  1. Can emacsclient -c access Emacs servers started by other users, or is it hard-wired to detect only sessions started by my own user?

  2. Does Emacs server (directly or indirectly) support remote connections? That is, is there some way to set up Emacs (possibly involving SSH) that allows calls to emacsclient -c on remote machines to have access to the local state of my Emacs server?

(In case you haven't already guessed, what I'd ultimately like to do is combine the two techniques above to provide rudimentary collaborative editing support.)


This is a real-world problem, so here's what I'm working with:

  • The necessary functionality should be built into Emacs already (23.3.1, 64-bit). I can stretch to Emacs extensions from the standard Ubuntu repositories, but I'd prefer not to. (Which I believe rules out Rudel, sadly.)
  • No new users or user spoofing. Solutions should work with the existing set of user accounts, and users must not pretend to be other users (e.g. via su or ssh).

If it makes any difference, the machines are on a private LAN, have OpenSSH clients and servers installed (and running), and all users can connect to (their own account on) all machines, but they have no shared filesystem.


So, does anybody know whether Emacs server can

  • grant access to other users, or
  • provide remote access?

EDIT

As commented in rwb's answer, it's clear that the new windows being opened locally by running emacsclient -c are actually being created by the remote Emacs server process. That is, emacsclient is simply triggering the relevant behaviour in the server. This causes some issues with incorrect display settings, since the server does not normally have access to the local desktop (see below). However, I can now connect in to a remote Emacs session if I use the following sequence of commands:

In one terminal, where 1.22.333.44 is the IP address of remotehost:

ssh -t -X remotehost \
  "emacs -nw --eval
   '(progn (setq server-host \"1.22.333.44\" server-use-tcp t) (server-start))'"

Then in another (on the same machine):

scp remotehost:.emacs.d/server/server /tmp/server-file
DISPLAY=localhost:10 emacsclient -c -f /tmp/server-file

The emacsclient command causes the remote Emacs server (which it finds details of in /tmp/server-file) to open up a graphical Emacs window (on the local display) that shares state with the Emacs session on the remote host.

Since the remote Emacs server was started via ssh -X, SSH provides it with access to my local display via a "fake" :10 display. The DISPLAY=:10 passed to it (via emacsclient) thus causes a window to be opened on my local desktop.


Although the approach above does tick the "Run Emacs server on remote machine, connect to it using emacsclient locally" box, it's very limited. In fact, it's not much different to running the server and clients all locally as a single user: the only difference is that the server is now remote, so has access to different system resources.

Unfortunately, launching via ssh -X is the only way I've been able to successfully open a window on a different machine's X server:

  • Specifying a basic DISPLAY=remote:0 gets nowhere (since Ubuntu X servers are started with the -nolisten tcp option).

  • Connecting via SSH and then using DISPLAY=:0 also fails, but this time only due to lack of suitable authentication credentials. (I believe that's the case, anyway: the error message cryptically says No protocol specified / Can't open display.)

I think that finding a way around the second problem would probably get me a good deal closer to a solution.


Having read the posts at http://comments.gmane.org/gmane.emacs.devel/103350 (starting at the '25 Oct 14:50' post, about half way down) I'm starting to wonder if this might be one of the rare things that Emacs cannot do (i.e. is impossible ;-) ).

However, if anyone does have a way to provide access to remote X displays without the permissions error above, I'm still open to persuasion....

TL;DR

As pointed out by rwb's answer, my questions above about whether Emacs can grant remote access have got things backwards. There's no real problem with Emacs granting access to other users (server-use-tcp and a suitable server-file take care of this): rather the problem is how to allow a process on one machine to open new X windows on other users' X displays (specifically, the Emacs running (start-server) needs to open windows for users who ask it to via emacsclient -c). That answer's beyond the scope of this question.

Alternative solution

As a workaround, we use the following:

  • machine0: tmux -S /tmp/shared-tmux-socket new-session
  • machine1..machineN: ssh -t machine0 tmux -S /tmp/shared-tmux-socket attach

with suitable file permissions on /tmp/shared-tmux-socket.

Then we run a text-mode Emacs in the shared terminal. :-) This does raise some user-spoofing questions, but at least the host can see everything that the guests are doing.

Answer

rwb picture rwb · Sep 23, 2012

This should provide a starting point for what you want.

From the info node (emacs) emacsclient Options

`--server-file=SERVER-FILE'
     Specify a "server file" for connecting to an Emacs server via TCP.

     An Emacs server usually uses an operating system feature called a
     "local socket" to listen for connections.  Some operating systems,
     such as Microsoft Windows, do not support local sockets; in that
     case, Emacs uses TCP instead.  When you start the Emacs server,
     Emacs creates a server file containing some TCP information that
     `emacsclient' needs for making the connection.  By default, the
     server file is in `~/.emacs.d/server/'.  On Microsoft Windows, if
     `emacsclient' does not find the server file there, it looks in the
     `.emacs.d/server/' subdirectory of the directory pointed to by the
     `APPDATA' environment variable.  You can tell `emacsclient' to use
     a specific server file with the `-f' or `--server-file' option, or
     by setting the `EMACS_SERVER_FILE' environment variable.

     Even if local sockets are available, you can tell Emacs to use TCP
     by setting the variable `server-use-tcp' to `t'.  One advantage of
     TCP is that the server can accept connections from remote machines.
     For this to work, you must (i) set the variable `server-host' to
     the hostname or IP address of the machine on which the Emacs server
     runs, and (ii) provide `emacsclient' with the server file.  (One
     convenient way to do the latter is to put the server file on a
     networked file system such as NFS.)

You also may want to look at variables server-auth-dir, server-auth-key and server-port