[ntp:questions] pool configuration directive on Windows
David L. Mills
mills at udel.edu
Mon Mar 10 14:28:36 UTC 2008
The specific accusation directed to me personally was about the notrust
bit, which change I described in my previous message. I hadn't noticed
the L option change, which was not by my hand.
While I don't maintain the changelog, it would seem a simple matter to
paste my hackers announcements to the changelog.
The web documentation does make specific mention that it applies only to
the latest snapshot and advises users to see the docuemntation that came
with the version they use. A statement to that effect is prominently
displayed in the documentation home page. It could be that statement
should be more specific and that it be displayed on a www.ntp.org page;
suggestions are welcomed.
Danny Mayer wrote:
> Martin Burnicki wrote:
>>David L. Mills wrote:
>>>1. The pool command has been present for, in the scheme of things, for
>>>some time, certainly before the latest release in September, 2007. If
>>>so, why are we having this discussion?
>>The release date of v4.2.4 was 2006-12-28, and the current point release
>>v4.2.4p4 (the current -stable version) was published 2007-09-10.
>>AFAIK only bug fixes have made their way into -stable after v4.2.4, but no
>>new features like the "pool" command.
>>Just grepping over the sources of both -dev and -stable shows that the word
>>"pool" does not appear in the -stable branch, except in the contect of
>>In ntp-dev the word "pool" is listed as a keyword in ntp_config.c.
>>>2. To what are you referring to about inverted restrict bits? I've heard
>>>this urban legend before from several sources. The only change some time
>>>ago was to the notrust bit. The interpretation was changed to deny
>>>access --unless-- the server was correctly authenticated to the client.
>>>Nothing was "inverted". You could help be spreading a new urban legend
>>>to this effect.
>>Yes, in fact I've been referring to the notrust bit:
>>For a similar case see Ronan Flood's recent post (2008-02-26) under the
>>thread "NTPD on bond0:0":
>>"The sense of -L was reversed in ntpd 4.2.0: before that version, it meant
>>listen to virtual IPs, after that version, it means do not listen to them."
>>>3. I have been rather studious in announcing new features and
>>>significatn changes to the hackers newsgroup. The archives of that group
>>>should form an adequate electric paper trail, but it would have to be
>>>correlated with the release dates.
>>The problem here is when a "normal" NTP user tries to find whether a bug has
>>already heen fixed in a certain version, or whether a feature is already
>>available in a certain version, it's hard for him to find out.
>>So for example the word "pool" can be found neither in the Changelog file of
>>ntp-dev, nor in the commit logs of ntp-dev's BK repo, so it's hard to find
>>when or in which version the "pool" feature has been introduced.
>>Members of the hackers list may search their local mail archives when the
>>"pool" keyword has been mentioned, then they have to determine whether the
>>involved developers just started to discuss how to implement it, or when
>>they finished to implement it.
>>For people who are not on the hackers list and thus don't have local copies
>>of the mails this is hard to do. Did you ever try to find a specific topic
>>in the mailing list archives:
>>You can review everything by date, thread, or download archives, but you can
>>not search the archive for a keyword.
>>(Steve or Brad, would it be possible to implement this?)
>>Once a user has happened to find a specific email which documents when a
>>feature has been added, they have to compare the date of that email to the
>>dates when specific versions or tarballs have been release. Unfortunatey
>>those dates are not even in the changelog files which come with the
>>tarballs / distributions (I've recently suggested to Harlan to include
>>those dates in the changelog).
>>So they once again they have to search the mailing list or news group
>>archives to find a mail or posting with the date when a specific version
>>has been released.
>>>4. There has been a serious upgrade effor for the documentation to
>>>improve the style, reduce the lies and correct misconceptions, but it is
>>>an ongoing effort. Much of that has already been incorporated in the
>>>development branch documentaiton, including a sitemap anc command index.
>>>However, I do not intend to create a back index documenting when changes
>>>have been introduced other that the rather vague release notes.
>>I think this is OK as long as it's made clear that this documentation refers
>>only to the current development code.
>>Anyway, I'd appreciate enhancements of the changelogs to simplify
>>investigations whether a specific feature is available in a specific
>>version of the NTP package.
> The real problem here is that as long as this is a volunteer effort it's
> hard to get someone to keep track of when a new feature is introduced or
> a bug is fixed apart from what we are doing in the Changelog. As you
> know the -stable release only changes with bug fixes and no new
> enhancements are introduced there unless the minor rev is bumped. The
> best that can be done right now is to include in Changelog whenever a
> new feature is introduced.
More information about the questions