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 dar suporte a 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çamentos, 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çamentos próprio. Isso é uma força da comunidade open source, mas torna-se um passivo quando se acumula uma dúzia deles no mesmo ambiente. Os sintomas que vemos com mais frequência:
- Compatibilidade desfasada do 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 ficar bloqueado na atualização.
- Conflitos entre plugins - dois plugins que sobrepõem 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 lhe associava.
- Superfície de manutenção multiplicada - cada plugin é um changelog para acompanhar, um CVE para vigiar e um "será que arranca na próxima?" em cada janela de manutenção.
Antes de mais: inventarie o que já tem
Antes de qualquer atualização - e antes de instalar mais um plugin - a primeira coisa que fazemos é listar 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 da atualizacao.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Para cada linha que aparecer, três perguntas: quem o mantém, com que ritmo de lançamentos, e o que parte se ele não arrancar na próxima atualização. Um plugin a que ninguém saiba responder é candidato a sair antes da janela, não durante.
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 | Cada plugin ao seu ritmo; um atrasado bloqueia a atualização | Um pacote para atualizar, com a compatibilidade testada pelo fornecedor | Sobe juntamente com o GLPI |
| Conflitos | Risco real entre plugins de responsáveis diferentes | Menor: os módulos são testados em conjunto. Não elimina bugs - concentra a responsabilidade num só sítio | Zero - é o próprio core |
| Cobertura de versões | Varia consoante o plugin; pode não existir para a sua versão | A base corre no GLPI 10 e 11; cada módulo declara em que versões corre (vários são exclusivos do 11) | Acompanha a versão instalada |
| Suporte | Comunidade / voluntário, sem SLA | Fornecedor único com canal de suporte | Roteiro oficial do projeto GLPI |
| Dependência do fornecedor | Baixa - código aberto, pode fazer fork e manter | Alta - roteiro, preço e continuidade dependem de uma só empresa | A 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 é 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 que cada um seja 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.
- Catálogo que cresce - novos módulos chegam sem exigir uma nova instalação de plugin; aparecem no ecrã 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 sítio, e paga só pelo que ativa.
O que aprendemos no suporte
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 que plugin bloqueava qual. A partir daí decidimos tratar cada plugin novo como dívida de manutenção, não como funcionalidade grátis. O erro comum - que já cometemos - é instalar um plugin para um único relatório e esquecê-lo instalado durante dois anos, até ser ele 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 bloqueada 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 módulo só. 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 no core no GLPI 11. Nem tudo precisa de plugin, e muito menos de NexTool: o melhor plugin costuma ser aquele que não é preciso instalar.
Há ainda um compromisso que a centralização não resolve, apenas muda de sítio: concentrar funcionalidades num único fornecedor concentra também o risco. Com plugins avulsos de código aberto, se o responsável abandonar o projeto pode fazer fork e continuar. Com um hub proprietário, roteiro, preço e continuidade passam a depender de uma só empresa. Não é motivo para descartar a abordagem - é motivo para avaliar o fornecedor como avaliaria qualquer outro: histórico de lançamentos, canal de suporte, e o que acontece aos seus dados se 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á a Configuração > NexTool > Módulos.
- Localize o módulo pretendido no catálogo, confirme as versões do GLPI que ele suporta 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.
Compatibilidade
O plugin base do NexTool é gratuito e corre tanto no GLPI 10 como no GLPI 11. A compatibilidade dos módulos, porém, é declarada módulo a módulo: parte do catálogo é cross-version e corre nas duas, ao passo que boa parte dos módulos mais recentes é exclusiva do GLPI 11, por assentar em funcionalidades 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 - descobre antes de instalar, não a meio da atualização.
Na prática, para quem está a migrar do 10 para o 11: verifique no catálogo quais dos módulos que usa são cross-version. É o mesmo inventário que este artigo recomenda para qualquer plugin - com a diferença de que aqui a informação está num só sítio, e não espalhada por uma dúzia de repositórios.
Se a sua operação chegou ao ponto em que gerir plugins passou a ser 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.
Revisto pela equipa NexTool Solutions.
