Re: [OBM] : dev cookbook

GARCIA Sylvain sylvain.garcia at aliasource.fr
Wed Sep 30 23:42:41 CEST 2009


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
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net><pascal.salaun at laposte.net>Salut,</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>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.</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>Nous avons choisi d'utilise munin en raison de sa simplicité et surtout pour éviter le moins de configuration possible.</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>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...?</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>Donc plusieurs points pour moi sont a réfléchir:</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>1 - le moins de conf possible ( par défaut ça fonctionne au pire une configuration à la main pour tuner le script)</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>à la place de mettre un lien symbolique je verrai bien un fichier de conf ( ou pas si on peut faire sans)</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>2 - éviter d'avoir une connexion BD.</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>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>)</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net>
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.
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net>
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 ??
<pascal.salaun at laposte.net>
</pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>-- </pascal.salaun at laposte.net>
<pascal.salaun at laposte.net>Sylvain Garcia
</pascal.salaun at laposte.net>



More information about the Obm mailing list