Re: [Sks-devel] Running a non-pool keyserver identifying offline peers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/01/2014 12:08 PM, Pete Stephenson wrote: Dear all, ... Is there a way to have the public and private systems stay in sync, but privately? One option is using a local hostname in the peer file and put an entry in /etc/hosts for it. Another is that I can put it in the global exclude list of the pool. 2. I have recently observed lines such as the following appearing in my recon.log: 2014-08-01 07:21:36 recon as client error in callback.: Sys_error(Connection reset by peer) 2014-08-01 07:23:38 recon as client error in callback.: Unix error: Connection refused - connect() I assume this means that a remote keyserver peer is offline or otherwise not responding to recon attempts. However, the recon log does not indicate which peer is not responding, which makes diagnosing the issue a bit difficult. Is there a way of determining which peer(s) are having issues? This message also shows up if gossip is temporarily disabled due to the server currently being in a recon process with another server, so nothing needs to be wrong per se. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Be a yardstick of quality. Some people aren't used to an environment where excellence is expected. (Steve Jobs) -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT22ugAAoJEPw7F94F4TagBOoP/16QrI5zZpG/FZSs8ZaVFw9G DcMPn0ESaR6YWorLvitdjXwV6ivUSrTdtIdOBavvROT9VAqLdJsbfo6kjttxTe2Z 4mkI6DTw1E4nZlQopdTO6Yo59oBxEn80+V89Q87M4J1WCVEPxKfTOE+TDwIxJCot M6MownN9fIFYP6DJQ62wsFJary7tK6KW6Rtgh6ELYUyhr0l2y/oKkWWAaxtnopwa GvqveF9xiqoPhc0R70uvNBY6aT8wzUHdzaFAOczIJPZ3pVCupcBOk3DQMNPLVo6e 2+ue+xDGUulPXYJXERWx4XjMgi5x4V0JDKjGs5g8aHC2PlR+ECrLIZRzLc2xhd57 R7NFdRRQJW4pqkt/VIe3pt7a40S43tsEdxbyXbwTbV3d0jpZ5/6U+rwn8sjR8zii 7uGiN5xtxrcetHbPH84zzoZpFZ/EYEgcP+XZMPWW8IFbyIc1wJkrgTBJvfvGL+td eoSDJmiBa6D2zCYQYWLuRj47U1fKCxNwrCgrzdOq5Eho2hvNso2J5b34W76YiA5+ K1OvGxPYsdbKD3Mje8b1+6QX1vypQcxoW8g4egatsf6XKV8+mYrWjpW46DhlrAGh r48eXrVKk65jO6+Lp8Wn9QLI9LTqmZPQGbUSnSm2bRRXzRs8sXTqpEQGV2IiMpP1 KD4DOZZCtYbEyQz99Iuy =cklf -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Running a non-pool keyserver identifying offline peers
On 8/1/2014 12:27 PM, Kristian Fiskerstrand wrote: On 08/01/2014 12:08 PM, Pete Stephenson wrote: Dear all, ... Is there a way to have the public and private systems stay in sync, but privately? One option is using a local hostname in the peer file and put an entry in /etc/hosts for it. Another is that I can put it in the global exclude list of the pool. Interesting. I'll look into the local hostname thing -- would using that method prevent the private server from showing up in the Servers currently not in the pool listing at https://sks-keyservers.net/status/ or not? I assume that since the test systems can't access it then it won't end up in the pool. As for the global exclude list, I don't think that'd be a good thing for my purposes: - It requires effort on your part for a local project for me, and I'd hate to waste your time. - Other, less-clueful bots might discover the server and do silly things, so I'd prefer if it weren't accessible to anyone, not just the pool. 2. I have recently observed lines such as the following appearing in my recon.log: 2014-08-01 07:21:36 recon as client error in callback.: Sys_error(Connection reset by peer) 2014-08-01 07:23:38 recon as client error in callback.: Unix error: Connection refused - connect() I assume this means that a remote keyserver peer is offline or otherwise not responding to recon attempts. However, the recon log does not indicate which peer is not responding, which makes diagnosing the issue a bit difficult. Is there a way of determining which peer(s) are having issues? This message also shows up if gossip is temporarily disabled due to the server currently being in a recon process with another server, so nothing needs to be wrong per se. Excellent. That clears up that issue. On a related note, I propose a feature for future versions of SKS: add an OK/Not OK indicator for each server's stats page ([keyserver]/pks/lookup?op=stats) so an admin can easily check if all the peers are working as expected. This is currently done at https://sks-keyservers.net/status/info/[keyserver] but it'd be nice to have it locally as well. Thanks for the prompt response. Cheers! -Pete Cheers! -Pete ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Running a non-pool keyserver identifying offline peers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/01/2014 12:50 PM, Pete Stephenson wrote: On 8/1/2014 12:27 PM, Kristian Fiskerstrand wrote: On 08/01/2014 12:08 PM, Pete Stephenson wrote: Dear all, ... Is there a way to have the public and private systems stay in sync, but privately? One option is using a local hostname in the peer file and put an entry in /etc/hosts for it. Another is that I can put it in the global exclude list of the pool. Interesting. I'll look into the local hostname thing -- would using that method prevent the private server from showing up in the Servers currently not in the pool listing at https://sks-keyservers.net/status/ or not? I'd still show up in servers not part of the pool. I assume that since the test systems can't access it then it won't end up in the pool. Affirmed. ... On a related note, I propose a feature for future versions of SKS: add an OK/Not OK indicator for each server's stats page ([keyserver]/pks/lookup?op=stats) so an admin can easily check if all the peers are working as expected. This is currently done at https://sks-keyservers.net/status/info/[keyserver] but it'd be nice to have it locally as well. How would the server know if it is good or not? A keyserver can run on a stand-alone basis with 10 keys for an organization and be perfectly useful. E.g. I use single instances for key signing parties to receive keys to auto-generate lists from. So this doesn't belong in the server software, but on the abstraction layer. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Cogito ergo sum I think, therefore I am -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT24D9AAoJEPw7F94F4TagnHQQAKXXjGB1xjEPseIGyJ3Ghxib XLBlDPJpHbOvf1cIvSweklFIxKTiGSD00/bXyw6s/eFp4U97DBUfc9rUopPvxzMc q+99pTn/jGL7QBVizTnykk8LsCOSinTCEVG3lxapGrdzX+/UPKWfMdcr/Qs1XrI6 9ujkp3UKRJD4ehAOqoveXQZxcCgVdpv/xEXwyLI6yA1RRF6vjPRLnPUDg7oBpYKl fBc8O9WuI8y/NcS7WSssWNTFr7NT/1RiSrQQWGkl7B3L5WDCYlW4T/ylBJV5rh+P OofpJZIVk+x/fY0hx2CfMV/CPVImZhzn5oVwyg2rViXzyICgy0rU43O+UVjXg3IL g31aBLbbCCRIWSHNQA5cijvju8L+8CfN5p5FPpVah29YAPgNozr8t0lB8IoVQ3Eo VyO6Ufgxw9ePVo+y2BWerdd4XumNGMkR75adDiQfvhPBJRlo2+dCvZhHkaVAVjOL ZR+nepoblxjrvFP5Jg/LCuk22CiVsNiXJW9GKUGv0+RusCHjCGYioVkuTiDBCbc6 U4DsMzquJLxIfs0w5NKiekneiSeiZOf3E4s/XdfJesGW+4QYQzGCrJwqBSo8AXx7 65mJmp/XePKLCY48EGcu2oMJZeVdD9Cjb2sktkvbB3Vdcb+AG+e7zBwaaEQuywYs R/CuiiSLYIJZlzjxgrnn =djs1 -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
