Quoting Salaun Pascal : > Bonjour tout le monde, > voici une première version de plugins pour Munin adaptés à OBM-Posftix. > Ils sont tous au format "wildcard", c'est à dire que vous pouvez > demander des stats par domaine en précisant dans le lien symbolique la > valeur du domain_id. > S'il n'est pas précisé, alors le graphe sera global et affichera tous > les domaines. > Le tar.gz comprend 3 scripts : > - script4munin_pstfx_nb_from_by_domain_ : nb de messages émis par > domaine. > - script4munin_pstfx_nb_to_by_domain_ : nb de msg reçus par domaine. > - script4munin_pstfx_vol_from_by_domain_ : volume en octet émis par > domaine. > Chaque script fait référence à des variables par défaut, à savoir : > [MySQL] : > database : obm > user : obm > password : obm > [Postfix] : > log : /var/log/mail.log > Je pense avoir mis pas mal de commentaire dans chaque script pour une > install aisée. > Pascal > PS : j'ai une version MIOCT à qui dois-je la faire parvenir <[email protected]> </[email protected]><[email protected]>Salut,</[email protected]> <[email protected]> </[email protected]> <[email protected]>désolé pour cette réponse tardive, mais nous avons pas mal de taf pour la sortie de la 2.3 le freeze est pour bientôt. Je n'ai regarder le code que de loin et pas encore testé réellement les script. Cependant j'ai quelques remarques a faire.</[email protected]> <[email protected]>Nous avons choisi d'utilise munin en raison de sa simplicité et surtout pour éviter le moins de configuration possible.</[email protected]> <[email protected]>Dans cette versions les scripts necessite pas mal de configuration coter client, (les histoires de liens symbolique, et surtout de connaitre l'id du domaine. Le truc le plus génant est le fait que les scripts doivent se connecter à la BD obm (maintenant il y a PGSQL et Mysql). En effet, mettre en place des scripts de stats de mails sur des relais de messagerie veut dire qu'en général, les relais se trouve en DMZ et donc les flux SQL sont surement bloqué, cela m'embète fortement de demander a un admin sys de laisser passer des flux SQL entre le LAN et la DMZ. Donc j'ai une question est-ce vraiment necessaire de récupérer la liste des utilisateurs et les emails...?</[email protected]> <[email protected]> </[email protected]> <[email protected]>Donc plusieurs points pour moi sont a réfléchir:</[email protected]> <[email protected]>1 - le moins de conf possible ( par défaut ça fonctionne au pire une configuration à la main pour tuner le script)</[email protected]> <[email protected]>à la place de mettre un lien symbolique je verrai bien un fichier de conf ( ou pas si on peut faire sans)</[email protected]> <[email protected]>2 - éviter d'avoir une connexion BD.</[email protected]> <[email protected]> </[email protected]> <[email protected]>Je sais tous cela est un peu chiant mais vu tous les déploiements d'OBM que j'ai effectué, il y a certaine chose qui ne passe pas avec les admins sytèmes (<troll> justifié ou PAS </troll>)</[email protected]> <[email protected]> </[email protected]> Pour le point 2, avant de se connecter à la BD il faut savoir ce que l'on a besion. D'après ce que j'ai pu voir on a besion de connaitre les domaines existant pour pouvoir stater by domaine. Une piste qui est interressante serait d'utiliser obm-locator ou obm-satellite (ces services sont disponible en 2.3 seulement) Je propose donc deux architecture qui vont fonctionner différement: * obm-locator: obm-locator est un nouveau service pour obm 2.3 qui permet de localiser un service enregistre dans OBM. Il est automatiquement déployé ou se trouve la BD. c'est un web-service qui sera toujours installé en https (l'admin-sys sera déja plus content). Actuellement il permet seulement de savoir quel est le serveur obm-sync associé a un utilisateur, on lui donne un login, il renvoi une ip. Il pourrait être enrichi afin de pouvoir retourner la liste des domaines
*obm-satellite: obm-satellite a été complètemen,t réécrit en 2.3, c'est mainteant lui aussi un web service qui peut-être étendu facilement. Là on ne fonctionne plus de la même façon qu'avec le locator. Avec obm-satellite, on l'install là ou en a besoin. Il est extensible via module. Le but serait donc de configurer les script munin via obm-satellite sur odre de l'interface OBM. Ainsi on a l'avantage de ne pas requeter sur un serveur distant a chaque appel des scripts munin. Lors de l'ajout d'un host smtp dans l'interface web, celle-ci fait une requete sur le web service obm-satellite en lui envoyant les informations necessaire pour se configurer, de son coter obm-satellite via son module 'muni-postfix' s'occupe de générer la con des scripts munin. <[email protected]> </[email protected]> <[email protected]> </[email protected]> Bon j'espère ne pas trop avoir disserté sur ces scripts, mais il est important que lorsqu'on intègre quelque chose dans obm on regarde tous ce que l'on a autour. L'équipe OBM est là pour cela, veiller a que tous s'imbrique correctement (private joke: thomas pas de blague ;) ) et vous donner des conseille. PS: c'est quoi une version MIOCT ?? <[email protected]> </[email protected]> <[email protected]>-- </[email protected]> <[email protected]>Sylvain Garcia </[email protected]> _______________________________________________ Obm mailing list [email protected] http://www.list.aliasource.fr/mailman/listinfo/obm
