Traditionellement, les serveurs UNIX utilisent mbox pour stocker les mails. Pour mbox, chaque dossier de votre boîte mail (Reçu, Envoyés, Archive, Corbeille, etc) est representé par un fichier, ou tout les mails sont enregistrés à la suite, séparés par une ligne vide.

Ce format, très simple à utiliser, pose de nombreux problèmes. Premièrement, on ne peut pas faire d’accès parallèles, même sur des mails différents, puisque le fichier est le même (problème de verrou). Deuxièment, les serveurs POP/IMAP (comme Dovecot) ont souvent un support limité de mbox. Dovecot est obligé de placer un mail “interne” dans la boîte, pour garder l’arborescence et l’organisation des dossiers. Courier ne supporte pas mbox.

L’avantage principal de mbox, c’est le fait qu’il soit très répandu. Il est supporté par tout les MUA (mailutils/mail, bsd-mailx, mutt, emacs, Kmail, thunderbird, evolution). Mais les problèmes récurrents qu’il pose ont poussé le principal développeur de qmail a créer un nouveau format : Maildir.

Maildir

Avec Maildir, chaque mail est un fichier, et chaque dossier de la boîte mail, un répertoire. Attention, c’est un peu plus compliqué que ça. Les mails ne sont pas directement enregistrés dans boîte/mail :

• Le MDA enregistre le mail dans boîte/tmp/unique (“unique” est un nom de fichier unique généré a partir de données pseudo-aléatoires)
• Une fois que le mail est écrit, le MDA le déplace dans boîte/new/unique
• Le MUA le déplace dans boîte/cur/unique une fois qu’il voit qu’un nouveau message est arrivé dans boîte/new/

Pourquoi ? Ce comportement est utilisé pour éviter que le MUA voit un mail incomplet (car le MDA est encore en train de l’écrire), ce qui peut arriver si la machine est surchargée, si le Maildir est sur un serveur distant (NFS,FTP), voire même si le mail est gigantesque.

Maildir et procmail

Le but de cet article n’est pas d’expliquer comment configurer un MDA pour qu’il enregistre les mails en Maildir, mais malgré tout je fais une petite encartade pour les gens qui utilisent procmail. Le code suivant dans /etc/procmailrc permet de dire à procmail de mettre par défaut (cela peut donc être supplanté par une directive contraire dans le ~/.procmailrc) :
DEFAULT=$HOME/Maildir/
Aussi, si vous n’utilisez pas encore procmail je vous conseille d’y migrer rapidement :

• Plus besoin de toucher à la configuration du MTA pour changer les méthodes de livraison des mails
• Les utilisateurs peuvent écrire leurs propres règles pour leurs boîtes mails (pour avoir des boîtes séparées pour certains mails, par exemple)
• Si vous changez de MTA vous pouvez toujours garder la même configuration, à condition de dire à votre MTA d’utiliser procmail

Configuration de mutt

mutt gère très bien les Maildirs, mais il faut le configurer. Dans le .muttrc, rajoutez :

# pour dire à mutt de que mbox est un Maildir
set mbox_type=Maildir
# pour dire à mutt que les chemins relatifs (avec +) sont dans "~/Maildir/"
set folder="~/Maildir/"
# pour dire à mutt que les mails arrivent dans Maildir/
set spoolfile="~/Maildir/"
# les mails archivés (pas nouveau) seront envoyés dans +Mailbox
# (+ est remplacé par la variable folder).
set mbox="+Mailbox"

# ce code montre la puissance de mutt (inclure des scripts shell dans sa configuration)
# ouvrir tous les dossiers qu'il trouve dans ~/Maildir/
mailboxes ! + `\
for file in ~/Maildir/.*; do \
box=$(basename "$file"); \
if [ ! "$box" = '.' -a ! "$box" = '..' -a ! "$box" = '.customflags' \
-a ! "$box" = '.subscriptions' ]; then \
echo -n "\"+$box\" "; \
fi; \
done`

On note qu’il faut créer les boîtes mails dans ~/Maildir/, ainsi que le Maildir en lui-même (même si procmail peut le créer tout seul, et que si vous avez converti vos mbox il existe déjà). On va créer la boîtes “Mailbox” (utilisé par mutt avec set mbox=”+Mailbox”).

cd # on se place dans $HOME
mkdir Maildir # on crée Maildir (ça sera peut-être déjà fait)
cd Maildir
mkdir cur new tmp # on crée une arborescence Maildir
mkdir .Mailbox # on crée une nouvelle boite
cd .Mailbox
mkdir cur new tmp

On note que :

• La boîte principale, ou les mails entrants sont enregistrés par le MDA, est à la racine du Maildir
• Les sous-dossiers de la boîte, commencent tous par un .

Vous pouvez maintenant démarrer mutt, et exploiter votre mbox (pour naviguer dans les boîtes, utilisez “y”)

Migrer des boîtes mbox en Maildir

Pour migrer les mbox en Maildir, le script perfect_maildir.pl est parfait, et son usage est simple :
./perfect_maildir.pl path_to_Maildir/ < mbox

pam_mail.so et You have new mail

Vous avez peut-être déjà remarqué que quand vous vous ouvrez un shell, vous avez un beau message "You have new mail" qui indique de nouveaux mail dans /var/mail/$USER. Cet avertissement est geré par pam_mail.so, un module de PAM qui permet de faire ça. Si on utilise Maildir il est intéressant de dire à pam_mail.so d'aller vérifier les nouveaux mails dans le Maildir. Cette configuration se fait dans /etc/pam.d/ sous Debian et Gentoo. Tout d'abord éditer le fichier login, et trouver cette ligne :

session optional pam_mail.so standard

Remplacer par :

session optional pam_mail.so standard dir=~/Maildir

Je recommande d'effectuer aussi la manipulation pour le fichier "ssh".

Normalement PAM devra modifier la variable d'environnement MAIL à Maildir/, si par hasard ce comportement ne marche pas (en fonction de la configuration de PAM) il y a toujours moyen d'ajouter
MAIL=Maildir/
dans /etc/environment.

Faire fonctionner la commande "mail"

La commande mail est le moyen le plus simple de lire ses mails sous unix. Vous constaterez probablement que votre commande mail ne marche plus (même avec MAIL=Maildir/), car elle ne supporte pas Maildir. Mais il y a plusieurs versions de cette commande, la plus répandue étant celle de bsd (bsd-mailx avec Debian). Je vous conseille d'installer une autre version, appellée "heirloom-mailx" (sous Debian), voire "nail", qui supporte très bien les Maildir.

Liens relatifs

• Configurer Maildir et Dovecot
• man pam_mail
• la première spécification de Maildir (a changé depuis)

Ironiquement j'ai trouvé beaucoup de mes renseignements sur bugs.debian.org :

• libpam-modules: pam_mail doesn't set MAIL enviroment variable when .hushlogin exists.
• login.defs: QMAIL_DIR problems

Si vous avez aimé ce post...

1. Filtrer ses mails ! Un cauchemard !
2. Mise en place d’un système de backup avec Rsnapshot
3. Migration de Geekfault

Python est devenu assez à la mode, pour le développement web, ces dernières années avec l’arrivée de frameworks web comme Django, Pylons et web.py. On le voit souvent utilisé sur apache2, avec mod_python, ou sur des serveurs Python dediés à ça (CherryPy, etc)

Je cherche depuis longtemps un moyen de faire du Python sur HTTP. J’ai mis pas mal de temps mais je pense avoir trouvé une configuration sympa.

Je vous propose ici d’essayer nginx, un serveur HTTP (entre autres), très performant et  beaucoup plus léger/rapide que apache2. Il est très efficace pour faire du reverse-proxy (c’est à dire être utilisé en frontal/load-balancer devant un serveur HTTP, et lui transmettre les requêtes en faisant du cache et le cas échéant du load-balancing).

La configuration de nginx est très simple, et la documentation est très complète : wiki.nginx.org. L’installation de nginx est facile, il est inclus dans la plupart des distributions actuelles, donc à vos emerge/apt-get.

apt-get install nginx

nginx ne gère pas le python nativement. Il y a plusieurs solutions cependant :

• Faire du proxy vers un serveur qui gère le python, comme apache2. On perd la majeure partie de l’intêret de nginx, cependant.
• Faire du FastCGI vers un serveur FastCGI. C’est la solution la plus fréquente, en utilisant fcgi.py ou flup
• Faire du WSGI. C’est un protocole de communication entre serveurs HTTP et applications Python. Solution aussi assez fréquente.
• Faire du proxy vers un serveur qui gère le python de manière native. C’est une solution moins fréquente mais très pratique.

Avant même de penser à choisir une des solutions ici présentes, il faut les comparer entre elles.

nginx => apache2 => python

L’ennui de cette solution c’est : apache2. Utiliser nginx pour forwarder à apache2 est presque inutile. Presque ? Oui, car on peut dire à nginx de garder les fichiers statiques pour lui. Cependant, le gain de cette méthode est assez minime, et ce n’est intéressant que pour faire du load balancing sur plusieurs apaches.

le FastCGI

FastCGI c’est une norme, pour faire traiter du contenu dynamique par une application externe. Donc le support du FastCGI tout seul est inutile, il faut aussi quelque chose pour gérer derrière.

J’ai testé flup, un framework Python léger. Le résultat : ça marche, méééé c’est lent. Je tournais autour de 35/50 requêtes par seconde, et l’utilisation en mémoire vive était phénoménale, 150 mégas pour 1000 requêtes. (bien sur ces chiffres n’auront de valeur que lorsqu’ils seront comparés aux autres).

FastCGI est sympa pour faire une configuration “vite”. C’est d’ailleurs la seule solution viable, à ma connaissance pour faire du PHP sur nginx, à part le proxy vers un autre serveur HTTP.

Bref, FastCGI ne m’a pas convaincu. Et mes tests avec les autres solutions m’ont donné raison. Toujours avec moi ? On passe au WSGI !

le WSGI

WSGI is the Web Server Gateway Interface. It is a specification for web servers and application servers to communicate with web applications (though it can also be used for more than that). It is a Python standard, described in detail in PEP 333.

le WSGI, c’est le standard pour le Web Python. Il n’y a qu’à consulter wsgi.org pour se rendre compte que c’est tout un monde. Il consiste en un ensemble de normes (nom de variables, par exemple) pour permettre au serveur d’exécuter  un fichier codé en Python.

Le standard pour le WSGI sur les serveurs HTTP grand public, c’est le mod_wsgi de apache2. Il a été porté sur nginx, mais c ‘est une #@!## infame, qui ne marche que sur les vieilles versions et qui n’a pas été mise à jour depuis bientôt 2 ans et demi (cf. hg.mperillo.ath.cx/nginx/mod_wsgi/). J’ai obtenu des performances d’environ 133 requêtes par seconde avec, ce qui est déjà mieux que FastCGI, pour ceux qui suivent . Par contre, dès que j’ai voulu avancer un peu avec (toucher à la configuration, et surtout, passer à une version supérieure de nginx), j’ai été confronté à ses limites (et aux #@!## de faute de frappe dans le code source)

D’autant plus que l’auteur de mod_wsgi pour apache2 et l’auteur de mod_wsgi pour nginx reconnaissent ses limitations, respectivement ici et ici. Le premier document est très intéressant pour comprendre un peu l’architecture de nginx et ses différences avec apache2. En effet, le mod_wsgi pour nginx a été codé à partir de celui pour apache2, et il subit les différences d’architecture entre apache2 et nginx.

Attention, je ne remet absolument pas à cause le WSGI ici, juste l’implémentation de mod_wsgi dans nginx.

Parce que justement, un projet super récent, c’est…. uWSGI ! uWSGI sert à combler le manque de support du WSGI dans nginx, en rajoutant un module, meilleur que mod_wsgi. Il nécessite donc de recompiler nginx. Il y a encore une autre solution, nommée gunicorn, qui ne nécessite pas de recompiler nginx. C’est un serveur HTTP minimal qui gère le WSGI nativement. uwsgi offre plus de fonctionalitées que gunicorn, mais gunicorn a l’air assez dynamique (dans le développement), et est plus facile à utiliser (pas de recompilation, support de Django natif). Au niveau des performances, je me suis amusé à faire cette comparaison :

Comparaison des performances entre uwsgi et gunicorn en fonction du niveau de parallélisme

On constate plusieurs choses :

• Les performances augmentent en utilisant 2 workers à la place d’un, mais au delà, le gain est ridicule, puis inexistant. Le nombre 2 est dépendant du nombre de coeurs de la machine, et le nombre de workers à utiliser ne sera pas le même sous un bi-socket octocore, bien évidemment. Les meilleures performances étaient obtenues en utilisant gunicorn+3workers.
• La différence est vraiment minime, gunicorn est en moyenne légèrement au dessus de uwsgi.
• Ces tests sont réalisés sur une application Django. Les performances augmentent en utilisant des frameworks plus légers comme web.py, bien évidemment.

uwsgi dispose de plus de fonctionalitées, comme par exemple une interface d’administration de serveur wsgi dans Django. Je vais ici expliquer l’installation et la configuration des deux solutions.

Ici je vais couvrir l’installation et la configuration de uwsgi et gunicorn avec Django et web.py, même si c’est bien sur adaptable avec d’autres frameworks supportant le wsgi (liste sur wsgi.org/wsgi/Frameworks).

Installation et configuration de uwsgi

Sous Debian :

1) Rajouter les dépots source, par exemple :

deb-src http://ftp.gr.debian.org/debian/ squeeze main contrib non-free

2) Télécharger la source

apt-get source nginx
tar -zxvf nginx_*.orig.tar.gz
cd nginx-*
tar -zxvf nginx_*.debian.tar.gz

2) Télécharger uwsgi

cd ..

tar -zxvf uwsgi-0.9.4.2.tar.gz

3) Modifier le paquet source de nginx pour y ajouter uwsgi. Il faut éditer le fichier nginx-*/debian/rules, trouver le bloc qui commence par ./configure et ou se trouvent toutes les options de compilation, et y ajouter

--add-module=$(CURDIR)/../uwsgi-0.9.4.2/nginx/

$(CURDIR)/../uwsgi-0.9.4.2/nginx/ est le chemin vers le dossier du module dans la source de uwsgi

4) maintenant, dans le dossier de la source de nginx, faites (pas besoin de root) :

dpkg-buildpackage

5) installer le .deb généré ainsi (en tant que root maintenant)

dpkg -i ../nginx-*.deb

6) Dernière étape : compiler uWSGI (le binaire en lui-même, qui va communiquer avec nginx par le biais du module)

cd ../uwsgi-0.9.4.2/ && make && make install && cp uwsgi_params /etc/nginx/

Cette dernière commande (le cp uwsgi_params…) sert à placer un fichier de configuration du module uwsgi exemple dans le repertoire de nginx.

Sous les autres distributions :

Il faut télécharger la source de nginx et de uwsgi, compiler nginx avec le module uwsgi (dans le répertoire nginx de la source de uwsgi), puis compiler uwsgi.

On a maintenant un serveur uWSGI et un nginx avec  le module uwsgi. Il va maintenant falloir dire à nginx de transférer les requêtes au serveur uWSGI, avec une commande uwsgi_pass. Par exemple, dans la section server d’un de vos vhost (/etc/nginx/sites-enabled/default, par exemple, sous Debian) :

location / {
include uwsgi_params;
uwsgi_pass unix:///tmp/uwsgi.sock;
}

Il faut ensuite créer une application WSGI, par exemple, pour le framework web.py :

import web

application = web.application(urls, globals()).wsgifunc()
applications = {'/': application }

Pour Django :

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
applications = {'/': application }

Nommez ce fichier wsgi.py et placez le dans le repertoire ou vous allez placer votre code (pour Django, dans le repertoire du projet, évidemment). Si vos nerfs n’ont pas encore lâché ici, allez prendre une petite pause de 5 minutes à titre préventif, et reprenez. Maintenant, on va démarrer un serveur uWSGI. Placez vous dans le répertoire de votre fichier wsgi.py, et faites :

uwsgi -s /tmp/uwsgi.sock -C -w wsgi -p2 -L

Explications : le -s indique ou placer le socket (ça pourrait aussi être une adresse au format hôte:port, pour un usage distant). Le -w wsgi indique de charger le fichier wsgi(.py), le -p2 indique de démarrer 2 processus, et le -L désactive l’envoi des requêtes à stdout (=>flood).

Si vous allez à l’adresse de votre serveur web, vous devriez voir votre application Python en face de vous ! Vous voilà en train d’utiliser nginx+uwsgi+python.

En annexe, je rappelle que uwsgi est aussi utilisable avec apache et lighttpd.

Aussi, dans le dossier source de uwsgi, vous trouverez des templates pour un module d’administration de Django, à installer dans le repertoire des templates de l’administration de Django (si, si).

Installation et configuration de gunicorn

gunicorn est carrèment plus facile à installer. Il est codé en python, donc pas de compilation, seulement un easy_install :

easy_install gunicorn

La configuration est tout aussi facile, il suffit de cela dans la configuration du vhost dans nginx :

location / {
proxy_pass http://unix:/tmp/gunicorn.sock
}

On démarre ensuite gunicorn. Pour Django, gunicorn dispose d’un support intégré, il vous suffit de vous placer dans le répertoire de votre projet, puis :

gunicorn_django -b unix:/tmp/gunicorn.sock --workers=2

Pour web.py, il faut créer un module :

import web

application = web.application(urls, globals()).wsgifunc()

Il faut ensuite démarrer le serveur Gunicorn. En étant dans le repertoire ou se trouve le module web.py (le fichier donc le code vient avant, là, au-dessus, oui), :

gunicorn -b unix:/tmp/gunicorn.sock --workers=2 wsgi

Je vous invite à consulter ce lien : gunicorn.org/tuning.html, pour vous permettre d’augmenter les performances de gunicorn.

Annexe

Fichiers statiques

location /admin-media {alias /usr/lib/pymodules/python2.5/django/contrib/admin/media;}

location /static {root /var/www/byteflow;}

Ces deux lignes, à rajouter après le “location /” avec uwsgi_pass ou proxy_pass (selon votre configuration) indiquent à nginx de traiter les fichiers statiques directement. Il faut bien évidemment adapter à votre configuration.

Munin

Vous pouvez trouver des plugins nginx pour munin ici. Je n’ai pas trouvé de plugin munin pour uwsgi/gunicorn, mais je pourrais peut-être en faire un si je trouve le temps.

Plusieurs serveurs

Si par hasard vous avez plusieurs serveurs gunicorn/uwsgi répartis sur plusieurs machines , vous pouvez les utiliser en déclarant une section

upstream nom {}

dans nginx, contenant les adresses des serveurs distant (hôte:port ou emplacement du socket) et en utilisant “nom” comme argument à uwsgi_pass et proxy_pass.

Conclusion

Ces deux architectures sont très pratiques pour faire tourner du python dans un serveur web, ici nginx. uwsgi dispose de plus de fonctionalités, mais la plupart (template d’admin Django, memory profiling) pourraient facilement être ajoutées à gunicorn, qui est beaucoup plus léger à installer/configurer/maintenir (2 commandes et 3 lignes de configuration dans nginx). J’ai les deux personellement sur mon serveur, j’ai eu à alterner entre les deux pour écrire cet article, et c’est pas bien dur, un daemon à arrêter, un autre à démarrer, et changer une ligne dans la configuration de nginx.

Liens

wsgi.org

gunicorn.org/

projects.unbit.it/uwsgi/

irc.freenode.org/#gunicorn

nginx.org/

djangoadvent.com/

www.django-fr.org/

www.djangoproject.com/

webpy.org/

Je tiens à remercier la communauté Geek{node|fault}, le chan irc #gunicorn, les développeurs de gunicorn qui sont très aimables, ainsi que Amandarn qui m’a aidé pour certains détails.

Si vous avez aimé ce post...

1. Devbox KVM+Libvirt perfect setup.
2. Maildir mbox – La migration
3. Filtrer ses mails ! Un cauchemard !