Aktualisierung

Ein neues Release wird immer in ein separates Verzeichnis entpackt. Es darf nicht über die vorhandene Installation kopiert oder direkt dort entpackt werden. Das neue update.sh aktualisiert anschließend genau die als Argument angegebene Instanz.

Vorbereitung und Sicherung

Vor jedem Update muss eine vollständige, geprüfte Sicherung vorhanden sein. Dazu gehören mindestens:

  • das vollständige Instanzverzeichnis, insbesondere core/config/QisutuConfig.pm

  • var/secure/security.key

  • die Datenbank

  • eigene Apache-, Proxy-, TLS- und systemd-Anpassungen

  • bei Bedarf externe Anhänge oder angebundene Speicherorte

security.key ist unverzichtbar, um verschlüsselte Mail-, OAuth- und Zwei-Faktor-Geheimnisse wiederherzustellen. Bewahren Sie ihn geschützt und zusammen mit der passenden Instanzsicherung auf.

Neues Programmpaket vorbereiten

Entpacken Sie das Programmpaket für Qisutu 2.0.1 in ein separates temporäres Verzeichnis, nicht in die laufende Instanz. Wechseln Sie anschließend in den enthaltenen Ordner mit update.sh. Das folgende Beispiel verwendet den in INSTALL.md beschriebenen Aufbau; passen Sie nur den Pfad an Ihren tatsächlichen Entpackort an.

cd /tmp/qisutu-neue-version/qisutu

Update starten

Produktivinstanz:

sudo ./update.sh /opt/qisutu

Zusätzliche Instanz:

sudo ./update.sh /opt/qisututest

Der Updater liest var/install/instance.conf und zeigt vor der Bestätigung Installationspfad, Instanzkennung, Webpfad, Datenbank und systemd-Dienst an. Brechen Sie ab, wenn einer dieser Werte nicht zur gewünschten Instanz gehört.

Ablauf des Updates

Das Skript führt unter anderem folgende Schritte aus:

  1. Prüfen der Release-Prüfsummen, Versionsstände, Schemadatei, Perl-Syntax und Programmregistrierung.

  2. Optionales Erstellen eines zusätzlichen Datenbankdumps. Prüfen Sie vorher den freien Platz unter /var/backups.

  3. Aktivieren des Wartungsmodus, Stoppen des instanzbezogenen Daemons und Sperren neuer Mailabrufe.

  4. Aktualisieren aller vom Release verwalteten Programmdateien; neue Dateien werden ergänzt und nicht mehr veröffentlichte verwaltete Dateien entfernt.

  5. Erhalten der lokalen Instanzdateien, Konfigurationen, Protokolle, Laufzeitdaten und des Sicherheitsschlüssels.

  6. Abgleichen des Datenbankschemas und Ausführen aller noch nicht protokollierten SQL- und Perl-Migrationen.

  7. Erneutes Prüfen des Zielstands und Starten des Daemons.

Nachkontrolle

Prüfen Sie nach erfolgreichem Abschluss:

systemctl status qisutu-daemon.service
journalctl -u qisutu-daemon.service --since today

Melden Sie sich anschließend an, prüfen Sie die angezeigte Qisutu- und Datenbankversion und testen Sie mindestens Anmeldung, Ticketansicht, E-Mail-Abruf und E-Mail-Versand. Bei mehreren Instanzen wird diese Kontrolle für jede aktualisierte Instanz getrennt durchgeführt.

Fehlgeschlagenes Update

Starten Sie das Skript nicht wiederholt ohne Ursachenanalyse. Sichern Sie die Ausgabe und die Protokolle, prüfen Sie freien Speicherplatz, Datenbankzugriff, Dateirechte und den Dienststatus. Ist der Zustand nicht eindeutig, stellen Sie die zuvor geprüfte Komplettsicherung von Programmverzeichnis und Datenbank gemeinsam wieder her.

Besonderheiten des Updates auf 2.0.1

Programm- und Datenbankstand werden auf 2.0.1 aktualisiert; die interne Zusatzmodul-API bleibt 1.0. Der Schemaabgleich ergänzt unter anderem internen Chat, Ticketanwesenheit, Berichtsversand mit Empfängern und Versandprotokoll, Service-CI-Zuordnungen, FAQ-Anhänge sowie die optionale Prozessvorlage an Formularen. Bestehende Daten werden durch diese Ergänzungen nicht gelöscht.

Verwenden Sie das update.sh aus dem neuen Programmpaket für die ausdrücklich ausgewählte Instanz. Das Aktualisieren dieser Sphinx-Quelldateien oder das Ausführen von build-all.bat aktualisiert nicht die Qisutu-Anwendung oder deren Datenbank.

Das Updateprogramm legt keine automatische Programmsicherung an. Eine vollständige Sicherung von Instanz und Datenbank einschließlich var/secure/security.key muss vorher vorhanden sein. Bei einem Fehler nach begonnenen Änderungen bleibt die Wartungssperre aktiv. Beheben Sie die gemeldete Ursache und führen Sie dasselbe Update erneut aus; überschreiben Sie nicht unkontrolliert einzelne Programm- oder Datenbankdateien.

Prüfen Sie anschließend Version, Anmeldung, Mailabruf, Chat und Ticketübergabe, einen Berichtsversand, einen FAQ-Download und die Service-CI-Zuordnung. Einen Formularprozess prüfen Sie nur, wenn KimProcesses tatsächlich installiert und aktiviert ist.