Zugschlusbeobachtungen (Entries tagged as hosting)

Mietserver-Recovery mit veraltetem Rescuesystem

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 24 Mar 2008 23:07:00 +0100

Den First Dedicated Power Server S Limited Edition benutze ich seit ziemlich genau einem Jahr als Entwicklungssystem. Da die Kiste ausschließlich verschlüsselt mit der Außenwelt spricht, sind die Schwächen im Netzwerksetup des Hosters für meine Anwendung irrelevant. Als nicht irrelevant zeigten sich vor einigen Wochen die Macken im Rescuesystem, als ein Umstieg auf neue Hardware anstand.

Mein Server hat im Herbst letzten Jahres angefangen, SMART-Fehlermeldungen zu werfen, und Anfang Februar wurde es mir dann zu bunt, so dass ich ein Ticket beim Hoster aufgemacht habe. Der Hoster findet bei einer oberflächlichen Prüfung des Systems, die mit einem knappen halben Tag Downtime verbunden war, keine Fehler und tauscht mir kulanterweise das PATA-Kabel. Leider hilft das nicht, die SMART- und CRC-Fehler im Syslog tauchen schnell wieder auf.

Als nächstes versucht der Hoster, die Schuld auf mein System zu schieben (“Fehlerhaftes Dateisystem oder Bugs im verwendeten Kernel”) und möchte, dass ich den Server neu aufsetze. Ich versuche das erstmal zu vermeiden und versuche das Problem mit dem Rescue-System zu reproduzieren. Das erweist sich aber als leichter gesagt als getan, denn das Rescuesystem ist - ich berichtete - so alt, dass ich damit meine Filesysteme nicht eingehängt bekomme. Und durch irgendwelche dd-Übungen ist das System nicht zum Werfen von CRC-Fehlern zu bringen.

Also rsynce ich die Daten zähneknirschend auf einen anderen Server (um mir das Restore vom Wohnungs-Backup über mein dünnes ADSL zu ersparen), mache eine Neuinstallation auf das Uralt-Standardimage des Anbieters, update auf aktuelles Debian etch mit security-Updates und beginne meine Daten draufzukopieren. Keine fünf Minuten später beginnen wieder die CRC-Fehler.

Nun ist der Hoster auch überzeugt und bietet mir den Tausch gegen eine komplett neue Maschine an, die dann auch eine neue IP bekommt. Das stört mich nicht, da ich das System ja nur inten verwende, also stimme ich zu. Leider ist es nicht möglich, Zugang auf beide Maschinen gleichzeitig zu bekommen; zuerst wird die alte abgeschaltet und dann für die neue Zugangsdaten generiert. Am Abend desselben Tages kommen die Zugangsdaten für die neue Kiste; ab dem ersten Kontakt bis hier sind sechs Tage vergangen.

Die Zugangsdaten für den neuen Server teilen mir mit, dass ich mich in das Rescuessystem mit grml@ip-adresse einloggen soll. Das funktioniert allerdings nicht, und das auf Port 22 sichtbare Banner mit dem String “Debian woody” lässt vermuten, dass ich es hier auch nicht mit einem grml zu tun habe, sondern mit dem “alten” Rescuesystem. Nach einer Stunde sind dann auch die Zugangsdaten in das System konfiguriert und ich kann mich endlich - als root - anmelden.

Wie schon im Servertest erwähnt, ist das Rescesystem von First Dedicated uralt. Es basiert irgendwo auf Debian woody, hat weder LVM-Support im Kernel noch die Userspace-Tools installiert und läuft noch mit Linux 2.4. Damit direkt mein LVM- und Linux-2.6-basierendes System wieder draufzuklatschen ist illusorisch. Also anders.

Ich entschliesse mich, wie schon bei einem anderen Hoster neulich durchgespielt, ein grml-small in die swap-Partition zu installieren. Aber dann kommt mir die Idee, dass das gar nicht not tut: Ich habe doch ein nicht im LVM liegendes ext2-Filesystem, nämlich das System, das im Produktivbetrieb als root eingehängt ist. Spricht eigentlich nichts dagegen, das grml dort abzulegen - dann steht es schneller zur Verfügung, wenn im Notfall das Root-Filesystem noch da ist. Wenn es nicht mehr da ist, kann man dann immer noch den Stunt mit dem swap-Filesystem machen.

Also wird schwupps die Platte partitioniert, das root-Filesystem auf hda1 angelegt und dessen Inhalt aus dem Backup zurückgeschoben. Nach /boot/grml kommt der Inhalt einer grml-small-CD. grml-medium hatte ich zu dem Zeitpunkt noch nicht ausprobiert; der Trick hätte aber nach den einschlägigen Erfahrungen aus der Erstellung meines Universal-Boot-Sticks auch mit grml-medium funktioniert.

Die für grml-small gültige Boot-Eintragung lautet:

title           grml
root            (hd0,0)
kernel          /boot/grml/linux26 toram grml_dir=/boot/grml/GRML/ grml_name=GRML toram ramdisk_size=100000
init=/etc/init lang=us BOOT_IMAGE=grml ssh=M9flN0A1
initrd          /boot/grml/minirt26.gz

und ich schätze, dass die für grml-medium irgendetwas rund um

title           grml-medium
root            (hd0,0)
kernel          /boot/grml/boot/grmlmedium/linux26 live-media-path=/grml-medium/live/ toram=grml-medium.squashfs lang=us
boot=live noeject noprompt keyboard=de
initrd          /boot/grml/boot/grmlmedium/initrd.gz

heißen müsste. Das hab nich aber nicht ausprobiert.

Nun nur noch grub auf der Platte installieren. Unter Debian liegt das grub-Binary in /usr und steht somit im vorliegenden Zustand des Systems nicht zur Verfügung; das Rescuesystem hat kein grub. Also schwupps die binäre grub-Package aus Debian stable gezogen, mit dpkg-deb ausgepackt und... festgestellt, dass die Libraries des Rescuesystems zu alt sind um das dynamisch gelinkte grub-Binary auszuführen. Ich spare mir den Bugreport “please build a new package with statically linked grub”, weil grub in Debian nicht mehr wirklich gepflegt wird - die Maintainer sind der Meinung, dass man die Arbeit besser in grub 2 stecken sollte, und ich bin der Meinung, dass bis zur rudimentären Benutzbarkeit von grub 2 noch ein wenig Wasser den Neckar wird herunter fliessen müssen.

Statt dessen wird /boot/grub in /boot/grub-backup umbenannt, ein historisches grub aus woody ausgepackt, die stages nach /boot/grub geschoben, menu.lst kopiert und auf der grub-shell installiert. Da der Server keine serielle Konsole hat, muss mit dem default-Keyword gearbeitet werden (die Einträge zählen ab Null, #451709), und schwupps läuft das grml.

Der Rest ist schnell erzählt: LVM bauen, Filesysteme anlegen, Daten zurück-rsyncen, chroot ins frisch restorete System, IP-Adresse anpassen, /boot/grub nach /boot/woody-grub umbenennen, /boot/grub-backup zurückschieben, “aktuellen” grub neu installieren, booten und Produktivbetrieb aufnehmen. Das grml bleibt da für zukünftige Aktionen liegen, mit dem aktuellen Grub lässt es sich ja auch nach Anpassung des Default-Wertes in der menu.lst kurzfristig booten.

First Dedicated Power Server S Limited Edition

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 20 Mar 2007 22:02:21 +0100

Ich habe damals entgegen meiner Ankündigung meinen Hetzner DS1000 nicht gekündigt und das System als torres.zugschlus.de in Betrieb genommen. Dabei wäre es geblieben, wenn nicht Hetzner zum 1. April 2007 den Preis für den DS1000 von 19,90 auf 29,90 Euro erhöhen würde.

Das habe ich zum Anlass genommen, einkaufen zu gehen und bin diesmal bei First Dedicated gelandet. Dort gibt es - nach Anwendung eines Einkaufstricks - einen Celeron 2400 mit 512 MB und 80 GB Platte für 19,90 Euro im Monat. Das ist eine ganz ähnliche Maschine wie der Strato-Powerserver, für den ich 29 Euro im Monat bezahle. Für zehn Euro weniger Geld gibt es auch eine ganze Menge weniger Leistung. You get what you pay for.

Bei der Webhostlist ist der Power Server S Limited Edition für 19,90 Euro im Monat aufgeführt; auf der Webseite von First Dedicated kostet dieser Server ohne “Limited Edition” 29,00 Euro, und die Limited Edition finde ich nicht. Kurzes googeln nach “site:firstdedicated.de power server limited edition” findet das Neunzehn-Euro-Angebot dann doch, und ich bestelle für eine Vertragslaufzeit von 18 Monaten bei Null Euro Einrichtungsgebühr.

Als Mobilfunknummer, auf deren Eingabe das System besteht, gebe ich die Nummer von Frank geht ran ein, was sich kurz danach als Fehler erweist: Das Bestellsystem schickt einem per E-Mail einen Link, und auf der verlinkten Webseite muss man einen Aktivierungscode eingeben, den man per SMS zugestellt bekommt. Hmpf.

Also schnell beim Callcenter angerufen (01805, gut erreichbar, kompetent, hilfsbereit) und versichern lassen, dass ein nicht bestätigter Auftrag sich selbst automatisch rückstandsfrei entsorgt. Dann das ganze nochmal mit richtiger Mobilfunknummer.

Schon eine knappe Stunde später ist der Server betriebsbereit übergeben. Alle Passworte, inklusive dem nicht veränderbaren Passwort für das Rescuesystem, kommen in einer einzigen Mail.

Hardware

Der Rechner ist ein Celeron 2,4 GHz mit 128 KB Cache. Er hat 512 MB Speicher und eine per PATA angebundene 80-GB-Platte. Als Netzwerkinterface ist ein VIA Rhine II eingebaut, der mit dem via-rhine Modul neuerer Kernel funktioniert. Das ganze ist meinem Strato PowerServer S nicht unähnlich.

Webinterface

Das Webinterface ist eher spartanisch: Es ist nur per http erreichbar, und außer der Systemauswahl (“Normal”, “Rettungssystem”, “Eigener Kernel”), dem Resetknopf, dem Eingabefeld für den Reverse DNS und dem Knopf für die automatische Neuinstallation kann man nicht mehr viel einstellen.

Standardimage

Das im Default auf dem System installierte Image habe ich - wie üblich - vergessen anzugucken. Nur, dass ich die Maschine so schnell in den Produktivbetrieb prügeln müsste, dass leider auch keine Zeit war, es zur Begutachtung nochmal aufzuspielen. Was ich gesehen habe, war ein sarge direkt aus der Box, mit einem 2.4-Kernel. Nun denn.

Bemerkenswert ist vielleicht, dass das Firstdedicated-System auch im Normalbetrieb den Kernel aus dem Netz bootet. Auf dem System liegt ein viel älterer Kernel als der, der dann wirklich läuft. Das bedeutet auch, dass man im Webinterface “Eigener Kernel” auswählen muss, wenn man ein eigenes System installiert hat - denn der Kernel aus dem Netz passt wirklich nur zum vorinstallierten System.

Netzwerkkonfiguration

Der Server steht mitten in einem /24 und wird ohne Klimmzüge direkt per DHCP konfiguriert. Das bedeutet allerdings auch, dass es mit der Sicherheit nicht so weit her ist: Da alle Server dieses IP-Netzes in derselben Broadcastdomain liegen, ist es relativ einfach, Man-in-the-Middle zu spielen und die IP-Adresse eines Nachbarn zu übernehmen oder durch ARP-Tricks dessen Traffic mitzulesen. Zum Test konfiguriere ich eine weit entfernte, aber frei scheinende IP-Adresse als zweite Adresse auf meinem Interface, und kann meine Maschine sofort erreichen. Nicht schön, das ist nicht mehr zeitgemäß und bietet einige fiese Einfallstore. Dass diese auch schon in der Vergangenheit ausgenutzt wurden, zeigt, dass mein Host im IRCnet restricted ist, und das System somit nicht zum uneingeschränkten Chatten geeignet ist.

In diesem Punkt kommt First Dedicated also nochmal eine Nummer schlechter weg als Hetzner im letzten Herbst, die inzwischen auch bezüglich ihrer Netzarchitektur nachgebessert haben.

Rescuesystem

Das Rescuesystem ist zweifellos einer der Tiefpunkte im Produkt von First Dedicated. Es handelt sich hierbei um ein sehr arg abgespecktes Debian, das auch wieder nur einen 2.4-Kernel hat. Der Kernel kommt aus dem Netz, und /usr wird - read/write! - per NFS eingehängt. Der Versuch, Software nachzuinstallieren, scheitert jedoch an “read-only file system”. Da ist also wohl noch ein Sicherheitsmechanismus dazwischen. Trotzdem sind manche Dinge, die man im Rescuesystem macht, persistent - so bleibt zum Beispiel das Home-Directory des root-Accounts über Rescuesystem-Aufrufe hinweg enthalten. Das ist gut, denn der PATH enthält im Default keins der sbin-Verzeichnisse, so dass meine Scripte erst nach Installation einer .bashrc laufen, die einen für root angemessenen PATH setzt.

Da im Userspace des Rescuesystems jegliche LVM-Tools fehlen, installiere ich zunächst einen normalen zgserver in die Partition, die später swap werden soll. Das dabei auftretende Fußschußpotenzial nutze ich voll aus: Man kann eine Partition mit Partitionstyp “Linux swap” zwar problemlos mit einem ext3-Filesystem formatieren, mounten und mit Daten betanken, grub legt sich dann aber bei der Installation erstmal königlich auf die Schnauze. Weiterhin möchte man - siehe oben - den Kernel im Webinterface wirklich auf “Eigener Kernel” setzen, denn sonst geht gar nichts.

Nachdem diese Unwägbarkeiten umschifft sind, kann ich endlich den LVM bauen. Eine erneute Installation meines zgservers kann ich mir sparen, denn die neue Maschine soll ein bereits existierendes und derzeit auf einem Strato-Server laufendes System übernehmen, damit meine torres von dem derzeitigen Hetzner-Server auf den dann freiwerdenden Strato-Server umziehen kann. Ich verbringe also den guten Teil des Resttages damit, einem 30-GB-rsync mit vielen Maildirs zuzugucken.

Nachdem das neue System erstmal nicht starten will, stelle ich fest, dass die auf einer LVM-LV liegenden Systemlogs aus dem Firstdedicated-Rescuesystem nicht einsehbar sind und rate eine mögliche Fehlerursache: udev. Kurzer Blick nach /etc/udev/rules.d/z25_persistent-net.rules bestätigt den Verdacht: Der Name eth0 ist noch von der MAC-Adresse des “alten” Interfaces belegt, so dass das einzig vorhandene Interface der “neuen” Maschine auf eth1 landet - für das keine Konfiguration in der /etc/network/interfaces vorhanden ist. Ein beherztes rm /etc/udev/rules.d/z25_persistent-net.rules und folgender Reboot löst das Problem und das System kommt brav ans Netz.

Fazit

Ein billiges Angebot. Mit Haupt- (Netzwerkstruktur) und Nebenleistungen (Rescuesystem) weit unter dem Durchschnitt. Aber dem Preis angemessen. Ich werde mein Entwicklungs- und Testsystem, das sowieso fast ausschließlich nur verschlüsselt und kryptografisch authentifiziert mit der Außenwelt kommuniziert, auf der First-Dedicated-Hardware betreiben. Einen Server bei der derzeitigen Preisentwicklung für 18 Monate für 19 Euro im Monat zu haben, kann praktisch sein.

Es bleibt die Hoffnung, dass im Netz von First Dedicated irgendwann mal so viel Missbrauch geschieht, dass man dort freiwillig anfängt, eine zeitgemäße Netzwerkstruktur auszurollen. Bis dahin muss man halt aufpassen, was man tut, und sich darüber im Klaren sein, dass manche Dienste nicht verfügbar sind.

Hetzner DS 3000

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 07 Oct 2006 10:52:00 +0200

kju hat mir netterweise einen Server von Hetzner zum Test zur Verfügung gestellt. Der DS 3000 ist ein Athlon 64 3700+ mit 1 GB RAM und zwei 160 GB-SATA-Platten inklusive 6 IP-Adressen, 50 GB Backupspace und einer Trafficflatrate. Das Spiel kostet 99 Euro Einrichtungsgebühr, 39 Euro im Monat und ist monatlich zu kündigen.

Der Server wurde problemlos am 2006-09-30 abends (also schon nach dem Beginn des großen Alturo-Runs) bestellt und am 2006-10-05 gegen 22.00 Uhr geliefert. Den Bestellprozess habe ich bei diesem “gespendeten” Server natürlich nicht selbst durchlaufen. Zum Produkt gehörende Features wie Zusatz-IP-Adressen, Backupspace und Servierüberwachung müssen gesondert nachbestellt werden. Es gibt keinen “Firlefanz” wie Bestätigungsrückrufe, zum Anbieter zu faxende Papierdokumente etc.

Hardware

Der gelieferte Rechner hat einen ein mit 2.2 wirklichen GHz getakteten Prozessor und entspricht der Spezifikation. Zwei baugleiche Samsung-Platten hängen per SATA an einem VIA-Chipsatz; als Netzwerkkarte dient eine RTL-8169, die aber nur mit 100 Mbit am Switch hängt. Letzteres hat ein Geschmäckle, da das Gigabit-Ethernet-Interface in der Serverbeschreibung ausdrücklich und deutlich beworben wird.

Webinterface

Das Webinterface ist wenig überraschend. Trafficauswertung, Auftragsschnittstelle, Resetservice, Rescuesystem, alles da was man braucht (wenn auch nicht unbedingt an der Stelle, wo man die einzelnen Menüpunkte erwarten würde). Die Reaktion von Reverse DNS und Reset sind schnell; die Aktionen finden sofort statt. Beim Reverse DNS kann man beliebige Werte eintragen; eine Prüfung wie bei der Konkurrenz findet nicht statt. Das finde ich angenehm, weil es die Migration erleichtert, bietet natürlich aber dem Anfänger jede Menge Möglichkeiten um sich selbst in den Fuß zu schiessen.

Aus dem Rettungssystem kann man per Shellkommando die Neuinstallation anstoßen. Dabei kann man zuerst aus einer recht reichhaltigen Auswahl wählen, welches System man installieren möchte und wird dann in einen Editor geworfen, in dem man per Textdatei auf das zu installierende System Einfluss nehmen kann. So kann man auch beeinflussen, wie die Platte zu partitionieren ist. Hübsch, wenn es ein bisschen fehlertoleranter wäre: Gleich mein erster Versuch mit Partition 2 als root und “so groß wie möglich” und 10 GB in Partition 3 für /home geht mit fiesen Scriptfehlern daneben. Im nächsten Versuch wähle ich dann Debian 3.1 64 bit und belasse die Einstellungen beim Default; diesmal funktioniert es.

Standardimage

In der Defaultkonfiguration besteht das System aus einer großen ext3-Partition, auf der das 328 MB große System installiert ist. Der einzige nach außen offene Port ist tcp/22; Webserver, Mailserver etc sind nicht installiert. An überflüssigen Packages finde ich die komplette Suite von Packages für PPP und PPPoE, die auf diesem System sicher überflüssig sind, hotplug, Tools für CD-ROM- und Floppylaufwerk, rdate, ein dhcp2-client, einige überflüssige Libraries sowie Teile des gcc verschiedener Versionen. Als root-passwort ist das Passwort des Rescue-Systems gesetzt. Ein Teil der instalierten Packages ist “kept back”.

Das 32-bit-Image ist genauso.

Der einkonfigurierte Debian-Mirror ftp.uni-erlangen.de ist aus dem Nürnberger Rechenzentrum via Frankfurt und Hannover erreichbar.

Netzwerkkonfiguration

Die Netzwerkkonfiguration ist statisch in der /etc/network/interfaces eingetragen. Im System kommt die folgende Konfiguration (anonymisiert) an:

# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:16:17:98:42:d7 brd ff:ff:ff:ff:ff:ff
    inet a.b.c.208/27 brd a.b.c.223 scope global eth0
    inet6 <snip>/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
# ip route
a.b.c.192/27 via a.b.c.193 dev eth0
a.b.c.192/27 dev eth0  proto kernel  scope link  src a.b.c.208
default via a.b.c.193 dev eth0
#

Die IP-Adressen sind aus 88/8. Wir stellen fest, dass das System in einem /27 liegt, wobei durch eine extra eingetragene Netzwerkroute der Traffic innerhalb des /27 auch über das Defaultgateway geschoben wird. Wie ich später feststelle, ist das System auch ohne diese Sonderroute uneingeschränkt konnektiert. Das später zugewiesene /29 ist aus einem anderen /24.

Ein tcpdump auf dem Interface zeigt schnell, dass hier wie in einem “normalen” LAN verschiedene Kundensysteme in einer Broadcastdomain liegen: Ich sehe ARP-Requests für “fremde” IP-Adressen und sogar vereinzelte Pakete mit Nutzdaten. Darüber bin ich sehr erschreckt, denn ein solches Setup mit vielen verschiedenen, potenziell bösartigen Systemen ist schon seit Jahren nicht mehr zeitgemäß. Aus dem später beauftragten /29-Netz sind nur fünf IP-Adressen nutzbar, da unnötigerweise Netz-, Broadcast- und sogar eine Gatewayadresse weggeschnitten sind.

Netzsicherheit

Was ich in diesem Kapitel erwähne, habe ich nicht selbst ausprobiert, da mein Gastgeber mich gebeten hat, derartige Experimente zu unterlassen. Die Experimente wurden aber von einem anderen Hetzner-Kunden durchgeführt, dem ich unbedingt vertraue.

Bei Hetzner liegen mehrere Kundensysteme innerhalb einer Broadcastdomain. Es ist durch einfache Konfiguration einer fremden IP-Adresse auf das Interface möglich, diese IP-Adresse zu benutzen. Sprich: Will man einen Nachbarn belauschen, braucht man ihn nur aus dem Netz zu flooden, seine IP-Adresse zu übernehmen und schon hat man seinen Datenverkehr auf dem Silbertablett. Mit den gängigen ARP-Angriffen dürfte es möglich sein, dies auch unbemerkt durch das eigentliche Opfer durchzuführen. Sehr unschön.

Vor diesem Hintegrund wundert mich nicht, dass Hetzner ständig Ärger mit den Betreibern der großen IRC-Netze hat. Hetzner hat in seinem Netz den Port tcp/6667 gesperrt, um Botnetze zu verhindern, und behält sich weitere Portsperren in seinen AGB vor. Trotzdem sind die Netze von Hetzner in vielen IRC-Netzen mit einer K-Line von der Teilnahme ausgeschlossen. Das wundert mich wenig, da ich von IRC-Experten erfahren habe, dass es wohl inzwischen Bot-Tools gibt, die größere Netzbereiche rund um die eigene IP nach freien IP-Adressen durchsuchen und dann diese IP-Adressen für weitere Connections ins IRC-Netz missbrauchen. Das funktioniert natürlich in einem so simpel designten Netz wie bei Hetzner hervorragend.

Da sind die anderen Anbieter im Markt besser, die üblicherweise wenigstens die IP-Adresse statisch mit der MAC-Adresse verknüpfen, so dass simple ARP-Angriffe oder simple Übernahmen unautorisierter IP-Adressen nicht erfolgreich sind. Strato und UI gehen sogar so weit, dass die einzelnen Kundensysteme nur /32-“Netze” zugewiesen bekommen und nicht mit anderen Systemen in einer Broadcastdomain liegen. Damit kann man nicht einmal durch die Übernahme einer fremden MAC-Adresse andere Systeme beeinflussen. So gehört sich das. Die einzige von mir wahrgenommene Sicherheitsmaßnahme ist die oben erwähnte Sonderroute auf den Systemen selbst, die aber natürlich wirkungslos ist, da sie einfachst entfernt werden kann.

Per Mail auf diesen Mißstand hingewiesen, reagierte Hetzner sinngemäß mit “Ja, das ist in unserem Netz möglich. Wir kriegen das aber raus und ergreifen dann disziplinarische Maßnahmen.”. Muß ich extra dazu schreiben, dass ich diese Politik unangemessen finde?

In das sehr zweifelhafte Bild passt dann auch noch das von Hetzner angebotene User-Web-Forum. Grundsätzlich nehme ich ein solches Angebot als sehr positiv wahr. Allerdings sind im Hetzner-Forum auch etliche Leute mit mehr oder weniger gesundem Halbwissen und umgekert proportionaler Überzeugung von der eigenen Kompetenz unterwegs. Es muss echt nicht sein, dass auf die Frage, warum von einem extra zugewiesenen /29 nur fünf Adressen nutzbar sind, ein Mitglied mit dem Status “Lebende Foren Legende” sinngemäß antwortet mit “Ja, so ist das beim Subnetting halt. Das sollte man als Rootserverbetreiber wissen”. Ich verlange von einem Rootserverbetreiber jedenfalls nicht das Wissen, dass man bei einem ordentlich designten Netz durchaus alle acht Adressen eines /29 für Dienste nutzen kann, wenn eine andere IP fürs Routing zur Verfügung steht (was hier ja der Fall ist). Natürlich kam dann auch noch ein “Haudegen” dazu, der eine Aufnahmeprüfung für Rootserverkunden verlangte. Was in diesem Forum passiert, ist jedenfalls nicht schön. Ob der im Forum aktive Hetzner-Supporter wirklich so wenig von IP weiß wie man aus seinen Beiträgen vermuten möchte, kann ich freilich nicht beurteilen - ich mache erst seit fünfzehn Jahren IP.

Installation des zgserver-Standardimages

Das klappt problemlos im zweiten Versuch, nachdem der erste Versuch daran gescheitert ist, dass ich zwar daran gedacht hatte, einen Kernel mit SATA-Unterstützung zu bauen, diesen aber dann nicht installiert hatte. Mein Standardimage ist allerdings nur i386, also 32 bit, und somit auf diesem Rechner nicht empfehlenswert verwendbar.

Fazit

Ein großer Server zu einem verträglichen Preis. Leider ist das Netzdesign auf dem Stand von 1999 stehen geblieben, so dass ein Hetzner-Server aus meinem Standpunkt unter der Berücksichtigung des entstehenden Sicherheitsrisikos derzeit nicht für sicherheitsrelevante Dinge wie DNS oder Mail empfehlenswert ist. Ob die Connectivity für private Streaming- oder Gameserver gut genug ist, vermag ich nicht zu beurteilen.

Ich denke aufgrund dieser Testergebnisse derzeit darüber nach, meinen eigenen DS 1000, der bis heute nicht geliefert ist, grad wieder zu kündigen.

STRATO Power-Server S

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 28 Sep 2006 16:03:00 +0200

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 von damals zu wiederholen und den Testbericht entsprechend anzupassen.

Bestellprozess

Der Power-Server S ist ein nicht hyperthreadingfähiger Celeron mit 2.4 GHz, 512 MB RAM und einer 80-GB-Festplatte. Der am Sonntagabend um 20.00 Uhr bestellte Server wird nach Klick auf einen per E-Mail übermittelten Verifikationslink und Eingabe einer auf Mausklick von einem Telefonroboter übermittelten PIN innerhalb von fünf Stunden kurz nach Mitternacht betriebsbereit bereitgestellt. Eindrucksvoll.

Vorinstallierte Systeme

Hier hat man deutlich modernisiert gegenüber früher und bietet nun SuSE 9.3 Professional und Debian 3.1 in jeweils zwei Versionen an; einmal mit “ServerAdmin Pro” und einmal “für Profis” (also vermutlich ohne Webfrontend). Zusätzlich gibt es SuSE 10.0 OSS und Fedora Core 3 “für Profis”. Die Neuinstallation mit Debian 3.1 für Profis dauert eine knappe Stunde.

Vorinstalliertes Debian

Das Debian sarge kommt auf drei Partitionen (hda1 = /boot, hda2 = swap, hda3 = /) und ist gegenüber dem im letzten Jahr gesehenen woody in viel besserem Zustand. Die Packageliste ist bis auf im Zuge von Securityupdates entfernte, aber nicht gepurgete Kernel-Images sauber. Die sources.list ist sauber konfiguriert; allerdings ist das System auf dem Security-Update-Stand von vor vier Monaten. So ist zum Beispiel ein root privilege escalation bug in passwd nicht gefixt und wartet darauf, dass der lokale Admin manuell die aktuellen Security-Updates installiert. Bei der Installation der Updates entfährt mir spontan ein “Igitt, das ist ja Deutsch!”

Auch auf diesem System verstehe ich nicht, wo die Hostroute für das Defaultgateway herkommt. Im IRC verrät man mir, dass der dhcpcd automatisch eine Hostroute für das Defaultgateway generiert, um es erreichbar zu machen. Dieses Verhalten überrascht mich, aber da ich dhcpcd nicht kenne, glaube ich das mal. Weitere Tests habe ich mit dem System nicht gemacht.

Rescue-System

Am Rescue-System hat sich leider nichts gebessert: Kein LVM-Support und sehr spartanische Umgebung dank Linux from Scratch. Ebenso dauert der Start des Rescue-Systems sehr lange. Abzug.

Migration von Alturo

Die Migration vom Alturo-Server zum neuen Strato-System läuft ähnlich wie die damalige Installation meines Standard-Images: Grundsystem mit LVM-Support in die Swappartition installiern, dort LVM und Filesysteme bauen und mounten, und die Daten vom alten System herüber-rsyncen. Dann das “richtige” System bootfähig machen (und in die üblichen Fallen “serielle Konsole mit unüblicher Baudrate” und “DHCP-Client” fallen).

Fazit

Der Strato Power-Server S ist ein gegenüber dem damals getesteten Server vorsichtig modernisiert worden. Die größte Macke, das viele Wünsche offen lassende Rescuesystem, besteht nach wie vor; die von mir angemäkelten Ungereimtheiten beim vorinstallierten System wurden größtenteils behoben.

dedizierter Low-Cost-Rootserver von Netdirekt

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 07 Sep 2006 15:02:32 +0200

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) geschrieben habe, findet man in den referenzierten Artikeln.

Im heutigen Test geht es um den für fünfzehn Euro im Monat erhältlichen 733-MHz-Server von Netdirekt.

Netdirekt bietet einen kleinen Server mit 733-MHz-Prozessor, 256 MB Hauptspeicher und 10 GB Festplatte zusammen mit 500 GB Transfervolumen zum Preis von EUR 15,00 bei 12 Monaten Laufzeit an. Will man monatliche Kündigungsfrist, zahlt man pro Monat fünf Euro mehr. Backupspace gehört nicht zum Angebot; dafür gibt es auf Anforderung bis zu drei IP-Adressen und ein 99.5%-SLA. Netdirekt sagt zu, defekte Hardware innerhalb von zwei Stunden zu tauschen - ohne Beschränkung auf die Geschäftszeiten. Sportlich und mutig.

Bestellprozess und Lieferzeit

Ich bestelle Mitte August per Webinterface und bekomme wenig später den Link zu einem PDF-Dokument, das ich unterschrieben an Netdirekt faxen soll. Nochmal wenig später kommt am 18. August per Mail die Bestätigung, dass der Server bis spätestens 04. September freigeschaltet wird. Hm. Über zwei Wochen Lieferzeit? Das geht sicher besser.

Hardware

Der Server wird auch tatsächlich erst am 04. September “geliefert” und ist ein wenig größer als die ursprünglich angebotene Maschine: 866 MHz hat der Prozessor und die Platte 15 GB. Als Netzinterface gibt es einen e100.

Kaufmännisches

In der “Fertigmeldung” steht auch einiges zur kaufmännischen Abwicklung: Netdirekt liefert auf offene Rechnung und empfiehlt die Anlage eines Dauerauftrags oder einer Einzugsermächtigung. Finde ich fair, dem Benutzer auf diese Weise die Wahl zu lassen. Unschön, dass sich das aus dem Webinterface herunterladbade Formular nicht als Einzugsermächtigung, sondern als Abbuchungsauftrag entpuppt. Auch schade, dass die als PDF versandte Online-Rechnung keine Signatur hat und es auch keine Möglichkeit gibt, sich die Rechnung gegen Aufpreis zusenden zu lassen. Also nix mit Vorsteuer ziehen.

Webinterface

Das Webinterface ist schnörkellos und funktional. Man sieht dort - im Gegensatz zu UI und Strato - eine grafische Trafficauswertung und kann Trafficwarnungen konfigurieren und die Zusatz-IPs ordern. Reset und Rescuesystem findet man hier genauso wie die Einstellung für den Reverse-DNS. Die kostenlos im Angebot enthaltene Neuinstallation des Ursprungs-Images stößt man per Konsolenkommando des gebooteten Rescuesystems an. Dort steht ein Minimal-Debian, ein Debian mit Admin-Webfrontend, Fedore Core 4 minimal, SuSE 9.3 minimal sowie - ausdrücklich als “Beta Test” gekennzeichnet - CentOS und Ubuntu zr Verfügung. Danach kann man dem System in der Konsolensession beim Download und Auspacken des Images zugucken.

Standardimage

Das vorgegebene Standardimage belegt 709 MB auf der nur in einer großen Partition hda1 bestehenden Platte und lässt mich nicht in Begeisterung ausbrechen. Die Packageauswahl ist freundlich gesprochen extrem konservativ, unfreundlich gesprochen nicht mehr zeitgemäß: apache 1.3, proftpd, sendmail, qpopper, portmapper, mysqld, rpc.dracd (für smtp-after-pop) sind installiert und lauschen alle auf 0.0.0.0; außerdem ist wie auch bei der Konkurrenz ein gcc installiert. Die im Laufe der Evolution des Systems herausgeworfenen Packages wurden nur removed und nicht gepurged. So kann man problemlos sehen, dass auf dem Mastersystem schonmal ein exim4, ein courier-mta und ein postfix installiert waren. Vom Courier ist sogar die Konfiguration noch vorhanden; die von exim und postfix hat man manuell abgeräumt.

Deutlich besser ist das minimale Debian-Sarge-Image. Hier kommt als MTA der Default exim4 zum Einsatz, der dank eines Tippfehlers in der /etc/exim4/update-exim4.conf.conf unkonfiguriert auf 0.0.0.0 läuft (siehe auch Debian Bug #386554). Auch hier hat man viele Packages nicht gepurged, und auch hier ist der gcc installiert. Das Minimalsystem belegt 476 MB.

Rescue-System

Der Aufruf des Rescue-Systems ist anders gelöst als bei den beiden großen. Wählt man den entsprechenden Menüpunkt an, bekommt man eine Mail, in der das neue Rootpasswort steht. Dieses Passwort muss man dann nochmal im Webinterface eingeben, damit der Reboot ins Rescuesystem eingeleitet wird. Dabei operiert das Webinterface stateless. Sprich: Ein aus dem Rescuesystem ausgelöster Reboot führt zwingend wieder ins Produktivsystem zurück; wenn man nur das Rescuesystem rebooten möchte (damit es z.B. Veränderungen an der Partitionierung sicher aufgreift) muss man wieder ins Webinterface.

Dieses Verfahren finde ich weniger schön als den rein webbasierten Prozess von Strato und UI. Denn auf diese Weise werden Passworte unverschlüsselt über das Netz gepustet (der ausgehende Mailserver von Netdirekt benutzt kein TLS), und man kann die Administration des Servers nicht delegieren.

Das für meinen Server zur Verfügung gestellte Debian-basierende Rescuesystem hatte einen Designfehler, der LVM unbenutzbar machte: Zum Kernel 2.6 war nur die Userspace-Package für LVM 1 installiert. Also ein Grund um den Support zu testen, der den Test mit Bravour bestand: Es dauerte nicht einmal 80 Minuten, bis der Fehler im Rescuesystem behoben und LVM 2 nachinstalliert war. Dabei fand ich heraus, dass das Rescuesystem nicht wie bei den anderen aus dem Netz kommt, sondern dass der Server wirklich ein physikalisches CD-ROM-Laufwerk hat, in dem eine echte CD liegt. Der Rechner bootet grundsätzlich von CD; über ein Keyboard-Dongle wird dann entschieden, ob von CD oder von Festplatte weitergebootet werden soll.

Die Authentifikation per ssh-Key funktioniert ohne Überraschungen; die Netzwerkkonfiguration fällt “vom Himmel”. Die /etc/network/interfaces des Rescuesystems enthält nur den Abschnitt für lo.

Installation des zgserver-Standardimages

Die Installation meines Standardimages läuft wie erwartet problemlos, wobei - wie schon erwartet - die Netzkonfiguration Ärger macht: Auch bei Netdirekt muss man zuerst eine Netzwerkroute für das nicht im lokalen IP-Netz liegende Defaultgateway setzen, bevor man die Defaultroute setzt. Allerdings arbeitet Netdirekt nicht per DHCP, so dass die /etc/network/interfaces manuell konfiguriert werden muss - was scheitert, wenn man die normale “gateway”-Klausel verwendet (da zu dem Zeitpunkt, zu dem die Defaultroute gesetzt wird das Gateway noch nicht erreichbar ist). So:

auto eth0
iface eth0 inet static
        address 84.16.252.249
        netmask 255.255.255.255
        broadcast 84.16.252.249
        up ip route add to 217.20.117.0/28 dev eth0
        up ip route add default via 217.20.117.1

funktioniert es jedenfalls.

In der Nacharbeit zu diesem Artikel verrät mir Netdirekt, wie man ein Standardimage installiert. In diesem ist das Netz ganz straightforward mit der IP-Adresse des Servers in einem /24 mit Gateway auf der .1 konfiguriert; ich hätte mir also den ganzen Zirkus sparen können. Nun ja, hinterher ist man immer schlauer

Fazit

Der Server von Netdirekt hat nach dem Abgang von Alturo ein sehr gutes Preis-Leistungs-Verhältnis. Die minmalen Abstriche, die man machen muss, liegen im “you get what you pay for” Bereich. Besser als ein vServer ist dieses “richtige Blech” allemal.

Dieser Artikel wurde nach Eingang einer ausführlichen Stellungnahme von netdirekt überarbeitet. Vielen Dank dafür an den netdirekt-Support.

Alturo-Service gemessen am Preis Top

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 18 May 2006 18:00:00 +0200

Nach dem neulich beobachteten Fehlalarm hatte mein erster Alturo-Server nechayev in den letzten Tagen eine wirkliche Störung. Unter hoher CPU-Last gab es Kernel-Oopses und Segfaults.

Mit dem Alturo-Service bin ich gemessen an dem, was ich dem Anbieter bezahle, völlig zufrieden. Für professionellen Einsatz will man allerdings Ausfallsicherungsmaßnahmen vornehmen.

Da nechayev meine Testmaschine mit Debian unstable und einem “blutende Kante” Kernel ist, war der erste Gedanke natürlich ein Fehler im lokalen System. Ich habe deswegen die Maschine in das von Alturo bereitgestellte Rescuesystem gebootet, die Platte gemounted und meine Standardübung “bzip2 eines unkomprimierten Kernel-tars” angeworfen. Kernel-Oops und segfault des bzip2-Prozesses. Damit ist ein Hardwarefehler Verdachtsmoment Nummer Eins.

Diesmal spare ich mir die 0900-Hotline, sondern sende gleich über die Alturo-Webseite eine Nachricht. Das Webinterface für Supportnachrichten ist arg versteckt unter “Support”, “Fragen zur Technik”. Dort muss man dann eine der vier unpassenden Kategorien (“E-Mail”, “Domain”, “FTP-SSH-FrontPage” oder “PHP-Perl-MySQL” - andere gibt es nicht) auswählen und kann dort dann unter “keine Antwort gefunden?” eine Nachricht hinterlassen.

Am nächsten Tag meldet sich ein Techniker per Mail, der für einen Lasttest einen relativ offenen root-Zugang auf dem System haben möchte. Das Rescue-System reicht nicht aus, aber md5sum, wget, bzip2 und screen sind akzeptabel. Root-Login per Passwort muss von überall her möglich sein, und das Passwort muss auf das im Alturo-Webfrontend unveränderbar vorgegebene Masterpasswort gesetzt sein. Dabei ist mir überhaupt nicht wohl, aber wenn das der Prozess ist, muss man da mitspielen.

Ich mache ein rsync-Backup auf torres und nehme mir vor, den Rechner nach Behebung der Probleme neu zu installieren. Schließlich öffne ich den Server wie gewünscht und melde Vollzug.

Das Ticket wird einmal am Tag angefasst, und zwar immer vom gleichen Techniker. Ich habe etappenweise den Verdacht, es hier mit einer Art “Jennifer Römer” zu tun zu haben. Die Turnaround-Zeit von 24 Stunden verzögert die Sache dann doch erheblich.

Schließlich beginnt Alturo mit dem angekündigten Lasttest, der aus je drei im Screen gestarteten tar-bzip2-prozessen von /mnt nach /dev/null und drei md5sum-Prozessen über das Gesamtsystem besteht. Der Supporter kommt dabei von einem ganz normalen t-ipconnect.de-Zugang, also vermutlich einem 1und1-DSL-Zugang. Den Lasttest hält der Server gerade mal eine Stunde durch und verabschiedet sich dann ganz komplett.

Am nächsten Tag kommt dann die Mail, dass der Fall an den Vor-Ort-Service weitergegeben wurde, und am gleichen Tag werde ich informiert, dass “die Hardware rund um die Festplatte” komplett getauscht wurde. Was in dieser Mail nicht drin steht ist, dass nach solchen Arbeiten der Server grundsätzlich im Rescue-System stehen gelassen wird, damit der Kunde selbst entscheiden kann, wann das System in den Wirkbetrieb zurückkehrt. Ich interpretierte das “System steht im Rescuesystem und ich hab das Passwort nicht” fälschlicherweise als “es wird noch gearbeitet” und hole mir noch einmal die Bestätigung ab, dass ich das System wieder übernehmen kann. Diese Bestätigung kommt schon nach einer Stunde.

Ich spiele daraufhin das Backup zurück, fixe die dabei entstandenen verdrehten uids und gids und kehre in den Wirkbetrieb zurück. Der Server arbeitet seitdem wieder im Rahmen der normalen Parameter, ist aber leider nach wie vor “nur” ein 1200-MHz-Celeron mit 256 MB und entspricht somit der Produktbeschreibung.

Alturo hat diesen Supportfall vorbildlich behandelt. Defekte Hardware wurde als defekt erkannt, ohne zu versuchen, dem Kunden die Schuld in die Schuhe zu schieben. Der Tausch ging problemlos und schmerzfrei ohne Datenverlust von sich. Kritikpunkte bleiben die lange Turnaroundzeit im Mailverkehr und die Forderung, gefährliche Sicherheitslöcher im System aufzureißen um den Lasttest zu ermöglichen. Diese Kritikpunkte sind aber vor dem Hintergrund, dass es sich um ein Billigprodukt der untersten Preisklasse handelt, vernachlässigbar.

Alles über alles hat die Behebung der Serverstörung drei Arbeitstage gebraucht. Auch das ist vor dem Hintergrund des Produktpreises völlig in Ordnung. Wenn auf einem Server wichtige Funktionen laufen, sollte man einen zweiten in der Hinterhand haben, um die Dienst kurzfristiger wieder online zu bekommen.

Rootserver-Anbieter drehen an der Preisschraube

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 20 Apr 2006 10:51:15 +0200

Bei Alturo sind die Billigserver “ausverkauft” - es klebt ein entsprechendes Banner über den Angeboten. Strato hat den “richtigen” Billigserver noch besser versteckt und einen neuen, großen VServer für 24 Euro im Monat ins Programm genommen.

Mietserverkomfort auf echter Hardware ist somit ein gutes Stück teurer geworden. Hoffen wir mal darauf, dass Alturo bald wieder ein paar Racks alter Server findet. Grund zur Hoffnung gibt es: Mein Anfang April ausgelaufener Alturo-Server ist bis jetzt noch nicht wieder in Betrieb gegangen. Jedenfalls nicht unter der alten IP-Adresse.

Update: Der Artikel wurde korrigiert. kju hat mich netterweise darauf hingewiesen, dass Strato den Server doch noch anbietet, nur an besser versteckter Stelle.

Ein halbes Gigabyte!

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 26 Mar 2006 20:50:00 +0200

Nachdem auf Strato oder Alturo ein Hoffnung machender Kommentar kam, hab ich schließlich den Weg des geringsten Risikos gewählt und habe die neue torres bei Alturo bestellt. Der Testanruf kam schon nach einer halben Stunde, und zwei Stunden später war der Server verfügbar und eingerichtet. Und, wie bei El Loco ist meine neue torres ebenfalls ein Pentium III 1.26 GHz mit 512 MB RAM. Das ist mehr als von Alturo versprochen, und für die geplante Anwendung mit Spamassassin mehr als ausreichend. Ich bin begeistert. Danke, Alturo!

Den Sonntag habe ich dann damit verbracht, mein Install-Script zu modularisieren und zu perfektionieren, um torres damit zu installieren. Bald ist es soweit, dass man es veröffentlichen kann - ich wurde oft danach gefragt, bezweifle aber, dass es anderen Leuten was bringt.

Wermutstropfen ist natürlich, dass das Bestellfrontend von Alturo nur eine Bankverbindung pro Kunden zulässg und ich die neue torres auf demselben Vertrag bestellt habe, in dem auch nechayev, mein erster Alturo-Server (Debian sid) untergebracht ist. Und nechayev wird eigentlich von meiner Mutter bezahlt. Wurde, denn ich musste nach meinem fehler mit torres natürlich die Bankverbindung ändern und lasse nun das Geld für beide Server von meinem Konto abbuchen.

Strato oder Alturo

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 23 Mar 2006 14:43:31 +0100

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 eines Bekannten gehabt. Diese Restlaufzeit endet am 3. April, und ich muss mir deswegen Gedanken machen, wie ich diese für mich wichtigen Dienste in Zukunft abbilde.

Dass es ein Billitsch-Mietserver bei einem der großen Anbieter werden soll, ist klar. Stellt sich nur die Frage, ob Strato oder Alturo. Praktische Erfahrungen habe ich mit den Produkten beider Anbieter, jetzt gilt es, politisch und kaufmännisch zu handeln. Beide Produkte haben ihre Vor- und Nachteile, und sind hinreichend unterschiedlich, um die Entscheidung schwer zu machen.

	Strato	Alturo
CPU	Celeron 2400	Celeron 1200
Speicher	512 MB	256 MB
Platte	60 GB	80 GB
Backup	4,90/Monat	inklusive
Serielle Konsole	ja	nein
Einrichtungsgebühr	0,00	49,90
monatliche Gebühr	29,90	14,99
Laufzeit	18 Monate (die letzten 3 Monate ohne monatliche Kosten)	3 Monate
Hotline	01805	0900 (1,90/Minute)
Inklusivtraffic	1000G	200G
Kosten über Laufzeit	536,70	319,72

Das sieht doch aus wie ein fairer Deal: Strato liefert doppelt so viel Rechner wie Alturo, dafür ist es auch doppelt so teuer. Ich glaube, die neue torres wird ein Alturoserver, wenn auch 256 MB RAM für einen Mailserver mit Spamassassin arg knapp sind.

Oder hat noch jemand Argumente, die mich doch zum Strato-Server wechseln lasssen? Ich meine ausser dem, dass nechayev schon ein Alturo-Server ist und somit Störungen bei Alturo gleich beide Server wegkicken könnten.

Alturo-Server ausgefallen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 17 Mar 2006 20:20:19 +0100

Um kurz vor acht kam von meinem Nagios die Meldung, dass der Alturo-Server, der mir derzeit als Entwicklungssystem dient, aus dem Netz gefallen ist. Auch ein Reset über das Alturo-Webinterface bringt das System nicht zurück. Die Systeme auf den “daneben liegenden” IP-Adressen sind da, also muss das “meine” Hardware sein.

Also, rund zwei Euro in die Alturo-Hotline investiert. Das Gespräch ging keine 30 Sekunden. Kundennummer angeben, “Server nicht mehr im Netz, reboot ins Recue-System hilft auch nicht” - “Ok, ich geb das weiter.” Eine Ticketnummer verraten will man mir nicht, “nützt Ihnen ja eh nix”. Sicherheitshalber schieb ich noch eine zweite Meldung über das (vermutlich unpassende) Webformular und hoffe nun, dass es ansatzweise so etwas wie einen Wochenenddienst gibt.

Wenn ich mir das Preisschild auf dem von mir gemieteten Server angucke, befürchte ich, dass das System irgendwann Mitte bis Ende nächster Woche wieder online kommen wird, und zwar mit frisch geleerter Platte. Von wann war eigentlich das letzte Backup?

Ich werde hier weiter berichten.

Kaum hatte ich den “Save”-Button gedrückt, war der Server auch schon wieder da. Danke, RZ-Service, das war flott. Hut ab, da kann sich mancher Hochpreishoster eine Scheibe abschneiden.

Nochmal Rootserver, diesmal Strato

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 10 Dec 2005 23:08:10 +0100

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.

Alturo-Server aus Sicht des Linuxers

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 04 Dec 2005 09:38:32 +0100

Dank der lieben Kooperation eines Ex-Kollegen konnte ich in den letzten Tagen einen Alturo Webserver Plus testen. Die üblichen Dinge (Anbindung, Hardware, Service, Qualität der vorinstallierten Systeme) haben die Zeitschriften alle schon auf Herz und Nieren auseinander genommen, also habe ich mich darauf konzentriert, wie die Wartungs- und Rettungsmöglichkeiten aussehen, und wie schwer es ist, ein eigenes System auf dem System zu installieren.

Webfrontend

Dreh- und Angelpunkt der Administration ist natürlich das Alturo-Webinterface. Dort logged man sich mit seiner Kundennummer und einem Webpasswort ein und erhält dann Zugriff auf alle Alturo-Webserver, die mit diesem Vertrag assoziiert sind.

Man kann das Reverse Mapping für die IP-Adresse einstellen, wobei das Webinterface nur PTR-Werte akzeptiert, die auch schon forward auf die zugewiesene IP-Adresse auflösen. Die Reverse-Zone ist mit einer TTL von 24 Stunden veröffentlicht.

Im Menüpunkt “Serverdaten” findet man die IP-Adresse, den von Alturo vorgegebenen Servernamen, den “Bearbeitungszustand” und das Master-Passwort, mit dem man im Rescue-System und im Defaultzustand der vorkonfigurierten Server-Images per ssh auf eine Shell des Benutzers root kommt.

Der Menüpunkt “Recovery-Tool” erlaubt, den Server “hart” zu resetten (der Reset wird ein bis zwei Minuten nach Auslösung im Webinterface ausgeführt) und zu wählen, welches System beim nächsten Systemstart starten soll. Zur Auswahl steht - natürlich - der Boot von der lokalen Platte (“Normales System”) und zwei Linux Rescue-Systeme. Beide sind im Webfrontend mit “debian/woody” angekündigt, entpuppen sich allerdings als aktuelles Debian stable, also sarge. Der Unterschied besteht im Kernel; es steht ein 2.4 und ein 2.6 zur Verfügung. Ich habe ausschließlich mit dem Kernel 2.6 gearbeitet.

Der nächste Menüpunkt “Server-Initialisierung” bietet die Möglichkeit, den Server restlos zu plätten
und mit einem der verschiedenen von Alturo vorgegebenen Installationsimages neu aufzusetzen.

Das dauert in etwa eine Stunde. Zur Auswahl stehen:

Debian 3.0 (woody) Minimalsystem

Debian 3.1 (sarge) Minimalsystem

SUSE 9.1 Minimalsystem

SUSE 9.1 mit Confixx Professional 3.0.x (das ist der default und das einzige System, für das es telefonischen und E-Mail-Support gibt)

Fedora Core 2 Minimalsystem

Es stehen 40 GB per ftp erreichbarer Backup-Space zur Verfügung, den ich mir nicht näher angeguckt habe.

Ebenfalls nicht näher betrachtet habe ich das Administrations-Frontend für die de-Domain, die man zusammen mit dem Server zwangsweise aufs Auge gedrückt bekommt. Ich vermute, dass sie United-Internet-typisch sehr eingeschränkt konfigurierbar ist - das ist selbst in den teuren Schlund-Produkten nur sehr wenig befriedigend realisiert.

Ein Frontend zur Abfrage des bereits verbrauchten Traffic-Kontingents findet man unter “Vertragsverwaltung / Kostenübersicht”. Die Anzeige hängt geschätzt 24 bis 36 Stunden hinterher.

Debian sarge aus dem Standardimage

Ich habe mir hier nur das Debian sarge Image angeschaut; es handelt sich hier um ein für meine Begriffe deutlich zu fettes System, das vermutlich 1:1 aus dem Debian-Installer kommt: Es ist ein C-Compiler installiert, und außerdem existiert Software für PPPoE und PCMCIA, was auf dieser Maschine sicherlich niemals gebraucht wird.

Das System erhält seine Netzkonfiguration per DHCP:


[1/23]mh@ivanova:~$ ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP /> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:40:63:c7:b9:11 brd ff:ff:ff:ff:ff:ff
    inet 82.165.x.y/32 brd 82.165.x.y scope global eth0
    inet6 fe80::240:63ff:fec7:b911/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
[2/24]mh@ivanova:~$ ip route
10.255.255.1 dev eth0  scope link
default via 10.255.255.1 dev eth0
[3/25]mh@ivanova:~$

Man beachte hier das /32 auf dem Ethernet und die Hostroute zum auf einer site local IP liegende Defaultgateway. Leider hat dieses Defaultgateway auch in den per DHCP zugewiesenen Alturo-DNS-Servern keinen PTR-Eintrag, so dass man in einem Trace “raus” immer eine nackte IP-Adresse in der ersten Zeile stehen hat.

Obwohl in der /etc/network/interfaces ein trivial aussehendes “iface eth0 inet dhcp” steht, ist das ganze etwas mehr tricky: Die beiden Routen werden im DHCP-Client mit einem lokalen Hook-Script unter /etc/dhcp3/dhclient-exit-hooks.d/local in das System hineingeprügelt. Leider ist das Script in keinster Weise kommentiert, so dass ich nicht weiß, ob das ein “normales” Script oder eins von Alturo ist. Zum “normalen” Lieferumfang von dhcp3-client gehört es jedenfalls nicht, und ausserdem scheint noch ein static-routes im “request”-Kommando in der /etc/dhcp/dhclient.conf notwendig zu sein, damit der Server in einem selbst gebauten System sauber ans Netz kommt.

Rettungssystem

Das Rettungssystem, in das man booten kann, ist - wie oben bereits erwähnt - ein Debian sarge, in das man per apt-get jederzeit weitere Packages hineininstallieren kann. Der Kernel kann LVM, so dass einer Installation “meines” Images über dieses Rettungssystem kaum etwas im Wege steht. Außerdem taugt das Rettungssystem als Referenz für “das läuft”. Im Gegensatz zu dem, was man von grml und co gewöhnt ist, wird weder eine der Plattenpartitionierung entsprechende /etc/fstab generiert, noch sinnvolle Mountpoints in /mnt angelegt - hier ist also solide Handarbeit angesagt.

Authentifikation per ssh-Key ist nach Anlage einer /root/.ssh/authorized_keys möglich, was für mein Installationsverfahren recht wichtig ist.

Die Netzwerkkonfiguration kommt wie im Produktivbetrieb per DHCP.

Installation des zgserver-Standardimages

Mein Installer für einen “Standard-zgserver”; arbeitet über ssh und kann somit auf jedem System installieren, das irgendwie im Netz erreichbar ist. Als “Startpunkt” braucht es irgend ein LVM-fähiges Linux auf dem Zielsystem, wobei der Zugriff des Scripts dadurch eingerichtet wird, dass der Bediener im ersten Schritt gebeten wird, ein paar Kommandos, die unter anderem einen ssh-Key für root etablieren, in eine Shell auf dem zu installierenden System zu pasten. Der Rest - Partitionierung, Einrichtung von LVM, Erzeugung der Filesysteme, Aufspielen und Personalisierung des Images - geht weitgehend automatisch.

Rechtzeitig bemerkte Hürde war, dass der Server ein via-rhine-II-Netzwerkinterface hat, was in meinem zgserver-Image nicht verfügbar war. Jetzt ist es.

Nach dem ersten Reboot in das neu installierte Linux kam das System nicht ans Netz - ich kannte die notwendigen DHCP-Tricks noch nicht, und musste sie per trial-und-error und Vergleich mit dem Rescuesystem erst herausarbeiten. Hier wäre eine serielle Konsole echt praktisch gewesen, aber ein zusätzliches Initscript, das als letzten Schritt des Bootvorgangs die Netzwerkkonfiguration ins syslog kippt, zeigte dann auch ziemlich schnell, dass ohne Defaultroute mit funktionierendem Internetzugang eher nicht zu rechnen sei.

Turn-Offs

Im Alturo-Angebot fehlt leider eine serielle Konsole. Die gibt es bei United Internet leider erst ab 1und1. Da ist der Server dann zwar kein Celeron, sondern eine relativ dicke AMD64-Kiste und kostet dann fast das Fünffache, aber wer braucht so ‘nen dicken Rechner? Mit 40 GB ist die Festplatte auch nicht wirklich groß, aber für den Hausgebrauch reicht das. Einen Debian-Mirror wird man damit eher nicht aufsetzen wollen.

Ebenfalls nicht möglich sind zusätzliche IP-Adressen, was den Einsatz von Virtualisierungstechniken sicher erschwert. Stellt sich die Frage, ob man das für den Preis überhaupt braucht.

Fazit

Bis auf die serielle Konsole und das unflexible IP-Setup erfüllt das Alturo-Produkt fast alle meine Anforderungen, die ich an einen Housing-Server habe. Die Konfiguration geht bis auf minimale Fallen beim DHCP geradeaus und einfach, das Rescuesystem erfüllt seine Arbeit, das Webfrontend taugt. Der von mir getestete Server kostet 19,99 Euro im Monat, und wenn der noch billigere Alturo Webserver (ohne Plus, für 14,99 Euro im Monat) dasselbe System hat (was ich vermute), frag ich mich, wie andere Anbieter ihre im gleichen Preissegment liegenden vserver überhaupt an den Mann bekommen.

Einrichtungsgebühr kostet 49 Euro, das ist schmerzlich, aber akzeptabel.

Mein Urteil: nicht billig, aber preiswert.