They say that in comedy, timing is everything. That goes for computing, too. While PC system boards feature a battery-backed real-time clock that continues to run while the system is powered down, these clocks typically drift quite widely. Similarly, the system clock that is maintained by the Linux kernel, using the motherboard's counter/timer circuit, also drift over time. As a consequence, your PC's clock will progressively run fast or slow, and if you have multiple machines, the fact that they all show different times can grate.
There are more serious reasons to get your clocks in sync, though. For a start debugging of network client/server applications is considerably simpler when log file entries are accurately time-stamped - you can see that something happened on the client at a certain time, and a quarter of a second later, the server responded by doing something else. If the system clocks aren't in sync, it can look as though the server responded before the client asked it to, or worse, you're not sure whether the server is responding to this event on the client or an earlier one.
Similar problems arise when you are trying to investigate security-related incidents such as network breakins. Did this daemon on server A crash before the hacker did something on server B? Was that how he got in? Or did he attack B first, then A? An accurate understanding of the sequence of events can be important in configuring the systems to defeat future attacks.
While we're on the subject of security, some network protocols, such as Kerberos, use time-stamps in their messages, in order to defeat what are called replay attacks. Kerberos allows for a plus-or-minus five minutes error in time synchronization between systems, but if you drift outside this, authentication will fail.
To get around these problems we need two things:
Fortunately, the US Department of Defense provides a number of freely-accessible atomic clocks, in the form of the Global Positioning System satellite constellation. Because GPS works by accurately measuring the times it takes for signals to arrive from several satellites, and the receiver has to know precisely where the satellite is, the GPS satellite signal includes highly precise timestamps from atomic clocks on board the satellites. It's possible to retrieve the time from a GPS receiver using the NMEA protocol over RS-232C or via proprietary drivers.
However, you probably don't want to even go to the expense of dedicating a GPS receiver to providing an accurate time source. Instead, it's enough to know that there are publicly-accessible time source servers which use either atomic clocks or GPS receivers, and to which you can slave your computer's clock using the NTP protocol.
Network Time Protocol
The Network Time Protocol is a distributed network application, in which many systems operate as both clients and servers in a distributed hierarchy. Technically, a client is just a server that has no clients of their own.
Strata
Systems which acquire time from an atomic clock, GPS receiver or similar source are said to be Stratum 1 servers. From this point on, down the hierarchy, the stratum numbers increase - a system that gets its time from a stratum 1 server is said to be a stratum 2 server, and so on.
It is considered poor form to configure all the systems - or even multiple systems - on your LAN to get their time from an external stratum 1 server (or even someone else's stratum 2 server). The goal is to keep the load on these servers as light as possible in order to preserve accuracy. Instead, you should configure one of your systems to get the time from an external server and also function as a time server for your remaining systems.
NTP is a much more sophisticated protocol than you might expect.
Setting Up a Time Client
restrict default ignore restrict 127.0.0.1 driftfile /etc/ntp/drift broadcastdelay 0.008 authenticate yes keys /etc/ntp/keys restrict 192.168.168.252 nomodify notrap noquery server 192.168.168.252
Setting up a Stratum 2 Time Server
This configuration shown here illustrates a machine that is configured as a startum 2 time server for an office LAN. Of course, it gets its time from an external stratum 1 time server.
# Prohibit general access to this service # restrict default ignore # Allow this machine to query any time server. restrict default nomodify notrap noquery # Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 # -- 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 notrust nomodify notrap restrict 192.168.168.0 mask 255.255.252.0 notrust nomodify notrap # --- OUR TIMESERVERS ----- # or remove the default restrict line # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. # restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery # server mytrustedtimeserverip server ntp0.cs.mu.OZ.AU server ntp.saard.net # --- NTP MULTICASTCLIENT --- #multicastclient # listen on default 224.0.1.1 # restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap # restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap # --- GENERAL CONFIGURATION --- # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /etc/ntp/drift broadcastdelay 0.008 #broadcast 192.168.168.255 #broadcast 192.168.170.255 # # Authentication delay. If you use, or plan to use someday, the # authentication facility you should make the programs in the auth_stuff # directory and figure out what this number should be on your machine. # authenticate yes # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 600 for sure) and define the key number to be # used for making requests. # # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. Note also that # ntpd is started with a -A flag, disabling authentication, that # will have to be removed as well. # keys /etc/ntp/keys
Testing Your Setup
[root@sleipnir root]# ntptrace localhost.localdomain: stratum 3, offset 0.000023, synch distance 0.10294 dvalin.cullen.lesbell.com.au: stratum 2, offset 0.014781, synch distance 0.07835 murgon.cs.mu.OZ.AU: stratum 1, offset 0.013050, synch distance 0.00084, refid 'GPS'
References and Further Reading
The Network Time Protocol Project: http://www.ntp.org/
RFC 1305: Network Time Protocol (Version 3): Specification, Implementation and Analysis: ftp://ftp.rfc-editor.org/in-notes/rfc1305.txt
The Public NTP Servers List: http://ntp.isc.org/bin/view/Servers/WebHome
Page last updated: 15/Jul/2006 Back to Home Copyright © 1987-2010 Les Bell and Associates Pty Ltd. All rights reserved. webmaster@lesbell.com.au