On Thu, 19 Oct 2017 09:16:00 -0400, Paul Robert Marino <prmari...@gmail.com> wrote:
>well the clock sqew allowed is a client side setting and may be different >on the two the real question is what is the time on the kerberos server? My only access to the server is via kinit, so I can't see the time there or the krb5.conf file. But it seems unlikely that they would suddenly have switched to millisecond tolerance for skew when the standard is 5 minutes. >the clock sqew probably there not on the clients, The clock sqew allowed is >set in the/etc/krb5.conf file by default (and also has a default value if >not specified) however may be overriden by the library call so in other >words the pam module may also over ride the defaults. Sometime they have >been known to change the default for clock sqew in the MIT Kerberos >libraries between major releases so thats probably why you are seeing this. >looking at differences in the upstream NTP servers is only something you >should consider when all of the other possibilities are exausted because >the public ones are usually getting their time from the same upstream >source (usually GPS which is fed by NORAD's atomic clock, or NTP from >NIST's or CERN'satomic clocks or other simmilar autoritative source all of >which syncronize with eachother regualrly ), and there for are very >unlikely to have more than a few miliseconds difference between them which >is not enough to cause such an error. > >In short look at your Kerberos server not the clients NTP servers as that >is most likely where the real clock drift issue is. > >Then next thing to check is the firewalls because NTP works in a veru >unusual way when compared to other protocols on the internet, for example >in netfilters firewalls you need to load a special conntrack helper module >to support it other wise it breaks due to the inability to the blocking of >related connections the source server tries to make back to the client >durring the syncronization process. >. > > > >On Wed, Oct 18, 2017 at 8:10 PM, Stephen Isard <7p03xy...@sneakemail.com> >wrote: > >> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold <herr...@owlriver.com> >> wrote: >> >> >On Wed, 18 Oct 2017, Howard, Chris wrote: >> > >> >> Is it possible the two boxes are talking to two different servers? >> > >> >as the initial post mentioned and showed it was using remote >> >host lists to a pool alias, almost certainly -- >> >> Oh, I took the question to be about the kerberos server. Yes, you are >> right, >> ntpd -q returns different results on the two machines. However, as I said >> in the original post, the time on the two machines is the same to within a >> very small amount., well within the five minute tolerance used by >> kerberos. So I don't understand why it should matter that the two machines >> have arrived at the same time by syncing with different servers. >> >> >as a way around, set up ONE unit to act as the local master, >> >and then sync against it, to get 'site coherent' time >> >> Could you tell me how to do this, or point me at a document that does? >> >> Thanks. >> >> >[a person with more than one clock is never quite _sure_ what >> >time is correct ;) ] >> > >> > >> >for extra geek points, spend $25 on AMZN, and get a GPS USB >> >dongle; run a local top strata server (the first three >> >lintes of the following) >> > >> >[root@router etc]# ntpq -p >> > remote refid st t when poll reach delay >> >offset jitter >> > ============================================================ >> ================= >> > GPS_NMEA(0) .GPS. 0 l - 16 0 0.000 >> >0.000 0.000 >> > SHM(0) .GPS. 0 l - 16 0 0.000 >> >0.000 0.000 >> > SHM(1) .PPS. 0 l - 16 0 0.000 >> >0.000 0.000 >> >+ntp1.versadns.c .PPS. 1 u 665 1024 377 51.817 >> >-12.510 19.938 >> >*tock.usshc.com .GPS. 1 u 294 1024 377 34.608 >> >-8.108 10.644 >> >+clmbs-ntp1.eng. 130.207.244.240 2 u 429 1024 377 31.520 >> >-5.674 7.484 >> >+ntp2.sbcglobal. 151.164.108.15 2 u 272 1024 377 23.117 >> >-6.825 10.479 >> >+ntp3.tamu.edu 165.91.23.54 2 u 1063 1024 377 63.723 >> >-3.319 16.813 >> >[root@router etc]# >> > >> > >> >configuring ntp.conf is not all that hard >> > >> >-- Russ herrold >> >