Les Plugins se désinstalle désactivent après Minuit (H. serveur)

papifouettard · 2022-06-13 16:45:16

Bonjour à tous,

J'ai un petit soucis avec les plugins qui fonctionnaient jusqu'alors correctement en permanence.

Depuis 2-3mois (j'enquête dessus que maintenant), nos plugins semblent se désinstaller vers minuit (heure du serveur)
Il faut chaque matin :
- réinstall les plugins.
- réactiver les plugins(en activant l'interrupteur).

Plugins fusionInventory & DataInjection concernés, mais pas que (depuis on en a rajouté des nouveaux, le problème est le même.
___
Install GLPI sur Debian Buster. GLPI version 9.5.5

Rien dans les logs ne me semble pertinents.

Je ne sais pas quoi vous dire d'intéressant de plus, pour vous aider à m'aider. Auriez-vous des pistes que je pourrais vérifier ?

papifouettard · 2022-06-13 16:51:35

Operating system: Linux #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64
PHP 7.3.30-1+0~20210826.87+debian10~1.gbpe56a7b fpm-fcgi (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bcmath,
bz2, calendar, cgi-fcgi, ctype, curl, date, dba, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, igbinary, imap,
intl, json, ldap, libxml, mbstring, memcached, msgpack, mysqli, mysqlnd, openssl, pcre, pdo_mysql, posix, readline, session,
shmop, soap, sockets, sodium, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib)
Setup: max_execution_time="3600" memory_limit="2048M" post_max_size="25M" safe_mode="" session.save_handler="files"
upload_max_filesize="25M"
Software: Apache ()
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.115 Safari/537.36
Server Software: MySQL Community Server (GPL)
Server Version: 5.6.10

OK - PHP version is at least 7.2.0 - Perfect!PHP version is at least 7.2.0 - Perfect!
OK - Sessions support is available - Perfect!Sessions support is available - Perfect!
OK - Allocated memory > 64 Mio - Perfect!Allocated memory > 64 Mio - Perfect!
OK - mysqli extension is installedmysqli extension is installed
OK - ctype extension is installedctype extension is installed
OK - fileinfo extension is installedfileinfo extension is installed
OK - json extension is installedjson extension is installed
OK - mbstring extension is installedmbstring extension is installed
OK - iconv extension is installediconv extension is installed
OK - zlib extension is installedzlib extension is installed
OK - curl extension is installedcurl extension is installed
OK - gd extension is installedgd extension is installed
OK - simplexml extension is installedsimplexml extension is installed
OK - intl extension is installedintl extension is installed
OK - ldap extension is installedldap extension is installed
WARN - apcu extension is not presentapcu extension is not present
OK - Zend OPcache extension is installedZend OPcache extension is installed
WARN - xmlrpc extension is not presentxmlrpc extension is not present
WARN - CAS extension is not presentCAS extension is not present
OK - exif extension is installedexif extension is installed
OK - zip extension is installedzip extension is installed
OK - bz2 extension is installedbz2 extension is installed
OK - sodium extension is installedsodium extension is installed
OK - Database version seems correct (5.6.10) - Perfect!Database version seems correct (5.6.10) - Perfect!
WARN - Access to timezone database (mysql) is not allowed.Access to timezone database (mysql) is not allowed.
OK - The log file has been created successfully.The log file has been created successfully.
OK - Write access to /home/production/glpi/files/_cache has been validated.Write access to /home/production/glpi/files/_cache has been validated.
OK - Write access to /home/production/glpi/config has been validated.Write access to /home/production/glpi/config has been validated.
OK - Write access to /home/production/glpi/files/_cron has been validated.Write access to /home/production/glpi/files/_cron has been validated.
OK - Write access to /home/production/glpi/files has been validated.Write access to /home/production/glpi/files has been validated.
OK - Write access to /home/production/glpi/files/_dumps has been validated.Write access to /home/production/glpi/files/_dumps has been validated.
OK - Write access to /home/production/glpi/files/_graphs has been validated.Write access to /home/production/glpi/files/_graphs has been validated.
OK - Write access to /home/production/glpi/files/_lock has been validated.Write access to /home/production/glpi/files/_lock has been validated.
OK - Write access to /home/production/glpi/files/_pictures has been validated.Write access to /home/production/glpi/files/_pictures has been validated.
OK - Write access to /home/production/glpi/files/_plugins has been validated.Write access to /home/production/glpi/files/_plugins has been validated.
OK - Write access to /home/production/glpi/files/_rss has been validated.Write access to /home/production/glpi/files/_rss has been validated.
OK - Write access to /home/production/glpi/files/_sessions has been validated.Write access to /home/production/glpi/files/_sessions has been validated.
OK - Write access to /home/production/glpi/files/_tmp has been validated.Write access to /home/production/glpi/files/_tmp has been validated.
OK - Write access to /home/production/glpi/files/_uploads has been validated.Write access to /home/production/glpi/files/_uploads has been validated.
OK - Write access to /home/production/glpi/marketplace has been validated.Write access to /home/production/glpi/marketplace has been validated.
WARN - Web access to the files directory should not be allowed but this cannot be checked automatically on this instance. Make sure access to error log file (/files/_log/php-errors.log) is forbidden; otherwise review .htaccess file and web server configuration.Web access to the files directory should not be allowed but this cannot be checked automatically on this instance.
Make sure access to error log file (/files/_log/php-errors.log) is forbidden; otherwise review .htaccess file and web server configuration.

cconard96 · 2022-06-13 21:58:15

Bonjour,

Comme cela se produit périodiquement, cela ressemble à une tâche planifiée qui peut la casser.

Si vous utilisez une tâche "cron" pour les actions automatiques de GLPI, veuillez vérifier qu'elle s'exécute en tant qu'utilisateur du serveur Web (exemple : www-data) et non en tant que root.

Ensuite, vérifiez les autorisations de fichier de GLPI pour vous assurer que le serveur Web a accès au lieu de quelque chose appartenant à l'utilisateur root.

papifouettard · 2022-06-14 10:07:39

Bonjour et merci pour le retour.
Je check ça dessuite .

Voici la crontab root du serveur :
0 0 * * * /home/production/glpi/bin/console glpi:ldap:synchronize_users -c -s=2 -f
0 0 * * * /home/production/glpi/bin/console glpi:ldap:synchronize_users -u -s=2 -f

Donc je lance ainsi la sync de l'annuaire n°2, toutes les heures, en création et en update.
ça s'exécute toutes les heures, mais les plugins se désactivent tous les jours donc je ne pense pas que ce soit lié. Par ailleurs, il me semble avoir testé à l'époque avec l'utilisateur de production et ces dernières ne s'exécutaient pas?

Concernant les droits des fichiers du serveur web, on est sur production:production (en -R bien-sûr) sur tous les dossiers de /home/production/glpi (le dossier racine du server web) (géré par php-fpm), chmod700 sur ~/files

Last edited by papifouettard (2022-06-14 10:08:57)

papifouettard · 2022-06-15 14:21:46

Bon j'ai avancé un peu sur le sujet, je n'ai pas de réponse à ma question.

Par contre j'envisage de retenter de basculer les cron sur l'user production. en y ayant réfléchis, pas de raison que ça ne marche pas .

Qui plus est, je vais rajouter deux cron qui devraient fix le problème :
0 0 * * * /home/production/glpi/bin/console glpi:plugins:install
0 0 * * * /home/production/glpi/bin/console glpi:plugins:activate

ça devrait patch le soucis, même si pas ultra quali.
Manque certainement quelques paramètres à mes crons pour qu'elles soient propres, mais je vais chercher ça dans la doc .

Je vous tiendrais au courant si le fix fonctionne. Mais toujours curieux d'une solution long terme.

Edit : je réalise que les crons précédentes que je vous link s'exécute à minuit, tout comme la désactivation des plugins. On peut imaginer que c'est lié vu que les cron étaient sous root, et que le user de production est production. Mais pourquoi la sync des annuaires impacteraient-elles les plugins ? (⊙_⊙;)

Last edited by papifouettard (2022-06-15 14:26:32)

francois-teclib · 2022-06-15 19:20:52

Hello papifouettard,

Le processus interne à GLPI qui désactive les plugins, se déclenche :
- soit au début du processus de mise à jour
- soit lorsque les dossiers des plugins ne sont plus visibles (problème de propriétaire ou droit / dossier disparu ou déplacé / restriction selinux / restriction apparmor / restriction openbasedir, ou autre système de sécurité)

On parle de "visibilité" de la part :
- soit de l'utilisateur qui porte le processus Apache, et donc quand on navigue en mode WEB dans GLPI (ou la page de login) les plugins se désactivent
- soit en CLI par l'utilisateur qui exécute une commande de la console (peu importe la commande)
- soit en CLI par l'utilisateur qui fait appel à front/cron.php (pour lancer les Actions automatiques paramétrées en mode "CLI")

De ce fait, il est clairement conseillé que : l'utilisateur qui porte le processus Apache/PHP, soit le même que celui qui est utilisé pour lancer la bin/console, et le même que celui qui fait appel à front/cron.php.

Cela concerne aussi les droits d'écriture sur le dossiers "files" (/var/lib/glpi/), il faut que l'utilisateur autorisé en écriture soit aussi le même.

Une erreur classique c'est un lancement de la console CLI de GLPI en root (aïe), qui du coup vient écrire dans files/_log/ en root, ou écrire le files/_cache/ en root. Et la c'est les problèmes assurés derrière quand l'utilisateur WEB viendra essayer d'accéder à ces répertoires essentiels ou tenter d'écrire dans ces fichiers (appartenant à root).

J'imagine que votre problème se situe donc bien de ce côté là : il faut bien vérifier que votre utilisateur "production", puisse lire les dossiers des plugins dans tous les cas (web, bin/console, cron).

Vous ne devriez pas avoir besoin de faire une crontab plugins:activate (même si c'est une solution de contournement), et encore moins "plugins:install" ! (le process d'installation de plugin se relancerait).

++

papifouettard · 2022-06-20 10:04:34

Bonjour François et merci pour le retour détaillé .

Je n'ai pas pris le temps de répondre vendredi mais j'ai finalement été convaincu que c'était bien le pb (que certains fichiers s'écrivent en root:root et que ça casse le serveur).

Ceci dit : je n'ai pas pu exécuter les commande de la console, synchronisant notre répertoire ldap, avec le user production. Je suppose après que ça vient de la conf linux de ce user (pas sudoer, etc..)

J'ai donc fait le bourrin et :
-exécuté ma crontab en root
- appliqué prod:prod au dossier glpi à la fin.
Voici ma crontab fonctionnelle du coup :

2 0 * * * /home/production/glpi/bin/console glpi:ldap:synchronize_users -c -s=3 -f
2 0 * * * /home/production/glpi/bin/console glpi:ldap:synchronize_users -u -s=3 -f
2 0 * * * /home/production/glpi/bin/console glpi:plugin:install "*" --username glpi
3 0 * * * /home/production/glpi/bin/console glpi:plugin:activate "*"
4 0 * * * chown -R production:production /home/production/glpi

___
Par ailleurs, comme vous voyez, il m'a fallut spécifier un compte glpi pour "install" les plugins avec la console. Je supposeque c'est côté web, pour les droits d'install plugin. Est-ce que ça craint d'avoir spécifié le default super-admin "glpi" pour cela ?

Merci en tout cas pour le coup de main, je ferme le ticket dans quelques jours vu que le problème principale est résolu!

francois-teclib · 2022-06-21 14:38:43

Hello papifouettard,

Super si vous avancez !

"je n'ai pas pu exécuter les commande de la console, [...], avec le user production"

Cela vient probablement du manque du droit "exécution" sur le fichier bin/console (chmod +x), plutôt que de faire le call :

2 0 * * * /home/production/glpi/bin/console glpi:ldap:synchronize_users -c -s=3 -f

Dans la crontab de votre user "production", en indiquant le chemin vers le binaire php correct de votre serveur:

2 0 * * * cd /home/production/glpi/ && /usr/bin/php bin/console glpi:ldap:synchronize_users -c -s=3 -f

Et tout devrait mieux se passer

Clairement il ne faut pas lancer "glpi:plugin:install" dans la crontab, vous allez au devant d'autres problèmes (consistance des données dans la base).

Pour l'option "--username" oui c'est bien pour "simuler" en CLI le fait que vous soyez connecté avec un utilisateur (comme une installation dans l'interface) : vous devez donc indiquer un compte super-admin.

++

Forum GLPI-Project

Announcement

#1 2022-06-13 16:45:16

Les Plugins se désinstalle désactivent après Minuit (H. serveur)

#2 2022-06-13 16:51:35

Re: Les Plugins se désinstalle désactivent après Minuit (H. serveur)

#3 2022-06-13 21:58:15

Re: Les Plugins se désinstalle désactivent après Minuit (H. serveur)

#4 2022-06-14 10:07:39

Re: Les Plugins se désinstalle désactivent après Minuit (H. serveur)

#5 2022-06-15 14:21:46

Re: Les Plugins se désinstalle désactivent après Minuit (H. serveur)

#6 2022-06-15 19:20:52

Re: Les Plugins se désinstalle désactivent après Minuit (H. serveur)

#7 2022-06-20 10:04:34

Re: Les Plugins se désinstalle désactivent après Minuit (H. serveur)

#8 2022-06-21 14:38:43

Re: Les Plugins se désinstalle désactivent après Minuit (H. serveur)

Board footer