18 Préparation de l'environnement de démarrage réseau #

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.

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.

À 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 :

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 AutoYaST Guide (Guide d'AutoYaST). Consultez également man 4 initrd et la documentation pour les options dhcp4 "create-cid", dhcp6 "default-duid" dans man 5 wicked-config, wicked duid --help et wicked iaid --help.

Pour installer un serveur TFTP, procédez comme suit :

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 :

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 par la 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-OS_VERSION-ARCHITECTURE. Vous pouvez également copier les fichiers des autres versions et architectures de SUSE Linux Enterprise Server dans le répertoire /srv/tftpboot.

Astuce : diversité des architectures desservies

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.

Note : répertoire /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.

Ouvrez le fichier /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default dans un éditeur. Remplacez le chemin d'accès du paramètre install selon votre configuration, comme décrit dans le Chapitre 17, 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 18.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 8.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.

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 8.3.3, « Spécification de la source d'installation » pour plus d'informations sur le paramètre install.

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é pour éviter les réinstallations accidentelles.

Ajustez votre pare-feu pour autoriser le trafic sur le port UDP 9.

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

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

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 depuis un autre ordinateur sur le 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à.