On Thursday, 7 October 2010 21:37:30 Andreas Ntaflos wrote: > On Tuesday 05 October 2010 10:19:37 Buchan Milne wrote: > > On Monday, 4 October 2010 19:47:16 Andreas Ntaflos wrote: > > > So the requirements are basically: > > > * Independent domains and users, i.e. [email protected] is > > > > > > completely different/distinct from [email protected], even > > > though both may be the same physical human being. > > > > > > * Thus accounts in different domains must have separate passwords > > > > > > fields > > > > > > * Groups and aliases must be possible > > > > What specifically do you mean by groups? > > Thank you too for your reply! It is most helpful. > > By group support I just mean the usual way to group users together, as > in ou=groups,dc=example,dc=com. Users on different hosted domains > won't/can't be in the same group, if that matters any.
But, what would you use the groups for? Authorization to specific services only available to specific groups? [...] > > > * Applications such as Apache, Ejabberd, Wikis and Webmail clients > > > (to > > > > > > name a few) which support LDAP authentication should be able to > > > query the DIT or DITs without needing any hacks or ugly constructs > > > (this is a vague requirement, I know). > > > > > > Now I believe the question basically boils down to this: > > > > > > Should we use multiple independent backend databases (DITs) or one > > > large "hosting" database as described in [1,2]? > > > > There are limits on the number of backend databases you can have, so > > for any hosting application, individual databases per domain will > > probably not be feasible. I would recommend a single database in > > most cases. What the suffix is is largely irrelevant IMHO. For > > example, there is almost no difference between > > [email protected],dc=example,dc=com (IOW, empty suffix) vs > > [email protected],dc=example,dc=com,o=mysitename. However, if > > accounts will have aliases on different domains, it does not make > > much sense to over- complicate the structure for no benefit, > > [email protected],o=mysitename would be fine. > > Ok, so a single hosting database is clearly the better approach (others > have suggested similarly). It also seems that a DIT for such a hosting > database doesn't have to be as complicated as I had initially thought, > which is great. > > However, when using [email protected],o=mysitename, how would Postfix > (or anything else) look up which virtual domains it is supposed to > serve, i.e. virtual_mailbox_domains? > > That's the one think about which I am not yet quite clear. In our > relational database there's a simple table "virtual_domains" with a name > and an ID for the hosted domains. Postfix only wants the key (the domain > name) to exist when doing a lookup so a query is just a simple "SELECT 1 > FROM virtual_domains WHERE name='%s'", %s being the domain name of > course. How would a "corresponding" LDAP query look like? Don't try and one-to-one map an RDBMS table to an LDAP container, start by mapping the query to an ldap search (basedn, filter, result attributes) first. You could use something like this: dn: domain=domain1.example.com,dc=example,dc=com objectclass: domain domain: domain1.example.com Then you would use an LDAP map with search_base = dc=example,dc=com query_filter = (&(objectclass=domain)(domain=%s)) result_attribute = domain You may choose to have more separation, with a separate basedn for domains, but it isn't necessary. But, depending on your requirements, you may need more complex schemas and/or layouts. Regards, Buchan
