Rob -
Yes, I do wonder about that, but I am adding missing pieces manually -
ipa-dns-install (no errors)
ipa-ca-install (no errors)
so, I have rebooted a few times, rechecked logs and don't seem to have
further errors. I know this is risky, but I refused to believe this
would not work. :-)
-K
On 2/9/18 10:07, Rob Crittenden wrote:
Kat wrote:
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.
So the installer failed at some point and then you ran the upgrader?
It is possible that there are still things that remain unconfigured,
perhaps subtle things.
rob
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@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
