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

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.

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.

Lokales Multiroom-Audio Part 2 - Wechsel zu Snapcast

Fri, 13 Mar 2026 00:00:00 +0000

Bisher hatte ich für das lokale Multiroom-Audio-Setup Lyrion Music Server im Einsatz. Grundsätzlich funktioniert das - es gibt allerdings einige Punkte, die mich stören.

Was mir fehlt bzw. was mich stört

Spotify Connect

Das Lyrion-Plugin für Spotify hatte ursprünglich Unterstützung für Spotify Connect, auch wenn das schon immer eher hakelig war und schnell die Verbindung verloren hat. Dieses Feature musste der Entwickler vom Plugin allerdings irgendwann entfernen, seit dem ist die Wiedergabe nur noch über LMS selbst möglich. Auf diesem Weg lässt sich zwar immer noch Musik von Spotify wiedergeben, trotzdem ist es deutlich schneller und angenehmer, einfach von der Spotify-App aus das Audio-Setup als Ziel auswählen zu können. Dieser Umweg hat auch dafür gesorgt, dass meine Partnerin das Soundsystem alleine ungefähr nie benutzt.

Synchronisierung

Die Synchronisierung von Lautsprechern funktioniert generell gut. Bei Verbindungsproblemen wird bei LMS allerdings die Wiedergabe auf allen Lautsprechern kurz unterbrochen. Snapcast lässt alle anderen Lautsprecher weiterlaufen, der Lautsprecher mit Verbindungsproblemen synchronisiert sich dann selbst wieder zum Rest. Die Aussetzer betreffen also nur den Player, der die Verbindungsprobleme hat.

Zu viele Features

Wir brauchen zuhause eigentlich nur Spotify Connect. Lyrion bringt ein eigenes WebUI inkl. Verwaltungsmöglichkeiten für eine eigene Mediathek mit, das brauchen wir nicht. Snapcast ist insgesamt spürbar schlanker und braucht weniger Ressourcen.

Das neue Setup

Bisher hatte ich bei den drei Playern jeweils piCorePlayer im Einsatz, das ist eine minimalistische Linux-Distribution speziell für die Nutzung eines Raspberry Pis für Squeezelite bzw. Lyrion Music Server. LMS selbst lief in Docker in einem LXC, mit einer Squeezelite-Instanz daneben für lokale Wiedergabe.

Server

Der Server ist ein Debian 13 mit installiertem snapserver. Librespot für Spotify Connect habe ich aus den Quellen selbst kompiliert, um eine möglichst neue Version zu haben. Ich habe zusätzlich noch snapweb installiert, das ist ein moderner Webclient für Snapserver, der vor allem Gruppierung und Lautstärkeregelung ermöglicht und für Mobilgeräte optimiert ist. Damit entfällt die Notwendigkeit einer eigenen App für die Steuerung.

Meine Konfiguration sieht wie folgt aus (/etc/snapserver.conf):

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


[server]

[http]
enabled = true
doc_root = /usr/share/snapweb # for snapweb

[tcp-control]
enabled = true

[stream]
source = pipe:///tmp/snapfifo?name=default
source = librespot:///librespot?name=Spotify%201&devicename=Home%201&bitrate=320&volume=90
source = librespot:///librespot?name=Spotify%202&devicename=Home%202&bitrate=320&volume=90

[streaming_client]
initial_volume = 80

Die Config ist generell sehr minimal gehalten. Für Spotify Connect habe ich zwei Quellen definiert, damit beispielsweise ich im Arbeitszimmer und meine Partnerin im Wohnzimmer verschiedene Musik hören können.

Clients

Thin-Clients

Im Arbeitszimmer stehen an beiden Arbeitsplätzen Lautsprecher, diese sind mit je einem meiner Thin-Clients (Futro S740) verbunden. Der eine snapclient läuft im selben LXC wie der Server, ich habe die Audiogeräte dafür durchgereicht. Für den zweiten läuft ein weiterer LXC, der eigentlich nur snapclient installiert hat.

Die Config (/etc/defaults/snapclient):

1

SNAPCLIENT_OPTS="--hostID arbeitszimmer-1 --soundcard hw:CARD=PCH,DEV=0 tcp://[Snapserver-IP]"

Raspberry Pis

Hier bin ich einen anderen Weg gegangen als vorher. Alle drei Pis haben Raspberry Pi OS Lite bekommen, also die Variante ohne GUI.

Auch hier ist Snapclient installiert, die Config sieht minimal anders aus (/etc/defaults/snapclient):

1

SNAPCLIENT_OPTS="--soundcard plug:plugequal --hostID wohnzimmer tcp://[Snapserver-IP]"

Das Zielgerät ist hier ein virtuelles Gerät von Alsa, um über den Equalizer Korrekturen vornehhmen zu können.

Daher sieht die Konfiguration für Alsa so aus (/etc/asound.conf):

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


ctl.equal {
 type equal;
}

pcm.plugequal {
 type equal;
 slave.pcm "plughw:CARD=Audio,DEV=0"
}

pcm.equal {
 type plug;
 slave.pcm plugequal;
}

Die Steuerung vom Equalizer ist via sudo -u snapclient alsamixer -D equal möglich.

Relais für Verstärker

An zwei Pis hängt an den GPIOs jeweils ein Relais, was einen Verstärker steuert. piCorePlayer hatte native Unterstützung dafür, dort musste ich nur den GPIO-Pin einstellen. Für Snapcast brauchte ich eine eigene Lösung.

Das Ergebnis ist ein kleines Script, was in Dauerschleife prüft, ob auf einer Soundkarte Audio abgespielt wird und darüber einen GPIO-Output steuert.

Das Script liegt bei mir unter /usr/local/bin/amp-control.sh.

 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


#!/bin/bash

GPIO=14

CHECK_INTERVAL=2
POWER_ON_DELAY=3
IDLE_TIMEOUT=30

amp_on=0
last_audio=0
audio_detected=0

pinctrl set $GPIO op
pinctrl set $GPIO dl

while true; do

 if grep -q RUNNING /proc/asound/card*/pcm*/sub*/status; then
 audio_detected=1
 last_audio=$(date +%s)
 else
 audio_detected=0
 fi

 now=$(date +%s)

 # Amp einschalten
 if [[ $audio_detected -eq 1 && $amp_on -eq 0 ]]; then
 pinctrl set $GPIO dh
 amp_on=1
 sleep $POWER_ON_DELAY
 fi

 # Amp ausschalten
 if [[ $amp_on -eq 1 && $((now-last_audio)) -gt $IDLE_TIMEOUT ]]; then
 pinctrl set $GPIO dl
 amp_on=0
 fi

 sleep $CHECK_INTERVAL

done

Dazu gehört natürlich dann auch ein Systemd-Service, damit das ganze beim Systemstart mitstartet. Der Service liegt unter /etc/systemd/system/amp-control.service.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[Unit]
Description=Snapclient Amp Control
After=snapclient.service

[Service]
ExecStart=/usr/local/bin/amp-control.sh
Restart=always

[Install]
WantedBy=multi-user.target

Read-Only-Root

Nach der fertigen Konfiguration habe ich die SD-Karte via overlayfs als Read-Only gemoutet, damit das System das Trennen vom Strom problemlos übersteht. Das geht einfach via raspi-config.

Fazit

Ich habe Snapcast jetzt seit wenigen Wochen im Einsatz, bisher bin ich zufrieden damit. Nach dem initialen Setup musste ich mich nicht mehr darum kümmern, Spotify Connect läuft auch sehr zuverlässig damit.

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.

Minecraft-Server - meine Best Practises

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

Da ich über 10 Jahre Erfahrung im Betrieb von Minecraft-Servern habe und das zwischenzeitlich auch im größeren Stil gemacht habe, möchte ich hier einmal meine Best Practises dokumentieren.

Vieles werde ich hier anhand meines eigenen Servers beschreiben. Dabei handelt es sich um einen Survival-Server, der seit bald 6 Jahren aktiv ist (gestartet während der ersten Corona-Zeiten). Der Server hat einige Plugins, das meiste davon aber rein serverseitig und ohne direkten Einfluss auf das Spielerlebnis.

Dieser Post bezieht sich komplett auf die Java-Edition. Mit der Bedrock-Edition habe ich wenig Erfahrung, da ich diese selbst nicht spiele.

Nutzungsprofil erstellen

Bevor man überhaupt mit der genaueren Planung bzw. Umsetzung beginnt, sollte feststehen, was überhaupt das Ziel ist, wie viele Spieler erwartet werden (Gesamt/Peak/Durchschnitt). Auch ist es ein großer Unterschied, ob die Spieler in einem recht kleinen Bereich aktiv sind (bspw. bei Minigames) oder verteilt auf einer großen Welt spielen. Ich habe auch häufig beobachtet, dass der Ressourcenbedarf bei einem Server z.B. in einer Freundesgruppe in den ersten Tagen deutlich höher ist als in der darauf folgenden Zeit. Dort kann es sinnvoll sein, erst kurzzeitig einen größeren virtuellen Server bei einem Anbieter zu mieten, der stundenweise bzw. tagesweise abrechnet und danach für den längerfristigen Betrieb auf einen günstigeren Server oder z.B. auch den Betrieb im Homelab zu wechseln.

Hardware bzw. Plattform

CPU

Bei Minecraft läuft, wie bei vielen anderen Spielen auch, ein großer Teil der Spiellogik in einem Haupt-Thread ab. Das heißt, dass man eher wenige schelle CPU-Kerne benötigt als viele. Große Server-CPUs mit vielen Kernen sind hier meistens eher weniger geeignet, außer man möchte viele Minecraft-Server parallel betreiben. Die (halbwegs) aktuellen Desktop-CPUs von Intel und AMD mit min. 4 (Performance) Cores sind hier meistens eine solide Wahl.

RAM

Als Minimum sehe ich 4GB, darunter kommt es schnell zu Problemen. Mehr ist bis zu einem gewissen Punkt besser, über ca 30GB RAM würde ich unter normalen Umständen nicht gehen. Mehr Mods und Plugins benötigen mehr RAM, die Sichtweite und Verteilung der Spieler (und damit die Zahl der geladenen Chunks) ist hier auch relevant. Mein eigener Server läuft normalerweise mit 8GB.

SSD vs HDD

Minecraft profitiert von schnellem Speicher. SSD ist in meinen Augen ein Muss, NVMe ist zu bevorzugen. Die benötigte Größe hängt hauptsächlich von der Weltgröße und eingesetzten Plugins (bspw. Dynmap) ab, 20GB reichen meistens aber mehr als aus.

Internetanbindung

Ein Punkt, der beim Betrieb zuhause öfter mal übersehen wird. Leistungsstarke Hardware bringt wenig, wenn nicht genügend Bandbreite zur Verfügung steht. Ich kalkuliere normalerweise mit ca 2-5 MBit/s pro gleichtzeitigem Spieler. Wenn keine Chunks geladen werden, ist der Bedarf an Bandbreite niedriger, bei einem Weltwechsel oder schnellem Bewegen auf der Karte entstehen deutlich größere Peaks. Mit ca 50 MBit/s an verfügbarer Upload-Bandbreite kann man aber schon einige Spieler bedienen.

Wenn man zuhause hostet, ist aus verschiedenen Gründen das Tunneln über einen Server in einem Rechenzentrum hilfreich. Einerseits gibt man damit seine Heim-IP nicht preis, andererseits ist durch bessere Peerings von Rechenzentren im Vergleich zu ISPs untereinander auch die Verbindungsqualität höher. Nebenbei kann man damit auch Einschränkungen durch CGNAT umgehen und den Server auch bei Nutzung einer zweiten Internetleitung für Failover erreichbar halten.

Software

Betriebssystem

Hier ist irgendeine gängige Linux-Distribution, die Docker-Support hat, sinnvoll. Ich verwende meistens Debian oder Ubuntu. Docker benötige ich für die verwendete Verwaltungssoftware, aber auch ohne ist der Betrieb von einem MC-Server in Docker häufig angenehmer als direkt auf dem Server.

Management-Tool

Ich nutze bisher Pterodactyl (pterodactyl.io) als webbasiertes Gameserver-Panel. Lange Jahre kam bei mir Multicraft zum Einsatz - da ist allerdings das letzte Release von Februar 2022 und die letzte Preview-Version von November 2023. Alternativ zu Pterodactyl möchte ich zeitnahe Pelican (pelican.dev) testen. Pelican ist ein Fork von Pterodactyl und soll trotz Beta-Stadiums sehr gut nutzbar sein. Daneben gibt es noch einige weitere erwähnenswerte Panels:

Crafty (craftycontrol.com)
PufferPanel (pufferpanel.com)
AMP (kommerziell, cubecoders.com)

Vor ein paar Jahren hätte ich noch Multicraft empfohlen, das fand ich insgesamt am angenehmsten in der Nutzung; aber da dieses Produkt scheinbar nicht mehr gepflegt wird, würde ich es nicht mehr einsetzen.

Server-Software

Kommen wir zum Kernpart. Hier ist erst einmal entscheidend, ob Mods, Plugins oder keins von beidem zum Einsatz kommen sollen. Plugins sind hierbei rein serverseitige Modifikationen bzw. Erweiterungen, normalerweise basierend auf der Spigot-API. Mods sind client- und/oder serverseitige Erweiterungen/Modifikationen, meistens geht es dabei mehr um Erweiterung des Spielinhalts (neue Blöcke, Biome, Kreaturen, Spielmechaniken, …).

Server mit Mods

Hier wird meistens Fabric (fabricmc.net) als Modloader verwendet, dieser startet dann den eigentlichen Server.

Server mit Plugins

Für Plugins und generell als Serversoftware ist PaperMC (papermc.io) der Quasi-Standard. Es fing mit Bukkit an (Vanilla-Server mit Pluginfähigkeit), daraus entstand dann SpigotMC (optimiertes Bukkit), wovon dann wieder PaperMC geforkt wurde. Auch unterhalb von PaperMC geht die Fork-Kette weiter, wobei PaperMC als guter Kompromiss von Performance und akkuraten Spielmechaniken gilt und meistens empfohlen wird. Es gibt im Wiki von PaperMC auch einen Artikel, der beschreibt, wie man PaperMC vom Gameplay-Verhalten möglichst nahe an Vanilla annähern kann.

Kurz erwähnen möchte ich hier auch Folia, eine weitere Serversoftware von PaperMC - allerdings ausgelegt auf wirklich große survival-artige Server. Die Besonderheit bei Folia ist, dass es den einen großen Haupt-Game-Thread gibt, in dem alle Aktionen passieren. Folia teilt die Welt in distinkte Regionen auf, die getrennt voneinander arbeiten. Dadurch gibt es einen Game-Thread pro Region, wodurch sich die Last deutlich besser auf viele CPU-kerne verteilen lässt. Relevant wird das aber erst bei großen Spielerzahlen, Folia hat zudem auch viele Nachteile (Plugin-Kompatibilität, Entwicklungsstadium der Software, Bugs in Spielmechaniken, …).

Proxies

Es gibt für Minecraft spezielle Proxy-Software. Damit lassen sich mehrere Server zu einem “Netzwerk” verbinden und Spieler können via Commands oder andere Wege zwischen den Servern wechseln. Seit einiger Zeit gibt es im originalen Minecraft auch den Befehl /transfer, mit dem Spieler zu einem anderen Server transferiert werden können.

Ein Proxy ist sinnvoll, wenn man z.B. mehrere Minecraft-Server betreibt und zwischen diesen nahtlos wechseln können möchte oder auch dann, wenn man den eigentlichen Server zuhause betreibt, die Spieler aber über einen vServer beitreten sollen.

Wenn nur ein einzelner Server hinter einem Proxy betrieben werden soll, kann auch einfach eine Software wie HAProxy eingesetzt werden; PaperMC unterstützt bspw. das Proxy-Protokoll, mit dem die originale Client-IP erhalten bleibt.

Von den Entwicklern von SpigotMC gibt es hier Bungeecord, von den Entwicklern von PaperMC Velocity. Ich selbst nutze Velocity, da es die modernere Software ist und viele Plugins dafür existieren.

GeyserMC

Ein Spezialfall bei den Proxies ist Geyser. Das ist eine Software, die es Client mit der Bedrock Edition erlaubt, auf einem Server der Java-Edition zu spielen. Dazu werden fehlende Blöcke und Features möglichst nahe mit dem angehähert, was die Bedrock Edition bietet. Spieler verbinden sich mit Geyser, der dann wiederum die Verbindung zum eigentlichen Server aufbaut und übersetzt. Geyser läuft entweder als Plugin/Mod direkt auf dem Server, als Plugin auf dem Proxy oder Standalone, ich selbst habe es als Plugin auf dem Proxy installiert.

Empfohlene Plugins

Sofern der Server mit Plugins betrieben wird, habe ich hier einige Empfehlungen für Plugins, die ich fast immer installiere. Für Fabric gibt es diverse der genannten Plugins allerdings auch.

Chunky (Plugin und Mod)

Chunky gibt es für alle relevanten Modloader und Servertypen, also sowohl PaperMC als auch Fabric (und weitere). Das ist ein Tool, mit dem man Weltteile bzw. Chunks vorgenerieren kann. Vor dem Start eines neuen Servers generiere ich meistens mindestens 1000 Blöcke um den Spawn herum vor, da das Generieren von Chunks einer der rechenintensiveren Vorgänge auf einem Minecraft-Server ist. Vor allem am Anfang, wenn noch viele Spieler aktiv sind, merkt man einen Unterschied. Auch im Nether sollte man Weltteile vorgenerieren. Im End geht das auch, bringt aber aufgrund der Verteilung der End-Cities meiner Erfahrung nach nicht ganz so viel.

WorldEdit (bzw. FastAsyncWorldEdit)

Einer der Klassiker, das Plugin gibt es gefühlt schon immer. Wer es nicht kennt: Damit kann man schnell große Teile der Welt bearbeiten, Blöcke ersetzen, neu generieren usw.

FastAsyncWorldEdit ist für Server die bessere Wahl, da die Änderungen an der Welt asynchron ausgeführt werden und damit der Server nicht einfriert.

WorldGuard

Auch ein Klassiker. Damit kann z.B. festgelegt werden, dass nur bestimmte Spieler/Gruppen in einem Bereich bauen dürfen, auch Mob-Spawning lässt sich damit für einzelne Bereiche deaktiveren.

Dynmap

Das ist auch ein eher altes Plugin, allerdings bis heute gut gepflegt. Es erlaubt das Generieren einer webbasierten Karte des Servers, und das in 2D und auch in 3D. Das Plugin benötigt (vor allem bei den höheren Detailstufen) viel Rechenpower zum Rendern und auch einiges an Speicher bei größeren Welten. Ein Webserver ist integriert, es lässt sich allerdings auch ein externer Webserver dafür nutzen. Ich habe lowres als Qualitätslevel einstellt, das genügt mir. Wer etwas leichtgewichtigeres sucht, ist beim nächsten Plugin besser aufgehoben.

squaremap

squaremap bietet, ähnlich wie Dynmap, auch eine webbasierte Karte des Servers mit integriertem Webserver an, allerdings in geringerer Auflösung und ausschließlich in 2D. Dafür geht das Rendern sehr viel schneller und das Plugin ist generell auch leichtgewichtiger. Für einen kleinen privaten Server genügt squaremap vollkommen.

BlueMap

Das nächste Tool für eine webbasierte Karte. Bluemap hat die große Besonderheit, dass die Karte als 3D-Modelle gespeichert wird und sich die Welt im Browser daher frei erkunden lässt. Man kann beliebig zoomen, drehen usw, da die 3D-Modelle an den Browser übertragen werden und erst dort gerendet werden. BlueMap lässt sich zudem auch komplett unabhängig vom Server benutzen, so habe ich es auch im Einsatz. Ein kleines Script kopiert in regelmäßigen Abständen die Welt des Servers, führt BlueMap-CLI aus und stellt die generierten Daten über einen Webserver (Caddy, was auch sonst) bereit. Damit belastet es den Server selbst nicht, trotzdem finde ich es eine schöne Ergänzung zu Dynmap oder squaremap. Vor allem, um “mal eben” Freunden eigene Bauten auf dem Server auf dem Handy zeigen zu können, ist BlueMap wirklich super.

Plan

Plan ist ein Statistikplugin, das Einblicke in die Nutzung des Servers bietet. Man erfährt damit beispielsweise, wie die Auslastung des Servers aussieht, wann meistens gespielt wird und kann auch erkennen, ob neue Spieler erhalten bleiben oder eine hohe Fluktuation herrscht. Plan unterstützt auch diverse Plugins, um zusätzliche Daten anzuzeigen.

ViaVersion (und ViaBackwards)

Mit ViaVersion können Spieler mit neueren Minecraft-Versionen als der Server trotzdem beitreten. ViaBackwards hingegen erlaubt das Beitreten mit älteren Client-Versionen als der Server. Es gibt zusätzlich auch noch ViaRewind, damit können selbst Clients mit Version 1.7 und 1.8 noch beitreten - ob das sinnvoll ist, sei mal dahingestellt.

LuckPerms

LuckPerms ist so mit das bekannteste Plugin, um Permissions und Benutzergruppen zu verwalten. Mit MySQL oder einer anderen Datenbank als Backend lassen sich damit Berechtigungen auch über mehrere Server hinweg synchronisieren. Es gibt davon auch Versionen für Velocity, Fabric, Forge und weitere Server.

DiscordSRV

DiscordSRV ist eine Verbindung zwischen Discord und einem Minecraft-Server. Damit lässt sich bspw. der Ingame-Chat mit einem Discord-Channel verbinden. Auch lassen sich Discord-Rollen mit Permissions-Gruppen koppeln.

Distant Horizons server plugin

Distant Horizons ist eine Client-Mod, die eine deutlich höhere Sichtweite erlaubt. Dafür werden Versionen der Karte mit niedrigeren “Auflösungen” (LODs) generiert und alles außerhalb der gerade normal geladenen Chunks damit aufgefüllt. Damit ist der Performance-Einfluss eher gering. Distant Horizons braucht an sich keinen serverseitigen Support, die Mod speichert einfach Weltteile vom Server zwischen und generiert die LODs lokal.

Seit einiger Zeit gibt es ein Plugin für Server, womit die LOD-Dateien serverseitig generiert und vorgehalten werden können. Damit muss man nicht mehr jeden Weltteil besucht haben, um LODs dafür zu sehen. Es ist allerdings empfehlenswert, in der Config generate_new_chunks: false zu setzen, da sonst für die LODs neue Chunks generiert werden, was deutlich Ressourcen kostet.

Weitere Plugins

TabTPS

Damit lässt sich die aktuelle Performance des Servers (TPS, MSPT und weitere) an verschiedenen Positionen (Tabliste, Bossbar, Actionbar) anzeigen. Ich nutze das Plugin gerne, um die Leistung beim Spielen laufend im Auge zu behalten.

Multiverse-Core

Damit lassen sich mehrere Welten anlegen und verwalten, Spieler können auch zwischen den Welten wechseln. Ich habe auf meinem Server beispielsweise eine Kreativwelt, wo Spieler Gebäude vorbauen oder mit Redstone experimentieren können.

Mit weiteren Addons wie Multiverse-Inventories lassen sich die Features von Multiverse-Core noch erweitern.

SimpleVoiceChat

Das ist ein Plugin, was Ingame Voicechat hinzufügt. Dieser ist auf die direkte Umgebung des Spielers begrenzt und ermöglicht ein realistischeres Spielerlebnis. Es wird allerdings auch Client-Seitig eine Mod benötigt.

CoreProtect

Mit CoreProtect werden alle Aktionen auf dem Server geloggt und können damit auch rückgängig gemacht werden. Das ist vor allem für Survival-Server ohne ein System für “Grundstücke” praktisch und hat sich bei vergangenen Projekten bewährt.

EssentialsX

Ein Plugin, was viele kleinere Features (z.B. Befehle für Home oder Teleport-Anfragen) bündelt. Den Vorgänger habe ich früher viel genutzt, heutzutage installiere ich die benötigten Features als einzelne Plugins.

Scriptausführung mit Healthchecks überwachen

Fri, 31 Oct 2025 00:00:00 +0000

Ich nutze für regelmäßige Backups von Daten (z.B. Nextcloud) ein kleines Script, das Restic verwendet. Ich hatte allerdings schon mehrfach den Fall, dass ein Backup nicht sauber durchlief und das Backup-Repository damit gesperrt war und weitere Backups fehlschlugen, was ich dann natürlich erst Wochen (okay, Monate) später bemerkt habe.

Abhilfe schafft hier das Tool Healthchecks (https://github.com/healthchecks/healthchecks). Das funktioniert so, dass man Checks einrichtet und dafür eine Webhook-URL bekommt. In einem Script ruft man dann diese URL auf und setzt damit den Timer zurück. Sofern der Webhook nicht innerhalb der richtigen Zeit aufgerufen wird, wird ein Alert ausgelöst. Insgesamt also recht simpel.

Installation

Ich nutze hier, wie üblich, Docker. Hier meine docker-compose.yml:

 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:
 healthchecks:
 image: healthchecks/healthchecks:latest
 container_name: healthchecks
 environment:
 - DB=sqlite
 - DB_NAME=/data/hc.sqlite
 - DEBUG=False
 - DEFAULT_FROM_EMAIL=me@example.com
 - EMAIL_HOST=smtp.example.com
 - EMAIL_HOST_PASSWORD=MyMailPassword
 - EMAIL_HOST_USER=me@example.com
 - EMAIL_PORT=587
 - EMAIL_USE_TLS=True
 - SECRET_KEY=Hok4K0Va6EwaYltk4ah7muc223rUVmz3
 - SITE_ROOT=https://checks.example.com
 - DISCORD_CLIENT_ID=123123
 - DISCORD_CLIENT_SECRET=123123
 - REGISTRATION_OPEN=False
 ports:
 - 8000:8000
 volumes:
 - ./data:/data
 restart: unless-stopped

REGISTRATION_OPEN muss initial auf True gestellt werden, damit man sich selbst registrieren kann, danach sollte das allerdings wieder auf False gesetzt werden, damit sich keine fremden User registrieren können. Ich habe hier direkt die Discord-Integration eingerichtet, damit ich auf dem Weg auch Notifications verschicken kann. Die beiden Variablen sind aber natürlich optional.

Das Datenverzeichnis muss die richtigen Zugriffsrechte haben, damit der Container starten kann. Das geht schnell mittels

1
2


mkdir ./data
chown -R 999:999 ./data

Danach lässt sich der Stack mit docker compose up -d starten und die Seite aufrufen. Dort kann man sich dann mit einer E-Mail-Adresse registrieren.

Einbindung in ein Script

Um jetzt einen Check einzurichten, muss zuerst im Webinterface ein neuer Check erstellt werden. Dabei wird auch das normale Intervall (z.B. täglich) sowie eine Karenzzeit eingestellt.

Nun wird eine Check-URL angezeigt, ich nehme hier https://checks.example.com/ping/bla-bla-blub als Beispiel.

Simpler Check

Für einen einfachen Check, ob das Script gelaufen ist, reicht es, einen Befehl wie z.B.

1

curl -fsS -m 10 --retry 5 https://checks.example.com/ping/bla-bla-blub

mit der Check-URL auszuführen. Der Befehl sollte im Script als letztes ausgeführt werden, damit er erst ausgeführt wird, wenn alles andere funktioniert hat.

Check mit Laufzeitberechnung

Healthchecks kann auch die Laufzeit eines Scripts mit prüfen. Dazu wird erst der Endpunkt https://checks.example.com/ping/bla-bla-blub/start aufgerufen und nach Fertigstellung dann https://checks.example.com/ping/bla-bla-blub. Hierbei sollte auch noch eine Request-ID mitgegeben werden, um die einzelnen Ausführungen voneinander unterscheiden zu können.

Ich habe das bspw. so umgesetzt:

1
2
3
4
5
6
7
8


set -e
RID=`uuidgen`
HEALTHCHECK_ID=bla-bla-blub
curl -fsS -m 10 --retry 5 https://checks.example.com/ping/$HEALTHCHECK_ID/start?rid=$RID

# do backup

curl -fsS -m 10 --retry 5 https://checks.example.com/ping/$HEALTHCHECK_ID?rid=$RID

Nachdem das Script ausgeführt wurde, sieht das im Webinterface so aus:

Sollte ein Check nicht innerhalb der eingestellten Zeit aufgerufen werden, wird eine Notification ausgelöst. So sollte ich in Zukunft fehlschlagende Backups schneller bemerken.

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.

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.

Blocky - eine Alternative zu AdGuard Home und Pi-hole

Sun, 18 May 2025 00:00:00 +0000

Bisher habe ich als internen DNS-Resolver AdGuard Home eingesetzt. Das ist eine Alternative zu Pi-hole, die ebenfalls DNS-Blocking unterstützt. Die Wahl fiel damals auf AdGuard Home, da Pi-hole für eigene lokale Domains (die über einen anderen DNS-Server aufgelöst werden - das ist ein simpler bind9-Server) eher hakelig war und sich AdGuard Home einfach runder angefühlt hat.

Mit der Zeit gefiel mir aber die Ressourcenauslastung von AdGuard Home nicht, sowohl CPU als auch RAM waren etwas höher, als ich es mochte. Außerdem fielen mir teilweise längere Antwortzeiten beim DNS auf, wobei ich da nicht hundertprozentig sagen kann, ob es an AdGuard Home lag oder etwas anderes dahinter steckte. Außerdem wollte ich bessere Metriken bekommen, am besten über einen Prometheus-kompatiblen Metrikendpunkt.

Suche nach einer Alternative

Bei der Recherche nach einer Alternative zu AdGuard Home habe ich mir Pi-hole noch einmal angesehen, hatte dort aber Probleme, meine beiden lokalen Zonen über einen anderen Server aufzulösen. Den Technitium DNS-Server habe ich mir auch angesehen, aber der gefiel mir von der Konfiguration her nicht und auch hier habe ich nicht sofort herausfinden können, wie ich eine lokale Domain anders auflöse. Ein Setup mit einem Server wie Bind oder dnsmasq wollte ich ebenfalls nicht, da mir das von der Konfiguration her für die Blocklisten (benötigt ja dann Skripte, die die blockierten Einträge importieren) nicht gefallen hat. Bei den meisten Lösungen war auch die Herstellung einer Redundanz über einen zweiten Resolver nicht einfach.

Meine Anforderungen

Hier einmal meine Anforderungen als Liste:

Normale DNS-Auflösung und Caching
Unterstützung von Block- und Allowlists, möglichst in einem der gängigen Formate, damit die bekannten Listen funktionieren
Unterstützung von verschiedenen DNS-Servern für einzelne Domains, um lokale Domains an einen anderen Resolver weiterzuleiten
Metriken als Prometheus-Endpunkt
Redundanz über zweite Instanz auf anderem Host

Blocky - eine schlanke Alternative

Bei der Suche bin ich irgendwann auf Blocky gestoßen - das ist ein schlanker, in Go geschriebener DNS-Resolver, der als Alternative zu Pi-hole, AdGuard Home und co gedacht ist. Es gibt kein Webinterface, die Konfiguration findet über eine simple Yaml-Datei statt. Alle Features, die ich haben wollte, waren auch simpel einzurichten und funktionierten sofort. Die Performance ist ebenfalls super, gefühlt auch etwas flotter als AdGuard Home. Redundanz lässt sich simpel über das Kopieren der Config und Neustart vom Container lösen, das macht ein ganz einfaches Script alle x Stunden. Theoretisch könnte ich über Redis auch den Cache zentral halten, aber dafür müsste ich auch hier einen redundanten Redis-Service aufbauen - was ich hier auch einfach für Overkill halte.

Mein Erfahrung

Ich wollte Blocky erst einmal nur temporär zum Testen aktiv schalten - habe das dann aber vergessen. Nach ein paar Tagen fiel mir dann wieder ein, dass ich ja auf Blocky umgestellt hatte - bemerkt habe ich es ansonsten nicht. Was in diesem Fall ein wirklich gutes Zeichen ist. Blocky läuft bislang störungsfrei, liefert gute Metriken und benötigt wenig Ressourcen. Wir reden hier über ca 20MB RAM und vielleicht 0,1 % CPU-Auslastung von dem Container. AdGuard Home braucht, ohne aktive Clients seit einigen Tagen (aber auch ohne Neustart seit dem) grob 200MB RAM und hat immer wieder kurze Spikes auf >10 % CPU-Last, etwas was ich bei Blocky so überhaupt nicht wahrnehme.

Update: Die Ressourcenauslastung im Livebetrieb ist jetzt doch etwas höher, mit ein paar Blocklisten und als primärer DNS-Server ist die Auslastung vom Container bei 50-70MB bei allerdings weiterhin im Schnitt deutlich unter 1 % CPU-Auslastung (mit kurzen Spikes auf einige wenige Prozent). +

Meine Konfiguration

Hier einmal die Konfiguration, wie sie bei mir jetzt seit einiger Zeit im Einsatz ist:

 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


# ich habe leider kein ipv6, daher habe ich hier v6 vollständig deaktiviert und weiter unten auch AAAA-Records gefiltert.
connectIPVersion: v4

upstream:
 default:
 - 1.1.1.1
 - 8.8.8.8

blocking:
 blockType: nxDomain
 blackLists:
 ads:
 - https://raw.githubusercontent.com/RPiList/specials/master/Blocklisten/Win10Telemetry
 - https://raw.githubusercontent.com/RPiList/specials/master/Blocklisten/Phishing-Angriffe
 - https://raw.githubusercontent.com/RPiList/specials/master/Blocklisten/malware
 - https://raw.githubusercontent.com/RPiList/specials/master/Blocklisten/easylist
 - https://raw.githubusercontent.com/RPiList/specials/master/Blocklisten/MS-Office-Telemetry
 whiteLists:
 ads:
 - https://raw.githubusercontent.com/m0zgen/dns-hole/master/whitelist.txt
 - https://raw.githubusercontent.com/m0zgen/dns-hole/master/vendors-wl/microsoft.txt
 - https://raw.githubusercontent.com/m0zgen/dns-hole/master/vendors-wl/google.txt
 - https://raw.githubusercontent.com/m0zgen/dns-hole/master/regex/common-wl.txt
 clientGroupsBlock:
 default:
 - ads

caching:
 cacheTimeNegative: 1m

filtering:
 queryTypes:
 - AAAA


# Konfiguration der lokalen Domains und Reverse-IP-Lookups zum DNS-Server unter 192.168.1.15
conditional:
 fallbackUpstream: false
 mapping:
 home.local: 192.168.1.15
 homelab.local: 192.168.1.15
 179.168.192.in-addr.arpa: 192.168.1.15
 178.168.192.in-addr.arpa: 192.168.1.15

ports:
 dns: 53
 http: 4000

bootstrapDns: 1.1.1.1

prometheus:
 enable: true
 path: /metrics

queryLog:
 type: none