La migrazione da GLPI 10 a GLPI 11 quasi mai fallisce sul comando di aggiornamento del database - fallisce in ciò che viene prima e dopo. Questa guida consolida il piano che applichiamo nella manutenzione degli ambienti dei clienti: dove le cose si rompono davvero, come blindare ogni passaggio e come tornare indietro se qualcosa va storto.
Prima di tutto: perché la migrazione richiede metodo
Migrare dalla 10 alla 11 modifica lo schema del database in modo irreversibile e sostituisce l'intero strato di presentazione (ora su Symfony e Twig). Non è un "sostituire i file e avviare". I due fattori che causano più downtime non pianificato sono i plugin incompatibili lasciati attivi durante l'aggiornamento e la versione di PHP sul server. Tratti la migrazione come un piccolo progetto, con finestra e piano di rollback, non come un hotfix. Pianifichi anche di avvisare gli utenti che l'interfaccia della 11 è diversa da quella della 10 - buona parte dei ticket post-migrazione sono persone perse nel nuovo layout, non bug reali.
Checklist di pre-migrazione
- Backup completo del database (mysqldump) e delle directory di configurazione e dati.
- Essere sull'ultima minor di GLPI 10 (10.0.x più recente) prima di saltare alla 11.
- PHP 8.1+ installato e attivo nella versione corretta di CLI e FPM.
- Un inventario dei plugin con lo stato di compatibilità di ciascuno in GLPI 11.
- Un ambiente di collaudo con una copia reale del database per provare la migrazione.
Plugin: cosa cambia in GLPI 11
| Plugin | Situazione in GLPI 11 | Azione prima di migrare |
|---|---|---|
| FormCreator | Incorporato nel core (moduli nativi) | Disattivare e rimuovere |
| GenericObject | Incorporato nel core (oggetti personalizzati) | Disattivare e rimuovere |
| FusionInventory | Dismesso | Migrare al GLPI Agent |
| Fields, Escalade, DataInjection, PDF, Tag | Hanno una versione per la 11 | Aggiornare dopo la migrazione |
| NexTool | Compatibile con 10 e 11 | Aggiornare alla versione della 11 |
| Plugin senza aggiornamenti dal 2023 | Probabile incompatibilità | Valutare la sostituzione |
1. Backup completo (e testato)
Un backup che non ha mai ripristinato non è un backup, è una speranza. Lo generi e, come minimo, ne validi la dimensione del file:
# Database
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql
# File (configurazione, dati e plugin)
tar -czf /backup/glpi_files_pre_migration.tar.gz /var/www/glpi /etc/glpi /var/lib/glpi2. Disattivare i plugin incompatibili
In GLPI 10, vada in Configurazione > Plugin e disattivi tutti quelli senza versione per la 11. Rimuova le directory di quelli incompatibili. Questo passaggio non è opzionale: è la causa numero 1 di fallimento al comando di aggiornamento.
3. Aggiornare i file di GLPI
cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz
# Sostituire i file preservando configurazione, dati e plugin
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpiScarichi sempre l'ultima release stabile della linea 11.x, non necessariamente la 11.0.0.
4. Eseguire la migrazione del database
php /var/www/glpi/bin/console db:update --no-interactionQuesto comando applica tutte le migrazioni di schema. Segua tutto l'output - qualsiasi errore va risolto prima di procedere, mai ignorato.
5. Pulire cache e sessioni
php /var/www/glpi/bin/console cache:clear
rm -rf /var/lib/glpi/_sessions/*6. Verifica post-migrazione
- Il login funziona e la versione in Configurazione > Generale mostra 11.x.
- Ticket, asset e utenti sono presenti con i totali attesi.
- L'apertura di un nuovo ticket funziona da capo a fondo.
- Log senza errori ricorrenti dopo qualche minuto di utilizzo.
- Riattivi e aggiorni i plugin compatibili uno a uno, testando tra l'uno e l'altro.
Cosa abbiamo imparato in manutenzione
In pratica, la migrazione raramente fallisce sul db:update in sé. Fallisce dopo: un plugin incompatibile rimasto attivo che manda giù l'interfaccia con un errore 500, il PHP di FPM che punta a una versione che GLPI 11 non accetta (mentre il CLI è già alla 8.1), o il cliente che ha saltato una minor della 10 e arriva al comando di aggiornamento con uno schema che non torna. Per questo il nostro piano aggiorna prima all'ultima 10.0.x, valida, e solo allora salta alla 11 - riattivando i plugin uno a uno, mai tutti insieme, perché quando qualcosa si rompe bisogna sapere esattamente quale plugin ne è responsabile.
La trappola più comune
L'errore classico è credere che i moduli di FormCreator migrino da soli ai moduli nativi di GLPI 11. Non migrano: il plugin sparisce, ma i moduli che creava vanno ricostruiti manualmente nel nuovo core. Inventari i moduli di FormCreator prima di rimuovere il plugin, altrimenti scoprirà la perdita in produzione, con un utente che si lamenta che il modulo è sparito. Il secondo errore più comune è eseguire db:update con un plugin incompatibile ancora attivo: il console tenta di caricare il plugin, incontra un'API che non esiste più e si interrompe a metà migrazione.
Rollback: quando qualcosa va storto
Poiché il cambio di schema è irreversibile, il rollback non è un "annulla" - è ripristinare lo stato precedente. Per questo il backup testato del passaggio 1 è irrinunciabile:
# Ripristinare i file
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /
# Ripristinare il database
mysql -u root -p glpi < /backup/glpi_pre_migration.sqlProvare questo ripristino in collaudo prima della finestra reale è ciò che separa uno spavento da un incidente.
Prossimo passo
Dopo la migrazione, esplori i moduli nativi e le altre novità di GLPI 11, e reintroduca i plugin essenziali. Per estendere il core senza accumulare plugin che si rompono alla prossima major, NexTool concentra decine di moduli in un unico plugin, con versioni per 10 e 11. Serve supporto per la migrazione? Parli con il team.
Revisionato dal team NexTool Solutions.
