La problématique est simple : soit deux machines, par exemple un portable et une machine de bureau, le tout sous GNU/Linux/X11, comment faire de sorte à ce que les deux machines forment un seul et même bureau ?
Précisions
Dans cette histoire, le but n'est pas uniquement de placer le bureau de la seconde machine dans le prolongement (au sens clavier/souris du terme) de la première, synergy fait cela déjà très bien tout seul. Il s'agit en fait de pousser la logique un cran plus loin en étendant l'affichage de la machine de bureau sur l'écran du portable. En d'autres termes, avoir une application qui tourne "physiquement" sur la machine de bureau tout en s'affichant sur l'écran du portable. Les avantages étant que le seul CPU plus musclé de la machine de bureau est sollicité et que ce sont les données et paramétrages de la machine de bureau qui sont utilisées.
Les applications de cette approche sont nombreuses, on peut ainsi déplacer sur cet écran supplémentaire des applications importante mais qui prennent de la place (mail, chat, etc). On peut aussi lancer un VmWare pour placer selon ses besoins une machine Windows ou MacOS afin de tester un développement. La seule contrainte étant qu'il serait impossible de déplacer une fenêtre d'une machine à l'autre.
Pour faire cela nous n'avons besoin que de deux choses. Tout d'abord l'indispensable synergy, et tout simplement SSH. Etant entendu que les deux machines communique par un réseau local.
Paramétrage de de Synergy
Je pars ici du principe que cette machine est déjà équipée de X et d'un environnement tel Gnome ou KDE. La première chose qu'il fait faire c'est de paramétrer synergy pour asservir le ou les serveurs X esclaves. Pour cela j'utilise le tutorial sur synergy pour rédiger un /etc/synergy.conf de sorte à placer les deux écrans côte à côte.
Pour que le serveur synergy soit correctement lancé en même temps que notre session graphique, nous allons créer un petit script qui va s'exécuter au moment du lancement de la session X. Ce genre de script se trouve dans le dossier /etc/X11/xinit.d. Le numéro par lequel il commence indique l'ordre de chargement. Le notre s'apellera 35multiX11. 35 pour le placer après le chargement de D-BUS (30) que nous allons voir juste après.
- #! /bin/sh
- synergys
Ensuite, il faut rendre le fichier exécutable (chmod +x ...) et ainsi, dés que votre session de X11 se lance, le serveur synergy est mis en route.
Sur le portable, la seule chose à faire est de lancer le client synergy en même temps que la session, cela se fait très simplement en modifiant (ou créant) le ficher ~/.xinitrc et en ajoutant :
- # On tue un éventuel reste
- pkill synergyc
- # Lancement du client synergy
- synergyc machine_maitre
Paramétrer l'ouverture de liens
Lorsque vous vous connectez sur chaque machine, vous pouvez normalement vous balader avec votre souris de l'une à l'autre. Pour lancer une application sur l'écran du portable, il nous faut maintenant ouvrir une session ssh de celui-ci vers la machine de bureau. Après, dans cette console, exécutez par exemple liferea qui devrait s'afficher sur le portable mais utiliser les réglages de la machine de bureau, logique.
Maintenant, lorsque l'on clique sur un lien dans liferea, cela ne s'ouvre pas sur le firefox de l'autre machine... En effet, FireFox utilise l'identificateur de l'écran (variable DISPLAY) pour savoir où ajouter son onglet. Or cette variable dans une session SSH n'est évidement pas le :0.0 dans lequel FireFox tourne, mais plutôt un localhost:11.0 lié au tunnel créé par SSH.
La "Solution" est donc de se dire que FireFox est toujours sur mon écran de droite : DISPLAY=:0. Il suffit de faire un petit script qui va exporter la valeur de DISPLAY avant d'appeler FireFox
- #! /bin/sh
- export DISPLAY=:0
- /usr/bin/firefox $1
Pour que Gnome utilise ce script, il ne reste plus qu'à lancer Préférences/applications préférées pour remplacer l'appel d'origine à FireFox par celui à notre script.
Et pour que KDE soit au courant, il faut lancer kcontrol/Composants KDE/Sélecteur de Resources pour remplacer l'appel d'origine à FireFox par celui à notre script.
Voilà, c'est "presque" fini 
Presque j’ai dit… En effet il se peut que cela continue de coincer pour des raisons de sécurité. Il faut dans ce cas autoriser l'interaction entre les deux serveurs de manière explicite. C'est le rôle de la commande xhost. Nous allons donc, une fois de plus, ajouter une ligne, avant exec gnome-session, à notre ~/.gnomerc de sorte a donner cette autorisation sur le DISPLAY=:0 :
Et comme il va falloir aussi autoriser les connections au display ouvert de l'autre côté par SSH, nous rajoutons dans ~/.bashrc :
- if [ ! -z $DISPLAY ] ; then
- xhost + > /dev/null
- fi
Faire causer FireFox avec l'aggregateur de nouvelles
Lors de la première version de ce tutoriel, il fallait toute une magouille avec DBUS pour arriver à pouvoir interagir dans l'autre sens, à savoir ajouter un flux à Liferea à partir de FireFox. J'ai laissé la dite magouille en fin de billet pour mémoire mais aujourd'hui il semble que cela fonctionne très bien sans cela. Du coup ce qui suit est la procédure générale permettant d'ajouter de firefox un flux à liferea, avec ou sans portable.
Liferea est fournit avec un petit script, /usr/bin/liferea-add-feed qui fait normalement le boulot. Pour l'ajouter à firefox, là aussi, la procédure c'est diablement simplifiée. Il suffit maintenant d'aller dans les préférences, onglet Applications, aller à Flux WEB et sélectionner Autres... puis le fameux script. Ceci fait, ça marche tout seul.
Lancer X sur le portable à partir de la machine de bureau
Il n'est pas nécessaire, surtout si c'est un petit portable, de lancer toute l'artillerie Gnome. Vous pouvez très bien ne lancer que le serveur X11 avec dans ~/.xinitrc le strict minimum comme un openbox, fbpanel, etc.
Dans cette option, on aime bien l'idée de lancer ce serveur à la main à partir de la machine de bureau. Le seul "hic" c'est qu'un utilisateur ne peut "officiellement" pas lancer un serveur X, je donne ici le résultat pour que Google le mange :
- ssh machine_esclave "startx" &
- xauth: creating new authority file /home/yoran/.serverauth.9780
- Authentication failed - cannot start X server.
- Perhaps you do not have console ownership?
L'astuce cette fois est d'autoriser une telle chose en modifiant, sur la machine esclave
le fichier /etc/pam.d/xserver comme suite :
- #%PAM-1.0
- auth sufficient pam_rootok.so
- auth required pam_console.so
- #auth required pam_permit.so
- account required pam_permit.so
Maintenant vous pouvez lancer, via ssh, votre serveur X à distance et le nouvel écran devrait prendre vie et vous devez pouvoir y aller avec votre souris.
Gestion de DBUS
L'autre aspect à prendre en compte sur la machine "maître" est le partage de la session de DBUS . Rapidement, DBUS est un bus logiciel qui permet, comme DCOP mais de manière standard, aux applications de causer entre elles. Il existe dans les distributions modernes deux instances de DBUS, celle utilisée par le système, et celle locale à la session utilisateur. C'est cette dernière que nous devons chercher à partager.
La session utilisateur de DBUS est crée par le gestionnaire de session de l'environnement graphique, ici gnome-session. Cette session est lancée par dbus-launch qui export la variable DBUS_SESSION_BUS_ADDRESS. C'est cette variable qui permet aux applications de savoir quelle session utiliser pour causer entre elles.
Le « problème » lorsque nous nous connectons via SSH, cette fameuse variable n'existe pas et du coup les applications lancées dans le SSH ne peuvent communiquer avec celles lancées dans la session gnome qui elles, ont cette variable.
Pour régler ce problème, nous allons commencer par ajouter à notre précédent fichier /etc/X11/xinit.d/35multiX11 la ligne suivante :
L'astuce ici est donc de renseigner au lancement de la session, ce fichier ~/.ssh/environment qui est utilisé par ssh pour nourrir l'environement d'une nouvelle session. Mais pour que cela fonctionne, il faut modifier le fichier /etc/ssh/sshd_config pour ajouter la permission PermitUserEnvironment yes et redémarrer le serveur ssh.
Du coup, toute session SSH ouverte sur la machine maître
aura sa bonne variable DBUS et les applications pourront communiquer d'où qu'elles soient lancées.
Conclusion
Ok, c'est un peu de la bidouille mais avouez que c’est fascinant ce que X11 et un peu d’huile de ou de permettent de faire ! Je ne voudrais pas jouer les trolls provoquant mais je vois mal ce genre de montage fonctionner avec Windows (sans Cygwin .