GLPI 11: ITSM e Helpdesk Self-Hosted

O GLPI é um sistema open source de ITSM (gestão de serviços de TI) que junta helpdesk, inventário automático e gestão de recursos técnicos numa única aplicação web. Para uma PME, significa trocar emails e folhas de cálculo por uma fila de tickets organizada, com cada máquina da rede inventariada sem trabalho manual. É software livre (licença GNU GPLv3) e corre num servidor próprio, num stack LAMP ou num contentor Docker.

A versão 11 trouxe mudanças que interessam a quem vem do 10.x: os formulários passaram a ser nativos (o plugin Formcreator deixa de ser necessário), o catálogo de serviços foi redesenhado com categorias hierárquicas e pesquisa instantânea, e o portal do utilizador final ganhou tradução por entidade. Este artigo percorre o caminho completo: instalar o GLPI 11, fazer o primeiro arranque com o instalador web, ligar o glpi-agent para inventário, criar tickets com SLAs, configurar as notificações por email, organizar perfis e entidades e, por fim, montar uma rotina de manutenção e backups.

Neste artigo:

1. Instalar o GLPI 11
2. Primeiro arranque e o instalador web
3. Inventário com o glpi-agent
4. Tickets: tipos, SLA e atribuição
5. Notificações por email
6. Perfis e entidades
7. Manutenção e backups
8. Erros Comuns
9. Checklist
10. Artigos Relacionados
11. Fontes Oficiais

1. Instalar o GLPI 11

O GLPI é uma aplicação web em PHP com base de dados MySQL/MariaDB. Antes de descarregar nada, confirma os requisitos na página oficial de pré-requisitos — são os mesmos que o instalador web vai verificar no arranque:

Duas notas sobre o GLPI 11 em concreto: a extensão bcmath passou a ser obrigatória (geração de códigos QR) e o openssl também (comunicação encriptada com os agentes de inventário e autenticação OAuth 2.0). Quem vem de uma instalação do GLPI 10 com PHP 7.4 precisa primeiro de actualizar o PHP.

Caminho A — Tarball num stack LAMP (Ubuntu 22.04 LTS)

Começa por instalar a stack completa. Atenção: os repositórios do Ubuntu 22.04 trazem PHP 8.1 e o GLPI 11 exige 8.2 ou superior — o comando seguinte vem do tutorial oficial, mas em 22.04 falta-lhe o PHP compatível; acrescenta antes o repositório ondrej/php, que disponibiliza as versões recentes de PHP:

apt update && apt upgrade
add-apt-repository ppa:ondrej/php && apt update
apt install -y apache2 php8.3 php8.3-{apcu,cli,common,curl,gd,ldap,mysql,xmlrpc,xml,mbstring,bcmath,intl,zip,redis,bz2} libapache2-mod-php8.3 php8.3-soap php8.3-cas
php -v && apache2ctl -M | grep php
apt install -y mariadb-server

Prepara a MariaDB. O mysql_secure_installation define a palavra-passe de root e remove as configurações inseguras de fábrica:

mysql_secure_installation
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql mysql

O último comando carrega os fusos horários do sistema para a base de dados — o GLPI precisa deles para os calendários e SLAs funcionarem, e o tutorial oficial recomenda-o sempre.

Cria a base de dados e o utilizador exclusivos do GLPI. Usa uma palavra-passe forte de verdade — a que está no exemplo serve apenas de marcação:

CREATE DATABASE glpi;
CREATE USER 'glpi'@'localhost' IDENTIFIED BY 'SenhaForte123!';
GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'localhost';
GRANT SELECT ON `mysql`.`time_zone_name` TO 'glpi'@'localhost';
FLUSH PRIVILEGES;

Descarrega e extrai o pacote oficial. A versão 11.0.9 é a mais recente neste momento — confirma sempre a última no site oficial antes de copiar o comando:

cd /var/www/html
wget https://github.com/glpi-project/glpi/releases/download/11.0.9/glpi-11.0.9.tgz
tar -xvzf glpi-11.0.9.tgz
chown -R www-data:www-data /var/www/html/glpi

A instalação em produção também pode seguir o padrão FHS (Filesystem Hierarchy Standard) documentado no tutorial oficial: código em /var/www/html/glpi, configuração em /etc/glpi, ficheiros variáveis em /var/lib/glpi e registos em /var/log/glpi. Para isso, cria um inc/downstream.php que define GLPI_CONFIG_DIR e um local_define.php que aponta GLPI_VAR_DIR — é mais trabalho inicial, mas torna as actualizações mais limpas porque os dados ficam fora do directório de código.

O último detalhe do lado do Apache: desde a versão 10.0.7, o GLPI usa a subpasta public/ como entrada. O DocumentRoot do site deve apontar para glpi/public, com regras de reescrita que enviam os pedidos para o index.php. A configuração de exemplo para Apache está na página oficial de pré-requisitos (secção Web server). Se apontares o vhost para a raiz do GLPI, o próprio sistema avisa que a configuração não é segura e que expõe ficheiros não públicos.

Caminho B — Docker

O projecto publica uma imagem oficial e uma stack completa no Docker Hub (glpi/glpi). Cria uma pasta de trabalho com dois ficheiros:

# docker-compose.yml
name: glpi
services:
  glpi:
    image: "glpi/glpi:latest"
    restart: "unless-stopped"
    volumes:
       - glpi_data:/var/glpi
    env_file: .env
    depends_on:
      - db
    ports:
      - "80:80"
  db:
    image: "mysql"
    restart: "unless-stopped"
    volumes:
       - db_data:/var/lib/mysql
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "yes"
      MYSQL_DATABASE: ${GLPI_DB_NAME}
      MYSQL_USER: ${GLPI_DB_USER}
      MYSQL_PASSWORD: ${GLPI_DB_PASSWORD}
volumes:
  glpi_data:
  db_data:

# .env
GLPI_DB_HOST=db
GLPI_DB_PORT=3306
GLPI_DB_NAME=glpi
GLPI_DB_USER=glpi
GLPI_DB_PASSWORD=glpi

Depois é uma linha:

docker compose up -d

Na versão 11, os ficheiros do GLPI (incluindo os plugins do Marketplace) vivem dentro do volume glpi_data montado em /var/glpi — no 10.x havia um volume separado para a pasta marketplace, já desnecessário.

Para suporte a fusos horários no stack Docker, dois passos — primeiro concede o acesso à tabela de fusos:

docker exec -it <id_do_contentor_db> mysql -u root -p -e "GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'%';FLUSH PRIVILEGES;"
docker exec -it <id_do_contentor_glpi> /var/www/glpi/bin/console database:enable_timezones

2. Primeiro arranque e o instalador web

Abre o endereço do servidor no browser (http://IP_DO_SERVIDOR/). Numa instalação LAMP, como o GLPI ainda não está instalado, o instalador web arranca automaticamente — os passos, pela ordem em que aparecem: no stack Docker a imagem instala a base de dados sozinha por omissão (só com GLPI_SKIP_AUTOINSTALL=true no .env é que o instalador web arranca):

1. Idioma — escolhe português (Portugal) e valida.
2. Licença — aceita os termos da GNU GPLv3 para continuar.
3. Instalar ou actualizar — escolhe Instalar numa instalação nova.
4. Verificação do ambiente — o instalador confere as extensões PHP e as versões. Falhas críticas bloqueiam o avanço e as opcionais apenas avisam. Se algo faltar aqui, instala a extensão em falta e recarrega.
5. Ligação à base de dados — servidor (localhost), utilizador (glpi) e a palavra-passe definida no passo anterior.
6. Base de dados — escolhe a existente ou cria uma nova. Atenção: se seleccionares uma base de dados existente com dados, o conteúdo é destruído pela inicialização.
7. Inicialização — o GLPI preenche as tabelas com os valores por omissão.
8. Telemetria e registo — partilhar estatísticas anónimas é opcional e podes saltar.
9. Fim — o resumo final lista as contas criadas. Anota-o.

Ao terminar, o GLPI abre o ecrã de início de sessão com quatro contas por omissão:

Trata destas contas no mesmo dia. A documentação oficial é explícita: cria primeiro um utilizador novo com perfil de super-admin, inicia sessão com ele e só então muda as palavras-passe ou remove as contas de fábrica. Deixar a glpi/glpi activa é o erro de segurança mais comum em instalações novas.

Ainda no primeiro arranque, define o URL da aplicação em Configuração > Geral > Configuração geral. O endereço é usado nos links das notificações por email e na configuração do agente de inventário — corrigi-lo depois de os utilizadores já receberem emails é trabalho dobrado.

3. Inventário com o glpi-agent

O inventário de equipas é nativo desde o GLPI 10 — dispensa plugins para o inventário de máquinas. Para o activar: Administração > Inventário e confirma que a opção de activar o inventário está ligada. A partir daqui, o servidor aceita os inventários enviados pelos agentes.

O agente oficial é o glpi-agent, disponível no GitHub do projecto (glpi-project/glpi-agent/releases) em MSI para Windows, instalador Perl para GNU/Linux, AppImage, RPM e Snap. A versão estável mais recente é a 1.20.

Windows — instalação silenciosa por linha de comandos, com o servidor de inventário definido logo na instalação:

msiexec /i GLPI-Agent-1.20-x64.msi /quiet RUNNOW=1 ADD_FIREWALL_EXCEPTION=1 SERVER="http://glpi.pme.local/front/inventory.php" TAG="escritorio"

RUNNOW=1 força um inventário logo após a instalação, ADD_FIREWALL_EXCEPTION=1 abre o acesso no firewall do Windows e TAG carimba a máquina com uma etiqueta que depois usas para filtrar no GLPI.

GNU/Linux — o instalador Perl acompanha a mesma lógica de opções:

wget https://github.com/glpi-project/glpi-agent/releases/download/1.20/glpi-agent-1.20-linux-installer.pl
perl glpi-agent-1.20-linux-installer.pl --server http://glpi.pme.local/front/inventory.php --tag servidores

A configuração fica em /etc/glpi-agent/agent.cfg (sistemas compatíveis com FHS). O aconselhável é não editar o ficheiro principal — usa um ficheiro na pasta conf.d/ — porque as actualizações do agente podem repor o original:

# /etc/glpi-agent/conf.d/local.cfg
server = http://glpi.pme.local/front/inventory.php
tag = servidores

Depois de instalar e reiniciar o serviço do agente, abre Parque de Informática > Computadores no GLPI — a máquina surge em poucos minutos, com sistema operativo, placa de rede, discos, software instalado e histórico de hardware.

Para distribuir o agente a um parque Windows inteiro, a documentação oficial descreve a via GPO: uma partilha de rede com os MSI, o script glpi-agent-deployment.vbs (do repositório oficial do agente, com a versão e o servidor editados no topo do ficheiro) e uma GPO de script de arranque da máquina.

Duas notas úteis de operação:

• Nos agentes Windows aparecem erros 400 Bad Request, Protocol not supported nos pedidos das tarefas Collect e Deploy — estas tarefas só funcionam com o plugin GLPI Inventory (instalável no Marketplace em Configuração > Plugins, gratuito). Se só queres o inventário de máquinas, os erros podem ser ignorados.
• O inventário de rede (descoberta de equipamentos e SNMP — impressoras, switches) também corre pelo plugin GLPI Inventory com o agente a fazer o trabalho de campo.

4. Tickets: tipos, SLA e atribuição

Um ticket assume um de dois tipos: incidente (algo deixou de funcionar) ou pedido (uma solicitação de serviço). Problema e alteração não são tipos de ticket — são objectos ITIL próprios, com registo separado no GLPI, aos quais se podem associar tickets: o problema analisa a causa raiz por trás de incidentes repetidos, a alteração planeia mudanças na infraestrutura. Para o dia-a-dia de um helpdesk de PME, o par incidente/pedido cobre quase tudo — problema e alteração servem as equipas que querem separar o trabalho correctivo do planeado.

Uma categoria ajuda a encaminhar. As categorias criam-se em Configuração > Intitulados, pesquisando por ITIL e escolhendo Categorias ITIL. Atribuir categoria a todos os tickets é o que depois permite relatórios úteis por tipo de pedido.

O ciclo do ticket e a atribuição

O ticket nasce no estado Novo e percorre Em curso (atribuído), Pendente e Resolvido, terminando em Fechado — o fecho automático após a resolução configura-se por entidade em Administração > Entidades > Assistência, no campo de fecho automático dos tickets resolvidos.

A atribuição pode ser manual (selecciona técnico ou grupo no campo de atribuição) ou automática através dos motoristas de atribuição em Administração > Motoristas, que distribuem os tickets por técnico, grupo ou entidade segundo critérios como a categoria ou a origem. O registo do tempo do técnico no ticket faz-se nas Acções adicionais de cada seguimento (follow-up), escolhendo duração e categoria de tempo — é este registo que alimenta as estatísticas.

Nos seguimentos, distinguir público de privado é essencial: o seguimento público é visível ao utilizador que abriu o ticket, enquanto o privado só é visto por quem tem direito a isso (técnicos, gestão). Nos tickets, o pedido pode responder, e a equipa usa os seguimentos privados para notas internas sem expor discussões internas.

SLAs: TTO e TTR

Um SLA (Service Level Agreement) compromete prazos com o utilizador: o TTO (Time to Own) mede o tempo até o ticket ser assumido, o TTR (Time to Resolve) mede o tempo até estar resolvido. Os OLAs são o mesmo mecanismo aplicado internamente entre equipas. Em GLPI, configuram-se assim:

1. Define o calendário de trabalho em Configuração > Calendários — as datas dos SLAs contam apenas as horas do calendário, por isso o calendário certo é metade do trabalho.
2. Cria o SLA em Configuração > Níveis de serviço > Adicionar: nome, calendário e, no interior do SLA, os itens Time to own (ex. 4 horas) e Time to resolve (ex. 5 dias).
3. Atribui o SLA ao ticket de três formas: manualmente (no ticket, secção Níveis de serviço), por motorista (ex. todos os tickets da entidade X levam o SLA do contrato X) ou por modelo de ticket (Assistência > Tickets > Modelos > Campos pré-definidos).
4. Configura os níveis de escalonamento dentro do SLA: por exemplo, se o ticket ainda estiver no estado Novo quando o TTO expira, atribuir automaticamente um grupo de técnicos e subir a prioridade. Também é possível notificar a equipa dias antes de o TTR terminar.

O cálculo termina quando o estado muda: o TTO conta até o ticket ser atribuído a um técnico ou grupo, e o TTR recomeça a contar quando um ticket em Pendente regressa a Em curso, somando o tempo em espera. O cumprimento vê-se no separador Estatísticas do ticket — os indicadores em vermelho são os que falharam.

Dois requisitos operacionais para os lembretes de SLA funcionarem: a acção automática slaticket tem de estar em modo CLI (ver próximo ponto) e a notificação TicketRecall tem de ter destinatários.

Acções automáticas em CLI, não em GLPI

As tarefas agendadas do GLPI (fechos automáticos, lembretes de SLA, notificações em fila, purgas) dependem da acção automática correspondente estar a correr. Por omissão, muitas correm em modo GLPI — só disparam quando alguém usa a interface, o que à noite e ao fim de semana significa não disparar. Muda para CLI em Configuração > Acções automáticas: neste modo, quem as dispara é o cron do sistema:

crontab -e -u www-data
# crontab de utilizador: SEM campo de utilizador (esse campo só existe em /etc/crontab e /etc/cron.d/*)
* * * * * /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

A documentação oficial indica o script front/cron.php como o runner das acções automáticas em CLI, executado a cada minuto pelo cron do sistema, com a opção --force <acção> para forçar uma acção específica (ex. php front/cron.php --force mailgate). Neste modo, as acções disparam à hora agendada independentemente de alguém estar a usar o GLPI. Sem este passo, os tickets resolvem-se mas as notificações e SLAs atrasam-se sem razão aparente — um clássico dos fóruns de suporte.

5. Notificações por email

As notificações por email configuram-se em Configuração > Notificações. O caminho, por ordem:

1. Activa as notificações por email e guarda — só depois aparece o formulário de configuração do servidor de email.
2. Preenche o email do administrador, a assinatura das mensagens e o método de envio: SMTP, SMTP + SSL, SMTP + TLS ou SMTP + OAUTH (PHP é o método por omissão mas a documentação oficial recomenda mudar para SMTP numa instalação própria).
3. Indica o servidor SMTP no formato servidor:porta (ex. smtp.office365.com:587), o utilizador e a palavra-passe.
4. Grava e usa o botão de testar envio de email para validar na hora.

Para Microsoft 365, o caminho moderno é o SMTP + OAUTH — a Microsoft está a desactivar gradualmente a autenticação básica por TLS, e o GLPI suporta o fluxo OAuth 2.0 (com Entra ID). O OAuth tem uma regra: a conta usada na autenticação tem de ser a mesma do remetente das mensagens. Para Google Workspace com OAuth no receptor IMAP, existe o plugin Oauth IMAP no Marketplace.

As notificações em si (novo ticket, novo seguimento, atribuição, resolução) activam-se individualmente em Configuração > Notificações > Notificações — cada uma lista os modelos, os destinatários e a opção de permitir resposta por email. A resposta por email a um ticket cria um seguimento no mesmo. Se não quiseres isso, define Permitir resposta como não na notificação.

Criar tickets a partir de uma caixa de email

O receptor de emails (mail receiver) transforma uma caixa IMAP em fila de tickets: cada email recebido vira ticket. Configura-se em Configuração > Receptores, com uma caixa dedicada (ex. [email protected]) e acesso IMAP. Duas regras do comportamento documentado: emails enviados pelo próprio endereço do receptor são recusados para evitar ciclos, e as regras de atribuição definem a entidade de destino (em Administração > Motoristas > Atribuição de tickets via receptor de emails). Emails recusados ficam visíveis em Configuração > Receptores > Emails não importados, com o motivo — o primeiro sítio a consultar quando um email não gera ticket.

6. Perfis e entidades

Um perfil é um conjunto de direitos. Os perfis assentam num de dois tipos de interface: simplificada (o portal de utilizador final, orientado a criar e seguir tickets) e padrão (a interface completa de quem administra). Criam-se em Administração > Perfis > Adicionar, escolhendo o tipo de interface logo no primeiro campo. Na prática de uma PME:

O direito de ver tickets do grupo (para um gestor acompanhar os tickets da equipa de técnicos, por exemplo) concede-se num perfil criado para o efeito, associado depois ao grupo em Administração > Grupos. Contas com interface simplificada não contam como licenças pagas nas ofertas cloud — numa instalação própria o conceito não se aplica, mas a regra mostra que o portal de utilizadores finais pode ser aberto sem custo.

Uma entidade partilha a vista e o âmbito de acção. É o mecanismo para isolar empresas clientes (num cenário MSP), filiais ou departamentos com orçamentos distintos: cada entidade passa a ter tickets, equipamentos, calendários e regras próprios. A raiz não se remove, apenas se renomeia, e as entidades criam-se em Administração > Entidades. Há um detalhe que apanha quem as usa pela primeira vez: os objectos (fornecedores, contratos, contactos) têm âmbito Local (visíveis só na entidade) ou Global (visíveis também nas sub-entidades), e uma entidade nova só aparece na lista de navegação depois de terminar e voltar a iniciar sessão — se continuar invisível, php bin/console cache:clear resolve.

A documentação oficial aconselha contenção: cada entidade adicional complexifica as regras e penaliza o desempenho. Para atribuir tickets a um departamento ou equipa, um grupo chega. A entidade só se justifica quando há mesmo partições de visão ou delegação de administração, e as localizações (pisos, edifícios, moradas) são o campo certo para posição geográfica, não a entidade.

7. Manutenção e backups

Rotina de backups

Um backup completo do GLPI são três coisas, não uma:

# 1. Base de dados
mysqldump -u root -p --single-transaction glpi > /backup/glpi-db-$(date +%F).sql
# 2. Pasta de ficheiros variáveis (documentos anexados, sessões, plugins)
tar -czf /backup/glpi-files-$(date +%F).tgz /var/lib/glpi
# 3. Pasta de configuração (inclui as chaves glpi.key / glpicrypt.key)
tar -czf /backup/glpi-config-$(date +%F).tgz /etc/glpi

A documentação oficial de actualização sublinha um pormenor que muitos backups ignoram: a pasta de configuração guarda as chaves de encriptação (glpi.key, glpicrypt.key, oauth.pem, oauth.pub) — sem elas, as credenciais guardadas (SMTP, LDAP) deixam de ser desencriptáveis depois de uma reposição. Em Docker, o backup resume-se ao volume db_data e ao volume glpi_data. A regra do 3-2-1 aplica-se na mesma: cópias em dois suportes, uma fora do servidor.

Actualizações

O GLPI avisa da existência de novas versões em Configuração > Geral > Sistema (botão de verificar nova versão) ou no campo “Acerca de” do menu do utilizador. O procedimento oficial de actualização, em resumo:

1. Backup completo (base de dados + código + pastas de ficheiros e configuração).
2. Não copies a nova versão por cima da antiga — remove ou move o directório actual antes de extrair o novo tarball. Copiar por cima causa erros de aplicação.
3. Extrai o novo glpi-<versão>.tgz no mesmo caminho e repõe as pastas de configuração, ficheiros e plugins, mais o inc/downstream.php se existir.
4. Abre o endereço no browser e o assistente de actualização corre (ou via consola: php bin/console db:update).

A partir do GLPI 11, a execução dos plugins é suspensa assim que uma nova versão de ficheiros é detectada e, numa actualização maior (10 → 11, por exemplo), é preciso retomá-la manualmente com php bin/console plugin:resume_execution ou na página de administração de plugins. O mesmo procedimento oficial nota que o GLPI 11 migra directamente de qualquer versão desde a 0.85 — não é preciso passar pela 10.

O GLPI inclui também uma verificação de coerência da base de dados antes da actualização: php bin/console db:check lista desvios ao esquema esperado causados por actualizações antigas parcialmente falhadas.

Saúde da base de dados

Duas tarefas agendadas mantêm o parque saudável a longo prazo: glpi:assets:cleansoftware (remove versões de software sem instalações associadas) e glpi:assets:purgesoftware (purga software eliminado). Depois de um pico de erros ou de uma actualização, php bin/console cache:clear limpa a cache. O Marketplace (Configuração > Plugins) instala e actualiza os plugins com dois cliques — mantém o GLPI Inventory actualizado junto com o core, porque as versões do agente e do plugin evoluem em paralelo.

Erros Comuns

Checklist

• Requisitos confirmados: PHP 8.2+, MariaDB 10.6+ (ou MySQL 8.0+), extensões obrigatórias instaladas.
• Fusos horários carregados na base de dados (mysql_tzinfo_to_sql) e o utilizador glpi com SELECT em mysql.time_zone_name.
• DocumentRoot a apontar para glpi/public com regras de reescrita (sem aviso de segurança no ecrã inicial).
• Contas de fábrica (glpi, tech, normal, post-only) removidas ou com novas palavras-passe, depois de criar um super-admin próprio.
• URL da aplicação definido em Configuração > Geral (com HTTPS se exposto na rede).
• Cron do GLPI no crontab (front/cron.php a cada minuto) e acções automáticas relevantes em modo CLI.
• glpi-agent instalado nos postos principais, com SERVER a apontar a front/inventory.php e TAG por localização.
• Primeira máquina visível em Parque de Informática > Computadores.
• Calendário de trabalho e SLA (TTO/TTR) criados e atribuídos por motorista ou modelo de ticket.
• Notificações por email activadas com método SMTP/OAUTH e teste de envio bem sucedido.
• Backup agendado com base de dados + /var/lib/glpi + /etc/glpi (chaves incluídas).
• Marketplace acessível e plugin GLPI Inventory instalado se precisares de inventário de rede ou SNMP.

Artigos Relacionados

• Registar e Documentar Tickets: Por Que o Registo Correcto Resolve Mais Rápido
• Wazuh SIEM: Detecção de Ameaças e Compliance NIS2 para PME
• Dia 20: Monitorização de Rede — SNMP, Cacti, Zabbix e PRTG
• Monit: Monitorização e Reparação Automática de Serviços Linux
• OpenVAS/Greenbone: Scan de Vulnerabilidades Self-Hosted

Fontes Oficiais

• GLPI Project — site oficial e descarregamentos — versões estáveis (a 11.0.9 é a mais recente) e novidades do projecto.
• Pré-requisitos oficiais de instalação — matriz exacta de versões PHP/MariaDB/MySQL e extensões obrigatórias.
• Instalador web (wizard) — passos do primeiro arranque e contas criadas por omissão.
• Procedimento de actualização — backups, substituição do directório e db:update/db:check.
• Tutorial oficial: instalar o GLPI no Ubuntu — stack LAMP completa com FHS e permissões.
• Tutorial oficial: GLPI em Docker — stack docker-compose oficial com MySQL.
• Documentação do glpi-agent — instalação, parâmetros (SERVER, TAG) e configuração.
• FAQ oficial: SLAs / Service levels — TTO, TTR, OLAs e escalonamentos.
• FAQ oficial: Tickets — tipos, seguimentos, categorias e fecho automático.
• FAQ oficial: Notificações e receptores — SMTP, OAuth, mail receivers e emails não importados.