Having worked on the simple / practical way of getting collective attributes, my next task is to investigate and possibly fix ? the more complex but ultimately more complete, collective attribute scheme, which is used when you declare an object in the schema with COLLECTIVE (eg. in collective.schema).
So far, i have worked out how to create a collective definition, but it has no effect as i'm presuming *subtreeSpecification* is currently unimplemented. Can somebody please check i have the below correct at least.
I have declared the following :
dn: cn=template1,o=openldap,c=AU *objectClass: collectiveAttributeSubentry objectClass: subentry objectClass: top* cn: template1 *subtreeSpecification: { base "ou=test1,o=openldap,c=AU" }* createTimestamp: 20080906145020Z creatorsName: cn=Manager,c=AU entryCSN: 20080906145740.998417Z#000000#000#000000 entryDN: cn=template1,o=openldap,c=AU entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8 hasSubordinates: FALSE modifiersName: cn=Manager,c=AU modifyTimestamp: 20080906145740Z structuralObjectClass: subentry subschemaSubentry: cn=Subschema
This appears to set up the collective attributes, and where they should apply but has no effect. Presumably this is because c-PostalAddress and/or c-PostalCode (as defined in collective.schema) are not present.
Well there are no suplimentary objectclases that allow these attributes, so i tried adding the extensibleObject objectclass, and then added the c-PostalCode and c-PostalAddress attributes. This gave me :
dn: cn=template1,o=openldap,c=AU objectClass: collectiveAttributeSubentry *objectClass: extensibleObject* objectClass: subentry objectClass: top cn: template1 subtreeSpecification: { base "ou=test1,o=openldap,c=AU" } *c-PostalAddress: 123 Someplace St c-PostalCode: 9999* createTimestamp: 20080906145020Z creatorsName: cn=Manager,c=AU entryCSN: 20080906145740.998417Z#000000#000#000000 entryDN: cn=template1,o=openldap,c=AU entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8 hasSubordinates: FALSE modifiersName: cn=Manager,c=AU modifyTimestamp: 20080906145740Z structuralObjectClass: subentry subschemaSubentry: cn=Subschema
(Incidentally very impressed that Apache Directory Studio can handle the above subschema stuff quite competently)
So although the configuration information is now present, i assume there is nothing actually using or applying this data. If i understand the above correctly, the intent is to apply the above values in c-PostalAddress and c-PostalCode, to the matching attributes postalAddress and postalCode for all entries under base "ou=test1,o=openldap,c=AU", with no exclusions
I'm thinking that it is a requirement to efficiently keep a list of objects matching (objectClass=collectiveAttributeSubentry) and then applying the specifications therein to search results. The existing collect overlay is a simple demonstration overlay, which keeps only a simple static definition which never changes, so does not implement collective attributes in the more complex dynamic form.
To implement collective attributes fully (and as declared in collective.schema) this meta data would need to be dynamic, but without the overhead of continually searching for new things matching (objectClass=collectiveAttributeSubentry) which would trash performance.
Any thoughts on how to go about implementing this ?
Cheers Brett
Brett @Google wrote:
Having worked on the simple / practical way of getting collective attributes, my next task is to investigate and possibly fix ? the more complex but ultimately more complete, collective attribute scheme, which is used when you declare an object in the schema with COLLECTIVE (eg. in collective.schema).
So far, i have worked out how to create a collective definition, but it has no effect as i'm presuming *subtreeSpecification* is currently unimplemented. Can somebody please check i have the below correct at least.
Correct; while there is support for *storing* subentries in some of the backends, there is no support for implementing their meaning.
So although the configuration information is now present, i assume there is nothing actually using or applying this data. If i understand the above correctly, the intent is to apply the above values in c-PostalAddress and c-PostalCode, to the matching attributes postalAddress and postalCode for all entries under base "ou=test1,o=openldap,c=AU", with no exclusions
I'm thinking that it is a requirement to efficiently keep a list of objects matching (objectClass=collectiveAttributeSubentry) and then applying the specifications therein to search results. The existing collect overlay is a simple demonstration overlay, which keeps only a simple static definition which never changes, so does not implement collective attributes in the more complex dynamic form.
Re: static vs dynamic - this distinction doen't really exist, since the collect overlay can be reconfigured dynamically using cn=config.
But the more general problem - yes, there needs to be a piece of code that keeps a list of (objectclass=subentry) and applies the relevant behaviors to each. Doing this correctly would introduce a quite different administrative model to the server, and would require quite a lot of architectural changes.
To implement collective attributes fully (and as declared in collective.schema) this meta data would need to be dynamic, but without the overhead of continually searching for new things matching (objectClass=collectiveAttributeSubentry) which would trash performance.
Any thoughts on how to go about implementing this ?
Nothing I'd contemplate before OpenLDAP 3.0.
In hindsight, a fair number of our overlays have redundant code for specifying what subtrees they should operate on. It may have been better to implement a single overlay that maintained a cache of subentries, and have it invoke particular handlers for a given module after evaluating their SSSs. Then a number of our existing modules would be reimplemented as new modules that are only invoked from the subentry overlay...
The approach isn't so different from the autogroup overlay currently in contrib - search for all relevant entries at startup, and then monitor add/modify/deletes to keep sync'd.
On Sun, Sep 7, 2008 at 4:32 AM, Howard Chu hyc@symas.com wrote:
But the more general problem - yes, there needs to be a piece of code that keeps a list of (objectclass=subentry) and applies the relevant behaviors to each. Doing this correctly would introduce a quite different administrative model to the server, and would require quite a lot of architectural changes.
Overlays are single threaded, but can they themselves have private worker threads? I guess that this would depend how much the worker thread could do without using the overlay's (single threaded) callbacks / resources etc., and it would need to update the meta data in paralel so as to not block use of the meta information by the overlay proper (and lock access to pointers which might change when the metadata is updated).
Providing there is a thread safe mechanism between the overlay's private worker thread, the overlay-local metadata information and the overlay that used that local meta information, then might his be doable without tampering with the theadedness of the rest of the server ?
I think this metadata update might be done single threaded, but it would mean that if a query triggers or requires a meta data update, then the ldap requests on that thread would block until the metadata refresh was complete.
Cheers Brett
Brett @Google wrote:
On Sun, Sep 7, 2008 at 4:32 AM, Howard Chu <hyc@symas.com mailto:hyc@symas.com> wrote:
But the more general problem - yes, there needs to be a piece of code that keeps a list of (objectclass=subentry) and applies the relevant behaviors to each. Doing this correctly would introduce a quite different administrative model to the server, and would require quite a lot of architectural changes.Overlays are single threaded, but can they themselves have private worker threads? I guess that this would depend how much the worker thread could do without using the overlay's (single threaded) callbacks / resources etc., and it would need to update the meta data in paralel so as to not block use of the meta information by the overlay proper (and lock access to pointers which might change when the metadata is updated).
Overlays are not single-threaded, so the rest of this question is moot.
-
Brett ＠Google -
Howard Chu