Soutenance mémoire
Vu que les machines avec lesquelles nous travaillons nécessitent des systèmes d’exploitation qui à leurs tours demandent une maintenance et un suivi par un administrateur. Pour pallier à ce phénomène qui demande des moyens pour pouvoir garantir tout cela nous avons pensés à se migrer vers une nouvelle technologie connue sous le nom de LTSP. Cette technologie va nous permettre d’administrer des ordinateurs qui n’ont pas besoin de disque dur mais juste d’une carte réseau pour pouvoir télécharger un système d’exploitation via un réseau ou nous avons installé un serveur LTSP. En sachant que le système linux est toujours ignorer par beaucoup d’utilisateurs nous avons pensés à intégrer sur cette technologie l’utilisation simultané des deux systèmes d’exploitations à savoir linux et Windows de tel sorte que les utilisateurs puissent se basculer dans l’environnement de leur choix en faisant une simple combinaison de touche Crt+Alt+F1 pour être sur linux ou crt+Alt+F2 pour être sur Windows. Pour le coté windows l’utilisation d’un terminal serveur et Active Directory est indispensable.
LTSP : qu’est-ce que c’est ?
LTSP est l’abréviation de « Linux Terminal Server Project » ou projet de serveur de terminaux Linux. C’est une suite logicielle qui permet de fournir des environnements identiques à plusieurs stations de vieilles machines en les convertissant en terminaux. Cela réduit les couts et la maintenance, surtout dans un milieu ou chaque station doit avoir le même environnement de travail (écoles, entreprises,…).
Terminal Server : qu’est ce que c’est ?
C’est un ensemble de logiciels qui permet a plusieurs membres du réseau d’exécuter des programmes directement sur le serveur plutôt que sur leurs propres postes, baptises a l’occasion clients légers. En effet, l’utilisateur à l’impression d’utiliser les applications du serveur comme si elles étaient sur son propre poste. En réalité, ces applications sont exécutées sur le serveur et affichées sur le poste client par l’intermédiaire d’une fenêtre. Tous les traitements liés à l’application sont effectués sur le serveur. Le poste client se contente d’afficher des images transmises par le serveur. Cet outil présent un intérêt majeur lie a une réduction importante de l’administration. La gestion du parc est centralisée. A la différence du système LTSP, le client léger du Terminal serveur nécessite un système d’exploitation pour exécuter le programme TSE. LTSP, quant à lui, charge un système d’exploitation léger sur le client par le biais du réseau.
Solution
La solution que nous devons étudiée consiste à exécuter un client léger Terminal Serveur sur un terminal X charge par LTSP. Un client léger démarrera par le réseau en PXE si la carte réseau le permet. Le système d’exploitation lui sera envoyé par TFTP grâce au partage NFS au niveau du serveur. Seul le serveur exécutera des taches, tous les clients légers ne feront qu’effectuer des requêtes d’entrées (clavier, souris) et des affichages. Lorsque l’utilisateur désirera ouvrir une session Windows, il lui suffira d’utiliser le client léger Terminal Serveur. L’utilisation telle quelle de systèmes Linux et Windows sur le même réseau nécessite une gestion séparée des comptes utilisateurs. Pour y remédier, les comptes des utilisateurs sous les différents systèmes devront être synchronises. Nous utiliserons pour cela l’annuaire Active Directory pour la gestion ainsi que l’outil Winbind pour la synchronisation.
Principe de fonctionnement
Avant de mettre en place une telle solution, il est important de connaitre les ressources dont nous avons besoin pour faire fonctionner le tout de manière optimale.
Définir les ressources appropriées
Pour réalisé ce projet nous avons besoin de certaines ressources bien appropriées à savoir une quantité de mémoire vive et d’un réseau bien dimensionné .
Une quantité de mémoire vive appropriée
Le service LTSP est un gros consommateur de mémoire vive. La quantité de mémoire vive nécessaire est variable et dépend du nombre de machines à gérer. Elle se calcule de la manière suivante : Mémoire totale = 256Mo + (128M* nombre de terminaux) La mémoire est donc un facteur limitant pour l’emploi de ces technologies. Il faudra prévoir une quantité de RAM en fonction de la taille du parc que l’on souhaite mettre en place.
Un réseau bien dimensionne
Dans notre environnement LTSP, chaque client léger est connecte au Switch, qui est lui même connecte au serveur. Cela signifie que tout le trafic réseau se fait entre le Switch et le serveur. Il faut donc mettre en place un lien le plus rapide possible entre le Switch et le serveur pour que le réseau ne soit pas un facteur limitant. Pour une utilisation en production il sera donc crucial d’adapter les performances du réseau en fonction de l’utilisation souhaitée. Un lien minimum de 1Gbit vers le serveur ainsi qu’un lien à 100Mbit vers chaque client léger est conseillé pour une utilisation fluide.
Les différentes étapes du démarrage d’un client léger
Nous allons vous présenter les différentes étapes du chargement du système à partir d’un client léger. Ces étapes décrites en détails cidessous permettent de mieux assimiler le fonctionnement de l’interaction Client /Serveur LTSP.
➤ La première étape est le chargement du noyau Linux en mémoire du client léger. Ceci est réalise par le biais du réseau grâce à un boot rom (ou Ether boot) contenu dans la carte réseau, le PXE. Celui-ci émet tout d’abord une requête DHCP pour configurer son interface réseau, puis télécharge le noyau Linux se trouvant sur le serveur TFTP.
➤ Une fois le noyau Linux chargé dans la mémoire du client léger, il commence à s’exécuter.
➤ Le noyau va initialiser puis l’ensemble du système et de tous les périphériques qu’il peut reconnaitre.
➤ Pendant le chargement du noyau, une image de disque virtuel est également chargée en mémoire du client léger .Un argument de la ligne de commande root=/dev/ram0 du fichier de configuration demande au noyau de monter cette image comme racine de son système de fichiers.
➤ Le script / linuxrc s’exécute alors commence par un balayage (scan) du bus PCI du client léger dans le but de rechercher une carte réseau. Chaque composant PCI trouvé est comparé aux descriptions stockées dans le fichier /etc/niclist. En cas d’égalité, le nom du module-driver correspondant à la carte réseau trouvée est renvoyé par le script, et le module est charge en mémoire.
➤ Un petit module client DHCP appelé dhclient est ensuite lance. Il lance une nouvelle requête au serveur DHCP. Cette requête est nécessaire pour recouper les informations nécessaires au système Linux que la première requête du boot rom ne pouvait retourner.
➤ Lorsque le dhlient reçoit une réponse du serveur, il exécute le script /etc/dhclient-script. Ce script récupère les informations renvoyés et configur l’interface eth0.
➤ Jusqu’ à cette étape, le système de fichiers était un disque virtuel en RAM. Le script /linuxrc va maintenant monter un nouveau système de fichiers sur sa racine (root) via NFS. Le répertoire exporté par NFS depuis le serveur vers le client léger est en principe /opt/ltsp/i386.Cette opération ne peut être réalisée en montant directement ce répertoire sur /. Il doit d’abord être monté sur /mnt, puis la commande pivot rot est lancée. pivot rot va échanger la racine courante (le disque virtuel) avec le nouveau système de fichiers. Lorsque cela termine, le répertoire exporté par NFS est monté sur / et l’ancienne racine est montée sur /oldroot.
➤ Une fois le montage et l’échange de racine effectués, le script /linuxrc a terminé son travail. Le programme /sbin/init s’exécute alors init va lire le fichier /etc/inittab et mettre en place l’environnement du client léger.
➤ Le script rc.sysinit crée un nouveau disque virtuel en mémoire (ramdisk) de 1 Mo, destiné à contenir toutes les données et informations devant être écrites ou modifiées par la suite (disque en lecture/écriture).Ce disque virtuel est monté en tant que /tmp sur le système de fichiers local du client léger.
➤ Le fichier lts.conf est examiné, et tous les paramètres en rapport avec le client léger en cours d’initialisation sont exportés comme variables d’environnement. Le script rc.sysinit les utilisera par la suite.
➤ L’interface réseau loopback est ensuite configurée. Il s’agit de l’interface ”interne” ayant pour adresse IP 127.0.0.1.
➤ Si l’exécution locale d’applications est activée, le répertoire /home du serveur est exporte via NFS pour être monté sur le répertoire /home du client léger, afin que les applications puissent avoir accès aux répertoires personnels des utilisateurs.
➤ Lorsque le script rc.sysinit est termine, le contrôle revient au programme /sbin/init, qui va alors changer le niveau d’exécution (run level) de sysinit. Ceci aura pour effet de lancer toutes les autres commandes spécifiées dans le fichier /etc/inittab.
➤ Par défaut, le fichier inittab contient des lignes demandant l’exécution du script /etc./screen session sur tty1, tty2 et tty3 (Terminaux internes).Il est donc possible d’utiliser trois sessions simultanées sur le client léger. Le type de ces sessions est contrôle par les paramètres SCREEN 01, SCREEN 02 et SCREEN 03 que l’on trouve dans le fichier de configuration lts.conf de LTSP.
➤ Si le paramètre SCREEN 01 de lts.conf a pour valeur startx, le script /etc./screen.d/startx est éxécute, ce qui lancera l’interface graphique Xwindows sur le client léger.
➤ Dans le fichier lts.conf, il existe un paramètre appelé XSERVER. Si ce paramètre est absent, ou a pour valeur ”auto”, le script startx tente de détecter automatiquement quelle est la carte vidéo du client léger.
➤ Le fichier /etc/X11/xorg.conf est crée en fonction des paramètres trouvés dans le fichier de configuration /etc/lts.conf.
➤ Une fois le fichier /etc/X11/xorg.conf crée, le script startx lance le serveur x correspondant avec ce nouveau fichier de configuration.
➤ Le serveur x lance alors une requête XDMCP au serveur LTSP, qui ouvre un écran de login.
➤ Arrive à ce stade, l’utilisateur peut s’identifier et se connecter (login) au serveur. Une fois authentifié, l’utilisateur a enfin accès à une nouvelle session graphique sur le serveur et a tous les programmes installés sur ce dernier.
➤ Une fois l’utilisateur authentifié, tous les programmes seront éxécutés sur le serveur, et seule leur sortie sera affichée sur l’écran du client léger. Toutes les ressources nécessaires à l’utilisation du système seront donc à la charge du serveur LTSP.L’avantage d’une telle solution est de recycler un vieux parc informatique à moindre cout, à condition d’avoir un serveur LTSP suffisamment puissant et un réseau local robuste.
|
Table des matières
Introduction
Avant-propos
I.PREMIERE PARTIE
I.1 INTRODUCTION
I.2 PRESENTATION DU PROJET
I.3 LTSP : QU’EST-CE QUE C’EST ?
I.4 TERMINAL SERVEUR QU’EST-CE QUE C’EST?
I.5 SOLUTION
II.PRINCIPE DE FONCTIONNEMENT
II.1 DEFINIR LES RESSOURCES APPROPRIEES
II.2 UNE QUANTITE DE MEMOIRE VIVE APPROPRIEE
II.3 UN RESEAU BIEN DIMENSIONNE
II.4 LES ETAPES DU DEMARRAGE D’UN CLIENT LEGER
II.5 LES MECANISMES D’AUTHENTIFICATION
II.6 AUTHENTIFICATION POUR SESSION WINDOWS
II.7 AUTHENTIFICATION POUR UNE SESSION LINUX
III.INSTALLATION DES SERVEURS
III.1 PRELIMINAIRES
III .2 INSTALLATION DU SERVEUR LTSP
III.3 INSTALLATION DU SEVEUR WINDOWS
IV. LE TERMINAL SERVEUR
IV.1 CONFIGURATION DE L’ACTIVE DIRECTORY
IV.2 CONFIGURATION DU PROFIL ITINERANT
IV.3 CONFIGURATION DU TERMINAL SERVEUR
V. LE SERVEUR LTSP
V.1 CONFIGURATION DU SERVICE DHCP
V.2 CONFIGURATION DU SEVICE LTSP
V.3 MODIFICATION DES FICHIERS lts.conf
VI.DEUXIEME PARTIE
VI.1 INTEGRATION DU SERVEUR LTSP AU DOMAINE A-D
VI.2 QU’EST-CE QUE WINBIND?
VI.3 CONFIGURATION DU SERVEUR SAMBA
VI.4 INSTALATION DE SAMBA ET WINBIND
VI.5 MODIFICATION DU FICHIER /etc/smb.conf
VI.6 INSTALLATION D’UN CLIENT KERBROS
VI.7 INTEGRATION SERVEUR LTSP A L’ACTIVE DIRECTORY
VI.8 CONFIGURATION DE WINBIND
VI.8.1 LE FICHIER /nsswitch.conf
VI.8.2 LE MODULE PAM
VI.8.3 Les 4 GROUPES DE MODULES
VI.8.4 LES INDICATEURS DE CONTROLE PAM
VI.8.5 CONFIGURATION DU FICHIER /etc/pam.d/login
VI.8.6 CONFIGURATION DU FICHIER /etc/pam.d/system-auth
VI.8.7CONFIGURATIONDUFICHIER/etc/Security/Pam mount.con
VI.9 GESTION DES MOTS DE PASSES DES UTILISATEURS
VI.10 CHARGEMENT DES MOTS DE PASSES
VI.11 Mise en œuvre
VII.TROISIEME PARTIE
VII.1 Sécurisation du réseau
VII.1.1 Installation d’un PROXY
VII.1.2 PRESENTATION DU SERVICE SQUID
VII.2 CONFIGURATION DU SERVICE SQUID
VII.3 CONFIGURATION DE SQUIDGARD
Conclusion
LISTE DES FIGURES
GLOSSAIRE
BIBLIOGRAPHIE
