Étiquette : PHP

Centreon vous déconnecte au bout de quelques minutes ou d’une poignée d’heures d’inactivité ? Ce tutoriel montre, pas à pas, comment porter la durée des sessions à plusieurs heures ou plusieurs jours — sous Debian comme sous RHEL/Rocky/AlmaLinux. Le point important : il faut agir sur deux couches, et la seconde recèle un piège qui fait échouer la plupart des réglages.

Deux sessions, pas une

Quand Centreon vous déconnecte, la durée réellement appliquée est celle du maillon le plus court parmi :

• Le timeout applicatif Centreon — le paramètre session_expire, réglable dans l’interface. Par défaut 120 minutes (2 heures).
• La session PHP — Centreon est servi par php-fpm ; si PHP purge le fichier de session avant, vous êtes déconnecté, quelle que soit la valeur côté Centreon. C’est ici que se cache le piège.
• Un éventuel proxy d’authentification (SSO/reverse proxy devant Centreon) — il a lui aussi sa propre durée de session à aligner.

Régler l’un sans l’autre ne sert à rien : il faut que les deux (voire trois) couches dépassent la durée voulue.

Rappel d’unités : minutes ou secondes ?

Piège classique : les deux couches n’utilisent pas la même unité. Centreon (session_expire) se règle en minutes, tandis que PHP (gc_maxlifetime, cookie_lifetime) se règle en secondes. Une même durée s’écrit donc de deux façons différentes :

Le calcul pour les valeurs « 30 jours » utilisées plus bas : côté PHP, 30 × 24 × 3600 = 2 592 000 secondes ; côté Centreon, 30 × 24 × 60 = 43 200 minutes.

Étape 1 — Le timeout applicatif Centreon

Dans l’interface : Administration → Paramètres → Centreon UI, champ « Durée d’expiration de session » (session_expire), exprimé en minutes. Exemples : 10080 pour 7 jours, 43200 pour 30 jours.

En ligne de commande, la valeur est stockée dans la table options :

-- 30 jours = 43200 minutes
UPDATE options SET `value` = '43200' WHERE `key` = 'session_expire';

Attention : ce réglage seul ne suffit pas. Si la couche PHP purge la session à 24 minutes, vous serez déconnecté à 24 minutes malgré ce paramètre. Passons donc au vrai nerf de la guerre.

Étape 2 (Debian) — La session PHP

Sous Debian, la garbage collection probabiliste de PHP est désactivée (session.gc_probability = 0). Le ménage est confié à un script système, /usr/lib/php/sessionclean, déclenché toutes les 30 minutes par un timer systemd. Et c’est là que ça se corse.

1. Poser les réglages dans un module dédié

On crée un fichier propre (adaptez 8.2 à votre version PHP). Ici, 30 jours :

cat > /etc/php/8.2/mods-available/centreon-session.ini <<'EOF'
; Session Centreon longue — durée serveur et cookie (en secondes)
session.gc_maxlifetime  = 2592000   ; 30 jours (30 x 24 x 3600)
session.cookie_lifetime = 2592000   ; 30 jours
EOF

2. Activer le module sur TOUTES les SAPI (l’étape qu’on oublie)

Centreon tourne sous php-fpm, mais le nettoyeur, lui, regarde toutes les SAPI (fpm, cli et apache2). Il faut donc activer le réglage partout :

phpenmod -v 8.2 centreon-session

# Vérifier les liens : les trois SAPI doivent apparaître
ls -l /etc/php/8.2/*/conf.d/*centreon-session*

Si une SAPI manque — souvent apache2, qui reste au défaut de 24 minutes — créez le lien à la main :

ln -sf /etc/php/8.2/mods-available/centreon-session.ini \
       /etc/php/8.2/apache2/conf.d/50-centreon-session.ini

3. Vérifier la valeur effective, SAPI par SAPI

Ne vous fiez pas au php.ini : mesurez ce que verra réellement sessionclean. Les trois lignes doivent afficher la même durée longue :

for sapi in apache2 fpm cli; do
  eff=$(PHP_INI_SCAN_DIR=/etc/php/8.2/$sapi/conf.d/ \
        php8.2 -c /etc/php/8.2/$sapi/php.ini \
        -r 'echo ini_get("session.gc_maxlifetime")," / ",session_save_path();')
  echo "$sapi : $eff"
done

apache2 : 2592000 / /var/lib/php/sessions
fpm     : 2592000 / /var/lib/php/sessions
cli     : 2592000 / /var/lib/php/sessions

Si une SAPI affiche encore 1440 (24 minutes) sur ce même dossier, c’est elle qui purgera tout à 24 minutes — même si les autres sont à 30 jours.

4. Redémarrer php-fpm

systemctl restart php8.2-fpm

La purge serveur est corrigée dès le prochain passage du timer (aucun redémarrage requis pour cet aspect), mais le redémarrage est nécessaire pour que le nouveau cookie_lifetime s’applique aux nouveaux cookies.

Le piège qui fait tout échouer

Le timer exécute /usr/lib/php/sessionclean, qui itère sur toutes les SAPI. Pour chacune, il calcule la durée effective et son save_path, puis lance indépendamment :

find "$save_path" -depth -mindepth 1 -name 'sess_*' -type f -cmin "+$duree_minutes" -delete

Or apache2, fpm et cli partagent le même /var/lib/php/sessions. Si une seule est restée à 24 min (typiquement apache2, car libapache2-mod-php est souvent installé en dépendance), cette entrée efface tout le dossier commun toutes les 30 minutes — y compris les sessions Centreon servies par php-fpm. C’est pourquoi régler « seulement fpm » ne marche jamais. À noter aussi : un php_value[session.gc_maxlifetime] mis dans le pool FPM de Centreon n’a aucun effet ici, car sessionclean lit le php.ini + conf.d de la SAPI, pas le pool.

Étape 2 (RHEL / Rocky / AlmaLinux) — La session PHP

La famille RHEL ne suit pas la même logique : pas de sessionclean ni de timer. Le nettoyage est assuré par la garbage collection probabiliste native de PHP (gc_probability = 1, gc_divisor = 1000 par défaut), exécutée pendant les requêtes. C’est le php-fpm de Centreon lui-même qui purge, avec sa valeur — donc pas de piège multi-SAPI par timer.

1. Poser les réglages

Globalement dans /etc/php.d/zz-centreon-session.ini (valeurs en secondes) :

session.gc_maxlifetime  = 2592000   ; 30 jours
session.cookie_lifetime = 2592000   ; 30 jours

…ou ciblé dans le pool /etc/php-fpm.d/centreon.conf :

php_value[session.gc_maxlifetime]  = 2592000   ; 30 jours
php_value[session.cookie_lifetime] = 2592000

2. Redémarrer (obligatoire ici)

systemctl restart php-fpm

Vérifiez au passage les permissions de /var/lib/php/session : si php-fpm ne peut pas y supprimer les fichiers, la GC échoue silencieusement. Et si httpd/mod_php coexiste avec php-fpm sur le même save_path, le même piège de dossier partagé peut réapparaître.

Vérifier que ça marche

• Test réel : connectez-vous à Centreon, laissez l’onglet inactif plus longtemps que l’ancien plancher (30-40 min), puis rechargez une page. Vous devez rester connecté.
• Âge des sessions : après plus de 24 min d’inactivité, les fichiers doivent toujours être là : ls -l /var/lib/php/sessions/.
• Debian : forcez le nettoyeur et vérifiez qu’il ne supprime rien : systemctl start phpsessionclean.service.

Debian vs RHEL — récapitulatif

Bonnes pratiques

• Régler les deux couches : session_expire côté Centreon et la session PHP côté serveur.
• Mesurer la valeur effective par SAPI — jamais se fier au seul php.ini.
• Toutes les SAPI partageant un save_path sont gouvernées par la durée la plus courte.
• Aligner gc_maxlifetime et cookie_lifetime sur la même valeur.
• Tester en inactivité, pas en cliquant — sinon le plancher réel reste masqué.
• Si Centreon est derrière un SSO/reverse proxy, aligner aussi la durée de session de ce dernier.

Une fois le bon réflexe acquis — régler les deux couches et vérifier l’effectif sur toutes les SAPI — porter une session Centreon à 30 jours tient en quelques lignes. Le plus dur, c’est de savoir où regarder.