Configuration d'un serveur de démarrage PXE sous SLES for SAP 16.0
- CONTENU
Configurez un serveur de démarrage PXE prenant en charge UEFI Secure Boot et le programme d'installation Agama.
- MOTIF
Automatisez et rationalisez l'installation de plusieurs systèmes SUSE Linux Enterprise Server for SAP Applications 16.0 sur le réseau.
- EFFORT
Pour un administrateur de système ou de réseau, la lecture et la compréhension de cet article prennent généralement 30 à 45 minutes.
- OBJECTIF
Disposer d'un serveur PXE fonctionnel qui peut démarrer plusieurs architectures dans le programme d'installation Agama.
- CONDITIONS REQUISES
Un système SUSE Linux Enterprise Server for SAP Applications 16.0 doté de privilèges administratifs
Une connexion Internet pour récupérer les images ISO
Une configuration IP statique pour le serveur PXE
1 Présentation du démarrage PXE avec SUSE Linux Enterprise Server for SAP Applications 16.0 #
Le démarrage PXE permet aux machines de se lancer sur le réseau dans un environnement d'installation ou d'exécution sans stockage local. Cette section explique le fonctionnement de PXE dans le programme d'installation Agama de SUSE Linux Enterprise Server for SAP Applications 16.0 et les images dynamiques de ce programme d'installation, en mettant l'accent sur GRUB 2.
1.1 Qu'est-ce que le démarrage PXE ? #
PXE (Preboot Execution Environment) est une méthode qui permet aux systèmes de récupérer les chargeurs de démarrage et les programmes d'installation de système d'exploitation à partir d'un serveur réseau en utilisant DHCP et TFTP ou HTTP. Elle est largement utilisée pour provisionner des machines sans support physique ni système d'exploitation préinstallé.
1.2 Avantages du démarrage PXE #
Le démarrage PXE simplifie l'approvisionnement en supprimant la nécessité d'un support d'installation local ou d'une configuration manuelle. Il offre les avantages suivants :
Installation sans surveillance de nombreux systèmes sur le réseau
Gestion centralisée des versions du programme d'installation et des configurations de démarrage
Prise en charge de divers types d'architectures et de microprogrammes, y compris UEFI Secure Boot
Sélection dynamique des programmes d'installation ou des paramètres d'installation à l'aide des menus GRUB 2
1.3 Procédure de démarrage PXE sous SUSE Linux Enterprise Server for SAP Applications 16.0 #
Le démarrage PXE dans SUSE Linux Enterprise Server for SAP Applications 16.0 utilise GRUB 2 comme chargeur de démarrage et le programme d'installation Agama comme interface d'installation. Les chargeurs de démarrage et les fichiers du programme d'installation sont fournis sur le réseau à l'aide de HTTP ou TFTP, GRUB 2 récupérant le kernel Linux, l'unité RAM initiale (initrd) et l'image dynamique. Les clients PXE peuvent utiliser une variété de microprogrammes (notamment les plus courants tels que BIOS ou UEFI), d'exécutables de chargeur de démarrage ou de formats d'image, en fonction de leur architecture, par exemple AMD64/Intel 64, AArch64, ppc64le et s390x. En outre, ils doivent fonctionner à la fois sur les réseaux IPv4 et IPv6.
Le chargeur de démarrage transmet les paramètres du kernel Linux, tels que root=live:, pour charger le système de fichiers racine basé sur squashfs à partir d'une image ISO dynamique, en démarrant l'interface Agama soit localement, soit en tant que service Web pour une interface utilisateur Web distante.
1.3.1 Compatibilité avec les versions précédentes SLES for SAP 15.x #
Les informations contenues dans cet article s'appliquent principalement à SUSE Linux Enterprise Server for SAP Applications 16.0 et versions ultérieures. Il se concentre sur les flux de travail de démarrage PXE qui s'intègrent au programme d'installation Agama et s'appuient sur des images d'installation dynamiques. Dans le contexte et la portée de cet article, SLES for SAP 16.0 et les versions ultérieures diffèrent de SLES for SAP 15.x comme suit :
- Programme d'installation
Utilise
dracutet Agama au lieu delinuxrcet YaST.- Serveur DHCP
L'utilisation de DHCP ISC est abandonnée (fin de service 2022). Pour un serveur DHCP, utilisez plutôt Kea ou dnsmasq.
- Paramètres de démarrage
Utilise le paramètre
root=live:pour charger l'image du programme d'installation Agama et le paramètre facultatifinst.install_url=pour le dépôt d'installation non par défaut, au lieu du paramètreinstall=.
Le choix du chargeur de démarrage (GRUB 2, pxelinux, etc.) reste flexible et ne dépend pas de la version.
1.3.2 Différentes configurations et étapes possibles #
Cet article présente les étapes de configuration obligatoires et les configurations facultatives ou alternatives. Ne suivez que les sections pertinentes pour votre déploiement et ignorez les alternatives qui ne s'appliquent pas à votre déploiement.
- Obligatoire
Les tâches telles que l'installation des composants, la préparation de l'image du programme d'installation, la configuration de GRUB 2 et la validation du serveur doivent être effectuées dans toutes les configurations.
- Méthode de distribution des fichiers
Un serveur HTTP (recommandé avec Agama) comme
nginxet/ou un serveur TFTP commetftpoudnsmasq.- Serveur DHCP
Choisissez Kea ou dnsmasq.
Note : limites et caractéristiques de la méthode choisieUtilisez Kea, le nouveau serveur DHCP d'ISC, comme remplacement moderne de DHCP ISC. Pour plus d'informations sur Kea, reportez-vous au document https://www.isc.org/kea/. Pour l'avis de fin de service de DHCP ISC, reportez-vous au document https://www.isc.org/dhcp/. Kea est un serveur DHCP et nécessite un logiciel de serveur TFTP séparé. Le serveur DHCP Kea prend en charge les options de démarrage TFTP/PXE via IPv4 et IPv6 ainsi que le démarrage HTTP via IPv4. Le démarrage HTTP via IPv6 nécessite que le serveur DHCPv6 puisse renvoyer au client la valeur
Vendor Class Option(voirRFC3315, Section 22.16), censée être utilisée « par un client pour identifier le fournisseur, » et n'est actuellement pas pris en charge.dnsmasq en tant que combinaison d'un serveur DNS, d'un serveur DHCP et d'un serveur TFTP. Vous pouvez l'utiliser pour servir le chargeur de démarrage, le kernel Linux, l'unité RAM initiale (et d'autres fichiers) via TFTP. Pour plus d'informations sur dnsmasq, reportez-vous au document https://thekelleys.org.uk/dnsmasq/doc.html. Le serveur DHCP dnsmasq prend en charge les options de démarrage TFTP/PXE via IPv4 et IPv6 ainsi que le démarrage HTTP via IPv4. Le démarrage HTTP via IPv6 nécessite que le serveur DHCPv6 puisse renvoyer au client la valeur
Vendor Class Option(voirRFC3315, Section 22.16), censée être utilisée « par un client pour identifier le fournisseur, » et n'est actuellement pas pris en charge.
2 Préparation du réseau pour les services de démarrage PXE #
Ce module décrit les exigences en matière d'infrastructure réseau pour le déploiement des services de démarrage PXE sous SUSE Linux Enterprise Server for SAP Applications 16.0.
2.1 Introduction #
Un serveur PXE comprend trois serveurs : un serveur DHCP qui fournit l'adresse et l'emplacement du fichier de démarrage (chargeur de démarrage) et un serveur TFTP et/ou HTTP pour récupérer les fichiers. En outre, il peut y avoir un serveur DNS, un serveur NTP et un routeur prenant en charge IPv6 ; ceux-ci sont généralement séparés du serveur PXE dans un réseau de production. Un serveur PXE exécutant SUSE Linux Enterprise Server for SAP Applications 16.0 peut également nécessiter une configuration spécifique de l'interface réseau, l'ajout de certaines règles persistantes au pare-feu et certaines autorisations dans SELinux. Cette section présente un exemple de réseau avec des plages d'adresses IP appropriées et les règles nécessaires pour le pare-feu et SELinux.
2.2 Hypothèses et exemple de configuration du réseau #
Dans cet article, nous partons des hypothèses suivantes :
Le serveur PXE est en cours d'exécution sur l'interface réseau
eno1avec la configuration réseau suivante :Tableau 1 : Exemple de configuration de réseau PXE #IPv4 IPv6 Nom DNS Réseau PXE 192.168.1.0/24 2001:db8:0:1::/64 example.net Serveur PXE 192.168.1.200 2001:db8:0:1::200 pxe.example.net Passerelle PXE 192.168.1.1 2001:db8:0:1::1 Serveur DNS 192.168.1.200 2001:db8:0:1::200 Serveur NTP 192.168.1.1 2001:db8:0:1::1 Par défaut, les serveurs routeur, NTP et DNS sont externes et s'exécutent sur une autre machine. Cet article fournit quelques conseils, mais ne couvre pas leur configuration complète.
2.3 Configuration de l'interface réseau, du pare-feu et de SELinux pour les services PXE #
Configurez l'interface réseau et le pare-feu pour autoriser les services réseau requis par le serveur PXE. Ajustez les paramètres SELinux pour permettre les tests d'installation et définir des stratégies locales persistantes.
Vérifiez l'interface réseau PXE et assignez-la à la zone firewalld appropriée.
Vérifiez les zones actuellement actives et les interfaces qui leur sont assignées :
>sudofirewall-cmd --get-active-zonesSi
eno1n'est pas assigné à la zonepublic, faites-le :>sudofirewall-cmd --zone=public --change-interface=eno1Faites en sorte que l'assignation de l'interface persiste après les redémarrages :
>sudofirewall-cmd --permanent --zone=public --add-interface=eno1
Configurez le pare-feu pour l'accès au service DNS.
Autorisez le service DNS pour la session en cours :
>sudofirewall-cmd --zone=public --add-service=dnsRendez la modification permanente :
>sudofirewall-cmd --permanent --zone=public --add-service=dns
Configurez le pare-feu pour l'accès au service NTP.
Autorisez le service NTP pour la session en cours :
>sudofirewall-cmd --zone=public --add-service=ntpRendez la modification permanente :
>sudofirewall-cmd --permanent --zone=public --add-service=ntp
Configurez le pare-feu pour l'accès au service DHCP (IPv4).
Autorisez le service DHCP pour la session en cours :
>sudofirewall-cmd --zone=public --add-service=dhcpRendez la modification permanente :
>sudofirewall-cmd --permanent --zone=public --add-service=dhcp
Configurez le pare-feu pour l'accès au service DHCPv6.
Autorisez le service DHCPv6 pour la session en cours :
>sudofirewall-cmd --zone=public --add-service=dhcpv6Rendez la modification permanente :
>sudofirewall-cmd --permanent --zone=public --add-service=dhcpv6
Configurez le pare-feu pour l'accès au service TFTP.
Autorisez le service TFTP pour la session en cours :
>sudofirewall-cmd --zone=public --add-service=tftpRendez la modification permanente :
>sudofirewall-cmd --permanent --zone=public --add-service=tftp
Configurez le pare-feu pour l'accès au service HTTP.
Autorisez le service HTTP pour la session en cours :
>sudofirewall-cmd --zone=public --add-service=httpRendez la modification permanente :
>sudofirewall-cmd --permanent --zone=public --add-service=http
Configurez le pare-feu pour l'accès au service HTTPS.
Autorisez le service HTTPS pour la session en cours :
>sudofirewall-cmd --zone=public --add-service=httpsRendez la modification permanente :
>sudofirewall-cmd --permanent --zone=public --add-service=https
Désactivez temporairement
SELinuxpour les tests de configuration.Définissez
SELinuxsur le mode permissif :>sudosetenforce 0Vérifiez le statut de
SELinux:>sudosestatus
Générez et installez des modules de stratégie
SELinuxlocaux pour les services liés à PXE.Créez et installez un module pour
nginx:>sudoif test `ausearch -c 'nginx' --raw | wc -l` -gt 0 ; then>sudoausearch -c 'nginx' --raw | audit2allow -a -M local-nginx>sudosemodule -i local-nginx.pp>sudofiCréez et installez un module pour
dnsmasq:>sudoif test `ausearch -c 'dnsmasq' --raw | wc -l` -gt 0 ; then>sudoausearch -c 'dnsmasq' --raw | audit2allow -a -M local-dnsmasq>sudosemodule -i local-dnsmasq.pp>sudofiCréez et installez un module pour
in.tftpd:>sudoif test `ausearch -c 'in.tftpd' --raw | wc -l` -gt 0 ; then>sudoausearch -c 'in.tftpd' --raw | audit2allow -a -M local-tftpd>sudosemodule -i local-tftpd.pp>sudofi
Réactivez le mode d'application de
SELinux.Réglez
SELinuxsur le mode d'application :>sudosetenforce 1Vérifiez le statut de
SELinux:>sudosestatus
2.4 Résumé #
Cette procédure a permis de s'assurer que l'interface réseau du serveur PXE, le pare-feu et la stratégie SELinux étaient correctement configurés pour un fonctionnement sûr et opérationnel.
L'interface de service PXE (
eno1dans cet exemple) a été vérifiée et assignée à la zone firewalldpublic.Les services de pare-feu requis pour le fonctionnement de PXE, notamment
dns,ntp,dhcp,dhcpv6,tftp,http, ethttps, ont été ouverts.SELinuxa été temporairement mis en modepermissiveafin de faciliter les tests de service et d'enregistrer les refus AVC.Les commandes
ausearchetaudit2allowont été utilisées pour générer et installer des modules de stratégie SELinux personnalisés pour des services tels quenginx,dnsmasqetin.tftpd.SELinuxa été restauré en modeenforcingpour sécuriser le système en vue de son utilisation en production.
Une fois ces étapes terminées, le serveur PXE est configuré de manière sécurisée et prêt à servir des machines clientes sur le réseau en utilisant IPv4 ou IPv6.
3 Installation des composants requis pour le serveur PXE #
Cette section explique comment installer les paquets nécessaires à la prise en charge du démarrage PXE sous SUSE Linux Enterprise Server for SAP Applications 16.0, y compris les composants GRUB 2, DHCP, TFTP et/ou HTTP.
3.1 Introduction #
Pour configurer un serveur de démarrage PXE sous SUSE Linux Enterprise Server for SAP Applications 16.0, vous devez installer plusieurs services et outils. En fonction de votre configuration, vous pouvez avoir besoin des éléments suivants :
Le paquet dnsmasq fournit une combinaison d'un serveur DNS, d'un serveur TFTP et d'un serveur DHCP (DHCPv4 et DHCPv6) avec une prise en charge limitée des annonces de routeur (RA) IPv6. Il fournit les éléments suivants :
Serveur DHCP dnsmasq : prend en charge la distribution conditionnelle d'options DHCP en fonction de la demande et de l'architecture du client pour :
les demandes de démarrage PXE à l'aide de DHCPv4 et DHCPv6 ;
les demandes de démarrage HTTP à l'aide de DHCPv4.
Note : limites de dnsmasq pour le démarrage HTTP via DHCPv6À l'heure actuelle, dnsmasq ne prend pas en charge l'envoi de l'option DHCPv6
vendor-classrequise.
Serveur TFTP dnsmasq : fournit les fichiers du chargeur de démarrage, le kernel Linux et l'unité RAM initiale via TFTP pendant le démarrage PXE.
Serveur DNS dnsmasq : fournit une résolution récursive des noms de domaine et des adresses IP pour les micrologiciels clients et
/etc/resolv.confdans le programme d'installation/système d'exploitation.Annonces de routeur IPv6 dnsmasq : prennent en charge l'envoi d'annonces de routeur (RA) IPv6 lorsque le serveur PXE fait également office de routeur (configurabilité limitée à un « modèle RA commun »).
Le paquet kea est un serveur DHCP et un successeur au serveur DHCP ISC. Il prend en charge la distribution conditionnelle d'options DHCP en fonction de la demande et de l'architecture du client pour :
les demandes de démarrage PXE à l'aide de DHCPv4 et DHCPv6 ;
les demandes de démarrage HTTP à l'aide de DHCPv4.
Note : limites de Kea pour le démarrage HTTP via DHCPv6À l'heure actuelle, Kea ne prend pas en charge l'envoi de l'option DHCPv6
vendor-classrequise. Pour plus d'informations, reportez-vous au document https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#id4.
Un serveur TFTP distribue les fichiers du chargeur de démarrage, le kernel Linux et l'unité RAM initiale via TFTP, tandis que le démarrage PXE avec Kea est fourni par le paquet tftp et n'est pas nécessaire pour le démarrage HTTP. Si vous utilisez dnsmasq, vous n'avez pas besoin du paquet tftp.
Un serveur Web tel que le paquet nginx fournit les images du programme d'installation via HTTP.
Note : nécessité des serveurs HTTPUn serveur HTTP/HTTPS comme nginx est presque toujours requis. Son utilisation s'étend au-delà du démarrage HTTP. En particulier, vous pouvez en avoir besoin dans les cas suivants :
Il s'agit d'une exigence de base pour le démarrage HTTP.
Il est recommandé pour la fourniture de
squashfs.img. Vous pouvez utiliserroot=live:tftp://.../squashfs.imgdans la ligne de commande de démarrage.Il est également recommandé pour la fourniture de RPM à Agama dans le paramètre de ligne de commande de démarrage
inst.install_url=http://.../install/sur un fichierSLES-16.0-Full-*.inline.iso, ainsi qu'avec des profils d'installation et d'autres fichiers pour une installation sans surveillance.
Les paquets du chargeur d'amorçage GRUB 2 permettent le démarrage du réseau pour les architectures et les méthodes prises en charge. Par exemple, l'architecture AMD64/Intel 64 propose deux méthodes de démarrage du réseau : BIOS et UEFI. En outre, UEFI prend généralement en charge le démarrage PXE (TFTP) et HTTP. D'autres chargeurs de démarrage, tels que pxelinux, ne prennent pas en charge UEFI et le démarrage HTTP.
Un daemon d'annonce de routeur pour IPv6, tel que le paquet radvd, peut éventuellement être fourni. Il est nécessaire sous SLES for SAP s'il sert également de routeur pour un réseau de programme d'installation afin d'effectuer les tâches suivantes :
Configurer le routage sur un réseau pour les clients de démarrage PXE ou HTTP.
Activer l'utilisation de DHCPv6 sur un réseau pour les clients de démarrage PXE ou HTTP.
3.2 Configuration requise #
Un système exécutant SUSE Linux Enterprise Server for SAP Applications 16.0 avec des privilèges administratifs, enregistré auprès du SUSE Customer Center et configuré avec un accès aux dépôts en ligne appropriés à l'aide de SUSEConnect.
Des modules SLE activés : module Server Applications, module Legacy et module Base System.
Un accès aux dépôts de modules SLE pour les services de réseau et les chargeurs de démarrage.
Une connexion Internet opérationnelle pour récupérer les paquets.
3.3 Installation des paquets #
Procédez comme suit pour installer les paquets de base nécessaires au serveur de démarrage PXE.
Installez le chargeur de démarrage GRUB 2 et le serveur HTTP nginx en tant qu'exigences communes.
>sudozypper install grub2 nginxExécutez l'une des commandes suivantes pour installer les paquets essentiels à votre approche :
kea pour le serveur DHCP, tftp pour le serveur TFTP
>sudozypper install kea tftpdnsmasq en tant que fournisseur commun pour les serveurs DHCP, DNS et TFTP
>sudozypper install dnsmasq
Note : limites des serveurs DHCP fournis par Kea et dnsmasqLe démarrage HTTP via IPv6 n'est actuellement pas pris en charge par les serveurs DHCP fournis par les paquets kea et dnsmasq. Il ne permet pas de renvoyer l'option
vendor-classau client HTTP, comme l'exige la spécification UEFI.Vous pouvez éventuellement installer des cibles GRUB 2 supplémentaires spécifiques à l'architecture si vous prévoyez de prendre en charge d'autres plates-formes.
Pour l'architecture AMD64/Intel 64 :
>sudozypper install grub2-x86_64-efi grub2-i386-pcPour l'architecture AArch64 :
>sudozypper install grub2-aarch64-efiPour l'architecture ppc64le :
>sudozypper install grub2-ppc64le-ieee1275
Note : mode de fourniture de paquets GRUB 2 par le serveur PXE à des clients dont l'architecture est différente de celle de la machine serveurLes paquets noarch.rpm spécifiques à l'architecture de GRUB 2 sont inclus dans le sous-répertoire
noarchdu média/dépôt d'installation, quelle que soit l'architecture de la machine sur laquelle le serveur PXE est configuré. En d'autres termes, vous pouvez installer les paquets grub2-arm64-efi et grub2-powerpc-ieee1275 sur un serveur PXE s'exécutant sur une machine AMD64/Intel 64, afin de prendre en charge les clients dotés d'autres architectures.Vous pouvez éventuellement installer le paquet shim si vous avez besoin du mode UEFI Secure Boot pour AMD64/Intel 64 ou AArch64, mais que vous ne souhaitez pas utiliser les fichiers de l'image ISO du support d'installation.
>sudozypper install shimVous pouvez éventuellement installer le daemon d'annonce de routeur radvd si vous souhaitez utiliser le serveur PXE comme routeur (non recommandé pour les réseaux de production).
>sudozypper install radvdInstallez l'utilitaire rsync pour copier ou synchroniser facilement l'image ISO et l'arborescence Annuaire.
>sudozypper install rsyncAssurez-vous que les services sont installés, mais qu'ils n'ont pas encore démarré. La configuration sera abordée dans des sections ultérieures.
4 Création des répertoires NetBoot de GRUB 2 pour le serveur PXE #
Cette section décrit comment créer des répertoires NetBoot de GRUB 2 pour les serveurs PXE à l'aide de grub2-mknetdir, qui génère des répertoires spécifiques à l'architecture pour les systèmes AMD64/Intel 64 (UEFI et BIOS), AArch64 et ppc64le. Pour la prise en charge du mode UEFI Secure Boot, les administrateurs doivent copier les fichiers EFI signés à partir du support d'installation ou utiliser le paquet shim pour remplacer les fichiers par défaut non signés du chargeur de démarrage.
4.1 Introduction #
Cette section décrit comment configurer les répertoires NetBoot de GRUB 2 pour le déploiement d'un serveur PXE sur plusieurs architectures. La commande grub2-mknetdir crée des répertoires spécifiques à l'architecture sous /srv/tftpboot/boot/grub2/ pour différentes plateformes. Par exemple, les systèmes AMD64/Intel 64 génèrent à la fois des répertoires UEFI (x86_64-efi) et du BIOS hérité (i386-pc), tandis que les systèmes AArch64 et ppc64le créent leurs répertoires UEFI respectifs (arm64-efi et powerpc-ieee1275).
Pour la prise en charge du mode UEFI Secure Boot, qui n'est pas assurée par les fichiers core.efi par défaut non signés, les administrateurs peuvent soit copier des fichiers EFI signés à partir du support d'installation, soit installer le paquet shim et copier manuellement les fichiers de chargeur de démarrage requis (shim.efi, grub.efi, MokManager.efi) dans les répertoires d'architecture appropriés, en veillant à une résolution correcte des liens symboliques afin de conserver tous les fichiers dans le répertoire racine TFTP.
4.2 Configuration requise #
Assurez-vous d'avoir installé les paquets suivants : grub2, tftp et tout autre paquet GRUB 2 spécifique à l'architecture, tel que grub2-x86_64-efi et grub2-i386-pc.
Assurez-vous que le support d'installation (ISO) est disponible pour le montage ou que le paquet shim est installé sur le système. Vous pouvez télécharger le support d'installation (ISO) pour votre architecture cible à partir du SUSE Customer Center.
4.3 Préparation des répertoires NetBoot et du mode UEFI Secure Boot #
Cette procédure crée la structure de répertoire GRUB 2 requise pour le démarrage réseau PXE et configure éventuellement la prise en charge du mode UEFI Secure Boot sur plusieurs architectures.
Créez une structure de répertoire NetBoot de GRUB 2.
>sudogrub2-mknetdir --net-directory=/srv/tftpboot --subdir=/boot/grub2Cela crée des répertoires spécifiques à l'architecture :
AMD64/Intel 64 :
/srv/tftpboot/boot/grub2/x86_64-efiet/srv/tftpboot/boot/grub2/i386-pcAArch64 :
/srv/tftpboot/boot/grub2/arm64-efippc64le :
/srv/tftpboot/boot/grub2/powerpc-ieee1275
AvertissementN'écrasez pas manuellement le fichier
grub.cfgcréé pargrub2-mknetdir.Copiez sur le serveur TFTP les autres répertoires indépendants de l'architecture, tels que
fonts/etlocale/, qui sont disponibles sous le répertoire/srv/tftpboot/boot/grub2/.Vous pouvez également utiliser le fichier
/srv/tftpboot/boot/grub2/ARCH-efi/core.efiinstallé par la commandegrub2-mknetdirpour les architectures AMD64/Intel 64 ou AArch64 pour UEFI PXE. Cependant, ils ne sont pas signés et ne prennent pas en charge UEFI Secure Boot. Pour activer éventuellement UEFI Secure Boot pour les architectures AMD64/Intel 64 et AArch64 prises en charge, effectuez l'une des étapes suivantes :Copiez les fichiers nécessaires à partir de l'image ISO du support d'installation :
Montez l'image ISO.
>sudomount -o loop /PATH/TO/SLES.ISO /mntCopiez les fichiers EFI.
>sudocp -v /mnt/EFI/BOOT/*.efi /srv/tftpboot/boot/grub2/ARCH-efi/1Remplacez
ARCH-efiparx86_64-efiouarm64-efi, les architectures prises en charge pour UEFI Secure Boot.Testez l'image ISO du support d'installation.
>sudoumount /mnt
Utilisez le paquet shim si vous ne souhaitez pas utiliser les fichiers de l'image ISO du support d'installation :
Si ce n'est déjà fait, installez le paquet shim.
>sudozypper install shimCopiez les fichiers signés du chargeur de démarrage pour l'architecture requise :
Copiez le fichier
shim.efi.Pour l'architecture AMD64/Intel 64 :
>sudocp -v -p -L /usr/share/efi/x86_64/shim.efi /srv/tftpboot/boot/grub2/x86_64-efi/bootx64.efiPour l'architecture AArch64 :
>sudocp -v -p -L /usr/share/efi/aarch64/shim.efi /srv/tftpboot/boot/grub2/arm64-efi/bootaa64.efi
Copiez le fichier
grub.efi.Pour l'architecture AMD64/Intel 64 :
>sudocp -v -p -L /usr/share/efi/x86_64/grub.efi /srv/tftpboot/boot/grub2/x86_64-efi/Pour l'architecture AArch64 :
>sudocp -v -p -L /usr/share/efi/aarch64/grub.efi /srv/tftpboot/boot/grub2/arm64-efi/
Copiez le fichier
MokManager.efi.Pour l'architecture AMD64/Intel 64 :
>sudocp -v -p -L /usr/share/efi/x86_64/MokManager.efi /srv/tftpboot/boot/grub2/x86_64-efi/Pour l'architecture AArch64 :
>sudocp -v -p -L /usr/share/efi/aarch64/MokManager.efi /srv/tftpboot/boot/grub2/arm64-efi/
NoteL'indicateur
-Lrésout les liens symboliques pour s'assurer que les fichiers restent à la racine TFTP.
5 Préparation du contenu de l'image du programme d'installation #
Cette section décrit comment extraire les fichiers du programme d'installation à partir du support d'installation de SUSE Linux Enterprise Server for SAP Applications 16.0 et comment les organiser pour les environnements de démarrage PXE. Il couvre à la fois les images .install.iso et les paquets RPM, avec des instructions spécifiques pour différents types d'installation et architectures.
5.1 Introduction #
SUSE Linux Enterprise Server for SAP Applications 16.0 fournit des fichiers de programme d'installation dans plusieurs formats afin de prendre en charge différents scénarios de démarrage PXE. Le programme d'installation Agama nécessite trois fichiers essentiels : l'image du kernel Linux (linux), l'unité RAM initiale (initrd) et le système de fichiers racine compressé (squashfs.img). Ces fichiers doivent être extraits à partir du support d'installation et organisés dans une structure de répertoires accessible via TFTP et HTTP.
Cette section couvre les méthodes de préparation à la fois des images .install.iso et des paquets RPM, afin d'assurer la compatibilité avec les différents types d'installation et architectures pris en charge par SUSE Linux Enterprise Server for SAP Applications 16.0.
5.2 Configuration requise #
Support d'installation de SUSE Linux Enterprise Server for SAP Applications 16.0 tel que disponible dans le SUSE Customer Center. Choix possibles :
Image ISO en ligne : programme d'installation uniquement pour les installations réseau (
SLES-16.0-Online-ARCH-BUILD.install.iso)Image ISO complète : programme d'installation avec dépôt d'installation (
SLES-16.0-Full-ARCH-BUILD.install.iso)Paquets RPM : tftpboot-agama-installer-SUSE_SLE_16_PXE-ARCH
Un point de montage temporaire, tel que
/mnt.Espace disque suffisant sous
/srv/tftpbootet/srv/installpour la méthode d'installation choisie.Privilèges administratifs permettant de créer des répertoires et de copier des fichiers.
5.3 Préparation des fichiers du programme d'installation à partir d'images ISO #
Les images ISO constituent une méthode simple pour extraire les fichiers du programme d'installation. Les procédures suivantes couvrent à la fois les types Image ISO en ligne et Image ISO complète pour différentes architectures.
5.3.1 Utilisation d'images ISO en ligne #
Les images ISO en ligne ne contiennent que les composants du programme d'installation, ce qui nécessite un accès réseau aux dépôts d'installation lors de l'installation du système. Cela correspond à l'entrée du menu de démarrage SLES-16.0 Online Installation dans GRUB.
Créez la structure de répertoires pour les fichiers du programme d'installation :
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ARCH/Montez l'images ISO en ligne :
>sudomount -oro,loop /srv/install/iso/SLES-16.0-Online-ARCH-BUILD.install.iso /mntCopiez les fichiers du kernel Linux et initrd :
>sudocp /mnt/boot/ARCH/loader/linux /srv/tftpboot/boot/images/SLES-16.0/ARCH/>sudocp /mnt/boot/ARCH/loader/initrd /srv/tftpboot/boot/images/SLES-16.0/ARCH/Copiez le système de fichiers racine compressé :
>sudocp /mnt/LiveOS/squashfs.img /srv/tftpboot/boot/images/SLES-16.0/ARCH/Montez l'image ISO :
>sudoumount /mnt
Créez la structure de répertoire :
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ppc64le/Montez l'image ISO :
>sudomount -oro,loop /srv/install/iso/SLES-16.0-Online-ppc64le-BUILD.install.iso /mntCopiez les fichiers du kernel Linux et initrd (notez la structure de chemin différente pour ppc64le) :
>sudocp /mnt/boot/ppc64le/linux /srv/tftpboot/boot/images/SLES-16.0/ppc64le/>sudocp /mnt/boot/ppc64le/initrd /srv/tftpboot/boot/images/SLES-16.0/ppc64le/Copiez le système de fichiers racine compressé :
>sudocp /mnt/LiveOS/squashfs.img /srv/tftpboot/boot/images/SLES-16.0/ppc64le/Montez l'image ISO :
>sudoumount /mnt
5.3.2 Utilisation d'images ISO complètes #
Les images ISO complètes comprennent à la fois le programme d'installation et les dépôts d'installation, ce qui permet des installations locales sans dépendances réseau externes. Cela correspond à l'entrée du menu de démarrage SLES-16.0 Local Installation dans GRUB avec le paramètre supplémentaire inst.install_url=http://pxe.example.net/install/SLES-16.0/${arch}.
Créez des répertoires à la fois pour les fichiers du programme d'installation et pour le dépôt d'installation :
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ARCH/>sudomkdir -p /srv/install/SLES-16.0Montez l'image ISO complète :
>sudomount -oro,loop /srv/install/iso/SLES-16.0-Full-ARCH-BUILD.install.iso /mntCopiez les fichiers du kernel Linux et initrd (ajustez les chemins pour ppc64le comme indiqué dans les procédures précédentes) :
>sudocp /mnt/boot/ARCH/loader/linux /srv/tftpboot/boot/images/SLES-16.0/ARCH/>sudocp /mnt/boot/ARCH/loader/initrd /srv/tftpboot/boot/images/SLES-16.0/ARCH/Copiez le système de fichiers racine compressé :
>sudocp /mnt/LiveOS/squashfs.img /srv/tftpboot/boot/images/SLES-16.0/ARCH/Copier le dépôt d'installation pour l'accès au serveur HTTP local :
>sudorsync -avP /mnt/install/ /srv/install/SLES-16.0/ARCH/Montez l'image ISO :
>sudoumount /mnt
5.4 Préparation des fichiers du programme d'installation à partir de paquets RPM #
Les paquets RPM constituent une méthode alternative pour obtenir les fichiers du programme d'installation en ligne.
Installez les paquets requis :
>sudozypper in tftpboot-agama-installer-SUSE_SLE_16-ARCHCopiez les fichiers linux, initrd et squashfs.img dans tftpboot :
>sudomkdir -p /srv/tftpboot/boot/images/SLES-16.0/ARCH>sudocd /srv/tftpboot/boot/images/SLES-16.0/ARCH>sudocp -v /usr/share/tftpboot-installation/agama-installer-SUSE_SLE_16/ARCH/loader/linux .>sudocp -v /usr/share/tftpboot-installation/agama-installer-SUSE_SLE_16/ARCH/loader/initrd .>sudocp -v /usr/share/tftpboot-installation/agama-installer-SUSE_SLE_16/ARCH/loader/squashfs.img .
5.5 Structure de répertoires recommandée #
Organisez les fichiers extraits selon la disposition de répertoires suivante afin de garantir la cohérence et la facilité de maintenance. Cette structure prend en charge plusieurs types d'installation et architectures.
/srv/tftpboot/ ├── boot/ │ ├── grub2/ │ │ ├── x86_64-efi/ │ │ │ ├── bootx64.efi │ │ │ └── grub.cfg │ │ ├── i386-pc/ │ │ │ └── core.0 │ │ ├── arm64-efi/ │ │ │ └── bootaa64.efi │ │ └── powerpc-ieee1275/ │ │ └── core.elf │ └── images/ │ └── SLES-16.0/ │ ├── x86_64/ │ │ ├── linux 1 │ │ ├── initrd 2 │ │ └── squashfs.img 3 │ ├── aarch64/ │ └── ppc64le/ /srv/install/ └── SLES-16.0/ ├── x86_64/ 4 ├── aarch64/ └── ppc64le/
5.6 Vérification de l'installation #
Après avoir extrait et organisé les fichiers du programme d'installation, vérifiez que tous les composants requis sont présents et accessibles.
Vérifiez que les fichiers essentiels sont présents :
>ls -la /srv/tftpboot/boot/images/SLES-16.0/ARCH/*Veillez à ce que les autorisations d'accès aux fichiers soient correctes :
>sudofind /srv/tftpboot/boot/images/ -type d -exec chmod 0755 {} \;>sudofind /srv/tftpboot/boot/images/ -type f -exec chmod 0644 {} \;
Assurez-vous que tous les fichiers extraits sont lisibles par les services TFTP et HTTP. Les clients PXE accéderont aux fichiers au cours du processus de démarrage. Il est donc essentiel de disposer d'autorisations et d'une configuration de service adéquates pour que les déploiements réussissent.
5.7 Étapes suivantes #
Une fois les fichiers du programme d'installation correctement préparés et organisés, vous pouvez poursuivre avec les tâches suivantes :
Configurer GRUB 2 pour le démarrage PXE avec des entrées de menu faisant référence à ces fichiers
Configurer les services HTTP et TFTP pour desservir le contenu extrait
Configurer DHCP pour diriger les clients PXE vers les chargeurs de démarrage appropriés
Les fichiers extraits seront référencés dans la configuration GRUB 2 à l'aide de chemins tels que root=live:http://pxe.example.net/boot/images/SLES-16.0/ARCH/squashfs.img.
6 Configuration de GRUB 2 pour le démarrage PXE #
Cette section décrit comment configurer le chargeur de démarrage GRUB 2 pour un démarrage basé sur PXE sous SUSE Linux Enterprise Server for SAP Applications 16.0. Elle couvre la création de la structure de répertoires de démarrage du réseau, la configuration de chargeurs de démarrage spécifiques à l'architecture et l'implémentation d'un système de configuration flexible qui prend en charge plusieurs architectures et scénarios d'installation.
6.1 Introduction #
GRUB 2 fait office de chargeur de démarrage réseau pour les clients PXE, en chargeant les fichiers du noyau Linux et initrd pour lancer le programme d'installation Agama. Cette section montre comment créer une configuration GRUB 2 sophistiquée qui détecte automatiquement l'architecture du client, gère la sélection de l'interface réseau et fournit un menu de démarrage unifié prenant en charge plusieurs types d'installation et architectures cibles.
L'approche de la configuration utilise une conception modulaire avec des fichiers séparés pour la détection de l'architecture, les définitions de variables et les entrées du menu de démarrage. Cela permet de prendre en charge des configurations spécifiques aux machines et des profils d'installation automatisés, tout en maintenant la cohérence entre les différentes plates-formes matérielles.
6.2 Configuration requise #
Assurez-vous que la structure du répertoire de démarrage du réseau GRUB 2 est en place, comme décrit dans les sections précédentes.
Assurez-vous que les fichiers du programme d'installation sont correctement organisés comme décrit dans les sections précédentes.
Les paquets GRUB 2 pour toutes les architectures cibles doivent être installés : grub2-x86_64-efi, grub2-i386-pc, grub2-aarch64-efi et grub2-ppc64le-ieee1275.
Le paquet shim pour la prise en charge du mode UEFI Secure Boot (facultatif).
Un accès administratif à
/srv/tftpbootou à la racine PXE équivalente.
6.3 Création de la configuration GRUB 2 #
Le fichier de configuration GRUB 2 gère trois tâches principales : la détection de l'architecture du client, la gestion des interfaces réseau et le chargement d'autres fichiers de configuration. Cette approche modulaire permet de s'adapter à différents scénarios de déploiement.
grub.cfg #Créez le fichier de configuration GRUB 2 principal à l'emplacement
/srv/tftpboot/boot/grub2/grub.cfg:>sudocat > /srv/tftpboot/boot/grub2/grub.cfg << 'EOF'# Architecture detection and mapping if [ "$grub_cpu" == "i386" ]; then set arch='x86_64' elif [ "$grub_cpu" == "x86_64" ]; then set arch='x86_64' elif [ "$grub_cpu" == "arm64" ]; then set arch='aarch64' elif [ "$grub_cpu" == "powerpc" ]; then set arch='ppc64le' fi if [ "X$arch" == "X" ]; then echo "ERROR: No architecture found for ${grub_cpu}" exit else echo "Running on $arch CPU architecture" fi export arch # Network interface configuration for PXE-selected NIC # - dracut based images on SLE-16: set ipcfg="ifname=pxe0:${net_default_mac} ip=pxe0:dhcp" export ipcfg # - linuxrc installer on SLE-15: set ifcfg="ifcfg=${net_default_mac}=dhcp" export ifcfg # Define typical serial console kernel parameter #set sconsole="console=tty0 console=ttyS0,115200n8" #export sconsole # Load machine-specific configuration if available if [ -s "${config}/${net_default_mac}/grub.cfg" ]; then ## Source a host specific configuration of grub menu: source "${config}/${net_default_mac}/grub.cfg" else ## Source default grub boot menu: source "${prefix}/menu.cfg" fi EOF
- Détection de l'architecture
Associe les types de processeur de GRUB 2 aux architectures de distribution, ce qui permet de créer des entrées de menu unifiées fonctionnant sur différentes plates-formes matérielles.
- Gestion de l'interface réseau
Définit une variable
${ipcfg}utilisant la variable grub2${net_default_mac}pour activer DHCP uniquement sur l'interface de démarrage PXE nomméepxe0, évitant ainsi les problèmes de sondage du réseau sur les systèmes multi-interfaces.- Définitions des utilitaires
Définit une variable type
${sconsole}avec des paramètres de console série.- Configuration spécifique à la machine
Charge les fichiers de configuration facultatifs par machine en fonction de l'adresse MAC, ce qui permet de personnaliser les paramètres de démarrage par machine et d'automatiser les profils d'installation.
6.5 Configurations spécifiques à la machine #
Pour les déploiements avancés, vous pouvez créer des fichiers de configuration spécifiques à la machine qui remplacent les paramètres par défaut ou fournissent des paramètres d'installation automatisés.
Créez un répertoire pour les configurations spécifiques à la machine :
>sudomkdir -p /srv/tftpboot/boot/configPour une machine avec une adresse MAC
aa:bb:cc:dd:ee:ff, créez une configuration spécifique :>sudomkdir -p /srv/tftpboot/boot/config/aa:bb:cc:dd:ee:ffCréez le fichier
grub.cfgspécifique à la machine :>sudocat > /srv/tftpboot/boot/config/aa:bb:cc:dd:ee:ff/grub.cfg << 'EOF'# Machine-specific configuration for aa:bb:cc:dd:ee:ff set default='SLES-16.0 Full Installation' # Activate the menu-entry after 5sec timeout set timeout=5 # Use know predictable network interface name set ipcfg="ip=eno1:dhcp" # Set the autoinstall variable for this machine set autoinstall="inst.auto=http://pxe.example.net/install/profiles/aa:bb:cc:dd:ee:ff/sles16.json" export autoinstall # Load the default menu source "/boot/grub2/menu.cfg" EOFVous pouvez éventuellement fournir une entrée de menu propre dans le fichier
grub.cfgspécifique à l'hôte (par exemple, généré pour une tentative de démarrage spécifique) :>sudocat > /srv/tftpboot/boot/config/aa:bb:cc:dd:ee:ff/grub.cfg << 'EOF'set default='SLES-16.0 Auto-Installation' set timeout=5 menuentry 'SLES-16.0 Auto-Installation' { linux /boot/images/SLES-16.0/${arch}/linux showopts root=live:http://pxe.example.net/boot/images/SLES-16.0/${arch}/squashfs.img inst.install_url=http://pxe.example.net/install/SLES-16.0/${arch} inst.auto=http://pxe.example.net/install/profiles/${net_default_mac}/sles16.json ip=eno1:dhcp initrd /boot/images/SLES-16.0/${arch}/initrd } EOF
-
default Spécifie l'entrée de menu pour démarrer automatiquement.
-
timeout Définit le timeout de démarrage en secondes.
-
ipcfg Remplace la configuration de l'interface réseau pour un matériel spécifique.
-
autoinstall Fournit des URL de profil d'installation automatisé spécifiques à la machine
6.6 Vérification de la configuration GRUB 2 #
Après avoir créé les fichiers de configuration, vérifiez que la configuration est correcte et que tous les fichiers requis sont en place.
Vérifiez la structure de répertoires GRUB 2 :
>find /srv/tftpboot/boot/grub2 -type f -name "*.cfg" -o -name "*.efi" -o -name "core.*"Vérifiez la syntaxe du fichier de configuration en la testant à l'aide des outils GRUB 2 :
>grub2-script-check /srv/tftpboot/boot/grub2/grub.cfg>grub2-script-check /srv/tftpboot/boot/grub2/menu.cfgVeillez à ce que les autorisations d'accès aux fichiers soient correctes :
>sudochmod -R 644 /srv/tftpboot/boot/grub2/*.cfg>sudofind /srv/tftpboot/boot/grub2 -type d -exec chmod 0755 {} \;
Testez la configuration GRUB 2 avec des clients PXE réels pour vous assurer de la détection de l'architecture et le menu fonctionnent correctement. La variable ${net_default_mac} n'est disponible que dans les scénarios de démarrage réseau réels.
6.7 Dépannage de la configuration GRUB 2 #
Problèmes courants et leurs solutions lors de l'utilisation de configurations PXE GRUB 2. Chaque problème comprend des étapes de diagnostic et des commandes spécifiques pour résoudre le problème.
6.7.1 Échec de la détection de l'architecture #
Lorsque GRUB 2 ne détecte pas l'architecture correcte, les clients risquent de démarrer avec des fichiers binaires incorrects ou de ne rien pouvoir charger.
Ajoutez une sortie de débogage à la configuration GRUB 2 pour afficher les valeurs détectées :
>sudocat >> /srv/tftpboot/boot/grub2/grub.cfg << 'EOF'# Debug architecture detection echo "Detected grub_cpu: ${grub_cpu}" echo "Mapped arch: ${arch}" sleep 3 EOFTestez la syntaxe de la configuration :
>grub2-script-check /srv/tftpboot/boot/grub2/grub.cfgSi l'assignation de l'architecture est incomplète, étendez la logique de détection :
>sudosed -i '/elif \[ "$grub_cpu" == "powerpc" \]/a\\nelif [ "$grub_cpu" == "riscv64" ]; then\n set arch='\''riscv64'\''\\' /srv/tftpboot/boot/grub2/grub.cfgVérifiez que les répertoires spécifiques à l'architecture existent :
>ls -la /srv/tftpboot/boot/grub2/
6.7.2 Interface réseau introuvable #
Certaines implémentations de microprogrammes peuvent ne pas définir correctement la variable ${net_default_mac}, ce qui entraîne des échecs de configuration du réseau.
Ajoutez une sortie de débogage pour vérifier les variables réseau :
>sudosed -i '/set ipcfg=/i\\necho "Default MAC: ${net_default_mac}"\necho "Network variables set"\nsleep 2' /srv/tftpboot/boot/grub2/grub.cfgCréez une configuration réseau de secours :
>sudocat >> /srv/tftpboot/boot/grub2/grub.cfg << 'EOF'# Fallback network configuration if net_default_mac is empty if [ "X${net_default_mac}" == "X" ]; then set ipcfg="ip=dhcp" set ifcfg="ifcfg=*=dhcp" echo "WARNING: Using fallback network configuration" sleep 2 fi EOFTestez la configuration réseau avec une interface spécifique :
>sudoecho 'set ipcfg="ip=eno1:dhcp"' > /srv/tftpboot/boot/config/test-network.cfgVérifiez les noms des interfaces réseau sur le système cible :
>ip link show
6.7.3 Chemins d'accès aux fichiers introuvables #
Des chemins d'accès incorrects empêchent GRUB 2 de charger les fichiers de kernel Linux et initrd, ce qui provoque des échecs de démarrage.
Vérifiez si les fichiers du programme d'installation existent aux emplacements prévus :
>find /srv/tftpboot/boot/images -name "linux" -o -name "initrd" -o -name "squashfs.img"Vérifiez l'accès TFTP aux fichiers de démarrage :
>tftp localhost -c get /boot/grub2/grub.cfg /tmp/test-grub.cfgTestez l'accès HTTP aux fichiers du programme d'installation :
>curl -I http://localhost/boot/images/SLES-16.0/x86_64/linuxVérifiez les autorisations et la propriété des fichiers :
>ls -la /srv/tftpboot/boot/images/SLES-16.0/*/Corrigez les autorisations si nécessaire :
>sudochmod -R 644 /srv/tftpboot/boot/images/>sudofind /srv/tftpboot/boot/images/ -type d -exec chmod 755 {} \;Vérifiez que les liens symboliques ne sont pas rompus :
>find /srv/tftpboot/boot/images/ -type l -exec ls -la {} \;
6.7.4 Échecs des démarrages EFI #
Des problèmes liés à EFI et Secure Boot peuvent empêcher l'initialisation correcte du chargeur de démarrage ou provoquer des échecs d'authentification.
Vérifiez que les fichiers Secure Boot sont présents :
>ls -la /srv/tftpboot/boot/grub2/x86_64-efi/*.efiVérifiez que les fichiers shim (bootx64.efi ou shim.efi), grub.efi et MokManager.efi sont correctement copiés :
>file /srv/tftpboot/boot/grub2/x86_64-efi/bootx64.efiVérifiez l'intégrité du fichier EFI :
>sha256sum /srv/tftpboot/boot/grub2/x86_64-efi/*.efiTestez si les fichiers sont accessibles via TFTP :
>tftp localhost -c get /boot/grub2/x86_64-efi/bootx64.efi /tmp/test-shim.efiPour les systèmes aarch64, vérifiez les fichiers EFI ARM64 :
>ls -la /srv/tftpboot/boot/grub2/arm64-efi/*.efiVérifiez que la configuration DHCP fournit les bons chemins d'accès au chargeur de démarrage :
>grep -n "bootx64.efi\|shim.efi\|bootaa64.efi" /etc/dnsmasq.d/dhcp.conf /etc/kea/kea-dhcp?.conf /etc/dhcpd?.confSi des fichiers sont manquants, recopiez-les à partir de l'image ISO montée dans /mnt ou à partir des fichiers du paquet shim :
>sudocp -v /mnt/EFI/BOOT/*.efi /srv/tftpboot/boot/grub2/x86_64-efi/>sudocp -pL /usr/share/efi/x86_64/*.efi /srv/tftpboot/boot/grub2/x86_64-efi/
6.7.6 Activation de la journalisation détaillée #
Pour les problèmes persistants, activez la journalisation complète afin de capturer des informations détaillées sur le processus de démarrage.
Créez une version de débogage de la configuration principale :
>sudocp /srv/tftpboot/boot/grub2/grub.cfg /srv/tftpboot/boot/grub2/grub.cfg.backupAjoutez une sortie de débogage complète :
>sudocat > /srv/tftpboot/boot/grub2/debug.cfg << 'EOF'# Debug configuration for GRUB troubleshooting set debug=all set pager=1 echo "=== GRUB Debug Information ===" echo "grub_cpu: ${grub_cpu}" echo "grub_platform: ${grub_platform}" echo "net_default_mac: ${net_default_mac}" echo "net_default_server: ${net_default_server}" echo "=============================" sleep 5 EOFIncluez la configuration de débogage dans le fichier principal :
>sudosed -i '1i\source "${prefix}/debug.cfg"' /srv/tftpboot/boot/grub2/grub.cfgSurveillez les journaux TFTP pendant les tentatives de démarrage :
>sudo journalctl -f -u tftp.socketSurveillez les journaux DHCP pour les requêtes PXE :
>sudo journalctl -f -u dhcpdDésactivez le mode de débogage après le dépannage :
>sudosed -i '/source "${prefix}\/debug.cfg"/d' /srv/tftpboot/boot/grub2/grub.cfg
6.8 Étapes suivantes #
Une fois GRUB 2 correctement configuré, vous pouvez passer aux tâches suivantes :
Configurer les services HTTP et TFTP pour desservir les fichiers de démarrage et le contenu du programme d'installation.
Configurer les services DHCP pour diriger les clients PXE vers les chargeurs de démarrage appropriés.
Tester le processus complet de démarrage PXE sur le matériel cible.
Le système de configuration flexible GRUB 2 fournit une base pour des scénarios de déploiement PXE sophistiqués, prenant en charge de multiples architectures et types d'installation par le biais d'une interface unifiée.
7 Configuration de TFTP pour le démarrage PXE #
Cette section explique comment configurer les services TFTP pour desservir les chargeurs de démarrage GRUB 2 et le contenu de démarrage PXE pour les installations SUSE Linux Enterprise Server for SAP Applications 16.0. Elle couvre le serveur traditionnel in.tftpd et la fonctionnalité TFTP intégrée fournie par dnsmasq.
7.1 Introduction #
TFTP fournit des fichiers de chargeur de démarrage aux clients PXE pendant le processus de démarrage du réseau. SUSE Linux Enterprise Server for SAP Applications 16.0 prend en charge deux implémentations de serveur TFTP : le serveur traditionnel in.tftpd du paquet tftp et la fonctionnalité TFTP intégrée dans dnsmasq.
7.2 Configuration requise #
Le paquet tftp ou le paquet dnsmasq est installé.
Les fichiers de démarrage PXE sont organisés sous
/srv/tftpboot.Des privilèges administratifs sont disponibles pour configurer les services.
7.3 Configuration du serveur in.tftpd #
Le serveur in.tftpd utilise le fichier de configuration /etc/sysconfig/tftp pour définir le répertoire racine TFTP et les options du serveur.
Vous pouvez éventuellement activer la journalisation verbeuse en définissant les options TFTP :
>sudosed -i 's/^TFTP_OPTIONS=.*/TFTP_OPTIONS="-v"/' /etc/sysconfig/tftpL'option
-vactive la journalisation verbeuse afin de consigner les noms des fichiers récupérés via TFTP.Activez et démarrez le service TFTP :
>sudosystemctl enable --now tftp.service
7.4 Configuration du serveur TFTP dnsmasq #
dnsmasq fournit un serveur TFTP intégré qui peut être activé et configuré pour utiliser le répertoire /srv/tftpboot.
Créez le fichier de configuration TFTP :
>sudocat > /etc/dnsmasq.d/tftp.conf << 'EOF'enable-tftp tftp-root=/srv/tftpboot EOFActivez et démarrez le service dnsmasq :
>sudosystemctl enable --now dnsmasq
7.5 Vérification de la configuration TFTP #
Testez la fonctionnalité du serveur TFTP pour vous assurer qu'il peut fournir des fichiers aux clients PXE.
Créez un fichier de test :
>echo "test file" | sudo tee /srv/tftpboot/test.txtRécupérez le fichier de test via TFTP :
>tftp localhost -c get test.txt /tmp/tftp-test.txtVérifiez que le fichier a bien été récupéré :
>cat /tmp/tftp-test.txtNettoyez les fichiers de test :
>sudorm /srv/tftpboot/test.txt /tmp/tftp-test.txt
7.6 Dépannage de la configuration TFTP #
Problèmes courants lors de la configuration des services TFTP pour les environnements de démarrage PXE.
7.6.1 Conflits de services sur le port 69 #
in.tftpd et dnsmasq utilisent tous deux le port UDP 69 pour les services TFTP et ne peuvent pas s'exécuter simultanément.
Vérifiez quels sont les services en cours d'exécution :
>systemctl status tftp.service dnsmasqVérifiez ce qui utilise le port 69 :
>ss -ulnp | grep :69Arrêtez le service en conflit (exemple pour dnsmasq) :
>sudosystemctl stop dnsmasqDémarrez votre service TFTP préféré :
>sudosystemctl start tftp.service
7.6.2 Problèmes liés au répertoire TFTP #
Des problèmes d'accès au répertoire racine TFTP peuvent empêcher la distribution des fichiers.
Vérifiez la configuration du répertoire TFTP pour in.tftpd :
>grep TFTP_DIRECTORY /etc/sysconfig/tftpVérifiez la configuration du répertoire TFTP pour dnsmasq :
>grep tftp-root /etc/dnsmasq.d/tftp.confVérifiez si le répertoire existe :
>ls -la /srv/tftpboot/S'il est manquant, créez le répertoire :
>sudomkdir -p /srv/tftpboot
7.6.3 Activation de la journalisation TFTP #
La journalisation verbeuse permet d'identifier les problèmes d'accès aux fichiers lors des transferts TFTP.
Vérifiez les options TFTP actuelles :
>grep TFTP_OPTIONS /etc/sysconfig/tftpActivez la journalisation verbeuse :
>sudosed -i 's/^TFTP_OPTIONS=.*/TFTP_OPTIONS="-v"/' /etc/sysconfig/tftpRedémarrez le service TFTP :
>sudosystemctl restart tftp.serviceSurveillez les journaux TFTP :
>journalctl -u tftp.service -f
7.7 Étapes suivantes #
Une fois TFTP configuré, vous pouvez passer à la configuration des services HTTP pour desservir les fichiers du programme d'installation et les services DHCP de manière à diriger les clients PXE vers les chargeurs de démarrage appropriés.
8 Configuration de nginx pour la distribution HTTP #
Cette section explique comment configurer nginx pour qu'il desserve le contenu du démarrage PXE via HTTP, de manière à permettre aux clients de charger des fichiers du programme d'installation, tels que les images du kernel Linux, initrd et squashfs, à partir d'un emplacement central. La distribution HTTP offre de meilleures performances que TFTP pour les fichiers volumineux et est requise pour les installations de SUSE Linux Enterprise Server for SAP Applications 16.0 à l'aide d'Agama.
8.1 Introduction #
nginx sert de serveur HTTP pour les environnements de démarrage PXE et permet d'accéder aux fichiers du programme d'installation par le biais d'une distribution basée sur le Web. Le serveur HTTP expose le répertoire de démarrage TFTP et les dépôts d'installation, ce qui permet aux clients PXE de télécharger les images du kernel Linux, les fichiers initrd et les composants du programme d'installation Agama via HTTP plutôt que via le protocole TFTP, qui est plus lent.
8.2 Configuration requise #
Le paquet nginx est installé.
Les fichiers de démarrage PXE sont organisés sous
/srv/tftpboot/boot.Les dépôts d'installation sont disponibles sous
/srv/install.Des privilèges administratifs sont disponibles pour modifier la configuration nginx.
8.3 Configuration de nginx pour le démarrage PXE #
La configuration de nginx définit des alias d'emplacement qui exposent le répertoire de démarrage TFTP et les dépôts d'installation par le biais d'URL HTTP.
Éditez le fichier de configuration nginx :
>sudovim /etc/nginx/nginx.confConfigurez le bloc du serveur HTTP dans la section
http:>sudocat > /etc/nginx/nginx.conf << 'EOF'http { include mime.types; default_type application/octet-stream; charset utf-8; sendfile on; keepalive_timeout 65; server { listen 80 default_server; listen [::]:80 default_server; location / { root /srv/www/htdocs/; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /srv/www/htdocs/; } # Expose TFTP boot directory for HTTP boot location /boot { alias /srv/tftpboot/boot; autoindex on; } # Expose installation repositories and profiles location /install { alias /srv/install; autoindex on; } } } events { worker_connections 1024; } EOFTestez la syntaxe de la configuration nginx :
>sudonginx -tActivez et démarrez le service nginx :
>sudosystemctl enable --now nginx.service
8.4 Vérification de la configuration nginx #
Testez la fonctionnalité du serveur HTTP pour vous assurer qu'il peut desservir les fichiers de démarrage PXE et le contenu de l'installation aux clients.
Testez l'accès HTTP aux fichiers de démarrage :
>curl -I http://localhost/boot/Testez l'accès au répertoire d'installation :
>curl -I http://localhost/install/Vérifiez qu'un fichier spécifique du programme d'installation est accessible :
>curl -I http://localhost/boot/images/SLES-16.0/x86_64/liveiso/LiveOS/squashfs.img
8.5 Dépannage de la configuration nginx #
Problèmes courants lors de la configuration de nginx pour la distribution HTTP au démarrage PXE.
8.5.1 Erreurs de syntaxe de la configuration #
Une syntaxe de configuration nginx incorrecte empêche le service de démarrer ou de se recharger correctement.
Testez la syntaxe de la configuration :
>sudonginx -tVérifiez le statut du service nginx si le démarrage échoue :
>systemctl status nginx.serviceAffichez les journaux d'erreurs détaillés :
>journalctl -u nginx.service -fVérifiez le fichier journal des erreurs de nginx :
>tail -f /var/log/nginx/error.log
8.5.2 Problèmes liés à l'accès aux fichiers et aux autorisations #
nginx peut ne pas parvenir à desservir des fichiers en raison d'autorisations incorrectes ou de répertoires manquants.
Vérifiez que le répertoire de démarrage existe et qu'il est accessible :
>ls -la /srv/tftpboot/boot/Vérifiez si le répertoire d'installation existe :
>ls -la /srv/install/Vérifiez que nginx peut lire les répertoires :
>sudo -u nginx ls /srv/tftpboot/boot/Créez les répertoires manquants le cas échéant :
>sudomkdir -p /srv/installDéfinissez les autorisations appropriées :
>sudochmod -R 755 /srv/tftpboot/boot /srv/install
8.5.3 Conflits de liaison de port #
nginx peut ne pas parvenir à démarrer si un autre service utilise le port 80.
Vérifiez ce qui utilise le port 80 :
>ss -tlnp | grep :80Arrêtez les services en conflit le cas échéant :
>sudosystemctl stop apache2Redémarrez le service nginx :
>sudosystemctl start nginx.serviceVérifiez que nginx écoute sur le port 80 :
>ss -tlnp | grep :80
8.6 Étapes suivantes #
Une fois nginx configuré pour la distribution HTTP, vous pouvez passer à la configuration des services DHCP de manière à diriger les clients PXE vers les chargeurs de démarrage et les ressources HTTP appropriés.
9 Configuration d'un serveur DNS à l'aide de dnsmasq #
Cette section explique comment configurer les services DNS à l'aide de dnsmasq afin d'assurer la résolution des noms d'hôte pour les clients PXE qui accèdent aux ressources d'installation de SUSE Linux Enterprise Server for SAP Applications 16.0. La configuration DNS permet aux clients d'utiliser des noms d'hôtes au lieu d'adresses IP dans les URL de démarrage et les configurations DHCP.
9.1 Introduction #
Les services DNS permettent aux clients PXE de résoudre les noms d'hôtes dans les URL de démarrage et les sources d'installation. Bien que la configuration complète d'un serveur DNS dépasse le cadre de ce document, cette section présente une configuration DNS de base utilisant dnsmasq qui permet aux clients de résoudre le nom d'hôte du serveur PXE (PXE.EXAMPLE.NET) en adresses IP.
Sans configuration DNS, les URL de démarrage doivent utiliser directement des adresses IP, telles que http://192.168.1.200/ ou http://[2001:db8:0:1::200]/. Certaines implémentations de microprogrammes BIOS/UEFI ne prennent pas en charge les noms d'hôtes dans les URL TFTP DHCP et requièrent des adresses IP telles que tftp://[2001:db8:0:1::200]/.
9.2 Configuration requise #
Le paquet dnsmasq est installé.
Des adresses IP statiques sont configurées pour le serveur PXE.
Des privilèges administratifs sont disponibles pour configurer les services DNS.
9.3 Configuration de services DNS dnsmasq #
La configuration DNS dnsmasq assure la résolution des noms d'hôtes locaux et utilise des serveurs de noms en amont pour les requêtes externes.
Créez le fichier de configuration DNS pour dnsmasq :
>sudocat > /etc/dnsmasq.d/dns.conf << 'EOF'# DNS configuration file for dnsmasq # Log DNS queries log-queries # DNS cache behavior cache-size=10000 local-ttl=60 neg-ttl=10 # Never forward A or AAAA queries for plain names to upstream name servers domain-needed # Add local domain to simple names in /etc/hosts and DHCP expand-hosts # Specifies DNS domain and networks including local forward and reverse declarations domain=EXAMPLE.NET,192.168.1.0/24,local domain=EXAMPLE.NET,2001:db8:0:1::/64,local EOFAjoutez des entrées de noms d'hôtes au fichier des hôtes (hosts) du système :
>sudocat >> /etc/hosts << 'EOF'192.168.1.200 PXE.EXAMPLE.NET 2001:db8:0:1::200 PXE.EXAMPLE.NET EOFTestez la configuration dnsmasq :
>sudodnsmasq --testActivez et démarrez le service dnsmasq :
>sudosystemctl enable --now dnsmasq
Par défaut, dnsmasq utilise les serveurs de noms de /etc/resolv.conf comme redirecteurs et fournit des enregistrements à partir de /etc/hosts. Cela permet au serveur PXE de résoudre les noms d'hôtes externes tout en fournissant une résolution locale pour les services liés à PXE.
9.4 Vérification de la configuration DNS #
Testez la fonctionnalité du serveur DNS pour vous assurer que la résolution du nom d'hôte fonctionne pour les clients PXE.
Testez la résolution du nom d'hôte IPv4 :
>nslookup PXE.EXAMPLE.NET localhostTestez la résolution du nom d'hôte IPv6 :
>nslookup PXE.EXAMPLE.NET localhost | grep 2001:db8Testez la recherche DNS inversée pour IPv4 :
>nslookup 192.168.1.200 localhostVérifiez que le transfert DNS externe fonctionne toujours :
>nslookup google.com localhost
9.5 Dépannage de la configuration DNS #
Problèmes courants lors de la configuration de dnsmasq pour les services DNS dans les environnements PXE.
9.5.1 Problèmes de configuration et de service #
dnsmasq peut ne pas démarrer en raison d'erreurs de configuration ou de conflits de ports.
Testez la syntaxe de la configuration dnsmasq :
>sudodnsmasq --testVérifiez le statut du service dnsmasq :
>systemctl status dnsmasqVérifiez ce qui utilise le port DNS 53 :
>ss -ulnp | grep :53Consultez les journaux dnsmasq pour vérifier s'il y a des erreurs :
>journalctl -u dnsmasq -fArrêtez les services DNS en conflit le cas échéant :
>sudosystemctl stop systemd-resolved
9.5.2 Échecs de la résolution de nom d'hôte #
Les requêtes DNS peuvent échouer en raison d'une configuration incorrecte ou d'entrées de noms d'hôtes manquantes.
Vérifiez si les entrées de noms d'hôtes existent dans le fichier hosts :
>grep PXE.EXAMPLE.NET /etc/hostsVérifiez la configuration du domaine dans dnsmasq :
>grep domain= /etc/dnsmasq.d/dns.confTestez une requête DNS avec sortie verbeuse :
>dig @localhost PXE.EXAMPLE.NETSurveillez les journaux de requêtes dnsmasq :
>journalctl -u dnsmasq | grep "query"Redémarrez dnsmasq pour recharger la configuration :
>sudosystemctl restart dnsmasq
9.5.3 Problèmes de transfert DNS #
Les requêtes DNS externes peuvent échouer si la configuration du serveur de noms en amont est incorrecte.
Vérifiez la configuration du serveur de noms en amont :
>cat /etc/resolv.confTestez une requête directe auprès du serveur de noms en amont :
>nslookup google.com 8.8.8.8Vérifiez la configuration du transfert dnsmasq :
>grep -E "server=|no-resolv" /etc/dnsmasq.d/dns.confAjoutez un serveur de noms spécifique en amont le cas échéant :
>sudoecho "server=8.8.8.8" >> /etc/dnsmasq.d/dns.confRedémarrez le service dnsmasq :
>sudosystemctl restart dnsmasq
9.6 Étapes suivantes #
Une fois les services DNS configurés, les clients PXE peuvent résoudre les noms d'hôtes dans les URL de démarrage et les sources d'installation. Vous pouvez procéder à la configuration des services DHCP qui font référence au serveur DNS pour la configuration du client.
10 Configuration d'un serveur NTP à l'aide de chrony #
Cette section explique comment configurer les services NTP à l'aide de chrony afin d'assurer une synchronisation horaire précise pour les clients PXE pendant les installations de SUSE Linux Enterprise Server for SAP Applications 16.0. Une synchronisation horaire correcte est essentielle pour la validation des certificats et la journalisation système lors d'installations basées sur le réseau.
10.1 Introduction #
Les services NTP assurent une synchronisation horaire précise dans l'ensemble de l'infrastructure réseau. Pour les environnements de démarrage PXE, la synchronisation horaire est cruciale pour la validation des certificats lors des connexions HTTPS, l'horodatage correct des journaux et les opérations système coordonnées. Cette section présente la configuration de base du serveur NTP à l'aide de chrony.
10.2 Configuration requise #
Le paquet chrony est installé.
>sudozypper install chronyLa connectivité réseau est assurée vers les serveurs NTP en amont.
Des privilèges administratifs sont disponibles pour configurer les services NTP.
10.3 Configuration du service NTP chrony #
Le service chrony fournit une fonctionnalité NTP avec une synchronisation horaire automatique avec les serveurs en amont et des fonctionnalités d'heure locale pour les clients du réseau.
chrony #Activez et démarrez le service
chrony:>sudosystemctl enable --now chronyd.service
10.4 Vérification de la configuration NTP #
Testez la fonctionnalité du service NTP pour vous assurer que la synchronisation horaire fonctionne correctement.
Vérifiez le statut du service
chrony:>systemctl status chronyd.serviceAffichez le statut actuel de la synchronisation horaire :
>chronyc trackingListez les sources NTP configurées :
>chronyc sourcesVérifiez les statistiques du serveur NTP :
>chronyc sourcestats
10.5 Dépannage de la configuration NTP #
Problèmes courants lors de la configuration de chrony pour les services NTP dans les environnements PXE.
10.5.1 Problème de démarrage du service #
Le service chrony peut ne pas démarrer en raison d'erreurs de configuration ou de problèmes de connectivité réseau.
Vérifiez le statut du service
chronyet ses journaux :>systemctl status chronyd.serviceAffichez les journaux détaillés du service :
>journalctl -u chronyd.service -fTestez la configuration
chrony:>sudochronyd -QRedémarrez le service le cas échéant :
>sudosystemctl restart chronyd.service
10.5.2 Échecs de synchronisation horaire #
La synchronisation horaire peut échouer en raison de problèmes de réseau ou d'une mauvaise configuration du serveur.
Vérifiez le statut actuel de la synchronisation :
>chronyc trackingVérifiez la connectivité de la source NTP :
>chronyc sources -vForcez une synchronisation immédiate :
>sudochronyc makestepVérifiez l'heure système par rapport à l'horloge matérielle :
>timedatectl statusVérifiez la connectivité réseau vers les serveurs NTP :
>chronyc activity
10.5.3 Pare-feu et problèmes de réseau #
Le trafic NTP peut être bloqué par des règles de pare-feu, ce qui empêche la synchronisation horaire.
Vérifiez si le port NTP est ouvert dans le pare-feu :
>firewall-cmd --list-services | grep ntpAjoutez le service NTP au pare-feu le cas échéant :
>sudofirewall-cmd --permanent --add-service=ntpRechargez la configuration du pare-feu :
>sudofirewall-cmd --reloadTestez manuellement la connectivité NTP :
>ntpdate -q pool.ntp.orgVérifiez l'utilisation du port
chrony:>ss -ulnp | grep :123
10.6 Étapes suivantes #
Si les services NTP sont configurés, le serveur et les clients PXE maintiendront une synchronisation horaire précise. Cela garantit une validation correcte des certificats et une coordination des opérations système lors d'installations basées sur le réseau.
11 Configuration des annonces de routeur IPv6 #
Cette section décrit comment configurer la fonctionnalité d'annonces de routeur IPv6 afin de fournir des annonces de routeur adéquates aux clients PXE. Les annonces de routeur IPv6 permettent la configuration du routage IPv6 et la configuration automatique des adresses DHCPv6 avec état pour les installations SUSE Linux Enterprise Server for SAP Applications 16.0.
11.1 Introduction #
Les annonces de routeur (RA) IPv6 fournissent des informations essentielles sur la configuration du réseau aux clients PXE, notamment les paramètres de routage IPv6 et de configuration automatique de l'adresse DHCPv6. Cette section suppose qu'un routeur IPv6 est configuré pour fournir des annonces de routeur adéquates afin de configurer le routage IPv6 vers le réseau et la route par défaut, et d'activer la configuration automatique de l'adresse DHCPv6 avec état à l'aide de AdvManagedFlag on.
11.2 Configuration requise #
Le paquet radvd est installé.
Configuration du réseau IPv6 sur l'interface du serveur
Des privilèges administratifs sont disponibles pour configurer les services d'annonces de routeur.
11.3 Configuration de radvd pour les annonces de routeur IPv6 #
Le service radvd fournit une fonctionnalité d'annonce de routeur IPv6 utilisant la configuration définie dans /etc/radvd.conf.
radvd #Configurez le service
radvd:>sudocat > /etc/radvd.conf << 'EOF'interface eno1 { # radvd options IgnoreIfMissing on; # Do not fail and exit when interface is missed AdvSendAdvert on; # Sending RAs on the interface is not disabled # Configuration settings AdvManagedFlag on; # Request IPv6 address and dns options via DHCPv6 AdvOtherConfigFlag off; # Request only dns info via DHCPv6, IP via SLAAC AdvDefaultLifetime 1800; # Add default route via this router for 1800sec prefix 2001:db8:0:1::/64 # Add direct route for this local network/prefix { AdvAutonomous off; # Assign IPv6 address via SLAAC AdvValidLifetime 7200; AdvPreferredLifetime 3600; }; }; EOFActivez et démarrez le service
radvd:>sudosystemctl enable --now radvd
11.4 Vérification des annonces de routeur IPv6 #
Testez la fonctionnalité d'annonces de routeur IPv6 (IPv6 RA) pour garantir sa bonne configuration et son fonctionnement correct.
Vérifiez le statut du service
radvd:>systemctl status radvdPassez en revue et vérifiez les paramètres IPv6 RA à l'aide de
ravdump:>radvdumpL'utilitaire
radvdumpaffiche les paramètres IPv6 RA envoyés par le routeur IPv6 toutes les quelques minutes.
11.5 Configuration du transfert IP pour la fonctionnalité de routeur #
Si le serveur PXE fait également office de routeur, le transfert IP doit être activé pour permettre au système de remplir un rôle de routeur.
Créez le fichier de configuration réseau :
>sudocat > /etc/sysctl.d/90-network.conf << 'EOF'# This machine is a router net.ipv4.conf.all.forwarding = 1 net.ipv6.conf.all.forwarding = 1 # Accept host autoconf on router uplink net.ipv6.conf.uplink.accept_ra = 2 EOFAppliquez les paramètres de configuration réseau :
>sudosysctl -p /etc/sysctl.d/90-network.conf
Par défaut, un routeur ne traite pas les annonces de routeur IPv6 pour la configuration automatique de l'hôte. Pour accepter les annonces de routeur IPv6 sur une interface de liaison montante de routeur, le paramètre sysctl accept_ra = 2 est requis. Consultez la section Configuration du réseau du Guide d'administration pour plus de détails sur la configuration du routeur, y compris les réglages du pare-feu et les autres étapes nécessaires.
11.6 Dépannage des annonces de routeur IPv6 #
Problèmes courants lors de la configuration des annonces de routeur IPv6 pour les environnements PXE.
11.6.1 Problèmes liés au service radvd #
Le service radvd peut ne pas démarrer en raison d'erreurs de configuration ou de problèmes d'interface.
radvd #Vérifiez le statut du service
radvdet ses journaux :>systemctl status radvdAffichez les journaux détaillés du service :
>journalctl -u radvd -fTestez la syntaxe de la configuration
radvd:>sudoradvd -C /etc/radvd.confVérifiez si l'interface spécifiée existe :
>ip link show eno1Redémarrez le service après avoir corrigé la configuration :
>sudosystemctl restart radvd
11.6.2 Problèmes liés à la configuration du transfert IP #
Des paramètres de transfert IP incorrects peuvent empêcher le bon déroulement de la fonctionnalité de routeur.
Vérifiez le statut actuel du transfert IP :
>sysctl net.ipv4.conf.all.forwardingVérifiez le statut du transfert IPv6 :
>sysctl net.ipv6.conf.all.forwardingVérifiez le fichier de configuration sysctl :
>cat /etc/sysctl.d/90-network.confAppliquez la configuration si les valeurs sont incorrectes :
>sudosysctl -p /etc/sysctl.d/90-network.confVérifiez le paramètre accept_ra sur l'interface de liaison montante :
>sysctl net.ipv6.conf.uplink.accept_ra
11.6.3 Problèmes liés à la réception des annonces de routeur #
Les clients peuvent ne pas recevoir ou traiter correctement les annonces de routeur IPv6.
Surveillez les annonces des routeurs à l'aide de
ravdump:>radvdump -dVérifiez la configuration de l'interface IPv6 sur les clients :
>ip -6 addr showVérifiez la table de routage IPv6 sur les clients :
>ip -6 route showTestez la connectivité IPv6 avec le routeur :
>ping6 2001:db8:0:1::1Vérifiez les règles de pare-feu pour ICMPv6 :
>firewall-cmd --list-protocols | grep ipv6-icmp
11.7 Étapes suivantes #
Si l'annonce de routeur IPv6 est configurée, les clients PXE peuvent recevoir une configuration réseau IPv6 correcte. Cela active la fonctionnalité DHCPv6 et la connectivité IPv6 pour les installations basées sur le réseau.
12 Configuration d'un serveur DHCP à l'aide de dnsmasq #
Cette section explique comment configurer les services DHCP à l'aide de dnsmasq afin de fournir les informations de configuration réseau et de démarrage PXE pour les installations SUSE Linux Enterprise Server for SAP Applications 16.0. Le serveur DHCP dnsmasq utilise la configuration basée sur les balises pour prendre en charge les clients PXE IPv4 et IPv6 avec des fonctionnalités de démarrage UEFI et BIOS.
12.1 Introduction #
Le serveur DHCP dnsmasq fournit des informations sur la configuration réseau et le fichier de démarrage aux clients PXE à l'aide d'un système basé sur les balises afin d'établir une correspondance avec les types de clients et de fournir les chargeurs de démarrage appropriés. Cette configuration prend en charge les correspondances PXEClient et HTTPClient qui fonctionnent pour DHCPv4 et DHCPv6, permettant le démarrage via les systèmes UEFI et BIOS sur de multiples architectures.
Les versions 2.90 et antérieures de dnsmasq ne prennent pas en charge l'envoi de l'option de classe de fournisseur (vendor-class) 6:16 aux clients DHCPv6 pour les configurations HTTPClient. Pour une prise en charge complète de HTTPClient, envisagez d'utiliser des serveurs DHCP Kea ou ISC.
12.2 Configuration requise #
Le paquet dnsmasq est installé.
Les fichiers de démarrage PXE sont correctement organisés sous
/srv/tftpboot.L'interface réseau est configurée pour le service DHCP.
Des privilèges administratifs sont disponibles pour configurer les services DHCP.
12.3 Configuration des services DHCP dnsmasq #
La configuration DHCP dnsmasq comprend la mise en correspondance des types de clients, les plages réseau et les affectations de fichiers de démarrage pour les réseaux IPv4 et IPv6.
Créez le fichier de configuration DHCP pour dnsmasq :
>sudocat > /etc/dnsmasq.d/dhcp.conf << 'EOF'# DHCP configuration file for dnsmasq # Log DHCP processing log-dhcp # This is the only DHCP server, don't ignore unknown clients/send NAK dhcp-authoritative # Disable re-use of the DHCPv4 servername and filename fields as extra # option space, which may confuse old or broken clients dhcp-no-override # IPv4 PXE/HTTP boot client matches (no enterprise number) # Match client type in PXEClient:Arch and map to a tag dhcp-vendorclass=set:tftp_bios_x86_pc,PXEClient:Arch:00000 dhcp-vendorclass=set:tftp_uefi_x86_64,PXEClient:Arch:00007 dhcp-vendorclass=set:tftp_ieee_ppc_64,PXEClient:Arch:0000e dhcp-vendorclass=set:tftp_uefi_arm_64,PXEClient:Arch:00011 # Match client type in HTTPClient:Arch and map to a tag dhcp-vendorclass=set:http_uefi_x86_64,HTTPClient:Arch:00016 dhcp-vendorclass=set:http_uefi_arm_64,HTTPClient:Arch:00019 # IPv6 PXE/HTTP boot client matches (enterprise:343 intel) # Match client type in PXEClient:Arch and map to a tag dhcp-vendorclass=set:tftp_bios_x86_pc,enterprise:343,PXEClient:Arch:00000 dhcp-vendorclass=set:tftp_uefi_x86_64,enterprise:343,PXEClient:Arch:00007 dhcp-vendorclass=set:tftp_ieee_ppc_64,enterprise:343,PXEClient:Arch:0000e dhcp-vendorclass=set:tftp_uefi_arm_64,enterprise:343,PXEClient:Arch:00011 # Match client type in HTTPClient:Arch and map to a tag dhcp-vendorclass=set:http_uefi_x86_64,enterprise:343,HTTPClient:Arch:00016 dhcp-vendorclass=set:http_uefi_arm_64,enterprise:343,HTTPClient:Arch:00019 EOFConfigurez la plage et les options DHCP IPv4 :
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv4 range and options dhcp-range=set:net0v4,192.168.1.100,192.168.1.199,255.255.255.0,1h dhcp-option=tag:net0v4,option:domain-search,example.net dhcp-option=tag:net0v4,option:dns-server,192.168.1.200 dhcp-option=tag:net0v4,option:ntp-server,192.168.1.1 dhcp-option=tag:net0v4,option:router,192.168.1.1 EOFConfigurez les options de démarrage PXE IPv4 :
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv4 PXEClient boot dhcp-boot=tag:net0v4,tag:tftp_bios_x86_pc,/boot/grub2/i386-pc/core.0,192.168.1.200 dhcp-boot=tag:net0v4,tag:tftp_uefi_x86_64,/boot/grub2/x86_64-efi/bootx64.efi,192.168.1.200 dhcp-boot=tag:net0v4,tag:tftp_ieee_ppc_64,/boot/grub2/powerpc-ieee1275/core.elf,192.168.1.200 dhcp-boot=tag:net0v4,tag:tftp_uefi_arm_64,/boot/grub2/arm64-efi/bootaa64.efi,192.168.1.200 # IPv4 HTTPClient boot dhcp-option-force=tag:net0v4,tag:http_uefi_x86_64,option:vendor-class,HTTPClient dhcp-boot=tag:net0v4,tag:http_uefi_x86_64,http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efi dhcp-option-force=tag:net0v4,tag:http_uefi_arm_64,option:vendor-class,HTTPClient dhcp-boot=tag:net0v4,tag:http_uefi_arm_64,http://192.168.1.200/boot/grub2/arm64-efi/bootaa64.efi EOFConfigurez la plage et les options DHCP IPv6 :
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv6 range and options dhcp-range=set:net0v6,2001:db8:0:1:d::,2001:db8:0:1:d::ffff,64,1h dhcp-option=tag:net0v6,option6:domain-search,example.net dhcp-option=tag:net0v6,option6:dns-server,[2001:db8:0:1::200] dhcp-option=tag:net0v6,option6:sntp-server,[2001:db8:0:1::1] EOFConfigurez les options de démarrage PXE IPv6 :
>sudocat >> /etc/dnsmasq.d/dhcp.conf << 'EOF'# IPv6 PXEClient boot dhcp-option=tag:net0v6,tag:tftp_bios_x86_pc,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/i386-pc/core.0 dhcp-option=tag:net0v6,tag:tftp_uefi_x86_64,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi dhcp-option=tag:net0v6,tag:tftp_ieee_ppc_64,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/powerpc-ieee1275/core.elf dhcp-option=tag:net0v6,tag:tftp_uefi_arm_64,option6:bootfile-url,tftp://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi # IPv6 HTTPClient boot # Note: dnsmasq <= 2.90 does not support sending vendor-class option6:16 back to client EOFTestez la configuration dnsmasq :
>sudodnsmasq --testActivez et démarrez le service dnsmasq :
>sudosystemctl enable --now dnsmasq
12.4 Vérification de la configuration DHCP #
Testez la fonctionnalité de serveur DHCP pour vous assurer que la configuration réseau est correcte et que le fichier de démarrage adéquat est distribué aux clients PXE.
Vérifiez le statut du service dnsmasq :
>systemctl status dnsmasqVérifiez la liaison de port DHCP :
>ss -ulnp | grep :67Surveillez les assignations de baux DHCP :
>journalctl -u dnsmasq -fVérifiez les baux DHCP actifs :
>cat /var/lib/dhcp/dhcpd.leases
12.5 Dépannage de la configuration DHCP dnsmasq #
Problèmes courants lors de la configuration de dnsmasq pour les services DHCP dans les environnements PXE.
12.5.1 Problèmes liés à la configuration et au démarrage de services #
dnsmasq peut ne pas démarrer en raison d'erreurs de configuration ou de conflits de ports avec d'autres services DHCP.
Testez la syntaxe de la configuration dnsmasq :
>sudodnsmasq --testRecherchez les éventuels conflits de ports DHCP :
>ss -ulnp | grep :67Arrêtez les services DHCP conflictuels :
>sudosystemctl stop dhcpdAffichez les journaux détaillés du service :
>journalctl -u dnsmasq -fRedémarrez dnsmasq après avoir résolu les conflits :
>sudosystemctl restart dnsmasq
12.5.2 Problèmes liés aux assignations de baux DHCP #
Les clients peuvent ne pas recevoir d'adresses IP en raison de problèmes de configuration de plage ou de connectivité réseau.
Vérifiez la configuration de la plage DHCP :
>grep dhcp-range /etc/dnsmasq.d/dhcp.confSurveillez les demandes DHCP en temps réel :
>journalctl -u dnsmasq -f | grep DHCPVérifiez le statut de l'interface réseau :
>ip addr showVérifiez le paramètre DHCP faisant autorité :
>grep dhcp-authoritative /etc/dnsmasq.d/dhcp.confTestez la réponse DHCP avec dhcping :
>dhcping -s 192.168.1.200
12.5.3 Problèmes liés à la distribution du fichier de démarrage PXE #
Les clients PXE peuvent recevoir des adresses IP mais ne pas démarrer en raison d'une configuration incorrecte du fichier de démarrage ou de problèmes liés à la correspondance des types de clients.
Vérifiez la correspondance de la classe de fournisseur du client :
>grep dhcp-vendorclass /etc/dnsmasq.d/dhcp.confVérifiez les chemins d'accès au fichier de démarrage :
>grep dhcp-boot /etc/dnsmasq.d/dhcp.confTestez l'accès TFTP aux fichiers de démarrage :
>tftp 192.168.1.200 -c get /boot/grub2/x86_64-efi/bootx64.efiSurveillez les journaux DHCP spécifiques à PXE :
>journalctl -u dnsmasq | grep -E "PXE|HTTP"Vérifiez l'assignation des balises dans les journaux :
>journalctl -u dnsmasq | grep "tags:"
12.5.4 Problèmes liés à la configuration DHCP IPv6 #
Les clients DHCP IPv6 nécessitent une configuration correcte des annonces de routeur et peuvent avoir des exigences d'adressage différentes de celles d'IPv4.
Vérifiez la configuration de la plage DHCP IPv6 :
>grep "2001:db8" /etc/dnsmasq.d/dhcp.confVérifiez le statut des annonces de routeur IPv6 :
>systemctl status radvdSurveillez les requêtes DHCPv6 :
>journalctl -u dnsmasq | grep "DHCPv6"Testez la connectivité IPv6 :
>ping6 2001:db8:0:1::200Vérifiez la configuration de l'option IPv6 :
>grep option6 /etc/dnsmasq.d/dhcp.conf
12.6 Étapes suivantes #
Avec les services DHCP dnsmasq configurés, les clients PXE peuvent recevoir des informations sur la configuration réseau et le fichier de démarrage à la fois pour les environnements IPv4 et IPv6. Le système basé sur les balises permet une assignation flexible des fichiers de démarrage en fonction de l'architecture du client et des exigences de la méthode de démarrage.
13 Configuration d'un serveur DHCP à l'aide de Kea #
Cette section explique comment configurer les services DHCP à l'aide de Kea afin de fournir les informations de configuration réseau et de démarrage PXE pour les installations SUSE Linux Enterprise Server for SAP Applications 16.0. Kea est un serveur DHCP moderne qui prend en charge à la fois IPv4 et IPv6 avec une mise en correspondance de la classe du client pour les scénarios de démarrage PXE et HTTP.
13.1 Introduction #
Kea est le serveur DHCP moderne développé par ISC pour succéder au serveur DHCP ISC hérité. Il assure une prise en charge robuste à la fois de DHCPv4 et de DHCPv6 avec des fonctionnalités de classification des clients qui permettent de distribuer un fichier de démarrage approprié en fonction de l'architecture et de la méthode de démarrage de ces derniers. Kea utilise des fichiers de configuration basés sur JSON et prend en charge des fonctionnalités avancées telles que l'identification de la classe du fournisseur pour le démarrage HTTP.
13.2 Configuration requise #
Les paquets DHCP Kea kea-dhcp4 et kea-dhcp6 sont installés.
Les fichiers de démarrage PXE sont correctement organisés sous
/srv/tftpboot.L'interface réseau est configurée pour le service DHCP.
Des privilèges administratifs sont disponibles pour configurer les services DHCP.
13.3 Configuration du serveur DHCPv4 Kea #
La configuration DHCPv4 Kea utilise des classes de clients pour mettre en correspondance les types de clients PXE et HTTP et fournir des fichiers de démarrage appropriés pour différentes architectures.
Configurez le serveur DHCPv4 Kea :
>sudocat > /etc/kea/kea-dhcp4.conf << 'EOF'{ "Dhcp4": { "interfaces-config": { "interfaces": [ "eno1" ] }, "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea4-ctrl-socket" }, "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/dhcp4.leases", "lfc-interval": 3600 }, "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, "renew-timer": 1800, "rebind-timer": 3150, "valid-lifetime": 3600, "option-data": [], "client-classes": [ { "name": "pxeclients#00000", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/i386-pc/core.0" }, { "name": "pxeclients#00007", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00007'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/x86_64-efi/bootx64.efi" }, { "name": "pxeclients#0000e", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:0000e'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/powerpc-ieee1275/core.elf" }, { "name": "pxeclients#00011", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00011'", "next-server": "192.168.1.200", "boot-file-name": "/boot/grub2/arm64-efi/bootaa64.efi" }, { "name": "httpclients#00016", "test": "substring(option[60].hex,0,21) == 'HTTPClient:Arch:00016'", "boot-file-name": "http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efi", "option-data": [ { "name": "vendor-class-identifier", "data": "HTTPClient" } ] }, { "name": "httpclients#00019", "test": "substring(option[60].hex,0,21) == 'HTTPClient:Arch:00019'", "boot-file-name": "http://192.168.1.200/boot/grub2/arm64-efi/bootaa64.efi", "option-data": [ { "name": "vendor-class-identifier", "data": "HTTPClient" } ] } ], "subnet4": [ { "id": 1, "subnet": "192.168.1.0/24", "pools": [ { "pool": "192.168.1.100 - 192.168.1.199" } ], "option-data": [ { "name": "routers", "data": "192.168.1.1" }, { "name": "ntp-servers", "data": "192.168.1.1" }, { "name": "domain-name-servers", "data": "192.168.1.200" }, { "name": "domain-search", "data": "example.net" } ], "reservations": [] } ], "loggers": [ { "name": "kea-dhcp4", "output-options": [ { "output": "/var/log/kea/dhcp4.log" } ], "severity": "INFO", "debuglevel": 0 } ] } } EOFCréez le répertoire pour les journaux de Kea :
>sudomkdir -p /var/log/keaTestez la configuration DHCPv4 Kea :
>sudokea-dhcp4 -t /etc/kea/kea-dhcp4.confActivez et démarrez le service DHCPv4 Kea :
>sudosystemctl enable --now kea-dhcp4
13.4 Configuration du serveur DHCPv6 Kea #
La configuration DHCPv6 Kea assure l'assignation d'adresses IPv6 et la fourniture des informations sur le fichier de démarrage à l'aide de la mise en correspondance de la classe de fournisseur pour différentes architectures de clients.
Configurez le serveur DHCPv6 Kea :
>sudocat > /etc/kea/kea-dhcp6.conf << 'EOF'{ "Dhcp6": { "interfaces-config": { "interfaces": [ "eno1" ] }, "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea6-ctrl-socket" }, "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/dhcp6.leases", "lfc-interval": 3600 }, "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, "renew-timer": 1800, "rebind-timer": 2880, "preferred-lifetime": 3600, "valid-lifetime": 7200, "option-data": [], "option-def": [], "client-classes": [ { "name": "pxeclients#00000", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:00000'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/i386-pc/core.0" } ] }, { "name": "pxeclients#00007", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:00007'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi" } ] }, { "name": "pxeclients#0000e", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:0000e'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/powerpc-ieee1275/core.elf" } ] }, { "name": "pxeclients#00011", "test": "substring(option[16].hex,6,20) == 'PXEClient:Arch:00011'", "option-data": [ { "name": "bootfile-url", "data": "tftp://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi" } ] } ], "subnet6": [ { "id": 1, "subnet": "2001:db8:0:1::/64", "interface": "eno1", "pools": [ { "pool": "2001:db8:0:1:d::/112" } ], "option-data": [ { "name": "sntp-servers", "data": "2001:db8:0:1::1" }, { "name": "dns-servers", "data": "2001:db8:0:1::200" }, { "name": "domain-search", "data": "example.net" } ], "reservations": [] } ], "loggers": [ { "name": "kea-dhcp6", "output-options": [ { "output": "/var/log/kea/dhcp6.log" } ], "severity": "INFO", "debuglevel": 0 } ] } } EOFTestez la configuration DHCPv6 Kea :
>sudokea-dhcp6 -t /etc/kea/kea-dhcp6.confActivez et démarrez le service DHCPv6 Kea :
>sudosystemctl enable --now kea-dhcp6
13.5 Vérification de la configuration DHCP Kea #
Testez la fonctionnalité du serveur DHCP Kea pour vous assurer que la configuration réseau est correcte et que le fichier de démarrage adéquat est distribué aux clients PXE.
Vérifiez le statut du service DHCPv4 Kea :
>systemctl status kea-dhcp4Vérifiez le statut du service DHCPv6 Kea :
>systemctl status kea-dhcp6Vérifiez la liaison de port DHCP :
>ss -ulnp | grep -E ":67|:547"Surveillez les journaux DHCPv4 :
>tail -f /var/log/kea/dhcp4.logSurveillez les journaux DHCPv6 :
>tail -f /var/log/kea/dhcp6.logVérifiez les baux DHCP actifs :
>cat /var/lib/kea/dhcp4.leases
13.6 Dépannage de la configuration DHCP Kea #
Problèmes courants lors de la configuration des serveurs DHCP Kea pour les environnements de démarrage PXE.
13.6.1 Problèmes de configuration et de service #
Les services Kea peuvent ne pas démarrer en raison d'erreurs de configuration JSON ou de problèmes d'interface réseau.
Testez la syntaxe de la configuration DHCPv4 :
>sudokea-dhcp4 -t /etc/kea/kea-dhcp4.confTestez la syntaxe de la configuration DHCPv6 :
>sudokea-dhcp6 -t /etc/kea/kea-dhcp6.confRecherchez les éventuelles erreurs de syntaxe JSON :
>python3 -m json.tool /etc/kea/kea-dhcp4.confVérifiez la configuration de l'interface réseau :
>ip addr show eno1Vérifiez les journaux du service Kea :
>journalctl -u kea-dhcp4 -f
13.6.2 Problèmes liés aux assignations de baux DHCP #
Les clients peuvent ne pas recevoir d'adresses IP en raison de problèmes de configuration de sous-réseau ou d'épuisement du pool.
Vérifiez la configuration du sous-réseau et du pool :
>grep -A 10 "subnet4\|pools" /etc/kea/kea-dhcp4.confSurveillez les assignations de baux en temps réel :
>tail -f /var/log/kea/dhcp4.log | grep -E "ALLOC|DISCOVER"Recherchez les éventuels conflits dans la base de données des baux :
>cat /var/lib/kea/dhcp4.leases | tail -20Vérifiez la liaison de l'interface :
>grep interfaces /etc/kea/kea-dhcp4.confEffacez la base de données des baux le cas échéant :
>sudosystemctl stop kea-dhcp4>sudomv /var/lib/kea/dhcp4.leases /var/lib/kea/dhcp4.leases.backup>sudosystemctl start kea-dhcp4
13.6.3 Problèmes de mise en correspondance de la classe des clients PXE #
Les clients PXE peuvent recevoir des adresses IP mais ne pas obtenir le bon fichier de démarrage en raison de problèmes de configuration de la classe des clients.
Vérifiez les définitions de classes des clients :
>grep -A 5 "client-classes" /etc/kea/kea-dhcp4.confSurveillez la mise en correspondance de la classe des clients dans les journaux :
>tail -f /var/log/kea/dhcp4.log | grep -i classVérifiez les modèles d'identificateur de classe de client :
>grep "PXEClient\|HTTPClient" /etc/kea/kea-dhcp4.confTestez l'accessibilité du fichier de démarrage :
>curl -I http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efiActivez la journalisation de débogage pour une analyse détaillée du client :
>sudosed -i 's/"debuglevel": 0/"debuglevel": 99/' /etc/kea/kea-dhcp4.conf>sudosystemctl restart kea-dhcp4
13.6.4 Problèmes spécifiques à DHCPv6 #
Les clients DHCP IPv6 nécessitent une configuration correcte des annonces de routeur et gèrent l'option de classe de fournisseur différemment des clients IPv4.
Vérifiez la configuration de sous-réseau DHCPv6 :
>grep -A 10 "subnet6" /etc/kea/kea-dhcp6.confVérifiez le statut des annonces de routeur IPv6 :
>systemctl status radvdVérifiez la correspondance de la classe de fournisseur DHCPv6 :
>tail -f /var/log/kea/dhcp6.log | grep "option\[16\]"Vérifiez le format de l'option bootfile-url IPv6 :
>grep "bootfile-url" /etc/kea/kea-dhcp6.confTestez la connectivité IPv6 vers le serveur de démarrage :
>ping6 2001:db8:0:1::200
13.7 Étapes suivantes #
Avec les services DHCP Kea configurés, les clients PXE peuvent recevoir des informations complètes sur la configuration réseau et le fichier de démarrage à la fois pour les environnements IPv4 et IPv6. Le système de classification des clients permet une assignation précise des fichiers de démarrage en fonction de l'architecture du client et prend en charge à la fois les méthodes traditionnelles de démarrage PXE et les méthodes modernes de démarrage HTTP.
14 Configuration d'un serveur DHCP avec DHCP ISC #
Cette section explique comment configurer les serveurs DHCP ISC afin de fournir les informations de configuration réseau et de démarrage PXE pour les installations SUSE Linux Enterprise Server for SAP Applications 15. Le paquet dhcp-server ISC n'est plus disponible sous SUSE Linux Enterprise Server for SAP Applications 16.0. DHCP ISC utilise la mise en correspondance des classes et des sous-classes pour prendre en charge les scénarios de démarrage PXE et HTTP dans différentes architectures de clients.
14.1 Introduction #
DHCP ISC est le serveur DHCP traditionnel qui fournit les informations sur la configuration réseau et le fichier de démarrage aux clients PXE à l'aide d'un système de classes et de sous-classes. Bien qu'ISC ait déclaré ce serveur en fin de vie à partir de 2022, il reste largement utilisé dans les déploiements existants et offre une prise en charge solide des scénarios de démarrage PXE et HTTP avec identification de la classe du fournisseur.
DHCP ISC a été déclaré en fin de vie par ISC en 2022. Pour les nouveaux déploiements, envisagez d'utiliser Kea ou dnsmasq à la place. Cette configuration est fournie pour assurer la compatibilité avec les installations DHCP ISC existantes.
14.2 Configuration requise #
Les paquets DHCP ISC dhcp-server sont installés.
Les fichiers de démarrage PXE sont correctement organisés sous
/srv/tftpboot.L'interface réseau est configurée pour le service DHCP.
Des privilèges administratifs sont disponibles pour configurer les services DHCP.
14.3 Configuration du serveur DHCPv4 ISC #
La configuration DHCPv4 ISC utilise des déclarations de classes et de sous-classes pour mettre en correspondance les types de clients PXE et HTTP et fournir des fichiers de démarrage appropriés pour différentes architectures.
Configurez le serveur DHCPv4 ISC :
>sudocat > /etc/dhcpd.conf << 'EOF'# /etc/dhcpd.conf # # Sample configuration file for ISC dhcpd # # *** PLEASE CONFIGURE IT FIRST *** # # Don't forget to set the DHCPD_INTERFACE in the # /etc/sysconfig/dhcpd file. # # if you want to use dynamical DNS updates, you should first read # read /usr/share/doc/packages/dhcp-server/DDNS-howto.txt # ddns-updates off; # Use this to enable / disable dynamic dns updates globally. ddns-update-style none; # default lease time default-lease-time 3600; max-lease-time 7200; ## ## PXE / HTTP boot option declarations ## class "pxeclients" { # PXEClient:Arch:00000:UNDI:002001 match substring (option vendor-class-identifier, 0, 20); } class "httpclients" { # HTTPClient:Arch:00016:UNDI:003001 match substring (option vendor-class-identifier, 0, 21); } ## ## PXE / HTTP boot subclass request matches ## subclass "pxeclients" "PXEClient:Arch:00000" { next-server 192.168.1.200; filename "/boot/grub2/i386-pc/core.0"; } subclass "pxeclients" "PXEClient:Arch:00007" { next-server 192.168.1.200; filename "/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "pxeclients" "PXEClient:Arch:0000e" { next-server 192.168.1.200; filename "/boot/grub2/powerpc-ieee1275/core.elf"; } subclass "pxeclients" "PXEClient:Arch:00011" { next-server 192.168.1.200; filename "/boot/grub2/arm64-efi/bootaa64.efi"; } subclass "httpclients" "HTTPClient:Arch:00016" { option vendor-class-identifier "HTTPClient"; filename "http://192.168.1.200/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "httpclients" "HTTPClient:Arch:00019" { option vendor-class-identifier "HTTPClient"; filename "http://192.168.1.200/boot/grub2/arm64-efi/bootaa64.efi"; } ## ## Subnet declaration for the pxe network ## subnet 192.168.1.0 netmask 255.255.255.0 { authoritative; range dynamic-bootp 192.168.1.100 192.168.1.199; option subnet-mask 255.255.255.0; option routers 192.168.1.1; option ntp-servers 192.168.1.1; option domain-name-servers 192.168.1.200; option domain-name "example.net"; option domain-search "example.net"; } EOFConfigurez l'interface DHCP dans sysconfig :
>sudoecho 'DHCPD_INTERFACE="eno1"' > /etc/sysconfig/dhcpdTestez la configuration DHCPv4 :
>sudodhcpd -t -cf /etc/dhcpd.confActivez et démarrez le service DHCPv4 ISC :
>sudosystemctl enable --now dhcpd
14.4 Configuration du serveur DHCPv6 ISC #
La configuration DHCPv6 ISC assure l'assignation d'adresses IPv6 et la fourniture des informations sur le fichier de démarrage à l'aide de la mise en correspondance de la classe de fournisseur avec la gestion adéquate des options DHCPv6.
Configurez le serveur DHCPv6 ISC :
>sudocat > /etc/dhcpd6.conf << 'EOF'# /etc/dhcpd6.conf # # Sample DHCPv6 configuration file for ISC dhcpd # # *** PLEASE CONFIGURE IT FIRST *** # # Don't forget to set the DHCPD6_INTERFACE in the # /etc/sysconfig/dhcpd file. # # if you want to use dynamical DNS updates, you should first # read /usr/share/doc/packages/dhcp-server/DDNS-howto.txt ddns-updates off; # Use this to enable / disable dynamic dns updates globally. ddns-update-style none; # IPv6 address valid lifetime # (at the end the address is no longer usable by the client) # (set to 30 days, the usual IPv6 default) default-lease-time 7200; # IPv6 address preferred lifetime # (at the end the address is deprecated, i.e., the client should use # other addresses for new connections) # (set to 7 days, the usual IPv6 default) preferred-lifetime 3600; ## ## PXE / HTTP boot option declarations ## # The dhcp6 option 16 is in fact an: # { uint32 enterprise-number, array of { uint16 len, string tag} vendor-class-data } # this declaration is using the whole option data as string for substring match: option dhcp6.vendor-class-as-string code 16 = string; # this declaration is using the enterprise-number with 1st tag length and string: option dhcp6.vendor-class-en-len-tag code 16 = {integer 32, integer 16, string}; class "pxeclients" { # PXEClient:Arch:00000:UNDI:002001 # note: +6 to skip the enterprise-number+len until the PXEClient string match substring (option dhcp6.vendor-class-as-string, 6, 20); } class "httpclients" { # HTTPClient:Arch:00016:UNDI:003001 # note: +6 to skip the enterprise-number+len until the HTTPClient string match substring (option dhcp6.vendor-class-as-string, 6, 21); } ## ## PXE / HTTP boot subclass request matches ## subclass "pxeclients" "PXEClient:Arch:00000" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/i386-pc/core.0"; } subclass "pxeclients" "PXEClient:Arch:00007" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "pxeclients" "PXEClient:Arch:0000e" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/powerpc-ieee1275/core.elf"; } subclass "pxeclients" "PXEClient:Arch:00011" { option dhcp6.bootfile-url "tftp://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi"; } subclass "httpclients" "HTTPClient:Arch:00016" { option dhcp6.vendor-class-en-len-tag 343 10 "HTTPClient"; option dhcp6.bootfile-url "http://[2001:db8:0:1::200]/boot/grub2/x86_64-efi/bootx64.efi"; } subclass "httpclients" "HTTPClient:Arch:00019" { option dhcp6.vendor-class-en-len-tag 343 10 "HTTPClient"; option dhcp6.bootfile-url "http://[2001:db8:0:1::200]/boot/grub2/arm64-efi/bootaa64.efi"; } ## ## Subnet declaration for the pxe network ## subnet6 2001:db8:0:1::/64 { authoritative; range6 2001:db8:0:1:d:: 2001:db8:0:1:d::ffff; option dhcp6.sntp-servers 2001:db8:0:1::1; option dhcp6.name-servers 2001:db8:0:1::200; option dhcp6.domain-search "example.net"; } EOFConfigurez l'interface DHCPv6 dans sysconfig :
>sudoecho 'DHCPD6_INTERFACE="eno1"' >> /etc/sysconfig/dhcpdTestez la configuration DHCPv6 :
>sudodhcpd -6 -t -cf /etc/dhcpd6.confActivez et démarrez le service DHCPv6 ISC :
>sudosystemctl enable --now dhcpd6
14.5 Vérification de la configuration DHCP ISC #
Testez la fonctionnalité du serveur DHCP ISC pour vous assurer que la configuration réseau est correcte et que le fichier de démarrage adéquat est distribué aux clients PXE.
Vérifiez le statut du service DHCPv4 ISC :
>systemctl status dhcpdVérifiez le statut du service DHCPv6 ISC :
>systemctl status dhcpd6Vérifiez la liaison de port DHCP :
>ss -ulnp | grep -E ":67|:547"Surveillez les journaux DHCP :
>journalctl -u dhcpd -fVérifiez les baux DHCP actifs :
>cat /var/lib/dhcp/dhcpd.leasesSurveillez l'activité DHCPv6 :
>journalctl -u dhcpd6 -f
14.6 Dépannage de la configuration DHCP ISC #
Problèmes courants lors de la configuration des serveurs DHCP ISC pour les environnements de démarrage PXE.
14.6.1 Problèmes de configuration et de service #
Les services DHCP ISC peuvent ne pas démarrer en raison d'erreurs de syntaxe de la configuration ou de problèmes de liaison d'interface.
Testez la syntaxe de la configuration DHCPv4 :
>sudodhcpd -t -cf /etc/dhcpd.confTestez la syntaxe de la configuration DHCPv6 :
>sudodhcpd -6 -t -cf /etc/dhcpd6.confVérifiez la configuration de l'interface :
>cat /etc/sysconfig/dhcpdVérifiez le statut de l'interface réseau :
>ip addr show eno1Recherchez les éventuels conflits de ports :
>ss -ulnp | grep :67Affichez les journaux détaillés du service :
>journalctl -u dhcpd -xe
14.6.2 Problèmes liés aux assignations de baux DHCP #
Les clients peuvent ne pas recevoir d'adresses IP en raison de problèmes d'autorisation ou de configuration de sous-réseau.
Vérifiez la configuration du sous-réseau et de la plage :
>grep -A 10 "subnet\|range" /etc/dhcpd.confVérifiez le paramètre faisant autorité :
>grep authoritative /etc/dhcpd.confSurveillez les assignations de baux en temps réel :
>tail -f /var/log/messages | grep dhcpdRecherchez les éventuelles erreurs dans la base de données des baux :
>tail -20 /var/lib/dhcp/dhcpd.leasesTestez la réponse DHCP manuellement :
>dhcping -s 192.168.1.200 -h aa:bb:cc:dd:ee:ff
14.6.3 Problèmes de mise en correspondance des classes et sous-classes #
Les clients PXE peuvent recevoir des adresses IP mais ne pas obtenir les fichiers de démarrage appropriés en raison de problèmes de configuration de la mise en correspondance des classes.
Vérifiez les définitions de classe :
>grep -A 3 "class.*clients" /etc/dhcpd.confVérifiez les entrées de sous-classe :
>grep -A 5 "subclass" /etc/dhcpd.confSurveillez l'identification des classes de fournisseurs :
>tail -f /var/log/messages | grep -E "PXEClient|HTTPClient"Testez l'accessibilité du fichier de démarrage :
>tftp 192.168.1.200 -c get /boot/grub2/x86_64-efi/bootx64.efiActivez la journalisation détaillée :
>sudosed -i '1i\log-facility local7;' /etc/dhcpd.conf>sudosystemctl restart dhcpd
14.6.4 Problèmes liés à l'option de classe de fournisseur DHCPv6 #
Les clients DHCP IPv6 présentent une gestion complexe de l'option de classe fournisseur qui peut nécessiter une configuration spécifique pour une prise en charge correcte du démarrage PXE.
Vérifiez les définitions des options DHCPv6 :
>grep -A 3 "option dhcp6" /etc/dhcpd6.confVérifiez l'analyse des chaînes de classes de fournisseurs :
>grep "substring.*6.*20\|21" /etc/dhcpd6.confVérifiez la correspondance de la classe de fournisseur DHCPv6 :
>journalctl -u dhcpd6 | grep -i vendorVérifiez le format de l'option bootfile-url IPv6 :
>grep "bootfile-url" /etc/dhcpd6.confVérifiez la dépendance des annonces de routeur :
>systemctl status radvdTestez la connectivité IPv6 :
>ping6 2001:db8:0:1::200
14.7 Étapes suivantes #
Lorsque les services DHCP ISC sont configurés, les clients PXE peuvent recevoir des informations sur la configuration réseau et le fichier de démarrage à l'aide du système traditionnel de classes et de sous-classes. Bien que DHCP ISC soit en fin de vie, cette configuration assure la compatibilité pour les déploiements existants qui nécessitent des fonctionnalités de démarrage PXE et HTTP sur plusieurs architectures de clients.
15 Validation de la configuration du serveur PXE #
Cette section décrit comment valider et tester la configuration complète du serveur PXE afin de s'assurer que tous les composants fonctionnent correctement pour les installations réseau de SUSE Linux Enterprise Server for SAP Applications 16.0. Il couvre la vérification des services, les tests de connectivité du réseau et la validation du démarrage PXE de bout en bout.
15.1 Introduction #
Après avoir configuré tous les composants du serveur PXE, y compris les services TFTP, HTTP, DNS, DHCP et de chargeur de démarrage GRUB 2, il est essentiel de valider le bon fonctionnement de l'ensemble du système. Cette validation garantit que les clients PXE peuvent démarrer avec succès dans le programme d'installation Agama et effectuer des installations basées sur le réseau de SUSE Linux Enterprise Server for SAP Applications 16.0.
15.2 Configuration requise #
Tous les composants du serveur PXE sont configurés et opérationnels.
Des systèmes clients de test capables d'effectuer des démarrages PXE sont disponibles.
Une connectivité réseau est assurée entre le serveur PXE et les clients.
Un accès administratif est disponible pour surveiller les services du serveur.
15.3 Validation des services du serveur PXE #
Vérifiez que tous les services essentiels du serveur PXE sont en cours d'exécution et sont correctement configurés avant de les tester avec les clients PXE.
Vérifiez le statut du service TFTP :
>systemctl status tftp.socketRésultat attendu : le service doit être actif et écouter sur le port 69.
Vérifiez le service HTTP nginx :
>systemctl status nginxRésultat attendu : le service doit être actif et écouter sur le port 80.
Vérifiez le service DNS (si vous utilisez dnsmasq) :
>systemctl status dnsmasqRésultat attendu : le service doit être actif et écouter sur le port 53.
Vérifiez le statut du service DHCP (choisissez le service approprié) :
>systemctl status dhcpdPour DHCP dnsmasq :
>systemctl status dnsmasqPour DHCP Kea :
>systemctl status kea-dhcp4 kea-dhcp6Résultat attendu : le service DHCP doit être actif et écouter sur les ports appropriés.
Vérifiez les annonces de routeur IPv6 (si configurées) :
>systemctl status radvdRésultat attendu : le service doit être actif pour les environnements IPv6.
Vérifiez le service NTP :
>systemctl status chronydRésultat attendu : le service doit être actif et synchronisé.
15.4 Test de la connectivité réseau et de l'accès aux fichiers #
Vérifiez que les clients PXE peuvent accéder aux fichiers de démarrage et au contenu de l'installation sur le réseau à l'aide des protocoles TFTP et HTTP.
Testez l'accès TFTP aux fichiers de chargeur de démarrage :
>tftp localhost -c get /boot/grub2/x86_64-efi/bootx64.efi /tmp/test-bootx64.efiVérifiez que le fichier a bien été récupéré :
>file /tmp/test-bootx64.efiNettoyez les fichiers de test :
>rm /tmp/test-bootx64.efiTestez l'accès HTTP à la configuration GRUB 2 :
>curl -I http://localhost/boot/grub2/grub.cfgRésultat attendu : réponse HTTP 200 OK.
Vérifiez l'accès HTTP aux fichiers du programme d'installation :
>curl -I http://localhost/boot/images/SLES-16.0/x86_64/liveiso/LiveOS/squashfs.imgRésultat attendu : réponse HTTP 200 OK avec une longueur de contenu appropriée.
Testez la résolution DNS (si le DNS local est configuré) :
>nslookup pxe.example.net localhostRésultat attendu : résolution correcte des enregistrements A et AAAA.
Vérifiez la navigation dans les répertoires pour les emplacements d'autoindex :
>curl http://localhost/boot/Résultat attendu : liste de répertoires montrant les fichiers de démarrage.
15.5 Validation de la fonctionnalité DHCP #
Testez les réponses du serveur DHCP et vérifiez que les informations de démarrage appropriées sont fournies aux différents types de clients.
Vérifiez la liaison de port DHCP :
>ss -ulnp | grep -E ":67|:547"Résultat attendu : services DHCP écoutant sur les ports 67 (IPv4) et 547 (IPv6).
Surveillez les demandes DHCP en temps réel :
>journalctl -u dhcpd -fOu pour dnsmasq :
>journalctl -u dnsmasq -fLaissez cette commande s'exécuter pour observer l'activité DHCP pendant le test.
Testez la réponse DHCP à l'aide de dhcping (si disponible) :
>dhcping -s 192.168.1.200Résultat attendu : réponse DHCP réussie du serveur.
Vérifiez les baux DHCP actifs :
>cat /var/lib/dhcp/dhcpd.leasesOu pour Kea :
>cat /var/lib/kea/dhcp4.leasesRésultat attendu : entrées de baux pour les clients tests.
15.6 Test de démarrage PXE de bout en bout #
Effectuez des tests complets de démarrage PXE avec des systèmes clients réels pour valider l'ensemble du processus de démarrage, depuis DHCP jusqu'au démarrage du programme d'installation Agama.
Préparez un système client de test :
Configurez le BIOS/UEFI pour permettre le démarrage réseau.
Définissez le démarrage réseau comme première priorité de démarrage.
Connectez le client au même réseau que le serveur PXE.
Surveillez les journaux du serveur PXE pendant le démarrage du client :
>journalctl -f | grep -E "dhcp|tftp|nginx"Démarrez le client de test et observez la séquence suivante :
Le client devrait recevoir une adresse IP via DHCP.
Le client devrait télécharger le chargeur de démarrage via TFTP.
Le menu GRUB 2 devrait apparaître avec les options d'installation.
Le kernel Linux et l'unité RAM initiale (initrd) devraient se charger via HTTP.
Le programme d'installation Agama devrait démarrer correctement.
Vérifiez la détection de l'architecture du client en testant différents types de clients :
Systèmes BIOS x86_64 hérités (devraient obtenir le fichier core.0)
Systèmes UEFI x86_64 (devraient obtenir le fichier bootx64.efi)
Systèmes UEFI aarch64 (devraient obtenir le fichier bootaa64.efi)
Testez le démarrage PXE IPv6 (si IPv6 est configuré) :
Activez la configuration réseau IPv6 uniquement sur le client de test.
Vérifiez l'assignation d'adresses DHCPv6.
Vérifiez la distribution de bootfile-url IPv6.
15.7 Validation des fonctionnalités du programme d'installation Agama #
Vérifiez que le programme d'installation Agama démarre correctement et qu'il peut accéder aux sources d'installation pour effectuer les installations de SUSE Linux Enterprise Server for SAP Applications 16.0.
Vérifiez l'accessibilité de l'interface Web d'Agama :
Lors du démarrage du client, notez l'adresse IP assignée et l'accès :
http://CLIENT_IP_ADDRESS
Résultat attendu : l'interface Web Agama devrait se charger correctement.
Vérifiez les journaux du programme d'installation Agama sur le client :
Basculez vers la console (Alt+F2) et exécutez :
#journalctl -u agama-web-server -fRésultat attendu : aucune erreur critique ne doit se produire au démarrage d'Agama.
Vérifiez l'accessibilité de la source d'installation :
Pour les installations ISO complètes, vérifiez l'accès au dépôt :
#curl -I http://192.168.1.200/install/SLES-16.0/x86_64/Résultat attendu : réponse HTTP 200 OK avec la liste du dépôt.
Testez la fonctionnalité d'installation de paquet :
Dans l'interface Agama, vérifiez que :
le système peut détecter les disques disponibles ;
la configuration réseau est conservée ;
le dépôt de paquets est accessible ;
l'installation peut se poursuivre jusqu'à son terme.
15.8 Dépannage des échecs de validation #
Problèmes courants lors de la validation du serveur PXE et leurs étapes de résolution.
15.8.1 Échecs de l'assignation DHCP #
Les clients ne reçoivent pas d'adresses IP pendant le démarrage PXE.
Recherchez les éventuels conflits de service DHCP :
>ss -ulnp | grep :67Vérifiez que l'interface réseau est opérationnelle :
>ip addr show eno1Vérifiez la disponibilité de la plage DHCP :
>nmap -sn 192.168.1.100-199Surveillez les journaux DHCP pour repérer les éventuelles erreurs :
>journalctl -u dhcpd | tail -50
15.8.2 Échecs de distribution des fichiers de démarrage #
Les clients reçoivent des adresses IP, mais ne parviennent pas à télécharger les fichiers de démarrage.
Vérifiez l'accessibilité du service TFTP :
>tftp 192.168.1.200 -c get /boot/grub2/x86_64-efi/bootx64.efiVérifiez les autorisations des fichiers :
>ls -la /srv/tftpboot/boot/grub2/x86_64-efi/Surveillez les journaux d'accès TFTP :
>journalctl -u tftp.socket -fVérifiez la détection de l'architecture des clients :
>grep -E "PXEClient|HTTPClient" /var/log/messages
15.8.3 Échecs du démarrage du programme d'installation Agama #
Les fichiers de démarrage se chargent correctement, mais le programme d'installation Agama ne démarre pas.
Vérifiez l'accès HTTP aux fichiers du programme d'installation :
>curl -I http://192.168.1.200/boot/images/SLES-16.0/x86_64/liveiso/LiveOS/squashfs.imgVérifiez la syntaxe des paramètres du kernel Linux dans la configuration GRUB 2 :
>grep "root=live:" /srv/tftpboot/boot/grub2/menu.cfgSurveillez le processus de démarrage des clients :
>journalctl -f | grep -E "kernel|initrd|agama"Vérifiez la persistance de la configuration réseau :
#ip addr show
15.9 Liste de contrôle pour la validation du serveur PXE #
Cette liste de contrôle vous permet de vérifier systématiquement tous les aspects de la configuration de votre serveur PXE.
| Composant | Étape de validation | Statut |
|---|---|---|
| TFTP Service | Service actif, écoute sur le port 69, fichiers accessibles | ☐ |
| Service HTTP | nginx actif, écoute sur le port 80, fichiers du programme d'installation accessibles | ☐ |
| Service DNS | Résolution du nom d'hôte opérationnelle, écoute sur le port 53 | ☐ |
| Service DHCP | Assignation d'adresses IP opérationnelle, options de démarrage distribuées | ☐ |
| Configuration GRUB 2 | Le menu se charge ; la détection de l'architecture fonctionne | ☐ |
| Prise en charge d'IPv6 | Annonces de routeur actives, DHCPv6 opérationnel | ☐ |
| Démarrage PXE | Le client démarre correctement et reçoit un chargeur de démarrage correct | ☐ |
| Programme d'installation Agama | Le programme d'installation démarre ; l'interface Web est accessible | ☐ |
| Source d'installation | Dépôt accessible, paquets installables | ☐ |
| Persistance du réseau | Maintien de la configuration réseau pendant l'installation | ☐ |
15.10 Conclusion de la validation #
Un serveur PXE correctement validé devrait présenter une fonctionnalité correcte de bout en bout, depuis le démarrage du réseau du client jusqu'au démarrage du programme d'installation Agama. Tous les services devraient fonctionner sans erreur et les clients devraient être en mesure d'effectuer des installations de SUSE Linux Enterprise Server for SAP Applications 16.0 sur le réseau. Des tests de validation réguliers garantissent la fiabilité continue de l'infrastructure PXE pour les déploiements automatisés.
16 Mentions légales #
Copyright © 2006–2025 SUSE LLC et contributeurs. Tous droits réservés.
Il est autorisé de copier, distribuer et/ou modifier ce document conformément aux conditions de la licence « GNU Free Documentation License » version 1.2 ou (à votre discrétion) 1.3, avec la section permanente qu'est cette mention de copyright et la licence. Une copie de la version de licence 1.2 est incluse dans la section intitulée « GNU Free Documentation License ».
Pour les marques commerciales SUSE, consultez le site Web https://www.suse.com/company/legal/. Toutes les autres marques de fabricants tiers sont la propriété de leur détenteur respectif. Les symboles de marque (®, ™, etc.) désignent des marques de SUSE et de ses sociétés affiliées. Des astérisques (*) désignent des marques commerciales de fabricants tiers.
Toutes les informations de cet ouvrage ont été regroupées avec le plus grand soin. Cela ne garantit cependant pas sa complète exactitude. Ni SUSE LLC, ni les sociétés affiliées, ni les auteurs, ni les traducteurs ne peuvent être tenus responsables des erreurs possibles ou des conséquences qu'elles peuvent entraîner.