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(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/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(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproje
> > ct.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
_______________________________________________
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