Am Sonntag 19 Dezember 2010, um 22.50:06 schrieb Andreas Dick: > Hei LDAP gurus listening on RCD > > I try to write a howto for a simple LDAP server setup, such that LDAP > dummies out there should be able to setup a server from scratch working > with RC "out of the box". (No, I do not write it for you if you are > knowing how to setup a LDAP server yourself! Just for beginners how I have > been some month ago:-) > > My first question is, what structure should such a server have... I know, > there exist a plenty of professional solutions, but what I want is just: - > a verry good RC support, including especially groups > - good support for other clients (Thunderburd, Kaddressbook, Outlook, ...) > ( if they do not support groups as we do, it sould at least be possible > to read/write contacts) > - RC must stay compatible with other LDAP servers as it is today > > Now, what structure do I propose? I prefere two different directory trees: > > 1) Addressbook directory with grouping subdirectories: > # the base > dn: ou=rcaddrbook,dc=localhost > # some groups: > dn: ou=Group1,ou=rcaddrbook,dc=localhost > dn: ou=Group2,ou=rcaddrbook,dc=localhost > # some contacts > dn: cn=Conact 1,ou=Group1,ou=rcaddrbook,dc=localhost > dn: cn=Conact 2,ou=Group1,ou=rcaddrbook,dc=localhost > dn: cn=Conact 3,ou=Group2,ou=rcaddrbook,dc=localhost > > -> this structure works fine with one restriction: having a contact in two > groups means having duplicates, and this is bad > but this is easy to use in RC and even in Kaddressbook while crating a > static addressbook per group (RC will learn to read the group-list soon if > needed) > > 2) Addressbook directory with seperate group list in a sub, contacts and > groups are connected with the member attribute: > # the base > dn: ou=rcaddrbook,dc=localhost > # group and member dirs > dn: ou=Groups,ou=rcaddrbook,dc=localhost > dn: ou=Members,ou=rcaddrbook,dc=localhost > # some groups (not all attributes shown here!) > dn: cn=Group1,ou=Groups,ou=rcaddrbook,dc=localhost > member: cn=Contact 1,ou=Members,ou=rcaddrbook,dc=localhost > member: cn=Contact 2,ou=Members,ou=rcaddrbook,dc=localhost > dn: cn=Group2,ou=Groups,ou=rcaddrbook,dc=localhost > member: cn=Contact 3,ou=Members,ou=rcaddrbook,dc=localhost > # some members > dn: cn=Contact 1,ou=Members,ou=rcaddrbook,dc=localhost > dn: cn=Contact 2,ou=Members,ou=rcaddrbook,dc=localhost > dn: cn=Contact 3,ou=Members,ou=rcaddrbook,dc=localhost > > -> this structure works fine on my server, including memberOf search just > in the "Members" subdir. I do not know the restrictions of this structure > yet, clients like RC and Kaddressbook again can access at least with > "addressbook per group", but again, RC will learn to get the grouplist > soon (if wanted) While testing 2), I found a big drawback of it: if the contact is removed or a new contact is added by a client not handling goups, the member (and even memberOf) addributes are invalid and inconsistent. thus RC would have to check the consistency at each ldapserch... and this is not the meaning of such a stucture.
In meantime I found an other, alias based structure. It looks like 1) but not the contatcts are stored in the goup dirs, but just aliases (links) to them: 3) # the base dn: ou=rcaddrbook,dc=localhost # group and contact dirs dn: ou=groups,ou=rcaddrbook,dc=localhost dn: ou=contacts,ou=rcaddrbook,dc=localhost # some groups: dn: ou=Group 1,ou=groups,ou=rcaddrbook,dc=localhost dn: ou=Group 2,ou=groups,ou=rcaddrbook,dc=localhost # some contacts, all stored in the same dir dn: cn=Conact 1,ou=contacts,ou=rcaddrbook,dc=localhost dn: cn=Conact 2,ou=contacts,ou=rcaddrbook,dc=localhost dn: cn=Conact 3,ou=contacts,ou=rcaddrbook,dc=localhost # a contacts belonging to a group (not all attributes shown here!) dn: cn=Conact 1,ou=Group 1,ou=groups,ou=rcaddrbook,dc=localhost objectClass: alias aliasedObjectName: cn=Conact 1,ou=contacts,ou=rcaddrbook,dc=localhost -> it is now possible to search after all contacts belonging to a group (dereferenced search), or, also to the goups to which a contact belongs (not dereferenced search).... -> if any client is adding a new contact to "ou=contacts,..." , a new ungrouped contact is added. -> if a client is removing a contact without the alias, the alias still exists but do not disturb the structure, it is easy to remove it once later I am testing this structure now... but what do you think about? thanks Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/8f4f07cd
