On Thu, 19 Oct 2017 09:16:00 -0400, Paul Robert Marino <[log in to unmask]> 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 <[log in to unmask]>
>wrote:
>
>> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold <[log in to unmask]>
>> 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
>>
>
|