Re: [Sks-devel] Request for SKS gossip peers

[Andreas Thulin]

My bad, I sent my e-mail to the wrong receiver...

Also, a correction: I'm running sks version 1.1.3.

Please see below.

/A

2012/9/9 Andreas Thulin 

> Hi!
>
> I'm running Ubuntu 12.04 (64 bit) on an Asrock Ion 3D (
> http://www.asrock.com/nettop/overview.asp?Model=ION%203D%20Series#Specifications),
> 2Gb RAM.
>
> SKS version 1.1
> Berkeley version: ? - How do I find out?
>
> I'm running a fastbuild (n=1), which seemed to work for a qouple of
> minutes, but then it looked like it stopped.
>
> Running
> # strace -p processID
> first gave a lot of reads, but then has produced nothing but
>
> futex(0x7f0c1db15358, FUTEX_WAIT, 2, NULL
>
> the last 10 hours.
>
> The funny thing is that something writes to the /sks/DB directory every
> now and then. It seems to happen each time I run strace, but also at other
> times. I'm thinking maybe the "n=1" thing makes this fastbuild very slow,
> and the process hence should take several hours still.
>
> What amount of time should I expect this to take?
>
> Running this DB build with some sort of human readable periodic progress
> indication is of course preferrable.
>
> Thanks all for helpful pointers! :-)
>
> Best regards,
> Andreas
>
>
> 2012/9/9 John Clizbe 
>
>> Andreas Thulin wrote:
>> > Hi!
>> >
>> > Thanks for good advice, I'll get back on getting a dump immediately.
>> Trouble
>> > is I tried and failed a couple of times with building the DB, and the
>> sks
>> > binary doesn't really give any useful feedback on what I'm doing wrong.
>> >
>> > Would you say an e-mail to the sks devel sendlist explaining my
>> predicament
>> > could be one way of getting further in the process?
>>
>> Most certainly. Most useful data would be:
>>
>> Amount of RAM, CPU architecture sometimes matters, CPU speed doesn't.
>>
>> OS/Distro and version.
>>
>> Versions of SKS and Berkeley DB.
>>
>> Was it a fastbuild or a build?
>>
>> Did it die immediately or some time later?
>>
>> Just by way of a quick check, the most common issue that I have seen is
>> that
>> the SKS process is run as a specific user, eg, debian_sks, and that user
>> does
>> not own the directory where the databases are being created, eg,
>> /var/lib/sks.
>>
>> > Best regards,
>> > Andreas
>>
>> Good Luck,
>> John
>> --
>>
>> John P. Clizbe  Inet: John (a) Gingerbear DAWT net
>> SKS/Enigmail/PGP-EKP  or: John ( @ ) Enigmail DAWT net
>> FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
>>  mailto:pgp-public-k...@gingerbear.net?subject=HELP
>>
>> Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
>> A:"An odd melody / island voices on the winds / surplus of vowels"
>>
>>
>>
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Request for SKS gossip peers

[John Clizbe]

Andreas Thulin wrote:
> My bad, I sent my e-mail to the wrong receiver...
> 
> Also, a correction: I'm running sks version 1.1.3.
> 
> Please see below.
> 
> /A
> 
> 2012/9/9 Andreas Thulin  >
> 
> Hi!
> 
> I'm running Ubuntu 12.04 (64 bit) on an Asrock Ion 3D
> 
> (http://www.asrock.com/nettop/overview.asp?Model=ION%203D%20Series#Specifications),
> 2Gb RAM.
> 
> SKS version 1.1
> Berkeley version: ? - How do I find out?
> 
> I'm running a fastbuild (n=1), which seemed to work for a qouple of
> minutes, but then it looked like it stopped.
> 
> Running
> # strace -p processID
> first gave a lot of reads, but then has produced nothing but
> 
> futex(0x7f0c1db15358, FUTEX_WAIT, 2, NULL
> 
> the last 10 hours.
> 
> The funny thing is that something writes to the /sks/DB directory every
> now and then. It seems to happen each time I run strace, but also at other
> times. I'm thinking maybe the "n=1" thing makes this fastbuild very slow,
> and the process hence should take several hours still.

For a variety of reasons mostly personal, I have never used fastbuild only
build. n for fastbuild is the multiple of 15000 keys to load on a single pass,
For build, n is the number of key files to read in per pass. Depending on
which keydump you are using, the two may effectively be the same as 15000 is
the default number of keys to dump per file. I use n=14 (21 keys) on my
gingerbear machine which is the same hardware as the Windows XP box mentioned
below, it runs Slackware-current.

In /etc/sks, you should have a file named sksconf. Add the following two lines

pagesize:   128
ptree_pagesize: 8

The default value for pagesize is 4 (2048 bytes) and for PTree it's 1 (512
bytes). Experience has shown these to be too low. The defaults are adjusted in
the trunk version.

Make that change, stop the (fast)build. Delete any directories in /var/sks/lib
and try again. I'd use something like:

sks build -n 12 -cache 100 /var/sks/dump/*.pgp

or similar or use the build script that ships with Debian.

> What amount of time should I expect this to take?

I last built a SKS database on a Windows XP box (Athlon XP 2800+, 2.13GHz; 2GB
RAM, PATA/133 drives) back on 25 July. Times were

build:  4:18:39.734
clean:  0:03:31.031
pbuild: 1:12:11.641

That was a build with n=5. n is adjusted on each machine to a value that does
not cause swapping to occur. build depends more on the speed of your disks
than anything else.

> Running this DB build with some sort of human readable periodic progress
> indication is of course preferrable.

When I run build, I get the output like:

Build
Wed, Jul 25, 2012  1:15:51 AM
Loading keys...done
DB time:  2.95 min.  Total time: 4.74 min.
Loading keys...done
DB time:  4.88 min.  Total time: 6.74 min.
Loading keys...done
DB time:  3.69 min.  Total time: 5.28 min.
Loading keys...done
DB time:  3.78 min.  Total time: 5.29 min.
Loading keys...done
etc...

The first two lines are from my build script. clean and pbuild both have their
own log files that you can follow with 'tail -f'. clean.log tells you what
actions it is performing. pbuild.log spits out a timestamp every 5000 hashes
it processes.

> Thanks all for helpful pointers! :-)

No problem. You're welcome.

> Best regards,
> Andreas

Good luck.
-John
-- 

John P. Clizbe  Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"




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

[Sks-devel] New Keyserver

[Moritz Rudert]

Hi All,

After some downtime our keyserver is back.

So please readd me to your 'membership' file with the following
entry and provide your details in return so I can do the same:

gpg.planetcyborg.de 11370 # Moritz  Rudert 0x4941485B

Thanks
Moritz  Rudert

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

[Sks-devel] Fwd: Request for SKS gossip peers

[Andreas Thulin]

All right,

those were really good tips - the build actually looks like it's working
now (since I get the expected output).

The sks_build.sh script contains further actions:

echo "=== Running (fast)build... ==="
if ! /usr/sbin/sks $mode -n 12 -cache 100; then fail; fi
echo === Cleaning key database... ===
if ! /usr/sbin/sks cleandb; then fail; fi
echo === Building ptree database... ===
if ! /usr/sbin/sks pbuild -cache 20 -ptree_cache 70; then fail; fi
echo === Done! ===

Am I right when assuming that I need to run

# /usr/sbin/sks cleandb

and then

# /usr/sbin/sks pbuild -cache 20 -ptree_cache 70

after this build step? And are the cache options in the pbuild step OK? I'm
on a steep learning curve here... :-)

Humbly,
A

2012/9/9 John Clizbe 

> Andreas Thulin wrote:
> > My bad, I sent my e-mail to the wrong receiver...
> >
> > Also, a correction: I'm running sks version 1.1.3.
> >
> > Please see below.
> >
> > /A
> >
> > 2012/9/9 Andreas Thulin  > >
> >
> > Hi!
> >
> > I'm running Ubuntu 12.04 (64 bit) on an Asrock Ion 3D
> > (
> http://www.asrock.com/nettop/overview.asp?Model=ION%203D%20Series#Specifications
> ),
> > 2Gb RAM.
> >
> > SKS version 1.1
> > Berkeley version: ? - How do I find out?
> >
> > I'm running a fastbuild (n=1), which seemed to work for a qouple of
> > minutes, but then it looked like it stopped.
> >
> > Running
> > # strace -p processID
> > first gave a lot of reads, but then has produced nothing but
> >
> > futex(0x7f0c1db15358, FUTEX_WAIT, 2, NULL
> >
> > the last 10 hours.
> >
> > The funny thing is that something writes to the /sks/DB directory
> every
> > now and then. It seems to happen each time I run strace, but also at
> other
> > times. I'm thinking maybe the "n=1" thing makes this fastbuild very
> slow,
> > and the process hence should take several hours still.
>
> For a variety of reasons mostly personal, I have never used fastbuild only
> build. n for fastbuild is the multiple of 15000 keys to load on a single
> pass,
> For build, n is the number of key files to read in per pass. Depending on
> which keydump you are using, the two may effectively be the same as 15000
> is
> the default number of keys to dump per file. I use n=14 (21 keys) on my
> gingerbear machine which is the same hardware as the Windows XP box
> mentioned
> below, it runs Slackware-current.
>
> In /etc/sks, you should have a file named sksconf. Add the following two
> lines
>
> pagesize:   128
> ptree_pagesize: 8
>
> The default value for pagesize is 4 (2048 bytes) and for PTree it's 1 (512
> bytes). Experience has shown these to be too low. The defaults are
> adjusted in
> the trunk version.
>
> Make that change, stop the (fast)build. Delete any directories in
> /var/sks/lib
> and try again. I'd use something like:
>
> sks build -n 12 -cache 100 /var/sks/dump/*.pgp
>
> or similar or use the build script that ships with Debian.
>
> > What amount of time should I expect this to take?
>
> I last built a SKS database on a Windows XP box (Athlon XP 2800+, 2.13GHz;
> 2GB
> RAM, PATA/133 drives) back on 25 July. Times were
>
> build:  4:18:39.734
> clean:  0:03:31.031
> pbuild: 1:12:11.641
>
> That was a build with n=5. n is adjusted on each machine to a value that
> does
> not cause swapping to occur. build depends more on the speed of your disks
> than anything else.
>
> > Running this DB build with some sort of human readable periodic
> progress
> > indication is of course preferrable.
>
> When I run build, I get the output like:
>
> Build
> Wed, Jul 25, 2012  1:15:51 AM
> Loading keys...done
> DB time:  2.95 min.  Total time: 4.74 min.
> Loading keys...done
> DB time:  4.88 min.  Total time: 6.74 min.
> Loading keys...done
> DB time:  3.69 min.  Total time: 5.28 min.
> Loading keys...done
> DB time:  3.78 min.  Total time: 5.29 min.
> Loading keys...done
> etc...
>
> The first two lines are from my build script. clean and pbuild both have
> their
> own log files that you can follow with 'tail -f'. clean.log tells you what
> actions it is performing. pbuild.log spits out a timestamp every 5000
> hashes
> it processes.
>
> > Thanks all for helpful pointers! :-)
>
> No problem. You're welcome.
>
> > Best regards,
> > Andreas
>
> Good luck.
> -John
> --
>
> John P. Clizbe  Inet: John (a) Gingerbear DAWT net
> SKS/Enigmail/PGP-EKP  or: John ( @ ) Enigmail DAWT net
> FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
>  mailto:pgp-public-k...@gingerbear.net?subject=HELP
>
> Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
> A:"An odd melody / island voices on the winds / surplus of vowels"
>
>
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
___
Sk

Re: [Sks-devel] Fwd: Request for SKS gossip peers

[John Clizbe]

Andreas Thulin wrote:
> All right,
> 
> those were really good tips - the build actually looks like it's working now
> (since I get the expected output).

I've done this a few times :-)

> Am I right when assuming that I need to run
> 
> # /usr/sbin/sks cleandb
> 
> and then
> 
> # /usr/sbin/sks pbuild -cache 20 -ptree_cache 70
> 
You are correct. Both of those need to to be ran. No need to change any options.

After pbuild finishes, you should be able to start the daemons without any
problems. Be mindful to check the file ownership on the DB directories though.

Looks like you're over the hump and on your way.
> 
> Humbly,
> A

Good luck,
John

-- 

John P. Clizbe  Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"




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] New Keyserver

[John Clizbe]

Moritz Rudert wrote:
> Hi All,
> 
> After some downtime our keyserver is back.
> 
> So please readd me to your 'membership' file with the following
> entry and provide your details in return so I can do the same:
> 
> gpg.planetcyborg.de 11370 # Moritz  Rudert 0x4941485B
> 
> Thanks
> Moritz  Rudert

Hello Moritz,

Your server was never removed from mine. In case you need my membership info
again:

keyserver.gingerbear.net 11370 # John Clizbe  0xD6569825
sks.keyservers.net   11370 # John Clizbe  0xD6569825

-John

PS: Anyone seeking additional peers, please write to me off-list.

-- 

John P. Clizbe  Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"




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] Fwd: Request for SKS gossip peers

[Andreas Thulin]

So I was, thanks a lot for all your help!

redundant.dyndns.org is now up again with 3114167 keys. My ambition is to
run it permanently (although I realise the domain name suggests otherwise).

Best regards,
Andreas

2012/9/9 John Clizbe 

> Andreas Thulin wrote:
> > All right,
> >
> > those were really good tips - the build actually looks like it's working
> now
> > (since I get the expected output).
>
> I've done this a few times :-)
>
> > Am I right when assuming that I need to run
> >
> > # /usr/sbin/sks cleandb
> >
> > and then
> >
> > # /usr/sbin/sks pbuild -cache 20 -ptree_cache 70
> >
> You are correct. Both of those need to to be ran. No need to change any
> options.
>
> After pbuild finishes, you should be able to start the daemons without any
> problems. Be mindful to check the file ownership on the DB directories
> though.
>
> Looks like you're over the hump and on your way.
> >
> > Humbly,
> > A
>
> Good luck,
> John
>
> --
>
> John P. Clizbe  Inet: John (a) Gingerbear DAWT net
> SKS/Enigmail/PGP-EKP  or: John ( @ ) Enigmail DAWT net
> FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
>  mailto:pgp-public-k...@gingerbear.net?subject=HELP
>
> Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
> A:"An odd melody / island voices on the winds / surplus of vowels"
>
>
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel