Configuring NTP
ITworld.com, UNIX IN THE ENTERPRISE --- 10/28/2004
Sandra Henry-Stocker
Setting up a Unix system to be an NTP client is generally straightforward. On those Unix platforms that include NTP in the default configuration, you may only need to make a few adjustments to NTP's default configuration file for the system to sync up to a reference time server(s) and keep good time. On a Solaris system, for example, this involves copying a prototype file and customizing it. You can insert the names or IP addresses of the time server(s) you have elected to use -- whether public NTP servers or NTP servers that you have set up on your local network -- or configure the system to receive broadcast time updates. Once a system has been configured, the NTP daemon will start whenever the system boots and run continuously in the background.
Configuration of NTP servers, on the other hand, can be simple or complex, depending on the options that you wish to use and how well you understand the NTP service.
Many Unix systems today ship with NTP software. These include Solaris, SCO, FreeBSD and Mac OS X. On some Linux systems, you will need to download and install a package, such as ntp-4.1.2-5.i386.rpm, to acquire NTP services.
Once configured, the NTP service requires little or no administration. New clients will have to be configured and an occasional verification of your time sources may be warranted, but the service otherwise runs unattended.
Boot-time NTP
If you only want to synchronize your systems at boot time, you can configure an ntpdate command in your start scripts. This will ensure that your system starts up with a reasonable clock setting. On a Solaris system, this might be done with a script like that shown below, installed as /etc/rc2.d/S73ntpdate.
------------------------------ cut here ------------------------------
#!/bin/sh
# # synchronize date to NTP server at start-up
/usr/sbin/ntpdate -s -b -p 8 -u 129.6.15.28 216.200.93.8
------------------------------ cut here ------------------------------
In this start script, we're synchronizing our system clock to publicly available time servers in the Washington, DC area. The options used in this command are as follows:
option means
-s divert logging output to syslogd
-b force time stepping instead of skewing
-p specify number of time samples to be obtained from the server
-u use an unprivileged port (this can be important if privileged ports are blocked by a firewall). NOTE: NTP uses port 123.
Notice that the ntpdate command in the script includes all the information that it needs to run, obviating the need to insert this information from the NTP configuration file.
On systems which boot from rc.conf files (such as FreeBSD and its derivatives), you would need to modify additional files to use NTP. For example, you would enable ntpdate in the /etc/rc.conf file by setting ntpdate_enable="YES". Arguments for the ntpdate command, including the server(s) you intend to obtain time information from need to be included in the ntpdate_flags line. These lines might look like this:
ntpdate_enable="YES"
ntpdate_flags="-b 129.6.15.28 216.200.93.8"
Using the ntpdate command on system boot will keep your system clocks in closer proximity and is generally a good idea. At the same time, for synchronization, using only boot time commands is of very limited utility. Many Unix systems run for months, even years, at a time without a reboot. Clocks that drift can become seriously ahead or behind after months or years.
Clock Setting via Cron Jobs
A root crontab entry might be used to synchronize clocks on an hourly basis. This practice can help keep clocks from becoming increasingly out of synch, but represents something of a brute force approach to synchronization due to the jumps backward and forward that might occur once an hour as rdate forces system clocks to adjust.
An entry like that shown below will run once an hour and obtain current time from the listed public NTP servers.
0 * * * * /usr/sbin/ntpdate -s -b -p 8 -u 129.6.15.28
Synchronization, Daemon Style
A continuously running NTP server is clearly the best choice if you want a highly accurate and disciplined clock.
On Solaris systems, the script that starts the NTP daemon is already in position within the /etc/rc2.d directory. It's called S74xntpd and does not need to be modified in any way for the NTP service to run. Instead, it looks for its configuration file (/etc/inet/ntp.conf) and, if it finds this file, starts the daemon. Therefore, to set up NTP, all you need to do is make sure the script finds the configuration file. This is easily done because two prototype files are included in the /etc/inet directory. One, /etc/inet/ntp.client, includes a single command -- multicastclient 224.0.0.1 -- and starts the client NTP service to receive multicast time messages. If this prototype file is copied to /etc/inet/ntp.conf, the system will start a multicast NTP client daemon whenever it is rebooted.
Before you run off and set up your ntp.conf file, you should understand that an NTP client can be set up to work in any of three basic modes. A "normal" NTP client (e.g., an isolated system which needs to keep accurate time) is set up with the "server" keyword. This keyword identifies the time sources that the client will use. Alternately, a client can be set up to receive (instead of request) time updates with a "broadcastclient" or "multicastclient" keyword. Each of these keywords causes the client to listen for time updates from NTP servers.
To set up a normal NTP client, you would use server lines that look like this:
server 129.6.15.28
server 216.200.93.8
server 64.236.96.53
Each of these lines identifies a time server to which the client will send time requests. The NTP daemon on the client will then filter the responses and, from them, determine the most accurate time.
NOTE: It's a good idea to include more than one server line into an NTP client's configuration file to allow the client to disregard time responses that appear to be significantly out of line with the other responses. If you have greater confidence in one of the time servers listed in your configuration file, you can attach a "prefer" keyword to any of the servers listed. However, a preferred time source will be used only if it falls within a certain window of accuracy determined by your NTP daemon.
server 129.6.15.28 prefer
server 216.200.93.8
server 64.236.96.53
Broadcast/Multicast NTP Clients
A broadcast or multicast NTP client listens for NTP packets from, as you would expect, a broadcast or multicast NTP server. For such a client, the server lines shown above are not used. Instead, a single line is used in the ntp.conf file. This line, included in the ntp.client prototype file, identifies the client as a multicast client:
multicastclient 224.0.1.1
The address shown (224.0.1.1) is the multicast address reserved for NTP.
To use NTP in multicast mode, you need to provide a multicast server. While this isn't necessarily difficult, many more options exist for defining NTP servers and a bit more work must be done to get even the most basic server running.
Setting Up an NTP Server
Fortunately for Solaris sysadmins, a prototype NTP server file is also included in the /etc/inet directory. The file, /etc/inet/ntp.server, serves a template for setting up an NTP server. If you copy this file to /etc/inet/ntp.conf and then customize it to reflect the proper settings for your network, you will end up with an NTP server that will be started by the same script that starts the NTP client daemon.
Once configured as a broadcast or multicast server, an NTP server daemon will issue periodic time updates to its broadcast or multicast clients. To understand how this works, let's take a closer look at the ntp.server file.
The ntp.server File
The top 50 lines or so of this prototype file are comments that provide information on the syntax of the operative lines. The most important line of this file is the server line. The initial server line will look like this:
server 127.127.XType.0 prefer
If you want to set up NTP for synchronization purposes only and are unconcerned with whether or not the system clocks are accurate with respect to the atomic clocks, you can configure this line to look like this:
server 127.127.1.0 prefer
The third octet in this IP address, the "1", indicates that you are electing to use a reference clock driver of type "undisciplined local clock". This simply means your system clock. This setting is intended for isolated networks where no external source of synchronization is available. The 127.127.1.0 IP address is a type of loopback (as are all IP addresses in the 127.127.x.x range), indicating that this NTP server will use its own clock as a time reference and will make no requests to external time sources. NTP clients using this server for time information should use the multicastclient keyword as shown below. The 127.127.1.0 loopback can also be used on networks where real time is unimportant, but synchronization is critical.
multicastclient 224.0.1.1
If you want your NTP server to obtain time updates from external servers, add server lines like these (the same as those shown earlier in the column):
server 129.6.15.28 prefer
server 216.200.93.8
server 64.236.96.53
NTP servers are usually NTP clients as well. By deriving accurate time from highly accurate (i.e., low stratum) servers, your servers are a better source of time for your clients.
Many sysadmins favor the use of broadcast/multicast messages for NTP because this limits the amount of NTP traffic on a network. Instead of having numerous NTP clients individually requesting time updates from NTP servers, the servers periodically send out the updates that can be received by all NTP clients simultaneously. Network traffic is only one consideration in setting up NTP, however, and the overall savings in network bandwidth is relatively small because NTP is a lightweight protocol, using small, infrequent packets to distribute time updates. The decision of whether or not to configure your NTP servers and clients to use broadcast/multicast or normal (request) mode should depend more heavily on how reliably broadcast/multicast transmissions traverse your network and are received by your intended clients.
The decision to configure your clients to get time updates from local or remote time sources, on the other hand, can make a significant difference in how well NTP works for you. While you may be tempted to synchronize all of your clients to a public time server, instead of setting up an internal time server, this will not result in optimum synchronization. Recommended practice is to configure one to three local NTP servers, each of which receives time updates from different external time sources. The remainder of the systems on your network would then configured to obtain time information from these internal time servers, whether through requests or broadcasts.
References
There are many good sources of information on NTP and much more to be known and understood about how this time accuracy and synchronization service works. I heartily recommend the following references.
From the source:
http://www.ntp.org/
http://www.eecis.udel.edu/~mills/ntp/html/index.html
From Sun's blueprint series, this 3-part white paper:
http://www.sun.com/blueprints/0701/NTP.pdf
http://www.sun.com/blueprints/0801/NTPpt2.pdf
http://www.sun.com/blueprints/0901/NTPpt3.pdf
Sandra Henry-Stocker has been administering Unix systems for nearly 18 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She currently works for TeleCommunication Systems, a wireless communications company, in Annapolis, Maryland, where no one else necessarily shares any of her opinions. She lives with her second family on a small farm on Maryland's Eastern Shore. Send comments and suggestions to mailto:sstocker@itworld.com.