Je sais qu'après avoir appelé (start-server)
Dans une session Emacs existante, je peux ensuite utiliser emacsclient -c
(Sur le même ordinateur) pour créer de nouveaux cadres qui se connectent à ce serveur, de sorte que chaque nouveau cadre créé par emacsclient
a accès au même ensemble d'états partagés (par exemple des tampons).
La plupart de la documentation que j'ai trouvée se concentre sur le cas d'utilisation "Donnez-moi un accès rapide à mes Emacs locaux", et il y a donc deux choses dont je n'ai pas encore vu les détails:
emacsclient -c
Peut-il accéder aux serveurs Emacs démarrés par autres utilisateurs, ou est-il câblé pour détecter uniquement les sessions démarrées par mon propre utilisateur?
Le serveur Emacs prend-il en charge (directement ou indirectement) les connexions à distance? Autrement dit, existe-t-il un moyen de configurer Emacs (impliquant éventuellement SSH) qui permet aux appels à emacsclient -c
Sur à distance d'avoir accès aux locaux état de mon serveur Emacs?
(Au cas où vous ne l'auriez pas déjà deviné, ce que j'aimerais finalement faire, c'est combiner les deux techniques ci-dessus pour fournir un support d'édition collaboratif rudimentaire.)
Il s'agit d'un problème réel, alors voici ce avec quoi je travaille:
su
ou ssh
).Si cela fait une différence, les machines sont sur un réseau local privé, ont des clients et des serveurs OpenSSH installés (et en cours d'exécution), et tous les utilisateurs peuvent se connecter à (leur propre compte sur) toutes les machines, mais ils n'ont pas de système de fichiers partagé.
Alors, est-ce que quelqu'un sait si le serveur Emacs peut
ÉDITER
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 serveur distant Emacs. Autrement dit, emacsclient
déclenche simplement le comportement pertinent sur le serveur. Cela provoque certains problèmes avec des paramètres d'affichage incorrects, car le serveur n'a normalement pas accès 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
amène le serveur Emacs distant (dont il trouve les détails dans /tmp/server-file
) À ouvrir une fenêtre graphique Emacs (sur l'affichage local) qui partage l'état avec la session Emacs sur la télécommande Hôte.
Puisque le serveur Emacs distant a été démarré via ssh -X
, SSH lui donne accès à mon affichage local via un affichage "faux" :10
. Le DISPLAY=:10
Qui lui est passé (via emacsclient
) provoque donc 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 à celle-ci en utilisant emacsclient
localement", c'est très limité. En fait, ce n'est pas très différent d'exécuter le serveur et les clients tous localement en tant qu'utilisateur unique: la seule différence est que le serveur est maintenant distant, donc a accès à différentes ressources système.
Malheureusement, le lancement via ssh -X
Est la seule façon d'ouvrir avec succès une fenêtre sur le serveur X d'une machine différente:
La spécification d'un DISPLAY=remote:0
De base ne mène à rien (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 d'informations d'authentification appropriées. (Je crois que c'est le cas, de toute façon: le message d'erreur dit cryptiquement No protocol specified
/Can't open display
.)
Je pense que trouver un moyen de contourner le deuxième problème me rapprocherait probablement beaucoup d'une solution.
Après avoir lu les articles sur http://comments.gmane.org/gmane.emacs.devel/10335 (à partir du message '25 oct 14:50 ', environ à mi-chemin), je suis commence à se demander si cela pourrait être l'une des rares choses qu'Emacs ne peut pas faire (c'est à dire impossible ;-)).
Cependant, si quelqu'un a un moyen de fournir un accès aux écrans X distants sans l'erreur d'autorisation ci-dessus, je suis toujours ouvert à la persuasion ....
TL; DR
Comme l'a souligné la réponse de rwb, mes questions ci-dessus sur la question de savoir si Emacs peut accorder l'accès à distance ont fait reculer les choses. Il n'y a pas de vrai problème avec Emacs accordant l'accès à d'autres utilisateurs (server-use-tcp
Et un server-file
Approprié s'en occupent): le problème est plutôt comment autoriser un processus sur une machine pour ouvrir de nouvelles fenêtres X sur les écrans X d'autres utilisateurs (en particulier, Emacs exécutant (start-server)
doit ouvrir des fenêtres pour les utilisateurs qui le demandent via emacsclient -c
). Cette réponse dépasse la portée de cette question.
Solution alternative
Pour contourner ce problème, nous utilisons les éléments suivants:
tmux -S /tmp/shared-tmux-socket new-session
ssh -t machine0 tmux -S /tmp/shared-tmux-socket attach
avec les autorisations de fichier 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 d'identité, mais au moins l'hôte peut voir tout ce que les invités font.
Je pense que ce que vous demandez est impossible par définition, parce que si vous donnez à un utilisateur distant un accès illimité à vos Emacs, cela revient tout autant à "usurper l'utilisateur" que de laisser cet utilisateur distant accéder à un Shell via ssh. Pour l'exprimer, d'un point de vue de la sécurité, c'est probablement une mauvaise idée.
De plus, le fait de laisser deux utilisateurs accéder à un Emacs n'est pas aussi bon que vous pourriez l'espérer. Il n'est pas conçu avec un accès simultané à l'esprit. Cela fait des années que je l'ai essayé, donc les choses ont peut-être évolué un peu, mais quand je l'ai fait, c'était pour le moins excentrique.
Je vais quand même essayer de répondre à votre question.
On dirait que vous pensez à cela de l'avant, car, contre-intuitivement, en termes de réseau, l'écran X11 est le serveur et l'application X11 est le client. Cela est surprenant car, généralement, l'affichage est 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 écran distant et d'ouvrir une nouvelle fenêtre avec M-x make-frame-on-display. Pour que cela fonctionne, le propriétaire de cet affichage devra vous en accorder l'accès.
Nous supposerons Host-l
est l'ordinateur qui exécute Emacs et que vous souhaitez rendre accessible à un utilisateur de l'affichage 0 sur Host-r
. Sachez que vous avez dit que vous ne vouliez pas utiliser le transfert SSH, donc en suivant cette méthode, tout le trafic traversera le réseau non crypté.
Tout d'abord, assurez-vous que l'affichage Host-r:0
accepte 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 mentions suivantes -nolisten tcp
alors vous devrez changer cette configuration.
Host-r$ ps -ef | grep X
Ensuite, demandez à l'utilisateur de Host-r d'exécuter ce qui suit et de vous envoyer la sortie. Assurez-vous de les avertir que cela vous permettra de prendre le contrôle complet de leur session de bureau actuelle, si vous le souhaitez.
Host-r$ xauth list $DISPLAY
Host-r/unix:0 MIT-MAGIC-COOKIE-1 01234567890abcdef0123456789abcd
Il s'agit en fait du "mot de passe" de l'affichage. Sur Host-l
, placez-le là où Emacs pourra le trouver avec:
Host-l$ xauth add Host-r:0 MIT-MAGIC-COOKIE-1 01234567890abcdef0123456789abcd
Entrez maintenant M-x make-frame-on-display Host-r:0 et une fenêtre Emacs devrait apparaître sur l'écran distant.
Cela devrait fournir un point de départ pour ce que vous voulez.
Depuis le 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:
J'ai ajouté un commentaire à son billet de blog proposant cette idée à discuter et à améliorer sur emacs-devel.
Si vous faites cela pour permettre aux gens de modifier à distance des fichiers, vous voudrez peut-être regarder le "mode tramp"