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
Attachment:
signature.asc
Description: This is a digitally signed message part.