NexTool Solutions

Installer GLPI 11 sur Linux se passe bien jusqu'à la ligne où vous sortez config/ et files/ du webroot et où l'installateur ne "trouve" plus la base de données. Voici le pas à pas que nous utilisons pour provisionner GLPI chez nos clients : les commandes réelles, les deux php.ini qui comptent vraiment, le fichier qui évite l'erreur la plus courante de l'installation manuelle et la liste de contrôle post-installation qui verrouille l'environnement.

Avant de commencer : dimensionnez le serveur

GLPI 11 tourne sur la pile classique LAMP : Apache (ou Nginx) + PHP 8.1 ou supérieur + MariaDB 10.5+ (ou MySQL 8). Sous Debian 12 le PHP par défaut est le 8.2 ; sous Ubuntu 24.04 LTS, le 8.3 - les deux conviennent. Ce qui change vraiment entre un pilote et un environnement de centaines de techniciens, c'est la RAM et le modèle d'exécution de PHP (mod_php contre PHP-FPM). Voici la matrice que nous utilisons pour dimensionner :

1. Système, serveur web, PHP et extensions

Mettez le système à jour et installez tout d'un coup. Les extensions ne sont pas optionnelles : GLPI valide chacune sur l'écran des prérequis.

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

L'erreur courante ici est d'oublier php-intl : l'installation du paquet réussit quand même, mais GLPI bloque à la vérification des prérequis et le formatage des dates ainsi que l'internationalisation cassent. php-ldap et php-imap ne sont nécessaires que si vous intégrez Active Directory et le collecteur de courrier, mais les installer maintenant évite une réinstallation plus tard.

2. Les deux php.ini qui comptent

C'est ce qui sépare une installation qui "marche" d'une qui marche aussi à 3 h du matin. PHP garde des réglages séparés par SAPI : Apache lit /etc/php/8.2/apache2/php.ini, mais le cron de GLPI tourne en ligne de commande et lit /etc/php/8.2/cli/php.ini. Réglez les deux avec les mêmes valeurs :

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/Paris
; rappel : ce même fichier existe aussi dans .../cli/php.ini

En infogérance, la cause numéro un des "actions automatiques qui se sont arrêtées" n'est presque jamais le cron du système : c'est le memory_limit à 128M dans le php.ini du CLI qui étouffe la synchro d'inventaire ou l'envoi de notifications en lot, alors que celui d'Apache était déjà à 256M et que personne ne s'en doutait. Éditez les deux fichiers.

3. MariaDB, la base et le fuseau horaire

Lancez mysql_secure_installation et créez la base en utf8mb4 (les accents et les emojis en dépendent) :

mysql -u root -p

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

Un détail qui n'apparaît que plus tard : le sélecteur de fuseau horaire de GLPI reste vide tant que vous n'importez pas les tables de fuseaux de MariaDB et n'accordez pas la lecture à l'utilisateur GLPI. Faites-le maintenant :

# Charge les tables de fuseaux ; sans cela le sélecteur reste vide
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. Sortez config, files et logs du webroot - et dites à GLPI où ils sont

Téléchargez GLPI 11 et décompressez-le :

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

Pour la sécurité, les données sensibles ne doivent pas rester sous le webroot. Déplacez-les :

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

Voici l'erreur la plus courante de l'installation manuelle : déplacer les répertoires sans dire à GLPI où ils sont allés. Résultat : l'installateur recrée config/ et files/ dans le webroot, vous verrouillez les permissions au mauvais endroit et l'environnement reste exposé. La bonne façon est de créer inc/downstream.php - il est lu par Apache comme par le CLI, donc il règle le web et le cron d'un coup :

<?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 et le DocumentRoot sur public/

Le DocumentRoot pointe vers /var/www/glpi/public, jamais vers la racine de l'installation - c'est obligatoire depuis GLPI 10 et c'est ce qui empêche config et files d'être servis par le web.

<VirtualHost *:80>
    ServerName glpi.cliente.com.br
    DocumentRoot /var/www/glpi/public   # jamais /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. Installez en ligne de commande et configurez le cron

Avec downstream.php en place, db:install écrit déjà config_db.php dans /etc/glpi - inutile d'exporter la moindre variable :

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

GLPI traite les notifications, l'inventaire et les actions automatiques via un cron externe. Planifiez-le chaque minute - GLPI décide lui-même ce qui tourne à chaque déclenchement, selon la fréquence de chaque tâche :

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

Ensuite, dans Configuration > Actions automatiques, passez le mode d'exécution en CLI. S'il reste en mode interne (déclenché à l'accès des utilisateurs), les tâches disparaissent la nuit et le week-end - exactement quand vous voulez l'inventaire et les sauvegardes en marche.

7. Post-installation : la liste qui verrouille l'environnement

1. Supprimez l'installateur : rm /var/www/glpi/install/install.php. Attention : chaque upgrade recrée ce fichier - supprimez-le à nouveau après chaque mise à jour.
2. Changez les mots de passe des quatre comptes par défaut : glpi, tech, normal et post-only.
3. Configurez le SMTP dans Configuration > Notifications et envoyez un e-mail de test.
4. Confirmez que l'installateur a disparu et que le cron a tourné :

# L'installateur est-il encore accessible ? (attendu : 404)
curl -s -o /dev/null -w "%{http_code}\n" https://glpi.cliente.com.br/install/install.php

-- Le cron externe tourne-t-il ? (lastrun doit être récent)
SELECT name, state, lastrun FROM glpi_crontasks ORDER BY lastrun DESC LIMIT 5;

Ce que nous vérifions en reprenant un GLPI installé par un tiers

Quand nous reprenons l'infogérance d'un environnement installé par une autre équipe, le diagnostic est toujours le même trio : y a-t-il un inc/downstream.php, ou deux répertoires config qui cohabitent (un vivant, un fantôme que quelqu'un modifie sans effet) ? Le memory_limit du CLI suit-il celui d'Apache ? Et le mode des actions automatiques est-il en CLI ou lié à l'accès des utilisateurs ? Ces trois points expliquent la plupart des "GLPI est lent" et "les notifications n'arrivent pas" que nous recevons - et aucun n'apparaît sur une installation testée seulement en cliquant dans l'interface aux heures de bureau.

Besoin d'un GLPI 11 provisionné et maintenu avec cette rigueur, sans hériter d'une dette d'installation ? Découvrez la maintenance et le support GLPI de NexTool.

Révisé par l'équipe NexTool Solutions.