Thought I would share some "trickery" I used to resolve this.
So it seems it wants to go to another server to try to check for keys,
which I don't know why, since it was not being setup from server "A" -
and that server was not reachable from this VPC anyway.
2018-02-09T14:16:48Z INFO Waiting up to 300 seconds to see our keys
appear on host: "A"
2018-02-09T14:16:48Z DEBUG Transient error getting keys: '{'desc':
"Can't contact LDAP server"}'
2018-02-09T14:21:49Z DEBUG File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in
execute
return_value = self.run()
However, when I checked the status of the replica with "ipactl status" -
well, as expected, everything was not running. For grins, I tried to
"start" it and got the error:
# ipactl restart
Upgrade required: please run ipa-server-upgrade command
Aborting ipactl
So, what harm would there be in trying it. I ran :
# ipa-server-upgrade
Missing version: no platform stored
Upgrading IPA:. Estimated time: 1 minute 30 seconds
[1/8]: saving configuration
[2/8]: disabling listeners
[3/8]: enabling DS global lock
[4/8]: starting directory server
[5/8]: updating schema
[6/8]: upgrading server
[7/8]: stopping directory server
[8/8]: restoring configuration
Done.
Update complete
Upgrading IPA services
Upgrading the configuration of the IPA services
... (lots more removed)
The IPA services were upgraded
The ipa-server-upgrade command was successful
And finally:
# ipactl restart
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting ipa-otpd Service
ipa: INFO: The ipactl command was successful
And everything checks out - even created some objects/users and
replication seems to be working just fine.
I did run a re-init just to make sure:
# ipa-replica-manage re-initialize --from=E
Update in progress, 3 seconds elapsed
Update succeeded
So who knows - maybe I outsmarted it.
Kat
On 2/6/18 13:03, Rob Crittenden wrote:
Kat via FreeIPA-users wrote:
> And now a new error if I just try to install as a simple replica with no
> CA or DNS :-(
>
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 30 seconds
> [1/40]: creating directory server instance
> [error] RuntimeError: failed to create DS instance Command
> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpml5FQc' returned
> non-zero exit status 1
>
> Any ideas/suggestions on this one? Only ran "ipa-replica-install" after
> client was installed and working. So frustrating since the other 4 have
> been working flawlessly for months.
>
You have to look in ipareplica-install.log for details.
rob
> -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.
>>>>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org