Installare un plugin per ogni esigenza sembra la soluzione ovvia in GLPI - fino al giorno dell'aggiornamento, quando metà di essi non riparte. Dopo anni di manutenzione di ambienti GLPI dei clienti, abbiamo imparato che il collo di bottiglia non è quasi mai un plugin fatto male: è la somma di una dozzina di plugin isolati, ognuno 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, onestamente, dove non serve.
Il problema: il "plugin sprawl"
Ogni plugin dell'ecosistema GLPI è un progetto a sé: manutentore proprio, repository proprio, ritmo di rilascio proprio. È un punto di forza della comunità open source, ma diventa un passivo quando ne accumuli una dozzina nello stesso ambiente. I sintomi che vediamo più spesso:
- Compatibilità disallineata con il core - GLPI pubblica una versione maggiore e ogni plugin ha bisogno di un proprio aggiornamento per stare al passo. Basta che uno non sia stato portato per bloccare l'intero ambiente in fase di aggiornamento.
- Conflitti tra plugin - due plugin che sovrascrivono lo stesso hook, iniettano CSS in concorrenza o registrano la stessa rotta. Il sintomo si manifesta di solito 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, una CVE da sorvegliare e un "ripartirà la prossima volta?" a ogni finestra di manutenzione.
Prima di tutto: inventaria quello che hai già
Prima di qualsiasi aggiornamento - e prima di installare un altro plugin - la prima cosa che facciamo è elencare cosa è installato e in che stato. La query che lanciamo 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'aggiornamento.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Per ogni riga che compare, tre domande: chi lo mantiene, con che ritmo di rilascio e cosa si rompe se non riparte al prossimo aggiornamento. Un plugin a cui nessuno sa rispondere è candidato a uscire prima della finestra, non durante.
I tre approcci, a confronto
Non ogni esigenza richiede la stessa risposta. La tabella riassume il trade-off tra colmare una lacuna con un plugin isolato della comunità, con un modulo NexTool o con una funzione già nativa di GLPI 11:
| Criterio | Plugin isolato della comunità | Modulo NexTool | Funzione nativa di GLPI 11 |
|---|---|---|---|
| Dipendenze | Una per plugin, spesso implicite | Un unico plugin base; moduli testati insieme | Nessuna - fa parte del core |
| Aggiornamento | Ogni plugin al proprio ritmo; uno in ritardo blocca l'aggiornamento | Un solo pacchetto da aggiornare, con la compatibilità testata dal fornitore | Sale insieme a GLPI |
| Conflitti | Rischio reale tra plugin di manutentori diversi | Minore: i moduli sono testati insieme. Non elimina i bug - concentra la responsabilità in un solo posto | Zero - è il core stesso |
| Copertura delle versioni | Varia da plugin a plugin; può non esistere per la tua versione | La base gira su GLPI 10 e 11; ogni modulo dichiara le versioni che supporta (diversi sono esclusivi della 11) | Segue la versione installata |
| Supporto | Comunità / volontario, senza SLA | Fornitore unico con canale di supporto | Roadmap ufficiale del progetto GLPI |
| Dipendenza dal fornitore | Bassa - codice aperto, puoi fare un fork e mantenerlo | Alta - roadmap, prezzo e continuità dipendono da una sola azienda | Quella del progetto GLPI stesso |
| Curva di manutenzione | Cresce con il numero di plugin | Piatta - un solo punto da seguire | Minima, ma limitata a ciò che il core copre |
Come funziona l'approccio modulare
L'alternativa non è rinunciare alle funzioni - è 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 ognuno 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 necessità, senza portarti dietro ciò che non usi.
- Nessuna dipendenza da gestire 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 richiedere una nuova installazione di plugin; compaiono nella schermata dei moduli del plugin già installato.
- Base gratuita - il plugin base e buona parte dei moduli sono FREE; quelli con licenza convivono nello stesso posto e paghi solo ciò che attivi.
Cosa abbiamo imparato in manutenzione
In un cliente con più di 15 plugin isolati, un aggiornamento minore di GLPI ne ha fatti cadere metà: l'ambiente ripartiva, ma quattro plugin restavano in stato "da aggiornare" e sparivano dal menu. Quello che nessuno si aspettava è che un plugin di reportistica dipendeva da una tabella creata da un altro plugin - disattivare il secondo cancellava silenziosamente il primo. Abbiamo speso 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 una funzione gratis. 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 aggiornamento non si chiude.
A chi è indicato (e quando NON usarlo)
L'approccio modulare brilla quando servono più funzioni coese - IA sul ticket, notifica via WhatsApp, ordine di lavoro 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 aggiornamento bloccato da un plugin orfano, centralizzare conviene.
Ma sii onesto sul contrario: se un singolo plugin della comunità risolve già 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 form e gli oggetti personalizzati, che richiedevano 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.
C'è inoltre un trade-off che la centralizzazione non risolve, si limita a spostarlo: concentrare le funzioni in un unico fornitore concentra anche il rischio. Con plugin open source isolati, se il manutentore abbandona il progetto puoi fare un fork e proseguire. Con un hub proprietario, roadmap, prezzo e continuità finiscono per dipendere da una sola azienda. Non è un motivo per scartare l'approccio - è un motivo per valutare il fornitore come valuteresti qualsiasi altro: storico dei rilasci, canale di supporto e cosa succede ai tuoi dati se decidi di andartene.
Come attivare un modulo
- Installa il plugin base NexTool come qualsiasi plugin GLPI: scompatta in
plugins/, poi installa e attiva in Configurazione > Plugin. - Nel menu, vai su Configurazione > NexTool > Moduli.
- Individua il modulo desiderato nel catalogo, verifica quali versioni di GLPI supporta e clicca su attiva.
- Apri la schermata configura del modulo e imposta i parametri (chiavi API, canali, profili, quel che serve).
- Ripeti per ogni modulo. Nessun passaggio richiede di reinstallare il plugin base né di risolvere dipendenze a mano.
Compatibilità
Il plugin base di NexTool è gratuito e gira sia su GLPI 10 sia su GLPI 11. La compatibilità dei moduli, però, è dichiarata modulo per modulo: parte del catalogo è cross-version e gira su entrambe, mentre buona parte dei moduli più recenti è esclusiva di GLPI 11, perché si appoggia a funzioni che esistono solo lì. Il catalogo mostra le versioni supportate da ciascun modulo e l'attivazione viene bloccata con un messaggio esplicito quando l'ambiente non è compatibile - lo scopri prima di installare, non a metà dell'aggiornamento.
In pratica, per chi migra dalla 10 alla 11: verifica nel catalogo quali dei moduli che usi sono cross-version. È lo stesso inventario che questo articolo raccomanda per qualsiasi plugin - con la differenza che qui l'informazione sta in un posto solo, invece di essere sparsa su una dozzina di repository.
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 centralizzazione o se il core basta già.
Revisionato dal team NexTool Solutions.
