NTP Server
Zunächst wollte ich wie z.B. hier beschrieben einen NTP Server mit einem Raspberry PI und einem Bausatz bauen. Mein ursprünglicher Ansatz war die Antenne in einem Gehäuse auf dem Raspi zu platzieren. Das hat sich für mich aber als untauglich erwiesen, da der Raspi selbst den Empfang zu stören scheint. Längere Kabel wollte ich mir nicht antun. Deshalb habe ich auf einen USB-DCF77-Empfänger (gibt es z.B. von Lindy oder Gude) zurückgegriffen. Der hat ein langes Kabel und funktioniert problemlos.
Das wichtigste ist Geduld. Das System braucht nach dem Aufbau eine Weile bis es sich einpendelt. Mindesten die erste Minute schlagen die Tests des DCF77-Empfängers fehl. Hier meine ntp.conf:
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ logfile /var/log/ntpd.log logconfig =all driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 server ptbtime1.ptb.de noselect server ptbtime2.ptb.de noselect server ptbtime3.ptb.de noselect server 127.127.8.0 mode 19 prefer fudge 127.127.8.0 time1 0.4250 server 127.127.1.0 fudge 127.127.1.0 stratum 10
Der Empfänger wird durch die Zeile:
server 127.127.8.0 mode 19 prefer
angesprochen. Ausschalggebend ist hier „mode 19“. Der NTP-Daemon sucht dazu den Empfänger unter
/dev/refclock-0
0 korrespondiert mit der letzen Null in „127.127.8.0“. Der einfachkeithalber mache ich einen passenden Symlink beim Systemstart:
ln -s /dev/ttyUSB0 /dev/refclock-0
„ttyUSB0“ muss natürlich das passende Device sein, welches sich per „lsusb“ herausfinden lässt. Alternativ kann man UDEV-Regeln schreiben wie z.B. hier beschreiben.
Ggf. muss AppAmor deaktiviert werden:
ln -s /etc/apparmor.d/usr.sbin.ntpd /etc/apparmor.d/disable/ apparmor_parser -R /etc/apparmor.d/usr.sbin.ntpd
Die „ptbtime“-Servereinträge braucht man um die „fudge time“ berechnen zu können. Hier meine abgewandelte Form des Scripts von hier zur Berechnung der „fudge time“:
#!/bin/bash
FT=$(ntpq -c cv | grep fudgetime1 | cut -d" " -f 5 | cut -d "=" -f 2 | cut -d "," -f 1)
OS=$(cat /var/log/ntpstats/peerstats | grep -v 127.127.8 | cut -d" " -f 5 | awk '{a+=$1} END{print a/NR}')
X=$(echo "scale=4;($FT+$OS)/1000" | bc | sed -e 's/^-\./-0./' -e 's/^\./0./')
echo "ntp.conf value: " $(grep "fudge 127.127.8.0 time1" /etc/ntp.conf)
echo "calculated value: fudge 127.127.8.0 time1 "$X
Den Server einfach mal zwei Tage laufen lassen und dann den Berechneten Wert in die ntp.conf eintragen. Für die Überwachung des Systems in der Testphase nutze ich:
watch -n 10 "ntpq -c clocklist; echo; echo; ntpq -p; echo; echo; tail /var/log/ntpd.log; echo; echo; calcfudge"
Was bei mir im Moment folgenden Output liefert:
associd=0 status=0020 , 2 events, clk_unspec,
device="RAW DCF77 CODE (Expert mouseCLOCK USB v2.0)",
timecode="--##----##-###----M-S1---1-4P----1-P1-4-1-1--1-------81---P",
poll=30, noreply=0, badformat=0, baddata=1, fudgetime1=425.000,
stratum=0, refid=DCFa, flags=0,
refclock_time="de06f810.00000000 Mon, Jan 15 2018 9:51:12.000",
refclock_status="TIME CODE; (LEAP INDICATION; ANTENNA)",
refclock_format="RAW DCF77 Timecode",
refclock_states="*NOMINAL: 00:31:00 (96.87%); ILLEGAL DATE: 00:01:00 (3.12%); running time: 00:32:00"
remote refid st t when poll reach delay offset jitter
==============================================================================
ptbtime1.ptb.de .PTB. 1 u 19 64 377 28.840 23.168 1.147
ptbtime2.ptb.de .PTB. 1 u 17 64 337 28.913 23.124 1.495
ptbtime3.ptb.de .PTB. 1 u 27 64 377 28.704 23.151 5.603
*GENERIC(0) .DCFa. 0 l 60 64 377 0.000 0.314 0.422
LOCAL(0) .LOCL. 10 l 1852 64 0 0.000 0.000 0.000
14 Jan 15:41:00 ntpd[3117]: PARSE receiver #0: 2 messages where suppressed, error condition class persists for 00:01:20
14 Jan 15:41:00 ntpd[3117]: PARSE receiver #0: FAILED TIMECODE: "-#-##--#-#-###-----Ls12-----P--48-2p1--8-2-2412-------12--p" (check receiver configuration /
wiring)
15 Jan 09:19:09 ntpd[3117]: ntpd exiting on signal 15
15 Jan 09:19:13 ntpd[25518]: PARSE receiver #0: new phase adjustment 0.425000 s
15 Jan 09:19:13 ntpd[25518]: 0.0.0.0 c016 06 restart
15 Jan 09:19:13 ntpd[25518]: 0.0.0.0 c012 02 freq_set kernel -37.243 PPM
15 Jan 09:19:17 ntpd[25518]: 0.0.0.0 c515 05 clock_sync
15 Jan 09:20:00 ntpd[25518]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 46 bits
15 Jan 09:20:00 ntpd[25518]: PARSE receiver #0: interval for following error message class is at least 00:01:00
15 Jan 09:20:00 ntpd[25518]: PARSE receiver #0: FAILED TIMECODE: "##---#-#-----#-R----S-24-1-4p1--8--p----12---" (check receiver configuration / wiring)
ntp.conf value: fudge 127.127.8.0 time1 0.4250
calculated value: fudge 127.127.8.0 time1 0.4250
Von den „FAILED TIMECODE“-Einträgen im Log nicht verrückt machen lassen. Das ist normal.