Aggiornamento

Una nuova release viene sempre estratta in una directory separata. Non deve essere copiata sopra l’installazione esistente né estratta direttamente al suo interno. Il nuovo update.sh aggiorna quindi esattamente l’istanza indicata come argomento.

Preparazione e backup

Prima di ogni aggiornamento deve essere disponibile un backup completo e verificato. Deve includere almeno:

  • L’intera directory dell’istanza, in particolare core/config/QisutuConfig.pm

  • var/secure/security.key

  • Il database

  • Personalizzazioni proprie di Apache, proxy, TLS e systemd

  • Se necessario, allegati esterni o posizioni di archiviazione collegate

security.key è indispensabile per ripristinare i segreti crittografati di posta, OAuth e autenticazione a due fattori. Conservarlo protetto insieme al backup corrispondente dell’istanza.

Preparare il nuovo pacchetto applicativo

Estrarre il pacchetto Qisutu 2.0.2 in una directory temporanea separata, non nell’istanza in esecuzione. Accedere quindi alla directory estratta contenente update.sh. L’esempio usa la struttura descritta in INSTALL.md; adattare il percorso alla posizione effettiva di estrazione.

cd /tmp/qisutu-neue-version/qisutu

Avviare l’aggiornamento

Istanza di produzione:

sudo ./update.sh /opt/qisutu

Istanza aggiuntiva:

sudo ./update.sh /opt/qisututest

L’updater legge var/install/instance.conf e mostra prima della conferma percorso di installazione, identificatore dell’istanza, percorso web, database e servizio systemd. Interrompere se uno di questi valori non appartiene all’istanza desiderata.

Procedura di aggiornamento

Lo script esegue, tra l’altro, i seguenti passaggi:

  1. Verifica dei checksum della release, delle versioni, del file di schema, della sintassi Perl e della registrazione dei programmi.

  2. Creazione facoltativa di un dump aggiuntivo del database. Controllare prima lo spazio libero in /var/backups.

  3. Attivazione della modalità manutenzione, arresto del daemon dell’istanza e blocco di nuovi recuperi della posta.

  4. Aggiornamento di tutti i file del programma gestiti dalla release; vengono aggiunti i nuovi file e rimossi i file gestiti non più pubblicati.

  5. Conservazione di file locali dell’istanza, configurazioni, registri, dati di esecuzione e chiave di sicurezza.

  6. Confronto dello schema del database ed esecuzione di tutte le migrazioni SQL e Perl non ancora registrate.

  7. Nuova verifica dello stato di destinazione e avvio del daemon.

Controllo successivo

Dopo il completamento riuscito, controllare:

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

Accedere quindi, controllare le versioni Qisutu e database visualizzate e testare almeno accesso, visualizzazione dei ticket, recupero e invio e-mail. In presenza di più istanze, il controllo viene eseguito separatamente per ogni istanza aggiornata.

Aggiornamento non riuscito

Non eseguire ripetutamente lo script senza analizzare la causa. Salvare output e registri, controllare spazio libero, accesso al database, permessi dei file e stato del servizio. Se lo stato non è chiaro, ripristinare insieme il backup completo precedentemente verificato della directory del programma e del database.

Aggiornamento a 2.0.2

Applicazione e database passano a 2.0.2; l’API interna resta 1.0. La sincronizzazione aggiunge chat interna, presenza sui ticket, pianificazioni dei report con destinatari e registri, relazioni servizio-CI, allegati FAQ e riferimento opzionale al modello di processo nei moduli. Queste aggiunte non eliminano dati esistenti.

Usare update.sh del nuovo pacchetto per l’istanza selezionata esplicitamente. Aggiornare le sorgenti Sphinx o eseguire build-all.bat non aggiorna l’applicazione Qisutu o il database.

L’aggiornatore non crea un backup automatico dei file applicativi. Prima deve esistere un backup completo di istanza e database, incluso var/secure/security.key. In caso di errore dopo l’inizio delle modifiche, la manutenzione resta attiva. Correggere la causa e ripetere lo stesso aggiornamento; non sovrascrivere indiscriminatamente singoli file applicativi o del database.

Controllare poi versioni, accesso, e-mail, chat e passaggio, invio di report, download FAQ e associazioni servizio-CI. Verificare un processo di modulo soltanto con KimProcesses installato e abilitato.