Robert RappandClaude Opus 5.5
c4ae5b2494
ci / test (push) Failing after 23s
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
153 lines
8.7 KiB
Markdown
153 lines
8.7 KiB
Markdown
# 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.
|