On Nov 24, 2010, at 16:56 , masarati@aero.polimi.it wrote: >> Hi, >> >> I have built my ldap groups with dynlist overlay. >> >> _If i search for a group i can see the members: >> ldapsearch -Y EXTERNAL -b 'ou=Groups,dc=abc,dc=net' 'cn=ou-is' >> dn: cn=ou-is,ou=Groups,dc=abc,dc=net >> objectClass: groupOfURLs >> objectClass: fhvGroup >> cn: ou-is >> memberURL: >> ldap:///ou=People,dc=abc,dc=net??sub?(fhvIsAISMemberOf=cn=ou-is,ou=Groups,dc=abc,dc=net) >> member: uid=cb,ou=fhv,ou=People,dc=abc,dc=net >> >> _But if i search for members i only get empty results: >> ldapsearch -Y EXTERNAL -b 'ou=Groups,dc=abc,dc=net' >> '(member=uid=cb,ou=fhv,ou=People,dc=abc,dc=net)' cn member >> >> Is this not working with dynamic groups? > > Yes, the module is working as intended. From slapo-dynlist(5): > > Any time an entry with a specific objectClass is being returned, > the LDAP URI-valued occurrences of a specific attribute are > expanded into the corresponding entries, and the values of the > attributes listed in the URI are added to the original entry. > > So the overlay operates on entries *returned* by a search, and thus it has > nothing to do with the search filter. At the time of filtering, the > dynamic values are not present in the entry, and thus cannot match. ok, but how can this be solved without to have to maintain the group tree with static members and to have the ability to search for member=.. ? i thought about a proxy cache but this would probably be senseless because a proxytemplate (member=) would result in nothing to cache because of the target server? /chris > >> And does it make sense to build indexes for dynamic member attributes? > > No, it's pure nonsense. > > p. >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature