[Top][All Lists]

[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
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[keyserver] but it'd be nice to
have it locally as well.

Thanks for the prompt response.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]