Am Tue, 31 Jul 2012 08:16:39 -0400 schrieb Patrick Hemmer openldap@stormcloud9.net:

Sent: Tue Jul 31 2012 02:55:05 GMT-0400 (EDT) From: Dieter Klünter dieter@dkluenter.de To: openldap-technical@openldap.org Subject: Re: Issue with dynlist overlay

...

Am Mon, 30 Jul 2012 12:52:22 -0400 schrieb Patrick Hemmeropenldap@stormcloud9.net:

...

So I just ran across an undocumented issue with slapo-dynlist. I'm not sure if this is a bug, or just missing in the documentation.

The issue is that if the entry being dynamically added to the parent entry has the objectClass slapo-dynlist is configured to use, that entry is not dynamically added to the parent. For example:

---

olcOverlay=dynlist,olcdatabase=hdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcDlAttrSet: groupOfURLs memberUrl

---

dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: groupOfURLs member: uid=foo,dc=example,dc=com memberUrl: ldap:///cn=child,dc=example,dc=com

dn: cn=child,dc=example,dc=com objectClass: groupOfNames objectClass: groupOfURLs member: uid=bar,dc=example,dc=com

---

In the above example, I would "member: uid=bar,dc=example,dc=com" to be added to cn=parent,dc=example,dc=com, but it isn't.

Now the documentation clearly states recursion is not allowed, so if cn=child were to have a 'memberUrl', this memberUrl would not be expanded. But this is not what is being done here, cn=child has no memberUrl present. It also behaves perfectly fine if I pull the "objetClass: groupOfURLs" off cn=child.

So is this supposed to behave this way? If so can the documentation be updated to indicate this restriction? If not I'd be happy to open an ITS on the issue.

The memberURL attribute value is not complete, see rfc 4516. It should be something like memberURL:ldap:///cn=child,dc=example,dc=com?<attributetype>?<scope>?<filter>

-Dieter

I've tried that too, it doesn't matter.

...

It also behaves perfectly fine if I pull the "objetClass:

groupOfURLs" off cn=child.

Your principle design is a bit strange, objectClass groupOfURLs is a structural object class. Try something like

dn: cn=parent,dc=example,dc=com objectClass: groupOfURLs memberUrl: ldap:///cn=child,dc=example,dc=com?member?base?(objectclass=groupOfNames)

dn: cn=child,dc=example,dc=com objectClass: groupOfNames member: uid=bar,dc=example,dc=com member: uid=foo,dc=example,dc=com

-Dieter

Am Tue, 31 Jul 2012 10:04:38 -0400 schrieb Patrick Hemmer openldap@stormcloud9.net:

[...]

So I just ran across an undocumented issue with slapo-dynlist. I'm not sure if this is a bug, or just missing in the documentation.

The issue is that if the entry being dynamically added to the parent entry has the objectClass slapo-dynlist is configured to use, that entry is not dynamically added to the parent.

I have just created a dynamic group, each newly added entry has been displayed on the following search operation.

For example:

dn: olcOverlay={4}dynlist,olcDatabase={3}hdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {4}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI

---

dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*)

dn: cn=child,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject member: uid=bar,dc=example,dc=com cn: child

---

In the above example, I would "member: uid=bar,dc=example,dc=com" to be added to cn=parent,dc=example,dc=com, but it isn't.

Now the documentation clearly states recursion is not allowed, so if cn=child were to have a 'labeledURI', this labeledURI would not be expanded. But this is not what is being done here, cn=child has no labeledURI present. It also behaves perfectly fine if I pull the "objetClass: labeledURIObject" off cn=child.

ldapsearch with objectClass labeledURIObject present on cn=child:

dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*)

---

ldapsearch without objectClass labeledURIObject present on cn=child:

dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent cn: child member: uid=foo,dc=example,dc=com member: uid=bar,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*)

---

So is this supposed to behave this way? If so can the documentation be updated to indicate this restriction? If not I'd be happy to open an ITS on the issue.

This is not the expected behaviour. My example with attribute type telephoneNumber shows following results

ldapsearch -LLL -Y EXTERNAL -U dieter -H ldapi:/// -b cn=dynamicGroup,o=avci,c=de -s base

telephoneNumber: +49.40.4454984 telephoneNumber: +49.40.4454985 telephoneNumber: +49.40.4454986 telephoneNumber: +49.40.4454987 telephoneNumber: +49.40.4454988 telephoneNumber: +49.40.4454989 telephoneNumber: +49.40.4454990 telephoneNumber: +49.40.4454991 telephoneNumber: +49.40.4454992 telephoneNumber: +49.40.4454993 telephoneNumber: +49.40.4454994 telephoneNumber: +49.40.4454995 telephoneNumber: +49.40.4454996 telephoneNumber: +49.40.4454997 telephoneNumber: +49.40.4454998 telephoneNumber: +49.40.4454999

this is my entry

dn: cn=dynamicGroup,o=avci,c=de cn: dynamicGroup objectClass: groupOfURLs memberURL: ldap:///ou=benchmark,o=avci,c=de?telephoneNumber?sub?(objectClass=inetorgPerson)

-Dieter