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

[ondrej.kuznik@acision.com]

On 07/07/2011 03:26 PM, ondrej.kuznik@acision.com wrote:
> 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.

The issue is in bconfig.c:4726, the code treats all siblings as part of
one ordering (contrary to what
http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html
implies since cn=config seems to treat everything as X-ORDERED
'SIBLINGS'), while back-ldif orders them accordingly.
Also its caller (config_ldif_resp) does not expect any reordering to be
necessary, after all it should be (and is) reading a valid cn=config db,
so the entry renaming then never gets propagated to back-ldif causing
this desync.

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