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

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them

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.

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
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


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.