PROJET N 5 : SYSTÈME DE BOOT MULTIPLE HÉTÉROGÈNE SUR RÉSEAU
Sommaire Présentation du projet Description...2 Objectif...2 Cahier des charges Termes techniques......3 Etudes de l'existant...5 Comparaison des solutions envisageables......5 Choix des solutions...6 Méthodes de travail......6 1er axe de recherche: Restauration via le réseau 1 ) Microsoft RIS et WDS...8 2 ) FOG project...10 3 ) Microsoft RIS et WDS...11 4 ) Proposition final...12 2er axe de recherche: le boot via PXE 1 ) DRBL...13 2 ) UDA...14 3 ) Serveur PXE avec livecd...15 4 ) Proposition final...20 Bilan du projet...21 Evolutivité du projet...21 Problèmes rencontrés...21 Bilan personnel...22 Conclusion...22 Annexes...23 1
Présentation du projet Description Ce projet a pour objectif d'étudier un système de démarrage à distance, à travers un réseau local, sur plusieurs OS différents comme Linux (Ubuntu, Debian, etc...) et Windows. Ce projet pourra être déployé dans les salles réseaux du CERI si il est fontionnel. Objectif Dans un souci de gain de temps pendant un TP réseau, il est nécessaire qu'un certain nombre de postes travail soit disponible avec des systèmes d exploitation préinstallés et propres. Pour qu'un TP se déroule dans de bonnes conditions, il y a des règles à respecter : Les OS doivent être propres et optimisés. C'est-à-dire sans configurations ou paramétrages particulièrs, sans aucun daemon lancés, etc Durant une séance de TP, les élèves utilisent un nombre d outils, de paquets ou d applications (wireshark, dhcpd3, vlc, etc) qui peuvent être préinstallés sur chaque poste mais qui varient suivant les TP (Sécurité, Multimédia, Wifi, etc ) Les étudiants se logue en root afin d'avoir la main sur l'ensemble du serveur et ainsi pouvoir travailler librement. Il faut donc que ce critère soit pris en considération durant l'avancement du projet. Les étudiants doivent aussi pouvoir accéder au disque dur local pour sauvegarder leur travail. La finalité du projet est que les postes clients auront la possibilité de choisir au démarrage parmi la liste des systèmes d exploitation accessibles depuis le réseau ou parmi ceux installés sur le disque dur local. 2
Cahiers des charges Termes techniques Le PXE (Pre-boot execution Environment) Le démarrage PXE permet à le démarrage d'une station de travail depuis le réseau en récupérant une image de système d'exploitation qui se trouve sur un serveur par exemple. L'image ainsi récupérée peut être le système d'exploitation brut ou bien le système d'exploitation personnalisé avec des composantes logicielles (suite bureautique, utilitaires, packs de sécurité, scripts, etc...). Une fois cette image "pré-chargée", elle peut éventuellement, en fonction des paramétrages, être installée sur la machine qui a booté en PXE. Pour activer le PXE, il faut auparavant le configurer dans le BIOS. L option se trouve fréquemment dans un menu concernant la carte réseau. Le boot par PXE s'effectue en plusieurs étapes : Recherche d'une adresse IP sur un serveur DHCP/BOOTP ainsi que du fichier à booter Téléchargement du fichier à booter depuis un serveur Trivial FTP. Exécution du fichier à booter. La taille du fichier à booter ne permet pas de booter directement un noyau Linux, par exemple, il faut d'abord booter en PXE, le télécharge et l'exécute en local. Unicast L' unicast est le fait de communiquer entre deux ordinateurs identifiés chacun par une adresse réseau unique (adresse IP). Les paquets de données sont routés sur le réseau suivant l'adresse du destinataire encapsulée dans la trame transmise. 3
Normalement, seul le destinataire intercepte et décode le paquet qui lui est adressé. Exemple d'une adresse IP locale (privée) pouvant servir à une communication unicast : 192.168.1.32 Multicast Le multicast est le fait de communiquer simultanément avec un groupe d'ordinateurs identifiés par une adresse spécifique (adresse de groupe). Il repose sur le protocole IGMP (Internet Group Management Protocol), cela permet à un PC de s'enregistrer à un groupe, le paquet est envoyé au groupe donc à plusieurs utilisateurs. L'avantage de ce système par rapport au classique unicast devient évident quand on veut diffuser de la vidéo par exemple ou un fichier volumineux. En streaming on envoie une image autant de fois que l'on a de connexions simultanées ce qui conduit à une perte de temps, de ressources du serveur et surtout de bande passante. En multicast, le protocole IP utilise les adresses de la classe d'adresses D 224.0.0.1 à 239.255.255.254. Les adresses IP multicast 224.0.0.1 à 224.0.0.255 ont un rôle spécifique à utilisation locale. Exemple d'une adresse IP locale pouvant servir à une communication multicast : 224.0.0.15 Enfin, un groupe multicast est entièrement dynamique c'est à dire qu' une station peut rejoindre ou quitter le groupe à tout moment, ouvert (une station peut émettre un paquet dans un groupe sans en faire partie). 4
Etudes de l'existant Actuellement en salle réseau, la configuration d'une machine est la suivante, un seul disque dur par PC. Celui-ci contient une partition sous Windows XP et 3 partitions Ubuntu (une pour chaque UE nécessitant l'uti). Cependant, cette solution n'est pas des plus agréable à utilisé car d'une séance de TP à une autre, la configuration change sans cesse. Dans les autres salles, on retrouve la solution DBRL qui consiste ici à charger le Grub depuis le réseau sur un serveur et non pas en local. Une fois le Grub téléchargé, on a le choix entre une partition Windows XP et une partition Ubuntu. Ces deux OS sont installés sur la machine locale, on ne fait que les amorcer via le Grub. De plus, j'ai pu constater que lors d'un restauration des OS via Clonezilla, la salle restait inutilisable durant un certains temps (de mémoire une demi journée) car la restauration avec cette technique prend énormément de temps. Comparaison des solutions envisageables Face à cette problématique, plusieurs solutions sont envisageables, voici une énumération des solutions possibles: Une restauration des OS depuis le réseau Adopter une solution de clients léger Démarrer les OS en mode diskless Démarrer les OS via un boot PXE 5
Choix des solutions On peut déjà éliminer la solution des clients légers car elle ne permet pas d'être en root sur les PC de plus cela implique une consommation importante de la bande passante. On élimine également la solution du diskless car cela nécessite l'utilisation d'un SAN (très couteux), n'ayant pas ce genre de matériel à ma disposition, je ne pourrai effectuer des tests avec cette solution. Après quelques recherche effectué sur internet, j'ai choisi de travailler sur deux axes de recherche en parallèle; D'une part la restauration d'os via le réseau et d'autre part le lancement des OS via un boot PXE. Méthodes de travail Ce projet a été entièrement réalisé sur une architecture virtualisé via le logiciel VMware Workstation 7 Ce choix permet non seulement de travailler sur le projet en dehors des horaires d'ouverture de l'iup, mais la raison principal de ce choix c'est surtout que cette méthode de travail offre plus de souplesse par rapport à une architecture physique. En effet, des que l'on effectue une mauvaise manipulation, on peut revenir en arrière très facilement et très rapidement. La première étape consiste à créer une machine virtuel qui servira de master pour tous mes tests. Cette machine sera dupliquer en fonction de mes besoins. Pour cela j'ai donc préparé un PC avec une seule partition Windows XP, j'ai ensuite installé quelques logiciels basique comme firefox, un anti-virus ainsi que la suite Open-office. Afin de ne pas avoir de problèmes avec le Grub lors de la restauration, il n'y a pas de seconde partition dédié à Linux car cela rendrai le processus de restauration instable j'ai donc choisi d'utiliser Wubi, 6
Wubi est un programme permettant d'installer et de désinstaller Ubuntu sous Windows, comme n'importe quel autre programme sous ce système d'exploitation. Cela permet une plus grande souplesse lors des tests de restauration. Ubuntu apparaît ensuite dans l'utilitaire Ajout et suppression de programmes de Windows XP. Ubuntu est installé dans un fichier virtuel créé sous Windows, et une entrée de menu est ajoutée à l'amorceur de Windows afin de permettre de charger l'un des systèmes d'exploitation. Ce mode d'installation d'ubuntu est très pratique pour tester Ubuntu sur du court à moyen terme (TP réseau par exemple), de plus il conserve les fichiers modifiés après un réamorçage de l'ordinateur. D'un point de vu technique Wubi ne modifie que l'amorceur de Windows (NTLDR ou BootMgr) afin d'y ajouter une entrée de menu pour charger son propre amorceur. De cette maniérer Ubuntu est virtualisé au-dessus du système de fichier NTFS natif au lieu d'être sur une partition dédiée. Cette méthode ne modifiant pas la structure des partitions sur le disque, elle limite tout risque de mauvaise manipulation à l'installation ainsi qu'à la désinstallation. La seconde étape consiste à créer des machines virtuels de serveur Windows et Linux qui me serviront de master pour effectuer les tests des différentes solutions. J'ai donc eu à ma disposition les serveurs suivants: un serveur Windows 2003 un serveur Windows 2008 un serveur Linux Debian un serveur Linux Ubuntu Toutes ces VM ont été sauvegardées et dupliquées afin d'avoir une machine totalement vierge et ainsi avoir la possibilité de repartir sur une base neutre très rapidement. 7
1er axe de recherche : Restauration via le réseau 1 ) Microsoft RIS et WDS Dans cette partie, c'est la solution de déploiement de Microsoft qui sera présentée. Celle-ci repose sur un service Microsoft intégré dans Windows server 2003, il s'agit du service RIS (Remote Installation Service) et du service WDS (Windows Deployment Services) disponible sur Windows server 2003 et 2008. Ces services permettent à des ordinateurs dont le BIOS prend en charge le Preboot execution Environment (PXE) d'exécuter de façon distante des variables d'environnement de démarrage. En effet, un PC peut démarrer (booter) de différentes manières (disquettes, disque dur local, ou via le réseau), au moment du boot, une machine va émettre une requête BOOTP sur le réseau. Le BOOTP et le DHCP sont apparentés, une station de travail envoie une requête pour obtenir une adresse IP. Ici c'est le port UDP 4011 qui est utilisé. Une fois reçu, un serveur DHCP fournira une adresse IP à la machine et lui permettra de booter à partir d'un support distant. Dans ce cas, le serveur RIS de Microsoft fournira une image de boot comme celle stockée sur une disquette de démarrage, qui peut être utilisée pour atteindre un fichier image (image au format.vim). De plus, ce service fournit des pilotes (tels que ceux de cartes d'interface réseau) pour les clients. Ceux-ci sont requis pour lancer l'application de choix du système d'exploitation, et lui permette de monter le point de partage (appelé généralement REMINST) où les images sont stockées. Enfin, il sera nécessaire de modifier directement la base de registre du client servant de modèle pour le master afin de changer le SID, le numéro identifiant unique du système, ou, en utilisant l'utilitaire sysprep de Microsoft puis en relancer la machine afin de générer un nouveau SID. 8
NB : Il est possible d'installer ou booter d'autres systèmes d'exploitation grâce au RIS, par exemple une distribution GNU/Linux au travers du LTSP (Linux Terminal Server Project). Le successeur de RIS est Windows Deployment Services (WDS), et est surtout prévu pour réaliser des déploiements à distance des versions existantes de Windows Vista, Seven et Windows Server 2008 ainsi que des versions précédentes Windows XP et Windows Server 2003. WDS est inclus dans Windows Server 2008 en tant que rôle et est disponible pour Windows Server 2003 à partir du service pack 2. Le déploiement peut être totalement automatisé et personnalisé en utilisant des fichiers personnalisés unattend.xml. L automatisation peut comprendre le nommage de la machine, la jonction de la machine dans un domaine, l installation des rôles de server ou de paramètres ou de composants du bureau. Une des nouvelles fonctionnalités dans la variante de WDS est qu elle supporte les déploiements en multicast. Le multicast dans WDS possède une fonctionnalité innovante appelée auto-cast avec laquelle les clients peuvent rejoindre une session multicast qui a déjà démarré. Le server WDS va «envelopper» le multicast pour que n importe quel client qui a rejoint le multicast après le début de la session puisse récupérer les données manquantes. Un déploiement auto-cast va continué tant que des clients continuent à demander la même image. Le multicast de WDS utilise le protocole Internet IGMP. Inconvénient de cette solution : le temps de restauration est très long en unicast, sur mon architecture il faut compter à peu près autant de temps que lorsqu'on fait une installation classique soit un délais compris entre 20 et 25 minutes. Il faudrait pouvoir réaliser des tests sur une architecture physique afin de mesurer le temps de restauration en unicast et en multicast. Par conséquent, cette solution n'a pas été retenu pour respecter le critère de temps. 9
2 ) FOG project FOG est une solution de déploiement d'image open-source basé sur Linux, il est compatible avec Windows XP, Windows Seven et certaines distribution Linux. C'est un outil qui s'administre via une interface web basée sur du PHP. FOG n'utilise pas de disquettes de démarrage, ou des CD, tout se fait via TFTP et PXE. Afin de mettre en place ce type de serveur, on peut soit télécharger une machine virtuel prêt installée soit installer le paquet FOG sur une Debian ou une Ubuntu. Cette machine virtuel est un tout-en-un, en effet sur un seul serveur on y trouve un serveur DHCP, TFTP, Web, PXE cela permet de centralisé sur un seul serveur les services nécessaire au projet. On peut aussi installer les services un à un sur une distribution de notre choix. Ce type de serveur est intéressant car il permet de créer un master (une image de base) qui sera ensuite déployé sur les clients en unicast ou en multicast sous réserve d'avoir du matériel compatible. Les tests avec cette solution ne se sont pas révélé concluant, en effet le déploiement de l'image du master ne fonction pas. La restauration se déroule sans erreur seulement au redémarrage du poste client, l'écran reste noir après quelques recherche internet, je n'ai pas trouver de solutions à ce problème. A cela s'ajoute que le temps de restauration est un peu long (environ 20 minutes pour un seul PC) j'ai donc laissé tombé cette solution. Il existe plusieurs solutions de déploiement/sauvegarde d'images systèmes gratuites, FOG fait parti de ses solutions Open-Source, ses concurrents sont DRBL, Clonezilla, Pratinage... 10
3 ) Acronis Snap Deploy 3.0 Acronis Snap Deploy est une solution logicielle (payante) permettant de déployer un système d'exploitation entièrement configuré sur plusieurs ordinateurs. Ce produit utilisant la technologie des images disque, il convient parfaitement aux installations rapides. Pour cette solution il faut prévoir d'acheter des licences, il faut compter une licence par PC soit un coût d'acquisition égal à 23. Pour le cas d'un salle de TP réseau avec 16 PC cela reviendrai à 368. A cela il faudra ajouter le prix d'un switch 24 ports compatible IGMP pour le multicast soit environ 500. Les composants de l'infrastructure Acronis s'installent sur des ordinateurs Windows. La création d'image, le déploiement et la gestion de l'infrastructure Acronis s'effectuent de façon centralisée à l'aide de la console d'administration Acronis Snap Deploy Management Console. Une image de référence peut être créée sous Windows soit dans l'environnement Acronis (avec un CD) ou par PXE. L'environnement Acronis fournit le mode GUI, le déploiement peut s'exécuter selon un programme de planification s'effectuant dans l'environnement Acronis ou Windows PE. La planification suppose qu'à l'heure fixée, le programme allumera les ordinateurs cibles ayant des adresses MAC prédéfinies grâce à la fonctionnalité BIOS Wake On LAN (WOL). Cette solution est techniquement proche de celle de Microsoft vu précédemment cependant celle-ci est plus rapide. Elle inclus un serveur PXE et permet de déployer en unicast ou en multicast. C'est une solution simple à utilisé mais qui est très efficace, rapide est stable. J'ai pu par exemple restaurer un PC client (virtuel) en moins de 15 minutes en comptant le temps de téléchargement de l'image (3.4Go) ainsi que son installation, le PC a été opérationnel de suite après le reboot. Je précise que ce test à été réalisé en unicast, en multicast les résultat que j'ai pu voir sur internet sont très prometteur sous réserver d'avoir des switchs compatible par exemple j'ai vu le cas d'un LAN contenant 60 postes sous Vista qui ont été déployé en seulement 23 minutes!!! 11
(Temps de téléchargement de l'image + installation de celle-ci sur les 60 postes). 4 ) Proposition final Pour moi, la solution de restauration d'acronis est la solution qui répond à la problématique du projet cependant, le faite que cette solution soit payante peu être un frein à son implémentation à l' IUP. Je pense que dans le cas d'une salle de TP réseau qui contient 16 postes sous XP avec Wubi d'installé, on peut espérer restaurer l'ensemble des machines de la salle en 15 minutes voir moins ce qui permettra d'avoir des machines propres pour chaque TP ayant lieu dans une même journée par exemple. De plus, grâce à la possibilité de planifier la restauration, l'administrateur réseau pourra par exemple sur simple demande d'un professeur ou d'un intervenant, préparer la salle réseau quelques minutes/heures avant le début du cours. Voici un tableau récapitulatif des différentes solutions: 12
2eme axe de recherche : le boot via PXE 1 ) DRBL L'outil DRBL (Diskless Remote Boot in Linux) peut être utilisé de plusieurs manière. Il permet notamment de pouvoir utiliser des clients terminaux, sans système d exploitation, et de les faire démarrer par le réseau à travers une connexion PXE. La grande différence avec LTSP se trouve au niveau de la gestion des ressources. Avec LTSP, les machines clientes font tourner toutes leurs applications sur le serveur, ce dernier devant donc être puissant. Avec DRBL, tous les clients accèdent au serveur pour obtenir les ressources cependant ils utilisent leurs processeurs et leur mémoire vive contrairement à LTSP. Cela permet d'avoir un serveur avec une configuration matériel assez basique (un serveur avec 2go de RAM peut s occuper d une trentaine de PC sous Linux). Ces clients légers ne nécessitent ni disque dur, ni processeur puissant on les appelle «diskless clients». Il peut s'agir d'ordinateurs anciens, obsolètes ou peu puissants. Autres fonctionnalités de DRBL, il permet de cloner une image client et de la déployer à un ensemble de clients, à l aide de Clonezilla server. Enfin, Il est possible d utiliser DRBL pour injecter un système ultraléger en RAM, comme Toutou Linux ou Damn Small Linux, FreeDOS permettant ensuite d utiliser le client sans connexion PXE. C est cette fonctionnalité qui est intéressante pour le projet car DRBL va permettre aux clients de booter un OS installé et configuré sur le serveur. Cependant, DRBL ne permet pas de charger un système d'exploitation Windows par exemple. Cette solution n' a pas été retenue malgrès son potentiel non négligeable. 13
2 ) UDA L' UDA (Ultimate Deployment Appliance) est un serveur DHCP / TFTP / PXE / NFS qui inclus avec un outil de gestion basé sur le Web qui simplifie l'installation d'un système d'exploitation soit sur des machines physiques ou soit des machines virtuelles. L'OS hébergeant ces différents services est CentOS 5.3. On trouve ce serveur sous forme d'une machine virtuel disponible gratuitement sur le site de VMware. Ce serveur est très simple d'utilisation et très peu gourmand en ressources, une fois qu'il est correctement configuré (c'est à dire la partie réseau et la partie identification) toutes les manipulation ce font via l'outil Web. Avec ce serveur le client boot en PXE, il obtient une adresse IP grâce au serveur DHCP puis le client arrive sur la fenêtre du PXE proposant une liste des différents OS Windows et Linux. La particularité de ce serveur c'est qu'il est compatible avec la quasi totalité des OS Windows et Linux. Il permet de récupérer depuis le réseau une image ISO et ainsi de procédé à une installation. L'intérêt d'un tel serveur dans ce projet c'est la possibilité de multiboot OS Linux et Windows. Il fait partir des rares serveurs PXE permettant de lancer des images ISO à travers le réseau, je suppose donc qu'il est en mesure de permette le lancer un livecd Linux ET Windows. De part les tests que j'ai pu effectuer sur ce serveur, je n'ai pour le moment pas réussi à lancer un livecd cependant, j'ai déjà réussi à lancer des ISO de Windows XP et Windows serveur 2003. 14
3 ) Seveur PXE avec livecd Un LiveCD contient un système d exploitation exécutable sans installation, qui se lance au démarrage de l ordinateur. Ce système d exploitation peut être présent sur un support externe (CD, clé USB...). Lorsque le livecd est amorcé, il copie les données nécessaires à son fonctionnement en mémoire vive, en utilisant un RAM disque par exemple. Un livecd n a pas besoin de la présence d un disque dur, bien qu il puisse s en servir comme swap si la mémoire vive est pleine. Il faut savoir qu'un live CD n altère pas les données présentes sur le disque dur, le système retourne dans son état précédent lorsque le livecd est éjecté et que l ordinateur est redémarré. Le plus gros avantages d'un live CD notamment pour ce projet, c'est qu'il permet d avoir un système d exploitation complet et propre (environnement graphique, navigateur web, suite bureautique complète, outils de programmation, logiciels de communication, etc) sur un support externe, il serait intéressant de voir si on peut lancer un live CD depuis un serveur PXE Enfin, le système d exploitation utilisé dans un système livecd est majoritairement une distribution GNU/Linux, il existe des versions Windows mais celles-ci ne sont pas légal donc inutilisable à l'iup. La solution envisageable est de mettre en place un serveur PXE basique mais ce dernier doit être permettre de booter un client avec un livecd Ubuntu que l'on récupère sur le réseau. Pour cela on a besoin de : - un serveur dhcp pour permettre au bios d'accéder au reseau Le serveur DHCP (Dynamic Host Configuration Protocol) permet d'assurer la configuration automatique des paramètres TCP/IP d'un PC. Le but principal de ce protocole est la simplification de l'administration d'un réseau. J'ai donc installer ce servie réseau sur un serveur. 15
Cette machine va servir de base pour toutes les requêtes DHCP, aussi elle doit avoir une adresse IP fixe. - un serveur tfptd-hpa qui permet au bios d'aller chercher l'image du noyau pour booter. TFTP (Trivial File Transfert Protocol) est un protocole simplifié de transfert de fichiers. Il fonctionne en UDP sur le port 69, au contraire du FTP qui utilise lui TCP (sur le port 21). L'utilisation d'udp, protocole "non connecté", implique que le client et le serveur doivent gérer eux-mêmes une éventuelle perte de paquets. On réserve généralement l'usage du TFTP à un réseau local. Les principales simplifications visibles du TFTP par rapport au FTP est qu'il ne gère pas le listage de fichiers, et ne dispose pas de mécanismes d'authentification, ni de chiffrement. Il faut connaître à l'avance le nom du fichier que l'on veut récupérer. De même, aucune notion de droits de lecture/écriture n'est disponible en standard. A cause de ces fonctionnalités absentes, FTP lui est généralement préféré. TFTP reste très utilisé pour la mise à jour des logiciels embarqués sur les équipements réseaux (routeurs, pare-feux, etc.). En général le serveur TFTP permet à l'ordinateur connecté au réseau d'accéder aux fichiers de la machine qui se trouvent dans le dossier pxelinix.cfg. Donc c'est lui qui va fournir les fichiers nécessaires au démarrage. - les fichiers pxe permettent au bios de savoir comment booter boot. Ces derniers ce trouve sur internet ou dans le CD dans le dossier Cette solution semble adapter au projet cependant elle ne marche que pour les livecd Ubuntu (ou autre distribution Linux). Sous Windows cele semble en théorie pratique mais le manque de documentation et d'information à ce niveau empêche d'avoir des résultats concret. 16
Voici en détails les étapes pour mettre en place ce serveur: Dans un premier temps, il faut configuration l'interface du serveur en static : sudo vi /etc/network/interfaces auto eth0 iface eth0 inet static address 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 gateway 192.168.1.1 On install le paquet dhcp3-server sudo apt-get install dhcp3-server sudo vi /etc/dhcp3/dhcpd.conf #DNS ddns-update-style none; #option domain-name-servers 212.27.53.252,212.27.54.252; option domain-name "example.org"; #Baux DHCP default-lease-time 600; max-lease-time 7200; log-facility local7; #reseau subnet 192.168.1.0 netmask 255.255.255.0 { option broadcast-address 192.168.1.255; option routers 192.168.1.1; range 192.168.1.20 192.168.1.30; filename "pxelinux.0"; next-server 192.168.1.1; ping-check = 1; } #on autorise le boot distant allow bootp; allow booting; 17
Configuration du serveur DHCP afin qu'il ecoute sur la bonne interface : sudo vi /etc/default/dhcp3-server INTERFACES="eth0" On redémarre l'interface réseau et le serveur dhcp : sudo /etc/init.d/networking restart sudo /etc/init.d/dhcp3-server restart Ensuite on passe directement à l' installation du paquet tfptd-hpa : sudo apt-get install tftpd-hpa Ici on configuration tfptd-hpa : sudo vi /etc/default/tftpd-hpa Voici les paramètres à modifier: #Defaults for tftpd-hpa RUN_DAEMON="yes" OPTIONS="-l -c -u pcr -s /var/lib/tftpboot sudo chown pcr:pcr /var/lib/tftpboot/ -R sudo chmod 755 /var/lib/tftpboot/ On procède à cette étape à un test du serveur tftp sur une autre machine que le serveur : touch toto tftp 192.168.1.2 tftp> put toto On vérifie ensuite que le fichier test est bien présent sur le serveur : cd /var/lib/tftpboot/test 18
On récupère le fichier netboot de l'ubuntu : wget http://archive.ubuntu.com/ubuntu/dists/gutsy/main/installer- 386/current/images/netboot/netboot.tar.gz On décompresse le fichier : tar -xvzf netboot.tar.gz On monte l'image du livecd d'installation ubuntu Desktop : sudo mount -o loop -t iso9660 /path/to/ubuntu-10.04-desktop-i386.iso /media/cdrom0/ On copie le noyau du livecd pour le boot distant dans le répertoire /var/lib/tftpboot/ cp /media/cdrom0/casper/vmlinuz. cp /media/cdrom0/casper/initrd.gz. On ajoute le fichier de boot depuis l'image CD : vi pxelinux.cfg/default LABEL LiveCD kernel vmlinuz append initrd=initrd.gz boot=casper netboot=nfs nfsroot=192.168.0.1:/media/cdrom0 Installation du serveur nfs sudo apt-get install nfs-kernel-server On partage le cdrom pour l'installation : vi /etc/exports ~$ /media/cdrom0 192.168.0.0/24(ro,async) 19
On redémarre le serveur NFS : etc/init.d/nfs-kernel-server restart Enfin, on redémarre le serveur complètement sudo reboot Cette solution est fonctionnel mais uniquement avec un LiveCD ubuntu. Le client boot en PXE est récupère ainsi le livecd, ce dernier ce charge dans la RAM du PC. Cependant il faut prévoir assez de RAM pour pouvoir effectuer les TP de manière confortable. Un PC client avec 4 Go de RAM devrait suffir. Voici un tableau récapitulatif des différentes solutions: 20
Bilan du projet Bien que travaillant en parallèle sur 2 axes différents, j'ai pu trouver un solution totalement fonctionnel pour la partie restauration et, trouver une piste sur le deuxième axe avec le déploiement de livecd dans les salles de TP réseau. Evolutivité du projet Concernant le restauration des OS via le réseau il serait intéressant de tester le multicast est de mesurer le temps nécessaire à une tel opération. Enfin, pour la partie boot depuis un serveur PXE, les livecd sont à mon sens une alternatives à ne pas négliger, pour les OS Linux il n'y a pas de problèmes à ce niveau là cependant il serait intéressant de trouver une solution légal pour les OS Microsoft. A voir si on ne pourrai pas utilisé une version de Windows XP Embedded (version utilisé dans beaucoup d'automate) dans les salles de TP. Problèmes rencontrés Hormis certains problèmes de configuration et d'installation, le problème que j'ai rencontré c'est au niveau matériel. En effet travaillant sur du matériel personnel qui date de plusieurs années, j'ai perdu l'ensemble de mon architecture virtualité en octobre qui ce trouvait sur le disque dur de mon PC, ce dernier étant arriver en fin de vie, j'ai du le remplacer et refaire mon architecture virtuel. J'aurai notamment aimé avoir en ma possession un Switch compatible IGMP pour pouvoir tester la restauration en multicast. De part les témoignages que j'ai pu lire sur internet, cela semble très prometteur en terme de temps de restauration. 21
Conclusion J'espère que ce projet verra le jour a l'iup ou du moins une partie car, il y a vraiment un travail à réaliser sur les salles TP réseau, à titre indicatif, durant ce semestre ils nous ait arrivé à moi ainsi qu'aux étudiants de ma promotion de perdre facilement une heure sur une séance de TP de trois heures du faite que les machines sont manipulé par un grand nombre d'étudiants et que nos machines ne sont pas propres au début de chaque séance de TP. Bilan personnel Ce semestre et ce projet m ont permis d améliorer mes connaissances sur les serveurs Linux et Windows plus particulièrement sur le PXE et la restauration de postes clients via le réseau. J ai pu grâce à ce projet, me faire une idée plus claire de certains tâches effectués par un d administrateur réseau. De plus, le fait de travailler seul sur ce projet m'a permis d'être en autonomie totale, d'être méthodique et de pouvoir gérer mon temps de travail. Ce fut une expérience enrichissante qui je suis sur me sera bénéfique dans un futur proche. J'ai pu prendre conscience que la rigueur, dans la documentation mais aussi dans l analyse et la mise en place de procédures sont très importantes pour pouvoir faire le tri des informations disponibles sur internet et ainsi orienter le choix final vers une solution qui est en adéquation avec la problématique initial. De plus, cela permettra aux futur étudiants qui choisiront ce projet d'avoir des pistes à explorer et ainsi faire aboutir le projet et de permettre un avancement supplémentaire et ne pas reprendre le projet au départ. 22