Proxmox-Hosts auf Updates scannen, anzeigen und aktualisieren (ohne Snapshot) #13

New issue

Closed

opened 2026-09-26 04:42:51 +00:00 by AxonByteDev · 0 comments

AxonByteDev commented

2026-09-26 04:42:51 +00:00

Owner

Problem

Proxmox-Server lassen sich unter Einstellungen → Proxmox schon hinterlegen. Dort dienen sie aber nur als Snapshot-Ziel für VMs/LXCs. Ob auf den Proxmox-Hosts selbst Updates anstehen, sieht man in PatchPilot nicht. Man muss das weiterhin in der Proxmox-Oberfläche oder per SSH prüfen und die Updates dort einspielen.

Ziel

Proxmox-Hosts werden wie normale Server behandelt:

Scannen: Sie werden beim manuellen Scan ("Alle scannen") und beim geplanten automatischen Scan auf verfügbare Updates geprüft.
Anzeigen: Stehen Updates an, erscheinen sie in der Updateliste (Updates.tsx) und im Dashboard (Dashboard.tsx), mit Paketanzahl, Paketliste und Zeitpunkt des letzten Scans, genau wie bei den anderen Servern.
Aktualisieren: Man kann das Update für einen Proxmox-Host aus PatchPilot heraus starten, mit Live-Log und interaktivem Terminal wie bei den normalen Servern.
Kein Snapshot: Für einen Proxmox-Host selbst gibt es keinen Snapshot. Der Snapshot-Schritt wird übersprungen, und die Oberfläche bietet ihn für diese Hosts gar nicht erst an (kein Snapshot-Badge, keine Snapshot-Option, keine Snapshot-Verwaltung).

Stand im Code

backend/database.py: ProxmoxServer enthält nur die API-Zugangsdaten (host, port 8006, user, password, verify_ssl) und keine SSH-Daten.
UpdateScan.server_id und UpdateRun.server_id sind Fremdschlüssel auf server.id. Scans und Update-Läufe können sich also im Moment nur auf Einträge aus der Tabelle Server beziehen, nicht auf ProxmoxServer.
backend/routers/updates.py: Scan (_run_scan, _scan_upgradable_packages) und Update (_execute_update) laufen komplett über SSH. Schritt 1 in _execute_update ist proxmox_utils.create_snapshot().
backend/proxmox_utils.py: create_snapshot() überspringt schon jetzt, wenn create_snapshot/proxmox_server_id/proxmox_vmid fehlen. Das lässt sich wiederverwenden.
Ein ProxmoxServer-Eintrag steht für einen Cluster-Zugang, der mehrere Nodes haben kann (GET /api/proxmox/{id}/nodes). Updates gibt es aber pro Node.

Lösungsvorschlag

Datenmodell: Jeder Proxmox-Node wird ein Server-Eintrag mit einem neuen type = "proxmox" (bisher lxc | vm | unraid | bare), os_type = "debian", create_snapshot = False und einem Verweis auf den ProxmoxServer und den Node (proxmox_server_id, proxmox_node). So funktionieren UpdateScan, UpdateRun, Historie, Benachrichtigungen, Dashboard und Updateliste ohne Schemaänderung an den Fremdschlüsseln. Die Alternative wäre, alle diese Stellen um einen zweiten Servertyp zu erweitern, und das wäre deutlich aufwendiger.

Scannen: Zwei Wege sind möglich:

a) Über SSH wie bei den anderen Servern (apt list --upgradable). Das ist einheitlich, braucht aber SSH-Zugangsdaten für den Node.
b) Über die Proxmox-API: POST /nodes/{node}/apt/update aktualisiert die Paketlisten, GET /nodes/{node}/apt/update liefert die verfügbaren Updates. Dafür reichen die schon hinterlegten API-Zugangsdaten.

Aktualisieren: Die Proxmox-API hat keinen Endpunkt, der die Updates wirklich einspielt (apt dist-upgrade). Für diesen Schritt ist SSH also nötig. Auf Proxmox sollte dabei apt dist-upgrade/full-upgrade laufen, nicht apt upgrade, weil Proxmox das ausdrücklich so vorgibt.

Snapshot: In _execute_update wird der Snapshot bei type == "proxmox" immer übersprungen, und im Log erscheint ein Hinweis wie "Proxmox-Host – kein Snapshot möglich". Im Frontend werden SnapshotBadge, die Snapshot-Option und die Snapshot-Verwaltung für diesen Typ ausgeblendet.

Offene Punkte

SSH-Zugang zum Node: Soll es in den Proxmox-Einstellungen eigene SSH-Felder geben (Port, Benutzer, Key/Passwort), oder werden die Nodes automatisch als Server-Einträge angelegt und dort gepflegt? Das API-Passwort von root@pam als SSH-Passwort wiederzuverwenden wäre bequem, sollte aber höchstens als Voreinstellung dienen.
Nodes anlegen: Automatisch aus GET /nodes beim Speichern bzw. Testen des Proxmox-Eintrags, oder per Hand einzeln auswählen?
Neustart: Nach einem Kernel-Update braucht der Host einen Neustart, und der betrifft alle VMs/LXCs darauf, eventuell auch PatchPilot selbst. Mindestens ein Hinweis "Neustart erforderlich" (/var/run/reboot-required) wäre sinnvoll. Ein automatischer Neustart gehört nicht in dieses Issue.
Repository-Hinweis: Ist das Enterprise-Repo ohne Subscription aktiv, schlägt apt update mit 401 fehl. Diese Fehlermeldung sollte verständlich im Scan-Ergebnis stehen.

Akzeptanzkriterien

Proxmox-Nodes werden beim manuellen und beim automatischen Scan mitgeprüft
Verfügbare Updates auf Proxmox-Nodes erscheinen im Dashboard und in der Updateliste
Ein Update auf einem Proxmox-Node lässt sich starten (Live-Log, dist-upgrade) und landet in der Historie
Für Proxmox-Nodes wird nie ein Snapshot versucht; die Snapshot-UI ist für sie ausgeblendet
Matrix-Benachrichtigungen funktionieren für Proxmox-Nodes wie für andere Server
Tests für Scan und Update mit übersprungenem Snapshot beim Typ proxmox

## Problem Proxmox-Server lassen sich unter **Einstellungen → Proxmox** schon hinterlegen. Dort dienen sie aber nur als Snapshot-Ziel für VMs/LXCs. Ob auf den Proxmox-Hosts selbst Updates anstehen, sieht man in PatchPilot nicht. Man muss das weiterhin in der Proxmox-Oberfläche oder per SSH prüfen und die Updates dort einspielen. ## Ziel Proxmox-Hosts werden wie normale Server behandelt: 1. **Scannen:** Sie werden beim manuellen Scan ("Alle scannen") und beim geplanten automatischen Scan auf verfügbare Updates geprüft. 2. **Anzeigen:** Stehen Updates an, erscheinen sie in der **Updateliste** (`Updates.tsx`) und im **Dashboard** (`Dashboard.tsx`), mit Paketanzahl, Paketliste und Zeitpunkt des letzten Scans, genau wie bei den anderen Servern. 3. **Aktualisieren:** Man kann das Update für einen Proxmox-Host aus PatchPilot heraus starten, mit Live-Log und interaktivem Terminal wie bei den normalen Servern. 4. **Kein Snapshot:** Für einen Proxmox-Host selbst gibt es keinen Snapshot. Der Snapshot-Schritt wird übersprungen, und die Oberfläche bietet ihn für diese Hosts gar nicht erst an (kein Snapshot-Badge, keine Snapshot-Option, keine Snapshot-Verwaltung). ## Stand im Code - `backend/database.py`: `ProxmoxServer` enthält nur die API-Zugangsdaten (`host`, `port` 8006, `user`, `password`, `verify_ssl`) und keine SSH-Daten. - `UpdateScan.server_id` und `UpdateRun.server_id` sind Fremdschlüssel auf `server.id`. Scans und Update-Läufe können sich also im Moment nur auf Einträge aus der Tabelle `Server` beziehen, nicht auf `ProxmoxServer`. - `backend/routers/updates.py`: Scan (`_run_scan`, `_scan_upgradable_packages`) und Update (`_execute_update`) laufen komplett über SSH. Schritt 1 in `_execute_update` ist `proxmox_utils.create_snapshot()`. - `backend/proxmox_utils.py`: `create_snapshot()` überspringt schon jetzt, wenn `create_snapshot`/`proxmox_server_id`/`proxmox_vmid` fehlen. Das lässt sich wiederverwenden. - Ein `ProxmoxServer`-Eintrag steht für einen **Cluster-Zugang**, der mehrere Nodes haben kann (`GET /api/proxmox/{id}/nodes`). Updates gibt es aber pro Node. ## Lösungsvorschlag **Datenmodell:** Jeder Proxmox-**Node** wird ein `Server`-Eintrag mit einem neuen `type = "proxmox"` (bisher `lxc | vm | unraid | bare`), `os_type = "debian"`, `create_snapshot = False` und einem Verweis auf den `ProxmoxServer` und den Node (`proxmox_server_id`, `proxmox_node`). So funktionieren `UpdateScan`, `UpdateRun`, Historie, Benachrichtigungen, Dashboard und Updateliste ohne Schemaänderung an den Fremdschlüsseln. Die Alternative wäre, alle diese Stellen um einen zweiten Servertyp zu erweitern, und das wäre deutlich aufwendiger. **Scannen:** Zwei Wege sind möglich: - a) Über SSH wie bei den anderen Servern (`apt list --upgradable`). Das ist einheitlich, braucht aber SSH-Zugangsdaten für den Node. - b) Über die Proxmox-API: `POST /nodes/{node}/apt/update` aktualisiert die Paketlisten, `GET /nodes/{node}/apt/update` liefert die verfügbaren Updates. Dafür reichen die schon hinterlegten API-Zugangsdaten. **Aktualisieren:** Die Proxmox-API hat keinen Endpunkt, der die Updates wirklich einspielt (`apt dist-upgrade`). Für diesen Schritt ist SSH also nötig. Auf Proxmox sollte dabei **`apt dist-upgrade`/`full-upgrade`** laufen, nicht `apt upgrade`, weil Proxmox das ausdrücklich so vorgibt. **Snapshot:** In `_execute_update` wird der Snapshot bei `type == "proxmox"` immer übersprungen, und im Log erscheint ein Hinweis wie "Proxmox-Host – kein Snapshot möglich". Im Frontend werden `SnapshotBadge`, die Snapshot-Option und die Snapshot-Verwaltung für diesen Typ ausgeblendet. ## Offene Punkte - **SSH-Zugang zum Node:** Soll es in den Proxmox-Einstellungen eigene SSH-Felder geben (Port, Benutzer, Key/Passwort), oder werden die Nodes automatisch als `Server`-Einträge angelegt und dort gepflegt? Das API-Passwort von `root@pam` als SSH-Passwort wiederzuverwenden wäre bequem, sollte aber höchstens als Voreinstellung dienen. - **Nodes anlegen:** Automatisch aus `GET /nodes` beim Speichern bzw. Testen des Proxmox-Eintrags, oder per Hand einzeln auswählen? - **Neustart:** Nach einem Kernel-Update braucht der Host einen Neustart, und der betrifft alle VMs/LXCs darauf, eventuell auch PatchPilot selbst. Mindestens ein Hinweis "Neustart erforderlich" (`/var/run/reboot-required`) wäre sinnvoll. Ein automatischer Neustart gehört nicht in dieses Issue. - **Repository-Hinweis:** Ist das Enterprise-Repo ohne Subscription aktiv, schlägt `apt update` mit 401 fehl. Diese Fehlermeldung sollte verständlich im Scan-Ergebnis stehen. ## Akzeptanzkriterien - [x] Proxmox-Nodes werden beim manuellen und beim automatischen Scan mitgeprüft - [x] Verfügbare Updates auf Proxmox-Nodes erscheinen im Dashboard und in der Updateliste - [x] Ein Update auf einem Proxmox-Node lässt sich starten (Live-Log, `dist-upgrade`) und landet in der Historie - [x] Für Proxmox-Nodes wird nie ein Snapshot versucht; die Snapshot-UI ist für sie ausgeblendet - [x] Matrix-Benachrichtigungen funktionieren für Proxmox-Nodes wie für andere Server - [x] Tests für Scan und Update mit übersprungenem Snapshot beim Typ `proxmox`

AxonByteDev added the

feat

prio

normal

labels

2026-09-26 04:42:51 +00:00

AxonByteDev referenced this issue

2026-09-26 05:03:49 +00:00

Backup & Wiederherstellung + Einstellungen in Kategorien mit Untermenü #17

AxonByteDev referenced this issue from a commit

2026-09-26 06:13:23 +00:00

refactor: SSH-Verbindung zentral in ssh_utils, Anmeldung mit Proxmox-Zugangsdaten (#13)