Que se passe-t-il lorsqu'apache reçoit une requête ?

La question peut paraître anodine jusqu'à ce qu'on ait à écrire un fichier de configuration un peu complexe. Il faut alors avoir une idée de l'ordre dans lequel les opérations sont effectuées.

Commençons par un aperçu rapide :
-> récupération du virtualhost concerné
-> récupération de la partie requête
-> rewrite rules et redirect
-> alias et réécriture de la requête nom de fichier
-> traitement par <Directory>, <DirectoryMatch>, .htaccess, <Files>, <FilesMatch>, <Location> et <LocationMatch>
-> droits d'accès
-> traitement du fichier en fonction de son type.

Ouf c'est long ! Comme cet article, alors prenez votre temps ...

Traitement de l'URL

Pour chaque requête, apache relit sa configuration (en fait il récupère la version parsée en mémoire). Ensuite il parcourt les éléments dans l'ordre, les compile en une seule conf puis la utilise cette conf spécifiquement pour cette requête.

Virtualhost

Bon ca c'est facile, on se base sur les ServerName définis dans les <Virtualhost>. Si on n'en trouve pas, on cherche dans les ServerAlias, si on n'en trouve pas on cherche encore, mais cette fois avec les wildcard (*.mondomaine.com), si on ne trouve toujours pas, on prend le premier <Virtualhost> qui a été dacléré. Et enfin s'il n'y a pas de virtualhost, on prend le DocumentRoot défini à la racine du serveur apache lui-même.

Voilà on a trouvé le virtualhost, maintenant on prend la requête, qui est la partie située à droite de l'URL après l'hôte et le port.

Transformation de l'URL

Contrairement à ce qu'on pourrait penser, lorsqu'il y a modification de l'url, il n'y a pas de gestion de droits d'accès sur la requête originale, seulement sur l'url modifiée (par rewriterule en général).

On traite d'abord les RewriteRule, dans l'ordre de leur priorités.

Si aucune ne correspond, on traite ensuite les Redirect et les RedirectMatch dans l'ordre de leur écriture. Attention on prend aussi en compte ceux qui sont dans les <Location> qui correspondent, mais on fait comme s'ils avaient été écrits à la racine. C'est-à-dire qu'on n'enlève pas le préfixe du location pour les traiter.

On traite ensuite les Alias, AliasMatch, ScriptAlias et ScriptAliasMatch dans l'ordre de leur apparition. Ce traitement fournit le nom de fichier réel à utiliser pour une URL donnée.

Si on ne trouve pas d'alias on ajoute le DocumentRoot à la requête pour obtenir le chemin complet du fichier.

Configuration et droits d'accès

A partir de maintenant on repart de la configuration du virtualhost et pour chaque section on prend la configuration qui correspond à la requête en cours. Et à la fin on fusionne les configurations récupérées selon une règle de fusion dépendant de chaque module.

C'est complexe et chiant à retenir, donc pour simplifier retenez que les configurations spécifiques aux droits d'accès sont en mode remplacement, c'est-à-dire que la dernière configuration remplace toutes les autres.

Directory et DirectoryMatch

On sait maintenant quel chemin doit être lu, on parcourt l'arborescence pour savoir si c'est un fichier et si on peu le lire s'il a un vrai chemin sur le système ...

On part de / et au fur et a mesure qu'on descend dans le système de fichier on vérifie les <Directory>, puis les .htaccess, puis les <DirectoryMatch> dans l'ordre pour chacun des répertoires. On a donc séquentiellement pour par exemple /var/www :

• <Directory />
• /.htaccess
• <DirectoryMatch />
• <Directory /var>
• /var/.htaccess
• <DirectoryMatch /var>
• <Directory /var/www>
• /var/www/.htaccess
• <DirectoryMatch /var/www>

Toutes les sections qui correspondent sont accumulées dans la configuration en cours.

Attention ! Si l'option FollowSymLinks est activée, on fait la correspondance sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on la fait sur les liens après les avoir déréférencés. C'est assez contre intuitif !

Files et FilesMatch

Une fois arrivé au bout, on a un fichier, on lit alors les sections <Files> et <FilesMatch> dans l'ordre de leur apparition, y compris celles qu'on a trouvé dans les .htaccess ou les <Directory>.

Notez que ces sections ne prennent en compte que le nom de fichier, sans chemin.

Attention, même remarque que précédemment sur les liens symboliques : "Si l'option FollowSymLinks est activée, on matche sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on matche sur les liens après les avoir déréférencés."

Location et LocationMatch

Maintenant il nous reste à prendre en compte tous les <Location> et <LocationMatch> de la configuration qui correspondent à notre URL. Cette fois on les prend séquentiellement et uniquement en fonction de l'url.

Attention les étapes de réécriture de règle sont passées, on matche donc sur l'url réécrite.

Configuration des droits

Dans le cas des droits d'accès, les blocs de directives se remplacent. C'est-à-dire que si vous avez une série de "order / allow / deny" dans une section, elle remplace intégralement toute autre série de "order / allow / deny" que vous pourriez trouver dans une section précédente.

Attention ceci est valable pour chacun des modules séparément.

Un exemple pour être plus clair :

<Location />
    order allow,deny
</Location>
<Directory /html>
    deny from all
    AuthUserFile users.txt
</Directory>
<DirectoryMatch />
    AuthUserFile web.txt
</DirectoryMatch>
<Directory />
    order deny,allow
    allow from all
    AuthUserFile admins.txt
</Directory>

Le premier <Directory> est lu, puis il est remplacé par le 2e <Directory>, puis il est remplacé par le <DirectoryMatch> puis par le <Location> intégralement, mais séparément pour le module authz_host (order, allow, deny) et le module authnz_user (AuthUserFile). On a donc pour une requête qui matcherait les 3 sections la configuration suivante :

order allow,deny
AuthUserFile web.txt

Pas évident hein :-) Surtout que cette règle n'est pas la même pour d'autres modules comme mod_rewrite.

Traitement des droits

Le traitement des droits lui-même est particulier.

Si on est en satisfy all (par défaut) :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès, on interdit l'accès.
  
• Puis on prend tous les modules d'authentification utilisateur et si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise l'accès.

Si on est en satisfy any :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès :
  • On demande son avis aux modules d'authentification, si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise.

Rewrite (again)

Arrivé ici, on repasse dans les RewriteRules Mais cette fois on ne traite que le cas particulier des rewrite dans les sections <Location>, <Directory>, <Files> et .htaccess

Ces rewrite se cumulent cette fois (contrairement aux module d'accès, mais toujours selon le même parsing vu précédemment).

Ces rewrites sont cette fois relatifs, contrairement aux rewrite globaux. Ce qui veut dire qu'on les écrit par rapport à une racine qui est l'endroit où la règle est écrite.

Réponse

Cool maintenant on a notre requête nettoyée et on sait vers quelle fichier elle pointe.

Reste à la traiter.

Filter

On cherche tous les filtres (input et output) associés à cette url. Par exemple il y a mod_include, vous savez, pour les fichier .shtml qui contiennent des truc genre :

<!--#echo var="DATE_LOCAL" --> 

Il y a aussi les filtres pour compresser (oui pas besoin de zipper en php, apache peut le faire tout seul).

Tout ceci avec SetInputFilter et SetOutputFilter.

Handler

Ensuite on cherche le handler associé à ce type de fichier. Il y a bien sur le handler fichier (incroyable), mais aussi le handler php, le handler perl (sisi), le handler cgi, mais aussi le handler proxy, et tous ceux que vous pourriez définir avec SetHandler .

On et hop lance le tout : inputfilter -> handler -> outputfilter.

Conclusion

En résumé c'est le bordel ! Celui qui a écrit ça devait en avoir pris une sacrée dose et pas que de la farine. Probablement un pote de celui qui a fait X11 ...

Ne supposez jamais que ça marche comme vous le pensez, testez à chaque modification de votre conf.

Espérons que le prochain apache en développement tiendra ses promesses et nettoiera un peu la gestion de la configuration et surtout des droits d'accès. Sinon je prédis un avenir merveilleux pour toutes les alternatives soit disant "légères" comme lighthttpd ou nginx.

Supposons que vous administriez une machine distante. Vous n'avez pas d'accès physique à cette machine. C'est ennuyant puisque vous venez de changer la configuration de votre bootloader.

Comment faire pour rebooter tout en garantissant que ca va marcher ?

Hé bien j'ai la solution qui vous permettra de tester ce boot avant de rebooter : qemu.

Préparer les disques

Il nous faut des disques en lecture seule pour éviter que le boot de la machine virtuelle n'écrive sur un disque en cours d'utilisation. Donc pour chacun de vos disques physique :

$ cp -a /dev/sda /root/sda
$ chmod 440 /root/sda

Ainsi nous avons des disques garantis en lecture seule.

Préparer son terminal

Nous allons enregistrer ce qui se passe sur le terminal, lequel va tourner en ncurses, il est donc important pour la lisibilité des logs de le dimensionner à la même taille que l'écran de boot, c'est-à-dire 80x25.

Modifiez la taille de votre fenêtre de terminal jusqu'à ce que les variables $COLUMNS et $LINES vaillent respectivement 80 et 25.

Préparer son bootloader

Quel que soit votre bootloader configurez le de façon à ce qu'il ne lance pas de mode graphique, sinon vous ne pourrez pas stocker les logs de ce qui se passe.

Choisit son qemu

Installez qemu. Puis en fonction du matériel à émuler choisissez qemu-system-i386 ou qemu-system-x86_64 ou une autre architecture si vous travaillez sur d'autres machines.

Lancer le tout

Préparez un 2e terminal pour tuer qemu , ca sera plus simple que d'attendre qu'il se termine proprement (killall qemu pour les impatients).

$ sync
$ ssh -t localhost "qemu-system-x86_64 -m 512 -curses -hda /root/sda" | tee logs

Pourquoi sync ? au cas où vous auriez fait des modification impactant le boot, on force l'écriture de celles-ci sur le disque.

Pourquoi ssh ? Pour profiter de l'option -t qui crée un terminal virtuel même lorsqu'on travaille dans un pipe.

Pourquoi tee ? Pour stocker les logs de ce qui se passe tout en gardant la main sur le clavier. Tout est tellement rapide qu'il peut y avoir des erreurs invisibles.

Pourquoi -m 512 (512Mo de ram): prenez une valeur inférieure à votre matériel mais malgré tout proche pour éviter les effets de bord.

Pensez à ajouter les disques dont vous pourriez avoir besoin selon le niveau de boot que vous voudriez tester.

Lire les logs

Bon, qemu s'est lancé, le boot a planté, mais vous n'avez pas eu le temps de voit l'erreur.

Commencez par tuer le qemu s'il vous gêne. Puis lisez les logs :

$ less -R logs

Pourquoi -R ? parce que cette option vous permet de ne pas traduire les caractères spéciaux que qemu écrit à travers ncurses et vous permet de voir le contenu des logs tels qu'ils sont apparus à l'écran.

Mode graphique

Si vous ne voulez pas de logs ou que vous ne pouvez pas empêcher le mode graphique de se lancer, vous pouvez faire sans. Dans ce cas, à vous de vous connecter à la machine de façon à ce qu'un serveur X soit accessible (par exemple avec ssh -X).

La commande devient alors :

$ sync
$ qemu-system-x86_64 -m 512 -hda /root/sda

PS : Et ça marche avec les outils de virtualisation comme xen.

Linux est un système très stable. Tellement stable que certaines personnes font une gloire personnelle de la durée d'allumage de leurs machines.

Pour pouvoir vous vanter vous aussi auprès de vos collègues et briller dans les soirées, voici le moyen de savoir quelles ont été les différentes durées d'uptime de votre machine.

Uptimed est un simple démon disponible dans le paquet éponyme. Il suffit de l'installer. Ce démon ne fait qu'une chose et il le fait bien, il enregistre la durée depuis laquelle le système est lancé dans un fichier de logs et rend ces informations disponibles aux utilisateurs. Il est même capable de vous envoyer un mail pour vous avertir de l'atteinte d'un record.

Les utilisateurs ont accès aux meilleurs temps avec la commande uprecords :

$ uprecords

Tout ceci est bien joli et il est vrai que c'est très gratifiant d'avoir réussi à maintenir un système en fonctionnement pendant plusieurs années, voir une dizaine d'années pour certains. Mais il ne faut pas oublier une chose, la sécurité. Un noyau qui n'est jamais rebooté, ce n'est pas seulement un noyau stable, mais c'est aussi un noyau vulnérable car non mis à jour.

Alors bien sur certains argueront qu'il existe maintenant ksplice. Mais je pense que son usage reste marginal. C'est pourquoi, n'oubliez pas de mettre une sonde sur vos serveur pour surveiller les machines qui n'ont pas été rebootées depuis longtemps, c'est en fait un signe de faiblesse.

Aujourd'hui la suite tant attendue d'une série sur lvm.

Figurez-vous qu'il est possible de faire du raid avec LVM. Hé oui, vous avez déjà remarqué que vous pouviez mettre plusieurs disque dans un vg. Pour l'instant lvm se contente de les mettre bout à bout, comme le ferait un raid de type linear.

Striping

Le raid0 aussi appelé striping découpe un disque en petits morceaux et les alterne pour en faire un disque plus gros. Le but est d'avoir un disque plus gros, mais aussi d'augmenter les performances. En effet, dès qu'on va lire ou écrire un fichier un peu plus gros que ces morceaux, on va le faire sur 2 disques simultanément et donc augmenter la bande passante.

Lorsqu'on répartit les données linéairement sur le disque on ne gagne pas en performances, par contre en cas de crash d'un des deux disques, il y a moyen de récupérer presque la moitié des données, alors que dans le cas du striping, vous êtes sur de ne rien pouvoir récupérer.

Pour faire du striping avec lvm, rien de plus simple. Lors de la création de votre LV, il suffit de préciser le nombre de "stripes" qu'on désire :

# 2 etant le nombre de partition sur lesquels découper le volume
$ lvcreate -L 1G -i 2 lv0 vg0

Notez que si vous voulez forcer le striping sur certaines partitions, il est possible de donner en paramètre à lvcreate la liste des pv sur lesquels vous vous qu'il soit.

Et pour vérifier que c'est bien ce que vous vouliez :

$ lvdisplay -m /dev/vg0/lv0

Miroir

Le raid1 aussi appelé "mirroring" recopie intégralement un disque sur un autre pour permettre une récupération sans soucis lorsqu'un des deux disques grille, au coût d'un disque supplémentaire.

Alors lvm permet aussi de faire ce genre de chose tout aussi simplement :

# 1 correspond au nombre de copies du volume
$ lvcreate -m 1 -L 1G lv0 vg0

Les miroirs lvm diffèrent du raid1 du fait que lvm demande un périphérique supplémentaire pour stocker les logs du miroir. C'est grâce à ces logs qu'il sait quel est l'endroit qui pose problème lorsqu'il y en a un. C'est donc un peu plus exigeant qu'un raid1.

Et pour vérifier que c'est bien ce que vous vouliez :

$ lvdisplay -m /dev/vg0/lv0

Avançons encore un peu dans notre exploration de lvm. LVM permet beaucoup de choses, et entre autre la création de snapshots. Un snapshot c'est une prise de vue instantanée, qui dans le cas de lvm se fait au niveau du disque. Ce qui veut dire que le contenu du snapshot peut ne pas être cohérent, par exemple si le système est en train d'écrire sur le disque en plein milieu du snapshot.

On peut utiliser les snapshot pour beaucoup de choses, par exemple, Apple l'utilise pour faire sa machine à remonter dans le temps, on peut l'utiliser pour faire des backup cohérents mais aussi pour faire des expérimentations avec des retours arrière rapide.

Un snapshot

Partons d'un lv existant avec un vg sur lequel il reste de la place (hé oui, il faudra bien stocker nos snapshots. Faisons un snapshot de notre lv :

$ lvcreate -L 50M -s -n snap /dev/vg0/original

Et voila, c'est tout, fin de l'article !

Bon, pas encore. Déjà, pourquoi donner une taille au snapshot ? Tout simplement parce que celui-ci est intelligent, donc il ne va pas copier l'intégralité du lv original. Au contraire, il ne va stocker que les différences. C'est pourquoi il est instantané et commence avec une occupation taille nulle. Par contre, il faut lui allouer une taille dans le vg, donc 50Mo sera la quantité maximum de différence qu'il pourra stocker. Au delà de cette taille, le snapshot sera cassé et il ne pourra plus fonctionner correctement (les données ne sont plus valides, laissez tomber).

C'est pourquoi il faut faire attention à bien dimensionner ses snapshots et les gérer correctement. Après quelque quelque temps, vous verrez l'occupation du lv augmenter avec la commande lvdisplay :

$ lvdisplay /dev/vg0/snap
...
  Allocated to snapshot  26,27% 
...

Votre snapshot est occupé à 26%, vous avez encore un peu de marge. C'est à vous de monitorer cette valeur et de prendre une décision, soit supprimer le snapshot (lvremove) ou d'augmenter la place allouée au snapshot (lvextend).

Une fois le snapshot cassé, vous avez ce genre d'information :

$ lvdisplay /dev/vg0/snap
...
  LV snapshot status     source of
                         /dev/vg0/original [INACTIVE]
...

Backup

Donc la technique pour faire un backup est simple, seul problème, si la machine a besoin du système de fichier pendant le snapshot. La meilleure méthode serait de faire "umount;lvcreate -s;mount", mais on ne peut pas. On va donc avoir de préférence un système de fichier qui résiste au crash (ext3 par exemple) et limiter la casse avec sync :

$ sync
# on espère qu'il y aura le moins d'écriture possible entre ces 2 commandes
$ lvcreate -s -L 500M -s -n backup /dev/vg0/original

# et maintenant on a une durée de 500Mo d'écriture pour faire tranquillement notre backup
$ mount /dev/vg0/backup /mnt
$ tar cfz /backups/today.tgz /mnt # c'est vous qui voyez
$ umount /mnt
$ lvremove /dev/vg0/backup

Annulation

Maintenant supposons que nous voulions nous amuser avec notre système de fichier (par exemple pour tester un passage à la prochaine debian sans pour autant avoir peur de tout perdre. Sur / ça risque d'être un peu difficile. Pour ne pas vous perturber nous allons simplifier en utilisant le / d'une machine virtuelle (ou d'un chroot).

$ sync
# choisissez une grande taille, voire la même taille que la partition originale pour éviter tout problème
$ lvcreate -L 5G -s -n backup /dev/vg0/root
# pas besoin de monter le backup
# on bidouille
$ vi /etc/apt/sources.list && apt-get update && apt-get dist-upgrade

Et là paf c'est cassé, réparons (avec un noyau <= 2.6.27):

# on va le casser
$ umount /dev/vg0/root

# on récupère le backup dans un espace temporaire
$ dd if=/dev/vg0/bakup of=/srv/temp.dd

# et on le restaure sur le lv d'origine
$ lvremove /dev/vg0/bakup
$ dd if=/srv/temp.dd of=/dev/vg0/root

# fin
$ rm /srv/temp.dd
$ mount /dev/vg0/root

Le problème de cette technique est qu'elle nécessite un espace aussi gros que la partition disponible pour la restauration. Un petit gzip bien placé peut vous faire gagner en place, mais c'est pas top. Mais ... un patch est en cours pour permettre de faire tout ça en une seule commande et sans nécessiter d'espace intermédiaire. Il ne devrait malheureusement pas être disponible dans le noyau avant la version 2.6.28

# noyau > 2.6.27
$ lvconvert -M bakcup --nameorigin

Lire l'annonce pour plus de détails.

Deux snapshots

Remarquez que de même, il n'est pas possible de faire le snapshot d'un snapshot. C'est bien dommage car cela empêche de faire des tests sur un arbre de test et de revenir à l'endroit ou l'on veut. Ce genre de fonctionnalité n'est pas encore prévue. Il va donc falloir le faire soi-même, ou alors atendre la sortie de btrfs qui devrait permettre ce genre de chose directement sur le système de fichiers..

Donc en attendant, les commandes qui permettent de faire ça en utilisant des copies complètes :

# on snapshotte l'original
$ lvcreate -L 50M -s -n v1x /dev/vg0/v0

# on copie le snapshot (vérifier la taille)
$ lvcreate -L 5G -n v1 vg0
$ dd if=/dev/vg0/v1x of=/dev/vg0/v1
$ lvremove /dev/vg0/v1x

# et on peut resnapshotter
$ vcreate -L 500M -s -n v2 /dev/vg0/v1

Après l'immense succès du premier article, voici sous vos applaudissements le deuxième article.

Ajout d'un nouveau disque

Maintenant que vous savez utiliser LVM vous voudriez aller un peu plus loin. Mise en situation : vous avez un disque de 50To, un vg déjà en place et sur sur ce VG un LV de 30To dédié à votre médiathèque. Or vous venez de découvrir (et donc d'acheter) un nouveau disque de 1Po (Péta Octet pour ceux qui ne suivent pas, hé oui, c'est fou comme ça avance vite la technologie).

$ lvdisplay /dev/vg0/mediatheque
  --- Logical volume ---
  LV Name                /dev/vg0/mediatheque
  VG Name                vg0
  LV UUID                AN0y7h-1cIF-cPmC-vE9E-JnKG-worn-dWeQ8D
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                31,82 TB
  Current LE             81459200
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

Commençons donc par ajouter notre nouveau disque au vg :

# partitionnement
$ cfdisk /dev/sdc
# formatage
$ pvcreate /dev/sdc1
# ajout au vg
$ vgextend vg0 /dev/sdc1

Et voila nous avons de la place disponible. Maintenant agrandissons notre LV. Remarquez qu'il faut le faire avant d'agrandir le système de fichier puisqu'il se trouve au dessous. Au contraire en cas de réduction, il faut commencer par le système de fichier qui se trouve au dessus.

$ lvextend -l +100%FREE /dev/vg0/mediatheque
# cas de l'ext2/ext3
$ umount /dev/vg0/mediatheque
$ resize2fs /dev/vg0/mediatheque
$ mount /dev/vg0/mediatheque

Remarquez que chaque système de fichier a ses propres contraintes quant au redimensionnement :

• ext2 doit être démontés
• ext3 doit être démonté pour être réduit, il semblerait qu'il est possible de l'agrandir monté (voir ext2online)
• reiserfs peut être agrandi monte, mais doit être démonté pour être réduit
• xfs peut (et doit) être agrandi monté, mais ne peut pas être réduit
• jfs peut (et doit) être agrandi monté, mais ne peut pas être réduit

En résumé :

Suppression d'un disque

Il est possible de faire la même chose dans l'autre sens a quelques subtilités près. Il faut forcer la désallocation de l'espace présent sur ce disque. Pour cela on va réduire un système de fichier pour faire de la place, puis faire en sorte que cette place libre soit sur le disque à retirer, et enfin retirer ce disque du groupe. Le tout pouvant se faire en direct.

Comme dit précédemment, lors d'une réduction, le système de fichier doit être réduit en premier :

# supposons de l'ext3
$ umount /dev/vg0/mediatheque
# il faut préciser la nouvelle taille puisqu'il n peut pas la deviner seul
$ resize2fs -p /dev/vg0/mediatheque 1024G
$ mount /dev/vg0/mediatheque
# réduction du lv, je vous conseille d'utiliser la taille absolue pour éviter les erreurs
$ lvreduce-L 1024G /dev/vg0/mediatheque

On fait en sorte que le disque à supprimer ne contienne plus de données :

# il se débrouille pour savoir où mettre les données
$ pvmove /dev/sdb1

Et enfin on le supprime du vg :

$ vgreduce vg0 /dev/sdb1

Supposons que vous ayez une application qui envoie régulièrement des mails. Vous voulez tester cette application en conditions réelles, mais sans envoyer ces mails (par exemple un logiciel de spam :-)

Pour ne pas tout casser, nous allons juste changer la configuration du serveur utilisé pour envoyer les mails. Tous les mails, tous domaines et tous destinataires confondus seront acceptés.

Étape 1 : tout rediriger vers le compte de quelqu'un

Prenons un postfix. Ajoutons une ligne dans main.cf :

# on matche les mails qu'on va accepter avec des expression régulières
virtual_alias_maps = regexp:/etc/postfix/virtual

Créons notre fichier /etc/postfix/virtual :

# on redigige tout vers quelqu'un qui va pouvoir lire les mails
/@/	peck@ditoto.com

C'est bien mais on voudrait pouvoir centraliser ce serveur de test et trier les mails envoyés en fonction des serveurs d'origine (développement, recette, qualification ...).

Étape 2 : filtrer

On va donc rediriger vers un compte local créé pour l'occasion (si vous avez des comptes virtuel, il faut faire différemment, vous saurez faire) :

$ adduser genericmail

On adapte /etc/postfix/virtual et on n'oublie pas de laisser passer les destinataires finaux sous peine de boucles :

# on redirige tout vers notre filtre
if !/@ditoto.com$/
/@/	genericmail
endif

On relaie les mails de ces mêmes destinataires finau[xd] vers leur vrai serveur dans main.cf et on se prépare à utiliser procmail :

relay_domains = ditoto.com
mailbox_command = /usr/bin/procmail -Y -a $DOMAIN

Et enfin, le plus important, nous allons filtrer avec un procmail (au passage vérifiez qu'il est installé :-p) :

# on redirige en fonction du destinataire
:0
* ^TO.*@gnagna.fr.*
! peck@ditoto.com

# plus important, on peut le faire en fonction de la source
:0
* ^Received:.*from mamachine.dev.ditoto.com
! pock@ditoto.com

# et une petite règle par défaut pour ne pas être surchargé
:0
* ^.*
/dev/null

La fin

Voilà, vous avez un serveur mail paramétrable qui vous permet de faire ce que vous voulez des mails qu'il reçoit, quels que soient leurs destinataires. Rien de bien compliqué, mais bien pratique en environnement de test.