Thanks Willam. It does make sense now. I don't know how I could have misunderstood it
:) So thank you again for clarifying it!
> On Nov 7, 2017, at 4:44 PM, William Brown <wibrown(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
>> rg
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org