cluster-knaster/docs/NOTFALL-ADMIN-UEBERGABE.md

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):

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:

   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:

   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):

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.