17 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 (DHCP 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 :

Les champs xx:xx:xx:xx de l'horodatage DUID-LLT (DUID-Link-Layer Timestamp) correspondent à 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.

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 :

tux > 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-SP2-x86_64, et ARCHITECTURE par l'architecture de votre système, par exemple x86_64. Le texte obtenu ressemble à ceci : tftpboot-installation-SLE-15-SP2-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.

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-SP2-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 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.

Il est inutile de modifier les fichiers de configuration GRUB2. Toutefois, les paramètres par défaut ne comportent pas de source réseau pour le système d'installation. Si vous souhaitez installer entièrement SUSE Linux Enterprise Server via le réseau, ajoutez le paramètre install aux lignes linuxefi dans le fichier /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg. Définissez le paramètre install en fonction de votre configuration, comme décrit dans le Chapitre 16, Configuration d'une source d'installation réseau. Pour plus d'informations sur les autres paramètres de démarrage qui sont utilisés dans les lignes efilinux, reportez-vous à la Section 7.3, « Liste des paramètres de démarrage importants ».