HOWTO ensure your clock is accurate and showing the correct time using the Network Time Protocol

From LinuxReviews
Jump to navigationJump to search

The Network Time Protocol (NTP) has been the standard for accurate clocks on devices connected to the Internet for a very long time. Here's how you can set it up on your Linux system to ensure your clock is accurate.

Traditionally ntpdate and ntpd was the standard for syncing clocks on GNU/Linux machines. Today systemd's timesyncd is the common way of doing it.

How to sync your clock with systemd-timesyncd

First, change the configuration file /etc/systemd/timesyncd.conf to your preferences. Here's a globally usable example you can cut and paste:

File: /etc/systemd/timesyncd.conf
[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=2.pool.ntp.org 3.pool.ntp.org
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048

The values for RootDistanceMaxSec, PollIntervalMinSec and PollIntervalMaxSec in this example are the defaults. The important values to change are NTP and FallbackNTP.

The example above will actively use two of the global NTP pools and fallback to two others if those fail. This, of course, means that you would be screwed if ntp.org were to fail. See Picking timeservers to choose better ones for your location.

Once you're happy with your systemd-timesyncd configuration you should start it and enable it:

systemctl start systemd-timesyncd
systemctl enable systemd-timesyncd

timesyncd manual page

Syncing your clock with ntpd

ntpd is a full-fledged time-server. You can use it to sync the clock on your own computer or run a timeserver service on your local network which can be used by other machines and devices.

The ntpd package is simply called ntpd on most distributions and it is installed in the usual manner (dnf -y install ntp / yum install ntp / apt-get install ntp / emerge ntp depending on distribution).

You need version ntp-4.2.5p16 or later to listen on IPv6 addresses.

Client (Desktop) NTPD configuration

Most people just need a nice client setup which asks timeserver(s) what time it is and adjusts the local clock accordingly. The default /etc/ntp.conf configuration file is actually quite cool out-of-the-box most distributions but you may want to change it anyway. Here's an example of a simple client setup:

File: /etc/ntp.conf
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1

# Timeserver(s) to (ab)use
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst
pool 2.fedora.pool.ntp.org 

# not actually a server, it's your local clock
server  127.127.1.0     
fudge   127.127.1.0 stratum 10

driftfile /var/lib/ntp/drift

Take note of the use of pool in the above example. You can also use server if you are specifying that you want to use one single all-alone timeserver and not a pool.

If you are going to use ntp on modern distributions you will want to mask systemd-timesync and enable ntpd:

systemctl stop systemd-timesyncd
systemctl disable systemd-timesyncd
systemctl mask systemd-timesyncd

then

systemctl enable ntpd
systemctl start ntpd

Once ntpd is running you can use ntpstat to verify that it is synchronizing.


What the fudge?

There are two lines in the above example which require some explanation:

File: /etc/ntp.conf
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

server says that the local system clock is a timeserver. fudge says that this server is stratum 10. If you are connected to the Internet then you are likely using timeservers who are more l33t than stratum 10 what time it is, and these servers are used because they have lower stratum and thus; higher priority[1].

However, if you are disconnected from the Internet then they are unavailable and you're left with the local clock. Using fudge to say that the local clock is stratum 10 makes ntp use the local clock when no timeservers are available. This is good because it makes sure you can disconnect your box from the Internet without getting your clock screwed.

NTP Time Server configuration

You much likely want to run your own NTP server if you are a huge and profitable corporation, intelligence service or just a private citizen who happen to control a really large network.

The reason is this: Only one box really needs to get the correct time from the outside. This box can act as a timeserver and tell the rest of the boxes on your network what time it is.

Here's a nice "standard" configuration file for a timeserver:

File: /etc/ntp.conf
restrict default kod nomodify notrap
restrict -6 default kod nomodify notrap

pool 0.pool.ntp.org
pool 1.pool.ntp.org
pool 2.pool.ntp.org

server ntp6.remco.org prefer
server chime3.ipv6.surfnet.nl
server ntp1.ipv6.lrz-muenchen.de

server          127.127.1.0     # local clock
fudge           127.127.1.0 stratum 10

driftfile /var/lib/ntp/drift
broadcastdelay  0.008
keys            /etc/ntp/keys

Notice that this is basically the same configuration as the client example except that in the client example the very important restrict lines are

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

while on a server the restrictions are just

restrict default kod nomodify notrap
restrict -6 default kod nomodify notrap

A notice on Firewall setup: It must be possible to connect to port 123, both UDP and TCP, from the outside / all boxes who will be (ab)using your timeserver.

A notice on restrictions: restrict is probably the least understood part of ntpd configuration. In the above example

  • kod makes ntpd send a "kiss-o'-death (KoD) packet" when something violates it
  • nomodify makes run-time state and configuration modification impossible. Perhaps you'd like to setup keys and use ntpq and ntpdc to do this but you likely don't.
  • noquery will deny queries from ntpq and ntpdc and does not deny time service queries-

Picking your timeservers

There are two things to consider when picking timeservers: Distance (d), and stratum. stratum really means "How l33t is this sever?". Servers who are able to figure out what time it is all on their own using an external source - not the Internet - are very l33t and thus; Stratum 1. Servers using an atomic clock or satellite systems like GLONASS and GPS are considered to be Stratum 1.

Laziest Way To Pick Timeservers: Use pool.ntp.org[2]. Their global pool:

File: /etc/ntp.conf
pool 0.pool.ntp.org
pool 1.pool.ntp.org
pool 2.pool.ntp.org

There are local ntp pools for most parts of the world, for example:

File: /etc/ntp.conf
pool 0.europe.pool.ntp.org
pool 1.europe.pool.ntp.org
pool 2.europe.pool.ntp.org
pool 3.europe.pool.ntp.org

Other continents where you have [0-3].continent.pool.ntp.org are:

Asia asia.pool.ntp.org
Europe europe.pool.ntp.org
North America north-america.pool.ntp.org
Oceania oceania.pool.ntp.org
South America south-america.pool.ntp.org

There's also local country pools such as dk.pool.ntp.org (Denmark), fr.pool.ntp.org (France), etc.

File: /etc/ntp.conf
pool 0.fr.pool.ntp.org
pool 1.fr.pool.ntp.org
pool 2.fr.pool.ntp.org
pool 3.fr.pool.ntp.org

If you know there are good local timeservers in your area and you know their names you should use those and use server instead of pool to specify them. Example:

File: /etc/ntp.conf
server ntp.uio.no
server gbg1.ntp.se
server gbg2.ntp.se
server sth1.ntp.se
server  sth2.ntp.se

rdate - The almost forgotten light-weight client/desktop alternatives to using ntpd

Using ntpd is good because it kind of smooths things over and gradually adjusts the system clock. This is good because some software may become very confused if the clock suddenly and unexpectedly jumps 5 minutes back or forth. systemd-timesync tries to do the same.

If you do not like those two then there's a third alternative: rdate. Good old rdate. The original rdate binary is just 3kb and the more common openrdate is about 30kb. Both are used the same way: rdate -p timeserver as in

rdate -p 0.pool.ntp.org

rdate is something you could run once upon boot or put on a hourly or daily cron schedule if you want a bare minimum of services running in the background.

Testing your NTP configuration

ntpq, the NTP query program, can give you all sorts of interesting information about your timeserver. Running

ntpq -pn

will print out all kind of incriminating evidence about your time-server such as:

     remote           refid      st t when poll reach   delay   offset  jitter
 127.127.1.0     .LOCL.          10 l   52   64    1    0.000    0.000   0.000
 2001:610:508:11 .GPS.            1 u   51   64    1   45.997    5.521   0.000

Another example:

     remote           refid      st t when poll reach   delay   offset  jitter
 0.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
 127.127.1.0     .LOCL.          10 l   15   64    1    0.000    0.000   0.000
 83.251.208.60   .PPS0.           1 u   15   64    1   20.583   -3.385   0.000
 91.209.0.19     194.58.204.148   2 u   14   64    1   10.177   -0.697   0.000
 83.168.200.198  194.58.202.20    2 u   14   64    1    5.476   -1.751   0.000
 91.216.111.52   244.77.152.229   2 u   12   64    1    6.159   -1.148   0.000
 193.228.143.13  194.58.202.148   2 u   13   64    1   12.826    2.533   0.000
 91.209.0.20     232.6.188.111    2 u   10   64    1    8.490   -1.354   0.000
 217.75.106.216  194.58.202.20    2 u    9   64    1    5.962   -1.163   0.000
 83.168.200.199  194.58.202.20    2 u   10   64    1    6.219   -1.340   0.000

ntpq manpage story is:

Output all host addresses in dotted-quad numeric format rather than converting to the canonical host names.
Print a list of the peers known to the server as well as a summary of their state. This is equivalent to the peers interactive command.

There is a perl script called ntptrace available on older systems which can be used as a command-line front-end for ntpq. It has not been updated in decades and does not appear to be available on modern systems.

If most of your servers are showing a very high delay then it's worth considering using another server and/or pool.

References