[nSLUG] Why is ntp so terrible?
George N. White III
gnwiii at gmail.com
Sat Mar 11 11:33:41 AST 2017
On 11 March 2017 at 08:53, D G Teed <donald.teed at gmail.com> wrote:
> NTP, should by default, log as a warning each time it
> fails to reach any upstream source, and it should give
> an error when it goes into the reject/mobilize status.
> That status is as good as having no NTP, so it
> should scream out it is failing. It should not be
> necessary to enter two letter commands in ntpq
> or set up nagios monitors on each host to monitor
> time sync as seen on every system.
NTP suffers from the sort of neglect that allowed openssl
to be released with major security problems.
The "official" NTP (www.ntp.org) is a research project that
provides a "reference implementation". Maybe if it was less
than "good enough" we would have some higher quality
is installed by default on some RHEL 7 versions (e.g., on systems that
might not have constant network access).
Over the years, ntp problems have cost my group considerable lost time
due to things like systems (SGI IRIX64) that start ntpd before the
network is up so every restart requires manual intervention with ntpd, not
to mention trying to convince IT that NTP packets should be allowed on
the internal network.
RSN we will be getting ntimed (http://nwtime.org/projects/ntimed/
a Linux Foundation’s Core Infrastructure Initiative).
Time can be obtained from HTTPS servers using TLS, useful, e.g.,
when you are on a network where IT blocks ntp.
> ntpd should also behave the same way as ntpdate. If ntpdate
> can fail over from IPv6 to IPv4 and set the date, so should ntpd.
> It is misleading that one works and the other silently fails.
> If I could trade off, I'd rather it give us reliable performance
> via status or abort the service on severe error
> than sub-millisecond accuracy.
> By default the logs have more information about the technical
> stuff than about being connected with a source. I never did
> find information about making the log more verbose
> to reveal this problem, only some two letter
> commands to the ntpq CLI.
> openntpd might be something to look at someTIME.
> But the issue goes beyond Linux. Our SAN should have
> alerted there was no connection. Likely ntpd inside.
Marketing depts. know that purchasing depts. use checklists
and don't much care about details of ntp implementations, ssl
versions, etc. Until organizations start paying attention to the
overall operating costs of research quality software users will
be spending more an more time working around the problems.
> On Fri, Mar 10, 2017 at 9:49 PM, <billdavidson at eastlink.ca> wrote:
>> So can we change the subject of this thread to"Why is NTP so great?". I
>> could give a bunch of reasons! Imagine a protocol that can synchronize
>> clocks over a distributed network, with a handful of packets, to
>> sub-millisecond accuracy? It is mind boggling!
Good protocol, but we haven't moved past "research quality" implementations.
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG