[Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Petr Vobornik]

On 01/20/2016 12:31 AM, Rob Crittenden wrote:
> Nathan Peters wrote:
>> [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 ADD dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config"
>>   [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 RESULT err=68 tag=105 nentries=0 etime=0
>>   [18/Jan/2016:09:28:33 -0800] conn=18732 op=11 UNBIND
>>
>> Do you mean that log entry ^?  I am seeing that entry on dc2-ipa-dev-nvan, the host that dc1-ipa-dev-van is contacting as its master when we attempt the ipa-replica-install.  Look through my earlier posts in this thread for a full log.
>
> Don't assume we have any idea what your hostnames mean, especially when
> they differ only by a few characters. It is good to list them but I'd
> also suggest you use terms like existing master and new server or
> something so we can distinguish the players without having to slowly
> parse every name.
>
>> Yes, of course that DN exists on all my masters.  With a 3 way replication it would have to exist because the current master is replicating to 2 other masters.  Here is the ldapsearch for all 3 existing hosts showing that DN (dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config") which is apparently failing to be added because it already exists on all my hosts.
>
> The important thing here is that cn=config is not replicated. It is
> configured on each master during replica setup, exactly where it is
> failing for you. Given that it is failing on ANOTHER server says a lot.
>
> It is failing, I think in part, because this search on the remote master
> is returning no entries:
>
> [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 SRCH
> base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config"
> scope=0 filter="(objectClass=*)" attrs=ALL
> [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 RESULT err=0 tag=101
> nentries=0 etime=0

IMO this is the culprit. It should return the entry if it is in fact there.

>
> Right after this is the ADD which fails with err=68 which means that in
> fact, it does exist.
>
> I'm not sure why this is happening. I don't immediately see why a
> NotFound would be raised in this case but I'm guessing it is. It would
> be interesting to walk through the code using the python debugger, pdb.
>
> In any case the duplicate entry is due to the replica setup code trying
> to configure the remote master for basic replication and this has
> already been done.

Yes the replica code works as expected.

Next step is to investigate why the search returns nothing. ACI issue? 
Weird DB state?

Can other user fetch it? E.g. admin?

If so wow does "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping 
tree,cn=config" on the master server looks like?
-- 
Petr Vobornik