5 Úno
2021
5 Úno
'21
17:16
On 2021-02-05 04:01, Marek Szuba wrote:
On 04/02/2021 16:46, Chris wrote:
That is of course possible. I felt qualified to
pose a possible solution.
As I had to move a couple of zones from a server we were retiring to a
different server. Which ran a newer version of knot by more than a couple
of points. As memory serves. I froze the zones prior to dumping. Tarred
them up, and then transferred them. Again, as I recall. I got errors
indicating
that the DB was incompatible. So I *think* I simply purged *all* history on
the
transferred zones. shut down knot. Deleted the zone DBs. Ensured that the
(transferred) zone algos were consistent in the newer (knot) version. Then
leaving the keys in the zone files. Asked knot to load them on restart. And
that was that. Your mileage may vary. ;-)
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.
LOL. Yep. I did. I was pondering
a problem someone mentioned on another
mailing
list I'm subscribed to regarding unbound, when I was answering you -- DO'H!
;-)
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.