Installare un plugin per ogni esigenza sembra la mossa ovvia in GLPI - fino al giorno dell'aggiornamento, quando metà non riparte. Dopo anni a mantenere parchi GLPI di clienti, abbiamo imparato che il collo di bottiglia raramente è un plugin scadente: è la somma di una dozzina di plugin isolati, ciascuno con il suo ciclo di rilascio, la sua dipendenza e il suo manutentore. Questa guida mostra come scegliere e combinare le estensioni senza cadere nel "plugin sprawl", dove si inserisce l'approccio modulare di NexTool - e, in tutta onestà, dove non serve.
Il problema: il "plugin sprawl"
Ogni plugin dell'ecosistema GLPI è un progetto a parte: manutentore proprio, repository proprio, ritmo di rilascio proprio. È una forza della comunità open source, ma diventa una passività quando ne accumuli una dozzina nello stesso ambiente. I sintomi che vediamo più spesso:
- Compatibilità sfasata con il core - GLPI pubblica una versione maggiore e ogni plugin ha bisogno di un proprio aggiornamento per stare al passo. Basta che uno solo non sia stato portato perché l'intero ambiente si blocchi all'aggiornamento.
- Conflitti tra plugin - due plugin che sovrascrivono lo stesso hook, iniettano CSS in competizione o registrano la stessa rotta. Il sintomo compare spesso lontano dalla causa.
- Dipendenze implicite - un plugin che funziona solo con un altro installato, senza che sia documentato. Disattivare quello sbagliato fa cadere una funzione che nessuno gli associava.
- Superficie di manutenzione moltiplicata - ogni plugin è un changelog da seguire, un CVE da sorvegliare e un "riparte la prossima volta?" a ogni finestra di manutenzione.
Come funziona l'approccio modulare
L'alternativa non è rinunciare alle funzionalità - è ridurre il numero di cose indipendenti da gestire. NexTool ribalta la logica: invece di N plugin, un unico plugin base (gratuito) che ospita moduli attivati su richiesta.
- Un unico punto di installazione - installi e aggiorni il plugin base; i moduli vivono al suo interno, senza che ciascuno sia un pacchetto separato nel marketplace.
- Attiva solo ciò che usi - il catalogo copre IA, comunicazione, documenti, sicurezza, automazione e altro; accendi modulo per modulo secondo l'esigenza, senza portarti dietro ciò che non usi.
- Nessuna gestione di dipendenze tra moduli - la compatibilità tra loro è responsabilità di un unico fornitore, testata insieme a ogni rilascio.
- Un catalogo che cresce - i nuovi moduli arrivano senza esigere una nuova installazione di plugin; compaiono nella schermata dei moduli del plugin già installato.
- Una base gratuita - il plugin base e buona parte del catalogo sono FREE; i moduli con licenza convivono nello stesso posto, e paghi solo ciò che attivi.
Come attivarlo
- Installa il plugin base NexTool come qualsiasi plugin GLPI: scompatta in
plugins/, poi installa e attiva in Configurazione > Plugin. - Nel menu, vai in Configurazione > NexTool > Moduli.
- Individua il modulo desiderato nel catalogo e clicca su attiva.
- Apri la schermata configura del modulo e regola i parametri (chiavi API, canali, profili, ciò che serve).
- Ripeti per ogni modulo. Nessun passaggio richiede di reinstallare il plugin base o risolvere dipendenze a mano.
I tre approcci, fianco a fianco
Non ogni esigenza chiede la stessa risposta. La tabella riassume il compromesso tra colmare una lacuna con un plugin isolato della comunità, con un modulo NexTool o con una funzionalità già nativa di GLPI 11:
| Criterio | Plugin isolato della comunità | Modulo NexTool | Funzionalità nativa di GLPI 11 |
|---|---|---|---|
| Dipendenze | Una per plugin, spesso implicite | Un unico plugin base; moduli testati insieme | Nessuna - fa parte del core |
| Aggiornamento / upgrade | Ogni plugin al suo ritmo; uno in ritardo blocca l'upgrade | Un solo pacchetto da aggiornare, compatibilità garantita dal fornitore | Sale insieme a GLPI |
| Conflitti | Rischio reale tra plugin di manutentori diversi | I moduli convivono nello stesso spazio, senza collisioni di hook | Zero - è il core stesso |
| Supporto | Comunità / volontario, senza SLA | Fornitore unico con canale di supporto | Roadmap ufficiale del progetto GLPI |
| Curva di manutenzione | Cresce con il numero di plugin | Piatta - un solo punto da seguire | Minima, ma limitata a ciò che il core copre |
Prima di ogni upgrade, la prima cosa che facciamo è inventariare cosa è installato e in quale stato. La query che eseguiamo direttamente sul database:
-- Inventario dei plugin installati in GLPI e lo stato di ciascuno.
-- state = 1 significa attivato; gli altri stati meritano attenzione prima dell'upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Cosa abbiamo imparato in manutenzione
In un cliente con più di 15 plugin isolati, un upgrade minore di GLPI ne ha fatti cadere metà: l'ambiente ripartiva, ma quattro plugin restavano in stato "da aggiornare" e sparivano dal menu. Ciò che nessuno si aspettava è che un plugin di report dipendeva da una tabella creata da un altro plugin - disattivare il secondo cancellava in silenzio il primo. Ci è servita un'intera finestra solo per mappare quale plugin bloccava quale. Da lì abbiamo deciso di trattare ogni nuovo plugin come debito di manutenzione, non come funzione gratuita: prima di installare, la domanda è diventata "chi lo mantiene, con quale ritmo di rilascio e cosa si rompe se non riparte al prossimo upgrade?". L'errore comune - che abbiamo già commesso - è installare un plugin per un singolo report e dimenticarlo installato per due anni, finché non diventa il motivo per cui un upgrade non si chiude.
Per chi è (e quando NON usarlo)
L'approccio modulare brilla quando servono più funzionalità coese - IA sul ticket, notifica via WhatsApp, ordine di servizio in PDF, flusso di approvazione - e vuoi un unico fornitore responsabile della compatibilità e del supporto. Se la tua operatività vive di finestre di manutenzione strette e non può permettersi un upgrade bloccato da un plugin orfano, centralizzare conviene.
Ma sii onesto sul contrario: se un singolo plugin della comunità già risolve bene la tua unica esigenza, installalo e vai avanti - non c'è motivo di portare un plugin base per accendere un solo modulo. E soprattutto, guarda prima cosa GLPI fa già nativamente. L'inventario nativo (GLPI Inventory, dal GLPI 10) sostituisce il vecchio FusionInventory nella maggior parte dei casi; i moduli e gli oggetti personalizzati che esigevano FormCreator e GenericObject sono stati incorporati nel core in GLPI 11. Non tutto ha bisogno di un plugin, tanto meno di NexTool: il miglior plugin è spesso quello che non devi installare.
Compatibilità
Il plugin base di NexTool è gratuito e gira sia su GLPI 10 sia su GLPI 11 - i moduli funzionano su entrambe le versioni senza adattamenti. Conta nella pratica: chi migra dal 10 all'11 mantiene la stessa base di moduli da entrambi i lati, senza riscrivere l'integrazione. I moduli con licenza convivono con quelli gratuiti nella stessa schermata, e attivi solo ciò che ti serve.
Se la tua operatività è arrivata al punto in cui gestire i plugin è diventato un lavoro a sé, vale la pena conoscere NexTool come hub modulare - oppure parla con il team per valutare se il tuo caso richiede la centralizzazione o se il core già basta.
Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team Nextool Solutions.
