5 Úno
2021
5 Úno
'21
13:01
On 04/02/2021 16:46, Chris wrote:
I am by no means an expert here. But from my
experience. If the DB is
somehow not supported. The log will be filled with messages
indicating that.
I thought it might have been something like that, especially given this
server runs on arm and the old master was an amd64 box; as a matter of
fact I *had* to use the dump-and-restore procedure for the KASP database
because the copied LMDB files had not been recognised as valid, by
either knotd or lmdb-utils.
That said, this also happens when Knot is launched on that server with
NO databases present. Yesterday evening I tried shutting knotd down,
deleting everything except the plain-text zone files from /var/lib/knot,
restarted - and as soon as Knot had generated new KSK and ZSK the log
spam started anew.
I honestly don't know what is going on here. It's as if there was
something wrong with this specifically on arm...
BTW. All the systems discussed here run Debian Buster and use Knot .deb
packages from deb.knot-dns.cz.
Another thought that comes to mind; You indicated you
transferred
data from one machine to another. Did the perms change in any way?
IOW Can unbound read/write to the transferred data files? Are they
owned by the user unbound was/is installed as?
I take it you meant knot and not unbound here :-) I've just checked
again and all the file-system permissions are exactly the same, apart
from the fact that the user and the group "knot" resolve to different
UIDs/GIDs on the two machines.
--
MS