Even if this is the first article I’m writing on the subject, I’ve always been attracted to the time keeping part. My favorite way to keep the clock in line is NTP (Network Time Protocol) and it’s linux implementation ntpd.
Over the years I’ve seen the configuration of NTP server was overlooked by many fellow system administrators. A sincronized clock is crucial for so many scenarios and should be a priority to ensure the time system is working correctly.
Some examples of infrastructural services where time keeping is very important can be: Virtual Machine Hosts, DHCP, LDAP, Kerberos Authentication Servers.
Most Linux distros come with a preconfiguration of ntpd or systemd-timesyncd. This preconfiguration is usually a good one, but it uses free public services that are not always reachable in LAN. Some implementations can use the configuration of NTP server pushed by the DHCP servers. I will leave the latter to Desktop or mobile users, along with systemd-timesyncd.
For a server environment, whether it is a Linux, Windows, appliance or whatever, a sysadmin usually changes the NTP servers configured to the one available in the LAN and here come the Best Practices that can be very different in NTP, than other protocols that are used everyday like DNS o DHCP.
Here is the NTP RFC, and it’s actually of simple reading:
https://datatracker.ietf.org/doc/rfc8633/
What I normally see on a daily basis on my job, and that is usually mistaken in a NTP configuration is that people tend to be tight with the number of ntp time servers configured in ntpd. I know this is primarly a philosophical issue, in fact also a wrong configuration can be a working one for years in some environments, but why risk it?
The philosophical part is this one:
- a man has one single clock to look at. He has to assume this clock is right.
- a man has two clock to look at. If they ALWAYS show the same time, then the man can assume they’re right. Otherwise the man don’t know which one to choose.
- a man has three clock to look at. If none of them ever break, the correct time must be within the two clock running closer to each other. If one of the clocks break, then the man quickly falls in the two clock situation above.
Now with phisical clocks, the occurrence that one break is maybe not likely to happen every day. With private server running ntpd could happen more often, for example when rebooting for updates. Public NTP servers are the hell of “false tickers”, servers that say they can be trusted but they give the wrong time, and they can go down or openly bad in any moment, since they are free and there is no assurance they have to stay up and working all the time.
So the Best Practices for the number of NTP server is to configure 4 or more, or if you can’t, to use just one. If using public server my suggestion is to use as many as you think is best: NTP is a very light protocol, so there is no downside in using 10 servers for example. Usually I always stick to something between 4 and 8 server: I think more than that are not really useful to the cause, but there’s not really a limit. Local and public server can be mixed.
There are other Best Practices in addition to the number of time server, for example using the peer statement in ntpd, discussion on virtualized clocks or find ways to bicker with systemd, but I’ll leave this to another time.