docs: Notfall-Übergabe der Verwaltung (für die Geschäftsführung)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -18,6 +18,7 @@ Anfrage → n8n → Router-Service ──▶ Stufe 3  Embedding-Classifier (CPU)
 | [AGENTS.md](AGENTS.md) | **Einstieg für Agenten und neue Admins**: Arbeitsweise, Regeln, Muster |
 | [project-map.md](project-map.md) | Was wo läuft: Rechner, Adressen, Dienste, Ports, Namespaces, Repo, Orte der Geheimnisse |
 | [known-issues.md](known-issues.md) | Bekannte Probleme und Fallen |
+| [docs/NOTFALL-ADMIN-UEBERGABE.md](docs/NOTFALL-ADMIN-UEBERGABE.md) | Notfall: Verwaltung an eine andere Person übergeben (für die Geschäftsführung) |
 | [docs/PLAN.md](docs/PLAN.md) | Architektur und Betrieb: Proxmox, Pflege, Autohealing, Lifecycle, Finetuning, Problemerkennung, Portabilität |
 | [docs/adr/](docs/adr/) | Architekturentscheidungen |
 | [docs/spec/](docs/spec/) | Spezifikationen der Komponenten |

docs/ANMELDUNG.md

@@ -12,6 +12,8 @@ Eintrag **„Proxmox knaster – r.rapp@pve“**:
 
 Zweiter Eintrag **„Proxmox knaster – root (Notfall)“**: Passwörter `PVE44_PASS` … `PVE61_PASS` aus `.env`.
 
+Muss die Verwaltung im Notfall ganz an eine andere Person gehen: [NOTFALL-ADMIN-UEBERGABE.md](NOTFALL-ADMIN-UEBERGABE.md).
+
 ## 2. Anmelden (Weboberfläche)
 
 1. Nur vom **Admin-Laptop** (WLAN 192.168.100.151 oder Dock 192.168.100.181) oder über den Steuerrechner `ops`. Von anderen Rechnern sperrt die Firewall die Weboberfläche. Soll ein anderer PC dauerhaft Zugriff bekommen: seine IP in `cluster-knaster/sites/knaster/proxmox.yaml` unter `firewall.management` eintragen und auf ops `ansible-playbook playbooks/cluster.yml` laufen lassen.

docs/BETRIEB.md

@@ -279,6 +279,8 @@ SSH-Schlüssel dort, von ops aus laufen `kubectl`, Ansible und tofu und erreiche
 den Knoten (`/etc/pve/priv/authorized_keys`), in infra und in den VMs. Neue Personen brauchen das nicht; bei einer
 vollständigen Übergabe dort ebenfalls entfernen.
 
+**Notfall (bisherige Person nicht erreichbar):** `docs/NOTFALL-ADMIN-UEBERGABE.md` (Unterlage für die Geschäftsführung, ohne Passwörter): Firewall-Freigabe vor Ort an pve61, Schlüssel über die Proxmox-Shell von pve46 (`pct enter 100`) auf ops eintragen, danach wie oben dauerhaft machen.
+
 **Später („Weg 2“, Phase 9):** Verwaltung über nex-admin mit freigegebenen Aktionen auf ops statt persönlicher
 Shell, siehe Aufbauplan.
 

docs/NOTFALL-ADMIN-UEBERGABE.md

@@ -0,0 +1,152 @@
+# Notfall: Verwaltung des Clusters „knaster“ an eine andere Person übergeben
+
+Stand 19.10.2026. Für die Geschäftsführung als Notfallunterlage. **In diesem Dokument stehen keine Passwörter.**
+Alle Geheimnisse liegen in Password Depot; hier steht nur, wo sie liegen und was man damit tut.
+
+Technische Einzelheiten für die übernehmende Person: `docs/BETRIEB.md` Abschnitt 15, `AGENTS.md`, `project-map.md`
+im Repository `cluster-knaster`.
+
+---
+
+## 1. Worum es geht
+
+Der Cluster „knaster“ (fünf Proxmox-Server mit KI-Diensten) wird von einer Person verwaltet, heute **Robert Rapp**.
+Fällt diese Person aus (Krankheit, Austritt, nicht erreichbar), muss eine andere Person die Verwaltung übernehmen
+können. Dafür braucht sie vier Zugänge:
+
+| Zugang | Wofür | Woher im Notfall |
+|---|---|---|
+| **Proxmox-Konto mit TOTP** (Einmalcode) | Weboberfläche der Server: Zustand, Neustart, Konsole | Notfall: `root`-Passwort aus Password Depot; danach eigenes Konto |
+| **Freigabe der Geräteadresse in der Firewall** | Ohne Freigabe ist die Weboberfläche vom eigenen Rechner aus gesperrt | vor Ort am Server pve61 (Abschnitt 4, Schritt 2) |
+| **SSH-Schlüssel auf dem Steuerrechner „ops“** | Alle Verwaltungsarbeiten (Kubernetes, Ansible, Updates) | über die Proxmox-Weboberfläche eintragen (Schritt 4) |
+| **Gitea-Zugang** zum Repository `cluster-knaster` | Konfiguration ändern und dauerhaft festhalten | Gitea-Administrator (siehe unten) |
+
+## 2. Was vorher bereitliegen muss (einmal prüfen, dann jährlich)
+
+- [ ] Die Geschäftsführung (oder eine benannte Vertretung) hat Zugriff auf Password Depot mit den Einträgen
+  **„Proxmox knaster – root (Notfall)“** (Passwörter `PVE44_PASS` … `PVE61_PASS`) und
+  **„Proxmox knaster – r.rapp@pve“** (Passwort, Einmalcode, Recovery-Keys).
+- [ ] Bekannt ist, wo der Server **pve61** steht (Microsoft Surface mit eigenem Bildschirm, im Dock am Netzwerk):
+  Standort: ______________________________
+- [ ] Gitea-Administrator für `gitea.mindboost.team` (kann Personen Zugang zum Repository geben):
+  Name / Kontakt: ______________________________
+- [ ] Benannte übernehmende Person(en) mit Grundkenntnissen in Linux und SSH:
+  ______________________________
+
+## 3. Geplante Übergabe (die bisherige Person ist noch erreichbar)
+
+Dauer etwa 30–60 Minuten, beide gemeinsam. Die bisherige Person führt die neue nach `docs/BETRIEB.md` Abschnitt 15
+durch: Schlüssel eintragen, Proxmox-Konto mit TOTP anlegen, Geräteadresse freigeben, Gitea-Zugang. Danach ist
+Abschnitt 4 nicht nötig. Das ausgefüllte Übergabeblatt (Abschnitt 6) zur Notfallunterlage legen.
+
+## 4. Notfall: die bisherige Person ist nicht erreichbar
+
+Die übernehmende Person (im Folgenden **B**) braucht: einen eigenen Laptop im Büronetz, Zugriff auf Password Depot
+(über die Geschäftsführung) und einmal Zugang zum Server pve61 vor Ort.
+
+**Schritt 1 – Laptop vorbereiten (B, 5 Minuten).** Unter Windows in „Git Bash“ (oder Linux/macOS im Terminal):
+```bash
+ssh-keygen -t ed25519 -C "<name>-<geraet>-<datum>"     # z. B. m.muster-laptop-2026-11-03, Enter für Standardpfad
+cat ~/.ssh/id_ed25519.pub                             # öffentlicher Schlüssel, eine Zeile: ssh-ed25519 AAAA… <name>
+ipconfig                                              # eigene IPv4-Adresse im Netz 192.168.100.x notieren
+```
+Nur der **öffentliche** Schlüssel (`.pub`) wird weitergegeben, nie die Datei ohne Endung.
+
+**Schritt 2 – Adresse von B in der Firewall freigeben (vor Ort an pve61, 5 Minuten).**
+1. Am Surface anmelden: Benutzer `root`, Passwort `PVE61_PASS` aus Password Depot.
+2. Datei öffnen: `nano /etc/pve/firewall/cluster.fw`
+3. Im Block `[IPSET admin]` eine Zeile ergänzen, z. B. `192.168.100.57 # Notfall m.muster 2026-11-03`
+4. Speichern (`Strg+O`, Enter, `Strg+X`). Die Änderung gilt nach wenigen Sekunden auf allen Servern.
+
+Diese Freigabe ist vorläufig: Der nächste Lauf von `playbooks/cluster.yml` schreibt die Datei aus dem Repository neu.
+Darum in Schritt 5 dauerhaft eintragen.
+
+**Schritt 3 – Weboberfläche (B, am eigenen Laptop).** Browser: `https://192.168.100.210:8006`
+(Zertifikatswarnung bestätigen). Benutzer `root`, Realm **„Linux PAM standard authentication“**, Passwort
+`PVE44_PASS` aus Password Depot.
+
+**Schritt 4 – Schlüssel von B auf dem Steuerrechner ops eintragen.**
+1. Links im Baum den Server **pve46** wählen, oben **„Shell“**.
+2. In der Shell:
+   ```bash
+   pct enter 100
+   echo "ssh-ed25519 AAAA…   <öffentlicher Schlüssel von B, ganze Zeile>" >> /root/.ssh/authorized_keys
+   exit
+   ```
+3. Am Laptop von B prüfen: `ssh root@192.168.100.173 kubectl get nodes` → fünf Zeilen mit `Ready`.
+
+Ab hier kann B den Cluster verwalten. Alle weiteren Arbeiten laufen über ops (siehe `AGENTS.md`).
+
+**Schritt 5 – Dauerhaft machen (B, mit Gitea-Zugang).**
+1. Gitea-Administrator gibt B Schreibzugang zu `gitea.mindboost.team/rorapp/cluster-knaster`; Repository klonen.
+2. In `sites/knaster/proxmox.yaml` eintragen (Beispiel in Abschnitt 6):
+   Schlüssel unter `access.ops_ssh_keys`, Name unter `access.admin_users`, Adresse unter `firewall.management`.
+3. Committen und pushen, dann auf ops:
+   ```bash
+   cd /root/cluster-knaster && git pull
+   cd platform/proxmox/ansible
+   ansible-playbook playbooks/admins.yml
+   ansible-playbook playbooks/cluster.yml
+   ```
+4. Eigenes Proxmox-Konto mit TOTP: vom Laptop `platform/proxmox/scripts/pve-admin-user.sh <name>`
+   (setzt Passwort, Einmalcode und Recovery-Keys; die erzeugte Datei `tfa-<name>.txt` in Password Depot übernehmen
+   und löschen). Ab dann nicht mehr als `root` anmelden.
+
+**Schritt 6 – Bisherige Person austragen (nur bei Austritt).**
+Nach `docs/BETRIEB.md` Abschnitt 15 „Person oder Gerät entfernen“: Schlüssel nach `ops_ssh_keys_revoked`, Konto
+`r.rapp@pve` löschen, alte Laptop-Adressen aus `firewall.management`, Gitea-Zugang entziehen. Zusätzlich die
+root-Passwörter aller Server ändern (Password Depot aktualisieren) und die Token in `/root/.config/knaster/` auf ops
+erneuern (BETRIEB Abschnitt 8). Der Laptop-Schlüssel der bisherigen Person liegt auch direkt auf den Servern
+(`/etc/pve/priv/authorized_keys`), in infra und in den VMs und muss dort ebenfalls entfernt werden.
+
+## 5. Was man im Notfall nicht tun sollte
+
+- Die Firewall **nicht** ganz abschalten, solange es nicht anders geht (`pve-firewall stop` nur als letzter Ausweg,
+  danach sofort wieder `pve-firewall start`).
+- Keine Server neu installieren oder Festplatten anfassen; Daten und KI-Dienste laufen weiter, auch ohne Verwaltung.
+- Keine Passwörter oder privaten Schlüssel per Mail oder Chat verschicken.
+- Server nur einzeln und nacheinander neu starten (`docs/BETRIEB.md` Abschnitt 6).
+
+## 6. Beispiel: ausgefülltes Übergabeblatt (fiktive Person)
+
+| Punkt | Beispiel | Wo es festgehalten wird |
+|---|---|---|
+| Person | Max Muster, IT, max.muster@… | dieses Blatt |
+| Proxmox-Konto | `m.muster@pve`, Gruppe `admins`, TOTP eingerichtet am 03.11.2026 | Passwort, Einmalcode, Recovery-Keys in Password Depot, Eintrag „Proxmox knaster – m.muster@pve“ |
+| Geräte und Adressen | Laptop WLAN `192.168.100.57`, Dock `192.168.100.58` (beim DC reservieren lassen) | `sites/knaster/proxmox.yaml` → `firewall.management` |
+| SSH-Schlüssel | `ssh-ed25519 AAAAC3Nz…Xy m.muster-laptop-2026-11-03` | `sites/knaster/proxmox.yaml` → `access.ops_ssh_keys` |
+| Gitea | Benutzer `mmuster`, Schreibzugang zu `rorapp/cluster-knaster`, erteilt von ________ | Gitea |
+| Prüfung | `ssh ops kubectl get nodes` → 5× Ready; Anmeldung Weboberfläche mit TOTP ok | Datum, Unterschrift: ________ |
+
+Eintrag in `sites/knaster/proxmox.yaml` (Ausschnitt):
+```yaml
+access:
+  admin_users: [r.rapp, m.muster]
+  ops_ssh_keys:
+    - {name: r.rapp-laptop, key: "ssh-ed25519 AAAAC3Nz…QcoJ rrapp-laptop-2026-10-08"}
+    - {name: m.muster-laptop, key: "ssh-ed25519 AAAAC3Nz…Xy m.muster-laptop-2026-11-03"}
+  ops_ssh_keys_revoked: []
+firewall:
+  management:
+    - {ip: 192.168.100.57, comment: Laptop m.muster WLAN}
+    - {ip: 192.168.100.58, comment: Laptop m.muster Dock}
+```
+
+SSH-Konfiguration auf dem Laptop von B (`~/.ssh/config`):
+```
+Host ops
+    HostName 192.168.100.173
+    User root
+    IdentityFile ~/.ssh/id_ed25519
+    IdentitiesOnly yes
+```
+Danach genügt `ssh ops`. Von ops aus erreicht man alle Server und Gäste (`ssh pve44`, `kubectl …`, `ansible-playbook …`).
+
+## 7. Prüfliste nach der Übernahme
+
+- [ ] `ssh ops kubectl get nodes` zeigt fünf Knoten `Ready`.
+- [ ] Weboberfläche mit eigenem Konto und Einmalcode, Übersicht ohne rote Server.
+- [ ] Grafana `http://192.168.100.188:3000` öffnet (Passwort `admin` steht in `/opt/knaster/infra/.env` auf infra).
+- [ ] Proxmox-Benachrichtigungen kommen an (Mail an `ki@mygodel.de`; Empfänger bei Bedarf in
+  `access.mail_to` ändern).
+- [ ] Übergabeblatt ausgefüllt und zur Notfallunterlage gelegt; Password Depot aktualisiert.

project-map.md

@@ -66,6 +66,7 @@ Feste Adressen: Knoten, ops und infra statisch konfiguriert; GPU-VMs und k3s-VM
 | `docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md` | Aufbauplan mit Stand je Task |
 | `docs/BETRIEB.md` | Betriebshandbuch (Monitoring §7, Zugang §8, Firewall §10, k3s §14, Übergabe §15) |
 | `docs/ANMELDUNG.md` | Anmeldung und Vertretung (Password Depot) |
+| `docs/NOTFALL-ADMIN-UEBERGABE.md` | Notfall-Übergabe der Verwaltung an eine andere Person (für die Geschäftsführung) |
 | `docs/PLAN.md`, `docs/adr/`, `docs/spec/` | Architektur, Entscheidungen, Spezifikationen |
 | `sites/knaster/proxmox.yaml` | Zielbild: Knoten, GPUs, VMs, LXC, Zugang, Firewall |
 | `sites/knaster/registry.yaml`, `catalog/` | Slots (Modelle je Rolle) und Modellkatalog |