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.

Ajoutez maintenant dans votre httpd.conf (dans cet ordre) :

LoadModule ldap_module libexec/apache2/mod_ldap.so
LoadModule vhost_ldap_module libexec/apache2/mod_vhost_ldap.so

puis

VhostLDAPEnabled on
VhostLDAPUrl "ldap://127.0.0.1/ou=votre,dc=basedn"
VhostLdapBindDN "cn=utilisateur,ou=qui,dc=binde"
VhostLDAPBindPassword "mot de passe convivial"


Copiez le schéma fourni /usr/local/share/doc/mod_vhost_ldap/mod_vhost_ldap.schema dans /usr/local/etc/openldap/schema/ et ajoutez

include /usr/local/etc/openldap/schema/mod_vhost_ldap.schema

dans votre slapd.conf

Evidemment, redémarrez slapd et httpd.

Il ne vous reste plus qu’à provisionner avec votre editeur LDAP favori. Les attributs sont triviaux, par exemple :

# jard.in, apache, jardin
dn: apacheServerName=jard.in,ou=apache,dc=jardin
objectClass: top
objectClass: apacheConfig
apacheServerName: jard.in
apacheDocumentRoot: /home/www

Je regrette toutefois que l’auteur n’ait pas prévu des champs relatifs aux logfiles, j’ai du utiliser une vieille bidouille à base de LogFormat :

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog /var/log/httpd-access-vhosts.log combined

Pour faire passer sur le fichier httpd-access-vhosts.log le script split-logfile fourni avec apache2 qui sépare ce type de log fonction du vhost. Par très classe.