On 7/24/19 6:03 PM, François Cami wrote:
On Wed, Jul 24, 2019 at 5:52 PM François Cami
<fcami(a)redhat.com> wrote:
>
> On Wed, Jul 24, 2019 at 5:48 PM Till Hofmann <thofmann(a)fedoraproject.org>
wrote:
>>
>>
>>
>> On 7/24/19 4:03 PM, Till Hofmann wrote:
>>> Hi François,
>>>
>>> Thanks for the reply!
>>>
>>> On 7/24/19 2:32 PM, François Cami wrote:
>>>
>>>>>
>>>>> Interestingly, during the setup of the replica, the setup is stuck
for quite some time (~30 minutes) in the step " [1/28]: configuring certificate
server instance". In the ns-slapd log, I can see a lot of the following:
>>>>> INFO - import_monitor_threads - import ipaca: Processed 40105 entries
-- average rate 123.8/sec, recent rate 114.0/sec, hit ratio 100%
>>>>> I'm surprised by the number of entries. I had set up the same
host as a replica in a previous try, but needed to remove it due to another error. May
those be left-overs from the previous replica instance? I didn't see this happening on
the first attempt. Before redoing the setup, I removed the host from the replica set with
`ipa-replica-manage del --force`, from the csreplica with `ipa-csreplica-manage del
--force`, and also deleted the host entry itself with `ipa host-del`. I also uninstalled
the freeipa server on the replica host.
>>>>
>>>> Could you count the actual number of requests records in the o=ipaca
>>>> suffix and examine them?
>>>
>>>
>>> I'm not exactly sure what you mean (I don't have much experience
with
>>> LDAP). Searching for "(objectclass=ipaca*)" gives me 2 results (but
I
>>> guess that's not what you meant). On the replica, ns-slapd processed
>>> 267358 entries before finishing.
>>
>> OK, I was looking in the wrong place. The number of request records in
>> LDAP is 268721. I'm not sure what exactly I should be looking for, but I
>> don't see anything unusual.
>
> I could be wrong but at 114 entries processed per second, 268721 would
> need 37 mins to complete and the timeout is at 5 mins (the 300 seconds
> above).
>
> Let me investigate a bit more and I'll get back to you.
So it looks like you are hitting an issue Rob is already working on:
https://github.com/freeipa/freeipa/pull/3374
but the fix is WIP.
In the meantime, can you edit ipalib/constants.py in your system?
Around line 175 there should be:
('replication_wait_timeout', 300),
It should be safe to replace 300 with 3600 at replica install time.
If install succeeds then wait at least 1h then shut down services:
# ipactl stop
revert the above change, and restart IPA:
# ipactl start
Please let us know if this helped.
Thanks for the suggestion. Unfortunately, that didn't help. The timeout
timer only starts after the last step (28/28), but the syncing already
happens before that, so the timeout doesn't affect that. I see the same
errors as before, just for a longer time.
I could get one step further by modifying the tomcat config so it
wouldn't use the certificate, similar to what they did here:
https://www.redhat.com/archives/freeipa-users/2017-January/msg00216.html
However, that's just a workaround. Also, I immediately get another error:
testLDAPConnection: The specified user cn=Replication Manager
masterAgreement1-replica.fqdn-pki-tomcat,cn=config does not exist
CMSEngine: init(): password test execution failed for replicationdbwith
NO_SUCH_USER. This may not be a latest instance. Ignoring ..
Kind regards,
Till