il y a 1 an

PXE : déployer et démarrer des machines par le réseau

PXE, pour Preboot eXecution Environment, permet à un ordinateur de démarrer depuis le réseau avant même qu’un système d’exploitation local soit chargé. Au lieu de promener une clé USB de machine en machine, le firmware récupère automatiquement les informations et fichiers nécessaires au démarrage.

PXE est particulièrement utile pour déployer Debian ou d’autres systèmes sur plusieurs postes, lancer des outils de maintenance, automatiser des installations ou fournir des environnements de secours.

PXE n’est pas un système d’exploitation et ce n’est pas un serveur unique : c’est une chaîne de démarrage faisant coopérer firmware, DHCP, programme de boot réseau et serveur de fichiers.

Comment fonctionne un démarrage PXE ?

Le scénario classique commence dans le BIOS ou l’UEFI. La carte réseau et le firmware disposent d’un client capable de demander une configuration réseau puis de télécharger un premier programme d’amorçage.

La machine démarre et sélectionne le boot réseau.
Le client effectue une découverte DHCP pour obtenir sa configuration IP.
Il reçoit également, directement ou via un service PXE complémentaire, l’emplacement du serveur de boot et le programme à charger.
Le firmware télécharge ce premier programme, historiquement via TFTP.
Le programme de boot affiche éventuellement un menu et charge un noyau, un initramfs ou un autre environnement.
L’installateur ou le système live peut ensuite récupérer ses ressources par TFTP, HTTP, NFS ou un autre protocole adapté.

Dans une installation Debian traditionnelle, l’enchaînement peut donc ressembler à :

UEFI / BIOS
    ↓
DHCP
    ↓
TFTP
    ↓
PXELINUX ou GRUB EFI
    ↓
noyau Linux + initrd
    ↓
installateur Debian
    ↓
dépôts réseau

Le rôle de TFTP est généralement limité au bootstrap. Transporter plusieurs gigaoctets avec TFTP parce qu’il était déjà là reste possible dans certains scénarios, mais HTTP offre souvent une bien meilleure efficacité dès que le chargeur utilisé le permet.

BIOS, UEFI et fichiers de démarrage

L’une des principales sources d’erreurs PXE vient de l’existence de plusieurs architectures de firmware. Un fichier qui fonctionne parfaitement avec une ancienne machine BIOS peut être inutilisable sur une machine UEFI.

Client	Programme de démarrage typique
BIOS / Legacy PXE	`pxelinux.0` ou `undionly.kpxe`
UEFI x86-64 Debian	`bootnetx64.efi` ou chargeur GRUB EFI approprié
UEFI avec iPXE	`ipxe.efi` ou autre image UEFI iPXE adaptée

Le serveur DHCP doit donc souvent distinguer l’architecture du client afin de lui remettre le bon fichier.

Le paquet netboot officiel de Debian fournit déjà une arborescence adaptée comprenant notamment le noyau, l’initrd, PXELINUX et les programmes EFI nécessaires. Il est généralement plus sûr d’utiliser cette structure plutôt que de reconstruire manuellement un puzzle de fichiers récupérés dans quatre paquets différents et trois tutoriels datant de 2014.

Et Secure Boot ?

Sur une machine UEFI avec Secure Boot actif, le firmware contrôle également les signatures des exécutables EFI qu’il accepte. Un chargeur personnalisé ou une image iPXE non signée de manière acceptable peut donc être refusé.

Il faut ainsi distinguer trois problèmes :

le client ne reçoit aucune configuration réseau ;
le client trouve le serveur mais ne télécharge pas son bootloader ;
l’UEFI télécharge correctement le fichier mais refuse de l’exécuter.

Les trois affichent volontiers « Network boot failed », ce qui permet au diagnostic de commencer dans une ambiance sereine et parfaitement explicite.

Construire un petit serveur PXE Debian avec dnsmasq

Pour un laboratoire ou un petit réseau dédié, dnsmasq constitue une solution compacte puisqu’il sait fournir DHCP, TFTP et les informations nécessaires au boot PXE.

N’utilisez cet exemple que sur un segment où dnsmasq doit réellement être le serveur DHCP. S’il existe déjà un DHCP sur le réseau, adaptez l’architecture ou utilisez un mode ProxyDHCP plutôt que d’en lancer un second.

Installer les composants

sudo apt update
sudo apt install dnsmasq

Préparez ensuite le répertoire TFTP :

sudo mkdir -p /srv/tftp

Téléchargez séparément le fichier officiel netboot.tar.gz correspondant à votre version et architecture Debian, puis extrayez-le dans ce répertoire :

sudo tar -xzf netboot.tar.gz -C /srv/tftp

Pour Debian amd64, l’arborescence contient notamment des éléments ressemblant à :

/srv/tftp/
├── pxelinux.0
└── debian-installer/
    └── amd64/
        ├── linux
        ├── initrd.gz
        ├── bootnetx64.efi
        └── grub/

Configurer dnsmasq

Sur un réseau de laboratoire dédié, une configuration simplifiée peut ressembler à ceci :

interface=enp1s0
bind-interfaces

dhcp-range=192.168.50.100,192.168.50.200,255.255.255.0,12h
dhcp-option=3,192.168.50.1

enable-tftp
tftp-root=/srv/tftp

pxe-service=x86PC,"Debian PXE BIOS","pxelinux.0"
pxe-service=X86-64_EFI,"Debian PXE UEFI","debian-installer/amd64/bootnetx64.efi"

Adaptez évidemment l’interface, le sous-réseau, la passerelle et les fichiers de boot à votre infrastructure.

Vérifiez ensuite la syntaxe :

sudo dnsmasq --test

Puis redémarrez et contrôlez le service :

sudo systemctl restart dnsmasq
systemctl status dnsmasq

Pour suivre les événements pendant un essai PXE :

journalctl -u dnsmasq -f

Cette commande est souvent plus instructive que de contempler pendant vingt minutes le message PXE-E53: No boot filename received.

iPXE : dépasser les limites du PXE traditionnel

Le PXE historique s’appuie beaucoup sur TFTP, protocole volontairement minimaliste. iPXE peut être chargé à la place ou en complément du firmware PXE pour fournir des fonctions beaucoup plus avancées.

Il sait notamment travailler avec HTTP et HTTPS, utiliser des scripts, afficher des menus et enchaîner différents environnements de démarrage.

Une stratégie fréquente consiste à effectuer un petit bootstrap par TFTP :

PXE firmware
    ↓
TFTP
    ↓
iPXE
    ↓
HTTP / HTTPS
    ↓
menu + noyau + initrd

Pour un BIOS Legacy, on rencontre fréquemment :

undionly.kpxe

et pour UEFI :

ipxe.efi

Une fois iPXE lancé, un script peut par exemple charger un noyau et son initrd depuis un serveur HTTP :

#!ipxe

dhcp
kernel http://192.168.50.10/boot/linux
initrd http://192.168.50.10/boot/initrd.gz
boot

HTTP est généralement beaucoup plus performant et flexible que TFTP pour les gros fichiers.

UEFI HTTP Boot

Certains firmwares UEFI modernes prennent directement en charge le démarrage HTTP. Dans ce cas, il devient même possible de récupérer le premier programme EFI via HTTP et de réduire la dépendance à TFTP.

La compatibilité dépend toutefois du firmware des machines. Dans un parc hétérogène, conserver un chemin PXE/TFTP pour certains clients et HTTP/iPXE pour d’autres reste fréquent.

À quoi sert réellement PXE ?

Le boot réseau devient particulièrement intéressant lorsque l’on gère plusieurs machines.

Usage	Exemple
Installation d’OS	Déployer Debian sur des dizaines de postes
Installation automatisée	Associer PXE à preseed, FAI ou d’autres outils
Imagerie	FOG Project ou Clonezilla Server
Maintenance	Démarrer un environnement de diagnostic ou de récupération
Provisioning	Installer automatiquement des serveurs bare-metal
Tests	Démarrer ponctuellement un système live sans média local

PXE ne doit toutefois pas être confondu avec Wake-on-LAN. WoL peut demander à une machine éteinte de s’allumer si son matériel et sa configuration le permettent ; PXE lui indique ensuite quoi démarrer.

Les deux peuvent évidemment être combinés :

Wake-on-LAN
    ↓
machine allumée
    ↓
PXE
    ↓
installation ou maintenance automatique

Sécurité et dépannage

Le PXE traditionnel a été conçu pour fonctionner sur un réseau local relativement maîtrisé. DHCP et TFTP classiques ne fournissent pas à eux seuls les garanties que l’on attendrait d’un protocole moderne exposé à un réseau hostile.

Il est donc prudent de séparer ou contrôler l’infrastructure de provisioning, d’éviter les serveurs DHCP sauvages, de limiter les ressources disponibles et de tenir compte de Secure Boot ou de mécanismes cryptographiques lorsque la chaîne de confiance l’exige.

Pour le dépannage, procédez dans l’ordre plutôt que de modifier simultanément DHCP, TFTP, GRUB, le BIOS et trois câbles :

Le client tente-t-il réellement un boot réseau ? Vérifiez l’ordre de boot et le firmware.
Obtient-il une adresse IP ? Contrôlez DHCP et le VLAN.
Reçoit-il le bon bootloader pour son architecture ? BIOS et UEFI n’utilisent pas nécessairement le même fichier.
Le fichier est-il accessible ? Consultez les logs TFTP/dnsmasq.
Le bootloader démarre-t-il ? Un problème Secure Boot ou d’architecture peut intervenir.
Le noyau et l’initrd sont-ils trouvés ? Vérifiez chemins et noms de fichiers.
L’installateur accède-t-il ensuite au réseau ? DNS, routage, HTTP et dépôts deviennent alors les suspects suivants.

Une capture réseau peut également être extrêmement utile :

sudo tcpdump -ni enp1s0 'port 67 or port 68 or port 69'

Elle permet de vérifier rapidement si les échanges DHCP et TFTP ont réellement lieu.

Conclusion : automatiser le boot sans automatiser les catastrophes

PXE transforme une opération physique répétitive en infrastructure de déploiement :

firmware
→ DHCP
→ programme de boot
→ noyau / initrd
→ installateur ou système
→ automatisation

Le modèle historique BIOS + pxelinux.0 reste utile à comprendre, mais une infrastructure moderne doit aussi tenir compte d’UEFI, de Secure Boot et de chargeurs comme GRUB ou iPXE. Pour les nouveaux déploiements, HTTP et HTTPS peuvent prendre en charge une part croissante du transfert des fichiers, tandis que TFTP reste souvent cantonné au premier bootstrap.

Le principal danger n’est finalement pas la complexité de PXE. C’est la facilité avec laquelle une infrastructure bien automatisée peut reproduire une mauvaise configuration sur cinquante machines avant que l’administrateur ait terminé son café.

Testez donc sur un VLAN de laboratoire, vérifiez le fichier de boot reçu par chaque architecture et automatisez progressivement.

Être fainéant est une excellente qualité d’administrateur système, à condition d’automatiser la bonne chose.

Post Views: 6