Je suis toujours dans le fastidieux processus de migration des services d’iMil.net vers sa nouvelle demeure. Vous ne l’avez probablement pas remarqué, mais le site que vous avez sous les yeux est désormais servi par un apache chrooté, reverse-proxyisé par l’incroyable nginx. Je reviendrai probablement sur cette configuration dans un prochain post.
Ce week end, je m’attaque à la migration du MX. *soupir*
Dans la liste infinie de trucs à configurer, il y a mon “nouveau” meilleur ami: dspam.
On aurait pu s’attendre à une installation straightforward de la bête (j’utilise évidemment intensivement pkgin pour l’installation des packages), mais en réalité, quelques petits casse-tête sont dispersés de-ci de-la.
En premier lieu, le package lui même. On peut lire dans le fichier options.mk le commentaire suivant :
### This is the backend database used to store the DSPAM signatures as ### well as other state information. The recommended storage driver is ### "mysql", even for small installations.
“Fabuleux”, me dis-je. Sauf que les deux lignes d’après précisent :
### Possible: mysql, pgsql, sqlite, sqlite3 or hash ### Default: hash
Va comprendre. Cela signifie que, une fois n’est pas coutume, je devrai me fendre de la compilation de ce package avec une option particulière :
$ grep -i dspam /etc/mk.conf DSPAM_STORAGE_DRIVER= mysql
Bon.
La configuration du logiciel en soi n’a pas changé, je vous renvoie aux differentes documentations expliquant les paramètres clé du fichier dspam.conf.
L’integration à sendmail n’a pas changé non plus, ces deux lignes appliquées à votre .mc suffiront :
define(`LOCAL_MAILER_PATH', `/usr/pkg/bin/dspam') define(`LOCAL_MAILER_ARGS', `dspam -t -Y -a $h "--deliver=innocent" --user $u -d %u')
Je rappelle à toutes fins utiles que la construction du .cf, sous NetBSD, s’effectue de cette façon :
make install-cf CF=nom
Jusqu’ici, tout va bien.
Et nous en arrivons à la partie la moins bien integrée du package: l’interface web. Première chose, le package n’embarque pas toutes les dépendances nécessaires au bon fonctionnement de l’interface de dspam. Il vous faudra donc vous fendre d’un :
$ sudo pkgin in p5-GD p5-GD-Graph3d
Afin de ne pas voir admingraph.cgi se crouter misérablement.
Vient ensuite l’application web en elle même. Je ne souhaitais pas dédier un vhost à dspam, mais plutot l’utiliser dans un sous repertoire de la partie privée de mon site; en effet, cette dernière est accédée en HTTPS, sur un FQDN unique, et l’idée de gêrer plusieurs certificats CACert pour mes simples besoins me rebutait. En prime, cette methode me permet de configurer mon reverse proxy le plus simplement du monde.
Ainsi, j’ai copié l’ensemble des fichiers situés dans /usr/pkg/share/dspam/webui/cgi-bin/ et /usr/pkg/share/dspam/webui/htdocs/ dans un repertoire dédié. Afin de signifier à apache qu’il devra interpreter les cgi de ce repertoire, j’ai ajouté un fichier .htaccess contenant les directives suivantes :
Options +ExecCGI AddHandler cgi-script .cgi .pl
Tous ces cgis incluent le fichier /usr/pkg/etc/dspam/configure.pl, qui définit entre autres la variable WEB_ROOT, chemin vers la CSS et la petite icône dspam. Plutot que de copier le fichier configure.pl puis modifier tous les scripts afin que l’inclusion se fasse sur ./configure.pl, j’ai renseigné la variable qui m’interesse directement dans /usr/pkg/etc/dspam/configure.pl :
$CONFIG{'WEB_ROOT'} = "/dspam";
Reste à copier le fichier /usr/pkg/etc/dspam/cgi-default.prefs dans le repertoire choisi pour héberger l’interface dspam sous le nom default.prefs, et enfin d’ajouter l’utilisateur autorisé à manipuler l’interface dans /usr/pkg/etc/dspam/cgi-admins.
Tout ceci n’est pas bien propre, je vous l’accorde.
Notez que si vous souhaitez utiliser un vhost, la configuration serait bien moins fastidieuse puisqu’il suffirait de créer un VirtualHost dans lequel vous préciseriez un ScriptAlias et un DocumentRoot.
Recent Comments