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

Magazine
Marque
GNU/Linux Magazine
Numéro
166
Mois de parution
décembre 2013
Spécialité(s)


Résumé

Créer un serveur de démarrage PXE est un sujet qui a déjà été abordé de nombreuses fois. Ce qui est moins courant, c'est de démarrer l'installeur NetBSD par le réseau. Et ce qui l'est encore moins, c'est de créer le serveur d'installation avec une machine NetBSD !


Body

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) :

root@arreat:~# mkdir -p /srv/www/pub/NetBSD

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 :

root@arreat:~# mkdir -p /srv/www/pub/scripts
root@arreat:~# vi /srv/www/pub/scripts/rsync_netbsd.sh
/usr/pkg/bin/rsync \
-avzPH --stats \
--delete --delete-after \
--include="/NetBSD-[5-6].?/" \
--include="/NetBSD-[5-6].?/amd64/" \
--include="/NetBSD-[5-6].?/amd64/**" \
--include="/NetBSD-[5-6].?/i386/" \
--include="/NetBSD-[5-6].?/i386/**" \
--include="/NetBSD-[5-6].?/shared/" \
--include="/NetBSD-[5-6].?/shared/ALL/" \
--include="/NetBSD-[5-6].?/shared/ALL/**" \
--include="/NetBSD-[5-6].?/source/" \
--include="/NetBSD-[5-6].?/source/**" \
--include="/NetBSD-[5-6].?.?/" \
--include="/NetBSD-[5-6].?.?/amd64/" \
--include="/NetBSD-[5-6].?.?/amd64/**" \
--include="/NetBSD-[5-6].?.?/i386/" \
--include="/NetBSD-[5-6].?.?/i386/**" \
--include="/NetBSD-[5-6].?.?/shared/" \
--include="/NetBSD-[5-6].?.?/shared/ALL/" \
--include="/NetBSD-[5-6].?.?/shared/ALL/**" \
--include="/NetBSD-[5-6].?.?/source/" \
--include="/NetBSD-[5-6].?.?/source/**" \
--include="/iso/" \
--include="/iso/[5-6].?/" \
--include="/iso/[5-6].?/*amd64*" \
--include="/iso/[5-6].?/*i386*" \
--include="/iso/[5-6].?.?/" \
--include="/iso/[5-6].?.?/*amd64*" \
--include="/iso/[5-6].?.?/*i386*" \
--exclude=* \
rsync://rsync.fr.NetBSD.org/NetBSD/ /srv/www/pub/NetBSD/ 2>&1
| tee -a /var/log/sync_netbsd.log
root@arreat:~# /srv/www/pub/scripts/rsync_netbsd.sh
# (s’en suivent de nombreuses minutes d’attente...)

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) :

root@arreat:~# ls -hl /srv/www/pub/NetBSD/
total 7,0K
drwxr-xr-x 6 99 wheel 512B Sep 18 2012 NetBSD-5.0/
drwxr-xr-x 6 99 wheel 512B Jul 30 2009 NetBSD-5.0.1/
drwxr-xr-x 6 99 wheel 512B Sep 18 2012 NetBSD-5.0.2/
drwxr-xr-x 7 99 wheel 512B Sep 18 2012 NetBSD-5.1/
drwxr-xr-x 4 root wheel 512B Mar 22 2011 NetBSD-5.1.0_PATCH/
drwxr-xr-x 6 99 wheel 512B Jan 6 2012 NetBSD-5.1.1/
drwxr-xr-x 7 99 wheel 512B Sep 18 2012 NetBSD-5.1.2/
drwxr-xr-x 6 99 wheel 512B Nov 29 2012 NetBSD-5.2/
drwxr-xr-x 6 99 wheel 512B Oct 15 2012 NetBSD-6.0/
drwxr-xr-x 6 99 wheel 512B Dec 29 2012 NetBSD-6.0.1/
drwxr-xr-x 6 99 wheel 512B May 16 08:26 NetBSD-6.0.2/
drwxr-xr-x 6 99 wheel 512B May 16 02:54 NetBSD-6.1/
drwxr-xr-x 6 99 wheel 512B Aug 25 13:29 NetBSD-6.1.1/
drwxr-xr-x 15 root daemon 512B Aug 25 09:19 iso/
root@arreat:~# ls -hl /srv/www/pub/NetBSD/NetBSD-6.1

total 2,0K
drwxr-xr-x 4 99 wheel 512B May 16 02:04 amd64/
drwxr-xr-x 4 99 wheel 512B May 16 00:02 i386/
drwxr-xr-x 3 99 wheel 512B May 15 22:24 shared/
drwxr-xr-x 3 99 wheel 512B May 15 22:24 source/

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 :

root@arreat:~# grep httpd /etc/defaults/rc.conf
httpd=NO httpd_flags=""
httpd_wwwdir="/var/www"
httpd_wwwuser="_httpd"

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

# bozohttpd
httpd=YES
httpd_flags="-X -S ‘AHP Intranet’"
httpd_wwwdir="/srv/www"

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 :

root@arreat:~# cp -vp /usr/mdec/pxeboot_ia32.bin /srv/www/

Ensuite, on active les options adéquates :

root@arreat:~# installboot -v -e -o bootconf,modules /srv/www/pxeboot_ia32.bin

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) :

root@arreat:~# vi /srv/www/boot.cfg
banner=Welcome to the NetBSD PXE Installer
banner===============================================================================
banner=
banner=This menu contains only the installation kernels. Binary sets to complete the
banner=installation must be downloaded separately. The installer can download them
banner=if this machine has a working internet connection.
banner=
banner=ACPI (Advanced Configuration and Power Interface) should work on all modern
banner=and legacy hardware. However if you do encounter a problem while booting,
banner=try disabling it and report a bug at http://www.NetBSD.org/.
menu=Drop to boot prompt:prompt
menu=Install NetBSD 5.2 amd64:boot tftp:pub/NetBSD/NetBSD-5.2/amd64/binary/kernel/netbsd-INSTALL.gz
menu=Install NetBSD 5.2 i386:boot tftp:pub/NetBSD/NetBSD-5.2/i386/binary/kernel/netbsd-INSTALL_FLOPPY.gz
menu=Install NetBSD 6.0.2 amd64:boot tftp:pub/NetBSD/NetBSD-6.0.2/amd64/binary/kernel/netbsd-INSTALL.gz
menu=Install NetBSD 6.0.2 i386:boot tftp:pub/NetBSD/NetBSD-6.0.2/i386/binary/kernel/netbsd-INSTALL.gz
menu=Install NetBSD 6.1 amd64:boot tftp:pub/NetBSD/NetBSD-6.1/amd64/binary/kernel/netbsd-INSTALL.gz
menu=Install NetBSD 6.1 i386:boot tftp:pub/NetBSD/NetBSD-6.1/i386/binary/kernel/netbsd-INSTALL.gz
menu=Install NetBSD 6.1.1 amd64:boot tftp:pub/NetBSD/NetBSD-6.1.1/amd64/binary/kernel/netbsd-INSTALL.gz
menu=Install NetBSD 6.1.1 i386:boot tftp:pub/NetBSD/NetBSD-6.1.1/i386/binary/kernel/netbsd-INSTALL.gz
default=1
timeout=10
clear=1

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

root@arreat:~# cd /srv/www/pub
root@arreat:/srv/www/pub# wget --no-check-certificate https://www.
kernel.org/pub/linux/utils/boot/syslinux/syslinux-6.01.tar.gz
root@arreat:/srv/www/pub# tar -xvzpf syslinux-6.01.tar.gz
root@arreat:/srv/www/pub# ln -sv syslinux-6.01 syslinux

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 :

root@arreat:~# cd /srv/www/
root@arreat:/srv/www# for i in $(find /srv/www/pub/syslinux/bios/
-type f -iname *.c32); do ln -sv $i; done
root@arreat:/srv/www# for i in $(find /srv/www/pub/syslinux/bios/
-type f -iname *.0); do ln -sv $i; done

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.

root@arreat:~# mkdir /srv/www/pxelinux.cfg
root@arreat:~# vi /srv/www/pxelinux.cfg/default
UI menu.c32
PROMPT 0
TIMEOUT 90
MENU AUTOBOOT Starting default choice in # seconds
ONTIMEOUT local1
MENU TABMSG Press <TAB> to edit options
MENU TITLE Another Home Page PXE Menu
MENU ROWS 16
MENU TIMEOUTROW 22
MENU TABMSGROW 24
MENU CMDLINEROW 24
MENU HELPMSGROW 26
MENU WIDTH 78
MENU MARGIN 6
MENU color title 1;31;40 #FFFF0000 #00000000 std
MENU color sel 7;37;40 #FF000000 #FFC0C0C0 all
MENU color unsel 37;44 #FF000000 #00000000 none
MENU color hotsel 1;7;37;40 #FF000000 #FFC0C0C0 all
MENU color tabmsg 1;31;40 #FFFFFF00 #00000000 std
MENU color help 1;31;40 #FFFFFFFF #00000000 none
LABEL local1
MENU LABEL *) Boot from first hard disk
kernel chain.c32
append hd0
TEXT HELP
Boot local OS installed on first hard disk
ENDTEXT
LABEL local2
MENU LABEL *) Boot from second hard disk
kernel chain.c32
append hd1
TEXT HELP
Boot local OS installed on second hard disk
ENDTEXT
MENU SEPARATOR
MENU BEGIN
MENU TITLE A) INSTALL AN OPERATING SYSTEM
# inserer ici d’autres OS
LABEL nbpxe
MENU LABEL NetBSD PXE installer
KERNEL pxeboot_ia32.bin
MENU SEPARATOR
LABEL return
MENU LABEL Return to main menu

MENU EXIT
MENU END
MENU BEGIN
MENU TITLE B) BOOT SPECIAL TOOLS
# inserer ici certains outils speciaux
MENU SEPARATOR
LABEL return
MENU LABEL Return to main menu
MENU EXIT
MENU END
MENU BEGIN
MENU TITLE C) BOOT SOME LIVE SYSTEMS
# inserer ici des OS complets live
MENU SEPARATOR
LABEL return
MENU LABEL Return to main menu
MENU EXIT
MENU END

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) :

tftp dgram udp wait.600 root /usr/libexec/
tftpd tftpd -d -l -s /srv/www

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

root@arreat:~# grep inetd /etc/defaults/rc.conf
# inetd is used to start the IP-based services enabled in /etc/inetd.
conf
inetd=YES inetd_flags="-l" # -l logs libwrap

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

inetd=YES inetd_flags="-l"

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

root@arreat:~# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.

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 :

root@arreat:~# which tftp
/usr/bin/tftp

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

root@arreat:~# mkdir /tmp/tftptest && cd /tmp/tftptest
root@arreat:/tmp/tftptest#

Et testons :

nils@arreat:~$ mkdir /tmp/tftptest
nils@arreat:~$ cd /tmp/tftptest/
nils@arreat:/tmp/tftptest$ tftp
tftp> connect <ip du serveur>
tftp> binary
tftp> get pxelinux.0
Received 42534 bytes in 0.1 seconds
tftp> get gpxelinux.0
Received 106660 bytes in 0.2 seconds
tftp> get menu.c32
Received 25708 bytes in 0.1 seconds
tftp> get pxeboot_ia32.bin
Received 53444 bytes in 0.1 seconds
tftp> get pub/NetBSD/NetBSD-6.1.1/amd64/INSTALL.txt
Received 97413 bytes in 0.2 seconds
tftp> quit
nils@arreat:/tmp/tftptest$ ll
total 318K
-rw-r--r-- 1 nils wheel 95K Sep 24 16:37 INSTALL.txt
-rw-r--r-- 1 nils wheel 104K Sep 24 16:36 gpxelinux.0
-rw-r--r-- 1 nils wheel 25K Sep 24 16:36 menu.c32
-rw-r--r-- 1 nils wheel 52K Sep 24 16:36 pxeboot_ia32.bin
-rw-r--r-- 1 nils wheel 42K Sep 24 16:36 pxelinux.0

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.

root@arreat:~# vi /etc/dhcpd.conf
ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
allow booting;
allow bootp;
authoritative;
allow unknown-clients;
# Duree de vie du bail en secondes
max-lease-time 3600;
default-lease-time 1800;
# Sous-reseau interne
subnet 192.168.6.0 netmask 255.255.255.0 {
pool {
deny dynamic bootp clients;
range 192.168.6.200 192.168.6.249;
option domain-name-servers 192.168.6.5, 192.168.6.60;
option domain-name "anotherhomepage.loc";
option routers 192.168.6.254;
option broadcast-address 192.168.6.255;
next-server 192.168.6.60;
option root-path "/srv/www";
filename "pxelinux.0";
# Pour expérimenter gPXE
#filename "gpxelinux.0";
# Pour ne démarrer que l’installeur NetBSD
#filename "pxeboot_ia32.bin" ;
# Si pxeboot nous demande quelque chose, c’est boot.cfg
# et c’est en TFTP qu’il faut le trouver
if substring (option vendor-class-identifier, 0, 17) =
"NetBSD:i386:libsa" {
if filename = "boot.cfg" {
filename "tftp:boot.cfg";
}
}
}
group {
use-host-decl-names true ;
host pxelaptop {
hardware ethernet 00:01:02:03:04:f7;
fixed-address 192.168.6.198;
option host-name "pxelaptop";
}

# Virtual Machine
host pxemachine {
hardware ethernet 08:00:27:d3:8f:2d;
fixed-address 192.168.6.199;
option host-name "pxemachine";
}}

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

root@arreat:~# grep dhcpd /etc/defaults/rc.conf
dhcpd=NO dhcpd_flags="-q"

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

dhcpd=YES

Et enfin, démarrons notre serveur :

root@arreat:~# /etc/rc.d/dhcpd start
Starting dhcpd.

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

root@arreat:~# tail -f /var/log/messages
Jul 10 16:43:06 arreat dhcpd: Wrote 0 deleted host decls to leases
file.
Jul 10 16:43:06 arreat dhcpd: Wrote 0 new dynamic host decls to
leases file.
Jul 10 16:43:06 arreat dhcpd: Wrote 48 leases to leases file.
Jul 10 16:43:06 arreat dhcpd: pool 7f7ff7ba5150 192.168.6/24 total 50
free 26 backup 24 lts 1

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).

boot_menu

Fig. 1 : Exemple de sélection au démarrage via la carte mère, sans passer par tous les écrans du BIOS

 

bios_activation_lan

Fig. 2 : Exemple d’activation dans un BIOS de la capacité de démarrage de carte réseau : cela lui permet d’être sélectionnée comme périphérique amorçable

bios_boot_selection

Fig. 3 : Exemple de paramétrage permanent d’ordre de démarrage au niveau du BIOS

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.

virtualbox_config

Fig. 4 : Ordre d’amorçage dans Oracle VirtualBox

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.

pxelinux_01

Fig. 5 :Premier menu pxelinux

pxelinux_02

Fig. 6 : Deuxième menu pxelinux

pxeboot_01

Fig. 7 : Menu pxeboot NetBSD

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…

Type de problème

Résolutions possibles

La machine ne peut pas démarrer sur le réseau.

Paramétrer le BIOS ou le mettre à jour si besoin. Si la machine ne peut démarrer sur la carte réseau, utiliser une image CD ou disquette du projet Etherboot (http://rom-o-matic.net/). Pour VirtualBox, pensez au pack d'extension et à paramétrer la carte réseau en Intel PRO/1000.

La carte réseau n'obtient pas d'adresse IP

Le serveur DHCP est en cause : est-il démarré et correctement paramétré ?

La carte réseau n'arrive pas à télécharger un fichier.

Probablement une erreur TFTP : celui-ci est paramétré via inetd, il faut donc vérifier à ce niveau s'il accepte les connexions. Il se peut aussi que le fichier ne soit pas au bon endroit ou que les droits soient insuffisants.

PXELinux ne trouve pas pxeboot_ia32.bin

Assurez-vous que le fichier pxeboot_ia32.bin est bien téléchargeable via TFTP dans la même arborescence que PXELinux et que c'est bien ce chemin qui est utilisé dans le fichier de configuration. On peut mettre hors de cause le lancement du serveur TFTP puisqu'il a été utilisé pour télécharger le chargeur PXELinux et sa configuration.

L'installeur NetBSD ne trouve pas les sets.

Dans notre exemple, les sets sont téléchargés via HTTP mais il n'est pas possible pour le moment de paramétrer en amont l'installeur NetBSD pour lui donner l'URL vers un miroir personnel. Pensez donc à paramétrer l'URL des sets vers lors de l'installation et assurez-vous qu'ils sont accessibles.

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



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 125 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous