On Tue, Apr 21, 2009 at 12:16:02PM -0400, Brian Utterback wrote: > >How is upgrade handled? Are old configs re-written to the new style on > >service start? > > No. Because of the fact that the ntp.conf file is almost completely > backwards compatible, we will not attempt to re-write the files. At > your request, I have added a check for the obsolete "authentication > no" configuration line, and if found will disable the authentication > requirement.
On re-review that seems reasonable. What happens if a user's ntp.conf uses removed keywords? Will the service end up in maintenance mode? Or will there be but a warning in the service log file (and/or syslog)? > The "enable/disable pps" option is really never used, since it implies > that a hardware refclock is in use (which cuts the percentage down to > a very small number right there) and that the PPS signal is wired > (still smaller) and that the customer has gone to that trouble and now > does not want to use it (I'd be surprised if we hear from even one). I can certainly imagine "enable pps" being used because I've seen it... But it's almost certainly exceedingly rare too (the rig I saw using it required some homemade circuitry). > To answer your questions in another leaf of this thread, I would > prefer "Uncommitted Obsolete" for ntpdc and ntpdate rather than > "Committed Obsolete". I would like the possibility of removing them > someday, when the NTP distro drops them. It would be most difficult to > upgrade later if we needed to deliver something that isn't in the distro. Sure. Obsolete is fine for these, and Uncommitted is fine too AFAIAC (but IANAAM). > If you really want a link from xntpdc to ntpdc, I am okay with that. > Does anybody besides Nico like that idea? IMO the link costs nothing, but I don't care that much. Might anyone have written scripts based on xntpdc? I might have in my sysadmin past...
