From: "Don Levey" <fedora-list@xxxxxxxxxxxxx>
> On Wed, 2004-03-03 at 18:56, Bevan C. Bennett wrote:
> > Don Levey wrote:
> >
> > > ntp.conf (some comments excised):
> > (other comments excised)
> >
> > Well, let's start with your .conf file and see what we can do...
> >
> > > 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
> > > fudge 127.127.1.0 stratum 10
> > > driftfile /etc/ntp/drift
> > > broadcastdelay 0.008
> > >
> > > keys /etc/ntp/keys
> >
> > This is all a little odd... you won't need the 192.168 line until you're
> > ready to broadcast (which you aren't doing).
> >
> > Try the following:
> > # /etc/ntp.conf test file
> > #
> > # be paranoid by default
> > restrict default ignore
> > # local clock of last resort
> > server 127.127.1.0
> > fudge 127.127.1.0 stratum 10
> > #
> > driftfile /etc/ntp/drift
> > #
> > # allow loopback ntpq connections
> > restrict 127.0.0.0 mask 255.0.0.0 nomodify
> > #
> > # servers servers servers
> > server 69.22.157.240
> > restrict 69.22.157.240 mask 255.255.255.255 nomodify notrap noquery
> > server ntp.ourconcord.net
> > restrict ntp.ourconcord.net mask 255.255.255.255 nomodify notrap noquery
> > server ntp-0.cso.uiuc.edu
> > restrict ntp-0.cso.uiuc.edu mask 255.255.255.255 nomodify notrap noquery
> >
> > Then try 'service ntpd restart' to start up ntpd, wait a minute or so,
> > and use 'ntpq -np' to see what's going on.
> >
>
> Hmm... I tried your test conf file, here's what I got:
> [root@davinci etc]# ntpq -np
> remote refid st t when poll reach delay offset
> jitter
>
============================================================================
==
> 127.127.1.0 127.127.1.0 10 l 44 64 1 0.000 0.000
> 0.008
> 69.22.157.240 0.0.0.0 16 u - 64 0 0.000 0.000
> 4000.00
>
> Looks like I'm not getting out and back?
> -Don
It looks like you have not waited out a couple minutes even. After a
minute and loose change you should know if it is reachable, though.
You can check that with:
[root@it ~]# ntpq -n -c peers;ntpq -n -c assoc
remote refid st t when poll reach delay offset
jitter
============================================================================
==
127.127.1.0 127.127.1.0 3 l 11 64 17 0.000 0.000
0.008
132.239.1.6 132.249.20.88 2 u 3 64 17 29.482 -12.287
0.550
+63.192.96.3 63.192.96.10 2 u 13 64 17 51.090 2.395
0.008
*164.67.62.194 .PSC. 1 u 11 64 17 26.581 0.058
0.074
ind assID status conf reach auth condition last_event cnt
===========================================================
1 1164 9014 yes yes none reject reachable 1
2 1165 9014 yes yes none reject reachable 1
3 1166 9414 yes yes none candidat reachable 1
4 1167 9614 yes yes none sys.peer reachable 1
If reach is no then you have troubles. Just why I don't know because
ntpdate uses the same ports pretty much the same way as ntpd itself.
I prefer to sit in "ntpq" and use the "assoc" and "peers" commands
more or less alternately to watch the system trying to synch up. It
takes several minutes for things to settle down. But "reach" should
get set pretty quickly.
(NOte that it took 17 polls to get to this status. That was almost 18
minutes. You must have patience IF reach increments each 64 seconds or
so.)
{^_^}
