Greencell USV an Synology: Wenn NAS und USV nicht miteinander reden

Heute verabschieden wir uns von meiner USV. Meine alte APC Back-UPS 700 hat nach gut sechs Jahren mit einem piependen Dauerton den Dienst quittiert. Weil mein Homelab inzwischen gewachsen ist, sollte die nächste USV mehr Akku und mehr Ausgabeleistung in Watt mitbringen.
In diesem Artikel zeige ich, wie ich die neue Green Cell USV 2000VA, 1200W, Hersteller-Modell UPS05, trotzdem mit meinem NAS zusammenbringe. Das NAS erkennt das Gerät zwar, liest aber kaum brauchbare Werte aus. Die Lösung ist ein kleiner Umweg: Die USV hängt per USB an einem Mini-PC, ein NUT-Server in einem Docker-Container liest sie aus und stellt den Status über das Netzwerk bereit. Die Synology liest dann die Werte der USV per Netzwerk.
Nach den Schritten kennt die NAS den Zustand der USV wieder und kann sich rechtzeitig herunterfahren. Die Messwerte kannst du dir bei Bedarf zusätzlich in PeaNUT ansehen.
Warum die neue USV an der NAS fast nichts liefert
Die alte […]

Wenn Docker schneller als das NAS ist

Am Morgen meldete mein Backup-Tool einen Fehler, und zwar bei allen GitHub-Repositories, die es in meine selbst gehostete Forgejo-Instanz spiegeln sollte. Im Log standen ERR pkt-line 3: EOF git=push und anschließend Exiting with status=1. Mein erster Verdacht fiel auf das Tool-Image, das ich kurz zuvor aktualisiert hatte. Plausibel, schnell gedacht und komplett daneben.
Die eigentliche Ursache lag eine Schicht tiefer. Forgejo speichert seine Repositories auf der NAS, die per NFS in den Container gemountet wird. Mein Docker-Host bootete um 04:06:14, der Forgejo-Container startete um 04:06:45. Die NFS-Mounts waren erst ab 04:07:06 aktiv, der letzte sogar erst um 04:07:16. Docker war also schneller als die NAS.
Das ist eine ungünstige Reihenfolge, weil Docker Bind-Mounts beim Containerstart auflöst und fehlende Quellverzeichnisse selbst anlegt. Existiert der Mountpunkt zu diesem Zeitpunkt nur als lokales Verzeichnis, bindet Docker genau dieses leere Verzeichnis ein. Wenn NFS später erscheint, sieht der Host zwar die echten Daten, der Container bleibt […]

llama.cpp in Docker unter WSL2 mit CUDA

In diesem Guide zeige ich dir, wie ich einen lokalen, OpenAI-kompatiblen llama-server in Docker unter WSL2 mit CUDA-Beschleunigung einrichte, und nehme dich dabei vom grundlegenden Aufbau bis zum ersten funktionierenden Request mit.
Am Ende läuft ein llama-server im Container, der über WSL2 die GPU nutzt, mit genau einem Slot, also -np 1, und mindestens 128k Kontext. Ich brauche diese Größe aus eigener Erfahrung, weil ich einen Coding-Agenten wie OpenCode damit laufen lasse: Bei kleineren Kontexten kommt es zu häufigen Compactions, was das Arbeiten mühsam macht. Ein größerer Kontext wäre schön, passt aber in meinem Setup nicht mehr in den VRAM. Das Setup ist für einen einzelnen lokalen Arbeitsplatz gedacht, nicht für einen Server, an dem mehrere Nutzer gleichzeitig ihre Anfragen stellen.
Den fertigen Endpoint kann jeder Client ansprechen, der die OpenAI-kompatible API versteht, während die Modelle lokal auf deiner eigenen Maschine laufen und keine Cloud benötigen. Der lange Kontext ist dabei kein […]