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

Petr Spacek pspacek at redhat.com
Tue Feb 11 12:07:42 UTC 2014


On 11.2.2014 12:46, Mauricio Tavares wrote:
> On Feb 11, 2014 4:12 AM, "Martin Kosek" <mkosek at redhat.com> wrote:
>>
>> 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.
>
> Sorry. I didn't know I could submit a patch and how. It's already
> impressive I did the bugzilla thing. I can also do the patch, but would it
> then be redundant?

Bugzilla is just a bug tracker - it allows us to organize development and to 
know what we need to fix/add etc.

If you send a patch we will handle the paperwork for you (I mean closing the 
bug etc.) :-)

If you want to send a patch, please follow instructions on page:
http://www.freeipa.org/page/Contribute/Code#Get_the_source

Don't hesitate to ask any question.

Thank you for your time. Have a nice day!

-- 
Petr^2 Spacek




More information about the Freeipa-users mailing list