diff --git a/README.md b/README.md index 5fcc3cd..af8a336 100644 --- a/README.md +++ b/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 | diff --git a/docs/ANMELDUNG.md b/docs/ANMELDUNG.md index 329b207..de8c9de 100644 --- a/docs/ANMELDUNG.md +++ b/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. diff --git a/docs/BETRIEB.md b/docs/BETRIEB.md index 97626e6..a0950bd 100644 --- a/docs/BETRIEB.md +++ b/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. diff --git a/docs/NOTFALL-ADMIN-UEBERGABE.md b/docs/NOTFALL-ADMIN-UEBERGABE.md new file mode 100644 index 0000000..b3f648f --- /dev/null +++ b/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 "--" # 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… +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 ` + (setzt Passwort, Einmalcode und Recovery-Keys; die erzeugte Datei `tfa-.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. diff --git a/project-map.md b/project-map.md index 807a15d..0623cac 100644 --- a/project-map.md +++ b/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 |