VM-Enrollment: OS-Erkennung Cache-first (vm_qemu_scans/ostype), kein Linux-Default, UI-OS-Auswahl bei Unbekannt #66

New issue

Closed

opened 2026-06-02 15:48:25 +00:00 by chinux · 0 comments

chinux commented

2026-06-02 15:48:25 +00:00

Owner

Problem

Beim VM-Enrollment wird das Gast-OS per redundantem Live-Call qm.agent.osinfo bestimmt (admin_router.py:363-373). Wenn der scheitert (Guest-Agent langsam/tot, oder Node-Agent-Session flappt), greift ein gefaehrlicher Default: is_windows bleibt False → "Linux/sh wird angenommen" (:385) → es wird curl ... | sh an den Gast geschickt (:408-413).

Real beobachtet: eine Windows-VM (106) bekam dadurch curl ... | sh und anschliessend apt-get -s upgrade || dnf check-update || pkg upgrade — beides laeuft auf Windows ins Leere/Timeout.

Kern des Bugs: Die korrekten OS-Daten liegen bereits in der DB. Der periodische identity_scan legt das komplette get-osinfo ab:

Node-Agent/src/vm_scan.rs:48 → scan.insert("os", osinfo.clone()) (inkl. id = "mswindows" bei Windows, pretty-name)
→ Node-Agent/src/data.rs:118/133 → last_data.vm_qemu_scans[vmid]

Die Enrollment-Logik ignoriert diese gecachte, verlaessliche Quelle und fragt stattdessen live nach — genau der Call, der timeoutet.

Fix — OS-Erkennung mit klarer Prioritaet (`admin_router.py:360-385` umbauen)

Cache zuerst: node.last_data["vm_qemu_scans"][str(vmid)] lesen → os.id / os.name / os_pretty → Windows bei mswindows/windows. Kein Live-Call, kein Timeout.
Proxmox ostype aus vm.config (host-seitig, billig) als Quervergleich / wenn kein Scan-Eintrag vorhanden. ostype.startswith("w") → Windows.
Live qm.agent.osinfo nur noch als letzter Ausweg (VM nie gescannt, kein ostype).
Linux/sh-Default ENTFERNEN (:385). Wenn OS danach immer noch unbekannt → kein Befehl senden.

Unbekanntes OS → manuelle Auswahl im UI (statt Default/Abbruch)

Wenn 1-3 kein eindeutiges OS liefern:

Enrollment-Stream gibt ein os_unknown-Signal aus und pausiert (kein sh/curl blind senden).
Frontend zeigt einen OS-Picker (Windows / Linux / FreeBSD).
Auswahl ruft das Enrollment mit os_override=windows|linux|freebsd erneut auf → fuehrt den passenden Pfad aus.
Optional: das ermittelte/gewaehlte OS am VM-/Enrollment-Record persistieren, damit Folgeaktionen nicht neu erkennen muessen.

Befehle OS-spezifisch verzweigen

Install: Windows → vm-install-windows + PowerShell (existiert, :397-404); Linux/FreeBSD → vm-install + sh.
Update-Check: apt-get/dnf/pkg-Probe NIE an Windows. Windows-Update-Pfad ueber den Windows-VM-Guest-Agent (#27) / PowerShell. (Der Update-Befehl verzweigt aktuell gar nicht nach OS — mit fixen.)

Akzeptanz

Eine gescannte Windows-VM wird beim Enrollment aus dem Cache korrekt als Windows erkannt (kein Live-Call noetig).
Bei totem Guest-Agent + vorhandenem Scan/ostype trotzdem korrektes OS.
Kein sh/curl/apt mehr an Windows; bei unbekanntem OS erscheint der UI-Picker.
Install- UND Update-Befehl sind OS-spezifisch.

Bezug

#27 (Windows-VM-Guest-Agent / Windows-Update-Pfad)
#56 (Haertung auf fremden Umgebungen — OS-Erkennung robust, nie blind Linux)

Branch

fix/vm-os-detection-cache-first-no-linux-default

## Problem Beim VM-Enrollment wird das Gast-OS per **redundantem Live-Call** `qm.agent.osinfo` bestimmt (`admin_router.py:363-373`). Wenn der scheitert (Guest-Agent langsam/tot, oder Node-Agent-Session flappt), greift ein **gefaehrlicher Default**: `is_windows` bleibt `False` → **"Linux/sh wird angenommen"** (`:385`) → es wird `curl ... | sh` an den Gast geschickt (`:408-413`). **Real beobachtet:** eine **Windows-VM (106)** bekam dadurch `curl ... | sh` und anschliessend `apt-get -s upgrade || dnf check-update || pkg upgrade` — beides laeuft auf Windows ins Leere/Timeout. **Kern des Bugs:** Die korrekten OS-Daten **liegen bereits in der DB**. Der periodische `identity_scan` legt das komplette get-osinfo ab: - `Node-Agent/src/vm_scan.rs:48` → `scan.insert("os", osinfo.clone())` (inkl. `id` = `"mswindows"` bei Windows, `pretty-name`) - → `Node-Agent/src/data.rs:118/133` → `last_data.vm_qemu_scans[vmid]` Die Enrollment-Logik **ignoriert diese gecachte, verlaessliche Quelle** und fragt stattdessen live nach — genau der Call, der timeoutet. ## Fix — OS-Erkennung mit klarer Prioritaet (`admin_router.py:360-385` umbauen) 1. **Cache zuerst:** `node.last_data["vm_qemu_scans"][str(vmid)]` lesen → `os.id` / `os.name` / `os_pretty` → Windows bei `mswindows`/`windows`. Kein Live-Call, kein Timeout. 2. **Proxmox `ostype`** aus `vm.config` (host-seitig, billig) als Quervergleich / wenn kein Scan-Eintrag vorhanden. `ostype.startswith("w")` → Windows. 3. **Live `qm.agent.osinfo`** nur noch als **letzter Ausweg** (VM nie gescannt, kein ostype). 4. **Linux/sh-Default ENTFERNEN** (`:385`). Wenn OS danach immer noch unbekannt → kein Befehl senden. ## Unbekanntes OS → manuelle Auswahl im UI (statt Default/Abbruch) Wenn 1-3 kein eindeutiges OS liefern: - Enrollment-Stream gibt ein `os_unknown`-Signal aus und **pausiert** (kein `sh`/`curl` blind senden). - Frontend zeigt einen **OS-Picker** (Windows / Linux / FreeBSD). - Auswahl ruft das Enrollment mit `os_override=windows|linux|freebsd` erneut auf → fuehrt den passenden Pfad aus. - Optional: das ermittelte/gewaehlte OS am VM-/Enrollment-Record persistieren, damit Folgeaktionen nicht neu erkennen muessen. ## Befehle OS-spezifisch verzweigen - **Install:** Windows → `vm-install-windows` + PowerShell (existiert, `:397-404`); Linux/FreeBSD → `vm-install` + sh. - **Update-Check:** `apt-get/dnf/pkg`-Probe NIE an Windows. Windows-Update-Pfad ueber den Windows-VM-Guest-Agent (#27) / PowerShell. (Der Update-Befehl verzweigt aktuell gar nicht nach OS — mit fixen.) ## Akzeptanz - Eine gescannte Windows-VM wird beim Enrollment aus dem Cache korrekt als Windows erkannt (kein Live-Call noetig). - Bei totem Guest-Agent + vorhandenem Scan/ostype trotzdem korrektes OS. - Kein `sh`/`curl`/`apt` mehr an Windows; bei unbekanntem OS erscheint der UI-Picker. - Install- UND Update-Befehl sind OS-spezifisch. ## Bezug - #27 (Windows-VM-Guest-Agent / Windows-Update-Pfad) - #56 (Haertung auf fremden Umgebungen — OS-Erkennung robust, nie blind Linux) ## Branch `fix/vm-os-detection-cache-first-no-linux-default`

chinux added the

bug

agent

labels

2026-06-02 15:48:25 +00:00

chinux referenced this issue

2026-06-02 16:23:11 +00:00

Agent-Flag-TTL-Cache + Backoff für tote Guest-Agents → Scan-Cap entkappen (offener Teil von #38) #67

chinux referenced this issue from a commit

2026-06-02 17:48:47 +00:00

fix(enrollment): #66 cache-first OS detection, OS picker for unknown

chinux closed this issue