Shippable ntp.conf files for the HOWTO

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > My plan was to encourage you to elaborate - *and explain* - your favorite
> > odd features for your local config, then work with you to prune it back to
> > someting we might ship. 
> 
> You are letting Gary suck you down ratholes.
> 
> I think you need to think hard about what your goals are and make sure they 
> are correctly and fully described in the first paragraph to two.
> 
> That will help the rest of us provide appropriate feedback.
> 
> Are you trying to setup a good-enough server that requires minimal knowledge 
> and minimal care?  (Even that requires some sysadmin attention to track 
> updates.  That should probably be included on the security area.)
> 
> Are you trying to setup a server appropriate for the pool?
> 
> Are you trying to setup a server for geeks to play with?  (lots of logging 
> and stats)
> 
> 
> What level of geeky detail do you want to dicsuss?  The ARP timeout is
> a good example.

Fair enough.  OK, let me try to refocus the discussion.  Note that I have changed
the thread title.  Much of the rest of this note is a restatement and
(hopefully) a clarification of 

I am attempting to assemble a gallery of working ntp.conf files that
we can ship with the HOWTO. My intentions include adding these to the
NTP documentation as tutorial examples.

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.

Please send me configurations.  This is a last blocker on releasing
version 1.0 of the HOWTO and I don't want to wait too long. If I don't
get a suitable replacement in a reasonable time I will shrug and ship
the flawed one.  If nobody cared enough to correct it, it can't be bad
enough not to ship.  (Yes, this is a blatant poke.)

Constraints:

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.

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.

3. If fudge factors are included, reasons for believing them must be
specified in the explanatory comment.

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

5. The management reserves the right to tell you "explanation not good
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.

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

Hal, I hope this answers your question and clarifies things for everybody.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>