NexTool Solutions

Abbiamo aggiornato due volte una copia di un GLPI 11.0.11 alla 12.0.0: in Docker con l'immagine ufficiale e su Debian 13 con il pacchetto .tgz. La migrazione del database ha richiesto circa 5 secondi in entrambi i casi. Il lavoro vero è arrivato prima e dopo: MariaDB 10.6 è stato rifiutato, i plugin sono rimasti sospesi, le categorie della base di conoscenza sono diventate articoli che tecnici e utenti non riescono ad aprire e il webhook ha smesso di inviare, per due motivi diversi. Questa guida riporta la procedura passo passo dei due percorsi e la correzione di ogni problema, nell'ordine in cui sono comparsi.

State ancora decidendo se è il momento di aggiornare? Leggete prima GLPI 12 è uscito: cosa cambia, requisiti e quando aggiornare.

Cosa abbiamo testato

Abbiamo preparato un GLPI 11.0.11 usa e getta con dati fittizi di Acme: 120 ticket con followup e 40 attività, uno SLA, 9 articoli della base di conoscenza in 4 categorie con permessi diversi, un webhook verso un server interno e tre plugin della community (Fields, Tag e Data Injection), con dati. Abbiamo fatto il backup e aggiornato alla 12.0.0. Poi abbiamo ripristinato lo stesso backup su un Debian 13 e ripetuto l'aggiornamento con il pacchetto .tgz.

Prima di iniziare: requisiti

Due dettagli emersi dal test:

• Con PHP 8.2 non c'è un avviso, c'è un errore di sintassi. La console di GLPI 12 non arriva nemmeno a controllare i requisiti: si ferma con un "Parse error" in un file di GLPI stesso. Debian 12 e Ubuntu 22.04 hanno PHP 8.2 o precedente. Debian 13 (PHP 8.4) e Ubuntu 24.04 (PHP 8.3) vanno bene con i pacchetti standard. L'immagine Docker ufficiale include già PHP 8.5.
• Controllate il database prima di tutto. Eseguite php bin/console system:check_requirements con il codice nuovo puntato sul vostro database. Sul nostro MariaDB 10.6 la risposta è stata netta: versione non supportata, minimo 10.11.

Passo 0: backup (database, file e chiave)

Fate tre copie prima di toccare qualsiasi cosa: il database, la cartella dei file e la cartella di configurazione. La cartella di configurazione contiene glpicrypt.key. Senza di essa, le password salvate da GLPI (raccoglitore di e-mail, LDAP, proxy, segreti dei webhook) non si aprono più.

mariadb-dump --single-transaction --routines -u root -p glpi | gzip > glpi11-$(date +%F).sql.gz
tar czf glpi11-arquivos-$(date +%F).tgz /etc/glpi /var/lib/glpi/files /var/www/glpi/marketplace

In Docker con l'immagine ufficiale, tutto sta nel volume montato su /var/glpi (config, files, marketplace e log): copiate l'intero volume. Nel nostro test il dump ha richiesto 5 secondi e la copia del volume 8,5.

Percorso 1: Docker con l'immagine ufficiale

L'immagine ufficiale (glpi/glpi) aggiorna il database da sola quando parte con una versione nuova. Basta cambiare il tag e avviare il container: non c'è alcuna conferma. Per questo il backup va fatto prima del cambio di tag, mai dopo. Se preferite eseguire l'aggiornamento a mano, avviate con GLPI_SKIP_AUTOUPDATE=true e usate il comando del percorso 2.

1. Aggiornate MariaDB, se serve. Con MariaDB 10.6, il container di GLPI 12 è uscito con codice 128. Il log ha segnalato requisiti mancanti e, subito dopo, ha scritto una frase che spaventa: "GLPI is not installed... Starting installation". Non ha installato niente. Il database è rimasto intatto, alla versione 11.0.11, con i 120 ticket. Semplicemente non ha superato il controllo dei requisiti. Il passaggio da MariaDB 10.6 a 10.11 ha richiesto 22 secondi con la variabile di aggiornamento automatico dell'immagine di MariaDB. Avviate prima solo il database (docker compose up -d db) e controllate il log prima di proseguire:

services:
  db:
    image: mariadb:10.11          # era 10.6
    environment:
      MARIADB_AUTO_UPGRADE: "1"   # esegue mariadb-upgrade all'avvio
  glpi:
    image: glpi/glpi:12.0.0       # era 11.0.11 (passo 2)
    volumes:
      - glpi-data:/var/glpi

2. Cambiate il tag e avviate. docker compose up -d. Il log mostra "GLPI is installed, and auto-update is enabled. Starting update..." e, subito dopo, il messaggio di benvenuto. Nel test sono passati 17 secondi dall'up al messaggio di benvenuto nel log.

3. Verificate. docker compose exec glpi bin/console db:check deve rispondere "Database schema is OK".

Percorso 2: Linux con il pacchetto .tgz

I comandi qui sotto seguono la struttura della nostra guida all'installazione di GLPI 11 su Debian e Ubuntu: codice in /var/www/glpi, configurazione in /etc/glpi e file in /var/lib/glpi/files.

cd /var/www/glpi && sudo -u www-data php bin/console maintenance:enable
cd /var/www && mv glpi glpi-11-antigo
wget https://github.com/glpi-project/glpi/releases/download/12.0.0/glpi-12.0.0.tgz
tar xzf glpi-12.0.0.tgz
cp glpi-11-antigo/inc/downstream.php glpi/inc/                  # se esiste
cp glpi-11-antigo/config/local_define.php glpi/config/ 2>/dev/null  # se esiste
cp -a glpi-11-antigo/marketplace/. glpi/marketplace/
chown -R www-data:www-data glpi
cd glpi
sudo -u www-data php bin/console system:check_requirements
sudo -u www-data php bin/console database:update
sudo -u www-data php bin/console maintenance:disable

Il file che nessuno ricorda: inc/downstream.php. È lui che dice a GLPI che la configurazione sta in /etc/glpi. Si trova dentro la cartella del codice, quindi sparisce quando sostituite la cartella. Nel test, senza di lui, database:update ha risposto "Unable to connect to database". Il messaggio non dice il motivo reale: GLPI ha cercato la configurazione nel posto sbagliato. Con il file ricopiato, l'aggiornamento è partito subito. Lo stesso vale per config/local_define.php, se lo usate.

Se il vostro GLPI tiene config e files dentro /var/www/glpi, copiate anche config/ e files/ dalla cartella vecchia. È andata così su Debian 13 (PHP 8.4): la migrazione ha richiesto 5 secondi e db:check è uscito pulito.

Se l'aggiornamento del database fallisce

Sul forum di GLPI, il 3 novembre, è comparso un aggiornamento dalla 11.0.8 alla 12.0.1 su Debian 13 che si è bloccato: file copiati, proprietario e permessi sistemati, poi maintenance:disable ha dato errore e l'aggiornamento del database è fallito. Non abbiamo riprodotto questo caso. Una risposta nella discussione ha indicato una causa probabile, e il codice della migrazione conferma che è possibile: nella 11, la tabella che collega gli articoli alle categorie della knowledge base accetta più volte la stessa coppia articolo/categoria; la tabella che la sostituisce nella 12 no. Basta un collegamento duplicato per fermare la migrazione. Ripristinate il backup della 11 (la migrazione può essersi fermata a metà) e cercate i duplicati:

SELECT knowbaseitems_id, knowbaseitemcategories_id, COUNT(*) AS n
FROM glpi_knowbaseitems_knowbaseitemcategories
GROUP BY knowbaseitems_id, knowbaseitemcategories_id
HAVING n > 1;

Se esce qualche riga, cancellate le copie e tenete un collegamento per coppia. L'articolo resta nella sua categoria:

DELETE l1 FROM glpi_knowbaseitems_knowbaseitemcategories l1
JOIN glpi_knowbaseitems_knowbaseitemcategories l2
  ON l1.knowbaseitems_id = l2.knowbaseitems_id
 AND l1.knowbaseitemcategories_id = l2.knowbaseitemcategories_id
 AND l1.id > l2.id;

Se la query non restituisce nulla, la causa è un'altra. Verificate che la cartella dei file e quella di configurazione (nel nostro schema, /var/lib/glpi/files e /etc/glpi) appartengano a www-data, eseguite system:check_requirements e leggete php-errors.log nella cartella _log dei file e il log degli errori del server web. Eseguite database:update da riga di comando, che mostra l'errore a schermo, e solo dopo maintenance:disable.

Dopo la migrazione: cosa si è rotto e come risolvere

1. I plugin restano sospesi (e il comando di elenco non lo dice)

Dopo l'aggiornamento, GLPI 12 sospende l'esecuzione di tutti i plugin. plugin:list continuava a mostrare i tre come "Enabled". Ma l'impostazione plugins_execution_mode era su "suspended_by_update", e nessun plugin girava. Per sbloccarli:

php bin/console plugin:resume_execution

Allo sblocco, GLPI ha controllato le versioni e ha disattivato tutti e tre ("Installed / not activated"). Le versioni per la 11 accettano al massimo GLPI 11.0.99, e quelle per la 12 richiedono almeno la 12.0.0. In altre parole: non si possono aggiornare questi plugin prima di GLPI. Prima GLPI, poi i plugin:

Per ognuno: sostituite la cartella in marketplace/ con la versione nuova ed eseguite plugin:install e plugin:activate. I dati sono rimasti: i 5 valori del campo "Centro di costo" di Fields e le 10 etichette di Tag erano ancora lì. Prima di fissare la data, verificate che tutti i vostri plugin abbiano già una versione per la 12 (come scegliere i plugin senza bloccare l'upgrade).

2. Le categorie della base di conoscenza diventano articoli senza visibilità

GLPI 12 non ha più categorie nella base di conoscenza: le 4 categorie sono diventate 4 articoli "padre", e sopra di loro è stato creato un articolo radice ("Home"). I 9 articoli hanno mantenuto i permessi che avevano. Ma i 4 articoli che erano categorie sono rimasti senza alcuna regola di visibilità. Abbiamo provato via API con un tecnico e con un utente Self-Service: entrambi hanno ricevuto un errore 403 aprendo "Procedure", "Rete", "Wi-Fi" e "FAQ utente". Ciascuno continuava ad aprire solo gli articoli che vedeva già prima.

Correzione: aprite ogni ex categoria e assegnatele il pubblico che aveva la cartella (entità, profilo o gruppo). Nella 12, un articolo eredita la visibilità degli articoli sopra di lui. Nel test, rendere visibile l'ex categoria "FAQ utente" all'entità Acme ha permesso al tecnico di aprire la cartella e i due articoli al suo interno, che prima davano 403. Per l'utente Self-Service c'è un passo in più: vede solo gli articoli contrassegnati come FAQ, e le ex categorie arrivano senza questo contrassegno. Con visibilità e contrassegno FAQ, la cartella è comparsa anche a lui. Fatelo prima di aprire il sistema agli utenti.

3. Il webhook si è fermato: metodo "post" in minuscolo

Il webhook creato in GLPI 11 è entrato in coda ed è fallito. Il log webhook.log ha mostrato la causa: Invalid HTTP method "post", only uppercase letters are accepted. GLPI salva il metodo in minuscolo, e il client HTTP della 12 accetta solo maiuscole. Il problema riguarda tutti i webhook, compresi quelli creati nella 12. È registrato sul GitHub di GLPI (issue 25883), con una correzione proposta. Quando abbiamo fatto il test, il 16 ottobre, la correzione non era ancora nella 12.0.0 né nella versione di sviluppo della 12.0.1.

Finché la correzione non esce, l'aggiramento è portare il metodo in maiuscolo direttamente nel database (con backup):

UPDATE glpi_webhooks SET http_method = UPPER(http_method);
UPDATE glpi_queuedwebhooks SET http_method = UPPER(http_method);

Se qualcuno salva di nuovo il webhook dall'interfaccia, il campo torna in minuscolo. In quel caso ripetete il comando, e tenete d'occhio le note di rilascio delle versioni 12.0.x: quando la correzione entrerà, l'aggiramento non servirà più.

4. Poi, il blocco della rete interna

Con il metodo corretto, l'errore è cambiato: Host "glpiup-hook" is blocked. GLPI 12 blocca per impostazione predefinita le chiamate dal server verso reti private (10.x, 172.16-31.x, 192.168.x). Vale per webhook, calendari esterni, feed RSS e la connessione a GLPI Network. Per impostazione predefinita restano consentite solo le chiamate all'agente di inventario e all'autenticazione esterna. Se il vostro webhook punta a un n8n, a un ERP o a un'API sulla rete interna, si fermerà.

Per consentire solo ciò che serve, create il file config/local_define.php nella cartella del codice di GLPI:

<?php
define('GLPI_SERVERSIDE_URL_ALLOWED_PRIVATE_NETWORKS_CONTEXTS', [
    \Agent::class,    // predefinito
    \Auth::class,     // predefinito
    \Webhook::class,  // consente i webhook verso la rete interna
]);

Trappola di Docker: GLPI legge questo file in /var/www/glpi/config/, che si trova dentro l'immagine, e non nel volume /var/glpi/config. Messo nel volume, il file non ha avuto effetto. Montato come file, ha funzionato:

    volumes:
      - glpi-data:/var/glpi
      - ./local_define.php:/var/www/glpi/config/local_define.php:ro

Dopo questo passaggio, i due webhook in coda sono stati consegnati con stato 200. Per configurare un webhook da zero, vedete i webhook nativi di GLPI 11.

5. L'avviso sui documenti

La migrazione ha lasciato un solo avviso nel log warning_during_migration_to_12.0.0.log: "Rights have been given for document, you should review ACLs after update". GLPI ha assegnato nuovi permessi sui documenti. Rivedeteli in Amministrazione > Profili, scheda Gestione > Documenti, soprattutto nei profili degli utenti finali.

Checklist dell'aggiornamento

E i moduli NexTool?

Il plugin NexTool e i 37 moduli girano su GLPI 11 e 12 con la stessa versione. Per questo, a differenza dei plugin sopra, si possono aggiornare prima, ancora sulla 11, in NexTool > Moduli > Aggiorna tutti. Dopo la migrazione restano sospesi come gli altri plugin: eseguite plugin:resume_execution e controllate l'elenco in NexTool > Moduli. La tabella modulo per modulo è in NexTool su GLPI 12: compatibilità. Se volete supporto per pianificare o eseguire l'aggiornamento, contattateci.

Test di NexTool del 16 ottobre 2026, su una copia usa e getta con dati fittizi: immagine ufficiale glpi/glpi da 11.0.11 a 12.0.0 (PHP 8.5), MariaDB da 10.6 a 10.11, e pacchetto .tgz su Debian 13 (PHP 8.4). L'ambiente è stato eliminato al termine. GLPI è un marchio registrato di Teclib'. NexTool non è affiliata a Teclib'.