IPA cannot handle Multi-master Replication conflicts correctly. Attribute conflicts are solved via 389-ds, but conflicts over DN not. When 2 LDAP records with the same DN are detected during synchronization, 389-ds renames one of them to, e.g. dn: nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com which will confuse the IPA server.
dn: nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
In this case, user-find will display records like this one but is not able to manipulate it (rename, delete). This may lead to unpleasant issues that can be solved only by manual LDAP update. IPA should provide some way to at least remove (preferably rename) records like these.
user-find
Reproduction scenario:
Prepare 3 replicating IPA servers in a star topology. Shut down the central server (SRV1) and add a record with the same DN on the remaining boxes (SRV2, SRV3), e.g.:
SRV2: $ ipa user-add --first=User1 --last=Test1 utest SRV3: $ ipa user-add --first=User2 --last=Test2 utest
Start the SRV1 again, directory synchronization will create the following 2 records:
SRV1: $ ipa user-find --all --raw dn: uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid: utest givenname: User2 sn: Test2 ... dn: nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid: utest givenname: User1 sn: Test1 cn: User1 Test1 ...
Then:
$ ipa user-del utest ---------------------- Deleted user "utest" ---------------------- $ ipa user-add --first=User --last=Test utest ipa: ERROR: Constraint violation: Another entry with the same attribute value already exists (attribute: "krbPrincipalName")
because of dangling record dn: nsuniqueid=...+uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
dn: nsuniqueid=...+uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
Alternative approach would be fix replication conflicts on Directory Server side. Possible approaches:
Related ticket: #1174
RFE for 389-ds replication improvement: https://bugzilla.redhat.com/show_bug.cgi?id=747701
Moving the ticket to the next month iteration.
The 389-ds bug is getting pushed back so we will need to deal with conflicts on our own initially.
A conflict entry gets a new objectclass added, nsds5replconflict, so we should be able to filter on that to find any entries. How one would use this to resolve the conflict is another matter.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=772294
We will open a doc bug for now to cover the manual procedure until the issue is addressed in 389 and we can create tools around it.
Opened ticket 2258 to document
This is 389-ds ticket https://fedorahosted.org/389/ticket/160
Moving my tickets back to free-to-take pool.
Another DS ticket with alternate proposal:
https://fedorahosted.org/389/ticket/48161
Metadata Update from @mkosek: - Issue assigned to someone - Issue set to the milestone: Ticket Backlog
Login to comment on this ticket.