PDA

Bekijk Volledige Versie : Vraagje mbt NTP



IT-worX
05/01/14, 11:52
Ik heb hier enkele raspberry's liggen die meedoen aan het NTP project. Het grappige is dat deze - ondanks de configuratie die identiek is - er een verschillende tijd op nahouden.

Nu heb ik zelf wat zitten zoeken, en heb al vlug de oorzaak gevonden. Ik had vroeger een VPS met IP 46.28.43.66 en deze werd ook ingezet als NTP bak. Nu bestaat deze VPS nog, maar deze heeft onlangs een ander IP gekregen. Op zich niks erg (hij is reeds verwijderd uit de NTP lijsten ook), ware het niet dat één van de raspi's deze nog gebruikt...en daarom een "slechte" tijd (lees : geen tijd) meekrijgt. Ik had dan ook verwacht dat hij de servers uit de ntp.conf file ging nemen en daar mee verder zou gaan, maar dit blijkt dus niet zo te zijn...

Foute Raspi


root@raspberrypi:/etc# ntpq -pn
remote refid st t when poll reach delay offset jitter
================================================== ============================
46.28.43.66 .INIT. 16 u - 512 0 0.000 0.000 0.000


Correcte Raspi


root@raspberrypi:/etc# ntpq -pn
remote refid st t when poll reach delay offset jitter
================================================== ============================
193.190.230.65 .PPS. 1 u 20 64 377 22.773 -1.197 0.750
*193.190.230.66 .PPS. 1 u 24 64 377 22.541 -0.804 0.391
195.13.23.5 195.13.23.6 2 u 17 64 377 22.377 0.829 0.251
195.13.1.153 195.13.23.6 2 u 21 64 57 22.700 0.583 0.563
193.190.147.153 170.199.127.80 3 u 17 64 377 24.087 1.010 0.411


In de configuratiefile staat telkens de volgende timeservers om mee te syncroniseren:


server ntp1.oma.be
server ntp2.oma.be
server ntp1.belbone.be
server ntp2.belbone.be
server be.pool.ntp.org


Jullie enig idee hoe het komt dat beide raspi's, ook al hebben ze dezelfde configuratie, toch dit probleem geven? Waarom de correcte raspi alle 5 de servers die in /etc/ntp.conf staan gebruikt, en de foute raspi zweert bij een niet-correct IP adres? Waarom gebruikt deze raspi niet de 5 NTP servers in zijn config?

Ikzelf heb reeds van alles gedaan : de configuratie via SCP van de ene naar de andere gekopieerd (om zeker te zijn dat elke bit correct is), de NTP service al tientallen keren herstart, power off/power on, etc. Niks helpt : de ene raspi blijft zijn tijd ophalen bij een niet-bestaande tijdserver en werkt als gevolg dus...niet...

visser
05/01/14, 13:55
Ik heb hier enkele raspberry's liggen die meedoen aan het NTP project. Het grappige is dat deze - ondanks de configuratie die identiek is - er een verschillende tijd op nahouden.

Nu heb ik zelf wat zitten zoeken, en heb al vlug de oorzaak gevonden. Ik had vroeger een VPS met IP 46.28.43.66 en deze werd ook ingezet als NTP bak. Nu bestaat deze VPS nog, maar deze heeft onlangs een ander IP gekregen. Op zich niks erg (hij is reeds verwijderd uit de NTP lijsten ook), ware het niet dat één van de raspi's deze nog gebruikt...en daarom een "slechte" tijd (lees : geen tijd) meekrijgt. Ik had dan ook verwacht dat hij de servers uit de ntp.conf file ging nemen en daar mee verder zou gaan, maar dit blijkt dus niet zo te zijn...

Foute Raspi


Correcte Raspi


In de configuratiefile staat telkens de volgende timeservers om mee te syncroniseren:


Jullie enig idee hoe het komt dat beide raspi's, ook al hebben ze dezelfde configuratie, toch dit probleem geven? Waarom de correcte raspi alle 5 de servers die in /etc/ntp.conf staan gebruikt, en de foute raspi zweert bij een niet-correct IP adres? Waarom gebruikt deze raspi niet de 5 NTP servers in zijn config?

Ikzelf heb reeds van alles gedaan : de configuratie via SCP van de ene naar de andere gekopieerd (om zeker te zijn dat elke bit correct is), de NTP service al tientallen keren herstart, power off/power on, etc. Niks helpt : de ene raspi blijft zijn tijd ophalen bij een niet-bestaande tijdserver en werkt als gevolg dus...niet...

Ik denk aan een DNS issue.
Staat op de foute raspberry misschien een ntp server hard in /etc/hosts , bijvoorbeeld van een test ?
En misschien geen bereikbare resolver in /etc/resolv.conf ?

Kijk dus of de ntp server namen op de foute raspberry wel te resolven zijn. (dig , evt ping ).

IT-worX
05/01/14, 14:01
Bedankt om mee te denken Visser, dit had ik ook al bedacht, maar dit lijkt me correct. In /etc/hosts zie ik niks speciaals, in /etc/resolve.conf zie ik enkel de DNS servers van google zelf. Als ik bvb een ping doe naar om het even welk domein, dan krijg ik daar netjes het correcte IP van.



/etc/hosts


27.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

#127.0.1.1 raspberrypi


/etc/resolve.conf


nameserver 8.8.8.8
nameserver 8.8.4.4


root@raspberrypi:~# ping twitter.com
PING twitter.com (199.16.156.198) 56(84) bytes of data.
64 bytes from 199.16.156.198: icmp_req=1 ttl=47 time=123 ms
64 bytes from 199.16.156.198: icmp_req=2 ttl=47 time=125 ms
64 bytes from 199.16.156.198: icmp_req=3 ttl=47 time=123 ms
^C
--- twitter.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 123.535/124.320/125.544/0.876 ms



root@raspberrypi:~# ping facebook.com
PING facebook.com (173.252.110.27) 56(84) bytes of data.
64 bytes from edge-star-shv-13-frc1.facebook.com (173.252.110.27): icmp_req=1 ttl=83 time=119 ms
64 bytes from edge-star-shv-13-frc1.facebook.com (173.252.110.27): icmp_req=2 ttl=83 time=121 ms
64 bytes from edge-star-shv-13-frc1.facebook.com (173.252.110.27): icmp_req=3 ttl=83 time=118 ms
^C
--- facebook.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 118.114/119.444/121.059/1.282 ms



root@raspberrypi:~# ping google.com
PING google.com (173.194.113.104) 56(84) bytes of data.
64 bytes from fra02s22-in-f8.1e100.net (173.194.113.104): icmp_req=1 ttl=50 time=67.4 ms
64 bytes from fra02s22-in-f8.1e100.net (173.194.113.104): icmp_req=3 ttl=50 time=67.4 ms
64 bytes from fra02s22-in-f8.1e100.net (173.194.113.104): icmp_req=4 ttl=50 time=68.0 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3006ms
rtt min/avg/max/mdev = 67.426/67.654/68.061/0.358 ms



root@raspberrypi:~# ping webhostingtalk.nl
PING webhostingtalk.nl (109.72.90.229) 56(84) bytes of data.
64 bytes from web01.wht.pcxpro.nl (109.72.90.229): icmp_req=1 ttl=57 time=23.6 ms
64 bytes from web01.wht.pcxpro.nl (109.72.90.229): icmp_req=2 ttl=57 time=22.9 ms
64 bytes from web01.wht.pcxpro.nl (109.72.90.229): icmp_req=3 ttl=57 time=23.2 ms
^C
--- webhostingtalk.nl ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 22.908/23.243/23.601/0.309 ms

systemdeveloper
05/01/14, 14:09
Het je op de foute toevallig nog ergens een 2de ntp config staan die gewoon eerder gevonden wordt?

Grep gewoon eens op het ip van de foute ntp server in je /etc, /usr/local/etc en shared directories.

visser
05/01/14, 14:26
Het je op de foute toevallig nog ergens een 2de ntp config staan die gewoon eerder gevonden wordt?

Grep gewoon eens op het ip van de foute ntp server in je /etc, /usr/local/etc en shared directories.

Ook een goed idee inderdaad.

Ik weet niet hoe compleet de installatie op een raspberry is, maar indien beschikbaar zou ik met 'strace' kijken welke files bij startup allemaal gelezen worden en welke lookups gedaan worden.
Evt ook met tcpdump even kijken naar dns verkeer bij (her)start van ntp , dan zou je een hostname die resolved naar het foute ip langs moeten zien komen, en weet je naar welke hostnaam je moet zoeken in configs.
Of niet, of niets, en dan weet je dat het ip adres zelf ergens ingesteld moet staan.

IT-worX
05/01/14, 14:47
Ik zie nergens enig spoor van een tweede ntp config.

Maar de tip van Visser gaf in elk geval al een hint : in een eerste SSH sessie heb ik tcpdump port 53 open staan, in de andere doe ik een simpele ping opdracht dan zie ik in de eerste ssh sessie het volgende voorbij komen :



root@raspberrypi:~# tcpdump port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:38:50.974047 IP 79.132.237.1.static.edpnet.net.53642 > google-public-dns-a.google.com.domain: 37347+ A? google.be. (27)
14:38:50.980318 IP 79.132.237.1.static.edpnet.net.60895 > google-public-dns-a.google.com.domain: 27340+ PTR? 1.237.132.79.in-addr.arpa. (43)
14:38:51.000333 IP google-public-dns-a.google.com.domain > 79.132.237.1.static.edpnet.net.53642: 37347 3/0/0 A 173.194.113.119, A 173.194.113.127, A 173.194.113.120 (75)
14:38:51.006296 IP google-public-dns-a.google.com.domain > 79.132.237.1.static.edpnet.net.60895: 27340 1/0/0 PTR 79.132.237.1.static.edpnet.net. (87)
14:38:51.007488 IP 79.132.237.1.static.edpnet.net.35993 > google-public-dns-a.google.com.domain: 60227+ PTR? 8.8.8.8.in-addr.arpa. (38)
14:38:51.033869 IP google-public-dns-a.google.com.domain > 79.132.237.1.static.edpnet.net.35993: 60227 1/0/0 PTR google-public-dns-a.google.com. (82)
14:38:52.076167 IP 79.132.237.1.static.edpnet.net.54218 > google-public-dns-a.google.com.domain: 12328+ PTR? 119.113.194.173.in-addr.arpa. (46)
14:38:52.102317 IP google-public-dns-a.google.com.domain > 79.132.237.1.static.edpnet.net.54218: 12328 1/0/0 PTR fra02s22-in-f23.1e100.net. (85)


Als ik de NTP service probeer te herstarten (service ntp restart) dan zie ik daar niks bij komen. Dus inderdaad, iets moet verwijzen naar dat IP en dat moet hardcoded zijn. Dus heb ik nu op de 2 mappen die systemdeveloper aanraad even "grep 46.28.43.66" gedaan. Duurt precies wel een tijdje, maar ik hou je op de hoogte!

visser
05/01/14, 15:13
Ik zie nergens enig spoor van een tweede ntp config.

Maar de tip van Visser gaf in elk geval al een hint : in een eerste SSH sessie heb ik tcpdump port 53 open staan, in de andere doe ik een simpele ping opdracht dan zie ik in de eerste ssh sessie het volgende voorbij komen :



Als ik de NTP service probeer te herstarten (service ntp restart) dan zie ik daar niks bij komen. Dus inderdaad, iets moet verwijzen naar dat IP en dat moet hardcoded zijn. Dus heb ik nu op de 2 mappen die systemdeveloper aanraad even "grep 46.28.43.66" gedaan. Duurt precies wel een tijdje, maar ik hou je op de hoogte!

Er staat geen strace op, begrijp ik ?
Jammer, want voor vragen als 'welke (config) file wordt nu geopend bij starten' is dat wel makkelijk.
Lees ook even het hele init script door (en de verwante files die met '. filename' erin gesourced worden , env variabelen e.d. ).
Een config file of config directory die als argument meegegeven wordt moet daar in staan.

Als je wel 'strings' hebt , kun je met 'strings <ntpd binary> ' alles wat lijkt op ascii zien .
Daarmee zie je welke files/directories erin gecompileerd zijn als default plekken voor configuratie files.
Normaal is dat /etc/ntp.conf (of /etc/ntp/ ) , maar hier zoek je mogelijk toch naar een andere of extra plek die gelezen wordt.

systemdeveloper
05/01/14, 15:34
Vergeet niet om in /etc/default/ en /etc/sysconfig/ntpd te kijken en naar pool.ntp te zoeken.

visser
05/01/14, 15:38
Ik heb hier enkele raspberry's liggen die meedoen aan het NTP project. Het grappige is dat deze - ondanks de configuratie die identiek is - er een verschillende tijd op nahouden.

[knip]

Oja, zie ik nu pas :

Dit is natuurlijk geen onderwerp voor de lounge, maar gewoon techniek -> unix/linux/bsd .

systemdeveloper
05/01/14, 15:50
Oja, zie ik nu pas :

Dit is natuurlijk geen onderwerp voor de lounge, maar gewoon techniek -> unix/linux/bsd .

Ach, het is geen crime om ook in je loungetijd op zondag te filosoferen over strace en zo, hoor... Hooguit een beetje nerdy ;)

IT-worX
05/01/14, 18:27
Had inderdaad beter onder techniek gestaan, dus modjes die hun willen amuseren : doe gerust!

Juist even verder gekeken : de grep heeft er niks uitgehaald met het IP 46.28.43.66. In de map /etc/default zie ik 2 bestanden staan die te maken hebben met NTP : "ntp" en "ntpdate".

/etc/default/ntp

NTPD_OPTS='-g'

/etc/default/ntpdate


# The settings in this file are used by the program ntpdate-debian, but not
# by the upstream program ntpdate.

# Set to "yes" to take the server list from /etc/ntp.conf, from package ntp,
# so you only have to keep it in one place.
NTPDATE_USE_NTP_CONF=yes

# List of NTP servers to use (Separate multiple servers with spaces.)
# Not used if NTPDATE_USE_NTP_CONF is yes.
NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org"

# Additional options to pass to ntpdate
NTPOPTIONS=""



Strace staat er standaard niet op, maar heb ik kunnen installeren middels apt. Ga juist nog even moeten googlen hoe ik het juist moet gebruiken met die regex :)

visser
05/01/14, 21:43
Had inderdaad beter onder techniek gestaan, dus modjes die hun willen amuseren : doe gerust!

Juist even verder gekeken : de grep heeft er niks uitgehaald met het IP 46.28.43.66. In de map /etc/default zie ik 2 bestanden staan die te maken hebben met NTP : "ntp" en "ntpdate".

/etc/default/ntp


/etc/default/ntpdate


Strace staat er standaard niet op, maar heb ik kunnen installeren middels apt. Ga juist nog even moeten googlen hoe ik het juist moet gebruiken met die regex :)

Ik doe gewoonlijk
strace -f /pad/programma <argumenten van programma>
of strace -f -p <process id van draaiend proces>

De -f zegt 'follow', dus ook geforkte children stracen .
Eventueel de output meteen naar een file dumpen .

Hier wil je eigenlijk alleen de startup zien, puur om te kijken welke files geopend worden, dus starten onder strace en na een paar seconden afbreken .
Je kunt veel meer argumenten meegeven, welke libs en calls wel en niet te tracen, maar voor de vraag naar 'welke config files' (of soms : waar probeert hij een pid file of lock file te schrijven waar het niet mag, als oorzaak van het niet willen starten ) is gewoon strace -f programma <normale argumenten>

Je moet dus nog wel het init script goed lezen om te zien welke argumenten meegegeven worden .

Als ik even kijk zie ik dat een normale debian in /etc/init.d/ntp ook nog doet :

if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
fi

Dat is ook nog een plek/file om te bekijken.
(naast idd :
if [ -r /etc/default/ntp ]; then
. /etc/default/ntp
fi
)

Ik schrijf 'normale debian' omdat ik niet weet wat de raspberry draait, dat het iets debian is weet ik sinds je schreef 'middels apt' en het is natuurlijk een buitenbeentje, misschien is het een customized debian versie.

Maar goed, tools als strace, strings en tcpdump leren gebruiken om dit soort problemen te kunnen debuggen is algemeen nuttig . (give a man a fish etc )

visser
08/01/14, 13:18
[..]

Strace staat er standaard niet op, maar heb ik kunnen installeren middels apt. Ga juist nog even moeten googlen hoe ik het juist moet gebruiken met die regex :)

Ben wel benieuwd of het nu opgelost is, en zo ja, wat het was ...

IT-worX
09/01/14, 15:44
Helaas is het nog niet opgelost, maar dat ligt aan mezelf (werkweek...dus amper tot geen tijd helaas)

IT-worX
10/01/14, 15:01
Gisteren en vandaag nog eens bekeken, maar helaas zonder succes.

Iemand die tegen betaling er even naar wilt kijken?

visser
11/01/14, 18:39
Helaas is het nog niet opgelost, maar dat ligt aan mezelf (werkweek...dus amper tot geen tijd helaas)

Voor meelezers en geïnteresseerden :
Ik heb even gekeken (om niet ), en het probleem was het volgende :

TS heeft de raspberry's eerst in een huisnetwerk met DHCP aangesloten gehad, en daarbij wordt een ntp.conf file gemaakt met de naam /var/lib/ntp/ntp.conf.dhcp . Dat is de file uit /etc/ntp.conf , met de servers vervangen door de ntp server die met dhcp meegegeven was.

Bij het opstarten van ntp wordt die file gebruikt als die bestaat (ook als inmiddels geen dhcp als netwerk configuratie gebruikt wordt).

Wellicht een debian bugje dat die file niet gewist wordt, hetzij bij afsluiten/vrijgeven van dhcp lease, hetzij bij omschakelen naar een fixed ip configuratie. Of in elk geval niet in alle scenario's gewist wordt .
(bekend probleem , als je het eenmaal gevonden hebt en er gericht naar zoekt :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569775
http://us.generation-nt.com/answer/bug-600661-ntp-uses-var-lib-ntp-ntp-conf-dhcp-regardless-help-207622511.html
http://ntpi.openchaos.org/pps_pi/
)

Ik had nog niet eerder op een raspberry gekeken, maar gelukkig voelde het als een heel 'normale' linux; Ik heb wel eens op heel kleine linux-gebaseerde devices gewerkt waar van alles ontbreekt of anders in elkaar zit, alleen busybox maar bijna geen normale commando's e.d. maar dat viel dus erg mee.
Anyway, IT-worX' raspberry's doen ntp nu als verwacht.

frankske
13/01/14, 17:45
Geef eens output van ntpq -c peers op die waar het fout is?

IT-worX
13/01/14, 17:47
Dag Frankske,

Inmiddels werken ze allen zoals gezegd terug (zie hierboven). Ik gebruik alleen ntp1.oma.be, ntp2.oma.be, ntp1.belbone.be en ntp2.belbone.be om mee te syncen.
Ik reageer vanavond verder op dit bericht, en op Visser zijn bericht.