History

PreBoot

Nicht in allen Umgebungen lässt sich PXE/PXELinux sinnvoll zum Start von OpenSLX-Clients einsetzen. Wenn man beispielsweise eine Maschine per WLAN starten möchte oder sie über eine WAN-Verbindung (DSL, Kabel ab 10Mbit/s Datendurchsatz, siehe hierzu auch #191) booten will, benötigt man einen vorgeschalteten Schritt, der für das Laden der Stage3-Komponenten (dem zu startenden System entsprechenden Kernel und InitRamFS) verantwortlich ist. Die Realisierung des schnellen Warmstarts übernimmt kexec.

Sinnvollerweise ist das PreBoot so gestaltet, dass seine Grundlagen möglichst statisch sind (und nur selten aktualisiert werden müssen):

  • Es wird ein bestehender Bootloader erweitert oder ein alternatives Boot-Device erstellt.
  • Der Kernel ist ein aktueller Vanilla-Kernel mit allen wichtigen Ethnernet- und WLAN-Treibern (entweder fest einkompiliert oder in Module ins InitRamFS ausgelagert). Er sollte nicht auf Effizienz sondern eher auf größtmögliche Kompatibilität getrimmt sein und das kexec sicher unterstützen. Gleichzeitig sollte er eine möglichst geringe Größe aufweisen.
  • Das InitRamFS sollte ein Basis-System umfassen (welches mit dem von Embedded-Systemen vergleichbar ist). Dieses Basis-System benötigt die Busybox, kexec, je nach Bedarf WLAN-Tools und eine Skripting-Umgebung o.ä. für die Benutzerinteraktion. Auch dieses InitRamFS sollte möglichst kompakt sein.

Die beiden Dateien Kernel und InitRamFS lassen sich dann mittels verschiedener Boot-Loader aus der Syslinux-Familie in sehr unterschiedlichen Umgebungen starten: Sie könnten auf CD's als Boot-Option untergebracht sein, im NT-Loader von Windows-Systemen, im GRUB etc. Sie sollten hier möglichst wenig Platz wegnehmen und nur selten ausgetauscht werden müssen.

Die Idee hinter PreBoot ist, dass es möglich sein muss, verschiedene, sich ändernde Systeme ohne Änderungen am PreBoot zu starten. Variable Elemente, wie die sich ändernde Liste von startbaren Systemen oder verschiedene Module für Benutzerinteraktion müssen daher nachladbar und nicht fest kodiert sein.

PreBoot-Szenarien

Folgende Einsatzszenarien sind denkbar:

  1. Massenbetrieb ala PXE nur halt wegen WLAN über PreBoot
  2. Standard-Kiosk ohne spezielle Nutzerkonfig (individueller WAN Demo-Betrieb oder allgemeiner Massenbetrieb)
  3. Einzel-User, der WAN-Boot macht
Für diese Szenarien ist zu überlegen, wie man die Konfiguration realisiert, die nun ja nicht als ConfTGZ via TFTP bereitgestellt wird.
  1. ... benötigte ein klassisches default.tgz analog zum PXE-Bootmodus
  2. ... wäre mit einem default.tgz zu bedienen, welches sich aber von 1. unterscheidet. Das müsste dann über unterschiedliche PrebootIDs abgewickelt werden.
  3. ... würde das neue HTTP-Konfigurationsmodell intensiver nutzen ...

Ablauf in der PreBoot-Umgebung

Das OpenSLX PreBoot realisiert folgenden Ablauf:

  1. Laden der Netzwerkkartenmodule und IP-Konfiguration per DHCP (es wird davon ausgegangen, dass DHCP immer zur Verfügung steht: Typischerweise in heutigen LAN-Szenarien und im Heimbereich mit DSL/Kabel-Routern gegeben). (Es wäre auch denkbar, dass ein Anwender statisch die IP-Daten festlegt, das müsste er aber bei jedem Neustart wiederholen, was nicht besonders komfortabel wäre.) Dieses übernimmt das PreBoot-Skript init.
  2. Feststellen, ob die IP-Verbindung zum OpenSLX-Server besteht, in dem ein TGZ (preboot.env) mit der Auswahl der bootbaren Systeme (analog zum pxelinux.cfg/default) per HTTP (oder FTP) geholt wird. Entpackt wird in das Verzeichnis /preboot. Aus dem init heraus wird dann preboot.sh aus /preboot gestartet, was alle weiteren Schritte der Interaktion bis hin zum Laden des eigentlichen Kernels/InitRamFS des klassischen Stage3 übernimmt.
  3. Im nächsten Schritt (Start von preboot.sh) wird eine Liste der einstellbaren Variablen der Client-Konfiguration (späteres ConfTGZ des jeweils bootenden Clients) bezogen. (Es kommt hierzu das Busybox wget zum Einsatz.)
  4. Anbieten der Auswahl bootbarer Systeme.
  5. Feststellen, ob es schon eine Client-Konfiguration für das zu bootende System passend zur Maschine gibt, indem versucht wird das entsprechende ConfTGZ (kodiert mit der MAC des Clients, später zur Erhöhung der Sicherheit könnte es auch ein Hash-Wert über einen Username o.ä. sein, der dann aber vom Anwender bei jedem Start angegeben werden müsste. Auf diesem Wege liessen sich die Daten auch verschlüsseln.) geladen werden kann.
  6. Lag kein ConfTGZ vor, sollte es dem Benutzer die Möglichkeit der Konfiguraton via dialog (Alternativ auch via Web-Konfiguration und oder komfortablerer Oberfläche) anbieten. Das sollte modular gestaltet sein, so dass nicht immer alle Optionen zur Auswahl stehen müssen und auch der Benutzer sehr schnell nach ein paar Standardeinstellungen fertig wird (wenn er nicht unbedingt an weiteren Parametern herumschrauben will. Interface evtl. ähnlich zur Kernel-, Busybox-Konfiguration). Das generiert am Ende serverseitig ein ConfTGZ, so dass es in Zukunft wiederholt genutzt werden kann.
  7. Anschliessend wird in jedem Fall das Menü der bootbaren Systeme präsentiert (siehe auch #209). Dieses enthält alle wichtigen Daten, damit die passenden Kernels und InitRamFS aus HTTP- oder FTP-Quellen gezogen werden können.
  8. Generieren des notwendigen Kexec-Aufrufs (incl. Pfad zum ConfTGZ "file=http://<MAC-des-Clients>", der als Option mitgegeben werden muss). Es gibt keine Möglichkeiten Daten direkt aus dem PreBoot ins Stage3 zu übertragen! (Nur auf dem Umweg ConfTGZ, Kernel Commandline) Hier wäre alternativ auch die Ablage auf einem "OpenSLX" USB-Stick zum Booten und mit User Home-Verzeichnis denkbar, via "file=disk://usb/pfad/Client-Config" ...
  9. Wechsel ins Stage3. Per "file=..." bekommt der Client mitgeteilt, wo er seine Konfiguration findet und dass er diese per HTTP/FTP beschaffen muss.

Erstellen von PreBoot Umgebungen

Eine PreBoot-Umgebung lässt sich durch Anlegen eines speziellen Clients generieren: slxconfig add-client name=PreBoot comment="Dummy client for creating the PreBoot environment" mac="FF:FF:FF:FF:FF:FF" boot_type=preboot preboot_media=cd boot_uri=http://servername Anschließend muss der Demuxer neu aufgerufen werden. Das Ergebnis findet sich dann unterhalb von ...

Dabei sind die Attribute
  • "boot_type" - Ändern des Standard-Boot-Typs von "pxe" auf "preboot"
  • "preboot_media" - muss auf "cd" gesetzt sein, um ein ISO zu generieren. Zur Zeit gibt es nur die Option "cd", weitere Bootmedien befinden sich in der Entwicklung.
  • "boot_uri" - Quelle des übers Netz nachzuladenden preboot.env und der verschiedenen Systeme Kernel/InitRamFS von Bedeutung und müssen definiert sein. Als Protokolle sind derzeit "http" (oder "ftp") erlaubt (z.B. boot_uri=http://preboot.openslx.org).

Für das Erzeugen von SLX Preboot USB Sticks finden Sie die eine Anleitung hier: PreBootLoader

Nach dem Lauf des slxconfig-demuxers findet sich im Verzeichnis /srv/openslx/images/PreBoot/ das Ergebnis in Form einer ISO oder entsprechenden Datei.

Die erstellte PreBoot-Umgebung muss dann via geeignetem Boot-Loader/Device gestartet werden können. Hierzu kommt der Einbau in bestehende Boot-Loader (ntldr, bootmgr, grub, ...) in Frage, die Erstellung von Boot-ISOs oder der Start vom USB-Stick in verschiedenen Konfigurationen.

Konfigurieren eines PreBoot Webservers

Der PreBoot-Webserver stellt sowohl die klassischen Elemente Kernel und InitRamFS zur Verfügung, als auch das preboot.env und die Erzeugung spezieller ConfTGZ. Für letzteres kommt ein spezielles Perl-CGI-Skript zum Einsatz (user_settings.pl im Quell-Baum unterhalb des Verzeichnisses preboot/http-server). Auf diesem werden die üblichen Verzeichnisse leicht abgewandelt benötigt (aus Sicht des "Document Root"):

  • /bootloader - hier liegt das preboot.env
  • /"preboot-id"/client_conf - "preboot_id" entspricht dem Namen des speziellen PreBoot-Clients. Unterhalb des Verzeichnisses finden sich dann die konfigurierten Systeme (diese Unterverzeichnisse werden dynamisch erzeugt)
  • /system/"system-name" - Kernel und InitRamFS des jeweiligen Systems ("system-name")

Entwicklungsschritte

Ein erster Vorläufer des PreBoots wurde mit r1589, r1600 realisiert. Die weiteren Schritte erfolgen mit r2535 und nun r2900 ff.

  1. Implementierung der System/Menüauswahl (siehe #209)
  2. Start in einen festgelegten Demo-Kioskmode (entsprechendes statisches ConfTGZ für alle PreBoot nutzenden Clients). Hierzu sollte das Standard-OpenSLX-Theme als Demo funktionieren.
  3. Implementierung einer rudimentären Benutzerinteraktion (Root-Passwort, Anlegen eines definierten Nichtprivilegierten Nutzers mit Passwort, Sprache: erstmal nur Englisch, siehe #200)
  4. Nutzung der GentooUclibcChroot Toolchain (weitgehend realisiert).
  5. Erweiterung der Konfigurationsmöglichkeiten (Tastatur-Layout, Wahl des Desktops, Displaymanagers, ...)
  6. Sprachanpassungen für andere Sprachen neben dem Default (könnte Probleme mit uClibc/local/iconv geben)
  7. ...
  8. Anbieten einer grafischen Oberfläche für das PreBoot (Framebuffer-Tools/DirectFB).

Im jeweiligen PreBoot ist die URL für das Laden der Auswahl der bootbaren Systeme und eine Liste der einstellbaren Variablen über die Variable "boot_uri" bestimmt. Sie könnte damit eine Versionierung bereitstellen, um API-Änderungen abbilden zu können und trotzdem zu erlauben, dass auch alte PreBoot-Umgebungen (dann vielleicht im Vergleich zur neuen mit eingeschränktem Funktionsumfang) weiterhin funktionieren.