Migrar de FusionInventory a GLPI Agent no es solo desinstalar uno e instalar el otro. En las flotas GLPI que NexTool mantiene para clientes B2B, lo que de verdad decide la migración es proteger el vínculo del activo: asegurar que cada máquina que cambió de agente siga cayendo en el mismo registro de GLPI en lugar de convertirse en un duplicado. Este post muestra cómo planificamos y ejecutamos ese cambio en toda la flota, desde el punto de ingesta hasta la verificación que cierra cada ola.
Lo que de verdad cambia: el punto de ingesta
El FusionInventory Agent alimentaba GLPI a través del plugin FusionInventory, con su propio endpoint. GLPI Agent alimenta el inventario nativo del core, que recibe en /front/inventory.php. Son dos rutas de ingesta distintas que conviven en el mismo servidor durante la transición. El agente es solo la mitad de la historia: la otra mitad es que el servidor deje de depender del plugin. Por eso el orden importa - se migra primero la flota y solo después se desactiva y desinstala el plugin FusionInventory, nunca al revés. Quitar el plugin antes de migrar la flota corta la ruta de datos de los agentes que todavía no cambiaron.
Buena noticia para quien teme perder funciones: GLPI Agent mantiene las mismas tasks de FusionInventory (Inventory, NetDiscovery, NetInventory, Deploy, ESX, Collect y RemoteInventory). No se pierde descubrimiento de red ni deploy en el cambio; cambia el binario y el punto de entrega, no el conjunto de funciones.
El riesgo real: activos duplicados (y por qué ocurre)
Aquí está el detalle que solo aparece cuando operas esto en producción. Cada agente lleva un deviceid (algo como hostname-2026-07-02-10-30-00). Al instalar GLPI Agent desde cero se genera un deviceid nuevo. Eso crea un registro de Agente nuevo en GLPI - pero no debería crear un Ordenador nuevo, porque el emparejamiento del activo lo hacen las reglas de importación por número de serie y UUID, no por el deviceid.
En el soporte del día a día, los que duplican casi nunca son los equipos físicos: tienen serie de fábrica y emparejan perfectamente. Los que duplican son las VMs. Una máquina virtual con serie vacía, o con un UUID clonado de una plantilla, escapa del match por serie/UUID y se convierte en activo nuevo en cada cambio de deviceid. Por eso, antes de la primera ola, auditamos las reglas de importación y garantizamos un criterio de reserva que funcione para VMs (nombre + dominio), además del serial. Saltarse esa auditoría es el error más caro de la migración: descubres el problema cuando el inventario se ha duplicado en tamaño.
Configuración real de GLPI Agent
El corazón de la migración es el archivo de configuración. En Linux vive en /etc/glpi-agent/agent.cfg (con conf.d/ para overrides). El server apunta directo al inventario nativo, y la tag es lo que usamos para enrutar el activo a la entidad correcta del cliente vía regla:
# /etc/glpi-agent/agent.cfg (reemplaza el agent.cfg antiguo de FusionInventory)
server = https://glpi.cliente.com/front/inventory.php
tag = central-sp # enruta el activo a la entidad correcta via regla
delaytime = 3600 # ventana aleatoria antes del 1er envio (evita pico)
httpd-trust = 127.0.0.1, 10.20.0.0/24 # IPs que pueden forzar ejecucion remota
httpd-port = 62354
no-ssl-check = 0 # 1 solo si el certificado de GLPI es interno/autofirmado
logger = File
logfile = /var/log/glpi-agent.logEn Windows, el despliegue masivo va por GPO o una herramienta de gestión, con el MSI silencioso. La misma tag y el mismo server del archivo Linux entran como propiedades del instalador:
:: 1) Desinstalar el FusionInventory Agent (GUID en la clave Uninstall del registro)
msiexec /x "{GUID-DEL-FUSIONINVENTORY-AGENT}" /quiet /norestart
:: 2) Instalar GLPI Agent apuntando al inventario NATIVO de GLPI
msiexec /i GLPI-Agent-1.11-x64.msi /quiet /norestart ^
SERVER="https://glpi.cliente.com/front/inventory.php" ^
TAG="central-sp" RUNNOW=1 ADD_FIREWALL_EXCEPTION=1La propiedad RUNNOW=1 fuerza un envío justo tras la instalación, lo que acorta el ciclo de validación de la ola: no esperas a la próxima programación para ver llegar el activo. Y ADD_FIREWALL_EXCEPTION=1 abre el puerto local 62354, que es como forzamos después una ejecución remota (útil cuando un lote no reportó).
Migración por olas, no big bang
Cambiar toda la flota de golpe es como se despliega para perder el fin de semana. El flujo que usamos:
- Auditar las reglas de importación - match por serie/UUID con reserva nombre+dominio para VMs. Es el paso que evita duplicados.
- Confirmar el inventario nativo activo - el servidor debe estar recibiendo en
/front/inventory.phpantes de que cualquier agente nuevo apunte ahí. - Ola piloto - 5% a 10% de la flota, segmentada por
tagde sitio. Se valida cero duplicados antes de seguir. - Rollout por lote - GPO/Ansible quita FusionInventory e instala GLPI Agent. Cada lote se verifica antes del siguiente.
- Solo al final - con el 100% migrado, se desactiva y desinstala el plugin FusionInventory del servidor.
FusionInventory Agent vs GLPI Agent
| Aspecto | FusionInventory Agent | GLPI Agent |
|---|---|---|
| Mantenimiento | Comunidad, sin nuevas releases | Oficial Teclib, releases activas |
| Ingesta en GLPI | Plugin FusionInventory (endpoint propio) | Inventario nativo (/front/inventory.php) |
| GLPI 11 | No soportado | Soportado |
| Tasks (descubrimiento, deploy, ESX) | Sí | Sí (mismo conjunto) |
| Interfaz local | Puerto 62354 | Puerto 62354 |
| Config | agent.cfg | agent.cfg + conf.d/ |
Verificación: qué comprobamos antes de cerrar la ola
Ninguna ola se cierra solo porque el agente se instaló. La primera prueba es forzar un envío y leer la respuesta, directo en el host:
# Forzar un envio y seguirlo en modo debug (Linux)
glpi-agent --force --debug
# Estado local del agente (puerto por defecto 62354)
curl -s http://localhost:62354/statusDel lado del servidor, la red de seguridad es una consulta que recorre toda la flota buscando el síntoma clásico de una migración mal hecha - dos activos con el mismo número de serie:
-- Activos con el mismo serial: candidatos a duplicado post-migracion
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;Si esa consulta vuelve vacía tras la ola piloto, las reglas de importación están bien y el rollout puede acelerar. Si vuelve con filas, paramos: es el momento de ajustar la regla, no de instalar más agentes. También comprobamos, en la lista de Agentes de GLPI, si el "último contacto" se está actualizando - un agente que instaló pero no reporta en 24h suele ser SSL interno sin no-ssl-check, o un firewall bloqueando la salida.
Una migración de flota de inventario es un proyecto: tiene auditoría de reglas, piloto, rollout controlado y prueba objetiva de que nadie duplicó. Si tienes GLPI con FusionInventory y necesitas llegar a GLPI Agent sin sustos, ese es exactamente el trabajo que NexTool ejecuta. Habla con nosotros sobre proyectos e implantación de tu entorno GLPI.
Revisado por el equipo de NexTool Solutions.
