Gregor Horvath, Ing.

Industrieberatung

Softwareentwicklung

Web und Email Server auf eigener Hardware

1 Motivation

Ich habe seit Jahren meine Webseite und Email auf einem selbst verwalteten gemieteten, virtuellen VPS Server. Dann kam ein erfolgreicher Angriff auf das Host System des Providers, bei dem die Angreifer Zugriff auf alle VPS Instanzen und deren Passwörter, Schlüssel etc. haben konnten. Dies und der Verkauf meines Anbieters an eine unsympathische Firma und deren im Vergleich miserablen Support bewies den FSFE Spruch

"There is no cloud, only other people computers".

Dann kam noch die x86 Prozessorsicherheitslücken Meltdown und Spectre, die die Unsicherheit von Containern, VPS etc. zusätzlich erhöhten. Sicherheit ist eine Grundvoraussetzung für sinnvolle Datenverarbeitung.

Um eine Doku für mich zu haben und um etwas für die Verbreitung von Self Hosting beizutragen dokumentiere ich meine Vorgangsweise hier, in der Hoffnung andere mögen Hinweise, Hilfestellung und Anregung für die Realisierung der eigenen informationstechnischen Unabhängigkeit finden. Ich habe hier nur dokumentiert was nicht in freier Dokumentation oder anderen Webseiten zu finden ist.

Diese Dokumentation ist lizenziert unter der CC BY-SA 4.0. Der Quellcode unter GNU General Public License v3 or later. Bei Fragen oder kommerziellen Beratungs/Installationsbedarf bitte melden.

#ownyourdata

2 Auswahl der Hardware

Wichtig war mir Langzeitstabilität, Zuverlässigkeit und Sicherheit. Im Idealfall installiere ich den Rechner einmal und mache die nächsten mindestens 10 Jahre nur mehr Updates mit apt-get dist-upgrade. Das spart Zeit, Geld und schont die Umwelt. Selbst wenn die initiale Installation länger benötigen sollte, oder die Hardware etwas teurer wäre, oder die Software/Hardware nicht die Allerneueste wäre.

Da meine Langzeiterfahrungen mit Debian diesbezüglich exzellent sind, war mir wichtig ein ganz normales Debian und nicht eine spezielle Distribution die vielleicht in 3 Jahren nicht mehr gepflegt wird, zu verwenden. Desweiteren sollte die Hardware lange Zeit erhältlich sein, um ggf. einfach Ersatz zu haben. Dies führt zu freier Open Source Hardware, denn diese kann auch gepflegt werden wenn der Hersteller nicht mehr existiert oder das Produkt oder Ersatzteile nicht mehr anbieten will.

Meine Wahl fiel auf den bulgarischen Anbieter Olimex mit seinen Allwinner A20 Angeboten. Im IRC bekam ich sehr guten Support, auch das Forum und Wiki machten einen guten Eindruck und demonstrierten eine lebendige und kompetente Gemeinschaft. Auch Bekannte machten guten Erfahrungen mit diesen Platinencomputern. Die A20 Plattform ist recht weit verbreitet, hat gute Debian Unterstützung, ist ausgereift, von Meltdown und Spectre nicht betroffen und bietet darüberhinaus im Vergleich zu anderen SoCs exzellente I/O Eigenschaften (natives SATA & Fast bzw. Gigaethernet), die häufig der Flaschenhals in Servern sind. x86 hätte möglicherweise bessere Software Unterstützung und vermutlich auch Langzeitstabilität, aber auch deutlich höheren Stromverbrauch und mir ist keine freie Hardware für einen Mini Server bekannt. Darüberhinaus hat x86 mit Intel ME und Spectre & Meltdown massive Sicherheitsprobleme.

2.1 Vergleich A20-OLinuXino-MICRO zu A20-OLinuXino-LIME2

Diese kamen in die engere Wahl, sehen auf den ersten Blick ähnlich aus, haben aber doch einige Unterschiede. Hier die für meinen Anwendungsfall relevanten:

  MICRO LIME2
Größe 142.24 x 82.55 84 x 60
Ethernet 100 MBit 1000 MBit (~500 MBit real)
Gehäuse kann 2.5'' HDD aufnehmen keine HDD installierbar
VGA ja nein
Spannungsversorgung 6-16VDC 5 VDC
Industrieausführung (-45+85)°C ja nein
Stabilität ? es gibt Berichte über Temperaturprobleme

Die Wahl viel auf MICRO, wegen der integrierbaren Platte, Industrieausführung und Stabilität. Gigabit Ethernet wird vermutlich nicht notwendig sein, weil das Internet ohnehin langsamer ist und SATA und Ethernet auf der Platine über denselben Kanal läuft.

3 Aufstellungsort

Email benötigt einen IP Adressbereich der nicht in Spam Block Listen aufscheint.

Die gängigen IP Adressbereiche von Internet Providern sind auf solchen Listen. Darüberhinaus ist in deren Verträgen Serverbetrieb häufig verboten. Die Uplink Bandbreite von solchen Anschlüssen ist meist schlecht und für Serverbetrieb eher ungeeignet. Das Zuhause mit einem klassischen Internet Anschluss ist also ein schlechter Ort für einen solchen Server.

Gottseidank gibt es Server-Housing-Anbieter z.B. https://www.easyserver.at/serverhousing die für 3,14 € im Monat eine Stellplatz für einen kleinen Embedded Server anbieten. Das Funkfeuer embedded Board Housing hatte ich getestet. Leider bietet es nur eine ungenügende DC Stromversorgung (USB hat max. 900mA spezifiziert), die zu Instabilitäten, vermutlich durch Stromspitzen der SSD, führte. 220V AC mit Netzteil war bei Funkfeuer leider nicht möglich (im Gegensatz zu Easyserver). Eine Alternative wäre eine Funkfeuer Antenne am Dach zu betreiben, da ist Serverbetrieb erlaubt und die Bandbreiten sind theoretisch unlimitiert und symmetrisch.

4 Bestellung

folgende Artikel habe ich bestellt:

Ein Netzteil hatte ich lagernd, die Spannungsversorgung ist beim Micro ja recht flexibel. Ebenso habe ich ein Seriell zu USB Adapter / Kabel lagernd und daher nicht bestellt.

Das ganze kostete inkl. Versand ohne Ust 127,81 €. Ein paar Tage kam die Lieferung. Alles sehr problemlos. Später habe ich das SATA Kabel durch ein längeres mit einem Winkelstecker ersetzt, weil es zu Fehlern mit dem Olimex Kabel kam.

5 Zusammenbau, erste Tests

Das Gehäuse macht einen recht stabilen und professionellen Eindruck, alle Schalter / Buchsen etc. sind frei zugänglich, die Platine ist gut geschützt. Da es aus Metall ist, sollte die Wärmeabstrahlung / Leitung und elektromagnetische Abschirmung besser sein als mit Kunststoff. Eine SSD hatte ich lagernd und konnte sie mit ein wenig Fummelei mit dem SATA Kabel, das nicht optimal passt, fix eingebaut werden. Das SATA Kabel muss aus dem Gehäuse heraus geführt werden und steht daher ein wenig heraus.

Beim ersten Einschalten sah ich mit dem VGA Ausgang nichts, weil die eingestellte Auflösung / Frequenz nicht zu meinem Monitor passte. Im Boot Verzeichnis sind entsprechende Skripte zum Umstellen mitgeliefert. Ein Serielles Kabel für die initiale Einrichtung ist daher empfohlen. Die Bedienungsanleitung beschreibt das und ist übrigens von sehr guter Qualität.

Erste Belastungstests zeigten ein stabiles Laufen mit dem mitgelieferten Image. Für Desktopbetrieb schien es doch etwas langsam zu sein, der Start von Firefox z.B. brauchte etwa 7 Sekunden. Als Terminal Server Desktop Client (z.B x2go) könnte die Geschwindigkeit des Systems aber ausreichend sein.

6 Installation Debian Stretch

Da ich ein vollverschlüsseltes System haben wollte (EMails sind vertrauliche Daten) musste ich eine Neuinstallation durchführen. Daher sollte es ein normales Debian Image sein, damit ich die nächsten Jahre problemlos aktualisieren kann. Freedombox ist leider nicht verschlüsselt und enthält keine Email Server Installation.

Der aktuelle Stretch Kernel unterstützt nicht die komplette Hardware wie das Image von Olimex, es sollte jedoch für meine Anwendung genügen. Die vorhandene Olimex Installation auf der uSD Karte wollte ich als Dual Boot Option belassen, ebenso wollte ich das dort installierte U-Boot verwenden für die neue Debian Installation auf der SSD (Sata).

Im Debian Wiki gibt es eine recht gute Anleitung zur Installation. Ich entschied mich für die Variante der Installation über USB Stick, die funktionierte wie beschrieben. Der Installer funktionierte wie immer, wobei jedoch keine Netzwerkverbindung klappte. Dies lag an dem neuen Ethernet Chip in dem Revision J Board, das ich erhielt. Das Löschen der Platte vor der Verschlüsselung lief sehr, sehr langsam. Nach einem Neustart und Anhalten von U-Boot mit der Taste ESC startetet ich das neue System erfolgreich mit 

> bootcmd_scsi0

6.1 Ethernet Hardware Problem Rev. J

Ein Lösungsvorschlag für das Ethernetproblem findet sich hier. Ich entschied mich für die initramfs Methode, da ich ja per ssh das Verschlüsselungspasswort aus der Ferne eingeben möchte und daher das Ethernet bereits beim Booten vorhanden sein muss. Vom Modifizieren des Device Trees (dts/dtb) habe ich abgesehen um mit dem Debian Stable Kernel aktualisierungsfähig zu bleiben.

6.2 Batterie Info fehlt

Ein anderes Hardware Problem ist die fehlende Batterieinfo unter /sys/class/power_supply. Mit dem Olimex Kernel/Image war die Info vorhanden mit dem Debian Stretch Kernel nicht. Auch ein Laden von 

modprobe ACP20x

brachte keine Besserung. Die Info ist aber für meinen Anwendungsfall nicht essentiell. Die Batterie ist nur eine Notfall USV (unterbrechungsfreie Stromversorgung) Lösung, da Funkfeuer / easyserver keine zur Verfügung stellt. Ich habe daher das Problem nicht weiter verfolgt. Für Hinweise wäre ich natürlich dankbar.

6.3 Dual Boot, Bootreihenfolge

die Bootreihenfolge habe ich in U-Boot mit setzen der Variable boot_targets mit setenv auf zuerst scsi0 (sata) und dann mmc0 umgestellt.

6.3.1 Update auf neueres u-boot 2023

Nach Upgrade auf Debian Bullseye habe ich auch eine neuere u-boot Version des Olimex Images auf der sd Karte verwendet. Die Umstellung der Bootreihenfolge auf zuerst sata / scsi dann mmc erfolgt bei dieser so: 

=> printenv boot_targets
boot_targets=fel mmc_auto scsi0 usb0 pxe dhcp
=> setenv boot_targets fel scsi0 mmc_auto usb0 pxe dhcp
=> saveenv

6.4 Leistungstests

Mit bonni++, sysbench und iperf machte ich ein paar einfache CPU und IO Leistungstests um eine ungefähre Abschätzung der Größenordnung der Unterschiede zu meinem jetzigen VPS und vorhandenen Rechnern zu haben.

Ergebnis:

  • Olimex bei der CPU etwa 2 mal und bei IO etwa 0-3 mal schneller war als mein Raspberry PI erste Generation.
  • Mein VPS war bei CPU etwa 20 mal und bei IO ca. 2-10 mal schneller als der Olimex. (!)
  • Ein ThinkStation E20 Desktop Rechner war etwa 23 mal schneller bei CPU und IO ca. 7 mal.
  • Ein alter Maxdata PC aus 2005 mit AMD Athlon(tm) 64 Prozessor 3400+ und IDE HDD war ca. 6 mal bei CPU und 2-7 x bei IO schneller.
  • Die Netzwerkleistung war bei allen ähnlich.

Das ist kein genauer Benchmarktest und es werden auch Äpfel mit Birnen verglichen, aber man bekommt einen groben Eindruck. Überraschend war die starke Leistung des VPS Systems. Das war auch zu mehreren unterschiedlichen Zeitpunkten ähnlich. Tatsächlich hatte ich damit in der Praxis auch nie irgendwelche Leistungsprobleme.

Nach einigen Woche Betrieb wurde deutlich, dass die deutlich geringere Leistung des Olimex im Vergleich zum VPS keinen nennenswerten Unterschied als Email und Webserver mit geringen Zugriffen und schlanker Software macht. Die Spamprüfung und das Spam Lernen dauert zwar spürbar länger, aber das ist in einem akzeptablem Rahmen. Da der Olimex statt in Düsseldorf (wie der VPS) jetzt direkt in Wien steht spielen bessere Netzwerklatenzen evtl. auch eine Rolle.

6.4.1 Verschlüsselt vs. unverschlüsselt

Der Unterschied zwischen dem unverschlüsselten Olimex Debian Image und dem vollverschlüsselten Debian Stretch war beim IO Test je nach Parameter ca. 0 bis +70%. Hier hatte ich Schlimmeres befürchtet, da der Kernel die Verschlüsselungs-Hardware Unterstützung noch nicht vollständig implementiert.

6.5 Verschlüsselung per ssh entsperren

Nach einem Reboot muss über die Ferne das Passwort eingebbar sein. Dazu habe ich dropbear installiert: 

$ apt-get -y install dropbear-initramfs

dann das oben erwähnte Ethernet initramfs Skript eingebaut. Und die autorisierten Schlüssel von meinem normalen ssh auch für dropbear verwendet: 

$ ln /home/gregor/.ssh/authorized_keys /etc/dropbear-initramfs/

und dann die initramfs neu erzeugt: 

update-initramfs -u

Auf meinem Laptop auf dem ich die Entsperrung machen möchte habe ich einen ssh Alias angelegt, damit es keinen Konflikt zwischen regulärem und dropbear host key gibt: 

$ tail  ~/.ssh/config
 Host olimex_unlock
 HostName 192.168.0.111
 User root
 HostKeyAlias olimex_unlock

Ein Entschlüsselungsvorgang sieht so aus: 

gregor@host1:~$ ssh olimex_unlock
To unlock root partition, and maybe others like swap, run `cryptroot-unlock`


BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # cryptroot-unlock
Please unlock disk sda5_crypt:
cryptsetup: sda5_crypt set up successfully

Aus der Ferne kann die Entschlüsselung ohne Passworteingabe z.B per Skript so erfolgen: 

$ ssh olimex_unlock 'echo -n "password" > /lib/cryptsetup/passfifo'

Um einen unbeaufsichtigten Neustart zu ermöglichen überprüft ein anderer Server per cron job regelmäßig, ob eine Passworteingabe notwendig ist und führt diese über ssh aus.

Quellen:

7 Hardware Redundanz

Ich habe dieselbe Hardware (mit anderer Gehäusefarbe) noch einmal gekauft und als festplattenbasierten Backupserver eingerichtet. Im Notfall kann ich rasch den Webserver mit der Ersatzhardware betreiben. Das Backup muss dann solange die Reparatur/Ersatz dauert manuell gemacht werden.

Autor: Gregor Horvath

Created: 2023-09-20 Mi 13:48

Validate