Was versteht man unter Remoteboot? Kurz gesagt, bedeutet Remoteboot das Starten von einer bootfähigen RAM-Disk, welche vorher über ein Netzwerk von einem Server geladen wurde. Der Inhalt einer solchen RAM-Disk wird vorher z.B. auf einer Floppy-Disk je nach Notwendigkeiten konfiguriert. In den meisten Fällen dürfte als Betriebssystem DOS 622 oder in Einzelfällen ein schlanker LINUX-Kernel zum Einsatz kommen.
Remoteboot wurde in letzter Zeit im Zuge der Diskussion um PXE (Preboot eXecution Environment), WfM (Wired for Management) und ACPI (Advanced Configuration and Power Interface) wieder spruchreif. Die Grundzüge dieser Technik sind allerdings schon vor über 10 Jahren definiert (RFC 951), sowie in Novell-Netzwerk-Umgebungen eingesetzt worden, um diskless Clients zu betreiben. Mit dem Zerfall der Hardwarepreise verschwanden auch PC’s ohne eigene Disk mehr und mehr von der Bildfäche.
Warum wurde Remoteboot plötzlich wieder interessant? Ein wichtiger Grund ist sicher die immer aufwendigere Konfiguration der heutigen PC’s. Auch wenn die Installation weitgehend automatisiert wird, reichen 1 – 2 Stunden heute oft nicht mehr aus, um einen PC vollständig zu installieren und ein Administrator muss vor Ort sein. Kostendruck spielt ebefalls eine immer wichtigere Rolle. Der grosse Vorteil der heutigen Remoteboot-Lösungen ist die zentrale Parameterisierung von ganzen Netzwerken mittels sogenannter DHCP-Servern. Zwei Beispiele:
Mit diesem Verfahren werden bei der Uni Genf alle Studentenrechner konfiguriert. Der Benutzer kann zwischen Win95, Winnt oder Linux als OS auswählen. Das entsprechende Betriebssystem wird danach innert weniger als 3 Minuten aus einem Image das in einer lokalen versteckten Partition liegt, auf die aktive Partition geladen und aufgestartet. So wird garantiert, dass der Benutzer immer mit einem "jungfäuliches" OS arbeiten kann.
Die WindowsNT-Maschinen in den Kursräumen der ETH Informatikdienste werden pro Hardwarelinie mit nur einem Image bedient, welches eine Partition mit über 1,5 GB Nutzung enthält. Nach dem aufspielen dieses Image auf den Rechner läuft selbständig eine Konfigurationsprozedur ab, die auf den einzelnen Clients die notwendigen Parameter (z. B. Computername, Mailadresse etc.) einträgt und die Maschine in die Domäne einfügt. Die ganze Installation und Konfiguration von über 1,5 GB dauert knapp 20 Minuten und läuft, dank Remoteboot, vollautomatisch ab.
Als Vorreiterin für Remoteboot von PC‘s in TCP/IP-Netzwerken hat sich die deutsche Firma Bootix (vormals Incom) hervorgetan. Vieles aus der heutigen PXE-Spezifikation wurde von dieser Firma erarbeitet.
Im folgenden wird vor allem auf TCP/IP-Remoteboot eingegangen, wenn notwendig werden Unterschiede zu PXE aufgezeigt.
BOOT-ROM
Ein BOOT-ROM ist eine Erweiterung zum
normalen System-BIOS das 
in jedem PC steckt. Diese
Erweiterung blendet sich genau gleich wie z.B. ein
SCSI-Kontroller in einen bestimmten Speicherbereich ein und wird
dann beim starten vom System-BIOS erkannt und ausgeführt.
als ROM’s werden heutzutage fast ausschliesslich EEPROM-Bausteine (Electrical Eraseable and Programable Read Only Memory) verwendet. Dabei werden vorwiegend 2 verschiedene Elemente entweder für DIP- oder PLCC-Sockel eingesetzt (siehe Abb. 1+2). Bei Netzwerk-Kontrollern die direkt auf dem PC-Motherboard sitzen, wird das BOOT-ROM oft im gleichen EEPROM gespeichert, das auch schon das System-BIOS enthält. Dies variert aber von Hersteller zu Hersteller.
Ein BOOT-ROM muss ausführbaren Code enthalten,
welcher sich in die Bootabfolge des PC einklinkt. Dadurch wird
bei jedem Neustart die Software aus diesem ROM gestartet, welche
dann die Kontrolle über den Rechner übernimmt. Weiter
kontaktiert diese via Broadcast einen Bootp- oder DHCP-Server und
bekommt die notwendigen Parameter (z.B. IP-Nummer, SubNet Mask,
Router, TFTP-Server etc.) geliefert. Danach kann bei Bedarf von
einem Server ein Bootimage in den lokalen Speicher geladen und
als startbare RAM-Disk verwendet werden. Oder es wird z. B. das
System von der lokalen Harddisk gestartet.
Bootp-Server
Bootp steht für BOOTSTRAP PROTOCOL und wurde bereits 1985 definiert (RFC 951).
Ein Bootp-Server sendet dem Client auf eine Anforderung über Broadcast, die IP-Adresse, die Server-Adresse und den Namen des Bootfiles. Diese Informationen können, wenn notwendig statisch pro Maschine oder auch für einen ganzen Bereich von Rechnern definiert werden, da der Bootp-Server die Ethernet- (MAC) Adresse des Clients filtert.
Diese Informationen sind normalerweise in einem File namens "Bootptab" enthalten. Die Auflösung welche Parameter an welchen Client gesendet werden, wird über die MAC (Ethernet)-Adresse vorgenommen, welche aus den Broadcast-Paketen ermittelt wird.
DHCP-Server
DHCP (Dynamic Host Configuration Protokoll) wurde 1993 in RFC 1531 definiert, kann als Nachfolger von Bootp betrachtet werden und ist logischerweise eine Erweiterung dessen. Neben den oben erwähnten Eigenschaften sind vor allem 2 Merkmale hervorzuheben, welche DHCP zu einem enorm mächtigen Werkzeug machen: Wie der Name schon sagt, kann ein DHCP-Server einen Bereich von IP-Adressen dynamisch an Clients vergeben. Aber auch eine statische Zuweisung aller Variablen auf Grund der Client-MAC-Adresse ist möglich. Als zweites sind die benutzerdefinierbaren Parameter zu erwähnen. Mit diesen Features kann DHCP als flexible System-Konfigurations-Datenbank verwendet werden.
DHCP-Server werden z.B. bei Internet-Providern für die Zuweisung einer IP-Adresse eingesetzt.
TFTP-Server
Das TFTP-Protokoll (Trivial File Transfer Protocol) ist seit 1981 in RFC 783 spezifiziert. Bereits 1984 wurde vorgeschlagen, dieses Protokoll zum transferieren von Bootimages zu verwenden (RFC 906). Wie der Name schon sagt, handelt es sich hier um ein einfaches Verfahren zur Dateiübertragung, das für solche Anwendungsfälle wie geschaffen ist, da es sehr wenig Ressourcen benötigt. Leider ist es relativ langsam, dies fällt aber nicht gross ins Gewicht, da die zu übertragenden Bootimages max. 2.88 MB enthalten.
Um dieses Manko trotzdem noch zu reduzieren, hat Bootix eine Erweiterung von TFTP um Multicast vorgeschlagen und in ihren Produkten auch umgesetzt. Damit lässt sich auf einem Sub-Netz eine beliebige Anzahl Clients von einem Server aus gleichzeitig mit einem Bootimage versorgen.
Spezielle Utilities von Bootix
Bootix bietet einen eigenen sogenannten Bootstrap-Loader an. Dies ist ein kleines Programm, welches anstelle eines Bootimages vom Server geladen wird (wird auf dem DHCP-Server als Bootfile eingetragen). Dieser Loader kann verschiedene Zustände auf der lokalen Festplatte abfragen und daraus resultierend unterschiedliche Bootfiles laden. Dies ist eine sehr mächtige Eigenschaft, lässt sich doch damit der genaue Zustand einer über mehrere Neustarts verteilte Installations- oder Restore-Operation abfragen. Weiter sind die Programme bputil und bputil32 (für WindowsNT) zu erwähnen, welche DHCP-Parameter in beliebige Dateien patchen können (und noch einigers mehr).
Ablauf einer Neuinstallation in den Kursräumen der ETH-ID
Grundsätzliches
Als Betriebsystem wird WindowsNT Version 4 SP4 eingesetzt. Alle benötigte Software für ein Kurssemester ist bereits lokal installiert. Das sind weit über 20 Anwendungen, dies ergibt eine totale Belegung von über 1,5 GB auf den lokalen Harddisks.
Die komplette Installation und Konfiguration erfolgt auf nur 1 Maschine. Danach wird die NTFS-Partition mit Norton Ghost in ein Imagefile auf eine 2. lokale Partition geschrieben die FAT formatiert ist. Diese Partition die nur dieses komprimierte Image (etwa 850 MB) enthält wird danach in ein eigenens Image auf den NT-Server geschrieben. Danach wird dieses Image mit dem Ghost Server und Multicasting auf alle 17 Clients gleichzeitig verteilt. Ein solcher Multicasting-Transfer dauert etwa 35-40 Minuten über das 10 Mbit Ethernet. Anschliessend wird die soeben geschriebene FAT-Partition auf "hidden" gesetzt.
Das bedeutet: Auf jeder lokalen Harddisk liegt jetzt ein identisches Image!
Der eigentliche Restore Vorgang
Zuerst wird auf dem DHCP-Server ein Bootfile eingetragen, welches neben DOS6.22, Ghost und ein Utility (GDISK) zum verstecken und zurückholen von Partitions enthält. Letzteres wird in einem ersten Startvorgang benutzt um die FAT-Partition sichtbar zu machen, danach erfolgt ein Neustart. Beim zweiten Hochstarten von diesem Image wird aus einem Batchfile heraus automatisch Ghost gestartet und der Restore beginnt. Dieser dauert rund 14 Minuten anschliessend wird die FAT-Partition wieder auf "hidden" gesetzt, sowie die Maschine neu gestartet.
Nach diesem Neustart laufen die Clients in das neu aufgespielte WindowsNT-System hinein. Dabei wird sehr früh ein NT-Service von Bootix gestartet, der die DHCP-Parameter aus dem Speicherbereich des BootROM's liest und in die NT-Umgebung "hinüber rettet". Anschliessend startet ein weiterer Service, der diese maschinenspezifischen Werte in die Registry und Konfigurationsfiles schreibt, noch bevor NT das Netzwerk startet. Diese Services sind für PXE-Clients noch nicht erhältlich, sind aber angekündigt.
Weiter ist ein AutoAdmin Logon konfiguriert, damit der Rechner automatisch in den Administrator-Account einloggt. Dort wird dann nach einer Wartezeit mittels eines Batchfiles das Utility "netdom" aus dem NT-Resource-Kit aufgerufen, welches dann die Maschine in die NT-Domäne einträgt. Danach werden durch das Batchfile die Konfigurationsdateien auf der lokalen Maschine, das AutoAdmin Logon entfernt, der richtige Benutzer eingetragen und die Maschine heruntergefahren.
Dauer des ganzen Restore-Vorgangs inkl. automatischer Konfiguration: Ungefähr 18-20 Minuten.
Warum dieses zweistufige Vorgehen mit einem lokalen Image? Die Vorteile sind einerseits eine kürzere Restorezeit und andererseits kann so bei Problemen jede Maschine (im schlimmsten Fall selbst während eines laufenden Kurses!) auch einzeln in rund 20 Minuten neu aufgesetzt werden, ohne das Netzwerk zu belasten. Da dies noch nie benutzt werden musste, ist es fraglich, ob in Zukunft nicht auf eine lokale Kopie verzichtet werden soll. Die nachfolgenden Dateien stellen einen Auszug aus der gesamten Konfiguration dar.
Datei 1: Registry patchen mit bputil32 von bootix
Datei 2: Auszug aus Eudora.ini
Datei 3: Netdom in Aktion