There are multiple issues in this scenario:
- if db2index is executed without specifying an attribute the script runs "upgradedb -f" instead, that will also recreate the indexes, but as reported in this issue not all indexes are correct.
what should be the correct behaviour if no attr for reindexing is specified ?
-- reject the command ?
-- do a db2index for all attributes on the specified backend
-- do an upgradedb, but do it correctly.

• since upgradedb can be run directly, independent of the answer to the above question it should work correctly
  -- the ruv entry should be indexed properly in the entryrdn index
  -- while testing I noticed that also the numsubordinates index is not created by upgradedb
  -- other indexes ?

The focus of this ticket should be to make upgradedb work correctly, if we want to change behaviour for db2index without attrs this should be handled in a different ticket

this is a can of worms. It could be that the RUV entry itself is not correct and prevents proper indexing.
If a normal replication test is run the RUV entry in the database, as seen by dbscan, looks like this:

 id 15
rdn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsUniqueId: ffffffff-ffffffff-ffffffff-ffffffff
nsds50ruv: {replicageneration} 5c1a1807000000010000
nsds50ruv: {replica 1 ldap://lucy1:39001} 5c1a1807000100010000 5c1a18160000000
 10000
dc: example
nscpEntryDN: dc=example,dc=com
nsruvReplicaLastModified: {replica 1 ldap://lucy1:39001} 5c1a1816

note that the nspentrydn is that of the suffix, not of the entry itself, there is a "dc" attr, which does not make sens and there is no entryid and parentid attribute.

If we do a db2ldif/ldif2db, the entry now looks like this:

 id 15
rdn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff
nsUniqueId: ffffffff-ffffffff-ffffffff-ffffffff
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5c1a1807000000010000
nsds50ruv: {replica 1 ldap://lucy1:39001} 5c1a1807000100010000 5c1a18160000000
 10000
dc: example
nscpEntryDN: dc=example,dc=com
nsruvReplicaLastModified: {replica 1 ldap://lucy1:39001} 5c1a1816
creatorsName:
modifiersName:
createTimestamp: 20181219101224Z
modifyTimestamp: 20181219101224Z
parentid: 1
entryid: 15

we have now parentid and entryid, and timestamps. And if we run the upgradedb now, the ruv entry is properly indexed in the entryrdn index and can be found

ok, in ldbm_back_add() we need to add the operational attributes entryid and parentid in the "is_ruv" case. Then the ruv can be read after a upgradedb operation.

BUT: I have not further tested if it has side effects (and the first fix is a hack)
AND: it does not address the missing numsubordinates index

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3162

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.