Raspberry pi 3 * reverse * bureau à distance

J'ai une machine locale (A) et Raspberry PI 3 (B).
B a un moniteur HDMI connecté et exécute Raspbian OS.

Je veux exécuter l'application X sur la présentation A-dire Libre Office Impress que j'ai sur A, et la rendre visible (être affichée sur) sur l'écran connecté à B.
Je veux faire ça devant une machine:

  • pas par ssh -X to_A de B,
  • ni utiliser VNC de B pour get la sortie de A

Je ne cherche pas:

  • Exécuter l'application X sur B en utilisant ssh depuis A et avoir sa sortie affichée sur A (cela peut être fait par les from_a $ ssh -X machine_B ou rdp / remmina / vnc)
  • Exécuter l'application X sur B en utilisant ssh depuis A et avoir sa sortie affichée sur B (cela peut être fait en exportant l'affichage dans ssh et la configuration correcte de xhost, par exemple from_a $ ssh machine_b from -> at_a_but_sshed_onto_b $ xhost + && export DISPLAY=:0 xeyes )
  • solution qui nécessite un access physique direct à B

Ce que j'ai essayé, c'était setup (B) pour exécuter des éléments X distants … si je n'avais pas oublié quoi que ce soit – depuis nmap -p6000 machine_B returnné ce port et fermé (depuis la command line A):

 A_machine $ env DISPLAY=B_machine:0 xeyes 

où B_machine est défini dans /etc/hosts ainsi que ~/.ssh/config échoue.

Ce que je soupçonne, c'est que ça me manque tout à fait de copyr X11 magic_cookies de .Xauthority … mais peut-être que cette étape n'est pas nécessaire et qu'il y a un moyen plus simple?

Edit: en réponse à la question @Rostislav Kandilarov – il semblerait que lightdm démarre le server X, mais bientôt je pourrai vérifier son lundi, ainsi que vérifier si elle commence par --nolistn tcp .

(Edited, vieille réponse ci-dessous)

Sans avoir à toucher B, le problème avec l'exécution d'un server X sur B et la connection avec une application sur A est que ce server X utilisera uniquement des périphériques d'input (keyboard, souris ) connecté à B. Donc, pour utiliser votre application, vous devez utiliser ces périphériques d'input, que vous ne voulez pas.

En principe, vous pouvez essayer de partager les périphériques d'input de A, mais la construction commence vraiment à devenir byzantine …

Donc VNC est beaucoup plus facile dans cette situation.

Configurez un vnc4server sur A. Ce server servira également de server X pour les applications sur A. Démarrez un xvnc4viewer sur A et utilisez-le pour démarrer et contrôler votre application. Démarrez un autre vncviewer sur B et connectez-le au server sur A, il affichera l'application. Il peut être aussi simple que directvnc (utilisez le framebuffer du RaspPi directement, pas de détour supplémentaire sur X, donc less de charge de travail pour le RaspPi), ou si vous voulez continuer à exécuter un server X existant sur B, ou xvnc4viewer .


Le moyen le plus simple est d'utiliser un bureau distant comme VNC , très probablement déjà disponible en tant que package dans votre dissortingbution. Cela fonctionne généralement beaucoup mieux que X forwarding via ssh ou autrement, car il est beaucoup mieux compressé et n'utilise pas de primitives X sur le fil.

Bien sûr, il existe également plusieurs façons de configurer le transfert X, sur SSH ou directement. Par exemple, vous pouvez vous connecter via ssh -X de B à A, exécuter votre application sur A, et avoir la sortie affichée sur B. (Vous avez exclu la direction inverse, mais n'a rien dit à ce sujet, je ne sais pas si tu veux ça).

Vous pouvez également configurer le server X pour une session distante via XDMCP . Ou faites une seule application utiliser un server X distant en utilisant les parameters xauth et DISPLAY appropriés.

Mais je recommand toujours d'essayer VNC en premier.

Donc, si vous utilisez Raspbian OS sur (B), si vous n'avez pas effectué de personnalisation spécifique, vous avez probablement utilisé lightdm.

Pour sûr, vous devez indiquer à lightdm d'utiliser le server X pour écouter tcp (port 6000). Vous le faites en définissant xserver-allow-tcp=true dans le file conf dans la section globale [Seat:*] . Vous devrez peut-être spécifier explicitement xserver-command=X -listn tcp (jetez un oeil ici ). C'est votre choix entre n'importe quel file supplémentaire dans /etc/lightdm/lightdm.conf.d/*.conf ou directement dans /etc/lightdm/lightdm.conf .

Ensuite, si vous ne vous souciez pas trop de la security, vous devrez probablement exécuter (B) une forme de command xhost + IP_OF_(A) comme xhost + IP_OF_(A) . Si vous vous souciez des vulnérabilités du réseau local, vous ne devriez pas utiliser directement X sur tcp en premier lieu, mais sans ssh vous pouvez donner un peu de hack en échangeant un MIT-MAGIC-COOKIE entre (A) et (B) xauth extract - $DISPLAY | ssh (A) xauth merge - xauth extract - $DISPLAY | ssh (A) xauth merge - .

Redémarrez ensuite lightdm service lightdm restart ou systemctl restart lightdm.service fonction de la version de votre operating system.

Dernier – vérifier (B) si Xorg écoute 6000 netstat -antp | grep -F 6000 netstat -antp | grep -F 6000