Création d'un serveur de démarrage PXE sous NetBSD, pour installer... NetBSD !

1. Pour ceux qui ne suivent pas, au fond

PXE, si vous n'en avez jamais entendu parler, signifie “Preboot Execution Environment”. Wikipédia définit ainsi PXE : « L'amorçage PXE (sigle de Pre-boot eXecution Environment) permet à une station de travail de démarrer depuis le réseau en récupérant une image de système d'exploitation qui se trouve sur un serveur. L'image ainsi récupérée peut être le système d'exploitation brut ou bien le système d'exploitation personnalisé avec des composantes logicielles (suite bureautique, utilitaires, packs de sécurité, scripts, etc…). »

Et cela tombe bien, c'est ce que nous voulons obtenir, avec quelques éléments en plus, comme la possibilité de choisir différentes versions de notre OS préféré, que ce soit en terme de version ou d'architecture (i386 ou amd64). Grosso modo, le scénario de démarrage PXE est le suivant :

- la machine démarre sur la carte réseau, laquelle cherche à obtenir une adresse IP et de quoi démarrer ;

- le serveur DHCP lui fournit l'adresse IP, l'adresse IP du serveur où trouver de quoi démarrer, ainsi que le nom du fichier et le protocole de téléchargement (généralement TFTP, HTTP est possible dans le cas de gPXE) ;

- la machine télécharge donc le fichier et l'exécute ;

- le fichier exécuté est dans notre cas un chargeur de démarrage, qui va se procurer sa configuration (en TFTP ou autrement) sur le serveur d'où il a été téléchargé ;

- l'utilisateur fait face à un menu de démarrage, avec un choix par défaut et peut sélectionner une option, qui ira télécharger un noyau, un initrd, un code permettant d'exécuter une image disquette ou ISO contenant un système d'exploitation ;

- selon le cas, l'OS chargé aura besoin de certains composants, situés selon les choix sur un serveur TFTP, FTP, HTTP ou NFS.

2. Prérequis

Cet article est basé sur ma configuration personnelle, qui peut s'avérer quelque peu… surdimensionnée, du moins pour un usage personnel. Je dispose d'un PC à processeur Atom, disposant de trois disques durs, officiant comme serveur TFTP, DHCP et DNS secondaire, miroir local HTTP, partages CIFS et hyperviseur Xen. Le rôle de DHCP et de DNS primaire est tenu par un Soekris. La machine Atom est donc considérée comme le « serveur PXE ». Ces machines fonctionnent, bien entendu, sous NetBSD. Côté clients, je dispose de deux vieux ordinateurs portables (générations Pentium 3 et Athlon XP) et d'une machine virtuelle VirtualBox (avec le pack d'extensions d'Oracle), contenant 1 Go de mémoire vive, accédant au réseau par pont et dont la carte réseau émulée est une Intel Pro 1000 Desktop. Ces machines sont bien entendu configurées pour démarrer sur la carte réseau, que ce soit de manière ponctuelle ou permanente.

Il n'est bien entendu pas nécessaire d'avoir autant de machines différentes, ni de monter une configuration DNS et DHCP redondée. Une infrastructure de démarrage PXE nécessite au minimum une machine avec les services DHCP et TFTP, mais nous allons ajouter dans celle-ci un serveur HTTP. Si dans l'absolu un seul client, physique ou virtuel, devrait suffire pour les tests, je ne saurais trop recommander à ceux qui envisagent un déploiement en production de tester avec des machines identiques à leur(s) cible(s). Mon expérience, qui s'est étendue au-delà de NetBSD, m'a montré que d'une carte réseau à l'autre, d'une génération de machine à l'autre et d'un système à l'autre, les résultats peuvent être différents. Si vous souhaitez reproduire cette architecture avec une solution de virtualisation, je vous recommande donc de faire attention à la carte réseau émulée et d'essayer de la modifier si votre machine virtuelle ne démarre pas sur le réseau (après vous être assuré que le reste de la configuration est correct).

Les logiciels à installer seront signalés au fur et à mesure. Pour éviter que cet article soit démesurément long, je pars du principe que le lecteur sait installer des logiciels sous NetBSD en utilisant pkg_add, pkgin ou la compilation de packages via pkgsrc. L'installation du système n'est pas non plus abordée, car celle réalisée pour le serveur est tout ce qu'il y a de plus classique. De nombreux articles ont déjà traité ces sujets et de fort belle manière !

Enfin, le lecteur attentif remarquera que ce document met en place les briques dans le sens inverse de leur utilisation (détaillée au paragraphe précédent). C'est totalement volontaire et permet de tester facilement les étapes de la mise en place et de « casser » votre configuration DHCP au dernier moment par exemple. Autre avantage : si vous voulez juste faire une installation en réseau sans démarrage réseau, il suffit de s'arrêter à la fin de la partie “Arborescence netinstall et serveur HTTP”.

3. Miroir, miroir, dis-moi qui est le plus beau

Côté arborescence, j'ai choisi de mettre l'ensemble des fichiers publiquement accessibles dans le répertoire /srv/www de mon serveur. Ce répertoire sera à la fois la racine du serveur TFTP et la racine du serveur HTTP. Un sous-répertoire pub va contenir les nombreuses données et outils utilisés non seulement pour démarrer l'installeur NetBSD, mais aussi pour accueillir les sets ainsi que d'autres systèmes à démarrer et à installer par le réseau. Nous allons aussi prévoir l'arrivée de futurs autres OS, en créant un répertoire dédié à NetBSD (chaque version sera dans un sous-répertoire) :

Reste à peupler ce répertoire. NetBSD est connu pour sa portabilité, il est donc possible de télécharger des sets, images ISO et installeurs pour de nombreuses architectures mais seules deux nous intéressent ici : i386 et amd64, respectivement nos PC classiques, en 32 et 64 bits. Il est possible de télécharger les images iso pour i386 et amd64, de les monter en loopback et de copier leur contenu dans deux répertoire amd64 et i386. Mais ce n'est pas drôle. Nous allons synchroniser sur un serveur rsync ces parties et utiliser pour cela net/rsync :

Ce script récupère toutes les versions 5 et 6 de NetBSD et permet d'éviter de télécharger les versions plus anciennes. Bien sûr, il peut facilement être adapté lors de la sortie d'une future version 7. Mais nous n'en sommes pas encore là…

A titre d'indication, et après plusieurs versions de NetBSD passées, voici un aperçu de mes répertoires (ne tenez pas compte de NetBSD-5.1.0_PATCH, il s'agit d'une version recompilée par mes soins) :

Passons à présent à la configuration du serveur web. Comme je suis le seul à me servir de ce système d'installation dans mon réseau local et que je souhaite une configuration simple ne nécessitant pas 421337 packages à installer et à mettre à jour, j'ai choisi d'utiliser celui qui est inclus dans le système de base : bozohttpd. La configuration de ce dernier est on ne peut plus simple, en voici pour preuve la liste des paramètres disponibles :

Je me suis donc contenté d'ajouter les lignes suivantes dans mon /etc/rc.conf :

L'option -X active le listage des fichiers lorsqu'aucun fichier index.html n'est présent et l'option -S permet de changer la signature du serveur web. Cette dernière option est totalement inutile dans le cadre de notre objectif mais reste amusante à connaître. Le démarrage, l'arrêt et la relance de bozohttpd s'effectuent via un classique /etc/rc.d/httpd (start|stop|restart).

A la fin de cette première étape, nous disposons d'un serveur HTTP capable de servir les fichiers d'une installation de NetBSD. Je vous encourage à tester ce premier point avec une machine virtuelle, en démarrant sur le fichier boot.iso que vous trouverez sur le serveur dans /pub/NetBSD-6.1/i386/installation/cdrom/ (remplacer i386 par amd64 pour tester la version 64 bits). Il nous faut encore installer ce qui va nous permettre de démarrer par le réseau.

4. Pxelinux et pxeboot sont dans un bateau...

De mon expérience, 99% des documentations sur le démarrage en réseau utilisent l'outil pxelinux, présent dans la suite syslinux. Le pourcentage restant utilise GRUB. Mais ça, c'était sans compter NetBSD, qui dispose de son propre chargeur de démarrage : pxeboot. Si on souhaite créer un serveur de démarrage PXE uniquement pour NetBSD, ce dernier est amplement suffisant. Si, comme moi, vous souhaitez en plus démarrer des installeurs d'autres systèmes, il faut chaîner pxelinux et pxeboot. Voyons dans un premier temps la configuration de pxeboot, puis nous ajouterons pxelinux.

Comme le serveur PXE est sous NetBSD, pxeboot est déjà disponible : il s'agit du fichier /usr/mdec/pxeboot_ia32.bin. Si ce n'est pas le cas mais que l'arborescence détaillée plus haut est déjà synchronisée, vous le trouverez là : /srv/www/pub/NetBSD/NetBSD-6.1/i386/installation/misc/pxeboot_ia32.bin (disponible aussi pour amd64 et pour les autres versions de NetBSD). Par défaut, ce fichier ne permet pas grand-chose, car il se contente de télécharger sur un partage NFS un fichier nommé netbsd désignant un noyau, le plus souvent d'installation. Cependant, il est possible d'étendre ses possibilités via l'outil installboot, fourni aussi en standard dans NetBSD. La possibilité qui nous intéresse le plus est celle de faire lire à pxeboot un fichier de configuration de type boot.cfg. Il sera donc possible de choisir via un menu le noyau d'installation souhaité.

Commençons par copier le fichier à ce qui sera la racine du serveur TFTP :

Ensuite, on active les options adéquates :

Attention : installboot est un petit malin, malgré l'option -v (verbose), il n'est pas très bavard. Si une option est déjà active, il va la supprimer. Ne lancez donc pas deux fois de suite la commande et si vous avez un doute, repartez du fichier d'origine. Enfin, on rédige un fichier boot.cfg (la liste des noyaux n'est pas exhaustive puisque nous avons synchronisé toutes les versions 5 et 6) :

Si le système PXE ne doit servir que des installations de NetBSD, on peut s'arrêter là et passer à la partie suivante (configuration du serveur TFTP). Vérifions au moins que les fichiers pxeboot_ia32.bin et boot.cfg peuvent être téléchargés en HTTP, ils sont disponibles à la racine du serveur web.

Pour pouvoir avoir plus de choix que NetBSD, continuons avec pxelinux. Nous allons continuer dans l'arborescence que nous connaissons déjà mais, une fois n'est pas coutume, nous n'allons pas installer pxelinux via les paquets de la distribution mais directement depuis le site du noyau Linux avec net/wget. On notera que le téléchargement n'est possible qu'en HTTPS, d'où l'utilisation de l'option –no-check-certificate

De la sorte, il sera possible de passer simplement à une version supérieure de syslinux et de revenir en arrière si besoin. Comme vu plus tôt, il est prévu que la racine du serveur TFTP soit /srv/www et non /srv/www/pub. Pour rendre accessible les vrais fichiers de démarrage, remontons d'un niveau et effectuons nos liens symboliques :

Les fichiers .0 servent à démarrer sur le réseau, tandis que les fichiers en .c32 sont des modules appelés par la configuration (chain.c32 permet de chaîner un démarrage, menu.c32 permet de créer un menu d'affichage perfectionné). Lorsque nous configurerons le serveur DHCP, nous indiquerons au client d'aller télécharger le fichier pxelinux.0. Les autres fichiers seront nécessaires selon la configuration que nous appliquerons au niveau de notre menu de démarrage. Le fichier gpxelinux.0 fournit les mêmes fonctionnalités que pxelinux.0 mais permet entre autres de démarrer sur HTTP au lieu de TFTP, pour télécharger des fichiers de taille assez importante (au hasard l'initrd obèse des Fedora depuis la 14 ou la 15). Le prix à payer s'avère être une compatibilité moins étendue avec les cartes réseau. Comme nous n'en avons pas un besoin immédiat, nous allons rester sur pxelinux.0.

Une fois pxelinux installé, il nous reste à le configurer. C'est là que réside une grande partie de l'intelligence du système, puisque c'est dans cette configuration que nous créons notre « menu de démarrage réseau », où il sera possible de choisir de démarrer le disque dur local, de démarrer un système, ou de chaîner vers pxeboot pour installer NetBSD. Rendons à César ce qui est à Jules, ce fichier est fortement inspiré du fichier de configuration ISOLINUX de la distribution Linux « System Rescue CD », que je vous recommande au passage.

Les arborescences de pxelinux et de pxeboot sont publiques, vous pouvez donc facilement vérifier que les chargeurs de démarrage pxelinux.0 et pxeboot_ia32.bin peuvent être téléchargés, ainsi que les fichiers de configuration (situés sur le serveur HTTP dans /pxelinux.cfg/default et dans /boot.cfg). Mais il nous faut aussi les télécharger en TFTP…

5. TFTP

NetBSD, en plus de comprendre un serveur HTTP dans son système de base, contient aussi un serveur TFTP. Pour être actif, celui-ci a besoin du super-serveur inetd. Configurons donc tftpd en éditant le fichier /etc/inetd.conf (on notera que tftpd n'écoute que sur ipv4) :

Il nous faut aussi démarrer inetd par défaut, mais nous avons de la chance, ceci est normalement le cas :

Si ce n'est pas le cas, il faudra ajouter au fichier /etc/rc.conf la ligne suivante :

Et dans tous les cas, nous redémarrons Inetd pour la prise en compte de l'ajout de tftpd :

Continuons notre bonne habitude et vérifions que notre serveur TFTP fonctionne. Pour cela, il nous faut un client. On peut utiliser une machine distante, ou notre serveur lui-même, qui en possède justement un :

Déplaçons-nous là où ça ne gênera pas :

Et testons :

Le test est donc concluant, tous nos fichiers sont arrivés :)

6. Configuration du serveur DHCP

Attaquons-nous maintenant à la dernière brique de notre infrastructure, qui paradoxalement est appelée en premier lors de son utilisation : le serveur DHCP. Tout comme les serveurs HTTP et TFTP, NetBSD dispose d'un serveur DHCP dans son système de base, il s'agit du célèbre ISC DHCPD. Le principe est le suivant : lorsqu'une machine demande une adresse IP (v4) sur le réseau, le serveur DHCP va lui répondre en lui donnant de nombreuses informations, dont :

- son adresse IP ;

- le masque de sous-réseau ;

- l'adresse de la passerelle par défaut ;

- l'adresse d'un ou de plusieurs serveurs DNS ;

- l'adresse du next-server, ce sera ici notre serveur PXE ;

- un fichier à télécharger, ici le fichier pxelinux.0.

A noter que le réseau en exemple ici a les caractéristiques suivantes :

- adressage 192.168.6.0/24 ;

- paserelle par défaut 192.168.6.254 ;

- serveurs DNS 192.168.6.5 et 192.168.6.60, domaine local anotherhomepage.loc ;

- les adresses IP DHCP allouées sont entre 192.168.6.200 et 192.168.6.249 ;

- serveur PXE 192.168.6.60.

Nous allons de plus ajouter un petit hack qui va nous éviter de mettre en place un serveur NFS : en effet, pxeboot a pour comportement habituel d'aller chercher son fichier boot.cfg sur un partage NFS. Pour éviter de mettre en place un tel partage, paramétrons le serveur DHCP pour qu'il indique à pxeboot que le fichier est disponible en TFTP.

On remarquera dans le fichier de configuration ci-après deux exemples de machines disposant d'une adresse IP fixe allouée par DHCPD ainsi que la présence en commentaire du fichier gpxelinux.0, prêt à remplacer pxelinux.0.

ISC DHCPD ne démarre pas automatiquement avec le démarrage de notre serveur :

Autorisons-le en ajoutant à /etc/rc.conf :

Et enfin, démarrons notre serveur :

Par défaut, DHCPD écrit dans /var/log/messages :

7. Test de bout en bout

Il est maintenant temps de tester le bon fonctionnement de notre infrastructure, du début à la fin. Dans le cas d'une machine physique, il faut se rendre dans le BIOS et activer le démarrage par le réseau. Celui-ci peut prendre plusieurs formes, comme par exemple : activer le démarrage de la carte réseau, puis modifier l'ordre des périphériques de démarrage pour amener la carte réseau avant le lecteur optique ou le disque dur. D'autres machines disposent d'un moyen de démarrer sur le réseau ou de changer l'ordre de démarrage via une touche du clavier, généralement l'une des touches de fonction (F1 à F12).

Dans le cas d'une machine virtuelle, cela dépend de la solution de virtualisation utilisée. Dans le cas précis d'Oracle VirtualBox, il est impératif d'installer les extensions (attention à leur licence !), qui activent justement le démarrage PXE. Ensuite, le principe est presque le même qu'une machine physique, à la différence que cela se fait dans la configuration de la machine virtuelle : activer le démarrage de la carte réseau, puis, au choix, le déplacer avant la disquette, le CD et le disque dur, ou appuyer sur F12 au démarrage.

Le menu PXELinux devrait alors apparaître. On sélectionne alors avec les touches du clavier l'entrée du menu NetBSD et le menu d'installation de NetBSD s'affiche alors. Attention, celui-ci n'est pas aussi intuitif que PXELinux et le clavier est paramétré en QWERTY.

8. Pimp my PXE... ou pas

Notre menu est fonctionnel et à peu près pratique, mais ce n'est pas le plus beau de la terre. Il est possible de modifier les couleurs et de paramétrer un fond d'écran… ou pas, en fait. Syslinux est parfaitement capable de gérer une image de fond, c'est même grâce à cela que les CD de démarrage de nos distributions Linux favorites fonctionnent. Mais l'utilisation du menu avancé vesamenu.c32 empêchait pxeboot de fonctionner. Il m'aura fallu plusieurs heures et un appel à l'aide sur la liste de diffusion netbsd-users avant d'arriver à ce constat. Qui est en cause ? Syslinux ? Pxeboot ? Pour l'instant, je ne sais pas.

9. Quand ça veut pas...

C'est le grand moment. Vous démarrez votre machine, et… rien. Pas de démarrage sur le réseau, pas d'installeur NetBSD en vue, éventuellement la machine démarre sur son disque local et amorce l'OS que vous auriez installé. Sans être un guide exhaustif des erreurs possibles, cette partie aborde celles qui risquent d'arriver. Il se peut aussi que votre problème soit insoluble avec la combinaison BIOS/carte réseau dont vous disposez, la qualité de l'implémentation PXE est variable d'un constructeur à l'autre…

10. Le mot de la fin

La configuration telle que je vous la livre ne s'est pas inventée en quelques heures. Elle est le résultat de près de 3 ans de vie du système et de paramétrages différents selon la version de NetBSD : pour donner une idée, il m'a été possible avec la branche 5 de NetBSD de démarrer les images ISO directement via PXELinux grâce à l'outil memdisk (mais cela n'est plus possible avec les versions 6, sinon cela aurait été trop facile). Pendant un temps, j'ai même modifié avec un éditeur hexadécimal pxeboot_ia32.bin pour qu'il s'identifie de manière différente selon la version et l'architecture auprès du serveur DHCP (et donc avec plusieurs clauses if…). Cette configuration a le mérite d'être fonctionnelle et testée, et de permettre d'installer d'autres systèmes à côté. Ainsi, mon serveur PXE me permet d'installer non seulement NetBSD, mais aussi CentOS, Fedora (j'installe mon PC de bureau principal de cette manière) et certaines versions de Microsoft Windows.

J'en profite pour remercier la communauté NetBSDfr pour son ambiance chaleureuse qui donne envie de s'intéresser à ce système !

11. Liens utiles

Syslinux : http://www.syslinux.org/wiki/index.php/The_Syslinux_Project

NetBSD : http://www.netbsd.org/

Documentation “MENU” Syslinux : http://www.syslinux.org/wiki/index.php/Comboot/menu.c32

Pas de joli menu graphique dans PXELinux avec pxeboot : http://mail-index.netbsd.org/netbsd-users/2013/08/25/msg013203.html