Abhilfe schafft die Android-App “DriveDroid“. Voraussetzung ist ein Android-Smartphone mit Root-Zugriff. DriveDroid verwandelt das Smartphone in ein Multi-ISO-Bootmedium für verschiedenste Linux-Distributionen – so hat man seine “Sammlung” immer griffbereit.

Die Bedienung der App ist sehr einfach. Beim ersten Start wird man darauf hingewiesen, dass noch keine Image-Dateien heruntergeladen wurden. Eine große Auswahl von Imagedateien für alle “großen” Distributionen kann direkt innerhalb der DriveDroid-App heruntergeladen werden. ISO-Dateien, die nicht direkt von DriveDroid zum Download angeboten werden, können manuell heruntergeladen und anschließend in den Ordner “images” innerhalb des Download-Ordners auf dem Smartphone kopiert werden.

Sobald das Image gemountet wurde, muss das Smartphone nur noch via USB-Kabel mit dem Rechner verbunden werden und im BIOS das Bootmedium auf das von DriveDroid hinzugefügte USB-Gerät eingstellt werden. Anschließend bootet der Rechner die ausgewählte Image-Datei.

Unterstütz werden derzeit nur sog. Hybrid-ISOs, also ISO-Dateien, die sowohl für den Einsatz auf CD-Rohlingen als auch auf USB-Sticks gedacht sind. Hybrid-ISOs werden inzwischen von allen populären Distributionen verwendet. Support für Nicht-Hybrid-ISOs soll wohl in Zukunft hinzugefügt werden, allerdings wird dafür auch ein Custom-Kernel nötig sein.

Die App ist in einer werbefinanzierten, kostenfreien Version ohne Einschränkungen erhältlich. Die werbefreie Version gleichen Funktionsumfang ist für 1€ erhältlich.

Auf meinem Nexus 4 funktioniert die App bis auf eine Einschränkung einwandfrei: Nachdem das Image in der App wieder unmounted wurde, erscheint im Windows-Arbeitsplatz das Nexus 4 nur noch als ausgegrauter Wechseldatenträger, in den angeblich kein Datenträger eingelegt ist. Abhilfe schafft es, in den Einstellungen des Nexus den Verbindungsmodus auf “Kamera (PTP)” und anschließend wieder auf “Mediengerät (MTP)” umzustellen.

Die Durchführung einer solchen Attacke ist kein Hexenwerk und auch für “Einstiegshacker” kein Ding der Unmöglichkeit. Doch wie einfach es sein kann, eine Man-in-the-middle-Attacke mithilfe der in der Security-Distribution Backtrack 5 R2 durchzuführen, habe ich in einem Artikel beschrieben, der in der aktuellen Ausgabe des IT-Security-Magazins hakin9 erschienen ist. Denn nur wer die verwendeten Angriffstechniken kennt, kann seine Computersysteme und Netzwerke wirkungsvoll vor solchen Angriffen schützen.

Dieser und weitere Artikel zum Thema “Backtrack 5″ sind in der aktuellen Ausgabe des hakin9-Magazins erhältlich. Besitzer eines gültigen Abonnements können sich diese Ausgabe hier herunterladen.

Exklusiv für alle Leser dieses Blogs gibt es den kompletten Artikel über Man-in-the-middle-Attacken mit Backtrack 5 R2 ungekürzt zum kostenfreien PDF-Download.

Viel Spaß und bleibt sicher,
Euer Leetperator

Der Raspberry Pi bzw. die verbaute CPU benötigt mehrere zum Teil proprietäre Software-Komponenten auf einer FAT-Partition, welche sich auf der eingesetzten SD-Karte befindet. Das Linux-System wird dann von einer ext3/ext4-Partition geladen, welche sich ebenfalls auf der SD-Karte befindet.

• Wenn der Raspberry Pi angeschaltet wird, sind sowohl der SDRAM-Speicher als auch die ARM-CPU deaktiviert. Die GPU-Einheit des SoC ist aktiv und lädt die erste Stufe des proprietären Bootloaders. Diese erste Stufe ist im ROM des SoC gespeichert. Sie greift auf die eingesetzte SD-Karte zu und lädt die zweite Stufe des Bootloaders (bootcode.bin) von der FAT-Partition in den L2-Cache des SoC und führt diese aus.

• Die zweite Stufe des Bootloaders aktiviert den SDRAM des SoC und lädt die dritte Stufe des Bootloaders (loader.bin) von der SD-Karte in den Arbeitsspeicher. Anschließend wird die dritte Stufe ausgeführt. Mit der dritten Stufe des Bootloaders ist der Bootloader komplett geladen.

• Die dritte Stufe des Bootloaders lädt die Firmware der GPU (start.elf) in den Arbeitsspeicher. Anschließend wird das Kernel-Image (kernel.img) in den Arbeitsspeicher geladen. Soweit vorhanden werden von der GPU-Firmware (in Insider-Kreisen gerne als “The Blob” bezeichnet) nun die Konfigurationsdateien config.txt und cmdline.txt geladen. config.txt beinhaltet Parameter, wie die GPU die Grundeinstellungen des Systems vorzunehmen hat. cmdline.txt beinhaltet zusätzliche Kernel-Parameter.

• Die GPU startet die ARM-CPU des SoC und führt einen Sprung zu Offset 0×8000 durch, da an dieser Adresse der Linux-Kernel “beginnt”. Der Linux-Kernel übernimmt die “Kontrolle” und bootet das System vollständig.

Eine Munin-Installation besteht aus zwei Komponenten. Die eine Komponente ist der “Master”-Server, der alle von den zu überwachenden Servern gesammelten Daten zusammenträgt und visualisiert. Die andere Komponente wird als “Munin-Node” bezeichnet. Ein Node ist ein Server, der von dem Munin-Master überwacht werden soll. Dazu werden von jedem Node die Leistungsdaten so aufbereitet, dass der Master diese Daten “abholen” und verarbeiten kann.

0. Einleitung

Jedes Munin-System braucht einen Master-Server, der die Munin-Nodes kontaktiert und alle dort gesammelten Daten zusammenträgt und visualisiert. Dabei kann ein Server zugleich Master und Node sein, wenn man beispielsweise nur einen Server überwachen will oder der überwachende Server ebenfalls überwacht werden soll. Zur Visualisierung erstellt der Munin Master-Server HTML-Seiten, welche die Grafiken mit den Leistungsdaten enthalten. Aus diesem Grund muss auf dem Master-Server auch ein Webserver installiert werden. Ich empfehle wie üblich den nginx-Webserver.

Die Zahl der Nodes, die durch einen Master abgefragt werden können, ist nicht begrenzt. Abgesehen von Munin selbst ist auf den Nodes auch keine weitere Software erforderlich, weshalb die Überwachung mit Munin recht ressourcenschonend ist. Allein auf dem Master-Server entsteht eine gewisse Last, da die Grafiken generiert und durch den Webserver ausgeliefert werden müssen. Bei einer überschaubaren Zahl von überwachten Nodes hält sich die Serverlast allerdings sehr in Grenzen, zumal die durch Munin erstellten Websites vollkommen statisch sind und keine zusätzliche Skript-Sprache wie PHP benötigen.

Im folgenden Szenario setzen wir ein Munin-Cluster mit einem Master und einem Nodes auf. Der Master soll dabei selbst auch ein Node sein, um die Leistungsdaten des Masters visualisieren zu können. Auf beiden Servern ist eine Minimalinstallation von Debian Squeeze installiert. Bei anderen Linux-Distributionen dürfte die Vorgehensweise ähnlich sein, aber bitte u.A. auf die Pfade der Konfigurationsdateien und das Paketmanagement achten.

1. Munin Master-Server installieren

Unter Debian und dessen Derivate befindet sich Munin in Form der Pakete munin und munin-node im Paket-Repository. Munin lässt sich über Plugins erweitern, sodass noch weitere Dienste überwacht werden können. Einige Plugins sind im Paket munin-plugins-extra enthalten. Auf die Installation eines Webservers wird an dieser Stelle nicht weiter eingegangen, da habe ich zum Beispiel hier schon etwas darüber geschrieben.

Im ersten Schritt sollte in der Konfiguration des Webservers ein neuer vHost für den Speicherort der Munin-Ausgaben angelegt werden. Anschließend muss der DocumentRoot dieses vHosts mit chown munin:munin dem Munin-Benutzer zugeteilt, sonst kann Munin die Report-Websites mangels Schreibrechten nicht abspeichern. Auch sollte der DocumentRoot mit einem Passwort geschützt werden, sonst kann jeder, der den Webroot von Munin kennt, sämtliche Server-Statistiken einsehen. Ganz praktisch für Angreifer, können diese doch direkt nachprüfen, ob z.B. der Arbeitsspeicher dank einer Flooding-Attacke langsam aber sicher überläuft.

Anschließend geht es an die Grundlegende Konfiguration des Munin-Masters. Die Konfiguration wird in der Datei /etc/munin/munin.conf gespeichert. Dort passen wir zunächst den Parameter htmldir an den DocumentRoot des Munin-vHosts an. Jetzt können wir uns testweise einmal als Benutzer munin anmelden und mit folgendem Befehl den Munin-Cronjob starten: /usr/bin/munin-cron. Jetzt sollte eine Übersichtsseite von Munin erscheinen, wenn man im Webbrowser den für Munin konfigurierten DocumentRoot aufruft.

Dann wird in der munin.conf der Block “a simple host tree” durch ein “#” an den Beginn jeder Zeile auskommentiert, denn wir wollen für jeden Munin-Node eine eigene Konfigurationsdatei anlegen. Dies erhöht meiner Meinung nach die Übersichtlichkeit, gerade wenn mehrere Munin-Nodes überwacht werden sollen.

Nun legen wir für den Munin-Master eine neue Konfigurationsdatei im Verzeichnis /etc/munin/munin.conf.d/ an. Den Namen der Konfigurationsdatei kann man frei wählen, allerdings empfehle ich, dort den Hostnamen des Servers zu nehmen.

Die Konfigurationsdatei wird nach folgendem Muster aufgebaut:

[Hostname.Domainname]
    address 127.0.0.1
    use_node_name yes

Für den Master-Server können wir die IP-Adresse 127.0.0.1 beibehalten. Mithilfe des Domainnamen lassen sich die überwachten Server in Gruppen einteilen, denn alle Munin-Nodes mit dem gleichen Domainnamen werden in der Munin-Übersicht gruppiert dargestellt.

2. Munin-Node installieren und zum Munin-Master hinzufügen

Die Installation eines Munin-Nodes geht wesentlich einfacher vonstatten. Zuerst muss das Paket munin-node installiert werden. Damit der Munin-Master mit dem Munin-Node kommunizieren kann, muss man in der Konfigurationsdatei des Nodes – zu finden unter /etc/munin/munin-node.conf – die IP-Addresse des Munin-Masters hinzufügen. Dazu ergänzen wir die Konfigurationsdatei um die Zeile allow xx.xx.xx.xx, wobei xx.xx.xx.xx für die IP-Adresse des Munin-Masters steht. Abschließend muss der Munin-Node neu gestartet werden.

Damit der Munin-Master den Node auch kontaktiert, um die Leistungsdaten einzusammeln, müssen wir für den Node eine neue Konfigurationsdatei im Verzeichnis /etc/munin/munin.conf.d anlegen. Auch hier kann wieder der Name für die Datei frei gewählt werden. Die Konfigurationsdatei wird nach folgendem Muster aufgebaut:

[Hostname.Domainname]
    address xx.xx.xx.xx
    use_node_name yes

Hier muss xx.xx.xx.xx an die IP-Adresse des Munin-Nodes angepasst werden.

Auf diese Weise können beliebig viele Munin-Nodes hinzugefügt werden.

3. Optional: Zusätzliche Plugins aktivieren

Standardmäßig überwacht Munin die Festplatte, den Munin-Prozess selbst, das Netzwerk, alle Prozesse, Sendmail sowie einige Systemparameter wie RAM- oder CPU-Auslastung. Im Verzeichnis /usr/share/munin/plugins befinden sich noch viele weitere Plugins, mit denen z.B. auch die Auslastung des MySQL-Servers visualisiert werden kann. Um ein Plugin zu aktivieren, genügt es, einen Symlink zum Verzeichnis /etc/munin/plugins zu setzen und den Munin-Node anschließend neuzustarten.

Fragen, Anregungen, Anmerkungen sind wie immer gerne gesehen!

Auch wenn ich das Key-Auth-Verfahren schon länger selbst einsetzte und es durchaus für sicherheitsrelevant halte, habe ich komischerweise nie einen Artikel darüber verfasst. Here we go!

Als Basis nehmen wir wie üblich einen Server mit einer “blanken” Debian Squeeze-Installation. Die Vorgehensweise dürfte bei anderen Distributionen ähnlich sein, jedoch bitte vor jedem Schritt prüfen, ob auch alle Konfigurationsdateien am “richtigen” Platz sind. Der verwendete Test-Server wurde von TomAte92 gesponsert, als Client-Rechner muss mein Raspberry Pi herhalten.

Hinweis: Dieses Tutorial geht davon aus, dass auf dem Client-Rechner ebenfalls ein Linux installiert ist. Ein Howto zur Schlüsselgenerierung und zum Verbindungsaufbau unter Windows mit PuTTY folgt ggf. später!

Kurz ein paar Grundlagen zum Public Key-Verfahren: Wir werden zwei Schlüsseldateien erstellen, einmal den öffentlichen und einmal den privaten Schlüssel. Der öffentliche Schlüssel ist – wie der Name schon impliziert – kein großes Geheimnis. Wesentlich brisanter ist der private Schlüssel. Dieser in der Regel passwortgeschützte Schlüssel ist das Gegenstück zum öffentlichen Schlüssel und erlaubt dem Client eine Verbindung zum Server aufzubauen. Wenn der private Schlüssel dann nicht mit einem Passwort gesichert ist und von Dritten kopiert wird, erhalten diese Root-Zugang zum Server.

Kleine Analogie: Der öffentliche Schlüssel ist quasi das Schloss einer Tür und der private Schlüssel der zum Türschloss passende Schlüssel. Während sich jeder das Schloss ansehen darf, sollte auf den dazu passenden Schlüssel natürlich niemand Zugriff erhalten.

1. Schlüsselpaar auf dem Client-Rechner erzeugen

Zum Generieren des Schlüsselpaares auf dem Client-Rechner kommt das Tool ssh-keygen zum Einsatz. Dieses Tool ist im Debian-Repository in dem Paket openssh-client enthalten.

user@client:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
65:5f:b9:52:9e:03:81:2e:59:df:0d:b7:7f:9e:59:9d user@client
The key's randomart image is:
+--[ RSA 2048]----+
|           ..    |
|          o  ....|
|         +o...++.|
|        oo...=.+.|
|        S.  o = +|
|             . E=|
|               .=|
|               o.|
|                 |
+-----------------+

ssh-keygen erstellt daraufhin ein Schlüsselpaar, bestehend aus dem public und dem private Key. Der pubic Key ist an der Dateiendung .pub erkennbar. Soll auf dem Rechner nur ein Schlüsselpaar angelegt werden, kann der vorgegebene Dateiname beibehalten werden. Bei mehreren Schlüsselpaaren müssen natürlich andere Dateinamen verwendet werden, sonst werden die alten Schlüssel einfach überschrieben.

Auch wenn ssh-keygen den Nutzer dazu verleitet, doch kein Passwort einzugeben, sollte man das auf jeden Fall unterlassen. Auch wenn die Anmeldung damit “bequemer” wird, stellt das ganze doch ein erhebliches Sicherheitsrisiko dar. Immerhin können Angreifer, die sich Zugriff auf den privaten Schlüssel verschaffen, sich dann ebenso bequem und ohne Passworteingabe auf allen Servern anmelden, die dieses Schlüsselpaar verwenden. Also bitte unbedingt ein ausreichend starkes Passwort verwenden!

Sowohl der public als auch der private Key sollten nun redundant an mehreren sicheren (!!!) Orten abgespeichert werden. Ohne Keys steht ihr nämlich vor verschlossenen “Server-Türen”.

2. Schlüssel auf den Server übertragen

Im nächsten Schritt muss der public Key des eben erstellten Schlüsselpaares auf alle Server kopiert werden, auf denen eine Anmeldung mit dem Schlüsselpaar ermöglicht werden soll. Dazu verwenden wir den Befehl ssh-copy-id. Dieser Vorgang muss auch für alle User-Accounts auf dem Server wiederholt werden, für die ein direkter SSH-Login erlaubt sein soll. Dies ist besonders wichtig, wenn sich der root-Account aus Sicherheitsgründen nicht direkt am SSH-Server anmelden darf. (Stichwort “PermitRootLogin no”).

user@client:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@192.168.xx.xx
user@192.168.xx.xx's password:
Now try logging into the machine, with "ssh 'user@192.168.xx.xx'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Username und IP-Adresse müssen natürlich den reealen Bedingungen angepasst werden. Sollte der SSH-Server des Ziel-Servers nicht auf dem Standard-Port 22 “lauschen”, muss der Aufruf folgendermaßen aussehen:

user@client:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub "user@192.168.xx.xx -p Portnummer"

Die Anführungszeichen vor user und hinter der Portnummer sind erforderlich, sonst werden die Parameter nicht richtig an den SSH-Client übergeben.

Wie uns ssh-copy-id schon vorgeschlagen hat, melden wir uns nun am Ziel-Server an. Anstelle des User-Passwortes werden wir nun nach dem Passwort für den private Key gefragt. Wenn wir dieses richtig angeben, sind wir auch schon “drin”.

3. Passwort-Authentifizierung deaktivieren

Anschließend sollten wir noch für alle Accounts, die das Schlüsselpaar zur Authentifizierung verwenden, den Login über das User-Passwort verbieten. Denn schließlich haben wir die Authentifizierung über das Schlüsselpaar vor allem aus Sicherheitsgründen eingerichtet, unser “Passwort” soll ja unknackbar werden.

Die Passwort-Authentifizierung kann global in der Konfiguration des SSH-Servers oder nur für einzelne Benutzeraccounts gesperrt werden. Um die Passwort-Authentifizierung global zu deaktivieren, fügen wir folgende Optionen in die Datei /etc/ssh/sshd_config ein:

PasswordAuthentication no
UsePAM no

Anschließend muss der SSH-Server neu gestartet werden, damit die geänderte Konfiguration verwendet wird. Für einzelne Benutzer-Accounts kann die Passwort-Authentifizierung auch einfach deaktiviert werden:

passwd -l username

4. Für den Notfall: Keys zurückziehen

Sollte ein private Key durch Angreifer kopiert werden, muss auch bei einem passwortgeschützten Schlüssel dieser sofort im System für ungültig erklärt werden. Dazu muss zuerst die Passwort-Authentifizierung wieder aktiviert werden, sonst hat man nach dem Zurückziehen des Schlüssels keine Möglichkeit mehr, sich an dem System anzumelden. Dazu wird in der Datei /etc/ssh/sshd_config der Parameter PasswortAuthetication auf yes gesetzt und der SSH-Server neu gestartet.

Bei Benutzeraccounts, die über passwd -l gesperrt wurden, muss die Passwort-Authentifizierung mit dem Befehl passwd -u username wieder aktiviert werden.

Anschließend muss der betroffene Schlüssel aus der Datei /home/username/.ssh/authorized_keys entfernt werden. Dazu kann entweder die betreffende Zeile gelöscht werden oder durch ein vorangestelltes “#” auskommentiert werden. Zu guter Letzt muss der SSH-Server neu gestartet werden. Danach sind aus Sicherheitsgründen die Passwörter aller User-Accounts zu ändern.

Da ich grundsätzlich für sämtliche Neuerungen der Hosting-Branche offen bin, habe ich bei Host Europe nach einem Test-Server gefragt und diesen auch erstaunlich unkompliziert (genau eine Twitter-Nachricht hat’s gebraucht, danke dafür!) für eine Woche zum Testen bekommen.

Die Root-Server werden in zwei Baureihen angeboten. Bei der günstigeren “Professional”-Serie teilen sich immer mehrere Server ein Hostsystem (ähnlich wie bei herkömmlichen vServern), bei der teureren “Premium”-Serie läuft auf jedem Hostsystem nur ein vollvirtualisierter Server. Doch auch bei der Professional-Serie sollte man sich keine Gedanken über die Performance machen müssen, denn die Ressourcen der einzelnen Server werden garantiert vergeben.

Wenn ein Server z.B. mit 4 vCores angeboten wird, dann sind diese 4 Kerne (bzw. Threads bei HT-Technologie) im Hostsystem fest für diesen Server vergeben und können auch nicht von einem anderen Server, der auf dem gleichen Hostsystem liegt, mitbenutzt werden. Ein weiterer Unterschied zu vServern liegt darin, dass jeder Server ein eigenes, dediziertes Hardware-RAID1 zugeteilt bekommt, was eine gleichbleibende IO-Performance garantiert. Für das auf dem Server installierte Betriebssystem sieht es so aus, als wäre nur eine einzige Festplatte verbaut, denn der RAID-Verbund wird von Host Europe verwaltet.

Durch die verwendete Virtualisierungs-Technologie ist es problemlos möglich, eigene Kernel-Versionen oder Betriebssysteme zu installieren. Dazu besteht die Möglichkeit, ISO-Dateien bis zu einer Größe von 5GB einzubinden, um anschließend über einen VNC-Zugang das gewünschte System installieren zu können. Natürlich ist es zur vereinfachten Installation auch möglich, ein vorgefertigtes Template zu verwenden. Ein weiterer Vorteil der Virtualisierung ist die von herkömmlichen vServern bekannte Möglichkeit, einfach und automatisiert Backups zu erstellen und wieder einzuspielen.

Der von mir getestete Root Server Professional M besitzt 4 vCores, 16GB RAM und 1TB Festplattenspeicher. Das verwendete Hostsystem besitzt eine Intel Xeon CPU E5649 mit einer Taktfrequenz von 2,53GHz.

Netzwerk: Host Europe garantiert eine Bandbreite von 100Mbit/s, die auch zu Stoßzeiten erreicht werden soll. Downloadtest einer 100MB großen Datei aus dem Cachefly-CDN:

root@rs200087:~# wget cachefly.cachefly.net/100mb.bin -O /dev/null
--2012-05-26 11:54:34--  http://cachefly.cachefly.net/100mb.bin
Resolving cachefly.cachefly.net... 140.99.93.175
Connecting to cachefly.cachefly.net|140.99.93.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: “/dev/null”

100%[================================================================================================>] 104,857,600 57.0M/s   in 1.8s

2012-05-26 11:54:36 (57.0 MB/s) - “/dev/null” saved [104857600/104857600]

Im Gegensatz zu den versprochenen 100Mbit/s erreicht der Server Download-Raten von ca. 450Mbit/s. Bei einem Download einer 700MB großen Debian-ISO-Datei von cdimage.debian.org liegen die Übertragungsraten bei ca. 40MB/s, also auch wieder deutlich über den versprochenen 100MBit. Der ausliefernde Server, der durch den Loadbalancer des Debian-Mirrors zugeteilt wurde, war napoleon.acc.umu.se.

Ping: Mein DSL 3000-Anschluss der Telekom über WLAN erreicht Ping-Zeiten von ca. 40ms. Eine direkte Verbindung über LAN-Kabel kann ich mangels Verkabelung leider nicht testen. Weltweite Ping-Tests über just-ping.com sind hier verfügbar.

Festplatte: Aufgrund der eingesetzten Virtualisierung war es mir nicht möglich, das eingesetzte Festplatten-Modell zu ermitteln.

• Lese-Test mit hdparm:

  root@rs200087:~# hdparm -t /dev/sda
  
  /dev/sda:
   Timing buffered disk reads: 2236 MB in  3.00 seconds = 745.28 MB/sec

  Die Lesegeschwindigkeit 745.28 MB/s ist einfach nur richtig schnell. Auch bei mehrfacher Ausführung dieses Tests ändern sich die Lesegeschwindigkeiten nicht signifikant, sodass Messfehler ausgeschlossen werden können.

• Schreib-Test mit dd:

  root@rs200087:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
  16384+0 records in
  16384+0 records out
  1073741824 bytes (1.1 GB) copied, 4.18072 s, 257 MB/s

  Die Schreibgeschwindigkeit von 257 MB/s liegt auch deutlich über meinen Erwartungen. Ich würde die Geschwindigkeit für einen Server dieser Preisklasse als “schnell” bezeichnen. Leider fehlen mir hier noch ein wenig die Erfahrungswerte, um die Geschwindigkeit für einen Root-Server richtig bewerten zu können. Vielleicht mag jemand über die Kommentarfunktion helfen und Vergleichswerte posten?!

• Zugriffszeiten mit ioping:

  ./ioping . -c5
  4096 bytes from . (ext3 /dev/disk/by-uuid/...): request=1 time=0.3 ms
  4096 bytes from . (ext3 /dev/disk/by-uuid/...): request=2 time=0.5 ms
  4096 bytes from . (ext3 /dev/disk/by-uuid/...): request=3 time=0.6 ms
  4096 bytes from . (ext3 /dev/disk/by-uuid/...): request=4 time=0.7 ms
  4096 bytes from . (ext3 /dev/disk/by-uuid/...): request=5 time=0.4 ms
  
  --- . (ext3 /dev/disk/by-uuid/9cc886cd-98f3-435a-9830-46b316e2a20e) ioping statistics ---
  5 requests completed in 4004.6 ms, 2014 iops, 7.9 mb/s
  min/avg/max/mdev = 0.3/0.5/0.7/0.1 ms

  Die Zugriffszeiten liegen mit durchschnittlich 0,5ms relativ niedrig.

Benchmarks: Die Gesamt-Performance des Servers wird über die beiden Benchmark-Tools “GeekBench” und “UnixBench” ermittelt. Im GeekBench-Benchmark erreicht der Server eine Gesamtpunktzahl von 6148 Punkten. Getestet wurde auf einem 64 Bit Debian Squeeze-System. Die genauen Testergebnisse sind unter http://browse.geekbench.ca/geekbench2/view/699212 verfügbar.

Im UnixBench-Test erreicht der Server eine Gesamtpunktzahl von 3143,5 Punkten beim Test mit allen vier vCores.

------------------------------------------------------------------------
Benchmark Run: Sat May 26 2012 13:12:37 - 13:41:00
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       97288136.6 lps   (10.3 s, 7 samples)
Double-Precision Whetstone                    12975.6 MWIPS (9.9 s, 7 samples)
Execl Throughput                              14317.4 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        536619.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          125685.6 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1518786.3 KBps  (30.0 s, 2 samples)
Pipe Throughput                             8534176.3 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                1145792.9 lps   (10.0 s, 7 samples)
Process Creation                              45258.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                  18418.0 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   2490.7 lpm   (60.0 s, 2 samples)
System Call Overhead                        6218438.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   97288136.6   8336.6
Double-Precision Whetstone                       55.0      12975.6   2359.2
Execl Throughput                                 43.0      14317.4   3329.6
File Copy 1024 bufsize 2000 maxblocks          3960.0     536619.4   1355.1
File Copy 256 bufsize 500 maxblocks            1655.0     125685.6    759.4
File Copy 4096 bufsize 8000 maxblocks          5800.0    1518786.3   2618.6
Pipe Throughput                               12440.0    8534176.3   6860.3
Pipe-based Context Switching                   4000.0    1145792.9   2864.5
Process Creation                                126.0      45258.9   3592.0
Shell Scripts (1 concurrent)                     42.4      18418.0   4343.9
Shell Scripts (8 concurrent)                      6.0       2490.7   4151.2
System Call Overhead                          15000.0    6218438.8   4145.6
                                                                   ========
System Benchmarks Index Score                                        3143.5

Die Gesamtpunktzahl ist wie das Resultat im Geekbench-Test für diese CPU recht gut. Auffallend ist, dass die CPU scheinbar wirklich nicht “oversold” wird, da im Vergleich zu Testresultaten mit allen 12 CPU-Threads der Host-CPU die Werte bei genau einem Drittel der “vollen” CPU-Leistung liegen. Demnach dürften sich immer 3 Server dieser Leistungsklasse auf einem Hostsystem befinden, genaueres werde ich aber noch durch den Support erfragen.

Fazit: Solider Server zum vergleichsweise niedrigen Preis. Interessant sind vor allem die Features, die bedingt durch die Vollvirtualisierung dazu kommen, wie Snapshot-Backups und die Möglichkeit, bei Problemen mit dem Hostsystem den Server einer anderen Hostmaschine zuzuordnen.

Die Festplattenleistung ist für ein RAID1-System wirklich hervorragend. Gerade umfangreiche und gut besuchte MySQL-Datenbanken dürften damit glücklich werden. Die CPU knickt auch bei anspruchsvolleren Aufgaben nicht gleich ein, und 16GB Arbeitsspeicher sollten auch nicht so schnell aufgebraucht sein. Insgesamt eignet sich der Server für mittelgroße bis größere Websites, sofern man die eingesetzte Software noch etwas optimiert.

Wie gut die Server in der Praxis abschneiden, soll mit dem folgenden Test überprüft werden. CINIPAC hat mir für den Test freundlicherweise einen dieser Server zur Verfügung gestellt. Wie bei CINIPAC üblich steht der Server im Rechenzentrum von limehost.ro/Voxility [AS39743]. Dank direkter Anbindung zu dem Internet-Knoten DE-CIX in Frankfurt und einer direkten Leitung von Frankfurt nach Bukarest durch den Anbieter Level3 sind die Paket-Laufzeiten zwischen Deutschland und Voxility erfreulich gering.

Der Server besitzt einen Intel(R) Celeron(R) CPU 2.80GHz Single-Core-Prozessor und kann auf 3GB RAM zurückgreifen. Als Festplatte ist eine Seagate ST500DM002-1BD14 mit 500GB Speicherplatz verbaut.

Netzwerk: Angebunden ist der Server über eine 1Gbit-Leitung (shared). Zu Stoßzeiten garantiert CINIPAC eine Bandbreite von 250Mbit/s pro Server. Downloadtest einer 100MB großen Datei aus dem Cachefly-CDN:

wget cachefly.cachefly.net/100mb.bin -O /dev/null
--2012-05-20 16:12:55--  http://cachefly.cachefly.net/100mb.bin
Auflösen des Hostnamen cachefly.cachefly.net... 205.234.175.175
Verbindungsaufbau zu cachefly.cachefly.net|205.234.175.175|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 104857600 (100M) [application/octet-stream]
In »/dev/null« speichern.

100%[=============================================================>] 104.857.600 20,2M/s   in 4,8s

2012-05-20 16:13:00 (20,7 MB/s) - »/dev/null« gespeichert [104857600/104857600]

Der Download einer 700MB großen Debian-ISO-Datei lief mit durchschnittlich 18MB/s. Quelle war cdimage.debian.org, der Loadbalancer des Debian-Repositorys hat den Download über den Server caesar.acc.umu.se in Schweden ausgeliefert.

Ping: Mein DSL 3000-Anschluss der Telekom über WLAN erreicht Ping-Zeiten von ca. 80ms. Eine direkte Verbindung über LAN-Kabel kann ich mangels Verkabelung leider nicht testen. Weltweite Ping-Tests über just-ping.net zeigen, dass die Ping-Zeiten für die Standorte durchaus im Rahmen liegen. Von europäischen Standorten aus liegt die durchschnittliche Ping-Zeit bei ca. 50ms. Aus Gründen des Datenschutzes ist es dieses Mal nicht möglich, die IP des Servers zu veröffentlichen.

Festplatte: Im Test mit dem Tool dd erzielt die verbaute Seagate-Festplatte durchaus brauchbare Schreibraten von durchschnittlichen 84MB/s.

dd if=/dev/zero of=test.2 bs=64k count=16k conv=fdatasync
16384+0 Datensätze ein
16384+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 12,4042 s, 86,6 MB/s

Im Test mit dem Festplatten-Benchmark-Tool ioping zeigt sich eine niedrige Zugriffszeit von durchschnittlich 0,4ms.

./ioping . -c5
4096 bytes from . (ext3 /dev/sda2): request=1 time=0.3 ms
4096 bytes from . (ext3 /dev/sda2): request=2 time=0.4 ms
4096 bytes from . (ext3 /dev/sda2): request=3 time=0.5 ms
4096 bytes from . (ext3 /dev/sda2): request=4 time=0.3 ms
4096 bytes from . (ext3 /dev/sda2): request=5 time=0.4 ms

--- . (ext3 /dev/sda2) ioping statistics ---
5 requests completed in 4002.5 ms, 2596 iops, 10.1 mb/s
min/avg/max/mdev = 0.3/0.4/0.5/0.1 ms

Die durchschnittliche sequentielle Leserate liegt bei 108,3MB/s.

./ioping -RL /dev/sda

--- /dev/sda (device 465.8 Gb) ioping statistics ---
1237 requests completed in 3001.7 ms, 433 iops, 108.3 mb/s
min/avg/max/mdev = 2.3/2.3/20.7/0.5 ms

Anmerkung: Auf dem verwendeten Server war das Partition Alignment der Root-Partition fehlerhaft. Dadurch können bei intensiver IO-Last die Schreib/Leseraten einbrechen. Im Produktivbetrieb mit korrekter Partitionsausrichtung kann die IO-Performance daher über diesen Testwerten liegen.

Benchmarks: Um die Server-Performance zu testen, kommt dieses Mal neben dem Geekbench-Benchmark noch UnixBench hinzu. Leider gibt Geekbench in der aktuellen Demo-Version die Testergebnisse nicht mehr direkt auf der Konsole aus, sondern lädt diese nur in das Geekbench-Archiv hoch. Die Testergebnisse können unter http://browse.geekbench.ca/geekbench2/view/687567 abgerufen werden.

Die 1514 Punkte in der Geekbench-Bewertung sind zwar nicht sonderlich gut, aber für einen Prozessor dieser Leistungsklasse durchaus angemessen. Die CPU-Performance ist in etwa mit einem frühen Intel Core2Duo oder einem Pentium 4 der letzten Bauweise vergleichbar. Eine bessere CPU-Performance ist bei einem Celeron-Prozessor aber nicht zu erwarten. Ähnliches zeigt auch der UnixBench-Benchmark:

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: coloXX: GNU/Linux
   OS: GNU/Linux -- 2.6.32-5-686 -- #1 SMP Sun May 6 04:01:19 UTC 2012
   Machine: i686 (unknown)
   Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
   CPU 0: Intel(R) Celeron(R) CPU 2.80GHz (5584.2 bogomips)
          Hyper-Threading, MMX, Physical Address Ext, SYSENTER/SYSEXIT
   17:15:58 up  3:29,  1 user,  load average: 0.00, 0.00, 0.01; runlevel 2

------------------------------------------------------------------------
Benchmark Run: So Mai 20 2012 17:15:58 - 17:44:04
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        5460785.3 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1162.3 MWIPS (10.8 s, 7 samples)
Execl Throughput                               1664.6 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        253459.6 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           77608.0 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        570293.1 KBps  (30.0 s, 2 samples)
Pipe Throughput                              527808.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  93039.7 lps   (10.0 s, 7 samples)
Process Creation                               5359.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2690.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    340.6 lpm   (60.1 s, 2 samples)
System Call Overhead                         904416.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    5460785.3    467.9
Double-Precision Whetstone                       55.0       1162.3    211.3
Execl Throughput                                 43.0       1664.6    387.1
File Copy 1024 bufsize 2000 maxblocks          3960.0     253459.6    640.0
File Copy 256 bufsize 500 maxblocks            1655.0      77608.0    468.9
File Copy 4096 bufsize 8000 maxblocks          5800.0     570293.1    983.3
Pipe Throughput                               12440.0     527808.9    424.3
Pipe-based Context Switching                   4000.0      93039.7    232.6
Process Creation                                126.0       5359.4    425.4
Shell Scripts (1 concurrent)                     42.4       2690.2    634.5
Shell Scripts (8 concurrent)                      6.0        340.6    567.6
System Call Overhead                          15000.0     904416.1    602.9
                                                                   ========
System Benchmarks Index Score                                         465.3

Der niedrige System Benchmarks Index Score von 465.3 Punkten ist vor allem der CPU geschuldet. Für rechenintensive Anwendungen ist die Intel Celeron-Reihe einfach nicht geschaffen. Wie schon beim Geekbench-Benchmark sind die Resultate etwa mit einem späten Pentium 4 oder einem frühen Core2Duo vergleichbar.

Fazit: Kleiner Server zum kleinen Preis. A propos Preis: Auch wenn es in Deutschland in der Preisklasse deutlich leistungsfähigere Server gibt, ist der Preis von 49€ bei monatlicher bzw. 39€/Monat bei jährlicher Zahlung in Rumänien recht niedrig. Empfehlen würde ich den Server für kleine Websites mit hohem Speicherbedarf, als Storage/Backup-Server oder z.B. als Download-Archiv (5TB Traffic inklusive). Nicht geeignet ist der Server für besonders rechenintensive Anwendungen oder gut besuchte Websites, die sehr CPU-Lastig sind.

Über einen kleinen Umweg ist es jedoch trotzdem möglich, IPv6 heute schon nutzen zu können, auch wenn die ISPs dies noch nicht direkt unterstützen.

Das Zauberwort heißt “Teredo”. Teredo (RFC 4380) ist die Bezeichnung für ein IPv6-Tunnel-Protokoll, welches mithilfe externer Server eine Verbindung zwischen dem herkömmlichen IPv4-Netz und dem IPv6-Netz herstellen kann. Dabei werden die IPv6-Pakete in IPv4 UDP-Pakete “verpackt”. Diese Datenpakete können auch durch NAT-Geräte geroutet werden, sodass alle Geräte, die sich hinter einem Router befinden und sich eine gemeinsame öffentliche IPv4-Adresse teilen, eine eigene lffentliche IPv6-Adresse bekommen.

Teredo ist jedoch keinesfalls als permanente Lösung für das IPv4-Problem gedacht, da der Tunnel nur dann funktioniert, wenn sowohl Teredo-Server (auch als Teredo-Relay bezeichnet) als auch der Client über eine IPv4-Adresse verfügen. Früher oder später greifen also auch solche Tunnel-Lösungen nicht mehr. Momentan ist Teredo jedoch eine einfache Lösung, um als Privatnutzer ohne IPv6-Support durch den Internet-Provider auf IPv6-Netze zugreifen zu können.

Die durch Teredo generierten IPv6-Adressen befinden sich normalerweise im Subnetz 2001:0000::/32. Die restlichen Bits der IPv6-Adresse werden unter anderem aus den IPv4-Adressen von Teredo-Relay und Client sowie des aktuell durch den Client verwendeten NAT-Port berechnet.

Unter Windows XP SP2, Windows Vista und Windows 7 ist Teredo bereits vorinstalliert und fertig eingerichtet. Als Teredo-Relay wird dabei ein Server von Microsoft verwendet. Unter Linux kann man Teredo ganz einfach nachrüsten. Die benötigte Software hört auf den Namen miredo und ist in allen aktuellen Distributionen enthalten. Nach der Installation aus dem Distributions-Repository wird der miredo-Daemon gestartet und ein neues Netzwerk-Interface namens “teredo” angelegt. Sofort nach der Installation ist die Verbindung ins IPv6-Netz auch schon möglich.

Konfiguriert wird miredo über die Konfigurationsdatei /etc/miredo/miredo.conf (unter Debian/Ubuntu, andere Distributionen ggf. abweichend). Viel einzustellen gibt es dort nicht, jedoch kann unter anderem der Teredo-Server ausgwählt werden. Die Wahl des Servers ist auch nicht ganz unwichtig, denn die Leistung und Auslastung des Teredo-Relays ist entscheidend für die erzielte Bandbreite der IPv6-Verbindung.

Aktuell gibt es mehrere öffentliche Teredo-Server:

• teredo.remlab.net / teredo-debian.remlab.net (Frankreich)
• teredo.autotrans.consulintel.com (Spanien)
• teredo.ipv6.microsoft.com (USA, Redmond) (Standard unter Windows XP/Vista/7)
• teredo.ngix.ne.kr (Südkorea)
• teredo.managemydedi.com (USA, Chicago)
• teredo.trex.fi (Finnland)

Der Teredo-Server kann in der miredo.conf über den Parameter ServerAddress ausgewählt werden. Gleichzeitig kann jedoch immer nur ein Server ausgwählt werden, ansonsten startet der miredo-Daemon nicht mehr. Meiner Erfahrung nach sind die Server von Microsoft immer sehr ausgelastet, was auch nicht besonders verwundert, da dieser Server standardmäßig auf allen Windows XP/Vista/7-System eingerichtet ist. Ich habe die besten Erfahrungen mit dem Server teredo.trex.fi gemacht, dort sind Ping-Zeiten und Bandbreite für mich am besten.

Den Client gibt es zwar auch in einer Linux-Version, doch leider wird der immer noch für Ubuntu 8.10 und Fedora 9 beworben, 64 Bit gibts’s auch nicht.

Auch wenn der Downloader sicherlich funktionieren mag, dürfte es unter aktuellen Linux-Versionen langsam aber sicher zu Schwierigkeiten kommen, mal ganz abgesehen von den Problemen, die auf einem 64 Bit-System aufgrund fehlender Abhängigkeiten entstehen können. Insgesamt wirkt Linux in diesem Fall von Amazon ein wenig vernachlässigt.

Doch wie so oft: Wenn schon der Hersteller nicht hilft, dann gibt’s Hilfe aus der Open Source-Community. Dieses Mal in Form eines kleinen Kommandozeilentools namens clamz. clamz ist ein Ersatz für den offiziellen Amazon MP3-Downloader. Gefüttert mit den AMZ-Dateien, die nach einem Kauf zum Download angeboten werden, lädt clamz vollautomatisch das Album oder die Single. Zusätzlich können sogar mehrere AMZ-Dateien übergeben werden, dann arbeitet clamz diese alle nacheinander ab.

Die Installation ist sehr einfach, für Ubuntu beispielsweise gibt es ab Version 10.10 das Paket “clamz” im Repository, in den aktuellen Versionen anderer Distributionen dürfte es ähnlich sein. Wer eine Distribution besitzt, für die es keine paktierte Version gibt, kann clamz einfach selbst kompilieren, den Quellcode gibt’s auf der Google Code-Seite des Projekts.

Nach der Einrichtung muss einmalig der folgende Link aufgerufen werden: http://www.amazon.com/gp/dmusic/after_download_manager_install.html?AMDVersion=1.0.9. Dieser Link setzt einen Cookie im Browser welches vortäuscht, die aktuelle Version des MP3-Downloaders wäre installiert. Ohne dieses Cookie wird einem nach dem Kauf nur angeboten, doch bitte den MP3-Downloader zu installieren.

Nach dem Abschluss des Bezahlvorganges wird dem Benutzer die nötige AMZ-Datei zum Download angeboten. Diese Datei enthält alle Informationen, die clamz oder auch der originale Download-Manager benötigen. Dabei kann eine AMZ-Datei nur einmal für einen Download verwendet werden, danach wird sie automatisch ungültig. Deswegen ist es auch sehr wichtig, alle Amazon MP3s extra zu sichern, da ein Redownload zumindest mit dem originalen Client nicht möglich ist. Mit clamz ist zwar grundsätzlich ein Redownload möglich, solange die AMZ-Datei nicht gelöscht wird. Darauf sollte man allerdings nicht vertrauen, da unbekannt ist, wie lange evtl. vorhandene Sicherheitsmechanismen in der AMZ einen Download noch zulassen.

Aufgerufen wird clamz einfach über den Befehl:

clamz name-der-amz.amz

Die MP3-Dateien werden in den Ordner heruntergeladen, in dem sich auch die AMZ-Datei befindet. Alle Einstellugen werden in der Datei ~/.clamz/config vorgenommen. Dort kann zum Beispiel auch angegeben werden, nach welchem Schema die heruntergeladenen MP3s benannt werden sollen. Auch die Wahl eines anderen Ziel-Ordners ist möglich. Die Konfiguration ist prinzipiell selbsterklärend und gut dokumentiert, sodass hier keine weitere Anleitung nötig ist.

Noch ein abschließendes Wort zur Garantie: Da clamz von Amazon nicht offiziell unterstützt wird, wird möglicherweise keine Hilfestellung seitens Amazon geboten, sollte der Download abbrechen und ein erneuter Download bereits gekaufter Titel nicht mehr möglich sein. In diesem Fall ist man auf die (allerdings sehr gute) Kulanz von Amazon angewiesen.

In dem folgenden Interview wird euch Jonas Pasche, Geschäftsführer von Uberspace und einer der vier Administratoren, einiges über die Firma, deren Philosophie und Besonderheiten erzählen.

Leetperium.de (Leet): Hallo Jonas, danke, dass Du dir Zeit für das Interview genommen hast. Erzähle doch bitte zuerst ein wenig über deine Person.

Jonas: Ach, eine große Personality-Show will ich da gar nicht daraus machen – Uberspace.de ist schließlich ein Team-Projekt, das ich ohne meine Kollegen überhaupt nicht stemmen könnte. Aber jeder mag ein paar Eckdaten, also: Ich bin Jahrgang 78, kann mich eigentlich nicht mehr an Zeiten erinnern, an denen ich nichts mit Computern gemacht hätte, und habe irgendwann vor Jahren für mich entschieden, dass ich an Software, deren Quellen ich nicht einsehen und bearbeiten kann, einfach kein Interesse mehr habe.

Seit über einem Jahrzehnt arbeite ich ausschließlich mit diversen Linux-Distributionen (mit einigen kurzen Ausflügen in die Welt von NetBSD und OpenBSD); andere Betriebssysteme sind mir inzwischen einfach zu kompliziert. Ich bin Wahlmainzer der Liebe wegen (nein, nicht wegen des Karnevals). Hobbys entfallen derzeit; mein Beruf ist mein Hobby. Es kommen sicherlich auch wieder andere Zeiten, aber ich bin glücklich, wie’s grad ist, wozu als was ändern. Wer mehr wissen will, kann auf http://jonaspasche.com/app/about_us/jp schauen.

Leet: Wie seid Ihr auf die Idee gekommen, einen Webhoster wie Uberspace zu starten? Wie ist euer Konzept genau aufgebaut, was ist eure “Philosophie”?

Jonas: Entstanden ist es letztlich aus persönlichem Bedarf heraus: Wir machen halt eigentlich primär Dedicated Hosting und Clustering, aber es wurde immer wieder auch simples Shared Hosting bei uns angefragt, obwohl wir das nirgendwo angeboten haben – aber wenn man “irgendwas mit Internet” macht, bleibt das nicht aus. Wir wollten hier die Leute dann aber nicht wegschicken, insbesondere, da wir eigentlich keinen Hoster wirklich empfehlenswert fanden. Also haben wir uns überlegt, wie für *uns* das optimale Hosting aussehen müsste, wenn wir selbst irgendwo Kunde sein wollten.

Und da liegt nun mal auf der Hand: Schon allein, wenn man einen SSH-Zugang will, fallen 80% der gängigen Webhosting-Angebote direkt raus. “Zu gefährlich”, was weiß ich. Wir haben das aber immer schon anders gesehen, denn es ist ja nicht so, dass User nicht trickreich wären: Da hat man sich flugs eine PHP-Shell irgendwo hochgeladen, das Ganze dann noch hübsch unverschlüsselt per HTTP, und schon haben die Leute die Shell, die sie wollen, aber viel unsicherer, nicht supported, ohne Key-Authentifizierung, und im blödesten Fall vergessen sie noch den Passwortschutz. Soll heißen: Das Fehlen eines SSH-Zugangs bringt User eher noch dazu, sich Lösungen einfallen zu lassen, die dann sicherheitstechnisch viel grauenvoller sind als ein ganz profaner SSH- Zugang. Weiterhin war uns wichtig: Wir wollen etwas haben, was möglichst wenig speziell ist.

Wenn die Leute sich einen Account bei uns klicken, sollen sie sich sofort zu Hause fühlen. Das ist jetzt gar nicht marketing-kuschelig gemeint, sondern ganz profan: Man hat eine Shell, die sich so bedienen lässt, wie sich eine Shell eben bedienen lässt. Man hat die Tools, die man erwartet. Die Konfiguration liegt an den Stellen, die man kennt. Das klingt vielleicht merkwürdig, aber ich glaube, unser “unique selling point” ist, dass wir so unbesonders sind. Linux ist ja nun ein prima System: Ausgereift, etabliert, breite Userbasis, umfangreiche Dokumentation. Und vor allem eben quelloffen und voller Freiheit. Wenn ich nun, um mir eine Mailadresse anzulegen, meinen Browser anwerfen muss, in meinen Bookmarks das Admin-Interface anklicken muss, einloggen, klicken, klicken, klicken, Mailadresse anlegen, klicken, warten … also, in der Zeit habe ich einfach schon längst “vadduser blub” und ein Passwort eingegeben und die Adresse funktioniert, und dann hab ich mir noch einen Kaffee gemacht.

Ein Admin-Interface steht mir im Weg. Und deshalb war klar: Das machen wir einfach nicht. Woanders kriegen die Leute keine Shell; bei uns *müssen* sie auf die Shell. Und sie lernen was dabei – um gleich noch einen Pfeiler unseres Konzepts aufzumachen: Wir wollen, dass unsere User schlauer werden und kapieren, was sie da tun. Das ist erstmal unbequem, klar.

Aber es gibt den Leuten die Macht zurück, wieder selbst zu bestimmen, und wir bekommen fast täglich im Support zu spüren, wie besonders die Leute, die über den “Zwang” zur Shell gemault haben, schon nach Tagen geradezu begeistert sind: Das sei alles gar nicht so schwer wie gedacht; da würden ja auch lauter Dinge gehen, die sie in ihrem Confixx gar nicht machen könnten; alles ginge viel schneller. Und da freuen wir uns dann eben auch, weil es damit wieder ein paar Leute mehr gibt, für die Computer langfristig nicht nur ein Ding sind, wo man bunte Bildchen anklicken kann, sondern etwas, was man wirklich selbst auch in Details kontrollieren kann.

Leet: Wie ist euer Preismodell, das “zahl-so-viel-du-willst”-Modell, entstanden?

Jonas: Dessen Wurzeln sind ehrlich gesagt schlicht und einfach Faulheit. Als wir vor Uberspace.de mal eine Zeitlang Shared Hosting angeboten haben, hat’s 5 Euro im Monat gekostet. Das gab von der einen Hälfte der User Gemaule, weil’s doch woanders schon Hosting für 2 Euro gibt. Von der anderen Hälfte gab’s Gemaule, weil das doch viel zu billig sei. Soll heißen, wir haben ewig viel Zeit mit Preisdiskussionen, Rabattverhandlungen und vor allem mit “mach mir doch mal ein Angebot” verbracht.

Das war nervig; deshalb haben wir diesen Faktor kurzerhand rausgemendelt. Wir sind Admins und keine Verkäufer. Insofern könnte man auch sagen: Wir sind fies und haben den Ball einfach zurückgespielt, weil wir es leid waren, uns für unsere Preise vor jedermann rechtfertigen zu müssen. Das zwingt unsere User eben dazu, sich hier ein paar Gedanken machen zu müssen – aber genau darum geht’s ja auch. Ich meine, nehmen wir hier doch mal den 1-Euro-Billighoster. Da ruft jemand an und lässt sich erklären, wie er eine E-Mail-Adresse in seinem Outlook einrichtet. Sagen wir, 15 Minuten lang. Damit ist doch klar, dass da im Grunde schon der Gewinn der nächsten Jahr mit dem einen Telefonat aufgefressen ist. Es muss sich also niemand wundern, dass der Service meistens schlecht ist – aber lautesten meckern ja meistens die, die sich den Billigsten raussuchen und dann absolut nicht dazu in der Lage sind, einen Zusammenhang zu sehen.

Wir versuchen genau den umgekehrten Weg zu gehen: Wir erbringen Leistungen, und dann sagen wir: So, jetzt wo du die Leistung bekommen hast: Was ist’s dir wert? Denn diese Frage der Wertigkeit ist die, die meistens zu kurz kommt. Weder fallen Server einfach so vom Himmel, noch arbeiten meine Mitarbeiter kostenlos für mich. Wir wollen einfach versuchen, das etwas transparenter zu machen, um den Leuten zu ermöglichen, einen Preis zu wählen, mit dem sie den Eindruck haben, dass sie uns fair bezahlen. Hier zu knausern hieße ja letztlich auch, sich ins eigene Fleisch zu schneiden, denn damit sägte man ja nur an dem Ast, auf dem man gemeinsam mit uns sitzt: Gehen wir pleite, muss man sich einen neuen Hoster suchen, und darauf hat ja auch niemand Bock.

Der andere Aspekt des Preismodells ist: Wir waren es leid, Geld hinterherzulaufen. Denn das ist leider eine sehr unerfreudliche Erfahrung: Während die drei- und vierstelligen Monatsrechnungen unserer Server- und Clusterkunden in der Regel binnen einer Woche bezahlt sind, sind es gerade die kleinen 5-Euro-Rechnungen, denen wir dann immer noch mit drei Mahnungen hinterherlaufen mussten. Das hat vielleicht genervt..! Also war klar: Das Ding wird nur auf Guthabenbasis laufen. Es ist aber sozusagen “nachträgliches Prepaid” – also, es ist Prepaid in dem Sinne, dass wir ganz klar sagen: Du musst uns bezahlen, sonst klemmen wir dich ab.

Aber weil niemand die Katze im Sack kaufen will, gehen wir einen Monat in Vorleistung, damit du schauen kannst, wie’s bei uns so ist, und das ist kein eingeschränkter Testzugang. Es passiert technisch absolut gar nichts, wenn du dann dein Konto auflädst; du behältst einfach exakt das, was du hast. Das ist nämlich was wert, und deshalb musst du es bezahlen, wenn du es genug ausprobiert hast.

Leet: Funktioniert das System auch, oder zahlen 90% aller Kunden nur den erforderlichen Mindestpreis von 1€?

Jonas: Ich habe gerade den aktuellen Stand in der Datenbank abgefragt: Es sind rund 80% der User, die mehr bezahlen als sie zwingend müssten. Das ist mehr, als wir erwartet haben, und ich finde, das ist ein schöner Anlass, den Leuten, die uns vor allem in den ersten Wochen und Monaten für unser freies Preismodell ausgelacht haben, einmal gepflegt den Stinkefinger zu zeigen. Es sind im Regelfall die Knauserer, die glauben, auch alle anderen würden knausern. Unsere Erfahrung ist das genaue Gegenteil.

Leet: Habt ihr keine Angst, das euer Zahlungssystem einmal ausgenutzt wird?

Jonas: Nein. Man muss nicht immer vor allem Angst haben, sondern auch mal einfach was machen. Meistens überraschen einen die Menschen. Positiv.

Leet: So praktisch euer Zahlungssystem ist, findet ihr es nicht ein wenig unfair, dass Kunden, die z.B. 1€ zahlen, genau den gleichen Support und die gleichen Leistungen erhalten wie ein Kunde, der z.B. 50€ im Monat zahlt?

Jonas: Nein, denn alle User kennen das Modell und die Bedingungen. Wer 50 Euro im Monat zahlt und dann plötzlich auf den Trichter kommt, dass das ja voll unfair sei, der möge dann bitte seinen Preis eben so anpassen, bis er ihn nicht mehr unfair findet.

Wer mehr zahlt, unterstützt unser Modell eben stärker – was eben auch indirekt anderen zugute kommt, die nicht deshalb nur 1 Euro zahlen, weil sie solche Sparbrötchen sind, sondern weil sie sich schon den einen Euro vom Mund absparen müssen. Es lässt sich nun mal nicht alles in Geld aufrechnen. Wer 50 Euro an eine karitative Einrichtung spendet, hat auch nicht mehr davon als jemand, der nur 1 Euro spendet. Es macht ihn nicht mal zu einem besseren Menschen. Er trägt einfach nur dazu bei, dass es etwas gerechter auf der Welt zugeht. Daran kann ich nichts Unfaires erkennen.

Leet: Gäbe es Uberspace noch, wenn jeder Benutzer nur 1€ bezahlen würde?

Jonas: Die Frage ist wohl hypothetisch gemeint, denn schon allein die Gesetze der Wahrscheinlichkeit verhindern, dass das passiert. “Aber wenn das alle machen würden” ist so ein Totschlag-Argument, mit dem wohl oder übel jedes Geschäftsmodell zugrundegehen würde. Man stelle sich nur mal vor, jeder Kunde eines Onlineshops würde einfach nur von seinem gesetzlich verbrieften Widerrufsrecht Gebrauch machen! Vermutlich hätten wir dann bald kein Widerrufsrecht mehr, und das wäre dann wiederum zum Nachteil aller. Es gibt Dinge, die funktionieren eben nur, weil *nicht* alle sie machen.

Leet: Wie viel zahlen eure Kunden im Durchschnitt und was ist der höchste Betrag, den je ein Kunde bei euch gezahlt hat?

Jonas: Der durchschnittlich eingestellte Wunschpreis liegt derzeit bei 2,96 Euro. Bereinigt um den Mindestpreis (der ja bei der Buchung von Domains über uns ggf. auch höher als 1 Euro liegen kann, damit sichergestellt ist, dass wir die externen Domainkosten mit ihm decken können), zahlen die User durchschnittlich monatlich 1,60 Euro mehr, als sie zwingend müssten.

Das ist etwas mit Vorsicht zu genießen, denn viele User haben mehrere Accounts bei uns, insbesondere, weil wir das ausdrücklich empfehlen, wenn man z.B. mehrere Domains auf einer Site hat. Es ist bei vielen Hostern üblich, mehrere oder gar unbegrenzt viele Domains auf einem Account zu hosten (also auch mit unterschiedlichen Inhalten und ggf. auch unterschiedlichen Zugängen, so dass der Accountinhaber quasi schon als eine Art Reseller auftritt). Während wir das Hosting mehrerer Sites auf einem einzelnen Uberspace zwar auch ermöglichen (eingeschränkt, weil die sicherheitstechnischen Implikationen aus unserer Sicht beachtlich sind), ermutigen wir unsere User stattdessen dazu, sich dann lieber mehrere Uberspaces zu klicken und ihren Wunschpreis auf die einzelnen Account zu verteilen.

Klar: Wir empfehlen auf uberspace.de/prices, einen Preis zwischen 5 und 10 Euro monatlich zu zahlen, und davon ist dieser Wert weit entfernt. Auch wenn wir durchaus davon überzeugt sind, dass unser Hosting diesen Preis auch durchaus wert ist, so machen wir uns aber nichts vor: Wir hätten auch nicht damit gerechnet, dass der Durchschnittswert auch nur annähernd in diese Richtung kommen würde, sondern zum einen von vielen eher schon als Obergrenze empfunden wird, und zum anderen ist auch klar, dass unser Preismodell eben auch viele Leute anzieht, die wirklich nicht viel zahlen können.

Der dabei vergleichsweise geringe Anteil von Usern, die nur den Mindestpreis zahlen, zeigt aber auch, dass viele sich zumindest bemühen, “etwas” mehr zu zahlen – und auch 1,50 Euro statt 1 Euro sind schon eine Geste, über die wir uns sehr freuen.

Zu den höchsten eingestellten Wunschpreisen: Die Top 10 deckt hier eine Spanne zwischen 15 und 30 Euro ab. Bei den Beträgen, die User auf einmal via Überweisung aufgeladen haben, liegt die Top-10-Spanne zwischen 200 und 350 Euro.

Leet: Jonas, ich danke Dir für das Interview!