Szenario A: Cluster Compute Node

Als richtiger IT-Nerd habe ich natürlich ein Homelab. Konkret werkeln zwei Rechner als Cluster auf Basis Proxmox VE. Dazu dient ein Raspberry Pi als „QDevice“, um im Falle einer Wartung oder Störung festzustellen, welche Cluster-Knoten noch aktiv sind. Ein QDevice stellt aber keine Rechenkapazität zur Verfügung, darum sollte ein Mini-PC als 3. Knoten in den Cluster ziehen, Rechenleistung beisteuern und das QDevice obsolet machen.

Der GMKtec NucBox G5 N97 wurde auf Amazon für ca. 150€ angeboten. Mit Intel N97 CPU, 12 GB RAM und 256 GB SSD ist er gegenüber den anderen Knoten bzgl. Speicher und Storage zwar unterlegen, aber die Intel N97 CPU ist den AMD Ryzen 3 3200G der anderen Knoten ebenbürtig. Und mit einem (einstellbaren) Thermal Design Power (TDP) von 8-15 Watt im Stromverbrauch deutlich unter den 65W TDP der AMD CPUs.

Um es kurz zu machen: Die gestellte Aufgabe als „Compute-Knoten“ im Cluster hat der G5 einwandfrei erfüllt. Die Installation von Proxmox VE 9, die Aufnahme in den Cluster und der Betrieb von virtuellen Maschinen liefen völlig reibungslos. Die Rahmendaten des G5 reichen für Services wie Home Assistant oder WordPress (für diesen Blog) völlig aus.

Für Nextcloud oder Photoprism ist die 256 GB SSD aber zu klein. Da aufgrund der winzigen Abmessungen des G5 auch nur 2242 M.2 SSDs möglich sind, wird es bei mehr Speicherbedarf schnell teuer. Außerdem gibt es nur einen M.2 M-Key Slot. Spiegelung von 2 SSD als RAID ist damit unmöglich.

Szenario B: Office & Internet-PC

Also habe ich den G5 für seinen eigentlichen Anwendungsfall vorbereitet: Als winziger, hinreichend dimensionierter und performanter Arbeitsplatz für Office und Internet. BIOS zurückgesetzt, Windows 11 re-installiert (Produktschlüssel ist im BIOS/UEFI hinterlegt) und ins WLAN aufgenommen.

Das Ergebnis ersprach vollumfänglich den Erwartungen. Der G5 ist leise und erfüllt die Aufgaben eines Office PCs zuverlässig und unauffällig. Die N97 CPU kommt (in diesem Szenario) niemals an ihre Grenzen, 12 GB RAM (festverlötet) und 256 GB SSD Speicher sind absolut ausreichend. An einem 4K Monitor angeschlossen, konnte auch die interne Grafikeinheit mit YOUTube und anderen Quellen nicht ins Schwitzen gebracht werden. Spiele jedoch habe ich – da abseits des Szenarios – nicht getestet.

Ergebnis: eBay

Warum geht der G5 letztendlich in den Wiederverkauf zu eBay und warum ist das nicht dem Gerät anzulasten?

Nun – den G5 als Compute Node im Cluster einzusetzen ist zwar technisch abbildbar und der geringe Stromverbrauch von Vorteil, aber die Ressourcen des G5 und seine mangelnde Erweiterbarkeit reduzieren die Einsatzszenarien, gerade bei virtuellen Maschinen. Allerdings ist der G5 dafür auch nicht gemacht. Wie man auf dem Bild oben erkennt, wurde inzwischen ein vollwertiger, 3. Knoten zusammengestellt.

Den Anspruch ein kleiner und diskreter Office PC zu sein, der auch bei großen Dokumenten, Multimedia-Wiedergabe und (vermutlich) einfachen Spielen nicht in die Knie geht, erfüllt der GMKtec NucBox G5 vollumfänglich. Allerdings habe ich dafür keinen Bedarf, dank hinreichend Arbeitsplatz-Rechnern im Zugriff.

Es bleibt also Festzuhalten, der der GMKTec NucBox G5 gemäß seiner Spezifikation als Office PC sehr gut funktioniert. Leistung und Anschlußmöglichkeiten sind ausreichend, Strombedarf und Lautstärke moderat.

Mein größter Kritikpunkt am G5 ist der USB-C-Port, der ausschließlich der Stromversorgung dient (über das mitgelieferte Netzteil). Besitzt man einen Monitor, der einen vollwertigen USB-C-Anschluß inkl. Power Delivery bereitstellt, bringt das beim G5 leider gar nichts. Es sind mindestens USB-C-Netzteil, USB-Hub bzw. -Tastatur/-Maus und HDMI-Kabel zu verbinden.

Außerdem wissenswert: Die USB-Anschlüsse des GMKtec NucBox G5 liefern nur minimal Strom an angeschlossene Peripherie. Eine 2,5“ HDD im USB-Gehäuse kann noch bedient werden, eine 2. an einem anderen Port setze immer wieder aus.

Der Beitrag GMKtec NucBox G5 N97 Mini-PC erschien zuerst auf dahlen.org.

Corona hat mich erwischt, mit mäßigen Auswirkungen. Und die M2 SSD in meinem Server ist „geplatzt“, mit deutlichen Auswirkungen. Und eine der beiden HDDs im RAID1 sagt ihren nahenden Tod via S.M.A.R.T.-Warnung voraus – zumindest das soll ohne Auswirkungen bleiben.

Eine unwillkommene Gelegenheit also dem RAID 1 zu unverminderter Stabilität (und einer Verdoppelung der Kapazität) durch den Tausch beider Festplatten gegen neue zu verhelfen. Und da dies nicht das erste Mal ist und sicher auch nicht das letzte Mal sein wird, diesmal mit Mitschrift.

Ausgangsituation

Mein Heim-Server verwendet (aktuell) Ubuntu 22.04 Server als Betriebssystem. Die beiden 2,5″ Seagate Barracuda Festplatten sind als /dev/sda und /dev/sdb eingebunden. Sie wurden aus dem inzwischen verkauften ASRock Desk Mini in den neuen 19″-Server übernommen.

Via Linux Software RAID wird ein RAID 1 /dev/md0 über die beiden Platten realisiert. Das ASUS A320I Mainboard unterstützt hot-plug, d.h. die Platten können im laufenden Betrieb abgezogen oder angesteckt werden.

Der Wechsel der Festplatten wird im laufenden Betrieb stattfinden. Ich beuge Datenverlusten durch regelmäßige, ausgelagerte und geprüfte Backups mit Borgmatic vor.

Warnung

Die im folgenden beschriebenen Schritte sind auf meine Hard- und Software-Konstellation ausgerichtet und haben dort fehlerfrei funktioniert. Dennoch kann selbst bei korrekter Ausführung das Risiko des Datenverlusts niemals ganz ausgeschlossen werden.

Das Nachvollziehen der hier beschriebenen Schritte geschieht auf eigene Gefahr!

Festplatte aus RAID entfernen

Zunächst gilt es eine der beiden Festplatten zu entfernen (hier: /dev/sda). Da diese vom RAID aktuell verwendet wird, muss sie zunächst als fehlerhaft markiert werden (es sei denn, sie ist es bereits):

$ sudo mdadm --manage /dev/md0 --fail /dev/sda

Im nächsten Schritt wird die fehlerhafte bzw. als fehlerhaft markierte Festplatte aus dem RAID entfernt:

$ sudo mdadm --manage /dev/md0 --remove /dev/sda

Um das Entfernen der Platte vorzubereiten und die Identifizierung zu erleichtern, wird als nächstes die Platte in den Sleep-Modus geschickt. Bei SSDs ist dieser Schritt natürlich nicht notwendig:

$ sudo hdparm -Y /dev/sda

Und schließlich (aus reiner Vorsicht) melden wir die Platte noch im Kernel ab. Damit sollte das Entfernen nun sicher sein:

$ echo 1 | sudo tee /sys/block/sda/device/delete

Nun steht der physikalische Tausch der Platten an, den ich an dieser Stelle natürlich nicht im Detail beschreiben möchte. Ist die neue Platte eingebaut und wieder online, beginnt man mit der Anmeldung am RAID.

Festplatte in RAID aufnehmen

Da die neue Platte (3,5″ 4TB WD RED Plus) fabrikfrisch und ohne Initialisierung daherkam, musste zunächst eine Partitionstabelle angelegt werden, auch wenn die gesamte Platte ohne dedizierte Partitionen verwendet wird:

$ sudo cfdisk -z /dev/sda

Ist auch dies geschehen, kann die Platte – wie gesagt, als Ganzes – am RAID angemeldet werden:

$ sudo mdadm --manage /dev/md0 --add /dev/sda

Die Linux RAID-Software beginnt nun mit der Synchronisierung der 2. Platte, d.h. im Wesentlichen werden die Informationen der verbliebenen „alten“ Platte (/dev/sdb) auf die neue (/dev/sda) übertragen.

Das nimmt einige Zeit in Anspruch und während dieser Zeit ist das RAID recht „empfindlich“, da bis zum Abschluß der Synchronisierung logisch nur eine Platte für das RAID zur Verfügung steht. Bei höheren RAID-Leveln (5,6) sieht das natürlich anders aus und bei RAID 0 ist mit dem Ausfall einer Platte eh „Schicht im Schacht“.

Über den Fortschritt der Synchronisierung kann (und muß) man sich immer wieder informieren. Ein Tausch der verbliebenen, „alten“ Platte /dev/sdb ist erst nach vollständiger Synchronisierung möglich und erfolgt dann analog zu den obigen Schritten.

Der Möglichkeiten zur Analyse lauten:

$ sudo mdadm --detail /dev/md0

bzw.

$ cat /proc/mdstat

Die Ausgaben zum ersten Befehl ist umfangreich, aber eher zusammenfassend, der relevante Wert befindet sich in „Rebuild Status“:

/dev/md0:
           Version : 1.2
     Creation Time : Fri Apr  1 17:19:01 2022
        Raid Level : raid1
        Array Size : 1953382464 (1862.89 GiB 2000.26 GB)
     Used Dev Size : 1953382464 (1862.89 GiB 2000.26 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent
     Intent Bitmap : Internal
       Update Time : Wed Nov 30 19:10:58 2022
             State : active, degraded, recovering
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 1
Consistency Policy : bitmap
    Rebuild Status : 32% complete
              Name : example:0  (local to host example)
              UUID : a3738222:357f6cb8:b4014413:62be2f37
            Events : 109210
    Number   Major   Minor   RaidDevice State
       2       8       16        0      active sync   /dev/sdb
       3       8        0        1      spare rebuilding   /dev/sda

Der zweite Befehl führt zu einer kürzeren, aber detaillierteren Anzeige. Die Ausgabe sollte der folgenden ähneln, natürlich mit unterschiedlichen (und bei mehrfachem Aufruf ansteigenden) Angaben zum Fortschritt:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb[2] sda[1]
      1953382464 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.2% (5148736/1953382464) finish=398.8min speed=81402K/sec
      bitmap: 5/15 pages [20KB], 65536KB chunk
unused devices: <none>

Nun heißt es Geduld zu haben, bis das Recovery abgeschlossen ist und der Wechsel der verbleibenen Platte nach dem gleichen Muster vollzogen werden kann.

RAID und Filesystem vergrößern

In meinem Falle wurden 2x2TB Platten gegen 2x4TB Platten getauscht. Entsprechend vergrößerte sich der für RAID1 zur Verfügung stehende Platz von 2TB auf 4TB. Dieses Mehr an Platz wird aber nicht automatisch genutzt. Fragt man den genutzten Speicher mittels mdadm ab, so werden nur 2TB berichtet.

$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Fri Apr  1 17:19:01 2022
        Raid Level : raid1
        Array Size : 1953382464 (1862.89 GiB 2000.26 GB)

Der folgende Befehl dehnt das RAID nun auf den gesamten, zur Verfügung stehenden Platz aus:

$ sudo mdadm --grow /dev/md0 --size max

Ein erneuter Aufruf von mdadm bestätigt die neue Größe:

$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Fri Apr  1 17:19:01 2022
        Raid Level : raid1
        Array Size : 3906886488 (3.64 TiB 4.00 TB)
[...]

Nur – so wie das RAID nicht unmittelbar den gesamten, verfügbaren Platz auf den Datenträgern verwendet hat, so nutzt auch das Filesystem auf dem RAID nicht ohne weiteren Eingriff den verfügbaren Platz, wie mittels df festgestellt werden kann:

$ df -h /srv
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        1.8T  271G  1.5T  16% /srv

Aber auch das lässt sich beheben, mit dem entsprechenden Werkzeug des Filesystems. Da ich ext4 verwende, ist resize2fs das Mittel der Wahl:

$ sudo resize2fs /dev/md0
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/md0 is mounted on /srv; on-line resizing required
old_desc_blocks = 233, new_desc_blocks = 466
The filesystem on /dev/md0 is now 976721622 (4k) blocks long.

Nochmal das Ergebnis mit df prüfen und fertig:

$ df -h /srv
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        3.6T  271G  3.2T   8% /srv

Postskriptum

Im Nachhinein hat sich herausgestellt, dass der nahende Tod der installierten 2,5″ 2TB Seagate Barracuda-Platten ein Fehlalarm war, verursacht durch die tatsächlich endgültig zerstörte WD Green. Auf letzterer war leider das Betriebssystem installiert (non-raid). Fairerweise sei darauf hingewiesen, dass die WD Green Serie ausdrücklich nicht auf Dauerbetrieb ausgelegt ist. Grundsätzlich setze ich gerne auf Western Digitial und so wird als Ersatz in Kürze eine WD Red SA500 eingebaut.

Nach dem Ersetzen der SSD, dem Neuaufsetzen des OS und dem Einspielen des Backups waren auch die S.M.A.R.T.-Werte der „alten“ Platten wieder einwandfrei. Aber die Neuen waren halt schon geliefert, was will man machen …

Der Beitrag Linux Software RAID – Festplatte(n) tauschen erschien zuerst auf dahlen.org.

Dabei bleibt der Anwendungsfall unverändert: Die Auswertung und Steuerung von ca. 50 Zigbee-Geräten im Außenbereich der Dahlen-Mühle. Leuchtmittel, Sensoren und Steckdosen auf einer Fläche von über 10.000m², ohne direkten Zugang zum Internet und teilweise abseits einer dauerhaften Stromversorgung.

Hardware aktuell

Seinerzeit habe ich einen Raspberry Pi 4 und das Phoscon Raspbee II-Modul als Hardware-Plattform gewählt. Ziel war ein kompakter, unauffälliger Aufbau mit geringem Stromverbrauch. Dieses Ziel wurde erreicht, doch der Betrieb ist nicht frei von Problemen:

• die SD-Karte im Raspberry Pi 4 macht schlapp, obwohl es sich um eine Endurance-Version von Samsung handelt. Gleichzeitig ist es mir nicht auf Anhieb gelungen, den Raspberry von USB-Stick der -Disk zu booten (wie z.B. beim Raspberry Pi 3)
• die Raspbee II-Karte werkelt unsichtbar vor sich hin, aber (ich fürchte) ihre Bauform hat negativen Einfluss auf die Reichweite. Gleichzeitig fehlen ihr moderne Funktionen wie Touchlink
• trotz guter technischer Werte kommt der Raspberry Pi 4 doch an seine Grenzen. Im „Wirkbetrieb“ fällt das wenig auf, aber bei der (remote) Administration kommt es immer wieder zu Wartezeiten

Besonders der letzte Punkt treibt einem die Schweißperlen auf Stirn, wenn man nach einem Reboot aus der Ferne nicht weiß, ob die Kiste einfach noch ein paar Minuten braucht oder man den Weg ins 25km entfernte Elternhaus antreten darf.

Neue Hardware

Die neue Hardware soll entsprechend die identifizierten Ursachen beseitigen und gleichzeitig den unveränderten Anspruch eines unauffälligen 24/7-Betriebs bei geringem Stromverbrauch erfüllen.

Konkret bedeutet dies:

• sparsame x86-Hardware mit angemessener Leistung
• kompakt (was zu Lasten der Flexibilität gehen darf)
• keine beweglichen Teile, wie Lüfter oder mechanische Festplatten
• einwandfreie Unterstützung durch (Ubuntu) Linux
• moderne Zigbee Coordinator-Hardware mit hoher Reichweite

Minisforum N40 Mini-PC

Der Minisforum N40 (Datenblatt) Mini-PC erfüllt die gestellten Kriterien und ist für den angedachten Anwendungsfall mehr als ausreichend:

• Intel Celeron N4020 CPU (2 Kerne, bis zu 2,8 GHz)
• 4 GB RAM (DDR4, nicht erweiterbar)
• 64 GB „eMMC“ SSD
• 3 USB-A 3.0-Anschlüsse
• RJ45 GbE LAN und IEEE 802.11ac Dual-Band Wi-Fi

Bei Bedarf kann eine zusätzliche SSD (M.2 2242 SATA 3.0) verbaut werden. Ich habe aber darauf verzichtet, weil nach der Installation und Konfiguration nur 8,5 GB der verfügbaren 56 GB der eMMC belegt waren.

Das Netzteil (DC 12V, 1,5A) liefert bis zu 18 Watt, der tatsächliche Verbrauch des N40 in meiner Konstellation liegt zwischen 3 und 5 Watt. Die CPU ist mit Grafikeinheit, für den Anschluss an Fernseher / Monitor (während der Installation) steht ein Standard-HDMI Port zur Verfügung.

Die Kantenlänge des N40 entspricht übrigens ziemlich genau dem Durchmesser einer Audio CD (wer es noch kennt). Die CPU wird passiv gekühlt, das gesamte System gibt keinerlei Geräusche von sich und wird nicht warm.

SONOFF ZBDongle-P

Bei der Wahl der neuen Coordinator-Hardware fiel die Wahl auf das SONOFF Zigbee 3.0 USB Dongle Plus (kurz: ZBDongle-P), welches auf der Adapter-Seite von Zigbee2MQTT als „recommended“ aufgeführt wird und über einen modernen Texas Instruments CC2652P Chip mit zusätzlichem Verstärker verfügt.

Direkt eingesteckt steht das Dongle deutlich über den N40 hinaus. Allerdings wird bei USB 3.0 und Zigbee wg. möglicher Interferenzen der Einsatz einer USB-Verlängerung empfohlen, was eine relativ freie Platzierung des Dongles erlaubt. Genau wie der Minisforum N40 wird das Dongle auch bei max. Verstärkung von 20dBm nicht warm.

Der Einsatz des Dongles mit Zigbee2MQTT ist problemlos und es liefert „vernünftige“ LQI-Werte. Beim Raspbee II steigen diese mit der Zeit von 0 bis 255 und starten dann wieder erneut. Die Aussagekraft des Link Quality Indicators ist zwar begrenzt, aber stabile Werte sind dennoch von Vorteil.

Software: Home Assistant

Unverändert soll Home Assistant in der „Container„-Edition zum Einsatz kommen, in Verbindung mit Zigbee2MQTT. Jedoch werden die bestehende Installation und Konfiguration verworfen und neu aufgebaut. Nach diversen Iterationen des technisch „Machbaren“ gebe ich dem Wunsch meiner Eltern nach und reduziere auf „das Nötigste“: Licht an bei Bewegung in der Dunkelheit.

Auf dem Gelände sind mehrere, batteriebetriebene Bewegungssensoren von Philips Hue verteilt. Diese werden via Automatiken in Home Assistant mit einen oder mehreren Gruppen von Leuchten verbunden und agieren entsprechend – aber nur wenn es draußen dunkel ist.

Die „Sun„-Integration von HA wird verwendet, um über Dunkelheit zu entscheiden: Sie beginnt 15min nach Sonnenuntergang und endet 30min vor Sonnenaufgang. Alternativ kann die tatsächliche Helligkeit als Indikator dienen, denn die Hue Sensoren liefern ensprechene Angaben. Damit wären dunkle Phasen tagsüber abgedeckt (z.B. bei schlechtem Wetter).

Für meine Belange habe ich ein Repository auf Github angelegt, welches aber ausreichend generisch ist und auch für andere Einsteiger hilfreich sein könnte. Quelle und Instruktionen finden sich unter https://github.com/m0wlheld/homeassistant-zigbee2mqtt/.

Leider bedeutet ein Wechsel der Zigbee-Controller-Plattform (von Raspbee II auf den TI CC2652P des Sonoff Dongle) immer auch eine erneute Einbindung (Pairing) der Zigbee-Geräte. Ein Wochenende mit Leiter, Schraubendreher und Wäschekörben voller smarter LEDs ist also garantiert …

Der Beitrag Neue Hardware für den Zigbee-Hub und Home Assistant erschien zuerst auf dahlen.org.

Der „Alte“

Der N54L Generation 7 (G7) ist ein Microserver auf Basis der AMD Turion II Neo Dual-Core CPU. Sie ist auf einem HP Custom Mainboard verlötet und bietet 2x 2,2 GHz. Ihr zur Seite stehen aktuell 8 GB RAM und 4x 2 TB HDDs (WD Red) im RAID 5 Verbund.

Auf diesem Server laufen Dienste, welche in unserem Haus durch mich und andere Familienmitglieder genutzt werden. Zunächst natürlich Homegear und Home Assistant zur Heimautomatisierung. Aber auch Datenbanken und Datei-Freigaben für die Windows-Geräte im Haus. Und eben auch mehrere Minecraft Server – zur Unterhaltung.

All das bringt die CPU immer deutlicher an ihre Grenzen, es kommt zu Mikrorucklern („Lags“) in Minecraft und zwischen auslösendem Ereignis und Reaktion des Smart Home können schonmal Sekunden vergehen. Man liegt also bereits im Dunkeln, wenn die Beleuchtung endlich angeht.

Der „Neue“

Zeit also für etwas Neues, was größer (= leistungsstärker) und gleichzeitig kleiner (= raumsparender) ist. Von den insgesamt 5,6 TB Plattenplatz waren nämlich dauerhaft nie mehr als 600 GB belegt.

Es war schnell klar, dass ein Eigenbau zum Einsatz kommen sollte. Möglichst klein, doch mit ausreichend aktueller Hardware und Platz für mindestens 2 Festplatten. Intel NUC oder Gigabyte BRIX Systeme kamen daher nicht infrage. Außerdem sollte wieder Ubuntu Linux zu Einsatz kommen. Damit schieden NAS-Systeme von Synology oder QNAP aus.

Nach einiger Recherche stieß ich auf System, das für meine Anforderung wie gemacht schien: Den ASRock DeskMini A300 Barebone.

ASRock DeskMini A300

Der DeskMini A300 ist ein Barebone im Mini-STX Format. Die Abmessungen des Gehäuses betragen 155x155x80 mm. Auf dem Mainboard befindet sich ein AM4 Sockel mit A300 Chipsatz für moderne AMD CPUs der Picasso, Raven Ridge oder Bristol Ridge Familie.

Somit sind viele aktuelle AMD Athlon und Ryzen CPUs nutzbar, solange die TWP nicht 65 W übersteigt. Außerdem muss eine CPU mit integrierter Grafik (APU bzw. iGPU) zum Einsatz kommen. Das Bild-Signal kann via HDMI, Display Port oder D-SUB/VGA abgegriffen werden.

Verfügbar sind weiterhin M.2 Slots (Type 2280), SATA 6GB/s, Gigabit-LAN und USB 3.1 vorhanden. Der maximale Speicherausbau beträgt 64 GB und im Gehäuse haben 2 2,5″ HDDs bis max. 9mm Dicke Platz.

AMD Athlon 200GE

Die AMD Athlon 200GE APU ist eine Low-Cost CPU aus der Raven Ridge Familie mit 2 Kernen in Zen-Architektur. Sie bietet 4 logische CPUs und taktet mit bis zu 3,2 GHz.

Neben der CPU ist noch eine Vega 3 Grafikeinheit verbaut, so dass auf eine dedizierte Lösung verzichtet werden kann. Mit 35 W TWP passt sie locker in die Spezifikation des DeskMini A300 und liegt leistungstechnisch doch weit über dem Turion II des N54L.

Speicher

Ein Barebone muss neben der CPU natürlich noch mit flüchtigem und permanentem Speicher bestückt werden. Der Athlon 200GE unterstützt DDR4-2666 Speicher, entsprechend den Vorgaben des Boards kommt ein 2x 8 GB Kit von Crucial zum Einsatz.

Als Medium für das Betriebssystem (Ubuntu Server 18.04 LTS) kommt eine Samsung PM981 256 GB SSD im M.2 2280 Format zum Einsatz. Über NVMe angesteuert, können bis zu 3GB/s gelesen werden. Als „Bulk Version“ ohne Kühlkörper ist sie für knapp 50 EUR erhältlich.

Die eigentlichen Nutzdaten werden auf 2 Seagate BarraCuda 2000 GB HDDs abgelegt, welche über md-tools zu einem RAID 1 (also gespiegelt) verbunden sind. Bis zu 125 MB/s lesender Transfer sind möglich. Aufgrund der beengten Platzverhältnisse können keine HDDs höher als 9 mm verbaut werden, die Seagates sind 7,5 mm dick.

Fazit

Der Eigenbau auf Basis des DeskMini A300 erfüllt meine Anforderungen bis dato in vollem Umfang. Er ist klein, leistungsstark, dabei leise und günstig in Anschaffung und Unterhalt. Der gesamte Setup hat ca. 450 EUR gekostet.

Der Zusammenbau war kinderleicht, lediglich die Montage der zweiten HDD ist etwas aufwendiger, dann muss das Mainboard demontiert werden.

Die Geräuschentwicklung mit dem „boxed“ Kühler des Athlon 200GE ist moderat, für Wohn- oder Schlafzimmer sicher zu laut, steht mir allerdings ein eigener Raum für die „Haus-IT“ zur Verfügung.

Ausblick

Die Migration des N54L auf den neuen Server wird sicherlich einige Zeit in Anspruch nehmen. Vorteilhaft ist, dass schon auf dem alten Server Docker und Docker Compose zum Einsatz kommen. Nutz- und Konfigurationsdaten der Anwendungen sind daher leicht identifizier- und kopierbar.

Um meine „Skills“ im Bereich Container Orchestrierung auszubauen, werde ich wohl Kubernetes oder Rancher K3s installieren. Letzteres läuft schon auf den Raspberry Pis im Haus, so dass ein Cluster mit 4 Nodes entstünde.

Sollte da neue System wider Erwarten an seine Grenzen stoßen, bleiben mir mehrere Möglichkeiten der „vertikalen“ Skalierung: Eine leistungsstärkere CPU und/oder mehr Hautpspeicher. Auch eine „horizontale“ Skalierung ist möglich, durch mehrere Duplikate des neuen Systems. Das Volumen eines N54L (ca. 14 Liter) ist auf jeden Fall ausreichend für bis zu 6 ASRock DeskMinis.

Weiterführende Informationen

Software und Dokumentation

• Ubuntu Server
• Docker Community Edition für Ubuntu
• Rancher K3s
• Prometheus
• Homegear
• Home Assistant
• Minecraft

Produkte*

• ASRock DeskMini A300 Barebone (Produktseite)
• AMD Athlon 200GE APU boxed (YD200GC6FBBOX) (Produktseite)
• Crucial DDR4-2666 16GB Kit (CT2K8G4SFS8266)
• Samsung PM981 256GB M.2 SSD (MZVLB256HAHQ)
• Seagate BarraCuda 2000GB HDD (ST2000LM015) (Datenblatt)
• Western Digital RED 2TB 3,5″ HDD (WD20EFAX)

Der Beitrag ASRock DeskMini A300 erschien zuerst auf dahlen.org.

In diesem dritten und vorerst letzten Teil wird auf die Anbindung von stationären und mobilen Clients eingegangen. Dabei kommen vorerst iOS und Mozilla Thunderbird zum Einsatz. Der fiktive ownCloud Server ist dabei unter der URL https://owncloud.dahlen.org/ mit dem Benutzer cloudmaster zu erreichen.

Client-Geräte und -Software

Die Nutzungsmöglichkeiten von ownCloud via iPhone oder anderen mobilen Geräten sind vielfältig. Neben einem Zugriff über die entsprechende ownCloud App können Kontakte und Kalenderdaten über das CardDAV resp. CalDAV Protokoll verwaltet werden, welches von iOS direkt unterstützt wird.

Geräte mit Apples iOS

Die entsprechenden Assistenten zur Einrichung in iOS sind recht straight-forward, benötigen aber etwas Vorarbeit auf der Server-Seite. Zur automatischen Erkennung der Möglichkeiten fragt iOS zunächst die Pfade

• /.well-known/carddav bzw.
• /.well-known/caldav ab.

Diese existieren in ownCloud nicht, ihre Funktionalität allerdings sehr wohl, nur an anderer Stelle. Am einfachsten ist es jetzt, die Anfragen per HTTP Redirect umzuleiten. Dazu wird die Konfiguration unter /etc/lighttpd/lighttpd.conf um einen Eintrag ergänzt, z.B. ab Zeile 22:

url.access-deny = ( „~“, „.inc“ )
url.redirect = (
„^/.well-known/carddav$“ => „/remote.php/carddav/“,
„^/.well-known/caldav$“ => „/remote.php/caldav/“
)

Außerdem ist es wichtig, daß man den eigenen Kalender in ownCloud über den Browser mindestens 1x aufruft. Erst dann werden die notwendigen Strukturen in ownClouds CalDAV-Server eingerichtet.

Dann kann die Anbindung via iPhone beginnen. Die Assistenten befinden sich in Einstellungen – Mail, Kontakte, Kalender – Account hinzufügen …. Aus der Liste der Möglichen Anbieter (iCloud, Exchange usw.) wählt man den letzten Punkt (Andere):

Die Dialoge für CardDAV und CalDAV sind im Wesentlichen identisch. Durch unsere Vorbereitung reicht es, den Namen des Server (owncloud.dahlen.org, ohne https://), den Benutzernamen und das Paßwort einzutragen. Alles andere wird bei Wahl von Weiter oben rechts automatisch ermittelt.

Und das war es dann auch schon. Der neue Kalender taucht in der Kalender-App auf und nimmt Termine entgegen. Die Enrichtung eines Kontakt-Accounts geschieht völlig analog und wird hier nicht weiter beschrieben.

Mozilla Thunderbird mit Lightning Add-On

Mozillas Mail-Client Thunderbird wird durch das Kalender-AddOn Lightning in die Richtung eines Personal Information Assistents, wie z.B. Outlook gerückt. Als Vertreter der Open Source Idee war zu erwarten, daß eine Anbindung an offene Standards möglich ist.

Zumindest für den Kalender gilt das auch. Nach der Installation von Lightning und dem Neustart von Thunderbird wird über das Menü Datei – Neu – Kalender der Assistent für einen neuen Kalender gestartet. Zunächst entscheidet man sich für einen Kalender im Netzwerk.

Im folgenden Dialog wählt man das Kalender-Format, was hier CalDAV ist. Der Dialog erwartet auch die Adresse, unter welcher der Kalender erreichbar ist. An dieser Stelle ist es leider nicht ausreichend einfach nur die URL des ownCloud-Servers anzugeben. Vielmehr wird hier die vollständige URL zum persönlichen Kalender erwartet.

Diese URL kann in ownCloud ausgelesen werden. Dazu wählt man in der Web-Oberfläche von ownCloud den Kalender und klickt dann oben rechts auf das Kalender-Symbol. Ein weiterer Klick auf das Weltkugel-Symbol offenbart dann den CalDAV-Link.

Gemäß den Beispieldaten in diesem Artikel lautet die CalDAV-Adresse meines Default-Kalenders
https://owncloud.dahlen.org/remote.php/caldav/principals/cloudmaster/defaultcalendar. Diese trägt man in den offenen Dialog ein und bestätigt mit Weiter.

Im nächsten Dialog-Schritt hat man noch die Möglichkeit die Darstellung des Kalendars zu personalisieren und eine E-Mail-Adresse zuzuordnen. Außerdem werden in einem Popup die Anmeldedaten abgefragt.

Schließlich kommt es zum letzten Schritt des Dialogs, in welchem man einfach nur auf Fertigstellen klickt. Das war’s.

Damit hat mein Protokoll zur Einrichtung des eigenen, abgesicherten ownCloud-Servers auf dem Raspberry PI und die Anbindung an Clients sein vorläufiges Ende erreicht. Es ist nicht ausgeschlossen, daß Ergänzungen für weiter Clients wie Android oder Outlook folgen.

Ich hoffe, daß meine Ausführungen dem ein oder anderem zur Hilfe reichen und freue mich auf Feedback.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 3: Anbindung von Clients) erschien zuerst auf dahlen.org.

Dazu wurde die Web-Server-Software lighttpd installiert und die Kommunikation via Transport Layer Security (TLS) abgesichert. Mein (fiktiver) Web-Server ist nun ausschließlich unter https://owncloud.dahlen.org/ erreichbar.

Installation von ownCloud

Wegen der begrenzten Ressourcen des Raspberry PI wurde nicht auf das ownCloud-Paket der Distribution (Raspian) zurückgegriffen, da hier eine Abhängigkeit zum Apache 2 http-Server besteht. Dennoch kann das Gros der notwendigen Software aus den Paketquellen der Distribution genommen werden, z.B. PHP5 mit seinen Modulen:
$ sudo apt-get install php5-gd php5-curl php5-sqlite php5-cgi

PHP5

Nach der Installation von PHP5 sind bei Bedarf zwei Einstellungen anzupassen, welche Auswirkung auf den gleichen Aspekt haben: Die maximale Größe für Uploads nach ownCloud. Es handelt sich um folgende Parameter, die sich in der Datei /etc/php5/cgi/php.ini befinden:

• upload_max_filesize
• post_max_size

Ich habe beide Werte auf 16M gesetzt. In erster Linie möchte ich ownCloud für Kalender- und Kontaktdaten nutzen, aber mit 16MB sind auch mal ein Bild oder ein größeres Dokument drin.

Vor dem Beginn der eigentlichen Installation von ownCloud muß PHP5 noch via FastCGI angebunden werden. Dazu ist auch ein Neustart des Web-Servers notwendig:
$ sudo lighttpd-enable-mod fastcgi-php
$ sudo service lighttpd force-reload

ownCloud

Jetzt kann das ownCloud-Setup-Skript direkt vom Anbieter gezogen werden. Abgelegt wird es im Document-Root des Web-Servers /var/www/:
$ sudo wget -O /var/www/setup-owncloud.php \
https://download.owncloud.com/download/community/setup-owncloud.php

Außerdem sind noch Berechtigungen anzupassen, damit ownCloud Daten nachladen und installieren kann:
$ sudo chown www-data:www-data /var/www /var/www/setup-owncloud.php

Schließlich wird das Skript im Browser aufgerufen, gemäß Beispiel lautet die URL zum Setup https://owncloud.dahlen.org/setup-owncloud.php.

Es erscheint der Begrüßungsbildschirm der Installation. Dieser kann ohne Änderungen per Next bestätigt werden.
Der Startbildschirm der OwnCloud Installation

Im folgenden Dialog kann man das Zielverzeichnis der Installation auswählen, relativ zum Document Root. Auch hier reicht ein Klick auf Next, auch wenn man mit owncloud nicht einverstanden ist (dazu später mehr):

Im Hintergrund lädt ownCloud nun die aktuelle Version vom ownCloud-Server und entpackt sie im vorhin gewählten Zielverzeichnis. Je nach Internet-Anbindung kann dieser Schritt etwas dauern. Sein Abschluß wird durch den dritten Dialog berichtet, den man wieder über Next bestätigt.

Schließlich wird nach den Anmeldedaten des ersten Benutzers gefragt. Dieser wird automatisch zum Administrator. Nachdem man Benutzernamen und Passwort eingetragen hat, kann die Installation über die entsprechende Schaltfläche abgeschlossen werden.

Im letzten Dialog war ein roter Textabschnitt zu sehen. Sinngemäß wird dadrin darauf hingewiesen, daß alle Daten, die man ownCloud anvertraut ohne jede Zugangskontrolle abrufbar sind. Darum wird lighttpd (und damit ownCloud) jetzt erstmal runtergefahren:
$ sudo service lighttpd stop

Nun zu Ursache und Beseitigung der Warnung: ownCloud speichert die meisten seiner Daten in einem Unterverzeichnis namens data. Dieses Verzeichnis wird in der Regel über eine Datei namens .htaccess vor direkten Zugriffen aus dem Internet geschützt. Nur indirekt, über die ownCloud-Software und das dort integrierte Rechtemanagement soll der Zugriff erfolgen.

lighttpd bietet aber keine Unterstützung für die Anweisungen in der .htaccess-Datei, darum besteht auch kein Zugriffsschutz. Zwar bietet auch lighttpd ähnliche Mechanismen, aber ich wähle einen anderen Weg.

Als erstes ersetze ich /var/www/owncloud durch /var/www, weil ich keine weitere Anwendung auf dem Raspberry PI laufen lassen werde.
$ sudo mv /var/www /var/www.off
$ sudo mv /var/www.off/owncloud /var/www
$ sudo rm -r /var/www.off

Dann verschiebe ich das data-Verzeichnis aus dem Bereich des Webservers.
$ sudo mkdir -p /srv/owncloud
$ sudo chown www-data:www-data /srv/owncloud
$ sudo mv /var/www/data /srv/owncloud

Den neuen Ort des data-Verzeichnisses müssen wir ownCloud bekannt machen, dazu wird der alte Wert in der Konfigurationsdatei /var/www/config/config.php geändert.

Aus
'datadirectory' => '/var/www/owncloud/data',
wird also
'datadirectory' => '/srv/owncloud/data',

Zeit lighttpd (und damit owncloud) neu zu starten.
$ sudo service lighttpd start

Damit ist die Installation von ownCloud abgeschlossen. Sie steht (nur lt. meinem Beispiel) jetzt direkt unter https://owncloud.dahlen.org/ zur Verfügung.

Im nächsten Teil gehe ich auf die Anbindung von Kontakten und Kalender via iOS und anderen Clients ein.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 2: ownCloud Installation) erschien zuerst auf dahlen.org.

Jetzt habe ich auch endlich eine Verwendung für die Himbeere 3,1415 gefunden: Meine eigene, kleine Cloud – mein Wölkchen also.

Motivation

Zunächst möchte ich noch meine Zielsetzung schärfen: Trotz der Auswahl von ownCloud als Server-Software geht es mir primär nicht um die Einrichtung einer Dateiablage oder ähnlichem. Vielmehr steht der weltweite Zugriff auf Kontakte und Kalenderdaten via Browser oder mobilem Endgerät im Vordergrund. Die dafür notwendigen Protokolle CalDAV und CardDAV sind in ownCloud integriert und die Installation der ownCloud-Software ist um ein Vielfaches einfacher als der dedizierten Varianten (z.B. DaviCAL).

Zwar kann man alle Leistungen kostenlos bei Google bekommen, doch liegen die persönlichen Daten dann eben bei Google. Natürlich muß das nicht zwangsläufig zu Mißbrauch führen (Don’t be evil, sagt Google). Aber ab und an wird Google sicherlich mal einen Blick auf die Daten werden, um die Benutzererfahrung zu verbessern. Anders wären Dienste wie Google Now gar nicht möglich.

Hard- und Software-Basis

Meine Beschreibung orientiert sich dabei an den Möglichkeiten eines Raspberry Pi, Modell B, 256MB Variante. Als Betriebssystem kommt die Debian Wheezy basierte Raspbian-Distribution zum Einsatz. Wegen der begrenzten Ressourcen wird nicht auf das ownCloud-Paket der Distribution zurückgegriffen, da hier eine Abhängigkeit zum Apache 2 http-Server besteht. Stattdessen wird auf LigHTTPd zurückgegriffen:
$ sudo apt-get install lighttpd

Damit ist der Webserver bereits installiert und liefert sein Platzhalter-Seite über HTTP aus. Allerdings handelt es sich um eine unverschlüsselte Verbindung. Die später notwendigen Anmelde-, meine Kontakt- und Kalenderdaten sollen so nicht verschickt werden. Vielmehr muß eine Absicherung über TLS, besser bekannt als SSL.

Absicherung der Kommunikation

Ich will erreichen, daß die Kommunikation mit den Clients (iPhone, Browser, etc.) verschlüsselt abläuft. Dazu würde theoretisch ein einfaches, selbst-signiertes Zertifikat reichen. Allerdings würden dann unbedarfte Anwender mit Dialogen konfrontiert werden, in denen Begriffe wie Gefahr, Sicherheitshinweis und nicht empfohlen vorkommen.

Der Grund ist, daß ein selbst-signiertes Zertifikat zwar für den Aufbau einer verschlüsselten Verbindung ausreicht, aber die Identität des Servers nicht bestätigt. Dies geht nur über eine Zertifikatskette, welche ausschließlich aus dem Client bekannten Certification Authorities (CA) besteht. Das heißt: Eine dem Client bekannte und als vertrauenswürdig eingestufte CA hat die Validität meines Server-Zertifikats mit ihrer Signatur bestätigt.

In meiner Beschreibung verwende ich als Hostnamen owncloud.dahlen.org und einen Benutzer namens cloudmaster. Weder die Domäne, noch der Benutzer existieren in der Realität.

Leider verlangen die im Browser vorinstallierten CAs teilweise horrende Gebühren für ihre Signatur. Doch es gibt kostenlose Ausnahmen, welche für meinen Anwendungsfall auch völlig ausreichend sind. Eine davon ist die Firma StartSSL.

Wichtig: Für die Erstellung eines durch StartSSL-signierten Zertifikats wird die eigene Domäne benötigt (wie dahlen.org). Ohne diese Domäne bleibt euch nur die Möglichkeit eines selbst-signierten Zertifikats. Auch muß der ownCloud-Host über einen Fully Qualified Domain Name (FQDN) erreichbar sein, also über einen Namen wie owncloud.dahlen.org.

Das erforderliche Software (OpenSSL) sollte bereits bei der Installation von Raspian mitgekommen sein, ansonsten schadet eine erneuter Versuch auch nicht.
$ sudo apt-get install openssl

Schlüssel und Zertifikate

Zunächst erstellt man einen privaten Schlüssel, mit welchem das spätere Server-Zertifikat abgesichert ist. Auf die Möglichkeit, diesen private key mit einem weiteren Kennwort abzusichern wird bewußt verzichtet:
$ openssl genrsa -out server.key 2048

Dann erstellt man einen Certificate Signing Request (CSR), eigentlich ist das der öffentliche Teil des privaten Schlüssels, welcher zur Signatur bei der CA eingereicht wird (oder eben selbst signiert wird):
$ openssl req -new -key server.key -out server.csr

Die gestellten Fragen sind gemäß der eigenen Umgebung anzugeben. Wichtig dabei: Das Feld Common Name (CN) muß den Namen und die Domäne (Fully Qualified Domain Name, FQDN) des eigenen ownCloud-Servers beinhalten. Der vollständige Dialog kann also wie folgt aussehen:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:Toenisvorst
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:owncloud.dahlen.org
Email Address []:cloudmaster@dahlen.org

Der erzeugte CSR wird jetzt bei StartSSL zur Signatur eingereicht. Diesen Prozeß muß ich glücklicherweise nicht beschreiben, denn das haben die Kollegen auf heise Security bereits getan. Im Ergebnis wird das signierte Zertifikat angezeigt, welches man kopiert und eine Datei namens server.crt speichert. Es ist dabei enorm wichtig, daß der Inhalt der Datei nicht durch Umbrüche oder ähnliches verändert wird.

Drei Dateien befinden sich nun im aktuellen Verzeichnis:

• server.key – der private Schüssel zum Zertifikat
• server.csr – der öffentliche, unsignierte Schlüssel
• server.crt – das öffentliche, signierte und damit „zertifizierte“ Schlüssel

Der CSR wird nicht mehr benötigt und kann gelöscht werden. Eine weitere Datei muss noch besorgt werden, um die Kette der Zertifikat-Signaturen zu schliessen: Das Intermediate Certificate von StartSSL. Diese lässt sich direkt abrufen:
$ wget -O ca.pem http://www.startssl.com/certs/sub.class1.server.ca.pem

Damit ist die Zertifikatskette geschlossen und die Gültigkeit des eigenen Server-Zertifikats kann überprüft werden:
$ openssl verify -CAfile ca.pem server.crt
Erwartetes Ergebnis:

server.crt: OK

Als letzten Schritt der Zertifikat-Vorbereitung müssen jetzt noch der private Schlüssel und das Zertifikat in eine Datei überführt werden.
$ cat server.key server.crt > server.pem

Installation in lighttpd

Nun ist es Zeit, die generierten Teile der SSL-Infrastruktur dem Webserver bekannt zu machen:
$ sudo cp server.pem /etc/lighttpd/
$ sudo cp ca.pem /etc/lighttpd/

Außerdem muß die Konfiguration unter /etc/lighttpd/lighttpd.conf angepasst werden. Die Änderungen beginnen mit der Änderung der Port-Nummer (ca. ab Zeile 15). Aus
server.port = 80
wird
server.port = 443
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/server.pem"
ssl.ca-file = "/etc/lighttpd/ca.pem"

Letztendlich wird damit der Zugriff über einfaches, unverschlüsseltes HTTP abgeschaltet. Durch einen Neustart wird dies aktiviert:
$ sudo service lighttpd restart

Danach ist der Dienst nur noch über HTTPS auf Port 443 zu erreichen, also https://owncloud.dahlen.org/.

Im nächsten Teil beschreibe ich, wie jetzt ownCloud ins Spiel kommt.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 1: lighttpd und SSL) erschien zuerst auf dahlen.org.