-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 07/07/2011 11:16 AM, masarati@aero.polimi.it wrote:

...

When storing cn=config entries whose rdns use different attributes, they may be received in a different order during startup. This will mess with their "{}" numbering and since a change like that is not anticipated in the code, it is never pushed to the underlying database either.

This leads to a state when the cn=config database and underlying on-disk representation are out of sync, making modification (and maybe deletion) of the affected entries impossible.

If needed, I can create a minimal overlay showing these symptoms.

Please, do. I find this report quite unclear, as I could not understand what the actual issue is.

ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c has an example of such overlay. To try it, initialize the overlay and add these entries:

dn: olcTestAttrOne=zero,$OVERLAY_DN objectclass: olcTestOne

dn: olcTestAttrTwo=one,$OVERLAY_DN objectclass: olcTestTwo

dn: olcTestAttrOne=two,$OVERLAY_DN objectclass: olcTestOne

dn: olcTestAttrTwo=three,$OVERLAY_DN objectclass: olcTestTwo

After a restart compare the output of slapcat -n0 with the output of ldapsearch -b cn=config, you should see at least one different entry. You might also try to modify the entries before and after the restart. For those that do not match you get "no such object" as the dn is no longer in the ldif database.

- -- 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.