NTP, ntpdate, and ISP-based firewall

[Kaj J. Niemi]

> restrict default ignore
> restrict 69.22.157.240 mask 255.255.255.255 nomodify notrap noquery
> restrict 127.0.0.1
> restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
> server 69.22.157.240
> server  ntp.ourconcord.net
> server  ntp-0.cso.uiuc.edu
> driftfile /etc/ntp/drift
> broadcastdelay  0.008
> keys            /etc/ntp/keys

You've got three server definitions but only one of them is relaxed. What
does "ntpq -np" (or "ntpq -n -c peers") tell you? If all you get back is
"connection refused" ntpd isn't running which usually means that the amount
of time needed to be synchronised is more than the limit (1000 s, iirc). On
the other hand if you get something like the example below, you've got timing
from two servers while the third is somewhere in the void.

% ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 212.226.226.1   .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
*192.26.119.7    192.36.144.23    2 u  465  512  377    7.779   11.173   0.810
+192.26.119.4    192.36.144.22    2 u  482  512  377    9.948    8.984   1.891

If you're concerned of getting the correct time on boot, you should
put the IP addresses of your time servers (one per line) in
/etc/ntp/step-tickers.

In /etc/ntp.conf the "netmask 255.255.255.255" statements are redundant,
"restrict 69.22.157.240 nomodify notrap noquery" should be the equivalent.

Are you using a firewall? The ntpd startup script attempts to punch holes
into RH-Lokkit-0-50-INPUT but that'll only work if the said chain is being
referenced in INPUT. /sbin/service iptables status should be your friend in
this case.

Hth.


// kaj