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.
- 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?
This was more of a requirement for the design, i.e. avoiding unnecessary lookups and things like that.
There are about 10 hosted domains and the most active one has about 300 accounts, which is not very much. The others are much less active and have much less users. But it is quite possible those numbers will grow in the next year. The hardware is a dual quad core Xeon 5520 with 12GB RAM and four SATA disks RAID-10ed together. Up until now the server hasn't broken a sweat.
- 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?
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.
Sounds reasonable.
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.
Right, I thought as much as well. Real users (i.e. not accounts in virtual domains) are no concern in our simple ISP-like setup so while basing everyting on NSS is a very elegant and transparent solution, as Dan has explained, I think it's too much additional complexity for us.
Thanks again for your reply, much appreciated.
Andreas