Netboot-Produkte
Netboot-Produkte können unabhängig vom installierten Betriebssystem verwendet werden und bieten dadurch maximale Flexibilität für verschiedene Einsatzszenarien. Typische Anwendungsfälle sind die Neuinstallation von Betriebssystemen, Diagnosezwecke oder Wartungsarbeiten. In der Regel erfolgt die Ausführung über das opsi-linux-bootimage – eine speziell für opsi entwickelte und angepasste Linux-Distribution. Als Bootloader kommt GRUB2 zum Einsatz. Für den Secure-Boot-Betrieb wird eine shim verwendet.
Standardmäßig wird das opsi-linux-bootimage per PXE-Boot gestartet. Alternativ steht eine ISO-Datei zur Verfügung, die von CD oder USB-Stick gebootet werden kann. Dadurch können Netboot-Produkte auch in Umgebungen genutzt werden, in denen PXE nicht verfügbar ist.
Netboot-Produkte können auch eigene Boot-Images bereitstellen, die ebenfalls per PXE gestartet werden. Beispiele hierfür sind MemDisk oder das Sicherheitstool Desinfec’t.
Die Steuerung des PXE-Boots übernimmt der Dienst opsipxeconfd auf dem opsi-Depotserver. Zusätzlich werden ein DHCP-Server und ein TFTP-Server benötigt.
Konfiguration der Netboot-Umgebung
Die Netboot-Umgebung wird hauptsächlich über Host-Parameter mit dem Präfix netboot.
konfiguriert.
Diese Parameter können Depot-weit (für alle Clients eines Depots) oder Client-bezogen (nur für einen bestimmten Client) gesetzt werden.
Client-spezifische Einstellungen greifen aktuell nur, wenn für den Client eine Aktion für ein Netboot-Produkt gesetzt ist. |
Wichtige Host-Parameter für das Verhalten beim Netboot:
netboot.use_host_onetime_password
-
Beim Netzwerk-Boot authentifiziert sich der Client am opsi-Service. Standardmäßig wird hierfür der opsi-Host-Key genutzt. Ist dieser Parameter auf
true
gesetzt, wird stattdessen ein einmaliges Passwort verwendet, was die Sicherheit erhöht. netboot.host_identifiers
-
Legt fest, wie Clients beim Netzwerk-Boot identifiziert werden. Mögliche Werte sind:
-
mac_address
(MAC-Adresse der Netzwerkkarte) -
system_uuid
(System-UUID des Clients)
-
Beide Werte können kombiniert werden. Je nach Auswahl wird im Boot-Verzeichnis eine Konfigurationsdatei erstellt, die entweder auf der System-UUID oder der MAC-Adresse basiert.
netboot.grub.additional_menu_entries
-
Ermöglicht das Hinzufügen weiterer Menüeinträge zu GRUB2.
netboot.grub.graphicsmode
-
Aktiviert oder deaktiviert den Grafikmodus von GRUB2.
netboot.grub.password
-
Legt ein Passwort für den Zugriff auf das GRUB2-Menü fest. Der Benutzername ist immer
admin
. Das Passwort kann im Klartext oder als Hash angegeben werden (grub.pbkdf2.sha512.10000.<salt>.<hash-value>
). Hashwerte lassen sich zum Beispiel mitgrub-mkpasswd-pbkdf2
erzeugen. netboot.grub.timeout
-
Legt fest, wie viele Sekunden das GRUB2-Menü angezeigt wird, bevor automatisch der Standard-Eintrag gestartet wird (sofern keine Aktion für ein Netboot-Produkt gesetzt ist).
Parameter für das Linux-Bootimage
Alle Parameter mit dem Präfix netboot.opsi-linux-bootimage.cmdline.
werden als Kernel-Parameter an das opsi-linux-bootimage übergeben.
Dabei können sowohl reguläre Linux-Kernel-Parameter als auch spezielle, vom opsi-linux-bootimage unterstützte Parameter verwendet werden.
Es gibt zwei Typen von Host-Parametern:
- Boolesche Host-Parameter
-
Diese dienen als Flags. Sie werden der Kernel-Commandline hinzugefügt, wenn sie auf
true
gesetzt sind. Beifalse
werden sie nicht übergeben. - String-Host-Parameter
-
Diese werden als
<Parametername>=<Wert>
an die Kernel-Commandline übergeben. Mehrere Werte werden durch Kommata getrennt. Ist kein Wert gesetzt, wird der Parameter nicht übergeben.
Weitere Kernel-Parameter können jederzeit ergänzt werden, indem entsprechende Host-Parameter mit dem Präfix netboot.opsi-linux-bootimage.cmdline.
definiert werden.
Wichtige Kernel-Parameter im Zusammenhang mit opsi:
hn
-
Setzt den Hostnamen des Systems.
dn
-
Setzt den Domainnamen.
host_id
-
Setzt die opsi-Host-ID des Systems.
service
-
Adresse des opsi-Service, zu dem eine Verbindung hergestellt werden soll.
pckey
-
opsi-Host-Key für die Authentifizierung.
otp
-
Einmal-Passwort für die Authentifizierung (Alternative zu pckey).
opsi_ui
-
Auswahl der opsi-Benutzeroberfläche (splash oder tui). Standard ist splash.
lang
-
Setzt die Systemsprache. Format:
<Sprache>[_Region][.Zeichensatz]
(z. B.de
,de_DE
,de_DE.UTF8
). tz
-
Setzt die Zeitzone, z. B.
Europe/Berlin
(Standard istUTC
). pwh
-
Passwort oder Passwort-Hash für den Root-Benutzer (
$<hash-type>$<salt>$<hash>
). macaddress
-
Weist dem Netzwerkgerät eine benutzerdefinierte MAC-Adresse zu.
nodhcp
-
Deaktiviert die DHCP-Konfiguration für Netzwerkgeräte.
dhcp_identifier
-
Bestimmt den DHCPv4-Client-Identifier (
mac
oderduid
). Standard istmac
. ssh
-
Startet beim Booten den SSH-Dienst.
splash
-
Aktiviert den grafischen Splash-Screen während des Bootens.
tcpdump
-
Aktiviert die Netzwerk-Paketaufzeichnung in
/tmp/tcpdump.pcap
. Zusätzliche Optionen werden als Argumente an tcpdump übergeben. opsi_loglevel
-
Setzt das opsi-Loglevel (0-9).
product
-
Gibt die ID des Netboot-Produkts an, das verarbeitet werden soll.
ask_conf
-
Fordert den Benutzer interaktiv zur Bestätigung von Konfigurationswerten auf.
Weitere relevante Kernel-Parameter:
quiet
-
Unterdrückt die meisten Kernel- und Systemmeldungen während des Bootens.
loglevel
-
Setzt das Kernel-Loglevel (0-7).
video
-
Konfiguriert den Framebuffer.
vga
-
Legt VGA-Auflösung und Farbtiefe fest.
noapic
-
Deaktiviert den I/O-APIC (I/O Advanced Programmable Interrupt Controller).
irqpoll
-
Aktiviert IRQ-Polling für problematische Hardware.
pci
-
Optionen für das PCI-Subsystem.
mem
-
Legt die vom Kernel zu nutzende Speichermenge fest.
acpi
-
Steuert das Verhalten des ACPI-Subsystems.
reboot
-
Gibt die Methode für den Neustart an.
efi_no_storage_paranoia
-
Deaktiviert die Sicherheitsprüfung für reservierten Speicherplatz im EFI-NVRAM (standardmäßig 5120 Byte unter Linux 6.14.0). Achtung: Dieser Parameter sollte nur verwendet werden, wenn sichergestellt ist, dass die Firmware eine ordnungsgemäße Speicherbereinigung gemäß UEFI-Spezifikation durchführt. Andernfalls besteht die Gefahr, dass das Mainboard unbrauchbar wird.
Debugging und Fehlerbehebung beim Booten
Da beim Booten eines Netboot-Produkts mehrere Services und Komponenten zusammenarbeiten, können Probleme an verschiedenen Stellen auftreten. Prüfen Sie zunächst, ob Sie die aktuellsten Versionen der opsi-Komponenten verwenden.
DHCP
Der DHCP-Server weist den Clients IP-Adressen und weitere Netzwerkkonfigurationsparameter zu. Zusätzlich übermittelt er die Informationen zum Boot-Server und zur Boot-Datei, die für den PXE-Boot benötigt werden. Im Kapitel DHCP Troubleshooting finden Sie Hinweise zur Fehlersuche bei DHCP-Problemen.
TFTP
Der TFTP-Server stellt die Boot-Dateien bereit, die der Client zum Starten benötigt. In der Regel läuft der TFTP-Server auf dem opsi-Depotserver. Im Kapitel TFTP-Troubleshooting finden Sie Hinweise zur Fehlersuche bei TFTP-Problemen.
GRUB2
GRUB2 ist der von opsi verwendete Bootloader. Sollte der Bootvorgang an dieser Stelle fehlschlagen, prüfen Sie folgende Punkte:
-
Gibt es eine aktuellere BIOS- oder UEFI-Firmware für das Gerät?
-
Ist die Firmware korrekt konfiguriert (z.B. Boot-Reihenfolge, Secure Boot-Einstellungen)?
-
Funktioniert das Booten mit deaktiviertem Secure Boot?
-
Schalten Sie den Grafikmodus von GRUB2 aus (Host-Parameter
netboot.grub.graphicsmode
auf false setzen). -
Testen Sie das Booten des opsi-linux-bootimage über USB-Stick oder CD.
Es steht auch eine Debug-Version von GRUB2 zur Verfügung.
Diese gibt während des Bootvorgangs ausführlichere Informationen aus und setzt den Ablauf nicht automatisch fort.
Die Debug-Varianten befinden sich unter <boot>/opsi/loader/grub-debug.<arch>.<efi|bios>
und können entweder über angepasste Symlinks oder durch entsprechende Einstellungen in der DHCP-Konfiguration des Clients genutzt werden.
opsi-linux-bootimage
Scheitert der Bootvorgang beim Start des opsi-linux-bootimage, prüfen Sie folgende Punkte:
-
Deaktivieren Sie den quiet-Mode und den Splash-Screen (Host-Parameter
netboot.opsi-linux-bootimage.cmdline.quiet
undnetboot.opsi-linux-bootimage.cmdline.splash
auf false setzen). -
Erhöhen Sie das Log-Level des Linux-Kernels (Host-Parameter
netboot.opsi-linux-bootimage.cmdline.loglevel
auf 7 setzen). -
Testen Sie das Booten mit verschiedenen Kernel-Parametern (z.B.
acpi=off
,noapic
,irqpoll
,pci=nomsi
,mem=2G
).
Um sich am laufenden Bootimage anzumelden, können Sie auf eines der TTYs 3-6 wechseln (z.B. mit Ctrl
`Alt`F3
).
Melden Sie Sich mit dem Benutzernamen root
und dem Passwort an, das im Host-Parameter netboot.opsi-linux-bootimage.cmdline.pwh
gesetzt ist.
Das Systemlog können Sie mit dem Befehl journalctl
anzeigen.
Das Kernel-Log ist über dmesg
verfügbar.
Um den Status des Netzwerks zu analysieren, können Sie die beispielsweise die Kommandos networkctl status --all
, ip l
und ip a
verwenden.
Tritt der Fehler erst bei Verarbeitung des Netboot-Produkts auf, können Sie die Log-Datei des Bootimages prüfen.
Diese befindet sich unter /tmp/log
im laufenden Bootimage.
Wenn möglich, wird die Log-Datei auch auf den opsi-Configserver übertragen und ist dann z. B. über den opsi-configed einsehbar.
Bei bestehender opsi-Messagebus-Verbindung können Sie über opsi-Configed oder opsi-cli ein Terminal auf dem Client öffnen.
Auch über SSH ist ein Zugriff möglich.
Dafür muss der Parameter netboot.opsi-linux-bootimage.cmdline.ssh
auf true
gesetzt sein.
Der Benutzername für den SSH-Zugriff ist root
.
Als Passwort wird das unter netboot.opsi-linux-bootimage.cmdline.pwh
gesetzte Passwort verwendet.
Spezielle PXE-Boot-Konfigurationen
Standardmäßig werden Netboot-Produkte über das opsi-linux-bootimage ausgeführt. Es besteht jedoch auch die Möglichkeit, eigene Boot-Images einzubinden, indem eine individuelle PXE-Boot-Konfiguration erstellt wird.
Dazu kann das Attribut pxeConfigTemplate
in den Metadaten des Netboot-Produkts verwendet werden.
In diesem Attribut lässt sich ein GRUB2-Konfigurations-Template hinterlegen, das beim Start des Netboot-Produkts automatisch in die GRUB2-Konfiguration eingebunden wird.
Die Templates basieren auf Jinja2 und können auf verschiedene Variablen zugreifen, unter anderem:
host
-
Das Host-Objekt des Clients. Alle Attribute sind verfügbar, z. B.
host.id
,host.description
,host.hardwareAddress
,host.systemUUID
. product
-
Das Product-Objekt des Netboot-Produkts. Verfügbare Attribute sind u. a.
product.id
,product.name
,product.description
. product_on_depot
-
Das zugehörige ProductOnDepot-Objekt.
product_on_client
-
Das zugehörige ProduktOnClient-Objekt.
product_property_states
-
Die ProductPropertyState-Objekte des Produkts für den Client als Dictionary. Der Zugriff erfolgt über
product_property_states["<property_id>"]
. Sollte das Property nicht existieren, wird ein Platzhalter-Objekt zurückgegeben. Es stehen folgende Attribute zur Verfügung:-
id
: ID des ProductProperty. -
exists
: Gibt an, ob das ProductProperty existiert. -
values
: Die gesetzten Werte als Liste von Booleans oder Strings. -
str_value
: Die gesetzten Werte als kommaseparierter String. -
bool_value
: Der gesetzte Wert als Boolean. -
password_hash(method, format)
: Gibt den Wert als Passwort-Hash zurück.-
method
:md5
,sha512
oderpbkdf2-sha512
. -
format
:shadow
,grub
-
-
cmdline(pattern, remove_prefix)
: Generiert Linux-Kernel-Parameter als String.-
pattern
: Ein einzelnes oder eine Liste von Unix-Wildcards zum Filtern der Property-Namen. -
remove_prefix
: Ein einzelnes oder eine Liste von Präfixen, die vom Property-Namen entfernt werden sollen.
-
-
config_states
-
Alle ConfigStates des Clients, die mit
netboot.
beginnen, als Dictionary. Die gleichen Attribute wie beiProductPropertyState
-Objekten sind verfügbar. opsi-linux-bootimage
-
Ein spezielles Objekt, das die Methode
cmdline(additional_params, config_id_prefix)
bereitstellt, mit der alle erforderlichen Linux-Kernel-Parameter als String erzeugt werden.-
additional_params
: Zusätzliche Kernel-Parameter als Dictionary, die hinzugefügt oder überschrieben werden. -
config_id_prefix
: Prefix von Config-IDs, die als Kernel-Parameter hinzugefügt werden sollen (Standard istnetboot.opsi-linux-bootimage.cmdline.
).
-
Alternativ kann in pxeConfigTemplate
auch ein Verzeichnisname angegeben werden.
Dann wird die Datei grub.cfg
aus dem Verzeichnis <boot>/opsi/<verzeichnisname>
geladen.
Beispiel für ein pxeConfigTemplate
-Attribut:
if [ "$grub_platform" = "efi" ]; then
menuentry 'Start {{ product.name }}' --unrestricted {
echo "Loading {{ product.name }} {{ product.productVersion }}..."
linux (${bootsrc})/opsi/my-product/loader.efi {{ product_property_states.cmdline("cmdline.*", "cmdline.") }}
}
else
echo "{{ product.id }} does not support Legacy BIOS booting."
sleep 5
exit
fi
Bootimage-Parameter mit opsi-cli setzen
Mit opsi-cli können Bootimage-Parameter komfortabel gesetzt werden. Passwörter lassen sich dabei direkt in sichere Hashes umwandeln.
opsi-cli bootimage set-boot-password <PASSWORD>
Der Passwort-Hash wird automatisch im Host-Parameter netboot.opsi-linux-bootimage.cmdline.pwh
gespeichert und zusätzlich auf der Konsole ausgegeben.
Automatische Betriebssysteminstallation
Voraussetzungen
Das Gerät sollte für einen Netzwerk-Boot (PXE-Boot) konfiguriert sein. Alternativ ist auch ein Boot von CD oder USB-Stick möglich.
Das opsi-Paket für das gewünschte Betriebssystem muss auf dem opsi-Server installiert sein.
Netzwerkboot
-
Das Gerät startet per PXE-Boot.
-
Der DHCP-Server weist dem Gerät eine IP-Adresse zu und teilt ihm Boot-Server (meist opsi-Depotserver) und Boot-Datei mit.
-
Der Client lädt die Boot-Datei vom Boot-Server, abhängig von Architektur und BIOS-Typ (UEFI / Legacy BIOS).
-
Bei aktiviertem Secure Boot wird die shim geladen, die anschließend den GRUB2-Bootloader startet.
-
Ohne Secure Boot wird GRUB2 direkt geladen und gestartet.
-
GRUB lädt die eingebettete Konfigurationsdatei.
-
Die client-spezifische GRUB-Konfigurationsdatei
<SystemUUID>.cfg
oder<MAC-Adresse>.cfg
wird nachgeladen. Diese Dateien werden vom Dienst opsipxeconfd dynamisch erstellt. -
Kernel und initramfs des opsi-linux-bootimage werden vom Bootserver geladen.
-
Der Kernel startet mit den Boot-Parametern aus der GRUB-Konfigurationsdatei.
-
Das Linux-Bootimage konfiguriert die Netzwerkschnittstellen per DHCP.
-
Der opsi-Service des Bootimage startet und verbindet sich mit dem opsi-Service.
-
Die Installationskonfiguration wird vom opsi-Service abgerufen.
-
Es wird eine Verbindung zum opsi-Depotserver hergestellt, um die Installationsdateien zu laden.
-
Das für die gewählte Aktion hinterlegte Skript wird ausgeführt.
Alle weiteren Schritte hängen vom jeweiligen Netboot-Produkt ab. Im Folgenden wird der Ablauf für die unattended-Installation von Windows-Betriebssystemen unter UEFI beschrieben.
Unattended-Installation von Windows-Betriebssystemen
Ist das ProductProperty askBeforeInst
gesetzt, muss der Start der Neuinstallation bestätigt werden.
- Vorbereitung der Festplatte
-
Die Festplatte wird partitioniert. Es werden mindestens eine EFI-Partition (FAT32), eine NTFS-Partition für Windows PE und eine NTFS-Partition für das Betriebssystem angelegt und formatiert.
- Kopieren der Installationsdateien
-
Das im Netboot-Produkt hinterlegte Windows PE, die Installationsdateien, die passenden Windows-Treiber sowie der opsi-client-agent werden vom opsi-Depotserver auf die lokale Platte kopiert.
- Erstellen der Konfigurationsdateien
-
Es werden verschiedene Konfigurationsdateien für die Installation erstellt, darunter die
unattend.xml
als Steuerdatei für die Windows-Installation. - Anpassung der Boot-Konfiguration
-
Die UEFI-Boot-Konfiguration wird so angepasst, dass beim nächsten Start von der Windows PE-Partition gebootet wird.
- Windows Setup
-
Nach dem Neustart startet Windows PE und führt die automatische Installation des Betriebssystems über das Windows Setup durch.
- Installation des opsi-client-agent
-
Im Rahmen der Windows-Installation wird auch der opsi-client-agent installiert und konfiguriert. Anschließend installiert der opsi-client-agent weitere Localboot-Produkte, die auf
installed
odersetup
stehen.
ProductProperties der Windows-Netboot-Produkte
Die Windows-Netboot-Produkte sind so konzipiert, dass sie eine möglichst flexible und anpassbare Installation von Windows-Betriebssystemen ermöglichen. Die Steuerung der Installation erfolgt über verschiedene ProductProperties, die im folgenden beschrieben werden.

- additional_drivers
-
Liste von Verzeichnissen unterhalb von
<depot-share>\<product-id>\drivers\drivers\additional
. Alle Treiber-Verzeichnisse unterhalb der angegebenen Verzeichnisse werden unabhängig von der automatischen Treibererkennung zusätzlich in die Installation mit eingebunden. - administrator_password
-
Hier kann das Passwort angegeben werden, welches bei der Installation für den lokalen Administrator gesetzt wird.
- askbeforeinst
-
Soll eine Bestätigung vor der Installation erfolgen?
- boot_partition_size
-
Größe der Boot-Partition (Bitlocker Partition). Wird der Wert auf
0
gesetzt, wird keine Boot-Partition angelegt. - boot_partition_label
-
Label der Boot-Partition (Bitlocker Partition)
- boot_partition_letter
-
Laufwerksbuchstabe der Boot-Partition (Bitlocker Partition)
- data_partition_create
-
Soll eine eigene Datenpartition angelegt werden?
- data_partition_label
-
Label der Datenpartition.
- data_partition_letter
-
Laufwerksbuchstabe der Datenpartition.
- data_partition_preserve
-
Soll eine vorhandene Datenpartition bei einer Reinstallation erhalten bleiben?
- fullname
-
Vollständiger Name des Lizenznehmers, wie er der Installation übergeben wird.
- imagename
-
Name der Variante des Betriebssystems das zu installieren ist.
- installto
-
Diese Einstellung ist nicht editierbar. Es dient beim Ablauf zur Unterscheidung zwischen Standard (
disk
), opsi-local-image (oli
) und opsi-vhd (vhd
). - multi_disk_mode
-
Diese Property dient zur Wahl der Festplatte auf die installiert werden soll. Mögliche Werte sind:
0
,1
,2
,3
,prefer_ssd
undprefer_rotational
. Die Werte0
,1
,2
,3
geben den Index der Festplatte direkt an (0
= 1. Festplatte). Der Wertprefer_ssd
wählt die erste SSD aus. Der Wertprefer_rotational
wählt die erste rotierende Festplatte (HDD) aus. Auf Systemen mit nur einer Festplatte wird das ProductProperty ignoriert. - orgname
-
Vollständiger Name der Organisation des Lizenznehmers, wie er der Installation übergeben wird.
- pre_format_system_partitions
-
Sollen vorherige Partitionen formatiert werden um Spuren vorheriger Installationen zu löschen?
- preserve_winpe_partition
-
Soll die Windows PW Partition nach der OS-Installation erhalten bleiben?
- productkey
-
Lizenzschlüssel zur Installation. Wird nur verwendet wenn der Hostparameter
license-management.use
auf 'false' steht. Ansonsten wird ein Lizenzschlüssel aus dem Lizenzmanagement bezogen. - setup_after_install
-
Welche Localboot-Produkte sollen nach dem Betriebssystem installiert werden?
- system_keyboard_layout
-
Sprachauswahl für die Tastatur.
- system_language
-
Sprachauswahl für das System.
- system_timezone
-
Zeitzoneneinstellung
- use_raid1
-
Soll ein Software-RAID1 angelegt werden?
- windows_partition_label
-
Label der System-Partition (
C:
) auf die das Betriebssystem installiert werden soll. - windows_partition_size
-
Größe der System-Partition (
C:
). Die Angabe kann prozentual zur Festplatte oder als absolute Zahl (G=Gigabyte) erfolgen. Der verbleibende Speicherplatz wird für die Datenpartition genutzt. - winpe_dir
-
Das für die Installation verwendete Windows PE-Verzeichnis. Der Wert
auto
wählt das Verzeichnis automatisch. Andere Werte müssen auf ein gültiges Verzeichnis im Netboot-Produkt zeigen. - winpe_inputlocale
-
Die unter Windows PE verwendete Eingabesprache.
- winpenetworkmode
-
Ist dieser Wert
true
, wird der Depot-Share im WinPE als Netzlaufwerk eingebunden und die Installation erfolgt über das Netzwerk. Andernfalls werden die benötigten Windows-Installationsdateien bereits im opsi-linux-bootimage auf die lokale Festplatte kopiert und die Installation erfolgt von den lokalen Dateien. - winpe_uilanguage
-
Die unter Winows PE verwendete Anzeigesprache.
- winpe_uilanguage_fallback
-
Fallback-Anzeigesprache unter Windows PE, falls die primäre Sprache nicht verfügbar ist.
memtest86
Das memtest86-Produkt dient dazu, einen umfassenden Speichertest auf dem Gerät durchzuführen.