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.