Allgemein:

Eine "Non Distructive Distribution" ( im Folgenden mit N2D abgekürzt ) ist eine Betriebssystem Installation welche auf ein vorhandenes Betriebssystem aufgesetzt werden., wobei das bereits installierte Betriebssystem nicht verändert wird. Mit einer solchen N2D läßt sich also ein Rechnersystem kurzfristig für andere Aufgaben mit einem speziellen Betriebssystem betanken.

Diese N2D wird mit LINUX erstellt und im folgenden Beschrieben.

Designkriterien

Lassen sie uns folgende selbst darstellende Frage stellen: "Warum haben Wir Was Wie gemacht ?"

1.Schnelle Installation um kostbare Zeit zu sparen und um Flexibel auf bestimmte Anforderungen reagieren zu können.

2.Einfache Installation um eine Automation zur Distributionsverteilung vornehmen zu können.

3.Die Distribution soll auf mehr als 500 Systemen innerhalb von weniger 12 Stunden verteilbar sein.

1.Die Distribution soll auf möglichst vielen Rechnersystemen im Bezug auf die Hardware- Komponenten einsetzbar sein.

2.Sie soll schnell und einfach auf die von ihr bedienten Softwareprodukte anpaßbar sein. ( Besser noch, sie soll vollkompatibel zu allen auf LINUX portierten und entwickelten Softwareprodukten sein. )

3.Sie soll jeder Zeit konfigurierbar sein.

1.Das Testen der Kernel- Hardwarekonfiguration soll schon im Vorfeld der produktiven Anwendung getestet werden können.

2.Das Testen der Installation sollte auch in kleineren Rahmen Rückschlüsse auf das Verhalten in großen Rechnernetzen oder Rechnerclustern ermöglichen.

Cluster

1.Die Distribution muß also MPP ( PVM ) Verarbeitung in einem Rechner- Netzverbund zulassen.

2.Sie muß also konkurrierende Datenströme auf den Netzsegmenten zulassen und tolerabel verarbeiten.

Ramdisk Installation oder Festplatte

sprengen würde war klar das die Platte als Medium gebraucht würde.

Konfigurationsfrei Booten

Nun galt es die Installation so flexibel zu gestalten das ohne Hardware/Softwaremodifikationen an den Zielsystemen eine funktionsfähige Installation gebootet werden konnte.

Als mögliche Installationsplätze bieten sich folgende Positionen an:

1.native ext2

2.umsdos

3.ramdisk

4.loop-root

Wegen einiger Kernelfehler kann UMSDos nicht eingesetzt werden. Statt dessen kann loop-root für die volle Funktionsbreite eingesetzt werden. Die einzige der obengenannten Installationsmöglichkeiten die nicht

in jedem Standardkernel vorhanden ist, ist allerdings loop-root. Auf der Internetseite http://www.linuxhq.com liegt eine Liste von inoffiziellen Kernel Patches unter welchem sich auch ein loop-root Patch befindet.

Loop root bedeutet das sich das Root Filesystem in einer Datei auf einem anderen Filesystem (z.b. ext2 oder FAT 16 ) befindet und zur Bootzeit über einen Loop gemounted wird. Das ermöglicht eine Installation auf einer MSDOS( FAT 16 ) /ext2 Partition ohne deren Inhalt zu modifizieren, bzw. nur durch hinzuzufügen einer Datei.

Die Temporäre RAMDISK wird durch die BOOT- Diskette angelegt, formatiert und mit dem Nötigsten initialisiert.

Netzwerktreiber

Um möglichst flexibel auf die Hardware für die Netzwerkanbindung reagieren zu können sind alle

Netzwerkkartentreiber als Module auf der Diskette vorhanden. Dieses verhindert einen möglichen Dead- Lock beim Booten durch fälschliches Autoprobing der Hardware und die Möglichkeit trotzdem alle Karten zu unterstützen.

Das Ziel ist es weiterhin alle Rechnertypen innerhalb von kurzfristigen produktiven Zusammenschaltungen zu unterstützen um eine einheitliche Distribution als Grundlagen zu definieren.

Distributionsdiskette und Konfiguration

Um die benötigte Zeit pro Rechner möglichst gering zu halten sollte im Vorhinein die Konfiguration der Hardware bekannt sein.

Sämtliche Einstellungen wie:

1.Installationsziel

2.IP Adressen

3.NFS Server

4.Zu ladende Module + IRQ/IO settings

...sind deshalb im MSDOS- Filesystem auf der Diskette als ASCII Datei vorhanden, und können

über "mtools" leicht modifiziert werden.

Um die Konfiguration der Diskette zu überprüfen muß kein NFS Server vorhanden sein. Wenn kein NFS Server vorhanden ist, "looped" das Programm bei dem Versuch einen solchen zu erreichen. Dieser Sachverhalt kann als Erfolg gelten .

Woraus besteht die Software - Pakete/Distribution ?

Die Software besteht im Hauptsächlichen aus der Debian 2.0/Hamm LINUX- Distribution.Diese ist "glibc2/libc6" basierend.

Die Installation ist auf das Nötigste zusammen geschnitten, dieses garantiert eine Installationsgröße von ca. 20MB.

Die für die aus den Designvorgaben resultierenden Aufgaben überflüssige Pakete wie z.B.: Zoneinfos, Keyboard mappings wurden entfernt.

Als Kernel kommt ein 2.0.36 mit "loop-root-patch" zum Einsatz, da die 2.1.x ( Entwickler- )

Kernel noch nicht die Stabilität liefern, die für einen professionellen Einsatz nötig ist.

Aufgrund der gestiegenen Netzperformance wäre es allerdings wünschenswert auf 2.1 bzw. später 2.2 zu

wechseln.

Die eigentliche Boot Diskette ist eine von der Debian 2.0/Hamm abstammende Rescue Disk, von dieser bleibt nicht viel mehr als Binarys wie: "ls", "mount", "umount", "mke2fs".

Modifikationen

Modifikationen an der Distribution und des Kernels

Die Distribution wurde auf das notwendigste zusammen geschnitten. Zusätzlich wurden "rshd", und "rlogind" so modifiziert das keinerlei DNS anfragen gestellt werden und keinerlei Authentisierung über ~/.rhosts und /etc/hosts.equiv vorgenommen werden, um zum Einen, die Zeit zum einloggen zu minimieren, zum Anderen mögliche

Fehlerquellen wie geänderte IP Adressen der Master Console(n), oder nicht vorhandene DNS Server zu eliminieren.

Das login Binary ist weiterhin so modifiziert, daß es einen root- login auf allen tty's unabhängig der /etc/securetty zuläßt.

Diese Modifikationen machen den Einzelnen Node zwar angreifbar allerdings ist der Cluster nicht dazu gedacht ins Netz gestellt zu werden. Die jeweiligen Patches gegen die Debian Source Packages sind ebenfalls unter ftp://move.mediaways.net/pub/cluster/testing zu finden.

Weiterhin sind einige Boot Scripte ergänzt, oder sogar neue hinzugekommen. Zur Bootzeit wird eine Standard-installation vom NFS Server geholt die nachträglich personalisiert werden muß. Hierfür werden anhand der auf eth0 konfigurierten IP Adresse /etc/hostname und /etc/hosts ergänzt bzw. erstellt um zumindest dem Rechner das Auflösen seiner eigenen Adresse zu ermöglichen.

Weiterhin muß nach dem fsck der Root- Partition (nicht vorher wie üblich) dafür gesorgt werden das ausreichend Swap vorhanden ist. Hierfür wird via fdisk auf allen bekannten Platten nach bestehenden Swap Partitions gesucht und falls vorhanden werden diese aktiviert.

Ist danach noch immer nicht genügend Swap vorhanden erstellt das Bootupscript (außer bei "ramdisk install") ein Swapfile im Root- Verzeichnis der Installation ("partition install") oder auf /bootfs wo im "loop- root" Fall das Filesystem mit der Loop- Datei gemounted ist.

Zusätzlich zu den Modifikationen an der eigentlichen Distribution sind drei System- User hinzugekommen (pvm34, rc5 und povray) die dazu dienen sollen die eigentlichen Applikationen laufen zu lassen.

Der pvm34- User soll es ermöglichen mit der Aktuellen development PVM Version 3.4beta7 zu Experimentieren. In Homedir des Users ist ein pvm3d vorhanden sowie der Beispielclient "mtile" um

verteilte Fraktalberechnung (Apfelmännchen) zu testen.

Unter dem User "povray" ist die aktuellen Version von povray (3.02) zu finden, die es ermöglicht ein verteiltes povray ( nicht distpov oder pvmpov) zu testen. Eventuell wird eine angepaßte Povray Version noch hinzu- gefügt um Spezielle Effekte in uns angebotenen Filmen mit abzudecken.

Als zusätzliches Programm für das verteilte Povray ist unter /usr/local/sbin das tool "mw_client" vorhanden was eine RPC ( Remote Procedure Call ) gestützte Kommunikation ermöglicht um Povray jobs/frames zu

verteilen. Dieses Programm ist speziell für diese Anwendung in einer Cluster- Umgebung von

Roger Butenuth (butenuth@uni-paderborn.de) entwickelt worden und ermöglicht das verteilte Rechnen von Povray Animationen.

Das Client Server Modell ist allerdings so flexibel gehalten das die Lösung jeglicher Art von verteilten Problemen, bei denen sich ein Teilproblem mit einem Aufruf eines Programms mit unterschiedlichen

Commandline Options lösen läßt, möglich ist.

Distributionsdiskette ( Cluster - Einsatz )

Das interessanteste an der Diskette ist das in der initrd (root.bin) vorhandene script "linuxrc" das in Abhängigkeit der auf der Diskette vorhandenen Config Dateien (ip.cfg, dst.cfg, mod.cfg) die entsprechenden Module lädt, Filesysteme Mounted, Interfaces Konfiguriert, die Installation über NFS holt und auf dem Ziel Filesystem installiert und schlußendlich dort weiterbootet.

Der im Kernel verwendete loop-root-patch ist eine erweiterte Version des auf linuxhq.com vorhandenen. Der Original Patch ließ es nicht zu, zur Laufzeit der Initrd den loop-root-name, also den Namen der Loop Datei zu setzen und damit das loop- root zu aktivieren.

Der modifizierte Patch ist unter http://move.mediaways.net/pub/cluster/testing zu finden, in der 2.0.36 Version und der 2.1.122 Version. Dieser Patch ergänzt das /proc filesystem um ein /proc/sys/kernel/loop-root-name.

Theoretisch ist es möglich jede Linux Distribution mit mehr oder weniger Aufwand so zu modifizieren das sie für diesen Einsatzfall zu benutzen. Natürlich ist die Wahl durch das Wissen um die Distribution bestimmt. Daneben hat die Debian Distribution folgende große Vorteile.

1.Sämtliche Modifikationen der Debian Pakete (nicht contrib oder non-free) können ohne Lizenrechtliche Bedenken wieder veröffentlicht werden. (So hier geschehen.)

2.Sehr einfache Boot Scripte und damit leicht zu modifizieren.

3.Extrem zu verkleinern (Auf unter 16MB)

4.Sehr striktes einhalten des FSSTND

Es haben schon Schulen angefragt in wieweit die bestehenden Funktionalitäten dazu einsetzbar sind im Unterricht auch Linux zu benutzen. - Ganz grundsätzlich ist dieses kein Problem. Es wird einfach pro Rechner eine Boot Diskette erstellt die sämtliche Personality enthält um den Rechner booten zu lassen.

Der Vorteil liegt auf der Hand. Bei jedem Reboot wird neu installiert d.h. es besteht nicht die Gefahr das ein Rechner nicht einsetzbar ist. Die Funktionalität der Distribution kann hierbei Zentral auf einem Server gesteuert werden.

Es können durch hinzufügen oder entfernen von Paketen die Installation an den Unterricht angepaßt werden. Durch Installation eines Automounters und NIS ist es außerdem möglich Zentrale Benutzerverwaltung und Home- Directorys zu realisieren.

 

Performance

Die Installation (Von Einlegen der Diskette bis zum Login prompt) dauert in einer etwas älteren Version 105 Sekunden. Dadurch das zusätzliche PCMCIA Support mit aufgenommen wurde, wird sich die Zeit um ca. 10-20 Sekunden verlängert haben. Diese Werte gelten für die Installation auf einer native ext2 Partition mit 200MB.

Benchmarks für die "loop-root" Installation liegen derzeit nicht vor, allerdings spricht der Originalautor des Patches von nahezu identischer Performance von ext2-loop-ext2 und native ext2 . Der Loop-root-ext2 auf MSDOS soll allerdings nur halb so schnell sein was an schlechter Performance des mmaps bei MSDOS Filesystems liegen soll.