Mise à jour

Une nouvelle version est toujours extraite dans un répertoire séparé. Elle ne doit pas être copiée par-dessus l’installation existante ni extraite directement dans celle-ci. Le nouveau update.sh met ensuite à jour exactement l’instance indiquée en argument.

Préparation et sauvegarde

Avant chaque mise à jour, une sauvegarde complète et vérifiée doit être disponible. Elle comprend au minimum :

  • Le répertoire complet de l’instance, notamment core/config/QisutuConfig.pm

  • var/secure/security.key

  • La base de données

  • Personnalisations propres à Apache, au proxy, à TLS et à systemd

  • Si nécessaire, pièces jointes externes ou emplacements de stockage connectés

security.key est indispensable pour restaurer les secrets chiffrés de messagerie, OAuth et d’authentification à deux facteurs. Conservez-le de manière protégée avec la sauvegarde correspondante de l’instance.

Préparer le nouveau paquet applicatif

Décompressez le paquet Qisutu 2.0.2 dans un répertoire temporaire distinct, et non dans l’instance en fonctionnement. Placez-vous ensuite dans le répertoire extrait contenant update.sh. L’exemple reprend la structure décrite dans INSTALL.md ; adaptez le chemin à votre emplacement réel.

cd /tmp/qisutu-neue-version/qisutu

Lancer la mise à jour

Instance de production :

sudo ./update.sh /opt/qisutu

Instance supplémentaire :

sudo ./update.sh /opt/qisututest

L’outil de mise à jour lit var/install/instance.conf et affiche avant confirmation le chemin d’installation, l’identifiant de l’instance, le chemin web, la base de données et le service systemd. Annulez si l’une de ces valeurs ne correspond pas à l’instance souhaitée.

Déroulement de la mise à jour

Le script effectue notamment les étapes suivantes :

  1. Vérification des sommes de contrôle de la version, des versions, du fichier de schéma, de la syntaxe Perl et de l’enregistrement des programmes.

  2. Création facultative d’un dump supplémentaire de la base de données. Vérifiez au préalable l’espace libre dans /var/backups.

  3. Activation du mode maintenance, arrêt du démon de l’instance et blocage des nouvelles récupérations de courrier.

  4. Mise à jour de tous les fichiers de programme gérés par la version ; les nouveaux fichiers sont ajoutés et les fichiers gérés qui ne sont plus publiés sont supprimés.

  5. Conservation des fichiers locaux de l’instance, configurations, journaux, données d’exécution et clé de sécurité.

  6. Comparaison du schéma de base de données et exécution de toutes les migrations SQL et Perl non encore enregistrées.

  7. Nouvelle vérification de l’état cible et démarrage du démon.

Contrôle final

Après la réussite de l’opération, vérifiez :

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

Connectez-vous ensuite, vérifiez les versions affichées de Qisutu et de la base de données, puis testez au minimum la connexion, l’affichage des tickets, la récupération et l’envoi des e-mails. En présence de plusieurs instances, ce contrôle est effectué séparément pour chaque instance mise à jour.

Échec de la mise à jour

Ne relancez pas le script de manière répétée sans analyser la cause. Conservez la sortie et les journaux, vérifiez l’espace libre, l’accès à la base de données, les droits des fichiers et l’état du service. Si l’état n’est pas clair, restaurez ensemble la sauvegarde complète précédemment vérifiée du répertoire du programme et de la base de données.

Particularités de la mise à jour vers 2.0.2

L’application et la base passent en 2.0.2 ; l’API interne des modules reste en 1.0. La synchronisation du schéma ajoute notamment chat interne, présence sur les tickets, planifications de rapports avec destinataires et journaux, relations service-CI, pièces jointes de FAQ et référence facultative au modèle de processus des formulaires. Ces ajouts ne suppriment pas les données existantes.

Utilisez le update.sh du nouveau paquet pour l’instance explicitement choisie. Mettre à jour les sources Sphinx ou exécuter build-all.bat ne met pas à jour l’application Qisutu ni sa base.

Le programme ne crée pas de sauvegarde automatique des fichiers applicatifs. Une sauvegarde complète de l’instance et de la base, y compris var/secure/security.key, doit exister auparavant. Si une erreur survient après le début des changements, le mode maintenance reste actif. Corrigez la cause et relancez la même mise à jour ; n’écrasez pas arbitrairement des fichiers applicatifs ou de base de données isolés.

Vérifiez ensuite versions, connexion, collecte e-mail, chat et transfert, envoi de rapport, téléchargement de FAQ et associations service-CI. Ne testez un processus de formulaire que si KimProcesses est installé et activé.