The aim of this article is to provide an actually working, reasonably explained NTP config for people who aren't NTP fans and think their time service is acting weird.
The truth is that most distributions now, like in the 90s, deliver very bad settings as the default NTP config. NTP itself is working just fine once it's told what to look for. If you're thinking "LOL? NTP is just one line of config!"... please take note that the book on the network time protocol has a chapter about "use on long range space exploration missions". One line of config will get you something similar to running a DNS Server with only one of the root servers configured.
Yes, that would be stupid :-)
Please understand that this article is rather fresh, as such we're...
...still working on it!
Let's get started!
What are step tickers?
In RHEL/CentOS/Oracle Linux, put the name server's adresses as a space separated list in this file:
The system will run an initial ntpdate against the first of those to be found available.
This is run early on in the boot process so the OS can still safely STEP instead of using SLEW.
That means it will immediately in one operation (the "step") jump in time to the right clock time. The slew would instead slowly correct the time. At boot time, it's much easier and safer to first get to the right time and then starting up stuff. Someone at RedHat luckily understood that.
The accompanying options for ntp are:
(Allow large offset on start, and STEP once to adjust it. That of course means NTP should be one of the first network-based services to start, and no database based application should be allowed to start before NTP. Basic OS design, I hope your maintainers still know that.
Isn't NTPdate outdated?
In fact, ntp has a subcommand for fetching time just like ntpdate did it. What it doesn't easily allow is to use the most common use case of ntpdate: The debug mode, accessible even to non-root since it does not attempt to set the time.
Much worse off are debian users since every single Debian release comes without the NTP debugging support compiled in.
Example NTP.conf configuration file
This block shows an example for an actual NTP config file.
- driftfile - NTP is smart enough to track the normal differences in your systems hardware clock. if you don't have that configured and complain about weird NTP behaviour... your fault. Change it now :)
- statsdir - Stats aren't most important unless you suddenly find you would need them.
- tinker panic 0 - normally NTP would give up if the clock is suddenly WAY OFF. This can happen with BIOS bugs around EIST/HPET, badly designed hypervisors, bad suspend/resume configuration, hypervisor bugs and rare other scenarios. Tinker is the heads up to NTP you want to modify one of it's core features.
- server 127.0.0.1 this is the "local clock fallback". Real local GPS clocks will also start with 127. but include other numbers instead of the zeroes, which tells NTP what driver to use. 0.0. is always the fake local clock.
- fudge - lets you modify certain aspects of a server. In this case the stratum value that tells NTP this "server" has to rely on 12 intermediate ones till it gets to one that actually _HAS_ a clock. So it will only be used if all other's failed
- server - these lines list the individual servers. make sure you have a number of at least 3. Uneven numbers are preferred, not counting the "local fallback clock"
- iburst means a short volley of packets will be sent once the server is found reachable. This allows NTP to quickly select a "good" server.
- burst means it'll also use those volleys during normal operation. Do not use if you only have 2 servers
- minpoll and maxpoll set the interval NTP should try to reach it's upstream clock. Maxpoll also influences the backstep algorithm for dead servers. Don't let it be too high or it will take hours after you fixed the upstream server till your fix gets noticed.
- Only one server should be preferred
- The restrict options are important on servers to disallow certain attacks (mostly on the "monitor" command). Also, it disallows other people on the network to set your clock.
These settings are the ones you should immediately look for in your existing configs:
- iburst and burst
The no panic option is also helpful, but I've found this to be a very very rare issue.
It's of course helpful to set it - just as it's really good to monitor your NTP service itself. The Check_MK NTP checks are very very sensitive to common NTP issues and uncover them quickly. Especially those errors that you don't quickly recognize in the NTP output. Or do you remember right away what character indicates a "falseticker" (time jumped backwards) NTP Server?
No matter what you read about it, the quality of the NTP pool is not consistently great. There are broken servers, there have been malicious servers. If your ISP provides stratum 1 servers, please use those.
More advanced larger scale config
For larger networks or network islands, those are the things to look for
- orphan mode
Finally a quote about running with two servers only from the famous comp.protocols.time newsgroup:
A man with a watch clock will always know the time.
The man with two watches will never be able to be sure.