satellite:ipxe-pxe - bwLehrpool

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
===== Bootmenü verwalten ===== 

Ein Menü setzt sich aus einem oder mehreren Booteinträgen oder Verweise auf andere Bootmenüs zusammen. Seien Sie vorsichtig, wenn Sie einen der Standardeinträge verändern. Für Experimente bietet es sich an, den "Kopieren"-Button in der Liste der Menüeinträge zu nutzen, damit der originale Eintrag erhalten bleibt.

Eine Einführung zu Bootmenüs mit iPXE finden Sie unter [[satellite:ipxe_bootmenu|iPXE Bootmenü]].


===== UEFI =====

<WRAP group>
<WRAP 70% column>
Bisher unterstützen die meisten Rechner noch einen Legacy-PXE-Boot. Es gibt allerdings bereits erste Systeme, die sich ausschließlich über EFI starten lassen. Hier sind Anpassungen am DHCP-Server notwendig. Bitte beachten Sie außerdem, dass Secure Boot bei Verwendung von UEFI deaktiviert werden muss, da bwLehrpool Binaries nicht von den standardmäßig im UEFI hinterlegten Schlüsseln signiert worden sind.

BIOS und UEFI unterscheiden sich grundlegend voneinander. Auch die über den DHCP-Server ausgelieferte PXE-Binary muss daher auf die jeweilige Architektur passen. Der Satellitenserver enthält Binaries für beide Architekturen, jedoch muss das jeweils richtige Bootfile an die Clients ausgeliefert werden.

<note tip>Für normalen BIOS-PXE Boot muss der DHCP als Bootfile wie bisher <wrap em>ipxelinux.0</wrap> oder eine andere BIOS-Variante (<wrap em>unidonly.kpxe.0</wrap>, <wrap em>ipxe.pxe.0</wrap>) ausliefern. Für Clients die über EFI booten lautet das Bootfile <wrap em>ipxe.efi</wrap> oder <wrap em>snponly.efi</wrap>.</note>

In der Regel lässt sich die Architektur über die DHCP Option 60 (Vendor class identifier)((https://www.ietf.org/rfc/rfc2132.txt)) bzw. 93 (Client System Architecture)((https://www.rfc-editor.org/rfc/rfc4578.txt)) erkennen und das Verhalten entsprechend steuern. Vergleichen Sie dazu auch die beiden nebenstehenden Screenshots.


Je nach verwendetem DHCP-Server unterscheidet sich die Konfiguration, weswegen wir hier nur Beispiele bzw. weiterführende Informationen angeben können. 

==== DHCP-Beispielkonfiguration ====

Sie können die Konfiguration zunächst erst mal ohne Unterscheidung der Client-Architektur fest für einen einzelnen Test-Rechner setzen. Somit können Sie gefahrlos prüfen, ob UEFI-Boot mit bwLehrpool generell funktioniert. Sind alle Rechner eines Subnetzes auf EFI oder BIOS gestellt, ist es evtl. ebenfalls ausreichend, das Bootfile Netzweit zu setzen.

++++ Einzelner Rechner (Bsp. isc-dhcpd) |
<code>
host efi-test-client {
    fixed-address 10.9.9.99;
    hardware ethernet 8a:51:45:2b:9a:12;
    next-server 10.9.9.5;
    log (info, "bwLehrpool efi64 client test");
    filename "ipxe.efi";
}
</code>
++++ 

Damit nicht jeder Client mit UEFI einzeln eingetragen werden muss, sollten Sie jedoch über den "vendor-class-identifier" unterscheiden, ob ein Client per BIOS oder UEFI bootet und das entsprechende Bootfile ausliefern. Somit lassen sich leicht ganze Subnetze konfigurieren.

++++ Unterscheidung mittels "vendor-class-identifier" (Bsp. isc-dhcpd) |
<code>
subnet 10.9.9.0 netmask 255.255.255.0 {
    range 10.9.9.100 10.9.9.200;
    option routers 10.9.9.254;
    next-server 10.9.9.5;
    filename "ipxelinux.0";
    option domain-name "xyz.meine-domain.de";

    if substring (option vendor-class-identifier, 19, 1) = "0" {
        log (info, "pxe client");
        filename "ipxelinux.0";
    }
    else if substring (option vendor-class-identifier, 19, 1) = "7" {
        log (info, "efi64 client");
        filename "ipxe.efi";
    }
    else {
        log (info, concat ( "Unhandled vendor class Arch: ", substring (option
        vendor-class-identifier , 19,1 )));
    }
}
</code>
++++

\\
Unseres Wissens unterstützt Windows Server 2008R2 die Unterscheidung anhand des "vendor-class-identifier" nicht. Sie haben in diesem Fall daher drei Möglichkeiten:
  * Wechsel auf einen anderen DHCP (z.B. Windows Server 2012)
  * Festes Eintragen für einzelne Rechner bzw. IP-Ranges wenn alle Rechner in einer Range gleicher Architektur sind
  * Nutzen eines ProxyDHCP wie z.B. dnsmasq

\\
**Weitere Konfigurationsbeispiele:**
  * isc dhcpd (ganz unten): http://ipxe.org/cfg/platform
  * Mit Windows Server: https://2pintsoftware.com/whitepaper-using-dhcp-uefi-bios-pxe-booting/
  * https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence


</WRAP>

<WRAP column>
[{{ :satellite:ipxe:dhcp-discover-bios.png?direct&350|BIOS-Client - DHCP Discover}}]
[{{ :satellite:ipxe:dhcp-discover-efi.png?direct&350|UEFI-Client - DHCP Discover}}]
</WRAP>
</WRAP>


===== DHCP - MAC/UUID ===== 

DHCP-Server vergeben IP-Adressen für ein bestimmtes Zeitfenster (Lease). Wenn derselbe Rechner mehrmals bootet bzw. mehrfach Anfragen an einen DHCP-Server stellt, sollte dieser (im Rahmen der Lease oder einer statisch hinterlegten Regel) immer die gleiche IP erhalten. Ist dies nicht der Fall, kann es irgendwann passieren, dass keine freien IPs mehr zur Verfügung stehen und ein Client keine IP erhält. Außerdem gibt es voraussichtlich Probleme mit der Raumzuordnung von Clients innerhalb von bwLehrpool.

Im Fall von bwLehrpool werden beim Boot systembedingt zwei DHCP-Anfragen gestellt. Die Erste vom PXE-ROM, die Zweite vom MiniLinux. Manche PXE-Implementierungen senden die [[https://www.ietf.org/rfc/rfc2132.txt|Option 61 (Abschnitt 9.14. Client-identifier)]] obwohl diese eigentlich nicht mehr verwendet werden sollte ([[https://www.intel.com/content/www/us/en/support/articles/000007129/software/manageability-products.html|Compatibility Issues]]). Wird diese Option vom Client bzw. PXE-ROM gesetzt, unterscheidet sich die Anfrage von der zweiten Anfrage des MiniLinux, welches die Option standardmäßig nicht setzt.

Normalerweise erkennt der DHCP-Server Rechner einfach anhand der MAC-Adresse - dann sollte es keine Probleme geben. Manche DHCP-Server prüfen jedoch den oben erwähnten Client Identifier (Option 61). Der DHCP-Server erkennt durch die dann zwei unterschiedlichen Anfragen, fälschlicherweise zwei unterschiedliche Clients und vergibt daher zwei IP-Adressen an den selben Client.


Um dieses Verhalten zu ändern, kann per Kernel Command Line (KCL) die Option 'dhcpuuid' gesetzt werden. Ist die Option gesetzt, setzt das MiniLinux in seinen DHCP-Anfragen die Option 61 auf die System-UUID. Bearbeiten Sie dazu den entsprechenden Bootmenü-Eintrag für bwLehrpool und fügen **dhcpuuid** hinzu. Somit sollten beide Anfragen wieder identisch und das Problem behoben sein. 

**Menüeintrag Beispiel (bwlp-default + dhcpuuid):**
<WRAP box 100%>
imgfree ||\\
set slxextra initrd=logo ||\\
initrd /boot/default/initramfs-stage31 || goto fail\\
initrd --name logo /tftp/bwlp.cpio || clear slxextra\\
boot -a -r /boot/default/kernel initrd=initramfs-stage31 ${slxextra} slxbase=boot/default quiet splash loglevel=5 rd.systemd.show_status=auto intel_iommu=igfx_off <wrap em>dhcpuuid</wrap> ${ipappend1} ${ipappend2} || goto fail
</WRAP>
Zuletzt angesehen: • logo • dateisystemvergroesserung • raeume_orte • ipxe-pxe • vm_direkt_bearbeiten • satellitenserver_ereignisse • virtualisierer • mailingliste • satellite_changelog • bwgpul
Suche

Navigation

Drucken/exportieren

Werkzeuge
