I am looging this RFE as a complement of
ticket 160:Make replication plugin put conflicts and tombstones in a special suffix
This ticket concerns only replication conflicts. Several clients are finding replication in queries like, for instance, named (component bind-dyn-ldap):
DNApr 16 18:05:02 ipaserver named[5340]: failed to convert DN 'nsuniqueid=f311d481-7ded11e3-8956f0ed-685ab636,idnsname=XXX.com ,cn=dns,dc=xxx,dc=local' to DNS name:
It could be interesting to have replication conflicts hidden as, for instance, belonging to objectclass: ldapsubentry.
it is not possible to completely hide the results of conflict resolution. If the two conflicting entries have different children, this will be reflected in their dn, independent if the conflicting entry is hidden or not.
This is the scenario: on A add dn: cn=user_YYY,<suffix> dn: cn=child_Y1,cn=user_YYY,<suffix>
on B add (simultaneosly): dn: cn=user_YYY,<suffix> dn: cn=child_Y2,cn=user_YYY,<suffix>
NOTE: parent dn is identical, child dn is not.
After replication we have: dn: cn=user_YYY,ou=People,dc=example,dc=com
dn: cn=child_Y1,cn=user_YYY,ou=People,dc=example,dc=com
dn: cn=user_YYY+nsuniqueid=28ad5989-13f611e5-ac309989-c3cc84f8,ou=People,dc=example,dc=com
dn: cn=child_Y2,cn=user_YYY+nsuniqueid=28ad5989-13f611e5-ac309989-c3cc84f8,ou=People,dc=example,dc=com
we could hide the conflicting entry, but not its child.
This scenario also makes the original request unfeasable, if we would put the entry into a separate backend, we would have an orphaned child
Good point, this is a problem. What about adding ldapsubentry objectclass to conflicting entries to hide them from ordinary searches?
ldapsubentry
Couldn't be the children of a conflicting entry considered also replication conflicts and logged as such ?
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274434
Metadata Update from @lkrispen: - Issue set to the milestone: 1.3.6 backlog
Metadata Update from @mreynolds: - Issue close_status updated to: None - Issue set to the milestone: 1.4 backlog (was: 1.3.6 backlog)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue tagged with: RFE
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/1492
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.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.