State of the microserver HOWTO

[Eric S. Raymond]

It's nearly done.  But when I projected "two working days" over the weekend,
I forgot that we till have a significant area of controversy about what to put
in the ntp.conf file.

Before getting into that, I should explain the Odroid problem better
than I did in my last note.  What's going on is that the pps-gpio
driver is configured hard off (not modular) in the Odroid kernel.  You
can't get it without building a custom kernel that has the right load
hook in it.

This adds enough complexity to the recipe that I think it makes the Odroid
uncompetitive with the Pi for this build.  I have explained the problem
and the context to the Odroid dev running their tech support forum, and
am hoping for a commitment to fix this in the next release.  It's literally
a matter of fipping one switch in a config file.

Now onto the ntp.conf file.

At the moment it uses gpsd via the SHM channel and three named public
timservers.  I'm told the latter is bad practice and should be got rid of.

I would like to replace what's there with something better.  I'd also
like to carry a couple of alternate, more advanced configuration that
use (say) drivers 20 and 22 rather than gpsd + SHM.

I'd like to have at least one configuration that is truly autonomous and
doesn't use check servers at all.

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. 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, try again with better exokanation.  Remember
that part of our purpose is to teach newbies, and if you suspect that
I plan to add the winners to the NTPsec documentation as tutorial
examples you are absolutely right.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>