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

[David Shaw]

On Mar 29, 2011, at 2:30 PM, Jonathon Weiss wrote:

> 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.

Thanks for clarifying everything.

I assume you've read the VMware guide to time sync issues?  I've found it 
helpful when I had similar issues, but not helpful enough.  In one case, the 
clock was slipping enough that the recommended kernel timing parameters and 
ntpd was not able to correct it, and the user finally gave up and just ran 
'ntpdate' via cron every 30 minutes to forcibly set the clock (with all the 
usual problems that jumping the clock can bring).

David