Re: [Sks-devel] disk full, keys.niif.hu crashed

[Keith Erekson]

Just a heads up for anyone trying to rebuild from the dump on
keyserver.mattrude.com...

Looks like something went wrong with the export, as today's dump is only
4GB, but the day before is 11GB.

Compare the README.txt files:

http://keyserver.mattrude.com/dump/2018-06-17/README.txt

http://keyserver.mattrude.com/dump/2018-06-18/README.txt

~Keith


On 06/18/2018 05:57 AM, Paul M Furley wrote:
> I'm not sure if there's a better way, but I rebuilt. If you've forgotten
> how and you're on debian, the following gist might help you:
>
> https://gist.github.com/paulfurley/b901428d1702c613531147f7573757fd
>
> Kind regards,
>
> Paul
>
> On 18/06/18 10:47, Shengjing Zhu wrote:
>> Hi,
>>
>> My server disk is also fulled with logs.
>> I tried to run db_archive, but the command never returns.
>> So I deleted all the log.* file, now I can't start the sks.
>>
>> Is there anything I can do except rebuilding?
>>
>> Thanks
>> Shengjing Zhu
>>
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>
>
>
> ___
> 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

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

[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.


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

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

[Andrew Gallagher]

On 18/06/18 11:11, Hendrik Visage wrote:
>> On 17 Jun 2018, at 14:59 , Andrew Gallagher > > 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. ;-)

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[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,

> On 17 Jun 2018, at 14:59 , Andrew Gallagher  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? 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




signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] disk full, keys.niif.hu crashed

[Paul M Furley]

I'm not sure if there's a better way, but I rebuilt. If you've forgotten
how and you're on debian, the following gist might help you:

https://gist.github.com/paulfurley/b901428d1702c613531147f7573757fd

Kind regards,

Paul

On 18/06/18 10:47, Shengjing Zhu wrote:
> Hi,
> 
> My server disk is also fulled with logs.
> I tried to run db_archive, but the command never returns.
> So I deleted all the log.* file, now I can't start the sks.
> 
> Is there anything I can do except rebuilding?
> 
> Thanks
> Shengjing Zhu
> 
> ___
> 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

Re: [Sks-devel] disk full, keys.niif.hu crashed

[Shengjing Zhu]

Hi,

My server disk is also fulled with logs.
I tried to run db_archive, but the command never returns.
So I deleted all the log.* file, now I can't start the sks.

Is there anything I can do except rebuilding?

Thanks
Shengjing Zhu

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel