We are running a normal sks instance to keep up with the peering - the instance is stopped every hour and a snapshot of the database is created - the snapshot is then used in another VM for testing.
Am 18.06.18 um 12:27 schrieb Andrew Gallagher: > On 18/06/18 11:11, Hendrik Visage wrote: >>> On 17 Jun 2018, at 14:59 , Andrew Gallagher <andr...@andrewg.com >>> <mailto:andr...@andrewg.com>> wrote: >>> >>> You can’t do it using recon, because any additions to the test server >>> will cause the key delta to diverge and recon will eventually fail. >> Do you mean that the recon *needs* a similar from the destination? > Unless recon is enabled in both directions, the key delta will > inevitably grow to the point that recon will fail. It might take a long > time, but it will happen eventually - and as the delta grows the load on > the recon partner will increase. > >> I don’t really care about it failing, > Recon failure is very messy and affects both sides of the recon. > >> the idea might be to inject problem keys into >> the tet environment, and the test environment’s problem keys not to >> “infest” the current public SKS keyservers. > The only way to reliably prevent leakage of test data into the wild is > to block all communication between test systems and production ones. A > recon that works in one direction and not the other is fine until the > day that you redeploy the server and forget to add the configuration > that blocks comms in the wrong direction! > > If you rely on a highly specific configuration to prevent utter > disaster, then utter disaster is inevitable the first time something > goes wrong. And something *will* go wrong... ;-) > >> The type of troubles we saw, I read as something that was caused as the >> updates was being recon’s between servers, after the problem keys was >> already injected, thus the idea would be multiple servers to test >> against, having some ingres feeeds from the public servers, but no >> egress to the public side. Might be good for others to test there “test >> certs/keys” against before actual publication?? > The beauty of docker images is that you can spin up as many copies as > you like and get them to recon with each other. > > For a test setup, I would strongly recommend using VMs or docker images > that have no connectivity whatsoever with the internet. Build them from > dump images and run them in an isolated environment. If you want random > people to be able to use them for testing, then enable port 80 incoming > and NOTHING ELSE. You are effectively running an infectious-prion > research lab. Treat it as such. ;-) > > > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
