@@ -49,6 +49,8 @@ Vorgehen pro Baustein: **Spec → Implementierung → Tests → Commit**. Bis zu
## Gemeinsames Deployment (später)
> **Abgelöst** durch [docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort steht der Ablauf auf der echten Hardware, zusammengeführt mit Planner Epic 7. Die Liste unten bleibt nur zur Nachvollziehbarkeit stehen.
1. Inventarlauf auf allen Nodes → `sites/knaster/inventory.yaml` ergänzen → `knaster placement plan`
@@ -279,6 +279,8 @@ Die Portabilität beruht also auf den **Daten und der Pipeline**, nicht auf Gewi
## 8. Roadmap
> **Abgelöst** durch [superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort ist der chronologische Ablauf auf der echten Hardware beschrieben, mit den Entscheidungen D1–D5 und der Zuordnung zu Planner Epic 7. Die Tabelle unten bleibt nur zur Nachvollziehbarkeit stehen (Zuordnung: 0 → Phasen 0–5, 1 → 6, 2 → 7, 3–6 → 9).
| Phase | Inhalt | Fertig, wenn … |
|---|---|---|
| **0 Fundament** | Proxmox-Templates, Resource Mappings, OpenTofu/Ansible, Monitoring-Stack | eine GPU-VM lässt sich per Code neu erzeugen, Grafana zeigt GPU- und Proxmox-Metriken |
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Die fünf installierten Proxmox-Knoten werden Schritt für Schritt zum Cluster „knaster“ ausgebaut, auf dem die Architektur aus `docs/PLAN.md` läuft. Grundlage sind die echte Hardware und die Aufgaben aus Planner Epic 7.
**Architecture:** Fünf Proxmox-Knoten mit ZFS bilden einen Cluster. Jeder GPU-Knoten bekommt **eine** Ubuntu-VM, an die alle seine Karten durchgereicht werden; darin laufen Docker-Container pro Rolle. Die Infrastruktur (Router, Postgres, Monitoring) läuft als LXC mit Docker und HA. Die beiden RTX-4000-Ada-Rechner bleiben Windows-Arbeitsplätze und stellen ihre Leistung über die vorhandene Worker-Registry v2 bereit. Starke Modelle laufen ausschließlich über den LiteLLM mit PSE auf appsrv08.
-`C:\Users\r.rapp\it\proxmox\STAND-2026-10-08.md` und `healthcheck-2026-10-08.txt` (Ist-Stand der Knoten)
- Repo `mygodel/nex`: `docs/plans/2026-10-07-nex-stt-gpu.md` (Whisper im Haus), `docs/plans/2026-09-29-nex-worker-registry-v2.md` (Ada-Worker)
Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `docs/IMPLEMENTATION.md` („Gemeinsames Deployment“) **ab**. Deren Phasen sind unten zugeordnet.
| pve61 | 192.168.100.214 | Surface Book, i5-8350U, 8 GB | 1× 256 GB NVMe | Intel UHD 620 | LAN nur über USB-NIC im Lenovo-Dock, 2 Akkus |
Alle Knoten: PVE 9.2.2, Kernel 7.0.2, **ext4 + LVM-thin auf einer SSD (kein ZFS)**, 1 GbE, kein Cluster. VT-x und VT-d sind aktiv. IOMMU ist geprüft: Jede Karte liegt mit ihrer Audio-Funktion in einer eigenen Gruppe (M4000 in Gruppe 1, P2000 in Gruppe 8), Passthrough ist also möglich.
Außerhalb des Clusters:
- **GODE-PC-05/06:** je eine RTX 4000 Ada mit 20 GB, Windows, tagsüber Arbeitsplätze. Sie laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`).
- **appsrv08 (.29):** GRP produktiv, NEX und LiteLLM mit PSE-Filter.
- **n8n:** n8n.mindboost.app.
- **Gitea:** gitea.mindboost.team.
---
## Global Constraints
- **Starke Modelle (tier0, OpenRouter) nur über den LiteLLM mit PSE auf appsrv08.** Kein zweiter Gateway-Weg nach außen, sonst wird die Pseudonymisierung umgangen (Epic 7 „LiteLLM Swarm: PSE-Fix“).
- **Netz:** flach `192.168.100.0/24`, Gateway `.1`, DNS `.120`. Feste IP-Literale, kein DNS-Name in Konfigurationen, vorerst kein VLAN.
- **Container zuerst:** Dienste laufen als Docker-Container, in LXC oder in einer VM. Eine VM gibt es nur dort, wo sie ein Treiberproblem löst (GPU-VM pro Knoten, D2) oder ein Produkt sie verlangt.
- **Dry-Run:** Alle knaster-Aktionen gegen Infrastruktur starten mit `KNASTER_DRY_RUN=true` und werden erst nach einer Woche Beobachtung einzeln freigeschaltet.
- **STT:** `whisper-server` auf Port 8178, nur von `192.168.100.29` erreichbar. `stt.openai.base_url` nur als IP-Literal (nex-STT-Plan, Annahmen).
- **Ada-Rechner:** Windows bleibt, Mitarbeitende haben tagsüber Vorrang, kein Proxmox darauf.
- **Datacenter-weite Einstellungen** (Benutzer, 2FA, Firewall, Benachrichtigungen, Pools, Metriken) erst, wenn alle Knoten im Cluster sind.
- **Alte Windows-SSDs** (pve44 sdb, pve52 sdb) nur nach ausdrücklicher Freigabe löschen (D1).
- **Geheimnisse** nie ins Repo. Zugangsdaten liegen in `C:\Users\r.rapp\it\proxmox\.env`, der Schlüssel unter `…\proxmox\keys\`.
- **Planner-Webhook `tdo-codex-update`:** pro Aufruf nur **eine** Aktualisierung, vorhandene Titel nie umbenennen (Abgleich läuft über den Titel, Schwelle 0.8).
## Review Focus
1.**Eine Neuinstallation löscht die Einrichtung vom 08.10.** Betroffen sind Schlüssel, Paketquellen, Dock-Bindung und SSH-Hostschlüssel. Erwartung: Das Bootstrap-Skript stellt alles wieder her, und `ssh -o BatchMode=yes pveXX hostname` klappt danach ohne Nachfrage (Task 1.1, Test im Skript).
2.**Der Cluster-Beitritt ersetzt `authorized_keys`.** Erwartung: Nach jedem `pvecm add` funktioniert der Laptop-Zugang auf allen Knoten weiter (Task 2.1, Prüfschritt).
3.**Die USB-NIC von pve61 verschwindet nach einem Stromausfall oder einem Umstecken des Docks.** Erwartung: `vmbr0` hängt danach wieder an der Karte, ohne Eingriff (Task 1.3, Test: Dock aus- und einstecken).
4.**Ein Ada-Worker ist tagsüber belegt oder aus.** Erwartung: tier1-Anfragen landen ohne Fehler bei tier0 über PSE (Task 6.4, Unit-Test im Router).
5.**Die Rolle `pve-host` sperrt NVIDIA und setzt VFIO.** Erwartung: Das passiert nur auf GPU-Knoten. pve61 behält seine iGPU für den Kiosk (Task 3.1, Ansible-Gruppen, Prüfung `lspci -k`).
---
## Entscheidungen (vor der jeweiligen Phase bestätigen)
| **D1** | Speicher | **Alle Knoten mit ZFS neu installieren:** RAID1 auf Knoten mit zwei SSDs (pve44, pve52, ggf. pve48), Einzel-ZFS auf pve46 und pve61. Gast-Speicher ist überall `local-zfs`. | Es steht noch nichts auf den Knoten, ein Neuaufbau kostet etwa 30 Min. pro Knoten. Gleicher Speichername überall ermöglicht Replikation und HA zwischen beliebigen Knoten. Dazu kommen Snapshots und Ausfallsicherheit der Systemplatte. pve46 kommt dabei auf UEFI. Das Video empfiehlt ZFS RAID1. Kapazität: 256 GB je Knoten reichen für das Speicherbudget aus PLAN §1.4. | Kein Neuaufbau: SSD2 als Einzel-ZFS `tank` nur auf pve44 und pve52, Replikation nur zwischen diesen beiden. pve46 und pve61 bleiben ohne ZFS. |
| **D2** | GPU als VM oder LXC | **Pro GPU-Knoten eine Ubuntu-24.04-VM mit allen Karten des Knotens**, darin Docker Compose pro Rolle. | Der Host-Kernel (7.0) bleibt ohne NVIDIA, Proxmox-Updates gefährden den Treiber nicht. R580 kommt als Ubuntu-Paket und ist per Snapshot rückrollbar. IOMMU-Gruppen sind geprüft. Eine VM pro Knoten statt pro Rolle (ADR-0001) spart RAM. Das Argument „gemischte Generationen“ aus ADR-0001 gilt im Cluster nicht mehr, alle Karten sind Maxwell/Pascal. Kosten: 2–5 % CPU, fest reservierter VM-RAM (12–16 GB von 32 GB). | LXC mit Host-Treiber: braucht R580 auf Kernel 7.0 oder einen festgehaltenen älteren Kernel. |
| **D3** | Ada-Rechner | **Windows bleibt.**`LocalLLMWorker.ps1` mit llama-server (CUDA) meldet sich über die Worker-Registry v2. Die knaster-Slots `tier1-general`/`tier1-flex` lösen auf einen Worker auf, der online ist, sonst tier0. | Die Registry v2 ist fast fertig (44 von 55 Schritten). Mitarbeitende werden nicht gestört. vLLM läuft unter Windows nicht nativ, Multi-LoRA, QLoRA und Qwen3-TTS kommen deshalb erst mit einer späteren WSL2-Entscheidung (Phase 9). | Dual-Boot mit Proxmox: scheidet aus, die Rechner werden tagsüber genutzt. |
| **D4** | LiteLLM | **Kein eigener LiteLLM im knaster-Infra.** Der Router nutzt den LiteLLM auf appsrv08 (mit PSE), die lokalen Slots werden dort als Modelle eingetragen. | Es läuft bereits ein dritter LiteLLM; noch einer würde PSE für tier0 umgehen. Ein Modellwechsel bleibt eine Datenänderung. | Eigener LiteLLM nur für lokale Slots, ohne OpenRouter-Zugang. |
| **D5** | IP-Plan | **Knoten behalten .207–.214.** Gäste bekommen einen festen Block außerhalb des DHCP-Bereichs. Vorschlag `.220–.239`, wird in Task 0.3 gegen den DHCP-Bereich geprüft. | Die STT-Konfiguration braucht IP-Literale. Die alten GODEL-DNS-Einträge zeigen, dass die Knoten-IPs aus DHCP stammen, deshalb Reservierungen anlegen. | VLAN `svc` (PLAN §1.4) später, wenn der Switch das zulässt. |
---
## Phase 0 – Bestandsaufnahme und Repo an die Wirklichkeit anpassen
Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeinsames Deployment“ Schritt 1.
### Task 0.1: Zugang zu pve48 und Inventar aller Knoten
**Wo:** Teil a vor Ort an der Konsole von pve48, Teil b remote · **Planner:** „Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen“
- [ ]**a (vor Ort):** An pve48 als root anmelden, gegebenenfalls `passwd`, neuen Wert in `.env` (`PVE48_PASS`) eintragen.
- [ ]**b:** Schlüssel verteilen (Verfahren vom 08.10., `push_keys.py`) und Paketquellen umstellen.
- [ ]**c:** Gesundheitscheck auf pve48 ausführen und `healthcheck-2026-10-08.txt` ergänzen. Notieren: CPU, RAM, Platten, GPUs, IOMMU-Gruppen.
- [ ]**d (vor Ort, falls nötig):** pve52 – steckt neben der M4000 eine P2000? Falls ja: Sitz und Steckplatz prüfen, bis `lspci | grep -c NVIDIA` zwei VGA-Geräte zeigt. Verbleib von Godel45 klären (im STT-Plan aufgeführt).
### Task 0.2: DHCP-Bereich und IP-Plan (D5)
**Wo:** remote (DHCP-Server, vermutlich DC `.120` oder UniFi) · **Planner:** „PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität“
- [ ] DHCP-Bereich auslesen. Für .207, .209, .210, .212 und .214 Reservierungen auf die MACs der Knoten anlegen (MACs stehen im Healthcheck).
- [ ] Gäste-Block festlegen (Vorschlag `.220–.239`) und als Ausschluss im DHCP eintragen.
Prüfung: `ping` auf jede Adresse des Blocks → keine Antwort. DHCP-Ausschluss sichtbar.
### Task 0.3: Entscheidungen D1–D5 bestätigen
**Wo:** Gespräch mit dem Nutzer
- [ ] D1: Ausdrückliche Freigabe zum Löschen von pve44 sdb (NTFS) und pve52 sdb (BitLocker „GODEL55“). Vorher klären, ob Daten oder Recovery-Key gebraucht werden.
- [ ] D2–D5 bestätigen. Ergebnis als Abschnitt „Entscheidungen 2026-10“ in `docs/PLAN.md` §9 eintragen.
### Task 0.4: Site-Dateien, Ansible-Inventar und ADRs an die echte Hardware anpassen
- Modify: `docs/adr/0001-gpu-vms-infra-lxc.md` (eine VM pro Knoten), `docs/adr/0002-storage-zfs-kein-ceph.md` (D1), `docs/adr/0006-legacy-gpus-llamacpp-tts-auf-ada.md` (Ada unter Windows, D3)
- [ ]**Step 1: Failing test.** In `test_inventory_validate.py` den Test `test_site_knaster_matches_real_nodes` anlegen: Die Inventar-Knoten sind genau `{pve44, pve46, pve48, pve52, pve61}`, `proxmox.yaml` enthält keine IP aus `10.20.0.0/24`, und jedes `pci_mappings[*].node` ist ein Inventar-Knoten.
- [ ]**Step 3:** Site-Dateien umschreiben. Werte für IDs und Pfade aus `lspci -nn` und dem Healthcheck: M4000 `10de:13f1` auf `0000:01:00`, P2000 `10de:1c30` auf `0000:02:00`. Gateway `192.168.100.1`, DNS `192.168.100.120`, keine `vlan_svc`, Gast-IPs aus D5. Die M4000 bleiben `disabled: true` bis zum Benchmark-Tag (Task 3.5). Die Ada-Slots zeigen auf `engine: worker-registry` (siehe Task 6.4).
- [ ]**Step 4:**`make test && make validate` → PASS. `knaster placement plan --inventory sites/knaster/inventory.yaml` liefert eine Zuordnung ohne Fehler.
- [ ]**Step 5:** Commit `sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt`.
---
## Phase 1 – Knoten-Grundlage (vor dem Cluster)
### Task 1.1: Bootstrap-Skript für einen frischen Knoten
- Produces: `bootstrap-node.sh <knoten>`, idempotent. Ausgabe endet mit `BOOTSTRAP OK <hostname>` oder Exit ≠ 0.
- [ ]**Step 1:** Das Skript (läuft auf dem Laptop, Git-Bash) erledigt Folgendes:
- alten Hostschlüssel mit `ssh-keygen -R <ip>` entfernen
- Schlüssel per Passwort aus `.env` eintragen, mit dem SSH_ASKPASS-Verfahren vom 08.10. (nur anhängen, `grep -qxF`)
- Enterprise-Quellen auf `Enabled: no` setzen, `proxmox.sources` mit `pve-no-subscription` anlegen, vorher sichern
-`apt-get update && apt-get -y full-upgrade`
- Pakete `ethtool lm-sensors` installieren
- Prüfen: `timedatectl show -p NTPSynchronized` = `yes`
- [ ]**Step 2:** Zweiter Lauf gegen denselben Knoten → keine Änderung, wieder `BOOTSTRAP OK`.
- [ ]**Step 3:** Commit.
### Task 1.2: Neuinstallation mit ZFS (nur wenn D1 = Empfehlung)
**Wo:****vor Ort**, USB-Stick mit PVE 9.2 (ISO und Prüfsumme in `C:\Users\r.rapp\it\proxmox`) · **Planner:** „Proxmox: Speicher aller Knoten richtig konfigurieren“, „PVE-Config: RAM-Planung je Knoten (Host-Reserve, ZFS-ARC, KSM, Swap)“
Reihenfolge: **pve46** (eine Platte, Legacy → UEFI), dann pve44, pve52, pve48 und zuletzt **pve61 mit angestecktem Dock** (der USB-C-Adapter ist zurückgegeben).
- [ ] Pro Knoten: BIOS auf UEFI, Secure Boot aus, iGPU als primäre Anzeige (GPU-Knoten). Installer: gleicher Hostname und gleiche IP wie bisher, `ZFS (RAID1)` bzw. `ZFS (RAID0)` bei einer Platte, `ashift=12`, `compress=on`.
- [ ] Danach `bootstrap-node.sh <knoten>` → `BOOTSTRAP OK`.
- [ ] ZFS-ARC begrenzen: `zfs_arc_max` = 4 GiB auf 32-GB-Knoten, 1 GiB auf pve61 (`/etc/modprobe.d/zfs.conf`, `update-initramfs -u`).
### Task 1.3: pve61 – Netzwerk am Dock robust machen, Akku schonen
**Wo:** remote, Akku-Einstellung vor Ort · **Planner:** Teil von „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
- [ ] NIC des Docks per systemd-`.link` auf den Namen `nic0` festlegen, Zuordnung über die MAC `3c:e1:a1:c0:83:9d`. `bridge-ports nic0` in `/etc/network/interfaces`. Nach dem Ausstecken hängt ein `udev`-Hook `ifup`/`ifreload` die Karte wieder an `vmbr0`.
- [ ]**Test (vor Ort):** Dock 10 s ausstecken und wieder einstecken → nach höchstens 30 s `ping 192.168.100.214` vom Laptop ok.
Prüfung: `grep . /sys/class/power_supply/BAT*/capacity` pendelt bei etwa 50 %.
---
## Phase 2 – Cluster
Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
### Task 2.1: Cluster „knaster“ bilden
**Wo:** remote · **Planner:** „GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container“ (Teil Cluster)
- [ ] Auf pve44: `pvecm create knaster --link0 192.168.100.210`.
- [ ] Nacheinander auf pve46, pve48, pve52 und pve61: `pvecm add 192.168.100.210 --link0 <eigene IP>`. Nach **jedem** Beitritt den Laptop-Schlüssel in `/etc/pve/priv/authorized_keys` prüfen und gegebenenfalls einmal ergänzen.
Prüfung: `pvecm status` → `Quorate: Yes`, `Total votes: 5`. `for n in pve44 pve46 pve48 pve52 pve61; do ssh -o BatchMode=yes $n hostname; done` → fünf Namen.
- [ ] Datacenter-Optionen: Migrationsnetz `192.168.100.0/24`, Typ `secure`.
### Task 2.2: HA-Regeln und Replikation
**Wo:** remote
- [ ] Node-Affinity-Regeln: Infra-Dienste nur auf pve44, pve48, pve52. **pve61** bekommt keine HA-Gäste, GPU-VMs bleiben an ihrem Knoten.
- [ ] Replikationspartner festlegen: Infra-LXC von seinem Knoten auf einen zweiten, `*/15`.
Prüfung: `ha-manager rules config` bzw. `ha-manager groupconfig` zeigt die Regeln.
---
## Phase 3 – GPU-Grundlage und Benchmark-Tag
### Task 3.1: Steuerrechner „ops“ und Host-Rolle nur für GPU-Knoten
- [ ] LXC `ops` (Debian 13, vmid 100, auf pve44, IP aus D5) mit `ansible-core`, `opentofu`, `git` und dem Repo-Clone. Ansible läuft nicht auf dem Windows-Laptop.
- [ ]`site.yml`: `pve-host` nur für `pve_gpu_hosts` (pve44, pve46, pve52, ggf. pve48). pve61 steht in `pve_kiosk` ohne VFIO und Blacklist.
- [ ]`ansible-playbook playbooks/site.yml --limit pve_gpu_hosts --check`, danach der echte Lauf. Knoten **einzeln** neu starten.
Prüfung: `lspci -nnk -s 01:00.0` auf jedem GPU-Knoten → `Kernel driver in use: vfio-pci`. Auf pve61: `lspci -k -s 00:02.0` → `i915`.
### Task 3.2: Resource Mappings, Template und GPU-VMs
- [ ] PCI-Resource-Mappings aus `sites/knaster/proxmox.yaml` anlegen (Namen aus Task 0.4).
- [ ] Ubuntu-24.04-Cloud-Template vmid 9000 auf jedem GPU-Knoten.
- [ ]`tofu plan` und dann `tofu apply` für `gpu-pve44`, `gpu-pve46` und `gpu-pve52`: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf `local-zfs`, IPs aus D5.
Prüfung in jeder VM: `nvidia-smi -L` → beide Karten. `docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi` → beide Karten.
### Task 3.3: Benchmark-Tag (fasst drei Pläne zusammen)
**Wo:** remote, **Strommessung vor Ort** (Messgerät an der Steckdose) · **Planner:** „GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000“ · ersetzt außerdem den „Benchmark-Tag“ aus IMPLEMENTATION und den Gate-Task 1 des nex-STT-Plans
- [ ]`llama-bench` je Kartentyp: Embedding-Modell, 3–4B Q4 (verifier/signature), 7B Q4. Tokens/s und VRAM messen.
- [ ] whisper.cpp `large-v3-turbo`, Sprache `de`: Sekunden je 10 s Diktat auf M4000 und P2000. Klärt, ob CC 5.2 überhaupt rechnet. Zusätzlich die Dialekt-Testsätze.
- [ ]`knaster bench tts` (Piper, CPU).
- [ ] Strom je Knoten: Leerlauf und Volllast beider Karten (400-W-Netzteil, erwartet etwa 300 W).
- [ ] Ergebnis eintragen in `catalog/models.yaml` und `sites/knaster/registry.yaml`, in ADR-0006 „M4000 wieder aufnehmen ja/nein“ und in die STT-Entscheidung D131/D133 (nex). Commit.
Prüfung: `make validate` → PASS, Placement ordnet jede aktive Rolle einer gemessenen Karte zu.
---
## Phase 4 – Cluster-Grundkonfiguration (erst wenn alle Knoten drin sind)
**Wo:** remote. Jede Aufgabe hier entspricht einer Planner-Aufgabe.
- [ ]**4.1 Benutzer und Token** („PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen“): Admin-Benutzer und Gruppe, root@pam nur als Notfallzugang. Token `monitoring@pve!prom` (PVEAuditor), `healer@pve!knaster` (nur `VM.PowerMgmt` auf GPU-VMs, PLAN §3), `tofu@pve!ops`.
- [ ]**4.2 2FA** („PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren“): TOTP für root@pam und Admin. Recovery-Keys offline ablegen.
- [ ]**4.3 Benachrichtigungen** („PVE-Config: Benachrichtigungen (Notification Center) einrichten“): SMTP-Ziel Büro-Postfach, Matcher für Backup, Fencing und Updates. Testnachricht kommt an.
- [ ]**4.4 Firewall** („PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten“): IP-Set `admin` (Laptop) und `appsrv08` (.29). Zuerst Allow-Regeln für 8006, 22 und ICMP, **dann** aktivieren. Konsole als Rückfall bereithalten. Prüfung: Weboberfläche vom Laptop ok, von einem anderen Rechner gesperrt.
- [ ]**4.5 Ordnung** („PVE-Config: Ressourcenpools und Tags festlegen“, „PVE-Config: Standard für neue LXC-Container festlegen“): Pools `infra`, `gpu`, `test`. Tags `gpu`, `infra`, `test`. LXC-Standard: unprivilegiert, Debian-13-Vorlage, Nesting nur für Docker.
- [ ]**4.6 Zertifikat** („PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität)“): `/etc/pve/pve-root-ca.pem` auf dem Laptop als vertrauenswürdig importieren.
- [ ]**4.7 Update-Routine** („PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten)“): Ablauf in `docs/BETRIEB.md` eintragen (Wartungsmodus, ein Knoten nach dem anderen, GPU-VMs vorher sauber stoppen).
---
## Phase 5 – Backup und Monitoring
### Task 5.1: Proxmox Backup Server
**Wo:** remote, Speicherort vor Ort · **Planner:** „Proxmox: Backup-System überlegen“ (beantwortet PLAN §9, offener Punkt 6)
- [ ] Ziel-Speicher entscheiden. Empfehlung: externer Datenträger oder NAS, **nicht** die Toshiba-Platte „BACKUP“ des Nutzers. PBS als VM `pbs` (vmid 110), Datastore auf dem Ziel.
- [ ] Jobs: nächtlich Infra-LXC, ops-LXC und GPU-VMs (ohne Modellplatte), Aufbewahrung 7 Tage, 4 Wochen und 6 Monate. Dazu ein wöchentlicher Verify-Job.
- [ ]**Restore-Test:** Infra-LXC als Kopie zurückspielen.
Prüfung: Die Kopie startet, `docker ps` zeigt die Dienste.
### Task 5.2: Infra-LXC mit Monitoring (ein Stack)
**Wo:** remote · **Planner:** „Proxmox: Grafana-Dashboard für den Cluster“, „PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen“ · **Files:** Modify `deploy/compose/infra/docker-compose.yml`, `deploy/prometheus/prometheus.yml`
- [ ]`deploy/compose/infra` ohne den Dienst `litellm` (D4). Router zeigt auf `http://192.168.100.29:<LiteLLM-Port>`. Image-Tags pinnen (offener Punkt aus IMPLEMENTATION).
- [ ] LXC `infra` (vmid 101, Nesting, 4 Kerne, 12 GB) mit HA und Replikation (Task 2.2). Compose mit `KNASTER_DRY_RUN=true`.
- [ ] Prometheus-Ziele: `pve-exporter` (Token aus 4.1), `node-exporter` und `nvidia_gpu_exporter` in den GPU-VMs, Router.
- [ ] Grafana: Dashboards für Proxmox, Knoten, GPU (Community-JSON) und knaster. Konto `kiosk` mit Rolle Viewer.
- [ ] Alertmanager an den Router (Healer, Dry-Run) und an n8n `knaster-notify`. Der Workflow wird inaktiv importiert, dann aktiviert.
Prüfung: Grafana zeigt alle 5 Knoten und alle GPUs. Ein Test-Alert (`amtool alert add test`) erscheint im Kanal.
### Task 5.3: Kiosk auf pve61
**Wo:** remote, Abnahme vor Ort · **Planner:** „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
- [ ] Empfehlung: minimaler Kiosk **direkt auf dem Host** (`cage` + `chromium` als eigener Benutzer, systemd-Dienst, Bildschirmschoner aus). Das ist eine bewusste kleine Ausnahme von „Container zuerst“, weil ein Kiosk Bildschirm und Eingabe des Geräts braucht.
- [ ] URL: Grafana-Playlist im Kiosk-Modus mit Konto `kiosk`.
Prüfung: Nach einem Neustart von pve61 zeigt der Bildschirm ohne Eingriff das Dashboard.
---
## Phase 6 – Data Plane
Ersetzt PLAN §8 „1 Data Plane“.
- [ ]**6.1 GPU-Rollen:**`deploy/compose/gpu-llamacpp` in den GPU-VMs nach der Zuordnung aus Task 3.3, also Embedding und Rerank redundant auf zwei Knoten, Chat für verifier und signature. Prüfung: Canary-Checks grün (`knaster` Canary-Prober).
- [ ]**6.2 STT** (nex-STT-Plan Tasks 2–4): `whisper-server` als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot `stt-de` im Katalog. Port 8178 nur von `192.168.100.29` (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert `curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions` deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
- [ ]**6.3 Lokale Slots in LiteLLM (D4):**`embed-default`, `rerank-default`, `verifier-small` und `signature-extractor` als Modelle im LiteLLM auf appsrv08 eintragen (IP-Literale). Prüfung: `curl http://192.168.100.29:<port>/v1/models` listet die Slots, ein Aufruf je Slot antwortet.
- [ ]**6.4 Ada-Worker (D3)** · **Planner:** „LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette“
- Offene Schritte der Worker-Registry v2 im Repo `mygodel/nex` abschließen.
- Gefilterte Ports auf GODE-PC-05/06 freigeben (nex-STT-Plan, Anhang A).
- Im knaster-Router `engine: worker-registry` umsetzen: `GET /webhook/llm-worker-list` lesen und einen Worker wählen, der online ist; sonst Eskalation auf tier0.
- Prüfung: `make test` PASS. Live tagsüber geht eine tier1-Anfrage an tier0, nachts an GODE-PC-05.
---
## Phase 7 – Kernpfad
Ersetzt PLAN §8 „2 Kernpfad“.
- [ ] n8n-Workflows `knaster-request`, `knaster-jobs` und `knaster-service-routine` inaktiv importieren und Credentials setzen (`n8n/README.md`).
- [ ] Ende-zu-Ende: Eine Anfrage läuft über Router, Verifier und Eskalation über den PSE-LiteLLM. Die Dry-Run-Woche beginnt.
- [ ] Nex-STT-Plan Tasks 5–8: Hermes-Overlay `stt.openai.base_url` mit IP-Literal, Rückfall auf CPU, Abnahme.
- [ ] Offen und hier zu entscheiden: Langfuse (PLAN §2.4) steht nicht im Infra-Compose.
## Phase 8 – GRP als Testdienst
**Planner:** „Proxmox: GRP als Testservice in einen LXC-Container umziehen“ · **Voraussetzung:** PBS (Task 5.1)
- [ ] LXC `grp-test` (Pool `test`, Docker) mit einer Kopie der GRP-Daten von appsrv08. Die Produktion bleibt unangetastet. Feste IP aus D5, Zugriff nur intern.
Prüfung: Die Testinstanz läuft, das Backup des Containers ist im PBS sichtbar.
## Phase 9 – knaster-Ausbau (eigene Pläne folgen)
Die Software-Phasen aus PLAN §8 bleiben inhaltlich gültig und bekommen jeweils einen eigenen Plan:
- „5 Lifecycle“: QLoRA-Training. Voraussetzung ist die Entscheidung über WSL2 bzw. vLLM auf den Ada-Rechnern nachts (D3, Folgeentscheidung).
- „6 Portabilität“
Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betriebshandbuch und Testvorgehen anlegen“). Das geschieht als Erweiterung von `docs/BETRIEB.md`, nicht als neues Dokument.
---
## Parallelspur NEX (ohne Cluster-Bezug, nach Dringlichkeit)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.