In den letzten Jahren habe ich immer mal wiedereinen Post über meine Top 10 der Apps in meinem Homelab geschrieben. Dieses Mal möchte ich einen etwas anderen Beitrag verfassen. Schlussendlich sind die Top 10 nämlich immer recht gleich. Vor allen Dingen auch wenn man sich die Beiträge von anderen Menschen mit Homelab anschaut. Entsprechend habe ich mir gedacht, dass ich dir einmal ein paar Tools vorstelle, die nicht jeder in seinem heimischen Netzwerk laufen hat. Gegebenenfalls ist das für dich eine Inspiration.

AutoKuma

Uptime Kuma kennen fast alle. Ich mag es nicht, alles immer per klicken konfigurieren zu müssen. Vor allen Dingen nicht, wenn sich die Arbeiten ziemlich einfach wiederholen. MitAutoKuma (externer Link) lässt sich Uptime Kuma einfach mit Docker Labels konfigurieren. Somit entfällt das zusätzliche Konfigurieren nach dem starten der App. Gerade wenn man, wie ich,GitOps betreibt wird das Verfügbarkeitsmonitoring direkt mit dem deployment der Anwendung eingerichtet. Natürlich funktionieren hier alle gängigen Uptime Kuma Überwachungen.

labels:-"kuma.strava.http.name='Strava Statistics'"-"kuma.strava.http.url=https://strava.casalani.de"-"kuma.strava.http.parent_name=apps"-"kuma.strava.http.max_retries=5"

Das ist einmal ein kleines Beispiel aus Strava Statistics. Schlussendlich lässt sich das recht einfach immer per copy & paste auf andere Systeme übertragen.

AutoKuma an sich ist natürlich auch nur ein Docker Container und lässt sich damit auf jeden Host einfach mitstarten.

services:autokuma:image:ghcr.io/bigboot/autokuma:2.0.0restart:unless-stoppedenvironment:AUTOKUMA__KUMA__URL:https://uptimekuma.example.comAUTOKUMA__KUMA__USERNAME:kumaadminAUTOKUMA__KUMA__PASSWORD:STRENGGEHEIMHESPASSWORDvolumes:-/var/run/docker.sock:/var/run/docker.sock-./autokuma:/datalabels:-"kuma.apps.group.name=Applications"

Mehr ist es nämlich auch schon nicht.

Patchmon

Patchmon (externer Link) habe ich vor einiger Zeit erst entdeckt. Die auch noch sehr junge Software kann dein Patchmanagement deiner Linux und Windows Systeme übernehmen. Zusätzlich lässt sich über einen kleinen Schwachstellenscanner direkt diverse Härtungsmaßnahmen anzeigen. Die Umsetzung liegt aber dann natürlich an dir selbst.

Der Docker Compose Stack ist bei Patchmon ein wenig größer, weil er aus App, Datenbank, Redis und Guacamole besteht. Die vom Hersteller angegebene Compose Datei funktioniert aber sehr gut, ich habe sie, inkl. der dazugehörigen .env-Datei, einfach übernommen und musste sie kaum anpassen.

AdGuardHome-Sync

Einige Zeit lang hatte ich mehrere physische Server im Einsatz und habe auf jedem eineAdGuard Home Instanz gehabt. Mittlerweile läuft zwar nur noch einProxmox Host , aber mehrere AdGuard Instanzen laufen trotzdem noch.

Auch hier möchte ich nicht immer manuell alle Anpassungen vornehmen und vor allen Dingen dann nicht zwei Mal. Mir ist irgendwann aufgefallen, dass ich eine neue Filterliste auf einer Instanz eingetragen hatte und erst Tage später beim Debuggen eines ganz anderen Problems gemerkt habe, dass die zweite Instanz davon nie etwas mitbekommen hat. Genau für dieses Vergessen gibt esAdGuardHome-Sync (externer Link) . Passe ich die Sperrlisten oder andere Einstellungen auf einem Host an, werden sie nach kurzer Zeit direkt auf den zweiten Host synchronisiert.

Konfiguriert wird das Ganze über eine einzige YAML-Datei mit Origin- und Replica-Definition:

cron:"*/10 * * * *"origin:url:https://adguard-1.example.comusername:adminpassword:STRENGGEHEIMESPASSWORDreplicas:-url:https://adguard-2.example.comusername:adminpassword:STRENGGEHEIMESPASSWORDautoSetup:true

Besonders praktisch ist derautoSetup-Parameter: kommt mal eine komplett frische AdGuard-Home-Instanz dazu, wird die Replica direkt beim ersten Sync automatisch eingerichtet, statt dass ich sie erst manuell durch den Setup-Wizard klicken muss.

OpenCloud

OpenCloud (externer Link) ist meine (theoretisch) schlankere Alternative zuNextcloud . Letzteres habe ich über viele Monate mit dem All-in-one Container Setup laufen gehabt. Stabil war es auf jeden Fall. Im Gegensatz zu vielen anderen Menschen konnte ich mich nicht darüber beschweren. Allerdings eine extra VM für ein paar Dateien die ich außerhalb des Netzwerkes im Zugriff haben möchte mit dem großen Nextcloud Stack zu verwalten war mir irgendwann zu viel.

Vor einiger Zeit ist OpenCloud immer häufiger in diversen Netzwerken erwähnt worden und ich habe mir gedacht, dass ich dem ganzen einmal eine Chance gebe. An Ressourcen benötigt die neue Umgebung deutlich weniger, dafür ist das Grundsetup aber auch deutlich komplizierter. Gerade wenn man, wie ich, viel über Single-Sign-On verwalten möchte. Das ganze Setup mit Authentik ist schon ein wenig komplexer, weshalb ich darüber gegebenenfalls noch einen extra Beitrag schreiben möchte.

Meerkat

Dem einen oder anderen ist sicherlich schon mal Monica als CRM über den Weg gelaufen. Leider scheint die Software nicht mehr weiter entwickelt zu werden und der Nachfolger Chandler scheint dem gleichen Schicksal ergangen zu sein. Im Gegensatz dazu wirktMeerkat (externer Link) angenehm schlank und aktiv gepflegt: die App kommt als ein einziger Container statt eines großen Stacks, was die Hürde deutlich senkt, das Ganze auch wirklich am Leben zu halten.

Meerkat ist ein System mit dem du deine Familie, Freunde, Bekannte, Arbeitskollegen und alle anderen als Kontakt verwalten kannst. Heißt hier nicht einfach Adressen oder Telefonnummern, sondern auch Beziehungen, Jahrestage aller Art und vor allen Dingen persönliche Informationen zu den jeweiligen Personen. Ich hab da zum Beispiel hinterlegt, dass mein Schwager keine Erdnüsse verträgt, weil ich mir sowas garantiert nicht bis zum nächsten Grillabend merken würde. Für Menschen wie mich, für die es schwer ist sich viele Informationen zu merken, ein großartiges System. Zumindest wenn man es pflegt…

Über den optionalen CardDAV-Server lassen sich die Kontakte sogar mit dem Smartphone synchronisieren. Damit wird Meerkat nicht nur ein digitaler Notizzettel, sondern kann auch dein eigentliches Adressbuch ersetzen.

SparkyFitness

Apps um sein Kalorienverbrauch, Aktivitäten und ähnliches zu tracken gibts wie Sand am Meer. Leider kosten die meisten mittlerweile eine ganz schöne Menge Geld. Wer ein sehr aktives Ziel verfolgt für den sind diese Apps ggf. genau das richtige. Für mich, der einfach nur ein wenig Überblick möchte ein Kostenpunkt der nicht unbedingt sein muss.

Glücklicherweise bin ich vor einiger Zeit daher aufSparkyFitness (externer Link) gestoßen. Der Entwickler beschreibt seine App als MyFitnessPal-Alternative fürs Selfhosting. Ich würde dem gut zustimmen. Die App kann wirklich eine Menge. Dafür sind aber leider das Onboarding bzw. die ersten Schritte recht schwierig. Man muss sich wirklich in Ruhe hinsetzen und die Lebensmittel, die man konsumiert, eintragen.

AdventureLog

MitAdventureLog (externer Link) kannst du deine Reisen entweder planen oder einfach nur tracken. Ich benutze es lediglich für letzteres. In AdventureLog habe ich alle Urlaube, die ich mit meiner Partnerin gemacht habe, eingetragen.

Sehr schön ist in AdventureLog die Darstellung der Reisen auf einer Karte. Ich habe diese ausgedruckt und im Wohnzimmer an einer Wand mit diversen Urlaubsfotos aufgehängt, damit Gäste rätseln können, welches Foto von uns zu welchem Punkt auf der Karte gehört.

Fazit

Sieben Tools, die hoffentlich nicht schon in jeder anderen Homelab-Top-10-Liste stehen – vom Monitoring über Patchmanagement bis zum digitalen Adressbuch. Bei manchen bin ich mir inzwischen sicher, dass sie bei mir bleiben (AutoKuma und AdGuardHome-Sync laufen seit Monaten unauffällig im Hintergrund), bei anderen wie OpenCloud oder SparkyFitness bin ich selbst noch am Ausprobieren.

Was fast alle gemeinsam haben: sie lösen ein einziges, konkretes Problem richtig gut, statt eine riesige All-in-One-Lösung sein zu wollen. Genau solche Tools gehen in den üblichen Top-10-Listen am ehesten unter – dabei sind es oft die, die man im Alltag am meisten zu schätzen lernt.

Läuft bei dir selbst etwas im Netzwerk, von dem kaum jemand redet? Schreib’s mir gerne, vielleicht wird daraus ja ein zweiter Teil dieser Liste.

Wer meinenletzten Beitrag zum Homelab Setup 2025 gelesen hat, weiß dass ich dortKomodo (externer Link) als GitOps-Werkzeug für meine Docker Compose Stacks einsetze. Das Prinzip dahinter ist gut: Git als Single Source of Truth, Renovate für automatische Version-Updates, und bei einem neuen Commit deployed Komodo die Änderungen auf das Zielsystem. Funktioniert im Grunde auch – aber Komodo hat mich mit einer Sache regelmäßig zur Weißglut gebracht: File Permissions. Das funktioniert einfach nicht konsistent. Entweder stimmen die Berechtigungen auf dem Host nicht, oder Komodo meckert beim Deployment, oder irgendwas dazwischen. Nach dem x-ten Mal hatte ich genug und wollte eine schlankere Lösung.

Die Anforderung ist dabei überschaubar: Wenn Renovate einen neuen Commit in das Repo pusht (nach meinem Merge des Pull Requests), soll die compose-Datei auf dem Server aktualisiert und die betroffenen Container neu gestartet werden. Kein Kubernetes, kein weiteres Framework. Einfach git pull und docker compose up.

Das Grundprinzip

Das Setup basiert auf drei Komponenten die zusammenspielen:

1. Gitea (externer Link) – mein selbst gehosteter Git-Server, auf dem die Compose-Dateien liegen
2. Renovate (externer Link) – überprüft alle vier Stunden per Cronjob die verwendeten Image-Tags gegen die jeweiligen Container-Registries und öffnet bei neuen Versionen automatisch Pull Requests. Ich merge den PR, der Commit landet aufmain.
3. webhook (externer Link) – ein einzelnes Go-Binary, das auf dem Zielserver einen HTTP-Endpunkt bereitstellt. Gitea feuert bei jedem Push einen Webhook dorthin, woraufhin das Deploy-Script ausgeführt wird.

Der Datenfluss sieht so aus:

Renovate erkennt neues Image-Tag
→ PR in Gitea
→ Merge
→ Gitea feuert Webhook
→ webhook-Binary ruft deploy.sh auf
→ git pull + docker compose up -d

Kein Polling, kein Daemon der irgendwelche Container-Registries beobachtet, kein Framework das eigene Meinungen zu File Permissions hat.

Warum nicht einfach Watchtower oder ein Cron-Script?

Bevor ich zu webhook gegriffen habe, hatte ich kurz zwei andere Ansätze im Kopf.

Watchtower (externer Link) überwacht laufende Container und zieht neue Images automatisch. Das Problem: Watchtower reagiert auf neue Images in der Registry, nicht auf Git-Commits. Wenn Renovate einen PR öffnet und ich den merge, hat Watchtower davon keine Ahnung – der zieht einfach irgendwann wenn er selbst nachschaut. Das passt nicht zu einem Setup bei dem Git die einzige Quelle der Wahrheit sein soll. Außerdem will ich den Merge-Zeitpunkt kontrollieren, nicht Watchtower.

Cron-Script mitgit fetch wäre die andere Möglichkeit – alle paar Minuten nachschauen ob es Änderungen gibt und dann deployen. Funktioniert, hat aber einen konzeptionellen Nachteil: Es ist Polling. Ich baue mit Gitea bereits eine Infrastruktur auf die Push-Events liefern kann, die sollte ich auch nutzen. Ein Webhook reagiert innerhalb von Sekunden, ein Cron-Job mit 5-Minuten-Intervall verzögert unnötig.

webhook ist der sauberste Weg: Event-getrieben, kein Extra-Daemon, ein einzelnes Binary ohne Abhängigkeiten.

Repo-Struktur

Ich habe pro Server ein eigenes Repository:

• apps-stack für dendocker01 – dort laufen Tools wiePaperless-ngx (externer Link) ,Immich (externer Link) ,Vaultwarden (externer Link) und ähnliches
• media-stack für denmedia01 – dort leben alle*arr-Container und was sonst noch zum Medien-Stack gehört

Jedes Repo enthält einfach diecompose.yaml sowie ggf. weitere Konfigurationsdateien die einzelne Anwendungen benötigen. Nichts Besonderes.

Renovate in den Repos

Renovate läuft selfhosted und überprüft per Cronjob alle vier Stunden die Image-Tags in den Compose-Dateien. Dafür reicht eine minimalerenovate.json im Repo-Root:

{"$schema":"https://docs.renovatebot.com/renovate-schema.json","extends": ["config:base"],"docker-compose": {"enabled":true }}

Renovate erkennt dann automatisch die Image-Tags in der Compose-Datei und öffnet PRs wenn eine neuere Version verfügbar ist. Bei Software die semantische Versionierung verwendet (alsomajor.minor.patch) lässt sich das besonders fein steuern – z. B. nur Patch-Updates automatisch mergen, bei Minor-Updates erst schauen was sich geändert hat.

Für Postgres-Container würde ich Renovate übrigens ausschließen. Major-Upgrades zwischen Postgres-Versionen erfordern einen manuellen Datenbankdump und -import, das soll mir kein Bot automatisch reinschießen.

webhook installieren und konfigurieren

webhook gibt es als einzelnes Binary, alternativ auch als Paket:

apt install webhook

Die Konfiguration liegt unter/etc/webhook/webhook.conf:

-id:deployexecute-command:/opt/scripts/deploy.shcommand-working-directory:/opt/media-stacktrigger-rule:match:type:payload-hmac-sha256secret:"{{getenv \"WEBHOOK_SECRET\"}}"parameter:source:headername:X-Gitea-Signature

Ein paar Anmerkungen dazu:

Header-Name: Gitea schickt die Signatur alsX-Gitea-Signature – ohne-256-Suffix und ohnesha256=-Präfix im Wert. Das klingt trivial, hat mich aber beim ersten Versuch einen Debugging-Durchgang gekostet.

Secret als Umgebungsvariable: Das HMAC-Secret gehört nicht im Klartext in die Konfigurationsdatei, erst recht nicht wenn die Datei im Repo versioniert ist. Deshalb wird es pergetenv aus der Umgebung gelesen.

Das Secret generieren:

openssl rand -hex32

Und in eine Secrets-Datei schreiben die nur root lesen kann:

# /etc/webhook/secrets.envWEBHOOK_SECRET=dein-generierter-string

chmod600 /etc/webhook/secrets.env

Systemd-Unit

# /etc/systemd/system/webhook.service[Unit]Description=Webhook ReceiverAfter=network.target[Service]User=teqqy # Hier den eigenen Usernamen eintragenEnvironmentFile=/etc/webhook/secrets.envExecStart=/usr/bin/webhook -hooks /etc/webhook/webhook.conf -port 9000Restart=on-failure[Install]WantedBy=multi-user.target

User=teqqy sorgt dafür dass der webhook-Daemon und damit auch das Deploy-Script nicht als root laufen. Das ist mir wichtig – Prozesse die nur git pull und docker compose up ausführen müssen haben nichts als root verloren. Den Usernamen natürlich durch den eigenen ersetzen; der User braucht Zugriff auf das Repo-Verzeichnis und muss Mitglied derdocker-Gruppe sein.

EnvironmentFile lädt diesecrets.env und stelltWEBHOOK_SECRET als Umgebungsvariable bereit, bevor der Prozess startet – so kommt das Secret sauber in dengetenv-Aufruf der Konfiguration.Restart=on-failure sorgt dafür dass der Daemon bei einem unerwarteten Absturz automatisch neu startet, ohne dass man manuell eingreifen muss.

systemctl enable --now webhook

Gitea Webhook einrichten

In Gitea unterRepository → Einstellungen → Webhooks → Webhook hinzufügen → Gitea:

• Ziel-URL:http://media01.example.com:9000/hooks/deploy
• Secret: denselben String den du oben generiert hast
• Trigger: NurPush-Events reichen aus

Gitea berechnet bei jedem Push automatisch eine HMAC-SHA256-Signatur über den Request-Body und schickt sie alsX-Gitea-Signature-Header mit. Das webhook-Binary verifiziert die Signatur bevor es das Script ausführt – ein simpler Authorization-Header wäre hier deutlich unsicherer, weil man den Payload damit nicht gegen Manipulation absichert.

Port 9000 sollte nicht direkt ins Internet exponiert sein. In meinem Setup sind Gitea und der webhook-Daemon im selben internen Netz, der Port ist von außen nicht erreichbar. Wer den Endpunkt für eine externe Gitea-Instanz oder GitHub erreichbar machen muss, sollte das zumindest hinter einem Reverse Proxy mit IP-Beschränkung tun.

Das Deploy-Script

#!/bin/bashset -euo pipefailREPO=/opt/media-stackLOG=/opt/deploy-logs/deploy-$(date +%Y%m%d-%H%M%S).logexec >>"$LOG" 2>&1echo"=== Deploy$(date) ==="cd"$REPO"git pull origin maindocker compose up -d --remove-orphansdocker compose psecho"=== Done ==="

set -euo pipefail sorgt dafür dass das Script bei jedem Fehler sofort abbricht und einen Exit-Code ≠ 0 zurückgibt. Den loggt webhook dann ebenfalls, sodassjournalctl -u webhook bei Problemen der erste Anlaufpunkt ist.

Das Log-Verzeichnis muss dem ausführenden User gehören:

mkdir -p /opt/deploy-logschown teqqy:teqqy /opt/deploy-logs

Stolpersteine die ich unterwegs getroffen habe

.git-Verzeichnis Ownership: Wenn das Repo irgendwann mal als anderer User geklont oder gepullt wurde, verweigert Git den Zugriff mit einer Warnung zu “dubiosen Besitzverhältnissen”. Fix:

chown -R teqqy:teqqy /opt/media-stack/.git

safe.directory: In manchen Setups hilft zusätzlich:

git config --global --add safe.directory /opt/media-stack

/var/log Permissions: Der ausführende User hat dort keine Schreibrechte. Deshalb das Log-Verzeichnis in einen Pfad legen der dem User gehört – ich nutze/opt/deploy-logs.

*arr-Container und UID/GID: Meine*arr-Container laufen mit99:100 (Unraid-kompatibel wegen NFS). Beim allerersten Deployment legt Docker die Bind-Mount-Verzeichnisse mit1000:1000 an wenn sie noch nicht existieren. Einmalig vor dem ersten Start:

chown -R 99:100 /mnt/data/arr/

Danach ist das kein Thema mehr da die Verzeichnisse bereits existieren.

Monitoring

Ich setzeUptime Kuma (externer Link) ein und beobachte dort ob die Container nach einem Deployment noch sauber laufen. Das reicht für meinen Use Case: Wenn ein Container nach einem fehlgeschlagenen Update nicht mehr antwortet, schlägt Uptime Kuma an. Das deploy.log undjournalctl -u webhook liefern dann die Details warum es schiefgelaufen ist.

Ein Dead-Man’s-Switch (z. B. über Healthchecks.io) wäre der nächste sinnvolle Schritt wenn man auch merken will wenn ein Deploy einfachausbleibt – aber für einen Media-Stack ist das für mich nicht kritisch genug um extra Aufwand zu treiben.

Fazit

Das Setup ist jetzt seit kurzem in Betrieb und macht genau was es soll – ohne dass ich irgendwas an Komodo debuggen muss. Das webhook-Binary ist stabil, der Deployment-Flow ist deterministisch, und der Gesamtoverhead beschränkt sich auf ein paar Konfigurationsdateien und ein Shell-Script.

Wer ähnliche Anforderungen hat und kein Kubernetes betreiben möchte: Das ist meiner Meinung nach der pragmatischste Weg. Keine Magie, keine Frameworks, kein Overengineering. Nur git pull und docker compose up.

Bei Fragen oder Anmerkungen erreichst du mich über die Links in der Menüleiste.

Diejenigen die ein Homelab auch zum experimentieren und lernen nutzen, kennen das Problem: Nichts ist richtig und irgendwie machen alle anderen alles immer besser, schöner, toller. Naja, zumindest mir gehts häufig so wenn ich Blogbeiträge oder Posts inr/homelab (externer Link) lese. Eine längere Zeit nutzte ich Kubernetes für mein Homelab und habe damit einige Dinge gelernt. Die Umgebung hat auch Spaß gemacht, wurde mir aber irgendwann zu anstrengend zu administrieren. Ich setze Kubernetes nicht in meinem normalen Berufsleben ein, sodass mir häufig die Übung fehlt. Und daheim: Nunja, ist ja eher ein Homeprod als ein Homelab. Was ich in der ganzen Zeit aber super fand ist das GitOps Prinzip. Es machte die Pflege von Versionen einfach ohne mal wieder in einen riesen breaking change gelaufen zu sein der “alles kaputt macht”.

Mein Homelab sah also nach dem Weggang von Kubernetes so aus, dass ich diverse VMs für Docker Container hatte und divere LXC für einzelne Anwendungen. Ich hatte die meisten Container mittels:latest Tag versehen um mich so nicht mehr um die Updates großartig kümmern zu müssen. Watchtower hat sich dann um die Updates entsprechend gekümmert. Bei größeren Tools, oder denen häufiger ein breaking change enthalten ist, wie z. B. bei Immich, habe ich die Version gepinnt. Bekomme so aber nicht mehr mit wann ein neues Update erschienen ist. Zumindest nicht, wenn die Software nicht in ihrer Weboberfläche einen erinnert.

Als ich dann vor einiger Zeit auf Komodo aufmerksam gemacht wurde, haben sich meine Gedanken über mehrere Tage hinweg damit beschäftigt wie ich die Software gut in mein Homelab einbauen kann. Komodo ermöglicht nämlich das GitOps Prinzip bei Docker bzw. Docker Compose Umgebungen.

Das Grundprinzip meines Homelabs

Nachdem ich mir ein paar Blog Beiträge (z. B.den (externer Link) hier) und YouTube Videos (z. B.das (externer Link) hier) zu Komodo angeguckt habe, war mir klar, dass ich meine Docker Installationen damit verwalten werde. Gerade der Blog Post von Nick hat mich auch dazu gebracht wie das ganze im “Backend” ggf. aussehen könnte.

Der Stromverbrauch meines Homelabs hatte sich die ganzen Monate immer so zwischen 120 W und 150 W bewegt. Nichts tragisches für mich, aber ggf wäre auch eine Reduzierung möglich. Zudem hatte ich die ganze Zeit sämtliche Dinge immer auf meinen Unraid Server gesichert. Das wollte ich auch ändern. Ziel war es also alles auf einen Proxmox Host, anstatt vorher drei Kubernetes Nodes, zu bringen. Dazu sollte der Proxmox Backup Server als dedizierte Maschine mit eigenem Stroage bereit stehen. Die NFS implementierung von Unraid ist einfach extrem nervig.

Des weiteren wollte ich nicht mehr duzende virtuelle Maschinen oder LXC auf dem System am laufen haben, es soll alles etwas verschlankt werden. Allerdings bin und war ich nie ein Fan davon alles in eine VM zu quetschen. Aber das muss jeder für sich selbst entscheiden.

Wie sieht mein Homelab jetzt aus?

Mittlerweile habe ich nur zwei Thin Clients am laufen: Einen als Proxmox Host und einen als Proxmox Backup Server. Natürlich mein Unraid NAS noch zusätzlich. Aber auf dem Proxmox Server läuft jetzt alles. Der ist zwar sehr gut ausgelastet, wird aber in der nächsten Zeit noch durch einen Minisforum MS-01 ersetzt. Das hat den Vorteil, dass ich den PVE dann auch via 10 GBit anschließen kann. Perspektivisch würde ich nämlich gerne das Netzwerk etwas aufrüsten.

Die Fragmentierung meiner virtuellen Systeme hat auch stark nachgelassen. Auch wenn es noch etwas mehr sind als geplant. Manche Systeme lassen sich einfach schwer containerisieren bzw. möchte ich auf Grund von Hardwareressourcennutzung separieren. Im Grundlegenden habe ich vier wichtige virtuelle Maschinen:

1. infra01 - Für Infrastruktur relevante Systeme
2. docker01 - Für meine ganzen “normalen” Anwendungen
3. media01 - Für alle Anwendungen rund um Bewegbild
4. ha01 - Home Assistant

Dazu gesellen sich noch zwei AdguardHome LXC, meine LXC für die Wetterstation und Wetter Webseite sowie Nextcloud (zieht aber auch bald um). Gehen wir mal auf die einzelnen Systeme ein.

infra01 - Das Backend meine Homelabs

Als so ziemlich wichtigste virtuelle Maschine der neuen Infastruktur ist diese VM quasi das Herzstück des ganzen. Hier werden alle relevanten Anwendungen gehostet. Diese Maschine ist aber leider auch gewisser single point of failure. Dadurch das ich kein Cluster mehr betreibe, würde sich der Punkt sonst einfach nur verschieben. Da wir später noch auf den genauen Workflow eingehen werden liste ich euch nur die dortigen Anwendunge einmal auf:

• Traefik: Mein GoTo Reverse Proxy den ich eigentlich überall einsetze (Webseite:https://traefik.io (externer Link) )
• Gitea: Interner GIT Server für sämtliche Konfigurationsdateien (Webseite:https://about.gitea.com/ (externer Link) )
• Komodo: Deployment der Container (Webseite:https://komo.do/ (externer Link) )
• Uptime-Kuma: Verfügbarkeitsmonitoring der Anwendungen (Webseite:https://uptimekuma.org/ (externer Link) )
• Authentik: Single Sign On für fast alle Anwendungen (Webseite:https://goauthentik.io/ (externer Link) )
• Beszel: Lastmonitoring der Systeme (Webseite:https://beszel.dev/ (externer Link) )

docker01 - Anwendungen des täglichen Bedarfs

Auf dieser VM lasse ich so ziemlich alle Anwendungen laufen die nicht auf die beiden anderen Systeme gehören. Gegebenenfalls wird hier zu einem späteren Zeitpunkt noch mal eine zweite VM hinzu kommen um die Apps ein wenig zu verteilen. Schlussendlich laufen hier die Apps die ich inmeiner Top 10 schon verbloggt habe . Zusätlich aber auch Dinge wie

• Treafik
• AdGuardHome Sync: Synct meine beiden AdGuardHome LXC (Webseite:https://github.com/bakito/adguardhome-sync (externer Link) )
• autokuma: Halbautomatisches hinzufügen der Anwendungen zu Uptime Kuma (Webseite:https://github.com/BigBoot/AutoKuma (externer Link) )
• beszel-agent: Monitoring Agent für Beszel

media01 - Für das Bewegbild

Alle Anwendungen rund um Filme und Serien, bis auf Jellyfin finden sich hier. Jellyfin hat seinen eigenen LXC bekommen um besser auf die iGPU des Hostsystems zugreifen zu können. Zwar sind 99 % aller Medienwiedergaben DirectPlay, aber man weiß ja nie.

Mein Workflow

Schlussendlich ist es bis hier hier nicht so wirklich spannend. Einfach nur wie ich die diversen Anwendungen auf diverse virtuelle System aufteile. Spannender wird es aber mit dem eigentlichen Workflow, denn der nutzt wieder das GitOps Prinzip. Da Komodo leider keine verschlüsselten Secrets kann, wollte ich meine compose Dateien nicht mehr auf GitHub hosten, sondern auf meinem eigenen GIT Server. Für diese Zwecke nutze ich schon immer gitea, auch wenn es da mittlerweile diverse Alternativen gibt.

Ich habe also zwei Repositories auf meinem Git Server erstellt, einen für den docker01 als “apps-stack” sowie für den media01 als “media-stack”. Das sind 08-15 compose Dateien ohne weiteren besonderen Konfigurationen. Sobald ich Änderungen pushe wird ein Webhook zu Komodo gesendet. Dieser triggert dort einen Workflow um das Repo zu aktuallisieren und die Änderungen entsprechend auf dem Zielsystem zu deployen. Ich kann über diesen Weg auch dedizierte Konfigurationsdateien mitgeben die einzelne Anwendungen benötigen. So habe ich alles immer zusammen in einem Repo. Dieses Vorgehen gilt, wie geschrieben, für die den docker01 sowie für den media01. Die Anwendungen auf dem infra01 werden so nicht deployed. Gitea installieren zu können ohne ihn zu haben funktioniert nunmal nicht. Sobald Komodo verschlüsselte Secrets beherrscht würde ich die Dateien sicherlich wieder auf GitHub auslagern um direkt mit dem Deployment starten zu können.

Update Management der Container

In meinen Compose Dateien versuche ich Container zu verwenden deren Entwickler semver verwendet. Damit habe ich es einfacher die Container leichter zu updaten. Okay, eigentlich habe ICH es nicht einfacher, sondern Renovate. Renovate habe ich auch bereits in meinem Kubernetes Cluster verwendet, damals als SaaS jetzt auch selfhosted. Renovate läuft alle vier Stunden per cronjob und überprüft ob es in den angebenen Container Registry eine neuere Version gibt. Sobald das der Fall ist, erstellt mir der Service einen Pull Request in dem jeweilgen Repository. Diesen kann ich dann entsprechend aktzeptieren und der o. a. Workflow wird getriggert.

Sollte eine Anwendung extrem häufig eine neue Version veröffentlichen, kann ich natürlich auch ein automatisches commit erstellen, dann muss ich nicht mehr händisch eingreifen. Auf der anderen Seite kann z. B. Postgres bei Upgrades auf neue Versionen unschön werden. Derzeit wird es noch nicht unterstützt, dass die Datenbank einfach auf die neue Version gehoben wird, wie das bei MySQL oder MariaDB der Fall ist. Entsprechend schließe ich die Postgres Container von Renovate aus und belasse sie derzeit auf Version 17.

Backup und Restore

Im vorherigen Proxmox Cluster habe ich Unraid als NFS Storage eingebunden und darauf meine Backups gespeichert. Auch mit dem Proxmox Backup Server als virtuelle Maschine hatte ich eine Zeit lang dieses Vorgehen. Wie du Unraid NFS Shares als Ziel im Proxmox Backup Server einbindest, kannst du indiesem Beitrag lesen.

Weiter oben habe ich bereits erwähnt, dass ich nun einen dedizierten PBS einsetze. Dieser ist mit einer 1 TB großen SSD ausgestattet auf dem ich meine Backups speichere. Zuküftig möchte ich noch ein Backupsatz außer Haus speichern, weil ich sonst das 3-2-1-Prinzip nicht einhalten kann und mir das schon wichtig ist.

Fazit

Das Setup läuft jetzt noch nicht so lange, fühlt sich für mich aber stabiler und kompletter an. Zudem habe ich die Updates der Anwendungen wieder besser im Griff. Allerdings muss ich mich noch um die Updates für die Betriebssysteme kümmern. Dazu werde ich mir sicherlich ein Ansible Playbook schreiben dass das für mich vereinfachen wird. Solltest du Fragen oder Anregungen zu irgendwelchen Punkten haben, kontaktiere mich einfach über die Wege oben in der Menüleiste.

Wie in den Jahren2021 und2024 möchte ich auch dieses Jahr wieder eine Liste mit meinen Lieblingssoftwareprodukten verbloggen. Ich finde solche Beiträge immer sehr interessant, weil man dort oft kleine Schätze entdeckt. Zumeist – so ehrlich muss man wohl sein – finden sich aber häufig die altbekannten Produkte in solchen Listen. Nichtsdestotrotz werden dieses Jahr sicherlich drei selfhosted Produkte dabei sein, die nicht jeder von euch kennen wird.

Platz 10: Wanderer

Beginnen möchte ich die Liste mit der AppWanderer (externer Link) . Hier kannst du deine Wanderrouten sammeln – quasi einKomoot fürs Selfhosting. Leider kann die App selbst keine Routen aufzeichnen, aber mittels GPX, Strava oder Komoot lassen sich deine Touren importieren und dort verwalten. Außerdem kannst du sie mit weiteren Informationen anreichern.

Seit einem der letzten Updates kannst du deine neuen Aktivitäten im Fediverse mit anderen teilen. So lassen sich schnell neue Routen von Menschen auf der ganzen Welt entdecken.

Ich mag die Software, weil ich nach der Übernahme und der Preiserhöhung bei Komoot keine Lust mehr auf die App hatte und nach Alternativen gesucht habe. Wenn ich wandern gehe, logge ich die Route mit Strava und importiere sie anschließend in Wanderer.

Platz 9: Nextcloud

Nextcloud (externer Link) ist eigentlich eine Software, zu der man kaum noch etwas sagen muss. Es ist bei mir eine Art Hassliebe: Zum einen ist Nextcloud für ein bisschen Dateiablage völlig überdimensioniert, auf der anderen Seite lassen sich hier schnell und einfach viele kleine Apps einbinden. Es gibt zahlreiche Alternativen, aber am Ende bin ich doch immer wieder bei Nextcloud gelandet.

In meinemHomelab (externer Link) läuft mittlerweile die All-in-one-Installation. Diese ist bei mir stabiler als eine normale Docker-Compose-Variante oder gar eine manuelle Installation. Zugegeben: Ich nutze Nextcloud aktuell nur für Kalender und Dateiablage – andere Apps habe ich derzeit nicht dauerhaft im Einsatz.

Platz 8: Jellyfin

Jellyfin (externer Link) , der allseits bekannte Mediaplayer. Was für mich der Unterschied zum Platzhirsch Plex ist, habe ich schon in einem älterenBlogartikel beschrieben. Ich bin mit Jellyfin sehr zufrieden – es macht, was es soll. Und dank fehlender Cloud-Anbindung muss man sich keine Gedanken über Hacks oder Datenlecks machen.

Jellyfin läuft bei mir als LXC auf meinem Proxmox-Host. Dadurch kann ich einfach auf die iGPU meines Thin Clients zugreifen und spare mir eine dedizierte Grafikkarte für mögliches Transcoding. Allerdings versuche ich ohnehin, meine Medien so vorzuhalten, dass kein Transkodieren notwendig ist.

Platz 7: FreshRSS

ZuFreshRSS (externer Link) habe ich schon ein paar Mal etwas veröffentlicht. Für mich ist es weiterhindie Software, wenn es um selbst gehostete RSS-Reader geht. FreshRSS aggregiert meine Feeds (die derzeit etwas leer sind), ich lese sie aber nicht direkt dort. Auf meinen Apple-Geräten greife ich mit der AppReeder auf meine Instanz zu – diese Verbindung funktioniert seit jeher absolut zuverlässig.

Platz 6: Mealie

Wer gerne kocht, kennt das Problem: Rezepte sind überall verteilt, und viele Rezeptseiten sind inzwischen reine Tracking- und Werbeschleudern. Deshalb setze ich aufMealie (externer Link) und trage dort alle Rezepte ein, die sich lohnen.

Mealie erkennt sehr zuverlässig die relevanten Informationen auf Rezeptseiten und stellt sie super dar. Teilschritte und Zutaten passe ich häufig manuell an. Inzwischen werden es immer mehr Rezepte – also habe ich angefangen, alles ordentlich zu sortieren, sonst findet man irgendwann nichts mehr.

Mealie läuft bei mir klassisch als Docker-Container, ohne zusätzliche Datenbank, einfach mit SQLite. Ich habe in den letzten Jahren festgestellt, dass kleine Softwareprodukte oft keine vollwertige Datenbank brauchen. Wichtig ist nur: SQLite-Datenbanken niemals auf ein NFS-Share legen!

Platz 5: Immich

Immich (externer Link) ist wohl einer der aufstrebenden Sterne am Selfhosted-Himmel. Die Fotoverwaltung läuft einfach extrem gut. Natürlich gibt’s hier und da kleine Problemchen, aber das Entwicklerteam reagiert schnell. Ich habe mich für Immich entschieden, weil viele andere Tools mittlerweile Integrationen dafür anbieten – so lassen sich Fotos oder Alben direkt in anderen Apps anzeigen.

Eines meiner Highlights ist dieErinnerungen-Funktion. Ähnlich wie bei Facebook (wer noch dort ist, weiß, was ich meine) zeigt Immich Fotos vom selben Datum an. So kann man schön in Erinnerungen schwelgen – zum Beispiel beim 1000. Katzenfoto vor zwei Jahren.

Die Software ist mir recht wichtig, deshalb läuft sie in einer eigenen VM – allerdings trotzdem als Docker-Container. So habe ich alle Fotos und Daten zentral in einer VM, und Backup sowie Restore sind über Snapshots und Backups deutlich einfacher.

Platz 4: Adventure Log

Adventure Log (externer Link) war ein Zufallsfund im Subreddit r/selfhosted. Der Entwickler hat die Software dort kurz vorgestellt, und seitdem bin ich Fan.

Mit Adventure Log kannst du deine Abenteuer (Reisen, Urlaube etc.) planen und tracken. Ein Import aus Wanderer ist inzwischen möglich, andere Quellen leider noch nicht. Für alle, die gerne reisen, aber ein super Tool.

Hier spielt auch wieder die Immich-Integration eine Rolle: Man kann auf Alben aus Immich verweisen und sie direkt in den jeweiligen Reisen anzeigen.

Adventure Log ist aktuell die einzige Software, die bei mir über die Proxmox Helper Scripts läuft. Aufgrund des etwas komplexeren Aufbaus wollte ich sie nicht normal installieren – eventuell wechsle ich aber auf die Docker-Version.

Platz 3: Statistics for Strava

Seit einigen Monaten gehe ich wieder regelmäßig laufen.Strava begleitet mich dabei schon seit Jahren.Statistics for Strava (externer Link) erweitert die Funktionen des Standardaccounts um zusätzliche Auswertungen. Wichtig: Der Entwickler darf laut API-Richtlinien keine Features anbieten, die mit Strava Premium konkurrieren.

Trotzdem bekomme ich hier viele spannende Informationen – etwa zu Bestzeiten, Herzfrequenzen und anderen Statistiken. Anfangs lag der Fokus nur auf Radfahren, mittlerweile werden aber viele Ausdauersportarten unterstützt.

Statistics for Strava läuft ebenfalls als Docker-Container. Etwas schade: Für den Import der Daten und die Generierung der HTML-Dateien ist ein separater Cronjob nötig.

Wenn du möchtest, kannst du mir gern aufStrava (externer Link) folgen.

Platz 2: Mastodon

Mastodon (externer Link) begleitet mich seit der Übernahme von Twitter durch Musk. Inzwischen haben sich viele weitere Softwareprodukte rund um ActivityPub und das Fediverse entwickelt, die wunderbar mit Mastodon interagieren können. Manchmal gibt’s noch kleine technische Stolpersteine – wie ich in einem meiner letztenBeiträge beschrieben habe.

Trotzdem ist Mastodon mein soziales Netzwerk der Wahl. Ich bin zwar auch auf Bluesky, aber dort kaum aktiv. Der Nachteil (oder vielleicht Vorteil) von Mastodon: Es gibt keine Algorithmen. Man bekommt also keine Account-Vorschläge und findet interessante Menschen etwas schwerer.

Bei mir läuft Mastodon als Docker-Container auf meinem VPS, auf dem auch dieser Blog gehostet ist. Die Container-Installation macht Updates deutlich einfacher.

Platz 1: Proxmox

Die wohl wichtigste Software in meinem Homelab ist definitivProxmox (externer Link) . Die Virtualisierungsplattform hält all meine virtuellen Maschinen zusammen und funktioniert seit Jahren ohne nennenswerte Probleme. Mit der integrierten Backup-Software lassen sich granular Dateien wiederherstellen – oder im Zweifel einfach mal eine kaputte Konfiguration aus dem Backup ziehen.

Damit wäre meine diesjährige Top 10 also komplett. Wie immer war es gar nicht so einfach, die Plätze zu vergeben, denn eigentlich laufen bei mir noch etliche weitere kleine Tools und Dienste, die ebenfalls einen Platz verdient hätten. Aber irgendwo muss man ja eine Grenze ziehen. 😊

Spannend finde ich jedenfalls, wie sich mein Homelab über die Jahre verändert hat – und das bringt mich direkt zum Fazit.

Fazit – was sich seit 2024 verändert hat

Wenn ich den Beitrag vom letzten Jahr mit diesem hier vergleiche, zeigt sich ganz gut, wie sich mein Homelab und auch meine Prioritäten verändert haben. 2024 standen noch viele „klassische“ Infrastruktur-Services ganz oben: Home Assistant, Paperless, Minio oder EVCC – also Tools, die man fast schon als Rückgrat eines smarten Zuhauses oder Labors bezeichnen könnte. Dieses Jahr hat sich der Fokus etwas verschoben: weg von reiner Hausautomatisierung und mehr hin zu Dingen, die mir persönlich Freude bereiten.

Das zeigt sich besonders daran, dass mit Wanderer, Adventure Log oder Statistics for Strava gleich mehrere Selfhosted-Projekte vertreten sind, die sich um Hobbys und Aktivitäten drehen. Ich merke, dass mein Homelab inzwischen nicht mehr nur „funktionieren“ soll, sondern mich auch im Alltag begleiten darf – beim Wandern, Kochen oder Sport.

Ein paar Klassiker sind geblieben: Nextcloud, Immich und Mastodon haben sich bewährt und laufen zuverlässig weiter. Andere wie Home Assistant oder Paperless-NGX fehlen diesmal, was aber eher daran liegt, dass sie bei mir inzwischen so selbstverständlich geworden sind, dass ich kaum noch darüber nachdenke. Man könnte sagen: Sie sind vom Highlight zum Fundament geworden.

Spannend finde ich auch, dass viele meiner diesjährigen Favoriten deutlich sozialer geworden sind – sei es durch das Fediverse, gemeinsame Fotoalben oder das Teilen von Aktivitäten. Das Homelab ist also nicht mehr nur mein technisches Spielzeug, sondern verbindet mich auf gewisse Weise mit anderen Menschen, die ähnliche Interessen haben.

Mal schauen, was 2026 bringt – vielleicht geht’s dann wieder etwas technischer zu, vielleicht auch nicht. Aber eines steht fest: Langweilig wird’s im Homelab garantiert nie.

Ich bin seit der Übernahme von Twitter durch Elon Musk auch aufMastodon (externer Link) bzw. im ActivityPub-Universum unterwegs. Das Konzept, dass es viele verteilte Server im sozialen Netzwerk gibt finde ich total spannend. Das ist, wenn man so will, das soziale Netzwerk neu gedacht – dezentral, offen und communitygetrieben. Vor allem haben wir damit nicht die allgemeinen Probleme welche die derzeit großen Netzwerke so mit sich bringen. Egal in welche politische Richtung man jetzt denken möge.

Mein Werdegang im Fediverse

Seit dem ersten Tag war für mich klar: Wenn ich irgendwo im Internet aktiv bin, dann selfhosted. Ich wollte also meine eigene Instanz betreiben – nicht einfach einen Account aufmastodon.social (externer Link) oderchaos.social (externer Link) haben, sondern wirklich alles selbst in der Hand. Angefangen habe ich mit einem Mastodon Server der auf einem Netcup VPS installiert wurde, in der klassischen Installation, also ohne Container. Einige Zeit später habe ich meine Installation dann zu den Docker Containern umgezogen. Beide Installationsvarianten liefen ohne Probleme. Lediglich das Updaten ist mittels Container einfacherer.

Umzug ins Homelab

Ein paar Monate später lief mein Kubernetes-Homelab (externer Link) endlich stabil – und was liegt näher, als den Mastodon-Server auch dorthin umzuziehen? Mit Cloudflare Tunnel war das Routing kein Problem. Auch diese Installation lief reibungslos. Ich habe irgendwann von den offiziellen Mastodon-Containern auf die Images von Linuxserver.io gewechselt. Funktional gab’s aber keinen Unterschied.

Der Umstieg auf GoToSocial

Vor einigen Wochen schriebMatthias (externer Link) dann über sein Experiment mitGoToSocial (externer Link) – kurz GTS. Diese Software ist im Prinzip eine leichtgewichtige Alternative zu Mastodon, geschrieben in Go, und läuft als Single Binary. Kein Ruby, keine externe Datenbank nötig, kein Overhead. Also perfekt für kleine Instanzen mit nur wenigen aktiven Konten. GTS bringt leider kein eigenes Frontend mit, sodass man hier auf externe oder auf die gängigen Smartphone Apps ausweichen muss.

Matthias hat hier ein paar Beobachtungenauf seinem Blog (externer Link) dazu geschrieben was die Unterschiede der Performance sowie des Resourcenverbrauches angeht. Sehr spannend zu lesen.

Also habe ich mir ebenfalls eine kleine GoToSocial-Instanz eingerichtet. Die Einrichtung war wirklich simpel: Binary herunterladen, Konfigurationsdatei anlegen, starten – fertig. Und ja, es lief erstaunlich stabil. Nur merkt man schnell, dass GTS zwar das ActivityPub-Protokoll unterstützt, aber bei der Interoperabilität noch nicht auf dem gleichen Level wie Mastodon ist.

Problem Nummer 1 - Wanderer und das schweigen im Feed

Das Thema ActivityPub, also quasi das Protokoll das hinter vielen verschiedenen Föderierenden in sozialen Netzwerken steckt, findet in den letzten Monaten bei diversen Apps der selfhosting-Szene auch immer mehr anklang. Ich war also erfreut, dass die AppWanderer (externer Link) ebendies nun anbietet. Die Idee dahinter ist großartig: Man kann eigene Wanderrouten teilen, GPS-Tracks hochladen und diese als Beiträge ins Fediverse posten. Und das Ganze natürlich föderiert über ActivityPub.

Nach kurzer Zeit musste ich dies einmal ausprobieren wie das so funktioniert. Das folgen meines Accountes aus der GoToSocial Instanz war kein Problem. Also eine neue Wanderroute per GPX importiert und gewartet was ich nun als Beitrag in meinem Feed sehen werde… Nix… Nach ein wenig hin und her habe ich es von einem normalen Mastodon Account probiert und siehe da: Die Wanderung wird mir als Beitrag in die Timeline gespült.

Ich habe den Fehler natürlich dem Entwickler gemeldet, aber bisher (Stand heute) hat sich da noch nichts getan. Das zeigt recht deutlich: ActivityPub ist mächtig, aber eben auch komplex. Nicht jede Implementierung spricht dieselbe „Sprache“, und schon kleine Abweichungen führen zu Inkompatibilitäten.

Problem Nummer 2 - PeerTube und seine Follower

Das zweite Thema, das mich beschäftigt hat, war mein alter YouTube-Kanal. Ich hatte Lust, mal wieder ein paar Videos zu machen – aber eben nicht nur auf YouTube. Wenn man schon im Fediverse ist, bietet sichPeerTube (externer Link) an: eine dezentrale Videoplattform, die nach dem gleichen Prinzip funktioniert wie Mastodon, nur eben für Videos.

Die Installation war schnell erledigt, aber die Einrichtung hat es in sich. PeerTube hat ein komplexes Rollen- und Berechtigungssystem, dazu die Föderationseinstellungen und eine ganze Menge an Tuning-Parametern. Aber: Es läuft stabil, und die Community ist sehr aktiv.

Auch hier habe ich ein paar Testvideos hoch geladen und geschaut was so passiert. Leider steckt das Thema Interoperabilität zwischen PeerTube und GoToSocial sogar noch weiter vorne fest. Ich kann Accounts oder Kanälen folgen, die Anfrage wird aber nicht sauber von PeerTube verarbeitet. Das Problem war sogar bekannt: Auf GitHub gab es bereits ein Issue, und angeblich sollte der Bug mit Version 7.2 behoben sein. Ich hatte allerdings schon Version 7.3 – und trotzdem trat der Fehler auf. Auch hier wieder das gleiche Muster: Mit einem Mastodon-Account lief alles tadellos.

Ich könnte noch ein paar Kleinigkeiten auflisten die mir im Laufe des Tests aufgefallen sind, aber du erkennst sicherlich den Punkt worauf ich hinaus möchte. Wer keine größeren Ansprüche hat ist mit einer GoToSocial Instanz super zufrieden, allerdings hapert es häufig an Kleinigkeiten.

Zwischenfazit – Kleine Tools, große Hürden

Ich könnte jetzt noch viele Kleinigkeiten aufzählen, die mir im Laufe der Tests aufgefallen sind: kleinere Inkompatibilitäten, Eigenheiten in den HTTP-Headern, Timeouts bei der Föderation und so weiter. Aber das wäre Haarspalterei.

Der Punkt ist: Wer keine großen Ansprüche hat und einfach nur einen minimalistischen Account im Fediverse betreiben möchte, ist mit GoToSocial super beraten. Die Software ist schlank, ressourcenschonend und wirklich stabil. Aber sobald man versucht, etwas weiter über den Tellerrand zu schauen – also PeerTube, Bookwyrm, Pixelfed oder eben Wanderer zu integrieren – merkt man, dass viele Projekte noch nicht vollständig aufeinander abgestimmt sind.

Und das ist völlig verständlich. Jedes dieser Tools wird von kleinen Teams oder sogar Einzelpersonen entwickelt, meist in der Freizeit. Es gibt keinen großen Konzern im Hintergrund, der alles zentral steuert. Das ist einerseits der Charme des Fediverse, andererseits aber auch die Quelle vieler kleiner Frustrationen.

Fazit

Wer jetzt der Schuldige des ganzen ist, kann ich nicht beurteilen. Sicherlich gibt Mastodon die Entwicklung des ganzen vor und schlussendlich werden die ganzen kleinen Tools von Menschen programmiert und gepflegt die das lediglich in ihrer Freizeit tun. Ich hoffe nur, dass perspektivisch sich das ganze angleicht und alle möglichen Plattformen sauber miteinander kommunizieren können..

In meinem Homelab verwende ich einen Kubernetes Cluster der auf Talos als Betriebssystem aufsetzt. Bei einer kompletten Neuinstallation ist es für mich aufwendig immer drei USB Sticks vorzubereiten um dann alle drei Nodes parallel installieren zu können. Also entschied ich mich einen PXE Server bereit zu stellen um die ISO Images aus dem Netzwerk booten zu können.

Es gibt für das Endergebnis verschiedene Wege. Ich habe mich dazu entschlossen iVentoy als PXE Server zu verwenden. Ventoy an sich ist ja sicherlich vielen von euch schon ein Begriff. Damit kann man nämlich USB Sticks erstellen mit mehreren ISO Dateien. iVentoy ist vom gleichen Entwickler und bietet dann die Möglichkeit diese ISO Images aus dem Netzwerk zu booten.

Ich verwende wo ich nur kann Container, sei es Docker oder, wie in diesem Fall, LXC. Ich benötige hier nicht eine voll aufgeblähte virtuelle Maschine, wenn ein kleiner LXC auf meinem Proxmox Host dafür ausreichend ist.

Was ist ein PXE Server?

Ein PXE-Server (Preboot Execution Environment) erlaubt es Computern, ein Betriebssystem über das Netzwerk zu starten, ohne dass eine Festplatte oder ein USB-Stick nötig ist. Beim Start fragt der Computer per Netzwerk nach einem Boot-Server. Der PXE-Server antwortet und liefert die nötigen Daten, damit der Computer ein Betriebssystem laden und installieren kann. Das ist nützlich für die automatische Einrichtung vieler Computer.

LXC anlegen

Unter Proxmox könnt ihr ganz normal einen LXC anlegen. Ich verwende in meinem Fall einen priviligierten Container, weil es mir die Sache etwas einfach macht. Wer sehr stark auf Sicherheit wert legt, müsste für einen unpriviligierten Container entsprechend noch Dinge anpassen. Zudem verwende ich, wie in der Überschrift angegeben, Debian als Betriebssystem. Zum Zeitpunkt der Erstellung dieses Beitrages in Version 11 alias Bookworm. Ggf. sind Anpassungen bei Ubuntu notwendig. Wenn du den Container also angelegt hast, müsstest du ihn einmal wieder beenden bzw. noch nicht starten. Wir müssen nämlich die Konfiguration noch anpassen, weil wir sonst später auf ein APPARMOR Problem stoßen werden. Also bitte per SSH auf den Proxmox Server verbinden (oder die interne Shell nutzen) und die LXC Datei editieren

nano /etc/pve/lxc/<LXC ID>.conf

Die LXC ID siehst du im Proxmox Frontend. Hier fügen wir am Ende folgendes ein

lxc.apparmor.profile: unconfined
lxc.cap.drop:

Nun können wir den Container starten.

iVentoy installieren

Als erstes sollten wir natürlich das System aktualliseren

apt update&& apt upgrade -y

Jetzt benötigen wir bei einem LXC noch diverse Pakete. Bei einer VM könnten diese nicht notwendig sein.

apt install libevent-2.1-7 libevent-pthreads-2.1-7 glibc libwim15 libhivex0 wget

Jetzt laden wir uns noch das aktuelle Paket beiGitHub (externer Link) herunter. Am besten vorher die aktuelle Version kontrollieren.

wget https://github.com/ventoy/PXE/releases/download/v1.0.20/iventoy-1.0.20-linux-free.tar.gz

Anschließend können wir das Paket entpacken

tar xvfz iventoy-1.0.20-linux-free.tar.gz

Ich für meinen Teil packe solche Installationen immer nach/opt, aber das kannst du gerne anpassen. Ich verschiebe also die iVentoy Installation und benenne gleichzeitig den Ordner um

mv iventoy-1.0.20-linux-free /opt/pxe

Es sollte bei dir dann ungefähr so aussehen. Wichtig ist das VerzeichnisISO, weil du dort alle ISO Dateien ablegen muss welche du im Netzwerk verfügbar haben möchtest.

iVentoy starten und einrichten

Nun können wir das Programm starten

./iventoy.sh start

Du bekommst dann eine Ausgabe unter welcher PID der Prozess läuft und wie du auf die Webseite zugreifen kannst. Wir rufen also die iVentoy Seite einmal mit der IP deines Containers sowie Port 26000 auf und bekommen dann sowas angezeigt Nun hängt es wieder ein bisschen von deiner Wunschkonfiguration ab. Ich möchte den DHCP Server von iVentoy nicht verwenden, sondern den meines Unifi Gateways. Wenn du einen (für iVentoy) externen DHCP Server verwenden möchtest, gehst du links aufConfiguration und stellst beiServer Mode aufExternal. Etwas oben drüber dann auf speichern klicken. UnterImage Management kannst du die ISO Dateien sehen welche du ggf. vorher schon abgelegt hast. Andernfalls kannst du auf der rechten Seite auch per drag and drop eine neue hochladen.

Zu guter letzte müssen wir den Server “nochmal” starten. UnterBoot Information ist rechts ein Play-Button der grün hinterlegt ist. Den musst du unbedingt anklicken, sonst funktioniert es nicht.

Wenn du jetzt ein System mit der Bootoption Netzwerk am Anfang startest erwartet dich dann solch eine Anzeige ]]>selfhostedpxeproxmoxlinuxhttps://www.teqqy.de/meine-top-10-homelab-services-2024/Sun, 20 Oct 2024 13:00:00 +0100Sun, 20 Oct 2024 13:00:00 +0100https://www.teqqy.de/meine-top-10-homelab-services-2024/Nach langer Zeit möchte ich mal wieder ein Beitrag über meine Lieblings-Software in meinem Homelab schreiben. Der letzte Beitrag ist schon fast zwei Jahre alt und in diesem Zeitraum hat sich ein bisschen was getan. Nummer 10: Ghostfolio Ghostfolio (externer Link) ist eine Software um sein Wertpapierportfolio zu verwalten. Es gibt zwar viele weitere Onlineservices wie parqet oder ähnliche, aber als webbasiertes zum selbst betreiben sieht die Auswahl dann schon sehr eng aus. Ghostfolio nutze ich seit ca. zwei Jahren um mein Aktienportfolio damit zu verwalten und zu tracken. Ich bin keine Person die viel handelt, dennoch möchte man die Performance der einzelnen Werte gern mal ausgewertet haben.<![CDATA[

Nach langer Zeit möchte ich mal wieder ein Beitrag über meine Lieblings-Software in meinem Homelab schreiben. Der letzte Beitrag ist schon fast zwei Jahre alt und in diesem Zeitraum hat sich ein bisschen was getan.

Nummer 10: Ghostfolio

Ghostfolio (externer Link) ist eine Software um sein Wertpapierportfolio zu verwalten. Es gibt zwar viele weitere Onlineservices wie parqet oder ähnliche, aber als webbasiertes zum selbst betreiben sieht die Auswahl dann schon sehr eng aus. Ghostfolio nutze ich seit ca. zwei Jahren um mein Aktienportfolio damit zu verwalten und zu tracken. Ich bin keine Person die viel handelt, dennoch möchte man die Performance der einzelnen Werte gern mal ausgewertet haben.

Über die Zeit hinweg sind auch weitere Funktionen wie die Verwaltung von Kryptowährungen oder nicht digitalen Assets hinzugekommen. Ghostfolio könnte man auch als Service einkaufen, finde aber das es dann bessere Lösung gäbe.

Nummer 9: Mealie

Mealie (externer Link) ist eine Rezeptverwaltung. Klingt vielleicht erst mal nicht so spannend, aber durch den eingbauten scraper (ging schon ohne KI) können Seiten wie Chefkoch einfach ausgelesen und Zutaten oder Zubereitung einfac sauber importiert werden. Zumindest wenn das Rezept anständig hinterlegt ist. Ich nutze die Software zwar nur für wenige Rezepte die ich manuell eingetragen habe, aber auch hier hilft sie mir eine Zettelwirtschaft zu umgehen. Gerade wenn man von befreundeten Menschen ein Rezept des Saltes der letzten Grillparty bekommen hat oder auf Instram einen interessanten Kuchen fand.

Wer tiefer bei Mealie einsteigen möchte, kann sogar auch einen Wochenplan erstellen und die entsprechende Einklaufsliste sich ausgeben lassen.

Nummer 8: EVCC

Ich habe lange Zeit das Überschussladen unseres Elektroautos über Home Assistant realisiert. Dann hat allerdings Tesla die API bzw. den API Zugang angepasst und es wurde unzuverlässig. In einem alten Beitrag habe ich dieses vorgehen beschrieben und es kann sicherlich noch für diverse andere Hersteller verwendet werden. Bei meiner Recherche wie ich mein Unterfangen herstellerunabhängig realisieren kann, bin ich aufEVCC (externer Link) gestoßen. Die Software verbindet Photovoltaikanlage und Wallbox miteinander - oder auf Wunsch das Auto. Ich hätte auch von Kostal eine Wallbox kaufen können, aber sind wir mal ehrlich: Kostal und Software passen nicht so wirklich zusammen.

EVCC verbindet sich also mit unserem Kostal Wechselrichter bzw. KSEM und überprüft wie viel Strom produziert und viel viel Strom das Haus derzeit verbraucht. Diese Information wird dann an die Wallbox übermittelt und regelt deren Ausgangsleistung. Am Auto selbst muss also nichts eingestellt werden. So kann selbst der Besuch mit sauberem Strom versorgt werden.

Die Voraussetzung ist natürlich, dass man eine steuerbare Wallbox hat. Als wir unsere PV-Anlage 2020 installiert bekamen wollte ich noch eine OpenWallbox kaufen. Durch die Lieferengpässe und anschließende Inflation ist mir diese allerdings nicht mehr den aktuellen Kaufpreis wert. Ich habe entsprechend eine Easee Wallbox angeschafft die auch ohne Probleme zwischen 1- und 3-phasigem Laden wechseln kann. Sehr gut um auch kleinere Ladeleistungen mitnehmen zu können.

Zudem kann EVCC mittlerweile die heimische Batterie der PV-Anlage auch über Netzladen aufladen. Zumindest noch so lange wie es gesetzlich erlaubt ist.

Nummer 7: Paperless-NGX

Ich denke, dass jedem Paperless-NGX bekannt sein wird. Falls nicht: Paperless-NGX ist ein Dokumenten Management System das man auf dem eigenen Server hosten kann. Die Software bzw. der Quellcode hat in den letzten Jahren immer mal wieder neue Entwickler bekommen und so änderte sich der Name sehr häufig. Mittlerweile gibt es aber eine stabile Entwicklung die die Software immer besser macht.

Ich versuche mit Paperless den Papierkram in meinem Privatleben so gering als möglich zu halten. Lediglich Dokumente die im Original aufbewahrt werden müssen kommen in einen Ordner. Alles andere wird digitalisiert und danach geschreddert. Der Prozess der Digitalisierung wird bei mir noch nicht mit einem Dokumentenscanner durchgeführt, sondern per Smartphone App. Unter iOS nutze ich dafür die App “Paperparrot”. Als ehemaliger Beta-Tester bekomme ich diese glücklicherweise immer noch kostenfrei. Aber selbst wenn dem nicht so wäre, kann ich die App jedem Nutzenden ans Herz legen.

Nummer 6: Stirling PDF

Was für ein tolles Werkzeug für PDF Bearbeitung. Ich hatte den Namen immer mal wieder gelesen, hatte aber keine Lust mal nachzugucken was das denn für eine Software ist. Nun weiß ich es und verfluche mich ein wenig die Software noch nicht früher installiert zu haben. Viele kennen sicherlich das Problem PDF Dateien bearbeiten zu müssen. Egal ob zusammenfügen, trennen, Seiten drehen oder ähnliches. Für vieles müsste man sich extra Tools installieren. Nicht mit Stirling PDF. Damit kannst du all diese Funktionen bequem über den Browser erledigen. Bisher hatte ich noch keinen Anwendungsfall bei dem mir diese Software bei PDF-Dateien nicht weiterhelfen konnte.

Nummer 5: Minio

Minio (externer Link) kennen sicherlich nur diejenigen die tiefer in der technischen Materie der IT stecken. Mit diesem kleinen Tool kannst du nämlich einen S3 kompatiblen Speicherplatz bereit stellen. Dies braucht man zwar nicht so häufig, aber bei mir ist S3 Speicher sehr häufig das Backend für meine Backups. Gerade in meinem Kubernetes Cluster werden sämtliche Backups auf meinen Minio-Server gespeichert. Sei es die Volumes der Anwendungen oder Datenbank Backups, alles wird in einzelnen sogenannten Buckets gespeichert. Wer möchte könnten sogar hier noch eine gewisse Versionierung mit einbringen.

Ich wünschte es könnten mehr Softwareprodukte S3 Speicher als Backend für die Dateiablage nutzen. Sicherlich ist das eher etwas für fortgeschrittene, aber die einfachheit überzeugt für mich. Zumal die Dateiablage via Netzwerkprotokolle wie SMB oder NFS immer mal wieder ihre Fallstricke haben.

Nummer 4: Gatus

Viele werden Uptime Kuma als “Monitoring-Tool” kennen. Damit kann man hervorragend die Verfügbarkeit seiner Services im Homelab überwachen und sich über eine Statusänderung benachrichtigen lassen. Uptime Kuma würde ich auch jedem empfehlen im Homelab zu installieren. Sobald man allerdings versucht viele Dinge nur mittels einzelnen Konfigurationsdateien zu betreiben wird es schwierig. Das sogenannte Config-as-Code Prinzip hilft mir Dinge sehr einfach und nachhaltig reproduzieren zu können. Damit kann man in nur wenigen Augenblicken den “alten” Stand wiederherstellen. Häufig sind Backup- und Restoreprozesse in Anwendungen nicht vorhanden oder nur schwerlich umsetzbar. Eine Automatisierung ist nur in seltenen Fällen gegeben.

Gatus habe ich in meinem Kubernetes Cluster installiert und wird dort über eine einzelne Datei konfiguriert. Sobald die Anwendung bei einer Neuinstallation deployt wurde, habe ich den exakt gleichen Status wie vorher. Es erspart mühselige Arbeit alles neu einrichten zu müssen.

Nummer 3: Immich

Immich bezeichnet sich selbst als Google Photos alternative. Entsprechend würde das theoretisch auch für Apple Fotos gelten. Wobei Immich die Funktion zur Bearbeitung von Fotos fehlt. Du kannst mit der Software automatisiert deine Bilder deines Smartphones auf deinen Server laden. Dort können sie mittels Bilderkennung Personen kennzeichnen oder Ort auf einer Karte visualisieren. Letzteres natürlich nur mit entsprechend vorhandenen EXIF Daten. Immich nutze ich mittlerweile als “Langzeitbackup” meiner Fotos. Auf meinem Smartphone kann ich so schneller die Bilder löschen und aufräumen. Alle paar Wochen sortiere ich die Bilder in Immich dann entsprechenden Alben zu oder lösche gegebenenfalls auch hier.

Die Software hat leider einen Nachteil: Sie wird sehr aktiv entwickelt. Alle paar Versionen gibts ein Breaking Change der glücklicherweise auch als entsprechender gekennzeichnet wird. Ein einfaches automatisches Updaten z. B. über Docker Container und Watchtower wäre also nicht zu empfehlen.

Nummer 2: Mastodon Server

Als Herr M. Twitter aufkaufte ging es mit der Plattform leider stark bergab. Am Anfang hoffte ich noch, dass es nicht ganz so tragisch wird, bin mittlerweile allerdings sehr froh die Plattform “verlassen” zu haben. Mein Account existiert dort noch, wird aber seit langem nicht mehr aktiv genutzt. Ich bin dann sehr schnell zu Mastodon gewechselt. Gerade so als ITler eine sehr interessante Plattform. Zudem BluSky und Threads damals noch nicht wirklich in Europa zugänglich waren.

Seit vielen Monaten hoste ich also meine eigene Instanz teqqy.social. In dem Netzwerk bin ich derzeit auch was das posten von Beiträgen angeht, am aktivsten. Über die Zeit hinweg habe ich dort auch viele gleichgesinnte getroffen und fühle mich dort sehr wohl. Natürlich hat Mastodon nicht die Nutzeranzahl und für Menschen oder Organisationen die unbedingt Reichweite benötigen ist es derzeit nicht das richtige Netzwerk.

Nummer 1: Home Assistant

Auch in meinem alten Beitrag war Home Assistant die beliebteste Software in meinem Homelab. Wobei die Position 1 nicht unbedingt aus dem “Lieblings”-Faktor heraus entstand sondern weil sie einfach Elementar wichtig geworden ist. MitHome Assistant (externer Link) werden sämtliche aktiven Komponenten des Hauses gesteuert, Alarme generiert, die Energienutzung optimiert sowie Langzeitaufzeichnungen von Strom und Wasser realisiert. Ohne die wohl beste Smart Home Software kämen wir nicht mehr aus. Dabei nutzen wir mittlerweile nur ein Bruchteil der Möglichkeiten die die Software mittlerweile liefern kann. Unser Smart Home besteht aus ca.

• 10 Z-Wave
• 24 ZigBee
• 8 WiFi

Aktoren, Sensoren und anderen Geräten. Diese möchte ich sauber über ein Frontend managen. Dabei ist Home Assistant nicht immer die zuverlässigste Software aber ich habe hier alle Freiheiten schnell und (meistens) unkompliziert einzelne Komponenten auszutauschen. Manchmal sind es aber auch einfach Kleinigkeiten die mir Home Assistant ermöglicht, z. B. mittels Knopfdruck auf meinem Elgato Streamdeck die Videobeleuchtung für ein Teams-Meeting einzuschalten. Oder kürzlich via Music Assistant den Radiosender auf den HomePod Mini im Büro abspielen zu lassen. Wer sich noch nicht mit der Software vertraut gemacht hat, sollte auf jeden Fall mal ein Blick darauf werfen.

Der Proxmox Backup Server ist eine eigenständige Software mit dem man sein Proxmox Server besser sichern kann. Dieser bietet diverse weitere Features wie Einzeldateiwiederherstellung. Wenn du ein bisschen mehr wissen möchtest, empfehle ich dir mein Video dazu.

In dieser Anleitung soll es aber darum gehen wie man beim Proxmox Backup Server eine NFS Freigabe hinzufügen kann. Da ich UnRaid als NAS System derzeit verwende bin ich hier direkt auf weitere Fehler gestoßen. Grund genug alles zusammen in einen Blogbeitrag zu verfassen. Vielleicht stößt jemand anderes auch auf dieses Problem.

NFS Freigabe in Unraid anlegen

In Unraid legen wir uns zuerst eine Freigabe an. In dieser Anleitung heißt die Freigabeproxmox. Das ist für die weiteren Schritte wichtig zu wissen. Ich empfehle die Backups erst auf dem Cache Array zu speichern und dann per. Mover auf das eigentliche Array verschieben zu lassen. So sind die Backups deutlich schneller erstellt. Wenn die Freigabe angelegt ist, möchte wir diese natürlich via NFS publizieren. Also stellen wirExportieren aufja. Anschließend müssen wir dieSicherheit vonÖffentlich aufprivat umstellen. Das ist wichtig, da wir sonst keine besonderen NFS Export Parameter mitgeben können. In dem FeldRegel Tragen wir dann folgendes ein:

192.168.10.19/24(sec=sys,rw,insecure,anongid=100,anonuid=99,no_root_squash)

Die IP-Adresse am Anfang muss auf die IP-Adresse deines Promox Backup Servers angepasst werden. Natürlich könntest du auch das ganze Netz frei geben, ist aber aus Sicherheitsgründen nicht empfohlen.

PBS NFS Freigabe einrichten

Nun können wir uns um den Proxmox Backup Server kümmern. Diesen Part habe ich ebenfalls mal in einem Video fest gehalten. Falls du also lieber das schauen möchtest. Andernfalls lies gerne weiter.

Wir müssen uns per SSH mit dem Server verbinden. Anschließend überprüfen wir ob der NFS Client installiert ist bzw. installieren ihn direkt.

apt install nfs-common

Bei mir war er schon installiert, aber sicher ist sicher. Anschließend wollen wir die NFS Freigabe vom Unraid Server mounten. In Linux werden Freigaben normalerweise nach/mnt gelegt. Also erstellen wir uns dort drin ein Verzeichnis in dem wir das NAS mounten.

mkdir -p /mnt/nfs-backup

Du kannst natürlich den Partnfs-backup umbenennen. Passe nur den Rest der Anleitung entsprechend an deine Umgebung an.

Nun mounten wir die Freigabe mit

mount -t nfs 192.168.10.21:/mnt/user/proxmox /mnt/nfs-backup

Die IP-Adresse musst du natürlich auf die IP-Adresse deines Unraid Servers anpassen. Hier sollte natürlich kein Fehler auftreten. Wenn das der Fall sein sollte, überprüfe ob die Freigabe und der Ordner korrekt angelegt worden sind. Damit die Freigabe auch nach dem Neustart vom PBS wieder funktioniert sollten wir das permanent machen. Dazu editieren wir die/etc/fstab Datei

nano /etc/fstab

Und fügen am Ende folgende Zeile ein:

192.168.10.21:/mnt/user/proxmox /mnt/nfs-backup nfs rw 0 0

Berechtigungen der Freigabe anpassen

Der Proxmox Backup Server erstellt die Sicherungen mit dem Nutzerbackup und der UUID/GUID34. Da dies nicht zu der Freigabe von Unraid passt, müssen wir die ändern. Ich habe festgestellt, dass es am einfachsten ist, wenn wir in der Freigabe einen weiteren Ordner anlegen und dem die notwendigen Berechtigungen geben.

mkdir -p /mnt/nfs-backup/backups

Auch hier kannst du das gerne an deine Gegebenheiten anpassen. Anschließend ändern wir den Besitzer des Ordners

chown backup:backup /mnt/nfs-backup/backups

Sollte hier ein Fehler auftreten mitOperation not permitted hast du ggf. die Anleitung oben zu Unraid vergessen. Die NFS Export Parameter sind nämlich hier entscheidend.

Datastore im Proxmox Backup Server hinzufügen

Jetzt können wir endlich die Freigabe auch im PBS hinzufügen. Dazu verbinden wir uns zur PBS GUI und wählen links unterDatastoreAdd Datastore aus. Den Namen kannst du natürlich frei vergeben. AlsBacking Path kommt der Pfad der Freigabe rein. In unserem Fall/mnt/nfs-backup/backups Solltest du den angepasst haben, bitte entsprechend hier auch tun. Die restlichen Parameter kannst du nach belieben einstellen.

Sollte hier ein Fehler auftreten wird der Backup-Nutzer nicht in das Verzeichnis schreiben dürfen. Überprüfe nochmal die Berechtigungen des Pfades.

Der Proxmox Backup Server legt nach dem Bestätigen die ganzen Chunks an. Dies kann je nach Performance des Netzwerkes oder des Unraid Servers zwischen ein paar Sekunden und ein paar Minuten dauern. Anschließend kannst du den Datastore zu Proxmox hinzufügen und deine Backups erstellen.

Ich persönlich finde S3 Speicher sehr angenehm und versuche ihn für verschiedene Anwendungsbereiche zu verwenden. Heute habe ich mir wieder einen extra Server installiert und möchte den Prozess hiermit quasi dokumentieren. Mit dieser Anleitung installieren wirMinio (externer Link) auf einem Debian 12 (Bookworm) System. Dazu verwenden wir direkt nginx als Reverse Proxy und sichern das mittels Let’s encrypt Zertifikaten ab, sodass immer eine gesicherte Verbindung aufgebaut werden kann.

Was ist S3 Speicher?

S3-Speicher bezieht sich auf Amazon Simple Storage Service, kurz Amazon S3. Es handelt sich dabei um einen skalierbaren Cloud-Speicherdienst von Amazon Web Services (AWS). S3 ermöglicht es Benutzern, große Datenmengen sicher und kostengünstig in der Cloud zu speichern. Ein Objektspeicher ist eine Art von Datenspeicher, der darauf ausgelegt ist, große Mengen unstrukturierter Daten in Form von Objekten zu speichern. Jedes Objekt besteht aus Daten, Metadaten und einem eindeutigen Identifikator. Im Fall von S3 werden diese Objekte in sogenannten “Buckets” organisiert, die als virtuelle Container dienen, um die Objekte zu gruppieren.

Installation von Minio

Anlegen des Nutzers und Gruppe

Mittlerweile gibt es extra Paket fürDebian (externer Link) und Ubuntu sodass sich die Installation etwas mehr vereinfacht. Minio sollte natürlich nicht im Kontext des root-Nutzers laufen. Best practise ist hier, sich einen eigenen Nutzer anzulegen. Du kannst natürlich auch gerne schon einen vorhanden verwenden.

groupadd -r minio-useruseradd -M -r -g minio-user minio-user

Wie geschrieben kannst du die Parameter auch entsprechend anpassen. Bedenke aber, dass die Anleitung davon ausgeht, dass du die Nutzer und Gruppe genau so genannt wurden.

Datenverzeichnis vorbereiten

Als nächstes solltest du dir noch Gedanken machen wohin auf deinem System die Daten abgelegt werden sollen. In meinem Fall lege dich diese nach/opt ab. Zuerst wird das Verzeichnis angelegt und anschließend bekommt unser Minio Nutzerminio-user das Verzeichnis als Besitzer zugeordnet.

mkdir -p /opt/miniochown minio-user:minio-user /opt/minio

Minio Paket installieren

Glücklicherweise gibt es Minio mittlerweile auch als fertiges Paket, sodass wir uns um diverse Dinge keine Gedanken machen müssen. Dies beinhaltet nämlich mittlerweile auch einensystemd Skript um das Programm sauber darüber starte und stoppen zu können. Zuerst laden wir uns das Paket erst einmal runter. Sehr wahrscheinlich ist die verlinkte Version schon veraltet wenn du dieses Tutorial liest. Schaue als bitter malhier (externer Link) welche die aktuelle Version ist und ersetze die Versionnummer.

wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio_20240217011557.0.0_amd64.deb -O minio.deb

Sollte dein System aus irgendwelchen Gründen den Befehlwget nicht kennen kannst du den mittels

apt install wget -y

installieren.

Nun brauchen wir nur noch Minio zu installieren und haben schon einen großen Teil erledigt.

dpkg -i minio.deb

Nach ein paar Sekunden ist das ganze auch schon fertig und wir können anfangen das Programm zu konfigurieren.

Standardkonfiguration für Minio anlegen

Wir nutzen in diesem Tutorial eine recht einfache Konfiguration. Diese kannst du natürlich immer noch nach weiterem belieben erweitern wenn du möchtest. Wir legen uns also die Default Konfiguration an

touch /etc/default/minio

und bearbeiten diese. Ich verwende immervim als Editor. Du kannst natürlich auch gernenano verwenden wenn dir das lieber ist.

vim /etc/default/minio

Darin kopieren wir jetzt folgende Zeilen

# Definition des Admin Accounts
MINIO_ROOT_USER=myminioadmin
MINIO_ROOT_PASSWORD=minio-secret-key-change-me
# MINIO_VOLUMES setzt das Verzeichnis in dem unsere Daten gespeichert werden
MINIO_VOLUMES="/opt/minio"
# Damit wir auch die Konsole bzw. Webfrontend verwenden können, müssen wir das natürlich noch setzen
MINIO_OPTS="--console-address :9001"

Bitte pass entsprechendMINIO_ROOT_USER undMINIO_ROOT_PASSWORD an und lasse die Werte nicht auf default setzen. Auch wenn du das System nicht nach außen hin veröffentlichst, sollten niemals Standardzugangsdaten verwendet werden.

Minio starten und Login

Nun starten wir Minio erst einmal um zu sehen ob alles funktioniert. Zudem sollten wir uns auch einmal anmelden um auch das gegengetestet zu haben.

systemctl enable miniosystemctl start minio

Nun öffnen wir einen Browser und navigieren zu{HOSTIP}:9001 und sollten anschließend so ein Bild sehen. Bitte anschließend einmal einloggen um zu sehen, dass auch deine Zugangsdaten korrekt funktionieren.

nginx als Rervse Proxy mit Zertifkat einrichten

Ich verwende in dem TutorialCerbot zum generieren des Let’s encrypt Zertifikates. Zudem wird mein öffentliches DNS meiner Domain von Cloudflare betrieben. Entsprechend verwende ich hier diedns-challenge mit Cloudflare und API Token.

Cloudflare API Token generieren

Auf der Cloudflare Profilseite gibt es den PunktAPI Tokens (externer Link) (Generischer Link dorthin). Dort legen wir uns rechts oben ein neuen Token an und verwenden das TemplateEdit Zone DNS. Du solltest nun ungefähr dieses Bild hier sehen. Den Bereich Permissions lassen wir so wie er ist. Im BereichZone Resources müssen wir im letzten drop down Feld in der Reihe nur noch die entsprechende Domain auswählen. Den Rest können wir mitContinue to summary ebenfalls auslassen. Auf der nächsten Seite bestätigen wir mitCreate Token und nun wird uns unser Token angezeigt. Ich empfehle diesen sicher abzuspeichern falls du den später noch mal für andere Dinge verwenden möchtest.

Pakete installieren

Nun zurück zu unserer Linux Maschine. Wir können hier nun endlich alle benötigten Pakete installieren die wir brauchen.

apt install nginx certbot python3-certbot-dns-cloudflare

Dies benötigt ein paar Sekunden und wir können weiter machen uns unser Zertifikat zu besorgen.

Let’s encrypt Zertifikat mit Certbot beantragen

Zuerst richten wir noch die Punkte für die DNS Challenge zu Cloudflare ein. Dazu erstellen wir uns ein Verzeichnis

mkdir -p /etc/certbot

und legen uns dort eine Datei an

touch /etc/certbot/credentials

in diese kommt nun unser Cloudflare Token. Also editieren wir die Datei

vim /etc/certbot/credentials

und kopieren folgendes dort rein

dns_cloudflare_api_token={DEIN_CLOUDFLARE_API_TOKEN}

Damit die Datei nicht von jedem Nutzer auf dem System gelesen werden kann, passen wir noch die Berechtigungen mittels

chmod600 /etc/certbot/credentials

an. Nun haben wir den Grundstock gelegt um das Zertifikat beantragen zu können. Beachte jetzt, dass du die Domain entsprechend an deine Domain anpassen musst.

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/certbot/credentials -d minio.example.com -d s3.example.com

nginx einrichten

Nun können wir uns mit dem Thema nginx als reverse proxy für minio beschäftigen. Die Software wurde bereits oben schon installiert, also können wir direkt mit der Konfiguration der Seite beginnen. Dazu wechseln wir in das Konfigurationsverzeichnis für die Webseiten

cd /etc/nginx/sites-available

Dort legen wir dann die Seitenkonfiguration an

touch minio.conf

und können dann auch diese im Anschluss bearbeiten

vim minio.conf

Dort kannst du dann folgendes rein kopieren:

## API End Point
server
{
# Listen
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Directory & Server Naming
server_name s3.example.com;
# HTTP to HTTPS redirection
if ($scheme != "https")
{
return 301 https://$host$request_uri;
}
# SSL
ssl_certificate /etc/letsencrypt/live/minio.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/minio.example.com/privkey.pem;
# Disable Hidden FIle Access Except Lets Encrypt Verification
location ~ /\.well-known
{
allow all;
}
# Allow special characters in headers
ignore_invalid_headers off;
# Allow any size file to be uploaded.
# Set to a value such as 1000m; to restrict file size to a specific value
client_max_body_size 0;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
location /
{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 300;
# Default is HTTP/1, keepalive is only enabled in HTTP/1.1
proxy_http_version 1.1;
proxy_set_header Connection "";
chunked_transfer_encoding off;
proxy_pass http://127.0.0.1:9000;
}
# Nginx Logging
access_log /var/log/nginx/s3.example.com-access.log;
error_log /var/log/nginx/s3.example.com-error.log warn;
}
###################### Console ######################
server
{
# Listen
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Directory & Server Naming
server_name minio.example.com;
# HTTP to HTTPS redirection
if ($scheme != "https")
{
return 301 https://$host$request_uri;
}
# SSL
ssl_certificate /etc/letsencrypt/live/minio.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/minio.example.com/privkey.pem;
# Disable Hidden FIle Access Except Lets Encrypt Verification
location ~ /\.well-known
{
allow all;
}
# Allow special characters in headers
ignore_invalid_headers off;
# Allow any size file to be uploaded.
# Set to a value such as 1000m; to restrict file size to a specific value
client_max_body_size 0;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
location /
{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-NginX-Proxy true;
proxy_connect_timeout 300;
# To support websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
chunked_transfer_encoding off;
proxy_pass http://127.0.0.1:9001;
}
# Nginx Logging
access_log /var/log/nginx/minio.example.com-access.log;
error_log /var/log/nginx/minio.example.com-error.log warn;
}

Bitte beachte, dass du überall dasexample.com durch deine eigene Domain austauschst. Die Konfiguration habe ich vonhier (externer Link) übernommen und ein wenig angepasst.

Jetzt legen wir noch den symlink an

ln /etc/nginx/site-available/minio.conf /etc/nginx/site-enabled/

und sollten testen ob wir auch kein Fehler gemacht haben. Das können wir am einfachsten mittels

nginx -t

Hier sollte keine Ausgabe erscheinen. Andernfalls müstest du die angezeigten Fehler noch verbessern. Zu guter letzt können wir nginx neu starten

systemctl restart nginx

Jetzt kannst du auch Minio über https über deine Domainnamen erreichen. Solltest du Minio nur im lokalen Netzwerk verwenden, denk daran, dass noch im DNS entsprechend zu hinterlegen.

Optional: Minio Admin Cli installieren

Gegebenenfalls brauchst du zu einem späteren Zeitpunkt mal die Admin CLI von Minio. Also solltest du diese direkt mit installieren. Diese ist ein einfaches binary das wir nur auf das System kopieren müssen.

curl https://dl.min.io/client/mc/release/linux-amd64/mc -o /usr/local/sbin/mc

Allerdings wird es ohne Execute Rechte nicht ausgeführt werden können, also fügen wir diese noch hinzu

chmod +x /usr/local/sbin/mc

Anschließend könntest du mittelsmc den Minio Server auch via CLI administrieren.

Fazit

In meinemKubernetes Cluster verwende ich Minio um daraufBackups abzulegen die mittelsvolsync (externer Link) erstellt wurden. Ebenso verwendet Thanos den S3 Speicher als Langzeitspeicher um die Prometheus Daten lange aufzuheben.

Solltest du Fragen zu dem Tutorial haben, kannst du mich gerne über eine der im Blog angegebenen Netzwerke erreichen.

Wie langjährige Leser meines Blogs oder Zuschauer meines YouTube Kanals wissen, nutze ich primär Traefik als Reverse Proxy unter Docker. Über die letzten Jahre hat sich entsprechend etwas an Know how angesammelt. Durch einenBeitrag (externer Link) auf Mastodon vonThomas Leister (externer Link) bin ich darauf gekommen auch mal http3 zu aktivieren. Was du entsprechend tun musst, um das bei dir ebenfalls einzurichten habe ich hier aufgeschrieben.

Vorteile von http3

HTTP/3 (externer Link) ist die neueste Version des Hypertext Transfer Protocols (HTTP) und bringt mehrere Vorteile gegenüber seinen Vorgängerversionen, insbesondere HTTP/1.1 und HTTP/2, mit sich. Hier sind einige der wichtigsten Vorteile von HTTP/3:

1. Schnellerer Verbindungsaufbau: HTTP/3 verwendet dasQUIC (externer Link) -Protokoll (Quick UDP Internet Connections), das auf UDP (User Datagram Protocol) basiert. Im Vergleich zu TCP (Transmission Control Protocol), das in vorherigen HTTP-Versionen verwendet wurde, ermöglicht QUIC einen schnelleren Verbindungsaufbau. Es beseitigt die Latenz, die durch den sogenannten “Handshake” in TCP verursacht wird.

2. Multiplexing ohne Head-of-Line-Blocking: HTTP/3 unterstützt effizientes Multiplexing von Anfragen und Antworten. Im Gegensatz zu HTTP/1.1, bei dem eine Verbindung nur eine Anfrage gleichzeitig behandeln kann (Head-of-Line-Blocking), können bei HTTP/3 mehrere Anfragen und Antworten gleichzeitig übertragen werden. Dies verbessert die Effizienz und verkürzt die Ladezeiten von Webseiten.

3. Bessere Leistung bei Netzwerkproblemen: HTTP/3 wurde entwickelt, um besser mit Netzwerkproblemen umzugehen. Das QUIC-Protokoll ermöglicht es, Verbindungen beizubehalten, auch wenn sich die Netzwerkbedingungen ändern. Dies trägt dazu bei, dass die Leistung aufrechterhalten wird, selbst wenn es zu Paketverlusten oder Netzwerkwechseln kommt.

4. Adaptivität: HTTP/3 wurde entwickelt, um sich besser an verschiedene Netzwerkbedingungen anzupassen. Es kann sich automatisch an veränderte Latenzen und Bandbreiten anpassen, um eine optimale Leistung zu gewährleisten.

5. Verbesserte Sicherheit: HTTP/3 unterstützt standardmäßig Verschlüsselung durch Transport Layer Security (TLS). Die Integration von TLS in den Kern des Protokolls trägt zur Sicherheit der Datenübertragung bei.

6. Flexibilität: HTTP/3 ist so konzipiert, dass es besser mit den Anforderungen moderner Webanwendungen und Dienste umgehen kann. Durch die kontinuierliche Entwicklung des Protokolls können zukünftige Anforderungen besser erfüllt werden.

Es ist wichtig zu beachten, dass die Einführung von HTTP/3 nicht nur von den Vorteilen, sondern auch von der Unterstützung auf Server- und Clientseite abhängt. Nicht alle Webserver und Browser unterstützen möglicherweise bereits HTTP/3, aber die Akzeptanz nimmt stetig zu.

Anpassen der traefik Konfiguration

Ich verwendet primär dietraefik.yml Datei um alles zu konfigurieren. Nutzt du mehr Labels, musst du das natürlich umbauen. Mit traefik 2.11 und 3 muss noch die experimentelle Funktion aktiviert werden. Dies kann zu einem späterern Zeitpunkt nicht mehr notwendig sein.

experimental:http3:true

Nun sind noch die Entrypoints anzupassen. meiner heißtwebsecure für die Verbindung von https. Entsprechend brauchen wir hier nur

http3:advertisedPort:'443'

hinzuzufügen. Der vollständigkeit halber sieht mein kompletter Block so aus:

entryPoints:ping:address:':88'web:address:':80'http:redirections:entryPoint:to:websecurescheme:httpswebsecure:address:':443'http:http3:advertisedPort:'443'proxyProtocol:trustedIPs:-10.0.0.0/8-172.16.0.0/12-192.168.0.0/16forwardedHeaders:trustedIPs:-10.0.0.0/8-172.16.0.0/12-192.168.0.0/16

Natürlich reicht das nicht ganz aus. Wie ihr seht, veröffentliche ich Port443 um http3 auszuliefern. Da http3 aber via QUIC über UPD kommuniziert, muss auch diedocker-compose.yaml Datei angepasst werden.

Die Portkonfiguration sieht dann entsprechen so aus:

ports:-target:80published:80protocol:tcpmode:host-target:443published:443protocol:tcpmode:host-target:443published:443protocol:udpmode:host

Der letztetarget Block ist der wichtige. Hier wird Port 443 auf udp ausgeliefert. Abschließend noch den Container neu starten

docker compose rm -sf&& docker compose up -d

Solltest du mehr als nur Traefik in der Datei haben, werden diese Services entsprechend auch neu gestartet. Ich empfehle zukünftig traefik zu separieren.

Du willst deine RSS-Feeds selbst verwalten, ohne auf Drittanbieter angewiesen zu sein?FreshRSS ist ein kostenloser, selbst gehosteter RSS-Reader, der dir volle Kontrolle über deine Nachrichtenquellen gibt. Die Open-Source-Software lässt sich in wenigen Minuten mit Docker installieren und funktioniert perfekt mit Apps wie Reeder (iOS) oder FeedMe (Android).

In dieser Anleitung zeige ich dir Schritt für Schritt, wie du FreshRSS einrichtest – von der Docker-Installation über das Importieren bestehender Feeds bis zur Einbindung mobiler Apps. Das Beste daran: FreshRSS bietet einevollständige API-Unterstützung, sodass du deine Feeds überall synchronisiert nutzen kannst.

Für mich persönlich war genau dieses API-Feature der entscheidende Grund, auf FreshRSS zu setzen. Nach Jahren der Nutzung kann ich sagen: Es ist die zuverlässigste selbst gehostete RSS-Lösung, die ich kenne.

Diejenigen die immer noch RSS nutzen wissen es sehr zu schätzen. Es gibt zwar mittlerweile viele Dienste die einen über neue Informationen auf Seiten benachrichtigen, aber wenn man „nur“ Blogs liest ist das Abonnement von RSS Feeds die wohl bessere Wahl. Feedreader, eines der alten Google Produkte, war sicherlich ein Vorreiter auf diesem Gebiet. Im laufe der ganzen Jahre kamen und gingen dann viele andere Produkte und Onlinedienste. Ich setze schon seit Jahre auf eine selbst gehostete Variante mitFreshRSS (externer Link) .

In der Szene der Open Source RSS Tools gibt es natürlich viele weitere Programme die sicherlich auch alle sehr gut sind. Für mich gab es nie den Grund mir andere detaillierter anzusehen da ich mit FreshRSS sehr gut zurecht komme. Zudem bietet es ein Feature an, dass für mich ein entscheidendes Kriterium ist. Dazu aber später noch mehr.

Installation von FreshRSS

Wie viele andere Softwareprodukte, die ich hier vorstelle, kann FreshRSS auch unter Docker installiert werden. Glückerlicherweise gibt der Entwickler einem die Wahl ob man mit der integrierten SQLite arbeiten möchte, oder eine MySQL bzw. PostgresDB Datenbank anbinden möchte. Je nachdem wie die heimische Infrastruktur so aufgestellt ist, empfiehlt sich das eine oder andere mehr.

Für diejenigen die nichts mit Docker oder Containerisierung anfangen können, gibt es sogar noch die klassische Installation. Allerdings möchte ich in diesem Beitrag eher auf die Variante in Docker zurückgreifen.

FreshRSS mit Docker Compose

Ich habe hier mal einedocker-compose.yaml Datei vorbereitet die mit PostgresDB als Datenbankbackend arbeitet. Eine Anpassung auf MySQL/MariaDB ist recht einfach vorzunehmen. Lassen wir die DB weg, können wir auch einfach bei der Installation die SQLite Variante auswählen.

---services:freshrss-db:image:postgres:17container_name:fressrss-dbrestart:unless-stoppedvolumes:-/etc/localtime:/etc/localtime:ro-/etc/timezone:/etc/timezone:ro-/var/docker/freshrss/db:/var/lib/postgresql/dataenvironment:-POSTGRES_USER=freshrss-POSTGRES_PASSWORD=${POSTGRES_PASSWORD}-POSTGRES_DB=freshrssfreshrss-app:image:freshrss/freshrss:latestcontainer_name:freshrss-apprestart:unless-stoppeddepends_on:-freshrss-dbvolumes:-/etc/localtime:/etc/localtime:ro-/etc/timezone:/etc/timezone:ro-/var/docker/freshrss/data:/var/www/FreshRSS/data-/var/docker/freshrss/extensions:/var/www/FreshRSS/extensionsenvironment:-CRON_MIN=*/20ports:-80:80

Wer das ganze mittels Traefik auch sauber mit Zertifikaten etc hosten möchte, verweise ich einfach auf meinevorbereitete Version auf GitHub (externer Link) .

Webinstallation

Leider müssen wir noch ein paar Schritte unternehmen um den RSS-Reader wirklich komplett installieren zu können. Die Installation erkennt nicht die Datenbankparameter oder ähnliches sodass wir die Schritte manuell durchführen müssen.

Sobald das alles durch ist, können wir uns mit den Zugangsdaten anlegen die wir anfangs angegeben haben. Unser erster Nutzer ist nämlich direkt Administrator der Seite.

Erste Schritte nach der Installation

Grundsätzlich kann die Software direkt verwendet werden. Allerdings habe ich noch einen kleinen Tipp der das Leben im Nachgang einfacherer macht. Wer nämlich wie ich die Feeds nicht über den Browser konsumieren möchte, sondern mittels eine Anwendung muss die API frei schalten. Dafür gehen wir rechts oben auf das Zahnrad und dann auf Authentifizierung. Hier setzen wir das Häkchen bei * API-Zugriff erlauben (für mobile Anwendungen benötigt)* und klicken aufSpeichern Nun müssen wir noch das API Kennwort für unseren Nutzer festlegen. Das machen wir in unserem Profil das ihr links oben direkt findet. Im unteren Bereich unterAPI-Verwaltung tragt ihr einfach ein Passwort ein. Sicherer wäre es, wenn ihr ein anderes verwendet als für euren Login.

Nutzung von FreshRSS

Löschen des FreshRSS Feeds (optional)

Nachdem wir die grundlegenden Schritte durchgeführt haben, können wir endlich die Software nutzen. Wir sollten zurück zur Startseite gehen - Klick links oben auf den Produktnamen. Anschließend wählen wir die ** Abonnementverwaltung** aus. Hier sollte bis auf den Feed der Software selbst nichts weiteres angezeigt werden.

Wenn ihr den Feed nicht benötigt, könnt ihr den natürlich löschen. Mit einem Klick auf das Zahnrad und dann rechtsEntfernen.

Import von bestehenden RSS Abonnements (optional)

Natürlich kann man auch von seinem bestehenden RSS Feedreader die Feeds importieren. Also zumindest solange der bisherige auch ein Export in zum Beispiel OPML Format unterstützt. Alles mir bisher gängigen haben das beherrscht. Hierzu klicken wir wieder aufAbonnementverwaltung und dann auf **Importieren / Exportieren **. Nun können wir rechts eine Datei unterImportieren auswählen und aufImportieren klicken.

Feeds hinzufügen

Um neue Feeds hinzuzufügen, wie zum Beispiel den von teqqy.de, klickt man links oben auf das+ Symbol. Anschließend kopiert man die Feed-URL in das Feld und klickt aufHinzufügen Wer möchte, kann natürlich vorher noch eineKategorie erstellen um gegebenenfalls eine größere Menge an Feeds besser zu verwalten.

3rd Party Apps

Da meine primären Endgeräte auf Apple Basis laufen, kann ich hier leider keine große Liste aufzeigen die ich empfehlen kann. Falls jemand ein guten RSS Client kennt der mit FreshRSS zusammen arbeitet, kann er mir den Tipp gerne zukommen lassen.

MacOS und iOS/iPadOS

Unter den Betriebssystemen verwende ich seit JahrenReeder (externer Link) als RSS Reader App. Mittlerweile in Version 5 angekommen hatte es mich immer gut begleitet. Seit in einer der letzten Versionen auch eine korrekte Unterstützung von FreshRSS via API hinzugekommen ist, war natürlich ein weiterer Grund auf die Liste gekommen.

Um Reeder einzurichten brauchen wir wieoben beschrieben einAPI-Passwort. In Reeder selbst gehen wir dann aufAccounts undAdd Account. Ganz unten findet man dann FreshRSS zur Auswahl. Nun tragen wir die benötigten Daten ein und klicken aufSign in. Anschließend zieht sich Reeder alle Informationen und würde noch ungelesene Artikel anzeigen.

Häufig gestellte Fragen zu FreshRSS

Was ist FreshRSS?

FreshRSS ist ein kostenloser, Open-Source RSS-Reader, den du auf deinem eigenen Server installieren kannst. Anders als Cloud-Dienste behältst du die volle Kontrolle über deine Daten und Feeds.

Ist FreshRSS wirklich kostenlos?

Ja, FreshRSS ist komplett kostenlos und Open Source. Du benötigst lediglich einen Server oder Computer, auf dem du die Software installieren kannst. Es fallen keine Lizenzkosten an.

Welche Apps kann ich mit FreshRSS nutzen?

FreshRSS unterstützt verschiedene mobile Apps über seine API. Beliebte Optionen sind Reeder (iOS/macOS), FeedMe (Android) und NetNewsWire (iOS/macOS). Alle Apps, die mit Google Reader kompatibel waren, funktionieren meist auch mit FreshRSS.

Wie viel Speicherplatz benötigt FreshRSS?

Die Installation selbst benötigt etwa 50-100 MB. Je nach Anzahl deiner Feeds und gespeicherten Artikeln solltest du 500 MB bis 2 GB Speicherplatz einplanen. Bei sehr vielen Feeds können es auch mehr werden.

Kann ich FreshRSS ohne Docker installieren?

Ja, FreshRSS lässt sich auch klassisch per PHP auf einem Webserver installieren. Die Anforderungen sind: PHP 7.4+, Apache oder Nginx, und optional MySQL/PostgreSQL. Die Docker-Variante ist jedoch einfacher zu verwalten.

Update Dezember 2025: Dieser Artikel wurde überarbeitet und berücksichtigt die wichtigen Änderungen der Tesla Fleet API sowie aktuelle Teslamate-Versionen.

Moderne Fahrzeuge bieten mittlerweile eine API-Schnittstelle, um alle möglichen Daten auslesen zu können. Tesla war einer der ersten Hersteller, der dies umfangreich zur Verfügung stellt. Entsprechend sind Softwareprodukte wie Teslamate entstanden. Teslamate ist ein selbstgehosteter Open-Source-Datenlogger, der deine Tesla-Daten kontinuierlich erfasst, speichert und mit Grafana visualisiert.

Was hat sich 2025 geändert?

Die wichtigsten Updates auf einen Blick:

Tesla Fleet API: Tesla hat die inoffizielle “Owner API” durch die offizielle Fleet API ersetzt. Seit Februar 2025 gilt ein Pay-per-Use-Modell mit monatlichem $10-Freikontingent. Für Privatnutzer mit 1-2 Fahrzeugen reicht das Kontingent meist aus, zusätzliche Kosten liegen bei etwa $2-5/Monat bei intensiver Nutzung.

PostgreSQL 17: Teslamate benötigt nun mindestens PostgreSQL 16.7 oder 17.3. Die Entwickler empfehlen PostgreSQL 17.

Fleet Telemetry: Neu ist die Möglichkeit, dass das Fahrzeug Daten direkt streamt. Das ist präziser und günstiger als klassisches Polling, aber komplexer in der Einrichtung. Fleet Telemetry erfordert einen eigenen Server-Endpunkt und TLS-Zertifikate. Die Daten werden dann vom Fahrzeug per WebSocket gestreamt, sobald sich Werte ändern. Das spart API-Kosten, da du nicht mehr aktiv pollen musst. Besonders bei Fahrten erhältst du hochfrequente Daten mit minimaler Latenz. Für die meisten Nutzer funktioniert das bewährte Polling jedoch weiterhin problemlos und ist deutlich einfacher einzurichten.

Teslamate – Installieren oder einkaufen?

Teslamate ist keine Software-as-a-Service, sondern wird vom Nutzer selbst installiert. Ob im heimischen Homelab oder auf einem VPS-Server in der Cloud, z. B. beiNetcup (externer Link) – beides funktioniert. Ich hoste die Software auf meinem eigenen Server im Heimnetzwerk.

Die Installation ist mitDocker sehr einfach. Du benötigst eine Datenbank (PostgreSQL) und den Anwendungscontainer. Für die Visualisierung setzt Teslamate auf Grafana mit fertig konfigurierten Dashboards.

Voraussetzungen

Hardware & Software:

• Server mit mindestens 2 GB RAM (Raspberry Pi 4/5, NAS, VPS)
• Docker und Docker Compose installiert
• Dauerhaft aktive Internetverbindung

Tesla-Account:

• Tesla-Konto mit Zwei-Faktor-Authentifizierung
• Tesla Developer Account (kostenlos beideveloper.tesla.com (externer Link) )

Tesla Developer Account einrichten

Seit der Umstellung auf die Fleet API brauchst du einen Developer Account:

1. Melde dich beideveloper.tesla.com (externer Link) mit deinem Tesla-Konto an
2. Erstelle eine neue Application (z.B. “Teslamate Homelab”)
3. Gib eine kurze Beschreibung an
4. Bei lokaler Nutzung kannst du localhost als Domain verwenden

Die Prüfung dauert ein paar Tage, für private Zwecke erfolgt die Freigabe normalerweise problemlos. Das monatliche $10-Guthaben ist ein echtes Guthaben – du musst keine Kreditkarte hinterlegen, solange du darunter bleibst.

Token-Erstellung

Früher funktionierte die Anmeldung mit Benutzerdaten. Heute benötigst du einen „Refresh Token" und „Access Token". Diese generierst du am einfachsten mit Apps:

• iOS: “Auth for Tesla” (Apple AppStore)
• Android: “Tesla Tokens” oder “Auth for Tesla”
• Windows/Mac: “Tesla Auth” oder Web-basierte Tools

Vorgehensweise:

1. App installieren und mit Tesla-Benutzernamen anmelden
2. Passwort eingeben
3. Beim zweiten Prompt deinen 2FA-Code eingeben (nicht nochmal das Passwort!)
4. App zeigt Refresh Token und Access Token – beide sicher aufbewahren

Die Tokens bleiben mehrere Monate gültig. Teslamate erneuert den Access Token automatisch.

Installation mit Docker Compose

Die einfachste Installation erfolgt über Docker Compose. Falls du Docker Compose noch nicht installiert hast:

# Auf Ubuntu/Debiansudo apt install docker-compose-plugindocker compose version

Erstelle ein Arbeitsverzeichnis:

mkdir ~/teslamate&& cd ~/teslamate

Ich verweise auf dieoffizielle Dokumentation (externer Link) , da sich die Konfiguration regelmäßig ändert.

Wichtige Anpassungen für 2025:

version:"3"services:teslamate:image:teslamate/teslamate:latestrestart:alwaysenvironment:-ENCRYPTION_KEY=dein_sicherer_schluessel-DATABASE_USER=teslamate-DATABASE_PASS=sicheres_passwort-DATABASE_NAME=teslamate-DATABASE_HOST=database-TZ=Europe/Berlin# Deine Zeitzone!-MQTT_DISABLE=true# Falls kein MQTT benötigtports:-4000:4000cap_drop:-alldatabase:image:postgres:17# Mindestens 16.7 oder 17.3!restart:alwaysenvironment:-POSTGRES_USER=teslamate-POSTGRES_PASSWORD=sicheres_passwort-POSTGRES_DB=teslamatevolumes:-teslamate-db:/var/lib/postgresql/datagrafana:image:teslamate/grafana:latestrestart:alwaysenvironment:-DATABASE_USER=teslamate-DATABASE_PASS=sicheres_passwort-DATABASE_NAME=teslamate-DATABASE_HOST=databaseports:-3000:3000volumes:-teslamate-grafana-data:/var/lib/grafanavolumes:teslamate-db:teslamate-grafana-data:

MQTT für Home Assistant:

Wenn du die Daten an einen MQTT-Server weiterleiten willst (z. B. fürHome-Assistant ), ersetzeMQTT_DISABLE=true durchMQTT_HOST=mosquitto und füge einen Mosquitto-Container hinzu.

Container starten:

docker compose up -d

Teslamate ist anschließend unterhttp://{IP-deines-Servers}:4000 erreichbar. Beim ersten Aufruf gibst du die zuvor generierten Tokens ein. Nach 1-2 Minuten (ggf. Fahrzeug mit der App aufwecken) sollten erste Daten angezeigt werden.

Auswertung mit Grafana

Ein großer Vorteil der vordefinierten Docker-Compose-Datei: Grafana ist direkt mit dabei. Grafana läuft standardmäßig unterhttp://{IP-deines-Servers}:3000.

Standard-Login (sofort ändern!):

• Benutzername:admin
• Passwort:admin

Grafana hat die PostgreSQL-Datenbank als Datenquelle bereits konfiguriert und alle Dashboards sind importiert. Bei Nutzung einer eigenen Grafana-Instanz musst du die JSON-Dateien aus demGitHub (externer Link) Repository manuell importieren.

Wichtige Dashboards:

• Overview: Gesamtübersicht aller Kennzahlen – der perfekte Einstieg
• Drives: Fahrtenauswertung mit interaktiven Karten, zeigt Route, Geschwindigkeit und Verbrauch
• Charges: Detaillierte Ladehistorie mit Kostenanalyse pro Ladevorgang, Vergleich verschiedener Ladestationen
• Battery Health: Langzeitentwicklung der Batteriekapazität, zeigt Degradation über Zeit und Kilometer
• Efficiency: Verbrauchsanalysen nach Geschwindigkeit, Temperatur, Höhenmetern – erkenne was deine Reichweite beeinflusst
• Vampire Drain: Standby-Verbrauch im geparkten Zustand, hilft Phantom Drain zu identifizieren
• Locations: Häufige Aufenthaltsorte, automatische Geofencing-Erkennung
• Updates: Historie aller Software-Updates mit Zeitstempeln

Langzeitnutzung und Erkenntnisse

Der wahre Wert zeigt sich nach mehreren Monaten. Hier konkrete Beispiele aus meiner Nutzung:

Batteriedegradation: Mein Model Y zeigte nach 50.000 km etwa 4% Kapazitätsverlust. Typisch sind 3-5% in den ersten 50.000 km, danach verlangsamt sich die Degradation deutlich. Mit Teslamate siehst du die exakte Entwicklung und kannst Ausreißer (z.B. durch BMS-Kalibrierung) erkennen.

Saisonale Unterschiede: Im Winter (Temperaturen um 0°C) liegt mein Verbrauch bei ca. 20-22 kWh/100km, im Sommer bei 15-17 kWh/100km. Das sind rund 30% Mehrverbrauch durch Heizung und kalte Batterie. Diese Daten helfen bei der Routenplanung.

Kostenoptimierung: Heimladen (0,30 €/kWh) vs. Supercharger (0,52 €/kWh) – der Unterschied summiert sich. Bei 15.000 km jährlich spare ich durch Heimladen etwa 400 € pro Jahr. Noch besser:PV-Überschussladen reduziert die Kosten auf ca. 0,08 €/kWh.

Effizienz: Überraschend war, dass mein optimaler Geschwindigkeitsbereich bei 90-110 km/h liegt, nicht wie erwartet bei 70 km/h. Unter 70 km/h steigt der relative Verbrauch durch Hilfsaggregate wieder leicht an.

Troubleshooting

Teslamate zeigt “offline” statt “asleep”: Das ist seit Tesla-Firmware 2024.8+ normal. Tesla hat die API-Rückmeldung geändert – kein Teslamate-Bug.

Token wird nicht akzeptiert: Verwende den Refresh Token (der längere der beiden Strings), nicht den Access Token.

Keine Daten: Prüfe die Docker-Logs mitdocker compose logs teslamate. Häufige Ursachen: Fahrzeug im Tiefschlaf, falsche Zeitzone, Netzwerkprobleme.

Hohe API-Kosten: Reduziere die Polling-Frequenz, nutze Fleet Telemetry oder prüfe auf unnötige Wake-Befehle.

Sicherheit und Backup

Netzwerk:

• Nicht direkt ins Internet exponieren
• Reverse Proxy mit HTTPS nutzen (Nginx, Caddy, Traefik)
• Firewall-Regeln aktivieren

Backup:

docker compose exec database pg_dump -U teslamate teslamate > backup.sql

Updates:

docker compose pulldocker compose up -d

Häufige Fragen

Kostet Teslamate Geld? Die Software ist kostenlos. Tesla API-Kosten fallen an, werden aber meist vom $10-Freikontingent abgedeckt. Nur bei intensiver Nutzung entstehen ca. $2-5/Monat zusätzlich.

Funktioniert es mit der neuen Fleet API? Ja, vollständig kompatibel und aktuell gehalten.

Entlädt es die Batterie? Nein, der Zusatzverbrauch ist vernachlässigbar.

Mehrere Fahrzeuge möglich? Ja, jedes wird separat erfasst.

Fazit

Teslamate ist für mich die beste Lösung für umfassende Fahrzeugdatenanalyse. Die Vorteile:

• Volle Datenkontrolle durch Self-Hosting
• Detaillierte Analysen mit Grafana
• Geringe Kosten dank Freikontingent
• Aktive Community
• Perfekt für Home-Assistant-Integration

Die Nachteile: Technisches Know-how erforderlich, eigener Server nötig, kein offizieller Support.

Für Tesla-Besitzer mit Smart-Home- oder Homelab-Affinität ist Teslamate eine hervorragende Software. Nach einigen Monaten Nutzung werden die Auswertungen besonders interessant, da sich Tendenzen und Langzeitentwicklungen zeigen. Selbst während der Fahrt liefern die Grafana-Dashboards diverse interessante Daten.

Tipps für Fortgeschrittene

Reverse Proxy Setup: Für sicheren Zugriff von unterwegs empfehle ich einen Reverse Proxy mit Let’s Encrypt SSL-Zertifikat. Traefik oder Caddy automatisieren den Prozess komplett.

Datenbank-Optimierung: Bei sehr alten Installationen kann ein manuelles Vacuum der Datenbank helfen:

docker compose exec database vacuumdb -U teslamate -d teslamate -z -v

Custom Dashboards: Grafana bietet unendliche Möglichkeiten. Du kannst beispielsweise Vergleiche mit anderen Tesla-Fahrern erstellen oder Korrelationen zwischen Wetter und Verbrauch visualisieren.

Weiterführende Links:

• Teslamate Dokumentation (externer Link)
• GitHub Repository (externer Link)
• Community Forum (externer Link)

Es gibt viele Mediaplayer die zum Streaming von Filmen, Serien und Musik geeignet ist. DerPlex Media Server (externer Link) ist sicherlich hier der Platzhirsch, aber es gibt Alternativen. Ich möchte dir aus meiner persönlichen Sicht Plex vs.Jellyfin (externer Link) vergleichen. Natürlich muss dann jeder selbst entscheiden welches von beiden Programmen er nutzen möchte.

Warum der Vergleich?

Sicherlich wäre es für dich interessant zu wissen warum ich überhaupt diesen Vergleich Plex vs Jellyfin anstelle und warum ich nicht auch noch Emby oder Kodi mit in den Vergleich nehme. Diese Frage kann ich dir sehr einfach beantworten:
Ich nutze nurPlex und Jellyfin als Mediaplayer. Zugegeben habe ichKodi (externer Link) , damals noch als XMBC viel verwendet. Ich sehe hier aber einfach Vorteile.

Warum nicht Kodi?

Was hat im Plex vs Jellyfin Kodi in diesem Beitrag zu tun?
Kodi ist im Vergleich zu Plex, Jellyfin oder Emby anders aufgestellt. Kodi wird als direkter Mediaplayer am Endgerät eingesetzt, heißt hier müssen die Medien direkt liegen bzw. übers Netzwerk direkt erreichbar sein. Die anderen Tools sind in einer Server-Client-Infrastruktur zuhause. Dies bringt natürlich Vor- und Nachteile mit sich.

Vorteile von Plex und Jellyfin gegenüber Kodi

Diese Punkte sehe ich persönlich als Vorteil. Für jemand anderen können sie durchaus ein Nachteil sein. Es ist immer die jeweilige Situation und/oder Einsatzzweck zu bewerten.

Die Server-Client-Infrastruktur hat für mich den Vorteil, dass ich die benötigten Ressourcen auf den Server auslagern kann. Mögliches Transcoding wird auf der potenteren Maschine durchgeführt. Dadurch kann der Client sogar ein einfachererRaspberry Pi (externer Link) sein.

Ein weiterer Vorteil ist, dass ich auf meine Medien von unterwegs zugreifen kann. Am besten natürlich immer nur via VPN geschützt.

Nachteile von Plex/Jellyfin/Emby gegenüber Kodi

Man kann die Vorteile quasi umkehren um direkt zu den Nachteilen zu kommen. Heißt ich brauche hier nicht zwei Geräte betreiben. Wenn die Medien auf dem gleichen System liegen wie der Abspieler kann natürlich reichlich Energie gespart werden. Gegebenenfalls muss hier auch kein potentes System angeschafft werden.

Plex vs Jellyfin

Kommen wir zum eigentlichen Vergleich und dem Kern dieses Beitrages. Ich habe viele Jahre den Plex Media Server verwendet um Medien von meinem Server auf Abspielgeräte am TV oder auf dem Mobiltelefon zu streamen. Natürlich hatte ich die ganze Zeit auch einen Server der schon 24/7 lief und somit kein zusätzlichen Ressourcen benötigt wurden.

Über die Zeit hinweg habe ich stets die kostenfreie Version von PMS verwendet. Für den normalen Nutzer reicht diese auch voll und ganz. Dann kam später das Hardware Transcoding dazu und ich wollte diese Funktion unbedingt nutzen. Also musste ich zum Plex Pass greifen. Der kostete damals nur ein paar Euro und war daher schnell gekauft. Die letzten Jahre habe ich mittels jährlichem Beitrag weiterhin bezahlt obwohl sich sicherlich bei einem Black Friday Deal die Plex-Lifetime Mitgliedschaft gelohnt hätte.

Mit dem Plex Pass kannst du mittlerweile mehr machen als nur Hardware Transcoding (geht nämlich jetzt auch in der kostenfreien Version). Die meisten werden die Funktion wohl kaufen um seine Mediathek mit Freunden und Familie zu teilen. Zudem bietet es Funktionen wie die Offline Verfügbarkeit von Medien an. Beides habe ich aber nie wirklich genutzt.

Vor einigen Monaten wollte ich mir einfach mal Jellyfin angucken. Ich habe über Podcasts,YouTube (externer Link) Videos und reddit schon viel über die Software gehört, aber noch nie ausprobiert. Jellyfin ist als fork von Emby entstanden, weil viele Menschen die Entwicklung von Emby nicht mehr gut fanden und es besser machen wollten.

Im Vergleich Plex vs Jellyfin hat letzteres den Vorteil, dass es grundsätzlich kostenfrei ist und auch keine bezahloption gibt. Das birgt natürlich den gewissen Nachteil das die Entwicklung nicht immer so schnell vorwärts gehen kann, als wenn ein Vollzeitentwickler an dem Projekt arbeitet.

Was störte mich am Plex Media Server?

Warum habe ich also das Produkt gewechselt? Viel hatte damals mit meinem Kubernetes Cluster zu tun. Plex lief darauf gut und ich konnte sehr einfach mal Jellyfin parallel installieren und es mir angucken. Die Benutzeroberfläche ist zwar durchaus anders, lässt sich aber pro Benutzer zumindest etwas konfigurieren. Hier hat man bei Plex nicht so viele Möglichkeiten.

Als Plex mal wieder ein Problem mit deren Server hat und man sich daher nicht mehr am System anmelden kann, war ich gezwungen meine Medien via Jellyfin zu konsumieren. Man muss nämlich wissen, dass Plex quasi einen Onlinezwang hat. Die Medien werden zwar völlig offline gestreamt, aber die Anmeldung des Clients am Server erfolgt immer via Cloud. Nervig, wenn die Infrastruktur nicht immer gut funktioniert.

Jellyfin bietet mir noch den Vorteil meine „watch history“ sauber aufTrakt.tv (externer Link) (Link zu meinem Profil (externer Link) ) zu verfolgen. Es gibt zwar auch ein paar Möglichkeiten das via Plex zu machen, diese werden aber häufig nicht sauber gepflegt oder bedürfen eines kostenpflichtigen Trakt.tv Accounts.

Des Weiteren gefällt mir die Wiedergabelisten bei Jellyfin auch besser. Ich habe mir zum Beispiel Listen fürsMarvel Cinematic Universe (externer Link) angelegt um die Filme nochmal der Reihenfolge nach zu gucken. Die Collections bei Plex packen zwar die Filme zusammen, sortieren diese aber nicht nach der korrekten Reihenfolge.

Was stört mich an Jellyfin

Im Vergleich Plex vs Jellyfin hat der PMS den charmanten Vorteil über mehr unterstützte Clients zu verfügen. Quasi für jedes Betriebssystem gibts einen nativen Client. Für mich im Apple Universum war das natürlich kein Problem.

Jellyfin hingegen hat zur Zeit noch kein AppleTV Client. Hier muss man auf Infuse Pro zurückgreifen. Jetzt habe ich also doch kosten. Zwar wesentlich günstiger als bei Plex, aber ganz kostenfrei kam ich nicht hin.

Die AndroidTV App ist auch eher schlecht als recht (gewesen). Die alte Version hatte viele Fehler. Mit der aktuellen wurde da ganz viel dran gearbeitet und nun läuft sie auch sehr stabil und performant.

Fazit

Ich fühle mich bei Jellyfin rundum mehr zuhause als das ich das bei Plex hatte. Natürlich vermisse ich noch eine native App fürs AppleTV, kann mich aber mit der AndroidTV am Fernseher begnügen. Am iPhone oder am iPad schaue ich via Infuse Pro, weil ich die Lizenz ja schon habe.

Das Duell Plex vs Jellyfin gewinnt für mich, wie sollte es auch anders sein, Jellyfin. Wenn du die Software mal ausprobieren möchtest, kannst du ja gern mal ein Blick in meineDocker Compose Sammlung (externer Link) werfen, dort findest du vorgefertigte Dateien um einfach mal zu starten.

In der heutigen Welt, in der Containerisierung und die Nutzung von Docker für viele Entwickler und IT-Experten zum Alltag gehören, ist es entscheidend, effiziente und benutzerfreundliche Tools zu haben, um diese komplexen Systeme zu verwalten. Hier kommtPortainer ins Spiel – ein leistungsstarkes und intuitives Verwaltungstool, das die Arbeit mit Docker-Containern und -Stacks erheblich vereinfacht. Portainer bietet eine grafische Benutzeroberfläche (GUI), mit der sowohl Anfänger als auch erfahrene Entwickler ihre Container, Images, Netzwerke und Volumes verwalten können, ohne tief in die Kommandozeile eintauchen zu müssen.

In diesemPortainer-Tutorial führen wir dich Schritt für Schritt durch die Installation, Einrichtung und die wichtigsten Funktionen des Tools. Egal, ob du gerade erst in die Welt der Containerisierung einsteigst oder bereits Erfahrung mit Docker hast – dieses Tutorial hilft dir, Portainer effektiv zu nutzen, um deine Container-Infrastruktur effizienter und übersichtlicher zu gestalten. Am Ende wirst du in der Lage sein, deine Docker-Umgebung problemlos zu überwachen, zu konfigurieren und zu steuern. Mach dich bereit, deine Docker-Workflows auf das nächste Level zu heben!

Voraussetzungen

Voraussetzungen für diesesPortainer (externer Link) Tutorial gibt es eigentlich fast keine. Wir beschränken uns in diesem Beitrag allerdings auf die Verwaltung von Docker. Entsprechend solltest du ein Linux-Server mit installiertem Docker vorbereitet haben. Alles weitere werden wir zusammen erarbeiten.

Installation von Portainer

Eine wirkliche Installation findet ja nicht statt. Wir starten Portainer als Docker Container und müssen uns eigentlich nur gegen diesen verbinden. Du findest eine vorgefertigte docker-compose.yaml-Datei inmeiner Compose-Sammlung (externer Link) . Die für die Docker GUI sieht zum Beispiel so aus.

---version:'3.3'services:portainer:image:portainer/portainer-ce:2.11.1container_name:portainerrestart:unless-stoppedvolumes:-/etc/localtime:/etc/localtime:ro-/etc/timezone:/etc/timezone:ro-/var/run/docker.sock:/var/run/docker.sock-/var/docker/portainer:/dataports:-9000:9000

Den Datenspeicherort der Portainer-Konfiguration kannst du dir natürlich nach Belieben anpassen (4. Zeile bei den Volumes). Anschließend können wir den Container auch schon starten.

docker compose up

Nach ein paar Sekunden sollte die Anwendung dann vollständig gestartet sein.

portainer | INFO 2022/03/22 18:18:21 Encryption key file `portainer` not present
portainer | INFO 2022/03/22 18:18:21 Proceeding without encryption key
portainer | INFO 2022/03/22 18:18:21 Loading PortainerDB: portainer.db
portainer | level=info msg="2022/03/22 18:18:21 [INFO] [internal,ssl] [message: no cert files found, generating self signed ssl certificates]"
portainer | 2022/03/22 18:18:22 server: Reverse tunnelling enabled
portainer | 2022/03/22 18:18:22 server: Fingerprint 8f:41:d0:fc:b7:fe:45:23:9d:f1:31:5d:70:f8:38:76
portainer | 2022/03/22 18:18:22 server: Listening on 0.0.0.0:8000...
portainer | INFO 2022/03/22 18:18:22 [INFO] [cmd,main] Starting Portainer version 2.11.1
portainer |
portainer | level=info msg="2022/03/22 18:18:22 [INFO] [http,server] [message: starting HTTPS server on port :9443]"
portainer | level=info msg="2022/03/22 18:18:22 [DEBUG] [chisel, monitoring] [check_interval_seconds: 10.000000] [message: starting tunnel management process]"
portainer | level=info msg="2022/03/22 18:18:22 [DEBUG] [internal,init] [message: start initialization monitor ]"
portainer | level=info msg="2022/03/22 18:18:22 [INFO] [http,server] [message: starting HTTP server on port :9000]"

Ab jetzt können wir mit der Einrichtung beginnen.

Einrichtung von Portainer

Hierzu öffnen wir einen neuen Tab im Browser (oder gern auch ein neues Fenster) und geben die IP-Adresse des Docker-Servers gefolgt vom Port ein. Uns sollte so etwas begrüßen.

Wenn du möchtest, kannst du den Administrator-Account gerne einen anderen Nutzernamen geben. Andernfalls lass einfach das „admin“ in der ersten Zeile stehen. Anschließend tippst du bitte zwei Mal ein selbst gewähltes Passwort ein. Nun noch unten auf „Create user“ klicken und schon erscheint der nächste Bildschirm.

Solltest du mehrere DockerServer damit verwalten wollen, wäre „Add Environment“ das Richtige. Allerdings wollen wir in diesem Portainer Tutorial lediglich den lokalen Docker Server verwalten. Wir klicken also auf „Get Started“ und landen direkt beim nächsten Fenster.

Es werden hier eine Liste der möglichen Docker-Umgebungen dargestellt. Da wir natürlich nur auf die Lokale Zugriff haben, können wir nur „local“ auswählen. Genau dieses wollen wir natürlich auch.

Anschließend ist die Einrichtung auch schon abgeschlossen.

Anwendungen hinzufügen

Docker Container bzw. die Anwendungen werden als Stack in Portainer verwaltet. Entsprechend ist die Benennung hier ein wenig anders als du das vielleicht gewohnt bist. In diesem Portainer Tutorial gehe ich auf zwei Methoden ein eine neue Anwendung hinzuzufügen, nämlich per copy & paste der docker-compose.yaml-Datei und per Import vonGitHub (externer Link) .

Per Copy & Paste

Diese Methode ist wohl die einfachste. Du kannst bestehende docker-compose.yaml-Dateien fast immer einfach hier rein kopieren. Allerdings ist aufzupassen, dass keine Variablen verwendet werden. Diese können in der Methodik nämlich nicht ausgefüllt werden. Gegebenenfalls ersetzt du einfach die Variablen durch die eigentlichen Werte, dann funktioniert das auch.

Als erstes vergeben wir einen Namen. Dieser Name ist eineindeutig für die jeweiligen Umgebungen. Zudem dürfen keine Umlaute oder Leerzeichen verwendet werden. Binde- oder Unterstriche, wie im Beispiel zu sehen, sind natürlich erlaubt.

Für dieses Beispiel deployen wir das Ghost CMS. Wir nehmen also einfach eine docker-compose.yaml-Datei (wie diese aus meiner Sammlung) und fügen den Inhalt einfach ein.

In unserem einfachen Beispiel müssen wir nichts weiter beachten und lassen alle anderen Felder und Möglichkeiten außer Acht. Wir müssen also nur noch auf „Deploy the stack“ klicken und Portainer zieht das Image aus der Registry und startet den Container.

So einfach war die Copy & Paste-Methode. Anschließend fügen wir jetzt noch eine compose-Datei ausGitHub (externer Link) hinzu.

Compose Datei aus GitHub

Diese Methode kann verwendet werden, wenn man keine Lust auf Copy & Paste hat. Allerdings hat sie nicht wirklich große Vorteile. Zumal der Stack dann auch nicht vollständig über Portainer verwaltet werden kann. Auf der anderen Seite wird der Stack über die originale Datei auf GitHub synchronisiert und entsprechend aktuell gehalten (wenn man das möchte).

Auch hier geben wir dem Stack einen Namen.

Natürlich kann hier jede Art von git-Repository verwendet werden. GitHub ist nur das prominenteste Beispiel der Cloud Anbieter für git-Repositories.

Als Repository-URL gibst du den Standardpfad bzw. URL des Repos ein. Das ist meist die Startseite. Die „Repository reference“ kannst du leer lassen, denn diese nimmt immer die Dateien aus dem Master Branch. Wenn du das nicht möchtest, weißt du sicherlich selbst, was du hier einzutragen hast.

Der „Compose path“ ist im Standard nur eine einfach „docker-compose.yml“-Angabe. Ich habe für dieses Beispiel eine Anwendung aus meiner Sammlung genommen und muss entsprechend den Pfad dorthin genau angeben.

Auch hier müssen wir anschließend nur auf „Deploy the Stack“ unten klicken und schon wird die compose-Datei aus dem Repo geklont und die Anwendung deployt.

Fazit

Portainer erweist sich als unverzichtbares Tool für jeden, der mit Docker arbeitet, egal ob Anfänger oder erfahrener Profi. Durch seine benutzerfreundliche grafische Oberfläche wird die Verwaltung von Containern, Images und Netzwerken erheblich vereinfacht, ohne dabei auf Flexibilität und Funktionsvielfalt zu verzichten. Besonders vorteilhaft ist, dass Portainer nicht nur für kleinere Umgebungen, sondern auch in größeren, produktiven Setups problemlos einsetzbar ist. Es hilft, komplexe Docker-Architekturen übersichtlich zu strukturieren und bietet umfassende Verwaltungs- und Überwachungsmöglichkeiten, die weit über das hinausgehen, was die Kommandozeile bietet.

In diesem Tutorial haben wir die Grundlagen von Portainer beleuchtet – von der Installation über die wichtigsten Funktionen bis hin zu praktischen Anwendungsszenarien. Damit solltest du nun bestens gerüstet sein, Portainer in deinem eigenen Docker-Setup erfolgreich einzusetzen und deine Workflows effizienter zu gestalten.

Abschließend lässt sich sagen, dass Portainer nicht nur Zeit und Mühe spart, sondern auch dazu beiträgt, die Container-Verwaltung sicherer und kontrollierter zu gestalten. Wer Docker nutzt, sollte Portainer als Ergänzung auf jeden Fall in Betracht ziehen, um das Beste aus seiner Container-Umgebung herauszuholen.

Ein DNS Werbeblocker gehört mittlerweile zur Standardausstattung eines jedenHomelabs . Für diese Werbeblocker werden natürlich auch DNS Blocklisten benötigt die gepflegt werden sollten. In diesem Beitrag möchte ich dir meine Listen darstellen und warum ich diese empfehle.

Natürlich kann man auch wesentlich mehr Listen pflegen als diese drei die ich in diesem Beitrag empfehle, allerdings verursachen mehr Listen auch mehr Last und dadurch kann die Performance deinesWerbeblockers beeinträchtigt werden.

Welche Software man zum Blocken von Werbung verwendet ist natürlich Geschmacksache. Da ich in meinem Kubernetes-Cluster GitOps betreibe und config-as-code bevorzuge (genug Bullshit Bingo vorerst) verwende ichblocky (externer Link) . Diese Listen funktionieren aber genau so gut inPiHole (externer Link) oderAdguard (externer Link) .

Werbung und Tracker

Um Werbung und Tracker zu blockieren reicht im Regelfall diese eine Liste. Ich habe bis jetzt noch keine Werbung festgestellt die durch einen Werbeblocker gefiltert werden könnte und hiermit durchkommt.

https://raw.githubusercontent.com/ookangzheng/dbl-oisd-nl/master/dbl.txt

TV Werbung und Tracking

Natürlich werden keine Werbung im regulären TV geblockt allerdings nutzen moderne TVs, sollten sie im Netzwerk hängen und Internetkommunikation haben, diverse Tracker um z. B. via Red Button Werbung einzublenden. Hierfür habe ich bei mir mehrere Listen hinterlegt, Grundsätzlich würde aber die erste Liste aussreichen

https://gist.githubusercontent.com/wassname/b594c63222f9e4c83ea23c818440901b/raw/1b0afd2aecf3a099f1681b1cf18fc0e6e2fa116a/Samsung%2520Smart-TV%2520Blocklist%2520Adlist%2520(for%2520PiHole)
https://gist.githubusercontent.com/wassname/78eeaaad299dc4cddd04e372f20a9aa7/raw/d7863a978993e99d9c77c9001008ce670a3b4c29/LG%2520Smart-TV%2520Blocklist%2520Adlist%2520(for%2520PiHole)
https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV.txt
https://gist.githubusercontent.com/hkamran80/779019103fcd306979411d44c8d38459/raw/e0f084b396bb8ffcb390c8e7272ae96a6c292d10/SmartTV2.txt

Fakenews

Gerade in heutiger Zeit werden immer mehr Fakenews verbreitet und es ist daher wichtiger sich davor zu schützen. Auch wenn man selbst vielleicht die notwendige Kompetenz hat das selbst zu erkennen sollte man seine Familie evtl. auch davor schützen. Als ich diese Liste gefunden habe, bin ich natürlich erst mal über die Liste drüber geflogen ob es sicher hier wirklich um Fakenews Seiten handelt. Aus meiner Sicht ja. Entsprechend habe ich diese DNS Blocklisten auch bei mir hinterlegt.

https://raw.githubusercontent.com/StevenBlack/hosts/master/alternates/fakenews/hosts

Whitelist

Diverse Seiten landen aus unterschiedlichen Gründen gern auf Blocklisten. Zumeist auf Grund von Telemetrie oder Tracking. Nichts desto trotz möchte man vlt. seine Lieblingsdienste gut und uneingeschränkt verwenden. Entsprechend habe ich zwei Liste in meiner blocky Konfiguration um diese verwenden zu können. Wem das zu viel ist, sollte lieber die Dienste einzeln pflegen.

https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt

Weiter Empfehlungen

Vor kurzem wurde mir auf Mastodon eine sehr interessante Liste in die Timeline gespült. Jemand macht sich die Arbeit und listet alle URLs des Axel Springer Verlages auf. Damit kann man sicher stellen, dass dem sehr umstrittenen Verleger nicht noch mehr Geld zugespielt wird. Die Liste ist natürlich auch für diverse andere Werbeblocker optimiert. Einfach mal imGitHub Repo (externer Link) angucken.

https://raw.githubusercontent.com/autinerd/anti-axelspringer-hosts/master/axelspringer-hosts

Mit diesem Traefik letsencrypt Tutorial möchte ich dir helfen einfach und sauber Zertifikate via freier CA Let’s Encrypt zu beantragen und zu verwalten. In diesem Tutorial gehe ich auf die Punkte http-challenge, dns-challenge sowie weiteres Zertifikatsmanagement ein. Sollte Dir ein Punkt fehlen, schreibe mir dazu gerne in Kommentare.

Solltest Du auf dieses Tutorial gestoßen sein, weil du Docker nutzt, kann ich dir meinedocker-compose Sammlung auf GitHub (externer Link) sehr ans Herz legen. Dort sind gerade für das ThemaHomelab sehr viele Softwareprodukte hinterlegt die eine direkteTraefik (externer Link) Anbindung realisieren. Sicherlich ist auch meine Traefik Konfiguration ein guter Startpunkt für ein gutes Gelingen.

Traefik Grundkonfiguration

Traefik lässt sich über mehrere Wege konfigurieren. Hierbei spielt es keine Rolle ob man sämtliche Befehle und Konfigurationen direkt in die docker-compose Datei oder in separate Dateien packt. Ich für meinen Teil verwende dedizierte um eine einfachere und übersichtliche Konfiguration zu haben. Solltest du einen anderen Weg bevorzugen ist dies für dieses Traefikletsencrypt (externer Link) Tutorial nicht wichtig. Du musst natürlich nur die Einstellungen adaptieren.

Das ist ist meine Docker Compose Beispielkonfiguration welche ich normalerweise einsetze. Je nach Umgebung kann diese aber natürlich ein wenig variieren. Ich gebe auch immer http3 mit aus, einfach weil ich es mag neue Standard direkt mit zu implentieren.

---services:traefik:image:traefik:v3container_name:traefikvolumes:-/etc/localtime:/etc/localtime:ro-/etc/timezone:/etc/timezone:ro-/var/run/docker.sock:/var/run/docker.sock-/var/log/auth.log:/var/log/auth.log:ro-/var/log/traefik:/var/log/traefik-./config:/etc/traefiknetworks:-traefik_proxy-defaultports:-target:80published:80protocol:tcpmode:host-target:443published:443protocol:tcpmode:host-target:443published:443protocol:udpmode:hostrestart:unless-stoppednetworks:traefik_proxy:external:truedefault:driver:bridge

Anschließend brauchen wir natürlich noch die zwei Dateien die wir oben als Volume angegeben haben. Starten wir mit dertraefik.yaml Diese beinhaltet alle notwenigen Eigenschaften umTraefik sauber ans laufen zu bekommen.

---log:level:"INFO"filePath:"/var/log/traefik/traefik.log"accessLog:filePath:"/var/log/traefik/access.log"bufferingSize:100providers:docker:endpoint:"unix:///var/run/docker.sock"exposedByDefault:falsenetwork:"traefik_proxy"file:filename:"/etc/traefik/dynamic.yml"watch:trueapi:dashboard:falseentryPoints:ping:address:':88'web:address:':80'http:redirections:entryPoint:to:websecurescheme:httpswebsecure:address:':443'http3:proxyProtocol:trustedIPs:-10.0.0.0/8-172.16.0.0/12-192.168.0.0/16forwardedHeaders:trustedIPs:-10.0.0.0/8-172.16.0.0/12-192.168.0.0/16certificatesResolvers:default:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"httpChallenge:entryPoint:webtls_resolver:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"tlsChallenge:{}

Gehen wir die Punkt einmal durch:

[log]

Das Loglevel sollte für den produktiven Betrieb so gewählt werden, dass nach Möglichkeit nicht die Festplatte voll läuft. Für den Beginn ist es evtl. ratsam hier aufDEBUG umzustellen um mehr zu sehen und um Fehler leichter erkennen zu können.

[providers]

Wir nutzen für diese Beispielkonfiguration Docker. Wir möchten allerdings nicht, dass grundsätzlich alleDocker Container via Traefik veröffentlicht werden (exposedByDefault = false) und setzen die jeweiligen Anpassungen für jeden Container dediziert. Traefik lassen wir auf den Docker Socket hören um zu wissen was Traefik so machen muss. Gegebenenfalls musst du den Parameter „network“ anpassen. Ich nutze hierfür immer „traefik_proxy“ als Netzwerk. Möchtest du das ebenfalls nutzen musst du

docker network create traefik_proxy

ausführen und das Netzwerk anzulegen.

[api]

Das Dashboard brauchen wir hierfür nicht, wird also deaktiviert

[entryPoints]

Die entryPoints sind die Ports und Protokolle auf die Traefik hört. Stand jetzt kann Traefik nur HTTP/HTTPS Traffic. Weitere Protokolle sollen in Zukunft kommen. Wir lauschen natürlich auch auf Port 80 (HTTP) und machen eine direkte Weiterleitung auf Port 443 (HTTPS). Unverschlüsselte Kommunikation sollte nur in Ausnahmefällen noch erlaubt sein.

Wie du siehst binden wir auch eine dynamic.yml Datei ein. Diese hat folgenden Aufbau

---tls:options:default:minVersion:VersionTLS12cipherSuites:-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256-TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384-TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305-TLS_AES_128_GCM_SHA256-TLS_AES_256_GCM_SHA384-TLS_CHACHA20_POLY1305_SHA256curvePreferences:-CurveP521-CurveP384sniStrict:truehttp:middlewares:default:chain:middlewares:-default-security-headers-gzipdefault-security-headers:headers:browserXssFilter:truecontentTypeNosniff:trueforceSTSHeader:trueframeDeny:truestsIncludeSubdomains:truestsPreload:truestsSeconds:31536000customFrameOptionsValue:"SAMEORIGIN"gzip:compress:{}

Die dynamic.yml ist zur Konfiguration aller Sicherheitsmerkmale gedacht. Bitte passe diese nach den aktuellen Gegebenheiten an, da sich gerade die Cipher Suites häufig ändern können! Die restlichen Werte sind nach langjähriger Erfahrung von mir so zusammen getragen und müssen nicht dem aktuellen Sicherheitsstandards entsprechend. Für Tipps bin ich aber dankbar und passe die Datei dann gerne an.

Traefik letsencrypt tlsChallenge

Mit der tlsChallange ist es wahrscheinlich die einfachste Variante Zertifikate via Let’s encrypt zu beantragen. Hier kann Traefik direkt so konfiguriert, bzw. über die Docker Konfiguration so eingerichtet werden, dass nur Port 443, also HTTPS, veröffentlicht werden muss. Möchte man nur ein paar wenige Zertifikate beantragen ist das meiner Meinung die empfehlenswerte Version.

Die Konfiguration der tlsChallenge ist ziemlich einfach. Man fügt in der traefik.toml Datei folgende Zeilen am Ende ein:

certificatesResolvers:default:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"

Email-Adresse ist für die Benachrichtigung von Let’s encrypt an dich gedacht. Entsprechend empfehle ich hier eine valide Email-Adresse anzugeben. Die Storage Angabe ist der Speicherort der Zertifikate. Entsprechend muss in der Docker Konfiguration auch das beachtet werden.

Traefik letsencrypt httpChallenge

Die httpChallenge ist quasi das gleich wie die tlsChallenge, allerdings via Port 80 anstatt 443. Hier muss als in der Docker Konfiguration auch Port 80 veröffentlicht werden. So ergibt sich daraus folgender Inhalt für die traefik.toml:

certificatesResolvers:default:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"httpChallenge:entryPoint:web

Traefik letsencrypt dnsChallenge (am Beispiel Cloudflare)

Die dnsChallenge ist quasi die Königsdisziplin. Allerdings nur wirklich dann sinnvoll wenn man z. B. Wildcard Zertifikate benötig oder wenn man viele Subdomainzertifikate benötigt. Entsprechend muss man hier auch ein wenig mehr konfigurieren und vor allen Dingen benötigt man einen DNS Provider der von Let’s encrypt unterstützt wird. Ich empfehle hier Cloudflare.

certificatesResolvers:default:acme:email:"mail@teqqy.de"storage:"/etc/traefik/ACME/acme.json"dnsChallenge:provider:"cloudflare"resolvers:-"1.1.1.1:53"-"1.0.0.1:53"

Hinzu kommt, dass wir in derdocker-compose.yaml noch den API Token für die Cloudflare API hinzufügen. Dazu einfach noch folgende Zeilen einfügen:

environment:CF_DNS_API_TOKEN:"{STRENGGEHEIMERAPIKEY}"

Zertifikate löschen

Zertifikate werden in deracme.json Datei gespeichert und könnten dort heraus gelöscht werden. Zu jedem Zertifikat gibt es einecertificate undkey Definition. Man kann also die Datei entsprechend editieren und die Zeichenketten entsprechend heraus löschen.

 {"domain": {"main":"teqqy.de","sans": ["www.teqqy.de" ] },"certificate":"<Zeichenkette>","key":"<Zeichenkette>","Store":"default" },

Notwendig ist dies aber nur dann, wenn bei der Erstellung ein Fehler aufgetreten ist oder Let’s Encrypt Zertifikate wg. Fehlern zurückruft. Andernfalls laufen die Zertifikate automatisch nach 90 Tagen ab. Ein manuelles Aufräumen ist nicht notwendig.

Inspiriert durchr/selfhosted (externer Link) dachte ich mir, dass ich auch mal mein Homelab Dashboard vorstellen möchte. Der Sinn und Zweck eines solchen Homelab „Dashboards“ ist es möglichst viele Dinge als quasi Lesezeichen parat zu haben. Verschiedene andere Softwareprodukte können z. B. auch noch Livezahlen darstellen.

Ich nutze bei mir Hajimari. Das ist eine Software welche für den Einsatzzweck in Kubernetes-Umgebungen gedacht ist.Hajimari (externer Link) hat den Vorteil, dass es Ingress Defintionen auslesen kann und man somit weniger Einstellungen manuell machen muss.

Auf meinemYouTube Kanal (externer Link) habe ich vor längerer Zeit schon malHeimdall (externer Link) undOrganizer (externer Link) vorgestellt. Du kannst dir diese zwei Videos ja gern einmal ansehen.

Aufteilung

Grundsätzlich ist das Dashboard in zwei Bereich aufgeteilt. Der obere welcher meine ganzen Homelab Dienste und Systeme darstellt und der untere Teil der verschiedene Lesezeichen immer parat hält.

Während die oberen quasi automatisch dargestellt werden, müssen die Bookmarks unten komplett manuell in die Konfiguration übertragen werden.

Meine ganze Kubernetes Konfiguration findest du übrigens aufGithub (externer Link) .

Was sind das für Dienste?

Ich gehe einmal von links oben nach rechts unten die Liste durch. Ich verlinke jedes Produkt sodass du dich selbst genauer über die einzelnen Softwareprodukte informieren kannst.

Paperless

Paperless ist mein Dokumenten Management System. Hier werden alle aufzuhebenen Dokumente eingescannt oder per Email weiter geleitet und verarbeitet. Anfangs recht viel Aufwand bis man viele Korrespondenten hinterlegt hat, aber jetzt habe ich mich an den Workflow gewöhnt.

Link:https://github.com/jonaswinkler/paperless-ng (externer Link)

Teslamate

Teslamate ist eine Software um mittels Tesla API die Werte des Fahrzeuges auszulesen und in eine Datenbank zu speichern. Hiermit lassen sich hervorragend Langzeitstatistiken erstellen.

Eine Alternative wäreTronity (externer Link) , welche auch für viel anderen Hersteller von Elektroautos verfügbar ist.

Link:https://github.com/adriankumpf/teslamate (externer Link)

Home Assistant & Home Assistant Codeserver

Home Assistant sollte den meisten wohl bekannt sein: Eine Software zur Steuerung von Smart-Home Geräten. Home Assistant konzentriert sich darauf komplett offline funktionieren zu können und den Datenschutz als eine der wichtigsten Komponenten zu nehmen. Theoretisch könnte man auch Home Assistant als Homelab Dashboard nehmen, da sich hier auch viele Services integrieren lassen.
Der Code Server ist dazu Visual Studio Code im Browser um meine Konfiguration editieren zu können.

Link Home Assistant:https://www.home-assistant.io (externer Link)
Link Code Server:https://github.com/coder/code-server (externer Link)

Node-Red

Mittels Node-Red lassen sich Abläufe für Automatisierungen erstellen. Eine gute Ergänzung zu Home Assistant. Ich nutze es aber nur dafür um von einem Wechselrichter unser PV-Anlage die Daten via XML auszulesen und per MQTT weiter zu leiten.

Link:https://nodered.org (externer Link)

ZwaveJS2MQTT

Noch besitze ich einige ZWave Geräte. Diese werden mittels einem Aeotec Z-Wave Stick als Bridge ausgelesen und via dieser Software per MQTT übertragen. Home-Assistant kümmert sich dann um den Rest.

Link:https://github.com/zwave-js/zwavejs2mqtt (externer Link)

Jellyfin

Jellyfin ist ein Fork von Emby. Dieser wurde, wenn ich das recht in Erinnerung habe, erstellt weil Emby einen sehr merkwürdigen Weg der Datenverwaltung und Monetarisierung hatte. Mittlerweile erfreut sich Jellyfin immer größerer Beliebtheit und ist definitiv eine Alternative zu Plex.

Link:https://jellyfin.org (externer Link)

Lidarr / Radarr / Sonarr / Sabnzbd

Auf diese Produkte gehe ich nicht genauer ein. Wer sie googelt wird schon finden wofür sie sind. 😉

Navidrome

Diese Software stellt mir meinen Musikserver bereit und mittels Subsonic Protokoll sind damit auch verschiedene Clients Kompatibel. Ich habe ein paar andere Musikserver ausprobiert und bin jetzt bei Navidrome hängen geblieben. Ehrlich gesagt, ohne besonderen Grund. Läuft einfach.

Link:https://www.navidrome.org (externer Link)

Plex

Neben Kodi (wollte schon gerade xmbc schreiben 🙄) wohl der bekannteste Medienserver. Diesen nutze ich zum Teilen von Mediatheken. Jellyfin wird rein für mich verwendet. In einem älteren Beitrag habe ich auch beschrieben wie man einenlow-end Plex Server aufsetzen kann.

Link:https://www.plex.tv/de/ (externer Link)

Grafana

Die Mutter aller Visualisierungstools. Mit Grafana lässt sich so jede Datenquelle anzapfen und visualisieren. Entsprechend stellt sie mir diverse Informationen aus dem Prometheus Monitoring des Kubernetes Clusters bereit. Aber auch Teslamate visualisiert hiermit die gewonnenen Daten.

Link:https://grafana.com (externer Link)

Authentik

Authentik ist ein Single-Sign-On-Provider. Verschiedene Produkte lassen sich hieran anbinden um nicht immer einzelne Zugangsdaten pflegen zu müssen. Authentik hat auch die Möglichkeit verschiedene Quellen an Nutzerinformationen anzubinden (z. B. GitHub, Microsoft AAD, LDAP, etc)
Es ist sehr angenehm sich nur noch mit einem paar Zugangsdaten anmelden zu können. Auch Authentik bietet die Möglichkeit Links in einer Art Startseite zu sammeln. So fungiert Authentik auch fast als kleines Homelab Dashboard.

Link:https://goauthentik.io (externer Link)

Unifi

Die Controllersoftware meinerUbiquiti (externer Link) Unifi Geräte. Ohne diese lassen sich die ganzen Komponenten nicht konfigurieren.

Link:https://ui.com (externer Link)

Rook-Ceph

Mein Kubernetes Cluster braucht natürlich auch ein Speicher. Da ich mehrere Hosts verwende muss dieser Speicher natürlich allen Systemen bekannt sein. Ich setzte hierfürCeph (externer Link) als verteiltes Dateisystem ein. Rook-Ceph ist dabei die Implementation für Kubernetes um Ceph als Cluster Storage Interface (CSI) verwenden zu können.

Link:https://rook.io (externer Link)

UnRaid

Natürlich braucht ein Homelab auch ein NAS. Da dieses bei mir wirklich nur „kalte Daten“ speichern muss, habe ich mich für UnRaid entschieden. Zwar kostet die Software ein paar Dollar, allerdings lassen sich wie beimSynology (externer Link) SHR verschieden große Festplatten miteinander kombinieren. Bei dem Wust an 2, 3 und 4 TB HDDs sehr angenehm. Wird nur langsam mal Zeit neue Disks zu kaufen.

Link:https://unraid.net/de (externer Link)

opnSense

Vor ein paar Monaten habe ich meine Unifi USG verkauft. Nicht das sie schlecht war, aber für meinen Kubernetes Cluster wollte ich aufBGP (externer Link) setzen. Das wird so nicht offiziell unterstützt und auf einen nervigen weg über eingepflanzte json-Dateien habe ich keine Lust. OpnSense „gefällt“ mir besser als pfSense. Eine Featureentscheidung hat es hier nicht gegeben.

Link:https://opnsense.org (externer Link)

vzlogger

Eine sehr große Hassliebe! vzlogger ist ein Teil des Volkszähller-Projektes. Damit lassen sich Smart-Meter auslesen. Leider haben wir in Deutschland ja immer noch ein Problem mit dem Datenschutz, sodass seit Jahren diese Dinger verbaut werden, aber ohne zusätzlich Strom zu fressen sind sie zu nix zu gebrauchen.

Link:https://volkszaehler.org (externer Link)

Zigbee2MQTT

Ähnlich zu zwavejs2mqtt bietet mit zigbee2mqtt die Möglichkeit Zigbee-Geräte per MQTT mit Home Assistant verbinden zu können. Ich nutze hierfür dasRaspberry Pi (externer Link) Modul RaspBee II und verzichte somit auf sämtliche Herstellerbridges die mir Zigbee bereit stellen wrüden.

Link:https://www.zigbee2mqtt.io (externer Link)

PGAdmin

Meine Kenntnisse bei MySQL/MariaDB sind ganz okay. PostgresQL kann ich allerdings so gut wie gar nicht. Entsprechend habe ich hier ein Webinterface zur Verwaltung meines PostgresQL Servers. Die MySQL/MariaDB AlternativephpMyAdmin (externer Link) sollte ja auch jedem bekannt sein.

Link:https://www.pgadmin.org (externer Link)

Heute habe ich mir ein neues NAS auf Basis von Ubuntu 21.04 eingerichtet und muss für unsere diversen macOS Geräte natürlich auch eine Dateifreigabe einrichten. Da das interne Netzwerk, für ein privates akzeptabel, abgesichert ist, verzichte ich auf eine erneute Authentifizierung an den Freigaben.

Heute habe ich mir ein neues NAS auf Basis von Ubuntu 22.0

Mein neues NAS ist auf Basis vonUbuntu (externer Link) 22 und SAMBA für CIFS Freigaben. Hierfür musste ich eine SAMBA Gast Freigabe erstellen die primär für MacOS gedacht ist. Aber natürlich funktioniert diese auch für Windows und Linux. Für MacOS benötigt man lediglich erweiterte Parameter.

SAMBA installieren

Zuerst müssen wir natürlich alle benötigten Pakete installieren. Diese sollten sich nicht unterscheiden, wenn du eine andere Ubuntu oder auf Debian/Ubuntu basierende Distribution verwendest. Zumindest wenn der Versionunterschied nicht allzugroß ist.

apt install samba samba-vfs-modules

Das wir SAMBA als Paket benötigen, sollte klar sein. Die „samba-vfs-modules“ sind Erweiterungen damit macOS die notwenigen Funktionen bereitgestellt bekommt.

SAMBA Gast Freigabe einrichten

Erst einmal sichern wir uns die Original Konfiguration

mv /etc/samba/smb.conf /etc/samba/smb.conf.org

Nun können wir uns eine neue Datei anlegen

nano /etc/samba/smb.conf

Dort packen wir folgenden Inhalt rein

[global]
workgroup = WORKGROUP
security = user
map to guest = Bad User
min protocol = SMB2
vfs objects = fruit streams_xattr
fruit:metadata = stream
fruit:model = Xserve
fruit:posix_rename = yes
fruit:veto_appledouble = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
[Dateien]
path = /nas02/shares/Dateien
vfs objects = catia fruit streams_xattr
public = yes
only guest = yes
browseable = yes
read only = no
writeable = yes
create mask = 0644
directory mask = 0755

Natürlich müsstest du noch ein paar Dinge anpassen:

• workgroup sollte entsprechend deiner im Heimnetzwerk befindlichen angepasst werden.
• [Dateien] ist der Name der Freigabe wie sie im Finder oder Windows Explorer angezeigt wird. Verwende hier nur Buchstaben und/oder Zahlen. Keine Sonderzeichen oder Leerzeichen. Das kann immer mal zu Problemen führen
• path sollte natürlich der Pfad wiederspiegeln in dem deine Dateien liegen sollen. Häufig ist das eine extra Festplatte oder gemountetes Laufwerk.

Den Rest kannst du so übernehmen. Natürlich kannst auch Dinge direkt anpassen, wenn du weißt was du tun musst.

Also können wir jetzt den SAMBA-Dienst neu starten

systemctl restart smbd

Anzeige mit AVAHI verschönern

Grundsätzlich würde die Freigabe im Finder jetzt schon auftauchen und funktionieren. Wir wollen das ganze aber noch ein wenig aufhübschen und ein passendes Icon an die Freigabe hängen. Das ganze wird mit AVAHI realisiert. Das muss auch erst einmal installiert werden

apt install avahi-daemon

Nun erstellen wir eine Datei die die benötigte Konfigration enthält

nano /etc/avahi/services/smb.service

Die bekommt folgenden Inhalt

<?xml version="1.0" standalone='no'?>
<!–*-nxml-*–>
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_smb._tcp</type>
<port>445</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=Xserve</txt-record>
</service>
</service-group>

Pass beim kopieren auf das die Hochkommata und Anführungszeichen richtig sind. Gegebenenfalls einfach noch mal ersetzen.

Solltest du denXserve nicht als Model verwenden wollen, stehen dir auch noch andere zur Verfügung. Füge einfach folgende URL in Safari ein und übernehme eines der Icons

file:///System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/`

Anschließend muss natürlich AVAHI einmal neu gestartet werden

systemctl restart avahi-daemon

Nun solltest du eine saubere Freigabe für macOS und Windows Geräte haben die keine Authentifizierung erfordern.

Viele Menschen starten ihr Homelab mit ein oder zwei Programmen auf einem kleinen Rechner. Langsam aber sicher wird dieses dann ausgebaut und im Laufe der Zeit erweitert. Geht man weg von einemRaspberry Pi (externer Link) und wechselt zum Beispiel auf einen Intel NUC hat man viel Freiraum für neue Services.

Genau aus diesem Grund möchte ich dir als Anregung meine Top 10 Homelab Services aufzählen. Vielleicht ist ja noch ein wenig Inspiration für dich mit dabei.

Bevor du dein Homelab startest solltest du dir erst einmal Gedanken machen auf welcher Hardware du deine Dienste installieren möchtest. Am einfachsten startet man mit alter, vorhandener Hardware. Solltest du etwas stromspurenderes benötigten kann man mit einemRaspberry Pi (externer Link) starten. Auf Amazon gibt es diverse Sets die direkt alles in einem liefern. Das ist zwar etwas teurer, dafür musst du dich nicht um Einzelteile kümmern.

Eine Alternative die natürlich mehr Power haben, sind Intel NUCs. Diese sehr beliebten Minirechner sind von kleinen stromsparenden CPUs bis hin zu einem potenten Core i7! Wer direkt viel Freiraum haben, langfristig plant und dennoch wenig für Strom ausgaben möchte ist damit wohl am besten bedient.

Meine Top 10 Homelab Services

Natürlich sind diese Softwareprodukte in eine Reihenfolge gebracht worden. Allerdings ist es manchmal schwer diese auch dauerhaft so zu verargumentieren. Die Reihenfolge ändert sich natürlich immer ein wenig. Aber die Produkte an sich bleiben doch meist gleich. Also los gehts:

10 – FreshRSS

FreshRSS (externer Link) ist wie der Name schon verrät ein RSS Reader. Eigentlich ja nichts Besonderes zumal es ja viele Cloud-Dienste wie z. B. Feedly gibt, die genau das gleiche machen. Wir wären aber nicht im Homelab, wenn wir nicht versuchen würden, möglichst viele Dienste selbst bereitzustellen.

Mit FreshRSS kannst du über den Browser den RSS Feed deiner Lieblingsblogs und -webseiten lesen. Hoffentlich auch den von teqqy.de 😉

Ich nutze als mobilen Client unter iOS zudem nochReeder (externer Link) . Diese App hat eine direkte Integration für FreshRSS und macht so das Setup total einfach.

Paperless-NG (externer Link) ist ein DMS (Document Management System) und der Nachfolger des leider nicht mehr weiter entwickelten paperless. Viele Tutorials da draußen funktionieren auch weiterhin mit paperless-ng. Ein DMS hilft dir deinen Papierkram digital zu strukturieren und im Falle des Falles schnell wieder zu finden.

Im Laufe der Zeit habe ich verschiedene andere DMS Systeme ausprobiert. Das ebenfalls kostenfreie papermerge sowie das kostenpflichtige ecoDMS, um nur zwei der gefühlt unendlich langen Liste zu nennen.

8 – Hajimari

Davon wirst du bestimmt noch nichts gehört haben. Macht nichts, dafür bin ich ja da. Hajimari ist einDashboard . Aber im Gegensatz zu Dashboards wie Heimdall ist dies rein auf die Installation in einem Kubernetes Cluster spezialisiert. Hajimari verwendet die Ingress API, um automatisch die Anwendungen im Cluster darzustellen.

Zudem kann es noch mit weiteren Links zu Lieblingsseiten erweitert werden. Falls du kein Kubernetes einsetzt, empfehle ich dir Heimdall oder Organizr mal anzugucken. Zu beiden gibt es sogar auch ein Video auf meinemYouTube (externer Link) Kanal.

7 – Littlelink

Sicherlich auch ein Service von dem du noch nichts gehört hast.Littlelink (externer Link) ist eine Alternative zu Linktree, einer Onlineplattform um Links zu verschiedenen Webseiten zusammen zu fassen. Wenn du viel in sozialen Netzwerken unterwegs bist, hast du das sicherlich schon mal gesehen.

Littlelink wurde von dem YouTuber TechnoTim (Folgeempfehlung (externer Link) ) erstellt und kann natürlich auch via Docker installiert werden. Ein Beispiel kannst du dir beimir (externer Link) anschauen.

6 – Grafana

Im Laufe der Zeit sammeln sich verschiedene Metriken, Performance- und Statistikdaten im Homelab an. Sei es durch das Monitoring, die Heim-Automatisation oder einfach nur weil die intelligenten Steckdosen den Strom sauber messen sollen. Grafana ist hierbei eines der, wenn nicht das beste Tool, um diese Daten zu visualisieren. Einen guten Einsteig in Grafana habe auch als kleineTutorialserie (externer Link) auf YouTube veröffentlicht. Vielleicht ist das ja noch was für dich.

5 – Authentik

Bereits vor kurzem hatte ich einen Blogartikel veröffentlicht, wie man Proxmox an Authentik anbinden kann. Aber was ist Authentik eigentlich? Mit dieser Software kannst du eine zentrale Nutzerverwaltung für deine Homelab Dienste bereitstellen. So musst du nicht in jeder Anwendung einzelne Benutzeraccounts pflegen.

Das besondere an Authentik ist, dass es die Benutzer auch nicht selbst pflegen muss, sondern z. B. von GitHub, Google oder LDAP heranziehen kann. Dir stehen damit also viele Möglichkeiten offen.

Ich versuche mittlerweile, jede Software, die eine Schnittstelle zu OpenID, oAuth oder LDAP hat, mit Authentik bekannt zu machen, um mir die Pflege der Nutzeraccounts zu vereinfachen.

4 – Proxmox

Proxmox? Ja Proxmox. Eine gute Virtualisierungsplattform zu haben, ist für das Homelab äußerst praktisch. Es lassen sich schnell und einfach neue System hoch ziehen und neue Software und Tools ausprobieren. Die Möglichkeit neue Dinge zu lernen kann somit schier unendlich sein.

{% youtube Io7oOnmhpZs %}

3 – Jellyfin

Ich ware viele Jahre Plex Nutzer. Plex ist ein Netzwerkmediaplayer, um Filme, Serien oder Musik im Netzwerk zu streamen. Da die coolen Funktionen in Plex nur mit einem Plex Pass zu haben sind, welcher gebührenpflichtig ist, ist das für viele ein kleines Hindernis.

Weitere Platzhirsche sind noch Kodi und Emby. Kodi hat für mich persönlich den Nachteil, dass die ganze Intelligenz in Client am TV hängt, heißt der muss entsprechend die Power haben. Bei den anderen wird mögliche Transcodierleistung vom Server erwartet.

ZuJellyfin (externer Link) bin ich vor kurzem gewechselt, weil ich etwas neues ausprobieren wollte – und bin dort hängen geblieben. Es ist einfach eine richtig gute Software.

2 – blocky

Von dieser Software hast du sicherlich auch noch nichts gehört. PiHole oder AdGuard Home allerdings schon.Blocky (externer Link) ist eine weitere Alternative dazu. Ich setze eben diese ein, weil sie perfekt für einen Kubernetes Cluster gemacht ist: Leichtgewichtig, komplett via deployment zu konfigurieren und stabil.

Wer den Werbeblocker nicht in einem Containercluster bereit stellt, dem ist weiterhin aus meiner Sicht eher AdGuard als PiHole zu empfehlen. Ich verfolge zwar die Entwicklung von PiHole nicht mehr aktiv, war aber mit AdGuard einfach immer zufriedener.

1 – Home-Assistant

Sicherlich eine der wenigen Software in der Liste, die du auf jeden Fall kennst. Home-Assistant ist meine Software, um meine komplette Heimautomatisation zu steuern. Von smarten Glühbirnen über Tür- und Fenstersensoren, Luftbefeuchter bis hin zu Staubsaugern und vielem mehr wird hierüber durch verschiedene Automatisierungen gesteuert. Meine Konfiguration findet du dazu übrigens auch aufGitHub (externer Link) .

Home-Assistant nutze ich, seit dem ich vor ca. 4 Jahren von FHEM dorthin gewechselt bin. Mit FHEM wurde ich irgendwie nie wirklich warm und openHAB2… nunja… Es ist Java…

Sonstiges

Sicherlich vermisst du Dienste wie Passwortmanager oder Codeverwaltung? Das liegt daran, dass beide Services so wichtig sind, dass ich im Homelab nicht die notwendige Uptime dafür bereitstellen kann und möchte. Zwar gehört auch immer ein gewisses Stück Vertrauen in die Software, allerdings haben mich 1Password als Passwortmanager und GitHub als Codeverwaltung noch nie enttäuscht.

Zwischenzeitlich hatte ich beide Services sogar mal selbst gehostet, aber auf Grund der eben angesprochenen Problematik dann doch wieder einem Cloud-Service überlassen.

In allen meiner Tutorials verwende ich Traefik alsReverse Proxy für Docker Container, so natürlich auch auf meinemYouTube Kanal (externer Link) . Im Laufe der Zeit fragen immer wieder Leser und Zuschauer ob ich ihnen bei ihrem Problem helfen kann. Dies mache ich natürlich gerne. Für ein gewisse Selbsthilfe möchte ich dir allerdings diesen Traefik Troubleshooting Guide an die Hand geben.

Vorbereitende Maßnahmen

Um mit einem guten Troubeshooting zu beginnen möchte ich zwei Maßnahmen vorweg greifen. Diese helfen dir ein paar Dinge auszuschließen bzw. eventuell schnell selbst auf eine Lösung zu kommen.

Container richtig neu starten

Wenn ihr Änderungen am Container von Traefik oder gar an den Konfigurationsdateien vornimmt, muss Traefik komplett neu gestartet werden. Ein stoppen des jeweiligen ist nicht ausreichend. Beimeinen Compose Dateien (externer Link) verwende also bitte nach dem stoppen noch ein

docker-compose rm

um diesen komplett zu löschen. Anschließend kannst du den Container wieder starten und eine neue Konfiguration ist übernommen.

Erhöhen des Log Levels

Zum Traefik Troubleshooting gehört auf jeden Fall auch das betrachten der Log Dateien. In meiner Vorlage steht das Logging auf einer sehr kleinen Stufe um nicht unnötig Speicherplatz zu benötigen. Wenn du mit Traefik startest empfehle ich dir, dieses auf debug zu stellen.

Hierzu einfach die traefik.toml Datei anpassen:

[log]
level = "DEBUG"

Fehlerlösungen

Die Webseite wird als nicht sicher angezeigt

Dieser Fehler entsteht zumeist wenn Traefik keinLet’s Encrypt (externer Link) Zertifikat abrufen konnte. Leider kann das mehrere Ursachen haben:

Zu häufiges Abrufen von Zertifikaten

Im Log steht hier meist, dass die Anzahl der Möglichen Erstellversuche von Zertifikaten erreicht ist. LE lässt es nur zu 10 Versuche binnen 24 Stunden auf ein SSL-Zertifikat zu erstellen. Wenn du eine eigene Domain hast, versuche es mit einer anderen Subdomain erneut. Andernfalls hilft nur warten.

Ein anderer Container hört auf Port 80

Let’s Encrypt nutzt bei der ersten Kommunikation zwischen Server und Client auch HTTP (Port 80). Wenn dieser Port also noch durch einen anderen Container geblockt ist kann keine Verbindung aufgebaut werden. Ebenso könnte es sein, dass dein NAT in deinem Router Port 80 noch nicht weiter leitet.

Eine 404-Seite wird angezeigt

Jetzt wird es spannend. Sobald eine 404-Seite angezeigt wird, gibts nämlich ein Problem mit dem Routing zu den Containern. Folgende Dinge kannst du hier prüfen:

• Wird der korrekte Port weiter geleitet?
• Stimmen alle Middlewere-Configs überein?