Sorry I didn't get a chance to respond earlier - time being what it is, it is
sometimes in short supply.
I hope I can offer some comments about using NTP. I started out with plain
Apple defaults and have gone a ways past that, and noted some updates/"bugs"
Apple could fix to make things better. I have a largely working ntp service
running across 30 some schools and have given feedback to intermapper to help
them be more robust in their ability to monitor the effectiveness of NTP
The Apple default implementation of NTP starts with version 4.1.1xsomething.
It's ok, but there is a 4.2.something which has some big advantages when
starting up time service but only once the Apple default configuration is
changed anyway. They are "aware" of the situation. Basically this can help a
NTP server promote itself in less than 15 minutes rather than 3 hrs (best case
scenario) as they do currently.
The Apple defaults first list the Apple time servers which while ok are a bit
under stress - I think I've perceived a round-robin resolution for multiple
time servers on their end to try and help things out. The other part of the
Apple default is that you can only enter one time service source, and they take
any entry and add/trim specific syntax around the entry you put through the
System Preference Pane GUI. You put in "time.apple.com" and it makes an entry
"server time.apple.com minpoll 12 maxpoll 17" in /etc/ntp.conf. This moderates
how often the local ntp system updates and once it gets enough responses the
NTP service will correct the time gradually unless the user actually checks the
date/time with the preference pane in which case it will jump to the"right
time" if the NTP service can find the time server ("right time" because it's
setting the time based on one packet and that can drift some seconds from "true
time" depending on packet delays between you and the time server.)
I did a large amount of reading about ntp services and the idea of thousands of
machines in just my school system relying on one (round-robined) time server
upstream seemed a bit of a stretch of credibility. However having gone through
a lot of work I can say it can be done better, but it's not easy. I managed to
setup NTP services in an effective manner at the head of our network on a few
servers and have them act as feeders of NTP time to servers in each school and
the clients in each school point to their servers. I can't give solid numbers
on comparing uptime of the overall scheme compared to pure defaults but it
seems to me clearly better - until a network interrupt big enough to degrade
the NTP status and the fact that time has been caught for a long time "shows"
as a school full of dead batteries when almost all of them come up with the
wrong time. But on the plus side I would say that our times on our computers
are about right "all" the time, and not infrequently more correct than the
declared time through administrative channels.
The configuration begins on the servers. Checking the box to enable ntp
services is just the beginning.
The first revision I recommend to the Apple defaults is to use an apparent
loophole in how the GUI accepts time servers. Make an entry, hit the space bar,
make a second entry, and so on for 4 or 5 servers - for your NTP server. The
more servers you have the less vulnerable you are to one upstream server going
down. But the leg work is to find appropriate time servers to point to. There
are rules of engagement - arbitrarily pointing all your desktops to one would
likely result in you being blocked and or getting some nasty emails. The idea
is to configure a server or three to point to these official NTP servers and
then point your clients to them (or in my case a three layer system - front of
the network servers, school based server, desktops.) Some are public for
certain regions only, some require email correspondence to setup.... here's
where some pooled time servers are setup on a round-robin scheme -
http://ntp.isc.org/bin/view/Servers/NTPPoolServers but start reading with the
"Rules of Engagement" section. Add these servers with the time.apple.com one
and you can beginning to get a real mix of time servers.
There is also a section here http://ntp.isc.org/bin/view/Servers/WebHome for
*Participating* in the network of time servers (offering officially as well as
getting) requires Apple to tune up it's defaults and versions. Don't try - some
have and apparently there is something of a bad reputation that's come about as
I wouldn't bother trying to change the Apple default syntax as even looking at
the Date/Time Pref Pane will re-write the syntax Apple uses but as I said above
- it turns out trivial to add multiple time servers and it works fine.
Now there is a bug or two to work out/around. If an Apple server starts up
physically, it seems to not be able to promote itself as a NTP server unless a
step is taken even if everything is right (all the check boxes are set and
entries put in.) And this appears to be true of 10.3 and 10.4 servers. You have
to at least look at the Date/Time Preference itself. All you have to do is look
at it long enough for it to allow you to uncheck the box (it's greyed out for a
few seconds as the service checks and kicks in.) Don't uncheck it, just see it
ungrey-out. Since you have to do this this pretty much obviates any
customization you might try with the ntp.conf file. Despite comments about a
command line entry in a cron job should do it I've been unable to find a
correct syntax that just works. Apparently there are several fingers in the pie
deep in how all this works and living with the Apple fingers seems to be best.
Another exception or bug happens with a DNS gets confused. I don't know exactly
the details but NTP seems to follow the confusion sometimes and not unconfuse
just because the DNS does. I don't know what this DNS confusion is but
sometimes the time servers don't point right - might be a purely local problem
with DNS servers. IN any case you can check and clear the confused info through
a command line check with ntpq.
ntpq is an interactive interface into the ntp configuration. The command most
useful once in ntpq is peers. This will pole the configuration file for entries
and check the status of those entries. If it can't communicate then you need to
uncheck and re-check the Automatic time setting in the Date/Time Pref Pane. If
it doesn't resolve right (probably a lot of zeroes for the IP address) then try
again a few times. If it stays zeroes check your names - they aren't resolving
or you have a DNS problem. Uncheck/recheck in Date/Time Pref pane to force NTP
to try fresh. Sometimes the entries seem confused - I wish I could be more
particular about this but I've only seen it twice and didn't take notes. It was
just wrong - the second column in the ntpq>peers command is supposed to be
related to where your first column is getting it's time from I think and it was
just all goofed up. NTP service wouldn't kick in. Again unchecking and
rechecking the box in Date/Time eventually cleared it out.
Add alittle monitoring and things quickly settle down and are "up" far more
than it is down.
Speaking of monitoring.... there was almost no way to check whether the NTP
service was running well enough to declare the time to other machines. It was
fairly trivial to see if the service was running at all but as packet transfers
are elemental to NTP running well enough occasional dropped packets would mean
the service would demote itself and tracking *that* wasn't so easy. I
eventually found some work done in nagios and big brother type monitors and
used that info to get Intermapper to beaf up it's abilities. These are now part
of the current beta release of intermapper - it notes when a service demotes
(in fact it just notes what strata the NTP service is running at 1,2,3 are
"good" 0 or 16 are "bad".) And you can now graph these over time and see a
pattern if a server is going "down" too much.
' ' ' ' ' ' ''"""""""""""'' ' ' ' ' '
Alamance-Burlington NC USA, Mac Systems Tech
Possess a pure, kindly and radiant heart!
They that observe lying vanities forsake their own mercy.
Do not post admin requests to the list. They will be ignored.
Client-management mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden