go-glpi-agent: inventario para GLPI 10+ sin Perl

Mascote LinuxPro fazendo inventário de um rack com scanner ao lado de um cachorro caramelo

El inventario de activos solo funciona cuando el agente consigue ejecutarse en toda la flota, identificar la máquina de forma estable y entregar datos que GLPI entienda. El go-glpi-agent es una reimplementación en Go del agente de inventario del ecosistema FusionInventory/GLPI: un binario estático que recopila hardware y software localmente y envía el resultado a GLPI 10+ — sin runtime de Perl, árbol de módulos ni acceso SSH al endpoint.

Contenido ocultar

1 Qué es go-glpi-agent

2 Por qué un binario en Go cambia la operación

3 Qué recopila

4 Instalación en Ubuntu y Debian

5 Configurar el destino y probar sin enviar nada

6 Programar con systemd

7 Cómo mantener la identidad del activo

8 Configuraciones útiles y sus valores

9 Otros sistemas operativos

10 Límites conocidos: dónde no prometer de más

11 Versión actual y hoja de ruta de adopción

12 Referencias

Qué es go-glpi-agent

El proyecto no es el agente oficial glpi-agent, ni intenta sobrescribirlo. Es una implementación independiente, pensada para coexistir con el agente oficial y con el antiguo fusioninventory-agent. El punto de compatibilidad es deliberado: lee el formato agent.cfg ya usado por el agente Perl y reutiliza identificadores existentes, reduciendo el riesgo de que una máquina reaparezca en GLPI como otro activo después de una migración.

El flujo es directo:

el binario descubre datos locales de hardware, sistema y software;
monta el inventario en el modelo interno del proyecto;
intenta enviar a /front/inventory.php mediante el protocolo JSON nativo de GLPI;
cuando es necesario, realiza una fallback automática al flujo XML heredado de OCS/FusionInventory;
GLPI asocia el inventario al equipo identificado por el agente.

También hay un modo local: go-glpi-agent run --local DIRETÓRIO guarda el XML sin enviarlo. Es el mejor primer paso para comprobar qué se recopilará antes de apuntar una flota a producción.

Por qué un binario en Go cambia la operación

Implantación sencilla: el proyecto publica paquetes nativos para Linux, además de archivos para Windows, FreeBSD y macOS. Para un equipo de infraestructura, esto reduce dependencias en el host.
Un código, cuatro sistemas: la misma base cubre Linux amd64, Windows amd64, FreeBSD amd64 y macOS 13+ en Apple Silicon; Mac Intel es un caso de compilación en el host Intel.
Agenda predecible: en Linux, el paquete instala un timer systemd por hora con retraso aleatorio. En Windows, la versión 0.6.0 pasó a usar un servicio de Windows en lugar de la tarea programada anterior.
Compatibilidad operativa: el archivo de configuración y la importación de dumps de identidad hacen que el cambio sea menos disruptivo para las instalaciones existentes.

No confunda “binario único” con “inventario mágico”. El agente sigue necesitando permisos, el endpoint correcto, TLS válido y una rutina de cotejo en GLPI.

Qué recopila

La cobertura depende del sistema operativo, porque cada plataforma expone el hardware de forma diferente. En Linux, el agente utiliza fuentes como /sys, /proc, dmidecode, lsblk, lvs y los gestores dpkg, rpm e pacman. En Windows, combina WMI, Registro y gopsutil; en FreeBSD, utiliza kenv, pkg, geom, sysctl e usbconfig; en macOS, utiliza system_profiler, ioreg, sysctl e sw_vers.

Categoría	Ejemplos de datos	Observación
Identidad y sistema	hostname, dominio, distribución/versión, zona horaria	los valores de serie conocidos como basura se filtran; en algunas máquinas virtuales el UUID puede actuar como fallback.
Hardware	CPU, memoria y ranuras, BIOS, placa base, chasis, discos, sistemas de archivos, LVM, USB y red	algunos campos, como las ranuras de memoria y el número de serie del disco, requieren privilegios de administrador.
Software	paquetes dpkg/rpm/pacman en Linux; claves de desinstalación en Windows; `pkg` en FreeBSD	en Windows, el proyecto evita `Win32_Product`, que es lento y puede disparar la reparación de MSI.
Inventario opcional	procesos en ejecución	desactivado por defecto; habilítelo solo si tiene sentido para su política de inventario.

Instalación en Ubuntu y Debian

Use un paquete de la release v0.6.0. El ejemplo siguiente es para amd64; confirme la arquitectura con dpkg --print-architecture antes de descargar.

sudo apt update
sudo apt install -y curl

VER=0.6.0
curl -fLO "https://github.com/jniltinho/go-glpi-agent/releases/download/v${VER}/go-glpi-agent_${VER}_amd64.deb"
sudo apt install "./go-glpi-agent_${VER}_amd64.deb"

/opt/go-glpi-agent/go-glpi-agent version
systemctl cat go-glpi-agent.service

El paquete coloca el binario y la configuración en /opt/go-glpi-agent/ y las unidades en /lib/systemd/system/. No copie encima del agent.cfg en una actualización: el paquete fue diseñado para preservar la configuración del operador.

Configurar el destino y probar sin enviar nada

Edite /opt/go-glpi-agent/agent.cfg. El mínimo es el endpoint de inventario de su GLPI. Use HTTPS en producción y mantenga la validación de certificado activada.

# /opt/go-glpi-agent/agent.cfg
server = https://glpi.exemplo.com/front/inventory.php
tag = datacenter-sp

# Estado persistente: não apague sem planejar a consequência no inventário.
vardir = /opt/go-glpi-agent/var

# Opcional: limita o inventário de processos e categorias.
scan-processes = 0
# no-category = printer,software

# Se a CA for interna, informe a CA; não desative TLS em produção.
# ca-cert-file = /etc/ssl/certs/minha-ca.pem
# proxy = http://proxy.exemplo.com:3128

Antes del primer envío, genere un inventario local. Permite abrir el XML, comprobar el hostname, el serial, los discos y la lista de programas sin crear ni modificar un activo remoto.

sudo install -d -m 0750 /var/tmp/go-glpi-agent-inventory
sudo /opt/go-glpi-agent/go-glpi-agent run --local /var/tmp/go-glpi-agent-inventory
sudo find /var/tmp/go-glpi-agent-inventory -maxdepth 1 -type f -printf '%f\n'

Cuando la salida tenga sentido, ejecútelo una vez contra el GLPI con depuración. A continuación, compruebe la creación o actualización del equipo en la interfaz del GLPI.

sudo /opt/go-glpi-agent/go-glpi-agent run \
  --conf-file /opt/go-glpi-agent/agent.cfg \
  --debug

Evite no-ssl-check = 1 en producción. Si una CA privada falla, instale la cadena correcta o use ca-cert-file/ca-cert-dir. Desactivar la verificación convierte un error de certificado en riesgo de intercepción.

Programar con systemd

La forma recomendada para Linux es una ejecución puntual por hora, activada por el timer. La unidad utiliza un retraso aleatorio de hasta diez minutos para evitar que todos los hosts llamen a GLPI en el mismo segundo.

sudo systemctl enable --now go-glpi-agent.timer
systemctl status go-glpi-agent.timer --no-pager
systemctl list-timers go-glpi-agent.timer
journalctl -u go-glpi-agent.service -n 100 --no-pager

También existe go-glpi-agent-daemon.service, para el proceso largo que respeta delaytime del archivo de configuración. Elija timer o daemon para el mismo propósito; activar ambos puede duplicar inventarios y cargar el servidor sin necesidad.

Cómo mantener la identidad del activo

El mayor error en una migración es que GLPI reconozca un equipo conocido como una máquina nueva. El proyecto adopta el formato de device ID del agente Perl y, en la primera ejecución, puede importar volcados existentes de FusionInventory/GLPI Agent. Preserve también el directorio vardir: allí se almacenan el estado y los identificadores persistentes.

En un cambio controlado, haga un piloto: seleccione algunos hosts, compare el activo antes y después en GLPI, valide el serial/UUID/hostname, y solo entonces habilite el temporizador en el resto. En máquinas virtuales, atención extra al serial genérico; el proyecto documenta un fallback a UUID cuando SMBIOS devuelve valores como 0.

Configuraciones útiles y sus valores

Nombre	Valor/ejemplo	Uso
`server`	`https://glpi.exemplo.com/front/inventory.php`	destino del inventario remoto.
`local`	`/var/tmp/inventario`	graba XML local en lugar de enviar.
`tag`	`datacenter-sp`	clasifica los activos en GLPI.
`delaytime`	`3600`	intervalo en segundos utilizado por el modo daemon.
`lazy`	`1`	no envía si el servidor no lo solicita.
`force`	`1`	fuerza el envío; utilícelo solo cuando conozca el efecto operativo.
`scan-processes`	`0` o `1`	incluye procesos en el inventario; evalúe privacidad y volumen.
`no-category`	`printer,software`	omite categorías separadas por comas.
`backend-collect-timeout`	`180`	límite por colector, en segundos.
`ca-cert-file`	`/etc/ssl/certs/minha-ca.pem`	CA privada para TLS.

Otros sistemas operativos

RHEL, Rocky, Alma, Fedora y openSUSE: la release incluye RPM amd64; instale con el gestor de paquetes de la distribución.
Arch Linux: hay paquete .pkg.tar.zst para la instalación con pacman -U.
Windows: la release ofrece ZIP y MSI. Desde la v0.6.0, el instalador registra el servicio go-glpi-agent, iniciado automáticamente bajo LocalSystem; la configuración y el ejecutable quedan en C:\Program Files\go-glpi-agent, mientras que el estado y los registros quedan en C:\ProgramData.
FreeBSD 14 amd64: use el tarball y el INSTALL.md incluido; hay opción de rc.d o cron.
macOS 13+ Apple Silicon: la release incluye .pkg e .dmg. Para Mac Intel, la documentación orienta compilar en el propio host Intel.

Límites conocidos: dónde no prometer de más

El proyecto cubre inventario local, no todo el catálogo del agente Perl. La documentación lista como lagunas, entre otras: GPUs, monitores vía EDID, impresoras, controladoras PCI/RAID/IPMI, descubrimiento e inventario de red, deploy, Wake-on-LAN, ESX e inventarios de Snap, Flatpak, Nix o Gentoo. Esto no es un defecto oculto: es criterio para decidir si satisface su entorno o si el agente oficial sigue siendo necesario en parte de la flota.

Tampoco es una herramienta de monitorización. Para métricas y alertas, complemente el inventario con Prometheus y Node Exporter; para la historia del ITSM y del inventario en el servidor, vea la historia de GLPI. Inventario responde “qué existe”; monitorización responde “qué está ocurriendo ahora”.

Versión actual y hoja de ruta de adopción

La versión actual, v0.6.0, se publicó el 10 de julio de 2026. Sustituye la tarea programada de Windows por un servicio real y conserva la configuración junto al ejecutable durante las actualizaciones. La serie anterior también incluyó correcciones para el protocolo nativo de GLPI 11; por eso conviene seguir la versión y el registro de cambios en lugar de copiar comandos antiguos de tutoriales.

realice una copia de seguridad y elija cinco máquinas piloto;
genere el inventario local y revise la identidad y las categorías;
apunte a un GLPI de pruebas o a una entidad piloto;
confirme que los activos se actualizaron, sin duplicarlos;
active el temporizador de forma gradual y supervise el journal y las colas de GLPI;
documente las categorías desactivadas y la CA utilizada, para que la operación sea reproducible.

Referencias

go-glpi-agent no sustituye a una política de inventario; la hace más fácil de distribuir. Cuando el piloto confirma la identidad, TLS y la cobertura de recopilación, el binario único se convierte en una alternativa práctica para mantener GLPI alimentado en entornos Linux, Windows, FreeBSD y macOS.