Mode opératoire — GLPI : gestion de parc et assistance, en actif / secours, base dans un cluster Galera

Document autonome. Partie théorique, puis mise en œuvre telle qu’elle a été réalisée et vérifiée du 05 au 06/11/2026 dans le lab : GLPI 11.0.12 sur les deux serveurs web srv-web-01 (10.0.10.10, actif) et srv-web-02 (10.0.10.11, secours), publié par le répartiteur HAProxy srv-ha (10.0.10.5) sous le nom https://glpi.sio.internal, base dans le cluster MariaDB / Galera à 3 nœuds (zone BDD). Phase 11 du suivi (SUIVI-TP.md), étapes 66, 69 et 70 de la documentation. Prérequis : le cluster Galera et HAProxy (MO-3), les deux serveurs web Apache + PHP, la recopie lsyncd (étape 64), la supervision (MO-13, MO-17).

Aucun mot de passe ni jeton ici : ils sont dans Bitwarden (registre des comptes, D-13, G-10 à G-18).

Dernière mise à jour : 06/11/2026 État au 12/11/2026 : §12 ajouté (portail des salariés en Self-Service, connexion par l’annuaire en LDAPS 636, phase 19, étape 73 ; 6 catégories de tickets, guide du salarié). 13 ordinateurs inventoriés.

Sommaire

1 · Ce qu’est GLPI, et les choix du lab

GLPI (Gestionnaire Libre de Parc Informatique) est l’outil libre de référence des services informatiques français : il tient l’inventaire du parc (machines, logiciels, licences) et l’assistance (tickets d’incident et de demande, suivis, solutions, statistiques). Dans le cas GSB, il répond à la mission « Assistance ».

Principe à retenir — Une application à état (sessions, fichiers) derrière un répartiteur se met en actif / secours, pas en répartition : l’utilisateur doit toujours retomber sur le même serveur tant que celui-ci vit.

2 · L’architecture

poste / admin ──HTTPS──► srv-ha 10.0.10.5:443 ──(nom demandé = glpi.sio.internal)──► backend glpi
                         certificat glpi.pem (SNI)                                    ├─ web-01 10.0.10.10:80  (actif)
                                                                                      └─ web-02 10.0.10.11:80  (backup)
srv-web-01 / 02 ──3306──► srv-ha (listen galera) ──► srv-mysql-01 (principal), 02 et 03 (secours)   base « glpi »
srv-web-01 ──lsyncd (SSH, clé confinée)──► srv-web-02 : /var/lib/glpi (documents, sessions)

3 · La base dans le cluster

Contexte : sur un nœud (srv-mysql-01), en root ; Galera recopie sur les deux autres.

CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Le compte est créé pour l’adresse de HAProxy (10.0.10.5) : les serveurs web passent par le répartiteur, c’est donc lui que voit la base. Mot de passe saisi sans affichage (read -rsp), rangé dans Bitwarden :

GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'10.0.10.5';
GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'10.0.10.5';

Le second droit sert aux fuseaux horaires de GLPI. Ils sont chargés une fois :

mariadb-tzinfo-to-sql /usr/share/zoneinfo | mariadb mysql

Constaté au lab : chargés sur srv-mysql-01, ils ont été recopiés par Galera sur les 3 nœuds (486 fuseaux).

Validation — depuis srv-web-01 : mariadb -h 10.0.10.5 -u glpi -p glpi -e "SELECT USER(), @@hostname" [email protected] et un nom de nœud. 213

4 · Installer GLPI sur le serveur actif

Contexte : srv-web-01, en root. Objectif : GLPI installé, base créée, page de connexion servie.

4.1 PHP

Extensions demandées par GLPI 11 (en plus de celles de WordPress) : bcmath (obligatoire), bz2, opcache, puis mise à jour de PHP (8.4.24 → 8.4.27). Contrôle : php bin/console system:check_requirements après la copie du code 17 prérequis obligatoires OK.

4.2 Le code, vérifié

Archive officielle glpi-11.0.12.tgz (GitHub, glpi-project/glpi), empreinte SHA-256 comparée à celle publiée avant décompression ; décompressée dans /var/www/glpi, propriétaire root.

4.3 Les chemins hors racine web

/var/www/glpi/inc/downstream.php :

<?php
define('GLPI_CONFIG_DIR', '/etc/glpi/');
if (file_exists(GLPI_CONFIG_DIR . '/local_define.php')) {
    require_once GLPI_CONFIG_DIR . '/local_define.php';
}

/etc/glpi/local_define.php :

<?php
define('GLPI_VAR_DIR', '/var/lib/glpi');
define('GLPI_LOG_DIR', '/var/log/glpi');

4.4 Créer les tables (par l’administrateur : il saisit le mot de passe de la base)

cd /var/www/glpi && sudo -u www-data php bin/console database:install --db-host=10.0.10.5 --db-name=glpi --db-user=glpi --default-language=fr_FR

Le mot de passe de la base n’est pas dans la commande : la console le demande (il ne reste ni dans l’historique ni dans la liste des processus).

442 tables InnoDB, toutes avec une clé primaire (Galera l’exige pour recopier), identiques sur les 3 nœuds ; télémétrie refusée. 215.

4.5 Le site Apache

/etc/apache2/sites-available/glpi.conf (HAProxy termine le HTTPS et transmet en HTTP sur le port 80) :

<VirtualHost *:80>
    ServerName glpi.sio.internal
    DocumentRoot /var/www/glpi/public
    php_admin_value max_execution_time 180
    php_admin_value memory_limit 256M
    <Directory /var/www/glpi/public>
        Require all granted
        RewriteEngine On
        RewriteCond %{HTTP:Authorization} ^(.+)$
        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^(.*)$ index.php [QSA,L]
    </Directory>
    SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on
    php_admin_flag session.cookie_httponly on
    php_admin_flag session.cookie_secure on
    php_admin_value session.cookie_samesite Lax
    ErrorLog ${APACHE_LOG_DIR}/glpi-error.log
    CustomLog ${APACHE_LOG_DIR}/glpi-access.log combined
</VirtualHost>

a2ensite glpi && apache2ctl configtest && systemctl reload apache2

cd /var/www/glpi && sudo -u www-data php bin/console config:set url_base https://glpi.sio.internal

Deux sites sur le même Apache : chaque site doit déclarer tous ses noms. Sans ServerAlias www.sio.internal dans wordpress.conf, le site GLPI est devenu le « site par défaut » et a fait tomber WordPress (H-86). Après tout ajout : apache2ctl -S (ligne « default server »), et tester aussi l’application existante.

4.6 Les tâches planifiées de GLPI (actif seulement)

/etc/systemd/system/glpi-cron.service (Type=oneshot, User=www-data, ExecStart=/usr/bin/php /var/www/glpi/front/cron.php) et glpi-cron.timer (OnBootSec=2min, OnUnitActiveSec=1min) :

systemctl daemon-reload && systemctl enable --now glpi-cron.timer

Sur srv-web-01 seulement : deux serveurs qui lancent les mêmes tâches en même temps se gêneraient.

Validation — https://glpi.sio.internal (une fois le §6 fait) page de connexion, puis tableau de bord. 216-218

5 · Le serveur de secours et la recopie des fichiers

Contexte : srv-web-02. Objectif : prêt à servir GLPI à l’identique si srv-web-01 tombe.

sync {
    default.rsyncssh,
    source    = "/var/lib/glpi",
    host      = "[email protected]",
    targetdir = "/",
    delay     = 30,
    delete    = true,
    exclude   = { "_cache/", "_tmp/", "_lock/" },
    rsync = { archive = true, compress = true, protect_args = false, owner = true, group = true, perms = true },
    ssh = { options = { IdentityFile = "/root/.ssh/id_lsyncd_glpi",
                        ControlMaster = "auto", ControlPath = "/root/.ssh/cm-lsyncd-glpi", ControlPersist = "10m" } },
}

Entretien indispensable des sessions (H-89) : Debian désactive le ménage des sessions par PHP (session.gc_probability = 0) et sa tâche sessionclean ignore le dossier de GLPI. Sur les deux serveurs, glpi-sessions-menage.timer efface toutes les 15 min les sessions de plus de 24 min (fichiers scripts/glpi/) :

ExecStart=/usr/bin/find /var/lib/glpi/_sessions -ignore_readdir_race -maxdepth 1 -type f -name sess_* -mmin +24 -delete

Sur srv-web-02 : loginctl enable-linger root (sinon le gestionnaire de session de root redémarre à chaque recopie et remplit le journal : 164 lignes par minute).

Une seule connexion SSH pour toutes les recopies (06/11 soir) : ControlMaster, ControlPath, ControlPersist gardent la connexion ouverte 10 min et la réutilisent ; sans eux, chaque recopie (toutes les 30 s) ouvrait une session SSH sur srv-web-02 et laissait une dizaine de lignes de journal (≈ 1 270 lignes par heure).

Un ControlPath propre à chaque bloc : la clé de GLPI est confinée à /var/lib/glpi (rrsync). Si le bloc WordPress partageait la même connexion ouverte, ses recopies passeraient par la clé de GLPI, donc vers le mauvais dossier. Le bloc WordPress (peu actif) garde des connexions séparées.

Validation — un fichier témoin créé dans /var/lib/glpi sur srv-web-01 apparaît sur srv-web-02 en moins de 30 s. 220

6 · Publier par HAProxy, nommer dans le DNS

Contexte : srv-ha, en root ; copie .avant-glpi de /etc/haproxy/haproxy.cfg avant toute modification ; haproxy -c -f /etc/haproxy/haproxy.cfg puis systemctl reload haproxy.

DNS — glpi → 10.0.10.5 à deux endroits : Host Override de pfSense (zones serveurs) et zone sio.internal de l’annuaire (postes USERS, qui interrogent le contrôleur de domaine). Au passage, www manquait aussi dans la zone de l’annuaire : à ajouter s’il le faut.

Un autre nom publié (ex. Pangolin) doit être rattaché au même pool, sinon il tombe dans le pool du site (alterné entre les deux serveurs) et la connexion échoue (« action non autorisée », H-91) ; et l’API y reste refusée.

Validation — depuis poste-win11 : Resolve-DnsName glpi.sio.internal 10.0.10.5 ; navigateur page de connexion ; https://www.sio.internal toujours le site GSB.

7 · Premiers pas : comptes par défaut, fuseau horaire

Validation — l’avertissement de sécurité a disparu du tableau de bord ; les dates de changement sont lisibles dans la table glpi_users. 219

8 · Prouver le secours : la bascule réelle

1. Connecté à GLPI, créer un ticket avec une pièce jointe.
2. Sur srv-web-01 : systemctl stop apache2.
3. Recharger la page.
4. systemctl start apache2.

Validation (05/11) — HAProxy retire web-01 en 7 s ; srv-web-02 sert GLPI ; l’utilisateur reste connecté (la session a été recopiée), retrouve son ticket et sa pièce jointe (même empreinte sha1 sur les deux serveurs) ; retour à 17:37:32. 225-226

Une bascule n’est prouvée que si l’utilisateur ne voit rien : ni nouvelle connexion, ni fichier manquant.

9 · Superviser, sauvegarder, entretenir

10 · L’inventaire automatique et les tickets d’alerte

11 · Pièges et checklist

 Base glpi (utf8mb4) et compte [email protected] ; fuseaux horaires chargés (et recopiés)
 Archive GLPI vérifiée (SHA-256) ; code root ; /etc/glpi, /var/lib/glpi, /var/log/glpi hors racine web
 database:install : 442 tables InnoDB à clé primaire, sur les 3 nœuds
 Site Apache glpi.conf (public/, réécriture, HTTPS relayé, cookies secure) ; url_base ; WordPress toujours servi
 glpi-cron.timer sur srv-web-01 seulement
 srv-web-02 : même code, même /etc/glpi (empreintes), lsyncd 30 s, ménage des sessions, linger root
 HAProxy : certificat dédié, ACL avant WordPress, API filtrée, pool web-01 + web-02 backup, contrôle /status.php
 DNS : pfSense ET zone de l'annuaire
 Comptes par défaut changés ; fuseau horaire Europe/Paris
 Bascule réelle : utilisateur toujours connecté, pièce jointe retrouvée
 Supervision (sonde, ligne, alertes), export SQL, sauvegarde PBS
 Inventaire (MO-18) et alertes → tickets (MO-23)

La règle à retenir en une phrase : une application à sessions et à fichiers se publie derrière un répartiteur en actif / secours, avec ses fichiers recopiés et ses secrets identiques des deux côtés — et on ne la croit sauvée qu’après une vraie bascule que l’utilisateur n’a pas vue.

12 · Le portail des salariés : connexion par l’annuaire Windows (phase 19)

Contexte. Jusqu’ici seuls l’administrateur et les alertes créaient des tickets. Ce paragraphe ajoute un portail simplifié : le salarié se connecte avec son compte Windows (annuaire Active Directory sio.internal), ouvre un ticket, le suit, valide la solution. Étape 73 de la documentation.

12.1 Prérequis (à vérifier avant de toucher à GLPI)

12.2 Le certificat LDAPS (le lab n’a pas d’autorité de certification)

1. Sur le contrôleur, créer un certificat auto-signé à son nom (New-SelfSignedCertificate -DnsName "AD-Core-01.sio.internal","sio.internal" -CertStoreLocation Cert:\LocalMachine\My, RSA 2048, 5 ans).
2. L’importer aussi dans les autorités racines du contrôleur (Import-Certificate … -CertStoreLocation Cert:\LocalMachine\Root). Sans cela, le journal Directory Service dit « LDAP sur SSL ne sera pas disponible » (8009030e).
3. Installer sa partie publique dans /usr/local/share/ca-certificates/ de chaque serveur web, puis update-ca-certificates.
4. Validation : openssl s_client -connect AD-Core-01.sio.internal:636 affiche Cipher is TLS_AES_256_GCM_SHA384 et Verify return code: 0 (ok). Lire le chiffrement négocié : « Verification: OK » seul peut tromper (Cipher is (NONE) = échec).

12.3 Le compte de liaison et l’annuaire

1. Dans l’AD : un compte CS_glpi_ldap dans une OU Comptes de service, sans aucun groupe (créé désactivé ; l’administrateur saisit le mot de passe avec Read-Host -AsSecureString, puis active le compte).
2. Configuration → Authentification → Annuaires LDAP → Ajouter :

3. Validation : onglet Tester : les 5 étapes passent, « Recherche réussie (6 entrées trouvées) ».

12.4 Les droits : une règle, et la règle « Root » désactivée

• Désactiver la règle « Root » (Administration → Règles → Règles d’affectation d’habilitations à un utilisateur) : par défaut, elle donne l’entité racine à tout compte d’annuaire, donc toute l’arborescence aux salariés.
• Créer une règle : critère Annuaire LDAP = Annuaire sio.internal ; actions Entité = GSB > USERS, Profil = Self-Service, Récursif = Non.
• Importer : https://glpi.sio.internal/front/ldap.php → Importation de nouveaux utilisateurs → Rechercher → cocher → Importer. ( dans cette version, le bouton n’apparaît pas dans la liste des utilisateurs ; l’adresse user.ldap.php n’existe pas.)
• Validation (base GLPI) : chaque compte importé a le profil Self-Service dans GSB > USERS, non récursif, et rien d’autre.

12.5 L’interface du salarié

• Catégories de ticket (aucune n’existe par défaut) : visibles dans l’interface simplifiée, pour un incident et une demande, récursives depuis la racine. Le lab les crée par l’API (glpi-categories-tickets.py).
• Tuiles de la page d’accueil : livrées en anglais ; leur texte se change en base (glpi_helpdesks_tiles_glpipagetiles) ou dans Configuration → Générale → Helpdesk.
• Test final : un ticket ouvert par un salarié, pris en charge par un technicien, solution acceptée par le salarié (c’est lui qui clôt). Un compte hors de l’OU doit être refusé.