NexTool Solutions

Instalar GLPI 11 en Linux va bien hasta la línea en la que sacas config/ y files/ del webroot y el instalador deja de "encontrar" la base de datos. Este es el paso a paso que usamos al aprovisionar GLPI para clientes: los comandos reales, los dos php.ini que de verdad importan, el archivo que evita el error más común de la instalación manual y la lista de verificación posterior que asegura el entorno.

Antes de empezar: dimensiona el servidor

GLPI 11 corre sobre la pila clásica LAMP: Apache (o Nginx) + PHP 8.1 o superior + MariaDB 10.5+ (o MySQL 8). En Debian 12 el PHP por defecto es el 8.2; en Ubuntu 24.04 LTS, el 8.3 - ambos sirven. Lo que realmente cambia entre un piloto y un entorno de cientos de técnicos es la RAM y el modelo de ejecución de PHP (mod_php frente a PHP-FPM). Esta es la matriz que usamos para dimensionar:

1. Sistema, servidor web, PHP y extensiones

Actualiza el sistema e instala todo de una vez. Las extensiones no son opcionales: GLPI valida cada una en la pantalla 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

El error común aquí es olvidar php-intl: la instalación del paquete continúa, pero GLPI se detiene en la verificación de requisitos y el formato de fechas y la internacionalización se rompen. php-ldap y php-imap solo son necesarios si vas a integrar Active Directory y el receptor de correo, pero instalarlos ya evita reinstalar después.

2. Los dos php.ini que importan

Este es el punto que separa una instalación que "funciona" de una que también funciona de madrugada. PHP mantiene configuraciones separadas por SAPI: Apache lee /etc/php/8.2/apache2/php.ini, pero el cron de GLPI corre por línea de comandos y lee /etc/php/8.2/cli/php.ini. Ajusta ambos con los mismos 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/Madrid
; recuerda: este mismo archivo existe en .../cli/php.ini

En el soporte, la causa número uno de "las acciones automáticas dejaron de funcionar" casi nunca es el cron del sistema: es el memory_limit de 128M en el php.ini del CLI ahogando la sincronización de inventario o el envío de notificaciones por lotes, mientras el de Apache ya estaba en 256M y nadie sospechaba. Edita los dos archivos.

3. MariaDB, la base de datos y la zona horaria

Ejecuta mysql_secure_installation y crea la base de datos con utf8mb4 (los acentos y los emojis dependen de ello):

mysql -u root -p

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

Un detalle que solo aparece después: el selector de zona horaria de GLPI queda vacío hasta que importes las tablas de zona horaria de MariaDB y concedas lectura al usuario de GLPI. Hazlo ahora:

# Carga las tablas de zona horaria; sin esto el selector queda vacío
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. Saca config, files y logs del webroot - y dile a GLPI dónde están

Descarga GLPI 11 y descomprímelo:

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 seguridad, los datos sensibles no pueden estar bajo el webroot. Muévelos:

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

Aquí está el error más común de la instalación manual: mover los directorios y no decirle a GLPI dónde fueron. El resultado es que el instalador recrea config/ y files/ dentro del webroot, tú cierras permisos en el lugar equivocado y el entorno sigue expuesto. La forma correcta es crear inc/downstream.php - lo leen tanto Apache como el CLI, así que resuelve la web y el cron de una 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 y el DocumentRoot en public/

El DocumentRoot apunta a /var/www/glpi/public, nunca a la raíz de la instalación - esto es obligatorio desde GLPI 10 y es lo que impide que config y files se sirvan por la 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. Instala por línea de comandos y configura el cron

Con downstream.php en su sitio, db:install ya escribe config_db.php en /etc/glpi - no hace falta exportar ninguna variable:

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

GLPI procesa notificaciones, inventario y acciones automáticas mediante un cron externo. Prográmalo cada minuto - el propio GLPI decide qué corre en cada disparo, según la frecuencia de cada tarea:

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

Luego, en Configurar > Acciones automáticas, cambia el modo de ejecución a CLI. Si se queda en modo interno (disparo al acceder los usuarios), las tareas desaparecen de madrugada y los fines de semana - justo cuando quieres el inventario y las copias corriendo.

7. Posinstalación: la lista que asegura el entorno

1. Elimina el instalador: rm /var/www/glpi/install/install.php. Ojo: cada upgrade recrea este archivo - bórralo de nuevo tras cada actualización.
2. Cambia las contraseñas de los cuatro usuarios por defecto: glpi, tech, normal y post-only.
3. Configura el SMTP en Configurar > Notificaciones y envía un correo de prueba.
4. Confirma que el instalador ya no está y que el cron corrió:

# ¿El instalador sigue accesible? (esperado: 404)
curl -s -o /dev/null -w "%{http_code}\n" https://glpi.cliente.com.br/install/install.php

-- ¿El cron externo está corriendo? (lastrun debe ser reciente)
SELECT name, state, lastrun FROM glpi_crontasks ORDER BY lastrun DESC LIMIT 5;

Qué revisamos al asumir un GLPI de terceros

Cuando asumimos el soporte de un entorno instalado por otro equipo, el diagnóstico es siempre el mismo trío: ¿existe inc/downstream.php o hay dos directorios config conviviendo (uno vivo y otro fantasma que alguien edita sin efecto)? ¿El memory_limit del CLI acompaña al de Apache? ¿Y el modo de las acciones automáticas está en CLI o atado al acceso de usuarios? Esos tres puntos explican la mayoría de los "GLPI está lento" y "las notificaciones no llegan" que recibimos - y ninguno aparece en una instalación probada solo haciendo clic en la interfaz durante el horario laboral.

¿Necesitas un GLPI 11 aprovisionado y mantenido con este rigor, sin heredar deuda de instalación? Conoce el soporte y mantenimiento de GLPI de NexTool.

Revisado por el equipo de NexTool Solutions.