Zugschlusbeobachtungen

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.