svn commit: r326095 - head/usr.sbin/bsdinstall/scripts

[Ian Lepore]

On Fri, 2017-11-24 at 14:57 -0700, Warner Losh wrote:
> On Fri, Nov 24, 2017 at 2:14 PM, Rodney W. Grimes <
> freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > 
> > 
> > > 
> > > > 
> > > > We are not talking about removing ntpdate in this thread.
> > >   Well, after Ian said that it was deprecated I ask if we should remove
> > > it to be honest.
> > And I think we have come to the agreement not to do that until the
> > official distribution does it as well, is that also correct?
> > 
> I think we should do whatever Ian suggests. I did time things with atomic
> clocks and ntpd for about 8 years. He's done them for the same company I
> have and knows the current set of quirks better than anybody else in this
> thread. These days, it's generally better to use the freebsd ntp pool, like
> we have in ntp.conf, and in that scenario, an invocation of ntpd with the
> appropriate flags can give you almost identical behavior to ntpdate. The
> 'almost' here has a lot of quibbles that aren't relevant to the installer.
> And if you don't like the freebsd ntpd pool, then the installer should be
> writing an appropriate ntpd.conf file anyway, which has the host. It can
> all be done w/o using ntpdate (note: I didn't say remove it), and once
> that's in place, and we know there's something not unforeseen, we'll be
> ready if the ntpd folks ever make good on their threat to kill ntpdate. So
> remove the use of ntpdate here, but keep the utility around.
> 
> tl;dr: Do what ever Ian says, if he doesn't do it himself. He's the expert
> with a decade of daily experience making products with ntpd work and
> shipping those to customers that have... somewhat diverse environments...
> 
> Warner

And yet, even with all that experience, I still neglected to consider
the case where ntpd_sync_on_start=YES can cause a time-step on a
running system if ntpd is restarted.  (Not that that's a common
scenario, but it's still a Bad Thing for people with strict auditing
requirements or timing-critical software running.)

What the ntpd developers currently say[1] is:

    The combination of ntpd and sntp now implements the functions of
    ntpdate. As soon as a few remaining issues with sntp are resolved
    the ntpdate program will be retired.

If you look at what they link to for the "sntp issues"[2] it hasn't
been updated since 2011.  So that leads me to the conclusions:

 - They have not yet provided a complete path away from ntpdate.
 - They don't seem to be in a big hurry to eliminate ntpdate.

All in all, I think what Manu committed is Good Enough For Now(tm).

[1] https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
[2] https://support.ntp.org/bin/view/Dev/SntpIssues

-- Ian