Hack22.Synchronize Your Watches


Hack 22. Synchronize Your Watches!

A simple NTP service that saves you hours of headaches can be set up in minutes.

The Network Time Protocol (NTP) is a service that seeks to synchronize the clocks of all its clients. An NTP daemon runs on a server, synchronizes its local system's clock with a public NTP server, and then serves as a time host so clients on the local network, including desktop PCs, can synchronize their clocks.

The number one reason to do this applies to environments of all sizes, and that reason is to enable you to easily correlate data in the logfiles on your systems. (It's also a convenient way to ensure that your coworkers meet you for lunch at the right time.) Even if you have centralized logging, there may be applications that only log locally, and any localized audit daemons, sar configurations, and login records kept in utmp and wtmp data files need to be kept in sync so that your troubleshooting or postmortem investigations don't begin with a list of hosts and their time offsets from the log server. You should also know that a central log host running Linux and running the syslogd daemon records a timestamp in the logfiles that corresponds to the time that the message was received, according to its local time, so that it can at least keep some semblance of order in its own logs.

Further encouragement to use an NTP service for your hosts will come from anyone who has ever had to maintain NFS servers and clients in an environment that does not synchronize time across the hosts. This can cause major issues with NFS, resulting in inexplicable "stale file handle" messages and mysterious make command errors stating that some required file has a "modification time in the future."

Now that you're convinced that having an NTP service is the right thing to do, let's move on to configuring a simple NTP server, and configuring your clients to use it.

First, you should make sure that you have the ntpd package installed. SUSE, Fedora, Red Hat, Mandrake, Debian, and all Debian variants that I've seen (including Ubuntu and Linspire) include ntpd. Red Hatbased systems even include it for minimal server installations. The configuration file for the server daemon is /etc/ntpd.conf, so let's start there by having a look at a barebones configuration:

 ## Default rules for all connections restrict default nomodify notrap noquery ## Allow full access to the local host restrict 127.0.0.1 ## Our client subnet restrict 192.168.42.0 mask 255.255.255.0 nomodify notrap # Our timeservers server ntp.cs.princeton.edu server clock.linuxshell.net server ntp0.cornell.edu 

OK, this is enough to get us started. The first line is a list of configuration keywords. The first two, restrict and default, define this line as the default access rule for all connections. The next three disallow remote hosts to modify the local server's configuration (nomodify), deny special ntpdq trap messages (notrap), and deny ntpdq/ntpdc queries to this server (noquery). Note that the noquery option is specific to queries regarding the status of the server itself, not the time: time queries are unaffected by that option.

All those restrictions may seem to make setting up the server pretty useless, but just remember it's a default rule that will be overridden by rules further down in the file.

The next line of the file, restrict 127.0.0.1, allows full access to the local hostand no, that's not a typo on my part. If you've never studied the ntpd.conf file, it looks weird to see a line starting with restrict that ultimately gives full access to the target of the rule. However, the way that the server reads the file is that it matches up incoming connections with all of the restrict statements, in the order they appear in the file. The keyword restrict is followed by a hostname, IP address, or the keyword default, followed by whatever restrictive flags you deem necessary. The absence of these flags means there are no restrictions, which is why the above line gives full access to the local host!

The next uncommented line gives access to our local subnet (192.168.42.0), so that users on this subnet can use this machine as their time server but cannot perform actions of any kind on the service itself.

The next three (uncommented) lines in the file are the servers that the local NTP server will trust for purposes of synchronizing the local clock. There are thousands of publicly available time servers worldwide, so consult one of the many lists online, find a few that are geographically close to you, and use them. You should be able to find a list by browsing the ISC web site, which maintains information about time server lists at http://ntp.isc.org/bin/view/Servers/WebHome. Do not put IP addresses in for the servers! As sites evolve, inevitably they incur some alterations in how networking works, how IP blocks are subnetted, and the like. An IP address change at Cornell University isn't something you should be concerned with, and you won't have to be if you use hostnames instead of IP addresses, because sites generally take care to make sure that packets bound for ntp0.cornell.edu get there regardless of the IP address of that server at the time.

3.4.1. Hey! My Servers Are Gone!

It happens. Maybe you've lost connectivity to the outside world. Maybe you picked three NTP servers that are at the same site (a bad idea) and they're all down. Regardless, you have clients to serve, and you need to tell them something. Enter the magical "fudge" statement:

 server 127.127.1.0 fudge 127.127.1.0 stratum 10 

Here, we enter the IP address of the local system's clock in the server line and then "fudge" its priority to stratum 10. All time servers are automatically assigned strata values based on their distance from the time source. Many of the public time servers are stratum 2 or 3 time servers. That means that the only way our local NTP daemon is ever going to use a stratum 10 time server is if it's the only one available. Most Linux distributions, and many other Unix variants, supply you with a default ntp.conf file that has this bit of configuration wisdom already uncommented. It's safe to leave it uncommented, and doing so will mean that you don't have to worry about NTP if you lose outside connectivity or if you don't catch a hiccup in time server availability right away.

3.4.2. See Also

  • Very detailed NTP documentation by the creator of NTP, David Mills: http://www.eecis.udel.edu/~mills/ntp/html/index.html



Linux Server Hacks (Vol. 2)
BSD Sockets Programming from a Multi-Language Perspective (Programming Series)
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 162
Authors: M. Tim Jones

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net