In Alturo-Server aus Sicht
des Linuxers habe ich letzte Woche dem United-Internet-Rootserverprodukt auf den Zahn gefühlt. Deswegen lag es
natürlich nahe, den Test kurz danach mit einem Produkt von Strato zu
wiederholen.
Als Testsystem stand mir ein Gerät zur Verfügung, das man heute nicht mehr neu bestellen kann: Der Anbieter hat
sein Produktportfolio auf AMD64-basierende Systeme modernisiert. Man muss deswegen meine Aussagen etwas
relativieren.
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 $new_routers dev eth0 scope link
ip route add default via $new_routers
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.
Nachdem der Server, auf dem dieses Blog um Zeitpunkt dieses Eintrages liegt in Bälde nicht mehr existieren wird, ziehen meine Webseite um, und zwar auf meinen eigenen Server.Nachdem Root-Server ja mittlerweile "nichts" mehr kosten, habe ich bei Comment (1)
Tracked: Jan 18, 21:18
Wie bereits neulich angekündigt, habe ich meinen Mailserver torres, den letzten verbliebenen Dauerläufer in meiner Wohnung, vor ein paar Wochen abgeschaltet. Meine Mail und meinen IRC-Client habe ich seitdem auf temptorres, einen Restlaufzeitserver ei Comments (3)
Tracked: Mar 23, 15:43
Es ist mal wieder an der Zeit für einen Rootservertest. Was ich zu den Produkten von Strato und dem inzwischen nicht mehr neu bestellbaren Produkt von Alturo (das allerdings große Ähnlichkeit zu den Produkten der anderen United-Internet-Firmen hat) Comments (3)
Tracked: Sep 07, 15:41
Als Ersatz für mein Entwicklungssystem nechayev habe ich einen STRATO Power-Server S aus der Alturo-Aktion bestellt. Da seit meinem letzten Test eines STRATO-Rootservers schon wieder fast ein Jahr vergangen ist, nutze ich die Gelegenheit, meinen Test v Comments (3)
Tracked: Sep 28, 17:13
Wie mittlerweile allseits bekannt ist, stellt Alturo zum 30.11.2006 den Geschäftsbetrieb ein. Im Rahmen der Geschäftsauflösung wurden den betroffenen (Server-) Kunden vergünstigte Angebote für Server von 1&1 unterbreitet. Da aber mit Sicherheit nicht jede Comment (1)
Tracked: Oct 08, 14:29
Um endlich mal mehr Leistung zu bekommen, bin ich dabei meine Altersschwache MR2 bei Strato durch eine SR7 zu ersetzen (4G RAM, 4 Cores, 500G RAID1). Die Installation ist eine Suse 11.1 ohne Plesk. Aktuell wäre eine (von Strato nicht unterstützte) 11.2 (o Comment (1)
Tracked: May 08, 22:22