# 11.3 -> 11.4 upgrading fun



## PMc (Jul 2, 2020)

First, the release notes:


> The timezone database files have been    updated to version 2020a.


That's nice. But then, it doesn't install that one:

```
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 ...

```
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
```
... 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:

```
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
```
and /etc/defaults/periodic.conf

```
# 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:

```
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
}
```
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?)

```
if [ ! -f $ntp_db_leapfile ]; then
                ntpd_fetch_leapfile
        fi
```
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 `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:


> 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
> ...


Fair enough.
But then, certctl(8) says this:

```
# certctl list
Listing Trusted Certificates:
```
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::

```
===> 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):

```
HOSTNAME_S != /bin/hostname -s
.if ${HOSTNAME_S} != build
COMPILER_TYPE=clang
COMPILER_VERSION=60000
.endif
```


----------



## Mjölnir (Jul 6, 2020)

File in a bug report.  Among the other issues, ntpd(8) should depend on security/ca_root_nss, like `pkg all-rdepends openntpd
ca_root_nss-3.54`.  But I have no idea how this could be done, since ntpd(8) is is the base and not a port...  Maybe this should be made clearer in the man pages or directly in the head of /etc/ntp.conf.


----------



## PMc (Jul 14, 2020)

> Among the other issues, ntpd(8) should depend on security/ca_root_nss, like `pkg all-rdepends openntpd
> ca_root_nss-3.54`.  But I have no idea how this could be done, since ntpd(8) is is the base and not a port...  Maybe this should be made clearer in the man pages or directly in the head of /etc/ntp.conf.



Yeah, You got it. But then that's maybe also the reason why these certs were said to be included into base - which, for some reason, was then reverted - only the remark in UPGRADING wasn't reverted.
Nevertheless, I wouldn't even care about that, *if* the new version would get into place during a release upgrade - this usually happens often enough.
But, as it seems, we cannot have one without the other: if we get annoyed from the error-messages of missing certs (or missing network connectivity) and switch OFF the leapfile fetch, then the new leapfile from system upgrade will also NOT be installed. ://



mjollnir said:


> File in a bug report.



Yeah that's an idea. As nobody bothers about bug reports with full patches/fixes that only need to be applied, I'm wondering what would happen with the others.

But then, always remember: we're still very much on the bright side. If you bother to look out of the window, things commonly look a lot worse already.


----------

