Re: [Sks-devel] pool.sks-keyservers.net in seahorse

[Jonathon Weiss]

Phil Pennock <address@hidden> wrote:

> On 2011-03-29 at 13:59 -0400, David Shaw wrote:
> > On Mar 29, 2011, at 1:53 PM, Phil Pennock wrote:
> > 
> > > On 2011-03-29 at 12:14 -0400, Daniel Kahn Gillmor wrote:
> > >> I don't use seahorse regularly, but i recently convinced them to replace
> > >> (old, broken, non-syncing) pgp.mit.edu with a pointer to
> > >> pool.sks-keyservers.net:
> > > 
> > > Uhm, the pgp.mit.edu which is running SKS and syncing with 10 peers?
> > 
> > I recall pgp.mit.edu went to SKS, but I just looked and it's back on pksd 
> > at the moment.
> 
> So what matters is what runs on the 11371 port.  Thus:
>   http://pgp.mit.edu:11371/pks/lookup?op=stats
> 
> So any bugs are bugs in SKS.  Unsurprisingly, one of the planet's most
> popular PGP keyservers stresses the software more than most of us.
> 
> Note: I'm not protesting moves to migrate software to use pools, that's
> sane.  I read Dan's post as referring to the old non-subkey-aware setup,
> which was stale.  On re-reading, he could just have been referring to
> the recent troubles and I misinterpreted.

Following up to several different people on this recent thread:

1) I support the move from pgp.mit.edu to a pool address, as the default
   configuration for pgp clients.  I'm not any happier with my server
   being a single point of failure than anyone else is.

2) pgp.mit.edu is running SKS, and has not run PKS since I upgraded it
   18-24 months ago.

3) That said, it has had long term problems with its recon process.  The
   symptoms are similar to those that another server admin (I forget who
   off the top of my head, and don't have the mail handy) tracked down
   to timing issues on thei VM.  pgp.mit.edu is a VM running on VMware
   ESXi, so it may or may not be having the same problems.  At the very
   least I have an entirely different set of knobs and buttons to play
   with, in an attempt to correct the problem.  Additionally, the test
   that was recommended on this list showed monotonically increasing
   time, on successive calls to "date", not the same time repeating on
   occasion as was the case on the VM where the timing problem was
   identified.  If anyone has any specific advice, I'd be happy to hear
   it.  I will try to poke at this more later this week, though doing so
   will at the very least require an outage to rebuild the PTree DB for
   the recon process.

4) Yes, pgp.mit.edu was down for about 10 minutes earlier this
   afternoon.  Ironically, as a result of me poking at the sync problem
   (before having seen any of today's mail to this list).  Your timing
   in noticing was just good/bad.  Sorry if that added to any confusion.


        Jonathon

        Jonathon Weiss <address@hidden>
        MIT/IS&T/OIS  Server Operations