[Epic] Härtung auf fremden VMs/Umgebungen (OS-Vielfalt, CT vs VM, fehlende Tools, isolierte Netze) #56

New issue

Open

opened 2026-06-02 13:33:09 +00:00 by chinux · 0 comments

chinux commented

2026-06-02 13:33:09 +00:00

Owner

Ziel (Tracking/Epic)

Die Features gehen aktiv in die Gäste hinein, brechen aber außerhalb der eigenen Umgebung. „Härten statt verbreitern": die Kern-Workflows müssen auf fremden VMs/Umgebungen robust laufen, nicht nur „bei mir".

Härtungs-Dimensionen

Gast-OS-Vielfalt
- Linux: Debian und Ubuntu/RHEL/Alma/Rocky/Alpine/Arch — unterschiedliche Paketmanager (apt/dnf/apk/pacman), Update-Counts, CVE-Ecosystems (#36).
- Fehlende Tools nicht voraussetzen: kein curl/wget auf FreeBSD-Base → fetch (#52); allgemein Tool-Existenz prüfen statt annehmen.
- FreeBSD/pfSense (#34) und Windows (#27) bei Port-Scan/Update vollwertig.
CT vs VM: LXC hat keinen qemu-guest-agent → nie der /qemu/<id>-Pfad für Container (#51/#52); CT-IP/-Update über pct/lxc (#50/#51).
Nicht erreichbare/tote Komponenten: toter qemu-guest-agent → Backoff statt Hämmern (#38); isolierte Gäste ohne Route zum Backend → Binaries vom Node-Agent servieren (#52).
PVE-Varianten: verschiedene PVE-/pvesh-Versionen und Output-Shapes (coerce_bool etc.) tolerant parsen.
Fehlerpfade sichtbar & sauber: nicht-unterstützte OS → skipped statt harter Fehler; klare Meldungen statt kryptischer pvesh-Fehler.

Vorgehen

Diese konkreten Bugs sind der Härtungs-Backlog: #34, #36, #38, #44, #51, #52 (+ #27 Windows-Port-Scan).
Test-Matrix definieren: pro Feature × {Debian, Ubuntu, Alpine, FreeBSD, Windows} × {VM, CT} dokumentieren, was unterstützt/getestet ist.
Capability-Checks im Agent zentralisieren (OS-Detect + Tool-Detect einmal, cachen).

Akzeptanz

Kern-Workflows (Scan, Update, Self-Update, Port-Scan, RDP) laufen auf den o. g. OS/CT-Kombinationen oder melden sauber „nicht unterstützt".
Keine kryptischen pvesh-/qemu-Fehler mehr bei CT/FreeBSD.

Bezug

Sammel-Issue; verlinkt #27/#34/#36/#38/#44/#50/#51/#52.

Label

tech-debt / agent

## Ziel (Tracking/Epic) Die Features gehen aktiv in die Gäste hinein, brechen aber außerhalb der eigenen Umgebung. „Härten statt verbreitern": die Kern-Workflows müssen auf **fremden VMs/Umgebungen** robust laufen, nicht nur „bei mir". ## Härtungs-Dimensionen 1. **Gast-OS-Vielfalt** - Linux: Debian **und** Ubuntu/RHEL/Alma/Rocky/Alpine/Arch — unterschiedliche Paketmanager (`apt`/`dnf`/`apk`/`pacman`), Update-Counts, CVE-Ecosystems (#36). - **Fehlende Tools nicht voraussetzen**: kein `curl`/`wget` auf FreeBSD-Base → `fetch` (#52); allgemein Tool-Existenz prüfen statt annehmen. - FreeBSD/pfSense (#34) und Windows (#27) bei Port-Scan/Update vollwertig. 2. **CT vs VM**: LXC hat keinen qemu-guest-agent → nie der `/qemu/<id>`-Pfad für Container (#51/#52); CT-IP/-Update über `pct`/`lxc` (#50/#51). 3. **Nicht erreichbare/tote Komponenten**: toter qemu-guest-agent → Backoff statt Hämmern (#38); isolierte Gäste ohne Route zum Backend → Binaries vom Node-Agent servieren (#52). 4. **PVE-Varianten**: verschiedene PVE-/`pvesh`-Versionen und Output-Shapes (coerce_bool etc.) tolerant parsen. 5. **Fehlerpfade sichtbar & sauber**: nicht-unterstützte OS → `skipped` statt harter Fehler; klare Meldungen statt kryptischer pvesh-Fehler. ## Vorgehen - Diese konkreten Bugs sind der Härtungs-Backlog: **#34, #36, #38, #44, #51, #52** (+ #27 Windows-Port-Scan). - Test-Matrix definieren: pro Feature × {Debian, Ubuntu, Alpine, FreeBSD, Windows} × {VM, CT} dokumentieren, was unterstützt/getestet ist. - Capability-Checks im Agent zentralisieren (OS-Detect + Tool-Detect einmal, cachen). ## Akzeptanz - Kern-Workflows (Scan, Update, Self-Update, Port-Scan, RDP) laufen auf den o. g. OS/CT-Kombinationen oder melden sauber „nicht unterstützt". - Keine kryptischen pvesh-/qemu-Fehler mehr bei CT/FreeBSD. ## Bezug Sammel-Issue; verlinkt #27/#34/#36/#38/#44/#50/#51/#52. ## Label tech-debt / agent

chinux added the

tech-debt

agent

labels

2026-06-02 13:33:09 +00:00

chinux referenced this issue

2026-06-02 15:29:13 +00:00

Lokale Volumes (inkl. /boot) als Telemetrie + backend-seitiger /boot-Watch (Trigger für #26) #64

chinux referenced this issue

2026-06-02 15:35:42 +00:00

Update Kernel Patch #26

chinux referenced this issue