Re: [Sks-devel] proxy config

[Todd Fleisher]

Hi Skip,
According to the stats page on your server 
(http://keyserver.taygeta.com:11371/pks/lookup?op=stats 
), you only have 
2250084 keys loaded. Mine shows 5512048, which means you are missing 3261964 
keys which is well above what you should be trying to pull down via recon. 
Please re-build your DB and check the total number of keys is much closer to 
the current number of keys that exist in the pool per the SKS status page 
(https://sks-keyservers.net/status/ ).

-T

> On Jun 6, 2019, at 10:04 AM, Skip Carter  wrote:
> 
> Signed PGP part
> 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: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Proxy config issue and question

[Phil Pennock]

On 2013-08-20 at 13:30 -0400, James Cloos wrote:
> > "PP" == Phil Pennock  writes:
> PP> Use:
> PP>   https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering#!nginx
> 
> Too bad that isn't what shows up when searching for example configs.

Write a blog post and link to it, help improve the reputation of the
wiki site so that search engines rank it more highly.  :)

There's not much else we can do, besides put correct information out
there.

> I'm sure I'm not the only one who used goog as a reminder and ended up
> with a config like the one I quoted.

People are wrong on the Internet.  It happens.

> It would be better were the proxy able to listen(2) on 0.0.0.0 a/o ::.

Depending upon your setup, you very possibly can.  On Unix systems with
a BSD sockets API (which is "all of the Unices that are left", I think),
a specific binding takes precedence over an INADDR_ANY binding.

Debugging that and helping people through just leads to more confusion,
as we then have to talk about layers of binding and more specific
binding, and debug server software which sees INADDR_ANY and iterates
the interfaces, binding to each IP in turn to prevent this masking
behaviour (as some security-conscious software does).

So instead, the example configurations keep things as simple as
possible, both for "simple to set up" and "simple to debug".

Once you have a working configuration, which you can revert back to if
things go wrong, you can of course experiment with "better"
configurations for your setup.

-Phil

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

Re: [Sks-devel] Proxy config issue and question

[James Cloos]

> "PP" == Phil Pennock  writes:

PP> On 2013-08-19 at 17:59 -0400, James Cloos wrote:
>> If one configures a proxy (such as nginx) with a config like:

PP> Don't, because that's not what the Peering wiki page says to do and
PP> advertises the wrong port.

PP> Use:
PP>   https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering#!nginx

Too bad that isn't what shows up when searching for example configs.

I'm sure I'm not the only one who used goog as a reminder and ended up
with a config like the one I quoted.

>> with listen directives for each specific address.

PP> Yes, that's why the Peering wiki page explicitly does this: SKS needs to
PP> listen on localhost, nginx (or other reverse proxy) on the public
PP> addresses, using the same port number for each.  This is handled in the
PP> examples for all three web-servers for which example configurations are
PP> provided.

It would be better were the proxy able to listen(2) on 0.0.0.0 a/o ::.

Fewer files to change in the face of renumbering is always a good thing.

PP> The spiders tend to force port 11371; if you know of a server where
PP> /pks/lookup?op=stats works on 11371 but shows a different port, then
PP> please re-educate the server operator.

That was the point of my post. :)

PP> The peering code actually just uses the SKS reconciliation port "+1",
PP> not the value configured in sksconf, so peering will get the keys
PP> through as long as you peer on 11370.

Didn't happen for my internal peer; it was unable to get anything from
my public peer, given the public peer's config.  As I noted with the
Requesting and resulting error messages from recon log.

>> Continuing on the nginx front, what is the optimal config for ports 80
>> and 443, presuming that one wants to be able to serve other content on
>> those ports in addition to /pks/?  I've tried several, and non worked
>> reliably.

PP> location /pks {
PP> proxy_pass http://127.0.0.1:11371;

I thought that I had tried that, and it didn't work.

I'll try again.

Thanks.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6


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

Re: [Sks-devel] Proxy config issue and question

[Phil Pennock]

On 2013-08-19 at 17:59 -0400, James Cloos wrote:
> If one configures a proxy (such as nginx) with a config like:

Don't, because that's not what the Peering wiki page says to do and
advertises the wrong port.

Use:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering#!nginx

> Instead, you need to specify 'hkp_port: 11371' in sksconf and configure
> the proxy like:

> with listen directives for each specific address.

Yes, that's why the Peering wiki page explicitly does this: SKS needs to
listen on localhost, nginx (or other reverse proxy) on the public
addresses, using the same port number for each.  This is handled in the
examples for all three web-servers for which example configurations are
provided.

> Perhaps this is why some severs seem to lack some keys?

I doubt it.

The spiders tend to force port 11371; if you know of a server where
/pks/lookup?op=stats works on 11371 but shows a different port, then
please re-educate the server operator.

The peering code actually just uses the SKS reconciliation port "+1",
not the value configured in sksconf, so peering will get the keys
through as long as you peer on 11370.

> Continuing on the nginx front, what is the optimal config for ports 80
> and 443, presuming that one wants to be able to serve other content on
> those ports in addition to /pks/?  I've tried several, and non worked
> reliably.

Make sure that /pks/ is passed through to SKS, no matter what hostname
is used, so that you can be in various pools.  For 443, additionally
look into what certificates you want to use, and read this page:

  http://www.sks-keyservers.net/overview-of-pools.php

for instructions on getting a cert for the hkps.pool.sks-keyservers.net
hostname.

You'll need to either have `default_server` on the listen lines for one
of the servers, or make sure you know which is first in the config
parsing for a given IP/port, so that on the default server for port 80
and 443, you can pass through /pks.

For myself, the various relevant server blocks just have:

location /pks {
proxy_pass http://127.0.0.1:11371;
proxy_set_header   Host $host:$server_port;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
proxy_pass_header  Server;
add_header Via "1.1 sks.spodhuis.org:80 (nginx)";
proxy_ignore_client_abort on;
}

The proxy_set_header rules are not needed, they just give SKS's own
debug logs more meaningful data.

-Phil

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