The plot thickens - it has nothing to do with replication.
If I try to install a brand new IPA Server instance, that too fails with
the sam error of the dirsrv failure.
Time to rebuild the instance to see what is going on.
-K
On 2/5/18 12:52, Simo Sorce wrote:
I think this could be considered a bug, not sure if there is a
ticket
open already, but I think someone else reported something similar
previously.
Simo.
On Mon, 2018-02-05 at 10:06 -0600, Kat wrote:
> Yes, D is CA
>
> Firewalling is not 100% accurate. The masters are in different VPCs
> across AWS AZ's. I use secure tunnels (stunnel) to connect the
> master/replicas, which has worked fine for months. This is the 3rd VPC.
> And in this case, rather than stunnel decided to peer the VPCs instead.
>
> They are all DNS servers too, but because of the unique VPCs, used
> "location" settings to have DNS work properly (this works great BTW)
>
> -k
>
>
> On 2/5/18 09:58, Simo Sorce wrote:
>> On Sun, 2018-02-04 at 14:28 -0600, Kat via FreeIPA-users wrote:
>>> This is a new one I have not seen before.
>>>
>>> Have 4 servers, trying to add a 5th.
>>>
>>> Master A and B (in one location) can talk to C and D (in another location)
>>>
>>> Trying to add E, which is a new location with the master to replicate
>>> from being D.
>>>
>>> When I run client install, no issues at all. Then I try to install E as
>>> a replica with DNS and CA setup and it gets almost all the way and ends
>>> up failing with (from the logs):
>>>
>>> 2018-02-04T20:00:56Z DEBUG The ipa-replica-install command failed,
>>> exception: RuntimeError: Timed out trying to obtain keys.
>>> 2018-02-04T20:00:56Z ERROR Timed out trying to obtain keys.
>>>
>>> It actually dies at:
>>>
>>> Done configuring ipa-otpd.
>>> Configuring ipa-custodia
>>> [1/4]: Generating ipa-custodia config file
>>> [2/4]: Generating ipa-custodia keys
>>> [3/4]: starting ipa-custodia
>>> [4/4]: configuring ipa-custodia to start on boot
>>> Done configuring ipa-custodia.
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>> What is confusing, the log also shows that it times out waiting for keys
>>> to appear on "A", which it cannot get to because of
location/firewall
>>> settings. What I don't understand, since I am building the replica off
>>> "D", why is it trying to communicate with A?
>>>
>>> Any ideas on how to resolve this?
>> Is D a CA master ?
>> I think the replica installation code picks the first master it can
>> find, so it may be picking A (if that's a CA) in your case.
>>
>> What's the reason to firewall off masters from each other ?
>>
>> Simo.
>>
>