Cause: If replication is enabled for a suffix before the suffix entry is added the entryID of the RUV entry is smaller than the suffix entry and exported before the suffix entry.
Consequence: During import it is skipped because the suffix was not yet imported. A new RUV element will be created, but the data genration is different and replication will fail
Fix: check if the suffix is already exported when writing the RUV entry, if necessary delay the writing of the RUV entry
Result: a ldif export can be used for import and replication succeeds
Description of problem:
A customer is exporting its data with "db2ldif -r" and the ldif has, as first entry, the ruv. The result is that the generated file is not straightfully imported:
# entry-id: 1
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsUniqueId: ffffffff-ffffffff-ffffffff-ffffffff
nsds50ruv: {replicageneration} 5b4e2610000000010000
nsds50ruv: {replica 1 ldap://example1.example.com:389} 5b4e261000010001000
0 5b4e2610002300010000
nsds50ruv: {replica 2 ldap://example2.example.com:389}
dc: example
nscpEntryDN: dc=example,dc=com
nsruvReplicaLastModified: {replica 1 ldap://example1.example.com:389} 5b4e
2610
nsruvReplicaLastModified: {replica 2 ldap://example2.example.com:389} 0000
0000
# entry-id: 2
dn: dc=example,dc=com
objectClass;vucsn-5b4e2610000100010000: domain
objectClass;vucsn-5b4e2610000100010000: top
dc;vucsn-5b4e2610000100010000;mdcsn-5b4e2610000100010000: example
description;vucsn-5b4e2610000100010000: Root of the directory
creatorsName;vucsn-5b4e2610000100010000: cn=directory manager
modifiersName;vucsn-5b4e2610000100010000: cn=directory manager
createTimestamp;vucsn-5b4e2610000100010000: 20180717172328Z
modifyTimestamp;vucsn-5b4e2610000100010000: 20180717172328Z
nsUniqueId: 1e61a805-89e611e8-87c6f971-856b23a3
Version-Release number of selected component (if applicable): 389-ds-base-1.3.7.5-19.el7_5.x86_64
How reproducible: I have not managed to reproduce it yet. Only the customer.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2019:2152
Description of problem: A customer is exporting its data with "db2ldif -r" and the ldif has, as first entry, the ruv. The result is that the generated file is not straightfully imported: # entry-id: 1 dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsUniqueId: ffffffff-ffffffff-ffffffff-ffffffff nsds50ruv: {replicageneration} 5b4e2610000000010000 nsds50ruv: {replica 1 ldap://example1.example.com:389} 5b4e261000010001000 0 5b4e2610002300010000 nsds50ruv: {replica 2 ldap://example2.example.com:389} dc: example nscpEntryDN: dc=example,dc=com nsruvReplicaLastModified: {replica 1 ldap://example1.example.com:389} 5b4e 2610 nsruvReplicaLastModified: {replica 2 ldap://example2.example.com:389} 0000 0000 # entry-id: 2 dn: dc=example,dc=com objectClass;vucsn-5b4e2610000100010000: domain objectClass;vucsn-5b4e2610000100010000: top dc;vucsn-5b4e2610000100010000;mdcsn-5b4e2610000100010000: example description;vucsn-5b4e2610000100010000: Root of the directory creatorsName;vucsn-5b4e2610000100010000: cn=directory manager modifiersName;vucsn-5b4e2610000100010000: cn=directory manager createTimestamp;vucsn-5b4e2610000100010000: 20180717172328Z modifyTimestamp;vucsn-5b4e2610000100010000: 20180717172328Z nsUniqueId: 1e61a805-89e611e8-87c6f971-856b23a3 Version-Release number of selected component (if applicable): 389-ds-base-1.3.7.5-19.el7_5.x86_64 How reproducible: I have not managed to reproduce it yet. Only the customer.