Hi everyone
I've been trying for a while now to get mod_shared_roster_ldap building rosters from the LDAP directory running on our Zimbra server, which I believe is OpenLDAP behind the scenes.
Here's a quick view of the LDAP schema that I'm trying to work with...
Basically I'm looking to have LDAP rosters based on the dc=domain1 and dc=domain2 branches. The rosters should list the uids within those branches, subject to a further filter.
The human-readable name of each group should be the value of the zimbraDomainName attribute under dc=domain1/dc=domain2 (see top screen in the above image).
Then the members of each group are defined by the zimbraMailDeliveryAddress attribute under each uid.
The problem is that there isn't an attribute under each uid which exactly matches a group/roster attribute.
The attribute under each uid that I need to match to the group name is actually an e-mail address and I need the domain part of the e-mail address to match to the zimbraDomainName attribute of the parent dc
Where {group name} is the value of zimbraDomainName from dc=domain1,dc=com as shown in the 1st screen
To make things more difficult, I only want to show certain uids under each domain1/domain2 group. But I have that filter figured out...
(&(objectClass=organizationalPerson)(zimbraAccountStatus=active)(|(zimbraIsSystemResource=FALSE)(!(zimbraIsSystemResource=*)))(|(zimbraHideInGal=FALSE)(!(zimbraHideInGal=*))))
Anyone know if it's possible to get what I'm looking for with this schema?
I've been trying various combinations of ldap_rfilter, ldap_gfilter and ldap_ufilter but I can't get it to work.
Also I'm not sure how to create a %g variable and then where it can be used.
Any ideas?
Cheers, B
Assuming you use the bundled
Assuming you use the bundled msrl:
you cannot do what you want unless you have some attribute in common among your group members (maybe tey have some other attribute set to the same value? perhaps zimbraMailHost?).
You may want to look at modified version that addresses this (among others) limitation.
Ok it's good to know that
Ok it's good to know that it's a limitation in the module. I'm not just being stupid :)
I don't want to use too many customisations - I'll always forget the steps after an upgrade.
zimbraMailHost is the same for both domain1.com and domain2.com as the mail for both domains is handled by the same server and same LDAP directory.
I'm trying to be clever and coming up with an ejabberd config that works for all domains on the LDAP server, and shows the other users under each domain.
I can get around this by writing host-specific module definitions for mod_shared_roster_ldap.
It just means I have to set up each domain in ejabberd rather than using a simple config for all domains/users on a particular LDAP server server.
If I just set ldap_base to the branch of the domain I'm defining eg: ou=people,dc=domain2,dc=com then that works to isolate the users I'm looking for.
The one thing that doesn't quite work is the human-readable display name of the roster.
It has to come from an LDAP attribute under a user entry.
In my case the closest thing I can get to a sensible human-readable roster from the pre-defined LDAP schema name is using zimbraMailHost which is... mail.domain1.com
So when I do a host-specific config of mod_shared_roster_ldap for domain2.com, the value of zimbraMailHost is still mail.domain1.com
Which doesn't look great for users of domain2.com. It doesn't look too great for users of domain1.com either.
It would be great if I could set my own roster display name in the config rather than it being an LDAP attribute.
But anyway, I've got it working just not as clean as I would like.
To be honest if I was handling higher numbers of domains/users I would probably want to set this up per-domain anyway to make sure the LDAP server isn't being worked too hard. And some domains might not want to have all users in a roster when there's loads of users. Plus it would use loads of server resources having subscriptions between hundreds of users by default. Really you would only ever need this module for small rosters.
But it makes things a bit more awkward for when you have large numbers of domains each with small numbers of users.
Thanks for the help - hope this helps someone else out!
Cheers, B