[Sks-devel] One Way replication (for test environments)

[Hendrik Visage]

I’m considering setting up some test environments for the “researchers” to test the SKS keyservers, but I was wondering about one way replication, ie. one server that will only sent out to the test server(s), but not receive from them.

What’s the easiest to set that up?

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
[phone] or [phone]
***@envisage.co.za

[Andrew Gallagher]

I’m considering setting up some test environments for the “researchers” to test the SKS keyservers, but I was wondering about one way replication, ie. one server that will only sent out to the test server(s), but not receive from them.
What’s the easiest to set that up?

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. The easiest way might be a docker image that pulls the latest dump from one of the public dump sources and spins up a fresh SKS instance from it. Then if you want to update the key database, you just redeploy the docker image.

A

[Hendrik Visage]

Well, the idea would be for these “researchers” to play with, and at least have something “newish” where I have some ingress point that propagates to some others,

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? I don’t really care about it failing, it’ll then be a re-spin as you said below, but for example, 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 easiest way might be a docker image that pulls the latest dump from one of the public dump sources and spins up a fresh SKS instance from it. Then if you want to update the key database, you just redeploy the docker image.

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??

---
Hendrik Visage

[Andrew Gallagher]

Post by Hendrik Visage

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.

Post by Hendrik Visage
I don’t really care about it failing,

Recon failure is very messy and affects both sides of the recon.

Post by Hendrik Visage
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... ;-)

Post by Hendrik Visage
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. ;-)

[Moritz Wirth]

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.

Post by Andrew Gallagher

Post by Hendrik Visage

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.

Post by Hendrik Visage
I don’t really care about it failing,

Recon failure is very messy and affects both sides of the recon.

Post by Hendrik Visage
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... ;-)

Post by Hendrik Visage
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Matthew Walster]

Probably to block TCP on the recon port for that direction?

M

Post by Hendrik Visage
I’m considering setting up some test environments for the “researchers” to
test the SKS keyservers, but I was wondering about one way replication, ie.
one server that will only sent out to the test server(s), but not receive
from them.
What’s the easiest to set that up?
---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
[phone] or [phone]
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[William Hay]

I=E2=80=99m considering setting up some test environments for the =
=E2=80=9Cresearchers=E2=80=9D to test the SKS keyservers, but I was =
wondering about one way replication, ie. one server that will only sent =
out to the test server(s), but not receive from them.
What=E2=80=99s the easiest to set that up?

Never tried it but might not the old e-mail based replication method work for this?

William