Principe: o Les comptes utilisateurs sont tous directement (sans hierarchie) a plat dans la branche ldap de l'asso (dc=smeuh,dc=loc); ils ne sont pas spécialement rattachés à un domaine particulier. o Les aliases mail sont dans des branches ldap distinctes, par nom de domaine o Un utilisateur donné à droit de controle sur les données ldap de son propre compte user, et sur la/les branche(s) aliases de son/ses doms. o Un suffixe de base du genre "dc=smeuh,dc=loc" : actuellement c'est "dc=reynerie,dc=org" ce qui ne fait plus de sens. Je pense qu'il est preferable de distinguer la branche de gestion du domaine smeuh.org (du type "dc=smeuh,dc=org", qui, a l'instar des autres domaines, contient les Aliases) de la racine administrative & branche people de l'annuaire (branche "speciale", d'ou le "dc=loc" et non "dc=org"). Avantages (selon ben) : o Un user n'est "inscrit aupres de" / n'a de "compte a rendre" qu'a l'asso - modèle non hiérarchique. un user n'est pas inféodé/affilié/soumis à un autre user propriétaire de son "domaine de rattachement" (il n'y a plus de "domaine de rattachement"). - aucun autre user ne peux connaitre/lui changer/enlever son mot de passe - un user ayant souscrit sa cotis (ou pas) ne peux pas voir son compte droppé/locké par un autre user, ou perdre l'accès à ses mails, ... - un user n'est pas obligé de modifier son rapport/login/... a l'asso si un domaine disparait, n'est pas renouvellé etc o Si un user veux un mail sur le domaine de son pote, il le lui demande - le proprietaire du domaine a juste a ajouter un alias (vs. creation d'un compte complet, avec mot de passe, choix de shell, transmission des infos sur canal securise au demandeur...) - l'utilisateur beneficiant de la nvlle addr email n'a rien a reconfigurer de son cote (aucun chgmt sur le client mail, etc) o Les logins / pass de base, shell comme mail, ne necessitent plus l'ajout d'un suffixe du genre "@mondom.com", du coup - le format des logins est unifié et traditionnel (moins de jonglerie dans la conf des services) - le '@mondom' forcé n'a pas vraiment toujours de sens (ex. mutah, pnine, etc: pourquoi seraient-ils symboliquement inféodés à un domaine donné ?) - les paths et noms des homes et mailboxes peuvent alors etre traditionnels et straightfowrard (par ex. /home/toto/ , /var/mail/toto/) o N'utilise que des attributs ldap déjà intégrés dans les schémas fournis avec le paquet slapd - soit des standards (core, ...), soit des drafts de rfc (schema "misc" pour le rfc822MailMember: mais attention, incompatible avec qmail.schema) Inconvenients (selon ben) : o Il faut créer l'acl dn.subtree correspondante sur la branche aliases lors de l'ajout d'un nveau domaine sur le systeme - mais idem avec les autres modeles utilisant ldap lui-meme pour le controle des actions users sur les domaines - dans un premier temps, l'ajout de domaines demande de toutes façons des checks et modifs en plus du pur ldap (verif qu'un type n'est pas en train de piquer le domaine d'un voisin, ajout dans la conf named, ...) o Les noms de comptes courants sont servis au premier arrivé - mais l'assignation des comptes users dans des sous-branches par domaine divise le probleme mais ne le resoud pas non plus (ie. il peux aussi y avoir plusieurs "olivier" souhaitant un compte @reynerie.org). o Migration de l'existant : - il faut voir au cas par cas ce qu'on fait pour les gens qui ont plusieurs mailboxes (ex. ben@zouh.org & ben@reynerie.org): on peux leur proposer de leur faire deux comptes (genre "ben" et "ben_reynerie"), ou de merger les boxes et faire un alias. Les users concernés sont al, ben, oolive, pnine et tof (a priori). - changement de login potentiel (pour enlever le '@domaine'). pas absolument necessaire (on peux dire a dovecot d'utiliser la partie avant le '@' comme login), mais comme de tt facon on doit transmettre des infos sur modifs de conf mua aux users (noms des serveurs a utiliser pour profiter de la couverture par le certificat ssl, params pour l'auth smtp) ... - modifs de l'annuaire ldap (et deplacement/renommage des homes et mailboxes si on souhaite remettre a plat ceci) Exemple possible (non testé !) de conf postfix et dovecot correspondante (mais je pense que pour postfix, il est peut-etre plus prudent de generer par cron les listes de comptes/aliases, histoire de ne pas bouncer si le ldap est indispo): /etc/postfix/main.cf : virtual_minimum_uid = 200 virtual_uid_maps = static:200 # vmail:vmail virtual_gid_maps = static:200 mydestination = smeuh.loc, $myhostname, localhost.$mydomain, localhost virtual_mailbox_maps = ldap:/etc/postfix/virtual_mailbox.cf virtual_alias_maps = ldap:/etc/postfix/virtual_alias.cf /etc/postfix/virtual_alias.cf : server_host = localhost search_base = ou=Aliases,dc=%2,dc=%1 bind = no query_filter = (cn=%u) result_attribute = rfc822MailMember /etc/postfix/virtual_mailbox.cf server_host = localhost search_base = ou=People,dc=smeuh,dc=loc bind = no query_filter = (&(mail=%s)(AccountStatus=active)) result_attribute = mail # eg. /var/mail/toto/ result_format = /var/mail/%u/ /etc/dovecot/dovecot.conf # en theorie, devrait etre retrocompatible avec logins user@dom (car on # prends le "%n", soit la partie "user" seule si format user@dom) mail_location = maildir:/var/mail/%n auth default { passdb pam { args = cache_key=%u dovecot } passdb ldap { args = /etc/dovecot/dovecot-ldap.conf } # on ne depends pas du ldap pour le userdb (donc pas de pb de # distribution si pb de ldap) userdb static { args = uid=200 gid=200 home=/var/mail/%n userdb_mail=maildir allow_all_users=yes mail=maildir:/var/mail/%n } ... } /etc/dovecot/dovecot-ldap.conf # idem: on utilise "%n" et non "%u" pour retro-compat format "user@dom" uris = ldap://localhost base = cn=%n,ou=People,dc=smeuh,dc=loc auth_bind = yes auth_bind_userdn = cn=%n,ou=People,dc=smeuh,dc=loc