Re: [Sks-devel] pgp.gmu.edu looking for peers

[Phil Pennock]

On 2014-04-24 at 11:21 -0400, Chris Reffett wrote:
>     The student-run computing group at George Mason University has set
> up an sks server, and we are looking for peers. We are running 1.1.3
> from Ubuntu's precise-backports repository, though we plan to upgrade to
> 1.1.4 once Ubuntu 14.04 works correctly on Xen.

Since you're running under virtualization, you should either make sure
that you have a high-ticking clock or upgrade to 1.1.4 sooner rather
than later, to avoid having PTree corruption cause you to have to nuke
the database and start over.

The relevant innocuous looking line from the CHANGELOG file is:
----------------------------8< cut here >8------------------------------
  - Use unique timestamps for keydb to reduce occurrances of Ptree corruption.
----------------------------8< cut here >8------------------------------

SKS uses unique time-derived identifiers, assuming that subsequent calls
to get a nanosecond-resolution clock will always differ in value.  Where
multiple calls to `gettimeofday()` can return the same value (Windows,
various virtualization environments) this breaks some in-memory
datastructures.

With 1.1.4, SKS switched to a wrapper which ensures that subsequent
calls _always_ return incrementing values.

> 1.1.4 once Ubuntu 14.04 works correctly on Xen. Since this is a student
> group, there will be occasional operator turnover, so if there are
> problems in the future you should email our keyserver email alias, given
> below. Our membership line:
> pgp.gmu.edu 11370 # GMU Student-Run Computing and Technology
> <address@hidden>
> If there are any initial setup issues which I have not caught, please
> feel free to email me directly as well.

There's a guide at:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering
which will walk you through the steps to get a decent keyserver setup.

Your keyserver exports statistics at a special predictable URL:
  http://pgp.gmu.edu:11371/pks/lookup?op=stats

Currently, it shows that you're not generating statistics on start-up,
which means that potential peers can't tell whether or not you have keys
loaded.

Note that the reconciliation algorithm means that each peer you add
(which is also an IP whitelist for incoming connections) can create a
DoS of your server: the greater the key-count difference, the greater
the resources required to serve that peer.  So adding peers involves a
degree of trust, which is why most/many folks like to be able to see the
stats from your server, so that they can tell that it has keys and is
not likely to be a source of problems for them.

Regards,
-Phil