You are not logged in.
Pages: 1
Bonjour,
Après avoir installé GLPI 0.71.3 sous Solaris 10 avec Apache2 et PHP5,
j'ai voulu tirer parti de la passerelle de messagerie en l'interconnectant avec notre serveur IMAP.
Afin que les mails soient intégrés comme tickets le plus rapidement possible, j'ai pris soin d'ajouter l'exécution de cron.php par le véritable démon cron.
Cependant, malgré cela, les logs de GLPI traduisent une exécution plutôt aléatoire de ce script (alors que les intervales d'exécution sont toutes les 5 minutes).
J'ai également modifié la valeur pour mailgate à 180 dans cron.class.php mais ça n'a rien changé.
Je me demande du coup si l'exécution du script par cron fait quelque chose...
On dirait que les seules exécutions sont celles liées au pseudo-cron de l'interface.
Des idées, des pistes ?
Merci et bonne année !
EDIT:
Voici un extrait du cron.log :
$ grep -B 1 'Launch mailgate' /media/disk/GLPI/cron.log |tail -30
--
2008-12-24 13:14:16
Launch mailgate
--
2008-12-24 13:47:46
Launch mailgate
--
2008-12-26 09:22:53
Launch mailgate
--
2008-12-29 11:03:19
Launch mailgate
--
2008-12-30 08:41:06
Launch mailgate
--
2008-12-30 10:21:55
Launch mailgate
--
2008-12-30 13:29:10
Launch mailgate
--
2008-12-30 14:11:17
Launch mailgate
--
2008-12-30 14:31:34
Launch mailgate
--
2008-12-30 15:17:41
Launch mailgate
Last edited by surcouf (2008-12-30 19:33:02)
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Il semblerait que le problème soit lié à mon utilisateur apache (nobody) avec lequel le script n'a pas l'air de faire grand chose bien qu'aucune erreur apparente ne soit relevée...
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
ne pas oublie qu'en plus de votre cron système le pseudo cron GLPI fonctionne toujours et peux passer avant le cron système
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
ne pas oublie qu'en plus de votre cron système le pseudo cron GLPI fonctionne toujours et peux passer avant le cron système
En effet, les exécutions relevées dans les logs semblent être celles du pseudo-cron.
Aujourd'hui, j'ai créé un nouvel utilisateur (apache) pour Apache2.
Différence notable avec nobody, cet utilisateur n'est pas locké d'un point de vue shadow.
Sinon, il n'a pas le droit de faire grand chose...
Je n'ai par pu pallier le problème qu'en ré-écrivant un second script (nommé cron-mailgate.php) qui instancie uniquement la tâche mailgate avec la classe Cron.
En outre, malgré tout mes efforts, j'ai dû ajouter une commande cd pour me déplacer dans le répertoire front/ avant l'exécution du script sans quoi, cela ne fonctionne pas...
Même en redéfinissant la constante GLPI_ROOT.
Bonne année à tous et merci.
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Sous Debian ou Ubuntu et d'autres distribution l'explication donnée sur le wiki fonctionne (http://glpi-project.org/wiki/doku.php?i … ig:crontab)
J'ai du mal à comprendre pourquoi ça pose tant de souci sur Solaris.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Sous Debian ou Ubuntu et d'autres distribution l'explication donnée sur le wiki fonctionne (http://glpi-project.org/wiki/doku.php?i … ig:crontab)
J'ai du mal à comprendre pourquoi ça pose tant de souci sur Solaris.
Disons que je ne comprends pas comment le pseudo-cron établit sa liste de tâches.
J'aimerais qu'il vérifie les boîtes aux lettres de façon prioritaire, à chaque exécution.
Je ne sais pas comment font les autres utilisateurs de GLPI mais nous utilisons intensivement la messagerie comme création de demandes, qu'elles soient liées à l'inventaire ou pas. Nos utilisateurs sont souvent géographiquement éloignés.
PS : Solaris a beau être un système Unix, ce n'est pas Linux. Malgré tout, j'aimerais bien comprendre.
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Si vous voulez vous rapprocher le plus d'une exécution régulière :
Il faut appeler dans votre crontab la page front/cron.php toutes les minutes
et éventuellement modifier le fichier cron.class.php variable $this->taches["mailgate"]=600;
et la passer à 120 par exemple.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Si vous voulez vous rapprocher le plus d'une exécution régulière :
Il faut appeler dans votre crontab la page front/cron.php toutes les minutes
et éventuellement modifier le fichier cron.class.php variable $this->taches["mailgate"]=600;
et la passer à 120 par exemple.
J'ai essayé mais les résultats ne sont guère probants mais sans doute parce qu'un détail a changé depuis mes congés.
N'y a-t-il point moyen d'instancier directement la classe Mailgate pour l'exécuter ?
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Pas pour le moment.
En fait c'est une fonctionnalité prévue. CF roadmap https://dev.indepnet.net/glpi/ticket/961
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Par conscience professionnelle, j'ai repris mes tests sur la machine Linux qui m'a servi de plate-forme d'intégration et, sans modifier le code de GLPI, la tâche mailgate exécutée par cron (via cron.php) toutes les 5 minutes importe bien les mails régulièrement.
Je ne comprends pas ce que l'environnement Solaris peut avoir comme influence sur le fonctionnement du cron.php...
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Finalement, la mailgate fonctionne à nouveau sous Solaris.
Il semblerait que certains mails bloquent le fonctionnement de la mailgate.
Y aurait-il de quelconques limites dans l'analyse des mails ? En l'occurence, le seul détail frappant pour celui-ci est la présence de deux pièces jointes...
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Le bogue se confirme en isolant l'une des deux pièces jointes.
La pièce jointe ne pèse pourtant que 1,3 Ko et ne contient que du texte.
J'essaie de voir si je peux masquer les parties sensibles pour l'analyse.
Par ailleurs, les forwards par pièces jointe créent des tickets totalement vides.
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
J'ai pu extraire les données sensibles du fichier et ce dernier demeure toujours bloquant.
Est-ce que quelqu'un peut confirmer le problème ?
http://www.sharefile.org/showfile-619/pbsynchro_timestamps_20090105_002.txt
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Pour les forwards par pièce jointe, cela me semble normal, le parseur ne sais pas ouvrir ces fichiers (eml etc...)
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
J'ai peur de n'avoir pas bien saisi, il correspond à quoi votre fichier ?
Si tu suis le lien publié précédement, à un « bête » fichier texte d'une vingtaine de lignes...
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Oui je l'ai ouvert votre fichier avant de poser ma question
Mais bon j'ai relu attentivement vos explications précédentes et j'ai sais de quoi il en retournait.
Bref j'ai fait le test et ça fonctionne parfaitement. La réception par GLPI d'un mail avec votre fichier joint, crée un ticket avec le fichier en document associé sans problème.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Oui je l'ai ouvert votre fichier avant de poser ma question
Mais bon j'ai relu attentivement vos explications précédentes et j'ai sais de quoi il en retournait.
Bref j'ai fait le test et ça fonctionne parfaitement. La réception par GLPI d'un mail avec votre fichier joint, crée un ticket avec le fichier en document associé sans problème.
Peux-tu me transmettre, en pièce jointe, le mail que tu t'es envoyé ?
De mon côté, les essais sont toujours négatifs : le moindre mail avec cette pièce jointe bloque immédiatement la mailgate...
Raphaël 'SurcouF' Bordet
GLPI 0.80
Apache 2 / Debian 6
Offline
Pages: 1