NexTool Solutions

Migrare da FusionInventory a GLPI Agent non è solo disinstallare l'uno e installare l'altro. Nei parchi GLPI che NexTool mantiene per clienti B2B, ciò che davvero decide la migrazione è proteggere il legame dell'asset: garantire che ogni macchina che ha cambiato agente continui a ricadere sullo stesso record GLPI invece di diventare un duplicato. Questo post mostra come pianifichiamo ed eseguiamo questo cambio sull'intero parco, dal punto di ingestione alla verifica che chiude ogni ondata.

Cosa cambia davvero: il punto di ingestione

Il FusionInventory Agent alimentava GLPI tramite il plugin FusionInventory, con un endpoint proprio. GLPI Agent alimenta l'inventario nativo del core, che riceve su /front/inventory.php. Sono due percorsi di ingestione diversi che convivono sullo stesso server durante la transizione. L'agente è solo metà della storia: l'altra metà è che il server smetta di dipendere dal plugin. Per questo l'ordine conta - si migra prima il parco e solo dopo si disattiva e disinstalla il plugin FusionInventory, mai il contrario. Rimuovere il plugin prima che il parco sia migrato taglia il percorso dati degli agenti che non hanno ancora cambiato.

Buona notizia per chi teme di perdere funzioni: GLPI Agent mantiene le stesse tasks di FusionInventory (Inventory, NetDiscovery, NetInventory, Deploy, ESX, Collect e RemoteInventory). Nessuna scoperta di rete o deploy si perde nel cambio; cambiano il binario e il punto di consegna, non l'insieme delle funzioni.

Il rischio reale: asset duplicati (e perché accade)

Ecco il dettaglio che emerge solo quando lo gestisce in produzione. Ogni agente porta un deviceid (qualcosa come hostname-2026-07-02-10-30-00). Installare GLPI Agent da zero genera un nuovo deviceid. Questo crea un nuovo record Agente in GLPI - ma non dovrebbe creare un nuovo Computer, perché l'abbinamento dell'asset è fatto dalle regole di importazione tramite numero di serie e UUID, non tramite il deviceid.

Nella gestione quotidiana, a duplicare non sono quasi mai i desktop fisici: hanno un seriale di fabbrica e si abbinano perfettamente. A duplicare sono le VM. Una macchina virtuale con seriale vuoto, o con un UUID clonato da un template, sfugge all'abbinamento per serie/UUID e diventa un nuovo asset a ogni cambio di deviceid. Per questo, prima della prima ondata, verifichiamo le regole di importazione e garantiamo un criterio di ripiego che funzioni per le VM (nome + dominio), oltre al seriale. Saltare questa verifica è l'errore più costoso della migrazione: scopre il problema quando l'inventario è raddoppiato di dimensione.

Configurazione reale di GLPI Agent

Il cuore della migrazione è il file di configurazione. Su Linux si trova in /etc/glpi-agent/agent.cfg (con conf.d/ per gli override). Il server punta direttamente all'inventario nativo, e il tag è ciò che usiamo per instradare l'asset verso l'entità corretta del cliente tramite una regola:

# /etc/glpi-agent/agent.cfg  (sostituisce il vecchio agent.cfg di FusionInventory)
server       = https://glpi.cliente.com/front/inventory.php
tag          = sede-sp               # instrada l'asset all'entita corretta via regola
delaytime    = 3600                  # finestra casuale prima del 1o invio (evita un picco)
httpd-trust  = 127.0.0.1, 10.20.0.0/24   # IP che possono forzare l'esecuzione remota
httpd-port   = 62354
no-ssl-check = 0                     # 1 solo se il certificato di GLPI e interno/autofirmato
logger       = File
logfile      = /var/log/glpi-agent.log

Su Windows, il deploy di massa passa da GPO o da uno strumento di gestione, con l'MSI silenzioso. Gli stessi tag e server del file Linux diventano proprietà dell'installer:

:: 1) Disinstallare il FusionInventory Agent (GUID nella chiave Uninstall del registro)
msiexec /x "{GUID-DEL-FUSIONINVENTORY-AGENT}" /quiet /norestart

:: 2) Installare GLPI Agent puntando all'inventario NATIVO di GLPI
msiexec /i GLPI-Agent-1.11-x64.msi /quiet /norestart ^
  SERVER="https://glpi.cliente.com/front/inventory.php" ^
  TAG="sede-sp" RUNNOW=1 ADD_FIREWALL_EXCEPTION=1

La proprietà RUNNOW=1 forza un invio subito dopo l'installazione, il che accorcia il ciclo di validazione dell'ondata: non aspetta la prossima pianificazione per vedere arrivare l'asset. E ADD_FIREWALL_EXCEPTION=1 apre la porta locale 62354, con cui poi forziamo un'esecuzione remota (utile quando un lotto non ha riportato).

Migrazione a ondate, non big bang

Cambiare l'intero parco in un colpo solo è il modo per fare deploy scommettendo il fine settimana. Il flusso che usiamo:

1. Verificare le regole di importazione - abbinamento per serie/UUID con ripiego nome+dominio per le VM. È il passo che evita i duplicati.
2. Confermare l'inventario nativo attivo - il server deve ricevere su /front/inventory.php prima che qualsiasi nuovo agente vi punti.
3. Ondata pilota - dal 5% al 10% del parco, segmentata per tag di sito. Si valida zero duplicati prima di proseguire.
4. Rollout per lotto - GPO/Ansible rimuove FusionInventory e installa GLPI Agent. Ogni lotto è verificato prima del successivo.
5. Solo alla fine - con il 100% migrato, si disattiva e disinstalla il plugin FusionInventory sul server.

FusionInventory Agent vs GLPI Agent

Verifica: cosa controlliamo prima di chiudere un'ondata

Nessuna ondata si chiude solo perché l'agente si è installato. Il primo test è forzare un invio e leggere il ritorno, direttamente sull'host:

# Forzare un invio e seguirlo in modalita debug (Linux)
glpi-agent --force --debug

# Stato locale dell'agente (porta predefinita 62354)
curl -s http://localhost:62354/status

Lato server, la rete di sicurezza è una query che scorre l'intero parco alla ricerca del sintomo classico di una migrazione fatta male - due asset con lo stesso numero di serie:

-- Asset con lo stesso serial: candidati a duplicato post-migrazione
SELECT serial, COUNT(*) AS total, GROUP_CONCAT(id) AS ids
FROM   glpi_computers
WHERE  is_deleted = 0 AND serial <> ''
GROUP  BY serial
HAVING total > 1
ORDER  BY total DESC;

Se questa query torna vuota dopo l'ondata pilota, le regole di importazione sono corrette e il rollout può accelerare. Se torna con righe, ci fermiamo: è il momento di correggere la regola, non di installare altri agenti. Controlliamo anche, nella lista degli Agenti di GLPI, se l'"ultimo contatto" si sta aggiornando - un agente che si è installato ma non riporta entro 24h di solito è SSL interno senza no-ssl-check, o un firewall che blocca l'uscita.

Una migrazione di parco d'inventario è un progetto: ha verifica delle regole, pilota, rollout controllato e prova oggettiva che nessuno ha duplicato. Se gestisce GLPI con FusionInventory e deve arrivare a GLPI Agent senza sorprese, è esattamente il lavoro che NexTool esegue. Parli con noi dei Suoi progetti di implementazione per il Suo ambiente GLPI.

Revisionato dal team NexTool Solutions.