[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Running a non-pool keyserver & identifying offline peers
From: |
Pete Stephenson |
Subject: |
Re: [Sks-devel] Running a non-pool keyserver & identifying offline peers |
Date: |
Fri, 01 Aug 2014 12:50:20 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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