[Sks-devel] SKS (re)peering request for pgp.uplinklabs.net
I've found that my keyserver's peer list has diminished significantly in recent months, and I'm now down to six unresponsive peers, two peers alive but out of the pool, and exactly one peer in a good state: https://sks-keyservers.net/status/ks-status.php?server=pgp.uplinklabs.net Can someone please peer with my keyserver? - Steven signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Sync issues with sks 1.1.6
On 31/08/16 07:07, Christoph Egger wrote: > Hi! > > Steven Noonan writes: >> Attempted doing a dump and rebuild of my database from that, but it didn't >> help >> with this problem. Still sees those same two keys out of sync: > > Wild guess: ECC keys and your peer doesn't understand them and sends you > some data your server doesn't like > > Christoph > Ah. Could that be what's making some of the bits on my server seem to stay on my server and apparently not replicate to other SKS hosts? Maybe I don't entirely understand the recon.log file, but it seems like it talks a bunch about pulling hashes from other hosts but doesnt log anything about sending them out. -- F8D5 F819 8DEB 0703 1565 1A90 7EAC B44B A7B3 0DB9 I am tycho (https://keybase.io/tycho) on keybase. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Sync issues with sks 1.1.6
Attempted doing a dump and rebuild of my database from that, but it didn't help
with this problem. Still sees those same two keys out of sync:
==> recon.log <==
2016-08-31 04:37:02 Added 1 hash-updates. Caught up to 1472643422.340101
2016-08-31 04:37:58 error in callback.: Sys_error("Connection
reset by peer")
2016-08-31 04:38:56 2 hashes recovered from
2016-08-31 04:38:56 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:38:56 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:38:56 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:38:56 2 keys received
==> db.log <==
2016-08-31 04:38:56 Applying 0 changes
==> recon.log <==
2016-08-31 04:39:59 2 hashes recovered from
2016-08-31 04:39:59 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:39:59 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:40:00 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:40:01 2 keys received
==> db.log <==
2016-08-31 04:40:01 Applying 0 changes
==> recon.log <==
2016-08-31 04:40:54 4 hashes recovered from
2016-08-31 04:40:54 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:40:54 4C9895E31B8E52499BADB8F03A629E5F
2016-08-31 04:40:54 9C9A6B3836B3431317E1F507EBE02E69
2016-08-31 04:40:54 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:41:04 Requesting 4 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:04 4 keys received
==> db.log <==
2016-08-31 04:41:04 Applying 0 changes
==> recon.log <==
2016-08-31 04:41:13 2 hashes recovered from
2016-08-31 04:41:13 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:13 AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:41:23 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:23 2 keys received
==> db.log <==
2016-08-31 04:41:23 Applying 0 changes
Any idea what is happening here?
On 30/08/16 23:03, Steven Noonan wrote:
> I've noticed that SKS seems to be having trouble staying synced. I've seen
> it attempt to recover the same two hashes several times in a row, but
> apparently somehow not succeeding. Below is after a fresh restart of both
> the DB and recon services:
>
> ==> db.log <==
> 2016-08-30 22:47:47 Calculating DB stats
> 2016-08-30 22:47:49 Done calculating DB stats
> 2016-08-30 22:47:49 Database opened
> 2016-08-30 22:47:49 Applied filters: yminsky.dedup, yminsky.merge
> 2016-08-30 22:52:38 Applying 4 changes
> 2016-08-30 22:52:38 Adding hash 5A43BA76C61920AD131BEB229F01CE77
> 2016-08-30 22:52:38 Adding hash 5E74523E56488B6FE65FAA3C584AAABF
> 2016-08-30 22:52:38 Adding hash 98CD7C824D3BEEC91B858BF4B53BE479
> 2016-08-30 22:52:38 Adding hash EEC18519F506D79394196B5F58A1A9F0
> 2016-08-30 22:52:39 Sending LogResp size 4
>
> ==> recon.log <==
> 2016-08-30 22:52:37 5E74523E56488B6FE65FAA3C584AAABF
> 2016-08-30 22:52:37 98CD7C824D3BEEC91B858BF4B53BE479
> 2016-08-30 22:52:37 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:52:37 EEC18519F506D79394196B5F58A1A9F0
> 2016-08-30 22:52:38 Requesting 6 missing keys from [163.172.29.20]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:52:38 6 keys received
> 2016-08-30 22:52:39 Added 4 hash-updates. Caught up to 1472622758.953643
> 2016-08-30 22:53:57 2 hashes recovered from [184.105.143.180]:11371>
> 2016-08-30 22:53:57 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:53:57 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:54:07 Requesting 2 missing keys from [184.105.143.180]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:54:07 2 keys received
>
> ==> db.log <==
> 2016-08-30 22:54:07 Applying 0 changes
>
> ==> recon.log <==
> 2016-08-30 22:55:14 2 hashes recovered from
> 2016-08-30 22:55:14 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:55:14 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:55:17 Reconciliation attempt from [78.47.176.74]:51680> while gossip disabled. Ignoring.
> 2016-08-30 22:55:24 Requesting 2 missing keys from [78.46.223.54]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:55:24 2 keys received
>
> ==> db.log <==
> 2016-08-30 22:55:24 Applying 0 changes
>
> ==> recon.log <==
> 2016-08-30 22:57:47 4 hashes recovered from
> 2016-08-30 22:57:47 1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:47 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:57:47 78C2581DB360C4EAD780866602AE2BFF
> 2016-08-30 22:57:47 AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:57:48 Requesting 4 missing keys from [163.172.29.20]:11371>, starting with 1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:48 4 keys received
>
> ==> db.log &l
[Sks-devel] Sync issues with sks 1.1.6
I've noticed that SKS seems to be having trouble staying synced. I've seen it attempt to recover the same two hashes several times in a row, but apparently somehow not succeeding. Below is after a fresh restart of both the DB and recon services: ==> db.log <== 2016-08-30 22:47:47 Calculating DB stats 2016-08-30 22:47:49 Done calculating DB stats 2016-08-30 22:47:49 Database opened 2016-08-30 22:47:49 Applied filters: yminsky.dedup, yminsky.merge 2016-08-30 22:52:38 Applying 4 changes 2016-08-30 22:52:38 Adding hash 5A43BA76C61920AD131BEB229F01CE77 2016-08-30 22:52:38 Adding hash 5E74523E56488B6FE65FAA3C584AAABF 2016-08-30 22:52:38 Adding hash 98CD7C824D3BEEC91B858BF4B53BE479 2016-08-30 22:52:38 Adding hash EEC18519F506D79394196B5F58A1A9F0 2016-08-30 22:52:39 Sending LogResp size 4 ==> recon.log <== 2016-08-30 22:52:37 5E74523E56488B6FE65FAA3C584AAABF 2016-08-30 22:52:37 98CD7C824D3BEEC91B858BF4B53BE479 2016-08-30 22:52:37 AA13C5E2197D1D97DF7061D30B954060 2016-08-30 22:52:37 EEC18519F506D79394196B5F58A1A9F0 2016-08-30 22:52:38 Requesting 6 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4 2016-08-30 22:52:38 6 keys received 2016-08-30 22:52:39 Added 4 hash-updates. Caught up to 1472622758.953643 2016-08-30 22:53:57 2 hashes recovered from 2016-08-30 22:53:57 3C6042D474F66ED92D763E76BEAF6DE4 2016-08-30 22:53:57 AA13C5E2197D1D97DF7061D30B954060 2016-08-30 22:54:07 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4 2016-08-30 22:54:07 2 keys received ==> db.log <== 2016-08-30 22:54:07 Applying 0 changes ==> recon.log <== 2016-08-30 22:55:14 2 hashes recovered from 2016-08-30 22:55:14 3C6042D474F66ED92D763E76BEAF6DE4 2016-08-30 22:55:14 AA13C5E2197D1D97DF7061D30B954060 2016-08-30 22:55:17 Reconciliation attempt from while gossip disabled. Ignoring. 2016-08-30 22:55:24 Requesting 2 missing keys from , starting with 3C6042D474F66ED92D763E76BEAF6DE4 2016-08-30 22:55:24 2 keys received ==> db.log <== 2016-08-30 22:55:24 Applying 0 changes ==> recon.log <== 2016-08-30 22:57:47 4 hashes recovered from 2016-08-30 22:57:47 1411D6DD875ABB5E89B4CB389B3C3487 2016-08-30 22:57:47 3C6042D474F66ED92D763E76BEAF6DE4 2016-08-30 22:57:47 78C2581DB360C4EAD780866602AE2BFF 2016-08-30 22:57:47 AA13C5E2197D1D97DF7061D30B954060 2016-08-30 22:57:48 Requesting 4 missing keys from , starting with 1411D6DD875ABB5E89B4CB389B3C3487 2016-08-30 22:57:48 4 keys received ==> db.log <== 2016-08-30 22:57:48 Applying 2 changes 2016-08-30 22:57:48 Adding hash 1411D6DD875ABB5E89B4CB389B3C3487 2016-08-30 22:57:48 Adding hash 78C2581DB360C4EAD780866602AE2BFF 2016-08-30 22:57:49 Sending LogResp size 2 ==> recon.log <== 2016-08-30 22:57:49 Added 2 hash-updates. Caught up to 1472623068.709972 For some reason the DB doesn't appear to want to add the hashes 3C6042D474F66ED92D763E76BEAF6DE4 and AA13C5E2197D1D97DF7061D30B954060. It's also mentioning "while gossip disabled" in the recon log, but I'm not sure I understand what conditions cause that to happen. I don't have a 'dontgossip' line in my sksconf or anything like that. -- F8D5 F819 8DEB 0703 1565 1A90 7EAC B44B A7B3 0DB9 I am tycho (https://keybase.io/tycho) on keybase. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] peer request for pgp.uplinklabs.net
Resending this message with a key that isn't revoked. Doh! And thank you to those who have peered with me so far. I'm looking for peers for a new SKS keyserver installation. Hostname: pgp.uplinklabs.net Location: Bellevue, WA, USA Version: 1.1.6 IPv6: Supported This is a privately owned machine. I have loaded the 2016-08-29 dump from pgp.key-server.io, which puts me at 4,415,399 keys. For operational issues, please contact me directly. pgp.uplinklabs.net 11370 # Steven Noonan 0x7EACB44BA7B30DB9 Thanks! -- F8D5 F819 8DEB 0703 1565 1A90 7EAC B44B A7B3 0DB9 I am tycho (https://keybase.io/tycho) on keybase. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] peer request for pgp.uplinklabs.net
Hi everyone, I'm looking for peers for a new SKS keyserver installation. Hostname: pgp.uplinklabs.net Location: Bellevue, WA, USA Version: 1.1.6 IPv6: Supported This is a privately owned machine. I have loaded the 2016-08-29 dump from pgp.key-server.io, which puts me at 4,415,399 keys. For operational issues, please contact me directly. pgp.uplinklabs.net 11370 # Steven Noonan 0x7EACB44BA7B30DB9 Thanks! -- F8D5 F819 8DEB 0703 1565 1A90 7EAC B44B A7B3 0DB9 I am tycho (https://keybase.io/tycho) on keybase. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
