Wonky NTP startup and the incremental-configuration problem

[Eric S. Raymond]

Heads up, Mark!

Achim Gratz <Stromeko at nexgo.de>:
> > It would be better for code verifiability and security if the
> > only source of configuration information for the daemon were the
> > ntp.conf file.  (We can't quite get there due to the requirement
> > to store drift state, but closer would be better.)
> 
> If you do that, you need some way to change the configuration without a
> wholesale restart of ntpd or at least determining and tweaking fudge
> factors gets a lot harder than it already is.

I didn't really understand that a week ago.  Now, having studied ntpq
in the process of getting rid of magic addresses, I do.

Mark, this bears on a conversation we were having at Penguicon.  There
are good complexity-reduction reasons for wanting to deep-six all the
run-time configuration stuff.  But until we've beaten the slow-convergence
problem into the ground I now think we shouldn't do it.

The problem is that at least some people are used to changing fudge
times and driver options on the fly in order to find a
jitter-minimizing set.  Shutdown/startup can introduce nasty
transients that screw up this process.

If we remove the ability to avoid those transients, some experienced
operators will be pissed off, and not without reason.  It's a fight
I think we should avoid; I'd rather spend peoples' limited tolerance
for change elsewhere.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>