#160 Make replication plugin put conflicts and tombstones in a special suffix
Closed: wontfix 4 months ago by mreynolds. Opened 8 years ago by rmeggins.

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

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

3 years ago

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)

3 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 months ago

Login to comment on this ticket.

Metadata