NexTool Solutions

Instalar o GLPI 11 no Linux corre bem até à linha em que tira config/ e files/ de dentro do webroot e o instalador deixa de "encontrar" a base de dados. Este é o passo a passo que usamos ao provisionar GLPI para clientes: os comandos reais, os dois php.ini que de facto importam, o ficheiro que evita o erro mais comum da instalação manual e a lista de verificação pós-instalação que fecha o ambiente.

Antes de começar: dimensione o servidor

O GLPI 11 corre sobre a pilha clássica LAMP: Apache (ou Nginx) + PHP 8.1 ou superior + MariaDB 10.5+ (ou MySQL 8). No Debian 12 o PHP predefinido é 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 é a RAM e o modelo de execução do PHP (mod_php contra 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 no ecrã 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 prossegue, 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 for integrar Active Directory e o coletor de correio, mas instalar já evita reinstalar depois.

2. Os dois php.ini que importam

Este é o ponto que separa uma instalação que "funciona" de uma que também funciona de madrugada. O PHP mantém definições separadas por SAPI: o Apache lê /etc/php/8.2/apache2/php.ini, mas o cron do GLPI corre pela linha de comandos 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 = Europe/Lisbon
; lembre-se: este mesmo ficheiro 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 a travar 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 ficheiros.

3. MariaDB, base de dados e o fuso horário

Corra o mysql_secure_installation e crie a base de dados 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é importar as tabelas de fuso do MariaDB e conceder leitura ao utilizador do GLPI. Faça agora:

# Importa as tabelas de fuso; sem isto o seletor de fuso 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 ficaram

Descarregue 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 as pastas e não avisar o GLPI para onde foram. O resultado é o instalador recriar config/ e files/ dentro do webroot, fechar permissões no sítio errado e o ambiente continuar exposto. A forma correta é criar inc/downstream.php - é lido tanto pelo Apache como pelo CLI, por isso 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 - é 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 comandos 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 de exportar nenhuma variável:

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

O GLPI processa notificações, inventário e ações automáticas por um cron externo. Agende-o ao minuto - o próprio GLPI decide o que corre 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 utilizador), as tarefas desaparecem de madrugada e aos fins de semana - exatamente quando quer o inventário e as cópias de segurança a correr.

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

1. Remova o instalador: rm /var/www/glpi/install/install.php. Atenção: cada upgrade recria este ficheiro - remova outra vez após cada atualização.
2. Troque as palavras-passe dos quatro utilizadores predefinidos: 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 correu:

# O instalador ainda está 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á a correr? (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 equipa, o diagnóstico é sempre o mesmo trio: existe inc/downstream.php ou há duas pastas config a conviver (uma viva, uma 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 do utilizador? Estes 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ó a clicar na interface durante o horário de expediente.

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

Revisto pela equipa NexTool Solutions.