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 > <k...@srct.gmu.edu> > 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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel