Hi, everyone,
Paul Fontela wrote:
> If nothing has been modified in the configuration of the server or
> in the SKS service, what has happened?
As others have commented at length, could this indeed be related to
malicious or problematic keys?
> I have seen that some other servers that are also
Hi Phill,
Thank you very much for your interest and your answer, the server
keyserver.ispfontela.es has no problems, in fact has been able to
synchronize almost 200,000 keys in less than 2 hours, that computer is
powerful, has a large processor and a lot of RAM, the one that has a
serious problem
On 2018-06-25 at 13:08 +0200, Paul Fontela wrote:
> I have tried almost everything, from downloading a dump and starting the
> server sks again to reinstall system and everything else, the result is
> always the same, it works well for a while, sometimes an hour sometimes
> a little more and
> I have tried almost everything, from downloading a dump and starting the
> server sks again to reinstall system and everything else, the result is
> always the same, it works well for a while, sometimes an hour sometimes
> a little more and suddenly it it freezes the key server, reaching 80%
>
Hello everyone,
without the intention of sticking your finger in the wound
I have spent almost 10 days investigating the problem that I see related
in different threads of the list [Sks-devel], the falls of the sks
servers for abuse of requests.
I have tried almost everything, from
I am afraid there is not much you can do about this right now - the pool
itself is very unstable and crashes multiple times per day.
I found over 8 key hashes which cause an Eventloop - this happens every
2-3 minutes, sometimes with the same key, sometimes with other keys.
Best regards,
Am
On 6/17/2018 12:59 AM, Paul M Furley wrote:
> Hi Pete,
>
>> 2. Is there some countermeasure one can use to protect their server? I
>> have LimitRequestBody set to 800 (8MB) to prevent blatant abuse, but
>> clearly something is still annoying the server.
>
> It appears from Rob's previous
On 6/17/2018 12:59 AM, Paul M Furley wrote:
> Hi Pete,
>
> On 17/06/18 04:53, Pete Stephenson wrote:
>> Thanks.
>>
>> I then have three more questions:
>>
>> 1. If this issue is affecting my server to the point of it being booted
>> from the pool (since it's stalling near-continuously and can't
I have an idea about this, however i am not sure that this is still the
same problem.
The spider who queries the availability of the keyservers requests
/pks/lookup?op=get=0x16e0cf8d6b0b9508 - which contains the
problematic key (just look it up..).
I am not sure that this is the actual problem,
Hi Pete,
On 17/06/18 04:53, Pete Stephenson wrote:
> Thanks.
>
> I then have three more questions:
>
> 1. If this issue is affecting my server to the point of it being booted
> from the pool (since it's stalling near-continuously and can't respond
> toe queries), why are other servers not being
Hi,
seems like that is the "problem":
https://bitbucket.org/skskeyserver/sks-keyserver/issues/60/denial-of-service-via-large-uid-packets
https://bitbucket.org/skskeyserver/sks-keyserver/issues/57/anyone-can-make-any-pgp-key-unimportable
Best regards,
Moritz
Am 17.06.18 um 02:18 schrieb Pete
On 6/16/2018 5:18 PM, Pete Stephenson wrote:
> Hi all,
>
> My server, ams.sks.heypete.com, has been suffering from periods where
> the amount of CPU used by the sks process goes to 100% for a few minutes
> at a time. During this time, my Apache reverse proxy produces errors of
> the following
Hi all,
My server, ams.sks.heypete.com, has been suffering from periods where
the amount of CPU used by the sks process goes to 100% for a few minutes
at a time. During this time, my Apache reverse proxy produces errors of
the following type (client IP address obfuscated for their privacy):
[Sun
13 matches
Mail list logo