Auto-Updates

EternalSystem aktualisiert sich selbst: Die REST-API prüft regelmäßig das öffentliche Release-Repo und meldet neue Versionen in die Datenbank. Proxy, Spigot-Server, API und Dashboard holen sich daraufhin jeweils ihre eigene neue Version. Aktiv wird ein Update immer erst nach einem Neustart der jeweiligen Komponente.

Was wohin geht

Die API fasst das Web-Root des Dashboards nie an – das erledigt der Web-Updater (siehe unten).

Einrichten

1. API (api.yml)

updates:
  enabled: true
  repo: "LeqitAdam/EternalV1-releases"   # öffentliches Release-Repo, leer = keine Prüfung
  check-interval-minutes: 60
  restart-on-update: false     # true: API beendet sich nach dem Tausch (systemd Restart=always nötig)
  plugin-dirs: []              # Plugin-Ordner auf diesem Host, die direkt beliefert werden
  plugin-jar-name: "Eternal.jar"

enabled: false auf dem API-Host heißt: Die API meldet weiter neue Releases, installiert aber selbst nichts.

2. Server (config.yml auf Proxy und Spigots)

updates:
  enabled: true              # Standard
  check-interval-minutes: 60

3. Dashboard: Server → Updates

Recht: eternal.web.updates (Standard-Stufe Admin, braucht eternal.web.admin).

• Schalter Auto-Update – gilt netzwerkweit.
• Jetzt prüfen und Anzeige des neuesten Releases.
• Tabelle Versionen: installierte Version der REST-API, jedes Plugin-Ordners auf dem API-Host und jedes Servers (offline-Server sind markiert).
• Hinweise, wenn in der api.yml updates.repo fehlt oder updates.enabled: false gesetzt ist.

Plugin-Ordner (plugin-dirs)

Cloud-Services werden bei jedem Start aus ihrem Template gebaut. Ein plugins/update/Eternal.jar im laufenden Service wäre nach dem Neustart weg. Deshalb kopiert die API das Jar direkt in die Ordner, aus denen die Server ihre Plugins beziehen – z. B. CloudNet-Templates oder statische Server auf demselben Host:

updates:
  plugin-dirs:
    - /home/cloudnet/local/templates/Proxy/default/plugins
    - /home/cloudnet/local/templates/Lobby/default/plugins
    - /home/cloudnet/local/templates/Survival/default/plugins
  plugin-jar-name: "Eternal.jar"

• Ein Download, danach atomarer Tausch in jedem Ordner. Daneben liegt Eternal.jar.version als Marker.
• Alte Eternal-<ver>.jar im selben Ordner werden entfernt (sie würden sonst doppelt geladen).
• Services bekommen die neue Version beim nächsten Start/Neustart.
• In der config.yml innerhalb der Templates updates.enabled: false setzen – der Updater im Service würde sonst ins Leere laden.
• Statische Server einfach mit ihrem plugins/-Ordner aufnehmen. Die API schreibt direkt ins Plugin-Verzeichnis, also den Server danach neu starten.

Eternal Cloud: Cloud-Ordner automatisch dabei

Mit cloud.enabled: true in der api.yml ergänzt die API den Cloud-Ordner (cloud.directory, Standard cloud) automatisch in plugin-dirs. Der Node kopiert cloud/Eternal.jar beim Start in jeden Service – damit bekommt jeder neu gestartete Service automatisch die aktuelle Version. Services unter der Eternal Cloud schalten ihren eigenen Updater selbst ab, ein Eintrag in den Templates ist nicht nötig.

cloud:
  enabled: true
  directory: cloud
updates:
  plugin-dirs: []   # der Cloud-Ordner wird automatisch ergänzt

Dashboard (eigener Web-Host)

Läuft das Dashboard auf einem anderen Server als die API, übernimmt dort tools/web-updater/server.mjs die Updates (Node ≥ 18, keine Abhängigkeiten, kein unzip nötig). Bedient wird er im Dashboard unter Server → Wartung (Seite „Dashboard & Wartung“, Recht eternal.web.updates).

Installation

sudo mkdir -p /opt/eternal/web-updater
sudo cp tools/web-updater/server.mjs /opt/eternal/web-updater/
sudo cp tools/web-updater/eternal-web-updater.service /etc/systemd/system/
sudo editor /etc/systemd/system/eternal-web-updater.service   # API_URL, WEB_DIR, User
sudo chown -R www-data:www-data /var/www/html/eternal-web      # Elternordner von WEB_DIR muss schreibbar sein
sudo systemctl enable --now eternal-web-updater

Apache-Beispiel (der Updater hinter dem Dashboard, Wartungsdatei und Version nie cachen):

ProxyPass        /updater/ http://127.0.0.1:8099/ connectiontimeout=5 timeout=600
ProxyPassReverse /updater/ http://127.0.0.1:8099/
<Location /updater/>
    SetEnv no-gzip 1
</Location>
<FilesMatch "^(maintenance\.json|VERSION)$">
    Header set Cache-Control "no-cache, no-store, must-revalidate"
</FilesMatch>

Die FilesMatch-Regel muss nach einer allgemeinen Cache-Regel für .json stehen (die letzte Regel gewinnt).

Funktionen

• Installiert / neues Release einspielen, auch einen bestimmten Tag.
• Rollback auf den vorherigen Build.
• Auto-Update mit Intervall (Standard: aus, alle 15 Minuten, mindestens 5); respektiert zusätzlich den netzwerkweiten Schalter der API (GET /public/updates).
• Verlauf (Updates, Rollbacks, Wartung an/aus, Fehler; 50 Einträge).
• Rechteprüfung: Jeder Request trägt den Dashboard-Token, der Dienst fragt API_URL/me und verlangt eternal.web.updates.

Dateien: WEB_DIR/VERSION (installiertes Release), WEB_DIR/maintenance.json (Wartungsflag), STATE_DIR/updater.json (Einstellungen + Verlauf), STATE_DIR/previous/ (vorheriger Build).

Landing-Seite und Lizenz-Server

Für eigene Installationen von Landing-Seite und Lizenz-Server (beides auf einem Host) gibt es die gleiche Update-Funktion im Landing-Admin → Updates. Sie kann jedes Paket einzeln aktualisieren, zurückrollen und automatisch aktualisieren (Intervall einstellbar). Der Lizenz-Server übernimmt das selbst: Er lädt eternal-landing-<ver>.zip und eternal-license-server-<ver>.zip aus den Releases.

Einmalig einrichten (danach läuft alles über den Admin):

sudo chown -R eternal-license: /var/www/html/eternal-landing
sudo cp tools/license-server/eternal-license.service /etc/systemd/system/   # LANDING_DIR + ReadWritePaths
sudo cp tools/license-server/updater.mjs /opt/eternal/license-server/
sudo systemctl daemon-reload && sudo systemctl restart eternal-license

Wartungsmodus

Auf derselben Seite: Schalter, Nachricht und voraussichtliches Ende. Der Updater schreibt WEB_DIR/maintenance.json; das Dashboard prüft die Datei jede Minute und zeigt allen ohne eternal.web.updates eine Wartungsseite. Während ein Update eingespielt wird, passiert das automatisch. /login bleibt erreichbar, damit Admins hineinkommen; sie sehen oben einen Hinweis „Wartungsmodus aktiv“.

Versionen

Versionsvergleich: v1.2.3 > 1.2.3-SNAPSHOT > 1.2.2. Das Release-Repo enthält nur Binärdateien; die Updater brauchen keinen Token.

Typische Stolperfallen

• Nichts passiert: Einer der beiden Schalter ist aus, oder updates.repo fehlt in der api.yml.
• Neue Version ist da, aber nicht aktiv: Jar-Tausch wirkt erst nach dem Neustart des Servers bzw. der API.
• Plugin doppelt geladen: Im Plugin-Ordner liegen Eternal.jar und ein altes Eternal-<ver>.jar – die API räumt nur in plugin-dirs auf, in anderen Ordnern von Hand löschen.
• Web-Updater kann nicht tauschen: Der Dienst braucht Schreibrechte auf den Elternordner von WEB_DIR (atomarer Ordnertausch).
• Wartungsseite bleibt nach dem Ausschalten: maintenance.json wird gecacht – die FilesMatch-Regel fehlt oder steht vor der allgemeinen JSON-Regel.