Full_Name: Jose Marco de la Rosa Version: 2.3.39 OS: Kubuntu 7.10 URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz Submission from: (NULL) (80.25.122.131) Two overlays that implement dynamic group classes defined with URL attributes and allowing nesting. - The first one is an extension of th overlay expandURL but allowing nesting - The second one changes the way groups are constructed in a more powerful way Examples of functioning follow for each version and are included in the overlays code archives (.c) The tarball Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz was uploaded to openldap's server and it includes a webpage with further detail in the implementation and configuration of the overlay. Code files are appropriately linked in the web page mentioned (all is included in the tarball: there are no external references in the webpage). Both search and compare operations were implemented I hope you like it... ####################################################### First overlay: nestedAggregateAttrDN: * SYNTAX: * * In slapd.conf : * overlay nestedAggregateAttrDN * nestedAggregateAttrDN <objectClass> <source-attribute> <destination-attribute> [[<maximum-depth>] <TTL>] * Where: * <objectClass> specifies the class that should expand. * <source-attribute> establishes the attribute that contains information * about other entries where to gather destination attribute values from. * <destination-attribute> establishes the attribute that should present all the gathered values. * <maximum-depth> establishes the maximum nesting depth level. If not specified, it defaults * to 0 which means no nesting is allowed (not even one level). * <TTL> establishes the maximum time allowed to serve the query. You should take into account that: * If different TTLs are set for the different configurations the minimum * will be used for all configurations. * The TTL affects ALL searches done when the overlay is active and not only * those related to the configured clases. * * * EXAMPLE: * * NOTE: you will probably need/want to define some attributes and classes in your schema * example.schema: * ------------------- * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber> * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2 * * # Attribute type for new classes * * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1 * NAME 'subgroupDN' * DESC 'DN of a aggregable entry' * SUP distinguishedName ) * * # Classes for using overlay nestedAggregateAttrDN * * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1 * NAME 'subgroupedDNGroup' * DESC 'Sample class for nestedAggregateAttrDN (experimental purpose)' * SUP top STRUCTURAL * MUST cn * MAY ( member $ subgroupDN $ cn $ ou $ o $ description ) ) * * * slapd.conf: * ------------------- * overlay nestedAggregateAttrDN * # Configure class: subgroupedDNGroup * # Source attribute: subgroupDN * # Aggregated attribute: member * # Max depth in nesting: 4 * # TTL: 5 sec * nestedAggregateAttrDN subgroupedDNGroup subgroupDN member 4 5 * * * ldif: * ------------------- * * # Static1 * dn: cn=Static1,dc=test * cn: Static1 * objectClass: groupOfNames * member: cn=person1,dc=test * member: cn=person2,dc=test * * # Static2 * dn: cn=Static2,dc=test * cn: Static2 * objectClass: groupOfNames * member: cn=person3,dc=test * member: cn=person4,dc=test * * # SubgroupedLevel1 * dn: cn=SubgroupedLevel1,dc=test * cn: SubgroupedLevel1 * objectClass: subgroupedDNGroup * subgroupDN: cn=Static1,dc=test * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedDNGroup * subgroupDN: cn=SubgroupedLevel1,dc=test * subgroupDN: cn=Static2,dc=test * * * ------------------- * * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedDNGroup * subgroupDN: cn=SubgroupedLevel1,dc=test * subgroupDN: cn=Static2,dc=test * member: cn=person1,dc=test * member: cn=person2,dc=test * member: cn=person3,dc=test * member: cn=person4,dc=test * * * IMPORTANT: this overlay conflicts with nestedAggregateAttrURL. * if both are active, some searches don't behave as expacted! * Specifically, if you turn both overlays on and search for * 'entries with member=<some member value>' won't work properly * for one of the overlays (the firstly activated one) */ ####################################################### Second overlay: nestedAggregateAttrURL: * SYNTAX: * * In slapd.conf : * overlay nestedAggregateAttrURL * nestedAggregateAttrURL <objectClass> <source-attribute> <destination-attribute> [[<maximum-depth>] <TTL>] * Where: * <objectClass> specifies the class that should expand. * <source-attribute> establishes the attribute that contains information * about other entries where to gather destination attribute values from. * <destination-attribute> establishes the attribute that should present all the gathered values. * <maximum-depth> establishes the maximum nesting depth level. If not specified, it defaults * to 0 which means no nesting is allowed (not even one level). * <TTL> establishes the maximum time allowed to serve the query. You should take into account that: * If different TTLs are set for the different configurations the minimum * will be used for all configurations. * The TTL affects ALL searches done when the overlay is active and not only * those related to the configured clases. * * * EXAMPLE: * * NOTE: you will probably need/want to define some attributes and classes in your schema. You can use * netscape's groupOfURLs, anyway... * example.schema: * ------------------- * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber> * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2 * * # Attribute type for new classes * * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1 * NAME 'subgroupURL' * DESC 'URL to search for aggregable entries' * SUP labeledURI ) * * # Classes for using overlay nestedAggregateAttrURL * * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1 * NAME 'subgroupedURLGroup' * DESC 'Sample class for nestedAggregateAttrURL (experimental purpose)' * SUP top STRUCTURAL * MUST cn * MAY ( member $ subgroupURL $ cn $ ou $ o $ description ) ) * * attributetype ( IAVANTE_LDAPattributeType:2 * NAME 'subgroupURL' * DESC 'Identifies an URL containing a search for names of subgroups.' * SUP labeledURI ) * * * slapd.conf: * ------------------- * overlay nestedAggregateAttrURL * # Configure class: subgroupedURLGroup * # Source attribute: memberURL * # Aggregated attribute: member * # Max depth in nesting: 4 * # TTL: 5 sec * nestedAggregateAttrURL subgroupedURLGroup subgroupURL member 4 5 * * * ldif: * ------------------- * * # Static1 * dn: cn=Static1,dc=test * cn: Static1 * objectClass: groupOfNames * member: cn=person1,dc=test * member: cn=person2,dc=test * * # Static2 * dn: cn=Static2,dc=test * cn: Static2 * objectClass: groupOfNames * member: cn=person3,dc=test * member: cn=person4,dc=test * * # SubgroupedLevel1 * dn: cn=SubgroupedLevel1,dc=test * cn: SubgroupedLevel1 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///dc=test??one?(cn=Static*) * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test * * * ------------------- * * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test * member: cn=person1,dc=test * member: cn=person2,dc=test * member: cn=person3,dc=test * member: cn=person4,dc=test * * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. * if both are active, some searches don't behave as expacted! * Specifically, if you turn both overlays on and search for * 'entries with member=<some member value>' won't work properly * for one of the overlays (the firstly activated one) * */
josemarcodelarosa@gmail.com wrote: > Full_Name: Jose Marco de la Rosa > Version: 2.3.39 > OS: Kubuntu 7.10 > URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz > Submission from: (NULL) (80.25.122.131) > > > Two overlays that implement dynamic group classes defined with URL attributes > and allowing nesting. > > - The first one is an extension of th overlay expandURL but allowing nesting > > - The second one changes the way groups are constructed in a more powerful way > * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. > * if both are active, some searches don't behave as expacted! > * Specifically, if you turn both overlays on and search for > * 'entries with member=<some member value>' won't work properly > * for one of the overlays (the firstly activated one) Seems there's really no need for the nestedAggregateAttrDN overlay, since that is just a proper subset of a URL. I.e., anywhere you would use a simple DN is just a case of subGroupURL: ldap:///<dn>??base -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Yes, you are completely right. The only reason I can think of using the DN version is because you are forced by your schema (attribute types for the expansion source attribute differ). I emphasize that the implementation of both is quite different. The DN version uses recursivity while the URL version relies in slapd's search-reply mechanism. I just added the first one as an example. URL version is much more powerful and more elegant. You suggested subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok (if I remember right).
josemarcodelarosa@gmail.com wrote: > Yes, you are completely right. The only reason I can think of using the > DN version is because you are forced by your schema (attribute types for the > expansion source attribute differ). I emphasize that the implementation of > both is quite different. The DN version uses recursivity while the URL > version relies in slapd's search-reply mechanism. I just added the first one > as an example. > > URL version is much more powerful and more elegant. You suggested > subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok > (if I remember right). According to Section 3 of RFC 4516, if <scope> is omitted, a scope of "base" is assumed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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 ---------------------------------------
Jose, few preliminary comments: - you coded your contribution for OpenLDAP 2.3; however, since it configures as a new feature, it should be coded for OpenLDAP 2.4 (better for HEAD), as 2.3 is feature-frozen ever since. This comment may appear trivial, but right now your contribution does not compile with HEAD/re24 because of some internal API changes. - the coding style you used does not conform to that of the OpenLDAP project. Although this is usually only loosely enforced, you used things we're a bit picky about, like C++-style comments, and late declarations; if you compile with enough warnings (e.g., with gcc, with -Wall -pedantic) you'll see that in many cases functions are not returning when a return value is expected or vice-versa; incorrect formats are used for (long) integers, pointers and so. Also, I note that besides being a totally new contribution, many of the comments are already no longer aligned with the code. - according to agreed development lines, new contributions should always provide back-config support (this can be added later, if and when the rest works as expected) - with respect to the possible improvements you indicate, I think: 1) permission checking should occur along the lines of, e.g., slapo-dynlist(5), honoring dgIdentity and dgAuthz. 2) avoiding unnecessary expansion would probably be mandatory for production use 3) use back-config rather than naive in-database configuration using an ordinary database - The build instructions you provide are incorrect: you suggest to place the source in servers/slapd/overlays/, and to modify statover.c; this is a generated file, so it should never be modified. You should rather suggest to place the sources in an arbitrary directory (it could be contrib/slapd-modules/nestedAggregateAttr as soon as your contribution enters the official distribution) and build it as a run-time module. - you should rather eliminate duplicate values from result sets (much like slapo-dynlist(5) does) as they are not allowed by the definition of the "member" attribute, which has a distinguishedNameMatch EQUALITY rule. - instead of copying compare_entry(), you should rather ask to make the one in servers/slapd/compare.c non-static - since the "OR" operator in filters allows more than 2 operands, I think your filter combination strategy could be optimized by simply defining a combine_filters() function that counts the number of filter strings in the array and creates a filter like "(|(f1)(f2)(f3)...)" - in check_filter(), you compare strings; you should rather compare pointers to AttributeDescription structures. - in nestedAggregateAttrURL_search() you don't need to run str2filter() on op->ors_filterstr, since an exploded filter is already available in op->ors_filter - strings[] containing "(objectClass=<ocname>)" could be prepared once for all during config; it would save a lot of mallocs (BTW: use the slab for operation-spanning allocation). - I would recommend you do some consistent checking of return values before dereferencing pointers. - I would recommend that you either remove or turn into useful standard debugging the plethora of non-standard messages you added. Use LDAP_DEBUG_ARGS to mark entering/exiting functions (and logging useful args); use LDAP_DEBUG_TRACE to trace operations; use slap_loglevel_get() to register friendly names for specific log subsystems (you'll get back the number to compare with ldap_debug). - with respect to the OID for the test schema items, you'll get an OID arc in the experimental OID namespace of the OpenLDAP project as soon as your contribution is incorporated. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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 ---------------------------------------
changed notes changed state Open to Feedback
From a private message the contributor sent me, it appears he's not working at this any more, and he doesn't intend to take care of the reviews. So I suggest his contribution goes to "contrib", in case anyone finds it useful. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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 ---------------------------------------
moved from Incoming to Contrib
changed notes
changed notes changed state Feedback to Suspended
IPR okay under review
Fixed with openldap 2.5 dynlist?