From aler2 at yandex.ru  Tue Jul  2 10:07:23 2013
From: aler2 at yandex.ru (=?koi8-r?B?4czFy9PBzsTSIOLBwsnO?=)
Date: Tue, 02 Jul 2013 14:07:23 +0400
Subject: =?UTF-8?B?0J/QtdGA0LXQvtC/0YDQtdC00LXQu9C10L3QuNC1INC30LDQs9C+0LvQvtCy0Lo=?=
 =?UTF-8?B?0LAgIkNvbm5lY3Rpb24i?=
Message-ID: <1396551372759643@web19f.yandex.ru>

Привет всем !
Столкнулся с такой проблемой. Есть некий портал, крутится на JBOSS. Используется NGINX в качестве front-end. По документации настроен keep-alive:

http{
...
keepalive_timeout 45 45;
keepalive_requests 1000;
...
}

А вот редирект на JBOSS, то есть на back-end:

server{
...
location /our-portal/ {
proxy_pass http://127.0.0.1:8080;
break;
error_page 404 = @404;
error_page 502 = @502;
error_page 504 = @504;
}
...
}

Проанализировал сетевые дампы между клиентом , nginx и jboss, и оказалось, что в случае проксирования клиенту всегда приходит Connection:close . В этом вся и проблема, несмотря на настройки в Nginx, возможно , что-то не так настроено...
СтОит отметить, что back-end ВСЕГДА возвращает вообще ответ без заголовка Connection. Причем это не зависит от заголовка запроса. Таким образом, в качестве исходных данных считаем, что back-end НИКОГДА не шлет заголовок Connection. 
Я попытался в реврайт добавить ручками нужный заголовок через more_set_headers:

location /our-portal/ {
proxy_pass http://127.0.0.1:8080;
more_set_headers 'connection: keep-alive';
break;
error_page 404 = @404;
error_page 502 = @502;
error_page 504 = @504;
}

но в этом случае в браузер приходит "Connection : close, keep-alive", и здесь, согласно документации, должно приходить только одно значение. Так что , как будут вести себя разные типы браузеров - неясно. 
Как быть в этом случае ? как заставить отдавать "Connection: keep-alive" ? если это возможно..

Спасибо!


From citrin at citrin.ru  Tue Jul  2 10:54:54 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Tue, 02 Jul 2013 14:54:54 +0400
Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7Qv9GA0LXQtNC10LvQtdC90LjQtSDQt9Cw0LPQvtC70L4=?=
 =?UTF-8?B?0LLQutCwICJDb25uZWN0aW9uIg==?=
In-Reply-To: <1396551372759643@web19f.yandex.ru>
References: <1396551372759643@web19f.yandex.ru>
Message-ID: <51D2B17E.4070100@citrin.ru>

On 07/02/13 14:07, Александр Бабин wrote:
> more_set_headers 'connection: keep-alive';
> break;
> error_page 404 = @404;
> error_page 502 = @502;
> error_page 504 = @504;
> }
>
> но в этом случае в браузер приходит "Connection : close, keep-alive", и здесь, согласно документации, должно приходить только одно значение. Так что , как будут вести себя разные типы браузеров - неясно.
> Как быть в этом случае ? как заставить отдавать "Connection: keep-alive" ? если это возможно..

Для начала попробуйте воспроизвести проблему без сторонних модулей. Еще полезно 
указывать версию nginx (а лучше вывод nginx -V).


From chipitsine at gmail.com  Tue Jul  2 11:30:24 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Tue, 2 Jul 2013 17:30:24 +0600
Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7Qv9GA0LXQtNC10LvQtdC90LjQtSDQt9Cw0LPQvtC70L4=?=
 =?UTF-8?B?0LLQutCwICJDb25uZWN0aW9uIg==?=
In-Reply-To: <1396551372759643@web19f.yandex.ru>
References: <1396551372759643@web19f.yandex.ru>
Message-ID: <CAFHpkQH7ORid1jWnvSs6AtZ-vrNOqFdAS7Qk53cbQmHdHzfcjA@mail.gmail.com>

На HTTP/1.1 заголовок Connection необязателен, дефолтным значением
считается Keep-Alive.
"заставлять" никого не надо.

2 июля 2013 г., 16:07 пользователь Александр Бабин <aler2 at yandex.ru> написал:
> Привет всем !
> Столкнулся с такой проблемой. Есть некий портал, крутится на JBOSS. Используется NGINX в качестве front-end. По документации настроен keep-alive:
>
> http{
> ...
> keepalive_timeout 45 45;
> keepalive_requests 1000;
> ...
> }
>
> А вот редирект на JBOSS, то есть на back-end:
>
> server{
> ...
> location /our-portal/ {
> proxy_pass http://127.0.0.1:8080;
> break;
> error_page 404 = @404;
> error_page 502 = @502;
> error_page 504 = @504;
> }
> ...
> }
>
> Проанализировал сетевые дампы между клиентом , nginx и jboss, и оказалось, что в случае проксирования клиенту всегда приходит Connection:close . В этом вся и проблема, несмотря на настройки в Nginx, возможно , что-то не так настроено...
> СтОит отметить, что back-end ВСЕГДА возвращает вообще ответ без заголовка Connection. Причем это не зависит от заголовка запроса. Таким образом, в качестве исходных данных считаем, что back-end НИКОГДА не шлет заголовок Connection.
> Я попытался в реврайт добавить ручками нужный заголовок через more_set_headers:
>
> location /our-portal/ {
> proxy_pass http://127.0.0.1:8080;
> more_set_headers 'connection: keep-alive';
> break;
> error_page 404 = @404;
> error_page 502 = @502;
> error_page 504 = @504;
> }
>
> но в этом случае в браузер приходит "Connection : close, keep-alive", и здесь, согласно документации, должно приходить только одно значение. Так что , как будут вести себя разные типы браузеров - неясно.
> Как быть в этом случае ? как заставить отдавать "Connection: keep-alive" ? если это возможно..
>
> Спасибо!
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin at mdounin.ru  Tue Jul  2 13:34:37 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 2 Jul 2013 17:34:37 +0400
Subject: nginx-1.5.2
Message-ID: <20130702133437.GF20717@mdounin.ru>

Изменения в nginx 1.5.2                                           02.07.2013

    *) Добавление: теперь можно использовать несколько директив error_log.

    *) Исправление: метод $r->header_in() встроенного перла не возвращал
       значения строк "Cookie" и "X-Forwarded-For" из заголовка запроса;
       ошибка появилась в 1.3.14.

    *) Исправление: в модуле ngx_http_spdy_module.
       Спасибо Jim Radford.

    *) Исправление: nginx не собирался на Linux при использовании x32 ABI.
       Спасибо Сергею Иванцову.


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


From karamba66 at ukr.net  Tue Jul  2 16:54:34 2013
From: karamba66 at ukr.net (ZZZ)
Date: Tue, 02 Jul 2013 18:54:34 +0200
Subject: =?UTF-8?Q?error=5Fpage_=D0=B8_limit=5Freq?=
Message-ID: <51D305CA.90308@ukr.net>

Привет.

Использую ограничение частоты запросов такого вида:

limit_req_zone $http_host zone=openx:10m rate=100r/s;
...
location / {
limit_req zone=openx;
...

всё работает. Но тут возникла необходимость переопределить статус ошибки 
для тех кто не "вместился" в лимит. Ответ должен быть 204.
limit_req_status даёт выставить только ответы с 400 по 599. Я решил 
использовать error_page 503 =204 но после этого сразу перестаёт работать 
limit_req. Я хочу слишком странного ?



From swood at fotofor.biz  Tue Jul  2 17:02:42 2013
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Tue, 2 Jul 2013 21:02:42 +0400
Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7Qv9GA0LXQtNC10LvQtdC90LjQtSDQt9Cw0LPQvtC70L4=?=
 =?UTF-8?B?0LLQutCwICJDb25uZWN0aW9uIg==?=
In-Reply-To: <CAFHpkQH7ORid1jWnvSs6AtZ-vrNOqFdAS7Qk53cbQmHdHzfcjA@mail.gmail.com>
References: <1396551372759643@web19f.yandex.ru>
 <CAFHpkQH7ORid1jWnvSs6AtZ-vrNOqFdAS7Qk53cbQmHdHzfcjA@mail.gmail.com>
Message-ID: <CAM_jxg2gzYZogtxSDa-QeU8HDjefOZeOL2=cJ4Sv-TY4wG2tbA@mail.gmail.com>

А не может ли дело быть в отсутствующем заголовке host?
02.07.2013 16:16 пользователь "Илья Шипицин" <chipitsine at gmail.com> написал:

> На HTTP/1.1 заголовок Connection необязателен, дефолтным значением
> считается Keep-Alive.
> "заставлять" никого не надо.
>
> 2 июля 2013 г., 16:07 пользователь Александр Бабин <aler2 at yandex.ru>
> написал:
> > Привет всем !
> > Столкнулся с такой проблемой. Есть некий портал, крутится на JBOSS.
> Используется NGINX в качестве front-end. По документации настроен
> keep-alive:
> >
> > http{
> > ...
> > keepalive_timeout 45 45;
> > keepalive_requests 1000;
> > ...
> > }
> >
> > А вот редирект на JBOSS, то есть на back-end:
> >
> > server{
> > ...
> > location /our-portal/ {
> > proxy_pass http://127.0.0.1:8080;
> > break;
> > error_page 404 = @404;
> > error_page 502 = @502;
> > error_page 504 = @504;
> > }
> > ...
> > }
> >
> > Проанализировал сетевые дампы между клиентом , nginx и jboss, и
> оказалось, что в случае проксирования клиенту всегда приходит
> Connection:close . В этом вся и проблема, несмотря на настройки в Nginx,
> возможно , что-то не так настроено...
> > СтОит отметить, что back-end ВСЕГДА возвращает вообще ответ без
> заголовка Connection. Причем это не зависит от заголовка запроса. Таким
> образом, в качестве исходных данных считаем, что back-end НИКОГДА не шлет
> заголовок Connection.
> > Я попытался в реврайт добавить ручками нужный заголовок через
> more_set_headers:
> >
> > location /our-portal/ {
> > proxy_pass http://127.0.0.1:8080;
> > more_set_headers 'connection: keep-alive';
> > break;
> > error_page 404 = @404;
> > error_page 502 = @502;
> > error_page 504 = @504;
> > }
> >
> > но в этом случае в браузер приходит "Connection : close, keep-alive", и
> здесь, согласно документации, должно приходить только одно значение. Так
> что , как будут вести себя разные типы браузеров - неясно.
> > Как быть в этом случае ? как заставить отдавать "Connection: keep-alive"
> ? если это возможно..
> >
> > Спасибо!
> >
> > _______________________________________________
> > 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/20130702/b4c798ed/attachment.html>

From mdounin at mdounin.ru  Tue Jul  2 22:01:23 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 3 Jul 2013 02:01:23 +0400
Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0LggbGltaXRfcmVx?=
In-Reply-To: <51D305CA.90308@ukr.net>
References: <51D305CA.90308@ukr.net>
Message-ID: <20130702220123.GK20717@mdounin.ru>

Hello!

On Tue, Jul 02, 2013 at 06:54:34PM +0200, ZZZ wrote:

> Привет.
> 
> Использую ограничение частоты запросов такого вида:
> 
> limit_req_zone $http_host zone=openx:10m rate=100r/s;
> ...
> location / {
> limit_req zone=openx;
> ...
> 
> всё работает. Но тут возникла необходимость переопределить статус
> ошибки для тех кто не "вместился" в лимит. Ответ должен быть 204.
> limit_req_status даёт выставить только ответы с 400 по 599. Я решил
> использовать error_page 503 =204 но после этого сразу перестаёт
> работать limit_req. Я хочу слишком странного ?

Правильно как-то так:

    error_page 503 = @empty;

    location @empty {
        return 204;
    }

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


From nginx-forum at nginx.us  Wed Jul  3 09:45:24 2013
From: nginx-forum at nginx.us (tao)
Date: Wed, 03 Jul 2013 05:45:24 -0400
Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QviDQu9C4INC40YHQv9C+0LvRjNC30L7QstCw0YLRjCBu?=
 =?UTF-8?B?Z2lueCDQutCw0Log0YLRg9C90L3QtdC70Ywg0YEg0LrQtdGI0LjRgNC+0LI=?=
 =?UTF-8?B?0LDQvdC40LXQvCDRgdGC0LDRgtC40LrQuCDQuCB3ZWJzb2NrZXRz?=
Message-ID: <e642065f2074a1c41da297318adac231.NginxMailingListRussian@forum.nginx.org>

в браузере-клиенте (chrome) прописан ip http proxy (nginx) 
на домене club по 3000 порту висит socket.io с поддержкой xhr-pooling и
websockets и nginx для отдачи статики по 80 порту
все хорошо и отлично кешируется c 80 порта, xhr-pooling  тоже работает
отлично

Но как только переключаюсь на websockets  , получаю в логи
==
[ 03/Jul/2013:11:50:17 +0400 ] -  "CONNECT club:3000 HTTP/1.1" "400"
"rt:0.018" "urt:-" "cache: -" 



==== CONFIG
map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}

upstream club_80        {    server club:80;}
upstream club_3000      {    server club:3000;}

server {

    listen 8090;
    server_name _;
    access_log /var/log/nginx/proxy.8090.access.log common;
    error_log  /var/log/nginx/proxy.8090.error.log;

    source_charset utf-8;
    charset        utf-8;

    recursive_error_pages on;

    #upstream mapping
    set $xport 80;
    if ($http_host ~ ":(\d+)") { set $xport $1; }
    set $upstr "club_${xport}";


    error_page 417 = @cached;
    error_page 418 = @nocached;
    
    proxy_http_version 1.1;
    proxy_set_header        Upgrade         $http_upgrade;
    proxy_set_header        Connection      $connection_upgrade;

    proxy_buffering off;
    
    location / {

        return 417;
    }
   location /socket.io {
        
        return 418;
    }
    
    location ~ /(ru|en/)?index.html {

        return 418;
    }
            
    #for index/socket.io
    location @nocached {
        proxy_read_timeout 86400;
        proxy_cache     off;
        proxy_pass      http://$upstr;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header              Cache-Control  
"no-cache,no-store,must-revalidate";
        expires -1;
    }
        
    #for static
    location @cached {
    
        proxy_cache_methods GET;
        proxy_cache_valid 200 5d;
        proxy_cache clubcache;
        proxy_pass      http://$upstr;
        proxy_set_header        Host            $host:$proxy_port;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_cache_bypass      $cookie_nocache $arg_nocache$arg_comment;
        proxy_cache_bypass      $http_pragma    $http_authorization;

        proxy_ignore_headers    X-Accel-Expires Expires Cache-Control
Set-Cookie;

        add_header Cache-Control "no-cache,no-store,must-revalidate";
        expires -1;

    }
}
================= END

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


From nginx-forum at nginx.us  Wed Jul  3 10:41:40 2013
From: nginx-forum at nginx.us (tao)
Date: Wed, 03 Jul 2013 06:41:40 -0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?=
 =?UTF-8?B?0Ywgbmdpbngg0LrQsNC6INGC0YPQvdC90LXQu9GMINGBINC60LXRiNC40YA=?=
 =?UTF-8?B?0L7QstCw0L3QuNC10Lwg0YHRgtCw0YLQuNC60Lgg0Lggd2Vic29ja2V0cw==?=
In-Reply-To: <e642065f2074a1c41da297318adac231.NginxMailingListRussian@forum.nginx.org>
References: <e642065f2074a1c41da297318adac231.NginxMailingListRussian@forum.nginx.org>
Message-ID: <94848e5aff327afeb1bdf563cb80ab56.NginxMailingListRussian@forum.nginx.org>

Забыл указать nginx 

nginx version: nginx/1.4.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) 
TLS SNI support enabled
configure arguments: 
--prefix=/etc/nginx 
--sbin-path=/usr/sbin/nginx 
--conf-path=/etc/nginx/nginx.conf 
--error-log-path=/var/log/nginx/error.log 
--http-log-path=/var/log/nginx/access.log 
--pid-path=/var/run/nginx.pid 
--lock-path=/var/run/nginx.lock 
--http-client-body-temp-path=/var/cache/nginx/client_temp 
--http-proxy-temp-path=/var/cache/nginx/proxy_temp 
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
--http-scgi-temp-path=/var/cache/nginx/scgi_temp 
--user=nginx 
--group=nginx 
--with-http_ssl_module 
--with-http_realip_module 
--with-http_addition_module 
--with-http_sub_module 
--with-http_gunzip_module 
--with-http_gzip_static_module 
--with-http_secure_link_module 
--with-http_stub_status_module 
--with-mail 
--with-mail_ssl_module 
--with-file-aio 
--with-ipv6 
--with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic' 
--add-module=/home/builder/rpmbuild/SOURCES/ngx_devel_kit 
--add-module=/home/builder/rpmbuild/SOURCES/redis2-nginx-module 
--add-module=/home/builder/rpmbuild/SOURCES/set-misc-nginx-module 
--add-module=/home/builder/rpmbuild/SOURCES/lua-nginx-module 
--add-module=/home/builder/rpmbuild/SOURCES/echo-nginx-module 
--add-module=/home/builder/rpmbuild/SOURCES/nginx-rtmp-module


tao Wrote:
-------------------------------------------------------
> в браузере-клиенте (chrome) прописан ip http proxy (nginx) 
> на домене club по 3000 порту висит socket.io с поддержкой xhr-pooling
> и websockets и nginx для отдачи статики по 80 порту
> все хорошо и отлично кешируется c 80 порта, xhr-pooling  тоже работает
> отлично
> 
> Но как только переключаюсь на websockets  , получаю в логи
> ==
> [ 03/Jul/2013:11:50:17 +0400 ] -  "CONNECT club:3000 HTTP/1.1" "400"
> "rt:0.018" "urt:-" "cache: -" 
> 
> 
> 
> ==== CONFIG
> map $http_upgrade $connection_upgrade {
>         default upgrade;
>         ''      close;
> }
> 
> upstream club_80        {    server club:80;}
> upstream club_3000      {    server club:3000;}
> 
> server {
> 
>     listen 8090;
>     server_name _;
>     access_log /var/log/nginx/proxy.8090.access.log common;
>     error_log  /var/log/nginx/proxy.8090.error.log;
> 
>     source_charset utf-8;
>     charset        utf-8;
> 
>     recursive_error_pages on;
> 
>     #upstream mapping
>     set $xport 80;
>     if ($http_host ~ ":(\d+)") { set $xport $1; }
>     set $upstr "club_${xport}";
> 
> 
>     error_page 417 = @cached;
>     error_page 418 = @nocached;
>     
>     proxy_http_version 1.1;
>     proxy_set_header        Upgrade         $http_upgrade;
>     proxy_set_header        Connection      $connection_upgrade;
> 
>     proxy_buffering off;
>     
>     location / {
> 
>         return 417;
>     }
>    location /socket.io {
>         
>         return 418;
>     }
>     
>     location ~ /(ru|en/)?index.html {
> 
>         return 418;
>     }
>             
>     #for index/socket.io
>     location @nocached {
>         proxy_read_timeout 86400;
>         proxy_cache     off;
>         proxy_pass      http://$upstr;
>         proxy_set_header        Host            $host;
>         proxy_set_header        X-Forwarded-For
> $proxy_add_x_forwarded_for;
>         add_header              Cache-Control  
> "no-cache,no-store,must-revalidate";
>         expires -1;
>     }
>         
>     #for static
>     location @cached {
>     
>         proxy_cache_methods GET;
>         proxy_cache_valid 200 5d;
>         proxy_cache clubcache;
>         proxy_pass      http://$upstr;
>         proxy_set_header        Host            $host:$proxy_port;
>         proxy_set_header        X-Forwarded-For
> $proxy_add_x_forwarded_for;
> 
>         proxy_cache_bypass      $cookie_nocache
> $arg_nocache$arg_comment;
>         proxy_cache_bypass      $http_pragma    $http_authorization;
> 
>         proxy_ignore_headers    X-Accel-Expires Expires Cache-Control
> Set-Cookie;
> 
>         add_header Cache-Control "no-cache,no-store,must-revalidate";
>         expires -1;
> 
>     }
> }
> ================= END

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


From sergey.kobzar at itcraft.org  Wed Jul  3 10:44:36 2013
From: sergey.kobzar at itcraft.org (Sergey Kobzar)
Date: Wed, 03 Jul 2013 13:44:36 +0300
Subject: Double gzip compression
Message-ID: <51D40094.4040008@itcraft.org>

Приветствую

На фронтенде (load balancer) стоит Nginx. За ним стоят бэкенды тоже с 
Nginx. На всех включено сжатие:

gzip on;
gzip_min_length 1024;
gzip_buffers 16 8k;
gzip_types application/x-javascript text/css text/plain;

Не будет ли load balancer повторно пережимать контент? Или его все-таки 
надо отключить для проксируемого контента как-то так:

location / {
	gzip off;

         proxy_pass http://backends;
	...
}

?


Спасибо.


From mdounin at mdounin.ru  Wed Jul  3 10:47:48 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 3 Jul 2013 14:47:48 +0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?=
 =?UTF-8?B?0Ywgbmdpbngg0LrQsNC6INGC0YPQvdC90LXQu9GMINGBINC60LXRiNC40YA=?=
 =?UTF-8?B?0L7QstCw0L3QuNC10Lwg0YHRgtCw0YLQuNC60Lgg0Lggd2Vic29ja2V0cw==?=
In-Reply-To: <e642065f2074a1c41da297318adac231.NginxMailingListRussian@forum.nginx.org>
References: <e642065f2074a1c41da297318adac231.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130703104748.GO20717@mdounin.ru>

Hello!

On Wed, Jul 03, 2013 at 05:45:24AM -0400, tao wrote:

> в браузере-клиенте (chrome) прописан ip http proxy (nginx) 
> на домене club по 3000 порту висит socket.io с поддержкой xhr-pooling и
> websockets и nginx для отдачи статики по 80 порту
> все хорошо и отлично кешируется c 80 порта, xhr-pooling  тоже работает
> отлично
> 
> Но как только переключаюсь на websockets  , получаю в логи
> ==
> [ 03/Jul/2013:11:50:17 +0400 ] -  "CONNECT club:3000 HTTP/1.1" "400"
> "rt:0.018" "urt:-" "cache: -" 

Ваша проблема в том, что nginx - не forward proxy, и не 
поддерживает метод CONNECT.

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


From mdounin at mdounin.ru  Wed Jul  3 10:49:10 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 3 Jul 2013 14:49:10 +0400
Subject: Double gzip compression
In-Reply-To: <51D40094.4040008@itcraft.org>
References: <51D40094.4040008@itcraft.org>
Message-ID: <20130703104910.GP20717@mdounin.ru>

Hello!

On Wed, Jul 03, 2013 at 01:44:36PM +0300, Sergey Kobzar wrote:

> Приветствую
> 
> На фронтенде (load balancer) стоит Nginx. За ним стоят бэкенды тоже
> с Nginx. На всех включено сжатие:
> 
> gzip on;
> gzip_min_length 1024;
> gzip_buffers 16 8k;
> gzip_types application/x-javascript text/css text/plain;
> 
> Не будет ли load balancer повторно пережимать контент? Или его
> все-таки надо отключить для проксируемого контента как-то так:
> 
> location / {
> 	gzip off;
> 
>         proxy_pass http://backends;
> 	...
> }
> 
> ?

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

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


From sergey.kobzar at itcraft.org  Wed Jul  3 11:00:45 2013
From: sergey.kobzar at itcraft.org (Sergey Kobzar)
Date: Wed, 03 Jul 2013 14:00:45 +0300
Subject: Double gzip compression
In-Reply-To: <20130703104910.GP20717@mdounin.ru>
References: <51D40094.4040008@itcraft.org> <20130703104910.GP20717@mdounin.ru>
Message-ID: <51D4045D.6060902@itcraft.org>

Максим

On 07/03/13 13:49, Maxim Dounin wrote:
> Hello!
>
> On Wed, Jul 03, 2013 at 01:44:36PM +0300, Sergey Kobzar wrote:
>
>> Приветствую
>>
>> На фронтенде (load balancer) стоит Nginx. За ним стоят бэкенды тоже
>> с Nginx. На всех включено сжатие:
>>
>> gzip on;
>> gzip_min_length 1024;
>> gzip_buffers 16 8k;
>> gzip_types application/x-javascript text/css text/plain;
>>
>> Не будет ли load balancer повторно пережимать контент? Или его
>> все-таки надо отключить для проксируемого контента как-то так:
>>
>> location / {
>> 	gzip off;
>>
>>          proxy_pass http://backends;
>> 	...
>> }
>>
>> ?
>
> Если бекенд возвращает сжатый контент, то nginx ничего
> дополнительно сжимать не будет.

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


From nginx-forum at nginx.us  Wed Jul  3 12:05:04 2013
From: nginx-forum at nginx.us (tao)
Date: Wed, 03 Jul 2013 08:05:04 -0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?=
 =?UTF-8?B?0Ywgbmdpbngg0LrQsNC6INGC0YPQvdC90LXQu9GMINGBINC60LXRiNC40YA=?=
 =?UTF-8?B?0L7QstCw0L3QuNC10Lwg0YHRgtCw0YLQuNC60Lgg0Lggd2Vic29ja2V0cw==?=
In-Reply-To: <20130703104748.GO20717@mdounin.ru>
References: <20130703104748.GO20717@mdounin.ru>
Message-ID: <478caf92c7bdfbef1b6dc261ca9d8cba.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
> 
> On Wed, Jul 03, 2013 at 05:45:24AM -0400, tao wrote:
> 
> > в браузере-клиенте (chrome) прописан ip http proxy (nginx) 
> > на домене club по 3000 порту висит socket.io с поддержкой
> xhr-pooling и
> > websockets и nginx для отдачи статики по 80 порту
> > все хорошо и отлично кешируется c 80 порта, xhr-pooling  тоже
> работает
> > отлично
> > 
> > Но как только переключаюсь на websockets  , получаю в логи
> > ==
> > [ 03/Jul/2013:11:50:17 +0400 ] -  "CONNECT club:3000 HTTP/1.1" "400"
> > "rt:0.018" "urt:-" "cache: -" 
> 
> Ваша проблема в том, что nginx - не forward proxy, и не 
> поддерживает метод CONNECT.
> 
> -- 
> Maxim Dounin
> http://nginx.org/en/donation.html
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


Возможно ли , предположить что эта проблема решится сторонним модулем aka
nginx_tcp_proxy_module ?

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


From mdounin at mdounin.ru  Wed Jul  3 12:15:23 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 3 Jul 2013 16:15:23 +0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?=
 =?UTF-8?B?0Ywgbmdpbngg0LrQsNC6INGC0YPQvdC90LXQu9GMINGBINC60LXRiNC40YA=?=
 =?UTF-8?B?0L7QstCw0L3QuNC10Lwg0YHRgtCw0YLQuNC60Lgg0Lggd2Vic29ja2V0cw==?=
In-Reply-To: <478caf92c7bdfbef1b6dc261ca9d8cba.NginxMailingListRussian@forum.nginx.org>
References: <20130703104748.GO20717@mdounin.ru>
 <478caf92c7bdfbef1b6dc261ca9d8cba.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130703121523.GT20717@mdounin.ru>

Hello!

On Wed, Jul 03, 2013 at 08:05:04AM -0400, tao wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > Hello!
> > 
> > On Wed, Jul 03, 2013 at 05:45:24AM -0400, tao wrote:
> > 
> > > в браузере-клиенте (chrome) прописан ip http proxy (nginx) 
> > > на домене club по 3000 порту висит socket.io с поддержкой
> > xhr-pooling и
> > > websockets и nginx для отдачи статики по 80 порту
> > > все хорошо и отлично кешируется c 80 порта, xhr-pooling  тоже
> > работает
> > > отлично
> > > 
> > > Но как только переключаюсь на websockets  , получаю в логи
> > > ==
> > > [ 03/Jul/2013:11:50:17 +0400 ] -  "CONNECT club:3000 HTTP/1.1" "400"
> > > "rt:0.018" "urt:-" "cache: -" 
> > 
> > Ваша проблема в том, что nginx - не forward proxy, и не 
> > поддерживает метод CONNECT.
> 
> Возможно ли , предположить что эта проблема решится сторонним модулем aka
> nginx_tcp_proxy_module ?

Это проблема решается сторонним forward proxy.  Говорят squid 
неплох.

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


From nginx-forum at nginx.us  Wed Jul  3 12:20:38 2013
From: nginx-forum at nginx.us (tao)
Date: Wed, 03 Jul 2013 08:20:38 -0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?=
 =?UTF-8?B?0Ywgbmdpbngg0LrQsNC6INGC0YPQvdC90LXQu9GMINGBINC60LXRiNC40YA=?=
 =?UTF-8?B?0L7QstCw0L3QuNC10Lwg0YHRgtCw0YLQuNC60Lgg0Lggd2Vic29ja2V0cw==?=
In-Reply-To: <20130703121523.GT20717@mdounin.ru>
References: <20130703121523.GT20717@mdounin.ru>
Message-ID: <ab0ea48ab8f80af01e6616f89d8a47ce.NginxMailingListRussian@forum.nginx.org>

Огромное спасибо

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


From nginx-forum at nginx.us  Wed Jul  3 18:38:31 2013
From: nginx-forum at nginx.us (shurik_saint)
Date: Wed, 03 Jul 2013 14:38:31 -0400
Subject: =?UTF-8?Q?HttpAccessKeyModule_=D0=B8=D0=BB=D0=B8_HttpSecureLinkModule?=
Message-ID: <8ef05ceacdcd2a649c5b80303216b988.NginxMailingListRussian@forum.nginx.org>

Подскажите, возможно ли как-то с использованием одного из модулей отдавать
статику только зарегистрированным пользователям и при этом не дёргать
backend для проверки?

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


From nginx-forum at nginx.us  Thu Jul  4 07:10:13 2013
From: nginx-forum at nginx.us (Kibets Alexander)
Date: Thu, 04 Jul 2013 03:10:13 -0400
Subject: =?UTF-8?B?cHJveHkgcGFzcyDQuCDRg9C60LDQt9Cw0L3QuNC1INC90L7QvNC10YDQsCDQv9C+?=
 =?UTF-8?B?0YDRgtCw?=
Message-ID: <6a38aa403dca197a3a20a30b22a394af.NginxMailingListRussian@forum.nginx.org>

Необходимо сделать проксирование WEB-Socket соединения
ВЕБ-часть открывает 2-ва WEB-Socket соединения на
http://mysite.com/ws_cmd
http://mysite.com/ws_data
по 80-му порту

Они должны пробрасоватся на http://mysite.com:8000

http
{
....

    server
    {
        listen ***.***.***.***:80;
        
       # Отдаем статику
       location ^~ /gmap2/
       {
           root /home/www/sites/nodejs/data/;
       }

       # WEB-Socket

       location /
       {
         # Извлекаем номер порта
         rewrite    ^/ws_cmd(/*/)    /ws_cmd    break;
         rewrite    ^/ws_data(/*/)   /ws_data   break;

         set  $port_num $1;
         # set   $port_num 8000; так тоже не работает
         # set   $port_num "8000"; так тоже не работает

так работает
proxy_pass http://mysite.com:8000;
а так !!! НЕ РАБОТАЕТ !!!
#proxy_pass http://mysite.com:$port_num;

         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "upgrade";
         proxy_buffering             off;
       }

    }

}

Я хочу в URL-е указывать номер порта на который должен пробрасоватся запрос
(для распределения нагрузки).
Помогите пожалуйста!

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


From anuryadov at gmail.com  Thu Jul  4 07:25:25 2013
From: anuryadov at gmail.com (=?KOI8-R?B?4c7E0sXKIPXS0cTP1w==?=)
Date: Thu, 4 Jul 2013 11:25:25 +0400
Subject: =?UTF-8?Q?Re=3A_HttpAccessKeyModule_=D0=B8=D0=BB=D0=B8_HttpSecureLinkModul?=
 =?UTF-8?Q?e?=
In-Reply-To: <8ef05ceacdcd2a649c5b80303216b988.NginxMailingListRussian@forum.nginx.org>
References: <8ef05ceacdcd2a649c5b80303216b988.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAJSpzyT15EM44NT7Av++r9vDru31qDuOabxGtuXtv4LCi_mofQ@mail.gmail.com>

Как вариант, можно при регистрации ставить куку, а потом при отдаче статики
ее проверять nginx-ом. Если есть - отдавать, если нет - 404.


3 июля 2013 г., 22:38 пользователь shurik_saint <nginx-forum at nginx.us>написал:

> Подскажите, возможно ли как-то с использованием одного из модулей отдавать
> статику только зарегистрированным пользователям и при этом не дёргать
> backend для проверки?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,240549,240549#msg-240549
>
> _______________________________________________
> 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/20130704/9f6a00b7/attachment.html>

From nginx-forum at nginx.us  Thu Jul  4 07:41:03 2013
From: nginx-forum at nginx.us (shurik_saint)
Date: Thu, 04 Jul 2013 03:41:03 -0400
Subject: =?UTF-8?Q?Re=3A_HttpAccessKeyModule_=D0=B8=D0=BB=D0=B8_HttpSecureLinkModul?=
 =?UTF-8?Q?e?=
In-Reply-To: <CAJSpzyT15EM44NT7Av++r9vDru31qDuOabxGtuXtv4LCi_mofQ@mail.gmail.com>
References: <CAJSpzyT15EM44NT7Av++r9vDru31qDuOabxGtuXtv4LCi_mofQ@mail.gmail.com>
Message-ID: <418a256d7bd60493d0f5691294dcd38e.NginxMailingListRussian@forum.nginx.org>

Т. е.
для accesskey_signature выставляем что-то вроде "$cookie_issignedin",
для всех залогиненых ставим куку issignedin, например, в "yes",
и раздаём ссылки вида
http://example.com/download/file.zip?key=09093abeac094, где "09093abeac094"
-- это заранее известный хэш куки issignedin.
Правильно я понял?

А что-то посложнее можно придумать?

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


From anuryadov at gmail.com  Thu Jul  4 10:21:06 2013
From: anuryadov at gmail.com (=?KOI8-R?B?4c7E0sXKIPXS0cTP1w==?=)
Date: Thu, 4 Jul 2013 14:21:06 +0400
Subject: =?UTF-8?Q?Re=3A_HttpAccessKeyModule_=D0=B8=D0=BB=D0=B8_HttpSecureLinkModul?=
 =?UTF-8?Q?e?=
In-Reply-To: <418a256d7bd60493d0f5691294dcd38e.NginxMailingListRussian@forum.nginx.org>
References: <CAJSpzyT15EM44NT7Av++r9vDru31qDuOabxGtuXtv4LCi_mofQ@mail.gmail.com>
 <418a256d7bd60493d0f5691294dcd38e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAJSpzyRGfoTWjbZ=BaqPu3p=mzaAJ57RdEOcOgtS+n5bYZfDug@mail.gmail.com>

Не понял в данном случае, зачем надо что-то передавать в ссылку после
file.zip. Ссылка для всех одна, а проверка уже идет из того, есть ли кука
соответствующая.
Например, выставляем при авторизации куку is_authorized в 1. И проверяем:
if($http_cookie ~* '^(.*)is_authorized=1(.*)$')
....тогда отдаем нормально
Иначе - 404.

>>А что-то посложнее можно придумать?
Посложнее в реализации? Зачем? :))

А вы случайно не файлообменник делаете? Ну т.е. обычный обмен файлами с
ограниченным доступом (чтобы скачивали не все, а только определенные люди)?
Если так, то проще сделать следующим образом (объясню саму идею, без
конкретной реализации). У вас есть кнопка, на которую человек может нажать,
чтобы получить право пользоваться файлом. Запускается скрипт, который
решает, можно ли ему этот файл получить или нет (например, заплатил ли он
за него или достаточно ли других прав - чистая бизнес-логика). Этот скрипт,
если человеку можно файл отдать, создает проверочный файлик вида
<ip_человека-сгенерированный_хэш>.
А в location, который эти файлы отдает, ставите проверку (примерно такую):

set $fileName '';
set $secretKey '';
if ($request_uri ~* ^/path_to_files/([0-9a-z]+)/(.+)$) {
        set $fileName $2;
        set $secretKey $1;
}
set $rightKey 0;
if (-f /path_to_download_keys/download_key/$remote_addr-$secretKey) {
      set $rightKey 1;
      rewrite ^(.*)$ /path_to_files/$fileName break;
}
if ( $rightKey != 1) {
      return 404;
}

Клиенту отдаете ссылку /path_to_files/<$secretKey>/<filename>. Здесь
$secretKey - это сгенерированный хэш из имени проверочного файлика.

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



4 июля 2013 г., 11:41 пользователь shurik_saint <nginx-forum at nginx.us>написал:

> Т. е.
> для accesskey_signature выставляем что-то вроде "$cookie_issignedin",
> для всех залогиненых ставим куку issignedin, например, в "yes",
> и раздаём ссылки вида
> http://example.com/download/file.zip?key=09093abeac094, где
> "09093abeac094"
> -- это заранее известный хэш куки issignedin.
> Правильно я понял?
>
> А что-то посложнее можно придумать?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,240549,240574#msg-240574
>
> _______________________________________________
> 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/20130704/fb6622f0/attachment-0001.html>

From gmm at csdoc.com  Thu Jul  4 11:18:39 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 04 Jul 2013 14:18:39 +0300
Subject: =?UTF-8?Q?Re=3A_HttpAccessKeyModule_=D0=B8=D0=BB=D0=B8_HttpSecureLinkModul?=
 =?UTF-8?Q?e?=
In-Reply-To: <CAJSpzyRGfoTWjbZ=BaqPu3p=mzaAJ57RdEOcOgtS+n5bYZfDug@mail.gmail.com>
References: <CAJSpzyT15EM44NT7Av++r9vDru31qDuOabxGtuXtv4LCi_mofQ@mail.gmail.com>
 <418a256d7bd60493d0f5691294dcd38e.NginxMailingListRussian@forum.nginx.org>
 <CAJSpzyRGfoTWjbZ=BaqPu3p=mzaAJ57RdEOcOgtS+n5bYZfDug@mail.gmail.com>
Message-ID: <51D55A0F.6040305@csdoc.com>

On 04.07.2013 13:21, Андрей Урядов wrote:

> set $fileName '';
> set $secretKey '';
> if ($request_uri ~* ^/path_to_files/([0-9a-z]+)/(.+)$) {
>          set $fileName $2;
>          set $secretKey $1;
> }
> set $rightKey 0;
> if (-f /path_to_download_keys/download_key/$remote_addr-$secretKey) {
>        set $rightKey 1;
>        rewrite ^(.*)$ /path_to_files/$fileName break;
> }
> if ( $rightKey != 1) {
>        return 404;
> }

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

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Thu Jul  4 23:00:50 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 5 Jul 2013 03:00:50 +0400
Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0Lgg0YPQutCw0LfQsNC90LjQtSDQvdC+0LzQtdGA0LAg?=
 =?UTF-8?B?0L/QvtGA0YLQsA==?=
In-Reply-To: <6a38aa403dca197a3a20a30b22a394af.NginxMailingListRussian@forum.nginx.org>
References: <6a38aa403dca197a3a20a30b22a394af.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130704230050.GY20717@mdounin.ru>

Hello!

On Thu, Jul 04, 2013 at 03:10:13AM -0400, Kibets Alexander wrote:

> Необходимо сделать проксирование WEB-Socket соединения
> ВЕБ-часть открывает 2-ва WEB-Socket соединения на
> http://mysite.com/ws_cmd
> http://mysite.com/ws_data
> по 80-му порту
> 
> Они должны пробрасоватся на http://mysite.com:8000
> 
> http
> {
> ....
> 
>     server
>     {
>         listen ***.***.***.***:80;
>         
>        # Отдаем статику
>        location ^~ /gmap2/
>        {
>            root /home/www/sites/nodejs/data/;
>        }
> 
>        # WEB-Socket
> 
>        location /
>        {
>          # Извлекаем номер порта
>          rewrite    ^/ws_cmd(/*/)    /ws_cmd    break;
>          rewrite    ^/ws_data(/*/)   /ws_data   break;
> 
>          set  $port_num $1;
>          # set   $port_num 8000; так тоже не работает
>          # set   $port_num "8000"; так тоже не работает
> 
> так работает
> proxy_pass http://mysite.com:8000;
> а так !!! НЕ РАБОТАЕТ !!!
> #proxy_pass http://mysite.com:$port_num;
> 
>          proxy_http_version 1.1;
>          proxy_set_header Upgrade $http_upgrade;
>          proxy_set_header Connection "upgrade";
>          proxy_buffering             off;
>        }
> 
>     }
> 
> }
> 
> Я хочу в URL-е указывать номер порта на который должен пробрасоватся запрос
> (для распределения нагрузки).
> Помогите пожалуйста!

В чём заключается "не работает"?

Использование переменных в proxy_pass, помимо прочего, приводит к 
тому, что nginx начинает пытаться в resolve'ить имя mysite.com, и 
скорее всего в логах при вышеприведённом конфиге будет ругань про 
то, что нужно указать resolver.  Подробнее тут:

http://nginx.org/r/proxy_pass/ru
http://nginx.org/r/resolver/ru

А вообще - для распределения нагрузки лучше описать блок 
upstream, подробнее тут:

http://nginx.org/r/upstream/ru

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


From admin at sysadmins.el.kg  Fri Jul  5 12:46:14 2013
From: admin at sysadmins.el.kg (admin at sysadmins.el.kg)
Date: Fri, 05 Jul 2013 18:46:14 +0600
Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0YDQtdGA0LDQudGC0L7QvCBodHRw?=
 =?UTF-8?B?ZCA9PiBuZ2lueCwg0LLQvtC30LzQvtC20L3Qvi3Qu9C4Pw==?=
In-Reply-To: <20130702220123.GK20717@mdounin.ru>
References: <51D305CA.90308@ukr.net> <20130702220123.GK20717@mdounin.ru>
Message-ID: <51D6C016.2080404@sysadmins.el.kg>

Возможно-ли конвертировать такой конфиг для апача под nginx?

<Location />
Require all granted
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} ^url=(.*)$ [NC]
RewriteRule .* %1 [P,L]
</Location>

Виртуалхост с этим локейшеном обрабатывает url типа 
https://proxy.tld/?url=http://backend.tld/filename и проксирует на 
соответствующий бэкенд в локалке.
Насколько я понимаю, nginx не имеет опции рерайта наподобие апачевской 
[P], а как иначе нарисовать - ума не приложу.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130705/b102a94f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sad_mini.gif
Type: image/gif
Size: 986 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130705/b102a94f/attachment.gif>

From nginx-forum at nginx.us  Sun Jul  7 09:09:10 2013
From: nginx-forum at nginx.us (akashm)
Date: Sun, 07 Jul 2013 05:09:10 -0400
Subject: =?UTF-8?Q?Addikt_Club=2CParis_Gay=2CLe_dep=C3=B4t?=
Message-ID: <6a7024ca4d05e5b9df26aac974337147.NginxMailingListRussian@forum.nginx.org>

Addikt Club,Paris Gay,Le dep?t


http://www.addiktclub.com/

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


From nginx-forum at nginx.us  Sun Jul  7 17:43:34 2013
From: nginx-forum at nginx.us (Antohat)
Date: Sun, 07 Jul 2013 13:43:34 -0400
Subject: =?UTF-8?B?0J7QsdGF0L7QtCDQvtCz0YDQsNC90LjRh9C10L3QuNC5IGxpbWl0IGNvbm4=?=
Message-ID: <b277b2690f050b907a38e2b96094b971.NginxMailingListRussian@forum.nginx.org>

Уважаемые разработчики!

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

limit_conn_zone $binary_remote_addr zone=addr:64m;
limit_conn addr 20;
limit_conn_log_level warn;

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

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

Не могли бы вы реализовать ограничение количества одновременных запросов с
одного IP на бекенд, т.к. текущий функционал limit_conn тут не помогает?

Спасибо,
Антон.

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


From mdounin at mdounin.ru  Sun Jul  7 21:50:13 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 8 Jul 2013 01:50:13 +0400
Subject: =?UTF-8?B?UmU6INCe0LHRhdC+0LQg0L7Qs9GA0LDQvdC40YfQtdC90LjQuSBsaW1pdCBjb25u?=
In-Reply-To: <b277b2690f050b907a38e2b96094b971.NginxMailingListRussian@forum.nginx.org>
References: <b277b2690f050b907a38e2b96094b971.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130707215013.GA30405@mdounin.ru>

Hello!

On Sun, Jul 07, 2013 at 01:43:34PM -0400, Antohat wrote:

> Уважаемые разработчики!
> 
> Мы используем на сайте ограничение на количество одновременных соединений с
> одного IP со следующим конфигом:
> 
> limit_conn_zone $binary_remote_addr zone=addr:64m;
> limit_conn addr 20;
> limit_conn_log_level warn;
> 
> Все работало отлично, но некоторое время назад мы с удивлением обнаружили,
> что бекенд обрабатывает более 500 запросов с одного IP.
> В результате анализа выяснилось, что какой-то смышленный малый создает
> большое количество соединений и сразу же их рвет. В результате nginx
> успевает передать запрос на бекенд, но т.к. пользователь сразу же рвет
> соединение и создает новые, то ограничение на количество запросов не
> срабатывает.
> 
> Я понимаю, что с точки зрения nginx тут все чисто, т.к. он считает только
> открытые соединения со стороны клиента, но если подумать, то limit_conn все
> таки используется администраторами как средство ограничения кол-ва
> одновременных запросов на бекенд, т.к. большое кол-во запросов на к самому
> Nginx совсем не проблема.
> 
> Не могли бы вы реализовать ограничение количества одновременных запросов с
> одного IP на бекенд, т.к. текущий функционал limit_conn тут не помогает?

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

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

http://nginx.org/r/proxy_ignore_client_abort

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

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


From nginx-forum at nginx.us  Mon Jul  8 10:16:50 2013
From: nginx-forum at nginx.us (Denis P.)
Date: Mon, 08 Jul 2013 06:16:50 -0400
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSBwcm94eSBwYXNzINC4IGxvY2F0aW9u?=
Message-ID: <8a54f77f0761a0244023108d4cf1bcdf.NginxMailingListRussian@forum.nginx.org>

Добрый день!

Хочу сделать доступность нескольких tomcat по одному имени, но с разными
location.
Т.е. есть http://server/, хочется обращаться по http://server/tomcat1 к
одному tomcat , и по http://server/tomcat2 ко второму. 

Если просто открыть http://server/tomcat1, то страница отображатется
нормально.

Проблема в другом.  Когда переходим по http://server/tomcat1/manager,
location обрезается и ссылка становится http://server/manager

Как сделать так, чтобы можно было по ссылкам ходить?

Конфиг:

server {
        listen          80;
        server_name     server;
        access_log  /var/log/nginx/access.log;
        error_log   /var/log/nginx/error.log;
        client_max_body_size 1024m;
        rewrite_log on;

        location /tomcat1/ {
                proxy_pass http://server_tomcat1:8080/;
                proxy_redirect http://server_tomcat1:8080/ /tomcat1/;
                proxy_set_header Host   $proxy_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
             }

        location /tomcat2/ {
                proxy_pass http://server_tomcat2:8080/;
                proxy_redirect http://server_tomcat2:8080/ /tomcat2/;
                proxy_set_header Host   $proxy_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,240642,240642#msg-240642


From denis at webmaster.spb.ru  Mon Jul  8 12:55:19 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 16:55:19 +0400
Subject: freebsd - Can't locate nginx.pm
Message-ID: <51DAB6B7.1000503@webmaster.spb.ru>

/usr/local/etc/rc.d/nginx reload
Performing sanity check on nginx configuration:
Can't locate nginx.pm in @INC (@INC contains: 
/usr/local/lib/perl5/5.10.1/BSDPAN 
/usr/local/lib/perl5/site_perl/5.10.1/mach 
/usr/local/lib/perl5/site_perl/5.10.1 /usr/local/lib/perl5/5.10.1/mach 
/usr/local/lib/perl5/5.10.1 .).
BEGIN failed--compilation aborted.
nginx: [alert] perl_parse() failed: 2
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

Недавно перезапуск работал нормально, и сейчас в памяти висит старая версия.
# ls -la /usr/local/lib/perl5/site_perl/5.10/mach/nginx.pm
-r--r--r--  1 root  wheel  3302 Jul  8 16:51 
/usr/local/lib/perl5/site_perl/5.10/mach/nginx.pm

то, что там 5.10 и 5.10.1 - чей баг, сборщика фри или нгинха?
nginx-1.4.1_1,1

# uname -a
FreeBSD cs3990 8.3-STABLE FreeBSD 8.3-STABLE #0: Thu Aug 30 23:26:18 MSK 
2012     root at cs3990:/usr/obj/usr/src/sys/GENERIC  i386

# cat /etc/make.conf|grep VERS
PERL_VERSION=5.10.1


From panfilov at sports.ru  Mon Jul  8 12:57:37 2013
From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=)
Date: Mon, 8 Jul 2013 16:57:37 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAB6B7.1000503@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
Message-ID: <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>

пути разные:

/usr/local/lib/perl5/site_**perl/5.10.1/mach
/usr/local/lib/perl5/site_**perl/5.10/mach


2013/7/8 denis <denis at webmaster.spb.ru>

> /usr/local/etc/rc.d/nginx reload
> Performing sanity check on nginx configuration:
> Can't locate nginx.pm in @INC (@INC contains: /usr/local/lib/perl5/5.10.1/
> **BSDPAN /usr/local/lib/perl5/site_**perl/5.10.1/mach
> /usr/local/lib/perl5/site_**perl/5.10.1 /usr/local/lib/perl5/5.10.1/**mach
> /usr/local/lib/perl5/5.10.1 .).
> BEGIN failed--compilation aborted.
> nginx: [alert] perl_parse() failed: 2
> nginx: configuration file /usr/local/etc/nginx/nginx.**conf test failed
>
> Недавно перезапуск работал нормально, и сейчас в памяти висит старая
> версия.
> # ls -la /usr/local/lib/perl5/site_**perl/5.10/mach/nginx.pm
> -r--r--r--  1 root  wheel  3302 Jul  8 16:51 /usr/local/lib/perl5/site_**
> perl/5.10/mach/nginx.pm
>
> то, что там 5.10 и 5.10.1 - чей баг, сборщика фри или нгинха?
> nginx-1.4.1_1,1
>
> # uname -a
> FreeBSD cs3990 8.3-STABLE FreeBSD 8.3-STABLE #0: Thu Aug 30 23:26:18 MSK
> 2012     root at cs3990:/usr/obj/usr/src/**sys/GENERIC  i386
>
> # cat /etc/make.conf|grep VERS
> PERL_VERSION=5.10.1
>
> ______________________________**_________________
> nginx-ru mailing list
> 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/20130708/464faf9b/attachment.html>

From citrin at citrin.ru  Mon Jul  8 12:59:20 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Mon, 08 Jul 2013 16:59:20 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAB6B7.1000503@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
Message-ID: <51DAB7A8.9060500@citrin.ru>

On 07/08/13 16:55, denis wrote:
> /usr/local/etc/rc.d/nginx reload
> Performing sanity check on nginx configuration:
> Can't locate nginx.pm in @INC (@INC contains: /usr/local/lib/perl5/5.10.1/BSDPAN
> /usr/local/lib/perl5/site_perl/5.10.1/mach /usr/local/lib/perl5/site_perl/5.10.1
> /usr/local/lib/perl5/5.10.1/mach /usr/local/lib/perl5/5.10.1 .).
> BEGIN failed--compilation aborted.
> nginx: [alert] perl_parse() failed: 2
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
>
> Недавно перезапуск работал нормально, и сейчас в памяти висит старая версия.
> # ls -la /usr/local/lib/perl5/site_perl/5.10/mach/nginx.pm
> -r--r--r--  1 root  wheel  3302 Jul  8 16:51
> /usr/local/lib/perl5/site_perl/5.10/mach/nginx.pm
>
> то, что там 5.10 и 5.10.1 - чей баг, сборщика фри или нгинха?
> nginx-1.4.1_1,1

5.10 уже не поддерживается портами FreeBSD.
Обновитесь до 5.12, а лучше сразу до 5.16, чтобы дольше потом не нужно было 
обновлять.

После обновления perl нужно будет пересобрать nginx (и все перловые модули).


From denis at webmaster.spb.ru  Mon Jul  8 13:01:16 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 17:01:16 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
Message-ID: <51DAB81C.10508@webmaster.spb.ru>

08.07.2013 16:57, Михаил Панфилов пишет:
> пути разные:
>
> /usr/local/lib/perl5/site_perl/5.10.1/mach
> /usr/local/lib/perl5/site_perl/5.10/mach
спасибо, кэп :)
см там же,
 > то, что там 5.10 и 5.10.1 - чей баг, сборщика фри или нгинха?

в этом 5.10 файлы только самого нгинха. Сделал так:
root at cs3990:/usr/local/lib/perl5/site_perl# cp 5.10/mach/nginx.pm 
5.10.1/mach/
root at cs3990:/usr/local/lib/perl5/site_perl# cp -rp 5.10/mach/auto/nginx 
5.10.1/mach/auto/
root at cs3990:/usr/local/lib/perl5/site_perl# /usr/local/etc/rc.d/nginx reload
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

заработало. Но корректно ли это и чья это вообще бага, как такое могло 
получиться?

и на всякий случай
# perl -v|grep 386
This is perl, v5.10.1 (*) built for i386-freebsd-thread-multi-64int

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

From pluknet at nginx.com  Mon Jul  8 13:02:32 2013
From: pluknet at nginx.com (Sergey Kandaurov)
Date: Mon, 8 Jul 2013 17:02:32 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAB6B7.1000503@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
Message-ID: <ACD8B0BA-1C23-422E-A938-3437CF32B180@nginx.com>

On Jul 8, 2013, at 4:55 PM, denis <denis at webmaster.spb.ru> wrote:
> /usr/local/etc/rc.d/nginx reload
> Performing sanity check on nginx configuration:
> Can't locate nginx.pm in @INC (@INC contains: /usr/local/lib/perl5/5.10.1/BSDPAN /usr/local/lib/perl5/site_perl/5.10.1/mach /usr/local/lib/perl5/site_perl/5.10.1 /usr/local/lib/perl5/5.10.1/mach /usr/local/lib/perl5/5.10.1 .).
> BEGIN failed--compilation aborted.
> nginx: [alert] perl_parse() failed: 2
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
> 
> Недавно перезапуск работал нормально, и сейчас в памяти висит старая версия.
> # ls -la /usr/local/lib/perl5/site_perl/5.10/mach/nginx.pm
> -r--r--r--  1 root  wheel  3302 Jul  8 16:51 /usr/local/lib/perl5/site_perl/5.10/mach/nginx.pm
> 
> то, что там 5.10 и 5.10.1 - чей баг, сборщика фри или нгинха?
> nginx-1.4.1_1,1
> 
> # uname -a
> FreeBSD cs3990 8.3-STABLE FreeBSD 8.3-STABLE #0: Thu Aug 30 23:26:18 MSK 2012     root at cs3990:/usr/obj/usr/src/sys/GENERIC  i386
> 
> # cat /etc/make.conf|grep VERS
> PERL_VERSION=5.10.1


Вам наверное сюда:

http://svnweb.freebsd.org/changeset/ports/320679

20130612:
  AFFECTS: users of  lang/perl* and any port that depends on it
  AUTHOR: az at FreeBSD.org

  lang/perl5.12 has been upgraded from version 5.12.4 to 5.12.5
  lang/perl5.14 has been upgraded from version 5.14.2 to 5.14.4
  lang/perl5.16 has been upgraded from version 5.16.2 to 5.16.3

  The directory structure where Perl is installed has also been modified:
  "major.minor" is now used instead of "major.minor.patchlevel".
[?]

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

-- 
Sergey Kandaurov
pluknet at nginx.com




From denis at webmaster.spb.ru  Mon Jul  8 13:03:25 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 17:03:25 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAB7A8.9060500@citrin.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru> <51DAB7A8.9060500@citrin.ru>
Message-ID: <51DAB89D.4050306@webmaster.spb.ru>

08.07.2013 16:59, Anton Yuzhaninov пишет:
>
> 5.10 уже не поддерживается портами FreeBSD.
> Обновитесь до 5.12, а лучше сразу до 5.16, чтобы дольше потом не нужно 
> было обновлять.
у нас есть софт, который тестировался именно с 5.10 и не получится 
"обновитесь до 5.16" сходу. Во всяком случае, при переходе с 5.8 на 5.10 
у нас были проблемы, которые решались около месяца.


From denis at webmaster.spb.ru  Mon Jul  8 13:05:15 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 17:05:15 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <ACD8B0BA-1C23-422E-A938-3437CF32B180@nginx.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <ACD8B0BA-1C23-422E-A938-3437CF32B180@nginx.com>
Message-ID: <51DAB90B.8030305@webmaster.spb.ru>

08.07.2013 17:02, Sergey Kandaurov пишет:
>
> Вам наверное сюда:
>
> http://svnweb.freebsd.org/changeset/ports/320679
>
> 20130612:
>    AFFECTS: users of  lang/perl* and any port that depends on it
>    AUTHOR: az at FreeBSD.org
>
>    lang/perl5.12 has been upgraded from version 5.12.4 to 5.12.5
>    lang/perl5.14 has been upgraded from version 5.14.2 to 5.14.4
>    lang/perl5.16 has been upgraded from version 5.16.2 to 5.16.3
>
>    The directory structure where Perl is installed has also been modified:
>    "major.minor" is now used instead of "major.minor.patchlevel".
> [?]
>
> Если придерживаться этой версии причины, то видимо вы чего-то недообновили.
То есть это "особенность" системы портов, приводящая к таким вот 
багам... понятно, спасибо. Какой файл поправить, чтобы вернуть 
major.minor.patchlevel

?


From denis at webmaster.spb.ru  Mon Jul  8 13:10:54 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 17:10:54 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAB90B.8030305@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <ACD8B0BA-1C23-422E-A938-3437CF32B180@nginx.com>
 <51DAB90B.8030305@webmaster.spb.ru>
Message-ID: <51DABA5E.8000202@webmaster.spb.ru>

08.07.2013 17:05, denis пишет:
>> Если придерживаться этой версии причины, то видимо вы чего-то 
>> недообновили.
>
> То есть это "особенность" системы портов, приводящая к таким вот 
> багам... понятно, спасибо. Какой файл поправить, чтобы вернуть 
> major.minor.patchlevel
а, придумал быстрый багфикс
root at cs3990:/usr/local/lib/perl5/site_perl# rm -rf 5.10
root at cs3990:/usr/local/lib/perl5/site_perl# ln -s 5.10.1 5.10

теперь будет оба варианта работать. Только я не понимаю, что мешало 
сделать подобную операцию при изменении структуры? Автоматом симлинк, 
чтобы не ломать зависимости и не нужно было срочно пересобирать весь 
зависимый софт только потому, что какой-то умник структуру поменял. Или 
менять @INC и на старые и на новые пути.


From citrin at citrin.ru  Mon Jul  8 13:15:36 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Mon, 08 Jul 2013 17:15:36 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAB90B.8030305@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <ACD8B0BA-1C23-422E-A938-3437CF32B180@nginx.com>
 <51DAB90B.8030305@webmaster.spb.ru>
Message-ID: <51DABB78.2050303@citrin.ru>

On 07/08/13 17:05, denis wrote:
> То есть это "особенность" системы портов, приводящая к таким вот багам...

Баг, это установка модулей в major.minor.patchlevel (как было раньше) и наконец 
то это исправили. Лучше поздно, чем никогда...

Между 5.10 и 5.12 не так много отличий, так что все таки рекомендую обновиться.

> понятно, спасибо. Какой файл поправить, чтобы вернуть major.minor.patchlevel

cd /usr/ports
svn diff -c 320679 Mk/bsd.perl.mk > ~/patch-r320679
patch -R < ~/patch-r320679

после этого пересобрать nginx


From vsjcfm at gmail.com  Mon Jul  8 13:24:21 2013
From: vsjcfm at gmail.com (Sayetsky Anton)
Date: Mon, 8 Jul 2013 16:24:21 +0300
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAB81C.10508@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
Message-ID: <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>

8 июля 2013 г., 16:01 пользователь denis <denis at webmaster.spb.ru> написал:
> заработало. Но корректно ли это и чья это вообще бага, как такое могло
> получиться?
Разруха начинается в головах. (с)

jason at jw:~$ egrep -A 10 "^20130204:" /usr/ports/UPDATING
...
20130204:
AFFECTS: users of lang/perl5.8 and lang/perl5.10
AUTHOR: az at FreeBSD.org

lang/perl5.8 and lang/perl5.10 have been removed since they've
been EOL by upstream. You will have to recompile all perl dependant
ports after updating your ports tree. Please see entry 20110517 for help.
...
jason at jw:~$

From denis at webmaster.spb.ru  Mon Jul  8 13:30:51 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 17:30:51 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DABB78.2050303@citrin.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <ACD8B0BA-1C23-422E-A938-3437CF32B180@nginx.com>
 <51DAB90B.8030305@webmaster.spb.ru> <51DABB78.2050303@citrin.ru>
Message-ID: <51DABF0B.3030406@webmaster.spb.ru>

08.07.2013 17:15, Anton Yuzhaninov пишет:
> On 07/08/13 17:05, denis wrote:
>> То есть это "особенность" системы портов, приводящая к таким вот 
>> багам...
>
> Баг, это установка модулей в major.minor.patchlevel (как было раньше) 
> и наконец то это исправили. Лучше поздно, чем никогда...
Ок. Но что мешало при этом переименовать 5.10.1 в 5.10 (условно) и 
сделать симлинк? Тогда не сломалось бы _ничего_, включая совместимость, 
кривые скрипты юзеров и прочее.

> Между 5.10 и 5.12 не так много отличий, так что все таки рекомендую 
> обновиться.
Сделаем на тестовом на 5.16 тогда уж сразу, и там будем работать... Что 
меня вымораживает в этих обновлениях -- 100% что-то сломается, и это 
большой недостаток системы портов (сама фря мне нравится, но порты 
реально дурные, банально гентушный portage+USE сильно функциональнее). 
Вот есть же perl-after-upgrade, но к великому сожалению нельзя просто 
обновить сам перл, и чтобы этот скрипт автоматом обновил все модули без 
необходимости пересборки. А так, с учетом сложных зависимостей, надо 
пересобирать 90% софта, что далеко не 10 минут и не всегда успешно, увы. 
Поэтому на боевых серверах приходится устраивать шаманские пляски с тем, 
чтобы вывести их из работы, обновить, отладить и снова ввести, что 
равнозначно перенакатке системы с нуля. А там, где нет резервных нод - 
молиться и закрывать статикой всё на время работы.
Ну и само обновление -- проще сразу сделать дамп всех пакетов перловых в 
файл, и потом переставлять утилитами типа portmaster с нежелательным 
обновлением софта типа БД...


From denis at webmaster.spb.ru  Mon Jul  8 13:34:59 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 17:34:59 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
Message-ID: <51DAC003.3010705@webmaster.spb.ru>

08.07.2013 17:24, Sayetsky Anton пишет:
> 8 июля 2013 г., 16:01 пользователь denis<denis at webmaster.spb.ru>  написал:
>> заработало. Но корректно ли это и чья это вообще бага, как такое могло
>> получиться?
> Разруха начинается в головах. (с)
>
> jason at jw:~$ egrep -A 10 "^20130204:" /usr/ports/UPDATING
> ...
> 20130204:
> AFFECTS: users of lang/perl5.8 and lang/perl5.10
> AUTHOR: az at FreeBSD.org
>
> lang/perl5.8 and lang/perl5.10 have been removed since they've
а что делать тем, у кого в продакшене именно на 5.8 привязка? Переходить 
на центос 5, где эта версия прибита гвоздями и исключает какую-либо 
замену в принципе кроме насильственной компиляции поверх?
У нас были проблемы с ухода с 5.8, и требовали переписывания примерно 20 
своих модулей. Не полностью конечно, но работы было достаточно. Что 
мешало оставить эти версии не трогая, кроме ЧСВ?


From vsjcfm at gmail.com  Mon Jul  8 13:41:10 2013
From: vsjcfm at gmail.com (Sayetsky Anton)
Date: Mon, 8 Jul 2013 16:41:10 +0300
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAC003.3010705@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
Message-ID: <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>

8 июля 2013 г., 16:34 пользователь denis <denis at webmaster.spb.ru> написал:
> а что делать тем, у кого в продакшене именно на 5.8 привязка? Переходить на
> центос 5, где эта версия прибита гвоздями и исключает какую-либо замену в
> принципе кроме насильственной компиляции поверх?
> У нас были проблемы с ухода с 5.8, и требовали переписывания примерно 20
> своих модулей. Не полностью конечно, но работы было достаточно. Что мешало
> оставить эти версии не трогая, кроме ЧСВ?
Во-первых, давайте в приличном обществе без луркояза, ок?
Во-вторых, удосужьтесь прочесть сообщение до конца, я даже его повторю:
lang/perl5.8 and lang/perl5.10 have been removed since they've
been EOL by upstream. You will have to recompile all perl dependant
ports after updating your ports tree. Please see entry 20110517 for help.

Если непонятно - почитайте о значении аббревиатуры EOL.
И да, "You will have to ___recompile all perl dependant ports___ after
updating your ports tree."
Если ваши скрипты кривоваты, и не могут быть легко перенесены на новую
версию, то обновление как минимум nginx (который dependant on perl)
является лишь вашей же проблемой и вашей ошибкой.
Так что, "Сынок, точно солнце встаёт каждый день на востоке, а заходит
на западе? Тогда ни в коем случае ничего не трогай!"

From citrin at citrin.ru  Mon Jul  8 13:59:13 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Mon, 08 Jul 2013 17:59:13 +0400
Subject: [offtopic] perl (was Re: freebsd - Can't locate nginx.pm)
In-Reply-To: <51DAC003.3010705@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
Message-ID: <51DAC5B1.60600@citrin.ru>

On 07/08/13 17:34, denis wrote:
>>
> а что делать тем, у кого в продакшене именно на 5.8 привязка? Переходить на
> центос 5, где эта версия прибита гвоздями и исключает какую-либо замену в
> принципе кроме насильственной компиляции поверх?
> У нас были проблемы с ухода с 5.8, и требовали переписывания примерно 20 своих
> модулей. Не полностью конечно, но работы было достаточно. Что мешало оставить
> эти версии не трогая, кроме ЧСВ?

Поддержка большого числа версий perl-а, требует дополнительных усилий от тех, 
кто поддерживает порты perl-а и Mk/* (а поддержка нужна, потому что 
инфраструктура портов развивается и иногда требует изменений в портах).

Поддерживать 5.10 который вышел в 2009-м и сейчас EoL желающих нет.

А вообще текущая стабильная версия perl-а уже 5.18.0 (но в портах пока нет).

Если у вас много perl-ового кода, который сложно изменить для работы с новыми 
версиями perl, то проще сделать так:
1. nginx и весь остальной перловый софт разнести по разным jail-ам (или вирт. 
машинам, если они есть).
2. В джайле с nginx использовать современный perl
В джайле с perl-овым софтом ставить нужный perl не из портов, а через 
App::perlbrew, а модули ставить через  Carton (и не обновлять, потому что рано 
или поздно столкнетесь с тем, что модулю нужна более свежая версия перла, чем есть).

Я поддерживаю некоторый (не очень маленький) объем perl-ового кода и после 5.10 
переход на последующие версии требовал простых изменений максимум нескольких 
строчек кода (с конструкциями, давно объявленными устаревшими типа if 
(defined(@array)) ). Из того, что я помню - сложным был только переход 5.6 - 
5.8, когда сильно поменялась работа с unicode.
Ну и полезно иметь тесты. Возможность прогнать make test на новой версии перла 
экономит время (хотя, конечно не гарантирует отсутствие багов)


From denis at webmaster.spb.ru  Mon Jul  8 14:16:59 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 18:16:59 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
Message-ID: <51DAC9DB.9090209@webmaster.spb.ru>

08.07.2013 17:41, Sayetsky Anton пишет:
> 8 июля 2013 г., 16:34 пользователь denis<denis at webmaster.spb.ru>  написал:
>> а что делать тем, у кого в продакшене именно на 5.8 привязка? Переходить на
>> центос 5, где эта версия прибита гвоздями и исключает какую-либо замену в
>> принципе кроме насильственной компиляции поверх?
>> У нас были проблемы с ухода с 5.8, и требовали переписывания примерно 20
>> своих модулей. Не полностью конечно, но работы было достаточно. Что мешало
>> оставить эти версии не трогая, кроме ЧСВ?
> Во-первых, давайте в приличном обществе без луркояза, ок?
а больше у меня нет предположений, зачем делать такую гадость. Это как 
дебиан, который очередным обновлением выпиливал jdk6 только потому, что 
он стал EOL, и тысячи человек крыли матом авторов дебиана, которым вдруг 
сломали в том числе продакшены. Тут можно долго говорить, что сами 
виноваты, надо было сначала на деплое обновить, прогнать кучу тестов 
функциональности, проверить все модули.. но мы не в идеальном мире живем 
и сделали они реально по свински. И у многих, реально многих продакшен и 
тестовый - один и тот же, ибо разделять просто нецелесообразно.

> Во-вторых, удосужьтесь прочесть сообщение до конца, я даже его повторю:
> lang/perl5.8 and lang/perl5.10 have been removed since they've
> been EOL by upstream. You will have to recompile all perl dependant
> ports after updating your ports tree. Please see entry 20110517 for help.
>
> Если непонятно - почитайте о значении аббревиатуры EOL.
У нормальных людей это всего-лишь значит, что на него больше не будет 
security bugfix, а не то что его выпилят принудительно, создавая лишние 
проблемы тем, кому необходима именно эта версия. Можно же было просто 
заморозить порт на последней версии, что и делают в линуксах, типа той 
же редхата/центоси 5 - там перл 5.8 до сих пор, и никто его не выпилил, 
оставив систему вообще без перла.
Тут еще хорошо привести в пример всякие встраиваемые системы, где после 
выпуска одни только багфиксы безопасности и делаются, а такое железо 
может работать десятилетиями, в том числе в военной и мед сферах (есть у 
знакомых ЭКГ под управлением доса, на 486 платформе - там из-за mmx бага 
макс 133МГц проц может быть), и платформе более 20 (30?) лет. А обновить 
нет денег, такое оборудование стоит по пол миллиона и выше, годовая 
прибыль такого уровня).

> И да, "You will have to ___recompile all perl dependant ports___ after
> updating your ports tree."
Про что и я. Проблемы начинаются уже в том, что необходимо обновить по 
сути _весь_ софт.

> Если ваши скрипты кривоваты, и не могут быть легко перенесены на новую
> версию,
Это не скрипты кривоваты, а язык меняется. В частости, в 5.8 было совсем 
плохо с юникодом, поэтому была куча хаков, которые надо было выпилить. 
Какие-то конструкции меняются, что-то убирается. А про "кривые скрипты 
юзеров" - это реалии жизни, такое есть у многих, просто потому что так 
быстрее делать, и для вспомогательных утилиток вполне допустимо.

И всё-таки во фре до сих пор обновить тот же perl или php даже внутри 
версии - иногда тот еще адЪ и содомия, я уж не говорю про минорное 
обновление, за таким все знакомые юзеры с вдс-ками ко мне бегут..


From denis at webmaster.spb.ru  Mon Jul  8 14:23:03 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 18:23:03 +0400
Subject: [offtopic] perl (was Re: freebsd - Can't locate nginx.pm)
In-Reply-To: <51DAC5B1.60600@citrin.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru> <51DAC5B1.60600@citrin.ru>
Message-ID: <51DACB47.7090704@webmaster.spb.ru>

08.07.2013 17:59, Anton Yuzhaninov пишет:
>
> Если у вас много perl-ового кода, который сложно изменить для работы с 
> новыми версиями perl, то проще сделать так:
Это да, вариант хороший.

> 1. nginx и весь остальной перловый софт разнести по разным jail-ам 
> (или вирт. машинам, если они есть).
> 2. В джайле с nginx использовать современный perl
> В джайле с perl-овым софтом ставить нужный perl не из портов, а через 
> App::perlbrew, 
Не осилили. У нас на некоторых узлах центось 5, пробовали ставить через 
perlbrew 5.10, но запустить так и не вышло - оно всегда юзало 5.8. И 
непонятно, как там модули ставить... Если бы были, кто эту систему 
осилил и мог советами помочь, может и внедрили бы.


> а модули ставить через  Carton (и не обновлять, потому что рано или 
> поздно столкнетесь с тем, что модулю нужна более свежая версия перла, 
> чем есть).
такого вообще не видели.

> Я поддерживаю некоторый (не очень маленький) объем perl-ового кода и 
> после 5.10 переход на последующие версии требовал простых изменений 
> максимум нескольких строчек кода (с конструкциями, давно объявленными 
> устаревшими типа if (defined(@array)) ). Из того, что я помню - 
> сложным был только переход 5.6 - 5.8, когда сильно поменялась работа с 
> unicode.
у нас 5.6 не было, а в 5.8 с юникодом тоже было много нюансов вплоть до 
того, что сайт рандомно показывал всё то хорошо, то кракозяблы, в 
результате было куча хаков вставлено. И при переходе на 5.10 
потребовался аудит почти всего кода.

> Ну и полезно иметь тесты. Возможность прогнать make test на новой 
> версии перла экономит время (хотя, конечно не гарантирует отсутствие 
> багов)
Согласен, нужно. Но много ли людей вообще знает, как их делать? Думаю, 
1%, у кого что-то серьезное и простой недопустим. И потом, тесты надо 
также писать, сопровождать, обновлять вместе с задачами.. и 100% 
покрытие нереально, там куча сил только на тесты будет уходить.


From denis at webmaster.spb.ru  Mon Jul  8 14:28:33 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 18:28:33 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
Message-ID: <51DACC91.1080508@webmaster.spb.ru>

08.07.2013 17:41, Sayetsky Anton пишет:
> Если непонятно - почитайте о значении аббревиатуры EOL.
> И да, "You will have to ___recompile all perl dependant ports___ after
> updating your ports tree."
и еще "прикол"
root at cs3990:/usr/ports/lang/perl5.16# perl-after-upgrade
perl-after-upgrade: Command not found.
root at cs3990:/usr/ports/lang/perl5.16# locate perl-after-upgrade
/usr/local/bin/perl-after-upgrade
/usr/local/man/man1/perl-after-upgrade.1.gz
root at cs3990:/usr/ports/lang/perl5.16# /usr/local/bin/perl-after-upgrade
/usr/local/bin/perl-after-upgrade: Command not found.

и как теперь это делается?


From citrin at citrin.ru  Mon Jul  8 14:38:52 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Mon, 08 Jul 2013 18:38:52 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DACC91.1080508@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DACC91.1080508@webmaster.spb.ru>
Message-ID: <51DACEFC.7020307@citrin.ru>

On 07/08/13 18:28, denis wrote:
>
> root at cs3990:/usr/ports/lang/perl5.16# perl-after-upgrade
> perl-after-upgrade: Command not found.
> root at cs3990:/usr/ports/lang/perl5.16# locate perl-after-upgrade
> /usr/local/bin/perl-after-upgrade
> /usr/local/man/man1/perl-after-upgrade.1.gz
> root at cs3990:/usr/ports/lang/perl5.16# /usr/local/bin/perl-after-upgrade
> /usr/local/bin/perl-after-upgrade: Command not found.
>
> и как теперь это делается?

Теперь perl-after-upgrade не нужен.

Раньше после обновления с 5.x.y на 5.x.(y+1) нужно было запускать perl-after-upgrade

Теперь после обновления с 5.16.3 на 5.16.4 (когда он выйдет) ничего делать не 
нужно будет.


From vsjcfm at gmail.com  Mon Jul  8 14:41:34 2013
From: vsjcfm at gmail.com (Sayetsky Anton)
Date: Mon, 8 Jul 2013 17:41:34 +0300
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAC9DB.9090209@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DAC9DB.9090209@webmaster.spb.ru>
Message-ID: <CAFG2KC+=7m6HkrTN8sbczhu2YarTU13B7FmN5znYBwfzkPG_5A@mail.gmail.com>

8 июля 2013 г., 17:16 пользователь denis <denis at webmaster.spb.ru> написал:
> а больше у меня нет предположений, зачем делать такую гадость. Это как
> дебиан, который очередным обновлением выпиливал jdk6 только потому, что он
> стал EOL, и тысячи человек крыли матом авторов дебиана, которым вдруг
> сломали в том числе продакшены. Тут можно долго говорить, что сами виноваты,
> надо было сначала на деплое обновить, прогнать кучу тестов функциональности,
> проверить все модули.. но мы не в идеальном мире живем и сделали они реально
> по свински. И у многих, реально многих продакшен и тестовый - один и тот же,
> ибо разделять просто нецелесообразно.
Выбросили jdk6 в пользу jdk7? Так perl с 5-й до 6-й версии не
обновляли. Минорное обновление - оно просто не может всё сломать. Если
так случилось - значит, неправильно всё написано.

> У нормальных людей это всего-лишь значит, что на него больше не будет
> security bugfix, а не то что его выпилят принудительно, создавая лишние
> проблемы тем, кому необходима именно эта версия. Можно же было просто
> заморозить порт на последней версии, что и делают в линуксах, типа той же
> редхата/центоси 5 - там перл 5.8 до сих пор, и никто его не выпилил, оставив
> систему вообще без перла.
У нормальных людей EOL значит, что продукт более _не поддерживается_,
и помощи в решении проблем с ним _не будет_. В качестве оффтоп-аналога
- как думаете, куда вас пошлёт саппорт МС, если зададите им вопрос о
Windows 98?

> Тут еще хорошо привести в пример всякие встраиваемые системы, где после
> выпуска одни только багфиксы безопасности и делаются, а такое железо может
> работать десятилетиями, в том числе в военной и мед сферах (есть у знакомых
> ЭКГ под управлением доса, на 486 платформе - там из-за mmx бага макс 133МГц
> проц может быть), и платформе более 20 (30?) лет. А обновить нет денег,
> такое оборудование стоит по пол миллиона и выше, годовая прибыль такого
> уровня).
Стоит. Работает. Не трогают. Так зачем вам было трогать систему,
которая работала?

> Это не скрипты кривоваты, а язык меняется. В частости, в 5.8 было совсем
> плохо с юникодом, поэтому была куча хаков, которые надо было выпилить.
> Какие-то конструкции меняются, что-то убирается. А про "кривые скрипты
> юзеров" - это реалии жизни, такое есть у многих, просто потому что так
> быстрее делать, и для вспомогательных утилиток вполне допустимо.
Опять же, между 5.10 и 5.1{2,4,6} разве такая непреодолимая разница?

> И всё-таки во фре до сих пор обновить тот же perl или php даже внутри версии
> - иногда тот еще адЪ и содомия, я уж не говорю про минорное обновление, за
> таким все знакомые юзеры с вдс-ками ко мне бегут..
Вы просто не умеете её готовить. (с)
У меня почему-то таких проблем не возникает. Нужно всего лишь читать
UPDATING перед любым запуском make (ручным или автоматическим) в
пределах ${PORTSDIR}. А если есть много машин, то ставим
tinderbox/poudriere (лучше последний + pkg), делаем свою репу и ставим
оттуда. Ну, или юзаем pkg_add (в котором версии пакетов, кстати, тоже
заморожены, ибо собирается это один раз - во время выхода очередного
релиза).
Более того, perl5.10 удалили ещё в марте. Т.е. вам не хватило трёх
месяцев для того, чтобы поправить несколько десятков строк, если уж
скрипты всё-таки не запускаются на новой версии?

From vsjcfm at gmail.com  Mon Jul  8 14:46:10 2013
From: vsjcfm at gmail.com (Sayetsky Anton)
Date: Mon, 8 Jul 2013 17:46:10 +0300
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DACC91.1080508@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DACC91.1080508@webmaster.spb.ru>
Message-ID: <CAFG2KC+wu8V=fsRhncdRa0tgov7NFzyYGnMLgwMUjV3o3BrHvA@mail.gmail.com>

2013/7/8 denis <denis at webmaster.spb.ru>:
> и еще "прикол"
> root at cs3990:/usr/ports/lang/perl5.16# perl-after-upgrade
> perl-after-upgrade: Command not found.
> root at cs3990:/usr/ports/lang/perl5.16# locate perl-after-upgrade
> /usr/local/bin/perl-after-upgrade
> /usr/local/man/man1/perl-after-upgrade.1.gz
> root at cs3990:/usr/ports/lang/perl5.16# /usr/local/bin/perl-after-upgrade
> /usr/local/bin/perl-after-upgrade: Command not found.
>
> и как теперь это делается?
И опять же проблема нежелания читать и понимать, как это работает.
jason at jw:~$ egrep -A 10 "^20130612:" /usr/ports/UPDATING
20130612:
AFFECTS: users of lang/perl* and any port that depends on it
AUTHOR: az at FreeBSD.org

lang/perl5.12 has been upgraded from version 5.12.4 to 5.12.5
lang/perl5.14 has been upgraded from version 5.14.2 to 5.14.4
lang/perl5.16 has been upgraded from version 5.16.2 to 5.16.3

The directory structure where Perl is installed has also been modified:
"major.minor" is now used instead of "major.minor.patchlevel".

jason at jw:~$

___ The directory structure where Perl is installed has also been modified:
"major.minor" is now used instead of "major.minor.patchlevel". ___
Следовательно, данный скрипт вообще более не нужен. Потому что модули
для 5.14.1 и 5.14.2 будут лежать в каталоге 5.14. А между 5.14 и 5.16
может измениться ABI, вследствие чего пересборка обязательна (и ось
тут ни при чём, однако).


From denis at webmaster.spb.ru  Mon Jul  8 15:04:36 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 19:04:36 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <CAFG2KC+=7m6HkrTN8sbczhu2YarTU13B7FmN5znYBwfzkPG_5A@mail.gmail.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DAC9DB.9090209@webmaster.spb.ru>
 <CAFG2KC+=7m6HkrTN8sbczhu2YarTU13B7FmN5znYBwfzkPG_5A@mail.gmail.com>
Message-ID: <51DAD504.3000100@webmaster.spb.ru>

08.07.2013 18:41, Sayetsky Anton пишет:
> 8 июля 2013 г., 17:16 пользователь denis<denis at webmaster.spb.ru>  написал:
>> а больше у меня нет предположений, зачем делать такую гадость. Это как
>> дебиан, который очередным обновлением выпиливал jdk6 только потому, что он
>> стал EOL, и тысячи человек крыли матом авторов дебиана, которым вдруг
>> сломали в том числе продакшены. Тут можно долго говорить, что сами виноваты,
>> надо было сначала на деплое обновить, прогнать кучу тестов функциональности,
>> проверить все модули.. но мы не в идеальном мире живем и сделали они реально
>> по свински. И у многих, реально многих продакшен и тестовый - один и тот же,
>> ибо разделять просто нецелесообразно.
> Выбросили jdk6 в пользу jdk7?
я бы сравнил изменения jdk6 - jdk7 и perl 5.8 - 5.10. У кого-то 
работает, у кого-то ломается. Изменений там даже поменьше, чем php 5.2 - 
5.3, а тоже всего-то минорную цифру поправили. Хотя я бы уже 6 версией 
назвал 5.3

> Так perl с 5-й до 6-й версии не
> обновляли. Минорное обновление - оно просто не может всё сломать. Если
> так случилось - значит, неправильно всё написано.
Но тем не менее ломает. И не у меня одного:
08.07.2013 17:59, Anton Yuzhaninov пишет:
> Из того, что я помню - сложным был только переход 5.6 - 5.8, когда 
> сильно поменялась работа с unicode. 

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

> У нормальных людей EOL значит, что продукт более _не поддерживается_,
> и помощи в решении проблем с ним _не будет_. В качестве оффтоп-аналога
> - как думаете, куда вас пошлёт саппорт МС, если зададите им вопрос о
> Windows 98?
Ну не поддерживается, и ладно. Удаление я бы скорее сравнил с тем, что 
юзер ставит дистрибутив 95 винды в сд-ром, и тот выжигает диск, ибо EOL. 
Нужно различать "больше нет поддержки" и "хрен вы даже поставите эту 
версию".

> Стоит. Работает. Не трогают. Так зачем вам было трогать систему,
> которая работала?
потому что потребовалось добавить нгинху passenger, а он вообще сломался 
после пересборки. Казалось бы, при чем тут перл вообще? Или что, 
зафиксировать теперь версию портов с запретом какого-либо обновления, и 
загрузить всё что может потребоваться в distfiles? Это тоже не вариант.

> Опять же, между 5.10 и 5.1{2,4,6} разве такая непреодолимая разница?
уже нет. Но кто даст 100% гарантию, что ничего не сломается на минорном 
обновлении?

>> И всё-таки во фре до сих пор обновить тот же perl или php даже внутри версии
>> - иногда тот еще адЪ и содомия, я уж не говорю про минорное обновление, за
>> таким все знакомые юзеры с вдс-ками ко мне бегут..
> Вы просто не умеете её готовить. (с)
> У меня почему-то таких проблем не возникает. Нужно всего лишь читать
> UPDATING перед любым запуском make (ручным или автоматическим) в
> пределах ${PORTSDIR}. А если есть много машин, то ставим
> tinderbox/poudriere (лучше последний + pkg), делаем свою репу и ставим
> оттуда.
спасибо еще за полезные утилиты.

>   Ну, или юзаем pkg_add (в котором версии пакетов, кстати, тоже
> заморожены, ибо собирается это один раз - во время выхода очередного
> релиза).
иногда так и приходится делать, но опять же - ставим мелкую либу под 
пхп.. а она за собой тянет перл 5.14 например. Косячок-с.

> Более того, perl5.10 удалили ещё в марте. Т.е. вам не хватило трёх
> месяцев для того, чтобы поправить несколько десятков строк, если уж
> скрипты всё-таки не запускаются на новой версии?
а мы и не знали, старая версия работала без проблем.

И еще. Вот не нужны нам плюшки свежих версий, есть софт которому нужны 
исключительно security bugfix-ы. И что делать? В этом плане тоже лучше 
брать саппорт тех же redhat, у них срок поддержки до 12 лет, если не 
ошибаюсь. То есть еще более 5 лет они будут закрывать баги в том же 5.8. 
Разумеется платно, но некоторых и это устраивает.
Ну и зафиксировали бы ту же 5.8 как увеличенный срок жизни, в 10+ лет, 
закрывая только крит баги -- головной боли почти нет, изменений - пара 
патчей в год. И какую-нибудь 5.18 как след версию. Чтобы можно было быть 
уверенным, что минимум 10 лет оно будет просто работать, и не дыряво. А 
так эту работу на себя берут хостеры...
это особенно для пхп актуально, который дыряв, но их сильные изменения 
апи вынуждают держать 5.1, 5.2, 5.3 и скоро еще 5.4 добавится.


From denis at webmaster.spb.ru  Mon Jul  8 15:16:03 2013
From: denis at webmaster.spb.ru (denis)
Date: Mon, 08 Jul 2013 19:16:03 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <CAFG2KC+wu8V=fsRhncdRa0tgov7NFzyYGnMLgwMUjV3o3BrHvA@mail.gmail.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DACC91.1080508@webmaster.spb.ru>
 <CAFG2KC+wu8V=fsRhncdRa0tgov7NFzyYGnMLgwMUjV3o3BrHvA@mail.gmail.com>
Message-ID: <51DAD7B3.4010409@webmaster.spb.ru>

08.07.2013 18:46, Sayetsky Anton пишет:
> ___ The directory structure where Perl is installed has also been 
> modified:
> "major.minor" is now used instead of "major.minor.patchlevel". ___
> Следовательно, данный скрипт вообще более не нужен. Потому что модули
> для 5.14.1 и 5.14.2 будут лежать в каталоге 5.14.
тут понятно, согласен, давно пора.

>   А между 5.14 и 5.16
> может измениться ABI, вследствие чего пересборка обязательна
_может_ измениться. То есть все-равно нужен скрипт для проверки, может и 
так можно перенести, а что действительно надо пересобирать - пересобрать.

> (и ось тут ни при чём, однако).
Не согласен. Например, как объяснить новичку обновление перла на 
минорную версию одной командой? Без установки доп пакетов. Вот что-то 
такое и должен делать perl-after-upgrade.
Ну и например обновил юзер перл руками, и теперь через portupgrade уже 
не обновить всё зависимое. Что-то типа
pkg info -qa |egrep "^p5-"|xargs portupgrade -r
потому что после ручного make install в новом месте portmaster выдает на 
обновление только то, что я уже руками пересобрал.
# portmaster -r perl
...
===>>> The following actions will be taken if you choose to proceed:
         Re-install perl-5.16.3
         Re-install nginx-1.4.1_1,1

===>>> Proceed? y/n [y]

И пусть теперь такую конструкцию напишет новичок. Или что, для 
обслуживания фри нужно искать гуру, ибо оно не юзер-френдли?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130708/e3c21d9c/attachment.html>

From nefer05 at gmail.com  Mon Jul  8 18:24:06 2013
From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=)
Date: Mon, 8 Jul 2013 22:24:06 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DAD7B3.4010409@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DACC91.1080508@webmaster.spb.ru>
 <CAFG2KC+wu8V=fsRhncdRa0tgov7NFzyYGnMLgwMUjV3o3BrHvA@mail.gmail.com>
 <51DAD7B3.4010409@webmaster.spb.ru>
Message-ID: <CAE-UrwiwNEt9xsstOnTwWH0VsC+suB31YFfo3_NNXSt6bsKoBA@mail.gmail.com>

Вы на внутриполостную операцию гуру будете искать, или будете просить
соседа, который в пятом классе учебник анатомии под одеялом рассматривал?
Потом еще о продакшене рассуждают :(


2013/7/8 denis <denis at webmaster.spb.ru>

> **
> 08.07.2013 18:46, Sayetsky Anton пишет:
>
> ___ The directory structure where Perl is installed has also been modified:
>
> "major.minor" is now used instead of "major.minor.patchlevel". ___
> Следовательно, данный скрипт вообще более не нужен. Потому что модули
> для 5.14.1 и 5.14.2 будут лежать в каталоге 5.14.
>
>  тут понятно, согласен, давно пора.
>
>
>   А между 5.14 и 5.16
> может измениться ABI, вследствие чего пересборка обязательна
>
>  _может_ измениться. То есть все-равно нужен скрипт для проверки, может и
> так можно перенести, а что действительно надо пересобирать - пересобрать.
>
>
>  (и ось тут ни при чём, однако).
>
>  Не согласен. Например, как объяснить новичку обновление перла на минорную
> версию одной командой? Без установки доп пакетов. Вот что-то такое и должен
> делать perl-after-upgrade.
> Ну и например обновил юзер перл руками, и теперь через portupgrade уже не
> обновить всё зависимое. Что-то типа
> pkg info -qa |egrep "^p5-"|xargs portupgrade -r
> потому что после ручного make install в новом месте portmaster выдает на
> обновление только то, что я уже руками пересобрал.
> # portmaster -r perl
> ...
> ===>>> The following actions will be taken if you choose to proceed:
>         Re-install perl-5.16.3
>         Re-install nginx-1.4.1_1,1
>
> ===>>> Proceed? y/n [y]
>
> И пусть теперь такую конструкцию напишет новичок. Или что, для
> обслуживания фри нужно искать гуру, ибо оно не юзер-френдли?
>
> _______________________________________________
> 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/20130708/c7d4e934/attachment-0001.html>

From nginx-forum at nginx.us  Mon Jul  8 19:16:06 2013
From: nginx-forum at nginx.us (shurik_saint)
Date: Mon, 08 Jul 2013 15:16:06 -0400
Subject: =?UTF-8?Q?Re=3A_HttpAccessKeyModule_=D0=B8=D0=BB=D0=B8_HttpSecureLinkModul?=
 =?UTF-8?Q?e?=
In-Reply-To: <CAJSpzyRGfoTWjbZ=BaqPu3p=mzaAJ57RdEOcOgtS+n5bYZfDug@mail.gmail.com>
References: <CAJSpzyRGfoTWjbZ=BaqPu3p=mzaAJ57RdEOcOgtS+n5bYZfDug@mail.gmail.com>
Message-ID: <33c64107cd5d6b9846b682a42ac533c9.NginxMailingListRussian@forum.nginx.org>

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

В любом случае спасибо.

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


From anuryadov at gmail.com  Tue Jul  9 08:10:14 2013
From: anuryadov at gmail.com (=?KOI8-R?B?4c7E0sXKIPXS0cTP1w==?=)
Date: Tue, 9 Jul 2013 12:10:14 +0400
Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIG1heF9mYWlscyDQuCDRg9C/0LDQstGI0LjQtSDRgdC10YA=?=
 =?UTF-8?B?0LLQtdGA0LA=?=
In-Reply-To: <20130617144611.GF72282@mdounin.ru>
References: <CAJSpzyQHGpy9ZAxRj9z4rkiW5QqemQSLHqNpJF6CMh8Vf1L8MA@mail.gmail.com>
 <20130617135359.GD72282@mdounin.ru>
 <CAJSpzyTNSpQuUocJ+dm=qr538AVCtvFXPZTfcfJYVQZHMPP__A@mail.gmail.com>
 <CAJSpzyTkcak3P8ekRZVpEAjaHqfayJw8NEdZhnnRkNGBwCjyng@mail.gmail.com>
 <20130617141944.GE72282@mdounin.ru>
 <CAJSpzyQ8awAtt7m-9DQsy=uiah-8zcOm8MzMspsg_68ORySqDw@mail.gmail.com>
 <20130617144611.GF72282@mdounin.ru>
Message-ID: <CAJSpzySFjBO2NLjD+uBj=BzW7EhsCuNCgmU7pXNn0i9b9c6ZwA@mail.gmail.com>

Сделал так, как советовали: после старта бэкенд говорит фронтенду, что надо
перечитать конфигурацию. Но в логах почему-то даже после перечитывания
появляются ошибки: (110: Connection timed out) while connecting to
upstream, причем указан ip бэкенда не из списка текущих - видимо, старый
остался. Причем, такое повторяется через несколько минут после
перечитывания конфигурации. Хотя, эти ошибки явно одиночные - проявляются
только для нескольких клиентов, у остальных все нормально работает. Это
результаты какого-то кэширования? Потому что запрос от клиента на nginx
пришел явно после того, как конфигурация уже была перечитана.


17 июня 2013 г., 18:46 пользователь Maxim Dounin <mdounin at mdounin.ru>написал:

> Hello!
>
> On Mon, Jun 17, 2013 at 06:32:29PM +0400, Андрей Урядов wrote:
>
> > Понятно, спасибо.
> > Видимо, самым дешевым вариантом будет прописывание в cron перечитывания
> > конфигурации каждый час + ручное перечитывание каждый раз после сбоя.
> > Тогда, даже если забыть руками перечитать конфигурацию, через час она
> > перечитается. Я так понимаю, это дешевая операция?
>
> Это зависит от структуры нагрузки.  Если есть длинные запросы - то
> старые рабочие процессы могут долго не завершаться.  В общем
> случае - я бы скорее смотрел в сторону init-скриптов на бекендах,
> уведомляющих фронтенд, что ему надо перечитать конфигурацию.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130709/24946383/attachment.html>

From mdounin at mdounin.ru  Tue Jul  9 11:58:08 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 9 Jul 2013 15:58:08 +0400
Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIG1heF9mYWlscyDQuCDRg9C/0LDQstGI0LjQtSDRgdC10YA=?=
 =?UTF-8?B?0LLQtdGA0LA=?=
In-Reply-To: <CAJSpzySFjBO2NLjD+uBj=BzW7EhsCuNCgmU7pXNn0i9b9c6ZwA@mail.gmail.com>
References: <CAJSpzyQHGpy9ZAxRj9z4rkiW5QqemQSLHqNpJF6CMh8Vf1L8MA@mail.gmail.com>
 <20130617135359.GD72282@mdounin.ru>
 <CAJSpzyTNSpQuUocJ+dm=qr538AVCtvFXPZTfcfJYVQZHMPP__A@mail.gmail.com>
 <CAJSpzyTkcak3P8ekRZVpEAjaHqfayJw8NEdZhnnRkNGBwCjyng@mail.gmail.com>
 <20130617141944.GE72282@mdounin.ru>
 <CAJSpzyQ8awAtt7m-9DQsy=uiah-8zcOm8MzMspsg_68ORySqDw@mail.gmail.com>
 <20130617144611.GF72282@mdounin.ru>
 <CAJSpzySFjBO2NLjD+uBj=BzW7EhsCuNCgmU7pXNn0i9b9c6ZwA@mail.gmail.com>
Message-ID: <20130709115808.GI38853@mdounin.ru>

Hello!

On Tue, Jul 09, 2013 at 12:10:14PM +0400, Андрей Урядов wrote:

> Сделал так, как советовали: после старта бэкенд говорит фронтенду, что надо
> перечитать конфигурацию. Но в логах почему-то даже после перечитывания
> появляются ошибки: (110: Connection timed out) while connecting to
> upstream, причем указан ip бэкенда не из списка текущих - видимо, старый
> остался. Причем, такое повторяется через несколько минут после
> перечитывания конфигурации. Хотя, эти ошибки явно одиночные - проявляются
> только для нескольких клиентов, у остальных все нормально работает. Это
> результаты какого-то кэширования? Потому что запрос от клиента на nginx
> пришел явно после того, как конфигурация уже была перечитана.

Такое может быть, e.g., если запрос _начал_ приходить давно, и 
соответственно - в старый рабочий процесс, и делал это долго - 
e.g. от клиента принималось большое тело запроса.  Либо запрос до 
этого где-то долго обрабатывался (e.g. ходил на другой бекенд, и 
потом из-за ошибки или по X-Accel-Redirect был куда-то ещё 
отправлен).

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

Ну и $request_time, $upstream_response_time имеет смысл в логи 
добавить - чтобы не писать "явно после", а оперировать фактами.

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


From denis at webmaster.spb.ru  Tue Jul  9 15:21:44 2013
From: denis at webmaster.spb.ru (denis)
Date: Tue, 09 Jul 2013 19:21:44 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <CAE-UrwiwNEt9xsstOnTwWH0VsC+suB31YFfo3_NNXSt6bsKoBA@mail.gmail.com>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DACC91.1080508@webmaster.spb.ru>
 <CAFG2KC+wu8V=fsRhncdRa0tgov7NFzyYGnMLgwMUjV3o3BrHvA@mail.gmail.com>
 <51DAD7B3.4010409@webmaster.spb.ru>
 <CAE-UrwiwNEt9xsstOnTwWH0VsC+suB31YFfo3_NNXSt6bsKoBA@mail.gmail.com>
Message-ID: <51DC2A88.1010605@webmaster.spb.ru>

08.07.2013 22:24, Роман Москвитин пишет:
> Вы на внутриполостную операцию гуру будете искать, или будете просить 
> соседа, который в пятом классе учебник анатомии под одеялом 
> рассматривал? Потом еще о продакшене рассуждают :(
>
Ну если такая простая вещь, как обновление системного языка, требует 
гуру - популярной оно точно не станет прежде всего в силу своей 
сложности и неадекватности. Опять же, в лине - делаем yum update perl\* 
- и у нас всё само обновилось, без неожиданных /libexec/ld-elf.so.1: 
Shared object "libpcre.so.1" not found, required by ....

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

Как-то мы действительно в оффтопик уползли


From nginx-ru at sadok.spb.ru  Tue Jul  9 20:01:28 2013
From: nginx-ru at sadok.spb.ru (Dmitry Ivanov)
Date: Wed, 10 Jul 2013 00:01:28 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <51DC2A88.1010605@webmaster.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DACC91.1080508@webmaster.spb.ru>
 <CAFG2KC+wu8V=fsRhncdRa0tgov7NFzyYGnMLgwMUjV3o3BrHvA@mail.gmail.com>
 <51DAD7B3.4010409@webmaster.spb.ru>
 <CAE-UrwiwNEt9xsstOnTwWH0VsC+suB31YFfo3_NNXSt6bsKoBA@mail.gmail.com>
 <51DC2A88.1010605@webmaster.spb.ru>
Message-ID: <7110177736.20130710000128@sadok.spb.ru>

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

Вы писали 9 июля 2013 г., 19:21:44:

> А вообще все недостатки фри хорошо обсуждали в ЖЖ слоника-в-домене.

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

> Как-то мы действительно в оффтопик уползли

Угу. Заканчиваем.


-- 
С уважением,
 Dmitry                          mailto:nginx-ru at sadok.spb.ru


From denis at webmaster.spb.ru  Tue Jul  9 20:13:41 2013
From: denis at webmaster.spb.ru (denis)
Date: Wed, 10 Jul 2013 00:13:41 +0400
Subject: freebsd - Can't locate nginx.pm
In-Reply-To: <7110177736.20130710000128@sadok.spb.ru>
References: <51DAB6B7.1000503@webmaster.spb.ru>
 <CAPL6oRVLmtA=Z1BrBtNKZxf0vCqNhbnfG_8oHXxqaJAz4byMyw@mail.gmail.com>
 <51DAB81C.10508@webmaster.spb.ru>
 <CAFG2KCLp+KBMCvNPJ3xoaWrE15e5OrBU-hCFQ90_zJHhxnFnKA@mail.gmail.com>
 <51DAC003.3010705@webmaster.spb.ru>
 <CAFG2KCK-G3eKShQ5SwJm=9+5Ht1J5T5+Y5gB5U4Y-Q6ezNGSPQ@mail.gmail.com>
 <51DACC91.1080508@webmaster.spb.ru>
 <CAFG2KC+wu8V=fsRhncdRa0tgov7NFzyYGnMLgwMUjV3o3BrHvA@mail.gmail.com>
 <51DAD7B3.4010409@webmaster.spb.ru>
 <CAE-UrwiwNEt9xsstOnTwWH0VsC+suB31YFfo3_NNXSt6bsKoBA@mail.gmail.com>
 <51DC2A88.1010605@webmaster.spb.ru> <7110177736.20130710000128@sadok.spb.ru>
Message-ID: <51DC6EF5.5050804@webmaster.spb.ru>

10.07.2013 0:01, Dmitry Ivanov пишет:
>> А вообще все недостатки фри хорошо обсуждали в ЖЖ слоника-в-домене.
> Где этого слоника, помнится, разложили на раз-два за криворукость.
Да, и за дело. Тем не менее, там были _не_его_ посты с реальными 
проблемами, а он просто придурок какой-то.

> Угу. Заканчиваем.
ага.


From nginx-forum at nginx.us  Sun Jul 14 14:53:03 2013
From: nginx-forum at nginx.us (commeta)
Date: Sun, 14 Jul 2013 10:53:03 -0400
Subject: =?UTF-8?Q?proxy_cache_bypass_=D0=B8_303_see_other?=
Message-ID: <4688ec1d97fc5a561fc04a5e246e4fb4.NginxMailingListRussian@forum.nginx.org>

Здравствуйте,
Подскажите как сделать конструкцию для отключения кэширования страницы
открывающейся по 303 see other?
на подобии:

if ( $http_responce = 303 ) { 
set $do_not_cache 1; 
} 
proxy_cache_bypass $do_not_cache;


Предистория:

nginx version: nginx/1.0.15
CentOs 6 
Linux 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux


nginx установлен в качестве прокси для apache2 + отдача статики.
Возникла необходимость кешировать один из сайтов, в результате родился такой
конфиг:
/etc/nginx/nginx.conf      

user apache;
worker_processes  4;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {worker_connections  1024;}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request"
'
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    keepalive_timeout  85;
    proxy_cache_path /var/cache/nginx levels= keys_zone=wholepage:500m;

    include /etc/nginx/conf.d/*.conf;

        include /usr/local/ispmgr/etc/nginx.domain;
        client_max_body_size 64M;
        log_format isp '$bytes_sent $request_length';

	server {
		server_name test3.mysite.ru www.test3.mysite.ru;
		listen 33.133.9.32;
		set $root_path /var/www/mysite.ru/data/www/test3.mysite.ru;
		location ~*
^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
			root $root_path;
			access_log /var/www/nginx-logs/mysite.ru isp;
			access_log /var/www/httpd-logs/test3.mysite.ru.access.log ;
			error_page 404 = @fallback;
		}
		location / {
			if ($request_method = POST) { set $do_not_cache 1; } 
			if ($cookie_session) { set $do_not_cache 1; } 
			proxy_cache_bypass $do_not_cache;
			
			proxy_pass http://33.133.9.32:81;
			proxy_redirect http://33.133.9.32:81/ /;
			
			proxy_hide_header "Set-Cookie";
			proxy_ignore_headers "Cache-Control" "Expires" "Set-Cookie";
			
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;
			proxy_set_header X-Real-IP $remote_addr;

			proxy_cache wholepage;
			proxy_cache_valid 200 301 302 304 5m;
			proxy_cache_key
"$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri";
		}
                                                      		
		location ~* ^/(webstat|awstats|webmail|myadmin|pgadmin)/ {
			proxy_pass http://33.133.9.32:81;
			proxy_redirect http://33.133.9.32:81/ /;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;
			proxy_set_header X-Real-IP $remote_addr;
		}
		location @fallback {
			proxy_pass http://33.133.9.32:81;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;
			proxy_set_header X-Real-IP $remote_addr;
		}
		location ^~ /webstat/ {
			auth_basic "Restricted area";
			auth_basic_user_file /var/www/mysite.ru/data/etc/3677707.passwd;
			try_files $uri @fallback;
		}
		location ~*
^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|ico)$
{
			root $root_path;
			access_log /var/www/nginx-logs/mysite.ru isp;
			access_log /var/www/httpd-logs/test3.mysite.ru.access.log ;
			error_page 404 = @fallback;
		}
		include /usr/local/ispmgr/etc/nginx.inc;
	}
	server_names_hash_max_size 8192;
}

на сайте есть корзина, при нажатии на ссылку открывается страница с кодом
303 see other, мне нужно чтобы страница которая по 303 вернулась не
кэшаровалась, как это сдлеать?

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


From nginx-forum at nginx.us  Sun Jul 14 19:27:24 2013
From: nginx-forum at nginx.us (isamitakata)
Date: Sun, 14 Jul 2013 15:27:24 -0400
Subject: =?UTF-8?B?TG9jYXRpb24g0LTQstCwINC/0LDRgNCw0LzQtdGC0YDQsA==?=
Message-ID: <b02d39524a174e2278f05407df625724.NginxMailingListRussian@forum.nginx.org>

Приветствую всех! Есть проблемка, с nginx познакомился недавно, нужна
помощь.
Есть урл вида http://example.com/d/STRING
Правило для него такое

if ($args ~ "^linkd=(.+)$"){
set $rule_0 1$rule_0;
set $bref_1 $1;
}
if ($rule_0 = "1"){
rewrite ^/d.php$ /d/$bref_1? permanent;
}
rewrite ^/d/(.*) /d.php?linkd=$1 last;


Помогите пожалуйста оформить его так чтобы страница принимала еще и второй
параметр.
И чтобы было  http://example.com/d/STRING/STRING2

Заранее благодарю!

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


From nginx-forum at nginx.us  Mon Jul 15 03:26:44 2013
From: nginx-forum at nginx.us (commeta)
Date: Sun, 14 Jul 2013 23:26:44 -0400
Subject: =?UTF-8?B?bmd4IGh0dHAgcGVybCBtb2R1bGUg0LrQsNC60LjQvCDQvNC10YLQvtC00L7QvCA=?=
 =?UTF-8?B?0L7QsdGA0LDQsdC+0YLQsNGC0Ywg0YLQtdC70L4g0L7RgtCy0LXRgtCwINCx?=
 =?UTF-8?B?0Y3QutGN0L3QtNCw?=
Message-ID: <2595780e8e7ecb6aac89c55ae70019cb.NginxMailingListRussian@forum.nginx.org>

Подскажите, существуют ли методы чтобы получить в переменную содержимое
страницы от бэкэнда? при помощи модуля ngx_http_perl_module?

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


From mdounin at mdounin.ru  Mon Jul 15 10:50:04 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 15 Jul 2013 14:50:04 +0400
Subject: =?UTF-8?Q?Re=3A_proxy_cache_bypass_=D0=B8_303_see_other?=
In-Reply-To: <4688ec1d97fc5a561fc04a5e246e4fb4.NginxMailingListRussian@forum.nginx.org>
References: <4688ec1d97fc5a561fc04a5e246e4fb4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130715105004.GS66479@mdounin.ru>

Hello!

On Sun, Jul 14, 2013 at 10:53:03AM -0400, commeta wrote:

> Здравствуйте,
> Подскажите как сделать конструкцию для отключения кэширования страницы
> открывающейся по 303 see other?

[...]

> 			proxy_hide_header "Set-Cookie";
> 			proxy_ignore_headers "Cache-Control" "Expires" "Set-Cookie";

[...]

> на сайте есть корзина, при нажатии на ссылку открывается страница с кодом
> 303 see other, мне нужно чтобы страница которая по 303 вернулась не
> кэшаровалась, как это сдлеать?

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

По существу вопроса:

Узнать, по какой причине бразуер пришёл с конкретным запросом - 
нельзя.  Так что вычленяйте корзину по другим признакам и 
отключайте кеширование по ним.  Обычно это либо URL (и 
соответственно отдельный location), либо аргументы запроса.

Ну либо уже уберите proxy_ignore_headers, и дайте бекенду 
управлять кешированием самому.

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


From mdounin at mdounin.ru  Mon Jul 15 10:55:19 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 15 Jul 2013 14:55:19 +0400
Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LLQsCDQv9Cw0YDQsNC80LXRgtGA0LA=?=
In-Reply-To: <b02d39524a174e2278f05407df625724.NginxMailingListRussian@forum.nginx.org>
References: <b02d39524a174e2278f05407df625724.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130715105519.GT66479@mdounin.ru>

Hello!

On Sun, Jul 14, 2013 at 03:27:24PM -0400, isamitakata wrote:

> Приветствую всех! Есть проблемка, с nginx познакомился недавно, нужна
> помощь.
> Есть урл вида http://example.com/d/STRING
> Правило для него такое
> 
> if ($args ~ "^linkd=(.+)$"){
> set $rule_0 1$rule_0;
> set $bref_1 $1;
> }
> if ($rule_0 = "1"){
> rewrite ^/d.php$ /d/$bref_1? permanent;
> }
> rewrite ^/d/(.*) /d.php?linkd=$1 last;
> 
> 
> Помогите пожалуйста оформить его так чтобы страница принимала еще и второй
> параметр.
> И чтобы было  http://example.com/d/STRING/STRING2

Лучше всего сделать как-то так:

    location /d/ {
        fastcgi_pass ...;
        fastcgi_param SCRIPT_FILENAME /path/to/d.php;
        include fastcgi_param;
    }

И разбирать всё дальше в php.

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


From mdounin at mdounin.ru  Mon Jul 15 10:56:20 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 15 Jul 2013 14:56:20 +0400
Subject: =?UTF-8?B?UmU6IG5neCBodHRwIHBlcmwgbW9kdWxlINC60LDQutC40Lwg0LzQtdGC0L7QtNC+?=
 =?UTF-8?B?0Lwg0L7QsdGA0LDQsdC+0YLQsNGC0Ywg0YLQtdC70L4g0L7RgtCy0LXRgtCw?=
 =?UTF-8?B?INCx0Y3QutGN0L3QtNCw?=
In-Reply-To: <2595780e8e7ecb6aac89c55ae70019cb.NginxMailingListRussian@forum.nginx.org>
References: <2595780e8e7ecb6aac89c55ae70019cb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130715105620.GU66479@mdounin.ru>

Hello!

On Sun, Jul 14, 2013 at 11:26:44PM -0400, commeta wrote:

> Подскажите, существуют ли методы чтобы получить в переменную содержимое
> страницы от бэкэнда? при помощи модуля ngx_http_perl_module?

Нет.

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


From bogdar at gmail.com  Mon Jul 15 11:41:42 2013
From: bogdar at gmail.com (Bogdan)
Date: Mon, 15 Jul 2013 14:41:42 +0300
Subject: =?UTF-8?B?0JTQvtGB0YLQsNGC0L7Rh9C90L4g0LvQuCDQutCw0YfQtdGB0YLQstC10L3QvdC1?=
 =?UTF-8?B?0L0gbmdpbngtYXV0aC1sZGFwPw==?=
Message-ID: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>

Добрый день.

Есть такой вот сторонний модуль: https://github.com/kvspb/nginx-auth-ldap

Насколько хорошо он работает, в т.ч. в случае регулярных перебоев связи со
ldap-сервером?
В настоящий момент у меня AD-аутентификация сделана средствами apache2,
хочу его заменить на nginx.


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

From v.v.biriukov at gmail.com  Mon Jul 15 12:02:30 2013
From: v.v.biriukov at gmail.com (Viacheslav Biriukov)
Date: Mon, 15 Jul 2013 16:02:30 +0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0LDRgtC+0YfQvdC+INC70Lgg0LrQsNGH0LXRgdGC0LLQtdC9?=
 =?UTF-8?B?0L3QtdC9IG5naW54LWF1dGgtbGRhcD8=?=
In-Reply-To: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
Message-ID: <CAPKsgQzRDz2eWChXh=WVryPC1Rj0dykk2v4cDQvLWx51Lq1UXg@mail.gmail.com>

Присоединяюсь к вопросу.


15 июля 2013 г., 15:41 пользователь Bogdan <bogdar at gmail.com> написал:

> Добрый день.
>
> Есть такой вот сторонний модуль: https://github.com/kvspb/nginx-auth-ldap
>
> Насколько хорошо он работает, в т.ч. в случае регулярных перебоев связи со
> ldap-сервером?
> В настоящий момент у меня AD-аутентификация сделана средствами apache2,
> хочу его заменить на nginx.
>
>
> --
> WBR,  Bogdan B. Rudas
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Viacheslav Biriukov
BR
http://biriukov.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130715/acd9e887/attachment.html>

From mdounin at mdounin.ru  Mon Jul 15 12:10:29 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 15 Jul 2013 16:10:29 +0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0LDRgtC+0YfQvdC+INC70Lgg0LrQsNGH0LXRgdGC0LLQtdC9?=
 =?UTF-8?B?0L3QtdC9IG5naW54LWF1dGgtbGRhcD8=?=
In-Reply-To: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
Message-ID: <20130715121029.GZ66479@mdounin.ru>

Hello!

On Mon, Jul 15, 2013 at 02:41:42PM +0300, Bogdan wrote:

> Добрый день.
> 
> Есть такой вот сторонний модуль: https://github.com/kvspb/nginx-auth-ldap
> 
> Насколько хорошо он работает, в т.ч. в случае регулярных перебоев связи со
> ldap-сервером?
> В настоящий момент у меня AD-аутентификация сделана средствами apache2,
> хочу его заменить на nginx.

Он блокируется на операциях в ldap'е, для серьёзного использования 
- негоден.

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


From kav at karagodov.name  Mon Jul 15 12:15:45 2013
From: kav at karagodov.name (Alexey V. Karagodov)
Date: Mon, 15 Jul 2013 16:15:45 +0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0LDRgtC+0YfQvdC+INC70Lgg0LrQsNGH0LXRgdGC0LLQtdC9?=
 =?UTF-8?B?0L3QtdC9IG5naW54LWF1dGgtbGRhcD8=?=
In-Reply-To: <20130715121029.GZ66479@mdounin.ru>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
 <20130715121029.GZ66479@mdounin.ru>
Message-ID: <EF99C1A0-A172-421A-872B-1A5AF9E20220@karagodov.name>

а http://web.iti.upv.es/~sto/nginx/ ? 
nginx-pam-auth 

On 15.07.2013, at 16:10, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Mon, Jul 15, 2013 at 02:41:42PM +0300, Bogdan wrote:
> 
>> Добрый день.
>> 
>> Есть такой вот сторонний модуль: https://github.com/kvspb/nginx-auth-ldap
>> 
>> Насколько хорошо он работает, в т.ч. в случае регулярных перебоев связи со
>> ldap-сервером?
>> В настоящий момент у меня AD-аутентификация сделана средствами apache2,
>> хочу его заменить на nginx.
> 
> Он блокируется на операциях в ldap'е, для серьёзного использования 
> - негоден.
> 
> -- 
> Maxim Dounin
> http://nginx.org/en/donation.html
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Mon Jul 15 13:29:26 2013
From: nginx-forum at nginx.us (spry)
Date: Mon, 15 Jul 2013 09:29:26 -0400
Subject: perl_set location
Message-ID: <17b7b4c1f1e5fda5ee5f64f1e45f9e8a.NginxMailingListRussian@forum.nginx.org>

Добрый день уважаемые!
У меня связка nginx проксирующий и отдающий статику, и backend apache2,
крутящий php
у меня уехали файлы из папки uploads/post-1234-1242743722_thumb.jpg в папку
соотвествую времени timestamp ->
uploads/2009/05/19/post-1234-1242743722_thumb.jpg
Как мне лучше организовать доступ к этим файлам? пересобрать на дебиане
nginx с поддержкой perl и сгенерировать URL для try_files
или повесить скрипт на apache2 и слать всех туда, вопрос ресурсо-затратности
актуален, обращений к ним довольно много

файлы переехали т.к. там файлов было уже более полумиллиона

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


From nginx-forum at nginx.us  Mon Jul 15 18:20:13 2013
From: nginx-forum at nginx.us (renaldiko)
Date: Mon, 15 Jul 2013 14:20:13 -0400
Subject: {title}
Message-ID: <5445f7a576e8566c85a32ebba8c3a373.NginxMailingListRussian@forum.nginx.org>

{content}

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


From postmaster at softsearch.ru  Mon Jul 15 20:44:48 2013
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Tue, 16 Jul 2013 00:44:48 +0400
Subject: perl_set location
In-Reply-To: <17b7b4c1f1e5fda5ee5f64f1e45f9e8a.NginxMailingListRussian@forum.nginx.org>
References: <17b7b4c1f1e5fda5ee5f64f1e45f9e8a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1361130708.20130716004448@softsearch.ru>

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

> У меня связка nginx проксирующий и отдающий статику, и backend apache2,
> крутящий php
> у меня уехали файлы из папки
> uploads/post-1234-1242743722_thumb.jpg в папку
> соотвествую времени timestamp ->
> uploads/2009/05/19/post-1234-1242743722_thumb.jpg
> Как мне лучше организовать доступ к этим файлам? пересобрать на дебиане
> nginx с поддержкой perl и сгенерировать URL для try_files
> или повесить скрипт на apache2 и слать всех туда, вопрос ресурсо-затратности
> актуален, обращений к ним довольно много

> файлы переехали т.к. там файлов было уже более полумиллиона

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

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


From nginx-forum at nginx.us  Tue Jul 16 02:24:31 2013
From: nginx-forum at nginx.us (PbIXTOP)
Date: Mon, 15 Jul 2013 22:24:31 -0400
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzRiyDRgSDRgdC+0LfQtNCw0L3QuNC10LwgcHJveHktQ0RO?=
Message-ID: <6467acc44b137640d294af06e68af39c.NginxMailingListRussian@forum.nginx.org>

Столкнулся с проблемой.
Имеется программа, которая обновляется используя технологию BITS от
Microsoft.
Поскольку обновляния попадаются большие, решили использовать nginx для
экономии трафика.
Версия nginx, которую возможно поставить на промежуточную машину FreeBSD
8.1, к сожелению не нова:

nginx version: nginx/0.7.67
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx-error.log --user=www --group=www
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-log-path=/var/log/nginx-access.log --with-http_stub_status_module
--with-pcre

Конфигурация достаточно стандартна:

worker_processes  8;
events { worker_connections  1024;}
http {
	include	mime.types;
	default_type	application/octet-stream;
	log_format	main	'$remote_addr - $remote_user [$time_local] "$host"
"$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"
"$http_x_forwarded_for"';
	access_log	/var/log/nginx-access.log	main;
	limit_zone softupdate	$request_uri	10m;
	sendfile	on;
	keepalive_timeout	65;
	server {
		listen 80;
		server_name proxy.cdn;
		default_type  application/octet-stream;
		limit_conn activity_threshold	1024;
		proxy_cache_valid	any	10m;
		proxy_cache_key	$uri$is_args$args;
		location / {
			if ($request_method !~ GET|HEAD) {return 405;}
			open_file_cache	max=1000;
			expires 10d;
			root /var/cache/cdn;
			try_files $uri @softupdate_it;
		}
		location @ms_au_download_it {
			open_file_cache max=1000;
			expires 3M;
			root /var/cache/cdn;
			proxy_set_header Range "";
			proxy_buffering on;
			proxy_ignore_client_abort on;
			limit_conn softupdate 1;
			proxy_store  on;
			proxy_set_header Host "parent.cdn";
    			proxy_set_header If-None-Match "";
    			proxy_set_header If-Modified-Since "";
    			proxy_pass http://127.0.0.1:3128;
		}
	}
}

Как видно при попадании запроса, если файла нет, запрос отправляется дальше
(стоит squid для проверки коректности работы).
Вроде бы все хорошо и настроенно корректо. Но как показывает Squid nginx
вместо одного потока пытается сразу соединяться как просит клиент - 4-10
потоков.
Поэтому строчки 
proxy_set_header Range "";
limit_conn softupdate 1;
были написаны чтоб избежать проблем - 206, при которой не работает
proxy_store, и множественных соеденинений. Но она как была так и осталась.
Пока маленький файл на трафике не так заметно. Но когда пытается скачаться
большой файл. эти несколько потоков убивают весь канал.

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


From vbart at nginx.com  Tue Jul 16 08:31:08 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Tue, 16 Jul 2013 12:31:08 +0400
Subject: =?UTF-8?B?UmU6ICDQlNC+0YHRgtCw0YLQvtGH0L3QviDQu9C4INC60LDRh9C10YHRgtCy0LU=?=
 =?UTF-8?B?0L3QvdC10L0gbmdpbngtYXV0aC1sZGFwPw==?=
In-Reply-To: <EF99C1A0-A172-421A-872B-1A5AF9E20220@karagodov.name>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
 <20130715121029.GZ66479@mdounin.ru>
 <EF99C1A0-A172-421A-872B-1A5AF9E20220@karagodov.name>
Message-ID: <201307161231.09017.vbart@nginx.com>

On Monday 15 July 2013 16:15:45 Alexey V. Karagodov wrote:
> а http://web.iti.upv.es/~sto/nginx/ ?
> nginx-pam-auth
> 

Аналогично. Та же беда, использует блокирующие вызовы PAM-а.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From kav at karagodov.name  Tue Jul 16 08:41:55 2013
From: kav at karagodov.name (Alexey V. Karagodov)
Date: Tue, 16 Jul 2013 12:41:55 +0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0LDRgtC+0YfQvdC+INC70Lgg0LrQsNGH0LXRgdGC0LLQtdC9?=
 =?UTF-8?B?0L3QtdC9IG5naW54LWF1dGgtbGRhcD8=?=
In-Reply-To: <201307161231.09017.vbart@nginx.com>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
 <20130715121029.GZ66479@mdounin.ru>
 <EF99C1A0-A172-421A-872B-1A5AF9E20220@karagodov.name>
 <201307161231.09017.vbart@nginx.com>
Message-ID: <71159155-EBFE-4DD3-A7A6-3EAB22B65CE1@karagodov.name>

а если как вариант - куча вокеров? ну, действительно куча 
и проксировать (или что-то ещё) все (все целевые) запросы не на апач и пр., а на эту кучу вокеров ? 


On 16.07.2013, at 12:31, Валентин Бартенев <vbart at nginx.com> wrote:

> On Monday 15 July 2013 16:15:45 Alexey V. Karagodov wrote:
>> а http://web.iti.upv.es/~sto/nginx/ ?
>> nginx-pam-auth
>> 
> 
> Аналогично. Та же беда, использует блокирующие вызовы PAM-а.
> 
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From onokonem at gmail.com  Tue Jul 16 08:46:08 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Tue, 16 Jul 2013 12:46:08 +0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0LDRgtC+0YfQvdC+INC70Lgg0LrQsNGH0LXRgdGC0LLQtdC9?=
 =?UTF-8?B?0L3QtdC9IG5naW54LWF1dGgtbGRhcD8=?=
In-Reply-To: <71159155-EBFE-4DD3-A7A6-3EAB22B65CE1@karagodov.name>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
 <20130715121029.GZ66479@mdounin.ru>
 <EF99C1A0-A172-421A-872B-1A5AF9E20220@karagodov.name>
 <201307161231.09017.vbart@nginx.com>
 <71159155-EBFE-4DD3-A7A6-3EAB22B65CE1@karagodov.name>
Message-ID: <CAKaHDOHOX1rwq4O9AhTd6zv4mn7uguZN5ksf8zZFW+zg_pwfDw@mail.gmail.com>

> а если как вариант - куча вокеров? ну, действительно куча
> и проксировать (или что-то ещё) все (все целевые) запросы не на апач и пр., а на эту кучу вокеров ?
ну и получится апач, только хуже.

From kav at karagodov.name  Tue Jul 16 08:53:48 2013
From: kav at karagodov.name (Alexey V. Karagodov)
Date: Tue, 16 Jul 2013 12:53:48 +0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0LDRgtC+0YfQvdC+INC70Lgg0LrQsNGH0LXRgdGC0LLQtdC9?=
 =?UTF-8?B?0L3QtdC9IG5naW54LWF1dGgtbGRhcD8=?=
In-Reply-To: <CAKaHDOHOX1rwq4O9AhTd6zv4mn7uguZN5ksf8zZFW+zg_pwfDw@mail.gmail.com>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
 <20130715121029.GZ66479@mdounin.ru>
 <EF99C1A0-A172-421A-872B-1A5AF9E20220@karagodov.name>
 <201307161231.09017.vbart@nginx.com>
 <71159155-EBFE-4DD3-A7A6-3EAB22B65CE1@karagodov.name>
 <CAKaHDOHOX1rwq4O9AhTd6zv4mn7uguZN5ksf8zZFW+zg_pwfDw@mail.gmail.com>
Message-ID: <DAAB1430-FB9F-4B05-B621-8B4F0B11BDFD@karagodov.name>


On 16.07.2013, at 12:46, Daniel Podolsky <onokonem at gmail.com> wrote:

>> а если как вариант - куча вокеров? ну, действительно куча
>> и проксировать (или что-то ещё) все (все целевые) запросы не на апач и пр., а на эту кучу вокеров ?
> ну и получится апач, только хуже.
почему? 

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


From vbart at nginx.com  Tue Jul 16 09:33:27 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Tue, 16 Jul 2013 13:33:27 +0400
Subject: =?UTF-8?B?UmU6ICDQlNC+0YHRgtCw0YLQvtGH0L3QviDQu9C4INC60LDRh9C10YHRgtCy0LU=?=
 =?UTF-8?B?0L3QvdC10L0gbmdpbngtYXV0aC1sZGFwPw==?=
In-Reply-To: <DAAB1430-FB9F-4B05-B621-8B4F0B11BDFD@karagodov.name>
References: <CACz2Q8HMGsnc5uQtQMN6jix9GV1X8WsspJOrGL3FY0ruXK5HNA@mail.gmail.com>
 <CAKaHDOHOX1rwq4O9AhTd6zv4mn7uguZN5ksf8zZFW+zg_pwfDw@mail.gmail.com>
 <DAAB1430-FB9F-4B05-B621-8B4F0B11BDFD@karagodov.name>
Message-ID: <201307161333.27152.vbart@nginx.com>

On Tuesday 16 July 2013 12:53:48 Alexey V. Karagodov wrote:
> On 16.07.2013, at 12:46, Daniel Podolsky <onokonem at gmail.com> wrote:
> >> а если как вариант - куча вокеров? ну, действительно куча
> >> и проксировать (или что-то ещё) все (все целевые) запросы не на апач и
> >> пр., а на эту кучу вокеров ?
> > 
> > ну и получится апач, только хуже.
> 
> почему?
> 

Почему хуже, или почему апач?

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

В случае же, если воркер nginx-а примет сразу несколько запросов, то все они 
будут ожидать пока один из них ходит в PAM/LDAP, у них уже не будет шанса 
"перескочить" на другой, освободившийся раньше воркер.  И хотя распределение 
запросов по рабочим процессам при правильной настройке скорее всего будет 
равномерно, а воркер будет сразу блокироваться приняв только один запрос, то это 
мало чем будет отличаться от апача, у которого исчерпался лимит на процессы,
с той лишь разницей, что единственная ваша ручка - константа worker_processes.

Апач просто в силу своей природы более гибкий и настраиваемый менеджер
процессов.

В будущем мы эту проблему решим.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Tue Jul 16 09:38:54 2013
From: nginx-forum at nginx.us (pavelb)
Date: Tue, 16 Jul 2013 05:38:54 -0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0LDRgtC+0YfQvdC+INC70Lgg0LrQsNGH0LXRgdGC0LLQtdC9?=
 =?UTF-8?B?0L3QtdC9IG5naW54LWF1dGgtbGRhcD8=?=
In-Reply-To: <71159155-EBFE-4DD3-A7A6-3EAB22B65CE1@karagodov.name>
References: <71159155-EBFE-4DD3-A7A6-3EAB22B65CE1@karagodov.name>
Message-ID: <8f338582133de3abd5f777d5fcb2ba5e.NginxMailingListRussian@forum.nginx.org>

Добрый день.

Я решился доработать этот модуль чтобы он поддерживал несколько ldap
серверов, и проблема блокирования встала еще более остро. Есть ли какие-то
рекомендации или примеры, как можно реализовать этот функционал в
неблокирующем виде? Насколько я понял те колбеки которые nginx позволяет
навешивать на upstream request не подходят в этой ситуации? Или можно как-то
реализовать это дело на апстримах? Если кто-нибудь подскажет куда копать -
буду очень благодарен.

Второй вопрос который меня мучает, этот тот факт что нужно ходить ко всем
(до первого принявшего логин-пароль) ldap серверам на каждый реквест, в том
числе на различные internal redirects. Хочется кешировать каким-то образом,
но вот безопасного способа в голову не приходит. Есть идеи на этот счет?
Может быть кто-то знает есть ли такая фича у апача, и как она там
реализована?

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

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


From nginx-forum at nginx.us  Tue Jul 16 11:19:19 2013
From: nginx-forum at nginx.us (memento)
Date: Tue, 16 Jul 2013 07:19:19 -0400
Subject: =?UTF-8?B?0J3QsNGB0YLRgNC+0LnQutCwIG5naW54?=
Message-ID: <240437df6a5e0e4b470d7a1eabacb61a.NginxMailingListRussian@forum.nginx.org>

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

Делаем  сервис в котором пользователь может создать свой сайт. Все сайты
обращаются к одной бд, скрипты тоже для всех пользователей одни. 
В качестве вебсервера используется nginx + apache2 

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

В конфигурацию nginx, apache домены не добавляются.
На IP1 сайты пользователей, на IP2 висит тестовый сайт. 

Пока используется только IP1 все хорошо, как только подключается IP2
начинаются проблемы с доступностью сайтов, зависает то один, то второй, то
третий.

Задача подключить IP2.
Опыта конфигурирования nginx нет, конфиг сделал по аналогии c  конфигом  для
одного IP, на котором сейчас все работает.


upstream  main_upstream  {  
    server   ip1:80;  
    server   ip2:80;  
}  
server {  
        listen ip1:80;  
        listen ip2:80;  
        server_name  www.domain.ru;  
        rewrite ^ http://domain.ru$request_uri? permanent; #301 redirect  
        }  
  
location / {  
           
           proxy_pass http://main_upstream;  
           proxy_set_header Host $host;  
           proxy_set_header X-Real-IP $remote_addr;  
           proxy_set_header X-Forwarded-For $remote_addr;  

 proxy_set_header X-Forwarded-Protocol $scheme;  
      # proxy_set_header X-Forwarded-For $proxy_add_x_forwarder_for;  

    }  
    location ~*
\.(jpeg|jpg|gif|png|css|js|pdf|tar|zip|rar|swf|flv|avi|mp3|mpeg)$ {  
        root /var/www/domain.ru/project/project;  
    }  
    location ~ /\.ht {  
       deny  all;  
 }  

        }  

   upstream  process_upstream  {  
    server   ip1:8080;  
    server   ip2:8080;  

server {  
        listen ip1:80 default_server;  
        listen ip2:80  default_server;  
        server_name .domain.ru;  
        #access_log /var/log/nginx/access.log;  
        #error_log  /var/log/nginx/error.log;  

   location / {  
      proxy_pass http://process_upstream;  
           proxy_set_header Host $host;  
           proxy_set_header X-Real-IP $remote_addr;  
           proxy_set_header X-Forwarded-For $remote_addr;  
      # proxy_set_header X-Forwarded-Protocol $scheme;  
      # proxy_set_header X-Forwarded-For $proxy_add_x_forwarder_for;  

    }  
    location ~*
\.(jpeg|jpg|gif|png|css|js|pdf|tar|zip|rar|swf|flv|avi|mp3|mpeg)$ {  
        root /var/www/domain.ru/project/project;  
    }  
    location ~ /\.ht {  
       deny  all;  
 }  

}

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


From nginx-forum at nginx.us  Tue Jul 16 13:26:53 2013
From: nginx-forum at nginx.us (yanda.a)
Date: Tue, 16 Jul 2013 09:26:53 -0400
Subject: =?UTF-8?B?0JjQs9C90L7RgNC40YDRg9C10YLRgdGPIGNsaWVudCBtYXggYm9keSBzaXplINCy?=
 =?UTF-8?B?INC40LzQtdC90L7QstCw0L3QvdC+0LwgbG9jYXRpb24=?=
Message-ID: <ba9152d2a33dae3a4c589f680698af4d.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток!
Недавно столкнулись с проблемой настройки nginx. Суть в том, что при
попадании в именованный location не срабатывает параметр
client_max_body_size определенный в нем. Например, при следующей
конфигурации и попытке залить файл размером более 1 МБ по адресу
http://server/index.php мы сталкиваемся с ограничением на максимальный
размер файла (получаем 413), при этом, в именованном location явно указан
параметр, переопределяющий это стандартное значение.

location / {
    root /var/www/htdocs/;
    try_files $uri @proxy_upstream;
}

location @proxy_upstream {  
    proxy_pass         http://127.0.0.1:80;

    proxy_redirect     off;
    proxy_intercept_errors on;
            
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Port $server_port;
            
    client_max_body_size       10m;
    client_body_buffer_size    128k;
}

Но, если перенести параметр client_max_body_size в location /, куда
изначально попадает запрос, то данный параметр работает нормально и файл
залить удается.

Параметры сборки nginx:
#nginx -V
nginx version: nginx/1.4.1
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx-error.log --user=www --group=www
--with-debug --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx-access.log --with-http_addition_module
--with-http_geoip_module --with-http_gzip_static_module
--with-http_image_filter_module --with-http_realip_module
--with-http_secure_link_module --with-http_stub_status_module --with-pcre
--with-http_ssl_module


Собственно вопрос, в чем может быть причина игнорирования
client_max_body_size в именованном location?

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


From nginx-forum at nginx.us  Tue Jul 16 13:32:03 2013
From: nginx-forum at nginx.us (memento)
Date: Tue, 16 Jul 2013 09:32:03 -0400
Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCBuZ2lueA==?=
In-Reply-To: <240437df6a5e0e4b470d7a1eabacb61a.NginxMailingListRussian@forum.nginx.org>
References: <240437df6a5e0e4b470d7a1eabacb61a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <0081f6d845a6cba4eba63ef1a4e8b21a.NginxMailingListRussian@forum.nginx.org>

Все, вроде бы разобрался, добавил в 

upstream main_upstream {
server ip1:80 weight=5;
server ip2:80 weight=5;

Пока работает нормально.

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


From landy2005 at gmail.com  Tue Jul 16 21:30:16 2013
From: landy2005 at gmail.com (Mike Stupalov)
Date: Wed, 17 Jul 2013 01:30:16 +0400
Subject: observium rewrite
In-Reply-To: <1355165029.825566496@f230.mail.ru>
References: <1355165029.825566496@f230.mail.ru>
Message-ID: <CAHK261c_83ccJuD1o84m02z6bBW+3fSve9JGF7oav1OkNM-qvg@mail.gmail.com>

Выложите ваш конфиг, пожалуйста, как вы сделали реврайты для observium.


2012/12/10 Habarov D.L <habich99 at mail.ru>

> При break я получал ошибку 404. Но проблему я решил с реврайтами. Спасибо.
> Если кому надо, могу выложить конфиг.
>
>
> Понедельник, 10 декабря 2012, 21:37 от Theodor Zurabishvili <
> theodor at itdc.ge>:
>
>  lastзавершает обработку текущего набора директив
> модуля ngx_http_rewrite_module, после чего ищется новый location,
> соответствующий изменённому URI; breakзавершает обработку текущего набора
> директив модуля ngx_http_rewrite_module;
>
>
> 2012/12/10 Habarov D.L <habich99 at mail.ru<https://e.mail.ru/cgi-bin/sentmsg?mailto=mailto%3ahabich99 at mail.ru>
> >
>
> Доброго времени суток всем!
> Пытаюсь завести observium с nginx, но проблемы с реврайтами.
>
> htaccess:
>
> Options FollowSymlinks Multiviews
>
> RewriteEngine on
> RewriteBase /
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-d
> RewriteCond %{REQUEST_URI} !\.(js|ico|txt|gif|jpg|png|css|php)
> RewriteRule ^(.*)$ index.php/$1/
> AcceptPathInfo On
>
> Правила для nginx:
>
>         location / {
>                 try_files $uri $uri/ @observium;
>         }
>
>
>         location @observium {
>                 rewrite ^(.+)$ /index.php/$1/ last;
>         }
>
> В error.log:
> 2012/12/10 01:09:05 [error] 32627#0: *8 rewrite or internal redirection
> cycle while redirect to named location "@observium", client: ***.***.**.**,
> server: observium.monitoring.mydomain.com, request: "GET
> /device/device=2/ HTTP/1.1", host: observium.monitoring.mydomain.com",
> referrer: "https://observium.monitoring.mydomain.com/"
>
> Скажите пожалуйста, что я делаю не так?
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org<https://e.mail.ru/cgi-bin/sentmsg?mailto=mailto%3anginx%2dru at nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Best Regards
>
> Theodor Zurabishvili
> System Administrator
> ITDC
>
> Tel: +032 2 490049
> Mob: +995 595 239014
>
>  _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org<https://e.mail.ru/cgi-bin/sentmsg?compose&To=nginx%2dru 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
>



-- 
Mike Stupalov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130717/f2dbd80b/attachment.html>

From nginx-forum at nginx.us  Wed Jul 17 02:09:06 2013
From: nginx-forum at nginx.us (is_as)
Date: Tue, 16 Jul 2013 22:09:06 -0400
Subject: =?UTF-8?B?V1NVUyDQsdC10Lcg0L/QtdGA0LXQvdCw0YHRgtGA0L7QudC60Lgg0LrQu9C40LU=?=
 =?UTF-8?B?0L3RgtC+0LI=?=
Message-ID: <f94da2d4657e0bc7609c736d71b59818.NginxMailingListRussian@forum.nginx.org>

Добрый день!
Имеется очень большая сеть > 10000 компьютеров, в разных подразделениях, в
разных населенных пунктах. Все выходят в сеть через один общий шлюз. Домена
нет и не будет. Перенастроить клиентов на использование сервера WSUS - проще
застрелиться (их и за год не объедешь, на местах только юзеры).
Надо при обновлении продуктов microsoft для экономии внешнего трафика
отдавать контент с локального сервера WSUS.

При обновлении через интернет ссылки имеют вид:
http://download.windowsupdate.com/msdownload/update/software/secu/2013/06/windows6.1-kb2850851-x64-express_8653F241799466FA67F9325EF257D47D5EC17DFF.exe

Ссылки на статику должны иметь вид:
http://192.168.82.218/Content/FF/8653F241799466FA67F9325EF257D47D5EC17DFF.exe
Каталог на хранилище WSUS, в примере это "FF", определяется по последним
двум символам перед расширением, после расширения после "?" могут идти
параметры.
В хранилище WSUS файлы четырех типов: psf, exe, cab, txt (регистр расширения
может меняться)

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


From chipitsine at gmail.com  Wed Jul 17 03:50:33 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 17 Jul 2013 09:50:33 +0600
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <f94da2d4657e0bc7609c736d71b59818.NginxMailingListRussian@forum.nginx.org>
References: <f94da2d4657e0bc7609c736d71b59818.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQH3D8tECjkBoqEJ4=oyN7MAd=9LMf48v-MQ_J1t3oCzYA@mail.gmail.com>

"Ссылки на статику должны иметь вид" - поясните, что вы имеете в виду ?

17 июля 2013 г., 8:09 пользователь is_as <nginx-forum at nginx.us> написал:
> Добрый день!
> Имеется очень большая сеть > 10000 компьютеров, в разных подразделениях, в
> разных населенных пунктах. Все выходят в сеть через один общий шлюз. Домена
> нет и не будет. Перенастроить клиентов на использование сервера WSUS - проще
> застрелиться (их и за год не объедешь, на местах только юзеры).
> Надо при обновлении продуктов microsoft для экономии внешнего трафика
> отдавать контент с локального сервера WSUS.
>
> При обновлении через интернет ссылки имеют вид:
> http://download.windowsupdate.com/msdownload/update/software/secu/2013/06/windows6.1-kb2850851-x64-express_8653F241799466FA67F9325EF257D47D5EC17DFF.exe
>
> Ссылки на статику должны иметь вид:
> http://192.168.82.218/Content/FF/8653F241799466FA67F9325EF257D47D5EC17DFF.exe
> Каталог на хранилище WSUS, в примере это "FF", определяется по последним
> двум символам перед расширением, после расширения после "?" могут идти
> параметры.
> В хранилище WSUS файлы четырех типов: psf, exe, cab, txt (регистр расширения
> может меняться)
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,240928,240928#msg-240928
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Wed Jul 17 04:00:45 2013
From: nginx-forum at nginx.us (is_as)
Date: Wed, 17 Jul 2013 00:00:45 -0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAFHpkQH3D8tECjkBoqEJ4=oyN7MAd=9LMf48v-MQ_J1t3oCzYA@mail.gmail.com>
References: <CAFHpkQH3D8tECjkBoqEJ4=oyN7MAd=9LMf48v-MQ_J1t3oCzYA@mail.gmail.com>
Message-ID: <1a040568af173596a2e8740f55662447.NginxMailingListRussian@forum.nginx.org>

Есть сервер WSUS, если просто перехватывать запросы на обновление и
отправлять их на этот сервер, то обновляться клиенты не хотят. Если вместо
этого разрешить клиентам обновляться "нормально", но при попытке скачать
обновление, брать его не с download.windowsupdate.com, а с локально WSUS
сервера. 
Т.е. если клиенту нужен psf, exe, cab или txt, то берем их с нашего сервера.
Такое возможно?

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


From chipitsine at gmail.com  Wed Jul 17 04:19:04 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 17 Jul 2013 10:19:04 +0600
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <1a040568af173596a2e8740f55662447.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQH3D8tECjkBoqEJ4=oyN7MAd=9LMf48v-MQ_J1t3oCzYA@mail.gmail.com>
 <1a040568af173596a2e8740f55662447.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGZq7kBuSNZcOMDsWxrnaAs_8LeCBeW3Jx+94Smt5eZVA@mail.gmail.com>

какой запрос будет приходить на ваш сервер (приведите пример) и какой
файл в итоге должен отдаться (тоже приведите пример)

17 июля 2013 г., 10:00 пользователь is_as <nginx-forum at nginx.us> написал:
> Есть сервер WSUS, если просто перехватывать запросы на обновление и
> отправлять их на этот сервер, то обновляться клиенты не хотят. Если вместо
> этого разрешить клиентам обновляться "нормально", но при попытке скачать
> обновление, брать его не с download.windowsupdate.com, а с локально WSUS
> сервера.
> Т.е. если клиенту нужен psf, exe, cab или txt, то берем их с нашего сервера.
> Такое возможно?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,240928,240931#msg-240931
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Wed Jul 17 04:24:56 2013
From: nginx-forum at nginx.us (is_as)
Date: Wed, 17 Jul 2013 00:24:56 -0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAFHpkQGZq7kBuSNZcOMDsWxrnaAs_8LeCBeW3Jx+94Smt5eZVA@mail.gmail.com>
References: <CAFHpkQGZq7kBuSNZcOMDsWxrnaAs_8LeCBeW3Jx+94Smt5eZVA@mail.gmail.com>
Message-ID: <c90327a6937a89ad6a4147faab2d649d.NginxMailingListRussian@forum.nginx.org>

Там же был вроде пример...
Запрос:
http://download.windowsupdate.com/msdownload/update/software/secu/2013/06/windows6.1-kb2850851-x64-express_8653F241799466FA67F9325EF257D47D5EC17DFF.exe
Ответ:
http://192.168.82.218/Content/FF/8653F241799466FA67F9325EF257D47D5EC17DFF.exe

Вот только имена файлов разные... как к этому отнесется клиент? Или он
просто его получит и съест?

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


From chipitsine at gmail.com  Wed Jul 17 04:35:54 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 17 Jul 2013 10:35:54 +0600
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <c90327a6937a89ad6a4147faab2d649d.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGZq7kBuSNZcOMDsWxrnaAs_8LeCBeW3Jx+94Smt5eZVA@mail.gmail.com>
 <c90327a6937a89ad6a4147faab2d649d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHQRAXJD1fuigX98zUy58wF-=AeGDTe4GBEgxyhEy8G4A@mail.gmail.com>

вы dns подменяете ? и nginx работает в режиме веб-сервера ? не как
forward-прокси ?



http://download.windowsupdate.com/msdownload/update/software/secu/2013/06/windows6.1-kb2850851-x64-express_8653F241799466FA67F9325EF257D47D5EC17DFF.exe
- поскольку вы подменили dns, то такой запрос приходит на ваш nginx ?

http://192.168.82.218/Content/FF/8653F241799466FA67F9325EF257D47D5EC17DFF.exe
- с этим непонятно, надо отдать это в виде редиректа ? или надо отдать
файл /Content/FF/8653F241799466FA67F9325EF257D47D5EC17DFF.exe с
файловой системы с кодом 200 ?

17 июля 2013 г., 10:24 пользователь is_as <nginx-forum at nginx.us> написал:
> Там же был вроде пример...
> Запрос:
> http://download.windowsupdate.com/msdownload/update/software/secu/2013/06/windows6.1-kb2850851-x64-express_8653F241799466FA67F9325EF257D47D5EC17DFF.exe
> Ответ:
> http://192.168.82.218/Content/FF/8653F241799466FA67F9325EF257D47D5EC17DFF.exe
>
> Вот только имена файлов разные... как к этому отнесется клиент? Или он
> просто его получит и съест?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,240928,240933#msg-240933
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Wed Jul 17 04:45:27 2013
From: nginx-forum at nginx.us (is_as)
Date: Wed, 17 Jul 2013 00:45:27 -0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAFHpkQHQRAXJD1fuigX98zUy58wF-=AeGDTe4GBEgxyhEy8G4A@mail.gmail.com>
References: <CAFHpkQHQRAXJD1fuigX98zUy58wF-=AeGDTe4GBEgxyhEy8G4A@mail.gmail.com>
Message-ID: <17d019de8458ae7ab3dd7134b2961c5c.NginxMailingListRussian@forum.nginx.org>

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

>> "надо отдать это в виде редиректа ? или надо отдать файл файловой системы
с кодом 200 ?"
Я вообще ничего не знаю, иначе бы не спрашивал.
Просто я задал вопрос на техподдержке microsoft, а они сказали "однозначно
невозможно", а я думаю что nginx как раз справится.

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


From chipitsine at gmail.com  Wed Jul 17 04:57:34 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 17 Jul 2013 10:57:34 +0600
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <17d019de8458ae7ab3dd7134b2961c5c.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQHQRAXJD1fuigX98zUy58wF-=AeGDTe4GBEgxyhEy8G4A@mail.gmail.com>
 <17d019de8458ae7ab3dd7134b2961c5c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHHRu+Fh6YpPZ63VgSQnFHp6_Ls+pMbDXKZMNjPzSbdJA@mail.gmail.com>

а что за организация с >10000 компьютерами, но без домена, если не секрет ?

17 июля 2013 г., 10:45 пользователь is_as <nginx-forum at nginx.us> написал:
> Да, запрос должен приходить на мой nginx, а дальше: если загрузка
> обновления, то надо как-то подсунуть файл с другого сервера, а если нет
> загрузки (поиск, проверка обновлений и т.д.), то отдать на оригинальный
> сайт...
>
>>> "надо отдать это в виде редиректа ? или надо отдать файл файловой системы
> с кодом 200 ?"
> Я вообще ничего не знаю, иначе бы не спрашивал.
> Просто я задал вопрос на техподдержке microsoft, а они сказали "однозначно
> невозможно", а я думаю что nginx как раз справится.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,240928,240935#msg-240935
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Wed Jul 17 05:05:07 2013
From: nginx-forum at nginx.us (is_as)
Date: Wed, 17 Jul 2013 01:05:07 -0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAFHpkQHHRu+Fh6YpPZ63VgSQnFHp6_Ls+pMbDXKZMNjPzSbdJA@mail.gmail.com>
References: <CAFHpkQHHRu+Fh6YpPZ63VgSQnFHp6_Ls+pMbDXKZMNjPzSbdJA@mail.gmail.com>
Message-ID: <35cd2c35279ead7fcf3403c0d1eb4bad.NginxMailingListRussian@forum.nginx.org>

Конечно не секрет: система образования края, школ много, компьютеров тоже,
специалистов - ноль. По мониторингу трафика обновление продуктов microsoft
съедает хороший кусок внешнего канала и дает дополнительную нагрузку на
систему контентной фильтрации.

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


From chipitsine at gmail.com  Wed Jul 17 05:22:12 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 17 Jul 2013 11:22:12 +0600
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <35cd2c35279ead7fcf3403c0d1eb4bad.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQHHRu+Fh6YpPZ63VgSQnFHp6_Ls+pMbDXKZMNjPzSbdJA@mail.gmail.com>
 <35cd2c35279ead7fcf3403c0d1eb4bad.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>

"специалистов - ноль" - это очень плохая предпосылка для того, чтобы
создавать (и поддерживать) самодельный WSUS. как дешевый вариант (в
том числе в поддержке), можно в днс "увести" адреса
download.microsoft.com, скажем в 127.0.0.1, сделать просто, работать
будет предсказуемо.

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

17 июля 2013 г., 11:05 пользователь is_as <nginx-forum at nginx.us> написал:
> Конечно не секрет: система образования края, школ много, компьютеров тоже,
> специалистов - ноль. По мониторингу трафика обновление продуктов microsoft
> съедает хороший кусок внешнего канала и дает дополнительную нагрузку на
> систему контентной фильтрации.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,240928,240937#msg-240937
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Wed Jul 17 05:30:02 2013
From: nginx-forum at nginx.us (is_as)
Date: Wed, 17 Jul 2013 01:30:02 -0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
Message-ID: <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>

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

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


From nginx-ru at sadok.spb.ru  Wed Jul 17 07:32:13 2013
From: nginx-ru at sadok.spb.ru (Dmitry Ivanov)
Date: Wed, 17 Jul 2013 11:32:13 +0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
 <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <212361212.20130717113213@sadok.spb.ru>

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

Вы писали 17 июля 2013 г., 9:30:02:

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

offtopic

не проще ли разослать по "очкам" cmd-шник, который пропишет один раз
настройки и самоудалится? результат, конечно, не 100%-ый, но over 50%
точно.


-- 
С уважением,
 Dmitry                          mailto:nginx-ru at sadok.spb.ru


From kav at karagodov.name  Wed Jul 17 07:43:12 2013
From: kav at karagodov.name (Alexey V. Karagodov)
Date: Wed, 17 Jul 2013 11:43:12 +0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <212361212.20130717113213@sadok.spb.ru>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
 <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
 <212361212.20130717113213@sadok.spb.ru>
Message-ID: <B93D5FF9-05A9-4713-93BB-289E5D0C7B56@karagodov.name>


On 17.07.2013, at 11:32, Dmitry Ivanov <nginx-ru at sadok.spb.ru> wrote:

> Здравствуйте, is_as.
> 
> Вы писали 17 июля 2013 г., 9:30:02:
> 
>> Специалистов нет в школах, со своей стороны сервера мы поддержкой обеспечим,
>> для этого весь трафик и централизовали. Отключать обновление совсем тоже
>> неправильно, это-то мы всегда можем сделать.
> 
> offtopic
> 
> не проще ли разослать по "очкам" cmd-шник, который пропишет один раз
> настройки и самоудалится? результат, конечно, не 100%-ый, но over 50%
> точно.

1. есть групповая политика 
2. есть МОРЕ мануала, по запуску локального ВСУС-сервера, как официального, громоздкого, дорого и пр и пр, так и на всяких там апачах 

обычно, и чтоб точно работало, надо выполнить оба пункта 
если вы хотите реализовать что-то вроде ДНС-спуффинга (иногда оно работает, конечно же, к примеру с провиженингом IP-телефонов), то тут ни кто не мешает экспериментировать, удачи ? 


> 
> 
> -- 
> С уважением,
> Dmitry                          mailto:nginx-ru at sadok.spb.ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nefer05 at gmail.com  Wed Jul 17 10:26:44 2013
From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=)
Date: Wed, 17 Jul 2013 14:26:44 +0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <B93D5FF9-05A9-4713-93BB-289E5D0C7B56@karagodov.name>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
 <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
 <212361212.20130717113213@sadok.spb.ru>
 <B93D5FF9-05A9-4713-93BB-289E5D0C7B56@karagodov.name>
Message-ID: <CAE-UrwgOeYavhxO4LKqsn9GsDaCqqHsP_nRqiTH4pzKsWFYtrA@mail.gmail.com>

По моему для таких задач использовался кеширующий прокси всегда...


2013/7/17 Alexey V. Karagodov <kav at karagodov.name>

>
> On 17.07.2013, at 11:32, Dmitry Ivanov <nginx-ru at sadok.spb.ru> wrote:
>
> > Здравствуйте, is_as.
> >
> > Вы писали 17 июля 2013 г., 9:30:02:
> >
> >> Специалистов нет в школах, со своей стороны сервера мы поддержкой
> обеспечим,
> >> для этого весь трафик и централизовали. Отключать обновление совсем тоже
> >> неправильно, это-то мы всегда можем сделать.
> >
> > offtopic
> >
> > не проще ли разослать по "очкам" cmd-шник, который пропишет один раз
> > настройки и самоудалится? результат, конечно, не 100%-ый, но over 50%
> > точно.
>
> 1. есть групповая политика
> 2. есть МОРЕ мануала, по запуску локального ВСУС-сервера, как
> официального, громоздкого, дорого и пр и пр, так и на всяких там апачах
>
> обычно, и чтоб точно работало, надо выполнить оба пункта
> если вы хотите реализовать что-то вроде ДНС-спуффинга (иногда оно
> работает, конечно же, к примеру с провиженингом IP-телефонов), то тут ни
> кто не мешает экспериментировать, удачи ...
>
>
> >
> >
> > --
> > С уважением,
> > Dmitry                          mailto:nginx-ru at sadok.spb.ru
> >
> > _______________________________________________
> > 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/20130717/138d6d43/attachment.html>

From kav at karagodov.name  Wed Jul 17 10:35:34 2013
From: kav at karagodov.name (Alexey V. Karagodov)
Date: Wed, 17 Jul 2013 14:35:34 +0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAE-UrwgOeYavhxO4LKqsn9GsDaCqqHsP_nRqiTH4pzKsWFYtrA@mail.gmail.com>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
 <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
 <212361212.20130717113213@sadok.spb.ru>
 <B93D5FF9-05A9-4713-93BB-289E5D0C7B56@karagodov.name>
 <CAE-UrwgOeYavhxO4LKqsn9GsDaCqqHsP_nRqiTH4pzKsWFYtrA@mail.gmail.com>
Message-ID: <4CB19DAA-AC55-4C37-BE91-7C71562832C4@karagodov.name>


On 17.07.2013, at 14:26, Роман Москвитин <nefer05 at gmail.com> wrote:

> По моему для таких задач использовался кеширующий прокси всегда?
очень опрометчивое замечание, в частности касательно ВСУС-а 


> 
> 
> 2013/7/17 Alexey V. Karagodov <kav at karagodov.name>
> 
> On 17.07.2013, at 11:32, Dmitry Ivanov <nginx-ru at sadok.spb.ru> wrote:
> 
> > Здравствуйте, is_as.
> >
> > Вы писали 17 июля 2013 г., 9:30:02:
> >
> >> Специалистов нет в школах, со своей стороны сервера мы поддержкой обеспечим,
> >> для этого весь трафик и централизовали. Отключать обновление совсем тоже
> >> неправильно, это-то мы всегда можем сделать.
> >
> > offtopic
> >
> > не проще ли разослать по "очкам" cmd-шник, который пропишет один раз
> > настройки и самоудалится? результат, конечно, не 100%-ый, но over 50%
> > точно.
> 
> 1. есть групповая политика
> 2. есть МОРЕ мануала, по запуску локального ВСУС-сервера, как официального, громоздкого, дорого и пр и пр, так и на всяких там апачах
> 
> обычно, и чтоб точно работало, надо выполнить оба пункта
> если вы хотите реализовать что-то вроде ДНС-спуффинга (иногда оно работает, конечно же, к примеру с провиженингом IP-телефонов), то тут ни кто не мешает экспериментировать, удачи ?
> 
> 
> >
> >
> > --
> > С уважением,
> > Dmitry                          mailto:nginx-ru at sadok.spb.ru
> >
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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/20130717/cb0c4af3/attachment.html>

From mdounin at mdounin.ru  Wed Jul 17 13:30:20 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 17 Jul 2013 17:30:20 +0400
Subject: nginx-1.4.2
Message-ID: <20130717133020.GE49108@mdounin.ru>

Изменения в nginx 1.4.2                                           17.07.2013

    *) Исправление: метод $r->header_in() встроенного перла не возвращал
       значения строк "Cookie" и "X-Forwarded-For" из заголовка запроса;
       ошибка появилась в 1.3.14.

    *) Исправление: nginx не собирался с модулем ngx_mail_ssl_module, но без
       модуля ngx_http_ssl_module; ошибка появилась в 1.3.14.

    *) Исправление: в директиве proxy_set_body.
       Спасибо Lanshun Zhou.

    *) Исправление: параметр fail_timeout директивы server в блоке upstream
       мог не работать, если использовался параметр max_fails; ошибка
       появилась в 1.3.0.

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если использовалась директива ssl_stapling.
       Спасибо Piotr Sikora.

    *) Исправление: nginx/Windows мог перестать принимать соединения, если
       использовалось несколько рабочих процессов.


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


From nginx-forum at nginx.us  Wed Jul 17 15:58:55 2013
From: nginx-forum at nginx.us (ks2)
Date: Wed, 17 Jul 2013 11:58:55 -0400
Subject: upstream: backup server
Message-ID: <2b6ad4aeca19b074a85092830693981e.NginxMailingListRussian@forum.nginx.org>

Добрый день,

В документации про

upstream backend {
  server  foo.com
  server  bar.com backup;
}

сказано:
only uses this server if the non-backup servers are all down or busy.

Что конкретно означает "busy" в данном случае?

Спасибо!

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


From chipitsine at gmail.com  Wed Jul 17 16:34:38 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 17 Jul 2013 22:34:38 +0600
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAE-UrwgOeYavhxO4LKqsn9GsDaCqqHsP_nRqiTH4pzKsWFYtrA@mail.gmail.com>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
 <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
 <212361212.20130717113213@sadok.spb.ru>
 <B93D5FF9-05A9-4713-93BB-289E5D0C7B56@karagodov.name>
 <CAE-UrwgOeYavhxO4LKqsn9GsDaCqqHsP_nRqiTH4pzKsWFYtrA@mail.gmail.com>
Message-ID: <CAFHpkQHt36LUUoFyX87cQdfK7uGCbbZ=Jms3NxRz-PR98u3JRg@mail.gmail.com>

WSUS - это задача из ряда "вызовов", доказать, что я это тоже могу.
Имя файла с хешем (по адресу запрашивающего), причем часть запросов
может пойти через прокси, часть напрямую. Хеш в итоге не склеится.
Слабо разрулить на кеширующем прокси ?

Заголовки ответов, несмотря на статический контент, не содержат ни
Expire, ни max-age. Слабо такое аккуратно закешить ?

Всякие разные дополнительные хедеры на статику. Слабо ?

Желание клиента качать контент в несколько потоков, с использованием
Range-запросов. Слабо такое закешить ?

Недокументированность всех этих нюансов, как следствие постоянно
держать руку на пульсе при (сюрприз!) внезапном переходе серверной
части от vN к vN+1 ? Причем, эта самая vN в хедерах особо не
светится...


так то полезное дело. можно погрузиться в HTTP по настоящему ))


17 июля 2013 г., 16:26 пользователь Роман Москвитин <nefer05 at gmail.com> написал:
> По моему для таких задач использовался кеширующий прокси всегда...
>
>
> 2013/7/17 Alexey V. Karagodov <kav at karagodov.name>
>
>>
>> On 17.07.2013, at 11:32, Dmitry Ivanov <nginx-ru at sadok.spb.ru> wrote:
>>
>> > Здравствуйте, is_as.
>> >
>> > Вы писали 17 июля 2013 г., 9:30:02:
>> >
>> >> Специалистов нет в школах, со своей стороны сервера мы поддержкой
>> >> обеспечим,
>> >> для этого весь трафик и централизовали. Отключать обновление совсем
>> >> тоже
>> >> неправильно, это-то мы всегда можем сделать.
>> >
>> > offtopic
>> >
>> > не проще ли разослать по "очкам" cmd-шник, который пропишет один раз
>> > настройки и самоудалится? результат, конечно, не 100%-ый, но over 50%
>> > точно.
>>
>> 1. есть групповая политика
>> 2. есть МОРЕ мануала, по запуску локального ВСУС-сервера, как
>> официального, громоздкого, дорого и пр и пр, так и на всяких там апачах
>>
>> обычно, и чтоб точно работало, надо выполнить оба пункта
>> если вы хотите реализовать что-то вроде ДНС-спуффинга (иногда оно
>> работает, конечно же, к примеру с провиженингом IP-телефонов), то тут ни кто
>> не мешает экспериментировать, удачи ...
>>
>>
>> >
>> >
>> > --
>> > С уважением,
>> > Dmitry                          mailto:nginx-ru at sadok.spb.ru
>> >
>> > _______________________________________________
>> > 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
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From onokonem at gmail.com  Wed Jul 17 16:35:59 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Wed, 17 Jul 2013 20:35:59 +0400
Subject: upstream: backup server
In-Reply-To: <2b6ad4aeca19b074a85092830693981e.NginxMailingListRussian@forum.nginx.org>
References: <2b6ad4aeca19b074a85092830693981e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3A834B90-2D69-4E00-8463-F6A930E7EE1D@gmail.com>


> 
> Что конкретно означает "busy" в данном случае?
> 
Невозможность установить с бекендом соединение


From mdounin at mdounin.ru  Wed Jul 17 16:37:04 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 17 Jul 2013 20:37:04 +0400
Subject: upstream: backup server
In-Reply-To: <2b6ad4aeca19b074a85092830693981e.NginxMailingListRussian@forum.nginx.org>
References: <2b6ad4aeca19b074a85092830693981e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130717163704.GH49108@mdounin.ru>

Hello!

On Wed, Jul 17, 2013 at 11:58:55AM -0400, ks2 wrote:

> Добрый день,
> 
> В документации про
> 
> upstream backend {
>   server  foo.com
>   server  bar.com backup;
> }
> 
> сказано:
> only uses this server if the non-backup servers are all down or busy.
> 
> Что конкретно означает "busy" в данном случае?

Вы, судя по всему, зашли в wiki.  Узнать, что имели ввиду 
пользователи, пишушие в вики - во многих случаях не представляется 
возможным.  Это отчасти компенсируется тем, что написанное одним - 
может легко поправить другой.

В документации же сказано:

: backup
: marks the server as a backup server. It will be passed requests when the primary servers are down.

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server

На русском:

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

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#server

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


From vsjcfm at gmail.com  Wed Jul 17 16:37:12 2013
From: vsjcfm at gmail.com (Sayetsky Anton)
Date: Wed, 17 Jul 2013 19:37:12 +0300
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAFHpkQHt36LUUoFyX87cQdfK7uGCbbZ=Jms3NxRz-PR98u3JRg@mail.gmail.com>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
 <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
 <212361212.20130717113213@sadok.spb.ru>
 <B93D5FF9-05A9-4713-93BB-289E5D0C7B56@karagodov.name>
 <CAE-UrwgOeYavhxO4LKqsn9GsDaCqqHsP_nRqiTH4pzKsWFYtrA@mail.gmail.com>
 <CAFHpkQHt36LUUoFyX87cQdfK7uGCbbZ=Jms3NxRz-PR98u3JRg@mail.gmail.com>
Message-ID: <CAFG2KC+uReoYFYpneVqfZugBisA-LBSFGhqaAkgT7Kr-y2j9SQ@mail.gmail.com>

Казалось бы, при чём здесь nginx...

From gmm at csdoc.com  Wed Jul 17 17:02:28 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 17 Jul 2013 20:02:28 +0300
Subject: upstream: backup server
In-Reply-To: <20130717163704.GH49108@mdounin.ru>
References: <2b6ad4aeca19b074a85092830693981e.NginxMailingListRussian@forum.nginx.org>
 <20130717163704.GH49108@mdounin.ru>
Message-ID: <51E6CE24.6080805@csdoc.com>

On 17.07.2013 19:37, Maxim Dounin wrote:

>> В документации про
>>
>> upstream backend {
>>    server  foo.com
>>    server  bar.com backup;
>> }
>>
>> сказано:
>> only uses this server if the non-backup servers are all down or busy.
>>
>> Что конкретно означает "busy" в данном случае?
>
> Вы, судя по всему, зашли в wiki.  Узнать, что имели ввиду
> пользователи, пишушие в вики - во многих случаях не представляется
> возможным.  Это отчасти компенсируется тем, что написанное одним -
> может легко поправить другой.

очень мало кто из пользователей догадывается, что wiki.nginx.org
не является "официальным" и **достоверным** источником информации.
ведь этот сайт размещается по "официальному" адресу wiki.nginx.org
и на него есть ссылка со страницы http://nginx.org/en/support.html

может быть имеет смысл на каждой странице wiki сверху повесить баннер,
что это не является документацией и может содержать ошибки и неточности?

или хотя бы написать об этом на странице
http://nginx.org/en/support.html
http://nginx.org/ru/support.html
и т.п.

-- 
Best regards,
  Gena


From kav at karagodov.name  Wed Jul 17 20:42:01 2013
From: kav at karagodov.name (Alexey V. Karagodov)
Date: Thu, 18 Jul 2013 00:42:01 +0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <CAFG2KC+uReoYFYpneVqfZugBisA-LBSFGhqaAkgT7Kr-y2j9SQ@mail.gmail.com>
References: <CAFHpkQEBm8mRJnuvHAF3eK5AsH06UC7UxfsDpR1uD5tcfU6sRw@mail.gmail.com>
 <7c233997c5e2f9aa497ad54aeb70c5aa.NginxMailingListRussian@forum.nginx.org>
 <212361212.20130717113213@sadok.spb.ru>
 <B93D5FF9-05A9-4713-93BB-289E5D0C7B56@karagodov.name>
 <CAE-UrwgOeYavhxO4LKqsn9GsDaCqqHsP_nRqiTH4pzKsWFYtrA@mail.gmail.com>
 <CAFHpkQHt36LUUoFyX87cQdfK7uGCbbZ=Jms3NxRz-PR98u3JRg@mail.gmail.com>
 <CAFG2KC+uReoYFYpneVqfZugBisA-LBSFGhqaAkgT7Kr-y2j9SQ@mail.gmail.com>
Message-ID: <CC4ED9BF-A8F3-46C7-8098-28335CFBB096@karagodov.name>


On 17.07.2013, at 20:37, Sayetsky Anton <vsjcfm at gmail.com> wrote:

> Казалось бы, при чём здесь nginx?
ну ? немножко статики отдать ? 

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


From nginx-forum at nginx.us  Thu Jul 18 04:30:46 2013
From: nginx-forum at nginx.us (PbIXTOP)
Date: Thu, 18 Jul 2013 00:30:46 -0400
Subject: =?UTF-8?B?UmU6IFdTVVMg0LHQtdC3INC/0LXRgNC10L3QsNGB0YLRgNC+0LnQutC4INC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQvtCy?=
In-Reply-To: <f94da2d4657e0bc7609c736d71b59818.NginxMailingListRussian@forum.nginx.org>
References: <f94da2d4657e0bc7609c736d71b59818.NginxMailingListRussian@forum.nginx.org>
Message-ID: <c41fea72f4551a527e1934e882097c67.NginxMailingListRussian@forum.nginx.org>

Как вариант рекомендую почитать мою проблему

http://forum.nginx.org/read.php?21,240884
Задача приблизительно такая же.
Экономит прилично причем не только Microsoft Update, но есть и проблемы,
которые я не могу решить самостоятельно. И поэтому просил помощи
Работает как раз через DNS-спуфинг

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


From vbart at nginx.com  Thu Jul 18 14:16:10 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Thu, 18 Jul 2013 18:16:10 +0400
Subject: =?UTF-8?B?UmU6ICDQmNCz0L3QvtGA0LjRgNGD0LXRgtGB0Y8gY2xpZW50IG1heCBib2R5IHNp?=
 =?UTF-8?B?emUg0LIg0LjQvNC10L3QvtCy0LDQvdC90L7QvCBsb2NhdGlvbg==?=
In-Reply-To: <ba9152d2a33dae3a4c589f680698af4d.NginxMailingListRussian@forum.nginx.org>
References: <ba9152d2a33dae3a4c589f680698af4d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201307181816.10499.vbart@nginx.com>

On Tuesday 16 July 2013 17:26:53 yanda.a wrote:
> Доброго времени суток!
> Недавно столкнулись с проблемой настройки nginx. Суть в том, что при
> попадании в именованный location не срабатывает параметр
> client_max_body_size определенный в нем. Например, при следующей
> конфигурации и попытке залить файл размером более 1 МБ по адресу
> http://server/index.php мы сталкиваемся с ограничением на максимальный
> размер файла (получаем 413), при этом, в именованном location явно указан
> параметр, переопределяющий это стандартное значение.
> 
> location / {
>     root /var/www/htdocs/;
>     try_files $uri @proxy_upstream;
> }
> 
> location @proxy_upstream {
>     proxy_pass         http://127.0.0.1:80;
> 
>     proxy_redirect     off;
>     proxy_intercept_errors on;
> 
>     proxy_set_header   Host             $host;
>     proxy_set_header   X-Real-IP        $remote_addr;
>     proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
>     proxy_set_header   X-Forwarded-Port $server_port;
> 
>     client_max_body_size       10m;
>     client_body_buffer_size    128k;
> }
> 
> Но, если перенести параметр client_max_body_size в location /, куда
> изначально попадает запрос, то данный параметр работает нормально и файл
> залить удается.
> 
> Параметры сборки nginx:
> #nginx -V
> nginx version: nginx/1.4.1
> TLS SNI support enabled
> configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
> /usr/local/include' --with-ld-opt='-L /usr/local/lib'
> --conf-path=/usr/local/etc/nginx/nginx.conf
> --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
> --error-log-path=/var/log/nginx-error.log --user=www --group=www
> --with-debug --with-file-aio
> --http-client-body-temp-path=/var/tmp/nginx/client_body_temp
> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
> --http-proxy-temp-path=/var/tmp/nginx/proxy_temp
> --http-scgi-temp-path=/var/tmp/nginx/scgi_temp
> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
> --http-log-path=/var/log/nginx-access.log --with-http_addition_module
> --with-http_geoip_module --with-http_gzip_static_module
> --with-http_image_filter_module --with-http_realip_module
> --with-http_secure_link_module --with-http_stub_status_module --with-pcre
> --with-http_ssl_module
> 
> 
> Собственно вопрос, в чем может быть причина игнорирования
> client_max_body_size в именованном location?
> 

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

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Sun Jul 21 09:22:07 2013
From: nginx-forum at nginx.us (dvital1001)
Date: Sun, 21 Jul 2013 05:22:07 -0400
Subject: =?UTF-8?B?0KXQvtGH0LXRgtGB0Y8g0YHQtNC10LvQsNGC0Ywg0YLQsNC6LCDRh9GC0L7QsdGL?=
 =?UTF-8?B?INGB0LDQudGCINC90LUg0LHRi9C7INC00L7RgdGC0YPQv9C10L0g0L/QviA=?=
 =?UTF-8?B?0LXQs9C+IGlw?=
Message-ID: <f4bc09d073983ca1f7f40e9bd185d4d2.NginxMailingListRussian@forum.nginx.org>

Добрый день!

Была поставлена задача сделать так, что 3 сайта на сервере не были доступны
по их ip. Каждый из сайтов размещен на отдельном ip. Для этого я создал
такой дополнительный конфиг:
server {
    listen xxx.xxx.xxx.xxx;
    server_name xxx.xxx.xxx.xxx;
    access_log off;
    return 444;
}

и для каждого из ip его продублировал. Самое удивительное то, что первые два
сайта не откликаются по ip при включении такого конфига, а третий все-равно
откликается. 

Версия nginx - 1.4.2

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


From loverjoni at gmail.com  Sun Jul 21 09:34:07 2013
From: loverjoni at gmail.com (Ivan Palanevich)
Date: Sun, 21 Jul 2013 12:34:07 +0300
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <f4bc09d073983ca1f7f40e9bd185d4d2.NginxMailingListRussian@forum.nginx.org>
References: <f4bc09d073983ca1f7f40e9bd185d4d2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5B40EBDC-D4F0-4765-BCBF-8570CCF190E3@gmail.com>

Лучше всего использовать

server {
 listen * default_server;
 server_name _;
 access_log off;
 return 444;
}
On Jul 21, 2013, at 12:22 PM, "dvital1001" <nginx-forum at nginx.us> wrote:

> Добрый день!
> 
> Была поставлена задача сделать так, что 3 сайта на сервере не были доступны
> по их ip. Каждый из сайтов размещен на отдельном ip. Для этого я создал
> такой дополнительный конфиг:
> server {
>    listen xxx.xxx.xxx.xxx;
>    server_name xxx.xxx.xxx.xxx;
>    access_log off;
>    return 444;
> }
> 
> и для каждого из ip его продублировал. Самое удивительное то, что первые два
> сайта не откликаются по ip при включении такого конфига, а третий все-равно
> откликается. 
> 
> Версия nginx - 1.4.2
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241085,241085#msg-241085
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Sun Jul 21 11:51:56 2013
From: nginx-forum at nginx.us (dwow)
Date: Sun, 21 Jul 2013 07:51:56 -0400
Subject: PATH_INFO
Message-ID: <0a313eed96b6c111f2c4fa3f01372671.NginxMailingListRussian@forum.nginx.org>

Добрый день,
такая задача:
бекенд работает через uwsgi, в параметрах передаваемых uwsgi path_info
передается вот так:
uwsgi_param  PATH_INFO          $document_uri;

но проблема в том, что $document_uri меняется во время обработки запроса.
можно использовать $request_uri, но этот параметр содержит в себе еще и
query_string (

Есть ли переменная в nginx, которая сохраняет первоначальный path_info?

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


From nginx-forum at nginx.us  Sun Jul 21 11:58:21 2013
From: nginx-forum at nginx.us (tiberule)
Date: Sun, 21 Jul 2013 07:58:21 -0400
Subject: =?UTF-8?B?0LrQsNC6INC+0YLQutC70Y7Rh9C40YLRjCB1cmxkZWNvZGUg0LIg0L/RgNC40YU=?=
 =?UTF-8?B?0L7QtNGP0YnQuNGFINC30LDQv9GA0L7RgdCw0YU/?=
Message-ID: <d67fdf40b1959c22bb2922fa21f3664a.NginxMailingListRussian@forum.nginx.org>

Задача достаточно простая.

статические страницы html
клиент запрашивает например страницу /информация.html
на сервер приходит запрос GET
/%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8F.html
на сервере лежит файл
"%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8F.html" и ждет
своего часа

и тут засада. nginx пытается открыть файл "информация.html" вместо
urlencoded названия пришедшего в запросе...

можно ли как-то отключить принудительное декодирование? потому как создавать
файлы с не латинскими буквами это повод нарваться на более глубокие проблемы
при работе с файлами

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


From nginx-forum at nginx.us  Sun Jul 21 12:24:33 2013
From: nginx-forum at nginx.us (tiberule)
Date: Sun, 21 Jul 2013 08:24:33 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDQvtGC0LrQu9GO0YfQuNGC0YwgdXJsZGVjb2RlINCyINC/0YA=?=
 =?UTF-8?B?0LjRhdC+0LTRj9GJ0LjRhSDQt9Cw0L/RgNC+0YHQsNGFPw==?=
In-Reply-To: <d67fdf40b1959c22bb2922fa21f3664a.NginxMailingListRussian@forum.nginx.org>
References: <d67fdf40b1959c22bb2922fa21f3664a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <c48adf898c61943d34f16a2b1f99967f.NginxMailingListRussian@forum.nginx.org>

как вариант приделал костыли

location /информация {
	try_files $uri
/%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d1%8f/index.html
=404;
}

но такой вариант подойдет только для статики. интересно что можно придумать
для динамических запросов?

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

location / {
	try_files $uri $uri/ urlencode($uri) urlencode($uri)/ =404;
}

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


From mva at mva.name  Sun Jul 21 14:24:58 2013
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Sun, 21 Jul 2013 18:24:58 +0400
Subject: nginx-1.4.2
In-Reply-To: <20130717133020.GE49108@mdounin.ru>
References: <20130717133020.GE49108@mdounin.ru>
Message-ID: <51EBEF3A.50109@mva.name>

А это всё в 1.5.2 уже входит? :)

17.07.2013 17:30, Maxim Dounin пишет:
> Изменения в nginx 1.4.2                                           17.07.2013
> 
>     *) Исправление: метод $r->header_in() встроенного перла не возвращал
>        значения строк "Cookie" и "X-Forwarded-For" из заголовка запроса;
>        ошибка появилась в 1.3.14.
> 
>     *) Исправление: nginx не собирался с модулем ngx_mail_ssl_module, но без
>        модуля ngx_http_ssl_module; ошибка появилась в 1.3.14.
> 
>     *) Исправление: в директиве proxy_set_body.
>        Спасибо Lanshun Zhou.
> 
>     *) Исправление: параметр fail_timeout директивы server в блоке upstream
>        мог не работать, если использовался параметр max_fails; ошибка
>        появилась в 1.3.0.
> 
>     *) Исправление: в рабочем процессе мог произойти segmentation fault,
>        если использовалась директива ssl_stapling.
>        Спасибо Piotr Sikora.
> 
>     *) Исправление: nginx/Windows мог перестать принимать соединения, если
>        использовалось несколько рабочих процессов.
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130721/e395077e/attachment.bin>

From postmaster at softsearch.ru  Sun Jul 21 15:49:45 2013
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sun, 21 Jul 2013 19:49:45 +0400
Subject: nginx-1.4.2
In-Reply-To: <51EBEF3A.50109@mva.name>
References: <20130717133020.GE49108@mdounin.ru> <51EBEF3A.50109@mva.name>
Message-ID: <559171795.20130721194945@softsearch.ru>

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

> А это всё в 1.5.2 уже входит? :)

Да. Оно от туда и берётся изначально. Исключение - обновления ошибок,
связанных с безопасностью, которые попадают сразу в несколько версий.


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


From nginx-forum at nginx.us  Sun Jul 21 18:15:13 2013
From: nginx-forum at nginx.us (dvital1001)
Date: Sun, 21 Jul 2013 14:15:13 -0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <5B40EBDC-D4F0-4765-BCBF-8570CCF190E3@gmail.com>
References: <5B40EBDC-D4F0-4765-BCBF-8570CCF190E3@gmail.com>
Message-ID: <ef2c6a282c650a2c4e358abd2e3827e5.NginxMailingListRussian@forum.nginx.org>

Я поставил этот код в конфиг:
server {
listen * default_server;
server_name _;
access_log off;
return 444;
}

и удалил свой код и теперь все сайты доступны по  ip стали. Как можно это
объяснить?

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


From onokonem at gmail.com  Sun Jul 21 18:19:16 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Sun, 21 Jul 2013 22:19:16 +0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <ef2c6a282c650a2c4e358abd2e3827e5.NginxMailingListRussian@forum.nginx.org>
References: <5B40EBDC-D4F0-4765-BCBF-8570CCF190E3@gmail.com>
 <ef2c6a282c650a2c4e358abd2e3827e5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOEzD_gkXYEX-+4jzvVdk7QJkxsFuxShC_fjgQY3RZsB+A@mail.gmail.com>

> и удалил свой код и теперь все сайты доступны по  ip стали. Как можно это
> объяснить?
Доступны - это отвечают 200, а не 444? Это можно объяснить только
неаккуратным тестированием.

From nginx-forum at nginx.us  Sun Jul 21 18:20:22 2013
From: nginx-forum at nginx.us (dvital1001)
Date: Sun, 21 Jul 2013 14:20:22 -0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <ef2c6a282c650a2c4e358abd2e3827e5.NginxMailingListRussian@forum.nginx.org>
References: <5B40EBDC-D4F0-4765-BCBF-8570CCF190E3@gmail.com>
 <ef2c6a282c650a2c4e358abd2e3827e5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <c95707e0248c50c66d127c2e50e7cec3.NginxMailingListRussian@forum.nginx.org>

А если поставить вместо * в этом коде ip и раскопировать этот код для всех
трех ip, то для первых двух он работает правильно, а последний ip все-равно
отдает сайт...


server {
    listen xxx.xxx.xxx.xxx default_server;
    server_name _;
    access_log off;
    return 444;
}

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


From onokonem at gmail.com  Sun Jul 21 18:29:03 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Sun, 21 Jul 2013 22:29:03 +0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <c95707e0248c50c66d127c2e50e7cec3.NginxMailingListRussian@forum.nginx.org>
References: <5B40EBDC-D4F0-4765-BCBF-8570CCF190E3@gmail.com>
 <ef2c6a282c650a2c4e358abd2e3827e5.NginxMailingListRussian@forum.nginx.org>
 <c95707e0248c50c66d127c2e50e7cec3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOGBmBbZQJF3=ya-mQbBr1jqTfUtTRM1T0oqL1UopWmshw@mail.gmail.com>

> А если поставить вместо * в этом коде ip и раскопировать этот код для всех
> трех ip, то для первых двух он работает правильно, а последний ip все-равно
> отдает сайт...
А покажите уже полный конфиг без xxx.xxx.xxx.xxx... Ну, если вам нужна помощь.

From nginx-forum at nginx.us  Sun Jul 21 18:43:24 2013
From: nginx-forum at nginx.us (dvital1001)
Date: Sun, 21 Jul 2013 14:43:24 -0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <CAKaHDOEzD_gkXYEX-+4jzvVdk7QJkxsFuxShC_fjgQY3RZsB+A@mail.gmail.com>
References: <CAKaHDOEzD_gkXYEX-+4jzvVdk7QJkxsFuxShC_fjgQY3RZsB+A@mail.gmail.com>
Message-ID: <68ce006fafd0fefa564e65a70e8a9709.NginxMailingListRussian@forum.nginx.org>

Первые два отдают 444. А последний отдает 404. В принципе наверное и так
сойдет. Просто странно.

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


From nginx-forum at nginx.us  Sun Jul 21 18:55:54 2013
From: nginx-forum at nginx.us (dvital1001)
Date: Sun, 21 Jul 2013 14:55:54 -0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <CAKaHDOGBmBbZQJF3=ya-mQbBr1jqTfUtTRM1T0oqL1UopWmshw@mail.gmail.com>
References: <CAKaHDOGBmBbZQJF3=ya-mQbBr1jqTfUtTRM1T0oqL1UopWmshw@mail.gmail.com>
Message-ID: <28367a61537812beca654f521c9fbcf4.NginxMailingListRussian@forum.nginx.org>

я думаю не слишком хорошо ip своего сервера светить в интернете таким
образом. :)  Я могу выложить конфиг, заменив домены на ip на что-то
нейтральное, но с сохранением смысла конфига. Так подойдет?

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


From swood at fotofor.biz  Sun Jul 21 18:57:25 2013
From: swood at fotofor.biz (Anton Kiryushkin)
Date: Sun, 21 Jul 2013 22:57:25 +0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <28367a61537812beca654f521c9fbcf4.NginxMailingListRussian@forum.nginx.org>
References: <CAKaHDOGBmBbZQJF3=ya-mQbBr1jqTfUtTRM1T0oqL1UopWmshw@mail.gmail.com>
 <28367a61537812beca654f521c9fbcf4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAM_jxg3KqHmCGUYP-FkLxJJdhV81tP-WkPU38kzEK=8-3MakvQ@mail.gmail.com>

Выкладывайте уже, будем смотреть )


21 июля 2013 г., 22:55 пользователь dvital1001 <nginx-forum at nginx.us>написал:

> я думаю не слишком хорошо ip своего сервера светить в интернете таким
> образом. :)  Я могу выложить конфиг, заменив домены на ip на что-то
> нейтральное, но с сохранением смысла конфига. Так подойдет?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,241085,241100#msg-241100
>
> _______________________________________________
> 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/20130721/5795ea3d/attachment.html>

From onokonem at gmail.com  Sun Jul 21 18:57:39 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Sun, 21 Jul 2013 22:57:39 +0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <28367a61537812beca654f521c9fbcf4.NginxMailingListRussian@forum.nginx.org>
References: <CAKaHDOGBmBbZQJF3=ya-mQbBr1jqTfUtTRM1T0oqL1UopWmshw@mail.gmail.com>
 <28367a61537812beca654f521c9fbcf4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOEc=hPhUTcRPO1JqECNyi1G4W=6Om6iVawoq36ebRF7nA@mail.gmail.com>

> я думаю не слишком хорошо ip своего сервера светить в интернете таким
> образом. :)  Я могу выложить конфиг, заменив домены на ip на что-то
> нейтральное, но с сохранением смысла конфига. Так подойдет?
мне - нет.

если два отдают 444, а третий 404 - скорее всего, в третьем ip опечатка.

From nginx-forum at nginx.us  Sun Jul 21 19:02:56 2013
From: nginx-forum at nginx.us (dvital1001)
Date: Sun, 21 Jul 2013 15:02:56 -0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <CAKaHDOEc=hPhUTcRPO1JqECNyi1G4W=6Om6iVawoq36ebRF7nA@mail.gmail.com>
References: <CAKaHDOEc=hPhUTcRPO1JqECNyi1G4W=6Om6iVawoq36ebRF7nA@mail.gmail.com>
Message-ID: <eca7b8b626b2259d4a3a8134dc9cdf44.NginxMailingListRussian@forum.nginx.org>

Это логично, но там нет опечатки, к сожалению. :(

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


From onokonem at gmail.com  Sun Jul 21 19:05:48 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Sun, 21 Jul 2013 23:05:48 +0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <eca7b8b626b2259d4a3a8134dc9cdf44.NginxMailingListRussian@forum.nginx.org>
References: <CAKaHDOEc=hPhUTcRPO1JqECNyi1G4W=6Om6iVawoq36ebRF7nA@mail.gmail.com>
 <eca7b8b626b2259d4a3a8134dc9cdf44.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOGnKZ30RN4RWTNctYFV9Bo4Ba2uF_7x=dikVZz8pS-Fpg@mail.gmail.com>

> Это логично, но там нет опечатки, к сожалению. :(
Ну воткните каждому серверу свой access.log, и убедитесь, что в третий
сервер запросы не попадают, а попадают в дефолтный.

потом разберитесь - почему так.

From nginx-forum at nginx.us  Sun Jul 21 19:12:16 2013
From: nginx-forum at nginx.us (dvital1001)
Date: Sun, 21 Jul 2013 15:12:16 -0400
Subject: =?UTF-8?B?UmU6INCl0L7Rh9C10YLRgdGPINGB0LTQtdC70LDRgtGMINGC0LDQuiwg0YfRgtC+?=
 =?UTF-8?B?0LHRiyDRgdCw0LnRgiDQvdC1INCx0YvQuyDQtNC+0YHRgtGD0L/QtdC9INC/?=
 =?UTF-8?B?0L4g0LXQs9C+IGlw?=
In-Reply-To: <CAM_jxg3KqHmCGUYP-FkLxJJdhV81tP-WkPU38kzEK=8-3MakvQ@mail.gmail.com>
References: <CAM_jxg3KqHmCGUYP-FkLxJJdhV81tP-WkPU38kzEK=8-3MakvQ@mail.gmail.com>
Message-ID: <55784160d75b22a9d047aea7e4987f42.NginxMailingListRussian@forum.nginx.org>

вот конфиги. Они у меня разнесены по файлам. В файле
/etc/nginx/sites-enabled/reset.conf отдельно расположены конфиг запрета
запроса сайта по ip. 
Надеюсь, это что-то даст. 

#### /etc/nginx/nginx.conf

user  www-data;
worker_processes  8;

error_log  /var/log/nginx/error.log notice;

pid        /var/run/nginx.pid;
worker_rlimit_nofile 8192;
timer_resolution 100ms;
worker_priority -5;

events {
    worker_connections  2048;
    use epoll;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request"
'
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;
    index              index.php index.html index.htm;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    client_max_body_size 20m;

    gzip  on;
    gzip_static      on;
    gzip_min_length  1000;
    gzip_proxied     any;
    gzip_types text/plain text/xml application/xml application/x-javascript
text/javascript text/css text/json;
    gzip_disable     "msie6";
    gzip_comp_level  8;


    include /etc/nginx/sites-enabled/*;
}


###  /etc/nginx/sites-enabled/site1.conf
  server {
        listen       192.168.10.1:80;        
        server_name example1.com;
        access_log  /home/example1.com/logs/access.log  main;

        charset windows-1251;

        root /home/example1.com/www;

        error_page  404              /index.php;

        location ~* 
\.(js|JPG|jpg|png|jpeg|gif|zip|tgz|gz|rar|doc|xls|exe|pdf|ppt|txt|wav|bmp|rtf)$
{
            expires 1y;
            open_file_cache_errors  off;
         #   error_page 404 = @fetch;
            access_log off;
        }

        # redirect server error pages to the static page /50x.html
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/nginx/html;
        }

        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        # pass the PHP scripts to FastCGI server listening on
127.0.0.1:9000
        location ~ \.php$  {
            try_files $uri =404;

            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            include fastcgi_params;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
            # fastcgi_intercept_errors on;
            fastcgi_pass 127.0.0.1:9000;
        }
}



###  /etc/nginx/sites-enabled/site2.conf
  server {
        listen       192.169.10.2:80;
        server_name  example2.com;
        access_log  /home/example2.com/logs/access.log  main;

        charset utf8;

        root /home/example2.com/www;

        error_page  404              /index.php;

        location ~* 
\.(js|JPG|jpg|png|jpeg|gif|zip|tgz|gz|rar|doc|xls|exe|pdf|ppt|txt|wav|bmp|rtf)$
{
            expires 1y;
            open_file_cache_errors  off;
         #   error_page 404 = @fetch;
            access_log off;
        }

        # redirect server error pages to the static page /50x.html
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/nginx/html;
        }

        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        # pass the PHP scripts to FastCGI server listening on
127.0.0.1:9000
        location ~ \.php$  {
            try_files $uri =404;

            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            include fastcgi_params;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
            # fastcgi_intercept_errors on;
            fastcgi_pass 127.0.0.1:9000;
        }


    }



###  /etc/nginx/sites-enabled/site3.conf
  server {
        listen       192.169.10.3:80;
        server_name  example3.com;
        access_log  /home/example3.com/logs/access.log  main;

        charset utf8;

        root /home/example3.com/www;

        error_page  404              /index.php;

        location ~* 
\.(js|JPG|jpg|png|jpeg|gif|zip|tgz|gz|rar|doc|xls|exe|pdf|ppt|txt|wav|bmp|rtf)$
{
            expires 1y;
            open_file_cache_errors  off;
         #   error_page 404 = @fetch;
            access_log off;
        }

        # redirect server error pages to the static page /50x.html
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/nginx/html;
        }

        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        # pass the PHP scripts to FastCGI server listening on
127.0.0.1:9000
        location ~ \.php$  {
            try_files $uri =404;

            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            include fastcgi_params;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
            # fastcgi_intercept_errors on;
            fastcgi_pass 127.0.0.1:9000;
        }


    }


### /etc/nginx/sites-enabled/reset.conf
server {
    listen 192.168.10.1 default_server;
    server_name _;
    access_log off;
    return 444;
}

server {
    listen 192.168.10.2 default_server;
    server_name _;
    access_log off;
    return 444;
}
server {
    listen 192.168.10.3 default_server;
    server_name _;
    access_log off;
    return 444;
}

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


From a.vasilishin at kpi.ua  Mon Jul 22 21:00:14 2013
From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=)
Date: Tue, 23 Jul 2013 00:00:14 +0300
Subject: =?UTF-8?B?0J7QsdGA0LDQsdC+0YLQutCwIGVycm9yX3BhZ2UgNDA1?=
Message-ID: <51ED9D5E.9030003@kpi.ua>

Есть такая конструкция:

         error_page 405             /errors/405.html;
         location = / {
                 if ($request_method = POST) {
                 return 405;
                 }
	}
         location ^~ /errors/ {
                 root   /var/www;
         }

но при  POST /

отдается стандартная нгинксовкая 405 Not Allowed


From nginx-forum at nginx.us  Tue Jul 23 09:04:28 2013
From: nginx-forum at nginx.us (igor.goncharenko)
Date: Tue, 23 Jul 2013 05:04:28 -0400
Subject: =?UTF-8?B?bWF4IGNsaWVudHMg0LIg0YHQu9GD0YfQsNC1INGA0LXQstC10YDRgSDQv9GA0L4=?=
 =?UTF-8?B?0LrRgdC4?=
Message-ID: <5aaf5926c107fe161c2c6a7df5b28e62.NginxMailingListRussian@forum.nginx.org>

Hi!

Увидел в англоязычной ветке форума:

http://forum.nginx.org/read.php?2,240989,240991#msg-240991

--
In a reverse proxy situation, max clients becomes
max clients = worker_processes * worker_connections/4
--

А почему, собственно говоря на 4? Я так понимаю, правильно на 2?

---
Igor

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


From mdounin at mdounin.ru  Tue Jul 23 11:13:12 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 23 Jul 2013 15:13:12 +0400
Subject: =?UTF-8?B?UmU6IG1heCBjbGllbnRzINCyINGB0LvRg9GH0LDQtSDRgNC10LLQtdGA0YEg0L8=?=
 =?UTF-8?B?0YDQvtC60YHQuA==?=
In-Reply-To: <5aaf5926c107fe161c2c6a7df5b28e62.NginxMailingListRussian@forum.nginx.org>
References: <5aaf5926c107fe161c2c6a7df5b28e62.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130723111312.GE90722@mdounin.ru>

Hello!

On Tue, Jul 23, 2013 at 05:04:28AM -0400, igor.goncharenko wrote:

> Hi!
> 
> Увидел в англоязычной ветке форума:
> 
> http://forum.nginx.org/read.php?2,240989,240991#msg-240991
> 
> --
> In a reverse proxy situation, max clients becomes
> max clients = worker_processes * worker_connections/4
> --
> 
> А почему, собственно говоря на 4? Я так понимаю, правильно на 2?

Там есть ссылка на wiki, где автор соответствующего утвреждения 
поясняет свою позицию: 

: Since a browser opens 2 connections by default to a server and 
: nginx uses the fds (file descriptors) from the same pool to 
: connect to the upstream backend

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

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


From mdounin at mdounin.ru  Tue Jul 23 11:38:39 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 23 Jul 2013 15:38:39 +0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <51ED9D5E.9030003@kpi.ua>
References: <51ED9D5E.9030003@kpi.ua>
Message-ID: <20130723113839.GG90722@mdounin.ru>

Hello!

On Tue, Jul 23, 2013 at 12:00:14AM +0300, Андрей Василишин wrote:

> Есть такая конструкция:
> 
>         error_page 405             /errors/405.html;
>         location = / {
>                 if ($request_method = POST) {
>                 return 405;
>                 }
> 	}
>         location ^~ /errors/ {
>                 root   /var/www;
>         }
> 
> но при  POST /
> 
> отдается стандартная нгинксовкая 405 Not Allowed

Видимо, конструкция не совсем такая, и либо там, где 
обрабатывается запрос, нет error_page 405, либо после 
пренаправления снова делается return 405.

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


From alexander.moskalenko at gmail.com  Tue Jul 23 13:19:02 2013
From: alexander.moskalenko at gmail.com (Alexander Moskalenko)
Date: Tue, 23 Jul 2013 16:19:02 +0300
Subject: =?UTF-8?B?0JHQu9C+0LrQuNGA0L7QstC60LAg0LrQvtC90YLQtdC90YLQsCDQv9C+IDIt0Lwg?=
 =?UTF-8?B?SFRUUC3Qt9Cw0LPQvtC70L7QstC60LDQvA==?=
Message-ID: <CACVfVFv=ENpVHiBm_prGtA1ktXpnBaQpy4cZdmeB8tyRACF8hQ@mail.gmail.com>

Привет.

Сейчас есть такая конфигурация:

    if ($http_x_cdn1 != "secret") {
       return 503;
    }

Мне нужно в дополнение проверить таким же образом заголовок X_CDN2.

Пока все что придумал - 3 map.

Может есть вариант покрасивее?

From andrey at kopeyko.ru  Tue Jul 23 13:33:17 2013
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Tue, 23 Jul 2013 20:33:17 +0700
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <20130723113839.GG90722@mdounin.ru>
References: <51ED9D5E.9030003@kpi.ua> <20130723113839.GG90722@mdounin.ru>
Message-ID: <12e8a784-fc7a-46b4-8c23-a3c9c27878eb@email.android.com>

А не потому ли, что POST по-прежнему делается в статический файл /errors/405.html? Ведь обработчик error_page, насколько помню, не меняет метод запроса. 

Maxim Dounin <mdounin at mdounin.ru> написал(а):

>Hello!
>
>On Tue, Jul 23, 2013 at 12:00:14AM +0300, Андрей Василишин wrote:
>
>> Есть такая конструкция:
>> 
>>         error_page 405             /errors/405.html;
>>         location = / {
>>                 if ($request_method = POST) {
>>                 return 405;
>>                 }
>> 	}
>>         location ^~ /errors/ {
>>                 root   /var/www;
>>         }
>> 
>> но при  POST /
>> 
>> отдается стандартная нгинксовкая 405 Not Allowed
>
>Видимо, конструкция не совсем такая, и либо там, где 
>обрабатывается запрос, нет error_page 405, либо после 
>пренаправления снова делается return 405.
>
>-- 
>Maxim Dounin
>http://nginx.org/en/donation.html
>
>_______________________________________________
>nginx-ru mailing list
>nginx-ru at nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Отправлено через К-9 Mail. Извините за краткость, пожалуйста.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130723/c9042eb5/attachment.html>

From mdounin at mdounin.ru  Tue Jul 23 13:53:48 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 23 Jul 2013 17:53:48 +0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <12e8a784-fc7a-46b4-8c23-a3c9c27878eb@email.android.com>
References: <51ED9D5E.9030003@kpi.ua> <20130723113839.GG90722@mdounin.ru>
 <12e8a784-fc7a-46b4-8c23-a3c9c27878eb@email.android.com>
Message-ID: <20130723135348.GL90722@mdounin.ru>

Hello!

On Tue, Jul 23, 2013 at 08:33:17PM +0700, Andrey Kopeyko wrote:

> А не потому ли, что POST по-прежнему делается в статический файл 
> /errors/405.html? Ведь обработчик error_page, насколько помню, 
> не меняет метод запроса. 

Почему не меняет?  Меняет, за исключением случая перенаправления в 
именованный location.

Цитата из ngx_http_send_error_page():

    if (uri.data[0] == '/') {

        if (err_page->value.lengths) {
            ngx_http_split_args(r, &uri, &args);

        } else {
            args = err_page->args;
        }

        if (r->method != NGX_HTTP_HEAD) {
            r->method = NGX_HTTP_GET;
            r->method_name = ngx_http_get_name;
        }

        return ngx_http_internal_redirect(r, &uri, &args);
    }

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


From postmaster at softsearch.ru  Tue Jul 23 15:35:14 2013
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Tue, 23 Jul 2013 19:35:14 +0400
Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQutCwINC60L7QvdGC0LXQvdGC0LAg0L/QviAy?=
 =?UTF-8?B?LdC8IEhUVFAt0LfQsNCz0L7Qu9C+0LLQutCw0Lw=?=
In-Reply-To: <CACVfVFv=ENpVHiBm_prGtA1ktXpnBaQpy4cZdmeB8tyRACF8hQ@mail.gmail.com>
References: <CACVfVFv=ENpVHiBm_prGtA1ktXpnBaQpy4cZdmeB8tyRACF8hQ@mail.gmail.com>
Message-ID: <853702739.20130723193514@softsearch.ru>

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

> Сейчас есть такая конфигурация:

>     if ($http_x_cdn1 != "secret") {
>        return 503;
>     }

> Мне нужно в дополнение проверить таким же образом заголовок X_CDN2.

> Пока все что придумал - 3 map.

> Может есть вариант покрасивее?

Через set сконкатенируйте все нужные заголовки в одну строку и потом в
map-е одним регэкспом все их сразу проверьте.

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


From a.vasilishin at kpi.ua  Tue Jul 23 21:58:54 2013
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Wed, 24 Jul 2013 00:58:54 +0300
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <20130723113839.GG90722@mdounin.ru>
References: <51ED9D5E.9030003@kpi.ua> <20130723113839.GG90722@mdounin.ru>
Message-ID: <51EEFC9E.6010106@kpi.ua>

23.07.2013 14:38, Maxim Dounin пишет:
> Hello!
>
> On Tue, Jul 23, 2013 at 12:00:14AM +0300, Андрей Василишин wrote:
>
>> Есть такая конструкция:
>>
>>          error_page 405             /errors/405.html;
>>          location = / {
>>                  if ($request_method = POST) {
>>                  return 405;
>>                  }
>> 	}
>>          location ^~ /errors/ {
>>                  root   /var/www;
>>          }
>>
>> но при  POST /
>>
>> отдается стандартная нгинксовкая 405 Not Allowed
>
> Видимо, конструкция не совсем такая, и либо там, где
> обрабатывается запрос, нет error_page 405, либо после
> пренаправления снова делается return 405.
>

Есть конечно еще локейшн location / { }
без обработки POST, да и error_page 405             /errors/405.html; 
вынесено уровень server.
Ну и в логах видно что запрос обрабатывается таки там больше нигде в 
конфиге нет return 405;


Дебаг:


2013/07/22 23:35:11 [debug] 28849#0: *3880899164 generic phase: 0
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 rewrite phase: 1
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script var
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script var: 
"http://site.com/pi.php"
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script regex: 
"(xxxxx|yyyyy)"
2013/07/22 23:35:11 [notice] 28849#0: *3880899164 "(xxxxx|yyyyy)" does 
not match "http://site.com/test.php", client: 176.104.57.123, server: 
site.com, request: "POST / HTTP/1.1", host:
"site.com", referrer: "http://site.com/test.php"
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script if
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script if: false
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 test location: "/"
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 using configuration "=/"
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http cl:2 max:2102394880
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 rewrite phase: 3
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script var
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script var: "POST"
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script value: "POST"
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script equal
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script if
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http finalize request: 
405, "/?" a:1, c:1
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http special response: 
405, "/?"
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http set discard body
2013/07/22 23:35:11 [debug] 28849#0: *3880899164 HTTP/1.1 405 Not Allowed
Server: nginx/1.2.4
Date: Mon, 22 Jul 2013 20:35:11 GMT
Content-Type: text/html
Content-Length: 172
Connection: keep-alive



From alexander.moskalenko at gmail.com  Tue Jul 23 22:18:34 2013
From: alexander.moskalenko at gmail.com (Alexander Moskalenko)
Date: Wed, 24 Jul 2013 01:18:34 +0300
Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQutCwINC60L7QvdGC0LXQvdGC0LAg0L/QviAy?=
 =?UTF-8?B?LdC8IEhUVFAt0LfQsNCz0L7Qu9C+0LLQutCw0Lw=?=
In-Reply-To: <853702739.20130723193514@softsearch.ru>
References: <CACVfVFv=ENpVHiBm_prGtA1ktXpnBaQpy4cZdmeB8tyRACF8hQ@mail.gmail.com>
 <853702739.20130723193514@softsearch.ru>
Message-ID: <CACVfVFuTE11ba_HiL1EYv1F=vbuzYWCXhdGp+FysSBk5osdzhQ@mail.gmail.com>

Спасибо, интересный вариант.
Сделал пока через сеты и 3 if.

2013/7/23 Михаил Монашёв <postmaster at softsearch.ru>:
> Здравствуйте, Alexander.
>
>> Сейчас есть такая конфигурация:
>
>>     if ($http_x_cdn1 != "secret") {
>>        return 503;
>>     }
>
>> Мне нужно в дополнение проверить таким же образом заголовок X_CDN2.
>
>> Пока все что придумал - 3 map.
>
>> Может есть вариант покрасивее?
>
> Через set сконкатенируйте все нужные заголовки в одну строку и потом в
> map-е одним регэкспом все их сразу проверьте.
>
> --
> С уважением,
>  Михаил                          mailto:postmaster at softsearch.ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin at mdounin.ru  Wed Jul 24 00:31:46 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 24 Jul 2013 04:31:46 +0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <51EEFC9E.6010106@kpi.ua>
References: <51ED9D5E.9030003@kpi.ua> <20130723113839.GG90722@mdounin.ru>
 <51EEFC9E.6010106@kpi.ua>
Message-ID: <20130724003146.GQ90722@mdounin.ru>

Hello!

On Wed, Jul 24, 2013 at 12:58:54AM +0300, Андрей Василишин wrote:

> 23.07.2013 14:38, Maxim Dounin пишет:
> >Hello!
> >
> >On Tue, Jul 23, 2013 at 12:00:14AM +0300, Андрей Василишин wrote:
> >
> >>Есть такая конструкция:
> >>
> >>         error_page 405             /errors/405.html;
> >>         location = / {
> >>                 if ($request_method = POST) {
> >>                 return 405;
> >>                 }
> >>	}
> >>         location ^~ /errors/ {
> >>                 root   /var/www;
> >>         }
> >>
> >>но при  POST /
> >>
> >>отдается стандартная нгинксовкая 405 Not Allowed
> >
> >Видимо, конструкция не совсем такая, и либо там, где
> >обрабатывается запрос, нет error_page 405, либо после
> >пренаправления снова делается return 405.
> >
> 
> Есть конечно еще локейшн location / { }
> без обработки POST, да и error_page 405
> /errors/405.html; вынесено уровень server.
> Ну и в логах видно что запрос обрабатывается таки там больше нигде в
> конфиге нет return 405;

[...]

> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script equal
> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script if
> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http finalize request: 405, "/?" a:1, c:1
> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http special response: 405, "/?"
> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http set discard body
> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 HTTP/1.1 405 Not Allowed

[...]

Debug log как бы намекает, что error_page 405 в location = / нет.  
Скорее всего, имеет смысл перечитать документацию, 
http://nginx.org/r/error_page/ru, особенно вот это предолжение:

: Директивы error_page наследуются с предыдущего уровня при 
: условии, что на данном уровне не описаны свои директивы 
: error_page.

И ещё раз внимательно посмотреть на содержимое location = /.

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


From nginx-forum at nginx.us  Wed Jul 24 06:11:19 2013
From: nginx-forum at nginx.us (yanda.a)
Date: Wed, 24 Jul 2013 02:11:19 -0400
Subject: =?UTF-8?B?UmU6INCY0LPQvdC+0YDQuNGA0YPQtdGC0YHRjyBjbGllbnQgbWF4IGJvZHkgc2l6?=
 =?UTF-8?B?ZSDQsiDQuNC80LXQvdC+0LLQsNC90L3QvtC8IGxvY2F0aW9u?=
In-Reply-To: <201307181816.10499.vbart@nginx.com>
References: <201307181816.10499.vbart@nginx.com>
Message-ID: <3ec8110c04b6605e04256343d0f22f51.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> On Tuesday 16 July 2013 17:26:53 yanda.a wrote:
> Причина в том, что ограничение в "location /, куда изначально попадает
> запрос"
> срабатывает раньше.  Ограничение проверяется при каждом выборе
> location.
> 
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


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

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


From mdounin at mdounin.ru  Wed Jul 24 07:41:16 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 24 Jul 2013 11:41:16 +0400
Subject: =?UTF-8?B?UmU6INCY0LPQvdC+0YDQuNGA0YPQtdGC0YHRjyBjbGllbnQgbWF4IGJvZHkgc2l6?=
 =?UTF-8?B?ZSDQsiDQuNC80LXQvdC+0LLQsNC90L3QvtC8IGxvY2F0aW9u?=
In-Reply-To: <3ec8110c04b6605e04256343d0f22f51.NginxMailingListRussian@forum.nginx.org>
References: <201307181816.10499.vbart@nginx.com>
 <3ec8110c04b6605e04256343d0f22f51.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130724074116.GS90722@mdounin.ru>

Hello!

On Wed, Jul 24, 2013 at 02:11:19AM -0400, yanda.a wrote:

> Валентин Бартенев Wrote:
> -------------------------------------------------------
> > On Tuesday 16 July 2013 17:26:53 yanda.a wrote:
> > Причина в том, что ограничение в "location /, куда изначально попадает
> > запрос"
> > срабатывает раньше.  Ограничение проверяется при каждом выборе
> > location.
> > 
> > --
> > Валентин Бартенев
> > http://nginx.org/en/donation.html
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> Ну так в нашем случае получается, что ограничение не проверяется при
> попадании в именованный location, а берется из location /, в который
> изначально попал запрос.

Размер тела проверяется при попдании запроса в location /.  
Проверка не проходит, возвращается ошибка.  До именованного 
location'а дело не доходит.

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


From a.vasilishin at kpi.ua  Wed Jul 24 07:52:38 2013
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Wed, 24 Jul 2013 10:52:38 +0300
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <20130724003146.GQ90722@mdounin.ru>
References: <51ED9D5E.9030003@kpi.ua> <20130723113839.GG90722@mdounin.ru>
 <51EEFC9E.6010106@kpi.ua> <20130724003146.GQ90722@mdounin.ru>
Message-ID: <51EF87C6.40502@kpi.ua>

24.07.2013 3:31, Maxim Dounin пишет:
> Hello!
>
> On Wed, Jul 24, 2013 at 12:58:54AM +0300, Андрей Василишин wrote:
>
>> 23.07.2013 14:38, Maxim Dounin пишет:
>>> Hello!
>>>
>>> On Tue, Jul 23, 2013 at 12:00:14AM +0300, Андрей Василишин wrote:
>>>
>>>> Есть такая конструкция:
>>>>
>>>>          error_page 405             /errors/405.html;
>>>>          location = / {
>>>>                  if ($request_method = POST) {
>>>>                  return 405;
>>>>                  }
>>>> 	}
>>>>          location ^~ /errors/ {
>>>>                  root   /var/www;
>>>>          }
>>>>
>>>> но при  POST /
>>>>
>>>> отдается стандартная нгинксовкая 405 Not Allowed
>>>
>>> Видимо, конструкция не совсем такая, и либо там, где
>>> обрабатывается запрос, нет error_page 405, либо после
>>> пренаправления снова делается return 405.
>>>
>>
>> Есть конечно еще локейшн location / { }
>> без обработки POST, да и error_page 405
>> /errors/405.html; вынесено уровень server.
>> Ну и в логах видно что запрос обрабатывается таки там больше нигде в
>> конфиге нет return 405;
>
> [...]
>
>> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script equal
>> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script if
>> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http finalize request: 405, "/?" a:1, c:1
>> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http special response: 405, "/?"
>> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http set discard body
>> 2013/07/22 23:35:11 [debug] 28849#0: *3880899164 HTTP/1.1 405 Not Allowed
>
> [...]
>
> Debug log как бы намекает, что error_page 405 в location = / нет.
> Скорее всего, имеет смысл перечитать документацию,
> http://nginx.org/r/error_page/ru, особенно вот это предолжение:
>
> : Директивы error_page наследуются с предыдущего уровня при
> : условии, что на данном уровне не описаны свои директивы
> : error_page.
>

Ну, так на уровне location нет своей директивы error_page

> И ещё раз внимательно посмотреть на содержимое location = /.
>

Полное содержимое:

         location = / {
                 if ($request_method = POST) {
                 return 405;
                 }
                 root   /var/www;
                 try_files $uri $uri/ /index.php?q=$uri&$args;
                 index  index.php index.htm index.html;
                 error_page 404 = @backend;
         }


From mdounin at mdounin.ru  Wed Jul 24 08:12:38 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 24 Jul 2013 12:12:38 +0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <51EF87C6.40502@kpi.ua>
References: <51ED9D5E.9030003@kpi.ua> <20130723113839.GG90722@mdounin.ru>
 <51EEFC9E.6010106@kpi.ua> <20130724003146.GQ90722@mdounin.ru>
 <51EF87C6.40502@kpi.ua>
Message-ID: <20130724081238.GT90722@mdounin.ru>

Hello!

On Wed, Jul 24, 2013 at 10:52:38AM +0300, Андрей Василишин wrote:

> 24.07.2013 3:31, Maxim Dounin пишет:
> >Hello!
> >
> >On Wed, Jul 24, 2013 at 12:58:54AM +0300, Андрей Василишин wrote:
> >
> >>23.07.2013 14:38, Maxim Dounin пишет:
> >>>Hello!
> >>>
> >>>On Tue, Jul 23, 2013 at 12:00:14AM +0300, Андрей Василишин wrote:
> >>>
> >>>>Есть такая конструкция:
> >>>>
> >>>>         error_page 405             /errors/405.html;
> >>>>         location = / {
> >>>>                 if ($request_method = POST) {
> >>>>                 return 405;
> >>>>                 }
> >>>>	}
> >>>>         location ^~ /errors/ {
> >>>>                 root   /var/www;
> >>>>         }
> >>>>
> >>>>но при  POST /
> >>>>
> >>>>отдается стандартная нгинксовкая 405 Not Allowed
> >>>
> >>>Видимо, конструкция не совсем такая, и либо там, где
> >>>обрабатывается запрос, нет error_page 405, либо после
> >>>пренаправления снова делается return 405.
> >>>
> >>
> >>Есть конечно еще локейшн location / { }
> >>без обработки POST, да и error_page 405
> >>/errors/405.html; вынесено уровень server.
> >>Ну и в логах видно что запрос обрабатывается таки там больше нигде в
> >>конфиге нет return 405;
> >
> >[...]
> >
> >>2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script equal
> >>2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http script if
> >>2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http finalize request: 405, "/?" a:1, c:1
> >>2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http special response: 405, "/?"
> >>2013/07/22 23:35:11 [debug] 28849#0: *3880899164 http set discard body
> >>2013/07/22 23:35:11 [debug] 28849#0: *3880899164 HTTP/1.1 405 Not Allowed
> >
> >[...]
> >
> >Debug log как бы намекает, что error_page 405 в location = / нет.
> >Скорее всего, имеет смысл перечитать документацию,
> >http://nginx.org/r/error_page/ru, особенно вот это предолжение:
> >
> >: Директивы error_page наследуются с предыдущего уровня при
> >: условии, что на данном уровне не описаны свои директивы
> >: error_page.
> >
> 
> Ну, так на уровне location нет своей директивы error_page
> 
> >И ещё раз внимательно посмотреть на содержимое location = /.
> >
> 
> Полное содержимое:
> 
>         location = / {
>                 if ($request_method = POST) {
>                 return 405;
>                 }
>                 root   /var/www;
>                 try_files $uri $uri/ /index.php?q=$uri&$args;
>                 index  index.php index.htm index.html;
>                 error_page 404 = @backend;
>         }

Строка "error_page 404 = @backend;" как бы намекает.

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


From a.vasilishin at kpi.ua  Wed Jul 24 08:19:55 2013
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Wed, 24 Jul 2013 11:19:55 +0300
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvcl9wYWdlIDQwNQ==?=
In-Reply-To: <20130724081238.GT90722@mdounin.ru>
References: <51ED9D5E.9030003@kpi.ua> <20130723113839.GG90722@mdounin.ru>
 <51EEFC9E.6010106@kpi.ua> <20130724003146.GQ90722@mdounin.ru>
 <51EF87C6.40502@kpi.ua> <20130724081238.GT90722@mdounin.ru>
Message-ID: <51EF8E2B.2080507@kpi.ua>

24.07.2013 11:12, Maxim Dounin пишет:

>
> Строка "error_page 404 = @backend;" как бы намекает.
>

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


From dmitriy at lyalyuev.info  Wed Jul 24 12:52:57 2013
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Wed, 24 Jul 2013 15:52:57 +0300
Subject: Redirect 8080 to 80
Message-ID: <51EFCE29.3000800@lyalyuev.info>

Добрый день, коллеги.

Столкнулся тут с ситуацией неочевидного редиректа.
Есть tomcat7, который слушает порт 8081 и nginx, который слушает 8080.
При заходе на http://domain.tld:8080/testapp меня редиректит на 
http://domain.tld/testapp
Не могу понять почему это происходит.

Подскажете?

Конфиг:

upstream backend {
        server localhost:8081;
}

server {
            listen   8080;
            server_name domain.tld;
            root /var/lib/tomcat7/webapps/;
            index index.html index.htm;

            location / {
                try_files $uri/maintenance.html $uri @app;
            }

            location @app {
                include /etc/nginx/proxy_params;
                proxy_pass http://backend;
            }
}

Добавляя listen 80 в сервер, все работает как надо, но на порту 80. А с 
8080 все равно редирект делается на 80.
Когда Tomcat висел на 8080 все было хорошо. Поставил nginx перед Tomcat 
и вот такое проявилось.

-- 
Dmitriy Lyalyuev
http://lyalyuev.info




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

From dmitriy at lyalyuev.info  Wed Jul 24 13:22:04 2013
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Wed, 24 Jul 2013 16:22:04 +0300
Subject: Redirect 8080 to 80
In-Reply-To: <51EFCE29.3000800@lyalyuev.info>
References: <51EFCE29.3000800@lyalyuev.info>
Message-ID: <51EFD4FC.5090002@lyalyuev.info>

Разобрался вроде:
proxy_set_header Host $host:$server_port;


24.07.2013 15:52, Dmitriy Lyalyuev пишет:
> Добрый день, коллеги.
>
> Столкнулся тут с ситуацией неочевидного редиректа.
> Есть tomcat7, который слушает порт 8081 и nginx, который слушает 8080.
> При заходе на http://domain.tld:8080/testapp меня редиректит на 
> http://domain.tld/testapp
> Не могу понять почему это происходит.
>
> Подскажете?
>
> Конфиг:
>
> upstream backend {
>        server localhost:8081;
> }
>
> server {
>            listen   8080;
>            server_name domain.tld;
>            root /var/lib/tomcat7/webapps/;
>            index index.html index.htm;
>
>            location / {
>                try_files $uri/maintenance.html $uri @app;
>            }
>
>            location @app {
>                include /etc/nginx/proxy_params;
>                proxy_pass http://backend;
>            }
> }
>
> Добавляя listen 80 в сервер, все работает как надо, но на порту 80. А 
> с 8080 все равно редирект делается на 80.
> Когда Tomcat висел на 8080 все было хорошо. Поставил nginx перед 
> Tomcat и вот такое проявилось.
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
Dmitriy Lyalyuev
http://lyalyuev.info

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

From unera at uvw.ru  Thu Jul 25 09:21:47 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Thu, 25 Jul 2013 13:21:47 +0400
Subject: =?UTF-8?B?0KLQsNC50LzQsNGD0YLRiyDQvdCwINCx0LDQutC10L3QtNC1?=
Message-ID: <20130725092147.GM30025@vdsl.uvw.ru>

столкнулся тут с проблемкой

выкатили некое обновление, которое привело к росту нагрузки в
несколько раз. огребли 504.

стали анализировать логи, 
nginx отдает 504 по причине того что бакенд дескать не отвечает, время
обработки запроса у него 60 секунд:

128.69.168.54 - - [25/Jul/2013:09:37:00 +0400] "POST /dispatcher/ajax/drivers HTTP/1.1" 504 584 "http://бла-бла/dispatcher" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36" [60.000 : 60.000]

в логе ошибок при этом:

2013/07/25 09:37:00 [error] 4832#0: *425146128 upstream timed out (110: Connection timed out) while connecting to upstream, client: 128.69.168.54, server: бла-бла.ru, request: "POST /dispatcher/ajax/drivers HTTP/1.1", upstream: "http://127.0.0.1:81/dispatcher/ajax/drivers", host: "бла-бла", referrer: "http://бла-бла/dispatcher"

(в конце логов добавлены '[$request_time : $upstream_response_time]')

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

далее поглядел я в логи апача, а там такая интересная хрень:

...
[Thu Jul 25 07:52:55 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:09 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:16 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:29 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:43 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:43 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:43 2013] [info] [client 127.0.0.1] Request header read timeout

и так на периоде 4 часа
...


то есть получается что в то же самое время (все это на периоде 4 часа
примерно было) когда nginx отдавал 504 через 60 секунд после начала
работы жалуясь на 'upstream timed out' в это же время апач жаловался
что к нему  коннектятся но ничего не просят.

nginx'ов - 4 вокрера конфиг для данного роута простейший:

    location / {
        proxy_pass          http://backend;
        proxy_set_header    Host            $host;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;

        more_clear_input_headers 'Transfer-Encoding';

        proxy_set_header X-Forwarded-Protocol $scheme;
    }

-- 

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


From ufaweb at gmail.com  Thu Jul 25 09:48:33 2013
From: ufaweb at gmail.com (=?UTF-8?B?0KDRg9GB0LvQsNC9INCo0LDRgNC40L/QvtCy?=)
Date: Thu, 25 Jul 2013 15:48:33 +0600
Subject: =?UTF-8?B?aW1hZ2UgZmlsdGVyINC4INCw0L3QuNC80LjRgNC+0LLQsNC90L3Ri9C1IGdpZic=?=
 =?UTF-8?B?0LrQuA==?=
Message-ID: <CALB9xzCPz2O7CUFDsjK1XMtSoBafrUkB=nL8V+romgo2ynZWiA@mail.gmail.com>

День добрый.

Есть ли способ ресайзить gif анимацию используя image filter модуль
nginx'а, при этом сохраняя анимацию?

-- 
С уважением, Шарипов Руслан.
Руководитель отдела разработки и сопровождения программного
обеспечения ОАО "Уфанет".

Контактная информация:
google+: http://gplus.to/ruslan
jid: serafim at jabber.ufanet.ru
wave: ufaweb at googlewave.com
skype: ufaweb
phone: +7(917)4775460
vkontakte: http://vkontakte.ru/ufaweb
myspace: http://www.myspace.com/ufaweb
facebook: http://facebook.com/sharipov
linkedin: http://www.linkedin.com/in/ufaweb
twitter: http://twitter.com/ufaweb

From postmaster at softsearch.ru  Thu Jul 25 20:14:50 2013
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Fri, 26 Jul 2013 00:14:50 +0400
Subject: =?UTF-8?B?UmU6IGltYWdlIGZpbHRlciDQuCDQsNC90LjQvNC40YDQvtCy0LDQvdC90YvQtSBn?=
 =?UTF-8?B?aWYn0LrQuA==?=
In-Reply-To: <CALB9xzCPz2O7CUFDsjK1XMtSoBafrUkB=nL8V+romgo2ynZWiA@mail.gmail.com>
References: <CALB9xzCPz2O7CUFDsjK1XMtSoBafrUkB=nL8V+romgo2ynZWiA@mail.gmail.com>
Message-ID: <889973855.20130726001450@softsearch.ru>

Здравствуйте, Руслан.

> Есть ли способ ресайзить gif анимацию используя image filter модуль
> nginx'а, при этом сохраняя анимацию?

После ресайза особенно в сторону УМЕНЬШЕНИЯ размер анимированного гифа
может ВЫРАСТИ на порядок. Их лучше на стороне браузера ресайзить.

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


From unera at uvw.ru  Fri Jul 26 07:53:33 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Fri, 26 Jul 2013 11:53:33 +0400
Subject: =?UTF-8?B?0KPQv9GA0LDQstC70LXQvdC40LUg0LrQtdGI0L7QvCAtINGE0LjRh9Cw0YDQtdC6?=
 =?UTF-8?B?0LLQtdGB0YI=?=
Message-ID: <20130726075333.GQ30025@vdsl.uvw.ru>

поигрался немного с кешами.

интересно, включаем кеш для location'а на скажем 0-30 минут и далее
бакенд определяет что данную страницу надо закешировать на скажем 20
секунд выдавая заголовок X-Accel-Expires: 20.
это классная фича!

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

например (утопический пример) мы на сайте кешируем список
пользователей написавших больше всего сообщений (ТОП по
пользователям).
понятное дело, такой ТОП меняется редко и можно смело ему выдать
скажем 10 минут время жизни кеша и все будет хорошо.
но допустим у нас задача есть чтобы этот ТОП выводился более
качественно. становится ТОП'ом другой пользователь (входит в ТОП10) и
сразу картинка перестраивается (без лага в 0-10 минут).

для такой задачи просто определение времени жизни кеширования из
бакенда не подойдет. еще нужно иметь возможность сказать что кеш
невалиден nginx'у. 

и вот тут фичареквест добавить опцию (насколько я понимаю не должно
быть сложным):

у нас есть один хидер на управление кешом:

X-Accel-Expires: [ секунд | @секунд ]

- определяет сколько времени данная страница может находиться в кеше

а можно сюда добавить еще хидер, например:

X-Cache-Invalid: "/users/top/123?all=yes"

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

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

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130726/4aacceb6/attachment.bin>

From vovansystems at gmail.com  Fri Jul 26 09:53:06 2013
From: vovansystems at gmail.com (VovansystemS)
Date: Fri, 26 Jul 2013 12:53:06 +0300
Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?=
 =?UTF-8?B?0LXQutCy0LXRgdGC?=
In-Reply-To: <20130726075333.GQ30025@vdsl.uvw.ru>
References: <20130726075333.GQ30025@vdsl.uvw.ru>
Message-ID: <CAAwq3jwTjV1OGxNQXpHmiJ+DUnj8ynkCMz70MmwhiA3HwkwKLQ@mail.gmail.com>

Добрый день

> а можно сюда добавить еще хидер, например:
>
> X-Cache-Invalid: "/users/top/123?all=yes"
>
> - определяет что с данного момента определенный набор страниц
>   находящихся в кеше (набор = если несколько таких заголовков выдали)
>   невалиден.
>
> Тогда если бакенд выдал такой заголовок (или несколько таких
> заголовков), чтобы nginx по факту выдачи такого ответа сбросил кеши,
> связанные с данными урлами?

удалить элемент из кеша можно директивой
http://nginx.org/r/proxy_cache_bypass/ru по ключу (т.е. новый элемент
возмётся не из кеша, но закешируется)

From nginx-forum at nginx.us  Fri Jul 26 09:57:22 2013
From: nginx-forum at nginx.us (spry)
Date: Fri, 26 Jul 2013 05:57:22 -0400
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/QviDQutGD0LrQsNC8INC00Ls=?=
 =?UTF-8?B?0Y8g0LPQvtGB0YLQtdC5INGE0L7RgNGD0LzQsCDQvdCwIElQQiAoSW52aXNp?=
 =?UTF-8?B?b24gUG93ZXIgQm9hcmQp?=
In-Reply-To: <5670fefb7d9daa357f6e16cecd78feca.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQG5wqqTdpiY2d+nBUGd+6pns-doypsmmTCj7z+c1DtfNQ@mail.gmail.com>
 <5670fefb7d9daa357f6e16cecd78feca.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5ab02dcc0fafa50e2a720bcc51360e38.NginxMailingListRussian@forum.nginx.org>

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

daitepiva Wrote:
-------------------------------------------------------
> Илья Шипицин Wrote:
> -------------------------------------------------------
> > поисковые роботы игнорируют куки, хотите попасть в поисковики в виде
> в
> > таком виде )) ?
> 
> В каком "таком"? С задержкой в одну минуту? Даже для живых людей,
> которые не захотели залогиниться, не видно в этом ничего плохого, а уж
> поисковики тем более переживут )
> Меня интересовала именно правильность реализации моей идеи с точки
> зрения nginx-а.

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


From unera at uvw.ru  Fri Jul 26 13:07:34 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Fri, 26 Jul 2013 17:07:34 +0400
Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?=
 =?UTF-8?B?0LXQutCy0LXRgdGC?=
In-Reply-To: <CAAwq3jwTjV1OGxNQXpHmiJ+DUnj8ynkCMz70MmwhiA3HwkwKLQ@mail.gmail.com>
References: <20130726075333.GQ30025@vdsl.uvw.ru>
 <CAAwq3jwTjV1OGxNQXpHmiJ+DUnj8ynkCMz70MmwhiA3HwkwKLQ@mail.gmail.com>
Message-ID: <20130726130734.GT30025@vdsl.uvw.ru>


>> а можно сюда добавить еще хидер, например:
>> 
>> X-Cache-Invalid: "/users/top/123?all=yes"
>> 
>> - определяет что с данного момента определенный набор страниц
>>   находящихся в кеше (набор = если несколько таких заголовков выдали)
>>   невалиден.
>> 
>> Тогда если бакенд выдал такой заголовок (или несколько таких
>> заголовков), чтобы nginx по факту выдачи такого ответа сбросил кеши,
>> связанные с данными урлами?

> удалить элемент из кеша можно директивой
> http://nginx.org/r/proxy_cache_bypass/ru по ключу (т.е. новый элемент
> возмётся не из кеша, но закешируется)

нет это совсем не то что в фичареквесте.

вот имеется nginx.

делаем GET/POST запрос по роуту /route1/path.
в location прописано что кеширование по данному роуту до 30 минут.

бакенд выдает X-Accel-Expires: 120

в ответ nginx создает кеш-запись о /route1/path, затем все последующие
аналогичные запросы к /route1/path приведут к тому что nginx отвечать
будет из кеша в течение 2 минут.

теперь через 40 секунд производится другой запрос

GET/POST итп /route_other/path_other/. этот запрос транслируется может
быть даже другому бакенду.
и вот в обработчике этого запроса производятся какие-то изменения в
БД, которые приведут в частности к тому что по предыдущему роуту
/route1/path бакенд начнет выдавать совсем другие данные.

то есть с момента запроса роута /route_other/path_other/ кеш для роута
/route1/path должен быть сброшен и обработчик /route_other/path_other/
это знает.

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

а директивы в конфиге = это не программа это набор условий :)


-- 

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130726/24a3145f/attachment.bin>

From chipitsine at gmail.com  Fri Jul 26 13:36:41 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Fri, 26 Jul 2013 19:36:41 +0600
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/QviDQutGD0LrQsNC8INC00Ls=?=
 =?UTF-8?B?0Y8g0LPQvtGB0YLQtdC5INGE0L7RgNGD0LzQsCDQvdCwIElQQiAoSW52aXNp?=
 =?UTF-8?B?b24gUG93ZXIgQm9hcmQp?=
In-Reply-To: <5ab02dcc0fafa50e2a720bcc51360e38.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQG5wqqTdpiY2d+nBUGd+6pns-doypsmmTCj7z+c1DtfNQ@mail.gmail.com>
 <5670fefb7d9daa357f6e16cecd78feca.NginxMailingListRussian@forum.nginx.org>
 <5ab02dcc0fafa50e2a720bcc51360e38.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQG5rrSkYUr-D-B3GQrzq_pG2BXObAucTa=BC1aySCFvOw@mail.gmail.com>

Изыскания закончились тем, что в подобных ситуациях надо использовать ESI,
это почти как SSI, только первая буква "E"

пятница, 26 июля 2013 г. пользователь spry писал:

> Очень интересно чем закончились ваши изыскания, я думаю может вы не учли
> что
> сессия пользователя может передаваться и без куки, если они отключены, т.е.
> надо еще смотреть аргументы на предмет наличия там сессии. Самому эта тема
> акутальна
>
> daitepiva Wrote:
> -------------------------------------------------------
> > Илья Шипицин Wrote:
> > -------------------------------------------------------
> > > поисковые роботы игнорируют куки, хотите попасть в поисковики в виде
> > в
> > > таком виде )) ?
> >
> > В каком "таком"? С задержкой в одну минуту? Даже для живых людей,
> > которые не захотели залогиниться, не видно в этом ничего плохого, а уж
> > поисковики тем более переживут )
> > Меня интересовала именно правильность реализации моей идеи с точки
> > зрения nginx-а.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,234824,241289#msg-241289
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org <javascript:;>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130726/7ed50ef9/attachment.html>

From vovansystems at gmail.com  Fri Jul 26 14:11:03 2013
From: vovansystems at gmail.com (VovansystemS)
Date: Fri, 26 Jul 2013 17:11:03 +0300
Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?=
 =?UTF-8?B?0LXQutCy0LXRgdGC?=
In-Reply-To: <20130726130734.GT30025@vdsl.uvw.ru>
References: <20130726075333.GQ30025@vdsl.uvw.ru>
 <CAAwq3jwTjV1OGxNQXpHmiJ+DUnj8ynkCMz70MmwhiA3HwkwKLQ@mail.gmail.com>
 <20130726130734.GT30025@vdsl.uvw.ru>
Message-ID: <CAAwq3jy5YxeYVFzEvNz6KnXj4Z0XXkq68ZR-LUGR3EfKvfniKw@mail.gmail.com>

>> удалить элемент из кеша можно директивой
>> http://nginx.org/r/proxy_cache_bypass/ru по ключу (т.е. новый элемент
>> возмётся не из кеша, но закешируется)
>
> нет это совсем не то что в фичареквесте.
>
...
>
> я хочу получить механизм внутри обработчика сбросить кеш на другом
> роуте.
> как вариант - выдать хидер с урлом кеш на котором надо сбросить.
>
> а директивы в конфиге = это не программа это набор условий :)
>
я раньше решал похожую проблему с помощью модуля ngx_cache_purge (
http://wiki.nginx.org/CachePurgeChs ). создавал в nginx специальный
локейшн (/purge/), при обращении к которому удалялся из кеша указанный
элемент. Т.е. после изменения в базе, запрос по этому локейшну делает
само приложение (для wordpress есть специальный плагин). Подробнее (с
конфигами) можно почитать тут:

http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html
http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html

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

Таким образом, применяя предложенную мной схему, вместо того чтобы
просто отдать nginx страницу с заголовком X-Cache-Invalid:
"/users/top/123?all=yes", вам придётся сначала сделать запрос из
приложения по адресу /purge/users/top/123?all=yes и элемент кеша
обновится.

From mdounin at mdounin.ru  Fri Jul 26 14:51:13 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 26 Jul 2013 18:51:13 +0400
Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?=
 =?UTF-8?B?0LXQutCy0LXRgdGC?=
In-Reply-To: <20130726075333.GQ30025@vdsl.uvw.ru>
References: <20130726075333.GQ30025@vdsl.uvw.ru>
Message-ID: <20130726145113.GR90722@mdounin.ru>

Hello!

On Fri, Jul 26, 2013 at 11:53:33AM +0400, Dmitry E. Oboukhov wrote:

> поигрался немного с кешами.
> 
> интересно, включаем кеш для location'а на скажем 0-30 минут и далее
> бакенд определяет что данную страницу надо закешировать на скажем 20
> секунд выдавая заголовок X-Accel-Expires: 20.
> это классная фича!
> 
> но вот если посмотреть на любой сайт с кешированием, то можно увидеть
> что какую-то информацию мы можем выдать в кеш, но при этом кеш валиден
> будет *до определенного действия пользователя*.
> 
> например (утопический пример) мы на сайте кешируем список
> пользователей написавших больше всего сообщений (ТОП по
> пользователям).
> понятное дело, такой ТОП меняется редко и можно смело ему выдать
> скажем 10 минут время жизни кеша и все будет хорошо.
> но допустим у нас задача есть чтобы этот ТОП выводился более
> качественно. становится ТОП'ом другой пользователь (входит в ТОП10) и
> сразу картинка перестраивается (без лага в 0-10 минут).
> 
> для такой задачи просто определение времени жизни кеширования из
> бакенда не подойдет. еще нужно иметь возможность сказать что кеш
> невалиден nginx'у. 
> 
> и вот тут фичареквест добавить опцию (насколько я понимаю не должно
> быть сложным):
> 
> у нас есть один хидер на управление кешом:
> 
> X-Accel-Expires: [ секунд | @секунд ]
> 
> - определяет сколько времени данная страница может находиться в кеше
> 
> а можно сюда добавить еще хидер, например:
> 
> X-Cache-Invalid: "/users/top/123?all=yes"
> 
> - определяет что с данного момента определенный набор страниц
>   находящихся в кеше (набор = если несколько таких заголовков выдали)
>   невалиден.
> 
> Тогда если бакенд выдал такой заголовок (или несколько таких
> заголовков), чтобы nginx по факту выдачи такого ответа сбросил кеши,
> связанные с данными урлами?

Помнится мне, когда-то давно Игорь писал в рассылку, что планирует 
нечто подобное сделать.  А сейчас даже есть draft RFC на 
аналогичную тему, тут:

http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-04

Я, правда, сомневаюсь, что draft взлетит, но вообще 
функциональность, как мне кажется, интересная.

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

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


From unera at uvw.ru  Fri Jul 26 16:44:06 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Fri, 26 Jul 2013 20:44:06 +0400
Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?=
 =?UTF-8?B?0LXQutCy0LXRgdGC?=
In-Reply-To: <CAAwq3jy5YxeYVFzEvNz6KnXj4Z0XXkq68ZR-LUGR3EfKvfniKw@mail.gmail.com>
References: <20130726075333.GQ30025@vdsl.uvw.ru>
 <CAAwq3jwTjV1OGxNQXpHmiJ+DUnj8ynkCMz70MmwhiA3HwkwKLQ@mail.gmail.com>
 <20130726130734.GT30025@vdsl.uvw.ru>
 <CAAwq3jy5YxeYVFzEvNz6KnXj4Z0XXkq68ZR-LUGR3EfKvfniKw@mail.gmail.com>
Message-ID: <20130726164406.GU30025@vdsl.uvw.ru>

>>> удалить элемент из кеша можно директивой
>>> http://nginx.org/r/proxy_cache_bypass/ru по ключу (т.е. новый элемент
>>> возмётся не из кеша, но закешируется)
>> 
>> нет это совсем не то что в фичареквесте.
>> 
> ...
>> 
>> я хочу получить механизм внутри обработчика сбросить кеш на другом
>> роуте.
>> как вариант - выдать хидер с урлом кеш на котором надо сбросить.
>> 
>> а директивы в конфиге = это не программа это набор условий :)
>> 
> я раньше решал похожую проблему с помощью модуля ngx_cache_purge (
> http://wiki.nginx.org/CachePurgeChs ). создавал в nginx специальный
> локейшн (/purge/), при обращении к которому удалялся из кеша указанный
> элемент. Т.е. после изменения в базе, запрос по этому локейшну делает
> само приложение (для wordpress есть специальный плагин). Подробнее (с
> конфигами) можно почитать тут:

> http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html
> http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html

> но теперь, я бы попытался реализовать соответствующий функционал без
> стороннего модуля, а только директивой proxy_cache_bypass.

> Таким образом, применяя предложенную мной схему, вместо того чтобы
> просто отдать nginx страницу с заголовком X-Cache-Invalid:
> "/users/top/123?all=yes", вам придётся сначала сделать запрос из
> приложения по адресу /purge/users/top/123?all=yes и элемент кеша
> обновится.

тогда уж проще идти по следующему пути:
1. настраиваем nginx на работу с мемкешом
2. реализуем в приложении тот же алгоритм взятия md5sum от урла что и
в nginx (чтобы получать id ключа в мемкеше)
3. удаляем ключи в мемкеше если надо
4. PROFIT

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

а вот зная четко что у бакенда с nginx уже установлена связь (отвечать
бакенд должен) то выдать по этой связи инструкцию управления кешом по
моему наиболее просто. 
а управлять кешом по урлам - это для кронскриптов/демонов/прочих
скриптов.
-- 

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130726/8083223f/attachment-0001.bin>

From unera at uvw.ru  Fri Jul 26 16:58:22 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Fri, 26 Jul 2013 20:58:22 +0400
Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?=
 =?UTF-8?B?0LXQutCy0LXRgdGC?=
In-Reply-To: <20130726145113.GR90722@mdounin.ru>
References: <20130726075333.GQ30025@vdsl.uvw.ru>
 <20130726145113.GR90722@mdounin.ru>
Message-ID: <20130726165822.GV30025@vdsl.uvw.ru>

>> X-Cache-Invalid: "/users/top/123?all=yes"
>> 
>> - определяет что с данного момента определенный набор страниц
>>   находящихся в кеше (набор = если несколько таких заголовков выдали)
>>   невалиден.
>> 
>> Тогда если бакенд выдал такой заголовок (или несколько таких
>> заголовков), чтобы nginx по факту выдачи такого ответа сбросил кеши,
>> связанные с данными урлами?

> Помнится мне, когда-то давно Игорь писал в рассылку, что планирует
> нечто подобное сделать.  А сейчас даже есть draft RFC на
> аналогичную тему, тут:

> http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-04

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

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

кстати почитав RFC можно дополнить:

хорошо бы не просто выпиливать конкретные страницы из кеша, а еще и
выпиливать их по маске

типа Invalid: /users/list/[1-9][0-9]*/abc

но это будет конфликтовать конечно с тем что в качестве ключа в БД
используется md5 от урла а не урл

> Я, правда, сомневаюсь, что draft взлетит, но вообще
> функциональность, как мне кажется, интересная.

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


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

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

народ, кто взялся бы такой плагин написать?
я бы мог инвестировать в него, скажем 500$ из своих скромных личных
средств :)

или лучше патч, чтобы его в апстрим положить :)
-- 

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130726/e269b9e0/attachment.bin>

From unera at uvw.ru  Fri Jul 26 17:01:16 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Fri, 26 Jul 2013 21:01:16 +0400
Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?=
 =?UTF-8?B?0LXQutCy0LXRgdGC?=
In-Reply-To: <CAAwq3jy5YxeYVFzEvNz6KnXj4Z0XXkq68ZR-LUGR3EfKvfniKw@mail.gmail.com>
References: <20130726075333.GQ30025@vdsl.uvw.ru>
 <CAAwq3jwTjV1OGxNQXpHmiJ+DUnj8ynkCMz70MmwhiA3HwkwKLQ@mail.gmail.com>
 <20130726130734.GT30025@vdsl.uvw.ru>
 <CAAwq3jy5YxeYVFzEvNz6KnXj4Z0XXkq68ZR-LUGR3EfKvfniKw@mail.gmail.com>
Message-ID: <20130726170116.GW30025@vdsl.uvw.ru>

>> нет это совсем не то что в фичареквесте.
>> 
> ...
>> 
>> я хочу получить механизм внутри обработчика сбросить кеш на другом
>> роуте.
>> как вариант - выдать хидер с урлом кеш на котором надо сбросить.
>> 
>> а директивы в конфиге = это не программа это набор условий :)
>> 
> я раньше решал похожую проблему с помощью модуля ngx_cache_purge (
> http://wiki.nginx.org/CachePurgeChs ). создавал в nginx специальный
> локейшн (/purge/), при обращении к которому удалялся из кеша указанный
> элемент. Т.е. после изменения в базе, запрос по этому локейшну делает
> само приложение (для wordpress есть специальный плагин). Подробнее (с
> конфигами) можно почитать тут:

> http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html
> http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html

> но теперь, я бы попытался реализовать соответствующий функционал без
> стороннего модуля, а только директивой proxy_cache_bypass.

proxy_cache_bypass ведь не дает того функционала о котором я говорю:
когда один роут сбрасывает кеш на другом роуте.

> Таким образом, применяя предложенную мной схему, вместо того чтобы
> просто отдать nginx страницу с заголовком X-Cache-Invalid:
> "/users/top/123?all=yes", вам придётся сначала сделать запрос из
> приложения по адресу /purge/users/top/123?all=yes и элемент кеша
> обновится.

я посмотрю внутрь модуля. сложно его доработать до того функционала
что я говорю?

-- 

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130726/5c896616/attachment.bin>

From unera at uvw.ru  Sat Jul 27 21:54:40 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Sun, 28 Jul 2013 01:54:40 +0400
Subject: =?UTF-8?B?0JrQtdGI0LjRgNC+0LLQsNC90LjQtSDQv9GA0L7QsdC70LXQvNCwOiDQv9C10YA=?=
 =?UTF-8?B?0LXRgdGC0LDQtdGCINC60LXRiNC40YDQvtCy0LDRgtGM?=
Message-ID: <20130727215440.GA7614@vdsl.uvw.ru>

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

nginx 1.2.1

конфиг такой:

proxy_cache_path /var/lib/nginx/proxy levels=1:2 keys_zone=proxy:30m max_size=1G;

    location ~ /cached/ {
        proxy_pass                              http://backend;
        proxy_cache proxy;
        proxy_buffering                         on;
        proxy_cache_valid                       200     60m;
        proxy_cache_lock                        on;
        proxy_method                            GET;
        proxy_cache_use_stale                   updating;

        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header    Host            $host;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header  "X-Taxi-Location" "/cached";

        proxy_set_header    Cookie '';
        proxy_ignore_headers 'Set-Cookie';
        proxy_cache_key $uri;
        proxy_hide_header 'Set-Cookie';

        expires off;
    }


Все запросы что имеют в урле /cached/ кешируются на 60m

Но есть проблема.
пока нагрузка небольшая все замечательно:

смотрим логи nginx (grep /cached/) а так же смотрим логи бакенда
(такой же греп). Видим что на nginx приходят сотни запросов, а на
бакенд (апач) единицы.
Все хорошо.

затем повышаем нагрузку и где-то на 100-500 запросов в секунду на апач
начинают "просачиваться" запросы минуя кеш.

то есть нормальное соотношение у нас там если он все кеширует = где-то
1000:1 (то есть на 1000 запросов nginx приходится один на бакенд).

но при работе под нагрузкой соотношение меняется к 1000:500 и местами
даже к 1000:800.
На апаче вижу строго одинаковые запросы (он эту нагрузку держит,
отдает 200'ки). в tcpdump никаких заголовков, касающихся кеша не вижу.
апач всегда выдает заголовок x-accel-expires: 600 для всех ответов по
роуту /cached/.

в error логе nginx ошибок никаких про кеш нет.

правда на старте выдает вот такую фигатень:

2013/07/27 23:53:32 [info] 9945#0: Using 32768KiB of shared memory for push module in /etc/nginx/nginx.conf:65
2013/07/27 23:53:32 [alert] 9952#0: epoll_ctl(1, 0) failed (1: Operation not permitted)
2013/07/27 23:53:32 [alert] 9952#0: failed to register channel handler while initializing push module worker (1: Operation not permitted)
2013/07/27 23:53:32 [alert] 9953#0: epoll_ctl(1, 0) failed (1: Operation not permitted)
2013/07/27 23:53:32 [alert] 9953#0: failed to register channel handler while initializing push module worker (1: Operation not permitted)
2013/07/27 23:53:32 [alert] 2232#0: cache manager process 9952 exited with fatal code 2 and cannot be respawned

В какую сторону покопать?


-- 

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130728/a4b325cd/attachment.bin>

From unera at uvw.ru  Sat Jul 27 23:11:23 2013
From: unera at uvw.ru (Dmitry E. Oboukhov)
Date: Sun, 28 Jul 2013 03:11:23 +0400
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?=
 =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?=
In-Reply-To: <20130727215440.GA7614@vdsl.uvw.ru>
References: <20130727215440.GA7614@vdsl.uvw.ru>
Message-ID: <20130727231123.GC7614@vdsl.uvw.ru>

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

> nginx 1.2.1

ушел от nginx-extras в nginx-light (Debian) проблема исчезла.
видимо какой-то сторонний модуль говнял :(
-- 

. ''`.                               Dmitry E. Oboukhov
: :?  :   email: unera at debian.org jabber://UNera at uvw.ru
`. `~?              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130728/64b68241/attachment.bin>

From maxout.mail at gmail.com  Mon Jul 29 13:02:21 2013
From: maxout.mail at gmail.com (Ktulhu Ftagn)
Date: Mon, 29 Jul 2013 20:02:21 +0700
Subject: =?UTF-8?B?0JrQsNC6INC/0L7Qu9GD0YfQuNGC0Ywg0L7RgiBQSFAtRlBNINC60L7QtCDQvtGI?=
 =?UTF-8?B?0LjQsdC60LgsINC+0YLQu9C40YfQvdGL0Lkg0L7RgiAyMDAsINC/0YDQuCBQ?=
 =?UTF-8?B?SFAgRmF0YWwgZXJyb3I/?=
Message-ID: <CAOheUCpJjNmGsySqW8JXRZqA5GvacNkhbmWW8e7nCg8tGcU0LQ@mail.gmail.com>

Дано: Nginx 1.4.1, PHP-FPM 5.3.27
При возникновении в PHP фатальной ошибки вебсервер возвращает текст ошибки
и код 200.

Прописываем в nginx fastcgi_catch_stderr <<PHP Fatal error:>>;

Теперь при фатальной ошибке возвращается код 502 Bad Gateway, но на этот
раз текста ошибки нет.

Нужно: возвращать ошибочный код и выводить саму ошибку PHP в браузер, как
это делает апач.

Вопрос: как?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130729/0f0d4b5c/attachment.html>

From mdounin at mdounin.ru  Tue Jul 30 13:41:20 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 30 Jul 2013 17:41:20 +0400
Subject: nginx-1.5.3
Message-ID: <20130730134120.GK2130@mdounin.ru>

Изменения в nginx 1.5.3                                           30.07.2013

    *) Изменение во внутреннем API: теперь при небуферизированной работе с
       бэкендами u->length по умолчанию устанавливается в -1.

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

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если использовался модуль ngx_http_spdy_module и директива
       client_body_in_file_only.

    *) Исправление: параметр so_keepalive директивы listen мог работать
       некорректно на DragonFlyBSD.
       Спасибо Sepherosa Ziehau.

    *) Исправление: в модуле ngx_http_xslt_filter_module.

    *) Исправление: в модуле ngx_http_sub_filter_module.


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


From nginx-forum at nginx.us  Wed Jul 31 08:06:27 2013
From: nginx-forum at nginx.us (Antohat)
Date: Wed, 31 Jul 2013 04:06:27 -0400
Subject: =?UTF-8?B?Tmdpbngg0LjRgdC/0L7Qu9GM0LfRg9C10YIgSVB2NiDQsiBwcm94eSBwYXNzLCA=?=
 =?UTF-8?B?0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?=
Message-ID: <13ff5e25e82398ab0490d0b6ac968657.NginxMailingListRussian@forum.nginx.org>

Добрый день,

На сервере отключен IPv6. На nginx настроено проксирование на upstream c
поддержкой IPv4 и IPv6.

Nginx периодически (раз в 5 секунд) пытается отправлять запросы на IPv6 и
соответственно обламывается с ошибками:

2013/07/30 00:25:06 [error] 1930#0: *1482670 connect() to
[AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443 failed (101: Network is unreachable) while
connecting to upstream, client: AA.BB.CC.DD, server: example.com, request:
"GET /download/file HTTP/1.0", upstream:
"https://[AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443/download/file", host:
"example.com"

Как можно отключить IPv6 для proxy_pass?

# nginx.conf:
upstream download {
  server download.example.com:443;
  keepalive 8;
}

location /download {
  proxy_set_header      X-Forwarded-For  $proxy_add_x_forwarded_for;
  proxy_set_header      Connection "";
  proxy_ignore_headers  X-Accel-Redirect;
  proxy_http_version    1.1;
  resolver              8.8.8.8;
  resolver_timeout      5s;
  proxy_pass            https://download;
}

nginx -V: 
nginx version: nginx/1.4.2
built by gcc 4.7.2 (Debian 4.7.2-5)
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-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,-z,relro
--with-ipv6

uname -a:
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux

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


From ru at nginx.com  Wed Jul 31 08:46:05 2013
From: ru at nginx.com (Ruslan Ermilov)
Date: Wed, 31 Jul 2013 12:46:05 +0400
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?=
In-Reply-To: <13ff5e25e82398ab0490d0b6ac968657.NginxMailingListRussian@forum.nginx.org>
References: <13ff5e25e82398ab0490d0b6ac968657.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130731084605.GE96850@lo0.su>

On Wed, Jul 31, 2013 at 04:06:27AM -0400, Antohat wrote:
> Добрый день,
> 
> На сервере отключен IPv6. На nginx настроено проксирование на upstream c
> поддержкой IPv4 и IPv6.
> 
> Nginx периодически (раз в 5 секунд) пытается отправлять запросы на IPv6 и
> соответственно обламывается с ошибками:
> 
> 2013/07/30 00:25:06 [error] 1930#0: *1482670 connect() to
> [AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443 failed (101: Network is unreachable) while
> connecting to upstream, client: AA.BB.CC.DD, server: example.com, request:
> "GET /download/file HTTP/1.0", upstream:
> "https://[AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443/download/file", host:
> "example.com"
> 
> Как можно отключить IPv6 для proxy_pass?

Как-то заставить системный resolver(3) не возвращать IPv6-адреса (ответы
типа AAAA) для хоста, на котором отключен IPv6.  Попробуйте добиться
желаемого эффекта с командой

	telnet download.example.com

Или же использовать IPv4-адреса в конфигурации nginx.  Кстати, в
приведенной конфигурации директива resolver не нужна.

> # nginx.conf:
> upstream download {
>   server download.example.com:443;
>   keepalive 8;
> }
> 
> location /download {
>   proxy_set_header      X-Forwarded-For  $proxy_add_x_forwarded_for;
>   proxy_set_header      Connection "";
>   proxy_ignore_headers  X-Accel-Redirect;
>   proxy_http_version    1.1;
>   resolver              8.8.8.8;
>   resolver_timeout      5s;
>   proxy_pass            https://download;
> }
> 
> nginx -V: 
> nginx version: nginx/1.4.2
> built by gcc 4.7.2 (Debian 4.7.2-5)
> 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-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,-z,relro
> --with-ipv6
> 
> uname -a:
> Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241403,241403#msg-241403


From admin at sysadmins.el.kg  Wed Jul 31 08:54:25 2013
From: admin at sysadmins.el.kg (admin at sysadmins.el.kg)
Date: Wed, 31 Jul 2013 14:54:25 +0600
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?=
In-Reply-To: <13ff5e25e82398ab0490d0b6ac968657.NginxMailingListRussian@forum.nginx.org>
References: <13ff5e25e82398ab0490d0b6ac968657.NginxMailingListRussian@forum.nginx.org>
Message-ID: <51F8D0C1.3060609@sysadmins.el.kg>

31.07.2013 14:06, Antohat пишет:
> Добрый день,
>
> На сервере отключен IPv6. На nginx настроено проксирование на upstream c
> поддержкой IPv4 и IPv6.
>
> Nginx периодически (раз в 5 секунд) пытается отправлять запросы на IPv6 и
> соответственно обламывается с ошибками:
>
> 2013/07/30 00:25:06 [error] 1930#0: *1482670 connect() to
> [AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443 failed (101: Network is unreachable) while
> connecting to upstream, client: AA.BB.CC.DD, server: example.com, request:
> "GET /download/file HTTP/1.0", upstream:
> "https://[AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443/download/file", host:
> "example.com"
>
> Как можно отключить IPv6 для proxy_pass?
>
> # nginx.conf:
> upstream download {
>    server download.example.com:443;
>    keepalive 8;
> }
>
> location /download {
>    proxy_set_header      X-Forwarded-For  $proxy_add_x_forwarded_for;
>    proxy_set_header      Connection "";
>    proxy_ignore_headers  X-Accel-Redirect;
>    proxy_http_version    1.1;
>    resolver              8.8.8.8;
>    resolver_timeout      5s;
>    proxy_pass            https://download;
> }
>
> nginx -V:
> nginx version: nginx/1.4.2
> built by gcc 4.7.2 (Debian 4.7.2-5)
> 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-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,-z,relro
> --with-ipv6
>
> uname -a:
> Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241403,241403#msg-241403
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
Вы используете ipv6? Если нет - попробуйте отключить его в системе. 
Выполните:
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.lo.disable_ipv6=1

и перезапустив nginx попробуйте воспроизвести ошибку. Если ошибка не 
воспроизведется - добавьте в /etc/sysctl.conf это:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1


From nginx-forum at nginx.us  Wed Jul 31 10:10:55 2013
From: nginx-forum at nginx.us (Antohat)
Date: Wed, 31 Jul 2013 06:10:55 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?=
In-Reply-To: <20130731084605.GE96850@lo0.su>
References: <20130731084605.GE96850@lo0.su>
Message-ID: <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>

Ruslan Ermilov Wrote:
-------------------------------------------------------
> Как-то заставить системный resolver(3) не возвращать IPv6-адреса
> (ответы
> типа AAAA) для хоста, на котором отключен IPv6.  Попробуйте добиться
> желаемого эффекта с командой
> 
> 	telnet download.example.com
Не уверен, что так можно сделать...
Может быть было бы правильнее, чтобы nginx определял, что IPv6 не настроен и
не пытался использовать записи AAAA?
По крайней мере такой параметр в конфиге точно не был бы лишним.

> Или же использовать IPv4-адреса в конфигурации nginx.  Кстати, в
> приведенной конфигурации директива resolver не нужна.
К сожалению не можем, т.к. IP апстрима могут меняться без предварительного
уведомления.

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


From nginx-forum at nginx.us  Wed Jul 31 10:13:10 2013
From: nginx-forum at nginx.us (Antohat)
Date: Wed, 31 Jul 2013 06:13:10 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?=
In-Reply-To: <51F8D0C1.3060609@sysadmins.el.kg>
References: <51F8D0C1.3060609@sysadmins.el.kg>
Message-ID: <81f90ef0c9aceeafa4458a8904a768e6.NginxMailingListRussian@forum.nginx.org>

Raven_kg Wrote:
-------------------------------------------------------
> Вы используете ipv6? Если нет - попробуйте отключить его в системе. 
> Выполните:
> sysctl -w net.ipv6.conf.all.disable_ipv6=1
> sysctl -w net.ipv6.conf.default.disable_ipv6=1
> sysctl -w net.ipv6.conf.lo.disable_ipv6=1
> 
> и перезапустив nginx попробуйте воспроизвести ошибку. Если ошибка не 
> воспроизведется - добавьте в /etc/sysctl.conf это:
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> 
У нас уже была установлена опция net.ipv6.conf.all.disable_ipv6=1
Добавление net.ipv6.conf.default.disable_ipv6=1 и
net.ipv6.conf.lo.disable_ipv6=1 не помогает.

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


From vbart at nginx.com  Wed Jul 31 10:56:15 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Wed, 31 Jul 2013 14:56:15 +0400
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywgINC00LDQttC1INC10YHQu9C4INC+0L0g0L7RgtC60LvRjtGH0LXQvQ==?=
In-Reply-To: <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>
References: <20130731084605.GE96850@lo0.su>
 <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201307311456.15668.vbart@nginx.com>

On Wednesday 31 July 2013 14:10:55 Antohat wrote:
[...]
> > Или же использовать IPv4-адреса в конфигурации nginx.  Кстати, в
> > приведенной конфигурации директива resolver не нужна.
> 
> К сожалению не можем, т.к. IP апстрима могут меняться без предварительного
> уведомления.
> 

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

--
Валентин Бартенев
http://nginx.org/en/donation.html

From ru at nginx.com  Wed Jul 31 10:59:08 2013
From: ru at nginx.com (Ruslan Ermilov)
Date: Wed, 31 Jul 2013 14:59:08 +0400
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?=
In-Reply-To: <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>
References: <20130731084605.GE96850@lo0.su>
 <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130731105908.GI96850@lo0.su>

On Wed, Jul 31, 2013 at 06:10:55AM -0400, Antohat wrote:
> Ruslan Ermilov Wrote:
> -------------------------------------------------------
> > Как-то заставить системный resolver(3) не возвращать IPv6-адреса
> > (ответы
> > типа AAAA) для хоста, на котором отключен IPv6.  Попробуйте добиться
> > желаемого эффекта с командой
> > 
> > 	telnet download.example.com
> Не уверен, что так можно сделать...
> Может быть было бы правильнее, чтобы nginx определял, что IPv6 не настроен и
> не пытался использовать записи AAAA?

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

> По крайней мере такой параметр в конфиге точно не был бы лишним.

А ещё хорошо иметь настройку в nginx.conf, которая проверяет,
что утюг дома не забыли выключить.  :)

> > Или же использовать IPv4-адреса в конфигурации nginx.  Кстати, в
> > приведенной конфигурации директива resolver не нужна.
> К сожалению не можем, т.к. IP апстрима могут меняться без предварительного
> уведомления.

Ну соберите nginx без --with-ipv6, и будет вам счастье.


From boco at ufanet.ru  Wed Jul 31 11:01:38 2013
From: boco at ufanet.ru (damir bikmuhametov)
Date: Wed, 31 Jul 2013 17:01:38 +0600
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywgINC00LDQttC1INC10YHQu9C4INC+0L0g0L7RgtC60LvRjtGH0LXQvQ==?=
In-Reply-To: <201307311456.15668.vbart@nginx.com>
References: <20130731084605.GE96850@lo0.su>
 <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>
 <201307311456.15668.vbart@nginx.com>
Message-ID: <20130731110138.GO85229@ufanet.ru>

топикстартеру:

если резолвер под вашим управлением, то, возможно, поможет следующее
обсуждение: http://comments.gmane.org/gmane.network.dns.operations/1538

-- 
boco


From admin at sysadmins.el.kg  Wed Jul 31 11:03:42 2013
From: admin at sysadmins.el.kg (admin at sysadmins.el.kg)
Date: Wed, 31 Jul 2013 17:03:42 +0600
Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?=
 =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?=
In-Reply-To: <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>
References: <20130731084605.GE96850@lo0.su>
 <fc39bee93f8239329e125cbd1cbdb60b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <51F8EF0E.3020505@sysadmins.el.kg>

31.07.2013 16:10, Antohat пишет:
> Ruslan Ermilov Wrote:
> -------------------------------------------------------
>> Как-то заставить системный resolver(3) не возвращать IPv6-адреса
>> (ответы
>> типа AAAA) для хоста, на котором отключен IPv6.  Попробуйте добиться
>> желаемого эффекта с командой
>>
>> 	telnet download.example.com
> Не уверен, что так можно сделать...
> Может быть было бы правильнее, чтобы nginx определял, что IPv6 не настроен и
> не пытался использовать записи AAAA?
> По крайней мере такой параметр в конфиге точно не был бы лишним.
>
>> Или же использовать IPv4-адреса в конфигурации nginx.  Кстати, в
>> приведенной конфигурации директива resolver не нужна.
> К сожалению не можем, т.к. IP апстрима могут меняться без предварительного
> уведомления.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241405,241407#msg-241407
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
Заюзайте резольвер не поддерживающий AAAA.


From sergey.kobzar at itcraft.org  Wed Jul 31 21:07:32 2013
From: sergey.kobzar at itcraft.org (Sergey Kobzar)
Date: Thu, 01 Aug 2013 00:07:32 +0300
Subject: Nginx and logrotate
Message-ID: <51F97C94.30303@itcraft.org>

Linux 3.8.13-gentoo x86_64
nginx-1.4.1-r2
logrotate-3.8.4

cat /etc/logrotate.d/nginx:
/var/log/nginx/*.log {
         daily
         rotate 5
         missingok
         nocompress
         sharedscripts
         postrotate
                 test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid`
         endscript
}

/etc/logrotate.conf:
weekly
rotate 4
create
dateext
compress
notifempty
nomail
noolddir
include /etc/logrotate.d
/var/log/wtmp {
     monthly
     create 0664 root utmp
         minsize 1M
     rotate 1
}
/var/log/btmp {
     missingok
     monthly
     create 0600 root utmp
     rotate 1
}

# ls -alh /var/log/nginx/ | grep access.log
-rw-r--r--  1 nginx root    0 Jul 30 03:10 access.log
-rw-r--r--  1 nginx root 4.7G Jul 18 10:09 access.log-20130712
-rw-r--r--  1 nginx root 7.6G Jul 29 09:46 access.log-20130719
-rw-r--r--  1 nginx root 1.4G Jul 31 22:04 access.log-20130730

Т.е. запись в access.log не идет, а растет access.log-20130730.

kill -USR1 `cat /run/nginx.pid` ситуацию не меняет.

Что я не так?

Спасибо.


From vbart at nginx.com  Wed Jul 31 22:14:30 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Thu, 1 Aug 2013 02:14:30 +0400
Subject: Nginx and logrotate
In-Reply-To: <51F97C94.30303@itcraft.org>
References: <51F97C94.30303@itcraft.org>
Message-ID: <201308010214.30476.vbart@nginx.com>

On Thursday 01 August 2013 01:07:32 Sergey Kobzar wrote:
> Linux 3.8.13-gentoo x86_64
> nginx-1.4.1-r2
> logrotate-3.8.4
> 
> cat /etc/logrotate.d/nginx:
> /var/log/nginx/*.log {
>          daily
>          rotate 5
>          missingok
>          nocompress
>          sharedscripts
>          postrotate
>                  test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid`
>          endscript
> }
> 
> /etc/logrotate.conf:
> weekly
> rotate 4
> create
> dateext
> compress
> notifempty
> nomail
> noolddir
> include /etc/logrotate.d
> /var/log/wtmp {
>      monthly
>      create 0664 root utmp
>          minsize 1M
>      rotate 1
> }
> /var/log/btmp {
>      missingok
>      monthly
>      create 0600 root utmp
>      rotate 1
> }
> 
> # ls -alh /var/log/nginx/ | grep access.log
> -rw-r--r--  1 nginx root    0 Jul 30 03:10 access.log
> -rw-r--r--  1 nginx root 4.7G Jul 18 10:09 access.log-20130712
> -rw-r--r--  1 nginx root 7.6G Jul 29 09:46 access.log-20130719
> -rw-r--r--  1 nginx root 1.4G Jul 31 22:04 access.log-20130730
> 
> Т.е. запись в access.log не идет, а растет access.log-20130730.
> 
> kill -USR1 `cat /run/nginx.pid` ситуацию не меняет.
> 
> Что я не так?
> 

https://bugs.gentoo.org/show_bug.cgi?id=473036

--
Валентин Бартенев
http://nginx.org/en/donation.html