17 Préparation de l'environnement de démarrage réseau #
Ce chapitre décrit la façon de configurer un serveur DHCP et un serveur TFTP fournissant l'infrastructure requise pour démarrer avec PXE.
SUSE® Linux Enterprise Server peut être installé par le biais d'un Preboot Execution Environment (PXE). Le matériel client a besoin de prendre en charge le démarrage via PXE. Le réseau doit être doté d'un serveur DHCP et d'un serveur TFTP fournissant les données requises aux clients. Ce chapitre vous guide dans la configuration des serveurs requis.
PXE démarre uniquement un kernel et initrd. Cela permet de démarrer dans un environnement d'installation ou dans des systèmes actifs. Pour configurer les sources d'installation, reportez-vous au Chapitre 16, Configuration d'une source d'installation réseau.
Cette section expose les tâches de configuration nécessaires pour les scénarios de démarrage complexes. Elle contient des exemples de configuration « prêts à l'emploi » pour le protocole DHCP, le démarrage PXE, le protocole TFTP et la fonction Wake on LAN.
Les exemples supposent que les serveurs DHCP, TFTP et NFS résident sur la même machine ayant pour adresse IP 192.168.1.1
. Tous les services peuvent résider sur des ordinateurs différents sans problème. Veillez à modifier les adresses IP en fonction de vos besoins.
17.1 Configuration d'un serveur DHCP #
Un serveur DHCP fournit des assignations d'adresses IP dynamiques (Section 17.1.1, « Assignation d'adresse dynamique ») et statiques (Section 17.1.2, « Assignation d'adresses IP statiques ») à vos clients réseau. Il annonce les serveurs, les routes et les domaines. Pour les serveurs TFTP, DHCP fournit également les fichiers de kernel et initrd. Les fichiers qui sont chargés dépendent de l'architecture de la machine cible et de l'utilisation éventuelle du démarrage BIOS ou UEFI hérité. Les clients transmettent leur type d'architecture dans leur demande DHCP. Suivant ces informations, le serveur DHCP décide quels fichiers le client doit télécharger pour le démarrage.
À partir de SUSE Linux Enterprise 15,0, il existe des situations spéciales dans lesquelles le démarrage PXE et les installations AutoYaST échouent. Pour plus d'informations et pour connaître la solution, reportez-vous à la Section 17.1.3, « Échecs de l'installation PXE et AutoYaST ».
17.1.1 Assignation d'adresse dynamique #
L'exemple suivant montre comment configurer un serveur DHCP qui assigne des adresses IP aux clients de façon dynamique, et qui annonce les serveurs, les routeurs, les domaines et les fichiers de démarrage.
Connectez-vous en tant qu'utilisateur
root
à la machine qui héberge le serveur DHCP.Activez le serveur DHCP en exécutant la commande
systemctl enable dhcpd
.Ajoutez les lignes suivantes à la configuration de sous-réseau du fichier de configuration du serveur DHCP, situé dans
/etc/dhcpd.conf
:# The following lines are optional option domain-name "my.lab"; option domain-name-servers 192.168.1.1; option routers 192.168.1.1; option ntp-servers 192.168.1.1; ddns-update-style none; default-lease-time 3600; # The following lines are required option arch code 93 = unsigned integer 16; # RFC4578 subnet 192.168.1.0 netmask 255.255.255.0 { next-server 192.168.1.1; range 192.168.1.100 192.168.1.199; default-lease-time 3600; max-lease-time 3600; if option arch = 00:07 or option arch = 00:09 { filename "/EFI/x86/grub.efi"; } else if option arch = 00:0b { filename "/EFI/aarch64/bootaa64.efi"; } else { filename "/BIOS/x86/pxelinux.0"; } }
Cet exemple de configuration utilise le sous-réseau
192.168.1.0/24
avec DHCP, DNS et la passerelle sur le serveur avec l'adresse IP192.168.1.1
. Assurez-vous que toutes les adresses IP sont modifiées en fonction de votre topologie de réseau. Pour plus d'informations sur les options disponibles dans, reportez-vous à la page de manuel
dhcpd.conf
dhcpd.conf.Redémarrez le serveur DHCP en exécutant la commande
systemctl restart dhcpd
.
17.1.2 Assignation d'adresses IP statiques #
Un serveur DHCP peut également assigner des adresses IP statiques et des noms d'hôte à des clients du réseau. Un cas d'utilisation consiste à assigner des adresses statiques à des serveurs. Un autre cas d'utilisation implique de limiter les clients qui peuvent rejoindre le réseau à ceux disposant d'une adresse IP statique, et de ne fournir aucune réserve d'adresses dynamiques.
Modifiez la configuration DHCP ci-dessus conformément à l'exemple suivant :
group { host test { hardware ethernet MAC_ADDRESS; fixed-address IP_ADDRESS; } }
L'instruction d'hôte assigne un nom d'hôte à la cible d'installation. Pour lier le nom d'hôte et l'adresse IP à un hôte spécifique, vous devez indiquer l'adresse matérielle (MAC) du client. Remplacez toutes les variables utilisées dans cet exemple par les valeurs réelles qui correspondent à votre environnement, puis enregistrez les modifications et redémarrez le serveur DHCP.
17.1.3 Échecs de l'installation PXE et AutoYaST #
À partir de SUSE Linux entreprise 15.0 et d'ISC DHCP 4.3.x, des situations spéciales peuvent entraîner un échec du démarrage de PXE et des installations AutoYaST. Si votre serveur DHCP ne possède pas de réserve d'adresses IP dynamiques disponibles, mais n'autorise que des adresses statiques prédéfinies par client, et que les clients envoient des identificateurs de client RFC 4361, les installations PXE/AutoYaST ne fonctionneront pas. (Si le système n'autorise que des adresses assignées à des clients réseau spécifiques et ne fournit pas de réserve d'adresses dynamiques, les machines aléatoires ne peuvent pas se connecter au réseau).
Lorsqu'un nouveau système démarre dans PXE, il envoie une requête au serveur DHCP et s'identifie à l'aide d'un identificateur de client constitué du type de matériel et de l'adresse MAC de l'interface réseau. Il s'agit d'un client-id
(ID client) RFC 2132. Le serveur DHCP propose alors l'adresse IP assignée. Ensuite, le kernel d'installation est chargé et envoie une autre requête DHCP, mais ce client-id
est différent et est envoyé au format RFC 4361. Le serveur DHCP ne reconnaît pas qu'il s'agit du même client et recherche une adresse IP dynamique disponible, alors qu'il n'y en a pas, de sorte que l'installation s'arrête.
La solution consiste à configurer les clients pour qu'ils envoient des ID de client au format RFC 2132. Pour envoyer un client-id
RFC 2132 au cours de l'installation, utilisez linuxrc
afin de transmettre la commande ifcfg
suivante :
ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67, DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67
Le client-id
DHCPv4 RFC 2132 traditionnellement utilisé sur Ethernet est constitué du type de matériel (01
pour Ethernet) et suivi de l'adresse matérielle (adresse MAC), par exemple :
01:52:54:00:02:c2:67
Le client-id
DHCPv4 RFC 4361 tente de corriger le problème d'identification d'une machine qui compte plusieurs interfaces réseau. Le nouveau client-id
DHCPv4 présente le même format que le client-id
DHCPv6. Il commence par le préfixe 0xff
(plutôt que par le type de matériel), suivi de l'IAID (Interface-address Association ID, ID d'association d'adresse d'interface qui décrit l'interface sur la machine) DHCPv6, puis du DUID ( Unique Identifier, identificateur unique DHCP) DHCPv6 qui identifie de manière unique la machine.
Selon le DUID basé sur le type et l'adresse de matériel susmentionnés, le nouveau client-id
DHCPv4 RFC 4361 serait :
En utilisant les derniers octets de l'adresse MAC en tant qu'IAID :
ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
Si l'IAID est un simple numéro incrémenté :
ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
Le champ xx:xx:xx:xx de l'horodatage DUID-LLT (DUID-Link-Layer Timestamp) correspond à un tampon horaire de création. Une couche de liaison de données DUID-LL (DUID-Link-Layer, par exemple 00:03:00:01:$MAC
) n'a pas de tampon horaire.
Pour plus d'informations sur l'utilisation de linuxrc
, reportez-vous au manuel (Guide d'AutoYaST). Consultez également le document man 4 initrd
et la documentation relative aux options dhcp4 "create-cid"
, dhcp6 "default-duid"
dans man 5 wicked-config
, wicked duid --help
et wicked iaid --help
.
17.2 Configuration d'un serveur TFTP #
La procédure suivante explique comment préparer le serveur de façon à ce que les machines clientes dotées de UEFI et BIOS puissent démarrer à distance à l'aide des fichiers exportés par TFTP.
17.2.1 Installation d'un serveur TFTP #
Pour installer un serveur TFTP, procédez comme suit :
Installez le paquetage
tftp
.>
sudo
zypper in tftp
Révisez la configuration
tftpd
dans/etc/sysconfig/tftp
et ajoutez ou modifiez les options selon vos besoins. Reportez-vous àman 8 tftpd
pour plus de détails. Le daemon TFTP fonctionne sans modifier la configuration. Le répertoire racine par défaut des fichiers est/srv/tftpboot
.Assurez-vous que
tftpd
est lancé au moment du démarrage, puis redémarrez-le pour lire la nouvelle configuration.>
sudo
systemctl enable tftp.socket
>
sudo
systemctl restart tftp.socket
17.2.2 Installation des fichiers de démarrage #
SUSE Linux Enterprise Server fournit les fichiers requis pour un démarrage via PXE sur des machines BIOS ou UEFI. Les architectures matérielles suivantes sont prises en charge :
AMD64/Intel 64
AArch64
POWER
IBM Z
Les fichiers nécessaires au démarrage à partir d'une architecture matérielle spécifique sont inclus dans un paquetage de RPM. Installez-le sur la machine exécutant le serveur TFTP :
>
sudo
zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE
Remplacez OS_VERSION (VERSION_SE) par le numéro de version de votre installation SUSE Linux Enterprise Server, par exemple SLE-15-SP3-x86_64, et ARCHITECTURE par l'architecture de votre système, par exemple x86_64
. Le texte obtenu ressemble à ceci : tftpboot-installation-SLE-15-SP3-x86_64. Exécutez zypper se tftpboot
pour rechercher toutes les versions et architectures disponibles.
Les fichiers seront installés dans /srv/tftpboot/SLE-VERSION_SE-ARCHITECTURE
. Vous pouvez également copier les fichiers des autres versions et architectures de SUSE Linux Enterprise Server dans le répertoire /srv/tftpboot
.
L'architecture matérielle client et serveur peut varier. Par exemple, vous pouvez exécuter un serveur TFTP AMD64/Intel 64 et fournir un environnement de démarrage pour les machines client AArch64 en installant le paquetage tftpboot-installation-SLE-15-SP3-aarch64.
/srv/tftpboot/
existant
Si le répertoire /srv/tftpboot
existe déjà sur votre machine, tous les fichiers vont être installés à l'emplacement /usr/share/tftpboot-installation/
. C'est le cas si vous mettez à niveau votre serveur PXE à partir d'une version précédente de SLES.
Pour résoudre ce problème, copiez les fichiers manuellement à partir de /usr/share/tftpboot-installation/
vers /srv/tftpboot/
. Vous pouvez également supprimer /srv/tftpboot/
et réinstaller le paquetage tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE.
17.2.3 Configuration de PXELINUX #
Ouvrez le fichier /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default
dans un éditeur de texte. Remplacez le chemin d'accès du paramètre install
selon votre configuration, comme décrit dans le Chapitre 16, Configuration d'une source d'installation réseau. Remplacez également TFTP_SERVER (SERVEUR_TFTP) par l'adresse IP du serveur TFTP. Pour obtenir une vue d'ensemble des options de configuration PXELINUX, reportez-vous à la Section 17.3, « Options de configuration PXELINUX ».
default linux # install label linux ipappend 2 kernel boot/ARCHITECTURE/loader/linux append initrd=boot/ARCHITECTURE/loader/initrd instsys=tftp://TFTP_SERVER/SLE-OS_VERSION-ARCHITECTURE/boot/ARCHITECTURE/root install=PROTOCOL://SERVER_IP:/PATH display message implicit 1 prompt 1 timeout 50
Pour plus de détails sur les paramètres de démarrage qui sont utilisés sur la ligne append
, reportez-vous à la Section 7.3, « Liste des paramètres de démarrage importants ».
Si nécessaire, modifiez /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message
pour afficher un message dans le menu de démarrage.
17.2.4 Préparation du démarrage PXE pour EFI avec GRUB2 #
Normalement, les fichiers de configuration GRUB2 ne nécessitent aucune modification. Toutefois, les paramètres par défaut n'incluent pas de ressource réseau pour le système d'installation. Pour effectuer une installation complète de SUSE Linux Enterprise Server via le réseau, vous devez spécifier le paramètre install
dans l'instruction linuxefi
du fichier /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg
. Reportez-vous à la Section 7.3.3, « Spécification de la source d'installation » pour plus d'informations sur le paramètre install
.
17.3 Options de configuration PXELINUX #
Les options répertoriées à cet endroit constituent un sous-ensemble de toutes les options disponibles pour le fichier de configuration PXELINUX.
APPEND OPTIONS
Ajoute une ou plusieurs options à la ligne de commande du kernel. Celles-ci sont ajoutées pour les démarrages automatique et manuel. Les options sont ajoutées en tout début de ligne de commande du kernel ; en règle générale, elles peuvent être remplacées par les options de kernel entrées de manière explicite.
APPEND -
N'ajoute rien.
APPEND
suivi d'un seul tiret, utilisé comme argument dans une sectionLABEL
peut servir à remplacer unAPPEND
global.DEFAULT OPTIONS_KERNEL...
Définit la ligne de commande de kernel par défaut. Si PXELINUX démarre automatiquement, il agit comme si les entrées qui figurent après DEFAULT avaient été saisies à l'invite de démarrage, et ce à une exception près : l'option auto est ajoutée automatiquement, ce qui indique un démarrage automatique.
Si aucun fichier de configuration n'existe ou si aucune entrée DEFAULT n'est définie dans le fichier de configuration, la valeur par défaut est le nom de kernel « linux » sans la moindre option.
IFAPPEND FLAG
Ajoute une option spécifique à la ligne de commande du kernel en fonction de la valeur FLAG. L'option
IFAPPEND
est disponible uniquement sur PXELINUX. FLAG attend une valeur, décrite dans le Tableau 17.1, « Options de ligne de commande de kernel générées et ajoutées à partir deIFAPPEND
» :Tableau 17.1 : Options de ligne de commande de kernel générées et ajoutées à partir deIFAPPEND
#Argument
Ligne de commande de kernel générée/Description
1
ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK
Les marques de réservation sont remplacées en fonction de l'entrée du serveur de démarrage PXE ou DHCP/BOOTP.
Notez que cette option ne remplace par l'exécution d'un client DHCP sur le système démarré. En l'absence de renouvellements réguliers, le bail obtenu par le BIOS PXE arrive à expiration, ce qui permet au serveur DHCP de réutiliser l'adresse IP.
2
BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE
Cette option se révèle particulièrement utile pour éviter les timeouts lorsque le serveur d'installation sonde les interfaces LAN les unes après les autres jusqu'à ce qu'il obtienne une réponse d'un serveur DHCP. Cette option permet à un programme initrd de déterminer l'interface à partir de laquelle le système a démarré. linuxrc lit cette option et utilise cette interface réseau.
4
SYSUUID=SYSTEM_UUID
Ajoute des UUID en hexadécimales minuscules ; voir
/usr/share/doc/packages/syslinux/pxelinux.txt
LABEL LABEL KERNEL IMAGE APPEND OPTIONS...
Indique que si LABEL est entré comme étant le kernel à démarrer, PXELINUX doit démarrer à la place IMAGE et les options
APPEND
spécifiées doivent être utilisées. Elles remplacent celles qui sont spécifiées dans la section globale du fichier avant la première commandeLABEL
. La valeur par défaut de la variable IMAGE est identique à celle de LABEL ; si aucune optionAPPEND
n'est fournie, l'entrée globale (le cas échéant) est utilisée par défaut. Vous pouvez utiliser jusqu'à 128 entréesLABEL
.PXELINUX utilise la syntaxe suivante :
label MYLABEL kernel MYKERNEL append MYOPTIONS
Les libellés sont tronqués comme s'il s'agissait de noms de fichiers et ils doivent être uniques après cette opération. Par exemple, les deux libellés « v2.6.30 » et « v2.6.31 » ne pourraient pas être différenciés sous PXELINUX car, une fois tronqués, ils portent tous deux le même nom de fichier DOS.
Le kernel ne doit pas nécessairement être un kernel Linux. Il peut également s'agir d'un secteur de démarrage ou d'un fichier COMBOOT.
LOCALBOOT TYPE
Sous PXELINUX, si vous remplacez une option
KERNEL
parLOCALBOOT 0
, vous appelez ce libellé précis, et entraînez le démarrage du disque local et non du kernel.Argument
Description
0
Effectue un démarrage normal.
4
Effectue un démarrage local avec le pilote UNDI (Universal Network Driver Interface - Interface de pilote réseau universelle) qui réside toujours en mémoire.
5
Effectue un démarrage local avec l'intégralité de la pile PXE, y compris le pilote UNDI, qui réside toujours en mémoire.
Aucune autre valeur n'est définie. Si vous ne savez pas à quoi correspondent les piles UNDI et PXE, indiquez
0
.TIMEOUT TIME-OUT
Indique la durée d'attente (en 1/10e de seconde) dans l'invite de démarrage, avant que le démarrage automatique soit lancé. Le timeout est annulé dès que l'utilisateur commence à saisir des données ; le système considère que l'utilisateur va terminer la commande initiée. Un timeout de zéro désactive entièrement le timeout (il s'agit également de la valeur par défaut). La valeur maximale de timeout est 35 996 (un peu moins d'une heure).
PROMPT val_drapeau
Si l'option
val_drapeau
a pour valeur 0, l'invite de démarrage apparaît uniquement si vous appuyez sur la touche Maj ou Alt, ou si Verr. maj ou Arrêt défil est défini (option par défaut). Sival_drapeau
a la valeur 1, cet argument affiche toujours l'invite de démarrage.F2 FILENAME F1 FILENAME ..etc.. F9 FILENAME F10 FILENAME
Affiche le fichier indiqué à l'écran lorsque vous appuyez sur une touche de fonction à l'invite de démarrage. Cette option peut être utilisée pour implémenter l'aide en ligne sur le pré-lancement (normalement pour les options de ligne de commande du kernel). Afin d'assurer une compatibilité avec les versions antérieures, vous pouvez également utiliser la touche F10 à la place de
F0
. Il n'y a actuellement aucun moyen de lier les noms de fichiers aux touches F11 et F12.
17.4 Préparation du système cible pour le démarrage PXE #
Préparez le BIOS du système pour le démarrage de l'environnement PXE en incluant l'option PXE dans l'ordre de démarrage du BIOS.
Ne placez pas l'option PXE avant le paramètre de démarrage du disque dur dans le BIOS. Le système essaierait sinon de se réinstaller chaque fois que vous le démarrez.
17.5 Utilisation de la fonction Wake-on-LAN pour les réveils à distance #
Wake-on-LAN (WOL) est une norme Ethernet permettant de réveiller à distance un ordinateur en lui envoyant un signal de réveil sur un réseau. Ce signal est appelé « paquet magique ». Installez WOL sur les machines clientes pour permettre les réveils à distance, ainsi que sur toutes les machines que vous souhaitez utiliser pour envoyer le signal de réveil. Le paquet magique est diffusé sur le port UDP 9 à l'adresse MAC de l'interface réseau sur la machine cliente.
Lorsque les ordinateurs sont arrêtés, ils ne sont généralement pas complètement éteints, mais restent en mode faible consommation. Lorsque l'interface réseau prend en charge WOL, elle écoute le signal de réveil par paquet magique lorsque la machine est éteinte. Vous pouvez envoyer le paquet magique manuellement ou planifier des réveils dans un travail cron sur la machine d'envoi.
17.5.1 Conditions préalables #
WOL fonctionne avec les cartes Ethernet filaires et sans fil qui le prennent en charge.
Vous devrez peut-être activer WOL dans le BIOS/UEFI de votre système.
Vérifiez vos paramètres BIOS/UEFI pour le démarrage PXE et assurez-vous qu'il est désactivé afin d'éviter les réinstallations accidentelles.
Ajustez votre pare-feu pour autoriser le trafic sur le port UDP 9.
17.5.2 Vérification de la prise en charge de l'Ethernet filaire #
Exécutez la commande suivante pour contrôler si une interface Ethernet filaire prend en charge WOL :
>
sudo
ethtool eth0 | grep -i wake-on Supports Wake-on: pumbg Wake-on: g
L'exemple de sortie montre que eth0 prend en charge WOL, indiqué par le drapeau g
sur la ligne Supports Wake-on
(Prend en charge Wake-on). Wake-on: g
indique que WOL est déjà activé, de sorte que cette interface est prête à recevoir des signaux de réveil. Si WOL n'est pas activé, activez-le avec cette commande:
>
sudo
ethtool -s eth0 wol g
17.5.3 Vérification de la prise en charge de l'interface sans fil #
Wakeup-over-Wi-Fi (WoWLAN), nécessite une interface réseau sans fil prenant en charge cette fonctionnalité. Pour vérifier si c'est le cas, effectuez un test avec la commande iw
, fournie par le paquetage iw :
>
sudo
zypper in iw
Recherchez le nom de votre périphérique :
>
sudo
iw dev phy#0 Interface wlan2 ifindex 3 wdev 0x1 addr 9c:ef:d5:fe:01:7c ssid accesspoint type managed channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz txpower 20.00 dBm
Dans cet exemple, le nom du périphérique à utiliser pour vérifier la prise en charge de WoWLAN est phy#0
. Cet exemple montre qu'il n'est pas pris en charge :
>
sudo
iw phy#0 wowlan show command failed: Operation not supported (-95)
Cet exemple montre une interface qui prend en charge WoWLAN, mais pour laquelle cette fonction n'est pas activée :
>
sudo
iw phy#0 wowlan show WoWLAN is disabled
Activez-la :
>
sudo
iw phy#0 wowlan enable magic-packet WoWLAN is enabled: * wake up on magic packet
17.5.4 Installation et test de WOL #
Pour utiliser WOL, installez le paquetage wol sur le client et les machines d'envoi :
>
sudo
zypper in wol
Installez le paquetage wol-udev-rules sur vos machines clientes. Ce paquetage installe une règle udev qui active automatiquement WOL au démarrage.
Obtenez l'adresse MAC de l'interface réseau sur la machine cliente :
>
sudo
ip addr show eth0|grep ether link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff
Dans l'exemple de sortie, 7c:ef:a5:fe:06:7c
est l'adresse MAC.
Arrêtez votre machine cliente et envoyez-lui un signal de réveil à partir d'un autre ordinateur du même sous-réseau :
>
wol 7c:ef:a5:fe:06:7c
Si votre machine cible et votre deuxième périphérique se trouvent sur le même réseau mais dans des sous-réseaux différents, spécifiez l'adresse de diffusion de votre machine cible :
>
wol -i 192.168.0.63 7c:ef:a5:fe:06:7c
Étant donné que WOL repose sur des domaines de diffusion, la machine d'envoi doit se trouver sur le même réseau, même si elle peut se trouver dans un segment de réseau différent.
Il est possible d'envoyer le paquet magique à partir d'un autre réseau. Une méthode consiste à utiliser le transfert de port, si votre routeur prend en charge le transfert de port vers une adresse de diffusion. Une méthode plus sécurisée consiste à se connecter à un hôte à l'intérieur de votre réseau via SSH et à envoyer le paquet magique à partir de là.