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 -- https://lists.nic.cz/mailman/listinfo/knot-dns-users
