Emile "iMil" Heitor 's home

Je sais, je suis un vieux con. Et en bon vieux con que je suis, je n’ai jamais réussi à utiliser un autre MUA que pine / alpine. C’est pas qu’il soit franchement au dessus des autres, loin s’en faut, mais que voulez-vous, on ne change pas 14 ans d’habitudes comme ça.

Alpine a des avantages, mais aussi beaucoup d’inconvénients, et l’un d’entre eux, c’est la manière dont il “gère” la validité des certificats TLS/SSL.

Jusqu’à présent, la flemme m’avait poussé à renseigner mes accès IMAP de cette façon :

$ grep novalidate .pinerc
inbox-path={mon.serveur.imap/ssl/novalidate-cert}inbox

De façon à ne plus voir le fameux warning me signifiant que le certificat du serveur IMAP auquel je souhaite me connecter n’est pas valide, blah blah blah. Et puis cette fois j’ai voulu faire les choses bien. En fouillant un peu, je suis tombé sur cette excellente documentation qui explique le pourquoi du comment, mais surtout le “comment”.

Voici donc en résumé la marche à suivre.

Vous aurez besoin, pour satisfaire alpine :

• Du root-certificate duquel est issu votre certificat serveur
• Du certificat serveur en question

J’utilise depuis quelques temps les services de CACert plutôt que d’auto-signer mes certificats. C’est peut-être dérisoire, mais je trouve ça plus sérieux.

La première étape consiste en la découverte du répertoire par défaut ou OpenSSL cherche les certificats. On obtient cette information avec la commande suivante :

$ openssl version -d
OPENSSLDIR: "/etc/openssl"

Pour moi, donc, ce sera /etc/openssl.

Là ou ça devient rigolo, c’est qu’aucune directive de configuration du .pinerc ne permet de définir un nom de fichier correspondant aux certificats. Non. À l’Université de Washington, ils préfèrent chercher ces derniers sous forme de hash, c’est tellement plus convivial. Heureusement, dans la documentation précédemment citée, Paul Heinlein a déblayé le terrain et nous explique qu’on obtient ce hash à l’aide de la commande openssl x509 -in certificat.pem -hash -noout.

Ainsi, il “suffit” de copier votre certificat racine et le certificat serveur avec leurs noms sous la forme du hash obtenu… suffixé par “.0″. Demandez pas.

Ce qui nous donne :

$ openssl x509 -in cacert-root.pem  -hash -noout
5ed36f99
$ openssl x509 -in cert_serveur.pem  -hash -noout
aaf089ef8

Puis

$ sudo cp cacert-root.pem /etc/openssl/certs/5ed36f99.0
$ sudo cp cert_serveur.pem  /etc/openssl/certs/aaf089ef8.0

Bin croyez-le ou non: ça marche.

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.

Au boulot, j’ai élu une solution de déploiement à haute teneur en convivialité qui m’a été suggérée par nico, j’ai nommé fabric.

Ce soft à l’utilisation simplissime permet en un tournemain de réaliser des opérations complexes en masse sur une architecture distante en utilisant le protocole SSH.

Si la documentation de la plupart des fonctions est clarissime, l’une d’entre elles, qui pourtant me semblait avoir un fort potentiel loutresque, n’était pas très clairement exposée: upload_template.
Cette fonction, comme son nom semble l’indiquer, permet d’envoyer sur un serveur distant un fichier “template” en ayant préalablement remplacé des variables par le contenu souhaité. Après un peu de lecture du code source de fabric, la subtilité de son utilisation m’est apparue.

Voici à quoi doit ressembler un fichier template, j’utilise ici l’exemple classique d’un /etc/network/interfaces à remplir avec les valeurs adéquates :

auto lo
iface lo inet loopback

auto %(iface)s
iface %(iface)s inet static
	address %(ipaddress)s
	netmask %(netmask)s
	gateway %(gateway)s

Ces variables utilisent les string interpolation formatting de python, que l’on renseigne à l’aide d’un dict de cette façon :

netinfo  = {
                'iface': 'eth0',
                'ipaddress': '10.20.30.40',
                'netmask': '255.255.255.0',
                'gateway': '10.20.30.254'
}

Et que l’on inclut finalement dans la fameuse fonction upload_template de cette façon :

        upload_template('etc/network/interfaces', '/etc/network/interfaces', context=netinfo, use_sudo=True)

Moyennant quoi, fabric enverra le fichier template sur sa destination puis remplacera les variables par leur valeurs définies dans le dict passé en paramètre.

Sysop, ne révèle pas à tes employeurs que tu construis aujourd’hui ta glande de demain.