je vois déjà un problème lié au (r)syslog. Le fichier mail.log est vide.
Je peux savoir ce que vous avez déplacé?
Les données sont stockées dans :
“/var/lib/bm-stats/” pour les données issues de bm-stats
“/var/log/mail” pour les archives légales des fichier “mail.log”
Une première piste est déjà de vérifier si la rotation du fichier mail.log se correctement.
Pour cela, il faut lancer (avec les droits qui vont bien) le fichier : /usr/share/bm-stats/scripts/SHELL/MailLogRotate.sh
Et ensuite regarder si le fichier s’alimente correctement.
Nous avons déplacé les mails et la archives voici le contenu du répertoire data :
administrateur@srv-bluemind:/data$ ls -l
total 32
drwxr-xr-x 3 root root 4096 mars 13 2015 archive
drwxr-xr-x 5 root root 4096 juin 14 22:00 backups
drwxr-xr-x 4 root root 4096 mars 13 2015 elasticsearch
drwx------ 2 root root 16384 mars 13 2015 lost+found
drwxr-xr-x 6 root root 4096 sept. 20 2015 mail
J’ai lancé ou relancé le MailLogRotate.sh :
administrateur@srv-bluemind:/var/lib/bm-stats/domaine.com$ sudo sh /usr/share/bm-stats/scripts/SHELL/MailLogRotate.sh
[sudo] password for administrateur:
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service rsyslog restart
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop rsyslog ; start rsyslog. The restart(8) utility is also available.
rsyslog stop/waiting
rsyslog start/running, process 6878
Combien de temps avant de voir si les premières données remonte dans l’interface BMStats ? EDIT : j’imagine que je vais déjà voir le fichier mail.log se renseigner.
Normalement, au bout de 5 minutes si le fichier mail.log s’alimente correctement.
Pour les données générales, ce sera demain. Toutes les grosses opérations se faisant de nuit.
Default logging rules can be found in /etc/rsyslog.d/50-default.conf
#################
MODULES
#################
$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog # provides kernel logging support (previously done by rklogd)
#$ModLoad immark # provides --MARK-- message capability
provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514
provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514
Enable non-kernel facility klog messages
$KLogPermitNonKernelFacility on
###########################
GLOBAL DIRECTIVES
###########################
Use traditional timestamp format.
To enable high precision timestamps, comment out the following line.
En fait, le fichier mail.log n’a pas les bons droits. Il doit appartenir à syslog.
Donc, avec les droits d’admin :
chown syslog /var/log/mail.log
service rsyslog restart
Normalement, le fichier devrait s’alimenter
Ensuite, selon vos procédures relatives aux changements :
*) remplacer le fichier “/usr/share/bm-stats/scripts/SHELL/MailLogRotate.sh” par celui disponible à cette adresse http://bm-stats.org/MailLogRotate.sh
et le rendre exécutable (chmod +x /usr/share/bm-stats/scripts/SHELL/MailLogRotate.sh)
Depuis ce matin toutes les statistiques remontent a nouveau dans la console BMStat, merci beaucoup.
Une dernière chose, la seul statistique qui n’a pas été remonté est “Top Disk Occupation” toutes les valeurs restent à zéro. Savez vous sur quel(s) fichier(s) se base cette statistique ? et comment faire pour qu’elle soit à nouveau renseignée ?
EDIT :
Autre chose en faite je viens de me rendre compte ce matin que les statistiques n’étaient plus collectées à partir de 00h, et en vérifiant mon fichier /var/log/mail.log, il a repris les droit d’origine a savoir root en propriétaire… J’ai effectué à nouveau la modification à la main mais je ne comprend pourquoi les droits se sont modifier.
J’ai a priori encore besoin de vos lumières
Merci
EDIT#2 :
Entre temps j’ai installé la dernière version et mis a jour le fichier MailLogRotate.sh
l’ancienne version du script “MailLogRotate” ne reprenait pas les infos de propriétés, et recréait un fichier par et pour “root”.
Donc si tu as réaffecté le bon proprio au fichier, l’info sera reprise pour la rotation de cette nuit.
Sinon, en 3.x.9, j’ai désactivé la surveillance des dossier Cyrus (stockage des messages). Le script lancé toutes les 5 minutes faisait tombé les serveurs contenant plusieurs milliers de comptes. Je vais faire en sorte de pouvoir l’activer pour ceux qui le souhaitent.
Enfin, tu pourrais me faire passer une copie du graphe en question, que je me remémore de quoi il s’agit (mémoire de poisson rouge).
Mon email pour ceux qui ne le sauraient pas encore : pascal.salaun[at]laposte.net
Pascal
PS : je ne suis pas un adepte du “vous”, mais alors pas du tout.
j’ai presque fini le portage de bm-stats sur BM 3.5.x.
Tous les appels SOAP on été ré-écrit en REST.
Je rencontre juste un problème de paquet fourni par BM. Il concerne “php-cli” sur lequel je m’appuie pour faire toutes les tâches de backoffice (graphes, rapports…).
BM en fournit un, mais il est vide. Je peux en fournir un paquet .deb intermédiaire, mais je n’ai pas envie de mettre le b.del non plus
juste quelques lignes pour vous dire où j’en suis.
Pour info, je travaille sur une VM Debian8 avec BM3.5.4.
Je rencontre toujours quelques problèmes concernant la génération des images (graphes) à la volée. Il s’agit des graphes relatifs aux utilisateurs.
Le packaging de PHP GD opéré par BM ne contient pas l’“option” FreeType, et pChart en a besoin.
Pour celles et ceux qui le veulent,je peux toujours vous fournir les 2 paquets Debian pour vos qualifs.
Vous n’avez qu’à me le faire savoir.
à cette heure d’apéro, je vous annonce que je viens de porter bm-stats sur BM35, enfin !
Je vous mettrai à disposition les 2 paquets, celui de bm-stats et un add-on (php-cli) ce dimanche 16 juillet 2017.
Avec l’API REST, on peut maintenant faire pas de chose,donc si vous voulez des trucs en plus, faites-le savoir.
pour celles et ceux qui voudrait installer cette nouvelle version adapte à BM3.5, voici les commandes à passer, depuis votre serveur, avec un compte ayant les droits suffisants :
