From alex.hha at gmail.com Mon Jan 5 22:28:38 2015 From: alex.hha at gmail.com (Alex Domoradov) Date: Tue, 6 Jan 2015 00:28:38 +0200 Subject: =?UTF-8?B?0JrQsNC6INGB0L7QsdGA0LDRgtGMIG5naW54INGBINC60LDRgdGC0L7QvNC90L4=?= =?UTF-8?B?0Lkg0LLQtdGA0YHQuNC10Lkgb3BlbnNzbCArIGZpcHM=?= Message-ID: Собственно сабж, есть CentOS 5.11. Никак не получается собрать с fips # ./configure --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_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-openssl=/usr/src/redhat/BUILD/openssl-1.0.1j --with-openssl-opt="zlib enable-camellia enable-seed enable-tlsext enable-rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp fips" # make ... ... ... make[3]: Entering directory `/usr/src/redhat/BUILD/openssl-1.0.1j/test' make[3]: Nothing to be done for `generate'. make[3]: Leaving directory `/usr/src/redhat/BUILD/openssl-1.0.1j/test' make[2]: Leaving directory `/usr/src/redhat/BUILD/openssl-1.0.1j' Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend Configured for linux-x86_64. make[2]: Entering directory `/usr/src/redhat/BUILD/openssl-1.0.1j' making all in crypto... make[3]: Entering directory `/usr/src/redhat/BUILD/openssl-1.0.1j/crypto' ( echo "#ifndef MK1MF_BUILD"; \ echo ' /* auto-generated by crypto/Makefile for crypto/cversion.c */'; \ echo ' #define CFLAGS "gcc -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM"'; \ echo ' #define PLATFORM "linux-x86_64"'; \ echo " #define DATE \"`LC_ALL=C LC_TIME=C date`\""; \ echo '#endif' ) >buildinf.h gcc -I. -I.. -I../include -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o cryptlib.o cryptlib.c cryptlib.c: In function ?CRYPTO_set_locking_callback?: cryptlib.c:415: warning: implicit declaration of function ?OPENSSL_init? cryptlib.c: At top level: cryptlib.c:670: error: conflicting types for ?OPENSSL_ia32cap_loc? ../include/openssl/crypto.h:561: error: previous declaration of ?OPENSSL_ia32cap_loc? was here cryptlib.c: In function ?OPENSSL_ia32cap_loc?: cryptlib.c:677: warning: dereferencing type-punned pointer will break strict-aliasing rules make[3]: *** [cryptlib.o] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/openssl-1.0.1j/crypto' make[2]: *** [build_crypto] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/openssl-1.0.1j' make[1]: *** [/usr/src/redhat/BUILD/openssl-1.0.1j/.openssl/include/openssl/ssl.h] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/nginx-1.4.7' make: *** [build] Error 2 если убрать fips из --with-openssl-opt, то все собирается корректно. P.S. nginx-1.4.7 openssl-1.0.1j openssl-fips-2.0.9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Jan 10 19:29:22 2015 From: nginx-forum at nginx.us (alexstream) Date: Sat, 10 Jan 2015 14:29:22 -0500 Subject: =?UTF-8?B?0L7RgtC00LDQstCw0YLRjCDQvtGI0LjQsdC60YMg0LIg0YHQu9GD0YfQsNC1IDIw?= =?UTF-8?B?MCDRgdGC0LDRgtGD0YHQsCDQvtGC0LLQtdGC0LAg0LHRjdC60LXQvdC00LAu?= Message-ID: nginx работает в качестве frontend-сервера. Позади него несколько backend-ов. Все они объединены в один upstream в конфиге nginx. Запросы между бэкендами перенаправляются при помощи директив proxy_next_upstream и т.д. Когда backend-ы возвращают (или не возвращают) какие-либо очевидные ошибки (500, 502 и т.д.), то директива proxy_next_upstream корректно для клиента перенаправляет запрос на следующий бэкенд, и всё хорошо. Однако возникла задача, в случае получения от бэкенда пустого ответа со статусом 200 (бэкенд сразу же закрывает соединение) также не отдавать его сразу клиенту, а перенаправлять запрос на следующий бэкенд в данном upstream. Пока у меня клиенты в таких случаях также получают пустой ответ со статусом 200. Подскажите, пожалуйста, как такое можно реализовать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256030,256030#msg-256030 From nginx-forum at nginx.us Sun Jan 11 00:25:25 2015 From: nginx-forum at nginx.us (Valeriy) Date: Sat, 10 Jan 2015 19:25:25 -0500 Subject: =?UTF-8?B?YnVnOiB0cnkgZmlsZXMg0L3QtSDQv9C10YDQtdC90LDQv9GA0LDQstC70Y/QtdGC?= =?UTF-8?B?INCyIGxvY2F0aW9uIEAg0Lgg0LPQtdC90LXRgNC40YIgNDA0?= Message-ID: <2ef42c28aaa1578bbe2d20de53a5a2e2.NginxMailingListRussian@forum.nginx.org> Здравствуйте! я пытался организовать рерайты на своем девелопмент сервере и столкнулся со странным багом. есть папка с проектами ($document_root), в ней находятся папки которые соответствуют названиям проектов ($prjct_folder), и в папке проекта есть папка с исходниками ($prjct_src - ее название по умолчанию src, но могут быть другие src2, src_old, ...). стояла задача при обращении по адресу (ЧПУ) http://dev_hos/project_name/src/badurl и адресу http://dev_hos/project_name/badurl перенаправлять оба логически одинаковых URL на исполнение скрипту: /var/www/project_name/src/index.php ---------------------------------------------------------------------------- для реализации я создал конфиг похожий на этот (максимально упрощенный вариант) ---------------------------------------------------------------------------- server { listen 80; server_name bug; root /var/www; set $prjct_folder ''; set $prjct_src 'src'; set $prjct_uri ''; location / { add_header Content-Type 'text/html; charset=UTF-8'; return 200 other; } location ~* ^/([^/]+)/?(src[^/]*)?/?(.*) { set $prjct_folder $1; set $tmp_src $2; set $prjct_uri $3; if ($tmp_src) { set $prjct_src $tmp_src; } try_files $uri @notfound; # add_header Content-Type 'text/html; charset=UTF-8'; # return 200 $document_root/$prjct_folder/$prjct_src/$prjct_uri; } location @notfound { add_header Content-Type 'text/html; charset=UTF-8'; return 200 $document_root/$prjct_folder/$prjct_src/$prjct_uri; } } ---------------------------------------------------------------------------- логика работы следующая: при обращении к серверу, ЧПУ попадает на обработку в блок с регулярным выражением, регулярное выражение извлекает из него название папки проекта и название папки с исходниками (если такова в адресе есть) и перенаправляет в блок @notfound который вызывает нужный скрипт (логику вызова скрипта я убрал, оставил только инструкции для дебага) ---------------------------------------------------------------------------- баг заключается в том, что при обращении по адресу вида (содержит src) http://dev_hos/project_name/src/badurl nginx выдает 404 проходя мимо блоков @notfound и / при заходе на адрес без src http://dev_hos/project_name/badurl nginx корректно переходит в блок @notfound ---------------------------------------------------------------------------- в лог nginx попадает следующая ошибка: #[error] 4288#0: *1 open() "/var/www/project_name/src/badurl" failed (2: No such file or directory), client: 192.168.234.1, server: bug, request: "GET /project_name/src/badurl HTTP/1.1", host: "bug" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256033,256033#msg-256033 From onokonem at gmail.com Sun Jan 11 01:04:49 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 11 Jan 2015 05:04:49 +0400 Subject: =?UTF-8?B?UmU6IGJ1ZzogdHJ5IGZpbGVzINC90LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9GP?= =?UTF-8?B?0LXRgiDQsiBsb2NhdGlvbiBAINC4INCz0LXQvdC10YDQuNGCIDQwNA==?= In-Reply-To: <2ef42c28aaa1578bbe2d20de53a5a2e2.NginxMailingListRussian@forum.nginx.org> References: <2ef42c28aaa1578bbe2d20de53a5a2e2.NginxMailingListRussian@forum.nginx.org> Message-ID: 2015-01-11 3:25 GMT+03:00 Valeriy : > баг заключается в том, что при обращении по адресу вида (содержит src) > http://dev_hos/project_name/src/badurl > nginx выдает 404 проходя мимо блоков @notfound и / вы бы глянули в логи, что ли. там написано, какой именно файл не найден. будете удивлены... From nginx.org at dubrovskiy.net Sun Jan 11 15:25:19 2015 From: nginx.org at dubrovskiy.net (Ivan) Date: Sun, 11 Jan 2015 18:25:19 +0300 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSwg0L/QvtC20LDQu9GD0LnRgdGC0LAsINGBINGA0LU=?= =?UTF-8?B?0LPRg9C70Y/RgNC90YvQvCDQstGL0YDQsNC20LXQvdC40LXQvCDQtNC70Y8g?= =?UTF-8?B?0LvQvtC60LXQudGI0LXQvdCw?= Message-ID: Здравствуйте! Помогите, пожалуйста, с регулярным выражением для локейшена. Нужно что бы для запросов: site.com/autodiscover/autodiscover.xml site.com/autodiscover/Autodiscover.xml site.com/Autodiscover/autodiscover.xml site.com/Autodiscover/Autodiscover.xml запросы для php-fpm перенаправлялись на лежащий в корне сайта autodiscover.xml не редирект, а именно локейшен, что-то вида: location = /(А или а)utodiscover/(А или а)utodiscover.xml { index autodiscover.xml; } Зарание огромное спасибо! From nginx-forum at nginx.us Sun Jan 11 16:36:10 2015 From: nginx-forum at nginx.us (Valeriy) Date: Sun, 11 Jan 2015 11:36:10 -0500 Subject: =?UTF-8?B?UmU6IGJ1ZzogdHJ5IGZpbGVzINC90LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9GP?= =?UTF-8?B?0LXRgiDQsiBsb2NhdGlvbiBAINC4INCz0LXQvdC10YDQuNGCIDQwNA==?= In-Reply-To: References: Message-ID: лог я скопировал в письме: #[error] 4288#0: *1 open() "/var/www/project_name/src/badurl" failed (2: No such file or directory), client: 192.168.234.1, server: bug, request: "GET /project_name/src/badurl HTTP/1.1", host: "bug" не найденный файл /var/www/project_name/src/badurl то что он не найден это не удивляет, т. к. это ЧПУ. удивляет то что try_files $uri @notfound; это событие не перенаправляет на блок location @notfound и удивляет, то что эта конструкция "работает" если убрать блок if если поможете разобраться буду очень признателен, возможно я не заметил то что заметили Вы спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256034,256044#msg-256044 From onokonem at gmail.com Sun Jan 11 16:59:37 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 11 Jan 2015 20:59:37 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: References: Message-ID: 2015-01-11 18:25 GMT+03:00 Ivan : > location = /(А или а)utodiscover/(А или а)utodiscover.xml { index > autodiscover.xml; } Если следовать букве задания, то location ~ "^/+[aA]utodiscover/+[aA]utodiscover\.xml$" From onokonem at gmail.com Sun Jan 11 18:01:52 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 11 Jan 2015 22:01:52 +0400 Subject: =?UTF-8?B?UmU6IGJ1ZzogdHJ5IGZpbGVzINC90LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9GP?= =?UTF-8?B?0LXRgiDQsiBsb2NhdGlvbiBAINC4INCz0LXQvdC10YDQuNGCIDQwNA==?= In-Reply-To: References: Message-ID: 2015-01-11 19:36 GMT+03:00 Valeriy : > удивляет то что > try_files $uri @notfound; > это событие не перенаправляет на блок > location @notfound > и удивляет, то что эта конструкция "работает" если убрать блок if Я принялся глядеть в ваш конфиг внимательнее, и первое, что я обнаружил - if там не делает ничего полезного. можно его убрать, а set $prjct_src $tmp_src; оставить, и будет, по-видимому, ровно то, что вы хотите получить. это раз. и два - почитайте http://wiki.nginx.org/IfIsEvil. ситуация try_files wont work due to if там документирована (эта беда от того, что if создает скрытый location, внутри которого дальше и происходит обработка) From nginx-forum at nginx.us Sun Jan 11 19:38:22 2015 From: nginx-forum at nginx.us (Valeriy) Date: Sun, 11 Jan 2015 14:38:22 -0500 Subject: =?UTF-8?B?UmU6IGJ1ZzogdHJ5IGZpbGVzINC90LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9GP?= =?UTF-8?B?0LXRgiDQsiBsb2NhdGlvbiBAINC4INCz0LXQvdC10YDQuNGCIDQwNA==?= In-Reply-To: References: Message-ID: спасибо за ответ! в моем конфиге if переопределяет папку с исходниками по-умолчанию ($prjct_src). возможно я сделал неудачный пример написав http://dev_hos/project_name/src/badurl вместо http://dev_hos/project_name/src_zero/badurl ---------------------------- возникшую проблему - я у себя решил, написав два отдельных регулярных выражения я всегда думал что одно регулярное выражение лучше двух, поэтому и использовал if но раз это не баг, а if плохая штука, тогда okay! спасибо за консультацию! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256034,256048#msg-256048 From wangsamp at gmail.com Sun Jan 11 21:38:13 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sun, 11 Jan 2015 23:38:13 +0200 (EET) Subject: =?UTF-8?B?UmU6IGJ1ZzogdHJ5IGZpbGVzINC90LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9GP?= =?UTF-8?B?0LXRgiDQsiBsb2NhdGlvbiBAINC4INCz0LXQvdC10YDQuNGCIDQwNA==?= In-Reply-To: References: Message-ID: Today Jan 11, 2015 at 14:38 Valeriy wrote: > возникшую проблему - я у себя решил, написав два отдельных регулярных > выражения > я всегда думал что одно регулярное выражение лучше двух, поэтому и > использовал if Ещё откройте для себя именованные выделения в регулярных выражениях и поймёте, что set тоже не нужен: location ~* ^/(?[^/]+)/?(?src[^/]*)?/?(?.*) -- WNGS-RIPE From nginx.org at dubrovskiy.net Mon Jan 12 12:55:27 2015 From: nginx.org at dubrovskiy.net (Ivan) Date: Mon, 12 Jan 2015 15:55:27 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: References: Message-ID: Спасибо за ответ, но к сожалению не помог, получаю ошибку 404 2015/01/11 20:34:19 [error] 10334#0: *1 FastCGI sent in stderr: "Unable to open primary script: /www/flow.su/content/autodiscover/autodiscover.xml (No such file or directory)" while reading response header from upstream, client: 37.145.72.79, server: flow.su, request: "GET /autodiscover/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9900", host: "autodiscover.flow.su" Возможно, сразу стоило привести кусок конфига server { listen *:80; listen [::]:80; server_name flow.su www.flow.su autodiscover.flow.su; root /www/flow.su/content; location / { index index.html; } location ~ "^/+[aA]utodiscover/+[aA]utodiscover\.xml$" { index autodiscover.xml; try_files $fastcgi_script_name =404; fastcgi_pass 127.0.0.1:9999; fastcgi_index autodiscover.xml; fastcgi_param HTTPS on; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_read_timeout 10s; fastcgi_intercept_errors on; } } From universite at ukr.net Mon Jan 12 13:03:49 2015 From: universite at ukr.net (Vladislav Prodan) Date: Mon, 12 Jan 2015 15:03:49 +0200 Subject: =?UTF-8?B?UmVbMl06INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCA=?= =?UTF-8?B?0YEg0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg?= =?UTF-8?B?0LTQu9GPINC70L7QutC10LnRiNC10L3QsA==?= In-Reply-To: References: Message-ID: <1421067828.630538037.vb2nw5dw@frv35.fwdcdn.com> --- Original message --- From: "Ivan" Date: 12 January 2015, 14:55:52 > Спасибо за ответ, но к сожалению не помог, получаю ошибку 404 > 2015/01/11 20:34:19 [error] 10334#0: *1 FastCGI sent in stderr: "Unable to > open primary script: /www/flow.su/content/autodiscover/autodiscover.xml (No > such file or directory)" while reading response header from upstream, > client: 37.145.72.79, server: flow.su, request: "GET /autodiscover/ > HTTP/1.1", upstream: "fastcgi://127.0.0.1:9900", host: > "autodiscover.flow.su" > ls -l /www/flow.su/content/autodiscover/autodiscover.xml -- Vladislav V. Prodan System & Network Administrator support.od.ua From bazilek at gmail.com Mon Jan 12 13:06:33 2015 From: bazilek at gmail.com (Vasil Mikhalenya) Date: Mon, 12 Jan 2015 16:06:33 +0300 Subject: nested location inheritance Message-ID: Добрый день, озадачен вопросом составления казалось бы тривиального конфига, задача - для определенно урла выключить логирование, обойдясь без дублирования конфигурации. Однако, как я понял, директивы fastcgi_pass не наследуются во вложенный location. location / { root /usr/share/zabbix/; index index.php; location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js)$ { access_log off; expires 10d; } } location ~ \.php$ { fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; fastcgi_buffer_size 4k; fastcgi_buffers 4 32k; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/share/zabbix$fastcgi_script_name; include fastcgi_params; location ~ ^/api_jsonrpc\.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/share/zabbix$fastcgi_script_name; include fastcgi_params; access_log /var/log/nginx/zabbix_api.log main; error_log /var/log/nginx/zabbix_api_error.log; } Возможно ли для локейшена /api_jsonrpc\.php$ установить другие пути для логирования, не копируя при этом конфигурацию для fastcgi. Спасибо. -- Best regards, Vasil Mikhalenya -------------- next part -------------- An HTML attachment was scrubbed... URL: From loverjoni at gmail.com Mon Jan 12 13:18:20 2015 From: loverjoni at gmail.com (Ivan Polonevich) Date: Mon, 12 Jan 2015 15:18:20 +0200 Subject: nested location inheritance In-Reply-To: References: Message-ID: <1421068700.8526.1.camel@polonevich-nb> Вынести обработку всех fastcgi в именованный локейшн location @zabbix {} и location ~ ^/api_jsonrpc\.php поставить выше в конфиге, чем location ~ \.php -----Original Message----- From: Vasil Mikhalenya Reply-to: nginx-ru at nginx.org To: nginx-ru at nginx.org Subject: nested location inheritance Date: Mon, 12 Jan 2015 16:06:33 +0300 Добрый день, озадачен вопросом составления казалось бы тривиального конфига, задача - для определенно урла выключить логирование, обойдясь без дублирования конфигурации. Однако, как я понял, директивы fastcgi_pass не наследуются во вложенный location. location / { root /usr/share/zabbix/; index index.php; location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2| doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js)$ { access_log off; expires 10d; } } location ~ \.php$ { fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; fastcgi_buffer_size 4k; fastcgi_buffers 4 32k; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/share/zabbix $fastcgi_script_name; include fastcgi_params; location ~ ^/api_jsonrpc\.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/share/zabbix $fastcgi_script_name; include fastcgi_params; access_log /var/log/nginx/zabbix_api.log main; error_log /var/log/nginx/zabbix_api_error.log; } Возможно ли для локейшена /api_jsonrpc\.php$ установить другие пути для логирования, не копируя при этом конфигурацию для fastcgi. Спасибо. -- Best regards, Vasil Mikhalenya _______________________________________________ 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: From mdounin at mdounin.ru Mon Jan 12 13:30:43 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 12 Jan 2015 16:30:43 +0300 Subject: nested location inheritance In-Reply-To: References: Message-ID: <20150112133043.GH47350@mdounin.ru> Hello! On Mon, Jan 12, 2015 at 04:06:33PM +0300, Vasil Mikhalenya wrote: > Добрый день, > > озадачен вопросом составления казалось бы тривиального конфига, задача - > для определенно урла выключить логирование, обойдясь без дублирования > конфигурации. Однако, как я понял, директивы fastcgi_pass не наследуются во > вложенный location. Директивы fastcgi_pass - не наследуются, однако все остальные директивы fastcgi_* - наследуется. [...] > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME /usr/share/zabbix$fastcgi_script_name; > include fastcgi_params; Just a note: fastcgi_index такой по умолчанию, а SCRIPT_FILENAME в таком виде проще получить, задав правильно root (на уровне server, например) и сказав "include fastcgi.conf". > > location ~ ^/api_jsonrpc\.php$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > /usr/share/zabbix$fastcgi_script_name; > include fastcgi_params; > > access_log /var/log/nginx/zabbix_api.log main; > error_log /var/log/nginx/zabbix_api_error.log; > } > > Возможно ли для локейшена /api_jsonrpc\.php$ установить другие пути для > логирования, не копируя при этом конфигурацию для fastcgi. ... т.е. "дублировать" нужно ровно одну строку, собственно "fastcgi_pass 127.0.0.1:9000;". -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Mon Jan 12 13:31:26 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 12 Jan 2015 16:31:26 +0300 Subject: nested location inheritance In-Reply-To: <1421068700.8526.1.camel@polonevich-nb> References: <1421068700.8526.1.camel@polonevich-nb> Message-ID: <20150112133126.GI47350@mdounin.ru> Hello! On Mon, Jan 12, 2015 at 03:18:20PM +0200, Ivan Polonevich wrote: > Вынести обработку всех fastcgi в именованный локейшн location @zabbix {} > и location ~ ^/api_jsonrpc\.php поставить выше в конфиге, чем location ~ > \.php Не надо так. (c) -- Maxim Dounin http://nginx.org/ From nginx.org at dubrovskiy.net Mon Jan 12 13:49:26 2015 From: nginx.org at dubrovskiy.net (Ivan) Date: Mon, 12 Jan 2015 16:49:26 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: <1421067828.630538037.vb2nw5dw@frv35.fwdcdn.com> References: <1421067828.630538037.vb2nw5dw@frv35.fwdcdn.com> Message-ID: Здравствуйте, Владислав! Файла там нет, т.к. согласно задания он лежит в корне сайт, т.е. в $document_root Нужно чтобы для запросах следующих URLов site.com/autodiscover/autodiscover.xml site.com/autodiscover/Autodiscover.xml site.com/Autodiscover/autodiscover.xml site.com/Autodiscover/Autodiscover.xml отдавалась в php-fpm autodiscover.xml лежащий в корне сайта, site.com/autodiscover.xml > --- Original message --- > From: "Ivan" > Date: 12 January 2015, 14:55:52 > >> Спасибо за ответ, но к сожалению не помог, получаю ошибку 404 >> 2015/01/11 20:34:19 [error] 10334#0: *1 FastCGI sent in stderr: >>"Unable to open primary script: /www/site.com/content/autodiscover/autodiscover.xml (No such file or directory)" while reading response header from upstream, >> client: 37.145.72.79, server: site.com, request: "GET /autodiscover/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" >> > ls -l /www/site.com/content/autodiscover/autodiscover.xml > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua From onokonem at gmail.com Mon Jan 12 13:55:30 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 12 Jan 2015 17:55:30 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: References: <1421067828.630538037.vb2nw5dw@frv35.fwdcdn.com> Message-ID: > request: "GET /autodiscover/ HTTP/1.1" что-то этот запрос вашему заданию не соответствует From bazilek at gmail.com Mon Jan 12 20:33:35 2015 From: bazilek at gmail.com (Vasil Mikhalenya) Date: Mon, 12 Jan 2015 23:33:35 +0300 Subject: nested location inheritance In-Reply-To: <20150112133043.GH47350@mdounin.ru> References: <20150112133043.GH47350@mdounin.ru> Message-ID: Большое спасибо, так значительно компактнее. Можно пару слов, чем обусловлена такая реализация и где в документации описаны данные особенности, если описаны? 2015-01-12 16:30 GMT+03:00 Maxim Dounin : > Hello! > > On Mon, Jan 12, 2015 at 04:06:33PM +0300, Vasil Mikhalenya wrote: > > > Добрый день, > > > > озадачен вопросом составления казалось бы тривиального конфига, задача - > > для определенно урла выключить логирование, обойдясь без дублирования > > конфигурации. Однако, как я понял, директивы fastcgi_pass не наследуются > во > > вложенный location. > > Директивы fastcgi_pass - не наследуются, однако все остальные > директивы fastcgi_* - наследуется. > > [...] > > > fastcgi_pass 127.0.0.1:9000; > > fastcgi_index index.php; > > fastcgi_param SCRIPT_FILENAME > /usr/share/zabbix$fastcgi_script_name; > > include fastcgi_params; > > Just a note: fastcgi_index такой по умолчанию, а SCRIPT_FILENAME в > таком виде проще получить, задав правильно root (на уровне server, > например) и сказав "include fastcgi.conf". > > > > > location ~ ^/api_jsonrpc\.php$ { > > fastcgi_pass 127.0.0.1:9000; > > fastcgi_index index.php; > > fastcgi_param SCRIPT_FILENAME > > /usr/share/zabbix$fastcgi_script_name; > > include fastcgi_params; > > > > access_log /var/log/nginx/zabbix_api.log main; > > error_log /var/log/nginx/zabbix_api_error.log; > > } > > > > Возможно ли для локейшена /api_jsonrpc\.php$ установить другие пути для > > логирования, не копируя при этом конфигурацию для fastcgi. > > ... т.е. "дублировать" нужно ровно одну строку, собственно > "fastcgi_pass 127.0.0.1:9000;". > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Vasil Mikhalenya -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx.org at dubrovskiy.net Tue Jan 13 12:32:00 2015 From: nginx.org at dubrovskiy.net (Ivan) Date: Tue, 13 Jan 2015 15:32:00 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: References: <1421067828.630538037.vb2nw5dw@frv35.fwdcdn.com> Message-ID: > Mon, 12 Jan 2015 17:55:30 +0400 Вы писали: >> request: "GET /autodiscover/ HTTP/1.1" > что-то этот запрос вашему заданию не соответствует Извините, пробовал много вариантов, скопировал не те строчки, исправляюсь: 2015/01/12 19:29:14 [error] 8352#0: *12 FastCGI sent in stderr: "Unable to open primary script: /www/site.com/content/autodiscover/autodiscover.xml (No such file or directory)" while reading response header from upstream, client: 37.145.72.79, server: site.com, request: "GET /autodiscover/autodiscover.xml HTTP/1.1", upstream: "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" 2015/01/12 19:29:24 [error] 8352#0: *17 FastCGI sent in stderr: "Unable to open primary script: /www/site.com/content/autodiscover/Autodiscover.xml (No such file or directory)" while reading response header from upstream, client: 37.145.72.79, server: site.com, request: "GET /autodiscover/Autodiscover.xml HTTP/1.1", upstream: "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" 2015/01/12 19:29:33 [error] 8352#0: *20 FastCGI sent in stderr: "Unable to open primary script: /www/site.com/content/Autodiscover/autodiscover.xml (No such file or directory)" while reading response header from upstream, client: 37.145.72.79, server: site.com, request: "GET /Autodiscover/autodiscover.xml HTTP/1.1", upstream: "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" 2015/01/12 19:29:44 [error] 8352#0: *28 FastCGI sent in stderr: "Unable to open primary script: /www/site.com/content/Autodiscover/Autodiscover.xml (No such file or directory)" while reading response header from upstream, client: 37.145.72.79, server: site.com, request: "GET /Autodiscover/Autodiscover.xml HTTP/1.1", upstream: "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" [12/Jan/2015:19:29:14 +0300] "GET /autodiscover/autodiscover.xml HTTP/1.1" 404 45 "-" "Mozilla/5.0" [12/Jan/2015:19:29:24 +0300] "GET /autodiscover/Autodiscover.xml HTTP/1.1" 404 45 "-" "Mozilla/5.0" [12/Jan/2015:19:29:33 +0300] "GET /Autodiscover/autodiscover.xml HTTP/1.1" 404 45 "-" "Mozilla/5.0" [12/Jan/2015:19:29:44 +0300] "GET /Autodiscover/Autodiscover.xml HTTP/1.1" 404 45 "-" "Mozilla/5.0" P.S. Стоило не досмотреть и не затереть настоящее доменное имя в приведенном ранее конфиге и сразу накинулись гугловые роботы - сканируют (видимо уже проиндексировали переписку) :( From onokonem at gmail.com Tue Jan 13 12:44:58 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 13 Jan 2015 16:44:58 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: References: <1421067828.630538037.vb2nw5dw@frv35.fwdcdn.com> Message-ID: раз уж я влез в это дело по уши - покажите полный конфиг, а? можно в личку 2015-01-13 15:32 GMT+03:00 Ivan : >> Mon, 12 Jan 2015 17:55:30 +0400 Вы писали: >>> >>> request: "GET /autodiscover/ HTTP/1.1" >> >> что-то этот запрос вашему заданию не соответствует > > > Извините, пробовал много вариантов, скопировал не те строчки, исправляюсь: > > 2015/01/12 19:29:14 [error] 8352#0: *12 FastCGI sent in stderr: "Unable to > open primary script: /www/site.com/content/autodiscover/autodiscover.xml (No > such file or directory)" while reading response header from upstream, > client: 37.145.72.79, server: site.com, request: "GET > /autodiscover/autodiscover.xml HTTP/1.1", upstream: > "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" > 2015/01/12 19:29:24 [error] 8352#0: *17 FastCGI sent in stderr: "Unable to > open primary script: /www/site.com/content/autodiscover/Autodiscover.xml (No > such file or directory)" while reading response header from upstream, > client: 37.145.72.79, server: site.com, request: "GET > /autodiscover/Autodiscover.xml HTTP/1.1", upstream: > "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" > 2015/01/12 19:29:33 [error] 8352#0: *20 FastCGI sent in stderr: "Unable to > open primary script: /www/site.com/content/Autodiscover/autodiscover.xml (No > such file or directory)" while reading response header from upstream, > client: 37.145.72.79, server: site.com, request: "GET > /Autodiscover/autodiscover.xml HTTP/1.1", upstream: > "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" > 2015/01/12 19:29:44 [error] 8352#0: *28 FastCGI sent in stderr: "Unable to > open primary script: /www/site.com/content/Autodiscover/Autodiscover.xml (No > such file or directory)" while reading response header from upstream, > client: 37.145.72.79, server: site.com, request: "GET > /Autodiscover/Autodiscover.xml HTTP/1.1", upstream: > "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" > > [12/Jan/2015:19:29:14 +0300] "GET /autodiscover/autodiscover.xml HTTP/1.1" > 404 45 "-" "Mozilla/5.0" > [12/Jan/2015:19:29:24 +0300] "GET /autodiscover/Autodiscover.xml HTTP/1.1" > 404 45 "-" "Mozilla/5.0" > [12/Jan/2015:19:29:33 +0300] "GET /Autodiscover/autodiscover.xml HTTP/1.1" > 404 45 "-" "Mozilla/5.0" > [12/Jan/2015:19:29:44 +0300] "GET /Autodiscover/Autodiscover.xml HTTP/1.1" > 404 45 "-" "Mozilla/5.0" > > P.S. Стоило не досмотреть и не затереть настоящее доменное имя в приведенном > ранее конфиге и сразу накинулись гугловые роботы - сканируют (видимо уже > проиндексировали переписку) :( > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Tue Jan 13 13:09:13 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 13 Jan 2015 16:09:13 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: References: Message-ID: <1987690.jBYJhiYhTH@vbart-workstation> On Monday 12 January 2015 15:55:27 Ivan wrote: > Спасибо за ответ, но к сожалению не помог, получаю ошибку 404 > 2015/01/11 20:34:19 [error] 10334#0: *1 FastCGI sent in stderr: "Unable to > open primary script: /www/flow.su/content/autodiscover/autodiscover.xml (No > such file or directory)" while reading response header from upstream, > client: 37.145.72.79, server: flow.su, request: "GET /autodiscover/ > HTTP/1.1", upstream: "fastcgi://127.0.0.1:9900", host: > "autodiscover.flow.su" > > Возможно, сразу стоило привести кусок конфига > server { > listen *:80; > listen [::]:80; > server_name flow.su www.flow.su autodiscover.flow.su; > root /www/flow.su/content; > location / { index index.html; } > > location ~ "^/+[aA]utodiscover/+[aA]utodiscover\.xml$" { > index autodiscover.xml; > try_files $fastcgi_script_name =404; > fastcgi_pass 127.0.0.1:9999; > fastcgi_index autodiscover.xml; > fastcgi_param HTTPS on; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; [..] fastcgi_param SCRIPT_FILENAME $document_root/autodiscover.xml; -- Валентин Бартенев From mdounin at mdounin.ru Tue Jan 13 13:36:10 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 13 Jan 2015 16:36:10 +0300 Subject: nested location inheritance In-Reply-To: References: <20150112133043.GH47350@mdounin.ru> Message-ID: <20150113133610.GC79857@mdounin.ru> Hello! On Mon, Jan 12, 2015 at 11:33:35PM +0300, Vasil Mikhalenya wrote: > Большое спасибо, так значительно компактнее. > Можно пару слов, чем обусловлена такая реализация Идея состоит в том, что все настройки/опции - наследуются. Это позволяет писать простые и эффективные с точки зрения ресурсов конфиги. Не наследуются только некоторые специальные директивы, предназначенные для использования в конкретных location'ах: - Директивы, включающие какую-либо безусловную обработку запросов в рамках данного location'а вместо выдачи статических файлов (из стандартных - proxy_pass, fastcgi_pass, scgi_pass, uwsgi_pass, memcached_pass, flv, mp4, stub_status, empty_gif, perl). - Инструкции модуля rewrite. - Директива try_files. Собственно, до появления вложенных location'ов эти особенности вообще никак не были видны с точки зрения пользователя, т.к. упомянутые директивы (кроме разве что try_files с некоторых пор) нельзя было использовать вне контекста location (или, как в случае с инструкциями rewrite, они там документировано работали по другому). Да и сейчас случаи, когда директивы не наследуются, более или менее очевидны. > и где в документации > описаны данные особенности, если описаны? Явного описания, вероятно, не существует. -- Maxim Dounin http://nginx.org/ From nginx.org at dubrovskiy.net Wed Jan 14 17:55:54 2015 From: nginx.org at dubrovskiy.net (Ivan) Date: Wed, 14 Jan 2015 20:55:54 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUsINC/0L7QttCw0LvRg9C50YHRgtCwLCDRgSA=?= =?UTF-8?B?0YDQtdCz0YPQu9GP0YDQvdGL0Lwg0LLRi9GA0LDQttC10L3QuNC10Lwg0LQ=?= =?UTF-8?B?0LvRjyDQu9C+0LrQtdC50YjQtdC90LA=?= In-Reply-To: <1987690.jBYJhiYhTH@vbart-workstation> References: <1987690.jBYJhiYhTH@vbart-workstation> Message-ID: >> Спасибо за ответ, но к сожалению не помог, получаю ошибку 404 >> 2015/01/11 20:34:19 [error] 10334#0: *1 FastCGI sent in stderr: >> "Unable to open primary script: >> /www/site.com/content/autodiscover/autodiscover.xml (No >> such file or directory)" while reading response header from upstream, >> client: 37.145.72.79, server: site.com, request: "GET /autodiscover/ >> HTTP/1.1", upstream: "fastcgi://127.0.0.1:9999", host: "autodiscover.site.com" >> >> Возможно, сразу стоило привести кусок конфига >> server { >> listen *:80; >> listen [::]:80; >> server_name site.com www.site.com autodiscover.site.com; >> root /www/site.com/content; >> location / { index index.html; } >> >> location ~ "^/+[aA]utodiscover/+[aA]utodiscover\.xml$" { >> index autodiscover.xml; >> try_files $fastcgi_script_name =404; >> fastcgi_pass 127.0.0.1:9999; >> fastcgi_index autodiscover.xml; >> fastcgi_param HTTPS on; >> fastcgi_param SCRIPT_FILENAME >> $document_root$fastcgi_script_name; > [..] > > fastcgi_param SCRIPT_FILENAME $document_root/autodiscover.xml; > > -- > Валентин Бартенев Большое спасибо всем! Не использование $fastcgi_script_name помогло, но только в паре с убранным try_files $fastcgi_script_name =404; From kulmaks at gmail.com Thu Jan 15 10:19:31 2015 From: kulmaks at gmail.com (Maksim Kulik) Date: Thu, 15 Jan 2015 13:19:31 +0300 Subject: =?UTF-8?B?0J3QtSDRgdC+0LfQtNCw0Y7RgtGB0Y8g0LTQuNGA0LXQutGC0L7RgNC40Lgg0LQ=?= =?UTF-8?B?0LvRjyDQutGN0YjQsCDQuCBuZ2lueCDQvdC1INC60Y3RiNC40YDRg9C10YIg?= =?UTF-8?B?0YTQsNC50LvRiw==?= Message-ID: Здравствуйте! Пробую настраивать кэширование контента, поступающего с бэкенда. Директория для кэша появляется (в моем случае /var/tmp/nginx-cache), но не заполняется. В конфигурации есть следующее: user nginx nginx; worker_processes 1; events { worker_connections 2048; use kqueue; } http { include mime.types; default_type application/octet-stream; sendfile on; aio on; tcp_nopush on; tcp_nodelay on; postpone_output 0; keepalive_timeout 75; reset_timedout_connection on; client_header_timeout 15; client_body_timeout 15; client_max_body_size 256m; send_timeout 5; server_tokens off; proxy_read_timeout 600s; send_lowat 12000; output_buffers 32 8k; gzip on; gzip_types text/plain application/xml application/x-javascript text/css; gzip_proxied any; gzip_static on; proxy_max_temp_file_size 0; proxy_buffering off; ssl_session_timeout 10m; *proxy_cache_path /var/tmp/nginx-cache levels=1:1 keys_zone=secondary:10m;* server { listen 1.2.3.4:80; server_name example.com www.example.com; access_log /var/log/example.com-access.log combined buffer=32k; error_log /var/log/example.com-error.log debug; root /var/webs/user/example.com/; * proxy_cache secondary;* * proxy_cache_valid any 1h;* * proxy_ignore_headers "Expires" "Cache-Control" "Set-Cookie";* * proxy_cache_key "$host$request_uri";* location / { index index.php index.html index.htm; try_files $uri $uri/ @proxy; } location ~ /\. { deny all; } location ~[^?]*/$ { proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1; } location ~ \.php$ { proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1; } location @proxy { proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1; } } } Версия nginx: nginx -V nginx version: nginx/1.7.9 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 --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_geoip_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_stub_status_module --with-pcre --with-http_spdy_module --with-http_ssl_module OS: FreeBSD 9.2 Записи из дебаг-лога касательно кэша следующие: 2015/01/15 12:59:21 [debug] 40892#0: *14266 http cache key: " example.com/category/networks/" 2015/01/15 12:59:21 [debug] 40892#0: *14266 http file cache exists: -5 e:0 2015/01/15 12:59:21 [debug] 40892#0: *14266 cache file: "/var/tmp/nginx-cache/c/f/b1a01f3fd8c3e9c8908accfa9d8785fc" 2015/01/15 12:59:21 [debug] 40892#0: *14266 http upstream cache: -5 2015/01/15 12:59:21 [debug] 40892#0: *14266 http file cache free, fd: -1 Директория пустая: ls -l /var/tmp/nginx-cache/ total 0 Что может быть не так? Какие данные еще могут быть полезными для диагностики? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Jan 15 13:33:46 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 15 Jan 2015 16:33:46 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YHQvtC30LTQsNGO0YLRgdGPINC00LjRgNC10LrRgtC+0YDQuNC4?= =?UTF-8?B?INC00LvRjyDQutGN0YjQsCDQuCBuZ2lueCDQvdC1INC60Y3RiNC40YDRg9C1?= =?UTF-8?B?0YIg0YTQsNC50LvRiw==?= In-Reply-To: References: Message-ID: <20150115133345.GP79857@mdounin.ru> Hello! On Thu, Jan 15, 2015 at 01:19:31PM +0300, Maksim Kulik wrote: > Здравствуйте! > Пробую настраивать кэширование контента, поступающего с бэкенда. Директория > для кэша появляется (в моем случае /var/tmp/nginx-cache), но не заполняется. > В конфигурации есть следующее: [...] > * proxy_cache secondary;* > * proxy_cache_valid any 1h;* > * proxy_ignore_headers "Expires" "Cache-Control" "Set-Cookie";* > * proxy_cache_key "$host$request_uri";* [...] > Записи из дебаг-лога касательно кэша следующие: > > 2015/01/15 12:59:21 [debug] 40892#0: *14266 http cache key: " > example.com/category/networks/" > 2015/01/15 12:59:21 [debug] 40892#0: *14266 http file cache exists: -5 e:0 > 2015/01/15 12:59:21 [debug] 40892#0: *14266 cache file: > "/var/tmp/nginx-cache/c/f/b1a01f3fd8c3e9c8908accfa9d8785fc" > 2015/01/15 12:59:21 [debug] 40892#0: *14266 http upstream cache: -5 > 2015/01/15 12:59:21 [debug] 40892#0: *14266 http file cache free, fd: -1 Судя по тому, что зовётся ngx_http_file_cache_free(), по каким-то причинам до сохранения в кеш дело не доходит. Это может быть, например, из-за того, что ответ получен не полностью, или сохранение в кеш запрещено заголовками ответа (помимо перечисленных в proxy_ignore_headers, есть ещё как минимум X-Accel-Expires и "Vary: *"), или обработка запроса перенаправлена в другое место (X-Accel-Redirect). [...] > Что может быть не так? Какие данные еще могут быть полезными для > диагностики? См. выше. Если не поможет разобраться - отладочный лог имеет смысл показывать полностью. -- Maxim Dounin http://nginx.org/ From oleg.cherniy at gmail.com Thu Jan 15 13:54:23 2015 From: oleg.cherniy at gmail.com (=?UTF-8?B?0J7Qu9C10LMg0KfQtdGA0L3RltC5?=) Date: Thu, 15 Jan 2015 15:54:23 +0200 Subject: =?UTF-8?B?bmdpbngtMS43LjkgKyBuZ3hfY2FjaGVfcHVyZ2UgMi4zINGC0LXQv9C10YDRjCA=?= =?UTF-8?B?0YDQsNCx0L7RgtCw0LXRgiDRgtC+0LvRjNC60L4g0L/RgNC4INGB0L7QstC/?= =?UTF-8?B?0LDQtNC10L3QuNC4INC30LDQs9C+0LvQvtCy0LrQsCBBY2NlcHQgOig=?= Message-ID: Сегодня удивил эксперимент, при котором запрашивался блок, ложился в кэш и без проблем этот кэш можно было почистить из браузера. Но при попытке запросить это же адрес на очистку из curl или wget получал 404 и кеш не чистился. Как оказалось это реакция на несовпадение заголовка "Accept" при запросе контента, который помещается в кэш и запроса который этот контент должен удалить. Если заголовки совпадают -- все Ok, если нет - 404 и кэш не чиститься. Браузер обычно сетапит Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 curl и wget сетапит: Accept: */* В бинарной части вначале файлика с кэшем видно, что добавился "запакованый" заголовок "Accept", видимо проблема связана с этим. Не придумал ничего лучшего чем откатиться до nginx 1.7.6 + ngx_cache_purge 2.1 -- там этой проблемы нет. Может в кэше можно этот "Accept" как-то отрубить? -- --- С уважением, Олег Черний, руководитель отдела разработки AUTO.RIA.com RIA.com тел./факс.: 0 432 555-200 (многоканальний) моб: 0 (67) 295-27-52 E-mail: *oleg.cherniy at ria.ua * -------------- next part -------------- An HTML attachment was scrubbed... URL: From kulmaks at gmail.com Thu Jan 15 14:03:37 2015 From: kulmaks at gmail.com (Maksim Kulik) Date: Thu, 15 Jan 2015 17:03:37 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YHQvtC30LTQsNGO0YLRgdGPINC00LjRgNC10LrRgtC+0YDQuNC4?= =?UTF-8?B?INC00LvRjyDQutGN0YjQsCDQuCBuZ2lueCDQvdC1INC60Y3RiNC40YDRg9C1?= =?UTF-8?B?0YIg0YTQsNC50LvRiw==?= In-Reply-To: <20150115133345.GP79857@mdounin.ru> References: <20150115133345.GP79857@mdounin.ru> Message-ID: Максим, вот (вроде бы) полный дебаг-лог одного соединения: http://pastebin.com/E6PZk8m2 Заголовков X-Accel-Expires и Vary, равно как и X-Accel-Redirect - нет. Это простой сайт на wordpress (на нем просто можно потестить конфиг, перед внедрением на другие сайты). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Jan 15 14:16:55 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 15 Jan 2015 17:16:55 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YHQvtC30LTQsNGO0YLRgdGPINC00LjRgNC10LrRgtC+0YDQuNC4?= =?UTF-8?B?INC00LvRjyDQutGN0YjQsCDQuCBuZ2lueCDQvdC1INC60Y3RiNC40YDRg9C1?= =?UTF-8?B?0YIg0YTQsNC50LvRiw==?= In-Reply-To: References: <20150115133345.GP79857@mdounin.ru> Message-ID: <20150115141655.GR79857@mdounin.ru> Hello! On Thu, Jan 15, 2015 at 05:03:37PM +0300, Maksim Kulik wrote: > Максим, вот (вроде бы) полный дебаг-лог одного соединения: > > http://pastebin.com/E6PZk8m2 > > Заголовков X-Accel-Expires и Vary, равно как и X-Accel-Redirect - нет. Это > простой сайт на wordpress (на нем просто можно потестить конфиг, перед > внедрением на другие сайты). Понятно, я просто проглядел в конфиге - у вас "proxy_buffering off;" стоит. Для того, чтобы кеш работал, proxy_buffering надо включить, т.к. режим при кешировании ответ пишется на диск именно механизмом буферизации. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Thu Jan 15 14:24:56 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 15 Jan 2015 17:24:56 +0300 Subject: =?UTF-8?B?UmU6IG5naW54LTEuNy45ICsgbmd4X2NhY2hlX3B1cmdlIDIuMyDRgtC10L/QtdGA?= =?UTF-8?B?0Ywg0YDQsNCx0L7RgtCw0LXRgiDRgtC+0LvRjNC60L4g0L/RgNC4INGB0L4=?= =?UTF-8?B?0LLQv9Cw0LTQtdC90LjQuCDQt9Cw0LPQvtC70L7QstC60LAgQWNjZXB0IDoo?= In-Reply-To: References: Message-ID: <20150115142456.GS79857@mdounin.ru> Hello! On Thu, Jan 15, 2015 at 03:54:23PM +0200, Олег Черн?й wrote: > Сегодня удивил эксперимент, при котором запрашивался блок, ложился в кэш и > без проблем этот кэш можно было почистить из браузера. > > Но при попытке запросить это же адрес на очистку из curl или wget получал > 404 и кеш не чистился. > > Как оказалось это реакция на несовпадение заголовка "Accept" при запросе > контента, который помещается в кэш и запроса который этот контент должен > удалить. Если заголовки совпадают -- все Ok, если нет - 404 и кэш не > чиститься. [...] > В бинарной части вначале файлика с кэшем видно, что добавился "запакованый" > заголовок "Accept", видимо проблема связана с этим. > > Не придумал ничего лучшего чем откатиться до nginx 1.7.6 + ngx_cache_purge > 2.1 -- там этой проблемы нет. Может в кэше можно этот "Accept" как-то > отрубить? Начиная с 1.7.7 nginx умеет обрабатывать заголовок Vary в ответах бекенда, кешируя несколько вариантов ответа: *) Изменение: теперь nginx учитывает при кэшировании строку "Vary" в заголовке ответа бэкенда. Если нужно, старое поведение можно вернуть с помощью директивы proxy_ignore_headers (http://nginx.org/r/proxy_ignore_headers/ru): proxy_ignore_headers Vary; Совсем правильное решение - убрать из ответов Vary бекенда, если он вам на самом деле не нужен. -- Maxim Dounin http://nginx.org/ From kulmaks at gmail.com Thu Jan 15 14:37:14 2015 From: kulmaks at gmail.com (Maksim Kulik) Date: Thu, 15 Jan 2015 17:37:14 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YHQvtC30LTQsNGO0YLRgdGPINC00LjRgNC10LrRgtC+0YDQuNC4?= =?UTF-8?B?INC00LvRjyDQutGN0YjQsCDQuCBuZ2lueCDQvdC1INC60Y3RiNC40YDRg9C1?= =?UTF-8?B?0YIg0YTQsNC50LvRiw==?= In-Reply-To: <20150115141655.GR79857@mdounin.ru> References: <20150115133345.GP79857@mdounin.ru> <20150115141655.GR79857@mdounin.ru> Message-ID: Спасибо! К сожалению, об этом не сказано в документации. А есть ли способ заставить nginx отдавать ответ клиенту не дожидаясь заполнения первого буфера, в том случае, если бэкенд медленно и по чуть-чуть отдает данные? Это необходимо для того, чтобы пользователь мог видеть прогресс-бар при некоторых длительных операциях обслуживания сайта. Например, gallery2 может создавать кэш изображений разных размеров по запросу. Операция довольно длительная и в процессе отображается прогресс-бар со счетчиком обработанных/оставшихся изображений. Данные идут по чуть-чуть и nginx даже при буфере в 4к отдает их клиенту очень не скоро. Может быть есть/будет какой-то таймаут для наполнения буфера? Скажем, если бэкенд начал отдавать данные, но не заполнил буфер за 5 секунд - отправить их клиенту. Это помогло бы не отключать буферизацию в описанном выше случае и, таким образом, сохранить возможность кэширования ответов. 15 января 2015 г., 17:16 пользователь Maxim Dounin написал: > Hello! > > On Thu, Jan 15, 2015 at 05:03:37PM +0300, Maksim Kulik wrote: > > > Максим, вот (вроде бы) полный дебаг-лог одного соединения: > > > > http://pastebin.com/E6PZk8m2 > > > > Заголовков X-Accel-Expires и Vary, равно как и X-Accel-Redirect - нет. > Это > > простой сайт на wordpress (на нем просто можно потестить конфиг, перед > > внедрением на другие сайты). > > Понятно, я просто проглядел в конфиге - у вас "proxy_buffering off;" > стоит. Для того, чтобы кеш работал, proxy_buffering надо > включить, т.к. режим при кешировании ответ пишется на диск > именно механизмом буферизации. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Jan 15 15:12:42 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 15 Jan 2015 18:12:42 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YHQvtC30LTQsNGO0YLRgdGPINC00LjRgNC10LrRgtC+0YDQuNC4?= =?UTF-8?B?INC00LvRjyDQutGN0YjQsCDQuCBuZ2lueCDQvdC1INC60Y3RiNC40YDRg9C1?= =?UTF-8?B?0YIg0YTQsNC50LvRiw==?= In-Reply-To: References: <20150115133345.GP79857@mdounin.ru> <20150115141655.GR79857@mdounin.ru> Message-ID: <20150115151241.GU79857@mdounin.ru> Hello! On Thu, Jan 15, 2015 at 05:37:14PM +0300, Maksim Kulik wrote: > Спасибо! > К сожалению, об этом не сказано в документации. > > А есть ли способ заставить nginx отдавать ответ клиенту не дожидаясь > заполнения первого буфера, в том случае, если бэкенд медленно и по > чуть-чуть отдает данные? Это необходимо для того, чтобы пользователь мог > видеть прогресс-бар при некоторых длительных операциях обслуживания сайта. > > Например, gallery2 может создавать кэш изображений разных размеров по > запросу. Операция довольно длительная и в процессе отображается > прогресс-бар со счетчиком обработанных/оставшихся изображений. Данные идут > по чуть-чуть и nginx даже при буфере в 4к отдает их клиенту очень не скоро. > Может быть есть/будет какой-то таймаут для наполнения буфера? Скажем, если > бэкенд начал отдавать данные, но не заполнил буфер за 5 секунд - отправить > их клиенту. Это помогло бы не отключать буферизацию в описанном выше случае > и, таким образом, сохранить возможность кэширования ответов. Проще всего использовать заголовок "X-Accel-Buffering: no" в тех ответах, где такое поведение действительно требуется. -- Maxim Dounin http://nginx.org/ From oleg.cherniy at gmail.com Thu Jan 15 15:29:39 2015 From: oleg.cherniy at gmail.com (=?UTF-8?B?0J7Qu9C10LMg0KfQtdGA0L3RltC5?=) Date: Thu, 15 Jan 2015 17:29:39 +0200 Subject: =?UTF-8?B?UmU6IG5naW54LTEuNy45ICsgbmd4X2NhY2hlX3B1cmdlIDIuMyDRgtC10L/QtdGA?= =?UTF-8?B?0Ywg0YDQsNCx0L7RgtCw0LXRgiDRgtC+0LvRjNC60L4g0L/RgNC4INGB0L4=?= =?UTF-8?B?0LLQv9Cw0LTQtdC90LjQuCDQt9Cw0LPQvtC70L7QstC60LAgQWNjZXB0IDoo?= In-Reply-To: <20150115142456.GS79857@mdounin.ru> References: <20150115142456.GS79857@mdounin.ru> Message-ID: Спасибо за ответ! 2015-01-15 16:24 GMT+02:00 Maxim Dounin : > Hello! > > On Thu, Jan 15, 2015 at 03:54:23PM +0200, Олег Черн?й wrote: > > > Сегодня удивил эксперимент, при котором запрашивался блок, ложился в кэш > и > > без проблем этот кэш можно было почистить из браузера. > > > > Но при попытке запросить это же адрес на очистку из curl или wget получал > > 404 и кеш не чистился. > > > > Как оказалось это реакция на несовпадение заголовка "Accept" при запросе > > контента, который помещается в кэш и запроса который этот контент должен > > удалить. Если заголовки совпадают -- все Ok, если нет - 404 и кэш не > > чиститься. > > [...] > > > В бинарной части вначале файлика с кэшем видно, что добавился > "запакованый" > > заголовок "Accept", видимо проблема связана с этим. > > > > Не придумал ничего лучшего чем откатиться до nginx 1.7.6 + > ngx_cache_purge > > 2.1 -- там этой проблемы нет. Может в кэше можно этот "Accept" как-то > > отрубить? > > Начиная с 1.7.7 nginx умеет обрабатывать заголовок Vary в ответах > бекенда, кешируя несколько вариантов ответа: > > *) Изменение: теперь nginx учитывает при кэшировании строку "Vary" в > заголовке ответа бэкенда. > > Если нужно, старое поведение можно вернуть с помощью директивы > proxy_ignore_headers (http://nginx.org/r/proxy_ignore_headers/ru): > > proxy_ignore_headers Vary; > Не помогло, в файлике кеша в бинарной части нету "Accept", но далее в тексте в заголовках есть "Vary: Accept" и все также не работает при разных "Accept". Совсем правильное решение - убрать из ответов Vary бекенда, если > он вам на самом деле не нужен. > Это помогло, сначала вырубил на бекенде без анализа кода: more_clear_headers 'Vary'; Потом нашел установку заголовка в движке. Большое спасибо -- проблема решена. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- --- С уважением, Олег Черний, руководитель отдела разработки AUTO.RIA.com RIA.com тел./факс.: 0 432 555-200 (многоканальний) моб: 0 (67) 295-27-52 E-mail: *oleg.cherniy at ria.ua * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Jan 15 17:04:29 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 15 Jan 2015 20:04:29 +0300 Subject: =?UTF-8?B?UmU6IG5naW54LTEuNy45ICsgbmd4X2NhY2hlX3B1cmdlIDIuMyDRgtC10L/QtdGA?= =?UTF-8?B?0Ywg0YDQsNCx0L7RgtCw0LXRgiDRgtC+0LvRjNC60L4g0L/RgNC4INGB0L4=?= =?UTF-8?B?0LLQv9Cw0LTQtdC90LjQuCDQt9Cw0LPQvtC70L7QstC60LAgQWNjZXB0IDoo?= In-Reply-To: References: <20150115142456.GS79857@mdounin.ru> Message-ID: <20150115170429.GW79857@mdounin.ru> Hello! On Thu, Jan 15, 2015 at 05:29:39PM +0200, Олег Черн?й wrote: > 2015-01-15 16:24 GMT+02:00 Maxim Dounin : [...] > > Если нужно, старое поведение можно вернуть с помощью директивы > > proxy_ignore_headers (http://nginx.org/r/proxy_ignore_headers/ru): > > > > proxy_ignore_headers Vary; > > > > Не помогло, в файлике кеша в бинарной части нету "Accept", но далее в > тексте в заголовках есть "Vary: Accept" и все также не работает при разных > "Accept". Если из бинарной части значение пропало - это говорит о том, что директива "proxy_ignore_headers Vary" отработала нормально. В тексте заголовок "Vary" и должен был остаться. То, что не помогло - странно, но возможно это какая-то ещё проблема ngx_cache_purge. [...] > Потом нашел установку заголовка в движке. Большое спасибо -- проблема > решена. Пожалуйста. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Fri Jan 16 10:11:42 2015 From: nginx-forum at nginx.us (dwow) Date: Fri, 16 Jan 2015 05:11:42 -0500 Subject: HTTP + HTTPS Message-ID: <2259165d8c97b2a9a2e5386eac3679ee.NginxMailingListRussian@forum.nginx.org> Добрый день, такой вопрос: - есть сервер, который может обрабатывать HTTP и HTTPS. - все запросы с HTTP перенаправляются на HTTPS если я хочу сделать обработку ошибок SSL, например, 495-ой, таким образом - перенаправлять пользователей обратно на HTTP, то в таком случае скорее всего произойдет зацикливание, правильно? Как правильнее сделать, чтобы пользователь могущий получить ответ по HTTPS, получал его, в противном случае по HTTP? Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256142,256142#msg-256142 From chipitsine at gmail.com Sat Jan 17 10:22:57 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 17 Jan 2015 16:22:57 +0600 Subject: HTTP + HTTPS In-Reply-To: <2259165d8c97b2a9a2e5386eac3679ee.NginxMailingListRussian@forum.nginx.org> References: <2259165d8c97b2a9a2e5386eac3679ee.NginxMailingListRussian@forum.nginx.org> Message-ID: возможно вас заинтесует http://ru.m.wikipedia.org/wiki/HSTS пятница, 16 января 2015 г. пользователь dwow написал: > Добрый день, > > такой вопрос: > - есть сервер, который может обрабатывать HTTP и HTTPS. > - все запросы с HTTP перенаправляются на HTTPS > > если я хочу сделать обработку ошибок SSL, например, 495-ой, таким образом - > перенаправлять пользователей обратно на HTTP, то в таком случае скорее > всего > произойдет зацикливание, правильно? > > Как правильнее сделать, чтобы пользователь могущий получить ответ по HTTPS, > получал его, в противном случае по HTTP? > > Спасибо! > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,256142,256142#msg-256142 > > _______________________________________________ > 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: From swood at fotofor.biz Sat Jan 17 23:33:44 2015 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 18 Jan 2015 03:33:44 +0400 Subject: =?UTF-8?B?0JfQsNC/0YDQtdGC0LjRgtGMINC40YHQv9C+0LvRjNC30L7QstCw0YLRjCBTUERZ?= Message-ID: Здравствуйте. Это, конечно, немного странный вопрос, но можно ли принудительно запретить на каком-то домене использовать spdy? То есть, принудительно его выключить? К сожалению, убирание spdy из listen не спасает. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Sun Jan 18 05:33:04 2015 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 18 Jan 2015 08:33:04 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: Message-ID: <863532951.20150118083304@softsearch.ru> Здравствуйте, Anton. > Это, конечно, немного странный вопрос, но можно ли принудительно > запретить на каком-то домене использовать spdy? То есть, > принудительно его выключить? К сожалению, убирание spdy из listen не > спасает. Если я правильно всё пониманию, то spdy надо специально включать в конфиге nginx-а, чтобы по нему начали ходить. Так что его выключение состоит в не включении. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mva at mva.name Sun Jan 18 05:42:55 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 18 Jan 2015 11:42:55 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <863532951.20150118083304@softsearch.ru> References: <863532951.20150118083304@softsearch.ru> Message-ID: <5509208.bjILZFVDWb@note> В письме от Вс, 18 января 2015 08:33:04 пользователь Михаил Монашёв написал: > Если я правильно всё пониманию, то spdy надо специально включать в > конфиге nginx-а, чтобы по нему начали ходить. Так что его выключение > состоит в не включении. Так ведь, на сколько я понял, товарищ хочет чтобы работало для всех server{} кроме одного. И жалуется, что недобавления spdy в listen в этом server{} не достаточно для того, чтобы SPDY в нём не работал. // надеюсь, телепатический шлем отработал без ошибок -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From swood at fotofor.biz Sun Jan 18 11:52:55 2015 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 18 Jan 2015 15:52:55 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <5509208.bjILZFVDWb@note> References: <863532951.20150118083304@softsearch.ru> <5509208.bjILZFVDWb@note> Message-ID: Здравствуйте. Да, все равно так. Я хочу принудительно выключить spdy для конкретного сервера. Так как, по удивительным причинам, не указывание spdy в конфиге не отменяет факта, что chrome берет и поднимает spdy соединение. Ну фантастика. Но по конфигу работать не должно. Но работает. 18 января 2015 г., 8:42 пользователь Vadim A. Misbakh-Soloviov написал: > В письме от Вс, 18 января 2015 08:33:04 пользователь Михаил Монашёв > написал: > > Если я правильно всё пониманию, то spdy надо специально включать в > > конфиге nginx-а, чтобы по нему начали ходить. Так что его выключение > > состоит в не включении. > > Так ведь, на сколько я понял, товарищ хочет чтобы работало для всех > server{} > кроме одного. И жалуется, что недобавления spdy в listen в этом server{} не > достаточно для того, чтобы SPDY в нём не работал. > > // надеюсь, телепатический шлем отработал без ошибок > > -- > Best regards, > mva > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Sun Jan 18 12:44:33 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Sun, 18 Jan 2015 14:44:33 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: <863532951.20150118083304@softsearch.ru> <5509208.bjILZFVDWb@note> Message-ID: <54BBAAB1.7000206@csdoc.com> On 18.01.2015 13:52, Anton Kiryushkin wrote: > Я хочу принудительно выключить spdy для конкретного сервера. > Так как, по удивительным причинам, не указывание spdy в конфиге > не отменяет факта, что chrome берет и поднимает spdy соединение. > Ну фантастика. Но по конфигу работать не должно. Но работает. spdy в nginx - это параметр сокета, а не виртуального сервера: http://nginx.org/en/docs/http/ngx_http_core_module.html#listen -- Best regards, Gena From mva at mva.name Sun Jan 18 12:49:52 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 18 Jan 2015 18:49:52 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <54BBAAB1.7000206@csdoc.com> References: <54BBAAB1.7000206@csdoc.com> Message-ID: <1750894.Qk6b0EDQ3Z@note> В письме от Вс, 18 января 2015 14:44:33 пользователь Gena Makhomed написал: > spdy в nginx - это параметр сокета, а не виртуального сервера: > http://nginx.org/en/docs/http/ngx_http_core_module.html#listen ... и отсюда следует что Вы, Anton Kiryushkin), впринципе, можете иметь spdy выключенным для конкретного server{} и включенным для остальных... Только данный server{} должен слушать отдельный от остальных сокет :) // раз уж начали прямыми подсказками сыпать, то можно и продолжить... :D -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From swood at fotofor.biz Sun Jan 18 14:17:11 2015 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 18 Jan 2015 18:17:11 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <1750894.Qk6b0EDQ3Z@note> References: <54BBAAB1.7000206@csdoc.com> <1750894.Qk6b0EDQ3Z@note> Message-ID: Да, прекрасно. Вот только я не могу слушать отдельный сокет. 18 января 2015 г., 15:49 пользователь Vadim A. Misbakh-Soloviov < mva at mva.name> написал: > В письме от Вс, 18 января 2015 14:44:33 пользователь Gena Makhomed написал: > > > spdy в nginx - это параметр сокета, а не виртуального сервера: > > http://nginx.org/en/docs/http/ngx_http_core_module.html#listen > > > ... и отсюда следует что Вы, Anton Kiryushkin), впринципе, можете иметь > spdy > выключенным для конкретного server{} и включенным для остальных... > Только данный server{} должен слушать отдельный от остальных сокет :) > > > // раз уж начали прямыми подсказками сыпать, то можно и продолжить... :D > > -- > Best regards, > mva > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva at mva.name Sun Jan 18 15:16:11 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 18 Jan 2015 21:16:11 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: <1750894.Qk6b0EDQ3Z@note> Message-ID: <2912557.4yHFbuWRzt@note> В письме от Вс, 18 января 2015 18:17:11 пользователь Anton Kiryushkin написал: > Да, прекрасно. Вот только я не могу слушать отдельный сокет. Почему? -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From swood at fotofor.biz Sun Jan 18 15:56:50 2015 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 18 Jan 2015 19:56:50 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <2912557.4yHFbuWRzt@note> References: <1750894.Qk6b0EDQ3Z@note> <2912557.4yHFbuWRzt@note> Message-ID: У меня есть сервер, у которого один адрес. Nginx случает этот адрес на порту 443. И обрабатывает два адреса, для который используется один сертификат. Как, простите, тут можно использовать разные сокеты? Я чего-то не понимаю может быть? 18 января 2015 г., 18:16 пользователь Vadim A. Misbakh-Soloviov < mva at mva.name> написал: > В письме от Вс, 18 января 2015 18:17:11 пользователь Anton Kiryushkin > написал: > > Да, прекрасно. Вот только я не могу слушать отдельный сокет. > > Почему? > > > -- > Best regards, > mva > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From motienko at gmail.com Sun Jan 18 16:17:16 2015 From: motienko at gmail.com (Oleg Motienko) Date: Sun, 18 Jan 2015 20:17:16 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: <1750894.Qk6b0EDQ3Z@note> <2912557.4yHFbuWRzt@note> Message-ID: <К.О.> Докупите второй IP ? 2015-01-18 18:56 GMT+03:00 Anton Kiryushkin : > У меня есть сервер, у которого один адрес. Nginx случает этот адрес на порту > 443. И обрабатывает два адреса, для который используется один сертификат. > Как, простите, тут можно использовать разные сокеты? > Я чего-то не понимаю может быть? > -- Regards, Oleg From swood at fotofor.biz Sun Jan 18 16:50:30 2015 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 18 Jan 2015 20:50:30 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: <1750894.Qk6b0EDQ3Z@note> <2912557.4yHFbuWRzt@note> Message-ID: Спасибо за предложение. Проблема не в том, что у меня нет второго адреса. Вопрос мой ведь в другом, можно ли обойтись иными способами? 18 января 2015 г., 19:17 пользователь Oleg Motienko написал: > <К.О.> Докупите второй IP ? > > 2015-01-18 18:56 GMT+03:00 Anton Kiryushkin : > > У меня есть сервер, у которого один адрес. Nginx случает этот адрес на > порту > > 443. И обрабатывает два адреса, для который используется один сертификат. > > Как, простите, тут можно использовать разные сокеты? > > Я чего-то не понимаю может быть? > > > > -- > Regards, > Oleg > _______________________________________________ > 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: From postmaster at softsearch.ru Sun Jan 18 20:58:25 2015 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 18 Jan 2015 23:58:25 +0300 Subject: HTTP + HTTPS In-Reply-To: References: <2259165d8c97b2a9a2e5386eac3679ee.NginxMailingListRussian@forum.nginx.org> Message-ID: <926668008.20150118235825@softsearch.ru> Здравствуйте. > http://ru.m.wikipedia.org/wiki/HSTS Попробовали, заработало? -- С уважением, Михаил mailto:postmaster at softsearch.ru From mva at mva.name Sun Jan 18 21:17:17 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 19 Jan 2015 03:17:17 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: Message-ID: <2295484.iLMp3WfYXU@note> В письме от Вс, 18 января 2015 20:50:30 пользователь Anton Kiryushkin написал: > Спасибо за предложение. Проблема не в том, что у меня нет второго адреса. > Вопрос мой ведь в другом, можно ли обойтись иными способами? Можно: слушать на другом порту. Или вообще unix-сокет :) // а ещё, не помню, как у NginX с SCTP. -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From gmm at csdoc.com Mon Jan 19 11:27:56 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 19 Jan 2015 13:27:56 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: <1750894.Qk6b0EDQ3Z@note> <2912557.4yHFbuWRzt@note> Message-ID: <54BCEA3C.5070801@csdoc.com> On 18.01.2015 18:50, Anton Kiryushkin wrote: > Вопрос мой ведь в другом, можно ли обойтись иными способами? теоретически - да, если научить nginx смотреть на имя сервера в SNI и на основании этого имени включать или выключать SPDY практически - нет, потому что такая feature обычно мало кому интересна и нужна, раз такой патч так и не был предоставлен -- Best regards, Gena From vbart at nginx.com Mon Jan 19 12:42:54 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 19 Jan 2015 15:42:54 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <54BCEA3C.5070801@csdoc.com> References: <54BCEA3C.5070801@csdoc.com> Message-ID: <2224165.cBL30fZFYP@vbart-workstation> On Monday 19 January 2015 13:27:56 Gena Makhomed wrote: > On 18.01.2015 18:50, Anton Kiryushkin wrote: > > > Вопрос мой ведь в другом, можно ли обойтись иными способами? > > теоретически - да, если научить nginx смотреть на имя сервера > в SNI и на основании этого имени включать или выключать SPDY nginx научить то можно, а клиентов кто при этом научит не ходить на этот сервер по spdy? С точки зрения протокола spdy, его анонс на каком-либо соединении эквивалентен анонсу на всех виртуальных серверах с тем же портом, чьи домены резолвятся в тот же ip, имеют тот же порт и для которых валиден сертификат. Это позволяет запрашивать эти хосты в том же, уже открытом spdy-соединении, тем самым экономя хэндшейки - основной смысл spdy. Всё несколько сложнее, чем кажется. -- Валентин Бартенев From nginx-forum at nginx.us Mon Jan 19 14:16:54 2015 From: nginx-forum at nginx.us (dwow) Date: Mon, 19 Jan 2015 09:16:54 -0500 Subject: HTTP + HTTPS In-Reply-To: References: Message-ID: спасибо, заинтересовало! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256142,256196#msg-256196 From nginx-forum at nginx.us Mon Jan 19 14:21:30 2015 From: nginx-forum at nginx.us (dwow) Date: Mon, 19 Jan 2015 09:21:30 -0500 Subject: HTTP + HTTPS In-Reply-To: <926668008.20150118235825@softsearch.ru> References: <926668008.20150118235825@softsearch.ru> Message-ID: да, заработало, спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256142,256197#msg-256197 From _lsv_ at bk.ru Tue Jan 20 06:52:10 2015 From: _lsv_ at bk.ru (=?UTF-8?B?UyBM?=) Date: Tue, 20 Jan 2015 09:52:10 +0300 Subject: =?UTF-8?B?bG9jYXRpb24gcGhwINC00LvRjyDQv9GD0YLQtdC5INGBINC00LjRgNC+0Lk=?= Message-ID: <1421736730.588986410@f368.i.mail.ru> Всем привет, Вопросец есть. Как сделать для сайта на котором ссылки сделаны на каком-то фреймворке вроде http://127.0.0.1/login что-бы такие ссылки уходили на php-fpm? т.е. у меня         location  ^~ /old {         alias /www/oldsite; location ~ \.php$ {     fastcgi_pass 127.0.0.1:9000;     include fastcgi_params; } } работает для .php на конце А например вот так: location ~ login$ {.php     fastcgi_pass 127.0.0.1:9000;     include fastcgi_params; } все равно не работает для странички http://127.0.0.1/login а раньше этот сайт был просто в server root прописан и все работало: server {         listen 443;         root /www/site/;         index index.php; ... } т.е. проблема в том что в php не работают пути которые как-бы директории, а не php -файлы. Как их заставить работать в location? -- S L -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Tue Jan 20 11:28:07 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 20 Jan 2015 13:28:07 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <2224165.cBL30fZFYP@vbart-workstation> References: <54BCEA3C.5070801@csdoc.com> <2224165.cBL30fZFYP@vbart-workstation> Message-ID: <54BE3BC7.5060709@csdoc.com> On 19.01.2015 14:42, Валентин Бартенев wrote: >>> Вопрос мой ведь в другом, можно ли обойтись иными способами? >> >> теоретически - да, если научить nginx смотреть на имя сервера >> в SNI и на основании этого имени включать или выключать SPDY > > nginx научить то можно, а клиентов кто при этом научит не ходить > на этот сервер по spdy? > > С точки зрения протокола spdy, его анонс на каком-либо соединении > эквивалентен анонсу на всех виртуальных серверах с тем же портом, > чьи домены резолвятся в тот же ip, имеют тот же порт и для которых > валиден сертификат. Это позволяет запрашивать эти хосты в том же, > уже открытом spdy-соединении, тем самым экономя хэндшейки - основной > смысл spdy. > > Всё несколько сложнее, чем кажется. Раньше было необходимо для каждого HTTPS сайта покупать отдельный IP. Сейчас - поддержка SNI появилась уже практически во всех серверах и клиентах. Кроме того изменились ситуация с поисковыми машинами и появилась возможность получить бесплатный SSL сертификат: http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html https://letsencrypt.org/ https://www.cloudflare.com/ssl Поэтому в ближайшее время можно ожидать массовое использование SNI для HTTPS сайтов, в результате на одном и том же listen сокете IP:PORT будут десятки а то и сотни разных HTTPS-сайтов с разными сертификатами. Соответственно - можно будет управлять включением/выключением поддержки протокола SPDY для каждого из этих сайтов в отдельности. То есть, теоретически - это сделать возможно. Другой вопрос - что в этом нет какой-либо большой практической ценности, - совершенно не понятно зачем может кому-либо понадобиться "Запретить использовать SPDY". Тем более, что существует простой обходной вариант, - купить/взять в аренду два IP, для spdy on и spdy off соответственно. И даже если бы были какие-то веские причины, чтобы сделать spdy параметром сервера, а не параметром listen сокета - это сделать уже не получится, потому что тогда придется сломать обратную совместимость. То есть, овчинка выделки наверное не стоит. -- Best regards, Gena From nginx-forum at nginx.us Tue Jan 20 21:39:07 2015 From: nginx-forum at nginx.us (ShivaS) Date: Tue, 20 Jan 2015 16:39:07 -0500 Subject: =?UTF-8?B?0JLRi9C00LDQtdGC0YHRjyA0MDUg0L/RgNC4ICLQvdC10LrQvtC90LLQtdC90YY=?= =?UTF-8?B?0LjQvtC90LDQu9GM0L3Ri9GFIiBIVFRQINC80LXRgtC+0LTQsNGFINCyIHRy?= =?UTF-8?B?eSBmaWxlcyAkdXJpLw==?= Message-ID: <9761c1ccd42d7edc3e981aeeff8ecad8.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Помогите разобраться пожалуйста. Имеется: location / { try_files $uri $uri/ @somewhere; } location ~ \.php$ { limit_except GET POST { deny all; } ...... } При заходе на сайт/ (или директорию/) - всё стандартно отработало. А вот при использовании метода, отличного от GET/HEAD/POST, выдается 405 на $uri/. Т.е., несмотря на то, что у сайта определен индекс файл - index.php, видимо есть причины, по которым не прокидывается дальше на .php, а обрабатывается сразу в основном /. Почему не прокидываются в .php разные методы а-ля DELETE и т.д.? Может "запрещенный прием" на некий статический контент, порядок обработки или by design/rfc...? ИМХО, должно идти на индекс файл в найденной (и существующей) директории, и уже на него пытаться применить желаемый метод http, что в указанном примере должно выдать 403. Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256220,256220#msg-256220 From igor at sysoev.ru Wed Jan 21 14:17:47 2015 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 21 Jan 2015 17:17:47 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: <54BE3BC7.5060709@csdoc.com> References: <54BCEA3C.5070801@csdoc.com> <2224165.cBL30fZFYP@vbart-workstation> <54BE3BC7.5060709@csdoc.com> Message-ID: On 20 Jan 2015, at 14:28, Gena Makhomed wrote: > On 19.01.2015 14:42, Валентин Бартенев wrote: > >>>> Вопрос мой ведь в другом, можно ли обойтись иными способами? >>> >>> теоретически - да, если научить nginx смотреть на имя сервера >>> в SNI и на основании этого имени включать или выключать SPDY >> >> nginx научить то можно, а клиентов кто при этом научит не ходить >> на этот сервер по spdy? >> >> С точки зрения протокола spdy, его анонс на каком-либо соединении >> эквивалентен анонсу на всех виртуальных серверах с тем же портом, >> чьи домены резолвятся в тот же ip, имеют тот же порт и для которых >> валиден сертификат. Это позволяет запрашивать эти хосты в том же, >> уже открытом spdy-соединении, тем самым экономя хэндшейки - основной >> смысл spdy. >> >> Всё несколько сложнее, чем кажется. > > Раньше было необходимо для каждого HTTPS сайта покупать отдельный IP. > > Сейчас - поддержка SNI появилась уже практически во всех серверах > и клиентах. Кроме того изменились ситуация с поисковыми машинами > и появилась возможность получить бесплатный SSL сертификат: > > http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html > > https://letsencrypt.org/ > > https://www.cloudflare.com/ssl > > Поэтому в ближайшее время можно ожидать массовое использование SNI > для HTTPS сайтов, в результате на одном и том же listen сокете IP:PORT > будут десятки а то и сотни разных HTTPS-сайтов с разными сертификатами. > > Соответственно - можно будет управлять включением/выключением поддержки > протокола SPDY для каждого из этих сайтов в отдельности. > То есть, теоретически - это сделать возможно. Теоретичкески - невозможно. Есть два сервера на одном listen сокете. Один со SPDY, второй - нет. Пользователь запросил первый сервер. Браузер установил SPDY-соединение к первому. Потом пользователь запросил второй сервер. Браузер пошлёт этот запрос по этому же самому SPDY-соединению. Как его обработать не в рамках SPDY-протокола? Закрыть stream? Вполне возможно, что браузер после этого вообще перестанет работать с данным IP-адресом по SPDY. -- Igor Sysoev http://nginx.com From gmm at csdoc.com Wed Jan 21 15:33:45 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 21 Jan 2015 17:33:45 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg?= =?UTF-8?B?U1BEWQ==?= In-Reply-To: References: <54BCEA3C.5070801@csdoc.com> <2224165.cBL30fZFYP@vbart-workstation> <54BE3BC7.5060709@csdoc.com> Message-ID: <54BFC6D9.8090808@csdoc.com> On 21.01.2015 16:17, Igor Sysoev wrote: >>>>> Вопрос мой ведь в другом, можно ли обойтись иными способами? >>>> >>>> теоретически - да, если научить nginx смотреть на имя сервера >>>> в SNI и на основании этого имени включать или выключать SPDY >>> >>> nginx научить то можно, а клиентов кто при этом научит не ходить >>> на этот сервер по spdy? >>> >>> С точки зрения протокола spdy, его анонс на каком-либо соединении >>> эквивалентен анонсу на всех виртуальных серверах с тем же портом, >>> чьи домены резолвятся в тот же ip, имеют тот же порт и для которых >>> валиден сертификат. Это позволяет запрашивать эти хосты в том же, >>> уже открытом spdy-соединении, тем самым экономя хэндшейки - основной >>> смысл spdy. >>> >>> Всё несколько сложнее, чем кажется. >> >> Раньше было необходимо для каждого HTTPS сайта покупать отдельный IP. >> >> Сейчас - поддержка SNI появилась уже практически во всех серверах >> и клиентах. Кроме того изменились ситуация с поисковыми машинами >> и появилась возможность получить бесплатный SSL сертификат: >> >> http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html >> >> https://letsencrypt.org/ >> >> https://www.cloudflare.com/ssl >> >> Поэтому в ближайшее время можно ожидать массовое использование SNI >> для HTTPS сайтов, в результате на одном и том же listen сокете IP:PORT >> будут десятки а то и сотни разных HTTPS-сайтов с разными сертификатами. >> >> Соответственно - можно будет управлять включением/выключением поддержки >> протокола SPDY для каждого из этих сайтов в отдельности. >> То есть, теоретически - это сделать возможно. > > Теоретичкески - невозможно. > Есть два сервера на одном listen сокете. Один со SPDY, второй - нет. > Пользователь запросил первый сервер. Браузер установил SPDY-соединение к > первому. Потом пользователь запросил второй сервер. Браузер пошлёт этот > запрос по этому же самому SPDY-соединению. Браузер пошлет этот запрос только в том случае, если сертификат первого сервера будет валидным для второго сервера. У первого сервера сертификат на имя www.example.com а у второго - сертификат на имя www.example.net Разве в этой ситуации браузер пришлет запрос на сервер www.example.net используя установленное подключение с сертификатом www.example.com? > Как его обработать не в рамках > SPDY-протокола? Закрыть stream? Вполне возможно, что браузер после этого > вообще перестанет работать с данным IP-адресом по SPDY. Да, если сертификат окажется валидным и для первого и для второго имени, тогда раздельно включать/выключать протокол SPDY для них не получится. В такой ситуации nginx может выдать пользователю warning о том, что не смотря на отсутствие параметра spdy в директиве listen, протокол SPDY всеравно будет включен для этого сервера. Если клиент в SNI прислал одно имя сервера, а фактически пытается делать запросы к другому имени сервера, это будет выглядеть как попытка взлома. А в RFC https://tools.ietf.org/html/rfc6066#section-3 написано что клиент SHOULD NOT так делать. -- Best regards, Gena From nginx-forum at nginx.us Wed Jan 21 21:19:21 2015 From: nginx-forum at nginx.us (tigran.bayburtsyan) Date: Wed, 21 Jan 2015 16:19:21 -0500 Subject: =?UTF-8?B?0JXRgdGC0Ywg0LvQuCBIYW5kbGVyINC00LvRjyDQt9Cw0LrRgNGL0YLQuNGPINGB?= =?UTF-8?B?0L7QtdC00LXQvdC10L3QuNGPL9C30LDQv9GA0L7RgdCwINC40LvQuCDQuiA=?= =?UTF-8?B?0L7QutC+0L3Rh9Cw0L3QuNC4INC+0YLQv9GA0LDQstC60Lgg0LTQsNC90L0=?= =?UTF-8?B?0YvRhSA/?= Message-ID: <2b354a3f35d1688f0d90fe4aface650d.NginxMailingListRussian@forum.nginx.org> Привет. Есть проблема с получением кокого то хандлера который бы вызывался когда все данные в out_chain переданны клиенту или когда соеденение с клиентом уже закрыто. Например вызываю комбинацыю этих функцый для отправки данных в out_chain. Поскольку у меня данные больше 700КБ то все равно эта функцыя не отправит все за раз, и мне бы хотелось вызвать кокойто callback или хандлер при окончании отправки данных, или же при закрытии соеденения с клиентом. ngx_http_finalize_request(r, ngx_http_output_filter ( r , out_chain )); Я так думаю что чтото подобное должно быть в цыкле Nginx но не нахажу ничего. Более важно получить хандлер для закрытия соедения с клиентом, но хандлер окончания отправки тоже сайдет. Спасибо заранее :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256235,256235#msg-256235 From _lsv_ at bk.ru Thu Jan 22 07:26:05 2015 From: _lsv_ at bk.ru (=?UTF-8?B?UyBM?=) Date: Thu, 22 Jan 2015 10:26:05 +0300 Subject: nginx/1.4.6 spdy In-Reply-To: <1421736730.588986410@f368.i.mail.ru> References: <1421736730.588986410@f368.i.mail.ru> Message-ID: <1421911565.964286224@f177.i.mail.ru> Всем привет,вопрос касательно нового протокола spdy. на сервере делаю listen 443 ssl spdy; но клиент не выдает никаких новых заголовков. от гугла проходит вот такой заголовок: X-Firefox-Spdy:"3.1" nginx/1.4.6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Thu Jan 22 07:57:26 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 22 Jan 2015 10:57:26 +0300 Subject: nginx/1.4.6 spdy In-Reply-To: <1421911565.964286224@f177.i.mail.ru> References: <1421736730.588986410@f368.i.mail.ru> <1421911565.964286224@f177.i.mail.ru> Message-ID: <3952701.e3IDGAiBS1@vbart-laptop> On Thursday 22 January 2015 10:26:05 S L wrote: > Всем привет,вопрос касательно нового протокола spdy. > > на сервере делаю > > listen 443 ssl spdy; > > но клиент не выдает никаких новых заголовков. > > от гугла проходит вот такой заголовок: > > X-Firefox-Spdy:"3.1" От гугла не приходит таких заголовков, этот заголовок добавляет сам Firefox к ответу сервера при работе по spdy/3.1. > > nginx/1.4.6 > У вас слишком древняя версия nginx, в которой реализована версия протокола spdy/2, поддержку которой уже исключили из современных браузеров. Вам стоит обновить nginx до 1.7.9. -- Валентин Бартенев From denis at webmaster.spb.ru Thu Jan 22 09:02:04 2015 From: denis at webmaster.spb.ru (denis) Date: Thu, 22 Jan 2015 12:02:04 +0300 Subject: nginx/1.4.6 spdy In-Reply-To: <3952701.e3IDGAiBS1@vbart-laptop> References: <1421736730.588986410@f368.i.mail.ru> <1421911565.964286224@f177.i.mail.ru> <3952701.e3IDGAiBS1@vbart-laptop> Message-ID: <54C0BC8C.6060109@webmaster.spb.ru> 22.01.2015 10:57, Валентин Бартенев пишет: > У вас слишком древняя версия nginx, в которой реализована > версия протокола spdy/2, поддержку которой уже исключили > из современных браузеров. > > Вам стоит обновить nginx до 1.7.9. а можно список, какая версия какой протокол умеет? Лучше сразу на сайте From vbart at nginx.com Thu Jan 22 13:35:49 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 22 Jan 2015 16:35:49 +0300 Subject: nginx/1.4.6 spdy In-Reply-To: <54C0BC8C.6060109@webmaster.spb.ru> References: <1421736730.588986410@f368.i.mail.ru> <3952701.e3IDGAiBS1@vbart-laptop> <54C0BC8C.6060109@webmaster.spb.ru> Message-ID: <1462704.JFmWvQ9qjI@vbart-workstation> On Thursday 22 January 2015 12:02:04 denis wrote: > 22.01.2015 10:57, Валентин Бартенев пишет: > > У вас слишком древняя версия nginx, в которой реализована > > версия протокола spdy/2, поддержку которой уже исключили > > из современных браузеров. > > > > Вам стоит обновить nginx до 1.7.9. > > а можно список, какая версия какой протокол умеет? Лучше сразу на сайте > Об этом в документации по spdy модулю написано: http://nginx.org/ru/docs/http/ngx_http_spdy_module.html -- Валентин Бартенев From nginx-forum at nginx.us Fri Jan 23 14:51:18 2015 From: nginx-forum at nginx.us (Kouki) Date: Fri, 23 Jan 2015 09:51:18 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgQUpBWA==?= In-Reply-To: References: Message-ID: <86ed229ac759b9f66279bcde5ed2d538.NginxMailingListRussian@forum.nginx.org> Вот сделал пример с другими данными. Здесь запросы идентичны, куки одной строкой и пр. Но проблема та же. http://forums.pentaho.com/showthread.php?180602-Saiku-through-proxy-(nginx)&p=398850&posted=1#post398850 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255278,256247#msg-256247 From chipitsine at gmail.com Fri Jan 23 16:53:30 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 23 Jan 2015 21:53:30 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgQUpBWA==?= In-Reply-To: <86ed229ac759b9f66279bcde5ed2d538.NginxMailingListRussian@forum.nginx.org> References: <86ed229ac759b9f66279bcde5ed2d538.NginxMailingListRussian@forum.nginx.org> Message-ID: у вас хедер Host разный. возможно, что ваше приложение не хочет отвечать 200 из-за этого еще может быть тыща других причин. есть определенная логика в том, чтобы посмотреть логи приложения. почему вы хотите именно угадывать? еще странный момент, в обоих случаях кука с сессией дублируется пятница, 23 января 2015 г. пользователь Kouki написал: > Вот сделал пример с другими данными. Здесь запросы идентичны, куки одной > строкой и пр. Но проблема та же. > > http://forums.pentaho.com/showthread.php?180602-Saiku-through-proxy-(nginx)&p=398850&posted=1#post398850 > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,255278,256247#msg-256247 > > _______________________________________________ > 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: From nginx-forum at nginx.us Fri Jan 23 17:13:12 2015 From: nginx-forum at nginx.us (Kouki) Date: Fri, 23 Jan 2015 12:13:12 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgQUpBWA==?= In-Reply-To: References: Message-ID: <0a3552af5bf3a888d47d880b0f06bb7b.NginxMailingListRussian@forum.nginx.org> Host должен быть разный? Вот конфиг для данного примера: server { listen 80; server_name olap.ru; location / { proxy_pass http://192.168.133.131:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } Логи приложения я смотрел в первую очередь. Никакой реакции на эту ошибку там нет. Возможен вариант, что nginx каким-то образом меняет исходный запрос, шлет его приложению, а оно выдает ему соответствующее кривое содержимое, которое оно не считает за ошибку. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255278,256251#msg-256251 From vbart at nginx.com Fri Jan 23 17:28:25 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 23 Jan 2015 20:28:25 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgQUpBWA==?= In-Reply-To: <0a3552af5bf3a888d47d880b0f06bb7b.NginxMailingListRussian@forum.nginx.org> References: <0a3552af5bf3a888d47d880b0f06bb7b.NginxMailingListRussian@forum.nginx.org> Message-ID: <4680604.AKRNTU5Cad@vbart-workstation> On Friday 23 January 2015 12:13:12 Kouki wrote: > Host должен быть разный? Вот конфиг для данного примера: > > server { > listen 80; > server_name olap.ru; > > location / { > proxy_pass http://192.168.133.131:8080/; Есть большая разница между: proxy_pass http://192.168.133.131:8080/; и proxy_pass http://192.168.133.131:8080; Уберите слеш на конце и всё у вас заработает. -- Валентин Бартенев From chipitsine at gmail.com Fri Jan 23 17:29:43 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 23 Jan 2015 22:29:43 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgQUpBWA==?= In-Reply-To: <0a3552af5bf3a888d47d880b0f06bb7b.NginxMailingListRussian@forum.nginx.org> References: <0a3552af5bf3a888d47d880b0f06bb7b.NginxMailingListRussian@forum.nginx.org> Message-ID: я имею в виду хедер Host, отправляемый в сторону приложения. в двух приведенных вами примерах он разный. статус ответа 400 отдает вам ваше приложение. это видно из приведенной вами диагностики, nginx-у не остается ничего другого кроме как отдать это статус дальше но проблема и причина тут не в nginx. и правды искать на форуме nginx можно, но, кажется более логичным поискать на стороне приложения. если в логах ничего нет, как вы говорите, можно взять исходники Apache/Coyote и навтыкать в них отладки. пятница, 23 января 2015 г. пользователь Kouki написал: > Host должен быть разный? Вот конфиг для данного примера: > > server { > listen 80; > server_name olap.ru; > > location / { > proxy_pass http://192.168.133.131:8080/; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > } > } > > Логи приложения я смотрел в первую очередь. Никакой реакции на эту ошибку > там нет. > Возможен вариант, что nginx каким-то образом меняет исходный запрос, шлет > его приложению, а оно выдает ему соответствующее кривое содержимое, которое > оно не считает за ошибку. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,255278,256251#msg-256251 > > _______________________________________________ > 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: From nginx-forum at nginx.us Fri Jan 23 19:23:14 2015 From: nginx-forum at nginx.us (Kouki) Date: Fri, 23 Jan 2015 14:23:14 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgQUpBWA==?= In-Reply-To: <4680604.AKRNTU5Cad@vbart-workstation> References: <4680604.AKRNTU5Cad@vbart-workstation> Message-ID: Спасибо. Никогда бы не подумал, что в этом проблема. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255278,256254#msg-256254 From nginx-forum at nginx.us Sat Jan 24 11:26:40 2015 From: nginx-forum at nginx.us (Sollomon) Date: Sat, 24 Jan 2015 06:26:40 -0500 Subject: =?UTF-8?B?bmdpbngg0L/RgNC4INCn0J/QoyDQstGL0LTQsNC10YIg0L3QsCDRgdGC0YDQsNC9?= =?UTF-8?B?0LjRhtGDINGB0LrRgNC40L/RgiDQsiDRgdGL0YDQvtC8INCy0LjQtNC1Lg==?= Message-ID: <20ac942cf933d7b4c31ec02b600cef66.NginxMailingListRussian@forum.nginx.org> Решил переехать с апача на нгинкс, все как бы не поблема, все работает, пока не дошло дело до ЧПУ. Вроде как бы и работает ЧПУ, ибо браузер то отдает страницу нужную, но загвоздка в том, что выдает в сыром виде, ни пхп, даже хтмл не обрабатывается в браузере и выдает все в сыром виде, как прописано в самом скрипте, с хтмл-тегами, и пхп-кодом. Домен сайта условно назовем help.ru Сам конфиг домена. server { listen 80; server_name www.help.ru; rewrite ^ http://help.ru$request_uri? permanent; #301 redirect } server { listen 80; server_name help.ru; root /web/help/public_html/www; index index.php; #location / { # try_files $uri $uri/ /error404.html; #} autoindex off; location / { if ($query_string ~ "^$"){ rewrite ^/index.php$ http://$http_host/ redirect; } if ($http_host ~* "^www.help\.ru$"){ rewrite .? http://help.ru$request_uri redirect; } if (!-e $request_filename){ rewrite ^/referat.html$ /wiev.php?cat=Реферат break; } if ($query_string ~* "(<|%3C).*script.*(>|%3E)"){ return 403; } if ($query_string ~ "GLOBALS(=|[|%[0-9A-Z]{0,2})"){ return 403; } if ($query_string ~ "_REQUEST(=|[|%[0-9A-Z]{0,2})"){ return 403; } } location = /error404.html { rewrite ^(.*)$ /error404.php break; } location = /referat.html { rewrite ^(.*)$ /wiev.php?cat=Реферат break; } location = /kontrolnaya.html { rewrite ^(.*)$ /wiev.php?cat=Контрольная break; } location = /kyrsovaya.html { rewrite ^(.*)$ /wiev.php?cat=Курсовая break; } location = /search.html { rewrite ^(.*)$ /search.php break; } location = /regulations.html { rewrite ^(.*)$ /regulations.php break; } location = /contacts.html { rewrite ^(.*)$ /contacts.php break; } location = /news.html { rewrite ^(.*)$ /news.php break; } location = /input.html { rewrite ^(.*)$ /input.php break; } location /sub_ { rewrite ^/sub_([a-z]+).html$ /wievsub.php?sub=$1 break; rewrite ^/sub_([a-z]+)([0-9]+).html?$ /wievsub.php?sub=$1&page=$2 break; } location /referat { rewrite ^/referat([0-9]+).html?$ /wiev.php?cat=Реферат&page=$1 break; rewrite ^/referat/([0-9]+).html?$ /wievjob.php?id=$1 break; } location /kontrolnaya { rewrite ^/kontrolnaya([0-9]+).html?$ /wiev.php?cat=Контрольная&page=$1 break; rewrite ^/kontrolnaya/([0-9]+).html?$ /wievjob.php?id=$1 break; } location /kyrsovaya { rewrite ^/kyrsovaya([0-9]+).html?$ /wiev.php?cat=Курсовая&page=$1 break; rewrite ^/kyrsovaya/([0-9]+).html?$ /wievjob.php?id=$1 break; } location = /downloadjob.html { rewrite ^(.*)$ /downloadjob.php break; } location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico)$ { access_log off; expires max; } location ~ \.php$ { # fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /help.ru; fastcgi_param SCRIPT_FILENAME /help.ru$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /help.ru$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } ## Disable viewing .htaccess & .htpassword location ~ /\.ht { deny all; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256258,256258#msg-256258 From n.g.i.n.x.e.r at gmail.com Tue Jan 27 08:25:47 2015 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Tue, 27 Jan 2015 12:25:47 +0400 Subject: =?UTF-8?B?0J/QvtC00LLQuNGB0LDQvdC40Y8g0L/RgNC4INGA0LDRgdC/0LDQutC+0LLQutC1?= =?UTF-8?B?INCw0YDRhdC40LLQsA==?= Message-ID: Nginx перестает отдавать файлы при распаковке архивов с большим количеством файлов. Пробовал запускать через nice -n 15 ionice -c3 - не помогает. В чем может быть проблема? -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at webmaster.spb.ru Tue Jan 27 10:34:45 2015 From: denis at webmaster.spb.ru (denis) Date: Tue, 27 Jan 2015 13:34:45 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QtNCy0LjRgdCw0L3QuNGPINC/0YDQuCDRgNCw0YHQv9Cw0LrQvtCy?= =?UTF-8?B?0LrQtSDQsNGA0YXQuNCy0LA=?= In-Reply-To: References: Message-ID: <54C769C5.7090302@webmaster.spb.ru> 27.01.2015 11:25, Роман пишет: > Nginx перестает отдавать файлы при распаковке архивов с большим > количеством файлов. > > Пробовал запускать через nice -n 15 ionice -c3 - не помогает. > > В чем может быть проблема? > в логах? :) Скорее всего в лимит открытых файлов уперлись, но опять же - логи где? Сайта и общий. From vbart at nginx.com Tue Jan 27 14:17:32 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 27 Jan 2015 17:17:32 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QtNCy0LjRgdCw0L3QuNGPINC/0YDQuCDRgNCw0YHQv9Cw0LrQvtCy?= =?UTF-8?B?0LrQtSDQsNGA0YXQuNCy0LA=?= In-Reply-To: References: Message-ID: <2265663.MBfDqU9pZ9@vbart-laptop> On Tuesday 27 January 2015 12:25:47 Роман wrote: > Nginx перестает отдавать файлы при распаковке архивов с большим количеством > файлов. > > Пробовал запускать через nice -n 15 ionice -c3 - не помогает. > > В чем может быть проблема? > nginx не умеет распаковывать архивы. А при использовании сторонних модулей - это естественный результат. Распаковка архива блокирует рабочий процесс и тот не может обрабатывать соединения. Вывод: не надо распаковывать архивы nginx-ом, он для этого не предназначен. -- Валентин Бартенев From n.g.i.n.x.e.r at gmail.com Tue Jan 27 21:09:33 2015 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Wed, 28 Jan 2015 01:09:33 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNCy0LjRgdCw0L3QuNGPINC/0YDQuCDRgNCw0YHQv9Cw0LrQvtCy?= =?UTF-8?B?0LrQtSDQsNGA0YXQuNCy0LA=?= In-Reply-To: <2265663.MBfDqU9pZ9@vbart-laptop> References: <2265663.MBfDqU9pZ9@vbart-laptop> Message-ID: Про распаковывание с помощью nginx веселая шутка ) Все не совсем так. Я распаковываю tar архив в системе и независимо от того какие приоритеты я выставляю через какое то время nginx начинает медлить с ответом. Вот и возникает вопрос что надо подкрутить чтобы он не обращал на это внимание. Количество открытых файлов в системе я увеличил, но это не дает эффекта. 27 января 2015 г., 17:17 пользователь Валентин Бартенев написал: > On Tuesday 27 January 2015 12:25:47 Роман wrote: > > Nginx перестает отдавать файлы при распаковке архивов с большим > количеством > > файлов. > > > > Пробовал запускать через nice -n 15 ionice -c3 - не помогает. > > > > В чем может быть проблема? > > > > nginx не умеет распаковывать архивы. > > А при использовании сторонних модулей - это естественный результат. > Распаковка архива блокирует рабочий процесс и тот не может обрабатывать > соединения. Вывод: не надо распаковывать архивы nginx-ом, он для этого > не предназначен. > > -- > Валентин Бартенев > _______________________________________________ > 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: From denis at webmaster.spb.ru Tue Jan 27 21:44:14 2015 From: denis at webmaster.spb.ru (denis) Date: Wed, 28 Jan 2015 00:44:14 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QtNCy0LjRgdCw0L3QuNGPINC/0YDQuCDRgNCw0YHQv9Cw0LrQvtCy?= =?UTF-8?B?0LrQtSDQsNGA0YXQuNCy0LA=?= In-Reply-To: References: <2265663.MBfDqU9pZ9@vbart-laptop> Message-ID: <54C806AE.50408@webmaster.spb.ru> 28.01.2015 0:09, Роман пишет: > Про распаковывание с помощью nginx веселая шутка ) > > Все не совсем так. > > Я распаковываю tar архив в системе и независимо от того какие > приоритеты я выставляю через какое то время nginx начинает медлить с > ответом. > Вот и возникает вопрос что надо подкрутить чтобы он не обращал на это > внимание. > Количество открытых файлов в системе я увеличил, но это не дает эффекта. > Телепаты в отпуске. В логах что? И можно еще дебаг-лог включить. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Wed Jan 28 05:29:27 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 28 Jan 2015 11:29:27 +0600 Subject: =?UTF-8?B?UmU6INCf0L7QtNCy0LjRgdCw0L3QuNGPINC/0YDQuCDRgNCw0YHQv9Cw0LrQvtCy?= =?UTF-8?B?0LrQtSDQsNGA0YXQuNCy0LA=?= In-Reply-To: References: <2265663.MBfDqU9pZ9@vbart-laptop> Message-ID: ionice 28 января 2015 г., 2:09 пользователь Роман написал: > Про распаковывание с помощью nginx веселая шутка ) > > Все не совсем так. > > Я распаковываю tar архив в системе и независимо от того какие приоритеты я > выставляю через какое то время nginx начинает медлить с ответом. > Вот и возникает вопрос что надо подкрутить чтобы он не обращал на это > внимание. > Количество открытых файлов в системе я увеличил, но это не дает эффекта. > > > > > 27 января 2015 г., 17:17 пользователь Валентин Бартенев > написал: >> >> On Tuesday 27 January 2015 12:25:47 Роман wrote: >> > Nginx перестает отдавать файлы при распаковке архивов с большим >> > количеством >> > файлов. >> > >> > Пробовал запускать через nice -n 15 ionice -c3 - не помогает. >> > >> > В чем может быть проблема? >> > >> >> nginx не умеет распаковывать архивы. >> >> А при использовании сторонних модулей - это естественный результат. >> Распаковка архива блокирует рабочий процесс и тот не может обрабатывать >> соединения. Вывод: не надо распаковывать архивы nginx-ом, он для этого >> не предназначен. >> >> -- >> Валентин Бартенев >> _______________________________________________ >> 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 sytar.alex at gmail.com Wed Jan 28 05:32:13 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Wed, 28 Jan 2015 09:32:13 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNCy0LjRgdCw0L3QuNGPINC/0YDQuCDRgNCw0YHQv9Cw0LrQvtCy?= =?UTF-8?B?0LrQtSDQsNGA0YXQuNCy0LA=?= In-Reply-To: <54C806AE.50408@webmaster.spb.ru> References: <2265663.MBfDqU9pZ9@vbart-laptop> <54C806AE.50408@webmaster.spb.ru> Message-ID: 28 января 2015 г., 0:44 пользователь denis написал: > 28.01.2015 0:09, Роман пишет: > > Про распаковывание с помощью nginx веселая шутка ) > > Все не совсем так. > > Я распаковываю tar архив в системе и независимо от того какие приоритеты > я выставляю через какое то время nginx начинает медлить с ответом. > Вот и возникает вопрос что надо подкрутить чтобы он не обращал на это > внимание. > Количество открытых файлов в системе я увеличил, но это не дает эффекта. > > Телепаты в отпуске. > В логах что? > > И можно еще дебаг-лог включить. > Все нормально, телепаты на месте. Подозреваю что вашей системе не хватает IO для того чтобы отдавать файлики через nginx и одновременно что-то делать с диском. Как вариант, ionice для распаковки понизить, для кеш-менеджера повысить. Угадал? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Jan 28 06:10:21 2015 From: nginx-forum at nginx.us (Dmitrij) Date: Wed, 28 Jan 2015 01:10:21 -0500 Subject: =?UTF-8?B?0J3QtdCy0L7Qt9C80L7QttC90L4g0LjQt9C80LXQvdC40YLRjCBkb2N1bWVudCBy?= =?UTF-8?B?b290?= Message-ID: Приветствую! Столкнулся со странным поведение Nginx. Никогда такого не наблюдал ранее. Если вкратце, то при указании любой root директории отличной от /usr/share/nginx/html для отсутствующего файла возвращается 404, для существующего возвращается 403 с соответствующей ошибкой в логе: 2015/01/28 09:02:00 [error] 29646#0: *1 "/srv/www/default/index.html" is forbidden (13: Permission denied), client: 109.172.78.32, server: dig.tips, request: "GET / HTTP/1.1", host: "dig.tips" 1. Права на весь путь от корня к root сайта выставлены 2. Права на /var/lib/nginx/tmp выставлены Вот nginx.conf: user nginx; worker_processes 1; error_log /var/log/nginx/error.log; #error_log /var/log/nginx/error.log notice; #error_log /var/log/nginx/error.log info; 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"'; client_header_buffer_size 1k; large_client_header_buffers 4 4k; gzip on; sendfile on; index index.php; include /etc/nginx/conf.d/*.conf; } Вот примитивный конфиг хоста, который работает с одним root и не работает с другим server { listen 80; server_name dig.tips; root /srv/www/default; # root /usr/share/nginx/html; location / { index index.html; } } Платформа: VPS flops.ru, Centos 6.5. Ставил разные версии nginx, результат одинаковый. Сложилось ощущение, что document_root где-то захардкодили. Кто сталкивался? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256299,256299#msg-256299 From aleksei at miheev.info Wed Jan 28 06:17:29 2015 From: aleksei at miheev.info (Aleksey Miheev) Date: Wed, 28 Jan 2015 13:17:29 +0700 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?= =?UTF-8?B?bnQgcm9vdA==?= References: Message-ID: <20150128131729.5e2967d8@gussie> SELinux? On Wed, 28 Jan 2015 01:10:21 -0500 "Dmitrij" wrote: > Приветствую! > > Столкнулся со странным поведение Nginx. Никогда такого не наблюдал > ранее. Если вкратце, то при указании любой root директории отличной от > /usr/share/nginx/html для отсутствующего файла возвращается 404, для > существующего возвращается 403 с соответствующей ошибкой в логе: > > 2015/01/28 09:02:00 [error] 29646#0: *1 "/srv/www/default/index.html" > is forbidden (13: Permission denied), client: 109.172.78.32, server: > dig.tips, request: "GET / HTTP/1.1", host: "dig.tips" > > 1. Права на весь путь от корня к root сайта выставлены > 2. Права на /var/lib/nginx/tmp выставлены > > Вот nginx.conf: > > user nginx; > worker_processes 1; > > error_log /var/log/nginx/error.log; > #error_log /var/log/nginx/error.log notice; > #error_log /var/log/nginx/error.log info; > > 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"'; > > client_header_buffer_size 1k; > large_client_header_buffers 4 4k; > > gzip on; > sendfile on; > index index.php; > > include /etc/nginx/conf.d/*.conf; > } > > > Вот примитивный конфиг хоста, который работает с одним root и не > работает с другим > > server { > listen 80; > server_name dig.tips; > root /srv/www/default; > # root /usr/share/nginx/html; > location / { > index index.html; > } > } > > Платформа: VPS flops.ru, Centos 6.5. Ставил разные версии nginx, > результат одинаковый. Сложилось ощущение, что document_root где-то > захардкодили. Кто сталкивался? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,256299,256299#msg-256299 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Warm Regards, Aleksei Miheev mailto:aleksei at miheev.info | xmpp:aleksei at miheev.info From sytar.alex at gmail.com Wed Jan 28 06:44:39 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Wed, 28 Jan 2015 10:44:39 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?= =?UTF-8?B?bnQgcm9vdA==?= In-Reply-To: References: Message-ID: 28 января 2015 г., 9:10 пользователь Dmitrij написал: > Приветствую! > > Столкнулся со странным поведение Nginx. Никогда такого не наблюдал ранее. > Если вкратце, то при указании любой root директории отличной от > /usr/share/nginx/html для отсутствующего файла возвращается 404, для > существующего возвращается 403 с соответствующей ошибкой в логе: > > 2015/01/28 09:02:00 [error] 29646#0: *1 "/srv/www/default/index.html" is > forbidden (13: Permission denied), client: 109.172.78.32, server: dig.tips, > request: "GET / HTTP/1.1", host: "dig.tips" > > 1. Права на весь путь от корня к root сайта выставлены > Нужны еще права на промежуточные папки. Они есть? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Jan 28 07:02:54 2015 From: nginx-forum at nginx.us (Dmitrij) Date: Wed, 28 Jan 2015 02:02:54 -0500 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?= =?UTF-8?B?bnQgcm9vdA==?= In-Reply-To: <20150128131729.5e2967d8@gussie> References: <20150128131729.5e2967d8@gussie> Message-ID: <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org> По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего обеда. Я ж developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь делать все нормально, однако за тенденциями не слежу. Все решается выключением SELinux. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256299,256302#msg-256302 From defan at nginx.com Wed Jan 28 07:08:43 2015 From: defan at nginx.com (Andrei Belov) Date: Wed, 28 Jan 2015 10:08:43 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?= =?UTF-8?B?bnQgcm9vdA==?= In-Reply-To: <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org> References: <20150128131729.5e2967d8@gussie> <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org> Message-ID: <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com> On 28 Jan 2015, at 10:02, Dmitrij wrote: > По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова > "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего обеда. Я ж > developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь делать все > нормально, однако за тенденциями не слежу. > > Все решается выключением SELinux. JFYI: http://nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/ From eugene.peregudov at gmail.com Wed Jan 28 07:26:44 2015 From: eugene.peregudov at gmail.com (Eugene Peregudov) Date: Wed, 28 Jan 2015 13:26:44 +0600 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?= =?UTF-8?B?bnQgcm9vdA==?= In-Reply-To: <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com> References: <20150128131729.5e2967d8@gussie> <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org> <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com> Message-ID: Andrei Belov писал(а) в своём письме Wed, 28 Jan 2015 13:08:43 +0600: > > On 28 Jan 2015, at 10:02, Dmitrij wrote: > >> По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова >> "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего обеда. >> Я ж >> developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь делать >> все >> нормально, однако за тенденциями не слежу. >> >> Все решается выключением SELinux. > > JFYI: > http://nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/ > ИМХО, очень зря решается выключением. В первую очередь разработчик приложения и мэйнтейнер должны знать и предоставить информацию о том, какие разрешения необходимы приложению для корректного выполнения, а в идеале еще и написать policy-файл. Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh (http://stopdisablingselinux.com/) -- With best regards, Eugene JONIK Peregudov mailto: eugene.peregudov at gmail.com From nginx-forum at nginx.us Wed Jan 28 08:14:37 2015 From: nginx-forum at nginx.us (alexvamp) Date: Wed, 28 Jan 2015 03:14:37 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUgbmdpbng=?= In-Reply-To: References: Message-ID: Добрый день Уважаемый! Простите что вопросом на вопрос! Вы разобрались как кешировать сторонние скрипты? А то я уже неделю пытаюсь найти этому решение - но что то пока не как. ткните носом куда капать - если есть така возможность. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,213636,256305#msg-256305 From vladget at gmail.com Wed Jan 28 08:38:45 2015 From: vladget at gmail.com (Vladimir Getmanshchuk) Date: Wed, 28 Jan 2015 10:38:45 +0200 Subject: CVE-2015-0235 - GHOST Message-ID: JFYI Here is a list of potential targets that we investigated (they all call *gethostbyname*, one way or another), but to the best of our knowledge, the buffer overflow cannot be triggered in any of them: apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, *nginx*, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd. http://seclists.org/oss-sec/2015/q1/283 -- Yours sincerely, Vladimir Getmanshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From thresh at nginx.com Wed Jan 28 08:55:09 2015 From: thresh at nginx.com (Konstantin Pavlov) Date: Wed, 28 Jan 2015 11:55:09 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?= =?UTF-8?B?bnQgcm9vdA==?= In-Reply-To: References: <20150128131729.5e2967d8@gussie> <27c792d075756e2abdbe67637819e8ee.NginxMailingListRussian@forum.nginx.org> <55FDE149-EE5D-4B14-853C-6A3E6B06D90B@nginx.com> Message-ID: <54C8A3ED.5080500@nginx.com> On 28/01/2015 10:26, Eugene Peregudov wrote: > Andrei Belov писал(а) в своём письме Wed, 28 Jan 2015 > 13:08:43 +0600: > >> >> On 28 Jan 2015, at 10:02, Dmitrij wrote: >> >>> По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова >>> "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего >>> обеда. Я ж >>> developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь >>> делать все >>> нормально, однако за тенденциями не слежу. >>> >>> Все решается выключением SELinux. >> >> JFYI: >> http://nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/ >> > ИМХО, очень зря решается выключением. В первую очередь разработчик > приложения и мэйнтейнер должны знать и предоставить информацию о том, > какие разрешения необходимы приложению для корректного выполнения, а в > идеале еще и написать policy-файл. Разрешения, упакованные в selinux-policy-targeted, вполне работают для конфигурации по-умолчанию. Если пользователь пакета меняет эту конфигурацию, логично и поменять правила для SELinux. Разрешать при этом на уровне пакета любые действия, которые может предпринять будущий пользователь, кажется еще большим злом, чем полное выключение SELinux этим самым пользователем. > Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh > (http://stopdisablingselinux.com/) -- Konstantin Pavlov From nginx-forum at nginx.us Wed Jan 28 19:47:05 2015 From: nginx-forum at nginx.us (iprok) Date: Wed, 28 Jan 2015 14:47:05 -0500 Subject: =?UTF-8?B?bmdpbngg0L/QtdGA0LXRgdGC0LDQtdGCINC+0YLQstC10YfQsNGC0Ywg0L3QsNCz?= =?UTF-8?B?0YDRg9C20LDRjyBJTyDQvdCwIDEwMCU=?= Message-ID: <0466431e7bb829389ca6f4e6008f184e.NginxMailingListRussian@forum.nginx.org> Есть сервер с несколькими десятками сайтов на Debian Wheezy amd64. nginx 1.6.2 отсюда deb http://nginx.org/packages/debian/ wheezy nginx Симптоматика следующая. Сначала приходит письмо от заббикса о превышение порога IO: CPU iowait time (hostname:system.cpu.util[,iowait]): 24.95 % Через несколько секунд перестают отвечать все сайты. nginx становится недоступен. Смотрю iotop, все процессы nginx выглядят так (disk read, disk write, swap in, io): 0.00 B/s 0.00 B/s 0.00 % 99.99 % nginx: worker process Честно говоря совершенно загадочная для меня ситуация, чтоб IO было большое, но ни записи ни чтения не происходило. Что это может быть? В error.log ничего за этот период нет. Вообще в логах не вижу ничего криминального. Места везде с запасом. По памяти: free -m total used free shared buffers cached Mem: 8002 7869 132 0 476 6001 -/+ buffers/cache: 1392 6610 Swap: 8191 0 8191 nginx.conf: user nginx; worker_processes 4; worker_rlimit_nofile 200000; error_log /var/log/nginx/error.log error; events { worker_connections 100000; # use epoll; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server_names_hash_max_size 2048; server_names_hash_bucket_size 64; server_tokens off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; proxy_cache_path /var/cache/nginx keys_zone=one:50m; limit_req_zone $binary_remote_addr zone=agency:1m rate=20r/m; limit_req_zone $binary_remote_addr zone=a7:1m rate=3r/s; limit_req_zone $binary_remote_addr zone=default:1m rate=10r/s; limit_req_zone $binary_remote_addr zone=global:10m rate=500r/s; limit_req zone=global burst=500; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent"'; log_format proxy '$http_host == $remote_addr - $remote_user [$time_local] "$request"' '$status $body_bytes_sent "$http_referer" '; log_format global '$http_host == $remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" "$http_user_agent" '; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 60; gzip on; gzip_types text/css application/x-javascript; gzip_vary on; reset_timedout_connection on; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Connection close; proxy_set_header Range ""; proxy_pass_header Content-Type; proxy_pass_header Last-Modified; proxy_pass_header Expires; client_max_body_size 50m; large_client_header_buffers 16 16k; client_body_buffer_size 256k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 300; proxy_buffer_size 64k; proxy_buffers 16 64k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; access_log /var/log/nginx/access.log global buffer=8k; server { listen :80 default_server; return 444; } server { listen 127.0.0.1:80 default_server; location /nginx_status { stub_status on; access_log off; } } include sites-enabled/*; include deploy-enabled/*; } В настройках виртуальных хостов никаких особенных настроек нет: location, root, access_log, error_log, proxy_pass. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256316,256316#msg-256316 From nginx-forum at nginx.us Wed Jan 28 20:31:13 2015 From: nginx-forum at nginx.us (tyoma) Date: Wed, 28 Jan 2015 15:31:13 -0500 Subject: =?UTF-8?B?0J/QvtCy0LXQtNC10L3QuNC1IHJvdW5kIHJvYmlu?= Message-ID: Добрый день. Вопрос в следующем: есть сервер nginx, выполняющий роль балансировщика нагрузки с конфигурацией: upstream backend { server 192.168.94.129; server 192.168.94.130; } server { location / { proxy_pass http://backend; } } При простой перезагрузке страницы сервер не меняется, хотя, насколько я понимаю должен, так как по умолчанию используется алгоритм планирования round robin. Почему так происходит? А при такой конфигурации: upstream backend { server 192.168.94.129 weight = 1; server 192.168.94.130 weight = 2; } server { location / { proxy_pass http://backend; } } все работает, как и ожидается - два перехода на второй сервер, а затем на первый. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256317,256317#msg-256317 From alex.hha at gmail.com Wed Jan 28 20:42:52 2015 From: alex.hha at gmail.com (Alex Domoradov) Date: Wed, 28 Jan 2015 22:42:52 +0200 Subject: =?UTF-8?B?UmU6INCf0L7QstC10LTQtdC90LjQtSByb3VuZCByb2Jpbg==?= In-Reply-To: References: Message-ID: keepalive? 2015-01-28 22:31 GMT+02:00 tyoma : > Добрый день. > > Вопрос в следующем: есть сервер nginx, выполняющий роль балансировщика > нагрузки с конфигурацией: > > upstream backend { > server 192.168.94.129; > server 192.168.94.130; > } > > server { > location / { > proxy_pass http://backend; > } > } > > При простой перезагрузке страницы сервер не меняется, хотя, насколько я > понимаю должен, так как по умолчанию используется алгоритм планирования > round robin. Почему так происходит? > > А при такой конфигурации: > > upstream backend { > server 192.168.94.129 weight = 1; > server 192.168.94.130 weight = 2; > } > > server { > location / { > proxy_pass http://backend; > } > } > > все работает, как и ожидается - два перехода на второй сервер, а затем на > первый. > > Спасибо. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,256317,256317#msg-256317 > > _______________________________________________ > 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: From nginx-forum at nginx.us Wed Jan 28 21:28:06 2015 From: nginx-forum at nginx.us (Helper code) Date: Wed, 28 Jan 2015 16:28:06 -0500 Subject: =?UTF-8?B?0KDQtdC00LjRgNC10LrRgiDQutCw0YLQsNC70L7Qs9CwINC90LAgaW5kZXguaHRt?= =?UTF-8?B?bCDQsdC10Lcg0LTQuNGA0LXQutGC0LjQstGLIElOREVY?= Message-ID: <6bb52fb0b0977516fb8127a2c6720c62.NginxMailingListRussian@forum.nginx.org> Здравствуйте! При обращении к каталогу директива "Index index.html" осуществляет внутренний редирект на файл index.html. Т.е. получить содержимое файла index.html можно по двум URL - site.ru/ и site.ru/index.html. Как при обращении к любому каталогу на сайте осуществить 301 редирект на файл index.html находящийся в этом каталоге? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256319,256319#msg-256319 From voron at amhost.net Wed Jan 28 21:28:01 2015 From: voron at amhost.net (Alex Vorona) Date: Wed, 28 Jan 2015 23:28:01 +0200 Subject: =?UTF-8?B?UmU6INCf0L7QtNCy0LjRgdCw0L3QuNGPINC/0YDQuCDRgNCw0YHQv9Cw0LrQvtCy?= =?UTF-8?B?0LrQtSDQsNGA0YXQuNCy0LA=?= In-Reply-To: References: <2265663.MBfDqU9pZ9@vbart-laptop> Message-ID: <54C95461.5020507@amhost.net> Пробуйте запускать распаковку через cgexec в группе с небольшим количеством памяти и придавленным IO. From nginx-forum at nginx.us Wed Jan 28 21:32:59 2015 From: nginx-forum at nginx.us (Helper code) Date: Wed, 28 Jan 2015 16:32:59 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUgbmdpbng=?= In-Reply-To: References: Message-ID: <9558bafc60200880bdf7b613e52e6bd7.NginxMailingListRussian@forum.nginx.org> anon Wrote: > Есть ли вообще смысл их кешировать? Нет. Эта задача стороннего сервера. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,213636,256321#msg-256321 From juriy.foboss at gmail.com Thu Jan 29 03:32:49 2015 From: juriy.foboss at gmail.com (Juriy Strashnov) Date: Thu, 29 Jan 2015 07:32:49 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDQvtGC0LLQtdGH0LDRgtGMINC9?= =?UTF-8?B?0LDQs9GA0YPQttCw0Y8gSU8g0L3QsCAxMDAl?= In-Reply-To: <0466431e7bb829389ca6f4e6008f184e.NginxMailingListRussian@forum.nginx.org> References: <0466431e7bb829389ca6f4e6008f184e.NginxMailingListRussian@forum.nginx.org> Message-ID: А как вообще выглядит график загрузки IO? Наблюдал что-то похожее на хостинге, где с нагрузкой не справлялась СХД. 2015-01-28 22:47 GMT+03:00 iprok : > Есть сервер с несколькими десятками сайтов на Debian Wheezy amd64. nginx > 1.6.2 отсюда > deb http://nginx.org/packages/debian/ wheezy nginx > > Симптоматика следующая. Сначала приходит письмо от заббикса о превышение > порога IO: > CPU iowait time (hostname:system.cpu.util[,iowait]): 24.95 % > > Через несколько секунд перестают отвечать все сайты. nginx становится > недоступен. Смотрю iotop, все процессы nginx выглядят так (disk read, disk > write, swap in, io): > > 0.00 B/s 0.00 B/s 0.00 % 99.99 % nginx: worker process > > Честно говоря совершенно загадочная для меня ситуация, чтоб IO было > большое, > но ни записи ни чтения не происходило. Что это может быть? В error.log > ничего за этот период нет. Вообще в логах не вижу ничего криминального. > Места везде с запасом. > По памяти: > free -m > total used free shared buffers cached > Mem: 8002 7869 132 0 476 6001 > -/+ buffers/cache: 1392 6610 > Swap: 8191 0 8191 > > nginx.conf: > > user nginx; > worker_processes 4; > worker_rlimit_nofile 200000; > > error_log /var/log/nginx/error.log error; > > events { > worker_connections 100000; > # use epoll; > } > > http { > include /etc/nginx/mime.types; > default_type application/octet-stream; > server_names_hash_max_size 2048; > server_names_hash_bucket_size 64; > > server_tokens off; > > ssl_session_cache shared:SSL:10m; > ssl_session_timeout 10m; > > proxy_cache_path /var/cache/nginx keys_zone=one:50m; > limit_req_zone $binary_remote_addr zone=agency:1m rate=20r/m; > limit_req_zone $binary_remote_addr zone=a7:1m rate=3r/s; > limit_req_zone $binary_remote_addr zone=default:1m rate=10r/s; > limit_req_zone $binary_remote_addr zone=global:10m rate=500r/s; > limit_req zone=global burst=500; > log_format main '$remote_addr - $remote_user [$time_local] "$request" > ' > '$status $body_bytes_sent "$http_referer" ' > '"$http_user_agent"'; > log_format proxy '$http_host == $remote_addr - $remote_user > [$time_local] "$request"' > '$status $body_bytes_sent "$http_referer" '; > > log_format global '$http_host == $remote_addr - $remote_user > [$time_local] "$request" ' > '$status $body_bytes_sent "$http_referer" > "$http_user_agent" '; > sendfile on; > tcp_nopush on; > tcp_nodelay on; > keepalive_timeout 60; > gzip on; > gzip_types text/css application/x-javascript; > gzip_vary on; > > reset_timedout_connection on; > > proxy_redirect off; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header Connection close; > proxy_set_header Range ""; > > proxy_pass_header Content-Type; > proxy_pass_header Last-Modified; > proxy_pass_header Expires; > > client_max_body_size 50m; > large_client_header_buffers 16 16k; > client_body_buffer_size 256k; > > proxy_connect_timeout 90; > proxy_send_timeout 90; > proxy_read_timeout 300; > > > proxy_buffer_size 64k; > proxy_buffers 16 64k; > proxy_busy_buffers_size 64k; > proxy_temp_file_write_size 64k; > > access_log /var/log/nginx/access.log global buffer=8k; > > > server { > listen :80 default_server; > return 444; > } > server { > listen 127.0.0.1:80 default_server; > location /nginx_status { > stub_status on; > access_log off; > } > } > include sites-enabled/*; > include deploy-enabled/*; > } > > В настройках виртуальных хостов никаких особенных настроек нет: location, > root, access_log, error_log, proxy_pass. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,256316,256316#msg-256316 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Juriy Strashnov Mob. +7 (953) 742-1550 E-mail: j.strashnov at me.com Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Jan 29 09:23:01 2015 From: nginx-forum at nginx.us (Dmitrij) Date: Thu, 29 Jan 2015 04:23:01 -0500 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC40LfQvNC10L3QuNGC0YwgZG9jdW1l?= =?UTF-8?B?bnQgcm9vdA==?= In-Reply-To: References: Message-ID: <5248b27204b421b585f3800bea02a2b9.NginxMailingListRussian@forum.nginx.org> Нет, вы не поняли. Я не веду речь о том, что не буду использовать технологию. Просто я не был в курсе и долбился с локализацией проблемы целый вечер. Лог Nginx писал сообщение, которое было стандартным для ситуации с кривыми правами на файл или его предка. А сейчас мне просто нужно было поднять машину для тестов, ничего серьезного и критичного. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256299,256326#msg-256326 From vbart at nginx.com Thu Jan 29 12:23:24 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 29 Jan 2015 15:23:24 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QstC10LTQtdC90LjQtSByb3VuZCByb2Jpbg==?= In-Reply-To: References: Message-ID: <1739728.BlEA0eRnd2@vbart-workstation> On Wednesday 28 January 2015 15:31:13 tyoma wrote: > Добрый день. > > Вопрос в следующем: есть сервер nginx, выполняющий роль балансировщика > нагрузки с конфигурацией: > > upstream backend { > server 192.168.94.129; > server 192.168.94.130; > } > > server { > location / { > proxy_pass http://backend; > } > } > > При простой перезагрузке страницы сервер не меняется, хотя, насколько я > понимаю должен, так как по умолчанию используется алгоритм планирования > round robin. Почему так происходит? [..] Один из них видимо не отвечает. -- Валентин Бартенев From mva at mva.name Thu Jan 29 20:02:24 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 30 Jan 2015 02:02:24 +0600 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0LrQsNGC0LDQu9C+0LPQsCDQvdCwIGluZGV4?= =?UTF-8?B?Lmh0bWwg0LHQtdC3INC00LjRgNC10LrRgtC40LLRiyBJTkRFWA==?= In-Reply-To: <6bb52fb0b0977516fb8127a2c6720c62.NginxMailingListRussian@forum.nginx.org> References: <6bb52fb0b0977516fb8127a2c6720c62.NginxMailingListRussian@forum.nginx.org> Message-ID: <2004407.AA34O4Zod5@note> В письме от Ср, 28 января 2015 16:28:06 пользователь Helper code написал: > Здравствуйте! > > При обращении к каталогу директива "Index index.html" осуществляет > внутренний редирект на файл index.html. Т.е. получить содержимое файла > index.html можно по двум URL - site.ru/ и site.ru/index.html. Как при > обращении к любому каталогу на сайте осуществить 301 редирект на файл > index.html находящийся в этом каталоге? > указать index в server{} а не в location{} -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From mva at mva.name Thu Jan 29 20:33:08 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 30 Jan 2015 02:33:08 +0600 Subject: CVE-2015-0235 - GHOST In-Reply-To: References: Message-ID: <1451400.2dAiVRubiR@note> Так уязвимость в glibc же ж, а не в коде приложений :) -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From igor at sysoev.ru Thu Jan 29 20:50:49 2015 From: igor at sysoev.ru (Igor Sysoev) Date: Thu, 29 Jan 2015 23:50:49 +0300 Subject: CVE-2015-0235 - GHOST In-Reply-To: <1451400.2dAiVRubiR@note> References: <1451400.2dAiVRubiR@note> Message-ID: <173A7B27-7054-48B9-92B1-1AA722F5D2F8@sysoev.ru> On 29 Jan 2015, at 23:33, Vadim A. Misbakh-Soloviov wrote: > Так уязвимость в glibc же ж, а не в коде приложений :) В сочетании nginx/glibc тоже нет уязвимости. -- Igor Sysoev http://nginx.com From mva at mva.name Thu Jan 29 21:01:48 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 30 Jan 2015 03:01:48 +0600 Subject: CVE-2015-0235 - GHOST In-Reply-To: <173A7B27-7054-48B9-92B1-1AA722F5D2F8@sysoev.ru> References: <1451400.2dAiVRubiR@note> <173A7B27-7054-48B9-92B1-1AA722F5D2F8@sysoev.ru> Message-ID: <2049570.GnheSYYI3L@note> В письме от Чт, 29 января 2015 23:50:49 пользователь Igor Sysoev написал: > В сочетании nginx/glibc тоже нет уязвимости. В общем случае ? да :) Но, на сколько я понял намёк ОП, он имеет в виду, что (не смотря на отсутствие PoC) потенциальная уязвимость есть (если подшаманить на основе exim-эксплойта) + иметь необновляемую годами систему "старым" glibс (2.2x<2.18), то может можно и словить. Мало ли, какие [умные люди] крутят NgX 0.7.x на МСВС каком-нибудь :) Ну, или какой-нибудь там Debian old-stable (а то и Maemo какой-нибудь. Любителей нестандартных развлечений ведь много). А так, да, в большинстве систем, где не забывают обновлять пакетную базу и вовремя "стабилизировать" новые версии (а юзеры не забывают обновляться) проблем быть, конечно, не должно. -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From igor at sysoev.ru Thu Jan 29 21:11:30 2015 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 30 Jan 2015 00:11:30 +0300 Subject: CVE-2015-0235 - GHOST In-Reply-To: <2049570.GnheSYYI3L@note> References: <1451400.2dAiVRubiR@note> <173A7B27-7054-48B9-92B1-1AA722F5D2F8@sysoev.ru> <2049570.GnheSYYI3L@note> Message-ID: On 30 Jan 2015, at 00:01, Vadim A. Misbakh-Soloviov wrote: > В письме от Чт, 29 января 2015 23:50:49 пользователь Igor Sysoev написал: >> В сочетании nginx/glibc тоже нет уязвимости. > > В общем случае ? да :) > > Но, на сколько я понял намёк ОП, он имеет в виду, что (не смотря на отсутствие > PoC) потенциальная уязвимость есть (если подшаманить на основе exim-эксплойта) > + иметь необновляемую годами систему "старым" glibс (2.2x<2.18), то может > можно и словить. > > Мало ли, какие [умные люди] крутят NgX 0.7.x на МСВС каком-нибудь :) Ну, или > какой-нибудь там Debian old-stable (а то и Maemo какой-нибудь. Любителей > нестандартных развлечений ведь много). > > А так, да, в большинстве систем, где не забывают обновлять пакетную базу и > вовремя "стабилизировать" новые версии (а юзеры не забывают обновляться) > проблем быть, конечно, не должно. nginx перед вызовом gethostbyname() вызывает свой аналог inet_addr() и сам обрабатывает длинный адрес, поэтому даже в комбинации nginx-0.7.0/glibс-2.3 проблемы нет. -- Igor Sysoev http://nginx.com From nginx-forum at nginx.us Thu Jan 29 22:59:48 2015 From: nginx-forum at nginx.us (Helper code) Date: Thu, 29 Jan 2015 17:59:48 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0LrQsNGC0LDQu9C+0LPQsCDQvdCwIGluZGV4?= =?UTF-8?B?Lmh0bWwg0LHQtdC3INC00LjRgNC10LrRgtC40LLRiyBJTkRFWA==?= In-Reply-To: <2004407.AA34O4Zod5@note> References: <2004407.AA34O4Zod5@note> Message-ID: mva Wrote: ------------------------------------------------------- > указать index в server{} а не в location{} У меня строка "index index.html;" находится именно в server{}. Nginx при этот отдает одну и туже страницу index.html c кодом 200 и при запросе site.com/en/ и при запросе site.com/en/index.html Никакого редиректа 301 с site.com/en/ на site.com/en/index.html не происходит. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256319,256348#msg-256348 From mva at mva.name Thu Jan 29 23:12:45 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 30 Jan 2015 05:12:45 +0600 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0LrQsNGC0LDQu9C+0LPQsCDQvdCwIGluZGV4?= =?UTF-8?B?Lmh0bWwg0LHQtdC3INC00LjRgNC10LrRgtC40LLRiyBJTkRFWA==?= In-Reply-To: References: <2004407.AA34O4Zod5@note> Message-ID: <50829308.aCdneCleYg@note> В письме от Чт, 29 января 2015 17:59:48 пользователь Helper code написал: > У меня строка "index index.html;" находится именно в server{}. Nginx при > этот отдает одну и туже страницу index.html c кодом 200 и при запросе > site.com/en/ и при запросе site.com/en/index.html > Никакого редиректа 301 с site.com/en/ на site.com/en/index.html не > происходит. > Ах, вы хотите именно явный видимый редирект... Ну, попутно с ответом я бы хотел поинтересоваться зачем нужно такое извращение? А так: > rewrite ^(.*)/$ $1/index.html permanent; (ну, или, может, кто-нибудь в рассылке подскажет менее костыльный вариант...) Но лично мне, если честно, противна и непонятна сама суть затеи. Более "красиво" выглядит как раз наоборот некое подобие ЧПУ... -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nginx-forum at nginx.us Fri Jan 30 10:09:25 2015 From: nginx-forum at nginx.us (maxim88) Date: Fri, 30 Jan 2015 05:09:25 -0500 Subject: 500 Internal Server Error Message-ID: Добрый день! Есть два вида ссылок: http://domen.ly/tds/0d25 - nginx отдает 500 Internal Server Error http://domen.ly/tds/?0d25 - такую ссылку обрабатывает корректно Подскажите, где ошибка в конфиге и что нужно добавить-убрать, чтобы ссылка http://domen.ly/tds/0d25 обрабатывалась без ошибок? -------- server { server_name domen.ly www.domen.ly; listen 198.198.198.198; port_in_redirect off; server_tokens off; autoindex off; client_max_body_size 15m; client_body_buffer_size 128k; root /var/www/www.domen.ly/html/; index index.php index.html; try_files $uri $uri/ /index.php?$args; # Define default caching of 24h expires 3600s; add_header Pragma public; add_header Cache-Control "public, must-revalidate, proxy-revalidate"; # deliver a static 404 error_page 404 /404.html; location /404.html { internal; } # Deliver 404 instead of 403 "Forbidden" error_page 403 = 404; # Do not allow access to files giving away your WordPress version location ~ /(\.|wp-config.php|readme.html|licence.txt) { return 404; } # Add trailing slash to */wp-admin requests. rewrite /wp-admin$ $scheme://$host$uri/ permanent; # Don't log robots.txt requests location = /robots.txt { allow all; log_not_found off; access_log off; } # Rewrite for versioned CSS+JS via filemtime location ~* ^.+\.(css|js)$ { rewrite ^(.+)\.(\d+)\.(css|js)$ $1.$3 last; expires 31536000s; access_log off; log_not_found off; add_header Pragma public; add_header Cache-Control "max-age=31536000, public"; } # Aggressive caching for static files # If you alter static files often, please use # add_header Cache-Control "max-age=31536000, public, must-revalidate, proxy-revalidate"; location ~* \.(jpg|jpeg|png|gif|css|js|ico)$ { expires 31536000s; access_log off; log_not_found off; add_header Pragma public; add_header Cache-Control "max-age=31536000, public"; } # pass PHP scripts to Fastcgi listening on Unix socket # Do not process them if inside WP uploads directory # If using Multisite or a custom uploads directory, # please set the */uploads/* directory in the regex below location ~* (^(?!(?:(?!(php|inc)).)*/uploads/).*?(php)) { try_files $uri = 404; fastcgi_split_path_info ^(.+.php)(.*)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 128k; fastcgi_busy_buffers_size 128k; fastcgi_temp_file_write_size 128k; } # Deny access to hidden files location ~ /\. { deny all; access_log off; log_not_found off; } # block-exploits-sql-injections-file-injections-spam-user-agents-etc ## Block SQL injections set $block_sql_injections 0; if ($query_string ~ "union.*select.*\(") { set $block_sql_injections 1; } if ($query_string ~ "union.*all.*select.*") { set $block_sql_injections 1; } if ($query_string ~ "concat.*\(") { set $block_sql_injections 1; } if ($block_sql_injections = 1) { return 403; } ## Block file injections set $block_file_injections 0; if ($query_string ~ "[a-zA-Z0-9_]=http://") { set $block_file_injections 1; } if ($query_string ~ "[a-zA-Z0-9_]=(\.\.//?)+") { set $block_file_injections 1; } if ($query_string ~ "[a-zA-Z0-9_]=/([a-z0-9_.]//?)+") { set $block_file_injections 1; } if ($block_file_injections = 1) { return 403; } ## Block common exploits set $block_common_exploits 0; if ($query_string ~ "(<|%3C).*script.*(>|%3E)") { set $block_common_exploits 1; } if ($query_string ~ "GLOBALS(=|\[|\%[0-9A-Z]{0,2})") { set $block_common_exploits 1; } if ($query_string ~ "_REQUEST(=|\[|\%[0-9A-Z]{0,2})") { set $block_common_exploits 1; } if ($query_string ~ "proc/self/environ") { set $block_common_exploits 1; } if ($query_string ~ "mosConfig_[a-zA-Z_]{1,21}(=|\%3D)") { set $block_common_exploits 1; } if ($query_string ~ "base64_(en|de)code\(.*\)") { set $block_common_exploits 1; } if ($block_common_exploits = 1) { return 403; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256357,256357#msg-256357 From denis at webmaster.spb.ru Fri Jan 30 10:28:32 2015 From: denis at webmaster.spb.ru (denis) Date: Fri, 30 Jan 2015 13:28:32 +0300 Subject: 500 Internal Server Error In-Reply-To: References: Message-ID: <54CB5CD0.7040504@webmaster.spb.ru> 30.01.2015 13:09, maxim88 пишет: > Добрый день! > > Есть два вида ссылок: > > http://domen.ly/tds/0d25 - nginx отдает 500 Internal Server Error > http://domen.ly/tds/?0d25 - такую ссылку обрабатывает корректно > для начала, около listen ставим error_log /var/log/nginx/domen.ly-error.log info; перечитываем конфиг и ошибку сюда -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Jan 30 10:44:05 2015 From: nginx-forum at nginx.us (maxim88) Date: Fri, 30 Jan 2015 05:44:05 -0500 Subject: 500 Internal Server Error In-Reply-To: <54CB5CD0.7040504@webmaster.spb.ru> References: <54CB5CD0.7040504@webmaster.spb.ru> Message-ID: Сделал, вот что пишет: 2015/01/30 10:40:02 [error] 29336#0: *1 rewrite or internal redirection cycle while internally redirecting to "/index.php", client: 140.140.140.184, server: domen.ly, request: "GET /tds/0d25 HTTP/1.1", host: "domen.ly" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256357,256360#msg-256360 From nginx-forum at nginx.us Fri Jan 30 11:03:04 2015 From: nginx-forum at nginx.us (maksis) Date: Fri, 30 Jan 2015 06:03:04 -0500 Subject: 500 Internal Server Error In-Reply-To: References: <54CB5CD0.7040504@webmaster.spb.ru> Message-ID: <60fe331d811318d7a490d08f9f78eff9.NginxMailingListRussian@forum.nginx.org> Может быть глупый вопрос, но все же: файл http://domen.ly/index.php существует и отдаётся по этому URL? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256357,256361#msg-256361 From nginx-forum at nginx.us Fri Jan 30 11:10:00 2015 From: nginx-forum at nginx.us (maxim88) Date: Fri, 30 Jan 2015 06:10:00 -0500 Subject: 500 Internal Server Error In-Reply-To: <60fe331d811318d7a490d08f9f78eff9.NginxMailingListRussian@forum.nginx.org> References: <54CB5CD0.7040504@webmaster.spb.ru> <60fe331d811318d7a490d08f9f78eff9.NginxMailingListRussian@forum.nginx.org> Message-ID: <139510a704ad4183bd1926d99a758602.NginxMailingListRussian@forum.nginx.org> Хороший вопрос. В корне домена файла index.php нет, там стоит заглушка index.html, файл index.php лежит в паке /tds/ http://domen.ly/tds/index.php Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256357,256362#msg-256362 From nginx-forum at nginx.us Fri Jan 30 11:18:15 2015 From: nginx-forum at nginx.us (maksis) Date: Fri, 30 Jan 2015 06:18:15 -0500 Subject: 500 Internal Server Error In-Reply-To: <139510a704ad4183bd1926d99a758602.NginxMailingListRussian@forum.nginx.org> References: <54CB5CD0.7040504@webmaster.spb.ru> <60fe331d811318d7a490d08f9f78eff9.NginxMailingListRussian@forum.nginx.org> <139510a704ad4183bd1926d99a758602.NginxMailingListRussian@forum.nginx.org> Message-ID: <6a0c8663cfc6100b34354b96556b8fc5.NginxMailingListRussian@forum.nginx.org> Тогда try_files $uri $uri/ /index.php?$args; выполнит перенаправление на http://domen.ly/index.php, которого нет, и обработка начнется заново, что приведет к циклу. Может быть стоит указать таким образом: try_files $uri $uri/ /tds/index.php?$args; ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256357,256363#msg-256363 From nginx-forum at nginx.us Fri Jan 30 11:31:15 2015 From: nginx-forum at nginx.us (maxim88) Date: Fri, 30 Jan 2015 06:31:15 -0500 Subject: 500 Internal Server Error In-Reply-To: <6a0c8663cfc6100b34354b96556b8fc5.NginxMailingListRussian@forum.nginx.org> References: <54CB5CD0.7040504@webmaster.spb.ru> <60fe331d811318d7a490d08f9f78eff9.NginxMailingListRussian@forum.nginx.org> <139510a704ad4183bd1926d99a758602.NginxMailingListRussian@forum.nginx.org> <6a0c8663cfc6100b34354b96556b8fc5.NginxMailingListRussian@forum.nginx.org> Message-ID: <15aa2623f48ee7a21ca079bb0174b484.NginxMailingListRussian@forum.nginx.org> Спасибо) "try_files $uri $uri/ /tds/index.php?$args;" - все заработало! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256357,256364#msg-256364 From nginx-forum at nginx.us Fri Jan 30 14:44:04 2015 From: nginx-forum at nginx.us (Helper code) Date: Fri, 30 Jan 2015 09:44:04 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0LrQsNGC0LDQu9C+0LPQsCDQvdCwIGluZGV4?= =?UTF-8?B?Lmh0bWwg0LHQtdC3INC00LjRgNC10LrRgtC40LLRiyBJTkRFWA==?= In-Reply-To: <50829308.aCdneCleYg@note> References: <50829308.aCdneCleYg@note> Message-ID: <8957fb0e33678f7ad40617aba7308fc1.NginxMailingListRussian@forum.nginx.org> mva Wrote: ------------------------------------------------------- > rewrite ^(.*)/$ $1/index.html permanent; > (ну, или, может, кто-нибудь в рассылке подскажет менее костыльный > вариант...) Огромного вам спасибо! Все отлично работает. А в чем собственно костыль в этой конструкции? Скорость? > Ну, попутно с ответом я бы хотел поинтересоваться зачем нужно такое > извращение? Для уменьшения дублей страниц. > Но лично мне, если честно, противна и непонятна сама суть затеи. Более > "красиво" выглядит как раз наоборот некое подобие ЧПУ... Это как с WWW для домена, кому то нравиться с ним, кому то без. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256319,256368#msg-256368 From sytar.alex at gmail.com Sat Jan 31 07:45:22 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Sat, 31 Jan 2015 11:45:22 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0LrQsNGC0LDQu9C+0LPQsCDQvdCwIGluZGV4?= =?UTF-8?B?Lmh0bWwg0LHQtdC3INC00LjRgNC10LrRgtC40LLRiyBJTkRFWA==?= In-Reply-To: <8957fb0e33678f7ad40617aba7308fc1.NginxMailingListRussian@forum.nginx.org> References: <50829308.aCdneCleYg@note> <8957fb0e33678f7ad40617aba7308fc1.NginxMailingListRussian@forum.nginx.org> Message-ID: 30 января 2015 г., 17:44 пользователь Helper code написал: > > > Ну, попутно с ответом я бы хотел поинтересоваться зачем нужно такое > > извращение? > > Для уменьшения дублей страниц. > на стороне приложения более правильнее помогут с этим справиться. -------------- next part -------------- An HTML attachment was scrubbed... URL: