One of the more popular time server protocols is known as the Network Time Protocol (NTP), which is described by RFC 1305 (http://www.ietf.org/rfc/rfc1305.txt). Previous versions were described in RFCs 958, 1059, and 1119. The current version number is 4, although version 3 NTP servers are still common in 2002. The main NTP Web site is http://www.eecis.udel.edu/~ntp/. NTP allows for a hierarchical structure of time servers, so those closest to accurate clocks can serve others, which in turn serve the ultimate clients. NTP clients and servers are readily available for Linux and other OSs. Configuring NTP for Linux requires editing a single configuration file. You can monitor the server's operation using dedicated tools. Limited-functionality clients are also available for easy use if a system is to be a terminus in the time server hierarchy.
Understanding How a Time Server Functions
Time server functionality begins with a veridical time source, such as an atomic clock or a radio or modem receiver that can synchronize with an official time source. Global Positioning System (GPS) receivers work in part by using time signals from satellites , so these may be used as a way to acquire such an accurate time source. (The NTP Web page includes a discussion of such hardware devices at http://www.eecis.udel.edu/~ntp/hardware.html.)
The atomic clock, radio hardware, or similar device is known as a reference or a stratum 0 time server. Unless you own such a device, you won't connect directly to it, since they don't have network connections (they usually interface through an RS-232 serial port and require special drivers). The computer that synchronizes its clock to the reference is known as a stratum 1 server. In theory, these computers have the most accurate times available on the Internet, although in practice, surveys suggest that roughly a third of them have times that are incorrect by a second or more. Systems that synchronize to stratum 1 servers are known as stratum 2 servers, and so on.
Synchronization involves transferring several packets (typically at least five over roughly a five-minute period) between the client and the server. The client sends a packet with the client's current time to the server. The server responds with a similar packet. By comparing the send and receive times using its local clock, the client can estimate the round-trip network delays between it and the server, and thus compensate for these delays in adjusting its own time. The client may also be configured to use several servers, and thus to compare the times, network delays, and other salient factors between these servers in order to select the best time from among these servers.
Locally, a full NTP server runs continuously, checking back with its parent servers every once in a while (initially every 64 seconds, but this interval usually increases to 1024 seconds, or possibly higher with some configurations). The NTP server program can adjust the clock on the computer on which it runs in several ways. NTP typically ignores large differences (those over a second or so) for a while, on the grounds that the large difference might be a protocol error; but after the difference has persisted for a while, NTP compensates either by resetting the time at once or by running the system clock faster or slower (that is, slewing the clock) until the system and external time are synchronized. Small errors are compensated by slewing the system clock until the measurements are synchronized. The NTP server also maintains a file, typically /etc/ntp/ drift , /var/state/ntp.drift , or something similar, in which a number is stored that allows the server to compensate for the bulk of a computer's clock drift even if contact with lower-stratum time servers is lost or if the computer is powered off for a while.
Normally, an NTP server on a small network synchronizes its clock to about three external time servers. (Three is a somewhat arbitrary number; you may increase it or decrease it as you see fit, but three usually provides enough redundancy and cross-checking to work well.) The external time servers for a small network should normally be stratum 2 servers; there's very little accuracy to be gained by using stratum 1 servers, and because there are so few of them, stratum 1 servers are best reserved for use by servers with over a hundred clients. Clients on the small network may then run NTP servers for near-continuous updates from the network's stratum 3 NTP server, or they may use NTP clients or other time protocol clients to update their clocks less frequently. If your network has more than a couple dozen computers and continuous service is important, you might consider running two stratum 3 time servers to reduce the chance of problems should your main time server computer go down or become unreliable. If extremely precise time is important, you might obtain a GPS-based clock and run your own stratum 1 time server. Such clocks sell for a few hundred dollars. Devices based on AM radio time broadcasts are less costly, but are also much less accurate (they're usually accurate to less than a second, but if the goal is high accuracy, that may not be enough).
NTP uses Coordinated Universal Time (UTC) as the basis for all operations. UTC is similar to Greenwich Mean Time (GMT) ”the time in Greenwich, England, unadjusted for Daylight Savings Time. UTC differs from GMT in several technical details, but the main point of interest is that it's defined more precisely and in terms of highly reliable atomic reactions , rather than the rotation of the Earth, which varies by small but measurable amounts. When necessary, UTC is adjusted for variation in Earth's rotation by the addition or subtraction of a second from a day (a leap second ). Local time is related to UTC by adding or subtracting your time zone, with Daylight Savings Time adjustments, if necessary. Linux systems use UTC internally, so UTC is a good choice for a time protocol from a Linux point of view.
Most x 86 OSs require that the motherboard's hardware clock be set to local time, not UTC. For this reason, Linux supports motherboard clocks that are set to either local time or UTC, and maintains a separate software clock set to UTC. On a Linux-only system, UTC is the better option because Daylight Savings Time requires no adjustments to the hardware clock. On a system that dual boots Linux and Windows (or some other OS that requires a clock set to local time), you may be forced to use local time, and both OSs may attempt to make Daylight Savings Time adjustments. Using a time protocol at system boot time can help alleviate this problem, but Linux doesn't automatically adjust the hardware clock when the system clock is set, so the benefit of NTP running under Linux may not manifest itself in the other OS. You can type hwclock ”systohc ”localtime to set the hardware clock from the system clock on a system that sets the hardware clock to local time. Substitute ”utc for ”localtime if the computer stores time in UTC.
Time Server Programs for Linux
The main NTP server package for Linux is known as ntp , or some variant of that, such as xntp , xntp3 , or xntpd . The x in the name stands for experimental, although that's something of a misnomer, since the software has been in common use for several years . NTP version 4 packages usually omit the x . Most Linux distributions ship with one of these packages ”usually version 4, although in 2002 some distributions still ship with version 3.
The NTP package included with most distributions includes the main NTP server and several support programs, including the following:
In addition to the main NTP package, there are other time-setting programs available for Linux. The most common of these is rdate , which is similar to ntpdate in general principles ”you use rdate to set the clock on a one-time basis. Most distributions don't install rdate by default, but many do ship with it. One advantage of ntpdate over rdate is that ntpdate provides much greater precision ”to within a few milliseconds , depending upon network connections and the precision of the parent server. By contrast, rdate provides a precision of only about a second.
NTP is configured through a file called ntp.conf , which is usually located in the /etc directory. This file contains comment lines, which begin with a pound sign ( # ), and option lines that set various NTP options. Important options include the following:
There are many other ntp.conf options available for performing more exotic functions. Consult the documentation, which ships in HTML format and usually appears in /usr/share/doc/xntp- version or a similar directory.
The default ntp.conf file on most distributions is nearly functional; you need only edit or add one or more server lines to point the computer to appropriate NTP server systems. Your choice of servers is important, because a server that's very distant from you in a network topology sense, that has unreliable network connections, or that has synchronized to an unreliable source, can cause your own time to be incorrect or of highly variable accuracy. As noted earlier, unless you're setting up a time server that will serve hundreds or more clients, or unless you have some compelling reason to have the most precise time possible, you should synchronize to a stratum 2 or higher server. You can find an extended discussion of these issues at http://www.eecis.udel.edu/~mills/ntp/servers.htm. The bottom of this document includes links to lists of public stratum 1 and stratum 2 time servers, so you can search the stratum 2 list for suitable time server candidates. Try to find a server that's close to you in a network topology sense. Network topology corresponds only very loosely with geography ”if you're in Philadelphia, a server in Canberra, Australia, is likely to be farther than one in Boston, but the Boston server might be closer than one in New York City, depending on how your network links work.
If the time server list indicates that a server's operators want to be notified before you use the server, be sure to do so. You might also want to investigate time server options that might be less public, but closer to you. Many large organizations, including many Internet service providers (ISPs), operate time servers. You might therefore find a time server that's very close to you on the Internet. Consult your ISP, or your network manager if you want to set up a time server for a department in a larger organization.
If you buy a GPS time receiver or other external clock hardware, you can synchronize your system to it to become a stratum 1 time server. You'll need to install special drivers for the external clock hardware. These drivers make the hardware appear to be a device on the 127.127.0.0/16 network, so you can use an ordinary server option line, but point it to the appropriate IP address. You must consult the documentation for your device's Linux drivers for details. The NTP Web site includes a list of hardware product manufacturers at http://www.eecis.udel.edu/~ntp/hardware.html.
When you're done reconfiguring ntp.conf , you should restart the NTP server. This is usually done through a SysV startup script, as discussed in Chapter 4, Starting Servers. Unless your startup script calls ntpdate prior to starting ntpd , you won't see your system time change dramatically, even if it's off by a few minutes. Instead, NTP will wait a while as it receives multiple time checks, then either change the time quickly or adjust it more slowly to synchronize it with its own parent server's time. You can monitor its operations using ntpq , as discussed in the next section.
Monitoring NTP's Operations
Aside from watching the time with a program like xclock , the usual way to monitor NTP's operation is to use the ntpq program. You launch this program and then enter any of a large number of text-based commands at its prompt. The program then displays information in response to these commands. Some of the more important ntpq commands include the following:
The first time you configure NTP, whenever you reconfigure it, and possibly periodically thereafter, you may want to use ntpq to check that it's doing what you expect. Figure 10.1 shows ntpq in action on a server that's been running for some time. When you first run ntpq after starting ntpd , many of the fields will be blank or will hold dummy values (typically 0). Over the course of a minute or so, most of those fields should fill with values similar to those shown in Figure 10.1, but the plus signs and asterisks to the left of most of the entries in Figure 10.1 won't appear for several minutes because the server will take a while to determine which of the would-be peers is most reliable. Some other values will change over the course of several minutes, as well, and then stabilize. If you see an x to the left of a server name, you may want to consider removing it from your configuration, because chances are that server is seriously misconfigured.
Figure 10.1. The ntpq program lets you monitor NTP server activities.
If you notice your system time drifting or changing in some odd way, you may want to use ntpq to check your NTP server's configuration. It may have lost synchronization with a server because of a change in IP address or some permanent network connectivity problem. (A temporary network outage shouldn't create noticeable problems; the server will just switch to the local clock until the network comes back online.) If your system doesn't synchronize with any time server for several minutes after starting ntpd , you should investigate general network connectivity. Can you ping the remote server? Do you have a firewall in place that might block NTP queries? (You may need to reconfigure the firewall to pass through UDP port 123 packets, at least to and from the servers in question ”both yours and the remote servers.) Do you have authorization to use a remote server? (That server might use a firewall or an authentication key to keep out unwanted clients.)
Using an NTP Client Package
If you've configured an NTP server on one computer on your network to acquire its time from a remote system, you can install and configure NTP servers on all other systems on your network in much the same way, but point these computers to your first NTP server instead of to external servers. The result is that your entire network will generate relatively little in the way of Internet traffic related to NTP, although the entire network will be set to the correct time via local NTP queries. You'll get the full benefits of ntpd on each of the clients, even though most or all of them won't be used as servers. On a complex network, you might implement several strata of time servers yourself. For instance, you might run an NTP server on each subnet for the benefit of clients on that subnet, and have each of these subnet servers connect to a system on the subnet that's one closer to the Internet at large to obtain its own time. This design will minimize NTP-related network traffic within your own network.
For many systems, running ntpd is overkill. This program is designed to keep the time on an entire network synchronized to within a few milliseconds, and to keep the entire network's time set to well under a second of UTC. Furthermore, ntpd is designed to keep this time accurate constantly, with little drift from accuracy during the course of a day. Your needs might be more modest; for instance, you might not be concerned if the time on any given system drifts a few seconds each day. Furthermore, ntpd is a server, and as such poses a potential risk; a security-related bug could conceivably be found and exploited in ntpd , resulting in a potential vulnerability for all your systems, or at least all those that are exposed to the Internet at large. (In fact, such vulnerabilities have been found in ntpd in the past.) For these reasons, the ntpdate program may be useful in many situations. As noted earlier, the rdate program can be used in a similar manner, but it uses its own protocol and is less precise than is ntpdate .
To run ntpdate , you type its name followed by the name or IP address of the time server against which you want to synchronize your system's time. You can specify multiple time servers if you want the program to automatically select the best one. You can also include several optional parameters before the program name and the time server addresses:
When you run ntpdate to synchronize your clock with a server, the program reports various statistics, such as the stratum, offset, and delay associated with the server you contact. Unless you specify -q or there's an error, the program then either slews your clock's speed or sets the absolute time on your computer.
One common method of using ntpdate is to run it as a cron job. You might run it once an hour or once a day, for instance. This may be often enough for many purposes, and it can reduce network loads to run ntpdate on a periodic basis, as opposed to running ntpd constantly.