* libor.peltan [2018-10-31 11:03]:
> Please try purging the journal (or deleting it directly on the filesystem)
> and restarting the server.
Yeah, that worked...
Regards
Sebastian
--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S
Please try purging the journal (or deleting it directly on the
filesystem) and restarting the server.
Dne 30.10.18 v 17:00 Sebastian Wiesinger napsal(a):
* libor.peltan [2018-10-30 15:04]:
Hi Sebastian,
i don't see clearly what happened in your case. It seems for some reason the
history
* libor.peltan [2018-10-30 15:04]:
> Hi Sebastian,
>
> i don't see clearly what happened in your case. It seems for some reason the
> history stored in journal (just changes) was no longer appliable on the
> zonefile. Nothing terrible, just one annoying warning and a bit more
> annoying AXFR
Well, journal is a complicated piece of stuff to handle. There are many
use-cases (from just IXFR to zone-in-journal) and situations (many small
zones, one big zone, some combination) which behave differently. There
are some more-or-less obvious technical limits. Many users have their
zones by
Hi Sebastian,
i don't see clearly what happened in your case. It seems for some reason
the history stored in journal (just changes) was no longer appliable on
the zonefile. Nothing terrible, just one annoying warning and a bit more
annoying AXFR from slaves (instead of IXFR). Anyway, I would
* libor.peltan [2018-10-29 16:20]:
> 2) No, "discontinuity in changes history" is not expected. Could you please
> describe what did you do before such warning appeared, with longer snippets
> of the log? In any case, there is no need to be scared of journal getting
> full, once you read the
* libor.peltan [2018-10-29 16:20]:
> 2) No, "discontinuity in changes history" is not expected. Could you please
> describe what did you do before such warning appeared, with longer snippets
> of the log? In any case, there is no need to be scared of journal getting
> full, once you read the
Hi Sebastian,
1) that's OK. You don't need to worry about that warning unless you edit
the zonefile on the signer manually. You can also consider zonefile-less
signer, either completely headless (needs AXFR after each daemon start)
or with the zone stored in journal (needs some thoughts
Right now I have two zone types for my knot test setup, one where knot
is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and
one where the knot is the master for the zone and zone data is coming
out of a git repository and gets signed.
Reading older threads on this ML and browsing