mirrors/hockeypuck
1
0
Fork 0
mirror of https://github.com/hockeypuck/hockeypuck.git synced 2025-12-17 08:55:43 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
Page: Migrating from SKS‐keyserver to Hockeypuck
Pages
HIP 000: Hockeypuck Improvement Proposals HIP 001: [REVERTED] Regaining control over public key identity with authenticated key management HIP 002: SKS v2 protocol HIP 003: Timestamp aware merge strategy HIP 004: Third party revocation sig distribution HIP 005: Reliable personal data deletion using self signatures HIP 006: WKD support HIP 007: Recursive resolver HIP 008: Out of Band Email Ownership Proof HIP 009: Management Interface HIP 010: Internal rate limiting support HIP 011: Merge ptree into pghkp HIP 012: Define and use JSON‐LD schemas HIP 013: In‐Band Metadata Sync Using Trust Packets Home Migrating from SKS‐keyserver to Hockeypuck Semantic Versioning Policy Upgrading docker‐compose standalone deployment from 2.1 to 2.2
9 Migrating from SKS‐keyserver to Hockeypuck
Andrew Gallagher edited this page 2025-12-16 13:51:10 +00:00
Table of Contents

Prerequisites

A production dataset of ~6M keys will require ~40GB of disk space for postgres and ~15GB for the dump files.

Hockeypuck requires PostgreSQL. You will normally have to create a fresh database in PostgreSQL, and a user account with full privileges on that database. The only exception is if you are using the docker-compose/standalone deployment template, which will provision a PostgreSQL instance automatically.

A public-facing instance of Hockeypuck SHOULD be located behind a haproxy instance with connection rate-limiting enabled. This is most easily done using the docker-compose/standalone deployment template. Otherwise, the haproxy configuration can be extracted and implemented separately.

Migration

To migrate from SKS-keyserver to Hockeypuck:

It is recommended not to enable any partner keyservers when initially setting up and testing Hockeypuck. Most keyserver operators will wish to test your haproxy rate limiting before peering - this ensures that no one keyserver can be used as a back door for abuse into the rest of the network. In addition, existing sync partners may see a large delta of keys when re-connecting to your new Hockeypuck instance, and this may result in unnecessary network and/or disk traffic. Please compare notes with your partners before re-enabling sync.