Update-Manager: Zustandsautomat, Prüfungen und Hintergrundaufgaben
Die gesamte Update-Kette: Registrierung, Prüfung, Zustandsautomat für Download und Vorbereitung, Aktivierungsschritte, Gesundheitsprüfung, Einstellungen, die zwei Hintergrundaufgaben und die Berechtigungsschlüssel.
Der Update-Manager steuert den Update-Prozess der Installation in Verbindung mit dem zentralen Release-Server. Der Controller ist schlank: Die Logik liegt in der Update-Dienstbibliothek, die SQL in den Modellen system/update und system/migrate. Rechte werden über einen Helfer mit canAction abgefragt; der automatische Extraktor zeigt daher keine Schlüssel, geprüft werden sie dennoch.
Datenmodell
Die Tabellennamen tragen in der Datenbank das eigene Präfix der Installation.
| Tabelle | Rolle |
|---|---|
update_config | Server, Kanal, Automatikmodus, Fenster, Intervall, Sicherungsziel, Registrierung (ID, Geheimnis, Schlüsselversion), Ergebnis der letzten Prüfung |
update_run | Update- und Sicherungsläufe mit Zustandsautomat |
update_log | Protokollzeilen je Lauf |
update_backup | Sicherungen (Dump + Code-Zip), Prüfstatus |
migration | Verlauf der versionierten Migrationen |
Ablauf
- Registrierung (
update.register): Installations-ID + Einmalcode an den Registrierungs-Endpunkt; zurückgegebenes Geheimnis, Schlüsselversion, Kanal und Betriebsmodell werden gespeichert. Im lokalen Modus (diese Installation ist der Release-Server) per lokalem Transport. - Prüfung (
update.check): signierte Anfrage mit ETag; Einstufungup_to_date,available,not_allowed,unreachable,revoked,unregistered. Es wird kein Paket geladen. - Vorbereitung (
update.start,update.advance,update.cancel): ein Lauf zur Zeit; der Automat schreitet in 15-Sekunden-Scheiben voran:authorize→download(fortsetzbar, höchstens 3 Versuche je Token) →verify(Manifest-Signatur, Größe, SHA-256, PHP- und Framework-Anforderungen, Mindestvorversion) →stage(Entpacken ins Staging, Baumprüfung) →preflight(Abweichung, Syntax, Abhängigkeiten, Schreibbarkeit, doppelter freier Platz) →backup→ready. Ohne Freigabe:waiting_approval. Abbruch nur vor der Aktivierung, mit Löschen von Staging und Teil-Download. - Aktivierung (
update.approve): Wartungsmodus mit 30 Minuten Selbstablauf; höchstens 60 s Warten auf den laufenden Zeitplaner-Worker (sonstwaiting_window); Installation des Wiederherstellungswerkzeugs der aktuellen Version, Web-Wiederherstellung für 24 Stunden; Differenzsicherung; versionierte Migrationen aus dem Staging (bei Fehler kein Codetausch); Messung der Schemakompatibilität; Verzeichnistausch mit zwei Umbenennungen (vorheriger Baum unterprevious/); Vendor-Abgleich; OPcache und Vorlagen-Cache geleert. - Gesundheitsprüfung: HTTP-Probe an den Catalog-Endpunkt
api/update.healthmit Einmaltoken; erreicht sich der Server nicht selbst,verify_pending, bestätigt durch den nächsten Admin-Seitenaufruf. Fehlerhafter neuer Code wird bei additivem Schema automatisch zurückgetauscht. - Erfolg: installierte Version erhöht, Benachrichtigung, Meldung an den Server;
previous/behält höchstens 2,failed/höchstens 1 Baum.update.retrywiederholt fehlgeschlagene versionierte Migrationen.
Hintergrundaufgaben
| Aufgabe | Verhalten |
|---|---|
update_check | Systemebene, immer aktiv; bei nicht registrierter Installation übersprungen; erzwungene Prüfung; ohne aktiven Lauf übernimmt sie zentrale Anforderungen (Installation nur bei erlaubter zentraler Installation, sonst Vorbereitung und Warten auf Freigabe); benachrichtigt einmal über neue Versionen; im Modus patch startet sie den berechtigten, lizenzierten PATCH-Schritt. Neuplanung: Intervall + 0–59 Minuten aus der Installations-ID + 0–9 Minuten Zufall. |
update_apply | Ereignisjob: treibt den aktiven Lauf ohne Warten auf die Worker-Sperre voran; wenn nicht abgeschlossen, nach 1 Minute, beim Warten auf Freigabe oder Fenster nach 15 Minuten erneut eingereiht, mit Duplikatschutz. |
Einstellungen und Validierung
update.save: Server-URL (nur https://), Kanal (stable, beta, dev), Automatikmodus (off, patch), Fenster (HH:MM-HH:MM), Intervall 1–168 Stunden, Übernahme direkter Auslieferung, Annahme zentraler Installationsanforderungen, Sicherungsziel (local, gdrive + Konto + Ordner), aufbewahrte Sicherungen 1–20, Benachrichtigungs-E-Mail. Fehlerschlüssel: error_value, error_window, error_backup_gdrive, error_https. Google-Konten werden nur mit der Berechtigung settings geladen.
Berechtigungen
| Schlüssel | Einstufung | Öffnet |
|---|---|---|
list | SYSTEM | Seite, Status, Läufe, Sicherungen, Migrationen |
check | SYSTEM | Prüfung |
download | SUBSCRIPTION | Vorbereitung; Fortschritt und Abbruch mit download oder install |
install | SYSTEM | Installation, Freigabe, Wiederholung |
settings, register | SYSTEM | Einstellungen, Registrierung |
debug | SYSTEM | von den Vorlagen nicht gelesen; keine wirksame Verwendung feststellbar |
Kein Inhaltsbereich: installationsweite technische Daten. Token, Manifest, Signatur und interner Sicherungsstatus werden nie mit Laufdaten ausgegeben. Der zentrale Server knüpft den Download an die Funktionsberechtigung system/update + download bei den Benutzern des Mandanten und an ein aktives Abonnement.
Bekannte Einschränkungen
Die gesamte Kette ist auf einer echten Datenbank mit lokalem Transport getestet; auf einem produktiven zentralen Server mit echtem Signaturschlüssel, HTTPS-Transport und echtem Drive-Archiv lief sie noch nicht.