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.

ntpdate and ntpd were historically the standard for syncing clocks on GNU/Linux machines. ntpd can still be used but there are several other modern alternatives one may want to consider.

Client / Desktop Configuration

There are several alternatives you can use to synchronize your click with NTP. You should make sure you are only using one. The most popular alternatives are:

  • chronyd - Default on Fedora
  • ntpd - The most widely used network time servers. Primarily for servers, can also be used on desktops
  • rdate - small, light, does not run as a daemon. Can be used as a startup-job or cron job
  • systemd-timesyncd - Comes with systemd, most distributions have it installed (but not activated by default)

Howto Sync Your Clock With The Chrony Daemon

chronyd is a fully featured time synchronization daemon which is similar to ntpd. It is a good choice for network time synchronization and it is the default network time client on Fedora. It is configured by the configuration file /etc/chrony.conf which does not need to contain much. If can look like this:

pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
minsources 1
driftfile /var/lib/chrony/drift
makestep 5.0 3
rtcsync 
keyfile /etc/chrony.keys
leapsectz right/UTC   
logdir /var/log/chrony

The pool directives are the most important parts of a chronyd configuration file. The makestep directive is also worth noticing. The chrony.conf manual[1] explains its arguments as makestep threshold limit. It makes chrony adjust the system clock to real time if the clock is more than threshold out of sync - but only if chrony has done less than threshold adjustments. makestep 5.0 3 makes chrony harshly adjust the clock if it is more than five seconds out of sync upon boot. chrony will normally gradually smoothly adjust the clock. That is ideal but not if the clock is wildly out of sync.

minsources 1 makes chronyd adjust the clock even if there is just one clock source available. You may want to use minsources 5 if you configure a lot of pools and do not want any adjustments to take place unless there are five clock sources available.

rtcsync makes chronyd adjust the system clock.

Howto 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[2]. 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
See also: systemd-timesyncd

Howto Sync Your Clock With rdate

rdate is a a light-weight client/desktop alternative for synchronizing your clock. It does have some limitations. Most importantly, it adjusts the clock and walks away, it does not run as a daemon or care what time the system thinks it is after adjusting the clock once when it is executed.

chronyd, systemd-timesync and or ntpd will smoothly and gradually adjust the clock. This is good because some software will become very confused if the clock suddenly and unexpectedly jumps 30 minutes back or forth. rdate will simply set the clock to whatever time it is, if the system clock is two hours off and rdate runs then the clock is adjusted by two hours.

rdate does have one advantage: it is very small and light-weight. The original rdate binary is just 3kb and the more common openrdate is about 30kb. Both are used the same way: rdate -p timeserver[3] 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. Do note that adjusting the clock daily with a rdate cron job may cause problems if your system clock is wildly inaccurate; rdate will set the clock to the time the ntp server it contacts reports - it will NOT do gradual smooth adjustments.

Howto Sync 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.

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.

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[4].

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.

Network Time Protocol 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.

There are two good choices:

  • chronyd, which is fully featured and modern, and
  • ntpd, which is a old and very well tested time server.

Configuring A ntpd Time Server

Here's a nice "standard" configuration file for a ntpd 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-
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[5] story is:

-n Output all host addresses in dotted-quad numeric format rather than converting to the canonical host names.
-p 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.

Most distributions have a package called ntpstat which can show some basic information about a NTP server available. It will show less useful information like:

synchronised to NTP server (2a01:3f7:4:1::1) at stratum 2
   time correct to within 16 ms
   polling server every 64 s

Running ntpq -pn will give you a lot more detailed information; ntpstat is not useful for more than verifying that a ntp server is working.

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

Configuring A Chrony Time Server

A chronyd time server meant to serve a LAN is configured mostly the same way a chronyd client meant to serve the box it is running on is. A server configuration can look like this:

pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst

driftfile /var/lib/chrony/drift
makestep 5.0 3
rtcsync
allow 192.168.0/24
local stratum 10
keyfile /etc/chrony.keys
leapsectz right/UTC
logdir /var/log/chrony

The above configuraiton file is mostly the same as you would use to syncronize time on a single computer with two exceptions worth paying attention to:

allow 192.168.0/24
local stratum 10

The allow directive opens the door for other computers on the network. It should have a subnet and a prefix as an argument.

local stratum 10 tells the NTP clients on the network that the NTP server is not using a primary clock source. You could use 3 too. Servers with a real clock source (GPS, etc) are stratum 1, servers connecting directly to a server with a real clock source are stratum 2. What higher number you use beyond that is kind of irrelevant, just be aware that you should not use 1 or 2 since your networks time server isn't a going to be a primary or secondary clock source.

You will have to make sure clients who are going to use the network time server have access to UDP port 123. chronyd does not listen to any TCP ports.

Picking Network Time Servers

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.

The Simple And Lazy Way To Pick Timeservers

Laziest Way To Pick Timeservers is to use a global or regional pool,

The global ntp poool pool.ntp.org[6] will work just fine anywhere:

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

There are local regional ntp pools for most parts of the world. This ensures that the ntp servers are relativily close. As an 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. They are typically available as digit.countrycode.pool.ntp.org like:

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 then you could use those and use servers instead of a pool. Specify them by DNS/name if you go that route. 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

The Cumbersome Way Of Picking NTP servers

Lovelyz Kei ProTip.jpg
TIP: Going with your countries NTP pool is simpler and quicker than manually querying a lot of time servers in order to fine one you "like".

The program ntpdate, which is NOT part of the regular ntp package - you will have to install ntpdate separately - can be used to check time-servers with it's -q option. -q means "Query only - don't set the clock"[7]. Querying a working ntp time server with ntpdate -q hostname will print out some details about the time server. Querying a host which is not running a working time-server will output no server suitable for synchronization found.

Some examples:

$ ntpdate -q  ntp.time.nl
server 2a00:d78:0:712:94:198:159:10, stratum 1, offset 0.005731, delay 0.06699
server 94.198.159.10, stratum 1, offset 0.004027, delay 0.06264
 4 Dec 21:38:28 ntpdate[1745229]: adjust time server 94.198.159.10 offset 0.004027 sec

The above indicates that ntp.time.nl is a working ntp time server with both IPv4 and IPv6 connectivity. It is a stratum 1 which means that it has it's own clock-source.

Another example:

$ ntpdate  -q ntp.uio.no
server 2001:700:100:2::6, stratum 2, offset 0.003351, delay 0.04016
server 129.240.2.6, stratum 2, offset 0.001663, delay 0.03783
 4 Dec 21:38:04 ntpdate[1725109]: adjust time server 129.240.2.6 offset 0.001663 sec
</code>
The above shows that <code>ntp.uio.no</code> is also a working ntp time server with both IPv4 and IPv6 connectivity. This server is a <code>stratum 2</code> server which means that it has no way of keeping track of time on it's own. It can only ask <code>stratum 1</code> servers who do have GPS or an atomic clock or something else to rely on.

'''The <code>delay</code> part of <code>ntpdate -q</code> is worth a close-up inspection if you do decide to manually pick and choose the time-servers you use.'''

<code>lrte.ntp.ifsc.usp.br</code> is a working NTP server which is part of the <code>south-america.pool.ntp.org</code> NTP pool. Consider this response when querying <code>ntpdate -q  lrte.ntp.ifsc.usp.br</code> from Europe:

server 143.107.229.211, stratum 1, offset -0.002947, delay 0.27168

4 Dec 21:48:10 ntpdate[2257544]: adjust time server 143.107.229.211 offset -0.002947 sec

The delay of 0.27168 may not appear to be huge but it is compared to the in-comparison small 0.04016 delay to local NTP servers.

The page IPv6-listening NTP servers has a list of NTP servers with IPv6 connectivity. It is less relevant than it was when it was first created in 2008 since most NTP servers supports IPv6 these days.

References

Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.