Ce tutoriel installe GLPI 11.0.7 sur un serveur Ubuntu Server 24.04 LTS prêt pour la production. Vous obtenez à la fin de la lecture une instance accessible en HTTPS, branchée sur MariaDB, sécurisée par les bases (HTTPS Let’s Encrypt, headers, suppression du fichier d’installation), avec une procédure de sauvegarde et de mise à jour clairement définie.
Le tutoriel s’adresse à un administrateur système ayant déjà manipulé Apache ou Nginx et l’apt-get. Aucun pré-requis avancé Linux. Le temps de mise en œuvre tient en deux à trois heures pour un opérateur méthodique. Le guide de référence GLPI 11 helpdesk ITIL : déployer un service desk professionnel donne le contexte ITSM autour de l’installation présentée ici.
Étape 1 — Préparer la VM Ubuntu 24.04 LTS
Provisionnez une VM ou un serveur dédié avec au minimum 2 vCPU, 4 Go de RAM et 40 Go de SSD. Pour 50 à 200 utilisateurs visés, 4 vCPU, 8 Go de RAM et 80 Go de SSD restent confortables et donnent une marge pour les pics. L’image officielle Ubuntu Server 24.04 LTS (Noble Numbat, support standard jusqu’en avril 2029) est le choix par défaut. Connectez-vous en SSH avec un utilisateur sudoer.
Mettez le système à jour, installez les utilitaires courants, fixez le nom d’hôte et le fuseau horaire :
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget unzip vim ufw fail2ban
sudo hostnamectl set-hostname glpi.example.lan
sudo timedatectl set-timezone Europe/Paris
À la fin de ces commandes, hostnamectl et timedatectl status doivent renvoyer le nom et le fuseau attendus. Cette étape évite les surprises classiques : un serveur en UTC qui décale toutes les heures de tickets, ou un nom d’hôte par défaut qui pollue les certificats TLS.
Étape 2 — Installer LAMP : Apache, PHP 8.3 et MariaDB
GLPI 11.0.x exige PHP 8.2 minimum selon la documentation officielle, et MariaDB 10.6 LTS ou plus récent (ou MySQL 8.0+). Ubuntu 24.04 livre PHP 8.3 et MariaDB 10.11 LTS dans ses dépôts standards, ce qui couvre largement la matrice de support. Nous installons l’ensemble en une commande :
sudo apt install -y apache2 mariadb-server \
php php-cli php-common php-curl php-gd php-intl php-mbstring \
php-mysql php-xml php-zip php-bz2 php-bcmath php-ldap \
php-fileinfo php-opcache libapache2-mod-php
Vérifiez les versions installées :
php -v
mariadb --version
apache2 -v
Vous devez lire au minimum PHP 8.3.x, mariadb Ver 10.11.x et Apache/2.4.x. Si une de ces lignes manque ou pointe sur une version trop ancienne, corrigez avant d’aller plus loin — GLPI refusera de s’installer sur PHP 8.1.
Activez les modules Apache nécessaires (rewrite pour les URL propres, headers pour la sécurité, ssl pour HTTPS) puis redémarrez :
sudo a2enmod rewrite headers ssl
sudo systemctl restart apache2
Le service Apache doit retourner active (running) sous systemctl status apache2. Si le port 80 est déjà occupé par un autre service, identifiez-le avec ss -ltnp et libérez-le avant la suite.
Étape 3 — Durcir l’installation MariaDB
MariaDB s’installe avec un mot de passe root vide et des comptes de test inutiles en production. Le script mysql_secure_installation nettoie tout cela en quelques questions :
sudo mysql_secure_installation
Répondez :
- « Enter current password for root » : laissez vide, appuyez sur Entrée
- « Switch to unix_socket authentication » : n (la suite des étapes utilise un compte applicatif dédié)
- « Change the root password » : y, puis tapez un mot de passe robuste (au moins 16 caractères mélangés)
- « Remove anonymous users » : y
- « Disallow root login remotely » : y
- « Remove test database » : y
- « Reload privilege tables » : y
Ce script supprime les portes ouvertes par défaut. Sans cette étape, n’importe quel processus local peut tenter une élévation de privilèges via le compte root MariaDB sans authentification.
Étape 4 — Créer la base et le compte applicatif GLPI
Ne réutilisez jamais le compte root MariaDB pour l’applicatif. GLPI doit disposer d’un compte dédié, limité à sa propre base, avec un mot de passe fort propre. Connectez-vous à MariaDB en root :
sudo mariadb -u root -p
Une fois sur le prompt SQL, créez la base et le compte :
CREATE DATABASE glpidb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'glpiuser'@'localhost' IDENTIFIED BY 'ChangeMe-N0w-Pl3ase!';
GRANT ALL PRIVILEGES ON glpidb.* TO 'glpiuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;
Remplacez bien sûr ChangeMe-N0w-Pl3ase! par un mot de passe généré (par exemple via openssl rand -base64 24) que vous notez dans votre gestionnaire de secrets. La collation utf8mb4_unicode_ci garantit le support correct des caractères étendus (accents, emojis, idéogrammes) que vous trouverez dans les tickets.
Depuis MariaDB 10.6, GLPI exige que le timezone soit chargé pour autoriser certaines fonctions de date. Chargez-le une fois pour toutes :
sudo mariadb-tzinfo-to-sql /usr/share/zoneinfo | sudo mariadb -u root -p mysql
sudo mariadb -u root -p -e "GRANT SELECT ON mysql.time_zone_name TO 'glpiuser'@'localhost'; FLUSH PRIVILEGES;"
Sans ce chargement, l’installeur GLPI affichera un avertissement « Le serveur de base de données ne supporte pas les fuseaux horaires » et certaines fonctionnalités liées aux SLA s’écarteront silencieusement.
Étape 5 — Télécharger et déposer GLPI 11.0.7
Récupérez la dernière archive depuis GitHub. La version 11.0.7 publiée le 29 avril 2026 est notre cible :
cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.7/glpi-11.0.7.tgz
tar -xzf glpi-11.0.7.tgz
sudo mv glpi /var/www/glpi
sudo chown -R www-data:www-data /var/www/glpi
sudo find /var/www/glpi -type d -exec chmod 755 {} \;
sudo find /var/www/glpi -type f -exec chmod 644 {} \;
L’archive contient tous les fichiers PHP, les assets statiques, et la documentation. Les permissions 755/644 sous l’utilisateur Apache www-data sont le minimum requis. Une vérification rapide :
ls -la /var/www/glpi | head
Vous devez voir le répertoire appartenir à www-data:www-data avec les dossiers config/, files/, install/, marketplace/, plugins/ présents.
Étape 6 — Configurer le virtual host Apache
Pour des raisons de sécurité, GLPI 11 recommande de pointer le DocumentRoot sur le sous-dossier public/ et non sur la racine de l’archive. Cela isole les fichiers de configuration et les bibliothèques internes. Créez le virtual host :
sudo tee /etc/apache2/sites-available/glpi.conf > /dev/null <<'EOF'
<VirtualHost *:80>
ServerName glpi.example.com
DocumentRoot /var/www/glpi/public
<Directory /var/www/glpi/public>
Require all granted
RewriteEngine On
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
sudo a2dissite 000-default.conf
sudo a2ensite glpi.conf
sudo systemctl reload apache2
Remplacez glpi.example.com par votre vrai nom de domaine ou sous-domaine. Si vous testez en local sans DNS, ajoutez l’entrée dans /etc/hosts de la machine cliente.
Testez avec un navigateur ou avec curl : curl -I http://glpi.example.com doit renvoyer un code 200 ou une redirection 302 vers /install/install.php. Si vous obtenez 403 ou 404, vérifiez les droits sur /var/www/glpi/public et le module rewrite.
Étape 7 — Exécuter l’installeur web
Ouvrez http://glpi.example.com/install/install.php dans votre navigateur. L’assistant déroule sept écrans :
- Choix de la langue (Français)
- Acceptation de la licence GPLv3
- Choix « Installer GLPI »
- Vérification des prérequis — la page doit afficher des coches vertes partout, les avertissements jaunes acceptables, aucun rouge
- Connexion à la base : serveur
localhost, utilisateurglpiuser, mot de passe noté à l’étape 4 - Choix de la base : sélectionner
glpidb - Création des tables et finalisation
Si tous les voyants sont verts, vous arrivez sur une page « Installation terminée » qui rappelle les quatre comptes par défaut : glpi/glpi (super-admin), tech/tech (technicien), normal/normal (utilisateur normal), post-only/postonly (utilisateur self-service).
Étape 8 — Étapes de sécurisation post-installation
Trois actions sont obligatoires juste après la première connexion :
Premièrement, changez immédiatement les mots de passe des quatre comptes par défaut. Connectez-vous avec glpi/glpi, allez dans « Administration » puis « Utilisateurs », et modifiez chaque compte. Beaucoup de scans Internet ciblent en priorité /install/install.php et les comptes par défaut GLPI.
Deuxièmement, supprimez le dossier install/ qui n’a plus aucune utilité après installation et qui constitue une porte d’entrée pour les attaquants :
sudo rm -rf /var/www/glpi/install
Troisièmement, activez le pare-feu UFW et n’ouvrez que ce qui doit l’être :
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status
Vous devez voir trois règles ALLOW (22, 80, 443) et le statut active. Si SSH passe par un port custom, ajustez. Le port 3306 de MariaDB n’est pas ouvert — la base est accédée uniquement en local.
Étape 9 — Activer HTTPS avec Let’s Encrypt
HTTPS n’est pas négociable pour un service desk. Installez certbot et le plugin Apache, puis générez le certificat :
sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache -d glpi.example.com --non-interactive --agree-tos -m admin@example.com --redirect
Certbot installe le certificat, modifie la configuration Apache pour ajouter le virtual host SSL sur le port 443, force la redirection HTTP → HTTPS, et programme le renouvellement automatique via un timer systemd. Vérifiez le timer :
sudo systemctl list-timers | grep certbot
Le service certbot.timer doit apparaître comme actif. Le renouvellement se fait deux fois par jour mais ne déclenche un appel à Let’s Encrypt que 30 jours avant l’expiration. Un test à blanc rassure : sudo certbot renew --dry-run doit afficher « Congratulations, all simulated renewals succeeded ».
Étape 10 — Planifier la sauvegarde MariaDB
Une instance GLPI sans sauvegarde est une bombe à retardement. Programmez une sauvegarde quotidienne avec rotation sur sept jours :
sudo mkdir -p /var/backups/glpi
sudo tee /usr/local/bin/glpi-backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
DATE=$(date +%F)
BACKUP_DIR=/var/backups/glpi
mariadb-dump --single-transaction --quick --routines --triggers \
-u glpiuser -p"$(cat /root/.glpi-db-password)" glpidb \
| gzip > "$BACKUP_DIR/glpidb-$DATE.sql.gz"
find "$BACKUP_DIR" -name "glpidb-*.sql.gz" -mtime +7 -delete
EOF
sudo chmod 700 /usr/local/bin/glpi-backup.sh
echo "MotDePasseGlpiUser" | sudo tee /root/.glpi-db-password > /dev/null
sudo chmod 600 /root/.glpi-db-password
echo "30 2 * * * root /usr/local/bin/glpi-backup.sh" | sudo tee /etc/cron.d/glpi-backup
Cette ligne crontab exécute la sauvegarde tous les jours à 2h30, écrit un dump compressé daté, et supprime les sauvegardes de plus de sept jours. Le mot de passe est stocké hors de la ligne de commande pour ne pas apparaître dans ps aux.
Pour aller plus loin, exportez les sauvegardes vers un stockage externe (object storage S3-compatible, NFS distant, deuxième serveur) — une sauvegarde locale ne protège pas d’une panne du disque ou d’un ransomware qui chiffre la VM entière.
Étape 11 — Vérifier l’installation
Ouvrez votre instance en HTTPS, connectez-vous avec votre compte super-admin renommé, et parcourez le menu de gauche : Parc, Assistance, Outils, Administration, Configuration. Cliquez « Configuration » puis « Notifications » pour configurer le serveur SMTP (passerelle interne ou SaaS comme SendGrid, Brevo, Postmark). Sans SMTP, les notifications de tickets ne partiront pas et le ressenti utilisateur s’effondre.
Ouvrez un ticket de test depuis le portail Self-Service : « Assistance » puis « Créer un ticket ». Vérifiez que l’utilisateur receveur reçoit bien la notification e-mail. Si ce n’est pas le cas, consultez /var/log/apache2/glpi_error.log et la table glpi_queuednotifications dans MariaDB pour comprendre l’erreur.
Erreurs fréquentes et solutions
| Symptôme | Cause probable | Solution |
|---|---|---|
| Page blanche après installation | Extension PHP manquante (curl, gd, intl) | Réinstaller les paquets et redémarrer Apache |
| « Le serveur DB ne supporte pas les fuseaux horaires » | Tables timezone non chargées | Relancer mariadb-tzinfo-to-sql et accorder le SELECT |
| Erreur 500 sur /install/install.php | Permissions incorrectes sur files/ |
chown -R www-data:www-data /var/www/glpi/files |
| Notifications jamais envoyées | Cron non lancé | Vérifier /etc/cron.d/glpi ou lancer manuellement php front/cron.php |
| Login en boucle | Cookies bloqués par un reverse proxy | Activer la directive Apache RequestHeader edit Cookie |
Mise à jour vers la version suivante
Quand 11.0.8 ou 11.1.x sortira, la procédure de mise à jour suit toujours le même schéma : sauvegarder la base et les fichiers, télécharger la nouvelle archive, écraser /var/www/glpi sauf config/, files/ et marketplace/, puis exécuter la migration de schéma :
cd /var/www/glpi
sudo -u www-data php bin/console db:update
La commande détecte la version installée, applique les migrations nécessaires, et reporte les éventuelles erreurs. Testez d’abord sur un environnement de pré-production cloné de la production avant de mettre à jour l’instance en service.
Articles associés
- GLPI 11 helpdesk ITIL : déployer un service desk professionnel
- Configurer l’authentification LDAP/AD avec GLPI 11
- Inventorier le parc IT avec GLPI Agent
- Sécuriser GLPI en production : TLS, Fail2ban, durcissement