Comme vous ne l'ignorez peut-être pas, X11 est une technologie client/serveur. C'est à dire que lorsque une application est lancée, elle n'écrit jamais directement sur l'écran mais se connecte via le réseau, à un serveur, le fameux Xorg. Ainsi, à chaque vois qu'elle 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 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 impactes sur la vitesse sont limités à plusieurs étages comme par l'utilisation de sockets rapides dits UNIX au lieu des classiques TCP/IP ou encore un accès direct à la carte graphique 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 serveur X.
X était conçu l'origine pour tourner sur des LAN à 10mb/s avec un serveur puissant et des terminaux graphiques. Mais rapidement, le développement des modems RTC a amené des groupes de travail à plancher sur des versions plus efficaces de X, moins consommatrices en bande passante, pour arriver à le faire passer par ces petits tuyaux à 14400 bauds . Nous pouvons citer pour mémoire le module LBX.
Aujourd'hui, avec nos lignes haut débit, il est possible de disposer à distance d'une fluidité d'affichage très proche de ce que l'on obtient en local. Non plus grâce à LBX, paix à son âme, mais par une savante mixture de SSH et d'optimisation du protocole X : les clients/serveurs NX.
Comme nous l'avons vu, il est depuis longtemps possible de lancer une application distante en utilisant un serveur graphique local. A nature même de X est faite pour cela. SSH permet lui aussi de faire ce genre de chose sans avoir à ouvrir le moindre port, grâce à son système de redirection. Du coup, si vous faites un ssh sur une machine distante qui dispose de X, il suffit de lancer une application graphique pour qu'elle s'affiche en locale. C'est le CPU distant qui travail mais votre machine locale qui affiche avec SSJ qui faire la colle sécurisée entre les deux.
L'idée de NoMachine exploite ce concept en le combinant avec l'idée de compression, d'optimisation, et de mise en cache de LBX. Le résultat est un la possibilité d'accéder à son bureau de n'importe où, avec une qualité et une rapidité étonnante.
Le système NoMachine ne demande aucune modification des applications et utilise pleinement la norme X11. Il se compose d'un serveur et d'un client. Ce dernier existe pour Linux, Windows, MacOS et Solaris.
Côté serveur, à l'origine, la version était seulement commerciale et les sources pas tous 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.
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 gastoon est autorisé à s'y connecter :
Ceci fait, c'est terminé pour la machine distante. Il faut maintenant installer le client NX pour la machine locale. Il se trouve sur la partie download du site de NX. Une fois téléchargé, lancez la commande urpmi en mettant en paramètre le chemin et le nom du fichier téléchargé.
Ne reste alors plus qu'à tester. Lancez la commande nxclient. Cela devrait faire apparaître une fenêtre de connexion. Saisissez toto 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 copier la clef publique du serveur. Cette clef 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.
Allez maintenant dans l'onglet Advanced et vérifiez que l'option Disable SSL encryption of all traffic est bien décoché. Ensuite cliquez sur OK.
Maintenant, il ne reste plus qu'à se connecter en cliquant sur login.
Par défaut, le client NX chercher à lancer en plein écran une session KDE complète. Il est possible de customiser ce comportement dans l'onglet General en sélectionnant votre environnement (Gnome par exemple) dans la section desktop. Pour lancer l'environnement par défaut, sélectionnez Custom. Cela lancera ce qui aurait été utilisé par un startx sur la machine distante.
Enfin, pour lancer une seule application, sans mettre en branle une session complète, retournez dans le paramétrage de la session. Réglez à Custom, puis cliquez sur Settings.... Là, par exemple pour ne lancer que la commande xterm, sélectionnez Run the following command et saisissez /usr/bin/xterm. Et comble du raffinement, pour que cette application ne se lancera pas un bureau virtuel mais uniquement sa fenêtre standard. Totalement intégré donc.
Il y a un paquet de choses qui peuvent bloquer la connexion à NX. Voici celles que j'ai pu rencontrer.
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.
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.
Cela coince avec les versions .4 de freeNX si l'on utilise une version du client supérieur à la 1.5. On peut trouver facilement cette ancienne version via google (me la demander le cas échéant).
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.
Si l'on n'est pas en LAN et donc que l'on passe par un tunnel SSH, il faut absolument, dans la configuration du client, activer l'option de l'onglet Avanced, Enable SSH encryption of all Traffic.
Si vous obtenez l'erreur
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 :
mv authorized_keys2 authorized_keys
Si les fontes sont trop petites, vous devez rajouter sur le compte local un fichier ~/.Xresources et y mettre la ligne
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.
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.
NX/FreeNX sont des outils fantastiques permettant de transformer un vieille bécane poussive en un performant serveur X. Personnellement c'est le mode d'affichage qui me permet d'exploiter mon troisième écran utilisé en conjonction avec synergy.
]]>