Re: [Sks-devel] Peering etiquette reminder

[Jeremy T. Bouse]

On 04/06/2014 06:19 PM, David Benfell wrote:
> On Sun, Apr 06, 2014 at 11:37:50AM -0400, Jeremy T. Bouse wrote:
>>     Having just spent about an hour sifting through my recon.log and
>> trying to track down the number of unauthorized gossip attempts I was
>> seeing I've stopped. I've already contacted a few that I was able to
>> identify and instead just figured I'd blanket the list as it seems to be
>> a wider issue.
>>
> I think there might be more to this than meets the eye. I just paid a
> visit to my own peering status page at:
>
> https://sks-keyservers.net/status/info/sks.disunitedstates.com
>
> I see a number of "not ok's" despite the fact that I have been in
> contact with these administrators and they agreed to peer with me. I
> have no idea what's going on here. Only one has ever contacted me to
> suggest that there was ever a problem--after I'd been aggressive about
> purging servers with whom peering didn't seem to be working.
>
> I think a larger conversation might be in order here.
>
    I know looking at your server info page at the link you listed that
keyserver.undergrid.net is obviously "Not OK" as I turned that server
off and re-pointed DNS to sks.undergrid.net's IP address but did not
automatically add entries that were peered to keyserver.undergrid.net as
I had some peers with both and had stated I woudln't do so in my notice
to the list.

    I also believe that there might be some issues in the cross-peered
"Not OK" state when dealing with load-balanced hosts like mine,
keys2.kfwebs.net, keyserver.searchy.nl & sks.fidocon.de as the nodes
behind the LB end-point typically only have the other nodes in the
cluster. This can make the status info page appear to show no peers
while the reference membership file will display more accurately the
peerings. I routinely check the reference membership file for my server
for hosts not being responsive more than I look at any of the other data
points because of that.

    I know for me I assume everything is running smoothly and only
periodically take a deeper look into things. This mornings investigation
was prompted by Christian's posting about removing peering for my host
and others because of perceived failed status which surprised me as I
had added sks.alpha-labs.net to my configuration back on my 2014-02-10
commit to my VCS repo and hadn't heard of any issues being brought to my
attention. As long as my other monitoring indicators for the reverse
proxy, drive space, running sks process, etc don't trigger an alert I go
with the belief it's working and just do a routine periodic audit. My
entire config is pushed out via Puppet using a module I wrote and
published to the Forge so I can simply add a new peer with a simple VCS
commit to my git repo which triggers a Jenkins CI job to push to my
Puppet master and it's picked up in around 30 minutes. I rarely have to
actually log into any of my servers unless there's a problem to investigate.

Regards,
Jeremy

signature.asc
Description: OpenPGP digital signature