Hi, If I wanted to simulate a conflict the way it’s described in the RedHat documentation (14.23.1.1. Renaming an Entry with a Multi-Valued Naming Attribute <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-solving_common_replication_conflicts>) with a series of LDIF transformations, what would be the LDIFs? I installed and set up a 389 instance in a VM for this purpose.
I tried adding: user1 user2 Then I tried to modrdn user2 to nsuniqueid=VALUE+user1, but got this error: Rename Result: Server is unwilling to perform (53) Additional info: new superior is identical to the entry dn The exact LDIF for the ldapmodrdn command was: uid=user1,ou=People,dc=example,dc=com uid=nsuniqueid=82d86a81-c44811e7-b207809a-7d9aed98+user1 I’m just getting my feet wet with LDAP, so bear with me. Thanks, Sergei > On Nov 7, 2017, at 4:44 PM, William Brown <wibr...@redhat.com> wrote: > > On Tue, 2017-11-07 at 13:33 -0600, Sergei Gerasenko wrote: >> Hi, >> >> I was going through RedHat’s documentation on naming conflicts. >> Here’s what it says at the beginning (https://access.redhat.com/docum >> entation/en- >> us/red_hat_directory_server/10/html/administration_guide/managing_rep >> lication-solving_common_replication_conflicts >> <https://access.redhat.com/documentation/en- >> us/red_hat_directory_server/10/html/administration_guide/managing_rep >> lication-solving_common_replication_conflicts>): >> >> 14.23.1. Solving Naming Conflicts >> When two entries are created with the same DN on different servers, >> the automatic conflict resolution procedure during replication >> renames the last entry created, including the entry's unique >> identifier in the DN. Every directory entry includes a unique >> identifier given by the operational attribute nsuniqueid. When a >> naming conflict occurs, this unique ID is appended to the non-unique >> DN. >> <> >> What I don’t understand is how conflicts can happen at all if the >> last one wins? > > The point is that if the last one wins, what do we do with the first? > We don't want to just delete it in case the order of operations was not > what the admin expected. So when you do: > > Master 1 Master 2 > > Time 0 ADD E > > Time 1 ADD E > > We are going to keep M1 E, and we'll conflict on M2 E - this becomes > the conflict entry. > >> Also, they are talking about solutions to the conflicts and >> specifically renaming the user that has nsuniqueid prepended. Does >> that assume that the conflicting user is actually another person? Or >> does it mean the conflicting record denotes the same user? If it’s >> the same user, shouldn’t the conflicting record just be removed? >> Really confused about the nature of the problem and the suggested >> solutions. >> Thanks! > > See above. It's about preserving the duplicate entry incase the > administrator wishes to revive them or see what happened. :) > > > Hope that helps, Ludwig might have more to say on this. > >> _______________________________________________ >> 389-users mailing list -- 389-users@lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o >> rg > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
