On Mon, 29 Nov 2010 12:00:49 +0200, Vladislav Bogdanov wrote: > 29.11.2010 11:08, J. Roeleveld wrote: >> On Monday 29 November 2010 09:36:11 Vladislav Bogdanov wrote: >>> 26.11.2010 18:14, Andreas Dick wrote: >>> >>> First, I'm definitely for having UUID in a DN instead of name. It's >>> a >>> way more general. >>> ... >>> >>>> 4) how to implement address groups? My first try will be to use >>>> simple >>>> subdirectorries for the groups. It fits all my needs and I will >>>> try to >>>> implement add/del/change groups in RC. This could look like that: >>>> >>>> my base_dn: >>>> ou=abook,dc=server >>>> >>>> example of an ungrouped address : >>>> cn=Firstname Surname,ou=abook,dc=server >>>> >>>> group exsample: >>>> o=My Groupe,ou=abook,dc=server >>>> >>>> example of an grouped address : >>>> cn=Firstname Surname,o=My Groupe,ou=abook,dc=server >>>> >>>> Patrik pointed that ou would fit better for the group: >>>> ou=My Groupe,ou=abook,dc=server >>>> >>>> I think this should be configured as well. >>> >>> I'd exploit native LDAP groups for that. >>> I mean: >>> >>> dn: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server >>> objectType: inetOrgPerson >>> uuid: 1cfeae5f-264e-4b4a-a8e9-efdb259df138 >>> ... >>> >>> dn: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server >>> objectType: inetOrgPerson (or whatever else that fits, because >>> inetOrgPerson has some drawbacks) >>> uuid: 2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34 >>> ... >>> >>> dn: cn=Group1,ou=abook,dc=server >>> objectType: groupOfNames >>> cn: Group1 >>> member: >>> uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server >>> member: >>> uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server >>> ... >>> >>> Then you can have one contact in multiple groups without object >>> duplication. >> >> This is ok for OS-level groups, but not for grouping addresses. > > This is a way LDAP supports general groups natively, nothing more. > >> How will you be able to integrate this with other Email clients? > > If all other clients in the universe use one standard implementation > of > LDAP addressbooks, then this way should be used here. > > If every developers group reinvents a wheel, then there is no way to > be > compatible with all others simultaneously. > > LDAP data tree is a very configurable, and there is no one common > point > of view on how data should be stored there. That's why it is very > difficult to make implementation to be compatible with all and to be > easy to setup. > > Look on how simple object can be accessed: > 1. Direct hit on constructed DN. > 2. One-level search on specific baseDN with filter. > 3. Subtree search on baseDN with filter. > 4. Getall search on subtree with filtering in a client (brain-dead). > > And what for groups, I see at least two possible ways to access data. > 1. GroupOfNames membership > 2. One-level/subtree search on addressbook branch with filter on > predefined attribute. > > Additionally, addressbook data may be placed either in one common > branch > with additional branching on uid, or under users own object. Or > attribute could be added to every object, which specifies whom this > object belongs to. > > And these are only native ways to do things. Many implementations are > broken from the very beginning and try to use LDAP as a relational > database. posixGroup/posixAccount is a good example. And it found its > way to RFC btw. > >> >> Also, why do you want address-entries into multiple groups? I fail >> to see the >> use-case for this. > > First, because this is supported be SQL addressbook backend. > Next, because user may want to (and they do) have one address > belonging > to several "perpendicular" groups: "Coworkers", "Beer-lovers", > "Bike-riders". > >> >> I use webmail when I'm accessing my email from a remote machine, but >> when I'm >> at home, I use a desktop email client. >> I do need to be able to use this client with the LDAP-tree as well. > > See above. > >> >> Additionally, the conventional way of securing the LDAP-tree uses >> ACLs. >> Writing ACLs to implement the schema you are proposing will be >> difficult at >> best. I can't even begin to think of a way to write them that would >> allow me >> to add an address. > > Even if you move that branch under user's own DN? > I mean something like that: > dn: > > uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=AddressBook,uid=blablabla,ou=People,dc=example,dc=com > > OpenLDAP allows very flexible wildcard ALCs.
As I understand is the today implementation of RC able to read such addressbooks allready...(?) On the other hand, is it as well possible to create/move entries out of RC in a such setup? How can RC get new UUIDs for new contacts? And how can RC handle (add/del/move) groups then? -> this is what I need and what I will try to implement first for an easy LDAP situation: groups with subdirs, which in my opinion can be read out of every client out there....(?) do you agree? Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/8f4f07cd
