Hallo Welt, willkommen zur inoffiziellen Website Projektdokumentation vom Schulserver an der Grundschule Bergmark. Im Folgenden werden wir einen Überblick über den Fortschritt dieses Projektes geben.
Beteiligt an diesem Projekt sind zur Zeit die Grundschule Berg-Mark-Straße, Wuppertaler Linux User Group e.V. (WupLUG.org) und das Medienzentrum Wuppertal. Im Einzelnen handelt es sich dabei um:
Einige Passagen und Textblöcke wurden nicht von mir geschrieben, sondern durch triviales cut and paste hier eingefügt. Das gilt insbesondere für die von mir übernommene Zusammenfassung vom aktuellen Projektstatus vom Bram Anfang dieses Jahres.
Diese Seite erhebt keinen Anspruch auf Vollständigkeit, weder inhaltlich, den aktuellen Stand betreffend noch bezüglich der beteiligten Personen. Gefundene Rechtschreibfehler dürfen behalten werden.
Den ersten Kontakt mit der Grundschule hatte der Bram irgendwann im Jahre 2002, als eine Anfrage vom Axel über eine sinnvolle Hardwareausstattung für einen kleinen Schulserver bei ihm im Postfach landete. TODO. Ende 2002 bekamen wir dann die Nachricht, daß der Server an die Schule geliefert wurde und wir uns zum ersten Mal verabredeten, um das Wunder moderner Intel-Architektur bestaunen zu dürfen.
An diesem Tag konnten wir nur ein paar Vorbereitungen treffen, denn es gab etliche Hindernisse.
Hardwareprobleme:
Softwareprobleme:
Nachdem die Hardwareprobleme inzwischen beseitigt wurden und wir es uns mit vier Laptops gemütlich gemacht haben, wurden in Akkordtempo etliche Serverdienste installiert und konfiguriert:
Diesmal gab es nur kleinere Feinheiten zu regeln:
Was bleibt sind noch ein paar Kleinigkeiten.
Heute haben der Arno und ich an der Schule Opphof gewerkelt. Ein historischer Tag, da es sich um den ersten Compaq-Server außerhalb unserer gewohnten Test-Umgebung - Berg-Mark - handelt. Unseren ursprünglichen Plan, die Installation der Server durch clonen der Masterinstallation mit Hilfe einer bootfähigen CD durchzuführen, haben wir zunächst mal auf Eis gelegt: Das dafür vorgesehene Paket arbeitet nicht so, wie es soll, bzw. es wären noch einige Anpassungen nötig, für die aber die Zeit zu knapp war. Also wurden die Rechner auf die natürlichste Art geclont, die es in diesem Falle gab: Immerhin handelt es sich hier ja um ein RAID 1 System, d.h. die beiden Platten enthalten ja schon eine 1:1 Kopie des Systems. Was lag also näher, als einfach eine Platte aus einem laufenden System zu entnehmen und in einen neuen Rechner einzusetzen.
Damit das aber so klappte, war jedoch noch eine Änderung am Lilo notwendig (s.u. TODO link). Danach konnte das System mit beiden Platten, aber auch nur mit einer von beiden Platten gestartet werden. Sehr vorteilhaft bei der ganzen Angelegenheit erwieß sich die Tatsache, daß das System immer von SCSI-ID #0 booten will, so das eine bootfähige Platte mit ID #0 vorhanden sein muß. Bei den Compaq-Servern fängt die Zählung unten an, also sollte die Platte mit System ganz unten eingesetzt werden, die leere Platte dann als nächstes darüber. Somit hat die neue (leere) HD immer die ID #1. Das vereinfacht dann unsere Skripte, die jetzt immer davon ausgehen können, daß ID #0 immer die vorhandene und ID #1 immer die neue, leere Platte ist.
Eine weitere Änderung, die wir noch gemacht haben (danke Aron für diesen Tipp), ist das Umwandeln von den zwei Swap-Partitionen (pro Platte eine) in ebenfalls ein RAID 1 Verbund. Damit ist sichergestellt, daß auch der Swap-Bereich auf beide Platten gespiegelt wird und somit der Ausfall einer Platte in jedem Fall die Funktionalität des Systems nicht beeinflußt. Also wurde ein der Swap zunächst einmal abgeschaltet (swapoff -a), ein neuer RAID-Verbund /dev/md1 in der /etc/raidtab angelegt, mit mkraid /dev/md1 das neue RAID 1 erzeugt, mit mkswap /dev/md1 die Swap-Partition formatiert und schließlich wieder mit swapon /dev/md1 aktiviert. Damit beim nächsten Booten der Swap automatisch antiviert wird, mußte noch eine Änderung in /etc/fstab vorgenommen werden. Läuft. Es war fast zu einfach. *gg*
Um nun eine neue Platte in der RAID-Verbund zu integrieren, benutzen wir das Kommando raidhotadd, mit dessen Hilfe wir
eine neue Partition zu einem bestehen, laufenden, aktiven RAID-Verbund hinzufügen können. Beispiel. Das Kommando fdisk -l
/dev/sda liefert uns den Partitiontable der ersten (a) SCSI-Platte (sd), zusammen also sda:
root@server:~# fdisk -l /dev/sda
Disk /dev/sda: 255 heads, 63 sectors, 4427 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 33 265072 fd Linux raid autodetect
/dev/sda2 34 4427 35294805 fd Linux raid autodetect
root@server:~#
TODO.
| Typenbezeichnung: | TODO |
| Prozessor: | Intel XEON 1.80 GHz Hyperthreading |
| Speicher: | 512 MB ECC |
| Storagesystem: | Onboard Dual Adaptec SCSI Controller (AIC7899P) Intel RAID Controller |
| Festplatten: | 3 x 18 GB TODO 10K RPM SCSI Wide Ultra 160 HotSwap |
| Netzwerk: | Onboard 100 MBit Intel Ethernet Pro 100 (82557) Onboard 1000 MBit Intel Gigabit Ethernet Controller (82544GC) |
| Betriebsystem: | Debian GNU/Linux (Stable/Woody) |
| Datensicherheit: | Hardware RAID 5 mit 3 x 18 GB |
| Typenbezeichnung: | TODO |
| Prozessor: | Intel XEON 2.40 GHz Hyperthreading |
| Speicher: | 512 MB ECC |
| Storagesystem: | Onboard Adaptec SCSI Controller (AIC7TODO) |
| Festplatten: | 2 x 36.4 GB 10K RPM SCSI Wide Ultra 320 HotSwap |
| Netzwerk: | Onboard 1000 MBit Broadcom Tigon3 kompatibel |
| Betriebsystem: | Debian GNU/Linux (Stable/Woody) |
| Datensicherheit: | Software RAID 1 (mirror) mit 2 x 36 GB |
TODODa es sich bei dem Compaq-Server-RAID um ein Software-RAID handelt (das OS kümmert sich darum, daß die Daten auf die richtigen Platten geschrieben wird), ist beim Booten im Gegensatz zum Hardware-RAID (hier kümmert sich ein spezieller Controller um alles) etwas mehr Aufwand nötig:
Sobald der Kernel den Treiber für den SCSI-Controller initialisiert und die beiden Platten gefunden hat, erkennt das unbedingt in den Kernel eincompilierte raid1-modul automatisch, daß sich auf den beiden Festplatten ein RAID 1 befindet und startet dieses, so daß es unter /dev/md0 erreichbar wird. Kurz danach wird /dev/md0 als root-entry gemountet, also als Filesystem-Wurzel eingebunden, und normal weitergebootet.
Sollte eine der beiden Platten ausfallen, arbeitet das System normal weiter. Das wird dadurch erreicht, daß alle Daten, die gespeichert werden sollen, gleichzeitig auf beide Platten geschrieben werden. Die Schreibperformance wird dadurch fast nicht beeinflußt, die Leseperformance wird um TODO Prozent von TODO MB/s auf TODO MB/s gesteigert. Administriert und beobachtet wird das Software-RAID mit dem Kommando mdadm. Dieses Tool informiert auch automatisch den zuständigen Admin für diesen Server via Mail, sollte irgend etwas mit dem RAID nicht stimmen, z.B. den Ausfall oder die manuelle Entnahme einer Platte.
Das System ist in der Lage, mit nur einer Platte zu booten. Damit das System von einer beliebigen Festplatte booten kann, ist unbebingt die lilo-option raid-extra-boot=auto notwendig, damit der lilo auf beide Platten geschrieben wird. Außerdem sollte nicht nur das root-Device auf /dev/md0 gesetzt sein, sondern ebenfalls das boot-Device ist auf /dev/md0 zu setzen. Lilo ist seit einiger Zeit in der Lage (ich glaub ab Version 22.0), zu erkennen, daß es sich bei dem boot-Device um kein normales Device handelt, sondern um ein RAID 1 und der Lilo den Bootcode entsprechend auf beide (oder besser: alle) Platten verteilt, so daß von jeder Platte im RAID-Verbund aus gebootet werden kann.
Um die Lehrer vor Ort nicht zu sehr mit betriebsystemspezifischen Problemen zu belasten (einspielen, updaten oder deinstallieren von Software, anpassen und konfigurieren von Diensten, absichern der Server), wird die Möglichkeit zur Fernadministration angeboten. Dabei ergab sich zunächst einmal das Problem, daß der Server hinter einem Bintec-Router steht, der wiederum keine (einfache, ohne Update der Firmware) Möglichkeit bietet, um von außen auf interne Hosts zugreifen zu können (kein Port-forwarding, keine dyn-dns-module, keine vpn-funktionalität). Die Lösung (in meinen Augen sogar die äußerst elegante Lösung) des Problems ist ein vom Server zu einer festen IP aufgebauter verschlüsselter Tunnel. Dieser wird, sobald der Server sich ins Internet einklingt, aufgebaut und man kann ohne Probleme vom anderen Tunnelende den Server erreichen. Diese Lösung arbeitet wunderbar über den NAT-Router transparent hinweg. Die Installation und Wartung ist dank des verwendeten openVPN ein Kinderspiel und trotzdem sehr sicher. Es ergeben sich folgende Vorteile: