During ipa-client-install, we attempt to sync the time with the server before getting a Kerberos ticket for the user who is joining the client. On fedora 20, this used ntpdate. On fedora 21, this uses ntpd. If ntpdate is unable to reach the ntp server, it will timeout and the client install continues. The ntpd command will never timeout if it can't reach the ntp server, which results in an indefinite hang of ipa-client-install.
The debug output of ipa-client-install will end up hanging here:
----------------------------------------------------- ... Synchronizing time with KDC... Search DNS for SRV record of _ntp._udp.example.test DNS record found: 0 100 123 ipa.example.test. Starting external process args='/usr/sbin/ntpd' '-qgc' '/tmp/tmpRhhyCz' -----------------------------------------------------
It would be nice to add a timeout to ipa-client-install to allow it to bail out if ntpd never returns. We could simply log a warning that we are unable to sync the time and continue on with the installation.
We have a few options for addressing this:
1 - Make the "--no-ntp" option for ipa-client-install skip the time synchronization before attempting to get the TGT of the user who is joining the client system. This is an easy change, but one has to no to use it to avoid the hang that occurs when the NTP server is not reachable.
2 - Add a timeout for running 'ntpd -q'. There is no capability for a timeout in 'ntpd' itself, so we would need to implement one ourselves. We run 'ntpd' via ipautil.run(), which uses subprocess.Popen. As of Python 3.3, Popen.communicate() supports a timeout option. There is a backport of the Python 3.x subprocess module that includes this timeout support for Python 2.x called subprocess32. It's even packaged for Fedora as python-subprocess32. We could add a dependency on this pacakge and use this model until such time that we are able to use Python 3.3+. We would then be able to extend ipautil.run() to allow timeouts to be used if desired, which we would make use of when calling 'ntpd -q' from ipa-client-install.
This bug prevents recommended deployment with Ipsilon. The patch is on the list. Bumping priority and setting the NEEDS_TRIAGE.
The patch was reviewed, given it is a blocker, I would like to having it fixed in 4.1.x, with special F21+ builds.
master:
ipa-4-1:
Does this also fix ticket 3092?
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1211708 (Red Hat Enterprise Linux 7)
Forgotten reference:
Metadata Update from @nkinder: - Issue assigned to nkinder - Issue set to the milestone: FreeIPA 4.1.4
Login to comment on this ticket.