Versions-Check-Scripts für Software außerhalb von apt (neuer Menüpunkt „Software“ + Dashboard) #14

New issue

Open

opened 2026-09-26 04:49:47 +00:00 by AxonByteDev · 0 comments

AxonByteDev commented

2026-09-26 04:49:47 +00:00

Owner

Problem

Manche Software lässt sich mit apt update gar nicht auf neue Versionen prüfen, zum Beispiel Paperless-ngx, Nginx Proxy Manager oder andere Docker-, Git- oder Binär-Installationen. Ob es davon eine neue Version gibt, sieht man in PatchPilot nicht. Man muss selbst auf GitHub nachsehen und merkt deshalb oft nicht, dass man das passende Update-Script laufen lassen sollte.

Ziel

Versions-Check-Scripts: Man kann eigene Scripts anlegen, die die installierte Version einer Software auf einem Server auslesen und die neueste verfügbare Version ermitteln, zum Beispiel über die GitHub-Releases-API. Wie beide Versionen ermittelt werden, bestimmt das Script komplett selbst.
Geplant ausführen: Diese Checks laufen per Zeitplan (Cron + Zeitzone), wie die bestehenden Script-Zeitpläne, und lassen sich auch von Hand starten.
Neuer Menüpunkt „Software“: Eine eigene Seite listet alle überwachten Programme mit Server, installierter Version, neuester Version, Zeitpunkt des letzten Checks und Status (aktuell / Update verfügbar / Fehler).
Dashboard: Wenn für ein Programm eine neue Version verfügbar ist, zeigt das Dashboard einen Hinweis, damit man weiß, dass das Update-Script fällig ist.
Optional: Update-Script verknüpfen. Zu jedem Eintrag kann man ein bestehendes Script aus „Scripts“ hinterlegen und es direkt von der Software-Seite aus starten.

Stand im Code

backend/database.py: Script (Inhalt, target_servers, create_snapshot), ScriptRun (Ausgabe, Status) und ScriptSchedule (cron_expr, timezone, server_ids) gibt es schon.
backend/routers/scripts.py → _run_script() führt Scripts per SSH auf dem Zielserver aus. Die Ausgabe landet als Text in ScriptRun.output, strukturierte Rückgabewerte gibt es bisher nicht.
backend/scheduler.py → _make_script_runner() / add_script_schedule() plant Scripts schon mit Cron und Zeitzone ein. Darauf lässt sich direkt aufbauen.

Lösungsvorschlag

Script-Typ: Script bekommt ein Feld kind = "action" | "version_check". Die bisherigen Scripts sind action. So lassen sich Editor, SSH-Ausführung, Zeitpläne und Live-Log wiederverwenden.

Ausgabeformat: Ein Versions-Check-Script gibt am Ende eine Zeile mit einem festen Präfix aus, die PatchPilot auswertet, zum Beispiel:

#!/bin/bash
# Paperless-ngx: installierte Version aus dem Container, neueste von GitHub
CURRENT=$(docker exec paperless cat /usr/src/paperless/src/paperless/version.py | grep -oP '\d+\.\d+\.\d+')
LATEST=$(curl -s https://api.github.com/repos/paperless-ngx/paperless-ngx/releases/latest | jq -r .tag_name | sed 's/^v//')
echo "PATCHPILOT_VERSION {\"name\":\"Paperless-ngx\",\"current\":\"$CURRENT\",\"latest\":\"$LATEST\"}"

name: Anzeigename (optional, sonst der Script-Name)
current: installierte Version
latest: neueste Version
Optional update_available (bool): damit kann das Script selbst entscheiden, falls ein einfacher Versionsvergleich nicht reicht, etwa bei Datums-Tags oder latest-Images. Fehlt das Feld, gilt current != latest als „Update verfügbar“.
Ein Script kann mehrere solche Zeilen ausgeben, um mehrere Programme auf einmal zu prüfen.
Fehlt die Zeile, ist das JSON ungültig oder endet das Script mit Exit-Code ≠ 0, bekommt der Eintrag den Status Fehler, und der Log wird angezeigt.

Datenmodell: Eine neue Tabelle, zum Beispiel SoftwareVersion, mit server_id, script_id, name, current_version, latest_version, update_available, checked_at, status, error_message und optional update_script_id. Jeder Check aktualisiert pro Server und Programmname genau einen Eintrag, damit die Tabelle nicht mit jeder Prüfung wächst.

Frontend:

Neue Seite Software.tsx mit Menüpunkt „Software“: eine Tabelle mit den Spalten oben, Filter „nur Updates“ und den Buttons „Jetzt prüfen“ und „Update-Script starten“ (wenn eines verknüpft ist).
Dashboard: eine Kachel bzw. Liste „Software-Updates verfügbar“ mit Programm, Server und alt → neu.
Scripts.tsx: beim Anlegen den Typ „Versions-Check“ auswählen, am besten mit einer Beispielvorlage wie oben.

Benachrichtigung (optional): Ein Matrix-Ereignis „Neue Software-Version verfügbar“, das sich wie die anderen Ereignisse einzeln ein- und ausschalten lässt (vgl. #6). Es geht nur raus, wenn sich latest gegenüber dem letzten Check geändert hat, damit dieselbe Meldung nicht bei jedem Lauf wiederkommt.

Offene Punkte

Ausführungsort: Läuft der Check immer per SSH auf dem Zielserver? Alternativ könnte er ohne Zielserver lokal im PatchPilot-Container laufen, wenn nur die neueste Version abgefragt wird. Vorschlag: vorerst nur per SSH auf dem Zielserver, weil die installierte Version sowieso von dort kommt.
GitHub-Limit: Die API erlaubt ohne Token 60 Anfragen pro Stunde und IP. Bei vielen Checks könnte eine globale Einstellung für ein GitHub-Token nützlich sein, das dem Script als Umgebungsvariable übergeben wird. Das kann auch ein eigenes Issue werden.
Snapshot: Für Versions-Check-Scripts ergibt ein Snapshot keinen Sinn, die Option wird für diesen Typ ausgeblendet.

Akzeptanzkriterien

Beim Anlegen eines Scripts lässt sich der Typ „Versions-Check“ auswählen
Versions-Checks laufen per Zeitplan und lassen sich von Hand starten
Die PATCHPILOT_VERSION-Ausgabe wird ausgewertet (auch mehrere pro Lauf), Fehler sind im Status sichtbar
Die neue Seite „Software“ zeigt Programm, Server, alte und neue Version, letzten Check und Status
Das Dashboard zeigt an, wenn für ein Programm eine neue Version verfügbar ist
Optional: Ein Update-Script lässt sich verknüpfen und von der Software-Seite aus starten
Tests für das Auswerten der Ausgabe (gültig, ungültig, mehrere Einträge, update_available überschrieben)

## Problem Manche Software lässt sich mit `apt update` gar nicht auf neue Versionen prüfen, zum Beispiel **Paperless-ngx**, **Nginx Proxy Manager** oder andere Docker-, Git- oder Binär-Installationen. Ob es davon eine neue Version gibt, sieht man in PatchPilot nicht. Man muss selbst auf GitHub nachsehen und merkt deshalb oft nicht, dass man das passende Update-Script laufen lassen sollte. ## Ziel 1. **Versions-Check-Scripts:** Man kann eigene Scripts anlegen, die die **installierte Version** einer Software auf einem Server auslesen und die **neueste verfügbare Version** ermitteln, zum Beispiel über die GitHub-Releases-API. Wie beide Versionen ermittelt werden, bestimmt das Script komplett selbst. 2. **Geplant ausführen:** Diese Checks laufen per Zeitplan (Cron + Zeitzone), wie die bestehenden Script-Zeitpläne, und lassen sich auch von Hand starten. 3. **Neuer Menüpunkt „Software“:** Eine eigene Seite listet alle überwachten Programme mit Server, installierter Version, neuester Version, Zeitpunkt des letzten Checks und Status (aktuell / Update verfügbar / Fehler). 4. **Dashboard:** Wenn für ein Programm eine neue Version verfügbar ist, zeigt das Dashboard einen Hinweis, damit man weiß, dass das Update-Script fällig ist. 5. **Optional: Update-Script verknüpfen.** Zu jedem Eintrag kann man ein bestehendes Script aus „Scripts“ hinterlegen und es direkt von der Software-Seite aus starten. ## Stand im Code - `backend/database.py`: `Script` (Inhalt, `target_servers`, `create_snapshot`), `ScriptRun` (Ausgabe, Status) und `ScriptSchedule` (`cron_expr`, `timezone`, `server_ids`) gibt es schon. - `backend/routers/scripts.py` → `_run_script()` führt Scripts per SSH auf dem Zielserver aus. Die Ausgabe landet als Text in `ScriptRun.output`, strukturierte Rückgabewerte gibt es bisher nicht. - `backend/scheduler.py` → `_make_script_runner()` / `add_script_schedule()` plant Scripts schon mit Cron und Zeitzone ein. Darauf lässt sich direkt aufbauen. ## Lösungsvorschlag **Script-Typ:** `Script` bekommt ein Feld `kind = "action" | "version_check"`. Die bisherigen Scripts sind `action`. So lassen sich Editor, SSH-Ausführung, Zeitpläne und Live-Log wiederverwenden. **Ausgabeformat:** Ein Versions-Check-Script gibt am Ende eine Zeile mit einem festen Präfix aus, die PatchPilot auswertet, zum Beispiel: ```bash #!/bin/bash # Paperless-ngx: installierte Version aus dem Container, neueste von GitHub CURRENT=$(docker exec paperless cat /usr/src/paperless/src/paperless/version.py | grep -oP '\d+\.\d+\.\d+') LATEST=$(curl -s https://api.github.com/repos/paperless-ngx/paperless-ngx/releases/latest | jq -r .tag_name | sed 's/^v//') echo "PATCHPILOT_VERSION {\"name\":\"Paperless-ngx\",\"current\":\"$CURRENT\",\"latest\":\"$LATEST\"}" ``` - `name`: Anzeigename (optional, sonst der Script-Name) - `current`: installierte Version - `latest`: neueste Version - Optional `update_available` (bool): damit kann das Script selbst entscheiden, falls ein einfacher Versionsvergleich nicht reicht, etwa bei Datums-Tags oder `latest`-Images. Fehlt das Feld, gilt `current != latest` als „Update verfügbar“. - Ein Script kann **mehrere** solche Zeilen ausgeben, um mehrere Programme auf einmal zu prüfen. - Fehlt die Zeile, ist das JSON ungültig oder endet das Script mit Exit-Code ≠ 0, bekommt der Eintrag den Status **Fehler**, und der Log wird angezeigt. **Datenmodell:** Eine neue Tabelle, zum Beispiel `SoftwareVersion`, mit `server_id`, `script_id`, `name`, `current_version`, `latest_version`, `update_available`, `checked_at`, `status`, `error_message` und optional `update_script_id`. Jeder Check aktualisiert pro Server und Programmname genau einen Eintrag, damit die Tabelle nicht mit jeder Prüfung wächst. **Frontend:** - Neue Seite `Software.tsx` mit Menüpunkt „Software“: eine Tabelle mit den Spalten oben, Filter „nur Updates“ und den Buttons „Jetzt prüfen“ und „Update-Script starten“ (wenn eines verknüpft ist). - Dashboard: eine Kachel bzw. Liste „Software-Updates verfügbar“ mit Programm, Server und `alt → neu`. - `Scripts.tsx`: beim Anlegen den Typ „Versions-Check“ auswählen, am besten mit einer Beispielvorlage wie oben. **Benachrichtigung (optional):** Ein Matrix-Ereignis „Neue Software-Version verfügbar“, das sich wie die anderen Ereignisse einzeln ein- und ausschalten lässt (vgl. #6). Es geht nur raus, wenn sich `latest` gegenüber dem letzten Check geändert hat, damit dieselbe Meldung nicht bei jedem Lauf wiederkommt. ## Offene Punkte - **Ausführungsort:** Läuft der Check immer per SSH auf dem Zielserver? Alternativ könnte er ohne Zielserver lokal im PatchPilot-Container laufen, wenn nur die neueste Version abgefragt wird. Vorschlag: vorerst nur per SSH auf dem Zielserver, weil die installierte Version sowieso von dort kommt. - **GitHub-Limit:** Die API erlaubt ohne Token 60 Anfragen pro Stunde und IP. Bei vielen Checks könnte eine globale Einstellung für ein GitHub-Token nützlich sein, das dem Script als Umgebungsvariable übergeben wird. Das kann auch ein eigenes Issue werden. - **Snapshot:** Für Versions-Check-Scripts ergibt ein Snapshot keinen Sinn, die Option wird für diesen Typ ausgeblendet. ## Akzeptanzkriterien - [ ] Beim Anlegen eines Scripts lässt sich der Typ „Versions-Check“ auswählen - [ ] Versions-Checks laufen per Zeitplan und lassen sich von Hand starten - [ ] Die `PATCHPILOT_VERSION`-Ausgabe wird ausgewertet (auch mehrere pro Lauf), Fehler sind im Status sichtbar - [ ] Die neue Seite „Software“ zeigt Programm, Server, alte und neue Version, letzten Check und Status - [ ] Das Dashboard zeigt an, wenn für ein Programm eine neue Version verfügbar ist - [ ] Optional: Ein Update-Script lässt sich verknüpfen und von der Software-Seite aus starten - [ ] Tests für das Auswerten der Ausgabe (gültig, ungültig, mehrere Einträge, `update_available` überschrieben)

AxonByteDev added the

feat

prio

normal

labels

2026-09-26 04:49:47 +00:00

AxonByteDev referenced this issue

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

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