====== NTP Server ====== Zunächst wollte ich wie z.B. [[http://blog.debuglevel.de/raspberry-pi-und-dcf77-empfaenger-von-conrad/|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 [[http://www.lindy.de/DCF77-Funkuhr-USB-Version-fuer-PC.htm?websale8=ld0101&pi=20984&ci=4008|Lindy]] oder [[https://www.gude.info/funkuhrsysteme.html|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. [[http://wiki.gude.info/Ntpd_Installation|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 [[http://blog.debuglevel.de/raspberry-pi-und-dcf77-empfaenger-von-conrad/|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.