# Rebuild-Dokumentation – Übersicht

Diese Dateien enthalten alle tatsächlich verwendeten CLI-Befehle, in Reihenfolge, um jede Instanz von Grund auf neu aufzusetzen — ohne Rückfrage. Fehlgeschlagene Zwischenschritte sind **nicht** enthalten, nur das jeweils korrekte Endergebnis plus eine explizite Warnung, was nicht funktioniert (siehe „⚠️ NICHT TUN"-Blöcke).

Für den Kontext/die Begründung hinter Entscheidungen: `ENTSCHEIDUNGEN.md` (hier rein technisch als Runbook, dort die Trade-offs/Alternativen). Zum Hintergrund dieser Freigabe: `ACHTUNG-DISCLAIMER.md`.

## Instanzen

| Datei | Host | IP (LAN) | IP (Tailscale) | Rolle |
|---|---|---|---|---|
| [01-pve-host.md](01-pve-host.md) | `<PVE_HOSTNAME>` | `<LAN_IP_PVE>` | `<TS_IP_PVE>` | Proxmox-Host, Subnet-Router, ZFS, WoL-Trigger |
| [02-ct100-adguard.md](02-ct100-adguard.md) | `adguard` (CT 100) | `<LAN_IP_ADGUARD>` | — | DNS/Ad-Blocking |
| [03-ct101-nas.md](03-ct101-nas.md) | `nas` (CT 101) | `<LAN_IP_NAS>` | — | Samba/SFTP/Filebrowser |
| [04-ct102-management-desktop.md](04-ct102-management-desktop.md) | `browser` (CT 102) | `<LAN_IP_DESKTOP>` | `<TS_IP_DESKTOP>` | Gemeinsamer Browser-Desktop |
| [05-ct103-vaultwarden.md](05-ct103-vaultwarden.md) | `vaultwarden` (CT 103) | `<LAN_IP_VAULTWARDEN>` | `<TS_IP_VAULTWARDEN>` | Passwortmanager |
| [06-vps-strato.md](06-vps-strato.md) | `vps` (STRATO) | — | `<TS_IP_VPS>` | Guacamole-Gateway, öffentlicher Fallback-Zugang |
| [08-monitoring.md](08-monitoring.md) | `monitoring` (CT 104) | `<LAN_IP_MONITORING>` | `<TS_IP_MONITORING>` | Grafana/InfluxDB/Uptime Kuma/ntfy |

Cross-cutting, kein eigener Host:
- [07-backup-restore.md](07-backup-restore.md) — nächtliches Backup des Laufzeit-Zustands aller Instanzen (LXCs, Guacamole-DB) plus Restore-Anleitung.
- [09-gast-zugang.md](09-gast-zugang.md) — read-only Showcase-Zugang (genau die Oberfläche, über die diese Dateien hier gerade ausgeliefert werden) für Freunde/Bekannte und Bewerbungsgespräche.

## Reihenfolge beim Neuaufbau

1. PVE-Host (Proxmox-Grundinstallation wird vorausgesetzt, danach Tailscale + ZFS + WoL)
2. CT 100 (AdGuard) — muss vor DHCP-Umstellung stehen, da alle anderen Container/das LAN danach über AdGuard auflösen
3. CT 101 (NAS) — ZFS-Pool muss vorher existieren
4. VPS (STRATO) — unabhängig von den LXCs, kann parallel/vorher passieren
5. CT 102 (Management-Desktop) und CT 103 (Vaultwarden) — brauchen Tailscale (Punkt 1) und idealerweise Guacamole (VPS) für vollen Funktionsumfang, technisch aber auch eigenständig baubar

## Globale Konventionen, die für alle Instanzen gelten

* **Nameserver bei jedem `pct create` explizit setzen:** `--nameserver <LAN_IP_ADGUARD>`. Grund: siehe `01-pve-host.md`, Abschnitt „DNS-Falle bei neuen Containern".
* **IP-Schema:** `.1` Fritzbox, `.9` AdGuard, `.10` PVE-Host, `.11` NAS, `.12` Management-Desktop, `.13` Vaultwarden, `.14` Monitoring, `.254` PC1 (Windows). `.1`–`.20` sind im Fritzbox-DHCP-Pool ausgeschlossen, für feste Zuweisungen reserviert.
* **Alle LXCs unprivileged**, außer es gibt einen zwingenden Grund (Kernel-Module/Storage-Passthrough) für privileged/VM.
* **Passwörter/Tokens/private Keys stehen NICHT in diesen Dateien** — die liegen im Chat-Verlauf bzw. sind vom Nutzer selbst zu setzen (Vaultwarden-Master-Passwort) oder in Vaultwarden zu hinterlegen, sobald der Umzug dorthin gemacht ist.