[ntp:hackers] 4.2.5p203 adds ntpq dumpcfg command

Dave Hart davehart at gmail.com
Mon Aug 17 19:36:49 UTC 2009

On Mon, Aug 17, 2009 at 6:48 PM, Hal Murray<hmurray at megapathdsl.net> wrote:
> Thinking out loud....
> How does it handle comments?
> My straw man would be  something like a diff against the current config file
> so I can do the edits by hand, inserting the changes and comments in the
> right place rather than at the end of the file.

It's based on dumping the config_tree structures generated by the
parser, which gleefully ignores comments right now.  So, they're all
munched, and currently the only comments added are in the case of an
internal error, such as Reg quoted.

It is, as Brian might say, a simple matter of programming to extend
the concept to emit a closer reproduction of the original.  Comments
would have to be preserved along with the location of every
token/string.  The output would have to be buffered and sorted while
inserting (using a priority queue would work) or at the end.

> I can think of two types of info I might like to see.
> One is history, perhaps commands with time stamps.

Max has just added code to tag the config tree with its source.  I'd
like to see that information as comments in the dump output:

# /etc/ntp.conf read 2009-08-17 19:20:21
# ntpq :config from key 5 at 2009-08-17 20:21:22
# ntpq configfromfile from key 5 at 2009-08-17 20:21:44
pool pool.ntp.org
tos minsane 2 minclock 4 maxclock 8

> Perhaps config changes
> over the net should get logged.  (Perhaps they already do.  Perhaps this
> should be part of the great logging cleanup.)

I believe they should, and don't.  See http://bugs.ntp.org/1285

> The other is the current status and/or a diff between the current status and
> the initial config file.  If there are paired commands that cancel eachother
> (add X, delete X), it would reduce clutter to omit them from the output.
> Similarly for a sequence of commands that override the previous ones, just
> keep the last one.

I'm not sure I see the value as worth the additional code complexity
and maintenance.  The unpeer (unconfig) command, for example, will
take out the association immediately after setting it up and before
any packets are sent.  Code to modify configuration trees at runtime
to delete/merge into the most concise form would be fragile to
maintain, because detecting breakage requires special attention to
test dumpcfg, which is likely peripheral to the reason for the
hypothetical patch that broke it.  Simply outputting the same
configuration that was input ensures the same sequence of application
steps (via config_*() funtions) loading the dump as in the dumped

Here's a tangent, heck, some might call it an invitation to bikeshed.
Is "dumpcfg" the right name?  "saveconfig" jumps out to me as an
alternative with less negative connotation.  It seems appropriate to
spell out config to me, as well.

Dave Hart

More information about the hackers mailing list