rapport sur le projet tuteur´e “les clients l´egers”

LP ASRALL 2008-2009
IUT Charlemagne Nancy 2
RAPPORT SUR LE
PROJET TUTEURÉ
“LES CLIENTS LÉGERS”
Alexandre
Cédric
Joël
1er avril 2009
Benjamin
Table des matières
1 Introduction
1.1 Présentation de systèmes de clients légers .
1.2 Répartition des tâches. . . . . . . . . . . . .
1.2.1 Alexandre BAILLY . . . . . . . . . .
1.2.2 Cédric MATHIEU . . . . . . . . . .
1.2.3 Joël NOGRÉ . . . . . . . . . . . . .
1.2.4 Benjamin SECLIER . . . . . . . . .
1.3 Divers . . . . . . . . . . . . . . . . . . . . .
1.3.1 Réunions - moyen de communication
1.3.2 Problèmes rencontrés . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
5
5
5
5
5
5
5
2 Le matériel
2.1 Le serveur . . . . . . . . . . . . .
2.2 Les clients légers . . . . . . . . .
2.3 Des PC en tant que clients légers
2.4 Notre système de clients légers .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
7
10
10
3 XDMCP
3.1 Présentation . . . . . . . . .
3.2 Connexion . . . . . . . . . .
3.3 Mise en place. . . . . . . . .
3.3.1 Activation manuelle
3.3.2 Activation graphique
3.4 Avantages / Inconvénients.
3.4.1 Avantages . . . . . .
3.4.2 Inconvénients . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
13
13
13
14
14
14
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
avec GDM
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
15
16
16
17
17
18
18
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 VNC
4.1 Introduction . . . . . . . . . . . .
4.2 Installation . . . . . . . . . . . .
4.2.1 Installation du serveur . .
4.2.2 Installation du client . . .
4.3 Encapsulation SSH . . . . . . . .
4.4 Se connecter sur un serveur VNC
4.5 Problèmes rencontrés . . . . . . .
4.6 Avis . . . . . . . . . . . . . . . .
4.6.1 Avantages . . . . . . . . .
4.6.2 Inconvénients . . . . . . .
1
5 LTSP
5.1 Présentation . . . . . . . . . . . . . . . . . . . . .
5.1.1 Présentation du projet . . . . . . . . . . .
5.1.2 Différences LTSP 4/LTSP 5 . . . . . . . .
5.1.3 Principales fonctionnalités de LTSP 5. . .
5.1.4 Configuration matérielle recommandée. .
5.2 Principe de fonctionnement . . . . . . . . . . . .
5.2.1 Démarrage du client . . . . . . . . . . . .
5.2.2 Services requis et utiles . . . . . . . . . .
5.3 Installation et configuration. . . . . . . . . . . . .
5.3.1 Installation. . . . . . . . . . . . . . . . . .
5.3.2 Configuration du serveur. . . . . . . . . .
5.3.3 Configuration des clients. . . . . . . . . .
5.3.4 Configuration de LTSP . . . . . . . . . .
5.3.5 Administration des clients. . . . . . . . .
5.4 Tests. . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Consommation réseau pour un client léger
5.4.2 Charge du serveur : . . . . . . . . . . . .
5.4.3 Efficacité des clients : . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
19
20
20
21
21
22
22
22
23
24
25
27
27
27
27
27
6 Free NX
6.1 Présentation . . . . . . . . . . . .
6.2 Installation . . . . . . . . . . . .
6.2.1 Sur le serveur . . . . . . .
6.2.2 Installation du serveur . .
6.2.3 Configuration du serveur
6.2.4 Sur le client . . . . . . . .
6.2.5 Configuration du client .
6.2.6 Sécurité . . . . . . . . . .
6.3 Performances, montée en charge .
6.4 Émulation application Windows .
6.5 Gestion des périphériques . . . .
6.6 Impression . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
30
31
31
31
32
32
36
36
36
37
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Conclusion
38
8 Remerciements
40
9 Glossaire
41
10 Sources
42
2
Table des figures
2.1
2.2
2.3
Vue interne d’un client léger . . . . . . . . . . . . . . . . . . . . .
Vue avant et arrière du client léger . . . . . . . . . . . . . . . . .
Configuration du réseau . . . . . . . . . . . . . . . . . . . . . . .
7
8
10
3.1
3.2
Schéma simplifié du fonctionnement de XDMCP . . . . . . . . .
Capture d’écran de réglage de XDMCP avec GDM . . . . . . . .
12
13
4.1
Connexion VNC sécurisé par SSH . . . . . . . . . . . . . . . . . .
16
5.1
Schéma du démarrage du client. . . . . . . . . . . . . . . . . . . .
21
6.1
6.2
6.3
Schéma Export d’affichage via le réseau. . . . . . . . . . . .
Pare-feu Windows bloquant NX client. . . . . . . . . . . . .
Pare-feu Windows avec les services NX ajoutés dans la liste
services autorisés. . . . . . . . . . . . . . . . . . . . . . . . .
Configuration - introduction. . . . . . . . . . . . . . . . . .
Configuration - introduction. . . . . . . . . . . . . . . . . .
Configuration - introduction. . . . . . . . . . . . . . . . . .
Configuration - introduction. . . . . . . . . . . . . . . . . .
Boı̂te de dialogue de connexion . . . . . . . . . . . . . . . .
Le bureau gnome affiché dans un client NX. . . . . . . . . .
30
33
6.4
6.5
6.6
6.7
6.8
6.9
3
. . .
. . .
des
. . .
. . .
. . .
. . .
. . .
. . .
. . .
33
34
34
35
35
36
37
Chapitre 1
Introduction
1.1
Présentation de systèmes de clients légers
Tout d’abord, qu’est-ce qu’un système de clients légers ?
C’est un système informatique composé d’une puissante machine (le serveur)
et de plusieurs machines très légères (sans disque et avec un minimum de
matériel) capablent de se connecter, via un réseau informatique, sur le serveur
et d’exécuter sur ce dernier des applications.
Avantages d’un système de clients légers :
– Les clients légers ne comportent qu’un minimum de matériel et n’ont pas
d’applicatifs (ou très peu) tournant sur eux d’où un faible coùt de maintenance et pas de licence à rémunérer.
– Toutes les applications se trouvent sur le serveur donc, une seule licence
par programme à payer. Encore une fois, des économies.
– Toutes les bases de données se trouvent sur le serveur, d’où une grande
facilité pour les sauvegardes.
– Les mises à jour ne se font que sur le serveur. Là encore, une économie de
temps.
Inconvénients d’un système de clients légers :
– Le serveur doit être une machine puissante, voire très puissante en fonction
du nombre de clients légers susceptibles de se connecter sur lui, d’où un
prix non négligeable.
– Le réseau doit être en haut débit pour supporter un grand nombre de
connections simultanées. Là aussi, les finances s’en ressentent !
– En cas de panne du serveur ou du réseau, c’est tout un organisme qui
est arrêté. Ceci peut être évité en mettant en place un système de haute
disponibilité mais, là encore, celà a un coùt.
Pour vous démontrer cela, nous allons mettre en place quatre solutions :
1. Free NX
2. XDMCP
3. LTSP
4. VNC
4
1.2
1.2.1
Répartition des tâches.
Alexandre BAILLY
Alexandre s’est chargé de la partie Free NX. Il a principalement travaillé
chez lui. Il a passé une vingtaine d’heures sur sa partie du projet.
1.2.2
Cédric MATHIEU
Cédric a pris en charge les parties XDMCP et LTSP. Il a passé près de 30
heures en recherches, paramétrages et surtout en tests divers.
1.2.3
Joël NOGRÉ
Joël, quand à lui, s’est occupé des recherches générales, de la partie “Client
Léger” du matériel, de la mise en forme et des corrections “ortografic” et grammaticales du rapport final. Il a passé une vingtaine d’heures à faire ses recherches, embêter certains profs et étudiants pour commencer à se débrouiller
avec LaTex, tanner ses camarades pour avoir leur documentation afin de terminer ce rapport en temps et en heure.
1.2.4
Benjamin SECLIER
Passionné par tout ce qui est connexion à distance, “Benji” s’est occupé de
la partie VNC. Il a monté une toute première expérience avec ses ordinateurs
personnels avant de la transposer sur la configuration locale choisie. Il a passé
une vingtaine d’heures en recherches diverses, montages de l’expérience et tests.
1.3
1.3.1
Divers
Réunions - moyen de communication
Nous avons tenu trois réunions d’avancement dont la première avec notre
tuteur.
Hors ces réunions, nous nous recontrions deux fois par semaine, à l’occasion des
travaux collaboratifs. Notre moyen de communication a été le wiki qu’a créé
Benjamin à l’adresse : http ://www.generation-linux.fr/asrall
1.3.2
Problèmes rencontrés
La machine que nous avions choisie en tant que serveur est tombée en panne
une première fois et a du être changée. Ensuite, la carte réseau additionelle a
eu un problème au niveau du connecteur et a du, elle aussi, être changée.
Notre “serveur” manquant de mémoire RAM, nous avons demandé à le passer
à 1 Go.
Nous ne pouvons que déplorer le manque cruel de prises électriques pour brancher tous nos équipements et l’interdiction formelle qui nous a été faite d’utiliser
des rallonges et multiprises.
5
Chapitre 2
Le matériel
2.1
Le serveur
C’est une machine Dell.
– L’ordinateur
– Processeur Intel(R) Pentium(R) 4 CPU 2.80GHz
– Memoire 1 Gbytes
– Système d’exploitation Debian GNU/Linux 5.0
– Multimedia
– Audio ICH4 - Intel ICH5
– Périphériques d’entrées
– Clavier PS2
– Souris PS2
– Disques IDE
– Disque WDC WD400BB-75FJA1
– CD/DVD HL-DT-ST RW/DVD GCC-4481B
– Interfaces réseaux
– lo (127.0.0.1)
– eth0 (192.168.1.1)
– eth1 (192.168.10.191)
– Partitionnement
– /dev/hda1 / ext3 defaults,errors=remount-ro (14 Go)
– /dev/hda3 /home ext3 defaults (22 Go)
– /dev/hda2 swap swap sw (2 Go)
– /dev/hdc /media/cdrom0 udf,iso9660 user,noauto
– Comme gestionnaire Xdm, nous avons choisi gdm.
Les clients légers prêtés, offrant une possibilité de connection via telnet, nous
avons installé le serveur du même nom, malgré son manque de sécurité.
6
Nous avons aussi installé :
– un serveur SSH,
– apache pour créer un Intranet,
– vino : le serveur VNC pour gnome,
– GIMP,
– xterm,
– ltsp-Server V5,
– VNC-Server.
2.2
Les clients légers
Ce sont des machines NEOWARE EON 400I prêtées par le LORIA.
Première prise de contact avec celles-ci :
Ce sont des boitiers d’environ 29 X 25 X 3 cm avec à l’intérieur :
– Processeur Geode (NCS) cadencé à 300 Mhz.
– Mémoire 64 Mbytes
– Système d’exploitation NeoLinux 2.4.1-051903 (permettant juste d’amorcer la machine)
Fig. 2.1 – Vue interne d’un client léger
7
Nous trouvons sur la façade avant :
– Un bouton marche/arret.
– Un voyant ”Sous-Tension”.
– Un voyant ”présence réseau”.
Et à l’arrière les connecteurs suivants :
– Une prise d’alimentation secteur.
– Deux Prises Vidéo VGA (une sur la carte mère, inopérante, l’autre sur
une carte d’extension).
– Une prise clavier PS2.
– Une prise souris PS2.
– Une prise RJ45 pour connecter le réseau filaire.
– Une prise Entrée et Sortie son.
– Deux prises DB9 pour connection terminal série.1
– Une prise DB25 pour connection imprimante parallèle.2
– Deux ports USB.
Fig. 2.2 – Vue avant et arrière du client léger
1 Nous
n’avons pas pu tester cette sortie, n’ayant pas trouvé de périphérique série à connec-
ter.
2 Nous n’avons pas pu tester cette sortie, n’ayant pas trouvé d’imprimante parallèle à
connecter.
8
Aucune documentation ne nous a été fournie avec le matériel, heureusement,
Google est notre ami et Internet regorge d’informations sur cet appareil.
Première chose à faire, réinitialiser le mot de passe root qui nous est inconnu.
Nous avons trouvé une procédure qui permet de démarrer en mode single
user, il est alors très simple de modifier le mot de passe root :
– mise sous tension avec shift droit enfoncé.
– un prompt lilo classique linux apparait.
– entrer au clavier la phrase suivante pour booter en single user (attention :
clavier en mode qwerty à ce niveau de démarrage du NEOWARE) : «
software single ». Selon la version du logiciel dans le NEOWARE, ce n’est
peut-être pas le mot « software ». Le prompt lilo indiquera le bon mot à
taper.
– attendre quelques secondes puis faire Alt-F2 pour obtenir une console
texte en single user.
– on obtient alors un prompt en single user.
– Il est alors possible de modifier le mot de passe du compte root par la
simple commande passwd.
Ceci nous montre une grosse lacune quand à la sécurité du système. Lacune
qui nous est bénéfique et dont nous profitons. Nous apprenons par la même occasion que l’on peut se connecter au client léger en mode telnet (et sur le compte
”root” !). Nous ne nous priverons pas de cette possibilité pour reparamètrer les
machines.
Ensuite, nous réinitialisons le client.
Pour cela, le redémarrer.
1. Réinitialisation du mot de passe.
Choix Settings / Appliance Properties / Security puis Change Password.
(Entrer 3 fois le mot de passe root)
2. Autoriser les connections à être créées ou modifiées.
3. Réinitialisation du server.
Choix Settings / Appliance Properties / Factory Reset.
4. Après le redémarrage de la machine, il faudra, de nouveau, renseigner le
mot de passe root.
Création des connections
1. création d’une connection Telnet vers le serveur.
2. création d’une connection X Windows en mode ”Chooser”.
3. création d’une connection X Windows en mode ”Direct” vers le serveur.
4. création d’une connection X Windows en mode ”Indirect” vers le serveur,
cette dernière nous propose un choix de serveurs trouvés sur le réseau,
mais ne nous permet pas de nous connecter au serveur !
5. Création d’une connection ”Netscape” permettant d’entrer directement
sur l’intranet de notre réseau.
9
2.3
Des PC en tant que clients légers
Nous utiliserons aussi des PC portables, en tant que client léger. Ceux-ci
étant relativement récent (processeurs dual-core, plus de mémoire vive), nous
remarquerons la différence de temps de réponse entre ces derniers et les clients
légers prêtés par le LORIA.
Cela est d’autant plus visible lorsqu’on regarde une vidéo. Sur les PC, l’image
est relativement fluide, sur les clients légers, on a l’impression de visualiser un
diaporama !
2.4
Notre système de clients légers
Nous avons gardé une connexion sur le réseau “ASRALL” afin de pouvoir
installer et faire les mises à jour des logiciels du serveur.
Sur une seconde carte réseau, nous avons monté “notre” réseau “clients
léger”. Il est composé de :
– Un routeur Linksys WRT54G monté en switch.
– Trois clients légers NEOWARE connectés en filaire.
– Quelques PC portables connectés en filaire (tests avec Wifi).
Fig. 2.3 – Configuration du réseau
10
Chapitre 3
XDMCP
3.1
Présentation
La version 4 de X11 introduit X Display Manager Control Protocol (XDMCP)
en décembre 1989 pour corriger les problèmes présents dans X Display Manager
de la version 3 de X11, sortie en octobre 1988.
Le serveur X est lancé par un gestionnaire d’affichage X, comme xdm, gdm
ou kdm. Le gestionnaire d’affichage peut se connecter à un serveur X local ou
distant en utilisant le protocole XDMCP.
Il est spécifié dans X11 que la communication entre les programmes, le gestionnaire de fenêtre, le gestionnaire d’affichage et le serveur d’affichage doit se
faire au travers de sockets réseau locales ou distantes.
XDMCP utilise par défaut le port UDP 177.
3.2
Connexion
Le serveur X (du client) envoi une requête ”Query” au gestionnaire d’affichage X (XDM). Si la connexion est autorisée, XDM répond par un paquet
”Willing”. Le gestionnaire d’affichage s’authentifie lui même sur le serveur. Pour
ce faire, le serveur X envoie un paquet ”Request” au Display Manager, qui renvoie un paquet ”Accept”. Si le paquet ”Accept” est conforme à ce que le serveur
X attend, le Display Manager est identifié. Le serveur X envoie alors un paquet ”Manage” pour signaler au Display Manager qu’il est bien identifié. Enfin,
l’écran de connexion apparaı̂t.
Pendant la session, le serveur X envoie des paquets ”KeepAlive” au Display
Manager. S’il ne répond pas au bout d’un certain temps, le serveur X arrête la
connexion.
11
Fig. 3.1 – Schéma simplifié du fonctionnement de XDMCP
12
3.3
Mise en place.
Il existe deux méthodes d’activation du serveur.
3.3.1
Activation manuelle
Il est possible de l’activer en réglant les options dans la partie XDMCP du
fichier de configuration du display manager.
Partie intéressante du fichier de configuration
[xdmcp]
Enable=true
3.3.2
Activation graphique
Fig. 3.2 – Capture d’écran de réglage de XDMCP avec GDM
13
3.4
3.4.1
Avantages / Inconvénients.
Avantages
– Déjà présent avec le serveur X depuis 1989, donc facile et rapide à mettre
en place.
3.4.2
Inconvénients
– Non sécurisé (aucun chiffrement par défaut).
– Nécessite un serveur X sur le client, donc un support de stockage.
– Consomme beaucoup de ressources réseau.
14
Chapitre 4
VNC
4.1
Introduction
Virtual Network Computing ou VNC est un logiciel utilisé pour se connecter
à un ordinateur distant. Il permet de transmettre les saisies au clavier ainsi que
les clics de souris d’un ordinateur à l’autre, à travers un réseau informatique,
qu’il soit local ou par le biais d’Internet. VNC est indépendant de la plateforme, un client VNC installé sur n’importe quel système d’exploitation peut se
connecter à un serveur VNC installé sur un autre système d’exploitation. Plusieurs clients peuvent se connecter en même temps sur un même serveur VNC.
L’utilisation principale de ce logiciel est le support technique à distance. Il
est aussi possible de visualiser des fichiers sur son ordinateur de travail à partir
de son ordinateur personnel ou, pour un professeur, de contrôler ce que font ses
élèves pendant le cours d’informatique.
Il existe deux types de serveur VNC.
1. Le premier, le seul que nous allons mettre en place, créé une session ”virtuelle” accessible par le client. Le client exploite donc les ressources du
serveur pour utiliser cette session virtuelle.
2. Le deuxième type de serveur VNC consiste à prendre le contrôle du poste
distant, donc à contrôler sa session ainsi que sa souris et son clavier.
4.2
4.2.1
Installation
Installation du serveur
Pour installer le serveur, voici la commande :
apt-get install vncserver (ou vnc4server sous Debian)
Pour lancer le serveur, voici la commande :
vncserver [:n], n étant le numéro de la session à démarrer.
Par défaut, VNC utilise les ports 590n, n étant le numéro de session. Par
exemple : vncserver :2 lancera un serveur VNC sur la session numéro 2 (soit
le port 5902)
15
4.2.2
Installation du client
Pour installer le client, voici la commande :
apt-get install xvncwiewer (ou xvnc4viewer sous Debian)
Pour lancer le client, voici la commande :
vncviewer 192.168.0.45:1 (:1 si c’est la première session, dans ce cas, port = 5901)
Pour tuer une session (sur le serveur) :
vncserver -kill :1
4.3
Encapsulation SSH
VNC n’est pas sécurisé. Les mots de passe circulent donc en clair sur le
réseau. Pour remédier à ce problème, nous allons encapsuler VNC dans un tunnel SSH crypté.
Pour passer par un cryptage ssh, il faut faire un transfert de port sur le pc
du client :
ssh -f -N -L 1337:localhost:5901 [email protected]
(f :background, N :pas de commande, -L 1337 :transfert du port 5901 non crypté
vers le port 1337 encapsulé dans du SSH)
Puis on accède sur le serveur via le tunnel sur la machine client :
vncviewer localhost:1337\\
Fig. 4.1 – Connexion VNC sécurisé par SSH
16
4.4
Se connecter sur un serveur VNC avec GDM
En temps normal, pour se connecter sur une session vnc, il faut qu’un utilisateur lance le serveur VNC. Le client se connectera donc avec l’identité de
l’utilisateur qui a lancé le serveur.
En clair, on se connecte avec l’utilisateur ”eleve” sur le serveur, on lance VNC,
le client se connecte, il sera automatiquement connecté sur le serveur en tant
que ”eleve”.
Pour changer cela, il est possible de se connecter sur un serveur VNC grâce
à GDM (et donc un utilisateur au choix sur la machine).
Pour cela il faut installer le paquet suivant :
sudo apt-get install xinetd
Puis définir un mot de passe :
sudo vncpasswd /root/.vncpasswd
Ensuite il faut créer le fichier suivant :
/etc/xinetd.d/Xvnc
et le compléter de la sorte :
service Xvnc
{
type = UNLISTED
disable = no
socket_type = stream
protocol = tcp
wait = yes
user = root
server = /usr/bin/Xvnc
server_args = -inetd :1 -query localhost -depth 16 -once
-DisconnectClients=0 -NeverShared
passwordFile=/root/.vncpasswd
port = 5901
}
Enfin, il suffit de redémarrer la machine et un compte sera automatiquement
créé, disponible sur le port 5901.
4.5
Problèmes rencontrés
Il faut penser à lancer le bon Windows Manager dans le .vnc/xstartup. De
plus, en cas d’écran gris, j’ai eu cette erreur : “/etc/X11/xinit/xinitrc : permission denied”
Pour la résoudre j’ai remplacé dans le xtartup “exec /etc/X11/...” par “exec
sh /etc/X11/...”
17
4.6
4.6.1
Avis
Avantages
– La mise en place est très rapide et assez simple, que ce soit sur le serveur
ou sur le client.
4.6.2
Inconvénients
– Pour lancer plusieurs sessions différentes, il faut démarrer explicitement
ces sessions.
Par exemple, si l’on veut 3 sessions différentes il faut lancer 3 commandes
vncserver auparavant.
– Le protocole n’est pas crypté, il faut mettre en place un tunnel SSH pour
le faire passer.
– La protocole est assez gourmand en ressources système du fait qu’il compresse les données avant de les envoyer.
18
Chapitre 5
LTSP
5.1
Présentation
5.1.1
Présentation du projet
Le projet Linux Terminal Server Project (LTSP) est un ensemble de programmes et scripts pour Linux qui permettent de connecter des clients légers à
un serveur.
Ce projet est publié sous la licence GNU/GPL, et la première version est sortie
en août 1999.
Son fondateur et mainteneur principal est Jim McQuillan.
La dernière version, sortie en 2006 est LTSP 5.
5.1.2
Différences LTSP 4/LTSP 5
LTSP 4 fut publié en 2004. Cette version a permis l’utilisation des périphériques
locaux sur les clients (comme les lecteurs CD, imprimantes...). Elle utilisait ses
propres binaires. LTSP 4 est encore utilisé actuellement pour sa légèreté. La
version 5 (connue aussi sous le nom MueKow) est une nouvelle approche du
projet, LTSP ne fournit plus de binaires mais un framework, de façon à utiliser
les composants du système hôte. Ainsi les outils et mises à jour de la distribution sont utilisés et l’équipe LTSP peut se concentrer sur l’essentiel du projet.
Cela permet aussi une meilleure intégration aux distributions et un plus grand
nombre d’architectures supportées.
Tableau récapitulatif :
Version
Export GUI
Serveur d’authentification
Connexion distante/ X display manager
Méthode de distribution
19
LTSP 4
XDMCP
serveur XDMCP
KDM/GDM
sources LTSP
LTSP 5 (MueKow)
ssh -X
serveur SSH
LTSP Display Manager (LDM)
distribution native
5.1.3
–
–
–
–
Principales fonctionnalités de LTSP 5.
Environnement de connexions sécurisées par SSH (LDM).
Utilisation possible de 3 imprimantes locales.
Utilisation d’un scanner local.
Accès aux périphériques locaux et à la carte son du client.
5.1.4
Configuration matérielle recommandée.
Ces recommandations proviennent principalement de la documentation de
LTSP.
Client
– CPU : Au moins 533 MHz. Il est possible d’utiliser des processeurs de 233 à
533MHz, mais au détriment de certaines fonctions, comme le chiffrement.
– Mémoire RAM : Minimum 48MB, mais le client sera très lent. Il est recommandé 128MB pour une utilisation fluide et optimale.
– Carte Réseau : Si possible permettant un boot (g)PXE, sinon il faudra
utiliser gPXE/Etherboot sur un support.
– Carte Vidéo : Utilisant le bus PCI.
Serveur
Le dimensionnement du serveur dépend de l’usage qui est fait des clients.
Les recommandations sont faites pour une utilisation ”classique”, c’est à dire :
bureautique et un peu de multimédia.
– CPU : 2GHz pour 20 clients. Le multi-coeur (ou même multi-processeurs)
est recommandé, surtout dans le cas d’un grand nombre de clients.
– Mémoire RAM : 256MB(Mémoire occupée par le serveur lui même) +
192MB/Client.
– Disque Dur : Dépend du nombre d’applications installées. Le RAID est
recommandé.
Réseau
Pour une utilisation bureautique l’usage du réseau est de 0.5 à 2Mbit/s,
mais peut monter à 70Mbits/s (voir plus) lors d’un usage multimédia. Pour un
usage plus orienté multimédia ou avec plus d’une vingtaine de clients, il est
recommandé d’utiliser un réseau Gigabit.
Caractéristiques de notre structure.
Notre serveur (CPU Intel Pentium IV à 2,80GHz et 1024Mo de memoire
RAM) et notre réseau (100 Mb/s), permet de connecter théoriquement 4 clients
légers pour un usage bureautique et multimédia léger et jusqu’à 6 clients pour
des applications peu gourmandes en mémoire RAM.
20
5.2
5.2.1
Principe de fonctionnement
Démarrage du client
– Le client démarre sur le réseau via le protocole PXE ou Etherboot et
contacte le serveur DHCP qui va lui attribuer une configuration réseau et
les informations nécessaires (chemin du fichier à télécharger sur le serveur
via TFTP).
– Le noyau Linux est téléchargé par TFTP puis exécuté sur le client.
– Le noyau initialise les périphériques du client.Quand le noyau est téléchargé,
il télécharge aussi un ”initramfs” qui contient des utilitaires et des scripts
que le client a besoin pour démarrer.
– La boucle locale de l’interface réseau est configurée.
– Un client DHCP (ipconfig) est lancé.
– Le système de fichier va être monté via NFS. Jusque là le système de
fichier était un ramdisk. Maintenant le /init script va monter un nouveau
système racine via NFS dans le dossier /root. Une fois le système monté,
la racine est changée de / à /root. Enfin les dossiers nécessitant des droits
en écritures, comme /tmp et /var sont montés en mémoire
– La système lance la configuration du client.
– Si le son est configuré le démon pulseaudio est lancé. Si le support des
périphériques de stockage locaux est activé, le démon ltspfsd est démarré.
– Les sessions graphiques sont initialisées. Si LDM est utilisé le serveur X
démarre un tunnel SSH. Si startx est utilisé, XDMCP est lancé.
– L’utilisateur peut se connecter.
Fig. 5.1 – Schéma du démarrage du client.
21
5.2.2
Services requis et utiles
Services nécessaires :
Service
DHCP
TFTP
Port(s)
67/68
69
Protocole
udp
udp
NFS
SSH
Portmaper
2049
22
111
udp/tcp
tcp
udp/tcp
XFS (X Font Service)
7100
udp/tcp
6000-6003
udp/tcp
X11
Remarques
configuration du réseau.
transfert de fichiers nécessaire au boot image
du noyau.
montage à distance du système de fichier du client.
cryptage des données.
Démon qui attribue à un logiciel donné
le port correspondant.
Service fournissant des fichiers de police
à ses clients.
Interface utilisateur graphique.
Services Optionnels :
Service
CUPS
SANE
Syslog
XDMCP
5.3
5.3.1
Port(s)
9100
6566
514
177
Protocole
tcp
tcp
udp
udp/tcp
Remarques
Systeme d’impression.
Gestion des scanners.
Gestion des logs.
X Display Manager Control Protocol.
Installation et configuration.
Installation.
Installation de ltsp :
Sous Debian il existe 2 paquets : ltsp-server et ltsp-server-standalone. Ltspserver est juste le serveur ltsp, alors que ltsp-server-standalone inclus les paquets
nécessaires au bon fonctionnement de LTSP sous forme de dépendance, comme
dhcp3-serveur, tftp-hpa, etc...
Nous avons decidé d’installer ltsp-server-standalone, car nous utilisons un
seul serveur pour tous les services.
apt-get install ltsp-server-standalone
Dependances : dchp3-server, openssh-server, ltsp-server, ltspfs, nfs-kenrel-server,
nbd-server, libasound2-plugins, openbsd-inetd, squashfs-tools, tftpd-hpa, xauth.
Construction du client :
L’installation du chroot client se fait grâce à l’outil ltsp-build-client. Cet outil crée le chroot, l’initialise et installe le système de base.
Cet outil télécharge une Debian complète dans /opt/ltsp/i386 et installe
ltsp-client et LDM (Ltsp Display Manager) : le gestionnaire de connexion.
Il a pour options :
– –dist permet de choisir une distribution Debian differente de celle du serveur.
22
– –arch permet de définir l’architecture (i386, powerpc, ARM, ...).
– –base permet de modifier le répertoire d’installation.
Nous avons choisi de garder le dossier d’origine et d’utiliser une Debian
Lenny (stable) pour les clients comme pour le serveur. Les clients et le serveur
utilisent l’architecture i386.
Il est possible de créer le dossier du chroot manuellement, par exemple pour
installer une distribution différente entre les clients et le serveur.
5.3.2
Configuration du serveur.
Configuration de DHCP
Ci-dessous, les parties concernant LTSP dans le fichier de configuration :
/etc/dhcp3-server/dhcpd.conf
#LTSP
authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.250;
# option domain-name "example.com";
option domain-name-servers 192.168.1.1;
option broadcast-address 192.168.1.255;
# option routers 192.168.0.1;
# next-server 192.168.0.1;
# get-lease-hostnames true;
option subnet-mask 255.255.255.0;
option root-path "/opt/ltsp/i386";
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/i386/pxelinux.0";
} else {
filename "/ltsp/i386/nbi.img";
}
}
Répertoires exportés par NFS
Le fichier /etc/exports défini les répertoires à exporter par NFS. Pour les
clients légers il s’agit du dossier où se trouve les systèmes clients, à savoir
/opt/ltsp. Nous le montons en lecture seule (ro), autorisant le montage par
root (no root squash),en permettant au serveur NFS de répondre aux requêtes
avant que tous les changements soient effectués (améliore les performances, au
risque de perdre des données en cas de redémarrage brutal d’un serveur)(async)
et en neutralisant la vérification des sous-répertoires(no subtree check).
/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)
23
Configuration de tftpd
TFTP qui veut dire Trivial File Transfert Protocol est un protocole simplifié
de transfert de fichiers.
Il fonctionne en UDP sur le port 69, au contraire de FTP qui utilise TCP sur
le port 21. L’utilisation d’UDP comme protocole implique que le client et le
serveur doivent gérer eux-mêmes une éventuelle perte de paquets. On réserve
plutôt l’usage de TFTP à un réseau local, vu le manque de fiabilité du protocole
UDP.
Le serveur TFTP utilisé est tftp-hpa, il a été installé comme dépendance de
ltsp-server-standalone.
Il faut ajouter au fichier de configuration /etc/inetd.conf.
tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot
Le dossier /var/lib/tftpboot contient les fichiers essentiels pour réaliser un boot
réseau.
Et mettre dans le fichier /etc/default/tftpd-hpa
RUN_DAEMON="yes"
afin de lancer tftpd comme démon au démarrage de la machine.
Démarrer tftpd.
Par défaut tftpd-hpa est démarré par inetd, il faut donc relancer inetd après
avoir installé tftpd-hpa et mis à jour les fichiers de configuration.
invoke-rc.d openbsd-inetd restart
5.3.3
Configuration des clients.
Pour que le client puisse se connecter au serveur LTSP il doit permettre
le boot réseau ((g)PXE). La plupart des ordinateurs le permettent en activant
cette fonction dans le bios.
Si le bios du client ne le permet pas il faut alors utiliser Etherboot avec un
périphérique de stockage (disquette, CDRom, clé USB, ...) sur lequel le client
pourra démarrer. Le client s’initialisera sur le péripherique de stockage, puis
continuera sur le réseau.
Il est possible de modifier GRUB. Cette solution est utile dans le cas d’un
ordinateur avec un système d’exploitation installé et pouvant, aussi, être utilisé
comme client léger.
Récupérer une image ROM sur le site http ://rom-o-matic.net/ (Projet
Etherboot).
La copier dans le dossier /boot sous le nom, par exemple, ltsp.zlilo.
Ajouter au fichier /boot/grub/menu.lst les lignes suivantes :
title LTSP
# partition sur laquelle se trouve le répertoire /boot
root (hd0,1)
kernel /boot/ltsp.zlilo
24
REMARQUE : Un client léger ne peut pas démarrer sur un réseau Wifi. Mais
il est possible d’utiliser Etherboot pour démarrer et ensuite utiliser le Wifi.
5.3.4
Configuration de LTSP
Cette configuration ce fait dans le fichier /opt/ltsp/i386/etc/lts.conf. Grâce
à ce fichier nous pouvons configurer les clients dans leur ensemble ou individuellement grâce aux sections et aux groupes. La section [default] s’applique à tous
les clients. Une section peut être utilisé pour un client. Pour définir un groupe
il suffit de créer une section qui ne correspond pas à un client et d’associer les
clients au groupe avec la directive LIKE.
Nous allons vous présenter les options utiles par catégorie, puis vous donner le fichier de configuration final. Nous ne présenterons ici que les principales options, pour une liste exaustive, se référer à la documentation de LTSP
(http ://www.ltsp.org/ sbalneav/LTSPManual.html#id2536548)
Configuration Clients
Variables
SOUND
LOCALDEV
LOCAL APPS
CONSOLE KEYMAP
XKBLAYOUT
XKBMODEL
XKBVARIANT
X COLOR DEPTH
USE TOUCH
SCREEN “num”
Valeurs Possibles
true, false
true, false
true, false
Mappage clavier (fr, en, ...)
Mappage clavier (fr, en, ...)
Modèle de clavier
Variante de clavier
2,4,6,8,16,24,32
true, false
ldm, xdm, shell, startx, ....
Remarques
Active le son sur les clients
Active le support des périphériques locaux
Active le support des applications locales.
Disposition du clavier pour la console
Disposition du clavier pour X11
Modèle du clavier pour X11
Variante du clavier pour X11
Profondeur de l’affichage
Active le support des écrans tactiles
Type de session utilisée par l’écran “num”
Réglage des serveurs
Variables
DNS SERVER
SEARCH DOMAIN
USE NDB SWAP
SWAP SERVER
NBD PORT
USE XFS
XFS SERVER
XDM SERVER
Valeurs Possibles
@ IP
nom de domaine
true, false
@ IP
Numéro de port
true, false
@ IP
@ IP
Remarques
Serveur DNS
Nom de domaine
Active le swap réseau
Adresse IP du serveur de swap
Numéro de port du serveur swap
Utilisation d’un serveur de police
Adresse du serveur de police
Adresse IP du serveur XDMCP
Imprimantes
Variables
PRINTER 0 DEVICE
PRINTER 0 TYPE
Valeurs Possibles
Chemin (/dev/lp0)
P(parallèle), S(série), U(USB)
PRINTER 0 PORT
port
25
Remarques
Chemin de l’imprimante
Type de l’imprimante,
Obligatoire pour les imprimantes séries,
les autres sont automatiquement détectées.
Numéro de port de l’imprimante
Options spécifiques LDM
Variables
LDM AUTOLOGIN
Valeurs Possibles
true, false
LDM USERNAME
compte utilisateur sur le serveur
LDM PASSWORD
mot de passe du compte utilisateur
LDM ALLOW GUEST
true, false
Remarques
Connecte automatiquement
l’utilisateur décrit par les options
LDM USERNAME et
LDM PASSWORD.
spécifie le nom d’utilisateur
que le client devra utiliser
pour une ouverture de
session automatique.
spécifie le mot de passe à utiliser
pour l’ouverture automatique
de session.
fait apparaitre un bouton
“Login as Guest” sur l’écran
de connection. Cliquer sur ce bouton
connecte l’utilisateur décrit par les
options LDM USERNAME et
LDM PASSWORD.
Voici notre fichier de configuration :
#
#
#
#
lts.conf file for ltsp 5.
For more information about valid options please see:
/usr/share/doc/ltsp-client/examples/lts-parameters.txt.gz
in the client environment
[default]
SOUND=True
#Peripheriques locaux
LOCALDEV=True
HOTPLUG=Y
#CONFIGURE_X=False
X_COLOR_DEPTH=16
#Pc Portable Cedric
[00:17:31:96:25:D8]
SCREEN_02=shell
SCREEN_06=startx
SCREEN_07=ldm
X_COLOR_DEPTH=32
[Neoware]
X_COLOR_DEPTH=8
XKBLAYOUT=fr
[00:E0:C5:6E:69:2F]LIKE=Neoware
26
[00:E0:C5:6E:68:E2]LIKE=Neoware
[00:E0:C5:6E:6A:50]LIKE=Neoware
##Imprimante
#[]
# PRINTER_0_DEVICE = /dev/lp0
# PRINTER_0_TYPE = P
# PRINTER_0_PORT = 1
5.3.5
Administration des clients.
Mise à jour et installation/suppression de programmes :
Il suffit d’utiliser la commande chroot et chrooter sur l’environnement du
client et utiliser les commandes disponibles, comme apt-get.
Mise à jour du noyau :
Pour réaliser la mise à jour du noyau il existe une commande spécifique :
ltsp-update-kernels. Cette commande doit être lancé à partir du serveur (et
non dans l’environnement chrooté du client). Elle permet de mettre à jour le
noyau contenu dans le dossier du serveur TFTP et les fichiers de configuration
nécessaire au boot du client.
Mise à jour des clés SSH :
Ltsp utilisant ssh, en cas de modification de l’adresse IP du serveur il faut
effectuer une mise à jour des clés en utilisant la commande ltsp-update-sshkeys.
5.4
Tests.
Nous avons réalisés plusieurs séries de test pour mesurer la consommation
mémoire et réseau ainsi que l’efficacité selon les clients et les applications lancées.
5.4.1
Consommation réseau pour un client léger :
Bureautique : (OpenOffice Writer) : de 500Kbits/s (repos) à 2,5Mbits/s
(frappe rapide de texte, déplacement de fenêtres) et quelques pointes à 5MBits/s.
Lecture de vidéo (640x480) : 70Mbits/sec.
5.4.2
Charge du serveur :
RAM 80 Mo/client bureatique jusqu’à 130 Mo avec un navigateur (firefox)
Internet. CPU Pour trois clients connectés simultanément, 10% en repos et
jusqu’à 100%.
5.4.3
Efficacité des clients :
Nous avons voulu voir l’influence des clients léger sur les performances.
Nous avons donc comparé un client léger Neoware (voir configuration en première
partie) et un portable récent (Intel Core Duo 1,66GHz et 1Gb de RAM) utilisé
27
comme client léger.
Nous avons, bien sur, utilisé la même configuration LTSP pour les 2 clients.
Nous remarquons que le Neoware est plus lent au démarrage (2 minutes 30 secondes contre 35 secondes pour le PC portable), que le déplacement des fenêtres
et la lecture de vidéo apparaissent saccadées sur les clients légers, alors que le
PC portable n’éprouve aucun problème. Ces légers ralentissement proviennent
du fait que le Neoware possède très peu de RAM et éprouve des difficultés à
déchiffrer tous les paquets reçus lors d’un fort afflux de données (70MBits/sec
lors de la lecture de vidéo).
Au vue de ces différences nous avons testé un PC avec un processeur à 900MHz
et 512Mo de RAM. Il n’y a pas de différence avec le PC portable. Le processeur
doit donc avoir une fréquence vers les 900MHz pour avoir un client léger tres
réactif.
28
Chapitre 6
Free NX
6.1
Présentation
La technologie NX est un protocole client-serveur permettant des connexions
graphiques X11 distantes rapides et sûres pour accéder à un bureau Linux / Unix
à distance. Le protocole est basé à la fois sur SSH (pour la sécurité) et sur la
compression X (pour l’interface graphique et la rapidité). Selon l’éditeur, NX est
aussi beaucoup plus facile à utiliser que le protocole X classique. Il est développé
par Gian Filippo Pinzari de l’éditeur de logiciels italien NoMachine.
NoMachine NX est une solution Terminal Serveur et d’accès distant basée
sur un ensemble de technologies open source de classe entreprise. Les binaires
eux-mêmes sont des applications propriétaires. NX permet de lancer n’importe
quelle application graphique sur n’importe quel système d’exploitation à travers
n’importe quelle connexion de réseau à une vitesse remarquable.
FreeNX est une application client léger / serveur open source basée sur la
technologie NX de NoMachine. Elle est capable de faire fonctionner des sessions
graphiques X11 sur toute connexion à partir d’un modem 56 kbps, soit malgré
une faible bande passante et une latence importante. Le paquetage FreeNX
contient une implémentation libre (GPL) de la composante nxserver.
Le schéma provient de http ://openfacts2.berlios.de/wikien/index.php/BerliosProject :FreeNX NX Components
NX permet d’utiliser un bureau à distance, comme VNC.
29
Fig. 6.1 – Schéma Export d’affichage via le réseau.
NX utilise 3 méthodes basiques pour accélérer l’affichage à distance :
1. La compression des données.
2. La mise en cache des données.
3. La suppression du trafic X11 redondant.
NoMachine a développé son propre algorithme de compressions pour le trafic
X : NX Compression. Il est, environ, dix fois plus efficace que le code générique
de compression ZLIB. C’est le premier secret de la rapidité de NoMachine NX.
NoMachine a aussi développé un mécanisme intelligent de cache pour le trafic X11. C’est le second secret.
Avant NX, il n’existait pas de méthode pour supprimer les aller-retours sur
le réseau entre le serveur et les clients. NX transfert le trafic vers le client et c’est
ce dernier qui gère, à travers l’application NXAgent. C’est le troisième secret.
Ces trois méthodes combinées, permettent d’être jusqu’à soixante-dix fois
plus efficace et rapide que toutes les autres méthodes.
6.2
Installation
La solution retenue ici est celle de FreeNX, pour plusieurs raisons :
– FreeNX est libre et gratuit (Sous licence GPL).
– FreeNX n’est pas limité à deux clients simultanés, contrairement à NX
Server Free Edition.
Remarque : la version commerciale de NX Server n’a pas de limite de clients,
suivant la licence retenue.
30
6.2.1
Sur le serveur
L’installation de FreeNX nécessite un serveur SSH fonctionnel. En effet, c’est
par ce dernier que passe le trafic.
Une documentation existe pour debian, mais elle est un peu ancienne. Elle
est disponible via http ://wiki.debian.org/freenx
Les paquets disponibles pour debian sont assez anciens, et ne sont plus compatible avec les dernières versions des clients NX.
Deux solutions se présentent :
– Compiler les paquets à la main
– Installer les paquets provenant d’un dépot extérieur.
La solution retenue ici est la seconde solution.
Un tutoriel pour Ubuntu et Debian est disponible à cette adresse : http ://doc.ubuntufr.org/freenx.
6.2.2
Installation du serveur
Il faut ajouter le dépot dans /etc/apt/sources.list.
deb http://ppa.launchpad.net/freenx-team/ppa/ubuntu intrepid main
Puis, ajouter la clé du dépot :
gpg --keyserver subkeys.pgp.net --recv-keys D018A4CE
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 2A8E3034D018A4CE
Il est maintenant possible d’installer le serveur FreeNX.
apt-get install freenx
Quelques questions sont alors posées.
Le nom du groupe de travail pour samba/windows.
J’ai laissé WORKGROUP par défaut.
6.2.3
Configuration du serveur
Édition du fichier /etc/ssh/sshd config
Si on souhaite utiliser l’identification par échange de clés SSH, il faut décommenter
la ligne
AuthorizedKeysFile
\%h/.ssh/authorized_keys
Redémarrer alors le serveur ssh via la commande
31
/etc/init.d/ssh restart
Edition du fichier /etc/nxserver/node.conf
Si le port a été modifié sur le serveur ssh, il faut penser à modifier la ligne
SSHD PORT=22 en remplaçant 22 par le nouveau port.
Création du certificat (auto-signé)
Ce certificat pour ssh permet de se connecter à distance sans mot de passe.
Remarque : j’ai eu quelques soucis en reconfigurant FreeNX sur un
autre serveur. La connexion via l’échange de clés ssh posait problème
(le client n’arrivait pas à s’identifier, code NX 204), j’ai donc commenté la ligne AuthorizedKeysFile %h/.ssh/authorized keys
dans la configuration du serveur ssh et relancé le démon. La connexion
a donc pu s’établir sans aucun soucis. La seule contrainte est que
l’identification par login/mot de passe est obligatoire.
dpkg-reconfigure freenx-server
Dans la liste, choisir Create Custom Keys, puis Authentification avec SSH.
Copier alors la clé située dans /var/lib/nxserver/home/custom keys/client.id dsa.key
sur une clé USB (ou autre support).
Elle servira à identifier un poste client.
La configuration du serveur est terminé.
Penser alors à relancer le démon freenx pour que les changements soient pris
en compte.
/etc/init.d/freenx-server restart
6.2.4
Sur le client
On peut installer QTNX ou un client NX provenant de NoMachine. Ces
derniers ne sont pas limités au niveau nombre de connexions.
Ici, le client installé est le client NX sur un poste fonctionnant sous Windows
XP.
L’installation s’effectuant de manière classique, elle ne sera pas détaillée.
6.2.5
Configuration du client
La configuration du client est assez simple. Le seul problème pouvant être
rencontré est celui du pare-feu windows, qui bloque toute connexion entrante
ou sortante. Il faut alors penser à débloquer nxclient et nx-ssh.
Configuration du client
Il faut préciser le nom de la session (qui sera comme profil), l’adresse du
serveur NX et le port sur lequel celui-ci écoute. On peut aussi préciser le type
de connexion, afin d’optimiser la bande passante.
Le choix de l’environnement de bureau se fait sur cette étape. Comme le
serveur est un serveur unix, et que le bureau proposé est gnome, il faut choisir
unix et gnome. Il est possible de choisir une autre résolution d’écran.
32
Fig. 6.2 – Pare-feu Windows bloquant NX client.
Fig. 6.3 – Pare-feu Windows avec les services NX ajoutés dans la liste des
services autorisés.
33
Fig. 6.4 – Configuration - introduction.
Fig. 6.5 – Configuration - introduction.
34
Fig. 6.6 – Configuration - introduction.
Fig. 6.7 – Configuration - introduction.
35
Fig. 6.8 – Boı̂te de dialogue de connexion
La configuration est terminée, et le client peut se connecter au serveur via
un raccourci placé sur le bureau.
L’ouverture de session graphique est simple.
Après quelques secondes, l’écran affiche le logo NoMachine, puis le bureau
apparaı̂t. Il est dès lors, utilisable.
6.2.6
Sécurité
La connexion s’effectuant via ssh, le niveau de la sécurité est donc liée à ce
dernier.
6.3
Performances, montée en charge
(nombre d’utilisateurs, nombre d’applications)
NX étant conçu pour fonctionner avec une connexion de type modem 56k,
le nombre d’utilisateurs total pouvant se connecter à un serveur NX peut être
assez conséquent.
Il a été possible de regarder une vidéo sans trop de soucis en utilisant la
configuration type “modem”. En utilisant la configuration type “ADSL”, la
vidéo fut parfaitement fluide. Par contre, comme aucun serveur de son était
configuré sur le poste client, il n’y avait pas de son.
Cependant, comme chaque utilisateur ouvre une session graphique sur le
serveur, celui-ci doit être suffisamment puissant pour pouvoir répondre à la
demande. Néamoins, en utilisant des environnements graphiques assez légers,
comme fluxbox ou WindowMaker, le serveur devrait accepter cette montée en
charge.
6.4
Émulation application Windows
Les applications étant exécutées sur le serveur, il est possible d’installer wine
ou crossover office pour exécuter des applications Windows.
36
Fig. 6.9 – Le bureau gnome affiché dans un client NX.
6.5
Gestion des périphériques
Les applications s’exécutant sur le serveur, elle ne peuvent pas voir les
périphériques branchés sur un poste client.
6.6
Impression
L’impression via une imprimante réseau est possible, la configuration étant
effectuée sur le serveur. Cependant, cette fonctionnalité n’a pas été testée.
37
Chapitre 7
Conclusion
L’utilisation de postes “client léger”, à faible coùt, est un avantage certain.
Un système clients legers est, aussi, une bonne alternative pour “recycler” des
PC hors service, ou obsolètes.
Les systèmes clients légers offrent l’énorme avantage d’avoir les applicatifs et les
bases de données centralisés, d’où une maintenance simplifiée pour l’administrateur système.
L’évolution du parc informatique est plus simple et, souvent, moins coùteuse
car il suffit de faire évoluer le serveur.
Tous les systèmes testés ont comme point commun leur facilité de mise en
oeuvre, et la plupart du temps, les options par défaut des fichiers de configuration suffisent à obtenir un système opérationnel.
Dans le cas spécifique de ltsp, la documentation officielle se montre pessimiste dans ses chiffres. En effet, nous avons remarqué que le système consommait
moins de ressources qu’annoncé.
Au titre des quelques choses “regrettables”, il faut remarquer que l’avantage de la centralisation devient un inconvénient en cas de panne du serveur ou
du réseau. En effet, là où les utilisateurs pourraient faire de la “bureautique”
avec un système conventionnel, ils sont complètement bloqués. L’utilisation de
la haute disponnibilité doit être envisagée pour pallier à ce soucis.
Si les options par défaut des fichiers de configuration suffisent à avoir un
système opérationnel, il faut toutefois mettre les mains dans le cambouis pour
améliorer certains points.
VNC déplore, lui, une grave lacune quand à la sécurité des informations
circulant sur le réseau. Heureusement l’encapsulation SSH permet de parer cette
imperfection au prix d’une légère augmentation de la charge CPU.
38
39
LTSP
VNC
Facile à mettre en
oeuvre. Complet.
XDMCP
Mise en place très rapide, tant au niveau
du serveur que du
client.
Déjà présent avec
le serveur X depuis
1989, facile et rapide
à mettre en place.
Free NX
Très gourmand en
ressources. Il faut
lancer autant de
sessions sur le serveur que de sessions
clientes désirées.
Nécessite un serveur
sur le client, donc un
support de stockage.
Consomme beaucoup
de ressources réseau.
Consomme beaucoup
de ressources réseau.
obliga-
Client
toire.
Faible bande passante
nécessaire.
Facile à installer.
NX
Inconvénients
Avantage
Solution
Protocole
nonsécurisé,
d’où
la
nécessité de l’encapsuler dans un tunnel
SSH.
Très bonne sécurité.
(SSH par défaut)
Non sécurisé (aucun chiffrement par
défaut).
Bonne sécurité, car
lié à SSH. Toutefois, certains ports
doivent être ouverts.
Sécurité
Il
n’est
possible
d’ajouter
des
périphériques
que
sur le serveur.
Oui, aussi bien côté
client que serveur.
Nulle
Gestion
des
périphériques
Tout
périphérique
branché sur le serveur,
imprimantes
et partages réseau
accessibles depuis le
serveur.
VNC est un protocole assez lourd
(vidéo). il a une
meilleure
gestion dans un cas
multi-session
en
bureautique
Moyenne.
Plutôt moyen
La mise en cache permet de réduire l’utilisation de la bande
passante, et un modem 56k suffit.
Performances
Chapitre 8
Remerciements
Nous remercions tout d’abord le LORIA, et plus particulièrement Laurent
VALLAR, sans qui, notre projet aurait été privé d’une partie de sa substance
et aurait été réduit à “peau de chagrin”.
Nous remercions aussi Gael LAMBERT et Yilmaz ILHAN qui nous ont évité
de nous perdre dans les méandres d’Internet en nous remettant le résultat de
leurs recherches, et ainsi de nous permettre de privilégier la partie pratique.
Nous remercions Felix CHASSAGNE, Philippe DOSCH, Remi JACHNIEWICZ et Vincent MESLARD sans qui le document actuel aurait été fait avec
autre chose que LaTex.
Nous remercions monsieur Sylvain GALLION pour sa gentillesse, sa disponnibilité et la rapidité de ses interventions lors des problèmes matériels rencontrés.
Et bien sur, notre tuteur : Damien MARINGER, pour le support qu’il nous
a fourni, et ses encouragements.
40
Chapitre 9
Glossaire
– LORIA : Le LORIA, Laboratoire Lorrain de Recherche en Informatique et
ses Applications, est une Unité Mixte de Recherche commune à plusieurs
établissements.
Pour plus d’information, voir leur site web sur http ://www.loria.fr.
– X11 : X11 ou X Window System ou X est une interface utilisateur graphique utilisée sur les systèmes UNIX (Linux,BSD,..)
– PXE : Preboot eXecution Environment est un protocole permettant à un
ordinateur de démarrer à partir d’un réseau.
Le boot se déroule en 3 étapes :
1. Recherche d’informations par DHCP et du chemin de l’image disque
à booter par TFTP.
2. Téléchargement du fichier image.
3. Chargement de l’image en mémoire. La taille de l’image est limitée
et ne permet pas d’utiliser directement un noyau Linux. L’image ne
sert qu’à lancer le telechargement du noyau.
– gPXE/Etherboot : gPXE/Etherboot est un chargeur reseau sous GPL,
visant à remplacer les ROM PXE proprietaire par une solution libre. Ces
ROM peuvent aussi etre chargé à partir d’une disquette, d’un CD-ROM,..
pour booter sur le réseau meme si l’ordinateur ne le peut pas.
– chroot : Chroot est une commande des systèmes Unix permettant de modifier la racine visible du systeme. Dans le cas des clients leger, elle permet
d’administrer l’environement des clients leger.
– framework : En informatique, un framework est un espace de travail modulaire. C’est un ensemble de bibliothèques, d’outils et de conventions
permettant le développement d’applications. Il fournit suffisamment de
briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et dont la maintenance est aisée. Ces composants sont organisés pour être utilisés en interaction les uns avec les
autres.
41
Chapitre 10
Sources
1. http ://www.wikipedia.fr/
2. http ://people.math.jussieu.fr/
3. http ://www.informatique.math.jussieu.fr/
4. http ://forums13.itrc.hp.com/
5. http ://www.hp.com/
6. http ://www.ubuntu-fr.org/
7. http ://www.psil.fr/spip.php ?rubrique11
8. http ://www.ltsp.org/
9. Linux Magazine No 102
42