17 Vorbereiten der Netzwerk-Boot-Umgebung #
In diesem Kapitel wird beschrieben, wie Sie einen DHCP- und einen TFTP-Server konfigurieren, die die erforderliche Infrastruktur für das Booten über PXE bilden.
SUSE® Linux Enterprise Server kann über PXE (Preboot Execution Environment) installiert werden. Die Client-Hardware muss das Booten über PXE unterstützen. Das Netzwerk muss einen DHCP-Server und einen TFTP-Server umfassen, die den Clients die erforderlichen Daten bereitstellen. Dieses Kapitel führt Sie durch die Einrichtung der erforderlichen Server.
Mit PXE werden lediglich ein Kernel und initrd gebootet. Hiermit können Sie in eine Installationsumgebung oder in Live-Systeme booten. Weitere Informationen zum Einrichten der Installationsquellen finden Sie in Kapitel 16, Einrichten einer Netzwerkinstallationsquelle.
In diesem Abschnitt werden die für komplexe Boot-Szenarien erforderlichen Konfigurationsschritte beschrieben. Er enthält zudem Konfigurationsbeispiele für DHCP, PXE-Boot, TFTP und Wake-on-LAN.
Bei den Beispielen wird davon ausgegangen, dass sich der DHCP-, TFTP- und NFS-Server auf demselben Rechner mit IP 192.168.1.1
befinden. Alle Dienste können sich problemlos auf verschiedenen Rechnern befinden. Ändern Sie die IP-Adressen in jedem Fall entsprechend.
17.1 Einrichten eines DHCP-Servers #
Ein DHCP-Server weist Ihren Netzwerk-Clients sowohl dynamische (Abschnitt 17.1.1, „Dynamische Adressenzuweisung“) als auch statische (Abschnitt 17.1.2, „Zuweisen von statischen IP-Adressen“) IP-Adressen zu. Er gibt Server, Routen und Domänen bekannt. Für TFTP-Server gibt DHCP auch den Kernel und die initrd-Dateien an. Welche Dateien geladen werden hängt von der Architektur des Zielrechners ab und davon, ob Legacy-BIOS oder UEFI-Boot verwendet wird. Die Clients übermitteln ihren Architekturtyp in den DHCP-Anforderungen. Auf der Grundlage dieser Information entscheidet der DHCP-Server, welche Dateien der Client zum Booten herunterladen muss.
Ab SUSE Linux Enterprise 15.0 treten unter bestimmten Umständen Fehler beim PXE-Boot und den AutoYaST-Installationen auf. Weitere Informationen und die Lösung finden Sie in Abschnitt 17.1.3, „Fehler bei der PXE- und AutoYaST-Installation“.
17.1.1 Dynamische Adressenzuweisung #
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.
Melden Sie sich als
root
auf dem Computer an, der den DHCP-Server bereitstellt.Aktivieren Sie den DHCP-Server mit
systemctl enable dhcpd
.Fügen Sie einer Subnetzkonfiguration in der Konfigurationsdatei des DHCP-Servers, die sich unter
/etc/dhcpd.conf
befindet, folgende Zeilen hinzu:# The following lines are optional option domain-name "my.lab"; option domain-name-servers 192.168.1.1; option routers 192.168.1.1; option ntp-servers 192.168.1.1; ddns-update-style none; default-lease-time 3600; # The following lines are required option arch code 93 = unsigned integer 16; # RFC4578 subnet 192.168.1.0 netmask 255.255.255.0 { next-server 192.168.1.1; range 192.168.1.100 192.168.1.199; default-lease-time 3600; max-lease-time 3600; if option arch = 00:07 or option arch = 00:09 { filename "/EFI/x86/grub.efi"; } else if option arch = 00:0b { filename "/EFI/aarch64/bootaa64.efi"; } else { filename "/BIOS/x86/pxelinux.0"; } }
Diese Konfiguration verwendet das Teilnetz
192.168.1.0/24
mit DHCP, DNS und dem Gateway am Server mit der IP192.168.1.1
. Vergewissern Sie sich, dass alle IP-Adressen gemäß Ihres Netzwerk-Layouts geändert wurden. Weitere Informationen zu den inverfügbaren Optionen finden Sie auf der man-Seite
dhcpd.conf
dhcpd.conf.Starten Sie den DHCP-Server mit
systemctl restart dhcpd
neu.
17.1.2 Zuweisen von statischen IP-Adressen #
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.
17.1.3 Fehler bei der PXE- und AutoYaST-Installation #
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
:
Unter Verwendung der letzten Bytes der MAC-Adresse der IAID:
ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
Wenn die IAID eine einfache inkrementierte Zahl ist:
ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
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.
17.2 Einrichten eines TFTP-Servers #
Im folgenden Verfahren wird beschrieben, wie der Server so vorbereitet wird, dass die Client-Rechner mit UEFI und BIOS dezentral mit den durch TFTP exportierten Dateien gebootet werden können.
17.2.1 Installieren eines TFTP-Servers #
So installieren Sie einen TFTP-Server:
Installieren Sie das Paket
tftp
.>
sudo
zypper in tftp
Überprüfen Sie die
tftpd
-Konfiguration unter/etc/sysconfig/tftp
und ergänzen oder ändern Sie die Optionen je nach Bedarf. Weitere Informationen finden Sie unterman 8 tftpd
. Beim TFTP-Daemon muss die Konfiguration nicht geändert werden. Das Standard-Stammverzeichnis für die Dateien lautet/srv/tftpboot
.tftpd
muss beim Booten gestartet werden; starten Sie es zum Einlesen der neuen Konfiguration erneut.>
sudo
systemctl enable tftp.socket
>
sudo
systemctl restart tftp.socket
17.2.2 Installieren der Dateien zum Booten #
SUSE Linux Enterprise Server stellt die erforderlichen Dateien zum Booten über PXE auf BIOS- oder UEFI-Rechnern bereit. Die folgenden Hardwarearchitekturen werden unterstützt:
AMD64/Intel 64
AArch64
POWER
IBM Z
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:
>
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.
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 installieren.
/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.
17.2.3 Konfigurieren von PXELINUX #
Ö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
.
17.2.4 Vorbereiten des PXE-Boot-Vorgangs für EFI mit GRUB2 #
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
.
17.3 PXELINUX-Konfigurationsoptionen #
Die hier aufgeführten Optionen sind eine Teilmenge der für die PXELINUX-Konfigurationsdatei verfügbaren Optionen.
APPEND OPTIONEN
Fügt der Kernel-Kommandozeile eine oder mehrere Optionen hinzu. Diese werden sowohl bei automatischen als auch bei manuellen Bootvorgängen hinzugefügt. Die Optionen werden an den Beginn der Kernel-Kommandozeile gesetzt und ermöglichen, dass explizit eingegebene Kernel-Optionen sie überschreiben können.
APPEND -
Hiermit wird nichts angehängt.
APPEND
mit einem Bindestrich als Argument in einemLABEL
-Abschnitt kann zum Überschreiben einer globalenAPPEND
-Option verwendet werden.DEFAULT KERNEL_OPTIONEN...
Legt die standardmäßige Kernel-Kommandozeile fest. Wenn PXELINUX automatisch gebootet wird, agiert es, als wären die Einträge nach DEFAULT in der Booteingabeaufforderung eingegeben worden, außer, dass die Option für das automatische Booten (boot) automatisch hinzugefügt wird.
Wenn keine Konfigurationsdatei vorhanden oder der DEFAULT-Eintrag in der Konfigurationsdatei nicht definiert ist, wird standardmäßig der Kernel-Name „linux“ ohne Optionen verwendet.
IFAPPEND FLAG
Fügt eine bestimmte Option in die Kernel-Kommandozeile ein, abhängig vom Wert für FLAG. Die Option
IFAPPEND
ist nur unter PXELINUX verfügbar. Für FLAG ist ein Wert erforderlich, siehe Tabelle 17.1, „Generierte und hinzugefügte Optionen für Kernel-Kommandozeilen vonIFAPPEND
“:Tabelle 17.1: Generierte und hinzugefügte Optionen für Kernel-Kommandozeilen vonIFAPPEND
#Argument
Generierte Kernel-Kommandozeile/Beschreibung
1
ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK
Die Platzhalter werden auf der Grundlage der Eingaben vom DHCP/BOOTP- oder PXE-Boot-Server ersetzt.
Diese Option ist kein Ersatz für das Ausführen eines DHCP-Clients im gebooteten System. Ohne regelmäßige Verlängerung läuft die vom PXE BIOS erworbene Lease ab, sodass die IP-Adresse zur erneuten Verwendung durch den DHCP-Server verfügbar wird.
2
BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE
Mit dieser Option lässt sich eine Zeitüberschreitung vermeiden, wenn der Installationsserver die LAN-Schnittstellen einzeln nacheinander abfragt, bis er eine Antwort von einem DHCP-Server erhält. Ein initrd-Programm kann dabei ermitteln, von welcher Schnittstelle das System gebootet wurde. linuxrc liest diese Option aus und verwendet die erkannte Netzwerkschnittstelle.
4
SYSUUID=SYSTEM_UUID
Fügt UUIDs im Hexadezimalformat mit Kleinbuchstaben hinzu, siehe
/usr/share/doc/packages/syslinux/pxelinux.txt
LABEL KENNUNG KERNEL IMAGE APPEND OPTIONEN...
Wenn KENNUNG als der zu bootende Kernel angegeben wird, soll PXELINUX stattdessen IMAGE booten und dabei die angegebenen
APPEND
-Optionen heranziehen. Diese Optionen ersetzen die im globalen Abschnitt der Datei vor dem ersten KommandoLABEL
angegebenen Optionen. Die Vorgabe für IMAGE ist dieselbe wie für KENNUNG und wenn keineAPPEND
-Optionen angegeben sind, wird standardmäßig der globale Eintrag verwendet (sofern vorhanden). Es sind bis zu 128LABEL
-Einträge zulässig.PXELINUX verwendet die folgende Syntax:
label MYLABEL kernel MYKERNEL append MYOPTIONS
Kennungen werden wie Dateinamen umgesetzt und müssen nach der Umsetzung (sogenanntes Mangling) eindeutig sein. Die beiden Kennungen „v2.6.30“ und „v2.6.31“ wären beispielsweise unter PXELINUX nicht unterscheidbar, da beide auf denselben DOS-Dateinamen umgesetzt würden.
Der Kernel muss kein Linux-Kernel sein. Auch ein Bootsektor oder eine COMBOOT-Datei ist möglich.
LOCALBOOT TYP
Wenn Sie unter PXELINUX
LOCALBOOT 0
an Stelle einerKERNEL
-Option angeben, bedeutet dies, dass diese bestimmte Kennung aufgerufen und die lokale Festplatte an Stelle eines Kernels gebootet wird.Argument
Beschreibung
0
Führt einen normalen Bootvorgang aus
4
Führt einen lokalen Bootvorgang mit dem noch im Arbeitsspeicher vorhandenen UNDI-Treiber (Universal Network Driver Interface) aus
5
Führt einen lokalen Bootvorgang mit dem gesamten PXE-Stack, einschließlich des UNDI-Treibers aus, der sich im Arbeitsspeicher befindet
Alle anderen Werte sind nicht definiert. Wenn Sie die Werte für die UNDI- oder PXE-Stacks nicht wissen, geben Sie
0
an.TIMEOUT ZEITLIMIT
Gibt in Einheiten von 1/10 Sekunde an, wie lange die Booteingabeaufforderung angezeigt werden soll, bevor der Bootvorgang automatisch gestartet wird. Das Zeitlimit wird aufgehoben, sobald der Benutzer eine Eingabe über die Tastatur vornimmt, da angenommen wird, dass der Benutzer die Eingabe des Kommandos abschließt. Mit einem Zeitlimit von Null wird das Zeitüberschreitungsoption deaktiviert (dies ist die Vorgabe). Der größtmögliche Wert für das Zeitlimit ist 35996 (etwas weniger als eine Stunde).
PROMPT flag_val
Wenn
flag_val
auf 0 gesetzt ist, wird die Booteingabeaufforderung nur angezeigt, wenn die Taste Umschalttaste oder Alt gedrückt wird oder die Feststelltaste oder die Taste Rollen gesetzt ist (dies ist die Standardeinstellung). Wennflag_val
1 ist, wird die Booteingabeaufforderung immer angezeigt.F2 FILENAME F1 FILENAME ..etc.. F9 FILENAME F10 FILENAME
Zeigt die angegebene Datei auf dem Bildschirm an, wenn an der Booteingabeaufforderung eine Funktionstaste gedrückt wird. Mithilfe dieser Option kann auch die Preboot-Online-Hilfe implementiert werden (für die Kernel-Kommandozeilenoptionen). Aus Gründen der Kompabilität mit früheren Versionen kann F10 auch als
F0
verwendet werden. Beachten Sie, dass derzeit keine Möglichkeit besteht, Dateinamen an F11 und F12 zu binden.
17.4 Vorbereiten des Zielsystems für PXE-Boot #
Bereiten Sie das System-BIOS für PXE-Boot vor, indem Sie die PXE-Option in die BIOS-Boot-Reihenfolge aufnehmen.
Die PXE-Option darf im BIOS nicht vor dem Boot-Parameter für die Festplatte stehen. Andernfalls würde dieses System versuchen, sich selbst bei jedem Booten neu zu installieren.
17.5 Verwenden von Wake-on-LAN für Fernaktivierungen #
Wake-on-LAN (WOL) ist ein Ethernet-Standard zum Fernaktivieren eines Rechners durch Senden eines Aktivierungssignals über ein Netzwerk. Dieses Signal wird „Magic Packet“ genannt. Installieren Sie WOL auf Client-Rechnern, um Fernaktivierungen zu ermöglichen, und auf jedem Rechner, den Sie zum Senden des Aktivierungssignals verwenden möchten. Das Magic Packet wird über UDP-Port 9 an die MAC-Adresse der Netzwerkschnittstelle auf dem Client-Rechner gesendet.
Beim Herunterfahren werden Rechner in der Regel nicht ganz ausgeschaltet, sondern verbleiben in einem Energiesparmodus. Wenn die Netzwerkschnittstelle WOL unterstützt, überwacht sie auf das Aktivierungssignal des Magic Packet, wenn das Gerät ausgeschaltet ist. Sie können das Magic Packet manuell senden oder Aktivierungen in einem Cron auf dem sendenden Rechner planen.
17.5.1 Voraussetzungen #
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.
17.5.2 Überprüfen der Unterstützung von kabelgebundenem Ethernet #
Führen Sie folgendes Kommando aus, um festzustellen, ob eine kabelgebundene Ethernet-Schnittstelle WOL unterstützt:
>
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:
>
sudo
ethtool -s eth0 wol g
17.5.3 Überprüfen der Unterstützung für drahtlose Schnittstellen #
Für Wakeup-over-wifi (WoWLAN) ist eine drahtlose Netzwerkschnittstelle erforderlich, die WoWLAN unterstützt. Testen Sie dies mit dem Kommando iw
, das im Paket iw enthalten ist:
>
sudo
zypper in iw
Suchen Sie den Gerätenamen:
>
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:
>
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:
>
sudo
iw phy#0 wowlan show WoWLAN is disabled
Aktivieren Sie sie:
>
sudo
iw phy#0 wowlan enable magic-packet WoWLAN is enabled: * wake up on magic packet
17.5.4 Installieren und Testen von WOL #
Zur Verwendung von WOL installieren Sie das Paket wol auf dem Client und den sendenden Rechnern:
>
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:
>
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:
>
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:
>
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.