Zugschlusbeobachtungen (Entries tagged as rootserver-test)

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.

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.

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.