19.04.2022 23:38, Dennis Filder wrote:
I wasn't CC'ed, thus the late reply.
I didn't know either, Dennis. I just replied to the bug :)
But now I've a question: how the initial problem happened?
Okay, it smells like it is, and it definitely it should not be
copied from /usr/share/dns/root.key..
What can I say? My /var partition became full (too many .deb files
IIRC) and unbound.service wouldn't start because of an unusable trust
Yeah, I see it quite well now how exactly things went wrong, and
you confirm my thoughts.
And the root cause was using install/cp to create the file, --
neither of which do it atomically. So any error during the
copy and we'll have some bad file out there. Even for a small
file like this - today we have filesystems with inline data,
when small files are written directly into the directory,
and only for larger files a real extent is allocated, -
this root.key is enough to flip from inline to extent (which
we might not have).
anchor file (which was empty). How exactly that happened I have no
idea. It may have been from unbound trying to replace root.key with
its own changes and failing, but looking at the code
(validator/autotrust.c:autr_write_file()) that should have left the
old version in place upon failure. So maybe it was from
package-helper trying to copy over the existing file for some other
It definitely is. Because install/cp which was used.
...
As far as I see it a problem also was that (in the old version) after
the reboot the package-helper script only tried to overwrite
/var/lib/unbound/root.key when it was older than
Because no one thought about possible partial file in there.
It should never be partial. And this update ensures just that.
Well, there still *is* a possibility here, but I don't know if
any real modern filesystem allows this: a file should be comitted
to disk before the final rename completes.
...
Am I right this is just the initial key and unbound updates this key
automatically by its own?
I think so, but I'm not sure. My knowledge of both unbound and the
details of DNSSEC is rather spotty.
It is the initial value and unbound will keep it updated.
P.S.: I also noticed that unbound.service under [Service] defines no
StateDirectory=/var/lib/unbound to ensure that it is mounted on start.
Hmm this is a good idea to add this.
The chroot setup procedure has its own load of issues.
I see. Maybe adding just
After=var.mount var-lib.mount var-lib-unbound.mount
I think StateDirectory helps here.
Thank you!
/mjt
