Environnement d'exécution de pré-démarrage

En informatique, la spécification Preboot eXecution Environment ( PXE ; souvent prononcé / ˈpɪksiː / pixie , souvent appelée PXE Boot/ pixie boot ) décrit un environnement client-serveur standardisé qui démarre un assemblage logiciel, récupéré à partir d'un réseau, sur des clients compatibles PXE. Côté client, il ne nécessite qu'un contrôleur d'interface réseau (NIC) compatible PXE et utilise un petit ensemble de protocoles réseau standard tels que le protocole DHCP ( Dynamic Host Configuration Protocol ) et le protocole TFTP (Trivial File Transfer Protocol ).

Le concept à l'origine du PXE remonte aux débuts des protocoles tels que BOOTP /DHCP/TFTP et, depuis 2015, il fait partie de la norme UEFI ( Unified Extensible Firmware Interface ). Dans les centres de données modernes, le PXE est le choix le plus fréquent pour le démarrage, l'installation et le déploiement du système d'exploitation.

Depuis le début des réseaux informatiques, il existe un besoin persistant de systèmes clients capables de démarrer des images logicielles appropriées, avec des paramètres de configuration appropriés, tous deux récupérés au moment du démarrage à partir d'un ou de plusieurs serveurs réseau . Cet objectif nécessite qu'un client utilise un ensemble de services de pré-démarrage, basés sur des protocoles réseau standard de l'industrie . De plus, le programme d'amorçage du réseau (NBP) qui est initialement téléchargé et exécuté doit être construit à l'aide d'une couche de micrologiciel client (au niveau du périphérique à amorcer via PXE) fournissant un moyen standardisé indépendant du matériel pour interagir avec l'environnement de démarrage réseau environnant. Dans ce cas, la disponibilité et la soumission aux normes sont un facteur clé requis pour garantir l'interopérabilité du système de processus de démarrage réseau.

L'une des premières tentatives dans ce domaine a été le chargement par bootstrap à l'aide de la norme TFTP RFC 906, publiée en 1984, qui a établi la norme TFTP ( Trivial File Transfer Protocol ) RFC 783 publiée en 1981 à utiliser comme protocole de transfert de fichiers standard pour le chargement par bootstrap. Elle a été suivie peu après par la norme Bootstrap Protocol RFC 951 (BOOTP), publiée en 1985, qui a permis à une machine cliente sans disque de découvrir sa propre adresse IP, l'adresse d'un serveur TFTP et le nom d'un NBP à charger en mémoire et à exécuter. Les difficultés d'implémentation de BOOTP, entre autres raisons, ont finalement conduit au développement de la norme Dynamic Host Configuration Protocol RFC 2131 (DHCP) publiée en 1997. L'approche pionnière TFTP/BOOTP/DHCP n'a pas été à la hauteur, car à l'époque, elle ne définissait pas le côté client standardisé requis de l'environnement de provisionnement.

L'environnement d'exécution de pré-amorçage (PXE) a été introduit dans le cadre de la structure Wired for Management Intel et est décrit dans la spécification publiée par Intel et SystemSoft. La version 2.0 de PXE a été publiée en décembre 1998 et la mise à jour 2.1 a été rendue publique en septembre 1999. L'environnement PXE utilise plusieurs protocoles client-serveur standard, notamment DHCP et TFTP (désormais définis par la RFC 1350 publiée en 1992). Dans le schéma PXE, le côté client de l'équation de provisionnement fait partie intégrante de la norme PXE et est implémenté soit sous la forme d'une extension du BIOS de la carte d'interface réseau (NIC), soit sous la forme de périphériques actuels dans le code UEFI . Cette couche de micrologiciel distinctive met à disposition du client les fonctions d'une interface de périphérique réseau universel (UNDI) de base, d'une pile UDP / IP minimaliste , d'un module client Preboot (DHCP) et d'un module client TFTP, formant ensemble les interfaces de programmation d'applications (API) PXE utilisées par le NBP lorsqu'il doit interagir avec les services offerts par l'homologue serveur de l'environnement PXE. Le faible débit du TFTP , en particulier lorsqu'il est utilisé sur des liaisons à latence élevée , a été initialement atténué par l'option TFTP Blocksize RFC 2348 publiée en mai 1998, puis par l'option TFTP Windowsize RFC 7440 publiée en janvier 2015, permettant des livraisons de charges utiles potentiellement plus importantes et améliorant ainsi le débit.

L'environnement PXE repose sur une combinaison de protocoles Internet standard du secteur, à savoir UDP/IP, DHCP et TFTP. Ces protocoles ont été sélectionnés car ils sont facilement implémentés dans le micrologiciel de la carte réseau du client, ce qui permet d'obtenir des ROM PXE standardisées à faible encombrement . La standardisation, la petite taille des images du micrologiciel PXE et leur faible utilisation des ressources sont quelques-uns des principaux objectifs de conception, permettant au côté client de la norme PXE d'être implémenté de manière identique sur une grande variété de systèmes, allant des ordinateurs clients puissants aux ordinateurs monocartes (SBC) à ressources limitées et aux ordinateurs système sur puce (SoC).

DHCP est utilisé pour fournir les paramètres réseau client appropriés et en particulier l'emplacement (adresse IP) du serveur TFTP hébergeant, prêt à être téléchargé, le programme d'amorçage initial (NBP) et les fichiers complémentaires. Pour lancer une session d'amorçage PXE, le composant DHCP du microprogramme PXE du client diffuse un paquet DHCPDISCOVER contenant des options spécifiques à PXE sur le port 67/UDP (port du serveur DHCP) ; il demande la configuration réseau requise et les paramètres de démarrage réseau. Les options spécifiques à PXE identifient la transaction DHCP initiée comme une transaction PXE. Les serveurs DHCP standard (non compatibles PXE) pourront répondre avec un DHCPOFFER normal contenant des informations réseau (c'est-à-dire l'adresse IP) mais pas les paramètres spécifiques à PXE. Un client PXE ne pourra pas démarrer s'il ne reçoit une réponse que d'un serveur DHCP non compatible PXE.

Après avoir analysé un serveur DHCP PXE activé DHCPOFFER, le client pourra définir sa propre adresse IP réseau, son masque IP, etc., et pointer vers les ressources de démarrage situées sur le réseau, en fonction de l'adresse IP du serveur TFTP reçue et du nom du NBP. Le client transfère ensuite le NBP dans sa propre mémoire vive (RAM) à l'aide de TFTP, le vérifie éventuellement (c'est-à-dire UEFI Secure Boot ) et démarre enfin à partir de celui-ci. Les NBP ne sont que le premier maillon du processus de chaîne de démarrage et ils demandent généralement via TFTP un petit ensemble de fichiers complémentaires afin de lancer un système d'exploitation minimaliste (c'est-à-dire WindowsPE ou un noyau Linux de base + initrd ). Le petit système d'exploitation charge ses propres pilotes réseau et sa pile TCP/IP. À ce stade, les instructions restantes requises pour démarrer ou installer un système d'exploitation complet ne sont pas fournies via TFTP, mais à l'aide d'un protocole de transfert robuste (tel que HTTP , CIFS ou NFS ).

L'environnement client/serveur PXE a été conçu pour pouvoir être intégré de manière transparente à une infrastructure de serveur DHCP et TFTP déjà en place. Cet objectif de conception représentait un défi lorsqu'il s'agissait de traiter le protocole DHCP classique. Les serveurs DHCP d'entreprise sont généralement soumis à des politiques strictes conçues pour empêcher l'ajout facile de paramètres et de règles supplémentaires nécessaires à la prise en charge d'un environnement PXE. C'est pour cette raison que la norme PXE a développé le concept de redirection DHCP ou « proxyDHCP ». L'idée derrière un proxyDHCP est de diviser les exigences DHCP PXE en deux unités de serveur gérées et administrées indépendamment :

1. Le serveur DHCP classique fournissant l'adresse IP, le masque IP, etc. à tous les clients DHCP de démarrage .
2. Le serveur proxyDHCP fournit l'adresse IP du serveur TFTP et le nom du NBP uniquement aux clients de démarrage identifiés PXE .

Dans un environnement DHCP plus serveur proxyDHCP le client PXE diffuse initialement un seul paquet PXE DHCPDISCOVER et reçoit deux DHCPOFFER complémentaires ; l'un provenant du serveur DHCP standard non compatible PXE et l'autre du serveur proxyDHCP. Les deux réponses ensemble fournissent les informations requises pour permettre au client PXE de poursuivre son processus de démarrage. Cette approche non intrusive permet de configurer un environnement PXE sans toucher à la configuration d'un serveur DHCP déjà opérationnel. Le service proxyDHCP peut également s'exécuter sur le même hôte que le service DHCP standard, mais même dans ce cas, il s'agit de deux applications exécutées et administrées indépendamment. Étant donné que deux services ne peuvent pas utiliser le même port 67/UDP sur le même hôte, le proxyDHCP s'exécute sur le port 4011/UDP. L'approche proxyDHCP s'est avérée extrêmement utile dans un large éventail de scénarios PXE allant des environnements d'entreprise aux environnements domestiques.

PXE a été conçu en tenant compte de plusieurs architectures système. La version 2.1 de la spécification définissait des identifiants d'architecture pour six types de systèmes, dont IA-64 et DEC Alpha . Cependant, PXE v2.1 ne couvrait complètement que IA-32 . Malgré ce manque apparent d'exhaustivité, Intel a récemment décidé de prendre largement en charge PXE dans la nouvelle spécification UEFI , étendant la fonctionnalité PXE à tous les environnements EFI/UEFI. La spécification actuelle de l'interface de micrologiciel extensible unifiée 2.4A, section 21 Protocoles réseau — SNP, PXE et BIS définit les protocoles qui fournissent l'accès aux périphériques réseau lors de l'exécution dans l'environnement des services de démarrage UEFI. Ces protocoles incluent le protocole réseau simple (SNP), le protocole de code de base PXE (PXE) et le protocole de services d'intégrité de démarrage (BIS). Aujourd'hui, dans un environnement PXE, la détection de l'architecture client est rarement basée sur les identifiants initialement inclus dans la spécification PXE v2.1. Au lieu de cela, chaque ordinateur qui démarrera à partir du réseau doit avoir défini l'option DHCP 93 pour indiquer l'architecture du client. Cela permet à un serveur PXE de connaître (au moment du démarrage) l'architecture exacte du client à partir du premier paquet de démarrage réseau.

Avec l'avènement d' IPv6 , DHCP a évolué vers DHCPv6 ; le besoin d'options prenant en charge PXE dans le nouveau protocole DHCP a été résolu en 2010.

L'extension du micrologiciel client PXE d'origine a été conçue comme une ROM optionnelle pour le BIOS IA-32 . Ainsi, un ordinateur personnel (PC) était à l'origine rendu compatible PXE en installant un contrôleur d'interface réseau (NIC) qui fournissait une ROM optionnelle PXE. Aujourd'hui, le code PXE client est directement inclus dans le micrologiciel de la carte réseau ou dans le cadre du micrologiciel UEFI de la carte mère.

Même si le micrologiciel PXE client d'origine a été écrit par Intel et toujours fourni gratuitement sous forme de module de format de code objet IA32 inclus dans leur kit de développement de produit (PDK), le monde open source a produit au fil des ans des projets dérivés non standard comme gPXE / iPXE proposant leurs propres ROM. Alors que les ROM basées sur Intel implémentent le côté client de la norme PXE depuis plus de 20 ans, certains utilisateurs étaient prêts à échanger des fonctionnalités supplémentaires contre de la stabilité et de la conformité à la norme PXE.

L'acceptation du PXE depuis la version 2.1 est omniprésente ; aujourd'hui, il est pratiquement impossible de trouver une carte réseau sans micrologiciel PXE. La disponibilité de matériel Gigabit Ethernet peu coûteux (cartes réseau, commutateurs , routeurs , etc.) a fait du PXE la méthode la plus rapide disponible pour installer un système d'exploitation sur un client face aux alternatives classiques CD , DVD et clés USB .

Au fil des années, plusieurs projets majeurs ont inclus le support PXE, notamment :

• Toutes les principales distributions Linux.
• OpenVMS sur HPE Integrity et matériel x86-64 .
• Services d'installation à distance Microsoft (RIS)
• Services de déploiement Microsoft Windows (WDS)
• Boîte à outils de déploiement Microsoft (MDT)
• Gestionnaire de configuration Microsoft System Center (SCCM)

En ce qui concerne le développement de NBP, il existe plusieurs projets implémentant des gestionnaires de démarrage capables d'offrir des fonctionnalités étendues de menu de démarrage, des capacités de script, etc. :

• Syslinux PXELINUX
• gPXE / iPXE

Tous les projets mentionnés ci-dessus, lorsqu'ils sont capables de démarrer/installer plus d'un système d'exploitation, fonctionnent sous un paradigme « Boot Manager - Boot Loader ». Le NBP initial est un Boot Manager capable de récupérer sa propre configuration et de déployer un menu d'options de démarrage. L'utilisateur sélectionne une option de démarrage et un Boot Loader dépendant du système d'exploitation est téléchargé et exécuté afin de poursuivre la procédure de démarrage spécifique sélectionnée.

Apple a mis au point une approche de démarrage réseau très similaire sous l'égide de la spécification Boot Server Discovery Protocol (BSDP). BSDP v0.1 a été initialement publié par Apple en août 1999 et sa dernière version v1.0.8 a été publiée en septembre 2010. Mac OS X Server incluait un outil système appelé NetBoot . Un client NetBoot utilise BSDP pour acquérir dynamiquement des ressources qui lui permettent de démarrer un système d'exploitation approprié. BSDP est conçu sur DHCP en utilisant des informations spécifiques au fournisseur pour fournir la fonctionnalité NetBoot supplémentaire non présente dans le DHCP standard. Le protocole est implémenté dans le micrologiciel client. Au démarrage, le client obtient une adresse IP via DHCP puis découvre les serveurs de démarrage à l'aide de BSDP. Chaque serveur BSDP répond avec des informations de démarrage composées de :

• Une liste d'images de système d'exploitation amorçables
• L'image par défaut du système d'exploitation
• L'image du système d'exploitation actuellement sélectionnée par le client (si définie)

Le client choisit un système d'exploitation dans la liste et envoie un message au serveur indiquant sa sélection. Le serveur de démarrage sélectionné répond en fournissant le fichier de démarrage et l'image de démarrage, ainsi que toute autre information nécessaire pour télécharger et exécuter le système d'exploitation sélectionné.

Microsoft a créé une extension non chevauchante de l'environnement PXE avec sa couche de négociation des informations de démarrage (BINL). BINL est implémenté en tant que service serveur et constitue un composant clé de ses stratégies de services d'installation à distance (RIS) et de services de déploiement Windows (WDS). Il comprend certains processus de préparation et un protocole réseau qui pourrait être considéré d'une manière ou d'une autre comme une extension DHCP conçue par Microsoft. BINL est une technologie propriétaire de Microsoft qui utilise le micrologiciel client standard PXE. Il n'existe actuellement aucune spécification BINL disponible au public.

• KR Sollins (juin 1981). LE PROTOCOLE TFTP (REVISION 2). Groupe de travail réseau. doi : 10.17487/RFC0783 . RFC 783. Statut inconnu. Obsolète depuis la RFC 1350.
• R. Finlayson (juin 1984). Chargement Bootstrap à l'aide de TFTP. Groupe de travail réseau. doi : 10.17487/RFC0906 . RFC 906. Statut inconnu.
• Bill Croft; John Gilmore (septembre 1985). PROTOCOLE BOOTSTRAP (BOOTP). Groupe de travail réseau. doi : 10.17487/RFC0951 . RFC 951. Projet de norme. Mise à jour par RFC 1395, 1497, 1532, 1542 et 5494.
• K. Sollins (juillet 1992). LE PROTOCOLE TFTP (RÉVISION 2). Groupe de travail réseau. doi : 10.17487/RFC1350 . STD 33. RFC 1350. Norme Internet 33. Rend obsolète la RFC 783. Mise à jour par les RFC 1782, 1783, 1784, 1785, 2347, 2348 et 2349.
• R. Droms (mars 1997). Protocole de configuration dynamique d'hôte. Groupe de travail réseau. doi : 10.17487/RFC2131 . RFC 2131. Projet de norme. Rend obsolète la RFC 1541. Mise à jour par les RFC 3396, 4361, 5494 et 6842.
• G. Malkin; A. Harkin (mai 1998). Option de taille de bloc TFTP. Groupe de travail réseau. doi : 10.17487/RFC2348 . RFC 2348. Projet de norme. Mise à jour de la RFC 1350. Rend obsolète la RFC 1783.
• M. Johnston (juin 2006). S. Venaas (éd.). Options du protocole DHCP (Dynamic Host Configuration Protocol) pour l'environnement Intel Preboot eXecution Environment (PXE). Groupe de travail réseau. doi : 10.17487/RFC4578 . RFC 4578. Informatif.
• T. Huth ; J. Freimann ; V. Zimmer ; D. Thaler (septembre 2010). Options DHCPv6 pour le démarrage réseau. Groupe de travail sur l'ingénierie Internet . est ce que je : 10.17487/RFC5970 . ISSN2070-1721 . RFC5970 . Options DHCPv6 pour le démarrage réseauNorme proposée.
• P. Masotta (janvier 2015). Option TFTP Windowsize. Groupe de travail d'ingénierie Internet (IETF). doi : 10.17487/RFC7440 . ISSN 2070-1721. RFC 7440. Norme proposée.