[Freeipa-users] Migration error?

[Rich Megginson]

On 06/16/2015 06:18 AM, Ludwig Krispenz wrote:
>
> On 06/16/2015 02:08 PM, Janelle wrote:
>> On Jun 16, 2015, at 01:56, thierry bordaz <tbordaz at redhat.com> wrote:
>>>> On 06/16/2015 09:02 AM, Ludwig Krispenz wrote:
>>>>
>>>>> On 06/16/2015 05:07 AM, Janelle wrote:
>>>>>> On 6/15/15 1:12 PM, Rob Crittenden wrote:
>>>>>> Janelle 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.
>>>>> Hi again,
>>>>>
>>>>> 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 
>>>>> "nsuniqueid=ffc68a41-86e71c6-71714816-fcf248a0+uid=janelle,cn=users,cn=accounts,dc=example,dc=com"
>>>>> 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?
>>>> 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
>>>> uid=janelle,... and one nsuniqueid=nnnn+uid=janelle,....
>>> The error you get is coming from 'uid uniqueness'. Like ludwig 
>>> mention,  it exists duplicated entries  with both of them 
>>> 'uid=janelle'.
>>> 'uid uniqueness' plugin prevents you to do a direct MODRDN on one of 
>>> them because, it finds duplicated 'uid=janelle'.
>>>> you can delete the nsuniqeid=nnnn entry to get rid of it.
>>> +1
>>>
>>> thierry
>>>> There is a request to hide these nsuniqueid+uid entries from 
>>>> regular searches, it will be in a next release of 389
>>>>
>>>> Ludwig
>>>>> ~J
>>> -- 
>> But everything I try to delete fails.  Is there a procedure in 389-DS 
>> I can read for this? Maybe I am missing an option in ldapmodify? I am 
>> happy to delete, if only it would let me.
> hm, it should be straightforwrd:
> ldpapmodify -D <user which has permissions to delete> ..
> dn: 
> nsuniqueid=ffc68a41-86e71c6-71714816-fcf248a0+uid=janelle,cn=users,cn=accounts,dc=example,dc=com
> changetype: delete
>
> if it fails, what is the error you get ?

This is probably https://fedorahosted.org/389/ticket/48133
which is fixed in 389-ds-base-1.2.11.15-53.el6

>>
>> ~J
>