On Wed, 2017-11-08 at 00:11 -0600, Sergei Gerasenko wrote: > 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-u > s/red_hat_directory_server/10/html/administration_guide/managing_repl > ication-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. No problem. I think there is an easier way to simulate this. Make sure you have MMR setup (IE agreement from M1 -> M2, and M2 -> M1). Then on both, there is an agreement object, something like: cn=ExampleAgreement,cn=replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config To that object on *BOTH* masters add: nsds5ReplicaEnabled: off This will pause all replication. Now, add your "user1" to both M1 and M2. Try to make them have the same DN, but different attributes like: uid=user,ou=People,.... ... description: m1 uid=user,ou=People,.... ... description: m2 Next, on both masters set: nsds5ReplicaEnabled: on This will trigger a replication update. You should have conflict entries on your servers now :) Anyway, in reality, it's rare you'll ever see conflicts like this, but I'm glad you are researching this so thoroughly, > > Thanks, > Sergei > > > On Nov 7, 2017, at 4:44 PM, William Brown <wibrown@xxxxxxxxxx> > > 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/d > > > ocum > > > 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.fedoraproje > > > ct.o > > > rg > > > > -- > > Sincerely, > > > > William Brown > > Software Engineer > > Red Hat, Australia/Brisbane > > _______________________________________________ > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject > > .org > > _______________________________________________ > 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
