Installer un serveur de clients légers (LTSP sous Debian Wheezy) dans un réseau Se3

De Wiki Dane (ex wikitice)
Aller à : navigation, rechercher

Sommaire

Présentation

Un serveur de clients légers permet de gérer facilement un ensemble de PC disposant d'une carte réseau PXE (ou d'une solution Etherboot) ainsi que des Raspberry Pi (avec le projet Berryterminal).

Cet article décrit la solution libre LTSP 5 (Linux Terminal Server Project Version 5) sous Debian Wheezy. Pour un serveur LTSP sous Debian Jessie, consulter :
Installer un serveur de clients légers (LTSP sous Debian Jessie) dans un réseau Se3

L'objectif étant, par exemple, d'installer et de pouvoir gérer simplement des points d'accès Web dans un établissement scolaire.

A noter :

Quasiment tout cet article a été testé sur machines virtuelles ; seule la configuration "1 serveur LTSP + 2 Clients légers (Raspberry) en kiosque Web dans l'architecture A" a été testée en réalité et est fonctionnelle.

Architectures réseaux possibles avec un serveur LTSP

On peut envisager trois architectures réseaux, la dernière étant un mixte des deux premières :

  • Architecture A : Les clients légers "dans" le réseau pédagogique


Diagramme reseau.jpeg

Dans cette architecture, le serveur LTSP n'a qu'une carte réseau et les clients légers sont connectés sur le réseau pédagogique. Cette configuration est simple à mettre en oeuvre côté matériel puisqu' elle utilise l'architecture réseau déjà existante (attention toutefois, les clients légers consommant de la bande passante, les commutateurs réseaux doivent être "calibrés" en conséquence, selon le nombre de clients légers connectés).
Par contre, les serveurs LTSP ne pourront pas faire serveur DHCP (il ne peut en général y avoir qu'un serveur DHCP dans un réseau) : il faudra donc renseigner chaque client léger dans le serveur DHCP du SE3 (sauf si utilisation d'un proxy DHCP ? avec dnsmasq ? ).
Cette architecture peut être adoptée pour mettre en place quelques kiosques web gérés par un serveur LTSP dans un réseau pédagogique. En effet, les kiosques Web sont en général dispersés dans le lycée et sont rarement tous utilisés en même temps ; l'architecture réseau existante est en générale suffisante.


  • Architecture B : Les clients légers "dans" un sous-réseau du réseau pédagogique


Diagramme reseau2.jpeg

Dans cette architecture, le serveur LTSP a deux cartes réseaux, une sur le réseau pédagogique et une autre dans le sous-réseau de clients légers où il fait office de serveur DHCP. Ce dernier peut distribuer des adresses IP aux clients légers dans une plage d'adresses données (il n'est ainsi pas nécessaire de saisir pour chaque client son adresse IP et son adresse MAC ...). Cette architecture peut être envisagée pour gérer une ou plusieurs salles de classe.

Dans cette configuration, les clients légers n'impactent pas le trafic du réseau pédagogique.

  • Architecture C : Cluster de serveurs LTSP

Il est possible de mixer les deux architectures précédentes et de mettre plusieurs serveurs LTSP : on obtient alors un cluster de serveurs LTSP.

Cluster serveurs LTSP.jpeg

Remarques :

  • Pour les serveurs LTSP n'ayant qu'une carte réseau (architecture A), il est possible de les séparer en "serveur d'environnement" et en "serveurs d'applications" et de configurer le serveur d'environnement en répartiteur de charge (load balancing).
  • Pour les serveurs LTSP a deux cartes réseaux (architecture B), il est possible de les configurer "par pair" en "DHCP failover" afin d'introduire de la tolérance aux pannes.

Principe

LTSP exploite l'aspect multi-utilisateur et multi-tâche du système Linux : des postes clients se connectent via le réseau sur un serveur LTSP et peuvent utiliser (ou non) les ressources de ce serveur pour y lancer des applications.

Ces derniers sont appelés des clients légers car :

  • lors de leur démarrage PXE, ils vont monter par le réseau leur environnement (leur racine /) présente sur le serveur LTSP  : ils n'ont donc pas besoin de disque dur.
  • ils peuvent exécuter des applications en utilisant leurs propres ressources (ram et processeur) ou celles du serveur LTSP . Dans ce dernier cas, ils peuvent être assimilés à des terminaux X se contentant de gérer l'affichage écran et la saisie clavier.

L'identification des utilisateurs et les échanges entre les clients légers et le serveur LTSP sont sécurisés par ssh et gérés par le gestionnaire d'affichage LDM du projet LTSP.

Un serveur LTSP regroupe les services suivants :

  • TFTP (et si nécessaire DHCP) pour réaliser le boot PXE des clients légers.
  • NFS pour mettre à disposition un environnement, c'est à dire la racine / montée par les clients légers via le réseau lors de leur démarrage.
  • SSH pour sécuriser l'identification des utilisateurs et éventuellement les échanges graphiques entre le serveur et les clients légers.
  • LDM pour lancer les applications sur le serveur LTSP et gérer la liaison entre le serveur LTSP et ses clients légers (montage des répertoires, ...)

Un serveur LTSP est donc un serveur d'environnement (TFTP + NFS) et une serveur d'identification et d'applications (SSH + LDM). Le réseau est donc beaucoup plus sollicité que sur un réseau de clients non légers.

Remarque :
Il est possible d'utiliser NBD à la place de NFS : le boot du client léger est censé être plus rapide (image compressée) et NBD devrait économiser de la bande passante sur le réseau. Par contre, il est nécessaire à chaque modification de l'environnement du client léger de reconstruire l'image compressée.

Les trois "types" de clients légers

Sur le serveur LTSP, il est possible de construire trois environnements différents pour les clients légers :

  • Un environnement léger :

le client léger lance une session X (gnome, lxde, xfce, ...) sur le serveur LTSP et tout est exécuté sur le serveur LTSP puis "déporté" sur l'écran du client léger dans un tunnel X (ssh -X) : le client se comporte alors comme un terminal X et a besoin de peu de ressource (128 à 256 Mo de RAM).

  • Un environnement lourd (Fat client) :

le client léger lance une session X de son environnement et exécute des applications installées dans son environnement, avec ses propres ressources (ram et processeur) : le serveur LTSP est alors « juste » utilisé pour identifier l'utilisateur et mettre à disposition des clients légers leur environnement. On parle alors de "Fat client". Cette configuration permet d' « alléger » le serveur LTSP mais nécessite des clients légers plus performant (1 Go de ram pour des applications avec java et flash).

  • Un environnement hybride (local-app) : il s'agit d'un environnement léger dans lequel certaines applications (iceweasel, libreoffice, …) sont installées dans l'environnement du client léger afin d'être exécutées avec ses ressources (la session X reste par contre lancée sur le serveur LTSP).

Intérêt d'un serveur LTSP

On ne configure que le serveur LTSP et cette configuration est disponible à l'ensemble des clients légers gérés par ce serveur LTSP :

  • Pour des clients légers, on configure et installe les applications directement sur le serveur LTSP.
  • Pour des fat clients, on configure et installe les applications dans leur environnement (on chroote), sur le serveur LTSP.
  • Pour les clients hybrides, on fait un mixte des deux points précédents.

Démarrage d'un client léger

On peut résumer la séquence de démarrage par :

  • Le client léger boote en PXE (ou Etherboot) sur le réseau.
  • Le serveur DHCP (SE3 ou LTSP, selon l'architecture) lui envoie son adresse IP ainsi que celle du serveur LTSP (TFTP).
  • Le client léger télécharge sur le serveur LTSP (TFTP) un noyau linux et une initrd qu'il exécute.
  • Le client léger monte son environnement (sa racine /) présent sur le serveur LTSP via le réseau (NFS).
  • Le client léger lance le gestionnaire d'affichage LDM présent dans son environnement.
  • Un utilisateur se connecte sur le client léger avec un compte local du serveur LTSP ou un compte de l'annuaire ldap du se3.
  • Selon l'environnement du client léger (léger ou lourd), une session X (lxde, xfce, gnome ..) est lancée soit sur le serveur LTSP, soit sur le client léger.


A noter :

Les clients légers peuvent être de marque et de configurations différentes. Seule leur architecture (i386, amd64 ou arm) a une importance.

Configuration matérielle des clients et du serveur [non testé]

Les données ci-dessous sont extraits du "guide de référence LTSP pour l'administrateur" (datant de juin 2009) :

Clients légers en environnement léger

CPU : au moins 533 Mhz

RAM : 256 Mo

Carte réseau : 100 Mbs (usage normal de 0,5 à 2 mbit mais pic possible à 70 Mbs si consultation de contenu multimedia sur le serveur LTSP)

Serveur LTSP

CPU : multi-processeurs.

RAM du serveur LTSP = 256 + (192 * Nb_clients_legers) MB

Exemple : pour gérer 20 clients légers, environ 4 Go de RAM (Si les clients ont un usage graphique gourmand, doubler la valeur précédente).

Carte(s) réseau(x) : 1 Gigabit

Clients légers en environnement fat client

La configuration du serveur LTSP en fat client va nécessiter moins de ressources en processeurs et en RAM sur le serveur LTSP vu que toutes les applications sont exécutées par les ressources du client léger. Par contre, les ressources réseaux sont sollicitées différemment :

  • alors que pour les clients légers, c'est le déport d'affichage graphique qui circule sur le réseau ethernet.
  • pour les fat clients, à chaque fois qu'un utilisateur lance une application (comme libreoffice), cette application est chargée via le réseau (NFS ou NBD) dans la RAM du fat client puis exécuté par son processeur. Si la carte réseau du fat client est en 100 Mbs, une application de taille 50 Mo prendra environ 4 secondes à être chargé en RAM avant de s'exécuter.

Autrement dit, le lancement d'une application en fat client peut être plus longue qu'en environnement léger (par contre, une fois chargée, l'utilisation de cette application doit être aussi rapide que sur un poste "classique").

C'est pourquoi il est préférable d'utiliser le service NBD plutôt que NFS, lorsque les clients sont configurés en fat client.

Procédure d'installation d'un serveur LTSP (Architecture A)

Dans ce paragraphe, on suppose que :

- le futur serveur LTSP a une carte réseau connectée au réseau pédagogique avec un serveur Se3 qui fait office de serveur DHCP.

- les clients légers sont dans le réseau pédagogique (architecture A)

  • Depuis le module dhcp du se3, réserver l'adresse IP de votre (futur) serveur LTSP.
  • Depuis le module tftp du se3, installer un système Debian Wheezy (Xfce dans cet article) sur votre (futur) serveur LTSP.
  • Une fois l'installation précédente terminée, installer le serveur LTSP. Pour cela, ouvrir une console sur votre serveur LTSP et saisir en tant que root :
apt-get update
apt-get install ltsp-server ldm-server ltsp-docs
  • Configurer le fichier /etc/exports pour le montage de la racine des clients légers par NFS. Pour cela :
nano /etc/exports

Rajouter la ligne suivante :

/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

Remarque :

Pour obtenir plus d'information sur ces options, saisir dans une console :

man exports

Construction de (ou des) environnement(s) des clients légers sur le serveur LTSP

Pour contruire l'environnement des clients légers sur le serveur LTSP, on utilise la commande ltsp-build-client. Pour obtenir l'ensemble des options, saisir :

ltsp-build-client --extra-help

Attention la construction d'un environnement prend du temps (heureusement qu'on ne le fait qu'une fois ;-)). Vous pouvez installer plusieurs environnements sur votre serveur LTSP pour choisir le plus approprié à vos clients légers.

  • Construire un environnement léger :
ltsp-build-client --arch i386 --chroot lightclient --prompt-rootpass

Cette commande installe l'environnement du nom de « lightclient » dans « /opt/ltsp/lightclient » et les fichiers nécessaire au démarrage PXE dans « /srv/tftp/ltsp/lightclient ». Saisir un mot de passe pour le compte root de l'environnement du client léger.

Les clients légers qui utilisent cet environnement comme racine disposeront du bureau et des applications installés sur le serveur LTSP et « tout » sera exécuté avec les ressources du serveur LTSP.

  • Construire un environnement hybride :

On commence par installer un environnement léger :

ltsp-build-client --arch i386 --chroot hybridclient --prompt-rootpass

Puis on installe dans cet environnement (on « chroote ») les applications que les clients légers doivent exécuter avec leurs propres ressources. Par exemple, si l'on souhaite que les clients légers lance le navigateur iceweasel avec leurs propres ressources. Sur le serveur LTSP, saisir :

ltsp-chroot --mount-dev --mount-proc --arch hybridclient
apt-get install iceweasel 
exit

Pour activer le mode hybride, activer le paramètre local-apps dans le fichier lts.conf de configuration des clients légers (voir paragraphe 13.2)

  • Construire un environnement lourd :
ltsp-build-client --arch i386 --chroot fatclient --fat-client-desktop xfce4 --prompt-rootpass

Cette commande installe l'environnement du nom de « fatclient » dans « /opt/ltsp/fatclient » et les fichiers nécessaire au démarrage PXE dans « /srv/tftp/ltsp/fatclient ».

Cet environnement contiendra le bureau xfce : on peut en mettre d'autres (lxde, gnome-desktop-environment ...), il est préférable de privilégier des bureaux "légers" pour économiser de la bande passante sur le réseau. Comme pour l'environnement hybride, il est possible ensuite d'installer d'autres applications dans cet environnement en chrootant sur le serveur LTSP avec la commande ltsp-chroot. Les fat clients lanceront le bureau xfce de leur environnement et toutes les applications s'exécuteront avec les ressources du client léger.

Pour activer le configuration "fat client", activer le mode "fatclient" dans le fichier lts.conf de configuration des clients légers (voir paragraphe 13.3)

A noter :

Choisir une architecture i386 permettra de faire fonctionner des clients légers ayant une architecture i386 ou amd64 (ainsi que les Raspberry Pi car ces derniers n'utilisent pas l'environnement du serveur LTSP mais la mini-distribution Berryterminal installée sur leur carte SD).

  • Redémarrer le serveur NFS :
service nfs-kernel-server restart

Configuration du serveur DHCP (le serveur SE3)

Il faut créer un fichier de configuration spécifique aux clients légers et définir un groupe par environnement installé sur le serveur LTSP.

Se connecter en tant que root sur votre se3 :

  • Créer un fichier /etc/dhcp/dhcpd_ltsp.conf qui contiendra la description de vos clients légers et les paramètres de votre serveur LTSP :
nano /etc/dhcp/dhcpd_ltsp.conf
  • Dans le fichier dhcpd_ltsp.conf créé, ajouter et adapter les lignes suivantes à votre réseau et à vos clients légers (il faut, pour chaque client léger, définir un nom d'hôte et donner son adresse MAC et une adresse IP à choisir selon la configuration du réseau pédagogique ) :


Si vous avez construit un environnement lightclient sur votre serveur LTSP, créer un groupe contenant la description de vos clients légers :

group {					               # description des clients légers qui utilisent l'environnement léger
       option root-path "/opt/ltsp/lightclient";       # chemin de l'environnement léger sur le serveur LTSP
       next-server 172.20.1.20;                        # IP du serveur TFTP (c'est à dire du serveur LTSP)
       filename "/ltsp/lightclient/pxelinux.0";        # chemin du chargeur d'amorçage PXE
        
         # On définit chaque client léger désservi par le serveur LTSP en indiquant son nom d'hôte, son adresse mac et ip
         # Client léger N°1
                host leger1 {                          # nom d'hôte ou dns du client
                hardware ethernet 00:fc:b9:15:13:gh;   # adresse MAC du client 1
                fixed-address 172.20.100.1;            # adresse IP du client (à choisir en fonction de la plage d'adresse du serveur DHCP, le se3)
                }
         
         # Client léger N°2 …
		host leger2 { 
                hardware ethernet 00:fc:b9:15:13:gh;          
                fixed-address 172.20.100.2;                   
                }
         }

Si vous avez construit un environnement hybridclient sur votre serveur LTSP, créer un groupe contenant la description de vos clients hybrides :

group {					                # description des clients légers qui utilisent l'environnement hybride
       option root-path "/opt/ltsp/hybridclient";       # chemin de l'environnement hybride sur le serveur LTSP
       next-server 172.20.1.20;                         # IP du serveur TFTP (c'est à dire du serveur LTSP)
       filename "/ltsp/hybridclient/pxelinux.0";        # chemin du chargeur d'amorçage PXE
        
         # Client hybrid N°1
                host hybrid1 {                          # nom d'hôte ou dns du client
                hardware ethernet 00:fc:b9:15:13:gh;    # adresse MAC du client 
                fixed-address 172.20.150.1;             # adresse IP du client (à choisir en fonction de la plage d'adresse du serveur DHCP, le se3)
                }
         
         # Client hybrid N°2
		host hybrid2 { 
                hardware ethernet 00:fc:b9:15:13:gh;          
                fixed-address 172.20.150.2;                   
                }
         }

Si vous avez construit un environnement fatclient sur votre serveur LTSP, créer un groupe contenant la description de vos fat clients :

group {					                # description des clients fat
       option root-path "/opt/ltsp/fatclient";          # chemin de l'environnement des clients hybrides sur le serveur LTSP
       next-server 172.20.1.20;                         # IP du serveur TFTP (c'est à dire du serveur LTSP)
       filename "/ltsp/fatclient/pxelinux.0";           # chemin du chargeur d'amorçage PXE
        
         # Fat client 1
                host fat1 {                             # nom d'hôte ou dns du client
                hardware ethernet 00:fc:b9:15:13:gh;    # adresse MAC du client 
                fixed-address 172.20.200.1;             # adresse IP du client (à choisir en fonction de la plage d'adresse du serveur DHCP, le se3)
                }
         
         # Fat client 2
		host fat2 { 
                hardware ethernet 00:fc:b9:15:13:gh;          
                fixed-address 172.20.200.2;                   
                }
         }

Remarques :

Il s'agit de la partie pénible de l'installation : pour se faciliter la tâche, il est possible de rapidement récupérer l'adresse MAC des clients légers à l'aide du module dhcp du serveur se3 :

- soit l'adresse IP de votre client léger n'a pas été réservée sur votre se3 : son adresse mac est alors visible dans le menu "Gestion des baux" du module dhcp du se3, via l'interface web du se3 (ne réserver pas l'adresse IP d'un client léger)

- soit l'adresse IP de votre client léger a été réservée sur votre se3 : son adresse mac est alors disponible dans le menu "Réservations actives" du module dhcp du se3 (via l'interface web du se3). Supprimer la réservation active du client léger.

Pour éviter un conflit entre les fichiers dhcpd.conf et dhcpd_ltsp.conf, supprimer de la réservation active du SE3 tous les clients légers que vous avez renseignés dans le fichier dhcpd_ltsp.conf (sinon votre serveur dhcp risque de ne pas redémarrer ...)

  • Se rendre sur l'interface Web du se3, dans le menu configuration du serveur dhcp, puis renseigner le fichier de conf à inclure (en chemin absolu) :
/etc/dhcp/dhcpd_ltsp.conf 
  • Valider la modification (votre serveur dhcp va redémarrer et l'inclure dans /etc/dhcp/dhcpd.conf)

Tester l'installation avec un compte local du serveur LTSP


Sur un client léger avec carte réseau PXE :

  • Démarrer en boot PXE (à régler dans le bios) un des clients légers que vous avez précédemment renseigné dans le fichier dhcpd_ltsp.conf du se3.
  • Une fenêtre de connexion apparaît sur l'écran du client léger : entrer l'identifiant et le mot de passe d'un des comptes local de votre serveur LTSP, par exemple, le compte enseignant.
  • Sur l'écran de votre client léger devrait s'afficher :

- soit un bureau identique à celui du compte local de votre serveur LTSP si le client léger utilise un environnement léger ou hybride.

- soit le bureau installé dans l'environnement si le client léger est configuré en fat client.


Sur un Raspberry Pi

Le Raspberry Pi ne dispose pas de boot PXE ; on peut quand même le transformer en client léger avec la mini-distribution Berryterminal (les ressources du serveur LTSP seront alors utilisées).

Berryboot permet de faire du multi-boot sur un Raspberry Pi, en particulier d'installer Berryterminal :

  • Télécharger la dernière archive zip du projet Berryboot disponible ici : Berryboot
  • Formater en FAT32 la carte SD de votre Raspberry Pi puis y désarchiver l'archive Berryboot .
  • Démarrer votre Raspberry Pi, puis dans la liste proposée, installer Berryterminal.
  • Redémarrer votre Raspberry Pi puis booter avec Berryterminal.
  • Une fenêtre de connexion apparaît sur l'écran du client léger : entrer l'identifiant et le mot de passe d'un des comptes local de votre serveur LTSP, par exemple, le compte enseignant.
  • Sur l'écran de votre client léger devrait s'afficher un bureau identique à celui du compte local de votre serveur LTSP.

(Mon raspberry pi n'a pas réussi à booter directement sur Berryterminal, à partir de l'archive zip présente ici Berryterminal, c'est pourquoi je me suis tourné vers Berryboot)


Remarques :

  • Si votre client léger utilise un environnement léger ou un environnement hybride :

- installer des applications sur le serveur LTSP : elles seront instantanément disponibles aux clients légers connectés.

- l'administration du serveur LTSP peut se faire depuis un client léger, en ouvrant xterm et en s'identifiant en tant que root sur le serveur LTSP.

  • Il existe une solution alternative à Berryterminal pour les Raspberry Pi, proposée ici : Solution alternative à Berryterminal utilisant une racine pour ARM sur le serveur LTSP. [NON TESTE ...].

S'identifier sur un client léger avec un compte (admin, prof ou élève) de l'annuaire ldap du se3

Jusqu'à présent, un utilisateur ne peut se connecter sur un client léger qu'avec le compte local (le compte enseignant) du serveur LTSP. Il est bien évidemment possible de rajouter des comptes locaux sur le serveur LTSP, en saissant en tant que root la commande suivante :

adduser user1

A noter :

- Éviter de connecter plusieurs clients légers sur le même compte local du serveur LTSP car certaines applications (tel que les navigateurs Web) se supportent pas plusieurs instances d'un même utilisateur.

Mais cette procédure atteint rapidement ces limites lorsque le nombre d'utilisateurs est important. Dans ce paragraphe, on détaille les modifications à apporter au serveur LTSP afin qu'un utilisateur puisse s'identifier sur un client léger avec ses identifiants se3 et récupérer un bureau identique à celui d'un client Linux non léger intégré au domaine se3.

Se connecter au client léger avec un compte utilisateur (admin, professeur ou élève) du se3

L'identification d'un utilisateur est réalisée par le module pam du service ssh du serveur LTSP. Il est possible de configurer ce module afin qu'il consulte l'annuaire ldap du serveur SE3 lors de l'identification de l' utilisateur d'un client léger : ce dernier pourra ainsi se connecter "au client léger" (au serveur LTSP en réalité ...) avec ses identifiants du réseau pédagogique.


Pour cela, sur le serveur LTSP, ouvrir un terminal, s'identifier en root puis saisir :

nano /etc/pam.d/sshd

Mettre en commentaire les "@include common-*" du fichier puis insérer les lignes suivantes :

#@include common-auth
@include common-auth.AVEC-LDAP

auth optional pam_script.so
#@include common-account
@include common-account.AVEC-LDAP
#@include common-session
session required pam_mkhomedir.so skel=/etc/se3/skel umask=0077                 # Création du home de l'utilisateur identique en contenu et en droit au modèle skel du se3
@include common-session.AVEC-LDAP
#@include common-password
@include common-password.AVEC-LDAP

Remarques

  • En procédant de cette façon, vous aurez le "pam de vos clients légers" configuré de la même façon que "celui de vos clients non légers".
  • Le home de l'utilisateur est identique à celui d'un client Linux non léger, à savoir le "skel" présent sur le se3 et qui permet de personnaliser le bureau des utilisateurs.
  • Le module pam_mkhomedir.so ne créé un home directory que si ce dernier n'existe pas pour l'utilisateur qui se connecte : ce module n'impacte donc pas le home directory des comptes locaux du serveur LTSP.

Monter automatiquement les partages Samba du se3

Nous allons utiliser le script /etc/se3/bin/logon 'ouverture' présent sur le serveur LTSP et permettant de réaliser, en autres, le montage automatique des partages Samba du se3 pour des clients Linux non léger.

Pour cela, ouvrir une console sur le serveur LTSP, se connecter en root, puis créer un script ouverture_ltsp.sh :

nano /etc/se3/bin/ouverture_ltsp.sh

Ajouter les lignes suivantes :

#!/bin/bash

if [ -x '/etc/se3/bin/logon' ]; then
   LOGNAME="$PAM_USER" /etc/se3/bin/logon ouverture
fi

exit 0

Mettre les droits en cohérence avec le dossier /etc/se3

chmod 700 /etc/se3/bin/ouverture_ltsp.sh 

Sur le serveur LTSP, modifier le module pam de ssh afin qu'il exécute le script précédent en tant que root et juste après l'identification de l'utilisateur. Pour cela, saisir :

nano /etc/pam.d/sshd

Ajouter la ligne correspondant au module "pam_exec.so" (attention, l'ordre des modules pam a une importance):

#@include common-auth
@include common-auth.AVEC-LDAP

auth optional pam_script.so
auth optional pam_exec.so /etc/se3/bin/ouverture_ltsp.sh

Remarque :

Le montage automatique des partages Samba du se3 est réalisé sur le serveur LTSP : il sera donc directement disponible aux clients légers configurés avec un environnement léger ou hybride.
Pour les fat clients, il faut réaliser le montage des partages Samba dans leur environnement. Sachant que les partages Samba de l'utilisateur sont montés dans le répertoire /mnt du serveur LTSP, il faut donc monter ce répertoire dans l'environnement du fat client : ce montage peut se faire à l'aide du protocole sshfs. Cette configuration s'effectue dans fichier lts.conf de configuration des fat clients (voir paragraphe 13.3).

Tester votre serveur LTSP intégré au se3

  • Redémarrer votre serveur LTSP et attendre que la fenêtre de login de Gnome apparaisse.
  • Démarrer un de vos clients légers configurés avec un environnement léger ou hybride.
  • Sur le client léger, s'identifier avec un compte du domaine se3 (admin, professeur ou eleve).
  • Apparaît sur l'écran du client léger un bureau identique à celui des clients Linux non légers intégrés au se3.

Remarque :

Pour tester un fat client, paramétrer au préalable son fichier lts.conf comme expliquer au paragraphe 13.3

Configuration des clients légers PXE

Ce paragraphe ne concernent pas les Raspberry (car ces derniers n'utilisent pas l'environnement construit sur le serveur LTSP).

Ces clients légers se configurent à travers le fichier lts.conf présent dans l'environnement "/opt/ltsp/$CHROOT/etc/" sur serveur LTSP (dans cet article, $CHROOT vaut soit lightclient, soit hybridclient ou fatclient)
[Sécurité : penser à mettre les droits 700 sur ce fichier afin qu'il ne soit pas lisible par les clients légers]

Attention, il y a un fichier lts.conf par environnement : si vous avez installé plusieurs environnements sur votre serveur LTSP, il faudra alors configurer chacun fichier lts.conf.

Pour obtenir une liste très détaillée de l'ensemble des paramètres possibles ainsi qu'un exemple, saisir sur le serveur LTSP la commande :

man lts.conf

Paramètres globaux appliqués à l'ensemble des clients légers

Les paramètres de la section [Default] du fichier lts.conf s'appliquent à l'ensemble des clients légers ayant cet environnement.

On peut par exemple :

Régler les locales
[Default]                          # Paramètres globaux qui seront appliqués à l'ensemble des clients légers
LDM_LANGUAGE=fr_FR.UTF-8          
Régler le clavier
XKBLAYOUT=fr                      

Pour paramétrer un client léger particulier, préciser son adresse mac suivi de ces paramètres. Par exemple :

Réaliser un autologin des clients légers
[00:00:fc:48:2e:mn]                # Adresse MAC du client léger auquel s'applique les paramètres qui suivent
LDM_AUTOLOGIN=true              
LDM_USERNAME=user1                 # compte local sur le serveur LTSP pour ce client léger
LDM_PASSWORD=mdp_user1             # mot de passe du compte local du client léger sur le serveur LTSP
Activer le clavier numérique des clients légers
X_NUMLOCK=true                     # Le paquet numlockx doit être installé dans l'environnement des clients légers (faire du chroot ...)'''
Désactiver les périphériques du client léger
LOCALDEV=false                    # Désactive le montage sur le serveur LTSP des périphérique (tel que les clés usb) des clients légers.
Désactiver la tunnel X via ssh et rendre les connexions réseaux plus fluides mais moins sécurisés (utilisé avant la version V5 de LTSP)
LDM_DIRECTX=True                  # Utilise un protocole moins sécurisé pour les échanges graphiques entre le serveur LTSP et les clients légers.

Activer l'environnement hybride des clients légers (local_apps)

LOCAL_APPS=True                               # Activie le mode hybride 
LOCAL_APPS_MENU=True                          # Autoriser les applications disponibles dans la liste d'applications du bureau à s'exécuter sur le client léger
LOCAL_APPS_MENU_ITEMS=iceweasel,libreoffice   # Liste des applications à exécuter sur le client léger : ces applications doivent avoir étés au préalable chrootées dans l'environnement du client léger

Activer l'environnement des fat client et monter via sshfs les partages Samba du se3

LTSP_FATCLIENT=True                           # Activer le mode fatclient : LDM va lancer la session X installée dans l'environnement du client léger à la place de celle du serveur LTSP
LOCAL_APPS_EXTRAMOUNTS=/mnt                    # Les partages Samba sont montés dans le dossier /mnt du serveur LTSP : il faut donc monter via sshfs ce dossier dans l'environnement du fatclient afin de récupérer le montage des partages Samba du se3.

Configuration des clients légers Raspberry pi

  • Au démarrage du Raspberry, penser à verrouiller Berryboot par un mot de passe.
  • Berryterminal n'utilise pas la racine présente sur le serveur LTSP (/opt/ltsp/i386/) : on ne peut donc pas configurer le Raspberry avec le fichier lts.conf du serveur LTSP.

Les paramètres du fichier lts.conf doivent être rajoutés sur une ligne dans le fichier de configuration cmdline.txt présent sur la carte SD sur laquelle a été installée Berryterminal. Par exemple :

server=172.20.1.20 XKBLAYOUT=fr LDM_LANGUAGE=fr_FR.UTF-8

Remarques :<br

  • Vous pouvez aussi saisir ces paramètres plus simplement à partir du menu de multi-boot s'affichant au démarrage du Raspberry.
  • En spécifiant l'adresse IP du serveur LTSP dans la variable SERVER, il devient inutile de renseigner l'adresse MAC et IP des Raspberry Pi dans le fichier de conf du dhcp du se3.

Remarques sur Berryterminal :

  • Berryterminal étant une solution spécifique au Raspberry pour se connecter à un serveur LTSP, il n'est pas dit que tous les paramètres du fichier lts.conf soient intégrés à Berryterminal et donc utilisables pour configurer le Raspberry.
  • Avec Berryterminal, toutes les applications sont exécutées sur le serveur LTSP.

Piloter les clients connectés avec Epoptes

Epoptes est une application similaire à Italc : elle permet de visionner et de piloter un ensemble des postes clients linux. Son déploiement est très simple.

Installation rapide et simple : l'application maître d'epoptes sur le serveur LTSP

Cette installation convient pour des clients légers hors fat client. Elle consiste à installer l'application maître et l'application cliente sur le serveur LTSP.

  • Sur le serveur LTSP :
apt-get update
apt-get install epoptes          # installe l'application maître et le client d'epoptes
  • Ajouter les utilisateurs autorisés à utiliser epotes. Par exemple, pour que le compte enseignant puisse utiliser epoptes, saisir :
gpasswd -a enseignant epoptes
  • Se connecter sur le serveur LTSP (à partir d'un client léger par exemple) avec le compte enseignant puis lancer l'application maître d'epoptes.
  • Démarrer puis se connecter sur un (ou des) clients légers (hors fat client).
  • Des miniatures des postes des clients légers doivent apparaître.

Installation du client d'epoptes sur des fat clients

L'installation précédente ne fonctionnne pas pour des fat clients car ces derniers n'ouvrent pas leur session sur le serveur LTSP mais à partir de leur environnement : il faut donc chrooter le client epoptes dans l'environnement du fat client.

  • Sur le serveur LTSP, saisir en tant que root :
ltsp-chroot -a fatclient -m                 # Chroot dans l'environnement des fat client avec montage de /dev et de /proc
  • Ouvrir un terminal sur le serveur LTSP, puis saisir en tant que root :
apt-get install epoptes-client
  • Renseigner l'adresse IP du poste maître (pour récupérer les certificats) :
nano /etc/default/epoptes-client

Décommenter la ligne SERVER et indiquer l'adresse IP du poste maître :

SERVER=IP_POSTE_MAITRE                         # Spécifier l'adresse IP du poste maître d'epoptes (IP du serveur LTSP ici)
  • Récupérer le certificat du poste maître :
epoptes-client -c
  • Sortir du chroot :
exit
  • Démarrer puis se connecter sur un fat client , une miniature de ce fat client doit apparaître dans epoptes.

Installer epoptes maître sur un poste différent du serveur LTSP

Il est possible d'installer l'application maître sur un poste différent du serveur LTSP.

  • Choisir le poste Linux Wheezy (non léger) du réseau pédagogique qui sera le poste maître.
  • Ouvrir un terminal sur ce poste, puis saisir en tant que root :
apt-get update
apt-get install epoptes
  • Ajouter les utilisateurs autorisés à utiliser l'application maître d'epoptes. Par exemple :
gpasswd -a enseignant epoptes
  • Installer epoptes-client sur le serveur LTSP afin de pouvoir visionner les clients légers (hors fat client). Ouvrir un terminal sur le serveur LTSP, puis saisir en tant que root :
apt-get install epoptes-client
  • Renseigner l'adresse IP du poste maître. Pour cela, sur le serveur LTSP, saisir :
nano /etc/default/epoptes-client

Décommenter la ligne SERVER et indiquer l'adresse IP du poste maître :

SERVER=IP_POSTE_MAITRE                         # Spécifier l'adresse IP du poste maître.
  • Récupérer le certificat du poste maître. Sur le serveur LTSP, saisir :
epoptes-client -c

Tester epoptes sur un poste maître différent du serveur LTSP

  • Lancer epoptes sur le poste maître.
  • Se connecter sur un (ou des) clients légers.
  • Sur l'application maître, des miniatures des postes des clients légers doivent apparaître :

Illustration

Proposer aux clients légers une distribution différente de celle du serveur LTSP

Proposer un environnement Debian Jessie

Dans cet article, le serveur LTSP est sous Debian Wheezy mais il est possible de construire et de proposer aux clients légers des environnements différents comme celui de Debian Jessie.

Pour cela, sur le serveur LTSP, en tant que root, saisir :

ltsp-build-client --arch i386 --chroot lxde --fat-client-desktop lxde --dist jessie --mirror http://ftp.fr.debian.org/debian/ --prompt-rootpass

Cette commande va construire sur le serveur LTSP un environnement pour i386 avec la distribution Jessie et le bureau lxde installé. Vous pouvez installé d'autres environnements comme xfce4 ou gnome : pour ce dernier, la construction de l'environnement sera plus longue (compter une heure) et les fats clients devront disposer d'assez de mémoire vive pour fonctionner convenablement (2 à 4 Go de ram ?).

Dans la version Jessie de LTSP, il semble que le fichier "default" du boot PXE a été renommé en "ltsp". Pour être compatible avec la version Wheezy installé sur le serveur LTSP, il faut le renommer en default. Pour cela, sur le serveur LTSP, saisir en tant que root :

cp /srv/tftp/ltsp/lxde/pxelinux.cfg/ltsp /srv/tftp/ltsp/lxde/pxelinux.cfg/default

Démarrer un client léger (configuré au préalable dans le DHCP pour recevoir cet environnement lxde ...) puis se connecter sur ce client léger : le bureau lxde de Jessie devrait apparaître.
Remarque :

L'utilisation d'un environnement avec une distribution différente de celle du serveur LTSP est surtout "visible" pour les fat clients : pour les clients légers (ou hybrides), la session X étant lancée sur le serveur LTSP, ces derniers gardent le même bureau que celui du serveur LTSP ...

Proposer un environnement Ubuntu

Ubuntu Precise

Les distributions Ubuntu et Debian étant très proches, il est possible sur un serveur LTSP sous Debian Wheezy, de construire un environnement Ubuntu pour les fat clients.
Par exemple, pour obtenir Ubuntu avec l'environnement lxde (équivalent à une Lubuntu), saisir sur le serveur LTSP, en tant que root :

VENDOR=Ubuntu CONFIG_NBD=true ltsp-build-client --arch i386 --dist precise --chroot precise --fat-client-desktop lxde --mirror http://fr.archive.ubuntu.com/ubuntu/

Sous Ubuntu, on utilise NBD à la place de NFS, et sous Precise, pour que le boot du client léger fonctionne, il faut modifier le fichier default du boot pxe :

nano /srv/tftp/ltsp/precise/pxelinux.cfg/default

Ajouter à la fin de la ligne, l'option nbdroot qui précise le chemin de l'environnement precise sur le serveur LTSP

nbdroot=/opt/ltsp/precise

Démarrer (ou redémarrer) le serveur NBD :

service nbd-server restart

Ubuntu Trusty

L'ensemble des environnements constructibles se situe sur le serveur LTSP à :

cd /usr/share/debootstrap/scripts

On remarque que le script pour Trusty n'est pas présent sur Debian Wheezy. Par contre, sur Debian Jessie, le script Trusty existe et on peut remarquer que c'est un lien symbolique vers le script gutsy. En testant ce script, on constate qu'il est fonctionnel sur LTSP Wheezy et construit également un environnement Ubuntu Trusty :

ln -s gutsy trusty

On peut ensuite construire un environnement Ubuntu Trusty avec le bureau Unity en saisissant :

VENDOR=Ubuntu CONFIG_NBD=true ltsp-build-client --arch i386 --dist trusty --chroot trusty --fat-client-desktop ubuntu-desktop --mirror http://fr.archive.ubuntu.com/ubuntu/

Comme pour Debian Jessie, il faut renommer en default le fichier du boot pxe :

cp /srv/tftp/ltsp/trusty/pxelinux.cfg/ltsp /srv/tftp/ltsp/trusty/pxelinux.cfg/default

Démarrer (ou redémarrer) le serveur NBD :

service nbd-server restart

Remarque :

Avec le serveur NBD (à la place de NFS), à chaque modification de l'environnement du client léger (chroot dans l'environnement ou modification du fichier lts.conf ...), il faut reconstruire une image compressée et redémarrer le serveur nbd pour que les modifications soient effectives :

ltsp-update-image $CHROOT    # $CHROOT désigne le nom de l'environnement Ubuntu

Démarrer un PC en mode client léger depuis le menu PXE du SE3

Dans ce paragraphe, on suppose qu'un serveur LTSP a été installé dans l'architecture A et que son adresse IP est 172.20.1.20 et qu'un environnement fatclient (par exemple ...) a été installé et configuré sur ce serveur LTSP.

Jusqu'à présent, pour qu'un client léger puisse démarrer dans l'architecture A, il fallait au préalable l'avoir renseigné dans le dhcp du se3. Il est possible de modifier le menu de démarrage PXE du serveur SE3 afin d'ajouter une entrée qui va permettre de démarrer un PC (ayant une carte éthernet PXE) sur le réseau, avec l'environnement fatclient du serveur LTSP.

Cela peut permettre, par exemple :

- d'utiliser très facilement des PC sans avoir besoin de les configurer, dans le cadre d'un forum, d'une exposition...

- de promouvoir l'usage du libre au sein de l'établissement : il sera possible de faire essayer une distribution Debian aux collègues, sans toucher à la configuration de leur PC (portable) personnel, afin de leur faire découvrir Debian et pourquoi pas, si leur matériel est compatible, leur faire une installation sur leur disque dur à l'aide du modult tftp du se3.

Pour cela, ajouter une entrée au menu de démarrage pxe du se3. Saisir en tant que root, sur le serveur se3 :

nano /tftpboot/pxelinux.cfg/default

Puis, ajouter, après le menu "maintenance", les lignes suivantes :

LABEL LTSP
	MENU LABEL ^Demarrer le pc en client leger
	MENU PASSWD enseignant
	KERNEL tftp://172.20.1.20/ltsp/fatclient/vmlinuz-3.2.0-4-486
	APPEND ro initrd=tftp://172.20.1.20/ltsp/fatclient/initrd.img-3.2.0-4-486 init=/sbin/init-ltsp quiet ip=dhcp boot=nfs nfsroot=172.20.1.20:/opt/ltsp/fatclient
	IPAPPEND 2

Remarques:

  • Les paramètres de boot sont ceux par défaut du serveur TFTP du serveur LTSP : il a simplement été rajouté l'adresse IP du serveur LTSP (serveur d'environnement) afin que le client aille cherché le noyau linux, l'initramdisk et son environnement au "bon endroit", c'est à dire sur le serveur LTSP.
  • Un mot de passe a été rajouté (ici, enseignant) afin que limiter l'accès à ce mode de démarrage.
  • L'ajout de ce menu "n'alourdit pas" le serveur SE3 : tous les services (TFTP, NFS, LDM et SSH) restent à la charge du serveur LTSP.


Tester ce nouveau menu :

  • Démarrer en PXE un PC.
  • Sélectionner le menu "Demarrer le pc en client leger" puis saisir le mot de passe d'accès à ce menu.
  • S'identifier sur le client léger (avec un compte de l'annuaire ldap du se3, si votre serveur LTSP a été configuré pour ...).
  • Devrait apparaître un bureau identique à celui de l’environnement fatclient que vous avez installé et configuré sur votre serveur LTSP.

Menu pxe ltsp.png

Un exemple d'utilisation de LTSP pour mettre en place des kiosques Web

Dans ce paragraphe, on se place dans la cadre de l'architecture A et les clients légers sont des Raspberry Pi Model B (512 Mo de Ram).

  • Installer un navigateur web sur votre serveur LTSP :

Avec la solution Berryterminale, nous avons des problèmes de détection du clavier avec Iceweasel (le clavier est en querty) alors qu'il est en azerty pour les autres applications ... (problème que nous n'avons pas avec des clients légers "classiques" qui ont un boot PXE et utilisent donc la racine /opt/ltsp/i386 du serveur). Nous avons finalement renoncé à Iceweasel pour Chromium :

apt-get install chromium chromium-l10n

Si vous êtes derrière un pare-feu AMON, vous risquez d'avoir des problèmes d'accès au site en https. Contrairement à Iceweasel, les paramètres proxy pour Chromium doivent se configurer au niveau système. On peut les régler dans le fichier /etc/environment (le fichier /etc/profile ne semble pas exécuté à l'ouverture de session de ssh) qui est exporté par le module pam_env au moment de l'identification du client léger :

nano /etc/environment
http_proxy="http://172.20.1.1:3128"        # Indiquer l'adresse IP et le port de votre proxy, si ce dernier n'est pas configurer en proxy transparent
https_proxy="http://172.20.1.1:3128"       # Indiquer l'adresse IP et le port de votre proxy, si ce dernier n'est pas configurer en proxy transparent

Pour installer le plugin Flash Player pour Chromium : Editer la liste de vos dépots :

nano /etc/apt/sources.list

Ajouter le dépot backports :

deb http://ftp.fr.debian.org/debian wheezy-backports main contrib non-free

Télécharger le plugin Flash Player pour chromium :

apt-get update
apt-get install -t wheezy-backports pepperflashplugin-nonfree
  • Sur le serveur LTSP, créer un compte local pour le kiosk1. Pour cela, ouvrir une console et en tant que root :
adduser kiosk1

Définir en particulier un mot de passe pour ce kiosque (mpd_kiosk1 dans cet article).

  • Se connecter sur le serveur LTSP avec le compte kiosk1 puis paramétrer chromium (désactiver la mémorisation des mots de passe par exemple ...)
  • Sur le serveur LTSP, configurer l'utilisateur kiosk1 afin que seul le navigateur chromium se lance à l'ouverture de session :

- Ouvrir un terminal et se connecter en tant que kiosk1 puis saisir :

nano /home/kiosk1/.xsession                    # Utiliser par X à l'ouverture de session pour lancer les applications clientes.
xset s off            # Pour éviter que l'écran ne s'éteigne au bout d'un temps
xset -dpms
xfwm4 &               # Gestionnaire de fenêtre de xfce4
while true; do        # pour que le navigateur se relance automatiquement à la fermeture de la fenêtre
     chromium --start-maximized --app=http://site_a_ouvrir     # Pour ouvrir en plein écran chromium sur le site web disponible au kiosque
done

Solution alternative :
On peut aussi utiliser plus simplement le mode kiosque de Chromium :

xset s off            # Pour éviter que l'écran ne s'éteigne au bout d'un temps
xset -dpms
chromium --start-maximized --kiosk "http://site_a_ouvrir"    # Pour ouvrir en plein écran chromium en mode kiosque

- Rendre le fichier exécutable :

chmod u+x /home/kiosk1/.xsession              

Remarque :

La présence d'un fichier .xsession dans le home directory d'un utilisateur permet de passer outre l'ouverture "normale" d'une session X par le système.

  • Installer Berryboot puis Berryterminal sur un raspberry.
  • Depuis le menu multi-boot de Berryboot (ou dans le fichier cmdline.txt de la carte SD du Raspberry), paramétrer le client léger Rapsberry en autologin :
XKBLAYOUT=fr LDM_LANGUAGE=fr_FR.UTF-8 LDM_AUTOLOGIN=true LDM_USERNAME=kiosk1 LDM_PASSWORD=mdp_kiosk1
  • Booter votre raspberry : la session s'ouvre automatiquement sur votre page Web. Fermer votre page Web, elle se réouvre automatiquement.
  • Répéter l'opération pour chaque kiosque web.

Procédure d'installation d'un serveur LTSP (Architecture B)

On suppose que le serveur LTSP a deux cartes réseaux, une notée eth0 qui sera configurée en client DHCP du réseau du SE3 et l'autre notée eth1 sur le sous-réseau de clients légers.
Dans ce paragraphe, on ne reprend pas tout : il est conseillé d'avoir lu les paragraphes précédents (8, 9, 12 et 13 en particulier).

Installation du serveur LTSP

  • Déconnecter le cable RJ45 de la carte du sous-réseau (eth1) (est-ce utile ?)
  • Sinon, la procédure est quasiment identique à celle du paragraphe 8 et 9 [architecture A] : installer le meta-paquet ltsp-server-standalone qui contient en plus un serveur DHCP :
apt-get update
apt-get install ltsp-server-standalone       # Méta-paquet contenant un serveur DHCP pour le sous-réseau de clients légers

Configuration des interfaces réseaux

  • Rebrancher le cable RJ45 de votre carte eth1.
  • Durant l'installation du paragraphe précédente, la carte eth0 a du être automatiquement configurée en client dhcp du se3. Reste à donner une IP statique à la carte eth1 du sous-réseau de clients légers. Pour cela, éditer le fichier interfaces :
nano /etc/network/interfaces

Adapter les lignes suivantes à votre réseau :

auto eth0
iface eth0 inet dhcp                  

auto eth1
iface eth1 inet static
address 192.168.67.1                 
netmask 255.255.255.0
  • Redémarrer le service réseau :
service networking restart

Configuration des interfaces réseaux pour des fats clients

La configuration précédente est suffisante si vous utilisez des clients légers avec un environnement léger (ou hybride) car la session X est lancée sur le serveur LTSP et que ce dernier a accès au réseau pédagogique. Les fat clients ne pourront par contre pas "sortir" de leur sous-réseau (pour naviguer sur Internet par exemple) ; une solution simple consiste à configurer le serveur LTSP en routeur NAT. Pour cela :

  • Activer le mode routeur (ipforwarding)
nano /etc/sysctl.conf

Puis décommenter la ligne suivante :

net.ipv4.ip_forward=1

Activer l'ipforwarding :

sysctl -p /etc/sysctl.conf
  • Création de l'iptable pour configurer le serveur LTSP en serveur NAT puis sauvegarde de cet iptable.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables-save > /etc/iptables_ltsp
  • Restaurer l'iptable au démarrage de l'interface eth1. Pour cela :
nano /etc/network/interfaces

Ajouter la ligne "post-up" :

auto eth1
iface eth1 inet static
address 192.168.67.1
netmask 255.255.255.0
post-up iptables-restore < /etc/iptables_ltsp

Redémarrer le service network :

service networking restart

Configurer le serveur DHCP du sous-réseau de clients légers

  • Indiquer quelle carte réseau le serveur DHCP doit servir :
nano /etc/default/isc-dhcp-server

Ajouter l'interface à servir :

INTERFACES="eth1"
  • Faire une sauvegarde de la configuration par défaut avant sa modification :
mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.save
  • Adapter le modèle de fichier DHCP fourni par LTSP :
cp /etc/ltsp/dhcpd.conf /etc/dhcp/dhcpd.conf
nano /etc/dhcp/dhcpd.conf

Les paramètres importants sont l'adresse IP du serveur DNS et celle du routeur :

#
# Default LTSP dhcpd.conf config file.
#

authoritative;                                     

subnet 192.168.67.0 netmask 255.255.255.0 {
    range 192.168.67.20 192.168.67.250;            # Plage d'adresse desservie par le serveur DHCP du serveur LTSP
    option domain-name "demo.ac-versailles.fr";    # nom DNS du réseau pédagique
    option domain-name-servers 172.20.1.1;         # adresse IP du serveur DNS (adresse IP de Amon)
    option broadcast-address 192.168.67.255;
    option routers 192.168.67.1;                   # adresse du routeur (serveur LTSP)
    next-server 192.168.67.1;                      # adresse du serveur TFTP (serveur LTSP)
#    get-lease-hostnames true;
    option subnet-mask 255.255.255.0;
    option root-path "/opt/ltsp/i386";             # Chemin de l'environnement des CL sur le serveur LTSP

    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/i386/pxelinux.0";          # Chemin du chargeur d'amorçage réseau PXE sur le serveur LTSP
    } else {
        filename "/ltsp/i386/nbi.img";             # Charger d'amorçage Etherboot
    }
}
  • Redémarrer le service dhcp :
service isc-dhcp-server restart

Remarque :

Dans l'architecture B, il n'est pas nécessaire de spécifier, pour chaque client léger, son adresse MAC et IP car le serveur DHCP du serveur LTSP peut lui attribuer une adresse IP dans la plage 192.168.67.20 / 192.168.67.250 (sur l'exemple ci-dessus).

Tester l'installation d'un serveur LTSP [architecture B]

  • Démarrer en boot PXE un des clients légers connecté au sous-réseau de clients légers.
  • Une fenêtre de connexion apparaît sur l'écran du client léger : entrer l'identifiant et le mot de passe d'un compte.
  • Vérifier que la navigation Internet fonctionne (en particulier pour les fat client).

Mise en place d'un cluster de serveurs LTSP

dans l'architecture A

Dans l'architecture A, il est possible de séparer le serveur d'environnement (TFTP + NFS) du serveur d'applications (LDM-server + SSH) et de configurer le serveur d'environnement afin de réaliser un "load balancing" (répartition de charges) entre les différents serveurs d'applications.

Remarque :

L'installation de serveur(s) d'applications n'a de sens que si le serveur d'environnement contient un environnement léger (ou hybrid). Si vous souhaitez configurer vos clients en fat client, seul un (ou plusieurs) serveur(s) d'environnement sont utiles et nécessaires.

Installation des serveurs d'applications

Un serveur d'application réalise l'identification de l'utilisateur qui se connecte au client léger et se charge de lancer les applications sur le serveur LTSP et du déport d'affichage (si le client léger n'est pas un fat client).

  • Après avoir réservée l'adresse ip du serveur d'applications et installé un client Linux via l'interface web se3, saisir dans un terminal en tant que root :
apt-get update
apt-get install ldm-server
  • Répéter la procédure pour chaque serveur d'applications souhaité. Dans la suite, on suppose installé deux serveurs d'applications :

- 172.20.1.21 ayant pour nom d'hôte ltspappli01

- 172.20.1.22 ayant pour nom d'hôte ltspappli02

Installation du serveur d'environnement

Le serveur d'environnement se charge de distribuer l'environnement (léger, hybrid ou fat) aux clients légers (via TFTP + NFS) et contient le fichier de configuration des clients légers (lts.conf).

  • Après avoir réservée l'adresse ip du serveur d'environnement et installé un client Linux via l'interface web , saisir dans un terminal en tant que root :
apt-get update
apt-get install ltsp-server
  • Se reporter ensuite aux paragraphes 9 et 10 pour la construction du (ou des) environnements et la configuration du serveur dhcp du se3.
  • Un client léger ne pourra s'identifier sur un serveur d'applications que s'il possède dans son environnement la clé publique de ce serveur d'applications. Pour récupérer les clés publiques des serveurs d'applications, saisir sur le serveur d'environnement en tant que root :
ltsp-update-sshkeys 172.20.1.21 172.20.1.22     # Récupére la clé publique des deux serveurs d'application ltspappli01 et ltspappli02 et les sauvegarde dans /etc/ltsp/ssh_known_hosts.auto 
ltsp-update-sshkeys                             # Mise à jour des clés publiques dans l'environnement des clients légers.
  • Dans le fichier lts.conf, spécifier, selon l'adresse MAC du client léger, le serveur d'application qu'il doit consulter :
[00:01:GE:AE:45:31]                    # Adresse mac du client léger devant se connecter par défaut à ltspappli01
LDM_SERVER="172.20.1.21 172.20.1.22"   # Liste des serveurs d'applications accessibles depuis la fenêtre de login d'un client léger (le 1er serveur de la liste étant celui par défaut)

[00:02:AB:13:87:R4]                    # Adresse mac du client léger devant se connecter par défaut à ltspappli02
LDM_SERVER="172.20.1.22 172.20.1.21"
  • Mise en place d'un répartiteur de charge (load balancing) entre les serveurs d'applications :

Pour éviter d'avoir à renseigner pour chaque client léger la liste de serveurs d'applications disponibles, il est possible de réaliser un répartiteur de charge entre les différents serveurs d'applications.

Pour cela, dans le fichier lts.conf du serveur d'environnement, commenter le paramètre LDM_SERVER puis spécifier la liste des serveurs d'applications dans la variable MY_SERVER_LIST :

MY_SERVER_LIST="172.20.1.21 172.20.1.22"           # Liste des serveurs d'applications du réseau [Architecture A]

On peut alors créer un script dans l'environnement du client léger (script exécuté par son LDM à l'ouverture de session). Ce script peut-être basé sur le "hasard" (choisir "au hasard" un des serveurs d'applications) ou sur le "taux de charge" des serveurs d'applications (choisir le serveur d'applications qui a le plus faible "taux de charge").

Dans le manuel de référence de l'administrateur LTSP est proposé un script basé sur le hasard, ce dernier peut être adapté pour se baser sur le "taux de charge" des serveurs d'applications. Par exemple :

nano /opt/ltsp/i386/usr/share/ltsp/get_hosts        # Attention, dans le manuel de référence LTSP, il y a une erreur sur l'emplacement du script ...
#!/bin/bash
TMP_LIST=""
SHUFFLED_LIST=""

for i in $MY_SERVER_LIST; do
        rank=$(nc $i 9571 | grep rating | cut -d: -f2)              # "Taux de charge" du serveur d'application
        TMP_LIST="$TMP_LIST\n${rank}_$i"                            # "Taux de charge" de l'ensemble des serveurs applications
done

TMP_LIST=$(echo -e $TMP_LIST | sort -r)                             # Plus le taux est elevé moins le serveur est "chargé"
for i in $TMP_LIST; do                                              # On récupère l'adresse IP des serveurs applications du moins chargés au plus chargés
        SHUFFLED_LIST="$SHUFFLED_LIST $(echo $i | cut -d_ -f2)"
done

echo $SHUFFLED_LIST

Mettre le droit d'exécution sur ce script :

chmod u+x /opt/ltsp/i386/usr/share/ltsp/get_hosts 

Tester l'installation d'un cluster de serveurs LTSP [Architecture A]

  • Démarrer le serveur d'environnement et les deux serveurs d'applications.
  • Démarrer et se connecter sur un client léger, noter sur quel serveur d'applications il est connecté, puis lancer une vidéo.
  • Démarrer et se connecteur sur deux ou trois autres clients légers, ces derniers devraient se connecter sur l'autre serveur d'applications.

dans l'architecture B

Les serveurs LTSP avec deux cartes réseaux sont autonomes et gèrent uniquement leur sous-réseau de clients légers : il n'impacte pas le réseau pédagogique et il n'y a rien à faire de particulier pour les mettre en cluster de serveurs LTSP.

Par contre, dans cette architecture, une panne d'un serveur LTSP entraîne "la panne" de tous les clients légers du sous-réseau ... Pour pallier à une telle situation, il est possible de configurer les serveurs LTSP de cette architecture "par pair", en "DHCP failover". Ainsi, si l'un des serveurs LTSP tombe, l'autre peut prendre le relais.

Le DHCP failover permet de faire "cohabiter" deux serveurs DHCP sur le même réseau. Dans le cadre d'un réseau avec deux serveurs DHCP, on peut imaginer la configuration suivante :
DHCP failover

Paramétrage du failover

  • Installer et configurer les deux serveurs de façon identique en suivant la procédure décrite au paragraphe 15 : seule le nom d'hôte et l'adresse IP de la carte du sous-réseau (eth1) doit différer entre les deux serveurs. Dans la suite, on suppose que :

- Le serveur LTSP maitre a pour nom d'hôte ltsp1 et adresse IP dans le sous-réseau 192.168.67.1

- Le serveur LTSP esclave a pour nom d'hôte ltsp2 et adresse IP dans le sous-réseau 192.168.67.2

  • Sur le serveur LTSP maître, définir le failover. Pour cela, en tant que root, saisir :
nano /etc/dhcp/dhcpd.conf
# Default LTSP dhcpd.conf config file.
#

authoritative;

failover peer "ltsp" {                 # Définition du failover
         primary;                      # Ce DHCP est le maître
         address 192.168.67.1;         # IP du serveur LTSP maître
         port 520;     
         peer address 192.168.67.2;    # Adresse de son pair, le serveur LTSP esclave
         peer port 520;
         max-response-delay 60;
         max-unacked-updates 10;
         mclt 3600;
         split 128;                    # Chaque serveur desserve la moitié des requêtes DHCP
         load balance max seconds 3;
       }

subnet 192.168.67.0 netmask 255.255.255.0 {
    pool {                                           # Le failover doit être dans un pool
        failover peer "ltsp";
        range 192.168.67.20 192.168.67.250;          # La plage d'adresses desservie doit être identique à celle du LTSP esclave
        option domain-name "demo.ac-versailles.fr";
        option domain-name-servers 172.20.1.1;       # Adresse IP du serveur DNS (IP du serveur AMON)
        option broadcast-address 192.168.67.255;
        option routers 192.168.67.1;                 # IP du routeur (IP du LTSP maître)
        next-server 192.168.67.1;                    # IP du TFTP (IP du LTSP maître)
#    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";
        }
      }
}

  • Sur le serveur LTSP esclave, définir le failover. Pour cela, en tant que root :
nano /etc/dhcp/dhcpd.conf
#
# Default LTSP dhcpd.conf config file.
#

# authoritative;

failover peer "ltsp" {                     # Définition du failover
        secondary;                         # Ce serveur est le serveur esclave
        address 192.168.67.2;              # IP du serveur LTSP esclave
        port 520;     
        peer address 192.168.67.1;         # IP de son pair, le serveur LTSP maître 
        peer port 520;
        max-response-delay 60;
        max-unacked-updates 10;
        load balance max seconds 3;
}

subnet 192.168.67.0 netmask 255.255.255.0 {
    pool{                                           # Le failover doit être dans un pool
        failover peer "ltsp";
        range 192.168.67.20 192.168.67.250;         # La plage d'adresses desservie doit être identique à celle du LTSP maître
        option domain-name "demo.ac-versailles.fr";
        option domain-name-servers 172.20.1.1;      # Adresse IP du serveur DNS (IP du serveur AMON)
        option broadcast-address 192.168.67.255;
        option routers 192.168.67.2;                # IP du routeur (IP du LTSP esclave)
        next-server 192.168.67.2;                   # IP du TFTP (IP du LTSP esclave)
#    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";
        }
      }
}

Remarque :

Ce failover a été adapté de celui fourni dans :

man dhcpd.conf

Les paramètres sont ceux par défaut.

Tester le failover

  • Démarrer vos deux serveurs LTSP.
  • Démarrer des clients légers.
  • Se connecter sur les clients légers : la moitié des clients légers devraient s'être connectés au LTSP maître et l'autre moitié au LTSP esclave.
  • Éteindre un des deux serveurs LTSP puis redémarrer les clients légers qui étaient connectés à ce serveur LTSP : ils devraient se connecter à l'autre serveur LTSP.
  • Rallumer le serveur LTSP éteint, puis allumer d'autres clients légers : le nombre de baux gérés par chaque serveur LTSP devraient se rééquilibrer.

Remarque :

Il est important que les deux serveurs LTSP soient réglés précisément à la même heure, sinon les deux serveurs DHCP en failover ne parviendront pas à se synchroniser.

Ressources