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/", line 172, in execute
    return_value =

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
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.

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/ --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.



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


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)


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

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
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
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 ?


FreeIPA-users mailing list --
To unsubscribe send an email to
FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to