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

Tue Feb 11 11:46:24 UTC 2014

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?
>
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140211/57486cb2/attachment.htm>