On Monday, 4 October 2010 19:47:16 Andreas Ntaflos wrote:
Hi,
I will probably also post this to the Postfix mailing list but it is fundamentally an (Open)LDAP question so here goes:
Short version: What is a recommended way to set up virtual mail hosting based on OpenLDAP? I.e. providing mail and authentication services, like SMTP and IMAP, using Postfix and Dovecot, for multiple *independent domains* such as example.net, example.org, example.com?
I am looking for RTFMs, HOWTOs, blogs, or any experience and anecdotes users on this list can provide. I myself no experience designing a DIT in LDAP (I am more at home in Postgres) and have much learning to do.
Long version: I know such setups exist and I have found many references in the archives of this list but there was never a completely straigt- forward answer that didn't say "it depends on your requirements" or involve frontends/add-ons like Jamm or Phamm, which I have no interest in.
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?
- Performance should not be terrible, obviously
How many accounts, and what are the specs (memory, CPU speed, disk speed) of the hardware you will be running the LDAP server on?
- 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.
Which of the two is the better approach? Which is more flexible, which has less administrative or functional overhead?
Obviously multiple databases gives you more flexibility for more administrative overhead.
The advantages of multiple databases are: -Different index settings -Independent replication configuration -Different access controls
If these will not provide significant benefits, the additional overhead of managing multiple databases (and their tuning) is not justified IMHO.
If we use multiple DITs we probably will have to glue them together somehow, won't we? How would queries against multiple independent DITs look?
Our current setup is more like [1,2], one big hosting database. It is a PostgreSQL database with a few tables for virtual domains (virtual_mailbox_domains in Postfix), virtual users (virtual_mailbox_maps), virtual aliases (virtual_alias_maps) and a few others. It is based loosely on [3].
This works fine but now the need has arisen to see if we can migrate that setup to an LDAP-based one, mainly for flexibility and compatibility with various authentication needs: many applications and services provide some kind of LDAP-based authentication but are hopelessly overwhelmed with SQL backends, especially when the queries are a bit complex.
Thanks in advance!
While NSS was mentioned, I would avoid stuffing everthing through NSS, when all the applications you have listed so far already have direct LDAP support. However, if you are going to use LDAP for any "system" accounts, you may want to consider the DIT structure a bit more carefully than if you aren't.
Regards, Buchan