Exploiter et sécuriser GLPI : cron, sauvegardes, mises à jour

Exploiter GLPI au quotidien, c'est s'assurer que ses tâches automatiques tournent, que sa base et ses fichiers sont sauvegardés et restaurables, que l'application et ses plugins sont à jour, et que l'instance est protégée, puisqu'elle contient la carte complète du système d'information et des données personnelles. Ce chapitre rassemble les gestes d'administration : actions automatiques, sauvegarde et restauration, mise à jour de GLPI 11 vers 12, plugins, sécurité, journaux et conformité au RGPD.

Les actions automatiques et le cron

Beaucoup de fonctions de GLPI ne se déclenchent pas quand un utilisateur clique, mais à intervalles réguliers : ce sont les actions automatiques (Configuration > Actions automatiques). Chacune a une fréquence, un statut (active ou non), un mode d'exécution et une plage horaire.

• En mode GLPI, l'action est lancée de temps en temps quand des utilisateurs naviguent dans l'interface : la nuit ou le week-end, rien ne se passe.
• En mode CLI, l'action est lancée par une tâche planifiée du système, qui appelle front/cron.php. C'est le mode recommandé.

# crontab de l'utilisateur du serveur web : sudo crontab -u www-data -e
* * * * * /usr/bin/php /var/www/glpi/front/cron.php

# forcer une action précise, par exemple la relève des courriels
sudo -u www-data php /var/www/glpi/front/cron.php --force mailgate

Les actions à connaître :

Depuis GLPI 12, une action qui échoue cinq fois de suite passe au statut Erreur et demande une intervention ; une action interrompue de l'extérieur passe au statut Interrompue et sera relancée. La colonne « dernière exécution » et l'onglet des journaux de chaque action sont les premières choses à regarder quand « GLPI ne fait plus » quelque chose.

Sauvegarder GLPI, et tester la restauration

Une sauvegarde de GLPI comprend trois choses, et oublier l'une d'elles rend les deux autres inutilisables :

La clé glpicrypt.key mérite une attention particulière : GLPI chiffre avec elle les secrets qu'il stocke en base (mot de passe du compte de lecture de l'annuaire, mots de passe des collecteurs, jetons). Une base restaurée sans sa clé fonctionne, mais tous ces secrets sont illisibles : l'authentification par l'annuaire et les collecteurs cessent de fonctionner.

Le script de sauvegarde nocturne de Cèdre Habitat :

#!/bin/bash
# /usr/local/sbin/sauvegarde-glpi.sh, lancé chaque nuit par cron (compte root)
set -euo pipefail
DEST=/srv/sauvegardes/glpi
JOUR=$(date +%F)
mkdir -p "$DEST"

# 1. La base, dans une transaction cohérente, sans bloquer les utilisateurs
mariadb-dump --single-transaction --routines glpi | gzip > "$DEST/glpi-base-$JOUR.sql.gz"

# 2. Les fichiers et la configuration (dont la clé de chiffrement)
tar -czf "$DEST/glpi-fichiers-$JOUR.tar.gz" /var/lib/glpi /etc/glpi

# 3. Garder 14 jours de sauvegardes locales
find "$DEST" -name 'glpi-*' -mtime +14 -delete

Ces sauvegardes locales sont ensuite copiées hors du serveur, et une copie hors site, selon la règle 3-2-1 présentée dans le cours Sauvegarde et PRA. Avec Docker, on sauvegarde de la même façon la base (par docker compose exec sur le conteneur de la base) et le volume des données de GLPI.

Une sauvegarde qui n'a jamais été restaurée ne prouve rien. Chaque trimestre, Thomas restaure la sauvegarde de la veille sur une machine de test : il recrée la base, réimporte le fichier, remet en place les dossiers et la clé, puis vérifie qu'il peut se connecter avec un compte de l'annuaire, ouvrir un document joint et retrouver les tickets de la veille. Il note la date, la durée de la restauration et les problèmes rencontrés dans un ticket récurrent (chapitre 9).

# Restauration sur la machine de test
gunzip -c glpi-base-2026-11-01.sql.gz | sudo mariadb glpi
sudo tar -xzf glpi-fichiers-2026-11-01.tar.gz -C /
sudo chown -R www-data:www-data /var/lib/glpi /etc/glpi

Mettre à jour GLPI

GLPI publie régulièrement des versions correctives, souvent pour des failles de sécurité : 11.0.9, 11.0.10 et 12.0.1 étaient des versions de sécurité. Une instance jamais mise à jour est une instance vulnérable. Suis les annonces du projet et applique les versions correctives rapidement.

La procédure pour une installation à la main, celle que Thomas a suivie pour passer de GLPI 11 à GLPI 12 :

1. Vérifier les prérequis de la nouvelle version : PHP 8.3 et MariaDB 10.11 au minimum pour GLPI 12. Le serveur de Cèdre Habitat était sous Debian 13, donc rien à changer ; sous Debian 12, il aurait d'abord fallu mettre à jour le système.
2. Vérifier les plugins : chacun doit exister dans une version compatible avec la nouvelle version de GLPI, sinon il sera désactivé.
3. Sauvegarder la base, les fichiers et la configuration, et noter la version actuelle.
4. Passer en mode maintenance, pour que personne ne travaille pendant l'opération : sudo -u www-data php bin/console maintenance:enable.
5. Remplacer le dossier de l'application par celui de la nouvelle archive. Grâce à la séparation des dossiers du chapitre 2, les données et la configuration ne bougent pas ; il faut seulement recréer inc/downstream.php, qui est dans le dossier de l'application.
6. Mettre à jour la base : sudo -u www-data php bin/console db:update.
7. Supprimer à nouveau install/install.php, revenu avec la nouvelle archive.
8. Quitter le mode maintenance (maintenance:disable), puis vérifier : connexion, tickets, inventaire d'un poste, envoi d'un courriel, actions automatiques.
9. Contrôler les points propres à la version : pour GLPI 12, la visibilité de la base de connaissances (chapitre 12) et la ré-authentification des administrateurs.

Avec Docker, la mise à jour consiste à changer l'étiquette de l'image (glpi/glpi:12.0 au lieu de glpi/glpi:11.0), puis docker compose up -d : le conteneur met la base à jour au démarrage. La sauvegarde préalable reste obligatoire.

Les plugins et le marketplace

Les plugins ajoutent des fonctions à GLPI. Ils s'installent depuis le marketplace intégré (Configuration > Plugins) ou en déposant leur dossier à la main. Quelques plugins courants :

Chaque plugin est du code de plus à maintenir et à mettre à jour, et un plugin abandonné peut bloquer une mise à jour de GLPI. Beaucoup de fonctions qui demandaient un plugin sont désormais natives (inventaire, formulaires, actifs personnalisés, webhooks, double authentification) : avant d'installer un plugin, vérifie que la fonction n'existe pas déjà. Depuis GLPI 12, l'accès à la liste des plugins et au marketplace demande une ré-authentification.

Sécuriser l'instance

GLPI contient la liste de tous les postes avec leurs versions de logiciels, les adresses du réseau, les contrats, les tickets (qui mentionnent parfois des mots de passe envoyés par erreur par des utilisateurs) et les comptes de l'annuaire. C'est une cible de choix. Les mesures, de la plus simple à la plus avancée :

Les journaux

GLPI garde plusieurs traces, complémentaires :

• l'historique de chaque élément : qui a modifié quoi, quand, avec l'ancienne et la nouvelle valeur ;
• les journaux de l'application (Administration > Journaux) : connexions, échecs de connexion, actions d'administration, exécution des actions automatiques ;
• les fichiers de journaux du dossier /var/log/glpi (erreurs PHP, erreurs SQL, journaux des collecteurs et de l'inventaire), consultables depuis GLPI 11 dans une visionneuse intégrée ;
• les journaux du serveur web.

En cas d'incident (un compte d'administration créé sans raison, des fiches modifiées en masse), c'est en croisant ces sources qu'on reconstitue ce qui s'est passé : le cours Réponse aux incidents explique comment lire et conserver ces traces.

GLPI et le RGPD

GLPI traite des données personnelles : noms, adresses électroniques, téléphones, postes affectés, contenu des tickets, historique des connexions. L'organisation doit donc l'inscrire à son registre des traitements, avec sa finalité (gestion du parc et assistance), les catégories de données, les destinataires et les durées de conservation (cours Droit du numérique et RGPD). Dans GLPI, cela se traduit par :

• des profils qui limitent l'accès aux données au besoin de chacun ;
• des durées de conservation réglées dans Configuration > Données et confidentialité (nouveau menu de GLPI 12), qui rassemble les réglages de purge de l'historique et de l'historique des connexions ;
• la purge automatique des tickets clos au-delà d'une durée décidée par l'organisation, si elle est justifiée ;
• la désactivation des comptes des personnes parties, puis leur anonymisation ou leur suppression selon la politique de conservation ;
• l'option d'anonymisation des techniciens dans les tickets vus par les utilisateurs (onglet Assistance de l'entité), quand l'organisation le souhaite.

Superviser GLPI

GLPI est un service comme un autre : s'il tombe, plus personne ne peut ouvrir de ticket. La supervision de Cèdre Habitat surveille la réponse HTTPS de la page de connexion, l'espace disque de la base et des fichiers, la date d'expiration du certificat, et l'état fourni par la commande php bin/console system:status, qui indique notamment l'état de la base et des actions automatiques (dont, depuis GLPI 12, celles en erreur). Le cours Supervision montre comment intégrer ces contrôles dans Zabbix, l'outil du labo SISR (Centreon fait de même) : voir les scénarios web Zabbix.

Exercices