Re: [Sks-devel] sks.disunitedstates.com down and out
Hey David, it makes me sad to see you leaving the pool, and I really hope that you'll try to run SKS again in a few years, when the relevant problems might be solved and bugs have been fixed. See you; don't leave us forever! :) Best regards, Tobias Frei On Sat, Apr 11, 2015, 01:31 David Benfell benf...@parts-unknown.org wrote: Quoting Michael Sinatra michael+li...@burnttofu.net: On 04/10/15 15:44, David Benfell wrote: I'm giving up. When there is an sks that uses a reliable database system, I'll be happy to rejoin. But Berkeley DB is not sane in my environment, has never proven scalable in any environment I've had in the past, and I'm not messing with it any more. I had terrible stability problems when trying to run an SKS server on a VM platform (VMware ESXi 5.x). Once I moved it to standalone hardware, it has been rock solid. Just a datum--not trying to talk you out of it... This is on the biggest, most powerful server I've ever owned, a relatively new system--not a VPS. If I have to give sks its own system, then I can't run it anyway. I'm happy to be generous with what I have, but when it comes to buying a system just for sks, that's more than I can do. Thanks! -- David Benfell benf...@parts-unknown.org ___ 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] sks.disunitedstates.com down and out
Hello David, as desired I removed your server from our membership file. I am running SKS 1.1.5+ on CentOS6 (LXC container) and CentOS7 (KVM) for a long time w/o problems. In the past I had similar problems, but switching clocksource to tsc solved database problems. My current installations are working with tsc (LXC) and kvm-clock (kvm) You should give it a new try, may be it will work then. An other SKS server admin found a problem if sks recon is running via haproxy tcp: SKS consumes lot of memory and does no longer gossip keys then while tcp service is still available. This can be exploited only, if there is a membership entry to such a server. If there is a documentation how recon works, I would consider to build a new solution on Jetty with Hypersonic SQL or any other JDBC database. BouncyCastle is able to analyze PGP keys. Java is considered to be more spread than ocaml. Christian Am 11.04.2015 um 00:44 schrieb David Benfell: I have previously commented on the difficulty of keeping the sks database healthy. I just discovered my sks instance had been down for several days. I tried to recover and it crashed again. I'm giving up. When there is an sks that uses a reliable database system, I'll be happy to rejoin. But Berkeley DB is not sane in my environment, has never proven scalable in any environment I've had in the past, and I'm not messing with it any more. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks.disunitedstates.com down and out
Quoting Christian Felsing c...@ip6.li: Hello David, as desired I removed your server from our membership file. I am running SKS 1.1.5+ on CentOS6 (LXC container) and CentOS7 (KVM) for a long time w/o problems. In the past I had similar problems, but switching clocksource to tsc solved database problems. My current installations are working with tsc (LXC) and kvm-clock (kvm) You should give it a new try, may be it will work then. This is on FreeBSD. The relevant sysctl variable for tsc is kern.timecounter.invariant_tsc . It's on by default. I'm not running on a virtual machine, so if I understand correctly, kvm is irrelevant. An other SKS server admin found a problem if sks recon is running via haproxy tcp: SKS consumes lot of memory and does no longer gossip keys then while tcp service is still available. This can be exploited only, if there is a membership entry to such a server. I'm not using haproxy. If there is a documentation how recon works, I would consider to build a new solution on Jetty with Hypersonic SQL or any other JDBC database. BouncyCastle is able to analyze PGP keys. Java is considered to be more spread than ocaml. I tend to shy away from java. It, too, seems to be problematic, for a number of reasons including memory leaks and CPU hogging. And I've seen these problems with just about every java application I've tried to leave running. -- David Benfell benf...@parts-unknown.org pgprKAgokZD6T.pgp Description: PGP Digital Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks.disunitedstates.com down and out
Quoting Hendrik Grewe hendrik.gr...@tu-dortmund.de: Also what I have read about your tries to recover the database. I think I have read in some FAQ that one should _not_ try to recover a (somehow) corrupted sks database. Instead one should start (from skratch) with some actual keydump. Among the steps I took was indeed a recovery from an actual keydump. I have just seen way too many problems with Berkeley DB in way too many situations. It seems to be fine for small applications: postfix uses it for really small files, for example. But anything big and it becomes unmanageable. Again and again and again. I'm convinced it's just a really bad idea. -- David Benfell benf...@parts-unknown.org pgpFnsv3sczwI.pgp Description: PGP Digital Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks.disunitedstates.com down and out
Hi David, On 11-04-15 12:15, David Benfell wrote: Quoting Hendrik Grewe hendrik.gr...@tu-dortmund.de: Also what I have read about your tries to recover the database. I think I have read in some FAQ that one should _not_ try to recover a (somehow) corrupted sks database. Instead one should start (from skratch) with some actual keydump. Which by itself is a very strange recommendation, however true. Among the steps I took was indeed a recovery from an actual keydump. I have just seen way too many problems with Berkeley DB in way too many situations. After I had a few times problems, I changed strategy: every 2 or 3 months I generate a new dump, throw away both databases (do s/w upgrades if available) and do a fresh 'fastbuild'. In case of BDB problems in between I do the same, although I might re-use my previous dump. SKS is definitely taking more administrator time than any other service I've run. Best regards, Arnold ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks.disunitedstates.com down and out
Hi! As requested I have removed you from my membership file. For informational purpouse: I am running my sks on the tinyest VPS (parallels) from 11 it is a special offer for students, is rate unlimited and costs 1€/year so very very cheap (and powerless 2 gigs ram, 40 gigs discspace 1x2Ghz core). The VPS currently serves a postfix/dovecot/amavis/spamassasin/roundcube mailserver, LAMP stack + sks. I did not have any issues with BerkleyDB / sks so far. I think Berkley DB is wellsuited for use of a keyserver since it is optimised for key/value pairs (to quote Wikipedia): BDB stores arbitrary key/data pairs as byte arrays, and supports multiple data items for a single key. Berkeley DB is not a relational database. I don't think there will (ever?) be a swith from BDB to any relational database, as those features are not needed. Also what I have read about your tries to recover the database. I think I have read in some FAQ that one should _not_ try to recover a (somehow) corrupted sks database. Instead one should start (from skratch) with some actual keydump. But nevertheless thank you for your services within the SKS pool. Hendrik Am 11.04.2015 um 00:44 schrieb David Benfell: Hello all, There are a few folks in my membership file for whom I do not have email addresses. This is mostly for them. I have previously commented on the difficulty of keeping the sks database healthy. I just discovered my sks instance had been down for several days. I tried to recover and it crashed again. I'm giving up. When there is an sks that uses a reliable database system, I'll be happy to rejoin. But Berkeley DB is not sane in my environment, has never proven scalable in any environment I've had in the past, and I'm not messing with it any more. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel -- _ Hendrik Grewehendrik.gr...@tu-dortmund.de Public PGP-Key http://mypgpkey.b4ckbone.org PGP-Fingerprint B8D6 0D8C F5A9 410A 8077 66AE CF08 65D2 0A09 6F7B PGP-encrypted mails are welcome! _ signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
