Homelab on SecretMine.de

Planka - leider keine Empfehlung mehr

Mon, 10 Aug 2026 00:00:00 +0000

Ich habe Planka lange gerne eingesetzt. Das hat sich leider geändert, da sich die Entwickler dazu entschlossen haben, Single-Sign-On in die kostenpflichtige Pro-Version zu verschieben und aus der Community-Version zu entfernen. Die Erläuterung der Entwickler lässt sich hier nachlesen: https://github.com/plankanban/planka/issues/1754

SSO ist für mich ein ziemlich grundlegendes Feature, vor allem bei OIDC. Ich kann generell auch verstehen, wenn Entwickler nicht alle Features kostenfrei anbieten möchten, aber ein bereits bestehendes Feature aus der kostenfreien Version zu entfernen bzw. kostenpflichtig zu machen, gefällt mir gar nicht. Außerdem ist SSO bei mir quasi Voraussetzung, vor allem bei den Tools, die meine Partnerin ebenfalls nutzt.

Daher suche ich gerade eine Alternative. Mein Bruder ist mit Vikunja soweit glücklich, das werde ich mir selbst genauer ansehen. Auch gibt es Fork von einer früheren Version von Planka, das steht auch auf der Liste. Eine Migration ist für mich leider nicht so ganz einfach, da ich bspw. mit dem PlankaPrinter die API von Planka nutze, um damit zu interagieren. Nextcloud Deck ist für mich leider keine Alternative, das kann zu wenig.

Es wird ein weiterer Post folgen, wenn ich mich für etwas entschieden habe.

Was hostet man zuhause - und was eher nicht

Fri, 24 Jul 2026 00:00:00 +0000

Selfhosting ist cool, aber nicht automatisch die beste Lösung für alles. Manches ergibt zuhause mehr Sinn, manches ist auf einem vServer im Rechenzentrum besser aufgehoben und anderes würde ich wiederum gar nicht selbst hosten.

Die Möglichkeiten

Zuhause hosten

Zuhause ist oft die beste Wahl für Dienste, bei denen lokale Kontrolle, niedrige Kosten und direkte Datenhoheit wichtiger sind als maximale Verfügbarkeit. Besonders bei speicher- oder rechenintensiven Diensten rechnet sich das Hosten zuhause häufig recht schnell. Das gilt besonders für Dinge, die nur du oder die Familie nutzt und die auch mal einen kurzen Ausfall verkraften können.

Typische Kandidaten sind:

Medienserver wie Jellyfin oder Plex
HomeAssistant und andere Smarthome-Dienste
Wiki, Dokumentenmanagementsystem, Zusatzdienste wie Collabora
Monitoring für das eigene Heimnetz oder das Homelab
Interne Tools, die nur im LAN oder per VPN erreichbar sein müssen.
Gameserver

Kritischere Dienste (wie bei mir bspw. Nextcloud) müssen genauer abgewägt werden. Ich hoste meine Nextcloud zuhause, da der Speicherplatz dadurch deutlich günstiger ist und ich mit Ausfällen häufig leben kann.

Lieber auf einen vServer

Ein vServer lohnt sich vor allem dann, wenn Erreichbarkeit, feste Außenanbindung und sauberer Betrieb wichtiger sind als physische Kontrolle. Das gilt besonders für Dienste, die öffentlich erreichbar sein sollen oder eine bessere Upload-Anbindung brauchen, als sie zuhause realistisch verfügbar ist. Auch für kleine, aber internetnahe Workloads ist ein VPS oft die pragmatischere Lösung.

Gute Kandidaten sind:

Eigene Websites und kleine Webanwendungen
Reverse Proxies für externe Zugriffe
VPN-Endpunkte oder Jumphosts
Chatserver (Matrix)
Mailserver (zumindest Empfangen und Speichern)
Öffentliche APIs, Statusseiten oder kleine SaaS-nahe Dienste
Kleine Gameserver
Voice-Server wie bspw. TeamSpeak3
Single-Sign-On-Lösungen wie Keycloak und Authentik
Kennwortmanager wie Vaultwarden (sofern Ende-zu-Ende-Verschlüsselung vorhanden ist)

Ein vServer ist oft der bessere Kompromiss, wenn du Kontrolle behalten willst, aber nicht die typischen Heimnetzprobleme mit Strom, Router, DynDNS, NAT und Bandbreite haben möchtest. Gerade bei Diensten mit höherer Verfügbarkeit oder mehreren externen Nutzern ist ein VPS meist robuster. Dienste wie Vaultwarden sind hier eine kleine Besonderheit, die würde ich nur dann auf fremder Hardware betreiben, wenn Ende-zu-Ende-Verschlüsselung sauber implementiert ist.

Besser extern nutzen bzw. nicht selbst hosten

Manche Dienste sollte man trotz Selfhosting-Mentalität lieber outsourcen. Das ist kein Eingeständnis von Schwäche, sondern oft die vernünftigste Entscheidung. Besonders dann, wenn Ausfall, Sicherheitsaufwand oder Betriebsrisiko in keinem guten Verhältnis zum Nutzen stehen.

Typische Beispiele sind:

E-Mail, wenn man keine Lust hat, sich selbst um Whitelisting und generelle Zustellungsprobleme zu kümmern (zumindest ausgehendes SMTP)
Backups, zumindest von den kritischen Daten

Gerade E-Mail hat sich mit der Zeit leider zu etwas entwickelt, was man lieber von anderen machen lässt. Einen eigenen Mailserver kann man weiterhin betreiben, ich würde aber zumindest den ausgehenden Mailserver über ein externes Relay schicken.

Fazit

Für mich lässt sich anhand weniger Fragen entscheiden, ob bzw. wie ich Dienste selbst betreiben möchte:

Welche Anforderungen habe ich an die Verfügbarkeit?
Wie hoch ist der Ressourcenbedarf?
Was kostet externes Hosting?
Wie viel Aufwand ist der Betrieb?

Damit kann ich eigentlich immer eine gute Entscheidung treffen, wo ich Services betreiben möchte.

Mehr VRAM bei NVIDIA-GPUs (Workstation/Server) nutzbar machen

Sun, 14 Jun 2026 00:00:00 +0000

Ich habe nun seit einiger Zeit eine Nvidia Tesla P4. Diese hat 8 GB VRAM.

Mir war schon mehrfach aufgefallen, dass ich nur ca 7,5 GB davon nutzen konnte, habe das ganze aber einfach auf die üblichen Umrechnungsfaktoren geschoben.

Gestern habe ich dann einmal genauer hingesehen.

ECC bei GPUs

Nicht nur für den normalen Systemspeicher, sondern auch bei GPUs gibt es ECC (Fehlererkennung und -korrektur für Speicher). Das ist bei den Teslas standardmäßig aktiv, da diese Karten ja für professionelle Nutzung gedacht sind. Dadurch wird allerdings ein Teil des GPU-Speichers für die dafür notwendigen Informationen reserviert, auch die GPU-Leistung sinkt dadurch minimal (das Internet redet von grob 10 %, getestet habe ich es selbst nicht).

Das ist für maximale Verfügbarkeit und Verhinderung von Fehlern natürlich sinnvoll, für Zuhause und generell unkritische Anwendungen aber nicht notwendig.

ECC deaktivieren

Nach Installation des Treibers steht das Tool nvidia-smi für Monitoring und Konfiguration der GPU zur Verfügung. Darüber lässt sich auch ECC konfigurieren.

Status auslesen:

nvidia-smi -q

1
2
3
4
5
6
7
8
9


Attached GPUs : 1
GPU 00000000:01:00.0
 Product Name : Tesla P4
 Product Brand : Tesla
 Product Architecture : Pascal
[...]
 ECC Mode
 Current : Enabled
 Pending : Enabled

Der ECC-Modus lässt sich nun einfach mittels nvidia-smi --ecc-config=0 deaktivieren.

Nach einem Reboot waren bei mir damit statt vorher 7680 MiB die vollen 8192 MiB verfügbar. Das ist kein riesiger Unterschied, aber reduziert bei größeren Modellen den Anteil, der auf der CPU laufen muss.

Firefly III - Self-Hosted und Open Source Haushaltsbuch

Sat, 06 Jun 2026 00:00:00 +0000

Firefly III ist ein Open-Source Tool zur Verwaltung persönlicher Finanzen. Es eignet sich ideal als Haushaltsbuch für den privaten Einsatz oder geteilte Konten in der Familie (oder für Paare) und bietet detaillierte Berichte für einen klaren Überblick.

Warum überhaupt so ein Tool?

Vorher fand das ganze in einer Excel-Tabelle statt, die wurde aber mit der Zeit immer komplexer. Deshalb habe ich mir eine Software dafür gesucht.

Voraussetzung war aufgrund der Sensibilität ganz klar, dass ich es selbst betreiben können muss. Außerdem wollte ich ein verbreitetes System haben, wofür es auch schon Apps und ähnliches gibt. Gute Auswertungsmöglichkeiten waren mir auch wichtig.

Firefly III ist eher auf Niveau einer Buchhaltungssoftware als ein Haushaltsbuch. Es gibt auch einfachere Tools wie beispielsweise Actual Budget. Alternativen hatten für mich aber zu wenig Features.

Installation und Betrieb

Wie bei den meisten Dingen gibt es auch hierfür fertige Docker-Container, man findet auch offizielle Compose-Vorlagen. Der Stack besteht dabei aus der Anwendung, einer Datenbank (MariaDB) sowie einem Cron-Container. Von der Ressourcenauslastung her ist es eher auf der schlankeren Seite, also mehr als vertretbar.

Bedienung

Durch die Komplexität bzw. den Featureumfang ist Firefly anfangs etwas gewöhnungsbedürftig. Grundsätzlich bedient es sich aber ziemlich gut - Bestandskonten anlegen, danach kann man schon mit dem Anlegen von Transaktionen anfangen. Das lässt sich in Kategorien einteilen, Tags zuweisen und auch Budgets z.B. pro Monat definieren. Ich selbst nutze Firefly III nun seit 3 Jahren aktiv, dabei gemischt zwischen Rechner und Handy (via Waterfly III für mich und Abacus für die gemeinsamen Finanzen). Mittlerweile ist auch meine Partnerin von einer simplen Excel-Tabelle auf Firefly umgestiegen.

Die Auswertungen gefallen mir sehr gut, ich kriege schnell einen guten Überblick darüber, wie der aktuelle Monat im Vergleich zu anderen dasteht und wohin das Geld geflossen ist. Über die Daueraufträge habe ich alle regelmäßigen Buchungen abgedeckt, was den Aufwand deutlich reduziert. Mit den Regeln lassen sich zusätzlich auch Kategorien, Tags und noch mehr automatisch anhand beispielsweise des Buchungstitels festlegen. So landen bei den gemeinsamen Finanzen alle Buchungen, die <Laden> Lebensmittel als Titel haben, automatisch in der entsprechenden Kategorie und werden dem passenden Budget zugeordnet.

Die UI ist nichts besonderes, erfüllt aber auf verschiedenen Bildschirmgrößen gut ihren Zweck.

Fazit

Firefly III gehört für meine Partnerin und mich zu den zentralen Anwendungen, die am meisten verwendet werden. Wir nutzen es dabei fast täglich.

Matrix selbst hosten - Synapse, Element und warum das mehr als nur ein Messenger ist

Fri, 29 May 2026 00:00:00 +0000

Messenger gibt es viele. Matrix ist dabei eine Besonderheit, da es nicht direkt eine App meint, sondern ein offenes Protokoll für dezentrale Echtzeitkommunikation, auf dem verschiedene Clients und Server miteinander sprechen können.

Was ist Matrix?

Matrix ist ein offenes, föderiertes Kommunikationsprotokoll für Chat, Gruppenräume, Sprach- und Videokommunikation. Synapse ist dabei der klassische Matrix-Homeserver, also die Server-Software, die das eigenes Matrix-System betreibt.

Als Client wird sehr häufig Element genutzt, weil es auf Desktop und Mobilgeräten breit verfügbar ist und den größten Teil der üblichen Messenger-Funktionen abdeckt und sich wie andere bekannte Messenger anfühlt. Es gibt auch diverse andere Clients wie z.B. Cinny, was von der UI her näher an Discord ist.

Der größte Unterschied zu klassischen Messengern ist die Dezentralität. Man ist nicht an einen einzigen Anbieter gebunden, sondern kann mit anderen Matrix-Servern kommunizieren, ähnlich wie beispielsweise auch E-Mail über viele Anbieter hinweg funktioniert.

Dazu kommt die offene Architektur: Der Server ist selbst hostbar und man kann den Client frei wählen. Das macht Matrix auch nicht nur für die private Kommunikation interessant, auch in Unternehmen und co bietet sich die Nutzung an. Dort kann man beispielsweise auch die Förderation für rein interne Kommunikation deaktivieren.

Aber: Durch die Architektur und auch die Ende-zu-Ende-Verschlüsselung ist Matrix komplizierter in der Einrichtung, was schnell abschreckend wirkt.

Politischer Kontext

Ja, ein Thema was ich sonst nicht betrachte. Finde ich hier aber erwähnenswert.

Matrix passt ziemlich gut in die aktuelle Diskussion um digitale Souveränität, Datenschutz und unabhängige (Kommunikations-)Infrastruktur. Gerade in Europa und auch in Deutschland ist das Interesse an offenen Alternativen zu großen Plattformen seit Jahren hoch und auch diverse öffentliche Einrichtungen und Hochschulen nutzen Matrix als sicheren Messenger.

Installation

Ein alltagstaugliches Matrix-Setup besteht aus mehreren Komponenten:

Synapse als Homeserver (es gibt auch andere, aber Synapse ist der gängigste)
Element als Frontend im Browser
Synapse-Admin zur Benutzerverwaltung

Von der Domaingestaltung habe ich bei mir etwa folgendes Setup:

Synapse unter matrix.example.com
Element unter chat.example.com
Wobei example.com als Basis-URL für die Identitäten dient, das wird über eine .well-known an die Subdomain matrix.example.com delegiert

Die Delegation hat den großen Vorteil, dass die Hauptdomain als Matrix-Adresse genutzt werden kann, aber nicht von Synapse belegt wird. Über eine kleine “Hinweis-Datei” auf der Hauptdomain wissen Clients (und andere Homeserver) dann, dass diese sich zu matrix.example.com verbinden müssen.

In diesem Fall wird Synapse mit sqlite installiert. Für kleine Setups ist das vollkommen in Ordnung, ich selbst nutze Postgres als Datenbank.

Docker

Wie das meiste betreibe ich Matrix in Docker. Meine Compose (10.0.0.2 ist die interne IP dieses Servers):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


services:
 synapse:
 image: docker.io/matrixdotorg/synapse:latest
 restart: unless-stopped
 environment:
 - SYNAPSE_CONFIG_PATH=/data/homeserver.yaml
 volumes:
 - ./data:/data
 ports:
 - 10.0.0.2:8008:8008
 element:
 image: vectorim/element-web:latest
 restart: unless-stopped
 volumes:
 - ./config/element-config.json:/app/config.json
 ports:
 - 10.0.0.2:8009:80
 synapse-admin:
 image: ghcr.io/etkecc/synapse-admin:latest
 restart: unless-stopped
 volumes:
 - ./config/synapse-admin-config.json:/app/config.json
 ports:
 - 10.0.0.2:8010:8080

Die grundlegende Konfiguration für Synapse lässt sich generieren:

1

docker compose run --rm -e SYNAPSE_SERVER_NAME=example.com synapse generate

Die relevanten Config-Files:

Element (config/element-config.json):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
 "default_server_config": {
 "m.homeserver": {
 "base_url": "https://matrix.example.com"
 }
 },
 "disable_custom_urls": true,
 "disable_guests": true,
 "brand": "Mein Chatserver"
}

Synapse-Admin (config/synapse-admin-config.json):

1
2
3
4
5


{
 "restrictBaseUrl": [
 "https://matrix.example.com"
 ]
}

Die eigentliche Config von Synapse (data/homeserver.yaml) habe ich minimal modifiziert:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


# Configuration file for Synapse.
#
# This is a YAML file: see [1] for a quick introduction. Note in particular
# that *indentation is important*: all the elements of a list or dictionary
# should have the same indentation.
#
# [1] https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html
#
# For more information on how to configure Synapse, including a complete accounting of
# each option, go to docs/usage/configuration/config_documentation.md or
# https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html
server_name: "example.com"
pid_file: /data/homeserver.pid
listeners:
 - port: 8008
 resources:
 - compress: false
 names:
 - client
 - federation
 tls: false
 type: http
 x_forwarded: true

database:
 name: sqlite3
 args:
 database: /data/homeserver.db

log_config: "/data/example.com.log.config"
media_store_path: /data/media_store
registration_shared_secret: "[...]"
macaroon_secret_key: "[...]"
form_secret: "[...]"
signing_key_path: "/data/example.com.signing.key"
trusted_key_servers:
 - server_name: "matrix.org"


# Modifikationen
public_baseurl : "https://matrix.example.com" # URL, über die Synapse von außen erreichbar ist
report_stats: false
enable_registration: false

Reverse-Proxy

Ich habe Caddy als Reverse-Proxy im Einsatz. Die relevante Konfiguration in der Caddyfile sieht bei mir so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


matrix.example.com {
 reverse_proxy 10.0.0.2:8008
}

chat.example.com {
 reverse_proxy 10.0.0.2:8009
}

synapse-admin.example.com {
 # siehe https://caddyserver.com/docs/caddyfile/directives/basic_auth
 basic_auth {
 # User hier
 }
 reverse_proxy 10.0.0.2:8010
}

Synapse-Admin habe ich hinter Basic-Auth versteckt. Das ist an sich meiner Meinung nach nicht notwendig, aber fühlt sich besser an.

Delegation einrichten

Bei der Hauptdomain example.com müssen einige Dateien angelegt werden.

.well-known/matrix/server:

1
2
3


{
 "m.server": "matrix.example.com:443"
}

.well-known/matrix/client:

1
2
3
4
5


{
 "m.homeserver": {
 "base_url": "https://matrix.example.com"
 }
}

Damit sollte nun Förderation auch funktionieren. Mit dem Federation Tester (federationtester.matrix.org) lässt sich das prüfen.

Initialen User erstellen

Mittels

1

docker compose exec -it synapse register_new_matrix_user http://localhost:8008 -c /data/homeserver.yaml

lässt sich nun der initiale Admin-User (und auch weitere User natürlich) anlegen.

Clients einrichten

An den Clients sollte ein Login auf example.com nun funktionieren. Durch die Delegation werden Clients zu matrix.example.com weitergeschickt.

Verteilter Speicher im Homelab

Sun, 17 May 2026 00:00:00 +0000

Ich habe bekanntlich seit einiger Zeit Docker Swarm im Einsatz. Als Storage war anfangs ein mit NFS geteiltes DRBD-Volume im Einsatz, also replizierter Blockspeicher. Funktioniert hat das, war aber langsam.

Daher habe ich mir diverse Lösungen für verteilten bzw. replizierten Speicher angesehen und ausprobiert. Ziel war einerseits, replizierten und ausfallsicheren Storage für Docker Swarm zu bekommen, andererseits aber auch, einen größeren Speicherbereich für unwichtige Daten zu erhalten.

Anforderungen

Um eine vernünftige Auswahl treffen zu können, sollten vorher natürlich die konkreten Anforderungen klar sein.

Muss:

Unterstützung von verteiltem und repliziertem Storage
Hochverfügbarkeit (weiterhin funktionsfähig bei Ausfall von 1/3 Nodes)
Kostenfrei nutzbar
(halbwegs) aktives Projekt, nicht abgekündigt bzw. sichtbar inaktiv

Soll:

Open Source

Kann:

Metriken/Monitoring

Softwarelösungen

Ceph

Ceph ist eine gängige Lösung für hochverfügbaren Speicher und wird im sehr großen Stil eingesetzt. Es ist zudem in Proxmox VE integriert, womit sich schnell ein hyperconverged Cluster einrichten lässt.

Die Performance hat mir sehr gut gefallen, es war die schnellste getestete Lösung. Ceph lässt sich auch super konfigurieren und Pools mit verschiedenen Replikationsregeln erstellen. Der Ausfall einer Node wurde gut verkraftet, nach dem Hinzufügen war die Redundanz auch sehr schnell wiederhergestellt.

Problematisch für mich ist hier allerdings der Ressourcenbedarf. Ceph hat mit allen Komponenten pro Node 2-3 GB an RAM verbraucht, das ist mir mit den Thin Clients zu viel. Außerdem ist Ceph bekannt dafür, eine hohe Schreiblast auf den Datenträgern zu erzeugen. Auf Dauer könnte Ceph aber trotzdem die präferierte Lösung sein.

GlusterFS

Im Vergleich zu Ceph arbeitet GlusterFS auf Datei- und nicht auf Blockebene. Replizierte und verteilte Volumes werden unterstützt, auch erasure-code-basierte Volumes sind möglich. Es ist trotzdem weniger flexibel als Ceph, was die Replikationsoptionen angeht. Monitoring ist leider auch eher schwierig, es gibt aber einen halbwegs gepflegten Prometheus-Exporter.

GlusterFS wurde irgendwann von Red Hat gekauft, die es dann neben der Open-Source-Version als Red Hat Gluster Storage vermarktet haben. Das Red Hat Produkt hat allerdings Ende 2024 das Ende seines Lebenszyklus erreicht. Die Aktivität bei Github ist in den letzten Jahren auch stark gesunken, letztes Jahr waren es ~20 Commits im Repo. Das spricht deutlich gegen GlusterFS.

Vom Ressourcenbedarf her ist es angenehm, ich sehe kaum nennenswerten RAM- und CPU-Bedarf. Die Performance ist insgesamt auch okay, wenn auch geringer als bei Ceph.

MooseFS

Vom Prinzip her gefällt mir MooseFS. Man kann pro Verzeichnis die Anzahl der Kopien festlegen, beim über- oder unterschreiten durch Entfernen bzw. Hinzufügen von Volumes wird dann automatisch nachgesteuert. Die Performance ist ebenfalls in Ordnung, auch wenn es primär für Medien und andere größere Dateien ausgelegt ist. Bei vielen kleinen Dateien habe ich - zumindest bei den Forks von MooseFS - deutlich geringere Performance als bei Ceph gesehen.

Das Ausschlusskriterium für MooseFS war allerdings die fehlende Hochverfügbarkeit in der Open-Source-Version. Für dieses Feature benötigt man eine Pro-Lizenz.

LizardFS

Das ist ein Fork von MooseFS, der von den Funktionen her ziemlich gleich ist, allerdings auch Hochverfügbarkeit enthält. LizardFS wird allerdings seit mehreren Jahren nicht mehr weiterentwickelt, das Repo bei Github ist inaktiv.

LeilFS (vorher SaunaFS)

LeilFS ist ein Fork von LizardFS, laut den Infos, die ich finden konnte, sind wohl diverse Entwickler von LizardFS dort nun aktiv. Prinzipiell sieht LeilFS gut aus, es gibt bisher allerdings nur für Ubuntu fertige Pakete. Ich habe aber mit wenig Aufwand Pakete für Debian 13 kompilieren können.

Die Dokumentation lässt (zumindest bisher) auch sehr zu wünschen übrig. Das meiste habe ich mir bei LizardFS angesehen und nur die entsprechenden Bezeichnungen angepasst. Trotzdem hinterlässt das einen etwas faden Beigeschmack.

Dennoch ist es eine flexible und eher ressourcensparsame Option.

Weitere Lösungen

Folgende Möglichkeiten möchte ich zumindest erwähnt haben, auch wenn ich nicht im Detail darauf eingehen werde:

LINSTOR: Verteilte Block-Devices, basiert auf DRBD
S3 plus JuiceFS: Mit hochverfügbarem S3 in Verbindung mit JuiceFS lässt sich theoretisch auch ein hochverfügbares Dateisystem aufsetzen
DRBD plus NFS: Etwas klassischer, aber funktioniert
ZFS mit Replikation: Proxmox bietet Unterstützung dafür. Nicht direkt volles HA, aber für Homelab und kleine Produktion wahrscheinlich ausreichend

Fazit

Ceph ist eine gebräuchliche Lösung, weit verbreitet, aktiv gepflegt und auch schnell. Also eigentlich ideal. Es benötigt aber leider zu viele Ressourcen, ist also bei den aktuellen RAM-Preise eher eine Lösung für “irgendwann”.

Aktuell wird jetzt DRBD erst einmal durch GlusterFS ersetzt. Ich habe damit in der Vergangenheit viel zu tun gehabt und kenne mich weit genug aus, auch wenn es seine Nachteile hat. Regelmäßige Sicherungen mache ich natürlich, daher halte ich das Risiko für Datenverlust für überschaubar.

Für Massenspeicher kommt neben GlusterFS auch LeilFS zum Einsatz, da liegen z.B. ISOs/Templates für Proxmox, Medien und anderer Kram darauf. Ich habe mir verschiedene Storage-Klassen konfiguriert, die teilweise auch hochverfügbar sind. Dazu aber in einem weiteren Beitrag mehr.

GlusterFS ist für mich trotzdem nur eine Zwischenlösung, auf Dauer bleibt Ceph (inkl. CephFS) das Ziel. Einfach weil es verbreiteter und besser gepflegt ist. Aber das wird auf niedrigere RAM-Preise warten müssen.

Hochverfügbarkeit mit Keepalived

Sun, 03 May 2026 00:00:00 +0000

Wer schon einmal mit mehreren Servern gearbeitet hat, kennt das Problem: Ein Dienst soll zwecks Ausfallsicherheit auf mehreren Servern laufen und parallel unter einer festen IP erreichbar sein. Natürlich mit Failover.

An dieser Stelle kommt Keepalived ins Spiel. Das kleine, aber mächtige Tool übernimmt die Verwaltung von Floating IPs (oder Virtual IPs, kurz VIPs) und sorgt so für Hochverfügbarkeit für theoretisch beliebige Dienste.

Wie funktioniert das?

Keepalived setzt auf das VRRP-Protokoll (Virtual Router Redundancy Protocol), um eine virtuelle IP-Adresse an genau einen Master-Knoten zu vergeben.

Wenn der Master ausfällt, erkennt Keepalived das automatisch und weist die IP einem Backup-Knoten zu. Meistens passiert das innerhalb von wenigen Sekunden. Dienste hinter dieser IP bleiben dadurch durchgängig erreichbar.

Typische Szenarien

DNS

Ein Klassiker. DNS hat zwar an sich durch die Angabe mehrerer DNS-Server schon auf der Ebene Ausfallsicherheit integriert, hier lässt sich aber auch Keepalived gut einsetzen. Zwei (oder mehr) Server sind dabei identisch eingerichtet und können beide jederzeit DNS-Anfragen beantworten.

Keepalived sorgt hier nun für eine virtuelle IP, die immer auf einen der beiden Server gebunden ist und damit beim Ausfall des aktuell aktiven Servers innerhalb von kurzer Zeit auf den zweiten umgeschaltet wird.

Webserver

Eigentlich exakt das selbe Prinzip wie bei DNS, hier müssen nur die Website-Daten auch auf einem gemeinsamen Storage liegen oder anderweitig allen Nodes bekannt sein.

Keepalived und Docker Swarm

Hier wirds cool.

Swarm hat Mesh Routing. Das heißt, dass jede Node Anfragen zu einem Service entgegen nehmen kann und intern dann zum richtigen Knoten weiterleitet. Heißt, es ist egal, welche Node man anspricht, die Antwort kommt auf jeden Fall.

In Verbindung mit Keepalived kann man so Services in Docker Swarm wirklich hochverfügbar machen. Die virtuelle IP zeigt immer auf einen der Knoten, das interne Mesh-Routing erledigt dann den Rest. Wenn ein Knoten ausfällt, wird die IP umgeschaltet, parallel sorgt Swarm dafür, dass alle Services weiterhin verfügbar sind und bei Bedarf auf einem anderen Knoten neu gestartet werden.

DNS-Einträge können damit immer auf die virtuelle IP eingestellt werden, alles weitere passiert automatisch.

Beispielkonfiguration

Hier eine kurze Beispielconfig:

Node swarm-1:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


global_defs {
 router_id swarm-1
}

vrrp_instance VI_SWARM {
 state MASTER
 interface eth0
 virtual_router_id 60
 priority 255
 advert_int 1
 authentication {
 auth_type PASS
 auth_pass meinsicherespw
 }
 virtual_ipaddress {
 192.168.1.60/24
 }
}

Node swarm-2:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


global_defs {
 router_id swarm-2
}

vrrp_instance VI_SWARM {
 state BACKUP
 interface eth0
 virtual_router_id 60
 priority 254
 advert_int 1
 authentication {
 auth_type PASS
 auth_pass meinsicherespw
 }
 virtual_ipaddress {
 192.168.1.60/24
 }
}

Die router_id ist hierbei immer Node-spezifisch. Die virtual_router_id ist letztendlich die Instanzkennung. Bei mir ist swarm-1 normalerweise der Master, hier ist durch die höhere Priorität auch ein Fail-Back (also das Zurückschalten von einer der anderen Nodes zurück zu swarm-1) konfiguriert. Wenn die Prioritäten identisch sind, passiert kein Fail-Back.

Die restlichen Optionen sind weitestgehend selbsterklärend, ansonsten findet man im Internet auch genügend Informationen zu Keepalived.

Kubernetes

Bei Kubernetes lässt sich dieses Konstrukt mit MetalLB im Layer-2-Modus ziemlich identisch umsetzen. Die Erkennung von ausgefallenen Nodes läuft etwas anders, aber das Endergebnis (virtuelle IP, unter der immer eine Node erreichbar ist) ist das selbe.

Fazit

Mir gefällt das Setup in dieser Kombination wirklich gut. Swarm kümmert sich um die Services, Keepalived sorgt für eine einheitliche IP für alle Services. Und dabei braucht Keepalived auch fast nichts an Ressourcen.

Latenzmessungen mit Smokeping

Sat, 18 Apr 2026 00:00:00 +0000

Ich nutze nun schon seit vielen Jahren Smokeping zur Überwachung von Latenzen zu diversen Zielen. Primär mit dem Ziel, die Performance meiner Internetanbindung zu überwachen und Probleme gut identifizieren zu können, daneben aber auch, um Änderungen am Routing zwischen meinem Internetprovider und dem entsprechenden Ziel anhand von Latenzänderungen zu erkennen.

Das Tool ist an sich recht alt, bietet aber trotzdem einen super Einblick in die Latenzen.

Ping-Ziele

Neben meinem Router (und dem Router im Keller im zweiten Homelab) pinge ich regelmäßig diverse Ziele im Internet. Dazu gehören neben den DNS-Servern von Google, Cloudflare und Quad9 auch die Test-Targets von Hetzner an allen derer Standorte, alle meine eigenen Server auch das VPN-Gateway meines Arbeitgebers.

Konfiguration

Die gesamte Konfiguration liegt unter /etc/smokeping/, wenn Smokeping einfach als Systempaket installiert wurde. In der Datei /etc/smokeping/config.d/Targets lassen sich die Ziele definieren, die Syntax ist dabei recht einfach. Hier ein Auszug aus meiner Config:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


+ Local
menu = Local
title = Local Network

++ Gateway
menu = Gateway
title = Gateway
host = 192.168.1.1

+ Internet
menu = Internet
title = Internet

++ GoogleDNS1
menu = Google DNS
title = Google DNS
host = 8.8.8.8

++ CloudflareDNS
menu = Cloudflare DNS
title = Cloudflare DNS
host = 1.1.1.1

++ Quad9DNS
menu = Quad9 DNS
title = Quad9 DNS
host = 9.9.9.9

Viel mehr außer die Targets habe ich nicht modifiziert, es lassen sich aber viel mehr Dinge noch konfigurieren.

Statistiken

Hier ein Beispiel von einem Ping-Ziel. Die Daten gehen dabei über ein Jahr zurück. Bei den längeren Statistiken sieht man hier und da ein bisschen Packetloss, das kann bei größeren Downloads bzw. generell Auslastung der Internetleitung zwischenzeitlich passieren.

Schön zu sehen ist auch ein genereller Internetausfall im Juni für mehrere Tage mit Fallback zu LTE.

Alternativen zu Smokeping

Als Alternativen zu Smokeping für Latenz-, Jitter- und Packetloss-Monitoring bietet sich Uptime Kuma oder der Blackbox Exporter an.

Uptime Kuma ist ein selfhostbares Tool mit simplem Docker-Setup, das Ping-Monitoring inklusive Latenz, Packetloss und Up/Down-Status bietet – ergänzt durch schöne Dashboards, Status-Seiten und Notifications via Discord oder diverser anderer Kanäle. Jitter ist hier zwar nicht so detailliert wie bei Smokeping, aber die moderne Web-UI ist mobilfreundlich und ideal für Homelabs, wo man schnell loslegen will, ohne viel Konfigurationsaufwand. Uptime Kuma ist generell ein schönes Monitoring-Tool, mit dem man seine selbst betriebenen (oder auch externe) Dienste überwachen kann.

Wenn man eh schon den klassischen Metriken-Stack mit Prometheus und Grafana hat, ist der Blackbox Exporter einen Blick wert. Der kann neben ICMP auch diverse andere Messungen bzw. Tests ausführen und Ziele überwachen. Durch die Nutzung von Grafana sind deutlich umfangreichere Visualisierungen möglich, auch mehrere Probe-Quellen sind gut umzusetzen. Der initiale Aufwand ist natürlich höher als bei Smokeping oder Uptime Kuma, aber der Blackbox Exporter skaliert deutlich weiter und kann am Ende mehr.

Fazit

Obwohl die Software eher alt ist und visuell auch nicht die schönste ist, ist es trotzdem ein zentrales Tool in meinem Netzwerkmonitoring. Und das seit bald 10 Jahren. Das Tool funktioniert einfach, ist wartungsarm und liefert gute (wenn auch alt aussehende) Graphen. Daher wird es bei mir auch nicht in absehbarer Zeit abgelöst.

Nvidia Tesla P4

Fri, 10 Apr 2026 00:00:00 +0000

Ich experimentiere schon lange mit Ollama als Hosting-Plattform für LLMs. Bisher hatte ich dafür eine alte Nvidia GTX 1050 Ti mit 4GB, das reicht aber nur für kleine Modelle.

Auswahl einer GPU

Mein Ziel war wie üblich eine gute Kombination aus Preis, Leistung und Stromverbrauch. Gebrauchte Datacenter-GPUs aus der Pascal-Reihe waren hierbei am interessantesten, da diese alt genug sind um im Preis deutlich gefallen zu sein und trotzdem CUDA-Versionen unterstützen, die aktuell genug sind, um eine gute Softwareunterstützung zu haben. 8GB VRAM waren mein Minimum, da sich damit schon viele der kleineren Modelle vollständig auf der GPU und viele mittlere Modelle zumindest zu einem guten Teil auf der GPU ausführen.

Die Tesla P4 und die Tesla P40 fand ich hierbei am interessantesten. Die P40 hat 24GB VRAM, die P4 hat 8GB. Auch in der Rechenleistung unterscheiden sich die beiden Karten nennenswert. Da ich großen Wert auf einen niedrigen Energieverbrauch lege, habe ich mich für die Tesla P4 entschieden.

Bestellt habe ich eine gebrauchte Datacenter-Karte, diese kam dann auch nach kurzer Zeit an.

Kühlung

Es handelt sich bei der Tesla P4 um eine Karte, die für den Einsatz in Servern gebaut ist. Daher hat diese keine eigenen Lüfter, sondern ist auf Airflow vom Gehäuse angewiesen.

Da ich die GPU allerdings nicht in einem klassischen Server, sondern in einem Desktop-Case verwenden möchte, musste ich hier etwas kreativ werden. Es gibt Adapter als 3D-Modell, mit denen man einen 40mm- bzw. 80mm-Lüfter für den Luftstrom durch die GPU nutzen kann. Das habe ich ausprobiert, allerdings habe ich keine passenden Lüfter, die mit dem Luftwiderstand vernünftig zurecht kommen.

Daher wurde es eine etwas andere Lösung. Ich habe einfach zwei 40mm-Lüfter mit Kabelbindern auf der GPU platziert, vorher habe ich die Abdeckung entfernt und damit die Kühlrippen offengelegt. Das funktioniert tatsächlich brauchbar.

Ich hatte temporär einen 120mm-Lüfter ausprobiert, der hatte noch eine bessere Kühlleistung, passte aber natürlich nicht ins Gehäuse.

Von daher bleibt es bis auf Weiteres bei 2x 40mm-Lüftern für die GPU.

Performance

Im Vergleich zur GTX 1050 Ti merkt man den doppelten VRAM schon deutlich.

Die Performance gefällt mir soweit, auch wenn die Geschwindigkeit natürlich deutlich abfällt, sobald das Modell nicht mehr vollständig in den VRAM der GPU passt. Ich benutze weiterhin Ollama als Runtime, da ich nach Tests mit anderen Runtimes wie llama.cpp die Benutzerfreundlichkeit von Ollama bevorzuge.

Weitere Anwendungsfälle

Die P4 hat auch einen Hardware-Encoder für H.264 und H.265, damit kann ich auch gut altes Videomaterial (z.B. Aufnahmen von Spielen) gut komprimieren. Das geht aber mit der GTX 1050 Ti genauso gut, da der Hardware-Encoder am Ende der selbe ist.

Fazit

Für die Nutzung mit Ollama ist die P4 brauchbar, die 8GB VRAM schränken allerdings spürbar ein. Trotzdem bereue ich den Kauf nicht und bin zufrieden, ich war mir dieser Einschränkungen von vornherein bewusst.

Memos - Notizen und Tagebuch

Sat, 04 Apr 2026 00:00:00 +0000

Ich nutze nun seit über zwei Jahren Memos (https://usememos.com/) als Tool im Homelab. Es dient mir zum Notieren von Gedanken und Ideen, zusätzlich nutze ich es auch als eine Art unregelmäßig gepflegtes Tagebuch. Alles wird lokal gespeichert, es ist schlicht, braucht wenig Ressourcen und “just works” - perfekt, um mal eben etwas zu notieren.

Deployment

1
2
3
4
5
6
7


services:
 memos:
 image: neosmemo/memos:stable
 ports:
 - 5230:5230
 volumes:
 - ./data/:/var/opt/memos/

… ja, das wars schon. Davor sitzt dann noch Caddy als Reverse-Proxy, um SSL zu machen und das ganze erreichbar zu bekommen. In Caddy ist auch noch eine zusätzliche Authentifizierungsschicht eingebaut, dazu schreibe ich irgendwann noch mal mehr.

Nutzung im Alltag

Ich habe Memos als Lesezeichen auf dem Rechner, auf dem Handy ist es als PWA installiert. Damit habe ich es immer griffbereit, um mir schnell etwas zu notieren und es später auch wiederzufinden. Dazu sind die Tags super hilfreich, damit kann man die Memos schön organisieren. Anhänge wie Bilder sind auch vorgesehen, diese lassen sich lokal, in der Datenbank oder in einem S3-Bucket speichern. Ich nutze dabei die lokale Option, das reicht vollkommen aus. Standardmäßig kommt Memos mit SQLite als Datenbank. Hier werden aber auch andere Datenbanktypen unterstützt.

Zur Formatierung ist Markdown vorgesehen, das mag ich generell. Markdown ist für mich ein guter Mittelweg zwischen reinen Textdateien und erweiterten Formaten wie AsciiDoc oder LaTeX, kann aber trotzdem für das allermeiste genug.

Auch die gemeinsame Nutzung ist vorgesehen - dafür gibt es mehrere Sichtbarkeitsstufen für einzelne Einträge. Private ist nur für den Ersteller sichtbar, Protected können angemeldete Benutzer sehen und Public ist öffentlich. Gruppen oder ähnliches sind nicht vorgesehen, das fehlt mir allerdings auch nicht.

Fazit

Mir gefällt Memos und ich nutze es im Alltag regelmäßig. Daher fand ich einen Post nach all der Zeit angemessen, vor allem, da es ein eher wenig bekanntes Open-Source-Produkt ist. Als Wiki-Lösung nutze ich allerdings zusätzlich noch eine andere Software, dazu folgt wahrscheinlich auch mal ein Beitrag.

HP T430 - ThinPro 9 vs. Windows

Tue, 31 Mar 2026 00:00:00 +0000

Ich habe nun seit einen HP T430 Thin Client, den ich im Vergleich zu meinen ganzen anderen Thin Clients auch tatsächlich so benutze, wie es vorgesehen ist.

Zumindest größtenteils.

Wie man Updates für einen Thin Client bekommt

Für HP-Thin-Clients gibt es das Tool HP ThinUpdate, mit dem man Images für Thin Clients herunterladen und einen USB-Stick vorbereiten kann. Von dem Stick bootet man den Thin Client dann und kann das Image einspielen.

Randnotiz: Mit einem IODD-Gerät lässt sich ein USB-Laufwerk emulieren. ThinUpdate weigert sich zwar, das virtuelle Laufwerk als Ziel auszuwählen, man kann aber den Boot-Stick einmal so erstellen (einen normalen Stick nehmen und dann die Daten übertragen) und einzelne Images einfach als Datei übertragen.

HP ThinPro 8

Bisher war HP ThinPro 8 das neuste OS für diesen Client. Das ist ein für Thin-Clients entwickeltes OS auf Linux-Basis, was abgesehen von Remote-Verbindungen diverser Art (RDP, Citrix, Omnissa Horizon und co) nicht viel kann.

Das hat soweit auch funktioniert, war mir vom Booten her aber eher zu langsam und RDP war auch nicht komplett flüssig - das bin ich vom normalen Microsoft-Client aus anders gewohnt.

(Ich habe nur für dieses Bild ThinPro 8 noch mal auf dem Thin Client installiert…)

HP ThinPro 9

Seit Anfang des Jahres gibt es nun ThinPro 9, was das ganze modernisiert. Die Features sehen grob gleich aus, aus meiner Sicht ist vor allem die Oberfläche etwas moderner. Die installierte Version vom RDP-Client ist neuer, trotzdem ist die Performance verbesserungswürdig.

Windows 10

Als Alternative wollte ich Windows 10 testen, Windows 11 braucht noch mehr Ressourcen. Der Thin Client hat aber nur 2 GB RAM und 16 GB eMMC. Bei den 2 GB RAM kann ich wenig tun, beim Speicher gibt es aber natürlich immer irgendwelche Optionen.

Generell gibt es den HP T430 auch in einer Version mit 4 GB RAM und 32 GB eMMC, die dann auch für Windows gedacht ist und damit ausgeliefert wird.

Klappt es mit 16 GB vielleicht trotzdem?

Ein frisch installiertes Windows 10 braucht etwa 14 GB. Was gerade so noch passt. Aber spätestens nach Treibern (leider gibt es vom Intel Grafiktreiber keine “Lite-Version”) war hier Ende. Ich habe auch versucht, mit NTLite die Treiber und Updates direkt mit ins Image zu backen, aber das hat auch nicht geholfen.

Aufrüsten vom Speicher

Bis auf den M.2-Slot für das WiFi-Modul gibt es im Inneren des T430 keinerlei verfügbare Schnittstellen, alles andere ist verlötet.

Aber das reicht ja, WiFi-Module sind ja meistens über PCIe angebunden. Und für die Slots findet man günstig Adapter. Dementsprechend ist das eMMC-Modul aus meinem Steam Deck mit 64 GB in dem Slot gelandet. Das ist weiterhin nicht super üppig, aber reicht für ein schlankes Windows ohne nennenswert installierte Software mehr als aus.

Installation

Die Installation lief wie eine normale Windows-Installation abläuft. Nur eben etwas langsamer.

Benutzung

Man merkt schon, dass die CPU nicht viel kann. Nur das Öffnen der Einstellungen lastet den Prozessor zu 100% aus, auch Updates dauern länger als gewöhnlich. An die Nutzung als normalen Windows-Rechner braucht man kaum zu denken, dafür reichen die 2 GB RAM (von denen ca 1,5 GB nutzbar sind) und auch die CPU einfach nicht aus. Nur das Herunterladen und Installieren von Firefox hat schon deutlich mehr Zeit gekostet als üblich, normal Surfen ist schwierig.

Als Client für MS RemoteDesktop oder auch Omnissa Horizon macht der T430 mit Windows aber tatsächlich eine gute Figur. Alles läuft so flüssig wie es soll und zumindest in meiner Umgebung läuft RDP spürbar besser als mit ThinPro.

Vorteilhaft ist auch, dass man die normale Auswahl an Treibern zur Verfügung hat, damit kann ich eine alte USB-Grafikkarte auch problemlos am T430 betreiben. Game-Streaming mit Parsec geht damit theoretisch auch, praktisch habe ich es noch nicht getestet.

Wahrscheinlich bleibt es vorerst bei Windows 10. Vielleicht schaue ich, ob man Lizenzen für Windows 10 Enterprise IoT LTSC günstig findet, das wäre ja genau die passende Windows-Edition für einen Thin Client.

Boot-Zeiten

Aus Interesse habe ich Boot-Zeiten verglichen. Ich habe jeweils zwei Messungen durchgeführt, die bis auf wenige Sekunden identisch waren. Gemessen habe ich durch Aufzeichnen des HDMI-Signals mit einer Capture-Card, von erstem Bild bis zum betriebsbereiten Thin-Client.

	Boot-Zeit
ThinPro 9 Onboard	58s
TinPro 9 eMMC	52s
Windows 10 eMMC	23s

Die Ergebnisse finde ich durchaus spannend. Ich hätte einerseits erwartet, dass das eMMC-Modul vom Steam Deck die Boot-Zeiten deutlich verbesser (der interne Speicher hat wirklich niedrige Lese-/Schreibraten), andererseits hätte ich auch nicht gedacht, dass Windows grob doppelt so schnell bootet und einsatzbereit ist.

Fazit

HPs ThinPro ist insgesamt die passendere Lösung für einen Thin Client, das funktioniert einfach. Für mich ist Windows hier aber das bessere OS, da es schneller einsatzbereit ist, besser mit anderen Geräten kompatibel ist (Treiber) und sich RDP auch einfach flüssiger anfühlt.

Storage-Cluster - Part 2: Erster PoC und Planänderungen

Sat, 28 Mar 2026 00:00:00 +0000

Storage-Cluster - Ein erster PoC

Der Plan sieht Futro S740er mit SATA-Controllern vor. Einen entsprechenden Controller auf Basis des ASM1166 (energieeffizienter und gut unterstützter SATA-Controller) habe ich gekauft und mit einem NVMe-Adapter verbaut.

Zugegeben, der PoC sieht etwas wild aus. Am HBA hängen drei SSDs, den Strom bekommen die SSDs über USB zu SATA-Strom-Adapter. Das funktioniert, da 2,5-Zoll-Laufwerke normalerweise nur 5V und keine 12V benötigen, SATA hat eigentlich auch 12V anliegen.

Auf dem Futro läuft Proxmox, der Thin Client ist in meinen normalen Cluster eingebunden.

Ergebnisse vom PoC

Erst habe ich Ceph getestet. Hier hat sich schnell gezeigt, dass 4GB RAM für Ceph einfach zu wenig ist. Das ist schade, da ich Ceph eigentlich gerne genutzt hätte. Es war aber absehbar, dass das nicht klappt.

Ohne Proxmox und weitere Services würde es vermutlich knapp passen, es ist mir allerdings zu heikel.

Alternative zu Ceph

Ich brauche eine Lösung, die halbwegs brauchbare IOPS liefern kann. SaunaFS ist zwar sehr flexibel und kann natürlich auch Replikation, erreicht aber nicht die IOPS-Werte, die ich benötige.

Daher kommt vorerst GlusterFS zum Einsatz, das benutze ich auch jetzt schon für meinen Docker Swarm für persistenten Speicher. GlusterFS ist sehr viel schlanker als Ceph, allerdings auch langsamer und insgesamt schlechter zu administrieren. Ob es tatsächlich die bessere Wahl für mich ist wird sich mit der Zeit zeigen.

Wie es weitergeht

Ich habe die weitere Hardware für den Cluster hier schon liegen, von daher dürfte zeitnahe auch der Post zum vollständigen Setup kommen. Nebenbei bin ich dabei, Ansible-Rollen für die diversen Services zu entwickeln, da ich keine Lust habe, das meiste von Hand zu machen.

Auch habe ich ein 3D-Modell für eine alternative Abdeckung mit großer Öffnung für die SATA-Kabel erstellt, das habe ich auch schon gedruckt und getestet. Damit kann ich die Futros trotzdem schließen und muss die originale Abdeckung nicht beschädigen.

Zusätzlich habe ich auch ein Modell erstellt, was als Halterung für die Futros und die SSDs/HDDs dient. Davon passen dann auch drei nebeneinander in ein Kallax-Fach. Das dürfte insgesamt für mehr Ordnung sorgen und trotzdem Zugriff zu allem ermöglichen.

Code-Server

Sat, 21 Mar 2026 00:00:00 +0000

Ich nutze für meinen Blog mittlerweile Code-Server zum Schreiben und Bearbeiten der Beiträge. Da sich das für mich als überaus praktisch herausgestellt hat, möchte ich die Lösung hier einmal vorstellen.

Hintergrund

Dieser Blog basiert auf Hugo, einem Static Site Generator. Ich habe ein Git-Repo, wo der gesamte Content (und natürlich Dinge wie CI-Files) enthalten sind. Bislang habe ich auf jedem Rechner, wo ich am Blog arbeiten möchte, Visual Studio Code und Hugo (sowie ein paar weitere Tools dafür) installiert. Ich musste auch immer daran denken, im Repo zu committen und zu pushen, wenn ich an einem anderen Rechner weiterarbeiten wollte. Das hat mehrfach dazu geführt, dass ich Merge-Konflikte hatte und auf verschiedenen Rechnern verschiedene Stände.

Meine Lösung

Ich kenne Code-Server schon einige Zeit und habe es in anderem Kontext schon verwendet. Letztendlich handelt es sich “einfach nur” um ein VS Code im Webbrowser, was auf einem Server läuft. Das habe ich in einem LXC installiert, daneben natürlich noch die notwendigen Tools wie Hugo. Als Reverse-Proxy sitzt Caddy dazwischen, die Authentifizierung bzw. Absicherung ist über Forward-Auth zusammen mit Authentik gelöst. Damit kann ich sicher von überall auf den Code-Server zugreifen und an meinem Blog schreiben und bin nicht vom Rechner selbst abhängig.

Proxy für Preview

Standardmäßig lassen sich auf einem Subpfad von Code-Server freigegebene Ports (z.B. der integrierte Preview-Server von Hugo) unter /proxy/<port> aufrufen. Hugo hat hier allerdings ein Problem, da der Subpfad für Hugo nicht sichtbar ist. Damit laden Assets wie CSS und JS nicht.

Abhilfe schafft hier die Nutzung von /absproxy/<port>, in Verbindung mit den Argumenten --baserURL=https://coder.local/absproxy/1313/ --appendPort=false beim Aufruf von Hugo, damit einerseits der Subpfad vor Hugo nicht versteckt wird und andererseits Hugo für die Nutzung auf diesem Subpfad konfiguriert wird.

Fazit

Der neue Workflow funktioniert für mich wirklich gut, ich kann auch während der Schreibphase für einen neuen Post problemlos zwischen Rechnern wechseln und habe immer die selbe Codebasis zur Verfügung. Das hat den Overhead durch genannte Merge-Konflikte (oder das Hochfahren von einem anderen Rechner, um die Änderungen noch ins Repo zu schreiben) spürbar reduziert.

Ob das auf Dauer gut funktioniert weiß ich nicht, aber es sind mittlerweile 4 Monate, seit dem ich Code-Server nutze. Code-Server lässt sich auch für vieles anderes (und deutlich aufwändigeres) nutzen, als ich hier tue.

Planka - einfach nur Kanban

Sun, 08 Mar 2026 00:00:00 +0000

📝 Hinweis

Dieser Post entspricht nicht mehr dem aktuellen Stand, mehr dazu hier

Ich war lange auf der Suche nach einer ToDo-Lösung für mich.

Ein bisschen Historie

Ganz früher habe ich Wunderlist verwendet (heute Microsoft Todo), das hat aber nicht sonderlich lange funktioniert. Dann hatte ich über mehrere Jahre einen eigenen Jira-Server - das lief soweit gut, war aber für den normalen Alltag so viel Overkill wie nur geht. Klar, die Integration mit Confluence und auch die mobilen Apps dazu waren gut, trotzdem ist Jira eher für größeres Projektmanagement als für die eigene ToDo gebaut. Und die Server-Lizenzen für wenige Dollar gibts auch schon lange nicht mehr, Atlassian stellt die selbst hostbaren Produkte ja nach und nach komplett ein. Also zurück zu Microsoft Todo. Das war aber irgendwie immernoch nicht das Wahre. Auf der Suche nach einer weiteren neuen Lösung habe ich mir dann einige Softwareprodukte angesehen. Und gelandet bin ich am Ende bei Planka.

Was kann Planka?

Ganz ehrlich? Nicht viel. Planka kann Kanban-Boards, genau dafür ist es entwickelt worden. Und abseits davon gibts auch nicht viel zu sehen. Aber die Boards sind übersichtlich, Planka braucht eher wenig Ressourcen, lässt sich mit SSO gut integrieren, hat fürs Handy zumindest die Möglichkeit für eine PWA und just works.

Im Vergleich zu anderen Kanban-Lösungen ist Planka minimalistisch gehalten und konzentriert sich auf den Kerngedanken. Gefällt mir gut.

Wie nutze ich Planka?

Ich habe ein großes Board, mit Spalten für Irgendwann, Zeitnahe, Morgen, Heute, In Arbeit, Blocked und Fertig. Das ist also angelehnt an klassisches Kanban, aber mehr auf die Nutzung als persönliche ToDo getrimmt. Das ganze ist mit einer eigenen Software (Plankaprinter) auch halbwegs automatisiert und bindet z.B. meinen Kalender an (und druckt ToDos für heute automatisch auf einem Kassenbondrucker aus). Dadurch kann ich auch sagen, dass sich die API gut nutzen lässt.

Ich habe Planka als Web-App auf allen Rechnern “installiert”, auf dem Handy genauso. Die mobile Nutzung ist nicht perfekt, aber brauchbar.

Das ganze funktioniert so gut, dass meine Partnerin jetzt ebenfalls von Microsoft Todo zu Planka gewechselt hat und Planka einer der zentralen Dienste neben Nextcloud und HomeAssistant geworden ist.

Was fehlt mir?

Zugegeben, das neue Planka v2 habe ich mir noch nicht großartig angeschaut. Daher bezieht sich alles auf v1.

Die mobile Nutzung ist nicht optimal. Vor allem die Meldung, dass die Serververbindung unterbrochen wurde, nachdem man die “App” eine Weile nicht benutzt hat, nervt. Verschieben von Karten funktioniert, teilweise scrollt der Ausschnitt aber zu weit zur Seite und man trifft nicht die korrekte Spalte.

Auch das, was bei Jira die Epics sind, fehlt mir ein wenig. Also größere Aufgaben, zu der dann mehrere Karten gehören. Aber das ist eben nicht das Ziel von Planka, es ist kein volles Projektmanagement-Tool.

Ansonsten wüsste ich aber nicht viel. Eigentlich funktioniert Planka wirklich solide.

Fazit

Planka hat sich jetzt über mehrere Monate hinweg als hilfreich für die eigene Organisation erwiesen. Es kann genug (aber auch nicht zu viel), um als Kanban-Lösung für den Zweck ziemlich gut zu passen. Was will man mehr?

Storage-Cluster - Part 1: Der Plan

Sat, 28 Feb 2026 00:00:00 +0000

Storage-Cluster - der Plan

Wer regelmäßig mit Virtualisierung, Containern und Selfhosting arbeitet, kennt das Problem: der Storage wächst einem über den Kopf. Auch bei mir sind die bisherigen Nodes inzwischen so stark ausgelastet, dass für größere Storage-Aufgaben schlicht kein Platz mehr ist. Zeit also für den nächsten Ausbauschritt in meinem Homelab – ein (weitestgehend) dedizierter, energieeffizienter und möglichst robuster Storage-Cluster.

Das Ziel

Wie auch in größeren IT-Projekten üblich, beginnt alles mit der Zielsetzung bzw. der Erfassung der Anforderungen.

Ich brauche einerseits Storage, der schnell ist und den Ausfall einer von drei geplanten Nodes verkraftet, andererseits Massenspeicher für z.B. Medien, LXC-Templates, ISOs und co, der nicht hochverfügbar sein muss und auch nicht die selben Geschwindigkeiten erreichen muss. Auf dem schnellen Speicher sollen wichtige VMs/LXCs liegen (bspw. DNS und HomeAssistant), daneben soll dieser Bereich auch als Speicher für Docker Swarm dienen.

Am liebsten hätte ich hier natürlich vollständige Hochverfügbarkeit, also keinen einzelnen Single-Point-of-Failure (redundantes Netzwerk, redundante Stromversorgung, …). Das ist für Zuhause aber einerseits overkill und andererseits weder finanziell noch energetisch sinnvoll. Daher möchte ich eine möglichst gute Verfügbarkeit erreichen, ohne dabei komplett in den Enterprise-Bereich vorzudringen.

Die bisherigen Nodes sind mit ihren eigentlichen Aufgaben zu stark ausgelastet, um hier sinnvoll auch noch Storage machen zu können. Das ist so gerade zwar im Einsatz, ich merke allerdings, dass ich mich damit zu nahe an der Grenze bewege.

Der Plan

Ich habe über die letzten Wochen einen Plan erarbeitet, PoCs aufgesetzt und vieles ausprobiert. Bisher ist der Cluster noch nicht aufgebaut, aber ich denke, dass ich mit der Auswahl an Hardware und Software mein Ziel erreiche.

Hardware. Natürlich Thin-Clients

Die Hardwarebasis bilden drei Fujitsu Futro S740 Thin Clients. Dass ich die Dinger mag, ist bekannt. Die Wahl fiel auf dieses Modell, da es günstig ist, sehr energieeffizient läuft und genügend Erweiterungsmöglichkeiten bietet. Der Plan ist hierbei, in der ersten Ausbaustufe den WiFi-Slot für einen SATA-Controller zu nutzen. Später soll der SATA-Controller dann in den SSD-Slot (der laut Internet neben SATA auch PCIe-Anbindung hat) wandern und der WiFi-Slot für eine 2,5 GBit/s Netzwerkkarte genutzt werden.

Geplanter Ausbau pro Node:

4 GB RAM
1x 16/32GB für das OS (meistens dabei)
1× 480 GB SSD (für Ceph)
1× 1 TB HDD (für SaunaFS oder Alternativen)
SATA-Controller über den WiFi-Slot (Adapterlösung)
Später Upgrade auf 2,5 Gbit/s LAN

Das Netzwerk wird anfangs über meine bestehende 1 GBit/s-Infrastruktur gelöst, später ist hier ein zusätzlicher 2,5 GBit/s Switch geplant. Ich rechne ohne Datenträger mit Kosten von ca 75 € pro Knoten, was ich für nicht viel halte. Ohne Datenträger bekomme ich damit für etwas über 200 € einen weitestgehend redundanten Storage-Cluster.

Software

Für den Storage-Cluster sollen zwei Software-Lösungen zum Einsatz kommen. Ceph wird für den schnellen Speicher genutzt, der Massenspeicher wird nach aktuellem Stand auf SaunaFS aufbauen. Ceph habe ich ausgesucht, da es von Proxmox nativ unterstützt wird und dort sogar gut integriert ist. Neben Blockspeicher kann ich dort über CephFS auch Freigaben auf Dateiebene erzeugen, was ich für Docker Swarm benötige. Es ist zudem performant und im Enterprise-Bereich stark vertreten. Für den langsameren Speicher habe ich lange überlegt, was ich nutzen möchte. Erst hatte ich GlusterFS vorgesehen. Mittlerweile habe ich mich hier aber umentschieden und möchte SaunaFS einsetzen. Das ist ein Fork von LizardFS, was wiederum ein Fork von MooseFS ist. Es ist für verteilten Massenspeicher ausgelegt, hat eher wenig Overhead und bietet sogar die Option, die Anzahl der Replikas pro Ordner festzulegen.

Auf jedem der Futros wird dementsprechend Proxmox VE installiert und die Nodes in den bisherigen Cluster eingefügt. Die SSDs werden als OSDs für Ceph genutzt, die zusätzlichen Datenträger dann als Mountpoints an einen LXC pro Node angebunden. Dort wird dann SaunaFS installiert. SaunaFS kann ich aufgrund der Voraussetzung von Ubuntu als OS leider nicht direkt auf den Knoten installieren, die Variante mit SaunaFS habe ich jetzt aber auch schon eine Weile im Haupt-Cluster im Testbetrieb erfolgreich genutzt.

Das SaunaFS-Volume wird dann von einem Knoten via Samba und NFS freigegeben. Das hat den Hintergrund, dass es mit vielen Dingen kompatibel ist und sich so z.B. auch in Proxmox als Speicher für Templates und ISOs gut einbinden lässt.

Weitere Ideen und mögliche Dienste

Wenn die Performance passt, sollen auf dem Storage-Cluster später auch leichte Dienste laufen und damit die bestehenden Nodes etwas entlastet werden. Kandidaten dafür sind Dinge wie der Proxmox Backup Server oder auch Komponenten von meinem Monitoring-Stack.

Ob das mit 4 GB RAM pro Node praktikabel ist, wird sich erst zeigen - mehr RAM kaufen ist aber aufgrund der Lage am Markt gerade keine Option.

Nächste Schritte

Ich habe Hardware bestellt, um einen Futro mal mit einem SATA-Controller auszustatten und damit schonmal als Storage (ohne Ceph oder Replikation oder so) einzusetzen. Das dient als erster Test. Wenn das so funktioniert, wie ich mir das vorstelle, werden weitere Futro S740er gekauft und der Cluster aufgebaut.

Ich nehme dafür den Futro, den ich eigentlich für den 3D-Drucker gekauft hatte. Dort kommt einfach wieder der S520 hin. Das bietet sich an, da ich für den 3D-Drucker wenig Leistung brauche, der Futro S520 eh nichts zu tun hat und ich so gut etwas Geld sparen kann.

Authentifizierung und Single-Sign-On im Homelab mit Authentik

Sun, 22 Feb 2026 00:00:00 +0000

Zentrale Authentifizierung bringt selbst im Homelab klare Vorteile: Einmalige Anmeldung spart Zeit, erhöht die Sicherheit durch weniger Passwörter und erleichtert die Verwaltung von Zugriffsrechten – perfekt für ein Homelab mit vielen Services. Nebenbei bekommt man damit auch Anwendungen, die zwar SSO können, aber keine Multifaktorauthentisierung beherrschen, mit MFA ausgestattet.

Vorteile gegenüber anderen Lösungen (Keycloak)

Ich hatte früher Keycloak im Einsatz, was mir aber aufgrund seiner Komplexität im Homelab einfach zu überladen war. Keycloak kann sicherlich mehr als Authentik (denke ich zumindest), ist für mich zuhause allerdings overkill. Authentik ist zwar auch nicht trivial, trotzdem empfinde ich die Konfiguration als angenehmer. Für mich ist der Hauptzweck im Homelab OpenID Connect (OIDC), andere Protokolle wie SAML spielen bei mir keine Rolle.

Outposts

Ein weiterer großer Vorteil von Authentik sind die sogenannten Outposts, mit denen neben SSO-Protokollen auch LDAP-Dienste, Remotedesktop-Zugriff und Proxy-Authentifizierung angeboten werden.

Über den Proxy-Outpost kann man die Authentifizierung direkt in einem Reverse-Proxy bzw. Webserver integrieren. Dadurch lassen sich interne Anwendungen sehr sicher über das Internet erreichbar machen. Bei mir laufen viele Anwendungen mit OIDC-Anbindung, einige interne Dienste sind zudem über Caddy mit Forward-Auth abgesichert. Mein Proxmox-Cluster ist sogar direkt per LDAP-Outpost an Authentik angebunden, was den Sync von Usern und Gruppen einfach macht. Ob das sinnvoll ist, ist allerdings eine andere Sache, immerhin bin ich der einzige Benutzer. Andere Services wie beispielsweise Nextcloud oder Planka nutze ich hingegen nicht nur alleine.

Relativ neu ist der Remote Access Control (RAC) Outpost, womit sich Remotedesktop-Dienste anbinden lassen. Die Technik dahinter ist am Ende allerdings “nur” ein Apache Guacamole, den ich schon anderweitig betreibe und durch den getrennten Betrieb bessere Kontrolle und mehr Konfigurationsmöglichkeiten erhalte.

Konfiguration für Forward-Auth mit Caddy

Hier ein kurzes Config-Snippet für Auth mit Caddy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


(authentik_forwardauth) {
 reverse_proxy /outpost.goauthentik.io/* http://proxy-outpost:9000
 forward_auth http://proxy-outpost:9000 {
 uri /outpost.goauthentik.io/auth/caddy
 copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Entitlements X-Authentik-Email X-Authentik-Name X-Authentik-Uid X-Authentik-Jwt X-Authentik-Meta-Jwks X-Authentik-Meta-Outpost X-Authentik-Meta-Provider X-Authentik-Meta-App X-Authentik-Meta-Version
 trusted_proxies private_ranges
 }
}

proxmox.example.com {
 import authentik_forwardauth
 reverse_proxy 192.168.0.2:8006 {
 transport http {
 tls_insecure_skip_verify
 }
 }
}

In Authentik muss Proxmox mit der entsprechenden Domain als Proxy-Provider angelegt werden, mit dem Modus “Forward Auth”. Beim Outpost selbst muss dieser Provider dann noch zugewiesen werden, danach sollte alles schon funktionieren.

Der Proxy Outpost kann wohl auch direkt Proxy spielen - mit der Lösung via Caddy und Forward-Auth kann ich allerdings mehrere Anwendungen anbinden, ohne mehrere Outposts zu benötigen.

Weitere praktische Features

Neben der eigentlichen Authentifizierung zeigt Authentik die eingerichteten Anwendungen auch auf einer übersichtlichen Hub-Oberfläche an. Die Anwendungen lassen sich in Gruppen ordnen, es werden auch nur die Anwendungen angezeigt, die zu denen der entsprechende Benutzer Zugang hat. Das erspart den Betrieb von einer getrennten Homepage bzw. Hub-Oberfläche.

Fazit

Nach mehreren Jahren im Betrieb funktioniert Authentik zuverlässig und stabil. Es ist eine empfehlenswerte Alternative zu Keycloak, wenn man eine sichere, moderne Authentifizierungslösung mit erträglichem Konfigurationsaufwand im Homelab sucht. Vor allem die Outposts sind ein klarer Vorteil von Authentik gegenüber anderer Lösungen.

Harbor als lokale Container-Registry

Fri, 06 Feb 2026 00:00:00 +0000

Harbor ist eine Open-Source-Container-Registry-Plattform, die Docker-Images und Helm-Charts speichert und verwaltet. Neben der Nutzung als normale Registry zum Speichern von Images kann Harbor auch als Proxy-Registry dienen. Das ist bei mir der primäre Einsatzzweck. Nebenbei kann Harbor auch die Images mit Trivy auf bekannte Schwachstellen scannen. Die Übersichtsseite leuchtet leider schnell wie ein Weihnachtsbaum - man sieht schnell, welche Images lange nicht mehr aktualisiert wurden oder veraltete Softwareversionen nutzen. Trivy ist hierbei einer der gängigen Scanner, der die im Image vorhandenen Komponenten gegen Datenbanken mit bekannten Schwachstellen prüft (nicht nur normale Pakete, es werden bei diversen Programmiersprachen auch die verwendeten Libraries geprüft).

Registries wie Docker Hub haben oft Pull-Limits, besonders bei häufigen Updates im Homelab ist das schnell nervig. Mit Harbor dazwischen reduziere ich die Anzahl der Pulls direkt von Docker Hub und kann auch schon gespeicherte Images oder Layer schneller ausliefern. Vor allem durch meine Verwendung von Docker Swarm ist das von Vorteil, da sonst bei der Migration eines Services von einer Node zu einer anderen das Image neu von der Quelle heruntergeladen wird. Mit Harbor als Proxy bzw. Cache kommt das Image dann direkt aus dem lokalen Netz.

Installation

Die Einrichtung ist unkompliziert, allerdings etwas anders, als man es von anderen containerisierten Diensten kennt. Man benötigt den Harbor-Installer von z.B. Github. Dann muss noch die harbor.yml erstellt bzw. angepasst werden (Hostname, HTTPS, Admin-Passwort), dann wird der Installer ausgeführt. Die Services sind am Ende ein normaler Docker Compose Stack.

Sinnvoll ist hier auch die Nutzung eines Reverse-Proxies mit SSL, da Docker (und auch andere Container-Runtimes) Pulls aus unsicheren (=http) Registries ohne weitere Konfiguration verweigern. Am einfachsten ist ein Zertifikat von bspw. Lets Encrypt, mit der DNS-Verifizierungsmethode geht das dann auch, ohne dass Harbor von außen erreichbar ist. Selbstsignierte Zertifikate (z.B. via ACME von [Step-CA]({« ref “/blog/2025/2025-02-28-lokale-ssl-zertifikate-mit-caddy-und-step-ca/index.md” »})) sind möglich, dann muss das entsprechende Root-Zertifikat allerdings auf jedem System, das die lokale Registry nutzen soll, hinterlegt werden.

Cache-Repo einrichten

Damit man ein Cache-Repository einrichten kann, muss zuerst die Upstream-Registry unter Administration -> Registries hinzugefügt werden. Wenn ein Cache für Docker Hub angelegt werden soll, ist es hierbei empfehlenswert, Zugangsdaten mit anzugeben, um von den höheren Pull-Limits zu profitieren.

Danach kann unter Projekte ein neues Projekt mit aktivem Proxy Cache eingerichtet werden und der entsprechende Upstream (z.B. die angelegte Docker-Hub-Registry) ausgewählt werden.

Client einrichten

In Harbor lassen sich Robot-Zugänge unter Administration anlegen. Bei den Berechtigungen habe ich folgendes vergeben:

Artifact: Auflisten, Lesen
Repository: Auflisten, Pull, Lesen
Tag: Auflisten

Danach muss nur noch der Client (hier Docker) angemeldet werden.

Im Fall von Docker ist das schnell gemacht:

1

docker login harbor.local

Danach zieht man Images einfach über harbor.local/dockerhub-cache/image:tag (natürlich mit korrektem Hostnamen und Registry-Namen) - Harbor übernimmt den Rest automatisch. In Compose-Dateien lässt sich die Cache-Registry dann natürlich auch nutzen.

Fazit

Harbor funktioniert bei mir ziemlich gut, allerdings waren auch schon 1-2 Mal die Container morgens nicht mehr gestartet. Man schafft sich damit leider auch einen Single Point of Failure, da der Betrieb von allen Containern im Lab von der Registry abhängt. Vor allem beim Betrieb von vielen Containern oder bei Nutzung eines Orchestrators (wie Kubernetes oder Docker Swarm) ist ein lokaler Cache zur Verminderung von Pulls aber definitiv sinnvoll und verringert die Startzeiten von Containern auf neuen Nodes spürbar.

Outline als (persönliches) Wiki

Sat, 31 Jan 2026 00:00:00 +0000

Lange Zeit habe ich Confluence als Wiki genutzt. Funktionsreich, hübsch und mit Jira integriert. Aber irgendwann kamen die bekannten Punkte: hoher Ressourcenbedarf und aktiver Rückbau der selbstgehosteten Version durch Entfernung der günstigen Lizenzen (und zukünftig auch aller selbsthostbaren Varianten). Also begann die Suche nach einer Alternative, die möglichst schlank, aber trotzdem gut nutzbar sein sollte.

Ich habe mir dabei diverses angesehen. XWiki kannte ich von der Arbeit, gefiel mir aber weder optisch noch von der Bedienung her. Von den Ressourcen war es auch eher auf dem Level von Confluence. MediaWiki hat für nicht funktioniert - als Wiki generell nicht schlecht, für “mal eben” aber irgendwie unhandlich. Wiki.js habe ich mir ebenfalls angesehen, aber auch damit bin ich nicht so wirklich warm geworden. Die Bedienung ging nicht so von der Hand, wie ich mir das vorgestellt habe.

Dann hat mir mein Bruder Outline gezeigt. Was für mich ziemlich perfekt aussah. Minimalistisch, schnell, gute und intuitive Bedienung. Es fühlt sich modern an, ohne überladen zu sein. Und ist auch noch Markdown-basiert. Eine native App gibt es zwar nicht, die PWA funktioniert aber gut.

Der Funktionsumfang und auch Gestaltungsmöglichkeiten sind natürlich deutlich unter dem, was Confluence kann, aber davon vermisse ich auch nach vielen Jahren wenig.

Betrieb

Selfhosting bei Outline ist nicht so einfach wie bei anderen Softwareprodukten. Neben einer Postgres-Datenbank wird Redis benötigt - soweit so gut. Zwingend erforderlich ist aber auch ein externer Auth-Provider - in meinem Fall OIDC via Authentik. Früher war auch ein S3-Bucket als Speicher für Anhänge erforderlich, die Anforderung ist aber dank dem neu hinzugekommenen lokalen Storage nicht mehr verpflichtend. Trotzdem fühlt es sich so an, als ob Selfhosting zwar offiziell unterstützt wird, der Hersteller aber den Fokus klar auf dem eigenen SaaS-Angebot in der Cloud hat.

Hat man das Setup aber einmal laufen, ist Outline sehr stabil. Ich nutze es nun seit gut drei Jahren in meiner Umgebung, und es ist dabei geblieben – einfach, weil es funktioniert.

Fazit

Outline hat sich bei mir nun wirklich bewährt. Minimalistisch, aber trotzdem genügend Features; selbst hostbar, gute Bedienung. Alternativ lohnt sich ein Blick auf Bookstack. Das habe ich mir zwar lange nicht mehr angesehen, war aber der Alternativkandidat, falls Outline mir nicht gefallen hätte.

Docker Swarm nach zwei Monaten

Sat, 03 Jan 2026 00:00:00 +0000

Auch, wenn der Blog-Post zu Docker Swarm noch keinen Monat her ist, ist Swarm jetzt seit November bei mir im Einsatz. Ich möchte hier einmal ein Zwischenfazit geben.

Wie das Setup aussieht

Ich habe pro physischem Host eine Swarm-VM, die drei VMs sind auch alle als mögliche Master-Nodes konfiguriert. Damit findet die Auswahl eines neuen Masters statt, sobald der bisherige Master nicht mehr erreichbar sein sollte. Storage ist über NFS abgebildet, das basiert auf zwei VMs (plus eine Witness-Node) mit Pacemaker, Corosync und DRBD. Das läuft soweit auch stabil, auch wenn die Performance etwas besser sein könnte. Vor allem bei Random Access merkt man doch deutlich den Unterschied zu lokalem Storage. Fairerweise muss ich dazu aber auch sagen, dass das wahrscheinlich primär an der verwendeten Hardware liegt, die Kombination aus Thin Client und günstiger SSD ist da sicherlich nicht hilfreich. Ich muss leider auch die Verzeichnisse auf dem NFS-Server händisch anlegen, damit ich diese in Volumes referenzieren kann. Das geht besser, bin ich von Kubernetes mit dem NFS-Provisioner auch anders gewohnt. Alternative Storage-Lösungen wie Ceph oder ähnliche sind mir fürs Homelab allerdings auch zu komplex. Mit dem Punkt kann ich aber generell gut leben.

Zum Management nutze ich Portainer CE. Das ist eins der wenigen Tools, die auch mit Swarm umgehen können, wobei wohl bei Komodo in einer zukünftigen Version Swarm auch unterstützt werden soll. Zwecks Monitoring läuft auf den Nodes jeweils der Node-Exporter und ein Docker-Exporter. Der Docker-Exporter kann zwar nicht nativ mit Swarm umgehen, erfasst aber trotzdem dann pro Node die laufenden Container inkl. der benötigten Ressourcen. Das reicht mir.

Was mir im Betrieb aufgefallen ist

Der Scheduler ist sehr grundlegend. Nach dem, was ich im Internet finden konnte, wird aus den Nodes, die die Constraints und die Ressourcen-Requirements erfüllen, die Node mit den wenigsten Containern ausgewählt und der Task dort gestartet. Wirklich gut steuern lässt sich das auch nicht, es gibt nur harte Constraints und keine weichen. Das kann Kubernetes sehr viel besser. By Design werden Service auch nach dem Joinen einer neuen Node (oder eine bestehende Node war z.B. wegen Wartungsarbeiten offline) nicht neu verteilt, das machen andere Lösungen wie Kubernetes aber auch nicht anders. Um das auszugleichen bin ich aktuell dabei, einen Rebalancer zu entwickeln, der diesen Zustand erkennt und gezielt Services neu startet, um ein Rescheduling zu erzwingen. Das ist aber noch nicht fertig.

Wie es weitergeht

Ich bin weiterhin dabei, Services zum Swarm-Cluster zu migrieren, insgesamt bin ich mit der Lösung soweit glücklich. Storage wird von der Performance her irgendwann wahrscheinlich zum Flaschenhals, aber darum mache ich mir dann Gedanken, wenn es soweit ist.

Ich trauere tatsächlich noch ein wenig Kubernetes hinterher, vor allem weil ich es beruflich gewohnt bin. Für Zuhause ist es allerdings meiner Meinung nach komplett overkill.

Containerorchestrierung im Homelab

Wed, 17 Dec 2025 00:00:00 +0000

Wie die meisten anderen auch habe ich in meinem Homelab einiges an Containern mit Docker in Betrieb. Bisher verwalte ich das in mehreren VMs in Form von Docker-Compose-Stacks händisch - was eher unbequem ist und auch für Ausfallsicherheit und ähnliches nicht förderlich ist. Es ist außerdem aufwändig, Services zwischen den Nodes zu verschieben.

Orchestrierungstools

Das hier ist natürlich keine vollständige Auflistung, es sind nur die Optionen, die ich in Betracht gezogen habe.

Docker Compose Stacks

…also die bisherige Lösung.

Letztendlich einfach nur ein Ordner mit Unterordnern pro Compose-Stack bzw. pro Service.

Vorteile:

leicht verwaltbar
Tools wie Watchtower funktionieren problemlos
viele Softwareprodukte bieten fertige Compose-Files an

Nachteile:

Keine Redundanz bzw. Failover
Unübersichtlich, was wo läuft
Traffic muss von außen an die korrekte VM geleitet werden

Kubernetes

Beruflich hantiere ich täglich mit Kubernetes, ich bin also mit der Funktionsweise und auch den Tools vertraut. Ausprobiert habe ich k3s und Talos, sowohl mit Longhorn als auch mit NFS als Storage. Compose-Stacks lassen sich mit dem Tool Kompose leicht konvertieren. Mich hat hier allerdings der Overhead gestört. Eine Worker-Node ohne jegliche Workload hat ~10 % CPU-Auslastung erzeugt, was vor allem bei den Thin Clients einfach zu viel ist. Auch ist mir die Verwaltung für zuhause eigentlich zu komplex.

Vorteile:

gängiges Orchestrierungstool
Helm-Charts für viele gängige Softwareprodukte verfügbar
gutes Scheduling bzw. Lastmanagement, Scheduling auch sehr gut beeinflussbar
Kompatibel mit vielen Storage-Lösungen
hohe Anzahl an Tools (GUIs und andere Lösungen)
Ingress bzw. Overlay-Netzwerk - Services lassen sich problemlos auf allen Nodes erreichbar schalten, intern wird zur korrekten Node geroutet
Secret-Management mit vielen Optionen

Nachteile:

Komplex in der Verwaltung
Hoher Ressourcenoverhead

Docker Swarm

Docker Swarm ist eine Möglichkeit, mehrere Docker-Daemons miteinander zu vernetzen und zu einer Einheit zu kombinieren. Es ist von der Komplexität her irgendwo zwischen einfachem Docker und Kubernetes, bietet dabei aber auch längst nicht so viele Optionen wie Kubernetes. Der Ressourcenverbrauch ist erfreulich niedrig und die Arbeit mit dem Tool fällt recht leicht, wenn man Compose gewohnt ist. Die Migration von Services ist auch einfach - die Compose-File minimal modifizieren, Storage anlegen und Inhalte übertragen und deployen.

Vorteile:

Simpel zu nutzen, ähnlich zu Docker Compose
Compose-Files lassen sich nahezu unverändert einsetzen
Overlay-Netzwerk - Services sind auf allen Nodes erreichbar, intern wird zur korrekten Node geroutet

Nachteile:

wenig verbreitet, wenig Tools
Scheduling ist rudimentär (nur harte Constraints möglich, keine Präferenzen bzw. weiche Constraints)
Weniger Support für verschiedene Storage-Lösungen

Meine Entscheidung

Bisher läuft eigentlich alles mit normalen Compose-Stacks. Ich habe erst Kubernetes mit verschiedene Distributionen evaluiert (Talos und k3s) - und obwohl mir das eigentlich gut gefällt und für mich gewohnte Tools sind, ist mir der CPU-Overhead für meinen Wunsch nach Energieeffizienz einfach zu groß; auch wenn die Vorteile ansonsten überwiegen.

Am Ende fühlt sich Docker Swarm für meinen Einsatzzweck ideal an: leichtgewichtig, bekanntes Compose-Ökosystem, dazu Clustering und Failover. Durch den zentralen NFS-Storage (DRBD-basiert) kann ich Workloads problemlos verschieben, und das Deployment neuer Stacks ist sehr unkompliziert.

Der größte Nachteil ist tatsächlich die Tool-Landschaft. Portainer ist aktuell praktisch das einzige gepflegte GUI-Tool – aber es deckt alles ab, was ich brauche. Früher habe ich Swarmpit genutzt, aber dort passiert im Repo leider kaum noch etwas.

Alles in allem ist Swarm für mein Homelab der beste Kompromiss aus Redundanz, Energieeffizienz und administrativem Aufwand. Ich werde jetzt nach und nach meine Services migrieren, mal schauen, ob ich dabei noch auf Probleme stoße.

Nutzung alter Hardware als Minecraft-Server

Mon, 01 Dec 2025 00:00:00 +0000

Für ein temporäres Projekt brauchte ich genügend Ressourcen für einen Modded Minecraft Server. Auf dem Mini-PC, den ich für meinen Hauptserver gekauft hatte, habe ich allerdings nicht genügend freie Ressourcen. Dementsprechend habe ich mich im Keller umgesehen und passende Hardware gefunden - ein PC mit einem i5 4440, 16GB RAM und genügend SSD-Platz. Eine GPU war auch noch verbaut, die habe ich entfernt. Der PC diente zwischenzeitlich als Experimentierumgebung mit Ollama, genutzt habe ich den aber tatsächlich jetzt fast ein Jahr lang nicht mehr.

Hardware

Intel Core i5 4440 (4x 3,1 GHz, Haswell)
2x 8GB DDR3 RAM
16GB SSD (OS)
240GB SSD (MC-Server)
OS: Debian

Software

Als OS habe ich Debian installiert, hier geht aber auch fast jedes beliebige andere Linux. Letztendlich läuft auf dem Rechner eigentlich nur Wings für Pterodactyl. Installiert habe ich Debian über mein IODD ST400, das war jetzt der erste richtige und erfolgreiche Praxistest für das Gerät.

Auf dem Debian ist ansonsten Docker installiert, das benötigt Wings zum Ausführen der eigentlichen Gameserver. Daneben ist ansonsten noch der Prometheus Node Exporter installiert, damit ich Metriken für mein Monitoring abgreifen kann.

Stromverbrauch

Der Stromverbrauch liegt deutlich höher als beim Mini-PC: Im Idle ca 25 Watt, unter Last auch bis zu ca 60 Watt. Wie groß der Verbrauch in der Praxis dann ist weiß ich natürlich noch nicht. Das kostet auf Dauer natürlich mehr Geld, aber da ich diesen Server vermutlich nur wenige Wochen so benötige, ist es die wirtschaftlichste Option. Im Vergleich zu einem gemieteten vServer hat dieser Rechner auch den Vorteil, dass der Minecraft-Server die CPU vollständig für sich hat und es keine “noisy neighbors” gibt. Ein vServer mit diesen Leistungseckdaten ist bei den gängigen Anbietern auch etwas teurer als mich der Strom hier kostet.

Benchmark

Die Benchmarks sind in einem ähnlichen Bereich wie beim Lenovo ThinkCentre M715q Tiny, an einigen Stellen trotz des Alters besser.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


root@mc:~# curl -sL yabs.sh | bash -s -- -r -5 -6
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2025-04-20 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Mon Nov 17 08:34:30 PM CET 2025

Basic System Information:
---------------------------------
Uptime : 0 days, 0 hours, 0 minutes
Processor : Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz
CPU cores : 4 @ 3093.207 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 15.5 GiB
Swap : 953.0 MiB
Disk : 232.7 GiB
Distro : Debian GNU/Linux 13 (trixie)
Kernel : 6.12.57+deb13-amd64
VM Type : NONE
IPv4/IPv6 : ✔ Online / ❌ Offline

IPv4 Network Information:
---------------------------------
ISP : Vodafone Kabel Deutschland
ASN : AS3209 Vodafone GmbH
Host : Vodafone Kabel Deutschland GmbH
Location : Cadenberge, Lower Saxony (NI)
Country : Germany

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sdb2):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
 ------ | --- ---- | ---- ----
Read | 22.98 MB/s (5.7k) | 31.36 MB/s (490)
Write | 22.98 MB/s (5.7k) | 31.74 MB/s (495)
Total | 45.96 MB/s (11.4k) | 63.10 MB/s (985)
 | |
Block Size | 512k (IOPS) | 1m (IOPS)
 ------ | --- ---- | ---- ----
Read | 32.14 MB/s (62) | 32.97 MB/s (32)
Write | 34.56 MB/s (67) | 35.51 MB/s (34)
Total | 66.71 MB/s (129) | 68.49 MB/s (66)

Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
 |
Single Core | 918
Multi Core | 3049
Full Test | https://browser.geekbench.com/v5/cpu/23910060

Geekbench 6 Benchmark Test:
---------------------------------
Test | Value
 |
Single Core | 1194
Multi Core | 3614
Full Test | https://browser.geekbench.com/v6/cpu/15090984

YABS completed in 13 min 41 sec

Die Historie meines Labs (2016 bis Q3 2025)

Wed, 22 Oct 2025 00:00:00 +0000

Mein Homelab existiert seit 2016 - wenn man es als dauerhaften Betrieb von irgendwelchen Servern/Services zu Hause definiert. Wenn die Definition auch nur temporär aktive Server beinhaltet, geht es sogar noch weiter zurück, wobei ich dann das Jahr nicht einmal genau definieren kann. Mein Lab hat generell viele Iterationen durch, wobei das auch mehr ein kontinulierlicher Prozess ist. Ich habe hier einmal die bisherigen nennenswerten Iterationen einmal aufgelistet.

Vor 2016

Ich habe auf einem alten Laptop erst versucht, mit ESXi herumzuspielen, dann aber festgestellt, dass die CPU noch keine Hardwarevirtualisierung kann. Daher habe ich dann Debian und openVZ installiert, um zumindest mit Containern arbeiten zu können. Das lief auch soweit brauchbar.

2016 - erste richtige Anfänge

2016 habe ich bei meinen Eltern den ersten Server dauerhaft betrieben. Es war ein Server mit einem AMD Sempron 3850 (kleine CPU mit 4 Kernen von AMD, ziemlich leistungsschwach). Der Standort im Haus war nur über Powerline zu erreichen, das hat mich aber damals nicht nennenswert gestört. Ich habe dort mit Proxmox verschiedene VMs betrieben, welche Software genau in den VMs und Containern lief weiß ich gar nicht mehr so genau.

2017

Im Laufe des Jahres kamen dann zwei weitere Server dazu. Einerseits ein alter Dell Poweredge (mit einem Xeon X3220), andererseits ein alter PC mit einem Core2Duo. Beide Maschinen liefen nicht dauerhaft, diese habe ich nur bei Bedarf mit hochgefahren. Für den Dauerbetrieb wäre der Stromverbrauch viel zu hoch gewesen. Ich habe auch am Netzwerk Änderungen vorgenommen, konkret den bisherigen 100M-Switch durch ein Gigabit-Fähiges Modell ausgetauscht.

2018

Hiervon habe ich leider kein Bild. Ich habe allerdings in meinem Zimmer im Studentenwohnheim hinter einem Regal einen kleinen Server betrieben. Dieser lief erst mit einem Intel Celeron G1820, dann habe ich via Ebay günstig ein Bundle mit einem Supermicro-Mainboard, einem Intel Xeon E3-1230v3 und 32GB ECC-RAM gekauft und in das Gehäuse gesetzt. Auf dem Server lief u.A. pfSense als Router, daneben noch diverse andere Services - auch hier habe ich leider keine Übersicht mehr, was das genau war. Irgendwann in dem Zeitraum habe ich auch eine einfache USV gekauft.

2019

Nachdem ich umgezogen war, hatte ich etwas mehr Möglichkeiten, ab hier habe ich auch für meinen Strom dann vollkommen selbst bezahlt. Der Server ist in ein schickeres Gehäuse gewandert, im Rahmen von dem Umzug habe ich auch das NAS, das bis dahin bei meinen Eltern stand, mit in die Wohnung geholt. Das NAS dürfte zu dem Zeitpunkt noch einen AMD Sempron 3850 als CPU gehabt haben, auch das kann ich leider nicht mehr wirklich rekonstruieren.

Das Netzwerk habe ich beim Umzug auch vollkommen neu gestrickt. Zentrum war ab dann ein Unifi USG mit einem Unifi AP AC Lite (man sieht links den PoE-Injector) als Access Point. Der 8-Port-Switch war vorher schon im Einsatz. Als Modem kam vor dem USG eine ältere Fritzbox zum Einsatz, die ist auch bis heute noch aktiv. Heutzutage ist die allerdings nur noch Basisstation für ein Schnurlostelefon sowie einige Thermostate. Das USG habe ich nach dem nächsten Umzug (2022) verkauft.

2020

Ich hatte den Plan, mir irgendwann mal ein Rack zuzulegen. Deswegen habe ich mehr oder weniger “einfach so” ein Rack-Gehäuse von Inter-Tech gekauft und den Server in dieses Case verschoben. Ich musste auch noch ein passendes Netzteil dazu kaufen, da die meisten ATX-Netzteile unten ansaugen und nach hinten rausblasen - von unten/oben Luft ansaugen geht bei so einem Case allerdings schlecht. Das Case habe ich auch bis heute, ein Rack bislang aber nicht. Vielleicht kommt das irgendwann dann doch noch mal…

Die USV ist auf dem Bild außer Betrieb, das habe ich irgendwann aus Stromgründen getan.

2021

Der Unterschied zu vorher ist kaum sichtbar, der Server steht nun allerdings auf Styropor und das NAS darauf. In dem weißen Kasten sind Module von Tinkerforge, der Temperatursensor hängt sichtbar vorne raus.

Hier kann man auch sehen, dass im NAS irgendeine Intel-CPU arbeitet und den Sempron 3850 abgelöst hat. Welche das ist weiß ich nicht, entweder der Celeron G1820 oder ein Core i3 4130; wahrscheinlicher ist allerdings der Celeron.

Das USG von Unifi ist hier auch schon nicht mehr in Betrieb, der Router ist nun ein Mikrotik hAP AC². Der Unif-Accesspoint dürfte allerdings zu dem Zeitpunkt noch aktiv gewesen sein, zumindest sehe ich auf dem Bild einen schwarzen Block hinten im Regal, der wahrscheinlich der PoE-Injektor ist. Später habe ich den Switch durch einen 24-Port-Switch von TP-Link getauscht, da ich mit 8 Ports nicht mehr hinkam. Ich habe nämlich immer mal wieder einen zweiten Server mit meiner alten Desktop-CPU (Intel Core i5 4440) betrieben, worauf dann mein Minecraft-Server lief. Zeitweise habe ich auch mit einem reinen SSD-NAS experimentiert - ein weiterer Tower.

2022

Ende 2022 bin ich erneut umgezogen, in dem Zuge habe ich das Lab wieder weiter verändert. Der dauerhaft laufende Server ist komplett entfallen und durch zwei Raspberry Pis ersetzt worden. Das Netzwerk hat sich auch stark geändert - Basis ist nun ein Mikrotik hAP AC2. Als Modem ist eine Vodafone Station sowie ein LTE-Router von TP-Link dazugekommen. Auch ein zweiter Switch ist neu.

Das NAS sowie der Server auf Supermicro-Basis (zurück in einem Tower-Case) haben einen anderen Ort innerhalb vom Arbeitszimmer bekommen - die Bilder von 2023 zeigen das gut.

2023

Die Raspberry Pis waren dann schneller zu klein als gedacht - es musste wieder mehr Hardware her. Deshalb kam hier der erste Futro S740 dazu. Das Regal habe ich in dem Zuge auch gleich getauscht.

Der Server auf Supermicro-Basis ist wieder in ein normales Tower-Case gewandert und in einer anderen Ecke im Arbeitszimmer hinter einem Regal verschwunden (man sieht es hinten auf dem Bild). Das NAS steht auf dem genannten Regal. Das hing alles hinter einer WLAN-Steckdose, um den Standby-Verbrauch möglichst weit zu reduzieren.

Später im Jahr habe ich dann den Supermicro-Server doch wieder in das Rack-Case umgebaut und zusammen mit dem großen Switch im Keller platziert. Die Anbindung vom Keller ging leider nur per Powerline, aber das lässt sich auch nicht ändern.

2024

Herbst 2024 kam der zweite Fujitsu Futro S740 und auch ein Lenovo Tinkcenter M715q Tiny dazu, auch habe ich den 5-Port-Switch durch einen 8-Port-Switch ausgetauscht, der neue Switch ist auch VLAN-fähig. Der Lüfter, der auf den Thin Clients liegt, ist auch neu - der war notwendig, da die SSDs bei beiden Thin Clients mit der Zeit zu warum wurden.

Im Keller ist der HP-Server dazugekommen, auch ein zweiter Thin-Client (Futro S520) ist hier neu. Der Keller hat zwischenzeitlich auch einen eigenen Mikrotik hAP AC2 bekommen, damit ich Routen via BGP austauschen kann, WLAN im Keller habe und die Netze zwecks Reduzierung von Broadcast auch soweit getrennt laufen.

2025

Anfang des Jahres sind einige Hardware-Upgrades passiert, aber wenig sichtbares. Im Sommer habe ich allerdings beschlossen, mir ein 10-Zoll-Rack zu bauen. Die Rahmen sind mit dem 3D-Drucker gedruckt, die Schienen zum Festschrauben als fertige Teile gekauft.

Was geplant ist

…das ist eine gute Frage. Gerade wenig konkretes. Ich habe viele Ideen, aber was davon ich wann umsetze, weiß ich tatsächlich nicht. Der Router ist für manches zu schwach (und hat auch wenig Speicher), ein Switch mit PoE wäre schön (damit der Injektor wegfällt), mehr Mini-PCs statt Thin-Clients wären eine Idee, ein NAS für VMs und co wäre cool, ein Server mit GPU fände ich auch nett…

Als nächstes wird vielleicht einer der Thin Clients noch gegen einen Mini-PC getauscht. Ich habe mittlerweile teilweise zu wenig RAM, vor allem wenn gerade ein LLM aktiv ist. Welche und wofür ich LLMs nutze, schreibe ich vielleicht irgendwann auch mal auf.

PlankaPrinter - oder auch: Ich habe mir einen Bondrucker gekauft

Sat, 20 Sep 2025 00:00:00 +0000

Ich neige manchmal dazu, unkonventionelle Ideen zu haben und diese auch umzusetzen. In diesem Fall ist die Idee nicht komplett von mir, es passt trotzdem gut ins Bild.

Aber der Reihe nach.

Die Idee

Ich habe bisher eine normale ToDo-App benutzt, aber das Problem, dass ich da wenig drauf schaue und daher auch eher wenig abarbeite. Durch Zufalll bin ich im Internet auf ein Video gestoßen, wo jemand einen Kassenbondrucker für ToDo-Tickets in Verbindung mit einer Pinnwand nutzt, um die zu erledigenden Aufgaben nicht aus dem Auge zu verlieren (wortwörtlich in dem Fall). Ich fand das so gut, dass ich recht schnell bei eBay unterwegs war und auch ein passendes Angebot gefunden hab, auch die Pläne für eine Software hatte ich ziemlich schnell im Kopf.

Der Drucker

Ich habe mich umgeschaut, was es an Druckern gibt. Bei Kassen sind Geräte von Epson recht weit verbreitet, dementsprechend gibt es hier auch einen guten Gebrauchtmarkt. Ich wollte ein Gerät haben, was halbwegs aktuell ist und auch ans Netzwerk angebunden werden kann (ob LAN oder WLAN war mir egal). Auch musste es von gängigen Bibliotheken für Python (bei mir python-escpos - auch wenn es für dieses spezielle Modell keinen direkten Support gibt; vergleichbare Modelle werden aber unterstützt und andere Profile (ich nutze TM-T20II) funktionieren fehlerfrei).

Gefunden habe ich einen Epson TM-m30II-S. Das ist ein Kassendrucker, der für den Einsatz bei Tabletkassen vorgesehen ist und dementsprechend auf der Oberseite auch eine Halterung für Tablets hat. Die Halterung brauche ich zwar nicht, aber das Angebot war wirklich gut (um die 25€ für ein Gerät in ordentlichem Zustand). Ich hab den dann auch bestellt.

Der Drucker war ein wenig staubig, aber ansonsten einwandfrei. Die “Abnutzung” (also gedruckte Kilometer und Schnittvorgänge) passten zwar nicht zu den Verkäuferangaben, waren aber trotzdem brauchbar - der Käufer hatte angegeben, dass das Gerät keine 5 Bonrollen gedruckt hat, mit 80m-Rollen waren das allerdings eher 35 Rollen. Und knapp 10000 Schnitte. Beides sind aber trotzdem Werte, die vollkommen im Rahmen liegen dürften und eher geringe Nutzung sein dürften. Ich will nicht wissen, wie viele Rollen und Schnitte ein Drucker in einem gut besuchten Supermarkt an der Kasse so auf dem Zähler haben…

An Schnittstellen hat dieses Modell USB, LAN und Bluetooth direkt an Board, über ein (teures) Dongle lässt sich theoretisch auch WLAN nachrüsten. Mir genügt LAN vollkommen bzw. es ist sogar meine bevorzugte Anschlussmethode.

Die Software

Planka

Ich habe mich dazu entschlossen, für die Software keine reine ToDo-Liste, sondern ein Kanban-Board zu nutzen. Die Wahl fiel hierbei auf Planka, da es Open Source ist, OIDC enthalten ist und die API gut beschrieben ist und gute Bibliotheken für Python existieren.

Planka läuft einfach als Docker, der User für den API-Zugriff ist ein normaler, lokaler Benutzer. Ansonsten hat das Board folgende Spalten:

Irgendwann: Für ToDo-Einträge, die noch nicht zu erledigen sind, aber irgendwann gemacht werden sollten/müssen
Zeitnahe: ToDos, die grob in den nächsten 1-2 Wochen zu erledigen sind
Morgen
Heute
In Arbeit
Blocked: Aufgaben, die angefangen oder noch anzufangen sind, die aber noch nicht gemach twerden können. Beispielsweise, wenn noch andere Dinge zu erledigen sind, Teile fehlen oder ich auf Dinge warten muss.
Done: Fertige Aufgaben von heute
Archiv: Ältere fertige Aufgaben

PlankaPrinter

Mein Python-Script sortiert täglich die Tickets. Dabei werden Tickets von Morgen nach Heute verschoben, Termine von Google importiert und in die passenden Spalten (Heute bzw. Morgen) verschoben, Aufgaben mit Zieldatum werden auch automatisch in die passende Spalte verschoben. Alles von Done wird dabei auch ins Archiv verschoben.

Termine

Ich importiere meine Kalender via ICS-URLs, mit einer passenden Library werden auch wiederkehrende Termine korrekt ausgewertet. Termine haben dabei ein eigenes Tag, um sie in der Übersicht direkt erkennen zu können.

Drucken

Die Tickets, die heute zu erledigen sind und noch nicht gedruckt sind, werden an den Drucker geschickt. Bereits gedruckte Aufgaben haben ein Printed-Tag.

Aufwandsschätzungen

Ich habe mir Tags mit geschätzten Zeitaufwänden (XS bis XL) erstellt. Der Tickettitel und die Beschreibung werden an ein lokal betriebenes LLM (konkret gemma3n) geschickt und von diesem der Aufwand geschätzt. Die Schätzungen sind nicht perfekt, aber gehen meistens zumindest in die richtige Richtung. Braucht man wahrscheinlich nicht wirklich, aber ist ein cooles Zusatzfeature.

HomeAssistant-Integration

Die Aktionen (täglicher Durchlauf mit Import, Sortieren und co sowie das Drucken von den Tickets) werden via MQTT von HomeAssistant aus getriggert, damit dies in Abhängigkeit von meiner Anwesenheit zuhause und auch der Tageszeit passieren kann. Via MQTT lassen sich auch direkt Dinge mit Titel und Nachricht drucken, das nutze ich bisher allerdings noch nicht.

Sonstige Features

Ich habe ein kleines Script gebaut, was Bilder ausdrucken kann. Sehr simpel, aber funktioniert. Das muss allerdings noch irgendwie an den Rest mit angebunden werden, da das bisher nur ein eigenständiges Python-Script ist.

Mein Aufbau

Ich habe den Drucker in einem Regal stehen, daneben dann ein Glas für die fertigen Aufgaben und oben drauf die Pinnwand für die aktuellen Aufgaben.

Um die Pinnadeln aufzubewahren, habe ich für die Tablethalterung eine kleine Schlade zum darüberstecken designed und gedruckt. Damit sieht man auch die offenen Metallflächen für die Halterung nicht mehr, was nebenbei auch noch schicker ist.

Der Drucker hängt per LAN am Netzwerk und läuft durchgängig. Der Stromverbrauch liegt tatsächlich nur bei etwas über 1 Watt, also nur etwas mehr als eine WLAN-Steckdose braucht; es lohnt sich also gar nicht, den Drucker abzuschalten bzw. über eine WLAN-Steckdose steuerbar zu machen.

Wie es weitergeht

Ich bin aktuell noch dabei, diverse kleinere Bugs zu beheben, dazu gehört beispielsweise das Erzeugen von neuen Tickets für wiederkehrende Termine - bisher verschiebt die Software dann das bestehende Ticket vom Archiv wieder auf Heute, behält dabei aber das Printed-Tag bei… Ansonsten läuft das meiste ziemlich gut, nur den Code könnte ich noch etwas aufräumen.

Dokumentieren muss ich hier auch noch viel. Aber wer hat auf Doku schon Lust?

Am Ende soll PlankaPrinter irgendwann auch Open Source werden, damit andere sich hier etwas abschauen können oder die Software direkt so einsetzen können.

HP T430 - ein weiterer Thin Client

Sat, 03 May 2025 00:00:00 +0000

Verwendungszweck

Ich habe mittlerweile eine kleine Sammlung an Thin Clients (eine Übersichtsseite mit allen Thin Clients und entsprechenden Beiträgen folgt bei Gelegenheit). Die nutze ich allerdings alle für Zwecke, für die sie nicht gedacht sind. Die meisten (3 von 4) dienen als Server, der letzte ist der Druckserver für meinen 3D-Drucker mit Octoprint. Das ist bei diesem Thin Client nun anders.

Ich habe seit etwa einem halben Jahr einen Lenovo Thinkcentre M715q Tiny als dritten Server im dauerhaft laufenden Homelab, der deutlich mehr Power als die beiden Futro S740 hat. Damit habe ich auch die notwendige Performance, um VMs als normale Desktop-Maschinen zu nutzen (sowohl Linux als auch Windows). Ich habe schon länger je eine VM mit Debian (KDE) und Windows 11, die ich für den Fernzugriff von außerhalb nutze, hauptsächlich über webbasiertes RDP via Guacamole. Das hat sich so auch schon mehrfach bewährt, da ich von jedem Ort der Welt mit einem Browser und Internet an einen Windows-Arbeitsplatz mit meiner gewohnten Ausstattung und Zugriffsmöglichkeiten komme (und dank 2FA und vernünftigen Zugangsdaten auch sicher). RDP habe ich dabei nicht offen am Internet und das ist auch gut so.

Zuhause nutze ich morgens vor der Arbeit, in der Mittagspause und auch nach der Arbeit (und natürlich auch an freien Tagen) viel meinen Desktop-PC, der auf Gaming ausgelegt ist, für leichte Aufgaben wie Mails, Surfen und an meinem Blog schrieben. Dafür ist die Rechenleistung aber eigentlich komplett überflüssig bzw. deutlich überdimensioniert. Die GPU brauche ich dabei natürlich auch nicht. Und mein Desktop verbraucht im fast-Leerlauf um die 80 Watt.

Durch die Arbeit habe ich eine USB-C-Dockingstation, die ich meistens für das Arbeits-Notebook nutze. Die ist über einen KVM-Switch so an meine Monitore und Maus und Tastatur angeschlossen, dass ich mit einem Knopfdruck zwischen Arbeitsrechner und meinem privaten Desktop wechseln kann.

Und an dieser Stelle kommt jetzt der HP T430 ins Spiel. Dieser Thin Client hat im Vergleich zu vielen anderen Thin Clients nämlich die Besonderheit, dass er einen USB-C-Port hat, der neben USB auch Display-Signale und Strom übertragen kann, sich also mit einem einzigen Kabel an einer Docking-Station betreiben lässt.

Damit kann ich also, wenn ich nicht auf viel Rechenleistung angewiesen bin, einfach den Thin Client an die Docking-Station anstecken und habe nach kürzester Zeit eine laufende RDP-Verbindung zu meiner Windows- oder Linux-VM und kann meinen Arbeitsplatz normal nutzen, ohne den großen Desktop in Betrieb zu haben. Und ja, natürlich spielt auch die Neugierde bzw. Spielfaktor da mit rein, hundertprozentig sinnvoll ist das Setup so nicht.

Der HP T430

Der Thin Client ist von den Spezifikationen her nichts überragendes bzw. schwächer als z.B. der Futro S740. Verbaut ist ein Intel Celeron N4020 mit 2x 1,1 GHz, also wirklich nicht viel. Dazu sind 2GB RAM und 16GB eMMC-Speicher verlötet. Heißt, an diesem Gerät ist bis auf das WLAN-Modul absolut nichts austauschbar bzw. erweiterbar. Das sieht man auch auf den Bildern gut.

Die Anschlüsse sind soweit wirklich solide und für so ein Gerät passend, ich hätte mir höchstens noch einen Front-USB gewünscht.

Bilder

Betriebssystem

HP ThinPro OS

Der Thin Client kam mit HP ThinPro OS ausgeliefert. Das ist ein auf Thin Clients ausgelegtes OS auf Linux-Basis (afaik Debian, aber da bin ich mir nicht sicher). Es ist auf den Einsatz in Unternehmen zugeschnitten und bietet damit natürlich auch Möglichkeiten wie zentralem Management. An Fernzugriff ist Citrix, VMware Horizon, RemoteDesktop und weiteres direkt an Board, RDP basiert hierbei auf FreeRDP. Funktioniert hat das ganze gut, war mir allerdings nicht flexibel genug.

Alpine mit XFCE und Remmina

Als nächstes habe ich mit Alpine experimentiert. Das lief soweit auch, nur hatte ich z.B. Probleme mit der Bildschirmanordnung in Remote-Sessions. Auch war mir das Alpine zu unflexibel bzw. zu minimalistisch.

Debian mit XFCE und Remmina

Und so bin ich dann beim guten alten Debian gelandet, auch hier mit XFCE als Desktop und Remmina als Remote-Tool. Das funktioniert soweit gut - und die RDP-Sessions auch flüssiger als mit dem OS von HP. Mit Debian habe ich auch ein OS, womit ich auch außerhalb von Remotezugriff arbeiten kann, auch wenn z.B. Firefox recht langsam ist.

Probleme mit Alpine und Debian

Bei Debian und Alpine hatte ich bei beidem Probleme mit Standby bzw. nach ausgeschaltetem Monitor, die Monitore wieder aufzuwecken. Außerdem wurde beim Booten die GUI nicht immer gestartet, teilweise blieben die Monitore nach dem Übergang zum X-Server schwarz. Der Thin Client lief, via Strg+Alt konnte ich auch zu anderen Terminals wechseln und via CLI arbeiten, aber wirklich zuverlässig war das nicht. Deswegen bin ich jetzt erstmal wieder bei dem OS von HP gelandet, worüber ich auch gerade diesen Absatz schreibe. Generell ist ein großer Teil dieses Posts über den Thin Client entstanden, das geht wirklich gut.

Stromverbrauch

Der Stromverbrauch von dem Gerät ist auf dem Desktop ohne Remote-Session bei etwa 6 Watt, was sehr angenehm ist. Ohne angeschlossene Peripherie sinkt der Verbrauch auf 4 Watt.

Mein kompletter Arbeitsplatz (also Monitore plus Dockingstation plus PC/Thin-Client) verbraucht statt vorher ~170 Watt im leichten Desktop-Betrieb mit Surfen oder leichteren Arbeiten in VSCode jetzt etwas unter 60 Watt, wobei das meiste wahrscheinlich schon auf die Monitore entfällt. Der Heimserver, auf dem die VM läuft, braucht natürlich ein wenig mehr Strom, während ich in der VM arbeite, aber das sind maximal 10 Watt oder so. Insgesamt spart es also gute 100 Watt. Und bei aktuellen Strompreisen von etwa 30 Cent pro kWh müsste ich das Setup 1650 Stunden nutzen, um den Break-Even zu erreichen (fast 70 Tage durchgehend). Realistisch ist das so nicht, wenn wir ehrlich sind. Ich würde sagen, ich nutze das Setup wahrscheinlich maximal 10 Stunden pro Woche, was 165 Wochen bzw. etwas über drei Jahre ergibt. Das geht vom ROI her natürlich noch, aber zeigt trotzdem, dass das Setup so eher mäßig sinnvoll ist.

Aber nicht alles im Homelab muss ja auch komplett sinnvoll sein. Mir gehts dabei eher darum, Erfahrung mit solchen Setups zu machen und mir die Praxistauglichkeit von so einer Lösung mal selbst anzusehen.

Andere Verwendungszwecke

Der nicht erweiterbare RAM und Speicher schränkt natürlich die Nutzung des Geräts für andere Zwecke ein. HomeAssistant oder als kleiner Docker-Host für z.B. Pihole dürfte allerdings gut funktionieren, auch wenn ich es nicht getestet habe. Auch als Printserver für einen 3D-Drucker mit Octoprint dürfte das Gerät eine gute Figur machen. Generell geht alles, was nicht viel Rechenleistung, RAM und Speicher braucht, Linux läuft auf dem T430 problemlos. Für Windows (und generell Einsatz als normaler Desktop) ist die Hardware schlicht zu schwach.

Benchmark

YABS darf natürlich hier auch nicht fehlen. Geekbench 6 lief hierbei aus mir nicht bekannten Gründen nicht durch.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


tc@hp-t430:~$ curl -sL https://yabs.sh | bash -s -- -5 -6 -i
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2025-04-20 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Do 1. Mai 08:59:13 CEST 2025

Basic System Information:
---------------------------------
Uptime : 0 days, 0 hours, 4 minutes
Processor : Intel(R) Celeron(R) N4020 CPU @ 1.10GHz
CPU cores : 2 @ 2186.154 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM : 1.5 GiB
Swap : 977.0 MiB
Disk : 13.4 GiB
Distro : Debian GNU/Linux 12 (bookworm)
Kernel : 6.1.0-34-amd64
VM Type : NONE
IPv4/IPv6 : ✔ Online / ❌ Offline

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mmcblk0p2):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
 ------ | --- ---- | ---- ----
Read | 5.51 MB/s (1.3k) | 8.98 MB/s (140)
Write | 5.53 MB/s (1.3k) | 9.50 MB/s (148)
Total | 11.05 MB/s (2.7k) | 18.49 MB/s (288)
 | |
Block Size | 512k (IOPS) | 1m (IOPS)
 ------ | --- ---- | ---- ----
Read | 9.08 MB/s (17) | 17.53 MB/s (17)
Write | 10.13 MB/s (19) | 18.86 MB/s (18)
Total | 19.22 MB/s (36) | 36.39 MB/s (35)

Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
 |
Single Core | 516
Multi Core | 779
Full Test | https://browser.geekbench.com/v5/cpu/23509544

Geekbench 6 test failed. Run manually to determine cause.

YABS completed in 27 min 5 sec

Upgrades für den zweiten Fujitsu Futro S740

Fri, 07 Mar 2025 00:00:00 +0000

… oder auch: Wie man zwei M.2 2280-SSDs in einem Thin Client verbaut.

Ich habe ja Ende letzten Jahres für meine Nextcloud einen zweiten Fujitsu Futro S740 gekauft. Bislang war dort eine 240GB SSD verbaut, der Speicher wurde allerdings jetzt langsam knapp.

Ich hatte beim ersten S740 ja mit einem Adapter schon den für das Wifi-Modul gedachte Slot für eine NVMe-SSD zweckentfremdet, das funktioniert auch bis heute stabil.

Jetzt steht ein ähnliches Upgrade für den zweiten Futro S740 an.

Die SSD

Ich habe (im Angebot) eine Kingston NV3 mit 1TB gekauft. Eine SSD aus dem unteren Preissegment mit keinen besonderen Leistungswerten, einfach nur brauchbarer Massenspeicher. Durch die Anbindung von dem Port (laut Internet PCIe 2.0 x1, also etwa 500 MB/s) würde eine schnellere SSD hier eh nicht viel bringen und ich habe nicht vor, nennenswert VMs oder ähnliches auf der SSD zu betreiben. Primär werden dort die eigentlichen Daten der Nextcloud liegen.

Das Upgrade

Zuerst habe ich den Futro also heruntergefahren und aufgeschraubt.

Danach habe ich den M.2-Adapter von A/E-Key zu M-Key zugeschnitten und verbaut

Nun war auch schon der Einbau der SSD dran. Dadurch, dass das eigentlich so nicht gedacht ist, gibt es natürlich keine Möglichkeit, die SSD festzuschrauben. Daher habe ich einfach temperaturbeständiges Klebeband verwendet - im anderen Futro S740 funktioniert das seit fast einem Jahr problemlos.

Damit das ganze auch nicht zu warm wird, habe ich noch ein kleines Reststück Kunststoff dazwischen gesetzt, um etwas Abstand zwischen die SSDs zu bringen.

Und ja, das ganze sieht ziemlich nach Bastelei aus und gefällt mir auch nicht zu hundert Prozent - aber es funktioniert wirklich gut.

Der Start danach

Die SSD wurde nach dem Starten nach dem Einbau nicht sofort erkannt. Ich hatte erst den Kontakt selbst im Auge, aber dann ist mir eingefallen, dass ich das Wifi/Bluetooth-Modul im BIOS deaktiviert hatte. Und die SSD sitzt natürlich genau in dem Slot. Nach dem Aktivieren wurde die SSD dann exakt wie erwartet erkannt und hat genau so funktioniert wie sie soll. Die Nextcloud-Daten sind auch schon umgezogen - das war letztendlich nur ein Verschieben der entsprechenden Disk.

Ausblick

Bald müsste auch noch eine weitere SSD ankommen, diesmal eine Sata-SSD für den Mini-PC. Dann gibts auch nen flotten Proxmox Backup Server direkt im Haupt-Lab. Beitrag folgt dann.

Lokale SSL-Zertifikate mit Caddy und Step-CA

Fri, 28 Feb 2025 00:00:00 +0000

Ich habe zuhause zwei Caddy-Instanzen als Reverse-Proxy laufen - einer als Proxy für Traffic von außen (via RZ), einer als Proxy für Traffic innerhalb vom Netzwerk.

Ich nutze eine interne Domain (home.local - ja, ich weiß, .internal wäre besser) für die Dienste, die nicht über das Internet aufrufbar sind. Dafür habe ich auch einen lokalen DNS-Server, der diese Zone bereitstellt.

Was noch fehlte war HTTPS für die internen Dienste, Lets Encrypt oder ähnliches ist dort nicht nutzbar.

Step-CA

Step-CA ist eine selbst betreibbare Zertifizierungsstelle, die u.a. ACME kann. ACME ist das selbe “Protokoll”, was auch Lets Encrypt zur Verifizierung von Hosts und der Ausstellung von Zertifikaten benutzt. Das ganze ist ziemlich flott eingerichtet und lässt sich dann simpel an Clients wie Certbot oder auch Caddy anbinden und damit automatisch Zertifikate ausstellen. Das einzige manuelle ist, dass man auf allen Computern (und Smartphones und co), die diese lokalen Dienste nutzen sollen, natürlich das Root-Zertifikat der Step-CA installieren muss, damit die Zertifikate auch akzeptiert werden.

Meine Docker-Compose dafür sieht sehr simpel aus:

1
2
3
4
5
6
7
8


services:
 step-ca:
 image: smallstep/step-ca
 restart: always
 ports:
 - 9443:9443
 volumes:
 - ./data:/home/step

Vor dem ersten Start muss die CA noch initialisiert werden. Dazu muss das Datenverzeichnis erstellt und die Berechtigungen angepasst werden:

1
2
3


mkdir data
chown -R 1000:1000 data/
docker run --rm -it -v "./data/:/home/step/" smallstep/step-ca step ca init

Der Assistent führt einen nun durch die notwendigen Schritte. Dann muss noch ein Secret angelegt werden:

1
2


echo blub | tee "data/secrets/password"
chown 1000:1000 data/secrets/password

Jetzt kann die CA schon gestartet werden und danach ACME aktiviert werden:

1
2
3
4


docker compose up -d
# kurz warten
docker compose exec step-ca step ca provisioner add acme --type ACME
docker compose restart

Das Root-CA, was auf den Clients verteilt werden muss, befindet sich unter data/certs/root_ca.crt.

Caddy

Die CA kann nun also Zertifikate ausstellen und muss nur noch an Caddy angebunden werden. Eine globale CA in der Caddyfile lässt sich dafür leider nicht nutzen, dieser Mechanismus ist laut Dokumentation von Caddy nicht für interne Domains freigegeben bzw. funktioniert damit nicht. Daher habe ich die für die lokale CA notwendige Konfiguration als Snippet angelegt:

1
2
3
4
5
6


(local-ca) {
 tls me@example.com {
 ca https://stepca.home.local:9443/acme/acme/directory
 ca_root /etc/caddy/root_ca.crt
 }
}

Das Root-CA habe ich, wie in der Config sichtbar, unter /etc/caddy/root_ca.crt abgelegt.

Nun lassen sich Reverse-Proxy-Hosts anlegen, die dieses Snippet verwenden und damit automatisch Zertifikate einrichten:

1
2
3
4
5


# Stirling-PDF
pdf.apps.home.local {
 import local-ca
 reverse_proxy http://192.168.104.46:8081
}

Oder im Falle von Proxmox vorerst mit Ignorieren der Korrektheit des vom PVE-Hosts genutzten Zertifikates (solange, bis ich bei PVE ACME mit der lokalen CA noch nicht eingerichtet habe):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Proxmox
pve.apps.home.local {
 import local-ca
 reverse_proxy https://192.168.103.2:8006 {
 transport http {
 tls
 tls_insecure_skip_verify
 }
 }
}

Das sieht in Fertig im Browser dann so aus:

Windows

Damit Windows diesem Zertifikat vertraut, muss das CA noch installiert werden. Dazu reicht es, die .ca-Datei mit Doppelklick zu öffnen und zu installieren. Danach muss das Zertifikat noch als Vertrauenswürdig eingestuft werden. Dazu kann man im Startmenü nach “Zertifikat” suchen und - je nachdem, wie man es installiert hat - die Verwaltung für Benutzer- oder Computerzertifikate öffnen. Das neue Zertifikat liegt dann wahrscheinlich unter Zwischenzertifizierungsstellen/Zertifikat und muss nur noch zu Vertrauenswürdige Stammzertifizierungsstellen/Zertifikate verschoben werden. Nach einem Neustart vom Browser sollte der Aufruf lokaler Subdomains mit SSL nun fehlerfrei funktionieren.

Lenovo ThinkCentre M715q Tiny - Upgrades

Tue, 25 Feb 2025 00:00:00 +0000

Mein ThinkCentre M715q hatte bisher 12 GB RAM, bestehend aus 4 GB + 8 GB – also ohne Dual-Channel und insgesamt recht wenig Speicher. Daher habe ich mir neuen RAM zugelegt: ein 32 GB-Kit von Timetec (2×16 GB, 2666 MHz, CL19). Die Wahl fiel auf 2666 MHz, da dies das Maximum ist, das der Mini-PC unterstützt.

Neben dem RAM wurde auch die 1 TB-HDD durch eine 500 GB SATA-SSD (Crucial MX500, die zuvor in einem anderen Gerät verbaut war) ersetzt. Dadurch erhalte ich auch dort bessere Performance, den zusätzlichen Speicherplatz benötige ich nicht

Benchmarks

Ich war davon ausgegangen, dass ich durch den Umstieg auf Dual-Channel Performance gewinne, der Unterschied ist jedoch deutlicher als gedacht.

	Vorher	Nachher
Geekbench 5 (Single-Core)	890	946 (+6%)
Geekbench 5 (Multi-Core)	2380	3075 (+29%)
Geekbench 6 (Single-Core)	1000	1074 (+7%)
Geekbench 6 (Multi-Core)	2494	3066 (+23%)

Die Single-Core-Werte sind etwa wie erwartet, ich hatte mit ~5-10% generellen Performanceverbesserungen gerechnet. Die Multi-Core-Werte mit +29% bzw. +23% wiederum haben mich erstaunt. Ich habe spaßeshalber noch einen Durchlauf mit dem Kernelparameter mitigations=off gemacht (deaktiviert Mitigations für Dinge wie Spectre oder Meltdown), das hat allerdings keinen nennenswerten Unterschied gemacht. Was auch daran liegt, dass es eine AMD-CPU und keine Intel-CPU ist.

Hinweis: Bei den Benchmarks wurde jeweils nur ein einzelner Durchlauf durchgeführt, es wurde also nicht über mehrere Messungen gemittelt.

Was ich mit den Ressourcen mache

Vor allem kann ich dank des zusätzlichen RAMs jetzt Ollama mit Modellen bis ca 15 Milliarden Parametern ausführen, wenn auch langsam. Modelle mit 7 Milliarden Parametern sind tatsächlich halbwegs nutzbar, allerdings weiterhin nicht sonderlich schnell.

Natürlich passen so auch allgemein mehr VMs und Container auf den Mini-PC, ich habe beispielsweise jetzt eine Windows-VM, die ich über HomeAssistant starten und stoppen kann. Das ermöglicht mir in Verbindung mit Guacamole (webbasierter RDP-Client) Zugang zu einer (bzw. meiner) Windows-VM von jedem beliebigen Computer mit Internet und einem Webbrowser, was sich als durchaus praktisch erweisen könnte.

Lenovo ThinkCentre M715q Tiny - mein neuer MC-Server

Mon, 16 Dec 2024 00:00:00 +0000

Ich habe mir vor ein paar Wochen einen Mini-PC, genauer gesagt einen Lenovo ThinkCentre M715q Tiny gekauft.

Wofür?

Mein Minecraft-Server läuft nun seit bald 5 Jahre durchgängig. Ursprünglich auf freien Ressourcen eines Dedicated Servers, zwischenzeitlich an verschiedenen anderen Orten und seit fast einem Jahr auf einem 1€-Angebots-vServer von 1blu. Dieses Angebot gibt es so aber anscheinend nicht mehr (und der vServer ist mit 8GB RAM ehrlich gesagt eigentlich auch zu klein dimensioniert), wodurch ich eine neue Lösung brauchte.

Hauptsächlich war tatsächlich der Preis ausschlaggebend für den Umzug des MC-Servers zu mir nach Hause - neben den einmaligen Anschaffungskosten sind hier eigentlich nur die Stromkosten zu nennen. Ein ausreichend starker vServer hätte mich vermutlich um die 10€ pro Monat gekostet, der Mini-PC kostet mich jetzt grob 3€ pro Monat an Strom.

Wenn man die Differenz zu einem vServer mit den Anschaffungskosten (im Angebot jetzt gut 90€ plus ~20€ für eine 240GB NVMe-SSD) vergleicht, ist der Mini-PC ab etwa 1,5 Jahren Betrieb insgesamt günstiger gewesen. Und das ist ausreichend kurz.

Die Hardware

Der M715q hat bei mir nun folgende Ausstattung:

AMD Ryzen 5 2400GE (4 Cores, 8 Threads)
12GB RAM (ausgeliefert mit 2x 4GB, ich hatte noch 8GB liegen)
240GB NVMe-SSD

Die SSD ist eine Patriot P310 mit 240GB, das war das günstigste brauchbare Modell, was ich so finden konnte. Die Performance macht einen guten Eindruck bislang, wobei hochwertigere SSDs mit Sicherheit deutlich besser sind.

Neben dem M.2-Slot hat der Mini-PC auch die Möglichkeit, ein 2,5-Zoll SATA-Gerät aufzunehmen, aktuell habe ich da eine 1TB HDD verbaut, die ich noch herumliegen hatte. Ich habe vor, die HDD durch eine 1-2TB SATA SSD zu ersetzen und den RAM irgendwann auf 32GB aufzurüsten.

Die Software

Wie alles andere auch läuft der Mini-PC bei mir mit Proxmox. Das ließ sich problemlos installieren und funktioniert einwandfrei. Viel mehr gibt es dazu eigentlich nicht zu sagen.

Stromverbrauch

Im Idle habe ich teilweise schon Werte unter 10W gesehen. Mit dem Minecraft-Server im Leerlauf und einigen weiteren Anwendungen liegt der M715q bei mir die meiste Zeit zwischen 10 und 15 Watt. Mit aktiven Spielern oder generell unter Last geht der Verbrauch teilweise auch auf 40-50 Watt hoch.

Das sind vermutlich ein paar Watt mehr als Geräte mit vergleichbaren Intel-CPUs aus dem Zeitraum verbrauchen würden, aber trotzdem ein guter Wert. Dieses Gerät ist vor allem deutlich günstiger als Mini-PCs mit Intel i5 8. oder 9. Generation und dabei von der Single-Core-Performance her sogar noch etwas stärker.

Der Lüfter ist im Leerlauf nur bei absoluter Stille ein wenig zu hören, unter Last klingt der Rechner ähnlich wie ein Notebook unter Last und ist deutlich hörbar.

Benchmark

Zum Abschluss hier noch das Ergebnis von YABS:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


root@host3:~# curl -sL yabs.sh | bash -s -- -5 -6 -r
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2024-06-09 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Thu Nov 28 02:53:32 PM CET 2024

Basic System Information:
---------------------------------
Uptime : 0 days, 0 hours, 6 minutes
Processor : AMD Ryzen 5 2400GE with Radeon Vega Graphics
CPU cores : 8 @ 1600.000 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 10.6 GiB
Swap : 3.7 GiB
Disk : 19.1 GiB
Distro : Debian GNU/Linux 12 (bookworm)
Kernel : 6.8.12-4-pve
VM Type : NONE
IPv4/IPv6 : ✔ Online / ❌ Offline

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mapper/vg1-root):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
 ------ | --- ---- | ---- ----
Read | 199.16 MB/s (49.7k) | 552.76 MB/s (8.6k)
Write | 199.68 MB/s (49.9k) | 555.67 MB/s (8.6k)
Total | 398.84 MB/s (99.7k) | 1.10 GB/s (17.3k)
 | |
Block Size | 512k (IOPS) | 1m (IOPS)
 ------ | --- ---- | ---- ----
Read | 761.70 MB/s (1.4k) | 810.20 MB/s (791)
Write | 802.17 MB/s (1.5k) | 864.16 MB/s (843)
Total | 1.56 GB/s (3.0k) | 1.67 GB/s (1.6k)

iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 53.6 Mbits/sec | 107 Mbits/sec | 45.1 ms
Leaseweb | Singapore, SG (10G) | 45.1 Mbits/sec | busy | 183 ms
Leaseweb | NYC, NY, US (10G) | 51.5 Mbits/sec | 98.5 Mbits/sec | 117 ms

Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
 |
Single Core | 938
Multi Core | 2862
Full Test | https://browser.geekbench.com/v5/cpu/23105065

Geekbench 6 Benchmark Test:
---------------------------------
Test | Value
 |
Single Core | 1069
Multi Core | 2833
Full Test | https://browser.geekbench.com/v6/cpu/9120078

YABS completed in 13 min 3 sec

Minecraft - mein Setup

Ich habe in einem LXC-Container (ja, das C ist eigentlich doppelt gemoppelt) Docker und Pterodactyl installiert. Damit kann ich die Gameserver bequem per Webinterface verwalten. Ich habe keine direkte Portfreigabe für den Minecraft-Server gemacht. Der Traffic geht erstmal ins Rechenzentrum und erreicht dort einen Velocity-Proxy. Von dort führt ein Wireguard-Tunnel zu meinem Router nach Hause, der dann die Spieldaten entsprechend zum Container auf dem Mini-PC leitet. Das Setup hat den Vorteil, dass ich einerseits meine Heim-IP nicht preisgebe, andererseits möglichen Peering-Problemen aus dem Weg gehe und den MC-Server auch problemlos und schnell (und ohne DNS-Änderungen) umziehen kann. Ich muss nach einem Umzug nur im Proxy eine neue IP hinterlegen und bin fertig. Die Dynmap hängt auch hinter einem Reverse-Proxy im Rechenzentrum und funktioniert auf dem selben Weg.

Fazit

Mir gefällt der kleine Rechner ziemlich gut, vor allem bei dem Preis. Vermutlich hätte ich mir den Kauf vom zweiten Futro S740 sparen können, das hätte problemlos mit auf diesen M715q gepasst. Aber egal, jetzt ist es so.

Die Performance ist wirklich gut, vor allem für den geringen Preis (auch im Vergleich zu den Intel-Modellen). Für einen (oder auch mehrere) Minecraft-Server ist die Kiste eine klare Empfehlung und erlaubt günstigen Betrieb von einem Minecraft-Server zuhause.

Der zweite Fujitsu Futro S740

Sat, 19 Oct 2024 00:00:00 +0000

Warum ein zweiter Thin Client?

Ich bin bekanntlich von meinem bisherigen Homeserver, einem Fujitsu Futro S740 ziemlich überzeugt, vor allem wenn es um Dinge wie Effizienz geht.

Warum ein zweiter Futro S740 und kein anderer Mini-PC? Ganz einfach: Der erste hat mich bereits überzeugt. Der kleine Thin Client lässt sich super als Homeserver nutzen. Der Prozessor (Intel Celeron J4105, 4 Kerne, bis zu 2,5 GHz), 4 GB RAM (aufrüstbar auf 16 GB) und mehrere Möglichkeiten für SSDs bieten genug Leistung für diverse Selfhosting-Projekte. Dazu kommt ein extrem niedriger Stromverbrauch – im Normalbetrieb gerade mal ein paar Watt. Und selbst zwei von den Futros zusammen verbrauchen weniger als die meisten anderen Mini-PCs alleine.

Da ich nun überlege, meine Nextcloud zuhause zu betreiben brauche ich etwas mehr Power als der eine Thin Client liefern kann. Aktuell laufen - inkl. Nextcloud - 1 VM und 19 LXC-Container. Das meiste davon ist normalerweise im Idle, aber z.B. der LXC für ADS-B braucht dauerhaft 10-20% CPU. Auch andere Software braucht immer mal wieder Rechenleistung, weshalb die durchschnittliche Auslastung vom Server mittlerweile bei 30-40% liegt (RAM bei 10,5 von 16 GB, Load Average meistens bei um die 2). Ich habe also zu wenig Rechenleistung. Das Problem lässt sich jetzt entweder durch Upgraden der bisherigen Hardware (was ein Austausch wäre, bei den Thin Clients lassen sich die CPUs natürlich nicht tauschen) oder durch Hinzufügen eines zweiten Servers lösen.

Der Kauf

Ich habe mich hierbei für die zweite Option entschieden und einen zweiten S740 gekauft. Wie letztes Mal habe ich wieder bei Piospartslab (piospartslap.de) gekauft, hier war der Preis durch einen Preisvorschlag meinerseits bei etwa 50 €.

Bilder

Ich habe letztes Mal wenig Bilder vom Futro gemacht, daher hole ich das hier mal nach.

Setup

Bevor ich mit der OS-Installation begonnen habe, habe ich erstmal das BIOS aktualisiert. Details dazu finden sich in einem Doku-Github-Repo zum S740 hier: https://github.com/R3NE07/Futro-S740. Die SSD habe ich gegen eine 240 GB M.2 SATA-SSD getauscht. Leider hatte ich keine M.2 2242 SSD mehr, deswegen wurde es erstmal eine 2280. Auf Dauer werde ich auch für den zweiten Futro einen M.2 Adapter kaufen, mit dem man eine normale NVMe-SSD in den Slot für eine WLAN-Karte stecken kann.

Auf dem ersten Futro läuft schon Proxmox, deswegen habe ich das auf dem zweiten auch installiert und beide zu einem Cluster zusammengefügt. Ich gewinne damit zwar keine Vorteile was Verfügbarkeit bzw. Redundanz angeht, aber ich kann beide Server über eine Oberfläche verwalten und auch VMs bzw. Container simpel zwischen beiden Servern migrieren. Dementsprechend habe ich nach der Installation auch direkt Nextcloud und einige weitere Dinge auf den zweiten Futro übertragen, um die Last zu verteilen.

Fazit

Für alle, die sich einen günstigen und leistungsstarken Homeserver zulegen möchten, kann ich den Futro S740 weiterhin nur empfehlen. Zusammen mit Proxmox hast du eine extrem vielseitige Virtualisierungsumgebung, die mit wenig Strom und Platzbedarf eine Menge Power unter der Haube hat.

YABS

Zum Abschluss habe ich hier noch einmal ein Ergebnis von YABS angefügt. Die SSD ist allerdings das mitgelieferte 8GB-SATA-SSD-Modul gewesen, weshalb die Storage-Ergebnisse eher schlecht ausgefallen sind.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


root@debian:~# curl -sL yabs.sh | bash -s -- -r -5 -6
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2024-06-09 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Wed Oct 16 02:34:15 PM CEST 2024

Basic System Information:
---------------------------------
Uptime : 0 days, 0 hours, 22 minutes
Processor : Intel(R) Celeron(R) J4105 CPU @ 1.50GHz
CPU cores : 4 @ 1996.811 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 3.6 GiB
Swap : 980.0 MiB
Disk : 6.3 GiB
Distro : Debian GNU/Linux 12 (bookworm)
Kernel : 6.1.0-26-amd64
VM Type : NONE
IPv4/IPv6 : ✔ Online / ❌ Offline

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mapper/debian--vg-root):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
 ------ | --- ---- | ---- ----
Read | 13.13 MB/s (3.2k) | 19.48 MB/s (304)
Write | 13.12 MB/s (3.2k) | 20.04 MB/s (313)
Total | 26.25 MB/s (6.5k) | 39.52 MB/s (617)
 | |
Block Size | 512k (IOPS) | 1m (IOPS)
 ------ | --- ---- | ---- ----
Read | 20.78 MB/s (40) | 20.82 MB/s (20)
Write | 22.35 MB/s (43) | 23.01 MB/s (22)
Total | 43.14 MB/s (83) | 43.84 MB/s (42)

iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 53.7 Mbits/sec | 92.1 Mbits/sec | 35.7 ms
Leaseweb | Singapore, SG (10G) | 44.8 Mbits/sec | 69.8 Mbits/sec | 197 ms
Leaseweb | NYC, NY, US (10G) | 50.3 Mbits/sec | 58.9 Mbits/sec | 97.2 ms

Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
 |
Single Core | 463
Multi Core | 1485
Full Test | https://browser.geekbench.com/v5/cpu/22967867

Geekbench 6 Benchmark Test:
---------------------------------
Test | Value
 |
Single Core | 384
Multi Core | 1139
Full Test | https://browser.geekbench.com/v6/cpu/8337911

YABS completed in 25 min 40 sec

Der erste Link mit 2.5GBit/s

Mon, 07 Oct 2024 00:00:00 +0000

Ich habe mir kürzlich zwei günstige PCIe-Netzwerkkarten mit Realtek RTL8125B Chips bestellt. Ich wollte damit eine direkte Verbindung zwischen meinem PC und meinem NAS herstellen, um schneller größere Datenmengen von A nach B zu bekommen. Das hilft ohne Switch natürlich dem Rest des Netzwerks nicht, aber der genannte Weg ist der, auf dem ich so mit die meisten Daten übertrage.

Ich habe die Karten also in meinen PC und das NAS eingebaut, ein Kabel verlegt und angeschlossen und die beiden Geräte wieder gebootet. Beide Rechner haben die Karte jeweils direkt erkannt, ich musste also nur noch IPs vergeben (anderer Adressbereich als das Heimnetz, damit sich da nichts in die Quere kommt). Danach konnte ich schon das Netzlaufwerk einrichten und die ersten Daten kopieren - mit über 280MB/s in meinen ersten Tests. Das ist ordentlich und mit knapp 2,3 GBit/s nahe an der theoretischen Kapazität der Leitung.

Ich gebe zu, das ganze war jetzt wirklich unspektakulär und funktioniert einfach direkt out-of-the-box. Ich hatte mir ein wenig mehr Spielerei erhofft, aber naja, eigentlich besser so.

Irgendwann wird sicherlich auch noch ein kleiner Switch folgen, der mehr als 1GBit/s kann, da warte ich aber noch auf Modelle zu brauchbaren Preisen mit genügend Ports und am besten noch Support für VLANs. Mehr oder weniger also den perfekten Switch für ein leicht überdurchschnittliches Heimnetz.

Upgrades für den Futro S740

Fri, 26 Apr 2024 00:00:00 +0000

Der Fujitsu Futro S740 verrichtet nun seit über einem Jahr brav seine Dienste als mein Heimserver, mittlerweile sind mir die 4GB RAM allerdings deutlich zu wenig (ach was, wer hätte es gedacht). Auch die 240GB Speicherplatz stören mich mittlerweile.

Daher war nun Zeit für ein Upgrade. Das Maximum, was an RAM funktionieren soll, sind 16GB. Bei so großen Modulen muss man sehr genau aufpassen - laut den “Community-Dokus” bei Github ( https://github.com/R3NE07/Futro-S740 ) muss es zwingend Dual Rank sein. Ich habe hierbei einen Stick von Integral (IN4V16GNDLRI) gekauft, da es einer der wenigen Sticks war, wo ich konkret herausfinden konnte, dass es sich um Dual Rank handelt. Wenn man beispielsweise 16GB-Module von Crucial bei Amazon kauft, ist nicht klar, welches exakte Modell man bekommt und ob es Dual oder Single Rank RAM ist. Mit Single Rank Modulen startet der Thin Client laut meinen Recherchen überhaupt nicht.

Zusätzlich habe ich auch noch eine weitere SSD verbaut, dafür habe ich einen M.2-Adapter von A/E-Key zu M-Key günstig gekauft. Ich hatte noch eine Kioxia Exceria G2 mit 500GB liegen, die ist zwar nicht die beste, aber für die Zwecke definitiv ausreichend. Da die SSD eine 2280 SSD ist, musste ich beim Befestigen etwas kreativ werden, vielleicht füge ich irgendwann noch mal ein Bild davon an.

Nachdem alles verbaut war, habe ich den S740 wieder eingeschaltet und nach dem Hochfahren habe ich das gewünschte Ergebnis gesehen:

Sowohl RAM als auch SSD wurden problemlos erkannt und funktionieren wie erwartet. Die SSD kann ihre volle Geschwindigkeit durch die Bandbreite von dem Port (laut Internet PCIe 2.0 x1, also etwa 500 MB/s) zwar längst nicht voll ausnutzen, aber die niedrigeren Latenzen im Vergleich zu SATA merkt man dennoch ein wenig. Aber alleine für den zusätzlichen Storage (insgesamt jetzt immerhin ~750 GB) hat es sich gelohnt.

Ich habe vor, auf dem Thin Client nun mehr zu betreiben, unter anderem liegt hier Hardware für den ADS-B-Empfang. Mal gucken, wann ich dazu komme, dazu etwas zu schreiben.

Mein neuer Server (HP DL360p G8)

Mon, 18 Dec 2023 00:00:00 +0000

Dank eines freundlichen Arbeitskollegen habe ich nun einen neuen Server im Keller stehen, einen HP DL360p G8. Die Specs:

2x Xeon E5 2670 v2 (je 10 Kerne/20 Threads mit 2,5GHz)
96 GB RAM
2x 146 GB SAS Festplatte (Proxmox)
1x 500 GB NVME-SSD (VMs)
Dual 10 GBit/s Netzwerkkarte

Der Server läuft, wie üblich, mir Proxmox und wird primär Aufgaben wie Encoding, Betrieb von diversen VMs parallel oder Experimente mit Deep-Learning übernehmen. Dauerhaft laufen wird das Teil aufgrund des Stromverbrauchs natürlich nicht. Die Single-Core-Performance ist aufgrund des Alters nicht ganz auf Höhe der Zeit, aber durch die 20 Kerne bzw. 40 Threads wird das für die meisten Aufgaben gut ausgeglichen. Generell ist der Server eine gute Spielwiese, da auch mehrere VMs parallel sich nicht in die Quere kommen und genug Leistung abrufen können.

TS3-Server günstig zuhause hosten

Wed, 18 Oct 2023 00:00:00 +0000

Mittlerweile sind verschiedene Thin-Client-Modelle (beispielsweise Fujitsu Futro S740, S720, S520, …) zu günstigen Preisen erhältlich, teilweise für unter 20 € - manchmal sogar für 15 € und weniger. Die Prozessoren (z.B. im S720 und S520) sind allerdings schwach, was den Einsatzzweck einschränkt. Netterweise braucht TeamSpeak3 wenig Ressourcen und ist im Vergleich zu anderen Services auch nicht direkt kompatibel mit ARM-Prozessoren.

Der Stromverbrauch von den Thin Clients ist ziemlich gering, je nach Modell nur wenige Watt. Damit ist das ganze auch zu sehr günstigen Konditionen (bei 5 Watt und 30 Cent pro kWh entspräche das Stormkosten von etwas über einem Euro pro Monat) zu betreiben. Teamspeak erlaubt den Betrieb eines Servers ohne Lizenz mit bis zu 32 Slots, was für viele Zwecke genügt. Klar ist die Internetanbindung zu Hause für den Serverbetrieb nicht optimal, aber für einen kleinen Server mit Freunden genügt so etwas. Dafür sind selbstverständlich Portfreigaben notwendig, welche Ports das sind steht weiter unten. Konkrete Anleitungen werde ich hier generell in diesem Post nicht nennen, da das meiste davon nicht weiter schwer ist.

Für ein kleines Beispiel nutze ich einen Futro S520, das schwächste der genannten Modelle. Als OS nutze ich hier Debian 12 ohne GUI, darauf habe ich dann mit meinem eigenen Script den TS3-Server installiert. Nach der Installation habe ich mich mit dem TS3-Server verbunden und mit einer einfachen WLAN-Steckdose den Verbrauch gemessen. Ohne weitere angeschlossene Geräte (nur LAN und Strom verbunden) liegt der Verbrauch bei angenehm niedrigen 5 Watt. Ein Futro S740 liegt hier noch etwas niedriger, aber kostet auch ein mehrfaches vom S520.

An Ports müssen für TS3 folgende freigebene werden:

Port 9987 UDP, Standard-Voice-Port
Port 30033 TCP, Filetransfer (optional)
Port 10011 TCP, Server-Query (optional)

Für den “Produktivbetrieb” sollte natürlich noch DynDNS eingesetzt werden, da sich zuhause die IP in gewissen Abständen ändern kann. Hierzu gibt es viele Anbieter am Markt, wer DNS über Cloudflare und co verwaltet, findet auch dafür passende DynDNS-Scripte.

Aber ergibt das ganze überhaupt Sinn?

Das kommt natürlich immer darauf an. Für das Geld, was der Thin Client durch den Stromverbrauch kostet, bekommt man bei einigen Anbietern schon kleine vServer, die dann im Rechenzentrum mit entsprechender Anbindung und Hardware betrieben werden, was natürlich für eine höhere Stabilität sorgt. Ich finde hier aber den Lern- und Spaßfaktor wichtig. Ein Homelab bzw. genereller Betrieb von Services zuhause muss nicht immer (wirtschaftlich) sinnvoll sein. Dieses kleine Beispiel enthält schon viele wichtige grundlegende Elemente wie die Installation vom Betriebsssystem, Installation von Software und auch die Bereitstellung der Services von Außen mit Dyndns und Portfreigaben.

Homelab im Keller

Tue, 03 Oct 2023 00:00:00 +0000

Mein Homelab hat mittlerweile viele Revisionen in verschiedenen Wohnungen hinter sich. Angefangen in einem Abstellraum bei meinen Eltern, über einen Server im Studentenwohnheim hinter einem Regal, mehrere Jahre eine Ecke in einer anderen Wohnung, dann die Minimierung bei bzw. vor dem Umzug in die jetzige Wohnung und nun die erneute Erweiterung in Richtung Keller.

Hintergrund für den Umzug in den Keller ist, dass im Arbeitszimmer bzw. generell in der Wohnung einfach der Platz fehlt und auch der Wärme-Output und die Geräuschkulisse durchaus nerven kann. Um dem entgegenzuwirken habe ich vor kurzem beschlossen, mein Lab in den Keller zu verlegen.

Internet/Netzwerkverbindung

Die einzige Möglichkeit, um Internet bzw. generell eine Netzwerkverbindung in den Keller zu bekommen, ist Powerline. Die Betonwände verhindern jegliche Funkverbindungen und andere Leitungen außer Strom gibt es leider nicht. Bisher hatte ich alte Adapter benutzt, Internet im Keller war nur für einen kleinen AP für eine WLAN-Steckdose notwendig. Die Bandbreite lag bei etwa 10 MBit/s - für den bisherigen Zweck mehr als genug. Für die Nutzung als Homelab allerdings deutlich zu wenig. Mit moderneren Powerline-Adaptern habe ich das nun auf ca. 70 MBit/s anheben können. Immer noch nicht überragend, aber ausreichend. Am liebsten wäre mir ein Leerrohr von der Wohnung in den Keller gewesen, damit hätte ich dort dann ein Glasfaserkabel verlegt, um 1G oder 10G zum Keller zu haben. Dann hätte auch das NAS mit in den Keller ziehen können, das ist aufgrund der geringen Bandbreite jetzt so nicht möglich.

Mit der nun brauchbaren Netzwerkanbindung war die Voraussetzung für den Betrieb im Keller erfüllt.

Hardware

Vorläufig bleibt es weitestgehend bei schon vorhandener Hardware. Dazu gehört:

TP-Link 24 Port Gigabit Switch (mit VLAN-Support)
Futro S720 (Storage), siehe hier
pve2 (Supermicro-Board, i5, 32GB RAM)
Notebook (Ryzen 3, 8GB RAM) - aktuell ungenutzt

Das ist erstmal nicht viel, aber ein Anfang. Geplant ist, dass eine weitere Maschine mit mehr Rechenleistung noch dazu kommt. Möglicherweise schaffe ich mir auch noch einen Server mit höherer Taktrate auf Ryzen-Basis an, aber dazu gibt es keinerlei konkrete Zeitpläne.

Kommen wir zum relevanten Part - ein Bild vom aktuellen Stand.

Weitere Pläne

Neben dem zusätzlichen Server habe ich erst einmal wenig Pläne für das Lab. Ich möchte hauptsächlich alles etwas ordentlicher gestalten und VMs einrichten. Möglicherweise folgt noch ein Router (Mikrotik), um Routing zwischen Netzen im Homelab machen zu können, ohne dass der Traffic zweimal durch die Powerline-Strecke muss. Außerdem habe ich noch einen Temperatursensor bestellt, der in Verbindung mit einem ESP dann die Raumtemperatur und Luftfeuchte überwachen soll. Vielleicht folgt auch noch eine Kamera, damit ich jederzeit sehen kann, ob alles korrekt arbeitet (und nichts raucht).

Das Netzwerk auf mehr als 1G zu upgraden lohnt sich aktuell nicht bzw. dafür fehlt bislang die Notwendigkeit. Solange bleibt es bei 1G.

Futro S720

Sat, 23 Sep 2023 00:00:00 +0000

Seit nun etwas über einem halben Jahr ist ein Fujitsu Futro S740 der Hauptserver in meiner Wohnung und verrichtet zuverlässig seinen Dienst. Zurzeit arbeite ich daran, mein Homelab aus dem Arbeitszimmer in den Keller zu verlegen. Dazu wollte ich gerne einen kleinen Server als Shared Storage für Dinge wie OS-ISOs, VM-Templates, Backups und generelle Datenablage haben. Das ganze auch als getrenntes Gerät mit geringem Stromverbrauch, damit ich diesen Storage-Server unabhängig von anderen Servern im Lab benutzen kann.

Nach kurzer Recherche fiel meine Wahl auf den Futro S720. Im Vergleich zum S740 ist hier ein AMD GX-217GA drin - ein Dual-Core mit 1,65 GHz. Die CPU hat grob ein Viertel der Leistung vom Intel Celeron J4105 aus dem S740, als Storage-Server ohne nennenswerte weitere Aufgaben genügt das aber. Das für mich relevante Argument war der (halb unter dem Kühlkörper versteckte) SATA-Anschluss für eine HDD/SSD.

Mein Gerät kam mit 8 GB SSD-Speicher sowie 2 GB RAM (DDR3). Nicht viel, aber reicht. Mit einem passenden Adapterkabel, um aus einem USB-Header ein Stromkabel für SATA zu machen, passt damit ein 2,5-Zoll Laufwerk gut mit in das Gehäuse. In meinem Fall eine Festplatte mit 640 GB, die ich noch liegen hatte. Der Stromverbrauch vom S720 (inkl. der HDD) liegt bei mir im Idle bei etwa 6 Watt, unter Last inkl. HDD-Aktivität etwas über 10 Watt. Dafür, dass das Teil nicht dauerhaft laufen wird, ist das mehr als in Ordnung. Mit Samba schaffe ich zur Festplatte konstant etwa 80 MB/s ohne weitere Optimierungen, auch das ist genug.

Dieser Post ist mehr oder weniger der Anfang vom “Neuaufbau” meines Homelabs im Keller. Sicherlich werden in naher Zukunft noch weitere Posts folgen, irgendwann werde ich dann auch die Übersichtsseite über mein Lab plus Netzwerkdiagramm entsprechend aktualisieren.

NAS-Upgrade

Tue, 23 May 2023 00:00:00 +0000

Mein NAS hat seine Kapazitätsgrenze von aktuell 9 TB (4x 3 TB, davon 1x 3 TB Parity) mittlerweile fast erreicht. Daher habe ich mich dazu entschieden, eine weitere Festplatte hinzuzufügen. Um später größere Datenplatten nachschieben zu können, fiel die Wahl hierbei auf eine 4 TB Seagate Ironwolf. Ich habe damit die bisherige Parity-Festplatte ersetzt und die bisherige Parity-Festplatte dem Array als Datenplatte hinzugefügt. Damit komme ich nun auf 12 TB nutzbare Kapazität. 1 TB habe ich damit jetzt mehr oder weniger verschwendet bzw. nutze ihn nicht, aber ich kann jederzeit weitere Festplatten mit bis zu 4 TB dem Array hinzufügen.

Mein neuer Homeserver (Fujitsu Futro S740)

Mon, 20 Feb 2023 00:00:00 +0000

Im letzten Update zu meinem Homelab sprach ich davon, den Raspberry Pi gegen etwas Leistungsstärkeres zu ersetzen, genauer gesagt durch einen Thin Client. Viele im Internet empfehlen hierbei den Fujitsu Futro S740 Thin Client, also habe ich mich darüber genauer informiert. Ein Intel Celeron J4105 (4 Kerne mit je max. 1,5 GHz), 4 GB RAM (aufrüstbar auf 16 GB) und 16 GB eMMC-Storage (eine normale 2242 M.2 SATA-SSD) in einem kleinen Gehäuse, passiv gekühlt und mit geringem Stromverbrauch klang wirklich interessant. Also habe ich mir so ein Teil mal bestellt. SSD (240GB M.2 SATA von Transcend, eine TS240GMTS420S) hatte ich noch liegen, das passte gut. Bezahlt habe ich inkl. Versand 55 €, was in einem ähnlichen Bereich wie ein Raspberry liegt. Wer hier nach Angeboten sucht, sollte MyDealz gut im Auge behalten. Die Dinger sind immer sehr schnell ausverkauft, sobald sie verfügbar sind.

Als ich den Thin Client ausgepackt habe, war ich erst einmal von der Größe etwas überrascht. Ich hatte ein größeres Gerät erwartet, aber der sehr kleine Formfaktor passt eigentlich gut. Nach einem kurzen Test-Boot ins BIOS habe ich dann RAM und SSD ausgetauscht, nur um festzustellen, dass das Gerät nicht mehr startete und das ganze mit Piepen quittierte. Wie sich herausstellt ist der RAM, den ich noch hatte, nicht kompatibel. Ich werde noch mal ein anderes Modul kaufen (eine gute Kompatibilitätsliste und haufenweise weitere Informationen finden sich hier: https://github.com/R3NE07/Futro-S740 ), sobald ich Bedarf für mehr RAM habe.

Ich habe also Debian installiert und dort Proxmox eingerichtet. Innerhalb von kürzester Zeit lief ein ganz normales Proxmox, mit 2,9 Watt im Idle. Wenn 2-3 VMs/Container mit insgesamt wenigen Prozent Last laufen, bin ich immer noch bei unter 5 Watt. Zur Optimierung habe ich den Govenor auf Conservative eingestellt. Damit bleibt der Takt meistens sehr niedrig, höher takten tut die CPU nur, wenn länger höhere Last anliegt. Bei VMs lohnt es sich auch, in den VM-Optionen in Proxmox “Use tablet for pointer” zu deaktivieren. Das senkt die CPU-Last von VMs um wenige Prozent und spart vor allem bei mehreren VMs durchaus Ressourcen. Man verliert hierbei die absolute Mausposition in der VM, was aber bei einer VM, die eh nur über die Konsole oder per Remote bedient wird, keinen Unterschied macht.

Seit der Umstellung fühlt sich Homeassistant flotter an, vor allem beim Aufruf von längerer Historie. Ich kann außerdem nun beispielsweise Smokeping und Adguard problemlos auf derselben Hardware laufen lassen. Zurzeit schränkt mich der RAM mit 4 GB etwas ein, belegt sind meistens etwa 2,7 GB. Der Prozessor ist im Schnitt bei etwas über 5 %, da ist also noch viel Luft nach oben. Ich bin allgemein super happy mit dem Gerät, da ich für wenig Geld und geringem Strombedarf wieder eine volle Virtualisierungsumgebung nutzen kann und wieder mehr “Spielwiese” habe.

Das Netzwerk-Kallax hat auch noch ein Updat bekommen - aus dem 1x1-Kallax wurde nun ein 2x1-Kallax. Ich habe dabei auch die Verkabelung noch neu gemacht, das ganze sieht jetzt etwas ordentlicher aus. Und ich komme an den Arbeits-Laptop, der obendrauf liegt, zum Einloggen besser ran.

Netzwerk und Homelab – Stand Januar 2023

Tue, 24 Jan 2023 00:00:00 +0000

Das letzte Update zu den Plänen mit meinem Homelab ist jetzt wieder einige Monate her, die dort gezeigte Lösung war auch nur bis etwa August aktiv. Ich bin seitdem umgezogen, wobei ich auch mein Netzwerk neu aufgebaut habe. Ich habe hierbei einiges vereinfacht und für einen geringen Stromverbrauch optimiert. Ich habe unten auch eine konkrete Hardware-Liste angefügt.

Fangen wir mit dem grundlegenden an. Bisher hatte ich einen 100-MBit/s-DSL-Vertrag bei der Telekom. Da an der neuen Adresse jedoch via DSL maximal 50MBit/s verfügbar sind, habe ich zu Vodafone Kabel gewechselt - damit bekomme ich nun 250 MBit/s. Verfügbar wären an sich bis zu 1 GBit/s, aber das benötige ich absolut nicht. Internet-Fallback ist ein LTE-Router mit günstigem Prepaid-Tarif, bei dem ich unkompliziert viel Datenvolumen nachbuchen kann - dazu später mehr.

Das Netzwerk im Kern

Wie in der vorherigen Wohnung ist ein hAP AC² von Mikrotik Kern des ganzen. Der Router übernimmt sowohl das Routing als auch Aufgaben wie VPN-Tunnel und dient parallel als WLAN-Access-Point. Klar, ich würde mit einem externen AP mehr Bandbreite bekommen - aber das, was jetzt durchkommt, genügt definitiv. Im selben Raum kriege ich über 200 MBit/s, in anderen Räumen meistens zwischen 50 und 100 MBit/s. Das reicht eigentlich für alles, nur bei Spiele-Downloads mit dem Steam Deck wäre mehr Bandbreite wünschenswert.

Am hAP hängen zwei Switches. Einer ist ein kleiner 5-Port-Switch für Smart-Home, der andere ist der Hauptswich für das Heimnetz. Bei den Switches haben sich die kleinen Geräte von TP-Link für mich seit über 10 Jahren bewährt - bislang ohne einen Ausfall.

Ich habe auch eine Powerline-Strecke in den Keller, dort hängt ein Mikrotik mAP Lite als Access Point für eine WLAN-Steckdose. Der Durchsatz liegt im Keller bei 20-30 MBit/s. Die Bandbreite war mir dort aber relativ egal, hauptsache es kommen stabil mindestens 1-2 MBit/s durch. Netter Nebeneffekt dadurch ist, dass wenn die Waschmaschine mal wieder 15min für die letzte Minute braucht, man sich die Zeit auf Reddit und co vertreiben kann. Ansonsten ist der Keller ein komplettes Funkloch, außer meinem eigenen Netz sehe ich gar nichts. Mobilfunk kommt auch nicht an.

Internetzugang

Für den Internetzugang nutze ich das Modem von Vodafone, allerdings im Bridge-Mode, um doppeltes NAT (bzw. mit CGNAT dann dreifaches) zu vermeiden. Im Vergleich zu einem eigenen Modem habe ich so den Vorteil, dass ich Hardware von Vodafone benutze, kein eigenes Modem anschaffen muss und auch Telefonie soweit gut funktioniert. Der große Nachteil ist allerdings, dass ich kein IPv6 bekomme. Dafür ist die IPv4-Adresse nicht geteilt, also kein CGNAT. Ich habe mir Tunnel-Provider wie Route48 angesehen, aber dort hatte ich dann Probleme mit der Verortung der IP-Adressen. Bei Google Shopping wurden beispielsweise auf einmal Ergebnisse bei Walmart und generell in Dollar angezeigt - das Ganze war nicht so richtig alltagstauglich und dementsprechend wieder deaktiviert. Ich werde das Thema irgendwann noch einmal untersuchen, da ich eigentlich schon gerne Dualstack hätte.

Als Internet-Fallback habe ich einen TP-Link MR100 LTE-Router gekauft, diesen gabs im Dezember für etwa 40 € im Angebot. Darin ist nun eine SIM-Karte von Edeka-Smart. Ich habe länger überlegt, was für ein Tarif geeignet ist und mich schlussendlich für einen Prepaid-Tarif entschieden, der bei nicht- bzw. geringer Nutzung günstig ist, wo ich aber tagesweise für einen brauchbaren Preis viel Datenvolumen nachbuchen kann. Normalerweise wird dann der 1GB-Tarif für knapp 5 €/Monat gebucht, sollte es tatsächlich zu Ausfällen kommen, lässt sich für etwa 6 € pro 24h unlimitiertes Datenvolumen nachbuchen. Da ich nicht davon ausgehe, das oft zu benötigen und der Tarif Prepaid und auch im Telekom-Netz ist, ist für mich alles erfüllt. Das Vodafone-Mobilnetz ist hier nicht brauchbar mit etwa 1-2 MBit/s, bei der Telekom kriege ich durchaus 70-80 MBit/s (Upload etwa 30 MBit/s). Das reicht mehr als aus, um von zu Hause zu arbeiten und auch Netflix in guter Qualität nutzen zu können.

Smart-Home

Vielleicht hat sich schon jemand gefragt, warum überhaupt eine FritzBox mit im Netzwerk hängt, wenn ich doch das Modem von Vodafone nutze und einen zusätzlichen Hauptrouter habe. Die dient nur als DECT-Basisstation, woran neben einem FritzFon auch drei smarte Thermostate angeschlossen sind.

Alles im Smart-Home wird von einem Raspberry Pi 3 mit HomeAssistant gesteuert. Der Pi 3 ist natürlich nicht mehr der neuste, aber den hatte ich noch, wodurch ich keine neue Hardware anschaffen musste. Hier sind aber Änderungen geplant, mehr dazu unten.

Neben den Thermostaten sind diverse WLAN-Steckdosen, Zigbee-Temperatursensoren und -Schalter, ein Strommessgerät sowie einige weitere Geräte eingebunden. Ich habe einen Post zum aktuellen Stand vom Smart-Home geplant, aber mal schauen, wann ich da tatsächlich zu komme und Lust darauf habe.

Stromverbrauch

Die komplette Hardware zusammen (also Router, Switches, Raspi, …) braucht im Leerlauf etwa 24 Watt, bei starker Nutzung der Internetleitung geht der Verbrauch auf knapp 30 Watt hoch. Das ist im Vergleich zu meinem vorherigen Setup (also das mit laufendem Server) recht wenig - ein einzelner Router würde aber natürlich weniger verbrauchen. Dennoch - unter 10 € Stromkosten pro Monat bei den aktuell hohen Preisen ist für mich vertretbar.

Ich suche generell Komponenten mittlerweile auch stark nach Stromverbauch aus. Einerseits natürlich um Kosten zu sparen, andererseits auch mit Blick auf die Umwelt.

Zukunftspläne

Mein Homelab ist, wie schon immer, im stetigen Wandel. Auch jetzt habe ich schon wieder einige Verbesserungen bzw. Änderungen im Kopf, die ich in den nächsten Wochen und Monaten umsetzen möchte.

Netzwerk

Der frühere Hauptswitch (TP-Link SG1024DE, also 24 Ports mit VLANs) ist aktuell ohne Verwendung. Ich habe vor, zur Serverecke im Arbeitszimmer nur noch ein Kabel statt bisher drei (wenn man das normal nicht steckende Kabel für das IPMI mitzählt) liegen zu haben und dort dann den Switch zu verwenden. Das ist natürlich deutlich übertrieben, aber damit kann ich die Kabel im Netzwerkbereich etwas reduzieren. Ich habe damit auch die Möglichkeit, einfacher einen weiteren Server (für temporäre Nutzung) hinzuzufügen.

Heimserver

Bekanntlich habe ich mehrfach versucht, den alten Heimserver gegen etwas Energieeffizientes auszutauschen. Das hat ja nicht so gut geklappt. Ich warte zurzeit darauf, dass beispielsweise Thin-Clients (wie ein Futro S740) oder vergleichbare Mini-PCs günstig im Angebot sind, da ich so etwas für eine gute Lösung für mich halte. Ich kann Proxmox einsetzen, Homeassistant als VM nutzen und Dinge wie PiHole/AdGuard oder mein altes Smokeping-Setup wieder problemlos verwenden. Generell erlaubt mir eine kleine Maschine mit Proxmox mehr Flexibilität und einfach Spielraum. Mir geht es hierbei aber auch stark darum, so wenig Strom wie nur möglich zu verwenden. Ich benötige zu Hause auch nicht viel Rechenleistung, das macht die Auswahl etwas leichter bzw. ich kann auf maximale Energieeffizienz setzen, ohne groß auf die Performance schauen zu müssen.

Hardware-Liste

Diese Liste werde ich eines Tages mal auf eine eigene Seite auslagern. Heute ist aber nicht dieser Tag.

Hauptrouter: Mikrotik hAP AC²
Access-Point im Keller: Mikrotik mAP Lite
LTE-Router: TP-Link MR100
Kabelmodem: Vodafone Station
Switches
- 5-Port: TP-Link SG105
- 8-Port: TP-Link SG108
Powerline-Adapter: TP-Link TL-PA4010
Smart-Home-Server: Raspberry Pi 3
Zigbee-Stick: Irgendein random Stick mit einem CC2531-Chip
DECT-Basis: FritzBox 7360

Änderungen am Homelab Part 3 – Meine Lösung

Wed, 13 Apr 2022 00:00:00 +0000

Ursprünglich hatte ich ja vor, meinen jetzigen Heimserver ( der so 30-40 Watt im Leerlauf verbraucht) durch einen Mini-PC zu ersetzen, der dann den Verbrauch auf 10 Watt oder so reduziert. Das lief bekanntlich nicht so wie geplant.

Daher nun ein neuer Plan. In meiner Wohnung laufen eh zwei Raspberry Pis (Model 1B, also nicht ganz frisch), die ein paar Sensoren ans Netz bringen. Ich habe auch einen primär privat genutzten Server in einem Rechenzentrum stehen (dazu bei Gelegenheit mehr). Und ich wollte meinen Router (aktuell ein Unifi USG von Ubiquiti) eh durch ein Gerät von Mikrotik austauschen. Kern meines Heimnetzes ist nun ein Mikrotik hAP AC2.

Also.

Die Idee ist, die Homeassistant-VM ins Rechenzentrum zu schieben und irgendwie das entsprechende Netz zu diesem Server zu bridgen (also kein Routing dazwischen). Mir ist klar, dass das definitiv nicht best-practise ist, das ist auch keine Dauerlösung. Ich habe nun also ein VLAN, was mittels EoIP (Ethernet over IP, Protokoll von Mikrotik) an ein VLAN auf dem Server im Rechenzentrum angeschlossen ist. Der EoIP-Tunnel läuft dabei innerhalb eines Wireguard-Tunnels. Nachdem ich ein paar Probleme, die alle auf die MTU zurückzuführen waren, behoben hatte, läuft das ganze nun erstaunlich gut. Zigbee wird mittels Zigbee2MQTT auf einem der Pis in MQTT übersetzt und an den Broker geschickt. Man merkt auch absolut keinen Unterschied dadurch, dass Homeassistant nun woanders läuft.

Parallel habe ich die Unifi USG und auch meinen Unifi AP AC Lite vom Netz genommen. Den AP erst einmal testhalber, da ich mir vom integrierten WLAN ein Bild machen möchte. Und bislang schafft der hAP AC2 es, von einer Ecke der Wohnung alles abzudecken. Geschwindigkeiten sind nicht auf dem Level vom Unifi AP (der hat problemlos 200MBit/s und mehr durchgehauen, jetzt sind es eher 60MBit/s), aber ich bin mehr als zufrieden damit. Das WLAN ist eh ungefähr nur für einige WLAN-Steckdosen und zwei Smartphones im Einsatz, alles andere hat ein Kabel dran. Die Konfiguration vom Mikrotik-Gerät war zwar alles andere als einfach, aber die Dinger können dafür auch sehr viel.

…und das relevante: Der Stromverbrauch. Vorher war ich mit dem Server im Idle bei grob 60 Watt mit allem. Also Switch, Router, AP und Server. Jetzt stehen da 17 Watt. Bei den aktuellen Strompreisen macht sich das sehr schnell bezahlt und ich fühle mich insgesamt besser dabei. Der Server kommt auch nicht weg, der steht weiterhin hier. Nur jetzt eben nicht mehr dauerhaft an, sondern nur bei Bedarf.

Eine Dauerlösung ist das so nicht. Auch, da der Server im RZ nicht mehr der Jüngste ist und die SSDs auch schon einige Jahre in Betrieb sind. Mein Ziel ist, Homeassistant dann irgendwann auf einen weiteren, aktuelleren Pi zu schieben. Was ich mit dem Atlassian-Stack dann mache weiß ich jetzt noch nicht, der ist im RZ soweit aber erstmal gut aufgehoben.

Vielleicht schaue ich beim Thema Mini-PC ja doch noch mal vorbei. Aber in absehbarer Zukunft steht eh ein Umzug an, wo ich mein Vorgehen neu betrachten muss.

Änderungen am Homelab Part 2 – Fail.

Sun, 10 Apr 2022 00:00:00 +0000

Der letzte Beitrag zu dem Thema endete damit, dass ich den JB95 von MinisForum getestet habe. Von der Leistung her war der in Ordnung, Stromverbrauch mit etwas unter 10 Watt im Idle auch gut. Was mich nur gestört hat, war, dass es keine Möglichkeit gab, den Mini-PC bei einem Stromausfall automatisch wieder zu booten. Auto-Start bei Stromzufuhr unterstützt er nicht, Wake on Lan geht leider auch nicht. Es gibt zwar ein BIOS-Update, was angeblich WOL aktivieren soll, aber das tut es nicht. Auch ethtool zeigt WOL als Deaktiviert an. Der Support war keine Hilfe bzw. hat - denke ich - mein Problem nicht verstanden. Das war leider dann ein KO-Kriterium für mich.

Aber es gibt ja auch andere Mini-PCs mit der selben CPU. Also habe ich einen Mini-PC von BMAX mit dem N5095 bestellt. Auto-Start bei Stromzufuhr klappt problemlos. Es ist auch ein Platz für ein 2,5-Zoll-Laufwerk vorhanden, aber es liegt kein passendes Kabel bei. Man bekommt so ein Kabel auch ungefähr nicht. Zudem war die SSD eine sehr kleine (wenn ich mich recht erinnere M.2 2242), und der Markt an solchen SSDs ist klein und dementsprechend teurer als z.B. M.2 2280. Also war dieses Gerät auch raus.

Also weiter. Der U59 von Beelink hat auch diese CPU. Auto-Power-On klappt, WOL geht und das Kabel für ein 2,5-Zoll-Laufwerk ist schon verbaut. Super. Ich habe also Proxmox installiert und meine VMs übertragen. Nur um dann festzustellen, dass VMs zufällig einfach crashen. Die Meldungen im Kernel-Panic der VMs sind leider wenig aussagekräftig, das Ganze passiert auch unregelmäßig. Teilweise direkt 1-2min nach dem Start, manchmal erst nach 1-2 Tagen. Aber mehrere VMs sind mehrfach immer wieder gecrasht, sowohl auf der internen als auch der zusätzlich verbauten SSD (die zusätzlich verbaute ist eine MX500, die bis dahin in meine Heimserver aktiv wawr und unproblematisch ist). Damit war der dritte Mini-PC auch nicht geeignet.

Jetzt bin ich an einem Punkt angelangt, wo ich keine Lust mehr habe, Mini-PCs zu bestellen nur um sie dann wieder zurückzuschicken. Ob Amazon das auf Dauer so cool findet, bezweifle ich auch. Ich habe nun aber einen komplett anderen Plan entwickelt, um meinen Stromverbrauch zu reduzieren. Mehr dazu dann im nächsten Beitrag - vorab sage ich nur, dass es kompliziert wird.

Hinweis am Rande: Das Problem mit den crasheden VMs habe ich auch auf dem Minisforum-Gerät feststellen können… Vielleicht ein generelles Problem mit der Plattform.

Änderungen am Homelab – Stromkosten.

Fri, 25 Feb 2022 00:00:00 +0000

Die Strompreise steigen aktuell immer weiter an, was den Betrieb von einem Heimserver zunehmend teurer macht. Deswegen habe ich mir einen Mini-PC angesehen, um zu schauen, ob dieser geeignet ist, meinen bisherigen Server zumindest für den 24/7-Betrieb abzulösen.

Ursprünglich sollte dieser Post direkt ein Review vom potenziellen neuen Heimserver werden - der Hintergrund-Part bzw. Überblick über die aktuelle Situation hat aber dermaßen den Rahmen gesprengt, dass ich das jetzt als eigenen Post vorher veröffentliche.

Der aktuelle Stand

Ich habe auch Raspberry Pis in Betracht gezogen - nachfolgende Auflistung an Hardware und vor allem der laufenden Dinge sollte aber gut zeigen, warum das nicht so wirklich eine Alternative ist.

Bisher läuft als Hauptserver folgende Hardware:

CPU: Intel Xeon E3-1230v3 (4C/8T @ 3,3GHZ)
Mainboard: Supermicro X10SLL-F (mit IPMI)
RAM: 32GB DDR3 ECC
OS: Proxmox
Datenträger:
- 240GB Sata-SSD (ohne Cache) für Proxmox
- 500GB NVMe-SSD für VMs
- 500GB Sata-SSD (mit Cache) für VMs
- 1TB HDD für Backups

Normale CPU-Last liegt bei grob 10%, RAM brauche ich meistens um die 20-24GB. An Anwendungen läuft folgendes:

Container (LXC)	VMs (KVM)
PiHole	Router/VPNs (z.B. zum RZ)
Reverse Proxy (Nginx Proxy Manager)	Unifi-Controller
Smokeping	Mikrotik CHR zum Rumspielen
Traceroute-Change-Detection	2x Windows-VM
Wordpress-Testumgebung	Confluence
Container mit random Scripts für Notifications o.ä.	Jira
Mosquitto für MQTT	Bitbucket
Paperless-NG	Jenkins
	Bitwarden-RS
	Backup-VM
	Homeassistant

Einige der VMs (z.B. den Unifi-Controller) kann man sicherlich noch auf Container umstellen und damit schlanker bekommen. Auch der komplette Atlassian-Stack (Jira, Confluence, Bitbucket) hat nichts, was die Verwendung von VMs benötigt. Damit dürfte vor allem der RAM-Verbrauch auch noch mal um ein paar GB sinken - das ist aber eher eine Sache für die nächsten Monate und nicht für Jetzt. Eilt nicht.

Die meisten der VMs bieten also irgendwelche Services im Heimnetz (oder auch extern) an. Und auf diese Services verzichten möchte ich auch nicht.

Wie also weniger Strom verbrauchen?

Der Server braucht aktuell im Idle um die 40-45 Watt, unter Last 60-80 Watt. Die meiste Zeit läuft das Teil eher im Idle, ich rechne also mit im Schnitt 45-50 Watt. Das sind bei den aktuellen Strompreisen also grob 150€ pro Jahr - und mir eindeutig zu viel Geld dafür, dass der die meiste Zeit kaum was zu tun hat. Un die Umwelt hat auch noch was davon, wenn ich weniger Strom verbrauche.

Dadurch, dass ich für ein paar Programme VMs mit Windows benötige, sind Raspberry Pis leider raus, der RAM ist da auch ein Argument. Ich weiß auch nicht, wie gut Jira oder Confluence auf einem Pi laufen würde - durch den hohen RAM-Verbrauch würde ich auch mehrere Pis benötigen. Und bei den aktuellen Preisen von 100€ und mehr für die Version mit 8GB wird mir das einfach zu teuer. Ein kleiner selbst gebauter Rechner würde zwar weniger verbrauchen, aber wahrscheinlich immernoch 20-30 Watt. Und die Boards mit kleinen Celerons/Pentiums sind teuer. Beim bisherigen Server die CPU mit was kleinerem zu ersetzen ginge zwar, aber würde vermutlich nur wenige Watt sparen. Mainboards mit IPMI sind vom Stromverbrauch her nicht die besten.

Bleiben eigentlich nur noch Mini-PCs. Und davon gibt es viele, wie ich gemerkt habe. Kriterien, die mir wichtig waren:

min. 4 CPU-Kerne
gesockelter RAM, min 16GB möglich
min. zwei Datenträger (am besten 1x M.2 und 1x 2,5-Zoll Sata)
Gigabit-LAN
geringer Stromverbrauch
max 300-350€

Klar, ein IPMI ist cool. Aber beim bisherigen Server bin ich da dermaßen selten drin, dass ich da auch drauf verzichten kann. Formfaktor ist mir auch nicht so wichtig.

Ich bin bei der Suche dann schnell auf den Hersteller MinisForum gestoßen. Ich hatte an anderer Stelle mit dem UM350 ( Ryzen 5 3550H, 16GB RAM und 256GB SSD) von denen zu tun und war zufrieden mit der Hardware. Der LAN-Port mit 2,5GBit/s ist zwar nett, aber fast 450€ rentieren sich dann doch nicht in akzeptabler Zeit.

Dann habe ich dieses Gerät hier, den JB95 (Intel Celeron N5095, 8GB RAM, 256GB SSD) gefunden. Preislich unter 300€ und sollte alle meine Anforderungen erfüllen. Klar, der Celeron wird deutlich schwächer sein als der Xeon, den ich gerade habe - aber die normale Last sollte der Rechner schaffen. Und ich werde den bisherigen Server ja nicht wegwerfen; der wird, wenn ich kurzzeitig mehr Power brauche, weiterhin bereitstehen.

Der Mini-PC steht gerade vor mir und läuft auch schon mit Proxmox. Ich habe noch nicht alles ausprobiert, was ich ausprobieren möchte, aber es sieht soweit ziemlich gut aus. Dementsprechend wird es in den nächsten Tagen einen ausführlicheren Post zu dem JB95 geben.