Zugschlusbeobachtungen

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.