Re: clock skew too great ** EXTERNAL **
On Thu, 19 Oct 2017 12:48:42 -0400, Paul Robert Marino wrote: >Here is a question was it using preauth? >In other words is there a key tab file in /etc? No. >The other question is NTP set to sync the time on shutdown to the bios? I don't think so. Certainly no setting in /etc/ntp.conf or /etc/sysconfig/ntp. In any case there was no shutdown between the last successful kinit and the first skew error message. >There are a couple of reasons why I can think this might happen the first >involves how NTP corrects the time and how it may interact with how an >option in MIT kerberos client works and that article. There is an incorrect >statement in that article about disabling the time sync. It's not that the >option disables the time sync it just corrects for it when the ticket is >created to mask the issue. The problem with that is NTP usually doesn't >sync the time in one shot by default it only corrects it in less than 1 >second increments so it doesn't break time dependant things like cron jobs. >That flag in combination with the default behavior of NTP can cause an >artificial clock skew issue later. >Now you can set in /etc/sysconfig an option in the NTP settings to tell it >to do an initial full sync on boot before starting ntpd but it is not the >default behavior in 6 if I remember correctly. If a ticket had been created >and the clock had been more than 5 minutes out of sync you would have >gotten a clock skew error after the clock had corrected its self because it >would still have still been compensating for the initial skew. In this case >kdestroy would clear the skew correction and the new key would be >unaffected. > >The other possibility is that if preauth is being used there could have be >something wrong in how the service credential was created in the kerberos >server which is quite common if the server is an AD server, and sometimes >happens with Heimdal kerberos servers too. Essentially the other >possibility is it may have a max ticket renewal set on the principal in >which case a kdestroy may force it to redo the preauth and then create a >new ticket. Usually you can correct this in the kerberos server if your >Kerberos admin really knows it well sadly most AD admins don't :(. I've had >to show more than a few of them over the years articles on Microsoft >technet, and tell them just do that and stop insisting it can't be done. > >By the way that article is right about one thing the DNS reverse lookup in >MIT kerberos can be problematic because it can't support the use of CNAMEs >in the forward lookup, and is not specified any where in any of the >ratified RFCs ( in fact it was proposed and rejected by committee on that >basis) so it causes more problem especially when it interacts with other >kerberos implementation or is implemented in the cloud. It's also the only >implementation of Kerberos 5 that does it. It's not the only place where >MIT kerberos violates the RFCs and those violations are the reason why you >can't use it for Samba version 4 AD server, and why most Linux based >appliances that support kerberos use Heimdal kerberos. > > >On Oct 19, 2017 11:48 AM, "Stephen Isard" <7p03xy...@sneakemail.com> wrote: > >> On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky >> wrote: >> >> >If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does >> >not. This could account for why one works and the other does not. >> > >> >Pat >> > >> >[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos >> >> That looks promising as an explanation. >> >> The problem has been "solved", or at least it has gone away, although I >> don't really understand why. Without any clear hypothesis as to why it >> might help, I decided to run "kdestroy -A" on the affected machine to clear >> expired tickets out of my local cache. That did it. No more clock skew >> messages. So it looks as if it was a kerberos issue, rather than an ntp >> one, and the error message wasn't really explaining what was wrong. >> >> Thanks to everyone for their advice. >> >> Stephen Isard >> > >> >On 10/18/2017 07:10 PM, Stephen Isard wrote: >> >> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold >> 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 sy
Re: clock skew too great ** EXTERNAL **
Here is a question was it using preauth? In other words is there a key tab file in /etc? The other question is NTP set to sync the time on shutdown to the bios? There are a couple of reasons why I can think this might happen the first involves how NTP corrects the time and how it may interact with how an option in MIT kerberos client works and that article. There is an incorrect statement in that article about disabling the time sync. It's not that the option disables the time sync it just corrects for it when the ticket is created to mask the issue. The problem with that is NTP usually doesn't sync the time in one shot by default it only corrects it in less than 1 second increments so it doesn't break time dependant things like cron jobs. That flag in combination with the default behavior of NTP can cause an artificial clock skew issue later. Now you can set in /etc/sysconfig an option in the NTP settings to tell it to do an initial full sync on boot before starting ntpd but it is not the default behavior in 6 if I remember correctly. If a ticket had been created and the clock had been more than 5 minutes out of sync you would have gotten a clock skew error after the clock had corrected its self because it would still have still been compensating for the initial skew. In this case kdestroy would clear the skew correction and the new key would be unaffected. The other possibility is that if preauth is being used there could have be something wrong in how the service credential was created in the kerberos server which is quite common if the server is an AD server, and sometimes happens with Heimdal kerberos servers too. Essentially the other possibility is it may have a max ticket renewal set on the principal in which case a kdestroy may force it to redo the preauth and then create a new ticket. Usually you can correct this in the kerberos server if your Kerberos admin really knows it well sadly most AD admins don't :(. I've had to show more than a few of them over the years articles on Microsoft technet, and tell them just do that and stop insisting it can't be done. By the way that article is right about one thing the DNS reverse lookup in MIT kerberos can be problematic because it can't support the use of CNAMEs in the forward lookup, and is not specified any where in any of the ratified RFCs ( in fact it was proposed and rejected by committee on that basis) so it causes more problem especially when it interacts with other kerberos implementation or is implemented in the cloud. It's also the only implementation of Kerberos 5 that does it. It's not the only place where MIT kerberos violates the RFCs and those violations are the reason why you can't use it for Samba version 4 AD server, and why most Linux based appliances that support kerberos use Heimdal kerberos. On Oct 19, 2017 11:48 AM, "Stephen Isard" <7p03xy...@sneakemail.com> wrote: > On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky > wrote: > > >If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does > >not. This could account for why one works and the other does not. > > > >Pat > > > >[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos > > That looks promising as an explanation. > > The problem has been "solved", or at least it has gone away, although I > don't really understand why. Without any clear hypothesis as to why it > might help, I decided to run "kdestroy -A" on the affected machine to clear > expired tickets out of my local cache. That did it. No more clock skew > messages. So it looks as if it was a kerberos issue, rather than an ntp > one, and the error message wasn't really explaining what was wrong. > > Thanks to everyone for their advice. > > Stephen Isard > > > >On 10/18/2017 07:10 PM, Stephen Isard wrote: > >> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold > 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 s
Re: clock skew too great ** EXTERNAL **
On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky wrote: >If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does >not. This could account for why one works and the other does not. > >Pat > >[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos That looks promising as an explanation. The problem has been "solved", or at least it has gone away, although I don't really understand why. Without any clear hypothesis as to why it might help, I decided to run "kdestroy -A" on the affected machine to clear expired tickets out of my local cache. That did it. No more clock skew messages. So it looks as if it was a kerberos issue, rather than an ntp one, and the error message wasn't really explaining what was wrong. Thanks to everyone for their advice. Stephen Isard > >On 10/18/2017 07:10 PM, Stephen Isard wrote: >> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold 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- 1600.000 >>> 0.000 0.000 >>> SHM(0) .GPS.0 l- 1600.000 >>> 0.000 0.000 >>> SHM(1) .PPS.0 l- 1600.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 > >-- >Pat Riehecky > >Fermi National Accelerator Laboratory >www.fnal.gov >www.scientificlinux.org
Re: clock skew too great ** EXTERNAL **
On Thu, 19 Oct 2017 09:16:00 -0400, Paul Robert Marino 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 >> 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- 1600.000 >> >0.000 0.000 >> > SHM(0) .GPS.0 l- 1600.000 >> >0.000 0.000 >> > SHM(1) .PPS.0 l- 1600.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 >> >
Re: clock skew too great ** EXTERNAL **
no difference there the time in both protocals are based on EPOC which means it is always using GMT time regardless of the OS settings. So that should make no difference in this case, though without NTP involved that has been a know issue for encrytion in genneral so its not a bad question just most likely irrelivant in this case. On Thu, Oct 19, 2017 at 9:42 AM, Howard, Chris wrote: > How about timezone? > > > -Original Message- > From: owner-scientific-linux-us...@listserv.fnal.gov [mailto: > owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen Isard > Sent: Wednesday, October 18, 2017 5:43 PM > To: scientific-linux-us...@listserv.fnal.gov > Subject: Re: clock skew too great ** EXTERNAL ** > > On Wed, 18 Oct 2017 21:02:53 +, Howard, Chris > wrote: > > >Is it possible the two boxes are talking to two different servers? > > Thanks for the idea, but no. The admin_server entry in /etc/krb5.conf is > the same on both machines, and the host command returns the same ip address > for that machine name on both machines. > > > > >-Original Message- > >From: owner-scientific-linux-us...@listserv.fnal.gov [mailto: > owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen Isard > >Sent: Wednesday, October 18, 2017 2:47 PM > >To: scientific-linux-us...@listserv.fnal.gov > >Subject: clock skew too great ** EXTERNAL ** > > > >Hello, > > > >I have two laptops side by side, one running SL6, the other SL7, both up > >to date. According to the date command, their times agree to within a > >small fraction of a second. > > > >On both machines, I normally run kinit to get a kerberos ticket in the > >same realm. Today, the SL7 machine gets its ticket normally, but the > >SL6 one shows an error message "Clock skew too great while getting > >initial credentials". Since the clocks of the two machines appear to > >agree, I would have expected that either both should produce the error > >or neither. From what I have read on the web, the standard tolerance > >for clock skew is 5 minutes, and the agreement between the times on the > >two machines is well within that. > > > >Both machines have ntpd running, using the time servers > >[0-3].rhel.pool.ntp.org. Powering off the SL6 machine and rebooting > >does not restore sanity. The problem just arose today. There have been > >no system updates on the SL6 machine since it successfully got its > >ticket yesterday. > > > >Any suggestions for what to try? > > > >Stephen Isard > > > > > > *** This email is from an EXTERNAL sender *** > >Use caution before responding. DO NOT open attachments or click links > from unknown senders or unexpected email. If this email appears to be sent > from a Platte River Power Authority employee or department, verify its > authenticity before acting or responding. Contact the IT Help Desk with any > questions. >
RE: clock skew too great ** EXTERNAL **
How about timezone? -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen Isard Sent: Wednesday, October 18, 2017 5:43 PM To: scientific-linux-us...@listserv.fnal.gov Subject: Re: clock skew too great ** EXTERNAL ** On Wed, 18 Oct 2017 21:02:53 +, Howard, Chris wrote: >Is it possible the two boxes are talking to two different servers? Thanks for the idea, but no. The admin_server entry in /etc/krb5.conf is the same on both machines, and the host command returns the same ip address for that machine name on both machines. >-Original Message- >From: owner-scientific-linux-us...@listserv.fnal.gov >[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen >Isard >Sent: Wednesday, October 18, 2017 2:47 PM >To: scientific-linux-us...@listserv.fnal.gov >Subject: clock skew too great ** EXTERNAL ** > >Hello, > >I have two laptops side by side, one running SL6, the other SL7, both up >to date. According to the date command, their times agree to within a >small fraction of a second. > >On both machines, I normally run kinit to get a kerberos ticket in the >same realm. Today, the SL7 machine gets its ticket normally, but the >SL6 one shows an error message "Clock skew too great while getting >initial credentials". Since the clocks of the two machines appear to >agree, I would have expected that either both should produce the error >or neither. From what I have read on the web, the standard tolerance >for clock skew is 5 minutes, and the agreement between the times on the >two machines is well within that. > >Both machines have ntpd running, using the time servers >[0-3].rhel.pool.ntp.org. Powering off the SL6 machine and rebooting >does not restore sanity. The problem just arose today. There have been >no system updates on the SL6 machine since it successfully got its >ticket yesterday. > >Any suggestions for what to try? > >Stephen Isard > > > *** This email is from an EXTERNAL sender *** >Use caution before responding. DO NOT open attachments or click links from >unknown senders or unexpected email. If this email appears to be sent from a >Platte River Power Authority employee or department, verify its authenticity >before acting or responding. Contact the IT Help Desk with any questions.
Re: clock skew too great ** EXTERNAL **
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? 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 > 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- 1600.000 > >0.000 0.000 > > SHM(0) .GPS.0 l- 1600.000 > >0.000 0.000 > > SHM(1) .PPS.0 l- 1600.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 >
Re: clock skew too great ** EXTERNAL **
On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold 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- 1600.000 >0.000 0.000 > SHM(0) .GPS.0 l- 1600.000 >0.000 0.000 > SHM(1) .PPS.0 l- 1600.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
Re: clock skew too great ** EXTERNAL **
On Wed, 18 Oct 2017 21:02:53 +, Howard, Chris wrote: >Is it possible the two boxes are talking to two different servers? Thanks for the idea, but no. The admin_server entry in /etc/krb5.conf is the same on both machines, and the host command returns the same ip address for that machine name on both machines. >-Original Message- >From: owner-scientific-linux-us...@listserv.fnal.gov >[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen >Isard >Sent: Wednesday, October 18, 2017 2:47 PM >To: scientific-linux-us...@listserv.fnal.gov >Subject: clock skew too great ** EXTERNAL ** > >Hello, > >I have two laptops side by side, one running SL6, the other SL7, both up >to date. According to the date command, their times agree to within a >small fraction of a second. > >On both machines, I normally run kinit to get a kerberos ticket in the >same realm. Today, the SL7 machine gets its ticket normally, but the >SL6 one shows an error message "Clock skew too great while getting >initial credentials". Since the clocks of the two machines appear to >agree, I would have expected that either both should produce the error >or neither. From what I have read on the web, the standard tolerance >for clock skew is 5 minutes, and the agreement between the times on the >two machines is well within that. > >Both machines have ntpd running, using the time servers >[0-3].rhel.pool.ntp.org. Powering off the SL6 machine and rebooting >does not restore sanity. The problem just arose today. There have been >no system updates on the SL6 machine since it successfully got its >ticket yesterday. > >Any suggestions for what to try? > >Stephen Isard > > > *** This email is from an EXTERNAL sender *** >Use caution before responding. DO NOT open attachments or click links from >unknown senders or unexpected email. If this email appears to be sent from a >Platte River Power Authority employee or department, verify its authenticity >before acting or responding. Contact the IT Help Desk with any questions.
RE: clock skew too great ** EXTERNAL **
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 -- as a way around, set up ONE unit to act as the local master, and then sync against it, to get 'site coherent' time [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- 1600.000 0.000 0.000 SHM(0) .GPS.0 l- 1600.000 0.000 0.000 SHM(1) .PPS.0 l- 1600.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
RE: clock skew too great ** EXTERNAL **
Is it possible the two boxes are talking to two different servers? -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen Isard Sent: Wednesday, October 18, 2017 2:47 PM To: scientific-linux-us...@listserv.fnal.gov Subject: clock skew too great ** EXTERNAL ** Hello, I have two laptops side by side, one running SL6, the other SL7, both up to date. According to the date command, their times agree to within a small fraction of a second. On both machines, I normally run kinit to get a kerberos ticket in the same realm. Today, the SL7 machine gets its ticket normally, but the SL6 one shows an error message "Clock skew too great while getting initial credentials". Since the clocks of the two machines appear to agree, I would have expected that either both should produce the error or neither. From what I have read on the web, the standard tolerance for clock skew is 5 minutes, and the agreement between the times on the two machines is well within that. Both machines have ntpd running, using the time servers [0-3].rhel.pool.ntp.org. Powering off the SL6 machine and rebooting does not restore sanity. The problem just arose today. There have been no system updates on the SL6 machine since it successfully got its ticket yesterday. Any suggestions for what to try? Stephen Isard *** This email is from an EXTERNAL sender *** Use caution before responding. DO NOT open attachments or click links from unknown senders or unexpected email. If this email appears to be sent from a Platte River Power Authority employee or department, verify its authenticity before acting or responding. Contact the IT Help Desk with any questions.