Re: Key server status

2024-03-07 Thread Skip Carter
I just tried uploading to the ubuntu server. 2024-03-07 18::08 GMT
uploading to the ubuntu server.  The response was:

{"inserted":null,"updated":null,"ignored":["rsa4096/05fa40b23af5025974c
3b1a6c62aa8645d00d25b"]}

I will check later if it sticks.

(For proper public access I also updated my key at keyserver.pgp.com

On Thu, 2024-03-07 at 09:54 -0800, Todd Fleisher wrote:
> I would challenge that the ubuntu server is even well maintained for
> day-to-day issues currently. My PGP key (0x 949D203A) was uploaded
> directly to their server in the past as well as being available on my
> nodes which they used to peer with. However, keyserver.ubuntu.com
> began to intermittently respond with 404 not found errors when
> searching for it (at least) almost 1 year ago when I began monitoring
> it on May 1 2023. It remained that way until June 19, 2023  at which
> point it started responding with 404 not found errors 100% of the
> time as you can see here:
> https://i.ibb.co/rcBJXbg/Screen-Shot-2024-03-07-at-09-45-53.png
> 
> I’d be curious to know if Skip or anyone else has had similar
> experiences after trying to upload their key directly to canonical’s
> server and then checking back to see if it is retained & made
> available to clients that query for it.
> 
> Not to be totally negative, as Andrew is correct that we may finally
> be making some progress with direct outreach to a new contact @
> Canonical whereas even that failed in the past with individuals who
> were responsible for their keyserver (e.g. handled peering requests
> and the like). Fingers crossed.
> 
> -T
> 
> > On Mar 7, 2024, at 09:15, Andrew Gallagher via SKS development and
> > deployment list  wrote:
> > 
> > On 7 Mar 2024, at 16:47, Skip Carter  wrote:
> > > 
> > > I have found that the keyservers are not properly synced:
> > > 
> > > The MIT server has my key from 2023-03-29
> > > but the Ubuntu server has only my old expired key 2019-04-10 (4
> > > years
> > > out of date!).
> > 
> > The MIT server is effectively running unmaintained at the moment.
> > It is a single-threaded sks-keyserver node with severe stability
> > issues. We have tried engaging with them on several occasions but
> > there has been no reply. I would not recommend relying upon it.
> > 
> > The Ubuntu keyserver is well-maintained for day to day issues, but
> > there is some disconnect internally between their SRE teams and
> > their support desk. We are making some progress and hope to be back
> > in sync shortly.
> > 
> > You can see the current sync state of the graph at
> > https://spider.pgpkeys.eu/graphs
> > 
> > A
> > 
> 

-- 
Dr Everett (Skip) Carter 0xC62AA8645D00D25B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955

831-641-0645 x103




Key server status

2024-03-07 Thread Skip Carter

I have found that the keyservers are not properly synced:

The MIT server has my key from 2023-03-29
but the Ubuntu server has only my old expired key 2019-04-10 (4 years
out of date!).


Whats up with that ?

-- 
Dr Everett (Skip) Carter 0xC62AA8645D00D25B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955

831-641-0645 x103




Re: sks.infcs.de online with hockeypuck server /// take down // Re: keyserver.insect.com GDRP takedown request

2022-06-15 Thread Skip Carter
Yes this server is down, too many frustrations with administering
hockeypuck.

On Wed, 2022-06-15 at 13:33 +0200, Steffen Kaiser wrote:
> 
> 
> 
> keyserver.taygeta.com 11370 (down?)
> 



-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




Re: State of the graph

2021-12-14 Thread Skip Carter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It looks like the cluster is collapsing. A year ago I had 18 peers, now I have
8.

On Mon, 2021-12-13 at 10:38 +, Andrew Gallagher wrote:
...
> It is now apparent that a significant fraction of otherwise responsive 
> keyservers are not correctly syncing with any of their peers. These are 
> indicated in the second graph of https://spider.pgpkeys.eu/graphs by a 
> 

- -- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEyBZyWQiIsOIlHndA43NIE4F2FjsFAmG4yMQACgkQ43NIE4F2
Fjvg7wwAi7sWBdKrU3+VLHZ6JzaDG6hB3iB9lD8N73tomNyJq07R52KjUsksWKhm
qHUtNmNMYDcoAPDD9CJp/ynlc8OGjjcmfX8dnvMK/8IP9d3SVR3EDJoH04pucPb8
85Mh8RApeBEpXkWbitzSEM86VIC9n2ZC7cneHZHJCkvfU5PoyJ7sTCWG1XTRm0po
o1Ihb02SGobYQGIC/cZeoN70W5sxbCm3tNSaWLA2iGTxg2aJSaHq5J6umrNCKb34
mBXANsLkoJC9iChpZPBFzx+TgK5DHmrPY7zryuaeFYK40EqOtIDVbvZowqliyxS6
xIhWUmOnM0xhX4/Zth7QAT6MZMQVNLG+vkqudL4BktdtDIRK3xJ9TN269OYw/Aq4
UZ6Caf1kg4auWA39+q8wDN+u7pKgpXL4dDDOFfBzsbzNRyhMBXcD1/XtpJmSOS6H
oqSh4O8NAmUx9/7iuYw6A/fWrmc+ynHPDrHzc2CTq/yXK7U8A3aT+MMhWqR4Nl/0
6rNAkWci
=4Jwd
-END PGP SIGNATURE-




Hockeypuck design principles

2021-11-12 Thread Skip Carter


I switched to hockeypuck about 6 months ago and I still have issues with it.
I am greatful I dont have to restart my key service every other day any more
(like sks), but the administration of hockeypuck is a source of other problems
to me.

I have found in the past that when I have the sort of frustrations that I am
having, it is because I was not aware of the design philosophy of the
application.  Is there a document that describes the hockeypuck design
principles ?


-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103





hockeypuck runaway

2021-10-25 Thread Skip Carter
A couple of months ago I had an incident where hockeypuck ran away resulting in
a CPU load over 50.  I firewalled accces to the http port temporarily and the
load subsided.  This has happened a couple times since then again today.

I found this in the logs (which I find frustratingly inadequate):

error[] recon with xxx.xxx.xxx.xxx:36506 failed error=read length
804813932 exceeds maximum limit

The remote address is more than one of my peers.

Has anyone else had CPU runaway issues ?  What is the cause and the cure ?

-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




open files in hockeypuck

2021-10-11 Thread Skip Carter
I noticed that hockeypuck maintains a huge number of open files, 1080 for me at
the moment.

lsof | grep  

Why is this ?  Is it really necessary ?
  

-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




filter errors

2021-10-06 Thread Skip Carter
I am getting the following errors in hockeypuck:

time="2021-10-06T19:41:31-07:00" level=error msg="recon with 128.180.6.195:33641
failed" error="remote rejected configuration\nfilters do not match.\n\tlocal
filters: [ yminsky.dedup yminsky.merge ]\n\tremote filters: [ yminsky.dedup ]

But my config file is set to:

filters=["yminsky.dedup"] 


Any idea what is wrong ?

Also, is there an authoritive document on the config file ?  The site I used
when first setting up hockeypuck, I failed to bookmark (never imagined I would
need it) and cannot find a complete document.



-- 

Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103


Hockeypuck troubles

2021-09-21 Thread Skip Carter


Last week I had an incident where for some reason hockeypuck ran away and caused
an enormous CPU load (over 25).  I firewalled off exernal HTTP access to my
keyserver and the load eventually returned to normal ( 0.10 ).  

There was nothing in the logfile that I could interpret as troublesome.

After restoring normal access to my server I got several silent crashes of
hockeypuck over the next several days.

Just now the runaway happened again, but I manually intervened before my server 
became unresponsive.  At the moment I am running hockeypuck with my firewall
blocking port 11371.


I tried to put an Apache proxy in front (a la sks) to get more info on whats
going on but hockeypuck ignores the config setting

[hockeypuck.conflux.recon]
 httpAddr="127.0.0.1:11371"

and uses all interfaces as if I set it to httpAddr="*:11371"




-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




Re: Hockeypuck logging

2021-09-16 Thread Skip Carter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I am running directly from the command line:

/usr/local/sbin/hockeypuck -config /usr/local/etc/hockeypuck.conf &

The logging entries in the config file are:

logfile="/var/lib/sks/hp.log"
loglevel="INFO"


The [16929] looks to me to be process runtime in seconds.


On Thu, 2021-09-16 at 11:52 +0100, Andrew Gallagher wrote:
> 
> * How are you running hockeypuck?
> * Is 169329 the hockeypuck process ID?
> * Where do you see these logs?
> * Have you tried sending stdout/stderr to `| logger -t hockeypuck` ?
> 
> 

- -- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEyBZyWQiIsOIlHndA43NIE4F2FjsFAmFDc/4ACgkQ43NIE4F2
Fjt2ugwAjmlxQKmv0EDYUX0x+btHFRgIrDeSSzphoEUTejIpcaETCWOVqOh96mSL
C+OO112Q0ES+39+0t0FsfYiSW2Tnugg7z5WaDBicEVR1Q27nzb+zMR9Xq3Wti+mV
KsogZxOcrh0FLH4ph0dRYMyI9qJJ30H492MfCycushjUMUwp2vVtqC+7MkLt8npC
Vw0y1GNwrcvYI1VqVwm1Ibs7tMhDlyYrqsS7GDkDgx6YUBx2gvUsGUCpbGZirTO8
XPps6cmdDE/TTwsux9jiKZXdIUWXJaPWVpb5pLPcU0HIYnrGFRWFvoACTNK93aus
BhJ8Xk2vLvXiO/noPlmHeFUAMWgmXEkpwrPhCpRfTcOFPqzx3BN4IftKRBqle+EY
iJ40ntpPVTub8GTgSPrexHHFCbLFxNXmqLQH2KpECROJeH5bmbqzEeOSf1Xkor9U
rbI5smoeWgksMHlohwz/ELgCPd67sJZ+CRRCADytqP2TP6Gvjp0iDZOiBtGfuu6v
zCzBUD2C
=G4EW
-END PGP SIGNATURE-




Hockeypuck logging

2021-09-15 Thread Skip Carter


I switched to hockeypuck about a month ago and am still getting used to it.


I have a question about logging. 

In a recent post, Gunnar Wolf gave a snippit of his logs which looked like:

Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: goroutine 12101
[running]:
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]:
sync.(*WaitGroup).Wait(0xc000152398)
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]: /usr/lib/go-
1.15/src/sync/waitgroup.go:132 +0xae
Sep 14 16:07:03 hkp.openpgpkeys.net hockeypuck[11829]:
gopkg.in/hockeypuck/conflux.v2/recon.(*Peer).mutate.func1(0x0, 0xc000275500)


these look like the went through syslog.


But MY logs look like:

INFO[169329]
lookupfp=63af7aa15067c05616fddd88a3a2e8f
226f0bc06 length=1219 op=get
INFO[169329]   GET=/pks/lookup?op=ge
t&options=mr&search=0x63AF7AA15067C05616FDDD88A3A2E8F226F0BC06
duration=6.444816ms from=20.186.38.99:1088 host=50.242.82.152:11371 status-
code=200 user-agent=pgp-happy-eyeballs
INFO[169503]   GET=/pks/lookup?op=st
ats duration=819.389µs from=188.141.23.154:54922
host=keyserver.taygeta.com:11371 status-code=200 user-agent=sks_peers/0.2 (SKS
mesh spidering)


The syslog format is much more useful.  Where can I find documentation on
customizing the logging ?  Pushing the logs to syslog would be preferable, but
even just adusting the format would be helpful


Thanks,

-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




hockeypuck logging

2021-09-13 Thread Skip Carter
Does hockeypuck have a logfile rotation mechanism ?  Or do I have to
periodically restart it after manually rotating out the logs ?

Also, it would be nice if the logging flushed the output after each line.  The
output volume is not that high so that flushing the output would not be a burden
on the application.

-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103





Re: number of keys reported by hockeypuck

2021-09-11 Thread Skip Carter
On Fri, 2021-09-10 at 12:52 -0500, Gunnar Wolf wrote:
> 
> > Hi, Skip.
> > 
> > It sounds like your ptree database has not been populated. After you
> > restore the postgres database, you need to run `hockeypuck-pbuild` to
> > generate the ptrees. After that it should return the correct number of
> > keys (and sync correctly!).
> 
> 
Yes,  I want to thank Andrew here for his assistance.  I am now up and running.


> I had the same issue as Skip, but with Andrew's help, I managed to get
> my server (hkp.openpgpkeys.net, aliased as pgp.gwolf.org, as I
> operated that keyserver in the past and there are some servers still
> trying to sync with it) to start syncing last week. However, my
> happiness lasted only for two days, as can be seen in the server's
> statistics:
> 


I wonder, if my problems were experienced by others as well, that 
thedocumentation needs improvement. 



-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103





number of keys reported by hockeypuck

2021-09-07 Thread Skip Carter


My new hockypuck instance reports 0 keys, but when I go to the database directly
and query the number of keys I see 6 million+ keys.  Can anybody suggest what is
wrong ?



-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103





keyserver.taygeta.com on hockeypuck

2021-08-30 Thread Skip Carter


I finally gave up on keeping the plates spinning and stopped using SKS and
switched to hockeypuck at keyserver.taygeta.com.

The switchover was gratifyingly trouble free.

At the moment there are no keys in the database, is there a tool which will take
a daily dump and initialize the database from that ?

I am also getting lots of recon failed messages in the log, probably from dead
peers.  Maybe we should post "I am still alive messages" here so we can
reconfigure to use live peers.
 

-- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103





Re: shutdown of pgpkeys.co.uk and pgpkeys.uk

2021-06-22 Thread Skip Carter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


So ... should the SKS holdouts (myself included) switch to hockeypuck ?
This service is vital, some version of it should live on.

- -- 
Dr Everett (Skip) Carter  0x8176163B
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEyBZyWQiIsOIlHndA43NIE4F2FjsFAmDSMssACgkQ43NIE4F2
FjuQHQv+J/LNa5Jpvcxpaouhbtgvd13vAjKlhm+P20fV885ThYW7PvCyI/A/VHIg
/NalrDqs+J/491flx8pb6gAMHynbYizYb9ZY6DlGEcHTbM3JOmS2saZNil/+GIoM
eNimZ+Sov7MImVAadCdLOeZIQVcbrat+tJ1P5vYHdge/deCxZw0VDP2+LiNwytlI
I/9qLiiR2vulfkO1QBatP8YrothSB7vhMOdWAO52aY/RMFTBvUEmWCVO0zZ10kIx
paCfDJJa2Suq9KihVOHZQV8J36wgOgqf5XvRnQ6FLu6LzDZpo/5sG7LOSK3ZoTtH
YZotijhqzmowcjyrZiSmiQv+a/StKeTom1hKISbxgwgabMMS8t1XHrJOjljzDM0K
NqapKg7aI8JwOSlI5w564wU7DIj6O9yxRm+CaeZoqA/QjpKJIb+gpElPdY4YCW3F
PQr16A08dCXGxzgDaE/6B7dk/4K6YGr+ftD7PMrYlvHPL6yX6MAVVMRK7if+ZSyh
L8U2SrVc
=ilEZ
-END PGP SIGNATURE-




Re: Building SKS on Alpine Linux 3.12 with ocaml 4.08

2020-10-16 Thread Skip Carter
What are the characteristics of a poison key ? What makes it bad ?
I wonder if there is an algorithmic way to deal with them instead of a
blacklist.

On Thu, 2020-10-15 at 21:45 -0700, Todd Fleisher wrote:
> > 
> > On Oct 15, 2020, at 17:58, Ángel  wrote:
> > 
> > First of all, those patches protect against a single poison key,
> > 0xE41ED3A107A7DBC7. By skipping the merge of changes to it, I
> > think.
> 
> I suppose one is better than none. I also block several other
> (popular?) keys that are problematic at the NGINX level after having
> issues with them in the past causing server instability. It’s far
> from a perfect system, but between that and automatic service
> restarts when SKS crashes I rarely have to touch anything anymore.
> *knocks on wood*
> 


-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part


Re: seeking peers for hyperboria.net.pl

2020-10-15 Thread Skip Carter
To avoid stack overflow type: ulimit -s unlimited
before building


Also after building a full build, move the dump out of the way,
otherwise you will have hunreds of open file handles consumed by sks
(you can see this if you type: lsof | grep sks)


On Thu, 2020-10-15 at 14:46 +, Adam Wojcieszonek wrote:
> ok, I have downloaded Your dump. ..with using "http" instead of
> "https" because of errors.
> 
> Now when trying to normal rebuild then:
> 
> DB time:  0.38 min.  Total time: 0.84 min.
> Loading keys...Fatal error: exception Stack overflow
> Command failed unexpectedly. Bailing out
> 
> ...and when fast rebuild :
> 
> === Running fastbuild... ===
> ./sks_build.sh: line 62: 29051 Segmentation fault  /usr/sbin/sks
> $mode -n 10 -cache 100
> Command failed unexpectedly. Bailing out
> 
> What can be a reason ? Is there any debug option to find what's going
> on ???
> 
> 
> 
> 
> 
> 
> 
> 
> ‐‐‐ Original Message ‐‐‐
> czwartek, 15 października 2020 07:03, Todd Fleisher  ops.com> napisał(a):
> 
> > I have placed a current dump @ https://sks.pod02.fleetstreetops.com
> > /dump/2020-10-15/ if anyone needs it. Otherwise, recon will need to
> > catch up 301,510 keys based on the stats pages of
> > http://keyserver.hyperboria.net.pl:11371/pks/lookup?op=stats &
> > other servers that are current in the network. Adam W’s server also
> > lists epidemic.cs.cornell.edu 11370 in it’s membership file, but
> > that hostname does not resolve in DNS. I would recommend he delete
> > his current instance and start over with a current dump if he wants
> > to participate in the pool. I would also urge operators to check
> > the stats page of a new server requesting peering to ensure the
> > delta is low before adding them to the network.
> > 
> > -T
> > 
> > > On Oct 14, 2020, at 20:54, Gabor Kiss ki...@ssg.ki.iif.hu wrote:
> > > On Wed, 14 Oct 2020, Adam Wojcieszonek wrote:
> > > 
> > > > -   loaded dump from
> > > > keys.niif.hu/
> > > > (14.10.2020)
> > > > 
> > > 
> > > Folks,
> > > FYI unfortunately the last successful dump was two months
> > > ago on keys.niif.hu.
> > > Since then some database corruption prevents dumping.
> > > I delete the garbled files from the dump area right now.
> > > I hope at the weekend I'll have some spare time to rebuild
> > > the whole server from scratch.
> > > Gabor
> 
> 
> 
-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


Re: seeking peers for hyperboria.net.pl

2020-10-14 Thread Skip Carter

the last time that I had to do a full key load, I found that 

 http://pgp.key-server.io/dump/current/

was reliable.

Currently I have 6059298 at keyserver.taygeta.com



On Wed, 2020-10-14 at 21:26 +, Adam Wojcieszonek wrote:
> Hi all
> I am looking for peers for a new SKS keyserver installation.
> 
> - SKS version 1.1.6, on hyperboria.net.pl:11371
> - Location - Poland (PL)
> - loaded dump from keys.niif.hu/ (14.10.2020)
> - I see total number of keys loaded 5757797
> 
> - direct contact a...@eksploracja.org.pl
> regards
> Adam Wojcieszonek
> 
> 
> 
> 
-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


Re: DB error in crontab

2020-09-05 Thread Skip Carter
What args are you using ?

For me:   db_archive -d -h PTree
just silently runs with no errors

On Sat, 2020-09-05 at 15:19 -0600, Dan via SKS development and
deployment list wrote:
> I mentioned this one before, but no one seems to have said anything,
> so 
> I'll try one more time.
> 
> When sks was installed, it throw a file into /etc/cron.daily. It is
> a 
> script to check and clean any temporary files from what I can see.
> But 
> it calls db_archive, and db_archive ALWAYS fails with this message:
> 
> db_archive: BDB1566 DB_ENV->log_archive interface requires an 
> environment configured for the logging subsystem
> db_archive: DB_ENV->log_archive: Invalid argument
> 
> It seems to only occur when running db_archive on the
> /var/lib/sks/PTree 
> directory. If I run it on /var/lib/sks/DB, it's fine.
> 
> 
> Any suggestions?
> 
> 
> Thanks!
> 
> 
-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


tatheta back online

2020-06-02 Thread Skip Carter
The taygeta servers have been moved to its new NOC.  It seems to be
running properly.


-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


taygeta moving

2020-05-27 Thread Skip Carter
Tomorrow taygeta.com is moving to a new NOC.  It is expected that
keyserver.taygeta.com will be offline a day or two.  We will be back.


-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part


Re: 6 million

2020-04-14 Thread Skip Carter
Stefan,

This has been such a frustrating experience, I am eager to jump ship. 
I looked at Hagrid some time ago, I rejected it -- I no longer remember
why.  I will take another look.  I never investigated Mailvelope.

On Tue, 2020-04-14 at 17:00 +0200, Stefan Claas wrote:
> 
> Why still focusing on a dead project like SKS and not convining the
> other
> guys from Mailvelope or Hagrid to add peering capabilities?
> 
> What benefits do you have as an SKS operator, to still support such
> old and dangerous GnuPG/SKS client-server model, in 2020?
> 
> 

-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part


6 million

2020-04-07 Thread Skip Carter
Today we crossed the 6 million keys mark with 6000194 keys.

This group's name "sks-devel" is historical no one appears to want to
admit actually developer; we are actually sks-admins that spend a lot
of time keeping the plates spinning.  In the time I have been active I
have solicited help from many of you (and I hope that I in turn
contributed).


I have decided to collect pointers and suggestions on how to keep sks
running in the absence of any development support.  The idea is to
periodically publish it here so it can be used, updated, refined by
everyone. I expect to have version 0 here in the next couple of days. 


-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


Re: Debian sks.service: Main process exited, code=killed, status=11/SEGV

2020-02-26 Thread Skip Carter
I see this during the DB build process,  increase the stack limit:
ulimit -s unlimited

Crashes that wont restart after deployment seem to be DB corruptions. 
Depending upon where the problem is, it might work to just remove the 
PTree and just rebuild that.  Otherwise you will need to do a fresh
build of both KDB and PTree

On Wed, 2020-02-26 at 13:40 +0100, Kristian Fiskerstrand wrote:
> On 26.02.2020 13:10, Azamat S. Kalimoulline wrote:
> > Hi. After recon started with peer sks crashed with message in logs 
> > "sks.service: Main process exited, code=killed, status=11/SEGV". No
> > other 
> > messages in logs. SKS version 1.1.6 Debian Buster. Is anyone get
> > that?
> > 
> > 
> > 
> 
> I'd guess it hitting a stack limit during merge of a large key.
> 
-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


down keyservers

2020-02-25 Thread Skip Carter

keyserver.taygeta.com  was down for most of the day today because of DB
 corruption.  I ultimately had to restore it from a snapshot and it is
restored.

I noticed that about 1/3 of the keyservers were also down.  Has
something systematic happened ?   Any ideas ?


-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part


Re: cant build dabase

2019-12-13 Thread Skip Carter
Thanks Kristian, that did it.

My keyserver keyserver.taygeta.com is back online

On Fri, 2019-12-13 at 10:51 +0100, Kristian Fiskerstrand wrote:
> On 13.12.2019 00:56, Skip Carter wrote:
> > correction, the errors are stackoverflows not segfaults
> > 
> 
> ulimit -s unlimited before building.
> 



-- 
Dr Everett (Skip) Carter   0xF29BF36844FB7922
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


Re: cant build dabase

2019-12-12 Thread Skip Carter
correction, the errors are stackoverflows not segfaults


On Thu, 2019-12-12 at 15:52 -0800, Skip Carter wrote:
> 
> My keyserver crashed last night, complaining about fatal database
> errors. I got a fresh current download from
> https://keyserver.mattrude.com/dump/ and started a full build. I keep
> getting segfaults on the first step
> ( /usr/sbin/sks build /var/lib/sks/dump/*.pgp -n 10 -cache 100 )
> 
> Any advice ?
> 
> BTW: keyserver.taygeta.com is down until I can restore the database.
> 
> -- 
> Dr Everett (Skip) Carter 0xF29BF36844FB7922 s...@taygeta.com
> Taygeta Scientific Inc 607 Charles Ave Seaside CA 93955 831-641-0645
> x103 
-- 
Dr Everett (Skip) Carter   0xF29BF36844FB7922
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


cant build dabase

2019-12-12 Thread Skip Carter

My keyserver crashed last night, complaining about fatal database
errors.  I got a fresh current download from 
https://keyserver.mattrude.com/dump/  and started a full build.  I keep
getting segfaults on the first step
( /usr/sbin/sks build /var/lib/sks/dump/*.pgp -n 10 -cache 100 )


Any advice ?


BTW: keyserver.taygeta.com is down until I can restore the database.


-- 
Dr Everett (Skip) Carter   0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part


Re: Sks-devel Digest, Vol 188, Issue 1

2019-12-09 Thread Skip Carter

Peter,

I found that guide to be reasonably clear and accurate.  Two things:

1 -- use systemd. That will give you a straightforward way do an
unattended restart to a crashed service (this happens to me once or
twice a day)

2 -- do a "normal build", but afterwards move the dump directory out of
the way. The documentation says after a normal build it is no longer
used, but that is not true. If you don't do this lsof will real
hundreds of open file handles (and who knows what else) wasting system
resources. 

 
On Mon, 2019-12-09 at 21:21 +, peter wrote:
> On 9 Dec 2019, at 17:02, sks-devel-requ...@nongnu.org wrote
> -641-0645 x103
> 
> Hi all,
> 
> I've literally just finished rebuilding my web server machine so I
> should
> be in a position to setup an SKS server. I'm running  Debian 10
> (Buster)
> so would this be the best install guide to follow?
> 
> https://keyserver.mattrude.com/guides/building-server/
> 
> Many thanks!
> 

-- 
Dr Everett (Skip) Carter   0xF29BF36844FB7922
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


Peer crisis

2019-12-09 Thread Skip Carter
This weekend  I lost half my peers as they have shutdown.

In the past I have expressed my frustration with the fragility of the
sks code; it seems from the feedback a lot of you that are still
running it resort to various tricks to keep the plates spinning (I do
as well).  Now it looks like time to do something with the peer
infrastructure itself.

So this is both a peer request and a peer invitation for others to peer
with me.  Lets try to raise the peer interconnectedness.  

keyserver.taygeta.com 11370  # s...@taygeta.com 0xF29BF36844FB7922

-- 
Dr Everett (Skip) Carter   0xF29BF36844FB7922
s...@taygeta.com
Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


Re: New peers request

2019-11-21 Thread Skip Carter
Christoph,

You can peer with:  keyserver.taygeta.com 11370 #  s...@taygeta.com

I have put you in my access list.

But I must warn you that "Segmentation fault  /usr/sbin/sks db"
is a daily occurrence and I have to manually restart it, so at any
specific moment it might be down.  Keep trying, you will eventually
connect.


On Thu, 2019-11-21 at 09:47 +0100, Christoph Martin wrote:
> Hi,
> 
> I got the keyserver pgp.uni-mainz.de up again. But now all my peers
> seam
> to be down.
> 
> So, who is willing to peer with pgp.uni-mainz.de ?
> 
> pgp.uni-mainz.de 11370  # sys...@uni-mainz.de
> 
> Christoph
> 
-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part


Re: [Sks-devel] The end of an Era

2019-08-12 Thread Skip Carter
On Mon, 2019-08-12 at 11:13 -0500, Daniel Roesler wrote:
> 
> There is no prominent alternative for _decentralized_ public key
> sharing. Keybase is centralized, as is keys.openpgp.org. I would
> argue that there must be a good decentralized alternative before
> shutting down this pool.\\

I agree that it is important that there be a decentralized key sharing
service.  Given the fragility of sks and the apparent lack of
developers willing to take up the task of fixing its problems, I have
been thinking about re-implement it.  This is a spare-time effort that
has so far been confined to reverse engineering experiments and tests. 
Has anybody else started down this path ?  Maybe we could collaborate
and a new sks could rise from the ashes of the old. 



-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] Extreme memory usage

2019-07-17 Thread Skip Carter
If you do an 'lsof' you will also see all the dump files (223 when I
built it) are open, even when having done a normal build.  The only way
to prevent this is to move the dump directory after the build finishes.
 This could also be contributing to the resource consumption.

On Wed, 2019-07-17 at 19:47 +0200, Kiss Gabor (Bitman) wrote:
> Dear folks,
> 
> I experienced in the past months that my SKS instance dies almost
> every day.
> Now I think I found the reason.
> 
> Program crashes when e-mail address to be search is broken
> into mostly 1-3 letter words.
> These very short words - that are legitim search patters - make
> sks db process eat the whole 6 GiB RAM of the VM and the OOM killer
> reapes it.
> Is this normal? What are your experiences?
> 
> Cheers
> 
> Gabor
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] The pool is shrinking

2019-06-23 Thread Skip Carter
On Fri, 2019-06-21 at 12:22 -0700, Todd Fleisher wrote:

> FWIW - in my experience, once you get things setup & dialed-in there
> is no need for daily poking at it. My load balanced pools have been
> running for months with only the occasional intervention required by
> me.

What do you do for log management ? 


-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] open files

2019-06-21 Thread Skip Carter
PS:  the server appears to be vastly faster and more reliable since I
did this

On Thu, 2019-06-20 at 09:34 -0700, Skip Carter wrote:
> so I did the experiment (for a normal build):
> 
> -- shutdown sks
> -- move /var/lib/sks/dump elsewhere
> -- restart sks
> 
> There seem to be no errors and there are a sane number of open files
> (15).
> 
> So it appears that if the dump files are present, that they will be
> opened regardless of the build mode.  I don't know the intentions of
> the designers; but from my point of view using unnecessary resources
> like that is a bug.
>  
> 
> On Tue, 2019-06-18 at 09:24 -0700, Skip Carter wrote:
> > I was doing some maintenance on my sks server and I was surprised
> > to
> > see that the sks db process has all of the dump files from the
> > initial
> > build open:
> > 
> 
> ...
> 
> > I thought that after a normal build that the dump files are no
> > longer
> > used.
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] The pool is shrinking

2019-06-21 Thread Skip Carter
As a newcomer to the pool, I have to agree.
There are several impediments to becoming a keyserver that just
shouldn't be and the need for daily poking at it is just one of those
things.  There were several times where I was just ready to give up on
it.
 
On Fri, 2019-06-21 at 07:43 -0500, Daniel Roesler wrote:
> I'd love to keep my server in the pool consistently, but until
> Issue #61 is resolved[1], my server will spike to 100% CPU for
> several minutes and become unresponsive as it tries to deal with
> the huge troll keys. Running a server in the pool is no longer
> a hobby project, and you have to constantly be restarting or
> reconfiguring your server to keep it running.
> 
> Overall, I think the main reason why the pool has shrunk so much
> is because of this issue.
> 


-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] open files

2019-06-20 Thread Skip Carter
so I did the experiment (for a normal build):

-- shutdown sks
-- move /var/lib/sks/dump elsewhere
-- restart sks

There seem to be no errors and there are a sane number of open files
(15).

So it appears that if the dump files are present, that they will be
opened regardless of the build mode.  I don't know the intentions of
the designers; but from my point of view using unnecessary resources
like that is a bug.
 

On Tue, 2019-06-18 at 09:24 -0700, Skip Carter wrote:
> I was doing some maintenance on my sks server and I was surprised to
> see that the sks db process has all of the dump files from the
> initial
> build open:
> 
...

> I thought that after a normal build that the dump files are no longer
> used.


-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] open files

2019-06-19 Thread Skip Carter
Todd,

Yes I did a normal build: /usr/sbin/sks build /var/lib/sks/dump/*.pgp
According to the docs I no longer need the dump but this software has
proven itself to be so fragile that I need to schedule downtime to dothe 
experiment. 

On Wed, 2019-06-19 at 10:15 -0700, Todd Fleisher wrote:
> Are you sure you didn’t do a fast build? I originally did a normal
> build on my servers, but due to the initial issues causing me to have
> to rebuild several times I switched to fast build to save time. I am 

I suffered through several builds myself.  I considered the fast build
but was concerned about the performance loss that the docs imply.  But
from what you say it is not really a problem.
 
> still running that way currently and can confirm my sks db process
> has the dump files opened. The documentation claims a normal build
> will run faster (although it contains an odd caveat to that statement
> - “depending from the source/age of the keydump”), but I haven’t
> noticed any serious performance problems since getting everything
> tuned and dialed in after the first few months. Maybe I will try a
> re-build one of these days and see if there’s any noticeable
> difference.
> 


-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] open files

2019-06-18 Thread Skip Carter
I was doing some maintenance on my sks server and I was surprised to
see that the sks db process has all of the dump files from the initial
build open:

lsof | grep sks 

ks   23189  root   17r  REG  254,35
4965717   10747909 /data/sks/dump/sks-dump-.pgp
sks   23189  root   18r  REG  254,3
53884256   10747910 /data/sks/dump/sks-dump-0001.pgp
sks   23189  root   19r  REG  254,3
75707940   10747911 /data/sks/dump/sks-dump-0002.pgp
sks   23189  root   20r  REG  254,3
85833346   10747912 /data/sks/dump/sks-dump-0003.pgp
sks   23189  root   21r  REG  254,3
57206889   10747913 /data/sks/dump/sks-dump-0004.pgp
sks   23189  root   22r  REG  254,3
54697273   10747914 /data/sks/dump/sks-dump-0005.pgp
and so on...

I thought that after a normal build that the dump files are no longer used.





-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] production tweaks

2019-06-17 Thread Skip Carter
Thanks.  Is there a document describing what can go into sksconf ?

On Mon, 2019-06-17 at 10:38 -0500, Travis Megee wrote:
> On 6/16/2019 8:30 PM, Skip Carter wrote:
> > Third, my Server Contact field is blank.  Where and how do I set it
> > ?
> > 
> 
> In your sksconf set `server_contact:` to your PGP ID.
> 

-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] production tweaks

2019-06-16 Thread Skip Carter
With a lot of help from people on this list, keyserver.taygeta.com has
been running (mostly) trouble-free for a week now.  I now want to make
some adjustment to make it a production system.

First, I don't see a mechanism to rotate logs.  I wrote a script to
rotate the logs and then restart the two components; it works fine but
I'd rather use a built-in mechanism if there is one.

Second, the log location -- can that be specified in the sksconf file ?

Third, my Server Contact field is blank.  Where and how do I set it ?

Fourth, how often is the server statistics information refreshed ?  How
do I control it ?  It appears to only happen at startup.


-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] I am syncing!

2019-06-12 Thread Skip Carter
After several false starts and many other issues, keyserver.taygeta.com
is finally up and syncing with 5511543 keys:

2019-06-12 10:22:51 Requesting 100 missing keys from , starting with 00048065DBB6235A5CEF51C8A7A402DD
2019-06-12 10:22:54 100 keys received
2019-06-12 10:23:11 Added 142 hash-updates. Caught up to
1560360175.871769

Thank you to all that helped, I couldn't have done it without you.

Now that I am up, I am happy to accept peering requests for
keyserver.taygeta.com 11370

-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] proxy config

2019-06-06 Thread Skip Carter
I am finally getting my keyserver running properly.  When building the
reverse proxy using Apache on Debian, I ran into this error:

[proxy:warn] [pid 5563:tid 140523378071296] [client
xxx.xxx.xxx.xxx:2368] AH01144: No protocol handler was valid for the
URL /pks/lookup. If you are using a DSO version of mod_proxy, make sure
the proxy submodules are included in the configuration using
LoadModule.

The solution is to load the module proxy_http as well as proxy

This might be worth noting in the documentation

-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] understanding error message

2019-06-03 Thread Skip Carter
my recon logs have messages like these:


 error in callback.: Failure("configuration of
remote host () rejected: filters do
not match.\n\tlocal filters: [ yminsky.dedup ]\n\tremote filters: [
yminsky.dedup yminsky.merge ]")

 callback timed out.

What do they mean and what do I do about them ?  What are these filters
? Is there something else I need to configure ?

-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] SKS directory

2019-05-31 Thread Skip Carter
I am confused about the "SKS directory" location.

Is it where the config files are ( /etc/sks  in my Debian instance) or
is it where the DB files are ( /var/lib/sks in my Debian instance) ? 
Are they both supposed to be the same place ?

Which is the CWD for when sks runs ?

-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] startup troubles

2019-05-30 Thread Skip Carter
I am having trouble with the startup file /etc/init.d/sks,
the sks db part fails with:

Fatal error: exception Keydb.Unsafe.No_db
Fatal error: exception Unix.Unix_error(63, "connect", "")

but when I execute it directly in works:

 sks -debug -stdoutlog db
2019-05-30 09:17:27 sks_db, SKS version 1.1.5
2019-05-30 09:17:27 Using BerkelyDB version 5.3.28
2019-05-30 09:17:27 Copyright Yaron Minsky 2002, 2003, 2004
2019-05-30 09:17:27 Licensed under GPL. See LICENSE file for details
2019-05-30 09:17:27 http port: 11371
2019-05-30 09:17:27 address for ...(peer data)
2019-05-30 09:17:29 address for ...(peer data)
2019-05-30 09:17:29 address for ...(peer data)
2019-05-30 09:17:29 address for ...(peer data)
2019-05-30 09:17:29 Opening KeyDB database
2019-05-30 09:17:29 Database opened
2019-05-30 09:17:29 Applied filters: yminsky.dedup


 
My environ:

Debian

apt-get install libdb-dev   installed bdb-5.3
apt-get install ocaml-nox   installed OCaml version 4.01.0
apt-get install sks installed SKS version 1.1.5

-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] missing DB file

2019-05-29 Thread Skip Carter
I recently installed sks.  Running 'sks build' I got:

Fatal error: exception Keydb.Unsafe.No_db

in /var/lib/sks I found PTree but not KDB

I manually created that folder and then 'sks build' ran without errors
and created the db files inside KDB

Somehow the install process failed to create the folder KDB.
 
My environ:

Debian

apt-get install libdb-dev   installed bdb-5.3
apt-get install ocaml-nox   installed OCaml version 4.01.0
apt-get install sks installed SKS version 1.1.5



-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] why is default startup no?

2019-05-29 Thread Skip Carter
I think I know the answer to my own question:  until you initiate the
database is not going to run anyway.


On Wed, 2019-05-29 at 08:33 -0700, Skip Carter wrote:
> Hello,
> 
> I am new to sks.  I think I installed it  (1.1.6) with no problems on
> Debian.  I am sure to be asking questions.  I will start with a
> simple
> one:  why is the default setting for /etc/default/sks no ?
> 
> 
> 
> 
-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103




signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


[Sks-devel] why is default startup no?

2019-05-29 Thread Skip Carter
Hello,

I am new to sks.  I think I installed it  (1.1.6) with no problems on
Debian.  I am sure to be asking questions.  I will start with a simple
one:  why is the default setting for /etc/default/sks no ?




-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



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


[Sks-devel] peering request for keyserver.taygeta.com

2019-05-28 Thread Skip Carter
Subject: seeking peers for keyserver.taygeta.com
Hi,

I am looking for peers for a new SKS keyserver installation.

I am running SKS version 1.1.6, on keyserver.taygeta.com.
We are a cyber-security company with a long history on the Internet.
The server is physically located in Monterey Calif (US).

I have loaded a keydump from https://keyserver.mattrude.com/dump/curren
t/, dated 2019-05-28.
I see 5505149 keys loaded.

For operational issues, please contact me directly.

keyserver.taygeta.com 11370 # Everett Carter 
DF16781A604A4F605F98B301F29BF36844FB7922

Thank you,
-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



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


[Sks-devel] Trouble building from source

2019-05-28 Thread Skip Carter

I am trying to build SKS from source, but I get an error:

SKS 1.1.6 from bitbucket.org
apt-get install libdb-devinstalled bdb-5.3
OCaml version 4.01.0

server:/usr/local/src/sks-1.1.6$ make
ocamlopt -I lib -I bdb -ccopt -L/usr/lib  -ccopt -Lbdb -dtypes  -inline 
40 unix.cmxa str.cmxa bdb.cmxa nums.cmxa bigarray.cmxa cryptokit.cmxa
-c pSet.ml
File "pSet.ml", line 1:
Error: Could not find the .cmi file for interface pSet.mli.
Makefile:388: recipe for target 'pSet.cmx' failed
make: *** [pSet.cmx] Error 2

-- 
Dr Everett (Skip) Carter
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel