17 Vorbereiten der Netzwerk-Boot-Umgebung #

Im folgenden Beispiel wird gezeigt, wie ein DHCP-Server eingerichtet wird, der dynamisch IP-Adressen zu Clients zuweist und Server, Router, Domänen und Boot-Dateien bekannt gibt.

Ein DHCP-Server kann auch statische IP-Adressen und Hostnamen zu Netzwerk-Clients zuweisen. Ein Anwendungsfall ist die Zuweisung von statischen Adressen zu Servern. Bei einem weiteren Anwendungsfall wird die Möglichkeit des Beitritts zum Netzwerk auf die Clients mit zugewiesenen statischen IP-Adressen beschränkt und es werden keine dynamischen Adressenpools zur Verfügung gestellt.

Bearbeiten Sie die obige DHCP-Konfiguration entsprechend des folgenden Beispiels:

group {
 host test {
   hardware ethernet MAC_ADDRESS;
   fixed-address IP_ADDRESS;
   }
}

Die Hostbestimmung weist einen Hostnamen zum Installationsziel zu. Um den Hostnamen und die IP-Adresse an einen bestimmten Host zu binden, müssen Sie die Hardware-Adresse (MAC) des Client angeben. Ersetzen Sie alle Variablen in diesem Beispiel durch die aktuellen Werte, die zu Ihrer Umgebung passen. Speichern Sie dann die Änderungen und starten Sie den DHCP-Server neu.

Ab SUSE Linux Enterprise 15.0 und ISC DHCP 4.3.x treten unter bestimmten Umständen Fehler beim PXE-Boot und den AutoYaST-Installationen auf. Die PXE/AutoYaST-Installationen funktionieren nicht, wenn Ihr DHCP-Server keinen Pool von verfügbaren dynamischen IP-Adressen enthält und nur vordefinierte statische Adressen pro Client zulässt, und die Clients RFC 4361-Client-Kennungen senden. (Zufällig ausgewählte Rechner können dem Netzwerk nicht beitreten, wenn nur Adressen zugelassen werden, die bestimmten Netzwerk-Clients zugewiesen sind, und wenn keine dynamischen Adressenpools zur Verfügung gestellt werden.)

Wenn ein neues System in PXE startet, sendet es eine Anforderung an den DHCP-Server und erkennt sich selbst anhand einer Client-Kennung, die aus dem Hardwaretyp plus der MAC-Adresse der Netzwerkschnittstelle erstellt wurde. Dies ist eine RFC 2132 client-id. Der DHCP-Server bietet dann die zugewiesene IP-Adresse an. Als nächstes wird der Installations-Kernel geladen und er sendet eine weitere DHCP-Anforderung. Doch diese client-id ist anders und wird im RFC 4361-Format gesendet. Der DHCP-Server erkennt sie nicht als denselben Client und sucht nach einer freien dynamischen IP-Adresse. Da diese nicht verfügbar ist, wird der Installationsvorgang angehalten.

Die Lösung besteht darin, Clients so zu konfigurieren, dass sie RFC 2132-Client-IDs senden. Verwenden Sie zum Senden einer RFC 2132 client-id während der Installation linuxrc, um das folgende ifcfg-Kommando weiterzugeben:

ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67,
DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67

Die üblicherweise verwendete RFC 2132 DHCPv4 client-id im Ethernet setzt sich aus dem Hardwaretyp (01 für Ethernet) gefolgt von der Hardwareadresse (der MAC-Adresse) zusammen, wie zum Beispiel:

01:52:54:00:02:c2:67

Die RFC 4361 DHCPv4 client-id versucht das Problem, einen Rechner mit mehr als einer Netzwerkschnittstelle zu erkennen, zu korrigieren. Die neue DHCPv4 client-id hat dasselbe Format wie die DHCPv6 client-id. Sie beginnt mit dem Präfix 0xff anstelle des Hardwaretyps, gefolgt von der DHCPv6 IAID (der ID der Schnittstellenadressverknüpfung, die die Schnittstelle am Rechner beschreibt), gefolgt von der eindeutigen DHCPv6-Kennung (DUID), mit der der Rechner eindeutig gekennzeichnet ist.

Mit der oben genannten DUID auf Basis des Hardwaretyps und der Hardwareadresse wäre die neue RFC 4361 DHCPv4 client-id:

Das Feld xx:xx:xx:xx im DUID-Link-Layer-Zeitstempel (DUID-LLT) ist ein Erstellungszeitstempel. Ein DUID-Link-Layer (DUID-LL) (00:03:00:01:$MAC) hat keinen Zeitstempel.

Weitere Informationen zur Verwendung vonlinuxrc finden Sie im AutoYaST-Handbuch. Sehen Sie sich dazu auch man 4 initrd und die Dokumentation für die Optionen dhcp4 "create-cid", dhcp6 "default-duid" in man 5 wicked-config, wicked duid --help und wicked iaid --help an.

So installieren Sie einen TFTP-Server:

SUSE Linux Enterprise Server stellt die erforderlichen Dateien zum Booten über PXE auf BIOS- oder UEFI-Rechnern bereit. Die folgenden Hardwarearchitekturen werden unterstützt:

Dateien, die von einer bestimmten Hardwarearchitektur gebootet werden müssen, sind in einem RPM-Paket enthalten. Installieren Sie die Dateien auf dem Rechner, auf dem der TFTP-Server ausgeführt wird:

tux > sudo zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE

Ersetzen Sie OS_VERSION durch die Versionsnummer Ihrer SUSE Linux Enterprise Server-Installation (z. B. SLE-15-SP3-x86_64) und ARCHITECTURE durch die Architektur Ihres Systems (z. B. x86_64). Der resultierende Text würde folgendermaßen aussehen: tftpboot-installation-SLE-15-SP3-x86_64. Führen Sie zypper se tftpboot zum Suchen nach allen verfügbaren Versionen und Architekturen aus.

Die Dateien werden unter /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE installiert. Sie können auch die Dateien für andere Versionen und Architekturen von SUSE Linux Enterprise Server in das Verzeichnis /srv/tftpboot kopieren.

Tipp: Bedienen verschiedener Architekturen

Die Hardwarearchitektur von Client und Server kann variieren. Sie können beispielsweise einen AMD64/Intel 64 TFTP-Server ausführen und eine bootfähige Umgebung für AArch64-Clientrechner bereitstellen, indem Sie das Paket tftpboot-installation-SLE-15-SP3-aarch64 Paket verfügbar ist.

Anmerkung: Bestehendes /srv/tftpboot/-Verzeichnis

Wenn das Verzeichnis /srv/tftpboot/ bereits auf Ihrem Rechner vorhanden ist, werden alle Dateien im Pfad /usr/share/tftpboot-installation/ installiert. Dies ist der Fall, wenn Sie Ihren PXE-Server von einer früheren SLES-Version upgraden.

Kopieren Sie die Dateien manuell von /usr/share/tftpboot-installation/ zu /srv/tftpboot/, um dieses Problem zu beheben. Entfernen Sie alternativ /srv/tftpboot/ und installieren Sie das Paket tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE Paket verfügbar ist.

Öffnen Sie die Datei /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default in einem Editor. Ersetzen Sie den Pfad für den Parameter install gemäß Ihrer Einrichtung (siehe Kapitel 16, Einrichten einer Netzwerkinstallationsquelle). Ersetzen Sie außerdem TFTP_SERVER durch die IP-Adresse des TFTP-Servers. Einen Überblick über die PXELINUX-Konfigurationsoptionen finden Sie in Abschnitt 17.3, „PXELINUX-Konfigurationsoptionen“.

default linux

# install
label linux
  ipappend 2
  kernel boot/ARCHITECTURE/loader/linux
  append initrd=boot/ARCHITECTURE/loader/initrd instsys=tftp://TFTP_SERVER/SLE-OS_VERSION-ARCHITECTURE/boot/ARCHITECTURE/root install=PROTOCOL://SERVER_IP:/PATH

display  message
implicit 1
prompt  1
timeout  50

Weitere Informationen zu den Boot-Parametern in der Zeile append finden Sie in Abschnitt 7.3, „Liste wichtiger Boot-Parameter“.

Wenn eine Meldung im Boot-Menü angezeigt werden soll, bearbeiten Sie gegebenenfalls /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message.

Normalerweise müssen die GRUB2-Konfigurationsdateien nicht geändert werden. Die Standardeinstellungen enthalten jedoch keine Netzwerkressource für das Installationssystem. Für eine vollständige Installation von SUSE Linux Enterprise Server über das Netzwerk müssen Sie den Parameter install in der Anweisung linuxefi der Datei /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg angeben. In Abschnitt 7.3.3, „Angeben der Installationsquelle“ finden Sie weitere Informationen über den Parameter install.

WOL funktioniert sowohl mit kabelgebundenen als auch mit drahtlosen Ethernet-Karten, die es unterstützen.

Möglicherweise müssen Sie WOL in Ihrem System-BIOS/UEFI aktivieren.

Überprüfen Sie Ihre BIOS/UEFI-Einstellungen für PXE-Boot und stellen Sie sicher, dass es deaktiviert ist, um versehentliche Neuinstallationen zu verhindern.

Passen Sie Ihre Firewall so an, dass der Datenverkehr über UDP-Port 9 zugelassen wird.

Führen Sie folgendes Kommando aus, um festzustellen, ob eine kabelgebundene Ethernet-Schnittstelle WOL unterstützt:

tux > sudo ethtool eth0 | grep -i wake-on
Supports Wake-on: pumbg
Wake-on: g

Die Ausgabe im Beispiel zeigt, dass WOL von eth0 unterstützt wird, angezeigt durch das g-Flag in der Zeile Supports Wake-on. Wake-on: g zeigt an, dass WOL bereits aktiviert ist, sodass diese Schnittstelle bereit ist, Aktivierungssignale zu empfangen. Wenn WOL nicht aktiviert ist, aktivieren Sie es mit folgendem Kommando:

tux > sudo ethtool -s eth0 wol g

Für Wakeup-over-wifi (WoWLAN) ist eine drahtlose Netzwerkschnittstelle erforderlich, die WoWLAN unterstützt. Testen Sie dies mit dem Kommando iw, das im iw Paket verfügbar ist:

tux > sudo zypper in iw

Suchen Sie den Gerätenamen:

tux > sudo iw dev
phy#0
        Interface wlan2
                ifindex 3
                wdev 0x1
                addr 9c:ef:d5:fe:01:7c
                ssid accesspoint
                type managed
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 20.00 dBm

In diesem Beispiel lautet der Gerätename zum Abfragen der WoWLAN-Unterstützung phy#0. Dieses Beispiel zeigt, dass es nicht unterstützt wird:

tux > sudo iw phy#0 wowlan show
command failed: Operation not supported (-95)

Dieses Beispiel zeigt eine Schnittstelle, die WoWLAN unterstützt, aber nicht aktiviert ist:

tux > sudo iw phy#0 wowlan show
WoWLAN is disabled

Aktivieren Sie sie:

tux > sudo iw phy#0 wowlan enable magic-packet
WoWLAN is enabled:
* wake up on magic packet

Installieren Sie zur Verwendung von WOL das Paket wol am Client und den sendenden Rechnern:

tux > sudo zypper in wol

Installieren Sie wol-udev-rules auf Ihren Client-Rechnern. Dieses Paket installiert eine udev-Regel, die WOL automatisch beim Start aktiviert.

Ermitteln Sie die MAC-Adresse der Netzwerkschnittstelle auf dem Client-Rechner:

tux > sudo ip addr show eth0|grep ether
link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff

In der Ausgabe des Beispiels ist 7c:ef:a5:fe:06:7c die MAC-Adresse.

Fahren Sie Ihren Client-Rechner herunter und senden Sie ihm ein Aktivierungssignal von einem anderen Rechner im selben Teilnetz:

tux > wol 7c:ef:a5:fe:06:7c

Wenn sich Ihr Zielgerät und das zweite Gerät zwar im selben Netzwerk, aber in unterschiedlichen Teilnetzen befinden, geben Sie die Broadcast-Adresse für Ihr Zielgerät an:

tux > wol -i 192.168.0.63 7c:ef:a5:fe:06:7c

Da WOL auf Broadcast-Domänen beruht, muss sich der sendende Rechner im selben Netzwerk befinden, kann aber auch in einem anderen Netzwerksegment liegen.

Es ist möglich, das Magic Packet von einem anderen Netzwerk aus zu senden. Eine Möglichkeit ist die Portweiterleitung, wenn Ihr Router die Portweiterleitung auf eine Broadcast-Adresse unterstützt. Eine sicherere Methode ist es, sich über SSH mit einem Host innerhalb Ihres Netzwerks zu verbinden und das Magic Packet von dort aus zu senden.