j’ouvre cette discussion, ici, parce que je sais que quelques uns d’entre vous ont fait la demande d’un outil de recherche dans les “traces”.
Je sais, par expérience, que l’utilisateur déclare ne pas avoir reçu un message, et donc à vous/moi de rechercher dans les logs.
Je travaille actuellement sur un tel outil, limité dans sa version générique au fichier “mail.log”.
Il n’est pas intégré à Blue-Mind, et pourra être installé sur n’importe quel poste Linux. Il faudra juste un accès aux fichiers de logs.
L’outil, en version alpha, sera proposé d’ici la fin du mois.
En attendant, je vous propose de lister vos attentes sur les fonctionnalités génériques et spécifiques à Blue-Mind.
Ca me sera utile dans le développement de l’outil.
Actuellement, les fonctions déjà développées :
authentification à l’outil via une base locale (sqlite)
recherche dans un fichier mail.log selon un message-id/émetteur/destinataire, et stockage du résultat dans une base locale (sqlite)
Me reste à faire :
afficher le résultat de la recherche (liste de tous les messages)
afficher le détail d’un message (serveur émetteur, date, heure, émetteur, destinataires initiaux, dépôt en BAL si destinataire(s) loca(l|ux))
ce sera dans un second temps. L’immédiat est de pondre un outil accessible dont les fonctions “unitaires” font leur taf sans écrouler la machine.
Après, il faudra déterminer si la recherche se fera dans une “plage” de fichiers, de date. Les 2 se recoupent.
voilà, une première version Alpha est en ligne sur “bm-stats.org”. =D
Elle fournit les bases, à savoir, faire une recherche sur une adresse (complète ou partielle), sur le message-id (complet ou partiel).
Il n’a pas besoin d’être installé sur un serveur BM, mais doit avoir accès fichiers de logs Postfix.
L’interface est encore rudimentaire, et je vais m’y atteler.
Pardon aux Pythonistes, mais ça ne fait même pas un mois que je me suis mis au Python, donc le code n’est pas des plus propres
Je viens de réessayer l’outil, il est plutôt pratique juste quelques détails :
sous redhat/centos, le fichier de log des mails s’appelle maillog et ne peux donc pas être affiché par les filtres du filechooser (il m’a fallu le renommer pour le sélectionner)
je suis tombé sur un problème d’encoding sur mon fichier de log, la lib python-magic n’arrivait pas à retourner le type du fichier et génére une stacktrace :
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "./class/bmTraces.py", line 187, in searchProcess
p.getFileContent()
File "./class/mailLogParser.py", line 91, in getFileContent
self.ftype =ftype = t.getType(self.searchFile)
File "./class/fileMIMEType.py", line 27, in getType
type = self.m.file(file).split(";")[0]
File "/usr/lib/python2.7/dist-packages/magic.py", line 128, in file
return _file(self._magic_t, filename.encode('utf-8'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128)
J’ai modifié /usr/share/bmTraces/class/mailLogParser.py en ligne 91 pour que cela fonctionne :
Une dernière chose je ne suis pas sûr de comprendre par contre l’intérêt des profils et du login/password, car si on a accès à l’outil on a aussi accès aux logs présents sur le pc non ?
merci du retour, je m’y pencherai un peu plus tard.
Je transpose actuellement l’équivalent de bmTraces sur Elasticsearch/Kibana.
Son petit nom bmSearch.
Sinon, j’ai choisi d’intégrer les profils, tout simplement au cas il y aurait plusieurs admin.
Quand tu fais une recherche, les infos sont stockées dans une db sqlite qui porte le nom profil.
Donc si plusieurs personnes se connectent à bmTraces avec le même login/profil, la recherche de l’un va écraser la recherche de l’autre.
Mais je peux supprimer la partie authent. pour ne garder que le choix du profil.
