Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Robert Rapp
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
50acfa6a95
commit
c4ae5b2494
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user