[ntp:hackers] unconfigure
David Mills
mills at udel.edu
Tue Jun 9 03:16:07 UTC 2009
Danny,
Believe me, a lot of thought has gone into this issue. The bottom line
is to avoid the debug trace unless absollutely necessaty; in fact, avoid
the system log unless absolutely necessary. The operator and
administrator should get almost everything from the statistics files,
including the protostats file designed for the operator, the sysstats
file designed for the administrator and the cryptostats file designed
for the security admiinistrator. Program misbehavior and file
configuration errors and the like go to the system log as fliltered by
the logconfig command, which may need some work.
I have reflected many, many times about the debug trace and whether a
smart filter would make things "simpler". However, the name of the game
is hiding complexity where possible and avoiding a greenhorn having to
sift through a set of complex options when all that is wanted is whether
it works. As it is, a casual observer can see whether packets arrive or
depart, whether the clock filter works and whether the clock is updated.
Beyond that, it is hard to deterine how to fiilter the noise without
accidentlly leaving out some important detail. I prefer to turn
everything on and sift later. I prefer a vertical rather than a
horizontal sift.
Dave
Danny Mayer wrote:
>Harlan Stenn wrote:
>
>
>>Max Kuehn (who did last year's GSoC SNTP project) is working on a
>>project for this year's GSoC that includes a "dumpconfig" command as
>>well as rewriting the logging/debugging code (both cleaning up the
>>existing code and figuring out how to get fine-grained control over
>>various debug messages in the codebase, and therefore how to specify
>>this in the config file).
>>
>>
>
>Part of the question here is where is the dump going to put it's output?
>Is it to the local drive or to return it to say ntpq. If the latter then
>the challenge is to keep the two ends in synch so nothing is lost.
>
>Danny
>
>
>
More information about the hackers
mailing list