Instalar um plugin para cada necessidade parece a solução óbvia no GLPI - até o dia do upgrade, quando metade deles não sobe. Depois de anos sustentando ambientes GLPI de clientes, aprendemos que o gargalo raramente é um plugin ruim: é a soma de uma dúzia de plugins avulsos, cada um com seu ciclo de release, sua dependência e seu mantenedor. Este guia mostra como escolher e combinar extensões sem cair no "plugin sprawl", onde a abordagem modular do NexTool encaixa - e, com honestidade, onde ela não é necessária.
O problema: o "plugin sprawl"
Cada plugin do ecossistema GLPI é um projeto à parte: mantenedor próprio, repositório próprio, ritmo de release próprio. Isso é uma força da comunidade open source, mas vira passivo quando você acumula uma dúzia deles no mesmo ambiente. Os sintomas que vemos com mais frequência:
- Compatibilidade descasada com o core - o GLPI lança uma versão maior e cada plugin precisa de uma atualização própria para acompanhar. Basta um não ter sido portado para o ambiente inteiro travar no upgrade.
- Conflitos entre plugins - dois plugins que sobrescrevem o mesmo hook, injetam CSS concorrente ou registram a mesma rota. O sintoma costuma aparecer longe da causa.
- Dependências implícitas - um plugin que só funciona com outro instalado, sem que isso esteja documentado. Desligar o errado derruba uma função que ninguém associava a ele.
- Superfície de manutenção multiplicada - cada plugin é um changelog para acompanhar, um CVE para vigiar e um "será que sobe na próxima?" a cada janela de manutenção.
Antes de tudo: inventarie o que você já tem
Antes de qualquer upgrade - e antes de instalar mais um plugin - a primeira coisa que fazemos é levantar o que está instalado e em que estado. A consulta que rodamos direto no banco:
-- Inventario dos plugins instalados no GLPI e o estado de cada um.
-- state = 1 significa ativado; os demais estados merecem atencao antes do upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Para cada linha que aparecer, três perguntas: quem mantém, com que ritmo de release, e o que quebra se ele não subir no próximo upgrade. Plugin que ninguém souber responder é candidato a sair antes da janela, não durante.
As três abordagens, lado a lado
Nem toda necessidade pede a mesma resposta. A tabela resume o trade-off entre resolver uma lacuna com um plugin avulso da comunidade, com um módulo do NexTool ou com um recurso já nativo do GLPI 11:
| Critério | Plugin avulso da comunidade | Módulo NexTool | Recurso nativo do GLPI 11 |
|---|---|---|---|
| Dependências | Uma por plugin, muitas vezes implícitas | Um único plugin base; módulos testados em conjunto | Nenhuma - faz parte do core |
| Atualização / upgrade | Cada plugin no seu ritmo; um atrasado trava o upgrade | Um pacote para atualizar, com a compatibilidade testada pelo fornecedor | Sobe junto com o GLPI |
| Conflitos | Risco real entre plugins de mantenedores diferentes | Menor: os módulos são testados em conjunto. Não elimina bugs - concentra a responsabilidade em um só lugar | Zero - é o próprio core |
| Cobertura de versões | Varia por plugin; pode não existir para a sua versão | Base roda no GLPI 10 e 11; cada módulo declara em quais versões roda (vários são exclusivos do 11) | Acompanha a versão instalada |
| Suporte | Comunidade / voluntário, sem SLA | Fornecedor único com canal de suporte | Roadmap oficial do projeto GLPI |
| Dependência de fornecedor | Baixa - código aberto, você pode forkar e manter | Alta - roadmap, preço e continuidade dependem de uma empresa só | Do próprio projeto GLPI |
| Curva de manutenção | Cresce com o número de plugins | Plana - um ponto para acompanhar | Mínima, mas limitada ao que o core cobre |
Como funciona a abordagem modular
A alternativa não é abrir mão de recursos - é reduzir o número de coisas independentes que precisam ser gerenciadas. O NexTool inverte a lógica: em vez de N plugins, um único plugin base (gratuito) que hospeda módulos ativados sob demanda.
- Um único ponto de instalação - você instala e atualiza o plugin base; os módulos vivem dentro dele, sem cada um ser um pacote separado no marketplace.
- Ative só o que usa - o catálogo traz IA, comunicação, documentos, segurança, automação e mais; você liga módulo a módulo conforme a necessidade, sem carregar o que não usa.
- Sem gerenciar dependências entre módulos - a compatibilidade entre eles é responsabilidade de um único fornecedor, testada em conjunto a cada release.
- Catálogo que cresce - novos módulos chegam sem exigir uma nova instalação de plugin; aparecem na tela de módulos do plugin já instalado.
- Base gratuita - o plugin base e boa parte dos módulos são FREE; os licenciados convivem no mesmo lugar, e você paga só pelo que ativa.
O que aprendemos na sustentação
Num cliente com mais de 15 plugins avulsos, um upgrade menor do GLPI derrubou metade deles: o ambiente subia, mas quatro plugins ficavam em estado "a atualizar" e sumiam do menu. O que ninguém esperava é que um plugin de relatórios dependia de uma tabela que outro plugin criava - desligar o segundo apagava silenciosamente o primeiro. Levamos uma janela inteira só para mapear qual plugin travava qual. Decidimos, a partir dali, tratar cada plugin novo como dívida de manutenção, não como recurso grátis. O erro comum - que já cometemos - é instalar um plugin para um único relatório e esquecê-lo instalado por dois anos, até ele ser o motivo de um upgrade não fechar.
Para quem é indicado (e quando NÃO usar)
A abordagem modular brilha quando você precisa de vários recursos coesos - IA no chamado, notificação por WhatsApp, ordem de serviço em PDF, fluxo de aprovação - e quer um único fornecedor responsável pela compatibilidade e pelo suporte. Se a sua operação vive de janelas de manutenção apertadas e não pode se dar ao luxo de um upgrade travado por um plugin órfão, centralizar compensa.
Mas seja honesto sobre o oposto: se um único plugin da comunidade já resolve bem a sua única necessidade, instale-o e siga em frente - não há por que trazer um plugin base para ligar um módulo só. E, principalmente, olhe primeiro para o que o GLPI já faz nativamente. O inventário nativo (GLPI Inventory, desde o GLPI 10) substitui o antigo FusionInventory na maioria dos casos; os formulários e os objetos personalizados, que exigiam FormCreator e GenericObject, foram incorporados ao core no GLPI 11. Nem tudo precisa de plugin, e muito menos de NexTool: o melhor plugin costuma ser o que você não precisa instalar.
Há ainda um trade-off que a centralização não resolve, apenas troca de lugar: concentrar recursos num único fornecedor concentra também o risco. Com plugins avulsos de código aberto, se o mantenedor abandona o projeto você pode forkar e seguir. Com um hub proprietário, roadmap, preço e continuidade passam a depender de uma empresa só. Não é motivo para descartar a abordagem - é motivo para avaliar o fornecedor como você avaliaria qualquer outro: histórico de releases, canal de suporte, e o que acontece com os seus dados se você decidir sair.
Como ativar um módulo
- Instale o plugin base NexTool como qualquer plugin do GLPI: descompacte em
plugins/, depois instale e ative em Configurar > Plugins. - No menu, vá em Configuração > NexTool > Módulos.
- Localize o módulo desejado no catálogo, confira as versões do GLPI que ele suporta e clique em ativar.
- Abra a tela configurar do módulo e ajuste os parâmetros (chaves de API, canais, perfis, o que couber).
- Repita para cada módulo. Nenhum passo exige reinstalar o plugin base nem resolver dependências à mão.
Compatibilidade
O plugin base do NexTool é gratuito e roda tanto no GLPI 10 quanto no GLPI 11. A compatibilidade dos módulos, porém, é declarada módulo a módulo: parte do catálogo é cross-version e roda nas duas, enquanto boa parte dos módulos mais recentes é exclusiva do GLPI 11, por se apoiar em recursos que só existem lá. O catálogo mostra as versões suportadas por cada módulo, e a ativação é bloqueada com mensagem explícita quando o ambiente não é compatível - você descobre antes de instalar, não no meio do upgrade.
Na prática, para quem está migrando do 10 para o 11: verifique no catálogo quais dos módulos que você usa são cross-version. É o mesmo inventário que este post recomenda para qualquer plugin - com a diferença de que aqui a informação está num lugar só, e não espalhada por uma dezena de repositórios.
Se a sua operação chegou ao ponto em que gerenciar plugins virou um trabalho por si só, vale conhecer o NexTool como hub modular - ou fale com a equipe para avaliar se o seu caso pede centralização ou se o core já resolve.
Revisado pela equipe NexTool Solutions.
