(application sur la suse 10.1 et 10.2 KDE)

Accéder à distance (réseau local ou internet) à une machine linux, à partir d'une machine cliente windows ou linux, par un accès graphique (bureau), sécurisé SSH, en utilisant FreeNX.

Le serveur FreeNX est la version libre du serveur “nxserver” de nomachine (http://www.nomachine.com ). Elle fait partie du package Suse v10.1 et v10.2.

Comme pour vnc lancé par xinetd, cette liaison permet d'accéder à un compte existant sur la machine linux, et de la piloter en mode graphique (kde ou gnome) comme si on était devant.

Comme linux est multi-utilisateurs (contrairement à windows), plusieurs personnes peuvent accéder à la même machine linux et y travailler en même temps. De même, un seul utilisateur peut ouvrir plusieurs sessions de son compte en même temps.

Bien entendu, comme pour vnc, les jeux et applications qui demandent l'accélération 3D de la carte graphique nécessitent qu'on soit devant la machine serveur!

FreeNX est vraiment très rapide (plus rapide que vnc) et malgré tout sécurisé par ssh. Il contient plusieurs niveaux de compression qui permettent de s'adapter au mieux à des débits de lignes très différentes, y compris en passant par internet. Le son peut être transmis par “esound”. Le copier/coller fonctionne dans le sens serveur → client.

Comme mon pc linux est à la cave, j'utilise freenx le plus souvent possible!

• Manuel de référence de la suse: voir liens utiles

• Site de “nomachine”: http://www.nomachine.com

• Site de freenx: http://freenx.berlios.de/

Sur la suse, il suffit d'installer le package rpm “freenx”.

En principe, les relations de dépendance entrainent l'installation d'openssh qui est nécessaire à son exécution.

La doc de freenx se trouve ici: /usr/share/doc/packages/FreeNX.

Il faut ensuite initialiser le service par (en console sous root):

# nxsetup --install --clean --purge --setup-nomachine-key  

Sur la 10.2, il y a des warning qui indiquent que smbmount ni smbumount ne sont pas trouvé: c'est normal, ils n'y sont plus (c'est cifs maintenant). Vous ne pourrez pas utiliser les partages samba en passant par freenx, mais ils marcheront toujours normalement. Peut-être peut-on configurer freenx pour qu'il tienne compte de mount-cifs en remplacement? Je n'ai pas encore essayé.

Après cela, nxserver apparait dans les processus actifs dans:

• menu → système → moniteurs → surveillance système de kde → table des processus

Le fichier de configuration du serveur nx est “/etc/nxserver/node.conf”, mais je n'ai pas eu à le modifier (sauf pour activer le fichier .log).

Au démarrage de la machine linux qui portera le nxserver, vous n'avez pas besoin d'aller plus loin que la page de login si vous n'avez pas besoin de travailler physiquement devant son écran.

Si vous voulez tracer la communication, il faut activer le fichier log dans le fichier de configuration /etc/nxserver/node.conf:

• il faut définir votre niveau de traçage en décommentant NX_LOG_LEVEL et en lui affectant une valeur de 1 à 7 (valeur par défaut=0, c'est à dire pas de traçage). Essayer la valeur 4 pour avoir la trace du protocole de communication client-serveur.

• le traçage voulu sera désormais enregistré dans /var/log/nxserver.log. Il n'est pas nécessaire de relancer freenx.

Si pour accéder au serveur nx, il faut traverser un parefeu, il ouvrir certains ports.

Dans tous les cas, il faut ouvrir le port 22 TCP, nécessaire à SSH, actif en début de session pour les mécanismes d'autorisation.

Pour le reste, tout dépend de la configuration du client nx:

• si la case “ Enable SSL encryption of all traffic” est cochée, alors tout le flux est crypté par SSL, et tout passe par le port 22 TCP!

• si cette cas n'est pas cochée, il faut ouvrir d'autres ports, et là, c'est un peu plus compliqué. Le manuel de la suse 10.1 dit qu'il faut ouvrir les ports 5000 à 5009 et 7000 à 7009, mais ça ne marche pas, et ça n'est pas conforme à la notice de freenx. Par contre, l'ouverture de 5000 à 5199 TCP et 7000 à 7199 TCP fonctionne. Il faut se reporter, pour ça, ainsi que pour des réglages plus complexes, à la note /usr/share/doc/packages/FreeNX/NX-Firewall.txt. Les ports à ouvrir se calculent facilement à partir des données du fichier de configuration /etc/nxserver/node.conf. Attention, certains services nécessitent l'ouverture de ports supplémentaires, comme les partages samba (8000 à 8199), si vous voulez que ces partages passent par freenx.

Mais en fait, le problème est simple:

• si vous voulez accéder par internet, utilisez l'encryptage SSL, et vous n'avez que le port 22 TCP à ouvrir!

• Au sein de votre réseau local, vous n'avez en général pas besoin de parefeu entre vos machines

Il faut télécharger le “client nx” windows. Attention: le client doit avoir la même version que le NX (=le proxy) du serveur. Comme sur la suse 10.1, NX est livré en version 1.5, le client windows disponible sur le site de nomachine (http://www.nomachine.com/download_client_windows.php) qui est passé à 2.0 n'est plus le bon. Il faut chercher la version 1.5 ici: http://ftp.dedibox.fr/pub/dedibox/utils/. Si le site n'était plus accessible, chercher “nxclient-1.5.0-138.exe” avec google.

Sur la page correspondant au lien de nomachine, demandez les instructions d'installation: c'est très bien fait.

Et installez comme précisé.

KDE arrive avec Knx qui est un client nx. Et ça marche, mais c'est un produit un peu rudimentaire, et il vaut mieux utiliser le même produit que pour windows: le client nx de nomachine. Avec yast, désinstallez Knx. On télécharge la version 1.5 au même endroit que pour windows: http://ftp.dedibox.fr/pub/dedibox/utils/ . Pour la suse, il s'agit du rpm: nxclient-1.5.0-113.i386.rpm.

Pour installer, utilisez yast. Si vous avez une version de suse dont le yast refuse d'installer un paquet isolé, il faut faire l'installation en console. Placez le rpm quelque part (dans /ressources/rpmsup/nxclient ou /usr/local/nxclient par exemple). Ouvrez une console sous root et placez vous dans ce répertoire. Faites alors:

# rpm -ivh nxclient-1.5.0-113.i386.rpm  

En double-cliquant sur l'icône NX (qui devrait être sur votre bureau), il apparait une petite fenêtre

La “session”, c'est le nom de la session que vous voulez definir: donnez, par exemple, le nom du compte linux (“tyrtamos” pour moi).

Entrez les login et password du compte linux en question

Cliquez sur le bouton “configure” → create → il apparait une fenêtre de configuration avec plusieurs onglets:

Onglet “General”:

• Host = l'adresse ip de votre machine nxserveur. Si vous êtes au sein de votre réseau local, c'est l'adresse locale (p ex 192.168.0.200). Utilisez l'adresse ip pour gagner le temps de résolution de nom, ce qui suppose, bien sûr, une adresse ip fixe!

• port = laisser le port 22 qui est le port SSH

• desktop = Unix et KDE (vous voyez que vous pourriez avoir gnome)

• vous choisissez la liaison (“LAN” pour un réseau local rapide ethernet) qui détermine le niveau de compression des données

• display = pour ma part, je choisis “fullscreen”

• je laisse “use default image encoding”

Onglet “Advanced”

• Network = je laisse comme c'est

• Cache: comme j'ai de la mémoire, je met tout au maxi

• Keyboard: je met un clavier français

Onglet “Services”

• Je ne mets pas “enable printer and file sharing” parce que j'ai déjà ça sur samba

• Je clique sur “enable multimedia support” pour avoir le son

Onglet “Environnement”

• Je laisse comme c'est

Vous faites “save” et vous cliquez sur “login” pour lancer la connection

A la 1ère connexion, le client nx donne un message d'alerte: il dit qu'il n'est pas absolument sûr que la machine à laquelle il accède est bien celle que vous voulez, et il vous affiche le “fingerprint” (une clé de 16 octets) de la machine en question pour vous permettre de le vérifier:

The authenticity of host 'xxx.xxx.xxx.xxx' (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is xx.xx.xx. .... xx.xx.
Are you sure you want to continue connecting (yes/no)?  

Si vous répondez “yes”, le programme répond:

Warning: Permanently added 'xxx.xxx.xxx.xxx' (RSA) to the list of known hosts 

et demande le mot de passe du login.

A partir de ce moment, la machine cliente nx (windows ou linux) conservera dans le fichier “known_hosts” les données concernant la machine serveur nx et saura la reconnaître la prochaine fois sans vous reposer la question. Sur une machine cliente nx “windows”, ce fichier est: C:\Documents and Settings\votrelogin\.ssh\known_hosts. Sur une machine cliente nx “linux”, ce fichier est: /home/jeanpaul/.ssh/known_hosts. Dans ce fichier se trouve la liste des machines serveur nx reconnues, avec une longue ligne par machine telle que:

192.168.0.200 ssh-rsa AAAAB3NzaC1yc2EAAA......ABIwAA=  

Vous pouvez d'ailleurs effacer la ligne, et, à la prochaine session, le client nx vous redemandera si la machine qu'il a trouvée est bien celle que vous voulez.

C'est normal: pour lutter contre les tentatives d'usurpation d'adresse, il faudrait procéder avant à un tranport de clés du serveur nx au client nx pour que cette reconnaissance soit certaine. Si vous êtes méfiant, vous pouvez vous donner le moyen de vérifier si c'est la bonne machine grâce à son “fingerprint” que vous devez connaître avant la 1ère connexion. Sur le serveur nx, placez-vous en console sous root dans le répertoire /etc/ssh qui contient les clés.

Lancez (le paramètre est un “L” minuscule):

# ssh-keygen -l  

le programme demande de quelle clé vous voulez le fingerprint. Répondez:

# ssh_host_rsa_key.pub  

Le programme vous donne alors le fingerprint de la clé en question. Quelque chose comme:

# 1024 d7:57:d2:5a:94:2c:49:6b:45:d0:1c:0d:fd:ac:08:95  

Prenez note de ce fingerprint, et vérifiez lors de la 1ère connexion que c'est bien cette valeur qui est présentée à votre approbation.

NB: selon la config de SSH, il est possible que ce soit le fingerprint de la clé dsa (ssh_host_dsa_key.pub) et non celle de rsa qui soit demandée.

Pour lancer la liaison NX, vous lancez l'icône “NX client” située sur le bureau (windows ou linux).

Vous choisissez le nom de session que vous voulez établir, et vous cliquez sur le bouton “login”.

Le protocole de connexion se déroule, et le bureau du compte demandé se retrouve sur l'écran de votre pc client nx.

Pour avoir la pleine accélération, je vous conseille de ne pas avoir de papier peint. Pour ma part, j'ai mis un écran bleu uni RGB (0,0,128).

Quand vous êtes en plein écran, comment revenir à votre écran normal de la machine client?

• Avec une machine cliente windows, vous faites simplement [alt]-[esc], ou [alt][F4].

• Avec une machine cliente windows ou linux, vous cliquez sur le dernier pixel en haut et à droite de l'écran

Pour revenir à l'écran de la machine serveur, il suffit de réactiver la fenêtre “NX” à partir de la barre des tâches.

Alors que vous êtes sur votre machine cliente (windows ou linux) et que vous avez l'écran de votre machine serveur linux, vous demandez simplement le log-out au menu afin d'arrêter proprement la session en cours.

Je vous déconseille de supprimer seulement la fenêtre linux, parce que des morceaux de programme linux peuvent continuer à s'exécuter, qui pourraient géner lors d'une future re-connexion. Par exemple, firefox peut alors vous demander à la connection suivante de créer une autre session firefox, parce que la session habituelle est occupée. Le problème est que vous n'avez plus alors vos bookmarks. La seule solution est de supprimer firefox dans les processus en fonctionnement sous votre compte, et ça marche de nouveau.

Mais la vrai solution est: sortez proprement par log-out en ayant arrêté avant toutes les applications!

Le manuel de référence de la suse 10.1 mentionne la possibilité de demander la mise en veille de la session au lieu de son arrêt. A la connexion suivante, le bureau réapparait dans le même état.

Tout au moins, c'est ce qui est prévu. J'ai rencontré quelques dysfonctionnements qui m'ont dissuadé de continuer. Il est possible que ce soit lié à mon kernel “smp”, car il est connu que les processus de mise en veille sont en difficulté avec ce kernel.

Mais rien ne vous empêche d'essayer: reportez-vous au manuel de référence suse 10.1, chapitre 15: c'est très bien expliqué.

Pour avoir les fonctions “multimedia” (son et image), il faut cocher la case “multimedia” dans la configuration du client nx.

Pour avoir le son, il faut avoir installé le rpm “esound” et, dans chaque logiciel, rediriger le module de sortie du son sur “esound” (ou “esd”) et non sur “alsa”.

Curieusement, la notice de nomachine dit qu'on doit utiliser “esound” quand le nx client est windows, et “aRts” quand le nx client est linux. Ce n'est pas ce que je constate: même avec nx client linux, c'est esound qui marche et non aRts.

Par exemple sur xmms: préférences → plugin de sortie → esound et vous pouvez écouter la musique sur votre machine cliente nx (windows ou linux), en ayant les fichiers musicaux et le logiciel de lecture sur la machine serveur nx linux… Idem avec Amarok, à condition d'avoir le moteur xine et de le configurer avec esound.

Vous pouvez faire cela aussi avec la lecture vidéo.

Par exemple avec xine: page setup → onglet audio → pilote audio à utiliser = “esd”. Vous voyez ainsi, par exemple, un film (image et son) sur votre machine cliente nx (windows ou linux) avec les fichiers video et le lecteur video sur la machine serveur nx linux. Mais ça demande une liaison ethernet performante, sinon, c'est un peu saccadé! Chez moi, le son est bon, mais la vidéo manque de fluidité (ou alors, il faut réduire la taille de la fenêtre).

Si tout cela c'est possible, ce n'est pas forcément une bonne idée, parce que le flux prend une bonne partie de la bande passante du réseau, et cela rend les autres opérations beaucoup moins fluides.

En tout cas, je n'ai pas réussi à avoir les notifications musicales de KDE. Par contre, j'ai la “cloche”: mystère de l'informatique…

Vous pourrez vérifier que le copier-coller fonctionne dans le sens “serveur nx” → “client nx”. Par contre, je n'ai pas réussi à le faire fonctionner dans l'autre sens.

Imaginez que vous ayez installé en même temps kde et gnome. C'est facile: quand vous avez kde (bureau par défaut), vous installez gnome avec yast (sélection de packages → gnome).

A partir de là, normalement, c'est à la page de login de connexion que vous pouvez choisir (en bas à gauche). Attention: il faut empêcher avant le login automatique.

Conséquences sur freenx:

• Que vous ayez franchi ou non cette page de login sur la machine serveur nx, vous pouvez choisir entre kde et gnome lors de la configuration de votre client nx!

• Encore mieux, vous pouvez ouvrir une session nx-kde et une session nx-gnome en même temps sur votre machine cliente nx.

• Et rien ne vous empêche, après avoir ouvert une session nx-kde, de réouvrir à l'intérieur de cette session, une 2ème session nx-gnome… ou le contraire.

Fantastique, non?

Sincèrement, je me demande comment linux est capable de faire cela sans se mélanger les pinceaux…

En modernisant mon matériel windows, je viens de découvrir que freenx et nxclient-windows peuvent rencontrer des difficultés.

On cite sur le web 2 problèmes connus:

• difficultés de nxclient-windows avec cygnus si celui-ci tourne déjà sur la machine cliente windows.
  • Le site de nomachine décrit la solution à adopter. En gros, il s'agit pour nxclient d'utiliser les dll cygnus déjà installées.

• difficultés de nxclient-windows avec les pilotes de webcam logitec.
  • Pas de solution citée, à part de désinstaller la webcam. Au coup par coup, on peut se contenter d'arrêter le processus “LVPrcSrv.exe” comme mentionné ici: http://www.nomachine.com/tr/view_notes.php?commid=107&id=TR06D01417

Si ça ne marche vraiment pas, revenez à VNC (avec ou sans SSH). Celui-ci est peut-être un peu moins rapide, mais il est plus tolérant avec les config.

Si vous n'avez qu'un clavier qwerty dans la connexion nx alors que vous avez le clavier azerty sur votre pc client ainsi que sur votre pc serveur, il y a une astuce qui marche chez moi:

• Ajouter à la fin du fichier /etc/nxserver/node.conf la ligne:

AGENT_EXTRA_OPTIONS_X="-xkbdir /usr/share/X11/xkb" 

• Je crois qu'il y a aussi une seconde condition: KDE ne doit pas gérer son propre clavier. Donc, dans la “configuration personnelle” de KDE, aller à la “Régionalisation & accessibilité” puis à “Disposition du clavier” et désactivez le clavier KDE (=décochez toutes les cases du haut pour les 3 onglets) ou vérifiez que c'est fait.