Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| anleitungen:pxe-boot [2024/01/24 16:39] – angelegt mike | anleitungen:pxe-boot [Unbekanntes Datum] (aktuell) – Externe Bearbeitung (Unbekanntes Datum) 127.0.0.1 | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | ====== PXE-Boot ====== | ||
| + | ===== Vorwort ===== | ||
| + | |||
| + | Das booten eines Betriebssystems von einem zentralen Repository im lokalen Netzwerk statt vom lokalen Datenträger bietet viele Vorteile, beispielsweise lassen sich so temporär oder zum testen Betriebssysteme laden die lokal nicht installiert sind, oder es können Betriebssysteme installiert werden (auch als Rollout im gesamten LAN), auch wenn kein USB-Anschluss oder optisches Laufwerk (CD/DVD) vorhanden, oder wenn der passende Installations-Datenträger auf DVD gerade nicht verfügbar ist und es lassen sich so ganz komfortabel komplette Tools wie die „Ultimate Boot-CD“ laden um beispielsweise Probleme mit einer Windows-Partition zu bereinigen. | ||
| + | In Firmen werden (neue) Betriebssysteme und Aktualisierungen (Patches) fast immer über ein zentrales Repository der IT-Administration ausgerollt, beispielsweise über Microsofts SCCM (System Center Configuration Manager). Für den Privatbereich gibt es einige Netzwerkspeicher wie beispielsweise die aktuellen NAS-Modelle von Synology die von Haus ein PXE-Boot unterstützen. Ab der Firmware Synology DSM 4.2 ist es möglich direkt vom NAS zu booten. | ||
| + | |||
| + | Microsoft´s SCCM kann seit dem 22.3.2018 nicht mehr mit Linux umgehen, da der dazu normalerweise benötigte Agent von Microsoft in der aktuellen SCCM-Version (seit SCCM 1902) rausgenommen wurde. Es bleibt jetzt nur noch die Möglichkeit eines „Handovers“ indem der SCCM einen externen PXE-Boot-Server (z.B. DNSmasq) antriggert. Alternative ist Microsoft Azure. | ||
| + | Damit zukünftig beide Systeme (Windows/ | ||
| + | |||
| + | ===== Scenarios ===== | ||
| + | |||
| + | Grundsätzlich gibt es zwei verschiedene Netboot-Scenarios: | ||
| + | |||
| + | * Live-System laden ohne Installation - Man bootet über das Netzwerk um darüber ein Live-System zu starten, das ohne Installation auskommt und daher auch keine Festplatte benötigt. Da das komplette Live-System ins RAM geladen wird ist die Auswahl an Live-Systemen sehr klein, der Rechner sollte mindestens 4 GB RAM haben, besser 8 GB RAM und das OS sollte möglichst klein sein, damit noch Platz für die Arbeitsdateien im RAM bleibt. In diesem Fall läuft alles ausschliesslich im RAM ab, die Festplatte bleibt komplett unberührt. | ||
| + | |||
| + | * Installation übers Netzwerk - Man bootet über das Netzwerk um darüber ein Betriebssystem zu installieren das auf der lokalen Festplatte eingerichtet wird. In diesem Fall lädt man per Netboot nur einen Installer, der anschließend die restlichen Daten aus einem zentralen Repository im LAN oder über das Internet holt. | ||
| + | |||
| + | ===== Voraussetzungen ===== | ||
| + | |||
| + | * Aktivieren von PXE-Boot im BIOS (Preboot Execution Environment) | ||
| + | * Funktioniert nur im LAN | ||
| + | * Funktioniert nur mit dynamischer IP via DHCP | ||
| + | * Zusätzlicher DHCP-Proxy | ||
| + | * Zusätzlicher TFTP-Server | ||
| + | * OS-Image als fertiges Netzwerk-Installationsprogramm oder als Live-System ohne Installation | ||
| + | * Im BIOS muß Secure Boot deaktiviert werden, da fast alle bootbaren ISO-Images nicht digital signiert sind | ||
| + | |||
| + | ===== Pre-Install ===== | ||
| + | |||
| + | * Im BIOS prüfen ob sich der Rechner auf Netzwerk-Boot (PXE-Boot) umschalten lässt. Alternativ über das Boot-Menü (je nach Rechner via F8, F10 oder F12) den Netzwerkadapter als Startgerät auswählen. Falls dieser nicht auswählbar ist, im BIOS nachsehen ob er als Startgerät aktivierbar ist. | ||
| + | * Secure Boot muß deaktiviert werden | ||
| + | * Fast immer muß auch UEFI-Boot deaktiviert werden, stattdessen Legacy Boot einschalten | ||
| + | |||
| + | ===== Testumgebung ===== | ||
| + | |||
| + | Da der Test für Netboot nur in einer abgeschotteten, | ||
| + | Nun kann man in dieser abgeschotteten Umgebung allerdings nicht den tatsächlichen Verlauf eines Netboots simulieren, denn es fehlen DNS, DHCP und Gateway. Somit kann kein Netboot mit Installation getestet werden, sondern nur Netboot mit einem Live-System ohne Installation. Beim starten des Clients bekommt dieser keine IP-Adresse des DHCP-Proxys zugewiesen, denn dieser kommt ausschliesslich vom richtigen DHCP-Server. | ||
| + | DNS wird benötigt um die Namensauflösung zu garantieren, | ||
| + | Bei einem vorhandenen DHCP darf DNSmasq nur als DHCP-Proxy laufen, oder der vorhandene DHCP muß einen IP-Bereich frei lassen der dann von DNSmasq benutzt werden kann. | ||
| + | Das Gateway (Internetzugang) wird benötigt um das Installationsimage vom Repository nachzuladen wenn ein Netboot mit anschließender Installation ausgewählt wird. Bei DNSmasq müsste eine Forwarder-DNS angegeben werden, aber ohne Gateway auch kein Nameserver in höherer Instanz. | ||
| + | |||
| + | ===== DNSmasq ===== | ||
| + | |||
| + | DNSmasq ist: | ||
| + | |||
| + | * DNS-Server für das lokale Netzwerk | ||
| + | * DNS-Forwarder | ||
| + | * DNS-Cache | ||
| + | * DHCP-Server / DHCP-Proxy | ||
| + | * TFTP-Server | ||
| + | |||
| + | DNSmasq bzw. genauer DNSmasq_base ist in allen aktuellen Debian-basierenden Linux-Distributionen enthalten. DNSmasq_base wird dabei vom Network Manager benutzt. | ||
| + | Um DNSmasq als PXE Boot-Server einzusetzen muß zunächst eine vollständige DNSmasq Installation eingerichtet werden. In allen Debian-basierenden Linux-Repositorys ist dieser bereits enthalten. Installation mit: | ||
| + | |||
| + | '' | ||
| + | |||
| + | Anschliessend muß DNSmasq passend konfiguriert werden: | ||
| + | |||
| + | '' | ||
| + | |||
| + | Folgende Konfiguration ist in der DNSmasq Konfigurationsdatei einzutragen: | ||
| + | |||
| + | ''# | ||
| + | port=0 | ||
| + | # Bei Bedarf die DHCP-Transaktionen mitloggen, sonst auskommentieren | ||
| + | log-dhcp | ||
| + | # Root-Verzeichnis mit den Boot-Images auf dem TFTP-Server setzen | ||
| + | enable-tftp | ||
| + | tftp-root=/ | ||
| + | # | ||
| + | dhcp-boot=pxelinux.0 | ||
| + | # Boot-Filename, | ||
| + | # Erster Parameter = Option 67 mit File-Location auf dem Server | ||
| + | # Zweiter Parameter = Server-Hostname | ||
| + | # Dritter Parameter = IP-Adresse des PXE-Servers | ||
| + | dhcp-boot=pxelinux, | ||
| + | # Doppelte DHCP-Benutzung deaktivieren um alte DHCP-Clients nicht zu verwirren | ||
| + | dhcp-no-override | ||
| + | # Bekannte Rechner-Architekturen vorauswählen. Damit kann gezielt das passende | ||
| + | # Boot-Images ausgerollt werden. Diese werden auch genutzt wenn der Anwender | ||
| + | # im Boot-Menü keine Auswahl trifft | ||
| + | # x86PC, PC98, IA64_EFI, Alpha, Arc_x86, Intel_Lean-Client, | ||
| + | # BC_EFI, Xscale_EFI, X86-64_EFI | ||
| + | pxe-service=x86PC, | ||
| + | # Möglichkeit 1: zusätzlicher DHCP IP-Bereich und Lease-Time angeben | ||
| + | dhcp-range=192.168.1.1, | ||
| + | # Möglichkeit 2: oder als DHCP-Proxy der keine IP vergibt | ||
| + | dhcp-range=192.168.1.1, | ||
| + | # Interfaces und Adressen auf die der DHCP reagieren soll | ||
| + | interface=eth0 | ||
| + | listen-address=127.0.0.1 | ||
| + | listen-address=192.168.1.1'' | ||
| + | |||
| + | Anschließend muß die neue DNSmasq Konfiguration geladen werden: | ||
| + | |||
| + | '' | ||
| + | |||
| + | Damit werden Legacy BIOS PXE Anfragen von DNSmasq abgefangen und umgeleitet, wobei der Microsoft DHCP immer noch seine SCCM UEFI-Optionen hat und – falls dieser Server einmal ausfallen sollte – diese bereitstellt, | ||
| + | |||
| + | Denn die DHCP Option 60 PXEClient ist nur dann von Nöten wenn der WDS/SCCM als eigenständiger DHCP-Proxy agieren soll, was er aber nicht braucht, weil die DHCP-Optionen sowieso vom DHCP-Server ausgeliefert werden. | ||
| + | |||
| + | ====== Microsoft DHCP-Server ====== | ||
| + | |||
| + | Der bestehende Windows DHCP-Server muß umkonfiguriert werden, sodaß ein Client über das Netzwerk auf den FOG-Server zugreifen kann: | ||
| + | Option 66 = IP-Adresse des FOG-Servers | ||
| + | Option 67 = undionly.kpxe | ||
| + | |||
| + | ===== SCCM-Konfiguration ===== | ||
| + | |||
| + | TODO | ||
| + | |||
| + | ===== Facts ===== | ||
| + | |||
| + | * Ein TFTP-Server ist nicht zwangsläufig Vorraussetzung für PXE, denn seit UEFI 2.5 kann anstelle des TFTP-Servers auch http verwendet werden. Somit wäre ein Nachteil egalisiert (UEFI-Boot statt Legacy-Boot). | ||
| + | * DHCP-Discover ist ein Broadcast auf UDP-Port 67 | ||
| + | * Etherboot, ab Sommer 2006 auch „gPXE“ | ||
| + | * Mit iPXE und manuell eingegebener Netzwerk-Konfiguration ermöglich booten über das Netzwerk, auch ohne DHCP und ohne TFTP | ||
| + | * Proprietäre Weiterentwicklung von PXE ist WDS (Windows Deployment Services) von Microsoft | ||
| + | * HTTP ist schneller als TFTP | ||
| + | * SCCM nutzt auch iPXE | ||
| + | * Intel beendet im Jahr 2020 den Support von BIOS Legacy Boot. Das bedeutet langfristig muß eine Lösung her die auch mit UEFI-Boot funktioniert. | ||
| + | |||
| + | ===== Alternativen ===== | ||
| + | |||
| + | [[anleitungen: | ||
| + | |||
| + | * iPXE mit manuell eingegebener Netzwerk-Konfiguration und booten über das Internet | ||
| + | * iPXE ist Open Source Software mit Hauptquelle auf ipxe.org | ||
| + | |||
| + | ===== FOG-Server ===== | ||
| + | |||
| + | Am 5.4.2019 wurde auf einem Linux Ubuntu Client-PC eine eigenständige OS-Deployment Lösung auf Basis der Open Source Software „FOG“ (fogproject.org) installiert. Dieser bietet bereits alle erforderlichen Ressourcen mit um geklonte Betriebssysteme über das Netzwerk auszurollen. | ||
| + | Bei Verwendung des FOG-Servers ist es nicht mehr erforderlich, | ||
| + | Der FOG-Server kann ein Image per Multicast gleichzeitig an viele Computer verschicken. Das bedeutet, dass das Image nur einmal von den Serverplatten gelesen und nur einmal über die Netzwerkkarte des Servers übertragen werden muss. Die Einrichtung der MulticastFunktionalität ist allerdings schwierig und erfordert vertiefte Netzwerkkenntnisse. Insbesondere muss auf allen verwendeten Switchen IGMP-Verkehr erlaubt werden. Sofern sich der FOG-Server in einem anderen Subnetz befindet als die Clients, muss der verwendete Router die Multicast-Pakete richtig weiterleiten. Dies ist nicht bei allen Geräten möglich. Wenn eine Firewall zwischen den Netzen eingerichtet ist, müssen einige Ports freigegeben werden (TCP: 20-22, 80, 111, 443, 2049, 1024-65535 sowie UDP: 69, 111, 1024-65535). | ||
| + | |||
| + | |||
| + | |||
| + | ===== Software ===== | ||
| + | |||
| + | * https:// | ||
| + | * https:// | ||
| + | * https:// | ||
| + | * https:// | ||
| + | * http:// | ||
| + | * https:// | ||
