Table des matières
Liste des exemples
Table des matières
Table des matières
Table des matières
Cette section présente la configuration du serveur de mail utilisé généralement avec VHFFS : Exim.
Si vous voulez offrir un service de qualité, il est nécessaire de disposer d'au moins deux serveurs mail, le serveur mail primaire et le (ou les) serveur(s) mail secondaire(s). Leur configuration diffère, nous les présentons dans cette section.
Ce serveur est appelé mx1 dans les
documents relatifs à VHFFS (du fait qu'il s'appelle
généralement mx1.domaine.tld). Sa configuration est plus
complexe que pour le serveur mail secondaire. En effet, il va devoir
déterminer si les adresses sont des boîtes mail, des
redirections ou des listes de diffusion et agir en
conséquence.
Il est possible de faire en sorte que le mx1 utilise directement la base de VHFFS ou bien de répliquer celle-ci afin de réduire les coûts d'interrogation (pour plus d'information sur la réplication, consultez la section intitulée « Serveur mail primaire »).
La configuration à adapter se trouve dans le
répertoire vhffs-doc/config/exim4-mx1/ à la
racine des sources.
Les paramètres de connexion sont le premier élément à être définis par la biais de la variable pgsql_servers. Elle doit être précédée du mot clé hide pour éviter que des utilisateurs "ordinaires" puissent y accéder. Vous devez spécifier, dans l'ordre, l'adresse du serveur PostgreSQL (sous la forme hôte::port, il y a deux fois deux-points, ce n'est pas une erreur typographique, si vous utilisez le port par défaut vour pouvez l'omettre), le nom de la base de données, le nom d'utilisateur ayant accès aux données nécessaires et enfin son mot de passe.
Le serveur mail secondaire peut être configuré de deux façons différentes (en tout cas, nous n'en présentons que deux). La configuration à utiliser dépend de la façon dont vous souhaitez organiser votre architecture. Vous avez le choix entre faire en sorte que le serveur mail utilise directement la base de données VHFFS ou bien répliquer celle-ci à intervalles réguliers sur le mx2 (pour plus d'information, consultez la section intitulée « Serveur mail secondaire »).
La seule tâche du mx2 consiste à vérifier que les adresses qu'on lui soumet existent afin de relayer les mails correspondants au mx1, les adresses inexistantes seront ignorées.
Nous ne rentrons pas ici dans les détails de la configuration, nous présentons simplement l'interfaçage avec VHFFS, c'est-à-dire principalement les requêtes nécessaires à l'exploitation des adresses VHFFS par Exim.
Les paramètres de connexion se définissent de la même façon que pour le serveur mail primaire.
Seule la requête
PGSQL_RELAY_CHECKLOCALPART est à configurer,
elle permet de déterminer si une adresse est valide et doit
être relayée vers le mx1. Si vous utilisez directement la
base de données VHFFS, elle doit contenir la requête
suivante :
Exemple 2.1. Configuration du mx2 (utilisation de la base VHFFS)
PGSQL_RELAY_CHECKLOCALPART = ${lookup pgsql{SELECT d.domain
FROM vhffs_mxdomain d
WHERE d.domain = '$domain' AND (d.catchall != '' OR
EXISTS (SELECT domain FROM vhffs_boxes WHERE domain = '$domain' AND local_part = '$local_part') OR
EXISTS (SELECT domain FROM vhffs_forward WHERE domain = '$domain' AND local_part = '$local_part') OR
EXISTS (SELECT domain FROM vhffs_ml WHERE domain = '$domain'
AND (local_part = '$local_part' OR local_part || '-request' = '$local_part')))}}En cas d'utilisation de la réplication, la requête est beaucoup plus simple, évite de surcharger le serveur de base de données principal et devrait offrir de meilleures performances.
Exemple 2.2. Configuration du mx2 (réplication)
PGSQL_RELAY_CHECKLOCALPART = ${lookup pgsql{SELECT d.domain
FROM vhffs_mxdomain WHERE d.domain = '$domain' AND (d.catchall != '' OR
EXISTS (SELECT domain FROM vhffs_addresses WHERE domain = '$domain' AND local_part = '$local_part'))}}Le reste de la configuration relève d'une configuration classique d'Exim. Vous trouverez plus d'informations à ce sujet sur http://www.exim.org.
La configuration de myDNS est relativement simple. Deux cas peuvent
se présenter, soit vous utilisez directgement la vue
vhffs_dns_soavhffs_dns_rr, soit vous les dupliquez sur un serveur
secondaire. Dans les deux cas, la configuration est la même.
Comme nous l'avons vu, l'utilisation directe repose sur l'exploitation de la vue vhffs_dns_soa et de la table vhffs_dns_rr. La première est une vue regroupant tous les domaines, il est nécessaire que myDNS ne prenne en compte que ceux étant activés. Vous trouverez ci-dessous les options les plus significatives, laissez les autres à leurs valeurs par défaut :
Table des matières
Dans le cadre d'une architecture distribuée, il peut être souhaitable de répartir les services sur différentes machines. Le problème des performances dues à l'accès à la base de données distantes (celle directement alimentée par VHFFS) peut alors se poser. Pour palier à cela il est possible de répliquer certaines parties de la base principale sur les autres machines. Cela permet d'alléger la charge du serveur de base de données principal et d'améliorer les performances (puisque les requêtes sont locales). La contrepartie est un certain décalage possible entre les données du serveur principal et celles de la base de données esclave (les scripts étant exécutés à intervalle régulier).
Il s'agit du service bénéficiant du plus gros gain de performances. le NSS est utilisé pour l'identification des utilisateurs en SSH (utilisé notamment pour Subversion et CVS) ainsi qu'en FTP. Les différentes requêtes permettent d'afficher le propriétaire ou le groupe d'un fichier ainsi que de savoir si un utilisateur peut accéder à tel ou tel fichier (en obtenant ses UID/GID et en les comparant à ceux du fichier et aux permissions).
Historiquement, il s'agissait de fichiers qui étaient utilisés, aussi, les requêtes ne sont pas spécialement adaptées à une base de données. Le coût d'établissement d'une connexion peut être important dans le cas d'une base de données distante.
La solution proposée par VHFFS est d'utiliser une bibliothèque NSS basée sur SQLite (libnss-sqlite). La partie de la base de données PostgreSQL concernant les utilisateurs est dupliquée pour être utilisée par libnss-sqlite.
La configuration s'effectue de la même façon que n'importe quelle bibliothèque NSS :
récupérez la dernière version de libnss-sqlite sur http://libnss-sqlite.tuxfamily.org ;
si vous la compilez à partir des sources, utilisez les
classiques ./configure, make
et make install (seule la dernière
commande doit être effectuée en root). Lancez
./configure --help pour une
liste des options disponibles. Vous aurez besoin des
bibliothèques de développement de sqlite ;
modifiez le fichier /etc/nsswitch.conf
pour que les lignes passwd,
shadow et groups finissent par
sqlite ;
créez la base de données esclave, dans laquelle
les données seront répliquées. Par
défaut, il s'agit de /var/db/auth.sqlite
(créez le répertoire /var/db/ s'il n'existe pas). Pour cela,
lancez la commande suivante depuis le répertoire des sources
de libnss-sqlite : sqlite3 -init
conf/passwd.sql /var/db/passwd.sqlite; sqlite3 -init conf/shadow.sql
/var/db/shadow.sqlite (le premierfichier devrait
appartenir à root
et être en mode 644, le second en mode 640 au
moins) ;
Le système est désormais prêt pour
l'utilisation de la base SQLite comme source de données
d'authentification. Vous pouvez insérer un utilisateur dans la
table shadow de la base de données SQLite et
vérifier qu'il est bien reconnu en utilisant la commande
id nouvel_utilisateur.
Il est maintenant nécessaire de configurer le script de
réplication. Celui-ci doit s'exécuter sur le serveur
esclave (celui disposant de la base de données SQLite) par le
biais de cron (ou un outil
similaire).
Il se trouve dans le répertoire
%BACKEND_DIR%/mirror/nss-mirror.pl. Copiez ce
fichier sur le serveur esclave et éditez-le pour définir
les variables $PG_DB_HOST,
$PG_DB_PORT, $PG_DB_NAME,
$PG_DB_USER et $PG_DB_PASS pour
les adapter à votre configuration (n'oubliez pas de configurer le
serveur PostgreSQL maître pour qu'il accepte les connexions de la
part de l'esclave[1]). Si besoin, modifiez les variables
$ST_PW_DB et $ST_SP_DB pour
qu'elles correspondent aux fichiers de base de données SQLite
précédemment créé.
Ajoutez une entrée dans la crontab
pour lancer le script de manière régulière (toutes
les 5, 10 ou 15 minutes, ou n'importe quelle valeur acceptable pour
votre système). Il est conseillé de lancer une
première fois le script à la main pour vérifier
qu'il n'émet aucun message d'erreur, il est possible que vous
deviez installer le paquetage perl
DBD::SQLite.
Les utilisateurs enregistrés et actifs sur la plateforme VHFFS peuvent désormais accéder au serveur esclave en utilisant leur identifiants VHFFS.
Tout comme le NSS, myDNS peut profiter d'une réplication
partielle de la base pour éviter les interrogations trop
fréquentes vers le serveur principal. Contrairement au NSS cette
fois, la base esclave est également une base PostgreSQL. Les
données à répliquer sont présentes dans la
vue vhffs_dns_soa et la table
vhffs_dns_rr.
Seule la mise en place du script de réplication est décrite ici, la configuration de myDNS est décrite dans le la section intitulée « myDNS (serveur DNS) » (myDNS (serveur DNS)).
Le script est disponible après l'installation sous le
répertoire %BACKEND_DIR%/mirror/mydns-mirror.pl. Il est possible
de placer le script de réplication sur le serveur maître ou
sur le serveur esclave. Les serveurs PostgreSQL devront être
configurés selon les choix effectués. La configuration se
résume au positionnement des variables
$MASTER_DB_HOST, $MASTER_DB_PORT,
$MASTER_DB_NAME, $MASTER_DB_USER
et $MASTER_DB_USER (ainsi que leurs homologues
préfixées par $SLAVE_). Les variables
préfixées par $MASTER_
définissent les paramètres de connexion au serveur
maître (contenant la base de données VHFFS) tandis que
celles préfixées par $SLAVE_
définissent les paramètres de connexion au serveur
esclave.
Au niveau du serveur maître, le script a besoin
d'accéder à la vue
vhffs_dns_soa et à la
table vhffs_dns_rr. La base de
données esclave doit contenir au minimum deux tables,
vhffs_dns_soa et vhffs_dns_rr qui
ont le même schéma que la vue et la table sources des
données.
Le troisième service à disposer de scripts de réplication livrés avec VHFFS est le serveur mail Exim. Deux scripts sont fournis, le premier permet une réplication sur le serveur mail primaire (appelé mx1 dans la suite du document), le second une réplication sur le serveur mail secondaire. La principale différence entre les deux tient en la quantité de données répliquée. Dans le cas du mx1, il est nécessaire d'assurer le bon fonctionnement de listengine, aussi beaucoup de données propres à vhffs sont répliquées ; dans le cas du mx2, seules les données permettant de vérifier qu'une adresse existe bien sont répliquées.
Les configurations des serveurs mail sont fournies dans les
répertoires %DOC_DIR%/config/exim4-mx1/ et %DOC_DIR%/config/exim4-mx2/ à la
racine des sources. Vous trouverez plus d'informations dans la section intitulée « Exim (serveur mail) ».
La configuration de la réplication pour le serveur mail
primaire consiste à positionner les différentes
variables $MASTER_DB_HOST,
$MASTER_DB_PORT,
$MASTER_DB_NAME, $MASTER_DB_USER
et $MASTER_DB_USER (ainsi que leurs homologues
préfixées par $SLAVE_) dans le script
%BACKEND_DIR%/mirror/mx1-mirror.pl.
La configuration du script est analogue à celle du script
concernant le serveur mail primaire. Il suffit de positionner les
différentes variables du script aux valeurs adéquates
pour que la connexion aux deux bases de données se fasse
convenablement. Enfin, le script doit être lancé par
cron.
Le serveur mail secondaire, lorsqu'il est utilisé avec la configuration présentée dans ce manuel, se contente de vérifier que les adresses email sont connues du système. Aussi, il a besoin de très peu d'informations : les domaines mail, les boîtes, les redirections et les listes de diffusion existants.
Le schéma de la base de données est disponible
dans le répertoire
%BACKEND_DIR%/mirror/mx2-mirror.sql. La base
esclave utilisée peut contenir des champs
supplémentaires, cependant, ceux-ci devront avoir des valeurs
par défaut pour éviter toute interruption du
script.
Exemple 3.1. Schéma de base de données du serveur mail secondaire
CREATE TABLE vhffs_mxdomain(
domain VARCHAR,
catchall VARCHAR
);
CREATE TABLE vhffs_addresses(
local_part VARCHAR,
domain VARCHAR
);
CREATE UNIQUE INDEX vhffs_mxdomain_unique_domain ON vhffs_mxdomain(domain);
CREATE UNIQUE INDEX vhffs_addresses_unique_couple ON vhffs_addresses(local_part, domain);
Si vous migrez depuis VHFFS 4.0, il est possible que les tables vhffs_boxes, vhffs_forward et vhffs_ml de la base de données maître contienne des doublons entre elles. Cela vient du fait qu'il n'y avait pas assez de vérifications et qu'il était possible de créer une liste de diffusion ayant le même nom qu'une boîte mail ou qu'un forward et vice versa. Vérifiez donc bien qu'il n'y a pas de doublons avant de mettre en place la réplication, sinon cette dernière ne fonctionnera pas (vous pouvez également tenter de lancer la réplication à la main, elle vous indiquera si des erreurs surviennent).
[1] L'utilisateur défini dans le script n'a besoin que d'accéder aux tables vhffs_users, vhffs_user_group et vhffs_groups en lecture, il ne devrait pas disposer de plus de privilèges que nécessaire.