Cela fait maintenant longtemps que je bricole avec trois écrans. A l'origine il s'agissait "juste" de deux cartes vidéo collées dans la même bécane, puis ce fût deux machines différente histoire de "rentabiliser" la consommation électrique de mon serveur local. Aujourd'hui le serveur a disparu au sous-sol pour être remplacé par l'U810 sur sa station d'accueil. Dans tous les cas c'est la même problématique : deux bureaux différents qui doivent communiquer de manière suffisamment transparente pour donner l'illusions de former un seul et même espace.

Paramétrage de Synergy

Avec SSH, synergy est la clef de voûte de ce petit bricolage. Pour ceux qui ne le connaissent pas encore, cet outil multi-plateforme permet de contrôler avec un même clavier et une même souris un ensemble de machine MacOS, Linux ou même Windows. En paramétrant simplement la disposition physique des écrans, il est ainsi possible de glisser la souris d'une machine à l'autre sans même s'en rendre compte. Les entrées clavier vont là où le pointeur de souris se trouve. L'architecture de synergie se compose donc d'un serveur qui est hébergé sur la machine à laquelle sont connectés physiquement clavier et souris, et d'autant de clients que nécessaires pour toutes les machines à relier au serveur.

Sous Mandriva, l'installation passe par un urpmi synergy sur chacune des machines (clients et serveur) ensuite, seul le serveur est a paramétrer, les clients se contentant d'être lancés en indiquant où le serveur se trouve sur le réseau.

Dans le cas qui nous intéresse, synergy sera donc paramétré pour placer l'écran de l'U810 à gauche des deux écrans de la machine de bureau. Et cela se fait très simplement en éditant un bête fichier texte sur le serveur, /etc/synergy.conf:

Là vous devinez comment tout cela va fonctionner. Grâce à ce fichier de configuration, j'ai déclaré que l'écran de l'U810 (netbook) était à la gauche de celui de mon PC, que celui du PC était à la droite du netbook.

Il suffit maintenant de lancer le serveur Synergy (synergys) sur le desktop par synergys. Le processus se met automatiquement en mode démon. De la même manière, sur le netbook, je lance cette fois le client par synergyc desktop, où desktop est le nom réseau de la machine serveur. Déjà vous devriez pouvoir passer avec votre souris d'une machine à l'autre en la faisant "taper" sur le bord gauche de l'écran du PC pour qu'elle passe comme par magie sur l'écran du netbook. Le clavier est alors utilisable à cet endroit. Et comble du fin, le presse-papier est aussi exporté !! Si vous copiez du texte d'un côté, vous pouvez le coller de l'autre. C'est pas beau ça ?

Pour automatiser tout cela, il faut que les deux commandes soient lancées sur chaque machine à l'ouverture de session. Cela se fait très simplement en utilisant sous Gnome Système/Préférences/Sessions/Programmes au démarrage et en ajoutant les bonnes commande sur chacune des deux machines.

Pour aller encore un peu plus loin, il peut être utile que le netbook soit connecté au serveur synergy avant la session, de sorte à pouvoir permette de rentrer identifiant et mot de passe avec le clavier et la souris du serveur.

Pour ce faire, il suffit sur le netbook d'ajouter un fichier /etc/X11/synergy.xsetup :

Un petit coup de chmod +x /etc/X11/synergy.xsetup sur le museau et le client devrait se connecter au serveur dés l'apparition de l'invite de connexion.

Lancement des applications

Nous avons maintenant lié nos deux écrans. cependant pour que ce soit réellement le même bureau il faut que l'on puisse sur le netbook afficher des applications qui en réalité s'exécutent sur le serveur. Pour cela il existe deux solutions, soit un freeNX ou beaucoup plus simplement un SSH configuré pour faire du déport de port X11 (voir ici pour plus d'info). Vu la proximité des deux machines, c'est la deuxième solution qui est adoptée, le réseau local supportant sans problème le débit imposé par la communication entre l'application et le serveur X11. Ainsi pour lancer par exemple evolution, il suffit juste sur le netbook d'ouvrir une session ssh, via un terminal, sur le serveur et de.. lancer evolution.

Paramétrer l'ouverture de liens

Maintenant, lorsque l'on clique sur un lien dans liferea, cela ne s'ouvre pas sur le firefox du desktop mais sur celui du netbook... En effet, FireFox utilise l'identifiant 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 si FireFox est toujours sur mon écran de droite, autrement dit DISPLAY=:0, il suffit de faire un petit script qui va systématique ouvrir les URL sur cet écran en exporter la valeur de DISPLAY avant d'appeler FireFox

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. Du coup toutes les applications Gnome ouvrent maintenant sur le bon firefox.

Il se peut que cela continue de coincer pour des raisons de sécurité. Pour régler cela, lancez en tant que root gdmsetup et dans l'onglet sécurité, cochez la case Autorisé la connexion uniquement si l'utilisateur possède son répertoire personnel. Au redémarrage de votre session sur la machine desktop, le problème devrait être réglé.

Faire causer FireFox avec l'aggregateur de nouvelles

Avec liferea est fournit un petit script, /usr/bin/liferea-add-feed qui fait normalement le boulot. Et 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.

Maintenant cela marchera très bien si liferea est lancé directement sur le desktop, un peu moins s'il est affiché par le netbook. La raison en est que dans le second cas, le liferea lancé via ssh n'est pas connecté à dbus. Pour que cela fonctionne, il faut renseigner la variable DBUS_SESSION_BUS_ADDRESS qui contient la référence au serveur DBUS principal. Et 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 cela, nous allons commencer par créer un fichier /etc/X11/xinit.d/35export_dbus en y mettant le contenu suivant :

L'astuce ici est donc de renseigner au lancement de la session, ce fichier ~/.ssh/environment qui est utilisé par ssh pour nourrir l'environnement 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 desktop aura sa bonne variable DBUS et les applications pourront communiquer d'où qu'elles soient lancées.

Lancer X sur le portable à partir de la machine de bureau

Il n'est pas nécessaire, surtout si votre "écran externe" est une petite machine qui ne fait cela, 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 :

L'astuce cette fois est d'autoriser une telle chose en modifiant, sur la machine esclave le fichier /etc/pam.d/xserver comme suite :

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.

Conclusion

J'avais prévenu c'est du bricolage, mais un bricolage que j'utilise quotidiennement depuis plus de deux ans et qui marche très bien0. Et 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 .

Comments