Introduction aux tables de correspondances

Introduction

• Le modèle de table de correspondance de Postfix
• Listes et tables de Postfix
• Préparer Postfix pour les consultations LDAP ou SQL
• Maintenir les fichiers tables de correspondances de Postfix
• Mettre à jour les fichiers BD Berkeley en sureté
• Types de tables de correspondances de Postfix

Le modèle de table de correspondance de Postfix

Postfix utilise les tables de correspondances pour stocker et lire les informations de contrôle d'accès, de réécriture d'adresses et pour le filtrage du contenu. Toutes ces tables sont indiquées dans le fichier main.cf sous la forme "type:table", où "type" est l'une des bases de données décrites au paragraphe "Postfix lookup table types" à la fin de ce document, et où "table" est le nom de la table de correspondance. La documentation de Postfix utilise les termes "base de données" et "table de correspondance" pour la même chose.

Exemples de tables de correspondances apparaissant souvent dans la documentation de Postfix :

/etc/postfix/main.cf:
    alias_maps = hash:/etc/postfix/aliases            (alias locaux)
    header_checks = regexp:/etc/postfix/header_checks (filtrage du contenu)
    transport_maps = hash:/etc/postfix/transport      (table de routage)
    virtual_alias_maps = hash:/etc/postfix/virtual    (réécriture des adresses)

Toutes les tables de correspondances de Postfix stockent les informations sous la forme de paires (clef, valeur). Cet interface peut paraître simpliste au premier abord, mais elle est très efficace. L'interface de requête (clef, valeur) masquent complêtement la complexité LDAP ou SQL de Postfix.

Bénéfices de l'interface de requête (clef, valeur) :

• Vous pouvez implémenter d'abord les tables de correspondances de Postfix avec des bases locales Berkeley (fichiers) et après basculer sur LDAP ou MySQL sans aucun impact sur la configuration de Postfix comme décrit au paragraphe "Préparer Postfix pour les consultations LDAP ou SQL" plus bas.
• Vous pouvez utiliser les fichiers Berkeley DB avec des correspondances fixes pour des opérations simples de réécriture d'adresses et utiliser des tables d'expressions rationnelles pour des travaux plus complexes.

Listes et tables de Postfix

Beaucoup de tables de correspondances de Postfix sont utilisées. Par exemple les réécritures d'adresses (la clef est l'ancienne adresse et la valeur la nouvelle) ou les contrôles d'accès (la clef est le client et la valeur correspond à l'action comme "reject").

Avec certaines tables, Postfix n'a besoin que de savoir si la clef existe. Le résultat de la consultation n'est pas utilisé lui-même. Par exemple, la table passée en paramètre à local_recipient_maps détermine les destinataires locaux que Postfix accepte dans le courrier issu du réseau , celle passée au paramètre mydestination les domaines livrés localement et celle passée à mynetworks les adresses IP considérées sûres. Techniquement, ce sont des listes et non des tables. En dépit de la différence, les listes de Postfix sont décrites ici car elles utilisent la même infrastructure que les tables de correspondances.

Préparer Postfix pour les consultations LDAP ou SQL

SQL et LDAP sont des systèmes complexes. Essayer de mettre en œuvre simultanément Postfix et LDAP ou SQL n'est pas une bonne idée. Vous pouvez vous éviter de nombreux problèmes en implémentant d'abord Postfix avec des fichiers locaux type Berkeley DB. Ces fichiers cachent peu de surprises et sont faciles à déboguer avec la commande postmap(1) :

% postmap -q info@exemple.com hash:/etc/postfix/virtual 

Une fois que vos fichiers locaux fonctionnent correctement, vous pouvez suivre les instructions des pages de manuel ldap_table(5), mysql_table(5) ou pgsql_table(5) et remplacer ces fichiers par des requêtes LDAP ou SQL. Dans ce cas, vous pouvez toujours utiliser la commande postmap(1) pour vérifier que les bases de données fournissent bien le même résultat :

% postmap -q info@exemple.com ldap:/etc/postfix/virtual.cf 

Vérifiez toutes requêtes à base d'adresses partielles ou sous-domaines qui sont documentées au paragraphe "ordre de recherche dans les tables" dans la page de manuel correspondante : access(5), canonical(5), virtual(5), transport(5), ou dans la documentation du paramètre de configuration correspondant : mynetworks, relay_domains et parent_domain_matches_subdomains.

Maintenir les fichiers tables de correspondances de Postfix

Lorsque vous effectuez des changements dans la base de données lorsque le système de messagerie est en fonctionnement, il est souhaitable que Postfix sache que les informations ont changé. Le faire sans avoir à exécuter "Postfix reload" améliore nettement les performances car le lencement de cette commande ralentit sensiblement le serveur le temps du rechargment.

• Si vous changez une base en réseau comme LDAP, NIS ou SQL, il n'y a pas besoins de lancer "postfix reload". Les serveurs LDAP, NIS ou SQL gèrent les conflits de lecture/écriture et fournissent les nouvelles données à Postfix dès qu'elles sont disponibles.

• Si vous changez un fichier d'expressions rationnelles regexp: ou pcre:, Postfix reliera peut-être le fichier immédiatement. C'est parce que Postfix lit le fichier entier lorsqu'il en a besoin et le garde en mémoire sans rexaminer le fichier.

  • Si le fichier est utilisé par un programme lancé ponctuellement tel smtpd(8), cleanup(8) ou local(8), il n'est pas nécessaire de lancer "postfix reload" après modification.

  • Si le fichier est utilisé par un processus lancé longtemps tel trivial-rewrite(8) sur un serveur chargé, il est nécessaire de lancer "postfix reload".

• Si vous changez un fichier local type DBM ou Berkeley DB, il n'est pas nécessaire de lancer "postfix reload". Postfix utilise des verrous pour éviter les conflits d'écriture/lecture et chaque fois qu'un démon découvre qu'un fichier a changé, il se termine avant de prendre une nouvelle requête ainsi le nouveau processus peut utiliser la nouvelle base de données.

Mettre à jour les fichiers BD Berkeley en sureté

Comme Postfix utilise des verrous de fichiers pour éviter les conflits lors des mises à jour des bases Berkeley DB ou des autres fichiers bases de données locaux, vous pouvez rencontrer un problème lors des mises à jour, car les commandes postmap(1) ou postalias(1) écrasent le fichier existant. Si la mise à jour rate au milieu alors la base sera inutilisable et Postfix arrêtera son travail. Ce problème ne se pose pas avec les bases de données de type CDB disponibles à partir de la version 2.2 de Postfix, car la reconstruction des bases CDB est atomique.

Avec des bases sur fichiers multiples comme DBM, il n'y a pas de solution simple. Avec les bases Berkeley DB et les autres bases à fichier unique, il est possible d'ajouter une sécurité en utilisant la commande "mv" pour remplacer un fichier existant au lieu de l'écraser :

# postmap access.in && mv access.in.db access.db

Ceci convertit le fichier "access.in" en une base "access.in.db" et remplace le fichier "access.db" seulement si la commande postmap(1) se termine avec succès. Pour améliorer ce dispositif, beaucoup utilisent "make" comme montré ci-dessous. Les entrées utilisateur correspondent aux caractères en gras.

# cat Makefile
all: aliases.db access.db virtual.db ...etc...

# Note 1: les commandes sont insérées après un caractère tabulation.
# Note 2: utilise postalias(1) for les alias locaux, postmap(1) pour le reste.
aliases.db: aliases.in
	postalias aliases.in
	mv aliases.in.db aliases.db

access.db: access.in
	postmap access.in
	mv access.in.db access.db

virtual.db: virtual.in
	postmap virtual.in
	mv virtual.in.db virtual.db

...etc...
# vi access.in
...session d'édition non montrée...
# make
postmap access.in
mv access.in.db access.db
#

La commande "make" ne met à jour que les fichiers qui ont changé. En cas d'erreur, elle s'arrête et n'appelle pas la commande "mv" ainsi Postfix continue de fonctionner avec l'ancienne base comme si de rien n'était.

Types de table de correspondances de Postfix

Pour obtenir la liste des types de bases de données que votre système Postfix supporte, utilisez la commande "postconf -m" command. Ci-dessous une liste des bases souvent supportées :

btree

Une structure en arbre balancé et trié. Ce n'est valable que si votre système supporte les bases Berkeley DB. Les fichiers sont créés avec les commandes postmap(1) ou postalias(1). Le nom de la table de correspondance utilisée dans "btree:table" est le nom du fichier base de données sans l'extension ".db".

cdb

Une structure optimisée pour la lecture sans support des mises à jour incrémentales. Les fichiers sont créés avec les commandes postmap(1) ou postalias(1). La nom de la table de correspondance utilisé dans "cdb:table" est le nom de du fichier de la base de données sans le suffixe ".cdb". Cette fonctionnalité est disponible à partir de la version 2.2de Postfix.

cidr

Une table qui associe des valeurs avec des expressions "Classless Inter-Domain Routing" (CIDR). Le format de ces tables est décrit à la page de manuel cidr_table(5).

dbm

Un fichier indexé basé sur des hachages. Ce n'est disponible que si votre système supporte les bases Berkeley DB. Les fichiers sont créés avec les commandes postmap(1) ou postalias(1). Le nom de la table de correspondance utilisée dans "dbm:table" est le nom du fichier base de données sans l'extension ".dir" ou ".pag".

environ

Le tableau de variables d'environnement UNIX. La clef est le nom de la variable. Le nom de la table de correspondances passé dans "environ:table" est ignoré.

hash

Un fichier indexé basé sur des hachages. Ce n'est disponible que si votre système supporte les bases Berkeley DB. Les fichiers sont créés avec les commandes postmap(1) ou postalias(1). Le nom de la table de correspondance utilisée dans "hash:table" est le nom du fichier base de données sans l'extension ".db".

ldap (lecture seule)

Recherche les correspondances en utilisant le protocole LDAP. Ce type de configuration est détaillé à la page de manuel ldap_table(5).

mysql (lecture seule)

Recherche les correspondances en utilisant une base de données MySQL. Ce type de configuration est détaillé à la page de manuel mysql_table(5).

netinfo (lecture seule)

Recherche les correspondances en utilisant les bases Netinfo.

nis (lecture seule)

Recherche les correspondances en utilisant les bases NIS.

nisplus (lecture seule)

Recherche les correspondances en utilisant les bases NIS+. Ce type de configuration est détaillé à la page de manuel nisplus_table(5).

pcre (lecture seule)

Une table de correspondances basée sur les expressions rationnelles compatibles Perl. Le format du fichier est décrit à la page de manuel pcre_table(5). Le nom de la table de correspondances utilisé dans "pcre:table" est celui du fichier.

pgsql (lecture seule)

Recherche les correspondances en utilisant une base de données PostgreSQL. Ce type de configuration est détaillé à la page de manuel pgsql_table(5).

proxy (lecture seule)

Accède aux informations via le service proxymap(8) de Postfix. La syntaxe du nom de la table de correspondances est "proxy:type:table".

regexp (lecture seule)

Une table de correspondances basée sue les expressions rationnelles POSIX. Le format du fichier est décrit à la page de manuel regexp_table(5). Le nom de la table de correspondances utilisé dans "regexp:table" est celui du fichier.

sdbm

Un type de fichier indexé par hachage. Ce n'est disponible que sur les systèmes qui supportent les bases de données SDBM. Les fichierssont créés avec les commandes postmap(1) ou postalias(1). Le nom de la table de correspondance utilisée dans "sdbm:table" est le nom du fichier base de données sans l'extension ".dir" ou ".pag".

static (lecture seule)

Retourne toujours le nom de la table de correspondances comme résultat. Par exemple, la table de correspondances "static:foobar" retourne toujours la chaîne "foobar" comme résultat de la consultation.

tcp

Accède aux informations par un serveur TCP/IP. Le protocol est décrit à la page de manuel tcp_table(5). Le nom de la table de correspondances est "tcp:machine:port" où "machine" indique un nom de machine ou une adresse IP et "port" un nom de service ou un numéro de port. Ce protocole n'est disponible qu'à partir de la version 2.1.

unix (lecture seule)

Une possibilité limitée pour interroger une base d'authentification UNIX. Les tables suivantes sont implémentées :

unix:passwd.byname

La table est la base de données de mots de passe UNIX. La clef est le nom de login. Le résultat est une entrée au format du fichier passwd(5).

unix:group.byname

La table est la base de données des groupes UNIX. La clef est le nom de groupe. Le résultat est une entrée au format du fichier group(5).

D'autres types de table de correspondances peuvent être disponible sur votre système suivant la manière dont à été compilé Postfix. Avec certaines distributions, la liste est extensible dynamiquement lorsque le support des tables de correspondances est lié dynamiquement à Postfix.

traduction par Xavier Guimard - Retour au menu