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

2

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

4

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é.

6

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

42

Configurer l’environnement

Aller dans /opt/ltsp/Nom_Du_Chroot/etc/lts.conf

43

Annexe 3 : Mise en place d’x2Go

Interface de configuration x2Go client

Interface de connexion x2Go client

44

Environnement XFCE

Interface de connexion x2go thin client

45

Captures d’écran des spécifications du serveur

46

Annexes 4 : Analyse du démarrage de streaming de bureau distant