Update Home

arnol 2026-07-23 14:42:37 +02:00
commit 81ad531733

72
Home.md

@ -1,36 +1,36 @@
# 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 |
|---|---|---|---|---|
| [PVE-Host](01-PVE-Host) | `<PVE_HOSTNAME>` | `<LAN_IP_PVE>` | `<TS_IP_PVE>` | Proxmox-Host, Subnet-Router, ZFS, WoL-Trigger |
| [AdGuard · CT100](02-AdGuard-CT100) | `adguard` (CT 100) | `<LAN_IP_ADGUARD>` | — | DNS/Ad-Blocking |
| [NAS · CT101](03-NAS-CT101) | `nas` (CT 101) | `<LAN_IP_NAS>` | — | Samba/SFTP/Filebrowser |
| [Management-Desktop · CT102](04-Management-Desktop-CT102) | `browser` (CT 102) | `<LAN_IP_DESKTOP>` | `<TS_IP_DESKTOP>` | Gemeinsamer Browser-Desktop |
| [Vaultwarden · CT103](05-Vaultwarden-CT103) | `vaultwarden` (CT 103) | `<LAN_IP_VAULTWARDEN>` | `<TS_IP_VAULTWARDEN>` | Passwortmanager |
| [VPS · STRATO](06-VPS-STRATO) | `vps` (STRATO) | — | `<TS_IP_VPS>` | Guacamole-Gateway, öffentlicher Fallback-Zugang |
| [Monitoring · CT104](08-Monitoring-CT104) | `monitoring` (CT 104) | `<LAN_IP_MONITORING>` | `<TS_IP_MONITORING>` | Grafana/InfluxDB/Uptime Kuma/ntfy |
Cross-cutting, kein eigener Host:
- [Backup & Restore](07-Backup-Restore) — nächtliches Backup des Laufzeit-Zustands aller Instanzen (LXCs, Guacamole-DB) plus Restore-Anleitung.
- [Gast-Zugang](09-Gast-Zugang) — 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.
# 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 |
|---|---|---|---|---|
| [PVE-Host](01-PVE-Host) | `<PVE_HOSTNAME>` | `<LAN_IP_PVE>` | `<TS_IP_PVE>` | Proxmox-Host, Subnet-Router, ZFS, WoL-Trigger |
| [AdGuard · CT100](02-AdGuard-CT100) | `adguard` (CT 100) | `<LAN_IP_ADGUARD>` | — | DNS/Ad-Blocking |
| [NAS · CT101](03-NAS-CT101) | `nas` (CT 101) | `<LAN_IP_NAS>` | — | Samba/SFTP/Filebrowser |
| [Management-Desktop · CT102](04-Management-Desktop-CT102) | `browser` (CT 102) | `<LAN_IP_DESKTOP>` | `<TS_IP_DESKTOP>` | Gemeinsamer Browser-Desktop |
| [Vaultwarden · CT103](05-Vaultwarden-CT103) | `vaultwarden` (CT 103) | `<LAN_IP_VAULTWARDEN>` | `<TS_IP_VAULTWARDEN>` | Passwortmanager |
| [VPS · STRATO](06-VPS-STRATO) | `vps` (STRATO) | — | `<TS_IP_VPS>` | Guacamole-Gateway, öffentlicher Fallback-Zugang |
| [Monitoring · CT104](08-Monitoring-CT104) | `monitoring` (CT 104) | `<LAN_IP_MONITORING>` | `<TS_IP_MONITORING>` | Grafana/InfluxDB/Uptime Kuma/ntfy |
Cross-cutting, kein eigener Host:
- [Backup & Restore](07-Backup-Restore) — nächtliches Backup des Laufzeit-Zustands aller Instanzen (LXCs, Guacamole-DB) plus Restore-Anleitung.
- [Gast-Zugang](09-Gast-Zugang) — read-only Showcase-Zugang (genau die Oberfläche, über die diese Dateien hier gerade ausgeliefert werden) für Freunde/Bekannte zur Diskussionszwecken.
## 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.