Die Idee des Netzwerk-Boots wurde in den letzten Jahren am Rechenzentrum der Universität Freiburg weiterentwickelt. Es entstand das Softwarepaket \texttt{OpenSLX}, welches eine allgemeine Abstraktionsschicht für das Remote-Boot aus dem Netzwerk zur Verfügung stellt und die Basis für weitere Optimierungen bietet\footnote{\texttt{OpenSLX}-Projektseite: \textit{http://openslx.org}}. Dieses löst die bisher nur zu Teilen implementierten und sehr unterschiedlichen Ansätze der Linux-Distributionen für Netzwerkstart oder Live-CD ab. Gleichzeitig wird die Konfiguration der einzelnen Maschinen von der allgemeinen Bereitstellung eines gemeinsamen Root-Dateisystems für ein bestimmtes Linux getrennt. Auf diese Weise arbeiten alle Cluster-Knoten "`stateless"' und legen keine maschinenspezifischen Daten im lokalen Dateisystem ab.

Hierzu stellt \texttt{OpenSLX} eine Skriptsammlung bereit, welche viele Stan\-dard-Dis\-tri\-bu\-tio\-nen -- deren Auswahl sich mit überschaubarem Aufwand erweitern lässt -- für den Stateless-Betrieb vorbereitet. Es bietet weiterhin eine Boot-Middleware, die für den Benutzer der laufenden Maschine optimalerweise unsichtbar bleibt. Das jeweilige typische Verhalten der gewählten Distribution bleibt bestehen, die Anpassungen und Änderungen finden im Hintergrund hauptsächlich während des Bootvorgangs statt. Dieser wurde dabei so optimiert, dass er teilweise sogar weniger Zeit als bei einer festplattenbasierten Installation benötigt.

\texttt{OpenSLX} definiert vier so genannte Stadien, welche die Schritte zur Einrichtung der Maschine sowohl auf dem Boot-Server als auch später auf den einzelnen Cluster-Nodes bezeichnen. \textsc{Stage1} beschreibt die primäre Installation einer Linux-Distribution in ein Unterverzeichnis des Boot-Servers. Dieser Grundinstallation können lokale Anpassungen des Administrators oder Zusatzkomponenten hinzugefügt werden. Im anschließenden Schritt, dem zweiten Stadium werden hieraus Root-Dateisystem-Exporte erzeugt. Dabei kann es sich um ein per NFS-exportierbares Unterverzeichnis oder ein per Blockdevice bereitgestellten SquashFS-Container handeln. Beides erfolgt serverseitig zur primären Einrichtung und nach Updates oder Veränderungen im Root-Filesystem für die Clients. Das Ganze ist so angelegt, dass sich auf einem Server damit theoretisch beliebig viele solcher Primärinstallationen und Exporte anbieten lassen. Alle vom Administrator für einen bestimmten Cluster-Knoten eingetragene Exporte stehen sodann als Auswahlliste in einem \texttt{PXE}-Menü\footnote{\texttt{PXElinux} ist Teil des \texttt{Syslinux}-Pakets von H. P. Anvin: \textit{http://syslinux.zytor.com}} bereit. Wobei sich selbstverständlich festlegen lässt, welches System ohne Benutzerinteraktion standardmäßig bootet.

\textsc{Stage3} und \textsc{4} laufen auf dem Client ab. Hierzu wird das von allen neueren Linux-Kernels unterstütze Konzept des InitialRamFS genutzt. In diesem erfolgt das individuelle Setup des einzelnen Knotens durch ein spezielles von OpenSLX bereitgestelltes Minisystem. In \textsc{Stage3} läuft die individuelle Einstellung der Maschine ab und es werden die vom Administrator bestimmten lokalen Erweiterungen installiert. Im nächsten Stadium übergibt das OpenSLX-Init an das jeweils angepasste Runlevel-System der Distribution \cite{openslx}.

Ein großer Vorteil dieses Ansatzes ist, dass sich nun auch sehr einfach weitere Maschinen, wie leistungsfähige, in bestimmten Randzeiten ungenutzte, Desktopsysteme zusätzlich als Cluster-Knoten starten lassen \cite{garching}.