db.log can easily be spammed by not found keys

Issue #13 resolved
Christoph Anton Mitterer created an issue

Hi.

With default log verbosity level, it happens that I see many messages like this in db.conf, when clients trie to get keys which don't exist (don't know why this happens).

2013-08-07 02:09:43 No results for request (GET,/pks/lookup?op=get&search=0x4D05A670101C2A66,[
accept:text/html, image/gif, image/jpeg, ; q=.2, /*; q=.2
cache-control:no-cache
connection:Keep-Alive
host:localhost:11371
pragma:no-cache
user-agent:Java/1.6.0_26
via:1.1 a.keyserver.pki.scientia.net:11371 (Apache/2.2.22)
x-forwarded-for:194.31.225.223
x-forwarded-host:pool.sks-keyservers.net:11371
x-forwarded-server:a.keyserver.pki.scientia.net]): No keys found

IMHO, in default there should be just a small one-liner, not the whole request printed.

Cheers,
Chris.

Comments (5)

  1. John Clizbe

    Thank you for your opinion. I cannot recall anyone complaining about this before and I've followed the project since the beginning.

    If you think there is too much info being logged at debuglevel:4, submit a patch.
    It would be wise to check with the sks-dev mailing list to see if your proposed change adversely impacts other operators.

  2. Christoph Anton Mitterer reporter

    Hi.

    That actually happened on level 3 (which I thought was the default?).

    Well I guess it's not end-of-the-world problem... likely I just reported it because I recently ran into several interesting DoS attacks, which involved servers that allowed clients to cause some excessive logging... that lead to filling the filesystem even before logrotate kicked in daily.

  3. Log in to comment