Re: High rate of updated keys
I have not investigated closely, but I noticed that after a restart of the Hockeypuck server, several hundred "updates" are being processed (I am using the version which does negative caching of recon attempts which did not result in updates). So, maybe we need to look closer at what actually counts as an "update" for Hockeypuck. An alternate explanation would be that the changes being applied are not idempotent or cumulative, e.g., that some UIDs or signatures are being reordered, which is counten as an update. And, in theory, several of those changes might be circulating in the network, updating each other again and again (even though I guess that over time, some of the updates should "win" over the others). But as I said, I'm just guessing wildly right now. -Marcel Am Dienstag, dem 11.05.2021 um 15:10 +0100 schrieb Andrew Gallagher: > On 08/05/2021 20:23, Andreas Puls wrote: > > Im running on both of my servers the deafult value. > > I think the main difference between pgpkeys.eu and other hockeypuck > installs is that pgpkeys.eu recons directly with three of the biggest > SKS pool members, while most other hockeypuck installs do not. I > temporarily disabled recon with all SKS peers and the number of > modified > keys immediately fell back to normal levels. > > I suspect this may be related to the hockeypuck/SKS recon thrashing > problem that Marcel diagnosed - the number of updated keys does not > seem > to reflect actual updates but rather update attempts, and as the SKS > and > Hockeypuck datasets have diverged, so have the number of repeated > sync > failures. This would appear to have been growing slowly for some > time. > > I'm still not sure why pgpkeys.eu has been disproportionately > affected - > other hockeypuck nodes have several SKS peers and haven't suffered to > the same extent. I suspect it may be an artifact of the topology - > perhaps pgpkeys.eu is getting different update sets from two > different > sources and they keep overwriting each other, or some such. > > Investigations continue... :-) > signature.asc Description: This is a digitally signed message part
Re: High rate of updated keys
On 08/05/2021 20:23, Andreas Puls wrote: Im running on both of my servers the deafult value. I think the main difference between pgpkeys.eu and other hockeypuck installs is that pgpkeys.eu recons directly with three of the biggest SKS pool members, while most other hockeypuck installs do not. I temporarily disabled recon with all SKS peers and the number of modified keys immediately fell back to normal levels. I suspect this may be related to the hockeypuck/SKS recon thrashing problem that Marcel diagnosed - the number of updated keys does not seem to reflect actual updates but rather update attempts, and as the SKS and Hockeypuck datasets have diverged, so have the number of repeated sync failures. This would appear to have been growing slowly for some time. I'm still not sure why pgpkeys.eu has been disproportionately affected - other hockeypuck nodes have several SKS peers and haven't suffered to the same extent. I suspect it may be an artifact of the topology - perhaps pgpkeys.eu is getting different update sets from two different sources and they keep overwriting each other, or some such. Investigations continue... :-) -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature
Re: High rate of updated keys
Hi Andrew, Am 06.05.2021 um 15:07 schrieb Andrew Gallagher: Hi, all. I'm noticing recently a large number of updated keys in pgpkeys.eu (hockeypuck), on the order of several thousand per hour. The total number of keys is not increasing unusually, just the modifications. I notice that both andreas-puls servers and utwente.nl seem to be experiencing similar activity (an order of magnitude less, at tens to a few hundred per hour), while other pool members seem unaffected (single digits of updates per hour). Can I ask hockeypuck operators what filter values they are using? pgpkeys.eu is currently set to: maxPacketLength=65536 maxKeyLength=1048576 Im running on both of my servers the deafult value. IIRC this should be: #maxPacketLength=8192 #maxKeyLength=1048576 This is more generous than the defaults, which makes me wonder if the root problem is that it is allowing abusive keys that others are filtering out. On a possibly related note, sks.pgpkeys.eu (sks) is timing out repeatedly during incoming bulk requests from its recon peers. It seems to manifest as "End_of_file" errors in the SKS logs as the reverse proxy gives up. Has anyone else seen similar issues? Thanks, A Br Andreas
