Dear Maintainer,

Powerdns server log format is probably changed. Service name is no
simple "pdns" any more but "pdns_server". So regular expressions
should be changed from this

^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ pdns\[[[:digit:]]+\]: blahblahblah

to

^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ pdns(_server)?\[[[:digit:]]+\]: blahblahblah

Gabor

On Thu, 14 Nov 2024 07:03:14 +0100 Gabor Kiss <kissg@probatbicol.hu> wrote:

(I dont know why, but gmail did not send me this bug report,  although
it made it to the bts.
hopefully the reply works ok!)

can you expand on why "probably"? if it's changed in a version that is
in testing (ie will be in stable)
then we should use pdns_server always. If it's been split into
different binaries we should use this opportunity
to check each rule: pdns is not something i use and there's a lot of
rules: are they all still valid?

(In my new macro-enabled branch this can be done with a one-line change :)

so is it always pdns_server (or pdns_resolver)?

Are these produced in normal operation or just on startup - we usually
dont include rules for messages that are only produced on
startup/shutdown
because it adds a lot of rules, and it can be useful to find out that
something has restarted unexpectedly. These all look like ones we
wouldn't cover
(If it's intended that it is restarted every day, or regularly reloads
things then this wouldnt apply and we'd include them).

I'm also interested in removing rules that are no longer produced at all

I do not use the resolver so I do not know, but I think so.

The above are startup messages.

I could help more if I knew what is the concept. What kind of messages
are to be filtered?

Gabor

On Sun, 17 Nov 2024, 10:14 Kiss Gabor (Bitman), <kissg@probatbicol.hu> wrote:


something like: log messages which are
 1. produced durinng normal operation and
 2. dont indicate something is odd/wrong/unusual/needs investigation.

(1) is really to try and reduce the noise -- if the system reboots you are
guaranteed a long report that you wont read so filtering startup messages
isnt worth the trade-off. The things you would skip if you read the logs
manually.

when logcheck started it was about detecting security issues but that that
wasnt sustainable. nowadays it's really meant to reduce the contents of the
log(/journal) to interesting messages that indicate issues/problems

It's a bit of a judgement call --- for a dns server, we would likely want
to filter most error messages ("cant resolve domain xxx"/"dnssec failed")
because realistically dns is full of crap and no-one is going to follow-up
most failures -- it's possibly one where each user would really want to
think hard about what is interesting to see reported.