видимо rewrite и location
день добрый. перечитал форум, перепробовал кучу вариантов, но не правильно
мыслю видимо совершенно.
есть задача из редиректов апача, перевести в синтаксис нгикса.
например.
RewriteRule ^/pro/neon/?n1=1&n2=2&n3=3$ /pro/neon/ [L,R=301]
сначала шёл простым путём, пробовал конвертерами, код получается не
правильный. позже читал форум, варианты шли примерно вот такие:
location = /pro/neon/ { rewrite ^/pro/neon/?n1=1&n2=2&n3=3$
http://xxx.ru/pro/neon/? redirect; }
или
location = /pro/neon/ { if ($args ~ ^n1){return 301
http://xxx.ru/pro/neon/;} }
в общем-то практически все варианты возвращают 404 и в логах
"/usr/local/etc/nginx/html/pro/neon/index.html" is not found (2: No such
file or directory)
спасибо
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,27,27#msg-27
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Максим, спасибо за ваш ответ.
Я попробовал сделать апгрейд nginx по вашему замечанию, чтобы сузить
область поиска ошибки.
На данный момент у меня сборка следующая:
nginx version: nginx/1.5.6
built by gcc 4.4.5 (Debian 4.4.5-8)
TLS SNI support enabled
configure arguments: --with-openssl=/usr/build/openssl-1.0.1e
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug
--with-http_flv_module --with-http_geoip_module
--with-http_gzip_static_module --with-http_realip_module
--with-http_stub_status_module --with-http_ssl_module
--with-http_sub_module --with-mail --with-mail_ssl_module
--add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module
--with-http_auth_request_module
Все симптомы остались прежними.
CGI скрипты нагиоса работают через такую связку отлично, как и ранее.
однако, другие приложения (owncloud, roundcube) требуют "медленного"
прохода.
Ещё сделал различие, что нагиос работает везде GET запросами, в то время,
как owncloud, jenkins, roundcube делают периодически POST
Возможно, это неверно как-то обрабатывается.
Дополнительно, я попытался смягчить условия для мониторинга, прописал в
http секцию
geo $ip_range {
default 0;
192.168.125.0/24 1;
}
и в секциях server/location
set $auth_location /auth/;
if ( $ip_range = 1 ) {
set $auth_location /always_ok;
}
location = /always_ok {
return 200;
}
location /jenkins {
auth_request $auth_location;
proxy_pass http://192.168.125.37:8080;
proxy_buffering on;
proxy_set_headerSSL NO;
proxy_set_headerHost $host;
proxy_set_headerX-Real-IP $remote_addr;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 1800;
}
такая связка не работает.
Ошибка в логе всё та же. auth_request зачем-то ищет файл $auth_location а
не делает подзапрос в локейшн возращаемый переменной.
2013/11/05 13:17:13 [error] 32126#0: *1243 open()
"/usr/local/nginx/html$auth_location" failed (2: No such file or
directory), client: 185.6.244.255, server: ssl.stremki.net, request: "GET
/jenkins/login?from=%2Fjenkins%2F HTTP/1.1", subrequest: "$auth_location",
host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/";
2013/11/05 13:17:13 [error] 32126#0: *1243 auth request unexpected status:
404, client: 185.6.244.255, server: ssl.stremki.net, request: "GET
/jenkins/login?from=%2Fjenkins%2F HTTP/1.1", host: "ssl.stremki.net",
referrer: "https://ssl.stremki.net/jenkins/";
Я включил дебаг для своего адреса. Вот, его вывод.
http://pastebin.com/aKDG4gYk
Буду благодарен за помощь.
2013/11/5 Maxim Dounin
> Hello!
>
> On Sat, Nov 02, 2013 at 10:21:39PM +0400, Dzmitry Stremkouski wrote:
>
> > Я установил nginx и модуль Максима Дунина (ngx_http_auth_request_module)
> > Настройку этого модуля производил по README от модуля.
> > Сам вебсервер собрал с такими параметрами в дебиане:
> >
> > nginx version: nginx/1.3.14
>
> Порекомендую начать с простого. Не надо использовать 1.3.14, это
> старая и неподдерживаемая версия. Надо взять 1.5.6, где
> соответствующий модуль в коробке.
>
> [...]
>
> > Я пытался делать без проксирования, указывая URI
> > auth_request http://192.168.125.35/auth/
> > Но это не работало и я в логах nginx видел ошибку
> > 2013/11/01 23:31:51 [error] 10938#0: *245 "/usr/local/nginx/htmlhttp://
> > 192.168.125.35/auth/index.html" is not found (2: No such file or
> > directory), client: 192.168.125.47, server: ssl.stremki.net, request:
> "GET
> > /mail/ HTTP/1.1", subrequest: "http://192.168.125.35/auth/";, host: "
> > ssl.stremki.net"
> >
> > Было бы здорово, если бы я смог работать без проксирования /auth/.
> > Просто, пока не понял, как прописать внутренний бекенд для обработки и
> > сейчас
> > пользуюсь локейшном /auth/ в режиме проксирования.
>
> Модуль auth_request не пытается реализовывать каких-либо
> протколов сам, он просто делает подзапрос. Точно так же, как это
> делает SSI или модуль addition.
>
> Настроить необходимую обработку для соответствующего URI, который
> вы используете в auth_request - ваша задача, будь то проксирование
> или что-либо ещё.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Здравствуйте.
location /jenkins {
auth_request /auth;
...
}
location = /auth {
internal;
if ($ip_range) {
return 200;
}
proxy_pass http://your_authentication_backend;
...
}
?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Вадим, здравствуйте!
Я могу сделать его internal, но мне этот локейшн нужен извне, также.
Или от этого ломается логика модуля Максима?
On Tue, Nov 5, 2013 at 3:13 PM, Vadim Lazovskiy
wrote:
> Здравствуйте.
>
> location /jenkins {
> auth_request /auth;
>
> ...
> }
>
> location = /auth {
> internal;
>
> if ($ip_range) {
> return 200;
> }
>
> proxy_pass http://your_authentication_backend;
> ...
> }
>
> ?
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
--
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Должно работать и без internal
5 ноября 2013 г., 15:14 пользователь Dzmitry Stremkouski
написал:
> Вадим, здравствуйте!
> Я могу сделать его internal, но мне этот локейшн нужен извне, также.
> Или от этого ломается логика модуля Максима?
>
>
> On Tue, Nov 5, 2013 at 3:13 PM, Vadim Lazovskiy > wrote:
>
>> Здравствуйте.
>>
>> location /jenkins {
>> auth_request /auth;
>>
>> ...
>> }
>>
>> location = /auth {
>> internal;
>>
>> if ($ip_range) {
>> return 200;
>> }
>>
>> proxy_pass http://your_authentication_backend;
>> ...
>> }
>>
>> ?
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
>
> (o_ - Dzmitry Stremkouski.
> //\ - cel: +7 (916) 090-85-68
> V_/_- web: http://mitroko.com
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
--
Best Regards,
Vadim Lazovskiy
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Хотя, ваша конструкция
if ($ip_range) {
return 200;
}
помогла решить проблему мониторинга.
RoundCube пока не работает через /auth/.
Спасибо!
2013/11/5 Dzmitry Stremkouski
> Вадим, здравствуйте!
> Я могу сделать его internal, но мне этот локейшн нужен извне, также.
> Или от этого ломается логика модуля Максима?
>
>
> On Tue, Nov 5, 2013 at 3:13 PM, Vadim Lazovskiy > wrote:
>
>> Здравствуйте.
>>
>> location /jenkins {
>> auth_request /auth;
>>
>> ...
>> }
>>
>> location = /auth {
>> internal;
>>
>> if ($ip_range) {
>> return 200;
>> }
>>
>> proxy_pass http://your_authentication_backend;
>> ...
>> }
>>
>> ?
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
>
> (o_ - Dzmitry Stremkouski.
> //\ - cel: +7 (916) 090-85-68
> V_/_- web: http://mitroko.com
>
>
--
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Hello!
On Tue, Nov 05, 2013 at 02:40:17PM +0400, Dzmitry Stremkouski wrote:
> Максим, спасибо за ваш ответ.
> Я попробовал сделать апгрейд nginx по вашему замечанию, чтобы сузить
> область поиска ошибки.
>
> На данный момент у меня сборка следующая:
> nginx version: nginx/1.5.6
> built by gcc 4.4.5 (Debian 4.4.5-8)
> TLS SNI support enabled
> configure arguments: --with-openssl=/usr/build/openssl-1.0.1e
> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
> --http-client-body-temp-path=/var/lib/nginx/body
> --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
> --http-log-path=/var/log/nginx/access.log
> --http-proxy-temp-path=/var/lib/nginx/proxy
> --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug
> --with-http_flv_module --with-http_geoip_module
> --with-http_gzip_static_module --with-http_realip_module
> --with-http_stub_status_module --with-http_ssl_module
> --with-http_sub_module --with-mail --with-mail_ssl_module
> --add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module
> --with-http_auth_request_module
>
> Все симптомы остались прежними.
> CGI скрипты нагиоса работают через такую связку отлично, как и ранее.
> однако, другие приложения (owncloud, roundcube) требуют "медленного"
> прохода.
> Ещё сделал различие, что нагиос работает везде GET запросами, в то время,
> как owncloud, jenkins, roundcube делают периодически POST
> Возможно, это неверно как-то обрабатывается.
>
> Дополнительно, я попытался смягчить условия для мониторинга, прописал в
> http секцию
>
> geo $ip_range {
> default 0;
> 192.168.125.0/24 1;
> }
>
> и в секциях server/location
>
> set $auth_location /auth/;
> if ( $ip_range = 1 ) {
> set $auth_location /always_ok;
> }
>
> location = /always_ok {
> return 200;
> }
>
> location /jenkins {
> auth_request $auth_location;
> proxy_pass http://192.168.125.37:8080;
> proxy_buffering on;
> proxy_set_headerSSL NO;
> proxy_set_headerHost $host;
> proxy_set_headerX-Real-IP $remote_addr;
> proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_read_timeout 1800;
> }
>
> такая связка не работает.
> Ошибка в логе всё та же. auth_request зачем-то ищет файл $auth_location а
> не делает подзапрос в локейшн возращаемый переменной.
>
> 2013/11/05 13:17:13 [error] 32126#0: *1243 open()
> "/usr/local/nginx/html$auth_location" failed (2: No such file or
> directory), client: 185.6.244.255, server: ssl.stremki.net, request: "GET
> /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", subrequest: "$auth_location",
> host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/";
> 2013/11/05 13:17:13 [error] 32126#0: *1243 auth request unexpected status:
> 404, client: 185.6.244.255, server: ssl.stremki.net, request: "GET
> /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", host: "ssl.stremki.net",
> referrer: "https://ssl.stremki.net/jenkins/";
>
> Я включил дебаг для своего адреса. Вот, его вывод.
> http://pastebin.com/aKDG4gYk
Директива auth_request не понимает переменных, и ваша конфигурация
ожидаемо пытается обратиться к файлу, которого не существует.
Правильное решение исходной задачи "разрешить свою сеть, для
остальных - требовать авторизацию" - написать что-нибудь вроде:
location / {
satisfy any;
auth_request /auth;
allow 192.168.125.0/24;
deny all;
...
}
http://nginx.org/r/satisfy
Что конкретно у вас происходит в случае, когда конфигурация
работоспособна и помогает "замедление" - надо смотреть, но скорее
всего просто авторизационный бекенд не справляется с нагрузкой.
--
Maxim Dounin
http://nginx.org/en/donation.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: При включении gzip не работает chunk-encoding
Hello! On Mon, Nov 04, 2013 at 05:10:14AM -0500, vulgast wrote: > Такое впечетление, что есть какой-то буфер 4096+, который нужно заполнить, > иначе чанк просто не отдается даже при сбросе буффера в php. Может это > какой-то буфер в пхп или нжинксе? Для эффективного сжатия данных - их надо сначала накопить хоть сколько-то, что и делает библиотека zlib, которую nginx использует для реализации gzip-сжатия. Чтобы данные по возможности не буферизировались nginx'ом при обработки ответов fastcgi-бекенда, а сразу отправлялись клиенту (в случае gzip'а - ценой худшего сжатия) - существует директива fastcgi_buffering, документация тут: http://nginx.org/r/fastcgi_buffering/ru Директива fastcgi_buffering появилась в nginx 1.5.6. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Nginx + Crome: part header is too long (400)
Используеся nginx + flash uploader для загузки файлов в медиахранилище. В целом, конфигурация стандартная. Возникла проблема с ответом от сервера кода 400 при попытке загрузки файлов через crome (при этом неисправность плавающая и не зависит от самого файла). Этот же файл в следующий раз загружается нормально, а какой-нибудь другой отдаёт 400. Увеличение буферов не особо помогает. Тестировалось также в FF, Opera, Safari: проблема не проявляется. Читал о схожей проблеме тут: http://forum.nginx.org/read.php?2,214924,214926 Но не понял, какие из этого делать выводы. Вот момент возникновения ошибки: 2013/11/05 19:17:45 [debug] 44995#0: *204201812 hashed path: /home/web/tmp_storage/0038896449 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".name" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".content_type" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "application/octet-stream" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 posix_memalign: 000803CA8000:4096 @16 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".path" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "/home/web/tmp_storage/0038896449" 2013/11/05 19:17:45 [info] 44995#0: *204201812 started uploading file "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" to "/home/web/tmp_storage/0038896449" (field "Filedata", content type "application/octet-stream"), client: 83.220.58.78, server: test.org, request: "POST /uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160 HTTP/1.1", host: "test.org", referrer: "http://test.org/"; 2013/11/05 19:17:45 [debug] 44995#0: *204201812 write: 32, 000803CA7000, 4096, 0 2013/11/05 19:17:45 [debug] 44995#0: *204201812 recv: eof:0, avail:5530, err:0 2013/11/05 19:17:45 [debug] 44995#0: *204201812 recv: fd:30 8192 of 8192 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http client request body recv 8192 2013/11/05 19:17:45 [debug] 44995#0: *204201812 write: 32, 000803CA7000, 4096, 4096 2013/11/05 19:17:45 [debug] 44995#0: *204201812 write: 32, 000803CA7000, 69, 8192 2013/11/05 19:17:45 [info] 44995#0: *204201812 finished uploading file "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" to "/home/web/tmp_storage/0038896449", client: 83.220.58.78, server: test.org, request: "POST /uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160 HTTP/1.1", host: "test.org", referrer: "http://test.org/"; 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".md5" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "9456bbbe7305698929a7ff9ab111602c" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".size" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "8261" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 malformed filename in part header 2013/11/05 19:17:45 [debug] 44995#0: *204201812 invalid Content-Disposition header 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http finalize request: 400, "/uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160" a:1, c:2 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http special response: 400, "/uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 uploadprogress error-tracker error: 400 2013/11/05 19:17:45 [debug] 44995#0: *204201812 uploadprogress error-tracker not tracking in this location 2013/11/05 19:17:45 [debug] 44995#0: *204201812 charset: "" > "utf-8" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 HTTP/1.1 400 Bad Request Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244464,244464#msg-244464 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx + Crome: part header is too long (400)
Hello! On Tue, Nov 05, 2013 at 11:02:15AM -0500, Bionicman wrote: > Используеся nginx + flash uploader для загузки файлов в медиахранилище. В > целом, конфигурация стандартная. > > Возникла проблема с ответом от сервера кода 400 при попытке загрузки файлов > через crome (при этом неисправность плавающая и не зависит от самого файла). > Этот же файл в следующий раз загружается нормально, а какой-нибудь другой > отдаёт 400. Увеличение буферов не особо помогает. > > Тестировалось также в FF, Opera, Safari: проблема не проявляется. Читал о > схожей проблеме тут: http://forum.nginx.org/read.php?2,214924,214926 > Но не понял, какие из этого делать выводы. Приведённая ссылка - про совсем другую проблему. [...] > 2013/11/05 19:17:45 [info] 44995#0: *204201812 finished uploading file > "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" to > "/home/web/tmp_storage/0038896449", client: 83.220.58.78, server: test.org, > request: "POST > /uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160 > HTTP/1.1", host: "test.org", referrer: "http://test.org/"; > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".md5" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: > "9456bbbe7305698929a7ff9ab111602c" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".size" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "8261" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 malformed filename in part > header > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 invalid Content-Disposition > header > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http finalize request: 400, > "/uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160" > a:1, c:2 Судя по логу, используемому стороннему модулю не нравится заголовок Content-Disposition. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Максим, спасибо огромное за подсказку с satisfy.
Гораздо удобнее геомапинга.
Я немного поэкспериментировал и выяснил, что nginx подвисает в подзапросе,
если прилетает POST запрос.
Я вставил следующее правило:
location /auth {
if ( $request_method = POST ) { return 200; }
И все приложения заработали, как положено. Бэкенд отлично справляется с
нагрузкой, дело не в нём.
Видимо, когда приходит запрос на
.https://ssl.stremki.net/project_nameметодом POST, то
ngx_http_auth_request_module
хочет сделать подзапрос таким же методом.
Но, мало того, что он хочет это сделать, он зачем-то добавляет знак ? в
конец локейшна /auth (это видно в дебаглоге)
На стороне бэкенда в этот момент не видно никакого трафика от nginx.
Тоесть, как только прилетает POST с данными на любой локейшн, который
проверяется вашим модулем, nginx строит подзапрос с методом POST, добавляет
символ ? и не делает подзапрос к бэкенду.
Простите, если запутал.
2013/11/5 Maxim Dounin
> Hello!
>
> On Tue, Nov 05, 2013 at 02:40:17PM +0400, Dzmitry Stremkouski wrote:
>
> > Максим, спасибо за ваш ответ.
> > Я попробовал сделать апгрейд nginx по вашему замечанию, чтобы сузить
> > область поиска ошибки.
> >
> > На данный момент у меня сборка следующая:
> > nginx version: nginx/1.5.6
> > built by gcc 4.4.5 (Debian 4.4.5-8)
> > TLS SNI support enabled
> > configure arguments: --with-openssl=/usr/build/openssl-1.0.1e
> > --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/var/log/nginx/error.log
> > --http-client-body-temp-path=/var/lib/nginx/body
> > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
> > --http-log-path=/var/log/nginx/access.log
> > --http-proxy-temp-path=/var/lib/nginx/proxy
> > --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid
> --with-debug
> > --with-http_flv_module --with-http_geoip_module
> > --with-http_gzip_static_module --with-http_realip_module
> > --with-http_stub_status_module --with-http_ssl_module
> > --with-http_sub_module --with-mail --with-mail_ssl_module
> > --add-module=/usr/build/nginx-upstream-fair-master
> --with-http_spdy_module
> > --with-http_auth_request_module
> >
> > Все симптомы остались прежними.
> > CGI скрипты нагиоса работают через такую связку отлично, как и ранее.
> > однако, другие приложения (owncloud, roundcube) требуют "медленного"
> > прохода.
> > Ещё сделал различие, что нагиос работает везде GET запросами, в то время,
> > как owncloud, jenkins, roundcube делают периодически POST
> > Возможно, это неверно как-то обрабатывается.
> >
> > Дополнительно, я попытался смягчить условия для мониторинга, прописал в
> > http секцию
> >
> > geo $ip_range {
> > default 0;
> > 192.168.125.0/24 1;
> > }
> >
> > и в секциях server/location
> >
> > set $auth_location /auth/;
> > if ( $ip_range = 1 ) {
> > set $auth_location /always_ok;
> > }
> >
> > location = /always_ok {
> > return 200;
> > }
> >
> > location /jenkins {
> > auth_request $auth_location;
> > proxy_pass http://192.168.125.37:8080;
> > proxy_buffering on;
> > proxy_set_headerSSL NO;
> > proxy_set_headerHost $host;
> > proxy_set_headerX-Real-IP $remote_addr;
> > proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
> > proxy_read_timeout 1800;
> > }
> >
> > такая связка не работает.
> > Ошибка в логе всё та же. auth_request зачем-то ищет файл $auth_location а
> > не делает подзапрос в локейшн возращаемый переменной.
> >
> > 2013/11/05 13:17:13 [error] 32126#0: *1243 open()
> > "/usr/local/nginx/html$auth_location" failed (2: No such file or
> > directory), client: 185.6.244.255, server: ssl.stremki.net, request:
> "GET
> > /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", subrequest:
> "$auth_location",
> > host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/";
> > 2013/11/05 13:17:13 [error] 32126#0: *1243 auth request unexpected
> status:
> > 404, client: 185.6.244.255, server: ssl.stremki.net, request: "GET
> > /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", host: "ssl.stremki.net",
> > referrer: "https://ssl.stremki.net/jenkins/";
> >
> > Я включил дебаг для своего адреса. Вот, его вывод.
> > http://pastebin.com/aKDG4gYk
>
> Директива auth_request не понимает переменных, и ваша конфигурация
> ожидаемо пытается обратиться к файлу, которого не существует.
>
> Правильное решение исходной задачи "разрешить свою сеть, для
> остальных - требовать авторизацию" - написать что-нибудь вроде:
>
> location / {
> satisfy any;
>
> auth_request /auth;
>
> allow 192.168.125.0/24;
> deny all;
>
> ...
> }
>
> http://nginx.org/r/satisfy
>
> Что конкретно у вас происходит в случае, когда конфигурация
> работоспособна и помогает "замедление" - надо смотреть, но скорее
> всего просто авторизационный бекенд не справляется с нагрузкой.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> ___
> nginx-ru mail
Nginx 1.2.7 + Apache2 2.2.24 on Freebsd 9.1 хостинг speedtest mini проблема с upload
На сервере живет связка из Nginx 1.2.7 + Apache2 2.2.24. Конфиг nginx дефолтный, размеры буферов и т.п не переопределены. Перенес на этот сервер свой хост speedtest mini. Папка с файлами спидеста расположена на рамдиске и проблем с скоростью доступа к ним нет, скорость скачивания (downlaod) 300+ Mbit/s. Но есть проблемы с тестом скорости загрузки (upload) - 40-50 Mbit/s После отключения sendfile в конфиге nginx скорость подросла до 80-120 Mbit/s Во время теста загрузки в top io mode nginx показывает 100% загрузки VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 4839 0 0 16 0 16 100.00% nginx и gstat показывает активную запись на диск. Вынос client_body_temp_path на рамдиск и изменение переменных client_body* относительно дефолтных значений приводят только к ухудшению результата теста скорости. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244480,244480#msg-244480 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
