Shippable ntp.conf files for the HOWTO

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> Yo Eric!
> 
> On Wed, 8 Jun 2016 08:09:42 -0400
> "Eric S. Raymond" <esr at thyrsus.com> wrote:
> 
> > One of these files may replace the single one we ship now.  At the
> > moment it uses gpsd via the SHM channel and IPs for three public
> > timeservers.  I'm told the latter is bad practice and should be got
> > rid of; I want someone wuth operational experience to show me (and
> > *explain*!) a better alternative.
> 
> This is in my example:
> 
> 
>     # if you have no other local chimers to help NTP perform sanity checks
>     # then you can use some public chimers from the NTP public pool:
>     # http://www.pool.ntp.org/en/
> 
>     # To use the pool servers uncomment the last four lines in this section.
>     # The iburst option tells ntpd to query the pool serers with bursts instead
>     # of single requests.  This can yield better results to remote servers.
>     # Notice I use the 'us' country code servers, otherwise I might get one
>     # pool server from Ukraine and another from Singapore.  If you are
>     # not in the USA, then change the 'us' to your two letter country code.
>     #  server 0.us.pool.ntp.org iburst
>     #  server 1.us.pool.ntp.org iburst
>     #  server 2.us.pool.ntp.org iburst
>     #  server 3.us.pool.ntp.org iburst
> 
> I just ran a test of pool servers.  The basic pool gave me servers in
> Switzerland, German, Czech Republic and one in New Jersey.
> 
> Not good.  You can't count on geo-location.  Specify the country!

You have explained that before.  I get it.
 
> > Please send me configurations.
> 
> I think that will be too hard.  Everyone want to focus on the
> different part of the ntp.conf.

Everyone can do that.  What I don't want to do is have to micropatch
the piece each person takes responsibility for a zillion times because
I get sent incremental corrections rather than a clean version of their
piece.

> I suggest we split the ntp.conf up into several parts.  Then pick the
> winner in each section.  Some things will be boer plate for almost
> all configurations, others will be very specific to certain refclocks.

OK, but these are still the things I need to see from the process.

> > Here are some themes I'd like to see expressed in configurations:
> > 
> > * Simplest possible, minimal-knowledge, fire-and-forget configuration.
> >   (The one we ship now is intended to be like this.)
> > 
> > * Fully "native" configuration that uses drivers 20 and 22 rather than
> >   gpsd + SHM.
> > 
> > * A configuration that is truly autonomous and doesn't use remote
> >   check servers at all.  Header comment should try to explain the
> >   tradeoffs.
> > 
> > * A configuration that uses the pool.
> > 
> > * A configuration intended to feed the pool.
> > 
> > * A configuration illustrating and explaning good logging practice
> >   for performance analysis.
> 
> Thus WAY too much duplication!  Most of those should be identical!
> Stop the duplication!

Let *me* worry about that.  If get the pieces and explanations I need, I'll
take eresponsibility for joining them together.

> I can't find an include file directive in ntp.conf?

There isn't one.  Eventually, for reasons related to the refclockd split,
I know I'll have to fix that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160608/be0fb7c4/attachment.bin>