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

Re: cn=config

Ondrej Kuznik wrote:
Hash: SHA1

I'm modifying an overlay for proper cn=config behaviour and have come
across some things I'm not sure about.

The overlay keeps a mapping derived from entries under its config entry,
if the overlay's dn is "olcoverlay={1}bla, olcdatabase={2}null,
cn=config" there are entries like:
"olcMappingRuleName={x}, olcoverlay={1}bla, olcdatabase={2}null, cn=config"

The rules are then stored in an avl in the overlay's info struct.

However to maintain the avl I think I need to know the boundaries of the
request. When adding the entry online, it is easy, one registers the
cleanup callback. When processing the entry during startup, the only way
to have the callback run is mucking with ConfigArgs' lineno variable.

However a modify operation is harder. It can transform the entry in
almost whatever way it pleases. Updating the entry in the avl each time
a subpart of the modify is sent to a ConfigDriver makes providing the
atomicity required by LDAP very hard. For instance, the mapping defined
by the entry may at one time be equal to another one in the avl. At that
time, the overlay does not know, whether this is supposed to be the
final version or there is a part of the modify that makes it a distinct
one again. Hopefully this paragraph makes sense.

If there is no such way, I propose that the cleanup be aplicable to a
modify operation too. No patches so far though.

The cleanup callback is already supported for Modify operations. back-bdb/config.c is an example of its use.

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