#50103 Unable to read the RUV after a db2index operation
Opened a year ago by lkrispen. Modified 16 days ago

Issue Description

Description of problem:

in ipa context, if we do a

db2index -n changelog

there's not only changelog that is re-indexed but all the backends.

Also, there's a backup that is being performed.

And after that, as a consequence, we cannot read the RUV anymore with a command like this:

ldapsearch -D "cn=directory manager" -W -b <root suffix=""> '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))'

rsions)

Package Version and Platform

Version-Release number of selected component (if applicable): 389-ds-base-1.3.7.5-19.el7_5.x86_64 (but shown in other ve


Metadata Update from @lkrispen:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1601470
- Custom field type adjusted to None
- Custom field version adjusted to None

a year ago

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

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.0

a year ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.9 (was: 1.4.0)

a year ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.10 (was: 1.3.9)

6 months ago

Metadata Update from @mreynolds:
- Issue priority set to: minor
- Issue set to the milestone: 1.4.4 (was: 1.3.10)

16 days ago

Login to comment on this ticket.

Metadata
Attachments 1
Attached a year ago View Comment