On Feb 11, 2014 4:12 AM, "Martin Kosek" <[email protected]> wrote: > > On 02/10/2014 10:08 PM, Mauricio Tavares wrote: > > On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal <[email protected]> wrote: > >> On 02/09/2014 09:52 PM, Mauricio Tavares wrote: > >>> > >>> On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard<[email protected]> > >>> 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@centos64 ~]# service ntpd status > >>> ntpd (pid 3721) is running... > >>> [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com > >>> [root@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<[email protected]> > >>>> 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@centos64 ~]# ntpdate auth > >>>>> 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset > >>>>> -0.003097 sec > >>>>> [root@centos64 ~]# > >>>>> > >>>>> so far so good, so how about running ipa-client-install? > >>>>> > >>>>> [root@centos64 ~]# hostname > >>>>> centos64 > >>>>> [root@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 [email protected]: > >>>>> > >>>>> 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@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| > >>>>> echo $? > >>>>> 0 > >>>>> [root@centos64 ~]# > >>>>> > >>>>> We see it was successful. > >>>>> > >>>>> I am feeling rather clueless here... > >>>>> > >>>>> _______________________________________________ > >>>>> Freeipa-users mailing list > >>>>> [email protected] > >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> > >>>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> [email protected] > >>> 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@centos64 ~]# date +%T -s "10:13:13" > > 10:13:13 > > [root@centos64 ~]# date > > Mon Feb 10 10:13:15 EST 2014 > > [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v -u auth > > [root@centos64 ~]# date > > Mon Feb 10 16:05:49 EST 2014 > > [root@centos64 ~]# service ntpd status > > ntpd (pid 8870) is running... > > [root@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
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
