You are not logged in.
Bonjour,
Dans le cadre d'un ajout de fonctionnalité de ticketing par mail sur le GLPI 10.0.6 de mon entreprise, j'ai créé un "collecteur de mail" qui fonctionne avec brio, cependant avec la volonté de rendre le processus de conversion en ticket automatique, j'ai vu qu'il fallait paramétrer les actions automatiques, plus particulièrement celle nommée "mailgate" et j'ai pus effectivement constater que c'est lié, car lorsque je lance l'action manuellement le processus s'effectue correctement.
Étant à mon premier essai j'ai suivi un tutoriel (le gpli dans l'état n'est pas encore en production) qui recommandait de mettre les actions automatique au mode CLI, et non en mode GLPI comme ça l'était avant, je l'ai donc fait, cependant depuis ce moment j'ai l'impression qu'aucune actions automatique ne s'exécute.
l'action automatique mailgate a les paramètre suivants :
Fréquence d'éxecution : 1 min
Statut : Programmée
Mode d'execution : CLI (GLPI ne fonctionne pas également)
Plage horaire d'execution : 8 -> 18
temps de conservaton des journaux : 30
nombre de courriel à récupérer : 10
À savoir que le GLPI est installé sur une machine debian 11.6 j'ai vu que dans ce cas de figure il fallait éditer la "crontab" du debian, toujours en suivant un tutoriel (rdr.it) voici ce que j'ai ajouté :
PATH=/usr/sbin:/usr/bin:/sbin:/bin
1 * * * * php /var/www/html/glpi/front/cron.php &>/dev/null
De ce fait j'ai plusieurs questions :
Est-ce que le passage en CLI de toutes les actions automatique peut avoir une incidence sur le fonctionnement du glpi ?
Quel est la configuration type de la crontab (debian 11.6) pour cette version de GLPI (fichier cron.php vérifié dans --> /var/www/html/glpi/front/cron.php) ?
En vous remerciant par avance
Cordialement
Last edited by riroyu (2023-05-05 14:31:29)
Offline
salut
quand tu regardes au niveau des actions automatique, meme si le lancement se fait par la crontab, elles ont quand meme une planification/frequences
de plus ca t'indique aussi quand elles se sont executé la dernière fois
a verifier a ce niveau la.
Offline
Bonjour merci pour votre réponse
Oui effectivement c'est grâce à ça que je vois que l'action ne se réalise pas car j'ai réglé une action ciblé (mailgate) à 1 minute d'action, cependant quand je regarde au niveau de la dernière actualisation il n'y a que les manuelles qui apparaissent.
Offline
Bonjour j'ai du nouveau concernant mon problème j'ai bien l'impression qu'il s'agisse d'un problème de droit, en effet j'ai simple essayé de réaliser manuellement la commande suivante sur mon utilisateur root :
php /var/www/html/glpi/front/cron.php &>/dev/null
La commande s'est correctement effectuée et mes actions automatique se sont réalisées.
De ce fait je me pose quelque question :
- Y'a t-il une variante à rajouter dans "crontab -e" qui permet assurément de réaliser la commande en tant que root ? J'ai essayé d'ajouter la variable suivante mais sans succès :
1 * * * * sudo /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/null
- Est-ce que les paramètre de temporalité sont bon ? "1 * * * *" permettent-ils de réaliser la tâche toutes les minutes ?
EDIT : j'ai ajouté mon utilisateur "glpi" qui correspond à mon premier utilisateur de base, autre que root, dans les sudoers, il est capable d'utiliser la commande, et elle s'applique aussi pour ce dernier cependant c'est toujours pareil, ça ne se fait pas de manière automatique
SOLUTION : Il ne s'agissait pas d'une erreur de droit mais d'une erreur dans la crontab même, en effet il fallait changer les "1 * * * *" en "* * * * *" afin que tout se fasse bien chaque minutes. TOUT FONCTIONNE DESORMAIS
Last edited by riroyu (2023-05-09 10:26:01)
Offline
ah oui, j'avais pas vu
1 * * * * = chaque 1ere minutes de chaque heure, chaque jours, etc, et pas toutes les minutes
sinon pour la crontab attention aux droits
soit tu la met dans la crontab de root, et t'es pas embeter
soit crontab d'un user particulier, mais comme tu l'a decouvert, bien attention qu'il puisse acceder aux pages/bdd et executer php
Offline
si la crontab tourne en root, les fichiers de log (php_error.log) seront générés avec root en propriétaire et glpi ne pourra plus écrire
je fais éxécuter mon cron par www-data
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
si la crontab tourne en root, les fichiers de log (php_error.log) seront générés avec root en propriétaire et glpi ne pourra plus écrire
je fais éxécuter mon cron par www-data
L'information est intéressante, comment on s'y prend ? (je débute sur linux)
Offline