Re: New peers request
I wrote a systemd service for the sks-recon service (installed from Debian packages) that uses "Restart=always", and it seems to keep SKS running well enough for now: # sks-recon.service [Unit] Description=SKS Keyserver Recon Wants=network.target network-online.target After=network.target network-online.target [Service] Type=simple Restart=always ExecStartPre=-/bin/mkdir -p /var/run/sks ExecStartPre=-/bin/chown debian-sks /var/run/sks ExecStart=/usr/sbin/sks -stdoutlog recon User=debian-sks Group=debian-sks TimeoutSec=300 [Install] WantedBy=multi-user.target On 11/21/19 11:08 AM, PGP wrote: > Hi Skip, > > Why not use https://mmonit.com/monit/ ? > > Greetings, > Melvin > > On 21/11/2019 17:04, Skip Carter wrote: >> 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 signature.asc Description: OpenPGP digital signature
Re: [Sks-devel] Withdrawal of Service - keys.flanga.io
Standard "I am not a lawyer" disclaimer applies, but it is my impression (both from speaking to people who know more than I do about this, and from reading article 17 of the GDPR) that the "right to be forgotten" isn't necessarily absolute. Meaning that if one were to receive such a request, and it is *not possible* to remove the data, this doesn't automatically mean that the only recourse is to shut down the service. Specifically, this language is the part that catches my attention: "the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers..." Perhaps someone who has access to a lawyer could ask for clarification on this? Speculation about what implications GDPR may or may not have for the SKS network isn't especially productive, in my opinion. (I say this as someone who might be shielded from liability by an employer's legal counsel, however.) Regarding the resource usage and/or instability of the SKS keyserver itself, there are some of us who don't need to care about this, thankfully ;-) I maintain a keyserver in a VM at work, where its CPU/disk/bandwidth usage are a proverbial drop in the bucket. As long as it keeps running with minimal oversight on my part, I'm happy to provide this service. The same applies to the mirrors that we operate. Obviously this is a luxury and is not the case for many (most?) admins, and I would never blame anyone for ceasing to volunteer their resources/time for a project like this, but it is not necessarily a problem for *all* of us that these issues have become (more) apparent in the last year or so. Just my two cents. ~Keith On 11/15/18 6:50 PM, Moritz Wirth wrote: > I asked to be allowed to share some more details, however the request > was to remove/prevent indexing of 2 keys stored on our keyservers - > including copies of ID's to verify the request as required by the > european data protection law. Since it is not possible to prevent the > indexing of data, I think the only possible way to handle this request > is to shut them down. I don't see a reason to fight this - it is the > right of someone to get his/her data removed so we are required to do > this regardless of how crappy that law might be. If someone decides to > ignore it, it's up on them. > > Am 16.11.18 um 00:31 schrieb Mike: > >> Fabian, im sure you can tell that nothings going to change :( >> >> But maybe these shutdowns in protest will provoke change, before its too >> late? >> >> On Thu, 15 Nov 2018 23:23:43 + >> "Fabian A. Santiago" wrote: >> >>> Wow! I’d love to see that as well. >>> >>> I just saw Kristian’s post with his email exchange. It’s a shame the >>> situation is going down like this. I do hope a proper solution can be found >>> so I and hopefully others can return to contributing to the network, should >>> the mode of operation dictate and stay this way. >>> >>> -- >>> >>> Thanks, >>> >>> Fabian S. >>> >>> OpenPGP: >>> >>> 0x643082042DC83E6D94B86C405E3DAA18A1C22D8F >>> >>> On Thu, Nov 15, 2018 at 5:58 PM, Georg Faerber wrote: >>> Hi, On 18-11-15 23:56:07, Moritz Wirth wrote: > keys.flanga.io will cease operation - we received a request to remove > some keys and since we are unable to do this, we will shutdown all > keyservers and erase all relevant databases immediately. Would it be possible to share this request, omitting sensitive details? Cheers, Georg > > ___ > 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] PTree may be corrupted kills recon service
After the last time I trashed the DB/PTree and rebuilt from a downloaded
dump, I copied the sample "DB_CONFIG" file from the Debian package into
the DB dir, and haven't had any problems since then.
Total disk space used by SKS is ~21GB.
(Sample config is /usr/share/doc/sks/sampleConfig/DB_CONFIG)
~Keith
On 07/17/2018 04:52 AM, André Keller wrote:
> Hi all,
>
>
> On 12.07.2018 17:55, André Keller wrote:
>> On 11.07.2018 20:40, John Zaitseff wrote:
for a few days I have an issue with the recon process on
keys.communityrack.org:
2018-07-02 15:17:53 Raising Sys.Break -- PTree may be corrupted:
Failure("remove_from_node: attempt to delete non-existant element
from prefix tree")
2018-07-02 15:17:53 DB closed
>>> I saw the same thing happen. I stopped SKS, dumped my existing keys
>>> to the dump directory ("/usr/sbin/sks dump 32768 /var/lib/sks/dump"),
>>> tweaked the /etc/sks/sksconf file to include "pagesize: 32" and
>>> "ptree_pagesize: 16", removed the DB and PTree directories, then
>>> rebuilt both:
>>>
>>> /usr/sbin/sks build /var/lib/sks/dump/*.pgp -n 1 -cache 100
>>> /usr/sbin/sks cleandb
>>> /usr/sbin/sks pbuild -cache 50 -ptree_cache 100
>>>
>>> SKS restarted fine; so far so good! I'll be keeping an eye on it
>>> over the next few days, so I'll report back as needed.
>> thank you for your reply, I have done that as-well and it is running
>> stable now since a few hours. Let's see for how long :-)
>>
> Unfortunately the issues is still not resolved. Is nobody else
> experiencing this?
>
>
> ___
> 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
Re: [Sks-devel] disk full, keys.niif.hu crashed
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] disk full, keys.niif.hu crashed
This has happened to my keyserver twice in the last two days. I assumed it was some sort of malicious behavior, because it happened quite suddenly both times and had the effect of a DoS. ;-) For example, I have over 1700 binary log files like "log.002014", each 10MB, created in the last 24 hours. (It would have kept going, but the filesystem filled up.) The timestamps show that often 30 or 40 of them are created in the same minute. ~Keith On 06/14/2018 11:54 PM, Kiss Gabor (Bitman) wrote: > Yesterday at 18:15 (CEST) keys.niif.hu started to produce tons > of logs in /var/lib/sks/DB. In less than 2 hours the 40 GB filesystem > got fulfilled. > Deleting files and restarting processes did not help: > > recon.log: > 2018-06-15 05:50:09 Opening log > 2018-06-15 05:50:09 sks_recon, SKS version 1.1.6 > 2018-06-15 05:50:09 Using BerkelyDB version 5.3.28 > 2018-06-15 05:50:09 Copyright Yaron Minsky 2002-2013 > 2018-06-15 05:50:09 Licensed under GPL. See LICENSE file for details > 2018-06-15 05:50:09 recon port: 11370 > 2018-06-15 05:50:09 Opening PTree database > 2018-06-15 05:50:09 Setting up PTree data structure > 2018-06-15 05:50:09 PTree setup complete > 2018-06-15 05:50:09 Initiating catchup > 2018-06-15 05:50:10 DB closed > > db.log: > 2018-06-15 05:50:09 Opening log > 2018-06-15 05:50:09 sks_db, SKS version 1.1.6 > 2018-06-15 05:50:09 Using BerkelyDB version 5.3.28 > 2018-06-15 05:50:09 Copyright Yaron Minsky 2002, 2003, 2004 > 2018-06-15 05:50:09 Licensed under GPL. See LICENSE file for details > 2018-06-15 05:50:09 http port: 11371 > 2018-06-15 05:50:09 Membership: (zimmermann.mayfirst.org 11370)[], ... > (keys.jpbe.de 11370)[] > 2018-06-15 05:50:09 address for zimmermann.mayfirst.org:11370 changed from [] > to > [, ] > ... > 2018-06-15 05:50:10 address for keys.jpbe.de:11370 changed from [] to > [, ] > 2018-06-15 05:50:10 Opening KeyDB database > 2018-06-15 05:50:10 Shutting down database > > Unfortunately I cannot work on restoration till Sunday evening. > > Gabor > > ___ > 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
[Sks-devel] seeking peers for pgp.lehigh.edu
Hi, I am looking for peers for a new SKS keyserver installation. I am running SKS version 1.1.6 on pgp.lehigh.edu (hosted at Lehigh University). The server is physically located in Pennsylvania (US). I have loaded a keydump from pgp.key-server.io, dated 2017-05-02. I see 4661852 keys loaded. For operational issues, please contact me directly. pgp.lehigh.edu 11370 # Keith Erekson <ke...@lehigh.edu> 0xC9A3C33D Thank you, ~Keith ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
