Pete Stephenson | 22 Sep 01:47 2014

IPv6 crawler & DNS zone offline?

Hi all,

There appears to be something wrong with the IPv6 pool crawler:
https://sks-keyservers.net/status/ reports that no servers support IPv6
(although many do). The DNS zone ipv6.pool.sks-keyservers.net is
returning NXDOMAIN.

Kristian, can you kick the crawler to get it working again?

Cheers!
-Pete

Hi all,

There appears to be something wrong with the IPv6 pool crawler:
https://sks-keyservers.net/status/ reports that no servers support IPv6
(although many do). The DNS zone ipv6.pool.sks-keyservers.net is
returning NXDOMAIN.

Kristian, can you kick the crawler to get it working again?

Cheers!
-Pete

Phil Pennock | 18 Sep 06:31 2014

sks-peer.spodhuis.org behind

Folks,

My keyserver is 8k keys behind; sks-recon was not running.

I've tried using runit but some failure modes meant that this caused
more problems that it solved (concurrent processes, etc).  I should find
time to spend looking into it more, but don't currently have that,
sorry.

I've restarted recon.  Kristian and I have been talking about this, and
I (still) owe him one recompiled SKS binary using gcc instead of clang
for the extensions -- _might_ be a FreeBSD / clang issue.

Apologies for the slight hit on load -- 8k keys isn't far enough behind
for reconciliation to be horrible, but it's enough for me to feel
guilty.

Hrmph, no core-dump for this one.  Ah well.

-Phil
Folks,

My keyserver is 8k keys behind; sks-recon was not running.

I've tried using runit but some failure modes meant that this caused
more problems that it solved (concurrent processes, etc).  I should find
time to spend looking into it more, but don't currently have that,
sorry.
(Continue reading)

Brian Minton | 16 Sep 16:04 2014

seeking peers for keyserver.brian.minton.name


Hi,

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

I am running SKS version 1.1.5, on keyserver.brian.minton.name.
This is a private machine.
The server is physically located in Wrightsville, Pennsylvania, USA.
The machine has IPv4 connectivity.

I have loaded a keydump dated 2014-09-10.
I see 3714964 keys loaded.

For operational issues, please contact me directly.

keyserver.brian.minton.name 11370 # Brian Minton <brian@...>
0xDBF6A5BA777DF487

Thank you,
Brian Minton
Pete Stephenson | 11 Sep 16:10 2014

ams.sks.heypete.com migrating to new facility, changing IP addresses

Hi all,

My VPS hosting company recently brought a new facility in Amsterdam
online. The new facility has an upgraded backend which allows live
snapshotting, native IPv6, and a bunch of other useful features.

Later today I will be migrating ams.sks.heypete.com to this new
facility. This will entail a period of downtime. When it comes back
online, the system will have new IPv4 and IPv6 addresses.

After things are setup, tested, and working, I will update the DNS
records pointing to the server. If I understand things correctly, SKS
should automatically reload the membership file and re-query DNS names
of peers every 6 hours or so, so peering should be reestablished
automatically.

Cheers!
-Pete

Hi all,

My VPS hosting company recently brought a new facility in Amsterdam
online. The new facility has an upgraded backend which allows live
snapshotting, native IPv6, and a bunch of other useful features.

Later today I will be migrating ams.sks.heypete.com to this new
facility. This will entail a period of downtime. When it comes back
online, the system will have new IPv4 and IPv6 addresses.
(Continue reading)

Jeremy T. Bouse | 6 Sep 20:32 2014
Picon

Generating a pubring.pgp from sks dump

	As the title indicates I'm trying to see if it isn't possible to simply
take a dump from my SKS server and produce a public key ring containing
all keys currently in the server.

	Part of the idea is to try and run keyanalyze against it and several
other smaller public keyrings. The other is just to understand better if
there is anything special about the keydumps from sks itself.

	As the title indicates I'm trying to see if it isn't possible to simply
take a dump from my SKS server and produce a public key ring containing
all keys currently in the server.

	Part of the idea is to try and run keyanalyze against it and several
other smaller public keyrings. The other is just to understand better if
there is anything special about the keydumps from sks itself.

Eddie Cornejo | 6 Sep 05:32 2014
Picon

keyserver.eddiecornejo.com down for maintenance


FYI keyserver.eddiecornejo.com is currently down due to lack of ram to
run hockeypuck.

The server is being rebuilt on another machine with double the ram.

Additionally it will be a standard SKS server rather than Hockeypuck.
I don't expect anything will change from a peering perspective.
Christoph Egger | 4 Sep 08:16 2014

Broken keyservers (413 Request Entity Too Large)

Hi!

Seems uploading my gpg key (d49ae731) to pool.sks-keyservers.net fails
for several of the hosts in rotation:

gpg: sending key D49AE731 to hkp server 213.206.252.51
gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large
gpg: keyserver internal error
gpg: keyserver send failed: keyserver error

gpg: sending key D49AE731 to hkp server 193.17.17.6
gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large
gpg: keyserver internal error
gpg: keyserver send failed: keyserver error

gpg: sending key D49AE731 to hkp server 162.17.206.197
gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large
gpg: keyserver internal error
gpg: keyserver send failed: keyserver error

gpg: sending key D49AE731 to hkp server [2001:4d88:1ffc:477::7]
gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large
gpg: keyserver internal error
gpg: keyserver send failed: keyserver error

gpg: sending key D49AE731 to hkp server [2001:1af8:3100:b010:a000::1]
gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large
gpg: keyserver internal error
gpg: keyserver send failed: keyserver error

(Continue reading)

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)


Gmane