![[*]](crossref.png)
Alban Créquy
Été 2003
Des méthodes de boot pour des PC Linux sans disque ont été mises au point. Je dois faire une synthèse de ces méthodes, rechercher de nouvelles méthodes et les mettre au point, puis éditer un manuel utilisateur de toutes ces méthodes.
Un parc informatique contenant plusieurs dizaines/centaines/milliards (rayer les mentions inutiles) de PC ne peut pas être géré sans méthode.
Le but de l'administrateur est de gérer les différentes ressources sur le réseau. Ces ressources sont:
Il existe plusieurs grands modèles pour gérer ces ressources. Je vais décrire brièvement trois catégories: celle des clients lourds, celle des terminaux X et celle des PC diskless (PC sans disque).
).
)
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.
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 être accessibles via NFS sur un serveur d'applications. Les grands espaces disques nécessaires aux simulations, modélisations, dépouillement de données sont servis par des serveurs de RAID.
Les PC bootaient sur une disquette contenant LILO
(voir glossaire page )
et le noyau Linux. Tous les systèmes
de fichiers étaient montés par NFS
(voir glossaire page ).
La disquette allait donc
chercher les fichiers système sur le serveur.
Mais depuis, les noyaux Linux sont devenus trop grop
pour être mis sur une disquette.
Chercher à réduire l'espace utilisé par le noyau sur la disquette
n'est pas une solution car le noyau risque de continuer à grossir au
fil du temps.
Cette méthode n'est donc plus utilisée.
Les PC diskless démarrent sur le réseau en utilisant le protocole de
démarrage PXE (voir glossaire page ).
PXE permet de booter sur le réseau. Concrétement, au démarrage du
PC diskless, le BIOS (glossaire page ) donne la main
au programme PXE qui se trouve sur la carte réseau. Ce programme fait
une requête DHCP (glossaire page ) pour trouver
un serveur qui lui donnera son adresse IP
(glossaire page ) et le nom du serveur qui lui
permettra de télécharger le noyau avec TFTP
(glossaire page ).
Ce protocole s'est bien développé: une bonne partie des cartes réseaux du LAOG supportent PXE. Toutes les nouvelles cartes réseaux le supporte.
Mais toutes les cartes réseaux ne supportent pas PXE. Il faut donc trouver d'autres méthodes pour ces PC.
De plus, la méthode utilisée pour administrer les diskless doit être améliorée pour corriger certains problèmes et faciliter l'administration.
Lorsqu'un PC démarre, il doit trouver son système d'exploitation, le charger et l'éxécuter. C'est ce qu'on appelle le boot.
Dans le cas de GNU/Linux, la méthode la plus employée est la suivante:
) possède plusieurs
options de démarrage: disque dur, CD, etc. La valeur la plus courante
de cette option est de démarrer sur le disque dur.
Mais dans le cas d'un diskless, le disque ne doit pas être utilisé pour héberger le système d'exploitation. Il faut donc trouver d'autres méthodes de boot.
La méthode utilisée au LAOG actuellement est la méthode de boot
par réseau avec le protocole PXE (glossaire ).
Je vais d'abord décrire cette méthode puis les différentes méthodes que j'ai trouvé.
Une documentation sur PXE existe sur:
http://clic.mandrakesoft.com/documentation/pxe/
Ce paragraphe est tiré de:
http://sari.inpg.fr/rubriques/themes/zone_publique.groupe_linux/diskless/serveur-diskless.html
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:
Après le chargement, exécution de ce fichier qui, toujours par une connection TFTP :
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.
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éjà fait par le script dkl-init-serveur.sh, cf. partie Installation).
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é dans l'archive diskless-kit.tar.gz (cf. partie Scripts en annexe).
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":
#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
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 :
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élécharger ce noyau par le réseau.
Une solution est d'utiliser PxeGrub
(page ).
Le diskless démarre 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.
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éseaux reconnues par Linux ne sont pas reconnues par PxeGrub.
La liste des cartes réseaux reconnues par PxeGrub n'est pas la même que la liste des cartes compatibles PXE (ca n'a rien à voir). Pour qu'une carte réseau soit compatible PXE, il faut que le protocole PXE soit programmé dans la puce de la carte réseau. Selon les modéles, une carte réseau peut ou pas être compatible PXE. Mais pour qu'une carte soit reconnue par PxeGrub, il faut que les développeurs du logiciel PxeGrub écrive le pilote de cette carte pour PxeGrub. PxeGrub est en cours de développement et tous les pilotes ne sont pas disponibles.
Cette méthode n'est pas retenue car les PC diskless doivent marcher sur tous les PC du LAOG.
Liste des cartes compatibles GRUB:
http://etherboot.sourceforge.net/db/
Un "PC diskless" peut très bien avoir un disque dur. PC diskless veut simplement dire que le disque dur n'est pas utilisé pour le système.
Dans cette partie, nous allons utiliser le disque dur pour démarrer le système mais on utilisera toujours NFS-Root (la racine du système sera montée par NFS). L'espace utilisé sur le disque dur du PC diskless sera environ 2 Mo.
Le noyau linux sera placé sur une partition déjà existante (ext2, ext3, ou vfat...) dans le répertoire /Grub. Grub sera installé sur le disque dur et proposera au démarrage de la machine un menu. L'utilisateur pourra choisir entre booter sur le réseau ou démarrer le système présent sur le disque dur, s'il existe. Grub peut ainsi démarrer de nombreux systèmes d'exploitation, dont Linux et Windows.
Avant de commencer, assurez vous qu'un partition est déjà présente sur le disque dur avec suffisamment d'espace libre (2 ou 3 Mo).
Grub est maintenant installé.
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:
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
Grub numérote les disques durs à partir de 0 (hd0, hd1) tandis que Linux les numérote à avec des lettres partir de a (hda, hdb).
Les partitions sont aussi numérotées à partir de 0 ((hd0,0), (hd0,1)) tandis que Linux commence à 1 (hda1, hda2).
Avec ce fichier de configuration, l'utilisateur aura le choix entre trois démarrage possibles:
Il faut ensuite copier le noyau du diskless sur /grub/vmlinuz-diskless.
Le répertoire /grub (sur le disque du diskless) doit donc contenir ces 4 fichiers:
Le PC diskless démarre sur le disque dur. Sur ce disque dur, il y a Grub. Celui-ci propose à l'utilisateur de démarrer en tant que diskless. En sélectionnant ce choix, Grub charge le noyau qui se trouve dans le répertoire /grub du disque dur. Les modules et la racine du système se trouvent comme d'habitude sur le serveur de diskless.
Un CD bootable est un CD, qui, inséré au démarrage de l'ordinateur permet de charger un système d'exploitation. Ce système d'exploitation peut être sur le CD (comme par exemple le système Knoppix) ou il peut être téléchargé sur un serveur (c'est le cas pour un PC diskless).
J'ai étudié plusieurs méthodes pour faire un CD bootable. Ma première piste était de faire un CD au format El Torito. Puis j'ai trouvé un outil bien pratique: isolinux.
Première possibilité: faire un CD au format "El Torito".
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éation d'image de CD: mkisofs.
En fait, quand le BIOS doit démarrer 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 émulant une disquette (ou le disque dur). Cette émulation se fait en changeant les fonctions du BIOS qui permettent d'accéder à la disquette ou au disque dur. Ainsi, une fois le système d'exploitation chargé, il croit qu'il se trouve sur une disquette (ou un disque dur).
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.
Cette première possibilité n'est donc pas utilisée.
Description du format de CD El Torito:
http://www.phoenix.com/resources/specs-cdrom.pdf
Le site de isolinux:
http://syslinux.zytor.com/iso.php
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.
Isolinux fonctionne sans émulation 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.
Voici les Étapes de la méthode que nous allons mettre en place:
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:
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
Voici ce que veut dire chaque ligne de ce fichier:
Voici la signification des paramètres passés au noyau linux:
Isolinux va donc nous permettre de démarrer le noyau à partir 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:
/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
Cette arborescence est crée automatiquement par le script dkl-init-serveur.sh. Voici ce qui doit être présent dans /diskless/CDROM/root/:
Tous ces fichiers sont disponibles, voir la partie Scripts en annexe.
Le script /diskless/scripts/dkl-init-diskless.sh a déjà crée les répertoires dans /diskless/CDROM décrits 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é à 8 caractères.
cp -a /diskless/tftpboot/bzImage-diskless-pxe1 \
/diskless/CDROM/root/isolinux/alt0/vmlinuz
Modifier le fichier /diskless/CDROM/root/isolinux/isolinux.cfg pour mettre à jour l'IP du serveur comme expliqué dans la partie Introduction à isolinux.
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:
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/
) du CD bootable.
Une fois le script dkl-graver-cdrom.sh lancé, l'image se trouve dans /diskless/CDROM/isos/iso1.iso. Il ne reste plus qu'à graver l'image.
Cette image de CD peut être gravée comme n'importe quelle autre image. Par exemple, on peut utiliser cdrecord:
cdrecord dev=0,0,0 blank=fast -eject /diskless/CDROM/isos/iso1.iso
Un CD bootable générique 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émarrer 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!
Avec la méthode précédente, 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):
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
L'adresse IP 195.220.79.220 est l'adresse IP du client. Celle-ci diffère sur chaque diskless. Le point d'où doit être montée la racine de notre diskless n'est pas constante.
Le chemin à accéder sur le serveur ( /diskless/tftpboot/195.220.79.220 ) doit être écrit sur le CD. Il faut donc:
Malheureusement, le serveur NFS de Linux ne permet pas ca... Cette idée n'est donc pas applicable!
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 être écrite sur le CD car elle est différente pour chaque diskless. La solution se trouve en fait dans la documentation de Linux sur:
/usr/src/linux/Documentation/nfsroot.txt
Il s'agit de l'option "nfsroot" que l'on passe au noyau. Il est dit:
If there is a "%s" token in the string, the token will be
replaced by the ASCII-representation of the client's IP
address.
Le fichier de configuration isolinux.cfg doit donc contenir:
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
Ainsi, le noyau va remplacer %s par l'adress IP qu'il a obtenue par DHCP. Le chemin sera donc formé 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:
default linux prompt 0 label linux KERNEL alt0/vmlinuz APPEND root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=/diskless/tftpboot/%s
Avec cette dernière solution, voici les étapes du boot qui seront effectuées:
Ainsi, le CD marchera quel que soit le diskless et quel que soit le serveur. Les seules contraintes sont:
Pour mettre au point la méthode, j'ai du effectuer de nombreux gravage. Mais utilisant un CD réinscriptible, aucun CD n'a été gaspillé.
Cette méthode marche tout aussi bien que la précédente et permet d'avoir un CD unique pour tout le LAOG.
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: http://syslinux.zytor.com/iso.php
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:
/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
Cette arborescence est crée automatiquement par le script dkl-init-serveur.sh. Voici ce qui doit être présent dans /diskless/CDROM/root/:
Ces deux fichiers ont été copié par dkl-init-serveur.sh. Les deux fichiers sont donc déjà présents. Si vous voulez récupérer la dernière version, téléchargez l'archive de syslinux sur http://www.kernel.org/pub/linux/utils/boot/syslinux/. Le fichier isolinux.bin se trouve dans l'archive.
La création de CD se fait en 5 étapes:
Le noyau se trouve ici: /diskless/tftpboot/bzImage-diskless-pxe1. Il faut le copier dans l'arborescence du CD:
cp -a /diskless/tftpboot/bzImage-diskless-pxe1 \
/diskless/CDROM/isolinux/alt1/vmlinuz
Par convention, on appelle le noyau vmlinuz car le nom est limité à 8 caractères.
Il se trouve sous /diskless/CDROM/root/isolinux/isolinux.cfg. Pas besoin de le modifier, il est correct. Voici un exemple:
# 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
Explications:
L'option qui nous intéresse pour un PC diskless est la ligne d'options à passer au noyau. Voici leurs significations:
Créer l'image. Cela se fait avec le script dkl-graver-cdrom.sh qui se lance sans argument. Ce script va créer l'image avec mkisofs.
Voici ce qu'il contient:
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/
Une fois le script dkl-graver-cdrom.sh lancé, l'image se trouve ici: /diskless/CDROM/isos/iso1.iso
L'image se trouve ici: /diskless/CDROM/isos/iso1.iso. Elle peut être gravée par n'importe quel logiciel de gravage. Voici la méthode avec cdrecord.
Tout d'abord, taper "cdrecord -scanbus" pour savoir où se trouve le graveur de CD. Le résultat doit être ceci:
0,0,0 0) 'AOPEN ' 'CD-RW CRW4048 ' '1.05' Removable CD-ROM
On voit donc que le graveur se trouve sur le périphérique "0,0,0".
Graver l'image avec ce commande (remplacer "0,0,0" si nécessaire):
cdrecord dev=0,0,0 -eject /diskless/CDROM/isos/iso1.iso
S'il s'agit d'un CD-RW (réinscriptible), il faut utiliser la commande suivante pour effacer le CD avant de graver:
cdrecord dev=0,0,0 blank=fast -eject /diskless/CDROM/isos/iso1.iso
Le BIOS du PC diskless doit être configuré de manière à booter sur le CD. Une fois ceci configuré, insérer le CD et redémarrer le PC diskless.
J'ai eu plusieurs machines à ma disposition pour effectuer des tests et mettre au point la méthodes. Pour voir la description de ces machines, allez voir en annexe la partie Machines de tests.
Pour faciliter l'installation, j'ai écrit des scripts qui sont accessibles en annexe.
Le serveur de diskless devra avoir les services suivants:
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 à installer sont:
Il faut aussi installer la partie client car, même si le serveur n'en a pas besoin, les PC diskless en ont besoin et le système des PC diskless va être récupéré à 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:
# Diskless de test numero 2
host gag242 {
allow booting;
hardware ethernet 00:d0:b7:c4:dc:ba;
fixed-address 195.220.79.242;
}
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:
# /etc/exports /diskless 195.220.79.220(rw,no_root_squash,insecure,async) /diskless 195.220.79.242(rw,no_root_squash,insecure,async)
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:
http://sari.inpg.fr/rubriques/themes/zone_publique.groupe_linux/diskless/tftp-hpa-install
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.
Il faut créer /diskless:
mkdir -p /diskless
Les scripts d'installation seront placés dans /diskless/scripts. Téléchargez-les dans /diskless/scripts (Voir l'adresse en annexe).
Il faut ensuite lire et lancer le script dkl-init-serveur.sh.
Ce script prépare l'arborescence /diskless:
Mais avant de lancer ce script, il faut être sûr d'avoir installé sur le serveur les paquetages qui seront utilisés sur les PC diskless (car les paquetages installés sur les PC diskless viennent de la copie du serveur).
En particulier, il faut:
Installer les sources du noyau:
urpmi kernel-source
Vérifier que les sources se trouvent bien dans /usr/src/linux. Sauvegarder /boot, les modules du serveur et les sources:
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
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. :
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
Si vous utilisez lilo, n'oubliez pas de taper lilo. Pour Grub, il n'y a rien à faire.
Tester pour voir si ca démarre bien.
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.
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
On va travailler à partir du .config qui deviendra celui du diskless. Il faudra mettre dans le noyau les paramètres suivants:
Pour compiler le noyau:
Le noyau se trouve maintenant dans /tftpboot/bzImage-diskless-pxe1. Selon les méthodes de boot, il devra être copié dans les emplacements suivants:
Dans tous les cas, les modules restent sur le serveur de diskless.
Il faut lancer le script dkl-init-diskless.sh avec comme premier argument l'adresse IP du PC diskless. Par exemple:
/diskless/scripts/dkl-init-diskless.sh 195.220.79.220
Voici ce que fait le script:
Aller dans le répertoire du diskless puis adapter ces fichiers aux paramètres du diskles (adresse IP, modules, disque dur...)
Voici deux exemples de fichier /etc/sysconfig/keyboard:
Clavier américain:
KBCHARSET=iso-8859-15 KEYBOARD=us_intl KEYTABLE=us-latin1
Clavier francais:
KBCHARSET=iso-8859-15 KEYBOARD=fr KEYTABLE=fr-latin1
Des exemples de /etc/X11/XF86Config-4 se trouvent en annexe. Voici ce qu'il faut penser à modifier:
Souris sans molette:
Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "PS/2"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons"
Option "Emulate3Timeout" "50"
EndSection
Souris avec molette:
Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/psaux"
Option "ZAxisMapping" "4 5"
EndSection
Il faut aussi adapter le fichier /etc/fstab du diskless. Voici un exemple:
# /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
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 à la fois par /diskless/bin et par /diskless/tftpboot/195.220.79.xxx/bin n'est pas gênant: en effet, grâce aux liens durs, cela ne prend pas plus de place.
De plus, il est indispensable de laisser ces fichiers dans ces deux endroits:
Faire du ménage avec dkl-diskless-menage.sh pour nettoyer /tmp, /root, /var/tmp, etc.
Ne pas lancer ce script quand le PC diskless tourne!
Il faut ensuite lire et lancer le script dkl-liens-durs-1diskless.sh avec comme premier argument l'adresse IP du PC diskless. Par exemple:
/diskless/scripts/dkl-liens-durs-1diskless.sh 195.220.79.220
Après ce script, tous les fichiers de /usr, ... du PC diskless seront mis en commun par des liens durs avec les autres PC diskless.
Voici ce qu'il faut penser à faire sur le serveur:
Le but est de rajouter un nouveau diskless dans /diskless/tftpboot/ à partir d'un modèle.
Si le diskless modèle s'appelle 195.220.79.modele et si le nouveau diskless s'appelle 195.220.79.242, tapez:
Il faut ensuite reprendre les étapes de la création du modèle mais cette fois pour le nouveau diskless (le diskless clone: 195.220.79.242 par ex.):
Sous Linux, les données systèmes sont classées dans des répertoires dont les noms sont standard. On trouve la même arborescence de base sur tous les PC Linux.
Voir:
http://www.freenix.fr/unix/linux/fsstnd-fr/
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ée 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 )
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.
Pour gagner de la place sur le serveur, il n'est pas nécessaire de faire une copie de l'arborescence complète de chaque diskless. Par exemple, le répertoire /usr des diskless peut être commun pour tous les diskless.
Voici la liste de ce qui peut être commun: /usr, /bin, /sbin, /home, /opt, et /lib.
Voici ce qui ne peut pas être commun: /dev, /etc, /mnt, /proc, /root, /tmp, et /var
La méthode utilisée pour partager le répertoire /usr (et les autres cités ci-dessus) pour tous les diskless est la suivante:
De plus, certain fichiers des répertoires non partagés doivent être communs. Ces fichiers se trouvent dans /diskless/tftpboot/commun sur le serveur. Le répertoire commun est monté par NFS sur les diskless avec cette ligne du fichier de configuration /etc/fstab:
195.220.79.217:/diskless/tftpboot/commun /commun nfs \ defaults,bg,intr,noac,rsize=8192,wsize=8192 0 0
Voici la liste de ces fichiers:
Les fichiers de cette liste sont dans /diskless/tftpboot/commun sur le serveur. La première idée est de créer 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épertoire /diskless/tftpboot/commun sur le serveur.
Mais cette méhtode pour partager les fichiers et répertoires pour les diskless pose quelques problèmes. En effet, au démarrage du diskless, tous les montages NFS ne sont pas encore monté et les scripts de démarrage ont besoin des fichiers qui se trouvent dans /commun.
En effet, /commun n'est pas encore monté 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é, il n'y a plus de probème car le lien symbolique devient fonctionnel. Mais avant cela, il y a des problèmes lors de l'éxécution des scripts de démarrage.
Pour les fichiers (/etc/passwd du diskless par exemple), la solution est de créer un lien dur sur le serveur entre /diskless/tftpboot/commun/passwd et tous les fichiers /etc/passwd de tous les diskless.
La commande utilisée pour le diskless gag220 est la suivante (bien sûr, cette commande est éxécutée sur le serveur):
ln /diskless/tftpboot/commun/passwd /diskless/tftpboot/195.220.79.220/etc/passwd
De cette facon, /etc/passwd est directement accessible par le diskless.
Les fichiers d'authentification sont: /etc/passwd, /etc/group, /etc/shadow, /etc/sudoers.
Ceux-ci doivent absolument être partagés 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ésolution des liens symboliques se fait du coté du client (diskless) et les fichiers pointés par les liens symboliques ne sont pas accessibles au démarrage du diskless: le montage NFS n'est pas encore fait.
Pas de problème particulier puisque /home n'est utilisé que lorsque la machine a fini de démarrer.
/home est monté par NFS.
Les modules du noyau du diskless sont stockés sur le serveur. Ils prennent de la place car:
Ce deuxième point doit être corrigé. Voici l'historique du placement des modules sur le serveur des diskless.
Lors de mes premiers tests, j'ai placé les modules dans le répertoire /diskless/lib/modules/ du serveur. Le répertoire /diskless/lib du serveur est monté par NFS sur le répertoire /lib du diskless.
Cela marchait à peu près mais il y avait un gros problème: dans les scripts de démarrage, le diskless lance depmod. Ce programme sert à recenser les modules pour pouvoir les charger plus facilement avec modprobe.
Mais au moment où depmod s'éxécute, le répertoire /lib du diskless n'est pas encore monté par NFS. depmod ne trouvait donc aucun module. Sur mon diskless de test, cela pose deux problèmes:
Pour corriger ces problèmes, j'ai copié les modules dans tous les répertoires de tous les diskless:
/diskless/tftpboot/195.220.79.xxx/lib/modules/
Ainsi, les modules se trouvent à la fois sous /diskless/lib/modules et dans tous les répertoires de tous les diskless. En effet, si on ne les met que dans les répertoires 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épertoire ne contient pas que les modules et il faut que le reste des fichiers soient communs à tous les diskless.
Cela prend donc beaucoup de place. De plus, la maintenance est plus difficile puisqu'à chaque modification des modules on doit les copier dans autant de répertoires qu'il y a de diskless.
Une autre solution doit donc être trouvée.
Pour corriger ces nouveaux problème, j'ai proposé une nouvelle solution. Elle corrige le problème de place.
Les modules doivent se placer dans /diskless/lib/modules et tous les diskless "possèdent" 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ême inode et désignent donc le même fichier.
Un script se chargera de synchroniser /diskless/lib/modules et le répertoire de modules de chacun des diskless.
Le besoin de synchronisation est justifié par:
Pour résumer, ce script contient la ligne suivante:
cp -al /diskless/lib/modules/ /diskless/tftpboot/195.220.79.xxx/lib/
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 à la place.
En fait, ce script contient d'autres choses mais l'idée est résumée dans cette ligne.
Les tests que j'ai effectués montrent que cette méthode marche correctement. Il reste à tester les performances sur un cas réel: je ne sais pas si ca va aller plus vite ou pas...
Maintenant, tous le répertoire /lib du PC diskless contient des liens durs "vers" les fichiers correspondant dans /diskless/lib du serveur.
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 à la main car:
Les modifications se font à l'aide de scripts:
Le fichier dkl-liens-durs-fonctions.sh contient des fonctions en shell permettant de modifier les liens durs. Les 6 scripts pré-cités appelent ces fonctions pour effectuer ces modifications.
Mise en place de tous les liens durs sur tous les diskless.
Exemple: dkl-liens-durs.sh (ce script s'appelle sans argument)
Mise en place de tous les liens durs sur un diskless.
Exemple: dkl-liens-durs-1diskless.sh 195.220.79.220
Mise en place d'un lien dur sur tous les diskless.
Exemple: dkl-1lien-dur-diskless.sh /diskless/shares/commun/passwd /etc/passwd
Mise en place d'un lien dur sur un diskless.
Exemple: dkl-1lien-dur-1diskless.sh 195.220.79.220 /diskless/shares/commun/passwd /etc/passwd
Suppression d'un lien dur sur tous les diskless:
Exemple: dkl-suppr-1lien-dur-diskless.sh /etc/passwd
Suppression d'un lien dur sur un diskless:
Exemple: dkl-suppr-1lien-dur-1diskless.sh 195.220.79.220 /etc/passwd
Une fois que les PC diskless marchent, ce n'est pas terminé. Il faut pouvoir mettre à jour les logiciels. La méthode habituelle sur Linux Mandrake est d'utiliser les outils rpm et urpmi. Cette méthode est parfaitement adaptée aux ordinateurs avec une installation classique sur le disque dur. Dans le cas des PC diskless, cette méthode pose quelques problèmes et doit être adaptée.
RPM et URPMI sont les équivalents de dpkg et apt-get respectivement pour Mandrake.
Le but est de faire marcher RPM et URPMI sur les PC diskless de telle facon qu'on puisse installer une fois le paquetage et qu'il soit installé sur tous les PC diskless.
La méthode doit être la plus automatique et la plus simple possible.
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.
Méthode simple:
Il y a deux choses à faire:
Voici un script qui permet de faire ca:
#!/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
Attention, ce script n'est pas testé !!
Page officielle de URPMI:
http://www.linux-mandrake.com/cooker/urpmi.html
Lors de mon premier essai de ces commandes sur un PC diskless, rpm ou urpmi se figent et ne font rien.
Ce problème est maintenant résolu. Voici comment je l'ai résolu. Pour résoudre le problème, je tape la commande suivante:
# strace rpm -qa
La commande strace permet de montrer tous les appels systèmes faits par la commande "rpm -qa". Cela affiche en particulier les lignes suivantes:
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)
Voici comment interpréter ces lignes:
La raison est donc que rpm veut vérouiller le fichier mais ne peut pas le faire car la fonction renvoie "ENOLCK (No locks available)".
Ce problème est apparu sur le PC diskless, quand le service NFS lockd n'avait pas réussi à démarrer. C'est donc normal que rpm ne puisse pas vérrouiller le fichier /var/lib/rpm/Packages car ce fichier est accédé par NFS.
Pour corriger le problème, il suffit donc de démarrer NFS lockd. Pour le démarrer, tapez la commande suivante:
/etc/init.d/nfslock start
En fait, NFS lockd se lance au démarrage automatiquement. S'il ne le fait pas, allez voir la partie "NFS lockd".
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être basé sur blackbox. Il est très léger et possède plusieurs fonctionnalitées intéressantes.
L'installation se fait depuis le PC diskless gag220 et se déroule sans problème avec la commande suivante:
urpmi fluxbox
Une fois installé, je regarde la liste des fichiers contenus dans le paquetage.
rpm -qli fluxbox
D'après cette commande, les fichiers sont placés dans:
Ce qui devait arriver arriva:
On a donc un gros problème: les autres PC diskless ne veront pas tous les fichiers.
URPMI a une fonctionnalité nommée "-parallel" qui permet de lancer urpmi automatiquement sur plusieurs machines pour installer un paquetage sur plusieurs machines en même temps.
Cette fonctionnalité a été développée pour être utilisée avec Clic mais elle peut en fait être utilisée sur n'importe quelle distribution Linux.
Une documentation de cette fonctionnalité se trouve sur:
http://clic.mandrakesoft.com/documentation/ch10.html
Malheureusement, cela ne convient pas pour nos PC diskless du LAOG pour plusieurs raisons:
Cette solution n'est donc pas réaliste.
Autre solution: installer un paquetage sur tous les PC diskless directement à partir du serveur en lancant la commande urpmi dans un chroot bien choisi (voir man chroot).
Trop compliqué à mettre en oeuvre.
C'est cette solution qui est retenue. Elle est décrite dans la section Procédure d'installation de paquetages.
Si on se contente de faire un urpmi sur un diskless, voici ce qui arrivera:
Les paquetages seront donc installés à moitié...
Je propose une solution en plusieurs étapes:
Cela se fait avec deux scripts:
Quelques commandes utiles:
Avant de commencer:
Voici les répertoires concernés:
Ces trois répertoires ne sont pas nécessaires au démarrage du PC diskless. Ils seront donc partagés par des liens symboliques. Voici les liens symboliques qui doivent être placés sur chaque diskless:
Ces 3 liens symboliques vont être mis en place sur le diskless modèle. Comme ce sont des liens symboliques et non des liens durs, ils seront correctement dupliqués sur les autres diskless lors de la commande "cp -a".
Démarrer un PC diskless. Taper "urpmi nom-du-logiciel". Noter les noms des paquetages qu'il installe sur le PC diskless. Par exemple:
-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#
Ici, les noms de paquetages sont "vim-X11" et "fluxbox" (indiqué en-dessous de la ligne "Préparation...").
Toujours sur le même diskless, une fois les logiciels installés, tapez:
/commun/dkl-paquetage-install-diskless.sh vim-X11 fluxbox
Cela va créer 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éjà partagés entre les diskless (fichiers dans /usr) et d'autres non (fichiers dans /etc).
Aller sur le serveur de diskless et taper la commande suivante:
/diskless/scripts/dkl-paquetage-install.sh 195.220.79.220 /tftpboot/195.220.79.220/tmp/MAJ-paquetages.txt
Les arguments de dkl-paquetage-install.sh sont:
Voici ce que fait ce dernier script:
Symptomes: RPM ou URPMI ne répondent plus.
Suivre les règles suivantes:
XFree a besoin de son fichier de configuration: /etc/X11/XF86Config.
Ce fichier contient le nom du driver de la carte vidéo (par exemple "ati"ou "nvidia") et d'autres choses.
Il doit donc être modifié sur chaque PC diskless en fonction de son matériel.
D'ordinaire, ce fichier de configuration est écrit automatiquement à l'installation de Linux Mandrake. Mais les PC diskless ne sont pas installés avec le programme d'installation de Mandrake mais en copiant le système du serveur.
Le fichier XF86Config contient donc les bonnes informations pour le serveur mais doit être adapté pour les PC diskless car leur matériel n'est pas le même.
Deux fichiers de configuration XF86Config-4 se trouvent en annexe.
Les scripts d'arrêt 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é est /etc/init.d/netfs, ligne 97. Il est appelé avec l'argument "stop" car il y a un lien vers ce script ici:
# 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 #
À cause de ce script, tous les montages NFS sont arrêtés, y compris la racine. Immédiatement après ce script, l'arrêt 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):
umount -f -l -a -t nfs
Les arguments la commande de démontage sont:
Un démontage paresseux ne démonte pas immédiatement le système de fichiers. Après un démontage paresseux, il n'est plus possible de lire ou de modifier les fichiers du système de fichiers tout comme un vrai démontage.
Cependant, les fichiers ouverts restent ouverts et il est possible de continuer à les lire ou les modifier.
Lorsque tous les programmes auront fermés leurs fichiers du système de fichier concerné, le démontage sera effectif.
L'option "-t nfs" sélectionne aussi la racine car elle est montée par NFS. Cependant, comme le démontage est paresseux, cela ne prend pas effet immédiatement. umount cherche donc à démonter la racine et pour ce faire, il faur démonter d'abord les sous-répertoires de la racine. Ainsi, /proc est démonté immédiatement car il n'est pas utilisé à cette étape du script.
Mais dans le script, la ligne qui suit le démontage est (ligne 102):
remaining=`LC_ALL=C awk '!/^#/ && $3 ~ /^nfs/ && $2 != "/" {print $2}' /proc/mounts`
Donc le script essaie de lire le fichier /proc/mounts; ce fichier n'est plus accessible car /proc est effectivement démonté.
Cependant, le système marche toujours (enfin, un peu...) car la racine n'est pas encore démontée car des fichiers sont encore ouverts et le démontage est paresseux.
Une idée serait de commenter l'entrée "root" (/) dans /etc/fstab. Ainsi, l'option "-a" de umount ne sélectionnerait pas la racine et / ne se démonterait pas à cette étape du script.
De toute facon, la racine n'est pas montée avec fstab mais avec les options root=/dev/nfs et nfsroot=/diskless/tftpboot/%s passées au noyau.
J'ai fait le test. Le PC diskless démarre correctement. XFree et XDM se lancent correctement mais KDE ne démarre plus (il se fige). Je ne sais pas pourquoi.
De toute facon, ce n'est sans doute pas une bonne idée car d'autres programmes pourraient avoir besoin de /etc/fstab pour savoir d'où est montée la racine.
La solution consiste à modifier le script d'arrêt pour ne pas démonter la racine. Le fichier à modifier est /etc/init.d/netfs, ligne 97.
J'ai donc remplacé ceci:
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
par ceci:
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
La variable $remaining contient la liste des montages à défaire. Cette variable est déjà remplie correctement par le script (c'est-à-dire elle ne contient pas "/", la racine), il n'y a donc rien d'autre à faire.
Cela résoud le problème: ces montages sont bien démontés et /proc est toujours accessibles après ces démontages. Le script peut donc continuer.
De plus, cette méthode est assez portable: si on décide de modifier les points de montage NFS, cela marchera toujours.
L'autre solution non portable serait d'énumerer les montages NFS à démonter dans le script. Il faudrait alors modifier le script d'arrêt chaque fois que l'on décide d'ajouter un montage.
Cependant, le script se bloque plus loin lors de l'arrêt de l'interface réseau eth0. En effet, cette interface réseau pour accéder au serveur NFS et est donc nécessaire pour le montage NFS de la racine.
Le problème se trouve dans le fichier /etc/init.d/network, ligne 210 environ. Ce fichier est appelé avec l'argument "stop" car des liens se trouvent ici:
# 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 #
J'ai donc mis en commentaire les lignes suivantes (ligne 215):
if ! check_device_down $i; then action "Shutting down interface %s: " $i ./ifdown $i boot fi
Depuis, le diskless s'arrête correctement.
Pour résumer, il faut:
De plus, comme le PC diskless a été arrêté correctement, il ne se plaint pas au démarrage et ne fait pas de fsck (file system check).
Les pilotes NVidia sont un module nommé NVdriver du noyau linux. J'avais copié le fichier NVdriver.o ici:
/diskless/tftpboot/195.220.79.220/lib/modules/2.4.21-0.13mdk-diskless-pxe1/kernel/drivers/char/NVdriver.o
Après le démarrage de la machine diskless, ce fichier se trouve au bon endroit, c'est à dire ici:
/lib/modules/2.4.21-0.13mdk-diskless-pxe1/kernel/drivers/char/
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:
/diskless/lib/
Ensuite, la partition /lib/ est montée à partir de:
/diskless/tftpboot/195.220.79.220/lib/
Les scripts de démarrage fonctionnent ainsi:
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.
Un serveur DHCP permet d'attribuer automatiquement des adresses IP aux clients qui font une requête DHCP. Le serveur peut être configuré 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ît donc les adresses MAC de toutes les cartes réseaux des PC diskless.
Pour démarrer, le PC diskless a besoin d'un serveur DHCP pour deux raisons:
Il faut donc un serveur DHCP. Cependant, sur le même réseau physique que mes machines de tests, un serveur DHCP légitime est déj&#