SKS (Synchronising Key Server) Setup

The documentation wiki for SKS has been down for a while and building it on Ubuntu Dapper turned out to require a couple of minor tweaks, so this is my crib sheet for how to get it up and running. It's a compilation of wiki content extracted from Archive.org, the README, and my own notes.

References

Build SKS

apt-get install ocaml-dev

FIXME

wget tar zxf sks- cd sks-

FIXME

mv Makefile.local.au Makefile.local

Edit Makefile.local: change "libdb-4.1" to "libdb4.2";

change "BDB=-L/usr/lib" to "BDB=-L/usr" make dep
make all
sudo -s
make install
mkdir /sks
cd /sks
mkdir dump
cd dump

Pre-Populate Database

Rather than starting with an empty database and attempting to populate it by syncing with other keyservers (a bad idea because it loads up your peers with lots of traffic and will probably fail anyway with deadlocks in the conflict resolution system) we'll grab a static dump from an existing SKS server. There are a couple of sources out there, including:

ftp://ftp.pramberger.at/services/keyserver/keydump/
ftp://ftp.prato.linux.it/pub/keyring/

Download Keydump

The keydump is about 3.3GB as of October 2007, so fetching it will take a long time. It's divided into a bunch of individual numbered files so you'll need to fetch all of them. Because I'm too lazy to spend 8 hours sitting there doing it manually I did it like this:

mkdir /sks/dump;
cd /sks/dump;
wget --recursive --timestamping --level=1 --cut-dirs=3 --no-host-directories ftp://ftp.pramberger.at/services/keyserver/keydump/

Many hours later, check that all the pieces downloaded correctly by verifying their checksums against the list published by the dump provider:

wget ftp://ftp.pramberger.at/services/keyserver/keydump/MD5SUMS
for name in *.pgp; do md5sum $name >> MD5SUMS2; done
diff MD5SUMS MD5SUMS2

If the final command doesn't return anything it means your locally calculated checksums match the expected values and everything's cool.

Build Local Database

There are two ways to do this: either a full build (which reads in the dump you just downloaded and leaves you with a complete, self-contained database) or a fastbuild (which just references the dump and requires it to be left in place after the fastbuild is complete). I started doing a full build, it looked like it was going to take forever so I aborted it and switched to a quickbuild. On the 4-processor machine I was using it still took in the order of 40 minutes to run so this might take a while.

You need to be in the basedir when running this and the dumps have to be in a sub-directory called "dump" (which they should be if you followed the steps above), so:

cd /sks
/usr/local/bin/sks_build.sh

If you edit the sks_build.sh script you'll discover it's just a shell script which calls SKS itself to do the heavy lifting. If you have trouble with lack of memory you may need to tweak the script a bit: in particular the "-n 10" flag used in the fastbuild call is a multiple of 15,000 keys to load at a time. The default setting therefore loads 150,000 keys at a time which could cause your machine to go into swap, and changing to something like "-n 2" will cause it to load only 30,000 at a time instead and possibly complete the job faster. The trick is to load as many as possible in each pass without hitting swap - if that happens, performance falls through the floor and you may as well abort it and start again (after deleting the KDB and PTree directories created by the aborted import).

If all goes smoothly you'll end up with KDB and PTree directories in /sks.

Create SKS Config File

/etc/sksconf is the main config file which is read on startup. This is my actual config file with my values, so change to suit your requirements:

# sks configuration for keys.keysigning.org
# Set the logfile to $basedir/log.[db|recon]
logfile: log

# debuglevel 4 is default (max debug level is 10)
debuglevel: 4

# Set the hostname of the server
hostname: keys.keysigning.org

# Set the email address we use to sync with other keyservers
from_addr: keysync@keys.keysigning.org

Set Up Peer Communications

It's important that changes made in both the SKS and PKS keyserver networks propagate to each other.

SKS Gossip

Internally the SKS network uses "gossip" to propagate changes around, so as long as your keyserver is gossiping with other servers which in turn gossip with others etc etc then you'll be fine internally and all changes will eventually make it to and from your server. You don't need to be gossiping with every other SKS server, just a couple.

Ask on the sks-devel list for servers to gossip with, and put an entry for them in /sks/membership like this:

FIXME

PKS Email Sync

The PKS network operates differently: it uses email notifications for internal notifications, so to make sure that changes made on your server reach the PKS network you need to send out sync emails to a cooperative PKS server. SKS servers will only send sync emails for changes that were initiated locally, so having other SKS servers to gossip with is *not* enough to get changes out to the PKS network. You must also set up mailsync.

Put something like this in /etc/mailsync:

# Send an email notification to this server when a key is added so that
# all new keys propagate to the PKS network
#pgp-public-keys@keyserver.kjsl.com

You'll need to add the (uncommented) email address of the PKS peer, but don't just do this without their permission or they might get upset.

Start DB Server

Finally time to start it up! Amazingly this is the point where I really came unstuck because nowhere in the README or on the archived wiki does it tell you what you need to do to start the actual server. I don't know if this is technically correct, but some poking around in the source led me to this and it seems to work so please let me know if this is not correct.

The main sks binary wraps a whole bunch of operations including the DB build stuff we just did. One of the operations is "db", which starts the main db server:

cd /sks
/usr/local/bin/sks db &

So that you can see what's going on, put a tail on the db logfile:

tail -f /sks/db.log

By default your new server will be running on port 11370 (the normal PGP/GPG server port) so edit your ~/.gnupg/options file on your workstation and select your keyserver with an entry like:

keyserver 1.2.3.4

where 1.2.3.4 is the IP address or hostname of your keyserver.

Then do something like:

gpg --recv-keys 64011A8B

and you should successfully pull down the key, as well as see the action appear in the DB log. Success! You now have a (partly) functioning keyserver.

Start Recon Server

Once again this is just my interpretation so I may be wrong, but the next step seems to be starting the recon server that handles synchronising with other servers.

cd /sks
/usr/local/bin/sks recon &

Check the operation with a tail on the recon logfile:

tail -f /sks/recon.log

Process Incoming Sync Email

aliases

FIXME

Server Statistics

SKS generates database statistics internally and makes a report available with details of all peers and the internal stats. Because generating the report puts quite a heavy load on the server it's only done once each day.

You can access the stats for your server by pointing a browser at "/pks/lookup?op=stats" on port 11371, similar to this:

http://keys.keysigning.org:11371/pks/lookup?op=stats

Firewall Issues

If you run a firewall in front of your keyserver (or iptables rules directly on it) you need to make sure certain ports are open. The critical ports are:

TCP 11370 (for reconciliation with other keyservers)
TCP 11371 (for HTTP connections)