If you’re a busy system administrator, you’ve probably got a clock displayed on your computer’s screen at all times. The clock is a handy convenience, but it has its problems: computer clocks are notoriously unreliable. After a few days, you may discover that your clock is several minutes off.
If it were just a question of seeing the wrong time on your desktop clock, the unreliability of computer clocks would be nothing more than an annoyance. Unfortunately, there’s more to the problem than that: computer timekeeping is vital for certain functions. For example, the make utility relies on time stamps to determine which files need to be rebuilt; the Kerberos network authentication tool uses time stamps as part of its security system; time stamps are built into email exchanges and are used for troubleshooting them, and so on. Incorrect system times can cause failures in any of these systems, particularly when the time differs from one computer to another.
Fortunately, a solution to inaccurate computer clocks exists: the Network Time Protocol (NTP). NTP is a tool to set one computer’s clock from another one. Using NTP, you can ensure that all the computers on your network have the same time, and that this time is synchronized to the time used by outside computers, all to within a fraction of a second. Once NTP is installed and configured, you’ll never again need to manually reset your computers’ clocks, except perhaps when setting up a new computer.
The first thing to know about NTP is that it’s hierarchical, as illustrated in Figure One. One time source, such as an atomic clock, maintains a precisely accurate time. This is referred to as a Stratum 0 time source. Ordinarily, Stratum 0 time sources communicate only with Stratum 1 servers. Each Stratum 1 server has the potential to deliver its time to many Stratum 2 servers, each of which in turn can service many Stratum 3 servers, and so on. In practice, the servers on each level are likely to service many more than the two or three computers shown in Figure One. The hierarchy can also extend to an arbitrary number of levels beyond Stratum 3 depicted in Figure One.
Some of the computers in Figure One synchronize to more than one NTP server. For instance, the Stratum 3 laptop refers to three Stratum 2 servers, whereas the desktop system to its right synchronizes to just one server. The option for redundancy provides automatic backup in case one NTP server becomes unavailable. It can also serve as a sanity check: if one server begins delivering wildly inaccurate times, NTP can detect the inconguity and discard the time signals from the “false ticker.”
In practice, if you maintain an entire network of computers, you’re likely to set aside one or two computers to synchronize with one or more upstream NTP servers. You’ll then configure your remaining systems to synchronize to your network’s primary NTP server (s). The result is that all of your networks’ computers’ clocks will be set to within a tiny fraction of a second of each other, and all of these computers’ clocks will be set to within a larger (but still small) fraction of a second of other computers that set their clocks via NTP.
At first, you might think that network time setting would be simple: One computer asks another for the time, the second computer replies, and the first sets its clock appropriately. Unfortunately, it’s not that simple. The problem is that packets take time to traverse a network. If a time protocol fails to take this delay into account, the times of client systems will be inaccurate. In a tiered system such as NTP, this inaccuracy builds the further one gets from the original time source. NTP solves this problem by using back-and-forth exchanges that enable the software to determine the round-trip delay and other related timing issues of the network connection. NTP can then compensate for the network delays, arriving at a very accurate time — assuming the upstream NTP server’s time is accurate, of course.
One quirk of NTP is that the most common NTP software for Linux functions as both a client and a server. The intent is for the software to be able to synchronize its time and then deliver its own time to other systems. The Stratum 1 and 2 computers in Figure One operate in this dual mode. However, even if the computer won’t be functioning as an NTP server to NTP clients, it’s common practice to install the entire NTP server package; you simply won’t use its server features.
One reason for running the full NTP package even on clients is that this package runs in the background and slews your clock– that is, it changes the rate at which the clock runs. In fact, if your clock is off by a couple of seconds when NTP starts, rather than reset the clock in a quick, wholesale operation, NTP slews your clock so that it reaches the correct time in a few hours or days, and then slews the clock so that it maintains the correct time. This method of operation ensures that clock-setting operations don’t disrupt time-dependent software, such as the cron daemon.
Locating an Upstream NTP Server
One of the first things you should do when planning an NTP installation is to locate one or more appropriate NTP servers. For networks of under about 100 computers, you should use a Stratum 2 or lower server; the Stratum 1 servers should be accessed only by computers that themselves deliver the time to hundreds or more computers. You can locate an appropriate server in several ways:
*Check with your ISP or your organization’s networking department. An appropriate server may exist close to you in a network sense, and this proximity improves the accuracy of the time signal.
, which hosts lists of public Stratum 1 and 2 servers. Be sure to follow any special instructions provided with the descriptions, since many NTP server operators like to be notified of your use of their servers as a matter of courtesy.
*Check your Linux distribution’s documentation. Some distribution maintainers run NTP servers for their customers. These are generally poor choices because they’re likely to be located far away from you in a network sense, but you might luck out on that score.
The ideal NTP server is close to you. This distance is measured in network terms, though, not in geographic miles. For instance, if you’re in Dayton Ohio, you might think an NTP server in Cincinnati (a few miles away) would be a good choice, but if your network traffic to Cincinnati is routed via Los Angeles, you might be better off using an NTP server located in the City of Angels! A quick test is to use the ping program and note the packet return times from the servers you’re considering. The shorter the time the better. The traceroute program is another useful diagnostic tool. It returns information on the number of network hops between you and a target computer; the fewer the hops, the better.
To begin, you should locate two or three candidate servers. You can then install the NTP software on your network’s primary NTP server computer and configure it.
Configuring a Network’s NTP Server
Your NTP server need not be a powerful system. Unless it serves many thousands of computers, NTP doesn’t put a great strain on a computer or its network connections. Thus, you can use an old 486 or have a computer do double-duty as some other internal server. (It’s probably best to keep your network’s own NTP server inaccessible to the outside world for security reasons.) Be sure your NTP server has reliable access to the Internet at large.
The bulk of the work of configuring an NTP server is installing the software. Most major distributions ship with NTP software in a package called ntp
, or something similar, so look for and install that package. You can also download the NTP software source code from http://www.ntp.org
, but you’ll then need to compile and install the software yourself.
Once you’ve installed NTP, you configure it through the /etc/ntp.conf file. The most important configuration option in this file is the server line, which specifies an NTP server by hostname or IP address:
These three lines tell the NTP server to look to three other systems for its time: 10.27.103.48, time.example.org, and tempus.luna.edu. The order in which servers are listed is unimportant; the server determines which server has the most reliable time and uses it.
Change your ntp.conf file’s server lines so that they point to the NTP servers you identified earlier as being appropriate for you. List precisely one server per line; don’t try to combine multiple servers on a single line.
Although you need to change only the server lines, the /etc/ntp.conf file contains several other options that may be important. You should probably review the following:
*fudge is used to override the claimed stratum level of a server. It’s most often used in conjunction with the 127.127.1.0 address, which refers to a computer’s own local clock. For example, fudge 127.127.1.0 10 sets the computer’s own clock to stratum 10. The result is that NTP can use the local clock as a last-resort method of setting itself. (The stratum 10 value is somewhat arbitrary, but is intended to be much higher than any likely, true NTP server’s stratum.)
*The restrict keyword provides access control for an NTP server. Typically, the first such line is restrict default ignore, which tells NTP to ignore all incoming requests. You can then add lines like restrict 192.168.43.0 mask 255.255.255.0 to open the server to the specified range of IP addresses.
*For very security-conscious sites, NTP provides options such as keys, trustedkey, requestkey, and controlkey to provide authentication between clients and servers. These options require special configuration and are normally commented out or are simply not present in default ntp.conf files. (The use of authentication options is beyond the scope of this article.)
*The broadcast keyword tells NTP to regularly broadcast its time to an entire subnet, while the broadcastclient option tells NTP to listen for such broadcasts. Although these options can be a useful way of minimizing NTP traffic on large networks, they should be used with the authentication options, and so aren’t described here.
Once you’ve reviewed and adjusted your /etc/ntp.conf file, you should start the server. (If your computer’s time is off by more than a few minutes, you might want to set it to something that’s at least approximately correct first. NTP quits if your local time is greatly at odds with the time found on remote NTP servers.)
In most cases, you can start NTP with a SysV startup script, as in:
# /etc/init.d/ntpd start
Of course, if the server is already running, you should pass it the restart option rather than start. You can then check the server’s operation and configure your clients.
Testing the NTP Server
Once you’ve started the NTP software, you can begin monitoring its operation. This is best done with the ntpq program, which provides a number of commands for monitoring NTP’s operation. The most important of these is peers, which displays information on the NTP servers you’ve told NTP to use as time sources. Figure Two shows the peers command in action.
In Figure Two, the tempus.luna.edu server has been selected as the most reliable, as denoted by the asterisk (*) to the left of the name. The plus signs (+) to the left of the other names indicate that each one is a reasonable backup time source. Many other symbols, such as an x or a minus (–), denote servers that are unreliable in one way or another. The st column identifies the server’s stratum. Figure Two ‘s LOCAL server is the computer’s own hardware clock.
Immediately after you launch NTP, ntpq won’t report a default upstream server (as denoted by the asterisk). Instead, NTP queries all the servers periodically, and as it gathers data on their reliability, eventually settles on one as the default. As NTP continues to run, it lengthens the interval between its queries, up to a typical value of 1,024 seconds (about 17 minutes), as denoted by the poll column.
Once NTP has been running for a few hours or days, you may want to reconfigure it to eliminate all but one or two of the upstream servers you configured earlier. Doing this minimizes the network traffic that NTP generates and reduces the load on the servers you remove from the list. You should periodically check your NTP server with ntpq; public NTP servers disappear from time to time, so if you fail to review NTP’s operation every few weeks, you may eventually end up with an NTP server that doesn’t synchronize itself with outside time sources.
Configuring NTP Clients
Once you’ve configured your network’s primary NTP server, you can configure the rest of your computers to refer to it. This task is just like configuring the server, except that you point your local computers to your local NTP server, rather than an external NTP server, in the clients’ /etc/ntp.conf files. This way, you won’t be putting unnecessary strain on the upstream server or unnecessarily increasing your Internet traffic.
If you have a Linux or other Unix- like system on your network, they can be configured as just described. For Windows systems, though, configuration is a bit different. Windows NT/200x systems support NTP via the NET TIME /SETSNTP command:
NET TIME /SETSNTP:time.server
This command sets the Windows computer’s clock to the time maintained by the NTP system called time.server (replace time.server with a real hostname). Older Windows 9x/Me systems lack NTP support, but they can synchronize their clocks to the time maintained by another Windows or Samba system using a similar command:
NET TIME \\SERVER /SET /YES
This command sets the clock to the time maintained by SERVER (replace SERVER with a real hostname). Both of these commands perform one-time clock setting operations.
If a Windows computer is shut down and rebooted regularly, placing such a command in a startup file can do the job. If you need the full NTP functionality on a Windows system, consult the NTP Web site for information on obtaining and using NTP for Windows.
Roderick W. Smith is the author or co-author of over a dozen books, including Linux in a Windows World and Linux Power Tools. He can be reached at
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62