From nginx-forum at nginx.us  Wed Oct  1 06:40:52 2014
From: nginx-forum at nginx.us (Ve0)
Date: Wed, 01 Oct 2014 02:40:52 -0400
Subject: =?UTF-8?B?UmU6IE5naW54ICsgUEhQNS1GUE0gPT4g0L3QtSDRgNCw0LHQvtGC0LDQtdGCIGph?=
 =?UTF-8?B?dmFzY3JpcHQuLi4gKCgo?=
In-Reply-To: <236771390998278@web25m.yandex.ru>
References: <236771390998278@web25m.yandex.ru>
Message-ID: <9e29f2752c2ea67874b82be0b1f310e6.NginxMailingListRussian@forum.nginx.org>

Васильев "Zmey!" Олег Wrote:
-------------------------------------------------------
> Во-первых, откройте инструменты разработчика в браузере и посмотрите,
> какой код ответа приходит для JS файлов.
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


Открыл. Все Java скрипты открываются, содержимое их так же видно. Не
работает библиотека jQuery. причем содержимое ее отображается. Так же
проблема со скриптами которые формируются через php.

Так же на сайтах не отрабатывается JavaScript.

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


From nginx-forum at nginx.us  Wed Oct  1 06:42:15 2014
From: nginx-forum at nginx.us (Ve0)
Date: Wed, 01 Oct 2014 02:42:15 -0400
Subject: =?UTF-8?B?UmU6IE5naW54ICsgUEhQNS1GUE0gPT4g0L3QtSDRgNCw0LHQvtGC0LDQtdGCIGph?=
 =?UTF-8?B?dmFzY3JpcHQuLi4gKCgo?=
In-Reply-To: <9e29f2752c2ea67874b82be0b1f310e6.NginxMailingListRussian@forum.nginx.org>
References: <236771390998278@web25m.yandex.ru>
 <9e29f2752c2ea67874b82be0b1f310e6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <51ededbaac174fadb19e54b5695ca5cc.NginxMailingListRussian@forum.nginx.org>

При включенном сжатии вообще Java отказывается работать. Когда отключаешь,
то что то работает, что то нет.

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


From nginx-forum at nginx.us  Wed Oct  1 13:00:19 2014
From: nginx-forum at nginx.us (tr00per)
Date: Wed, 01 Oct 2014 09:00:19 -0400
Subject: =?UTF-8?B?0JDQstGC0L7QvNCw0YLQuNGH0LXRgdC60LjQtSDQv9C+0LTQtNC+0LzQtdC90Ysg?=
 =?UTF-8?B?0Lgg0YDQtdCy0YDQsNC50YLRiw==?=
Message-ID: <73314c796bf359a9964f1f0ac85e8f8a.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток.

Столкнулся с такой проблемой.
Есть основной домен project.local. Есть несколько служебных поддоменов:
m.project.local, media.project.local, login.project.local. Для каждого из
них прописаны свои реврайры. Сейчас пилим автоматическое создание поддоменов
для профилей пользователей и как вот тут и появилась проблема.

Запросы вида m.project.local, media.project.local, login.project.local
обрабатываются как нужно. Запрос anysubdomain.project.local тоже
отрабатывает как надо и реврайтит на
project.local/Script3.aspx?ArgURL=anysubdomain.
Как при этом заставить Nginx корректно реврайтить запрос типа
anysubdomain.project.local/name-i200 на
project.local/Script1.aspx?ArgID=200&ArgURL=name

Конфиг:

server {
        listen 192.168.2.6:8080 default_server;
        server_name ~(www|m|login).project.local project.local;
        include /etc/nginx/custom.conf.d/headers.conf;
        include /etc/nginx/custom.conf.d/rewrite.conf;
        location / {
                proxy_pass http://webfarm;
        }
}
server {
        listen 192.168.2.6:8080;
        server_name media.project.local;
        include /etc/nginx/custom.conf.d/swift-rewrite.conf;
        location /{
                proxy_pass http://swift;
        }
}
server {
        listen 192.168.2.6:8080;
        server_name ~^(?<subdom>.+)\.project\.local$;
        rewrite /([a-z0-9-]+)-i([0-9]+)(/?)$
/Script1.aspx?ArgID=$2&ArgURL=$1 last;
        rewrite ^ http://www.vorotila.local/Script3.aspx?ArgURL=$subdom
last;
        location  / {
                proxy_pass http://webfarm;
        }
}

Заранее спасибо за подсказки.

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


From swood at fotofor.biz  Thu Oct  2 00:28:20 2014
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Thu, 2 Oct 2014 04:28:20 +0400
Subject: =?UTF-8?Q?nginx_=D0=B8_/etc/hosts?=
Message-ID: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>

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

Мы тут заметили, что при старте nginx, он довольно часто перечитывает
/etc/hosts и /etc/resolv.conf. Можно ли как-то узнать зачем. Причем ладно
бы один раз, а то ведь раз 5, по ощущениям.

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

From igor at sysoev.ru  Thu Oct  2 06:43:49 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Thu, 2 Oct 2014 10:43:49 +0400
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
Message-ID: <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>

On 02 Oct 2014, at 04:28, Anton Kiryushkin <swood at fotofor.biz> wrote:

> Мы тут заметили, что при старте nginx, он довольно часто перечитывает /etc/hosts и /etc/resolv.conf. Можно ли как-то узнать зачем. Причем ладно бы один раз, а то ведь раз 5, по ощущениям.

Это делает libc при вызове gethostbyname() и getaddrinfo().


-- 
Igor Sysoev
Join us for nginx.conf 2014, October 20-22, San Francisco.
Get 25% off with code NGINXUG: http://nginx.com/nginxconf/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141002/472c11b3/attachment.html>

From mva at mva.name  Thu Oct  2 08:47:13 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 02 Oct 2014 15:47:13 +0700
Subject: =?UTF-8?B?0J/RgNC+0LLQtdGA0LrQsCDQstGB0LXRhSBoZWFkZXIn0L7Qsg==?=
Message-ID: <3845591.iyExYORIlH@note>

Я тут надумал избавиться от товарищей, проверяющих на ShellShock и выдавать им 
444 (евпочя).
Но беда в том, что кодовая фраза "() {" может содержаться не только в 
Referrer, но и практически в любом хидере.

Перечислять все в if-блоке ? идея не лучшая. Но отчего-то ничего умнее мне в 
голову не приходет (не считая написания кастомного модуля).

Не могли бы вы подкинуть идей? :)


-- 
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/20141002/4c9988c1/attachment.bin>

From swood at fotofor.biz  Thu Oct  2 11:06:20 2014
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Thu, 2 Oct 2014 15:06:20 +0400
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
Message-ID: <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>

Здравствуйте, Игорь.

А можно у вас уточнить еще два момента.
1. Зачем nginx вызывает эти функции libc, например, если в нашем случае мы
не используем в proxy_pass домены, а только IP. Верно ли предположение, что
происходит вызов gethostbyname на IP?
2. Как оптимизировать это место, если файл hosts достаточно большой?

2 октября 2014 г., 10:43 пользователь Igor Sysoev <igor at sysoev.ru> написал:

> On 02 Oct 2014, at 04:28, Anton Kiryushkin <swood at fotofor.biz> wrote:
>
> Мы тут заметили, что при старте nginx, он довольно часто перечитывает
> /etc/hosts и /etc/resolv.conf. Можно ли как-то узнать зачем. Причем ладно
> бы один раз, а то ведь раз 5, по ощущениям.
>
>
> Это делает libc при вызове gethostbyname() и getaddrinfo().
>
>
> --
> Igor Sysoev
> Join us for nginx.conf 2014, October 20-22, San Francisco.
> Get 25% off with code NGINXUG: http://nginx.com/nginxconf/
>
> _______________________________________________
> 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/20141002/15078e07/attachment.html>

From mva at mva.name  Thu Oct  2 11:22:03 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 02 Oct 2014 18:22:03 +0700
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
 <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
Message-ID: <2274836.Xh6L1YSktx@note>

В письме от Чт, 2 октября 2014 15:06:20 пользователь Anton Kiryushkin написал:
> Здравствуйте, Игорь.

Прошу прощения, что влезаю, хоть и не Игорь :)

> А можно у вас уточнить еще два момента.
> 1. Зачем nginx вызывает эти функции libc, например, если в нашем случае мы
> не используем в proxy_pass домены, а только IP. Верно ли предположение, что
> происходит вызов gethostbyname на IP?

-//-//-//-

> 2. Как оптимизировать это место, если файл hosts достаточно большой?

А Вы не пробовали, раз уж у вас так разросся файл hosts посмотреть в сторону 
использования кеширующего dns-сервера? (хоть бы и того же dnsmasq)?

-- 
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/20141002/0b00ddaa/attachment-0001.bin>

From swood at fotofor.biz  Thu Oct  2 11:30:47 2014
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Thu, 2 Oct 2014 15:30:47 +0400
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <2274836.Xh6L1YSktx@note>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
 <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
 <2274836.Xh6L1YSktx@note>
Message-ID: <CAM_jxg3AE4+cA7fU7brcjqdo9mRsyXt1FA78apj830QtNGCoWA@mail.gmail.com>

Здравствуйте, Вадим.

Это не всегда удобно. Например, если у вас достаточно много хостов и не
одна площадка. В этом случае вы предлагаете на каждой площадке сделать
много таких dns-серверов? Но в чем выигрыш? Мы делаем запрос по сети и
тратим на это условно 500 миллисекунд, или мы имеем hosts в памяти и в
худшем случае тратим 200 на чтение этого файла, который и так оказывается в
кэше системы.

2 октября 2014 г., 15:22 пользователь Vadim A. Misbakh-Soloviov <
mva at mva.name> написал:

> В письме от Чт, 2 октября 2014 15:06:20 пользователь Anton Kiryushkin
> написал:
> > Здравствуйте, Игорь.
>
> Прошу прощения, что влезаю, хоть и не Игорь :)
>
> > А можно у вас уточнить еще два момента.
> > 1. Зачем nginx вызывает эти функции libc, например, если в нашем случае
> мы
> > не используем в proxy_pass домены, а только IP. Верно ли предположение,
> что
> > происходит вызов gethostbyname на IP?
>
> -//-//-//-
>
> > 2. Как оптимизировать это место, если файл hosts достаточно большой?
>
> А Вы не пробовали, раз уж у вас так разросся файл hosts посмотреть в
> сторону
> использования кеширующего dns-сервера? (хоть бы и того же dnsmasq)?
>
> --
> Best regards,
> mva
>
> _______________________________________________
> 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/20141002/53a15815/attachment.html>

From mdounin at mdounin.ru  Thu Oct  2 11:41:35 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 2 Oct 2014 15:41:35 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0LLRgdC10YUgaGVhZGVyJ9C+0LI=?=
In-Reply-To: <3845591.iyExYORIlH@note>
References: <3845591.iyExYORIlH@note>
Message-ID: <20141002114135.GX69200@mdounin.ru>

Hello!

On Thu, Oct 02, 2014 at 03:47:13PM +0700, Vadim A. Misbakh-Soloviov wrote:

> Я тут надумал избавиться от товарищей, проверяющих на ShellShock и выдавать им 
> 444 (евпочя).
> Но беда в том, что кодовая фраза "() {" может содержаться не только в 
> Referrer, но и практически в любом хидере.
> 
> Перечислять все в if-блоке ? идея не лучшая. Но отчего-то ничего умнее мне в 
> голову не приходет (не считая написания кастомного модуля).
> 
> Не могли бы вы подкинуть идей? :)

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

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

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


From igor at sysoev.ru  Thu Oct  2 12:29:00 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Thu, 2 Oct 2014 16:29:00 +0400
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
 <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
Message-ID: <0B8D7DED-C75E-420F-9F7A-5358249C224B@sysoev.ru>

On 02 Oct 2014, at 15:06, Anton Kiryushkin <swood at fotofor.biz> wrote:

> А можно у вас уточнить еще два момента.
> 1. Зачем nginx вызывает эти функции libc, например, если в нашем случае мы не используем в proxy_pass домены, а только IP. Верно ли предположение, что происходит вызов gethostbyname на IP?

Если в proxy_pass описан upstream с серверами, заданными IP, то при сборке ?with-ipv6
используется getaddrinfo(). А уж что оно делает, зависит от libc.

> 2. Как оптимизировать это место, если файл hosts достаточно большой?

Собрать без ipv6.


-- 
Igor Sysoev
Join us for nginx.conf 2014, October 20-22, San Francisco.
Get 25% off with code NGINXUG: http://nginx.com/nginxconf/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141002/d125d872/attachment.html>

From nginx-forum at nginx.us  Thu Oct  2 17:23:29 2014
From: nginx-forum at nginx.us (coali)
Date: Thu, 02 Oct 2014 13:23:29 -0400
Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgNC10YjQuNGC0Ywg0LfQsNC00LDRh9GD?=
Message-ID: <e356d399e98cca2daa7982b96e93f44c.NginxMailingListRussian@forum.nginx.org>

Есть 2 сервера nginx. Как с сервера 1 пропискать конфигурационный файл так
чтобы был доступ к www.1, www2,www3
[url=http://rghost.ru/58318117.view][img]http://rghost.ru/58318117/thumb.png[/img][/url]

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


From chipitsine at gmail.com  Thu Oct  2 17:52:49 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 2 Oct 2014 23:52:49 +0600
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
 <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
Message-ID: <CAFHpkQFZb+nU=OxWfQfXPmfsbYX1n8p7gvpfXHi8qdwBHmh8GA@mail.gmail.com>

насчет оптимизации можно посмотреть в сторону nscd, например. штука
интересная, но с нюансами, ttl у него совсем свой.
раз вы говорите, что у вас большое число хостов, вы не запутаетесь в
актуальном состоянии поддерживать это хозяйство без dns ?


и такой вопрос, почему вы думаете, что будет толк от оптимизации
именно этого места ? смотрели gprof-ом ?

2 октября 2014 г., 17:06 пользователь Anton Kiryushkin
<swood at fotofor.biz> написал:
> Здравствуйте, Игорь.
>
> А можно у вас уточнить еще два момента.
> 1. Зачем nginx вызывает эти функции libc, например, если в нашем случае мы
> не используем в proxy_pass домены, а только IP. Верно ли предположение, что
> происходит вызов gethostbyname на IP?
> 2. Как оптимизировать это место, если файл hosts достаточно большой?
>
> 2 октября 2014 г., 10:43 пользователь Igor Sysoev <igor at sysoev.ru> написал:
>>
>> On 02 Oct 2014, at 04:28, Anton Kiryushkin <swood at fotofor.biz> wrote:
>>
>> Мы тут заметили, что при старте nginx, он довольно часто перечитывает
>> /etc/hosts и /etc/resolv.conf. Можно ли как-то узнать зачем. Причем ладно бы
>> один раз, а то ведь раз 5, по ощущениям.
>>
>>
>> Это делает libc при вызове gethostbyname() и getaddrinfo().
>>
>>
>> --
>> Igor Sysoev
>> Join us for nginx.conf 2014, October 20-22, San Francisco.
>> Get 25% off with code NGINXUG: http://nginx.com/nginxconf/
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From semenukha at gmail.com  Thu Oct  2 17:55:27 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Thu, 02 Oct 2014 13:55:27 -0400
Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YDQtdGI0LjRgtGMINC30LDQtNCw0YfRgw==?=
In-Reply-To: <e356d399e98cca2daa7982b96e93f44c.NginxMailingListRussian@forum.nginx.org>
References: <e356d399e98cca2daa7982b96e93f44c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <23938294.MJ36xKuxdQ@tornado>

On Thursday, October 02, 2014 01:23:29 PM coali wrote:
> Есть 2 сервера nginx. Как с сервера 1 пропискать конфигурационный файл так
> чтобы был доступ к www.1, www2,www3
> [url=http://rghost.ru/58318117.view][img]http://rghost.ru/58318117/thumb.png
> [/img][/url]
> 
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,253709,253709#msg-253709
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Не понимаю, при чем тогда тут второй сервер, если у вас первый всем занимается 
сам. Согласно картинке будет так:
server {
?
server_name www1.x.ua;
proxy_pass http://10.0.0.3;
}
и так далее. Возможно, если вы переформулируете вопрос, тут более точно 
подскажут.

P.S. для отвечающих: картинка нашлась тут: http://rghost.net/58318117.view
-- 
Best regards,
Styopa Semenukha.

From public-mail at alekciy.ru  Fri Oct  3 06:12:27 2014
From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=)
Date: Fri, 3 Oct 2014 10:12:27 +0400
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <CAM_jxg3AE4+cA7fU7brcjqdo9mRsyXt1FA78apj830QtNGCoWA@mail.gmail.com>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
 <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
 <2274836.Xh6L1YSktx@note>
 <CAM_jxg3AE4+cA7fU7brcjqdo9mRsyXt1FA78apj830QtNGCoWA@mail.gmail.com>
Message-ID: <CAPP2NXoPBfE2_dms+phVoY6ZuN3Db1gCZxeCZs5VzYD57bUNiQ@mail.gmail.com>

>или мы имеем hosts в памяти и в худшем случае тратим 200 на чтение
> этого файла, который и так оказывается в кэше системы.

Вот-вот. Возникает вопрос, зачем тогда это вообще "оптимизировать"?

2 октября 2014 г., 15:30 пользователь Anton Kiryushkin <swood at fotofor.biz>
написал:

> Здравствуйте, Вадим.
>
> Это не всегда удобно. Например, если у вас достаточно много хостов и не
> одна площадка. В этом случае вы предлагаете на каждой площадке сделать
> много таких dns-серверов? Но в чем выигрыш? Мы делаем запрос по сети и
> тратим на это условно 500 миллисекунд, или мы имеем hosts в памяти и в
> худшем случае тратим 200 на чтение этого файла, который и так оказывается в
> кэше системы.
>
> 2 октября 2014 г., 15:22 пользователь Vadim A. Misbakh-Soloviov <
> mva at mva.name> написал:
>
>> В письме от Чт, 2 октября 2014 15:06:20 пользователь Anton Kiryushkin
>> написал:
>> > Здравствуйте, Игорь.
>>
>> Прошу прощения, что влезаю, хоть и не Игорь :)
>>
>> > А можно у вас уточнить еще два момента.
>> > 1. Зачем nginx вызывает эти функции libc, например, если в нашем случае
>> мы
>> > не используем в proxy_pass домены, а только IP. Верно ли предположение,
>> что
>> > происходит вызов gethostbyname на IP?
>>
>> -//-//-//-
>>
>> > 2. Как оптимизировать это место, если файл hosts достаточно большой?
>>
>> А Вы не пробовали, раз уж у вас так разросся файл hosts посмотреть в
>> сторону
>> использования кеширующего dns-сервера? (хоть бы и того же dnsmasq)?
>>
>> --
>> Best regards,
>> mva
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>
>
> _______________________________________________
> 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/20141003/52b9bcce/attachment-0001.html>

From daniel at yavorovych.com  Fri Oct  3 06:42:55 2014
From: daniel at yavorovych.com (Daniel Yavorovych)
Date: Fri, 03 Oct 2014 09:42:55 +0300
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <CAM_jxg3AE4+cA7fU7brcjqdo9mRsyXt1FA78apj830QtNGCoWA@mail.gmail.com>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <099C1CB8-73E0-4A63-8EE7-B06B96FE983F@sysoev.ru>
 <CAM_jxg164vOQD9ccjBcT3Q+s6JcMH2Zch+DcgMiYHf=fumu2hw@mail.gmail.com>
 <2274836.Xh6L1YSktx@note>
 <CAM_jxg3AE4+cA7fU7brcjqdo9mRsyXt1FA78apj830QtNGCoWA@mail.gmail.com>
Message-ID: <542E456F.6080300@yavorovych.com>

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

Достаточно 1 dns-сервера, что будет хостить все зоны и по одному 
кеширующему серверу на каждом сервере. Кеширующий сервер все 
незакешированные запросы отправляет на головной dns (в named для этого 
есть опция forwarders).
Это сократит время резолва, полагаю, в остню раз и управлять такой 
системой должно быть проще, чем поддерживать актуальность всех файлов 
hosts. Если зоны на каждый машинке разные - можно использовать view в bind.

Спасибо.

02.10.14, 14:30, Anton Kiryushkin пишет:
> Здравствуйте, Вадим.
>
> Это не всегда удобно. Например, если у вас достаточно много хостов и не
> одна площадка. В этом случае вы предлагаете на каждой площадке сделать
> много таких dns-серверов? Но в чем выигрыш? Мы делаем запрос по сети и
> тратим на это условно 500 миллисекунд, или мы имеем hosts в памяти и в
> худшем случае тратим 200 на чтение этого файла, который и так
> оказывается в кэше системы.
>
> 2 октября 2014 г., 15:22 пользователь Vadim A. Misbakh-Soloviov
> <mva at mva.name <mailto:mva at mva.name>> написал:
>
>     В письме от Чт, 2 октября 2014 15:06:20 пользователь Anton
>     Kiryushkin написал:
>      > Здравствуйте, Игорь.
>
>     Прошу прощения, что влезаю, хоть и не Игорь :)
>
>     > А можно у вас уточнить еще два момента.
>     > 1. Зачем nginx вызывает эти функции libc, например, если в нашем случае мы
>     > не используем в proxy_pass домены, а только IP. Верно ли предположение, что
>     > происходит вызов gethostbyname на IP?
>
>     -//-//-//-
>
>     > 2. Как оптимизировать это место, если файл hosts достаточно большой?
>
>     А Вы не пробовали, раз уж у вас так разросся файл hosts посмотреть в
>     сторону
>     использования кеширующего dns-сервера? (хоть бы и того же dnsmasq)?
>
>     --
>     Best regards,
>     mva
>
>     _______________________________________________
>     nginx-ru mailing list
>     nginx-ru at nginx.org <mailto:nginx-ru at nginx.org>
>     http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>


From mva at mva.name  Fri Oct  3 08:02:46 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 03 Oct 2014 15:02:46 +0700
Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_/etc/hosts?=
In-Reply-To: <542E456F.6080300@yavorovych.com>
References: <CAM_jxg1NECWDObphQO+x6j6K3rFORgiBqmM1fo7sYCaapp-pRQ@mail.gmail.com>
 <CAM_jxg3AE4+cA7fU7brcjqdo9mRsyXt1FA78apj830QtNGCoWA@mail.gmail.com>
 <542E456F.6080300@yavorovych.com>
Message-ID: <2409894.vPtxERffLN@note>

Да, на самом деле, тот же dnsmasq тут вполне справится (его тут вообще как 
доктор прописал)
-- 
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/20141003/e04585ab/attachment.bin>

From nginx-forum at nginx.us  Fri Oct  3 13:16:04 2014
From: nginx-forum at nginx.us (ole-lukoje)
Date: Fri, 03 Oct 2014 09:16:04 -0400
Subject: epoll_wait() reported that client prematurely closed connection
In-Reply-To: <1513259.TMtFkWvXjD@vbart-laptop>
References: <1513259.TMtFkWvXjD@vbart-laptop>
Message-ID: <1c55d43036621f064c9bb188ce266804.NginxMailingListRussian@forum.nginx.org>

Спасибо за совет, с помощью этой директивы удалось решить проблему

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


From eudovihin at gmail.com  Fri Oct  3 16:51:51 2014
From: eudovihin at gmail.com (=?KOI8-R?B?5dfHxc7JyiD1xM/XycjJzg==?=)
Date: Sat, 4 Oct 2014 03:51:51 +1100
Subject: =?UTF-8?B?0JzQuNC90LjQvNCw0LvRjNC90L7QtSDQstGA0LXQvNGPINC60LXRiNC40YDQvtCy?=
 =?UTF-8?B?0LDQvdC40Y8=?=
Message-ID: <CAJh8W=gsO_LeMbPuRv97m-A_k3RYv2gYZ0Ej0BQ9YFbr9krUAw@mail.gmail.com>

Добрый день.

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

Создал кеш
proxy_cache_path /tmp/an_cache levels=1 keys_zone=pagecache:1m max_size=1m;

Прописал в location
     proxy_cache             pagecache;
     proxy_cache_valid       200 1s;
     proxy_ignore_headers Expires Cache-Control;
     if ($arg_callback) {
        set $callback callback;
     }
     proxy_cache_key $scheme$proxy_host$uri$arg_widget$callback;
     proxy_pass_header "X-Accel-Expires";

В скрипте указываю:
header("X-Accel-Expires: 1");

Однако при монотонном F5 страницы скрипта теперь счетчик тикает не каждую
секунду, как и должен был бы, а раз в 2. Я понимаю, что кеш не совпадает с
моментом перехода между секундами и привносит погрешность в рамках секунды,
однако, почему кешированная страница живет дольше указанной 1 секунды?
Хотелось бы это исправить.

Спасибо.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141004/7c70aeff/attachment.html>

From nginx-forum at nginx.us  Fri Oct  3 17:57:47 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Fri, 03 Oct 2014 13:57:47 -0400
Subject: =?UTF-8?B?UmU6INCc0LjQvdC40LzQsNC70YzQvdC+0LUg0LLRgNC10LzRjyDQutC10YjQuNGA?=
 =?UTF-8?B?0L7QstCw0L3QuNGP?=
In-Reply-To: <CAJh8W=gsO_LeMbPuRv97m-A_k3RYv2gYZ0Ej0BQ9YFbr9krUAw@mail.gmail.com>
References: <CAJh8W=gsO_LeMbPuRv97m-A_k3RYv2gYZ0Ej0BQ9YFbr9krUAw@mail.gmail.com>
Message-ID: <5baafbccd1e02e1b65c6b2518c5598c3.NginxMailingListRussian@forum.nginx.org>

Вы указываете временную дельту равной 1 секунде, относительно от последнего
запроса к РНР бекенду.
Возможно вам больше подойдет вариант указывать абсолютный unix time.

Как-то так
header('X-Accel-Expires: @'.time() + 1);

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


From eudovihin at gmail.com  Fri Oct  3 18:10:25 2014
From: eudovihin at gmail.com (=?KOI8-R?B?5dfHxc7JyiD1xM/XycjJzg==?=)
Date: Sat, 4 Oct 2014 05:10:25 +1100
Subject: =?UTF-8?B?UmU6INCc0LjQvdC40LzQsNC70YzQvdC+0LUg0LLRgNC10LzRjyDQutC10YjQuNGA?=
 =?UTF-8?B?0L7QstCw0L3QuNGP?=
In-Reply-To: <5baafbccd1e02e1b65c6b2518c5598c3.NginxMailingListRussian@forum.nginx.org>
References: <CAJh8W=gsO_LeMbPuRv97m-A_k3RYv2gYZ0Ej0BQ9YFbr9krUAw@mail.gmail.com>
 <5baafbccd1e02e1b65c6b2518c5598c3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAJh8W=iFeqdj6Rs7BBq2UPnnWhvCDyeoS=XkuMvHE9ZrwqWvvg@mail.gmail.com>

При таком варианте эффективность кеширования падает до 0, будто и нет его.

4 октября 2014 г., 4:57 пользователь S.A.N <nginx-forum at nginx.us> написал:

> Вы указываете временную дельту равной 1 секунде, относительно от последнего
> запроса к РНР бекенду.
> Возможно вам больше подойдет вариант указывать абсолютный unix time.
>
> Как-то так
> header('X-Accel-Expires: @'.time() + 1);
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,253754,253756#msg-253756
>
> _______________________________________________
> 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/20141004/6a448d2e/attachment.html>

From eudovihin at gmail.com  Fri Oct  3 18:28:28 2014
From: eudovihin at gmail.com (=?KOI8-R?B?5dfHxc7JyiD1xM/XycjJzg==?=)
Date: Sat, 4 Oct 2014 05:28:28 +1100
Subject: =?UTF-8?B?UmU6INCc0LjQvdC40LzQsNC70YzQvdC+0LUg0LLRgNC10LzRjyDQutC10YjQuNGA?=
 =?UTF-8?B?0L7QstCw0L3QuNGP?=
In-Reply-To: <CAJh8W=iFeqdj6Rs7BBq2UPnnWhvCDyeoS=XkuMvHE9ZrwqWvvg@mail.gmail.com>
References: <CAJh8W=gsO_LeMbPuRv97m-A_k3RYv2gYZ0Ej0BQ9YFbr9krUAw@mail.gmail.com>
 <5baafbccd1e02e1b65c6b2518c5598c3.NginxMailingListRussian@forum.nginx.org>
 <CAJh8W=iFeqdj6Rs7BBq2UPnnWhvCDyeoS=XkuMvHE9ZrwqWvvg@mail.gmail.com>
Message-ID: <CAJh8W=g6vvBrFOxCfgYwqt8ZOEODe3B3qABfg6LrCfb8F9dDWQ@mail.gmail.com>

В общем разобрался, просто в header функция time в принципе некорректно
себя ведет, если вывести time()+1 в отдельную переменную и подставлять, то
тогда все работает. Спасибо всем.

4 октября 2014 г., 5:10 пользователь Евгений Удовихин <eudovihin at gmail.com>
написал:

> При таком варианте эффективность кеширования падает до 0, будто и нет его.
>
> 4 октября 2014 г., 4:57 пользователь S.A.N <nginx-forum at nginx.us> написал:
>
> Вы указываете временную дельту равной 1 секунде, относительно от последнего
>> запроса к РНР бекенду.
>> Возможно вам больше подойдет вариант указывать абсолютный unix time.
>>
>> Как-то так
>> header('X-Accel-Expires: @'.time() + 1);
>>
>> Posted at Nginx Forum:
>> http://forum.nginx.org/read.php?21,253754,253756#msg-253756
>>
>> _______________________________________________
>> 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/20141004/8d9a9b3b/attachment.html>

From nginx-forum at nginx.us  Fri Oct  3 19:43:08 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Fri, 03 Oct 2014 15:43:08 -0400
Subject: =?UTF-8?B?UmU6INCc0LjQvdC40LzQsNC70YzQvdC+0LUg0LLRgNC10LzRjyDQutC10YjQuNGA?=
 =?UTF-8?B?0L7QstCw0L3QuNGP?=
In-Reply-To: <CAJh8W=g6vvBrFOxCfgYwqt8ZOEODe3B3qABfg6LrCfb8F9dDWQ@mail.gmail.com>
References: <CAJh8W=g6vvBrFOxCfgYwqt8ZOEODe3B3qABfg6LrCfb8F9dDWQ@mail.gmail.com>
Message-ID: <009c9e5026a67d016909178697a49721.NginxMailingListRussian@forum.nginx.org>

Евгений Удовихин Wrote:
-------------------------------------------------------
> В общем разобрался, просто в header функция time в принципе
> некорректно
> себя ведет, если вывести time()+1 в отдельную переменную и
> подставлять, то
> тогда все работает. Спасибо всем.

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

Рабочий код выглядит так:

header('X-Accel-Expires: @'.(time() + 1));

Или через переменную...

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


From nginx-forum at nginx.us  Fri Oct  3 19:45:14 2014
From: nginx-forum at nginx.us (kiber)
Date: Fri, 03 Oct 2014 15:45:14 -0400
Subject: =?UTF-8?B?UmV3cml0ZSAuaHRhY2Nlc3Mg0LTQu9GPIG5naW54?=
Message-ID: <f728f4444c937d160b21e4bcc828fd2c.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток.

Пытаюсь преобразовать такую конструкцию

RewriteRule ^category-(.*)-(.*).html index.php?$2 [QSA,L,NC]
RewriteRule ^forum-(.*)-(.*).html forum.php?$2 [QSA,L,NC]
RewriteRule ^topic-(.*)-(.*).html topic.php?$2 [QSA,L,NC]

для nginx

так 

location /category {
rewrite ^/category-(.*)-(.*).html /index.php?$2 break;
}
location /forum {
rewrite ^/forum-(.*)-(.*).html /forum.php?$2 break;
}
location /topic {
rewrite ^/topic-(.*)-(.*).html /topic.php?$2 break;
}

или так 

rewrite ^/category-(.*)-(.*).html /index.php/$2 last;
rewrite ^/forum-(.*)-(.*).html /forum.php/$2 last;
rewrite ^/topic-(.*)-(.*).html /topic.php/$2 last;


Ни один вариант не срабатывает.

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


From nginx-forum at nginx.us  Mon Oct  6 05:12:57 2014
From: nginx-forum at nginx.us (den68)
Date: Mon, 06 Oct 2014 01:12:57 -0400
Subject: nginx API module #C
In-Reply-To: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org>
References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <dc3483971d426e69f675e4c06db35e8f.NginxMailingListRussian@forum.nginx.org>

хотелось задать еще один вопрос, где и собственно как прописывается
совместимость разных команд в одной секции?
на примере локейшена:

location /abc {
    variable1 "aaa";
    variable2 "bbb";
}

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

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


From mdounin at mdounin.ru  Mon Oct  6 11:17:25 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 6 Oct 2014 15:17:25 +0400
Subject: nginx API module #C
In-Reply-To: <dc3483971d426e69f675e4c06db35e8f.NginxMailingListRussian@forum.nginx.org>
References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org>
 <dc3483971d426e69f675e4c06db35e8f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141006111725.GH69200@mdounin.ru>

Hello!

On Mon, Oct 06, 2014 at 01:12:57AM -0400, den68 wrote:

> хотелось задать еще один вопрос, где и собственно как прописывается
> совместимость разных команд в одной секции?
> на примере локейшена:
> 
> location /abc {
>     variable1 "aaa";
>     variable2 "bbb";
> }
> 
> с учетом того что действия variable1 и variable2 несовместимы друг с другом
> в одном локейшене, хотелось бы реакцию конфига на ошибку конфигурации ...
> полагаю что лежит где-то на поверхности, но примеров подобного поведения в
> исходниках не нашел...

Плохо искали.  Обычно соответствующие проверки делаются в 
обработчике merge location config.

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


From nginx-forum at nginx.us  Wed Oct  8 08:03:57 2014
From: nginx-forum at nginx.us (petrofm)
Date: Wed, 08 Oct 2014 04:03:57 -0400
Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDIG5naW54INGD0LHQuNGA0LDQtdGCINC30LDQs9C+0LvQvtCy?=
 =?UTF-8?B?0L7QuiBDb250ZW50LUxlbmd0aCDRgSDQvtGC0LLQtdGC0LAgZmFzdGNnaSA/?=
Message-ID: <a713b7d568ff9b7d6fe9c8648bc420c6.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток!
С fastcgi приложения передаю заголовок Content-Length, но nginx его убирает
(.
не могу понять почему и зачем. 
кусочек debug.log :
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi header:
"Content-Length: 15868200;"
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi parser: 0
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi header:
"X-Content-Length: 15868200;"
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi parser: 0
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi header: "Content-Type:
application/octet-stream;"
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi parser: 0
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi header:
"Content-Disposition: attachment; filename='file.mp3';"
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi parser: 1
......
2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi header done
2014/10/07 21:35:51 [debug] 2740#0: *11 xslt filter header
2014/10/07 21:35:51 [debug] 2740#0: *11 HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Oct 2014 18:35:51 GMT
Content-Type: application/octet-stream;
Connection: close
Accept-Ranges: bytes;
X-Content-Length: 15868200;
Content-Disposition: attachment; filename='file.mp3';

После заголовка  X-Content-Length
fastcgi parser: 0
и после Content-Length так же fastcgi parser: 0
но,  X-Content-Length попадает в ответ,  Content-Length нет .

Конфиг:
server {
    server_name localhost 127.0.0.1;
    location / {
	chunked_transfer_encoding off;
	fastcgi_pass_header Content-Length;
        fastcgi_pass  unix://tmp/btfcgi;
        #include fastcgi_params;
    }
}

Может существует какая то волшебная опция, подскажите пожалуйста )

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


From vbart at nginx.com  Wed Oct  8 08:13:02 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 08 Oct 2014 12:13:02 +0400
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyBuZ2lueCDRg9Cx0LjRgNCw0LXRgiDQt9Cw0LPQvtC7?=
 =?UTF-8?B?0L7QstC+0LogQ29udGVudC1MZW5ndGgg0YEg0L7RgtCy0LXRgtCwIGZhc3Rj?=
 =?UTF-8?B?Z2kgPw==?=
In-Reply-To: <a713b7d568ff9b7d6fe9c8648bc420c6.NginxMailingListRussian@forum.nginx.org>
References: <a713b7d568ff9b7d6fe9c8648bc420c6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <12616909.LlW5kLYgof@vbart-laptop>

On Wednesday 08 October 2014 04:03:57 petrofm wrote:
> Доброго времени суток!
> С fastcgi приложения передаю заголовок Content-Length, но nginx его убирает
> (.
> не могу понять почему и зачем. 
> кусочек debug.log :
> 2014/10/07 21:35:51 [debug] 2740#0: *11 http fastcgi header:
> "Content-Length: 15868200;" 
[..]

Заголовок содержит некорректное значение, поэтому и не передается.
Использовать точку с запятой в заголовке Content-Length недопустимо.

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

From nginx-forum at nginx.us  Wed Oct  8 08:19:08 2014
From: nginx-forum at nginx.us (petrofm)
Date: Wed, 08 Oct 2014 04:19:08 -0400
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyBuZ2lueCDRg9Cx0LjRgNCw0LXRgiDQt9Cw0LPQvtC7?=
 =?UTF-8?B?0L7QstC+0LogQ29udGVudC1MZW5ndGgg0YEg0L7RgtCy0LXRgtCwIGZhc3Rj?=
 =?UTF-8?B?Z2kgPw==?=
In-Reply-To: <12616909.LlW5kLYgof@vbart-laptop>
References: <12616909.LlW5kLYgof@vbart-laptop>
Message-ID: <95f50f4df7a92edcec6a5b5050ce480f.NginxMailingListRussian@forum.nginx.org>

Большое СПАСИБО ! 
Все работает)

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


From nginx-forum at nginx.us  Wed Oct  8 08:35:23 2014
From: nginx-forum at nginx.us (vvmluxsite)
Date: Wed, 08 Oct 2014 04:35:23 -0400
Subject: =?UTF-8?B?bmdpbngtMS42LjIg0J7RiNC40LHQvtGH0L3Ri9C5INGB0LjQvdGC0LDQutGB0Lg=?=
 =?UTF-8?B?0YEg0LIg0LrQvtC90YTQuNCz0YPRgNCw0YbQuNC4?=
Message-ID: <cf039d6078362a296dc635f2f3d82ef4.NginxMailingListRussian@forum.nginx.org>

server (
...
    index index.html
    include     include.conf;
....
}

Результат:

Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
successful


Вместо индекса другая директива, например:
server (
...
    error_log /var/log/nginx/error_qqq.log
    include     include.conf;
....
}
даёт такой результат:

Performing sanity check on nginx configuration:
nginx: [emerg] invalid log level "include" in
/usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:15


Теперь error_log после индекса:
server (
...
    index index.html
    error_log /var/log/nginx/error_qqq.log
    include     include.conf;
....
}
Получается:

Performing sanity check on nginx configuration:
nginx: [warn] only the last index in "index" directive should be absolute in
/usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:15
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
successful


Просто "f":
server (
...
     index index.html
#    error_log /var/log/srv_www/nginx/error_qqq.log
    f
    include     include.conf;
....
}
Такой результат:

Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
successful

Если включить "error_log" из последнего примера:
Performing sanity check on nginx configuration:
nginx: [warn] only the last index in "index" directive should be absolute in
/usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:16
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
successful

Тут 16-я строка: include     include.conf;

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


From pluknet at nginx.com  Wed Oct  8 08:41:57 2014
From: pluknet at nginx.com (Sergey Kandaurov)
Date: Wed, 8 Oct 2014 12:41:57 +0400
Subject: =?UTF-8?B?UmU6IG5naW54LTEuNi4yINCe0YjQuNCx0L7Rh9C90YvQuSDRgdC40L3RgtCw0Lo=?=
 =?UTF-8?B?0YHQuNGBINCyINC60L7QvdGE0LjQs9GD0YDQsNGG0LjQuA==?=
In-Reply-To: <cf039d6078362a296dc635f2f3d82ef4.NginxMailingListRussian@forum.nginx.org>
References: <cf039d6078362a296dc635f2f3d82ef4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <482BA3B7-6445-4974-8C19-78C1364023C9@nginx.com>

On Oct 8, 2014, at 12:35 PM, vvmluxsite <nginx-forum at nginx.us> wrote:
> server (
> ...
>    index index.html

пропущена точка с запятой

>    include     include.conf;
> ....
> }

-- 
Sergey Kandaurov


From dmitriy at lyalyuev.info  Wed Oct  8 08:42:20 2014
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Wed, 08 Oct 2014 11:42:20 +0300
Subject: =?UTF-8?B?UmU6IG5naW54LTEuNi4yINCe0YjQuNCx0L7Rh9C90YvQuSDRgdC40L3RgtCw0Lo=?=
 =?UTF-8?B?0YHQuNGBINCyINC60L7QvdGE0LjQs9GD0YDQsNGG0LjQuA==?=
In-Reply-To: <cf039d6078362a296dc635f2f3d82ef4.NginxMailingListRussian@forum.nginx.org>
References: <cf039d6078362a296dc635f2f3d82ef4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5434F8EC.6040500@lyalyuev.info>

Добрый день.

Может дело в отсутствии точки с запятой в конце предыдущей строки?


08.10.2014 11:35, vvmluxsite пишет:
> server (
> ...
>      index index.html
>      include     include.conf;
> ....
> }
>
> Результат:
>
> Performing sanity check on nginx configuration:
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful
>
>
> Вместо индекса другая директива, например:
> server (
> ...
>      error_log /var/log/nginx/error_qqq.log
>      include     include.conf;
> ....
> }
> даёт такой результат:
>
> Performing sanity check on nginx configuration:
> nginx: [emerg] invalid log level "include" in
> /usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:15
>
>
> Теперь error_log после индекса:
> server (
> ...
>      index index.html
>      error_log /var/log/nginx/error_qqq.log
>      include     include.conf;
> ....
> }
> Получается:
>
> Performing sanity check on nginx configuration:
> nginx: [warn] only the last index in "index" directive should be absolute in
> /usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:15
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful
>
>
> Просто "f":
> server (
> ...
>       index index.html
> #    error_log /var/log/srv_www/nginx/error_qqq.log
>      f
>      include     include.conf;
> ....
> }
> Такой результат:
>
> Performing sanity check on nginx configuration:
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful
>
> Если включить "error_log" из последнего примера:
> Performing sanity check on nginx configuration:
> nginx: [warn] only the last index in "index" directive should be absolute in
> /usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:16
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful
>
> Тут 16-я строка: include     include.conf;
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253828,253828#msg-253828
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From vbart at nginx.com  Wed Oct  8 08:44:40 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 08 Oct 2014 12:44:40 +0400
Subject: =?UTF-8?B?UmU6IG5naW54LTEuNi4yINCe0YjQuNCx0L7Rh9C90YvQuSDRgdC40L3RgtCw0Lo=?=
 =?UTF-8?B?0YHQuNGBINCyINC60L7QvdGE0LjQs9GD0YDQsNGG0LjQuA==?=
In-Reply-To: <cf039d6078362a296dc635f2f3d82ef4.NginxMailingListRussian@forum.nginx.org>
References: <cf039d6078362a296dc635f2f3d82ef4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1459468.2NBTBu6yqL@vbart-laptop>

On Wednesday 08 October 2014 04:35:23 vvmluxsite wrote:
> server (
> ...
>     index index.html
>     include     include.conf;
> ....
> }
> 
> Результат:
> 
> Performing sanity check on nginx configuration:
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful

Ничего удивительного.  Вы пропустили точку с запятой
в результате чего "include" и "include.conf" были
интерпретированы как значения директивы index.

С точки зрения синтаксиса директивы index значения
валидны.

> 
> 
> Вместо индекса другая директива, например:
> server (
> ...
>     error_log /var/log/nginx/error_qqq.log
>     include     include.conf;
> ....
> }
> даёт такой результат:
> 
> Performing sanity check on nginx configuration:
> nginx: [emerg] invalid log level "include" in
> /usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:15
> 

В директиве error_log вторым параметром, если задан,
должен задаваться уровень логгирования, который
может принимать только одно из следующих значений:
debug, info, notice, warn, error, crit, alert и emerg.

Значение "include" не является корректным уровнем
логгирования.

См. документацию:
http://nginx.org/r/error_log/ru



> 
> Теперь error_log после индекса:
> server (
> ...
>     index index.html
>     error_log /var/log/nginx/error_qqq.log
>     include     include.conf;
> ....
> }
> Получается:
> 
> Performing sanity check on nginx configuration:
> nginx: [warn] only the last index in "index" directive should be absolute in
> /usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:15
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful

Опять же, из-за пропущенных точек запятой все это
интерпретируется как значения директивы index, а именно
пять значений:

 1. index.html
 2. error_log
 3. /var/log/nginx/error_qqq.log
 4. include
 5. include.conf



> 
> 
> Просто "f":
> server (
> ...
>      index index.html
> #    error_log /var/log/srv_www/nginx/error_qqq.log
>     f
>     include     include.conf;
> ....
> }
> Такой результат:
> 
> Performing sanity check on nginx configuration:
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful
> 
> Если включить "error_log" из последнего примера:
> Performing sanity check on nginx configuration:
> nginx: [warn] only the last index in "index" directive should be absolute in
> /usr/local/etc/nginx/vhosts/sites-enabled/sites.conf:16
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is
> successful
> 
> Тут 16-я строка: include     include.conf;
>
 
Аналогично.  Будьте внимательны.

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

From nginx-forum at nginx.us  Wed Oct  8 08:53:36 2014
From: nginx-forum at nginx.us (vvmluxsite)
Date: Wed, 08 Oct 2014 04:53:36 -0400
Subject: =?UTF-8?B?UmU6IG5naW54LTEuNi4yINCe0YjQuNCx0L7Rh9C90YvQuSDRgdC40L3RgtCw0Lo=?=
 =?UTF-8?B?0YHQuNGBINCyINC60L7QvdGE0LjQs9GD0YDQsNGG0LjQuA==?=
In-Reply-To: <1459468.2NBTBu6yqL@vbart-laptop>
References: <1459468.2NBTBu6yqL@vbart-laptop>
Message-ID: <9b9bd0edf63415a63c38688d68b93db6.NginxMailingListRussian@forum.nginx.org>

Так вот и удивило отсутствие ругани на несуществующую ";".
Уже после создания вопроса вспомнил о многострочности.

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


From nginx-forum at nginx.us  Thu Oct  9 00:21:21 2014
From: nginx-forum at nginx.us (makky)
Date: Wed, 08 Oct 2014 20:21:21 -0400
Subject: mod_zip
Message-ID: <325bccff036692ec4628f497c2831af2.NginxMailingListRussian@forum.nginx.org>

привет.

Делаю под gentoo ebuild:

....
nginx_modules_http_mod_zip? (
https://github.com/evanmiller/mod_zip/archive/master.zip -> ngx_mod_zip.zip
)
....
NGINX_MODULES_3RD="
 ....
    http_mod_zip"
....
    if use nginx_modules_http_mod_zip; then
        http_enabled=1
        myconf+=" --add-module=${WORKDIR}/mod_zip-master"
    fi

после установки порта с оверлея, делаю nginx -V:

nginx version: nginx/1.7.4
TLS SNI support enabled
configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error_log --pid-path=/run/nginx.pid
--lock-path=/run/lock/nginx.lock --with-cc-opt=-I/usr/include
--with-ld-opt=-L/usr/lib64 --http-log-path=/var/log/nginx/access_log
--http-client-body-temp-path=//var/lib/nginx/tmp/client
--http-proxy-temp-path=//var/lib/nginx/tmp/proxy
--http-fastcgi-temp-path=//var/lib/nginx/tmp/fastcgi
--http-scgi-temp-path=//var/lib/nginx/tmp/scgi
--http-uwsgi-temp-path=//var/lib/nginx/tmp/uwsgi --with-file-aio
--with-aio_module --with-pcre --without-http_auth_basic_module
--without-http_autoindex_module --without-http_geo_module
--without-http_scgi_module --without-http_upstream_ip_hash_module
--without-http_uwsgi_module --with-http_addition_module
--with-http_gzip_static_module --with-http_spdy_module
--with-http_stub_status_module --with-http_sub_module
--with-http_xslt_module --with-http_realip_module
--add-module=external_module/mod_zip-master
--add-module=external_module/nginx-upload-progress-module-0.9.1
--add-module=external_module/headers-more-nginx-module-0.25
--add-module=external_module/nginx_upstream_check_module-0.1.9
--without-http-cache --with-http_ssl_module --without-mail_imap_module
--without-mail_pop3_module --without-mail_smtp_module --user=nginx
--group=nginx

То есть модуль mod_zip присутствует:
--add-module=external_module/mod_zip-master 

Но элементарный скриптик из серии:

<?php

    $archive = [
       0 => "- 1845 /test/1 test.png"
    ];

    header("Content-Disposition: attachment; filename= test.zip");
   // header('X-Archive-Files: zip');
    echo implode("\r\n", $archive) . "\r\n";
    exit();

Даёт скачать архив, но он некорректный. Если раскомментирую X-Archive-Files
-  сброс соединения. Пробовал ставить с сорцов с добавлением этого модуля
версии 1.4.4, 1.4.7, 1.7.4 и 1.7.6, но поведение одинаковое - качаю архив,
но битый либо сброс. При этом всё тоже самое на другой лин-машинке (не
генту) все проходит превосходно.

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

Спасибо.

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


From mva at mva.name  Thu Oct  9 05:51:02 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 09 Oct 2014 12:51:02 +0700
Subject: mod_zip
In-Reply-To: <325bccff036692ec4628f497c2831af2.NginxMailingListRussian@forum.nginx.org>
References: <325bccff036692ec4628f497c2831af2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1657372.SfYZJy01j8@note>

> Делаю под gentoo ebuild:

Похвально :)

> ....
> nginx_modules_http_mod_zip? (
> https://github.com/evanmiller/mod_zip/archive/master.zip -> ngx_mod_zip.zip
А вот этого лучше не делать. Чексумма будет постоянно биться.
> 
> <?php
> 
>     $archive = [
>        0 => "- 1845 /test/1 test.png"
>     ];
> 
>     header("Content-Disposition: attachment; filename= test.zip");
>    // header('X-Archive-Files: zip');
>     echo implode("\r\n", $archive) . "\r\n";
>     exit();
> 
> Даёт скачать архив, но он некорректный. Если раскомментирую X-Archive-Files
> -  сброс соединения. Пробовал ставить с сорцов с добавлением этого модуля
> версии 1.4.4, 1.4.7, 1.7.4 и 1.7.6, но поведение одинаковое - качаю архив,
> но битый либо сброс. При этом всё тоже самое на другой лин-машинке (не
> генту) все проходит превосходно.

Скорее всего, дело в libzip (или что там модуль использует как бекенд). Более, 
чем уверен, что дело в разных версиях.

> 
> Подскажите, пожалуйста, на что обратить внимание, как выполнить дебаг. Может
> у кого-то была подобная проблема?


А вообще, для дебага есть USE=debug + gdb ;)


P.S. попробую добавить этот модуль в ебилд nginx в оверлее mva (обычно оттуда 
он частями синхронизируется с деревом) :)

-- 
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/20141009/478713e2/attachment.bin>

From nginx-forum at nginx.us  Thu Oct  9 06:38:35 2014
From: nginx-forum at nginx.us (makky)
Date: Thu, 09 Oct 2014 02:38:35 -0400
Subject: mod_zip
In-Reply-To: <1657372.SfYZJy01j8@note>
References: <1657372.SfYZJy01j8@note>
Message-ID: <b3a9f2b1c34db613fb80ef6821d9e30a.NginxMailingListRussian@forum.nginx.org>

>Скорее всего, дело в libzip (или что там модуль использует как бекенд).
Более,
>чем уверен, что дело в разных версиях.

Я тоже так думаю, но надеялся на халяву, чтоб сорцы не смотреть :)

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


From nginx-forum at nginx.us  Thu Oct  9 11:14:45 2014
From: nginx-forum at nginx.us (makky)
Date: Thu, 09 Oct 2014 07:14:45 -0400
Subject: mod_zip
In-Reply-To: <1657372.SfYZJy01j8@note>
References: <1657372.SfYZJy01j8@note>
Message-ID: <09e4e9071188291d6165f978576a0029.NginxMailingListRussian@forum.nginx.org>

Вот такую ошибку пишет в лог при переданном заголовке
header('X-Archive-Files: zip');:
87 mod_zip: a subrequest returned 404, aborting... while reading response
header from upstream 

пытаюсь дебажить. Игры с версиями библиотек не принесли результата.

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


From stalker at altlinux.ru  Thu Oct  9 11:37:18 2014
From: stalker at altlinux.ru (Anton Gorlov)
Date: Thu, 09 Oct 2014 15:37:18 +0400
Subject: mod_zip
In-Reply-To: <09e4e9071188291d6165f978576a0029.NginxMailingListRussian@forum.nginx.org>
References: <1657372.SfYZJy01j8@note>
 <09e4e9071188291d6165f978576a0029.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5436736E.4000905@altlinux.ru>

имеет смысл обратится к автору данного модуля

09.10.2014 15:14, makky пишет:
> Вот такую ошибку пишет в лог при переданном заголовке
> header('X-Archive-Files: zip');:
> 87 mod_zip: a subrequest returned 404, aborting... while reading response
> header from upstream 
>
> пытаюсь дебажить. Игры с версиями библиотек не принесли результата.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253852,253864#msg-253864
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Thu Oct  9 12:08:24 2014
From: nginx-forum at nginx.us (makky)
Date: Thu, 09 Oct 2014 08:08:24 -0400
Subject: mod_zip
In-Reply-To: <09e4e9071188291d6165f978576a0029.NginxMailingListRussian@forum.nginx.org>
References: <1657372.SfYZJy01j8@note>
 <09e4e9071188291d6165f978576a0029.NginxMailingListRussian@forum.nginx.org>
Message-ID: <13e1562b2fd2a7feca13027cde17d939.NginxMailingListRussian@forum.nginx.org>

Ошибки не было, вопрос решил размещением линка на директорию, где
размещались файлы.

amv, спасибо за поддержку. Я не чувствовал себя одиноким ;) Куски mod_zip из
ebuild, которые я привел - рабочие, забери в свой ебилд.

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


From nginx-forum at nginx.us  Thu Oct  9 12:09:06 2014
From: nginx-forum at nginx.us (makky)
Date: Thu, 09 Oct 2014 08:09:06 -0400
Subject: mod_zip
In-Reply-To: <5436736E.4000905@altlinux.ru>
References: <5436736E.4000905@altlinux.ru>
Message-ID: <6a8c220376d969c577c0c9304dcc008f.NginxMailingListRussian@forum.nginx.org>

Вопрос решился: http://forum.nginx.org/read.php?21,253852,253868#msg-253868

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


From eugene.toropov at gmail.com  Fri Oct 10 13:55:33 2014
From: eugene.toropov at gmail.com (Eugene Toropov)
Date: Fri, 10 Oct 2014 17:55:33 +0400
Subject: =?UTF-8?B?MSBiYXNpYyBhdXRoIC0g0LzQvdC+0LPQviDRgdGD0LHQtNC+0LzQtdC90L7Qsg==?=
Message-ID: <7063A753-0FFC-480E-A6DA-F103C055F98A@gmail.com>

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

Возможно ли настроить HTTP Basic Authentication (auth_basic/auth_basic_user_file) так чтоб однажды успешная авторизация работала на всех субдоменах?

Евгений

From dmitry.goryainov at gmail.com  Fri Oct 10 14:10:57 2014
From: dmitry.goryainov at gmail.com (Dmitry)
Date: Fri, 10 Oct 2014 18:10:57 +0400
Subject: =?UTF-8?B?UmU6IDEgYmFzaWMgYXV0aCAtINC80L3QvtCz0L4g0YHRg9Cx0LTQvtC80LXQvdC+?=
 =?UTF-8?B?0LI=?=
In-Reply-To: <7063A753-0FFC-480E-A6DA-F103C055F98A@gmail.com>
References: <7063A753-0FFC-480E-A6DA-F103C055F98A@gmail.com>
Message-ID: <CAHzBpYVHE0UDraF_YJ8X7+CXRr-mYTh36Ye=XV2DYUG77-qHGg@mail.gmail.com>

А прочитать протокол?
 10 окт. 2014 г. 17:55 пользователь "Eugene Toropov" <
eugene.toropov at gmail.com> написал:

> Добрый вечер,
>
> Возможно ли настроить HTTP Basic Authentication
> (auth_basic/auth_basic_user_file) так чтоб однажды успешная авторизация
> работала на всех субдоменах?
>
> Евгений
> _______________________________________________
> 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/20141010/6c4e6c9b/attachment.html>

From eugene.toropov at gmail.com  Fri Oct 10 14:12:58 2014
From: eugene.toropov at gmail.com (Eugene Toropov)
Date: Fri, 10 Oct 2014 18:12:58 +0400
Subject: =?UTF-8?B?UmU6IDEgYmFzaWMgYXV0aCAtINC80L3QvtCz0L4g0YHRg9Cx0LTQvtC80LXQvdC+?=
 =?UTF-8?B?0LI=?=
In-Reply-To: <CAHzBpYVHE0UDraF_YJ8X7+CXRr-mYTh36Ye=XV2DYUG77-qHGg@mail.gmail.com>
References: <7063A753-0FFC-480E-A6DA-F103C055F98A@gmail.com>
 <CAHzBpYVHE0UDraF_YJ8X7+CXRr-mYTh36Ye=XV2DYUG77-qHGg@mail.gmail.com>
Message-ID: <2E0F08AD-8641-483F-8FEE-A3D61F19B2E4@gmail.com>

Вам сложно ответить, если знаете? Или вы его прочитали для того, что посылать всех на RTFM?

On Oct 10, 2014, at 6:10 PM, Dmitry <dmitry.goryainov at gmail.com> wrote:

> А прочитать протокол?
> 10 окт. 2014 г. 17:55 пользователь "Eugene Toropov" <eugene.toropov at gmail.com> написал:
> Добрый вечер,
> 
> Возможно ли настроить HTTP Basic Authentication (auth_basic/auth_basic_user_file) так чтоб однажды успешная авторизация работала на всех субдоменах?
> 
> Евгений
> _______________________________________________
> 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/20141010/454c91cf/attachment.html>

From semenukha at gmail.com  Fri Oct 10 14:44:05 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Fri, 10 Oct 2014 10:44:05 -0400
Subject: =?UTF-8?B?UmU6IDEgYmFzaWMgYXV0aCAtINC80L3QvtCz0L4g0YHRg9Cx0LTQvtC80LXQvdC+?=
 =?UTF-8?B?0LI=?=
In-Reply-To: <7063A753-0FFC-480E-A6DA-F103C055F98A@gmail.com>
References: <7063A753-0FFC-480E-A6DA-F103C055F98A@gmail.com>
Message-ID: <6039910.0zqJNXJCxe@tornado>

On Friday, October 10, 2014 05:55:33 PM Eugene Toropov wrote:
> Добрый вечер,
> 
> Возможно ли настроить HTTP Basic Authentication
> (auth_basic/auth_basic_user_file) так чтоб однажды успешная авторизация
> работала на всех субдоменах?
 
> Евгений
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Насколько я понимаю, нельзя:
http://stackoverflow.com/questions/339244/using-apaches-mod-auth-across-multiple-sub-domains-for-single-sign-on
-- 
Best regards,
Styopa Semenukha.

From eugene.toropov at gmail.com  Fri Oct 10 14:46:36 2014
From: eugene.toropov at gmail.com (Eugene Toropov)
Date: Fri, 10 Oct 2014 18:46:36 +0400
Subject: =?UTF-8?B?UmU6IDEgYmFzaWMgYXV0aCAtINC80L3QvtCz0L4g0YHRg9Cx0LTQvtC80LXQvdC+?=
 =?UTF-8?B?0LI=?=
In-Reply-To: <6039910.0zqJNXJCxe@tornado>
References: <7063A753-0FFC-480E-A6DA-F103C055F98A@gmail.com>
 <6039910.0zqJNXJCxe@tornado>
Message-ID: <2C71A6B6-03E0-4D70-9971-ECA5B2C11CAC@gmail.com>

On Oct 10, 2014, at 6:44 PM, Styopa Semenukha <semenukha at gmail.com> wrote:

> On Friday, October 10, 2014 05:55:33 PM Eugene Toropov wrote:
>> Добрый вечер,
>> 
>> Возможно ли настроить HTTP Basic Authentication
>> (auth_basic/auth_basic_user_file) так чтоб однажды успешная авторизация
>> работала на всех субдоменах?
> 
>> Евгений
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> Насколько я понимаю, нельзя:
> http://stackoverflow.com/questions/339244/using-apaches-mod-auth-across-multiple-sub-domains-for-single-sign-on
> -- 
> Best regards,
> Styopa Semenukha.

Похоже на то. Спасибо. Хороших выходных :)

Евгений

From nginx-forum at nginx.us  Mon Oct 13 07:19:10 2014
From: nginx-forum at nginx.us (ole-lukoje)
Date: Mon, 13 Oct 2014 03:19:10 -0400
Subject: =?UTF-8?B?0JrQsNC6INC/0LXRgNC10LTQsNGC0Ywgbmdpbngg0LTQuNGA0LXQutGC0LjQstGD?=
 =?UTF-8?B?INGB0LXRgNCy0LXRgNGDID8=?=
Message-ID: <b1eceb4582dfd7513891d79445d17607.NginxMailingListRussian@forum.nginx.org>

Здравствуйте.
Нужно передать значения 2ух директив nginx (1 из них от подключаемого модуля
comet) проксируемому серверу.

В конфиге параметры заданы:
push_stream_longpolling_connection_ttl     5m;
proxy_buffer_size        64k;

Делаю так:
proxy_set_header X-Comet-Session-Timeout
$push_stream_longpolling_connection_ttl;
#proxy_set_header X-Buffer-Size $proxy_buffer_size;

Получаю:
[emerg] unknown "push_stream_longpolling_connection_ttl" variable
(или [emerg] unknown "proxy_buffer_size" variable, если раскомментирована
директива выше).

Вопрос: 
можно ли, не прибегая к дублированию настроек вида (аналогично для
proxy_buffer_size)
set $push_stream_longpolling_connection_ttl "5m";
proxy_set_header X-Comet-Session-Timeout
$push_stream_longpolling_connection_ttl;
, передать значение директив ?


nginx version: nginx/1.5.8
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54)

Буду ждать любого отклика :)

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


From nginx-forum at nginx.us  Mon Oct 13 10:05:11 2014
From: nginx-forum at nginx.us (ole-lukoje)
Date: Mon, 13 Oct 2014 06:05:11 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdC00LDRgtGMIG5naW54INC00LjRgNC10LrRgtC4?=
 =?UTF-8?B?0LLRgyDRgdC10YDQstC10YDRgyA/?=
In-Reply-To: <b1eceb4582dfd7513891d79445d17607.NginxMailingListRussian@forum.nginx.org>
References: <b1eceb4582dfd7513891d79445d17607.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1f590222088071405d3d6ed2d6380c6b.NginxMailingListRussian@forum.nginx.org>

Скажите, пжл, не все директивы поддерживают установку переменных ?
Пытался установить переменной $a значение, а потом директиве
proxy_buffer_size скормить $a, выдает 
nginx: [emerg] "proxy_buffer_size" directive invalid value in
/etc/nginx/nginx.conf:
Делал в секции server, location

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


From vbart at nginx.com  Mon Oct 13 10:38:56 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 13 Oct 2014 14:38:56 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdC00LDRgtGMIG5naW54INC00LjRgNC10LrRgtC4?=
 =?UTF-8?B?0LLRgyDRgdC10YDQstC10YDRgyA/?=
In-Reply-To: <1f590222088071405d3d6ed2d6380c6b.NginxMailingListRussian@forum.nginx.org>
References: <b1eceb4582dfd7513891d79445d17607.NginxMailingListRussian@forum.nginx.org>
 <1f590222088071405d3d6ed2d6380c6b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1603391.5pq9xdsZ59@vbart-workstation>

On Monday 13 October 2014 06:05:11 ole-lukoje wrote:
> Скажите, пжл, не все директивы поддерживают установку переменных ?
> Пытался установить переменной $a значение, а потом директиве
> proxy_buffer_size скормить $a, выдает 
> nginx: [emerg] "proxy_buffer_size" directive invalid value in
> /etc/nginx/nginx.conf:
> Делал в секции server, location
> 

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

proxy_buffer_size переменных не поддерживает.

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

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

From nginx-forum at nginx.us  Mon Oct 13 13:15:03 2014
From: nginx-forum at nginx.us (ole-lukoje)
Date: Mon, 13 Oct 2014 09:15:03 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdC00LDRgtGMIG5naW54INC00LjRgNC10LrRgtC4?=
 =?UTF-8?B?0LLRgyDRgdC10YDQstC10YDRgyA/?=
In-Reply-To: <1603391.5pq9xdsZ59@vbart-workstation>
References: <1603391.5pq9xdsZ59@vbart-workstation>
Message-ID: <d51d41cc3ed550dc761f38f3c435d064.NginxMailingListRussian@forum.nginx.org>

ну, ясно, это прискорбно. 

Спасибо большое за объяснение, Валентин !

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


From nginx-forum at nginx.us  Tue Oct 14 09:42:54 2014
From: nginx-forum at nginx.us (JohnBat26)
Date: Tue, 14 Oct 2014 05:42:54 -0400
Subject: =?UTF-8?B?ZnVuY3Rpb24gbmd4IG1lbWNtcDog0L7Qs9GA0LDQvdC40YfQtdC90LjQtSDQv9C+?=
 =?UTF-8?B?INC/0LDQvNGP0YLQuC4=?=
Message-ID: <226443397d26b7bc7e7904a1c7bc1839.NginxMailingListRussian@forum.nginx.org>

Привет всем.
Использую модуль nginx_push_stream_module для реализации push-механизма
server -> browser.
В определенный момент, когда очередной клиент пытается встать на канал,
начинает возвращаться ошибка: unable to allocate shared memory for channel 

Вот кусок кода в модуле где он [nginx_push_stream_module] пытается выделить
канал:

        channel = ngx_http_push_stream_find_channel(cur->id,
r->connection->log, mcf);
        if (channel == NULL) {
            // channel not found
            ngx_shmtx_unlock(&shpool->mutex);
            ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "push stream
module: unable to allocate shared memory for channel %s", cur->id->data);
            return NGX_HTTP_INTERNAL_SERVER_ERROR;
        }
Как видим, если ngx_http_push_stream_find_channel вернул NULL то вылетает
эта ошибка.

В свою очередь ngx_http_push_stream_find_channel использует nginx функцию
ngx_memn2cmp:

rc = ngx_memn2cmp(id->data, channel->id.data, id->len, channel->id.len);
        if (rc == 0) {
            return channel;
        }
Та в свою очередь использует уже ngx_memcmp в самом nginx:

ngx_memn2cmp(u_char *s1, u_char *s2, size_t n1, size_t n2)
{
    size_t     n;
    ngx_int_t  m, z;

    if (n1 <= n2) {
        n = n1;
        z = -1;

    } else {
        n = n2;
        z = 1;
    }

    m = ngx_memcmp(s1, s2, n);

    if (m || n1 == n2) {
        return m;
    }

    return z;
}

Вопросы:
- в каком случае может не хватить памяти для ngx_memcmp?
- что она точно делает? как я понял, это сравнение памяти.
- сейчас каждый воркер потребляет 30 мб всего 16 воркеров.
- как настроить систему, nginx или и то и то, чтобы ошибка больше не
проявлялалась

В системе еще 6 гб свободно памяти.

Ссылки на код модуля:

https://github.com/wandenberg/nginx-push-stream-module/blob/e802241cad3d5d1c1e63828f5f55a6f8a2f1be1e/src/ngx_http_push_stream_module_subscriber.c#L188

https://github.com/wandenberg/nginx-push-stream-module/blob/e802241cad3d5d1c1e63828f5f55a6f8a2f1be1e/src/ngx_http_push_stream_rbtree_util.c#L37

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


From mdounin at mdounin.ru  Tue Oct 14 10:00:35 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Oct 2014 14:00:35 +0400
Subject: =?UTF-8?B?UmU6IGZ1bmN0aW9uIG5neCBtZW1jbXA6INC+0LPRgNCw0L3QuNGH0LXQvdC40LUg?=
 =?UTF-8?B?0L/QviDQv9Cw0LzRj9GC0Lgu?=
In-Reply-To: <226443397d26b7bc7e7904a1c7bc1839.NginxMailingListRussian@forum.nginx.org>
References: <226443397d26b7bc7e7904a1c7bc1839.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141014100035.GI31276@mdounin.ru>

Hello!

On Tue, Oct 14, 2014 at 05:42:54AM -0400, JohnBat26 wrote:

> Привет всем.
> Использую модуль nginx_push_stream_module для реализации push-механизма
> server -> browser.
> В определенный момент, когда очередной клиент пытается встать на канал,
> начинает возвращаться ошибка: unable to allocate shared memory for channel 
> 
> Вот кусок кода в модуле где он [nginx_push_stream_module] пытается выделить
> канал:
> 
>         channel = ngx_http_push_stream_find_channel(cur->id,
> r->connection->log, mcf);
>         if (channel == NULL) {
>             // channel not found
>             ngx_shmtx_unlock(&shpool->mutex);
>             ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "push stream
> module: unable to allocate shared memory for channel %s", cur->id->data);
>             return NGX_HTTP_INTERNAL_SERVER_ERROR;
>         }
> Как видим, если ngx_http_push_stream_find_channel вернул NULL то вылетает
> эта ошибка.

Судя по коду, текст ошибки - копипаста из другого места и/или 
следствие замысловатого хода мысли автора модуля (что-нибудь вроде 
"нет нужного id, зачит мы его удалили, значит у нас кончалась 
память и мы его удалили").

Правильная причина указана в комментарии - канал с соответствующим 
идентификатором не найден.

[...]

> Вопросы:
> - в каком случае может не хватить памяти для ngx_memcmp?
> - что она точно делает? как я понял, это сравнение памяти.

Да, это сравнение памяти.  "Не хватить памяти" для сравнения - не 
может, по определению.  См. выше.

> - сейчас каждый воркер потребляет 30 мб всего 16 воркеров.
> - как настроить систему, nginx или и то и то, чтобы ошибка больше не
> проявлялалась

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

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


From nginx-forum at nginx.us  Tue Oct 14 10:13:43 2014
From: nginx-forum at nginx.us (JohnBat26)
Date: Tue, 14 Oct 2014 06:13:43 -0400
Subject: =?UTF-8?B?UmU6IGZ1bmN0aW9uIG5neCBtZW1jbXA6INC+0LPRgNCw0L3QuNGH0LXQvdC40LUg?=
 =?UTF-8?B?0L/QviDQv9Cw0LzRj9GC0Lgu?=
In-Reply-To: <20141014100035.GI31276@mdounin.ru>
References: <20141014100035.GI31276@mdounin.ru>
Message-ID: <572857e9d83ab1a8e643cf46e6eb51d1.NginxMailingListRussian@forum.nginx.org>

Максим, большое спасибо за развернутый и быстрый ответ !

Но возникло два вопроса:

Общая память это на все воркеры сразу?  или на каждый?

Это та память, которую модуль под себя запрашивает, и если превышает то
может получить ошибку от nginx ?

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


From mdounin at mdounin.ru  Tue Oct 14 10:49:34 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Oct 2014 14:49:34 +0400
Subject: =?UTF-8?B?UmU6IGZ1bmN0aW9uIG5neCBtZW1jbXA6INC+0LPRgNCw0L3QuNGH0LXQvdC40LUg?=
 =?UTF-8?B?0L/QviDQv9Cw0LzRj9GC0Lgu?=
In-Reply-To: <572857e9d83ab1a8e643cf46e6eb51d1.NginxMailingListRussian@forum.nginx.org>
References: <20141014100035.GI31276@mdounin.ru>
 <572857e9d83ab1a8e643cf46e6eb51d1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141014104934.GJ31276@mdounin.ru>

Hello!

On Tue, Oct 14, 2014 at 06:13:43AM -0400, JohnBat26 wrote:

> Максим, большое спасибо за развернутый и быстрый ответ !
> 
> Но возникло два вопроса:
> 
> Общая память это на все воркеры сразу?  или на каждый?

Разделяемая память - это память, общая для всех рабочих процессов.

> Это та память, которую модуль под себя запрашивает, и если превышает то
> может получить ошибку от nginx ?

Разделяемая память выделяется при запуске nginx'а, и затем 
полученный кусок памяти модуль использует по своему усмотрению.  
Если ошибка будет, то при запуске.

Обычно в документации указывается, какие объекты храняться в 
разделяемой памяти и сколько места нужно для хранения 
определённого количества объектов.  По крайней мере для 
официальных модулей это так, см. например 
http://nginx.org/r/limit_conn_zone/ru.  Размер разделяемой памяти 
имеет смысл задавать исходя из того, сколько объектов 
предполагается хранить.

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


From nginx-forum at nginx.us  Tue Oct 14 11:02:56 2014
From: nginx-forum at nginx.us (JohnBat26)
Date: Tue, 14 Oct 2014 07:02:56 -0400
Subject: =?UTF-8?B?UmU6IGZ1bmN0aW9uIG5neCBtZW1jbXA6INC+0LPRgNCw0L3QuNGH0LXQvdC40LUg?=
 =?UTF-8?B?0L/QviDQv9Cw0LzRj9GC0Lgu?=
In-Reply-To: <20141014104934.GJ31276@mdounin.ru>
References: <20141014104934.GJ31276@mdounin.ru>
Message-ID: <eaae22fd392dca57103732c567e2aeb2.NginxMailingListRussian@forum.nginx.org>

Максим спасибо!

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


From nginx-forum at nginx.us  Tue Oct 14 11:55:23 2014
From: nginx-forum at nginx.us (rreimche)
Date: Tue, 14 Oct 2014 07:55:23 -0400
Subject: =?UTF-8?B?bWlzaXRlMS5ydSDQvtGC0LrRgNGL0LLQsNC10YLRgdGPLCBzdWJkb21haW4ubXlz?=
 =?UTF-8?B?aXRlMS5ydSDQvdC10YIsIHN1YmRvbWFpbi5teXNpdGUyLnJ1INC00LA=?=
Message-ID: <1fcd372b4b711f883ee65b483cfe69c6.NginxMailingListRussian@forum.nginx.org>

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

На моём сервер работает несколько сайтов на nginx. Как серверы имён я
использую сервис zonomi.com

Сейчас получается странная ситуация:
ping mysite1.com ? OK
ping subdomain.mysite1.com ? OK
ping mysite2.ru ? OK
ping subdomain.mysite2.ru ? unknown host

mysite1.com и subdomain.mysite1.com и subdomain.mysite2.ru сконфигурированы
для wordpress, mysite2.ru ? для drupal.

Вообще, в моём понимании, если пинг доходит до domainname.zone, то должен и
до subdomain.domainname.zone и эта ситуация меня немного фрустрирует. В чём
может быть дело?

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


From vsjcfm at gmail.com  Tue Oct 14 11:56:42 2014
From: vsjcfm at gmail.com (Anton Sayetsky)
Date: Tue, 14 Oct 2014 14:56:42 +0300
Subject: =?UTF-8?B?UmU6IG1pc2l0ZTEucnUg0L7RgtC60YDRi9Cy0LDQtdGC0YHRjywgc3ViZG9tYWlu?=
 =?UTF-8?B?Lm15c2l0ZTEucnUg0L3QtdGCLCBzdWJkb21haW4ubXlzaXRlMi5ydSDQtNCw?=
In-Reply-To: <1fcd372b4b711f883ee65b483cfe69c6.NginxMailingListRussian@forum.nginx.org>
References: <1fcd372b4b711f883ee65b483cfe69c6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFG2KC+VgwY69jkSNw+x7NOQczoh3EoPBx154746-_CAJxdc3A@mail.gmail.com>

nginx не имеет никакого отношения к проблемам резолвера DNS

14 октября 2014 г., 14:55 пользователь rreimche <nginx-forum at nginx.us> написал:
> Здравствуйте.
>
> На моём сервер работает несколько сайтов на nginx. Как серверы имён я
> использую сервис zonomi.com
>
> Сейчас получается странная ситуация:
> ping mysite1.com ? OK
> ping subdomain.mysite1.com ? OK
> ping mysite2.ru ? OK
> ping subdomain.mysite2.ru ? unknown host
>
> mysite1.com и subdomain.mysite1.com и subdomain.mysite2.ru сконфигурированы
> для wordpress, mysite2.ru ? для drupal.
>
> Вообще, в моём понимании, если пинг доходит до domainname.zone, то должен и
> до subdomain.domainname.zone и эта ситуация меня немного фрустрирует. В чём
> может быть дело?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253970,253970#msg-253970
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From sytar.alex at gmail.com  Wed Oct 15 08:03:01 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Wed, 15 Oct 2014 12:03:01 +0400
Subject: unknown directive "server_names_hash_bucket_size:"
Message-ID: <CAKqRTSFG4zgGhxGFzPkJ5RDjHBAm7iOqo5B+dRZ6diF=CDAFkA@mail.gmail.com>

[!] root at UVM-PG-PROD-TEST at nginx >:/ sudo apt-get install nginx
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  nginx
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/384 kB of archives.
After this operation, 1 005 kB of additional disk space will be used.
Selecting previously unselected package nginx.
(Reading database ... 61375 files and directories currently installed.)
Preparing to unpack .../nginx_1.6.2-1~trusty_amd64.deb ...
----------------------------------------------------------------------

Thanks for using nginx!

Please find the official documentation for nginx here:
* http://nginx.org/en/docs/

Commercial subscriptions for nginx are available on:
* http://nginx.com/products/

----------------------------------------------------------------------
Unpacking nginx (1.6.2-1~trusty) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up nginx (1.6.2-1~trusty) ...
nginx: [emerg] could not build the server_names_hash, you should
increase server_names_hash_bucket_size: 32
invoke-rc.d: initscript nginx, action "start" failed.

[!] root at UVM-PG-PROD-TEST at nginx >:/ sudo service nginx restart
 * Restarting nginx nginx

                                       nginx: [emerg] unknown
directive "server_names_hash_bucket_size:" in /etc/nginx/nginx.conf:43
nginx: configuration file /etc/nginx/nginx.conf test failed


Что ему нужно и как побороть?

apt-cache policy nginx
nginx:
  Installed: 1.6.2-1~trusty
  Candidate: 1.6.2-1~trusty
  Version table:
 *** 1.6.2-1~trusty 0
        500 http://nginx.org/packages/ubuntu/ trusty/nginx amd64 Packages
        100 /var/lib/dpkg/status
     1.4.6-1ubuntu3.1 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty-security/main
amd64 Packages
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty-updates/main
amd64 Packages
     1.4.6-1ubuntu3 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages


nginx -V
nginx version: nginx/1.6.2
built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
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_flv_module --with-http_mp4_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-mail --with-mail_ssl_module --with-file-aio
--with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions
-Wl,-z,relro -Wl,--as-needed' --with-ipv6


From stalker at altlinux.ru  Wed Oct 15 08:31:55 2014
From: stalker at altlinux.ru (Anton Gorlov)
Date: Wed, 15 Oct 2014 12:31:55 +0400
Subject: unknown directive "server_names_hash_bucket_size:"
In-Reply-To: <CAKqRTSFG4zgGhxGFzPkJ5RDjHBAm7iOqo5B+dRZ6diF=CDAFkA@mail.gmail.com>
References: <CAKqRTSFG4zgGhxGFzPkJ5RDjHBAm7iOqo5B+dRZ6diF=CDAFkA@mail.gmail.com>
Message-ID: <543E30FB.3020701@altlinux.ru>

Так как Вы не привели конфигурацию, а телепаты немного устали -
предположу,  что у Вас данная директива прописана не в той секции.
Она должна быть прописана в секции http
http {
    server_names_hash_bucket_size 64;
...

15.10.2014 12:03, Aleksandr Sytar пишет:
> [!] root at UVM-PG-PROD-TEST at nginx >:/ sudo service nginx restart
>  * Restarting nginx nginx
>
>                                        nginx: [emerg] unknown
> directive "server_names_hash_bucket_size:" in /etc/nginx/nginx.conf:43
> nginx: configuration file /etc/nginx/nginx.conf test failed


From vbart at nginx.com  Wed Oct 15 08:51:02 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 15 Oct 2014 12:51:02 +0400
Subject: unknown directive "server_names_hash_bucket_size:"
In-Reply-To: <CAKqRTSFG4zgGhxGFzPkJ5RDjHBAm7iOqo5B+dRZ6diF=CDAFkA@mail.gmail.com>
References: <CAKqRTSFG4zgGhxGFzPkJ5RDjHBAm7iOqo5B+dRZ6diF=CDAFkA@mail.gmail.com>
Message-ID: <2625960.KcdlAPhKaN@vbart-laptop>

On Wednesday 15 October 2014 12:03:01 Aleksandr Sytar wrote:
> [!] root at UVM-PG-PROD-TEST at nginx >:/ sudo apt-get install nginx
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following NEW packages will be installed:
>   nginx
> 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
> Need to get 0 B/384 kB of archives.
> After this operation, 1 005 kB of additional disk space will be used.
> Selecting previously unselected package nginx.
> (Reading database ... 61375 files and directories currently installed.)
> Preparing to unpack .../nginx_1.6.2-1~trusty_amd64.deb ...
> ----------------------------------------------------------------------
> 
> Thanks for using nginx!
> 
> Please find the official documentation for nginx here:
> * http://nginx.org/en/docs/
> 
> Commercial subscriptions for nginx are available on:
> * http://nginx.com/products/
> 
> ----------------------------------------------------------------------
> Unpacking nginx (1.6.2-1~trusty) ...
> Processing triggers for ureadahead (0.100.0-16) ...
> Setting up nginx (1.6.2-1~trusty) ...
> nginx: [emerg] could not build the server_names_hash, you should
> increase server_names_hash_bucket_size: 32
> invoke-rc.d: initscript nginx, action "start" failed.
> 
> [!] root at UVM-PG-PROD-TEST at nginx >:/ sudo service nginx restart
>  * Restarting nginx nginx
> 
>                                        nginx: [emerg] unknown
> directive "server_names_hash_bucket_size:" in /etc/nginx/nginx.conf:43
> nginx: configuration file /etc/nginx/nginx.conf test failed
> 
> 
> Что ему нужно и как побороть?
> 
[..]

Есть директива "server_names_hash_bucket_size" , а такой директивы,
как "server_names_hash_bucket_size:"  - не существует.

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


From sytar.alex at gmail.com  Wed Oct 15 08:52:25 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Wed, 15 Oct 2014 12:52:25 +0400
Subject: unknown directive "server_names_hash_bucket_size:"
In-Reply-To: <543E30FB.3020701@altlinux.ru>
References: <CAKqRTSFG4zgGhxGFzPkJ5RDjHBAm7iOqo5B+dRZ6diF=CDAFkA@mail.gmail.com>
 <543E30FB.3020701@altlinux.ru>
Message-ID: <CAKqRTSGRguRpRcY9toL9Q5HNpDxz0-fYXNHB6KGOZypuhpkyMQ@mail.gmail.com>

15 октября 2014 г., 12:31 пользователь Anton Gorlov
<stalker at altlinux.ru> написал:
> Так как Вы не привели конфигурацию, а телепаты немного устали -
> предположу,  что у Вас данная директива прописана не в той секции.
> Она должна быть прописана в секции http
> http {
>     server_names_hash_bucket_size 64;
> ...
>
> 15.10.2014 12:03, Aleksandr Sytar пишет:
>> [!] root at UVM-PG-PROD-TEST at nginx >:/ sudo service nginx restart
>>  * Restarting nginx nginx
>>
>>                                        nginx: [emerg] unknown
>> directive "server_names_hash_bucket_size:" in /etc/nginx/nginx.conf:43
>> nginx: configuration file /etc/nginx/nginx.conf test failed
>


Директива прописана там где и должна быть в секции http.

Методом перебора установлено что не взлетает в следующей конфигурации:

server {
        listen 80 default_server;
        server_name obs-test.bbp;
}

server {
        listen 80;
        server_name docs.obs-test.bbp;
}


где docs - это CNAME


Что тут не так?

From sytar.alex at gmail.com  Wed Oct 15 08:55:06 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Wed, 15 Oct 2014 12:55:06 +0400
Subject: unknown directive "server_names_hash_bucket_size:"
In-Reply-To: <2625960.KcdlAPhKaN@vbart-laptop>
References: <CAKqRTSFG4zgGhxGFzPkJ5RDjHBAm7iOqo5B+dRZ6diF=CDAFkA@mail.gmail.com>
 <2625960.KcdlAPhKaN@vbart-laptop>
Message-ID: <CAKqRTSE-_RuL8b0U5=2NHCiChVTWfNKJm7Ntq3kSPcu4u7F-NA@mail.gmail.com>

2014-10-15 12:51 GMT+04:00 Валентин Бартенев <vbart at nginx.com>:
> On Wednesday 15 October 2014 12:03:01 Aleksandr Sytar wrote:
>> [!] root at UVM-PG-PROD-TEST at nginx >:/ sudo apt-get install nginx
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> The following NEW packages will be installed:
>>   nginx
>> 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
>> Need to get 0 B/384 kB of archives.
>> After this operation, 1 005 kB of additional disk space will be used.
>> Selecting previously unselected package nginx.
>> (Reading database ... 61375 files and directories currently installed.)
>> Preparing to unpack .../nginx_1.6.2-1~trusty_amd64.deb ...
>> ----------------------------------------------------------------------
>>
>> Thanks for using nginx!
>>
>> Please find the official documentation for nginx here:
>> * http://nginx.org/en/docs/
>>
>> Commercial subscriptions for nginx are available on:
>> * http://nginx.com/products/
>>
>> ----------------------------------------------------------------------
>> Unpacking nginx (1.6.2-1~trusty) ...
>> Processing triggers for ureadahead (0.100.0-16) ...
>> Setting up nginx (1.6.2-1~trusty) ...
>> nginx: [emerg] could not build the server_names_hash, you should
>> increase server_names_hash_bucket_size: 32
>> invoke-rc.d: initscript nginx, action "start" failed.
>>
>> [!] root at UVM-PG-PROD-TEST at nginx >:/ sudo service nginx restart
>>  * Restarting nginx nginx
>>
>>                                        nginx: [emerg] unknown
>> directive "server_names_hash_bucket_size:" in /etc/nginx/nginx.conf:43
>> nginx: configuration file /etc/nginx/nginx.conf test failed
>>
>>
>> Что ему нужно и как побороть?
>>
> [..]
>
> Есть директива "server_names_hash_bucket_size" , а такой директивы,
> как "server_names_hash_bucket_size:"  - не существует.

Блин, понял.


From andrei.seredenko at gmail.com  Wed Oct 15 11:49:38 2014
From: andrei.seredenko at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCh0LXRgNC10LTQtdC90LrQvg==?=)
Date: Wed, 15 Oct 2014 14:49:38 +0300
Subject: =?UTF-8?B?0J4g0YbQtdC70LXRgdC+0L7QsdGA0LDQt9C90L7RgdGC0Lgg0YDQsNC30LzQtdGJ?=
 =?UTF-8?B?0LXQvdC40Y8g0LrQtdGI0LAgTmdpbngg0LIgdG1wZnMgKExpbnV4KQ==?=
Message-ID: <CAK1EO=V6e31_cf7=vQF3yjUPyxOx1y==NjizUm-J_4yhqkvtHg@mail.gmail.com>

Привет сообществу!

Ребят, возник такой вопрос:


а есть ли профит от размещения кеша Nginx'а на tmpfs *в Linux *?


Дело в том, что когда-то, когда настраивал nginx с кешированием, натыкался
на старую рассылку, где ещё сам Игорь Сысоев рассказывал, что "*смысла в
этом нет, если только в кеш не производится много записи" **клац!
<http://markmail.org/message/hdjl6gawlvtsfwe5#query:+page:1+mid:hdjl6gawlvtsfwe5+state:results>*
Но там речь шла о FreeBSD, а не про Linux. А в каком-то другом (
очередном?:) ) холливаре про "nginx + RAM cache" тоже речь шла изначально
про фряху, где потом кто-то сказал что "да ерунда это все! в линухах tmpfs
работает как пологается", на что Игорь остановил - мол, "давайте
определимся, о какой оси речь идет: линуксы или фрибсд?" Жаль, но пруф уже
не найду..

Так вот. К чему это я всё: судя по всему, организация tmpfs во FreeBSD и
Linux'ах различается. И во фряхе размещать там кеш не всегда разумно. А как
с линуксами дело обстоит, может знает кто? Увы, у меня нет достаточных
знаний, чтобы философствовать на эту тему... но может у кого эмпирики
хватает.

purpose:

хочется отказаться от варниша в пользу nginx+cache. на данный момент
работает схема с варнишем спереди и nginx'ом в бэкенде.

Однако, при попытке убрать варниш, не было обнаружено какой-либо деградации
в синтетических тестбенчах (что весьма странно). То есть, выходило что
varnish не давал никакого профита (в синтетике) в сравнении с обычным
nginx'ом ? Поэтому встал вопрос "а можно ли вообще ускорить имеющийся
результат?" В ход пошли всякие коктейли из "pure nginx", "nginx+varnish",
"nginx+pagespeed", "nginx+cache".... <ещё с пару десятков комбинаций> ...
И вот, собсно, дошли до "nginx + tmpfs-cache + ..." Но, тк особого доверия
своим тестам нет никогда <http://eax.me/benchmarks/>, а теститься на
продакшенах бывает крайне дорого:) - хочется узнать мнения сообщества.

Спасибо!

P.s. Извините за графоманство - уж очень люблю это дело :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141015/6f5e3b75/attachment-0001.html>

From nginx-forum at nginx.us  Wed Oct 15 11:55:07 2014
From: nginx-forum at nginx.us (shambler81)
Date: Wed, 15 Oct 2014 07:55:07 -0400
Subject: auth_basic error nginx: [emerg] "auth_basic" directive is not allowed
 here in
Message-ID: <008b74b3241a4f6c851280a9b824a455.NginxMailingListRussian@forum.nginx.org>

http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html
По документации все должно работать  вот так:

if ($host ~ "(dev|pma).example.com" ) {
        auth_basic            "Website development";
        auth_basic_user_file  /var/www/domain.com/www/dev/authfile;
}


Но оно выдает: auth_basic error nginx: [emerg] "auth_basic" directive is not
allowed here in
В реалии приходится делать костыль

 error_page 555 = @pass;
                location @pass {
                auth_basic "Unauthorized"; 
                auth_basic_user_file /var/www/dev_htpasswd; 
                proxy_pass http://dev.zap-dom.ru:82;
                proxy_set_header Host dev.zap-dom.ru;
                proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
                proxy_set_header X-Real-IP $remote_addr;
                }

# В location / вписывем  условие
if ($http_host ~* "^dev\..*\..{2,8}$"){
                return 555;
                }

ПОЧЕМУ ?

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


From vbart at nginx.com  Wed Oct 15 11:58:44 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 15 Oct 2014 15:58:44 +0400
Subject: =?UTF-8?B?UmU6INCeINGG0LXQu9C10YHQvtC+0LHRgNCw0LfQvdC+0YHRgtC4INGA0LDQt9C8?=
 =?UTF-8?B?0LXRidC10L3QuNGPINC60LXRiNCwIE5naW54INCyIHRtcGZzIChMaW51eCk=?=
In-Reply-To: <CAK1EO=V6e31_cf7=vQF3yjUPyxOx1y==NjizUm-J_4yhqkvtHg@mail.gmail.com>
References: <CAK1EO=V6e31_cf7=vQF3yjUPyxOx1y==NjizUm-J_4yhqkvtHg@mail.gmail.com>
Message-ID: <1752937.s1kaoL9AqL@vbart-workstation>

On Wednesday 15 October 2014 14:49:38 Андрей Середенко wrote:
> Привет сообществу!
> 
> Ребят, возник такой вопрос:
> 
> 
> а есть ли профит от размещения кеша Nginx'а на tmpfs *в Linux *?
> 
[..]

С точки зрения производительности отдачи файлов ИМХО нет.

Единственный кейсы, который представляются, это когда нужно во что
бы то ни стало избежать записи на диск или он вовсе отсутствует.

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

From mdounin at mdounin.ru  Wed Oct 15 12:09:05 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 15 Oct 2014 16:09:05 +0400
Subject: auth_basic error nginx: [emerg] "auth_basic" directive is not
 allowed here in
In-Reply-To: <008b74b3241a4f6c851280a9b824a455.NginxMailingListRussian@forum.nginx.org>
References: <008b74b3241a4f6c851280a9b824a455.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141015120905.GO31276@mdounin.ru>

Hello!

On Wed, Oct 15, 2014 at 07:55:07AM -0400, shambler81 wrote:

> http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html
> По документации все должно работать  вот так:
> 
> if ($host ~ "(dev|pma).example.com" ) {
>         auth_basic            "Website development";
>         auth_basic_user_file  /var/www/domain.com/www/dev/authfile;
> }
> 
> 
> Но оно выдает: auth_basic error nginx: [emerg] "auth_basic" directive is not
> allowed here in

Документация говорит, что директиву auth_basic можно использовать 
в контексте "http, server, location, limit_except".  Использовать 
к контексте if директиву auth_basic нельзя.

[...]

> ПОЧЕМУ ?

http://wiki.nginx.org/IfIsEvil

Правильное решение в данном случае - отдельный блок server{}.

В общем случае - директива auth_basic понимает переменные, и 
соответственно там можно написать "Closed site" или "off" в 
зависимости от ранее проверенных условий.

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


From nginx-forum at nginx.us  Wed Oct 15 12:51:43 2014
From: nginx-forum at nginx.us (shambler81)
Date: Wed, 15 Oct 2014 08:51:43 -0400
Subject: auth_basic error nginx: [emerg] "auth_basic" directive is not
 allowed here in
In-Reply-To: <20141015120905.GO31276@mdounin.ru>
References: <20141015120905.GO31276@mdounin.ru>
Message-ID: <b979cf31666657ad11586cae8ff5f27e.NginxMailingListRussian@forum.nginx.org>

правильно ли я поимю чо нуно что-то вроде ?

set $true1
if ($http_host ~* "^(dev|www.dev)\..*\..{2,8}$"){
             auth_basic "Unauthorized";
                }
set $true2
if ($http_host ~* "^(dev|www.dev)\..*\..{2,8}$"){
            auth_basic_user_file /var/www/dev_htpasswd;
                }

.....
location / {
...
$true1
$true1

}

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


From gmm at csdoc.com  Wed Oct 15 13:04:01 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 15 Oct 2014 16:04:01 +0300
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
Message-ID: <543E70C1.9090607@csdoc.com>

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

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
Default: ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;

As most of you already know, there is an important SSLv3 vulnerability
(CVE-2014-3566 - see https://access.redhat.com/articles/1232123) ,
known as Poodle.

Возможно имеет смысл изменить значение по умолчанию для директивы
ssl_protocols, чтобы там было только "TLSv1 TLSv1.1 TLSv1.2"
или даже, только "TLSv1.1 TLSv1.2" ?

Чтобы nginx был "secure by default", прямо "из коробки".
А кому очень надо SSLv2 / SSLv3 / TLSv1 - смогут включить их вручную.

И второй вопрос, поскольку SSL уже фактически не осталось,
может быть имеет смысл все директивы ssl_******** переименовать
в tls_******** ? Так чтобы одновременно поддерживались и те и другие,
а со временем ssl_***** стали deprecated и потом removed ?

Аналогично, "ssl" => "tls" или "ssl" => "secure"
в параметре директивы listen.

"HTTPS" ведь расшифровывается как "HTTP Secure".

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Wed Oct 15 13:32:23 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 15 Oct 2014 17:32:23 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <543E70C1.9090607@csdoc.com>
References: <543E70C1.9090607@csdoc.com>
Message-ID: <20141015133223.GP31276@mdounin.ru>

Hello!

On Wed, Oct 15, 2014 at 04:04:01PM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
> Default: ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
> 
> As most of you already know, there is an important SSLv3 vulnerability
> (CVE-2014-3566 - see https://access.redhat.com/articles/1232123) ,
> known as Poodle.
> 
> Возможно имеет смысл изменить значение по умолчанию для директивы
> ssl_protocols, чтобы там было только "TLSv1 TLSv1.1 TLSv1.2"
> или даже, только "TLSv1.1 TLSv1.2" ?
> 
> Чтобы nginx был "secure by default", прямо "из коробки".
> А кому очень надо SSLv2 / SSLv3 / TLSv1 - смогут включить их вручную.

Убирать TLSv1 - совершенно точно очень плохая идея.  Это, в 
частности, отсечёт OpenSSL старее 1.0.1, что выглядит, мягко 
говоря, преждевременно.

Мысль убрать SSLv3 по умолчанию носится в воздухе, но я пока не 
уверен в правильности этого действия.

> И второй вопрос, поскольку SSL уже фактически не осталось,
> может быть имеет смысл все директивы ssl_******** переименовать
> в tls_******** ? Так чтобы одновременно поддерживались и те и другие,
> а со временем ssl_***** стали deprecated и потом removed ?

Изменение названия на TLS - это политические реверансы времён 
стандартизации.  Если же посмотреть в данные, то так называемый 
TLS, так называемой версии 1.0 - это SSL версии 3.1.  Так и живём.  
Бегать по этим граблям лишний раз - IMHO, малопродуктивное 
занятие, пусть остаётся как есть.

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


From mdounin at mdounin.ru  Wed Oct 15 13:46:07 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 15 Oct 2014 17:46:07 +0400
Subject: auth_basic error nginx: [emerg] "auth_basic" directive is not
 allowed here in
In-Reply-To: <b979cf31666657ad11586cae8ff5f27e.NginxMailingListRussian@forum.nginx.org>
References: <20141015120905.GO31276@mdounin.ru>
 <b979cf31666657ad11586cae8ff5f27e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141015134607.GQ31276@mdounin.ru>

Hello!

On Wed, Oct 15, 2014 at 08:51:43AM -0400, shambler81 wrote:

> правильно ли я поимю чо нуно что-то вроде ?
> 
> set $true1
> if ($http_host ~* "^(dev|www.dev)\..*\..{2,8}$"){
>              auth_basic "Unauthorized";
>                 }
> set $true2
> if ($http_host ~* "^(dev|www.dev)\..*\..{2,8}$"){
>             auth_basic_user_file /var/www/dev_htpasswd;
>                 }
> 
> .....
> location / {
> ...
> $true1
> $true1

Нет.

Во-первых, как уже было сказано, в данном случае - правильным 
решением будет сделать два отдельных блока server{}:

    server {
        server_name  example.com;

        # public site, no auth_basic here

        ...
    }

    server {
        server_name  dev.example.com  www.dev.example.com;

        auth_basic "Closed site";
        auth_basic_user_file /path/to/htpasswd;

        ...
    }

Во-вторых, переменные можно использовать в качестве параметра 
директивы, а не вместо неё в конфиге.  Т.е. в общем случае можно 
требовать или не требовать аутентификацию как-то так:


    set $realm "Closed site";

    if (...auth required...) {
        set $realm "off";
    }

    auth_basic $realm;
    auth_basic_user_file /path/to/htpasswd;

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


From gmm at csdoc.com  Wed Oct 15 16:06:30 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 15 Oct 2014 19:06:30 +0300
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141015133223.GP31276@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
Message-ID: <543E9B86.9070509@csdoc.com>

On 15.10.2014 16:32, Maxim Dounin wrote:

>> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
>> Default: ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>>
>> As most of you already know, there is an important SSLv3 vulnerability
>> (CVE-2014-3566 - see https://access.redhat.com/articles/1232123) ,
>> known as Poodle.
>>
>> Возможно имеет смысл изменить значение по умолчанию для директивы
>> ssl_protocols, чтобы там было только "TLSv1 TLSv1.1 TLSv1.2"
>> или даже, только "TLSv1.1 TLSv1.2" ?
>>
>> Чтобы nginx был "secure by default", прямо "из коробки".
>> А кому очень надо SSLv2 / SSLv3 / TLSv1 - смогут включить их вручную.
>
> Убирать TLSv1 - совершенно точно очень плохая идея.  Это, в
> частности, отсечёт OpenSSL старее 1.0.1, что выглядит, мягко
> говоря, преждевременно.
>
> Мысль убрать SSLv3 по умолчанию носится в воздухе, но я пока не
> уверен в правильности этого действия.

Древней версии IE 6.0 много только в Китае:
https://www.modern.ie/en-us/ie6countdown

- Таким образом они будут вынуждены поставить себе
на Windows XP более новые/современные версии браузеров.
Тот же Firefox или Chromium/Chrome/Opera. Давно пора.

Потому что в версии IE 6.0 очень много уязвимостей.
Из-за чего - в Китае есть очень много виндовых ботнетов
из зомби-машин. Заражаются они в интернете (в том числе)
через уязвимости в браузере или уязвимые плагины к нему.

Создатели сайтов будут очень рады, если им не придется
больше поддерживать (древние версии) Internet Explorer.

Mozilla в Firefox поддержку SSL 3.0 выключит по-умолчанию:
http://www.opennet.ru/opennews/art.shtml?num=40833
Новый вид атаки на HTTPS ставит под вопрос дальнейшее существование SSL 3.0

>> И второй вопрос, поскольку SSL уже фактически не осталось,
>> может быть имеет смысл все директивы ssl_******** переименовать
>> в tls_******** ? Так чтобы одновременно поддерживались и те и другие,
>> а со временем ssl_***** стали deprecated и потом removed ?
>
> Изменение названия на TLS - это политические реверансы времён
> стандартизации.  Если же посмотреть в данные, то так называемый
> TLS, так называемой версии 1.0 - это SSL версии 3.1.  Так и живём.
> Бегать по этим граблям лишний раз - IMHO, малопродуктивное
> занятие, пусть остаётся как есть.
>

Понял, спасибо.

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Wed Oct 15 17:40:54 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 15 Oct 2014 21:40:54 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <543E9B86.9070509@csdoc.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com>
Message-ID: <20141015174054.GS31276@mdounin.ru>

Hello!

On Wed, Oct 15, 2014 at 07:06:30PM +0300, Gena Makhomed wrote:

> On 15.10.2014 16:32, Maxim Dounin wrote:
> 
> >>http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
> >>Default: ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
> >>
> >>As most of you already know, there is an important SSLv3 vulnerability
> >>(CVE-2014-3566 - see https://access.redhat.com/articles/1232123) ,
> >>known as Poodle.
> >>
> >>Возможно имеет смысл изменить значение по умолчанию для директивы
> >>ssl_protocols, чтобы там было только "TLSv1 TLSv1.1 TLSv1.2"
> >>или даже, только "TLSv1.1 TLSv1.2" ?
> >>
> >>Чтобы nginx был "secure by default", прямо "из коробки".
> >>А кому очень надо SSLv2 / SSLv3 / TLSv1 - смогут включить их вручную.
> >
> >Убирать TLSv1 - совершенно точно очень плохая идея.  Это, в
> >частности, отсечёт OpenSSL старее 1.0.1, что выглядит, мягко
> >говоря, преждевременно.
> >
> >Мысль убрать SSLv3 по умолчанию носится в воздухе, но я пока не
> >уверен в правильности этого действия.
> 
> Древней версии IE 6.0 много только в Китае:
> https://www.modern.ie/en-us/ie6countdown

SSLv3 - это, как показывает практика, не только IE6.  Только в 
рамках нашего маленького офиса уже есть жертвы - у коллеги 
отвалился IRC-клиент в связи с запретом SSLv3 на серверной 
стороне.  При этом более или менее очевидно, что проблемы 
при использовании IRС - нет.

Ну и да, 11% IE6 в Китае - это _очень_ много, а 0.6% в России - 
это тоже не то чтобы мало, когда речь идёт об абсолютных цифрах.

При этом, на самом деле, проблема, как она есть - не в том, что в 
SSLv3 есть уязвимость.  Проблема в первую очередь в том, что MitM 
может легко убедить даже современный браузер использовать SSLv3.  
И именно эту проблему надо решать в первую очередь, IMHO.  
Собственно, это сейчас и делается со стороны браузеров, см.  
например у Adam'а Langley тут:

https://www.imperialviolet.org/2014/10/14/poodle.html

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


From dreik.da at gmail.com  Wed Oct 15 21:27:54 2014
From: dreik.da at gmail.com (Sergey 'dreik' Kolesnik)
Date: Thu, 16 Oct 2014 01:27:54 +0400
Subject: =?UTF-8?B?0J3QtdC+0LbQuNC00LDQvdC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUgbG9jYXRp?=
 =?UTF-8?B?b24=?=
Message-ID: <CAP-J4wV04Ds4k2=X+fCoZ1eD8nELCOb+4L-u_tBHrKWu0+WVMw@mail.gmail.com>

Доброго времени суток!

Наткнулся на неожиданное поведение location в случае правила следующего
вида:

location ~ ^/lenin.. { return 302 http://www.test.com/leningrad/; }

Если пойти по ссылке вида http://www.test.com/leninzhiv/ то указанное выше
правило так же сработает, чего в свою очередь быть, мне кажется, не должно.

На всякий случай:

~# nginx -V
nginx version: nginx/1.7.6
built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid
--without-http_uwsgi_module --without-http_scgi_module
--with-http_addition_module --with-http_gzip_static_module
--with-http_spdy_module --with-http_realip_module
--with-http_stub_status_module --with-http_ssl_module --with-ipv6
--add-module=/opt/src/ngx_pagespeed-release-1.9.32.1-beta

WBR,
Sergey 'dreik' Kolesnik
Skype: dreik.lc
Cell: +7 (921) 943-5237
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141016/db257f30/attachment-0001.html>

From onokonem at gmail.com  Wed Oct 15 21:49:39 2014
From: onokonem at gmail.com (Daniel Podolsky)
Date: Thu, 16 Oct 2014 01:49:39 +0400
Subject: =?UTF-8?B?UmU6INCd0LXQvtC20LjQtNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IGxv?=
 =?UTF-8?B?Y2F0aW9u?=
In-Reply-To: <CAP-J4wV04Ds4k2=X+fCoZ1eD8nELCOb+4L-u_tBHrKWu0+WVMw@mail.gmail.com>
References: <CAP-J4wV04Ds4k2=X+fCoZ1eD8nELCOb+4L-u_tBHrKWu0+WVMw@mail.gmail.com>
Message-ID: <CAKaHDOGUv8ZAA72GZxxrST3XHahvSEc=7a+5oBaWd-w4pm3v9w@mail.gmail.com>

2014-10-16 1:27 GMT+04:00 Sergey 'dreik' Kolesnik <dreik.da at gmail.com>:
> location ~ ^/lenin.. { return 302 http://www.test.com/leningrad/; }
тут написано "строка начинается с /lenin, потом идет любой символ,
потом еще один любой символ"
"/leninzhiv/" вполне соответствует описанию, правда?

From dreik.da at gmail.com  Wed Oct 15 22:11:20 2014
From: dreik.da at gmail.com (Sergey 'dreik' Kolesnik)
Date: Thu, 16 Oct 2014 02:11:20 +0400
Subject: =?UTF-8?B?UmU6INCd0LXQvtC20LjQtNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IGxv?=
 =?UTF-8?B?Y2F0aW9u?=
In-Reply-To: <CAKaHDOGUv8ZAA72GZxxrST3XHahvSEc=7a+5oBaWd-w4pm3v9w@mail.gmail.com>
References: <CAP-J4wV04Ds4k2=X+fCoZ1eD8nELCOb+4L-u_tBHrKWu0+WVMw@mail.gmail.com>
 <CAKaHDOGUv8ZAA72GZxxrST3XHahvSEc=7a+5oBaWd-w4pm3v9w@mail.gmail.com>
Message-ID: <CAP-J4wWMf_nq4oV-EaaMA2WrT0kMjs2ZfQ8QpFi8yNZNGFDnxQ@mail.gmail.com>

Забыл включить мозг. Виноват - дурак, каюсь.
Спасибо!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141016/b4bb4e2e/attachment.html>

From chipitsine at gmail.com  Thu Oct 16 04:05:27 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 16 Oct 2014 10:05:27 +0600
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141015133223.GP31276@mdounin.ru>
References: <543E70C1.9090607@csdoc.com>
	<20141015133223.GP31276@mdounin.ru>
Message-ID: <CAFHpkQGqdtSEpJFsC7AbiMDQAMkXrGk988K5tE=ihZXmQpLrZQ@mail.gmail.com>

любопытства ради залогировали ssl_protocol, в общем SSLv3 встречается
у 0.1% пользователей, разброс операционок от WinXP до Win 8.1

причина, вероятно, в пользовательских антивирусах, которые MITM-ом
вклиниваются в TLS.
не думаю, чтобы пользователи принудительно убирали себе галочки с TLS
и оставляли только SSL

15 октября 2014 г., 19:32 пользователь Maxim Dounin
<mdounin at mdounin.ru> написал:
> Hello!
>
> On Wed, Oct 15, 2014 at 04:04:01PM +0300, Gena Makhomed wrote:
>
>> Здравствуйте, All!
>>
>> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
>> Default: ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>>
>> As most of you already know, there is an important SSLv3 vulnerability
>> (CVE-2014-3566 - see https://access.redhat.com/articles/1232123) ,
>> known as Poodle.
>>
>> Возможно имеет смысл изменить значение по умолчанию для директивы
>> ssl_protocols, чтобы там было только "TLSv1 TLSv1.1 TLSv1.2"
>> или даже, только "TLSv1.1 TLSv1.2" ?
>>
>> Чтобы nginx был "secure by default", прямо "из коробки".
>> А кому очень надо SSLv2 / SSLv3 / TLSv1 - смогут включить их вручную.
>
> Убирать TLSv1 - совершенно точно очень плохая идея.  Это, в
> частности, отсечёт OpenSSL старее 1.0.1, что выглядит, мягко
> говоря, преждевременно.
>
> Мысль убрать SSLv3 по умолчанию носится в воздухе, но я пока не
> уверен в правильности этого действия.
>
>> И второй вопрос, поскольку SSL уже фактически не осталось,
>> может быть имеет смысл все директивы ssl_******** переименовать
>> в tls_******** ? Так чтобы одновременно поддерживались и те и другие,
>> а со временем ssl_***** стали deprecated и потом removed ?
>
> Изменение названия на TLS - это политические реверансы времён
> стандартизации.  Если же посмотреть в данные, то так называемый
> TLS, так называемой версии 1.0 - это SSL версии 3.1.  Так и живём.
> Бегать по этим граблям лишний раз - IMHO, малопродуктивное
> занятие, пусть остаётся как есть.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From chipitsine at gmail.com  Thu Oct 16 04:07:15 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 16 Oct 2014 10:07:15 +0600
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141015174054.GS31276@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
Message-ID: <CAFHpkQE7n-hBsv=SgONTtcOyb4QM+9Z-Z5uJ4KQKYF=JEj4r4w@mail.gmail.com>

15 октября 2014 г., 23:40 пользователь Maxim Dounin
<mdounin at mdounin.ru> написал:
> Hello!
>
> On Wed, Oct 15, 2014 at 07:06:30PM +0300, Gena Makhomed wrote:
>
>> On 15.10.2014 16:32, Maxim Dounin wrote:
>>
>> >>http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
>> >>Default: ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>> >>
>> >>As most of you already know, there is an important SSLv3 vulnerability
>> >>(CVE-2014-3566 - see https://access.redhat.com/articles/1232123) ,
>> >>known as Poodle.
>> >>
>> >>Возможно имеет смысл изменить значение по умолчанию для директивы
>> >>ssl_protocols, чтобы там было только "TLSv1 TLSv1.1 TLSv1.2"
>> >>или даже, только "TLSv1.1 TLSv1.2" ?
>> >>
>> >>Чтобы nginx был "secure by default", прямо "из коробки".
>> >>А кому очень надо SSLv2 / SSLv3 / TLSv1 - смогут включить их вручную.
>> >
>> >Убирать TLSv1 - совершенно точно очень плохая идея.  Это, в
>> >частности, отсечёт OpenSSL старее 1.0.1, что выглядит, мягко
>> >говоря, преждевременно.
>> >
>> >Мысль убрать SSLv3 по умолчанию носится в воздухе, но я пока не
>> >уверен в правильности этого действия.
>>
>> Древней версии IE 6.0 много только в Китае:
>> https://www.modern.ie/en-us/ie6countdown
>
> SSLv3 - это, как показывает практика, не только IE6.  Только в
> рамках нашего маленького офиса уже есть жертвы - у коллеги
> отвалился IRC-клиент в связи с запретом SSLv3 на серверной
> стороне.  При этом более или менее очевидно, что проблемы
> при использовании IRС - нет.
>
> Ну и да, 11% IE6 в Китае - это _очень_ много, а 0.6% в России -
> это тоже не то чтобы мало, когда речь идёт об абсолютных цифрах.
>
> При этом, на самом деле, проблема, как она есть - не в том, что в
> SSLv3 есть уязвимость.  Проблема в первую очередь в том, что MitM
> может легко убедить даже современный браузер использовать SSLv3.

https://www.openssl.org/news/secadv_20141015.txt


SSL 3.0 Fallback protection
===========================

Severity: Medium

OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
to block the ability for a MITM attacker to force a protocol
downgrade.



> И именно эту проблему надо решать в первую очередь, IMHO.
> Собственно, это сейчас и делается со стороны браузеров, см.
> например у Adam'а Langley тут:
>
> https://www.imperialviolet.org/2014/10/14/poodle.html
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From postmaster at softsearch.ru  Thu Oct 16 07:10:18 2014
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Thu, 16 Oct 2014 11:10:18 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <CAFHpkQGqdtSEpJFsC7AbiMDQAMkXrGk988K5tE=ihZXmQpLrZQ@mail.gmail.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <CAFHpkQGqdtSEpJFsC7AbiMDQAMkXrGk988K5tE=ihZXmQpLrZQ@mail.gmail.com>
Message-ID: <117441963.20141016111018@softsearch.ru>

Здравствуйте, Илья.

> любопытства ради залогировали ssl_protocol, в общем SSLv3 встречается
> у 0.1% пользователей, разброс операционок от WinXP до Win 8.1

> причина, вероятно, в пользовательских антивирусах, которые MITM-ом
> вклиниваются в TLS.
> не думаю, чтобы пользователи принудительно убирали себе галочки с TLS
> и оставляли только SSL

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

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


From aa.vasilenko at gmail.com  Thu Oct 16 08:15:21 2014
From: aa.vasilenko at gmail.com (Alex Vasilenko)
Date: Thu, 16 Oct 2014 11:15:21 +0300
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <CAFHpkQE7n-hBsv=SgONTtcOyb4QM+9Z-Z5uJ4KQKYF=JEj4r4w@mail.gmail.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <CAFHpkQE7n-hBsv=SgONTtcOyb4QM+9Z-Z5uJ4KQKYF=JEj4r4w@mail.gmail.com>
Message-ID: <CAJLyKy273w9xsx4_Nx+VLHx1RuyMRfMvSP5CvZ6NQhEQAwyzAQ@mail.gmail.com>

16 октября 2014 г., 7:07 пользователь Илья Шипицин <chipitsine at gmail.com>
написал:
>
> SSL 3.0 Fallback protection
> ===========================
>
> Severity: Medium
>
> OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
> to block the ability for a MITM attacker to force a protocol
> downgrade.


Кто-нибудь подскажет, можно ли это включить в nginx и как?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141016/db801fc6/attachment.html>

From sytar.alex at gmail.com  Thu Oct 16 11:35:22 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Thu, 16 Oct 2014 15:35:22 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141015133223.GP31276@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
Message-ID: <CAKqRTSE1SgEB0rh=tce9dSy00hdJUq1bhPiiQWtW1TyKonh=rw@mail.gmail.com>

15 октября 2014 г., 17:32 пользователь Maxim Dounin
<mdounin at mdounin.ru> написал:
> Мысль убрать SSLv3 по умолчанию носится в воздухе, но я пока не
> уверен в правильности этого действия.

А тем временем в Яндексе решил воспользоваться моментом:

"Отключили SSLv3 на Яндекс.Паспорте: https://t.co/b37iBiLWi4 смотрим
на другие сервисы. Все под контролем. #POODLE" -
https://twitter.com/ivladdalvi/status/522711602223910913

From mdounin at mdounin.ru  Thu Oct 16 13:43:55 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 16 Oct 2014 17:43:55 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <CAJLyKy273w9xsx4_Nx+VLHx1RuyMRfMvSP5CvZ6NQhEQAwyzAQ@mail.gmail.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <CAFHpkQE7n-hBsv=SgONTtcOyb4QM+9Z-Z5uJ4KQKYF=JEj4r4w@mail.gmail.com>
 <CAJLyKy273w9xsx4_Nx+VLHx1RuyMRfMvSP5CvZ6NQhEQAwyzAQ@mail.gmail.com>
Message-ID: <20141016134355.GD16333@mdounin.ru>

Hello!

On Thu, Oct 16, 2014 at 11:15:21AM +0300, Alex Vasilenko wrote:

> 16 октября 2014 г., 7:07 пользователь Илья Шипицин <chipitsine at gmail.com>
> написал:
> >
> > SSL 3.0 Fallback protection
> > ===========================
> >
> > Severity: Medium
> >
> > OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
> > to block the ability for a MITM attacker to force a protocol
> > downgrade.
> 
> 
> Кто-нибудь подскажет, можно ли это включить в nginx и как?

Это не надо никак включать в nginx, оно заработает само после 
обновления OpenSSL'я.  (При условии, естественно, что клиент его 
тоже умеет.)

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


From gmm at csdoc.com  Thu Oct 16 19:16:00 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 16 Oct 2014 22:16:00 +0300
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141015174054.GS31276@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
Message-ID: <54401970.1070305@csdoc.com>

On 15.10.2014 20:40, Maxim Dounin wrote:

>>> Мысль убрать SSLv3 по умолчанию носится в воздухе,
>>> но я пока не уверен в правильности этого действия.
>>
>> Древней версии IE 6.0 много только в Китае:
>> https://www.modern.ie/en-us/ie6countdown
>
> SSLv3 - это, как показывает практика, не только IE6.  Только в
> рамках нашего маленького офиса уже есть жертвы - у коллеги
> отвалился IRC-клиент в связи с запретом SSLv3 на серверной
> стороне.  При этом более или менее очевидно, что проблемы
> при использовании IRС - нет.
>
> Ну и да, 11% IE6 в Китае - это _очень_ много, а 0.6% в России -
> это тоже не то чтобы мало, когда речь идёт об абсолютных цифрах.
>
> При этом, на самом деле, проблема, как она есть - не в том, что в
> SSLv3 есть уязвимость.  Проблема в первую очередь в том, что MitM
> может легко убедить даже современный браузер использовать SSLv3.
> И именно эту проблему надо решать в первую очередь, IMHO.
> Собственно, это сейчас и делается со стороны браузеров, см.
> например у Adam'а Langley тут:
>
> https://www.imperialviolet.org/2014/10/14/poodle.html

Поддержка TLS_FALLBACK_SCSV должна быть и на стороне клиента
и на стороне сервера, иначе эта защита работать не будет.

Цитата оттуда: "...SSLv3 was deprecated very nearly 15 years ago"

Если отключить SSLv3 по умолчанию - это пока что плохая идея,
может быть имеет смысл выдавать deprecation warning, если nginx
при тесте конфига увидит, что включены протоколы SSLv3 или SSLv2 ?

Учитывая, что браузеры планируют полностью выключить поддержку
протокола SSLv3 по умолчанию, - рано или поздно протокол SSLv3
будет выключен по умолчанию и в nginx, как это произошло с SSLv2.

Deprecation warning может быть, например, в таком виде:

Warning! Protocol SSLv2 deprecated.
Details: http://nginx.com/warning/SSLv3-is-insecure/

Warning! Protocol SSLv3 deprecated.
Details: http://nginx.com/warning/SSLv3-is-insecure/

На странице будут подробно расписаны все нюансы с этим протоколом,
и каждый сисадмин тогда сам будет принимать решение, что ему делать,
выключать или оставить SSLv3 включенным и прописать suppress_warning.

======================================================================

Для тех системных администраторов, которым необходимо держать SSLv3 
включенным и которые осознают все последствия от своих действий -
можно добавить новую директиву suppress_warning <url>;
где <url> - это полный url варнинга, который вручную был suppressed.

Действие директивы suppress_warnings распостраняется только
на одну непосредственно следующую за ней директиву конфига,
которая не является директивой suppress_warning.
Например:

suppress_warning http://nginx.com/warning/SSLv2-is-insecure/;

suppress_warning http://nginx.com/warning/SSLv3-is-insecure/;

ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;

В результате: информация о том, что есть проблемы с протоколом SSLv3
будет видна или в логах/на екране или же прямо в конфиге nginx.

Сейчас - значение по умолчанию не является безопасным,
но nginx об этом своих пользователей не предупреждает.

Понятное дело, что только ради протокола SSLv3 добавлять механизм
suppress_warning в nginx смысла нет. Но таким же унифицированным
образом можно предупреждать пользователя nginx о любых других
проблемах c небезопасными настройками, давая возможность подавить
предупреждения, если пользователь думает что он знает, что делает.

-- 
Best regards,
  Gena


From gmm at csdoc.com  Thu Oct 16 19:48:46 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 16 Oct 2014 22:48:46 +0300
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141016134355.GD16333@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <CAFHpkQE7n-hBsv=SgONTtcOyb4QM+9Z-Z5uJ4KQKYF=JEj4r4w@mail.gmail.com>
 <CAJLyKy273w9xsx4_Nx+VLHx1RuyMRfMvSP5CvZ6NQhEQAwyzAQ@mail.gmail.com>
 <20141016134355.GD16333@mdounin.ru>
Message-ID: <5440211E.4020809@csdoc.com>

On 16.10.2014 16:43, Maxim Dounin wrote:

>>> SSL 3.0 Fallback protection
>>> ===========================
>>>
>>> Severity: Medium
>>>
>>> OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
>>> to block the ability for a MITM attacker to force a protocol
>>> downgrade.
>>
>> Кто-нибудь подскажет, можно ли это включить в nginx и как?
>
> Это не надо никак включать в nginx, оно заработает само после
> обновления OpenSSL'я.  (При условии, естественно, что клиент его
> тоже умеет.)

Кстати, тут есть еще один нюанс. Если клиент умеет TLSv1.1 и TLSv1,
а на сервере включено только TLSv1.2 и TLSv1 и если они оба умеют 
TLS_FALLBACK_SCSV - тогда The two will never talk to each other.
Подробности:

http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/

Поэтому - будет опасно на сервере включать поддержку TLSv1.2 и TLSv1
и при этом выключать TLSv1.1, если сервер умеет TLS_FALLBACK_SCSV
- похоже что это еще один повод для warning`а при тесте конфига.

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Thu Oct 16 20:36:24 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Oct 2014 00:36:24 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <54401970.1070305@csdoc.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <54401970.1070305@csdoc.com>
Message-ID: <20141016203624.GQ16333@mdounin.ru>

Hello!

On Thu, Oct 16, 2014 at 10:16:00PM +0300, Gena Makhomed wrote:

> On 15.10.2014 20:40, Maxim Dounin wrote:
> 
> >>>Мысль убрать SSLv3 по умолчанию носится в воздухе,
> >>>но я пока не уверен в правильности этого действия.
> >>
> >>Древней версии IE 6.0 много только в Китае:
> >>https://www.modern.ie/en-us/ie6countdown
> >
> >SSLv3 - это, как показывает практика, не только IE6.  Только в
> >рамках нашего маленького офиса уже есть жертвы - у коллеги
> >отвалился IRC-клиент в связи с запретом SSLv3 на серверной
> >стороне.  При этом более или менее очевидно, что проблемы
> >при использовании IRС - нет.
> >
> >Ну и да, 11% IE6 в Китае - это _очень_ много, а 0.6% в России -
> >это тоже не то чтобы мало, когда речь идёт об абсолютных цифрах.
> >
> >При этом, на самом деле, проблема, как она есть - не в том, что в
> >SSLv3 есть уязвимость.  Проблема в первую очередь в том, что MitM
> >может легко убедить даже современный браузер использовать SSLv3.
> >И именно эту проблему надо решать в первую очередь, IMHO.
> >Собственно, это сейчас и делается со стороны браузеров, см.
> >например у Adam'а Langley тут:
> >
> >https://www.imperialviolet.org/2014/10/14/poodle.html
> 
> Поддержка TLS_FALLBACK_SCSV должна быть и на стороне клиента
> и на стороне сервера, иначе эта защита работать не будет.

Существует более одного способа решить проблему fallback'а.  
Например, его можно банально запретить.  Но даже если говорить про 
TLS_FALLBACK_SCSV, то это уже сейчас - половина браузеров и 
есть серверная сторона.

> Если отключить SSLv3 по умолчанию - это пока что плохая идея,
> может быть имеет смысл выдавать deprecation warning, если nginx
> при тесте конфига увидит, что включены протоколы SSLv3 или SSLv2 ?

IMHO, не имеет.  Администраторы всё-таки не дети, и рассказывать 
им, какие протоколы включать, а какие нет - это не совсем задача 
http-сервера.  Да и подробный анализ всевозможных деталей 
кофигурации SSL с помощью nginx'а всё равно не сделаешь - хотя бы 
потому, что скорость обновления не отвечает реалиям быстро 
меняющегося окружающего мира.  Для этого есть гораздо более 
продвинутые инструменты, например - ssllabs.com.

И, кстати, пользуясь случаем, отрекламирую недавно вышедшую книжку 
Ivan Risti? из SSL Labs, "Bulletproof SSL and TLS":

http://www.feistyduck.com/books/bulletproof-ssl-and-tls/

> Учитывая, что браузеры планируют полностью выключить поддержку
> протокола SSLv3 по умолчанию, - рано или поздно протокол SSLv3
> будет выключен по умолчанию и в nginx, как это произошло с SSLv2.

Рано или поздно - будет, безусловно.

Но, если проблема fallback'а таки будет решена, то нет особых 
причин это делать рано.

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


From nginx-forum at nginx.us  Fri Oct 17 07:37:21 2014
From: nginx-forum at nginx.us (igor.goncharenko)
Date: Fri, 17 Oct 2014 03:37:21 -0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <543E70C1.9090607@csdoc.com>
References: <543E70C1.9090607@csdoc.com>
Message-ID: <bb23d8afbec2c078c2ad7891b7cefcb3.NginxMailingListRussian@forum.nginx.org>

Интересно, вот я выключил sslv3 в ssl_protocols, можно ли как-то увидеть в
логе, что клиент пытается установить соединение по sslv3? 

---
Igor

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


From gmm at csdoc.com  Fri Oct 17 11:34:38 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Fri, 17 Oct 2014 14:34:38 +0300
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141016203624.GQ16333@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <54401970.1070305@csdoc.com> <20141016203624.GQ16333@mdounin.ru>
Message-ID: <5440FECE.6050200@csdoc.com>

On 16.10.2014 23:36, Maxim Dounin wrote:

>>>>> Мысль убрать SSLv3 по умолчанию носится в воздухе,
>>>>> но я пока не уверен в правильности этого действия.
>>>>
>>>> Древней версии IE 6.0 много только в Китае:
>>>> https://www.modern.ie/en-us/ie6countdown
>>>
>>> SSLv3 - это, как показывает практика, не только IE6.  Только в
>>> рамках нашего маленького офиса уже есть жертвы - у коллеги
>>> отвалился IRC-клиент в связи с запретом SSLv3 на серверной
>>> стороне.  При этом более или менее очевидно, что проблемы
>>> при использовании IRС - нет.

Разве IRC-клиент подключается к nginx по протоколу http/https?

Если говорить про SSLv3 в контексте сервера nginx, есть ли
другие причины включать SSLv3 по умолчанию, кроме IE 6.0 ?

>>> Ну и да, 11% IE6 в Китае - это _очень_ много, а 0.6% в России -
>>> это тоже не то чтобы мало, когда речь идёт об абсолютных цифрах.

При этом, IE 6.0 умеет работать по протоколу TLSv1, но в майкрософте
решили перестраховаться и по умолчанию этот протокол просто выключен.

Включить его достаточно легко, всего один чекбокс переключить надо:
http://www.ci.lacey.wa.us/living-in-lacey/online-services/online-utility-bill-payments/how-to-enable-tls-in-ie-6.0

Может ли nginx определить, что к нему пытаются подключиться по SSLv3,
и в этом случае обработать запрос клиента в другом server,
в котором вместо сайта будет инструкция по включению TLSv1
в настройках клиентского браузера (Internet Explorer 6.0)
или рекомендация обновить браузер / обновить антивирус ?

Многие сайты не хотят потерять ни одного клиента и вместе с тем,
не хотят разрешать на сайте SSLv3 из-за POODLE SSLv3 Vulnerability.

Вообще идеально, если таким же вариантом можно будет обработать
попытки подключения по любой версии протокола, в том числе
и TLSv1 и TLSv1.1 - вдруг там тоже со временем найдут
критические уязвимости, аналогичные POODLE в SSLv3 ?

Тогда часть сайтов сможет оставить включенными у себя только
TLSv1.1 и TLSv1.2, например, чтобы полностью защититься от BEAST,
и вместе с тем быть user friendly к пользователям старых браузеров.

И заодно этот вариант будет использоваться создателями сайтов
для того чтобы простимулировать пользователей заапгрейдить браузер.
Тогда в интернете будет меньше зомби-машин и меньше ддос-атак/спама.

Это актуально в связи с тем, что сейчас все массово переходят на HTTPS:
http://habrahabr.ru/post/232629/ Google повышает сайты с HTTPS в выдаче

>> Если отключить SSLv3 по умолчанию - это пока что плохая идея,
>> может быть имеет смысл выдавать deprecation warning, если nginx
>> при тесте конфига увидит, что включены протоколы SSLv3 или SSLv2 ?
>
> IMHO, не имеет.  Администраторы всё-таки не дети, и рассказывать
> им, какие протоколы включать, а какие нет - это не совсем задача
> http-сервера.

Имхо многие администраторы полагают, что nginx настроен
в режиме "secure by default", а не "vulnerable by default".

Даже если nginx будет собран с самой последней версией OpenSSL,
которая умеет TLS_FALLBACK_SCSV - он всеравно будет vulnerable,
если по умолчанию останется включен SSLv3 - для очень большого
числа клиентских браузеров, которые не умеют TLS_FALLBACK_SCSV

> Да и подробный анализ всевозможных деталей
> кофигурации SSL с помощью nginx'а всё равно не сделаешь - хотя бы
> потому, что скорость обновления не отвечает реалиям быстро
> меняющегося окружающего мира.  Для этого есть гораздо более
> продвинутые инструменты, например - ssllabs.com.
>
> И, кстати, пользуясь случаем, отрекламирую недавно вышедшую книжку
> Ivan Risti? из SSL Labs, "Bulletproof SSL and TLS":
>
> http://www.feistyduck.com/books/bulletproof-ssl-and-tls/

Если эта информация будет полезна большинству пользователей nginx
при настройке SSL/HTTPS - может быть лучше будет разместить ссылку
на книгу "Bulletproof SSL and TLS" прямо на сайте http://nginx.org/,
в статье http://nginx.org/en/docs/http/configuring_https_servers.html
Там же была бы полезной и ссылка на https://www.ssllabs.com/ssltest/

Ivan Risti? из SSL Labs вряд ли будет против рекламы сервиса/книги.

>> Учитывая, что браузеры планируют полностью выключить поддержку
>> протокола SSLv3 по умолчанию, - рано или поздно протокол SSLv3
>> будет выключен по умолчанию и в nginx, как это произошло с SSLv2.
>
> Рано или поздно - будет, безусловно.
>
> Но, если проблема fallback'а таки будет решена, то нет особых
> причин это делать рано.

Кроме самых новых версий Firefox/Chrome на руках и пользователей
остается ведь очень много и других, более старых версий браузеров.
Которые умеют TLSv1 и которым для нормальной работы не нужен SSLv3.

Решить проблему fallback`а - это на несколько порядков более сложная
задача, чем "заставить" пользователей перестать пользоваться IE 6.0.

Как это можно сделать в сети, если вот уже более 10 лет
так и не удается решить проблему прекращения использования IE 6.0.

-- 
Best regards,
  Gena


From gmm at csdoc.com  Fri Oct 17 12:18:30 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Fri, 17 Oct 2014 15:18:30 +0300
Subject: SSL 3 is dead, killed by the POODLE attack
Message-ID: <54410916.5040508@csdoc.com>


Кстати, Ivan Risti? из SSL Labs считает, что:

SSL 3 is dead, killed by the POODLE attack
https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack

И рекомендует всем системным администраторам:

[...] As a web site operator, you should disable SSL 3
on your servers as soon as possible. You need to do this
even if you support the most recent TLS version [...]

Кстати, на сайте nginx.com эта рекомендация уже выполнена:
https://www.ssllabs.com/ssltest/analyze.html?d=nginx.com

P.S.

Всеравно не понятно, почему нельзя в следующей версии
по умолчанию сделать ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

И в CHANGELOG написать о том, что протокол SSLv3 по умолчанию выключен.

"Администраторы всё-таки не дети", и читать CHANGELOG перед апгрейдом
они ведь умеют. Кому этот протокол действительно надо - включат обратно.

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Fri Oct 17 12:50:51 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Oct 2014 16:50:51 +0400
Subject: SSL 3 is dead, killed by the POODLE attack
In-Reply-To: <54410916.5040508@csdoc.com>
References: <54410916.5040508@csdoc.com>
Message-ID: <20141017125051.GB35211@mdounin.ru>

Hello!

On Fri, Oct 17, 2014 at 03:18:30PM +0300, Gena Makhomed wrote:

> 
> Кстати, Ivan Risti? из SSL Labs считает, что:
> 
> SSL 3 is dead, killed by the POODLE attack
> https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack
> 
> И рекомендует всем системным администраторам:
> 
> [...] As a web site operator, you should disable SSL 3
> on your servers as soon as possible. You need to do this
> even if you support the most recent TLS version [...]

С тех пор, как Ivan это написал, прошло уже аж два дня.  За это 
время как минимум вышел OpenSSL с fallback protection, и 
нарисовалась свежая Opera с fallback protection и anti-POODLE 
record splitting.  Если развитие ситуации и дальше пойдёт такими 
темпами - то через пару недель про POODLE можно будет забыть, как 
в своё время забыли про BEAST.

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


From mdounin at mdounin.ru  Fri Oct 17 13:24:03 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Oct 2014 17:24:03 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <5440FECE.6050200@csdoc.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <54401970.1070305@csdoc.com> <20141016203624.GQ16333@mdounin.ru>
 <5440FECE.6050200@csdoc.com>
Message-ID: <20141017132403.GD35211@mdounin.ru>

Hello!

On Fri, Oct 17, 2014 at 02:34:38PM +0300, Gena Makhomed wrote:

> On 16.10.2014 23:36, Maxim Dounin wrote:
> 
> >>>>>Мысль убрать SSLv3 по умолчанию носится в воздухе,
> >>>>>но я пока не уверен в правильности этого действия.
> >>>>
> >>>>Древней версии IE 6.0 много только в Китае:
> >>>>https://www.modern.ie/en-us/ie6countdown
> >>>
> >>>SSLv3 - это, как показывает практика, не только IE6.  Только в
> >>>рамках нашего маленького офиса уже есть жертвы - у коллеги
> >>>отвалился IRC-клиент в связи с запретом SSLv3 на серверной
> >>>стороне.  При этом более или менее очевидно, что проблемы
> >>>при использовании IRС - нет.
> 
> Разве IRC-клиент подключается к nginx по протоколу http/https?

Это к вопросу о том, что запрет SSLv3 имеет смысл не всегда, и 
может выйти боком в самых неожиданных местах.

[...]

> Может ли nginx определить, что к нему пытаются подключиться по SSLv3,
> и в этом случае обработать запрос клиента в другом server,
> в котором вместо сайта будет инструкция по включению TLSv1
> в настройках клиентского браузера (Internet Explorer 6.0)
> или рекомендация обновить браузер / обновить антивирус ?

Есть переменная $ssl_protocol, по которой можно сделать 
условную обработку, и показать желаемую страницу.  Документация 
доступна по адресу http://nginx.org/r/$ssl_protocol.

[...]

> >Но, если проблема fallback'а таки будет решена, то нет особых
> >причин это делать рано.
> 
> Кроме самых новых версий Firefox/Chrome на руках и пользователей
> остается ведь очень много и других, более старых версий браузеров.
> Которые умеют TLSv1 и которым для нормальной работы не нужен SSLv3.

Браузер, который не обновляют - это браузер, рассматривать который 
с точки зрения безопасности достаточно бессмысленно, он всё равно 
дыряв, так или иначе.  И хорошо, если в качестве дырки будет 
выступать POODLE, а не remote code execution.

С точки зрения безопасности имеет смысл рассматривать только 
актуальные версии современных браузеров.  И тут уже, судя по 
всему, проблема решена как минимум в Chrome и Opera[1], и скоро 
будет решена в Firefox.  Ждём Safari и IE.

[1] http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/

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


From mdounin at mdounin.ru  Fri Oct 17 13:25:51 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Oct 2014 17:25:51 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <bb23d8afbec2c078c2ad7891b7cefcb3.NginxMailingListRussian@forum.nginx.org>
References: <543E70C1.9090607@csdoc.com>
 <bb23d8afbec2c078c2ad7891b7cefcb3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141017132551.GE35211@mdounin.ru>

Hello!

On Fri, Oct 17, 2014 at 03:37:21AM -0400, igor.goncharenko wrote:

> Интересно, вот я выключил sslv3 в ssl_protocols, можно ли как-то увидеть в
> логе, что клиент пытается установить соединение по sslv3? 

Да, будет ошибка на уровне info:

2014/10/17 17:25:08 [info] 71979#0: *1 SSL_do_handshake() failed (SSL: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number) while SSL handshaking, client: 127.0.0.1, server: 0.0.0.0:8443

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


From bogdar at gmail.com  Fri Oct 17 18:06:49 2014
From: bogdar at gmail.com (Bogdan)
Date: Fri, 17 Oct 2014 21:06:49 +0300
Subject: =?UTF-8?B?0J7RgtC60LvRjtGH0LXQvdC40LUgYWNjZXNzX2xvZyDQtNC70Y8g0L3QtdC60L4=?=
 =?UTF-8?B?0YLQvtGA0YvRhSBsb2NhdGlvbi4=?=
Message-ID: <CACz2Q8EHWfaO__-8OYNF6WhrSRCFWnHcgkJnCxw-Og11=o1mRg@mail.gmail.com>

Добрый день.

Nginx 1.2.1 (Debian 7)

Иерархия access_log примерно такая:

http {
    access_log /var/log/nginx/access.log benchmark_upstream;

server {
    server_name site.com;

    location /foo
    {
        access_log off;
    }
    access_log /var/log/nginx/site.access.log benchmark_upstream;
}
}

Хотелось бы, чтобы для /foo access-log не писался бы вообще, очевидно
access_log off я тут применил не верно, логи пишутся в site.access.log.
Как правильно отключить логи в location?

Спасибо.

-- 
WBR,  Bogdan B. Rudas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141017/5f64d41d/attachment.html>

From chmind at yandex.ru  Sun Oct 19 14:48:54 2014
From: chmind at yandex.ru (chmind at yandex.ru)
Date: Sun, 19 Oct 2014 17:48:54 +0300
Subject: location = / 
Message-ID: <958C9CD9-CF28-44A4-A6D9-1C19EBDA1751@yandex.ru>

Всем привет. 
Что я делаю не так: 

    server {
        listen 80 default_server;

	root /var/www; 

        location = / {
                access_log /var/log/nginx/root_access.log main;
        }
        location / {
                access_log /var/log/nginx/other_access.log main;
        }
    }

cat other_access.log
192.168.252.200 - - [19/Oct/2014:10:38:37 -0400] "GET / HTTP/1.1" 200 5 "-" "Gecko/20100101 Firefox/33.0" ?-"

Запрос попал во второй location, но согласно документации должен был попасть в первый. 
Почему так ? 

nginx -v
nginx version: nginx/1.6.2
CentOS 6.5


From chmind at yandex.ru  Sun Oct 19 14:51:45 2014
From: chmind at yandex.ru (chmind at yandex.ru)
Date: Sun, 19 Oct 2014 17:51:45 +0300
Subject: location = / 
Message-ID: <5BD5F267-E1D4-4190-8915-D10BA55ABE34@yandex.ru>

Всем привет. 
Что я делаю не так: 

   server {
       listen 80 default_server;

	root /var/www; 

       location = / {
               access_log /var/log/nginx/root_access.log main;
       }
       location / {
               access_log /var/log/nginx/other_access.log main;
       }
   }

cat other_access.log
192.168.252.200 - - [19/Oct/2014:10:38:37 -0400] "GET / HTTP/1.1" 200 5 "-" "Gecko/20100101 Firefox/33.0" ?-"

Запрос попал во второй location, но согласно документации должен был попасть в первый. 
Почему так ? 

nginx -v
nginx version: nginx/1.6.2
CentOS 6.5


From gmm at csdoc.com  Sun Oct 19 16:55:31 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Sun, 19 Oct 2014 19:55:31 +0300
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141017132403.GD35211@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <54401970.1070305@csdoc.com> <20141016203624.GQ16333@mdounin.ru>
 <5440FECE.6050200@csdoc.com> <20141017132403.GD35211@mdounin.ru>
Message-ID: <5443ED03.1010702@csdoc.com>

On 17.10.2014 16:24, Maxim Dounin wrote:

>> Кроме самых новых версий Firefox/Chrome на руках и пользователей
>> остается ведь очень много и других, более старых версий браузеров.
>> Которые умеют TLSv1 и которым для нормальной работы не нужен SSLv3.
>
> Браузер, который не обновляют - это браузер, рассматривать который
> с точки зрения безопасности достаточно бессмысленно, он всё равно
> дыряв, так или иначе.  И хорошо, если в качестве дырки будет
> выступать POODLE, а не remote code execution.
>
> С точки зрения безопасности имеет смысл рассматривать только
> актуальные версии современных браузеров.  И тут уже, судя по
> всему, проблема решена как минимум в Chrome и Opera[1], и скоро
> будет решена в Firefox.  Ждём Safari и IE.
>
> [1] http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/
>

Почему оставление включенным по умолчанию уязвимого протокола SSLv3
выглядит более предпочитетельным вариантом, если "с точки зрения 
безопасности" старых версий браузеров как бы и не существует?

Буква 'S' в аббревиатурах "HTTPS" и "SSL" обозначает слово "Secure".

Разве не лучше сделать сброс подключения по протоколу SSLv3 вместо
того, чтобы делать вид, что обмен данными между клиентом и сервером
надежно зашифрован и скрыт от посторонних глаз. Ведь там могут быть,
например, данные кредитных карт или другая sensitive information,
которая крайне не желательна к попаданию в руки man-in-the-middle.

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Mon Oct 20 04:13:53 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Oct 2014 08:13:53 +0400
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <5443ED03.1010702@csdoc.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <54401970.1070305@csdoc.com> <20141016203624.GQ16333@mdounin.ru>
 <5440FECE.6050200@csdoc.com> <20141017132403.GD35211@mdounin.ru>
 <5443ED03.1010702@csdoc.com>
Message-ID: <20141020041353.GH35211@mdounin.ru>

Hello!

On Sun, Oct 19, 2014 at 07:55:31PM +0300, Gena Makhomed wrote:

> On 17.10.2014 16:24, Maxim Dounin wrote:
> 
> >>Кроме самых новых версий Firefox/Chrome на руках и пользователей
> >>остается ведь очень много и других, более старых версий браузеров.
> >>Которые умеют TLSv1 и которым для нормальной работы не нужен SSLv3.
> >
> >Браузер, который не обновляют - это браузер, рассматривать который
> >с точки зрения безопасности достаточно бессмысленно, он всё равно
> >дыряв, так или иначе.  И хорошо, если в качестве дырки будет
> >выступать POODLE, а не remote code execution.
> >
> >С точки зрения безопасности имеет смысл рассматривать только
> >актуальные версии современных браузеров.  И тут уже, судя по
> >всему, проблема решена как минимум в Chrome и Opera[1], и скоро
> >будет решена в Firefox.  Ждём Safari и IE.
> >
> >[1] http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/
> >
> 
> Почему оставление включенным по умолчанию уязвимого протокола SSLv3
> выглядит более предпочитетельным вариантом, если "с точки зрения
> безопасности" старых версий браузеров как бы и не существует?

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

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


From mva at mva.name  Mon Oct 20 05:27:30 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Mon, 20 Oct 2014 12:27:30 +0700
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <20141020041353.GH35211@mdounin.ru>
References: <543E70C1.9090607@csdoc.com> <5443ED03.1010702@csdoc.com>
 <20141020041353.GH35211@mdounin.ru>
Message-ID: <5644327.0Sa8LtlZhE@note>

В письме от Пн, 20 октября 2014 08:13:53 пользователь Maxim Dounin написал:
> Потому что с точки зрения доступности сервиса - они продолжают
> быть.

Именно поэтому в апач внедрили[1] возможность сайту иметь несколько наборов 
сертификатов/ключей и выбирать в каких условиях какой отдавать. Неплохо бы и 
онтопику подтянуться...


[1] https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know (абзац "What if you need to support older 
clients")

-- 
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/20141020/eddf5512/attachment.bin>

From mdounin at mdounin.ru  Mon Oct 20 05:50:36 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Oct 2014 09:50:36 +0400
Subject: location = /
In-Reply-To: <5BD5F267-E1D4-4190-8915-D10BA55ABE34@yandex.ru>
References: <5BD5F267-E1D4-4190-8915-D10BA55ABE34@yandex.ru>
Message-ID: <20141020055035.GM35211@mdounin.ru>

Hello!

On Sun, Oct 19, 2014 at 05:51:45PM +0300, chmind at yandex.ru wrote:

> Всем привет. 
> Что я делаю не так: 
> 
>    server {
>        listen 80 default_server;
> 
> 	root /var/www; 
> 
>        location = / {
>                access_log /var/log/nginx/root_access.log main;
>        }
>        location / {
>                access_log /var/log/nginx/other_access.log main;
>        }
>    }
> 
> cat other_access.log
> 192.168.252.200 - - [19/Oct/2014:10:38:37 -0400] "GET / HTTP/1.1" 200 5 "-" "Gecko/20100101 Firefox/33.0" ?-"
> 
> Запрос попал во второй location, но согласно документации должен был попасть в первый. 
> Почему так ? 

Он сначала попал в первый, а потом - во второй.  Поскольку 
обработка завершилась во втором - там и был записан в лог.

Читать тут, в частности - последний абзац про "Обработка запроса 
"/" более сложная":

http://nginx.org/ru/docs/http/request_processing.html

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


From chmind at yandex.ru  Mon Oct 20 06:07:07 2014
From: chmind at yandex.ru (chmind at yandex.ru)
Date: Mon, 20 Oct 2014 09:07:07 +0300
Subject: location = /
In-Reply-To: <20141020055035.GM35211@mdounin.ru>
References: <5BD5F267-E1D4-4190-8915-D10BA55ABE34@yandex.ru>
 <20141020055035.GM35211@mdounin.ru>
Message-ID: <F57524B6-3A58-4991-9BC7-B6C4B24C98DE@yandex.ru>


> On Oct 20, 2014, at 08:50, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> Hello!
> 
> On Sun, Oct 19, 2014 at 05:51:45PM +0300, chmind at yandex.ru <mailto:chmind at yandex.ru> wrote:
> 
>> Всем привет. 
>> Что я делаю не так: 
>> 
>>   server {
>>       listen 80 default_server;
>> 
>> 	root /var/www; 
>> 
>>       location = / {
>>               access_log /var/log/nginx/root_access.log main;
>>       }
>>       location / {
>>               access_log /var/log/nginx/other_access.log main;
>>       }
>>   }
>> 
>> cat other_access.log
>> 192.168.252.200 - - [19/Oct/2014:10:38:37 -0400] "GET / HTTP/1.1" 200 5 "-" "Gecko/20100101 Firefox/33.0" ?-"
>> 
>> Запрос попал во второй location, но согласно документации должен был попасть в первый. 
>> Почему так ? 
> 
> Он сначала попал в первый, а потом - во второй.  Поскольку 
> обработка завершилась во втором - там и был записан в лог.
> 
> Читать тут, в частности - последний абзац про "Обработка запроса 
> "/" более сложная":
> 
> http://nginx.org/ru/docs/http/request_processing.html <http://nginx.org/ru/docs/http/request_processing.html>
> 

Получается http://nginx.org/en/docs/http/ngx_http_core_module.html#location <http://nginx.org/en/docs/http/ngx_http_core_module.html#location> 
тут документация неверная ? В примере запрос / - будет обработан в конфигурации B, а не в А как написано. Так ? 


> -- 
> Maxim Dounin
> http://nginx.org/ <http://nginx.org/>
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org <mailto:nginx-ru at nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141020/89dc20d0/attachment-0001.html>

From mdounin at mdounin.ru  Mon Oct 20 06:35:34 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Oct 2014 10:35:34 +0400
Subject: location = /
In-Reply-To: <F57524B6-3A58-4991-9BC7-B6C4B24C98DE@yandex.ru>
References: <5BD5F267-E1D4-4190-8915-D10BA55ABE34@yandex.ru>
 <20141020055035.GM35211@mdounin.ru>
 <F57524B6-3A58-4991-9BC7-B6C4B24C98DE@yandex.ru>
Message-ID: <20141020063534.GO35211@mdounin.ru>

Hello!

On Mon, Oct 20, 2014 at 09:07:07AM +0300, chmind at yandex.ru wrote:

[...]

> >> Запрос попал во второй location, но согласно документации должен был попасть в первый. 
> >> Почему так ? 
> > 
> > Он сначала попал в первый, а потом - во второй.  Поскольку 
> > обработка завершилась во втором - там и был записан в лог.
> > 
> > Читать тут, в частности - последний абзац про "Обработка запроса 
> > "/" более сложная":
> > 
> > http://nginx.org/ru/docs/http/request_processing.html <http://nginx.org/ru/docs/http/request_processing.html>
> > 
> 
> Получается http://nginx.org/en/docs/http/ngx_http_core_module.html#location <http://nginx.org/en/docs/http/ngx_http_core_module.html#location> 
> тут документация неверная ? В примере запрос / - будет обработан в конфигурации B, а не в А как написано. Так ? 

Рекомендую всё-таки прочитать то, что написано по ссылке выше.  
Особенно упомянутый последний абзац.  Даже приведу ссылку ещё раз, 
на всякий случай:

http://nginx.org/ru/docs/http/request_processing.html

Спойлер: документация - верная, но окружающий мир - немного 
сложнее, чем может показаться с первого взгляда.  В частности, в 
жизни запроса случаются перенаправления, и это приводит к тому, 
что location для обработки запроса будет выбираться заново, в 
соответствии с URI после перенаправления.

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


From chipitsine at gmail.com  Mon Oct 20 08:38:15 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 20 Oct 2014 14:38:15 +0600
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <5443ED03.1010702@csdoc.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <543E9B86.9070509@csdoc.com> <20141015174054.GS31276@mdounin.ru>
 <54401970.1070305@csdoc.com> <20141016203624.GQ16333@mdounin.ru>
 <5440FECE.6050200@csdoc.com> <20141017132403.GD35211@mdounin.ru>
 <5443ED03.1010702@csdoc.com>
Message-ID: <CAFHpkQHN2anODQWTHv-sV38Yq33u9E37KxiZ_beAX4+VTRsm2Q@mail.gmail.com>

вы можете пообщаться на тему здравого смысла с разработчиками RFC по SSL/TLS.
кажется, что они не всегда исходят от здравого смысла.

например, какая-либо сигнализация, доступная пользователю, возможно
уже после установления соединения.
т.е., если одна сторона принципиально хочет SSLv3, а другая TLS1.2, то
в браузере будет "CANNOT CONNECT" без объяснения причин.
и это by design.


но слава богу, вы можете оставить включенным SSLv3 и на основании
переменной $ssl_protocol в этом случае выдавать заранее заготовленную
страницу "вам необходимо поменять настройки браузера"


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

19 октября 2014 г., 22:55 пользователь Gena Makhomed <gmm at csdoc.com> написал:
> On 17.10.2014 16:24, Maxim Dounin wrote:
>
>>> Кроме самых новых версий Firefox/Chrome на руках и пользователей
>>> остается ведь очень много и других, более старых версий браузеров.
>>> Которые умеют TLSv1 и которым для нормальной работы не нужен SSLv3.
>>
>>
>> Браузер, который не обновляют - это браузер, рассматривать который
>> с точки зрения безопасности достаточно бессмысленно, он всё равно
>> дыряв, так или иначе.  И хорошо, если в качестве дырки будет
>> выступать POODLE, а не remote code execution.
>>
>> С точки зрения безопасности имеет смысл рассматривать только
>> актуальные версии современных браузеров.  И тут уже, судя по
>> всему, проблема решена как минимум в Chrome и Opera[1], и скоро
>> будет решена в Firefox.  Ждём Safari и IE.
>>
>> [1]
>> http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/
>>
>
> Почему оставление включенным по умолчанию уязвимого протокола SSLv3
> выглядит более предпочитетельным вариантом, если "с точки зрения
> безопасности" старых версий браузеров как бы и не существует?
>
> Буква 'S' в аббревиатурах "HTTPS" и "SSL" обозначает слово "Secure".
>
> Разве не лучше сделать сброс подключения по протоколу SSLv3 вместо
> того, чтобы делать вид, что обмен данными между клиентом и сервером
> надежно зашифрован и скрыт от посторонних глаз. Ведь там могут быть,
> например, данные кредитных карт или другая sensitive information,
> которая крайне не желательна к попаданию в руки man-in-the-middle.
>
> --
> Best regards,
>  Gena
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From chipitsine at gmail.com  Mon Oct 20 08:46:52 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 20 Oct 2014 14:46:52 +0600
Subject: CVE-2014-3566, important SSLv3 vulnerability, known as Poodle.
In-Reply-To: <CAFHpkQGqdtSEpJFsC7AbiMDQAMkXrGk988K5tE=ihZXmQpLrZQ@mail.gmail.com>
References: <543E70C1.9090607@csdoc.com> <20141015133223.GP31276@mdounin.ru>
 <CAFHpkQGqdtSEpJFsC7AbiMDQAMkXrGk988K5tE=ihZXmQpLrZQ@mail.gmail.com>
Message-ID: <CAFHpkQHc87ihJLZipO+XXmfxtQqKsAsexn7pwSVw7f+N_OyDuQ@mail.gmail.com>

есть забавная корелляция, надстройка sksb.dll (от factura.ru) приводит
к тому, что MSIE начинает общаться в SSLv3.
в процентах это в районе нуля.

в абсолютных цифрах - сотни пользователей.

16 октября 2014 г., 10:05 пользователь Илья Шипицин
<chipitsine at gmail.com> написал:
> любопытства ради залогировали ssl_protocol, в общем SSLv3 встречается
> у 0.1% пользователей, разброс операционок от WinXP до Win 8.1
>
> причина, вероятно, в пользовательских антивирусах, которые MITM-ом
> вклиниваются в TLS.
> не думаю, чтобы пользователи принудительно убирали себе галочки с TLS
> и оставляли только SSL
>
> 15 октября 2014 г., 19:32 пользователь Maxim Dounin
> <mdounin at mdounin.ru> написал:
>> Hello!
>>
>> On Wed, Oct 15, 2014 at 04:04:01PM +0300, Gena Makhomed wrote:
>>
>>> Здравствуйте, All!
>>>
>>> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
>>> Default: ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>>>
>>> As most of you already know, there is an important SSLv3 vulnerability
>>> (CVE-2014-3566 - see https://access.redhat.com/articles/1232123) ,
>>> known as Poodle.
>>>
>>> Возможно имеет смысл изменить значение по умолчанию для директивы
>>> ssl_protocols, чтобы там было только "TLSv1 TLSv1.1 TLSv1.2"
>>> или даже, только "TLSv1.1 TLSv1.2" ?
>>>
>>> Чтобы nginx был "secure by default", прямо "из коробки".
>>> А кому очень надо SSLv2 / SSLv3 / TLSv1 - смогут включить их вручную.
>>
>> Убирать TLSv1 - совершенно точно очень плохая идея.  Это, в
>> частности, отсечёт OpenSSL старее 1.0.1, что выглядит, мягко
>> говоря, преждевременно.
>>
>> Мысль убрать SSLv3 по умолчанию носится в воздухе, но я пока не
>> уверен в правильности этого действия.
>>
>>> И второй вопрос, поскольку SSL уже фактически не осталось,
>>> может быть имеет смысл все директивы ssl_******** переименовать
>>> в tls_******** ? Так чтобы одновременно поддерживались и те и другие,
>>> а со временем ssl_***** стали deprecated и потом removed ?
>>
>> Изменение названия на TLS - это политические реверансы времён
>> стандартизации.  Если же посмотреть в данные, то так называемый
>> TLS, так называемой версии 1.0 - это SSL версии 3.1.  Так и живём.
>> Бегать по этим граблям лишний раз - IMHO, малопродуктивное
>> занятие, пусть остаётся как есть.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From chipitsine at gmail.com  Mon Oct 20 09:18:27 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 20 Oct 2014 15:18:27 +0600
Subject: SSL 3 is dead, killed by the POODLE attack
In-Reply-To: <54410916.5040508@csdoc.com>
References: <54410916.5040508@csdoc.com>
Message-ID: <CAFHpkQEFVvFDHYin7n8sR20e-u=e+PsnfPq8uUg57PnGTJ_nHA@mail.gmail.com>

исходя из "Администраторы все-таки не дети", кажется, что нет разницы,
включать по умолчанию SSLv3 или выключать.

17 октября 2014 г., 18:18 пользователь Gena Makhomed <gmm at csdoc.com> написал:
>
> Кстати, Ivan Risti? из SSL Labs считает, что:
>
> SSL 3 is dead, killed by the POODLE attack
> https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack
>
> И рекомендует всем системным администраторам:
>
> [...] As a web site operator, you should disable SSL 3
> on your servers as soon as possible. You need to do this
> even if you support the most recent TLS version [...]
>
> Кстати, на сайте nginx.com эта рекомендация уже выполнена:
> https://www.ssllabs.com/ssltest/analyze.html?d=nginx.com
>
> P.S.
>
> Всеравно не понятно, почему нельзя в следующей версии
> по умолчанию сделать ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>
> И в CHANGELOG написать о том, что протокол SSLv3 по умолчанию выключен.
>
> "Администраторы всё-таки не дети", и читать CHANGELOG перед апгрейдом
> они ведь умеют. Кому этот протокол действительно надо - включат обратно.
>
> --
> Best regards,
>  Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Mon Oct 20 12:40:16 2014
From: nginx-forum at nginx.us (Klim81)
Date: Mon, 20 Oct 2014 08:40:16 -0400
Subject: =?UTF-8?B?dWlkIGdvdCB1aWQgc2V0INGA0LDQsdC+0YLQsNGO0YI/?=
Message-ID: <2eae159dfc4dd279c867af34360a697d.NginxMailingListRussian@forum.nginx.org>

Решил ввести систему отсекания ботов на уровне нгинкса... заморачиватся с
пересборкой testcookie_module не решился. 
 userid on;
 if ($uid_got = "qqk_i=5876790119") {
   return 404;
 }
и решил не выдавать плюшки, но меня не выбросило на 404, почему? 
естественно это в конфигах сервера.

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


From anatoly at sonru.com  Mon Oct 20 21:37:12 2014
From: anatoly at sonru.com (Anatoly Mikhaylov)
Date: Mon, 20 Oct 2014 22:37:12 +0100
Subject: =?UTF-8?B?0L7Qv9GC0LjQvNC40LfQsNGG0LjRjyBjbGllbnRfYm9keSDQvdCwINC80LXQtNC7?=
 =?UTF-8?B?0LXQvdC90L7QuSDRhNCw0LnQu9C+0LLQvtC5INGB0LjRgdGC0LXQvNC1?=
Message-ID: <B38C9AC6-70AC-4FA4-8566-F99DE2CDC0C8@sonru.com>

Какие оптимизации рекомендованы при использовании client_body_in_file_only on;?
Надо разобраться с минимизацией обращений к файловой системе и реиспользованию 
HTTP подключения с клиентом и бэкэндом (proxy_pass), на который идет колбек.

Условия: IO никакой (EBS), размер файла в среднем 10MB, количество файлов
для загрузки - 10, от одного клиента. Текущие настройки:

location /upload {
  sendfile                    on;
  limit_except POST          { deny all; }
  keepalive_timeout          300s;
  client_body_temp_path      /media/tmp/;
  client_body_in_file_only   on;
  client_body_buffer_size    128K;
  client_max_body_size       100M;

  proxy_pass_request_headers on;
  proxy_set_header           X-File $request_body_file; 
  proxy_set_body             off;
  proxy_redirect             off;
  proxy_pass                 https://***/server_callback
}

Смотрю в сторону client_body_in_single_buffer, tcp_nodelay, tcp_nopush, sendfile_max_chunk

О системе Linux 3.10, Red Hat 4.8.2-7.

Анатолий

From anatoly at sonru.com  Mon Oct 20 21:47:15 2014
From: anatoly at sonru.com (Anatoly Mikhaylov)
Date: Mon, 20 Oct 2014 22:47:15 +0100
Subject: =?UTF-8?B?UmU6INC+0L/RgtC40LzQuNC30LDRhtC40Y8gY2xpZW50X2JvZHkg0L3QsCDQvNC1?=
 =?UTF-8?B?0LTQu9C10L3QvdC+0Lkg0YTQsNC50LvQvtCy0L7QuSDRgdC40YHRgtC10Lw=?=
 =?UTF-8?B?0LU=?=
In-Reply-To: <B38C9AC6-70AC-4FA4-8566-F99DE2CDC0C8@sonru.com>
References: <B38C9AC6-70AC-4FA4-8566-F99DE2CDC0C8@sonru.com>
Message-ID: <8C9C925E-3E53-4B05-8AC4-908BDBEA6297@sonru.com>

Максим,

вопрос прежде всего на http://forum.nginx.org/read.php?2,220778,220840

> To limit disk I/O for big requests/responses there are following
> options available:
> 
> 1. Using larger buffers, notably client_body_buffer_size,
> proxy_buffer_size, proxy_buffers. This is basically what you've
> already done.

Хочется поподробнее узнать, что подходит в моем случае. Спасибо!

Анатолий

On Oct 20, 2014, at 10:37 PM, Anatoly Mikhaylov <anatoly at sonru.com> wrote:

> Какие оптимизации рекомендованы при использовании client_body_in_file_only on;?
> Надо разобраться с минимизацией обращений к файловой системе и реиспользованию 
> HTTP подключения с клиентом и бэкэндом (proxy_pass), на который идет колбек.
> 
> Условия: IO никакой (EBS), размер файла в среднем 10MB, количество файлов
> для загрузки - 10, от одного клиента. Текущие настройки:
> 
> location /upload {
>  sendfile                    on;
>  limit_except POST          { deny all; }
>  keepalive_timeout          300s;
>  client_body_temp_path      /media/tmp/;
>  client_body_in_file_only   on;
>  client_body_buffer_size    128K;
>  client_max_body_size       100M;
> 
>  proxy_pass_request_headers on;
>  proxy_set_header           X-File $request_body_file; 
>  proxy_set_body             off;
>  proxy_redirect             off;
>  proxy_pass                 https://***/server_callback
> }
> 
> Смотрю в сторону client_body_in_single_buffer, tcp_nodelay, tcp_nopush, sendfile_max_chunk
> 
> О системе Linux 3.10, Red Hat 4.8.2-7.
> 
> Анатолий
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From citrin at citrin.ru  Wed Oct 22 10:01:56 2014
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Wed, 22 Oct 2014 14:01:56 +0400
Subject: CVE-2014-3567
Message-ID: <54478094.6010004@citrin.ru>

Вышел очередной Security Advisory на OpenSSL:
https://www.openssl.org/news/secadv_20141015.txt

я правильно понимаю что с CVE-2014-3567 в nginx будет утечка памяти?


From aa.vasilenko at gmail.com  Wed Oct 22 10:18:48 2014
From: aa.vasilenko at gmail.com (Alex Vasilenko)
Date: Wed, 22 Oct 2014 13:18:48 +0300
Subject: CVE-2014-3567
In-Reply-To: <54478094.6010004@citrin.ru>
References: <54478094.6010004@citrin.ru>
Message-ID: <CAJLyKy2UmSmXWHM4eh77hQX6Nc4YSNA+5uEwbKYFXkAXUeyfUg@mail.gmail.com>

22 октября 2014 г., 13:01 пользователь Anton Yuzhaninov <citrin at citrin.ru>
написал:

> Вышел очередной Security Advisory на OpenSSL:
> https://www.openssl.org/news/secadv_20141015.txt
>
> я правильно понимаю что с CVE-2014-3567 в nginx будет утечка памяти?
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


Антон,

Насколько я понимаю, он вышел в тот же день вместе с фиксом POODLE. То
есть, если стоит openss вышедший после POODLE, то все ок. З.Ы. Глянул
changelog в своем CentOS 6.5, фикс для всех проблем есть:

> * Wed Oct 15 2014 Tom?? Mr?z <tmraz at redhat.com> 1.0.1e-30.2
> - fix CVE-2014-3567 - memory leak when handling session tickets
> - fix CVE-2014-3513 - memory leak in srtp support
> - add support for fallback SCSV to partially mitigate CVE-2014-3566
>   (padding attack on SSL3)



Alexandr Vasilenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141022/18630d04/attachment.html>

From vladimir at skubriev.ru  Wed Oct 22 13:11:26 2014
From: vladimir at skubriev.ru (Vladimir Skubriev)
Date: Wed, 22 Oct 2014 17:11:26 +0400
Subject: =?UTF-8?Q?server_=D0=B4=D0=BB=D1=8F_zope_managment_interface_?=
Message-ID: <927781413983486@web9h.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141022/448de0ea/attachment.html>

From vladimir at skubriev.ru  Thu Oct 23 08:01:57 2014
From: vladimir at skubriev.ru (Vladimir Skubriev)
Date: Thu, 23 Oct 2014 12:01:57 +0400
Subject: =?UTF-8?Q?Re=3A_server_=D0=B4=D0=BB=D1=8F_zope_managment_interface?=
In-Reply-To: <927781413983486@web9h.yandex.ru>
References: <927781413983486@web9h.yandex.ru>
Message-ID: <6579981414051317@web28o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141023/6a57ca2f/attachment.html>

From sytar.alex at gmail.com  Thu Oct 23 08:09:16 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Thu, 23 Oct 2014 12:09:16 +0400
Subject: =?UTF-8?Q?Re=3A_server_=D0=B4=D0=BB=D1=8F_zope_managment_interface?=
In-Reply-To: <6579981414051317@web28o.yandex.ru>
References: <927781413983486@web9h.yandex.ru>
 <6579981414051317@web28o.yandex.ru>
Message-ID: <CAKqRTSF41L5_6KYtk4rDHJfbeHfbfO8UmWTmu=CYAMMPZ4UFoA@mail.gmail.com>

2014-10-23 12:01 GMT+04:00 Vladimir Skubriev <vladimir at skubriev.ru>:

> Сейчас еще раз подумал и решил, что мне нужен rewrite, который будет
> rewrite'ить запросы от nginx к backend'у с /plone на /
>
> Я прав ?
>


localtion /plone/ {
     proxy_pass http://plone/;
}

Не нужен вам реврайт.



> 22.10.2014, 17:13, "Vladimir Skubriev" <vladimir at skubriev.ru>:
>
> Есть бэкэнд с запущенным plone сайтом и интерфейсом управления zope
>
> Есть конфиг nginx - frontend:
>
> upstream zope {
>     server 192.168.128.16:8080;
> }
>
> server {
>     # ENABLE FOR redirect always to SSL site let's go ssl only now.
>     #rewrite     ^   https://$server_name$request_uri? permanent;
>
>     listen 80;
>     server_name www.example.com;
>     access_log  /var/log/nginx/example-access.log;
>     error_log  /var/log/nginx/example-error.log;
>
>         proxy_redirect                  off;
>         proxy_set_header                Host                    $host;
>         proxy_set_header                X-Real-IP
> $remote_addr;
>         proxy_set_header                X-Forwarded-For
> $proxy_add_x_forwarded_for;
>         client_max_body_size            0;
>         client_body_buffer_size         128k;
>         proxy_connect_timeout           90;
>         proxy_send_timeout              90;
>         proxy_read_timeout              90;
>         proxy_buffer_size               4k;
>         proxy_buffers                   4 32k;
>         proxy_busy_buffers_size         64k;
>         proxy_temp_file_write_size      64k;
>
>     location / {
>         proxy_pass http://192.168.128.16:8080;
>         rewrite ^/(.*)$ /VirtualHostBase/http/
> example.ru:80/exampleru/VirtualHostRoot/$1 break;
>
>     }
>
>     location ~* /plone/ {
>         proxy_pass http://192.168.128.16:8080;
>         #rewrite ^(.*) http://192.168.128.16:8080/manage_main;
>         allow   192.168.128.0/24;
>         allow   192.168.129.0/24;
>         allow   127.0.0.1;
>         deny all;
>     }
>
> }
>
> Сайт example.com открывается, правда частично без картинок, опять же
> подозреваю, что дело в неправильном rewrite или у меня не отдает их zope.
> Но эта проблема будущего.
>
> Сейчас меня интересует как мне сделать так, чтобы интерфейс управления
> zope открывался в браузере при обращении к example.com/plone.
>
> Сам интерфейс управления(http://192.168.128.16:8080/manage_main)
> открывается вместо сайта, если закомментировать rewrite.
>
> Я даже пытался сделать отдельный location ~* /plone/, но что то пока у
> меня совсем не получается.
>
> Вопрос что неправильно я делаю в
>
>     location ~* /plone/ {
>         proxy_pass http://192.168.128.16:8080;
>         #rewrite ^(.*) http://192.168.128.16:8080/manage_main;
>         allow   192.168.128.0/24;
>         allow   192.168.129.0/24;
>         allow   127.0.0.1;
>         deny all;
>     }
>
> или ошибка совсем в другом месте ?
>
> Как это работает можете объяснить на пальцах - что за чем происходит в
> моем конкретном случае отображения интерфейса управления zope в url вида
> example.com/plone ?
>
> Самому ни как не получается разобраться.
> Можете ткнуть пальцем в документацию дополнительно. Буду благодарен.
> Спасибо.
>
>
> --
> Faithfully yours,
>
> Vladimir Skubriev
>
> ,
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> Faithfully yours,
>
> Vladimir Skubriev
>
>
> _______________________________________________
> 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/20141023/d36bed1f/attachment-0001.html>

From vladimir at skubriev.ru  Thu Oct 23 08:48:38 2014
From: vladimir at skubriev.ru (Vladimir Skubriev)
Date: Thu, 23 Oct 2014 12:48:38 +0400
Subject: =?UTF-8?Q?Re=3A_server_=D0=B4=D0=BB=D1=8F_zope_managment_interface?=
In-Reply-To: <CAKqRTSF41L5_6KYtk4rDHJfbeHfbfO8UmWTmu=CYAMMPZ4UFoA@mail.gmail.com>
References: <927781413983486@web9h.yandex.ru>
 <6579981414051317@web28o.yandex.ru>
 <CAKqRTSF41L5_6KYtk4rDHJfbeHfbfO8UmWTmu=CYAMMPZ4UFoA@mail.gmail.com>
Message-ID: <1454171414054118@web1j.yandex.ru>

Не работает возвращает текст:
<Products.Five.metaclass.Plone object at 0x7fc9b276f5d0>

Вместо интерфейса управления.

А если в location / {
#закомментировать rewrite, то сайт example.com выдает интерфейс управления.
}

Вопрос почему в location / хватает указать proxy_pass
А в location /plone/ этого не достаточно для вывода интерфейса управления.
Может быть разница в том, как nginx обращается к backend'у в зависимости от location ?


23.10.2014, 12:09, "Aleksandr Sytar" <sytar.alex at gmail.com>:
> 2014-10-23 12:01 GMT+04:00 Vladimir Skubriev <vladimir at skubriev.ru>:
>> Сейчас еще раз подумал и решил, что мне нужен rewrite, который будет rewrite'ить запросы от nginx к backend'у с /plone на /
>>
>> Я прав ?
>
> localtion /plone/ {
>      proxy_pass http://plone/;
> }
>
> Не нужен вам реврайт.
>
>> 22.10.2014, 17:13, "Vladimir Skubriev" <vladimir at skubriev.ru>:
>>> Есть бэкэнд с запущенным plone сайтом и интерфейсом управления zope
>>>
>>> Есть конфиг nginx - frontend:
>>>
>>> upstream zope {
>>>     server 192.168.128.16:8080;
>>> }
>>>
>>> server {
>>>     # ENABLE FOR redirect always to SSL site let's go ssl only now.
>>>     #rewrite     ^   https://$server_name$request_uri? permanent;
>>>
>>>     listen 80;
>>>     server_name www.example.com;
>>>     access_log  /var/log/nginx/example-access.log;
>>>     error_log  /var/log/nginx/example-error.log;
>>>
>>>         proxy_redirect                  off;
>>>         proxy_set_header                Host                    $host;
>>>         proxy_set_header                X-Real-IP               $remote_addr;
>>>         proxy_set_header                X-Forwarded-For         $proxy_add_x_forwarded_for;
>>>         client_max_body_size            0;
>>>         client_body_buffer_size         128k;
>>>         proxy_connect_timeout           90;
>>>         proxy_send_timeout              90;
>>>         proxy_read_timeout              90;
>>>         proxy_buffer_size               4k;
>>>         proxy_buffers                   4 32k;
>>>         proxy_busy_buffers_size         64k;
>>>         proxy_temp_file_write_size      64k;
>>>
>>>     location / {
>>>         proxy_pass http://192.168.128.16:8080;
>>>         rewrite ^/(.*)$ /VirtualHostBase/http/example.ru:80/exampleru/VirtualHostRoot/$1 break;
>>>
>>>     }
>>>
>>>     location ~* /plone/ {
>>>         proxy_pass http://192.168.128.16:8080;
>>>         #rewrite ^(.*) http://192.168.128.16:8080/manage_main;
>>>         allow   192.168.128.0/24;
>>>         allow   192.168.129.0/24;
>>>         allow   127.0.0.1;
>>>         deny all;
>>>     }
>>>
>>> }
>>>
>>> Сайт example.com открывается, правда частично без картинок, опять же подозреваю, что дело в неправильном rewrite или у меня не отдает их zope. Но эта проблема будущего.
>>>
>>> Сейчас меня интересует как мне сделать так, чтобы интерфейс управления zope открывался в браузере при обращении к example.com/plone.
>>>
>>> Сам интерфейс управления(http://192.168.128.16:8080/manage_main) открывается вместо сайта, если закомментировать rewrite.
>>>
>>> Я даже пытался сделать отдельный location ~* /plone/, но что то пока у меня совсем не получается.
>>>
>>> Вопрос что неправильно я делаю в
>>>
>>>     location ~* /plone/ {
>>>         proxy_pass http://192.168.128.16:8080;
>>>         #rewrite ^(.*) http://192.168.128.16:8080/manage_main;
>>>         allow   192.168.128.0/24;
>>>         allow   192.168.129.0/24;
>>>         allow   127.0.0.1;
>>>         deny all;
>>>     }
>>>
>>> или ошибка совсем в другом месте ?
>>>
>>> Как это работает можете объяснить на пальцах - что за чем происходит в моем конкретном случае отображения интерфейса управления zope в url вида example.com/plone ?
>>>
>>> Самому ни как не получается разобраться.
>>> Можете ткнуть пальцем в документацию дополнительно. Буду благодарен.
>>> Спасибо.
>>>
>>> --
>>> Faithfully yours,
>>>
>>> Vladimir Skubriev
>>>
>>> ,
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> --
>> Faithfully yours,
>>
>> Vladimir Skubriev
>>
>> _______________________________________________
>> 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

--
Faithfully yours,

Vladimir Skubriev


From sytar.alex at gmail.com  Thu Oct 23 10:45:53 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Thu, 23 Oct 2014 14:45:53 +0400
Subject: =?UTF-8?Q?Re=3A_server_=D0=B4=D0=BB=D1=8F_zope_managment_interface?=
In-Reply-To: <1454171414054118@web1j.yandex.ru>
References: <927781413983486@web9h.yandex.ru>
 <6579981414051317@web28o.yandex.ru>
 <CAKqRTSF41L5_6KYtk4rDHJfbeHfbfO8UmWTmu=CYAMMPZ4UFoA@mail.gmail.com>
 <1454171414054118@web1j.yandex.ru>
Message-ID: <CAKqRTSFAtJ3cUqBz_-VsRfp0+4tihn=cY6Xg0h+x61aZ=uvqYQ@mail.gmail.com>

23 октября 2014 г., 12:48 пользователь Vladimir Skubriev <
vladimir at skubriev.ru> написал:

> Не работает возвращает текст:
> <Products.Five.metaclass.Plone object at 0x7fc9b276f5d0>
>

кто-то к коде написал "print(что-то)" оно вам и вернулось. При чем здесь
nginx? То же самое вы должны увидеть и при запросе  через curl


> Вместо интерфейса управления.
>
> А если в location / {
> #закомментировать rewrite, то сайт example.com выдает интерфейс
> управления.
> }
>
> Вопрос почему в location / хватает указать proxy_pass
> А в location /plone/ этого не достаточно для вывода интерфейса управления.
> Может быть разница в том, как nginx обращается к backend'у в зависимости
> от location ?
>

Подозреваю нужно еще установить заголовки, например Host. Подробнее
смотрите документации к plone


>
>
> 23.10.2014, 12:09, "Aleksandr Sytar" <sytar.alex at gmail.com>:
> > 2014-10-23 12:01 GMT+04:00 Vladimir Skubriev <vladimir at skubriev.ru>:
> >> Сейчас еще раз подумал и решил, что мне нужен rewrite, который будет
> rewrite'ить запросы от nginx к backend'у с /plone на /
> >>
> >> Я прав ?
> >
> > localtion /plone/ {
> >      proxy_pass http://plone/;
> > }
> >
> > Не нужен вам реврайт.
> >
> >> 22.10.2014, 17:13, "Vladimir Skubriev" <vladimir at skubriev.ru>:
> >>> Есть бэкэнд с запущенным plone сайтом и интерфейсом управления zope
> >>>
> >>> Есть конфиг nginx - frontend:
> >>>
> >>> upstream zope {
> >>>     server 192.168.128.16:8080;
> >>> }
> >>>
> >>> server {
> >>>     # ENABLE FOR redirect always to SSL site let's go ssl only now.
> >>>     #rewrite     ^   https://$server_name$request_uri? permanent;
> >>>
> >>>     listen 80;
> >>>     server_name www.example.com;
> >>>     access_log  /var/log/nginx/example-access.log;
> >>>     error_log  /var/log/nginx/example-error.log;
> >>>
> >>>         proxy_redirect                  off;
> >>>         proxy_set_header                Host                    $host;
> >>>         proxy_set_header                X-Real-IP
> $remote_addr;
> >>>         proxy_set_header                X-Forwarded-For
> $proxy_add_x_forwarded_for;
> >>>         client_max_body_size            0;
> >>>         client_body_buffer_size         128k;
> >>>         proxy_connect_timeout           90;
> >>>         proxy_send_timeout              90;
> >>>         proxy_read_timeout              90;
> >>>         proxy_buffer_size               4k;
> >>>         proxy_buffers                   4 32k;
> >>>         proxy_busy_buffers_size         64k;
> >>>         proxy_temp_file_write_size      64k;
> >>>
> >>>     location / {
> >>>         proxy_pass http://192.168.128.16:8080;
> >>>         rewrite ^/(.*)$ /VirtualHostBase/http/
> example.ru:80/exampleru/VirtualHostRoot/$1 break;
> >>>
> >>>     }
> >>>
> >>>     location ~* /plone/ {
> >>>         proxy_pass http://192.168.128.16:8080;
> >>>         #rewrite ^(.*) http://192.168.128.16:8080/manage_main;
> >>>         allow   192.168.128.0/24;
> >>>         allow   192.168.129.0/24;
> >>>         allow   127.0.0.1;
> >>>         deny all;
> >>>     }
> >>>
> >>> }
> >>>
> >>> Сайт example.com открывается, правда частично без картинок, опять же
> подозреваю, что дело в неправильном rewrite или у меня не отдает их zope.
> Но эта проблема будущего.
> >>>
> >>> Сейчас меня интересует как мне сделать так, чтобы интерфейс управления
> zope открывался в браузере при обращении к example.com/plone.
> >>>
> >>> Сам интерфейс управления(http://192.168.128.16:8080/manage_main)
> открывается вместо сайта, если закомментировать rewrite.
> >>>
> >>> Я даже пытался сделать отдельный location ~* /plone/, но что то пока у
> меня совсем не получается.
> >>>
> >>> Вопрос что неправильно я делаю в
> >>>
> >>>     location ~* /plone/ {
> >>>         proxy_pass http://192.168.128.16:8080;
> >>>         #rewrite ^(.*) http://192.168.128.16:8080/manage_main;
> >>>         allow   192.168.128.0/24;
> >>>         allow   192.168.129.0/24;
> >>>         allow   127.0.0.1;
> >>>         deny all;
> >>>     }
> >>>
> >>> или ошибка совсем в другом месте ?
> >>>
> >>> Как это работает можете объяснить на пальцах - что за чем происходит в
> моем конкретном случае отображения интерфейса управления zope в url вида
> example.com/plone ?
> >>>
> >>> Самому ни как не получается разобраться.
> >>> Можете ткнуть пальцем в документацию дополнительно. Буду благодарен.
> >>> Спасибо.
> >>>
> >>> --
> >>> Faithfully yours,
> >>>
> >>> Vladimir Skubriev
> >>>
> >>> ,
> >>>
> >>> _______________________________________________
> >>> nginx-ru mailing list
> >>> nginx-ru at nginx.org
> >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >> --
> >> Faithfully yours,
> >>
> >> Vladimir Skubriev
> >>
> >> _______________________________________________
> >> 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
>
> --
> Faithfully yours,
>
> Vladimir Skubriev
>
> _______________________________________________
> 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/20141023/3fb18c6b/attachment.html>

From _lsv_ at bk.ru  Fri Oct 24 01:51:36 2014
From: _lsv_ at bk.ru (=?UTF-8?B?UyBM?=)
Date: Fri, 24 Oct 2014 05:51:36 +0400
Subject: nginx environment directives
Message-ID: <1414115496.236291929@f224.i.mail.ru>

 Добрый день,

Как в nginx можно сделать подобное -DOPENSSL_NO_HEARTBEATS флагу в apache2?
Попробовал вот так через env, не выходит.

nginx.conf:

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

env OPENSSL_NO_HEARTBEATS=1;



-- 
S L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141024/af4a83d1/attachment.html>

From stalker at altlinux.ru  Fri Oct 24 08:04:08 2014
From: stalker at altlinux.ru (Anton Gorlov)
Date: Fri, 24 Oct 2014 12:04:08 +0400
Subject: nginx environment directives
In-Reply-To: <1414115496.236291929@f224.i.mail.ru>
References: <1414115496.236291929@f224.i.mail.ru>
Message-ID: <544A07F8.1030103@altlinux.ru>

24.10.2014 05:51, S L пишет:
> Как в nginx можно сделать подобное -DOPENSSL_NO_HEARTBEATS флагу в apache2?
> Попробовал вот так через env, не выходит.
Вообще-то это опция сборки,а не параметр с которым работает приложение. 
В рантайме оно вроде как не срабатывает


From _lsv_ at bk.ru  Fri Oct 24 11:11:03 2014
From: _lsv_ at bk.ru (=?UTF-8?B?UyBM?=)
Date: Fri, 24 Oct 2014 15:11:03 +0400
Subject: nginx environment directives
In-Reply-To: <544A07F8.1030103@altlinux.ru>
References: <1414115496.236291929@f224.i.mail.ru>
 <544A07F8.1030103@altlinux.ru>
Message-ID: <1414149063.569669386@f87.i.mail.ru>

 где это опция сборки? В апаче? вот что это за опция... и она на запуск, а не на сборку.
  -D name            : define a name for use in <IfDefine name> directives



Fri, 24 Oct 2014 12:04:08 +0400 от Anton Gorlov <stalker at altlinux.ru>:
>24.10.2014 05:51, S L пишет:
>> Как в nginx можно сделать подобное -DOPENSSL_NO_HEARTBEATS флагу в apache2?
>> Попробовал вот так через env, не выходит.
>Вообще-то это опция сборки,а не параметр с которым работает приложение. 
>В рантайме оно вроде как не срабатывает
>
>_______________________________________________
>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/20141024/055b1bb3/attachment.html>

From mva at mva.name  Fri Oct 24 13:00:59 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 24 Oct 2014 20:00:59 +0700
Subject: nginx environment directives
In-Reply-To: <1414149063.569669386@f87.i.mail.ru>
References: <1414115496.236291929@f224.i.mail.ru>
 <544A07F8.1030103@altlinux.ru> <1414149063.569669386@f87.i.mail.ru>
Message-ID: <1858771.7uRfE3vSpl@note>

В письме от Пт, 24 октября 2014 
15:11:03 пользователь S L написал:
>  где это опция сборки? В апаче? вот 
что это за опция... и она на запуск, а

А с чего бы ей в Энджин Иксе 
называться так же, например?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141024/cafca71e/attachment.html>
-------------- 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/20141024/cafca71e/attachment.bin>

From nginx-forum at nginx.us  Sun Oct 26 09:11:36 2014
From: nginx-forum at nginx.us (photographer)
Date: Sun, 26 Oct 2014 05:11:36 -0400
Subject: =?UTF-8?B?0JrQsNC6INC60LXRiNC40YDQvtCy0LDRgtGMIHBocHNlc3NpZA==?=
Message-ID: <60e24860dd783d252d0e935f1df6c6c2.NginxMailingListRussian@forum.nginx.org>

Привет!

Плиз, подскажите как можно кешировать phpsessid? Сайт ставит много разных
кукисов, по которым я могу кешировать или нет, и также он всем ставит
phpsessid, даже незалогиненым. 
Как не кешировать я знаю, как в кеше привязать ключ тоже :)

Спасибо!

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


From nginx-forum at nginx.us  Sun Oct 26 10:35:36 2014
From: nginx-forum at nginx.us (Sferg)
Date: Sun, 26 Oct 2014 06:35:36 -0400
Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QviDQu9C4INGB0LrRgNGL0YLRjCBTZXQtQ29va2llcyA=?=
 =?UTF-8?B?0LjQtyBIVFRQLdC30LDQs9C+0LvQvtCy0LrQvtCyINC90LUg0LvQvtC80LA=?=
 =?UTF-8?B?0Y8g0LDQstGC0L7RgNC40LfQsNGG0LjRjj8=?=
Message-ID: <2092386a6f87d7cbc2a197f2bef136b1.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, господа. Настроена связка nginx + php-fpm. Возможно ли скрыть
строки Set-Cookies из HTTP-заголовков от посторонних глаз так, чтобы не
сломалась возможность авторизации на сайте? Пробовал добавлять в конфиг
nginx строчку:

fastcgi_hide_header "Set-Cookie";

Строки Set-Cookies в HTTP-заголовках исчезают, однако при этом становится
невозможной процедура авторизации на сайте. Возможно, я несколько
параноидален, но как-то не хочется всем и вся "светить" данной информацией.

С уважением, Геннадий.

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


From dmitry.goryainov at gmail.com  Sun Oct 26 10:57:06 2014
From: dmitry.goryainov at gmail.com (Dmitry)
Date: Sun, 26 Oct 2014 14:57:06 +0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDRgdC60YDRi9GC0YwgU2V0LUNvb2tp?=
 =?UTF-8?B?ZXMg0LjQtyBIVFRQLdC30LDQs9C+0LvQvtCy0LrQvtCyINC90LUg0LvQvtC8?=
 =?UTF-8?B?0LDRjyDQsNCy0YLQvtGA0LjQt9Cw0YbQuNGOPw==?=
In-Reply-To: <2092386a6f87d7cbc2a197f2bef136b1.NginxMailingListRussian@forum.nginx.org>
References: <2092386a6f87d7cbc2a197f2bef136b1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAHzBpYUdxv209ZydK-ug5yD9MP4P0mogMMMzJQ1byetpBWgf1g@mail.gmail.com>

А как без передачи сервером этого заголовка должна будет работать
авторизационная связка?

https://ru.wikipedia.org/wiki/HTTP_cookie#.D0.A0.D0.B0.D0.B1.D0.BE.D1.82.D0.B0_.D0.BA.D1.83.D0.BA.D0.B8


2014-10-26 13:35 GMT+03:00 Sferg <nginx-forum at nginx.us>:

> Здравствуйте, господа. Настроена связка nginx + php-fpm. Возможно ли скрыть
> строки Set-Cookies из HTTP-заголовков от посторонних глаз так, чтобы не
> сломалась возможность авторизации на сайте? Пробовал добавлять в конфиг
> nginx строчку:
>
> fastcgi_hide_header "Set-Cookie";
>
> Строки Set-Cookies в HTTP-заголовках исчезают, однако при этом становится
> невозможной процедура авторизации на сайте. Возможно, я несколько
> параноидален, но как-то не хочется всем и вся "светить" данной информацией.
>
> С уважением, Геннадий.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,254286,254286#msg-254286
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Dmitry Goryainov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141026/2cf59e4a/attachment.html>

From semenukha at gmail.com  Sun Oct 26 20:27:19 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Sun, 26 Oct 2014 16:27:19 -0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDRgdC60YDRi9GC0YwgU2V0LUNvb2tp?=
 =?UTF-8?B?ZXMg0LjQtyBIVFRQLdC30LDQs9C+0LvQvtCy0LrQvtCyINC90LUg0LvQvtC8?=
 =?UTF-8?B?0LDRjyDQsNCy0YLQvtGA0LjQt9Cw0YbQuNGOPw==?=
In-Reply-To: <2092386a6f87d7cbc2a197f2bef136b1.NginxMailingListRussian@forum.nginx.org>
References: <2092386a6f87d7cbc2a197f2bef136b1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5488258.28NtuPJzuX@hydra>

Геннадий,

Для сокрытия информации от посторонних глаз предназначен отдельный модуль ? SSL.
http://nginx.org/en/docs/http/ngx_http_ssl_module.html

On Sunday, October 26, 2014 06:35:36 AM Sferg wrote:
> Здравствуйте, господа. Настроена связка nginx + php-fpm. Возможно ли скрыть
> строки Set-Cookies из HTTP-заголовков от посторонних глаз так, чтобы не
> сломалась возможность авторизации на сайте? Пробовал добавлять в конфиг
> nginx строчку:
> 
> fastcgi_hide_header "Set-Cookie";
> 
> Строки Set-Cookies в HTTP-заголовках исчезают, однако при этом становится
> невозможной процедура авторизации на сайте. Возможно, я несколько
> параноидален, но как-то не хочется всем и вся "светить" данной информацией.
> 
> С уважением, Геннадий.
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254286,254286#msg-254286
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-- 
Sincerely yours,
Styopa Semenukha.

From nginx-forum at nginx.us  Mon Oct 27 10:58:37 2014
From: nginx-forum at nginx.us (den68)
Date: Mon, 27 Oct 2014 06:58:37 -0400
Subject: nginx API module #C
In-Reply-To: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org>
References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <cda41f5516703f0db9f38490821fca27.NginxMailingListRussian@forum.nginx.org>

Еще один вопрос если не затруднит, в каком пуле и какими стандартными
средствами сабжа разумней разместить кеш собственных данных?
А то его все время прибивают ... :)
И где максимальное время жизни пула? - process ?

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


From mdounin at mdounin.ru  Mon Oct 27 13:14:15 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 27 Oct 2014 17:14:15 +0400
Subject: nginx API module #C
In-Reply-To: <cda41f5516703f0db9f38490821fca27.NginxMailingListRussian@forum.nginx.org>
References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org>
 <cda41f5516703f0db9f38490821fca27.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141027131407.GE44913@mdounin.ru>

Hello!

On Mon, Oct 27, 2014 at 06:58:37AM -0400, den68 wrote:

> Еще один вопрос если не затруднит, в каком пуле и какими стандартными
> средствами сабжа разумней разместить кеш собственных данных?
> А то его все время прибивают ... :)
> И где максимальное время жизни пула? - process ?

Кеши разумнее всего размещать в разделяемой памяти, и при 
необходимости чистить их по LRU.  Пример кода можно посмотреть, 
например, где-нибудь в модуле limit_req.

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


From mdounin at mdounin.ru  Mon Oct 27 16:23:17 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 27 Oct 2014 19:23:17 +0300
Subject: nginx environment directives
In-Reply-To: <1414149063.569669386@f87.i.mail.ru>
References: <1414115496.236291929@f224.i.mail.ru>
 <544A07F8.1030103@altlinux.ru> <1414149063.569669386@f87.i.mail.ru>
Message-ID: <20141027162317.GB45418@mdounin.ru>

Hello!

On Fri, Oct 24, 2014 at 03:11:03PM +0400, S L wrote:

>  где это опция сборки? В апаче? вот что это за опция... и она на запуск, а не на сборку.
>   -D name            : define a name for use in <IfDefine name> directives

Если вы передаёте -DOPENSSL_NO_HEARTBEATS Апачу при запуске - то 
оно ничего полезного не делает, кроме как позволяет проверить 
соответствующее имя конфигах.

Если вопрос на самом деле про то, как сделать в nginx'е 
конфигурацию, зависящую от переменных окружения, т.е. какой-либо 
аналог директивы <IfDefine> в Апаче, то ответ - использовать 
любимый шаблонизатор, например make + sed.

Если вопрос про то, как защититься от атак в связи с уязвимостью 
Heartbleed, то ответ - обновить OpenSSL.  (В крайнем случае - 
пересобрать OpenSSL с соответствующей опцией, но лучше так не 
делать, ибо и других дырок хватает.)

Если вопрос про то, как запретить OpenSSL'ю использование 
расширения Heartbeat (на всякий случай, вдруг там ещё где грабли), 
то ответ - собрать OpenSSL с соответствующей опцией.

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


From nginx-forum at nginx.us  Mon Oct 27 17:21:23 2014
From: nginx-forum at nginx.us (oee)
Date: Mon, 27 Oct 2014 13:21:23 -0400
Subject: =?UTF-8?Q?=D0=9E=D1=88=D0=B8=D0=B1=D0=BA=D0=B8_php-fpm_=28connect=28=29_to?=
 =?UTF-8?Q?_unix=3A/tmp/php-fpm=2Esock_failed_=2811=3A_Resource_temporaril?=
 =?UTF-8?Q?y_unavailable=29_while_connecting_to_upstream=29?=
Message-ID: <9e1727909a355b77fdb8a59e126b0bd9.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток всем.
Появилась проблема с php-fpm на высоконагруженном сайте.
Через php-fpm настроен один единственный файл, остальной сайт через fcgid.
На данный файл идет по несколько запросов в секунду.
php-fpm конектится через сокет.
LA после 18 часов вечера (постепенный рост трафика в 2-3 раза) доходит до
40-50, днем 2-5 (хотя иногда и днем бывает уже 15-30)
Лог заваливается такими ошибками


2014/10/19 20:36:59 [error] 28352#0: *299209678 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28352#0: *299209681 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28356#0: *299194333 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28352#0: *299209689 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28359#0: *298980660 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28352#0: *299209700 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28352#0: *299209699 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28354#0: *299145235 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28354#0: *299162293 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28352#0: *299209664 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28353#0: *299209730 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28353#0: *299209733 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28359#0: *299195701 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28359#0: *299195704 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28353#0: *299209749 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream
2014/10/19 20:36:59 [error] 28352#0: *299209590 connect() to
unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
connecting to upstream

Раньше все было норм, появилось хз после чего, возможно после правки
некоторых конфигов.
Подскажите в чем проблема? Конфиги какие нужно скину, сервер мониторю
Munin`ом, графики тоже могу скинуть

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


From nginx-forum at nginx.us  Mon Oct 27 17:23:43 2014
From: nginx-forum at nginx.us (oee)
Date: Mon, 27 Oct 2014 13:23:43 -0400
Subject: =?UTF-8?Q?Re=3A_=D0=9E=D1=88=D0=B8=D0=B1=D0=BA=D0=B8_php-fpm_=28connect=28?=
 =?UTF-8?Q?=29_to_unix=3A/tmp/php-fpm=2Esock_failed_=2811=3A_Resource_temp?=
 =?UTF-8?Q?orarily_unavailable=29_while_connecting_to_upstream=29?=
In-Reply-To: <9e1727909a355b77fdb8a59e126b0bd9.NginxMailingListRussian@forum.nginx.org>
References: <9e1727909a355b77fdb8a59e126b0bd9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <9c5030f318f65feeb46d2efd81de3201.NginxMailingListRussian@forum.nginx.org>

Графики LA https://yadi.sk/i/pzaWs1UlcKndb

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


From mdounin at mdounin.ru  Mon Oct 27 17:57:53 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 27 Oct 2014 20:57:53 +0300
Subject: =?UTF-8?Q?Re=3A_=D0=9E=D1=88=D0=B8=D0=B1=D0=BA=D0=B8_php-fpm_=28connect=28?=
 =?UTF-8?Q?=29_to_unix=3A/tmp/php-fpm=2Esock_failed_=2811=3A_Resource_temp?=
 =?UTF-8?Q?orarily_unavailable=29_while_connecting_to_upstream=29?=
In-Reply-To: <9e1727909a355b77fdb8a59e126b0bd9.NginxMailingListRussian@forum.nginx.org>
References: <9e1727909a355b77fdb8a59e126b0bd9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141027175753.GE45418@mdounin.ru>

Hello!

On Mon, Oct 27, 2014 at 01:21:23PM -0400, oee wrote:

> Доброго времени суток всем.
> Появилась проблема с php-fpm на высоконагруженном сайте.
> Через php-fpm настроен один единственный файл, остальной сайт через fcgid.
> На данный файл идет по несколько запросов в секунду.
> php-fpm конектится через сокет.
> LA после 18 часов вечера (постепенный рост трафика в 2-3 раза) доходит до
> 40-50, днем 2-5 (хотя иногда и днем бывает уже 15-30)
> Лог заваливается такими ошибками
> 
> 
> 2014/10/19 20:36:59 [error] 28352#0: *299209678 connect() to
> unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while
> connecting to upstream

[...]

> Раньше все было норм, появилось хз после чего, возможно после правки
> некоторых конфигов.
> Подскажите в чем проблема? Конфиги какие нужно скину, сервер мониторю
> Munin`ом, графики тоже могу скинуть

Ошибки говорят о том, что у бекенда переполняется backlog aka 
listen queue.

Если бекенд справляется и проблема во всплесках - то поможет 
увеличение соответствующей очереди - смотреть listen.backlog в 
настройках php-fpm (по умолчанию там -1, т.е. лимит ставит 
система), и somaxconn в системе.

Если очередь и так большая (== размер сравним с тем, сколько 
запросов поступает за 1 секунду) - то надо думать про добавление 
новых бекендов (и/или оптимизацию существующего).

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


From nginx-forum at nginx.us  Mon Oct 27 20:32:40 2014
From: nginx-forum at nginx.us (oee)
Date: Mon, 27 Oct 2014 16:32:40 -0400
Subject: =?UTF-8?Q?Re=3A_=D0=9E=D1=88=D0=B8=D0=B1=D0=BA=D0=B8_php-fpm_=28connect=28?=
 =?UTF-8?Q?=29_to_unix=3A/tmp/php-fpm=2Esock_failed_=2811=3A_Resource_temp?=
 =?UTF-8?Q?orarily_unavailable=29_while_connecting_to_upstream=29?=
In-Reply-To: <20141027175753.GE45418@mdounin.ru>
References: <20141027175753.GE45418@mdounin.ru>
Message-ID: <add6ca7f7463ca550650b6249174a7aa.NginxMailingListRussian@forum.nginx.org>

listen.backlog выставил 1024
somaxconn стоит 102400, не менял его.
Ничего не изменилось.
Смотрю по топу, php-fpm очень сильно грузит процессор 10-20% на каждый
процесс, может от этого и ошибки? Как следствие.. А причина на самом деле в
другом

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


From _lsv_ at bk.ru  Tue Oct 28 01:21:53 2014
From: _lsv_ at bk.ru (=?UTF-8?B?UyBM?=)
Date: Tue, 28 Oct 2014 04:21:53 +0300
Subject: nginx environment directives
In-Reply-To: <20141027162317.GB45418@mdounin.ru>
References: <1414115496.236291929@f224.i.mail.ru>
 <1414149063.569669386@f87.i.mail.ru>
 <20141027162317.GB45418@mdounin.ru>
Message-ID: <1414459313.905831034@f397.i.mail.ru>




Mon, 27 Oct 2014 19:23:17 +0300 от Maxim Dounin <mdounin at mdounin.ru>:
>Hello!
>
>On Fri, Oct 24, 2014 at 03:11:03PM +0400, S L wrote:
>
>>  где это опция сборки? В апаче? вот что это за опция... и она на запуск, а не на сборку.
>>   -D name            : define a name for use in <IfDefine name> directives
>
>Если вы передаёте -DOPENSSL_NO_HEARTBEATS Апачу при запуске - то 
>оно ничего полезного не делает, кроме как позволяет проверить 
>соответствующее имя конфигах.
>
>Если вопрос на самом деле про то, как сделать в nginx'е 
>конфигурацию, зависящую от переменных окружения, т.е. какой-либо 
>аналог директивы <IfDefine> в Апаче, то ответ - использовать 
>любимый шаблонизатор, например make + sed.
>
>Если вопрос про то, как защититься от атак в связи с уязвимостью 
>Heartbleed, то ответ - обновить OpenSSL.  (В крайнем случае - 
>пересобрать OpenSSL с соответствующей опцией, но лучше так не 
>делать, ибо и других дырок хватает.)
>
>Если вопрос про то, как запретить OpenSSL'ю использование 
>расширения Heartbeat (на всякий случай, вдруг там ещё где грабли), 
>то ответ - собрать OpenSSL с соответствующей опцией.
А если у меня бинарный дистрибутив, то опцию никак нельзя выключить?
>
>-- 
>Maxim Dounin
>http://nginx.org/
>
>_______________________________________________
>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/20141028/19b040ff/attachment.html>

From chipitsine at gmail.com  Tue Oct 28 01:43:32 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 28 Oct 2014 07:43:32 +0600
Subject: nginx environment directives
In-Reply-To: <1414459313.905831034@f397.i.mail.ru>
References: <1414115496.236291929@f224.i.mail.ru>
 <1414149063.569669386@f87.i.mail.ru>
 <20141027162317.GB45418@mdounin.ru>
 <1414459313.905831034@f397.i.mail.ru>
Message-ID: <CAFHpkQH_iXTb-473OXt-8HdHf+N2jJF_QEk3fBgP73MdmZK5aA@mail.gmail.com>

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

если вам надо установить переменную окружения, это можно сделать перед
запуском nginx, процессы наследуют среду от родителя.

28 октября 2014 г., 6:21 пользователь S L <_lsv_ at bk.ru> написал:
>
>
>
> Mon, 27 Oct 2014 19:23:17 +0300 от Maxim Dounin <mdounin at mdounin.ru>:
>
> Hello!
>
> On Fri, Oct 24, 2014 at 03:11:03PM +0400, S L wrote:
>
>> где это опция сборки? В апаче? вот что это за опция... и она на запуск, а
>> не на сборку.
>>   -D name            : define a name for use in <IfDefine name> directives
>
> Если вы передаёте -DOPENSSL_NO_HEARTBEATS Апачу при запуске - то
> оно ничего полезного не делает, кроме как позволяет проверить
> соответствующее имя конфигах.
>
> Если вопрос на самом деле про то, как сделать в nginx'е
> конфигурацию, зависящую от переменных окружения, т.е. какой-либо
> аналог директивы <IfDefine> в Апаче, то ответ - использовать
> любимый шаблонизатор, например make + sed.
>
> Если вопрос про то, как защититься от атак в связи с уязвимостью
> Heartbleed, то ответ - обновить OpenSSL. (В крайнем случае -
> пересобрать OpenSSL с соответствующей опцией, но лучше так не
> делать, ибо и других дырок хватает.)
>
> Если вопрос про то, как запретить OpenSSL'ю использование
> расширения Heartbeat (на всякий случай, вдруг там ещё где грабли),
> то ответ - собрать OpenSSL с соответствующей опцией.
>
> А если у меня бинарный дистрибутив, то опцию никак нельзя выключить?
>
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> 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

From nginx-forum at nginx.us  Tue Oct 28 11:12:16 2014
From: nginx-forum at nginx.us (Zarus)
Date: Tue, 28 Oct 2014 07:12:16 -0400
Subject: =?UTF-8?B?0KHRgtCw0YLQuNC60LAg0YEg0L/QvtC00LTQvtC80LXQvdCw?=
Message-ID: <8714034ffd4f63fde1c4c2435bcbc03e.NginxMailingListRussian@forum.nginx.org>

Здравствуйте , пробую сделать раздачу статики с поддомена , не получаеться в
чем может быть ошибка ? Спасибо
в sites-available создал
static.mysite
server {

        server_name static.mysite.ru;

        location / {
                root /home/www/public/images;

        }
}

mysite

  server {
                set $mysite_root /home/www/mysite/public;
		listen mysite.ru;
                server_name mysite.ru;
                root $mysite_root;
                }

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


From dmitriy at lyalyuev.info  Tue Oct 28 11:16:45 2014
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Tue, 28 Oct 2014 13:16:45 +0200
Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINGBINC/0L7QtNC00L7QvNC10L3QsA==?=
In-Reply-To: <8714034ffd4f63fde1c4c2435bcbc03e.NginxMailingListRussian@forum.nginx.org>
References: <8714034ffd4f63fde1c4c2435bcbc03e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <544F7B1D.9080402@lyalyuev.info>

Добрый день.

Симлинки в sites-enabled сделали?


28.10.2014 13:12, Zarus пишет:
> Здравствуйте , пробую сделать раздачу статики с поддомена , не получаеться в
> чем может быть ошибка ? Спасибо
> в sites-available создал
> static.mysite
> server {
>
>          server_name static.mysite.ru;
>
>          location / {
>                  root /home/www/public/images;
>
>          }
> }
>
> mysite
>
>    server {
>                  set $mysite_root /home/www/mysite/public;
> 		listen mysite.ru;
>                  server_name mysite.ru;
>                  root $mysite_root;
>                  }
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254340,254340#msg-254340
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5374 bytes
Desc: п я─п╦п©я┌п╬пЁя─п╟я└п╦я┤п╣я│п╨п╟я▐ п©п╬п╢п©п╦я│я▄ S/MIME
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141028/cbb0cff2/attachment.bin>

From nginx-forum at nginx.us  Tue Oct 28 12:02:28 2014
From: nginx-forum at nginx.us (Zarus)
Date: Tue, 28 Oct 2014 08:02:28 -0400
Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINGBINC/0L7QtNC00L7QvNC10L3QsA==?=
In-Reply-To: <544F7B1D.9080402@lyalyuev.info>
References: <544F7B1D.9080402@lyalyuev.info>
Message-ID: <8588971d8c5f995629a280351c3d3f82.NginxMailingListRussian@forum.nginx.org>

Да симлинк в sites-enabled сделан , права выставленны

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


From vbart at nginx.com  Tue Oct 28 12:06:12 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 28 Oct 2014 15:06:12 +0300
Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINGBINC/0L7QtNC00L7QvNC10L3QsA==?=
In-Reply-To: <8714034ffd4f63fde1c4c2435bcbc03e.NginxMailingListRussian@forum.nginx.org>
References: <8714034ffd4f63fde1c4c2435bcbc03e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3292351.GXpEtu95Tc@vbart-workstation>

On Tuesday 28 October 2014 07:12:16 Zarus wrote:
> Здравствуйте , пробую сделать раздачу статики с поддомена , не получаеться в
> чем может быть ошибка ? Спасибо

Что именно не получается?


[..]
> mysite
> 
>   server {
>                 set $mysite_root /home/www/mysite/public;
> 		listen mysite.ru;
>                 server_name mysite.ru;
>                 root $mysite_root;
>                 }
> 

Не надо так делать.

Правильно:

  root /home/www/mysite/public;

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

From nginx-forum at nginx.us  Tue Oct 28 12:26:00 2014
From: nginx-forum at nginx.us (Zarus)
Date: Tue, 28 Oct 2014 08:26:00 -0400
Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINGBINC/0L7QtNC00L7QvNC10L3QsA==?=
In-Reply-To: <3292351.GXpEtu95Tc@vbart-workstation>
References: <3292351.GXpEtu95Tc@vbart-workstation>
Message-ID: <08bf13281483a69cfef0e4dd6ac64679.NginxMailingListRussian@forum.nginx.org>

После конфигурации , static.mysite.ru/image.png . не доступно

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


From mdounin at mdounin.ru  Tue Oct 28 12:46:33 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 28 Oct 2014 15:46:33 +0300
Subject: nginx environment directives
In-Reply-To: <1414459313.905831034@f397.i.mail.ru>
References: <1414115496.236291929@f224.i.mail.ru>
 <1414149063.569669386@f87.i.mail.ru>
 <20141027162317.GB45418@mdounin.ru>
 <1414459313.905831034@f397.i.mail.ru>
Message-ID: <20141028124633.GJ45418@mdounin.ru>

Hello!

On Tue, Oct 28, 2014 at 04:21:53AM +0300, S L wrote:

> Mon, 27 Oct 2014 19:23:17 +0300 от Maxim Dounin <mdounin at mdounin.ru>:
> >Hello!
> >
> >On Fri, Oct 24, 2014 at 03:11:03PM +0400, S L wrote:
> >
> >>  где это опция сборки? В апаче? вот что это за опция... и она на запуск, а не на сборку.
> >>   -D name            : define a name for use in <IfDefine name> directives
> >
> >Если вы передаёте -DOPENSSL_NO_HEARTBEATS Апачу при запуске - то 
> >оно ничего полезного не делает, кроме как позволяет проверить 
> >соответствующее имя конфигах.
> >
> >Если вопрос на самом деле про то, как сделать в nginx'е 
> >конфигурацию, зависящую от переменных окружения, т.е. какой-либо 
> >аналог директивы <IfDefine> в Апаче, то ответ - использовать 
> >любимый шаблонизатор, например make + sed.
> >
> >Если вопрос про то, как защититься от атак в связи с уязвимостью 
> >Heartbleed, то ответ - обновить OpenSSL.  (В крайнем случае - 
> >пересобрать OpenSSL с соответствующей опцией, но лучше так не 
> >делать, ибо и других дырок хватает.)
> >
> >Если вопрос про то, как запретить OpenSSL'ю использование 
> >расширения Heartbeat (на всякий случай, вдруг там ещё где грабли), 
> >то ответ - собрать OpenSSL с соответствующей опцией.
> А если у меня бинарный дистрибутив, то опцию никак нельзя выключить?

Никак.

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


From dmitriy at lyalyuev.info  Tue Oct 28 13:09:25 2014
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Tue, 28 Oct 2014 15:09:25 +0200
Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINGBINC/0L7QtNC00L7QvNC10L3QsA==?=
In-Reply-To: <8588971d8c5f995629a280351c3d3f82.NginxMailingListRussian@forum.nginx.org>
References: <544F7B1D.9080402@lyalyuev.info>
 <8588971d8c5f995629a280351c3d3f82.NginxMailingListRussian@forum.nginx.org>
Message-ID: <544F9585.3010002@lyalyuev.info>

Как-то с телепатией не задалось с детства. Может логи покажете?

28.10.2014 14:02, Zarus пишет:
> Да симлинк в sites-enabled сделан , права выставленны
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254340,254342#msg-254342
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5374 bytes
Desc: п я─п╦п©я┌п╬пЁя─п╟я└п╦я┤п╣я│п╨п╟я▐ п©п╬п╢п©п╦я│я▄ S/MIME
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141028/95be0b38/attachment.bin>

From vbart at nginx.com  Tue Oct 28 13:50:56 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 28 Oct 2014 16:50:56 +0300
Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINGBINC/0L7QtNC00L7QvNC10L3QsA==?=
In-Reply-To: <08bf13281483a69cfef0e4dd6ac64679.NginxMailingListRussian@forum.nginx.org>
References: <3292351.GXpEtu95Tc@vbart-workstation>
 <08bf13281483a69cfef0e4dd6ac64679.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2641821.03BgIFaeed@vbart-workstation>

On Tuesday 28 October 2014 08:26:00 Zarus wrote:
> После конфигурации , static.mysite.ru/image.png . не доступно
> 

Что понимается под "не доступно"? Ничего не возвращается? Возвращается ошибка? 
Если ошибка, то какая? Что в логе ошибок при этом?

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

From mdounin at mdounin.ru  Tue Oct 28 15:32:10 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 28 Oct 2014 18:32:10 +0300
Subject: nginx-1.7.7
Message-ID: <20141028153210.GT45418@mdounin.ru>

Изменения в nginx 1.7.7                                           28.10.2014

    *) Изменение: теперь nginx учитывает при кэшировании строку "Vary" в
       заголовке ответа бэкенда.

    *) Добавление: директивы proxy_force_ranges, fastcgi_force_ranges,
       scgi_force_ranges и uwsgi_force_ranges.

    *) Добавление: директивы proxy_limit_rate, fastcgi_limit_rate,
       scgi_limit_rate и uwsgi_limit_rate.

    *) Добавление: параметр Vary директив proxy_ignore_headers,
       fastcgi_ignore_headers, scgi_ignore_headers и uwsgi_ignore_headers.

    *) Исправление: последняя часть ответа, полученного от бэкенда при
       небуферизированном проксировании, могла не отправляться клиенту, если
       использовались директивы gzip или gunzip.

    *) Исправление: в директиве proxy_cache_revalidate.
       Спасибо Piotr Sikora.

    *) Исправление: в обработке ошибок.
       Спасибо Yichun Zhang и Даниилу Бондареву.

    *) Исправление: в директивах proxy_next_upstream_tries и
       proxy_next_upstream_timeout.
       Спасибо Feng Gu.

    *) Исправление: nginx/Windows не собирался с MinGW-w64 gcc.
       Спасибо Kouhei Sutou.


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


From megalin2 at gmail.com  Tue Oct 28 17:31:11 2014
From: megalin2 at gmail.com (=?KOI8-R?B?7snLydTBIOvB0sTB28nO?=)
Date: Tue, 28 Oct 2014 22:31:11 +0500
Subject: =?UTF-8?B?0JrQvtGA0YDQtdC60YLQvdCw0Y8g0YDQsNCx0L7RgtCwINGBIHRvbWNhdCBkZXBs?=
 =?UTF-8?B?b3k=?=
Message-ID: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>

Привет всем,

Каким образом можно корректно работать с tomcat-upstream, который
используется для java-приложения, deploy которого занимает несколько минут?

Среда:
На входе стоит nginx proxy, в котором настроено n апстримов в режиме
round-robin с max_fail=1. За ним - n серверов приложений, на которых
работает Apache Tomcat, в котором работает java-приложение.

Если падает один из серверов приложений - все прекрасно, nginx стучится к
нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное
время и рероутит запрос на другой апстрим. Пользователь проблемы не видит.
Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy
(либо мы сами стартовали re-deploy) - возникает проблема.

Проблема:
Деплой java-приложения в случае краша или обновления занимает несколько
минут (в особо злом случае - до десяти). Томкат, сволочь, в это время
принимает входящие соединения на свой порт, но не обслуживает их, а вешает
на холд до момента завершения деплоя приложения. Nginx принимает коннект от
пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока
бэкэнд не поднимется.
В итоге пользователь видит белый экран или частично загрузившуюся страницу
(как повезет раунд-робином), хотя в живых есть куча других апстримов,
которые могли бы обслужить его запрос.

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

Меня может что-то спасти?


-- 
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/20141028/37d93f53/attachment-0001.html>

From semenukha at gmail.com  Tue Oct 28 17:54:38 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Tue, 28 Oct 2014 13:54:38 -0400
Subject: =?UTF-8?B?UmU6INCa0L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDRgSB0b21jYXQg?=
 =?UTF-8?B?ZGVwbG95?=
In-Reply-To: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
References: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
Message-ID: <1865337.YrtEZOuGNp@tornado>

On Tuesday, October 28, 2014 10:31:11 PM Никита Кардашин wrote:
> Привет всем,
> 
> Каким образом можно корректно работать с tomcat-upstream, который
> используется для java-приложения, deploy которого занимает несколько минут?
> 
> Среда:
> На входе стоит nginx proxy, в котором настроено n апстримов в режиме
> round-robin с max_fail=1. За ним - n серверов приложений, на которых
> работает Apache Tomcat, в котором работает java-приложение.
> 
> Если падает один из серверов приложений - все прекрасно, nginx стучится к
> нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное
> время и рероутит запрос на другой апстрим. Пользователь проблемы не видит.
> Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy
> (либо мы сами стартовали re-deploy) - возникает проблема.
> 
> Проблема:
> Деплой java-приложения в случае краша или обновления занимает несколько
> минут (в особо злом случае - до десяти). Томкат, сволочь, в это время
> принимает входящие соединения на свой порт, но не обслуживает их, а вешает
> на холд до момента завершения деплоя приложения. Nginx принимает коннект от
> пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока
> бэкэнд не поднимется.
> В итоге пользователь видит белый экран или частично загрузившуюся страницу
> (как повезет раунд-робином), хотя в живых есть куча других апстримов,
> которые могли бы обслужить его запрос.
> 
> Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго
> думать или отдавать много данных и решить проблему "в лоб", урезав
> proxy_read_timeout до нескольких секунд - нельзя.
> 
> Меня может что-то спасти?
> 
> 
> -- 
> With best regards,
> differentlocal (www.differentlocal.ru | differentlocal at gmail.com),
> System administrator.

Привет.

Может быть, добавить в ваш скрипт прикрытие порта фаерволлом на время деплоя? 
По принципу:
try {
iptables -A ? -j REJECT
} finally {
iptables -D ? -j REJECT
}
-- 
Best regards,
Styopa Semenukha.

From mdounin at mdounin.ru  Tue Oct 28 18:04:06 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 28 Oct 2014 21:04:06 +0300
Subject: =?UTF-8?B?UmU6INCa0L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDRgSB0b21jYXQg?=
 =?UTF-8?B?ZGVwbG95?=
In-Reply-To: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
References: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
Message-ID: <20141028180406.GZ45418@mdounin.ru>

Hello!

On Tue, Oct 28, 2014 at 10:31:11PM +0500, Никита Кардашин wrote:

> Привет всем,
> 
> Каким образом можно корректно работать с tomcat-upstream, который
> используется для java-приложения, deploy которого занимает несколько минут?
> 
> Среда:
> На входе стоит nginx proxy, в котором настроено n апстримов в режиме
> round-robin с max_fail=1. За ним - n серверов приложений, на которых
> работает Apache Tomcat, в котором работает java-приложение.
> 
> Если падает один из серверов приложений - все прекрасно, nginx стучится к
> нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное
> время и рероутит запрос на другой апстрим. Пользователь проблемы не видит.
> Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy
> (либо мы сами стартовали re-deploy) - возникает проблема.
> 
> Проблема:
> Деплой java-приложения в случае краша или обновления занимает несколько
> минут (в особо злом случае - до десяти). Томкат, сволочь, в это время
> принимает входящие соединения на свой порт, но не обслуживает их, а вешает
> на холд до момента завершения деплоя приложения. Nginx принимает коннект от
> пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока
> бэкэнд не поднимется.
> В итоге пользователь видит белый экран или частично загрузившуюся страницу
> (как повезет раунд-робином), хотя в живых есть куча других апстримов,
> которые могли бы обслужить его запрос.
> 
> Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго
> думать или отдавать много данных и решить проблему "в лоб", урезав
> proxy_read_timeout до нескольких секунд - нельзя.
> 
> Меня может что-то спасти?

Если процедура проходит в штатном режиме, то правильно - убрать 
обновляемый сервер из блока upstream{}, после обновления - вернуть 
обратно.

Если говорить о нештатных ситуациях, то имеет смысл посмотреть в 
сторону балансировщика least_conn.  В отличие от round-robin'а он 
сразу заметит большое количество соединений, ждущих ответа, и 
перестанет направлять запросы на "плохой" бекенд.

Ну и в nginx-plus есть некоторое количество более других решений, 
таких как активные health check'и и реконфигурация 
upstream-серверов на лету.  Но это уже реклама.

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


From sytar.alex at gmail.com  Tue Oct 28 18:04:03 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Tue, 28 Oct 2014 22:04:03 +0400
Subject: =?UTF-8?B?UmU6INCa0L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDRgSB0b21jYXQg?=
 =?UTF-8?B?ZGVwbG95?=
In-Reply-To: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
References: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
Message-ID: <CAKqRTSEQhWP-LNZE6GRRUXr7kyKu=85DJ2YpRDzBRTaHGy+HGw@mail.gmail.com>

28 октября 2014 г., 20:31 пользователь Никита Кардашин <megalin2 at gmail.com>
написал:

> Привет всем,
>
> Каким образом можно корректно работать с tomcat-upstream, который
> используется для java-приложения, deploy которого занимает несколько минут?
>
> Среда:
> На входе стоит nginx proxy, в котором настроено n апстримов в режиме
> round-robin с max_fail=1. За ним - n серверов приложений, на которых
> работает Apache Tomcat, в котором работает java-приложение.
>
> Если падает один из серверов приложений - все прекрасно, nginx стучится к
> нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное
> время и рероутит запрос на другой апстрим. Пользователь проблемы не видит.
> Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy
> (либо мы сами стартовали re-deploy) - возникает проблема.
>
> Проблема:
> Деплой java-приложения в случае краша или обновления занимает несколько
> минут (в особо злом случае - до десяти). Томкат, сволочь, в это время
> принимает входящие соединения на свой порт, но не обслуживает их, а вешает
> на холд до момента завершения деплоя приложения. Nginx принимает коннект от
> пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока
> бэкэнд не поднимется.
> В итоге пользователь видит белый экран или частично загрузившуюся страницу
> (как повезет раунд-робином), хотя в живых есть куча других апстримов,
> которые могли бы обслужить его запрос.
>
> Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго
> думать или отдавать много данных и решить проблему "в лоб", урезав
> proxy_read_timeout до нескольких секунд - нельзя.
>
> Меня может что-то спасти?
>


Помечать неработающие бекенды как down -> nginx reload -> deploy -> убираем
down -> nginx reload
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141028/b73ae295/attachment.html>

From nginx-forum at nginx.us  Tue Oct 28 19:15:01 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 28 Oct 2014 15:15:01 -0400
Subject: nginx-1.7.7
In-Reply-To: <20141028153210.GT45418@mdounin.ru>
References: <20141028153210.GT45418@mdounin.ru>
Message-ID: <c9fe96100781c44b10f8ab6871efebd3.NginxMailingListRussian@forum.nginx.org>

> Изменения в nginx 1.7.7                                          
> 28.10.2014
> 
>     *) Изменение: теперь nginx учитывает при кэшировании строку "Vary"
> в
>        заголовке ответа бэкенда.

Где можно почитать подробности влияния Vary, на кеширования в Nginx?

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


From onokonem at gmail.com  Tue Oct 28 19:17:45 2014
From: onokonem at gmail.com (Daniel Podolsky)
Date: Tue, 28 Oct 2014 23:17:45 +0400
Subject: =?UTF-8?B?UmU6INCa0L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDRgSB0b21jYXQg?=
 =?UTF-8?B?ZGVwbG95?=
In-Reply-To: <CAKqRTSEQhWP-LNZE6GRRUXr7kyKu=85DJ2YpRDzBRTaHGy+HGw@mail.gmail.com>
References: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
 <CAKqRTSEQhWP-LNZE6GRRUXr7kyKu=85DJ2YpRDzBRTaHGy+HGw@mail.gmail.com>
Message-ID: <CAKaHDOGPCvT07fUkGrsQFJXLPnUP2yNbc92_dx5Gb871_Ah4PQ@mail.gmail.com>

> Помечать неработающие бекенды как down -> nginx reload -> deploy ->
> убираем down -> nginx reload

?И так на всех фронтах...

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

только надо проследить, чтобы блокировка не DROP, а REJECT (в терминах
iptables) ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141028/63b9aa7c/attachment.html>

From ru at nginx.com  Wed Oct 29 00:48:04 2014
From: ru at nginx.com (Ruslan Ermilov)
Date: Wed, 29 Oct 2014 04:48:04 +0400
Subject: nginx-1.7.7
In-Reply-To: <c9fe96100781c44b10f8ab6871efebd3.NginxMailingListRussian@forum.nginx.org>
References: <20141028153210.GT45418@mdounin.ru>
 <c9fe96100781c44b10f8ab6871efebd3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141029004804.GJ56368@lo0.su>

On Tue, Oct 28, 2014 at 03:15:01PM -0400, S.A.N wrote:
> > Изменения в nginx 1.7.7                                          
> > 28.10.2014
> > 
> >     *) Изменение: теперь nginx учитывает при кэшировании строку "Vary"
> > в
> >        заголовке ответа бэкенда.
> 
> Где можно почитать подробности влияния Vary, на кеширования в Nginx?

Какие-то подробности будут в документации, которая ещё не обновлена.
Какие-то останутся в коде.


From sytar.alex at gmail.com  Wed Oct 29 05:51:35 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Wed, 29 Oct 2014 09:51:35 +0400
Subject: =?UTF-8?B?UmU6INCa0L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDRgSB0b21jYXQg?=
 =?UTF-8?B?ZGVwbG95?=
In-Reply-To: <CAKaHDOGPCvT07fUkGrsQFJXLPnUP2yNbc92_dx5Gb871_Ah4PQ@mail.gmail.com>
References: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
 <CAKqRTSEQhWP-LNZE6GRRUXr7kyKu=85DJ2YpRDzBRTaHGy+HGw@mail.gmail.com>
 <CAKaHDOGPCvT07fUkGrsQFJXLPnUP2yNbc92_dx5Gb871_Ah4PQ@mail.gmail.com>
Message-ID: <CAKqRTSFojPE1nm_OgE=-QQWzZzAkhp4EuO7bLg=xxHPgJZrOTQ@mail.gmail.com>

28 октября 2014 г., 22:17 пользователь Daniel Podolsky <onokonem at gmail.com>
написал:

>
> Помечать неработающие бекенды как down -> nginx reload -> deploy ->
>> убираем down -> nginx reload
>
> ?И так на всех фронтах...
>
> Решение с добавлением блокировки через файрвол в процедуру деплоя выглядит
> несколько более простым.
>
> только надо проследить, чтобы блокировка не DROP, а REJECT (в терминах
> iptables) ?
>
>
Если вы уверены что на том томкате нет других приложений, которые вы
конечно не собирались отключать,ага.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141029/53d9befd/attachment.html>

From megalin2 at gmail.com  Wed Oct 29 11:37:19 2014
From: megalin2 at gmail.com (=?KOI8-R?B?7snLydTBIOvB0sTB28nO?=)
Date: Wed, 29 Oct 2014 17:37:19 +0600
Subject: =?UTF-8?B?UmU6INCa0L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDRgSB0b21jYXQg?=
 =?UTF-8?B?ZGVwbG95?=
In-Reply-To: <CAKqRTSFojPE1nm_OgE=-QQWzZzAkhp4EuO7bLg=xxHPgJZrOTQ@mail.gmail.com>
References: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
 <CAKqRTSEQhWP-LNZE6GRRUXr7kyKu=85DJ2YpRDzBRTaHGy+HGw@mail.gmail.com>
 <CAKaHDOGPCvT07fUkGrsQFJXLPnUP2yNbc92_dx5Gb871_Ah4PQ@mail.gmail.com>
 <CAKqRTSFojPE1nm_OgE=-QQWzZzAkhp4EuO7bLg=xxHPgJZrOTQ@mail.gmail.com>
Message-ID: <CALA_TQjOeQY2B4u9XH6v2A_8jVV1wQS2x-mJ1vrST1kVEAxcxg@mail.gmail.com>

Спасибо всем, но в целом системного уровня решения понятны. Проблема в том,
что redeploy может произойти и бесконтрольно - после ребута сервера
приложения, например, или в случае крэша приложения.

Есть ли решение на уровне nginx? Может, какая-ть волшебная директива
proxy_first_byte_read_timeout? :)
Интересный вариант с least_conn, но, насколько я понимаю, n клиентов все
равно повиснут?

29 октября 2014 г., 10:51 пользователь Aleksandr Sytar <sytar.alex at gmail.com
> написал:

>
>
> 28 октября 2014 г., 22:17 пользователь Daniel Podolsky <onokonem at gmail.com
> > написал:
>
>
>> Помечать неработающие бекенды как down -> nginx reload -> deploy ->
>>> убираем down -> nginx reload
>>
>> И так на всех фронтах...
>>
>> Решение с добавлением блокировки через файрвол в процедуру деплоя
>> выглядит несколько более простым.
>>
>> только надо проследить, чтобы блокировка не DROP, а REJECT (в терминах
>> iptables) 
>>
>>
> Если вы уверены что на том томкате нет других приложений, которые вы
> конечно не собирались отключать,ага.
>
> _______________________________________________
> 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/20141029/425150d7/attachment.html>

From gmm at csdoc.com  Wed Oct 29 12:27:43 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 29 Oct 2014 14:27:43 +0200
Subject: =?UTF-8?B?UmU6INCa0L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDRgSB0b21jYXQg?=
 =?UTF-8?B?ZGVwbG95?=
In-Reply-To: <CALA_TQjOeQY2B4u9XH6v2A_8jVV1wQS2x-mJ1vrST1kVEAxcxg@mail.gmail.com>
References: <CALA_TQgea6DQ=d7ZNWugSrKz96btYHn8cmhySw2N8figBpa7RQ@mail.gmail.com>
 <CAKqRTSEQhWP-LNZE6GRRUXr7kyKu=85DJ2YpRDzBRTaHGy+HGw@mail.gmail.com>
 <CAKaHDOGPCvT07fUkGrsQFJXLPnUP2yNbc92_dx5Gb871_Ah4PQ@mail.gmail.com>
 <CAKqRTSFojPE1nm_OgE=-QQWzZzAkhp4EuO7bLg=xxHPgJZrOTQ@mail.gmail.com>
 <CALA_TQjOeQY2B4u9XH6v2A_8jVV1wQS2x-mJ1vrST1kVEAxcxg@mail.gmail.com>
Message-ID: <5450DD3F.4040809@csdoc.com>

On 29.10.2014 13:37, Никита Кардашин wrote:

> Спасибо всем, но в целом системного уровня решения понятны. Проблема в
> том, что redeploy может произойти и бесконтрольно - после ребута сервера
> приложения, например, или в случае крэша приложения.

bindOnInit="false"

autoDeploy="false"

deployOnStartup="true"

чтобы произошел крэш JVM или tomcat - это надо очень сильно постараться.

> Есть ли решение на уровне nginx?
> Может, какая-ть волшебная директива proxy_first_byte_read_timeout? :)

proxy_connect_timeout

-- 
Best regards,
  Gena


From anatoly at sonru.com  Wed Oct 29 12:42:29 2014
From: anatoly at sonru.com (Anatoly Mikhaylov)
Date: Wed, 29 Oct 2014 12:42:29 +0000
Subject: =?UTF-8?B?UmU6INC+0L/RgtC40LzQuNC30LDRhtC40Y8gY2xpZW50X2JvZHkg0L3QsCDQvNC1?=
 =?UTF-8?B?0LTQu9C10L3QvdC+0Lkg0YTQsNC50LvQvtCy0L7QuSDRgdC40YHRgtC10Lw=?=
 =?UTF-8?B?0LU=?=
In-Reply-To: <8C9C925E-3E53-4B05-8AC4-908BDBEA6297@sonru.com>
References: <B38C9AC6-70AC-4FA4-8566-F99DE2CDC0C8@sonru.com>
 <8C9C925E-3E53-4B05-8AC4-908BDBEA6297@sonru.com>
Message-ID: <89A9A1E9-F372-4272-BFD3-7BA6E0072713@sonru.com>

ребята, стоит пробовать client_body_in_single_buffer?

Анатолий

On Oct 20, 2014, at 10:47 PM, Anatoly Mikhaylov <anatoly at sonru.com> wrote:

> Максим,
> 
> вопрос прежде всего на http://forum.nginx.org/read.php?2,220778,220840
> 
>> To limit disk I/O for big requests/responses there are following
>> options available:
>> 
>> 1. Using larger buffers, notably client_body_buffer_size,
>> proxy_buffer_size, proxy_buffers. This is basically what you've
>> already done.
> 
> Хочется поподробнее узнать, что подходит в моем случае. Спасибо!
> 
> Анатолий
> 
> On Oct 20, 2014, at 10:37 PM, Anatoly Mikhaylov <anatoly at sonru.com> wrote:
> 
>> Какие оптимизации рекомендованы при использовании client_body_in_file_only on;?
>> Надо разобраться с минимизацией обращений к файловой системе и реиспользованию 
>> HTTP подключения с клиентом и бэкэндом (proxy_pass), на который идет колбек.
>> 
>> Условия: IO никакой (EBS), размер файла в среднем 10MB, количество файлов
>> для загрузки - 10, от одного клиента. Текущие настройки:
>> 
>> location /upload {
>> sendfile                    on;
>> limit_except POST          { deny all; }
>> keepalive_timeout          300s;
>> client_body_temp_path      /media/tmp/;
>> client_body_in_file_only   on;
>> client_body_buffer_size    128K;
>> client_max_body_size       100M;
>> 
>> proxy_pass_request_headers on;
>> proxy_set_header           X-File $request_body_file; 
>> proxy_set_body             off;
>> proxy_redirect             off;
>> proxy_pass                 https://***/server_callback
>> }
>> 
>> Смотрю в сторону client_body_in_single_buffer, tcp_nodelay, tcp_nopush, sendfile_max_chunk
>> 
>> О системе Linux 3.10, Red Hat 4.8.2-7.
>> 
>> Анатолий
>> _______________________________________________
>> 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


From nginx-forum at nginx.us  Wed Oct 29 13:02:44 2014
From: nginx-forum at nginx.us (ecspertiza)
Date: Wed, 29 Oct 2014 09:02:44 -0400
Subject: =?UTF-8?B?0JfQsNC/0YDQvtGB0Ysg0YEg0L/QvtC00LTQvtC80LXQvdCwINC90LAg0LTRgNGD?=
 =?UTF-8?B?0LPQvtC5INGB0LXRgNCy0LXRgC4=?=
Message-ID: <2f8307f5aef3aeacc1fb6ca3ac52f4b2.NginxMailingListRussian@forum.nginx.org>

Суть вопроса такова. У меня есть домен напр. myproject.ru. "Боевая" часть
сайта (myproject.ru) лежит у одного хостера. Бета будет лежать у другого и
само собой хочется что бы запросы на beta.myproject.ru шли на другой сервер
где они уже могла бы обрабатываться. Вопрос в том как это реализовать в
настройках nginx ? Более того на сервере который обрабатывает бету так же
крутится еще один сайт.

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


From dmitriy at lyalyuev.info  Wed Oct 29 13:13:16 2014
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Wed, 29 Oct 2014 15:13:16 +0200
Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0L7RgdGLINGBINC/0L7QtNC00L7QvNC10L3QsCDQvdCwINC0?=
 =?UTF-8?B?0YDRg9Cz0L7QuSDRgdC10YDQstC10YAu?=
In-Reply-To: <2f8307f5aef3aeacc1fb6ca3ac52f4b2.NginxMailingListRussian@forum.nginx.org>
References: <2f8307f5aef3aeacc1fb6ca3ac52f4b2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5450E7EC.8090109@lyalyuev.info>

Nginx тут не при чем.
В DNS укажите для поддомена нужный IP и все.

29.10.2014 15:02, ecspertiza пишет:
> Суть вопроса такова. У меня есть домен напр. myproject.ru. "Боевая" часть
> сайта (myproject.ru) лежит у одного хостера. Бета будет лежать у другого и
> само собой хочется что бы запросы на beta.myproject.ru шли на другой сервер
> где они уже могла бы обрабатываться. Вопрос в том как это реализовать в
> настройках nginx ? Более того на сервере который обрабатывает бету так же
> крутится еще один сайт.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254402,254402#msg-254402
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5374 bytes
Desc: п я─п╦п©я┌п╬пЁя─п╟я└п╦я┤п╣я│п╨п╟я▐ п©п╬п╢п©п╦я│я▄ S/MIME
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141029/e916d3a5/attachment.bin>

From nginx-forum at nginx.us  Wed Oct 29 15:07:06 2014
From: nginx-forum at nginx.us (sunyang)
Date: Wed, 29 Oct 2014 11:07:06 -0400
Subject: =?UTF-8?B?0LDQvdCw0LvQvtCzIGh0YWNjZXNzINC/0YDQsNCy0LjQu9Cw?=
Message-ID: <705291b487557fa90185fef105200411.NginxMailingListRussian@forum.nginx.org>

Подскажите, как можно с эмитировать вот такое htaccess правило:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([A-z0-9-_]+\/)(.*)$ /$1index.php?req=$2&module=$1 [QSA,L]

тобишь если есть шлем все запросы в папку, остальное передаем в переменной
$req
Например запрос: /catalog/section_1/section_2/section_3/?aa=11&bb=22

В папке /catalog/ получаем:

Array
(
    [req] => section_1/section_2/section_3/
    [module] => catalog
    [aa] => 11
    [bb] => 22
)

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


From mdounin at mdounin.ru  Wed Oct 29 16:17:37 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 29 Oct 2014 19:17:37 +0300
Subject: =?UTF-8?B?UmU6INC+0L/RgtC40LzQuNC30LDRhtC40Y8gY2xpZW50X2JvZHkg0L3QsCDQvNC1?=
 =?UTF-8?B?0LTQu9C10L3QvdC+0Lkg0YTQsNC50LvQvtCy0L7QuSDRgdC40YHRgtC10Lw=?=
 =?UTF-8?B?0LU=?=
In-Reply-To: <89A9A1E9-F372-4272-BFD3-7BA6E0072713@sonru.com>
References: <B38C9AC6-70AC-4FA4-8566-F99DE2CDC0C8@sonru.com>
 <8C9C925E-3E53-4B05-8AC4-908BDBEA6297@sonru.com>
 <89A9A1E9-F372-4272-BFD3-7BA6E0072713@sonru.com>
Message-ID: <20141029161737.GG45418@mdounin.ru>

Hello!

On Wed, Oct 29, 2014 at 12:42:29PM +0000, Anatoly Mikhaylov wrote:

> ребята, стоит пробовать client_body_in_single_buffer?

При включённом client_body_in_file_only это не имеет смысла.

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


From an07d5 at gmail.com  Wed Oct 29 17:26:11 2014
From: an07d5 at gmail.com (An)
Date: Wed, 29 Oct 2014 21:26:11 +0400
Subject: =?UTF-8?B?RndkOiBuZ3hfaHR0cF9pbWFnZV9maWx0ZXJfbW9kdWxlIC0gcmVzaXplINGD0LI=?=
 =?UTF-8?B?0LXQu9C40YfQtdC90LjQtSDQuNC30L7QsdGA0LDQttC10L3QuNC5?=
In-Reply-To: <CAJAEogMG9B+Y8k+8rEdXOtBb=RxZbAVrMcTa-CoRz6dhsx_kMA@mail.gmail.com>
References: <CAJAEogMG9B+Y8k+8rEdXOtBb=RxZbAVrMcTa-CoRz6dhsx_kMA@mail.gmail.com>
Message-ID: <CAJAEogNrGUUYxWqU8WRvF-Ma_AurS5=c_b_+_L31bm2EOpmkEw@mail.gmail.com>

---------- Forwarded message ----------
From: An <an07d5 at gmail.com>
Date: 2014-10-29 12:49 GMT+04:00
Subject: ngx_http_image_filter_module - resize увеличение изображений
To: nginx-ru at nginx.org


Очень удобно, если фильтр может увеличивать изображения. Предлагаю внести
следующие изменения.

an at an-pc:~/Desktop$ cat ngx_http_image_filter_module.diff

# HG changeset patch
# User Anton Shefer <an07d5 at gmail.com>
# Date 1414566573 -14400
#      Wed Oct 29 11:09:33 2014 +0400
# Node ID a499f7c603f2322950698da88213aa53fb81ad46
# Parent  87ada3ba1392fadaf4d9193b5d345c248be32f77
Image filter resize - Increase images

diff -r 87ada3ba1392 -r a499f7c603f2
src/http/modules/ngx_http_image_filter_module.c
--- a/src/http/modules/ngx_http_image_filter_module.c    Mon Oct 27
14:25:56 2014 -0700
+++ b/src/http/modules/ngx_http_image_filter_module.c    Wed Oct 29
11:09:33 2014 +0400
@@ -546,7 +546,8 @@
         && ctx->width <= ctx->max_width
         && ctx->height <= ctx->max_height
         && ctx->angle == 0
-        && !ctx->force)
+        && !ctx->force
+        && conf->filter != NGX_HTTP_IMAGE_RESIZE)
     {
         return ngx_http_image_asis(r, ctx);
     }
@@ -773,7 +774,8 @@
     if (!ctx->force
         && ctx->angle == 0
         && (ngx_uint_t) sx <= ctx->max_width
-        && (ngx_uint_t) sy <= ctx->max_height)
+        && (ngx_uint_t) sy <= ctx->max_height
+        && conf->filter != NGX_HTTP_IMAGE_RESIZE)
     {
         gdImageDestroy(src);
         return ngx_http_image_asis(r, ctx);
@@ -809,15 +811,19 @@

     if (conf->filter == NGX_HTTP_IMAGE_RESIZE) {

-        if ((ngx_uint_t) dx > ctx->max_width) {
+
+        if ((int)ctx->max_width > 0 && (int)ctx->max_height > 0) {
             dy = dy * ctx->max_width / dx;
-            dy = dy ? dy : 1;
             dx = ctx->max_width;
-        }
-
-        if ((ngx_uint_t) dy > ctx->max_height) {
+            if (dy > (int)ctx->max_height) {
+                dx = dx * ctx->max_height / dy;
+                dy = ctx->max_height;
+            }
+        } else if ((int)ctx->max_width > 0) {
+            dy = dy * ctx->max_width / dx;
+            dx = ctx->max_width;
+        } else if ((int)ctx->max_height > 0) {
             dx = dx * ctx->max_height / dy;
-            dx = dx ? dx : 1;
             dy = ctx->max_height;
         }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141029/42b6c233/attachment-0001.html>
-------------- next part --------------
# HG changeset patch
# User Anton Shefer <an07d5 at gmail.com>
# Date 1414566573 -14400
#      Wed Oct 29 11:09:33 2014 +0400
# Node ID a499f7c603f2322950698da88213aa53fb81ad46
# Parent  87ada3ba1392fadaf4d9193b5d345c248be32f77
Image filter resize - Increase images

diff -r 87ada3ba1392 -r a499f7c603f2 src/http/modules/ngx_http_image_filter_module.c
--- a/src/http/modules/ngx_http_image_filter_module.c	Mon Oct 27 14:25:56 2014 -0700
+++ b/src/http/modules/ngx_http_image_filter_module.c	Wed Oct 29 11:09:33 2014 +0400
@@ -546,7 +546,8 @@
         && ctx->width <= ctx->max_width
         && ctx->height <= ctx->max_height
         && ctx->angle == 0
-        && !ctx->force)
+        && !ctx->force
+        && conf->filter != NGX_HTTP_IMAGE_RESIZE)
     {
         return ngx_http_image_asis(r, ctx);
     }
@@ -773,7 +774,8 @@
     if (!ctx->force
         && ctx->angle == 0
         && (ngx_uint_t) sx <= ctx->max_width
-        && (ngx_uint_t) sy <= ctx->max_height)
+        && (ngx_uint_t) sy <= ctx->max_height
+        && conf->filter != NGX_HTTP_IMAGE_RESIZE)
     {
         gdImageDestroy(src);
         return ngx_http_image_asis(r, ctx);
@@ -809,15 +811,19 @@
 
     if (conf->filter == NGX_HTTP_IMAGE_RESIZE) {
 
-        if ((ngx_uint_t) dx > ctx->max_width) {
+        
+        if ((int)ctx->max_width > 0 && (int)ctx->max_height > 0) {
             dy = dy * ctx->max_width / dx;
-            dy = dy ? dy : 1;
             dx = ctx->max_width;
-        }
-
-        if ((ngx_uint_t) dy > ctx->max_height) {
+            if (dy > (int)ctx->max_height) {
+                dx = dx * ctx->max_height / dy;
+                dy = ctx->max_height;
+            }
+        } else if ((int)ctx->max_width > 0) {
+            dy = dy * ctx->max_width / dx;
+            dx = ctx->max_width;
+        } else if ((int)ctx->max_height > 0) {
             dx = dx * ctx->max_height / dy;
-            dx = dx ? dx : 1;
             dy = ctx->max_height;
         }
 

From nginx-forum at nginx.us  Wed Oct 29 17:52:20 2014
From: nginx-forum at nginx.us (killart)
Date: Wed, 29 Oct 2014 13:52:20 -0400
Subject: =?UTF-8?B?bmdpbngg0LrQsNC6IGh0dHBzINGA0LXQtNC40YDQtdC60YLQvtGA?=
Message-ID: <0460393d6caf7e8904fe1032bf0ebe0e.NginxMailingListRussian@forum.nginx.org>

Возможно настроить nginx как редиректор 443 порта (без разбора) в
зависимости от URL на определенный сервер (группу серверов)? По сути
использование nginx для балансировки нагрузки между несколькими указанными
серверами.

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


From mdounin at mdounin.ru  Wed Oct 29 17:55:45 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 29 Oct 2014 20:55:45 +0300
Subject: =?UTF-8?B?UmU6IEZ3ZDogbmd4X2h0dHBfaW1hZ2VfZmlsdGVyX21vZHVsZSAtIHJlc2l6ZSA=?=
 =?UTF-8?B?0YPQstC10LvQuNGH0LXQvdC40LUg0LjQt9C+0LHRgNCw0LbQtdC90LjQuQ==?=
In-Reply-To: <CAJAEogNrGUUYxWqU8WRvF-Ma_AurS5=c_b_+_L31bm2EOpmkEw@mail.gmail.com>
References: <CAJAEogMG9B+Y8k+8rEdXOtBb=RxZbAVrMcTa-CoRz6dhsx_kMA@mail.gmail.com>
 <CAJAEogNrGUUYxWqU8WRvF-Ma_AurS5=c_b_+_L31bm2EOpmkEw@mail.gmail.com>
Message-ID: <20141029175545.GN45418@mdounin.ru>

Hello!

On Wed, Oct 29, 2014 at 09:26:11PM +0400, An wrote:

> Очень удобно, если фильтр может увеличивать изображения. Предлагаю внести
> следующие изменения.

Зачем?

С тем же успехом можно прописать увеличенные размеры в html / css, 
и браузер замечательно справится с задачей сам.  Уменьшение нужно 
в первую очередь для того, чтобы сократить объём данных, 
передаваемых клиенту.

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


From semenukha at gmail.com  Wed Oct 29 19:15:45 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Wed, 29 Oct 2014 15:15:45 -0400
Subject: =?UTF-8?B?UmU6IG5naW54INC60LDQuiBodHRwcyDRgNC10LTQuNGA0LXQutGC0L7RgA==?=
In-Reply-To: <0460393d6caf7e8904fe1032bf0ebe0e.NginxMailingListRussian@forum.nginx.org>
References: <0460393d6caf7e8904fe1032bf0ebe0e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1605368.Zo87jEbdsr@tornado>

On Wednesday, October 29, 2014 01:52:20 PM killart wrote:
> Возможно настроить nginx как редиректор 443 порта (без разбора) в
> зависимости от URL на определенный сервер (группу серверов)? По сути
> использование nginx для балансировки нагрузки между несколькими указанными
> серверами.
> 
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,254421,254421#msg-254421
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Возможно. Если домены разные, вам понадобятся SNI и/или сертификат с 
несколькими субъектами (subjectAltName).

Если только по URL, тогда достаточно директив upstream, location и proxy_pass.

Неясно только, как это ? "без разбора", и одновременно "в зависимости от URL".
-- 
Best regards,
Styopa Semenukha.

From an07d5 at gmail.com  Thu Oct 30 07:16:44 2014
From: an07d5 at gmail.com (An)
Date: Thu, 30 Oct 2014 11:16:44 +0400
Subject: =?UTF-8?B?UmU6IEZ3ZDogbmd4X2h0dHBfaW1hZ2VfZmlsdGVyX21vZHVsZSAtIHJlc2l6ZSA=?=
 =?UTF-8?B?0YPQstC10LvQuNGH0LXQvdC40LUg0LjQt9C+0LHRgNCw0LbQtdC90LjQuQ==?=
In-Reply-To: <20141029175545.GN45418@mdounin.ru>
References: <CAJAEogMG9B+Y8k+8rEdXOtBb=RxZbAVrMcTa-CoRz6dhsx_kMA@mail.gmail.com>
 <CAJAEogNrGUUYxWqU8WRvF-Ma_AurS5=c_b_+_L31bm2EOpmkEw@mail.gmail.com>
 <20141029175545.GN45418@mdounin.ru>
Message-ID: <CAJAEogP2na2wvC_LtiJaKVJD_YY8Kp9M814Hxnj2PwuqXbnUcA@mail.gmail.com>

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

29 октября 2014 г., 21:55 пользователь Maxim Dounin <mdounin at mdounin.ru>
написал:

> Hello!
>
> On Wed, Oct 29, 2014 at 09:26:11PM +0400, An wrote:
>
> > Очень удобно, если фильтр может увеличивать изображения. Предлагаю внести
> > следующие изменения.
>
> Зачем?
>
> С тем же успехом можно прописать увеличенные размеры в html / css,
> и браузер замечательно справится с задачей сам.  Уменьшение нужно
> в первую очередь для того, чтобы сократить объём данных,
> передаваемых клиенту.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> 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/20141030/8cb6dd31/attachment.html>

From nginx-forum at nginx.us  Thu Oct 30 08:36:38 2014
From: nginx-forum at nginx.us (killart)
Date: Thu, 30 Oct 2014 04:36:38 -0400
Subject: =?UTF-8?B?UmU6IG5naW54INC60LDQuiBodHRwcyDRgNC10LTQuNGA0LXQutGC0L7RgA==?=
In-Reply-To: <1605368.Zo87jEbdsr@tornado>
References: <1605368.Zo87jEbdsr@tornado>
Message-ID: <53e78cf9f56772295c7329585ddb7acd.NginxMailingListRussian@forum.nginx.org>

Идея в следующем:
Есть несколько веб-серверов (appsrv-n) разных компаний. Необходимо
обеспечить работу nginx в режиме обратного прокси-сервера и SSL-терминатора
для HTTPS запросов. При этом трафик различных серверов,
с точки зрения информационной безопасности, нельзя обрабатывать на одном
nginx. Для этого предполагается, что на периметре сети хост nginx будет
перенаправлять HTTP и HTTPS трафик на внутренние сервера nginx в зависимости
от URL к которому идут запросы (www.domain1.com на srv-1 b srv-2,
www.domain2.com на srv-3 и srv-4). На серверах srv-n трафик перенаправляется
на appsrv-1, ... appsrv-2 и т.д в зависимости от URL запроса (если HTTPS
запрос трафик расшифровывается). 

Вот примерно такую схему хотелось бы реализовать.

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


From megalin2 at gmail.com  Thu Oct 30 15:23:29 2014
From: megalin2 at gmail.com (=?KOI8-R?B?7snLydTBIOvB0sTB28nO?=)
Date: Thu, 30 Oct 2014 20:23:29 +0500
Subject: =?UTF-8?B?UmU6IG5naW54INC60LDQuiBodHRwcyDRgNC10LTQuNGA0LXQutGC0L7RgA==?=
In-Reply-To: <53e78cf9f56772295c7329585ddb7acd.NginxMailingListRussian@forum.nginx.org>
References: <1605368.Zo87jEbdsr@tornado>
 <53e78cf9f56772295c7329585ddb7acd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CALA_TQhzON=4j50h4_QHEd_2OrWiSrKppJioj6ayEkES8aKiJQ@mail.gmail.com>

Странная безопасность, если честно.

Если я правильно понимаю, то задача поставленная в этом посте решается
через n серверов с nginx и 301 redirect.

В чем принципиальная разница между "перенаправлять" и "проксировать" с т.з.
ИБ? В обоих случаях злоумышленник, скомпрометировав "центральный" nginx
сможет сделать с трафиком все, что угодно - хоть прочитать, хоть
перенаправить на свои сервера. Безопасности от создания дополнительных
промежуточных узлов _после_ точки входа не добавится совершенно.



30 октября 2014 г., 13:36 пользователь killart <nginx-forum at nginx.us>
написал:

> Идея в следующем:
> Есть несколько веб-серверов (appsrv-n) разных компаний. Необходимо
> обеспечить работу nginx в режиме обратного прокси-сервера и SSL-терминатора
> для HTTPS запросов. При этом трафик различных серверов,
> с точки зрения информационной безопасности, нельзя обрабатывать на одном
> nginx. Для этого предполагается, что на периметре сети хост nginx будет
> перенаправлять HTTP и HTTPS трафик на внутренние сервера nginx в
> зависимости
> от URL к которому идут запросы (www.domain1.com на srv-1 b srv-2,
> www.domain2.com на srv-3 и srv-4). На серверах srv-n трафик
> перенаправляется
> на appsrv-1, ... appsrv-2 и т.д в зависимости от URL запроса (если HTTPS
> запрос трафик расшифровывается).
>
> Вот примерно такую схему хотелось бы реализовать.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,254421,254442#msg-254442
>
> _______________________________________________
> 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/20141030/fd20c587/attachment.html>

From nginx-forum at nginx.us  Fri Oct 31 10:12:02 2014
From: nginx-forum at nginx.us (killart)
Date: Fri, 31 Oct 2014 06:12:02 -0400
Subject: =?UTF-8?B?UmU6IG5naW54INC60LDQuiBodHRwcyDRgNC10LTQuNGA0LXQutGC0L7RgA==?=
In-Reply-To: <CALA_TQhzON=4j50h4_QHEd_2OrWiSrKppJioj6ayEkES8aKiJQ@mail.gmail.com>
References: <CALA_TQhzON=4j50h4_QHEd_2OrWiSrKppJioj6ayEkES8aKiJQ@mail.gmail.com>
Message-ID: <e01fa5d5c5848a8078b77f1e67805b20.NginxMailingListRussian@forum.nginx.org>

Cкомпрометировав "центральный" nginx злоумышленник не сможет расшифровать
проходящий через него https трафик.

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


From nginx-forum at nginx.us  Fri Oct 31 11:08:38 2014
From: nginx-forum at nginx.us (Nikolay)
Date: Fri, 31 Oct 2014 07:08:38 -0400
Subject: =?UTF-8?B?0J/QvtGP0LLQu9C10L3QuNC1INGB0YLRgNCw0L3QvdC+0Lkg0LfQsNC/0LjRgdC4?=
 =?UTF-8?B?INCyINC70L7Qs9Cw0YU=?=
Message-ID: <104ac08e6c7f3e62ba797fb2776319ba.NginxMailingListRussian@forum.nginx.org>

При обращении к http://host.domain.tld в логах появляется запись

1.1.1.1 - - [31/Oct/2014:13:03:17 +0300] "GET / HTTP/1.1" 200 31 "-" 0.003
0.003 -"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/38.0.2125.104 Safari/537.36" "-" "host.domain.tld" "http"

а через несколько секунд вторая:

1.1.1.1 - - [31/Oct/2014:13:02:04 +0300] "-" 400 0 "-" - 0.000 -"-" "-"
"host.domain.tld" "http"
Второго запроса не делаю, но запись появляеися.
Почему появляется вторая запись да еще с таким странным значением $request?

Log format:

log_format  host_log_format  '$remote_addr - $remote_user [$time_local]
"$request" '
                '$status $body_bytes_sent "$http_referer" '
		'$upstream_response_time $request_time '
		'$request_body'
                '"$http_user_agent" "$http_x_forwarded_for" "$host"
"$scheme"';
Vhost:
        server {
                listen       80 default_server;
                server_name  host.domain.tld;
                access_log  /var/log/host.domain.tld.nginx.access.log 
host_log_format;
                gzip off;

                location /storage/ {
                        root /www/static-host/;
                        expires     24h;
                }

                location / {
                        proxy_pass   http://host;
                        proxy_read_timeout 60s;
                        proxy_next_upstream error timeout http_500
http_404;
                        proxy_set_header Host $host;
                        proxy_set_header   X-Real-IP        $remote_addr;
                        proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
                }
        }

server {
        listen *:443 default_server;
        server_name host.domain.tld;
	access_log  /var/log/host.domain.tld.nginx.access.log host_log_format;
	
       location /storage/ {
               root /www/static-host/;
               expires     24h;
             }


        ssl                  on;
	ssl_certificate      /etc/nginx/cert/crt.crt;
	ssl_certificate_key  /etc/nginx/cert/crt.key;

        location / {
                        proxy_pass   http://host;
			proxy_read_timeout 60s;
			proxy_next_upstream error timeout http_500 http_404;
                        proxy_set_header Host $host;
                        proxy_set_header   X-Real-IP        $remote_addr;
                        proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
                }

    }

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


From aa.vasilenko at gmail.com  Fri Oct 31 11:46:00 2014
From: aa.vasilenko at gmail.com (Alex Vasilenko)
Date: Fri, 31 Oct 2014 13:46:00 +0200
Subject: =?UTF-8?B?UmU6INCf0L7Rj9Cy0LvQtdC90LjQtSDRgdGC0YDQsNC90L3QvtC5INC30LDQv9C4?=
 =?UTF-8?B?0YHQuCDQsiDQu9C+0LPQsNGF?=
In-Reply-To: <104ac08e6c7f3e62ba797fb2776319ba.NginxMailingListRussian@forum.nginx.org>
References: <104ac08e6c7f3e62ba797fb2776319ba.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAJLyKy1eiTXYfHGZoWHaASsp9jwpE0saGgzADHSiFLbb07faeQ@mail.gmail.com>

Точно не могу утверждать, но это может быть обрыв соединения по таймауту:
клиент инициировал соединение, но при этом сам HTTP-запрос не передал (или
передал не полностью). При этом nginx не имея данных самого запроса пишет в
дефолтный лог 400 ответ и все прочерки.

С таким видом запросов еще связаны определенные виды атак на серверы, но
если это единичные записи в логах, то скорее всего у кого-то проблемы с
интернетом.

Alexandr Vasilenko

2014-10-31 13:08 GMT+02:00 Nikolay <nginx-forum at nginx.us>:

> При обращении к http://host.domain.tld в логах появляется запись
>
> 1.1.1.1 - - [31/Oct/2014:13:03:17 +0300] "GET / HTTP/1.1" 200 31 "-" 0.003
> 0.003 -"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/38.0.2125.104 Safari/537.36" "-" "host.domain.tld" "http"
>
> а через несколько секунд вторая:
>
> 1.1.1.1 - - [31/Oct/2014:13:02:04 +0300] "-" 400 0 "-" - 0.000 -"-" "-"
> "host.domain.tld" "http"
> Второго запроса не делаю, но запись появляеися.
> Почему появляется вторая запись да еще с таким странным значением $request?
>
> Log format:
>
> log_format  host_log_format  '$remote_addr - $remote_user [$time_local]
> "$request" '
>                 '$status $body_bytes_sent "$http_referer" '
>                 '$upstream_response_time $request_time '
>                 '$request_body'
>                 '"$http_user_agent" "$http_x_forwarded_for" "$host"
> "$scheme"';
> Vhost:
>         server {
>                 listen       80 default_server;
>                 server_name  host.domain.tld;
>                 access_log  /var/log/host.domain.tld.nginx.access.log
> host_log_format;
>                 gzip off;
>
>                 location /storage/ {
>                         root /www/static-host/;
>                         expires     24h;
>                 }
>
>                 location / {
>                         proxy_pass   http://host;
>                         proxy_read_timeout 60s;
>                         proxy_next_upstream error timeout http_500
> http_404;
>                         proxy_set_header Host $host;
>                         proxy_set_header   X-Real-IP        $remote_addr;
>                         proxy_set_header X-Forwarded-For
> $proxy_add_x_forwarded_for;
>                 }
>         }
>
> server {
>         listen *:443 default_server;
>         server_name host.domain.tld;
>         access_log  /var/log/host.domain.tld.nginx.access.log
> host_log_format;
>
>        location /storage/ {
>                root /www/static-host/;
>                expires     24h;
>              }
>
>
>         ssl                  on;
>         ssl_certificate      /etc/nginx/cert/crt.crt;
>         ssl_certificate_key  /etc/nginx/cert/crt.key;
>
>         location / {
>                         proxy_pass   http://host;
>                         proxy_read_timeout 60s;
>                         proxy_next_upstream error timeout http_500
> http_404;
>                         proxy_set_header Host $host;
>                         proxy_set_header   X-Real-IP        $remote_addr;
>                         proxy_set_header X-Forwarded-For
> $proxy_add_x_forwarded_for;
>                 }
>
>     }
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,254485,254485#msg-254485
>
> _______________________________________________
> 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/20141031/ab946e9f/attachment-0001.html>

From nginx-forum at nginx.us  Fri Oct 31 12:08:52 2014
From: nginx-forum at nginx.us (Nikolay)
Date: Fri, 31 Oct 2014 08:08:52 -0400
Subject: =?UTF-8?B?UmU6INCf0L7Rj9Cy0LvQtdC90LjQtSDRgdGC0YDQsNC90L3QvtC5INC30LDQv9C4?=
 =?UTF-8?B?0YHQuCDQsiDQu9C+0LPQsNGF?=
In-Reply-To: <CAJLyKy1eiTXYfHGZoWHaASsp9jwpE0saGgzADHSiFLbb07faeQ@mail.gmail.com>
References: <CAJLyKy1eiTXYfHGZoWHaASsp9jwpE0saGgzADHSiFLbb07faeQ@mail.gmail.com>
Message-ID: <49dd5b016dc6c6bc683e24d044305b40.NginxMailingListRussian@forum.nginx.org>

Провел эксперимент еще раз, одновременно со второй записью в access логе
появляется запись в error логе:

2014/10/31 14:59:45 [info] 30851#0: *2589 client prematurely closed
connection while reading client request line, client: 1.1.1.1, server:
host.domain.tld

похоже дело действительно в обрыве соединения, но как с этим бороться?

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


From vl at nginx.com  Fri Oct 31 12:13:07 2014
From: vl at nginx.com (Vladimir Homutov)
Date: Fri, 31 Oct 2014 15:13:07 +0300
Subject: =?UTF-8?B?UmU6INCf0L7Rj9Cy0LvQtdC90LjQtSDRgdGC0YDQsNC90L3QvtC5INC30LDQv9C4?=
 =?UTF-8?B?0YHQuCDQsiDQu9C+0LPQsNGF?=
In-Reply-To: <49dd5b016dc6c6bc683e24d044305b40.NginxMailingListRussian@forum.nginx.org>
References: <CAJLyKy1eiTXYfHGZoWHaASsp9jwpE0saGgzADHSiFLbb07faeQ@mail.gmail.com>
 <49dd5b016dc6c6bc683e24d044305b40.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20141031121306.GA19653@vlpc>

On Fri, Oct 31, 2014 at 08:08:52AM -0400, Nikolay wrote:
> Провел эксперимент еще раз, одновременно со второй записью в access логе
> появляется запись в error логе:
>
> 2014/10/31 14:59:45 [info] 30851#0: *2589 client prematurely closed
> connection while reading client request line, client: 1.1.1.1, server:
> host.domain.tld
>
> похоже дело действительно в обрыве соединения, но как с этим бороться?
>

http://mailman.nginx.org/pipermail/nginx/2011-September/029045.html


From nginx-forum at nginx.us  Fri Oct 31 12:15:43 2014
From: nginx-forum at nginx.us (Nikolay)
Date: Fri, 31 Oct 2014 08:15:43 -0400
Subject: =?UTF-8?B?UmU6INCf0L7Rj9Cy0LvQtdC90LjQtSDRgdGC0YDQsNC90L3QvtC5INC30LDQv9C4?=
 =?UTF-8?B?0YHQuCDQsiDQu9C+0LPQsNGF?=
In-Reply-To: <20141031121306.GA19653@vlpc>
References: <20141031121306.GA19653@vlpc>
Message-ID: <e02d8583ee9911ab511c7be24e0ebc00.NginxMailingListRussian@forum.nginx.org>

Проверил, все действительно так и есть. Большое спасибо за помощь.

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


From semenukha at gmail.com  Fri Oct 31 14:03:49 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Fri, 31 Oct 2014 10:03:49 -0400
Subject: =?UTF-8?B?UmU6IFJlOiBuZ2lueCDQutCw0LogaHR0cHMg0YDQtdC00LjRgNC10LrRgtC+0YA=?=
In-Reply-To: <e01fa5d5c5848a8078b77f1e67805b20.NginxMailingListRussian@forum.nginx.org>
References: <CALA_TQhzON=4j50h4_QHEd_2OrWiSrKppJioj6ayEkES8aKiJQ@mail.gmail.com>
 <e01fa5d5c5848a8078b77f1e67805b20.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4354774.W7Hfps0PLS@tornado>

On Friday, October 31, 2014 06:12:02 AM killart wrote:
> Cкомпрометировав "центральный" nginx злоумышленник не сможет расшифровать
> проходящий через него https трафик.
> 
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,254421,254481#msg-254481
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

По заданным вами условиям Nginx должен расшифровывать трафик и даже выявлять в 
нем URL/домены. Думаю, в таком виде задача невыполнима.
-- 
Best regards,
Styopa Semenukha.

From nginx-forum at nginx.us  Fri Oct 31 16:28:18 2014
From: nginx-forum at nginx.us (killart)
Date: Fri, 31 Oct 2014 12:28:18 -0400
Subject: =?UTF-8?B?UmU6IFJlOiBuZ2lueCDQutCw0LogaHR0cHMg0YDQtdC00LjRgNC10LrRgtC+0YA=?=
In-Reply-To: <4354774.W7Hfps0PLS@tornado>
References: <4354774.W7Hfps0PLS@tornado>
Message-ID: <cdab4abeb22bb8b519a17ec199b12358.NginxMailingListRussian@forum.nginx.org>

Да, Вы правы. Предложенный вариант не работает.
Возможно на периметровом  nginx редиректить (по round robin) HTTP и HTTPS
запросы на пул внутренних серверов nginx работающие как прокси и
SSL-терминаторы без выявления URL/доменов? Или правильнее не заморачиваться
с nginx и реализовать при помощи LVS?

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