setting up NTP server on 10.5.8

[mark2288]

Hey all,
I'm trying to set up an NTP server on a machine running Mac OS X 10.5.8 so machines on a local area network (not connected to the Internet) can sync their clocks.

I have had absolutely no luck in getting this to work.

Instructions here are for Mac OS X Server (I have no Network Time folder):
http://knol.google.com/k/dirk-h-schulz/time-synchronization-ntp-on-mac-os-x/2bcee0ik2900p/18#

Following the instructions at:
http://www.screaming-penguin.com/node/3246

I get a connection refused error when I run ntpq -p.

Any ideas?

 

[HenryAZ]

Hello,

I saw (and replied to) your earlier post, though I did not understand you were trying to make your OS X machine the ntp time source for your LAN.

I've never tried that, until tonight, but have it working as I type this. It took some poking around and learning myself some more about ntp configuration variables (because of how OS X restricts ntpd). I am using 10.6.2, though I would think this would apply also to 10.5.8, but could be wrong about this. I jumped right from 10.4.11 to SL.

First off, if you use Date & Time to configure/use time.apple.com as your ntp server, can you then run ntpq -p at the terminal and get valid output? If not, something is broken, I think. You have to tick the box to keep time set automatically, as this is how you start ntpd. You will get "connection refused" for ntpq -p for the first few seconds after it starts, depending on how remote your time source is. It must get a poll or two in.

Assuming you have a basic ntpd running this way, run the following from a terminal prompt:

ps -ax | grep ntp

and see what the ntpd command line is. This should point you to the config file. What I learned tonight is that OS X uses /etc/ntp-restrict.conf as the main config file, and includes /etc/ntp.conf from that, at least on SL. You can now modify /etc/ntp-restrict.conf, which does not get overwritten by Date & Time settings. The main thing you will want to do is add a line to permit your local network to sync with your OS X machine. Last match wins, so add the line right above the include line, and assuming your LAN is numbered 192.168.1.0/24, you would add a line like this:

restrict 192.168.1.0 mask 255.255.255.0

Now enter your ntp time source in Date & Time (either time.apple.com or enter your own, like pool.ntp.org), and tick the box to set time automatically, which will start the daemon.


My file /etc/ntp-restrict.conf:
# Access restrictions documented in ntp.conf(5) and
# http://support.ntp.org/bin/view/Support/AccessRestrictions
# Limit network machines to time queries only

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# localhost is unrestricted
restrict 127.0.0.1
restrict -6 ::1

# local lan is unrestricted
restrict 10.10.66.0 255.255.255.0

includefile /private/etc/ntp.conf

and ntpq -p on the SL machine:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+time-2.egr.unlv 66.45.62.14      4 u   31   64  373   46.514    0.440  22.011
+lennier.cc.vt.e 198.82.1.203     3 u   24   64  377  130.901   -7.627  23.281
*borzoi.hup.org  .GPS.            1 u   21   64  377    0.272   -1.645   2.624

I have one other machine syncing with the SL machine right now.

 

[HenryAZ]

It also dawned on me (yes I can be thick-headed), that even your OS X machine has no access to the Internet?

In that case use the following "server" in Date & Time as your ntp time source:

127.127.1.0

This will use the machine's local clock as the reference source. Of course your whole LAN will then be subject to the quality of the oscillator in your OS X machine.

 

[mark2288]

It also dawned on me (yes I can be thick-headed), that even your OS X machine has no access to the Internet?

In that case use the following "server" in Date & Time as your ntp time source:

127.127.1.0

This will use the machine's local clock as the reference source. Of course your whole LAN will then be subject to the quality of the oscillator in your OS X machine.

Many thanks! I just came back to this post after unsuccessfully trying many things. I will give this a shot and get back to you. Again, many thanks!

 

[mark2288]

The main thing you will want to do is add a line to permit your local network to sync with your OS X machine. Last match wins, so add the line right above the include line, and assuming your LAN is numbered 192.168.1.0/24, you would add a line like this:

restrict 192.168.1.0 mask 255.255.255.0

Hello,
So I modified my /etc/ntp-restrict.conf file with the following restrict line since my router assigns addresses 192.168.0.xxx

restrict 192.168.0.0 mask 255.255.255.0

Then in Date and Time I set my server to Set Date & Time Automatically from 127.127.0.1. Restarted the computer.

When I then try to run ntpq -p on the machine I just configured as a server (I have IP address 192.168.0.198), I get no output - it just hangs and I have to crtl+c to exit.

When I connect to another network that gives me IP addresses in a different range, ntpq -p gives me output that says I am getting my time from the local machine.

Thoughts? Thanks again for the help!

EDIT: I then configured another machine to sync that my NTP server machine via the Date and Time Settings. When connected to the network I unrestricted ntpq -p hangs again. Connecting to a different network that assigns IPs in a different range shows me the offset between the two machines, but no syncing occurs from what I gather.

 

[HenryAZ]

Hello,
So I modified my /etc/ntp-restrict.conf file with the following restrict line since my router assigns addresses 192.168.0.xxx

restrict 192.168.0.0 mask 255.255.255.0

Then in Date and Time I set my server to Set Date & Time Automatically from 127.127.0.1. Restarted the computer.

When I then try to run ntpq -p on the machine I just configured as a server (I have IP address 192.168.0.198), I get no output - it just hangs and I have to crtl+c to exit.

Perhaps could you try your "server" setup first without modifying ntp-restrict.conf. IOW, just get ntpd working locally and be able to query it with ntpq -p, locally. Give it a minute or so before querying. This much has to work first.

Then, when that works, modify ntp-restrict.conf to permit access to your LAN.

 

[mark2288]

Perhaps could you try your "server" setup first without modifying ntp-restrict.conf. IOW, just get ntpd working locally and be able to query it with ntpq -p, locally. Give it a minute or so before querying. This much has to work first.

Then, when that works, modify ntp-restrict.conf to permit access to your LAN.

Think I found the issue. My router was blocking the NTP query!

http://portforward.com/english/routers/port_forwarding/Dlink/DIR-655/NTP.htm

Going to try that now and see what happens!

 

[mark2288]

HenryAZ - thanks again for the help and advice.

I have a few questions for you though as I am running into some issues...

1. Using ps -ax | grep ntp to figure out what file to modify. On both a Leopard and SL machine I get:

ps -ax | grep ntp
229 ?? 0:00.02 /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift
256 ttys000 0:00.00 grep ntp

Your post says this tells me what file to edit, but you go on to edit /etc/ntp-restrict.conf instead of /private/etc/ntp-restrict.conf. Which one should I go with?

2. You suggest I use 127.127.1.0 as the "time source" on my NTP server so that I don't need to be on the Internet to get synced. But in the restrict file, only 127.0.0.1 is unrestricted. Does this matter? Should I also add the line: restrict 127.0.0.1?

3. General troubleshooting - I'm doing this now on a SL machine so I can follow your instructions exactly to see if I can get it working. The first step I do (skipping modifying ntp-restrict.conf) is to have my server sync to 127.127.1.0 and then see if I can get a NTP reply when I query the server. I set that, uncheck, re-check the set time/date automatically, restart the computer and give it a second and then run ntpq -p and get "No association ID's returned." Changing the address to 127.0.0.1 (see question #2) gives me....

remote refid st t when poll reach delay offset jitter
==============================================================================
localhost .INIT. 16 l - 64 0 0.000 0.000 0.000


The value of 0 for reach means the NTP server isn't responding.

Thoughts? Thanks again for all the help. I feel like I'm just screwing up something little here.

 

[HenryAZ]

1. I was not being precise, and being lazy not to type out the correct path. /private/etc/ntp-restrict.conf is the correct path to the file. These files are traditionally in /etc, but OS X links the entire /etc directory to /private/etc, so it is the same file.

2. The restrict configuration variables (in /private/etc/ntp-restrict.conf) deal with network addresses, as they appear as the source address in packet headers. 127.0.0.1 is the correct address to appear there, as it unrestricts packets coming from the localhost address. The address you enter in Date & Time as your time source is internal to NTP. This is how NTP refers to reference clocks (127.127.clock#.x), and does not appear as a source address in the UDP packet header. So, no, 127.127.1.0 does not need to appear in /private/etc/ntp-restrict.conf. [NTP reference clock #1 is the local hardware clock; NTP also includes support for some 3 dozen other reference clocks, such as GPS receivers, WWV radios, etc].

3. Just FYI, you do not have to reboot the machine to restart NTP. Making any change in Date & Time will do it; I usually just uncheck and then recheck the box to set date/time automatically. Once you get it working, you will be able to see this by the output of ntpq -p. Everthing in that output resets when you make any change (polls restart from scratch). I also feel like we're missing something little. Perhaps someone else can see it and chime in. On my SL machine, I set the time source to 127.127.1.0 (local clock), DO NOT modify /private/etc/ntp-restrict.conf, and then wait a minute (not a second) to run ntpq -p. You have to be patient here, as it can take a while for it to get polling on a new source.

It will never work by setting your time source to 127.0.0.1. Your ntpq -p output confirms that, as you observed. The reach never climbs off zero, and the stratum is 16, both of which indicate no contact with the "source".

HenryAZ - thanks again for the help and advice.

I have a few questions for you though as I am running into some issues...

1. Using ps -ax | grep ntp to figure out what file to modify. On both a Leopard and SL machine I get:

ps -ax | grep ntp
229 ?? 0:00.02 /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift
256 ttys000 0:00.00 grep ntp

Your post says this tells me what file to edit, but you go on to edit /etc/ntp-restrict.conf instead of /private/etc/ntp-restrict.conf. Which one should I go with?

2. You suggest I use 127.127.1.0 as the "time source" on my NTP server so that I don't need to be on the Internet to get synced. But in the restrict file, only 127.0.0.1 is unrestricted. Does this matter? Should I also add the line: restrict 127.0.0.1?

3. General troubleshooting - I'm doing this now on a SL machine so I can follow your instructions exactly to see if I can get it working. The first step I do (skipping modifying ntp-restrict.conf) is to have my server sync to 127.127.1.0 and then see if I can get a NTP reply when I query the server. I set that, uncheck, re-check the set time/date automatically, restart the computer and give it a second and then run ntpq -p and get "No association ID's returned." Changing the address to 127.0.0.1 (see question #2) gives me....

remote refid st t when poll reach delay offset jitter
==============================================================================
localhost .INIT. 16 l - 64 0 0.000 0.000 0.000


The value of 0 for reach means the NTP server isn't responding.

Thoughts? Thanks again for all the help. I feel like I'm just screwing up something little here.

 

[mark2288]

On my SL machine, I set the time source to 127.127.1.0 (local clock), DO NOT modify /private/etc/ntp-restrict.conf, and then wait a minute (not a second) to run ntpq -p. You have to be patient here, as it can take a while for it to get polling on a new source.

Seems my restarting and then not waiting a minute was contributing to the problem. Just changed the server's reference clock to 127.127.1.0, waited a minute and then....

ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================
*LOCAL(0) .LOCL. 5 l 9 64 77 0.000 0.000 0.001

That seems right for the server querying itself no? Going to now modify the restrict file - make sure the server still works and then try another machine...!!!

Thanks again for the help!

 

[HenryAZ]

Yes, that reference clock uses the local hardware clock as the time source, and the output of nptq -p look good. Congrats! I'm glad you got it working.

Seems my restarting and then not waiting a minute was contributing to the problem. Just changed the server's reference clock to 127.127.1.0, waited a minute and then....

ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================
*LOCAL(0) .LOCL. 5 l 9 64 77 0.000 0.000 0.001

That seems right for the server querying itself no? Going to now modify the restrict file - make sure the server still works and then try another machine...!!!

Thanks again for the help!

 

[mark2288]

Yes, that reference clock uses the local hardware clock as the time source, and the output of nptq -p look good. Congrats! I'm glad you got it working.

Thanks again! It does seem like restarting and running ntpq immediately was what was getting me. Just changed the ntp-restrict file and set up a client by changing the Set Date and Time Automatically to my server's sharing name and ONE MINUTE LA

ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================
*nope.local LOCAL(0) 6 u 42 64 377 20.628 8.126 16.725

from http://tech.kulish.com/content/ntp-ntpq-output-explained

reach: indicates success/failure to reach source, 377 all attempts successful
delay: indicates the roundtrip time, in milliseconds, to receive a reply
offset: indicates the time difference, in milliseconds, between the client server and source
disp/jitter: indicates the difference, in milliseconds, between two samples

Am I correct in concluding that offset is the calculated offset my client's time is from the server's based on delay/jitter/offset and then adjusted to bring the actual offset close to 0 between client/server?

I've run ntpq -p a few times on this machine (over the span of a few minutes) and have watched the offset change:

21.518 -> 8.126 -> 5.433

Which is desirable, but I was wondering if you had played around with modifying the ntp.conf file on clients. Right now it's just:

server nope.local

I heard burst (or iburst) helps get the client in sync faster with the server since you are polling multiple times at the beginning - advisable only when you are syncing to a server on your LAN since it wouldn't be nice to burst on someone else's server.

Also, setting minpoll and maxpoll to smaller values - minimum is 4 (which polls every 16 seconds). Obviously as you poll more often, you are more susceptible to jitter, so choosing something a little higher might be better.

minpoll stuff - http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-POLL-RANGE

What do you think?

Thanks again for the help!

 

[HenryAZ]

server nope.local

I heard burst (or iburst) helps get the client in sync faster with the server since you are polling multiple times at the beginning - advisable only when you are syncing to a server on your LAN since it wouldn't be nice to burst on someone else's server.

Also, setting minpoll and maxpoll to smaller values - minimum is 4 (which polls every 16 seconds). Obviously as you poll more often, you are more susceptible to jitter, so choosing something a little higher might be better.

What do you think?

Sounds like you have the basic structure in place. My thoughts...

First off, if nope.local does not have a static IP, I would give it one, and use that rather than the name on your LAN machines' configs. It is one less thing to go wrong (name resolution).

NTP does not so much set the time as it nudges the local clock into sync with the time source. You saw your offset converging in just a short period of time. For NTP, think in terms of days, weeks, even months. The longer you can keep client and server talking to each other, uninterrupted, the better your time sync will be. Iburst does help early convergence, and it is fine to use that on your local machines, and as you said not polite to use it against someone else's server.

The problem I mentioned several posts ago about OS X's implementation of NTP being a bit hamstrung is in how it ties NTP to Date & Time. You cannot simply edit /private/etc/ntp.conf, because Date & Time overwrites it with the value set there. Further, the value set in Date & Time, as you observed, does not afford you the opportunity to add configuration options to the "server" line, such as minpoll, maxpoll, iburst, etc. Yet, you have to have something set in Date & Time as a time source, in order to get NTP to start.

There is a workaround, though, which I use. If you edit /private/etc/ntp.conf (with NTP not running), and begin with a comment line, then anything below the comment line will remain. Date & Time will write its value above the comment line.

What I would do in your case is this:

1. on the client LAN machine, create /private/etc/ntp.conf like this:

# Date & Time writes above this line
#
server [nope.local's IP address here] prefer minpoll 5 maxpoll 7 iburst

2. on the client LAN machine, Date & Time settings, enter 127.127.1.0

After you start NTP, /private/etc/ntp.conf will look like this:

server 127.127.1.0
# Date & Time writes above this line
#
server [nope.local's IP address here] prefer minpoll 5 maxpoll 7 iburst

and when you run ntpq -p on the client machine you will see two time sources: it's own local hardware clock, and nope.local's preferred server. It should default to nope.local as the preferred source. The local hardware clock is sort of a "last resort".