Installons Linux et Windows depuis le réseau (PXE) simplement, de manière automatisée

Installons Linux et Windows depuis le réseau (PXE) simplement, de manière automatisée

Un Raspberry Pi et c'est parti !

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

04/05/2019 21 minutes
19

Installons Linux et Windows depuis le réseau (PXE) simplement, de manière automatisée

Les jours de repos s'enchaînent, et vous ne savez pas quoi faire pour occuper ces périodes parfois pluvieuses ? Et pourquoi pas utiliser l'amorçage PXE pour simplifier l'installation des machines de votre réseau. Un Raspberry Pi (et au moins un PC) suffit !

Installer un système d'exploitation passe le plus souvent par une clé USB désormais, le lecteur optique ayant été largement mis au placard ces dernières années. Mais lorsque vous avez plusieurs machines à configurer ou que vous passez souvent d'un OS à un autre, ce n'est pas la méthode la plus simple à utiliser.

Certes, il existe des boîtiers pour HDD/SSD permettant de monter les différentes images ISO présentes, pour que le système y accède comme s'il s'agissait d'un CD/DVD. Cela permet de ne pas avoir à utiliser différentes clés USB ou à transférer constamment des images. Mais ce n'est pas idéal.

Car il faut régulièrement y placer les nouvelles images, et donc le relier à un PC pour ça. Surtout, il ne peut être utilisé que pour une seule machine à la fois du fait de sa connectique USB. Impensable dans le cadre de déploiements ou lorsque l'on veut gérer les choses à distance, comme pour un petit serveur placé dans le coin d'une salle, sans écran/clavier/souris.

C'est ici que l'amorçage PXE (Pre-boot eXecution Environment) intervient, pour une installation simple via le réseau.

Notre dossier sur l'automatisation de l'installation des OS :

Un peu de théorie

Dans le domaine professionnel, l'installation à distance est largement utilisée et déjà possible sur les cartes mères équipées d'un KVM matériel, comme celles avec BMC (voir ici ou ). On peut ainsi monter une ISO à travers une interface web et/ou Java, démarrer dessus et l'utiliser pour mettre en place le système d'exploitation.

La méthode est intéressante, mais lente et là encore individuelle. Car cela revient à envoyer les fichiers d'installation à chaque machine depuis le poste utilisateur, alors que l'on préfèrerait que ce soit l'inverse : qu'elles aillent chercher l'image depuis un serveur de fichier prévu à cet effet, avec une bonne connexion et capable de soutenir de lourdes charges.

Avec l'amorçage PXE, on ne démarre pas sur un HDD/SSD, un CD/DVD ou même une clé USB, on initie une connexion au réseau local. Un serveur DHCP (Dynamic Host Configuration Protocol) se charge de fournir une adresse IP à la machine ainsi que l'adresse d'un fichier d'initialisation (BootP). Celui-ci est accessible via un serveur TFTP (Trivial FTP).

PXE BootPXE Boot

Ce dispositif est loin d'être nouveau, mais est encore massivement utilisé pour des déploiements en entreprise. Il repose sur des technologies qui ne sont pas de toute fraîcheur, mais simples à mettre en œuvre et éprouvées. Elles sont surtout peu gourmandes en ressources et compatibles avec un très grand nombre de machines, récentes ou non.

TFTP en est le parfait exemple puisque ce protocole remonte à 1981, sa dernière révision datant de 1995, avec quelques évolutions mineures depuis. Il a été pensé pour permettre de transférer facilement des fichiers entre un client et un serveur, sans mécanique de sécurité (ou presque), ne nécessitant que peu de ressources.

D'autres technologies peuvent ensuite venir permettre l'accès aux données liées à l'installation comme nous le verrons plus loin dans cet article. Toutes sont disponibles à travers des logiciels open source.

Pré-requis

Pour notre guide du jour nous utilisons un Raspberry Pi 3 B+ configuré pour un usage distant (via SSH), mais la procédure peut très bien être utilisée sur une distribution GNU/Linux classique sur un serveur ou via une machine virtuelle. C'est d'ailleurs ce que nous vous recommandons si vous avez parfois un grand nombre de machines à installer, le Raspberry Pi étant limité tant dans les performances de son stockage que de son réseau. 

Il vous faut également un PC capable de démarrer sur sa carte réseau, ce qui est souvent le cas. Mais il faut en général activer cette fonctionnalité depuis le BIOS/UEFI. Pour cela pressez la touche Suppr ou F2 au démarrage puis rendez-vous dans les paramètres liés au boot ou du réseau, le manuel de votre PC/carte mère pouvant détailler ces étapes :

  • BIOS UEFI Boot PXE ASRock
  • BIOS UEFI Boot PXE ASRock
  • BIOS UEFI Boot PXE ASRock

Vous y trouverez en général tout ce qu'il faut pour activer le démarrage sur le réseau local LAN (non-UEFI dans notre cas). Nous vous conseillons de ne pas l'utiliser comme méthode de boot automatique, mais plutôt à la demande, via le menu qui apparaît en pressant une des touches F8 à F12 au démarrage (selon le constructeur).

Notez que bien que cela soit possible, l'amorçage PXE ne passe en général pas par une connexion sans fil mais par un réseau filaire classique, nécessitant la présence d'un port RJ45. De quoi limiter les possibilités pour certains PC portables.

Installation et configuration du serveur DHCP/TFTP

La première étape consiste à mettre en place des serveurs DHCP et TFTP sur votre réseau. Pour le premier, c'est le plus souvent le cas à travers la box de votre fournisseur d'accès qui fournit leurs IP à l'ensemble de vos appareils.

Et c'est un problème. En effet, deux serveurs DHCP ne peuvent pas cohabiter, puisque cela reviendrait à une situation où chacun attribue des IP de manière non-coordonnée. Surtout, les serveurs DHCP mis en place par les opérateurs ne sont pas faits pour être modifiés, ne serait-ce que pour fonctionner en lien avec un serveur TFTP, même chez Free

La première possibilité est donc de couper le serveur DHCP déjà présent sur le réseau et de le remplacer par le vôtre. C'est la méthode à utiliser lorsque vous voulez un contrôle complet du dispositif ou que vous activez le serveur TFTP depuis un NAS QNAP ou Synology (pouvant faire office de serveur DHCP), par exemple.

PXE SynologyPXE Synology
Les paramètres TFTP/DHCP de DSM 6.x chez Synology

La seconde, pour laquelle nous avons opté dans ce guide, est la plus simple : utiliser un proxy DHCP. Ainsi, le serveur utilisé pour votre amorçage PXE ne fera qu'envoyer les requêtes à celui déjà présent sur le réseau, faisant suivre ses réponses en les adaptant au besoin. Pour cela, nous nous reposons sur Dnsmasq

Il s'agit d'une application open source, disponible dans la plupart des distributions, permettant de gérer différents services, dont le proxy DHCP et TFTP dont nous avons besoin. Vous pouvez aussi vous reposer sur des outils tels ques PfSense. Si vous préférez Windows, il existe de petites applications tout-en-un comme Tiny PXE Server (version 1.0.0.14+).

En complément, il nous faut les bibliothèques pxelinux, pour le démarrage du serveur et syslinux pour initialiser les OS. Sous Raspbian, cela revient à taper la commande suivante :

sudo apt install dnsmasq pxelinux syslinux-common

On commence par créer un répertoire qui sera utilisé comme racine du serveur TFTP et celui pour le menu de l'interface PXE. Nous y plaçons les fichiers qui nous seront nécessaires :

sudo mkdir -p /var/tftpboot/pxelinux.cfg
cd /var/tftpboot
sudo touch pxelinux.cfg/default

sudo cp /usr/lib/PXELINUX/pxelinux.0 .
sudo cp /usr/lib/syslinux/memdisk .
sudo cp /usr/lib/syslinux/modules/bios/* .

On sauvegarde la configuration de Dnsmasq, contenant sa documentation. Elle pourra vous être utile si vous souhaitez aller plus loin dans la gestion des paramètres et du menu. Puis on ouvre son remplaçant :

sudo mv /etc/dnsmasq.conf /etc/dnsmasq.conf.old
sudo nano /etc/dnsmasq.conf

On y place les lignes suivantes. Adaptez la variable dhcp-range à votre réseau :

## On n'active pas le serveur DNS
port=0

## On initialise le serveur TFTP
enable-tftp
tftp-root=/var/tftpboot

## On initialise le proxy DHCP
dhcp-range=192.168.0.0, proxy

## On initialise le service PXE
dhcp-boot=pxelinux.0

## On initialise le menu du service PXE
pxe-prompt="Veuillez faire votre choix :"
pxe-service=x86PC, "Boot depuis le disque local", 30
pxe-service=x86PC, "Interface PXE", pxelinux

## On active le log du serveur DHCP
log-dhcp

On sauvegarde le fichier (CTRL+X) et on relance le service :

sudo systemctl restart dnsmasq.service

C'est terminé ! Votre serveur fournissant un amorçage PXE est désormais fonctionnel. Pour le vérifier il vous suffit de lancer une machine en lui demandant de démarrer sur le réseau, il faut bien entendu qu'elle y soit connectée. Si tout s'est bien passé vous verrez après quelques secondes le serveur DHCP fournir une IP à la machine.

Le menu s'affiche alors vous proposant de démarrer sur son disque local (par défaut au bout de 30 secondes) ou sur le serveur PXE. Vous pouvez allumer ou stopper Dnsmasq via les commandes suivantes : 

sudo systemctl stop dnsmasq.service
sudo systemctl start dnsmasq.service

Hardware Detection Tool et autres petites options

Notre serveur PXE fonctionne, mais il affiche une erreur. Et pour cause, son menu est vide. Nous allons donc l'utiliser pour lancer un premier outil, intégré de base à syslinux : HDT. Il s'agit d'une petite interface affichant la composition de votre ordinateur : CPU, mémoire, carte mère, stockage, etc. 

Pour cela, il faut éditer le menu :

sudo nano /var/tftpboot/pxelinux.cfg/default

On y ajoute les lignes suivantes :

DEFAULT menu.c32
MENU TITLE Serveur d'installation PXE
LABEL hdt
MENU LABEL ^Hardware Detection Tool
KERNEL hdt.c32

Démarrez la machine sur le réseau local, accédez à l'interface PXE, vous pourrez alors lancer HDT, la ligne pouvant être sélectionnée via la touche H (grâce au ^) en cas de choix multiples. Attention, le clavier est configuré en QWERTY.

PXE BootPXE Boot

Un point que l'on peut configurer, tout comme le menu, notamment ses couleurs en ajoutant des textes d'aides, des sous-menus, etc. Tous les détails sont par ici. Pour lancer le choix par défaut au bout de 30 secondes, ajoutons la ligne suivante :

TIMEOUT 300

D'autres modules simples à intégrer sont disponibles, pour démarrer depuis un SAN (iSCSI, AoE), le stockage local ou redémarrer la machine. Dans ce dernier cas, il faut par exemple ajouter ces lignes. Ce sera notre valeur par défaut :

LABEL reboot
MENU DEFAULT
MENU LABEL Reboot
COM32 reboot.c32

Debian 9.9 (Mini ISO)

Notre serveur PXE fonctionne, mais il ne fait pas encore grand-chose. Il est temps de l'utiliser pour installer une première distribution : Debian 9.9. Elle est fournie sous une forme dite « netboot » avec les éléments nécessaires pour démarrer l'installation, qui utilisera ensuite un miroir local ou distant.

Pour ce premier essai nous optons pour une ISO qui est la forme la plus simple à utiliser. Commençons par la télécharger :

sudo mkdir /var/tftpboot/_iso
cd /var/tftpboot/_iso
sudo wget http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/netboot/mini.iso

Pensez à vérifier l'empreinte SHA-256 du fichier récupéré :

sudo wget http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS
grep -F /netboot/mini.iso SHA256SUMS
sha256sum mini.iso

Si les deux empreintes correspondent, c'est bon. On peut ensuite faire un peu de ménage :

sudo rm SHA256SUMS
sudo mv mini.iso debian_9.9_netboot.iso

Éditons le menu :

sudo nano /var/tftpboot/pxelinux.cfg/default

On y ajoute les lignes suivantes :

LABEL debian
MENU LABEL ^Debian 9.9 (Netboot)
LINUX memdisk
INITRD _iso/debian_9.9_netboot.iso

Le dispositif est ici assez basique puisque l'on demande à la machine de récupérer l'ISO depuis le serveur TFTP pour la placer en mémoire. Elle est alors montée comme un ramdisk puis utilisée. Notez que vous pouvez utiliser cette image avec la procédure d'automatisation par préconfiguration décrite dans notre précédent article.

Parfois, certaines images nécessitent une ligne complémentaire pour être chargées correctement :

APPEND iso raw

Cette façon de faire fonctionne sans problème avec les images prévues à cet effet, mais pas passé une certaine taille (1,2 Go environ) ou la plupart des ISO d'installation classique qui vont chercher un CD/DVD ou une clé USB, sans les trouver. Ce procédé peut donc être utilisé pour des images de dépannage et autres systèmes minimalistes, mais pas plus.

Fedora 30 (initrd)

Analysons maintenant un autre cas, Fedora 30, avec une autre méthode qui est la plus courante : charger un simple noyau compressé (vmlinuz) et une image système minimale (initrd.img). Les développeurs de Fedora fournissent les fichiers nécessaires via l'image pxeboot. Il suffit donc de télécharger les fichiers puis de les placer dans un dossier à part :

sudo mkdir /var/tftpboot/fedora_30
sudo wget -P /var/tftpboot/fedora_30/ http://mirror.in2p3.fr/pub/fedora/linux/releases/30/Workstation/x86_64/os/images/pxeboot/vmlinuz
sudo wget -P /var/tftpboot/fedora_30/ http://mirror.in2p3.fr/pub/fedora/linux/releases/30/Workstation/x86_64/os/images/pxeboot/initrd.img

Il suffit ensuite d'ajouter une entrée au menu afin d'initialiser la procédure d'installation en lui indiquant où trouver les fichiers complémentaires à travers le site de Fedora :

LABEL fedora30
MENU LABEL ^Fedora 30 (HTTP)
KERNEL fedora_30/vmlinuz
INITRD fedora_30/initrd.img
APPEND ip=dhcp inst.stage2=http://mirror.in2p3.fr/pub/fedora/linux/releases/30/Workstation/x86_64/os/

Une fois la procédure lancée et le système démarré le téléchargement commencera. Lorsque c'est terminé, l'installation se déroulera de manière classique. Une méthode facile à adapter à l'arrivée de nouvelles versions.

Netboot.xyz et iPXE : choisissez votre distribution

Un projet a décidé de généraliser les deux façons de faire que nous venons d'analyser : Netboot.xyz. Il utilise une version iPXE plutôt que PXE pour avoir accès à des protocoles avancés, vous pouvez l'utiliser comme environnement de base dans la configuration de votre serveur DHCP ou l'utiliser à travers un noyau à charger, votre UEFI, une clé USB, une ISO, etc. 

Nous opterons ici pour la dernière solution, en ajoutant l'entrée suivante à notre menu :

LABEL netboot
MENU LABEL ^Netboot.xyz
LINUX memdisk
INITRD _iso/netboot.xyz.iso
APPEND iso raw

La dernière ligne est ici ajoutée car il ne s'agit ne s'agit pas d'une ISO dite hybride, elle ne peut donc pas être montée comme un simple disque de stockage pour fonctionner correctement. Il faut bien entendu récupérer l'ISO au passage :

sudo wget https://boot.netboot.xyz/ipxe/netboot.xyz.iso

Une fois Netboot.xyz lancé, vous verrez un large choix de distributions, Live ou non, que vous pourrez installer comme bon vous semble. Vous pouvez même l'utiliser pour initialiser une installation de Windows (nous y reviendrons). Attention néanmoins, aucune donnée n'étant stockée localement, tous les fichiers seront téléchargés depuis des serveurs ce qui nécessite une bonne connexion internet pour ne pas y passer des heures.

PXE Netboot.xyzPXE Netboot.xyz

Ubuntu 19.04 Desktop (Live) : NFS à la rescousse

Passons maintenant à un cas plus complexe : le démarrage d'une ISO avec un système « Live », qui doit être directement utilisable. Nous avons cette fois opté pour Ubuntu 19.04 dont l'image pèse environ 2 Go.

Pour commencer, récupérons l'ISO et le fichier d'empreintes SHA-256 : 

sudo wget http://releases.ubuntu.com/19.04/ubuntu-19.04-desktop-amd64.iso
sudo wget http://releases.ubuntu.com/19.04/SHA256SUMS

On vérifie que le fichier récupéré est valide :

grep -F ubuntu-19.04-desktop-amd64.iso SHA256SUMS
sha256sum ubuntu-19.04-desktop-amd64.iso

Un Rasbperry Pi étant en général limité en espace de stockage sur sa microSD, n'hésitez pas à utiliser un périphérique USB ou un partage sur votre réseau local pour stocker vos ISO. Dans ce dernier cas, pensez néanmoins à monter ce partage dès le démarrage de la machine pour éviter les mauvaises surprises en cas de coupure de courant par exemple.

Puisqu'il est impossible de monter l'image récupérée en mémoire via TFTP, il faut utiliser une autre méthode pour accéder aux données. Ainsi, nous allons à nouveau utiliser l'amorçage PXE pour initialiser un noyau et le système de base, mais au lieu de lui faire passer les données via un serveur HTTP distant comme pour Fedora, nous allons utiliser un partage local. 

C'est le protocole NFS (Network File System) qui est ici utilisé puisqu'il est simple à mettre en œuvre avec une sécurité reposant plutôt sur des plages d'IP que des identifiants. Il n'y a de toutes façons pas besoin de plus pour accéder à une ISO sur un réseau local. Une fois l'image vérifiée, on la monte, on copie son contenu dans un répertoire puis on fait le ménage :

sudo mkdir -p /mnt/iso/ /var/tftpboot/expanded/ubuntu_19.04_desktop
sudo mount -o loop /var/tftpboot/_iso/ubuntu-19.04-desktop-amd64.iso /mnt/iso/
sudo cp -r /mnt/iso/* /var/tftpboot/expanded/ubuntu_19.04_desktop
sudo umount /mnt/iso
sudo rm /var/tftpboot/_iso/ubuntu-19.04-desktop-amd64.iso SHA256SUMS

On copie le noyau et le système de base dans un nouveau répertoire :

sudo mkdir /var/tftpboot/ubuntu_19.04
cp /var/tftpboot/expanded/ubuntu_19.04_desktop/casper/{initrd,vmlinuz} /var/tftpboot/ubuntu_19.04

On installe ensuite le service NFS puis on édite son fichier de configuration :

sudo apt install nfs-kernel-server
sudo nano /etc/exports

On y ajoute la ligne suivante (adaptez la plage d'IP à celle de votre réseau local), permettant à n'importe quelle machine du réseau d'accéder au dossier en lecture :

/var/tftpboot/expanded/ubuntu_19.04_desktop 192.168.0.*(sync,no_root_squash,no_subtree_check,ro)

Une fois le fichier enregistré, on initialise le serveur NFS :

sudo exportfs -a

On peut alors ajouter une nouvelle entrée à notre menu :

LABEL ubuntudesk
MENU LABEL ^Ubuntu Desktop 19.04 (Live)
KERNEL ubuntu_19.04/vmlinuz
INITRD ubuntu_19.04/initrd
APPEND boot=casper rootfstype=nfs netboot=nfs nfsroot=192.168.0.222:/var/tftpboot/expanded/ubuntu_19.04_desktop splash ---

Cela vous permet d'avoir une installation Ubuntu Desktop Live fonctionnelle accédant au contenu de l'ISO via le protocole NFS, et donc sans dépendre du débit de votre connexion internet.

Automatisation de l'installation d'Ubuntu

L'intérêt de cette méthode, c'est qu'elle permet d'ajouter simplement un fichier de préconfiguration (preseed). Mais là encore il faut user d'astuce pour le fournir lors du démarrage. Ne pouvant être chargé depuis un média local on passe par un serveur HTTP où l'on va rendre ce fichier disponible. Vous pouvez utiliser le modèle fourni dans notre précédent article.

sudo apt install apache2
sudo nano /var/www/html/auto.seed

Une fois le fichier enregistré, on modifie la dernière ligne de notre menu en ajoutant les paramètres d'automatisation, ce qui donne pour la nouvelle entrée suivante :

LABEL ubuntuauto
MENU LABEL ^Ubuntu Desktop 19.04 (Preseed)
KERNEL ubuntu_19.04/vmlinuz
INITRD ubuntu_19.04/initomatird
APPEND boot=casper preseed/url=http://192.168.0.222/auto.seed autc-ubiquity noprompt rootfstype=nfs netboot=nfs nfsroot=192.168.0.222:/var/tftpboot/expanded/ubuntu_19.04_desktop splash ---

Si vous choisissez cet élément dans le menu, l'installation d'Ubuntu démarrera, ne vous demandera rien et la machine sera redémarrée une fois la procédure terminée. Le tout, sans aucun média physique. Vous pouvez utiliser différents fichiers de préconfiguration avec une même image, et donc en changer selon les cas et les machines.

Environnement WinPE : le cas Windows 10

Le déploiement de Windows est un peu particulier. En effet, il est impensable de charger son ISO complète via le serveur TFTP. Aucun dispositif de type netboot minimal avec chargement des fichiers d'installation depuis les serveurs de Microsoft n'est ouvert à tous. Il faut donc passer par Windows Preinstallation Environment (WinPE).

C'est lui qui démarre lorsque vous initiez une installation depuis une clé USB ou un CD/DVD. Il contient une version minimale de Windows permettant de lancer le fichier setup.exe présent à la racine de l'image. Avec un amorçage PXE, nous l'utiliserons conjointement avec un dossier partagé sur le réseau local contenant les fichiers d'installation. 

Pour commencer, il vous faut récupérer Windows Assessment and Deployment Kit (ADK) ainsi que WinPE, désormais proposé sous la forme d'un complément :

Vous n'êtes pas obligés d'installer l'USMT (600 Mo) de l'ADK, qui gère la migration des utilisateurs et n'est pas nécessaire. L'ensemble occupera ainsi entre 6 et 7 Go d'espace de stockage.

  • Création de l'ISO WinPE

Une fois les deux fichiers ci-dessus récupérés installez-les sous Windows. Il faut ensuite ouvrir l'environnement de déploiement et d'outils de création d'images avec les droit administrateur pour lancer la création de l'ISO. Tout d'abord pour récupérer le contenu de WinPE (dans son édition 64 bits) :

copype amd64 c:\winpe_amd64

Ensuite on va ajouter un fichier qui permettra de monter le partage réseau dès le lancement de WinPE et de lancer automatiquement la procédure d'installation (avec un clavier français). Pour cela, il faut monter le fichier boot.wim :

Dism /mount-image /imagefile:c:\winpe_amd64\media\sources\boot.wim /index:1 /mountdir:c:\winpe_amd64\mount
Dism /Image:c:\winpe_amd64\mount /Set-InputLocale:fr-fr

Il aut ensuite éditer le fichier chargé au démarrage de l'OS :

notepad C:\WinPE_amd64\mount\Windows\System32\startnet.cmd

Modifiez son contenu comme suit (en utilisant l'adresse IP de votre Raspberry Pi) :

wpeinit
ping 192.168.0.222 -n 21 -w 1000 > null
net use z: \\192.168.0.222\RasPXE /user:dummy pass
z:\expanded\setup.exe

Cela nous permet de vérifier que le serveur est joignable, pour ensuite monter le partage réseau et lancer l'installation. D'autres possibilités de personnalisation s'ouvrent à vous à cette étape : ajouter des fichiers, des pilotes, des applications, des réglages et autres mises à jour. Vous pouvez même réduire la taille de l'image produite en suivant ce guide.

Une fois terminé, on démonte le fichier de boot et on génère l'ISO :

Dism /unmount-image /mountdir:c:\winpe_amd64\mount /commit
Makewinpemedia /iso c:\winpe_amd64 c:\winpe_amd64\winpe_amd64.iso

On peut alors supprimer les fichiers de travail et désinstaller l'ADK/WinPE. 

  • Création du partage réseau via Samba

Retour à la console de notre Raspberry Pi pour installer et configurer Samba ainsi que le partage réseau :

sudo apt install samba
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.old
sudo nano /etc/samba/smb.conf

Il faut ensuite créer le répertoire qui sera utilisé pour le partage réseau  :

sudo mkdir /var/tftpboot/winpe

Remplissez le fichier de configuration comme suit :

security = user
passdb backend = tdbsam
map to guest = Bad User

[RasPXE]
path = /var/tftpboot/winpe
browseable = yes
guest ok = yes
writeable = yes

On a créé ainsi un partage permettant à n'importe qui sur le réseau local d'écrire dans le répertoire contenant winpe. Pour que cela fonctionne il faut redémarrer le service Samba :

sudo systemctl restart smbd.service
  • Transfert de l'image Windows 10 sur le Raspberry Pi

On peut alors y accéder depuis Windows à l'adresse de notre RaspberryPi : \\192.168.0.222 dans notre cas. On y transfère alors l'ISO de WinPE et le contenu d'une image Windows 10 dans le répertoire expanded. Pour cela, on créé le dossier puis on monte l'image en double-cliquant dessus. Il suffit ensuite de faire un simple copier-coller :

WinPEWinPE 

On peut alors remplacer par no le paramètre d'accès en écriture de Samba et redémarrer à nouveau le service. On ajoute ensuite l'entrée suivante à notre menu :

LABEL winpe
MENU LABEL ^WinPE
LINUX memdisk
INITRD winpe/winpe_amd64.iso
APPEND iso raw

Si tout se passe comme prévu, l'environnement WinPE démarre, lance le script permettant d'accéder au partage réseau puis lance l'installation. Elle pourra alors poursuivre comme si elle avait été lancée depuis une clé USB ou un CD/DVD.

Si vous utilisez iPXE ou Netboot.xyz, sachez qu'ils permettent de charger directement un fichier WIM plutôt que de nécessiter une ISO complète, ce qui peut vous faciliter la tâche. Notez enfin que l'installation de Windows 10 est elle aussi automatisable. Ce sera l'objet d'un prochain article.

Vous trouverez le menu PXE complet et finalisé de cet article par ici.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un peu de théorie

Pré-requis

Installation et configuration du serveur DHCP/TFTP

Hardware Detection Tool et autres petites options

Debian 9.9 (Mini ISO)

Fedora 30 (initrd)

Netboot.xyz et iPXE : choisissez votre distribution

Ubuntu 19.04 Desktop (Live) : NFS à la rescousse

Automatisation de l'installation d'Ubuntu

Environnement WinPE : le cas Windows 10

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (19)


la stack ipxe permet d’aller plus loin dans le processus, avec des conditions plus élaborées, des possibilités de diagnostic, de téléchargement, le support du SSL, etc… elle est un peu plus “compliquée” à mettre en place q’un serveur PXE classique mais permet de faire booter des PC sans stack PXE avec une clé USB dédiée (ou autre support amovible)


J’en parle dans l’article ;) (Bon je sais, il faut lire 24k signes avant de commenter, dur ! <img data-src=" />)


Super ! Je me suis fait ça aussi sur un NAS l’an dernier mais pas moyen de le faire marcher sur une VM HyperV gen2… je me lis ça dans la journée :)


Bel article, direct en favoris, mais ce n’est pas plutôt la ligne éditoriale de IN-H ?


C’est essentiellement logiciel, touché surtout à l’installation des OS et pas lié à un matériel en particulier, donc non ;)


ou j’ai vu, mais le détail de son fonctionnement n’est pas abordé. il s’agit bien d’une stack différente avec son propre menu, commandes, drivers…

elle peut être lancée via le PXE classique via le chainage (c’est ce qu’utlise netboot.xyz) ou bien depuis un support amovible.



les menus peuvent être personnalisés pour afficher diverses informations (IP, passerelle, prochain serveur de chainage, etc) ou pour adapter le fonctionnement à son utilisation.



On peut aussi lancer un Linux Live depuis un PXE, même avec une persistance de données.


C’est un article sur PXE, pas sur iPXE, il est déjà assez long comme ça. Surout, iPXE n’était pas nécessaire pour les points abordés. Donc j’évoque les éléments de base, je donne les liens mais je ne détaille pas. Chaque chose en son temps, comme quand j’ai publié sur preseed avant uniquement sur les ISO avant de parler de PXE.&nbsp;


oui c’est pour ça que je le précise dans les commentaires, car je me doute bien que ce n’était pas pertinent dans l’article. mon commentaire n’était pas une critique mais un ajout d’informations pour les personnes qui seraient intéressées.




Dans ce dernier cas, pensez néanmoins à monter ce partage dès le démarrage de la machine pour éviter les mauvaises surprises en cas de coupure de courant par exemple.





Pour ça que je préfère jouer avec un automonteur du genre autofs. C’est pas le plus idéal en terme de perfs car délai de remontage lors de l’accès au dossier, mais ça éviter de bloquer un système au démarrage parce que le NFS ne répond pas à l’instant T.

Ou que cet abruti cherche à monter le NFS avant d’avoir démarré la pile réseau <img data-src=" />



Mon HTPC exploite ça justement. Toutes les ressources du NAS sont automontées à la demande.

La conf n’est pas bien complexe non plus.


ça me rappelle les PC à l’IUT, qui selon les TP bootaient pour installer un linux ou un windows <img data-src=" />



et de toute façon on jouait à Quake 3 après dessus <img data-src=" />


Bel article ;)



Pour ma part j’utilise pour Windows plutôt Tftpd64 (au lieu de TinyPXE Server), il y a des réglages certes (comme “use anticipation window” pour transférer plus vite) mais je trouve que ça tourne pas mal.

http://tftpd32.jounin.net/tftpd32_download.html



Cela m’a déjà aidé pour WinPE à démarrer en réseau, par exemple pour du déploiement Ghost.








Minikea a écrit :



la stack ipxe permet d’aller plus loin dans le processus, avec des conditions plus élaborées, des possibilités de diagnostic, de téléchargement, le support du SSL, etc… elle est un peu plus “compliquée” à mettre en place q’un serveur PXE classique mais permet de faire booter des PC sans stack PXE avec une clé USB dédiée (ou autre support amovible)







iPXE apporte surtout un vrai support UEFI, qui a toujours été merdique sur PXELinux classique. <img data-src=" />

Et pi obligatoirement passer par la compilation son environnement de boot réseau, ça fait moins “user friendly” tout de suite… <img data-src=" />



Vérifie que tu as bien une “carte réseau héritée” dans ta VM. De base il créé la VM avec une “carte réseau”.

edit : avais mal lu que tu étais en gen2, il me semble que ce n’est dispo qu’en gen1


Pour iPXE il existe des binaires déjà compilés, pas besoin de passer par la compilation pour ceux qui ont peur de copier/coller 2 lignes.



Il est possible d’utiliser wimboot avec pxelinux.



Pour ceux qui veulent rentrer dans le lard directement avec iPXE, si vous avez suivi l’article et utilisé DNSMASQ, il est possible de s’baser là dessus :



dhcp-match=set:x86PC, option:client-arch, 0 #BIOS

dhcp-match=set:UEFI32, option:client-arch, 6 #UEFI32

dhcp-match=set:UEFI64, option:client-arch, 7 #UEFI64

dhcp-match=set:UEFI64, option:client-arch, 9 #EBC -&gt; pareil que UEFI64

dhcp-boot=tag:x86PC, PXE/undionly.kpxe

dhcp-boot=tag:UEFI32, PXE/ipxe_32-bit.efi

dhcp-boot=tag:UEFI64, PXE/ipxe_64-bit.efi

pxe-service=tag:x86PC, X86PC, “BIOS iPXE”, PXE/undionly.kpxe

pxe-service=tag:UEFI32, BC_EFI, “UEFI32 iPXE”, PXE/ipxe_32-bit.efi

pxe-service=tag:UEFI64, X86-64_EFI, “UEFI64 iPXE”, PXE/ipxe_64-bit.efi



dhcp-match=set:ipxeboot,175

dhcp-boot=tag:ipxeboot,http://urlserveurweb/config.ipxe

pxe-service=tag:ipxeboot, X86PC,http://urlserveurweb/config.ipxe



Reste ensuite à faire votre fichier de config iPXE.



Une bonne base par icihttps://github.com/mbirth/ipxe-config/blob/master/boot.ipxe



Pour les froussard, attendez que David déblaye ça avec un article pour vous prendre par la main.


Oui, j’avais quand même oublié ce point il y a peu. Mais je n’ai plus besoin des gen1. Toutes les distrib’ linux ou presque étant parfaitement supporté en gen2 aujourd’hui. Il y a une config’ syslinux pour les uefi mais ça ne marchait pas encore à cause d’un bug sous hyper-V à l’époque. Faut que je ressaye.


Je ne connaissait pas ce mécanisme : je savais que ça existe, mais je n’ai jamais pu le voir en action. J’ai un tout nouveau parc informatique de 10 PC à gérer, je vais peut-être expérimenter ça pour me faire la main, en tout cas j’aime bien l’idée !


Heureux que ça puisse servir <img data-src=" />


Ça va servir, pas de soucis <img data-src=" />

Le point sur lequel je m’interroge le plus c’est la configuration de dnsmasq, et l’inconnue de savoir si le réseau d’entreprise laissera ou non passer ce trafic réseau.