> 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
