Bug 2113056

Summary: Import may break replication because changelog starting csn may not be created
Product: Red Hat Enterprise Linux 7 Reporter: mreynolds
Component: 389-ds-baseAssignee: Pierre Rogier <progier>
Status: CLOSED ERRATA QA Contact: RHDS QE <ds-qe-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 7.9CC: aadhikar, afarley, bsmejkal, cilmar, ds-qe-bugs, gkimetto, ldap-maint, msauton, progier, riehecky, sgouvern, tbordaz, zzoubkov
Target Milestone: rcKeywords: TestCaseProvided, Triaged
Target Release: 7.9   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sync-to-jira
Fixed In Version: 389-ds-base-1.3.10.2-17.el7_9 Doc Type: Bug Fix
Doc Text:
.Import from an LDIF file with replication metadata now works correctly Previously, importing an LDIF file with replication metadata could cause the replication to fail in certain cases: In the first case, a replication update vector (RUV) entry placed before the suffix entry in an imported LDIF file was ignored. As a consequence, the replication with the imported replica failed, because of a generation ID mismatch. This update ensures that Directory Server writes the skipped RUV entry at the end of the import. In the second case, a changelog reinitialized after an RUV mismatch did not contain the starting change sequence numbers (CSNs). As a consequence, the replication with the imported replica failed, because of a missing CSN in the changelog. This update ensures that Directory Server creates the RUV `maxcsn` entries, when reinitializing the changelog. As a result, with this update, administrators do not have to reinitialize the replication after importing from an LDIF file that contains replication metadata.
Story Points: ---
Clone Of: 2057058 Environment:
Last Closed: 2022-10-25 07:49:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2057056, 2057058    
Bug Blocks: 2057059    

Comment 2 mreynolds 2022-08-01 19:51:21 UTC
*** Bug 1908553 has been marked as a duplicate of this bug. ***

Comment 5 mreynolds 2022-10-12 15:45:32 UTC
*** Bug 1981334 has been marked as a duplicate of this bug. ***

Comment 6 Akshay Adhikari 2022-10-20 15:50:33 UTC
Build Tested: 389-ds-base-1.3.10.2-17.el7_9.x86_64

Steps:

1) Create a Supplier Consumer replication server.

2) Perform an Export operation on the Supplier.

3) Edit the ldif file and move the RUV as the first Entry.

4) Perform a re-import operation.

5) Restart the server, perform some updates/operations over the supplier, and check if replication is still working.

The replication is working, Marking it as VERIFIED.

Comment 10 errata-xmlrpc 2022-10-25 07:49:53 UTC
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 (Moderate: 389-ds-base security and bug fix update), 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/RHSA-2022:7087