Les fiches LDAP

Chez moi, une fiche LDAP peut comprendre jusqu’à 4 attributs différents liés au mail :

• mail contient l’adresse « officielle » de l’utilisateur
• mailLocalAddress contient ses alias locaux ; ils seront réécrits et remplacés par la valeur de l’attribut mail en sortie de site
• mailAcceptingAddress contient des alias « en réception seule », typiquement pour les groupes de travail
• mailRoutingAddress contient la destination des messages envoyés aux mailAcceptingAddress et mailLocalAddress de la fiche

En termes de schéma LDAP, nous avons ajouté ça au schéma de base d’OpenLDAP :

attributetype ( 1.3.6.1.4.1.7568.1.1.10
    NAME 'mailAcceptingAddress'
    DESC 'RFC822 alternate email address of this recipient'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

objectclass ( 1.3.6.1.4.1.7568.1.2.2 NAME 'ircamLocalMailRecipient' AUXILIARY
    DESC ''
    MAY ( mailAcceptingAddress ) )

objectclass ( 1.3.6.1.4.1.7568.1.2.10 NAME 'ircamAlias' SUP top STRUCTURAL
    DESC ''
    MAY ( mailRoutingAddress ) )

La classe d’objet ircamAlias ne sert que pour la gestion des alias indépendants des utilisateurs (listes de diffusion et redirections « vers l’extérieur » notamment). Nous allons la laisser de côté pour le moment.
Concrètement, un utilisateur ressemble à ça :

dn: uid=empion, ou=People, dc=example, dc=com
objectClass: account
objectClass: top
objectClass: inetLocalMailRecipient
objectClass: ircamLocalMailRecipient
objectClass: inetOrgPerson
objectClass: pilotPerson
objectClass: ircamAccount
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
objectClass: ircamPerson
uid: empion
mailRoutingAddress: empion@mailboxes.example.com
mailAcceptingAddress: tout-le-monde@example.com
mailAcceptingAddress: groupe-de-travail@example.com
mailLocalAddress: tartempion@example.com
mailLocalAddress: tarte.empion@example.com
mail: Tarte.Empion@example.com
sn: Empion
cn: Tarte Empion
uidNumber: 12345
gidNumber: 333

La configuration de Postfix

Postfix, c’est bien. Si, si. Je sais que vous en êtes déjà convaincus, mais c’est encore une occasion de le dire. Pour utiliser ce qui précède, il suffit de ces quelques lignes de config dans main.cf :

sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps = ldap:ldapcanon
ldapcanon_server_host = ldap.example.com
ldapcanon_server_port = 389
ldapcanon_search_base = dc=example,dc=com
ldapcanon_query_filter = (&(mailLocalAddress=%s)(mail=*))
ldapcanon_result_attribute = mail

virtual_maps = ldap:ldapvirt
ldapvirt_server_host = ldap.example.com
ldapvirt_server_port = 389
ldapvirt_search_base = dc=example,dc=com
ldapvirt_query_filter = (|(mailLocalAddress=%s)(mailAcceptingAddress=%s))
ldapvirt_result_attribute = mailRoutingAddress

C’est tout, rien de tordu à faire. Une fois ce bout de config en place, l’adresse source tartempion@example.com sera réécrite en Tarte.Empion@example.com (techniquement, tarte.empion@example.com sera réécrite aussi, mais ça ne fera ni chaud ni froid à la plupart des systèmes de courrier électronique actuels), et les messages envoyés à tarte.empion@example.com, tartempion@example.com, tout-le-monde@example.com et groupe-de-travail@example.com seront renvoyés à empion@mailboxes.example.com (et éventuellement à d’autres si ces mêmes alias sont aussi définis dans d’autres fiches). Elle est pas belle, la vie ?

Les scripts

OK, maintenant on sait à quoi les données peuvent ressembler, mais est-ce qu’il y a un outil plus simple que ldapvi pour les mettre dans l’annuaire ? Oui et non. J’ai bricolé récemment une petite série de scripts pour éditer l’attribut mailAcceptingAddress d’une fiche ; en pratique, c’est le seul qui varie plus ou moins souvent, les autres sont fixés à la création du compte. Les outils en question sont téléchargeables ici. L’archive contient :

• le module ircamldap.py qui initialise quelques variables utiles (serveur LDAP, mot de passe admin…)
• son fichier de configuration ircamldap.cfg
• les scripts add-mail-alias, remove-mail-alias et get-mail-aliases qui font l’essentiel du vrai boulot.

Pour l’utilisation de ces derniers, j’ai essayé de faire assez simple pour mes deux neurones ; en pratique, ça donne ça :

% get-mail-aliases empion
tout-le-monde@example.com
groupe-de-travail@example.com
% add-mail-alias empion monnouvelaliasquilestbien@example.net
% get-mail-aliases empion
tout-le-monde@example.com
groupe-de-travail@example.com
monnouvelaliasquilestbien@example.net
% remove-mail-alias empion monnouvelaliasquilestbien@example.net tout-le-monde@example.com
% get-mail-aliases empion
groupe-de-travail@example.com
%

Pour le moment, ces outils marchent à peu près mais il ne faut pas leur en demander trop. Entre autres, leur gestion des erreurs est assez minimale, et ils ne positionnent pas forcément toujours leur code de retour comme il faudrait. Ce sera pour la prochaine version.

Bien entendu, je suis preneur de toute suggestion, amélioration, patch ou autre « mais t’es con, ça fait 10 ans que ça existe en mieux ».

- Il est bizarre, ton café.
- Normal, c’est une bière. Tu es admin système ou pas ?

J’utilise linux-vserver sur une poignée de machines qui hébergent chacune quelques dizaines d’instances d’OS. Dans mon installation de base (CentOS), chaque isolateur fait tourner sendmail pour envoyer le mail local vers l’extérieur ; je parle essentiellement des rapports de logwatch et autres cronneries. Avec tous les problèmes habituels en cas de forte charge, ce qui arrive assez facilement dans ce genre de configuration.

Solution : installer un /usr/sbin/sendmail un peu plus léger, en l’occurrence ssmtp, sur toutes les machines sauf les vrais serveurs SMTP, qui eux font tourner Postfix.

La configuration puppet

Un petit extrait de ma config (nettement plus complète mais pas publiable en l’état) :

class mail{
}

class mail::smtp inherits mail {

package { "ssmtp": ensure => installed, }

file { "/etc/ssmtp/ssmtp.conf":
source => [
"puppet:///files/mail/ssmtp.conf.$hostname",
"puppet:///mail/ssmtp.conf",
],
owner => root,
group => root,
mode => 0644,
require => Package["ssmtp"],
}

exec { "setup_mta":
command => "/usr/sbin/update-alternatives --set mta /usr/sbin/sendmail.ssmtp",
subscribe => Package["ssmtp"],
refreshonly => true,
}

}

class mail::postfix inherits mail::smtp {

package { ["postfix", "postfix-pflogsumm"]: ensure => installed }

service { "postfix":
enable => true,
ensure => running,
hasstatus => true,
subscribe => Package["postfix"],
}

Exec["setup_mta"] {
command => "/usr/sbin/update-alternatives --set mta /usr/sbin/sendmail.postfix",
subscribe => Package["postfix"],
}

}

L’intérêt de la chose : toutes les machines sont dans la classe mail::smtp, et Postfix est installé uniquement là où il faut, et surtout une même machine peut cumuler les rôles « serveur SMTP » et « autre chose » et tout se passera comme il faut.

Pour le moment, ça installe ssmtp même sur les machines où il n’est pas nécessaire, on verra à corriger ça dans la prochaine version.