Thanks. I updated the ntp.conf file, then rebooted, then looked at the ntp.log file. The only thing I saw that stuck out was:Short answer: Use this instead
Long answer:Code:# logfile /opt/var/spool/ntp/ntp.log driftfile /opt/var/spool/ntp/ntp.drift leapfile /opt/var/spool/ntp/leap-seconds.list # https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list # restrict default limited kod nomodify notrap nopeer noquery # restrictive default IPv4 restrict -6 default limited kod nomodify notrap nopeer noquery # restrictive default IPv6 restrict source nomodify notrap noquery # required for pool directive if using restrictive default permissions restrict 127.0.0.1 # permissive localhost IPv4 restrict -6 ::1 # permissive localhost IPv6 # interface ignore wildcard interface listen br0 # disable auth # pool pool.ntp.org iburst #
- The ntp.conf that ntpdMerlin provides if fine. This is a slightly different alternative.
- Using "pool" instead of "server" only requires the slightly relaxed permissions of the "restrict source" line above
- The iburst argument is generally recommend. It allows for quicker time synchronization at startup.
- Using pool instead of server enables extra algorithms in NTPD which are considered to be good but I do not know the details
- The DNS for pool.ntp.org is configured to return geographically close NTP servers. However, I have noticed that I sometimes get servers as far as 120 msec of delay away.
- The default restrict permissions are intended to come into play if you provide NTP to the public, but will be in effect on your LAN as well
- The localhost restrict permissions enable you to run all of the NTP commands without restriction
- You may notice that, since I have a "server" at 192.168.50.200, it is on my LAN. I have another computer with an NTP daemon which has a GPS connected to it in order to provide better time. This ntp.conf line allows my router to take advantage of this as an NTP client. You would not include this line in your ntp.conf
- The interface commands determine which networks you can provide NTP time to. The first line sets a default to not provide NTP time. The second line enables your router to provide NTP time on the LAN interface. Do you need "interface listen br0" for the router to have NTP time? No, it is only necessary if you want to provide NTP time to the computers on your LAN.
- You do not need the stats. The router GUI graph data is collected another way. But if you are troubleshooting, it is nice for them to be available even if looking back and forth at the refererence documentation to decode is frustrating.
- In order to validate NTP daemon startup, you need to first look at /tmp/syslog.log and then /opt/var/spool/ntp/ntp.log because it switches over
- The leapfile can be considered esoteric but when they do happen it is nice to avoid the clock being instantaneously wrong by a second. You can wget the file at the URL in the comment.
- Do not use minpoll or maxpoll below 6 (64 seconds) unless the target is your computer. If not your computer, do not set them at all.
20 Mar 16:28:40 ntpd[1705]: leapsecond file ('/opt/var/spool/ntp/leap-seconds.list'): stat failed: No such file or directory
Will that file get auto-created when there are leap-seconds?
Also now that I'm using the pool, it looks there are a number of servers that will be used. I am not currently causing any of them to use the WAN in my OpenVPN config, so I presume all of these ntp transactions are through the VPN? Is that an issue for the accuracy of any of the data? Or, is there a way to configure the VPN client to cause all pool.ntp.org requests to use the WAN? Or, maybe that is a question better asked of the OpenVPN guys?
I just recalled that all requests from my router (192.168.2.1) are going to the WAN, so maybe the VPN issue is a non-issue?
Thanks for your help.