Retrouvez cet article dans : Linux Magazine 78

Les machines récentes sont de plus en plus puissantes et de moins en moins onéreuses. Pour autant, les ordinateurs plus anciens fonctionnent toujours et n’ont généralement rien perdu de leurs capacités. Une collaboration entre le projet LTSP et la distribution Ubuntu permet de tirer partie de ces deux phénomènes avec une simplicité jusqu’ici inconnue.

Alors voilà, vous venez d’acquérir une petite machine équipée d’un (deux ?) processeur(s) 64 bits bi-cœur avec 8 Go de mémoire centrale et 1 To d’espace disque.
Mais aussi clinquante soit-elle, la nouvelle arrivée ne peut effacer le souvenir de votre vieille compagne, aux 200 Mhz et quelques 64 Mo de RAM encore vaillants...
Dommage que son disque dur se soit transformé en microsillon et ne soit plus bon qu’en objet décoratif. Ajoutez à cette nostalgie les réclamations du gamin qui veut son « dinateur » pour faire comme papa et maman, le dramatique de la situation n’échappera à personne.
Heureusement, l’association entre le Linux Terminal Server Project (LTSP) [1] et la distribution Ubuntu [2] est là pour vous sauver.

(Aparté) Pour être honnête...

Pour cet article, le serveur et le terminal ont été en réalité installés dans deux machines virtuelles VmWare, le tout fonctionnant sur un Pentium IV à 3.2 GHz équipé de 1 Go de mémoire.
Le serveur virtuel s’est vu attribué 400 Mo de mémoire, le terminal 64 Mo, la machine hôte restant réactive et l’ensemble tournant assez confortablement. Le monstre évoqué en introduction serait capable de « tirer » 20 ou 30 terminaux sans trop de souci.

Installation du serveur

La base utilisée est une distribution Edubuntu [3], une variante d’Ubuntu destinée aux enfants en général et à leur éducation en particulier.
Toutefois, ce qui suit est parfaitement valable pour la distribution Ubuntu « normale » ou l’autre variante Kubuntu, qui utilise KDE plutôt que Gnome.
L’installation du système sur le serveur ne sera pas détaillée, tellement sa simplicité confine à la trivialité. Normalement, à l’issu de l’installation vous obtenez l’écran d’accueil d’Edubuntu :

Nous allons ensuite suivre les informations du ThinClientHowto [4], avec quelques adaptations. En particulier, le paquetage ltsp-server-standalone, qui fournit un environnement complet pour ce que nous voulons faire, a été installé lors de l’installation du système.
Si tel n’est pas le cas, installez-le : vous le trouverez dans la section « Divers – Texte » du gestionnaire de paquetages Synaptic. Vous pouvez également exécuter en ligne de commande :

$ sudo apt-get install ltsp-server-standalone

L’installation de ce paquetage va nous permettre de mettre en place notre configuration le plus simplement possible, avec attribution automatique des adresses IP des clients par un serveur DHCP propre.
Cela fait, quelques réglages sont à effectuer, notamment en ce qui concerne les adresses IP. Si vous utilisez un réseau privé de classe A comme votre serviteur, une paire de fichiers est à modifier.
En premier lieu, corrigeons la configuration du serveur DHCP réservé à LTSP, qui se trouve dans le fichier /etc/ltsp/dhcpd.conf.
En supposant que le serveur a pour adresse IP 10.0.0.1, que le réseau sur lequel il se trouve utilise une passerelle d’adresse 10.0.0.2 et accède à un serveur de nom en 10.0.0.3, voici un exemple de configuration :

authoritative;
subnet 10.0.0.0 netmask 255.0.0.0 {
  range 10.0.0.100 10.0.0.200;
  option domain-name «example.com»;
  option domain-name-servers 10.0.0.3 ;
  option broadcast-address 10.255.255.255;
  option routers 10.0.0.2 ;
  option subnet-mask 255.0.0.0;
  filename «/ltsp/pxelinux.0»;
  option root-path «/opt/ltsp/i386»;
}

La ligne introduite par range donne l’intervalle d’adresses IP pouvant être allouées par le serveur DHCP aux clients qui en réclame une. Par ailleurs, le nom de domaine a été laissé ici à sa valeur par défaut example.com, libre à vous d’inscrire ce que bon vous semble.
Ensuite, il faut autoriser les clients à accéder à certaines ressources du serveur. Cela est fait au moyen du fichier /etc/hosts.allow, par exemple en y inscrivant ceci :

portmap:        10.0.0.0/8
rpc.mountd:     10.0.0.0/8
rpc.statd:      10.0.0.0/8
in.tftpd:       10.0.0.0/8

Cela ouvre les services nécessaires à toutes les adresses IP présentes sur le réseau. Pour un déploiement sur une échelle plus grande que votre chambre, il peut être préférable de limiter à quelques plages d’adresses ou sous-réseaux.
Il est maintenant nécessaire de redémarrer le système NFS pour l’accès aux systèmes de fichier par réseau, à l’aide de ces trois commandes :

$ sudo invoke-rc.d nfs-kernel-server restart
$ sudo invoke-rc.d nfs-common restart
$ sudo invoke-rc.d portmap restart

Enfin, la dernière étape est de préparer l’environnement qui sera utilisé par le système fonctionnant sur les clients. Ceux-ci n’accèderont en effet pas au système principal, mais à un environnement chrooté. La commande à lancer est simplement :

$ sudo ltsp-build-client --mirror http://fr.archive.ubuntu.com/ubuntu

Le paramètre --mirror indique quelle source de paquetages utiliser, ici le miroir français d’Ubuntu. Plus de 125 Mo vont être récupérés de cette source : il peut donc être intéressant d’utiliser une source « locale ». Si vous n’avez pas accès à un miroir local ou à un accès internet suffisamment rapide, il est possible d’utiliser le CD-ROM d’installation pour cette opération. Il suffit de le monter quelque part, puis d’en donner le chemin comme source des paquetages. Par exemple :

$ sudo mount /dev/hdc /media/cdrom0
$ sudo ltsp-build-client --mirror file:///media/cdrom0

Oui, il y a bien trois / dans la ligne précédente, ce n’est pas une erreur.
Cette commande va créer une arborescence dans /opt/ltsp/i386, qui peut atteindre près de 1 Go pendant qu’elle travaille, puis finalement dans les 400 Mo une fois que tout est terminé.
Mon conseil : redémarrez complètement le serveur.
Intéressons-nous maintenant à la machine qui va nous servir de terminal.

Préparation du terminal

Première remarque : il semble indispensable de disposer d’au moins 64 Mo de mémoire sur celui-ci. En dessous, des problèmes peuvent survenir et empêcher le démarrage du système.
Deuxième remarque : il n’est pas nécessaire que cette machine dispose d’un disque dur ou d’un lecteur de CD-ROM. Une carte réseau et un lecteur de disquette suffisent.
Et si ce terminal est suffisamment récent pour être capable de démarrer sur le réseau ou que vous pouvez installer une ROM sur la carte réseau, le lecteur de disquette n’est même pas indispensable.
Le cas le plus fréquent est toutefois probablement celui d’une machine ancienne et sans possibilité d’installer une ROM.
Nous allons donc examiner le cas d’un démarrage sur une disquette. Mais dans tous les cas, il est indispensable de connaître précisément le modèle de la carte réseau.
Il est en effet nécessaire de générer un micro-système permettant au terminal de démarrer, puis de récupérer son véritable système par le réseau. C’est précisément l’objet du projet Etherboot [5].
Mais plutôt que d’entrer dans des détails compliqués (quoique fort intéressants), nous allons utiliser une facilité offerte par Marty Connor sur le site ROM-o-matic [6], qui consiste à générer automatiquement une image ROM pouvant être inscrite dans une carte réseau ou placée sur une disquette.
Choisissez de préférence la dernière version stable, 5.4.1 au moment où j’écris ces lignes.
Il faut d’abord choisir le modèle de carte réseau. 270 sont reconnues, vous devriez donc trouver la vôtre. Dans le cas présent, l’image pcnet32:lancepci est celle qui nous concerne, à adapter selon votre carte.
Choisissez ensuite le type de ROM que vous voulez. Comme nous allons démarrer le client par une simple disquette, choisissez Floppy Bootable ROM image (.zdsk) dans la liste.
Généralement, l’étape (optionnelle) de personnalisation n’est pas nécessaire.
Cliquez donc sur le bouton « Get ROM » : votre navigateur web devrait vous proposer de sauvegarder un fichier, nommé quelque chose comme eb-5.4.1-pcnet32.zdsk, qui dans mon cas ne fait pas plus de 24 Ko.
Inscrivez ensuite ce fichier sur une disquette, par exemple avec la commande :

$ dd if=eb-5.4.1-pcnet32.zdsk of=/dev/fd0

Naturellement, adaptez le nom de l’image ROM à celle que vous avez obtenue du site ROM-o-matic.
Ouf ! Maintenant, tout devrait être prêt. Insérez la disquette dans le lecteur du terminal, puis démarrez-le.

Connexion

Normalement, vous devriez voir quelque chose comme ceci sur l’écran du terminal alors qu’il démarre :

Bientôt suivent les messages usuels de démarrage d’un système GNU/Linux. Après quelques secondes (ou minutes, selon la rapidité du réseau et la puissance du terminal), vous obtenez un écran de connexion (page ci-contre).
Il suffit alors de s’identifier comme à l’accoutumée, et voilà !
Pour fixer les idées, sur mon (mini) système d’étude j’ai créé deux utilisateurs. Le premier se connecte directement sur le serveur pour exécuter le tableur Calc d’OpenOffice.org 2

Le deuxième se connecte sur le terminal et lance le traitement de textes Writer. Le serveur répond sans problème, la mémoire totale utilisée étant inférieure à 500 Mo.
Pour prendre un autre exemple, voici l’écran d’un serveur avec le moniteur système tandis que sur le terminal s’affiche GCompris, suite logicielle éducative de fort belle facture, mais qui n’est pas précisément réputée pour être légère :

 

Clairement, d’après ce petit test, un serveur sensiblement plus puissant pourrait assurer le fonctionnement sur de nombreux terminaux.
Il n’a jamais été aussi simple de donner une seconde vie à nos vieilles machines !

Liens :
[1] LTSP : http://www.ltsp.org/
[2] Ubuntu : http://www.ubuntu.com/
[3] Edubuntu :
http://www.edubuntu.org/
[4] Ubuntu Thin Client Howto :
https://wiki.ubuntu.com/ThinClientHowto
[5] Etherboot :
http://www.etherboot.org/
[6] ROM-o-matic :
http://www.rom-o-matic.net/