5.3-R: /etc/ntp.conf doesn't exist

[Brad Knowles]

At 8:45 PM -0800 2004-11-09, Brooks Davis wrote:

>  At a glance these guidelines seem reasionable, but it doesn't appears
>  that having 4-5 upstreams and having a file that just works are
>  compatable.

	If you want to protect yourself against at least one falseticker, 
you have no choice but to use at least four upstream time servers. 
Brian Utterback can explain the math better than I can, but that's 
the simple facts of the matter.

>               So long as we're not at risk of swamping a server like one
>  of the AP vendors did, having something that just works is going to
>  trump following the recommendations exactly.  It's not clear to me that
>  you can do both at the moment.  IMO, it's really lame to say that you
>  should use at least 5 servers and then only provide a stable way to
>  access 3 of them.  If 5 is the recomendation, there should be
>  3.pool.ntp.org and 4.pool.ntp.org entries.

	I wrote most of the TWiki entry that you read, based on comments 
I got from a variety of people, including fellow contributors to 
ntp.org/ntp.isc.org and knowledgeable participants on the 
comp.protocols.time.ntp newsgroup.

	Adrian runs the pool.ntp.org stuff as a separate project, and 
I've been trying to get him and the other members of the 
timekeepers at fortytwo.ch mailing list to contribute content to the 
TWiki, or to just give me feedback that I can use, but I have not yet 
been able to get any of them to do so.


	Most of the public support stuff has been moved from ntp.org over 
to ntp.isc.org (bugzilla is the last thing to be moved over), but 
even before that, Adrian's project was pretty much a completely 
separate effort and the only thing it shared with anything that the 
rest of us were doing was the ntp.org domain name.

	It used to be something totally different under Adrian's own 
domain name, but Dr. Mills liked the idea well enough that he worked 
with UDel to get pool.ntp.org delegated to Adrian's machines, so that 
he could run that part of his project totally separate from 
everything else, and largely without interference or interaction with 
anything else.


	Note that many of the servers in the pool are on ADSL or other 
low-bandwidth personal lines, do not have great clocks, running older 
NTP server code or alternative server code which might cause problems 
for people running a modern ntpd, and the monitoring system right now 
also has some problems.  For example, the recent issue that caused 
all of pool.ntp.org to become empty since the monitoring system was 
offline and it thought that all of the servers were offline, so it 
dutifully removed them all from the respective zones.

	My understanding is that the concept for pool.ntp.org was to 
provide decent-enough additional time sources in most cases for the 
majority of people using the system, without necessarily any regard 
for locality of reference (if you're using the top-level pool.ntp.org 
zones, those servers could be anywhere in the world), and definitely 
without being the primary source of time for most people.

	If you are a customer of a local ISP that has one or two time 
servers that they provide for your use, then using your 
country-code/regional pool.ntp.org zone is a perfect way to fill in 
the extra slots that you want/need to get up to the minimum level you 
should have in order to protect yourself against falsetickers.  If 
your country-code or regional sub-zone doesn't have enough servers in 
it, then you can always take one step higher.

	Providing the [012].whatever.pool.ntp.org zones is a hack to get 
around problems that some people have with broken resolvers which 
don't implement round-robin correctly, and prevent configurations 
from working where you list the exact same "server pool.ntp.org" line 
multiple times in your /etc/ntp.conf.  But it's just a hack.


	Do keep in mind that some server operators in pool.ntp.org are 
already complaining about individual ill-behaved clients that are 
hitting them once or twice a second, and firewalling them off.

	Then there was the recent incident when a small, heretofore 
unknown, provider of network equipment from the UK decided to ship 
out an update to their platform and pretty much got the entire 
pool.ntp.org server operator community in an uproar due to excessive 
traffic.  It took a few days to find out who the provider was, then a 
few more days to convince them to fix their software, and then it 
took a few more days for the rollout to occur and to get most of 
their small customer base fixed.

	If you're interested in reading more about this topic, go to the 
archives of Adrian's timekeepers mailing list and search for things 
like "netpilot", "Guidelines for large scale use", and "excessive 
traffic?".


	In the meanwhile, I've been trying to do what I can to help 
various projects get their own NTP configurations into more 
reasonable shape, based on what is currently in the TWiki.

>  If you have specific recomendations to fix the file, please make them.

	At the very least, if you're going to put [012].pool.ntp.org in 
your default /etc/ntp.conf file, you certainly couldn't hurt yourself 
any worse by also including northamerica.pool.ntp.org, 
europe.pool.ntp.org, and asia.pool.ntp.org, since all of the servers 
listed in the lower level pools also get listed in the higher level 
pools, and you can be reasonably certain that you're already going to 
get a world-wide distribution of servers within the 
[012].pool.ntp.org lists no matter what.

	Assuming no broken resolvers, and given the total number of 
servers currently listed in the pool, there should be relatively 
little chance of collision between the [012].pool.ntp.org and the 
<region>.pool.ntp.org zones, and you should result in getting five or 
six distinct IP addresses for ntpd to use.

>  Perhaps ntp.org should provide such a file.

	I'm not convinced that we can provide such a file.  Each 
different platform is going to have their own ideas of where log data 
should be sent, where statistics files should be kept, etc....  What 
might work for FreeBSD might not work for NetBSD and certainly 
wouldn't work for OpenBSD, and Linux would be a totally different 
ballgame altogether.

	Then there are the other 20+ platforms that we support, including 
non-*nix related OSes as Microsoft Windows NT/2000 and VMS; embedded 
platforms like QNX and VxWorx; ancient versions of Unix such as 
Ultrix, DomainOS, and SunOS 4; as well as a wide variety of "modern" 
Unix and Unix-like OSes.

	If we were to provide a standard default configuration file that 
was required to work equally across all platforms, it would have to 
be stripped of all features other than specifying a set of at least 
four servers to be used.


	Certainly, we can provide information and advice to the relevant 
projects and the people doing NTP-related work on those projects, and 
we are interested in doing whatever we can to help get everyone to an 
equally high level of performance, quality, and robustness of 
configuration.

	But I have to believe that there's going to be some 
project-specific parts to those configurations files, and we can't 
specify or dictate what they should be -- nor do I believe that we 
should try.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.