svn commit: r289421 - in head/etc: . mtree ntp
Bryan Drewery
bdrewery at FreeBSD.org
Sat Oct 17 18:34:21 UTC 2015
On 10/17/15 11:25 AM, Ian Lepore wrote:
> On Fri, 2015-10-16 at 14:04 +0000, Cy Schubert wrote:
>> Author: cy
>> Date: Fri Oct 16 14:04:16 2015
>> New Revision: 289421
>> URL: https://svnweb.freebsd.org/changeset/base/289421
>>
>> Log:
>> Add default leap-seconds file. This should help ntp networks get
>> the
>> leap second date correct
>>
>> Updates to the file can be obtained from ftp://time.nist.gov/pub/ o
>> r
>> ftp://tycho.usno.navy.mil/pub/ntp/.
>>
>> Suggested by: dwmalone
>> Reviewed by: roberto, dwmalone, delphij
>> Approved by: roberto
>> MFC after: 1 week
>
> One thing about this change scares me. In the ntpd documentation:
>
> If the leapseconds file is present, the leap bits for reference
> clocks and downstratum servers are ignored.
>
> I can't determine from casual code examination (and I don't have time
> to experiment now) whether that is true even if the file is expired.
>
> The leapfile expires every six months, and users must update it using
> some external mechanism, or they must have configured autokey stuff so
> that updates can be accepted from peer servers. In either case what
> we've done is created a default configuration that is likely to fail
> right out of the box, because at least for releases the file we deliver
> will be expired before they even download and install the image.
>
> At the very least I think we should hold off on MFC of this until we
> know for sure whether an expired-but-present leapfile causes incorrect
> operation. If a pending leap notification in the leap bits of packets
> from peer servers and refclocks will be honored when the file is
> expired, then there is no problem with this change.
>
Yeah. This sounds like something that needs to be delivered more easily
in a normal update mechanism, such as packages. ENs every 6 months are
not practical for this and a lot of users don't always apply EN while
IMO they are more likely to apply package upgrades. Short of that, some
kind of periodic script could fetch an updated file <enter ssl cacert
discussion>.
--
Regards,
Bryan Drewery
More information about the svn-src-all
mailing list