CLI: Wartungsmodus ein/ausschalten + Upgrade

Hallo zusammen,

um saubere automatisierte Backups durchzuführen (z.B. per cronjob), wäre es toll, wenn das CLI-Script in der Lage wäre, per Command den Wartungsmodus zu aktivieren.

Dadurch könnte man die Woltlab Software in einen definierten inaktiven Zustand versetzen, das Backup fahren und dann wieder aktivieren.

Beispiel Use case anhand eines Backup-Scripts (wobei das mit dem CLI-User noch zu diskutieren ist):

#!/bin/bash

/path/to/forum/cli.php -u <CLI USER> -t <CLI TOKEN> --maintenance-on

mysqldump [...]
# pack web dir

/path/to/forum/cli.php -u <CLI USER> -t <CLI TOKEN> --maintenance-off

Außerdem wäre es schön, wenn das CLI-Script um eine Update-Funktionalität erweitert werden könnte.

Ich stelle mir sowas wie bei nextcloud vor. Dort kann man mit dem "updater.phar" genannten interaktiven CLI-Tool saubere und Laufzeit-unabhängige Updates fahren (Siehe https://docs.nextcloud.com/ser…ommand-line-based-updater).

So könnten beim Update die Webserver-Konfiguration als eventuelle Fehlerquelle (Timeouts etc.) ausgeschlossen werden.

Quote from Donner

Wenn ich nicht irre, gibt es zwar Workarounds

Welche Workarounds gibt es da? Ich würde das gerne mal testen, zumindest bis was brauchbares von offizieller Seite da ist.

Um das Thema mit dem Updater aufgrund des Beitrags hier nochmal aufzugreifen, ich stelle mir sowas in der Art vor:

sudo -u www-data php /var/www/wbb/updater/updater.php

Ggf. könnte auch die zu installieren Pakete manuell heruntergeladen, im Dateisystem bereitgestellt und als Argumente an den Updater übergeben werden, um mögliche Probleme beim automatischen Download von den Paketquellen zu umgehen.

Etwa so:

sudo -u www-data php /var/www/wbb/updater/updater.php --package=/tmp/com.woltlab.wbb.tar.gz

Das Thema sollte von den Entwicklern auf jeden Fall überdacht werden.

Gerade richtig große Foren könnten davon profitieren.

Außerdem wäre vielleicht eine Art "Checkpointing" nicht schlecht, um unterbrochene Updates ab einem bestimmten Punkt nochmal wieder aufzunehmen.

Quote from ilou

Wieso sollte man zum Updaten auf einmal eine andere CLI verwenden als die vom WSC bereits eingebauten? Du hast doch sogar oben in deinem ersten Beitrag die im WSC eingebauten CLI verwendet.

Quote from lenrforum

ich stelle mir sowas in der Art vor

Wie das Ding am Ende heißt ist mir ehrlich gesagt völlig egal. Das war nur ein Beispiel.

Hello Alexander Ebert,

danke für die ausführliche Antwort!

Quote from Alexander Ebert

Bei einem Upgrade des Core wird beispielsweise in den ersten Schritten noch das "alte" Paketsystem verwendet und ab dem Deployment der Dateien wird bei folgenden Schritten bereits das neue Paketsystem verwendet. Nun kommt es immer wieder mal vor, dass das selbe PIP mehrfach in einem Schritt vorkommt, aber zwischen den Schritten das PIP selbst gegen eine neuere Version ausgetauscht wurde.

Deutet diese Problematik aber nicht auf ein tiefer greifendes Problem im Update. bzw. Paketmanager-System hin?

Das klingt für mich aus der Entfernung doch erstmal alles sehr hakelig.

Quote from Alexander Ebert

Ein Update via CLI ist daher technisch nicht machbar.

Wäre es nicht möglich, mit dem CLI Prozess bei der Ausführung mehrere Unterprozesse nacheinander zu starten (im Zweifel mittels popen())?

Diese würden dann ebenfalls bei der Prozesskreierung die Klassen neu laden und es hätte letzlich den selben Effekt wie die HTTP Requests.

Quote from Alexander Ebert

der Praxisnutzen fällt leider sehr überschaubar aus.

Sehr schade. Ich denke, dass WENN das Update unterstützt werden WÜRDE, der Praxisnutzen auch deutlich höher wäre.

Ich habe nämlich keine Lust 30 - 60 min Backups einzuspielen nur weil ich beim Browser Update einen Gateway Timeout vom nginx bekomme...