Quantcast
Channel: Nginx Forum
Viewing all 53287 articles
Browse latest View live

Re: nginx и смена симлинков

$
0
0
Приветствую.

1) Закомментируйте в файле fastcgi_params параметр SCRIPT_FILENAME , если
еще не сделали этого
2)
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
замените $document_root на $realpath_root
fastcgi_param SCRIPT_FILENAME $realpath_root/index.php;

Почитать про переменную можно тут
http://nginx.org/ru/docs/http/ngx_http_core_module.html
И как выше советовали почитайте про php realpath cache чтобы было понимание.

3)
> # /var/www/html указывает на /var/www/stable , переключаемся на current

>rm /var/www/html; ln -s /var/www/current/ /var/www/html

Я бы переделал чуть по другому.
ln -s path_to_latest_release /var/www/html_tmp
mv -Tf /var/www/html_tmp /var/www/html


28 ноября 2017 г., 20:34 пользователь Илья Шипицин <chipitsine@gmail.com>
написал:

>
>
> 28 ноября 2017 г., 20:52 пользователь Иван <nginx@kinetiksoft.com>
> написал:
>
>> Здравствуйте!
>>
>>
>>
>> nginx 1.12.2, debian 8, php-fpm (5.6)
>>
>> # nginx -V
>> nginx version: nginx/1.12.2
>> built by gcc 4.9.2 (Debian 4.9.2-10)
>> built with OpenSSL 1.0.1t 3 May 2016
>> TLS SNI support enabled
>> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
>> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf
>> --error-log-path=/va
>> r/log/nginx/error.log --http-log-path=/var/log/nginx/access.log
>> --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
>> --http-client-body-temp-path=/var/c
>> ache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp
>> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
>> --http-uwsgi-temp-path=/var/cach
>> e/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp
>> --user=nginx --group=nginx --with-compat --with-file-aio --with-threads
>> --with-http_addition_
>> module --with-http_auth_request_module --with-http_dav_module
>> --with-http_flv_module --with-http_gunzip_module
>> --with-http_gzip_static_module --with-http_mp4_mod
>> ule --with-http_random_index_module --with-http_realip_module
>> --with-http_secure_link_module --with-http_slice_module
>> --with-http_ssl_module --with-http_stub_sta
>> tus_module --with-http_sub_module --with-http_v2_module --with-mail
>> --with-mail_ssl_module --with-stream --with-stream_realip_module
>> --with-stream_ssl_module --w
>> ith-stream_ssl_preread_module --with-cc-opt='-g -O2
>> -fstack-protector-strong -Wformat -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-
>> z,relro -Wl,-z,now -Wl,--as-needed -pie'
>>
>>
>>
>> Есть самописное приложение на php. У него есть две версии: stable и
>> current. Для быстрой смены используется следующая схема:
>>
>> /var/www/stable/ - тут лежит stable
>>
>> /var/www/current/ - тут лежит current
>>
>> /var/www/html - симлинк на на /var/www/stable или /var/www/current
>>
>>
>>
>> В nginx пыха сконфигурирована как
>>
>>
>>
>> root /var/www/html;
>>
>> location / {
>>
>> fastcgi_pass unix:/run/php-fpm.socket;
>>
>
> сделайте тут проксирование на апстрим (в котором перечислены несколько
> бекендов)
> fastcgi_connect_timeout сделайте минимальным
>
>
>
>> include fastcgi_params;
>>
>> fastcgi_param SCRIPT_FILENAME $document_root/index.php;
>>
>> }
>>
>>
>>
>> Проблема в том. что при переключение stable->current (и наоборот),
>>
>
> достаточно будет запустить тот или иной бекенд
>
> (не уверен, что с unix-сокетами получится, в крайнем случае можно на tcp
> проксировать)
>
>
>
>> которая происходит примерно так:
>>
>> # /var/www/html указывает на /var/www/stable , переключаемся на current
>>
>> rm /var/www/html; ln -s /var/www/current/ /var/www/html
>>
>>
>>
>> до упора используются файлы из старой директории (stable в примере выше).
>> Не помогает ни очистка opcache, ни рестарт пыхи. Только restart (возможно
>> reload, не уверен) nginx.
>>
>> Хотелось бы
>>
>> 1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк?
>>
>> 2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в
>> принципе готовы поменять воркфлоу, но пока не понимаем как.
>>
>>
>>
>> С уважением, Иван.
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx и смена симлинков

$
0
0
Здравствуйте!

В письме от вторник, 28 ноября 2017 г. 21:34:02 MSK пользователь Илья Шипицин
написал:
>
> сделайте тут проксирование на апстрим (в котором перечислены несколько
> бекендов)
> fastcgi_connect_timeout сделайте минимальным
>
>
> достаточно будет запустить тот или иной бекенд
>
> (не уверен, что с unix-сокетами получится, в крайнем случае можно на tcp
> проксировать)
>

Мне в итоге помог предложенный чуть ранее и дополненный тут: https://
stackoverflow.com/questions/23737627/php-opcache-reset-symlink-style-deployment/
23904770#23904770

совет сделать

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;

Меня теперь волнует не выполняет ли nginx тот самый "тяжелый"
(как описано, например, https://habrahabr.ru/post/266909/) realpath
при использовании $realpath_root.

По непосредственно вашему способу вопрос только один, учитывая исторически
багнутый reload в php-fpm не понятно как запускать\останавливать один пул php,
не трогая другие.

С уважением, Иван.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

RE: [IE] Fwd: Problem with CAS on nginx configuration

$
0
0
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: domain only reachable with https:// in front

$
0
0
ahhh that's right, thanks for all your help guys !

Moving SSL termination to the edge increased the instance of 502 errors

$
0
0
Hi All,

We installed nginx as load balancer/failover in front of two upstream web servers.

At first SSL terminated at the web servers and nginx was configured as TCP passthrough on 443.

We rarely experiences 502s and when it did it was likely due to tuning/tweaking.

About a week ago we moved SSL termination to the edge. Since then we've been getting daily 502s. A small percentage - never reaching 1%. But with ½ million requests per day, we are starting to get complaints.

Stranger: the percentage seems to be rising.

I have more details and a pretty picture here:

https://serverfault.com/questions/885638/moving-ssl-termination-to-the-edge-increased-the-instance-of-502-errors


Any advice how to squash those 502s? Should I be worried nginx is leaking?
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Installing module in Nginx with souce, after installing from Repositiory

$
0
0
I have installed the mainline version of Nginx using the Lauchpad PPA Respositiy;
Via: add-apt-repository ppa:nginx/development

I wouldlike to install an additonal module into it, however I need to install it from source.

If I was to download the correct version from the Nginx site to my server and install the module via source, will this work ok, or will it mess up what had already been installed?

Thanks

[PATCH] Workaround for systemd error messages about nginx pid file.

$
0
0
# HG changeset patch
# User Gena Makhomed <gmm@csdoc.com>
# Date 1511951401 -7200
# Wed Nov 29 12:30:01 2017 +0200
# Node ID b529ea784244e13d8a5e58a12c8b639351652057
# Parent fc0d06224edac2c7cfbfd9a4def478f285d9957b
Workaround for systemd error messages about nginx pid file.

Race condition exists between nginx writing and systemd reading pid file.
Sometimes systemd can produce error messages about nginx pid file:

systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument
systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

This patch add small delay before nginx original process exit
to eliminate race condition between nginx and systemd.

diff -r fc0d06224eda -r b529ea784244 src/os/unix/ngx_daemon.c
--- a/src/os/unix/ngx_daemon.c Tue Nov 28 13:09:54 2017 +0300
+++ b/src/os/unix/ngx_daemon.c Wed Nov 29 12:30:01 2017 +0200
@@ -23,6 +23,7 @@
break;

default:
+ ngx_msleep(100);
exit(0);
}


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

Re: [PATCH] Workaround for systemd error messages about nginx pid file.

$
0
0
Hello!

On Wed, Nov 29, 2017 at 12:33:28PM +0200, Gena Makhomed wrote:

> # HG changeset patch
> # User Gena Makhomed <gmm@csdoc.com>
> # Date 1511951401 -7200
> # Wed Nov 29 12:30:01 2017 +0200
> # Node ID b529ea784244e13d8a5e58a12c8b639351652057
> # Parent fc0d06224edac2c7cfbfd9a4def478f285d9957b
> Workaround for systemd error messages about nginx pid file.
>
> Race condition exists between nginx writing and systemd reading pid file.
> Sometimes systemd can produce error messages about nginx pid file:
>
> systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument
> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
>
> This patch add small delay before nginx original process exit
> to eliminate race condition between nginx and systemd.
>
> diff -r fc0d06224eda -r b529ea784244 src/os/unix/ngx_daemon.c
> --- a/src/os/unix/ngx_daemon.c Tue Nov 28 13:09:54 2017 +0300
> +++ b/src/os/unix/ngx_daemon.c Wed Nov 29 12:30:01 2017 +0200
> @@ -23,6 +23,7 @@
> break;
>
> default:
> + ngx_msleep(100);
> exit(0);
> }

No, thanks. As a systemd-specific workaround this definitely
should be in the service unit file instead, if at all. Moreover, as
previously explained, the message in question is harmless and the
workaround is not needed for anything but silencing the message.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Moving SSL termination to the edge increased the instance of 502 errors

$
0
0
Hello!

On Wed, Nov 29, 2017 at 04:27:37AM +0000, Michael Ottoson wrote:

> Hi All,
>
> We installed nginx as load balancer/failover in front of two upstream web servers.
>
> At first SSL terminated at the web servers and nginx was configured as TCP passthrough on 443.
>
> We rarely experiences 502s and when it did it was likely due to tuning/tweaking.
>
> About a week ago we moved SSL termination to the edge. Since then we've been getting daily 502s. A small percentage - never reaching 1%. But with ½ million requests per day, we are starting to get complaints.
>
> Stranger: the percentage seems to be rising.
>
> I have more details and a pretty picture here:
>
> https://serverfault.com/questions/885638/moving-ssl-termination-to-the-edge-increased-the-instance-of-502-errors
>
>
> Any advice how to squash those 502s? Should I be worried nginx is leaking?

First of all, you have to find the reason for these 502 errors.
Looking into the error log is a good start.

As per provided serverfault question, you see "no live upstreams"
errors in logs. These errors mean that all configured upstream
servers were disabled due to previous errors (see
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails),
that is, these errors are just a result of previous errors. You
have to find out real errors, they should be in the error log too.

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

RE: Moving SSL termination to the edge increased the instance of 502 errors

$
0
0
Thanks, Maxim.

That makes a lot of sense. However, the problem started at exactly the same time we moved SSL termination. There were no changes to the application. It is unlikely to be a mere coincidence - but it could be.

We were previously using HAPROXY for load balancing (well, the company we inherited this from did) and the same happened when they tried moving SSL termination.

There is a reply to my question on serverfault, suggesting increasing keepalives (https://www.nginx.com/blog/load-balancing-with-nginx-plus-part2/#keepalive). This is because moving SSL increases the number of TCP connects. I'll give that a try and report back.

-----Original Message-----
From: nginx [mailto:nginx-bounces@nginx.org] On Behalf Of Maxim Dounin
Sent: Wednesday, November 29, 2017 7:43 AM
To: nginx@nginx.org
Subject: Re: Moving SSL termination to the edge increased the instance of 502 errors

Hello!

On Wed, Nov 29, 2017 at 04:27:37AM +0000, Michael Ottoson wrote:

> Hi All,
>
> We installed nginx as load balancer/failover in front of two upstream web servers.
>
> At first SSL terminated at the web servers and nginx was configured as TCP passthrough on 443.
>
> We rarely experiences 502s and when it did it was likely due to tuning/tweaking.
>
> About a week ago we moved SSL termination to the edge. Since then we've been getting daily 502s. A small percentage - never reaching 1%. But with ½ million requests per day, we are starting to get complaints.
>
> Stranger: the percentage seems to be rising.
>
> I have more details and a pretty picture here:
>
> https://serverfault.com/questions/885638/moving-ssl-termination-to-the
> -edge-increased-the-instance-of-502-errors
>
>
> Any advice how to squash those 502s? Should I be worried nginx is leaking?

First of all, you have to find the reason for these 502 errors.
Looking into the error log is a good start.

As per provided serverfault question, you see "no live upstreams"
errors in logs. These errors mean that all configured upstream servers were disabled due to previous errors (see http://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails),
that is, these errors are just a result of previous errors. You have to find out real errors, they should be in the error log too.

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

Re: [PATCH] Workaround for systemd error messages about nginx pid file.

$
0
0
On 29.11.2017 14:30, Maxim Dounin wrote:

> No, thanks. As a systemd-specific workaround this definitely
> should be in the service unit file instead, if at all. Moreover, as
> previously explained, the message in question is harmless and the
> workaround is not needed for anything but silencing the message.

These messages in question are harmless only if race condition occurs.

There are cases when these systemd messages talk about real problems,
for example, if user add to config pid directive with different
from unit-file pidfile location, or if nginx compiled with
different --pid-path= configure argument. For example:

In unit-file: PIDFile=/var/run/nginx.pid
in nginx config: pid /different/path/to/nginx.pid;
or in binary: --pid-path=/usr/local/nginx/logs/nginx.pid

The main purpose of my patch is to suppress harmless systemd messages
and leave alone all systemd messages which are indicates real problems.

nginx service unit file is not very good location for this workaround,
because there are many different linux distros and unit file sources,
not all nginx users use official packages from nginx.org site.

--
Best regards,
Gena
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Reverse proxy

$
0
0
Hi everybody,

I have a problem, I want to use nginx as a reverse proxy.
My lan server is reachable by https://test.mydomain.lan/rococo and I want to access it by https://work.rococo.com.

My config file is :
server {
listen 443 ssl;
server_name work.rococo.com;

ssl_certificate /etc/nginx/ssl/rococo.com/rococo.com.crt;
ssl_certificate_key /etc/nginx/ssl/rococo.com/rococo.com.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;
ssl_verify_client off;

# gestion des logs
access_log /var/log/nginx/rococo.com_access.log;
error_log /var/log/nginx/rococo.com_error.log;

location ~ /\. {
deny all;
access_log off;
log_not_found off;
}

location / {
allow all;
proxy_pass https://test.mydomain.lan;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
sub_filter_types text/html application/x-javascript;
sub_filter 'https://test.mydomain.lan:443' 'https://test.mydomain.lan/rococo';
sub_filter 'https:\u002f\u002ftest.mydomain.lan:443' 'https://test.mydomain.lan/rococo';
sub_filter 'test.mydomain.lan:443' 'work.rococo.com';
sub_filter_once off;
}
}


This file config doesn't work. Have you an idea?

Thank you for your help

Документация, директива pid

$
0
0
Здравствуйте, All!

В документации по директиве pid есть ошибки:

http://nginx.org/ru/docs/ngx_core_module.html#pid
http://nginx.org/en/docs/ngx_core_module.html#pid

Default: pid nginx.pid;

На самом деле значение по-умолчанию для директивы pid
берется из аргумента configure --pid-path=

А если аргумент configure --pid-path не задан,
тогда значение по-умолчанию равно logs/nginx.pid

Например, для официальных linux-сборок с сайта nginx.org
будет такое значение Default: pid /var/run/nginx.pid;

А для официальных windows-сборок с сайта nginx.org
будет такое значение Default: pid logs/nginx.pid;

--
Best regards,
Gena

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

Re: Moving SSL termination to the edge increased the instance of 502 errors

$
0
0
What's the backend for this IIS, NGINX, Apache, etc? Is it requiring SNI?
Do you have multiple hostnames?

On Wed, Nov 29, 2017 at 7:05 AM, Michael Ottoson <michael.ottoson@cri.com>
wrote:

> Thanks, Maxim.
>
> That makes a lot of sense. However, the problem started at exactly the
> same time we moved SSL termination. There were no changes to the
> application. It is unlikely to be a mere coincidence - but it could be.
>
> We were previously using HAPROXY for load balancing (well, the company we
> inherited this from did) and the same happened when they tried moving SSL
> termination.
>
> There is a reply to my question on serverfault, suggesting increasing
> keepalives (https://www.nginx.com/blog/load-balancing-with-nginx-
> plus-part2/#keepalive). This is because moving SSL increases the number
> of TCP connects. I'll give that a try and report back.
>
> -----Original Message-----
> From: nginx [mailto:nginx-bounces@nginx.org] On Behalf Of Maxim Dounin
> Sent: Wednesday, November 29, 2017 7:43 AM
> To: nginx@nginx.org
> Subject: Re: Moving SSL termination to the edge increased the instance of
> 502 errors
>
> Hello!
>
> On Wed, Nov 29, 2017 at 04:27:37AM +0000, Michael Ottoson wrote:
>
> > Hi All,
> >
> > We installed nginx as load balancer/failover in front of two upstream
> web servers.
> >
> > At first SSL terminated at the web servers and nginx was configured as
> TCP passthrough on 443.
> >
> > We rarely experiences 502s and when it did it was likely due to
> tuning/tweaking.
> >
> > About a week ago we moved SSL termination to the edge. Since then we've
> been getting daily 502s. A small percentage - never reaching 1%. But with
> ½ million requests per day, we are starting to get complaints.
> >
> > Stranger: the percentage seems to be rising.
> >
> > I have more details and a pretty picture here:
> >
> > https://serverfault.com/questions/885638/moving-ssl-termination-to-the
> > -edge-increased-the-instance-of-502-errors
> >
> >
> > Any advice how to squash those 502s? Should I be worried nginx is
> leaking?
>
> First of all, you have to find the reason for these 502 errors.
> Looking into the error log is a good start.
>
> As per provided serverfault question, you see "no live upstreams"
> errors in logs. These errors mean that all configured upstream servers
> were disabled due to previous errors (see http://nginx.org/en/docs/http/
> ngx_http_upstream_module.html#max_fails),
> that is, these errors are just a result of previous errors. You have to
> find out real errors, they should be in the error log too.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Документация, директива pid

$
0
0
Hello!

On Wed, Nov 29, 2017 at 04:10:46PM +0200, Gena Makhomed wrote:

> Здравствуйте, All!
>
> В документации по директиве pid есть ошибки:
>
> http://nginx.org/ru/docs/ngx_core_module.html#pid
> http://nginx.org/en/docs/ngx_core_module.html#pid
>
> Default: pid nginx.pid;
>
> На самом деле значение по-умолчанию для директивы pid
> берется из аргумента configure --pid-path=
>
> А если аргумент configure --pid-path не задан,
> тогда значение по-умолчанию равно logs/nginx.pid
>
> Например, для официальных linux-сборок с сайта nginx.org
> будет такое значение Default: pid /var/run/nginx.pid;
>
> А для официальных windows-сборок с сайта nginx.org
> будет такое значение Default: pid logs/nginx.pid;

По очевидным причинам документация не может отражать значение,
специфичное для конкретной сборки. Так что мы там указываем
значение по умолчанию, которое таки по умолчанию.

Какими именно параметрами configure можно переопределить какие
значения - сейчас документировано в выводе "configure --help":

--error-log-path=PATH set error log pathname
--pid-path=PATH set nginx.pid pathname
--lock-path=PATH set nginx.lock pathname

--user=USER set non-privileged user for
worker processes
--group=GROUP set non-privileged group for
worker processes


--http-log-path=PATH set http access log pathname
--http-client-body-temp-path=PATH set path to store
http client request body temporary files
--http-proxy-temp-path=PATH set path to store
http proxy temporary files
--http-fastcgi-temp-path=PATH set path to store
http fastcgi temporary files
--http-uwsgi-temp-path=PATH set path to store
http uwsgi temporary files
--http-scgi-temp-path=PATH set path to store
http scgi temporary files

Частично эта же информация есть на странице
http://nginx.org/en/docs/configure.html.

Возможно, стоит добавить эту информацию в описания соответствующих
директив (в виде note?). Patches, что называется, are welcome.

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

LDAP Authentication

$
0
0
Hello,

I'm trying to link authentication from /htpassword from nginx to an Active directory.
I'm a bit lost on how to do it.

First, is it possible to do it for free or I have to pay for 'nginx plus'.

I saw this tuto but not clear enough for me :
https://www.nginx.com/blog/nginx-plus-authenticate-users/

Then, how to proceees as I don't find this module :
http://nginx.org/en/docs/http/ngx_http_auth_request_module.html

Many thanks for your help.
Crapoulou.

Re: Hide a request cookie in proxy_pass

$
0
0
Hello,

I've found strange behaviour with this rewrite method.
When :
- there are space (%20) in the URI
And
- a cookie match regexp (and is removed)

Nginx replace ";" and " " in Cookie header with %3B%20

For example:
I want to remove "Testy" cookie.
Here is nginx sample config :
server {
set $new_cookie $http_cookie;
if ($http_cookie ~ "(.*)(?:^|;)\s*Testy=[^;]+(.*)") {
set $new_cookie $1$2;
}
if ($new_cookie ~ "^[;]+(.*)") {
set $new_cookie $1;
}
proxy_set_header Cookie $new_cookie;
proxy_pass http://www.com_backend;
}
upstream www.com_backend {
server localhost:9020;
keepalive 30;
}


With this request :
GET /api/TEST%20TEST HTTP/1.1
Cookie: country_code=FR; session=IntcI; lastvisitfor=IjIwMT%3D; Testy=uid%08474524469%26fst%3D15118; teaser=eyJ0eXBl2; popin=eyJib3R0

Nginx remove correctly Testy cookie but forward this cookie header to backend:
Cookie: country_code=FR%3B%20session=IntcI%3B%20lastvisitfor=IjIwMT%3D%3B%20teaser=eyJ0eXBl2%3B%20popin=eyJib3R0

Due to the fact there are no "; " anymore, backend consider there is only one big cookie : "country_code".

nginx version: nginx/1.12.1
OS : CentOS 6.9

Any ideas on how to fix it ?
Thanks.

Anto

Re: Документация, директива pid

$
0
0
On 29.11.2017 17:50, Maxim Dounin wrote:

> Patches, что называется, are welcome.

# HG changeset patch
# User Gena Makhomed <gmm@csdoc.com>
# Date 1511977733 -7200
# Wed Nov 29 19:48:53 2017 +0200
# Node ID 41edc73c0662fa9d62cb2cc7983fd9068fd9b390
# Parent 26e547b1022d5e64fe5dd4060f64f15c678c2e8a
Updated documentation of directive "pid".

diff -r 26e547b1022d -r 41edc73c0662 xml/ru/docs/ngx_core_module.xml
--- a/xml/ru/docs/ngx_core_module.xml Mon Nov 27 11:56:06 2017 +0300
+++ b/xml/ru/docs/ngx_core_module.xml Wed Nov 29 19:48:53 2017 +0200
@@ -401,12 +401,19 @@


<directive name="pid">
-<syntax><value>файл</value></syntax>
-<default>nginx.pid</default>
+<syntax><value>имя файла</value></syntax>
+<default>Зависит от параметров сборки nginx</default>
<context>main</context>

<para>
-Задаёт <value>файл</value>, в котором будет храниться номер (PID)
главного процесса.
+Задаёт <value>имя файла</value>, в котором будет храниться
идентификатор (PID) главного процесса nginx.
+Значение по умолчанию задается в момент конфигурирования nginx
параметром <literal>configure --pid-path</literal>.
+Узнать значение по умолчанию для директивы <literal>pid</literal> можно
запустив команду <literal>nginx -V</literal>
+и посмотрев на значение параметра <literal>configure --pid-path</literal>.
+</para>
+
+<para>
+Не рекомендуется явно указывать значение директивы
<literal>pid</literal> в конфигурационном файле.
</para>

</directive>

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

Re: Moving SSL termination to the edge increased the instance of 502 errors

$
0
0
There are many things that *could* cause what you’re seeing - say at least eight. You might be lucky and guess the right one- but probably smarter to see exactly what the issue is.

Presumably you changed your upstream webservers to do this work, replacing ssl with unencrypted connections? Do you have sar data showing #tcp connections before and after the change? Perhaps every request is negotiating SSL now?
What if you add another nginx instance that doesn’t use ssl at all (just as a test) - does that also have 502s?. You probably have data you need to isolate

Sent from my iPhone

> On Nov 29, 2017, at 8:05 AM, Michael Ottoson <michael.ottoson@cri.com> wrote:
>
> Thanks, Maxim.
>
> That makes a lot of sense. However, the problem started at exactly the same time we moved SSL termination. There were no changes to the application. It is unlikely to be a mere coincidence - but it could be.
>
> We were previously using HAPROXY for load balancing (well, the company we inherited this from did) and the same happened when they tried moving SSL termination.
>
> There is a reply to my question on serverfault, suggesting increasing keepalives (https://www.nginx.com/blog/load-balancing-with-nginx-plus-part2/#keepalive). This is because moving SSL increases the number of TCP connects. I'll give that a try and report back.
>
> -----Original Message-----
> From: nginx [mailto:nginx-bounces@nginx.org] On Behalf Of Maxim Dounin
> Sent: Wednesday, November 29, 2017 7:43 AM
> To: nginx@nginx.org
> Subject: Re: Moving SSL termination to the edge increased the instance of 502 errors
>
> Hello!
>
>> On Wed, Nov 29, 2017 at 04:27:37AM +0000, Michael Ottoson wrote:
>>
>> Hi All,
>>
>> We installed nginx as load balancer/failover in front of two upstream web servers.
>>
>> At first SSL terminated at the web servers and nginx was configured as TCP passthrough on 443.
>>
>> We rarely experiences 502s and when it did it was likely due to tuning/tweaking.
>>
>> About a week ago we moved SSL termination to the edge. Since then we've been getting daily 502s. A small percentage - never reaching 1%. But with ½ million requests per day, we are starting to get complaints.
>>
>> Stranger: the percentage seems to be rising.
>>
>> I have more details and a pretty picture here:
>>
>> https://serverfault.com/questions/885638/moving-ssl-termination-to-the
>> -edge-increased-the-instance-of-502-errors
>>
>>
>> Any advice how to squash those 502s? Should I be worried nginx is leaking?
>
> First of all, you have to find the reason for these 502 errors.
> Looking into the error log is a good start.
>
> As per provided serverfault question, you see "no live upstreams"
> errors in logs. These errors mean that all configured upstream servers were disabled due to previous errors (see http://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails),
> that is, these errors are just a result of previous errors. You have to find out real errors, they should be in the error log too.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Документация, директива pid

$
0
0
Hello!

On Wed, Nov 29, 2017 at 08:05:04PM +0200, Gena Makhomed wrote:

> On 29.11.2017 17:50, Maxim Dounin wrote:
>
> > Patches, что называется, are welcome.
>
> # HG changeset patch
> # User Gena Makhomed <gmm@csdoc.com>
> # Date 1511977733 -7200
> # Wed Nov 29 19:48:53 2017 +0200
> # Node ID 41edc73c0662fa9d62cb2cc7983fd9068fd9b390
> # Parent 26e547b1022d5e64fe5dd4060f64f15c678c2e8a
> Updated documentation of directive "pid".
>
> diff -r 26e547b1022d -r 41edc73c0662 xml/ru/docs/ngx_core_module.xml
> --- a/xml/ru/docs/ngx_core_module.xml Mon Nov 27 11:56:06 2017 +0300
> +++ b/xml/ru/docs/ngx_core_module.xml Wed Nov 29 19:48:53 2017 +0200
> @@ -401,12 +401,19 @@
>
>
> <directive name="pid">
> -<syntax><value>файл</value></syntax>
> -<default>nginx.pid</default>
> +<syntax><value>имя файла</value></syntax>

Использование пробела тут ломает синтаксис - получается, что
директива принимает два праметра, "имя" и "файла". Не надо так.

> +<default>Зависит от параметров сборки nginx</default>
> <context>main</context>

Это необычайно информативно, и наверное всё, что можно тут
сделать, это осознать, что некоторые идеи - просто плохие.

>
> <para>
> -Задаёт <value>файл</value>, в котором будет храниться номер (PID)
> главного процесса.
> +Задаёт <value>имя файла</value>, в котором будет храниться
> идентификатор (PID) главного процесса nginx.
> +Значение по умолчанию задается в момент конфигурирования nginx
> параметром <literal>configure --pid-path</literal>.
> +Узнать значение по умолчанию для директивы <literal>pid</literal> можно
> запустив команду <literal>nginx -V</literal>
> +и посмотрев на значение параметра <literal>configure --pid-path</literal>.
> +</para>

Это мало соответствует тому, что хотелось бы видеть в описании
директивы.

> +
> +<para>
> +Не рекомендуется явно указывать значение директивы
> <literal>pid</literal> в конфигурационном файле.
> </para>

Это не соответствует действительности. PID-файл можно и нужно
задавать во многих ситуациях, например - если на машине
запускается несколько независимых экземпляров nginx'а. Скажем, в
портах FreeBSD такое поддерживается из коробки штатными
rc-скриптами.

>
> </directive>

Отмечу также в скобках, что

- не стоит смешивать несколько изменений в один патч;

- при смысловых изменениях содержимого документации следует менять
ревизию в заголовке соответствующего файл. Это позволяет
показывать на сайте плашку "этот перевод может быть устаревшим,
смотрите английскую версию для ознакомления с последними
изменениями", если перевод по какой-то причине не
обновлён до текущей версии.

- русский язык - не единственный язык документации, и делать патчи
только на один язык - плохая идея. Более того, основной язык
документации - английский, см. выше про ревизии, так что обычно
лучше начинать с него.

- в предыдущем письме было перечислено 11 параметров configure,
которые влияют на значения различных директив. Нет никакого смысла
дублировать эту информацию в описании одной из директив, и не
дублировать в описаниях остальных. Наоборот, есть смысл так не
делать: текущий подход может быть не очень удобен для новичков,
ни разу не сталкивавшихся с configure, но консистентен и логичен.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Viewing all 53287 articles
Browse latest View live