From denis at webmaster.spb.ru  Mon Feb  2 11:33:31 2015
From: denis at webmaster.spb.ru (denis)
Date: Mon, 02 Feb 2015 14:33:31 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?=
 =?UTF-8?B?bnQgcm9vdA==?=
In-Reply-To: <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
References: <20150128131729.5e2967d8@gussie>
 <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org>
 <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com>
 <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
Message-ID: <54CF608B.9000802@webmaster.spb.ru>

28.01.2015 10:26, Eugene Peregudov пишет:
>
> ИМХО, очень зря решается выключением. В первую очередь разработчик 
> приложения и мэйнтейнер должны знать и предоставить информацию о том, 
> какие разрешения необходимы приложению для корректного выполнения, а в 
> идеале еще и написать policy-файл.
>
> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh 
> (http://stopdisablingselinux.com/)
>
До тех пор, пока оно будет включено по умолчанию - все инструкции будут 
начинаться с "выключите selinux", потому что обычно настройка делается 
так - селинух выкл или в permissive, нормальная настройка всего что 
запускаем и разворачиваем, а потом уже смотрим по результату, какие 
права нужны.
Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY", 
первым шагом диагностики всегда будет его отключение. Это как при 
сетевой мистике обычно первый шаг - отключить фаервол. Это неправильно, 
но сразу становится понятно, кто виноват.
До кучи - рабочим и тестовым машинам selinux больше мешает чем помогает, 
и там выключить совсем - нормальное действие.

Из самого банального: ssh, авторизация по ключам, .ssh создан, права 
0700, authorized_keys создан, права 0600, все владельцы правильные. Ключ 
не принимало, пока не выключили selinux (!). В логах ничего про то, что 
выполнена блокировка селинухом. Итог: я тоже приучился первым делом 
выключать это зло, пока оно не научится само и внятно говорить, что не так.


From juriy.foboss at gmail.com  Mon Feb  2 12:24:39 2015
From: juriy.foboss at gmail.com (Juriy Strashnov)
Date: Mon, 2 Feb 2015 15:24:39 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?=
 =?UTF-8?B?bnQgcm9vdA==?=
In-Reply-To: <54CF608B.9000802@webmaster.spb.ru>
References: <20150128131729.5e2967d8@gussie>
 <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org>
 <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com>
 <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
 <54CF608B.9000802@webmaster.spb.ru>
Message-ID: <CAMSCKAiF1Zjsu4gPovXh3VwKrwppm_9wviD1XFn3CUN8WxMXeg@mail.gmail.com>

SELinux умеет объяснять, что делает. Однако получение этой информации
требует некоторых усилий. Например для вышеописанного случая с блокировкой
SSH диагностику можно провести так:

grep sshd  /var/log/audit/audit.log | audit2why

Получим сообщение:

*type=AVC msg=audit(1382808690.186:75768): avc: denied { read } for
pid=26463 comm="sshd" name="authorized_keys2" dev=dm-0 ino=1441809
scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file*

2015-02-02 14:33 GMT+03:00 denis <denis at webmaster.spb.ru>:

> 28.01.2015 10:26, Eugene Peregudov пишет:
>
>>
>> ИМХО, очень зря решается выключением. В первую очередь разработчик
>> приложения и мэйнтейнер должны знать и предоставить информацию о том, какие
>> разрешения необходимы приложению для корректного выполнения, а в идеале еще
>> и написать policy-файл.
>>
>> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh (
>> http://stopdisablingselinux.com/)
>>
>>  До тех пор, пока оно будет включено по умолчанию - все инструкции будут
> начинаться с "выключите selinux", потому что обычно настройка делается так
> - селинух выкл или в permissive, нормальная настройка всего что запускаем и
> разворачиваем, а потом уже смотрим по результату, какие права нужны.
> Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY",
> первым шагом диагностики всегда будет его отключение. Это как при сетевой
> мистике обычно первый шаг - отключить фаервол. Это неправильно, но сразу
> становится понятно, кто виноват.
> До кучи - рабочим и тестовым машинам selinux больше мешает чем помогает, и
> там выключить совсем - нормальное действие.
>
> Из самого банального: ssh, авторизация по ключам, .ssh создан, права 0700,
> authorized_keys создан, права 0600, все владельцы правильные. Ключ не
> принимало, пока не выключили selinux (!). В логах ничего про то, что
> выполнена блокировка селинухом. Итог: я тоже приучился первым делом
> выключать это зло, пока оно не научится само и внятно говорить, что не так.
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Best regards, Juriy Strashnov

Mob. +7 (953) 742-1550
E-mail: j.strashnov at me.com

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150202/ff658831/attachment.html>

From eugene.peregudov at gmail.com  Mon Feb  2 13:10:34 2015
From: eugene.peregudov at gmail.com (Eugene Peregudov)
Date: Mon, 02 Feb 2015 19:10:34 +0600
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?=
 =?UTF-8?B?bnQgcm9vdA==?=
In-Reply-To: <CAMSCKAiF1Zjsu4gPovXh3VwKrwppm_9wviD1XFn3CUN8WxMXeg@mail.gmail.com>
References: <20150128131729.5e2967d8@gussie>
 <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org>
 <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com>
 <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
 <54CF608B.9000802@webmaster.spb.ru>
 <CAMSCKAiF1Zjsu4gPovXh3VwKrwppm_9wviD1XFn3CUN8WxMXeg@mail.gmail.com>
Message-ID: <op.xtfljw0vx116d8@ciu-306-05.corp.nstu.ru>

Коллега Juriy Strashnov опередил :)

В любой непонятной ситуации - смотрите логи, там все есть. Ни одно  
запрещающее действие SELinux не пройдет мимо audit.log, также можно  
поставить setroubleshoot-server, который будет писать все происходящее в  
messages.

Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских  
машинах:

Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае  
вырабатывается набор разрешающих правил еще на машине разработчика. На  
этом этапе уже становится ясно в деталях какие дополнительные разрешения  
(с поправкой на пути) необходимо применить администратору при деплое  
приложения.

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

Juriy Strashnov <juriy.foboss at gmail.com> писал(а) в своём письме Mon, 02  
Feb 2015 18:24:39 +0600:

> SELinux умеет объяснять, что делает. Однако получение этой информации  
> требует некоторых усилий. Например для >вышеописанного случая с  
> блокировкой SSH диагностику можно провести так:
>
> grep sshd  /var/log/audit/audit.log | audit2why
>
> Получим сообщение:
>
>> type=AVC msg=audit(1382808690.186:75768): avc: denied { read } for  
>> pid=26463 comm="sshd" name="authorized_keys2" >dev=dm-0 ino=1441809  
>> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023  
>> >tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
>
> 2015-02-02 14:33 GMT+03:00 denis <denis at webmaster.spb.ru>:
>> 28.01.2015 10:26, Eugene Peregudov пишет:
>>>
>>> ИМХО, очень зря решается выключением. В первую очередь разработчик  
>>> приложения и мэйнтейнер должны знать и >>>предоставить информацию о  
>>> том, какие разрешения необходимы приложению для корректного  
>>> выполнения, а в идеале >>>еще и написать policy-файл.
>>>
>>> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh  
>>> (http://stopdisablingselinux.com/)
>>>
>> До тех пор, пока оно будет включено по умолчанию - все инструкции будут  
>> начинаться с "выключите selinux", >>потому что обычно настройка  
>> делается так - селинух выкл или в permissive, нормальная настройка  
>> всего что >>запускаем и разворачиваем, а потом уже смотрим по  
>> результату, какие права нужны.
>> Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY",  
>> первым шагом диагностики всегда будет его >>отключение. Это как при  
>> сетевой мистике обычно первый шаг - отключить фаервол. Это неправильно,  
>> но сразу >>становится понятно, кто виноват.
>> До кучи - рабочим и тестовым машинам selinux больше мешает чем  
>> помогает, и там выключить совсем - нормальное >>действие.
>>
>> Из самого банального: ssh, авторизация по ключам, .ssh создан, права  
>> 0700, authorized_keys создан, права 0600, >>все владельцы правильные.  
>> Ключ не принимало, пока не выключили selinux (!). В логах ничего про  
>> то, что >>выполнена блокировка селинухом. Итог: я тоже приучился первым  
>> делом выключать это зло, пока оно не научится >>само и внятно говорить,  
>> что не так.
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --Best regards, Juriy Strashnov
>
> Mob. +7 (953) 742-1550
> E-mail: j.strashnov at me.com
>
> Please consider the environment before printing this email.



-- 
With best regards, Eugene JONIK Peregudov
mailto: eugene.peregudov at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150202/b751fed1/attachment-0001.html>

From gmm at csdoc.com  Mon Feb  2 13:22:38 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Mon, 02 Feb 2015 15:22:38 +0200
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?=
 =?UTF-8?B?bnQgcm9vdA==?=
In-Reply-To: <op.xtfljw0vx116d8@ciu-306-05.corp.nstu.ru>
References: <20150128131729.5e2967d8@gussie>
 <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org>
 <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com>
 <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
 <54CF608B.9000802@webmaster.spb.ru>
 <CAMSCKAiF1Zjsu4gPovXh3VwKrwppm_9wviD1XFn3CUN8WxMXeg@mail.gmail.com>
 <op.xtfljw0vx116d8@ciu-306-05.corp.nstu.ru>
Message-ID: <54CF7A1E.7000900@csdoc.com>

On 02.02.2015 15:10, Eugene Peregudov wrote:

> В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
> запрещающее действие SELinux не пройдет мимо audit.log

Это не совсем так, dontaudit AVC denials не логгируются. Подробнее:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Possible_Causes_of_Silent_Denials.html

> Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
> вырабатывается набор разрешающих правил еще на машине разработчика. На
> этом этапе уже становится ясно в деталях какие дополнительные разрешения
> (с поправкой на пути) необходимо применить администратору при деплое
> приложения.
>
> Напротив, если разработка ведется без включенного селинукс, после деплоя
> начинается многократный рефрен:
> "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
> написание правил\установка правильных меток"
> Причем, делать это приходится администратору порой без знания матчасти
> самого приложения, что добавляет трудностей.

В некоторых/почти всех ситуациях использование OpenVZ дает такую же
или даже еще лучшую изоляцию приложений без подобных танцев с бубном.

Или Docker - там деплой приложения происходит еще проще для сисадминов,
хотя уровень изоляции/надежности там будет меньше чем в случае с OpenVZ.

-- 
Best regards,
  Gena


From chipitsine at gmail.com  Tue Feb  3 02:51:55 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 3 Feb 2015 08:51:55 +0600
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?=
 =?UTF-8?B?bnQgcm9vdA==?=
In-Reply-To: <54CF608B.9000802@webmaster.spb.ru>
References: <20150128131729.5e2967d8@gussie>
 <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org>
 <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com>
 <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
 <54CF608B.9000802@webmaster.spb.ru>
Message-ID: <CAFHpkQHek4LfKomU8PTBhJv8THmrjuKgv-xnnrEcmjhCZ_dJaw@mail.gmail.com>

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

а во всех нормальных случаях - selinux просто мешает жить

2 февраля 2015 г., 16:33 пользователь denis <denis at webmaster.spb.ru> написал:
> 28.01.2015 10:26, Eugene Peregudov пишет:
>>
>>
>> ИМХО, очень зря решается выключением. В первую очередь разработчик
>> приложения и мэйнтейнер должны знать и предоставить информацию о том, какие
>> разрешения необходимы приложению для корректного выполнения, а в идеале еще
>> и написать policy-файл.
>>
>> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh
>> (http://stopdisablingselinux.com/)
>>
> До тех пор, пока оно будет включено по умолчанию - все инструкции будут
> начинаться с "выключите selinux", потому что обычно настройка делается так -
> селинух выкл или в permissive, нормальная настройка всего что запускаем и
> разворачиваем, а потом уже смотрим по результату, какие права нужны.
> Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY", первым
> шагом диагностики всегда будет его отключение. Это как при сетевой мистике
> обычно первый шаг - отключить фаервол. Это неправильно, но сразу становится
> понятно, кто виноват.
> До кучи - рабочим и тестовым машинам selinux больше мешает чем помогает, и
> там выключить совсем - нормальное действие.
>
> Из самого банального: ssh, авторизация по ключам, .ssh создан, права 0700,
> authorized_keys создан, права 0600, все владельцы правильные. Ключ не
> принимало, пока не выключили selinux (!). В логах ничего про то, что
> выполнена блокировка селинухом. Итог: я тоже приучился первым делом
> выключать это зло, пока оно не научится само и внятно говорить, что не так.
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From chipitsine at gmail.com  Tue Feb  3 02:53:30 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 3 Feb 2015 08:53:30 +0600
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?=
 =?UTF-8?B?bnQgcm9vdA==?=
In-Reply-To: <op.xtfljw0vx116d8@ciu-306-05.corp.nstu.ru>
References: <20150128131729.5e2967d8@gussie>
 <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org>
 <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com>
 <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
 <54CF608B.9000802@webmaster.spb.ru>
 <CAMSCKAiF1Zjsu4gPovXh3VwKrwppm_9wviD1XFn3CUN8WxMXeg@mail.gmail.com>
 <op.xtfljw0vx116d8@ciu-306-05.corp.nstu.ru>
Message-ID: <CAFHpkQFRNZr3PBGFcBmp57hZhqH6T4GSsaN723D4W323Um5gBg@mail.gmail.com>

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

2 февраля 2015 г., 18:10 пользователь Eugene Peregudov
<eugene.peregudov at gmail.com> написал:
> Коллега Juriy Strashnov опередил :)
>
> В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
> запрещающее действие SELinux не пройдет мимо audit.log, также можно
> поставить setroubleshoot-server, который будет писать все происходящее в
> messages.
>
> Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
> машинах:
>
> Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
> вырабатывается набор разрешающих правил еще на машине разработчика. На этом
> этапе уже становится ясно в деталях какие дополнительные разрешения (с
> поправкой на пути) необходимо применить администратору при деплое
> приложения.
>
> Напротив, если разработка ведется без включенного селинукс, после деплоя
> начинается многократный рефрен:
> "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
> написание правил\установка правильных меток"
> Причем, делать это приходится администратору порой без знания матчасти
> самого приложения, что добавляет трудностей.
>
> Juriy Strashnov <juriy.foboss at gmail.com> писал(а) в своём письме Mon, 02 Feb
> 2015 18:24:39 +0600:
>
> SELinux умеет объяснять, что делает. Однако получение этой информации
> требует некоторых усилий. Например для вышеописанного случая с блокировкой
> SSH диагностику можно провести так:
>
> grep sshd  /var/log/audit/audit.log | audit2why
>
> Получим сообщение:
>
> type=AVC msg=audit(1382808690.186:75768): avc: denied { read } for pid=26463
> comm="sshd" name="authorized_keys2" dev=dm-0 ino=1441809
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
>
> 2015-02-02 14:33 GMT+03:00 denis <denis at webmaster.spb.ru>:
>>
>> 28.01.2015 10:26, Eugene Peregudov пишет:
>>>
>>>
>>> ИМХО, очень зря решается выключением. В первую очередь разработчик
>>> приложения и мэйнтейнер должны знать и предоставить информацию о том, какие
>>> разрешения необходимы приложению для корректного выполнения, а в идеале еще
>>> и написать policy-файл.
>>>
>>> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh
>>> (http://stopdisablingselinux.com/)
>>>
>> До тех пор, пока оно будет включено по умолчанию - все инструкции будут
>> начинаться с "выключите selinux", потому что обычно настройка делается так -
>> селинух выкл или в permissive, нормальная настройка всего что запускаем и
>> разворачиваем, а потом уже смотрим по результату, какие права нужны.
>> Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY",
>> первым шагом диагностики всегда будет его отключение. Это как при сетевой
>> мистике обычно первый шаг - отключить фаервол. Это неправильно, но сразу
>> становится понятно, кто виноват.
>> До кучи - рабочим и тестовым машинам selinux больше мешает чем помогает, и
>> там выключить совсем - нормальное действие.
>>
>> Из самого банального: ssh, авторизация по ключам, .ssh создан, права 0700,
>> authorized_keys создан, права 0600, все владельцы правильные. Ключ не
>> принимало, пока не выключили selinux (!). В логах ничего про то, что
>> выполнена блокировка селинухом. Итог: я тоже приучился первым делом
>> выключать это зло, пока оно не научится само и внятно говорить, что не так.
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Best regards, Juriy Strashnov
>
> Mob. +7 (953) 742-1550
> E-mail: j.strashnov at me.com
>
> Please consider the environment before printing this email.
>
>
>
>
> --
> With best regards, Eugene JONIK Peregudov
> mailto: eugene.peregudov at gmail.com
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From alex.hha at gmail.com  Tue Feb  3 08:16:10 2015
From: alex.hha at gmail.com (Alex Domoradov)
Date: Tue, 3 Feb 2015 10:16:10 +0200
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?=
 =?UTF-8?B?bnQgcm9vdA==?=
In-Reply-To: <CAFHpkQFRNZr3PBGFcBmp57hZhqH6T4GSsaN723D4W323Um5gBg@mail.gmail.com>
References: <20150128131729.5e2967d8@gussie>
 <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org>
 <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com>
 <op.xs5waubgx116d8@ciu-306-05.corp.nstu.ru>
 <54CF608B.9000802@webmaster.spb.ru>
 <CAMSCKAiF1Zjsu4gPovXh3VwKrwppm_9wviD1XFn3CUN8WxMXeg@mail.gmail.com>
 <op.xtfljw0vx116d8@ciu-306-05.corp.nstu.ru>
 <CAFHpkQFRNZr3PBGFcBmp57hZhqH6T4GSsaN723D4W323Um5gBg@mail.gmail.com>
Message-ID: <CAK90gp4ExDRC0B=B0B430HnWtrgKU=VE0mmGBZrLHcCWh5OZ7g@mail.gmail.com>

> selinux хорошо для "compliance". типа у вас какое-то госучреждение или
типа того, есть политика безопасности, регулярный аудит, и есть
"соответствие требованиям" в
виде включенной галочки selinux
т.е. если ломанут ком-кий проект и уведут у вас базу данных, это нормально?
:) SELinux включают не для галочки, и да конечно же он не гарантирует 100%
безопасности в случае взлома, но он гарантирует, что взломщикам будет на
порядок сложнее получить необходимый результат

> а во всех нормальных случаях - selinux просто мешает жить
вы не любите кошек? Да вы просто не умеете их готовить!

2015-02-03 4:53 GMT+02:00 Илья Шипицин <chipitsine at gmail.com>:

> если вы специально делаете так, что у вас промышленные сервера и
> тестовые настроены по-разному - да, у вас проблема.
>
> 2 февраля 2015 г., 18:10 пользователь Eugene Peregudov
> <eugene.peregudov at gmail.com> написал:
> > Коллега Juriy Strashnov опередил :)
> >
> > В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
> > запрещающее действие SELinux не пройдет мимо audit.log, также можно
> > поставить setroubleshoot-server, который будет писать все происходящее в
> > messages.
> >
> > Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
> > машинах:
> >
> > Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
> > вырабатывается набор разрешающих правил еще на машине разработчика. На
> этом
> > этапе уже становится ясно в деталях какие дополнительные разрешения (с
> > поправкой на пути) необходимо применить администратору при деплое
> > приложения.
> >
> > Напротив, если разработка ведется без включенного селинукс, после деплоя
> > начинается многократный рефрен:
> > "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
> > написание правил\установка правильных меток"
> > Причем, делать это приходится администратору порой без знания матчасти
> > самого приложения, что добавляет трудностей.
> >
> > Juriy Strashnov <juriy.foboss at gmail.com> писал(а) в своём письме Mon,
> 02 Feb
> > 2015 18:24:39 +0600:
> >
> > SELinux умеет объяснять, что делает. Однако получение этой информации
> > требует некоторых усилий. Например для вышеописанного случая с
> блокировкой
> > SSH диагностику можно провести так:
> >
> > grep sshd  /var/log/audit/audit.log | audit2why
> >
> > Получим сообщение:
> >
> > type=AVC msg=audit(1382808690.186:75768): avc: denied { read } for
> pid=26463
> > comm="sshd" name="authorized_keys2" dev=dm-0 ino=1441809
> > scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> > tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
> >
> > 2015-02-02 14:33 GMT+03:00 denis <denis at webmaster.spb.ru>:
> >>
> >> 28.01.2015 10:26, Eugene Peregudov пишет:
> >>>
> >>>
> >>> ИМХО, очень зря решается выключением. В первую очередь разработчик
> >>> приложения и мэйнтейнер должны знать и предоставить информацию о том,
> какие
> >>> разрешения необходимы приложению для корректного выполнения, а в
> идеале еще
> >>> и написать policy-файл.
> >>>
> >>> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh
> >>> (http://stopdisablingselinux.com/)
> >>>
> >> До тех пор, пока оно будет включено по умолчанию - все инструкции будут
> >> начинаться с "выключите selinux", потому что обычно настройка делается
> так -
> >> селинух выкл или в permissive, нормальная настройка всего что запускаем
> и
> >> разворачиваем, а потом уже смотрим по результату, какие права нужны.
> >> Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY",
> >> первым шагом диагностики всегда будет его отключение. Это как при
> сетевой
> >> мистике обычно первый шаг - отключить фаервол. Это неправильно, но сразу
> >> становится понятно, кто виноват.
> >> До кучи - рабочим и тестовым машинам selinux больше мешает чем
> помогает, и
> >> там выключить совсем - нормальное действие.
> >>
> >> Из самого банального: ssh, авторизация по ключам, .ssh создан, права
> 0700,
> >> authorized_keys создан, права 0600, все владельцы правильные. Ключ не
> >> принимало, пока не выключили selinux (!). В логах ничего про то, что
> >> выполнена блокировка селинухом. Итог: я тоже приучился первым делом
> >> выключать это зло, пока оно не научится само и внятно говорить, что не
> так.
> >>
> >>
> >> _______________________________________________
> >> nginx-ru mailing list
> >> nginx-ru at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> >
> > --
> > Best regards, Juriy Strashnov
> >
> > Mob. +7 (953) 742-1550
> > E-mail: j.strashnov at me.com
> >
> > Please consider the environment before printing this email.
> >
> >
> >
> >
> > --
> > With best regards, Eugene JONIK Peregudov
> > mailto: eugene.peregudov at gmail.com
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150203/c6303a79/attachment-0001.html>

From swood at fotofor.biz  Wed Feb  4 21:16:14 2015
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Thu, 5 Feb 2015 01:16:14 +0400
Subject: proxy_pass on https
Message-ID: <CAM_jxg1ivWWmG5Jit8JJK83OzyTSMEGgYzvNy7tFbQSad6BrDA@mail.gmail.com>

Здравствуйте.

Расскажите, пожалуйста, почему в случае, если я делаю proxy_pass на http
хост, то keepalive работает. А если на https, то нет.
Если что, то настройки location у меня такие:

        location / {
                proxy_pass https://backend;
                proxy_http_version 1.1;
                proxy_ssl_session_reuse on;
                proxy_buffering on;
                proxy_set_header X_FORWARDED_PROTO https;
                proxy_ssl_verify off;
                proxy_set_header Connection "";
                proxy_set_header Host $host;
                proxy_pass_request_headers on;
        }

upstream mrg {
        server ip:443;
        keepalive 600;
}



-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150205/e66164e7/attachment.html>

From swood at fotofor.biz  Wed Feb  4 21:16:57 2015
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Thu, 5 Feb 2015 01:16:57 +0400
Subject: proxy_pass on https
In-Reply-To: <CAM_jxg1ivWWmG5Jit8JJK83OzyTSMEGgYzvNy7tFbQSad6BrDA@mail.gmail.com>
References: <CAM_jxg1ivWWmG5Jit8JJK83OzyTSMEGgYzvNy7tFbQSad6BrDA@mail.gmail.com>
Message-ID: <CAM_jxg34GLobGk4ET+6Hgd=5-CcNQOWSfsfMRCJayCKtKDDsWQ@mail.gmail.com>

 Да, upstream называется backend, все же.

5 февраля 2015 г., 0:16 пользователь Anton Kiryushkin <swood at fotofor.biz>
написал:

> Здравствуйте.
>
> Расскажите, пожалуйста, почему в случае, если я делаю proxy_pass на http
> хост, то keepalive работает. А если на https, то нет.
> Если что, то настройки location у меня такие:
>
>         location / {
>                 proxy_pass https://backend;
>                 proxy_http_version 1.1;
>                 proxy_ssl_session_reuse on;
>                 proxy_buffering on;
>                 proxy_set_header X_FORWARDED_PROTO https;
>                 proxy_ssl_verify off;
>                 proxy_set_header Connection "";
>                 proxy_set_header Host $host;
>                 proxy_pass_request_headers on;
>         }
>
> upstream mrg {
>         server ip:443;
>         keepalive 600;
> }
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>
>



-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150205/56dc2394/attachment.html>

From mdounin at mdounin.ru  Thu Feb  5 12:43:11 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 5 Feb 2015 15:43:11 +0300
Subject: proxy_pass on https
In-Reply-To: <CAM_jxg1ivWWmG5Jit8JJK83OzyTSMEGgYzvNy7tFbQSad6BrDA@mail.gmail.com>
References: <CAM_jxg1ivWWmG5Jit8JJK83OzyTSMEGgYzvNy7tFbQSad6BrDA@mail.gmail.com>
Message-ID: <20150205124311.GC99511@mdounin.ru>

Hello!

On Thu, Feb 05, 2015 at 01:16:14AM +0400, Anton Kiryushkin wrote:

> Расскажите, пожалуйста, почему в случае, если я делаю proxy_pass на http
> хост, то keepalive работает. А если на https, то нет.
> Если что, то настройки location у меня такие:

Я бы для начала посмотрел, поддерживает ли keepalive ваш 
https-бекенд.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Thu Feb  5 20:52:36 2015
From: nginx-forum at nginx.us (Forst)
Date: Thu, 05 Feb 2015 15:52:36 -0500
Subject: ssl_crl 3:unable to get certificate CRL
In-Reply-To: <CAH05gjbtCHQkNCSpZQakC0bRFi2UaU=w_RjzGGdpfeFUVytf9w@mail.gmail.com>
References: <CAH05gjbtCHQkNCSpZQakC0bRFi2UaU=w_RjzGGdpfeFUVytf9w@mail.gmail.com>
Message-ID: <6c813a338010ae86619b2abea37e6275.NginxMailingListRussian@forum.nginx.org>

Извините, что поднимаю мёртвую тему, но возникла та же проблема, что и у
топикстартера. CRL прописал и в сертификате, и вручную в конфиге. Однако,
ошибка 3.

Конфиг:

> ssl_certificate /etc/nginx/ssl/server.crt;
> ssl_certificate_key /etc/nginx/ssl/server.key;
> ssl_client_certificate /etc/ssl/forstwoof/client.crt;
> ssl_crl /etc/ssl/forstwoof/client.crl;
> ssl_verify_client on;

В клиентском сертификате:
> X509v3 CRL Distribution Points: 
>   Full Name:
>     URI:http://forstwoof.ru/ca/client.crl

Все файлы по путям доступны, как и по URI. Для меня это тупик, не понимаю, в
чём дело.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,217672,256484#msg-256484


From eudovihin at gmail.com  Sat Feb  7 06:25:05 2015
From: eudovihin at gmail.com (=?KOI8-R?B?5dfHxc7JyiD1xM/XycjJzg==?=)
Date: Sat, 7 Feb 2015 16:25:05 +1000
Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDINC60LXRiCBuZ2lueCDRgdC+0LfQtNCw0LXRgiDQt9Cw0LQ=?=
 =?UTF-8?B?0LXRgNC20LrQuD8=?=
Message-ID: <CAJh8W=gJh8pMmxBN+4W4UNRUcEij5-x0x7PZH0Er=5VZrYoPOA@mail.gmail.com>

Один php скрипт занимается раздачей статистики с сайта в двух видах.
Кешируется по сути один файл на секунду (так надо). При этом есть два типа
запросов, и кеш настроен их различать. Для первого типа всегда отдается
бекендом с заголовком header("X-Accel-Expires: 0"); а для второго
header("X-Accel-Expires: 1"); Все работает. Запросы первого типа не
кешируются вообще, запросы второго типа кешируются на секунду. В кеше 1
файл как раз второго типа.

А теперь вопрос - почему кеш nginx может создавать задержки. Т.е. вот идут
запросы нормально, время ответа 150мс, и тут вдруг внезапно задержка - от
2с до 20с, бывало. При этом другие запросы к серверу идут как обычно по
расписанию (раз в 2 секунды). Более того, зависший запрос может так и
висеть, когда следующие за ним уже отправились и выполнились. Бывало
выполнялось по 10 следующих запросов за те 20 секунд зависания. И
естественно данные приходили в развисшем запросе устаревшие. Не могу понять
почему такое может быть ...

Параметры кеширования nginx

proxy_cache_path /tmp/site levels= keys_zone=pagecache:1m
max_size=1m;proxy_cache             pagecache;proxy_cache_valid
200 1s;proxy_cache_lock on;proxy_cache_lock_timeout
100s;proxy_cache_use_stale  updating;proxy_ignore_headers Expires
Cache-Control;if ($arg_callback) {
  set $callback callback;
}proxy_cache_key
$scheme$proxy_host$uri$arg_widget$arg_layer$callback;proxy_pass_header
"X-Accel-Expires";sub_filter 'callback' $arg_callback;



Контроль и замена callback - это для jQuery ajax'а фикс, можете не обращать
внимания. Стоит cache_lock + proxy_cache_use_stale updating, т.е. при
ожидании обновления кеша должны отдаваться старые данные. Все так и
происходит во задержек проблем на сервере, проблема явно не тут. Тем более
что последующие за зависшим вопросы проходят нормально, а зависший все еще
висит, явно не ожидание обновления кеша.

Сам ответ на бекенде генерируется в пределах 30мс, проверял по mircotime()
php.

Запросы, которые не попадают в location с кешированием, тоже иногдла
заредживаются, но на пару секунд максимум. Число worker стоит auto, сервер
мощный и не перегружен.

В кеше 1 файл, не думаю что проблема в задержка HDD. Т.е. прям реально в
папке /tmp/site всего 1 файл с кешем. Плюс к тому зависают не только
вопросы из кешируемой группы, но и запросы из некешируемой тоже. Хотя они
всегда должны сразу уходить на бекенд и возвращаться с ответом.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150207/a6d518d6/attachment.html>

From nginx-forum at nginx.us  Tue Feb 10 07:47:32 2015
From: nginx-forum at nginx.us (Maximus43)
Date: Tue, 10 Feb 2015 02:47:32 -0500
Subject: =?UTF-8?B?JHNlcnZlciBwcm90b2NvbCDQv9C+0L/QsNC00LDQtdGCINCyIGxvY2F0aW9uLCA=?=
 =?UTF-8?B?0L/QvtGH0LXQvNGDINGC0LDQuj8=?=
Message-ID: <081d0f98530807a57a7e95e53460cdf7.NginxMailingListRussian@forum.nginx.org>

Насколько я помню, раньше все работало, а сейчас наткнулся на проблему,
которую сходу решить не смог.

Имеется location ~ '^/(?<lang_code>[\D-]{2})/(?<rest_uri>.*)'

В конце прописан алиас:

 alias /var/www/infoss/$lang_code/vpnbox/$rest_uri;

Цель, чтобы запрос http://box.infoss.no/no/index.html брал данные из 
/var/www/infoss/no/vpnbox/index.html 

Но в итоге я получаю ошибку:

2015/02/10 07:33:41 [error] 7046#0: *283439
"/var/www/infoss/no/vpnbox/HTTP/1.1index.html" is not found (2: No such file
or directory), client: 84.208.48.150, server: box.info, request: "GET /no/
HTTP/1.1", host: "box.infoss.no"

Почему-то HTTP/1.1 попадает в локейшен, а далее в переменную $rest_uri

Куда копать?

Заранее спасибо!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256531,256531#msg-256531


From vadim.lazovskiy at gmail.com  Tue Feb 10 08:13:45 2015
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Tue, 10 Feb 2015 11:13:45 +0300
Subject: =?UTF-8?B?UmU6ICRzZXJ2ZXIgcHJvdG9jb2wg0L/QvtC/0LDQtNCw0LXRgiDQsiBsb2NhdGlv?=
 =?UTF-8?B?biwg0L/QvtGH0LXQvNGDINGC0LDQuj8=?=
In-Reply-To: <081d0f98530807a57a7e95e53460cdf7.NginxMailingListRussian@forum.nginx.org>
References: <081d0f98530807a57a7e95e53460cdf7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAL-L5YA4tEMCqnr6C1Jp2F2qWC2eJXPQomyV9K-DV3=tgLTisw@mail.gmail.com>

Здравствуйте.

Версия nginx какая?
И, если можно, конфиг location полностью.

Есть мнение, что версия < 1.7.1:

    *) Bugfix: the "alias" directive used inside a location given by a
       regular expression worked incorrectly if the "if" or "limit_except"
       directives were used.


10 февраля 2015 г., 10:47 пользователь Maximus43 <nginx-forum at nginx.us> написал:
> Насколько я помню, раньше все работало, а сейчас наткнулся на проблему,
> которую сходу решить не смог.
>
> Имеется location ~ '^/(?<lang_code>[\D-]{2})/(?<rest_uri>.*)'
>
> В конце прописан алиас:
>
>  alias /var/www/infoss/$lang_code/vpnbox/$rest_uri;
>
> Цель, чтобы запрос http://box.infoss.no/no/index.html брал данные из
> /var/www/infoss/no/vpnbox/index.html
>
> Но в итоге я получаю ошибку:
>
> 2015/02/10 07:33:41 [error] 7046#0: *283439
> "/var/www/infoss/no/vpnbox/HTTP/1.1index.html" is not found (2: No such file
> or directory), client: 84.208.48.150, server: box.info, request: "GET /no/
> HTTP/1.1", host: "box.infoss.no"
>
> Почему-то HTTP/1.1 попадает в локейшен, а далее в переменную $rest_uri
>
> Куда копать?
>
> Заранее спасибо!
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256531,256531#msg-256531
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
WBR,
Vadim Lazovskiy

From nginx-forum at nginx.us  Tue Feb 10 09:57:44 2015
From: nginx-forum at nginx.us (Maximus43)
Date: Tue, 10 Feb 2015 04:57:44 -0500
Subject: =?UTF-8?B?UmU6ICRzZXJ2ZXIgcHJvdG9jb2wg0L/QvtC/0LDQtNCw0LXRgiDQsiBsb2NhdGlv?=
 =?UTF-8?B?biwg0L/QvtGH0LXQvNGDINGC0LDQuj8=?=
In-Reply-To: <CAL-L5YA4tEMCqnr6C1Jp2F2qWC2eJXPQomyV9K-DV3=tgLTisw@mail.gmail.com>
References: <CAL-L5YA4tEMCqnr6C1Jp2F2qWC2eJXPQomyV9K-DV3=tgLTisw@mail.gmail.com>
Message-ID: <8700ad8cb97395e36975191aebaeac25.NginxMailingListRussian@forum.nginx.org>

Да, похоже на указанный баг.

nginx version: nginx/1.6.2

В продакшене только стабильные версии.

Вот локейшен

location ~ '^/(?<lang_code>[\D-]{2})/(?<rest_uri>.*)' {

                # Redirect to Russian for some CIS countries
                        if ($lang_code ~* (uk|be|kk)) {
                                return 301
https://$host/ru/$rest_uri$is_args$args;
                                }
                # Redirect to Norwegian for Nordic countries
                        if ($lang_code ~* (sv|da)) {
                                return 301
https://$host/no/$rest_uri$is_args$args;
                              }

                # Redirect to English for unknown languages
                        if ($lang_code !~* (en|no|ru)) {
                                return 301
https://$host/en/$rest_uri$is_args$args;
                                }

                        if ($args ~ (.*)locale=[^&]*(.*)) {
                                set $args $1$2;
                                }
                # cleanup any repeated & introduced
                        if ($args ~ (.*)&&+(.*)) {
                                set $args $1&$2;
                                }
                # cleanup leading &
                        if ($args ~ ^&(.*)) {
                                set $args $1;
                                }
                # cleanup ending &
                        if ($args ~ (.*)&$) {
                                set $args $1;
                                }

        if ($cookie_lang = "") {
                add_header Set-Cookie
'lang=$lang_code;Domain=.infoss.no;Path=/;Max-Age=315360';
             }
        if ($cookie_lang !~ $lang_code) {
                add_header Set-Cookie
'lang=$lang_code;Domain=.infoss.no;Path=/;Max-Age=315360';
             }
              alias
/var/www/infoss/$lang_code/vpnbox/$rest_uri$is_args$args;
              index index.html;
        }

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256532,256536#msg-256536


From sytar.alex at gmail.com  Tue Feb 10 10:07:04 2015
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Tue, 10 Feb 2015 14:07:04 +0400
Subject: SPDY
Message-ID: <CAKqRTSFiNm7=GcT2G2gppGa2os7pJqzSMGTZU78fRXxGPnD95Q@mail.gmail.com>

В свете [1] хотелось бы узнать каковы шансы на появление в nginx поддержки
HTTP/2

1 - http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150210/e88e3a6c/attachment.html>

From mdounin at mdounin.ru  Tue Feb 10 15:02:55 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 10 Feb 2015 18:02:55 +0300
Subject: nginx-1.7.10
Message-ID: <20150210150255.GG19012@mdounin.ru>

Изменения в nginx 1.7.10                                          10.02.2015

    *) Добавление: параметр use_temp_path директив proxy_cache_path,
       fastcgi_cache_path, scgi_cache_path и uwsgi_cache_path.

    *) Добавление: переменная $upstream_header_time.

    *) Изменение: теперь при переполнении диска nginx пытается писать
       error_log'и только раз в секунду.

    *) Исправление: директива try_files при тестировании каталогов не
       игнорировала обычные файлы.
       Спасибо Damien Tournoud.

    *) Исправление: при использовании директивы sendfile на OS X возникали
       ошибки "sendfile() failed"; ошибка появилась в nginx 1.7.8.

    *) Исправление: в лог могли писаться сообщения "sem_post() failed".

    *) Исправление: nginx не собирался с musl libc.
       Спасибо James Taylor.

    *) Исправление: nginx не собирался на Tru64 UNIX.
       Спасибо Goetz T. Fischer.


-- 
Maxim Dounin
http://nginx.org/en/donation.html


From nginx-forum at nginx.us  Wed Feb 11 06:02:38 2015
From: nginx-forum at nginx.us (smartlight)
Date: Wed, 11 Feb 2015 01:02:38 -0500
Subject: =?UTF-8?B?cmV0dXJuIDMwMSAg0L3QtSDQvtCx0YDQsNCx0LDRgtGL0LLQsNC10YLRgdGPINCy?=
 =?UTF-8?B?IGxvY2F0aW9uICBhbGxvdyBJUCtkZW55IGFsbA==?=
Message-ID: <cd31d13d1039559ec84bbfe8b6e8d981.NginxMailingListRussian@forum.nginx.org>

Доброго дня.
Имеется задание для одного location разрешить редирект для white list и
запретить доступ всем остальным.
Реализовано это так:
   location / {
      proxy_pass          http://web_upstream;
      return 301 https://example.com;
      allow 1.1.1.1;
      allow 2.2.2.2
      deny all;
    }

Работает это так, что с любого IP идёт редирект на  https://example.com

Что сделано не так?
Буду признателен за любую помощь.
Спасибо за внимание.

PS
FreeBSD 9.1-RELEASE-p4 
nginx -V
nginx version: nginx/1.4.6
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx-error.log --user=www --group=www
--with-debug --with-ipv6
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx-access.log --with-http_addition_module
--without-http-cache --with-http_geoip_module --with-http_realip_module
--with-http_stub_status_module --with-http_sub_module --with-pcre
--add-module=/usr/ports/www/nginx/work/gabor-nginx-x-rid-header-0daa3cc
--with-http_ssl_module

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256564,256564#msg-256564


From nginx-forum at nginx.us  Wed Feb 11 07:11:10 2015
From: nginx-forum at nginx.us (igor.goncharenko)
Date: Wed, 11 Feb 2015 02:11:10 -0500
Subject: =?UTF-8?B?UmU6IHJldHVybiAzMDEg0L3QtSDQvtCx0YDQsNCx0LDRgtGL0LLQsNC10YLRgdGP?=
 =?UTF-8?B?INCyIGxvY2F0aW9uIGFsbG93IElQK2RlbnkgYWxs?=
In-Reply-To: <cd31d13d1039559ec84bbfe8b6e8d981.NginxMailingListRussian@forum.nginx.org>
References: <cd31d13d1039559ec84bbfe8b6e8d981.NginxMailingListRussian@forum.nginx.org>
Message-ID: <66b6b744879587471b9c7164acf2cb69.NginxMailingListRussian@forum.nginx.org>

Вот целый большой тред о вопросе
http://forum.nginx.org/read.php?21,243708,243708#msg-243708

Пользуйтесь поиском называется...

---
Igor

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256564,256566#msg-256566


From nginx-forum at nginx.us  Wed Feb 11 08:13:24 2015
From: nginx-forum at nginx.us (smartlight)
Date: Wed, 11 Feb 2015 03:13:24 -0500
Subject: =?UTF-8?B?UmU6IHJldHVybiAzMDEg0L3QtSDQvtCx0YDQsNCx0LDRgtGL0LLQsNC10YLRgdGP?=
 =?UTF-8?B?INCyIGxvY2F0aW9uIGFsbG93IElQK2RlbnkgYWxs?=
In-Reply-To: <66b6b744879587471b9c7164acf2cb69.NginxMailingListRussian@forum.nginx.org>
References: <cd31d13d1039559ec84bbfe8b6e8d981.NginxMailingListRussian@forum.nginx.org>
 <66b6b744879587471b9c7164acf2cb69.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5b6dab1cf2eda70e327d95dba8534b24.NginxMailingListRussian@forum.nginx.org>

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

решили сделать так:

   geo $forbiden_nets {

     default 0;
        1.1.1.0/24 1;
        2.2.2.2/32 1;
   }

   location /
    {
        if ( $forbiden_nets = 0 ) { 
                error_page 403  /en/403.html;
                return 403; 
                }
        return 301  https://example.com;
        proxy_pass http://web_upstream;
    }

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256564,256567#msg-256567


From megalin2 at gmail.com  Wed Feb 11 12:02:31 2015
From: megalin2 at gmail.com (=?KOI8-R?B?7snLydTBIOvB0sTB28nO?=)
Date: Wed, 11 Feb 2015 18:02:31 +0600
Subject: =?UTF-8?B?0J/RgNC+0LHQuNGC0LjQtSDQtNC+0YDQvtCz0Lgg0Log0LDQv9GB0YLRgNC40Lw=?=
 =?UTF-8?B?0YMg0YfQtdGA0LXQtyBodHRwIHByb3h5?=
Message-ID: <CALA_TQgoh_XV3pWkj=rfoM22oLSpK1ERs4ckpatprcPntHGuzQ@mail.gmail.com>

Добрый день,

Возникла необходимость для определенных location-ов прокладывать маршрут до
upstream-a через промежуточный HTTP Proxy (Squid в моем случае). Нужно это
для интеграции существующей системы с Kaspersky Antivirus for Proxies
(который работает по ICAP, т.е. только со сквидом).

Я вижу очевидное решение (настроить squid в качестве reverse proxy для тех
же самых апстримов и просто обращаться к нему, как к обычному
HTTP-серверу), но мне оно не нравится - придется поддерживать актуальный
список апстримов в двух местах (nginx и squid), плюс, сквид менее умный в
части выбора наиболее "хорошего" апстрима для запроса.

Вопрос. Можно ли заставить nginx ходить к апстриму *через* http proxy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150211/ba469ec7/attachment.html>

From onokonem at gmail.com  Wed Feb 11 12:08:46 2015
From: onokonem at gmail.com (Daniel Podolsky)
Date: Wed, 11 Feb 2015 16:08:46 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LjRgtC40LUg0LTQvtGA0L7Qs9C4INC6INCw0L/RgdGC0YA=?=
 =?UTF-8?B?0LjQvNGDINGH0LXRgNC10LcgaHR0cCBwcm94eQ==?=
In-Reply-To: <CALA_TQgoh_XV3pWkj=rfoM22oLSpK1ERs4ckpatprcPntHGuzQ@mail.gmail.com>
References: <CALA_TQgoh_XV3pWkj=rfoM22oLSpK1ERs4ckpatprcPntHGuzQ@mail.gmail.com>
Message-ID: <CAKaHDOERjRzBSj1YLbh1EJ9rnoFuL-S0rS4vPhyr-bScP6CSsg@mail.gmail.com>

> Можно ли заставить nginx ходить к апстриму через http proxy?
а почему нельзя указать squid как upstream?

или вы думаете, что там есть какая-то прокси-магия? так ее там нет :)

точно так же squid смотрит на заголовок Host и заголовки get/post/etc

From megalin2 at gmail.com  Wed Feb 11 12:15:48 2015
From: megalin2 at gmail.com (=?KOI8-R?B?7snLydTBIOvB0sTB28nO?=)
Date: Wed, 11 Feb 2015 18:15:48 +0600
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LjRgtC40LUg0LTQvtGA0L7Qs9C4INC6INCw0L/RgdGC0YA=?=
 =?UTF-8?B?0LjQvNGDINGH0LXRgNC10LcgaHR0cCBwcm94eQ==?=
In-Reply-To: <CAKaHDOERjRzBSj1YLbh1EJ9rnoFuL-S0rS4vPhyr-bScP6CSsg@mail.gmail.com>
References: <CALA_TQgoh_XV3pWkj=rfoM22oLSpK1ERs4ckpatprcPntHGuzQ@mail.gmail.com>
 <CAKaHDOERjRzBSj1YLbh1EJ9rnoFuL-S0rS4vPhyr-bScP6CSsg@mail.gmail.com>
Message-ID: <CALA_TQjsc3tGhFYgZxeCHiMPjbr2PfX5decwNL4MYWQ0a8pTow@mail.gmail.com>

У меня есть, например, такая штука:

upstream lk0 {
        server 192.168.242.45:8080    max_fails=1 fail_timeout=30s;
        server 192.168.242.46:8080    max_fails=1 fail_timeout=30s;
        server 192.168.242.68:8080    max_fails=1 fail_timeout=30s;
}

location / {
                proxy_pass http://lk0/;
}

В этой схеме nginx управляет тем, на какой апстрим ему идти, определяет их
доступность и т.д.
Если вместо трех апстримов указать один сквид и подменять заголовок Host на
требуемый апстрим - все скорее всего будет работать, но не будет
раунд-робина и автофейла, так?

11 февраля 2015 г., 17:08 пользователь Daniel Podolsky <onokonem at gmail.com>
написал:

> > Можно ли заставить nginx ходить к апстриму через http proxy?
> а почему нельзя указать squid как upstream?
>
> или вы думаете, что там есть какая-то прокси-магия? так ее там нет :)
>
> точно так же squid смотрит на заголовок Host и заголовки get/post/etc
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
With best regards,
differentlocal (www.differentlocal.ru | differentlocal at gmail.com),
System administrator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150211/bd24d43e/attachment.html>

From onokonem at gmail.com  Wed Feb 11 12:41:32 2015
From: onokonem at gmail.com (Daniel Podolsky)
Date: Wed, 11 Feb 2015 16:41:32 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LjRgtC40LUg0LTQvtGA0L7Qs9C4INC6INCw0L/RgdGC0YA=?=
 =?UTF-8?B?0LjQvNGDINGH0LXRgNC10LcgaHR0cCBwcm94eQ==?=
In-Reply-To: <CALA_TQjsc3tGhFYgZxeCHiMPjbr2PfX5decwNL4MYWQ0a8pTow@mail.gmail.com>
References: <CALA_TQgoh_XV3pWkj=rfoM22oLSpK1ERs4ckpatprcPntHGuzQ@mail.gmail.com>
 <CAKaHDOERjRzBSj1YLbh1EJ9rnoFuL-S0rS4vPhyr-bScP6CSsg@mail.gmail.com>
 <CALA_TQjsc3tGhFYgZxeCHiMPjbr2PfX5decwNL4MYWQ0a8pTow@mail.gmail.com>
Message-ID: <CAKaHDOEAGpycYMOAa7VsdP=49tEk+o4BrVe_LCJZb9JQxzRNrA@mail.gmail.com>

2015-02-11 15:15 GMT+03:00 Никита Кардашин <megalin2 at gmail.com>:
> все скорее всего будет работать, но не будет раунд-робина и автофейла, так?
то есть - вы хотите в http запрос к апстриму-сквиду вложить указание
на то, каким апстримом он должен воспользоваться?

нет, такой прокси-магии тоже не бывает

(на самом деле - бывает, но она требует поддержания актуальности
списка апстримов в двух местах минимум)

можно после сквида поставить опять nginx, и сделать магию на нем.
можно даже завернуть трафик обратно на тот ваш первый nginx, на другой
порт :)

From nginx-forum at nginx.us  Thu Feb 12 00:39:33 2015
From: nginx-forum at nginx.us (maximovru)
Date: Wed, 11 Feb 2015 19:39:33 -0500
Subject: =?UTF-8?B?0JTQstC1INGA0LDQt9C90YvRhSDRgNCw0LHQvtGH0LjRhSDQtNC40YDQtdC60YI=?=
 =?UTF-8?B?0L7RgNC40LggYyBwaHAtZnBt?=
Message-ID: <3a8a8338607ae2321fcd09ac3f598ff1.NginxMailingListRussian@forum.nginx.org>

Здравствуйте! Хочу настроить на одном домене Yii и вордпресс.
имеется следующий конфиг nginx:
http://pastebin.com/xmicMwYZ
хочется добиться эффекта чтобы для всех урлов начинающихся с /blog/
ставился обработчик php fpm и файлы обрабатывались из директории:
/srv/blog/wordpress
а для остального из директории: /srv/dev/frontend/www
при этом эффект достигнут, кроме случаев: /blog/ и /blog/index.php - тут
nginx выдает на скачивание(без обработки php-fpm) файл
/srv/dev/frontend/www/index.php
а для /blog/?abc и /blog/index.php?abc и /blog/index1.php - все отрабатывает
как и задумывалось
версия nginx/1.6.2

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256604,256604#msg-256604


From anatoly at sonru.com  Thu Feb 12 11:21:59 2015
From: anatoly at sonru.com (Anatoly Mikhaylov)
Date: Thu, 12 Feb 2015 11:21:59 +0000
Subject: SPDY
In-Reply-To: <CAKqRTSFiNm7=GcT2G2gppGa2os7pJqzSMGTZU78fRXxGPnD95Q@mail.gmail.com>
References: <CAKqRTSFiNm7=GcT2G2gppGa2os7pJqzSMGTZU78fRXxGPnD95Q@mail.gmail.com>
Message-ID: <0B77FD0A-4EC1-4AAB-B0D8-957CF215742F@sonru.com>

да, очень интересная тема, но спецификации то еще нет 
http://www.chromium.org/spdy/spdy-protocol <http://www.chromium.org/spdy/spdy-protocol> на основе чего имплементировать?


> On Feb 10, 2015, at 10:07 AM, Aleksandr Sytar <sytar.alex at gmail.com> wrote:
> 
> В свете [1] хотелось бы узнать каковы шансы на появление в nginx поддержки HTTP/2
> 
> 1 - http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html <http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html>_______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150212/f6c1a097/attachment.html>

From sytar.alex at gmail.com  Thu Feb 12 11:26:06 2015
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Thu, 12 Feb 2015 15:26:06 +0400
Subject: SPDY
In-Reply-To: <0B77FD0A-4EC1-4AAB-B0D8-957CF215742F@sonru.com>
References: <CAKqRTSFiNm7=GcT2G2gppGa2os7pJqzSMGTZU78fRXxGPnD95Q@mail.gmail.com>
 <0B77FD0A-4EC1-4AAB-B0D8-957CF215742F@sonru.com>
Message-ID: <CAKqRTSEcF2A6EUYwgHze_YETbiRc7qsTaNkyE+A5=-hbccSjwQ@mail.gmail.com>

12 февраля 2015 г., 14:21 пользователь Anatoly Mikhaylov <anatoly at sonru.com>
написал:

> да, очень интересная тема, но спецификации то еще нет
> http://www.chromium.org/spdy/spdy-protocol на основе чего
> имплементировать?
>

А это тогда что? - https://tools.ietf.org/html/draft-ietf-httpbis-http2-16


>
>
> On Feb 10, 2015, at 10:07 AM, Aleksandr Sytar <sytar.alex at gmail.com>
> wrote:
>
> В свете [1] хотелось бы узнать каковы шансы на появление в nginx поддержки
> HTTP/2
>
> 1 -
> http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150212/84750506/attachment-0001.html>

From nginx-forum at nginx.us  Fri Feb 13 07:28:08 2015
From: nginx-forum at nginx.us (maximovru)
Date: Fri, 13 Feb 2015 02:28:08 -0500
Subject: =?UTF-8?B?UmU6INCU0LLQtSDRgNCw0LfQvdGL0YUg0YDQsNCx0L7Rh9C40YUg0LTQuNGA0LU=?=
 =?UTF-8?B?0LrRgtC+0YDQuNC4IGMgcGhwLWZwbQ==?=
In-Reply-To: <3a8a8338607ae2321fcd09ac3f598ff1.NginxMailingListRussian@forum.nginx.org>
References: <3a8a8338607ae2321fcd09ac3f598ff1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <50375214d935e5912524b37bd51ade91.NginxMailingListRussian@forum.nginx.org>

Оказалось у меня браузер закешировал ответ на /blog/ когда было не все
хорошо. В общем конфиг рабочие если кому-то подобное надо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256604,256641#msg-256641


From nginx-forum at nginx.us  Fri Feb 13 07:33:34 2015
From: nginx-forum at nginx.us (maximovru)
Date: Fri, 13 Feb 2015 02:33:34 -0500
Subject: =?UTF-8?B?UmU6INCU0LLQtSDRgNCw0LfQvdGL0YUg0YDQsNCx0L7Rh9C40YUg0LTQuNGA0LU=?=
 =?UTF-8?B?0LrRgtC+0YDQuNC4IGMgcGhwLWZwbQ==?=
In-Reply-To: <3a8a8338607ae2321fcd09ac3f598ff1.NginxMailingListRussian@forum.nginx.org>
References: <3a8a8338607ae2321fcd09ac3f598ff1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <d038f85a641e4d6b15e3b498196976f1.NginxMailingListRussian@forum.nginx.org>

когда старая ссылка конфига перестанет быть действительна, то вот эта должна
работать: http://pastebin.com/pHCM3mBT

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256604,256642#msg-256642


From nginx-forum at nginx.us  Fri Feb 13 12:44:42 2015
From: nginx-forum at nginx.us (zdm)
Date: Fri, 13 Feb 2015 07:44:42 -0500
Subject: =?UTF-8?B?0KHQsdC+0YDQutCwINGBIFBDUkUyLTEwLjAwID8=?=
Message-ID: <21d270b093bb2ff2809b06c82cb5b443.NginxMailingListRussian@forum.nginx.org>

Как собрать из исходников с PCRE2-10.00 вместо 8.36?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256646,256646#msg-256646


From mdounin at mdounin.ru  Fri Feb 13 13:06:07 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 13 Feb 2015 16:06:07 +0300
Subject: =?UTF-8?B?UmU6INCh0LHQvtGA0LrQsCDRgSBQQ1JFMi0xMC4wMCA/?=
In-Reply-To: <21d270b093bb2ff2809b06c82cb5b443.NginxMailingListRussian@forum.nginx.org>
References: <21d270b093bb2ff2809b06c82cb5b443.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150213130607.GC19012@mdounin.ru>

Hello!

On Fri, Feb 13, 2015 at 07:44:42AM -0500, zdm wrote:

> Как собрать из исходников с PCRE2-10.00 вместо 8.36?

Никак, PCRE2 - другая библиотека, не совместимая с PCRE.  Работать 
с ней nginx не умеет.  Собственно, с ней пока даже exim работать 
не умеет, что уж говорить про всех остальных.

-- 
Maxim Dounin
http://nginx.org/


From citrin at citrin.ru  Fri Feb 13 15:22:48 2015
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Fri, 13 Feb 2015 18:22:48 +0300
Subject: =?UTF-8?B?0YHRgtGA0LDQvdC90L7RgdGC0Ywg0YEgc3NsX3Nlc3Npb25fY2FjaGUgb2Zm?=
Message-ID: <54DE16C8.5010805@citrin.ru>

В конфиге на уровне http написано

ssl_session_cache off;

при этом в логах пишется $ssl_session_reused=r

openssl s_client
показвыет
Session-ID: 4A2293CB....

Хотя по документации при off:
the use of a session cache is strictly prohibited: nginx explicitly tells a 
client that sessions may not be reused.

nginx 1.7.10
openssl 1.0.1k


From citrin at citrin.ru  Fri Feb 13 15:34:42 2015
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Fri, 13 Feb 2015 18:34:42 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0YHRgtGMINGBIHNzbF9zZXNzaW9uX2NhY2hlIG9m?=
 =?UTF-8?B?Zg==?=
In-Reply-To: <54DE16C8.5010805@citrin.ru>
References: <54DE16C8.5010805@citrin.ru>
Message-ID: <54DE1992.3040207@citrin.ru>

On 02/13/15 18:22, Anton Yuzhaninov wrote:
>
> ssl_session_cache off;
>
> при этом в логах пишется $ssl_session_reused=r
>
> openssl s_client
> показвыет
> Session-ID: 4A2293CB....

если добавить
ssl_session_tickets off;

То Session-ID не выдаётся. Надо почитать rfc5077, я раньше думал, что tickets 
без session-id работают...


From mdounin at mdounin.ru  Fri Feb 13 16:13:29 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 13 Feb 2015 19:13:29 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0YHRgtGMINGBIHNzbF9zZXNzaW9uX2NhY2hlIG9m?=
 =?UTF-8?B?Zg==?=
In-Reply-To: <54DE1992.3040207@citrin.ru>
References: <54DE16C8.5010805@citrin.ru>
 <54DE1992.3040207@citrin.ru>
Message-ID: <20150213161329.GH19012@mdounin.ru>

Hello!

On Fri, Feb 13, 2015 at 06:34:42PM +0300, Anton Yuzhaninov wrote:

> On 02/13/15 18:22, Anton Yuzhaninov wrote:
> >
> >ssl_session_cache off;
> >
> >при этом в логах пишется $ssl_session_reused=r
> >
> >openssl s_client
> >показвыет
> >Session-ID: 4A2293CB....
> 
> если добавить
> ssl_session_tickets off;
> 
> То Session-ID не выдаётся. Надо почитать rfc5077, я раньше думал, что
> tickets без session-id работают...

Почитай для начала dump трафика.  Если мне не изменяет память, 
Session-ID, который показывает openssl s_client в случае запрета 
кеша, тщательно придуман локально для эмуляции наличия сессии в 
случае наличия тикета.

-- 
Maxim Dounin
http://nginx.org/


From citrin at citrin.ru  Fri Feb 13 16:33:10 2015
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Fri, 13 Feb 2015 19:33:10 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0YHRgtGMINGBIHNzbF9zZXNzaW9uX2NhY2hlIG9m?=
 =?UTF-8?B?Zg==?=
In-Reply-To: <20150213161329.GH19012@mdounin.ru>
References: <54DE16C8.5010805@citrin.ru> <54DE1992.3040207@citrin.ru>
 <20150213161329.GH19012@mdounin.ru>
Message-ID: <54DE2746.8000403@citrin.ru>

On 02/13/15 19:13, Maxim Dounin wrote:
> Почитай для начала dump трафика.  Если мне не изменяет память,
> Session-ID, который показывает openssl s_client в случае запрета
> кеша, тщательно придуман локально для эмуляции наличия сессии в
> случае наличия тикета.

Да, так и оно и есть. В дампе session-id нет.


From swood at fotofor.biz  Sat Feb 14 16:49:06 2015
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Sat, 14 Feb 2015 20:49:06 +0400
Subject: SPDY errors
Message-ID: <CAM_jxg3Dge2L3-WdvYgZBtgz6v9CwF60s3U_Hwe9mm3kT-CZDQ@mail.gmail.com>

Здравствуйте.

Поймали следующую строчку в логе:

inflate() failed: -5 while processing SPDY

Это происходит, если сделать гигантскую cookie и спровоцировать внутренний
код ошибки 494.

Кто-нибудь сталкивался, может быть с такой проблемой? Версия nginx 1.7.4.

При этом, в http такого поведения не наблюдается.


Собственно, в конфиге я делаю вот так:

error_page   494  @fallback400;

А дальше обрабатываю именованный location.

-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150214/9c912272/attachment.html>

From vbart at nginx.com  Sat Feb 14 19:44:11 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Sat, 14 Feb 2015 22:44:11 +0300
Subject: SPDY errors
In-Reply-To: <CAM_jxg3Dge2L3-WdvYgZBtgz6v9CwF60s3U_Hwe9mm3kT-CZDQ@mail.gmail.com>
References: <CAM_jxg3Dge2L3-WdvYgZBtgz6v9CwF60s3U_Hwe9mm3kT-CZDQ@mail.gmail.com>
Message-ID: <1638948.J5VhiokeK4@vbart-laptop>

On Saturday 14 February 2015 20:49:06 Anton Kiryushkin wrote:
> Здравствуйте.
> 
> Поймали следующую строчку в логе:
> 
> inflate() failed: -5 while processing SPDY
> 
> Это происходит, если сделать гигантскую cookie и спровоцировать внутренний
> код ошибки 494.
> 
> Кто-нибудь сталкивался, может быть с такой проблемой? Версия nginx 1.7.4.
[..]

Это было исправлено 3 месяца назад в 1.7.8:
http://hg.nginx.org/nginx/rev/abb466a57a22

Стоит обновить nginx до актуальной версии (1.7.10 на данный момент).

--
Валентин Бартенев

From swood at fotofor.biz  Sat Feb 14 19:47:41 2015
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Sat, 14 Feb 2015 23:47:41 +0400
Subject: SPDY errors
In-Reply-To: <1638948.J5VhiokeK4@vbart-laptop>
References: <CAM_jxg3Dge2L3-WdvYgZBtgz6v9CwF60s3U_Hwe9mm3kT-CZDQ@mail.gmail.com>
 <1638948.J5VhiokeK4@vbart-laptop>
Message-ID: <CAM_jxg1a7Pn4aJ+b9zHZZjQX+x1B+vg2U701Xj0ZXK0p5Labfg@mail.gmail.com>

Спасибо.

14 февраля 2015 г., 22:44 пользователь Валентин Бартенев <vbart at nginx.com>
написал:

> On Saturday 14 February 2015 20:49:06 Anton Kiryushkin wrote:
> > Здравствуйте.
> >
> > Поймали следующую строчку в логе:
> >
> > inflate() failed: -5 while processing SPDY
> >
> > Это происходит, если сделать гигантскую cookie и спровоцировать
> внутренний
> > код ошибки 494.
> >
> > Кто-нибудь сталкивался, может быть с такой проблемой? Версия nginx 1.7.4.
> [..]
>
> Это было исправлено 3 месяца назад в 1.7.8:
> http://hg.nginx.org/nginx/rev/abb466a57a22
>
> Стоит обновить nginx до актуальной версии (1.7.10 на данный момент).
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150214/faaa5121/attachment.html>

From nginx-forum at nginx.us  Sat Feb 14 20:18:58 2015
From: nginx-forum at nginx.us (oee)
Date: Sat, 14 Feb 2015 15:18:58 -0500
Subject: =?UTF-8?B?0LrQsNC6INGD0LLQtdC70LjRh9C40YLRjCBOR1ggQ09ORiBCVUZGRVI/?=
Message-ID: <d194a7359a02fe1f635f4f5aaa4c6ba8.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток.
Использую nginx для определения браузера и платформы по user_agent через
perl_set '...
Но возникла проблема, регулярок собралось многовато, и размер получился
больше 4кб. Нагуглил, что NGX_CONF_BUFFER=4096 и именно он не дает добавить
еще информацию. Есть ли способ его увеличить хотя бы до 8192 байт? Понимаю,
что это будет влиять на производительность, но все же.
Делить назначение переменной на 2 и более конструкции perl_set не вариант.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256681,256681#msg-256681


From mdounin at mdounin.ru  Sun Feb 15 23:12:52 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 16 Feb 2015 02:12:52 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9Cy0LXQu9C40YfQuNGC0YwgTkdYIENPTkYgQlVGRkVSPw==?=
In-Reply-To: <d194a7359a02fe1f635f4f5aaa4c6ba8.NginxMailingListRussian@forum.nginx.org>
References: <d194a7359a02fe1f635f4f5aaa4c6ba8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150215231251.GL19012@mdounin.ru>

Hello!

On Sat, Feb 14, 2015 at 03:18:58PM -0500, oee wrote:

> Доброго времени суток.
> Использую nginx для определения браузера и платформы по user_agent через
> perl_set '...
> Но возникла проблема, регулярок собралось многовато, и размер получился
> больше 4кб. Нагуглил, что NGX_CONF_BUFFER=4096 и именно он не дает добавить
> еще информацию. Есть ли способ его увеличить хотя бы до 8192 байт? Понимаю,
> что это будет влиять на производительность, но все же.
> Делить назначение переменной на 2 и более конструкции perl_set не вариант.

Унесите перловый код из конфига nginx'а в перловый же модуль - и 
будет вам счастье без всяких увеличений.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Mon Feb 16 14:28:15 2015
From: nginx-forum at nginx.us (oee)
Date: Mon, 16 Feb 2015 09:28:15 -0500
Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9Cy0LXQu9C40YfQuNGC0YwgTkdYIENPTkYgQlVGRkVSPw==?=
In-Reply-To: <20150215231251.GL19012@mdounin.ru>
References: <20150215231251.GL19012@mdounin.ru>
Message-ID: <4fba70c3e11cc87530411fefdc22b8fd.NginxMailingListRussian@forum.nginx.org>

не просветите, как это сделать?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256698,256700#msg-256700


From mdounin at mdounin.ru  Mon Feb 16 15:53:47 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 16 Feb 2015 18:53:47 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9Cy0LXQu9C40YfQuNGC0YwgTkdYIENPTkYgQlVGRkVSPw==?=
In-Reply-To: <4fba70c3e11cc87530411fefdc22b8fd.NginxMailingListRussian@forum.nginx.org>
References: <20150215231251.GL19012@mdounin.ru>
 <4fba70c3e11cc87530411fefdc22b8fd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150216155347.GR19012@mdounin.ru>

Hello!

On Mon, Feb 16, 2015 at 09:28:15AM -0500, oee wrote:

> не просветите, как это сделать?

Пример есть в документации, тут:

http://nginx.org/ru/docs/http/ngx_http_perl_module.html#example

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Mon Feb 16 18:51:19 2015
From: nginx-forum at nginx.us (nrr)
Date: Mon, 16 Feb 2015 13:51:19 -0500
Subject: nginx-1.7.7
In-Reply-To: <20141029004804.GJ56368@lo0.su>
References: <20141029004804.GJ56368@lo0.su>
Message-ID: <5c601f34eafdd6afbdcdf294c2c67ed8.NginxMailingListRussian@forum.nginx.org>

Добрый вечер!

1. Как все таки использовать эту возможность?

В документации не нашел как использовать, есть только вот это:
Ответ, в заголовке которого есть поле ?Vary? со специальным значением ?*?,
не будет кэшироваться (1.7.7). Ответ, в заголовке которого есть поле ?Vary?
с другим значением, будет закэширован с учётом соответствующих полей
заголовка запроса (1.7.7). 

Нужно ли в fastcgi_cache_key добавлять $http_accept_encoding (или другую
переменную) или сохранение различных версий в кэше и так работает в
зависимости от заголовка Vary или Accept-Encoding?

2. Есть ли такая возможность в nginx:
кэширование nginx-ом 2-х результатов: gzip и не gzip если backend возвращает
только не gzip версию?

Спасибо!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254366,256703#msg-256703


From nginx-forum at nginx.us  Mon Feb 16 19:12:45 2015
From: nginx-forum at nginx.us (oee)
Date: Mon, 16 Feb 2015 14:12:45 -0500
Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9Cy0LXQu9C40YfQuNGC0YwgTkdYIENPTkYgQlVGRkVSPw==?=
In-Reply-To: <20150215231251.GL19012@mdounin.ru>
References: <20150215231251.GL19012@mdounin.ru>
Message-ID: <eae6b93069338fa121c247d5e2340d7c.NginxMailingListRussian@forum.nginx.org>

мммде, с перл слегка сложнее.
Других вариантов нет?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256698,256705#msg-256705


From mdounin at mdounin.ru  Mon Feb 16 19:19:10 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 16 Feb 2015 22:19:10 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9Cy0LXQu9C40YfQuNGC0YwgTkdYIENPTkYgQlVGRkVSPw==?=
In-Reply-To: <eae6b93069338fa121c247d5e2340d7c.NginxMailingListRussian@forum.nginx.org>
References: <20150215231251.GL19012@mdounin.ru>
 <eae6b93069338fa121c247d5e2340d7c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150216191910.GT19012@mdounin.ru>

Hello!

On Mon, Feb 16, 2015 at 02:12:45PM -0500, oee wrote:

> мммде, с перл слегка сложнее.
> Других вариантов нет?

Никто не заставляет использовать директиву perl, тот же синтаксис 
обращения к функциям понимает и директива perl_set, про которую вы 
спрашивали.  Чуть ниже в документации это явно указано.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Mon Feb 16 21:08:05 2015
From: nginx-forum at nginx.us (oee)
Date: Mon, 16 Feb 2015 16:08:05 -0500
Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9Cy0LXQu9C40YfQuNGC0YwgTkdYIENPTkYgQlVGRkVSPw==?=
In-Reply-To: <20150216191910.GT19012@mdounin.ru>
References: <20150216191910.GT19012@mdounin.ru>
Message-ID: <52224281505190d9781f680344d64165.NginxMailingListRussian@forum.nginx.org>

я и использую perl_set. Мне не хватает буфера размером 4кб для моих
функции.
Ладно, частично решил проблему, разделил функцию на несколько блоков
perl_set. Все работает.
Про директиву perl спасибо, возможно в будущем заюзаю

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256698,256710#msg-256710


From nginx-forum at nginx.us  Tue Feb 17 08:04:04 2015
From: nginx-forum at nginx.us (eximer)
Date: Tue, 17 Feb 2015 03:04:04 -0500
Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgNCw0LfQvtCx0YDQsNGC0YzRgdGPINGBINC60L4=?=
 =?UTF-8?B?0L3RgdGC0YDRg9C60YbQuNC10Lkg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C1?=
 =?UTF-8?B?0L3QuNGP?=
Message-ID: <bdb82761ada46ae565d4e30348648505.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, помогите пож-ста разобраться с конфигурацией.

Описание:
Нужно все адреса передавать скрипту index.php в параметре link, при этом
если адрес начинается на rus|de|frn|eng то передавать этот префикс в
параметре lang.
И в link, и в lang нужно передавать параметры без стартового /. Если
(rus|de|frn|eng) отсутствуют в lang ничего не передавать.

Например:
1. http://example.org/eng/about
$request_key = about
$request_lang = eng

2. http://example.org/about
$request_key = about
$request_lang =

Текущая конфигурация сайта:

map $request_uri $request_key {
   default "";
   ~^/(?P<key>.+)$ $key;
}

server {

location / {
   try_files $uri $uri/ /index.php?lang=&link=$request_key;
}
location ~* ^/(rus|de|frn|eng)/ {
   try_files $uri $uri/ /index.php?lang=$request_lang&link=$request_key;
}
location ~ \.php$ {
   fastcgi_pass fpm;
   include fastcgi_params;
   fastcgi_index index.php;
}
}

p.s. Сейчас в request_key передается весь url (без стартового слеша).
Не могу понять, как отпарсить и передать в request_lang параметр
rus|de|frn|eng (если таковой присутствует),
при этом в request_key передать все остальное.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256711,256711#msg-256711


From mdounin at mdounin.ru  Tue Feb 17 12:44:04 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Feb 2015 15:44:04 +0300
Subject: nginx-1.7.7
In-Reply-To: <5c601f34eafdd6afbdcdf294c2c67ed8.NginxMailingListRussian@forum.nginx.org>
References: <20141029004804.GJ56368@lo0.su>
 <5c601f34eafdd6afbdcdf294c2c67ed8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150217124404.GW19012@mdounin.ru>

Hello!

On Mon, Feb 16, 2015 at 01:51:19PM -0500, nrr wrote:

> Добрый вечер!
> 
> 1. Как все таки использовать эту возможность?
> 
> В документации не нашел как использовать, есть только вот это:
> Ответ, в заголовке которого есть поле ?Vary? со специальным значением ?*?,
> не будет кэшироваться (1.7.7). Ответ, в заголовке которого есть поле ?Vary?
> с другим значением, будет закэширован с учётом соответствующих полей
> заголовка запроса (1.7.7). 
> 
> Нужно ли в fastcgi_cache_key добавлять $http_accept_encoding (или другую
> переменную) или сохранение различных версий в кэше и так работает в
> зависимости от заголовка Vary или Accept-Encoding?

Не нужно ничего добавлять, всё само работает корректно.  Если 
бекенд возвращает ответ с заголовком Vary, то nginx основании 
переданного заголовка Vary и заголовков запроса клиента вторичный 
ключ, и будет возвращать данный ответ только тем клиентам, у 
которых ключ совпадёт (у других клиентов - будут свои вторичные 
ключи и свои ответы).

Следует, однако, понимать, что эффективность кеширования при 
использовании Vary - низкая, т.к. вторичных ключей даже при 
использовании "Vary: Accept-Encoding" будет наверняка больше, чем 
возможных вариантов ответов бекенда.

> 2. Есть ли такая возможность в nginx:
> кэширование nginx-ом 2-х результатов: gzip и не gzip если backend возвращает
> только не gzip версию?

Только с помощью дополнительного проксирования.

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Tue Feb 17 12:49:58 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Feb 2015 15:49:58 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9Cy0LXQu9C40YfQuNGC0YwgTkdYIENPTkYgQlVGRkVSPw==?=
In-Reply-To: <52224281505190d9781f680344d64165.NginxMailingListRussian@forum.nginx.org>
References: <20150216191910.GT19012@mdounin.ru>
 <52224281505190d9781f680344d64165.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150217124958.GY19012@mdounin.ru>

Hello!

On Mon, Feb 16, 2015 at 04:08:05PM -0500, oee wrote:

> я и использую perl_set. Мне не хватает буфера размером 4кб для моих
> функции.
> Ладно, частично решил проблему, разделил функцию на несколько блоков
> perl_set. Все работает.
> Про директиву perl спасибо, возможно в будущем заюзаю

Повторяю ещё раз: вынесите код, который вы используете в perl_set, 
в отдельный модуль, и будет вам счастье.

Как выносить код в отдельный модуль - показано в документации на 
примере директивы perl.  Это, однако, не означает, что там можно 
делать только с директивой perl.  С директивой perl_set можно 
делать то же самое.

-- 
Maxim Dounin
http://nginx.org/


From chipitsine at gmail.com  Tue Feb 17 13:10:13 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 17 Feb 2015 19:10:13 +0600
Subject: nginx-1.7.7
In-Reply-To: <5c601f34eafdd6afbdcdf294c2c67ed8.NginxMailingListRussian@forum.nginx.org>
References: <20141029004804.GJ56368@lo0.su>
 <5c601f34eafdd6afbdcdf294c2c67ed8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQF4KLFTkta5js3HAAbq+0p=7+uqj2BvrWpLZxa2GodqMg@mail.gmail.com>

а зачем кешировать gzip и не-gzip ?
какая задача решается ?

16 февраля 2015 г., 23:51 пользователь nrr <nginx-forum at nginx.us> написал:
> Добрый вечер!
>
> 1. Как все таки использовать эту возможность?
>
> В документации не нашел как использовать, есть только вот это:
> Ответ, в заголовке которого есть поле ?Vary? со специальным значением ?*?,
> не будет кэшироваться (1.7.7). Ответ, в заголовке которого есть поле ?Vary?
> с другим значением, будет закэширован с учётом соответствующих полей
> заголовка запроса (1.7.7).
>
> Нужно ли в fastcgi_cache_key добавлять $http_accept_encoding (или другую
> переменную) или сохранение различных версий в кэше и так работает в
> зависимости от заголовка Vary или Accept-Encoding?
>
> 2. Есть ли такая возможность в nginx:
> кэширование nginx-ом 2-х результатов: gzip и не gzip если backend возвращает
> только не gzip версию?
>
> Спасибо!
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254366,256703#msg-256703
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From vase at selfip.ru  Tue Feb 17 13:36:29 2015
From: vase at selfip.ru (Vasiliy Tolstov)
Date: Tue, 17 Feb 2015 17:36:29 +0400
Subject: offtopic linux routeing question
Message-ID: <CACaajQvP4hgXtp7HkaKaqKA8DWsF38F_O7gtZVXzbtgfjmW1FA@mail.gmail.com>

Добрый день.
Пока не знаю где можно еще уточнить, поэтому пишу сюда. Имеется сеть
адресов, для который по-умолчанию сделан blackhole роутинг.
Вопрос состоит в том, почему линукс все равно посылает icmp сообщение
в ответ о недоступности адреса из данной сети , причем как-то странно,
в среднем по 2 сообщения в секунду...
Если я все правильно прочитал, то в случае blackhole такого быть не должно.
Кто то может что-то подсказать по данному поводу?

-- 
Vasiliy Tolstov,
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

From bazilek at gmail.com  Tue Feb 17 14:11:59 2015
From: bazilek at gmail.com (Vasil Mikhalenya)
Date: Tue, 17 Feb 2015 17:11:59 +0300
Subject: try_files and index
Message-ID: <CAPc4iSAHOkWpcPD6pJtNnNyjRcTh5yKQKVa8vvRn7tE4obivYw@mail.gmail.com>

Коллеги,

location / {
  try_files $uri $uri/ @fallback;
}

помогите окончательно прояснить как работаю механизмы try_files и index
совместно.
Например, почему для GET / запрос не попадает в @fallback при добавлении
$uri/ в try_files, как это связано с index? какая конфигурация будет
правильной в случае статического index.html и в случае /, который должен
отдаваться бэкендом.

P.S. множественные темы видел, однако для себя из них ничего не вынес.

Спасибо.

-- 
Best regards,
Vasil Mikhalenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150217/182f607a/attachment.html>

From denis at webmaster.spb.ru  Tue Feb 17 16:37:10 2015
From: denis at webmaster.spb.ru (denis)
Date: Tue, 17 Feb 2015 19:37:10 +0300
Subject: nginx-1.7.7
In-Reply-To: <CAFHpkQF4KLFTkta5js3HAAbq+0p=7+uqj2BvrWpLZxa2GodqMg@mail.gmail.com>
References: <20141029004804.GJ56368@lo0.su>
 <5c601f34eafdd6afbdcdf294c2c67ed8.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQF4KLFTkta5js3HAAbq+0p=7+uqj2BvrWpLZxa2GodqMg@mail.gmail.com>
Message-ID: <54E36E36.80603@webmaster.spb.ru>

17.02.2015 16:10, Илья Шипицин пишет:
> а зачем кешировать gzip и не-gzip ?
> какая задача решается ?
>
видимо, разгрузить проц и не жать уже сжатое снова.. А не сжатое тем, 
кто не умеет сжатие.


From denis at webmaster.spb.ru  Tue Feb 17 16:39:36 2015
From: denis at webmaster.spb.ru (denis)
Date: Tue, 17 Feb 2015 19:39:36 +0300
Subject: offtopic linux routeing question
In-Reply-To: <CACaajQvP4hgXtp7HkaKaqKA8DWsF38F_O7gtZVXzbtgfjmW1FA@mail.gmail.com>
References: <CACaajQvP4hgXtp7HkaKaqKA8DWsF38F_O7gtZVXzbtgfjmW1FA@mail.gmail.com>
Message-ID: <54E36EC8.8010403@webmaster.spb.ru>

17.02.2015 16:36, Vasiliy Tolstov пишет:
> Добрый день.
> Пока не знаю где можно еще уточнить, поэтому пишу сюда. Имеется сеть
> адресов, для который по-умолчанию сделан blackhole роутинг.
> Вопрос состоит в том, почему линукс все равно посылает icmp сообщение
> в ответ о недоступности адреса из данной сети , причем как-то странно,
> в среднем по 2 сообщения в секунду...
> Если я все правильно прочитал, то в случае blackhole такого быть не должно.
> Кто то может что-то подсказать по данному поводу?
>
С каких пор nginx научился icmp? O_O
Это задача фаервола. А для правильного отлупа у iptables есть
-A INPUT -j REJECT --reject-with icmp-host-prohibited
и аналоги.
Ну и есть просто -j DROP


From nginx-forum at nginx.us  Tue Feb 17 16:40:24 2015
From: nginx-forum at nginx.us (nrr)
Date: Tue, 17 Feb 2015 11:40:24 -0500
Subject: nginx-1.7.7
In-Reply-To: <54E36E36.80603@webmaster.spb.ru>
References: <54E36E36.80603@webmaster.spb.ru>
Message-ID: <c32014479663c55256daa7bc1bfc782e.NginxMailingListRussian@forum.nginx.org>

denis Wrote:
-------------------------------------------------------
> 17.02.2015 16:10, Илья Шипицин пишет:
> > а зачем кешировать gzip и не-gzip ?
> > какая задача решается ?
> >
> видимо, разгрузить проц и не жать уже сжатое снова.. А не сжатое тем, 
> кто не умеет сжатие.
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

да именно так, - не нагружать процессор лишней работой.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254366,256723#msg-256723


From nginx-forum at nginx.us  Tue Feb 17 17:03:12 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Feb 2015 12:03:12 -0500
Subject: gzip_to_cache
Message-ID: <1dae2a862298961daa8aa7de0f51815b.NginxMailingListRussian@forum.nginx.org>

При кешировании ответов бекенда, нужно научить Nginx предварительно сжимать
ответ бекенда, если данный ответ соответствует указанному gzip_types.

Раньше это было сложно по многим причинам, не было модуля gunzip и не было
weak ETag, но сейчас есть все необходимое чтобы использовать gzip до
сохранения ответа в кеше.

Сейчас мы сжимаем ответ на стороне бекенда, все работает нормально, в кеш
кладется уже сжатый ответ, в Nginx используем gunzip.
Но хочется перенести задачу компрессии на Nginx, это позволит бекенду не
заниматься лишней работой, быстрей освобождаться и принимать следующий
запрос, компрессию будет делать Nginx, кстати у него это получается быстрей
чем в РНР.

Я знаю что можно поставить между бекендом и Nginx, ещё один прокси Nginx
который будет заниматься компрессией, но логичней и удобней это делать без
лишнего звена.

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

Спасибо!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256725,256725#msg-256725


From chipitsine at gmail.com  Tue Feb 17 17:15:10 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 17 Feb 2015 23:15:10 +0600
Subject: nginx-1.7.7
In-Reply-To: <c32014479663c55256daa7bc1bfc782e.NginxMailingListRussian@forum.nginx.org>
References: <54E36E36.80603@webmaster.spb.ru>
 <c32014479663c55256daa7bc1bfc782e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEt-w2X8GV1CSmsT=GcrXw5XrSHULEO1uanBaJMdD6Bjg@mail.gmail.com>

а какой у вас трафик, если не секрет ? и какая нагрузка на процессор?
и как вы определили, что именно компрессия нагружает процессор ?

17 февраля 2015 г., 21:40 пользователь nrr <nginx-forum at nginx.us> написал:
> denis Wrote:
> -------------------------------------------------------
>> 17.02.2015 16:10, Илья Шипицин пишет:
>> > а зачем кешировать gzip и не-gzip ?
>> > какая задача решается ?
>> >
>> видимо, разгрузить проц и не жать уже сжатое снова.. А не сжатое тем,
>> кто не умеет сжатие.
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> да именно так, - не нагружать процессор лишней работой.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254366,256723#msg-256723
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From gmm at csdoc.com  Tue Feb 17 17:51:00 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Tue, 17 Feb 2015 19:51:00 +0200
Subject: gzip_to_cache
In-Reply-To: <1dae2a862298961daa8aa7de0f51815b.NginxMailingListRussian@forum.nginx.org>
References: <1dae2a862298961daa8aa7de0f51815b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54E37F84.3050607@csdoc.com>

On 17.02.2015 19:03, S.A.N wrote:

> При кешировании ответов бекенда, нужно научить Nginx предварительно сжимать
> ответ бекенда, если данный ответ соответствует указанному gzip_types.
>
> Раньше это было сложно по многим причинам, не было модуля gunzip и не было
> weak ETag, но сейчас есть все необходимое чтобы использовать gzip до
> сохранения ответа в кеше.
>
> Сейчас мы сжимаем ответ на стороне бекенда, все работает нормально, в кеш
> кладется уже сжатый ответ, в Nginx используем gunzip.
 >
> Но хочется перенести задачу компрессии на Nginx, это позволит бекенду не
> заниматься лишней работой, быстрей освобождаться и принимать следующий
> запрос, компрессию будет делать Nginx, кстати у него это получается быстрей
> чем в РНР.

Тогда nginx будет заниматься лишней работой, вместо
"быстрей освобождаться и принимать следующий запрос".

Делать компрессию быстрей у nginx получается ровно по одной причине -
http://nginx.org/ru/docs/http/ngx_http_gzip_module.html#gzip_comp_level
дефолтовое значение настроено на максимальную скорость в ущерб качеству.

> Я знаю что можно поставить между бекендом и Nginx, ещё один прокси Nginx
> который будет заниматься компрессией, но логичней и удобней это делать без
> лишнего звена.

Без лишнего звена это делать можно и другим способом -
сжимая ответ прямо на бекенде и отдавая ответ уже в сжатом виде.

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

Совершенно не понятно, почему лучше будеть сжимать ответы бекенда
на стороне nginx, а не на самом бекенде, особенно если учесть, что:

1) любая "долгоиграющая" операция (например, компрессия ответа бекенда)
надолго блокирующая воркер процесс nginx создает проблемы в работе nginx

2) вокреров nginx обычно запускается небольшое число,
а воркеров php-fpm - обычно значительное большее число.

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Tue Feb 17 18:16:25 2015
From: nginx-forum at nginx.us (nrr)
Date: Tue, 17 Feb 2015 13:16:25 -0500
Subject: nginx-1.7.7
In-Reply-To: <CAFHpkQEt-w2X8GV1CSmsT=GcrXw5XrSHULEO1uanBaJMdD6Bjg@mail.gmail.com>
References: <CAFHpkQEt-w2X8GV1CSmsT=GcrXw5XrSHULEO1uanBaJMdD6Bjg@mail.gmail.com>
Message-ID: <e55061f1e3cea3ea5c9d3a4c3610b828.NginxMailingListRussian@forum.nginx.org>

Добрый вечер,

Трафик на разных проектах разный - от 100 человек  до 120 тысяч юзеров в
сутки.

Нагрузка на процессор не очень большая, но здесь главное хотелось бы
уменьшить время отдачи контента за счет уже подготовленных кэшированных
данных как в не gzip так и gzip.


Илья Шипицин Wrote:
-------------------------------------------------------
> а какой у вас трафик, если не секрет ? и какая нагрузка на процессор?
> и как вы определили, что именно компрессия нагружает процессор ?
> 
> 17 февраля 2015 г., 21:40 пользователь nrr <nginx-forum at nginx.us>
> написал:
> > denis Wrote:
> > -------------------------------------------------------
> >> 17.02.2015 16:10, Илья Шипицин пишет:
> >> > а зачем кешировать gzip и не-gzip ?
> >> > какая задача решается ?
> >> >
> >> видимо, разгрузить проц и не жать уже сжатое снова.. А не сжатое
> тем,
> >> кто не умеет сжатие.
> >>
> >> _______________________________________________
> >> nginx-ru mailing list
> >> nginx-ru at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> > да именно так, - не нагружать процессор лишней работой.
> >
> > Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,254366,256723#msg-256723
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254366,256730#msg-256730


From chipitsine at gmail.com  Tue Feb 17 18:39:11 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 18 Feb 2015 00:39:11 +0600
Subject: nginx-1.7.7
In-Reply-To: <e55061f1e3cea3ea5c9d3a4c3610b828.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEt-w2X8GV1CSmsT=GcrXw5XrSHULEO1uanBaJMdD6Bjg@mail.gmail.com>
 <e55061f1e3cea3ea5c9d3a4c3610b828.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQF3vm5otDNyrTYqC2QxgvAc8PH9aGYMORqN7ao6KZ4_=A@mail.gmail.com>

кеш берется из файловой системы, в то время как gzip работает на лету
(иногда, конечно, буферизует на диск).
при высокой нагрузке дисковый ввод-вывод будет узким местом.

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

17 февраля 2015 г., 23:16 пользователь nrr <nginx-forum at nginx.us> написал:
> Добрый вечер,
>
> Трафик на разных проектах разный - от 100 человек  до 120 тысяч юзеров в
> сутки.
>
> Нагрузка на процессор не очень большая, но здесь главное хотелось бы
> уменьшить время отдачи контента за счет уже подготовленных кэшированных
> данных как в не gzip так и gzip.
>
>
> Илья Шипицин Wrote:
> -------------------------------------------------------
>> а какой у вас трафик, если не секрет ? и какая нагрузка на процессор?
>> и как вы определили, что именно компрессия нагружает процессор ?
>>
>> 17 февраля 2015 г., 21:40 пользователь nrr <nginx-forum at nginx.us>
>> написал:
>> > denis Wrote:
>> > -------------------------------------------------------
>> >> 17.02.2015 16:10, Илья Шипицин пишет:
>> >> > а зачем кешировать gzip и не-gzip ?
>> >> > какая задача решается ?
>> >> >
>> >> видимо, разгрузить проц и не жать уже сжатое снова.. А не сжатое
>> тем,
>> >> кто не умеет сжатие.
>> >>
>> >> _______________________________________________
>> >> nginx-ru mailing list
>> >> nginx-ru at nginx.org
>> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >
>> > да именно так, - не нагружать процессор лишней работой.
>> >
>> > Posted at Nginx Forum:
>> http://forum.nginx.org/read.php?21,254366,256723#msg-256723
>> >
>> > _______________________________________________
>> > nginx-ru mailing list
>> > nginx-ru at nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254366,256730#msg-256730
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Tue Feb 17 19:13:47 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Feb 2015 14:13:47 -0500
Subject: gzip_to_cache
In-Reply-To: <54E37F84.3050607@csdoc.com>
References: <54E37F84.3050607@csdoc.com>
Message-ID: <e653eb2784e46e97f56f4836ec3de2b3.NginxMailingListRussian@forum.nginx.org>

Gena Makhomed Wrote:
-------------------------------------------------------
> Совершенно не понятно, почему лучше будеть сжимать ответы бекенда
> на стороне nginx, а не на самом бекенде, особенно если учесть, что:
> 
> 1) любая "долгоиграющая" операция (например, компрессия ответа
> бекенда)
> надолго блокирующая воркер процесс nginx создает проблемы в работе
> nginx
> 
> 2) вокреров nginx обычно запускается небольшое число,
> а воркеров php-fpm - обычно значительное большее число.
> 

1. Компрессия gzip, слабо повлияет на время блокировки воркера Nginx, на это
больше влияют другие факторы, скорость соединения с клиентом и т.д, в
процентом соотношении разница будет на уровне погрешности, если конечно
размер контента не очень большой.

2. Да, в php-fpm обычно параллельно работают много воркеров, но эти воркеры
держат коннекты к MySQL, Redis и другим ресурсам, по этому освободить воркер
РНР, означает освободить коннекты, к которым может выстроится очередь других
РНР воркеров.

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

Nginx получит потребительские преимущества если он сможет сжимать ответы и
класть в кеш уже сжатый ответ.
Сейчас большинство тех кто использует кеширования, не имют сжатия на стороне
бекенда и не используют дополнительный прокси ради сжатия, они просто
включают gzip on; в кеш кладется не сжатый ответ - это занимает больше места
на диске и его амортизацию.

Мы пока что сжимаем ответ на стороне бекенда, но будем использовать сжатия в
Nginx, если он научится класть в кеш сжатый ответ.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256725,256732#msg-256732


From gmm at csdoc.com  Tue Feb 17 21:53:36 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Tue, 17 Feb 2015 23:53:36 +0200
Subject: gzip_to_cache
In-Reply-To: <e653eb2784e46e97f56f4836ec3de2b3.NginxMailingListRussian@forum.nginx.org>
References: <54E37F84.3050607@csdoc.com>
 <e653eb2784e46e97f56f4836ec3de2b3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54E3B860.9020800@csdoc.com>

On 17.02.2015 21:13, S.A.N wrote:

> 1. Компрессия gzip, слабо повлияет на время блокировки воркера Nginx, на это
> больше влияют другие факторы, скорость соединения с клиентом и т.д, в
> процентом соотношении разница будет на уровне погрешности, если конечно
> размер контента не очень большой.

Каким образом скорость соединения с клиентом
влияет на время *блокировки* воркера nginx ?

nginx работает с сетью в неблокирующем режиме.

> 2. Да, в php-fpm обычно параллельно работают много воркеров, но эти воркеры
> держат коннекты к MySQL, Redis и другим ресурсам, по этому освободить воркер
> РНР, означает освободить коннекты, к которым может выстроится очередь других
> РНР воркеров.

Тогда уже придется делать больше воркеров nginx, чтобы они могли
часть своего времени потратить на компрессию ответов от бекенда.

> Скорость компрессии ответа в РНР будет медленней, потому что РНР должен
> получить весь буфер вывода сжать его, очистить весь буфер и записать в него
> сжатые данные, из-за этого в РНР это работает медленней, плюс небольшой
> оверхед на вызове функций врапера zlib.

А в nginx компрессия gzip разве работает каким-то другим способом?

В ответе будет заголовок Transfer-Encoding: chunked

и не будет заголовка Content-Length: - потому что в момент начала
отправки сжатого ответа его полный размер неизвествен воркеру nginx.

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Tue Feb 17 22:25:42 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Feb 2015 17:25:42 -0500
Subject: gzip_to_cache
In-Reply-To: <54E3B860.9020800@csdoc.com>
References: <54E3B860.9020800@csdoc.com>
Message-ID: <3b2e260a7fd469fa2c93953ddb6d254f.NginxMailingListRussian@forum.nginx.org>

Gena Makhomed Wrote:
-------------------------------------------------------
> Каким образом скорость соединения с клиентом
> влияет на время *блокировки* воркера nginx ?
> 
> nginx работает с сетью в неблокирующем режиме.

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

> > 2. Да, в php-fpm обычно параллельно работают много воркеров, но эти
> воркеры
> > держат коннекты к MySQL, Redis и другим ресурсам, по этому
> освободить воркер
> > РНР, означает освободить коннекты, к которым может выстроится
> очередь других
> > РНР воркеров.
> 
> Тогда уже придется делать больше воркеров nginx, чтобы они могли
> часть своего времени потратить на компрессию ответов от бекенда.
> 
> > Скорость компрессии ответа в РНР будет медленней, потому что РНР
> должен
> > получить весь буфер вывода сжать его, очистить весь буфер и записать
> в него
> > сжатые данные, из-за этого в РНР это работает медленней, плюс
> небольшой
> > оверхед на вызове функций врапера zlib.
> 
> А в nginx компрессия gzip разве работает каким-то другим способом?
> 
> В ответе будет заголовок Transfer-Encoding: chunked
> 
> и не будет заголовка Content-Length: - потому что в момент начала
> отправки сжатого ответа его полный размер неизвествен воркеру nginx.

Одно из немногих преимуществ компрессии на бекенде, это возможность отдать
правильный Content-Length, для нас это довольно важно чтобы мобил клиенты
могли правильно показывать прогресс бар загрузки, но думаю модуль
кеширования Nginx, может самостоятельно вычислить размер тела ответа и
сохранить в кеше правильный Content-Length.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256725,256736#msg-256736


From vbart at nginx.com  Tue Feb 17 22:42:13 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 18 Feb 2015 01:42:13 +0300
Subject: gzip_to_cache
In-Reply-To: <3b2e260a7fd469fa2c93953ddb6d254f.NginxMailingListRussian@forum.nginx.org>
References: <54E3B860.9020800@csdoc.com>
 <3b2e260a7fd469fa2c93953ddb6d254f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1525493.pRgIAKxUn2@vbart-laptop>

On Tuesday 17 February 2015 17:25:42 S.A.N wrote:
> Gena Makhomed Wrote:
> -------------------------------------------------------
> > Каким образом скорость соединения с клиентом
> > влияет на время *блокировки* воркера nginx ?
> > 
> > nginx работает с сетью в неблокирующем режиме.
> 
> Да, вы правы, медленный клиент не блокирует воркер, но компрессия ответа в
> Nginx, практически не влияет на скорость его работы, проверил в ab, разница
> на уровне погрешности.

nginx - это такой веб-сервер, с помощью которого можно измерить 
производительность ab, но не наоборот.

--
Валентин Бартенев

From nginx-forum at nginx.us  Tue Feb 17 23:00:49 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Feb 2015 18:00:49 -0500
Subject: gzip_to_cache
In-Reply-To: <1525493.pRgIAKxUn2@vbart-laptop>
References: <1525493.pRgIAKxUn2@vbart-laptop>
Message-ID: <815fff6cf004921846c4502c4c452814.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> nginx - это такой веб-сервер, с помощью которого можно измерить 
> производительность ab, но не наоборот.

:)
Вот по этому, компрессию лучше производить в Nginx, в кеше сохранять сжатый
ответ.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256725,256738#msg-256738


From vbart at nginx.com  Tue Feb 17 23:18:25 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 18 Feb 2015 02:18:25 +0300
Subject: gzip_to_cache
In-Reply-To: <815fff6cf004921846c4502c4c452814.NginxMailingListRussian@forum.nginx.org>
References: <1525493.pRgIAKxUn2@vbart-laptop>
 <815fff6cf004921846c4502c4c452814.NginxMailingListRussian@forum.nginx.org>
Message-ID: <15659475.DiEtOF9rWn@vbart-laptop>

On Tuesday 17 February 2015 18:00:49 S.A.N wrote:
> Валентин Бартенев Wrote:
> -------------------------------------------------------
> > nginx - это такой веб-сервер, с помощью которого можно измерить 
> > производительность ab, но не наоборот.
> 
> :)
> Вот по этому, компрессию лучше производить в Nginx, в кеше сохранять сжатый
> ответ.
> 

Как было уже правильно замечено, компрессию все же лучше производить:

 1. Как можно раньше, чтобы сократить издержки на передачу ответа в nginx;

 2. Там, где размер ответа заранее известен, а это чаще всего бэкенд;

 3. Вне рабочих процессов nginx, поскольку занимаясь сжатием, последний
    не может в этот момент заниматься своей основной задачей, а именно
    обрабатывать события на соединениях.

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

Кэш в nginx работает на уровне между сокетом и протокольным upstream-модулем.
И в кэш сохраняется сырой ответ от бэкенда, до какой либо обработки, т.е.
если это, например, FastCGI, то в кэше будут лежать соответствующие фреймы
(или records, как они называются в спецификации), которые нельзя так просто 
сжать целиком, а затем отдать клиенту.  Если это http, то там могут лежать 
чанки, которые, опять же, нельзя просто взять и сжать.

Все это большая работа, требующая значительное количество человеко-часов.

--
Валентин Бартенев

From nginx-forum at nginx.us  Tue Feb 17 23:29:46 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Feb 2015 18:29:46 -0500
Subject: gzip_to_cache
In-Reply-To: <15659475.DiEtOF9rWn@vbart-laptop>
References: <15659475.DiEtOF9rWn@vbart-laptop>
Message-ID: <d19f90df7ed227e3b6cd7572a3671fd3.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> Конечно, у задачи сжатия перед кэшированиям тоже есть свои юзкейсы, но
> её реализация не так проста, как может показаться.  Скорее всего для
> этого 
> придется переписать весь механизм кэширования или добавлять еще один,
> другого уровня.
> 
> Кэш в nginx работает на уровне между сокетом и протокольным
> upstream-модулем.
> И в кэш сохраняется сырой ответ от бэкенда, до какой либо обработки,
> т.е.
> если это, например, FastCGI, то в кэше будут лежать соответствующие
> фреймы
> (или records, как они называются в спецификации), которые нельзя так
> просто 
> сжать целиком, а затем отдать клиенту.  Если это http, то там могут
> лежать 
> чанки, которые, опять же, нельзя просто взять и сжать.
> 
> Все это большая работа, требующая значительное количество
> человеко-часов.

Ясно, спасибо за подробный ответ.
Будем продолжать использовать компрессию на бекенде.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256725,256741#msg-256741


From v.tolstov at selfip.ru  Wed Feb 18 05:50:20 2015
From: v.tolstov at selfip.ru (Vasiliy Tolstov)
Date: Wed, 18 Feb 2015 09:50:20 +0400
Subject: offtopic linux routeing question
In-Reply-To: <54E36EC8.8010403@webmaster.spb.ru>
References: <CACaajQvP4hgXtp7HkaKaqKA8DWsF38F_O7gtZVXzbtgfjmW1FA@mail.gmail.com>
 <54E36EC8.8010403@webmaster.spb.ru>
Message-ID: <CACaajQu=Esiu+rcq5fi4643Zm2=DtFWjo0Ui6OHx-xERy_+xsA@mail.gmail.com>

17 февраля 2015 г., 19:39 пользователь denis <denis at webmaster.spb.ru> написал:
> С каких пор nginx научился icmp? O_O

Поэтому и offtopic

> Это задача фаервола. А для правильного отлупа у iptables есть
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> и аналоги.
> Ну и есть просто -j DROP

Я понимаю про iptables, но документация про iproute2 говорит, что в
случае blackhole, ICMP посылаться не должен, я же вижу, что все равно
посылается.


-- 
Vasiliy Tolstov,
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

From chipitsine at gmail.com  Wed Feb 18 06:09:16 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 18 Feb 2015 12:09:16 +0600
Subject: offtopic linux routeing question
In-Reply-To: <CACaajQu=Esiu+rcq5fi4643Zm2=DtFWjo0Ui6OHx-xERy_+xsA@mail.gmail.com>
References: <CACaajQvP4hgXtp7HkaKaqKA8DWsF38F_O7gtZVXzbtgfjmW1FA@mail.gmail.com>
 <54E36EC8.8010403@webmaster.spb.ru>
 <CACaajQu=Esiu+rcq5fi4643Zm2=DtFWjo0Ui6OHx-xERy_+xsA@mail.gmail.com>
Message-ID: <CAFHpkQF+ggEMtDvwxTqX_32g2+2EpSXDbT8dexhxcDHBZUQXtg@mail.gmail.com>

правила фаирвола срабатывают раньше, у вас есть REJECT скорее всего.
а до маршрутизации не доходит

18 февраля 2015 г., 10:50 пользователь Vasiliy Tolstov
<v.tolstov at selfip.ru> написал:
> 17 февраля 2015 г., 19:39 пользователь denis <denis at webmaster.spb.ru> написал:
>> С каких пор nginx научился icmp? O_O
>
> Поэтому и offtopic
>
>> Это задача фаервола. А для правильного отлупа у iptables есть
>> -A INPUT -j REJECT --reject-with icmp-host-prohibited
>> и аналоги.
>> Ну и есть просто -j DROP
>
> Я понимаю про iptables, но документация про iproute2 говорит, что в
> случае blackhole, ICMP посылаться не должен, я же вижу, что все равно
> посылается.
>
>
> --
> Vasiliy Tolstov,
> e-mail: v.tolstov at selfip.ru
> jabber: vase at selfip.ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From v.tolstov at selfip.ru  Wed Feb 18 06:26:17 2015
From: v.tolstov at selfip.ru (Vasiliy Tolstov)
Date: Wed, 18 Feb 2015 10:26:17 +0400
Subject: offtopic linux routeing question
In-Reply-To: <CAFHpkQF+ggEMtDvwxTqX_32g2+2EpSXDbT8dexhxcDHBZUQXtg@mail.gmail.com>
References: <CACaajQvP4hgXtp7HkaKaqKA8DWsF38F_O7gtZVXzbtgfjmW1FA@mail.gmail.com>
 <54E36EC8.8010403@webmaster.spb.ru>
 <CACaajQu=Esiu+rcq5fi4643Zm2=DtFWjo0Ui6OHx-xERy_+xsA@mail.gmail.com>
 <CAFHpkQF+ggEMtDvwxTqX_32g2+2EpSXDbT8dexhxcDHBZUQXtg@mail.gmail.com>
Message-ID: <CACaajQvekrUrPJy=DTaacxmdNL4nV809hK4Rzkvcc5Xt0EDZKA@mail.gmail.com>

18 февраля 2015 г., 9:09 пользователь Илья Шипицин
<chipitsine at gmail.com> написал:
> правила фаирвола срабатывают раньше, у вас есть REJECT скорее всего.
> а до маршрутизации не доходит


Тогда я бы получал на каждый пакет icmp ответ, я же получаю всего два пакета.
Для данной сети есть в iptables только два правила, и если я правильно
помню iptables, они срабатывают после форварда ядра:
-A FORWARD -s xxx/21 -j NETFLOW
-A FORWARD -d xxx/21 -j NETFLOW

-- 
Vasiliy Tolstov,
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

From nginx-forum at nginx.us  Thu Feb 19 05:30:37 2015
From: nginx-forum at nginx.us (slyab)
Date: Thu, 19 Feb 2015 00:30:37 -0500
Subject: geoip
Message-ID: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>

Приветствую, вопрос не по nginx, но посоветовали сюда обратиться. Поэтому
сразу извиняюсь за оффтоп.

Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается? Вопрос
в следующем, некоторые сервисы, в частности www.2ip.ru используют этот адрес
(по крайней мере мне они сказали туда писать) для геоопределения ip-адресов.
Но вот беда - писал в почту, на форму на сайте, и cюда
http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256777,256777#msg-256777


From nginx-forum at nginx.us  Thu Feb 19 06:10:57 2015
From: nginx-forum at nginx.us (slyab)
Date: Thu, 19 Feb 2015 01:10:57 -0500
Subject: offtopic linux routeing question
In-Reply-To: <CACaajQvekrUrPJy=DTaacxmdNL4nV809hK4Rzkvcc5Xt0EDZKA@mail.gmail.com>
References: <CACaajQvekrUrPJy=DTaacxmdNL4nV809hK4Rzkvcc5Xt0EDZKA@mail.gmail.com>
Message-ID: <83180c8c488789e39aa8a3f08f36ce3b.NginxMailingListRussian@forum.nginx.org>

Ну да, все верно правила цепочки FORWARD обрабатываются после принятия
решения ядром о дальнейшей маршрутизации. Как делаешь blackhole? Сейчас
проверил:
ip rule add blackhole to 192.168.101.0/24

ip rule
0:	from all lookup local 
32765:	from all to 192.168.101.0/24 blackhole
32766:	from all lookup main 
32767:	from all lookup default 

Никаких icmp ответов от узла не исходит. Что вообще есть в ip rule?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256718,256779#msg-256779


From nginx-forum at nginx.us  Thu Feb 19 09:20:01 2015
From: nginx-forum at nginx.us (dwow)
Date: Thu, 19 Feb 2015 04:20:01 -0500
Subject: =?UTF-8?B?0J7Rh9C10YDQtdC00Lgg0Log0LHRjdC60LXQvdC00YMg0LIgcHJveHkgbW9kdWxl?=
Message-ID: <2a9a1b31f7304ead071f34d69b2642c1.NginxMailingListRussian@forum.nginx.org>

И снова здравствуйте!
Такой вопрос.
Nginx.  Запросы с него проксируются на какой-то бэкенд. Можно ли настроить
nginx так, чтобы не создавать/регулировать нагрузку на бэкенд, например, не
больше 3-х одновременных запросов? Чтобы создавалось что-то наподобие
очереди запросов на обработку бекендом?
Спасибо!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256785,256785#msg-256785


From citrin at citrin.ru  Thu Feb 19 10:59:40 2015
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Thu, 19 Feb 2015 13:59:40 +0300
Subject: geoip
In-Reply-To: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
References: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54E5C21C.8070109@citrin.ru>

On 02/19/15 08:30, slyab wrote:
> Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается? Вопрос
> в следующем, некоторые сервисы, в частностиwww.2ip.ru  используют этот адрес
> (по крайней мере мне они сказали туда писать) для геоопределения ip-адресов.
> Но вот беда - писал в почту, на форму на сайте, и cюда
> http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.

Данные обновляются (возможно в автоматическом режиме) - diff файлов скачанных в 
разное время не нулевой. С обратной связью у них хуже, можно разве что поискать 
людей лично знакомых с сотрудниками nic.ru


From v.tolstov at selfip.ru  Thu Feb 19 13:02:53 2015
From: v.tolstov at selfip.ru (Vasiliy Tolstov)
Date: Thu, 19 Feb 2015 17:02:53 +0400
Subject: offtopic linux routeing question
In-Reply-To: <83180c8c488789e39aa8a3f08f36ce3b.NginxMailingListRussian@forum.nginx.org>
References: <CACaajQvekrUrPJy=DTaacxmdNL4nV809hK4Rzkvcc5Xt0EDZKA@mail.gmail.com>
 <83180c8c488789e39aa8a3f08f36ce3b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CACaajQtJHNuGPnZcL=Ws0eazpCYVPr4Jq=6jGm=HCMgvNZ8MYg@mail.gmail.com>

19 февраля 2015 г., 9:10 пользователь slyab <nginx-forum at nginx.us> написал:
> Ну да, все верно правила цепочки FORWARD обрабатываются после принятия
> решения ядром о дальнейшей маршрутизации. Как делаешь blackhole? Сейчас
> проверил:
> ip rule add blackhole to 192.168.101.0/24
>
> ip rule
> 0:      from all lookup local
> 32765:  from all to 192.168.101.0/24 blackhole
> 32766:  from all lookup main
> 32767:  from all lookup default
>
> Никаких icmp ответов от узла не исходит. Что вообще есть в ip rule?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256718,256779#msg-256779


Да, так работает. А почему ip rule работает как надо, а ip route нет?


-- 
Vasiliy Tolstov,
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

From nginx-forum at nginx.us  Thu Feb 19 13:08:14 2015
From: nginx-forum at nginx.us (slyab)
Date: Thu, 19 Feb 2015 08:08:14 -0500
Subject: offtopic linux routeing question
In-Reply-To: <CACaajQtJHNuGPnZcL=Ws0eazpCYVPr4Jq=6jGm=HCMgvNZ8MYg@mail.gmail.com>
References: <CACaajQtJHNuGPnZcL=Ws0eazpCYVPr4Jq=6jGm=HCMgvNZ8MYg@mail.gmail.com>
Message-ID: <d69597f7dd0e3897ce3e07e32731c60f.NginxMailingListRussian@forum.nginx.org>

Я проверил ip route тоже, работает.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256718,256795#msg-256795


From v.tolstov at selfip.ru  Thu Feb 19 13:09:36 2015
From: v.tolstov at selfip.ru (Vasiliy Tolstov)
Date: Thu, 19 Feb 2015 17:09:36 +0400
Subject: offtopic linux routeing question
In-Reply-To: <d69597f7dd0e3897ce3e07e32731c60f.NginxMailingListRussian@forum.nginx.org>
References: <CACaajQtJHNuGPnZcL=Ws0eazpCYVPr4Jq=6jGm=HCMgvNZ8MYg@mail.gmail.com>
 <d69597f7dd0e3897ce3e07e32731c60f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CACaajQtkN=4wO9_Qp=VnriRrUTE64o5T4bg7YyPwbbRNh08i2Q@mail.gmail.com>

2015-02-19 16:08 GMT+03:00 slyab <nginx-forum at nginx.us>:
> Я проверил ip route тоже, работает.


У меня всегда посылает два пакета icmp в ответ на каждый соурс адрес
(пробовал менять соурс адреса для пакета для проверки).

-- 
Vasiliy Tolstov,
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

From nginx-forum at nginx.us  Thu Feb 19 13:21:14 2015
From: nginx-forum at nginx.us (slyab)
Date: Thu, 19 Feb 2015 08:21:14 -0500
Subject: offtopic linux routeing question
In-Reply-To: <CACaajQtkN=4wO9_Qp=VnriRrUTE64o5T4bg7YyPwbbRNh08i2Q@mail.gmail.com>
References: <CACaajQtkN=4wO9_Qp=VnriRrUTE64o5T4bg7YyPwbbRNh08i2Q@mail.gmail.com>
Message-ID: <a639f180d0d236643cfeebe412bd0c65.NginxMailingListRussian@forum.nginx.org>

Vasiliy Tolstov Wrote:
-------------------------------------------------------
> 2015-02-19 16:08 GMT+03:00 slyab <nginx-forum at nginx.us>:
> > Я проверил ip route тоже, работает.
> 
> 
> У меня всегда посылает два пакета icmp в ответ на каждый соурс адрес
> (пробовал менять соурс адреса для пакета для проверки).
> 
> -- 
> Vasiliy Tolstov,
> e-mail: v.tolstov at selfip.ru
> jabber: vase at selfip.ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

А что он отвечает то? На src что прилетает?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256718,256797#msg-256797


From vbart at nginx.com  Thu Feb 19 13:25:54 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 19 Feb 2015 16:25:54 +0300
Subject: =?UTF-8?B?UmU6INCe0YfQtdGA0LXQtNC4INC6INCx0Y3QutC10L3QtNGDINCyIHByb3h5IG1v?=
 =?UTF-8?B?ZHVsZQ==?=
In-Reply-To: <2a9a1b31f7304ead071f34d69b2642c1.NginxMailingListRussian@forum.nginx.org>
References: <2a9a1b31f7304ead071f34d69b2642c1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1480339.FCTLyYNuQj@vbart-workstation>

On Thursday 19 February 2015 04:20:01 dwow wrote:
> И снова здравствуйте!
> Такой вопрос.
> Nginx.  Запросы с него проксируются на какой-то бэкенд. Можно ли настроить
> nginx так, чтобы не создавать/регулировать нагрузку на бэкенд, например, не
> больше 3-х одновременных запросов? Чтобы создавалось что-то наподобие
> очереди запросов на обработку бекендом?
> Спасибо!
> 

Можно в nginx plus: http://nginx.org/r/queue/ru

--
Валентин Бартенев

From andrey at kopeyko.ru  Thu Feb 19 20:21:25 2015
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Thu, 19 Feb 2015 23:21:25 +0300
Subject: geoip
In-Reply-To: <54E5C21C.8070109@citrin.ru>
References: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
 <54E5C21C.8070109@citrin.ru>
Message-ID: <54E645C5.5020108@kopeyko.ru>

19.02.2015 13:59, Anton Yuzhaninov пишет:
> On 02/19/15 08:30, slyab wrote:
>> Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается?
>> Вопрос
>> в следующем, некоторые сервисы, в частностиwww.2ip.ru  используют этот
>> адрес
>> (по крайней мере мне они сказали туда писать) для геоопределения
>> ip-адресов.
>> Но вот беда - писал в почту, на форму на сайте, и cюда
>> http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.
>
> Данные обновляются (возможно в автоматическом режиме) - diff файлов
> скачанных в разное время не нулевой. С обратной связью у них хуже, можно
> разве что поискать людей лично знакомых с сотрудниками nic.ru

Да, напишите на info at nic.ru или даже позвоните им голосом - думаю, 
отреагируют.

Как бывший сотрудник Ру-Центра, попробую ткнуть в эту проблему кого-либо 
из старых коллег... Но без гарантий.




-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From andrey at kopeyko.ru  Thu Feb 19 22:18:08 2015
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Fri, 20 Feb 2015 01:18:08 +0300
Subject: geoip
In-Reply-To: <54E645C5.5020108@kopeyko.ru>
References: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
 <54E5C21C.8070109@citrin.ru> <54E645C5.5020108@kopeyko.ru>
Message-ID: <54E66120.6050806@kopeyko.ru>

19.02.2015 23:21, Andrey Kopeyko пишет:
> 19.02.2015 13:59, Anton Yuzhaninov пишет:
>> On 02/19/15 08:30, slyab wrote:
>>> Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается?
>>> Вопрос
>>> в следующем, некоторые сервисы, в частностиwww.2ip.ru  используют этот
>>> адрес
>>> (по крайней мере мне они сказали туда писать) для геоопределения
>>> ip-адресов.
>>> Но вот беда - писал в почту, на форму на сайте, и cюда
>>> http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.
>>
>> Данные обновляются (возможно в автоматическом режиме) - diff файлов
>> скачанных в разное время не нулевой. С обратной связью у них хуже, можно
>> разве что поискать людей лично знакомых с сотрудниками nic.ru
>
> Да, напишите на info at nic.ru или даже позвоните им голосом - думаю,
> отреагируют.
>
> Как бывший сотрудник Ру-Центра, попробую ткнуть в эту проблему кого-либо
> из старых коллег... Но без гарантий.

Коллеги отозвались в ФБ - но не могут идентифицировать ваш запрос. 
Помогите им - 
https://www.facebook.com/andrey.a.kopeyko/posts/543147882491684

>


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Fri Feb 20 02:52:27 2015
From: nginx-forum at nginx.us (slyab)
Date: Thu, 19 Feb 2015 21:52:27 -0500
Subject: geoip
In-Reply-To: <54E66120.6050806@kopeyko.ru>
References: <54E66120.6050806@kopeyko.ru>
Message-ID: <1818e321d995bce15731ffc29e2965b2.NginxMailingListRussian@forum.nginx.org>

> Коллеги отозвались в ФБ - но не могут идентифицировать ваш запрос. 
> Помогите им - 
> https://www.facebook.com/andrey.a.kopeyko/posts/543147882491684
Благодарю, в этом посте коментировать не могу (в ФБ не очень разюираюсь),
написал лично тому, кто отозвался.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256777,256827#msg-256827


From nginx-forum at nginx.us  Fri Feb 20 05:30:28 2015
From: nginx-forum at nginx.us (slyab)
Date: Fri, 20 Feb 2015 00:30:28 -0500
Subject: geoip
In-Reply-To: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
References: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <6bf2bce0aba8dbd22dddd527133c94e8.NginxMailingListRussian@forum.nginx.org>

Да, забыл добавить,  здесь
http://blog.ipgeobase.ru/?p=7#comments

мой коментарий не виден, потому что он находится в статусе:
Your comment is awaiting moderation.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256777,256831#msg-256831


From andrey at kopeyko.ru  Fri Feb 20 09:42:42 2015
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Fri, 20 Feb 2015 12:42:42 +0300
Subject: geoip
In-Reply-To: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
References: <0268b691f04f9195c628ba54d4855d1b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54E70192.2010801@kopeyko.ru>

19.02.2015 08:30, slyab пишет:
> Приветствую, вопрос не по nginx, но посоветовали сюда обратиться. Поэтому
> сразу извиняюсь за оффтоп.
>
> Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается? Вопрос
> в следующем, некоторые сервисы, в частности www.2ip.ru используют этот адрес
> (по крайней мере мне они сказали туда писать) для геоопределения ip-адресов.
> Но вот беда - писал в почту, на форму на сайте, и cюда
> http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.

У меня для вас плохие новости ;-(

По агентурным сведениям, весь отдельчик, который занимался в том числе и 
ipgeobase.ru, поувольняли... Т.е. просто некому реагировать на ваши 
обращения.


>


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Fri Feb 20 10:05:53 2015
From: nginx-forum at nginx.us (slyab)
Date: Fri, 20 Feb 2015 05:05:53 -0500
Subject: geoip
In-Reply-To: <54E70192.2010801@kopeyko.ru>
References: <54E70192.2010801@kopeyko.ru>
Message-ID: <ee9b36b67802f5e1867cb63f3f8aa191.NginxMailingListRussian@forum.nginx.org>

> 
> У меня для вас плохие новости ;-(
> 
> По агентурным сведениям, весь отдельчик, который занимался в том числе
> и 
> ipgeobase.ru, поувольняли... Т.е. просто некому реагировать на ваши 
> обращения.


Благодарю, примерно так я и предполагал...

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256777,256836#msg-256836


From nginx-forum at nginx.us  Wed Feb 25 07:21:04 2015
From: nginx-forum at nginx.us (akam)
Date: Wed, 25 Feb 2015 02:21:04 -0500
Subject: nginx proxy
Message-ID: <1c51ebba9f1b48d67397428dc469c900.NginxMailingListRussian@forum.nginx.org>

Здравствуйте,

хочу сделать реверс прокси для видео камеры, все получается, если
проксировать с location /:
server {
  listen *:80;
  server_name video.mysite.local;
}
location / {
  proxy_pass http://camera-ip/;
 ....
}
при этом браузер перекидывает на http:/video.mysite.local/eng/index.cgi
(редирект на веб интерфейсе камеры) и все прекрасно открывается...


Но если я сделаю так:
location / {
  root /var/www/......
 ....
}
location /camera1 {
  proxy_pass http://camera-ip/;
 ....
}
то браузер перекидывает на http:///video.mysite.local/eng/index.html

и nginx пытается искать папку eng у себя в /var/www и естественно не
находит

Можно ли сделать чтобы nginx просто отдавал результат запроса, а не
переадресовывал клиента? Или может это как то инчае делается? Заранее
спасибо!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256898,256898#msg-256898


From serp256 at gmail.com  Wed Feb 25 11:15:47 2015
From: serp256 at gmail.com (SerP)
Date: Wed, 25 Feb 2015 15:15:47 +0400
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzRiyDRgSBkZWZsYXRlINC+0YLQstC10YLQsNC80Lg=?=
Message-ID: <CAHgca+_eyGJeHDOxrHp-v-XXdOmhXqXNo2nuf7TH_BDEKPRqCg@mail.gmail.com>

Здравствуйте.
Недавно столкнулись с проблемой, никак не можем понять в чем дело.
Может быть у кого-нить возникнут мысли, куда можно еще посмотреть.

Приложение - игра на flash. Делает запросы на nginx.
nginx прокисрует их, на наш http демон, с игровой логикой.
И вот недавно,  где с 10го февраля, пользователи стали жаловаться на
"ошибку 200" :-), это наше кодовое название проблемы.
Суть в том, что флеш не дочитывает ответ до конца, браузер ему сообщает что
"Stream error" и данные не полные, http статус 200.
В access логе, мы видим, что ответ был отдан, но не до конца.
Такие ошибки есть всегда - "плохой интернет". Но вот это стало возникать у
большого кол-ва пользователей с "хорошим" интернетом.
Мы выяснили, что когда мы отключаем в ngnix deflate (gzip off) ответов, то
ситуация нормализуется.
Данные в ответе наши бинарные. Content-type: application/octet-stream
Настройки nginx:

 tcp_nodelay     on;
 gzip  on;
 gzip_comp_level 6;
 gzip_min_length 10K;
 gzip_types *;
 gzip_static      on;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150225/e3c3c220/attachment.html>

From nginx-forum at nginx.us  Wed Feb 25 13:13:16 2015
From: nginx-forum at nginx.us (xaleks)
Date: Wed, 25 Feb 2015 08:13:16 -0500
Subject: nginx redirect
Message-ID: <01356e7afbd801050aad0435bcca41d6.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, уважаемые знатоки.
Помогите с решением задачи, пожалуйста.
Работает nginx в связке с apache (+ еще задействован tomcat)
Суть:

Есть в .htaccess сайта такая схема

RewriteEngine On
RewriteCond ${lowercase:%{HTTP_HOST}} ^(.*)\.mydomain\.com$
RewriteRule ^(.*)$ index.php?partner=%1 [NC,L,PT]

это сделано для того, чтобы при запросе типа

anyvalue.mydomain.com 
обрабатывался запрос 
http://anyvalue.mydomain.com//index.php?partner=anyvalue

Возможно ли организовать такой финт средствами nginx без приминения
.htaccess?
Спасибо за любые ответы!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256900,256900#msg-256900


From mdounin at mdounin.ru  Wed Feb 25 13:51:21 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 25 Feb 2015 16:51:21 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgZGVmbGF0ZSDQvtGC0LLQtdGC0LDQvNC4?=
In-Reply-To: <CAHgca+_eyGJeHDOxrHp-v-XXdOmhXqXNo2nuf7TH_BDEKPRqCg@mail.gmail.com>
References: <CAHgca+_eyGJeHDOxrHp-v-XXdOmhXqXNo2nuf7TH_BDEKPRqCg@mail.gmail.com>
Message-ID: <20150225135121.GG19012@mdounin.ru>

Hello!

On Wed, Feb 25, 2015 at 03:15:47PM +0400, SerP wrote:

> Здравствуйте.
> Недавно столкнулись с проблемой, никак не можем понять в чем дело.
> Может быть у кого-нить возникнут мысли, куда можно еще посмотреть.
> 
> Приложение - игра на flash. Делает запросы на nginx.
> nginx прокисрует их, на наш http демон, с игровой логикой.
> И вот недавно,  где с 10го февраля, пользователи стали жаловаться на
> "ошибку 200" :-), это наше кодовое название проблемы.
> Суть в том, что флеш не дочитывает ответ до конца, браузер ему сообщает что
> "Stream error" и данные не полные, http статус 200.
> В access логе, мы видим, что ответ был отдан, но не до конца.
> Такие ошибки есть всегда - "плохой интернет". Но вот это стало возникать у
> большого кол-ва пользователей с "хорошим" интернетом.
> Мы выяснили, что когда мы отключаем в ngnix deflate (gzip off) ответов, то
> ситуация нормализуется.
> Данные в ответе наши бинарные. Content-type: application/octet-stream
> Настройки nginx:

Не во всех случаях gzip одинаково полезен.  Проблемы могут быть, 
например, если клиентская часть некорректно работает с 
gzip'ом.  Или же - некорректно работает с ответами, использующими 
"Transfer-Encoding: chunked" (можно попробовать явно выключить,
см. http://nginx.org/r/chunked_transfer_encoding/ru).  Или то же 
самое, но не в приложении, а в каком-нибудь антивирусе на 
компьютере клиента.

-- 
Maxim Dounin
http://nginx.org/


From jd at jdwuzhere.ru  Wed Feb 25 13:52:42 2015
From: jd at jdwuzhere.ru (Vladimir Sopot)
Date: Wed, 25 Feb 2015 16:52:42 +0300
Subject: nginx redirect
In-Reply-To: <01356e7afbd801050aad0435bcca41d6.NginxMailingListRussian@forum.nginx.org>
References: <01356e7afbd801050aad0435bcca41d6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <65DF5447-40AF-4CC4-92B6-6E72221CBEB0@jdwuzhere.ru>

server {
	server_name (.+).mydomain.com;
	location / {
		return 302 http://$1.mydomain.com//index.php?partner=$1;
		}
	}

> On 25 Feb 2015, at 16:13, xaleks <nginx-forum at nginx.us> wrote:
> 
> Здравствуйте, уважаемые знатоки.
> Помогите с решением задачи, пожалуйста.
> Работает nginx в связке с apache (+ еще задействован tomcat)
> Суть:
> 
> Есть в .htaccess сайта такая схема
> 
> RewriteEngine On
> RewriteCond ${lowercase:%{HTTP_HOST}} ^(.*)\.mydomain\.com$
> RewriteRule ^(.*)$ index.php?partner=%1 [NC,L,PT]
> 
> это сделано для того, чтобы при запросе типа
> 
> anyvalue.mydomain.com 
> обрабатывался запрос 
> http://anyvalue.mydomain.com//index.php?partner=anyvalue
> 
> Возможно ли организовать такой финт средствами nginx без приминения
> .htaccess?
> Спасибо за любые ответы!
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256900,256900#msg-256900
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From mdounin at mdounin.ru  Wed Feb 25 14:21:06 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 25 Feb 2015 17:21:06 +0300
Subject: nginx proxy
In-Reply-To: <1c51ebba9f1b48d67397428dc469c900.NginxMailingListRussian@forum.nginx.org>
References: <1c51ebba9f1b48d67397428dc469c900.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150225142106.GH19012@mdounin.ru>

Hello!

On Wed, Feb 25, 2015 at 02:21:04AM -0500, akam wrote:

> Здравствуйте,
> 
> хочу сделать реверс прокси для видео камеры, все получается, если
> проксировать с location /:
> server {
>   listen *:80;
>   server_name video.mysite.local;
> }
> location / {
>   proxy_pass http://camera-ip/;
>  ....
> }
> при этом браузер перекидывает на http:/video.mysite.local/eng/index.cgi
> (редирект на веб интерфейсе камеры) и все прекрасно открывается...
> 
> 
> Но если я сделаю так:
> location / {
>   root /var/www/......
>  ....
> }
> location /camera1 {
>   proxy_pass http://camera-ip/;
>  ....
> }
> то браузер перекидывает на http:///video.mysite.local/eng/index.html
> 
> и nginx пытается искать папку eng у себя в /var/www и естественно не
> находит
> 
> Можно ли сделать чтобы nginx просто отдавал результат запроса, а не
> переадресовывал клиента? Или может это как то инчае делается? Заранее
> спасибо!

Клиента переадресовывает, скорее всего, не nginx, а ваша камера.  
В большинстве случаев - помогает использование директивы 
proxy_redirect, см. http://nginx.org/r/proxy_redirect/ru.

-- 
Maxim Dounin
http://nginx.org/


From motienko at gmail.com  Wed Feb 25 14:41:43 2015
From: motienko at gmail.com (Oleg Motienko)
Date: Wed, 25 Feb 2015 18:41:43 +0400
Subject: =?UTF-8?B?0LPQtdC+LdCy0LXQsdGB0LXRgNCy0LjRgSDQvdCwIG5naW54INCx0LXQtyDQtNCy?=
 =?UTF-8?B?0LjQttC60LAg0LHQsNC30Ysg0LTQsNC90L3Ri9GFINC4INCx0LXQtyDQv9GA?=
 =?UTF-8?B?0L7Qs9GA0LDQvNC80LjRgNC+0LLQsNC90LjRjw==?=
Message-ID: <CAAtQP1x9mDoFgZ50mY=nuKCB2u3O3wDiDaukQ+pFgBX0zWFBTQ@mail.gmail.com>

Привет.

Может кому интересна будет наша поделка

http://habrahabr.ru/company/nodasoft/blog/251463/


-- 
Regards,
Oleg

From nginx-forum at nginx.us  Wed Feb 25 15:43:07 2015
From: nginx-forum at nginx.us (Romano)
Date: Wed, 25 Feb 2015 10:43:07 -0500
Subject: =?UTF-8?B?0JbRg9GA0L3QsNC7INC30LDQv9GA0L7RgdC+0LIg0LTQu9GPINC60LXRiNC40YA=?=
 =?UTF-8?B?0L7QstCw0L3QvdGL0YUg0YHRgtGA0LDQvdC40YY=?=
Message-ID: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>

Здравствуйте! На сервере настроено кэширование Nginx. До того как запрос
будет кеширован, он виден в журнале посещений access_log. Когда сервер
выдает кэшированные страницы, то в журнале посещений ничего не
регистрируется, поскольку не доходит до директивы задания журнала. Как
отслеживать такие запросы?

Спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256915,256915#msg-256915


From semenukha at gmail.com  Wed Feb 25 16:16:17 2015
From: semenukha at gmail.com (Styopa Semenukha)
Date: Wed, 25 Feb 2015 11:16:17 -0500
Subject: nginx redirect
In-Reply-To: <65DF5447-40AF-4CC4-92B6-6E72221CBEB0@jdwuzhere.ru>
References: <01356e7afbd801050aad0435bcca41d6.NginxMailingListRussian@forum.nginx.org>
 <65DF5447-40AF-4CC4-92B6-6E72221CBEB0@jdwuzhere.ru>
Message-ID: <94993855.16ElcCAK37@tornado>

Пропустили тильду в server_name:
server_name ~(.+).mydomain.com;

On Wednesday, February 25, 2015 04:52:42 PM Vladimir Sopot wrote:
> server {
> 	server_name (.+).mydomain.com;
> 	location / {
> 		return 302 http://$1.mydomain.com//index.php?partner=$1;
> 		}
> 	}
> 
> > On 25 Feb 2015, at 16:13, xaleks <nginx-forum at nginx.us> wrote:
> > 
> > Здравствуйте, уважаемые знатоки.
> > Помогите с решением задачи, пожалуйста.
> > Работает nginx в связке с apache (+ еще задействован tomcat)
> > Суть:
> > 
> > Есть в .htaccess сайта такая схема
> > 
> > RewriteEngine On
> > RewriteCond ${lowercase:%{HTTP_HOST}} ^(.*)\.mydomain\.com$
> > RewriteRule ^(.*)$ index.php?partner=%1 [NC,L,PT]
> > 
> > это сделано для того, чтобы при запросе типа
> > 
> > anyvalue.mydomain.com
> > обрабатывался запрос
> > http://anyvalue.mydomain.com//index.php?partner=anyvalue
> > 
> > Возможно ли организовать такой финт средствами nginx без приминения
> > .htaccess?
> > Спасибо за любые ответы!
> > 
> > Posted at Nginx Forum:
> > http://forum.nginx.org/read.php?21,256900,256900#msg-256900
> > 
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-- 
Best regards,
Styopa Semenukha.

From nginx-forum at nginx.us  Wed Feb 25 17:29:08 2015
From: nginx-forum at nginx.us (akam)
Date: Wed, 25 Feb 2015 12:29:08 -0500
Subject: nginx proxy
In-Reply-To: <20150225142106.GH19012@mdounin.ru>
References: <20150225142106.GH19012@mdounin.ru>
Message-ID: <b4d003ca51d08cf77160c6901b97f846.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
> Клиента переадресовывает, скорее всего, не nginx, а ваша камера.  
> В большинстве случаев - помогает использование директивы 
> proxy_redirect, см. http://nginx.org/r/proxy_redirect/ru.
> 
> -- 
> Maxim Dounin
> http://nginx.org/
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Да я так и написал, видимо плохо объясняю :(
Спасибо за подсказку, буду читать про proxy_redirect

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256898,256918#msg-256918


From annulen at yandex.ru  Wed Feb 25 17:28:11 2015
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 25 Feb 2015 20:28:11 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgZGVmbGF0ZSDQvtGC0LLQtdGC0LDQvNC4?=
In-Reply-To: <CAHgca+_eyGJeHDOxrHp-v-XXdOmhXqXNo2nuf7TH_BDEKPRqCg@mail.gmail.com>
References: <CAHgca+_eyGJeHDOxrHp-v-XXdOmhXqXNo2nuf7TH_BDEKPRqCg@mail.gmail.com>
Message-ID: <3240471424885291@web26j.yandex.ru>



25.02.2015, 14:16, "SerP" <serp256 at gmail.com>:
> Здравствуйте.
> Недавно столкнулись с проблемой, никак не можем понять в чем дело.
> Может быть у кого-нить возникнут мысли, куда можно еще посмотреть.
>
> Приложение - игра на flash. Делает запросы на nginx.
> nginx прокисрует их, на наш http демон, с игровой логикой.
> И вот недавно,  где с 10го февраля, пользователи стали жаловаться на "ошибку 200" :-), это наше кодовое название проблемы.
> Суть в том, что флеш не дочитывает ответ до конца, браузер ему сообщает что "Stream error" и данные не полные, http статус 200.
> В access логе, мы видим, что ответ был отдан, но не до конца.
> Такие ошибки есть всегда - "плохой интернет". Но вот это стало возникать у большого кол-ва пользователей с "хорошим" интернетом.
> Мы выяснили, что когда мы отключаем в ngnix deflate (gzip off) ответов, то ситуация нормализуется.
> Данные в ответе наши бинарные. Content-type: application/octet-stream
> Настройки nginx:
>
>  tcp_nodelay     on;
>  gzip  on;
>  gzip_comp_level 6;
>  gzip_min_length 10K;
>  gzip_types *;
>  gzip_static      on;

Ради инетереса стоит проверить, какой выигрыш дает gzip уровня 6 на типовом ответе сервера. Бинарные данные обычно сжимаются хуже, чем текст, и может оказаться, что выигрыш не оправдывает затрат на сжатие/распаковку.

-- 
Regards,
Konstantin


From postmaster at softsearch.ru  Wed Feb 25 17:49:55 2015
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Wed, 25 Feb 2015 20:49:55 +0300
Subject: =?UTF-8?B?UmU6INCW0YPRgNC90LDQuyDQt9Cw0L/RgNC+0YHQvtCyINC00LvRjyDQutC10Yg=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90L3Ri9GFINGB0YLRgNCw0L3QuNGG?=
In-Reply-To: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
References: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1061959864.20150225204955@softsearch.ru>

Здравствуйте, Romano.

> Здравствуйте!  На  сервере  настроено кэширование Nginx. До того как
> запрос  будет  кеширован,  он  виден в журнале посещений access_log.
> Когда  сервер  выдает  кэшированные страницы, то в журнале посещений
> ничего  не регистрируется, поскольку не доходит до директивы задания
> журнала. Как отслеживать такие запросы?

Надо включить их логирование.

Приведите, пожалуйста, конфиг nginx-а полностью. Так будет проще всего
Вам помочь.

-- 
С уважением,
 Михаил                          mailto:postmaster at softsearch.ru


From nginx-forum at nginx.us  Wed Feb 25 19:37:01 2015
From: nginx-forum at nginx.us (Romano)
Date: Wed, 25 Feb 2015 14:37:01 -0500
Subject: =?UTF-8?B?UmU6INCW0YPRgNC90LDQuyDQt9Cw0L/RgNC+0YHQvtCyINC00LvRjyDQutC10Yg=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90L3Ri9GFINGB0YLRgNCw0L3QuNGG?=
In-Reply-To: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
References: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <901abe3b9a3c5268aafa4254689ca6cf.NginxMailingListRussian@forum.nginx.org>

Я оказался невнимательным, все запросы записываются в журнал, просто
"теряются" среди прочих. Скажите, возможно их как-то разделить по признаку
кэширования? Полагаю можно добавить к директиве access_log условие if, но
какое?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256915,256921#msg-256921


From spuzirev at gmail.com  Wed Feb 25 19:39:29 2015
From: spuzirev at gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCf0YPQt9GL0YDRkdCy?=)
Date: Wed, 25 Feb 2015 23:39:29 +0400
Subject: =?UTF-8?B?UmU6INCW0YPRgNC90LDQuyDQt9Cw0L/RgNC+0YHQvtCyINC00LvRjyDQutC10Yg=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90L3Ri9GFINGB0YLRgNCw0L3QuNGG?=
In-Reply-To: <901abe3b9a3c5268aafa4254689ca6cf.NginxMailingListRussian@forum.nginx.org>
References: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
 <901abe3b9a3c5268aafa4254689ca6cf.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAC+mmMv6nsrqdzaeAGYp2GuBgs3U-dfajY=WXQpOwfaVva5zHA@mail.gmail.com>

Вы можете использовать переменную $upstream_cache_status из upstream-модуля
в access-логе.

25 февраля 2015 г., 22:37 пользователь Romano <nginx-forum at nginx.us>
написал:

> Я оказался невнимательным, все запросы записываются в журнал, просто
> "теряются" среди прочих. Скажите, возможно их как-то разделить по признаку
> кэширования? Полагаю можно добавить к директиве access_log условие if, но
> какое?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,256915,256921#msg-256921
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
С уважением,
Сергей Пузырёв
тел.: +7-916-980-70-45
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150225/0c1dd673/attachment.html>

From motienko at gmail.com  Wed Feb 25 20:58:54 2015
From: motienko at gmail.com (Oleg Motienko)
Date: Thu, 26 Feb 2015 00:58:54 +0400
Subject: geoip
In-Reply-To: <ee9b36b67802f5e1867cb63f3f8aa191.NginxMailingListRussian@forum.nginx.org>
References: <54E70192.2010801@kopeyko.ru>
 <ee9b36b67802f5e1867cb63f3f8aa191.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAAtQP1xa8G-CH8uew8yYdi6ob1KtUp2YW2NnLV_rF_kjrVw1eg@mail.gmail.com>

http://habrahabr.ru/company/nodasoft/blog/251463/ мы сделали замену xml сервису.
Базы залиты последние. Если с обновлением баз будет плохо, поищем
другие источники.


2015-02-20 13:05 GMT+03:00 slyab <nginx-forum at nginx.us>:

>
> Благодарю, примерно так я и предполагал...


-- 
Regards,
Oleg

From danila at shtan.ru  Thu Feb 26 06:29:40 2015
From: danila at shtan.ru (Danila Shtan)
Date: Thu, 26 Feb 2015 12:29:40 +0600
Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0YDQtdC20LXRgiBQT1NUINC00L4gNjQwMDAg0LHQsNC50YIg?=
 =?UTF-8?B?0L/RgNC4INC/0LXRgNC10YXQvtC00LUg0LIgbmV4dCB1cHN0cmVhbQ==?=
In-Reply-To: <CALUn_U4b+e-_PYVi5yQbW52eL0A7OTXtagOmNrJBX0Wi1wmQkA@mail.gmail.com>
References: <CALUn_U6w7FV6r5dpQtiKfh_bpjA0xsEwDuScxfAHD+M892WtGg@mail.gmail.com>
 <5335028.EeENnP5ACu@vbart-laptop>
 <CALUn_U4b+e-_PYVi5yQbW52eL0A7OTXtagOmNrJBX0Wi1wmQkA@mail.gmail.com>
Message-ID: <CALUn_U6Jr2zQejuT3FQnq4HNJ-n5X-We8U7wqCOjMT-YQr6Vsg@mail.gmail.com>

Добрый день.

Новостей не появилось, да?

Д.

2014-08-27 8:37 GMT+06:00 Danila Shtan <danila at shtan.ru>:

> Спасибо, Валентин.
>
> BTW, я чего-то не понимаю, или баг действительно довольно тяжелый? В моем
> случае он обозначает, что для ряда запросов вне зависимости от количества
> бэкендов и их загруженности нужно добиваться, чтобы запрос всегда мог
> обработать первый бэкенд. Это немного обескураживает.
>
> Д.
>
>
> 2014-08-27 2:37 GMT+06:00 Валентин Бартенев <vbart at nginx.com>:
>
>> On Tuesday 26 August 2014 23:35:06 Danila Shtan wrote:
>> > Полдня сегодня ловил баг, который оказался уже описан в рассылке
>> > (англоязычной, правда) ?
>> > http://forum.nginx.org/read.php?29,250947,251007#msg-251007
>> >
>> > Суть в том, что в случае проблем на первом бэкенде, запрос
>> перепосылается
>> > на второй, но содержимое POST оказывается равным ровно 64000.
>> >
>> > Насколько я понимаю, в виде "try this patch" решение пробегало, а есть
>> > какое-то понимание, когда оно добежит до stable?
>>
>> Увы, предложенный патч не понравилось ответственному и не был одобрен.
>> Придумать другое решение руки тогда не дошли.  Посмотрю на досуге, что
>> ещё можно с этим сделать.  А пока можете использовать предложенный патч.
>>
>> --
>> Валентин Бартенев
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150226/737fefe7/attachment.html>

From nginx-forum at nginx.us  Thu Feb 26 07:47:09 2015
From: nginx-forum at nginx.us (Romano)
Date: Thu, 26 Feb 2015 02:47:09 -0500
Subject: =?UTF-8?B?UmU6INCW0YPRgNC90LDQuyDQt9Cw0L/RgNC+0YHQvtCyINC00LvRjyDQutC10Yg=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90L3Ri9GFINGB0YLRgNCw0L3QuNGG?=
In-Reply-To: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
References: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <f767e34806f2913de1fc10488c932640.NginxMailingListRussian@forum.nginx.org>

Ребята, спасибо за помощь! На одной версии Nginx настроил, а на старых
выходит каменный цветок. Директива access_log условия не поддерживает, а
оператор if не позволяет разместить директиву в теле условия. 

Можно что-то сделать без обновления на более новые версии Nginx?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256915,256925#msg-256925


From mva at mva.name  Thu Feb 26 07:50:49 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 26 Feb 2015 13:50:49 +0600
Subject: =?UTF-8?B?UmU6INCW0YPRgNC90LDQuyDQt9Cw0L/RgNC+0YHQvtCyINC00LvRjyDQutC10Yg=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90L3Ri9GFINGB0YLRgNCw0L3QuNGG?=
In-Reply-To: <f767e34806f2913de1fc10488c932640.NginxMailingListRussian@forum.nginx.org>
References: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
 <f767e34806f2913de1fc10488c932640.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7321369.sDeAKqxY3r@note>

В письме от Чт, 26 февраля 2015 02:47:09 пользователь Romano написал:
> Можно что-то сделать без обновления на более новые версии Nginx?
> 

Всё же лучше обновиться. Security issue, там, вот это вот всё...

-- 
Best regards,
mva
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150226/3986c4dd/attachment-0001.bin>

From nginx-forum at nginx.us  Thu Feb 26 08:28:28 2015
From: nginx-forum at nginx.us (Romano)
Date: Thu, 26 Feb 2015 03:28:28 -0500
Subject: =?UTF-8?B?UmU6INCW0YPRgNC90LDQuyDQt9Cw0L/RgNC+0YHQvtCyINC00LvRjyDQutC10Yg=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90L3Ri9GFINGB0YLRgNCw0L3QuNGG?=
In-Reply-To: <7321369.sDeAKqxY3r@note>
References: <7321369.sDeAKqxY3r@note>
Message-ID: <8d3acdc9011ea5dcc82c3096601e24bf.NginxMailingListRussian@forum.nginx.org>

Согласен, но в моём случае "выше" Nginx стоит дополнительное ПО, в котором
учтены критические уязвимости старых версий (каскадный прокси). Хотелось бы
настроить конфигурацию текущих низовых систем, без обновлений.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256915,256927#msg-256927


From vadim.lazovskiy at gmail.com  Thu Feb 26 08:44:31 2015
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Thu, 26 Feb 2015 12:44:31 +0400
Subject: =?UTF-8?B?UmU6INCW0YPRgNC90LDQuyDQt9Cw0L/RgNC+0YHQvtCyINC00LvRjyDQutC10Yg=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90L3Ri9GFINGB0YLRgNCw0L3QuNGG?=
In-Reply-To: <f767e34806f2913de1fc10488c932640.NginxMailingListRussian@forum.nginx.org>
References: <6db80de44d3b7b7cfce16fed596605b6.NginxMailingListRussian@forum.nginx.org>
 <f767e34806f2913de1fc10488c932640.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAL-L5YD2h9Bk1CabeHqH4cwD9dDryUf1AAGVyofsJA-cPFJMnw@mail.gmail.com>

Здравствуйте.

Можно попробовать сделать (не проверял):

map $upstream_cache_status $log_name {
   HIT hit;
   default miss;
}

access_log /var/log/nginx/domain.name-access.$log_name.log;

http://nginx.org/ru/docs/http/ngx_http_log_module.html#access_log
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables

Даже если такая конструкция заработает, все же лучше обновиться до 1.7

26 февраля 2015 г., 10:47 пользователь Romano <nginx-forum at nginx.us> написал:
> Ребята, спасибо за помощь! На одной версии Nginx настроил, а на старых
> выходит каменный цветок. Директива access_log условия не поддерживает, а
> оператор if не позволяет разместить директиву в теле условия.
>
> Можно что-то сделать без обновления на более новые версии Nginx?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256915,256925#msg-256925
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
WBR,
Vadim Lazovskiy

From mdounin at mdounin.ru  Thu Feb 26 12:01:49 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 26 Feb 2015 15:01:49 +0300
Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0YDQtdC20LXRgiBQT1NUINC00L4gNjQwMDAg0LHQsNC50YIg?=
 =?UTF-8?B?0L/RgNC4INC/0LXRgNC10YXQvtC00LUg0LIgbmV4dCB1cHN0cmVhbQ==?=
In-Reply-To: <CALUn_U6Jr2zQejuT3FQnq4HNJ-n5X-We8U7wqCOjMT-YQr6Vsg@mail.gmail.com>
References: <CALUn_U6w7FV6r5dpQtiKfh_bpjA0xsEwDuScxfAHD+M892WtGg@mail.gmail.com>
 <5335028.EeENnP5ACu@vbart-laptop>
 <CALUn_U4b+e-_PYVi5yQbW52eL0A7OTXtagOmNrJBX0Wi1wmQkA@mail.gmail.com>
 <CALUn_U6Jr2zQejuT3FQnq4HNJ-n5X-We8U7wqCOjMT-YQr6Vsg@mail.gmail.com>
Message-ID: <20150226120149.GQ19012@mdounin.ru>

Hello!

On Thu, Feb 26, 2015 at 12:29:40PM +0600, Danila Shtan wrote:

> Добрый день.
> 
> Новостей не появилось, да?

Изменения в nginx 1.7.6, 30.09.2014:

    *) Исправление: при повторной отправке FastCGI-запроса на бэкенд тело
       запроса могло передаваться неправильно.

http://nginx.org/ru/CHANGES.ru

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Sat Feb 28 09:10:43 2015
From: nginx-forum at nginx.us (ingtar)
Date: Sat, 28 Feb 2015 04:10:43 -0500
Subject: Nginx + Android + ssl = 400
Message-ID: <ee44b2106dbf72070902ca1400035278.NginxMailingListRussian@forum.nginx.org>

Доброго дня! Столкнулся с непонятной проблемой, не могу даже локализовать.
Настраиваем на фронте доступ к сайту по ssl сертификатам (Публикуем Exchange
и как фронтенд - nginx)
Соответственно доступ с мобильных устройств идет на локейшен
Microsoft-Server-ActiveSync. Сгенерировали CA, клиенский сертификат и
установили его на Андроид и на iPad. На втором работает, на первом дает
ошибку 400 - обращение без сертификата.
Как смог повторил состав ПО на тестовом фронте - работает и на Андройде. 
Причем что необычно - запросы от андройда на проблемном фронте падают не в
лог для этого локейшена , а в основной лог для этого сайта (падают в
exchange.example.com_main_access.log, а не в
exchange.example.com_sync_access.log, листинг конфига ниже)
Доступ через web - локейшен owa работает без замечаний и корректно на всех
устройствах
Все указывает на проблему софта, но я теряюсь в догадках, кто может мне
помочь. Решил попытать счастья тут:)
Если вдруг вы сталкивались с чем-то подобным - помогите, пожалуйста.

Версия nginx:
nginx version: nginx/1.6.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) 
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/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/cache/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/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
--with-http_ssl_module --with-http_realip_module --with-http_addition_module
--with-http_sub_module --with-http_dav_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_random_index_module
--with-http_secure_link_module --with-http_stub_status_module
--with-http_auth_request_module --with-file-aio --add-module=ngx_devel_kit
--add-module=set-misc-nginx-module --add-module=echo-nginx-module
--with-http_spdy_module --with-cc-opt='-O2 -g'

CentOS release 6.3
openssl-1.0.1e-30.el6_6.5.x86_64

Конфиг nginx для данного сайта:
server 
{
       listen         :80;
       server_name    exchange.example.com;
       return         301 https://$server_name$request_uri;
}

server
{
	server_name exchange.example.com;
	listen *:443 ssl;

	ssl on;
       ssl_certificate /etc/pki/tls/certs/example.com_full.crt;
       ssl_certificate_key /etc/pki/tls/example.com.key;


	ssl_protocols        SSLv3 TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers          ALL;
	ssl_client_certificate /etc/nginx/exchange_ssl/ssl/ca.crt;
	ssl_verify_client on;

	keepalive_timeout 70;
	fastcgi_param SSL_VERIFIED $ssl_client_verify;
	fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
	fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
	fastcgi_param SSL_DN $ssl_client_s_dn;

# Set global proxy settings
        proxy_read_timeout      360;
        proxy_connect_timeout   360; 
        proxy_pass_header       Date;
        proxy_pass_header       Server;
 
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Accept-Encoding "";
 
        proxy_buffers 8 32k;
        proxy_buffer_size 64k;
        large_client_header_buffers 8 32k;

	location / {
               return 301 https://$server_name/owa;
		proxy_buffer_size 32k;
        }

        location ~* ^/owa { 
               proxy_buffer_size 32k;
               error_log /var/log/nginx/exchange.example.com_owa_error.log
;
               access_log /var/log/nginx/exchange.example.com_owa_access.log
exchange;
	       proxy_pass https://exchange; 
	}

        location ~* ^/Microsoft-Server-ActiveSync(.*) { 
		proxy_buffer_size 32k;
	        proxy_set_header Host $http_host;
	        proxy_set_header X-Forwarded-Host $http_host;
	        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	        proxy_set_header X_FORWARDED_PROTO https;
	        proxy_set_header X-Url-Scheme $scheme;
	        proxy_set_header X-Real-IP $remote_addr;

	        error_log /var/log/nginx/exchange.example.com_sync_error.log ;
	        access_log /var/log/nginx/exchange.example.com_sync_access.log
exchange;
	        proxy_pass https://exchange;
	}


        error_log /var/log/nginx/exchange.example.com_main_error.log ;
        access_log /var/log/nginx/exchange.example.com_main_access.log
exchange;

}

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256951,256951#msg-256951


From andrey at kopeyko.ru  Sat Feb 28 11:40:26 2015
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Sat, 28 Feb 2015 14:40:26 +0300
Subject: Nginx + Android + ssl = 400
In-Reply-To: <ee44b2106dbf72070902ca1400035278.NginxMailingListRussian@forum.nginx.org>
References: <ee44b2106dbf72070902ca1400035278.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54F1A92A.4000808@kopeyko.ru>

28.02.2015 12:10, ingtar пишет:
> Доброго дня! Столкнулся с непонятной проблемой, не могу даже локализовать.
> Настраиваем на фронте доступ к сайту по ssl сертификатам (Публикуем Exchange
> и как фронтенд - nginx)
> Соответственно доступ с мобильных устройств идет на локейшен
> Microsoft-Server-ActiveSync. Сгенерировали CA, клиенский сертификат и
> установили его на Андроид и на iPad. На втором работает, на первом дает
> ошибку 400 - обращение без сертификата.
> Как смог повторил состав ПО на тестовом фронте - работает и на Андройде.
> Причем что необычно - запросы от андройда на проблемном фронте падают не в
> лог для этого локейшена , а в основной лог для этого сайта (падают в
> exchange.example.com_main_access.log, а не в
> exchange.example.com_sync_access.log, листинг конфига ниже)

По-видимому, вы "не попадаете" в описывающую location регулярку - 
смотрите в логе куда именно он ломится, и корректируйте regexp.

...

>          location ~* ^/Microsoft-Server-ActiveSync(.*) {
> 		proxy_buffer_size 32k;

>


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Sat Feb 28 13:49:06 2015
From: nginx-forum at nginx.us (klimovv)
Date: Sat, 28 Feb 2015 08:49:06 -0500
Subject: =?UTF-8?B?bmdpbnggLSBOZ2lueCB1cmwg0L7RiNC40LHQutCwIDQwNCDQtdGB0LvQuCDQuNC8?=
 =?UTF-8?B?0Y8g0YTQsNC50LvQsCAo0LjQt9C+0LHRgNCw0LbQtdC90LjRjykg0LrQuNGA?=
 =?UTF-8?B?0LjQu9C70LjRhtC10Lk/?=
Message-ID: <9467718381ea8950ce5a6ba5a6c48804.NginxMailingListRussian@forum.nginx.org>

Nginx +php5-fpm wordpress
Все изображения с кириллицей (Пример: "недвижимость2-75x75.jpg") не
отображаются, выдает ошибку 404.
При добавлении новых изображений в базу, все работает нормально.
В чем может быть причина?

Лог:
2015/02/28 12:02:39 [error] 24896#0: *133 open()
"wp-content/uploads/2015/02/Обеденный-комплект-Пилар-75x75.jpg" failed (2:
No such file or directory), request: "GET
/wp-content/uploads/2015/02/%D0%9E%D0%B1%D0%B5%D0%B4%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9-%D0%BA%D0%BE%D0%BC%D0%BF%D0%BB%D0%B5%D0%BA%D1%82-%D0%9F%D0%B8%D0%BB%D0%B0%D1%80-75x75.jpg
HTTP/1.1",

Настройка nginx:
server {
    listen  80;
    
    server_name 111.net www.111.net;

   
    charset utf-8;

    
    access_log  /var/log/nginx/access.log combined;
    error_log   /var/log/nginx/error.log;

   
    root /var/www/111net/data/www/111.net;

   
    gzip on;
    gzip_disable "msie6";
    gzip_static on;
  gzip_comp_level 6;
    gzip_min_length  1100;
    gzip_buffers 16 8k;
    gzip_proxied any;
    gzip_types text/plain application/xml
      application/javascript
      text/css
      text/js
      text/xml
      application/x-javascript
      text/javascript
      application/json
      application/xml+rss;

    
    client_max_body_size            100m;
    client_body_buffer_size         128k;
    client_header_timeout           3m;
    client_body_timeout             3m;
    send_timeout                    3m;
    client_header_buffer_size       1k;
    large_client_header_buffers     4 16k;

   
    location / {
        
        root /var/www/111net/data/www/111.net;

        
        index  index.php index.html index.htm;     

        
        try_files $uri $uri/ @fallback;
    }

    
    location @fallback {
        rewrite  ^(.*)$ /index.php?$args last;
    }

    
    location ~* \.(jpeg|ico|jpg|gif|png|css|js|pdf|txt|tar|gz|wof|csv|zip)
{
        access_log off;
    
        try_files $uri @statics;
        expires 14d;
        add_header Access-Control-Allow-Origin *;
        add_header Cache-Control public;
        root /var/www/111net/data/www/111.net;
    }

    
    location @statics {
        rewrite ^/(\w+)/(.*)$ /$2 break;
        access_log off;
        rewrite_log off;
        expires 14d;
        add_header Cache-Control public;
        add_header Access-Control-Allow-Origin *;
        root /var/www/111net/data/www/111.net;
    }

    
    location ~ \.php$ {
        root /var/www/111net/data/www/111.net;
        proxy_read_timeout 61;
        fastcgi_read_timeout 61;
        try_files $uri $uri/ =404;
        #   Путь до сокета демона PHP-FPM
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }


    location /images/ {
        allow all;
        location ~* \.([pP][hH][pP].?)$ {
            deny all;
        }
    }

   
    location /var/ {
        deny all;
        location ~* \.(js|css|png|jpg|gz)$ {
            allow all;
            expires 1M;
            add_header Cache-Control public;
            add_header Access-Control-Allow-Origin *;
        }
    }
 
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256953,256953#msg-256953


From nginx-forum at nginx.us  Sat Feb 28 14:41:05 2015
From: nginx-forum at nginx.us (ingtar)
Date: Sat, 28 Feb 2015 09:41:05 -0500
Subject: Nginx + Android + ssl = 400
In-Reply-To: <54F1A92A.4000808@kopeyko.ru>
References: <54F1A92A.4000808@kopeyko.ru>
Message-ID: <18730abe0bd52d4e333537563a5a665c.NginxMailingListRussian@forum.nginx.org>

Andrey Kopeyko Wrote:
-------------------------------------------------------

> По-видимому, вы "не попадаете" в описывающую location регулярку - 
> смотрите в логе куда именно он ломится, и корректируйте regexp.


Спасибо, попробую покрутить локейшен.
На момент ошибки в логах вот такой запрос:

exchange.example.com 111.111.11.111 - user at example.com [28/Feb/2015:17:36:19
+0300] "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" 400 246 "-"
"Android/5.0.2-EAS-2.0" "-" upstream - status:- time: -NONE - -
Смущает то, что на iOS все работает и этот же же конфиг на другом сервере
тоже работает.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256951,256954#msg-256954


From andrey at kopeyko.ru  Sat Feb 28 17:19:12 2015
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Sat, 28 Feb 2015 20:19:12 +0300
Subject: Nginx + Android + ssl = 400
In-Reply-To: <18730abe0bd52d4e333537563a5a665c.NginxMailingListRussian@forum.nginx.org>
References: <54F1A92A.4000808@kopeyko.ru>
 <18730abe0bd52d4e333537563a5a665c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54F1F890.7050804@kopeyko.ru>

28.02.2015 17:41, ingtar пишет:
>
> На момент ошибки в логах вот такой запрос:
>
> exchange.example.com 111.111.11.111 - user at example.com [28/Feb/2015:17:36:19
> +0300] "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" 400 246 "-"
> "Android/5.0.2-EAS-2.0" "-" upstream - status:- time: -NONE - -
> Смущает то, что на iOS все работает

Смотрите, что шлёт яблочный клиент - предположу, что таки другое.

И гляньте в error_log - там будут подробности про ошибку.

> и этот же же конфиг на другом сервере тоже работает.

Включите debug на обоих серверах 
(http://nginx.org/ru/docs/debugging_log.html и 
http://nginx.org/ru/docs/ngx_core_module.html#debug_connection), 
сделайте по 1 запросу, и тщательно изучайте\сравнивайте отладочные логи 
- и разница должна вам открыться.


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Sat Feb 28 18:27:22 2015
From: nginx-forum at nginx.us (ingtar)
Date: Sat, 28 Feb 2015 13:27:22 -0500
Subject: Nginx + Android + ssl = 400
In-Reply-To: <54F1F890.7050804@kopeyko.ru>
References: <54F1F890.7050804@kopeyko.ru>
Message-ID: <19d98cf6808c80e79c6af2f9b314c497.NginxMailingListRussian@forum.nginx.org>

В error логах - только такая строчка с debug:
2015/02/28 20:49:35 [info] 20623#0: *178128083 client sent no required SSL
certificate while reading client request headers, client: 123.123.123.123,
server: exchange.example.com, request: "OPTIONS /Microsoft-Server-ActiveSync
HTTP/1.1", host: "exchange.example.com"

Ну и соответственно в access
exchange.example.com 123.123.123.123 - user at example.com
[28/Feb/2015:20:49:35 +0300] "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1"
400 246 "-" "Android/5.0.2-EAS-2.0" "-" upstream - status:- time: - NONE 


На рабочем хосте -
192.168.1.12 192.168.1.22 - user at example.com [28/Feb/2015:21:19:01 +0300]
"OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" 200 0 "-"
"Android/5.0.2-EAS-2.0" "-" upstream 192.168.1.253:443 status:200 time:
0.000 SUCCESS ED45D3CD01EDDB07
/C=RU/ST=Moscow/L=Moscow/O=Company/OU=User/CN=user at example.com/emailAddress=user at example.com

192.168.1.12 192.168.1.22 - user at example.com [28/Feb/2015:21:19:02 +0300]
"POST
/Microsoft-Server-ActiveSync?Cmd=FolderSync&User=user%40example.com&DeviceId=android171621781534095&DeviceType=Android
HTTP/1.1" 200 142 "-" "Android/5.0.2-EAS-2.0" "-" upstream 192.168.1.253:443
status:200 time: 0.300 SUCCESS ED45D3CD01EDDB07
/C=RU/ST=Moscow/L=Moscow/O=Company/OU=User/CN=user at example.com/emailAddress=user at example.com


nginx собран без опции --with-debug, с ним вывод был бы подробнее?
Пересобрать и обновить пока не смогу
Собрать такую же инфу по яблокам так же не выйдет - выходной как-никак :)

Andrey Kopeyko Wrote:
-------------------------------------------------------
> 28.02.2015 17:41, ingtar пишет:
> >
> > На момент ошибки в логах вот такой запрос:
> >
> > exchange.example.com 111.111.11.111 - user at example.com
> [28/Feb/2015:17:36:19
> > +0300] "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" 400 246 "-"
> > "Android/5.0.2-EAS-2.0" "-" upstream - status:- time: -NONE - -
> > Смущает то, что на iOS все работает
> 
> Смотрите, что шлёт яблочный клиент - предположу, что таки другое.
> 
> И гляньте в error_log - там будут подробности про ошибку.
> 
> > и этот же же конфиг на другом сервере тоже работает.
> 
> Включите debug на обоих серверах 
> (http://nginx.org/ru/docs/debugging_log.html и 
> http://nginx.org/ru/docs/ngx_core_module.html#debug_connection), 
> сделайте по 1 запросу, и тщательно изучайте\сравнивайте отладочные
> логи 
> - и разница должна вам открыться.
> 
> 
> -- 
> Best regards,
> Andrey Kopeyko <andrey at kopeyko.ru>
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256951,256958#msg-256958


From andrey at kopeyko.ru  Sat Feb 28 22:01:42 2015
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Sun, 01 Mar 2015 01:01:42 +0300
Subject: Nginx + Android + ssl = 400
In-Reply-To: <19d98cf6808c80e79c6af2f9b314c497.NginxMailingListRussian@forum.nginx.org>
References: <54F1F890.7050804@kopeyko.ru>
 <19d98cf6808c80e79c6af2f9b314c497.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54F23AC6.2020708@kopeyko.ru>

28.02.2015 21:27, ingtar пишет:
> В error логах - только такая строчка с debug:
> 2015/02/28 20:49:35 [info] 20623#0: *178128083 client sent no required SSL
> certificate while reading client request headers,

Вы внимательно прочитали строчку выше? Что она вам говорит?

Мне она говорит - что надо прекращать копать nginx.
Проблема в настройках или в фичах вашего клиента.


P.S.
Предположу, что конфигурация второго вашего nginx отличается отсутствием 
директивы
   	ssl_verify_client on;


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Sat Feb 28 22:19:42 2015
From: nginx-forum at nginx.us (ingtar)
Date: Sat, 28 Feb 2015 17:19:42 -0500
Subject: Nginx + Android + ssl = 400
In-Reply-To: <54F23AC6.2020708@kopeyko.ru>
References: <54F23AC6.2020708@kopeyko.ru>
Message-ID: <406420f579eeddffe434fb0e830fe7b9.NginxMailingListRussian@forum.nginx.org>

Все конфиги одинаковые.  Но специально сейчас еще раз проверил эту строчку -
присутствует

Кроме того, строчка из лога с работающего хоста указывает на то, что
сертификат передается:
SUCCESS ED45D3CD01EDDB07
/C=RU/ST=Moscow/L=Moscow/O=Company/OU=User/CN=user at example.com/emailAddress=user at example.com

А на неработающем нет. И у меня взрывается мозг :)

В формат лога включена информация о передаваемом сертификате - вот строчка
из лог формата:
   log_format  exchange  '$host $remote_addr - $remote_user [$time_local]
"$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      'upstream $upstream_addr status:$upstream_status time:
$upstream_response_time'
                      '$ssl_client_verify $ssl_client_serial
$ssl_client_s_dn';

Сертификаты так же идентичные (rsync клиенских и корневых) Настройки клиента
не меняются. Меняется только адрес обращения

Andrey Kopeyko Wrote:
-------------------------------------------------------

> Предположу, что конфигурация второго вашего nginx отличается
> отсутствием 
> директивы
>    	ssl_verify_client on;

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256951,256962#msg-256962


From stalker at altlinux.ru  Sat Feb 28 22:27:47 2015
From: stalker at altlinux.ru (Anton Gorlov)
Date: Sun, 01 Mar 2015 01:27:47 +0300
Subject: Nginx + Android + ssl = 400
In-Reply-To: <406420f579eeddffe434fb0e830fe7b9.NginxMailingListRussian@forum.nginx.org>
References: <54F23AC6.2020708@kopeyko.ru>
 <406420f579eeddffe434fb0e830fe7b9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54F240E3.70109@altlinux.ru>

В порядке бреда - возможно во 2 случае по пути шибко умный провайдер с
особо "умной"  DPI?

01.03.2015 01:19, ingtar пишет:
> Все конфиги одинаковые.  Но специально сейчас еще раз проверил эту строчку -
> присутствует


From andrey at kopeyko.ru  Sat Feb 28 22:40:45 2015
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Sun, 01 Mar 2015 01:40:45 +0300
Subject: Nginx + Android + ssl = 400
In-Reply-To: <406420f579eeddffe434fb0e830fe7b9.NginxMailingListRussian@forum.nginx.org>
References: <54F23AC6.2020708@kopeyko.ru>
 <406420f579eeddffe434fb0e830fe7b9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54F243ED.7040502@kopeyko.ru>

01.03.2015 01:19, ingtar пишет:
> Все конфиги одинаковые.

Это вы уже повторяли. Но diff так и не показали.

> Кроме того, строчка из лога с работающего хоста указывает на то, что
> сертификат передается:
> SUCCESS ED45D3CD01EDDB07
> /C=RU/ST=Moscow/L=Moscow/O=Company/OU=User/CN=user at example.com/emailAddress=user at example.com
>
> А на неработающем нет.

Ну, логично же : не передаётся обязательный сертификат клиента - вот 
nginx и отлупляет.


> Настройки клиента
> не меняются. Меняется только адрес обращения

Если клиент один и тот же - остаётся только вооружаться tcpdump, и под 
микроскопом изучать различия в двух ssl-handshake.



-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Sat Feb 28 22:52:24 2015
From: nginx-forum at nginx.us (ingtar)
Date: Sat, 28 Feb 2015 17:52:24 -0500
Subject: Nginx + Android + ssl = 400
In-Reply-To: <54F243ED.7040502@kopeyko.ru>
References: <54F243ED.7040502@kopeyko.ru>
Message-ID: <cc496b19f56fc89db43135838be57c69.NginxMailingListRussian@forum.nginx.org>

Andrey Kopeyko Wrote:
-------------------------------------------------------
> 
> Это вы уже повторяли. Но diff так и не показали.

Вот дифф. ssl_certificate для боевого хоста используется купленный. Для
теста соответственно самовыданный
2c2
< 	server 192.161.10.253:443;
---
> 	server 192.168.1.253:443;
7c7
<        listen         123.13.123.4:80;
---
>        listen         *:80;
18,21c18,21
< #	ssl_certificate /etc/nginx/exchange_ssl/ssl/server.crt;
< #	ssl_certificate_key /etc/nginx/exchange_ssl/ssl/server.nopass.key;
<        ssl_certificate
/etc/pki/tls/certs/22_01_2020/example.com_full.crt;
<        ssl_certificate_key
/etc/pki/tls/private/22_01_2020/example.com.key;
---
> 	ssl_certificate /etc/nginx/config/ssl/exchange.crt;
> 	ssl_certificate_key /etc/nginx/config/ssl/exchange.nopass.key;
> #       ssl_certificate
/etc/pki/tls/certs/22_01_2020/example.com_full.crt;
> #       ssl_certificate_key
/etc/pki/tls/private/22_01_2020/example.com.key;
25c25
< #	ssl_protocols	     TLSv1.1;
---
> #       ssl_protocols        TLSv1.1;
27c27
< 	ssl_client_certificate /etc/nginx/exchange_ssl/ssl/ca.crt;
---
> 	ssl_client_certificate /etc/nginx/config/ssl/ca.crt;
58,59c58,59
<                error_log /var/log/nginx/exchange.example.com_owa_error.log
debug;
<                access_log
/var/log/nginx/exchange.example.com_owa_access.log exchange;
---
>                error_log /var/log/nginx/exchange.example.com_owa_error.log
;
>                access_log
/var/log/nginx/exchange.example.com_owa_access.log;
73a74
> 
77,79c78,79
< 
<         error_log /var/log/nginx/exchange.example.com_main_error.log
debug;
<         access_log /var/log/nginx/exchange.example.com_main_access.log
exchange;
---
>         error_log /var/log/nginx/exchange.example.com_error.log ;
>         access_log /var/log/nginx/exchange.example.com_access.log
exchange;
81a82
>

> Если клиент один и тот же - остаётся только вооружаться tcpdump, и под
> 
> микроскопом изучать различия в двух ssl-handshake.

Снял strace в момент обращения, но там мало понятного.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256951,256965#msg-256965


From nginx-forum at nginx.us  Sat Feb 28 22:53:45 2015
From: nginx-forum at nginx.us (ingtar)
Date: Sat, 28 Feb 2015 17:53:45 -0500
Subject: Nginx + Android + ssl = 400
In-Reply-To: <54F240E3.70109@altlinux.ru>
References: <54F240E3.70109@altlinux.ru>
Message-ID: <10dec8b90a6244d35c7e69e4f242188e.NginxMailingListRussian@forum.nginx.org>

Anton Gorlov Wrote:
-------------------------------------------------------
> В порядке бреда - возможно во 2 случае по пути шибко умный провайдер с
> особо "умной"  DPI?
> 

Как вариант да, Подтвердить правда будет очень непросто :)

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256951,256966#msg-256966


From stalker at altlinux.ru  Sat Feb 28 23:05:29 2015
From: stalker at altlinux.ru (Anton Gorlov)
Date: Sun, 01 Mar 2015 02:05:29 +0300
Subject: Nginx + Android + ssl = 400
In-Reply-To: <10dec8b90a6244d35c7e69e4f242188e.NginxMailingListRussian@forum.nginx.org>
References: <54F240E3.70109@altlinux.ru>
 <10dec8b90a6244d35c7e69e4f242188e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <54F249B9.1000408@altlinux.ru>

01.03.2015 01:53, ingtar пишет:
>> В порядке бреда - возможно во 2 случае по пути шибко умный провайдер с
>> > особо "умной"  DPI?
>> > 
> Как вариант да, Подтвердить правда будет очень непросто :)

довольно просто - поднять vpn до тестового сервера и проверить оживёт ли
или нет. Это раз
Второе -подключится напрямую к тестовому серверу/тестовой конфигурации -
например по wifi