Pete Stephenson | 1 Sep 17:41 2014

Recon stalls for one hour

Hi all,

I was perusing my recon.log and db.log files today and noticed odd gaps
in gossip activity that last for an hour and result in error messages.
Logs for the last few days indicate this happens 10-15 times per day.

Normally, my server (ams.sks.heypete.com, running SKS 1.1.5) gossips
regularly with its peers. There are 27 entries in my server's membership
file. It's not uncommon for gossip traffic to occur a few times per
minute, though 1-3 minutes between gossiping is normal. Hour-long breaks
are definitely odd.

It appears that SKS stalls waiting for something to happen and it only
times out after an hour elapses. During this time, no other activity is
logged to the recon.log, though regular HKP queries are answered
normally. After the hour period is up a "Reconciliation failed due to
timeout." message is written to the log and the server syncs updates
over gossip as usual.

The standard recon.log and db.log files don't seem to shed any
information on what might be causing this. I'd be happy to enable
debug-level logging if that'd help.

Any ideas as to what might be causing this and what might be done to
resolve the issue?

I've included a log snippet below with the IP addresses of other servers
obfuscated.

Cheers!
(Continue reading)

echelon | 1 Sep 14:37 2014

Re: Searching servers to sync new server, changed ports, apache2 proxy


On 01.09.2014 10:30, Pete Stephenson wrote:

> Hi,
> 
> Your server is listening on ports 11371 in addition to 80. Is this
> what you intended?

Yes, that was intendend, as some kind of special user service (no need
to enter ports for users).

> Also, the suggested membership line is incorrect: you specified
> port 80 as the recon port. According to 
> http://keys.i2p-projekt.de/pks/lookup?op=stats your server is
> listening to port 11370 for recon traffic.

I did tweak a few ports and settings, and now the server acts on
standard ports (for clients like enigmail to work flawless), with a
apache2 proxy in front of hkp port 11371, and being public reachable
on port 80 and 11371 on IPv4 and IPv6 on keys.i2p-projekt.de.

If anyone still sees some issues, please get to me!

> Cheers! -Pete

Thank you so far

echelon

(Continue reading)

echelon | 1 Sep 15:51 2014

Re: Searching servers to sync new server


Hi!

Just some update. Sorry for the inconvenience.

On 01.09.2014 01:40, echelon wrote:

> keys.i2p-projekt.de 80 # echelon <echelon@...> 0x4A9B1723

Please use:

keys.i2p-projekt.de 11370 # echelon <echelon@...> 0x4A9B1723

The port 80 entry in old mail was absolutely wrong. Now I did tweek my
server and it runs on default ports.

> Thank you, echelon

echelon
echelon | 1 Sep 11:39 2014

Re: Searching servers to sync new server


On 01.09.2014 10:30, Pete Stephenson wrote:

> Hi,
> 
> Your server is listening on ports 11371 in addition to 80. Is this
> what you intended?
> 
> Also, the suggested membership line is incorrect: you specified
> port 80 as the recon port. According to 
> http://keys.i2p-projekt.de/pks/lookup?op=stats your server is
> listening to port 11370 for recon traffic.
> 
> Assuming you intend to listen to port 11370 for recon traffic, the 
> correct line would be: keys.i2p-projekt.de 11370 # echelon
> <echelon@...> 0x4A9B1723
> 
> That said, I've added your server as a peer (assuming you intend
> to listen for recon on 11370). You can add mine to your membership
> file as:
> 
> ams.sks.heypete.com 11370 # Pete Stephenson <pete@...>
> 0x85EB9F44

Hi!

The public reachable port is 80 via apache2 proxy on a vhost. The
internal sks port is still 11370/11371, as port 80/443 is in use by
Apache2 with different vhosts. So I cannot set SKS to listen on port 80.
Ports 11370/11371 are closed in firewall and will only be opened for
(Continue reading)

echelon | 31 Aug 12:04 2014

Searching servers to sync new server


Hi,

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

I am running SKS version 1.1.5 on a debian wheezy system (backports of
SKS), on keys.i2p-projekt.de port 80 with the apache2 proxy setup.
This is a private server dedicated mainly to the I2P network
(https://geti2p.net) and is reachable via I2P
(http://keys.echelon.i2p) and via clearnet IPv4/IPv6
http://keys.i2p-projekt.de. HTTPS will be added later (if needed).
The server is physically located in Germany (EU).
The machine has IPv6 connectivity.

I have loaded a keydump from
"keyserver.secretresearchfacility.com/dump/", dated 2014-08-30.
I see 3.704.974 keys loaded.

For operational issues, please contact me directly.

keys.i2p-projekt.de 80 # echelon <echelon@...> 0x4A9B1723

Thank you,
echelon
Pete Stephenson | 1 Sep 01:14 2014

ams.sks.heypete.com now available over IPv6

Hi all,

My hosting company has been somewhat slow about turning up IPv6 at the
facility where my VPS is hosted, so I decided to setup a Hurricane
Electric IPv4-to-IPv6 tunnel for my server.

I'll add native IPv6 transport when my hosting company offers it and
will update my DNS records accordingly.

There were some tunnel-related firewall issues that caused intermittent
problems for a day or two[1], but everything seems to be working well now.

Kristian's pool crawler has noticed that the server is listening on IPv6
(which is good check that things are working) and I'm seeing IPv6 traffic.

If anyone runs into issues with the server, IPv6-related or not, please
let me know.

Cheers!
-Pete

[1] In particular, unless one allows the firewall to accept "protocol
41"[2] (IPv6-in-IPv4) packets from the remote tunnel server, things may
work for a while but after a short time IPv6 connections will start
timing out since the firewall is blocking new inbound connections from
the tunnel server. This is annoying to diagnose.

It can be solved using this UFW rule:
"sudo ufw allow proto ipv6 from $TUNNEL_SERVER_IPv4_ADDRESS"

(Continue reading)

Jonathan Zhang | 30 Aug 11:41 2014
Picon

IPv6 address change for key.bbs4.us


Hello,

The AAAA record for key.bbs4.us was changed to 2604:180:1:44d::dead:beef.

The change should propagate immediately.

The old address, 2604:180:1::9d6:b497, will remain working after the change.

The A record for key.bbs4.us is unchanged.

Best regards,
Jonathan
Phil Pennock | 29 Aug 20:22 2014

sks-peer.spodhuis.org maintainer PGP key update

Folks,

I have a new(ish) PGP key, which is in the strong set and which I am now
finally set up to conveniently use with email, so I can switch away from
using my old 1024/DSA key 0x403043153903637F.

I am now using 0x4D1E900E14C1CC04 4096/RSA.  This key is signed by the
old one, with a signing policy statement which references text saying
"it's one of my keys", so rather than mess around to try to send this
one message with the old key, I think this should be sufficient for
folks to verify authenticity.

pub   4096R/0x4D1E900E14C1CC04 2013-10-22
      Key fingerprint = ACBB 4324 393A DE35 15DA  2DDA 4D1E 900E 14C1 CC04
[...]
sig 3   P    0x403043153903637F 2013-10-22 never       Phil Pennock <censored-against-spambots>
   Signature policy: https://www.security.spodhuis.org/PGP/policy/self

If you are peering with me, please update your membership line with:

sks-peer.spodhuis.org 11370  # Phil Pennock <keyserver@...> 0x4D1E900E14C1CC04

Thank you,
-Phil
Folks,

I have a new(ish) PGP key, which is in the strong set and which I am now
finally set up to conveniently use with email, so I can switch away from
(Continue reading)

David Benfell | 27 Aug 11:29 2014

sks.disunitedstates.com returns to IPv6

Hello all,

I'm finally getting the final kinks out of the new installation. I'd
nearly forgotten about getting sks back onto IPv6.

Sometime later this morning, after my daily dump,
sks.disunitedstates.com should start working on IPv6 at
2001:470:67:119::9. The DNS has pointed that way for a few days now
(once I finally gave up on trying to follow the documentation for
configuring the IPv6 tunnel), but I hadn't modified the sks
configuration to use the IPv6 for recon as well as the IPv4 address.

hkp should have worked automatically as I modified the Apache
configuration for IPv6 earlier.

It won't be ideal. Comcast Business doesn't do IPv6 yet, so I had to
get a tunnel from he.net in Fremont. (Hence the joy of trying to make
sense of FreeBSD documentation on setting these tunnels up. Clue: The
documentation is *WRONG* and is, as near as I can tell, completely
broken.)

But it is there.

--

-- 
David Benfell <benfell@...>
See https://parts-unknown.org/node/2 if you don't understand the
attachment.
Hello all,
(Continue reading)

Chris Boot | 22 Aug 16:25 2014
Picon

seeking peers for sks.bootc.eu

Hi,

I am looking for peers for a new SKS key server installation.

I am running SKS version 1.1.5-1 (from Debian), on sks.bootc.eu. This is
a private machine located in Devon UK, is connected via a fast bonded
VDSL setup, and has IPv6 connectivity.

I have loaded a key dump from keyserver.secretresearchfacility.com,
dated 2014-08-21. I see 3700039 keys loaded.

For operational issues, please contact me directly.

sks.bootc.eu 11370 # Chris Boot <sks@...> 0xD9CEEEEE

Stats are available from: http://sks.bootc.eu:11371/pks/lookup?op=stats

Thanks in advance,
Chris

--

-- 
Chris Boot
bootc@...

Hi,

I am looking for peers for a new SKS key server installation.

(Continue reading)

Horváth Dávid | 22 Aug 10:18 2014
Picon

Fwd: Re: PTree corrupted


Sorry,

* (stop sks, delete PTree folder, start sks)

:)

David

2014-08-22 10:10 időpontban Horváth Dávid ezt írta:
> Hi,
> 
> 
> PTree often crash in my server.
> Log:
> 
> 2014-08-18 14:27:38 Requesting 2 missing keys from <ADDR_INET
> [80.241.60.3]:11371>, starting with 1AFFB478E0DC9C6F6A3BEB58E5E6EED4
> 2014-08-18 14:27:38 2 keys received
> 2014-08-18 14:27:38 setting synctime to 1408372058.589961
> 2014-08-18 14:27:38 Added 3 hash-updates. Caught up to 
> 1408372058.589961
> 2014-08-18 14:27:38 Enabling gossip
> 2014-08-18 14:27:39 Raising Sys.Break -- PTree may be corrupted:
> Failure("remove_from_node: attempt to delete non-existant element from
> prefix tree")
> 2014-08-18 14:27:39 <further catchup> callback interrupted by break.
> 2014-08-18 14:27:39 DB closed
> 
> I use a workaround (delete stop sks, delet PTree forled, start sks)
(Continue reading)


Gmane