[FreeBSD] NTPD wil niet syncen met publieke tijdservers

[El Cid]

Hallo allemaal,

Al een tijdje probeer ik accurate tijd op mijn FreeBSD-5.3 server te krijgen. Dit wil ik dus doen met de ingebouwde NTP-daemon en de instructies in het FreeBSD handboek.

http://www.freebsd.org/do...handbook/network-ntp.html

Om onverklaarbare redenen krijg ik het maar niet voor elkaar. Mischien weten jullie raad.

Dit staat oa in mijn rc.conf:

code:

ntpdate_enable="YES"
ntpd_enable="YES"

En dit is mijn ntp.conf:

code:

# List of time servers we sync to
server nl.pool.ntp.org
server europe.pool.ntp.org
server north-america.pool.ntp.org

# Location of the driftfile
driftfile /var/db/ntp.drift

# Deny outside access to ntpd on this machine
restrict default ignore

Volgens mij heb ik alles goed gedaan en geen fouten gemaakt. Maar zoals ik al zei, de tijd loopt nog steeds niet correct op die server. De NTP-daemon start wel netjes op bij het booten. Dus hij loopt wel, maar doet niks.

[RagaBaSH]

als ik de documentatie doorlees die in je link stond, dan lijkt het me dat je klok niet in een keer verspringt als je die ntpd draait, maar dat hij dmv die driftfile probeert je klok langzamerhand meer "in-sync" te laten lopen.
je kan nog altijd met de hand je tijd goed zetten, dan zie je meteen een resultaat (gewoon ntpdate <server>). je zou kunnen proberen een van je ntpservers een "prefer" mee te geven, dan pakt ie eigenlijk automatisch die server om te syncen.

Wat ik me afvraag is waar je op baseert dat je FBSD niet de juiste tijd aangeeft? controleer je dat dmv een andere zichtbaar gesyncte klok? aan de hand van je horloge of ander natte vingerwerk? etc..

[El Cid]

Ik controleer het meestal via teletekst, of via dit linkje http://greenwichmeantime.com.

Als mijn server opstart loopt de tijd in het begin wel een tijdje goed, Dat komt omdat ie dan eerst synct via ntpdate, en alles in een ruk goed zet. Maar dat is alleen bij het opstarten. Daarna moet eigenlijk de NTP-daemon het overnemen, en continu kleine correcties uitvoeren. Dit gebeurt dus niet, want naarmate de server langer draait zie ik de tijd steeds verder afdrijven.

[BoAC]

Heb je ntpd ook al een keer in 'debug' mode (-d) gedraait?
Hier kun je veel uit halen bijvoorbeeld wanneer de tijd wordt 'gesynced'

[El Cid]

Nope, zal me d'r vanavond eens in verdiepen.

*edit*

Debug-mode krijg ik niet snel werkende. Blijkt namelijk dat je NTPD dan ook met debug support moet compileren. En dat is op het moment niet het geval.

[ Voor 67% gewijzigd door El Cid op 27-01-2006 16:47 ]

[El Cid]

Heb net ontdekt dat de eerste twee publieke pool-servers in mijn lijst helemaal geen response geven.

[ Voor 3% gewijzigd door El Cid op 27-01-2006 15:47 ]

[kenneth]

Wat is het resultaat als je het handmatig doet?

ntpdate ntp.xs4all.nl

[Verwijderd]

De "host" nl.pool.ntp.org geeft wel response, alleen niet op ICMP requests (lees: ping).

De correctie die ntp kan uitvoeren is niet oneindig. Draai daarom eerst een 'ntpdate nl.pool.ntp.org' om de klok gelijk te zetten en start daarna pas de ntp-daemon (ntpd).
Je config ziet er wel goed uit. Je zou nog een paar extra 'nl.pool.ntp.org'-servers ter referentie op kunnen nemen, maar dat is een detail. Geef de daemon een poosje de tijd en controleer na +/- 5 min. de stratum met het commando 'ntpdc -c sysinfo localhost', deze moet/zal een waarde 2 of 3 zijn.

[ Voor 5% gewijzigd door Verwijderd op 27-01-2006 16:32 ]

[El Cid]

Verwijderd schreef op vrijdag 27 januari 2006 @ 16:32:
De "host" nl.pool.ntp.org geeft wel response, alleen niet op ICMP requests (lees: ping).

Nu lijkt alles weer te werken. Maar een uurtje geleden kreeg ik een melding dat er op nl.pool.ntp.org geen NTP-service draaide toen ik het handmatig via ntpdate probeerde. Mischien had ik net een brakke server uit de pool ofzo.

Als ik dat commando van jou gebruik, dan zie ik een stratum van 16. De tijd loopt ook al weer ruim een seconde achter.

code:

system peer:          0.0.0.0
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -20
root distance:        0.00000 s
root dispersion:      0.03831 s
reference ID:         [73.78.73.84]
reference time:       00000000.00000000  Thu, Feb  7 2036  7:28:16.000
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.003998 s
authdelay:            0.000000 s

[El Cid]

kenneth schreef op vrijdag 27 januari 2006 @ 16:23:
Wat is het resultaat als je het handmatig doet?

ntpdate ntp.xs4all.nl

Werkt perfect!

[Verwijderd]

El Cid schreef op vrijdag 27 januari 2006 @ 16:41:
[...]
Als ik dat commando van jou gebruik, dan zie ik een stratum van 16. De tijd loopt ook al weer ruim een seconde achter.

Nog even wat langer wachten (niet herstarten of ntpdate'en) en je tijd zal gelijk gaan lopen nadat hij de tijd heeft gechecked met andere machines uit je server lijstje.

[El Cid]

Verwijderd schreef op vrijdag 27 januari 2006 @ 17:02:
[...]


Nog even wat langer wachten (niet herstarten of ntpdate'en) en je tijd zal gelijk gaan lopen nadat hij de tijd heeft gechecked met andere machines uit je server lijstje.

Ik hoop dat je gelijk hebt, maar ik vrees van niet. Er is namelijk niks fundamenteel veranderd aan mijn configuratie sinds mijn openings post. Dus ik zie niet in waarom het nu opeens wel zou werken, en de afgelopen weken niet.

[downtime]

Weet je zeker dat die NTP servers wel beschikbaar zijn voor jou? Sommige servers mogen niet door end-users benaderd worden en worden alleen op verzoek open gezet.

[BoAC]

El Cid schreef op vrijdag 27 januari 2006 @ 15:03:
Nope, zal me d'r vanavond eens in verdiepen.

*edit*

Debug-mode krijg ik niet snel werkende. Blijkt namelijk dat je NTPD dan ook met debug support moet compileren. En dat is op het moment niet het geval.

code:

man ntpd

code:

       -d     Specify debugging mode. This option may occur  more  than  once,
              with each occurrence indicating greater detail of display.

       -D level
              Specify debugging level directly.

De prompt return'd dan niet maar de output van NTPD wordt dan weergegeven.
Hier kun je dan zien of het 'syncen' wel lukt

[El Cid]

/downtime/ schreef op vrijdag 27 januari 2006 @ 17:30:
Weet je zeker dat die NTP servers wel beschikbaar zijn voor jou? Sommige servers mogen niet door end-users benaderd worden en worden alleen op verzoek open gezet.

Volgens mij zijn die publieke pool-servers daar nou net voor bedoeld, maar ik kan me vergissen.

[Coen Rosdorff]

Met ntpq / ntpdc kan je kijken wat je daemon aan het uitspoken is:

code:

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        LOCAL(0)        10 l   19   64  377    0.000    0.000   0.015
 192.168.0.255   0.0.0.0         16 -    -   64    0    0.000    0.000 4000.00
-obelix.xs4all.n ntp1.nl.uu.net   2 u  113 1024  377    9.076   -1.967   0.786
+auth1.xs4all.nl ntp0-rz.rrze.un  2 u  630 1024  377   10.783    0.026   0.164
*auth2.xs4all.nl ntp1.nl.uu.net   2 u  199 1024  377   10.347   -0.282   0.148
+auth3.xs4all.nl ntp0-rz.rrze.un  2 u  823 1024  377   10.668   -0.712   0.101
-auth4.xs4all.nl ntp1.nl.uu.net   2 u  231 1024  377   10.562    2.778   0.217
ntpq> q
# ntpdc 
ntpdc> pe
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=LOCAL(0)        127.0.0.1       10   64  377 0.00000  0.000000 0.00095
=auth1.xs4all.nl [ip-adres]       2 1024  377 0.01077  0.000026 0.01482
=auth3.xs4all.nl [ip-adres]       2 1024  377 0.01025 -0.000961 0.01483
=obelix.xs4all.n [ip-adres]       2 1024  377 0.00906 -0.001967 0.01486
*auth2.xs4all.nl [ip-adres]       2 1024  377 0.01035 -0.000282 0.01485
=auth4.xs4all.nl [ip-adres]       2 1024  377 0.01056  0.002778 0.01485
^192.168.0.255   5.0.0.0         16   64    0 0.00000  0.000000 0.00000

Uiteraard is er ook altijd wel iets in /var/log/.... te vinden.

[El Cid]

Ok, ben nu een dag verder, en nog niks opgeschoten. De tijd op mijn server wijkt al weer enkele seconden af van de klokken met wie het zou moeten synchroniseren. Dat commando van little_soundman had ik toevallig gisteren al ontdekt. Nu blijkt dus dat er bij mij inderdaad iets niet goed zit.

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 213.84.187.156  .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 213.222.11.211  .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 217.114.97.97   .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 81.171.100.40   .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 84.16.227.218   .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 66.93.39.87     .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 213.222.11.218  .INIT.          16 u    - 1024    0    0.000    0.000 4000.00

Volgens onderstaande site zou er dit te zien moeten zijn:

The IP addresses will be different, because you've been assigned random timeservers. The essential thing is that one of the lines starts with an asterisk (*), this means your computer gets the time from the internet - you'll never have to worry about it again!

Bron: http://www.pool.ntp.org/use.html

Zoals uit mijn output blijkt is er dus geen sterretje te zien. Ook zien een aantal van de andere waardes er niet goed uit naar mijn idee. Maar ik ben dus geen expert op dit gebied. Ik heb nu dus totaal geen idee wat er aan de hand is.

[weijl]

hm, dit staat er in mijn ntp.conf (draait wel onder debian, maar denk niet dat die config files erg veel verschillen.)

[Verwijderd]

Misschien is dit een nutteloze reply, maar let wel op dat het behoorlijk lang kan duren voordat ntpd een server uitkiest om mee te synchroniseren. Daarna zie je pas een sterretje ziet bij een van de servers en wordt de stratum-informatie geupdate. Die ntpq-output ziet er goed uit, maar hij heeft nog niet bepaald welke server het beste is om mee te synchroniseren. Dus laat 'm gewoon 's een paar uur proberen zonder te rebooten of ntpd te herstarten, dan komt 't volgens mij vanzelf goed. En check je ntp-logs in /var/log (of waar dat ook staat op BSD :-)

Je moet er rekening mee houden dat ntp niet is ontwikkeld zodat eindgebruikers overal in hun taakbalk dezelfde tijd op de seconde nauwkeurig te zien krijgen. Veel mensen denken dat en krijgen daarom verkeerde verwachtingen van ntp. Het is bedoeld om een enkele tijd binnen je netwerk te krijgen voor gedistribueerde toepassingen als gedistribueerde databases waarbij je op de milli- of microseconde nauwkeurig wilt weten wanneer bijv. een insert- of updatestatement gedaan wordt. Dat is ook de reden dat de klok heel voorzichtig wordt bijgestuurd en niet keihard gelijkgezet wordt als hij een seconde achterloopt.

[ Voor 53% gewijzigd door Verwijderd op 28-01-2006 15:55 ]

[El Cid]

Ik heb uit ellende maar openntpd uit ports gehaald. Kijken of die het wel doet.

[El Cid]

El Cid schreef op zaterdag 28 januari 2006 @ 17:23:
Ik heb uit ellende maar openntpd uit ports gehaald. Kijken of die het wel doet.

Uiteindelijk heb ik het probleem toch opgelost met de ingebouwde FreeBSD NTP-daemon.

Het bleek om deze regel in het configuratiebestand te gaan:

code:

restrict default ignore

Wat blijkt, niet alleen kunnen clients zo niet synchroniseren met mijn server, ook kan mijn server zelf niet syncen met de publieke tijdservers.

Wel vreemd dat het de UNIX goeroes hier niet is opgevallen.