> There are other definitions for "optimum" such as minimal propagation
> latency across all peers, or minimum distance to all other nodes.
> Almost certainly someone has modeled gossip protocols, lemme dig a bit.
>
> The minimum distance is likely computable simply from collecting
> a snapshot of
Hi all,
Funny, this list was working fine yesterday. Today seems to be
different
--
David Benfell
http://www.parts-unknown.org/
--- Begin Message ---
Hi all,
I'm mystified as to how I even got into this:
"PANIC: fatal region error detected; run recovery"
I see about running db_recover:
On Apr 21, 2011, at 12:52 AM, Jeff Johnson wrote:
>
> Almost certainly someone has modeled gossip protocols, lemme dig a bit.
Caveat:
This is just the 3-5 minute quick skim search. Take all my comments
as guesses.
This link
http://www.distributed-systems.net/maarten/dat
On Apr 21, 2011, at 12:38 AM, Gabor Kiss wrote:
>> Are there any recommendations for the number of peers each keyserver
>> should have in the membership file?
>
> Not yet. :-)
>
> In theory an optimal value could be computed but there are
> too many parameters (e.g. network delay and bandwidth,
> Are there any recommendations for the number of peers each keyserver
> should have in the membership file?
Not yet. :-)
In theory an optimal value could be computed but there are
too many parameters (e.g. network delay and bandwidth,
probability of hardware errors, average length of outages,
cp
Hi all,
Reviewing the logs, it appears my trouble began pretty close (I
don't know precisely) to when I did an sks dump. I'm now assuming
that's the culprit.
So several questions arise:
1) Can I use the dump I produced--apparently successfully--to
repopulate the database?
2) Should I? Or is t
Hi all,
I'm mystified as to how I even got into this:
"PANIC: fatal region error detected; run recovery"
I see about running db_recover:
debian-sks@atlanta:~/DB$ db4.8_recover -v
Finding last valid log LSN: file: 22 offset 120
Recovery starting from [21][657]
Recovery complete at Wed Apr 20 12:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Are there any recommendations for the number of peers each keyserver
should have in the membership file?
I'm hesitant to add each and every peering offer, but also want to
ensure my keyserver stays current even if one, or a few, peers are down
for a
> I have some (Debian/Slackware) VPS to spare and wonder about the
> resources needed to run SKS in the pool of keyservers. I'd build the
> database offsite and just transfer it, bandwidth is not an issue. RAM
> and CPU usage are, however.
Partial answer:
Two processes are running.
$ ps uww 1423
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sebastian Urbach wrote, On 04/20/2011 04:10 PM:
> On Wed, 20 Apr 2011 15:54:38 +0200
> markus reichelt wrote:
>
> Hi,
>
>> I have some (Debian/Slackware) VPS to spare and wonder about the
>> resources needed to run SKS in the pool of keyservers. I
On Wed, 20 Apr 2011 15:54:38 +0200
markus reichelt wrote:
Hi,
> I have some (Debian/Slackware) VPS to spare and wonder about the
> resources needed to run SKS in the pool of keyservers. I'd build the
> database offsite and just transfer it, bandwidth is not an issue. RAM
> and CPU usage are, how
Hi,
I have some (Debian/Slackware) VPS to spare and wonder about the
resources needed to run SKS in the pool of keyservers. I'd build the
database offsite and just transfer it, bandwidth is not an issue. RAM
and CPU usage are, however.
Could someone running SKS in a VPS please comment on this? Th
12 matches
Mail list logo
