Shippable ntp.conf files for the HOWTO

[Gary E. Miller]

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!


> Please send me configurations.

I think that will be too hard.  Everyone want to focus on the
different part of the ntp.conf.

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.

For a start:

1. logging, stats, etc.

2. trust and access

3. local refclocks (SHM, DVB, etc.).  Above all other chimers

4. local network refclocks

5. pool (at the bottom of the config!)

So, take my above pool example as the pool section.

> 1. Every submission must be an entire config file, *not* just
> instructions to "tweak this other one thus".  Change-merging at this
> level is error-prone, tedious, and drives me batty.  If I want to see
> changes I'll use diff.

As above, I object.
 
> 2. Every submission must include a header comment explaining the
> theory of the configuration and any unusual pieces of it.  Consider
> "unusual" to include any keyword or clause that doesn't occur in the
> current uber-simple one.

I would say each section.

> 4. Submissions should not contain references to private or local
> servers that a reader of the HOWTO cannot use.

Not in the basic config, but needed in advanced ones.

> enough" and therefore reject a submission even if it's technically
> sound.  If this happens, please try again with better explanation.
> Remember that part of our purpose is to teach newbies.
> 
> 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!

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


> Another reveal: I hope to use these as bases for comparative
> benchmarking.

Another good reason for them to be modular.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160608/a2e9e863/attachment.bin>