I. Présentation

L’idée de ce tutoriel est de vous présenter différentes techniques de mise en œuvre de l’amorçage réseau PXE (Pre-boot eXecution Environment). Pour ne léser personne, j’ai opté pour 2 implémentations distinctes, l’une consistant à installer un PXE sur un NAS de type Busybox (Linux) et l’autre chargé de modifier le mécanisme d’amorçage WDS en y injectant un syslinux.

L’intérêt principal de PXE réside dans le fait qu’il vous affranchit des médias de type CD ou autres clés USB. Toutefois, il peut également engendrer une augmentation significative du trafic réseau et doit donc être implémenté avec parcimonie dans votre environnement. Notez également qu’il n’est pas obligatoire d’implémenter un serveur PXE sur chaque sous-réseau. En effet, pour bénéficier des services PXE dans plusieurs sous-réseaux, il suffit d’agir sur l’option DHCP 66 sur laquelle je reviendrais plus tard.

A. Rappels sur PXE (WDS)

Pour garantir un mécanisme d’amorçage PXE, il est nécessaire d’offrir un adressage IP dynamique aux clients via un serveur BOOTP ou DHCP. Les clients peuvent ensuite télécharger un système d’amorçage via un serveur Trivial FTP (alias TFTP). Le schéma ci-après symbolise les principales étapes de ce processus.

Notez que les serveurs DHCP et PXE (dérivé de BOOTP) sont techniquement très proches et utilisent les mêmes ports de communication réseau.(D’où la nécessiter de désactiver l’option d’écoute lorsque le DHCP est présent sur le serveur WDS lui-même).  En présence d’Active Directory, les serveurs WDS doivent être “autorisés” au même titre que les serveurs DHCP.

Concernant PXE, les 2 options DHCP les plus intéressantes sont :

Option 66 : Nom d’hôte du serveur de démarrage – C’est-à-dire l’adresse IP ou le nom du serveur chargé de fournir un système d’amorçage à la machine cliente.

Option 67 : Nom du fichier de démarrage – permets de stipuler le nom du fichier d’amorçage (précédé du chemin éventuel, relatif à la racine TFTP du serveur). – Ne confondez pas l’option 67 avec le port 67, ça n’a rien à voir 

 

II. Mise en œuvre de WinPE/PXE sur un NAS Synology

Si comme moi, vous disposez d’un petit serveur NAS, de type Synology et d’une FreeBox (ou autre boitier d’accès Internet) chargée de distribuer les  adresses IP sur votre réseau local, vous pouvez envisager la solution suivante.

A. Activation du service NFS sur le NAS

Commencez par activer le service NFS sur votre NAS, via le panneau de configuration Synology (DSM4.3) en cliquant sur l’icône ci-dessous :

 

Sélectionnez l’onglet “Service NFS“, puis cochez la case “Activez NFS” puis par la même occasion cochez la case “Activer la prise en charge de NFS 4“.

Laissez les autres valeurs par défaut puis cliquez sur le bouton “Appliquer“. Acceptez le message vous indiquant que les services réseau vont redémarrer, puis fermez cette page.

 

B. Création d’un partage SMB (Windows) et NFS (Unix)

À partir de l’icône “File Station“, créez un nouveau dossier partagé, comme par exemple “PXEBOOT”

Cliquez sur le bouton “OK“. Cette action doit vous amener sur l’écran de “configuration des privilèges“.

Pour simplifier les copies et l’administration par la suite, cochez la case “Lecture/écriture” pour le compte “Admin“, puis cliquez sur le bouton “OK“.

De retour dans la fenêtre “Panneau de configuration … Dossier partagé“, votre nouveau partage doit être sélectionné. Cliquez alors sur le bouton “Privilèges … Privilèges NFS“, puis sur le bouton “Créer”

Sous la fenêtre “Créer une règle NFS“, entrez la/les machine(s) qui auront accès au partage NFS dans le champ “Nom d’hôte ou IP*”

Note : Comme indiqué *, plusieurs syntaxes sont autorisées. Ici, nous avons opté pour la notation CIDR (Classless Inter-Domain Routing), soit le réseau 192.168.0.0 avec un masque de classe C par défaut (255.255.255.0) donc /24

 

Sélectionnez ensuite “Lecture seule” dans la liste du champ “Privilège” et la valeur “Mapper vers guest” dans le champ “Root squash” *

Note : Cette option (de sécurité linux) a pour but d’empêcher un client de devenir root sur le système de fichiers NFS stockés sur le serveur

Cliquez 2 fois sur les boutons “OK” pour valider cette configuration.

 

C. Installation du PXE sur le NAS Synology

Pour cela, il faut procéder au téléchargement puis à la configuration d’un syslinux  (Modules PXE sous Linux). Vous pouvez trouver différents tutoriels sur la toile, comme par exemple en français ici et les sources de syslinux  ici

En gros, il vous faudra principalement modifier le fichier “PXEBOOT\pxelinux.cfg\default” afin qu’il ressemble à ceci :

DEFAULT menu.c32
MENU TITLE PXE Boot Menu de demo
PROMPT 0
TIMEOUT 100
ONTIMEOUT chainlocal

LABEL chainlocal
	MENU LABEL Demarrage sur le disque local
    MENU DEFAULT
	KERNEL chain.c32
	APPEND hd0

LABEL Demarrage sur WinPE generique
   LINUX memdisk
   INITRD ISO/Generic_x86.iso
   APPEND iso raw
  
LABEL Demarrage de CloneZilla
   LINUX memdisk
   INITRD ISO/clonezilla-live-2.4.2-10-i686-pae.iso
   APPEND iso

Je vous conseille d’effectuer la modification de ce fichier sans extension avec Notepad++ afin d’éviter les effets de bords et de format liés à l’utilisation du Bloc-notes Windows.

 

Et stocker vos images .iso sous le dossier “PXEBOOT\ISO“, comme par exemple une image de client LiteTouch ou générique de MDT, une image WinPE de votre cru, une image de réparation WinRE et pourquoi pas une image du logiciel libre Clonezilla – Pour peu que cela soit des images amorçables au format .ISO, ou (WinImage) libre à vous de choisir 

Si vous ne voulez vraiment pas vous casser la tête, vous pouvez télécharger mon exemple prêt à l’emploi :

• Pour la version complète, c’est ici (~455Mo)
  • Contient une image WinPE 32 bits avec quelques petits outils (cf CustPE : Comment installer vos propres outils dans WinPE ?)
  • Contient une image LiveIso de CloneZilla v2.4.2-10 pour système 32 bits/PAE (PC Récents)

 

• Pour la version sans les .ISO, c’est ici (~110Ko)
  • Pour l’image WinPE, utilisez simplement le MDT (cf Debuter avec MDT 2013)

Pour CloneZilla, vous trouverez les sources ici, sans oublier de choisir le format “.iso” au niveau de “File Type”

Copiez tous ces fichiers dans le fameux dossier “PXEBOOT” du NAS, créé précédemment.

Dans le panneau de configuration du NAS, cliquez sur l’icône “FTP“, puis sélectionnez l’onglet “TFTP / PXE“.

Cochez la case “Activer le service TFTP” puis cliquez sur le premier bouton “Selectionnez” afin de choisir le dossier racine “PXEBOOT“.

Cochez la case “Configurer le service DHCP sur ce serveur pour PXE”

A ce moment, il est possible que l’interface vous demande d’installer DHCP Server s’il n’est pas déjà installé. Laissez vous guider par l’assistant Synology, il va très bien s’en charger pour peu que l’accès Internet soit valide.

Cliquez sur le second bouton “Selectionnez” afin de choisir le fichier du chargeur de démarrage, soit “pxelinux.0”

La particularité de cette configuration réside dans la présence de 2 serveurs DHCP sur un même réseau. En effet, dans mon cas, la Freebox assure la distribution standard des adresses IP alors que le NAS fournira le chargeur de démarrage (option DHCP 67).

Dans le champ “Serveur DNS” et “Passerelle” entrez l’adresse de la box. Pour le reste, entrez une petite plage d’adresse IP (celles-ci ne seront pas retenues par le client DHCP)

Ça marche plutôt très bien, mais malgré mon analyse je n’ai pas encore d’explication claire sur ce comportement et j’aurais préféré stipuler explicitement l’option 66 sur le serveur DHCP (Freebox) afin d’indiquer le serveur PXE (NAS). – N’hésitez pas à commenter cet article si vous avez  des informations pertinentes sur le sujet  

• cf mon complément en annexe

Ensuite cliquez sur le bouton “Appliquer“.

D. Test du résultat

À partir d’une machine virtuelle ou physique, démarrer l’ordinateur sur l’amorçage PXE (généralement via [F12]). Après quelques secondes, vous devriez voir apparaître le menu suivant:

Voilà, c’est fini pour cet exemple, mais cela devrait marcher pour la plupart des NAS de type Busybox et pour les moins fortunés, je vous conseille la lecture d’un excellent article de Julien Darakdjian sur “Déployer Windows avec un Raspberry Pi“. Je vous concède que c’est un peu geek sur les bords, mais j’avoue que pour l’avoir testé, avoir un MDT complet dans le creux de la main pour une petite trentaine d’euros, c’était plutôt plaisant ( kifant pour les plus jeunes )

 

III. Mise en œuvre de syslinux sur WDS

Pour de nombreuses sociétés, universités ou centres de formation, la solution de déploiement ne se cantonne pas toujours à des machines sous Windows et peut conduire à des choix difficiles. Dans le cadre d’une complémentarité  avec les systèmes d’exploitation tels que Linux que WDS ne prend pas en charge, je vous propose une approche alternative,  prétexte à une analyse plus approfondie des mécanismes du chargeur de démarrage WDS (“bootstrap loader”).

A. Rappels et précisions sur WDS

Au besoin, reportez-vous à mon tutoriel sur WDS.

En premier lieu, il convient de présenter la structure des dossiers retenue par Microsoft pour son serveur WDS. La racine, dénommée “TFTP Root“, est située dans le dossier défini lors de l’installation (ie. “E:\RemoteInstall\” ), mais les clients ont un droit de lecture par défaut uniquement sur les sous-dossiers “boot” et “tmp”. Ces réglages sont respectivement stipulés sous la clé de registre  suivante :

“HKLM:\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP”

• Pour l’emplacement de la racine TFTP via l’entrée [REG_SZ] “RootFolder” =  “E:\RemoteInstall”
• Pour les droits de lecture des clients PXE via l’entrée [REG_MULTI_SZ] “ReadFilter” = “\boot\* \tmp\* boot\* tmp\*”.

Au niveau de la racine TFTP, on distinguera 2 dossiers essentiels :

• “Boot” : Contient la structure composée principalement des fichiers liés à l’amorçage (Bootstrap Loaders) et des images .WIM de démarrage (Autrement dit, les images système WinPE).
• “Images” : Contient les images .WIM d’installation (Autrement dit, les distributions Windows préparées avec “sysprep”)

 

Dans la structure de dossier “Boot“,  il semblerait que Microsoft ait choisi d’utiliser un sous-répertoire propre à chaque plateforme (x86, x64, IA64,arm …), dans lesquels sont stockés les fichiers  d’amorçage (tels que bootmgr.exe , default.bcd, pxeboot.com, wdsnbp.com …)  et un sous-dossier “Images” dans lequel sont placés les images .WIM de WinPE ainsi qu’un fichier “.WIM.bcd” associé.

Sur le plan pratique, il apparait que les fichiers situés dans les dossiers x86 et x64 sont identiques et le répertoire  x86x64 ne contient que le fichier de configuration d’amorçage. En focalisant les actions uniquement sur le dossier x86, je n’ai pas relevé de soucis notables avec des machines x64. Réciproquement, si vous travaillez sur le dossier x64, et adaptez les réglages en conséquence, les résultats devraient être sensiblement les mêmes.

Le premier chargeur d’amorçage PXE, nommé “wdsnbp.com” commence par valider l’architecture processeur du client puis, initialise l’amorçage correspondant. En fonction des réglages du serveur la machine peut attendre une confirmation (cf  périphériques en attente)  ou initialiser le chargeur par défaut “pxeboot.com“(son équivalent, le fichier “pxeboot.n12” évite la confirmation du chargement via un second appui sur la touche [F12]). En fonction des images de démarrage disponibles, un éventuel menu est ensuite affiché puis le chargement du noyau WinPE est effectué.

Ce processus peut être modifié au niveau des propriétés du serveur sous l’onglet “Démarrer“.

En résumé, sous WDS, le principe d’amorçage standard PXE pourrait schématiquement être représenté comme suit :

 

Note : Sous WDS, les fichiers portant l’extension “.n12” sont équivalents à leurs homologues “.com”  à la différence qu’ils ne demandent pas de confirmation via l’appui de la touche [F12].

B. Mise en œuvre d’un chainage PXE Linux sur WDS

Dans cette démonstration ostensiblement marginale, je souhaitais simplement démontrer qu’il était possible de substituer ce système d’amorçage par un chargeur Linux ayant la possibilité de rendre la main au chargeur WDS initial en cas de besoin.

1. Récupérer un noyau syslinux

Pour modifier le processus d’amorçage précédemment décrit, vous devez préalablement télécharger un noyau “syslinux” tel que la version 4.07 à l’adresse suivante  http://www.kernel.org/pub/linux/utils/boot/syslinux/

Sachant que certains de ces fichiers spéciaux ne portent pas d’extension, pensez à démasquer les extensions de fichiers connus afin d’éviter les confusions, surtout si vous effectuez ces manipulations via l’interface graphique de Windows.

Choisissez l’un des packages proposés,  portant idéalement une extension “.zip” afin de le gérer au sein de l’explorateur Windows. Vous devrez ensuite extraire de cette archive  les 3 fichiers suivants vers le dossier “Boot\x86”  situé sous la racine TFTP du serveur WDS, soit “\RemoteInstall“.

• modules/pxechain.com
• core/pxelinux.0
• com32/menu/menu.c32

 

2. Facultatif : Récupérer une distribution Linux

Téléchargez ensuite un noyau d’amorçage réseau Linux comme par exemple celui d’une distribution Ubuntu à l’adresse suivante : http://archive.ubuntu.com/ubuntu/dists/devel/main/installer-i386/20101020ubuntu387/images/hd-media/

Enregistrez les 2 fichiers “vmlinuz” et “initrd.gz” dans le même dossier “boot\x86” situé sous la racine TFTP du serveur WDS.

Note : Faites bien attention à respecter les extensions. En effet, lors du téléchargement d’un fichier spécial tel que “vmlinuz” une extension “.txt” peut être ajoutée à votre insu via l’explorateur Windows.

 

3. Facultatif : Ajouter un outil de test mémoire

Pour compléter cet exemple, je vous propose d’ajouter le célèbre outil de test mémoire “Memtest86” que vous pouvez télécharger à l’adresse suivante : http://www.memtest.org/download/5.01/memtest86+-5.01.bin

Si vous avez récupéré un fichier au format “.gz”, ouvrez cette archive avec “7-Zip” et faites une extraction de l’unique fichier dans ce même dossier “boot/x86” sous la racine TFTP du serveur WDS, puis renommez ce fichier “memtest86” sans extension.

 

4. Préparer les amorces PXE

À partir de l’explorateur Windows ou en ligne de commande, au niveau du sous-dossier “Boot\x86“, créez une copie du fichier “pxeboot.n12” et renommez-la en “pxeboot.0“. Faites de même pour le fichier “abortpxe.com” que vous renommerez en “abortpxe.0”

Au regard du schéma précédent sur WDS, vous pourriez me reprocher de ne pas prendre en considération le fichier “wdsnbp.com”. Ceci est lié au comportement de ce “pré-chargeur” qui redemander une confirmation via [F12] et tourner en boucle sur le menu.

Créez un sous-dossier nommé “pxelinux.cfg” : Un fichier de configuration nommé “Default.” (sans extension) doit être stocké dans ce dossier. Tapez les commandes suivantes :

mkdir E:\RemoteInstall\Boot\pxelinux.cfg
echo "" > E:\RemoteInstall\Boot\pxelinux.cfg\default.

Ajoutez le contenu suivant dans ce fichier en prenant garde à ne pas ajouter d’extension erronée.

#
# Fichier de configuration PXE
#
default menu.c32
prompt 0

menu title Demarrage PXE / Installation

label WDS (Services d'installation Windows)
	menu default
	kernel pxeboot.0
	
label Test memoire
	kernel memtest86

label Installation Ubuntu
	kernel vmlinuz
	append initrd=initrd.gz vga=788

label Demarrage sur disque local
	localboot 0

label Linux PXE
  menu label Linux PXE server...
 	kernel pxechain.com
	append 192.168.100.201::pxelinux.0
	# Entrez l'adresse IP du serveur PXE Linux
# append 192.168.100.201::\boot\x86\wdsnbp.com
  	# ou d'un autre serveur WDS "standard"

Label Annuler le boot PXE
	kernel abortpxe.0

A ce stade, le dossier “boot/x86” doit contenir les dossiers/fichiers suivants (surlignés)

Pour activer la nouvelle amorce sur le noyau PXE linux, entrez les commandes suivantes dans une invite de commande sur le serveur WDS.

 

wdsutil /set-server /bootprogram:boot\x64\pxelinux.0 /architecture:x64
wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.0 /architecture:x64
wdsutil /set-server /bootprogram:boot\x64\pxelinux.0 /architecture:x86
wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.0 /architecture:x86

 

5. Stipuler le fichier de démarrage au niveau des options DHCP

Il ne reste plus qu’à modifier l’option DHCP  stipulant le  fichier d’amorçage. Au niveau de la console du serveur DHCP (sous Windows), développez l’arborescence afin de sélectionner “DHCP … NomDuServeur … IPv4 … Etendue [Nom d’étendue] … Options d’étendue”

Si vous n’avez pas déjà configuré cette option, utilisez le menu “Action … Configurer les options” ou le menu contextuel.  Cochez la case “067  Nom du fichier de démarrage“, puis entrez la valeur “Boot\x86\pxelinux.0” dans le champ “Valeur de chaine“. Dans le cas contraire, éditez simplement l’option existante afin d’en modifier la valeur.

Pour les accrocs de la ligne de commande, vous pouvez configurer ces options d’étendue sur un DHCP  Windows via les commandes suivantes

 

netsh dhcp server scope 192.168.100.0 set optionvalue 066 STRING 192.168.100.201
netsh dhcp server scope 192.168.100.0 set optionvalue 067 STRING boot\x86\pxelinux.0

Ou via le module DHCP de Powershell depuis Windows Server 2012

Set-DhcpServerv4OptionValue -ScopeId 192.168.100.0 -OptionId 66 -Value "192.168.100.201"
Set-DhcpServerv4OptionValue -ScopeId 192.168.100.0 -OptionId 67 -Value "boot\x86\pxelinux.0"

 

C. Test du résultat

À partir d’une machine virtuelle ou physique, démarrer l’ordinateur sur l’amorçage PXE (généralement via [F12]).

Le résultat devrait ressembler à ceci :

Le premier choix aura pour conséquence de poursuivre l’initialisation de l’amorce WDS classique, comme par exemple :

Voilà, c’est tout pour cette fois. Si vous avez des questions, des remarques ou même des critiques à formuler sur cet article, n’hésitez pas à utiliser les commentaires : cette démarche d’échange est généralement plutôt constructive.

Bien à vous

Christophe

IV. Annexe : Mon complément sur les mécanismes DHCP et PXE

1. Démarrage du poste client

2. Le BIOS de la carte réseau initialise le processus PXE et envoie une diffusion générale (broadcast DHCP-Discover) avec l’option #60 (Client Class IDentifier) définie sur “PXEClient”

Note : Si cette option est aussi définie au niveau du serveur DHCP, cela indique que le serveur assure également un service PXE. L’usage de l’option #43 (Vendor Specific) est similaire, mais déconseillé en raison de sa complexité de mise en œuvre.

3. La carte réseau obtient une ou plusieurs propositions d’adresse IP (DHCP_Offer) et choisit celle qui répond à l’option #60 ou à défaut celle du DHCP le plus rapide.

4a. Si ces trames de retour contiennent les options DHCP #66 et #67, la carte réseau utilise directement le contenu de ces options pour communiquer avec le serveur PXE.

4b. Si les options DHCP #66 et #67 ne sont pas spécifiées, alors la carte réseau envoie une nouvelle diffusion générale afin trouver un serveur PXE. Si le serveur PXE n’est pas sur le sous-réseau local, un agent relai (ou iphelper) peut transmettre la demande vers autre serveur DHCP/PXE. Une fois le serveur PXE est contacté, il renvoie l’information au client afin que le client puisse communiquer directement avec le serveur PXE.

5. Si le serveur PXE a pu être contacté, il délivre le bootstrap (NBP) au client

6. La carte réseau charge l’image d’amorçage via TFTP à partir du serveur PXE.