Kat via FreeIPA-users wrote:
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. :-)
You'd need to correlate the install log with the installer code to see
what wasn't run once the installation failed. Perhaps it is just minor
stuff, or nothing at all, I don't know.
rob
-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(a)lists.fedorahosted.org
>>>> To unsubscribe send an email to
>>>> freeipa-users-leave(a)lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org