The built-in clocks of most personal computers are notoriously inaccurate. Even newer models run fast or slow by several seconds, sometimes whole minutes each day. Yet for quite some time now, I've been used to my computers always displaying the time, accurate to the second. Cool, you say, the author is a mad perfectionist; but what's the point? Is there a practical use, or need, for keeping your computers' clocks accurate?
When all you have is a simple computer that you use to browse the Web occasionally, it is indeed irrelevant whether your computer's clock shows the proper time. However, when you have several computers interacting via a network, synchronization becomes important. When you save a file to a network file server, you want the file's time and date stamp to mean the same thing on both systems. Even more importantly, some cooperative software packages actually depend on the assumption that all participating computers have the same time.
To solve this problem, you need to synchronize all the computers on the network to a single host. This can be accomplished in a variety of ways, depending on the operating systems in use and the software packages installed. It doesn't matter if the computers don't actually display an accurate time; what is important is that they always display the same time, and shared network services will operate properly.
Going one step further, it is also possible to synchronize your computers to an accurate external time source. For many years, software packages have been available that use your modem to connect to a well-known time service (for example, the time service of the U.S. Naval Observatory) to get the current time. Now it is also possible to do this via the Internet. The most comprehensive solution for this is provided by the Network Time Protocol (NTP).
Accurate timekeeping has been an important function ever since the dawn of Internet software development. Therefore, in addition to the deluxe solution represented by NTP, several other solutions exist on UNIX systems that provide certain types of timekeeping functionality.
As you surely know (who doesn't, in the year of the infamous Y2K problem?) PC-compatible computers have an internal CMOS clock . This is a battery-powered, low-power consumption clock device that keeps the time (and, incidentally, many other permanent BIOS configuration settings) when the computer is turned off. When the computer is turned on, the computer's operating system reads the time from the CMOS clock and sets the clock if necessary (for instance, in response to user commands).
Under MS-DOS, the CMOS clock is updated if you set the time with the date or time commands, or through the Windows Control Panel or clock utility.
Under Linux, the situation is different. The operating system maintains its own system time . The initial date and time is loaded from the CMOS clock when the operating system boots. The date and time can be set together using the date command. For example, to set the date and time to April 18, 1999, 01:20:20, you'd type (as the root user):
# date 041801201999.20 Sun Apr 18 01:20:20 EDT 1999
An important difference between MS-DOS and Linux is that the date command does not set the CMOS clock! To do so, you must use the hwclock command. (Note that on many distributions, especially older versions, the command is called clock.)
The hwclock command, in addition to being capable of setting and querying the CMOS clock, can also perform translations between local time and Universal Coordinated Time (Greenwich Mean Time). Customarily on UNIX systems, the hardware clock runs on UTC. However, if your computer can dual boot Linux and DOS (or another operating system) you might want to use local time on the hardware clock, because that's what DOS understands.
A particularly useful function of the hwclock utility is its capability to periodically update the hardware clock to compensate for drift. When you set the clock using hwclock, the program can save a calibration value to a special file. When it is later invoked with the appropriate command-line options, it can use the value found in this file to adjust the clock. The reason why this function is so useful is that although PC clocks are rarely accurate, their inaccuracy is systematic and predictable.
All UNIX systems provide simple Internet time services that can be used by other computers to update their clocks. To see for yourself, try the following:
$ telnet localhost daytime Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Sun Apr 18 01:10:19 1999 Connection closed by foreign host.
In addition to responding on the daytime port (port 13), some systems also provide a time service on port 37, the time port. When you connect to this port (if a server is available) you receive a binary response consisting of four binary bytes; these represent the current time and date in a compact machine-readable format.
The NTP is a protocol specifically developed for synchronizing computer clocks across an unreliable network such as the Internet. Synchronization is accomplished by connecting to NTP servers that serve the correct time. These servers, in turn, connect to other servers until you reach stratum 1 servers, which have their own high-precision clock hardware (for example, atomic clocks or GPS receivers). Such stratum 1 servers are operated by many entities that also provide stratum 2 NTP servers as a public service, including government agencies in the United States, Canada, and elsewhere (see Figure 14.1.)
FIGURE 14.1 The NTP server hierarchy.
It is also possible to use the NTP on a system that is not permanently connected to the Internet. An NTP server can be installed even on a computer that has no special clock hardware. Other computers can then be synchronized to this server. The server's clock can be kept accurate using the hwclock command or the NTP server's own capability to periodically adjust the clock for drift.
The software tool that is the de facto standard used for implementing NTP services is the NTP daemon and associated tools. This tool can be used to synchronize a computer using a high-precision clock or external servers; it can also be used on standalone systems with no such time reference and still keep accurate time.
The NTP server (usually under the name xntp) is found on the CD-ROMs of many a Linux distribution. This is certainly the case if you're using the CD-ROM attached to this book. However, if you do not have a copy, or if you want to install the latest version, it can be obtained via the Web ( http://www.ntp.org/). The software is distributed in source form, so it will be necessary to recompile and install the code before it becomes usable.
After the NTP software is installed, you'll have to ensure that it is started when the system is booted. This is accomplished by modifying your system startup files.
On my test system, the NTP daemon has been installed along with other Caldera OpenLinux components. This daemon does not need to be set up for autostart via LISA; when I rebooted the system, xntpd was one of the daemons already running in the background.
The most common mode of operation of the NTP daemon is when it's used to synchronize your server to other servers on the Internet and let other machines on your network, in turn, synchronize themselves to your server.
This is accomplished by preparing the appropriate configuration file for NTP. This file, usually located in /etc/ntp.conf, defines how the NTP daemon will behave, what other servers it will contact during its operation, and what computers it will accept incoming connection requests from.
The NTP daemon has a very large number of complex configuration options; however, for simple operation, all you really need are server and restrict lines in the configuration file. A server line defines a system that your NTP server can contact for accurate time. A restrict line defines what privileges other hosts have when connecting to your server.
That said, you cannot arbitrarily name a server in your NTP configuration file and expect it to work. First, and most obvious, the server you name must actually be running an NTP server, and it must be a system you can reach via the Internet. Second, it must be a server that you have permission to access! Most stratum 1 servers are not publicly accessible; however, many stratum 2 servers are, and it is best to find two or more such servers for synchronizing your clocks. Third, the server you pick should be one that is relatively nearby in terms of network hops, so as to minimize network latency, which may affect the accuracy of your clock settings.
The NTP Web page contains links to many public NTP servers. Note that the operators of some of these servers expect that you send them a courtesy email when you begin using their service.
I set up my test system to synchronize with two external NTP servers. Both of these servers are stratum 2 servers that are relatively "close" to my LAN. The first server is operated by Environment Canada in Montreal, and it is nine network hops from here. The second server, operated by Wang in the United States, is a bit further away, about 12 network hops.
My NTP configuration file, /etc/ntp.conf, contains the following entries:
server www1.cmc.ec.gc.ca server ticktock.wang.com restrict default notrust lowpriotrap nopeer nomodify restrict 18.104.22.168 mask 255.255.255.255 nopeer nomodify restrict 22.214.171.124 mask 255.255.255.255 nopeer nomodify restrict 192.168.1.0 mask 255.255.255.0 # local hosts restrict 127.0.0.1 mask 255.255.255.255 # local config
The two server lines identify the two NTP servers. The restrict lines that follow ensure that only authorized hosts can access my NTP server. In particular, the first line sets the default policy, namely that no unauthorized host is allowed to connect to my server for any NTP function. Next, the two remote servers are listed, in order to enable synchronizing my server's clock from them. The last two restrict lines allow local machines on my network to connect to the server and perform any function.
As is common with UNIX-style configuration files, the pound sign ( #) marks the beginning of a comment; anything after the pound sign up to the end of the line is ignored when the configuration file is being processed.
To ensure that these new settings take effect, I killed the xntpd server and restarted it by typing xntpd on the command line (while logged on as the root user of course).
Perhaps you don't have a permanent Internet connection and you're not about to invest a considerable sum just to keep your computers' clocks synchronized. Fortunately this is not necessary. You can run an NTP server without an external connection and still use it as a time reference for other machines on your network.
This mode of operation is possible because the NTP software contains several drivers for different hardware clocks. These include a driver for the local system clock. Setting up a driver for a local hardware clock is accomplished through a hack--a phony network address is used to identify the hardware device as an NTP "server." These phony addresses are in the form of 127.127.t.u where t identifies the type of the device, and u is a serial number between 0 and 3, which is used to distinguish multiple devices of identical type from one another.
The type identifier for your local system clock is 1. Therefore, the server address for the local system clock will be 127.127.1.0.
To set up my test system for operation with the local system clock, I modified my /etc/ntp.conf file to read as follows:
server 127.127.1.0 restrict default notrust lowpriotrap nopeer nomodify restrict 192.168.1.0 mask 255.255.255.0 # local hosts restrict 127.0.0.1 mask 255.0.0.0 # local config
To make sure these settings take effect, once again I had to restart the xntpd server.
Although installing the NTP server isn't terribly difficult, sometimes an even simpler solution is available. You can use the ntpdate command for synchronizing your Linux machine if the following conditions are true:
Note that the second of these two conditions doesn't mean that the machine cannot be accessed for synchronization purposes; it simply means that it will not be accessed using the NTP protocol. Other methods (such as connecting to the daytime port, as shown earlier in this chapter) will still work.
The ntpdate command accepts an Internet hostname on its command line. For instance, typing ntpdate host.ntp.sys would synchronize your system clock from a host named host.ntp.sys if such a host existed and was equipped with a publicly accessible NTP server.
The best way to use the ntpdate command is to invoke it periodically. Chapter 18, "Scheduled Tasks, Scripts, and Programming," contains more information on the use of the crontab facility for this purpose. When you run ntpdate this way, it is a good idea to use the 3s command-line switch, which directs all ntpdate output to the system log (instead of being displayed interactively).
Once you have a Linux system that keeps accurate time, you can synchronize other hosts with it. If those other hosts are running versions of Microsoft Windows, there are several methods available for this purpose.
One time-honored synchronization method under DOS and Windows is the net time command. This, however, requires that the server you use for synchronization be a participant in Windows networking. This isn't necessarily the case if your server is a Linux computer. However, if you are using the Samba suite (see Chapter 13, "File Services for Windows: Samba") you can synchronize a Windows machine using the following command:
C:\>net time \\linux /set Current time at \\linux is 4/18/99 3:45 PM The current local clock is 4/18/99 3:45 PM Do you want to set the local computer's time to match the time at \\linux? (Y/N) [Y]: y The command completed successfully.
Needless to say, you should substitute the Samba name (NetBIOS name) of the actual server that you're using for synchronization in place of \\linux, which is the Samba name I assigned to my test Linux system.
When you're using this command from a batch file, for instance, you can also append the /y command-line switch, in order to avoid the confirmation question.
Note that using the net time command does not require an NTP server on the other end; you can synchronize your workstation's clock to any computer that participates in Windows networking.
On Windows NT systems, there's another tool available for accurate timekeeping. The TimeServ time service is a freely available tool, also distributed as part of the Windows NT Resource Kit. This tool implements a Windows NT service that runs in the background, much like xntpd on Linux systems. It can synchronize your Windows NT computer to many types of sources, including NTP servers.
Other third-party tools also exist that can be used on DOS or Windows systems to synchronize your system clock to a remote UNIX server.
Keeping system clocks accurately synchronized on your network is not merely a perfectionist's mad dream; many software packages expect that networked computers keep more or less the same time when they interoperate.
Linux maintains a system clock that is separate from your computer's hardware CMOS clock. Often, the hardware clock is set to UTC, although in order to maintain compatibility with other operating systems on a multiboot computer, setting it to the local time is also possible.
The system clock can be set using the date command. The hardware clock can be set or queried using hwclock. This command can also be used to periodically adjust the hardware clock in order to compensate for drift.
A more sophisticated solution is to use NTP, the Network Time Protocol. With NTP server software, it is possible to synchronize your Linux system to timekeeping hosts over the Internet. It is also possible to run your Linux system as a server to which other hosts can synchronize themselves. You can run NTP server software even without a permanent Internet connection; in this case, the time source is your computer's local clock or special time hardware.
If your Linux host is not expected to operate as an NTP server, but has access to another (local or remote) NTP server, you can use the ntpdate command for synchronization instead of installing the full NTP server.
Windows workstations on your network can be synchronized with a Linux host in a variety of ways. These include the net time command (which requires a NetBIOS compatible server on the other end, such as Samba for Linux), the TimeServ service for Windows NT, and other third-party tools.
For additional information on topics discussed in this chapter, please refer to the following manual pages.
© Copyright 1999, Macmillan Computer Publishing. All rights reserved.