|
From: | tiker |
Subject: | Re: [Sks-devel] disk full, keys.niif.hu crashed |
Date: | Fri, 15 Jun 2018 17:42:13 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
Well, it turns out that the cause of our issues, the method to
re-create these keys and make things worse is already posted
publicly. Take a look at the recently reported issues on the SKS bitbucket site. I don't think my SKS node has enough storage space to survive long enough for this issue to be fixed. I may have to shut it down. Rob D On 2018-06-15 16:01, tiker wrote:
I don't think so but I could be wrong. (I'm no expert here.) Binary attachments (like images) are marked as "uat [contents ommited]". In this case, it's a "uid" row that starts the binary data instead of a text line showing a name. Here's a (temporary) link to an image of what I see: http://www.funkymonkey.org/tmp/bigkey.jpg I'll send an email to Kristian F. with the details about this key to review and comment on. Thanks. Rob D On 2018-06-15 15:24, Phil Pennock wrote:On 2018-06-15 at 12:40 -0400, tiker wrote:The problems seem to be caused by a large key. There's at least 2 different hash values for this key (so probably recently updated) and one of the versions of the key is 22mb. The size is causing timeouts on some reverse proxies and the constant retries is causing the .log files to be created and growing in the DB directory.The current advice over at https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering is to set client_max_body_size to 8 MiB.I don't think I want to post the key ID here because it's hard on the servers grabbing this key but someone should look at it and figure out what to do with this. My node only seems to sync with about 10% of its peers.Is this something with a binary image attribute? :( -Phil |
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |