We are currently replicating an openldap 2.0.23 directory to a 2.2.23
one, and
modified entries have a corrupt index on 'objectClass' (we are using
the ldbm
backend).

Steps to reproduce:
1- make an initial slapcat;slapadd to synchronize the two servers.
2- 'ldapsearch -x -h slave objectClass=posixAccount|grep toto' returns
the entry
(there are less than 500 entries)
3- modify something on the master
4- the same ldapsearch now returns nothing (but a 'ldapsearch -x'
without a
filter on the objectClass is ok).
5- if I remove 'index objectClass eq' from the slave server, then the
'ldapsearch' is ok.

So it seems that the replication corrupts the index. I can also
reproduce the
bug with slapd 2.2.26.

Is this bug related to 'Software Bugs/3406' ? Or is it only a replication
problem ?

I note that replication from 2.0 to 2.2 should be impossible because the
2.2 slave expects stuff like structuralObjectClass, entryUUID, entryCSN.
I don't see how ITS/3406 may be related to this.

I thought that only the contrary was impossible (2.2 to 2.0), and I don't get
syntax errors during the replication. How could a replication corrupt the index?