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. ...
- 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:
- Direct hit on constructed DN.
- One-level search on specific baseDN with filter.
- Subtree search on baseDN with filter.
- 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.
- GroupOfNames membership
- 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/aba52c80