LTSP (Linux Terminal Serveur Project) Retour...
Transcript of LTSP (Linux Terminal Serveur Project) Retour...
LTSP Retour d'expérience
LTSP (Linux Terminal Serveur Project) Retour d'expérience
Table des matières1)Historique...................................................................................................................................................22)Introduction.................................................................................................................................................2
Exemple vécu d'utilisation et de mise en oeuvre d'une solution LTSP.....................................................2Comment ça marche, vue macroscopique.................................................................................................2Pourquoi ce document ?............................................................................................................................3
Mes liens d'inspirations :......................................................................................................................43)Compléments aux procédure d'installation.................................................................................................44)LTSP c'est quoi, principes...........................................................................................................................4
Terminal X et client LTSP.........................................................................................................................65)Comment ça marche détails (solution LTSP).............................................................................................7
Généralités.................................................................................................................................................7Vue macroscopique de la phase 1..............................................................................................................8Insistons sur le vocabulaire utilisé.............................................................................................................8
6)Que peut on voir et ou tracer pour suivre les différentes étapes.................................................................97)Exemples d'écrans permettant de se localiser dans les phases et étapes décrites cidessus.......................9
Phase1 étape1............................................................................................................................................9Phase1 étape2 : initialisation de linux sur le client..................................................................................10Phase1 etape3 Ouverture d'une session X, écran de login.......................................................................11
8)Comment ça marche, zoom détaillé sur les différentes phases et étapes..................................................14Phase 1.....................................................................................................................................................14
9)Configuration et paramétrage des logiciels et protocoles mis en oeuvre..................................................2110)Lexique....................................................................................................................................................2411)Annexes...................................................................................................................................................25
Comment affecter une adresse fixe au PC serveur SFTP........................................................................25Comment désactiver la fonction serveur DHCP sur la livebox...............................................................26Comment autoriser les connexions à distance (configurer GDM)..........................................................27Comment tester le serveur DHCP...........................................................................................................28Comment tester DHCP XDMCP GDM..................................................................................................28
Teste d'une session distante en XDMCP............................................................................................28Comment activer les messages debug GDM...........................................................................................30Comment créer et autoriser un accès shell (login root) sur l'OS du client..............................................32Comment supprimer le splash du client..................................................................................................33Comment configurer les firewalls (pares feu).........................................................................................33Comment vérifier si les différents services du serveur sont opérationnels.............................................35Plus d'infos sur certaines configurations.................................................................................................37
/etc/inetd.conf.....................................................................................................................................37/etc/exports..........................................................................................................................................38lts.conf................................................................................................................................................38dhcpd.conf..........................................................................................................................................39gestion dhcp3server...........................................................................................................................40
Données complémentaires.......................................................................................................................40
Page : 1/45
LTSP Retour d'expérience
Boot avec le fichier pxelinux.0 ..........................................................................................................40Analyse des traces Wireshark........................................................................................................40
syslogd................................................................................................................................................41nbi.img................................................................................................................................................41Complément sur initrd.img.................................................................................................................42Compléments sur l'affichage graphique.............................................................................................43
Essais.......................................................................................................................................................44
1) Historique16/06/08 Création
01/10/08 Première version publiée
2) IntroductionLTSP signifie Linux Terminal Server Project, c'est une solution matérielle et logicielle qui permet à plusieurs stations de travails légères (PC+écran+clavier+souris) d'ouvrir une session sur une autre machine Linux.
Exemple vécu d'utilisation et de mise en oeuvre d'une solution LTSPJe dispose d'un PC récent (en fin tout est relatif surtout dans ce domaine ;) équipé d'une distribution GNU Linux récente et disposant d'un accès internet. Cette machine est utilisée par plusieurs membres de la famille. Chacun dispose d'un compte utilisateur (login+mot de passe) avec son propre environnement de travail.
Le problème c'est qu'en général, lors des heures de pointe comme le soir, tout le monde souhaite utiliser en même temps l'ordinateur et on assiste souvent à de dures négociations pour disposer de l'écran et du clavier.
Une des solutions consisterait à acheter un voire d'autres ordinateurs (no comment sur l'aspect économique et écologique de cette solution).
Une alternative est la mise en oeuvre de la solution LTSP, c'est à dire que je dépoussière mes vieux PC et j'installe LTSP. Outre l'aspect économique et écologique de cette solution, j'y trouve un autre avantage. Dans la famille tout le monde n'est pas administrateur informatique. Donc qu'en il y a problème qui est ce qui s'y colle ? Autant de machines différentes autant d'administrations à assurer (mises à jour à réaliser, paramétrages, surveillance etc.) Avec la solution LTSP une seule machine à administrer...
Comment ça marche, vue macroscopiqueLe PC principal (que l'on va appeler serveur) est démarré, je l'utilise pour naviguer sur le net et rédiger un article sur le serveur LTSP. Ma fille arrive « papa tu me prêtes l'ordi? » ;)« C'est pas possible tu n'as qu'a utiliser l'autre PC »
L'autre PC c'est le vieux PC qui n'a plus de disque dur un processeur poussif et très peu de mémoire.Mais alors comment est ce possible de démarrer Ubuntu, Firefox, ... ?
Page : 2/45
LTSP Retour d'expérience
C'est très simple (façon de parler). Lorsque ma fille démarre son PC (le vieux) grâce à une configuration spécifique du bios et la présence d'un CD de boot dans le lecteur (du client), mais avec une disquette cela fonctionne également, le PC va demander via le LAN une adresse IP et les logiciels nécessaires à son fonctionnement.
Mon PC va lui répondre favorablement et va également lui proposer l'emplacement d'un fichier qui est un mini kernel (noyau linux).Le client s'approprie l'adresse proposée, télécharge le mini kernel et l'installe enRAM (transformée en partie pour l'occasion en pseudo disque).Un fois ce travaille réalisé le client est déjà beaucoup plus intelligent. Comme on le lui a spécifié via un fichier de configuration, il va maintenant monter un système Linux.
Là encore on va ruser puisque l'on ne dispose pas de disque dur et que la RAM est limitée. En fait on va utiliser une arborescence Linux présente sur le serveur que l'on va monter via le lan (réseau local).
Cette étape terminée s'affiche sur l'écran du client, la page de login.(ou ouverture de session)
Ma fille va donc saisir son login et mot de passe (elle dispose depuis longtemps d'un compte sur mon PC qu'elle utilise quand je ne suis pas devant mon PC). A partir de ce moment tout se passe sur mon ordinateur, tous les processus ou programmes qu'elle active le sont sur mon PC (comme tout le monde le sait Linux est multi tâches et multi utilisateurs). La seule différence avec ma connexion c'est que son écran se trouve déporté sur son vieux PC et qu'elle utilise son clavier pour la saisie, pour le reste c'est linux qui se dém.
Elle dispose donc des mêmes services que si elle était connectée directement sur mon PC, avec cette solution nous pouvons travailler simultanément en partageant les ressources d'une machine unique.
Cette technique peut naturellement être dupliquer plusieurs fois, c'est à dire plusieurs clients légers peuvent se connecter simultanément.
Pourquoi ce document ?Ce document capitalise mes expériences accumulées sur LTSP et sur les mécanismes mis en oeuvre comme par exemple le serveur DHCP et les protocoles TFTP, XDMCP... Ce n'est pas une procédure d'installation (cela existe déjà) mais plus un document qui se veut être pédagogique et qui donne des axes d'investigations et des conseilles pour la résolution de problèmes. J'essaie de donner des explications sur les mécanismes et techniques mis en oeuvres et propose des moyens pour « visualiser ce qui se passe ». Je ne suis qu'un amateur de plus débutant sur linux, aussi si vous constatez des erreurs ou si vous souhaitez compléter ce document vous pouvez me contacter via l'adresse mail suivante [email protected]
Premier conseil, lorsque vous consultez de la documentation ou des forums, sur LTSP attention à bien vérifier que ces derniers s'appliquent à votre version de LTSP (à l'écriture de ce document on en est à la version 5).
Ce qui est écrit ici s'applique à la version 5 dans un environnement GNU linux distribution Ubuntu version Hardy ou 8.04
La machine que j'utilise comme client LTSP à les caractéristiques suivantes : cpu Celeron 400Mhz, 128Kcache, mémoire de 125M (informations obtenues par la commande cat /proc/cpuinfo et meminfo)
Page : 3/45
LTSP Retour d'expérience
La machine utilisée comme serveur LTSP : cpu AMD Sempron(tm) Processor 2800, 1,6Ghz+ 128K de cache, mémoire de 1 G
Mes liens d'inspirations :● pour l'installation : http://doc.ubuntufr.org/ltsp (voir ci dessus premier conseil), j'ai installé le
paquet ltspserverstandalone 5,0
● documentation sur LTSP : http://wiki.ltsp.org/twiki/bin/view/Ltsp/Documentation
● documentation en Français sur LTSP : je n'ai pas trouvé de documentation sur LTSP5 en Français par contre on peut s'inspirer des informations contenues dans la doc de LSP4 en Fr. http://ltsp.mirrors.tds.net/pub/ltsp/docs/ltsp4.1fr.html
● documentation en Anglais LTSP et Ubuntu : https://help.ubuntu.com/community/UbuntuLTSP
A noter également un article de Frédéric Le Roy qui m'a apporté beaucoup sur le sujet. Article intitulé « Mise en place d'un serveur de clients légers » paru dans la revue GNU Linux magazine / France de février 2008 numéro 102.
3) Compléments aux procédures d'installation1. Penser, le cas échéant, à désactiver le serveur DHCP de votre box. Ce reporter à l'annexe au
paragraphe « comment désactiver le serveur DHCP » sur la box.
2. Penser à déclarer le ou les clients dans votre /etc/hosts J'ai constaté que cela améliorait le fonctionnement global et surtout était indispensable dans le cas de l'activation des messages de debug au niveau du GDM (voir toujours en annexe, « Comment activer les messages de debug GDM »)
3. Si vous devez modifier une configuration, toujours s'assurer que vous le faites dans le bon fichier. Vous constaterez que souvent ou retrouve le même fichier de configuration (même nom) à des endroits différents. D'où l'importance également de s'assurer que les conseilles que vous trouvez sur le net sont en rapport avec votre version. Dans le tableau du paragraphe 9 j'indique pour tous les service mis en oeuvre le fichier de configuration et son emplacement.
4. Toujours dans le cas de modifications de fichiers de configuration, il faut savoir que dans la majorité des cas il faut une action pour sa prise en compte par le système. Ça peut être une relance de daemon, une commande spécifique comme ltspupdateimage etc. (se reporter au paragraphe 9)
5. Lors d'une mise à niveau de votre distribution Ubuntu (comme par exemple lorsque je suis passé de la 6.6 à la 8.4), si vous constatez que vos clients LTSP ne fonctionnent plus, ne pas attendre trop longtemps avant de réinstaller les paquets nécessaires.
6. Si vous utilisez un firewall (pare feu) au niveau du serveur, ne pas oublier de laisser passer les différents ports utilisés (en annexe on trouvera quelques un des ports mis en oeuvre et un paragraphe sur « Comment configurer les firewalls »)
4) LTSP c'est quoi, principesLTSP signifie Linux Terminal Server Project, voir site : http://www.ltsp.org/
Page : 4/45
LTSP Retour d'expérience
LTSP est une solution matérielle et logicielle qui permet à un ou plusieurs utilisateurs de se connecter à distance via leur compte sur une machine donnée que l'on peut appeler serveur.
Les sessions à distance se font à l'aide de terminaux reliés via un LAN (réseau local) au serveur. (on peut relier un client et un serveur LTSP directement avec un câble croisé, mais c'est toujours un LAN certes très réduit ;)
Le terminal est constitué d'un ancien PC à bout de souffle, qui ne serait pas capable de supporter un OS récent et tous les logiciels modernes associés. De l'ancien PC on n'utilisera que son processeur, sa carte ou interface ethernet, sa mémoire RAM, clavier, souris et écran. Dans la suite du document on l'appellera client.(mais avec un PC récent cela fonctionne aussi ;),
Cette technique est utilisée notamment dans l'enseignement (on simplifie ainsi la gestion du parc) et cela offre une solution particulièrement économique. C'est également un bon moyen de recycler de vieux PC.Elle est également utilisable en famille (mon cas personnel) lorsque plusieurs membres souhaitent utiliser le pc domestique simultanément.Rien n'interdit de déployer cette solution dans un environnement professionnel.
Autre avantage de cette solution, elle est entièrement bâtie sur des logiciels libres ce qui vous permet de faire des économies et ou de vous mettre en conformité avec la loi ;)
Sous forme graphique la cible de se que l'on veut faire
Figure 1 : infrastructure LTSP
Les adresses données ici sont à prendre comme exemples pour illustrer cette doc, naturellement cela dépend de votre configuration existante. J'ai une livebox mais avec les autres box c'est pareille.A titre d'info et pour une meilleur compréhension, des exemples de listings, le compte utilisateur sur le
Page : 5/45
PC – Clients légers
internet
192.168.1.11
192.168.1.150client1 192.168.1.1
PC principal – Serveur LTSP
Live boxrouteur
Switch ou hub
192.168.1.149client2
@internet
LTSP Retour d'expérience
serveur s'appelle uiop et le compte utilisateur activé depuis le client s'appelle invite
Dans la suite du document, on part du principe que le PC principal (le futur Serveur LTSP) fonctionne, est équipé d'Ubuntu 8.4 dit Hardy.Qu'il dispose d'une adresse IP fixe qui est 192.168.1.11, voir en annexe « Comment affecter une adresse fixe ».Que la liveBoxe dispose d'une adresse IP fixe qui est 192.168.1.1Que le serveur DHCP de la LiveBoxe est désactivé, voir en annexe « Comment désactiver la fonction DHCP dans la box ».
Terminal X et client LTSPUne variante à la technique LTSP s'appuie sur un PC transformé en terminal X : En fait dans les deux cas le PC client est transformé en terminal X. Avec LTSP le PC client ne contient aucun logiciel installé (tout sera téléchargé depuis le serveur) alors qu'avec un PC transformé en terminal X ce dernier possède un disque dur sur lequel un système d'exploitation est installé, en général un linux allégé, plus le logiciel d'émulation terminal X (intégré dans pratiquement toutes les distributions).
Pour plus d'informations sur un PC transformé ou utilisé comme terminal X se reporter au tuto suivant : http://doc.ubuntufr.org/tutoriel/comment_creer_un_terminal_x_ou_recycler_une_vieille_machine?s=xdmcp (en annexe je propose cette technique pour un dépannage de la solution LTSP).
Comme indiqué ci dessous pratiquement toutes les solutions linux proposent la possibilité de fonctionner en terminal X on trouve cela sous le terme ouverture session XDMCP Attention j'usqu'à preuve du contraire cette solution de fonctionne plus pour se connecter sur une machine ubuntu 8,4 voir à ce sujet le forum que j'ai initialisé : http://forum.ubuntufr.org/viewtopic.php?id=250774
En résumé et en image :
Page : 6/45
Serveur LTSP sur lequel on veut ouvrir une session utilisateur
Client léger LTSPhéberge aucun logiciel
PC transformé en terminal X
héberge un OS allégé
Session XDMCPlinux complet
LTSP Retour d'expérience
5) Comment ça marche détails (solution LTSP)
GénéralitésPour la clarté du document nous allons définir quelques termes qui seront utilisés tout en expliquant le fonctionnement d'une relation client LTSP / serveur, plus précisément nous allons décrire ce qui se passe lors du démarrage et de l'initialisation de l'ensemble.
Globalement on peut découper cela en 2 grandes phases :
Phase 1 : Cette dernière débute lors de la mise sous tension du PC client (le serveur fonctionne déjà) et se termine lorsque sur l'écran de ce dernier on obtient l'écran de login de session.
Phase 2 : Cette phase correspond à une session active sur le PC serveur, mais dont les éléments périphériques écran, clavier et souris mis en oeuvre sont ceux du PC client.
La figure suivante schématise cette approche.
La phase 2 ne sera pas développée dans ce document (pour la simple raison que je n'ai pas eu de problème à ce niveau). Ce qui convient de retenir c'est que tout ce que vous demandez depuis le client est exécuté sur le serveur et c'est simplement le résultat qui est affiché ou déporté sur l'écran du PC client.
Par contre la phase 1va être détaillée car elle met en oeuvre de nombreuses techniques et protocoles dont le paramétrage et où les réglages peuvent poser quelques difficultés.
Page : 7/45
Phase 2 : session utilisateur 1
PC – Client léger PC principal – Serveur LTSP
client1
Phase 1 : démarrage du pc client
Affichage résultat de la demande (par exemple page web)
Demande d'ouverture d'une session pour utilisateur1
création session utilisateur 1
Affichage écran login
Demande d'un service (par exemple navigation web)
activation du processus associé
Affichage environnement de travail de l'utilisateur 1
LTSP Retour d'expérience
Vue macroscopique de la phase 1On vous rappelle que le PC client ne possède pas de disque dur ni de système d'exploitation. Or vous avez appris qu'un PC ne pouvait pas fonctionner sans OS (Operating System ou système d'exploitation) alors comment ça marche ?
Comme le client ne dispose pas d'un OS on va en chercher un sur le serveur LTSP et naturellement se sera un système linux. Comme il ne possède pas de disque dur on utilisera deux techniques, un Ramdisk (une partie de la RAM est utilisée comme disque dur. L'autre technique consiste à utiliser une partie du disque du serveur (technique NBD voir lexique et annexe)
La phase 1 peut donc se découper en 3 étapes :
1. Phase 1 Etape 1 : boot du système et récupération d'un noyau et système linux
2. Phase 1 Étape 2 : initialisation du noyau linux du client avec montage d'un système de fichier hébergé en partie sur le serveur
3. Phase 1 Étape 3 :ouverture d'une session X sur le client puis affichage de l'écran de login
La figure suivante illustre cela.
Les temps communiqués ici sont donnés à titre indicatif, ses valeurs peuvent changer en fonction de l'activité sur votre LAN, du nombre de clients, la puissance des machines...
Insistons sur le vocabulaire utilisé.client ou client LTSP : en général le vieux PC utilisé pour ouvrir à distance une session sur le PC serveur LTSP
Page : 8/45
Phase 1 : démarrage du pc client
PC – Client léger PC principal – Serveur LTSP
client1
Phase 2 : session utilisateur 1
Etape 1 : boot et téléchargement noyau linux
Etape 3 : ouverture d'une session X
Etape 2 : initialisation linux du client
t0+~20''
t0
t0+~35''
t0+~1'20''
t0+~1'30''
LTSP Retour d'expérience
serveur ou serveur LTSP : en général le PC récent utilisé pour permettre aux utilisateurs d'ouvrir une session de travail (on parle de session de travail même si on se connecte pour des jeux ;)client1 : c'est le nom (host) de la machine client (client1 possède une adresse IP attribué par le serveur DHCP, lui même hébergé sur le serveur LTSP)loginclient : c'est le login qui est utilisé pour se connecter sur l'OS (linux) monté sur le PC client utilisé qu'en cas de mise au point ou pour un dépannage (voir plus loin comment permettre la connexion shell à partir de root)loginsession : c'est le login utilisé pour se connecter comme utilisateur sur le PC serveur, soit directement soit via un client LTSP (uiop et invite pour les illustration de cette doc)
J'ai l'air d'insister sur cette notion de login, mais lors de mes débuts et en me basant sur les discussions dans sur les forums, je pense que se n'est pas inutile car il y a de quoi se perdre..
6) Que peut on voir et ou tracer pour suivre les différentes étapesLorsque tout fonctionne du premier coup ce qui est écrit ici ne sert à rien, si ce n'est pour se cultiver. Par contre en cas de problème cela peut servir pour essayer de localiser le problème et soit le résoudre soit poser les bonnes questions sur un forum.
Les possibilités offertes :
● regarder l'écran du client, je devrais dire les écrans, en effet à l'init de linux sur le client on passe en mode graphique en général sur term07 or rien n'empêche de regarder sur term01 (ctr+alt+F1). Par contre pour se loger à ce niveau il faut auparavant configurer le client (voir en annexe « Comment créer et autoriser un accès shell (login root) sur l'OS du client »
● utiliser un sniffer (voir définition cidessous) sur le serveur au niveau de l'interface ethernet utilisé (en général eth0) et ou utiliser la commande tcpdump (un sniffer est un outil permettant de capturer et analyser les messages IP qui transitent sur un interface ethernet, personnellement j'utilise Wireshark anciennement Ethereal)
● consulter les fichiers syslog du serveur, sur ubuntu vous les trouverez sous /var/log
● a noter que le serveur envoi normalement son syslog vers le syslog du client
● activer des traces de debug sur le serveur.
● lister les processus actifs sur le serveur, voire sur le client (commande ps).
● lister les ports IP en écoute (commandes netstat ou lsof i) avec sudo devant.
7) Exemples d'écrans permettant de se localiser dans les phases et étapes décrites cidessus
Phase1 étape1Ce qu'il faut voir normalement dans cette étape, c'est la recherche d'un serveur DHCP c'est à dire un message de la forme « Searching for server (DHCP).... » puis à la réponse de ce dernier, s'assurer que les valeurs correspondent à vos attentes (dans notre exemple ligne qui débute par Me : 192... Puis on devrait voir s'afficher le nom du fichier img et l'avancement de son téléchargement. (voir figure cidessous)
Page : 9/45
LTSP Retour d'expérience
Si vous n'avez pas de demande DHCP cherchez au niveau du boot du client (cd ou disquette), si le support de boot n'est pas sollicité, voir setup du bios.
Si vous n'avez pas de réponse DHCP message du type « No IP address » (patientez, des fois la première tentative échoue, c'est le cas de mon exemple, simulation qemu), vérifiez votre raccordement au LAN, vérifier si le serveur DHCP est bien démarré (commande ps aux sur le serveur) et les ports bootps en écoute (netstat lataupe ou encor mieux lsof i certaines de ces commandes nécessitent les droits administrateur donc les faire précéder d'un sudo).
Si vous recevez des réponses DHCP mais sans les valeurs attendues et ou sans l'adresse du fichier img à télécharger, vérifier que le serveur DHCP de la box est bien désactivé (pb classique, pouvant survenir après un fonctionnement nominal suite à la raz de la Box car la configuration n'a pas été mémorisée voire pour une d'autres raisons).
Si le téléchargement du fichier ne fonctionne pas, vérifier que le port tftp est bien ouvert (voir plus loin).
Comme indiqué plus haut, en cas de problème on peut utiliser sur le serveur un analyseur du trafic sur le port ethernet.
A noter que j'ai constaté qu'avec certaine carte ethernet le téléchargement est très long, pour ma part j'avais changé de carte. Il semblerait que depuis que j'ai changé de logiciel de boot je n'ai plus ce type de pb.
Figure : Ecran 1 (note : les captures ont été réalisées sur un client LTSP émulé via qemu sur le serveur. Vous remplacez ME : 192.168.1.149 par 192.168.1.150 et vous avez ce qui s'affiche réellement sur le vrai client pris dans notre exemple.)
Phase1 étape2 : initialisation de linux sur le clientEn cas de problème au niveau de l'init de linux (toujours sur le client) on peut se positionner sur la console tty1(Ctrl+Alt+F1) pour suivre les éventuels messages d'erreurs. Le cas échéant et sous réserve
Page : 10/45
LTSP Retour d'expérience
que l'option est active on peut jeter un coup d'oeil dans le syslog du serveur (mais en général si pb init il y a peu de chance que l'on trouve quelque chose).
Suppression du splash, le splash c'est l'image qui s'affiche au démarrage et qui masque les messages d'initialisation qui pourraient affoler les néophytes (ce point est traité en annexe).
Figure Écran 2 Init linux du client LTSP et le fameux splash
Phase1 etape3 Ouverture d'une session X, écran de loginLorsque l'on a l'affichage de l'écran de login c'est que tout s'est bien passé. En cas d'échec à ce niveau on obtient souvent l'écran gris avec la croix, voir exemple cidessous.
Dans ce cas il faut déjà s'assurer que l'on autorise bien les connexions distantes sur le serveur voir annexe.
Page : 11/45
LTSP Retour d'expérience
Figure Ecran 3 : Demande login de connexion sur le serveur mais affiché sur le client (vous me suivez...)
Page : 12/45
LTSP Retour d'expérience
Figure Écran 4 : Le fameux écran gris, on cherche à ouvrir une session X avec le serveur
Page : 13/45
LTSP Retour d'expérience
Figure Écran 5 : Toujours une capture d'écran sur le client, ici on est en session ouverte sur le serveur, on retrouve notre environnement et nos logiciels comme si on était connecté directement.
8) Comment ça marche, zoom détaillé sur les différentes phases et étapesLe serveur LTSP est configuré, démarré et opérationnel :
Phase 11) Avant le démarrage du PC client on peut réaliser les vérifications suivantes ps aux, nestat lataupe
(voir en annexe), on voit notamment que le serveur dhcpd3 est opérationnel et en écoute
Note dans les tableaux suivants je donne un commentaire suivi le cas échéant de la commande linux ayant permis d'obtenir le résultat donné dans la cellule suivante (fond coloré).
Extraits des processus qui nous intéressent : ps auxroot 6203 0.0 0.0 2020 768 ? Ss 08:16 0:00 /usr/sbin/dhcdbd –system.../...dhcpd 6363 0.0 0.1 2868 996 ? Ss 08:16 0:00 /usr/sbin/dhcpd3 q pf
Page : 14/45
LTSP Retour d'expérience
/var/run/dhcp3server/dhcpd.pid cf /etc/ltsp/dhcpd.conf br0 eth0
Extraits : sudo netstat lataupeudp 0 0 *:bootps *:* dhcpd 16209 6363/dhcpd3udp 0 0 *:tftp *:* root 14663 5971/inetd
Le serveur est en écoute pour les requêtes DHCP, il est également en écoute pour les demandes TFTP (pour mémoire port écoute bootps 67 et port udp écoute TFTP 69
2) Mise sous tension du PC client, le BIOS est configuré pour booter sur un CDROM ou Disquette.
3) Via le protocole DHCP le PC client demande : une adresse IP, l'adresse du routeur, un fichier boot... voir également figure : écran 1 cidessus.
Extrait d'une capture réalisé avec le sniffer (ou analyseur) Wireshark
4) Réponse du serveur DHCP
Extraits depuis Wireshark, du paquet IP DHCP OFFER
On notera 2 informations importantes :● le fichier de boot, /var/lib/tftpboot/ltsp/i386/nbi.img● le root path /opt/ltsp/i386
Remarque : le fichier de boot est spécifié dans le fichier de configuration /etc/ltsp/dhcpd.conf on peut à la place de nbi.img spécifier le fichier /var/lib/tftpboot/ltsp/i386/pxelinux.0
En annexe on trouvera des compléments d'information sur la phase de boot dans le cas d'un fichier pxelinux
Côté serveur, ce dernier démarre un daemon tftpd (ci dessous extrait d'un ps aux)root 6879 0.0 0.0 2220 660 ? Ss 08:20 0:00 in.tftpd /var/lib/tftpboot/ltsp
Extraits du fichier de configuration /etc/inetd.conf.../...tftp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.tftpd /var/lib/tftpboot/ltsp
.../...9571 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/ldminfod 9572 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdswapd
Page : 15/45
LTSP Retour d'expérience
2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img
Info complémentaires : la requête de demande TCPD se fait vers le port 69 par contre le serveur utilise en retour un autre port dans notre exemple 39377, ce dernier est ensuite utilisé pour le transfert du fichier.Ci dessous un extrait du fichier syslog Aug 2 08:20:21 uiopdesktop dhcpd: DHCPDISCOVER from 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:21 uiopdesktop dhcpd: DHCPOFFER on 192.168.1.150 to 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:24 uiopdesktop dhcpd: DHCPREQUEST for 192.168.1.150 (192.168.1.11) from 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:24 uiopdesktop dhcpd: DHCPACK on 192.168.1.150 to 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:24 uiopdesktop in.tftpd[6879]: connect from 192.168.1.150 (192.168.1.150)
Comme déjà indiqué, le fichier syslog est le fichier journal qui trace certains événements affectant le système et ou la machine qui l'héberge. Dans l'extrait cidessus on observe la demande DHCP et la réponse du serveur.
5) Téléchargement du fichier img contenant le noyau linux via protocole TFTP, ci dessous extrait du paquet IP TFTP Read Request.
Extrait de Wireshark
Trivial File Transfer Protocol Opcode: Read Request (1) Source File: /var/lib/tftpboot/ltsp/i386/nbi.img
Ecran1 : le serveur DHCP à répondu à la demande du client, le téléchargement du fichier nbi.img est en cours
Plus d'infos : [nbi.img]
6) fin transfert fichier .img, début initialisation linux sur le client, et nouvelle demande DHCP
Page : 16/45
LTSP Retour d'expérience
Ci dessus le splash qui informe sur le début de l'initialisation du linux du client.
Extrait fichier syslog (sur le serveur), lors de l'init du réseau lors de l'init du système du client on observe une nouvelle demande DHCPAug 2 08:20:39 uiopdesktop dhcpd: DHCPDISCOVER from 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:39 uiopdesktop dhcpd: DHCPOFFER on 192.168.1.150 to 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:39 uiopdesktop dhcpd: DHCPREQUEST for 192.168.1.150 (192.168.1.11) from 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:39 uiopdesktop dhcpd: DHCPACK on 192.168.1.150 to 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:40 uiopdesktop dhcpd: DHCPREQUEST for 192.168.1.150 (192.168.1.11) from 00:18:4d:ef:e8:ce via eth0 Aug 2 08:20:40 uiopdesktop dhcpd: DHCPACK on 192.168.1.150 to 00:18:4d:ef:e8:ce via eth0
Capture écran Wireshark:
7) Montage système fichier du client hébergé par le serveur, via connexion TCP port destination 2000, client/serveur nbd
Le serveur est en écoute sur port 2000extrait fichier inetd.conf : pour le port 2000 TCP on a 2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img
Extrait syslogAug 2 08:20:40 uiopdesktop nbdrootd[6884]: connect from 192.168.1.150 (192.168.1.150) Aug 2 08:20:40 uiopdesktop nbd_server[6885]: connect from 192.168.1.150, assigned file is /opt/ltsp/images/i386.img Aug 2 08:20:40 uiopdesktop nbd_server[6885]: Size of exported file/device is 158105600
Extrait ps aux:
Page : 17/45
LTSP Retour d'expérience
nobody 6884 0.0 0.0 1772 492 ? Ss 08:20 0:00 /bin/sh /usr/sbin/nbdrootd /opt/ltsp/images/i386.img nobody 6885 0.1 0.1 3672 1132 ? S 08:20 0:00 /bin/nbdserver 0 /opt/ltsp/images/i386.img r C /dev/null
Extrait (copie manuelle) ps sur clientroot 1977 0.1 0.0 1612 104 ? S 16:55 0:00 nbdclient 192,168,1,11 2000 /dev/nbd0
Extrait wireshark
on observe fin DHCP et ouverture connexion TCP vers port 2000 (traduit en CiscoSCCP) mais qui correspond en fait à nbd
Extrait connexion netstattcp 0 0 uiopdesktop.loca:sieve lcient1:43665 ESTABLISHED root 20747 6884/sh
Pour mémoire port 2000 est traduit sieve dans linux et SCCP dans wireshark ne pas en tenir compte
8) Téléchargement du fichier de configuration du client LTSP
Source File: /var/lib/tftpboot/ltsp/i386/lts.conf
9) Note si dans lts.conf présence « SYSLOG_HOST =192.168.1.11 » dans ce cas on observe des paquets UDP client => serveur sur port syslog..
cidessous extraits du syslog sur le serveur
Aug 2 08:21:09 client1 syslogd 1.5.0#1ubuntu1: restart. Aug 2 08:21:09 client1 kernel: Inspecting /boot/System.map2.6.2416generic Aug 2 08:21:10 client1 kernel: Loaded 27704 symbols from /boot/System.map2.6.2416generic.
../...
dans syslog on a 'client1' si client1 défini dans hosts si non son adresse IP
Page : 18/45
LTSP Retour d'expérience
Capture paquets UDP sur port syslog
.../...
10) sur le client démarrage de ltspfsd (daemon)
Extrait du syslogAug 2 08:21:15 client1 /usr/bin/ltspfsd[3524]: Program started
11) Démarrage startx, initialisation d'une connexion XDMCP et connexion TCP sur port 6006 x11
Copie manuelle, extraits d'un ps aux sur client1.../... /bin/sh /usr/lib/ltsp/screen.d/startx.../... X query 192.168.1.11 xf86config /etc/X11/xorg.conf vt7 :6.0
Extrait netstat :udp6 0 0 [::]:xdmcp [::]:* (correspond au port 177)On notera que la connexion TCP pour x11 se fait à l'initiative du serveur qui pour X11 est en fait client. Voir plus loin en annexe ce sujet.
12) La session X entre le client et serveur a bien fonctionné, le serveur envoi l'écran de login
Page : 19/45
LTSP Retour d'expérience
13) Ouverture de la session sur le serveur avec affichage sur le client x11/tcp (après XDMCP manage).
Page : 20/45
Retour d'expérience
9) Configuration et paramétrage des logiciels et protocoles mis en oeuvreÉléments à configurer ou élément décrit
Nom et emplacement du fichier
Informations Prise en compte modification Documentation
Serveur DHCP et adresse IP des clients
/etc/ltsp/dhcp.conf[exemple en annexe]
Détermine plage ou adresse IP serveurPrécise root pathDonne emplacement image à charger au bootC'est également ici que l'on peut spécifier à une adresse MAC d'un PC client une @IP fixe et un nom.
$ sudo /ect/init.d/dhcp3server restart
uiop@uiopdesktop:/etc/init.d$ sudo ./dhcp3server restart * Stopping DHCP server dhcpd3 [ OK ] * Starting DHCP server dhcpd3 [ OK ]
$ man dhcpdconf
Configuration du client LTSP
/var/lib/tftpboot/ltsp/i386/lts.conf
On y trouve les paramètres par défaut du client, l'adresse serveur LTSP mais également XDMCP voire de journalisation, demande démarrage startx
A l'init du client Pour la signification des options, se positionner sous : /opt/ltsp/i386/usr/share/doc/ltspclientcore/examples et faire un $ zcat ltsparameters.txt.gz
Image boot /var/lib/tftpboot/ltsp/i386/nbi.img
Root path du client /opt/ltsp/i386 / du client ou répertoire racine
Page : 21/45
Retour d'expérience
Éléments à configurer ou élément décrit
Nom et emplacement du fichier
Informations Prise en compte modification Documentation
images /etc/inetd.conf Permet de démarrer nbd (Network Block Device) serveur qui va permettre de réaliser le montage du file système du client depuis le serveur.On y précise l'emplacement de i386.img
Configuration serveur NFS
/etc/exports Précise les répertoires autorisés en accès sudo /etc/init.d/nfskernelserver reload
Configuration serveur inet
/etc/inetd.conf
TFTP /etc/default/tftpdhda Sudo /etc/init.d/tftpdhda restart
GDM /etc/gdm/gdm.conf+/etc/gdm/gdm.confcustom
C'est ici que l'on autorise ou non les connexions distantes et les paramètres XDMCP et XSERVERUtiliser de préférence l'interface graphiqueSystème > Administration > Fenêtre de connexion
Ctrl+Alt+BackspaceAttention cela ferme votre session graphique !
Commandes Explications
ltspbuildclient Permet de créer un système client pour serveur LTSPConcrètement créé un répertoire racine « root path » client et une image système boot. Sous le root path on trouve l'arborescence habituelle d'un système linux. Implicitement le root path est créé sous /opt/ltsp/i386/ et l'image sous
Page : 22/45
Retour d'expérience
/var/lib/ftpboot/ltsp/i386/plus d'information avec man ltspbuildclient
ltspupdateimage
chroot Commande linux permettant d'exécuter une commande ou un shell interactif dans un répertoire racine fermé.sudo chroot /opt/ltsp/i386 permet de passer des commandes « comme si l'on était sous un client ltsp ». Dans cette environnement un cd / vous positionne sous /opt/ltsp/i386/exit permet de quitter ce modeplus d'informations man chroot ou info coreutils chroot
Page : 23/45
LTSP Retour d'expérience
10) Lexique● tftp Trivial file Transfer Protocol : Nom d'un protocole utilisé pour le transfert de fichiers en
UDP/IP, également le nom d'un commande linux permettant de se connecter sur une autre machine pour recevoir ou transférer des fichiers.
● GDM : GNOME Display Management, un des gestionnaires d'affichage pour linux voir en annexe « Complément sur l'affichage graphique »
● PXE : Preboot eXecution Environment, un des protocoles disponible pour permettre le démarrage d'une machine depuis le réseau en allant chercher les fichiers d'initialisation sur un serveur.
● XDMCP : X Display Manager Control Protocol une des techniques disponibles pour une connexion à distance sur une autre machine.
● NFS : Network File System (NFS) is a network file system protocol originally developed by Sun Microsystems in 1983, allowing a user on a client computer to access files over a network as easily as if the network devices were attached to its local disks.(source Wiképédia eng). A priori pas utilisé en LTSP5 et pour l'usage décrit dans ce document. Voir en Annexe le paragraphe « essais »
● NBD : Network Block Device In Linux, a network block device is a device node whose content is provided by a remote machine. Typically, network block devices are used to access a storage device that does not physically reside in the local machine but on a remote one. As an example, the local machine can access a fixed disk that is attached to another computer.(source Wikipédia eng) : Technique utilisée pour accéder via un réseau à un disque hébergé par une autre machine. Si on fait un df sur le client on voit /dev/nbd0 154496 154496 0 100% /rofs
si on fait un ls /rofs on retrouve l'arborescence /opt/ltsp/i386 (son image).Côté serveur un ps aux|grep nbd donnenobody 10698 0.0 0.0 1772 488 ? Ss 20:46 0:00 /bin/sh /usr/sbin/nbdrootd /opt/ltsp/images/i386.img nobody 10699 0.0 0.1 3672 1136 ? S 20:46 0:00 /bin/nbdserver 0 /opt/ltsp/images/i386.img r C /dev/null Côté client on a nbdclient 192.168.1.11 2000 /dev/nbd0
Page : 24/45
LTSP Retour d'expérience
11) Annexes
Comment affecter une adresse fixe au PC serveur SFTPVia le menu Système / Administration / Réseau
Cliquer sur Déverrouiller et saisir son mot de passe.Sélectionner l'interface utilisé pour le LAN dans la majorité des cas Eth0Dans la liste déroulante de configuration, sélectionner Adresse IP statique et compléter le reste comme indiqué ci dessous (mais en l'adaptant à votre configuration).
Page : 25/45
PC – Client léger PC principal – Serveur LTSP
client1
/rofs/
/dev/nbd0
nbdserver nbdclient
i386.img
TCP/IP : 2000
bin/boot/dev/etc/home//.../...
bin/boot/dev/etc/home//.../...
/opt/ltsp/images/
==/opt/ltsp/i386/
LTSP Retour d'expérience
Pourquoi des adresses fixesRéglons immédiatement le problème du réseau LAN et de l'affectation des adresses IP.Rappel des fonctions assurées par la live box. La livebox est un modem ADSL (permet le raccordement via ça ligne téléphonique au réseau internet), mais également un mini switch (2ports ethernet), un routeur, un serveur DHCP et assure le nattage des adresses privées avec les adresses publiques (mais également un firewall et plein d'autres choses...).En général les PC raccordés sur le LAN n'ont pas d'adresse IP fixe, c'est la box qui attribue dynamiquement les adresses en fonction des besoins dans un plan de numérotage privé comme la série 192.168.1.0/24En général quand dans un LAN on a des serveurs (comme le serveur LTSP) il est plus simple d'attribuer une adresse fixe. Dans mon cas je lui ai attribué l'adresse 192.168.1.11On pourrait laisser la fonction serveur DHCP active au niveau de la livebox mais on verra plus loin que cela poserait des problèmes.
On peut contrôler le paramétrage IP en utilisant la commande ifconfig, cette commande permet également de connaître l'état de la liaison éthernet
Exemple résultat de la commande ifconfig, sont surlignés l'interface ici eth0, l'adresse IP de la machine et l'état du lien$ ifconfig eth0 Link encap:Ethernet HWaddr 00:16:17:c7:04:5d inet adr:192.168.1.11 Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6: fe80::216:17ff:fec7:35d/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Packets reçus:1114365 erreurs:0 :0 overruns:0 frame:0 TX packets:3822454 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 Octets reçus:123304250 (117.5 MB) Octets transmis:1037060229 (989.0 MB) Interruption:21 Adresse de base:0x4000
Comment désactiver la fonction serveur DHCP sur la livebox.
1 Se connecter en html à la livebox
Utiliser votre navigateur web et saisir l'adresse de la box (192,168,1,1), saisir admin et son mot de passe
Page : 26/45
LTSP Retour d'expérience
2 Sélectionner le menu «Paramètre LAN et DHCP »
3 Cliquer sur le bouton « Arrêter »
Ce bouton est situé au bas de l'écran, une fois le serveur DHCP arrêté, le bouton est renommé « Démarrer ».
Comment autoriser les connexions à distance (configurer GDM)Via l'interface graphique : menu > Système > Administration > Fenêtre de connexion (ou depuis un terminal, saisir gdmsetup)
Sélectionner l'onglet Distante puis dans Style remplacer « connexion distante désactivé » par identique à locale par exemple.
A noter c'est également dans cet onglet que l'on peut accéder à la configuration XDMCP
Important : Pour la prise en compte des modifications demandées il convient de réinitialiser GDM. Mais attention cela provoque la fermeture de toutes les sessions, donc ne pas oublier d'enregistrer éventuellement et fermer vos documents ouverts, fermer votre session, puis vous positionner l'accès tty1 en faisant Alt+Ctrl+F1, saisir votre login et mot de passe, et enfin saisir : sudo /etc/init.d/gdm restart
En fait il faut se mettre sur tty1 puis faire un /etc/init.d/gdm restart (attention fermeture des sessions ouvertes)
Page : 27/45
LTSP Retour d'expérience
Comment tester le serveur DHCPUtiliser un PC configurer pour obtenir dynamiquement une adresse IP, le raccorder à votre LAN, si vous arrivez à faire un ping 192.168.1.11 c'est que le serveur DHCP fonctionne par contre avec cela on n'a pas vérifié s'il fournit un fichier de boot...
Comment tester DHCP XDMCP GDM1) sur le serveur LTSP si vous avez Terminal Server Client avec xnest installé vous pouvez déjà
vérifier si GDM accepte les connexion externes
Teste d'une session distante en XDMCPEn théorie on devrait pouvoir ouvrir une session sur une machine distante depuis un autre PC en utilisant ce que l'on nomme un terminal X ou plus précisément une émulation terminal X.
Depuis tous les systèmes Linux on peut se connecter à distance sur une autre machine (attention ne pas confondre avec VNC qui est la prise de contrôle d'un PC à distance). Pour cela 2 méthodes soit en mode
Page : 28/45
LTSP Retour d'expérience
graphique soit en mode console. On commence par démarrer le PC, dans un environnement graphique on se trouve normalement en présence d'un écran de login, il existe à ce niveau un menu ou une option qui permet de demander une connexion sur une machine distante via XDMCP. En mode console il suffit de saisir X query 192.168.1.11 (dans mon exemple ceci correspond à l'adresse de la machine distante sur la quelle je souhaite me connecter).
Voir : http://doc.ubuntufr.org/tutoriel/comment_creer_un_terminal_x_ou_recycler_une_vieille_machine?s=xdmcp
En théorie on pourrait utiliser cette technique pour tester notre serveur LSTP. Mais je vous déconseille fortement de le faire, effectivement après plusieurs heures passées à essayer de réaliser cela je me suis rendu compte qu'un bug existait :
https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/150193
Il est paradoxale de constater que LTSP qui utilise les mécanismes d'ouverture d'une session distante en XDMCP fonctionne alors qu'avec un PC ordinaire ça ne marche pas (dans la description du bug quelqu'un explique pourquoi).
Lors de mes tentatives ce que j'ai constaté et essayé (sans succès of course) :
Essai X query 192.168.1.11 On boucle (ecran X) impossible d'obtenir le login
depuis /var/log/auth.log Sep 6 15:20:29 uiopdesktop gdm[12107]: pam_nologin(gdm:auth): cannot determine username
Fonctionnement de PAM http://www.linuxkheops.com/doc/cours/jgourdin/outilstcpip/Linuxpam.html
fichiers de conf /etc/pam.conf ou /etc/pam.d/xxx fichier pour un service donné comme par exemple gdm
Contenu du fichier /etc/pam.d/gdm #%PAM1.0 auth requisite pam_nologin.so auth required pam_env.so readenv=1 auth required pam_env.so readenv=1 envfile=/etc/default/locale auth required pam_permit.so @include commonaccount session required pam_limits.so @include commonsession @include commonpassword
ligne "auth requisite pam_nologin.so" requisite => Doit réussir, on ne continue pas à lire les autres modules, Echec est renvoyé immédiatement.
ajout ligne suivante dans /etc/hosts.allow : gdm: 192.168.1.
modification dans /etc/pam.d/gdm requisite par required
Sur un forum on suggérait pour contourner le bug de dévalider « Son
Page : 29/45
LTSP Retour d'expérience
ESD » dans les préférences du son, sans succès.
J'ai également essayé de remplacer gdm par kdm (pour cela j'ai utilisé la commande sudo dpkgreconfigue kdm)Mais j'ai vite fait marche arrière car à un moment je n'avais plus de gestionnaire graphique et une configuration de mon clavier on ne peut plus bizarre.
Comment activer les messages debug GDMVia l'interface graphique : menu > Système > Administration > Fenêtre de connexion
Sélectionner l'onglet sécurité puis cocher la case « Activer les messages... »
Cette fonction de debug est très riche, il est donc conseillé de ne pas la laisser active pour ne pas remplir inutilement des fichiers log et diminuer la bande passante de votre liaison client/serveur.
Exemples de tracesAug 12 21:43:49 client1 /usr/bin/ltspfsd[3525]: Program started Aug 12 21:43:49 uiopdesktop gdm[5546]: DEBUG: decode_packet: GIOCondition 1 Aug 12 21:43:49 uiopdesktop gdm[5546]: DEBUG: XDMCP: Received opcode QUERY from client ::ffff:192.168.1.150 : 46514 Aug 12 21:43:49 uiopdesktop gdm[5546]: DEBUG: gdm_xdmcp_host_allow: client>hostname is 192.168.1.150 Aug 12 21:43:49 uiopdesktop gdm[5546]: DEBUG: XDMCP: Sending WILLING to ::ffff:192.168.1.150 Aug 12 21:43:56 client1 kernel: [ 85.008119] eth0: no IPv6 routers present Aug 12 21:43:57 uiopdesktop gdm[5546]: DEBUG: decode_packet: GIOCondition 1 Aug 12 21:43:57 uiopdesktop gdm[5546]: DEBUG: XDMCP: Received opcode REQUEST from client ::ffff:192.168.1.150 : 46514 Aug 12 21:43:57 uiopdesktop gdm[5546]: DEBUG: gdm_xdmcp_handle_request: Got REQUEST from ::ffff:192.168.1.150
Page : 30/45
LTSP Retour d'expérience
Aug 12 21:43:57 uiopdesktop gdm[5546]: DEBUG: gdm_xdmcp_host_allow: client>hostname is 192.168.1.150 Aug 12 21:43:57 uiopdesktop gdm[5546]: DEBUG: gdm_xdmcp_handle_request: xdmcp_pending=0, MaxPending=4, xdmcp_sessions=0, MaxSessions=16, ManufacturerID= Aug 12 21:43:57 uiopdesktop gdm[5546]: DEBUG: gdm_xdmcp_display_dispose_check (192.168.1.150:6)
Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: gdm_slave_wait_for_login: In loop Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: daemon/TimedLogin= Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: daemon/TimedLogin= Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Looking up per display value for security/PamStack=gdm Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/PamStack=gdm Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/PamStack=gdm Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Requesting group=security key=PamStack locale=(null) Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/PamStack=gdm Aug 12 21:43:59 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/PasswordRequired=false Aug 12 21:44:12 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: xdmcp/PingIntervalSeconds=15 Aug 12 21:44:27 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: xdmcp/PingIntervalSeconds=15 Aug 12 21:44:29 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/RetryDelay=1 Aug 12 21:44:30 uiopdesktop gdm[7002]: WARNING: Impossible d'identifier l'utilisateur Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/UtmpLineRemote= Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: Warning, invalid device Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: Display device is (null) for display 192.168.1.150:6 Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: Writing failed session attempt utmpwtmp record Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: utmpwtmp: Using username (unknown) Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: utmpwtmp: Using type USER_PROCESS Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: utmpwtmp: Using pid 7002 Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: utmpwtmp: Using time 1218570270 Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: utmpwtmp: Using id 192.(unknown) Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: utmpwtmp: Using line Aug 12 21:44:30 uiopdesktop gdm[7002]: DEBUG: utmpwtmp: Using hostname 192.168.1.150:6
Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Handling message: 'QUERYLOGIN 7002 invite' Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Got QUERYLOGIN invite Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/AllowRoot=true Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: security/AllowRemoteRoot=false
Page : 31/45
LTSP Retour d'expérience
Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: daemon/DisplayLastLogin=false Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: gdm_slave_wait_for_login: end verify for 'invite' Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: greeter/SoundOnLoginSuccessFile= Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: greeter/SoundOnLoginSuccess=false Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: gdm_slave_wait_for_login: got_login for 'invite' Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Sending LOGGED_IN == 1 for slave 7002 Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Attempting to parse key string: debug/Enable=false Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Handling message: 'LOGGED_IN 7002 1' Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Got logged in == TRUE Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Attempting to parse key string: debug/Enable=false Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: Sending LOGIN == <secret> for slave 7002 Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Attempting to parse key string: debug/Enable=false Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Handling message: 'LOGIN 7002 invite' Aug 12 21:45:27 uiopdesktop gdm[5546]: DEBUG: Got LOGIN == invite Aug 12 21:45:27 uiopdesktop gdm[7002]: DEBUG: gdm_slave_session_start: Attempting session for user 'invite'
Comment créer et autoriser un accès shell (login root) sur l'OS du clientImplicitement le système linux du client est configuré pour ne pas permettre de se connecter (ouvrir un shell). Pour pouvoir se connecter root, il convient de modifier le système sur le serveur pour le client. Pour cela on utilise la commande chroot (qui permet de basculer dans l'environnement root du client). Une fois les modifications réalisées il faut recréer une image i386.img qui prenne en compte ces évolutions. Pour cela on utilisera la commande ltspupdateimage.
Détail des opérations
Se positionner sous root du client :uiop@uiopdesktop:~$ sudo chroot /opt/ltsp/i386/ [sudo] password for uiop: root@uiopdesktop:/# ls bin dev home lib mnt proc sbin sys usr boot etc initrd media opt root srv tmp var
Affecter un mot de passe à root :root@uiopdesktop:/# passwd Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
Réactiver le compte root : modifier à l'aide d'un éditeur de texte le fichier /etc/shadow (attention on est toujours « chrooté »), la ligne débutant par root:, la fin de ligne se termine par 7::1: il faut
Page : 32/45
LTSP Retour d'expérience
supprimer le 1 pour avoir 7:::Enregistrer et quitte l'éditeur puis quitter le mode chrootroot@uiopdesktop:/# vim /etc/shadow
root:$1$quelquechoseunesuitedecaractères:14103:0:99999:7:::
root@uiopdesktop:/# exit exit uiop@uiopdesktop:~$
Créer une nouvelle imagesudo ltspupdateimage
Comment supprimer le splash du clientDans le cas d'un boot avec le fichier nbi.img je n'ai pas trouvé la solution.
Par contre dans le cas d'un boot en PXE, soit avec le fichier pxelinux.0, il suffit de modifier le fichier /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default, on supprime splash en fin de ligne pour ne plus avoir l'image affichée lors de l'initialisation. On peut également supprimer quiet pour enrichir les messages affichés au démarrage.
$ cat default DEFAULT vmlinuz ro initrd=initrd.img quiet splash
Comment configurer les firewalls (pares feu)Un firewall est un équipement et ou logiciel dont la fonction est de contrôler les flux IP. Un flux IP est caractérisé notamment par un protocole (UDP, TCP...), une adresse IP source destination et un numéro de port. On niveau d'un firewall on pourra donc mettre en place des filtres pour autoriser ou non certains flux. L'objectif de tout ça c'est de se protéger des méchants. Le firewall ce sont les portes de votre maison. Soit vous laissez tout ouvert soit vous fermez tout soit vous filtrez. Toujours par analogie avec les portes de votre demeure, on a des portes donnant sur l'extérieur et d'autres internes. On verra ci dessous que c'est pareille au niveau d'un réseau IP.
Revenons à notre architecture, en général (surtout pour un usage domestique), il convient de protéger les accès (portes) donnant sur l'extérieur. C'est le rôle attribué au firewall de la box. Je vous laisse le soin de le configurer selon vos besoins (pour ma part j'ai tout interdit, je peux sortir de chez moi, mais personne est autorisé à y entrer).
Concernant le firewall au niveau du serveur LTSP si vous en utilisez un il conviendra de le programmer de telle façon que vous autorisez les flux entre les clients légers et le serveur.
Pour ma part et pour mon besoin j'ai tout laissé ouvert, comme j'utilise iptable pour le vérifier il suffit de lancer la commande sudo iptable L
Page : 33/45
LTSP Retour d'expérience
Un petit rappel sur iptablesPour lister l'état de mes filtres, en faite on peut définir trois « filtres », INPUT/FORWARD et OUTPUT, se reporter au schéma suivant. Le listing suivant me permet de voir que mon firewall au niveau du serveur est désactivé.
$ sudo iptables L Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Page : 34/45
Firewall « iptable » du serveur LTSP
internet
PC principal – Serveur LTSP
Live box
Switch ou hub
PC – Clients légers
Firewall intégré à la box
LTSP Retour d'expérience
Comment vérifier si les différents services du serveur sont opérationnelsOn peut lister les ports en écoute via la commande lsfo i
Exemple :
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
syslogd 5314 syslog 17u IPv4 13614 UDP *:syslog (:514)gdm 5468 root 7u IPv6 13869 UDP *:xdmcp (:177)Xorg 5475 root 1u IPv6 13903 TCP *:x11 (LISTEN) (:6000)Xorg 5475 root 3r IPv4 13904 TCP *:x11 (LISTEN) (:6000)
inetd 5990 root 5u IPv4 14720 UDP *:tftp ()
inetd 5990 root 7u IPv4 14726 TCP *:9571 (LISTEN) ()inetd 5990 root 8u IPv4 14729 TCP *:9572 (LISTEN) ()inetd 5990 root 9u IPv4 14732 TCP *:sieve (LISTEN) (:2000)
dhcpd3 6383 dhcpd 5u IPv4 16007 UDP *:bootps (:67)
Une fois la page de login affichée
nbdrootd 7265 nobody 0u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED) nbdrootd 7265 nobody 11u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED) nbdrootd 7265 nobody 12u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED)
Page : 35/45
LTSP Retour d'expérience
nbdserve 7266 nobody 0u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED) gdm 7286 root 3u IPv4 22176 TCP 192.168.1.11:39264>192.168.1.150:6006 (ESTABLISHED) gdm 7286 root 7u IPv6 13869 UDP *:177 gdmgreete 7294 gdm 3u IPv4 22210 TCP 192.168.1.11:39265>192.168.1.150:6006 (ESTABLISHED) gdmgreete 7294 gdm 12w IPv4 22287 TCP 192.168.1.11:39268>192.168.1.150:6006 (ESTABLISHED) gdmgreete 7294 gdm 16u IPv4 22303 TCP 192.168.1.11:39270>192.168.1.150:6006 (ESTABLISHED) atspire 7296 gdm 9r IPv4 22233 TCP 192.168.1.11:39266>192.168.1.150:6006 (ESTABLISHED) atspire 7296 gdm 10u IPv4 22235 TCP 192.168.1.11:39267>192.168.1.150:6006 (ESTABLISHED)
Une fois la session ouverte
nbdrootd 7265 nobody 0u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED) nbdrootd 7265 nobody 11u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED) nbdrootd 7265 nobody 12u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED) nbdserve 7266 nobody 0u IPv4 22109 TCP 192.168.1.11:2000>192.168.1.150:55565 (ESTABLISHED) gdm 7286 root 3u IPv4 22176 TCP 192.168.1.11:39264>192.168.1.150:6006 (ESTABLISHED) gdm 7286 root 7u IPv6 13869 UDP *:177 gnomekey 7564 invite 7u IPv6 13869 UDP *:177 gnomeses 7566 invite 3u IPv4 23546 TCP 192.168.1.11:36439>192.168.1.150:6006 (ESTABLISHED) gnomeses 7566 invite 19u IPv4 23905 TCP 192.168.1.11:36894>192.168.1.150:16001 (ESTABLISHED) gnomeset 7645 invite 3u IPv4 23625 TCP 192.168.1.11:36440>192.168.1.150:6006 (ESTABLISHED) gnomeset 7645 invite 16u IPv4 23664 TCP 192.168.1.11:36889>192.168.1.150:16001 (ESTABLISHED) metacity 7657 invite 3u IPv4 23932 TCP 192.168.1.11:36450>192.168.1.150:6006 (ESTABLISHED) gnomepan 7660 invite 3u IPv4 23909 TCP 192.168.1.11:36448>192.168.1.150:6006 (ESTABLISHED) gnomepan 7660 invite 16u IPv4 24507 TCP 192.168.1.11:36905>192.168.1.150:16001 (ESTABLISHED) nautilus 7662 invite 3u IPv4 23922 TCP 192.168.1.11:36449>192.168.1.150:6006 (ESTABLISHED) nautilus 7662 invite 24u IPv4 24823 TCP 192.168.1.11:36910>192.168.1.150:16001 (ESTABLISHED) gnomescr 7670 invite 3u IPv4 23767 TCP 192.168.1.11:36444>192.168.1.150:6006 (ESTABLISHED) evolution 7683 invite 3u IPv4 24405 TCP 192.168.1.11:36455>192.168.1.150:6006 (ESTABLISHED) trackera 7685 invite 3u IPv4 24222 TCP 192.168.1.11:36451>192.168.1.150:6006 (ESTABLISHED) gnomecup 7692 invite 3u IPv4 24435 TCP 192.168.1.11:36456>192.168.1.150:6006 (ESTABLISHED) gnomepow 7693 invite 3u IPv4 24350 TCP 192.168.1.11:36453>192.168.1.150:6006 (ESTABLISHED) gnomepow 7693 invite 17u IPv4 24502 TCP 192.168.1.11:36904>192.168.1.150:16001 (ESTABLISHED) trashappl 7714 invite 3u IPv4 24605 TCP 192.168.1.11:36459>192.168.1.150:6006 (ESTABLISHED) trashappl 7714 invite 23w IPv4 24645 TCP 192.168.1.11:36907>192.168.1.150:16001 (ESTABLISHED) mixer_app 7721 invite 3u IPv4 24820 TCP 192.168.1.11:36462>192.168.1.150:6006 (ESTABLISHED) mixer_app 7721 invite 17u IPv4 24879 TCP 192.168.1.11:36912
Page : 36/45
LTSP Retour d'expérience
>192.168.1.150:16001 (ESTABLISHED)
Plus d'infos sur certaines configurationsLes configurations données cidessous le sont à titre d'information elles sont adaptées à mes besoins et mes configurations. A vous de les adapter.
/etc/inetd.confCi dessous un extrait de ma configuration, on notera le paramétrage pour TFTP et notamment la description du répertoire qui héberge les images à télécharger lors du boot du client
inetd est le super serveur internet. Il est en écoute des demandes IP et plus précisément il est en écoute sur les demandes de connexions pour un port donné. Par exemple il écoute le port alloué à TFTP mais également pour sur les ports 9571, 9572 et 2000 (ces éléments ont étés ajouté automatiquement lors de l'installation du paquet ltsp). Dès qu'un de ces ports est sollicité, inetd active le daemon associé par exemple tftpd.
ldminfod est utilisé pour une connexion en LDM (pour mémoire moi j'utilise GDM)
nbdswapd est utilisé pour la fonction swap du client sur le serveur en NBD
nbdroot est utilisé pour monter le système unix du client en NBD
Ce mécanisme évite le démarrage systématique de tous les daemons potentiellement utiles, pour ne les activer qu'en cas de besoin. C'est la raison pour laquelle un ps aux avant le démarrage du premier client est différent d'un ps aux réalisé après démarrage d'un client léger.
Voir aussi man inetd pour plus de présisions
tftp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.tftpd /var/lib/tftpboot/ltsp 9571 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/ldminfod 9572 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdswapd 2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img
Dans le tableau suivant représentation des processus créés suite au démarrage du client, gdm apparraît lors de de l'affichage de l'écran de login
root 6879 0.0 0.0 2220 660 ? Ss 08:20 0:00 in.tftpd /var/lib/tftpboot/ltsp nobody 6884 0.0 0.0 1772 492 ? Ss 08:20 0:00 /bin/sh /usr/sbin/nbdrootd /opt/ltsp/images/i386.img nobody 6885 0.1 0.1 3672 1132 ? S 08:20 0:00 /bin/nbdserver 0 /opt/ltsp/images/i386.img r C /dev/null root 6896 0.0 0.2 14980 2676 ? S 08:21 0:00 /usr/sbin/gdm gdm 6904 3.2 2.5 36276 25200 ? Ss 08:21 0:01 /usr/lib/gdm/gdmgreeter gtkmodule=gail:atkbridge:/usr/lib/gtk2.0/modules/libkeymouselis
Page : 37/45
LTSP Retour d'expérience
gdm 6906 0.1 0.4 13464 4536 ? S 08:21 0:00 /usr/lib/atspi/atspiregistryd gdm 6908 0.2 0.3 15768 3144 ? Ssl 08:21 0:00 /usr/lib/bonoboactivation/bonoboactivationserver acactivate ioroutputfd=13
/etc/exportsVoir aussi man exports,
Le fichier /etc/exports sert de liste de contrôle d’accès pour les systèmes de fichiers à partager avec les clients NFS. Il est utilisé par exportfs(8) pour informer mountd(8) et le démon serveur NFS en mode noyau nfsd(8).
Pour la prise en compte d'une modification de ce fichier il faut relancer nfsd pour cela : /etc/init.d/nfskernelserver reload (status)
Extrait du fichier# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
# Automatically added by ltspserver
#/opt/ltsp *(ro,no_root_squash,async)
# NFS installation client léger
/opt/ltsp/i386 192.168.1.0/24(rw,sync)
/var/opt/ltsp 192.168.1.0/24(rw,sync)
On note que les répertoires /opt/ltsp et /var/opt/ltsp sont accessibles à toutes les machines dont l'adresse IP débute par 192.168.1 en mode lecture et écriture.Note : j'ai volontairement arrêté le serveur DNS (et mis en commentaire les informations du fichier exports) cela n'a eu aucun effet sur le fonctionnement du client léger.
lts.confEmplacement : /var/lib/tftpboot/ltsp/i386
ents [default] #LOCALDEV =true
SCREEN_07 =startx XKBMODEL =pc105 XKBLAYOUT =fr CONSOLE_KEYMAP =fr USE_NBD_SWAP =Y SERVER =192.168.1.11 SYSLOG_HOST =192.168.1.11 XDM_SERVER =192.168.1.11
Page : 38/45
LTSP Retour d'expérience
Note : si on change startx par shell on obtient un access shell du client. Autre moyen de debug par exemple faire un dmesg
dhcpd.confEmplacement : /etc/ltsp/dhcp.conf
cat dhcpd.conf # # Default LTSP dhcpd.conf config file. #
ddnsupdatestyle adhoc; defaultleasetime 600; maxleasetime 7200;
option broadcastaddress 192.168.1.255; option subnetmask 255.255.255.0; option routers 192.168.1.1; option domainnameservers 192.168.1.1;
#### poste du réseau local ### subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.50 192.168.1.100; }
### clients ltsp ### # group { usehostdeclnames true;
nextserver 192.168.1.11;
option rootpath "/opt/ltsp/i386";
# emplacement des images à charger au boot
if substring( option vendorclassidentifier, 0, 9 ) = "PXEClient" { filename "/var/lib/tftpboot/ltsp/i386/pxelinux.0"; }else{ #filename "/var/lib/tftpboot/ltsp/i386/pxelinux.0"; filename "/var/lib/tftpboot/ltsp/i386/nbi.img"; } host client1 { hardware ethernet 00:18:4D:EF:E8:CE; fixedaddress 192.168.1.150; } host client2 { hardware ethernet 52:54:00:12:34:56; fixedaddress 192.168.1.149; } }
Page : 39/45
LTSP Retour d'expérience
gestion dhcp3serverPour connaître l'état du serveur
uiop@uiopdesktop:/etc/init.d$ ./dhcp3server status
Status of DHCP server: dhcpd3 is running.
Pour relancer le serveur suite à modification du fichier de configuration
uiop@uiopdesktop:/etc/init.d$ sudo ./dhcp3server restart
* Stopping DHCP server dhcpd3 [ OK ]
* Starting DHCP server dhcpd3 [ OK ]
Données complémentaires
Boot avec le fichier pxelinux.0 Rappel dans le fichier de configuration /etc/ltsp/dhcpd.conf on spécifie le premier fichier à télécharger sur le client au moment du boot de ce dernier. Deux possibilités sont offertes, soit protocole PXE soit etherboot.
Pxelinux est un chargeur d'amorçage (ou boot loader) de syslinux utilisant le protocole de boot par le réseau, PXE (Preboot eXecution Environment), Pour etherboot on utilisera un fichier spécifique nbi.img voir cidessous.
Analyse des traces Wireshark
pxelinux : Boot loader, utilisant le protocole PXE
default : fichier de configuration, contenu :DEFAULT vmlinuz ro initrd=initrd.img quiet splash
vmlinuz est un noyau (kernel) compressé sous forme d'un fichier exécutable. vmlinuz vm pour virtuel memory, linuz pour linux avec z à la place de x pour signifier compressé.
Page : 40/45
LTSP Retour d'expérience
initrd.img : image d'un mini système initial utilisé lors du boot
syslogdSur le serveur tourne un syslogd avec option r spécifiant qu'il accepte les messages syslog venant du réseau (dans /etc/default/syslogd on a « SYSLOGD="r" ». Sur le client on a également un syslogd d'actif, parcontre si on liste sont /etc/syslog.conf on peut lire *,* @192.168.1.11 ce qui signifie que tous les messages seront envoyés à la machine portant cette adresse donc le serveur. Dans le fichier /var/lib/tftpboot/ltsp/i386/lts.conf on peut préciser ( SYSLOG_HOST =192.168.1.11) l'adresse d'un serveur syslog mais implicitement il prend le serveur ltsp donc à priori on ne peut pas désactiver cette fonction.
nbi.imgnbi.img est un fichier créé pour Etherboot. D'un format spécifique il contient un noyau (kernel) et un mini système initial (root).Le paquet mknbi permet d'avoir à disposition des outils pour créer un nbi (mknbi), lister son contenu (disnbi), avec cette même commande et l'option e on peut extraire le différents composant du fichier.Ci dessous quelques commandes pour comparer les fichiers utilisé avec PXE et nbi.img utilisé en etherboot.
uiop@uiopdesktop:/var/lib/tftpboot/ltsp/i386$ ls rtl total 18316 rwrr 1 root root 1904248 20080410 18:51 vmlinuz2.6.2416generic rwrr 1 root root 899892 20080410 18:51 System.map2.6.2416generic rwrr 1 root root 79964 20080410 18:51 config2.6.2416generic rwrr 1 root root 422607 20080410 18:51 abi2.6.2416generic rwrr 1 root root 4486556 20080614 07:26 initrd.img2.6.2416generic.bak rwrr 1 root root 4486170 20080614 07:27 initrd.img2.6.2416generic rwrr 1 root root 14146 20080614 07:27 pxelinux.0 rrr 1 root root 6385282 20080614 07:27 nbi.img2.6.2416generic lrwxrwxrwx 1 root root 25 20080614 08:13 vmlinuz > vmlinuz2.6.2416generic lrwxrwxrwx 1 root root 25 20080614 08:13 nbi.img > nbi.img2.6.2416generic lrwxrwxrwx 1 root root 28 20080614 08:13 initrd.img > initrd.img2.6.2416generic rwrr 1 root root 230 20080810 20:12 lts.conf drwxrxrx 2 root root 4096 20080811 20:08 pxelinux.cfg
uiop@uiopdesktop:/var/lib/tftpboot/ltsp/i386$ file z * abi2.6.2416generic: ASCII text config2.6.2416generic: ASCII text initrd.img: symbolic link to `initrd.img2.6.2416generic' initrd.img2.6.2416generic: ASCII cpio archive (SVR4 with no CRC) (gzip compressed data, from Unix, last modified: Sat Jun 14 07:27:04 2008) initrd.img2.6.2416generic.bak: ASCII cpio archive (SVR4 with no CRC) (gzip
Page : 41/45
LTSP Retour d'expérience
compressed data, from Unix, last modified: Sat Jun 14 07:26:56 2008) lts.conf: UTF8 Unicode text nbi.img: symbolic link to `nbi.img2.6.2416generic' nbi.img2.6.2416generic: ELF 32bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, corrupted section header size pxelinux.0: data pxelinux.cfg: directory System.map2.6.2416generic: ASCII text vmlinuz: symbolic link to `vmlinuz2.6.2416generic' vmlinuz2.6.2416generic: Linux kernel x86 boot executable ROrootFS, root_dev 0x6801, swap_dev 0x1, Normal VGA
uiop@uiopdesktop:~/tmp/nbi$ disnbi nbi.img Type: ELF Start address: 00010000 Flags:
Segment number 0 Load address: 00000000 Image length: 144 Memory length: 144 Segment number 1 Load address: 00010000 Image length: 5772 Memory length: 76804
Segment number 2 Load address: 00020000 Image length: 0 Memory length: 4208
Segment number 3 Load address: 00100000 Image length: 1892984 Memory length: 7340032
Segment number 4 Load address: 00800000 Image length: 4486170 Memory length: 4486170
Complément sur initrd.imgRappel initrd.img est un mini système compressé utilisé lors du boot du client.Comment lire le contenu d'un initrd, après avoir créé un répertoire tmp/initrd
uiop@uiopdesktop:~$ cd tmp uiop@uiopdesktop:~/tmp$ cp /var/lib/tftpboot/ltsp/i386/initrd.img initrd/initrd.img.gz uiop@uiopdesktop:~/tmp$ cd initrd/ uiop@uiopdesktop:~/tmp/initrd$ ls initrd.img.gz uiop@uiopdesktop:~/tmp/initrd$ gunzip initrd.img.gz uiop@uiopdesktop:~/tmp/initrd$ ls initrd.img uiop@uiopdesktop:~/tmp/initrd$ cpio i makedirectories < initrd.img 25093 blocks uiop@uiopdesktop:~/tmp/initrd$ ls bin conf etc init initrd.img lib modules sbin scripts usr var
Page : 42/45
LTSP Retour d'expérience
uiop@uiopdesktop:~/tmp/initrd$ ls al total 12616 drwxrxrx 11 uiop uiop 4096 20080703 22:11 . drwxrxrx 12 uiop uiop 4096 20080812 06:36 .. drwxrxrx 2 uiop uiop 4096 20080703 22:11 bin drwxrxrx 3 uiop uiop 4096 20080703 22:11 conf drwxrxrx 6 uiop uiop 4096 20080703 22:11 etc rwxrxrx 1 uiop uiop 3355 20080703 22:11 init rwrr 1 uiop uiop 12847616 20080703 22:10 initrd.img drwxrxrx 4 uiop uiop 4096 20080703 22:11 lib drwxrxrx 2 uiop uiop 4096 20080703 22:11 modules drwxrxrx 2 uiop uiop 4096 20080703 22:11 sbin drwxrxrx 12 uiop uiop 4096 20080703 22:11 scripts drwxrxrx 3 uiop uiop 4096 20080703 22:11 usr drwxrxrx 3 uiop uiop 4096 20080703 22:11 var
On retrouve l'arborescence « classique » d'un ro
Compléments sur l'affichage graphiqueAu début le projet W comme Window, => projet X386 => Xfree86 => Xorg
11 version actuelle => X11
Architecture de l'interface graphique
Les éléments de cette architecture :
● le serveur X, il contrôle l'affichage, le clavier et la souris
● le client X, application souhaitant accéder aux services du serveur cad l'affichage, le clavier et la souris.
Le client s'appuie sur des bibliothèques pour offrir un look à l'affichage graphique (environnement de bureau). Les plus connus sont Gnome et KDE.
Page : 43/45
programme
clientXserveurX
XDMCP
TCP/IP
XDMCP
TCP/IP
clavierécran
souris
programme
clientXserveurX
clavierécran
souris
serveurX
serveurX
gdm
XDMCP
LTSP Retour d'expérience
Et GDM dans tout ça ?
GDM Gnome Display Manager, fournit un daemon gdm responsable de la gestion des affichages sur une machine (affichage local et distant). Sont rôle :
● Authentifier un utilisateur
● Démarrer une session (en s'appuyant sur Xserver plus XDMCP dans le cas d'un hôte distant)(GDM runs and manages the X servers for both local and remote logins (using XDMCP).)
● Arrêter une session.
Un PS sur une machine donne (ps aux et pstree a):
root 5463 0.0 0.2 14352 1980 ? Ss 20:36 0:00 /usr/sbin/gdm root 5466 0.0 0.3 14972 3340 ? S 20:36 0:00 /usr/sbin/gdm root 5470 4.5 4.7 52036 45828 tty7 Ss+ 20:36 3:37 /usr/bin/X :0 br audit 0 auth /var/lib/gdm/:0.Xauth vt7 ../..uiop 6520 0.0 0.8 29300 7832 ? Ssl 20:37 0:00 xsessionmanager
gdm ├─
gdm │ └─
Xorg :0 br audit 0 auth /var/lib/gdm/:0.Xauth vt7 │ ├─
xsessionmanag │ └─
gnomesession Starts up the GNOME desktop environment (man), This command is typically executed by your login manager (either gdm)startx initialize an X session, The startx script is a front end to xinit that provides a somewhat nicer user interface for running a single session of the X Window System.
X is the generic name for the X Window System display server. It is frequently a link or a copy of the appropriate server binary for driving the most frequently used server on a given machine. (man xserver)
Essais1) Renommage du répertoire /opt/ltsp/images => lors du démarrage du client, après récupération
adresse serveur, root path, fichier img (/var/lib) => messages d'erreurs Negotiation error server closed connection et erreurs mount. Le processus de démarrage stop avec un prompt (initramfs) autorisant un minimum de commandes linux (faire help). Le répertoire images étant renommé on ne peut plus charger images/i386.img. Ce dernier est l'image de l'arborescence « chroot » du client sur le serveur, sous forme d'un fichier block. Un client nbd (Network Block Device) sur le pc client, accèdera à ce système de fichier grâce au nbdserver sur le pc serveur.
2) Renommage du répertoire /opt/ltsp/i386, rappel ce répertoire est le chroot du client, mais ce n'est pas lui tel que qui est monté par le système de fichier distant c'est une image de ce dernier en l'occurrence i386.img. Donc le fait de renommer ce répertoire voire de le supprimer n'empêche pas le démarrage du client.
3) Modification fichier dhcp.conf pour démarrage à partir du fichier pxe (filename "/var/lib/tftpboot/ltsp/i386/pxelinux.0";). De fait on observe le chargement du fichier vmlinuz, puis initrd.img. vmlinuz serait un kernel compressé et initrd.img un ramdisk ou pour être plus précis un initial ram disk. Le fichier nbi.img est une sorte de compilation de vmlinuz et d'initrd.img
Page : 44/45
LTSP Retour d'expérience
4) Remplacement dans lts.conf startx par shell on a un shell du client (faire un Ctrl+Alt+F1 puis Ctrl+Alt+F7)
5) Arrêt du serveur NFS sans impact dans le fonctionnement du client léger
Page : 45/45