Instalar um plugin para cada necessidade parece a solução óbvia no GLPI - até ao dia da atualização, quando metade deles não arranca. Depois de anos a sustentar ambientes GLPI de clientes, aprendemos que o estrangulamento raramente é um plugin mau: é a soma de uma dúzia de plugins avulsos, cada um com o seu ciclo de lançamento, a sua dependência e o seu responsável. Este guia mostra como escolher e combinar extensões sem cair no "plugin sprawl", onde encaixa a abordagem modular do NexTool - e, com honestidade, onde ela não é necessária.
O problema: o "plugin sprawl"
Cada plugin do ecossistema GLPI é um projeto à parte: responsável próprio, repositório próprio, ritmo de lançamento próprio. Isso é uma força da comunidade open source, mas torna-se um passivo quando acumula uma dúzia deles no mesmo ambiente. Os sintomas que vemos com mais frequência:
- Compatibilidade desfasada 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 na atualização.
- Conflitos entre plugins - dois plugins que sobrescrevem o mesmo hook, injetam CSS concorrente ou registam 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 deita abaixo 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 arranca na próxima?" a cada janela de manutenção.
Como funciona a abordagem modular
A alternativa não é abdicar de funcionalidades - é reduzir o número de coisas independentes que é preciso gerir. O NexTool inverte a lógica: em vez de N plugins, um único plugin base (gratuito) que aloja módulos ativados a pedido.
- Um único ponto de instalação - 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; liga módulo a módulo conforme a necessidade, sem carregar o que não usa.
- Sem gerir dependências entre módulos - a compatibilidade entre eles é responsabilidade de um único fornecedor, testada em conjunto a cada lançamento.
- Um catálogo que cresce - os novos módulos chegam sem exigir uma nova instalação de plugin; aparecem no ecrã de módulos do plugin já instalado.
- Uma base gratuita - o plugin base e boa parte do catálogo são FREE; os módulos com licença convivem no mesmo sítio, e paga só pelo que ativa.
Como ativar
- Instale o plugin base NexTool como qualquer plugin do GLPI: descompacte em
plugins/, depois instale e ative em Configurar > Plugins. - No menu, vá a Configuração > NexTool > Módulos.
- Localize o módulo pretendido no catálogo e clique em ativar.
- Abra o ecrã configurar do módulo e ajuste os parâmetros (chaves de API, canais, perfis, o que se aplicar).
- Repita para cada módulo. Nenhum passo exige reinstalar o plugin base nem resolver dependências à mão.
As três abordagens, lado a lado
Nem toda a necessidade pede a mesma resposta. A tabela resume o compromisso entre resolver uma lacuna com um plugin avulso da comunidade, com um módulo do NexTool ou com uma funcionalidade já nativa do GLPI 11:
| Critério | Plugin avulso da comunidade | Módulo NexTool | Funcionalidade nativa 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 ao seu ritmo; um atrasado trava a atualização | Um pacote para atualizar, compatibilidade garantida pelo fornecedor | Sobe junto com o GLPI |
| Conflitos | Risco real entre plugins de responsáveis diferentes | Os módulos convivem no mesmo espaço, sem colisão de hooks | Zero - é o próprio core |
| Suporte | Comunidade / voluntário, sem SLA | Fornecedor único com canal de suporte | Roadmap oficial do 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 |
Antes de qualquer atualização, a primeira coisa que fazemos é inventariar o que está instalado e em que estado. A consulta que corremos diretamente na base de dados:
-- Inventario dos plugins instalados no GLPI e o estado de cada um.
-- state = 1 significa ativado; os restantes estados merecem atencao antes do upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;O que aprendemos na sustentação
Num cliente com mais de 15 plugins avulsos, uma atualização menor do GLPI deitou abaixo metade deles: o ambiente arrancava, mas quatro plugins ficavam em estado "a atualizar" e desapareciam 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. Levámos uma janela inteira só para mapear qual plugin travava qual. Decidimos, a partir daí, tratar cada plugin novo como dívida de manutenção, não como funcionalidade grátis: antes de instalar, a pergunta passou a ser "quem mantém, com que ritmo de lançamento e o que quebra se ele não arrancar na próxima atualização?". O erro comum - que já cometemos - é instalar um plugin para um único relatório e esquecê-lo instalado durante dois anos, até ser o motivo de uma atualização não fechar.
Para quem é indicado (e quando NÃO usar)
A abordagem modular brilha quando precisa de várias funcionalidades coesas - IA no pedido, 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 se pode dar ao luxo de uma atualização travada por um plugin órfão, centralizar compensa.
Mas seja honesto quanto ao oposto: se um único plugin da comunidade já resolve bem a sua única necessidade, instale-o e siga em frente - não há razão para trazer um plugin base para ligar um só módulo. E, sobretudo, 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 não precisa de instalar.
Compatibilidade
O plugin base do NexTool é gratuito e corre tanto no GLPI 10 como no GLPI 11 - os módulos funcionam nas duas versões sem adaptação. Isto importa na prática: quem está a migrar do 10 para o 11 mantém a mesma base de módulos dos dois lados, sem reescrever a integração. Os módulos com licença convivem com os gratuitos no mesmo ecrã, e ativa apenas o que precisa.
Se a sua operação chegou ao ponto em que gerir plugins se tornou um trabalho por si só, vale a pena conhecer o NexTool como hub modular - ou fale com a equipa para avaliar se o seu caso pede centralização ou se o core já resolve.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisto pela equipa Nextool Solutions.
