projet tuteuré - members.loria.fr · transmettre au serveur tftp qui contient les fichiers...
TRANSCRIPT
1
Projet tuteuré
Architecture de terminaux
bureautiques légers
Tuteurs :
Antoine ALLUIN
Mathieu GOULIN
Membres du projet :
Bilal ERTURAN
Quentin LAGAUDE
Gaetan PINARD
Youssef SEDDIKI
3
Table des matières Introduction ............................................................................................................................................. 5
Qu’est-ce que ? … .................................................................................................................................... 7
1) Le boot par réseau ....................................................................................................................... 7
2) Streaming de bureau à distance .................................................................................................. 9
3) Comparaison entre les deux solutions ...................................................................................... 10
Les solutions retenues ........................................................................................................................... 11
1) LTSP (Linux Terminal server Project) ......................................................................................... 11
2) X2Go .......................................................................................................................................... 14
a) NX Server ............................................................................................................................... 14
b) FreeNX ................................................................................................................................... 14
c) X2go, notre choix ................................................................................................................... 15
Mise en place et utilisation des solutions ............................................................................................. 16
1) Le réseau commun .................................................................................................................... 16
2) Mise en place de LTSP ............................................................................................................... 17
3) Mise en place d’x2Go ................................................................................................................ 22
Les tests entre les deux solutions .......................................................................................................... 26
1) Test des performances et du temps de démarrage ...................................................................... 26
a) Boot par le réseau : ............................................................................................................... 26
b) Streaming de bureau distant ................................................................................................. 28
2) Test des performances aux lancements d’applications ................................................................ 28
3) Test de stress ................................................................................................................................. 28
4) Conclusion ..................................................................................................................................... 29
Conclusion ............................................................................................................................................. 30
Glossaire ................................................................................................................................................ 31
Bibliographie.......................................................................................................................................... 34
Annexes ................................................................................................................................................. 36
5
Introduction
Aujourd’hui, de plus en plus d’entreprises se tournent vers des solutions de bureaux légers ou de machines sans disques. Ces solutions procurent aux équipes gérant les parcs informatiques d’une entreprise énormément d’avantages. Dans un premier temps, cela permet de faciliter la maintenance des machines en diffusant plus rapidement des mises à jour et en centralisant les données. Cela permet aussi une réduction des coûts évidents sur le matériel et sur le nombre du personnel affilié au parc informatique. Les plateformes de bureautique légère ce sont énormément développées au point où elles deviennent accessibles au grand public et donc dans le domaine extra-professionnel. Depuis quelques années dans le monde du jeu vidéo, par exemple, se développe des plateformes de jeux vidéo par le streaming plus communément appelé « Cloud Gaming ». Ceci a été rendu possible par l’extension des services de sauvegarde dans le nuage. Il existe deux types d’architectures de terminaux bureautiques légers qui ont tous eux leurs avantages et leurs inconvénients. Lors de ce projet tuteuré, nous allons mettre les deux en place afin de pouvoir comprendre leur fonctionnement, apprendre à les mettre correctement en place et les comparer :
• La première architecture est le boot par réseaux qui est composé d’un serveur central ainsi que des clients qui boot par le réseau afin de récupérer le système à partir de la machine centrale.
• La seconde sera aussi composée d’un serveur central et des clients qui seront capables de streamer un bureau à distance.
La licence professionnelle va faire de nous des administrateurs systèmes et réseaux dans lesquels nous serons sûrement amenés à déployer ou administrer ce type d’architecture. C’est dans cette optique que ce sujet nous a été donné.
7
Qu’est-ce que ? …
1) Le boot par réseau
Le boot par réseau permet le démarrage d’un ordinateur, non grâce à son disque dur,
mais par le biais le réseau. On utilise le boot par réseau pour installer des systèmes
exploitations ou bien pour utiliser des clients légers. Lorsqu’un client léger lance une
application, par exemple Libre Office, Firefox, cette application sera chargée par le réseau
(NFS) dans la RAM du client puis exécutée par son processeur.
Ainsi, le serveur LTSP est seulement utilisé pour identifier l’utilisateur et mettre à la disposition
des clients son environnement.
Pour réaliser un démarrage par le réseau, il faut avoir 3 serveurs :
• DHCP : Dynamic Host Configuration Protocol, serveur fournissant aux clients
ainsi qu’au serveur TFTP une adresse IP.
• TFTP : Trivial File Transfer Protocol, serveur fournissant les fichiers permettant
au client léger de démarrer.
• NFS : (Network File System), serveur permettant de monter le disque réseau
sur le client léger.
Très utile en entreprise, mais non obligatoire pour faire fonctionner la solution, un serveur
LDAP (Lightweight Directory Access Protocol) qui permet la centralisation des
authentifications.
Sur la machine cliente, il est nécessaire que le démarrage par le réseau soit activé dans le bios.
Avant que l’utilisateur puisse utiliser son ordinateur, plusieurs échanges entre le client et le
serveur se réalisent avant de démarrer. Afin d’illustrer ces échanges et de mieux comprendre
le mécanisme du boot par réseau, nous avons fait un schéma explicatif.
8
Explication du schéma :
L’utilisateur va mettre sous tension son poste. L’ordinateur qui a été configuré pour
démarrer sur le réseau va envoyer une requête au serveur DHCP pour lui demander une
adresse IP. Ce dernier qui reçoit la requête va lui attribuer une adresse IP en réponse et la
transmettre au serveur TFTP qui contient les fichiers nécessaires au démarrage du client. Le
TFTP va transmettre le chargeur de démarrage, tel que le Grub et le PXELinux de syslinux.
Le client va ensuite demander le noyau du système d’exploitation. Le TFTP va donc lui envoyer
une image minimale qui sera chargée dans la RAM du client, transformée pour l’occasion en
espace disque. Une fois chargé, il sera capable de monter son disque réseau puis de terminer
son démarrage comme un ordinateur ayant un système d’exploitation installée sur le disque
dur.
Dans le cadre du boot par réseau, les ressources utilisées pour effectuer les tâches demandées
par l’utilisateur sont celles du client léger et non celles du serveur. Ainsi, lorsque l’on veut
lancer une application, celle-ci sera chargée via le réseau, à partir du serveur NFS, puis les
ressources de la mémoire vive et du processeur de la machine cliente seront exploitées de la
même façon qu’un ordinateur standard. C’est pour cela que les clients légers destinés à
démarrer par le réseau doivent être plus performants qu’un poste standard.
Il existe différents produits sur le marché qui permettent de réaliser ce type d’architecture de
terminaux bureautiques légers tels que Windows TSE, LTSP, Thinstation.
9
2) Streaming de bureau à distance
Le streaming par le réseau est une méthode de clients légers. Il permet aux clients de se connecter à une machine distante, de voir cette machine et d’y travailler dessus. Le streaming de bureau à distance permet la connexion à différents comptes d’utilisateurs, donc, chaque personne aura son propre écran. Étant donné que c’est du streaming, la seule ressource utilisée par la machine cliente est la connexion internet qui doit être de bonne qualité, il est souvent recommandé d’avoir une connexion avec un temps de réponse inférieur à 100ms pour avoir une utilisation correcte. Depuis quelques années, les solutions de streaming sont de plus en plus utilisées. Ce service existait déjà pour retransmettre des événements en direct avec Twitch par exemple, aujourd’hui, son utilisation s’élargit pour être utilisée dans des situations différentes telles que pour jouer avec, par exemple, le boîtier de streaming de mise en place par Shadow. Le bureau à distance existe déjà pour envoyer le flux de la machine et de pouvoir la contrôler à distance à des fins extra-professionnelles. Il en existe trois populaire qui sont TeamViewer qui est très utilisé par les techniciens informatiques pour particulier afin de résoudre des problèmes mineurs, bureau à distance par Google chrome et le bureau à distance de Microsoft. Aujourd’hui, la méthode du streaming de bureau est utilisée en entreprise dans le but de réduire le matériel au niveau du client. Cette réduction permet la réduction de travail pour un technicien informatique qui n’aura plus à régler le problème de chaque machine séparément, mais permet aussi de réduire les coûts en matériel. En effet, la machine client pourra se contenter d’être une Raspberry ou un matériel équivalent sachant que le coût d’une Raspberry est de 40€.
10
3) Comparaison entre les deux solutions
Le boot par réseau et le streaming de bureau sont deux fonctionnements différents. L'un est
un client lourd ou FatClient et l'autre un client léger. Bien que ces deux solutions soient
différentes, le résultat sera transparent pour l'utilisateur final, tout se passe sur le serveur.
Dans une infrastructure avec boot par réseau, le client léger se verra obtenir une image qui
sera créée précédemment sur le serveur (ici serveur LTSP) le client recevra donc cette image
grâce au serveur TFTP. Lors du lancement des applications, c'est uniquement le client léger qui
va lancer les applications et utiliser son processeur et sa mémoire RAM. Le disque dur n'est
pas utile. La bande passante sera utilisée pour transférer l'image ce qui peut rendre le
lancement d'une application plus longue qu'un environnement léger.
Dans une infrastructure avec streaming de bureau, comme son nom l'indique le client aura un
flux vidéo du serveur c'est-à-dire qu'une image du serveur sera déportée, ce qui veut dire que
toutes les applications seront installées sur le serveur et qu’elles seront exécutées dessus. Le
client léger n'aura donc aucune ressource utilisée et la bande passante sera continuellement
utilisée.
Un client lourd devra donc utiliser plus de ressources qu'un client léger (128 Mo pour la
mémoire vive et 533 MHz pour le processeur suffisent amplement pour un client léger), ce qui
veut dire qu'ils seront plus coûteux.
11
Les solutions retenues
1) LTSP (Linux Terminal server Project)
LTSP et ThinStation sont deux solutions qui permettent d'utiliser une station de travail
sans disque.
LTSP ThinStation
Boot par réseau
Station de travail sans disque
Streaming de bureau
Compatible Linux
Compatible Windows
Multi OS
NBD
Dernière version LTSP 5 (2013) 5.5 (Juin 2016)
Documentation Très bien documenté. - Wiki - Tutoriels - Forum
Peu documenté. - Quelques tutoriels
Les avantages de LTSP sont :
- Tout d'abord d'avoir plusieurs environnements pour des clients légers spécifiques et deuxièmement le matériel est reconnu comme une distribution installée localement, mais le point négatif est qu'il ne faut aucun problème réseau sinon le client se fige, car il n'a plus accès à son filesystem qui est partagé par NFS.
- ThinStation quant à lui utilise un OS spécialement conçu pour du client léger. C'est une distribution basée sous Linux. ThinStation permet d’utiliser des applications préinstallées, il suffit de choisir lesquelles nous voulons installer. Il est possible d’installer des logiciels Windows.
12
- Le point fort de cette solution est que le système du client léger est stable, car tout le système ainsi que le filesystem tournent dans la RAM. Une coupure du réseau n'aura donc aucun impact.
LTSP est une abréviation de Linux Terminal Server Project. C’est un regroupement de logiciels
permettant de connecter des stations de travail légères, appelées plus simplement des clients
légers, sur le serveur LTSP.
Le projet a vu le jour en 1999, grâce à Jim McQuillan qui est encore aujourd’hui le chef du
projet. Cette solution est distribuée sous la licence GNU GPLv2. Aujourd’hui, le projet est
toujours maintenu et actif dont la dernière version stable est LTSP 5. C’est une alternative
open source à la solution propriétaire de Windows qui est Windows TSE (Terminal Server)
Nous avons choisi cette solution par rapport à plusieurs critères. Tout d’abord, c’est une
solution open source sous licence GPLv2. Elle répond à nos besoins qui sont d’avoir des clients
légers sous Linux, s’il fallait avoir des logiciels Windows par exemple, on aurait alors privilégié
la solution ThinStation, mais ce n’est pas le cas. La mise en place de LTSP ainsi que
l’administration du serveur et des clients légers, est simple et efficace.
LTSP est une solution qui s’installe sur de nombreuses distributions Linux : Debian, Ubuntu,
Fedora, Gentoo, OpenSuse. LTSP est aussi intégrée dans certaines distributions spécialisées,
tel que Edubuntu, Skolelinux (debian) qui sont destinées au monde de l’éducation. Mais il est
préférable de choisir Ubuntu ou Debian pour utiliser toutes les fonctionnalités de la solution.
Par ailleurs, plus de 80% des serveurs LTSP tournent sur la distribution Ubuntu. C’est
notamment pour cette raison que l’on a choisi cette distribution pour le projet.
LTSP est par ailleurs très intéressant, car il est possible d'utiliser différents types
d’environnement pour les clients légers :
• Le premier est l’environnement léger : le client léger va lancer une session X sur
le serveur LTSP et toutes les applications seront exécutées sur ce dernier. Ainsi,
les ressources utilisées sont ceux du serveur et non ceux qui appartiennent au
client léger. L’écran est donc déporté sur le client et se comporte comme un
terminal X ce qui permet au client avoir besoin de très peu de ressources (environ
128 / 256 Mo de RAM). Cette solution peut être appelée streaming de bureau.
13
• Le deuxième est l’environnement hybride : il s’agit également d’un
environnement léger, mais les applications peuvent soit être exécutées avec les
ressources du serveur ou bien avec les ressources du client léger. La conséquence
est que nos postes clients doivent contenir plus de mémoire RAM qu’un client
léger classique. Cet environnement est donc un mixte entre un environnement
léger et un environnement lourd.
• Et le dernier environnement est l’environnement lourd (dit Fat-Client) : toutes les
applications sont exécutées uniquement avec les ressources du poste léger. La
conséquence est que le serveur LTSP est utilisé uniquement pour l’identification
des utilisateurs et la mise à disposition du client un environnement. Le serveur est
donc allégé d’une grosse partie du travail, mais les postes utilisateurs doivent plus
performant que ceux qui destinée au 1er environnement. Cette solution est
destinée à réaliser du Boot par réseau, c’est pour cela que nous utilisons cet
environnement.
Remarque : il est possible de faire cohabiter les types environnement sur le
même serveur.
• Précédemment, nous avons parlé des environnements, mais à quoi peuvent-ils
servir ?
Cet environnement est une version minimaliste de GNU/Linux (par exemple,
Ubuntu) qui sera démarré sur le réseau par le client léger, car généralement il ne
dispose pas de disque dur. Cet environnement est généralement hébergé sur le
serveur lui-même. Ainsi, cette installation est un environnement chroot. L’intérêt
est de pouvoir disposer de plusieurs environnements en fonction de nos besoins
(par exemple à cause des différentes architectures CPU des postes utilisés, besoin
de posséder plusieurs systèmes d’exploitation).
Attention, il existe une petite différence avec les environnements Fat-client : le
chroot n’est pas qu’une version minimale d’un OS Linux, mais une version
complète d’un OS.
14
2) X2Go
Aujourd’hui, les méthodes d’affichage d’écran distant par le streaming se sont développées. Il existe plusieurs types de solutions de streaming de bureau distant. En prenant en compte seulement les logiciels libres, il y a des logiciels qui permettent seulement de répliquer une session sur une machine distante comme : VNC, Remmina, Terminal Server Client, Gitso, Vino, x11vnc, etc. Cependant, ce que nous voulons c’est de pouvoir ouvrir une session indépendante, c’est-à-dire de pouvoir se connecter via le serveur à notre session à partir d’une machine cliente. Ainsi, chaque machine cliente pourra se connecter indépendamment au serveur dans leur propre session sans avoir un système d’exploitation installé sur celles-ci. Les logiciels qui permettent ceci sont des Nos recherches se sont donc centrées sur les streamings de sessions indépendantes. Dans ces recherches, nous avons relevé trois logiciels qui correspondaient à nos besoins : NxServer, x2Go et FreeNx.
a) NX Server
Pour mettre en place ce
système, il faut installer NxServer sur
la machine hôte qui aura le rôle du
serveur et NxClient sur les machines
clientes qui se connectent au serveur.
Il supporte la transmission audio et
permet la reprise d’une session ; par
contre, source fermée et avec ce
système, on est limité à seulement 2
connexions simultanées.
b) FreeNX
C’est l'équivalent gratuit de NX Server, en s’appuyant sur le protocole NX. Il permet de
faire la même chose. De plus, il est open source et n’a pas de limites du nombre
de connexions en simultanés. Cependant, il ne permet pas la transmission
audio et la connexion à une session locale déjà active.
15
c) X2go, notre choix
Ce logiciel s'appuie sur le projet FreeNX. Il est performant et
permet une navigation fluide avec une connexion bas débit. Fondé
par Oleksandr Shneyder et Heinz-M. Graesing en 2013, cette
solution est disponible pour toutes les distributions ainsi que toutes
les architectures. Il n’est pas possible d’installer le serveur x2Go sur une machine Windows ou
Mac. En revanche, le client fonctionne sur les trois systèmes d’exploitation principaux. X2Go
est un logiciel de stream par le réseau, il utilise donc des clients légers. Il utilise la carte vidéo
et audio de la machine cliente et la connexion est sécurisée par le protocole SSH. La mise en
place se fait à peu près de la même manière, il faudra installer des paquets pour le serveur et
pour les clients.
Nous avons choisi de mettre en place cette solution dans le cadre du projet, car il répond
parfaitement à nos besoins. De plus, x2go intègre l’authentification LDAP. NX Server n’étant
pas open source, on ne peut l’utiliser.
X2Go NxServer FreeNx
Open Source Oui Non Oui
OS pris en charge Linux Toutes plateformes Toutes plateformes
Développement En cours En cours Fin : 2013
Client au démarrage Oui Oui Oui
En comparant les trois solutions avec un tableau on se rend rapidement compte qu’x2Go est la solution adéquate afin de bien mener notre projet. Dans le cas où Nx Server serait open source, il aurait pu répondre à nos besoins. On a pu voir qu’il y a des problèmes récurrents avec FreeNX. Celui-ci ne supporte pas la transmission audio, par exemple, et son développement n’est plus actif. Nous avons donc préféré partir sur un logiciel toujours suivi et documenté pour nous faciliter sa compréhension et son installation de plus au niveau de la sécurité, un logiciel mis à jour régulièrement est toujours mieux.
16
Mise en place et utilisation des solutions
1) Le réseau commun
Pour réaliser ce projet, nous avons créé deux maquettes séparément, l’une destinée
au boot par réseau et l’autre au streaming de bureau. Voici les plans réseau de nos deux
maquettes :
Les deux réseaux sont identiques et possèdent une configuration similaire, car nous les avons
réalisés sur une maquette que l’on a ensuite clonée sur le deuxième serveur, afin de gagner
du temps. Cela permet qu’elles soient identiques permettant à tous les membres du projet
d’intervenir dessus et aussi d’effectuer des tests disposant des mêmes ressources. Cela nous
assure la récupération de données les plus justes possible.
Les deux maquettes ont été virtualisées sur deux serveurs. Sur lesquels a été installé
l’hyperviseur ESXI. Nous avons décidé d’utiliser cette solution, car elle est fiable et utilisée par
de nombreuses entreprises, mais aussi, car nous connaissons la solution. Nous avons préféré
nous concentrer sur le cœur du projet plutôt que sur l’apprentissage d’une solution de
virtualisation.
Voir annexe 1 : Mise en place du LDAP sur LTSP et X2Go
17
2) Mise en place de LTSP
L’un des atouts du projet LTSP est sa mise en place facile, mais aussi sa gestion.
D’ailleurs, l’installation d’un serveur LTSP est modulable en fonction des besoins recherchés.
Ainsi, nous avons installé le serveur suivant différentes méthodes : la 1re est de centraliser
tous les services nécessaires sur un même serveur et la 2e consiste à séparer tous les services
nécessaires à notre infrastructure.
- Si l’on choisit l’installation élément par élément :
LTSP-server Le paquet va permettre installer sur le serveur LTSP, le serveur TFTP, NFS et le
SSH.
Ldm-server Ce paquet est à installer sur un serveur d'application (c’est lui qui va contenir toutes les applications pour les clients légers. Cependant pour notre projet, nous n’en avons pas besoin, car il est destiné au streaming de bureau). Il va permettre installer LDM et le SSH.
isc-dhcp-server Permets installer un serveur DHCP (si l’on possède déjà un serveur, il n’est pas nécessaire de l’installer. Mais pour le projet, nous allons installer).
ltsp-docs Permets d’avoir la documentation sur LTSP.
- Si l’on choisit l’installation centralisée, alors l’installation se réalise via un unique
paquet qui est « ltsp-server-standalone ». Il installe ainsi tous les paquets listés
précédemment.
Pour résumer, voici un tableau :
Pour réaliser la maquette, on a choisi l’installation dite élément par élément pour répondre
au besoin demander. La version « standalone » installe un service LDM, qui est inutile dans
notre cas puisque l’on réalise uniquement du boot par réseau et non du streaming de bureau
distant. Ainsi, nous allons installer les paquets suivants : LTSP-server, isc-dhcp-server, nfs-
kernel-server et ltsp-docs.
Les étapes d’installation et de configuration du serveur LTSP se trouvent dans les annexes de
rapport et ayant comme titre : Installation de LTSP. Seuls les points clés de l’installation vont
être présentés.
18
Une fois que le serveur est configuré, mis à jour tout en installation les paquets nécessaires et
en configurant le service NFS, il faut crée l’environnement chroot nécessaire pour les clients.
On distingue deux types d’environnement : l’environnement dans lequel une version
minimale du système exploitation est installée et utilisée uniquement pour l’authentification
et l’accès au serveur d’application (on utilise ce type environnement quand LTSP est configuré
pour fonctionner en streaming de bureau) et enfin l’environnement dans lequel une version
complète du système exploitation est installée. On appelle ce type d’environnement les FAT-
client. On utilise ce dernier quand l’on veut réaliser du boot par réseau.
Pour créer un environnement, on utilise la commande ltsp-build-client suivi des options pour
paramétrer l’environnement.
Pour créer un environnement FAT-client, on a utilisé la commande suivante :
ltsp-build-client --arch i386 --chroot FatClient --fat-client-desktop xubuntu-desktop
--prompt-rootpass
Que signifient toutes les options qui suivent la commande ?
✓ --arch i386 : spécifie l’architecture CPU des clients légers. Ici, l’architecture CPU
est de 32 bits. Si c’est une architecture 64 bits, alors on remplace la valeur i386
par AMD64.
✓ --chroot FatClient : permets de donner un nom à notre environnement. Ici, le
nom que nous avons donné est FatClient, mais il est évidemment possible de
le modifier.
✓ --fat-client-desktop xubuntu-desktop : option permettant d’installer un
système complet dans le chroot. L’option demande aussi de rajouter quelle
interface graphique qu'il faut installer. Dans notre cas, nous avons décidé
d’installer xubuntu-desktop, car c’est une interface légère.
✓ Prompt-rootpass : À la fin de la création de l’environnement, il sera demandé
de rentrer un mot de passe pour le compte root de l’environnement.
Le système d'exploitation qui sera installé dans le chroot, est le même qui est utilisé par le
serveur LTSP par défaut. Mais si l’on souhaite installer un OS différent, il faudra alors utiliser
l’option « --dist » suivi du nom de la distribution et l’option « --mirror » pour spécifier quel
miroir il devra utiliser pour télécharger les paquets liés à la distribution choisie.
À la fin de la création du chroot, on demande si l’on crée une image Squashfs pour utiliser
NBD. Pour ce projet, on ne va pas l’utiliser et donc passer outre cette demande. NBD est une
abréviation pour Network Block Device. C’est aussi un service qui permet de réaliser ce type
de montage (et remplace ainsi NFS). L’intérêt de ce type de montage est que l’environnement
des clients LTSP est compressé en une image Squashfs et donc permet une utilisation réseau
plus optimisée (économie de la bande passante, un démarrage des clients plus rapide).
19
Il offre aussi la possibilité de créer un SWAP réseau destiné à des clients n'ayant pas assez de
mémoire RAM. Mais cette solution comporte aussi des inconvénients tels qu’une perte de
flexibilité, car après chaque modification de l’environnement, il faut reconstruire l’image.
Ainsi, si l’on souhaite mettre un tel projet en production, il serait plus judicieux d’utiliser le
NBD à la place du NFS. Mais dans le cadre du projet, nous sommes restés sur le NFS.
Maintenant que l’environnement est créé, on va le configurer. Pour cela, il faut aller dans le
fichier : « /opt/ltsp/nom_chroot/etc/lts.conf ». Voici les différentes options qui y sont
présentes :
Dans ce fichier, plusieurs options s’offrent à nous. Certaines ne nous sont pas utiles dans le
cadre de la maquette. Le 1er est l’option NBD_SWAP que l’on peut régler à « false », car on
n’utilise pas NBD. Ensuite, la 2e option concerne LDM_SERVER, nous avons commenté la ligne,
car nous n’avons pas de serveur LDM, vu que nous ne sommes pas sur une architecture de
streaming de bureau.
Pour finir, il faut ajouter une option qui va activer le mode "fat-client", pour cela, il suffit de
rajouter l’option suivante :
Ainsi, le chroot est configuré et prêt à être utilisé sur un client léger.
Voir annexe 2 : Installation de LTSP
20
Gestion / administration du serveur LTSP
La gestion du serveur LTSP se réalise à travers différentes commandes qui sont
disponibles une fois LTSP installé. Voici une liste des commandes :
Une fois que l’on a créé un ou plusieurs environnements, il est possible que les applications
installées par défaut ne suffisent pas pour notre utilisation. Il se sera donc nécessaire de
pouvoir installer des applications et des paquets. Il est tout à fait possible de le faire. Pour
cela, il faut accéder au chroot. On va donc utiliser la commande ltsp-chroot :
ltsp-chroot --mount-dev --mount-proc --arch nom_chroot .
Une fois à l’intérieur du chroot, nous pouvons installer les paquets comme sur un système
Linux normal avec la commande « apt-get install ». Si nous devons supprimer des paquets,
alors il faut entrer « apt-get autoremove ».
Quand toutes nos opérations dans le chroot sont finies, il suffit de taper « exit » et
l’environnement se fermera.
Comme pour les postes physiques ou virtuels, faire les mises à jour du système est crucial,
aussi bien pour des questions de performances, de stabilité, de correction de bugs que pour
des questions de sécurité. Il est bien évidemment possible de réaliser des mises à jour à
l’intérieur des chroot. Il existe donc deux façons d’y parvenir :
- Manuellement en « rentrant » dans l’environnement comme pour l’installation de
paquets, soit grâce un script.
- La meilleure approche est d’automatiser le processus et de les exécuter de préférence
quand aucune personne ne se sert des postes. C’est-à-dire la nuit par exemple.
Commande Description
ltsp-info Affiche des informations sur l’installation LTSP, les packages serveur et client associés de chaque chroot.
ltsp-build-client Permets de créer un environnement destiné aux clients légers sur le serveur LTSP.
ltsp-update-image Mets à jour une image NBD d’un chroot client.
ltsp-update-sshkeys
Mets à jour les clés SSH des chroot. Ceci est obligatoire après la modification de l’adresse IP du serveur par exemple.
ltsp-update-kernels Mets à jour l'image tftpboot du client avec le noyau actuel du chroot LTSP.
ltsp-config Génère la configuration en fonction de votre configuration LTSP.
ltsp-chroot Permets d’accéder au chroot du client léger pour administrer le système (ex. : mise à jour, installation de paquets, etc.).
ltsp-localapps Exécute les applications sur le client léger au lieu du serveur.
ltsp-remoteapps Destiné aux Fat-client, il exécute une commande sur le serveur au lieu du client.
nbdswapd Permets d’activer le swap réseau (uniquement disponible avec NBD).
21
Pour résoudre cette problématique, on va créer un script et l’enregistrer dans la « crontab »
pour automatiser son déclenchement.
Voici le script qui va permettre de mettre à jour notre environnement qui se nomme
FatClient :
Remarque : Si l’on utilise NBD, après chaque modification, il faut donc recrée l’image. Ainsi il
suffit de rentrer dans le script la commande commentée en fin de script (ligne verte) qui va le
permettre, après chaque lancement du script, de générer une nouvelle image.
Autre point positif de cette commande, en plus de réaliser la nouvelle image, elle va conserver
l’image précédente (celle qui n’est pas mise à jour) en la renommant en « .old ». Ainsi, en cas
de problème avec la nouvelle image, le basculement vers l’ancienne image se fait très
facilement en renommant l’image avec le nom initial (ex. : la nouvelle image se nomme
Fatclient.img et la sauvegarde de l’ancienne se nomme FatClient.img.old. En cas de soucis avec
la nouvelle image, il faut la supprimer et renommer la sauvegarde en FatClient.img).
22
Le point suivant que nous avons abordé est l’authentification à l'aide d'un annuaire LDAP.
L’utilisation d’un annuaire permet de centraliser tous les comptes utilisateurs sur un serveur.
Ce qui permet une administration plus facile, mais aussi une meilleure sécurité.
Nous avons choisi d’utiliser un annuaire LDAP, car cela est très rependu en entreprise, et la
gestion des nombreux comptes utilisateur y est simple. La mise en place de l’authentification
se réalise sur le serveur LTSP, puisque c’est lui qui gère l’authentification pour les clients
légers.
Cela permettra de s’authentifier, mais aussi, si c’est un nouvel utilisateur, de créer
automatiquement le dossier personnel (home) dans lequel les documents des utilisateurs
seront enregistrés. Pour permettre cette authentification, nous allons nous baser sur le
démon « nslcd » qui va permettre d’effectuer les requêtes LDAP, mais aussi de PAM qui vérifie
les mots de passe avant d’accéder à la connexion.
La mise en place de l’authentification LDAP se trouve dans l’annexe, avec le titre suivant :
LDAP-LTSP/X2GO.
3) Mise en place d’x2Go
Pour mettre en place un serveur de streaming de bureau, il faut tout d’abord installer x2go au niveau du serveur. Pour cela, on doit ajouter la source, le paquet x2goserver ainsi que ses dépendances. Il faut aussi un serveur SSH, car x2go utilise le protocole SSH pour se connecter. Il est nécessaire d’avoir une interface graphique sur le serveur : dans notre cas, nous avons installé l’interface XFCE, car il est simple et léger. Il n’y a pas besoin de configuration précise au niveau du serveur. Ensuite, au niveau du client, il faut obligatoirement qu’un système d’exploitation soit déjà installé et à jour dessus. Nous devons installer le paquet x2go-client et ses dépendances. Comme pour le serveur le paquet SSH doit être opérationnel. Par la suite, nous devons configurer x2go pour qu’il puisse se connecter au serveur, c’est-à-dire de renseigner l’adresse IP de ce dernier et de préciser que l’on souhaite utiliser l’interface XFCE. Voir les annexes Interface de configuration x2go client et interface de connexion de x2go-client. Cependant, pour notre projet, nous devions mettre en place un client léger : au démarrage de la machine, nous devons accéder directement à une interface de connexion, sans passer par le système d’exploitation installé sur celle-ci. Pour faire cela, il faut installer le paquet x2gothinclient et x2gothinclientmanagement. Le premier est le démon qui se lancera au démarrage et l’autre permet la configuration. Par la suite, il faut éditer certains fichiers afin d’éviter les configurations à chaque connexion dans « /etc/x2go/ ». Voici les principaux :
• x2gothinclient_sessions : pour la configuration de la session une fois que l’on est connecté.
• x2gothinclient_start : pour la configuration de l’interface de connexion de x2go.
23
• X2gothinclient_settings : les configurations de bases, généralement il n'y a pas besoin de changer sauf par exemple le nom de la fenêtre de connexion, etc.
Captures d’écran respectives des fichiers x2gothinclient_sessions et x2gothinclient_start
Dans le premier fichier, nous pouvons voir que l’on a configuré le client pour qu’il se connecte au serveur x2go à l’adresse renseigné. On peut voir aussi l’interface qui sera utilisée (ici XFCE), la qualité avec la résolution, le type de clavier, l’activation du son, etc.
Dans le second fichier, nous pouvons configurer l’interface de x2go avant de nous connecter. C’est l’interface qui sera affichée au démarrage de la machine. Nous pouvons voir les options utilisées. Par exemple ici l’interface sera en plein écran, il n’y aura pas de menue option (pour être cloisonné dans celle-ci), l’image de fond, etc.
Une fois que la configuration est faite, il faut créer un environnement pour x2go avec la commande « x2gothinclient_create » et ensuite lancer « x2gothinclient_update » mettant à jour l'environnement avec la configuration précédente.
Aussi, nous avons centralisé les connexions avec un serveur LDAP. Pour faire passer les connexions vers le serveur LDAP, nous avons installé PAM, un module d’authentification, dans le serveur x2go. Pour le mettre en place, il faut installer les paquets « libpam-ldapd » et « libnss-ldapd » puis « auth-client-config » et « ldap-auth-config » qui permettront de configurer automatiquement le module. Avec cela, lorsque l’on crée un utilisateur sur le serveur LDAP, nous pouvons nous connecter avec l’identifiant et mot de passe de l’utilisateur
24
à partir du client. Il y aura création automatique d’un home directory pour cet utilisateur dans un environnement clos (chroot). Enfin, nous avons limité les ressources du serveur pour les utilisateurs. Grâce à la commande lshw qui génère un fichier HTML contenant toutes les spécifications du serveur, nous avons alloué au maximum 1Gb de RAM et 15Gb d’espace disque. Vu que le serveur possède environ 4Gb, nous avons donc aussi limité le nombre de connexions simultanées par quatre. Pour configurer ces limitations, il faut configurer le fichier /etc/security/limits.conf. Voici ce que cela donne (annexe) :
Capture d’écran du fichier limits.conf
L'astérisque indique que la limitation s’applique sur tous les utilisateurs (sauf root). Maxsyslogins limite le nombre de connexions simultanées, data limite l’utilisation de l’espace disque par utilisateur et memlock limite l'utilisation de la mémoire vive. Avec la commande ulimit -a, nous pouvons voir les limitations :
Capture d’écran de la réponse à la commande ulimit
25
Nous pouvons bien apercevoir que la mémoire vive et l’espace disque sont bien limités. Bien sûr, nous pouvons aussi limiter d’autres ressources comme l’utilisation du processeur, etc. Voir les annexes sur les spécifications du serveur pour voir une partie ce qu’a généré la
commande lshw.
Une fois que tout a été mis en place, l’utilisation est assez simple. En démarrant la machine cliente, on se trouve directement dans l’interface de connexion de x2go. Avec un compte créé au préalable, il suffit d’entrer l’identifiant et le mot de passe. Ainsi, nous pouvons créer des fichiers, utiliser les logiciels installés tels que LibreOffice ou un navigateur Internet, etc. Si l’on se déconnecte, tout sera sauvegardé sur le serveur, il n’y aura aucune perte de données. Pour terminer sur cette partie, nous pouvons ajouter qu’avec x2go, nous ne pouvons pas changer de systèmes d’exploitation. Nous pouvons seulement changer l’interface (il faut cependant installer l’interface voulu sur le serveur). Toutefois, si l’on veut avoir le choix par exemple entre Debian et Ubuntu, nous pouvons monter un deuxième serveur x2go : l’un tournera sous Debian et l’autre sous Ubuntu. Il faudra aussi configurer l’interface de connexion cotée client pour ajouter un deuxième choix (afin de se connecter au deuxième serveur) et de mettre en place un système comme NFS pour synchroniser les données du compte de l’utilisateur entre les deux serveurs. Pour voir le projet sous sa forme finale, voir les annexes Interface x2go thinclient et
Environnement XFCE.
Voir annexe 3 : Mise en place d’x2Go
26
Les tests entre les deux solutions
Dans un souci de comparaison, nous avons pensé à faire des tests de performance entre les deux solutions d’architecture de bureau léger. Grâce à l’outil de supervision NetData, on est capable de remonter en temps réel les performances de la machine et d’avoir des graphiques sur une durée de temps déterminée. Pour les tests de performance, nous allons comparer les deux solutions sur différents points. En premier lieu, les ressources utilisées au démarrage et le temps mis, ensuite les ressources utilisées afin de lancer une application et le temps mis et pour finir on stresse la machine afin de savoir quelles sont les ressources utilisées par le service. Pour tous les tests effectués, nous utiliserons des machines similaires afin que les tests soient réalistes.
1) Test des performances et du temps de démarrage
Pour ce test, nous ne pouvons pas mettre de supervision sur le client LTSP, car il ne
contient aucun système d’exploitation. Nous comparerons pour la partie streaming de bureau distant le serveur ainsi que le client. Pour chaque test de ressource aux démarrages nous avons enregistré l’écran pendant le processus de démarrage afin de pouvoir constater l’utilisation de ressources.
a) Boot par le réseau :
Lien de la vidéo : https://www.youtube.com/watch?v=qUsUWxwI-H0
On peut voir lors du démarrage qu’il y a une connexion entrante sur le serveur LTSP qui correspond au client : c’est le premier contact avec le serveur.
27
Le boot par le réseau ne demande quasiment aucune ressource provenant du processeur. Les ressources les plus utilisées durant cette tâche sont le disque et la connexion internet.
Le disque et le réseau sont donc sollicités lors de cette opération afin d’envoyer l’image au client. On peut voir plusieurs pics d’utilisations lors de cette opération.
À la fin du démarrage de la machine cliente via le boot par le réseau, le serveur LTSP n’utilise plus aucune ressource. Malgré le fait qu’il n’y ait pas d’outils de monitoring sur le client LTSP, on sait qu’il y a utilisation du disque et de la connexion.
28
b) Streaming de bureau distant
Lien de la vidéo : https://www.youtube.com/watch?v=NWo4n1cT3rA
Le streaming de bureau distant utilise les ressources du serveur afin de faire fonctionner les applications et le système. Les seules ressources alors utilisées par la machine cliente et la connexion internet qui doit être de bonnes qualités afin de permettre une retransmission sans latence. Comme on peut le voir sur les images et la vidéo, tout se passe sur le serveur. Voir annexe 4 : analyse du démarrage de streaming de bureau distant :
2) Test des performances aux lancements d’applications
Au lancement d’applications, les deux solutions ont toutes deux des comportements différents. Pour le streaming de bureau à distance rien ne se passe sur le client, l’application et les ressources utilisées par celle-ci sont sur le serveur. On le voit bien en la lançant. Toutes les contraintes seront liées au serveur central et non à la machine client finalement. Sur LTSP les applications lancées sur une machine distante utiliseront les ressources de la machine cliente, mais elles seront chargées via le réseau, auparavant, par le serveur LTSP.
3) Test de stress
Ce test permet de montrer clairement l’utilisation des ressources par les deux solutions et de voir les aspects positifs et les aspects négatifs des solutions. Sur un stress à partir d’un client de streaming de bureau distant, on constate que c’est le serveur qui assume le stress effectué. Sans configurations préalables le serveur prend en compte la totalité du processeur pour un utilisateur : comme si l’on utilisait le serveur central directement afin de mener nos tests. Pour un service LTSP et à partir du client, on voit bien que ce dernier se charge des ressources nécessaires du stress. Le serveur reste en stand-by, car il n’intervient aucunement pour attribuer des ressources.
29
4) Conclusion
On aperçoit clairement les différences entre les deux solutions sur les graphiques des tests qui montrent que chaque solution a ses avantages et ses inconvénients. Sur une solution de streaming, on ne sollicitera finalement que la connexion internet du client tandis que sur LTSP ce sera toutes les ressources du client au détriment du serveur central. C’est pour cela que les clients légers destinés à démarrer par le réseau se doivent d’être plus performants que le streaming de bureau. On voit exactement ce comportement sur le test de stress effectué.
Il est à noter que lorsqu’on lance une vidéo sur les deux différentes solutions on remarque
une grosse différence. Le streaming par réseau a du mal à afficher clairement la vidéo, il
saccade ou bloque selon la résolution. Au contraire, le boot par réseau n’a aucun mal à lire
une vidéo puisque tout se passe sur la machine cliente.
30
Conclusion
Pour finir, nous pouvons dire que ce projet nous a permis tout d’abord de nous organiser en équipe. On a dû s’adapter entre membres du groupe, mais nous avons aussi dû respecter notre planning. Ce projet nous a aussi permis de voir une autre facette sur la mise à place de machines sur un serveur et que celle-ci peut être la meilleure solution suivant le cas. Durant la mise en place des deux maquettes, nous avons pu apprendre à centraliser les connexions et à faire démarrer une machine, ou bien de streamer une interface par le réseau. Ce projet nous a aussi donc permis d’accroitre nos connaissances en informatique notamment la configuration et l’installation de serveurs. Pour résumer, ces deux solutions peuvent s’avérer bien meilleures face aux installations classiques telles que pour mettre à jour les paquets ou le coût réduit des installations. Entre ces deux maquettes, la principale différence est que le boot par réseau se limite aux performances de la machine cliente alors que le streaming se limite directement aux performances du serveur et à la vitesse de connexion. Si nous prenons la bonne décision en fonction du problème, ces deux solutions peuvent être aussi performantes que l’autre.
31
Glossaire
NFS : abréviation pour Network File System, c’est une application du type client/serveur qui
permet à un utilisateur de consulter et, éventuellement, de stocker et de mettre à jour des
fichiers sur un ordinateur distant, comme s'ils étaient sur son propre ordinateur. Il a vu le jour
en 1984 par Sun Microsystems.
(Source : http://www.lemagit.fr/definition/NFS).
DHCP : abréviation pour Dynamic Host Configuration Protocol, est un terme anglais désignant
un protocole réseau dont le rôle est d'assurer la configuration automatique des paramètres
IP d'une station, notamment en lui assignant automatiquement une adresse IP. Il donne aussi
d’autres informations comme le masque de sous-réseau, la passerelle, le/les serveurs DNS,
adresse de broadcast, et d’autres encore.
(Source : http://www.commentcamarche.net/forum/affich-6029118-qu-est-ce-que-le-dhcp).
TFTP : abréviation pour Trivial File Transfer Protocol, est un protocole simplifié de transfert de
fichiers qui fonctionne en UDP et sur le port 69. il ne gère pas le listage de fichiers, et ne
dispose pas de mécanismes d'authentification, ni de chiffrement. TFTP, reste très utilisé pour
la mise à jour des logiciels embarqués sur les équipements réseaux comme des routeurs,
switch par exemple, mais aussi pour faire booter des ordinateurs sur le réseau.
(Source : http://www.techno-science.net/?onglet=glossaire&definition=3884)
LDAP : abréviation pour Lightweight Directory Access Protocol, le LDAP est un gestionnaire
d’annuaire partagé permettant de centraliser les comptes utilisateurs ainsi que leurs groupes
d’appartenance. Le protocole LDAP a vu le jour en 1993 par l’université du Michigan et dont
le but est supplanté le protocole DAP (Directory Access Protocol).
GRUB : abréviation pour Grant Unified Bootloader, est un logiciel qui permet de charger
(d’amorcer) un système exploitation. Il est capable de charger des OS compatibles avec la
norme POSIX (GNU/Linux, BSD, etc.).
(Source : https://doc.ubuntu-fr.org/grub-pc)
32
SYSLINUX : C’est un chargeur de démarrage pour le système d'exploitation Linux qui s'exécute
sur un système de fichiers MS-DOS / Windows FAT. Il est destiné à simplifier la première
installation de Linux et à créer des disques de démarrage de secours et d'autres applications
spéciales.
(Source : http://www.syslinux.org/wiki/index.php?title=SYSLINUX#What_is_SYSLINUX.3F)
Kernel : en français "noyau", est une partie fondamentale des systèmes exploitation. Il gère
les ressources de l’ordinateur et permet aux différents composants (logiciel et/ou matériel)
de communiquer entre eux.
(Source : https://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d%27exploitation)
Windows TSE : Les services Microsoft Terminal Serveur Édition permettent d’accéder à un
système d’exploitation Windows partagé entre plusieurs utilisateurs. L’OS est hébergé sur un
serveur et les utilisateurs s’y connectent généralement via des clients légers qui ne servent
alors que de points d’accès. Cela permet aussi de travailler à distance depuis n’importe quel
client TSE.
(Source : https://www.promosoft.fr/les-12-avantages-travailler-en-tse/)
Streaming : Service permettant de diffuser un flux en temps réel et sans interruption.
(Source : http://www.linternaute.fr/dictionnaire/fr/definition/streaming/)
PAM : signifiant « Pluggable Authentication Modules » et inventé par SUN, celui-ci permet
d’intégrer des schémas d’authentification. Ce module est présent sur les systèmes UNIX
depuis 2006.
GPL : Abréviation pour Général Public Licence.
RAM : Random Access Memory ou mémoire vive est une mémoire volatile (les données sont
perdues lorsque que l’ordinateur est éteint) ici sont stockées les données en cours d’exécution
ESXI : VMWare ESXI est un hyperviseur de type 1 ce qui veut dire qu’il s’exécute sur la partie
hardware de l’ordinateur. C’est un hyperviseur des licences VMware vSphere.
33
SquashFS : SquashFS est un système de fichiers compressé en lecture seule sous Linux.
NBD : Network Block Devices (NBD) est utilisé pour accéder à un périphérique de stockage à distance
(Par exemple un disque dur qui ne réside pas sur la machine locale mais distante.)
SWAP : Le SWAP est une zone d'un disque dur faisant partie de la mémoire virtuelle de votre
ordinateur. Il est utilisé pour décharger la mémoire vive physique (RAM) de votre ordinateur
lorsque celle-ci arrive à saturation. (Source : https://doc.ubuntu-fr.org/swap)
Crontab : Cron est un gestionnaire de tâches qui exécute certaines tâches préalablement
mises dans un fichier crontab à un moment précis.
34
Bibliographie
Boot par réseau
• https://doc.ubuntu-fr.org/ltsp_version_5.x : Serveur LTSP version 5.x
• https://fr.wikipedia.org/wiki/Linux_Terminal_Server_Project : Linux Terminal Server
Project
• https://tutofacile.org/2017/10/02/installation-configuration-ltsp-5/
• http://www.dietpc.org
• https://thinstation.github.io/thinstation/
• https://en.wikipedia.org/wiki/Thinstation
• https://doc.ubuntu-fr.org/ltsp
• https://www.mathrice.fr/IMG/pdf_2009-03-diskless.pdf
• http://www.ltsp.org/ : Linux Terminal Server Project
• http://wiki.ltsp.org/wiki/Installation#Client : Exigences matérielles pour LTSP (client
et serveur)
• http://wiki.ltsp.org/wiki/Concepts : Concept du boot par réseaux et du projet LTSP
• https://tutofacile.org/2017/10/02/installation-configuration-ltsp-5/ : Installation
LTSP
• https://fr.wikipedia.org/wiki/D%C3%A9marrage_sur_le_r%C3%A9seau
• https://www.ibisc.univ-evry.fr/~petit/Bazar/AdminSysteme/PXE/PXE-test-pp.html :
Boot par réseau, schéma
• https://technet.microsoft.com/en-us/library/ee621815(v=ws.10).aspx : Schéma boot
réseau
• https://fr.wikipedia.org/wiki/Initrd : Initrd
• http://linuxedu.ac-toulouse.fr/lib/exe/fetch.php?media=clientleger:ltsp2.pdf :
Rapport sur ltsp
• https://en.wikipedia.org/wiki/Linux_Terminal_Server_Project : LTSP
• http://wiki.ltsp.org/wiki/Commands : Commande pour gérer LTSP
• http://wiki.ltsp.org/wiki/Concepts
• http://www.ltsp.org/download/ : Utilisation de LTSP par distribution
Streaming de bureau
• https://doc.ubuntu-fr.org/serveur_nomachine : NxServer
• https://doc.ubuntu-fr.org/freenx : FreeNX
• https://doc.ubuntu-fr.org/x2go : Documentation d’ubuntu sur x2Go
• https://wiki.x2go.org/doku.php : Wiki officiel de x2Go
• http://linuxfr.org/users/fravashyo/journaux/x2go-le-digne-successeur-de-freenx :
Article sur le streaming de bureau distant.
• https://doc.ubuntu-fr.org/vnc : Documentation sur VNC
35
• https://wiki.x2go.org/doku.php/wiki:advanced:tce:install : ThinClient x2Go
Glossaire
• http://www.lemagit.fr/definition/NFS
• http://www.commentcamarche.net/forum/affich-6029118-qu-est-ce-que-le-dhcp
• http://www.techno-science.net/?onglet=glossaire&definition=3884
• https://doc.ubuntu-fr.org/grub-pc
• http://www.syslinux.org/wiki/index.php?title=SYSLINUX#What_is_SYSLINUX.3F
• https://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d%27exploitation
• https://www.promosoft.fr/les-12-avantages-travailler-en-tse/
36
Annexes
Annexe 1 : Mise en place du LDAP sur LTSP et X2Go
- On installe les paquets nécessaires à l’authentification : apt-get install libnss-ldapd libpam-ldapd (auth-client-config ldap-auth-config)
- Durant l’installation, des informations sont demandées à l’utilisateur : URI du serveur LDAP : ldap://172.16.0.10
37
Une installation et configuration, on va installer les paquets suivants : apt-get install auth-client-config ldap-auth-config Une nouvelle, des informations vont être demandées à l’utilisateur: On rentre l’IP du serveur LDAP : ldap://172,16,0,10
38
Deux questions sont demandées. On répond d’abord “oui” puis “non” On rentre le cn du compte administrateur du LDAP : cn=admin,dc=asrall,dc=fr
Puis on rentre le mot de passe du compte Puis, on configure le client pour que l’on puisse réaliser la connexion LDAP auth-client-config -t nss -p lac_ldap
Enfin, on ajoute une option qui va crée automatiquement les homes lors de la première connexion d’un utilisateur LDAP. On tape la commande suivante : pam-auth-update Puis on coche la dernière case “create home directory on login”
Une fois les paramètres mis à jour, on redémarre le service nscd : systemctl restart nscd.service Et pour finir, on va tester la connexion en ligne de commande. Pour cela, on va prendre un utilisateur qui est inscrit dans le LDAP puis se connecter avec la commande su - utilisateur.
39
Et voilà, la connexion fonctionne bien en ligne de commande, maintenant on va tester avec lancer un client léger. Pour ce 2e test, on va utiliser un autre utilisateur qui ne s’est jamais connecté sur le serveur.
Et voilà, la connexion a réussi avec ce nouveau compte et l’on a accès au bureau de l’utilisateur. Donc l’authentification LDAP est bien fonctionnelle.
40
Annexe 2 : Installation de LTSP
Il y a deux façons d'installer LTSP, en méthode centralisée ou élément par élément.
Installation du serveur LTSP
apt-get install ltsp-server isc-dhcp-server ltsp-docs nfs-kernel-server Il faut autoriser l’accès du montage dans /etc/exports. Et ajouter : /opt/ltsp *(ro,no_root_squash,async,no_subtree_check) /opt/ltsp : dossier sur lequel s’applique les autorisations
* : représente « tout le monde » pour qui s’applique les instructions
On redémarre le service nfs-kernel-server
service nfs-kernel-server restart
Environnement chroot
ltsp-build-client --arch i386 --chroot Nom_Du_Chroot --fat-client-desktop gnome-desktop-environment –promptrootpass
• fat-client-desktop : spécifie qu’on exécute toutes les applications en local.
• gnome-desktop-environment : spécifie qu’il faut utiliser l’environnement de bureau GNOME.
Dans le cas de l’environnement hybride ou lourd, les applications doivent directement être installées dans l’environnement chroot, pour être exécutées avec les ressources locales du CL.
Pour cela, il faut aller à la racine de l'environnement :
ltsp-chroot --mount-dev --mount-proc --arch Nom_Du_Chroot
Une fois dans l’environnement, on installe n'importe quelle application, par exemple, pour Firefox :
apt-get install firefox-esr
41
Puis pour valider les modifications et sortir de l’environnement : exit.
Configurer le serveur DHCP
Aller dans /etc/dhcp/dhcpd.conf
Puis redémarrer le service isc-dhcp-server :
service isc-dhcp-server restart
43
Annexe 3 : Mise en place d’x2Go
Interface de configuration x2Go client
Interface de connexion x2Go client