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