rapport sur le projet tuteur´e “les clients l´egers”
Transcription
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