Dear List!
I have dynlist overlay configured in the following way: dynlist-attrset groupOfURLs memberURL uniqueMember
Also I have this dynamic group: dn: cn=audio,ou=PosixGroups,ou=Groups,dc=example,dc=com cn: audio description: All users eligible to use audio devices objectClass: groupOfURLs objectClass: top objectClass: posixGroup gidNumber: 11 memberURL: ldap:///ou=People,dc=example,dc=com?uid?one?(&(objectClass=p osixAccount)(gidnumber=1000))
When I run the following search: ldapsearch -x '(gidnumber=11)' Then I get: dn: cn=audio,ou=PosixGroups,ou=Groups,dc=example,dc=com cn: audio ... memberURL: ldap:///ou=People,dc=example,dc=com?uid?one?(&(objectClass=p osixAccount)(gidnumber=1000)) uniqueMember: uid=foo,ou=people,dc=example,dc=com uniqueMember: uid=bar,ou=people,dc=example,dc=com
I.e. everything works like exepected.
The problem is that this search returns nothing: ldapsearch -x '(uniquemember=*)' # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (uniquemember=*) # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
I would expect it to return dn: cn=audio,ou=PosixGroups,ou=Groups,dc=example,dc=com
How can I fix this?
-- Zaar
Hai Zaar wrote:
I would expect it to return dn: cn=audio,ou=PosixGroups,ou=Groups,dc=example,dc=com
How can I fix this?
This issue has been discussed many times, and it should be clear enough from slapo-dynlist(5) man page. Your expectation does not comply with the rationale of dynlist. In fact, for your expectation to hold, dynamic list expansion should occur __before__ filtering. A first adverse consequence is that indexing would be impossible. A second adverse consequence is that dynamic list expansion should __always__ occur for all dynamic entries that fall into the scope of any search. This is technically possible, but it would likely be very costly. Feel free to submit a patch that implements such design, but I'm pretty sure most of the dynlist users (including perhaps yourself) would then start complaining about the poor performances of databases that use that overlay.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
This issue has been discussed many times, and it should be clear enough from slapo-dynlist(5) man page. Your expectation does not comply with the rationale of dynlist. In fact, for your expectation to hold, dynamic list expansion should occur __before__ filtering. A first adverse consequence is that indexing would be impossible. A second adverse consequence is that dynamic list expansion should __always__ occur for all dynamic entries that fall into the scope of any search. This is technically possible, but it would likely be very costly. Feel free to submit a patch that implements such design, but I'm pretty sure most of the dynlist users (including perhaps yourself) would then start complaining about the poor performances of databases that use that overlay.
So, is there any other way to implement _dynamic_ posixGroup, whose membership is determined by particular filter? Or is the whole world using plain static groups?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it
openldap-software@openldap.org
-
Hai Zaar -
Pierangelo Masarati