Re: leapsecond file
In message <20160825001624.h1...@naund.org>, Andreas Ott writes:
> Hi,
>
> On Wed, Aug 24, 2016 at 06:55:37PM -0700, Cy Schubert wrote:
> > The file was obtained from USNO. Except for a $FreeBSD$ and a minor
> > spelling fix that was brought forward from r298087, the file was not
> > altered in any way. One of the problems is that the minor spelling fix
> > invalidated the secure hash at the end of the file, ntpd ignores the file.
> > r298087 needs to be reverted. (cc'd pfg@) I'll revert r298087.
>
> If I read the hash instructions towards the bottom of the file, you should
> be good to fix typos or add $FreeBSD$ in a comment line, the only lines
> that are hashed are the data and time stamps. Syslog shows that during the
> last week the hash was considered OK on the file in 10.3-p7 with
> $FreeBSD: releng/10.3/etc/ntp/leap-seconds 295461 2016-02-10 07:16:17Z cy $
> .
>
> 2016 Aug 18 18:26:07 [ntp.notice] mon leapsecond file ('/var/db/ntpd.leap-sec
> onds.list'): good hash signature
> 2016 Aug 18 18:26:07 [ntp.notice] mon leapsecond file ('/var/db/ntpd.leap-sec
> onds.list'): loaded, expire=2016-06-01T00:00:00Z last=2015-07-01T00:00:00Z of
> s=36
> 2016 Aug 18 18:26:07 [ntp.err] mon leapsecond file ('/var/db/ntpd.leap-second
> s.list'): expired less than 79 days ago
> 2016 Aug 18 18:26:07 [console.info] mon Aug 18 18:26:07 mon ntpd[584]: leapse
> cond file ('/var/db/ntpd.leap-seconds.list'): expired less than 79 days ago
The updated rc.d/ntpd will fix this.
>
> > I'll revert pfg's spelling fixup which I had brought forward and I'll need
> > to remove $FreeBSD$ as well, validating the hash again. Additional code
> > will need to be added to rc.d/ntpd to replace the copy in /var/db if
> > $FreeBSD$ exists.
>
> Please check the hash instructions, I don't think it's needed to remove that.
IMO it's better to use the virgin leap-seconds file anyway to avoid any
confusion as to its authenticity.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
Hi,
On Wed, Aug 24, 2016 at 06:55:37PM -0700, Cy Schubert wrote:
> The file was obtained from USNO. Except for a $FreeBSD$ and a minor
> spelling fix that was brought forward from r298087, the file was not
> altered in any way. One of the problems is that the minor spelling fix
> invalidated the secure hash at the end of the file, ntpd ignores the file.
> r298087 needs to be reverted. (cc'd pfg@) I'll revert r298087.
If I read the hash instructions towards the bottom of the file, you should
be good to fix typos or add $FreeBSD$ in a comment line, the only lines
that are hashed are the data and time stamps. Syslog shows that during the
last week the hash was considered OK on the file in 10.3-p7 with
$FreeBSD: releng/10.3/etc/ntp/leap-seconds 295461 2016-02-10 07:16:17Z cy $ .
2016 Aug 18 18:26:07 [ntp.notice] mon leapsecond file
('/var/db/ntpd.leap-seconds.list'): good hash signature
2016 Aug 18 18:26:07 [ntp.notice] mon leapsecond file
('/var/db/ntpd.leap-seconds.list'): loaded, expire=2016-06-01T00:00:00Z
last=2015-07-01T00:00:00Z ofs=36
2016 Aug 18 18:26:07 [ntp.err] mon leapsecond file
('/var/db/ntpd.leap-seconds.list'): expired less than 79 days ago
2016 Aug 18 18:26:07 [console.info] mon Aug 18 18:26:07 mon ntpd[584]:
leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired less than 79 days
ago
> I'll revert pfg's spelling fixup which I had brought forward and I'll need
> to remove $FreeBSD$ as well, validating the hash again. Additional code
> will need to be added to rc.d/ntpd to replace the copy in /var/db if
> $FreeBSD$ exists.
Please check the hash instructions, I don't think it's needed to remove that.
-andreas
--
Andreas Ott K6OTT +1.408.431.8727 andr...@naund.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
In message <1472070074.1430.39.ca...@freebsd.org>, Ian Lepore writes: > On Tue, 2016-08-23 at 22:40 -0700, Andreas Ott wrote: > > On Sun, Aug 07, 2016 at 09:44:55PM -0700, Kevin Oberman wrote: > > > On 11.0-BETA4 I have: > > > > grep expires /var/db/ntpd.leap-seconds.list > > > #File expires on: 1 Jun 2017 > > > > > > But I see what you do on 10.3-RELEASE. Looks like the update has > > > not made > > > it into 10 (an I would guess 9). > > > > The flaw is in the internal versioning of files, it does fetch the > > newer > > file from IETF and puts it into /var/run/ntpd.leap-seconds.list, but > > although the expiry is newer, the FreeBSD onboard source version > > claims > > to be newer in the 'last update date in NTP timestamp format' line > > ... > > > > FreeBSD 10.3-RELEASE-p7 onboard source is in /etc/ntp/leap-seconds, > > which gets copied to /var/db/ntpd.leap-seconds.list. The fetch > > IETF file downloads to /var/run/ntpd.leap-seconds.list . > > > > > > [root@mon ~]# egrep -e Update\|expires\|^'#\$' /etc/ntp/leap-seconds > > # Last Update of leap second values: 31 Dec 2015 > > #$ 3660508800 > > # Updated through IERS Bulletin C 50 > > # File expires on: 1 Jun 2016 > > [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/db/ntpd.leap > > -seconds.list > > # Last Update of leap second values: 31 Dec 2015 > > #$ 3660508800 > > # Updated through IERS Bulletin C 50 > > # File expires on: 1 Jun 2016 > > [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/run/ntpd.leap > > -seconds.list > > # Last Update of leap second values: 5 January 2015 > > #$ 3629404800 > > # Updated through IERS Bulletin C51 > > # File expires on: 28 December 2016 > > [root@mon ~]# > > > > with the end result that the file from /var/run/ never gets moved to > > /var/db/ . > > The 480.leapfile-ntpd used by periodic calls the same rc file fetch > > and > > comparison. > > > > -andreas > > The Last Update value reflects only additions of leap seconds to the > file, and it is specifically documented that Last Update does NOT > change when the file's expiration date is extended without changing the > other contents. > > It looks like part of the problem here is that the Last Update value IS > changing when the leap data itself is not. Our commit logs say the > files have been obtained from USNO. Either USNO is violating the > standard in their files, or the value is getting modified before it's > commited to the freebsd repos. (I'm adding Cy to the CC list, since he > committed them.) The file was obtained from USNO. Except for a $FreeBSD$ and a minor spelling fix that was brought forward from r298087, the file was not altered in any way. One of the problems is that the minor spelling fix invalidated the secure hash at the end of the file, ntpd ignores the file. r298087 needs to be reverted. (cc'd pfg@) I'll revert r298087. Fetching and comparing shows the files being totally different because of comments and whitespace differences. Comparing the version numbers (update dates) we have the following: slippy$ grep '#\$' leap-seconds.* leap-seconds.iers:#$3676752000 leap-seconds.ietf:#$ 3629404800 leap-seconds.usno:#$ 3676752000 (Slippy BTW is the name of a dead pet. I name my computers after dead pets.) The IETF file hasn't been updated for a while: slippy$ date -r $((3629404800-2208988800)) Sun Jan 4 16:00:00 PST 2015 The other two files were update in July: slippy$ date -r $((3676752000-2208988800)) Tue Jul 5 17:00:00 PDT 2016 Looking at expiry dates: slippy$ grep '#@' leap-seconds.* leap-seconds.iers:#@3707596800 leap-seconds.ietf:#@3691872000 leap-seconds.usno:#@3705264000 The IETF file expires at: slippy$ date -r $((3691872000-2208988800)) Tue Dec 27 16:00:00 PST 2016 slippy$ The IERS file expires at: slippy$ date -r $((3707596800-2208988800)) Tue Jun 27 17:00:00 PDT 2017 slippy$ The USNO file expires at: slippy$ date -r $((3705264000-2208988800)) Wed May 31 17:00:00 PDT 2017 slippy$ > > It looks like the fetch/install decisions in rc.d/ntpd are not quite > right either. Both Last Update and Expiration date have to be taken > into account. To allow for these broken files that incorrectly change > the Last Update, workable logic would be to keep the file with the > highest Expiration date, and if the expirations are equal, then keep > the one with the highest Last Update. (I think it would be better to > test Last Update first, then use Expiration as the tie-breaker, but > that fails with these broken files.) Testing both Expiration and Last > Update will allow for a corrected file to be published after > accidentally publishing bad data, and we'd take the corrected file. The attached patch should address this last issue. I'll revert pfg's spelling fixup which I had brought forward and I'll need to remove $FreeBSD$ as well, validating the
Re: leapsecond file
Hi, On Wed, Aug 24, 2016 at 02:21:14PM -0600, Ian Lepore wrote: > It looks like part of the problem here is that the Last Update value IS > changing when the leap data itself is not. Our commit logs say the > files have been obtained from USNO. Either USNO is violating the > standard in their files, or the value is getting modified before it's > commited to the freebsd repos. (I'm adding Cy to the CC list, since he > committed them.) The beauty of standards is, that there are too many to chose from. These seem to be the three top sources of the file (lmgtfy), and while they might agree in the actual leapsecond data, the meta information in it is very different. fetch -m --no-passive ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list fetch https://www.ietf.org/timezones/data/leap-seconds.list fetch https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list [root@mon /tmp]# ls -la *list -rw-r--r-- 1 root wheel 10384 Mar 14 18:33 ietf-leap-seconds.list -rw-r--r-- 1 root wheel 8795 Jul 6 14:13 navy-leap-seconds.list -rw-r--r-- 1 root wheel 4920 Jul 6 14:37 obspm-leap-seconds.list [root@mon /tmp]# wc *list 2491960 10384 ietf-leap-seconds.list 22016578795 navy-leap-seconds.list 117 8814920 obspm-leap-seconds.list [root@mon /tmp]# egrep -e Update\|expires\|^'#\$'\|^'#@' *list ietf-leap-seconds.list:#Last Update of leap second values: 5 January 2015 ietf-leap-seconds.list:#$3629404800 ietf-leap-seconds.list:#Updated through IERS Bulletin C51 ietf-leap-seconds.list:#File expires on: 28 December 2016 ietf-leap-seconds.list:#@ 3691872000 navy-leap-seconds.list:#Last Update of leap second values: 6 Jul 2016 navy-leap-seconds.list:#$3676752000 navy-leap-seconds.list:#Updated through IERS Bulletin C 52 navy-leap-seconds.list:#File expires on: 1 Jun 2017 navy-leap-seconds.list:#@ 3705264000 obspm-leap-seconds.list:# Updated through IERS Bulletin C (ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat) obspm-leap-seconds.list:#$ 3676752000 obspm-leap-seconds.list:# File expires on 28 June 2017 obspm-leap-seconds.list:#@ 3707596800 [root@mon /tmp]# For now, the following workaround did get me a current file that ended up in /var/db/ after being downloaded to /var/run/ . IMHO, I have bought myself some time that this either gets fixed upstream, or until I need to keep my own site copy of the file on a web server that I'm responsible to update every 5.95 months. [root@mon /tmp]# grep leap /etc/rc.conf ntp_leapfile_fetch_opts="-m --no-passive" ntp_leapfile_sources="ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list; [root@mon /tmp]# -andreas -- Andreas Ott K6OTT +1.408.431.8727 andr...@naund.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
On Tue, 2016-08-23 at 22:40 -0700, Andreas Ott wrote: > On Sun, Aug 07, 2016 at 09:44:55PM -0700, Kevin Oberman wrote: > > On 11.0-BETA4 I have: > > > grep expires /var/db/ntpd.leap-seconds.list > > #File expires on: 1 Jun 2017 > > > > But I see what you do on 10.3-RELEASE. Looks like the update has > > not made > > it into 10 (an I would guess 9). > > The flaw is in the internal versioning of files, it does fetch the > newer > file from IETF and puts it into /var/run/ntpd.leap-seconds.list, but > although the expiry is newer, the FreeBSD onboard source version > claims > to be newer in the 'last update date in NTP timestamp format' line > ... > > FreeBSD 10.3-RELEASE-p7 onboard source is in /etc/ntp/leap-seconds, > which gets copied to /var/db/ntpd.leap-seconds.list. The fetch > IETF file downloads to /var/run/ntpd.leap-seconds.list . > > > [root@mon ~]# egrep -e Update\|expires\|^'#\$' /etc/ntp/leap-seconds > # Last Update of leap second values: 31 Dec 2015 > #$ 3660508800 > # Updated through IERS Bulletin C 50 > # File expires on: 1 Jun 2016 > [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/db/ntpd.leap > -seconds.list > # Last Update of leap second values: 31 Dec 2015 > #$ 3660508800 > # Updated through IERS Bulletin C 50 > # File expires on: 1 Jun 2016 > [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/run/ntpd.leap > -seconds.list > # Last Update of leap second values: 5 January 2015 > #$ 3629404800 > # Updated through IERS Bulletin C51 > # File expires on: 28 December 2016 > [root@mon ~]# > > with the end result that the file from /var/run/ never gets moved to > /var/db/ . > The 480.leapfile-ntpd used by periodic calls the same rc file fetch > and > comparison. > > -andreas The Last Update value reflects only additions of leap seconds to the file, and it is specifically documented that Last Update does NOT change when the file's expiration date is extended without changing the other contents. It looks like part of the problem here is that the Last Update value IS changing when the leap data itself is not. Our commit logs say the files have been obtained from USNO. Either USNO is violating the standard in their files, or the value is getting modified before it's commited to the freebsd repos. (I'm adding Cy to the CC list, since he committed them.) It looks like the fetch/install decisions in rc.d/ntpd are not quite right either. Both Last Update and Expiration date have to be taken into account. To allow for these broken files that incorrectly change the Last Update, workable logic would be to keep the file with the highest Expiration date, and if the expirations are equal, then keep the one with the highest Last Update. (I think it would be better to test Last Update first, then use Expiration as the tie-breaker, but that fails with these broken files.) Testing both Expiration and Last Update will allow for a corrected file to be published after accidentally publishing bad data, and we'd take the corrected file. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
On Sun, Aug 07, 2016 at 09:44:55PM -0700, Kevin Oberman wrote: > On 11.0-BETA4 I have: > > grep expires /var/db/ntpd.leap-seconds.list > #File expires on: 1 Jun 2017 > > But I see what you do on 10.3-RELEASE. Looks like the update has not made > it into 10 (an I would guess 9). The flaw is in the internal versioning of files, it does fetch the newer file from IETF and puts it into /var/run/ntpd.leap-seconds.list, but although the expiry is newer, the FreeBSD onboard source version claims to be newer in the 'last update date in NTP timestamp format' line ... FreeBSD 10.3-RELEASE-p7 onboard source is in /etc/ntp/leap-seconds, which gets copied to /var/db/ntpd.leap-seconds.list. The fetch IETF file downloads to /var/run/ntpd.leap-seconds.list . [root@mon ~]# egrep -e Update\|expires\|^'#\$' /etc/ntp/leap-seconds # Last Update of leap second values: 31 Dec 2015 #$ 3660508800 # Updated through IERS Bulletin C 50 # File expires on: 1 Jun 2016 [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/db/ntpd.leap-seconds.list # Last Update of leap second values: 31 Dec 2015 #$ 3660508800 # Updated through IERS Bulletin C 50 # File expires on: 1 Jun 2016 [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/run/ntpd.leap-seconds.list # Last Update of leap second values: 5 January 2015 #$ 3629404800 # Updated through IERS Bulletin C51 # File expires on: 28 December 2016 [root@mon ~]# with the end result that the file from /var/run/ never gets moved to /var/db/ . The 480.leapfile-ntpd used by periodic calls the same rc file fetch and comparison. -andreas -- Andreas Ott K6OTT +1.408.431.8727 andr...@naund.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
On Mon, 8 Aug 2016 11:11+0900, Randy Bush wrote:
> i get these on all fbsd 10.3 hosts
>
> Aug 7 04:13:06 cache0 ntpd[576]: leapsecond file
> ('/var/db/ntpd.leap-seconds.list'): expired less than 68 days ago
>
> i have
>
> # grep ntp /etc/periodic.conf.local
> # 480.leapfile-ntpd
> daily_ntpd_leapfile_enable="YES"
> daily_ntpd_avoid_congestion="NO"
>
> consulting the net of a thousand lies did not bring enlightenment.
> maybe someone here has a clue bat? thanks.
I use:
daily_ntpd_leapfile_enable="YES"
daily_ntpd_avoid_congestion="YES"
You could try updating the leapsecond file manually:
service ntpd fetch
service ntpd restart
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
> But I see what you do on 10.3-RELEASE. Looks like the update has not > made it into 10 (an I would guess 9). i will be patient. probably wait for 11.1. thanks. randy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
On 11.0-BETA4 I have:
> grep expires /var/db/ntpd.leap-seconds.list
#File expires on: 1 Jun 2017
But I see what you do on 10.3-RELEASE. Looks like the update has not made
it into 10 (an I would guess 9).
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Sun, Aug 7, 2016 at 7:31 PM, Randy Bush <ra...@psg.com> wrote:
> >> Aug 7 04:13:06 cache0 ntpd[576]: leapsecond file
> ('/var/db/ntpd.leap-seconds.list'): expired less than 68 days ago
> >>
> >> # grep ntp /etc/periodic.conf.local
> >> # 480.leapfile-ntpd
> >> daily_ntpd_leapfile_enable="YES"
> >> daily_ntpd_avoid_congestion="NO"
> >
> > For whatever reason, /etc/periodic/daily/480.leapfile-ntpd enters the
> > check phase on every invocation (daily), sleeps some random time less
> > than one day (if "avoid_congestion" true) and then decides that the file
> > is too young to replace (the current file expires June 1st, 2017). Logs
> > that to syslog .. rinse and repeat .. every day ..
>
> /me is not understanding
>
> # grep expires /var/db/ntpd.leap-seconds.list
> # File expires on: 1 Jun 2016
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
>> Aug 7 04:13:06 cache0 ntpd[576]: leapsecond file
>> ('/var/db/ntpd.leap-seconds.list'): expired less than 68 days ago
>>
>> # grep ntp /etc/periodic.conf.local
>> # 480.leapfile-ntpd
>> daily_ntpd_leapfile_enable="YES"
>> daily_ntpd_avoid_congestion="NO"
>
> For whatever reason, /etc/periodic/daily/480.leapfile-ntpd enters the
> check phase on every invocation (daily), sleeps some random time less
> than one day (if "avoid_congestion" true) and then decides that the file
> is too young to replace (the current file expires June 1st, 2017). Logs
> that to syslog .. rinse and repeat .. every day ..
/me is not understanding
# grep expires /var/db/ntpd.leap-seconds.list
# File expires on: 1 Jun 2016
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
On 08/07/16 22:11, Randy Bush wrote:
> i get these on all fbsd 10.3 hosts
>
> Aug 7 04:13:06 cache0 ntpd[576]: leapsecond file
> ('/var/db/ntpd.leap-seconds.list'): expired less than 68 days ago
>
> i have
>
> # grep ntp /etc/periodic.conf.local
> # 480.leapfile-ntpd
> daily_ntpd_leapfile_enable="YES"
> daily_ntpd_avoid_congestion="NO"
>
> consulting the net of a thousand lies did not bring enlightenment.
> maybe someone here has a clue bat? thanks.
"Broken" as designed :-(
For whatever reason, /etc/periodic/daily/480.leapfile-ntpd enters the
check phase on every invocation (daily), sleeps some random time less
than one day (if "avoid_congestion" true) and then decides that the file
is too young to replace (the current file expires June 1st, 2017). Logs
that to syslog .. rinse and repeat .. every day ..
imb
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
leapsecond file
i get these on all fbsd 10.3 hosts
Aug 7 04:13:06 cache0 ntpd[576]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): expired less than 68 days ago
i have
# grep ntp /etc/periodic.conf.local
# 480.leapfile-ntpd
daily_ntpd_leapfile_enable="YES"
daily_ntpd_avoid_congestion="NO"
consulting the net of a thousand lies did not bring enlightenment.
maybe someone here has a clue bat? thanks.
randy
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
