[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Proxy config issue and question
From: |
James Cloos |
Subject: |
Re: [Sks-devel] Proxy config issue and question |
Date: |
Tue, 20 Aug 2013 13:30:29 -0400 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
>>>>> "PP" == Phil Pennock <address@hidden> 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 <address@hidden> OpenPGP: 1024D/ED7DAEA6