On 06/16/2015 05:07 AM, Janelle wrote:
these entries are already a result of conflict resolution, If you add
the same entry simultaneously on two servers (meaning add it on A and
add it on B (before B has received the replicated add from A), there
exist two entries with the same dn, which is not possible. So conflict
resolution does not arbitrarily throw one away, but renames it and
leaves it to the admin, which on to keep. So you should have one entry
On 6/15/15 1:12 PM, Rob Crittenden wrote:
On 6/15/15 6:36 AM, Rob Crittenden wrote:
Usually means there is a replication conflict entry. You may be able
to get more details on what failed by looking at the LDAP access log
of both LDAP servers, though I guess I'd expect this happened locally
on the IPA box.
I have been trying to follow this procedure for replication conflicts
regarding "nsds5ReplConflict", where I had the two account duplicates,
but no matter what, I still get:
modifying rdn of entry
ldap_rename: Constraint violation
additional info: Another entry with the same attribute value
already exists (attribute: "uid")
When I am trying to run the modrdn (ldapmodify) command? Which simply
refuses to work. I have been at it for over a week now with no luck.
I think this is the last of my issues causing my replication problems.
What caused this is that I do have multiple helpdesk personnel that
had been updating user accounts. This process has been resolved, but
we can't seem to remove the last few duplicates.
Any suggestions? Is there a missing step in conflict resolution perhaps?
uid=janelle,... and one nsuniqueid=nnnn+uid=janelle,....
you can delete the nsuniqeid=nnnn entry to get rid of it.
There is a request to hide these nsuniqueid+uid entries from regular
searches, it will be in a next release of 389
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project