Self Update DE

Self-Update

🌐 English · Deutsch

Das Dashboard kann sich selbst aus GitHub aktualisieren – neuesten Code holen, neu bauen und den Dienst neu starten – direkt von der Seite /system. Das ist doppelt abgesichert: Das Feature muss mit ENABLE_SELF_UPDATE=true aktiviert sein, und der Nutzer muss Bot-Owner sein. Intern führt es deploy/update.sh aus und streamt den Live-Fortschritt. Das einzige manuelle Setup ist, dem Dienst-User das Neustarten des Dienstes zu erlauben – dafür wird eine polkit-Regel empfohlen.

Aktivieren

In der .env:

ENABLE_SELF_UPDATE=true

Ist es aus (Default), erscheint der Update-Button nicht. Ist es an, zeigt sich der Button auf /system nur für den Bot-Owner. Siehe Konfiguration.

Was es tut

Ein Klick auf Update führt deploy/update.sh aus, das:

1. Das Repo holt und hart zurücksetzt auf origin/<branch> (git fetch --prune + git reset --hard). Ein Hard-Reset bedeutet: Lokale Änderungen an getrackten Dateien blockieren das Update nie; untrackte Dateien wie .env bleiben unangetastet.
2. Baut (npm ci, mit Fallback auf npm install, dann npm run build).
3. Den systemd-Dienst neu startet.

Das Skript schreibt Status-Marker, auf die die UI achtet: ===UPDATE_DONE=== (Build fertig), ===UPDATE_ERROR=== (Fehler) und ===RESTART_SKIPPED=== (Build ok, aber Dienst konnte nicht neu gestartet werden).

Live-Status in der UI

Die Seite /system pollt das Update-Log und zeigt die Phase:

Phase	Bedeutung
building	Code geholt, Abhängigkeiten installiert, App baut neu.
restarting	Build fertig; der Dienst startet neu (die Seite verliert kurz die Verbindung und gewinnt sie wieder).
done	Update fertig; die Seite lädt auf der neuen Version neu.
error	Etwas schlug fehl – das Log erklärt was.

Auf Updates prüfen (ohne Rebuild)

Neben dem Self-Update-Button hat /system einen „Auf Updates prüfen"-Button (nur Bot-Owner, unabhängig von ENABLE_SELF_UPDATE verfügbar). Er vergleicht die laufende Dashboard-Version (aus der package.json) mit der Version im Git-Remote – git fetch --prune plus die package.json aus origin/<branch> – und meldet entweder „aktuell" oder „Update verfügbar" (mit beiden Versionsnummern). Er liest nur; er pullt, baut oder startet nichts.

Die Neustart-Berechtigung (polkit empfohlen)

Die Web-App läuft als unprivilegierter Dienst-User (z. B. dks) und kann eine systemd-Unit nicht selbst neu starten. Diese eine konkrete Berechtigung musst du erteilen.

Warum nicht sudoers? In vielen Setups läuft der Dienst von einem Mount mit nosuid, wo sudo schlicht nicht zu root werden kann. Eine sudoers-Regel hilft dann nicht. Die robuste Option ist eine polkit-Regel, die genau diesen User berechtigt, genau diese Unit zu verwalten.

Lege /etc/polkit-1/rules.d/49-dks-dashboard.rules an:

polkit.addRule(function(action, subject) {
  if (action.id == "org.freedesktop.systemd1.manage-units" &&
      action.lookup("unit") == "dks-dashboard.service" &&
      subject.user == "dks") {
    return polkit.Result.YES;
  }
});

Das erlaubt dem User dks, systemctl restart dks-dashboard (und sonst nichts) ohne Passwort auszuführen. Passe Unit-Name und User an, falls du sie im Installer geändert hast.

sudoers-Alternative (nur wo sudo zu root kann)

Kann dein sudo root erreichen, funktioniert auch eine enge sudoers-Regel:

dks ALL=(root) NOPASSWD: /usr/bin/systemctl restart dks-dashboard

Ist keines von beidem konfiguriert, läuft der Build trotzdem durch, der Neustart wird aber übersprungen (===RESTART_SKIPPED===); dann manuell mit sudo systemctl restart dks-dashboard neu starten.

Verwandte Seiten

• Konfiguration – ENABLE_SELF_UPDATE
• Deployment – der systemd-Dienst und deploy/update.sh
• Web-UI – die Seite /system