\documentclass[a4paper,11pt]{article} \usepackage{html} \usepackage[latin1]{inputenc} \usepackage[T1]{fontenc} \usepackage[francais]{babel} \usepackage{eurosym} \usepackage{listings} \usepackage{color} \usepackage{indentfirst} \usepackage{alltt} \usepackage{moreverb} \usepackage[dvips]{graphicx} \definecolor{green}{rgb}{0,0.8,0} \title{Installation de PC diskless} \author{ Alban Cr\'equy} \date{\'Et\'e 2003} \begin{document} \maketitle \tableofcontents \clearpage % ################################################## \part{Sujet du stage} % ################################################## Des m\'ethodes de boot pour des PC Linux sans disque ont \'et\'e mises au point. Je dois faire une synth\`ese de ces m\'ethodes, rechercher de nouvelles m\'ethodes et les mettre au point, puis \'editer un manuel utilisateur de toutes ces m\'ethodes. % ################################################## \part{Description de la probl\'ematique} % ################################################## Un parc informatique contenant plusieurs dizaines/centaines/milliards (rayer les mentions inutiles) de PC ne peut pas \^etre g\'er\'e sans m\'ethode. Le but de l'administrateur est de g\'erer les diff\'erentes ressources sur le r\'eseau. Ces ressources sont: \begin{enumerate} \item Espace de stockage de donn\'ees (disques durs) \item Puissance de calcul (processeurs) \item Capacit\'e du r\'eseau (bande passante) \item Serveurs (machines plac\'ees dans la salle des machines) \item Terminaux (machines utilis\'ees directement par l'utilisateur) \end{enumerate} Il existe plusieurs grands mod\`eles pour g\'erer ces ressources. Je vais d\'ecrire bri\`evement trois cat\'egories: celle des clients lourds, celle des terminaux X et celle des PC diskless (PC sans disque). \section{Clients lourds} \paragraph{Principe:} installation du syst\`eme GNU/Linux sur les disques durs de chaque PC. \paragraph{Inconv\'enients:} \begin{enumerate} \item L'administration est tr\`es fastidieuse. En effet, il est n\'ecessaire de passer sur chaque machine pour mettre \`a jour le syst\`eme. \item Par cons\'equent, les syst\`emes install\'es sur les clients lourds ne sont jamais \`a jour. \item Les syst\`emes sont h\'et\'erog\`enes. L'administration est donc plus difficile. \end{enumerate} \paragraph{Avantage:} Les applications s'\'ex\'ecutent en local sur le PC; les serveurs ne sont donc pas surcharg\'es. \section{Terminaux X} \paragraph{Principe:} la machine est un terminal X ou PC qui sert juste \`a afficher les fen\^etres des programmes de l'utilisateur sur un \'ecran. La machine ne fait quasiment aucun calcul et tout est centralis\'e sur les serveurs. \paragraph{Inconv\'enients:} \begin{enumerate} \item Cela surcharge des serveurs car toutes les applications s'\'execute sur les serveurs. Les applications semblent donc tourner moins vite. \item Les terminaux X n'ont aucune puissance de calcul utilisable. Pour le m\^eme prix, un PC est plus puissant. \end{enumerate} \paragraph{Avantages:} \begin{enumerate} \item L'administration est centralis\'ee. C'est donc plus pratique que les clients lourds. \item Un terminal X ne fait aucun bruit. \item Un terminal X ne chauffe quasiment pas. \end{enumerate} \section{PC diskless} \paragraph{Principe:} Un PC sans disque ou "PC diskless" est un poste de travail dont le disque s'il en a un, n'est pas dédié au système Linux. Le PC diskless peut d\'emarrer par diff\'erents moyens que j'expliquerai par la suite (disquette, CD, carte r\'eseau PXE). Le syst\`eme d'exploitation est r\'ecup\'er\'e sur un serveur de diskless (voir glossaire page ~\pageref{def:serveurdediskless}). \paragraph{Inconv\'enient:} \begin{enumerate} \item Il faut trouver des m\'ethodes de boot. Cela fait partie de mon stage. \item La m\'ethode n'est pas encore tout \`a fait au point. \end{enumerate} \paragraph{Avantages:} \begin{enumerate} \item Toutes les applications s'\'ex\'ecutent sur le PC diskless (les serveurs sont donc peu charg\'es). Utiliser des PC diskless est donc plus rapide qu'utiliser des terminaux X. \item De plus, toutes les donn\'ees sont centralis\'ees sur les serveurs. L'administration des PC diskless est donc plus facile que l'administration des clients lourds. \item C'est moins co\^uteux car on n'a pas besoin de disque. \item Moins bruyant car il n'y a pas de disque. \item Les PC diskless chauffent moins car il n'y a pas de disque. \item Les PC diskless peuvent \^etre utilis\'es comme grille de calcul (voir glossaire page ~\pageref{def:grilledecalcul}) \end{enumerate} % ################################################## \section{Besoins du LAOG} % ################################################## \subsection{Population du laboratoire} Les besoins de l'ensemble de la population du laboratoire est homogène, hormis l'administration du laboratoire qui travaille sur des plateformes dédiées à la bureautique. La population, pour 80\% du laboratoire a besoin d'un poste de travail entièrement géré par l'administrateur : les doctorants, la majorité des chercheurs, les stagiaires et invités et les étudiants de l'école doctorale. Seules les machines dédiées au pilotage de manips ou au développement d'instruments sont gérées par les ingénieurs concernés. 40\% de la population se renouvelle régulièrement (stagiaires, invités, étudiants, doctorants) et les équipements des bureaux sont amenés à bouger, ce qui nécessite de poser des postes de travail banalisés et non encombrants. \subsection{Environnement} La nécessité est d'avoir des postes légers, non bruyants, banalisés, configurés à distance par l'administrateur, dont le nombre doit évoluer avec l'augmentation du nombre de personnes du laboratoire : une centaine actuellement. Le type des postes évolue selon le marché et la technologie. Les répertoires des utilisateurs (\$HOME) sont centralisés sur une machine serveur NFS, concentrés sur une baie RAID, donc indépendants des postes de travail. La mise à jour par l'administrateur, du système centralisé entraine une mise à jour de tous les postes de travail à la fois. Tous les logiciels hors licences doivent tourner en local, et \^etre accessibles via NFS sur un serveur d'applications. Les grands espaces disques n\'ecessaires aux simulations, modélisations, dépouillement de données sont servis par des serveurs de RAID. % ################################################## \section{Historique des PC diskless au LAOG} % ################################################## \subsection{Avant} Les PC bootaient sur une disquette contenant LILO (voir glossaire page ~\pageref{def:lilo}) et le noyau Linux. Tous les syst\`emes de fichiers \'etaient mont\'es par NFS (voir glossaire page ~\pageref{def:nfs}). La disquette allait donc chercher les fichiers syst\`eme sur le serveur. Mais depuis, les noyaux Linux sont devenus trop grop pour \^etre mis sur une disquette. Chercher \`a r\'eduire l'espace utilis\'e par le noyau sur la disquette n'est pas une solution car le noyau risque de continuer \`a grossir au fil du temps. Cette m\'ethode n'est donc plus utilisée. \subsection{\'Etat actuel} Les PC diskless d\'emarrent sur le r\'eseau en utilisant le protocole de d\'emarrage PXE (voir glossaire page ~\pageref{def:pxe}). PXE permet de booter sur le r\'eseau. Concr\'etement, au d\'emarrage du PC diskless, le BIOS (glossaire page ~\pageref{def:bios}) donne la main au programme PXE qui se trouve sur la carte r\'eseau. Ce programme fait une requ\^ete DHCP (glossaire page ~\pageref{def:dhcp}) pour trouver un serveur qui lui donnera son adresse IP (glossaire page ~\pageref{def:adresseip}) et le nom du serveur qui lui permettra de t\'el\'echarger le noyau avec TFTP (glossaire page ~\pageref{def:tftp}). Ce protocole s'est bien d\'evelopp\'e: une bonne partie des cartes r\'eseaux du LAOG supportent PXE. Toutes les nouvelles cartes r\'eseaux le supporte. \subsection{Ce qui reste \`a faire} Mais toutes les cartes r\'eseaux ne supportent pas PXE. Il faut donc trouver d'autres m\'ethodes pour ces PC. De plus, la m\'ethode utilis\'ee pour administrer les diskless doit \^etre am\'elior\'ee pour corriger certains probl\`emes et faciliter l'administration. % ################################################## \part{Solutions de boot} % ################################################## \section{Qu'est-ce que le boot?} Lorsqu'un PC d\'emarre, il doit trouver son syst\`eme d'exploitation, le charger et l'\'ex\'ecuter. C'est ce qu'on appelle le boot. Dans le cas de GNU/Linux, la m\'ethode la plus employ\'ee est la suivante: \begin{enumerate} \item Le BIOS (glossaire page ~\pageref{def:bios}) poss\`ede plusieurs options de d\'emarrage: disque dur, CD, etc. La valeur la plus courante de cette option est de d\'emarrer sur le disque dur. \item Le BIOS cherche donc sur le disque dur une zone qu'on appelle le MBR (pour Master Boot Record). Cette zone contient le chargeur de d\'emarrage. Il s'agit de GRUB ou de LILO. Le BIOS donne la main \`a ce programme. \item Le chargeur de d\'emarrage trouve le noyau Linux sur le disque dur, le charge en m\'emoire puis lui donne la main en lui passant des param\`etres. \item Linux d\'emarre et tient compte de ces param\`etres pour savoir que faire. \end{enumerate} Mais dans le cas d'un diskless, le disque ne doit pas \^etre utilis\'e pour h\'eberger le syst\`eme d'exploitation. Il faut donc trouver d'autres m\'ethodes de boot. La m\'ethode utilis\'ee au LAOG actuellement est la m\'ethode de boot par r\'eseau avec le protocole PXE (glossaire ~\pageref{def:pxe}). Je vais d'abord d\'ecrire cette m\'ethode puis les diff\'erentes m\'ethodes que j'ai trouv\'e. \section{Boot sur la carte r\'eseau PXE} Une documentation sur PXE existe sur: \htmladdnormallink{http://clic.mandrakesoft.com/documentation/pxe/}{http://clic.mandrakesoft.com/documentation/pxe/} Ce paragraphe est tir\'e de: \htmladdnormallink{http://sari.inpg.fr/rubriques/themes/zone\_publique.groupe\_linux/diskless/serveur-diskless.html}{http://sari.inpg.fr/rubriques/themes/zone\_publique.groupe\_linux/diskless/serveur-diskless.html} \subsection{Principe du boot en r\'eseau} Le boot réseau consiste pour une machine cliente à obtenir auprès d'une machine serveur son identité réseau (son adresse IP, son adresse de diffusion, son masque réseau, son nom de machine, son nom de domaine, les noms des serveurs DNS, l'adresse de la passerelle) et des informations sur le serveur de boot (l'adresse IP du serveur et le nom du fichier de boot). La machine cliente doit être raccordée au réseau et positionnée de manière à booter d'abord sur son interface réseau (UNDI/PXE): ceci est à positionner dans le BIOS du PC. Le protocole PXE indique les étapes nécessaires pour le démarrage effectif de la machine client: \begin{enumerate} \item Émission par le client d'une requête DHCPDISCOVER de demande de son identité réseau ; cette requête contient son adresse MAC. Réception par le serveur dhcp de la requête qui la traite en recherchant une correspondance de l'adresse MAC dans son fichier dhcpd.conf, puis envoie au client une réponse DHCPOFFER contenant son identité réseau si elle a été trouvée. \item Réception par le client et positionnement de ces paramètres (equivalent ifconfig) puis envoie au serveur une requête DHCPREQUEST demandant les informations de boot \item Réception par le serveur de la la requête DHCPREQUEST qui la traite en recherchant les infos demandées dans son fichier dhcpd.conf, puis envoie au client une réponse DHCPPACK contenant l'adresse IP du serveur TFTP et le nom du fichier de boot (pxelinux.0). \item Réception par le client de la requête DHCPPACK qui établit une connexion au serveur TFTP (port 69) et demande le chargement du fichier indiqué. \end{enumerate} Après le chargement, exécution de ce fichier qui, toujours par une connection TFTP : \begin{enumerate} \item chargera un fichier de configuration se trouvant dans un répertoire pxelinux.cfg ; celui-contient le nom du noyau et les options de démarrage de celui-ci ; \item chargera ensuite le noyau et les autres fichiers nécessaires au boot (fichier initrd). \end{enumerate} Le noyau est alors démarré... Le fichier initrd est un fichier système de fichiers compressé ; le système de fichiers contient les modules noyau et toute autre chose utile. \subsection{Installation et configuration du "bootloader" : pxelinux} Le programme de boot (bootloader) est celui qui chargera en fait le noyau linux en mémoire. Pour PXE, il faut un bootloader "intelligent" capable de charger un noyau et des images initrd, de les décompresser. Après la création de /diskless/tftpboot dans lequel on a construit les systèmes nécessaires aux diskless clients de ce serveur, il faut créer un répertoire pxelinux.cfg (ceci est normalement d\'ej\`a fait par le script dkl-init-serveur.sh, cf. partie Installation). \begin{enumerate} \item cd /tftpboot \item mkdir pxelinux.cfg \end{enumerate} pxelinux se trouve dans l'outil syslinux (la version utilisée est la 1.72). Installer syslinux-1.72.tar.gz sous /usr/local, depuis http://www.kernel.org/pub/linux/utils/boot/. Je l'ai ajout\'e dans l'archive diskless-kit.tar.gz (cf. partie Scripts en annexe). \begin{enumerate} \item cd /tftpboot \item cp /usr/local/syslinux-1.72/pxelinux.0 /tftpboot \end{enumerate} Dans le répertoire /tftpboot/pxelinux.cfg, sera édité un fichier par PC diskless qui bootera par PXE. Chaque fichier a pour nom le numéro hexadécimal de l'adresse IP du PC (Ex. C3DC4F0C: C3 pour 195,DC pour 220, 4F pour 79 et 0C pour 12). Ex. de fichier "bootloader": \begin{verbatim} #gagXXX DEFAULT bzImage-diskless-pxe1 APPEND root=/dev/nfs hdg=ide-scsi devfs=mount ip=::::::dhcp nfsroot=n0-IP-serveur-nfs:/diskless/tftpboot/195.220.79.XXX PROMPT 1 TIMEOUT 50 \end{verbatim} La première ligne donne le nom du noyau linux (bzImage...) qui doit être placé sous /tftpboot. La seconde ligne donne les options du noyau. Pour les PC avec graveur de CD, l'option hdg=ide-scsi ==> le noyau ne reconnaîtra plus le graveur en tant que périphérique IDE (et donc plus en tant que /dev/hdg mais en tant que /dev/scd0). Le noyau a été crée spécifiquement pour le diskless à partir du fichier de configuration qui a servi à créer le noyau du serveur. Pour visualiser le contenu d'une image : \begin{enumerate} \item mv initrd.img initrd.img.gz \item gunzip initrd.img.gz \item mount /tmp/initrd.img /mnt -t ext2 -o loop \item ls /mnt \end{enumerate} \section{Boot avec PxeGrub} \subsection{Principe} Il n'est plus possible de mettre le noyau sur une disquette car les nouveaux noyaux sont devenus trop gros. Une solution est donc de mettre le noyau sur le serveur et de trouver un moyen de t\'el\'echarger ce noyau par le r\'eseau. Une solution est d'utiliser PxeGrub (page ~\pageref{def:pxegrub}). Le diskless d\'emarre sur une disquette. Cette diskette contient PxeGrub, mais pas le noyau linux. PxeGrub va télécharger le noyau sur un serveur. Puis ce noyau est démarré et les systèmes de fichiers sont montés par NFS. \subsection{Avantages} \begin{enumerate} \item Permet de démarrer un noyau à partir d'une disquette, même si le noyau ne tient pas sur la disquette car PxeGrub va télécharger le noyau sur le serveur de diskless. \item Pas de contrainte sur la taille du noyau. \item Pas besoin de carte réseau compatible PXE. \item PxeGrub est lancé, soit en mode interactif (l'utilisateur choisit s'il veut démarrer sur le réseau ou sur le disque local, ou autres) soit en mode automatique (PxeGrub démarre sur le réseau sans rien demander à l'utilisateur). On peut donc proposer un menu \`a l'utilisateur. \end{enumerate} \subsection{Inconv\'enient} La carte réseau doit être reconnue par PxeGrub. Or, une partie des cartes réseaux du LAOG n'est pas reconnue par PxeGrub. Toutes les cartes r\'eseaux reconnues par Linux ne sont pas reconnues par PxeGrub. La liste des cartes r\'eseaux reconnues par PxeGrub n'est pas la m\^eme que la liste des cartes compatibles PXE (\,ca n'a rien \`a voir). Pour qu'une carte r\'eseau soit compatible PXE, il faut que le protocole PXE soit programm\'e dans la puce de la carte r\'eseau. Selon les mod\'eles, une carte r\'eseau peut ou pas \^etre compatible PXE. Mais pour qu'une carte soit reconnue par PxeGrub, il faut que les d\'eveloppeurs du logiciel PxeGrub \'ecrive le pilote de cette carte pour PxeGrub. PxeGrub est en cours de d\'eveloppement et tous les pilotes ne sont pas disponibles. \subsection{Conclusion} Cette méthode n'est pas retenue car les PC diskless doivent marcher sur tous les PC du LAOG. \subsection{Liens} Liste des cartes compatibles GRUB: \htmladdnormallink{http://etherboot.sourceforge.net/db/}{http://etherboot.sourceforge.net/db/} \section{D\'emarrage d'un PC diskless \`a partir du disque dur} Un "PC diskless" peut tr\`es bien avoir un disque dur. PC diskless veut simplement dire que le disque dur n'est pas utilis\'e pour le syst\`eme. Dans cette partie, nous allons utiliser le disque dur pour d\'emarrer le syst\`eme mais on utilisera toujours NFS-Root (la racine du syst\`eme sera mont\'ee par NFS). L'espace utilis\'e sur le disque dur du PC diskless sera environ 2 Mo. Le noyau linux sera plac\'e sur une partition d\'ej\`a existante (ext2, ext3, ou vfat...) dans le r\'epertoire /Grub. Grub sera install\'e sur le disque dur et proposera au d\'emarrage de la machine un menu. L'utilisateur pourra choisir entre booter sur le r\'eseau ou d\'emarrer le syst\`eme pr\'esent sur le disque dur, s'il existe. Grub peut ainsi d\'emarrer de nombreux syst\`emes d'exploitation, dont Linux et Windows. \subsection{Installation de Grub} Avant de commencer, assurez vous qu'un partition est d\'ej\`a pr\'esente sur le disque dur avec suffisamment d'espace libre (2 ou 3 Mo). \begin{enumerate} \item D\'emarrer sur le CD d'installation de Mandrake. \item Taper F1, imm\'ediatement au d\'emarrage puis taper rescue. \item Choisir "Go to console". \item \'Eventuellement, taper loadkeys fr si vous utilisez un clavier fran\,cais. \item Monter une partition du disque dur sur /mnt/disque. \item cp -a /boot/grub /mnt/disque \item Lancer grub \item Taper find /grub/stage1. Noter le r\'esultat de la commande (par exemple "(hd0,0)"). La commande find indique o\`u sur quelle partition se trouve le fichier /grub/stage1 selon la notation Grub. Grub lit toutes les partitions de tous les disques durs pour indiquer le r\'esultat. Aucune modification n'est effectu\'ee \`a cette \'etape. \item Taper "root (hd0,0)" (ou adapter selon le r\'esultat de la commande find). La commande root indique que le fichier de configuration se trouve sur la partition (hd0,0) \item Taper "setup (hd0)". La commande setup installe Grub sur le premier disque (hd0). \item Taper "quit" pour sortir de Grub. \end{enumerate} Grub est maintenant install\'e. \subsection{Fichier de configuration de Grub} Il faut maintenant changer son fichier de configuration. Celui-ci se trouve sur /mnt/disque/grub/menu.lst Voici un exemple de fichier de configuration: \begin{verbatim} timeout 30 default 0 title Demarrer en tant que diskless kernel (hd0,0)/grub/vmlinuz-diskless root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=/diskless/tftpboot/%s title Demarrer a partir du disque dur kernel (hd0,0)/boot/vmlinuz root=/dev/hde1 devfs=mount vga=788 initrd (hd0,0)/boot/initrd.img title Disquette root (fd0) chainloader +1 \end{verbatim} Grub num\'erote les disques durs \`a partir de 0 (hd0, hd1) tandis que Linux les num\'erote \`a avec des lettres partir de a (hda, hdb). Les partitions sont aussi num\'erot\'ees \`a partir de 0 ((hd0,0), (hd0,1)) tandis que Linux commence \`a 1 (hda1, hda2). Avec ce fichier de configuration, l'utilisateur aura le choix entre trois d\'emarrage possibles: \begin{enumerate} \item D\'emarrer en tant que diskless \item D\'emarrer \`a partir du disque dur \item D\'emarrer \`a partir d'une disquette \end{enumerate} \subsection{Copie du noyau du diskless} Il faut ensuite copier le noyau du diskless sur /grub/vmlinuz-diskless. Le r\'epertoire /grub (sur le disque du diskless) doit donc contenir ces 4 fichiers: \begin{enumerate} \item menu.lst \item stage1 \item stage2 \item vmlinuz-diskless \end{enumerate} \subsection{R\'esum\'e} Le PC diskless d\'emarre sur le disque dur. Sur ce disque dur, il y a Grub. Celui-ci propose \`a l'utilisateur de d\'emarrer en tant que diskless. En s\'electionnant ce choix, Grub charge le noyau qui se trouve dans le r\'epertoire /grub du disque dur. Les modules et la racine du syst\`eme se trouvent comme d'habitude sur le serveur de diskless. \section{CD bootable} Un CD bootable est un CD, qui, ins\'er\'e au d\'emarrage de l'ordinateur permet de charger un syst\`eme d'exploitation. Ce syst\`eme d'exploitation peut \^etre sur le CD (comme par exemple le syst\`eme Knoppix) ou il peut \^etre t\'el\'echarg\'e sur un serveur (c'est le cas pour un PC diskless). J'ai \'etudi\'e plusieurs m\'ethodes pour faire un CD bootable. Ma premi\`ere piste \'etait de faire un CD au format El Torito. Puis j'ai trouv\'e un outil bien pratique: isolinux. \subsection{El Torito} Première possibilité: faire un CD au format "El Torito". \subsubsection{Avec l'image d'une disquette} Un CD au format El Torito est un CD bootable qui contient un fichier image d'une disquette ou d'un disque dur. La technique est la même que pour créer une disquette ou un disque bootable. En fait, il faut mettre un fichier image d'une disquette (ou d'un disque) sur le CD et mettre un pointeur vers cette image au début du CD. Cela se fait facilement avec une option du logiciel de cr\'eation d'image de CD: mkisofs. \subsubsection{\'Emulation} En fait, quand le BIOS doit d\'emarrer sur le CD, cela ne se passe pas comme pour une disquette ou un disque dur. Le BIOS charge l'image de la disquette ou du disque dur qui se trouve sur le CD et boote dessus en \'emulant une disquette (ou le disque dur). Cette \'emulation se fait en changeant les fonctions du BIOS qui permettent d'acc\'eder \`a la disquette ou au disque dur. Ainsi, une fois le syst\`eme d'exploitation charg\'e, il croit qu'il se trouve sur une disquette (ou un disque dur). \subsubsection{Probl\`emes} Mais cette technique est très contraignante: si on utilise une image de disquette, on reste limité aux 1,44Mo (donc impossible d'utiliser de gros noyaux) et utiliser une image d'un disque est assez compliqué. En effet, bien qu'il existe des outils sous GNU/Linux pour créer un fichier image d'une partition assez facilement (exemple d'outils: dd, mkfs, mount -o loop), je n'ai pas trouvé d'outils pour créer un fichier image d'un disque. Lorsque j'essaie de partitionner l'image de mon disque avec fdisk, ce dernier me demande le nombre de cylindre de l'image disque et je n'ai pas la réponse. De plus je ne sais pas comment monter avec mount la partition qui se trouve dans l'image du disque. \subsubsection{Conclusion} Cette premi\`ere possibilit\'e n'est donc pas utilis\'ee. \subsubsection{Liens} Description du format de CD El Torito: \htmladdnormallink{http://www.phoenix.com/resources/specs-cdrom.pdf}{http://www.phoenix.com/resources/specs-cdrom.pdf} \subsection{Introduction \`a Isolinux} Le site de isolinux: \htmladdnormallink{http://syslinux.zytor.com/iso.php}{http://syslinux.zytor.com/iso.php} \subsubsection{Principe} C'est un chargeur de démarrage pour Linux sur CD. Il permet de charger un noyau Linux sans contrainte de taille. Isolinux est utilisé notamment sur les CD d'installation de Mandrake, Red Hat, Debian et sans doute d'autres. Isolinux fait partie du projet Syslinux. \subsubsection{Mode non-\'emulation} Isolinux fonctionne sans \'emulation de disquette ou de disque dur. Il n'y a donc pas de limite sur la taille de ce que l'on met sur le CD: le noyau. \subsubsection{\'Etapes} Voici les \'Etapes de la m\'ethode que nous allons mettre en place: \begin{enumerate} \item Créer une image bootable du CD pour le PC diskless \item Graver cette image. \item Démarrer le diskless sur le CD. \end{enumerate} \subsubsection{Fichier de configuration d'isolinux} Quand isolinux est installé sur le CD, son comportement est déterminé par son fichier de configuration qui se trouve dans le répertoire /isolinux/isolinux.cfg du CD. Isolinux propose au démarrage un menu avec plusieurs options possibles, tout comme LILO ou GRUB. Ainsi, on peut mettre plusieurs choix possibles au démarrage d'isolinux en mettant les entrées correspondantes dans le fichier de configuration. Voici un exemple du fichier isolinux.cfg: \begin{verbatim} default linux prompt 0 label linux KERNEL alt0/vmlinuz APPEND root=/dev/nfs devfs=mount ip=::::::dhcp \ nfsroot=195.220.79.217:/diskless/tftpboot/195.220.79.220 \end{verbatim} Voici ce que veut dire chaque ligne de ce fichier: \begin{enumerate} \item Le choix par d\'efaut du syst\`eme que l'on va d\'emarrer est "linux". On pourrait mettre plusieurs choix et laisser l'utilisateur choisir entre ces syst\`emes d'exploitation. Le nom "linux" correspond au label correspondant. \item Avec "prompt 0", on pr\'ecise qu'on ne veut pas que l'utilisateur puisse choisir. Il faut mettre "prompt 1" dans le cas contraire \item "label linux" permet de nommer un choix de d\'emarrage. C'est ce que l'utilisateur devra taper pour d\'emarrer. \item Avec l'option KERNEL, on choisit le noyau à démarrer. Le chemin est relatif au répertoire isolinux. Ainsi, "alt0/vmlinuz" désigne le noyau /isolinux/alt0/vmlinuz du CD. Le nom alt0 est une convention, on aurait très bien pu prendre autre chose. Cela veut dire "alternative 0". Si on voulait proposer le choix entre plusieurs noyaux, on aurait pu les mettre dans alt0, alt1, alt2, ... Attention, le nom du fichier noyau ne doit pas dépasser 8 caractères (c'est une contrainte d'isolinux). \item Enfin, avec l'option APPEND, on choisit toutes les param\`etres à passer au noyau linux. \end{enumerate} Voici la signification des param\`etres pass\'es au noyau linux: \begin{enumerate} \item root=/dev/nfs: indique que la racine doit être montée par NFS. \item devfs=mount: activer l'option devfs. Devfs permet de gérer les périphériques en mettant automatiquement les fichiers dans /dev/. Sans devfs, il faudrait créer tous les fichiers de /dev manuellement. C'est donc une option indispensable. \item ip=::::::dhcp: indique les paramètres réseaux de la machine. Ici, on dit au noyau de faire une requête DHCP pour récupérer ces paramètres. \item nfsroot=... : indique où trouver la racine du système de fichier. 195.220.79.217 est l'IP du serveur NFS et /diskless/tftpboot/195.220.79.220 est le chemin \`a monter sur le serveur. \end{enumerate} Isolinux va donc nous permettre de d\'emarrer le noyau \`a partir du CD. \subsection{M\'ethode utilis\'ee avec isolinux} \subsubsection{Cr\'eation des fichiers du CD} Nous allons mettre nos scripts dans le répertoire /diskless/scripts. Créez le s'il n'existe pas déjà. Tout ce qui est en rapport avec la création du CD sera mis sur le serveur dans /diskless/CDROM. Voici l'arborescence de /diskless/CDROM: \begin{verbatim} /diskless/CDROM | - isos : les images des CD seront placees ici | - root : correspond a la racine du CD | - isolinux : contient le binaire d'isolinux et son fichier de config. | - alt0 : contient le noyau vmlinuz \end{verbatim} Cette arborescence est cr\'ee automatiquement par le script \emph{dkl-init-serveur.sh}. Voici ce qui doit \^etre pr\'esent dans /diskless/CDROM/root/: \begin{enumerate} \item le fichier isolinux/isolinux.bin issu de l'archive syslinux \item le fichier de configuration isolinux/isolinux.cfg \end{enumerate} Tous ces fichiers sont disponibles, voir la partie \emph{Scripts} en annexe. Le script /diskless/scripts/dkl-init-diskless.sh a d\'ej\`a crée les répertoires dans /diskless/CDROM d\'ecrits ci-dessus (voir la partie Installation du serveur). /diskless/CDROM/root/ sera la racine de notre CD. Copier le noyau du diskless dans /diskless/CDROM/root/isolinux/alt0. Par convention, on appelle le noyau vmlinuz car le nom est limit\'e \`a 8 caract\`eres. \begin{verbatim} cp -a /diskless/tftpboot/bzImage-diskless-pxe1 \ /diskless/CDROM/root/isolinux/alt0/vmlinuz \end{verbatim} Modifier le fichier /diskless/CDROM/root/isolinux/isolinux.cfg pour mettre à jour l'IP du serveur comme expliqu\'e dans la partie \emph{Introduction \`a isolinux}. \subsubsection{Cr\'eer l'image du CD} Le script /diskless/scripts/dkl-graver-cdrom.sh permet ensuite de créer l'image de notre CD bootable avec mkisofs. Voici ce qu'il contient: \begin{verbatim} mkisofs -o /diskless/CDROM/isos/iso1.iso \ -b isolinux/isolinux.bin \ -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 \ -boot-info-table \ /diskless/CDROM/root/ \end{verbatim} \begin{enumerate} \item -o permet de choisir où mkisofs va mettre le fichier image (glossaire page ~\pageref{def:fichierimage}) du CD bootable. \item -b permet d'indiquer à mkisofs où se trouve le fichier binaire isolinux.bin par rapport à la racine du CD. C'est ce fichier qui sera \'ex\'ecut\'e au d\'emarrage du CD \item -c permet d'indiquer à mkisofs où il doit créer le fichier boot.cat. Ce fichier n'existe pas, c'est normal: mkisofs va le créer et une fois le CD gravé, on le trouvera sur le CD. \item -no-emul-boot permet de graver l'image sans \'emuler une disquette ou un disque pour d\'emarrer le CD. En effet, isolinux fonctionne sans \'emulation. \item -boot-load-size 4 et -boot-info-table sont des options pour créer l'image bootable. Je n'ai pas compris ce qu'elles faisaient exactement mais elles semblent indispensable pour créer l'image bootable. \item Enfin, /diskless/CDROM/root/ indique ce qui doit être gravé. \end{enumerate} \subsubsection{Graver l'image du CD} Une fois le script dkl-graver-cdrom.sh lanc\'e, l'image se trouve dans /diskless/CDROM/isos/iso1.iso. Il ne reste plus qu'à graver l'image. Cette image de CD peut \^etre grav\'ee comme n'importe quelle autre image. Par exemple, on peut utiliser cdrecord: \begin{verbatim} cdrecord dev=0,0,0 blank=fast -eject /diskless/CDROM/isos/iso1.iso \end{verbatim} \begin{enumerate} \item L'option blank=fast permet d'effacer le CD avant de graver s'il s'agit d'un CD r\'einscriptible. \item L'option \emph{eject} permet de sortir le CD du lecteur apr\`es la gravure. \item /diskless/CDROM/isos/iso1.iso indique l'image \`a graver. \end{enumerate} \subsubsection{Avantages} \begin{enumerate} \item Pas de contrainte sur la taille du noyau. \item Toutes les cartes r\'eseaux compatibles linux marcheront avec cette m\'ethode. \end{enumerate} \subsubsection{Inconv\'enient} Il faut trouver une méthode pour faire un CD générique. En effet, il serait fastidieux de créer un CD différent pour chaque diskless! Pour l'instant, on a \'ecrit sur le CD l'adresse IP du diskless et du serveur dans le fichier isolinux.cfg. Le CD ne sera donc utilisable que sur ce diskless. Ce probl\`eme est r\'esolu dans la partie suivante \subsubsection{Liens utiles} \begin{enumerate} \item Le répertoire /isolinux du CD d'installation de Mandrake. \item La page du manuel de mkisofs (man mkisofs) \item Le site d'isolinux \htmladdnormallink{http://syslinux.zytor.com/iso.php}{http://syslinux.zytor.com/iso.php} \item Description du format El Torito \htmladdnormallink{http://www.phoenix.com/resources/specs-cdrom.pdf}{http://www.phoenix.com/resources/specs-cdrom.pdf} \item Documentation sur la cr\'eation de CD bootables \htmladdnormallink{http://tldp.org/HOWTO/Bootdisk-HOWTO/cd-roms.html}{http://tldp.org/HOWTO/Bootdisk-HOWTO/cd-roms.html} \item Isolinux peut \^etre t\'el\'echarg\'e sur: \htmladdnormallink{http://www.kernel.org/pub/linux/utils/boot/syslinux/}{http://www.kernel.org/pub/linux/utils/boot/syslinux/} \item La derni\'ere version est Syslinux 2.04: \htmladdnormallink{http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-2.04.tar.bz2 }{http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-2.04.tar.bz2} \end{enumerate} \subsection{Comment faire des CD g\'en\'eriques avec isolinux} Un CD bootable g\'en\'erique est un CD qui marchera sur tous les PC diskless du LAOG. Nous avons vu comment créer un CD bootable qui permet de d\'emarrer un PC diskless en utilisant un serveur de diskless. Cependant, cette méthode a un gros défaut: il faut faire un CD différent pour chaque diskless! \subsubsection{Quel est le probl\`eme?} Avec la m\'ethode pr\'ec\'edente, il fallait un CD différent par diskless. Le seul paramètre qui change d'un diskless à l'autre dans notre création de CD se trouve dans le fichier de configuration d'isolinux (isolinux.cfg): \begin{verbatim} default linux prompt 0 label linux KERNEL alt0/vmlinuz APPEND root=/dev/nfs devfs=mount ip=::::::dhcp \ nfsroot=195.220.79.217:/diskless/tftpboot/195.220.79.220 \end{verbatim} L'adresse IP 195.220.79.220 est l'adresse IP du client. Celle-ci diff\`ere sur chaque diskless. Le point d'où doit être montée la racine de notre diskless n'est pas constante. \subsubsection{Comment r\'esoudre le probl\`eme: premi\`ere id\'ee} Le chemin \`a acc\'eder sur le serveur ( /diskless/tftpboot/195.220.79.220 ) doit être écrit sur le CD. Il faut donc: \begin{enumerate} \item Mettre un chemin unique sur le CD \item Le serveur NFS doit différencier les clients selon leur IP et donner des répertoires différents. \end{enumerate} Malheureusement, le serveur NFS de Linux ne permet pas ca... Cette idée n'est donc pas applicable! \subsubsection{Solution du probl\`eme} Le diskless doit trouver le chemin sur le serveur pour sa racine en fonction de son adresse IP. Mais cette adresse IP ne doit pas \^etre \'ecrite sur le CD car elle est diff\'erente pour chaque diskless. La solution se trouve en fait dans la documentation de Linux sur: \begin{verbatim} /usr/src/linux/Documentation/nfsroot.txt \end{verbatim} Il s'agit de l'option "nfsroot" que l'on passe au noyau. Il est dit: \begin{verbatim} If there is a "%s" token in the string, the token will be replaced by the ASCII-representation of the client's IP address. \end{verbatim} Le fichier de configuration isolinux.cfg doit donc contenir: \begin{verbatim} default linux prompt 0 label linux KERNEL alt0/vmlinuz APPEND root=/dev/nfs devfs=mount ip=::::::dhcp \ nfsroot=195.220.79.217:/diskless/tftpboot/%s \end{verbatim} Ainsi, le noyau va remplacer \%s par l'adress IP qu'il a obtenue par DHCP. Le chemin sera donc form\'e correctement. On peut même aller plus loin: la documentation de Linux dit que, dans l'option nfsroot=, si l'IP du serveur NFS n'est pas donnée, l'adresse du serveur DHCP est prise par défaut. Or, dans notre cas, le serveur DHCP et le serveur NFS du diskless sont la même machine. On peut donc mettre: \begin{verbatim} default linux prompt 0 label linux KERNEL alt0/vmlinuz APPEND root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=/diskless/tftpboot/%s \end{verbatim} Avec cette derni\`ere solution, voici les \'etapes du boot qui seront effectu\'ees: \begin{enumerate} \item Le PC diskless boote sur le CD \item Isolinux est lanc\'e \item Isolinux donne la main \`a Linux en lui passant les param\`etres indiqu\'es dans le fichier de configuration isolinux.cfg \item Linux d\'emarre \item Linux fait une requ\^ete DHCP car le param\`etre ip contient la valeur \emph{::::::dhcp}. \item Un serveur DHCP lui donne son IP. Linux m\'emorise son adresse IP ainsi que l'adresse IP du serveur DHCP. \item Linux demande le montage de sa partition racine au serveur NFS. Le serveur NFS utilis\'e est celui dont l'IP est celle du serveur DHCP. Le chemin d'acc\`es sur le serveur est /diskless/tftpboot/195.220.79.xxx/ car Linux a remplac\'e \%s par son adresse IP. \end{enumerate} Ainsi, le CD marchera quel que soit le diskless et quel que soit le serveur. Les seules contraintes sont: \begin{enumerate} \item Le serveur NFS et le serveur DHCP d'un même diskless doivent être la même machine (on ne peut pas utiliser deux machines, chacune \'etant sp\'ecialis\'ee sur un service) \item Le noyau étant sur le CD, il faudra changer le CD lors des mises à jour du noyau (ce qui ne devrait pas arriver très souvent). On ne peut donc pas mettre \`a jour le noyau juste sur le serveur, contrairement \`a la m\'ethode de boot par PXE. \end{enumerate} \subsubsection{Mise au point} Pour mettre au point la m\'ethode, j'ai du effectuer de nombreux gravage. Mais utilisant un CD r\'einscriptible, aucun CD n'a \'et\'e gaspill\'e. \subsubsection{Conclusion} Cette méthode marche tout aussi bien que la précédente et permet d'avoir un CD unique pour tout le LAOG. \section{Proc\'edure pour cr\'eer les CD bootable} \subsection{Principe} Isolinux est un chargeur de démarrage pour Linux sur CD. Il permet de charger un noyau Linux sans contrainte de taille. Isolinux est utilisé notamment sur les CD d'installation de Mandrake, Red Hat, Debian et sans doute d'autres. Isolinux fait partie du projet Syslinux. Le site de isolinux: \htmladdnormallink{http://syslinux.zytor.com/iso.php}{http://syslinux.zytor.com/iso.php} \subsection{proc\'edure} Tout ce qui est en rapport avec la création du CD sera mis sur le serveur dans /diskless/CDROM. Voici l'arborescence de /diskless/CDROM: \begin{verbatim} /diskless/CDROM | - isos : les images des CD seront placees ici | - root : correspond a la racine du CD | - isolinux : contient le binaire d'isolinux et son fichier de config. | - alt0 : contient le noyau vmlinuz \end{verbatim} Cette arborescence est cr\'ee automatiquement par le script \emph{dkl-init-serveur.sh}. Voici ce qui doit \^etre pr\'esent dans /diskless/CDROM/root/: \begin{enumerate} \item le fichier isolinux/isolinux.bin issu de l'archive syslinux \item le fichier de configuration isolinux/isolinux.cfg \end{enumerate} Ces deux fichiers ont \'et\'e copi\'e par \emph{dkl-init-serveur.sh}. Les deux fichiers sont donc d\'ej\`a pr\'esents. Si vous voulez r\'ecup\'erer la derni\`ere version, t\'el\'echargez l'archive de syslinux sur \htmladdnormallink{http://www.kernel.org/pub/linux/utils/boot/syslinux/}{http://www.kernel.org/pub/linux/utils/boot/syslinux/}. Le fichier isolinux.bin se trouve dans l'archive. La cr\'eation de CD se fait en 5 \'etapes: \begin{enumerate} \item Copier le noyau linux. \item Modifier le fichier de configuration d'isolinux. \item Créer une image bootable du CD pour le PC diskless \item Graver cette image. \item Démarrer le diskless sur le CD. \end{enumerate} \subsection{Copier le noyau linux} Le noyau se trouve ici: /diskless/tftpboot/bzImage-diskless-pxe1. Il faut le copier dans l'arborescence du CD: \begin{verbatim} cp -a /diskless/tftpboot/bzImage-diskless-pxe1 \ /diskless/CDROM/isolinux/alt1/vmlinuz \end{verbatim} Par convention, on appelle le noyau vmlinuz car le nom est limit\'e \`a 8 caract\`eres. \subsection{Fichier de configuration d'isolinux} Il se trouve sous /diskless/CDROM/root/isolinux/isolinux.cfg. Pas besoin de le modifier, il est correct. Voici un exemple: \begin{verbatim} # Fichier de configuration isolinux.cfg default linux # Pour afficher le menu #prompt 1 # Pour ne pas afficher le menu prompt 0 ##################### # CHOIX 1: "linux" label linux # A la racine du CDROM, repertoire isolinux/alt0 KERNEL alt0/vmlinuz # A ce stade, le noyau est charge du CD en memoire # Parametres passes au noyau pour booter sur le reseau APPEND root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=/diskless/tftpboot/%s ##################### # CHOIX 2: "linux-2" label linux-2 # A la racine du CDROM, repertoire isolinux/alt2 KERNEL alt1/vmlinuz # A ce stade, le noyau est charge du CD en memoire # Parametres passes au noyau pour booter sur le reseau APPEND root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=/diskless/tftpboot/%s \end{verbatim} Explications: \begin{enumerate} \item Le choix par d\'efaut du syst\`eme que l'on va d\'emarrer est "linux". On pourrait mettre plusieurs choix et laisser l'utilisateur choisir entre ces syst\`emes d'exploitation. Le nom "linux" correspond au label correspondant. \item Avec "prompt 0", on pr\'ecise qu'on ne veut pas que l'utilisateur puisse choisir. Il faut mettre "prompt 1" dans le cas contraire \item "label linux" permet de nommer un choix de d\'emarrage. C'est ce que l'utilisateur devra taper pour d\'emarrer (si prompt=1). \item Avec l'option KERNEL, on choisit le noyau à démarrer. Le chemin est relatif au répertoire isolinux. Ainsi, "alt0/vmlinuz" désigne le noyau /isolinux/alt0/vmlinuz du CD. Le nom alt0 est une convention, on aurait très bien pu prendre autre chose. Cela veut dire "alternative 0". Si on voulait proposer le choix entre plusieurs noyaux, on aurait pu les mettre dans alt0, alt1, alt2, ... Attention, le nom du fichier noyau ne doit pas dépasser 8 caractères (c'est une contrainte d'isolinux). \item Enfin, avec l'option APPEND, on choisit toutes les options à passer au noyau linux. \end{enumerate} L'option qui nous int\'eresse pour un PC diskless est la ligne d'options \`a passer au noyau. Voici leurs significations: \begin{enumerate} \item root=/dev/nfs: indique que la racine doit être montée par NFS. \item devfs=mount: activer l'option devfs. Devfs permet de gérer les périphériques en mettant automatiquement les fichiers dans /dev/. Sans devfs, il faudrait créer tous les fichiers de /dev manuellement. C'est donc une option indispensable. \item ip=::::::dhcp: indique les paramètres réseaux de la machine. Ici, on dit au noyau de faire une requête DHCP pour récupérer ces paramètres. \item nfsroot=... : indique où trouver la racine du système de fichier. Le serveur NFS est celui qui a r\'epondu \`a la requ\^ete DHCP et \%s est remplac\'e par l'IP du PC diskless obtenue par DHCP. \end{enumerate} \subsection{Cr\'eer l'image bootable du CD pour le PC diskless} Cr\'eer l'image. Cela se fait avec le script \emph{dkl-graver-cdrom.sh} qui se lance sans argument. Ce script va cr\'eer l'image avec mkisofs. Voici ce qu'il contient: \begin{verbatim} mkisofs -o /diskless/CDROM/isos/iso1.iso \ -b isolinux/isolinux.bin \ -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 \ -boot-info-table \ /diskless/CDROM/root/ \end{verbatim} \begin{enumerate} \item -o permet de choisir où mkisofs va mettre le fichier image du CD bootable. \item -b permet d'indiquer à mkisofs où se trouve le fichier binaire isolinux.bin par rapport à la racine du CD. C'est ce fichier qui sera \'ex\'ecut\'e au d\'emarrage du CD \item -c permet d'indiquer à mkisofs où il doit créer le fichier boot.cat. Ce fichier n'existe pas, c'est normal: mkisofs va le créer et une fois le CD gravé, on le trouvera sur le CD. \item -no-emul-boot permet de graver l'image sans \'emuler une disquette ou un disque pour d\'emarrer le CD. En effet, isolinux fonctionne sans \'emulation. \item -boot-load-size 4 et -boot-info-table sont des options pour créer l'image bootable. Je n'ai pas compris ce qu'elles faisaient exactement mais elles semblent indispensable pour créer l'image bootable. \item Enfin, /diskless/CDROM/root/ indique ce qui doit être gravé. \end{enumerate} Une fois le script \emph{dkl-graver-cdrom.sh} lanc\'e, l'image se trouve ici: \emph{/diskless/CDROM/isos/iso1.iso} \subsection{Graver l'image} L'image se trouve ici: \emph{/diskless/CDROM/isos/iso1.iso}. Elle peut \^etre grav\'ee par n'importe quel logiciel de gravage. Voici la m\'ethode avec cdrecord. Tout d'abord, taper "cdrecord -scanbus" pour savoir o\`u se trouve le graveur de CD. Le r\'esultat doit \^etre ceci: \begin{verbatim} 0,0,0 0) 'AOPEN ' 'CD-RW CRW4048 ' '1.05' Removable CD-ROM \end{verbatim} On voit donc que le graveur se trouve sur le p\'eriph\'erique "0,0,0". Graver l'image avec ce commande (remplacer "0,0,0" si n\'ecessaire): \begin{verbatim} cdrecord dev=0,0,0 -eject /diskless/CDROM/isos/iso1.iso \end{verbatim} S'il s'agit d'un CD-RW (r\'einscriptible), il faut utiliser la commande suivante pour effacer le CD avant de graver: \begin{verbatim} cdrecord dev=0,0,0 blank=fast -eject /diskless/CDROM/isos/iso1.iso \end{verbatim} \subsection{Démarrer le PC diskless sur le CD} Le BIOS du PC diskless doit \^etre configur\'e de mani\`ere \`a booter sur le CD. Une fois ceci configur\'e, ins\'erer le CD et red\'emarrer le PC diskless. \subsection{R\'esum\'e} \begin{enumerate} \item Le PC diskless boote sur le CD \item Isolinux est lanc\'e. \item Isolinux lit son fichier de configuration qui se trouve sur le CD. \item Isolinux charge le noyau linux qui se trouve sur le CD. \item Isolinux donne la main \`a Linux en lui passant les param\`etres indiqu\'es dans le fichier de configuration isolinux.cfg \item Linux d\'emarre \item Linux fait une requ\^ete DHCP car le param\`etre ip contient la valeur \emph{::::::dhcp}. \item Un serveur DHCP lui donne son IP. Linux m\'emorise son adresse IP ainsi que l'adresse IP du serveur DHCP. \item Linux demande le montage de sa partition racine au serveur NFS. Le serveur NFS utilis\'e est celui dont l'IP est celle du serveur DHCP. Le chemin d'acc\`es sur le serveur est /diskless/tftpboot/195.220.79.xxx/ car Linux a remplac\'e \%s par son adresse IP. \end{enumerate} % ################################################## \part{Installation du serveur de diskless: Manuel utilisateur} % ################################################## J'ai eu plusieurs machines \`a ma disposition pour effectuer des tests et mettre au point la m\'ethodes. Pour voir la description de ces machines, allez voir en annexe la partie \emph{Machines de tests}. Pour faciliter l'installation, j'ai \'ecrit des scripts qui sont accessibles en annexe. \section{Installation et configuration des services du serveur} Le serveur de diskless devra avoir les services suivants: \begin{enumerate} \item DHCP \item NFS \item TFTP (utile seulement pour les boots par PXE ou GrubPxe) \end{enumerate} \subsection{Configuration du serveur DHCP} DHCPD est un processus tournant tâche de fond qui assigne à toute machine sur un réseau TCP/IP qui le demande une adresse IP. Il fournit aussi certaines informations sur le réseau. L'adresse IP est fournie pour une durée déterminée dans la configuration. C'est le démon qui est à l'écoute des appels (requete "dhcp" par l'intermédiaire d'un broadcast) sur le réseau, provenant des PC clients. Le serveur tournant dhcpd regarde dans son fichier /etc/dhcpd.conf s'il contient une entreé correspondant à l'adresse éthernet (MAC) du PC. Il lui retourne l'adresse IP indiquée dans la table. Installer le serveur DHCP. Les paquetages \`a installer sont: \begin{enumerate} \item dhcp-server \item dhcp-common \item dhcpcd \item dhcp-client \end{enumerate} Il faut aussi installer la partie client car, m\^eme si le serveur n'en a pas besoin, les PC diskless en ont besoin et le syst\`eme des PC diskless va \^etre r\'ecup\'er\'e \`a partir du serveur. Un autre fichier - /var/lib/dhcp/dhcpd.leases - doit être créé pour que DHCPD puisse y stocker les informations sur les "locations" d'adresses actuelles. Pour le créer, taper simplement la commande touch /var/lib/dhcp/dhcpd.leases Voici une partie du fichier de configuration /etc/dhcpd.conf pour un diskless: \begin{verbatim} # Diskless de test numero 2 host gag242 { allow booting; hardware ethernet 00:d0:b7:c4:dc:ba; fixed-address 195.220.79.242; } \end{verbatim} \subsection{Configuration du serveur NFS} NFS veut dire Network File System. Le support du serveur nfs doit être inclus dans le noyau. Pour le démarrer : /etc/rc.d/init.d/nfs start ==> rpc.portmap et rpc.mountd vérifier que le serveur tourne : ps ex | grep nfsd Si le nombre de PC diskless à servir est grand, modifier, le fichier /etc/init.d/nfs et passer NFSDCOUNT à 16 (le défaut est 8). Après le chargement du noyau par tftp ou par CD, un système de fichiers racine doit etre fourni. Linux utilise le protocole NFS (qui fait partie intégrante du noyau qui vient d'être chargé) pour voir le système de fichiers racine. NFS-Root permet d'utiliser une partition NFS comme partition racine. Cette possibilité est particulièrement utile pour une station dépourvue de disque local (diskless) Installer et configurer le serveur NFS. Voici une partie du fichier de configuration /etc/exports pour deux diskless: \begin{verbatim} # /etc/exports /diskless 195.220.79.220(rw,no_root_squash,insecure,async) /diskless 195.220.79.242(rw,no_root_squash,insecure,async) \end{verbatim} \subsection{Configuration du serveur TFTP} TFTP est utile uniquement si certain PC diskless bootent par PXE ou par GrubPxe. TFTP = FTP sans authentification et tournant sur UDP : transfert bloc par bloc et non par flux comme tcp TFTP va permettre au PC diskless qui a obtenu son adresse IP par dhcp, de télécharger l'image de son OS, bloc par bloc, jusqu'à ce que tout le fichier soit transféré. Quand l'OS est entièrement chargé, la ROM de démarrage réseau, donne la main à l'image du système d'exploitation au point d'entrée. Un exemple d'installation, de configuration et de "debug" de tftp: \htmladdnormallink{http://sari.inpg.fr/rubriques/themes/zone\_publique.groupe\_linux/diskless/tftp-hpa-install}{http://sari.inpg.fr/rubriques/themes/zone\_publique.groupe\_linux/diskless/tftp-hpa-install} \section{Installation dans /diskless} On choisit de recopier l'image complète du système linux serveur, dans une partition réservée que l'on nommera /diskless, dans laquelle on va construire l'arborescence racine nécessaire à chaque diskless. Il faut donc prévoir une partition dont la taille sera égale à la taille du système linux serveur plus la taille d'un /usr/local pouvant accueillir les logiciels communs à tous les diskless soit environ 2Go, plus environ 100 Mo par diskless, plus une zone commune système d'environ 100Mo. Il est raisonable de prévoir une zone de 10 a 20Go pour être à l'aise. Cette solution va permettre de rendre l'ensemble des diskless indépendants du système serveur, de porter cette partition sur d'autres plateformes qu'un PC linux (par exemple, l'UNIX d'IBM: AIX). L'ensemble des logiciels installés sous /usr/local ou sous /opt seront partageables entre tous les diskless, ainsi que les librairies. \subsection{Cr\'eation des r\'epertoires de /diskless} Il faut cr\'eer /diskless: \begin{verbatim} mkdir -p /diskless \end{verbatim} Les scripts d'installation seront plac\'es dans /diskless/scripts. T\'el\'echargez-les dans /diskless/scripts (Voir l'adresse en annexe). Il faut ensuite lire et lancer le script \emph{dkl-init-serveur.sh}. Ce script pr\'epare l'arborescence /diskless: \begin{enumerate} \item Pr\'epare /diskless/tftpboot avec quelques fichiers exemples. \item Pr\'epare /diskless/CDROM pour qu'un CD puisse \^etre grav\'e. \item Copie les r\'epertoires /bin, /usr... communs \`a tous les diskless. \item Copie les fichiers communs \`a tous les diskless (/etc/passwd par exemple). \end{enumerate} Mais avant de lancer ce script, il faut \^etre s\^ur d'avoir install\'e sur le serveur les paquetages qui seront utilis\'es sur les PC diskless (car les paquetages install\'es sur les PC diskless viennent de la copie du serveur). En particulier, il faut: \begin{enumerate} \item kernel-source \item dhcp-client \end{enumerate} \section{Installer le noyau du diskless} \subsection{Faire d'abord une sauvegarde} Installer les sources du noyau: \begin{verbatim} urpmi kernel-source \end{verbatim} V\'erifier que les sources se trouvent bien dans /usr/src/linux. Sauvegarder /boot, les modules du serveur et les sources: \begin{verbatim} cp -a /boot /boot.sav cp -a /lib/modules/2.4.19-16mdk /lib/modules/2.4.19-16mdk.sav cp -a /usr/src/linux-2.4.19-16mdk /usr/src/linux-2.4.19-16mdk.sav \end{verbatim} Modifier /etc/lilo.conf ou /boot/grub/menu.lst: remplacer les vmlinuz, initrd, ... qui sont des liens symboliques par le nom réel des fichiers : vmlinuz-2.4.19-16mdk, initrd-2.4.19-16mdk.img, ... Ajouter une stanza dans lilo.conf ou menu.lst qui permettra de rebooter au cas ou le noyau serait endommagé. Par ex. : \begin{verbatim} image=/boot.sav/vmlinuz-2.4.19-16mdk label=linux.sav root=/dev/sda1 initrd=/boot.sav/initrd-2.4.19-16mdk.img append="quiet devfs=mount" vga=788 read-only \end{verbatim} Si vous utilisez lilo, n'oubliez pas de taper lilo. Pour Grub, il n'y a rien \`a faire. Tester pour voir si \,ca d\'emarre bien. \subsection{Construire le noyau et les modules} Les sources du noyau avaient été installés sur le serveur et la recopie du système sous /diskless, fait que ces sources sont sous /diskless/usr/src. \begin{verbatim} cd /diskless/usr/src cp -a linux-2.4.19-16mdk linux-2.4.19-16mdk-diskless-pxe1 cd linux-2.4.19-16mdk-diskless-pxe1 cp -a .config .config.serveur \end{verbatim} On va travailler à partir du .config qui deviendra celui du diskless. Il faudra mettre dans le noyau les param\`etres suivants: \begin{enumerate} \item "Network Device support". intégre dans le noyau toutes les cartes reseaux installees sur les PC du site : le pilote de la carte réseau d'un PC diskless, doit être compilé dans le noyau et non en module. \item "Networking options". IP: Kernel level autoconfiguration (CONFIG\_IP\_PNP=y); IP: BOOTP support (CONFIG\_IP\_PNP\_BOOTP=y). Cela permmettra le boot sur le réseau. \item "File systems" / "Network File Systems". NFS file system support (CONFIG\_NFS\_FS=y): permet d'activer CONFIG\_ROOT\_NFS; Provide NFSv3 client support (CONFIG\_NFS\_V3=y); Root file system on NFS (CONFIG\_ROOT\_NFS=y). Cela va permettra au noyau linux de monter la racine du système de fichiers par NFS lors du boot. \end{enumerate} Pour compiler le noyau: \begin{enumerate} \item make mrproper \item Modifier le fichier Makefile (EXTRAVERSION = -16mdk-diskless-pxe1) \item make xconfig \item Mettre dans le noyau les param\`etres cit\'es. \item make dep \item make bzImage \item make modules \item make modules\_install \item cp -a arch/boot/i386/bzImage /diskless/tftpboot/bzImage-diskless-pxe1 \item cp -a /lib/modules/2.4.19-16mdk-diskless-pxe1 /diskless/lib/modules \item cd /diskless/lib/modules/2.4.19-16mdk-diskless-pxe1/ \item rm build \item ln -s /diskless/usr/src/linux-2.4.19-16mdk-diskless-pxe1/ build \end{enumerate} Le noyau se trouve maintenant dans /tftpboot/bzImage-diskless-pxe1. Selon les m\'ethodes de boot, il devra \^etre copi\'e dans les emplacements suivants: \begin{enumerate} \item Boot par PXE, GrubPxe: le laisser dans /diskless/tftpboot/bzImage-diskless-pxe1 \item Boot \`a partir d'un CD: le copier dans /diskless/CDROM/root/isolinux/alt0/vmlinuz \item Boot \`a partir du disque dur: le copier sur le disque du PC diskless dans /grub/vmlinuz-diskless \end{enumerate} Dans tous les cas, les modules restent sur le serveur de diskless. \section{Cr\'eation des diskless: mod\`ele et clones} \subsection{Cr\'eation du mod\`ele} Il faut lancer le script \emph{dkl-init-diskless.sh} avec comme premier argument l'adresse IP du PC diskless. Par exemple: \begin{verbatim} /diskless/scripts/dkl-init-diskless.sh 195.220.79.220 \end{verbatim} Voici ce que fait le script: \begin{enumerate} \item créer la racine /tftpboot/adresse-IP du diskless \item créer l'architecture des répertoires du diskless modèle \item copier des répertoires propres au diskless et qui ne seront pas communs à tous les diskless \item créer les répertoires sous /mnt \end{enumerate} \subsection{Fichiers de configuration propres au diskless} Aller dans le r\'epertoire du diskless puis adapter ces fichiers aux param\`etres du diskles (adresse IP, modules, disque dur...) \begin{enumerate} \item /etc/sysconfig/network (modifier le HOSTNAME --> XXX) \item /etc/sysconfig/network-scripts/ifcfg-eth0 (modifier IPADDR --> XXX) \item /etc/sysconfig/keyboard \item /etc/modules.conf \item /etc/modules \item /etc/X11/XF86Config-4 \item /etc/fstab (modifier l'IP du diskless pour le montage de "/") \end{enumerate} Voici deux exemples de fichier /etc/sysconfig/keyboard: Clavier am\'ericain: \begin{verbatim} KBCHARSET=iso-8859-15 KEYBOARD=us_intl KEYTABLE=us-latin1 \end{verbatim} Clavier fran\,cais: \begin{verbatim} KBCHARSET=iso-8859-15 KEYBOARD=fr KEYTABLE=fr-latin1 \end{verbatim} Des exemples de /etc/X11/XF86Config-4 se trouvent en annexe. Voici ce qu'il faut penser \`a modifier: \begin{enumerate} \item \emph{Clavier}: Option "XkbLayout" "fr": Mettre "fr" ou "us\_intl" selon le clavier utilis\'e. \item \emph{Carte graphique}: Driver "nvidia": Mettre "nvidia" ou "ati" selon le driver utilis\'e. On pourra lancer xf86config pour voir la liste compl\`ete. \item \emph{Souris}: Voir les deux exemples ci-dessous. \end{enumerate} Souris sans molette: \begin{verbatim} Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/psaux" Option "Emulate3Buttons" Option "Emulate3Timeout" "50" EndSection \end{verbatim} Souris avec molette: \begin{verbatim} Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/psaux" Option "ZAxisMapping" "4 5" EndSection \end{verbatim} Il faut aussi adapter le fichier /etc/fstab du diskless. Voici un exemple: \begin{verbatim} # /etc/fstab du diskless # 195.220.79.217 est l'adresse IP du serveur # 195.220.79.220 est l'adresse IP du diskless 195.220.79.217:/diskless/tftpboot/195.220.79.220 / nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 195.220.79.217:/diskless/shares/bin /bin nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 195.220.79.217:/diskless/shares/usr /usr nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 195.220.79.217:/diskless/shares/sbin /sbin nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 195.220.79.217:/diskless/shares/home /home nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 195.220.79.217:/diskless/shares/lib /lib nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 195.220.79.217:/diskless/shares/commun /commun nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 195.220.79.217:/diskless/shares/opt /opt nfs defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 none /dev/pts devpts mode=0620 0 0 none /proc proc defaults 0 0 # DISQUETTES ET CDROM #none /mnt/cdrom supermount dev=/lib/dev-state/ide/host2/bus1/target1/lun0/cd,fs=auto,ro,--,iocharset=iso8859-15,codepage=850,umask=0 0 0 #OU: none /mnt/cdrom supermount dev=/dev/cdrom,fs=auto,ro,--,iocharset=iso8859-15,codepage=850,umask=0 0 0 #none /mnt/cdrom2 supermount dev=/lib/dev-state/ide/host2/bus1/target0/lun0/cd,fs=auto,ro,--,iocharset=iso8859-15,codepage=850,umask=0 0 0 #none /mnt/floppy supermount dev=/dev/fd0,fs=auto,--,iocharset=iso8859-15,sync,codepage=850,umask=0 0 0 # DISQUES DURS LOCAUX #/dev/ide/host2/bus0/target0/lun0/part1 /mnt/disk ext3 defaults 0 0 #/dev/ide/host2/bus0/target0/lun0/part3 /local ext3 defaults 0 0 #/dev/ide/host2/bus0/target0/lun0/part2 swap swap defaults 0 0 \end{verbatim} Remarque : Le mini-système initialement créé sous la racine /diskless/tftpboot/195.220.79.XXX par dkl-init-diskless.sh est indispensable au boot du PC diskless, à savoir : usr, lib, bin, sbin. Il va être supplanté par le système complet lors du montage NFS des partitions usr, lib, ... indiquées dans fstab et qui elles correspondent au système Linux copié sous /diskless et commun à tous les PC diskless. Le fait que les fichiers de /bin (par exemple) soient accessibles \`a la fois par /diskless/bin et par /diskless/tftpboot/195.220.79.xxx/bin n'est pas g\^enant: en effet, gr\^ace aux liens durs, cela ne prend pas plus de place. De plus, il est indispensable de laisser ces fichiers dans ces deux endroits: \begin{enumerate} \item Dans /usr \`a cause de rpm. \item Dans /tftpboot/195.220.79.xxx/usr pour le d\'emarrage quand les montages ne sont pas encore faits. \end{enumerate} \subsection{Faire du m\'enage} Faire du m\'enage avec dkl-diskless-menage.sh pour nettoyer /tmp, /root, /var/tmp, etc. Ne pas lancer ce script quand le PC diskless tourne! \subsection{Placer les liens durs} Il faut ensuite lire et lancer le script \emph{dkl-liens-durs-1diskless.sh} avec comme premier argument l'adresse IP du PC diskless. Par exemple: \begin{verbatim} /diskless/scripts/dkl-liens-durs-1diskless.sh 195.220.79.220 \end{verbatim} Apr\`es ce script, tous les fichiers de /usr, ... du PC diskless seront mis en commun par des liens durs avec les autres PC diskless. \subsection{Reconfigurer le serveur} Voici ce qu'il faut penser \`a faire sur le serveur: \begin{enumerate} \item R\'ecup\'eration de l'adresse MAC du nouveau diskless \item MAJ de /etc/dhcp.conf et red\'emarrer DHCP (/etc/init.d/dhcpd restart) \item MAJ de /tftpboot/pxelinux.cfg/ \item MAJ /etc/exports et recharger NFS (exportfs -a) \item MAJ de /etc/hosts et de /diskless/share/commun/hosts \item Si le diskless utilise auto.master et *.map, configurer les diff\'erents serveurs pour accepter le nouveau diskless. \end{enumerate} \subsection{Cloner un diskless} Le but est de rajouter un nouveau diskless dans /diskless/tftpboot/ \`a partir d'un mod\`ele. Si le diskless mod\`ele s'appelle \emph{195.220.79.modele} et si le nouveau diskless s'appelle \emph{195.220.79.242}, tapez: \begin{enumerate} \item cp -a /diskless/tftpboot/195.220.79.modele /diskless/tftpboot/195.220.97.242 \item dkl-liens-durs-1diskless.sh \item dkl-diskless-menage.sh \end{enumerate} Il faut ensuite reprendre les \'etapes de la cr\'eation du mod\`ele mais cette fois pour le nouveau diskless (le diskless clone: 195.220.79.242 par ex.): \begin{enumerate} \item Fichiers de configuration propres au diskless \item Faire du m\'enage \item Placer les liens durs \item Reconfigurer le serveur \end{enumerate} % ################################################## \part{Partage des fichiers syst\`emes entre les diskless} % ################################################## \section{Arborescence UNIX} Sous Linux, les donn\'ees syst\`emes sont class\'ees dans des r\'epertoires dont les noms sont standard. On trouve la m\^eme arborescence de base sur tous les PC Linux. \begin{enumerate} \item /bin: contient tous les programmes de base. Aucun fichier utilisateur ou fichier de configuration ne se trouve ici. Ce r\'epertoire peut donc \^etre commun \`a tous les diskless \item /boot: contient souvent le noyau et quelques fichiers de configuration de boot comme Grub. Mais dans notre cas, on ne d\'emarre pas le PC diskless \`a partir du disque. Ce r\'epertoire n'existe donc pas sur le PC diskless. \item /dev: contient les fichiers de type p\'eriph\'eriques. Ce r\'epertoire est automatiquement rempli au d\'emarrage gr\^ace \`a devfs. Il suffit donc juste de cr\'eer un r\'epertoire /dev vide pour les diskless. \item /etc: contient tous les fichiers de configuration propre \`a la machine. Ce r\'epertoire ne peut donc pas \^etre partag\'e entre les PC diskless car chaque PC diskless peut \^etre diff\'erent. \item /home: contient les fichiers des utilisateurs. Ce r\'epertoire doit \^etre commun sur tous les PC diskless car un utilisateur doit pouvoir se connecter sur n'importe quel PC diskless et retrouver ses fichiers. \item /lib: contient les librairies des programmes du syst\`eme et les modules du noyau. Ce r\'epertoire peut \^etre partag\'e entre les PC diskless. \item /mnt: permet de monter une disquette ou un CD. Ce r\'epertoire ne contient en fait aucun fichier. \item /proc \item /root \item /sbin: comme /bin mais ce r\'epertoire contient normalement les programmes r\'eserv\'es \`a l'administrateur. \item /tmp: espace r\'eserv\'e aux fichiers temporaires. \item /usr \item /var \end{enumerate} Voir: http://www.freenix.fr/unix/linux/fsstnd-fr/ \section{Id\'ee de base} L'idée de base est de créer une partition nommée ici "/diskless" sur une plateforme hôte quelconque qui hébergera l'image d'un système linux indépendant de son propre système. La machine hôte de cette partition (appel\'ee serveur de diskless), exportera par NFS cette partition vers les PC diskless. Sous /diskless, on va construire l'arborescence nécessaire au boot de chaque client diskless, en limitant au maximum sa taille. Chaque arborescence exportée par NFS depuis le serveur deviendra la racine du client diskless, car "NFS-Root" (glossaire page ~\pageref{def:nfsroot}) permet d'utiliser une partition NFS comme partition root (/). Chaque PC diskless bootera à l'aide du protocole PXE de sa carte réseau éthernet ou de son disque dur ou encore un CD. Il obtiendra son adresse IP du serveur de diskless par DHCP et importera par NFS les fichiers nécessaires à la suite de son démarrage. \section{Principe g\'en\'eral} Pour gagner de la place sur le serveur, il n'est pas n\'ecessaire de faire une copie de l'arborescence compl\`ete de chaque diskless. Par exemple, le r\'epertoire /usr des diskless peut \^etre commun pour tous les diskless. Voici la liste de ce qui peut \^etre commun: /usr, /bin, /sbin, /home, /opt, et /lib. Voici ce qui ne peut pas \^etre commun: /dev, /etc, /mnt, /proc, /root, /tmp, et /var \section{M\'ethode de mise en commun} La m\'ethode utilisée pour partager le r\'epertoire /usr (et les autres cit\'es ci-dessus) pour tous les diskless est la suivante: \begin{enumerate} \item /usr et les autres r\'epertoires se trouve \`a un endroit unique sur le serveur: /diskless/usr \item /diskless/usr est partag\'e par NFS et est mont\'e sous /usr \end{enumerate} De plus, certain fichiers des r\'epertoires non partag\'es \emph{doivent} \^etre communs. Ces fichiers se trouvent dans /diskless/tftpboot/commun sur le serveur. Le r\'epertoire commun est mont\'e par NFS sur les diskless avec cette ligne du fichier de configuration /etc/fstab: \begin{verbatim} 195.220.79.217:/diskless/tftpboot/commun /commun nfs \ defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0 \end{verbatim} Voici la liste de ces fichiers: \begin{enumerate} \item passwd, group, shadow, sudoers, hosts, printcap, termcap, ld.so.conf, ld.so.cache. Ces fichiers doivent se trouver sous /etc sur le diskless. \end{enumerate} Les fichiers de cette liste sont dans /diskless/tftpboot/commun sur le serveur. La premi\`ere id\'ee est de cr\'eer des liens symboliques permettent de les trouver. Prenons le cas de /etc/passwd. Du point de vue du diskless, le fichier /etc/passwd est un lien symbolique vers /commun/passwd et /commun est le point de montage du r\'epertoire /diskless/tftpboot/commun sur le serveur. Mais cette m\'ehtode pour partager les fichiers et r\'epertoires pour les diskless pose quelques probl\`emes. En effet, au d\'emarrage du diskless, tous les montages NFS ne sont pas encore mont\'e et les scripts de d\'emarrage ont besoin des fichiers qui se trouvent dans /commun. En effet, /commun n'est pas encore mont\'e et donc /commun/passwd n'existe pas encore pour le diskless. Le Lien symbolique /etc/passwd du diskless n'est donc pas valide. Une fois /commun mont\'e, il n'y a plus de prob\`eme car le lien symbolique devient fonctionnel. Mais avant cela, il y a des probl\`emes lors de l'\'ex\'ecution des scripts de d\'emarrage. Pour les fichiers (/etc/passwd du diskless par exemple), la solution est de cr\'eer un lien dur sur le serveur entre /diskless/tftpboot/commun/passwd et tous les fichiers /etc/passwd de tous les diskless. La commande utilis\'ee pour le diskless gag220 est la suivante (bien s\^ur, cette commande est \'ex\'ecut\'ee sur le serveur): \emph{ln /diskless/tftpboot/commun/passwd /diskless/tftpboot/195.220.79.220/etc/passwd} De cette fa\,con, /etc/passwd est directement accessible par le diskless. \section{Les fichiers d'authentification} Les fichiers d'authentification sont: /etc/passwd, /etc/group, /etc/shadow, /etc/sudoers. Ceux-ci doivent absolument \^etre partag\'es entre les diskless. En effet, une personne doit pouvoir se loguer sur n'importe quel diskless et retrouver son compte. De plus, il faut que quand on modifie ces fichiers (nouveau compte, changement de mot de passe...) la modification se fasse automatiquement. La solution choisie est de lier ces fichiers entre eux par des liens durs. On ne peut pas faire des liens symboliques car cela ne marche pas dans notre cas. En effet, la r\'esolution des liens symboliques se fait du cot\'e du client (diskless) et les fichiers point\'es par les liens symboliques ne sont pas accessibles au d\'emarrage du diskless: le montage NFS n'est pas encore fait. \section{Les fichiers utilisateurs} Pas de probl\`eme particulier puisque /home n'est utilis\'e que lorsque la machine a fini de d\'emarrer. /home est mont\'e par NFS. \section{Les modules du noyau} Les modules du noyau du diskless sont stock\'es sur le serveur. Ils prennent de la place car: \begin{enumerate} \item Le noyau est compil\'e avec un maximum de modules possible. Il n'est pas envisageable de chercher \`a r\'eduire le nombre de modules car l'ensemble de ces modules sera utilis\'e sur un parc h\'et\'erog\`ene de PC diskless avec du mat\'eriel h\'et\'erog\`ene et on ne connait pas \`a l'avance les composants du diskless. On veut donc un noyau g\'en\'eraliste avec un maximum de fonctionnalit\'es. \item Les modules sont recopi\'es dans les r\'epertoires de tous les diskless (/diskless/tftpboot/195.220.79.xxx/lib/modules). \end{enumerate} Ce deuxi\`eme point doit \^etre corrig\'e. Voici l'historique du placement des modules sur le serveur des diskless. \subsection{Modules dans /diskless/lib/modules} Lors de mes premiers tests, j'ai plac\'e les modules dans le r\'epertoire \emph{/diskless/lib/modules/} du serveur. Le r\'epertoire \emph{/diskless/lib} du serveur est mont\'e par NFS sur le r\'epertoire \emph{/lib} du diskless. Cela marchait \`a peu pr\`es mais il y avait un gros probl\`eme: dans les scripts de d\'emarrage, le diskless lance \emph{depmod}. Ce programme sert \`a recenser les modules pour pouvoir les charger plus facilement avec \emph{modprobe}. Mais au moment o\`u \emph{depmod} s'\'ex\'ecute, le r\'epertoire \emph{/lib} du diskless n'est pas encore mont\'e par NFS. \emph{depmod} ne trouvait donc aucun module. Sur mon diskless de test, cela pose deux probl\`emes: \begin{enumerate} \item \emph{modprobe} ne marche pas (car modprobe a besoin de depmod dont l'\'ex\'ecution n'a pas march\'e ay d\'emarrage du PC diskless) Cependant, \emph{insmod} marche toujours mais ce n'est pas satisfaisant. \item Les modules list\'es dans \emph{/etc/modules} ne sont pas charg\'es automatiquement. En effet, ceux-ci sont charg\'es par un script au d\'emarrage avec \emph{modprobe} et \emph{modprobe} ne marche pas. Une cons\'equence de ce probl\`eme est que XFree ne marchait pas car le module de NVidia ne se chargeait pas automatiquement. \end{enumerate} \subsection{Modules dans /diskless/lib/modules et dans les r\'epertoires des diskless} Pour corriger ces probl\`emes, j'ai copi\'e les modules dans tous les r\'epertoires de tous les diskless: \begin{verbatim} /diskless/tftpboot/195.220.79.xxx/lib/modules/ \end{verbatim} Ainsi, les modules se trouvent \`a la fois sous \emph{/diskless/lib/modules} et dans tous les r\'epertoires de tous les diskless. En effet, si on ne les met que dans les r\'epertoires des diskless, le diskless ne trouve plus ses modules car le montage NFS /lib vient cacher les fichiers de /lib. On doit cependant garder un point de montage NFS pour /lib car ce r\'epertoire ne contient pas que les modules et il faut que le reste des fichiers soient communs \`a tous les diskless. Cela prend donc beaucoup de place. De plus, la maintenance est plus difficile puisqu'\`a chaque modification des modules on doit les copier dans autant de r\'epertoires qu'il y a de diskless. Une autre solution doit donc \^etre trouv\'ee. \subsection{Modules dans /diskless/lib/modules et liens durs} Pour corriger ces nouveaux probl\`eme, j'ai propos\'e une nouvelle solution. Elle corrige le probl\`eme de place. Les modules doivent se placer dans /diskless/lib/modules et tous les diskless "poss\`edent" un lien dur vers chacun des modules du noyau. Ainsi, /diskless/tftpboot/195.220.79.xxx/lib/modules/.../ et /diskless/lib/modules/.../ pointent sur le m\^eme inode et d\'esignent donc le m\^eme fichier. Un script se chargera de synchroniser /diskless/lib/modules et le r\'epertoire de modules de chacun des diskless. Le besoin de synchronisation est justifi\'e par: \begin{enumerate} \item Lors de l'ajout d'un diskless, il ne faut pas copier les modules mais faire des liens durs. \item Lors de l'ajout d'un module, il faut cr\'eer tous les liens durs correspondants \`a chaque PC diskless. \item Lors de la suppression d'un module, il faut supprimer tous les liens. En effet, le supprimer de /diskless/lib/modules ne suffit pas \`a lib\'erer l'espace disque puisque des liens existent encore vers le fichier. \end{enumerate} Pour r\'esumer, ce script contient la ligne suivante: \begin{verbatim} cp -al /diskless/lib/modules/ /diskless/tftpboot/195.220.79.xxx/lib/ \end{verbatim} L'option -a permet de garder la structure et les attributs du fichier original lors de la copie. C'est une option indispensable pour les modules. L'option -l permet de ne pas copier les fichiers mais de faire des liens durs \`a la place. En fait, ce script contient d'autres choses mais l'id\'ee est r\'esum\'ee dans cette ligne. Les tests que j'ai effectu\'es montrent que cette m\'ethode marche correctement. Il reste \`a tester les performances sur un cas r\'eel: je ne sais pas si \,ca va aller plus vite ou pas... \subsection{/lib en lien dur} Maintenant, tous le r\'epertoire /lib du PC diskless contient des liens durs "vers" les fichiers correspondant dans /diskless/lib du serveur. \section{Manipulation des liens durs} Tous les fichiers communs entre les diskless se font avec les liens durs. Pour modifier la configuration de ces liens durs, on ne peut pas tout faire \`a la main car: \begin{enumerate} \item Il y a trop de diskless. \item Il y a trop de fichiers. \end{enumerate} Les modifications se font \`a l'aide de scripts: \begin{enumerate} \item Mise en place de tous les liens durs sur tous les diskless: \emph{dkl-liens-durs.sh} \item Mise en place de tous les liens durs sur un diskless: \emph{dkl-liens-durs-1diskless.sh} \item Mise en place d'un lien dur sur tous les diskless: \emph{dkl-1lien-dur-diskless.sh} \item Mise en place d'un lien dur sur un diskless: \emph{dkl-1lien-dur-1diskless.sh} \item Suppression d'un lien dur sur tous les diskless: \emph{dkl-suppr-1lien-dur-diskless.sh} \item Suppression d'un lien dur sur un diskless: \emph{dkl-suppr-1lien-dur-1diskless.sh} \end{enumerate} \subsection{Fonctionnement} Le fichier \emph{dkl-liens-durs-fonctions.sh} contient des fonctions en shell permettant de modifier les liens durs. Les 6 scripts pr\'e-cit\'es appelent ces fonctions pour effectuer ces modifications. \subsection{dkl-liens-durs.sh} Mise en place de tous les liens durs sur tous les diskless. Exemple: \emph{dkl-liens-durs.sh} (ce script s'appelle sans argument) \begin{enumerate} \item Recherche de tous les diskless install\'es (regarde dans /diskless/tftpboot) \item Cr\'e\'e les liens durs sur les r\'epertoires /lib, /usr, /bin, /sbin. \item Cr\'e\'e les liens durs sur les fichiers passwd, group, shadow, auto.master, *.map, ... \end{enumerate} \subsection{dkl-liens-durs-1diskless.sh} Mise en place de tous les liens durs sur un diskless. Exemple: \emph{dkl-liens-durs-1diskless.sh 195.220.79.220} \begin{enumerate} \item Modifie uniquement /diskless/tftpboot/195.220.79.220 \item Cr\'e\'e les liens durs sur les r\'epertoires /lib, /usr, /bin, /sbin. \item Cr\'e\'e les liens durs sur les fichiers passwd, group, shadow, auto.master, *.map, ... \end{enumerate} \subsection{dkl-1lien-dur-diskless.sh} Mise en place d'un lien dur sur tous les diskless. Exemple: \emph{dkl-1lien-dur-diskless.sh /diskless/shares/commun/passwd /etc/passwd} \begin{enumerate} \item Recherche de tous les diskless install\'es (regarde dans /diskless/tftpboot) \item Cr\'e\'e tous les liens durs de /diskless/shares/commun/passwd sur /diskless/tftpboot/195.220.79.*/etc/passwd. \end{enumerate} \subsection{dkl-1lien-dur-1diskless.sh} Mise en place d'un lien dur sur un diskless. Exemple: \emph{dkl-1lien-dur-1diskless.sh 195.220.79.220 /diskless/shares/commun/passwd /etc/passwd} \begin{enumerate} \item Modifie uniquement /diskless/tftpboot/195.220.79.220 \item Cr\'e\'e le lien dur de /diskless/shares/commun/passwd sur /diskless/tftpboot/195.220.79.220/etc/passwd. \end{enumerate} \subsection{dkl-suppr-1lien-dur-diskless.sh} Suppression d'un lien dur sur tous les diskless: Exemple: \emph{dkl-suppr-1lien-dur-diskless.sh /etc/passwd} \begin{enumerate} \item Recherche de tous les diskless install\'es (regarde dans /diskless/tftpboot) \item D\'etruit tous les fichiers /diskless/tftpboot/195.220.79.*/etc/passwd. \end{enumerate} \subsection{dkl-suppr-1lien-dur-1diskless.sh} Suppression d'un lien dur sur un diskless: Exemple: \emph{dkl-suppr-1lien-dur-1diskless.sh 195.220.79.220 /etc/passwd} \begin{enumerate} \item Modifie uniquement /diskless/tftpboot/195.220.79.220 \item D\'etruit le fichier /diskless/tftpboot/195.220.79.220/etc/passwd. \end{enumerate} % ################################################## \part{Installation de logiciels sur les PC diskless} % ################################################## Une fois que les PC diskless marchent, ce n'est pas termin\'e. Il faut pouvoir mettre \`a jour les logiciels. La m\'ethode habituelle sur Linux Mandrake est d'utiliser les outils rpm et urpmi. Cette m\'ethode est parfaitement adapt\'ee aux ordinateurs avec une installation classique sur le disque dur. Dans le cas des PC diskless, cette m\'ethode pose quelques probl\`emes et doit \^etre adapt\'ee. \section{Qu'est-ce que RPM et URPMI?} RPM et URPMI sont les \'equivalents de dpkg et apt-get respectivement pour Mandrake. Le but est de faire marcher RPM et URPMI sur les PC diskless de telle fa\,con qu'on puisse installer une fois le paquetage et qu'il soit install\'e sur tous les PC diskless. La m\'ethode doit \^etre la plus automatique et la plus simple possible. \subsection{Principe de URPMI} Lorsqu'on demande à URPMI d'installer un logiciel, il cherche ce logiciel dans les sources de paquetages installées sur la machine. Les sources de paquetages peuvent être de différents types: CD-ROM d'installation ou Internet. Certaines sources sont des sources officielles de Mandrakesoft (main, contrib, updates), d'autres n'ont rien à voir avec Mandrakesoft (plf, texstar). Certaines sources sont statiques (leur contenu ne change pas), d'autres sont des sources de mises à jour. Il faut donc installer des sources avant de commencer. A l'installation de Mandrake, les seules sources configurées sont les CD-ROM d'installation. Il faut donc installer les sources Internet. \subsection{Comment installer les sources la première fois} Méthode simple: \begin{enumerate} \item Aller sur le site \htmladdnormallink{http://plf.zarb.org/~nanardon/urpmiweb.php}{http://plf.zarb.org/~nanardon/urpmiweb.php} \item Sélectionner les sources (prendre des sites proches pour télécharger plus vite) \item Taper la commande indiquée sur la page. \end{enumerate} \subsection{Mises \`a jour automatiques} Il y a deux choses à faire: \begin{enumerate} \item garder les sources de paquetages à jour \item Mettre à jour les paquetages \end{enumerate} Voici un script qui permet de faire \,ca: \begin{verbatim} #!/bin/sh unset ftp_proxy unset http_proxy urpmi.update main updates ftp2 2>> /var/log/updates urpmi --auto-select --auto --no-verify-rpm >> /var/log/updates \end{verbatim} Attention, ce script n'est pas test\'e !! \subsection{Liens utiles sur URPMI} Page officielle de URPMI: \htmladdnormallink{http://www.linux-mandrake.com/cooker/urpmi.html}{http://www.linux-mandrake.com/cooker/urpmi.html} \section{Probl\`emes} \subsection{NFS lock} Lors de mon premier essai de ces commandes sur un PC diskless, rpm ou urpmi se figent et ne font rien. Ce probl\`eme est maintenant r\'esolu. Voici comment je l'ai r\'esolu. Pour r\'esoudre le probl\`eme, je tape la commande suivante: \begin{verbatim} # strace rpm -qa \end{verbatim} La commande strace permet de montrer tous les appels syst\`emes faits par la commande "rpm -qa". Cela affiche en particulier les lignes suivantes: \begin{verbatim} open("/var/lib/rpm/Packages", O_RDONLY|O_LARGEFILE) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=14807040, ...}) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0\0\0\10"..., 256) = 256 close(3) = 0 brk(0) = 0x8071000 brk(0x8072000) = 0x8072000 open("/var/lib/rpm/Packages", O_RDONLY|O_LARGEFILE) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=14807040, ...}) = 0 brk(0) = 0x8072000 brk(0x8073000) = 0x8073000 fcntl64(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOLCK (No locks available) \end{verbatim} Voici comment interpr\'eter ces lignes: \begin{enumerate} \item rpm ouvre le fichier /var/lib/rpm/Packages avec l\'appel syst\`eme open (voir la premi\`ere ligne). Cette fonction renvoie le descripteur de fichier associ\'e. Dans notre cas, c'est 3. \item rpm veut v\'erouiller le fichier avec l'appel syst\`eme fcntl64 (voir derni\`ere ligne). Il s'agit bien du fichier /var/lib/rpm/Packages car le premier param\`etre de fcntl64 est 3, c'est \`a dire le descripteur de fichier correspondant au fichier ouvert. \end{enumerate} La raison est donc que rpm veut v\'erouiller le fichier mais ne peut pas le faire car la fonction renvoie "ENOLCK (No locks available)". Ce probl\`eme est apparu sur le PC diskless, quand le service NFS lockd n'avait pas r\'eussi \`a d\'emarrer. C'est donc normal que rpm ne puisse pas v\'errouiller le fichier /var/lib/rpm/Packages car ce fichier est acc\'ed\'e par NFS. Pour corriger le probl\`eme, il suffit donc de d\'emarrer NFS lockd. Pour le d\'emarrer, tapez la commande suivante: \begin{verbatim} /etc/init.d/nfslock start \end{verbatim} En fait, NFS lockd se lance au d\'emarrage automatiquement. S'il ne le fait pas, allez voir la partie "NFS lockd". \subsection{Partages entre diskless} \subsubsection{D\'etails du probl\`eme} Pour mon premier test de urpmi sur un PC diskless, j'ai choisi d'installer ce paquetage: fluxbox-0.1.14-6mdk.i586.rpm. Fluxbox est un gestionnaire de fen\^etre bas\'e sur blackbox. Il est tr\`es l\'eger et poss\`ede plusieurs fonctionnalit\'ees int\'eressantes. L'installation se fait depuis le PC diskless gag220 et se d\'eroule sans probl\`eme avec la commande suivante: \begin{verbatim} urpmi fluxbox \end{verbatim} Une fois install\'e, je regarde la liste des fichiers contenus dans le paquetage. \begin{verbatim} rpm -qli fluxbox \end{verbatim} D'apr\`es cette commande, les fichiers sont plac\'es dans: \begin{enumerate} \item /etc \item /usr \end{enumerate} Ce qui devait arriver arriva: \begin{enumerate} \item Les fichiers dans /usr sont bien disponibles sur tous les diskless car /usr est commun \`a tous les PC diskless via un montage NFS. \item Les fichiers dans /etc ne sont accessibles que sur le PC diskless d'installation, c'est-\`a-dire, dans cet exemple, gag220. \end{enumerate} On a donc un gros probl\`eme: les autres PC diskless ne veront pas tous les fichiers. \subsubsection{Une piste: URPMI-parallel} URPMI a une fonctionnalit\'e nomm\'ee "--parallel" qui permet de lancer urpmi automatiquement sur plusieurs machines pour installer un paquetage sur plusieurs machines en m\^eme temps. Cette fonctionnalit\'e a \'et\'e d\'evelopp\'ee pour \^etre utilis\'ee avec Clic mais elle peut en fait \^etre utilis\'ee sur n'importe quelle distribution Linux. Une documentation de cette fonctionnalit\'e se trouve sur: \htmladdnormallink{http://clic.mandrakesoft.com/documentation/ch10.html}{http://clic.mandrakesoft.com/documentation/ch10.html} Malheureusement, cela ne convient pas pour nos PC diskless du LAOG pour plusieurs raisons: \begin{enumerate} \item URPMI-serveur lance en fait URPMI sur les clients diskless. Tous les PC diskless qui doivent \^etre mis-\`a-jour doivent donc \^etre allum\'es au moment de la MAJ, bien que tout se trouve en r\'ealit\'e sur les serveurs. \item Il ne faut pas installer 36 fois (s'il y a 36 PC diskless) le m\^eme fichier dans /usr si /usr partag\'e par tous les diskless. \item Le serveur va demander en m\^eme temps \`a tous les diskless d'acc\'eder en \'ecriture sur un fichier sur son partage NFS. Tous les clients vont donc vouloir acc\'eder en m\^eme temps au m\^eme fichier sur le serveur. \end{enumerate} Cette solution n'est donc pas r\'ealiste. \subsubsection{Une autre piste: installation dans un chroot} Autre solution: installer un paquetage sur tous les PC diskless directement \`a partir du serveur en lan\,cant la commande urpmi dans un chroot bien choisi (voir man chroot). Trop compliqu\'e \`a mettre en oeuvre. \subsubsection{Une autre piste avec quelques scripts} C'est cette solution qui est retenue. Elle est d\'ecrite dans la section \emph{Proc\'edure d'installation de paquetages}. \section{Proc\'edure d'installation de paquetages} Si on se contente de faire un urpmi sur un diskless, voici ce qui arrivera: \begin{enumerate} \item Les fichiers dans /usr sont bien disponibles sur tous les diskless car /usr est commun \`a tous les PC diskless via un montage NFS. \item Les fichiers dans /etc ne sont accessibles que sur le PC diskless d'installation. \end{enumerate} Les paquetages seront donc install\'es \`a moiti\'e... Je propose une solution en plusieurs \'etapes: \begin{enumerate} \item Installer les paquetages sur un diskless avec urpmi. \item Regarder tous les fichiers install\'es et les copier si n\'ecessaire (s'il y a des fichiers dans /etc par ex.) sur chacun des diskless. \end{enumerate} Cela se fait avec deux scripts: \begin{enumerate} \item \emph{dkl-paquetage-install-diskless.sh}, \`a \'ex\'ecuter sur un diskless. \item \emph{dkl-paquetage-install.sh}, \`a \'ex\'ecuter sur le serveur. \end{enumerate} Quelques commandes utiles: \begin{enumerate} \item \emph{rpm -ql nom-paquetage}: lister les fichiers d'un paquetage install\'e. \item \emph{rpm -qa}: lister tous les paquetages install\'es. \item \emph{rpm -qa | grep nom-paquetage}: regarder si un paquetage est install\'e. \item \emph{rpm -qa | xargs rpm -ql}: lister tous les fichiers install\'es par un paquetage. \end{enumerate} \subsubsection{Pr\'eparation} Avant de commencer: \begin{enumerate} \item \emph{dkl-paquetage-install-diskless.sh} doit \^etre accessible sur le diskless. Placez le par exemple dans /diskless/shares/commun. \item \emph{dkl-paquetage-install.sh} doit \^etre accessible sur le serveur. Placez le par exemple dans /diskless/scripts \item Les sources de paquetages doivent \^etre correctement install\'ees sur les diskless. \item Les bases de donn\'ees RPM et URPMI doivent \^etre correctement partag\'ees entre les diskless. \end{enumerate} \subsubsection{Partage des bases de donn\'ees RPM et URPMI} Voici les r\'epertoires concern\'es: \begin{enumerate} \item /etc/urpmi: contient la liste des sources. \item /var/lib/urpmi: contient la liste des paquetages de chaque source. \item /var/lib/rpm: contient la base de donn\'ees RPM, c.\`a.d. la liste des paquetages install\'es. \end{enumerate} Ces trois r\'epertoires ne sont pas n\'ecessaires au d\'emarrage du PC diskless. Ils seront donc partag\'es par des liens symboliques. Voici les liens symboliques qui doivent \^etre plac\'es sur chaque diskless: \begin{enumerate} \item /etc/urpmi -> /commun/etc/urpmi \item /var/lib/urpmi -> /commun/var/lib/urpmi \item /var/lib/rpm -> /commun/var/lib/rpm \end{enumerate} Ces 3 liens symboliques vont \^etre mis en place sur le diskless mod\`ele. Comme ce sont des liens symboliques et non des liens durs, ils seront correctement dupliqu\'es sur les autres diskless lors de la commande "cp -a". \subsubsection{Premi\`ere \'etape: sur un diskless} D\'emarrer un PC diskless. Taper "urpmi nom-du-logiciel". Noter les noms des paquetages qu'il installe sur le PC diskless. Par exemple: \begin{verbatim} -bash-2.05b# urpmi vim-X fluxb (...) installation de /var/cache/urpmi/rpms/vim-X11-6.1-36mdk.i586.rpm /var/cache/urpmi/rpms/fluxbox-0.1.14-6.1tex.i586.rpm Préparation... ################################################## 1:vim-X11 ################################################## 2:fluxbox ################################################## -bash-2.05b# \end{verbatim} Ici, les noms de paquetages sont "vim-X11" et "fluxbox" (indiqu\'e en-dessous de la ligne "Préparation..."). Toujours sur le m\^eme diskless, une fois les logiciels install\'es, tapez: \begin{verbatim} /commun/dkl-paquetage-install-diskless.sh vim-X11 fluxbox \end{verbatim} Cela va cr\'eer le fichier /tmp/MAJ-paquetages.txt qui contient la liste de tous les fichiers de vim-X11 et de fluxbox. Parmi ces fichiers, certains sont d\'ej\`a partag\'es entre les diskless (fichiers dans /usr) et d'autres non (fichiers dans /etc). \subsubsection{Seconde \'etape: sur le serveur} Aller sur le serveur de diskless et taper la commande suivante: \begin{verbatim} /diskless/scripts/dkl-paquetage-install.sh 195.220.79.220 /tftpboot/195.220.79.220/tmp/MAJ-paquetages.txt \end{verbatim} Les arguments de dkl-paquetage-install.sh sont: \begin{enumerate} \item L'adresse IP du diskless sous lequel on a install\'e les paquetages. \item Le fichier contenant la liste des fichiers qu'il faut \'eventuellement copier sur tous les autres diskless \end{enumerate} Voici ce que fait ce dernier script: \begin{enumerate} \item Il lit le fichier MAJ-paquetages.txt g\'en\'er\'e sur le PC diskless. \item Pour chaque fichier install\'e dans /etc/* et /lib/*, il copie ce fichier sur tous les autres diskless. \item Si ce fichier est d\'ej\`a pr\'esent, il demande \`a l'administateur de confirmer la copie car l'option -i est pass\'ee \`a cp. Ainsi, aucun fichier ne sera ecras\'e par erreur. \end{enumerate} \subsubsection{R\'esolution de probl\`emes RPM} Symptomes: RPM ou URPMI ne r\'epondent plus. Suivre les r\`egles suivantes: \begin{enumerate} \item Si rpm ou urpmi ne r\'epondent plus pendant longtemps, vérifier avec "top" qu'il ne fait vraiment rien. S'il utilise des cycles cpu, alors il faut juste attendre. \item Si rpm ou urpmi ne répond vraiment pas, arrêtez-le avec "Control+C" ou "kill -9". Mais dans ce cas, il faut absolument executer les commandes décrites dans l'étape 3 pour réparer les dégats. \item Pour réparer la base de données RPM: Exécuter: rm -f /var/lib/rpm/\_\_db* Ces fichiers seront reg\'en\'er\'es automatiquement. Puis, si n\'ec\'essaire, éxécuter: rpm --rebuilddb Cette commande prend du temps (quelques minutes). Il faut attendre. \end{enumerate} % ################################################## \part{Mises au point} % ################################################## \section{XFree} XFree a besoin de son fichier de configuration: \emph{/etc/X11/XF86Config}. Ce fichier contient le nom du driver de la carte vid\'eo (par exemple "ati"ou "nvidia") et d'autres choses. Il doit donc \^etre modifi\'e sur chaque PC diskless en fonction de son mat\'eriel. D'ordinaire, ce fichier de configuration est \'ecrit automatiquement \`a l'installation de Linux Mandrake. Mais les PC diskless ne sont pas install\'es avec le programme d'installation de Mandrake mais en copiant le syst\`eme du serveur. Le fichier XF86Config contient donc les bonnes informations pour le serveur mais doit \^etre adapt\'e pour les PC diskless car leur mat\'eriel n'est pas le m\^eme. Deux fichiers de configuration XF86Config-4 se trouvent en annexe. \section{Probl\`emes \`a l'arr\^et du diskless} \subsection{O\`u se situe le probl\`eme} Les scripts d'arr\^et de Mandrake Linux démonte les systèmes de fichiers NFS avant la fin de l'arrêt du PC diskless. Ensuite, l'arrêt ne peut pas se terminer car le script d'arrêt ne trouve plus les commandes qui se trouvent sur les systèmes de fichiers démontés. Le script concern\'e est /etc/init.d/netfs, ligne 97. Il est appel\'e avec l'argument "stop" car il y a un lien vers ce script ici: \begin{verbatim} # ls -1 /etc/rc.d/rc?.d/???netfs /etc/rc.d/rc0.d/K75netfs /etc/rc.d/rc1.d/K75netfs /etc/rc.d/rc2.d/K75netfs /etc/rc.d/rc3.d/S25netfs /etc/rc.d/rc4.d/S25netfs /etc/rc.d/rc5.d/S25netfs /etc/rc.d/rc6.d/K75netfs # \end{verbatim} \`A cause de ce script, tous les montages NFS sont arrêtés, y compris la racine. Immédiatement après ce script, l'arr\^et se poursuit et lance des programmes, mais ces programmes ne peuvent plus être trouvés. La commande de démontage est la suivante dans le script (voir ligne 97): \begin{verbatim} umount -f -l -a -t nfs \end{verbatim} Les arguments la commande de d\'emontage sont: \begin{enumerate} \item "-a" d\'emonter les entrées de /etc/fstab \item "-f" forcer le d\'emontage \item "-l" d\'emontage paresseux (voir paragraphe suivant) \item "-t nfs" ne d\'emonter que les montages NFS \end{enumerate} \subsection{Qu'est-ce qu'un d\'emontage paresseux?} Un d\'emontage paresseux ne d\'emonte pas imm\'ediatement le syst\`eme de fichiers. Apr\`es un d\'emontage paresseux, il n'est plus possible de lire ou de modifier les fichiers du syst\`eme de fichiers tout comme un vrai d\'emontage. Cependant, les fichiers ouverts restent ouverts et il est possible de continuer \`a les lire ou les modifier. Lorsque tous les programmes auront ferm\'es leurs fichiers du syst\`eme de fichier concern\'e, le d\'emontage sera effectif. \subsection{Ce qui se passe exactement} L'option "-t nfs" s\'electionne aussi la racine car elle est mont\'ee par NFS. Cependant, comme le d\'emontage est paresseux, cela ne prend pas effet imm\'ediatement. umount cherche donc \`a d\'emonter la racine et pour ce faire, il faur d\'emonter d'abord les sous-r\'epertoires de la racine. Ainsi, \emph{/proc} est d\'emont\'e imm\'ediatement car il n'est pas utilis\'e \`a cette \'etape du script. Mais dans le script, la ligne qui suit le d\'emontage est (ligne 102): \begin{verbatim} remaining=`LC_ALL=C awk '!/^#/ && $3 ~ /^nfs/ && $2 != "/" {print $2}' /proc/mounts` \end{verbatim} Donc le script essaie de lire le fichier \emph{/proc/mounts}; ce fichier n'est plus accessible car /proc est effectivement d\'emont\'e. Cependant, le syst\`eme marche toujours (enfin, un peu...) car la racine n'est pas encore d\'emont\'ee car des fichiers sont encore ouverts et le d\'emontage est paresseux. \subsection{Premi\`ere id\'ee} Une idée serait de commenter l'entrée "root" (/) dans /etc/fstab. Ainsi, l'option "-a" de umount ne s\'electionnerait pas la racine et / ne se d\'emonterait pas \`a cette \'etape du script. De toute facon, la racine n'est pas montée avec fstab mais avec les options \emph{root=/dev/nfs} et \emph{nfsroot=/diskless/tftpboot/\%s} passées au noyau. J'ai fait le test. Le PC diskless d\'emarre correctement. XFree et XDM se lancent correctement mais KDE ne démarre plus (il se fige). Je ne sais pas pourquoi. De toute fa\,con, ce n'est sans doute pas une bonne id\'ee car d'autres programmes pourraient avoir besoin de /etc/fstab pour savoir d'o\`u est mont\'ee la racine. \subsection{La solution} La solution consiste \`a modifier le script d'arr\^et pour ne pas d\'emonter la racine. Le fichier \`a modifier est \emph{/etc/init.d/netfs}, ligne 97. J'ai donc remplac\'e ceci: \begin{verbatim} if [ "$retry" -lt 3 ]; then action "Unmounting NFS filesystems (retry): " umount -f -l -a -t nfs else action "Unmounting NFS filesystems: " umount -f -l -a -t nfs fi \end{verbatim} par ceci: \begin{verbatim} if [ "$retry" -lt 3 ]; then for repert in $remaining do action "Unmounting NFS filesystems $repert (retry): " umount -f -l $repert done else for repert in $remaining do action "Unmounting NFS filesystems $repert: " umount -f -l $repert done fi \end{verbatim} La variable \emph{\$remaining} contient la liste des montages \`a d\'efaire. Cette variable est d\'ej\`a remplie correctement par le script (c'est-\`a-dire elle ne contient pas "/", la racine), il n'y a donc rien d'autre \`a faire. Cela r\'esoud le probl\`eme: ces montages sont bien d\'emont\'es et /proc est toujours accessibles apr\`es ces d\'emontages. Le script peut donc continuer. De plus, cette m\'ethode est assez portable: si on d\'ecide de modifier les points de montage NFS, cela marchera toujours. L'autre solution non portable serait d'\'enumerer les montages NFS \`a d\'emonter dans le script. Il faudrait alors modifier le script d'arr\^et chaque fois que l'on d\'ecide d'ajouter un montage. \subsection{D'autres probl\`emes} Cependant, le script se bloque plus loin lors de l'arr\^et de l'interface r\'eseau eth0. En effet, cette interface r\'eseau pour acc\'eder au serveur NFS et est donc n\'ecessaire pour le montage NFS de la racine. Le probl\`eme se trouve dans le fichier \emph{/etc/init.d/network}, ligne 210 environ. Ce fichier est appel\'e avec l'argument "stop" car des liens se trouvent ici: \begin{verbatim} # ls -1 /etc/rc.d/rc?.d/???network /etc/rc.d/rc0.d/K90network /etc/rc.d/rc1.d/K90network /etc/rc.d/rc2.d/S10network /etc/rc.d/rc3.d/S10network /etc/rc.d/rc4.d/S10network /etc/rc.d/rc5.d/S10network /etc/rc.d/rc6.d/K90network # \end{verbatim} J'ai donc mis en commentaire les lignes suivantes (ligne 215): \begin{verbatim} if ! check_device_down $i; then action "Shutting down interface %s: " $i ./ifdown $i boot fi \end{verbatim} Depuis, le diskless s'arr\^ete correctement. \subsection{Conclusion} Pour r\'esumer, il faut: \begin{enumerate} \item Ne pas d\'emonter la racine avec "umount -f -l -a -t nfs" mais plut\^ot d\'emonter tous les montages NFS sauf la racine qui sera d\'emont\'e \`a part. \item Ne pas d\'ebrancher le r\'eseau en cours d'utilisation. \end{enumerate} De plus, comme le PC diskless a \'et\'e arr\^et\'e correctement, il ne se plaint pas au d\'emarrage et ne fait pas de fsck (file system check). \section{Probl\`eme des pilotes NVidia} Les pilotes NVidia sont un module nommé NVdriver du noyau linux. J'avais copié le fichier NVdriver.o ici: \begin{verbatim} /diskless/tftpboot/195.220.79.220/lib/modules/2.4.21-0.13mdk-diskless-pxe1/kernel/drivers/char/NVdriver.o \end{verbatim} Après le démarrage de la machine diskless, ce fichier se trouve au bon endroit, c'est à dire ici: \begin{verbatim} /lib/modules/2.4.21-0.13mdk-diskless-pxe1/kernel/drivers/char/ \end{verbatim} Mais ce module n'était pas chargé, bien que le fichier /etc/modules et /etc/modules.conf étaient corrects. Donc XFree ne démarrait pas. Pourtant, on pouvait tout à fait taper "insmod NVdriver" avec succès. Par contre, "modprobe NVdriver" ne marchait pas. Et c'est modprobe qui est utilisé dans les scripts de démarrage. En fait l'explication est la suivante: le répertoire /lib/modules/.../ de la machine diskless est monté à partir d'un export NFS du serveur. Pendant l'exécution des scripts de démarrage, /lib/ est en fait: \begin{verbatim} /diskless/lib/ \end{verbatim} Ensuite, la partition /lib/ est montée à partir de: \begin{verbatim} /diskless/tftpboot/195.220.79.220/lib/ \end{verbatim} Les scripts de démarrage fonctionnent ainsi: \begin{enumerate} \item La partition / est montée par NFS \item depmod est lancé pour trouver tous les modules et leurs dépendances. \item /etc/modules est lu pour charger les bons modules \item La partition /lib/ et autres sont montées par NFS. Elles cachent les fichiers qui étaient à l'emplacement du montage. \end{enumerate} Il faut donc mettre le module NVdriver.o dans le répertoire /diskless/lib/... pour que le module soit chargé automatiquement. Mais il faut aussi le mettre dans /diskless/tftpboot/195.220.79.220/lib/... pour pouvoir charger le module manuellement avec modeprobe/insmod par la suite. Au départ, je n'avais mis le module que dans un répertoire, ce qui explique que le module ne pouvait pas se lancer automatiquement et qu'on pouvait le lancer manuellement avec insmod. Par contre, on ne pouvait pas lancer le module avec modprobe car modprobe utilise les calculs de dépendances effectués par depmod dans les scripts de démarrage. Et pout depmod, il n'y avait pas de module NVdriver. Maintenant, on le module se charge automatiquement et on peut le décharger avec rmmod puis le recharger avec insomod ou modprobe. \section{Conflits entre serveurs DHCP} Un serveur DHCP permet d'attribuer automatiquement des adresses IP aux clients qui font une requ\^ete DHCP. Le serveur peut \^etre configur\'e pour donner une adresse libre quelconque dans une plage d'adresse ou pour donner une IP fixe aux clients dont l'adresse MAC est connue. Dans notre cas, chaque PC diskless se voit attribuer une adresse IP fixe ; le serveur DHCP conna\^it donc les adresses MAC de toutes les cartes r\'eseaux des PC diskless. Pour d\'emarrer, le PC diskless a besoin d'un serveur DHCP pour deux raisons: \begin{enumerate} \item Si le PC diskless boote en utilisant le protocole PXE: quand le PC boote sur le réseau en utilisant le protocole PXE, il émet une requête DHCP pour trouver ses paramètres réseaux. Ces paramètres réseaux vont servir pour demander à un serveur TFTP le noyau du système d'exploitation. Si le PC diskless n'utilise pas PXE, seule la deuxi\`eme raison est correcte. \item Une fois le système d'exploitation lancé, celui-ci fait une requête DHCP pendant les scripts de d\'emarrage pour trouver ses paramètres réseaux. Le r\'eseau sera utilis\'e notamment pour les montages NFS. Cette seconde requête est nécessaire car le syst\`eme d'exploitation ne peut pas savoir qu'une requête DHCP a déjà été faite. \end{enumerate} Il faut donc un serveur DHCP. Cependant, sur le même réseau physique que mes machines de tests, un serveur DHCP l\'egitime est déjà présent. Il est tout à fait possible d'utiliser le serveur DHCP déjà présent mais je n'ai pas accès à ce serveur. De plus avoir un serveur DHCP pour chaque type d'utilisation est plus facile à administrer. J'ai donc configuré le serveur DHCP qui va servir au PC diskless. Le problème est de ne pas interférer avec le serveur DHCP légitime déjà en place. La solution est l'option suivante dans le fichier /etc/dhcp.conf: \begin{verbatim} deny unknown-clients; \end{verbatim} Cette option indique au serveur DHCP d'ignorer les requ\^etes des PC diskless dont l'adresse MAC n'est pas connue. Voici le fichier de configuration utilisé: \begin{verbatim} # allow booting # allow bootp ddns-update-style none; subnet 195.220.79.0 netmask 255.255.255.0 { # default gateway option routers 195.220.79.250; option subnet-mask 255.255.255.0; option domain-name "obs.ujf-grenoble.fr"; option domain-name-servers 195.220.79.11; deny unknown-clients; # Adresses dynamiques # range dynamic-bootp 195.220.79.124 195.220.79.125; # Adresses statiques affectees aux PC diskless bootant # a travers PXE #une directive "host" pour chaque diskless # l'option next-server donne l'adresse IP du serveur de boot # filename donne le nom de fichier de boot (attention, pas # le noyau linux) host gag220 { allow booting; hardware ethernet 00:07:95:C6:9F:A8; fixed-address 195.220.79.220; # Pour la methode de boot avec CDROM, on s'arrete la. # Pour les autres methodes, il faut rajouter l'IP du serveur # next-server 195.220.79.217; # et le fichier a telecharger: # filename "/pxelinux.0"; # Le chemin est 'relatif' au chemin donne à xinetd/tftpd } } \end{verbatim} Avec cette configuration, les autres clients du réseau ne sont pas dérangés par le nouveau serveur DHCP. car ce dernier ignore leurs requ\^etes. Le second problème est que l'ancien serveur DHCP répond aux requêtes du nouveau client. Le nouveau client recoit donc des réponses des deux serveurs DHCP. C'est le plus rapide qui gagne. Heureusement, le bon serveur répond souvent plus rapidement, sans doute parce qu'il est plus près en nombre de switch à traverser. Il faut modifier la configuration de l'ancien serveur DHCP pour qu'il ignore les requêtes qui ne le concerne pas. Pour cela, on utilise aussi l'option "deny unknown-clients;". \section{NFS lockd} Au d\'emarrage du PC diskless, les scripts de d\'emarrage peuvent afficher: \begin{verbatim} NFS lockd: chdir(/var/lib/nfs) failed: No such file or directory \end{verbatim} Voici ce que contient /var/lib/nfs: /var/lib/nfs/etab contains information about what filesystems should be exported to whom at the moment. /var/lib/nfs/rmtab contains a list of which filesystems actually are mounted by certain clients at the moment. /var/lib/nfs/xtab is the same information as /proc/fs/nfs/exports but is maintained by nfs-utils instead of directly by the kernel. It is only used if /proc isn't mounted. /tftpboot/195.220.79.xxx/var/lib est un lien symbolique vers /commun/lib. Or /commun n'est pas encore monté lorsque NFS lockd est lanc\'e. Actuellement, le /var/lib/nfs de chaque PC diskless sont communs entre les PC diskless car il se trouve dans /diskless/tftpboot/commun sur le serveur. Mais il faut que le /var/lib/nfs de chaque PC diskless ne soit pas partag\'e entre les PC diskless pour deux raisons: \begin{enumerate} \item NFS lockd doit \^etre d\'emarr\'e avant le montage des r\'epertoires NFS des PC diskless. Or, les fichiers communs ne sont accessibles que par un partage NFS. \item Le r\'epertoire /var/lib/nfs contient des informations qui par nature ne doivent pas \^etre partag\'ees. En effet, celles-ci renseignent sur l'activit\'e NFS du PC diskless qui ne sera pas la m\^eme d'un PC diskless \`a l'autre. \end{enumerate} Mettre un r\'epertoire /var/lib/nfs non partag\'e entre les PC diskless r\'esoud le probl\`eme. \section{Message "chgrp: invalid group name: utmp"} Le message suivant peut appara\^itre au d\'emarrage de la machine: \begin{verbatim} chgrp: invalid group name: utmp \end{verbatim} Le probl\`eme est maintenant r\'esolu. En suivant la m\'ethode d\'ecrite dans la partie Installation du serveur de diskless, vous ne devriez pas avoir ce probl\`eme. Ce probl\`eme se produisait lorsque les fichiers d'authentification (/etc/group, /etc/shadow et /etc/passwd) n'\'etaient pas partag\'es correctement. Le problème vient du fichier /etc/rc.d/rc.sysinit, ligne 930. La ligne est: \begin{verbatim} chgrp utmp /var/run/utmp /var/log/wtmp \end{verbatim} Pour connaitre le GID de utmp, le script a besoin de /etc/group. Le fichier /etc/group est commun à tous les diskless. Pour le rendre commun, il se trouve dans un endroit unique: /diskless/tftpboot/commun/. Des liens symboliques /'etaient faits dans tous les répertoires /etc des diskless vers les fichiers correspondants situés sous /diskless/tftpboot/commun. Or, /commun n'est pas encore monté par NFS à cette étape du script, sur le diskless. Celui-ci ne peut donc pas résoudre le lien symbolique. Solution: au lieu de faire un lien symbolique que le diskless est incapable de résoudre, j'ai fait un lien dur. Ainsi, ce sera le serveur qui résoudra le lien. Document sur les liens et NFS: \htmladdnormallink{http://ou800doc.caldera.com/SDK\_sysprog/\_Using\_Symbolic\_Links\_with\_NFS.html}{http://ou800doc.caldera.com/SDK\_sysprog/\_Using\_Symbolic\_Links\_with\_NFS.html} Mettre des liens durs est aussi utile pour les autres fichiers de /commun pour les mêmes raisons. \section{Impossible de trouver les modules dans /lib/modules/2.4.21-01} Les modules du noyau se trouvent normalement dans: \begin{verbatim} /lib/modules/`uname -r` \end{verbatim} O\`u \emph{uname -r} repr\'esente le num\'ero de version du noyau. Ici, les modules du noyau sont cherch\'es dans le mauvais r\'epertoire: il les cherche dans /lib/modules/2.4.21-01 au lieu de les chercher dans /lib/modules/2.4.21-0.13mdk-diskless-pxe1. Ce cas se produit lorsque les modules du diskless sont copi\'es sans utiliser l'option \emph{-a} de \emph{cp}. L'option -a permet de garder la structure et les attributs du fichier original lors de la copie. Le probl\`eme est r\'esolu en recopiant les modules en utilisant l'option \emph{-a} de \emph{cp}. % ################################################## \part{Utilisation du disque dur du diskless} % ################################################## \section{Introduction} But: \begin{enumerate} \item Swapper \item Stockage de fichiers utilisateurs: acc\`es plus rapide \item Possibilit\'e de d'installer un syst\`eme complet ult\'erieurement \item D\'emarrer sur le disque dur avec Grub en tant que diskless pour se passer du CDROM de d\'emarrage. \end{enumerate} Le script \emph{dkl-fdisk.sh} et son fichier de configuration \emph{partitions.fdisk} sont faits pour cela. Ces deux fichiers doivent \^etre plac\'es dans /commun/fdisk. En \'ex\'ecutant ce script en root \`a partir du diskless, il va faire les choses suivantes: \begin{enumerate} \item Effacer toutes les partitions de tous les disques durs. \item Recr\'eer des partitions et les formatter. \item Indiquer ce qu'il faut ajouter dans /etc/fstab pour que le PC diskless puisse monter les nouvelles partitions. \end{enumerate} Les partitions cr\'ees sont les suivantes: \begin{enumerate} \item 10 Go - Partition pr\^ete pour une utilisation ult\'erieure. \item 512 Mo - Swap pour le PC diskless. \item Reste - Mont\'ee sur /local pour le PC diskless. \end{enumerate} \section{Installation sur le serveur} Cr\'eer le r\'epertoire /commun/fdisk contenant: \begin{verbatim} /commun/fdisk | - partitions.fdisk: fichier de configuration de dkl-fdisk.sh | - dkl-fdisk.sh: script d'installation sur le disque dur du diskless | - grub | - vmlinuz-diskless: noyau du diskless | - stage1: fichier binaire de Grub | - stage2: fichier binaire de Grub | - menu.lst: fichier de configuration de Grub \end{verbatim} Voici un exemple du fichier menu.lst: \begin{verbatim} timeout 30 default 0 title Demarrer en tant que diskless kernel (hd0,0)/grub/vmlinuz-diskless root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=/diskless/tftpboot/%s title Demarrer a partir du disque dur kernel (hd0,0)/boot/vmlinuz root=/dev/hde1 devfs=mount vga=788 initrd (hd0,0)/boot/initrd.img title Disquette root (fd0) chainloader +1 \end{verbatim} \section{Installation sur le diskless} Lancer /commun/fdisk/dkl-fdisk.sh. % ################################################## \clearpage \appendix \part{Annexes} % ################################################## \section{Glossaire} \paragraph{Adresse IP}\label{def:adresseip}~: S\'erie de 4 nombres identifiant un ordinateur sur un r\'eseau. S'\'ecrit sous la forme: "195.220.97.220". \paragraph{Bios}\label{def:bios}~: Basic Input-Output System? \paragraph{Boot}\label{def:boot}~: D\'emarrer. Un ordinateur peut d\'emarrer un syst\`eme d'exploitation accessible sur le r\'eseau, une disquette, un disque, \paragraph{DHCP}\label{def:dhcp}~: Un serveur DHCP permet d'attribuer des adresses IP aux clients qui en font la requ\^ete. \paragraph{Diskless}\label{def:diskless}~: Un PC sans disque ou "PC diskless" est un poste de travail dont le disque s'il en a un, n'est pas dédié au système Linux. Celui-ci sera chargé au "boot" du PC, via le réseau à partir d'un serveur distant. \paragraph{GNU/Linux}\label{def:gnulinux}~: D\'esigne le syst\`eme d'exploitation compos\'e du noyau linux et des programmes GNU. \paragraph{Grille de calcul}\label{def:grilledecalcul}~: Ensemble d'ordinateurs travaillant en collaboration pour faire des calculs intensifs distribu\'es. \htmladdnormallink{http://www.urec.cnrs.fr/publications/JRES01.Datagrid.pdf}{http://www.urec.cnrs.fr/publications/JRES01.Datagrid.pdf} \paragraph{GRUB}\label{def:grub}~: Chargeur de d\`emarrage, tout comme LILO. Mais GRUB est plus pratique et poss\`ede plus de fonctionnalit\'es. \paragraph{Inode}\label{def:inode}~: Tous les fichiers d'une m\^eme partition poss\`edent un num\'ero unique appel\'e indode. \paragraph{LILO}\label{def:lilo}~: LInux LOader. Petit logiciel se pla\,cant au d\'ebut du disque et permettant de charher Linux au d\'emarrage de l'ordinateur. \paragraph{Lien dur}\label{def:liendur}~: Aussi appel\'e lien mat\'eriel. Fonctionnalit\'es sous UNIX permettant qu'un fichier soit pr\'esent dans plusieurs r\'epertoire \`a la fois. \paragraph{Linux}\label{def:linux}~: Nom du noyau de syst\`eme d'exploitation utilis\'e au LAOG. \paragraph{Monter}\label{def:monter}~: Monter un disquette, un CDROM. \paragraph{PXE}\label{def:pxe}~: Pre-boot Execution Environment. Protocole impl\'ement\'e dans certaines cartes r\'eseau permettant de d\'emarrer l'ordinateur non pas sur le disque ou une disquette mais sur le r\'eseau en utilisant un serveur DHCP et TFTP. \paragraph{PXE}\label{def:pxegrub}~: Pre-boot Execution Environment impl\'ement\'e par le logiciel Grub. \paragraph{NFS}\label{def:nfs}~: Network File System. Syst\`eme de fichiers en r\`eseau. \paragraph{Serveur de diskless}\label{def:serveurdediskless}~: Serveur qui va permettre aux PC diskless de d\'emarrer. \paragraph{Terminal X}\label{def:terminalx}~: Console permettant d'utiliser des applications graphiques sur un serveur. Les TX n'ont souvent aucun disque. \paragraph{TFTP}\label{def:tftp}~: Protocole de transfert de fichiers, similaire \`a FTP mais simplifi\'e. \paragraph{XFree}\label{def:xfree}~: Logiciel permettant d'afficher des applications graphiques utilis\'e sur les syst\`emes UNIX. \section{Arborescence du serveur de diskless} \begin{verbatim} /diskless | - CDROM | | - isos : les images des CD seront placees ici | | - root : correspond a la racine du CD | | - isolinux : contient le binaire d'isolinux et son fichier de config. | | - alt0 : contient le noyau vmlinuz | - scripts | - shares | | - commun | | - bin, sbin, home, lib, usr, opt | - tftpboot | - pxelinux.cfg | - 195.220.79.220 | - 195.220.97.242 \end{verbatim} \section{Machines de tests} J'ai eu deux machines de tests. Voici leurs adresses IP et MAC. $$ \begin{array}{lll} & Serveur & Diskless \\ Nom & gag217 & gag220 \\ MAC & 00:07:95:4E:B9:D9 & 00:07:95:C6:9F:A8 \\ IP & 195.220.79.217 (IP fixe) & 195.220.79.220 (DHCP) \\ IP en hexa & C3 DC 4F DC & C3 DC 4F DF \end{array} $$ \`A partir de la troisi\`eme semaine de mon stage, j'ai eu un autre PC de test. Celui-ci a servi de deuxi\`eme PC diskless: $$ \begin{array}{ll} & Second Diskless \\ Nom & gag242 \\ MAC & 00:d0:b7:c4:dc:ba \\ IP & 195.220.79.242 (DHCP) \end{array} $$ gag217 (le serveur de diskless) et gag220 (le premier PC diskless) ont exactement le m\^eme mat\'eriel. Cela ne posait donc pas trop de probl\`emes. Mais gag242 (le deuxi\`eme PC diskless) n'a pas le m\^eme mat\'eriel. Pour r\'ecup\'erer l'adresse MAC d'un PC diskless, on peut proc\'eder de la mani\`ere suivante: \begin{enumerate} \item S'assurer que le serveur DHCP tourne et surveiller /etc/log/messages (avec la commande tail -f /etc/log/messages). \item D\'emarrer le PC diskless sur le CD pour qu'il fasse une requ\^ete DHCP. \item L'adresse IP appara\^it dans /etc/log/messages, par exemple: "DHCPDISCOVER from 00:d0:09:71:a0:f5". \end{enumerate} \section{Fichiers XF86Config-4} Voici deux fichiers XF86Config-4. \subsection{Fichier du diskless gag220} \begin{verbatim} Section "Files" # Multiple FontPath entries are allowed (they are concatenated together) # By default, Mandrake 6.0 and later now use a font server independent of # the X server to render fonts. RgbPath "/usr/X11R6/lib/X11/rgb" #FontPath "tcp/195.220.79.217:7100" FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/drakfont" FontPath "/usr/X11R6/lib/X11/fonts/drakfont/Type1" FontPath "/usr/X11R6/lib/X11/fonts/drakfont/ttf" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/X11R6/lib/X11/fonts/TTF" FontPath "/usr/X11R6/lib/X11/fonts/Speedo" FontPath "/usr/X11R6/lib/X11/fonts/pcf\_drakfont:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/mdk:unscaled" FontPath "/usr/share/fonts/default/Type1" FontPath "/usr/share/fonts/ttf/western" FontPath "/usr/share/fonts/ttf/decoratives" EndSection Section "ServerFlags" AllowMouseOpenFail # allows the server to start up even if the mouse doesn't work EndSection Section "Module" Load "dbe" # Double-Buffering Extension Load "v4l" # Video for Linux Load "extmod" Load "type1" Load "freetype" Load "/usr/X11R6/lib/modules/extensions/libglx.so" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "Keyboard" Option "XkbModel" "pc105" Option "XkbLayout" "fr" Option "XkbCompat" "" Option "XkbOptions" "" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/psaux" Option "Emulate3Buttons" Option "Emulate3Timeout" "50" EndSection Section "Monitor" Identifier "monitor1" VendorName "Plug'n Play" HorizSync 30-96 VertRefresh 50-160 # Sony Vaio C1(X,XS,VE,VN)? # 1024x480 @ 85.6 Hz, 48 kHz hsync ModeLine "1024x480" 65.00 1024 1032 1176 1344 480 488 494 563 -hsync -vsync # TV fullscreen mode or DVD fullscreen output. # 768x576 @ 79 Hz, 50 kHz hsync ModeLine "768x576" 50.00 768 832 846 1000 576 590 595 630 # 768x576 @ 100 Hz, 61.6 kHz hsync ModeLine "768x576" 63.07 768 800 960 1024 576 578 590 616 EndSection Section "Device" Identifier "device1" VendorName "nVidia Corporation" BoardName "RIVA TNT2" Driver "nvidia" Option "DPMS" EndSection Section "Screen" Identifier "screen1" Device "device1" Monitor "monitor1" DefaultColorDepth 24 Subsection "Display" Depth 8 Modes "1024x768" "800x600" "640x480" EndSubsection Subsection "Display" Depth 15 Modes "1024x768" "800x600" "640x480" EndSubsection Subsection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" EndSubsection Subsection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" EndSubsection EndSection Section "ServerLayout" Identifier "layout1" InputDevice "Keyboard1" "CoreKeyboard" InputDevice "Mouse1" "CorePointer" Screen "screen1" EndSection \end{verbatim} \subsection{Fichier du diskless gag220} \begin{verbatim} Section "Files" # Multiple FontPath entries are allowed (they are concatenated together) # By default, Mandrake 6.0 and later now use a font server independent of # the X server to render fonts. RgbPath "/usr/X11R6/lib/X11/rgb" #FontPath "tcp/195.220.79.217:7100" FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/drakfont" FontPath "/usr/X11R6/lib/X11/fonts/drakfont/Type1" FontPath "/usr/X11R6/lib/X11/fonts/drakfont/ttf" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/X11R6/lib/X11/fonts/TTF" FontPath "/usr/X11R6/lib/X11/fonts/Speedo" FontPath "/usr/X11R6/lib/X11/fonts/pcf_drakfont:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/mdk:unscaled" FontPath "/usr/share/fonts/default/Type1" FontPath "/usr/share/fonts/ttf/western" FontPath "/usr/share/fonts/ttf/decoratives" EndSection Section "ServerFlags" AllowMouseOpenFail # allows the server to start up even if the mouse doesn't work EndSection Section "Module" Load "dbe" # Double-Buffering Extension Load "v4l" # Video for Linux Load "extmod" Load "type1" Load "freetype" Load "/usr/X11R6/lib/modules/extensions/libglx.so" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "Keyboard" Option "XkbModel" "pc105" Option "XkbLayout" "us_intl" Option "XkbCompat" "" Option "XkbOptions" "" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/psaux" Option "Emulate3Buttons" Option "Emulate3Timeout" "50" EndSection Section "Monitor" Identifier "monitor1" VendorName "Plug'n Play" HorizSync 30-96 VertRefresh 50-160 # Sony Vaio C1(X,XS,VE,VN)? # 1024x480 @ 85.6 Hz, 48 kHz hsync ModeLine "1024x480" 65.00 1024 1032 1176 1344 480 488 494 563 -hsync -vsync # TV fullscreen mode or DVD fullscreen output. # 768x576 @ 79 Hz, 50 kHz hsync ModeLine "768x576" 50.00 768 832 846 1000 576 590 595 630 # 768x576 @ 100 Hz, 61.6 kHz hsync ModeLine "768x576" 63.07 768 800 960 1024 576 578 590 616 EndSection Section "Device" Identifier "device1" VendorName "nVidia Corporation" BoardName "RIVA TNT2" Driver "ati" #Driver "nvidia" Option "DPMS" EndSection Section "Screen" Identifier "screen1" Device "device1" Monitor "monitor1" DefaultColorDepth 24 Subsection "Display" Depth 8 Modes "1024x768" "800x600" "640x480" EndSubsection Subsection "Display" Depth 15 Modes "1024x768" "800x600" "640x480" EndSubsection Subsection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" EndSubsection Subsection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" EndSubsection EndSection Section "ServerLayout" Identifier "layout1" InputDevice "Keyboard1" "CoreKeyboard" InputDevice "Mouse1" "CorePointer" Screen "screen1" EndSection \end{verbatim} \section{Ce qu'il reste \`a faire} \subsection{Vitesse de KDE} Accelerer KDE avec startkde... PC diskfull: 16 secondes PC diskless: 28 secondes \section{Scripts} Les scripts sont peuvent \^etre t\'el\'echarg\'es ici: \htmladdnormallink{http://alban.apinc.org}{http://alban.apinc.org} Voici le listing des scripts et des exemples de fichiers de configuration. \subsection{dkl-init-serveur.sh} \verbatiminput{../scripts/dkl-init-serveur.sh} \subsection{dkl-init-diskless.sh} \verbatiminput{../scripts/dkl-init-diskless.sh} \subsection{dkl-diskless-menage.sh} \verbatiminput{../scripts/dkl-diskless-menage.sh} \subsection{dkl-liens-durs.sh} \verbatiminput{../scripts/dkl-liens-durs.sh} \subsection{dkl-liens-durs-1diskless.sh} \verbatiminput{../scripts/dkl-liens-durs-1diskless.sh} \subsection{dkl-1lien-dur-diskless.sh} \verbatiminput{../scripts/dkl-1lien-dur-diskless.sh} \subsection{dkl-1lien-dur-1diskless.sh} \verbatiminput{../scripts/dkl-1lien-dur-1diskless.sh} \subsection{dkl-suppr-1lien-dur-diskless.sh} \verbatiminput{../scripts/dkl-suppr-1lien-dur-diskless.sh} \subsection{dkl-suppr-1lien-dur-1diskless.sh} \verbatiminput{../scripts/dkl-suppr-1lien-dur-1diskless.sh} \subsection{dkl-tftp-start.sh} \verbatiminput{../scripts/dkl-tftp-start.sh} \subsection{dkl-graver-cdrom.sh} \verbatiminput{../scripts/dkl-graver-cdrom.sh} \subsection{dkl-syslogd.sh} \verbatiminput{../scripts/dkl-syslogd.sh} \subsection{dkl-paquetage-install.sh} \verbatiminput{../scripts/dkl-paquetage-install.sh} \subsection{dhcpd.conf-exemple.txt} \verbatiminput{../scripts/exemples/dhcpd.conf-exemple.txt} \subsection{exports-exemple.txt} \verbatiminput{../scripts/exemples/exports-exemple.txt} \subsection{fstab-exemple.txt} \verbatiminput{../scripts/exemples/fstab-exemple.txt} \subsection{isolinux.cfg} \verbatiminput{../scripts/isolinux.cfg} \section{\`A propos de ce document} Ce document et les scripts qui l'accompagnent sont disponibles sur: \htmladdnormallink{http://alban.apinc.org/}{http://alban.apinc.org/} Ce document a \'et\'e \'ecrit par Alban Cr\'equy pendant son stage au LAOG du 1 juillet au 8 ao\^ut. Son utilisation en dehors d'un cadre privé est interdit sauf accord préalable. \end{document}