Instalando o GLPI

Introdução

Instalar o GLPI é fácil. Fazer com que ele realmente ajude a sua equipe no dia a dia é outra conversa, e ela começa por entender o que a ferramenta resolve.

O GLPI é uma solução de código aberto para gestão de serviços de TI (ITSM) e de ativos (ITAM). Em uma única aplicação web, você tem:

• Chamados: incidentes e requisições com responsável, histórico e prazo.

• Inventário: computadores, servidores, equipamentos de rede, software e licenças, com coleta automática pelo GLPI Agent.

• CMDB: a relação entre os ativos, para saber o que é afetado quando algo para.

• Relatórios e painéis: volume de chamados, prazos cumpridos e situação do parque.

• Base de conhecimento: soluções documentadas que a equipe reutiliza.

Aqui partimos do cenário mais simples e também o mais comum: não existe ferramenta de chamados, nem inventário, nem CMDB. Neste post você vai ver por que um sistema de chamados faz diferença e como instalar o GLPI de duas formas: direto no servidor (Debian 13 ou Rocky Linux 9) ou em container com Docker Compose.

Por que um sistema de chamados é essencial

Se você trabalha com infraestrutura de TI, sabe que um sistema de chamados é essencial para o seu trabalho. É dele que saem os seus KPIs e os números de desempenho da equipe, e são esses números que justificam para a diretoria a necessidade de pessoal de TI: quantas solicitações de usuários vocês atendem por dia, quais erros se repetem, quais departamentos mais pedem suporte, quando é hora de comprar equipamentos e muito mais.

Do helpdesk ao engenheiro de infraestrutura, todos precisam de chamados:

• Solicitações e pequenas ações: registrar o pedido do usuário e o que foi feito para atendê-lo.

• Gestão de mudanças: documentar qualquer alteração na infraestrutura e organizar as janelas de manutenção.

• Fornecedores: acompanhar contratos, garantias e o relacionamento com quem fornece os equipamentos e serviços que a TI usa e administra.

Sem um sistema que acompanhe tudo isso, manter esse controle é quase impossível e consome um tempo que a equipe não tem. E quando chega a auditoria, ou quando é preciso reportar um incidente, a diferença fica clara: em vez de vasculhar e-mails, você gera um relatório com quem pediu, quem aprovou, quem executou e quando. No Brasil, normas como a LGPD, que exige o registro dos incidentes de segurança envolvendo dados pessoais, e, para instituições financeiras, a Resolução CMN, que pede o registro de incidentes e trilhas de auditoria, tornam esse histórico ainda mais importante.

Existem ferramentas comerciais conhecidas para isso, como o Jira Service Management e o ServiceNow. Mas e quando você não tem acesso a nenhuma delas? A equipe pode ser pequena demais para justificar a licença, ou a empresa pode simplesmente não querer investir nisso agora. É nesse cenário que uma ferramenta de código aberto como o GLPI torna o projeto viável.

Instalar é simples, implantar é outra história

A instalação do GLPI é a parte rápida. Você tem dois caminhos, e os dois levam ao mesmo resultado:

• Servidor Linux: o GLPI roda direto no sistema operacional, com servidor web, PHP e banco de dados instalados por você. Vale tanto para uma VM quanto para uma máquina física, porque o processo é o mesmo.

• Container: o GLPI e o banco de dados sobem com Docker Compose. É o caminho mais rápido para quem já tem um host Docker, e facilita atualizar ou recriar o ambiente.

Implantar já é outra história. Cada empresa tem a sua estrutura, os seus processos, as ferramentas que já usa e as exigências de auditoria que precisa cumprir. Como dividir as áreas, quem pode ver e fazer o quê, quais categorias de chamado fazem sentido, quais prazos a equipe consegue cumprir: são decisões que nenhum guia toma por você. É nessa etapa que o GLPI deixa de ser uma ferramenta instalada e passa a refletir a forma como a sua TI trabalha.

Neste post, o objetivo é deixar a base pronta: o GLPI instalado, acessível e seguro para você começar a explorar.

Requisitos

Este post cobre a instalação do GLPI 12 em três caminhos: Debian 13, Rocky Linux 9 e container com Docker Compose. Os passos de configuração inicial no navegador são os mesmos para todos e aparecem uma única vez, no fim do post.

Neste laboratório, simulamos uma instalação em bare metal usando contêineres LXC no Proxmox. Você pode usar o hypervisor de sua preferência (Hyper-V, Proxmox, VMware) ou instalar o sistema operacional diretamente em uma máquina física: o processo de instalação do GLPI é o mesmo. A criação da VM não faz parte deste post.

Para um laboratório, uma VM pequena é suficiente:

• CPU e memória: 2 vCPU e 4 GB de RAM.

• Disco: 40 GB.

• Sistema: instalação mínima do Debian 13 ou do Rocky Linux 9, com acesso SSH como root ou sudo.

• Rede: uma placa de rede com IP fixo.

O GLPI 12 exige PHP 8.3 ou mais recente e MariaDB 10.11 (ou MySQL 8.0) ou mais recente. O Debian 13 já traz essas versões nos repositórios padrão; no Rocky Linux 9 vamos habilitar versões mais novas pelos módulos do AppStream.

Rocky Linux 10 ou Oracle Linux 10? Essas versões exigem uma CPU compatível com x86-64-v3 (AVX2). Em hardware mais antigo, use a versão 9, como neste post. O Oracle Linux 9 deve se comportar como o Rocky Linux 9, mas não foi testado neste laboratório.

Os exemplos usam estes nomes:

• GLPI01: Debian 13, 192.168.30.10

• GLPI02: Rocky Linux 9, 192.168.30.11

• DKR01: Rocky Linux 9 com Docker, 192.168.30.20

• Endereço do GLPI: glpi.itsm.lab

• Banco de dados: glpi_db, usuário glpi

Instalação no Debian 13 e no Rocky Linux 9

Os dois sistemas seguem a mesma sequência. Quando algo muda, aparecem os blocos Debian e Rocky Linux, ou um comentário # Rocky Linux: na linha que muda; sem indicação, o passo é igual nos dois. Todos os comandos rodam como root, e cada passo termina com uma verificação: se o resultado for diferente do esperado, pare e corrija antes de seguir.

Criando arquivos: cada arquivo aparece como um comando cat > caminho <<'EOF', que cria o arquivo de uma vez pelo terminal. Se preferir um editor (nano, vim ou outro), abra o caminho indicado e cole apenas o que está entre a linha do cat e a linha EOF.

1. Instalar os pacotes

Usamos o PHP-FPM nos dois sistemas. O Rocky Linux 9 traz por padrão o PHP 8.0 e o MariaDB 10.5, abaixo do mínimo do GLPI 12, então habilitamos versões mais novas pelos módulos do próprio AppStream, sem repositórios de terceiros.

Debian:

apt update && apt full-upgrade -y

apt install -y curl wget tar bzip2 ca-certificates apache2 mariadb-server \

  php-fpm php-mysql php-curl php-gd php-intl php-xml php-mbstring \

  php-bcmath php-zip php-bz2 php-ldap php-opcache

Rocky Linux: a instalação mínima não traz wget e tar, e o php-cli (que fornece o comando php) não vem junto com o php-fpm.

dnf -y update

dnf -y install curl wget tar bzip2

dnf -y module enable php:8.3 mariadb:11.8

dnf -y install httpd mariadb-server \

  php-cli php-fpm php-mysqlnd php-gd php-intl php-xml php-mbstring \

  php-bcmath php-ldap php-opcache php-pecl-zip

systemctl enable --now httpd mariadb php-fpm

Verificação (rode as linhas do seu sistema). O esperado:

• PHP 8.4 no Debian ou 8.3 no Rocky Linux, e MariaDB 11.8

• no Rocky Linux, php 8.3 [e] e mariadb 11.8 [e] na lista de módulos

• todos os serviços como active

• apenas fim do teste; no Rocky Linux, também FALTANDO: sodium, que é normal: a extensão só existe no EPEL, e o GLPI usa uma implementação própria

php -v | head -1; mariadb --version

dnf module list --enabled php mariadb | grep -E '^(php|mariadb)'   # só Rocky Linux

systemctl is-active apache2 mariadb php8.4-fpm   # Debian

systemctl is-active httpd mariadb php-fpm        # Rocky Linux

for e in dom fileinfo filter libxml simplexml tokenizer xmlreader xmlwriter curl gd intl mysqli session zlib bcmath mbstring openssl sodium; do

  php -m | grep -qix "$e" || echo "FALTANDO: $e"

done; echo "fim do teste"

2. Preparar o MariaDB

Debian: o MariaDB já vem seguro (o root só entra pelo socket local, sem usuários anônimos) e escuta apenas em 127.0.0.1. Não há nada a alterar.

Rocky Linux: rode o assistente de segurança (Enter na senha atual, n para unix_socket, n para trocar a senha do root e Y para as demais) e limite o banco às conexões locais, já que o GLPI roda no mesmo servidor.

Para desfazer o limite, apague /etc/my.cnf.d/99-glpi.cnf e rode systemctl restart mariadb.

mariadb-secure-installation

cat > /etc/my.cnf.d/99-glpi.cnf <<'EOF'

# Rocky/Oracle Linux: /etc/my.cnf.d/99-glpi.cnf

[mysqld]

bind-address = 127.0.0.1

EOF

systemctl restart mariadb

Nos dois sistemas, carregue as tabelas de fuso horário, que o GLPI usa para mostrar as datas no fuso de cada usuário:

mariadb-tzinfo-to-sql /usr/share/zoneinfo | mariadb mysql

Verificação. O esperado: apenas mariadb.sys, mysql e root, todos em localhost; uma única linha com 127.0.0.1:3306; e 2026-01-01 21:00:00 (se vier NULL, as tabelas não foram carregadas).

mariadb -e "SELECT user, host FROM mysql.user;"

ss -tlnp | grep 3306

mariadb -e "SELECT CONVERT_TZ('2026-01-01 12:00:00','UTC','Asia/Tokyo');"

As tabelas de fuso são uma cópia do tzdata do sistema; depois de uma atualização grande desse pacote, rode o carregamento de novo.

3. Criar o banco e o usuário do GLPI

O bloco pede a senha do usuário glpi duas vezes, sem mostrá-la na tela e sem gravá-la no histórico. Não use aspas simples na senha.

read -rsp "Senha do usuário glpi: " P1; echo

read -rsp "Confirme a senha: " P2; echo

[ "$P1" = "$P2" ] && [ -n "$P1" ] && mariadb <<SQL

CREATE DATABASE glpi_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER 'glpi'@'localhost' IDENTIFIED BY '${P1}';

GRANT ALL PRIVILEGES ON glpi_db.* TO 'glpi'@'localhost';

GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'localhost';

FLUSH PRIVILEGES;

SQL

[ "$P1" = "$P2" ] || echo "As senhas não conferem, nada foi criado."

unset P1 P2

Verificação. O esperado é ver glpi_db e as permissões em glpi_db.* e mysql.time_zone_name:

mariadb -u glpi -p -e "SHOW DATABASES; SHOW GRANTS;" | grep -v 'IDENTIFIED BY'

Este usuário é do banco de dados. Ele não serve para entrar na interface web, que tem contas próprias criadas pelo assistente de instalação.

4. Baixar o GLPI e separar as pastas

Seguindo a recomendação oficial, o código fica em /var/www/glpi, a configuração em /etc/glpi, os dados em /var/lib/glpi e os logs em /var/log/glpi. Assim, atualizações e backups ficam mais simples, e o servidor web não precisa de permissão de escrita no código. Confira a versão mais recente:

curl -s https://api.github.com/repos/glpi-project/glpi/releases/latest | grep '"tag_name"'

Ajuste GLPI_VER para a versão retornada, baixe, extraia e separe as pastas:

GLPI_VER=12.0.1

cd /tmp

wget https://github.com/glpi-project/glpi/releases/download/${GLPI_VER}/glpi-${GLPI_VER}.tgz

gzip -t glpi-${GLPI_VER}.tgz && tar -xzf glpi-${GLPI_VER}.tgz -C /var/www/

mkdir -p /etc/glpi /var/lib/glpi /var/log/glpi

mv /var/www/glpi/config/* /etc/glpi/ 2>/dev/null

mv /var/www/glpi/files/* /var/lib/glpi/

O downstream.php informa ao GLPI onde está a configuração:

cat > /var/www/glpi/inc/downstream.php <<'EOF'

<?php

// Debian e Rocky/Oracle Linux: /var/www/glpi/inc/downstream.php

define('GLPI_CONFIG_DIR', '/etc/glpi/');

if (file_exists(GLPI_CONFIG_DIR . '/local_define.php')) {

    require_once GLPI_CONFIG_DIR . '/local_define.php';

}

EOF

O local_define.php define as pastas de dados e de logs:

cat > /etc/glpi/local_define.php <<'EOF'

<?php

// Debian e Rocky/Oracle Linux: /etc/glpi/local_define.php

define('GLPI_VAR_DIR', '/var/lib/glpi');

define('GLPI_LOG_DIR', '/var/log/glpi');

EOF

O código continua pertencendo ao root; apenas configuração, dados, logs e marketplace pertencem ao usuário do servidor web (www-data no Debian, apache no Rocky Linux):

USR=www-data   # Rocky Linux: USR=apache

chown -R root:root /var/www/glpi

chown -R $USR:$USR /etc/glpi /var/lib/glpi /var/log/glpi /var/www/glpi/marketplace

find /etc/glpi /var/lib/glpi /var/log/glpi -type d -exec chmod 750 {} \;

Verificação, no mesmo terminal. O esperado é No syntax errors detected duas vezes e quatro linhas OK escrita:

php -l /var/www/glpi/inc/downstream.php; php -l /etc/glpi/local_define.php

for d in /etc/glpi /var/lib/glpi /var/log/glpi /var/www/glpi/marketplace; do

  su -s /bin/sh $USR -c "test -w $d" && echo "OK escrita: $d" || echo "FALHA: $d"

done

5. Ajustar o SELinux (Rocky Linux)

No Rocky Linux, o SELinux fica em modo enforcing e controla o que cada serviço pode acessar, além das permissões comuns do Linux. Por isso o teste acima passa, mas o GLPI ainda não consegue gravar: as pastas recebem rótulos como etc_t, var_lib_t e var_log_t, que o servidor web não pode alterar. No laboratório, o assistente acusou "Não foi possível criar o arquivo de log" até este ajuste.

A solução é rotular as pastas do GLPI com httpd_sys_rw_content_t (leitura e escrita pelo servidor web). O código em /var/www/glpi continua httpd_sys_content_t, somente leitura. Nunca desative o SELinux para contornar o problema.

As regras são permanentes. Para desfazer uma delas, use semanage fcontext -d "<caminho>" e depois restorecon -Rv <pasta>.

semanage fcontext -a -t httpd_sys_rw_content_t "/etc/glpi(/.*)?"

semanage fcontext -a -t httpd_sys_rw_content_t "/var/lib/glpi(/.*)?"

semanage fcontext -a -t httpd_sys_rw_content_t "/var/log/glpi(/.*)?"

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/glpi/marketplace(/.*)?"

restorecon -Rv /etc/glpi /var/lib/glpi /var/log/glpi /var/www/glpi/marketplace

Verificação. O esperado é Enforcing e httpd_sys_rw_content_t nas quatro pastas. Se algo ainda for bloqueado, o ausearch mostra as negações recentes:

getenforce

ls -dZ /etc/glpi /var/lib/glpi /var/log/glpi /var/www/glpi/marketplace

ausearch -m avc -ts recent | grep denied

Por que não httpd_log_t nos logs? Esse tipo é feito para os logs do Apache e só permite acrescentar linhas. O GLPI abre os próprios arquivos de log para escrita, e no laboratório cada arquivo de /var/log/glpi foi bloqueado até a troca.

O assistente do GLPI também sugere três booleanos do SELinux. Nenhum é obrigatório; ligue só os que for usar, com setsebool -P <booleano> on (para desligar, off):

• httpd_can_network_connect_db: só com o banco em outro servidor; com o banco local, a conexão usa o socket.

• httpd_can_network_connect: para o GLPI acessar a rede (marketplace, SMTP externo, webhooks).

• httpd_can_sendmail: para enviar e-mails pelo sendmail ou postfix local.

No laboratório, o Rocky Linux também foi testado em um contêiner LXC, que não suporta SELinux; ali o assistente mostra "Modo SELinux é Disabled". Em uma VM ou servidor físico, mantenha o modo enforcing e faça os ajustes desta etapa.

6. Configurar o Apache e o PHP-FPM

Debian: habilite os módulos e a integração com o PHP-FPM, e desative o site padrão. No Rocky Linux, os módulos rewrite e proxy_fcgi já vêm habilitados, e o /etc/httpd/conf.d/php.conf já envia o PHP ao PHP-FPM.

Para voltar ao site padrão no Debian, use a2ensite 000-default e systemctl reload apache2.

a2enmod rewrite proxy_fcgi setenvif

a2enconf php8.4-fpm

a2dissite 000-default

O virtual host segue o exemplo oficial: a raiz do site aponta para public/, todas as requisições passam pelo index.php e o cabeçalho de autorização chega ao PHP (necessário para a API). Muda apenas o caminho do arquivo e dos logs.

Debian:

cat > /etc/apache2/sites-available/glpi.conf <<'EOF'

# Debian: /etc/apache2/sites-available/glpi.conf

<VirtualHost *:80>

    ServerName glpi.itsm.lab

    DocumentRoot /var/www/glpi/public

    <Directory /var/www/glpi/public>

        Require all granted

        RewriteEngine On

        RewriteCond %{HTTP:Authorization} ^(.+)$

        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

        RewriteCond %{REQUEST_FILENAME} !-f

        RewriteRule ^(.*)$ index.php [QSA,L]

    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/glpi_error.log

    CustomLog ${APACHE_LOG_DIR}/glpi_access.log combined

</VirtualHost>

EOF

a2ensite glpi

Rocky Linux:

cat > /etc/httpd/conf.d/glpi.conf <<'EOF'

# Rocky/Oracle Linux: /etc/httpd/conf.d/glpi.conf

<VirtualHost *:80>

    ServerName glpi.itsm.lab

    DocumentRoot /var/www/glpi/public

    <Directory /var/www/glpi/public>

        Require all granted

        RewriteEngine On

        RewriteCond %{HTTP:Authorization} ^(.+)$

        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

        RewriteCond %{REQUEST_FILENAME} !-f

        RewriteRule ^(.*)$ index.php [QSA,L]

    </Directory>

    ErrorLog logs/glpi_error.log

    CustomLog logs/glpi_access.log combined

</VirtualHost>

EOF

As configurações de sessão são as recomendadas pela documentação. O session.cookie_secure fica desligado enquanto o acesso for por HTTP; ative-o quando publicar o GLPI com HTTPS.

INI=/etc/php/8.4/fpm/conf.d/99-glpi.ini   # Rocky Linux: INI=/etc/php.d/99-glpi.ini

cat > $INI <<'EOF'

; Debian: /etc/php/8.4/fpm/conf.d/99-glpi.ini | Rocky/Oracle Linux: /etc/php.d/99-glpi.ini

session.cookie_httponly = on

session.cookie_samesite = Lax

EOF

Por último, esconda a versão do Apache nos cabeçalhos e reinicie os serviços. No Debian, o arquivo security.conf já existe e só duas linhas mudam:

sed -i 's/^ServerTokens .*/ServerTokens Prod/; s/^ServerSignature .*/ServerSignature Off/' /etc/apache2/conf-available/security.conf

apache2ctl configtest && systemctl restart php8.4-fpm apache2

No Rocky Linux, o arquivo não existe; crie um novo:

cat > /etc/httpd/conf.d/00-security.conf <<'EOF'

# Rocky/Oracle Linux: /etc/httpd/conf.d/00-security.conf

ServerTokens Prod

ServerSignature Off

EOF

httpd -t && systemctl restart php-fpm httpd

Verificação. O esperado é HTTP/1.1 200 OK e Server: Apache, sem número de versão:

curl -sI -H "Host: glpi.itsm.lab" http://127.0.0.1/ | grep -iE '^HTTP|^server'

7. Liberar o HTTP no firewall (Rocky Linux)

No Rocky Linux, o firewalld vem ativo e bloqueia a porta 80; no Debian, não há firewall ativo por padrão. O esperado é ver http na lista.

Isso libera o HTTP pela rede. Para desfazer: firewall-cmd --permanent --remove-service=http && firewall-cmd --reload.

firewall-cmd --permanent --add-service=http

firewall-cmd --reload

firewall-cmd --list-services

8. Agendar as ações automáticas

As tarefas automáticas do GLPI (notificações, limpezas, coleta de e-mails) devem rodar pelo cron do sistema, a cada minuto, com o usuário do servidor web:

USR=www-data   # Rocky Linux: USR=apache

cat > /etc/cron.d/glpi <<EOF

# Debian e Rocky/Oracle Linux: /etc/cron.d/glpi

* * * * * $USR /usr/bin/php /var/www/glpi/front/cron.php

EOF

chmod 644 /etc/cron.d/glpi

Verificação, depois de dois minutos. O esperado são execuções marcadas como Externo, que é como o GLPI identifica as tarefas disparadas pelo cron. O horário do log pode aparecer em UTC, o que não indica problema.

tail -5 /var/log/glpi/cron.log

9. Acessar pelo navegador

Se ainda não houver um DNS interno com o nome glpi.itsm.lab, adicione uma linha com o IP do seu servidor no arquivo hosts do seu computador (no Windows, C:\Windows\System32\drivers\etc\hosts, editado como administrador):

192.168.30.10  glpi.itsm.lab

Abra http://glpi.itsm.lab. A tela de configuração do GLPI deve aparecer; siga para a seção Primeiro acesso e configuração inicial.

O install/install.php não precisa ser apagado: depois da instalação, o GLPI 12 bloqueia o acesso ao instalador, e a pasta install/ é usada nas atualizações.

Instalação em container

O GLPI e o banco de dados rodam em dois containers, definidos em um arquivo do Docker Compose. Os comandos rodam como root no DKR01, um Rocky Linux 9 com SELinux em modo enforcing e firewalld ativo, como em um servidor real. Se você já tem um host Docker, pule para o passo 3.

1. Instalar o Docker

Usamos o repositório oficial do Docker. A série Docker no Oracle Linux 9 explica cada etapa em detalhe; o Rocky Linux 9 segue o mesmo processo.

dnf -y install dnf-plugins-core

dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

dnf -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

systemctl enable --now docker

Verificação. O esperado é ver as versões do cliente, do servidor e do Compose, e a mensagem Hello from Docker!:

docker version --format 'Client {{.Client.Version}} | Server {{.Server.Version}}'

docker compose version

docker run --rm hello-world

2. Ativar o SELinux no Docker

Mesmo com o sistema em modo enforcing, o Docker CE vem com o suporte a SELinux desligado no daemon, e os containers rodam sem confinamento. Se o comando abaixo não mostrar name=selinux, o ajuste é necessário:

docker info --format '{{.SecurityOptions}}'

O Docker será reiniciado e os containers em execução vão parar. Para desfazer, remova a linha "selinux-enabled": true do arquivo e reinicie o Docker.

O bloco cria o /etc/docker/daemon.json. Se o arquivo já existir, não use o bloco: acrescente apenas a opção "selinux-enabled": true, sem apagar o que já está lá.

cat > /etc/docker/daemon.json <<'EOF'

{

  "selinux-enabled": true

}

EOF

systemctl restart docker

Verificação. O esperado é name=selinux na lista e um contexto com container_t, que indica que o container está confinado:

docker info --format '{{.SecurityOptions}}'

docker run --rm alpine cat /proc/self/attr/current; echo

3. Criar o projeto

Os arquivos ficam em /opt/glpi. O .env guarda a versão e as senhas, e só o root pode lê-lo. O bloco gera as duas senhas de forma aleatória, sem mostrá-las na tela; se preferir defini-las você mesmo, troque cada $(openssl ...) por uma senha forte.

mkdir -p /opt/glpi && cd /opt/glpi

cat > /opt/glpi/.env <<EOF

GLPI_VERSION=12.0.1

GLPI_DB_HOST=db

GLPI_DB_PORT=3306

GLPI_DB_NAME=glpi_db

GLPI_DB_USER=glpi

GLPI_DB_PASSWORD=$(openssl rand -base64 24 | tr -d '/+=')

GLPI_DB_ROOT_PASSWORD=$(openssl rand -base64 24 | tr -d '/+=')

EOF

chmod 600 /opt/glpi/.env

Guarde a senha de root do banco (GLPI_DB_ROOT_PASSWORD) no seu cofre de senhas. Ela é necessária para tarefas de manutenção, como a liberação dos fusos horários logo abaixo.

O docker-compose.yml segue o exemplo oficial do GLPI, com três ajustes: o banco é o MariaDB 11.8, a mesma versão dos outros caminhos; a versão do GLPI fica fixa no .env, para que atualizações só aconteçam quando você decidir; e o GLPI espera o banco ficar pronto antes de iniciar.

cat > /opt/glpi/docker-compose.yml <<'EOF'

# /opt/glpi/docker-compose.yml

name: glpi

services:

  db:

    image: mariadb:11.8

    restart: unless-stopped

    environment:

      MARIADB_ROOT_PASSWORD: ${GLPI_DB_ROOT_PASSWORD}

      MARIADB_DATABASE: ${GLPI_DB_NAME}

      MARIADB_USER: ${GLPI_DB_USER}

      MARIADB_PASSWORD: ${GLPI_DB_PASSWORD}

    volumes:

      - db_data:/var/lib/mysql

    healthcheck:

      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]

      interval: 10s

      timeout: 5s

      retries: 10

  glpi:

    image: glpi/glpi:${GLPI_VERSION}

    restart: unless-stopped

    env_file: .env

    volumes:

      - glpi_data:/var/glpi

    ports:

      - "80:80"

    depends_on:

      db:

        condition: service_healthy

volumes:

  glpi_data:

  db_data:

EOF

docker compose config --quiet && echo "compose OK"

O esperado é compose OK.

Os volumes são volumes nomeados do Docker, que recebem o rótulo do SELinux automaticamente. Se trocar por pastas do host (bind mounts), acrescente :Z no fim de cada linha de volume, por exemplo ./dados:/var/glpi:Z; sem isso, o SELinux bloqueia o acesso do container.

4. Subir o GLPI

A imagem oficial instala o GLPI sozinha na primeira inicialização, usando os dados do .env:

cd /opt/glpi && docker compose up -d

Depois de um minuto, libere a tabela de fusos horários para o usuário do GLPI e ative o uso de fusos. A senha de root passa pela variável MYSQL_PWD, sem aparecer na tela:

docker compose exec db sh -c 'MYSQL_PWD="$MARIADB_ROOT_PASSWORD" mariadb -uroot -e "GRANT SELECT ON mysql.time_zone_name TO \"$MARIADB_USER\"@\"%\"; FLUSH PRIVILEGES;"'

docker compose exec -u www-data glpi php /var/www/glpi/bin/console database:enable_timezones

Verificação. O esperado: db como Up (healthy) e glpi como Up; a mensagem GLPI installation completed successfully!; e, do comando anterior, Timezone usage has been enabled.

docker compose ps

docker compose logs glpi | grep -i "installation completed"

A imagem já tem um agendador interno que roda o front/cron.php a cada minuto; neste caminho, não crie o arquivo em /etc/cron.d. Os logs do container usam o horário UTC, o que não afeta o fuso configurado no GLPI.

5. Firewall: atenção às portas publicadas

Ao publicar uma porta ("80:80"), o Docker cria as próprias regras de firewall e libera o acesso, mesmo que a zona public do firewalld não tenha o serviço http. No laboratório, o GLPI ficou acessível pela rede sem nenhuma regra no firewalld. Não conte com o firewalld do host para proteger as portas dos containers: se o acesso precisar ficar restrito a uma rede ou a determinados endereços, faça esse controle no firewall da rede, antes do host Docker.

6. Acessar pelo navegador

Abra http://192.168.30.20 (ou o nome registrado no DNS ou no arquivo hosts). Neste caminho não há assistente de instalação: a tela de login aparece direto. Entre com glpi / glpi e siga para a seção Primeiro acesso e configuração inicial, a partir da etapa de login.

Primeiro acesso e configuração inicial

Esta parte é igual para os três caminhos. Quem instalou em container pode pular o assistente: a imagem oficial já instalou o GLPI, e o primeiro passo é o login.

Assistente de instalação

Abra http://glpi.itsm.lab. Como o banco ainda está vazio, o GLPI mostra a tela de configuração. Clique em Go to install page.

Siga as telas iniciais: escolha o idioma (ele vira o padrão do GLPI, e cada usuário pode trocar o seu depois), aceite a licença GPL e clique em Instalar. A opção Atualizar só serve para um banco de dados de uma versão anterior do GLPI. 

Clique em Instalar. A opção Atualizar só serve para um banco de dados de uma versão anterior do GLPI. 

Na Etapa 0, o GLPI confere o ambiente. Todos os itens Obrigatório precisam estar com ✔; se algum estiver em vermelho, volte à etapa correspondente da instalação. Os avisos em amarelo são Sugerido e não impedem a instalação. No Rocky Linux, aparecem dois avisos esperados: os booleanos do SELinux, explicados na etapa de SELinux, e a extensão sodium, que o GLPI emula. Clique em Continuar. 

Na Etapa 1, informe a conexão com o banco:

• Endereço do servidor SQL: localhost

• Usuário SQL: glpi

• Senha SQL: a senha criada na etapa do banco de dados

Clique em Continuar.

Na Etapa 2, o GLPI confirma a conexão. Em ou usar um existente, selecione glpi_db e clique em Continuar. Não crie um banco novo aqui: o glpi_db já foi criado com as permissões corretas. 

Na Etapa 3, o GLPI cria as tabelas e os dados iniciais. Isso leva cerca de um minuto. Quando a barra chegar a 100% e todos os itens estiverem marcados, clique em Continuar. 

Na Etapa 4, o GLPI pergunta se pode enviar estatísticas de uso, de forma anônima. É opcional; no laboratório, deixamos desmarcado. Clique em Continuar. 

A Etapa 5 apresenta o GLPI Network, o serviço comercial de suporte do fabricante. Clique em Continuar. 

A Etapa 6 confirma a instalação e mostra as contas criadas com senhas padrão: glpi, tech, normal e post-only. Anote-as: logo abaixo, vamos trocar a senha do administrador e desativar as demais. Clique em Usar o GLPI. 

Primeiro login

Entre com o usuário glpi e a senha glpi, mantendo a origem GLPI internal database. No caminho em container, é aqui que você começa.

O painel abre com um aviso em laranja: as contas padrão ainda usam as senhas de fábrica. Vamos resolver isso em seguida. Antes, repare na caixa Você está visualizando dados de demonstração: os números do painel são fictícios, só para mostrar como ele funciona. Seu banco não tem nenhum registro de exemplo. Clique em Desabilitar demonstração. 

Com a demonstração desligada, o painel passa a mostrar os dados reais, por enquanto zerados. 

Proteger as contas padrão

Vá em Administração → Usuários. O GLPI 12 pede a sua senha novamente antes de abrir áreas sensíveis da administração. Digite a senha atual e clique em Verificar.

A lista mostra as quatro contas padrão e a conta interna glpi-system, usada pelo próprio GLPI. Não altere a glpi-system. 

Comece pela conta do administrador. Abra o usuário glpi, role o formulário até a seção Senhas e chaves de acesso, clique em Alterar senha, digite uma senha forte nos dois campos e clique em Salvar. O esperado é a mensagem "Item atualizado com sucesso". 

As contas tech, normal e post-only só servem para demonstração. Abra o usuário post-only, altere o campo Ativo para Não e clique em Salvar. Repita o procedimento para tech e normal. 

A lista deve mostrar Não na coluna Ativo das três contas. Saia do GLPI e entre de novo com glpi e a nova senha: o aviso sobre senhas padrão não aparece mais. 

Ações automáticas em modo CLI

Ao instalar, parte das ações automáticas do GLPI vem no modo GLPI, que só roda quando alguém abre uma página. Sem essa troca, o GLPI funciona, mas em um servidor com pouco acesso a coleta de e-mails, as notificações e as limpezas podem atrasar por horas, e o GLPI mostra o aviso "As ações automáticas podem não estar rodando como esperado". No modo CLI, elas passam a rodar pelo cron configurado na instalação (no container, pelo agendador da própria imagem).

Vá em Configurar → Ações automáticas. A lista é paginada; primeiro, aumente linhas / página para que todas as ações apareçam na mesma página, e então marque a caixa do cabeçalho para selecionar todas.

Clique em Ações. Em Ação, escolha Atualizar; no campo, escolha Características - Modo de execução; selecione CLI e clique em Enviar. 

O esperado é a mensagem "Operação realizada com sucesso" e CLI em todas as linhas da coluna Modo de execução.

Para conferir pelo terminal nos caminhos Debian e Rocky Linux, o comando abaixo deve mostrar uma única linha, com mode igual a 2:

mariadb -e "SELECT mode, COUNT(*) AS tarefas FROM glpi_db.glpi_crontasks GROUP BY mode;"

Checklist

• O GLPI abre no navegador, e a tela de requisitos mostrou todos os itens Obrigatório com ✔

• O MariaDB escuta apenas em 127.0.0.1 (Debian e Rocky Linux)

• O código em /var/www/glpi pertence ao root; só configuração, dados, logs e marketplace pertencem ao usuário do servidor web

• (Rocky Linux) O SELinux está em modo enforcing, sem negações recentes no ausearch

• (Rocky Linux) O HTTP está liberado no firewalld; (container) o acesso à porta 80 é controlado no firewall da rede

• O cabeçalho Server não mostra a versão do Apache

• A senha da conta glpi foi trocada, e as contas tech, normal e post-only estão desativadas

• A demonstração do painel está desligada

• Todas as ações automáticas estão no modo CLI, e o cron.log mostra execuções Externo

• (Container) O arquivo .env tem permissão 600, e a senha de root do banco está guardada em um cofre de senhas

Para fechar

Agora você tem o GLPI 12 instalado e protegido, seja no Debian 13, no Rocky Linux 9 com SELinux em modo enforcing ou em container. As contas padrão estão desativadas, as tarefas automáticas rodam pelo cron, e a base está pronta para começar a registrar chamados e ativos.

O próximo passo é a parte que nenhum guia faz por você: implantar. Antes de criar o primeiro chamado, pense em como a sua TI trabalha: quem pede, quem atende, o que precisa ser medido e o que a auditoria vai perguntar. As respostas a essas perguntas é que vão definir entidades, perfis, categorias e prazos. Para produção, publique o GLPI com HTTPS e ative o session.cookie_secure.

Se você precisar de uma versão mais nova do PHP do que a do repositório padrão do Rocky Linux, existem repositórios alternativos, como o Remi. Eles trazem versões mais recentes, mas adicionam uma dependência externa às atualizações do servidor; avalie esse ponto antes de usar em produção.

Para saber mais

• Documentação de instalação do GLPI

• Pré-requisitos do GLPI

• Executando o GLPI no Docker

• Novidades do GLPI 12