First, the release notes:
Yes, this should be updated by periodic(8). But that doesn't work, unless ...
... one has outbound connectivity AND installs some port with certs (not sure how this is related to rejected mail hosts). And then, as we get a new release about once a year, that should be quite often enough for that file.
Actually, the new file gets installed during the release upgrade - but to a different place. /etc/defaults/rc.conf defines two places for the leapseconds file:
and /etc/defaults/periodic.conf
Now we're not picky about daily or weekly. And we could simply change the /etc/ntp.conf to pick that file from the other location. But I'm wondering what might be the point in the whole scheme. I mean, the actual matter is extremely trivial: on occasion, every couple of years, people may come up with a new leap-second. And then a single line needs to be added to that file, and that's all - it's a no-brainer.
Then, the /etc/rc.d/ntpd script seems to do a lot of things with these files (and the code is weird enough that I get quite reluctant to understand it), but, as shown above, it doesn't manage to get the newly installed file to the proper place:
Only if there is no file at all present at the active location, copy from the install location to the active location. (what has the comment to do with the code?)
Then, if after the copying there is still no file at the active location (sic!), run a fetch.
So, if there is an obsolete old file at the active location, nothing is done to bring the new file in after the release upgrade.
If we WOULD indeed call
Then, concerning the CERTs, /usr/src/UPDATING says this:
But then, certctl(8) says this:
That's not so very much. Checking the SVN logs to figure where these CERTs are supposed to appear, shows the only changed file in the source being /usr/src/UPDATING. Not sure what to make of this.
Searching along: the actual change happened earlier - and there the SVN log explains the new certs to appear in /usr/share/certs - where they do NOT appear; that place is empty. The SVN log also shows the src location where these CERTs should be - and that is also empty.
Somehow. the term fake news comes to my mind.
Next fun part is the actual installation - which does not succeed::
Looking into the Makefile for this one gives an interesting picture: The file in question, namely gnu/lib/libgcc/libgcc_eh.a, does only get compiled and installed when there is no compiler installed on the machine (and probably on some tier-2 archs where there is a different compiler).
So, since it is a bit difficult to compile things with no compiler installed, one could say this file gets never compiled. But it gets installed, on production machines (with no development tools) - which obviousely cannot work.
(Indeed, we're a bit old-fashioned here: we still don't install things which are entirely useless - like X on headless machines or development tools on production servers - besides, the buildworld takes ten times longer when development tools are included.)
The workaround here is to fake a proper compiler from /etc/make.conf (not fully sure about side-effects):
That's nice. But then, it doesn't install that one:The timezone database files have been updated to version 2020a.
Code:
Jul 2 04:33:30 <ntp.err> edge ntpd[4657]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired 5 days ago
Yes, this should be updated by periodic(8). But that doesn't work, unless ...
Code:
Checking for rejected mail hosts:
Certificate verification failed for /C=US/ST=CA/L=San Francisco/O=CloudFlare, In
c./CN=CloudFlare Inc ECC CA-2
673058728:error:14090086:SSL routines:ssl3_get_server_certificate:certificate ve
rify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
fetch: https://www.ietf.org/timezones/data/leap-seconds.list: Authentication err
or
Actually, the new file gets installed during the release upgrade - but to a different place. /etc/defaults/rc.conf defines two places for the leapseconds file:
Code:
ntp_src_leapfile="/etc/ntp/leap-seconds"
# Initial source for ntpd leapfile
ntp_db_leapfile="/var/db/ntpd.leap-seconds.list"
# Working copy (updated weekly) leapfile
Code:
# 480.leapfile-ntpd
daily_ntpd_leapfile_enable="YES" # Fetch NTP leapfile
Now we're not picky about daily or weekly. And we could simply change the /etc/ntp.conf to pick that file from the other location. But I'm wondering what might be the point in the whole scheme. I mean, the actual matter is extremely trivial: on occasion, every couple of years, people may come up with a new leap-second. And then a single line needs to be added to that file, and that's all - it's a no-brainer.
Then, the /etc/rc.d/ntpd script seems to do a lot of things with these files (and the code is weird enough that I get quite reluctant to understand it), but, as shown above, it doesn't manage to get the newly installed file to the proper place:
Code:
ntpd_init_leapfile() {
# Refresh working leapfile with an invalid hash due to
# FreeBSD id header. Ntpd will ignore leapfiles with a
# mismatch hash. The file must be the virgin file from
# the source.
if [ ! -f $ntp_db_leapfile ]; then
cp -p $ntp_src_leapfile $ntp_db_leapfile
fi
}
Code:
if [ ! -f $ntp_db_leapfile ]; then
ntpd_fetch_leapfile
fi
So, if there is an obsolete old file at the active location, nothing is done to bring the new file in after the release upgrade.
If we WOULD indeed call
ntpd_fetch_leapfile
, then this would still not copy the newly installed file in. But it would in turn call ntpd_needfetch_leapfile
, and THAT would (not always, but on certain conditions) copy the installed file in. This is what periodic appears to do, so, after a day, and if periodic was correctly run, the new file might actually appear. (In the past this did not work properly, because, every other year when I got bored from the messages, I just copied it into place manually.)Then, concerning the CERTs, /usr/src/UPDATING says this:
Fair enough.20200430:
The root certificates of the Mozilla CA Certificate Store have been
imported into the base system and can be managed with the certctl(8)
utility. If you have installed the security/ca_root_nss port or package
with the ETCSYMLINK option (the default), be advised that there may be
differences between those included in the port and those included in
base due to differences in nss branch used as well as general update
frequency. Note also that certctl(8) cannot manage certs in the
format used by the security/ca_root_nss port.
But then, certctl(8) says this:
Code:
# certctl list
Listing Trusted Certificates:
Searching along: the actual change happened earlier - and there the SVN log explains the new certs to appear in /usr/share/certs - where they do NOT appear; that place is empty. The SVN log also shows the src location where these CERTs should be - and that is also empty.
Somehow. the term fake news comes to my mind.
Next fun part is the actual installation - which does not succeed::
Code:
===> gnu/lib/libregex (install)
install -C -o root -g wheel -m 444 libgnuregex.a /usr/lib/
install -C -o root -g wheel -m 444 libgnuregex_p.a /usr/lib/
install -s -o root -g wheel -m 444 -S libgnuregex.so.5 /usr/lib/
install -l rs libgnuregex.so.5 /usr/lib/libgnuregex.so
install -C -o root -g wheel -m 444 regex.h.patched /usr/include/gnu/regex.h
install -C -o root -g wheel -m 444 /usr/src/gnu/lib/libregex/gnuregex.h /usr/include/
install -C -o root -g wheel -m 444 /usr/src/gnu/lib/libregex/../../../contrib/libgnuregex/regex.h /usr/include/gnu/posix/
===> gnu/lib/libgcc (install)
install -C -o root -g wheel -m 444 libgcc_eh.a /usr/lib
install: libgcc_eh.a: No such file or directory
*** Error code 71
Stop.
make[6]: stopped in /usr/src/gnu/lib/libgcc
*** Error code 1
Looking into the Makefile for this one gives an interesting picture: The file in question, namely gnu/lib/libgcc/libgcc_eh.a, does only get compiled and installed when there is no compiler installed on the machine (and probably on some tier-2 archs where there is a different compiler).
So, since it is a bit difficult to compile things with no compiler installed, one could say this file gets never compiled. But it gets installed, on production machines (with no development tools) - which obviousely cannot work.
(Indeed, we're a bit old-fashioned here: we still don't install things which are entirely useless - like X on headless machines or development tools on production servers - besides, the buildworld takes ten times longer when development tools are included.)
The workaround here is to fake a proper compiler from /etc/make.conf (not fully sure about side-effects):
Code:
HOSTNAME_S != /bin/hostname -s
.if ${HOSTNAME_S} != build
COMPILER_TYPE=clang
COMPILER_VERSION=60000
.endif