Utiliser le serveur Emacs et emacsclient sur d’autres machines comme d’autres utilisateurs

Je sais qu’après avoir appelé (start-server) dans une session Emacs existante, je peux utiliser emacsclient -c (sur le même ordinateur) pour créer de nouveaux frameworks qui se connectent à ce serveur, de sorte que chaque nouvelle image créée par emacsclient ait access à le même ensemble d’états partagés (par exemple, tampons).

La plupart de la documentation que j’ai trouvée se concentre sur le cas d’utilisation “donnez-moi un access rapide à mon Emacs local”. Il y a donc deux choses que je n’ai pas encore vues:

  1. Est-ce que emacsclient -c accéder aux serveurs Emacs lancés par d’ autres utilisateurs ou est-il câblé pour détecter uniquement les sessions lancées par mon propre utilisateur?

  2. Le serveur Emacs (directement ou indirectement) prend-il en charge les connexions à distance? C’est-à-dire, existe-t-il un moyen de configurer Emacs (impliquant éventuellement SSH) qui permet aux appels à emacsclient -c sur les machines distantes d’avoir access à l’état local de mon serveur Emacs?

(Au cas où vous ne l’auriez pas déjà deviné, ce que je voudrais faire en fin de compte, c’est combiner les deux techniques ci-dessus pour fournir un support rudimentaire de l’édition collaborative.)


Ceci est un problème réel, alors voici ce que je travaille avec:

  • La fonctionnalité nécessaire doit déjà être intégrée à Emacs (23.3.1, 64 bits). Je peux m’étendre aux extensions d’Emacs à partir des référentiels Ubuntu standard, mais je préfère ne pas le faire. (Ce qui, je crois, exclut Rudel , malheureusement.)
  • Aucun nouvel utilisateur ou usurpation d’utilisateur. Les solutions doivent fonctionner avec l’ensemble de comptes d’utilisateurs existants, et les utilisateurs ne doivent pas prétendre être d’autres utilisateurs (par exemple, via su ou ssh ).

Si cela fait une différence, les machines sont sur un LAN privé, les clients et serveurs OpenSSH sont installés (et en cours d’exécution), et tous les utilisateurs peuvent se connecter (à leur propre compte) à toutes les machines, mais ils n’ont pas de système de fichiers partagé.


Donc, quelqu’un sait-il si le serveur Emacs peut

  • accorder l’access à d’autres utilisateurs, ou
  • fournir un access à distance?

MODIFIER

Comme indiqué dans la réponse de rwb, il est clair que les nouvelles fenêtres ouvertes localement en exécutant emacsclient -c sont en fait créées par le processus du serveur Emacs distant. En d’autres emacsclient , emacsclient déclenche simplement le comportement approprié sur le serveur. Cela provoque des problèmes avec des parameters d’affichage incorrects, car le serveur n’a normalement pas access au bureau local (voir ci-dessous). Cependant, je peux maintenant me connecter à une session Emacs distante si j’utilise la séquence de commandes suivante:

Dans un terminal, où 1.22.333.44 est l’adresse IP de remotehost :

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

Puis dans un autre (sur la même machine):

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

La commande emacsclient permet au serveur Emacs distant (trouvé dans /tmp/server-file ) d’ouvrir une fenêtre graphique Emacs (sur l’affichage local) qui partage son état avec la session Emacs sur l’hôte distant.

Comme le serveur Emacs distant a été démarré via ssh -X , SSH lui donne access à mon affichage local via un affichage “fake” :10 . Le DISPLAY=:10 transmis (via emacsclient ) provoque l’ouverture d’une fenêtre sur mon bureau local.


Bien que l’approche ci-dessus coche la case “Exécuter le serveur Emacs sur une machine distante, connectez-vous en utilisant emacsclient localement”, elle est très limitée. En fait, il n’est pas très différent d’exécuter le serveur et les clients localement en tant qu’utilisateur unique: la seule différence est que le serveur est maintenant distant et a donc access à différentes ressources du système.

Malheureusement, le lancement via ssh -X est la seule façon dont j’ai réussi à ouvrir une fenêtre sur le serveur X d’une autre machine:

  • Spécifier un DISPLAY=remote:0 base DISPLAY=remote:0 va nulle part (puisque les serveurs Ubuntu X sont démarrés avec l’option -nolisten tcp ).

  • La connexion via SSH, puis l’utilisation de DISPLAY=:0 échoue également, mais cette fois uniquement en raison du manque de références d’authentification appropriées. (Je crois que c’est le cas, de toute façon: le message d’erreur indique de manière cryptée No protocol specified / Can't open display .)

Je pense que trouver un moyen de contourner le deuxième problème me rapprocherait probablement d’une solution.


Ayant lu les articles sur http://comments.gmane.org/gmane.emacs.devel/103350 (commençant au post ’25 oct 14:50 », à peu près à mi-chemin), je commence à me demander si cela pourrait être une des rares choses qu’Emacs ne peut pas faire (c.-à-d. c’est impossible ;-)).

Cependant, si quelqu’un dispose d’un moyen de fournir un access aux écrans X distants sans l’erreur d’autorisation ci-dessus, je suis toujours ouvert à la persuasion ….

TL; DR

Comme indiqué par la réponse de rwb, mes questions ci-dessus sur la capacité d’Emacs à accorder un access à distance ont des conséquences négatives. Il n’y a pas vraiment de problème avec Emacs autorisant l’access à d’autres utilisateurs ( server-use-tcp et un server-file approprié): le problème est plutôt de savoir comment autoriser un processus sur une machine à ouvrir de nouvelles fenêtres X sur d’autres utilisateurs. X affiche (en particulier, l’Emacs en cours d’exécution (start-server) doit ouvrir des fenêtres pour les utilisateurs qui le demandent via emacsclient -c ). Cette réponse dépasse le cadre de cette question.

Solution alternative

Pour contourner ce problème, nous utilisons les éléments suivants:

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

avec les permissions de fichiers appropriées sur /tmp/shared-tmux-socket .

Ensuite, nous exécutons un Emacs en mode texte dans le terminal partagé. 🙂 Cela soulève des questions d’usurpation, mais au moins l’hôte peut voir tout ce que font les invités.

Je pense que ce que vous demandez est impossible par définition, parce que si vous donnez à un utilisateur distant un access illimité à votre Emacs, cela équivaut à un «usurpation d’utilisateur» tout comme à ce que cet utilisateur distant accède à un shell via ssh. Pour le préciser, du sharepoint vue de la sécurité, c’est probablement une mauvaise idée.

En outre, le fait de laisser deux utilisateurs accéder à un seul Emacs n’est pas aussi bon que vous pourriez l’espérer. Il n’est pas conçu avec un access simultané en tête. Cela fait des années que je l’ai essayé, alors les choses ont peut-être évolué un peu, mais quand je l’ai fait, c’était pour le moins bizarre.

Je vais quand même essayer de répondre à votre question.

Il semble que vous y réfléchissiez de front, car, de manière contre-intuitive, en termes de réseau, l’affichage X11 est le serveur et l’application X11 est le client. Cela est surprenant, car l’affichage est généralement local pour l’utilisateur et l’application s’exécute sur un serveur distant.

Vous pouvez demander à un emacs en cours d’exécution de se connecter à un affichage distant et d’ouvrir une nouvelle fenêtre avec make-frame-on-display . Pour que cela fonctionne, le propriétaire de cet écran devra vous accorder l’access.

Nous supposerons que host-l est l’ordinateur qui exécute Emacs et que vous souhaitez le rendre accessible à un utilisateur de l’affichage 0 sur l’ host-r . Sachez que vous avez dit que vous ne souhaitez pas utiliser le transfert SSH. Si vous suivez cette méthode, tout le trafic passera sur le réseau sans être crypté.

Assurez-vous d’abord que l’ host-r:0 accepte les connexions TCP. Vous ne mentionnez pas votre système d’exploitation, mais c’est probablement la valeur par défaut sous Unix et probablement pas sous Linux (pour des raisons de sécurité). Si, par exemple, les -nolisten tcp suivants mentionnent -nolisten tcp vous devrez modifier cette configuration.

 host-r$ ps -ef | grep X 

Ensuite, demandez à l’utilisateur de l’hôte-r d’exécuter ce qui suit et de vous envoyer le résultat. Veillez à les avertir que cela vous permettra de prendre le contrôle complet de leur session de bureau en cours, si vous le souhaitez.

 host-r$ xauth list $DISPLAY host-r/unix:0 MIT-MAGIC-COOKIE-1 01234567890abcdef0123456789abcd 

C’est effectivement le “mot de passe” pour l’affichage. Sur l’ host-l , placez-le là où Emacs pourra le trouver avec:

 host-l$ xauth add host-r:0 MIT-MAGIC-COOKIE-1 01234567890abcdef0123456789abcd 

Maintenant, entrez Mx make-frame-on-display host-r: 0 et une fenêtre Emacs devrait apparaître sur l’écran distant.

Cela devrait fournir un sharepoint départ pour ce que vous voulez.

A partir du nœud info (emacs) Options emacsclient

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

Vous pouvez également vouloir regarder les variables server-auth-dir , server-auth-key et server-port

Aaron Gallagher a implémenté une solution: http://blog.habnab.it/blog/2013/06/25/emacsclient-and-tramp/

Cela fonctionne (AFAIU) comme:

  • Le serveur emacs est démarré avec tcp
  • Il ouvre une connexion à un système distant avec tramp-sh, en ouvrant un port direct (“back channel”)
  • tramp-sh est conseillé de copier un fichier de cookie d’authentification étendue sur le système distant
  • Sur le système distant, il appelle un script shell spécial emacsclient.sh qui émule emacsclient mais qui préfixe les noms de fichiers avec le préfixe correspondant trouvé dans le cookie d’authentification étendue.

J’ai ajouté un commentaire à son article de blog proposant que cette idée soit discutée et améliorée sur emacs-devel.

Si vous faites cela pour permettre aux utilisateurs de modifier à distance des fichiers, vous voudrez peut-être examiner le “mode tramp”

http://emacswiki.org/emacs/TrampMode