Update

Een nieuwe release wordt altijd in een aparte map uitgepakt. Deze mag niet over de bestaande installatie worden gekopieerd of daar direct worden uitgepakt. Het nieuwe update.sh werkt daarna precies de als argument opgegeven instantie bij.

Voorbereiding en back-up

Voor elke update moet een volledige, gecontroleerde back-up beschikbaar zijn. Deze omvat ten minste:

  • De volledige instantiemap, met name core/config/QisutuConfig.pm

  • var/secure/security.key

  • De database

  • Eigen Apache-, proxy-, TLS- en systemd-aanpassingen

  • Indien nodig externe bijlagen of gekoppelde opslaglocaties

security.key is onmisbaar voor het herstellen van versleutelde e-mail-, OAuth- en tweefactorgeheimen. Bewaar deze beschermd samen met de bijbehorende instantieback-up.

Het nieuwe applicatiepakket voorbereiden

Pak het Qisutu 2.0.2-programmapakket uit in een aparte tijdelijke map, niet in de actieve instantie. Ga vervolgens naar de uitgepakte map met update.sh. Het voorbeeld gebruikt de structuur uit INSTALL.md; pas het pad aan de werkelijke uitpaklocatie aan.

cd /tmp/qisutu-neue-version/qisutu

Update starten

Productie-instantie:

sudo ./update.sh /opt/qisutu

Extra instantie:

sudo ./update.sh /opt/qisututest

De updater leest var/install/instance.conf en toont vóór bevestiging het installatiepad, de instantie-id, het webpad, de database en de systemd-service. Breek af als een van deze waarden niet bij de gewenste instantie hoort.

Updateverloop

Het script voert onder meer de volgende stappen uit:

  1. Controleren van releasechecksums, versies, schemabestand, Perl-syntaxis en programregistratie.

  2. Optioneel maken van een extra databasedump. Controleer vooraf de vrije ruimte onder /var/backups.

  3. Activeren van onderhoudsmodus, stoppen van de instantiedaemon en blokkeren van nieuwe e-mailophaalacties.

  4. Bijwerken van alle door de release beheerde programmabestanden; nieuwe bestanden worden toegevoegd en niet meer gepubliceerde beheerde bestanden verwijderd.

  5. Behouden van lokale instantiebestanden, configuraties, logboeken, runtimegegevens en beveiligingssleutel.

  6. Vergelijken van het databaseschema en uitvoeren van alle nog niet geregistreerde SQL- en Perl-migraties.

  7. Doelstatus opnieuw controleren en daemon starten.

Nacontrole

Controleer na succesvolle afronding:

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

Meld u daarna aan, controleer de weergegeven Qisutu- en databaseversie en test ten minste aanmelden, ticketweergave, e-mail ophalen en e-mail verzenden. Bij meerdere instanties wordt deze controle voor elke bijgewerkte instantie afzonderlijk uitgevoerd.

Mislukte update

Voer het script niet herhaaldelijk uit zonder oorzaakanalyse. Bewaar de uitvoer en logboeken en controleer vrije ruimte, databasetoegang, bestandsrechten en servicestatus. Als de toestand niet duidelijk is, herstel dan de eerder gecontroleerde volledige back-up van programmamap en database samen.

Bijwerken naar 2.0.2

Applicatie en database worden 2.0.2; de interne API blijft 1.0. Schemasynchronisatie voegt chat, ticketaanwezigheid, rapportplannen met ontvangers en logs, service-CI-relaties, FAQ-bijlagen en de optionele processjabloonverwijzing op formulieren toe. Deze aanvullingen verwijderen geen bestaande gegevens.

Gebruik update.sh uit het nieuwe programmapakket voor de expliciet geselecteerde instantie. Sphinx-bronnen bijwerken of build-all.bat uitvoeren werkt de Qisutu-applicatie en database niet bij.

De updater maakt geen automatische programmaback-up. Er moet vooraf een volledige back-up van instantie en database bestaan, inclusief var/secure/security.key. Na een fout tijdens wijzigingen blijft onderhoudsmodus actief. Los de oorzaak op en voer dezelfde update opnieuw uit; overschrijf niet willekeurig losse programma- of databasebestanden.

Controleer daarna versies, login, e-mail, chat en overdracht, rapporten, FAQ-download en service-CI-koppelingen. Test een formulierproces alleen met geïnstalleerde en ingeschakelde KimProcesses.