RE: PSK Support

[Karstens, Nate]

Maxim,

The biggest downside that I can see to the dummy certificate approach is 
documentation. Using a dummy certificate wasn't immediately obvious to me, 
though perhaps my familiarity with OpenSSL's "nocert" option may have affected 
that. Which do you think would be easier for the user to find in the 
documentation: 1) a description of the dummy certificate approach under the 
"ssl_certificate" directive, 2) a separate directive ("ssl_nocert"), or 3) an 
explicit option to the "ssl_certificate" directive (e.g., " Syntax: 
ssl_certificate file | off;")?

I'm OK with changing it to read from a password file (formatted in a manner 
similar to stunnel) that is searched as needed (an "ssl_psk_file" directive). 
Would it be OK to support multiple files and stipulate that files are searched 
in the order that they are included in nginx.conf?

Can we support both ASCII and binary PSKs? RFC 4279 section 5.4 seems to 
require both types, and I need binary keys for my application :). Maybe a 
parameter to the "ssl_psk_file" directive could indicate how the PSKs are 
stored in the file?

Thanks,

Nate

-Original Message-
From: nginx-devel [mailto:nginx-devel-boun...@nginx.org] On Behalf Of Maxim 
Dounin
Sent: Monday, June 05, 2017 1:40 PM
To: nginx-devel@nginx.org
Subject: Re: PSK Support

Hello!

On Mon, Jun 05, 2017 at 02:08:15PM +, Karstens, Nate wrote:

> Maxim,
>
> Thanks for the reply. I understand your concerns about PSK. We
> discussed it quite a bit, but ultimately decided that a PKI was not
> practical for our environment. We have to rely on the end user to
> configure security and any solution using PKI would be so difficult to
> work with that they just wouldn't bother with security at all.

Ok, understood.  I think that PSK can be a reasonable alternative to using 
plain http in many cases.

> I considered some alternatives on the "ssl_nocert" option. My
> preference would have been to analyze the supported cipher suites
> (from "ssl_ciphers") and determine if any include a PSK, but it does
> not look like OpenSSL exposes APIs to accomplish this.

By default, nginx uses "HIGH:!aNULL:!MD5" as ciphers list, and this includes 
various PSK ciphers as well, so this approach doesn't look working even if 
there were appropriate APIs.

> Using a dummy certificate seemed more complicated than the other two
> suggestions you had (using "ssl_certificate" with a value of "off" or
> disabling the tests if there are PSK secrets), so I'd prefer one of
> those two. What is your preference?

Using a dummy certificate has an obvious benefit of not requiring any changes 
to the code, and might actually be a good starting option.

Disabling the tests with PSK secrets might not work as expected when they are 
defined at the http{} level.  Using "ssl_certificate off" is obviously most 
explicit of all options, but I would rather consider a dummy certificate 
instead for now, as long as there are no other downsides.

> One advantage of the PSK path concept is that it provides a lot of
> flexibility. It allows, for example, multiple applications to each
> independently manage their own PSKs without the need to coordinate
> changes to a single file (note that in this scenario each application
> would want to use $ssl_psk_identity to check the key).

On the one hand, it is a plus.  On the other - it is a nightmare when something 
goes wrong.  I would rather avoid such approach.

> stunnel uses a single file and seems to assume that keys will be ASCII
> strings. Its format, for example, would not allow NUL to appear in the
> string, as that would terminate the key early and, at best, lead to a
> reduced key size.

Yes, and stunnel author considers this to be a feature, see 
https://www.stunnel.org/pipermail/stunnel-users/2015-October/005275.html.
If you are targeting end-users, it might be actually easier to use sufficiently 
long printable keys then arbitrary binary strings.

> I might be mistaken, but wouldn't changing a certificate also require
> reloading the configuration? Do you have some ideas on how this could
> be done without requiring a reload?

Yes, changing a certificate requires a reload.  But the "path"
concept is generally used in SSL where appropriate filesystem lookups are done 
on the fly, in contrast to loading a file into memory and then working with the 
data from memory.  Consider "openssl verify -CApath" vs. "openssl verify 
-CAfile".

Additionally, PSK keys look much more dynamic than certificates, as adding a 
user requires configuration changes.  With PKI, you don't need any certificate 
changes on the server to add a user.
With PSK, you have to add a key to introduce a new user.

Overall, PSK seems to be very close to basic authentication, and it might worth 
looking how it is implemented in the auth_basic module (in short: the password 
file is searched on each request).

--
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list

Re: Unable to start php-fpm

[Anoop Alias]

grep apache /etc/passwd

should return something.

FYI this has nothing to do with nginx

On Wed, Jun 7, 2017 at 7:11 AM, marcospaulo877 
wrote:

> /etc/init.d/php-fpm restart
> Stopping php-fpm:  [FAILED]
> Starting php-fpm: [07-Jun-2017 01:35:37] ERROR: [pool www] cannot get uid
> for user 'apache'
> [07-Jun-2017 01:35:37] ERROR: FPM initialization failed
>[FAILED]
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?2,225788,274718#msg-274718
>
> ___
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



-- 
*Anoop P Alias*
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Unable to start php-fpm

[marcospaulo877]

/etc/init.d/php-fpm restart
Stopping php-fpm:  [FAILED]
Starting php-fpm: [07-Jun-2017 01:35:37] ERROR: [pool www] cannot get uid
for user 'apache'
[07-Jun-2017 01:35:37] ERROR: FPM initialization failed
   [FAILED]

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,225788,274718#msg-274718

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Convert Alias from apache (totally different root)

[ianwinter]

I've read the docs and understand how root and alias work within a location,
but, neither can be used to convert what I've got in apache that I can see.

Take the example `Alias /media /path/to/assets` in apache, the location and
path are completely different (media doesn't form any part either in
addition or removed).

The issue in converting to a location with alias or root is monitoring is
still there, or, excluded - I need a way to change the location to
completely use a different document root otherwise I'm not sure how I can?

location /media { root /path/to/assets; }

Any advice appreciated!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,274717,274717#msg-274717

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Active/Active NginX configuration

[Francis Daly]

On Tue, May 30, 2017 at 11:20:11AM -0400, kingstonsew wrote:

Hi there,

> I current have configured 2 NginX running on Red Had Enterprise Linux 7.3.
> Both NginX will load balance a set of 4 application servers. The current
> configuration for both of the NginX is active / passive by using keepalived
> with a single virtual IP.
> 
> I would like to know how to make the 2 NginX into an active/active
> configuration without using round-robin DNS approach.

Your active/passive setup is based on something external to nginx deciding
whether the traffic goes to the nginx1 server or the nginx2 server.

Your active/active setup will probably also be based on something external
to nginx deciding whether the traffic goes to the nginx1 server or the
nginx2 server. Probably you will want a load balancer.

Many exist, including nginx: you can have a third server that
reverse-proxies to either of your current servers.

f
-- 
Francis Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Stale While Revalidate Expires

[Rafael Cirolini]

We've just updated to 1.12 to use the stale-while-revalidate option.

The application is who sends the cache-control header, like this:
cache-control:max-age=180, stale-while-revalidate=60, stale-if-error=864000

If I understood how SWR works, the user shouldn't receive stale content after 
180+60 seconds.

But we are seing stale content after this time.
X-Cache-Status: STALE

Our DevOps team did a debug:
2017/05/22 15:14:31 [debug] 21376#21376: *44 http file cache expired: 4 
1495476646 1495476871
2017/05/22 15:14:31 [debug] 21376#21376: *44 http upstream cache: 4
2017/05/22 15:14:31 [debug] 21376#21376: *44 http file cache send: 
/var/cache/nginx/d/d2/fb19e1c85db7bda5c92ce21530bf5d2d
2017/05/22 15:14:31 [debug] 21376#21376: *44 http ims:1491861925 lm:1491861925
2017/05/22 15:14:31 [debug] 21376#21376: *44 http script var: "STALE"

The correct answer should be EXPIRED after the max-age+SWR time.

It looks reasonble to you?

Thanks.

Rafael Cirolini
Sup Programmatic & Digital Services
Terra Global


Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, 
podem conter informação privilegiada ou confidencial e são de uso exclusivo da 
pessoa ou entidade de destino. Se não for destinatário desta mensagem, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por engano, pedimos que nos comunique imediatamente por esta mesma via e, em 
seguida, apague-a.

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted él destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le pedimos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su exclusión.

The information contained in this transmissión is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: how to install nginx_substitutions_filter in existing Nginx

[Francis Daly]

On Tue, Jun 06, 2017 at 12:27:04AM -0400, David Woodstuck wrote:

Hi there,

> I am a new Nginx user. I just install Nginx 1.12. I like to
> use nginx_substitutions_filter. I cannot figure out how to install
> nginx_substitutions_filter in previously existing Nginx.

You (probably) don't.

https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/

describes how to build from source in general;

https://www.nginx.com/resources/wiki/modules/substitutions/

describes how to include the modules you mention, in specific.

> Should I unstall Nginx first?

You can run "nginx -V" to see the "configure" arguments that were used
to create your current version. Then add the extra bits that you want.

Depending on precisely how you installed your current nginx, you probably
*do* want to uninstall it before installing the new one.


If your current nginx supports dynamic modules (1.12 does), and if
this extra module you want supports being built as a dynamic module,
then you may be able to build-and-add the module.

I suspect that in your case, you will probably find more clear
documentation on how to build-and-maintain a new nginx than how to
build-and-maintain the extra module.

I also suspect that, based on parallel mail threads, you probably do
not need the extra module.

It is still useful to know how to add a module that you want, so it is
certainly worth trying it on a test system, at least.

Good luck with it,

f
-- 
Francis Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [PATCH] Use .exe for binaries for all win32 compilers

[Maxim Dounin]

Hello!

On Tue, Jun 06, 2017 at 05:54:01PM +0300, Orgad Shaneh wrote:

> > http://mailman.nginx.org/pipermail/nginx-devel/2016-December/009234.html
> 
> Thanks. It is needed with MSYS2 / gcc. Proposing a new patch:
> 
> ---
>  auto/cc/bcc  | 1 -
>  auto/cc/conf | 7 ++-
>  auto/cc/msvc | 1 -
>  auto/cc/owc  | 1 -
>  4 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/auto/cc/bcc b/auto/cc/bcc
> index ec82e60f..e990a9f7 100644
> --- a/auto/cc/bcc
> +++ b/auto/cc/bcc
> @@ -62,7 +62,6 @@ ngx_include_opt="-I"
>  ngx_objout="-o"
>  ngx_binout="-e"
>  ngx_objext="obj"
> -ngx_binext=".exe"
> 
>  ngx_long_start='@&&|
>   '
> diff --git a/auto/cc/conf b/auto/cc/conf
> index afbca62b..7e1186b5 100644
> --- a/auto/cc/conf
> +++ b/auto/cc/conf
> @@ -14,9 +14,14 @@ ngx_pic_opt="-fPIC"
>  ngx_objout="-o "
>  ngx_binout="-o "
>  ngx_objext="o"
> -ngx_binext=
>  ngx_modext=".so"
> 
> +if [ "$NGX_PLATFORM" = win32 ]; then
> +ngx_binext=".exe"
> +else
> +ngx_binext=
> +fi
> +
>  ngx_long_start=
>  ngx_long_end=
> 

Looking more at this I tend to think that a better place would be 
to redefine it in auto/os/win32, like this:

diff --git a/auto/os/win32 b/auto/os/win32
--- a/auto/os/win32
+++ b/auto/os/win32
@@ -13,6 +13,7 @@ NGX_ICONS="$NGX_WIN32_ICONS"
 SELECT_SRCS=$WIN32_SELECT_SRCS
 
 ngx_pic_opt=
+ngx_binext=".exe"
 
 case "$NGX_CC_NAME" in
 

Full patch modified accordingly provided below.  Please test if it 
works for you.

# HG changeset patch
# User Orgad Shaneh 
# Date 1496767054 -10800
#  Tue Jun 06 19:37:34 2017 +0300
# Node ID 6c9b1238cf5c99ffc5a8a449ce738606e312350e
# Parent  23bea7aaebe287722ec5b5252e145da55d7906a9
Configure: use .exe for binaries for all win32 compilers.

diff --git a/auto/cc/bcc b/auto/cc/bcc
--- a/auto/cc/bcc
+++ b/auto/cc/bcc
@@ -62,7 +62,6 @@ ngx_include_opt="-I"
 ngx_objout="-o"
 ngx_binout="-e"
 ngx_objext="obj"
-ngx_binext=".exe"
 
 ngx_long_start='@&&|
'
diff --git a/auto/cc/msvc b/auto/cc/msvc
--- a/auto/cc/msvc
+++ b/auto/cc/msvc
@@ -142,7 +142,6 @@ ngx_pic_opt=
 ngx_objout="-Fo"
 ngx_binout="-Fe"
 ngx_objext="obj"
-ngx_binext=".exe"
 
 ngx_long_start='@<<
'
diff --git a/auto/cc/owc b/auto/cc/owc
--- a/auto/cc/owc
+++ b/auto/cc/owc
@@ -84,7 +84,6 @@ ngx_include_opt="-i="
 ngx_objout="-fo"
 ngx_binout="-fe="
 ngx_objext="obj"
-ngx_binext=".exe"
 
 ngx_regex_dirsep='\\'
 ngx_dirsep="\\"
diff --git a/auto/os/win32 b/auto/os/win32
--- a/auto/os/win32
+++ b/auto/os/win32
@@ -13,6 +13,7 @@ NGX_ICONS="$NGX_WIN32_ICONS"
 SELECT_SRCS=$WIN32_SELECT_SRCS
 
 ngx_pic_opt=
+ngx_binext=".exe"
 
 case "$NGX_CC_NAME" in
 

-- 
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] Fix compilation on MinGW64

[Maxim Dounin]

Hello!

On Tue, Jun 06, 2017 at 05:48:39PM +0300, Orgad Shaneh wrote:

> On Tue, Jun 6, 2017 at 5:11 PM, Maxim Dounin  wrote:
> > Hello!
> >
> > On Tue, Jun 06, 2017 at 01:57:39PM +0300, Orgad Shaneh wrote:
> >
> >> I already proposed a similar patch (without MSYS) on November, but it
> >> was unnoticed since then.
> >> ---
> >>  auto/configure | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/auto/configure b/auto/configure
> >> index ceff15e4..107c2b5f 100755
> >> --- a/auto/configure
> >> +++ b/auto/configure
> >> @@ -36,7 +36,7 @@ if test -z "$NGX_PLATFORM"; then
> >>  NGX_PLATFORM="$NGX_SYSTEM:$NGX_RELEASE:$NGX_MACHINE";
> >>
> >>  case "$NGX_SYSTEM" in
> >> -MINGW32_*)
> >> +MINGW32_*|MINGW64_*|MSYS_*)
> >>  NGX_PLATFORM=win32
> >>  ;;
> >>  esac
> >> --
> >> 2.13.0.windows.1.7.g80a6209eb5
> >
> > A review of your previous patch can be found here:
> >
> > http://mailman.nginx.org/pipermail/nginx-devel/2016-December/009233.html
> >
> > It still applies.
> >
> > --
> > Maxim Dounin
> > http://nginx.org/
> > ___
> > nginx-devel mailing list
> > nginx-devel@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> 
> Thanks. I wasn't aware that I should stay subscribed to receive replies.

You can unsubscribe and/or switch to write-only mode, but unless 
you've used Mail-Followup-To in your messages there will be no 
direct replies.

> Posted a fixed patch (using Git, I hope you don't mind).

Mercurial is really preferred, though I was able to import this 
particular patch.  Queued with a couple of style fixes you've 
missed, thanks.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Proxy parameter to nginx service

[Francis Daly]

On Mon, Jun 05, 2017 at 04:16:55PM +0200, juan_barbancho_...@cajarural.com 
wrote:

Hi there,

> I need to use nginx to made a proxy_pass to some url, but  I need to pass 
> some proxy param in order to do not get the connection " upstream timed 
> out (110: Connection timed out)  "

Stock nginx does not talk to a proxy server.

So you cannot do what you want in nginx without someone writing code.

f
-- 
Francis Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: source rpms missing?

[David Kewley]

Thanks Konstantin!

I see this now:
http://nginx.org/packages/centos/6/SRPMS/nginx-1.12.0-1.el6.ngx.src.rpm.
Didn't see it yesterday, but maybe I was overlooking it. I did verify that
the binary rpms for CentOS and RHEL are identical, so agreed that the
CentOS srpm will meet my needs.

David

On Tue, Jun 6, 2017 at 5:36 AM, Konstantin Pavlov  wrote:

> Hello,
>
> On 06/06/2017 04:00, David Kewley wrote:
> > In http://nginx.org/packages/rhel/6/SRPMS/ I don't see
> nginx-1.12.0-1.el6.ngx.src.rpm as expected. Similar for RHEL 5 and 7, and
> for CentOS. This appears just to affect this release not (most of) the
> previous releases.
>
> RHEL5 and CentOS5 are discontinued by the vendor, so don't expect SRPMS
> (or binary RPMS for that matter) to appear for those distributions.
>
> 6 and 7 is a different matter, though, thanks - will fix.
>
> > Could the srpms be posted? If I should take a different route to raise
> this issue, please point me in the right direction.
>
> You can use SRPMS from CentOS 6 until we fix the repositories:
> http://nginx.org/packages/centos/6/SRPMS/ - those are exactly the same
> source packages we use to provide RHEL binaries.
>
> Thank you,
>
> --
> Join us at nginx.conf, Sept. 6-8, Portland, OR
> Konstantin Pavlov
> www.nginx.com
>
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [PATCH] Use .exe for binaries for all win32 compilers

[Orgad Shaneh]

> http://mailman.nginx.org/pipermail/nginx-devel/2016-December/009234.html

Thanks. It is needed with MSYS2 / gcc. Proposing a new patch:

---
 auto/cc/bcc  | 1 -
 auto/cc/conf | 7 ++-
 auto/cc/msvc | 1 -
 auto/cc/owc  | 1 -
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/auto/cc/bcc b/auto/cc/bcc
index ec82e60f..e990a9f7 100644
--- a/auto/cc/bcc
+++ b/auto/cc/bcc
@@ -62,7 +62,6 @@ ngx_include_opt="-I"
 ngx_objout="-o"
 ngx_binout="-e"
 ngx_objext="obj"
-ngx_binext=".exe"

 ngx_long_start='@&&|
  '
diff --git a/auto/cc/conf b/auto/cc/conf
index afbca62b..7e1186b5 100644
--- a/auto/cc/conf
+++ b/auto/cc/conf
@@ -14,9 +14,14 @@ ngx_pic_opt="-fPIC"
 ngx_objout="-o "
 ngx_binout="-o "
 ngx_objext="o"
-ngx_binext=
 ngx_modext=".so"

+if [ "$NGX_PLATFORM" = win32 ]; then
+ngx_binext=".exe"
+else
+ngx_binext=
+fi
+
 ngx_long_start=
 ngx_long_end=

diff --git a/auto/cc/msvc b/auto/cc/msvc
index 4eef1010..82572529 100644
--- a/auto/cc/msvc
+++ b/auto/cc/msvc
@@ -142,7 +142,6 @@ ngx_pic_opt=
 ngx_objout="-Fo"
 ngx_binout="-Fe"
 ngx_objext="obj"
-ngx_binext=".exe"

 ngx_long_start='@<<
  '
diff --git a/auto/cc/owc b/auto/cc/owc
index a063aa34..f7fd88c9 100644
--- a/auto/cc/owc
+++ b/auto/cc/owc
@@ -84,7 +84,6 @@ ngx_include_opt="-i="
 ngx_objout="-fo"
 ngx_binout="-fe="
 ngx_objext="obj"
-ngx_binext=".exe"

 ngx_regex_dirsep='\\'
 ngx_dirsep="\\"
-- 
2.13.0.windows.1.7.g80a6209eb5
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Configure: Fix compilation on MSYS2 / MinGW64

[Orgad Shaneh]

---
 auto/configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/auto/configure b/auto/configure
index ceff15e4..107c2b5f 100755
--- a/auto/configure
+++ b/auto/configure
@@ -36,7 +36,7 @@ if test -z "$NGX_PLATFORM"; then
 NGX_PLATFORM="$NGX_SYSTEM:$NGX_RELEASE:$NGX_MACHINE";

 case "$NGX_SYSTEM" in
-MINGW32_*)
+MINGW32_*|MINGW64_*|MSYS_*)
 NGX_PLATFORM=win32
 ;;
 esac
-- 
2.13.0.windows.1.7.g80a6209eb5
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] Fix compilation on MinGW64

[Orgad Shaneh]

On Tue, Jun 6, 2017 at 5:11 PM, Maxim Dounin  wrote:
> Hello!
>
> On Tue, Jun 06, 2017 at 01:57:39PM +0300, Orgad Shaneh wrote:
>
>> I already proposed a similar patch (without MSYS) on November, but it
>> was unnoticed since then.
>> ---
>>  auto/configure | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/auto/configure b/auto/configure
>> index ceff15e4..107c2b5f 100755
>> --- a/auto/configure
>> +++ b/auto/configure
>> @@ -36,7 +36,7 @@ if test -z "$NGX_PLATFORM"; then
>>  NGX_PLATFORM="$NGX_SYSTEM:$NGX_RELEASE:$NGX_MACHINE";
>>
>>  case "$NGX_SYSTEM" in
>> -MINGW32_*)
>> +MINGW32_*|MINGW64_*|MSYS_*)
>>  NGX_PLATFORM=win32
>>  ;;
>>  esac
>> --
>> 2.13.0.windows.1.7.g80a6209eb5
>
> A review of your previous patch can be found here:
>
> http://mailman.nginx.org/pipermail/nginx-devel/2016-December/009233.html
>
> It still applies.
>
> --
> Maxim Dounin
> http://nginx.org/
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

Thanks. I wasn't aware that I should stay subscribed to receive replies.

Posted a fixed patch (using Git, I hope you don't mind).

- Orgad
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] Use .exe for binaries for all win32 compilers

[Maxim Dounin]

Hello!

On Tue, Jun 06, 2017 at 01:58:17PM +0300, Orgad Shaneh wrote:

> ---
>  auto/cc/conf | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/auto/cc/conf b/auto/cc/conf
> index afbca62b..19a231aa 100644
> --- a/auto/cc/conf
> +++ b/auto/cc/conf
> @@ -144,7 +144,9 @@ fi
>  CFLAGS="$CFLAGS $NGX_CC_OPT"
>  NGX_TEST_LD_OPT="$NGX_LD_OPT"
> 
> -if [ "$NGX_PLATFORM" != win32 ]; then
> +if [ "$NGX_PLATFORM" = win32 ]; then
> +ngx_binext=".exe"
> +else
> 
>  if test -n "$NGX_LD_OPT"; then
>  ngx_feature=--with-ld-opt=\"$NGX_LD_OPT\"
> -- 
> 2.13.0.windows.1.7.g80a6209eb5

http://mailman.nginx.org/pipermail/nginx-devel/2016-December/009234.html

-- 
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] Fix compilation on MinGW64

[Maxim Dounin]

Hello!

On Tue, Jun 06, 2017 at 01:57:39PM +0300, Orgad Shaneh wrote:

> I already proposed a similar patch (without MSYS) on November, but it
> was unnoticed since then.
> ---
>  auto/configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/auto/configure b/auto/configure
> index ceff15e4..107c2b5f 100755
> --- a/auto/configure
> +++ b/auto/configure
> @@ -36,7 +36,7 @@ if test -z "$NGX_PLATFORM"; then
>  NGX_PLATFORM="$NGX_SYSTEM:$NGX_RELEASE:$NGX_MACHINE";
> 
>  case "$NGX_SYSTEM" in
> -MINGW32_*)
> +MINGW32_*|MINGW64_*|MSYS_*)
>  NGX_PLATFORM=win32
>  ;;
>  esac
> -- 
> 2.13.0.windows.1.7.g80a6209eb5

A review of your previous patch can be found here:

http://mailman.nginx.org/pipermail/nginx-devel/2016-December/009233.html

It still applies.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

nginx качает один и тот же файл в несколько коннектов с бэкенда

[Yury Lyakh]

День добрый, может кто сталкивался с проблемой закачки файлов с бэкенда 
параллельно в несколько потоков.

Есть мелкий конфиг ниже.
Клиенты приходят с запросами ренжовыми и обычными, если файл отсутствует в кеше 
он начинает качаться с бэкенда, но качается во столько нитей сколько клиентов 
запросило файл. В итоге трафик на бэкенде растет в прогрессии и все закономерно 
встает через пару минут.

применили:
proxy_cache_lock on;
и
proxy_cache_use_stale updating;
но ситуация не изменилась, все равно качается в множество нитей

Почистили полностью машину от временных файлов (temp файлы закачки находятся в 
кеше use_temp_path=off).
Запустили трафик, буквально через 10 секунд прошелся по кешу в поиске временных 
файлов, чтобы посмотреть их KEY в заголовке, видим что одновременно создались и 
качаются 177 временных файлов для одного по сути файла:

[root@upload-3 cache]# find -L ./ -type f -iname '*\.[0-9]*' | xargs head -n2 | 
grep -a ^KEY | sort | uniq -c
177 KEY: /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001

самы файлы выглядят как:
...
-rw--- 1 nginx nginx  205168640 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000253
-rw--- 1 nginx nginx  209281024 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000254
-rw--- 1 nginx nginx  286048256 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000255
-rw--- 1 nginx nginx  671723520 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000257
-rw--- 1 nginx nginx  217743360 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000258
-rw--- 1 nginx nginx  239915008 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000259
-rw--- 1 nginx nginx  635768832 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000261



версия nginx-1.13.1

конфиг:
proxy_cache_path /var/lib/nginx/cache/wop  levels=2:2 keys_zone=wop:20m 
inactive=2d use_temp_path=off;

server {
listen 80;
listen [::]:80;
server_name dl-share.wop.net ;

proxy_cache wop;
proxy_ignore_client_abort on;

location / {
proxy_pass http://dl.wop.net ;
proxy_set_header Host   $proxy_host;
proxy_cache_lock on;
proxy_cache_lock_age 1d;
proxy_cache_lock_timeout 1d;
proxy_cache_use_stale error updating;
proxy_cache_key "$uri";
proxy_cache_revalidate on;
proxy_cache_valid 404 10s;
proxy_cache_valid 200 1h;
}
}

запросы с которыми идут пользователи:

"195.242.151.17" "-" "-" "[06/Jun/2017:13:03:28 +]" "GET 
/ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" 
"0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" 
"dl-share.wop.net " "81.114" "81.114" "235" 
"bytes=1744977920-1745043455" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" 
"0" "-" "-"
"195.242.151.17" "-" "-" "[06/Jun/2017:13:03:26 +]" "GET 
/ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" 
"0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" 
"dl-share.wop.net " "121.167" "121.167" "235" 
"bytes=2059403264-2059468799" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" 
"0" "-" "-"

Ткните пожалуйста в документацию где я не дочитал, что вообще происходит?..
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: real_ip on Azure Cloud + Application Gateway

[Maxim Dounin]

Hello!

On Tue, Jun 06, 2017 at 04:12:20PM +0300, Sergey Kagansky wrote:

> Добрый день!
> Пользуемся Nginx в облаке Azure
> В качестве лоадбалансера перед несколькими Nginx серверами используем
> Application Gateway.
> Проблема в том, что он в заголовке X-Forwarded-For передаёт IP:PORT (пример
> ниже)
> Вопрос: можно это как то излечить и получить в логах Nginx правильный адрес
> клиента, потому как в данной ситуации Nginx подставляет адрес балансера
> который передается без порта
> 
> X-FORWARDED-PROTO: https
> X-FORWARDED-PORT: 443
> *X-Forwarded-For: 13.93.225.14:1217 *

Если вы используете актуальную версию nginx'а, то всё должно 
работать со штатным модулем realip.  Порты в X-Forwarded-For 
поддерживаются начиная с nginx 1.11.0, см.  
http://nginx.org/ru/docs/http/ngx_http_realip_module.html.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: SRP Support.

[Maxim Dounin]

Hello!

On Tue, Jun 06, 2017 at 10:06:57AM +0300, Антон Чивкунов via nginx wrote:

> Hi all.
> Please kindly let me know if nginx (or nginx Plus) have support 
> of SRP (Secure Remote Password Protocol) authentication?
> After checking nginx documentation and source code I guess the 
> answer on my question will be ‘NO’, but would like to get 
> confirmation (may be I missed something).
> If SRP is not supported, then I suppose the only way to get it 
> is to write new module by ourselves?

No, SRP is not currently supported.

BTW, you may want to check nginx-devel@ for preleminary patches about 
adding PSK support, which is somewhat related:

http://mailman.nginx.org/pipermail/nginx-devel/2017-June/009995.html

-- 
Maxim Dounin
http://nginx.org/
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

How to do proxy in this case

[David Woodstuck]

I have one proxy server(nginx) - such as nginx.mycom.com and three upstream
servers - name1.mycom.com, name2.mycom.com name3.mycom.com for my one
application. Contents from upstream servers have a lot of iframes which
have different domains. I want to allow XSS for these different domains. I
don't know how to achieve XSS for this application.

For instance, when contents from name1.mycom.com has two iframes that their
src are name1.mycom.com/content1 and name2.mycom.com/content2, can I do the
following to achieve XSS?

(1). replace name1.mycom.com/content1 with nginx.mycom.com/content1
  replace name2.mycom.com/content1 with nginx.mycom.com/content2
  add_header for XSS
(2). When nginx.mycom.com/content1 request is coming, proxy to
name1.mycom.com/content1
  add_header for XSS
(3). When nginx.mycom.com/content2 request is coming, proxy to
name2.mycom.com/content2
  add_header for XSS

I only have limited knowledge of Nignx. I like to use NginxScript to
achieve this goal. Can I do it in Nginx. I do appreciate your suggestion
and some examples.

David
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

real_ip on Azure Cloud + Application Gateway

[Sergey Kagansky]

Добрый день!
Пользуемся Nginx в облаке Azure
В качестве лоадбалансера перед несколькими Nginx серверами используем
Application Gateway.
Проблема в том, что он в заголовке X-Forwarded-For передаёт IP:PORT (пример
ниже)
Вопрос: можно это как то излечить и получить в логах Nginx правильный адрес
клиента, потому как в данной ситуации Nginx подставляет адрес балансера
который передается без порта

X-FORWARDED-PROTO: https
X-FORWARDED-PORT: 443
*X-Forwarded-For: 13.93.225.14:1217 *

Заранее всем благодарен

-- 
 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: source rpms missing?

[Konstantin Pavlov]

Hello,

On 06/06/2017 04:00, David Kewley wrote:
> In http://nginx.org/packages/rhel/6/SRPMS/ I don't see 
> nginx-1.12.0-1.el6.ngx.src.rpm as expected. Similar for RHEL 5 and 7, and for 
> CentOS. This appears just to affect this release not (most of) the previous 
> releases.

RHEL5 and CentOS5 are discontinued by the vendor, so don't expect SRPMS (or 
binary RPMS for that matter) to appear for those distributions.

6 and 7 is a different matter, though, thanks - will fix.

> Could the srpms be posted? If I should take a different route to raise this 
> issue, please point me in the right direction.

You can use SRPMS from CentOS 6 until we fix the repositories: 
http://nginx.org/packages/centos/6/SRPMS/ - those are exactly the same source 
packages we use to provide RHEL binaries.

Thank you,

-- 
Join us at nginx.conf, Sept. 6-8, Portland, OR
Konstantin Pavlov
www.nginx.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [PATCH 3 of 3] Headers filter: added "add_trailer" directive

[Maxim Dounin]

Hello!

On Mon, Jun 05, 2017 at 09:59:45PM -0700, Piotr Sikora via nginx-devel wrote:

> Hey Maxim,
> 
> > It doesn't look like "if (h[i].value.value.len)" is needed here.
> > It is either true, or the "add_trailer" directive is nop and we
> > already know this while parsing the configuration.
> >
> > -if (h[i].value.value.len) {
> > -r->expect_trailers = 1;
> > -break;
> > -}
> > +r->expect_trailers = 1;
> > +break;
> 
> Well, both "add_header" and "add_trailer" allow setting something like:
> 
> add_trailer Empty "";
> 
> which will get added to headers / trailers list.
> 
> I've added this extra check to avoid forcing chunked encoding with
> such configuration.
> 
> Maybe we should reject it during configuration instead, or ignore this
> case and let it force chunked encoding? Which one do you prefer?

I think it is perfectly ok to ignore this and let if force chunked 
encoding (and this is what the suggested change does).

-- 
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 3] Added support for trailers in HTTP responses

[Maxim Dounin]

Hello!

On Mon, Jun 05, 2017 at 09:56:03PM -0700, Piotr Sikora via nginx-devel wrote:

> Hey Maxim,
> 
> > I would prefer to preserve the typical code path (when there are no
> > trailers) without an extra allocation.  It looks like it would be
> > as trivail as:
> >
> > @@ -273,14 +273,18 @@ ngx_http_chunked_create_trailers(ngx_htt
> >  b->memory = 1;
> >  b->last_buf = 1;
> >
> > +if (len == sizeof(CRLF "0" CRLF CRLF) - 1) {
> > +b->pos = (u_char *) CRLF "0" CRLF CRLF;
> > +b->last = b->pos + sizeof(CRLF "0" CRLF CRLF) - 1;
> > +return cl;
> > +}
> 
> Sounds good, but the if statement reads a bit weird.
> 
> What about this instead, even though it might be a bit more expensive?
> 
> @@ -236,7 +236,7 @@ ngx_http_chunked_create_trailers(ngx_http_request_t *r,
>  ngx_list_part_t  *part;
>  ngx_table_elt_t  *header;
> 
> -len = sizeof(CRLF "0" CRLF CRLF) - 1;
> +len = 0;
> 
>  part = >headers_out.trailers.part;
>  header = part->elts;
> @@ -273,12 +273,14 @@ ngx_http_chunked_create_trailers(ngx_http_request_t *r,
>  b->memory = 1;
>  b->last_buf = 1;
> 
> -if (len == sizeof(CRLF "0" CRLF CRLF) - 1) {
> +if (len == 0) {
>  b->pos = (u_char *) CRLF "0" CRLF CRLF;
>  b->last = b->pos + sizeof(CRLF "0" CRLF CRLF) - 1;
>  return cl;
>  }
> 
> +len += sizeof(CRLF "0" CRLF CRLF) - 1;
> +
>  b->pos = ngx_palloc(r->pool, len);
>  if (b->pos == NULL) {
>  return NULL;

I've tried this as well, and decided that "if (len == 
sizeof(...))" is slightly more readable, and also produces smaller 
patch to your code.   No strict preference though, feel free to 
use any variant you think is better.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Use .exe for binaries for all win32 compilers

[Orgad Shaneh]

---
 auto/cc/conf | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/auto/cc/conf b/auto/cc/conf
index afbca62b..19a231aa 100644
--- a/auto/cc/conf
+++ b/auto/cc/conf
@@ -144,7 +144,9 @@ fi
 CFLAGS="$CFLAGS $NGX_CC_OPT"
 NGX_TEST_LD_OPT="$NGX_LD_OPT"

-if [ "$NGX_PLATFORM" != win32 ]; then
+if [ "$NGX_PLATFORM" = win32 ]; then
+ngx_binext=".exe"
+else

 if test -n "$NGX_LD_OPT"; then
 ngx_feature=--with-ld-opt=\"$NGX_LD_OPT\"
-- 
2.13.0.windows.1.7.g80a6209eb5
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Fix compilation on MinGW64

[Orgad Shaneh]

I already proposed a similar patch (without MSYS) on November, but it
was unnoticed since then.
---
 auto/configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/auto/configure b/auto/configure
index ceff15e4..107c2b5f 100755
--- a/auto/configure
+++ b/auto/configure
@@ -36,7 +36,7 @@ if test -z "$NGX_PLATFORM"; then
 NGX_PLATFORM="$NGX_SYSTEM:$NGX_RELEASE:$NGX_MACHINE";

 case "$NGX_SYSTEM" in
-MINGW32_*)
+MINGW32_*|MINGW64_*|MSYS_*)
 NGX_PLATFORM=win32
 ;;
 esac
-- 
2.13.0.windows.1.7.g80a6209eb5
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 2 of 3] HTTP/2: added support for trailers in HTTP responses

[Maxim Konovalov]

On 05/06/2017 21:00, Maxim Dounin wrote:
> Hello!
> 
> On Fri, Jun 02, 2017 at 08:33:46PM -0700, Piotr Sikora via nginx-devel wrote:
> 
>> # HG changeset patch
>> # User Piotr Sikora 
>> # Date 1493191954 25200
>> #  Wed Apr 26 00:32:34 2017 -0700
>> # Node ID 8d74ff6c2015180f5c1f399f492214d7d0a52b3f
>> # Parent  41c09a2fd90410e25ad8515793bd48028001c954
>> HTTP/2: added support for trailers in HTTP responses.
>>
>> Signed-off-by: Piotr Sikora 
> 
> I've asked Valentin to look into this part.  Hopefully he'll be 
> able to do so in a couple of days.
> 
> [...]
> 
To be precise and to avoid confusion: Valentin is on the conf today
so expect his feedback this week.

-- 
Maxim Konovalov
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

SRP Support.

[Антон Чивкунов via nginx]

Hi all.
Please kindly let me know if nginx (or nginx Plus) have support of SRP (Secure 
Remote Password Protocol) authentication?
After checking nginx documentation and source code I guess the answer on my 
question will be ‘NO’, but would like to get confirmation (may be I missed 
something).
If SRP is not supported, then I suppose the only way to get it is to write new 
module by ourselves?
Thank you in advance!
BR/Anton.___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Proxy parameter to nginx service

[juan_barbancho_rsi]

Hi,

I thought that the use of proxy_pass could be the opction to pass the 
proxy environment var, in the ngnix.conf file.

This may be at general level of only at proxy_pass level.

Could be a improve for the nginx server ?

Saludos

Juanp


 ADVERTENCIA LEGAL ---
"Este mensaje puede contener INFORMACIÓN CONFIDENCIAL, PRIVILEGIADA y/o 
DATOS DE CARÁCTER PERSONAL. Si usted no es el destinatario indicado en 
este mensaje (o el responsable de entregarlo al mismo) no debe copiar o 
entregar este mensaje a nadie más. En dicho caso le rogamos que destruya 
este mensaje y lo notifique al remitente. Por favor, indique 
inmediatamente si usted o su empresa no aceptan comunicaciones de este 
tipo por Internet. Las opiniones, conclusiones y demás información 
incluida en este mensaje que no esté relacionada con asuntos profesionales 
del Grupo Caja Rural se entenderá que nunca se ha dado, ni está respaldada 
por el mismo."

 LEGAL ADVICE ---
"This message can contain restricted confidential information or personal 
data. If you are not the intended recipient (or the responsible to give 
it) you shouldn't copy or forward this message. If this message has been 
received by mistake, please, delete it and inform to addressee. If you or 
your company don't accept this kind of information by internet, please 
send us a notification inmediately. Grupo Caja Rural are not responsible 
for the opinions, conclusions, contents or any file attached included in 
this message, which were not related to professional matters.”
---
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx