NexTool Solutions

Migrar do FusionInventory para o GLPI Agent não é apenas desinstalar um e instalar o outro. Na sustentação de parques GLPI que a NexTool opera para clientes B2B, o que realmente decide a migração é proteger a ligação do ativo: garantir que cada máquina que trocou de agente continua a cair no mesmo registo do GLPI em vez de se tornar um duplicado. Este artigo mostra como planeamos e executamos essa troca em todo o parque, do ponto de ingestão à verificação que fecha cada vaga.

O que muda de verdade: o ponto de ingestão

O FusionInventory Agent alimentava o GLPI através do plugin FusionInventory, com um endpoint próprio. O GLPI Agent alimenta o inventário nativo do core, que recebe em /front/inventory.php. São dois caminhos de ingestão diferentes a conviver no mesmo servidor durante a transição. O agente é apenas metade da história: a outra metade é o servidor deixar de depender do plugin. Por isso a ordem importa - migra-se o parque primeiro e só depois se desativa e desinstala o plugin FusionInventory, nunca ao contrário. Remover o plugin antes de o parque estar migrado corta o caminho de dados dos agentes que ainda não trocaram.

Boa notícia para quem receia perder funcionalidades: o GLPI Agent mantém as mesmas tasks do FusionInventory (Inventory, NetDiscovery, NetInventory, Deploy, ESX, Collect e RemoteInventory). Nenhuma descoberta de rede ou deploy se perde na troca; muda o binário e o ponto de entrega, não o conjunto de funcionalidades.

O risco real: ativo duplicado (e porque acontece)

Aqui está o detalhe que só aparece quando se opera isto em produção. Cada agente carrega um deviceid (algo como hostname-2026-07-02-10-30-00). Ao instalar o GLPI Agent de raiz, gera-se um deviceid novo. Isso cria um registo de Agente novo no GLPI - mas não deveria criar um Computador novo, porque a correspondência do ativo é feita pelas regras de importação por número de série e UUID, não pelo deviceid.

Na sustentação, quem duplica quase nunca são os postos físicos: têm série de fábrica e correspondem perfeitamente. Quem duplica são as VMs. Uma máquina virtual com série vazia, ou com um UUID clonado de um template, escapa à correspondência por série/UUID e torna-se ativo novo a cada troca de deviceid. Por isso, antes da primeira vaga, auditamos as regras de importação e garantimos um critério de recurso que funcione para VMs (nome + domínio), além da série. Saltar essa auditoria é o erro mais caro da migração: descobre-se o problema quando o inventário duplicou de tamanho.

Configuração real do GLPI Agent

O coração da migração é o ficheiro de configuração. No Linux vive em /etc/glpi-agent/agent.cfg (com conf.d/ para overrides). O server aponta diretamente para o inventário nativo, e a tag é o que usamos para encaminhar o ativo para a entidade certa do cliente através de uma regra:

# /etc/glpi-agent/agent.cfg  (substitui o agent.cfg antigo do FusionInventory)
server       = https://glpi.cliente.com/front/inventory.php
tag          = sede-sp               # encaminha o ativo para a entidade certa via regra
delaytime    = 3600                  # janela aleatoria ate ao 1o envio (evita pico simultaneo)
httpd-trust  = 127.0.0.1, 10.20.0.0/24   # IPs que podem forcar execucao remota
httpd-port   = 62354
no-ssl-check = 0                     # 1 apenas se o certificado do GLPI for interno/autoassinado
logger       = File
logfile      = /var/log/glpi-agent.log

No Windows, a instalação em massa é feita por GPO ou por uma ferramenta de gestão, com o MSI silencioso. A mesma tag e o mesmo server do ficheiro Linux entram como propriedades do instalador:

:: 1) Desinstalar o FusionInventory Agent (GUID na chave Uninstall do registo)
msiexec /x "{GUID-DO-FUSIONINVENTORY-AGENT}" /quiet /norestart

:: 2) Instalar o GLPI Agent a apontar para o inventario NATIVO do 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

A propriedade RUNNOW=1 força um envio logo após a instalação, o que encurta o ciclo de validação da vaga: não se espera pelo próximo agendamento para ver o ativo chegar. E ADD_FIREWALL_EXCEPTION=1 abre a porta local 62354, que é como forçamos depois uma execução remota (útil quando um lote não reportou).

Migração por vagas, não big bang

Trocar o parque inteiro de uma vez é como se faz deploy a apostar o fim de semana. O fluxo que usamos:

1. Auditar as regras de importação - correspondência por série/UUID com recurso nome+domínio para VMs. É o passo que evita duplicados.
2. Confirmar o inventário nativo ativo - o servidor tem de estar a receber em /front/inventory.php antes de qualquer agente novo apontar para lá.
3. Vaga piloto - 5% a 10% do parque, segmentada por tag de local. Valida-se zero duplicados antes de prosseguir.
4. Rollout por lote - GPO/Ansible remove o FusionInventory e instala o GLPI Agent. Cada lote é verificado antes do seguinte.
5. Só no fim - com 100% migrado, desativa-se e desinstala-se o plugin FusionInventory no servidor.

FusionInventory Agent vs GLPI Agent

Verificação: o que verificamos antes de encerrar a vaga

Nenhuma vaga fecha só porque o agente instalou. O primeiro teste é forçar um envio e ler o retorno, diretamente no host:

# Forcar um envio e acompanhar em modo debug (Linux)
glpi-agent --force --debug

# Estado local do agente (porta predefinida 62354)
curl -s http://localhost:62354/status

Do lado do servidor, a rede de segurança é uma consulta que percorre o parque inteiro à procura do sintoma clássico de uma migração mal feita - dois ativos com o mesmo número de série:

-- Ativos com o mesmo serial: candidatos a duplicado pos-migracao
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 essa consulta volta vazia depois da vaga piloto, as regras de importação estão certas e o rollout pode acelerar. Se volta com linhas, paramos: é a altura de ajustar a regra, não de instalar mais agentes. Também confirmamos, na lista de Agentes do GLPI, se o "último contacto" está a atualizar - um agente que instalou mas não reporta em 24h costuma ser SSL interno sem no-ssl-check, ou uma firewall a bloquear a saída.

Uma migração de parque de inventário é um projeto: tem auditoria de regras, piloto, rollout controlado e prova objetiva de que ninguém duplicou. Se tem GLPI com FusionInventory e precisa de chegar ao GLPI Agent sem sustos, é exatamente esse trabalho que a NexTool executa. Fale connosco sobre projetos e implementação do seu ambiente GLPI.

Revisto pela equipa NexTool Solutions.