Zugschlusbeobachtungen (Entries tagged as rootserver)

Neue Hardware, neues Glück

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 17 May 2008 10:27:37 +0200

Die Blogausfälle haben jetzt hoffentlich ein Ende. Einer der anderen Nutzer dieses Servers hat nochmal gemeckert, und dann ging es plötzlich ganz schnell. “Kulanterweise” wollte man dann doch die Hardware tauschen. Wir sollen ein Backup machen, die Maschine ins Rescuesystem stellen und im Frontend auf “Neuinstallation” klicken.

Die Eingabemaske hatte plötzlich eine neue Checkbox “Hardwaretausch”, der gegen 13:30 Uhr am Freitag betätigt wurde. Gegen 17.00 Uhr war der Host dann komplett down und kurz vor Mitternacht kam die Meldung, “Ihr Server wurde neu installiert”. Was stimmte: Neue Hardware, neue Platte und ein neu installiertes Debian 4.0, das unbesehen sofort wieder runterflog und durch das Backup ersetzt wurde.

Das Restore selbst hat dann nur 45 Minuten gedauert, aber als es fertig war war der Zugschlus schon im Bett, so dass der Normalbetrieb erst nach 20 Stunden Downtime heute morgen wieder aufgenommen werden konnte.

Da auf ivanova auch das Backport-Repository liegt, aus dem ich meine anderen Serversysteme mit Software versorge, war ich irgendwie den Freitag nachmittag über ziemlich gehandicapped. Gegen 21.00 Uhr dachte ich mir “das wird heute nichts mehr”, und da ich die letzten ssh-Security-Updates aber noch verteilen wollte und das Wochenende mit Ball, Tanzturnier (als Zuschauer), dem traditionellen, 39ten Semesterendfrühstück und einer Einladung zu einer Geburtstagsfeier eh in Stress ausartet, musste ich mir Alternativen einfallen lassen.

Die Alternative wurde schließlich dadurch realisiert, dass ich auf dem Server, auf dem das Backup von ivanova gelandet war, kurzerhand einen apache verpasst habe, der das entsprechende Verzeichnis aus ivanovas Backup gepublished hat und den Hostnamen umdelegiert habe. So war ich dann schon um kurz vor halb zwei im Bett **gähn**

Blogausfaelle in Vergangenheit und Zukunft

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 15 May 2008 14:42:53 +0200

Wie Euch sicher aufgefallen ist, war dieses Blog in den letzten Tagen öfter mal nicht erreichbar. Die Ursache hierfür ist eine Festplatte, die ihr baldiges Ableben angekündigt hat, und ein Serververmieter, der dies nicht verstehen möchte.

Wir erhöhen also die Backupfrequenz und warten darauf, dass die Platte komplett den Löffel abgibt. Leider wird es bis dahin noch mehrfach zu “read only” remounteten Filesystemen kommen. Viel mehr als “in dieser Situation rebooten und warten bis der Mist das nächste Mal passiert” kann man leider nicht tun. Ich bin derzeit nicht zuversichtlich, dass der Serververmieter noch das Licht sehen wird.

Das System faselt im Syslog alle paar Minuten von “smartd[1490]: Device: /dev/hda, 49 Currently unreadable (pending) sectors”, einmal hatten wir sogar schon das gefürchtete “Device: /dev/hda, FAILED SMART self-check. BACK UP DATA NOW!”. (Leider) hat die Platte danach alle manuell gestarteten SMART-Selbsttests bestanden, und der Serververmieter scheint mir zu unterstellen, dass ich mir die Logs aus der Nase gezogen habe und aus Spaß 120 GB sichere und wieder zurückspiele - denn er will den Fehler partout selbst sehen. Das kann ich im Augenblick nicht bieten, und so bleibt die Platte ungetauscht.

Bis zum nächsten Ausfall hoffe ich, dass ich auch mal wieder etwas Content zu liefern in der Lage bin, hier geht’s im Moment ordentlich rund.

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.

ping ist boese?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 31 Mar 2007 20:17:47 +0200

Vermieter von dedizierten Mietservern sind offensichtlich nicht daran interessiert, dass ihre Kunden im Störungsfall in der Lage sind zu diagnostizieren, wo die Störung liegt. Denn sonst wäre es nicht so üblich, auf den Coreroutern nicht auf ICMP echo requests zu antworten. Das ist doof, denn so erzeugt mein Nagios viel mehr Alarme als er müsste.

Bleibt also nur, im Störungfall stets sofort den Anbieter zu nerven - denn er will es offensichtlich so.

P.S. Ich will ein Nagios-Plugin das traceroutes auswerten kann. TTL exceeded verschicken die Corerouter der Serveranbieter nämlich immer.

using grml to prepare LVM surgery

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 29 Mar 2007 00:00:52 +0200

One of my dedicated servers was in bad need of major LVM surgery today. Since the rescue system delivered with the server by the housing provider suffers from lack of LVM support, I needed to pull a creative stunt with grub and grml to accomplish this.

The dedicated server rented from strato is the Box I tested in a different article. Installing the LVM-based Debian system via the LVM-less rescue system involved first installing without LVM in the partition which was originally supposed to be swap, booting the just installed system and using this temporary system to finally bootstrap the target.

I had originally planned to go this way again in case rescue should become necessary. Today, I checked first whether the provider supplied rescue system had improved in the mean time (which it hadn’t), and I didn’t feel like installing a new temporary system. Instead, I decided to go through a different route, using grml.

grml is extremely versatile regarding boot. All you need is to get the grml kernel to boot and point it towards the grml initrd, and the initrd automatically searches the available drives for the compressed file system image, mounts it and continues the boot process. This was the point where I hooked myself into grml. I put an ext3fs on the swap partition and copied the contents of a grml CD to that partition. After thinking a while about how to get ISOLINUX to boot this grml, I remembered that the disk already has grub installed, and decided to use grub to boot grml.

This was possible because the provider offers a serial console for the machine. If no serial console had been available, things would have been a lot harder since there would be no feedback and one would have to talk to grub via offline editing of menu.lst. Thanks to the serial console, things were a lot faster.

Booting grml via grub is actually easy. After finding out which partition grml is on (find /linux26) and setting this partition as root, all you need is “kernel /linux26 ramdisk_size=100000 init=/etc/init lang=us BOOT_IMAGE=grml console=ttyS0,57600n8”, “initrd /minirt26.gz” and finally “boot”.

The “57600” given on the kernel command line was actually the hardest part: Strato operates the serial console at unusual 57600 bps, and grml’s serial console feature starts mgetty with hard-coded 9600 bps. The rather frustrating symptom was that you can watch grml booting, with “Finished execution of main grml startup” as the last sign of life. Knowing that there is a login prompt waiting for you at the wrong baud rate.

After talking to Mika from the grml team for some minutes, we decided to take two “roads” to solve the issue. Mika hacked grml’s startup process to parse the baud rate to be used for mgetty from the kernel command line. Since I couldn’t wait for Mika’s fix, I used a grml.sh script to put a fixed mgetty.config over the file contained in grml. After fixing some stupid mistakes on my part, I finally received my grml login prompt and could start with the LVM surgery.

Grml is a perfect tool for such tasks since it is extremely flexible and not selective in which medium and partition types it can boot from. It has saved me a lot of grief today and has helped me in solving a difficult problem.

Oh, btw, pvmove --alloc anywhere can move a logical volume inside a pysical volume without the need of a temporary physical volume, and it is thus possible to “manually” defragment a physical volume in order to allow more clean resizing of logical values. While it is debateable whether this does really make sense, it satisfies my sense of order to have an LVM setup unfragmented.

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.

Alturo-Ersatz

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 24 Sep 2006 21:07:32 +0200

Alturo macht dicht. Das dürfte sich unter den Mietserverbetreibern inzwischen herumgesprochen haben. Laut der Pressemitteilung und Kündigung meiner Verträge (die Alturo nach seinen AGB mit einer Frist von 30 Tagen aussprechen zu dürfen meint), wendet sich die Zielgruppe zunehmend den Markenprodukten zu.

Ich habe ja eher den Verdacht, dass die Marktverdrängungsstrategie, die United Internet mit seiner Billigmarke Alturo offensichtlich ausprobiert hat, nicht so ganz aufgegangen ist: Zu wenig Konkurrenten haben versucht, dem Alturo-Serverangebot (z.B. ein Pentium mit 1200 MHz und 256 MB für fünfzehn Euro im Monat) nachzuziehen; dementsprechend ist kaum einer von Marktrelevanz pleite gegangen. Also macht Alturo zu.

Die Sonderkonditionen, die Alturo den Bestandskunden beim Wechsel zu 1und1 anbietet, haben zwischen den Zeilen in großen Lettern “geh woanders hin” stehen. Was ich gerne tue, auch und gerade weil die Konzernschwester 1und1 sich vor einigen Monaten mit ihren asymmetrischen Kündigungsfristen vor Gericht einen Dämpfer eingefangen hat und die Billigschwester trotzdem dieselbe Masche immer noch fährt.

Interessant finde ich, was die Konkurrenz nach der Ankündigung der neuen Alturo-Strategie macht. Netdirekt versucht, aus den Neukunden noch etwas Geld herauszupressen und erhöht den monatlichen Preis des eigenen Billigangebots von fünfzehn auf achtzehn Euro; Strato im Gegensatz fährt eine spezielle Alturo-Wechsel-Aktion und verbilligt den vierundzwanzig-Euro-Server für die erste Vertragslaufzeit auf neunzehn Euro. Hetzner führt unterhalb des bisherigen Einstiegsprodukts DS3000 zwei kleinere Produkte ein, wobei der DS1000 in etwa mit dem kleinen Alturo-Server vergleichbar ist. Ob hundert Gigabyte Traffic im Monat nicht etwas arg geizig sind, mag der Kunde entscheiden.

Über den Netdirekt-Server habe ich bereits geblogged, einen Stratoserver habe ich vor zehn Minuten bestellt und auf die Freischaltung eines Hetzner-DS1000 warte ich bereits seit der Bestellung vom Donnerstag abend.

Sollte der “neue” Stratoserver maßgeblich von der in Nochmal Rootserver, diesmal Strato getesteten Maschine abweichen, werde ich das hierzublog selbstverständlich berichten. Jedenfalls ist zu empfehlen, den Server sofort fristgerecht zum Ende der ersten Vertragslaufzeit zu kündigen, denn nach den 18 Monaten wird der Server um zehn Euro im Monat teurer und wenn man die Kündigung (Ein Monat zum Ende der Laufzeit) verpennt, hängt man nochmal 12 Monate drin.

Über den Hetzner-Server werde ich natürlich berichten, sobald er freigeschaltet und getestet ist.

Call for Server

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 11 Sep 2006 13:36:57 +0200

Nachdem ich letzte Woche den dritten Testbereicht eines mietbaren Internetservers mit root-Zugang gepostet habe, kam weitgehend positives Feedback. Deswegen möchte ich gerne die Testreihe fortsetzen.

Um weitertesten zu können, brauche ich allerdings Systeme, die ich testen kann. Deswegen möchte ich Euch bitten, mir zu helfen und mir Serversysteme zum Testen zur Verfügung zu stellen.

Dabei gilt folgendes:

Ich teste sowohl Systeme, die von “richtigen” Kunden gemietet sind als auch Systeme, die von den Anbietern zum Test zur Verfügung gestellt werden.
Für den Test zahle ich kein Geld.
Der Test ist nur bei Systemen möglich, für die es ein vom Anbieter gepflegtes auf Linux basierendes Rescue-System gibt, dessen Leistungsumfang mit in den Test eingeht.
Für den Test benötige ich Zugriff auf das Administrator-Webinterface (das ist das Webinterface, in dem man das System resetten und ins Rescue-System booten kann), da sein Umfang Bestandteil des Tests ist.
Wenn der Bestellprozess mitgetestet werden kann, verliere ich dazu auch das eine oder andere Wort.
Im Rahmen des Tests installiere ich den Server zwei- bis dreimal komplett neu. Deswegen sollen keine wichtigen Daten auf dem Server abgelegt sein. Bevorzugt hätte ich gerne Systeme, die frisch angemietet sind und auf denen noch keine Benutzerdaten liegen.
Der Test selbst dauert etwa drei bis vier Stunden, wobei er sich in meine sonstige Arbeit einfügen muss. Es ist deswegen davon auszugehen, dass ich für ca. zwei Tage die Verfügungsgewalt über das System benötige.
Manche Anbieter erlauben dem Kunden keine Änderung des Passworts für das Webinterface. In solchen Fällen habe ich theoretisch nach dem Test weiterhin Zugriff, sage aber zu, diesen nicht mehr zu verwenden.
Die Rückgabe erfolgt mit frisch installiertem Anbieter-Image.

Wer einen Server testen lassen will, möchte sich bitte mit mir in Verbindung setzen.

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.