-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, 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.
- -- Ondrej Kuznik
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/01/2011 03:11 AM, Howard Chu wrote:
Ondrej Kuznik wrote:
Hi, 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.
Thank you for the pointer.
I went with your suggestion, but there is still a slight catch. The cleanup callback is the only place I am able to tell if the final mapping collides with one already in the avl. Therefore it needs to be able to abort the operation. It does so as far as an Add operation is concerned (converting any failure to LDAP_OTHER, which makes sense), but in config_modify_internal it the call to ca->cleanup can have no influence on the result code.
Would you consider setting result code to the one ca->cleanup returns or, like in config_add_internal, mangling rc to LDAP_OTHER on failure?
- -- Ondrej Kuznik
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
-
Howard Chu -
Ondrej Kuznik