Harlan,
Sachin Kamboj's new code can use ntpq for anything in the configuration
file. Sachin has moved on to another job and his code, although working,
needs test and fix. It first needs to survive the recent rewrite of the
command line parsing, which has changed since he first merged with the
distribution. A volunteer could have a lot of fun with the new code,
which by the way has explicit support for the pool function plus a lot
of other goodies folks have been asking for.
I would suggest to a volunteer that a diff between Sachin's code and the
base code he has been working on, then apply the diff to the current
code and fix what breaks.
By the way, the new code parses exactly the same syntax and semantics as
the present configuration file, including non-reserved words. However,
it's all syntax-driven and configuration commands can be issued anytime
via ntpq. And yes, it is MD5 authenticated.
Dave
Harlan Stenn wrote:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Danny Mayer) writes:
Danny> We'd also like to get rid of
Danny> ntpdc but that requires that ntpq supports some queries that it
Danny> cannot currently handle. ntpdc uses private mode 7 packets which is
Danny> much more difficult to maintain while ntpq uses mode 6 packets.
ntpq does standard mode 6 queries and should be portable across versions and
implementations.
ntpdc uses vendor-specific mode 7 queries.
There is no way to bring up new associations with mode 6 packets.
This functionality *can* be done with a mode 7 packet.
I would be happy to see ntpdc simplified (ie, get rid of anything that can
be done with ntpq), but I can also see the value in having a single program
that knows when to use a mode 6 packet and when to use a mode 7 packet.
After all, it is most convenient to see the current peer list when adding or
removing associations.
H
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
