OpenNTPd howto?

Bill Moran wmoran at potentialtech.com
Tue Jul 1 19:26:39 UTC 2008


In response to "B. Cook" <bcook at poughkeepsieschools.org>:
> 
> On Jul 1, 2008, at 1:21 PM, Bill Moran wrote:
> 
> > In response to B. Cook <bcook at poughkeepsieschools.org>:
> >
> >> Hello All,
> >>
> >> Not sure what I am missing, but I am.
> >>
> >> so I put openntpd on a machine (10.20.0.16)
> >>
> >> cat ntpd.conf | egrep -v ^#
> >>
> >> listen on 0.0.0.0
> >> server clock.nyc.he.net
> >>
> >> then start it and it looks like it does:
> >>
> >> USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN
> >> ADDRESS
> >> _ntp     ntpd       15751 4  udp4   10.20.0.16:55180
> >> 209.51.161.238:123
> >> _ntp     ntpd       15751 6  udp4   *:123                 *:*
> >>
> >>
> >> Strange thing one:
> >>
> >> root at core [/usr/local/etc]# 30 > ntpdate -b clock.nyc.he.net
> >>  1 Jul 12:43:52 ntpdate[48881]: the NTP socket is in use, exiting
> >>
> >> root at core [/usr/local/etc]# 31 > /usr/local/etc/rc.d/openntpd stop
> >> Stopping openntpd.
> >>
> >> root at core [/usr/local/etc]# 32 > ntpdate -b clock.nyc.he.net
> >>  1 Jul 12:49:57 ntpdate[70917]: step time server 209.51.161.238
> >> offset 358.732506 sec
> >>
> >> Why when it was running did it not update the clock on the server?
> >
> > It was working on it.  You should read up on NTP a bit so you  
> > understand
> > how it works.  NTP does not "set" the clock unless you explicitly tell
> > it to (I believe the -s switch in openntpd).  Instead, it speeds up or
> > slows down the clock to bring it into adjustment, which prevents  
> > software
> > from seeing a sudden and space-time fabric-ripping shift in time.
> >
> > If you let openntpd run for a while, possibly a few hours, you'd see  
> > the
> > time come in to sync.
> >
> >> From a different computer I can not get the time from the server
> >> running openntpd.
> >
> > What error do you get?  Run ntpdate -d on the other computer to see  
> > _why_
> > it's refusing to sync.  I would guess it's because the OpenNTPd server
> > knows that it's not in sync yet, and thus refuses to sync other  
> > machines.
> >
> > -- 
> > Bill Moran
> > http://www.potentialtech.com
> 
> Thanks for the clue to the answer.
> 
> Here is the output:
> 
> pmsbsdsrv# ntpdate -d 10.20.0.16
>   1 Jul 13:31:00 ntpdate[899]: ntpdate 4.2.0-a Sun Feb 24 16:32:49 UTC  
> 2008 (1)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> 10.20.0.16: Server dropped: strata too high
> server 10.20.0.16, port 123
> stratum 16, precision -21, leap 11, trust 000
> refid [10.20.0.16], delay 0.02599, dispersion 0.00000
> transmitted 4, in filter 4
> reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
> originate timestamp: cc14e855.037077ff  Tue, Jul  1 2008 13:31:01.013
> transmit timestamp:  cc14e855.14ea3cc5  Tue, Jul  1 2008 13:31:01.081
> filter delay:  0.02605  0.02600  0.02599  0.02599
>           0.00000  0.00000  0.00000  0.00000
> filter offset: -0.06838 -0.06845 -0.06845 -0.06845
>           0.000000 0.000000 0.000000 0.000000
> delay 0.02599, dispersion 0.00000
> offset -0.068452
> 
>   1 Jul 13:31:01 ntpdate[899]: no server suitable for synchronization  
> found

This is because the server is not in sync yet, therefore your client
doesn't trust it.  Notice the stratum is 16, which (I believe) is the
highest possible.

> What I would like to have is a time server that works like how I think  
> it works.  this 10.20.0.16 machine was updated and rebooted, and I was  
> installing two new machines today and saw it wasn't syncing..
>
> Is there a way to make a time server serve the time of the local  
> computer, and then every hour update the server from a time server?   
> Or just serve the time as soon as the server is enabled?

Don't use NTP if that's what you require.  Sounds like you want some
sort of Windows software, but see below.

> On the server I have done this:
> 
> # 30 > /usr/local/sbin/ntpd -s -d -f /usr/local/etc/ntpd.conf
> listening on 10.20.0.16
> ntp engine ready
> reply from 209.51.161.238: offset 0.005419 delay 0.016668, next query 6s
> reply from 209.51.161.238: offset 0.005236 delay 0.016233, next query 6s
> reply from 209.51.161.238: offset 0.005288 delay 0.015782, next query 9s
> peer 209.51.161.238 now valid
> reply from 209.51.161.238: offset 0.005271 delay 0.016006, next query 9s
> reply from 209.51.161.238: offset 0.005550 delay 0.015967, next query 7s
> reply from 209.51.161.238: offset 0.005616 delay 0.016308, next query 7s
> reply from 209.51.161.238: offset 0.005714 delay 0.015999, next query  
> 30s
> reply from 209.51.161.238: offset 0.005995 delay 0.016138, next query  
> 32s
> adjusting local clock by 0.005288s
> 
> but the client still sees this:
> 
> # ntpdate -d 10.20.0.16
>   1 Jul 15:09:14 ntpdate[1105]: ntpdate 4.2.0-a Sun Feb 24 16:32:49  
> UTC 2008 (1)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> receive(10.20.0.16)
> transmit(10.20.0.16)
> 10.20.0.16: Server dropped: Leap not in sync
> server 10.20.0.16, port 123
> stratum 2, precision -21, leap 11, trust 000
> refid [10.20.0.16], delay 0.02599, dispersion 0.00000
> transmitted 4, in filter 4
> reference time:    cc14feea.d26147ff  Tue, Jul  1 2008 15:07:22.821
> originate timestamp: cc14ff5a.7657d7ff  Tue, Jul  1 2008 15:09:14.462
> transmit timestamp:  cc14ff5a.9fabbfcc  Tue, Jul  1 2008 15:09:14.623
> filter delay:  0.02602  0.02600  0.02599  0.02599
>           0.00000  0.00000  0.00000  0.00000
> filter offset: -0.16169 -0.16162 -0.16163 -0.16162
>           0.000000 0.000000 0.000000 0.000000
> delay 0.02599, dispersion 0.00000
> offset -0.161631
> 
>   1 Jul 15:09:14 ntpdate[1105]: no server suitable for synchronization  
> found
> 
> it looks different/closer.. but clients still can not sync to it..

The server is still not confident that it's synchronized yet.

Again, I recommend you take a bit of time to read up on NTP and it's
design.  NTP specifically does NOT make any quick or drastic decisions.
If you just started OpenNTPd, it's not going to be confident in its own
time sync, and therefore clients won't trust it.

Give OpenNTPd some time to settle (perhaps a few hours, although 10 - 15
minutes seems to be enough in my experience) and it will consider itself
reliable and other client's will use it.

-- 
Bill Moran
http://www.potentialtech.com


More information about the freebsd-questions mailing list