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

[ondrej.kuznik@acision.com]

Full_Name: Ondrej Kuznik
Version: HEAD
OS: Linux
URL: 
Submission from: (NULL) (62.168.56.1)


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.

Not sure what action is appropriate, probably letting back-ldif honor the
original ordering fully, but this can break other assumptions already in the
configuration code that relied on the "attribute name first, then numbers"
ordering. Another thing that comes to my mind is to make the ordering sequences
per attribute whatever the value of ce_type. Like this:
olcAttr={0}a, olcSomething={0}something, cn=config
olcAttr={1}c, olcSomething={0}something, cn=config
olcAttr={2}b, olcSomething={0}something, cn=config
olcOtherAttr={0}ccc, olcSomething={0}something, cn=config
olcOtherAttr={1}csad, olcSomething={0}something, cn=config
olcOtherAttr={2}safc, olcSomething={0}something, cn=config
olcOtherAttr={3}brt, olcSomething={0}something, cn=config

Again, this has other drawbacks (first restart after this is applied changes the
cn=config database probably messing with replication?)