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. john.doe@example.org is
completely different/distinct from john.doe@example.net, 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 uid=joe@example.com,dc=example,dc=com (IOW, empty suffix) vs uid=joe@example.com,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, uid=joe@example.com,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 uid=joe@example.com,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