[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: collective attributes (the hard way)

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.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/