Re: Solving Naming Conflicts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
> rg
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux