Lancer des applications graphiques à distance

Comme vous ne l'ignorez peut-être pas, X11 est une technologie client/serveur. C'est à dire que lorsqu'une application est lancée, elle n'écrit jamais directement sur l'écran mais se connecte, par l'intermédiaire d'un kit graphique (Qt, GTK, etc) à un serveur d'affichage, le fameux Xorg exploitant la norme X11. C'est ce serveur qui recueille les entrées (clavier et souris) pour le client, et c'est aussi lui qui affiche physiquement les informations. Ainsi, à chaque fois qu'une application X11 veut afficher un bouton, ou une image, c'est à ce serveur que cette demande est transmise et c'est lui qui effectue le rendu visuel.

Alors évidemment lorsque le client et le serveur sont sur une même machine, tout ceci ne va pas sans une certaine perte de performance par rapport, par exemple, à Windows dont les applications se passent de cet intermédiaire. Cependant les impacts sur la vitesse sont limités à plusieurs étages comme par l'utilisation de sockets rapides (sockets UNIX) au lieu des classiques sockets sur IP, ou encore par un accès direct au GPU dans des cas critiques comme la 3D ou la vidéo.

Maintenant cette toute relative perte de performance ne doit pas faire oublier les immenses avantages de cette solution : la transparence réseau. En effet déporter l'affichage d'une application sur une machine distante, exécuter sur son écran local une application qui se trouve sur un serveur distant, tout cela et bien d'autres choses encore sont rendues possibles grâce au couple client/serveur X11.

Cette transparence réseau n'est pas un coquetterie d'Unixien, comme peut l'être ce maudit pulseaudio. Il faut bien comprendre qu'à l'origine une architecture UNIX classique se composait d'un ou plusieurs serveur "puissant" et d'une myriade de terminaux graphiques causant couramment le X11 "en dur", le tout communiquant sur un LAN 1Mb/s.

A l'époque les kits graphiques était assez pauvre ce qui permettait une bonne réactivité avec des LAN de faible performance. Cependant X11 était aussi utilisable à travers internet et de bon vieux modems RTC, par exemple en utilisant un proxy LBX.

Aujourd'hui la transparence réseau offerte par X11 ne touche pas la majorité de ceux qui n'utilisent qu'une machine. Pour les autres c'est un véritable trésor permettant, et c'est tout le sujet de ce papier, de lancer à distance des applications avec un retour visuel local. Pour y parvenir nous avons principalement trois méthodes. Soit nous utilisons le mode du X11 ancestral, exploitant la transparence native sans artifice. Soit nous exploitons la redirection de ports de SSH, pour s'affranchir des limites de notre LAN. Soit enfin, pour booster les performances, nous pouvons utiliser un compresseur de protocole X11, freeNX.

Le cas classique d'utilisation d'un serveur X11 à travers un réseau correspond au besoin d'exécuter sur un serveur distant sans écran ni clavier une commande de type "graphique". La transparence réseau de X11 nous permettra donc une exécution distante de la commande (CPU, disques, etc) avec un visuel et des entrées claviers/souris locales.

L'option \"native\"

Comme nous l'avons vu, un serveur X11 utilise les sockets pour communiquer avec le client. Et pour que cette communication soit la plus rapide possible, il en utilise deux types : des sockets "lents" TCP/IP, et des sockets "rapides" UNIX. Dans le cas d'un serveur local parlant à une application locale, le socket utilisé est systématiquement de type UNIX.

Pour des raisons de sécurité, il y a de forte chance que votre serveur X soit paramétré de sorte à ne pas utiliser les sockets TCP/IP, et donc de ne pas permettre son utilisation par une machine distante. Nous allons donc changer cela en ayant conscience que cette manipulation n'est sure que sur un réseau local de confiance et protégé du réseau public.

Le lancement de votre serveur X11 est effectué par l'intermédiaire d'un gestionnaire de session, par exemple GDM pour Gnome. Pour autoriser les clients distant à utiliser ce serveur X11 via TCP, il faut donc lancer en tant que root l'outil gdmsetup, aller dans l'onglet sécurité, et décocher la ligne Refuser les connexions TCP au serveur X. Ceci fait vous pouvez fermer gdmsetup et relancer votre serveur X. Au retour, le port 6000 correspondant à l'écran X11 :0.0 (si c'est :1.0 le port sera 6001, et ainsi de suite) devrait être écouté par le serveur :

root#netstat -anlp | grep X | grep -v STREAM

tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 5667/X

root# 

vérification du serveur X11 en écoute

Ceci fait, nous allons pouvoir nous connecter sur la machine distante, par exemple avec SSH, et y lancer une commande graphique, par exemple evolution :

gaston$ssh machine_distante

gaston@machine_distante>DISPLAY=mon_desktop:0.0 evolution

gaston@machine_distante> 

Utilisation de la transparence native de X11

C'est aussi simple que cela. Tout passe par l'utilisation de la variable DISPLAY qui indique à l'application où se trouve le serveur X11 à utiliser. En local, votre variable DISPLAY est sûrement :0.0. Le fait qu'il n'y ait rien devant le : indique au client que le serveur est local. Dans notre exemple il va donc aller sur la machine mon_desktop. 0.0 indique d'utiliser l'écran .0 de la carte 0.

Si tout a fonctionné, c'est nickel. Il est possible que votre serveur soit configuré pour refuser les connexions externes et vous aurez alors obtenez l'erreur suivante :

gaston$ssh machine_distante

gaston@machine_distante>DISPLAY=mon_desktop:0.0 evolution

No protocol specified

Impossible d'ouvrir l'affichage :

Exécuter « evolution --help » pour obtenir la liste complète des options en ligne de commande.

gaston@machine_distante> 

Erreur d'autorisation

Ce qui compte ici c'est le No protocol specified qui dit, à qui sait le comprendre, que vous devez d'abord autoriser les connexions et lançant sur la machine secondaire la commande suivante :

gaston$xhost +

access control disabled, clients can connect from any host

gaston$ssh machine_distante

gaston@machine_distante>DISPLAY=mon_desktop:0.0 evolution&

gaston@machine_distante> 

Autorisation de tous les accès à la machine secondaire

Et là, ça marche...

L'option SSH

SSH permet la redirection de ports, et plus particulièrement est capable de rediriger le socket UNIX d'un serveur distant sur un socket TCP/IP local. Cette caractéristique nous permet en toute simplicité de faire la même chose que précédemment, mais à travers une connexion chiffrée convenant mieux à un réseau LAN moins sécurisé. Utilisé avec l'option -X (certaines configuration font cela par défaut), ssh va ainsi automatiquement changer la variable DISPLAY pour pointer sur son "faux" serveur X11 local :

gaston$ssh -X machine_distante

gaston@machine_distante>echo $DISPLAY

localhost:11.0

gaston@machine_distante>evolution&

gaston@machine_distante> 

lancement d'évolution à travers SSH

Là, plus besoin d'autorisation via xhost ni d'écoutes de port TCP/IP, tout se fait automatiquement par la grâce de SSH. Maintenant cette méthode n'est pas sans défaut. En effet, si la machine distante est un peu légère, le chiffrement temps réel de toutes les données circulant dans le tuyau SSH vont pénaliser notablement les performances. Pour un LAN sûr, la première méthode est donc largement préférable.

Concernant un réseau distant, par exemple à travers internet, c'est le volume de données échangé qui va pénaliser les performances. Il est donc plus sage d'utiliser solution suivante, qui combine SSH à une compression intelligente des données X11.

L'option FreeNX

De NoMachine à FreeNX

FreeNX est la version libre d'un excellent produit NoMachine. L'objectif de ces serveurs est de permettre, même à très bas débit, de "transporter" les données X11 d'un serveur distant à une machine locale, et ce même sous Windows.

L'idée de NoMachine exploiter le tube chiffré SSH mais en le combinant avec une compression, optimisation et mise en cache pour réduire au minimum le volume de données échangées. Le résultat d'une qualité et d'une rapidité étonnante.

Le système NoMachine ne demande aucune modification des applications qui utilise le protocole X11 classique. En revanche il n'utilise pas directement le serveur X11 local et passe, comme VNC, par un client gratuit fournit par NoMachine et disponible sur GNU/Linux, Windows, MacOS et Solaris.

Le serveur NX était à l'origine seulement commercial et les sources pas toutes libres. C'est pour cela qu'est né le projet FreeNX permettant d'intégrer dans toutes les distributions un serveur libre exploitant le protocole NX. Ceci dit, FreeNX ne serait rien sans la société NoMachine, donc pensez-y pour un usage en entreprise et prenez plutôt les licences chez eux.

Mise en oeuvre

L'installation du serveur FreeNX sur la machine distante est très simple, il suffit juste de faire un urpmi freenx. Ceci fait, il faut indiquer à freenx que l'utilisateur gaston est autorisé à s'y connecter :

root#nxserver --adduser gaston --system

root#nxserver --passwd gaston

mon_de_passe_gaston

root# 

Ceci fait, il faut maintenant télécharger et installer le client NX sur votre machine. Ensuite, il ne reste alors plus qu'à tester. Pour cela lancez le nxclient, ce qui devrait faire apparaître une fenêtre de connexion. Saisissez gaston comme login, le mot de passe, donnez le nom qui vous amuse à la session, puis cliquez sur configure...

Dans le cadre Server, saisissez le nom ou l'IP de la machine distante et cliquez sur Key....

NX utilisant le système SSH sans mot de passe pour se connecter. Il va donc nous falloir récupérer la clef publique du serveur qui se trouve sur la machine distante dans le fichier /var/lib/nxserver/nxhome/.ssh/client.id_dsa.key. Faites un simple copier/coller dans la boite de dialogue et validez.

Dans le cadre Desktop, sélectionnez le bureau de votre machine distante (Gnome, Kde, etc.) et le type de ligne utilisé (MODEM, ADSL, LAN, etc.). Ensuite allez dans l'onglet Advanced et vérifiez que l'option Disable SSL encryption of all traffic est bien décoché. Cliquez sur OK, puis sur login. Et le bureau distant devrait apparaître.

Maintenant cette approche "bureau" est certes sympathique mais peu adaptée pour ne lancer qu'une seule commande graphique distante. Fort heureusement il est possible de changer cela et de configurer une session dans ce sens.

Pour cela relancez le client, repassez dans la configuration de la session, et dans le groupe Desktop, sélectionnez cette fois Custom et clickez sur Settings.

Dans le groupe Application, sélectionnez Run the following command, et tapez par exemple /usr/bin/evolution. Vous aurez remarqué qu'en faisant cela, vous êtes passé de New Virtual Desktop à Floating Window. Pressez OK puis Save et connectez-vous. Là devrait apparaître une seule fenêtre pour un évolution exécuté sur la machine distante.

Vous pouvez spécifier ce qui vous chante comme commande distante, comme par exemple un /usr/bin/xterm vous permettant de lancer d'autres commandes distantes par la suite.

L'approche NX est ultra adaptée à un usage à travers internet que ce soit pour afficher un bureau complet ou une commande unique. Cependant dans le second cas l'intégration au bureau n'est pas aussi parfaite qu'avec les deux précédentes méthodes avec par exemple une boîte à miniatures inaccessibles aux applications distantes. En revanche NX permet l'export de l'audio et de l'impression ce qui n'est pas le cas des autres approches.

En cas de problème

Il y a un paquet de choses qui peuvent bloquer la connexion à NX, en voici quelques-unes :

Activation des logs

Il y a bien un fichier de logs créé sur le serveur en /Var/log/nxserver.log mais il n'est pas très bavard par défaut... Pour activer les logs, il faut ouvrir le fichier /etc/nxserver/node.conf puis décommenter/modifier la ligne NX_LOG_LEVEL<.kbd> en changeant le 0 par un 6 ou un 7. Sauver puis redémarrez le serveur par un nxserver --restart. Les logs devrait d'un coup être beaucoup plus loquaces.

Il y a des sessions suspendues...

Si la connexion ne passe pas, vérifiez qu'il n'y a pas de session existante bloquée dans le tuyau. Pour cela, il faut utiliser sur la machine distante la commande nxserver --list. Si des sessions apparaissent, lancez un nettoyage par nxserver --cleanup. Retentez la connexion.

Version du client incompatible

Cela coince avec les versions .4 de freeNX si l'on utilise une version du client supérieure à la 1.5. On peut trouver facilement cette ancienne version via google (me la demander le cas échéant).

Mauvaise configuration de sshd

Si l'on obtient l'erreur Failed publickey for nx from ... dans les logs serveurs de ssh, il est possible qu'il vous faille commenter dans le fichier /etc/sshd/sshd_config une ligne du style AuthorizedKeysFile home/lobs/.ssh/authorized_keys2. Relancez ensuite le serveur et recommencez la connexion.

Erreur de cookie

Si vous obtenez l'erreur

Error: Failure negotiating the session in stage '7'.

Error: Wrong version or invalid session authentication cookie.

root# 

erreur de cookie

Dans mon cas, il s'agissait seulement d'un serveur X non opérationnel sur la machine distante. Ceci a été réglé par un simple urpmi xinit.

Si les fontes sont moches

Si les fontes sont trop petites, vous devez rajouter sur le compte local un fichier ~/.Xresources et y mettre la ligne

Xft.dpi: 96

Si les fontes sont moches ET les icônes aussi

Là vous êtes sûrement sous Gnome. Auquel cas il faut que vous lanciez, dans la session NX, la commande /usr/lib/gnome-settings-daemon avant de lancer d'autres applications. Tous les thèmes devraient alors être correctement utilisés.

Si la connexion cale en disant que le serveur ne peut se connecter au localhost:22

Peut-être avez-vous suivi mes conseils et placé SSHD sur un port différent du 22. Auquel cas sur le serveur il vous faut éditer /etc/nxserver/node.conf, décommenter la ligne #Port 22 et replacer 22 par le port que votre SSHD écoute.

Un écran secondaire Distant

Un autre utilisation de ces techniques consiste à exploiter l'écran d'une machine secondaire pour y déporter un certain nombre d'applications courante (courrier, messagerie instantanée, flux RSS, etc.) de sorte à "dégager" l'écran de la machine de bureau tout en ne chargeant pas le CPU de la machine secondaire. Les deux machines n'auront alors plus qu'à être reliées par synergy pour former un seul et même bureau.

Pour cet usage, la première technique "native" est clairement la plus efficace mais celle par SSH marche aussi très bien. Dans les deux cas cela consiste à ouvrir une connexion SSH de la machine secondaire vers la machine principale. Ensuite soit nous utilisons le report du serveur X11 par SSH et il n'y a rien a faire

machine_secondairessh -X machine_principale

gaston@machine_principale>evolution&

gaston@machine_principale> 

Ecran secondaire en mode SSH

soit nous ouvrons notre serveur X11 secondaire au sockets TCP/IP et il faut commencer par régler la bonne variable DISPLAY

machine_secondairexhost+

machine_secondairessh machine_principale

gaston@machine_principale>export DISPLAY=machine_secondaire:0.0

gaston@machine_principale>evolution&

gaston@machine_principale> 

Ecran secondaire en mode SSH

Tout ceci marche à merveille à quelques détails près que nous allons examiner maintenant.

Ouverture de liens

Sur notre écran distant, lorsque l'on clique sur un lien dans liferea, cela n'ouvre pas l'URL sur le firefox du desktop mais sur celui un firefox distant... En effet, FireFox utilise l'identifiant de l'écran (variable DISPLAY) pour savoir où ajouter son onglet.

La "Solution" est donc de se dire que si FireFox est toujours sur mon écran principal, autrement dit DISPLAY=:0, il suffit de faire un petit script qui va systématique ouvrir les URL sur cet écran en exportant la valeur de DISPLAY avant d'appeler FireFox :

#! /bin/sh

export DISPLAY=:0
/usr/bin/firefox $1

/usr/bin/open-url.sh

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 Autoriser 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'agrégateur de nouvelles

Pour ajouter un flux à liferea par l'intermédiaire de FireFox, il suffit normalement d'utiliser le script /usr/bin/liferea-add-feed. Tout se passe dans les préférences de FireFox, onglet Applications. Une fois là dedans, allez à la ligne Flux WEB, sélectionner Autres... et choisissez le script.

Maintenant cela marchera très bien si liferea est lancé directement sur le desktop, un peu moins s'il est affiché par l'écran secondaire. En effet, liferea utilise une session DBUS, désignée par variable DBUS_SESSION_BUS_ADDRESS, pour communiquer avec le script d'ajout. Le « problème » lorsque nous nous connectons via SSH est que 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.

Pour régler cela, nous allons commencer par créer sur la machine principale un fichier /etc/X11/xinit.d/35export_dbus en y mettant le contenu suivant :

# to be sourced

echo DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS > ~/.ssh/environment

/etc/X11/xinit.d/35export_dbus

L'astuce ici est donc de créer, au lancement de la session sur la machine principale, un fichier ~/.ssh/environment qui est utilisé par ssh pour "nourrir" l'environnement d'une nouvelle session. 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.

Ceci fait, toute session SSH ouverte sur la machine principale 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 :

gaston$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?

gaston$ 

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

#%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 devraient prendre vie et vous devez pouvoir y aller avec votre souris.

Conclusion

Voilà, fin du petit tour de l'exécution de commande graphiques à distante, en espérant avoir à travers ces deux usages montré la puissance d'un serveur graphique doté d'une transparence réseau.