CLI: Wartungsmodus ein/ausschalten + Upgrade

  • App
    WoltLab Suite Core

    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):

    Bash
    #!/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/server/20/admi…e-based-updater).

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

    Einmal editiert, zuletzt von lenrforum (6. Oktober 2020 um 09:54)

  • Wenn ich nicht irre, gibt es zwar Workarounds, aber ich würde mir auch eine "korrekte" Möglichkeit wünschen, um den Wartungsmodus per CLI bzw. aus einem Shell-Script heraus (de-)aktivieren zu können.

    Gruß aus Südhessen

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

    Code
    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:

    Code
    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.

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

    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.

  • 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.

    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.

    • Offizieller Beitrag

    Hallo,

    ein Update oder Upgrade per CLI hat leider so seine Tücken, weil PHP-Klassen zur Laufzeit nicht neu geladen werden können. Die größte Stärke (und wahrscheinlich auch größte Schwäche) des Paketsystems ist die Fähigkeit, sich selbst zu modifizieren.

    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.

    Es ist nicht auf PIPs begrenzt, prinzipiell ist jede PHP-Klasse betroffen, die vor dem Ersetzen der Klasse geladen wurde und danach in der neuen Fassung aufgerufen werden soll. Aus Erfahrung kann ich sagen, dass dies deutlich häufiger auftritt, als man gemeinhin annehmen würde. Das Update über das ACP hat den großen Vorteil, dass wir PIPs je nach Anweisung in separaten Requests ausführen, womit wir das Problem der "Vorbelastung" komplett umgehen.

  • Hello Alexander Ebert,

    danke für die ausführliche Antwort!

    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.

    • Offizieller Beitrag

    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.

    Wir reden hier nicht von einem unbeabsichtigten Seiteneffekt, sondern von einem gewollten Feature. Das Paketsystem über die Administrationsoberfläche arbeitet mit einzelnen PHP-Requests um (a) Laufzeitlimits zu umgehen und (b) die Möglichkeit Dateien auszutauschen und mit Folgerequests die neuen Versinen aufzurufen.

    Das lässt sich halt nicht auf CLI übertragen, weil diese per Definition stateful arbeitet. Ein Update via CLI ist daher technisch nicht machbar.

  • 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.

    • Offizieller Beitrag

    Das Paketsystem wurde von Anfang nur auf die Interaktion über den Browser konzipiert. Die CLI-API kam erst sehr viel später und unterstützt nur einen Teil des Funktionsumfangs, bietet keine wirkliche Automatisierung und wird von uns aktiv nicht verwendet, wodurch sich die Stabilität rein auf synthetische Tests stützt. Der Aufwand den man betreiben müsste, um die CLI-API sauber auf dasselbe Niveau zu bekommen, ist unverhältnismäßig hoch und der Praxisnutzen fällt leider sehr überschaubar aus.

  • 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...

  • Alexander Ebert 9. Februar 2021 um 14:01

    Hat das Label Nicht geplant hinzugefügt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!