Server on SecretMine.de

Planka - leider keine Empfehlung mehr

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

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

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

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

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

Was hostet man zuhause - und was eher nicht

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

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

Die Möglichkeiten

Zuhause hosten

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

Typische Kandidaten sind:

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

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

Lieber auf einen vServer

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

Gute Kandidaten sind:

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

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

Besser extern nutzen bzw. nicht selbst hosten

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

Typische Beispiele sind:

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

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

Fazit

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

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

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

Firefly III - Self-Hosted und Open Source Haushaltsbuch

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

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

Warum überhaupt so ein Tool?

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

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

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

Installation und Betrieb

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

Bedienung

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

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

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

Fazit

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

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

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

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

Was ist Matrix?

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

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

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

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

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

Politischer Kontext

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

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

Installation

Ein alltagstaugliches Matrix-Setup besteht aus mehreren Komponenten:

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

Von der Domaingestaltung habe ich bei mir etwa folgendes Setup:

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

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

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

Docker

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

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


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

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

1

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

Die relevanten Config-Files:

Element (config/element-config.json):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

1
2
3
4
5


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

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

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


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

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

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


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

Reverse-Proxy

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

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


matrix.example.com {
 reverse_proxy 10.0.0.2:8008
}

chat.example.com {
 reverse_proxy 10.0.0.2:8009
}

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

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

Delegation einrichten

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

.well-known/matrix/server:

1
2
3


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

.well-known/matrix/client:

1
2
3
4
5


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

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

Initialen User erstellen

Mittels

1

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

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

Clients einrichten

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

Verteilter Speicher im Homelab

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

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

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

Anforderungen

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

Muss:

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

Soll:

Open Source

Kann:

Metriken/Monitoring

Softwarelösungen

Ceph

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

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

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

GlusterFS

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

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

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

MooseFS

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

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

LizardFS

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

LeilFS (vorher SaunaFS)

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

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

Dennoch ist es eine flexible und eher ressourcensparsame Option.

Weitere Lösungen

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

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

Fazit

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

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

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

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

Hochverfügbarkeit mit Keepalived

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

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

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

Wie funktioniert das?

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

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

Typische Szenarien

DNS

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

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

Webserver

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

Keepalived und Docker Swarm

Hier wirds cool.

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

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

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

Beispielkonfiguration

Hier eine kurze Beispielconfig:

Node swarm-1:

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


global_defs {
 router_id swarm-1
}

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

Node swarm-2:

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


global_defs {
 router_id swarm-2
}

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

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

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

Kubernetes

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

Fazit

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

Latenzmessungen mit Smokeping

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

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

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

Ping-Ziele

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

Konfiguration

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

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


+ Local
menu = Local
title = Local Network

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

+ Internet
menu = Internet
title = Internet

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

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

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

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

Statistiken

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

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

Alternativen zu Smokeping

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

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

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

Fazit

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

Memos - Notizen und Tagebuch

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

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

Deployment

1
2
3
4
5
6
7


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

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

Nutzung im Alltag

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

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

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

Fazit

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

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

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

Storage-Cluster - Ein erster PoC

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

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

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

Ergebnisse vom PoC

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

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

Alternative zu Ceph

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

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

Wie es weitergeht

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

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

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

Code-Server

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

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

Hintergrund

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

Meine Lösung

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

Proxy für Preview

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

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

Fazit

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

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

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.

Ein neues (bzw. altes) Mainboard für das NAS

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

Mein NAS läuft nun seit vielen Jahren mit einem i3 4130. Das ist eine Haswell-CPU von ca 2013. Das NAS ist meistens im Standby und wird nur bei Bedarf via HomeAssistant eingeschaltet und kann von dort aus auch wieder in den Standby gesetzt werden.

Das Problem

Seit diversen Monaten kommt es vor, dass das NAS nach einiger Zeit beim Aufwecken hängen bleibt, teilweise auch bei größeren Transfers. Das Gerät ist an, aber via Ping (und auch auf allen anderen Wegen) nicht mehr erreichbar. Eine Kernel-Panic ist dann auch auf dem Bildschirm zu sehen. Ich weiß, dass das Mainboard einen Defekt hat, die USB-Ports funktionieren nicht mehr sauber. Von daher vermute ich dort irgendwo ein Problem.

Die mögliche Lösung

Ich habe ein gebrauchtes Bundle mit einem i3 6100, einem Mainboard (Gigabyte H110M-S03) und 8GB DDR4-RAM bestellt. Da die CPU ähnlich alt (ca 2015) ist, war das ganze mit unter 40 € auch entsprechend preiswert. Die Wahl fiel auch primär aufgrund des Preises auf so ein Bundle. Besondere Ansprüche an die CPU-Leistung oder den RAM habe ich nicht, da das Teil nur als Dateiserver dient und dort keine weiteren Services laufen. Daher ist das Downgrade von 16 GB auf 9 GB RAM auch okay.

Laut Benchmarks ist der i3 6100 etwa 20% schneller als der i3 4130, vor allem kann aber die Encoding-Engine der iGPU neben h.264 auch h.265 bzw. HEVC in Hardware kodieren. Das ist vor allem für einen Mediasever mit Transcoding hilfreich. Neuere Hardware wäre zwar nett, aber die zusätzliche Leistung brauche ich nicht, der geringere Stromverbrauch ist durch die nicht dauerhafte Nutzung nicht so relevant und Lust auf die deutlich höheren Kosten habe ich auch nicht. Von daher genügt Skylake.

Umbau

Hardware abseits von Mainboard/CPU/RAM:

SATA-HBA mit 6 Ports (günstiges Modell mit einem ASM1166-Chip)
2,5 GBit/s Netzwerkkarte (günstiges Modell mit einem RTL8125B-Chip)
Samsung 850 Evo mit 120 GB als Cache (hauptsächlich genutzt für Daten von Docker-Containern)
1x 4 TB HDD als Parity
3x 3 TB HDD als Datenplatten
1x 4 TB HDD als Datenplatte

Damit kommt eine nutzbare Kapazität von 13 TB zustande.

Der Umbau war höchst unkompliziert. Altes Mainboard raus, neues Mainboard rein, alles wieder verkabeln, fertig. unRAID ist weitestgehend egal, auf was für Hardware es gerade läuft, solange alle Festplatten noch da sind. An der Stelle war also nichts weiter zu tun, ich musste nur noch die neue MAC-Adresse im Router für die DHCP-Zuweisung und in HomeAssistant für Wake-on-LAN anpassen.

Parallel habe ich auch den USB-Stick für das unRAID OS getauscht. Vorher war es ein Transcend JetFlash 700 mit 16 GB, nun ist es ein Samsung BAR Plus mit 32 GB. Die Wahl fiel auf diesen Stick, da der im unRAID-Forum und auch im entsprechenden Subreddit empfohlen wurde. unRAID inkl. Lizenz auf den neuen Stick zu migrieren war auch recht einfach. Ich habe einfach mit dd den alten Stick auf den neuen kopiert, die Partition vergrößert und wieder bootbar gemacht. Die Lizenz lässt sich über unRAID bzw. deren Kundencenter auch recht einfach auf einen neuen Stick migrieren, da hatte ich allerdings kurz das Problem, dass zwei alte Keys (der ursprüngliche Trial-Key sowie ein Key von vor einem Lizenzupgrade) noch auf dem Stick waren. Die musste ich natürlich löschen.

Hat es geholfen?

Den Tausch habe ich Anfang Januar durchgeführt, das ist jetzt etwa 6 Wochen her. Seit dem ist der Fall nur noch ein einziges Mal eingetreten, spürbar seltener als vorher. Auch die Probleme bei größeren Transfers (oder teilweise auch nur Container-Updates) sind seit dem nicht mehr aufgetreten. Den fehlenden Arbeitsspeicher spüre ich nicht, die zusätzliche CPU-Leistung allerdings auch nicht.

Das es einen weiteren Crash gab ist natürlich nicht erfreulich. Daher werde ich mein IP-KVM an das NAS anschließen, um mir im Bedarfsfall zumindest die Kernel-Panic ansehen zu können. Falls es dabei Erkenntnisse gibt, werde ich einen weiteren Post schreiben.

Als weitere Ursache fällt mir eigentlich nur noch der HBA ein. Die Probleme sind älter als die Netzwerkkarte, daher denke ich nicht, dass dort ein Problem liegt. Theoretisch kann auch die SSD oder eine der HDDs einen Fehler haben, der zu Lesefehlern führt, aber das ist wahrscheinlich schwer zu diagnostizieren.

Fazit

Der Tausch war notwendig und durch die gebrauchte Hardware günstig. Das Endergebnis sieht gut aus, es läuft stabiler als vorher. Perfekt ist es allerdings weiterhin nicht. Vermutlich wäre es sinnvoll, das NAS dauerhaft laufen zu lassen; das möchte ich aber aufgrund des Stromverbrauchs und auch der Wärme- und Geräuschentwicklung nicht. Von daher werde ich mit dem neuen Stand erst einmal leben.

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.

Docker Swarm nach zwei Monaten

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

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

Wie das Setup aussieht

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

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

Was mir im Betrieb aufgefallen ist

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

Wie es weitergeht

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

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

Mein Backupkonzept - 2025 Edition

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

Ein kleines Weihnachtsgeschenk? Naja. Wie dem auch sei.

Ich habe in den letzten Monaten immer wieder an meinem Backupkonzept gefeilt, bis es in der jetzigen Form stabil und weitestgehend automatisiert läuft. Das Ganze ist ein Mix aus Proxmox-Backups und Datei-Backups mit Restic - mit Fokus auf Verschlüsselung und Praktikabilität.

Proxmox-Cluster zuhause

Mein Haupt-Homelab läuft als Proxmox-Cluster. Alle VMs und LXC-Container werden täglich mit dem Proxmox Backup Server gesichert. Das Ziel ist eine billige große SSD im Cluster. Für kritische Systeme (Nextcloud, DNS, Reverse Proxy etc.) gibt es zusätzlich ein Offsite-Backup über S3 zu Backblaze B2. Der Part läuft verschlüsselt, da ich keinem Anbieter 100%ig vertraue. Wichtig war mir, dass der Backup-Server dedupliziert und komprimiert, um die Kosten für den S3-Storage möglichst gering zu halten. Da Proxmox Backup Server das inzwischen nativ kann, war der Aufwand überschaubar.

Neben dem automatischen täglichen Backup gibt es außerdem einen manuellen Sync auf eine externe Festplatte, die normalerweise im Keller lagert. Diese ist als “Removable Storage” im Backup Server eingehängt und dient als zusätzliche Offline-Kopie im Worst-Case. Ich habe auch einen Thin Client mit einer Festplatte und Proxmox Backup Server im Keller, zu dem ich unregelmäßig die Backups spiegele. Aufgrund der geringen Bandbreite in den Keller will ich diese Variante aber ablösen, dafür habe ich mit der externen Festplatte begonnen.

Nutzerdaten (Nextcloud, Gameserver usw.)

Für Dienste, die viele Nutzerdaten enthalten, setze ich zusätzlich auf Restic. Nextcloud-Daten und Backups der Gameserver werden etwa alle acht Stunden auf eine Hetzner Storage Box geladen. Auch hier läuft alles verschlüsselt, und die Snapshots lassen sich im Notfall granular wiederherstellen. Restic erfüllt neben der Verschlüsselung auch hier wieder die Kriterien mit Deduplizierung und Komprimierung, damit ich möglichst effizient viele Snapshots speichern kann.

Bei der Nextcloud gibt es generell die Besonderheit, dass ich alle Daten, um die Nextcloud wiederherzustellen (www-Verzeichnis, Datenverzeichnis, Dump der Datenbank) via Restic sichere, die virtuelle Festplatte mit den Nextcloud-Daten wird via Proxmox Backup Server aktuell wegen des Speicherbedarfs tatsächlich nicht gesichert.

NAS

Im Keller steht ein Backup-NAS mit TrueNAS. Hier laufen in unregelmäßigen Abständen manuelle rsync-Jobs, die Daten vom Haupt-NAS kopieren. Über ZFS-Snapshots sind ältere Stände ebenfalls abrufbar. Die Variante mit einem zusätzlichen NAS hat hauptsächlich Kostengründe, da das Speichern von über 10TB inkl. Snapshots sonst sehr viel teurer gewesen wäre.

vServer-Backups

Auf meinen externen vServern (hauptsächlich Docker-Dienste, diese Website und mein Mailserver) verwende ich ebenfalls Restic mit einer Hetzner Storage Box als Ziel.

Sicherung der Keys und Monitoring

Ich hatte zwischenzeitlich die Situation, dass die Keys für alle Offsite-Backups nur in einer Keepass-Datei in meiner Nextcloud gespeichert waren - die wiederum Teil genau dieser Offsite-Backups sind. Da ich alles verschlüssele, was offsite landet, hätte ich im Worst-Case zwar Backups, aber keinen Zugang mehr zu diesen Backups gehabt. Deshalb lagern die Keys mittlerweile zusätzlich auf einem USB-Stick bei meinen Eltern, just in case.

Die Backup-Scripte werden mittels Healthchecks auf ihre Ausführung überwacht, damit nicht (schon wieder) monatelang keine Backups passieren.

Offene Punkte

Was ich bisher zu selten mache sind Restore-Tests. Ich habe zwar bei jeder verwendeten Technik irgendwann mal einen Test-Restore gemacht und geprüft, aber seitdem nicht wieder getestet. Ich möchte für einige wichtige Dinge wie z.B. die Nextcloud auch Langzeitbackups einführen, die einen monatlichen Stand für mehrere Jahre effizient und günstig vorhalten können. Restic nutze ich aktuell nur mit --keep-last n, hier sollte ich eine bessere Retention Policy einsetzen. Mein Backup-Script loggt aktuell auch zu wenig - das ist generell ein offener Punkt.

Auch eine Dokumentation, wie Dinge wiederhergestellt werden können, fehlt komplett. An dem Thema bin ich aber aktuell dran. Basis wird eine möglichst automatische Datensammlung mit Ansible, Ergänzung mit eigenen Informationen und dann Erzeugen eines Wikis mittels MKDocs. Wenn ich das irgendwann mal fertig habe, gibt es dazu auch wieder einen Post.

Eine Ansible-Rolle zum Deployen vom Backup-Script wäre auch noch angenehm, aktuell passiert das komplett händisch.

Fazit

Das Setup ist über die Zeit gewachsen und sicher nicht perfekt - aber es deckt die wichtigsten Fälle ab: Hardwaredefekt, Ransomware, versehentliches Löschen und kompletten Verlust vom Cluster (bspw. durch einen Brand). Und das ganze wie üblich in möglichst kosteneffizient. Einige Dinge muss ich allerdings noch nachbessern.

Containerorchestrierung im Homelab

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

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

Orchestrierungstools

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

Docker Compose Stacks

…also die bisherige Lösung.

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

Vorteile:

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

Nachteile:

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

Kubernetes

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

Vorteile:

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

Nachteile:

Komplex in der Verwaltung
Hoher Ressourcenoverhead

Docker Swarm

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

Vorteile:

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

Nachteile:

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

Meine Entscheidung

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

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

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

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

Proxmox Backup Server 4 mit S3 Storage - ein Update nach einigen Wochen

Tue, 09 Dec 2025 00:00:00 +0000

Vor einiger Zeit habe ich ja Proxmox Backup Server 4 mit S3 Storage als Offsite-Backup eingerichtet. Hier nun also ein kleiner Zwischenbericht zur Speicherbelegung.

Ich sichere aktuell 8 LXCs zu dem Backup-Repo, pro CT werden jeweils drei Backups behalten. Im Bucket liegen 11,5 GB und etwa 7500 Dateien. PBS scheint aber im Bucket nur eher wenige Aktionen durchzuführen - auf der Abrechnung von Backblaze ist nur der belegte Speicher relevant, die S3-Operationen liegen bei mir komplett im kostenfreien Bereich. Proxmox Backup Server zeigt bei dem Repo eine Belegung von 8 GB an, das scheint nur der lokal zwischengespeicherte Part zu sein. Der Deduplizierungsfaktor liegt bei etwas über 7, das entspricht grob dem Faktor, den ich auch sonst erreiche.

Insgesamt sieht es für mich bisher so aus, als ob das ganze gut funktioniert. Große Restore-Tests habe ich allerdings weiterhin nicht gemacht und Stand heute ist das S3-Feature auch weiterhin nur eine Tech-Preview - also mit Vorsicht zu genießen und sollte nicht das einzige Backup sein.

Nutzung alter Hardware als Minecraft-Server

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

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

Hardware

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

Software

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

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

Stromverbrauch

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

Benchmark

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

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


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

Mon Nov 17 08:34:30 PM CET 2025

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

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

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

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

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

YABS completed in 13 min 41 sec

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.

Die Historie meines Labs (2016 bis Q3 2025)

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

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

Vor 2016

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

2016 - erste richtige Anfänge

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

2017

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

2018

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

2019

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

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

2020

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

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

2021

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

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

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

2022

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

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

2023

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

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

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

2024

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

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

2025

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

Was geplant ist

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

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

Proxmox Backup Server 4 mit S3 Storage - diesmal in Richtig

Thu, 25 Sep 2025 00:00:00 +0000

Proxmox Backup Server 4 hat eine erste tech preview für S3-Speicher mit drin, um offsite Backups zu speichern. Das ist durch die Deduplizierung und Komprimierung ideal, um günstig Backups zu machen. Als S3-Provider nutze ich Backblaze B2, da der Storage hier recht günstig ist (okay, ich hab auch einfach schon einen Account da). Die Backups werden auch lokal zwischengespeichert, es bedeutet also einiges an Schreibvorgängen auf der SSD/HDD.

Achtung! Das ganze ist noch im Preview-Stadium und ist mit Vorsicht zu genießen!

Bucket erstellen

Im Backblaze B2 Webinterface einen neuen Bucket anlegen.
- Bucket-Name: lowercase (z. B. pbsoffsite)
- Endpunkt notieren, z. B.: s3.eu-central-002.backblazeb2.com
Lifecycle-Einstellungen für den Bucket setzen:
- Nur die letzte Version der Datei aufbewahren

Application Keys erstellen

Im Menü Application Keys → Add New wählen.
Namen definieren, z. B.: PBSOffsiteKey
Im Feld Allow access to Bucket(s) den eben erstellten Bucket auswählen.
Haken setzen bei Allow List All Bucket Names

Die Ausgabe enthält die benötigten Werte:

1
2


keyID: keyIDblablablub
applicationKey: blablablub

S3 Endpoint im PBS hinzufügen

Im PBS-Webinterface einen S3-Endpoint hinzufügen:

ID: bspw. backblaze
Endpoint: ``{{bucket}}.s3.{{region}}.backblazeb2.com`
Region aus dem Endpunkt ableiten, z. B. eu-central-002
Access Key (keyID) und Secret Key (applicationKey) eintragen
Advanced → Provider Quirks: Skip If-None-Match header aktivieren

Cache-Verzeichnis erstellen

Die Doku empfiehlt hier 64-128GB Speicher. Ich nutze LVM-Thin und habe dementsprechend auf dem Host ein neues Volume erstellt und gemountet. Das Anlegen eines neuen logischen Volumes bei LVM geht mit folgendem Befehl:

1

lvcreate -V 100G -T vg-data/thinpool -n pbs-s3

Gemountet habe ich das unter /mnt/pbs-s3.

Datastore hinzufügen

Name: backblaze
Local Cache: /mnt/pbs-s3
S3 Endpoint ID: passenden Endpoint auswählen
Bucket: den angelegten Bucket auswählen. Wenn hier nichts auftaucht oder ein Fehler erscheint, stimmt was mit den Zugangsdaten nicht oder der Bucketname ist z.B. nicht kleingeschrieben.
Prune Options: nach Bedarf konfigurieren

Datastore nutzen

Ich habe nun also in Proxmox einen zweiten Proxmox Backup Server als Storage eingefügt und einen zweiten Backup-Job mit dem Offsite-Storage und nur den wichtigsten Containern und VMs angelegt. Ich lasse das aktuell erstmal nur mit eher kleinen Backups laufen, bis ich ein Gefühl dafür bekommen habe, was mich das dann am Ende so kostet. Irgendwann wird dementsprechend ein Update-Post folgen.

Ein Restore-Test steht auch noch aus…

Lokaler APT-Cache mit Apt-Cacher NG

Mon, 08 Sep 2025 00:00:00 +0000

Caching ist ein alter Hut - früher vor allem genutzt, um bei vielen Clients hinter einem Internetanschluss Assets wie Bilder und Videos möglichst nur einmal herunterzuladen und dann bei weiteren Aufrufen das Bild aus dem Cache auszuliefern. Kurz gesagt, um Bandbreite zu sparen bzw. die Auslieferung von Daten an mehrere Clients zu beschleunigen.

Das Ganze lässt sich auch für APT (den Paketmanager, den bspw. Debian und Ubuntu einsetzen) umsetzen - das ist tatsächlich auch einer der Gründe, warum APT-Repos heutzutage immer noch meistens via http und nicht https ausgeliefert werden. Mit https kommt Verschlüsselung dazu, was Caching ungemein erschwert.

Was bringt das?

Ich habe bekanntlich mehrere physische Server sowie irgendwas um die 30-40 virtuellen Server (sowohl virtuelle Maschinen als auch containerbasiert, z. B. LXC), die regelmäßig mit Updates versorgt werden wollen. Bisher hat sich dann jeder Server seine Pakete direkt aus dem Internet gezogen, was natürlich für eine gute Menge an Traffic gesorgt hat. Mit einem Cache lädt jeweils nur der erste Server ein bestimmtes Paket durch den Cache aus dem Internet herunter, die anderen Server ziehen sich das Paket dann vom Cache. Der Cache funktioniert dabei als Proxy, bis auf die Einstellungen für den Proxy muss bei APT nichts angepasst werden. Der Cache spart bei mir primär ein wenig Zeit, da vor allem bei größeren Paketen dann alle weiteren Server mit Geschwindigkeiten nahe an 1 GBit/s die Pakete herunterladen können.

Automatische Nutzung mittels auto-apt-proxy

Es gibt für Debian und Ubuntu (und diverse weitere Distros) das Tool auto-apt-proxy (Paketname ist identisch). Damit lässt sich ein Apt-Proxy (was der Cache ja auch ist) im Netzwerk automatisch erkennen und nutzen. Ich habe die dafür notwendigen DNS-Einträge lokal hinzugefügt und via Ansible das Paket auf allen Servern installiert, damit nutzt jeder Server direkt den Proxy, ohne weitere manuelle Einstellungen vornehmen zu müssen. Neben DNS gibt es allerdings auch andere Methoden, um auto-apt-proxy den korrenten Proxy zu signalisieren.

Wie viel bringt das?

Apt-Cacher NG hat eine Statistikseite (http://ip-vom-cache:3142/acng-report.html), die einige Einblicke in den Cache erlauben. Ich erreiche insgesamt eine Bandbreitenersparnis von über 70%, das kann sich schon sehen lassen. Hier einmal die Details:

Meine Config

Die Datei befindet sich unter /etc/apt-cacher-ng/acng.conf. Relevant ist vor allem das CacheDir, darin werden die zwischengespeicherten Pakete abgelegt.

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


CacheDir: /mnt/data/apt-cacher-ng
LogDir: /var/log/apt-cacher-ng
SupportDir: /usr/lib/apt-cacher-ng
Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian # Debian Archives
Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu Archives
Remap-klxrep: file:kali_mirrors /kali ; file:backends_kali # Kali Linux Archives
Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # incomplete, please create this file or specify preferred mirrors here
Remap-sfnet: file:sfnet_mirrors # ; file:backends_sfnet # incomplete, please create this file or specify preferred mirrors here
Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch Linux
Remap-fedora: file:fedora_mirrors # Fedora Linux
Remap-epel: file:epel_mirrors # Fedora EPEL
Remap-slrep: file:sl_mirrors # Scientific Linux
Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo Archives
debian-security ; deb.debian.org/debian-security security.debian.org cdn-fastly.deb.debian.org/debian-security
ReportPage: acng-report.html
ExThreshold: 4
FollowIndexFileRemoval: 1
LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng
AllowUserPorts: 80 443
PassThroughPattern: .* # this would allow CONNECT to everything

Das meiste davon ist Standard, ich habe vor allem PassThroughPattern ergänzt, damit auch Fremd-Repos mit https, die ja nicht ohne weiteres gecached werden können, weiterhin funktionieren. Was die Optionen konkret machen ist in der Default-Config gut erklärt. Wenn man mehrere Apt-Cacher-NG hintereinander schalten möchte (ich habe einen zweiten im Keller) sollte noch folgende Option gesetzt werden:

1

VfileUseRangeOps: 0

Stromverbrauch im Homelab optimieren

Sat, 16 Aug 2025 00:00:00 +0000

Ich achte bekanntlich stark darauf, den Stromverbrauch meines Homelabs im Idle-Zustand möglichst gering zu halten. Ich möchte hier einmal sammeln, worauf ich dabei achte und wie ich meine Hardware auswähle. Alles sind Tipps und nicht unbedingt allgemeingültig.

Monitoring

Der Stromverbrauch sollte mit z.B. einem Smart Plug überwacht werden, das ermöglicht auch das Erkennen von unerwarteten Erhöhungen Bisher messe ich den Stromverbrauch für das gesamte Lab, schöner wäre hier der Verbrauch pro Gerät. Dann könnte man z.B. anhand der CPU-Last sogar grob den Stromverbrauch pro Dienst berechnen. Ob ich das umsetze, weiß ich allerdings noch nicht, da jede weitere WLAN-Steckdose den Gesamtverbrauch wieder um ~1 Watt erhöht.

Hardware

Bevor zum Energie einsparen zusätzliche Hardware angeschafft werden soll, sollte man immer prüfen, ob sich die Stromersparnis im Vergleich zu den Anschaffungskosten überhaupt rechnet. Es kann sich auch lohnen, nicht ganz topaktuelle Hardware für deutlich weniger Geld zu kaufen. Bei einer Nutzungsdauer von x Jahren kann neuere Hardware durch den höheren Preis schnell mal die Stromersparnisse komplett aufheben bzw. auch übertreffen.

Weniger ist mehr

Jedes zusätzliche Gerät - also sowohl größere Geräte wie Router/Switch/Mini-PC als auch kleinere Geräte wie SSDs/HDDs - verbraucht Strom. Bei einem einzelnen RAM-Riegel oder einer NVMe-SSD ist der Unterschied marginal, bei einer HDD können das aber schnell mehrere Watt werden. Sofern hier z.B. mehrere HDDs zwecks Redundanz oder Kapazität benötigt werden, könnte man entweder möglichst große HDDs verwenden (um die Anzahl zu reduzieren), auf SSDs umsteigen oder z.B. ein externes NAS, das meistens im Standby ist, benutzen.

Auch ist es häufig besser, einen stärkeren Mini-PC als mehrere schwächere zu nutzen, das reduziert den “Overhead-Verbrauch” durch z.B. Mainboards, Netzteile, NICs und die weitere zusätzliche Hardware. Zwecks Redundanz können allerdings trotzdem mehrere Geräte sehr sinnvoll sein.

Generell sollte so wenig Hardware wie möglich verbaut werden, ich deaktiviere z.B. bei den Thin Clients auch den Audiochip. Das macht nicht viel aus, aber ist simpel zu machen.

Auf Severhardware eher verzichten

Serverhardware bringt meistens Management-Features wie eine integrierte KVM-Lösung (IPMI, ILO, IDRAC, …) mit. Das ist letztendlich ein kompletter weiterer Rechner, der im Server läuft, was natürlich wieder mehrere Watt an Strom zusätzlich verbraucht.

Passend dimensionieren

Beispielsweise benötigt ein Switch mit 48 Ports deutlich mehr Strom als ein Switch mit 8 Ports Das selbe gilt auch für Router und Server - alles sollte angemessen sein (im Zweifelsfall zum Ausbauen allerdings lieber etwas größer/leistungsstärker als eigentlich notwendig).

Neuer ist meistens besser (oder zumindest effizienter)

Vor allem bei Computern (und damit auch Servern bzw. Mini-PCs/Thin-Clients) sind modernere Geräte meistens energieeffizienter. Der Fujitsu Futro S740 braucht z.B. grob die Hälfte an Strom wie der Futro S720, obwohl der S740 deutlich mehr Rechenleistung besitzt. Bei Desktop-Hardware sollte man allerdings beachten, dass Mainboards und Netzteile alleine schon mehrere Watt verbrauchen, weshalb Mini-PCs häufig die bessere Wahl sind, wenn man auf den IO verzichten kann.

Effiziente Netzteile nutzen

Selbsterklärend.

10G Ethernet via RJ45 vermeiden

Für Netzwerkverbindungen mit 10G sollten bevorzugt entweder DACs verwendet werden, alternativ ist auch Glasfaser deutlich effizienter als 10G über RJ45.

Switches mit integriertem POE nutzen

“Sofern mehrere PoE-Geräte genutzt werden, ist es meistens besser, einen Switch mit PoE zu nutzen, statt jedes Gerät mit einem eigenen Injektor zu versehen.

Geräte nicht dauerhaft betreiben

Wenn ein NAS z.B. nur sporadisch genutzt wird, muss es auch nicht dauerhaft laufen. Automatischer Standby plus Wake on LAN hat sich bei mir als Betriebsmodus bewährt. Ein Rechner im Standby verbraucht natürlich auch einige wenige Watt, aber dafür ist das Gerät nach dem Aufwecken auch innerhalb von Sekunden verfügbar.

Auch kann man überlegen, ob man im Homelab permanent die komplette Power braucht oder einzelne Hosts nur bei Bedarf einschaltet.

Displays abstecken

Sofern ein Display am Server angeschlossen ist (selbst wenn es hinter einem KVM-Switch o.ä. ist), ist die integrierte GPU aktiv. Das kostet Strom.

Software

CPU-Governor

Der Govenor gibt an, anhand welcher Parameter und wie schnell der CPU-Takt angepasst wird. Die gängigsten sind:

powersave: Nutzt dauerhaft niedrigsten Takt, nicht empfohlen
performance: Nutzt dauerhaft höchsten Takt, nicht empfohlen
ondemand: Passt den Takt laufend an die aktuelle CPU-Auslastung an
conservative: Ähnlich zu ondemand, allerdings etwas “ruhiger” im Scaling-Verhalten

C-States

Moderne CPUs können die Leistung und damit auch die Stromaufnahme senken, das sind sogenannte C-States. Höhere States sind dabei effizientere Betriebsmodi. Mit Tools wie powertop lässt sich prüfen, ob die CPU C-States außerhalb von 0 erreicht. Wenn nicht, sollte einerseits im BIOS geprüft werden, ob C-States (teilweise versteckt sich das hinter Einstellungen bzgl. Energieverwaltung) aktiv sind, andererseits müssen auch die angeschlossenen Geräte auf die Unterstützung geprüft werden. Bei PCIe ist das beispielsweise ASPM.

Container statt VMs

Container (Docker oder auch LXC in Proxmox) sind leichtgewichtiger als VMs, sorgen dadurch für eine geringere CPU-Auslastung, was wiederum den Stromverbrauch geringer hält.

Proxmox-VMs

Bei VMs in Proxmox ist es sinnvoll, use tablet as pointer in den Optionen zu deaktivieren. Das erschwert die Bedienung über die Webkonsole deutlich, lässt sich aber auch jederzeit ohne Neustart wieder aktivieren. Das Deaktivieren der Option spart CPU-Last ein.

Generelle CPU-Last

Höhere CPU-Last bedeutet mehr Stromverbrauch. Ganz einfach. Je geringer die durchschnittliche Auslastung ist, desto besser. Mehr laufende Dienste bedeuten also eigentlich immer einen höheren Stromverbrauch.

Effiziente Software auswählen

Ich habe dazu gerade kein konkretes Beispiel. Ich achte aber auch auf den Ressourcenbedarf, wenn ich Software zum Selbsthosten auswähle.

ZRAM nutzen

ZRAM ist im Grunde komprimierter SWAP im RAM, was einerseits performanter ist und andererseits Lese-/Schreiboperationen auf dem Datenträger einspart.

Inkrementelle Backups statt Vollbackups

Viele Backuplösungen (z.B. Proxmox Backup Server, restic, …) können inkrementelle Sicherungen erstellen, also nur die seit dem letzten Snapshot geänderten Daten sichern. Das spart Zeit und Rechenleistung ein.

Dienste im Rechenzentrum betreiben

Manche Dienste lassen sich auf einem günstigen vServer effizienter betreiben als zuhause dafür Hardware und Strom zu bezahlen. Das ist allerdings immer eine Abwägungssache.

Proxmox VE 9

Fri, 08 Aug 2025 00:00:00 +0000

Inhalt der neuen Version

Proxmox VE 9 ist vor ein paar Tagen veröffentlicht (Roadmap und Changelog hier: https://pve.proxmox.com/wiki/Roadmap). Die wichtigsten Features in Kürze:

Debian 13 (Trixie) als Basis statt Debian 12 (Bookworm)
VM Snapshots bei tick-provisioned LVM
HA-Rules
Mehr Features für SDN
Neues mobiles Webinterface
Bei ZFS können neue Devices hinzugefügt werden
Hotplug von Devices bei LXC

Das volle Changelog ist auf der verlinkten Seite zu finden.

Das Upgrade

Ein Proxmox-Update ist generell kein Hexenwerk. Ich aktualisiere vorerst nur den Cluster im Keller, mit dem Production-Part warte ich noch etwas.

Da auf dem ersten PVE-Knoten auch Proxmox Backup Server installiert ist, aktualisiere ich diesen parallel. Das ist eigentlich genauso einfach - man ändert einfach den Distro-Eintrag in der entsprechenden Datei unter /etc/apt/sources.list.d/ von bookworm zu trixie.

Ich halte mich beim Upgrade an die Anleitung von Proxmox: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9

Voraussetzungen prüfen

Es gibt das Script pve8to9. Damit lässt sich schnell prüfen, ob der Cluster generell bereit für ein Update ist.

1
2
3
4
5
6
7


= SUMMARY =

TOTAL: 52
PASSED: 40
SKIPPED: 11
WARNINGS: 1
FAILURES: 0

Bei mir kam eine Warnung, die sich darauf bezog, dass noch eine VM auf dem Host lief. Die habe ich auch einfach weiterlaufen lassen - das hat auch bei vorherigen Upgrades problemlos funktioniert. Generell ist es allerdings empfehlenswert, alle VMs und LXCs vollständig herunterzufahren.

Upgrade durchführen

Nach einem vollen Update von PVE 8 mittels

1
2
3
4


apt update
apt dist-upgrade
reboot # optional, wenn neuer Kernel verfügbar
apt autoremove # nicht mehr benötigte Pakete entfernen

habe ich dann das eigentliche Upgrade gestartet. Dazu werden die APT-Sourcen angepasst. Ich habe den Befehl aus der Anleitung von Proxmox bei mir leicht modifiziert, weil bei mir die Dateien anders heißen und ich parallel auch PBS aktualisieren muss:

1
2
3


sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve*.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pbs*.list

Theoretisch geht auch

1
2


sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list

Dabei sollte man allerdings aufpassen, ob alle Einträge korrekt sind.

Danach die Paketlisten aktualisieren:

1

apt update

Und das eigentliche Update starten, ich empfehle das in z.B. screen zu machen, falls die SSH-Verbindung abbricht:

1

apt dist-upgrade

Zwischendurch kommen einige Abfragen bezüglich erneuterter Konfigurationsdateien. Auch dazu findet man in der Anleitung von Proxmox einiges, hier einmal die Kurzfassung (bitte aber nachlesen, welche Effekte das hat):

/etc/issue: Neue Version übernehmen
/etc/lvm/lvm.conf: Neue Version übernehmen
/etc/ssh/sshd_config: Habe ich verneint bzw. die bestehende Version belassen

Sofern alles durch ist, muss nur noch neu gestartet werden:

1

reboot

Danach kann man noch nicht mehr benötigte Pakete entfernen:

1

apt autoremove

Damit sollte das Upgrade schon fertig und das Webinterface wieder verfügbar sein. Bei mir lief das Upgrade auf allen drei Hosts problemlos durch, nach einem Reboot war alles wie immer - nur eben mit der neuen Version.

Proxmox Backup Server muss ich noch testen, der Storage wurde allerdings in Proxmox VE schon als Verfügbar angezeigt - ich gehe also davon aus, dass auch da alles okay ist.

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

Backup-Server für das NAS

Sun, 27 Apr 2025 00:00:00 +0000

Irgendwie bin ich in letzter Zeit im Backup-Fieber… Ich weiß auch nicht.

Bisher wurden die Daten von meinem NAS (etwa 8TB belegt) nicht gesichert, ich habe nur die wichtigsten paar hundert GB ab und an in meine Storagebox bei Hetzner gesynct. Damit bin ich aber nicht so zufrieden, da der Datenverlust im Zweifelsfall doch deutlich wäre.

Festplatten

Irgendwo müssen solche Datenmengen hin, so viel hat man auch nicht einfach an Festplatten herumliegen. Cloud-Speicher ist in den Größenordnungen auch eher teuer, selbst wenn man Archivspeicher (z.B. S3 Glacier bei Scaleway) nutzt. Daher habe ich hierfür Festplatten gekauft. Weil es nur um Backups geht, waren refurbished Platten für mich okay, solange die in einem RAID oder ZFS laufen. Konkret wurde es eine Seagate Enterprise Capacity mit 12TB und eine Seagate Ironwolf mit 12TB. Ich habe verschiedene Modellreihen genommen, um einem gleichzeitigen Ausfall etwas vorzubeugen.

Benchmarks

Bevor ich die Festplatten tatsächlich nutze, habe ich kurz mit CrystalDiskBench mit meinem Windows-Rechner Tests gemacht.

Server

Ich habe aus vorhandener Hardware einen kleinen Server gebaut, der dann in den Keller kommt und bei Bedarf eingeschaltet werden kann. Die Hardware ist absolut nicht herausragend, reicht für den Zweck allerdings problemlos:

CPU: Intel Pentium G3258
RAM: 4GB (zweiter Slot vom Mainboard leider defekt)
Datenträger:
- 120GB SSD (TrueNAS)
- 2x 12TB HDD

Ich habe dann das aktuelle TrueNAS Scale installiert und ein RAIDZ1 erstellt. Ich habe mich hier explizit für RAIDZ1 statt einem Mirror entschieden, damit ich später simpel die Kapazität mit z.B. einer weiteren 12TB-Platte erweitern kann. Das RAIDZ1 verhält sich mit zwei Festplatten eigentlich wie ein Mirror. Schade ist hierbei, dass sich so ein zdev nicht über die UI erstellen lässt, das muss per CLI passieren.

Datensicherung

Anfangs hatte ich die Sicherungen mit rsync gemacht, das funktioniert auch soweit gut. Es hat jedoch einen gravierenden Nachteil: Das Verschieben von Dateien wird nicht erkannt. Deswegen habe ich nun auf rclone umgestellt, weiterhin per SFTP. Dort gibt es das Argument --track-renames, was bei Dateien, die entweder nur in der Quelle oder nur im Ziel sind, versucht, ein Matching zu möglichen anderen Dateien zu machen und entsprechend umzubenennen. Das scheint auch gut zu funktionieren.

Nach einem Sync lege ich händisch einen ZFS Snapshot an, um den alten Stand einzufrieren. Mein Plan ist, dass ich den kompletten Prozess automatisiere, also dann folgende Schritte in ein Script gieße:

NAS hochfahren
Backup-NAS hochfahren
Sync ausführen und abwarten
ZFS-SNapshot auf Backup-NAS erstellen
Backup-NAS herunterfahren
NAS in Standby schicken

Das soll dann etwa 1x pro Woche erfolgen. Ich habe mich bisher mit der TrueNAS-API noch nicht auseinandergesetzt, aber ansonsten kann ich die ZFS-Snapshots auch einfach direkt per CLI erstellen.

Proxmox Backup Server für den Hauptcluster

Sun, 30 Mar 2025 00:00:00 +0000

Ich habe schon länger darüber nachgedacht, wie ich gut und günstig meine VMs und Container sichern kann. Ich hatte in dem Zuge erst PBS über S3 getestet, was lief, aber nicht optimal war - und dann lange einen externen Anbieter (Tuxis) für PBS genutzt. Da bin ich mit 150GB allerdings beim Speicherplatz stark eingeschränkt.

Bisherige Backup-Strategie

Bisher landen die wichtigsten VMs und Container auf einem externen PBS-Server bei Tuxis, die Dateien der Nextcloud werden mittels restic auf eine Storage-Box bei Hetzner gesichert. Das deckt aber nur einen Teil der VMs und Container ab, und vor allem ist die Wiederherstellung teilweise aufwändiger. Daher habe ich schon länger den Wunsch, das ganze zu vereinfachen

Der Plan

Ich habe eine billige 1TB Sata-SSD gekauft (genauer gesagt eine Lexar NQ100 im Angebot). Diese soll in den dritten Host (der Mini-PC, Lenovo Tinkcentre M715q Tiny) kommen, damit dort dann Proxmox Backup Server laufen kann. Damit habe ich dann genügend Kapazität, um wirklich alle VMs und Container zu sichern und bei Bedarf schnell wiederherstellen zu können.

Die Umsetzung

Ich habe also die SSD verbaut (nebenbei auch noch die NVMe von 240GB auf 480GB getauscht und mittels gparted die bisherigen Partitionen kopiert und vergrößert).

Installation von PBS

Ich habe PBS direkt mit auf dem Host installiert. Da das ein Proxmox ist, war das auch nicht weiter schwierig (wäre es allerdings auf jedem Debian nicht). In der Doku befindet sich dazu auch eine Anleitung, die man recht gut befolgen kann (https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-proxmox-ve). Vor dem apt-Befehl muss man aber noch manuell das APT-Repo hinzufügen. Die ganze Installation sieht also etwa so aus:

1
2
3
4


wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list
apt update
apt install proxmox-backup-server

Die Befehle habe ich vor dem Posten nicht getestet, das habe ich jetzt im Nachhinein noch kurz zusammengesammelt.

Danach ist Proxmox Backup Server unter https://[host]:8007 erreichbar.

Lexar NQ100 für diesen Zweck

Die SSD scheint soweit gut geeignet als Backup-Ziel zu sein, auch wenn ich leichte Zweifel an der Langlebigkeit dieser SSD habe. Das liegt aber eigentlich nur am Preis, mir sind generell bisher eigentlich fast keine SSDs kaputt gegangen (eine noname 32GB SSD aus Chinau und eine 240GB Billig-SSD von Toshiba).

Spiegel vom PBS Datastore

Proxmox Backup Server kann Backups auf einen externen Server replizieren. Ich habe im Keller im zweiten Part vom Homelab einen Thin-Client (Fujitsu Futro S720) mit einer Sata-HDD, der als Backup-Server und Storage für die Server im Keller dient. Dorthin will ich einen (unregelmäßigen und manuellen) Sync einrichten, damit ich zumindest halb-offsite auch noch einen schnell verfügbaren Spiegel habe.

Proxmox Backup Server kostenlos (bei Tuxis)

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

Was ist Proxmox Backup Server überhaupt?

Der Proxmox Backup Server (PBS) ist eine Open-Source-Lösung zum Sichern von virtuellen Maschinen (VMs), Containern und physikalischen Hosts. Besonders in Kombination mit Proxmox VE ist PBS ideal, um effiziente und sichere Backups zu erstellen. PBS ist in Proxmox VE direkt integriert.

PBS unterstützt deduplizierte und inkrementelle Backups, was bedeutet, dass nur geänderte Daten gesichert werden, um Speicherplatz zu sparen. Backups können zudem komprimiert und verschlüsselt werden, was die Sicherheit und Effizienz erhöht.

Der kostenlose Anbieter

Durch Zufall bin ich bei Reddit in einem Kommentar darauf gestoßen, dass es einen Anbieter gibt, der Proxmox Backup Server mit 150 GB Speicherplatz komplett kostenfrei anbietet. Tuxis ist ein IT-Service-Provider mit Sitz in den Niederlanden.

Der Link zum Angebot: https://www.tuxis.nl/de/proxmox-backup-server/

Beim Schreiben dieses Posts muss ich leider feststellen, dass es die kostenlosen Pakete zumindest Stand heute nicht verfügbar sind. Vielleicht kommen die noch wieder, vielleicht aber auch nicht.

Meine Erfahrung

Ich habe den kostenlosen PBS also bestellt und innerhalb weniger Minuten die Zugangsdaten bekommen. Das ganze habe ich dann auch direkt in meinem Homeserver eingerichtet, hierbei mit Verschlüsselung, da die Daten nicht in meiner Hoheit liegen. Der Backup Space funktioniert, hat bisher keinerlei Fehler geworfen und scheint auch zuverlässig zu sein. Ich nutze das ganze allerdings auch erst seit ein paar Tagen, von daher kann ich zur langfristigen Stabilität noch nichts sagen. Bei kostenlosen Angeboten wie diesen muss man natürlich auch immer damit rechnen, dass das Angebot ohne große Ankündigung eingestellt wird, daher nutze ich es auch nur als zusätzliches Offsite-Backup. Ich gebe mir dabei auch Mühe, dass ich nicht zu viel Platz belege, immerhin ist es ein kostenloses Angebot, von dem ich hoffe, dass es so schnell nicht eingestellt wird.

Alternativen

Mir sind sonst auf dem Markt nicht wirklich viele Alternativen (also bezahlt) bekannt, die PBS anbieten. Es gibt sie aber. Ansonsten geht natürlich auch ein vServer mit genügend Storage - dafür findet man auch problemlos Anbieter (teilweise auch mit kleinem SSD-Boot-Speicher und dickem HDD-Speicher dazu). Und PBS statt reinem Storage (z.B. Hetzner Storage Box oder so) hat den großen Vorteil, dass die Deduplizierung bzw. inkrementelle Sicherung greift (und damit nicht nur Speicherplatz, sondern auch Bandbreite spart). Bei mir ist das aktuell (insgesamt knapp 300 Snapshots) ein Deduplizierungsfaktor von etwa 17.

Upgrades für den zweiten Fujitsu Futro S740

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

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

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

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

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

Die SSD

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

Das Upgrade

Zuerst habe ich den Futro also heruntergefahren und aufgeschraubt.

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

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

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

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

Der Start danach

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

Ausblick

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

Lokale SSL-Zertifikate mit Caddy und Step-CA

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

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

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

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

Step-CA

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

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

1
2
3
4
5
6
7
8


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

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

1
2
3


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

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

1
2


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

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

1
2
3
4


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

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

Caddy

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

1
2
3
4
5
6


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

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

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

1
2
3
4
5


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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

Das sieht in Fertig im Browser dann so aus:

Windows

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

Lenovo ThinkCentre M715q Tiny - Upgrades

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

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

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

Benchmarks

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

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

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

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

Was ich mit den Ressourcen mache

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

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

Lenovo ThinkCentre M715q Tiny - mein neuer MC-Server

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

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

Wofür?

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

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

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

Die Hardware

Der M715q hat bei mir nun folgende Ausstattung:

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

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

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

Die Software

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

Stromverbrauch

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

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

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

Benchmark

Zum Abschluss hier noch das Ergebnis von YABS:

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


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

Thu Nov 28 02:53:32 PM CET 2024

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

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

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

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

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

YABS completed in 13 min 3 sec

Minecraft - mein Setup

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

Fazit

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

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

Umstellen von meinem internen Netzwerk

Sun, 08 Dec 2024 00:00:00 +0000

Ich nutze in meinem Netzwerk BGP, um einerseits die Routen zwischen meinem Router im Keller (da steht der größere Teil vom Homelab) und meinem Hauptrouter auszutauschen und andererseits um Routen für interne Netze zwischen dem Router zuhause und vServern in verschiedenen Rechenzentren auszutauschen.

Bisher war dies so gelöst, dass es ein Zerotier-Netzwerk gab, wo die vServer sowie der Router zuhause enthalten waren. Zerotier ist sehr leicht einzurichten und von der Performance her auf den Servern auch okay, aber auf dem Router zuhause konnte ich damit maximal einen Durchsatz von ca 20 MBit/s erreichen. Ich weiß nicht genau, welche Technik Zerotier unter der Haube einsetzt, es scheint allerdings nicht so effizient wie andere Techniken zu sein.

Ich habe nun eine Ansible-Rolle entwickelt, die zwischen beliebigen Servern von mir Wireguard-Tunnel aufbaut und den Routing-Daemon bird komplett konfiguriert. Das funktioniert auch soweit sehr gut. Wireguard ist deutlich effizienter, wodurch ich auch direkt über den Router meine Internetleitung mit ~110 MBit/s voll auslasten kann. Das erleichtert größere Datentransfers über das interne Netz deutlich.

Über das interne Netz laufen Dinge wie Monitoring, teilweise auch Backups oder über Reverse Proxies durchgereichter Traffic. Das sind einerseits Dinge wie meine Nextcloud, andererseits aber z.B. auch mein Minecraft-Server. Dieser läuft neuerdings auf einem Mini-PC bei mir zuhause, dazu werde ich wahrscheinlich bei Gelegenheit noch mal einen Post schreiben.

Proxmox Backup Server mit S3 Storage

Tue, 22 Oct 2024 00:00:00 +0000

Update: Es gibt bei Proxmox mittlerweile die Option, S3 nativ zu nutzen. Dazu habe ich auch hier einen neuen Post geschrieben.

Was ist JuiceFS?

In einem anderen Post hatte ich bereits von JuiceFS berichtet. Das ist ein Dateisystem, was einen Object Storage mit einer Datenbank verbindet, um so möglichst Posix-Compliant zu sein. Das heißt also, dass die Dateiinhalte in einem S3-Bucket landen, die Metadaten und Verzeichnisstrukturen liegen dann in z.B. einer MariaDB.

Das hatte ich erst für Nextcloud getestet, was auch soweit funktioniert hat. Zu dem Zeitpunkt war mir das ganze aber nicht geheuer, weshalb ich es produktiv dafür nicht einsetzen wollte und auch weiterhin nicht vor habe.

Die Kombination

Im Proxmox-Forum und bei Reddit findet man Beiträge dazu, wie Leute Proxmox Backup Server (PBS) mittels rclone mit einem S3-Speicher verbunden haben, um die Backups eben in S3 zu lagern. Das hat allerdings nur so lange funktioniert, wie leere Verzeichnisse im Cache von rclone waren, da S3 prinzipbedingt nicht mit leeren Verzeichnissen umgehen kann. JuiceFS dürfte diese Lücke füllen, da durch die Trennung von Inhalts- und Metadaten die Unterstützung für alle relevanten Attribute und co wiederhergestellt wird.

Das Setup

Benötigt wird ein Debian-Server mit folgenden installierten Komponenten:

Proxmox Backup Server (entweder von der ISO installieren oder zusätzlich installieren, siehe hier: https://pbs.proxmox.com/docs/installation.html)
MariaDB-Datenbank (in meinem Test lokal installierter Server)
JuiceFS (Installation siehe hier: https://juicefs.com/docs/community/getting-started/installation/)
Ein S3-Bucket (in meinem Test MinIO, aber es geht natürlich auch alles andere)

JuiceFS-Storage anlegen

Ich habe also die Datenbank und ein S3-Bucket angelegt und dann mit folgendem Command den JuiceFS-Store angelegt:

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


# diese Variable nutze ich, um die Zugangsdaten und Pfade zur Datenbank nicht jedes Mal neu angeben zu müssen
# Diese Zeile muss pro SSH-Session, in der mit JuiceFS gearbeitet werden soll, neu ausgeführt werden.
export METAURL=mysql://[user]:[passwort]@([datenbankserver]:3306)/[datenbankname]
# bei mir:
# export METAURL=mysql://juicefs:pbspbspbs@(localhost:3306)/juicefs

juicefs format \
 --storage s3 \
 --bucket [bucket-url] \
 --access-key [access-key] \
 --secret-key [access-secret] \
 $METAURL \
 pbsfs --trash-days=0

# bei mir:
#juicefs format \
# --storage s3 \
# --bucket http://s3.homelab.local:9000/pbs \
# --access-key pbs \
# --secret-key pbspbspbs \
# $METAURL \
# pbsfs --trash-days=0

Output:

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


2024/10/20 10:14:59.175588 juicefs[15366] <INFO>: Meta address: mysql://juicefs:****@(localhost:3306)/juicefs [interface.go:504]
2024/10/20 10:14:59.177822 juicefs[15366] <INFO>: Data use s3://pbs/pbsfs/ [format.go:484]
2024/10/20 10:14:59.372276 juicefs[15366] <INFO>: Volume is formatted as {
 "Name": "pbsfs",
 "UUID": "97f66daa-c003-4b5b-b1ed-af4788cfbb06",
 "Storage": "s3",
 "Bucket": "http://s3.homelab.local:9000/pbs",
 "AccessKey": "pbs",
 "SecretKey": "removed",
 "BlockSize": 4096,
 "Compression": "none",
 "EncryptAlgo": "aes256gcm-rsa",
 "KeyEncrypted": true,
 "TrashDays": 0,
 "MetaVersion": 1,
 "MinClientVersion": "1.1.0-A",
 "DirStats": true,
 "EnableACL": false
} [format.go:521]

Damit wird nun also ein JuiceFS-Store angelegt. Die Daten für das S3-Bucket werden dabei mit im Metadaten-Speicher (also der MariaDB-Datenbank) abgelegt und müssen nicht noch mal eingegeben werden.

JuiceFS mounten

Mittels

1
2


mkdir /mnt/jfs
juicefs mount --update-fstab --background $METAURL /mnt/jfs

können wir nun das JuiceFS unter /mnt/jfs mounten, der Parameter --update-fstab sorgt dafür, dass direkt auch eine neue Zeile in der fstab angelgt und das JuiceFS beim Systemstart mit gemountet wird.

Mit

1

juicefs config $METAURL --capacity 100

lässt sich auch ein Quota festlegen, hier 100GB. Ansonsten hat ein JuiceFS theoretisch unbegrenzte Kapazität bzw. legt kein Limit fest.

Storage in PBS einrichten

In PBS können wir nun einen neuen Datastore hinzufügen und /mnt/jfs als Pfad angeben. Das Anlegen eines Storages wird allerdings eine ganze Zeit dauern, da hierbei einige Tausend Verzeichnisse erzeugt werden. In meinem Fall hat das etwa 20 Minuten gedauert, lokal ging das immer sehr viel schneller. Danach lässt sich der Storage normal in einem Proxmox VE Server einbinden und nutzen.

Performance

Meine Werte sind leider nur semi-aussagekräftig, da der Minio-Server, der hier als S3-Storage dient, wirklich langsam ist. Ich habe hierbei grob 5 MB/s bei Backups erreicht zeitweise auch 40 MB/s. Ich gehe davon aus, dass mit passend schnellem S3-Storage die reale Leistung eher bei den 40 MB/s liegt, sicher sagen kann ich das aber nicht.

Fazit

Da die Performance soweit okay ist, kann ich mir gut vorstellen, das auf einem vServer im Rechenzentrum mit einem Backblaze B2 Bucket als Storage tatsächlich zu verwenden bzw. dem ganzen so zumindest einem Langzeittest auszusetzen. Ich habe bislang mit JuiceFS auch außerhalb von solchen kurzen Tests wenig Erfahrung. Wenn es gut funktioniert, wäre es aber eine wirklich coole Möglichkeit, um günstig viel Speicher für Proxmox zu bekommen. Ich habe bisher allerdings auch keine Werte bzgl. Trafficnutzung und auch Anzahl der API-Calls, die beim S3-Storage entstehen, das kann schnell zu Kosten führen.

Update

Kleines Update: Ich habe das so temporär auf einem vServer mit Backblaze als Backend in Betrieb. Über etwa 1-2 Wochen hinweg habe ich nun getestet - das ganze lief stabil und mit brauchbarer Performance. Was dauert sind Operationen mit vielen kleinen Dateien, da merkt man dann die andere Speicherart. Generell kann man das nutzen, aber ich würde mich da nicht als einzige Backup-Lösung drauf verlassen - dafür fühlt sich das ganze zu sehr nach einer Bastellösung mit zu vielen beweglichen Teilen an.

Backups von Pterodactyl in S3 speichern

Sun, 20 Oct 2024 00:00:00 +0000

Pterodactyl bietet als Möglichkeit an, Backups zu erstellen. Das muss konfiguriert werden, wie das geht steht in der Doku unter https://pterodactyl.io/panel/1.0/additional_configuration.html. Standardmäßig kommt hierfür ein Verzeichnis auf den Nodes zum Einsatz, was meistens auch genügt. Es gibt allerdings auch die Option, die Backups in einem S3-Bucket zu speichern.

Ich habe mich dazu entschieden, die Option mit S3-Speicher zu nutzen. Einerseits liegen damit alle Backups am selben Ort und belegen lokal auf den Nodes keinen Speicher, andererseits ist Off-Site bei Backups immer besser. Als Storage-Anbieter für S3 habe ich mich hierbei für Backblaze entschieden. Es handelt sich nicht um hochkritische Daten und Nutzer bin nur ich selbst, daher halte ich es für vertretbar, diese Daten bei einem US-Unternehmen zu speichern. Es gibt mit OVH oder Scaleway (und bald Hetzner) aber auch europäische Anbieter, die S3-Speicher anbieten. Backblaze war einfach die günstigste Option und hat keine Mindestabnahme o.ä..

Ich habe also ein Bucket bei Backblaze angelegt, in den Lifecycle-äEinstellungen vom Bucket es so eingestellt, dass nur die letzte Version einer Datei erhalten bleibt und dann einen Application Key für dieses Bucket erzeugt.

In Pterodactyl werden die Einstellungen fürs Backup in der .env im Hauptverzeichnis vom Panel durchgeführt. Dort habe ich folgende Einstellungen vorgenommen:

1
2
3
4
5
6


AWS_USE_PATH_STYLE_ENDPOINT=true
AWS_DEFAULT_REGION=eu-central-003 # Die Region kannst du der Endpoint URL vom Bucket bei Backblaze entnehmen
AWS_ACCESS_KEY_ID=<keyID von Backblaze>
AWS_SECRET_ACCESS_KEY="<applicationKey von Backblaze>"
AWS_BACKUPS_BUCKET=<Bucket Name>
AWS_ENDPOINT="https://s3.eu-central-003.backblazeb2.com/" # Der Endpoint steht in der Bucketübersich beim Bucket dabei

Danach sollte es schon möglich sein, Backup zu erstellen, diese sollten auch dann im Bucket landen. Bei mir funktioniert das seit einigen Monaten so stabil.

Der zweite Fujitsu Futro S740

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

Warum ein zweiter Thin Client?

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

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

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

Der Kauf

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

Bilder

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

Setup

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

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

Fazit

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

YABS

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

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


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

Wed Oct 16 02:34:15 PM CEST 2024

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

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

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

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

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

YABS completed in 25 min 40 sec

Umzugsziel für meine Nextcloud

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

Warum das ganze?

Meine Nextcloud läuft bisher auf einem Storage-Server bei Contabo. Das ist ein älterer Server der vorherigen Generation bei Contabo und ich habe kürzlich eine E-Mail bzgl. einer Preiserhöhung deshalb bekommen. Und knapp 20€ für 1.4 TB (gut, inkl. 6 Cores und 20GB RAM) ist mir dann doch etwas viel (vor allem, weil der Server vorher ~12€ oder so gekostet hat).

Dementsprechend muss eine Alternative her.

Die Möglichkeiten

1. Anderen vServer mit genug lokalem Storage mieten

Es gibt bei verschiedenen Anbieter vServer mit genügend Speicher. Ich brauche 300-400GB, das gibt es ab 6-7€ pro Monat, je nach Anbieter.

2. Anderen vServer mit externem Storage mieten

Das größte Problem auf der Suche nach einem vServer ist der Storage. Also wäre es sicherlich eine Überlegung wert, ob man nicht einfach einen externen Storage anbinden kann.

Nextcloud selbst bietet mit der External Storage App eine Möglichkeit, diverse externe Speicher anzubinden. Das hat allerdings einige Nachteile. Beispielsweise werden Vorschaubilder, Versionen und auch der Papierkorb weiterhin im lokalen Storage abgelegt. Auch an anderen Stellen ist bemerkbar, dass es externer Speicher ist.

Diverse Anbieter bieten lokalen Blockstorage für vServer an, das ist allerdings eher weniger für sowas gedacht und als Massenspeicher schlicht zu teuer.

S3 lässt sich als primärer Storage nutzen, dann legt Nextcloud die Dateien als Blobs im Bucket ab. Das funktioniert soweit, hat aber den Nachteil, dass man im Storage keine Dateien oder Ordner mehr erkennen kann und somit im Worst-Case vollkommen von der Zuordnung innerhalb der Datenbank abhängig ist. Bei Nutzung von lokalem Speicher hat man auf der Platte immer einen normalen Ordner-/Dateibaum, den man auch so nutzen kann.

Bleibt noch die Option, S3 mittels s3fs oder Rclone lokal zu mounten. Das funktioniert, aber S3 hat Probleme mit leeren Ordnern. Das Prinzip von Ordnern existiert bei S3 nicht so wirklich, das sind dann mehr oder weniger nur Dateiprefixe. Das wirkt auf den ersten Blick nicht wie ein Problem, da Tools wie rclone solche leeren (und eigentlich nicht existierenden) Ordner einfach cachen. Je nachdem, was für einen Anbieter man für S3 nutzt, gibt es auch andere Optionen, um leere Ordner abzubilden, beispielsweise existiert die Möglichkeit, Markerdateien zu nutzen. Das klappt allerdings mit dem Anbieter, den ich nutzen wollte (Backblaze B2) nicht.

Es gibt JuiceFS. Das kanne ich vorher nicht und bin ich bei meiner Recherche mehr oder weniger zufällig drüber gestolpert. Das ist ein Dateisystem, was Metadaten (Dateinamen, Verzeichnisbaum, (erweiterte) Attribute) in einer relationalen Datenbank wie MariaDB oder PostgreSQL oder alternativ z.B. in Redis speichert, die eigentlichen Daten dann in S3 (oder anderen Object Storages) lagert. Das hat den großen Vorteil, dass es POSIX-Kompatibel ist und auch mit leeren Verzeichnissen problemlos umgehen kann. Mir ist jedoch diese Aufteilung in Dateninhalte und Attribute nicht geheuer, es fügt auch mehrere zusätzliche Fehlerpunkte hinzu. Auch war in meinen kurzen Tests die Performance nicht da, wo ich sie gerne hätte. An sich könnte JuiceFS für solche Anwendungen aber echt eine Möglichkeit sein.

3. Managed Nextcloud mieten

Mehrere Anbieter (mir bekannt sind Hetzner und IONOS) bieten Managed Nextclouds für wenig Geld an, in beiden Fällen fangen die Preise irgendwo bei 5€ pro Monat an. Das ist für mich allerdings keine Option, da ich die Nextcloud vollständig selbst unter Kontrolle haben möchte und beliebig Einstellungen setzen können möchte. Diese Möglichkeit ist allerdings sehr interessant, wenn man wenig Aufwand mit der Pflege haben möchte oder nicht so viel Erfahrung mit dem selbst hosten hat.

4. Zuhause hosten

Ich habe zuhause bekanntlich einen Futro S740 als Homeserver, das Gerät hat einerseits genug Rechenleistung und andererseits genug Möglichkeiten für SSDs und co. Ich überlege aktuell, die Nextcloud einfach zuhause zu hosten. Die meisten Zugriffe passieren eh innerhalb des Heimnetzwerks, von außerhalb sind es eher nur kleine Änderungen oder hier und da mal ein Bild vom Handy. Die Cloud wird hauptsächlich von meiner Partnerin und mir genutzt, lokal könnte man dann auch den Weg zur Cloud komplett im lokalen Netzwerk halten und nur den Zugriff von außen über Proxies im Rechenzentrum laufen lassen.

Da auf dem bisherigen Thin Client jedoch schon einiges läuft, würde ich hierfür einen zweiten anschaffen wollen. Aber schauen wir uns mal kurz die Kosten an.

Ein Futro S740 inkl. passend großer SSD würde mich grob 100€ kosten. Das ganze hängt natürlich stark von der aktuellen Preislage ab, aber die grobe Richtung müsste passen. Stromkosten liegen bei angenommenen 10 Watt (real sind es weniger) bei grob 1,50€ pro Monat. Das ist eher pessimistisch gerechnet, real ist es wahrscheinlich eher 1€ pro Monat. Wenn man die Anschaffungskosten für die Hardware auf einen Zeitraum von 2 Jahren verteilt, sind das knapp über 4€. Macht also insgesamt im Worst-Case etwa 5,50€ pro Monat für eine Laufzeit von zwei Jahren, wobei hier eigentlich deutlich mehr realistisch ist. Die monatlichen Kosten hängen dabei auch nicht davon ab, wie viel Storage das Teil bekommt, das beeinflusst nur die Anschaffungskosten.

Nachteile sind hauptsächlich, dass ein Futro nicht wirklich redundant ist, ich kann kaum die SSDs in einem RAID betreiben. Abstriche bei der Verfügbarkeit gibt es natürlich auch hinsichtlich Strom und Internet, wobei der Strom hier in den vergangenen Jahren noch nie ausgefallen ist. Aber vielleicht wird es wieder Zeit, eine USV einzusetzen - das ist aber ein anderes Thema.

Diese Nachteile sind für mich jedoch verkraftbar. Eigentlich ist es nur im Urlaub der Fall, dass die Cloud dann längerfristig ausfallen könnte, ohne dass ich was tun kann. Normalerweise lässt sich Ersatzhardware schnell beschaffen, mit entsprechenden Backups lässt sich eine “Notfall-Cloud” dann auch schnell auf die Beine stellen. Genügend Hardware habe ich für sowas im Homelab.

Entscheidung

Bisher bin ich mir noch nicht sicher, wohin die Reise geht. Aktuell tendiere ich sehr stark dazu, die Cloud einfach zuhause zu hosten, dafür würde ich dann auch noch einen zweiten S740 anschaffen - der bisherige ist einfach zu stark ausgelastet dafür. Ich werde die Cloud testhalber zu mir nach Hause auf den bisherigen Homeeserver holen und mir die Performance dann einfach mal ansehen. Das ist ja mehr oder weniger der Worst-Case dann.

Upgrades für den Futro S740

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

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

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

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

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

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

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

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

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

Hinweis: Nutzung auf eigene Gefahr.

Einleitung

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

Voraussetzungen

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

1

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

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

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

1
2


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

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

Erstellen vom Datenverzeichnis

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

1

mkdir -p /opt/teamspeak3/data/

anlegen.

Erzeugung der Docker-Compose-Datei

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

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

1

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

ansehen.

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

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


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

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

Erster Start

Wechsle zuerst in das Verzeichnis vom Server:

1

cd /opt/teamspeak3

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

1

docker compose up teamspeak

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

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

Finaler Start

Mit

1

docker compose up -d

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

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

Mein neuer Server (HP DL360p G8)

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

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

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

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

TS3-Server günstig zuhause hosten

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

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

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

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

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

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

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

Aber ergibt das ganze überhaupt Sinn?

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

Homelab im Keller

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

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

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

Internet/Netzwerkverbindung

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

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

Hardware

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

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

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

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

Weitere Pläne

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

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

Futro S720

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

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

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

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

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

Erfahrungen mit dem Rechenzentrum „SkyLink“

Fri, 04 Aug 2023 00:00:00 +0000

Ich habe Ende 2019 ein Rechenzentrum gesucht, wo ich einen kleinen 1HE-Server unterstellen kann. Der Server sollte erst für MC4U (was ja mittlerweile eingestellt ist) genutzt werden, später dann für eigene Zwecke. Anfang 2023 habe ich den Stellplatz für den Server gekündigt, da ich ihn nicht mehr nutze. Nach etwa drei Jahren möchte ich hier nun einmal meine Meinung bzw. Erfahrungen mit dem Rechenzentrum Skylink teilen.

Kleiner Hinweis: Wenn ich konkrete Preise nenne, beziehen diese sich auf das, was im Januar 2023 dort auf der Website stand. Es kann hierbei auch passieren, dass ich mich verlesen habe oder ähnliches, also bitte im Zweifelsfall selbst recherchieren.

Bei der Recherche auf der Suche nach Colocation für einen einzelnen Server bin ich auf das Rechenzentrum Skylink (https://skylink-data-center.de/) in Eygelshoven gestoßen (bzw. das Unternehmen XSServer (https://xsserver.gmbh/), wo man die “kleineren” Services bekommt). Mittlerweile dürfte das RZ einigen Lesern ein Begriff sein, da ein Teil der (Gaming-)Hosting-Szene in dieses Rechenzentrum gezogen ist. Zu dem Zeitpunkt war das aber noch nicht so der Fall. Alternativen in einem ähnlich günstigen Preisbereich (unter 30 €/Monat für alles) gab und gibt es kaum. Höchstens das Interwerk, also Active-Servers, aber die sind für einzelne Höheneinheiten teurer und zu dem Zeitpunkt war dort auch generell keine Colocation buchbar.

Das Rechenzentrum bietet eigentlich alles, was man so braucht. Anbindung erfolgt über Amsterdam und Frankfurt, grundlegender DDoS-Schutz ist inklusive. Erweiterter DDoS-Schutz ist über Combahton möglich, von diesem Angebot habe ich jedoch keinen Gebrauch gemacht und kenne auch die Kosten nicht. Traffic ist mit 3,57 €/TB günstig, aber es gibt eine Mindestabnahme von 1 TB monatlich. Ich würde mir wünschen, dass sich dies reduzieren lässt, da ich meistens einiges weniger benötigte. Einzelne IP-Adressen waren bei XSServer anfangs sehr günstig, mittlerweile sind dort auch die Preiserhöhungen vom gesamten Hosting-Markt angekommen - der Preis liegt jetzt bei 2,50 €/Monat pro IP pro Monat. Das ist im Vergleich zu anderen eher auf der teuren Seite. IPv6 ist leider nicht inklusive, selbst für einzelne Adressen muss man bezahlen. Knapp 6 €/Monat für ein /64-Netz finde ich auch deutlich zu teuer - viele andere Anbieter werfen einem die IPv6-Adressen fast hinterher, ein /64 ist häufig inklusive. Daher habe ich bei meinem Server auch kein IPv6. Remote-Hands habe ich über die gesamte Laufzeit nicht benötigt, wäre im Zweifelsfall aber auch sehr erschwinglich. Ein Uplink ist bei einzelnen Höheneinheiten auch inklusive, und das unabhängig von der Bandbreite (also auch 10G). Interessant ist nur der Traffic, der verbraucht wird. Der Strom ist mit um die 25 Cent/kWh ebenfalls günstig, vor allem wenn man bedenkt, dass dort Klimaanlage und USV/Generator bereits mit enthalten sind. Was Brandschutz und co angeht, findet man nur Informationen zu Rauchmeldern im Doppelboden auf der Website.

Nach der Bestellung des Stellplatzes habe ich meinen Server dann Anfang Januar 2020 verpackt und verschickt. Am nächsten Morgen ist der Server angekommen und war mittags bereits online. Super. Generell muss ich sagen, dass der Kundenservice gut ist, Kontakt geht immer flott und ist unkompliziert und angenehm. Das Interface bei XSServer ist soweit ordentlich, man findet alles, was man braucht. Der Stromverbrauch und auch Traffic sind immer einsehbar, auch ist beim Traffic eine Hochrechnung für den Traffic des aktuellen Monats sichtbar.

Natürlich macht man bei dem Preis auch Abstriche. Sofern man keine Anbindung über Combahton bucht, wird der Traffic über Skylink selbst geroutet. Die Routen waren insgesamt okay, Combahton im selben RZ ist jedoch mehrere Milisekunden schneller. Auch kam es ab und an mal zu Paketverlust (<1 %) zu einigen Internetprovidern, dies ist beim Routing über Combahton laut anderen Kunden anscheinend nicht der Fall.

Über die drei Jahre, die ich dort war, gab es eine Reihe von kleineren Ausfällen. Insbesondere am Anfang gab es fast regelmäßig Probleme mit der Anbindung nach Frankfurt und das Routing via Amsterdam war dann nicht sonderlich gut. Das hat sich gebessert, mittlerweile ist die Anbindung erheblich stabiler geworden. Von der Telekom aus lief das über Cogent in Amsterdam ins Rechenzentrum, leider nicht über Frankfurt. Anfangs war dies so, da wurde über Voxility in Frankfurt geroutet. Das Routing über Amsterdam hat zumindest bei mir die Latenzen etwas verschlechtert, aber alles im Rahmen. Es gab zwischenzeitlich auch mindestens einen Stromausfall, was auch zu ein wenig Downtime geführt hat. Zudem kam es bei mir mehrfach dazu, dass auf der monatlichen Rechnung plötzlich erheblich mehr Stromverbrauch stand als eigentlich möglich sein sollte, das ließ sich aber immer mit dem Support schnell lösen. Das Nachbestellen oder auch Kündigen von einzelnen IP-Adressen ging über den Support ebenfalls problemlos. Ich hatte mir auch für einige Tage ein /29er IP-Netz (inkl. Routing auf eine IP von mir) gemietet, auch das war auf Anfrage möglich.

Wo ich deutliches Verbesserungspotenzial sehe, sind Informationen bei Ausfällen. Bis vor kurzem gab es keine Status-/Störungsseite, wie bei vielen anderen Hostinganbietern üblich. Bei Störungen musste ich daher immer selbst nachfragen, was gerade los ist - auf Nachfrage kam dann jedoch immer eine passende Antwort.

Verbesserungsmöglichkeiten im Bereich “nice to have” sehe ich im Kundencenter und auch bei dem Produkt selbst. Bei der Colocation wäre es schön, wenn man zu günstigem Preis einen weiteren Ethernet-Port (100MBit/s genügen ja) für IPMI zubuchen könnte. Idealerweise wäre dort dann ein Zugang ohne öffentliche IP, sondern nur via VPN möglich. Ich kenne dies so von einem anderen Anbieter und finde es sehr angenehm. Die Qualität der Anbindung ist soweit okay - es wäre allerdings schön, wenn man unkompliziert für ein paar Euro (und wahrscheinlich Zuweisung neuer IP-Adressen) den Traffic über Combahton beziehen könnte. Auch wünsche ich mir kostenlose IPv6-Adressen, idealerweise ein /64-Netz pro Server.

Im Kundencenter wären mehr Statistiken zum Stromverbrauch (beispielsweise grafische Darstellung oder auch Durchschnittsverbrauch in Watt nach Stunde/Tag aufgeschlüsselt) schön. Auch irgendeine Form von DDoS-Historie ist hilfreich, wobei ich nur zu Zeiten, wo auf dem Server diverse Minecraft-Server liefen, einige Male angegriffen wurde.

Insgesamt bin ich aber überrascht, wie gut die Qualität für diesen wirklich geringen Preis ist. Dementsprechend ist das Rechenzentrum durchaus eine Empfehlung wert, wenn es nicht gerade um hochkritische Anwendungen geht. Aber dann ist man eh in einer anderen Preisklasse unterwegs.

NAS-Upgrade

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

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

Mein neuer Homeserver (Fujitsu Futro S740)

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

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

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

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

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

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

Netzwerk und Homelab – Stand Januar 2023

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

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

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

Das Netzwerk im Kern

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

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

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

Internetzugang

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

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

Smart-Home

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

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

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

Stromverbrauch

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

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

Zukunftspläne

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

Netzwerk

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

Heimserver

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

Hardware-Liste

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

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

Warum ein Synology-NAS für mich nicht geeignet ist

Fri, 02 Sep 2022 00:00:00 +0000

Ich überlege ja schon länger, mein Heimserver-Setup komplett neu aufzubauen. Neben Mini-PCs habe ich hierfür auch ausgiebig in Richtung NAS-Geräte recherchiert. Aufgrund der Software und dem generellen Ruf bin ich dann bei Synology gelandet, durch die 4 Bays konkret bei der Diskstation DS920+.

Hardwaremäßig kann die Konkurrenz mittlerweile 2,5G-Ethernet bieten, Synology hat weiterhin (bis auf bei den High-End-Geräten) überall nur 1G-Schnittstellen verbaut. Bei dem Preis von den Geräten erwarte ich da eigentlich mehr, vor allem da entsprechende Chips nicht viel kosten. Die CPU ist ein Celeron J4125 – für so ein Gerät angemessen.

Der Plan war, hier 2x SSD und 2x HDD zu verbauen. Die SSDs sollten den normalen Alltag machen, damit die HDDs meistens abgeschaltet sein können und weniger Strom verbrauchen. Es stellt sich jedoch heraus, dass die Systempartition und der Swap über alle Datenträger gespiegelt wird, die HDDs gehen also ungefähr nie in den Ruhezustand über. Damit wäre der Vorteil schon mal weg. Synology Hybrid Raid hingegen finde ich absolut super. Damit lassen sich Festplatten mit unterschiedlichen Größen in einem RAID kombinieren, was sonst eher nicht so üblich ist.

Homeassistant via VM schien zu laufen – eingerichtet habe ich es jedoch nicht komplett. Da es eine VM ist, mache ich mir da aber auch wenig Sorgen.

Docker lief auch soweit gut, meine Tests mit Paperless-ngx funktionierten ebenfalls problemlos.

Die Software lässt sich generell gut bedienen, da sehe ich wenig Probleme. Die Grundfunktionen für Freigaben via Samba und co funktionieren ebenfalls gut. Die mitgelieferte Software für PC-Backups ist allerdings… nicht ganz zu Ende gedacht. An sich funktioniert diese gut (wobei ich einen Restore nicht getestet habe), es lassen sich allerdings keine Ordner ausschließen. Das heißt, dass meine ganzen Spiele und andere Daten, die sich leicht wiederherstellen lassen, mit gesichert wurden. Meine Spiele neu herunterzuladen ist für mich kein Thema, wenn ich dabei beim Backup einige hundert GB an Speicherplatz sparen kann. Mit Acronis führe ich dies auch genau so durch und fahre gut damit – mit dem Synology-Tool lässt es sich aber so nicht umsetzen und ich verbrenne unnötig Speicher.

Der Stromverbrauch lag bei mir im Idle (2x HDD, 2x SSD) mit abgeschalteten Platten bei 15-20 Watt, unter etwas Last bei eher 30-40 Watt. Ein kleiner Mini-PC benötigt durchaus weniger und bei den aktuellen Strompreisen ist es mir eigentlich zu viel. Vor allem, wenn man hier wieder den Aspekt berücksichtigt, dass die Festplatten ungefähr nie in den Ruhezustand gehen und damit immer Strom verbrauchen.

Ich habe das Gerät am Ende wieder zurückgeschickt. Über 500€ sind mir zu viel dafür, dass das Gerät nicht die Eierlegende Wollmilchsau ist, die ich mir gewünscht habe. Im groben und ganzen ist es ein solides Gerät, aber leider erfüllt es an mehreren Stellen die Ansprüche, die ich habe, nicht. Vorerst werde ich ohne Homeserver leben und einen Raspberry Pi für Homeassistant nutzen, wahrscheinlich lande ich am Ende aber doch wieder bei irgend einem Mini-PC mit Proxmox.

Änderungen am Homelab Part 3 – Meine Lösung

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

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

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

Also.

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

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

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

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

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

Änderungen am Homelab Part 2 – Fail.

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

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

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

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

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

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

Änderungen am Homelab – Stromkosten.

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

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

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

Der aktuelle Stand

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

Bisher läuft als Hauptserver folgende Hardware:

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

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

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

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

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

Wie also weniger Strom verbrauchen?

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

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

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

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

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

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

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

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

[Debian/Ubuntu] TS3-Server inkl. Autostart installieren

Sat, 03 Nov 2018 00:00:00 +0000

Hinweis: Nutzung auf eigene Gefahr.

Einen TS3-Server zu installieren ist schnell erledigt. Führe dafür einfach folgende Befehle aus, du kannst den ganzen Block kopieren

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


VERSION=$(wget -O- 'https://www.teamspeak.com/versions/server.json' | jq -r ".linux.x86_64.version")
adduser --disabled-password --disabled-login --gecos "" teamspeak
cd /home/teamspeak/
wget https://files.teamspeak-services.com/releases/server/$VERSION/teamspeak3-server_linux_amd64-$VERSION.tar.bz2
tar xf teamspeak3-server_linux_amd64-$VERSION.tar.bz2
rm teamspeak3-server_linux_amd64-$VERSION.tar.bz2
touch /home/teamspeak/teamspeak3-server_linux_amd64/.ts3server_license_accepted
chown -R teamspeak: *
sudo -u teamspeak /home/teamspeak/teamspeak3-server_linux_amd64/ts3server_startscript.sh start
sudo -u teamspeak /home/teamspeak/teamspeak3-server_linux_amd64/ts3server_startscript.sh stop

An dieser Stelle werden nun die Zugangsdaten für den TS-Query sowie der erste Admin-Token angezeigt. Kopiere dir diese Daten und speichere sie irgendwo, du brauchst sie später noch.

Jetzt erstellen wir noch den Service, aktivieren ihn und starten ihn auch direkt (und damit den TS3-Server):

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


cat > /etc/systemd/system/teamspeak3.service &lt;&lt; EOF
[Unit]
Description=TeamSpeak3-Server
After=network.service

[Service]
User=teamspeak
Group=teamspeak
Type=forking
WorkingDirectory=/home/teamspeak/teamspeak3-server_linux_amd64/
ExecStart=/home/teamspeak/teamspeak3-server_linux_amd64/ts3server_startscript.sh start
ExecStop=/home/teamspeak/teamspeak3-server_linux_amd64/ts3server_startscript.sh stop
PIDFile=/home/teamspeak/teamspeak3-server_linux_amd64/ts3server.pid
RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable teamspeak3.service
systemctl start teamspeak3

An dieser Stelle ist ein Reboot zum Testen sicherlich nicht falsch, aber auch nicht zwingend notwendig. Ich habe dieses Skript selbst schon an diversen Stellen genutzt, bei mir läuft es sehr gut.

Updates lassen sich wie folgt durchführen, wenn das obige Skript zur Installation genutzt wurde (vorher natürlich eine Sicherung machen):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


VERSION=$(wget -O- 'https://www.teamspeak.com/versions/server.json' | jq -r ".linux.x86_64.version")
rsync -rt --delete /home/teamspeak/teamspeak3-server_linux_amd64/ /home/teamspeak/teamspeak3-server_linux_amd64.bak/
cd /home/teamspeak/
wget https://files.teamspeak-services.com/releases/server/$VERSION/teamspeak3-server_linux_amd64-$VERSION.tar.bz2
systemctl stop teamspeak3
tar xf teamspeak3-server_linux_amd64-$VERSION.tar.bz2
rm teamspeak3-server_linux_amd64-$VERSION.tar.bz2
touch /home/teamspeak/teamspeak3-server_linux_amd64/.ts3server_license_accepted
chown -R teamspeak: *
systemctl start teamspeak3

Wer eine ältere Version des Installers genutzt hat, muss vorher folgendes ausführen:

1

apt-get -y install jq rsync tar gzip

TeamSpeak-Server: Ideen und Vorschläge für den TS

Thu, 13 Oct 2016 00:00:00 +0000

Ich suche derzeit neue Ideen bzw. Vorschläge für den TS, um da mal wieder ein wenig frischen Wind und neue User reinzubringen… Ich verlasse mich auf eure Ideen dabei! Hoffentlich ist etwas (sinnvolles 😉) dabei, das sich auch umsetzen lässt 🙂