https://bugzilla.redhat.com/show_bug.cgi?id=747701
Description of problem: Recently, we have run into several issues caused by LDAP replication conflicts in IPA replicas. Objects like this: nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=utest,cn=users,cn=accounts,d c=idm,dc=lab,dc=bos,dc=redhat,dc=com fqdn=rhel61-client3.testrelm+nsuniqueid=807bb87f-652211e0-9e848fb2-f0f04a39,cn= computers,cn=accounts,dc=testrelm lead to unpredictable issues for IPA end-user. Not every user can be experienced enough to determine that the issues he is experiencing are caused by these conflicts and rename/remove them. If 389-ds replication plugin would allow us to configure a suffix to put all conflicts in to prevent them from being in the tree that clients use, it would be a great help for a user to mitigate the replication conflict issue.
We should consider putting tombstones in a special suffix as well. For example, AD uses a special suffix to store deleted entries outside of the regular data suffix. Also analogous to the file system lost+found directory. This would solve some tricky issues with urp and entryrdn having to keep track of numsubordinates and tombstonenumbsubordinates separately.
batch move to milestone 1.3
Design doc wiki: http://directory.fedoraproject.org/wiki/Separate_Conflict_and_Tombstone_Entry
set default ticket origin to Community
Added initial screened field value.
This isn't going to make it for 1.3.0 (F18). Pushing out to 1.3.1.
Ludwig Krispenz wrote:
is it ok if I take this one ? Thanks, Ludwig! I reassigned this bug to you.
A possible alternative would be to have replication conflicts having ldapsubentry objectclass so as to be skipped in normal queries not including the mentioned objectclass in the filter and not referencing the entry by it's exact dn.
Former comment could be ignored to not to mix this RFE which involve tombstones with skipping replication conflicts from queries.
ticket 48161 has been created to trace this different requirement.
Per triage, pushing to 1.3.6.
Metadata Update from @nhosoi: - Issue assigned to lkrispen - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Custom field component reset (from Replication - General) - Issue close_status updated to: None - Issue set to the milestone: FUTURE (was: 1.3.6.0)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/160
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.