Before this experience, I was under the impression that the reference
implementation of NTP by the NTP
Project was the bees knees. I have since come to have a very
different opinion of the program. It all started with the need to
setup a pair of NTP servers.
First off I needed to get the correct time on the servers. After
changing the default server entries from the global pool.ntp.org entries
to the country specific us.pool.ntp.org and adding entries to the
step-tickers file (this enables the init script for ntpd to specifically
set the time from the listed servers upon daemon startup. Why exactly
isn't this the default?) I had the correct time on my servers. This
step was easy enough.
Next, I had to get the server to accept requests from other machines
on the network. Redhat kindly commented up ntp.conf. The
relevant section is;
# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service. Do not permit those systems to modify the
# configuration of this service. Also, do not use those
# systems as peers for synchronization.
# restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
Wait a minute, to allow a network to request time from the server, I
start a line with restrict? You have got to be kidding me.
Anyway, I make the change to make it applicable to the network, and from
another machine, queried the server for the time. The request was not
met with an answer that pleased me though.
[root@server ~]# ntpdate -q 192.168.0.1
server 192.168.0.1, stratum 0, offset 0.000000, delay 0.00000
2 Sep 22:27:26 ntpdate[2674]: no server suitable for synchronization
found
Which leads to perhaps the biggest problem with the project: some of
the worst documentation I have encountered. You can't blame them for
lack of documentation.
They have lots of documentation. Lots and
lots of
documentation. That is really the problem. I can assure the authors of
all that written material that very very few people care about the
gritty details of how NTP works. People just want a simple,
straight-forward, and reliable way to get sub second accurate time on
all of their machines.
I spent nearly four hours reading nearly all of that documentation.
I not only found the answer to my problem; ntpd won't respond to
requests for time until it is confident that it has the accurate time,
which takes a few minutes after each restart of the daemon. In the end,
I found that someone had already gone through the pain of working out
the correct config for ntp.conf and Redhat ships that nicely
documented config that will work for the majority of administrators.
After all of this, I am left with the feeling that there has got to
be a simpler and more straightforward ntp daemon. Thankfully, there are
indeed alternatives to the reference implementation of NTP. There is Chrony, or OpenNTPD from the fine OpenBSD
group. I have begun using the later at home. Next time I need to solve
this problem at work, perhaps I will move away from the reference
implementation.
