NexTool Solutions

Instalar o GLPI 11 no Linux é tranquilo até a linha em que você tira config/ e files/ de dentro do webroot e o instalador "não acha" mais o banco. Este é o passo a passo que usamos ao provisionar GLPI para clientes: os comandos reais, os dois php.ini que de fato importam, o arquivo que evita o erro mais comum da instalação manual e o checklist de pós-instalação que fecha o ambiente.

Antes de começar: dimensione o servidor

O GLPI 11 roda sobre a stack clássica LAMP: Apache (ou Nginx) + PHP 8.1 ou superior + MariaDB 10.5+ (ou MySQL 8). No Debian 12 o PHP padrão é o 8.2; no Ubuntu 24.04 LTS, o 8.3 - ambos servem. O que muda de verdade entre um piloto e um ambiente de centenas de técnicos é RAM e o modelo de execução do PHP (mod_php x PHP-FPM). Esta é a matriz que usamos para dimensionar:

1. Sistema, servidor web, PHP e extensões

Atualize o sistema e instale tudo de uma vez. As extensões não são opcionais: o GLPI valida cada uma na tela de requisitos.

apt update && apt upgrade -y
apt install -y apache2 mariadb-server \
  php php-{mysql,curl,gd,intl,xml,mbstring,zip,bz2,ldap,imap,apcu} \
  libapache2-mod-php certbot python3-certbot-apache

O erro comum aqui é esquecer o php-intl: a instalação do pacote segue, mas o GLPI barra na verificação de requisitos e a formatação de datas e a internacionalização quebram. php-ldap e php-imap só são necessários se você for integrar Active Directory e o coletor de e-mail, mas instalar desde já evita reinstalar depois.

2. Os dois php.ini que importam

Este é o ponto que separa uma instalação que "funciona" de uma que funciona de madrugada também. O PHP mantém configurações separadas por SAPI: o Apache lê /etc/php/8.2/apache2/php.ini, mas o cron do GLPI roda pela linha de comando e lê /etc/php/8.2/cli/php.ini. Ajuste os dois com os mesmos valores:

memory_limit = 256M
upload_max_filesize = 20M
post_max_size = 20M
max_execution_time = 300
max_input_vars = 5000
session.cookie_httponly = On
date.timezone = America/Sao_Paulo
; lembre-se: este mesmo arquivo existe em .../cli/php.ini

Na sustentação, a causa número um de "as ações automáticas pararam" quase nunca é o cron do sistema: é o memory_limit de 128M no php.ini do CLI travando a sincronização de inventário ou o envio de notificações em lote, enquanto o do Apache já estava em 256M e ninguém desconfiava. Edite os dois arquivos.

3. MariaDB, banco e o fuso horário

Rode o mysql_secure_installation e crie o banco com utf8mb4 (acentuação e emojis dependem disso):

mysql -u root -p

CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'glpi'@'localhost' IDENTIFIED BY 'SuaSenhaForte';
GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'localhost';
FLUSH PRIVILEGES;

Um detalhe que só aparece depois: o seletor de fuso horário do GLPI fica vazio até você importar as tabelas de timezone do MariaDB e conceder leitura ao usuário do GLPI. Faça agora:

# Importa as tabelas de fuso; sem isto o seletor de timezone fica vazio
mariadb-tzinfo-to-sql /usr/share/zoneinfo | mysql -u root mysql
mysql -u root -e "GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'localhost'; FLUSH PRIVILEGES;"

4. Tire config, files e logs do webroot - e diga ao GLPI onde foram

Baixe o GLPI 11 e extraia:

cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz -C /var/www/
chown -R www-data:www-data /var/www/glpi

Por segurança, os dados sensíveis não podem ficar sob o webroot. Mova-os:

mkdir -p /etc/glpi /var/lib/glpi/files /var/log/glpi
mv /var/www/glpi/config/* /etc/glpi/
mv /var/www/glpi/files/*  /var/lib/glpi/files/
chown -R www-data:www-data /etc/glpi /var/lib/glpi /var/log/glpi

Aqui está o erro mais comum da instalação manual: mover os diretórios e não avisar o GLPI onde eles foram. O resultado é o instalador recriar config/ e files/ dentro do webroot, você fechar permissão no lugar errado e continuar exposto. A forma correta é criar inc/downstream.php - ele é lido tanto pelo Apache quanto pelo CLI, então resolve web e cron de uma vez:

<?php // /var/www/glpi/inc/downstream.php
define('GLPI_CONFIG_DIR', '/etc/glpi');
define('GLPI_VAR_DIR',    '/var/lib/glpi/files');
define('GLPI_LOG_DIR',    '/var/log/glpi');

5. Virtual host, HTTPS e o DocumentRoot em public/

O DocumentRoot aponta para /var/www/glpi/public, nunca para a raiz da instalação - isto é obrigatório desde o GLPI 10 e é o que impede que config e files sejam servidos pela web.

<VirtualHost *:80>
    ServerName glpi.cliente.com.br
    DocumentRoot /var/www/glpi/public   # nunca /var/www/glpi

    <Directory /var/www/glpi/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

a2ensite glpi.conf && a2enmod rewrite
a2dissite 000-default.conf
systemctl reload apache2
certbot --apache -d glpi.cliente.com.br

6. Instale por linha de comando e configure o cron

Com o downstream.php no lugar, o db:install já grava o config_db.php em /etc/glpi - não precisa exportar variável nenhuma:

php /var/www/glpi/bin/console db:install \
  --db-host=localhost --db-name=glpi \
  --db-user=glpi --db-password='SuaSenhaForte' \
  --default-language=pt_BR --no-interaction

O GLPI processa notificações, inventário e ações automáticas por um cron externo. Agende-o de minuto em minuto - o próprio GLPI decide o que roda em cada disparo, conforme a frequência de cada tarefa:

echo "* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php &>/dev/null" > /etc/cron.d/glpi

Depois, em Configurar > Ações automáticas, mude o modo de execução para CLI. Se ficar no modo interno (disparo no acesso do usuário), as tarefas somem de madrugada e nos fins de semana - exatamente quando você quer o inventário e os backups rodando.

7. Pós-instalação: o checklist que fecha o ambiente

1. Remova o instalador: rm /var/www/glpi/install/install.php. Atenção: todo upgrade recria esse arquivo - remova de novo depois de cada atualização.
2. Troque as senhas dos quatro usuários padrão: glpi, tech, normal e post-only.
3. Configure o SMTP em Configurar > Notificações e envie um e-mail de teste.
4. Confirme que o instalador saiu do ar e que o cron rodou:

# Instalador ainda acessível? (esperado: 404)
curl -s -o /dev/null -w "%{http_code}\n" https://glpi.cliente.com.br/install/install.php

-- O cron externo está rodando? (lastrun deve ser recente)
SELECT name, state, lastrun FROM glpi_crontasks ORDER BY lastrun DESC LIMIT 5;

O que verificamos ao assumir um GLPI de terceiros

Quando entramos na sustentação de um ambiente instalado por outra equipe, o diagnóstico é sempre o mesmo trio: existe inc/downstream.php ou há dois diretórios config convivendo (um vivo, um fantasma que alguém edita sem efeito)? O memory_limit do CLI acompanha o do Apache? E o modo das ações automáticas está em CLI ou preso ao acesso de usuário? Esses três pontos explicam a maioria dos "o GLPI está lento" e "as notificações não chegam" que recebemos - e nenhum aparece numa instalação testada só clicando na interface durante o horário comercial.

Precisa de um GLPI 11 provisionado e sustentado com esse rigor, sem herdar dívida de instalação? Conheça a sustentação de ambientes GLPI da NexTool.

Revisado pela equipe NexTool Solutions.