NTP
One problem with logging events over a network is that differences in system clocks can make correlating events on different systems very difficult. It is not unusual for the clock on a system to have drifted considerably. Thus, there may be discrepancies among timestamps for the same events listed in different log files. Fortunately, there is a protocol you can use to synchronize the clocks on your system. Network Time Protocol (NTP) provides a mechanism so that one system can compare and adjust its clock to match another system's clock. Ideally, you should have access to a very accurate clock as your starting point. In practice, you will have three choices. The best choice is an authoritative reference clock. These devices range from atomic clocks to time servers that set their clocks based on time signals from radios or GPS satellites. The next best source is from a system that gets its clock setting from one of these reference clocks. Such systems are referred to as stratum 1 servers. If you can't get your signal from a stratum 1 server, the next best choice is to get it from a system that does, a stratum 2 server. As you might guess, there is a whole hierarchy of servers with the stratum number incrementing with each step you take away from a reference clock. There are public time servers available on the Internet with fairly low stratum numbers that you can coordinate to occasionally, but courtesy dictates that you ask before using these systems. Finally, if you are not attached to the Internet, you can elect to simply designate one of your systems as the master system and coordinate all your other systems to that system. Your clocks won't be very accurate, but they will be fairly consistent, and you will be able to compare system logs. NTP works in one of several ways. You can set up a server to broadcast time messages periodically. Clients then listen for these broadcasts and adjust their clocks accordingly. Alternately, the server can be queried by the client. NTP uses UDP, typically port 123. Over the years, NTP has gone through several versions. Version 4 is the current one, but Version 3 is probably more commonly used at this point. There is also a lightweight time protocol, Simple Network Time Protocol (SNTP), used by clients that need less accuracy. SNTP is interoperable with NTP. For Unix systems, the most common implementation is ntpd, formerly xntpd, which is described here. This is actually a collection of related programs including the daemon ntpd and support programs such as ntpq, ntpdate, and ntptrace. You'll want to start ntpd automatically each time you boot your system. ntpd uses a configuration file, /etc/ntp.conf, to control its operation. This configuration file can get quite complicated depending on what you want to do, but a basic configuration file is fairly simple. Here is a simple three-line example:server 205.153.60.20 logconfig =syncevents +peerevents +sysevents +allclock driftfile /etc/ntp.drift
The first line identifies the server. This is the minimum you'll need. The second establishes which events will be logged. The last line identifies a drift file. This is used by ntpd to store information about how the clock on the system drifts. If ntpd is stopped and restarted, it can use the old drift information to help keep the clock aligned rather than waiting to calculate new drift information. One minor warning about ntpd is in order. If your clock is too far off, ntpd will not reset it. (Among other things, this prevents failures from propagating throughout a network.) This is rarely a problem with computers, but it is not unusual to have a networking device whose clock has never been set. Just remember that you may need to manually set your clock to something reasonable before you run ntpd. ntpdate can be used to do a onetime clock set:
bsd2# ntpdate 205.153.60.20 4 Jan 10:07:36 ntpdate[13360]: step time server 205.153.60.20 offset 11.567081 sec
ntpdate cannot be used if ntpd is running, but there shouldn't be any need for it if that is the case. ntpq can be used to query servers about their state:
bsd2# ntpq -p 172.16.2.1 remote refid st t when poll reach delay offset jitter ============================================================================== *ntp.lander.edu .GPS. 1 u 18 64 173 5.000 -1.049 375.210 CHU_AUDIO(1) CHU_AUDIO(1) 7 - 34 64 177 0.000 0.000 125.020 172.16.3.3 0.0.0.0 16 - - 64 0 0.000 0.000 16000.0 172.16.2.2 0.0.0.0 16 u - 64 0 0.000 0.000 16000.0
In this example, we have queried a system for a list of its peers.ntptrace can be used to discover the chain of NTP servers, i.e., who gets their signal from whom:
bsd2# ntptrace 172.16.2.1 NLCisco.netlab.lander.edu: stratum 2, offset 0.009192, synch distance 0.00526 ntp.lander.edu: stratum 1, offset 0.007339, synch distance 0.00000, refid 'GPS '
Only two servers were involved in this example, but you should get the basic idea. Each of these tools has other features that are documented in their manpages. NTP can be an involved protocol if used to its fullest. Fortunately, a lot of documentation is available. Whatever you want -- information, software, a list of public NTP servers -- the best place to start is at http://www.eecis.udel.edu/~ntp. The work of Dave Mills and others, this is a remarkable site.