Dieser Beitrag zeigt die Einrichtung Schritt für Schritt: erst die Vorbereitung auf TrueNAS, dann Installation und Konfiguration auf Proxmox.

#Die Ausgangslage

#Teil 1: TrueNAS vorbereiten

#Dataset anlegen

Unter Datasets → Add Dataset ein neues Dataset erstellen:

• Name: Proxmox-Backup
• Übergeordnetes Dataset: der Speicherpool, z. B. pve
• Dataset-Voreinstellung: Generic

Unter diesem Dataset legt das Plugin später alle ZVOLs für die VMs ab.

#iSCSI-Dienst aktivieren

System → Services, in der Zeile iSCSI auf den Play-Button klicken und Start Automatically anhaken.

#Base Name prüfen

In derselben Zeile über das Stift-Symbol die iSCSI Global Configuration öffnen. Wichtig ist hier der Base Name: Er muss mit iqn beginnen. Der Standardwert iqn.2005-10.org.freenas.ctl passt.

Den Wert notieren. Er landet später zusammen mit dem Target-Namen in der storage.cfg, im Format <Base Name>:<Target Name>.

#Target, Extent und Portal per Wizard

Unter Shares → Block (iSCSI) Shares Targets auf Wizard klicken. Der Assistent hat drei Schritte.

1. Target

Das Dropdown auf Create New lassen und einen Target-Namen vergeben, z. B. pve. Weiter.

2. Extent

• Name: beliebig
• Extent Type: Device
• Device: das ZVOL, das TrueNAS freigeben soll
• Sharing Platform: Modern OS (4K-Blockgröße, TPC an, kein Xen-Kompatibilitätsmodus, SSD-Speed)
• Read-Only: aus lassen

3. Protocol Options

• Portal: über Add ein Portal auf 0.0.0.0:3260 anlegen oder ein bestehendes wählen.
• Initiators: leer lassen bzw. Allow all initiators anhaken, damit alle Proxmox-Knoten zugreifen dürfen. Wer den Zugriff einschränken will, trägt hier die IQNs der Proxmox-Knoten ein.

Speichern, fertig.

Wer jedes Feld einzeln steuern möchte, findet den manuellen Weg über die Registerkarten Targets, Extents, Initiators, Portals und Authorized Access weiterhin unter /ui/sharing/iscsi/targets. Für den Normalfall reicht der Wizard.

#API-Schlüssel erstellen

Oben rechts im Benutzermenü (root) → My API Keys → Add. Den Schlüssel sofort kopieren, TrueNAS zeigt ihn nur ein einziges Mal an. Er kommt später als tn_api_key in die storage.cfg.

#Optional: CHAP

Wer CHAP nutzen möchte:

1. Im Wizard (Schritt 3) ein Portal wählen, dessen Discovery Auth Method auf CHAP steht.
2. Im manuellen Ablauf unter Authorized Access einen Eintrag mit Benutzer und einem 12–16 Zeichen langen Passwort anlegen.
3. In Proxmox tn_chap_user und tn_chap_password in der storage.cfg ergänzen.

#Teil 2: Proxmox einrichten

#Plugin installieren

Das Plugin kommt über das offizielle APT-Repository. Das Installskript richtet es ein:

bash <(curl -sSL https://raw.githubusercontent.com/truenas/truenas-proxmox-plugin/main/install.sh) --non-interactive --apt-install

Bei einem Cluster muss das Plugin auf jedem Knoten installiert werden.

#Storage konfigurieren

Die Konfiguration liegt in /etc/pve/storage.cfg und gilt dank Cluster-Dateisystem automatisch für alle Knoten:

nano /etc/pve/storage.cfg

Dort einen neuen Eintrag mit den Werten der eigenen TrueNAS-Umgebung ergänzen:

truenasplugin: truenas-storage
    tn_api_host 10.26.0.15
    tn_api_key <DEIN-API-SCHLÜSSEL>
    tn_api_insecure 1
    tn_target_iqn iqn.2005-10.org.freenas.ctl:pve
    tn_dataset pve/Proxmox-Backup
    tn_discovery_portal 10.26.0.15:3260
    content images,rootdir
    shared 1

Was die Zeilen bedeuten:

#Was das Plugin ab jetzt erledigt

Ab hier übernimmt das Plugin. Sobald eine VM ihre erste Disk auf dem neuen Storage bekommt:

• legt es ein ZVOL unter dem Dataset an, z. B. pve/Proxmox-Backup/vm-100-disk-0,
• erstellt dafür einen iSCSI-Extent,
• ordnet den Extent dem Target unter einer eigenen LUN zu,
• und kümmert sich auf jedem Proxmox-Knoten um Auf- und Abbau der iSCSI-Sessions.

Kein Klicken in der TrueNAS-Oberfläche mehr, keine vergessenen LUNs. Der Storage taucht in Proxmox einfach als truenas-storage auf und verhält sich wie jeder andere.

#Fazit

Die meiste Arbeit steckt in der einmaligen iSCSI-Vorbereitung auf TrueNAS. Wer auf einen gültigen Base Name, ein Portal und erlaubte Initiators achtet, umgeht die typischen Stolpersteine. Danach ist das Plugin angenehm unsichtbar.

Weitere Details, Optionen und Troubleshooting stehen im GitHub-Repository des Plugins.

Dieser Beitrag erzählt, wie es wirklich gelaufen ist. Mit allen Irrwegen, denn die waren lehrreicher als das Ergebnis.

#Die Ausgangslage

#GPUs zum Leben erwecken

lspci zeigte beide T4, aber nvidia-smi gab es nicht. Also erstmal die Treiber von Nvidia selbst herunterladen.

In diesem fall müssen wir noch das non-free im Debian Repo akivieren: /etc/apt/sources.list.d/debian.sources (deb822-Format):

Components: main contrib non-free non-free-firmware

Danach den Treiber installieren:

sudo apt update
sudo apt install linux-headers-amd64 nvidia-driver nvidia-smi firmware-misc-nonfree

Debian liefert Treiber 550.163.01 (CUDA bis 12.4). Das Kernelmodul wird per DKMS gebaut, nouveau automatisch gesperrt und das initramfs neu erzeugt. Danach ist ein Neustart fällig.

Nach dem Reboot meldete nvidia-smi beide Karten: 49 °C, 10–12 W im Leerlauf, je 15 GB frei.

#Ollama: der einfache Teil

curl -fsSL https://ollama.com/install.sh | sh

Das war's. Ollama läuft als systemd-Dienst unter eigenem Benutzer, lauscht nur auf 127.0.0.1:11434 und erkennt beide T4 per CUDA. Ein separates CUDA-Toolkit braucht es nicht, Ollama bringt seine Bibliotheken selbst mit.

#OpenClaw: ein Agent mit Persönlichkeit

OpenClaw ist ein Open-Source-Agent, der über Discord, Telegram oder WhatsApp erreichbar ist. Er kann Shell-Befehle ausführen, Dateien bearbeiten, im Web suchen und Automationen planen. Dazu gehören ein Gateway-Dienst und eine Weboberfläche.

#Erst mal Sicherheit

Mein Benutzer hat passwortloses sudo. Ein Agent, der autonom Shell-Befehle ausführt, hätte damit indirekt Root-Rechte gehabt. Keine gute Idee. Also bekam OpenClaw einen eigenen Benutzer openclaw ohne sudo und ohne Zusatzgruppen. Damit sein systemd-User-Dienst auch ohne Login läuft, wird Lingering aktiviert:

sudo useradd -m -s /bin/bash openclaw
sudo loginctl enable-linger openclaw

#Installation und Stolpersteine

Debian trixie liefert ein zu altes Node.js, also kam Node 24 von NodeSource. Das Installskript von OpenClaw habe ich vorher heruntergeladen, dann als openclaw ausgeführt. Weil /usr für diesen Benutzer nicht beschreibbar ist, landete alles in ~/.npm-global.

Beim Onboarding gab es ein paar Fallen (meine eigene Inkompetenz):

• Erst mal eine Shell öffnen und dann mich als openclaw anmelden: sudo -iu openclaw.
• Für einen systemd-User-Dienst reicht auch das oft nicht, weil keine echte Login-Session mit D-Bus existiert. Abhilfe schafft sudo machinectl shell openclaw@ (Paket systemd-container).
• Ich habe sudo machinectl … natürlich erst mal als openclaw probiert. Der hat bewusst kein sudo. Also exit und noch mal mit meinem User:mace.
• „Gateway not detected yet“: Der Gateway braucht rund 30 Sekunden zum Starten, das Onboarding gibt vorher auf. Er lief trotzdem.

Als Modelle kamen qwen3:30b (18 GB) und gemma4:e4b (6,6 GB) auf die Platte. Was ich da noch nicht wusste: qwen3:30b ist bei Ollama die Thinking-Variante. Das wird später wichtig.

#Jarvis bekommt einen Charakter

OpenClaw liest bei jedem Sitzungsstart Dateien aus seinem Workspace: AGENTS.md, SOUL.md, IDENTITY.md und USER.md. Mein Agent heißt Jarvis, ist ein lockerer Typ, spricht Deutsch und duzt. In SOUL.md steht: direkt, ehrlich, trockener Humor, „erst die Lösung, dann der Spruch“. Die Sicherheitsgrenzen bleiben: private Daten schützen und vor riskanten Aktionen fragen.

#Die Weboberfläche und der Basic-Auth-Albtraum

Die Weboberfläche sollte im LAN erreichbar sein, später auch über NetBird, und natürlich mit Passwort.

Der Aufbau: Der OpenClaw-Gateway bleibt auf 127.0.0.1:18789 und ist nie direkt im Netz. Davor sitzt Caddy als Reverse Proxy mit selbst signiertem Zertifikat (tls internal). HTTP leitet automatisch auf HTTPS um. In OpenClaw kommen die neuen Adressen in gateway.controlUi.allowedOrigins, dazu gateway.trustedProxies: ["127.0.0.1"].

Dann sollte noch Basic Auth davor. Klingt trivial. Die Passwortabfrage kam aber immer wieder, egal was ich eingab. Die Fehlersuche lief über das Access-Log von Caddy:

1. WebSockets und /healthz kamen ohne Zugangsdaten an. Chromium schickt bei WebSocket-Verbindungen kein Basic Auth mit. Also eine Ausnahme dafür.
2. Anfragen mit Authorization-Header wurden trotzdem abgelehnt. Die OpenClaw-Oberfläche schickt bei API-Aufrufen Authorization: Bearer <Token>. Das ist derselbe Header wie bei Basic Auth, und ein Browser kann nur einen davon senden. Also noch eine Ausnahme für Bearer-Anfragen. Der Gateway prüft das Token ja selbst.
3. Immer noch Abfragen. An der Stelle habe ich entschieden: Der Passwortschutz fliegt raus. Caddy macht nur noch HTTPS, geschützt wird über das Gateway-Token und die Gerätefreigabe in OpenClaw.

#„Warum erzählt der so viel Müll?“

Jetzt kam der eigentliche Test. Ich fragte Jarvis: „Was macht die Thomas-Krenn.AG?“

Richtig wäre: ein Serverhersteller aus Freyung im Bayerischen Wald, bekannt für individuell konfigurierte Server, einen Online-Konfigurator und das Thomas-Krenn-Wiki.

Jarvis wusste es anders. Erst sei das wohl ein Tippfehler und Thomas Krenn ein IT-Sicherheitsexperte und Linux-Blogger. Auf „du liegst falsch“ war es plötzlich ein Serverhersteller, die „Thomas Krenn GmbH“. Auf „ist eine AG“ stimmte er sofort zu und erklärte mir den Unterschied zwischen AG und GmbH. Später kamen Rechenzentren in München, Frankfurt und Wien dazu, eine Gründung 1985 in Ludwigshafen und Pentests für Banken.

Klassisches Halluzinieren, garniert mit unkritischem Zustimmen. Also auf Fehlersuche.

#Ursache 1: Das Kontextfenster war zu klein

Im Gateway-Log stand:

route=compact_only estimatedPromptTokens=26176 promptBudgetBeforeReserve=24576

OpenClaw hatte das Modell auf 32 768 Tokens begrenzt, obwohl Qwen3 über 260 000 kann. Allein Systemprompt und Tools brauchten rund 26 000. Jede Anfrage wurde also zusammengestrichen, bevor das Modell überhaupt meine Frage sah.

Der Fix: contextTokens für das Modell auf 65.536 hochsetzen und Ollama per systemd-Override etwas tunen:

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KEEP_ALIVE=30m"

Ergebnis: 26 GB VRAM über beide GPUs verteilt, 100 % GPU, rund 75 Tokens pro Sekunde.

#Ursache 2: Ein riesiger Systemprompt

Mit /context detail zeigt OpenClaw, woraus der Prompt besteht:

Dabei fiel etwas Absurdes auf: IDENTITY.md war von 215 auf 4 415 Zeichen gewachsen. Ich hatte über die Weboberfläche ein Avatarbild gesetzt, und die UI hatte das Bild als Base64 direkt in die Datei geschrieben. Das waren rund 1 100 Tokens Bilddaten in jedem einzelnen Prompt. Das Bild liegt jetzt als Datei daneben, in IDENTITY.md steht nur noch der Pfad.

Danach habe ich per tools.deny alles entfernt, was auf einem Server ohne Bildschirm nichts bringt: Desktop-, Browser-, Canvas- und Sprach-Tools, dazu die Sub-Agenten (Ollama verarbeitet ohnehin nur eine Anfrage gleichzeitig). Ergebnis: ~18 700 statt ~28 300 Tokens, gut ein Drittel weniger.

#Mehr RAM bringt keinen größeren Kontext

Mein erster Gedanke: Der Host hat noch 400 GB RAM frei, die gebe ich der VM einfach. Leider hilft das kaum. Passt der Kontext nicht mehr in den VRAM, lagert Ollama Teile auf die CPU aus. Dann bricht die Geschwindigkeit ein, von 75 auf geschätzt 10–25 Tokens pro Sekunde, und das Einlesen langer Prompts wird noch viel zäher.

Der bessere Weg ist, den KV-Cache zu quantisieren. Mit OLLAMA_KV_CACHE_TYPE=q8_0 (setzt Flash Attention voraus) braucht der Cache nur noch rund die Hälfte:

Mit 128k Kontext läuft alles weiter komplett auf den GPUs: 26 GB VRAM, rund 63 Tokens pro Sekunde.

#Ursache 3: Das Thinking-Modell „verdenkt“ den Tool-Aufruf

Die Antworten waren trotzdem Unsinn. Also ging es in die SQLite-Datenbank von OpenClaw, wo die Verläufe der Sitzungen liegen. Im Denkprozess des Modells stand sinngemäß: „Ich sollte jetzt web_search mit ‚Thomas-Krenn.AG‘ aufrufen.“ Danach beendete es den Zug, ohne den Aufruf tatsächlich zu senden (non_deliverable_terminal_turn). OpenClaw erzwang dann eine Antwort ohne Tools, und das Modell fing an zu fantasieren.

Die Lösung war der Wechsel auf qwen3:30b-a3b-instruct-2507-q4_K_M: gleiche Größe, kein Thinking. Interessant: In einem direkten Test gegen die Ollama-API mit einem einzigen web_search-Tool lieferten beide Varianten 3 von 3 korrekte Aufrufe. Das Problem trat nur im großen OpenClaw-Kontext auf.

#Ursache 4: Falsche Tools, falscher Kanal

Das Instruct-Modell antwortete erst mal ganz ohne Suche. Also kam eine Regel in SOUL.md: Fakten: erst suchen, dann reden. Bei Firmen, Personen, Produkten, Preisen und allem Aktuellen immer zuerst web_search, Quelle nennen, bei Korrekturen erst nachprüfen.

Danach wurde es kurios:

• Jarvis rief tool_search mit „Thomas-Krenn AG company overview“ auf. Ergebnis: eine leere Liste. tool_search durchsucht aber nicht das Web, sondern OpenClaws eigenen Werkzeugkatalog. Das echte web_search war hinter der Tool-Suche versteckt.
• Mit abgeschalteter Tool-Suche griff er zum Tool intent, das Daueraufträge anlegt. Das scheiterte mit „authenticated sender identity is unavailable“.
• Fragte ich ihn nach seinen Tools, nannte er nur Nachrichten- und Sitzungs-Tools. web_search, read und exec fehlten komplett.
• Am Ende stellte er Rückfragen, brauchte über drei Minuten und schickte die Antwort auf eine Frage aus der Weboberfläche nach Discord.

Und dann gab es noch einen peinlichen Zwischenfall. Ich hatte Jarvis zum Testen über die Kommandozeile (openclaw agent) angesprochen. Dabei gab es keinen festen Antwortkanal, also nutzte Jarvis sein message-Tool und postete die Antworten schon wieder in einen zufälligen Discord-Channel. Danach war mit CLI-Tests Schluss.

#Die Einsicht: falsches Werkzeug für lokale Modelle

OpenClaw ist für starke Cloud-Modelle wie Claude oder GPT gebaut: ein riesiger Systemprompt, Dutzende Tools, Kanäle, Automationen, Tool-Suche, Regeln für Absender und Besitzer. Ein lokales 30B-Modell ist mit dieser Komplexität überfordert. Und die Tool-Logik war selbst für mich kaum zu durchschauen. Meine Vermutung, nicht bestätigt: Die Sitzung aus der Weboberfläche wurde nicht als Besitzer erkannt, weil nur meine Discord-ID hinterlegt war.

Am Ende standen drei Optionen auf dem Tisch:

• A: Open WebUI als lokales „ChatGPT“ mit Websuche und echten Benutzerkonten
• B: OpenClaw mit einem Cloud-Modell. Das kostet Geld, und die Daten verlassen das Haus.
• C: Weiter debuggen, mit ungewissem Ausgang

Ich habe mich für A entschieden und OpenClaw komplett vom Server entfernt: Dienst gestoppt, Lingering aus, Benutzer samt Home gelöscht, Logs weg, Node.js, das NodeSource-Repo und systemd-container deinstalliert. Eine abschließende Suche fand keine Reste.

#Open WebUI: „Juhuuuuu“

Open WebUI läuft als Docker-Container. Docker kommt direkt aus Debian (docker.io):

sudo apt install docker.io

sudo docker run -d --name open-webui \
  --restart unless-stopped \
  --network host \
  -v open-webui:/app/backend/data \
  -e PORT=8080 \
  -e HOST=127.0.0.1 \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -e WEBUI_SECRET_KEY=<ein-langer-zufälliger-wert> \
  -e WEBUI_NAME=AI-01 \
  -e DEFAULT_USER_ROLE=pending \
  -e ENABLE_WEB_SEARCH=true \
  -e WEB_SEARCH_ENGINE=duckduckgo \
  -e WEB_SEARCH_RESULT_COUNT=5 \
  -e ANONYMIZED_TELEMETRY=false \
  ghcr.io/open-webui/open-webui:main

Die wichtigsten Punkte:

• Der Container lauscht nur auf 127.0.0.1:8080 und ist von außen nicht erreichbar. Caddy zeigt jetzt dorthin, mit HTTPS und einem Upload-Limit von 200 MB.
• Neue Benutzer können sich registrieren, landen aber im Status „pending“, bis ich sie freischalte.
• Die Websuche läuft über DuckDuckGo, ganz ohne API-Key.

Dann kam dieselbe Frage, mit demselben Modell auf derselben Hardware: „Was macht die Thomas-Krenn.AG?“

Das Modell rief selbstständig die Websuche auf und antwortete im Kern richtig: Sitz in Freyung, individuell konfigurierte Server, Tests vor der Auslieferung, „Servers Made in Germany“. Meine Reaktion im Chat war ein schlichtes „Juhuuuuu“.

Das ist für mich die wichtigste Erkenntnis aus dem ganzen Projekt: Das Modell war nie das Problem. Mit einem schlanken Frontend, das sich auf Chat und Websuche konzentriert, funktioniert es. Mit einem überladenen Agenten-Framework nicht.

#Nebenschauplätze

#Programmieren mit dem eigenen Modell

Cursor erlaubt zwar eine eigene OpenAI-kompatible Adresse, schickt die Anfragen aber über die eigenen Server. Eine Adresse im LAN ist von dort nicht erreichbar, man müsste den KI-Server öffentlich ins Internet stellen. Das will ich nicht.

Besser passt VS Code mit der Erweiterung Continue (oder Cline). Die spricht direkt vom PC aus die OpenAI-kompatible API von Open WebUI unter https://<server>/api an, mit einem persönlichen API-Key. Die Keys muss der Admin in Open WebUI erst freigeben. Wegen des selbst signierten Zertifikats importiert man die Root-CA von Caddy auf dem PC oder schaltet die Zertifikatsprüfung in Continue ab.

Für Code ist qwen3-coder:30b die bessere Wahl. Es ist genauso groß und passt ebenfalls auf die beiden T4.

#Der Endstand

Auf der Liste steht noch: NetBird auf der VM einrichten, die Registrierung in Open WebUI eventuell ganz abschalten, qwen3-coder mit Continue ausprobieren und die ungenutzten Modelle löschen. Das sind rund 25 GB.

#Was ich gelernt habe

1. Agenten nie mit sudo: Ein autonomer Agent bekommt einen eigenen Benutzer ohne Rechte.
2. Basic Auth und moderne Web-Apps vertragen sich nicht.
3. Kontextgröße prüfen: Frameworks setzen oft vorsichtige Standardwerte. Hier waren es 32k, und das Modell sah nur einen Bruchteil seiner Anweisungen.
4. Mehr RAM heißt nicht mehr Kontext. Ein quantisierter KV-Cache (q8_0) verdoppelt den Kontext im selben VRAM, fast ohne Verlust.
5. Base64-Bilder in Prompt-Dateien fressen still und leise Tokens.
6. Thinking-Modelle können Tool-Aufrufe „verdenken“. Für Tools lieber die Instruct-Variante nehmen.
7. Lokale Modelle und überladene Frameworks ergeben Halluzinationen. Weniger Tools und eine klare Oberfläche bringen bessere Ergebnisse.
8. Logs lesen statt raten: Die echten Ursachen standen im Gateway-Log und in der Sitzungsdatenbank, nicht in der Doku.
9. Manchmal ist das Werkzeug falsch, nicht die Konfiguration. Open WebUI lief auf Anhieb.

Unterm Strich habe ich jetzt ein eigenes, lokales ChatGPT für mich und ein paar Leute, das weiß, wann es nachschauen muss. Und Jarvis? Der ist erst mal in Rente. Vielleicht kommt er wieder, wenn lokale Modelle groß genug für ihn sind.

#Versuch 1: git describe

Die Idee war simpel. Ich tagge Releases sowieso mit v1.0.x, also kann der Build die Version direkt aus Git holen:

function siteVersion() {
  try {
    return execFileSync('git', ['describe', '--tags', '--always'], { cwd: ROOT })
      .toString().trim();
  } catch {
    return `v${JSON.parse(fs.readFileSync('package.json', 'utf8')).version}`;
  }
}

git describe --tags ist dafür praktisch: Steht der Build genau auf einem Tag, kommt v1.0.4 raus. Gibt es danach noch Commits, wird daraus etwas wie v1.0.4-2-gabc1234, also „zwei Commits nach v1.0.4, aktueller Stand abc1234“. Für den Notfall gibt es noch einen Fallback auf die Version aus der package.json.

Lokal sah das super aus. Commit, Push, fertig.

#Live: v1.0.0

Auf der echten Seite stand im Footer: v1.0.0. Das war die Version, die seit dem allerersten Commit unverändert in der package.json stand.

Der Grund: Meine Seite wird nicht lokal gebaut, sondern auf dem Server. Ein git push nach GitLab löst einen Webhook aus, Plesk holt sich den Stand und baut die Seite. Nur legt Plesk die Dateien in httpdocs/ ab, ohne .git-Verzeichnis. git describe hatte dort also gar kein Repository, ist fehlgeschlagen und der Fallback hat leise übernommen.

#Versuch 2: Dann eben package.json

Einige Minuten später der nächste Commit: Weg mit Git, die Version kommt ab jetzt nur noch aus der package.json. Neue Releases mache ich mit npm version:

npm version patch                   # 1.0.4 → 1.0.5, mit Commit und Tag
git push --follow-tags origin main

npm version erhöht die Nummer, committet und setzt den passenden Git-Tag in einem Schritt. Das funktioniert und ist robust. Aber es fühlte sich wie ein Rückschritt an. Zwischenstände wie v1.0.4-2-gabc1234 sind weg, und vergesse ich das Release, zeigt der Footer wochenlang eine veraltete Nummer.

#Versuch 3: Das Repo suchen

Also nochmal genauer hingeschaut. Plesk hat das Repository ja irgendwo, sonst könnte es nicht pullen. Gefunden! Es liegt als Bare-Repo unter ~/git/, also nur die Git-Daten ohne ausgecheckte Dateien. Und git describe braucht genau das, keine Arbeitskopie.

Mit --git-dir kann man Git sagen, wo das Repository liegt:

for (const gitDir of [undefined, ...pleskRepos()]) {
  try {
    const v = describe(gitDir);
    return { version: v, source: gitDir ? `git (${gitDir})` : 'git' };
  } catch { /* nächste Quelle */ }
}
return { version: pkg, source: 'package.json' };

Zuerst das Projektverzeichnis selbst (lokal), dann alle *.git-Ordner unter ~/git/, wobei Repos mit „themace“ im Namen nach vorne sortiert werden. Erst wenn nichts klappt, kommt die package.json.

#Bonus-Stolperstein: „dubious ownership“

Seit einer Weile weigert sich Git, in Repositories zu arbeiten, die einem anderen Benutzer gehören. Das ist ein Sicherheitsfeature gegen manipulierte Repos auf geteilten Systemen. Auf dem Server gehört das Bare-Repo aber nicht unbedingt dem Benutzer, der den Build ausführt. Die Lösung für diesen einen Aufruf:

git -c safe.directory=* --git-dir ~/git/themace-de.git describe --tags --always

#Die eigentliche Lektion: Fallbacks müssen laut sein

Das Spannendste an der Geschichte ist nicht Git und nicht Plesk. Mein erster Versuch war eigentlich richtig. Er hatte nur einen Fallback, der still war. Die Seite lief, nichts ist abgestürzt, und trotzdem war das Ergebnis falsch.

Deshalb schreibt der Build jetzt ins Deploy-Log, woher die Version kommt:

→ Version v1.0.4 (aus git (/var/www/vhosts/.../git/themace-de.git))

Steht da (aus package.json), weiß ich sofort, dass etwas nicht stimmt. Eine Zeile Log hätte mir zwei Commits erspart.

#Fazit

Drei Commits für eine Versionsnummer im Footer. Was ich mitnehme:

• Lokal ist nicht gleich Server. Was auf meinem Rechner ein Git-Repo ist, ist auf dem Server nur ein Ordner mit Dateien.
• Bare-Repos reichen für Git-Abfragen. --git-dir ist dein Freund.
• Ein Fallback ohne Log ist ein versteckter Bug. Wenn der Plan B greift, will ich das wissen.

Und ja: Die Versionsnummer steht jetzt unten im Footer. Schau ruhig mal nach. 👇

#Warum gibt es überhaupt Cookie-Banner?

Kurz gesagt: Eine Website darf ohne deine Einwilligung nichts auf deinem Gerät speichern oder auslesen, außer es ist für die Funktion, die du willst, unbedingt nötig. In Deutschland steht das in § 25 TDDDG. Sobald Daten an Dritte gehen, kommt dazu noch die DSGVO.

Das heißt im Umkehrschluss: Ein Banner braucht nur, wer Dinge tut, die eine Einwilligung brauchen. Tracking, Werbung, eingebettete Inhalte von fremden Servern. Wer das alles weglässt, braucht auch kein Banner.

Klingt banal. Die Arbeit steckt im Detail, denn viele Seiten laden Drittanbieter, ohne dass es dem Betreiber bewusst ist.

#1. Kein Tracking, keine Analyse

Der einfachste Schritt: Ich habe kein Google Analytics, kein Matomo, kein Plausible eingebaut. Ich weiß ehrlich gesagt nicht, wie viele Leute hier mitlesen. Und das ist okay.

Die Server-Logs gibt es trotzdem, weil ein Webserver ohne sie nicht vernünftig betrieben werden kann. Sie werden aber nicht ausgewertet und nach spätestens sieben Tagen gelöscht.

Es kann natürlich sein, dass ich mir irgendwann denke: „Ja komm, ich will schon wissen, wie viele hier mitlesen.“ Dann baue ich vielleicht Matomo oder etwas Ähnliches ein. Und dann bräuchte es wahrscheinlich auch wieder ein Banner.

#2. Schriften selbst hosten

Das ist der Klassiker. Google Fonts per <link> einzubinden ist bequem, aber dabei baut der Browser eine Verbindung zu Google auf und überträgt deine IP-Adresse. Genau das hat 2022 eine ganze Abmahnwelle ausgelöst.

Auf TheMace.de liegen alle Schriften auf dem eigenen Server. Ein kleines Skript im Build (lib/fonts.js) holt sich Archivo, Inter, JetBrains Mono und Fraunces aus den Fontsource-Paketen von npm, kopiert die Dateien nach dist/fonts/ und erzeugt eine passende fonts.css.

Dabei gleich ein paar Optimierungen:

• Nur Latin und Latin-Extended. Kyrillisch, Griechisch und Vietnamesisch brauche ich hier nicht, also werden sie gar nicht erst ausgeliefert.
• Variable Fonts. Eine Datei pro Schrift statt einer pro Schriftschnitt.
• Preload für die beiden Schriften, die sofort sichtbar sind, damit nichts flackert.

#3. Keine eingebetteten Inhalte

Kein YouTube-Video, keine Twitter-Timeline, kein Discord-Widget, keine Karten von Google Maps. Jedes dieser Embeds lädt Code von fremden Servern und braucht damit eine Einwilligung.

Stattdessen gibt es ganz normale Links. Auf GitHub, Discord und Co. landest du nur, wenn du selbst klickst. Erst ab dann gelten deren Regeln.

#4. Alles vom eigenen Server

Auch sonst kommt nichts von außen: Kein CDN für JavaScript, keine Icon-Fonts, keine externen Bilder. CSS wird im fertigen Build sogar direkt ins HTML eingebettet. Das ist gut für den Datenschutz und nebenbei auch schneller.

Prüfen kannst du das selbst: Öffne die Entwicklertools (F12), wechsle zum Tab Netzwerk und lade die Seite neu. Jede Anfrage sollte an themace.de gehen.

#5. Und was ist mit dem Dark Mode?

Eine Ausnahme gibt es: Wenn du oben zwischen hell und dunkel wechselst, merkt sich die Seite das im localStorage deines Browsers.

try { localStorage.setItem('theme', next); } catch (e) {}

Das ist erlaubt, weil es genau die Funktion ist, die du gerade angeklickt hast. Ohne Speichern würde die Seite deine Wahl beim nächsten Aufruf vergessen. Der Wert bleibt auf deinem Gerät und wird nie an den Server geschickt. Gespeichert wird übrigens nur, wenn du selbst umschaltest.

#Bonus: E-Mail-Adressen verstecken

Mit Cookies hat das nichts zu tun, aber es gehört zum selben Gedanken: Ich möchte dich nicht ausspionieren, und ich möchte selbst nicht zugespammt werden. Deshalb stehen E-Mail-Adressen nicht im Klartext im HTML. Ein Schritt im Build kodiert sie, und erst im Browser werden sie wieder zu einem klickbaren Link. Für Menschen ändert sich nichts, Bots, die nur den Quelltext durchsuchen, finden nichts.

#Fazit

Eine Seite ohne Cookie-Banner ist kein großes Projekt. Es ist eher eine Reihe von Dingen, die man nicht macht:

• kein Tracking
• keine Schriften, Skripte oder Bilder von fremden Servern
• keine Embeds

Was übrig bleibt, ist eine schnelle Seite, eine kurze Datenschutzerklärung und Besucher, die einfach lesen können, ohne vorher etwas wegzuklicken.

#Warum eine eigene Seite?

Social-Media-Plattformen kommen und gehen. Eine eigene Domain bleibt. Hier gehört alles mir: das Design, die Inhalte und die Entscheidung, kein Tracking einzubauen.

Schreib Dinge auf. Dein zukünftiges Ich wird es dir danken.

#Was dich hier erwartet

• Notizen zu Projekten, an denen ich gerade arbeite
• Anleitungen zu Linux, Self-Hosting und Webentwicklung
• Gedanken zu Design und Werkzeugen
• Ab und zu etwas völlig anderes

#Wie geht es weiter?

Ich versuche, regelmäßig zu schreiben. Wenn du nichts verpassen willst, abonniere einfach den RSS-Feed.

Bis bald!