Hardware

Der Server selbst hat Hardware mit durchaus "Bums". Eine Hyperthreading-P4-CPU mit 3 GHz, 1 GB Speicher und eine 120-GB-Platte sind ja fast luxuriös. Wie bei allen neueren Strato-Server gibt es eine serielle Konsole. Der Server hat zwei e1000-Netzwerkinterfaces, von denen natürlich nur eine in Verwendung ist, und die auch "nur" mit 100 Mbit.

Webinterface

Das Webinterface sieht seinem UI-Pendant durchaus ähnlich. Man kann hier Verbrauchsdaten abrufen und erhält auch - hübsch - Informationen über Servicefenster etc.

Das Rettungssystem ist hier nicht Debian-basierend, sondern ist ein eher schlichtes und einiges an Wünschen offen lassendes LFS.

Zur Initialisierung stehen nur ältere Systeme (so z.B. ein Debian woody) zur Verfügung.

Standardimage Debian

Strato bietet hier das seit über einem halben Jahr veraltete Debian woody an, das zwar heute noch Security-Support hat, aber aufgrund seiner aus dem Jahr 2002 stammenden Basis nur noch museal verwendbar scheint. Die Paketliste sieht aus, als ob man hier einen mit dem Standard-woody installierten Server, der schon ein paar Monate in Benutzung war, geklont und abgespeckt hat: mutt, pppoe, fdutils und ein paar andere verwundernde Packages sind removed, aber nicht gepurged: Sie hängen also noch in der Paketliste herum und die Konfigdateien sind auch noch da.

Die Netzwerkkonfiguration kommt per dhcpcd und sieht ähnlich aus wie bei United: Ein /32, eine "dev eth0 scope link" Route auf das im gleichen /24 "ganz unten" liegende Gateway und eine Defaultroute dorthin. Allerdings wird die Sonderroute nicht wie bei UI "sauber" per DHCP übermittelt, sondern mit einem irgendwo versteckten Script (ich hab's nicht gefunden) manuell reingeprügelt - der DHCP-Server übermittelt "langweilig" die IP-Adresse, die Netzmaske und das Defaultgateway, und ein normaler DHCP-Client beschwert sich dann über ein nicht erreichbares Defaultgateway.

Rettungssystem

Das Rettungssystem ist - wie oben erwähnt - ein LFS, das einiges an Wünschen übrig lässt. Die ärgerlichste Unterlassungssünde ist meiner Meinung nach, dass weder Kernel noch Userspace LVM-Unterstützung haben. Da muss ich mir also bei der Installation "meines" Debians gewaltig was einfallen lassen.

Ich frage mich, warum man sich hier die unglaubliche Arbeit eines LFS-Eigenbaus macht, wenn das, was am Ende rauskommt, schlechter ist als das Produkt der Konkurrenz und natürlich auch von frei erhältlichen Lösungen wie grml locker abgehängt wird.

Bei jeder Wahl des Rettungssystems wird ein neues Rootpasswort dynamisch generiert - das ist besser gelöst als bei UI.

Installation des zgserver-Standardimages

Das war - wegen des LVM-losen Rettungssystems - eine wirkliche Herausforderung. Ich habe diese Herausforderung so gelöst, dass ich erst einmal LVM-los installiert habe, wobei /usr, /home und /var übergangsweise konventionell in der Partition gelandet sind, die später als swapspace zur Verfügung stehen wird. Dem DHCP-Client von Debian sarge habe ich ein hook-Script zur Seite gestellt:

/etc/dhcp3/dhclient-exit-hooks.d/local

!/bin/bash

if ip route | grep -q '^default via'; then
  # we already have a default gateway
  :
else
  ip route add $newrouters dev eth0 scope link
  ip route add default via $newrouters
fi

Sprich: wenn nach dem Ablauf der DHCP-Prozedur keine Defaultroute gibt, dann etabliere eine "dev eth0 scope link" Route, die das übermittelte Defaultgateway erreichbar macht - danach sollte die Defaultroute setzbar sein.

Die serielle Konsole betreibt Strato mit unüblichen 57600 bps, so dass ich im ersten Bootversuch in das neue System erstmal auf die Nase fiel - mein System geht von den üblichen 9600 bps aus, was natürlich mit dem fest konfigurierten Konsolenserver nicht geht. Man muss die Bitrate an drei Stellen (/etc/inittab, in der Kernelkommandozeile und der grub-Konfiguration) ändern.

A propos serielle Konsole: Sie ist per ssh erreichbar, Username, Passwort und Hostname findet man im Webfrontend.

Nach dem ersten Boot in das neue System stand die Migration zum LVM an: Volumes anlegen, Filesysteme anlegen. Nach / wechseln, root werden, Prozesse stoppen. Schließlich ein exec /bin/sh, um auch die Locale-Files von /usr freizubekommen (die Bash will partout locale-Files offen halten, wenn sie als /bin/bash aufgerufen wird). Dann konnte das temporäre Filesystem von /mnt umounted und nach /mnt.temp remounted werden. Mount der neuen LVs nach /mnt/foo,
umkopieren der Daten, umount /mnt.temp, mkswap, /etc/fstab anpassen, swapon -a, mount /mnt/foo, und wir waren wieder im Geschäft. Ich hab sicherheitshalber nochmal gebootet. Die ganze Aktion war dank serieller Konsole erheblich entspannter als die DHCP-Basteleien auf dem Alturo-Server letzte Woche.

Das Rettungssystem taugt jetzt freilich nur noch für absolute Notreparaturen am Root-Filesystem, denn aus dem Rettungssystem gibt es mangels LVM-Fähigkeit weder /home noch /usr. Ich hoffe, dass sich diese Entscheidung nicht im Nachhinein als falsch erweist. Momentan ist es mir allerdings wichtiger, dass das Produktivsystem die auf meinen Systemen üblichen Devices und Mountpoints hat, und auch die Flexibilität des LVM will man bei einer 120-GByte-Platte meiner Meinung nach haben.

Fazit

Der Strato-Server ist zum dreifachen Preis des Alturo-Billigservers eine "richtige" Maschine mit
ernstzunehmender Hardware und hat eine benutzbare serielle Konsole. Dafür muss man empfindliche Einschnitte auf Systemseite hernehmen: Das LVM-lose Rettungssystem ist ein major turn-off, und die "ab Werk" verfügbaren vorinstallierbaren Systeme sind nicht mehr zeitgemäß. Ich hoffe, dass mit den neuen, heute bestellbaren Servern auch die Betriebssysteme ein wenig modernisiert wurden - und dem Macher des Rescuesystems würde ich empfehlen, ein bisschen weniger "not invented here" zu spielen. Die "draußen" verfügbaren Lösungen sind größtenteils überlegen.

Mein Urteil: Das System ist genauso akzeptabel wie das von UI. Die Nachteile liegen woanders, und das Optimum scheint es wie so oft nicht zu geben.