J’ai migré notre plateforme Zarafa vers Bluemind. Notre nouvelle plateforme Bluemind est actuellement en version 3.5.3 et est hébergé sur une VM de type KVM tournant sous Debian 8.1 (RAM 8Go, 4 CPU).
J’ai activé l’archivage pour la BAL d’un utilisateur dans son profil. J’ai réglé “Nombre de jours avant archivage:” à 182 jours et j’ai coché les 5 dossiers présents dans le paramètre “Dossiers exclus de l’archivage”.
Lorsque l’on observe la BAL de cet utilisateur, on s’aperçoit que seuls quelques mails ont été archivés. la plupart des e-mails qui ont le critère (+ de 182 jours) pour être archivé ne le sont pas !
J’ai regardé dans les logs et particulièrement core.log…j’ai vu cela:
...
...
2017-03-05 12:06:01,207 [pool-13-thread-3] n.b.h.j.HSMJob WARN - Fail to process user tdupond, check core logs for more informations
net.bluemind.core.api.fault.ServerFault: [mailbox:acls-AC791D26-EE0B-435E-896A-DED517CFC16D] folder with uri imap://user/tdupond@mondomaine.fr/Partenaires-Contacts-fournisseurs/3gk not found.
at net.bluemind.core.api.fault.ServerFault.notFound(ServerFault.java:75) ~[net.bluemind.core.commons_3.1.20985.jar:na]
at net.bluemind.folder.service.internal.FolderHierarchyService.byContentUri(FolderHierarchyService.java:180) ~[net.bluemind.folder.service_3.1.20985.jar:na]
at net.bluemind.hsm.processor.FolderProcessor.process(FolderProcessor.java:72) ~[net.bluemind.hsm.processor_3.1.20985.jar:na]
at net.bluemind.hsm.processor.MailboxProcessor.process(MailboxProcessor.java:91) ~[net.bluemind.hsm.processor_3.1.20985.jar:na]
at net.bluemind.hsm.job.HSMJob.process(HSMJob.java:191) [net.bluemind.hsm.job_3.1.20985.jar:na]
at net.bluemind.hsm.job.HSMJob.archiveUserMailboxes(HSMJob.java:171) [net.bluemind.hsm.job_3.1.20985.jar:na]
at net.bluemind.hsm.job.HSMJob.run(HSMJob.java:135) [net.bluemind.hsm.job_3.1.20985.jar:na]
at net.bluemind.hsm.job.HSMJob.tick(HSMJob.java:119) [net.bluemind.hsm.job_3.1.20985.jar:na]
at net.bluemind.scheduledjob.scheduler.impl.JobTicker.run(JobTicker.java:63) [net.bluemind.scheduledjob.scheduler_3.1.20985.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_72]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_72]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
2017-03-05 12:06:01,207 [pool-13-thread-3] n.b.s.s.i.Scheduler WARN - [RunIdImpl [domainName=mondomaine.fr, jid=net.bluemind.hsm.job.HSMJob, startTime=1488715560751, endTime=1488715560751, groupId=8f9090d6-785b-4dc2-82bb-8a1337909157, status=IN_PROGRESS]] [fr] => Erreur lors du traitement de l'utilisateur tdupond: [mailbox:acls-AC791D26-EE0B-435E-896A-DED517CFC16D] folder with uri imap://user/tdupont@mondomaine.fr/Partenaires-Contacts-fournisseurs/3gk not found.
...
...
Pourtant le dossier qui pose problème (Partenaires-Contacts-fournisseurs/3gk) existe bien dans la BAL de l’utilisateur !
L’utilisateur utilise Icedove (Thunderbird sous Debian) version 45.6.0 comme client lourd et il y a une erreur en bas de fenêtre qui indique “Synchronisation Bluemind terminée avec erreur: TypeError: directory is null”
Et voilà ce qu’il y a dans le log du connecteur:
...
...
[ERROR][2017-03-06T09:45:50.673Z]BMContainerService: TypeError: directory is null
...
...
Avec la même BAL, l’erreur “TypeError: directory is null” semble ne pas se produire sous Thunderbird version 45.7.1 pour Windows.
Aussi, depuis l’interface d’administration, la tâche HSMjob est marqué comme OK (vert) mais affiche 0 seconde en temps d’exécution !
[quote=tikok974]
L’utilisateur utilise Icedove (Thunderbird sous Debian) version 45.6.0 comme client lourd et il y a une erreur en bas de fenêtre qui indique “Synchronisation Bluemind terminée avec erreur: TypeError: directory is null”
Et voilà ce qu’il y a dans le log du connecteur:
...
...
[ERROR][2017-03-06T09:45:50.673Z]BMContainerService: TypeError: directory is null
...
...
Avec la même BAL, l’erreur “TypeError: directory is null” semble ne pas se produire sous Thunderbird version 45.7.1 pour Windows.
Aussi, depuis l’interface d’administration, la tâche HSMjob est marqué comme OK (vert) mais affiche 0 seconde en temps d’exécution !
Quelqu’un pourrait m’aider SVP ?
Merci.[/quote]
Bonjour à tous,
J’ai tenté de réinitialiser les données locales vi le bt du connecteur BM prévu à cet effet … cela n’a rien donné !
J’ai supprimé manuellement le répertoire local dans le profil Icedove (~/.icedove/xxx.default/storage/default/https+++server.domain.tld) mais cela n’a pas résolu le problème !
Est-ce que c’est un Bug du connecteur BM sous Icedove 45.6.0 ?
Pour la partie archivage, le problème vient d’une désynchronisation de la liste des dossiers de l’utilisateur, vous pouvez corriger le problème depuis la fiche de l’utilisateur, onglet maintenance puis ‘Valider et réparer l’utilisateur’.
Des problèmes de désynchronisation ont été résolus en 3.5.4 qui sort ce soir ou demain.
[quote=aaujon]Pour la partie archivage, le problème vient d’une désynchronisation de la liste des dossiers de l’utilisateur, vous pouvez corriger le problème depuis la fiche de l’utilisateur, onglet maintenance puis ‘Valider et réparer l’utilisateur’.
Des problèmes de désynchronisation ont été résolus en 3.5.4 qui sort ce soir ou demain.[/quote]
Bonjour Arnaud,
Merci beaucoup pour ta réponse, je vais lancer la réparation et voir si c’est OK.
Bonne fin de journée.
J’ai relancé manuellement la tâche HSMjob pour forcer l’archivage et malheureusement j’ai toujours un message d’erreur identique à ci-dessus.
La “Validation et réparation” du compte n’a malheureusement pas résolu le problème.
J’attendrai la sortie de la 3.5.4 pour voir si le problème persiste.
Le check&repair aurait du corriger le problème, il n’y a pas de logs quand tu exécutes la réparation de l’utilisateur ?
Dans la base de données que te renvoie la commande :
select * from t_folder where content_uri like '%tdupond%';
Le log n’est pas très causant lorsque l’on faite le check&repair !
Il y a juste ça:
Oui le login est juste.
Alors très intéressant cette petite recherche dans la DB. En fait, le dossier concerné “imap://user/tdupond@mondomaine.fr/Partenaires-Contacts-fournisseurs/3gk” est encore noté dans la DB à son ANCIEN emplacement !!! …
le “content_uri” dans la DB est faux car le dossier à été déplacé par l’utilisateur un cran au dessus…c’est à dire juste en dessous de INBOX.
Dans la DB le “content_uri” est “imap://user/tdupond@mondomaine.fr/import-zarafa/INBOX/Partenaires-Contacts-fournisseurs/3gk” alors qu’il devrai plutôt être “imap://user/tdupond@mondomaine.fr/Partenaires-Contacts-fournisseurs/3gk” !
Lors du processus de migration de l’ancien système de mail Zarafa vers Bluemind, j’avais (pour chaque utilisateur) migré leurs mails (avec l’outil Imapsync) dans un dossier spécifique appelé “import-zarafa”. Puis, je leur ai demandé, lorsqu’ils ont un moment, de faire le trie de leur boîte pour ne garder que l’essentiel (histoire de ne pas commencer à surcharger inutilement le nouveau serveur Bluemind). Donc, c’est ce qu’ils ont commencé à faire.
Mais visiblement…dans la DB Postgresql de Bluemind…le chemin n’est pas mis à jour comme il faut !!!
J’ai commencé à faire le tour pour vérifier l’Outlook ou Thunderbird des utilisateurs. Certains ont même déjà fini le tri et supprimé le dossier “import-zarafa” mentionné ci-dessus.
Dans Outlook ou thunderbird c’est juste. J’ai vérifié via le Webmail et la structure des dossiers est juste aussi. Par contre, lorsque je vérifie leur profil dans la DB Postgresql …le chemin des dossiers n’est pas mis à jour !!!.
le “content_uri” est toujours sous “import-zarafa” !
J’espère qu’il y a un moyen simple de corriger cela car sinon ça va être la bronx dans la DB pour tous les utilisateurs !
Après vérification le correctif n’a pas pu être intégré à la 3.5.4 et sera disponible dans la 3.5.5 car il nécessite une modification au niveau du schéma de la base de données. il n’y a pas de contournement connu pour le moment.
Merci pour tes informations. Le problème mentionné ci-dessus et son impact sur l’archivage peut, pour ma part, attendre la sortie de la version 3.5.5 de BM.
Cependant, ce qui est plus embêtant c’est l’impact que celui-ci peut avoir sur le service EAS.
J’ai posté sur le forum ce que j’ai constaté ( voir ICI ) et cela handicap vraiment la synchro des mails et des dossiers sur les différents téléphones de notre parc (Iphone, Android). Actuellement, certains utilisateurs mon rapporté qu’il n’arrivait plus à lire leur mail dans les dossiers qui apparaissent vide sur leur téléphone !
Pour ma part, la synchro avec mon téléphone Wiko qui tourne sous Android ne fonctionne plus du tout !
J’ai le message en continu “chargement des messages en cours…” et rien ne s’affiche !
Dans les logs on voit clairement que les dossiers qui ont changés de répertoire ne sont pas attteignable à cause de leur “content_uri” faux dans la DB.
