Installare il GLPI Agent e solo il 20% del lavoro. Cio che decide se l'inventario diventa un dato affidabile e la configurazione lato server: abilitare l'inventario, regolare il cron, gestire i seriali duplicati e blindare le regole di importazione. Questa guida ripercorre il percorso che usiamo nella manutenzione dei parchi GLPI dei clienti, con gli accorgimenti che evitano una CMDB gonfia di fantasmi.
Passo 0: abilitare l'inventario sul server (il passaggio che tutti saltano)
L'errore piu comune che troviamo e l'agente installato correttamente sulle postazioni mentre l'inventario e spento in GLPI. Senza quell'interruttore, i POST degli agenti colpiscono un endpoint che non elabora nulla, e il supporto perde ore incolpando il firewall. Prima di installare qualsiasi agente, verifichi sul server:
- In Configurazione > Generale > scheda Inventario, spunti Abilita l'inventario.
- Confermi l'endpoint nativo di GLPI 10/11:
https://glpi.tuaazienda.com/front/inventory.php(l'agente 1.x risolve questo percorso da solo a partire dall'URL base). - Nella configurazione dell'inventario, riveda le opzioni di importazione: importare computer, monitor, stampanti e componenti secondo la policy del cliente.
Distribuzione del GLPI Agent (Windows e Linux)
Su Windows, l'MSI silenzioso e lo standard per la GPO. Il TAG e il parametro piu importante e quello che meno persone usano: e cio che le regole di importazione usano per indirizzare l'asset alla giusta entita e alla giusta ubicazione.
glpi-agent-1.x-x64.msi /qn SERVER=https://glpi.tuaazienda.com TAG=filiale-sp
Su Linux, l'installer ufficiale gestisce le dipendenze:
curl -sL https://raw.githubusercontent.com/glpi-project/glpi-agent/main/tools/linux-installer.sh | bash -s -- --server https://glpi.tuaazienda.com --tag filiale-sp
Indipendentemente dal SO, il comportamento dell'agente vive in un file di configurazione. Questa e la baseline che standardizziamo:
# /etc/glpi-agent/agent.cfg (Linux)
# %ProgramFiles%\GLPI-Agent\etc\agent.cfg (Windows)
# Endpoint nativo GLPI 10/11 (l'agente 1.x risolve /front/inventory.php):
server = https://glpi.tuaazienda.com
# TAG usato dalle regole per indirizzare entita/ubicazione (es.: filiale):
tag = filiale-sp
# Frequenza di reinvio in secondi (86400 = 1 volta al giorno):
delaytime = 86400
# Finestra casuale: evita che tutti inventarino nello stesso minuto del login:
lazy = 1
# SOLO su rete interna con certificato self-signed:
# no-ssl-check = 1
Cron: garantire che l'inventario sia davvero elaborato
Qui si nasconde una trappola classica. Per impostazione predefinita, le azioni automatiche di GLPI girano in modalita GLPI (attivate quando qualcuno naviga nel sistema). Questo e imprevedibile: in un fine settimana, senza nessuno collegato, non gira nulla. Per inventario, telemetria e code affidabili, passi le azioni automatiche in modalita CLI (esterna) e pianifichi il cron del sistema operativo. Su GLPI 11 il punto di ingresso e front/cron.php (la console bin/console glpi:cron non copre tutto):
# /etc/cron.d/glpi - elabora azioni automatiche e code di GLPI
# Gira come utente PHP (apache/www-data), ogni 2 minuti:
*/2 * * * * apache /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1
Poi, in Configurazione > Azioni automatiche, apra ogni attivita rilevante e cambi la modalita di esecuzione da GLPI a CLI. Senza questo, il cliente si lamenta di "inventario obsoleto" e la causa non e nell'agente.
SNMP discovery: switch, router e stampanti
Le postazioni con agente sono la parte facile. I dispositivi di rete non eseguono un agente e dipendono da SNMP. La sequenza che funziona:
- Installi le attivita di rete sull'agente concentratore (pacchetto
glpi-agent-task-networksu Linux; l'installer Windows include gia i moduli SNMP). - Registri le credenziali SNMP (community v2c o v3) in Amministrazione > Inventario > Credenziali SNMP.
- Definisca gli intervalli di IP da scansionare in Amministrazione > Inventario > Intervalli di IP.
- Pianifichi le attivita di Network discovery (scopre cosa esiste) e Network inventory (raccoglie il dettaglio di cio che e stato scoperto).
L'errore comune qui e pianificare il Network inventory senza eseguire prima il discovery: senza apparati scoperti e classificati, non c'e nulla da inventariare in dettaglio.
Regole di importazione e il problema dei seriali duplicati
Nella manutenzione di parchi con centinaia di macchine, cio che genera piu "fantasmi" nell'inventario non e l'agente: e il seriale generico. Notebook e desktop assemblati riportano numero di serie To be filled by O.E.M., System Serial Number o 0000000000; le macchine virtuali clonate dallo stesso template portano lo STESSO UUID. Se la regola di importazione confronta per seriale, GLPI collega tutte quelle macchine allo STESSO asset, o crea decine di duplicati a ogni ciclo di inventario. Abbiamo deciso di standardizzare due controlli presso ogni cliente: primo, registrare quei seriali e MAC spazzatura nella scheda Blacklist della configurazione dell'inventario, affinche GLPI li ignori; secondo, aggiungere nella regola di importazione (Amministrazione > Regole > Regole di importazione e collegamento delle apparecchiature) un criterio per UUID oltre al seriale. L'errore comune e fidarsi solo del seriale e scoprire il danno tre mesi dopo, con la CMDB gonfia e il conteggio delle licenze software sballato per via dei duplicati.
Diagnostica: SQL per trovare gli agenti silenziosi
Quando il cliente chiede "quante macchine hanno smesso di riportare?", l'interfaccia non risponde in fretta. Questa query elenca gli agenti senza contatto da piu di 7 giorni, candidati a macchina spenta, reimmagine o servizio dell'agente fermo:
-- Agenti senza contatto da piu di 7 giorni
SELECT a.name AS agente, a.last_contact, c.name AS computer
FROM glpi_agents a
LEFT JOIN glpi_computers c
ON c.id = a.items_id AND a.itemtype = 'Computer'
WHERE a.last_contact < (NOW() - INTERVAL 7 DAY)
ORDER BY a.last_contact ASC;
La esegua con un client SQL in sola lettura. Un picco di agenti silenziosi coincide spesso con un cambio di GPO, un certificato scaduto o una nuova regola di firewall.
Matrice di troubleshooting sul campo
| Sintomo | Causa probabile | Correzione |
|---|---|---|
| L'agente non compare in Amministrazione > Inventario | Inventario disabilitato sul server o URL/porta errata | Abilitare in Configurazione > Generale; verificare /front/inventory.php e firewall 443/80 |
| Il POST restituisce 413 o inventario troncato | post_max_size / upload_max_filesize bassi in PHP | Alzare a 20M o piu e riavviare php-fpm; i server con molto software generano XML grande |
| Errore SSL nel log dell'agente | Certificato self-signed non attendibile | Installare la CA sulla macchina o no-ssl-check = 1 (solo rete interna) |
| Macchine duplicate a ogni ciclo | Seriale generico o UUID di template clonato | Blacklist di seriali/MAC + criterio per UUID nella regola di importazione |
| I dispositivi di rete non vengono inventariati | Attivita di rete o credenziale SNMP mancante | Installare glpi-agent-task-network; registrare credenziale SNMP e intervalli di IP |
| Dati sempre obsoleti | Azioni automatiche in modalita GLPI (non gira senza traffico) | Passare in modalita CLI e pianificare front/cron.php nel cron del SO |
Dall'inventario al ciclo di vita dell'asset
Raccogliere e meta del lavoro. L'inventario diventa gestione solo quando il dato in ingresso viene classificato, normalizzato e verificato: le regole di importazione indirizzano entita e categoria, i dizionari normalizzano i nomi di produttore e modello, e la traccia di audit registra quando un asset entra, cambia proprietario o sparisce dall'inventario. E questa catena a separare "installare il GLPI Agent" dal "mantenere un inventario affidabile".
Se il Suo inventario GLPI e pieno di duplicati, con agenti che spariscono o dispositivi di rete fuori mappa, il team di manutenzione GLPI di NexTool rivede le regole di importazione, regola la blacklist e collega l'inventario al ciclo di vita degli asset. Parli con noi della manutenzione GLPI.
Revisionato dal team NexTool Solutions.