[Freeipa-users] ipa-client-install does not seem to like the ipa's ntp

Tue Feb 11 09:12:50 UTC 2014

On 02/10/2014 10:08 PM, Mauricio Tavares wrote:
> On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal <dpal at redhat.com> wrote:
>> On 02/09/2014 09:52 PM, Mauricio Tavares wrote:
>>>
>>> On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard<sdainard at miovision.com>
>>> wrote:
>>>>
>>>> I've noticed if ntpd is already running on the client when you run the
>>>> ipa-client-install, you will get that error. I'm guessing its using
>>>> ntpdate
>>>> IP ADDRESS to sync time, and cannot do so when the daemon is running.
>>>>
>>>> I've noticed if ntpd is already running on the client when you run the
>>>> ipa-client-install, you will get that error. I'm guessing its using
>>>> ntpdate
>>>> IP ADDRESS to sync time, and cannot do so when the daemon is running.
>>>>
>>>        Now that you mentioned that I would agree with you in that it is
>>> failing because ntpd is running already; I could not see it because of
>>> the option "-s" in
>>>
>>> [root at centos64 ~]# service ntpd status
>>> ntpd (pid  3721) is running...
>>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com
>>> [root at centos64 ~]#
>>>
>>> I could not find what all of those arguments mean in the centos 6.5
>>> ntpdate man page, but here is what I found under ubuntu's:
>>>
>>>         -b     Force  the  time  to  be stepped using the settimeofday()
>>> system
>>>                call, rather than slewed (default) using  the  adjtime()
>>> system
>>>                call. This option should be used when called from a startup
>>> file
>>>                at boot time.
>>>
>>>         -s     Divert logging output from the standard output (default) to
>>> the
>>>                system  syslog  facility.  This is designed primarily for
>>> conve‐
>>>                nience of cron scripts.
>>>
>>>         -v     Be verbose. This option will cause ntpdate's version
>>> identifica‐
>>>                tion string to be logged.
>>>
>>> In other words, -s is sending the output to syslog. And, if we check
>>> /var/log/messages we will find that
>>>
>>> Feb  9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting
>>>
>>> as you expected. Now, how did it detect the ntpdate failed?
>>>
>>>> Steve
>>>>
>>>>
>>>> On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares<raubvogel at gmail.com>
>>>> wrote:
>>>>>
>>>>>        Even though I already have a ntp server, I setup my newly
>>>>> created freeipa kdc to do that too (it is a slave to my primary ntp).
>>>>>
>>>>> I then build a centos host to be the test client. Just to make sure it
>>>>> can see and use auth's ntp, I tested with ntpdate:
>>>>>
>>>>> [root at centos64 ~]# ntpdate auth
>>>>>   8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset
>>>>> -0.003097 sec
>>>>> [root at centos64 ~]#
>>>>>
>>>>> so far so good, so how about running ipa-client-install?
>>>>>
>>>>> [root at centos64 ~]# hostname
>>>>> centos64
>>>>> [root at centos64 ~]# ipa-client-install --hostname=`hostname -f`
>>>>> Discovery was successful!
>>>>> Hostname: centos64.in.domain.com
>>>>> Realm: DOMAIN.COM
>>>>> DNS Domain: domain.com
>>>>> IPA Server: auth.in.domain.com
>>>>> BaseDN: dc=domain,dc=com
>>>>>
>>>>> [so far so good!]
>>>>>
>>>>> Continue to configure the system with these values? [no]: yes
>>>>> User authorized to enroll computers: admin
>>>>> Synchronizing time with KDC...
>>>>> Unable to sync time with IPA NTP server, assuming the time is in sync.
>>>>> Please check that 123 UDP port is opened.
>>>>> Password for admin at DOMAIN.COM:
>>>>>
>>>>> But, it had not problems using ntpdate against auth.  to add insult to
>>>>> injury, the log claims it is using ntpdate:
>>>>>
>>>>> 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v
>>>>> auth.in.domain.com
>>>>> 2014-02-08T13:14:31Z DEBUG stdout=
>>>>> 2014-02-08T13:14:31Z DEBUG stderr=
>>>>> 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server,
>>>>> assuming the time is in sync. Please check that 123 UDP port is
>>>>> opened.
>>>>>
>>>>> Could it be it is pissed because it was in sync to begin with? I mean,
>>>>> if we run the exact command the log file claims to have run,
>>>>>
>>>>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com|
>>>>> echo $?
>>>>> 0
>>>>> [root at centos64 ~]#
>>>>>
>>>>> We see it was successful.
>>>>>
>>>>> I am feeling rather clueless here...
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>
>>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>> This sounds like a bug to me but I would wait for European gurus to chime in
>> the morning.
>> If it is a bug we need a ticket.
>>
>       I dunno where to file a ticket but here is my suggestion:
> 
> in /usr/lib/python2.6/site-packages/ipaclient/ntpconf.py, function def
> synconce_ntp(server_fqdn):
> 
> replace
> 
>         cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", server_fqdn]
> 
> with
> 
>         cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", "-u", server_fqdn]
> 
> Reasoning:
> 
> [root at centos64 ~]# date +%T -s "10:13:13"
> 10:13:13
> [root at centos64 ~]# date
> Mon Feb 10 10:13:15 EST 2014
> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v -u auth
> [root at centos64 ~]# date
> Mon Feb 10 16:05:49 EST 2014
> [root at centos64 ~]# service ntpd status
> ntpd (pid  8870) is running...
> [root at centos64 ~]#

Just to close the loop - this is the filed Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1063512

I will clone it upstream so that we can triage it.

Martin