Docker 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.

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.

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.

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.

Lokales Multiroom-Audio mit dem Lyrion Music Server und Squeezelite

Tue, 29 Jul 2025 00:00:00 +0000

Ich bin vor einer Weile über Lyrion Music Server (https://lyrion.org/) gestolpert und fand das Konzept sehr spannend. Lyrion Music Server ist die Weiterentwicklung von Logitech Media Server, einem lokalen Musikserver für die Verwendung mit dafür gebauten Abspielgeräten (Squeezeboxen). Squeezeboxen gibt es abseits vom Gebrauchtmarkt nicht mehr, einen Softwarenachbau für die Player in Form von beispielsweise Squeezelite jedoch bereits vorhanden.

Was die Software besonders macht ist das Feature, dass mehrere Player synchron bespielt werden können, wie es mit Multiroom-Setups von anderen Herstellern möglich ist. Primär ist Lyrion dafür gebaut, lokale Mediatheken und auch Radio abzuspielen, es gibt jedoch auch ein Plugin, mit dem das ganze über Spotify Connect direkt via Spotify ansteuerbar ist.

Hardware

Ich habe aktuell in vier Räumen Player installiert. In einem weiteren Raum ist geplant, zumindest eine Buchse zum Anschluss von z.B. einer Bluetooth-Box izu installieren.

Arbeitszimmer

Hier stecken meine PC-Lautsprecher einfach über ein Klinke-Y-Kabel sowohl an meinem PC als auch an dem Thin Client, der LMS beherbergt. Dort läuft Squeezelite als Docker in LXC, das Audiogerät ist vom Host an den LXC und Docker durchgereicht und wird von dort bespielt.

Wohnzimmer

Im Wohnzimmer ist ein Raspberry Pi 1b mit piCorePlayer wie im Arbeitszimmer, ebenfalls mit einem Y-Kabel, an das Soundsystem des Fernsehers angeschlossen. Via Homeassistant wird automatisch das Soundsystem eingeschaltet, sobald Musik abgespielt wird.

Schlafzimmer

Hier befindet sich ein selbstgebauter Player. Dieser besteht aus einem Raspberry Pi 1b mit piCorePlayer, einem Verstärker-Board und Regallautsprechern. Der Verstärker kann über ein Relais vom Pi aus ein- und ausgeschaltet werden, um Grundrauschen oder andere Geräusche auf den Lautsprechern zu vermeiden, wenn keine Musik abgespielt wird. Nebenbei spart das natürlich auch Strom. Angetrieben wird das ganze von einem 19V Laptop-Netzteil.

Küche

Hier ist ähnlich wie im Schlafzimmer ein selbstgebauerter Player platziert, hier allerdings mit einem Raspberry Pi 3. Auch hier ist es ein günstiges Verstärker-Board, schaltbar über ein Relais. Ich hatte auch für diesen Pi erst einen WLAN-Stick bestellt und erst beim Einrichten von piCorePlayer festgestellt, dass der Pi 3 WLAN integriert hat und ich den Stick gar nicht brauche.

Software

Der Lyrion Music Server läuft als Docker, hier ist einmal meine Compose-Datei inkl. des Squeezelite-Players:

 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


services:
 lms:
 image: lmscommunity/lyrionmusicserver:dev
 network_mode: host
 volumes:
 - ./config:/config:rw
 - ./music:/music:ro
 - ./playlist:/playlist:rw
 - /etc/localtime:/etc/localtime:ro
 - /etc/timezone:/etc/timezone:ro
 environment:
 - HTTP_PORT=9000
 restart: unless-stopped
 squeezelite:
 image: giof71/squeezelite:latest-alsa
 devices:
 - /dev/snd:/dev/snd
 environment:
 - USER_MODE=yes
 - PUID=0
 - PGID=0
 - AUDIO_GID=29
 - SQUEEZELITE_NAME=Arbeitszimmer
 - SQUEEZELITE_AUDIO_DEVICE="hw:CARD=PCH,DEV=0"
 volumes:
 - ./sl-config/:/config/
 restart: unless-stopped

Bei den Plugins habe ich einerseits Spotty für Spotify Connect installiert, andererseits auch ein Plugin, um Gruppen vordefinieren zu können. Ich habe hierbei hauptsächlich eine Gruppe mit allen Lautsprechern definiert, ansonsten werden die Räume in der Regel nur einzeln genutzt.

Soundqualität und generelle Erfahrung

Die Player mit eigenem Verstärker haben leider ein gutes Maß an Grundgeräuschen, hauptsächlich dürfte das von Spannungswandlern von 19V auf 5V für die Pis kommen. Bei den Playern, wo Soundsysteme angeschlossen sind, habe ich damit keine Probleme.

Ich (bzw. wir) nutze das System hauptsächlich mit Spotify Connect. Das funktioniert nicht unbedingt perfekt - die Wiedergabe bleibt leider regelmäßig nach Ende eines Songs hängen und muss dann erstmal händisch wieder gestartet werden. Eine Lösung dafür habe ich bislang noch nicht, das Problem beim Spotty-Plugin ist allerdings bekannt. Playlists über die Integration in LMS und nicht via Spotify Connect zu starten soll das Problem beheben, ist für uns allerdings eher unpraktisch.

Update: Beim Plugin, was für Spotify zum Einsatz kommt, wurde aufgrund von API-Änderungen bei Spotify der Connect-Modus vorerst entfernt, seit dem nutzen wir die Integration. Das funktioniert auch fehlerfrei, das System spielt stundenlang ohne einen einzigen Fehler Musik ab.

Ansonsten funktioniert das System gut, die Lautsprecher laufen weitestgehend synchron. Zeitweise gab es mal mit einem Lautsprecher Probleme, weil aus irgendeinem Grund der WLAN-Empfang in der genauen Position des Players schlecht war, das hat dann dazu geführt, dass das gesamte System regelmäßig out of sync war und die Wiedergabe kurz unterbrochen wurde. Verschieben des Players um einige Zentimeter hat das beseitigt.

Webbasierter Remotezugriff mit Guacamole

Mon, 09 Jun 2025 00:00:00 +0000

Ich habe schon eine ganze Weile mit verschiedenen Möglichkeiten experimentiert, von unterwegs und ohne dabei einen eigenen Client zu benötigen. Dabei bin ich irgendwann auf Apache Guacamole gestoßen, einem webbasierten Remotedesktop-Tool, das im Browser läuft und RDP, VNC und SSH unterstützt. Und sich mit 2FA sichern lässt. Also alles abdeckt, was ich benötige.

Guacamole läuft bei mir als Docker-Container im Homelab und bietet mir über einen gesicherten Webzugang die Möglichkeit, sowohl meine Windows- als auch meine Linux-VMs zu nutzen. Ein Browser (und Internet) reicht, und ich habe Zugriff auf eine vollständige Desktop-Umgebung – mit gewohnter Software, Dateiablage und allem Drum und Dran. Das funktioniert in den meisten Fällen auch mit restriktiven Firewalls/Proxies, da alles über HTTPS und Websockets abgewickelt wird. Durch Zwei-Faktor-Authentifizierung und restriktive Firewall-Regeln ist das Ganze auch sicher genug, um es von außen erreichbar zu machen. Und es funktioniert meistens sogar hinter restriktiven Firewalls, solange Websockets funktionieren, und eignet sich damit auch für den Zugriff von z.B. der Arbeit oder der Schule/Uni - vorausgesetzt, die vorliegenden Regelungen lassen es zu.

Schematischer Aufbau

Technisch ist das ganze eigentlich recht simpel aufgebaut:

Guacamole ist das Herzstück vom ganzen, es stellt das Webinterface bereit, kümmert sich um das Benutzermanagement und verwaltet auch die Verbindungen. Guacamole wiederum steuert Guacd an, das ist ein Dienst, der diverse Protokolle wie RDP und VNC in ein allgemeineres Format übersetzt. Für die Benutzer- und Verbindungsverwaltung wird auch noch eine MySQL-Datenbank benötigt. Davor steht bei mir ein Caddy, aber jeder beliebige andere Reverse-Proxy tut es auch.

Einrichtung

Docker-Compose

 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



services:
 guacdb:
 container_name: guacamoledb
 image: mariadb:latest
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: '9ngmZtFToD3Ll4ncBA6V'
 MYSQL_DATABASE: 'guacamole_db'
 MYSQL_USER: 'guacamole_user'
 MYSQL_PASSWORD: 'qi1tqoSTRGx5eD4ghCAG'
 volumes:
 - './db-data:/var/lib/mysql'
 - './initdb.sql:/docker-entrypoint-initdb.d/initdb.sql'

 guacd:
 container_name: guacd
 image: guacamole/guacd:latest
 restart: unless-stopped

 guacamole:
 container_name: guacamole
 image: guacamole/guacamole:latest
 restart: unless-stopped
 ports:
 - 8080:8080
 environment:
 GUACD_HOSTNAME: "guacd"
 MYSQL_HOSTNAME: "guacdb"
 MYSQL_DATABASE: "guacamole_db"
 MYSQL_USER: "guacamole_user"
 MYSQL_PASSWORD: "qi1tqoSTRGx5eD4ghCAG"
 TOTP_ENABLED: "true" # optional, forciert 2FA
 depends_on:
 - guacdb
 - guacd

Vor dem Start muss allerdings die Datenbank noch befüllt werden. Das Container-Image bringt ein Script mit, um den nötigen Dump zu erzeugen:

1

docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --mysql > initdb.sql

Nun kann mit docker compose up -d der Stack gestartet werden. Der MariaDB-Container importiert beim ersten Start alles, was unter /docker-entrypoint-initdb.d/ liegt in alphabetischer Reihenfolge - und damit auch den Dump, den wir eben angelegt haben.

Reverse Proxy

Guacamole müsste nun unter dem angegebenen Port (hier 8080) erreichbar sein, es muss der Pfad /guacamole aufgerufen werden. Jetzt kann noch ein beliebiger Reverse-Proxy auf Guacamole verwiesen werden, beispielsweise Caddy:

1
2
3
4


guacamole.example.com {
 rewrite / /guacamole
 reverse_proxy http://192.168.1.2:8080
}

Ich habe hierbei auch einen Rewrite von / zu /guacamole hinzugefügt, damit man den Pfad nicht händisch angeben muss.

Konfiguration

Die initialen Logindaten sind guacadmin/guacadmin. Sofern TOTP über die Umgebungsvariablen aktiviert wurde, wird nun direkt nach einem zweiten Faktor gefragt. Oben rechts unter Einstellungen lässt sich dann eine Verbindung anlegen. Bei RDP lohnt es sich, den Haken bei Grössenänderungs-Methode: Display Update zu setzen. Die Haken unten bei Geschwindigkeit kann man setzen, wie man möchte - ich hab hier Desktophintergrund aktivieren und Schriftartglättung (ClearType) aktivieren.

Nutzung

Auf der Startseite sollte nun die Verbindung angezeigt werden. Nach einem Klick sollte die Verbindung stehen und sich auch mit Änderung der Fenstergröße automatisch anpassen.

Performance

Nach meiner Erfahrung ist die Performance primär von der Single-Thread-Performance des Hosts abhängig - auf den Futros läuft Guacamole langsamer als auf dem Mini-PC mit Ryzen-Prozessor. Aber beides ist definitiv nutzbar, auch wenn ich nicht 24/7 darüber arbeiten wollen würde.

TS3-Server inkl. Autostart installieren - 2.0 (Docker-Basis)

Mon, 26 Feb 2024 00:00:00 +0000

Hinweis: Nutzung auf eigene Gefahr.

Einleitung

Das alte Tutorial zum Installieren von einem TS3-Server basierte ja auf einer direkten Installation auf dem System. Das hat den Vorteil, dass es schlank ist - aber dafür ist auch mehr manuell zu pflegen. Ich habe kürzlich für jemanden einen TS3-Server inkl. automatischen Updates auf Dockerbasis aufgesetzt und finde das Setup eleganter als die bisherige Lösung, daher möchte ich es auch anderen zur Verfügung stellen.

Voraussetzungen

Auf dem Server muss Docker installiert sein. Sofern das noch nicht der Fall ist, lässt sich das einfach mit

1

wget -O- https://get.docker.com | sudo bash

durchführen. (Ja, das direkte Ausführen von fremdem Code als Root ist böse, aber die Quelle ist vertrauenswürdig. Trotzdem ist es empfehlenswert, das heruntergeladene Script einmal zu prüfen, bevor man es ausführt).

Sollte wget noch nicht ins alliert sein, geht das schnell mit

1
2


sudo apt-get update
sudo apt-get -y install wget

Das Tool, was zum Updaten des Containers genutzt wird, kann dir via Discord Webhooks (und diverse andere Varianten) Benachrichtigungen zu durchgeführten Updates schicken. Lege dazu einen Channel an und generiere dir einen Webhook - ich verwende hier im Beispiel die Webhook-URL https://discord.com/api/webhooks/asd/fgh.

Erstellen vom Datenverzeichnis

Die Daten für den Server sollen später unter /opt/teamspeak3/data liegen, die Compose-Datei im darüberliegenden Verzeichnis. Das lässt sich schnell mit

1

mkdir -p /opt/teamspeak3/data/

anlegen.

Erzeugung der Docker-Compose-Datei

Zur Verwaltung der Container nutze ich in solchen Fällen gerne Docker-Compose. Dafür muss eine Datei angelegt werden ( die docker-compose.yml), die die zu erstellenden Container inkl. Konfiguration beinhaltet. Ich nutze hier das offizielle TS3-Container-Image (von hier: https://hub.docker.com/_/teamspeak). Um das ganze möglichst pflegeleicht zu gestalten, stelle ich noch einen Watchtower-Container (von hier: https://hub.docker.com/r/containrrr/watchtower) dazu. Watchtower sorgt dafür, dass der TS3-Container immer auf dem aktuellsten Stand gehalten wird. Dazu wird in gewissen Abständen geprüft, ob es eine neue Version vom Container-Image gibt. Sofern ein Update verfügbar ist, wird das gezogen und der TS3-Container einmal frisch erzeugt.

Um den TS3-Server später nutzen zu können, musst du die Lizenzbedingungen explizit akzeptieren. Die Bedingungen kannst du dir mit dem Befehl

1

docker run --rm -it -e TS3SERVER_LICENSE=view teamspeak

ansehen.

Lege also die Datei docker-compose.yml unter /opt/teamspeak3/ beispielsweise mit nano /opt/teamspeak3/docker-compose.yml an. Der Inhalt sollte wie folgt aussehen:

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


version: '3.8'
services:
 teamspeak:
 image: teamspeak:latest
 restart: always
 ports:
 - 9987:9987/udp
 - 10011:10011
 - 30033:30033
 volumes:
 - "/opt/teamspeak3/data:/var/ts3server/"
 environment:
 TS3SERVER_LICENSE: view # "view" durch "accept" ersetzen, um die Lizenzbedingungen zu akzeptieren
 watchtower:
 image: containrrr/watchtower:latest
 restart: always
 environment:
 WATCHTOWER_SCHEDULE: '0 0 5 * * *' # Update-Prüfung täglich um 05:00 Uhr
 WATCHTOWER_NOTIFICATIONS: 'slack'
 WATCHTOWER_NOTIFICATION_SLACK_HOOK_URL: 'https://discord.com/api/webhooks/asd/fgh/slack' 
 WATCHTOWER_NOTIFICATION_SLACK_IDENTIFIER: 'Watchtower'
 WATCHTOWER_NOTIFICATION_SLACK_CHANNEL: '#watchtower'
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock

Die Zeilen, die mit WATCHTOWER_NOTIFICATIONS beginnen, sind für die Notifications zuständig. An die Webhook-URL muss, wie im Beispiel sichtbar, noch /slack angefügt werden.

Erster Start

Wechsle zuerst in das Verzeichnis vom Server:

1

cd /opt/teamspeak3

starte nun einmal den TS3-Server im Attached-Modus, damit du den Serveradmin-Token sehen kannst:

1

docker compose up teamspeak

Nach einigen Sekunden kannst du den Server mit Strg + c wieder beenden. Das sieht dann etwa so aus:

In der Ausgabe findest du neben dem Admin-Token auch die Zugangsdaten für die Query-Schnittstelle. Bewahre diese Daten gut auf!

Finaler Start

Mit

1

docker compose up -d

startest du nun den Server. Der Server wird auch automatisch bei Systemstart mit gestartet, also dort ist nichts weiter zu tun.

Damit sollte der Server nun erreichbar sein und das Tutorial ist beendet. Viel Spaß!