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 ]]>pxeproxmoxlinuxhttps://www.teqqy.de/zahlen-daten-fakten-nach-fuenf-jahren-tesla-model-3/Sun, 16 Mar 2025 12:00:00 +0100Sun, 16 Mar 2025 12:00:00 +0100https://www.teqqy.de/zahlen-daten-fakten-nach-fuenf-jahren-tesla-model-3/Tesla Model 3 Langzeittest: 77.000 km nach 5 Jahren - Ehrliche Bilanz zu Kosten, Verbrauch &amp; Akkugesundheit Nach fünf Jahren und 77.000 Kilometern mit unserem Tesla Model 3 ziehen wir Bilanz. Spoiler: Der Akku hat noch 93 % seiner Kapazität, wir haben rund 3.500 Euro fürs Laden ausgegeben und der Durchschnittsverbrauch liegt bei 20,6 kWh/100 km. Trotzdem verkaufen wir das Auto jetzt. Warum? Das erfährst du in diesem ehrlichen Erfahrungsbericht mit allen Zahlen, die du für deine Kaufentscheidung brauchst.<![CDATA[

Tesla Model 3 Langzeittest: 77.000 km nach 5 Jahren - Ehrliche Bilanz zu Kosten, Verbrauch & Akkugesundheit

Nach fünf Jahren und 77.000 Kilometern mit unserem Tesla Model 3 ziehen wir Bilanz. Spoiler: Der Akku hat noch 93 % seiner Kapazität, wir haben rund 3.500 Euro fürs Laden ausgegeben und der Durchschnittsverbrauch liegt bei 20,6 kWh/100 km. Trotzdem verkaufen wir das Auto jetzt. Warum? Das erfährst du in diesem ehrlichen Erfahrungsbericht mit allen Zahlen, die du für deine Kaufentscheidung brauchst.

Der Start: Corona sei Dank fast ohne Auto dastanden

Vor ziemlich genau fünf Jahren haben wir unser Tesla Model 3 abgeholt. Wir hatten sehr viel Glück, denn es wurden reichlich Überstunden der Mitarbeitenden geschoben damit alle ihr Auto noch rechtzeitig bekommen. Am Folgetag sollte nämlich die erste Corona Ausgangsbeschränkung gelten und wir hätten auf unbestimmte Zeit auf unser neues Auto warten müssen. Dahingehend fing der Start eigentlich schon mal ziemlich gut an.

Verarbeitungsqualität nach 5 Jahren: Besser als ihr Ruf

In den Anfangsjahren haben sich viele Menschen über die Qualität der Autos lustig gemacht. Wir hatten das Glück ein, auf den ersten Blick, mängelfreies Auto zu erhalten. Zugegebenermaßen bin ich nicht wie andere mit einer X-seitigen Checkliste um das Auto herum gelaufen. Als ob die Personen das jemals bei anderen Neufahrzeugen gemacht hätten…

Im Laufe der Jahre fiel auf, dass die eine oder andere Fixierung durch Plastikteile nicht vorhanden waren. Es wurde da also ein wenig an den Cent-Artikel gespart. Bei den heutigen Modellen wird das sicherlich nicht mehr der Fall sein.

Was nach 5 Jahren auffällt:

• Keine größeren Qualitätsprobleme
• Einzelne fehlende Plastikfixierungen im Innenraum
• Lackierung und Verarbeitung insgesamt solide
• Keine Rostprobleme oder Spaltmaße-Dramen

Verbrauch und Kosten im Detail: Die nackten Zahlen

Ich hatte das Auto fast die ganze Zeit bei Tronity in der Datenerfassung. Es könnte sein, dass zwar einzelne Fahrten fehlen, aber das Gesamtbild wird trotzdem stimmen.

Die harten Fakten:

• Gesamtkilometer: 76.922 km (davon 76.310 km getrackt)
• Durchschnittsverbrauch: 20,6 kWh/100 km
• Gesamte Ladekosten: ca. 3.500 Euro
• Kosten pro Kilometer: ca. 4,6 Cent
• AC/DC-Verhältnis: 80/20

Warum unser Verbrauch höher liegt

Wir fahren kaum schnell und Langstrecke häufig mit ca. 120 - 140 km/h Tempomat. Allerdings mag ich die sehr zügige Beschleunigung des Elektroautos. Entsprechend geht viel Energie immer hier verloren. Zudem kommt, dass die Heizung fast das ganze Jahr auf ca. 22,5 °C eingestellt ist und wir die Vorklimatisierungsfunktion sehr häufig nutzen. Das fällt alles in den Verbrauch mit rein und ist entsprechend zu bedenken.

Zum Vergleich: Ein vergleichbarer Verbrenner (z.B. BMW 320i) hätte bei ähnlichem Fahrprofil etwa 7-8 Liter auf 100 km verbraucht. Bei einem Benzinpreis von durchschnittlich 1,70 Euro wären das Kraftstoffkosten von rund 9.000 Euro gewesen.Ersparnis: ca. 5.500 Euro - und das obwohl wir zu 80 % an der heimischen Wallbox laden konnten.

Akkugesundheit nach 77.000 km: Das ist der wichtigste Wert

Das Verhältnis zwischen AC und DC laden beträgt 80/20. Das ergibt einen derzeitigenState of Health (SoH) von 93 % laut Tronity. Bedeutet: Der Akku unseres Autos hat noch 93 % der Leistung seines Neuzustandes.

Was bedeutet das konkret?

• Von ursprünglich ca. 500 km Reichweite (WLTP) bleiben noch ca. 465 km
• Der Verlust von 7 % in 5 Jahren ist völlig im Rahmen
• Hochgerechnet hätte der Akku nach 10 Jahren noch etwa 86 % Kapazität
• Tesla gibt 8 Jahre Garantie auf mindestens 70 % Restkapazität

6 Länder, 0 Ladeprobleme: Langstreckentauglichkeit im Test

Wir waren mit dem Auto in sechs Ländern und in keinem hatten wir jemals das Problem eine funktionierende Ladesäule zu finden. Durch Corona sind wir allerdings dann doch nicht so viel im Ausland gewesen als wir eigentlich gedacht hätten.

Lediglich unser Roadtrip im Jahr 2024 hat uns durch Frankreich, Spanien und Portugal geführt. Damals sind wir knapp6.200 km in 14 Tagen gefahren. Ein Urlaub der toll und zugleich ansträngend war.

Ladeerfahrung auf Langstrecke:

• Tesla Supercharger: Quasi immer verfügbar und zuverlässig
• Andere Anbieter: Mittlerweile deutlich besser als vor 5 Jahren
• Ladeplanung: Mit der Tesla-Navigation eigentlich kein Thema

Warum wir nach 5 Jahren verkaufen: Die ehrlichen Gründe

Nach fünf Jahren werden wir das Auto verkaufen. Das hat mehrere Gründe:

1. Die Marke und ihr Geschäftsführer Wir möchten die Marke mit seinem derzeitigen Geschäftsführer nicht mehr repräsentieren. Das ist eine persönliche Entscheidung, die jeder für sich treffen muss.

2. Zeit für etwas Neues Nach fünf Jahren wird es Zeit für etwas neues. Die aktuellen Modelle sind sehr spannend und scheinen weiterhin ein extrem gutes Preis-/Leistungsverhältnis zu haben.

3. Zu viel Touchscreen, zu wenig Tasten Der Weg den Tesla mit der immer voranschreitenden Reduzierung von physischen Knöpfen und Hebeln beschreitet, ist nicht mehr unseres. Wir mögen das reduzierte und aufgeräumte Interieur aber manche Funktionen haben für mich lieber einen Knopf als eine Geste im Infotainmentsystem. Ein gefühltes Flugzeugcockpit wie bei den deutschen Herstellern brauche ich aber auch überhaupt nicht.

Was kommt als Nächstes?

Wir haben uns jetzt einenNIO zugelegt den wir mindestens die nächsten drei Jahre fahren werden. Warum? Das wird ein eigener Erfahrungsbericht - stay tuned!

Fazit: Lohnt sich ein Tesla Model 3 nach 5 Jahren noch?

Die Top 3 Vorteile:

1. Niedrige Betriebskosten: 4,6 Cent/km sind unschlagbar günstig
2. Akkugesundheit: 93 % nach 77.000 km spricht für die Batteriequalität
3. Ladeinfrastruktur: Supercharger-Netz ist und bleibt der Goldstandard

Die Top 3 Nachteile:

1. Bedienkonzept: Immer mehr Funktionen nur über Touchscreen nervig
2. Markenimage: Das Thema Elon Musk polarisiert stark
3. Kleine Qualitätsmängel: Cent-Artikel wie Plastikclips wurden gespart

Für wen lohnt sich ein gebrauchter Tesla Model 3?

• Wer primär Kurzstrecke und gelegentlich Langstrecke fährt
• Wer Zugang zu günstigen Lademöglichkeiten hat (Wallbox, Arbeit)
• Wer mit dem Touchscreen-Konzept gut zurechtkommt
• Wer ein Auto mit niedrigen laufenden Kosten sucht

Wer sollte die Finger davonlassen?

• Wer viele physische Bedienelemente bevorzugt
• Wer ausschließlich öffentlich laden müsste
• Wer mit der Marke Tesla nicht identifizieren möchte

Häufige Fragen zum Tesla Model 3 Langzeittest

Wie hoch ist der Wertverlust nach 5 Jahren?[Falls du den Verkaufspreis schon kennst, könntest du das hier ergänzen]

Würdest du das Auto nochmal kaufen? Ja, für die damalige Zeit war es die richtige Entscheidung. Heute würde ich mir aber die Konkurrenz genauer anschauen - der Markt hat sich stark entwickelt.

Wie oft musstest du an die Werkstatt?[Hier könntest du deine Erfahrungen ergänzen]

Lohnt sich ein Tesla Model 3 gebraucht? Absolut, wenn du mit dem Bedienkonzept klarkommst und günstig laden kannst. Die Technik ist ausgereift, die Akkus halten gut.

Wie Menschen die mir auf social media folgen wissen, betreibe ich einen kleinenKubernetes Cluster im GitOps Prinzip. Meinevollständige Konfiguration (externer Link) befindet sich auf der Cloud Plattform GitHub und kann dort von allen eingesehen werden. Dazu setze ich auf eine saubere Versionverwaltung beim Update der Container. Das hilft um schnell auf eine alte Version zurück zu springen. Da ich mich nicht selbst um das heraussuchen der neusten Versionen kümmern möchte, nutze ichRenovate (externer Link) als App bei GitHub. Diese schaut in die verschiedenen Dateien und vergleicht die konfigurierte Version eines Containers mit der zuletzt veröffentlichten und erstellt daraus ein pull request.

Im Standard sind alle Labels bei den Plattformen wie GitHub, Gitlab odergitea (externer Link) in grau gehalten. Hier fehlt also etwas die Übersicht zur schnelleren Einschätzung der Situation. Aus diesem Grund verwende ich ein kleinen Workflow der mir die von Renovate angehäfteten Labels bunt einfärbt. Ich nutze das Vorgehen auf GitHub, sollte aber fast identisch auch bei GitLab oder gitea funktionieren.

Ich gehe davon aus, dass es bereit ein vorhandenes Repository gibt und sich dies lokal auf deiner Workstation befindet. Entsprechend erstellen wir im Hauptverzeichnis des Repos einen Unterordner mit dem Namen.github. Auf anderen Plattformen sollte er analog zur Plattform heißen.

In diesem Unterordner erstellen wir einen weiteren Order mit dem Namenworkflows. Sämtlichey(a)mlDateien werden hier als eingenständiger Workflow auf der jeweiligen Plattform aufgeführt.

Nun können wir auch den Workflow bzw. GitHub Action anlegen. Ich habe sie bei mirlabel-sync.yaml genannt und folgendes in die Datei kopiert:

---# yaml-language-server: $schema=https://json.schemastore.org/github-workflow.jsonname:"Label Sync"on:workflow_dispatch:push:branches:["main"]paths:[".github/labels.yaml"]jobs:label-sync:name:Label Syncruns-on:ubuntu-lateststeps:-name:Checkoutuses:actions/checkout@v4with:sparse-checkout:.github/labels.yaml-name:Sync Labelsuses:EndBug/label-sync@v2with:config-file:.github/labels.yamldelete-other-labels:true

Glücklicherweise brauchen wir hierfür ein Bot oder ähnliches, sondern es funktioniert direkt. Wie du gegebenenfalls in dem workflow siehst, verweisen wir auf eine Datei mit dem Namenlabels.yaml. Diese müssen wir noch in dem Ordner.github anlegen und befüllen.

In diese Datei kommen dann sämtliche Labels mit dem entsprechenden HTML-Farbcode. Bei mir sieht die Datei so aus:

---# Areas-name:area/ansiblecolor:"0e8a16"-name:area/docscolor:"0e8a16"-name:area/githubcolor:"0e8a16"-name:area/kubernetescolor:"0e8a16"-name:area/terraformcolor:"0e8a16"# Clusters-name:cluster/maincolor:"ffc300"-name:cluster/storagecolor:"ffc300"# Renovate Types-name:renovate/ansiblecolor:"027fa0"-name:renovate/containercolor:"027fa0"-name:renovate/github-actioncolor:"027fa0"-name:renovate/grafana-dashboardcolor:"027fa0"-name:renovate/github-releasecolor:"027fa0"-name:renovate/helmcolor:"027fa0"-name:renovate/terraformcolor:"027fa0"# Semantic Types-name:type/digestcolor:"ffeC19"-name:type/patchcolor:"ffeC19"-name:type/minorcolor:"ff9800"-name:type/majorcolor:"f6412d"# Uncategorized-name:holdcolor:"ee0701"

Wir können jetzt unsere Änderungen commiten und pushen. Beim nächsten push wird dann der Workflow angestoßen und ausgeführt. Nun sollten alle Labels die ihr als Issue oder Pull Request habt in der entsprechenden Farbe dargestellt werden. Bei mir sieht das z. B. so aus: ]]>githubgitlabgitearenovatehttps://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 (externer Link) 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.

Kunden bei Vodafone Kabel bekommen immer ein IPv6 Netz zugewiesen. In meinem Fall ist das ein /63 Netz. Da ich allerdings ein Doppel-NAT betreibe bekommen meine Clients keine IPv6 Adresse aus diesem Netz.

Warum überhaupt IPv6?

IPv6 fördert die End-to-End-Konnektivität. Dies ist wichtig, um eine direkte Kommunikation zwischen den Endgeräten im Internet zu ermöglichen, ohne dass komplexe Netzwerkadressübersetzung (NAT) eingesetzt werden muss, wie dies häufig bei IPv4 der Fall ist. Zudem hat IPv6 einige Verbesserungen gegenüber IPv4 in Bezug auf die Netzwerkeffizienz und Leistung. Dies umfasst eine optimierte Header-Struktur, die die Router-Verarbeitung erleichtert, sowie die Unterstützung für Multicasting, was dazu beiträgt, den Datenverkehr effizienter zu gestalten. IPv6 wurde mit Sicherheitsverbesserungen konzipiert. IPsec (Internet Protocol Security) ist in IPv6 integriert und bietet eine standardmäßige Verschlüsselung und Authentifizierung des Datenverkehrs. Angesichts der begrenzten Verfügbarkeit von IPv4-Adressen ist IPv6 die Zukunft des Internetprotokolls. Die Umstellung auf IPv6 stellt sicher, dass Netzwerke auch in den kommenden Jahren und Jahrzehnten in der Lage sind, mit dem ständig wachsenden Bedarf an IP-Adressen Schritt zu halten.

Einstellungen an der Fritzbox

Zuerst stellen wir alles bei der Fritzbox ein. Wir navigieren zuHeimnetzwerk ->Netzwerk ->Netzwerkeinstellungen ->IPv6-Einstellungen.

Router Advertisment im LAN aktiv

Die Einstellung ganz oben schalten wir ein. Dann möchten wir, dass die Unique Local Addresses (ULA) immer zugewiesen werden. Den ULA Prefix können wir uns quasi selbst ausdenken.

DNSv6 Server im Heimnetz

Ich habe den nicht aktiv. Ich versuche erst mal mein Pi-Hole im Netzwerk zu verwenden. Bisher habe ich noch keine Nachteile dadurch entdeckt.

DHCP-v6 Server im Heimnetz

Hier wird es spannend, weil hier die Zuweisung an die Endgeräte gemacht wird. Entsprechend aktivieren wir die erste OptionDHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren. Dann möchten wirDNS-Server und IPv6-Präfix (IA_PD) zuweisen. Den Rest lassen wir auf Standardeinstellung.

Einstellungen an der opnSense

Nun können wir mit der Konfiguration der opnSense fortfahren. Grundlegend sollten die Einstellungen auch sehr nah zur pfSense sein. Die Screenshots passen dann natürlich nicht mehr.

Einstellungen am WAN Interface

Wir starten mit den Einstellungen am WAN Interface. Also der Port mit dem sich die opnSense zur Fritzbox verbindet. Als erstes stellen wir denIPv6 Konfigurationstyp aufDHCPv6. In derDHCPv6 Clientkonfiguration fordern wir das IPv6 Prefix an und stellen diePräfixdelegationsgröße auf 63 (also ein bit kleiner als unser Netzwerk groß ist). Zudem senden wir den IPv6 Präfixhinweis.

Einstellungen des LAN Interface

Wir können auf Grund der Zuweisung des Netzes bis zu zwei Client Netzwerke mit IPv6 Adressen ausstatten. Wenn nur nur ein internes Netzwerk hast, sollte das natürlich kein Problem sein. Ich habe aber mein Normales Netzwerk für Server etc vom Client-Netzwerk getrennt und vergebe hier pro Netz IPv6 Adressen. Netzwerke wie für IoT Geräte oder Gastnetze können per IPv4 weiterhin verbleiben.

UnterSchnittstellen ->LAN möchten wir denIPv6 Konfigurationstyp ändern. Den müssen wir aufSchnittstelle aufzeichnen stellen. Ganz unten erscheint dann eine weitere Einstellungsgruppe mit dem NamenIPv6-Schnittstelle aufzeichnen. Die Schnittstelle setzen wir dann aufWAN, weil hier ja unsere IPv6 Pakete her kommen. Die Präfix-ID setzen wir auf0. Solltest du ein weiteres Netz konfigurieren, stellst du die ID dann im anderen Netz auf1. Wichtig ist unten noch das Häkchen beiErmöglichen Sie die manuelle Anpassung von DHCPv6- und Router-Ankündigungen* zu setzen!

Hier das ganze noch mal als Screenshot:

Router Advertisement

Als nächstes müssen wir das Router Advertisement einstellen. Dazu aufDienste ->Router Advertisement ->LAN klicken. Sollte der Punkt noch nicht vorhanden sein, kontrolliere mal ob du überall die Einstellungen auch korrekt gespeichert hast. Gegebenenfalls auch mal den Browser neu laden. Viel müssen wir hier nicht einstellen. Lediglich dasRouter Advertisement aufNichtVerwaltet.

Firewall Einstellungen überprüfen (optional)

Ich hatte noch das Problem, dass ich nur mit IPv4 Paketen ins Internet kam, allerdings nicht per IPv6. Entsprechend musste ich noch eine Firewall Regel anpassen. UnterFirewall ->Regeln ->LAN. Dort bearbeiten wir dieausgehende Regel und klicken hinten auf den Stift. Im sich öffnenden Fenster stellen wir dieTCP/IP Version vonIPv4 aufIPv4+IPv6 um. Anschließend auf speichern.

Testen der IPv6 Verbindung

Als erstes sollten wir gucken ob alle Interfaces auf der opnSense auch eine IPv6 Adresse bekommen haben. Dazu bitte unterSchnitstellen ->Überblick deine WAN Schnittstelle aufklappen. Du solltest unter IPv6-Adresse nun zwei Adressen haben. Einmal aus dem Vodafone Netz und eine die mitfd beginnt. Das ist die Adresse aus dem Bereich das wir bei der Fritzbox unterULA Prefix eingestellt haben. Unter deinen LAN Interfaces solltest du auch jeweils zwei Adressen haben. Wenn dem nicht so ist, kontrolliere nochmals alle Einstellungen.

Wenn bis dahin alles korrekt eingestellt wurde, öffnen wir die Seiteipv6-test.com (externer Link) . Diese kontrolliert nun ob ihr mit einer IPv4 und einer IPv6 Adresse ankommt. Entsprechend sollte es ähnlich zu meiner Anzeige sein.

]]>fritzboxopnsensenetworkinghttps://www.teqqy.de/freshrss-rss-reader-zum-selber-hosten/Sun, 06 Aug 2023 12:05:00 +0200Sun, 06 Aug 2023 12:05:00 +0200https://www.teqqy.de/freshrss-rss-reader-zum-selber-hosten/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 eine vollständige API-Unterstützung, sodass du deine Feeds überall synchronisiert nutzen kannst.<![CDATA[

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.

In den letzten Jahren habe ich immer wieder aus verschiedenen Gründen die Blogsoftware gewechselt. Dieses Mal bin ich von Wordpress zu Jekyll umgezogen. Mein Vorgehen und Gründe möchte ich in diesem Beitrag erläutern.

Was ist Jekyll?

Jekyll ist eine Blogsoftware bzw. ein sogenannter Static Site Generator. Primär wird Jekyll von GitHub Pages verwendet. Die meisten Tutorials die man so im Internet finden beziehen auch genau darauf. Grundlegend baut die Software Markdown-Dateien zu statischen HTML Dateien um diese mit einem einfachen Webserver ausliefern zu können. Im bequemsten Fall sogar mit dem integriertem.

Gründe für meinen Wechsel

Gründe könnten mannigfaltig sein. Schlussendlich läuft es aber darauf hinaus, dass Wordpress immer mächtiger wird. Das hat seine Vor- und Nachteile. Sicherlich ist es sehr praktisch für jeden Anwendungsfall Wordpress verwenden zu können, denn die verschiedenen Plugins und Themes machen das möglich. Viele großen Webseiten basieren auf Wordpress und mit dem notwendigen Know-How und Ressourcen lassen sich auch sehr Performance Webseiten bauen. Der Nachteil der Erweiterbarkeit liegt entsprechend auch in der Pflege und den Bemühungen einen guten Wert für den LCP zu erreichen. Mir ist es im Laufe der Zeit nicht gelungen einen guten Wert zu erreichen. Am HosterNetcup (externer Link) liegt es nicht, da ich hier auch verschiedene ausprobiert habe. Zudem bin ich im Moment dabei mich von verschiedenen großen Softwareprodukten zu trennen und auf freiere Software zu setzen.

In der Webentwicklung steht LCP für “Largest Contentful Paint”. Es handelt sich um eine wichtige Metrik für die Ladeleistung einer Webseite. LCP misst die Zeit, die benötigt wird, um den größten sichtbaren Inhalt im Viewport eines Nutzers während des Seitenladens zu rendern. Ein guter LCP-Wert ist wichtig, um sicherzustellen, dass Webseiten schnell und reibungslos geladen werden und Benutzer eine bessere Erfahrung haben. {:.note title=“Was ist LCP?”}

Installation von Jekyll

Die Installation von Jekyll kann unter verschiedenen Betriebssystemen durchgeführt werden. Allerdings ist Windows nicht mit dabei. Wenn man allerdings den Umweg über WSL2 geht, kann man der regulären Linux Installation für die verwendete Linux-Distribution folgen. In dieser Anleitung gehe ich erst mal auf die Installation unter MacOS ein, da ich persönlich dieses Betriebssystem verwende. Alternative Installationen finden sich natürlich in der offiziellen Dokumentation. Gern kann dort diese entsprechend verwendet werden.

Installation unter MacOS

Installation des Paketmanagers brew

MacOS Nutzer haben in der Regel schon den Paketmanagerbrew installiert. Falls du das noch nicht getan hast, lässt sich das mittels

/bin/bash -c"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

erledigen. Grundsätzlich sollte aber immer beim Ausführen von Programmen direkt aus dem Internet vorsichtig sein! Sobald das erledigt ist, brauchen wir jetzt den Ruby Installer denn Jekyll ist in der entsprechenden Programiersprache geschrieben.

Installation von ruby

brew install chruby ruby-install xz

Dies kann durchaus ein paar Minuten dauern, das ist nicht ungewöhnlich. Nun installieren wir noch ruby selbst.

ruby-install ruby 3.2.2

Beachte, dass die Version 3.2.2 die zum Zeitpunkt des Artikels die aktuellste Version ist, dass kann zum jetzigen Zeitpunkt anders sein. Der nächste Schritt ist, dass wir ruby und die ganzen Environment Variablen noch aktivieren und in die MacOS Konfiguration speichern

echo"source$(brew --prefix)/opt/chruby/share/chruby/chruby.sh" >> ~/.zshrcecho"source$(brew --prefix)/opt/chruby/share/chruby/auto.sh" >> ~/.zshrcecho"chruby ruby-3.2.2" >> ~/.zshrc# run 'chruby' to see actual version

Installation von Jekyll

Endlich kommen wir zu dem Punkt, dass wir Jekyll selbst installieren können.

gem install jekyll

Auch der Schritt kann einige Zeit lang brauchen. Anschließend haben wir Jekyll installiert.

Jekyll Webseite anlegen

Sobald wir also eine lauffähige Version von Jekyll haben, können wir nun eine Webseite anlegen. Wir suchen uns also einen entsprechenden Ordner aus in dem die Installation durchgeführt werden soll. Ich mache sowas immer in einem Unterordner in meinem Homeverzeichnis.

cd ~

Den Namen den wir im install Befehl mitgeben wird auch der Name des Ordners sein. Natürlich kann der Prozess beliebig oft ausgeführt werden, falls euch das nicht gefällt.

jekyll new blog

Es entsteht dann eine ungefähr solche Ausgabe

Running bundle install in /Users/teqqy/blog... Bundler: Fetching gem metadata from https://rubygems.org/............ Bundler: Resolving dependencies... Bundler: Fetching rouge 4.1.3 Bundler: Installing rouge 4.1.3 Bundler: Bundle complete!7 Gemfile dependencies,33 gems now installed. Bundler: Use`bundle info[gemname]` to see where a bundled gem is installed.New jekyll site installed in /Users/teqqy/blog.[21:31:33][cost 3.162s] jekyll new blog

Nun wechseln wir in das Verzeichnis und gucken mal was so für Dateien und Ordner dort hinterlegt sind.

[21:32:50][~/blog] ❱❱❱ ls -ltotal48-rw-r--r--1 teqqy staff41931 Jul 21:31 404.html-rw-r--r--1 teqqy staff130931 Jul 21:31 Gemfile-rw-r--r--1 teqqy staff205231 Jul 21:31 Gemfile.lock-rw-r--r--1 teqqy staff207931 Jul 21:31 _config.ymldrwxr-xr-x3 teqqy staff9631 Jul 21:31 _posts-rw-r--r--1 teqqy staff53931 Jul 21:31 about.markdown-rw-r--r--1 teqqy staff17531 Jul 21:31 index.markdown

Wie man sieht, sind das nicht viele Dateien. Nun sollten wir die_config.yml anpassen. Die Begriffe sollten selbsterklärend sein. Die Werte sind aber erst mal keine Pflicht. Um jetzt die HTML Dateien bauen zu lassen verwenden wir folgenden Befehl

jekyll serve

Es erscheinen diverse Fehlermeldungen und Warnungen auf Grund von veralteten Abhängigkeiten. Leider sind diese immer noch nicht sauber gefixt. Die letzte Ausgabe sollte etwas in der Art von

Run in verbose mode to see all warnings.done in 0.401 seconds. Auto-regeneration: enabledfor'/Users/teqqy/blog' Server address: http://127.0.0.1:4000/ Server running... press ctrl-c to stop.

Enthalten. Jetzt könnt ihr euren Browser öffnen und die URLhttp://127.0.0.1:4000 verwenden.

Wir brechen dann wieder den laufenden Server mitCTRL-C ab. Wenn wir jetzt nochmal die Verzeichnisse auflisten sehen wir, dass dort ein neuer Ordner_site erstellt worden ist.

[21:40:43][~/blog] ❱❱❱ ls -ltotal48-rw-r--r--1 teqqy staff41931 Jul 21:31 404.html-rw-r--r--1 teqqy staff130931 Jul 21:31 Gemfile-rw-r--r--1 teqqy staff205231 Jul 21:31 Gemfile.lock-rw-r--r--1 teqqy staff207931 Jul 21:31 _config.ymldrwxr-xr-x3 teqqy staff9631 Jul 21:31 _postsdrwxr-xr-x8 teqqy staff25631 Jul 21:35 _site-rw-r--r--1 teqqy staff53931 Jul 21:31 about.markdown-rw-r--r--1 teqqy staff17531 Jul 21:31 index.markdown

Dieser Ordner ist nun schlussendlich das wichtige. Dieser kann auf einen Webserver kopiert und ausgeliefert werden.

Webseite bereitstellen

Viele Tutorials im Internet verwenden denjekyll serve Befehl um die Webseite auszuliefern und richten einen Webserver wie NGINX oder apache2 als reverse proxy ein. Dies ist allerdings nicht der vom Hersteller empfohlene Weg. Ich für meinen Teil habe das Verzeichnis auf meinen Webserver kopiert und liefere es mit einem Nginx Docker-Container aus. Dieser hat entsprechende Traefik Labels, welches sich um die Zertifikate etc kümmert. Sicherlich kein Setup für jeden.

Nginx Docker Container

Meine verwendetedocker-compose.yaml Datei kannst du natürlich übernehmen wenn du möchtest. Du müsstest nur die Werte entsprechend anpassen.

---version:"3.8"services:nginx:image:nginxcontainer_name:nginxvolumes:-./_site:/usr/share/nginx/html-./nginx.conf:/etc/nginx/conf.d/www_nginx.conflabels:-"traefik.enable=true"-"traefik.http.middlewares.nginx-https.redirectscheme.scheme=https"-"traefik.http.middlewares.nginx-compress.compress=true"-"traefik.http.routers.nginx-http.entrypoints=web"-"traefik.http.routers.nginx-http.rule=Host(`www.example.com`) || Host(`example.com`)"-"traefik.http.routers.nginx-http.middlewares=teqqy-https@docker"-"traefik.http.routers.nginx.entrypoints=websecure"-"traefik.http.routers.teqqy.rule=Host(`www.example.com``) || Host(`example.com``)"-"traefik.http.routers.nginx.tls=true"-"traefik.http.routers.nginx.tls.certresolver=default"-"traefik.http.routers.nginx.middlewares=secHeaders@file"-"traefik.http.routers.nginx.middlewares=teqqy-compress"-"traefik.http.services.nginx.loadbalancer.server.port=80"networks:-teqqywp-traefik_proxynetworks:traefik_proxy:external:name:traefik_proxyteqqywp:driver:bridge

Nginx Konfiguration

Ich binde noch eine eigenenginx.conf Datei ein in der ich noch Anpassungen für Caching und anderes mache.

server {
listen 80;
server_name example.com www.example.com
root /usr/share/nginx/html;
index index.html index.htm;
if (!-f "${request_filename}index.html") {
rewrite ^/(.*)/$ /$1 permanent;
}
if ($request_uri ~* "/index.html") {
rewrite (?i)^(.*)index\.html$ $1 permanent;
}
if ($request_uri ~* ".html") {
rewrite (?i)^(.*)/(.*)\.html $1/$2 permanent;
}
error_page 404 /404.html;
location / {
try_files $uri $uri.html $uri/ =404;
}
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
}
# reduce the data that needs to be sent over network -- for testing environment
gzip on;
# gzip_static on;
gzip_min_length 10240;
gzip_comp_level 1;
gzip_vary on;
gzip_disable msie6;
gzip_proxied expired no-cache no-store private auth;
gzip_types
# text/html is always compressed by HttpGzipModule
text/css
text/javascript
text/xml
text/plain
text/x-component
application/javascript
application/x-javascript
application/json
application/xml
application/rss+xml
application/atom+xml
font/truetype
font/opentype
application/vnd.ms-fontobject
image/svg+xml;
# allow the server to close connection on non responding client, this will free up memory
reset_timedout_connection on;
# request timed out -- default 60
client_body_timeout 10;
# if client stop responding, free up memory -- default 60
send_timeout 2;
# server will close connection after this time -- default 75
keepalive_timeout 30;
# number of requests client can make over keep-alive -- for testing environment
keepalive_requests 100000;
}

Nun kann der Container gestartet werden und nach kurzer Zeit könnt ihr die Seite über die angegebene URL aufrufen.

Wordpress Daten exportieren

Für den Export habe ich das Wordpress PluginWordpress to Jekyll Exporter (externer Link) verwendet. Es nicht das beste Plugin aber für mich hat es gereicht. In Wordpress können wir dann unterWerkzeuge den Export ausführen und bekommen eine ZIP-Datei zum Download. Die Inhalte können wir direkt in unser Jekyll Verzeichnis kopieren und die Seiten neu genierieren lassen.

jekyll serve

Nun können wir den Ordner_site wieder auf unseren Webserver kopieren. Den Container müssen wir nicht neu starten, denn nginx liefert die Dateien direkt aus. Ein einfacher reload im Browser reicht dafür aus.

Jekyll anapssen

Jetzt liegt es an euch, Jekyll entsprechend den Bedürfnissen anzu passen. Heißt ein Theme herunter zu laden oder mit Plugins zu erweitern.

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)

In Zeiten steigender Energiekosten und wachsender Umweltbewusstheit suchen viele von uns nach Wegen, um den Stromverbrauch in der IT-Infrastruktur zu senken. Gerade in Heimnetzwerken und bei kleinen Servern, die rund um die Uhr laufen, kann der Energiebedarf schnell zu einer nicht unerheblichen Kostenquelle werden. Wenn du, wie ich, Proxmox nutzt, ein Open-Source-Tool zur Virtualisierung, gibt es glücklicherweise einige effektive Möglichkeiten, den Stromverbrauch deines Setups zu optimieren, ohne dabei auf Leistung zu verzichten.

In diesem Blogbeitrag teile ich vier erprobte Tipps, mit denen du deine Proxmox-Installation energieeffizienter gestalten kannst. Dabei geht es nicht nur um Hardware-Anpassungen, sondern auch um clevere Software-Optimierungen, die deine VMs und Container energieeffizienter machen. Egal, ob du ein erfahrener Proxmox-Nutzer bist oder gerade erst mit der Plattform beginnst, diese Tipps helfen dir, deine Stromrechnung zu senken und gleichzeitig einen kleinen Beitrag zum Umweltschutz zu leisten. Lass uns direkt loslegen und schauen, wie du aus deinem Proxmox-Server mehr Effizienz herausholen kannst!

Vorab: Stromverbrauch messen

Um überhaupt zu wissen wieviel Strom die Geräte verwenden sollte man diesen auch messen. Es kommt hierbei nicht auf gute Genauigkeit an, sondern um einfach mal ein Gefühl zu bekommen wieviel Strom die einzelnen Geräte so verbrauchen. Hierzu kann man sich eingünstiges Strommessgerät (externer Link) anschaffen. Beachte bitte, das bei günstigen Geräten die Genauigkeit natürlich nicht unbedingt vorhanden ist. Wer ein Smart Home sein eigen nennt, kann direkt eine Steckdose mit Strommessfunktion vor das Homelab anschließen. So hast du mittels Software immer den aktuellen Stromverbrauch.

Auf die richtige Hardware achten

Natürlich steht und fällt schlussendlich alles mit der richtigen Hardware. Alte Enterprise Hardware verbraucht natürlich viel Strom. Entsprechen sind so genannte ThinClients eine sehr gute Lösung einen energieeffizienten Server zu bauen. Ich habe diese mal in einem Video vorgestellt.

Zudem kann man auch mit den richtigen Komponenten im Selbstbau einen guten Server zusammen stellen. ImHardwareluxx Forum (externer Link) gibt es eine verlinkte Google Sheets Datei die Systeme unter 30 Watt idle Verbrauch auflistet.

Wichtig ist auch, dass bei einem selbst zusammen gestelltem PC bzw. Server es auf alle Komponenten ankommt. Es fängt bei einem effizienten Netzteil an, geht über ein gutes Mainboard bishin zur richtigen Auswahl der CPU. Gerade bei letzterem ist es so, dass Intel noch ein wenig die Nase vorne hat was einen günstigeren Stromverbrauch im idle Status angeht. Wichtig ist auch, dass Intel-CPUs mit einem “T” in der Bezeichnung nur eine geringere TDP haben. Der TDP nat erst mal nichts mit dem Stromverbrauch zu tun sondern ist die maximale Wärmeabgabe. Eine T-CPU ist also für Systeme geeignet die vollständig passiv laufen sollen. Koponenten die eher für einen hohen Stromverbrauch sprechen wären

• Grafikkarten
• RAID Controller / HBAs
• Netzwerkkarten mit mehr als 10 GBit Geschwindigkeit

Weiter unten den dem Beitrag gehe ich auf den ASPM Status ein. ASPM (Active State Power Management) bedeutet dass eine Komponente bestimmte Stromsparfunktionen erreichen kann oder nicht. Ganz grob lässt sich hier sagen, dass Enterprise-Hardware meistens nicht mit diesen Funktionen ausgestattet sind.

BIOS Einstellungen richtig setzen

Unnötige Hardware deaktivieren

Die meisten BIOS können verschiedene Geräte abschalten. Bei einem Virtualisierungshost wird zum Beispiel Audio häufig nicht gebraucht. Es wäre also dann ratsam die Soundkarte im BIOS zu deaktivieren. Ähnliches gilt für COM oder serielle Ports. Solltest du keine Grafikkarte oder andere Steckkarte die einen hohen PCI-Express Standard benötigt eingebaut haben, könntest du auch die PCIe Steckplätze z. B. von Version 4 auf 3 reduzieren. Auch dies spart gern mal das eine oder andere Watt.

ASPM aktivieren

ASPM steht für Active State Power Management und ist eine Technologie, die in Computern verwendet wird, um die Energieeffizienz von PCIe-Verbindungen zu verbessern. PCIe ist ein Hochgeschwindigkeits-Interface, das in Computern genutzt wird, um verschiedene Hardwarekomponenten wie Grafikkarten, Netzwerkkarten oder SSDs anzuschließen. ASPM zielt darauf ab, den Stromverbrauch von PCIe-Geräten zu reduzieren, indem es den Energieverbrauch in den Verbindungsleitungen zwischen der CPU (oder dem Chipsatz) und den angeschlossenen PCIe-Geräten dynamisch anpasst. Dies geschieht durch das automatische Umschalten zwischen verschiedenen Leistungszuständen, abhängig von der Auslastung und den aktuellen Anforderungen.

CPU Stromsparfunktionen aktivieren

Aktiviere im BIOS immer die C-States. Je nach Hersteller und Version solltest du bis zu C10 aktivieren können. Sei aber beruhigt wenn dein BIOS nur bis z. B. C6 konfigurierbar ist, viel Potential lässt du damit nicht liegen.

C-States

Was sind C-States

C-States, oder CPU-Schlafzustände, sind Zustände, in die eine CPU (Central Processing Unit, oder Zentraleinheit) eintreten kann, wenn sie nicht aktiv genutzt wird. Sie sind ein Teil der Leistungssteuerungsfunktionen moderner CPUs und dienen dazu, den Stromverbrauch zu reduzieren, wenn die volle Leistung der CPU nicht benötigt wird.

Es gibt verschiedene C-States, von C0 bis Cn (wobei n je nach Prozessor variiert). Hier sind einige der häufigsten:

• C0: Dies ist der Zustand, in dem die CPU aktiv ist und Aufgaben ausführt.
• C1: Dies ist ein leichter Schlafzustand, in dem die CPU schnell in den aktiven Zustand zurückkehren kann. In diesem Zustand ist die CPU nicht aktiv, aber sie kann schnell wieder in den Betrieb versetzt werden.
• C3: Dies ist ein tieferer Schlafzustand, in dem die CPU mehr Zeit benötigt, um in den aktiven Zustand zurückzukehren. In diesem Zustand werden mehr Teile der CPU abgeschaltet, was zu größerer Energieeinsparung führt.
• C6: Dies ist ein noch tieferer Schlafzustand, in dem die CPU fast vollständig abgeschaltet wird. Die CPU benötigt die längste Zeit, um aus diesem Zustand wieder in den aktiven Zustand zurückzukehren, aber es wird auch die meiste Energie gespart.

Der Wechsel zwischen diesen Zuständen wird automatisch vom Betriebssystem und der Hardware gesteuert, basierend auf der aktuellen CPU-Last und den Energieeinstellungen des Systems.

Anstreben sollte man immer den C10 Status. Bei einem Proxmox Server wirst du das aber wahrscheinlich nicht schaffen. Das System ist ja meistens dafür ausgelegt die ganze Zeit zu arbeiten. Vor allem wenn man viele virtuelle Maschinen oder LXC laufen lässt.

Mit powertop die C-States überprüfen

„powertop“ ist ein großartigesLinux Kommando mit dem du die C-States deines Servers überprüfen kannst. Gehen diese wie in diesem Beispiel nur bis zu C3, wird weiterhin viel Energie „unnötig“ verbraucht.

Häufig sind es PCI-Express Gerät die weitere C-States nicht erlauben. Mit dem Befehl

lspci -vv | awk '/ASPM/{print $0}' RS= | grep --color -P '(^[a-z0-9:.]+|ASPM )'

kannst du überprüfen ob für ein PCIe Gerät ein Active-State Power Management (ASPM) verfügbar ist. Sollte hier ein disabled dabei stehen, ist entweder die Funktion im BIOS deaktiviert oder das Gerät unterstützt diesen Modus nicht. Gerade ältere Geräte oder Enterprise Hardware wie 10G-Karten können hier ein Problem darstellen.

CPU runter Takten lassen um Proxmox Strom sparen zu lassen

Proxmox hat per default sämtliche Stromsparfunktionen deaktiviert. Diese zu aktivieren ist offiziell nicht supportet, aber natürlich funktionieren diese Systeme weiterhin. Bitte beachte, dass diese Funktion auch dazu führen kann, dass das System träger reagiert, weil Komponenten erst aufgeweckt werden müssen.

Um zu überprüfen auf welchen Modus die CPU steht, kannst du folgenden Befehl nutzen:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Hier bekommst du für jeden CPU-Kern eine Zeile zurück geliefert. Im Standard steht hier überall „performance“. Wenn du jetzt

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

verwendet, siehst du auf welcher Frequenz deine CPU Kerne derzeit arbeiten. Um diese runter takten zu lassen sollte der „scaling_govenor“ auf „powersafe“ gestellt werden. Das kannst du einmalig mit

echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

durchführen. Allerdings wird berichtet, dass bei Neustart oder Updates das wieder zurück gesetzt wird. Entsprechend habe ich mir den Befehl in die crontab eingetragen, dass dieser Befehl bei jedem reboot durchgeführt wird.

Dazu gehst du mit

crontab -e

in die Crontab Datei. Ggf. wirst du gefragt mit welchem Editor du diese öffnen möchtest. Ich empfehle dir hier „nano“.

Anschließend trägst du ganz unten folgendes ein

@reboot echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Die Datei kannst du dann mit STRG+X beenden. Bei Nachfrage ob du speichern möchtest, solltest du das natürlich bestätigen.

Anschließend kannst du mit den oben genannten Befehlen deine Eingaben überprüfen. Bei mir sieht das zur Zeit so aus:

Meine derzeitigen Einstellungen des CPU govenor und scaling {:.figcaption}

Zusatztipp

Versuche immer BIOS und alle Treiber auf den aktuellen Stand zu bringen. Auch neue Kernel-Versionen bringen häufig Verbesserungen im Bereich des Stromverbrauches. Es ist also auch hierfür ratsam seine Systeme in einem anständigem Zeitrahmen zu patchen.

Fazit

Ich habe diese Dinge selbst beachtet und konnte mit meinem Proxmox Strom sparen. Bei mir konnte ich den Verbrauch meine Servers von 36 Watt auf 24 Watt verringern. Das hört sich zwar erst einmal nicht viel an, sind aber bei uns derzeit auch knapp 52,56 Euro im Jahr. Kleinvieh macht schließlich auch Mist.

Die geeignet Hardware zu finden ist nicht immer einfach. Du kannst dich oben an der Liste aus dem Hardwareluxx-Forum orientieren. Andernfalls sind die Mitglieder im Unraid Forum (vor allem in deutschen Bereich) auch immer sehr daran interessiert ein paar Watt zu sparen. Hier kannst du auf die Suche nach guten Kombinationen für Hardware ausschau halten. Auch wenn Unraid nicht die typische Software für Virtualisierung ist.

Wer meinen Blog verfolgt weiß, dass ich seit einiger Zeit einenKubernetes Cluster verwendet habe. Dieser hat meine ganzen Anwendungen die man so im Homelab braucht gehostet. Nun bin ich auf einProxmox (externer Link) Cluster im Homelab mit Thinclients als Hardware umgestiegen.

Zum Thema Thinclients und warum diese gerade in jetzigen Zeiten eine gute Alternative für Homelabs sind, habe ich bereits mal ein Video gedreht das vielleicht ganz spannend für dich sein kann.

Grundsätzlicher Aufbau des Proxmox Clusters im Homelab

Mittlerweile nutze ich einenProxmox Cluster über drei physische Nodes. Die Hardware ist zwar leicht unterschiedlich, aber als Gesamtcluster stehen mir damit genug Ressourcen zur Verfügung.

Das Widget für Storage täuscht leider bei Proxmox immer gewaltig. Daruch, dass NFS-Freigaben eingebunden sind, werden diese mitgezählt.

Als Storage wird für die virtuellen Systeme ein Ceph-Cluster auf den gleichen Systemen ausgeführt. Für ISOs, Templates und Backups wird ein NFS-Storage von meinemUnRaid Server aus bereit gestellt.

Ein weiteres System dient alsProxmox Backup Server und soll sich hier nur um entsprechend dieses kümmern.

Welche Hardware verwende ich?

Fassen wir erst mal die Hardware des neuen Cluster zusammen, damit du schon mal eine Vorstellung des ganzen hast:

• 2 x Lenovo M900 mit Core i3-6100t, 24 GB RAM
• 2 x Lenovo M910 mit Core i5-6500t, 24 GB RAM

Alle vier Systeme sind mit einer 120 GB SATA SSD ausgestattet. Ein i3 sowie beide i5 Systeme haben zusätzlich eine500 GB NVMe SSD (externer Link) eingebaut.

Die verwendeten Netzwerkkomponenten

Netzwerkkarten

Ich verwende die eingebaute Netzwerkschnittstelle für das normale Management und VM-Netzwerk. Hierauf liegt, wie bei Proxmox üblich, eine Linux Bridge.

Zusätzlich habe ich mir insgesamt sechsUSB-Netzwerkkarten (externer Link) gekauft die mir in meinerDiscord Community (externer Link) empfohlen wurden. Jeweils zwei USB-Karten pro System, eine für das Cluster-Netzwerk und eine für Ceph.

Switch und VLANs

Alle drei Netzwerkports hängen an einemUniFi (externer Link) USW-24-G2 Switch. Das Ceph Netzwerk sowie das Cluster Netzwerk haben ihre eigene VLAN erhalten. Dies wurde so gemacht um den Datenverkehr sauber zu trennen. Grundsätzlich kann zwar alles über eine NIC transferiert werden, allerdings ist dann doch ein deutlicher Performanceunterschied zu spüren. Ceph empfiehlt sowieso schon mindestens 10 GBit Netzwerke, besser gar 40 GBit. Für ein Homelab meiner Größe natürlich viel zu überdimensioniert.

Backup mittels Proxmox Backup Server

Wie oben bereits erwähnt verwende ich denProxmox Backup Server (externer Link) als Sicherungsanwendung. Dieser soll, so vom Hersteller empfohlen über lokale Festplatten verfügen. Da mein verwendeter Thinclient aber nicht ausreichend Speicherplatz hat, habe ich mein UnRaid Server angebunden. NFS Shares sind nicht direkt als Storage anlegbar, sondern müssen via mount am System selbst hinzugefügt werden. Anschließend lässt sich das Verzeichnis als Sicherungsziel definieren.

Als retention policy verwende ich im privaten Bereich eigentlich fast immer

• 7 tägliche Sicherungen
• 4 wöchentliche Sicherungen
• 12 monatliche Sicherungen

Auf Sicherungen stündlich oder jährlich verzichte ich meist. Lediglich bei ZFS-Snapshots habe ich in der Vergangenheit auf stündliche „Sicherungen“ gesetzt.

Fazit

Der Cluster läuft noch nicht so lange. Allerdings habe ich auf ein paar Screenshots aufMastodon (externer Link) Feedback erhalten, dass man doch gerne mehr wissen möchte. Entsprechend habe ich den aktuellen Status einmal hier zusammen gefasst. Den späteren Endausbau mit den virtuellen Maschinen werde ich sicherlich noch mal präsentieren.

Vor einiger Zeit sind die neuen Heizkörperthermostate von Aqara auf den Markt gekommen: DieAqara E1 (externer Link) . Diese verwenden das ZigBee Protokoll und können so mit vielen verschiedenen Smart-Home Gateways verbunden werden, nicht nur mit dem Aqara eigenen.

Ich bin schon seit Jahren auf der Suche nach einigermaßen bezahlbaren und guten Thermostaten. Meine Lieblinge bisher waren die Eurotronics Z-Wave, leider gibt es diese nur noch in der neuen Version welche häufiger zu Problemen führen. Meine alten hingegen funktionieren nach jetzt 5 Jahren immer noch sehr gut. Batteriewechsel ist hier so alle 1,5 – 2 Jahre notwendig.

Als dieAqara E1 (externer Link) jetzt bei Amazon im Angebot waren, musste ich mir mal zwei Stück bestellen um diese auszuprobieren. Optisch kommen sie ziemlich wuchtig daher, aber ohne für mich klobig zu wirken. Das Display vorne ist natürlich nicht unbedingt für jede Montage gut geeignet. Dafür ist die Anzeige schön hell und kann so auch in einem nicht optimalen Winkel gut eingesehen werden.

Lieferumfang der Aqara E1

Im Lieferumfang befinden sich

• Das Heizkörperthermostat
• drei Adapterringe
• Anleitung

Die Anleitung ist natürlich in den gängigen Sprachen incl. Deutsch vorhanden.

Verbindung mit einem Gateway

In meinem Smart-Home werden dieAqara E1 (externer Link) mitzigbee2mqtt (externer Link) verbunden. Ich verwende dieses Gateway schon lange und ist nicht direkt mit meinerHome Assistant Instanz auf dem gleichen System. Beim Einbinden der neuen Thermostate habe ich festgestellt, dass man mindestens die Version 1.28 verwenden muss, weil vorher das Gerät nicht erkannt wurde. Stand Ende November 2022 sind wir bei Version 1.28.2, also sollte es für dich kein Problem sein, das Gerät zu betreiben.

Es werden Stand jetzt aber noch nicht alle Funktionen unterstützt die mit demAqara Hub E2 (externer Link) möglich wären. Hier können nämlich externeTemperatursensoren wie die von Aqara (externer Link) direkt verbunden werden. So wird eine realistischere Temperatur des Raumes an das Thermostat übermittelt. Ebenso die Türerkennung über die Tür- und Fenstersensoren sind noch nicht aktiv. Beides aber eine Frage der Zeit, weil es hierfür schon bereits eine aktive Entwicklung beiGitHub (externer Link) gibt.

Im Betrieb sind die Geräte ziemlich schnell. Wird die Temperatur via Software oder am Gerät geändert, stellt der Motor die Heizung direkt ein. Allerdings ist dieser bei meinen zwei Geräten nicht wirklich leise. Zwar hört man diese in 1 – 2 m Entfernung nicht mehr, aber empfindliche Menschen könnten diese doch wahrnehmen.

Zum Batterieverbrauch kann man natürlich nach zwei Wochen noch nichts sagen. Andere ZigBee Thermostate alten bei mir aber immer mindestens ein Jahr. Da ich alle mit Akkus betreibe werden diese im Sommer, wenn die Heizung eh aus ist, gerade geladen und wieder neu eingelegt.

In der kurzen Zeit machen die Geräte aber einen sehr guten Eindruck und bisher kann ich sie gut weiterempfehlen. Der Markt an smarten Heizkörperthermostaten wird in den nächsten Jahren sicherlich umkämpfter werden, da ist es gut qualitativ gute Alternativen zu haben.

Wer nicht grad unter einem Stein lebt, bekommt ein wenig die Tragik um Twitter und Elon Musk mit. Musk ist IMHO eh sehr kontrovers und die Dinge die gerade auf der Plattform passieren passen nicht jedem.

Seit einiger Zeit wechseln viele Menschen von Twitter zu Mastodon um einen anderen Microblogging-Dienst zu verwenden. Ob man die zwei Plattformen wirklich vergleichen kann sei mal dahin gestellt.

Ich für meinen Teil wollte der Plattform mal eine Chance geben. Natürlich habe ich mir dafür nicht einfach eine Instanz ausgesucht, sondern habe mir eine eigene Instanz in meinem Homelab installiert. Grundsätzlich ist das auch keine schwere Aufgabe. Leider benötigt allerdings eine Installation doch recht viel Ressourcen.

Die Standardinstallation von tootsuite benötigt

• Elasticsearch
• Postgres Datenbank
• S3 Storage
• Redis

und natürlich die normalen Container für die Software an sich.

Ob Mastodon und diese Installation langfristig für mich bestand haben wird, wird die Zeit zeigen. Ich wollte mal bis Ende des Jahres warten wie es sich entwickelt. Sollte ich dann dabei bleiben werde ich die Instanz sicherlich auf meinen VPS beiNetcup (externer Link) umziehen.

Wenn man auf den gängigen Shop-Seiten nach einer WLANWetterstation (externer Link) sucht, findet man ziemlich viele Geräte. Teilweise Smart, manche sehr einfach und manch andere messen eigentlich selbst gar nix sondern beziehen ihre Daten nur von zentralen Diensten.

Wie du vielleicht weißt, betreiben wir schon seit einigen Jahren eine eigenekleine Wetterstation in unserem Garten. Diese basierte bisher auf einer Foggit WH1080. Einem sehr gängigen System, das uns vor kurzem aber leider im Stich gelassen hatte. Die Daten wurden hier vom Außensensor immer an die Konsole übermittelt und dort von einemRaspberry Pi (externer Link) per USB ausgelesen. Die Wettersoftware weewx hat dann unsere Wetter-Webseite erstellt.

Screenshot unserer Wetter Webseite Ich musste nun eine neueWetterstation (externer Link) finden. Eigentlich wollte ich schon immer eine Davis Vantage 2 haben, allerdings ist mir diese zu kostenintensiv. Also suchte ich nach einer guten, aber günstigen Lösung. Am liebsten noch modularer als unsere bisherige. Diese hatte nämlich lediglich eine Außeneinheit, sodass die einzelnen Sensoren nicht gut platziert werden können.

Nach etwas Recherche bin ich auf die Firma Ecowitt gestoßen die gute Hardware zu vernünftigen Preisen verkauft. Natürlich kommen auch diese Sensoren nicht an die Qualität offizieller Wetterstationen heran, aber darum geht es uns auch gar nicht.

Komponenten

WLAN Wetterstation Empfänger

Das Herz ist der EmpfängerGW1100 (externer Link) der alle Signale der einzelnen Sensoren empfängt. Hier können natürlich auch alle Werte direkt in einer Weboberfläche abgefragt werden. Wer eine Konsole lieber hat, wird auch hier fündig. Wir für unseren Teil konnten auf die Konsole verzichten und nutzen lieber unsere Webseite.

Außensensor Temperatur

Der alte Sensor war leider direkt in der Sonne. Ich habe ihn zwar so positioniert, dass zumindest nicht die Mittagssonne drauf trifft, aber morgens und abends wurden die Ergebnisse doch sehr verfälscht. Durch die modulare Bauweise konnte ich den neuen TemperatursensorWH32 (externer Link) nun an die Ostseite des Hauses hängen. Allerdings auch so, dass er keine direkte Sonnenstrahlung abbekommt.

Offiziell soll ein Temperatursensor zwei Meter über den Boden in einer aktiv belüfteten Wetterhütte stehen.

Außensensor Windrichtung und -geschwindigkeit

Der WindsensorWS68 (externer Link) ist eine Einheit und besteht aus einem Sensor der die Windgeschwindigkeit misst, sowie unterhalb für die Windrichtung. Durch den Umbau konnten wir jetzt diesen Teil auch ein Stück höher hängen um ein weniger Verwirbelungen durch „nahestehende“ Pflanzen zu messen.

Der DWD gibt vor, dass der Windmesser auf mindestens 10 Meter Höhe positioniert werden muss. Zudem muss reichlich Platz zu nahestehenden Gebäuden und Pflanzen eingehalten werden.

Außensensor Regenmesser

Der Regenmesser der WH1080 war nicht wirklich gut. Wie eigentlich alle Sensoren in dieser Preisregion wird die Regenmenge durch eine Wippe berechnet. Grundsätzlich ist das kein Problem, solange man die Wippe einmal im Jahr säubert.

Leider war der Trichter der alten Station sehr klein, sodass kaum Regen direkt hinein regnete. Der neue SensorWH40 (externer Link) ist deutlich größer und kann nun Regenstärken ab 0,1 mm messen. Der alte hatte lediglich eine Genauigkeit von 0,3 mm.

Die Positionierung konnte ich auch verbessern, sodass mehr Platz um den Sensor herum ist. Zudem werde ich bei Gelegenheit noch eine Erweiterung drucken die den Rand erhöht. So kann selbst bei stärkerem Wind besser gemessen werden.

Anbindung an weewx

Das Gateway GW1100 wird ins heimische WLAN integriert (sonst wäre es ja auch keine WLAN Wetterstation 😉) und kann dann mit weewx ausgelesen werden.

Offiziell werden die Ecowitt gateways von Haus aus unterstützt. Die Community empfehlt aber einenalternativen Treiber (externer Link) zu verwenden er die Sensoren besser ausliest.

Sobald der Treiber installiert ist, kann die Wetterstation einfach in der weewx.conf Datei hinzufügt werden und die Daten werden ausgelesen.

YouTube Video

Möchtest du noch ein paar mehr Worte zu unserer WLAN Wetterstation wissen, kannst du dir gerne dieses YouTube Video auf meinem Kanal anschauen.