From hell-for-yahoo at umail.ru Tue Jan 1 00:41:06 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Tue, 1 Jan 2013 04:41:06 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: Message-ID: <1338013788.20130101044106@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) OZzzy! O> location /snow { O> root /opt/jakarta-tomcat-5.5.9/webapps/snow/; Вы его попросили открывать /opt/jakarta-tomcat-5.5.9/webapps/snow/snow/ - вот он и пытается... Логично, что все его попытки обламываются. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) вторник, 01.01.2013, <04:39> From nginx-forum at nginx.us Tue Jan 1 01:57:08 2013 From: nginx-forum at nginx.us (OZzzy) Date: Mon, 31 Dec 2012 20:57:08 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: <1338013788.20130101044106@mtu-net.ru> References: <1338013788.20130101044106@mtu-net.ru> Message-ID: <8b9189fb2135a8b62f76ae4d3ffd02fa.NginxMailingListRussian@forum.nginx.org> я так и не поняла где я ошиблась. Может подскажете? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234602#msg-234602 From nginx-forum at nginx.us Tue Jan 1 02:03:03 2013 From: nginx-forum at nginx.us (OZzzy) Date: Mon, 31 Dec 2012 21:03:03 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: Message-ID: <7bb05240b0f3f4454270a21d8d6a7878.NginxMailingListRussian@forum.nginx.org> Это будет правильным решением? location /snow { root /opt/jakarta-tomcat-5.5.9/webapps/; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234603#msg-234603 From nginx-forum at nginx.us Tue Jan 1 10:40:20 2013 From: nginx-forum at nginx.us (OZzzy) Date: Tue, 01 Jan 2013 05:40:20 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: Message-ID: <35f68d5a72902bb9443a7eb270b51221.NginxMailingListRussian@forum.nginx.org> нет - ничего не изменилось Всех с Новым годом! Пожалуйста подскажите правильный конфиг Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234604#msg-234604 From hell-for-yahoo at umail.ru Wed Jan 2 06:58:05 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Wed, 2 Jan 2013 10:58:05 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: <7bb05240b0f3f4454270a21d8d6a7878.NginxMailingListRussian@forum.nginx.org> References: <7bb05240b0f3f4454270a21d8d6a7878.NginxMailingListRussian@forum.nginx.org> Message-ID: <1398253103.20130102105805@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) OZzzy! O> Это будет правильным решением? O> location /snow { O> root /opt/jakarta-tomcat-5.5.9/webapps/; location /snow { root /opt/jakarta-tomcat-5.5.9/webapps; Так будет точнее. Попробуйте, если ситуация не изменится - увеличивайте детализацию логов и ищите причину проблемы. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) среда, 02.01.2013, <10:56> From igor at sysoev.ru Wed Jan 2 07:39:09 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 2 Jan 2013 11:39:09 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: Message-ID: On Dec 31, 2012, at 23:31 , OZzzy wrote: > Конфигурация вэб сервера: > Nginx, PHP5 и MySQL на Debian Squeeze с использованием spawn-fcgi > > Появилась необходимость вот в такой конфигурации: > Основной сайт - слушается на 80 порту > На порт 35000 мне нужно повесить /opt/jakarta-tomcat-5.5.9/webapps/snow > > Индексный файл index.jsp > > Конфигурация: > ------------------------------------------------------------------------------- > > server { > listen X.X.X.X:80; ## listen for ipv4 > server_name site.ru www.site.ru; > access_log /var/www/site.ru/log/access.log; > location / { > root /var/www/site.ru/htdocs; > index index.php index.html index.htm; > } > location ~ \.php$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > /var/www/site.ru/htdocs$fastcgi_script_name; > include fastcgi_params; > allow X.X.X.X; > allow X.X.X.X; > deny all; > } > > location ~ /\.ht { > #deny all; > } > > } > > server { > listen X.X.X.X:35002; > server_name snow; > > location /snow { > root /opt/jakarta-tomcat-5.5.9/webapps/snow/; > index index.jsp index.php index.html index.htm; > access_log /var/log/snow/admin_access.log; > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > /opt/jakarta-tomcat-5.5.9/webapps/snow/$fastcgi_script_name; root /opt/jakarta-tomcat-5.5.9/webapps/; fastcgi_param SCRIPT_FILENAME /opt/jakarta-tomcat-5.5.9/webapps/$fastcgi_script_name; или root /opt/jakarta-tomcat-5.5.9/webapps/; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Wed Jan 2 13:05:35 2013 From: nginx-forum at nginx.us (Craken) Date: Wed, 02 Jan 2013 08:05:35 -0500 Subject: nginx reload -> segfault Message-ID: Приветствую. Сегодня нужно было добавить еще один server {...}, и по привычке выполнил не перезапуск а переконфигурирование (ч-з reload), в ответ получил "ОК", но сайты "отвалились". Вот что в dmesg: nginx[20921]: segfault at 7f3a1c25f5e8 ip 00007f3a1c25f5e8 sp 00007fff2cd87c28 error 15 nginx[20920] trap stack segment ip:7f3a1bf491cd sp:7fff2cd87a50 error:0 nginx[21033] general protection ip:7f3a1bf48d43 sp:7fff2cd87b80 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[20940] trap stack segment ip:7f3a1bf491cd sp:7fff2cd87a30 error:0 nginx[20997] general protection ip:7f3a1bf48d43 sp:7fff2cd87630 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[21052] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[21006] general protection ip:7f3a1bf48d43 sp:7fff2cd87b80 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[21035] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[20988] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[21064] general protection ip:7f3a1bf47e71 sp:7fff2cd86b30 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[21066] general protection ip:7f3a1bf59061 sp:7fff2cd86b28 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[20953] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[20923] general protection ip:7f3a1bf47e71 sp:7fff2cd86b50 error:0 in libc-2.12.so[7f3a1bed0000+189000] nginx[20971] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in libc-2.12.so[7f3a1bed0000+189000] __ratelimit: 1 callbacks suppressed nginx[21232]: segfault at 19 ip 0000000000449deb sp 00007fff5982d660 error 4 in nginx[400000+e1000] nginx[23181]: segfault at 0 ip 00007f52d5dfbf3c sp 00007fff5982e388 error 4 in libc-2.12.so[7f52d5d81000+189000] В логах самого nginx'a следующие записи: 2013/01/02 10:36:02 [alert] 20121#0: worker process 21042 exited on signal 11 *** glibc detected *** nginx: worker process: free(): corrupted unsorted chunks: 0x000000000210b200 *** *** glibc detected *** nginx: worker process: malloc(): memory corruption: 0x000000000207c200 *** Nginx установлен из репозиториев: root#beryllium[2]/var/log/nginx>nginx -V nginx version: nginx/1.3.10 built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/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 --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-http_geoip_module --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --with-file-aio --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upstream-fair --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-progress-module --add-module=/builddir/build/BUILD/nginx-1.3.10/mod_zip-1.1.6 --add-module=/builddir/build/BUILD/nginx-1.3.10/ngx_http_auth_pam_module-1.2 --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-module-2.2 --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-rtmp-module-master ОС: Scientific Linux release 6.3 (Carbon) После "сбоя" пришлось немедленно убить nginx (ч-з killall -9) и запустить заново, потому что при попытке выполнить restart скрипт тупо висел на этапе "Stopping nginx:......................". Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234628,234628#msg-234628 From nginx-forum at nginx.us Wed Jan 2 13:20:12 2013 From: nginx-forum at nginx.us (Craken) Date: Wed, 02 Jan 2013 08:20:12 -0500 Subject: nginx reload -> segfault In-Reply-To: References: Message-ID: <4de1514fb97e76bc7d0e662eae981a4e.NginxMailingListRussian@forum.nginx.org> Так же забыл уточнить кое-какие моменты: 1) баг появился именно после перехода на версию "1.3.10". 2) ipv6 не используем. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234628,234629#msg-234629 From self at alaz.me Wed Jan 2 13:57:14 2013 From: self at alaz.me (Azarov Alexander) Date: Wed, 2 Jan 2013 14:57:14 +0100 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: Message-ID: <7EB0B3AE-E681-4C08-A4CD-BD59C975AE3F@alaz.me> On 31.12.2012, at 20:31, OZzzy wrote: > Конфигурация вэб сервера: > Nginx, PHP5 и MySQL на Debian Squeeze с использованием spawn-fcgi > > Появилась необходимость вот в такой конфигурации: > Основной сайт - слушается на 80 порту > На порт 35000 мне нужно повесить /opt/jakarta-tomcat-5.5.9/webapps/snow > location /snow { > root /opt/jakarta-tomcat-5.5.9/webapps/snow/; > index index.jsp index.php index.html index.htm; > access_log /var/log/snow/admin_access.log; > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > /opt/jakarta-tomcat-5.5.9/webapps/snow/$fastcgi_script_name; > include fastcgi_params; В дополнение к предыдущих комментариям. Я сильно подозреваю, что у Вас на порту 35000 работает Tomcat. А он, будучи Java веб-сервером, Fast CGI не умеет. В Tomcat надо проксировать через proxy_pass. (появление порта 9000 в этом location также нелогично, раз Вы пишете выше о 35000) From vbart at nginx.com Wed Jan 2 14:00:55 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 2 Jan 2013 18:00:55 +0400 Subject: nginx reload -> segfault In-Reply-To: References: Message-ID: <201301021800.55663.vbart@nginx.com> On Wednesday 02 January 2013 17:05:35 Craken wrote: > Приветствую. > Сегодня нужно было добавить еще один server {...}, и по привычке выполнил > не перезапуск а переконфигурирование (ч-з reload), в ответ получил "ОК", > но сайты "отвалились". > > Вот что в dmesg: > nginx[20921]: segfault at 7f3a1c25f5e8 ip 00007f3a1c25f5e8 sp > 00007fff2cd87c28 error 15 > nginx[20920] trap stack segment ip:7f3a1bf491cd sp:7fff2cd87a50 error:0 > nginx[21033] general protection ip:7f3a1bf48d43 sp:7fff2cd87b80 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[20940] trap stack segment ip:7f3a1bf491cd sp:7fff2cd87a30 error:0 > nginx[20997] general protection ip:7f3a1bf48d43 sp:7fff2cd87630 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[21052] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[21006] general protection ip:7f3a1bf48d43 sp:7fff2cd87b80 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[21035] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[20988] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[21064] general protection ip:7f3a1bf47e71 sp:7fff2cd86b30 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[21066] general protection ip:7f3a1bf59061 sp:7fff2cd86b28 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[20953] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[20923] general protection ip:7f3a1bf47e71 sp:7fff2cd86b50 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > nginx[20971] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in > libc-2.12.so[7f3a1bed0000+189000] > __ratelimit: 1 callbacks suppressed > nginx[21232]: segfault at 19 ip 0000000000449deb sp 00007fff5982d660 error > 4 in nginx[400000+e1000] > nginx[23181]: segfault at 0 ip 00007f52d5dfbf3c sp 00007fff5982e388 error 4 > in libc-2.12.so[7f52d5d81000+189000] > Стоит собрать с дебагом. http://nginx.org/ru/docs/debugging_log.html [...] > --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' > --with-ipv6 --with-file-aio > --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upstream-fair > --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-progress-modul > e --add-module=/builddir/build/BUILD/nginx-1.3.10/mod_zip-1.1.6 > --add-module=/builddir/build/BUILD/nginx-1.3.10/ngx_http_auth_pam_module-1. > 2 --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-module-2.2 > --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-rtmp-module-master > И без сторонних модулей. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From alexander.moskalenko at gmail.com Wed Jan 2 14:36:29 2013 From: alexander.moskalenko at gmail.com (Alexander Moskalenko) Date: Wed, 2 Jan 2013 16:36:29 +0200 Subject: nginx reload -> segfault In-Reply-To: <201301021800.55663.vbart@nginx.com> References: <201301021800.55663.vbart@nginx.com> Message-ID: Точно такую же ситуацию сегодня получил на CentOS 6 Nginx установлен из CentALT nginx version: nginx/1.3.10 built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/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 --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-http_geoip_module --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --with-file-aio --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upstream-fair --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-progress-module --add-module=/builddir/build/BUILD/nginx-1.3.10/mod_zip-1.1.6 --add-module=/builddir/build/BUILD/nginx-1.3.10/ngx_http_auth_pam_module-1.2 --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-module-2.2 --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-rtmp-module-master Делался upgrade, после restart падения прекратились 2013/1/2 Валентин Бартенев : > On Wednesday 02 January 2013 17:05:35 Craken wrote: >> Приветствую. >> Сегодня нужно было добавить еще один server {...}, и по привычке выполнил >> не перезапуск а переконфигурирование (ч-з reload), в ответ получил "ОК", >> но сайты "отвалились". >> >> Вот что в dmesg: >> nginx[20921]: segfault at 7f3a1c25f5e8 ip 00007f3a1c25f5e8 sp >> 00007fff2cd87c28 error 15 >> nginx[20920] trap stack segment ip:7f3a1bf491cd sp:7fff2cd87a50 error:0 >> nginx[21033] general protection ip:7f3a1bf48d43 sp:7fff2cd87b80 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[20940] trap stack segment ip:7f3a1bf491cd sp:7fff2cd87a30 error:0 >> nginx[20997] general protection ip:7f3a1bf48d43 sp:7fff2cd87630 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[21052] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[21006] general protection ip:7f3a1bf48d43 sp:7fff2cd87b80 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[21035] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[20988] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[21064] general protection ip:7f3a1bf47e71 sp:7fff2cd86b30 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[21066] general protection ip:7f3a1bf59061 sp:7fff2cd86b28 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[20953] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[20923] general protection ip:7f3a1bf47e71 sp:7fff2cd86b50 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> nginx[20971] general protection ip:7f3a1bf47e71 sp:7fff2cd86ba0 error:0 in >> libc-2.12.so[7f3a1bed0000+189000] >> __ratelimit: 1 callbacks suppressed >> nginx[21232]: segfault at 19 ip 0000000000449deb sp 00007fff5982d660 error >> 4 in nginx[400000+e1000] >> nginx[23181]: segfault at 0 ip 00007f52d5dfbf3c sp 00007fff5982e388 error 4 >> in libc-2.12.so[7f52d5d81000+189000] >> > > Стоит собрать с дебагом. > http://nginx.org/ru/docs/debugging_log.html > > > [...] >> --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' >> --with-ipv6 --with-file-aio >> --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upstream-fair >> --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-progress-modul >> e --add-module=/builddir/build/BUILD/nginx-1.3.10/mod_zip-1.1.6 >> --add-module=/builddir/build/BUILD/nginx-1.3.10/ngx_http_auth_pam_module-1. >> 2 --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-upload-module-2.2 >> --add-module=/builddir/build/BUILD/nginx-1.3.10/nginx-rtmp-module-master >> > > И без сторонних модулей. > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Wed Jan 2 15:20:53 2013 From: nginx-forum at nginx.us (OZzzy) Date: Wed, 02 Jan 2013 10:20:53 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: Message-ID: <9a7ac195c5b48c430574dd85e2f1435c.NginxMailingListRussian@forum.nginx.org> Игорь Владимирович! Спасибо, что ответили. Но ни один вариант вашего совета не дал результата. в броузере при наборе адреса: No input file specified. Скорее всего я в своем недопонимании неправильно совет использовала. Если вам нетрудно, просто исправьте этот кусок конфига: --------------------------- server { listen X.X.X.X:35002; server_name snow; location /snow { root /opt/jakarta-tomcat-5.5.9/webapps; index index.jsp index.php index.html index.htm; access_log /var/log/snow/admin_access.log; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /opt/jakarta-tomcat-5.5.9/webapps$fastcgi_script_name; include fastcgi_params; allow X.X.X.X; allow X.X.X.X; deny all; } } ------------------------- to Azarov Alexander root at test:~# netstat -ntpl | grep 35002 tcp 0 0 X.X.X.X:35002 0.0.0.0:* LISTEN 4381/nginx больше ничего не висит на порт 35002 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234636#msg-234636 From nginx-forum at nginx.us Wed Jan 2 15:23:09 2013 From: nginx-forum at nginx.us (OZzzy) Date: Wed, 02 Jan 2013 10:23:09 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: <7EB0B3AE-E681-4C08-A4CD-BD59C975AE3F@alaz.me> References: <7EB0B3AE-E681-4C08-A4CD-BD59C975AE3F@alaz.me> Message-ID: <7e0078b64dd1e03ff3f21e2870a66cde.NginxMailingListRussian@forum.nginx.org> root at test:~# netstat -ntpl | grep 35002 tcp 0 0 X.X.X.X:35002 0.0.0.0:* LISTEN 4381/nginx больше ничего не висит на порт 35002 35000 порт чистый Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234637#msg-234637 From igor at sysoev.ru Wed Jan 2 16:18:52 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 2 Jan 2013 20:18:52 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: <9a7ac195c5b48c430574dd85e2f1435c.NginxMailingListRussian@forum.nginx.org> References: <9a7ac195c5b48c430574dd85e2f1435c.NginxMailingListRussian@forum.nginx.org> Message-ID: <7FFC1FA3-E719-48C5-B650-044EC6D2FEA2@sysoev.ru> On Jan 2, 2013, at 19:20 , OZzzy wrote: > Игорь Владимирович! > Спасибо, что ответили. > Но ни один вариант вашего совета не дал результата. > в броузере при наборе адреса: > No input file specified. > > Скорее всего я в своем недопонимании неправильно совет использовала. > Если вам нетрудно, просто исправьте этот кусок конфига: > > --------------------------- > server { > listen X.X.X.X:35002; > server_name snow; > > location /snow { > root /opt/jakarta-tomcat-5.5.9/webapps; > index index.jsp index.php index.html index.htm; > access_log /var/log/snow/admin_access.log; > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > /opt/jakarta-tomcat-5.5.9/webapps$fastcgi_script_name; > include fastcgi_params; > allow X.X.X.X; > allow X.X.X.X; > deny all; > } > } В первом письме было: Индексный файл index.jsp Если http://Х.Х.Х.Х:35002/snow/index.jsp работает, то нужно fastcgi_index index.php; заменить на fastcgi_index index.jsp; А почему используется PHP, но при этом jakarta-tomcat-5.5.9, типичный порт томката и JSP ? -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Wed Jan 2 18:36:24 2013 From: nginx-forum at nginx.us (valch85) Date: Wed, 02 Jan 2013 13:36:24 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0LrQsNC20LjRgtC1INC/0L4g0L/QtdGA0LXQvdCw0L/RgNCw?= =?UTF-8?B?0LLQu9C10L3QuNGO?= In-Reply-To: References: Message-ID: <00eb11e901366af9aceb7daa08d80aa0.NginxMailingListRussian@forum.nginx.org> Вот так сделай перенаправление server { server_name www.myhost2.myhost.ru myhost2.myhost.ru; rewrite ^/(.*)$ http://www.myhost.ru permanent; } получилось? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234541,234645#msg-234645 From nginx-forum at nginx.us Wed Jan 2 19:58:04 2013 From: nginx-forum at nginx.us (OZzzy) Date: Wed, 02 Jan 2013 14:58:04 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: <7FFC1FA3-E719-48C5-B650-044EC6D2FEA2@sysoev.ru> References: <7FFC1FA3-E719-48C5-B650-044EC6D2FEA2@sysoev.ru> Message-ID: Нужна catalina в конфиге : сейчас такая конфигурация в nginx: ------------------------------------------------------------- server { listen X.X.X.X:35002; access_log /var/log/snow/admin_access.log; location /snow { root /opt/jakarta-tomcat-5.5.9/webapps; index index.jps index.php index.html index.htm; } location ~ \.jsp$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.jsp; fastcgi_param SCRIPT_FILENAME /opt/jakarta-tomcat-5.5.9/webapps$fastcgi_script_name; include fastcgi_params; allow X.X.X.X; allow X.X.X.X; deny all; } location ~ /\.(ht|svn|cvs|hg|txt|log|class|cgi|xml|conf|config|properties|jar) { deny all; } } ------------------------------------------------------------ Ответ в браузере: 404 Not Found nginx/0.7.67 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234646#msg-234646 From igor at sysoev.ru Wed Jan 2 20:23:57 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Thu, 3 Jan 2013 00:23:57 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: <7FFC1FA3-E719-48C5-B650-044EC6D2FEA2@sysoev.ru> Message-ID: <1B68D126-674E-4004-A9E0-E3DBAD79ABA4@sysoev.ru> On Jan 2, 2013, at 23:58 , OZzzy wrote: > Нужна catalina > > в конфиге : > maxThreads="100" minSpareThreads="5" maxSpareThreads="10" > enableLookups="false" redirectPort="443" acceptCount="100" > connectionTimeout="20000" disableUploadTimeout="true" /> > > сейчас такая конфигурация в nginx: > ------------------------------------------------------------- > server { > listen X.X.X.X:35002; > access_log /var/log/snow/admin_access.log; > location /snow { > root /opt/jakarta-tomcat-5.5.9/webapps; > index index.jps index.php index.html index.htm; } index.jps вместо index.jsp. > location ~ \.jsp$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.jsp; > fastcgi_param SCRIPT_FILENAME > /opt/jakarta-tomcat-5.5.9/webapps$fastcgi_script_name; > include fastcgi_params; > allow X.X.X.X; > allow X.X.X.X; > deny all; > } > location ~ > /\.(ht|svn|cvs|hg|txt|log|class|cgi|xml|conf|config|properties|jar) { > deny all; > } > } > ------------------------------------------------------------ > > Ответ в браузере: > 404 Not Found > > nginx/0.7.67 -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Wed Jan 2 22:44:03 2013 From: nginx-forum at nginx.us (OZzzy) Date: Wed, 02 Jan 2013 17:44:03 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: <1B68D126-674E-4004-A9E0-E3DBAD79ABA4@sysoev.ru> References: <1B68D126-674E-4004-A9E0-E3DBAD79ABA4@sysoev.ru> Message-ID: .jsp - JavaServer Pages небольшой пример кода файла index.jsp if(showTag) {%> <%@include file="/include/topheader.jsp"%> <% } else {%> <%@include file="/include/topheader_nologin.jsp"%> <%}%> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234655#msg-234655 From dmitriy at lyalyuev.info Thu Jan 3 07:04:12 2013 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Thu, 03 Jan 2013 09:04:12 +0200 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: <1B68D126-674E-4004-A9E0-E3DBAD79ABA4@sysoev.ru> Message-ID: <50E52D6C.4080408@lyalyuev.info> Игорь имел ввиду, что в конфиге у Вас указано jps вместо jsp. Опечатались. 03.01.2013 00:44, OZzzy пишет: > .jsp - JavaServer Pages > > небольшой пример кода файла index.jsp > > if(showTag) > {%> > <%@include file="/include/topheader.jsp"%> > <% > } else {%> > <%@include file="/include/topheader_nologin.jsp"%> > <%}%> > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234655#msg-234655 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Thu Jan 3 09:59:25 2013 From: nginx-forum at nginx.us (OZzzy) Date: Thu, 03 Jan 2013 04:59:25 -0500 Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0L3QsCDQstGL0LHRgNCw0L3QvdGL0Lkg0L8=?= =?UTF-8?B?0L7RgNGC?= In-Reply-To: References: Message-ID: Большое спасибо всем Помогло вот это: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#example -------------------------------------------------------------------------------- server { listen X.X.X.X:35002; location ~ /\.(ht|svn|cvs|hg|txt|log|class|cgi|xml|conf|config|properties|jar) { deny all; } location /snow/ { proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080/ http://X.X.X.X:35002/; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; access_log /var/log/snow/admin_access.log; allow X.X.X.X.; deny all; } } --------------------------------------------------------------------------------- Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234597,234661#msg-234661 From neo at miritec.com Thu Jan 3 18:42:55 2013 From: neo at miritec.com (=?KOI8-R?B?4NLJyiDnz87ewdLP1w==?=) Date: Thu, 3 Jan 2013 20:42:55 +0200 Subject: Match if GET param exist Message-ID: Здравствуйте Подскажите пожалуйста как решить задачу. Есть папка проекта /admin/ Необходимо разрешить доступ в /admin/ только с X.X.X.X но если URL содержит GET параметр login, например http://domain.com/admin/logon?url=blablabla&login=name тогда пускать с любого IP Премного благодарю за любые советы, подсказки, примеры! -- NEO83-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Jan 3 19:54:22 2013 From: nginx-forum at nginx.us (OZzzy) Date: Thu, 03 Jan 2013 14:54:22 -0500 Subject: Match if GET param exist In-Reply-To: References: Message-ID: Конфигурация web сервера? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234665,234667#msg-234667 From neo at miritec.com Thu Jan 3 21:23:47 2013 From: neo at miritec.com (=?KOI8-R?B?4NLJyiDnz87ewdLP1w==?=) Date: Thu, 3 Jan 2013 23:23:47 +0200 Subject: Match if GET param exist In-Reply-To: References: Message-ID: nginx version: nginx/1.2.5, PHP 5.3.19 (php-fpm) server { listen 80; server_name domain.com; location /templates/ { deny all; } location /system/ { deny all; } location / { try_files $uri /front.php =405; include fastcgi_params; fastcgi_connect_timeout 3600; fastcgi_send_timeout 3600; fastcgi_read_timeout 3600; fastcgi_pass unix:/tmp/php.socket; client_max_body_size 100m; root /www/projects/domain.com; } 2013/1/3 OZzzy > Конфигурация web сервера? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,234665,234667#msg-234667 > > _______________________________________________ > 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 hell-for-yahoo at umail.ru Fri Jan 4 03:53:23 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Fri, 4 Jan 2013 07:53:23 +0400 Subject: Match if GET param exist In-Reply-To: References: Message-ID: <38167348.20130104075323@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Юрий Гончаров! ЮГ> Подскажите пожалуйста как решить задачу. ЮГ> Есть папка проекта /admin/ ЮГ> Необходимо разрешить доступ в /admin/ только с X.X.X.X но если URL содержит ЮГ> GET параметр login, например ЮГ> http://domain.com/admin/logon?url=blablabla&login=name Вас ссылки с поисковиков заколебут, обещаю вам это. Советую спользовать куки, а не GET параметры. ЮГ> тогда пускать с любого IP ЮГ> Премного благодарю за любые советы, подсказки, примеры! Не вижу в вашей конфигурации веб-сервера папку /admin/ -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) пятница, 04.01.2013, <07:50> From igor at sysoev.ru Fri Jan 4 06:35:43 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 4 Jan 2013 10:35:43 +0400 Subject: Match if GET param exist In-Reply-To: References: Message-ID: <800DAABF-AFF7-4D87-ADD2-918DD4058884@sysoev.ru> On Jan 3, 2013, at 22:42 , Юрий Гончаров wrote: > Здравствуйте > Подскажите пожалуйста как решить задачу. > Есть папка проекта /admin/ > Необходимо разрешить доступ в /admin/ только с X.X.X.X но если URL содержит GET параметр login, например http://domain.com/admin/logon?url=blablabla&login=name > тогда пускать с любого IP > Премного благодарю за любые советы, подсказки, примеры! Как-то так: http { map $arg_login $forbidden { "" $forbidden_address; default 0; } geo $fobidden_address { X.X.X.X 0; default 1; } server { location /admin/ { if ($forbidden) { return 403; } -- Igor Sysoev http://nginx.com/support.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Jan 5 20:53:20 2013 From: nginx-forum at nginx.us (Renat) Date: Sat, 05 Jan 2013 15:53:20 -0500 Subject: =?UTF-8?B?dXNlIGVwb2xsINC4INGBINGH0LXQvCDQtdCz0L4g0LXQtNGP0YI/?= Message-ID: <04e9b926f97bfb466710b776ae18d0b5.NginxMailingListRussian@forum.nginx.org> К сожалению в Интернете удалось найти очень мало документации о epoll, это какой-то эффективный метод обработки соединений в Linux 2.6+. Но кто-то может более подробно рассказать как он работает и чем он хорош? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234729,234729#msg-234729 From nginx-forum at nginx.us Sat Jan 5 21:11:12 2013 From: nginx-forum at nginx.us (sanchous) Date: Sat, 05 Jan 2013 16:11:12 -0500 Subject: nginx sparc Message-ID: Добрый ночь! Не удается собрать nginx на машине sun sparc (не ultra) под NetBSD. # uname -srm NetBSD 4.0.1 sparc # gcc -v Using built-in specs. Target: sparc--netbsdelf Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=i386-unknown-netbsdelf4.99.3 --host=sparc--netbsdelf --target=sparc--netbsdelf Thread model: posix gcc version 4.1.2 20061021 prerelease (NetBSD nb3 20061125) # openssl version OpenSSL 0.9.8e 23 Feb 2007 # pcre-config --version 8.31 # ./configure --prefix=/usr/pkg \ --conf-path=/usr/pkg/etc/nginx/nginx.conf \ --sbin-path=/usr/pkg/sbin \ --with-http_ssl_module --with-http_stub_status_module \ --with-cpu-opt="sparc32" Configuration summary + using system PCRE library + using system OpenSSL library + md5: using OpenSSL library + sha1: using OpenSSL library + using system zlib library nginx path prefix: "/usr/pkg" nginx binary file: "/usr/pkg/sbin" nginx configuration prefix: "/usr/pkg/etc/nginx" nginx configuration file: "/usr/pkg/etc/nginx/nginx.conf" nginx pid file: "/usr/pkg/share/nginx/log/nginx/.pid" nginx error log file: "/usr/pkg/share/nginx/log/nginx-error.log" nginx http access log file: "/usr/pkg/share/nginx/log/nginx-access.log" nginx http client request body temporary files: "/usr/pkg/share/nginx/log/client-body-temp" nginx http proxy temporary files: "/usr/pkg/share/nginx/log/proxy-temp" nginx http fastcgi temporary files: "/usr/pkg/share/nginx/log/fastcgi-temp" nginx http uwsgi temporary files: "/usr/pkg/share/nginx/log/uwsgi-temp" nginx http scgi temporary files: "/usr/pkg/share/nginx/log/scgi-temp" /usr/bin/make -f objs/Makefile gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/nginx.o src/core/nginx.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_log.o src/core/ngx_log.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_palloc.o src/core/ngx_palloc.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_array.o src/core/ngx_array.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_list.o src/core/ngx_list.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_hash.o src/core/ngx_hash.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_buf.o src/core/ngx_buf.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_queue.o src/core/ngx_queue.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_output_chain.o src/core/ngx_output_chain.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_string.o src/core/ngx_string.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_parse.o src/core/ngx_parse.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_inet.o src/core/ngx_inet.c gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_file.o src/core/ngx_file.c /var/tmp//ccouiI9K.s: Assembler messages: /var/tmp//ccouiI9K.s:683: Error: Architecture mismatch on "casa". /var/tmp//ccouiI9K.s:683: (Requires v9|v9a|v9b; requested architecture is sparclite.) *** Error code 1 Stop. make: stopped in /usr/pkg/src/nginx-1.2.6 *** Error code 1 Stop. make: stopped in /usr/pkg/src/nginx-1.2.6 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234730,234730#msg-234730 From sb at waeme.net Sat Jan 5 22:18:46 2013 From: sb at waeme.net (Sergey Budnevitch) Date: Sun, 6 Jan 2013 02:18:46 +0400 Subject: nginx sparc In-Reply-To: References: Message-ID: <0273F14A-6B62-47A6-AAF0-51A35B296EDE@waeme.net> On 6 Jan2013, at 01:11 , sanchous wrote: > Добрый ночь! > > Не удается собрать nginx на машине sun sparc (не ultra) под NetBSD. Судя по sparclite это не просто не ultra, а даже не sparc-v8, а v8e. casa в нем нем нет, поэтому и не собирается. Из какого-то музея или какой-то странный embedded? Попробуйте собрать с --with-libatomic, с установленной соответствующей библиотекой (/usr/pkgsrc/devel/libatomic_ops). > > # uname -srm > NetBSD 4.0.1 sparc > > # gcc -v > Using built-in specs. > Target: sparc--netbsdelf > Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure > --enable-long-long --disable-multilib --enable-threads --disable-symvers > --build=i386-unknown-netbsdelf4.99.3 --host=sparc--netbsdelf > --target=sparc--netbsdelf > Thread model: posix > gcc version 4.1.2 20061021 prerelease (NetBSD nb3 20061125) > > # openssl version > OpenSSL 0.9.8e 23 Feb 2007 > > # pcre-config --version > 8.31 > > # ./configure --prefix=/usr/pkg \ > --conf-path=/usr/pkg/etc/nginx/nginx.conf \ > --sbin-path=/usr/pkg/sbin \ > --with-http_ssl_module --with-http_stub_status_module \ > --with-cpu-opt="sparc32" > > Configuration summary > + using system PCRE library > + using system OpenSSL library > + md5: using OpenSSL library > + sha1: using OpenSSL library > + using system zlib library > > nginx path prefix: "/usr/pkg" > nginx binary file: "/usr/pkg/sbin" > nginx configuration prefix: "/usr/pkg/etc/nginx" > nginx configuration file: "/usr/pkg/etc/nginx/nginx.conf" > nginx pid file: "/usr/pkg/share/nginx/log/nginx/.pid" > nginx error log file: "/usr/pkg/share/nginx/log/nginx-error.log" > nginx http access log file: "/usr/pkg/share/nginx/log/nginx-access.log" > nginx http client request body temporary files: > "/usr/pkg/share/nginx/log/client-body-temp" > nginx http proxy temporary files: "/usr/pkg/share/nginx/log/proxy-temp" > nginx http fastcgi temporary files: > "/usr/pkg/share/nginx/log/fastcgi-temp" > nginx http uwsgi temporary files: "/usr/pkg/share/nginx/log/uwsgi-temp" > nginx http scgi temporary files: "/usr/pkg/share/nginx/log/scgi-temp" > > /usr/bin/make -f objs/Makefile > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/nginx.o > src/core/nginx.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_log.o > src/core/ngx_log.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_palloc.o > src/core/ngx_palloc.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_array.o > src/core/ngx_array.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_list.o > src/core/ngx_list.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_hash.o > src/core/ngx_hash.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_buf.o > src/core/ngx_buf.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_queue.o > src/core/ngx_queue.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o > objs/src/core/ngx_output_chain.o src/core/ngx_output_chain.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_string.o > src/core/ngx_string.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_parse.o > src/core/ngx_parse.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_inet.o > src/core/ngx_inet.c > gcc -c -m32 -I/usr/pkg/include -L/usr/pkg/lib -I src/core -I src/event -I > src/event/modules -I src/os/unix -I objs -o objs/src/core/ngx_file.o > src/core/ngx_file.c > /var/tmp//ccouiI9K.s: Assembler messages: > /var/tmp//ccouiI9K.s:683: Error: Architecture mismatch on "casa". > /var/tmp//ccouiI9K.s:683: (Requires v9|v9a|v9b; requested architecture is > sparclite.) > *** Error code 1 > > Stop. > make: stopped in /usr/pkg/src/nginx-1.2.6 > *** Error code 1 > > Stop. > make: stopped in /usr/pkg/src/nginx-1.2.6 > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234730,234730#msg-234730 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From fry.kun at gmail.com Sat Jan 5 23:22:16 2013 From: fry.kun at gmail.com (Konstantin Svist) Date: Sat, 05 Jan 2013 15:22:16 -0800 Subject: =?UTF-8?B?UmU6IHVzZSBlcG9sbCDQuCDRgSDRh9C10Lwg0LXQs9C+INC10LTRj9GCPw==?= In-Reply-To: <04e9b926f97bfb466710b776ae18d0b5.NginxMailingListRussian@forum.nginx.org> References: <04e9b926f97bfb466710b776ae18d0b5.NginxMailingListRussian@forum.nginx.org> Message-ID: <50E8B5A8.3070306@gmail.com> On 01/05/2013 12:53 PM, Renat wrote: > К сожалению в Интернете удалось найти очень мало документации о epoll, это > какой-то эффективный метод обработки соединений в Linux 2.6+. Но кто-то > может более подробно рассказать как он работает и чем он хорош? > Спасибо. select, poll, epoll, kqueue, ... и.т.д. в упрощённом виде всё одно и тоже -- методы уведомления процесса о том что данные из/для I/O готовы. Т.е. процесс вместо того чтобы просыпаться каждые N миллисекунд в цикле только для того чтобы проверить готово ли I/O -- вызывает select и спит до тех пор пока kernel его разбудит. В Linux 2.6+ есть несколько таких методов, но epoll самый подходящий для того как nginx обрабатывает данные - потому и рекомендуется. From maillist at itcall.ru Sun Jan 6 00:48:45 2013 From: maillist at itcall.ru (maillist at itcall.ru) Date: Sun, 06 Jan 2013 04:48:45 +0400 Subject: =?UTF-8?B?cmVhbElQINC4IGZyb250ZW5kLWJhY2tlbmQg0LIg0LrQsNGH0LXRgdGC0LLQtSBu?= =?UTF-8?B?Z2lueA==?= Message-ID: <311820364.20130106044844@itcall.ru> Здравствуйте. Хочется, чтобы на бекенде переменная $remote_addr была корректно установлена. Ситуация: На фронтенде (nginx 1.3.8) подключено: proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; На бекенде (тоже nginx) переменная $http_x_forwarded_for корректно устанавливается, однако в логах бекенда вижу локальный (т.е. неправильный) IP фронтенда. Как можно поправить ситуацию? Спасибо. From hell-for-yahoo at umail.ru Sun Jan 6 00:59:19 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Sun, 6 Jan 2013 04:59:19 +0400 Subject: =?UTF-8?B?UmU6IHJlYWxJUCDQuCBmcm9udGVuZC1iYWNrZW5kINCyINC60LDRh9C10YHRgtCy?= =?UTF-8?B?0LUgbmdpbng=?= In-Reply-To: <311820364.20130106044844@itcall.ru> References: <311820364.20130106044844@itcall.ru> Message-ID: <1682725554.20130106045919@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) maillist at itcall.ru! mir> Здравствуйте. Хочется, чтобы на бекенде переменная $remote_addr была mir> корректно установлена. mir> Ситуация: mir> На фронтенде (nginx 1.3.8) подключено: mir> proxy_set_header Host $host; mir> proxy_set_header X-Real-IP $remote_addr; mir> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; mir> На бекенде (тоже nginx) переменная $http_x_forwarded_for корректно mir> устанавливается, однако в логах бекенда вижу локальный (т.е. неправильный) IP mir> фронтенда. mir> Как можно поправить ситуацию? Показывайте конфигурацию полностью, а не креативную нарезку и фантазии на тему. Тогда можно будет судить, что и как вы делаете. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) воскресенье, 06.01.2013, <04:58> From voron at amhost.net Sun Jan 6 06:50:34 2013 From: voron at amhost.net (Alex Vorona) Date: Sun, 06 Jan 2013 08:50:34 +0200 Subject: =?UTF-8?B?UmU6IHJlYWxJUCDQuCBmcm9udGVuZC1iYWNrZW5kINCyINC60LDRh9C10YHRgtCy?= =?UTF-8?B?0LUgbmdpbng=?= In-Reply-To: <311820364.20130106044844@itcall.ru> References: <311820364.20130106044844@itcall.ru> Message-ID: <50E91EBA.10408@amhost.net> 06.01.2013 02:48, maillist at itcall.ru wrote: [...] > На бекенде (тоже nginx) переменная $http_x_forwarded_for корректно > устанавливается, однако в логах бекенда вижу локальный (т.е. неправильный) IP > фронтенда. > > Как можно поправить ситуацию? http://nginx.org/ru/docs/http/ngx_http_realip_module.html#set_real_ip_from на бекенде From maillist at itcall.ru Sun Jan 6 10:25:14 2013 From: maillist at itcall.ru (=?koi8-r?B?4sXI1MXSxdcg5M3J1NLJyg==?=) Date: Sun, 06 Jan 2013 14:25:14 +0400 Subject: =?UTF-8?B?UmU6IHJlYWxJUCDQuCBmcm9udGVuZC1iYWNrZW5kINCyINC60LDRh9C10YHRgtCy?= =?UTF-8?B?0LUgbmdpbng=?= In-Reply-To: <50E91EBA.10408@amhost.net> References: <311820364.20130106044844@itcall.ru> <50E91EBA.10408@amhost.net> Message-ID: <239702242.20130106142512@itcall.ru> Здравствуйте, Alex. Спасибо, очень помогло. Вы писали 6 января 2013 г., 10:52:23: > 06.01.2013 02:48, maillist at itcall.ru wrote: > [...] >> На бекенде (тоже nginx) переменная $http_x_forwarded_for корректно >> устанавливается, однако в логах бекенда вижу локальный (т.е. неправильный) IP >> фронтенда. >> >> Как можно поправить ситуацию? > http://nginx.org/ru/docs/http/ngx_http_realip_module.html#set_real_ip_from на бекенде > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Бехтерев mailto:maillist at itcall.ru From nginx-forum at nginx.us Sun Jan 6 11:09:24 2013 From: nginx-forum at nginx.us (sanchous) Date: Sun, 06 Jan 2013 06:09:24 -0500 Subject: nginx sparc In-Reply-To: <0273F14A-6B62-47A6-AAF0-51A35B296EDE@waeme.net> References: <0273F14A-6B62-47A6-AAF0-51A35B296EDE@waeme.net> Message-ID: Sergey Budnevitch Wrote: ------------------------------------------------------- > > Судя по sparclite это не просто не ultra, а даже не sparc-v8, а v8e. > casa в нем нем нет, поэтому и не собирается. Из какого-то музея или > какой-то странный embedded? так точно, из музея перехватил ее, когда на мусорку несли > Попробуйте собрать с --with-libatomic, с установленной соответствующей > библиотекой (/usr/pkgsrc/devel/libatomic_ops). попробовал, собралось и заработало большое спасибо, проблема решена Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234730,234741#msg-234741 From nginx-forum at nginx.us Sun Jan 6 15:48:11 2013 From: nginx-forum at nginx.us (billi) Date: Sun, 06 Jan 2013 10:48:11 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0LrQsNC20LjRgtC1INC/0L4g0L/QtdGA0LXQvdCw0L/RgNCw?= =?UTF-8?B?0LLQu9C10L3QuNGO?= In-Reply-To: <00eb11e901366af9aceb7daa08d80aa0.NginxMailingListRussian@forum.nginx.org> References: <00eb11e901366af9aceb7daa08d80aa0.NginxMailingListRussian@forum.nginx.org> Message-ID: <008c456959fffd905b30ffde5197a526.NginxMailingListRussian@forum.nginx.org> с перенаправлением получилось. спс. сча задача немного изменилась. требуется чтобы контент который был запрошен через myhost2.myhost у myhost копировался на myhost2 чтобы при следующем запросе данного контента он уже забирался у myhost2 , а не у myhost. добавил в конфиг след параметр proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=cache:30m inactiv=3d; но насколько это верно хз. если неверно ,то посоветуйте как правильно Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234541,234743#msg-234743 From nginx-forum at nginx.us Mon Jan 7 12:28:50 2013 From: nginx-forum at nginx.us (Voenniy) Date: Mon, 07 Jan 2013 07:28:50 -0500 Subject: =?UTF-8?B?UmU6IE5naW54INC90LUg0YXQvtGH0LXRgiDRgNCw0LHQvtGC0LDRgtGMINGH0LU=?= =?UTF-8?B?0YDQtdC3IHVuaXggc29ja2V0INGBIHBocC1mcG0=?= In-Reply-To: <4c11341f05f0dc9b4d72bfb63c4425e6.NginxMailingListRussian@forum.nginx.org> References: <4c11341f05f0dc9b4d72bfb63c4425e6.NginxMailingListRussian@forum.nginx.org> Message-ID: <9b15c6c11c29f91d28dc3bb6af8fd594.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Такая же проблема. Вам удалось как-то её победить? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,117453,234770#msg-234770 From nginx-forum at nginx.us Tue Jan 8 15:35:32 2013 From: nginx-forum at nginx.us (aaaa5) Date: Tue, 08 Jan 2013 10:35:32 -0500 Subject: =?UTF-8?B?TWFwINGB0LXRgNCy0LXRgNCwINC40LcgdXBzdHJlYW0=?= Message-ID: <21a65b40102f1b5b33a95202efb05bec.NginxMailingListRussian@forum.nginx.org> Здравствуйте. С помощью map можно выбирать на какой upstream делать backend: map $host $backend { a backend1; b backend2; ...... } Вопрос следующий. Надо сделать map на сервера внутри upstream, т.е. upstream beckend { server1; server2; .... } Если беру в качестве переменной в map proxy_host, то проксирует на значение "beckend", а нужно чтобы на server1, server2 ... и т.д. Или я в чём-то ошибаюсь? Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234788,234788#msg-234788 From nginx-forum at nginx.us Tue Jan 8 16:04:26 2013 From: nginx-forum at nginx.us (aaaa5) Date: Tue, 08 Jan 2013 11:04:26 -0500 Subject: =?UTF-8?B?UmU6IE1hcCDRgdC10YDQstC10YDQsCDQuNC3IHVwc3RyZWFt?= In-Reply-To: <21a65b40102f1b5b33a95202efb05bec.NginxMailingListRussian@forum.nginx.org> References: <21a65b40102f1b5b33a95202efb05bec.NginxMailingListRussian@forum.nginx.org> Message-ID: $upstream_addr вообще ничего не даёт. Или я неправильно её использую? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234788,234789#msg-234789 From mdounin at mdounin.ru Tue Jan 8 17:11:19 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 8 Jan 2013 21:11:19 +0400 Subject: =?UTF-8?B?UmU6IE1hcCDRgdC10YDQstC10YDQsCDQuNC3IHVwc3RyZWFt?= In-Reply-To: <21a65b40102f1b5b33a95202efb05bec.NginxMailingListRussian@forum.nginx.org> References: <21a65b40102f1b5b33a95202efb05bec.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130108171119.GF73378@mdounin.ru> Hello! On Tue, Jan 08, 2013 at 10:35:32AM -0500, aaaa5 wrote: > Здравствуйте. С помощью map можно выбирать на какой upstream делать > backend: > map $host $backend { > a backend1; > b backend2; > ...... > } > Вопрос следующий. Надо сделать map на сервера внутри upstream, т.е. > upstream beckend { > server1; > server2; > .... > } > Если беру в качестве переменной в map proxy_host, то проксирует на значение > "beckend", а нужно чтобы на server1, server2 ... и т.д. > Или я в чём-то ошибаюсь? Блок upstream - это цельная сущность. Нельзя сделать "map на сервер внутри upstream", можно - выбрать, на какой из блоков upstream отправить запрос. -- Maxim Dounin http://nginx.com/support.html From andrey at kopeyko.ru Tue Jan 8 18:21:24 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Tue, 08 Jan 2013 22:21:24 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0LrQsNC20LjRgtC1INC/0L4g0L/QtdGA0LXQvdCw0L/RgNCw?= =?UTF-8?B?0LLQu9C10L3QuNGO?= In-Reply-To: <008c456959fffd905b30ffde5197a526.NginxMailingListRussian@forum.nginx.org> References: <00eb11e901366af9aceb7daa08d80aa0.NginxMailingListRussian@forum.nginx.org> <008c456959fffd905b30ffde5197a526.NginxMailingListRussian@forum.nginx.org> Message-ID: <50EC63A4.9050909@kopeyko.ru> 06.01.2013 19:48, billi пишет: > с перенаправлением получилось. спс. > сча задача немного изменилась. требуется чтобы контент который был запрошен > через myhost2.myhost у myhost копировался на myhost2 чтобы при следующем > запросе данного контента он уже забирался у myhost2 , а не у myhost. > добавил в конфиг след параметр > proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=cache:30m > inactiv=3d; но насколько это верно хз. > если неверно ,то посоветуйте как правильно Правильно - всёж таки прочитать документацию, там будет и ответ на вопрос "насколько это верно". И обратите внимание на proxy_store - вам он подойдёт больше, нежели proxy_cache. -- Best regards, Andrey Kopeyko From panfilov at sports.ru Tue Jan 8 18:25:54 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Tue, 8 Jan 2013 22:25:54 +0400 Subject: =?UTF-8?B?UmU6IE1hcCDRgdC10YDQstC10YDQsCDQuNC3IHVwc3RyZWFt?= In-Reply-To: <20130108171119.GF73378@mdounin.ru> References: <21a65b40102f1b5b33a95202efb05bec.NginxMailingListRussian@forum.nginx.org> <20130108171119.GF73378@mdounin.ru> Message-ID: при этом скоро вопрошающий узнает, что имя хоста узнаётся после того, как выбран нужный upstream. 8 января 2013 г., 21:11 пользователь Maxim Dounin написал: > Hello! > > On Tue, Jan 08, 2013 at 10:35:32AM -0500, aaaa5 wrote: > > > Здравствуйте. С помощью map можно выбирать на какой upstream делать > > backend: > > map $host $backend { > > a backend1; > > b backend2; > > ...... > > } > > Вопрос следующий. Надо сделать map на сервера внутри upstream, т.е. > > upstream beckend { > > server1; > > server2; > > .... > > } > > Если беру в качестве переменной в map proxy_host, то проксирует на > значение > > "beckend", а нужно чтобы на server1, server2 ... и т.д. > > Или я в чём-то ошибаюсь? > > Блок upstream - это цельная сущность. Нельзя сделать "map на > сервер внутри upstream", можно - выбрать, на какой из блоков > upstream отправить запрос. > > -- > Maxim Dounin > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jan 8 19:52:33 2013 From: nginx-forum at nginx.us (bioargonaft) Date: Tue, 08 Jan 2013 14:52:33 -0500 Subject: =?UTF-8?B?UmU6INC60LXRiNC40YDQvtCy0LDQvdC40LUg0Y3Qu9C10LzQtdC90YLQvtCyINC0?= =?UTF-8?B?0LjQt9Cw0LnQvdCw?= In-Reply-To: <7bc86e6055b603af263d743c90cff354.NginxMailingListRussian@forum.nginx.org> References: <7bc86e6055b603af263d743c90cff354.NginxMailingListRussian@forum.nginx.org> Message-ID: <3ec4ec654a867cd54977e2c9f442b459.NginxMailingListRussian@forum.nginx.org> Хочу еще раз уточнить дествительно ли в nginx можно реализовать алгоритм, расписанный выше? А именно мне бы хотелось реализовать схему, когда есть кеш и я хочу при помощи одного локейшена брать из кеша файлы с определенными расширениями. Т.е. хочу реализовать задачку наподобии той, когда файлы нужных расширений берутся из определенного каталога. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234478,234798#msg-234798 From nginx-forum at nginx.us Tue Jan 8 20:56:49 2013 From: nginx-forum at nginx.us (aaaa5) Date: Tue, 08 Jan 2013 15:56:49 -0500 Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCIHJld3JpdGUt0LzQvtC00YPQu9GM?= Message-ID: Переустановил систему и вместе с ней nginx. С самого начала nginx заругался на pcre, хотя в системе по умолчанию установлена pcre 8.21. я начал указывать --with-pcre=path, но не работала, поэтому решил сделать --without-http_rewrite_module. После этого заработала, благо никаких rewrite'ов у меня нет. Потом пришлось сделать rewrite. Скачал, установил pcre-8.32. Делаю так: ./configure --with-debug --with-pcre=/home/user/Downloads/pcre-8.32 make make install Система устанавливается, но rewrite'ы не работают. Вот отрывок из лога: 2013/01/09 00:04:34 [debug] 27746#0: *1 http script copy: "http://127.0.0.1:2222/loc1/" 2013/01/09 00:04:34 [debug] 27746#0: *1 http script capture: "aaaaaaaaa" 2013/01/09 00:04:34 [debug] 27746#0: *1 http script copy: "&bbbbbbbbb" 2013/01/09 00:04:34 [debug] 27746#0: *1 http script regex end 2013/01/09 00:04:34 [notice] 27746#0: *1 rewritten redirect: "http://127.0.0.1:2222/loc1/aaaaaaaaa&bbbbbbbbb", client: 127.0.0.1, server: test.ru, request: "GET /loc1 HTTP/1.1", host: "test.ru", referrer: "http://test.ru/001.php" 2013/01/09 00:04:34 [debug] 27746#0: *1 http finalize request: 302, "/loc1?" a:1, c:1 2013/01/09 00:04:34 [debug] 27746#0: *1 http special response: 302, "/loc1?" 2013/01/09 00:04:34 [debug] 27746#0: *1 http set discard body 2013/01/09 00:04:34 [debug] 27746#0: *1 HTTP/1.1 302 Moved Temporarily Server: nginx/1.2.5 Date: Tue, 08 Jan 2013 20:04:34 GMT Content-Type: text/html Content-Length: 160 Connection: keep-alive Location: http://127.0.0.1:2222/loc1/aaaaaaaaa&bbbbbbbbb 2013/01/09 00:04:34 [debug] 27746#0: *1 write new buf t:1 f:0 00000000006F9240, pos 00000000006F9240, size: 274 file: 0, size: 0 2013/01/09 00:04:34 [debug] 27746#0: *1 http write filter: l:0 f:0 s:274 2013/01/09 00:04:34 [debug] 27746#0: *1 http output filter "/loc1?" и никакого редиректа не происходит. Логи в 127.0.0.1:2222 пустые. Хотя все конфиги взяты со старой системы, то бишь в конфигах ошибок нет. В интернете ничего не нашёл. Т.е. из логов видно, что pcre работает, просто нет редиректа на бекенд 127.0.0.1:2222 Спасибо за помощь Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234801#msg-234801 From nginx-forum at nginx.us Tue Jan 8 21:13:40 2013 From: nginx-forum at nginx.us (aaaa5) Date: Tue, 08 Jan 2013 16:13:40 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: References: Message-ID: <5241deeb4b709fef12bdb40ac2dbaf63.NginxMailingListRussian@forum.nginx.org> Ещё что смущает: отрывок из установочного лога: pcre-8.32 configuration summary: Install prefix .................. : /usr/local C preprocessor .................. : gcc -E C compiler ...................... : gcc C++ preprocessor ................ : g++ -E C++ compiler .................... : g++ Linker .......................... : /bin/ld -m elf_x86_64 C preprocessor flags ............ : C compiler flags ................ : -O2 -fomit-frame-pointer -pipe -fvisibility=hidden C++ compiler flags .............. : -O2 -fvisibility=hidden -fvisibility-inlines-hidden Linker flags .................... : Extra libraries ................. : Build 8 bit pcre library ........ : yes Build 16 bit pcre library ....... : no Build 32 bit pcre library ....... : no Build C++ library ............... : yes Enable JIT compiling support .... : no Enable UTF-8/16/32 support ...... : no Unicode properties .............. : no Newline char/sequence ........... : lf \R matches only ANYCRLF ......... : no EBCDIC coding ................... : no EBCDIC code for NL .............. : n/a Rebuild char tables ............. : no Use stack recursion ............. : yes POSIX mem threshold ............. : 10 Internal link size .............. : 2 Match limit ..................... : 10000000 Match limit recursion ........... : MATCH_LIMIT Build shared libs ............... : no Build static libs ............... : yes Use JIT in pcregrep ............. : no Buffer size for pcregrep ........ : 20480 Link pcregrep with libz ......... : no Link pcregrep with libbz2 ....... : no Link pcretest with libedit ...... : no Link pcretest with libreadline .. : no Valgrind support ................ : no Code coverage ................... : no т.е. указано, что: Build 8 bit pcre library ........ : yes Build 16 bit pcre library ....... : no Build 32 bit pcre library ....... : no может из-за этого? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234803#msg-234803 From nginx-forum at nginx.us Tue Jan 8 21:37:54 2013 From: nginx-forum at nginx.us (aaaa5) Date: Tue, 08 Jan 2013 16:37:54 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: References: Message-ID: <560dbecb5149aff42661700e86e251d0.NginxMailingListRussian@forum.nginx.org> ещё один момент: в Chrome редирект красного цвета и статус Canceled. Почему происходит Cancel? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234804#msg-234804 From panfilov at sports.ru Tue Jan 8 21:39:26 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Wed, 9 Jan 2013 01:39:26 +0400 Subject: =?UTF-8?B?UmU6INC60LXRiNC40YDQvtCy0LDQvdC40LUg0Y3Qu9C10LzQtdC90YLQvtCyINC0?= =?UTF-8?B?0LjQt9Cw0LnQvdCw?= In-Reply-To: <3ec4ec654a867cd54977e2c9f442b459.NginxMailingListRussian@forum.nginx.org> References: <7bc86e6055b603af263d743c90cff354.NginxMailingListRussian@forum.nginx.org> <3ec4ec654a867cd54977e2c9f442b459.NginxMailingListRussian@forum.nginx.org> Message-ID: Действительно можно. Возникнут вопросы: 1. Как долго держать файлы в кеше и как их обновлять. 2. Если будет несколько бекендов/фронтендов и аплоад картинок - как это дело синхронизировать. Вопросы решаемы, но они возникнут :) 8 января 2013 г., 23:52 пользователь bioargonaft написал: > Хочу еще раз уточнить дествительно ли в nginx можно реализовать алгоритм, > расписанный выше? > А именно мне бы хотелось реализовать схему, когда есть кеш и я хочу при > помощи одного локейшена брать из кеша файлы с определенными расширениями. > Т.е. хочу реализовать задачку наподобии той, когда файлы нужных расширений > берутся из определенного каталога. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,234478,234798#msg-234798 > > _______________________________________________ > 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 Tue Jan 8 22:15:51 2013 From: nginx-forum at nginx.us (aaaa5) Date: Tue, 08 Jan 2013 17:15:51 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: References: Message-ID: <7b17e3b72f74747ab1a536a33adc4265.NginxMailingListRussian@forum.nginx.org> работает rewrite на один-единственный хост http://test.ru аля 127.0.0.1 - http://localhost - http://www.test.ru - http://127.0.0.1 не работают http://test.ru:2222 - не работает. Только без указания порта редиректит в корень Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234810#msg-234810 From mdounin at mdounin.ru Tue Jan 8 23:44:25 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 9 Jan 2013 03:44:25 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: <7b17e3b72f74747ab1a536a33adc4265.NginxMailingListRussian@forum.nginx.org> References: <7b17e3b72f74747ab1a536a33adc4265.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130108234424.GI73378@mdounin.ru> Hello! On Tue, Jan 08, 2013 at 05:15:51PM -0500, aaaa5 wrote: > работает rewrite на один-единственный хост http://test.ru аля 127.0.0.1 > - http://localhost > - http://www.test.ru > - http://127.0.0.1 > > не работают > > http://test.ru:2222 - не работает. > > Только без указания порта редиректит в корень Судя по симптомам, вы пытаетесь бороться с Same Origin Policy браузера, см. подробности тут: http://en.wikipedia.org/wiki/Same_origin_policy http://ru.wikipedia.org/wiki/Правило_ограничения_домена Делать это в настройках nginx'а - довольно бессмысленно, ибо nginx возврает браузеру ровно то, что сказали. Просто браузер некоторые вещи отказывается делать. По ссылкам выше расписано почему так, и как с этим жить. -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Wed Jan 9 05:45:04 2013 From: nginx-forum at nginx.us (aaaa5) Date: Wed, 09 Jan 2013 00:45:04 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: <20130108234424.GI73378@mdounin.ru> References: <20130108234424.GI73378@mdounin.ru> Message-ID: <64169d24c25697beb9e1971e278d1321.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Вот мой rewrite location: location ~/loc1(.*)$ { rewrite ^/loc1(.*)$ http://127.0.0.1:2222/loc1/$1 break; } server { listen 2222; .... } в старой системе на старом nginx'e всё работало. После переустановки перестало. Да и http://127.0.0.1 как-то не совсем понятно, он-то чем не угодил same origin policy Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234819#msg-234819 From nefer05 at gmail.com Wed Jan 9 06:44:14 2013 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Wed, 9 Jan 2013 09:44:14 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: <64169d24c25697beb9e1971e278d1321.NginxMailingListRussian@forum.nginx.org> References: <20130108234424.GI73378@mdounin.ru> <64169d24c25697beb9e1971e278d1321.NginxMailingListRussian@forum.nginx.org> Message-ID: Кусок лога, вами же приведенный, прозрачно намекает что nginx отрабатывает. Следовательно копайте дальше, но в другом месте. --- 2013/01/09 00:04:34 [debug] 27746#0: *1 HTTP/1.1 302 Moved Temporarily Server: nginx/1.2.5 Date: Tue, 08 Jan 2013 20:04:34 GMT Content-Type: text/html Content-Length: 160 Connection: keep-alive Location: http://127.0.0.1:2222/loc1/aaaaaaaaa&bbbbbbbbb -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Jan 9 07:15:42 2013 From: nginx-forum at nginx.us (daitepiva) Date: Wed, 09 Jan 2013 02:15:42 -0500 Subject: =?UTF-8?B?0JrQtdGI0LjRgNC+0LLQsNC90LjQtSDQv9C+INC60YPQutCw0Lwg0LTQu9GPINCz?= =?UTF-8?B?0L7RgdGC0LXQuSDRhNC+0YDRg9C80LAg0L3QsCBJUEIgKEludmlzaW9uIFBv?= =?UTF-8?B?d2VyIEJvYXJkKQ==?= Message-ID: Приветствую. Пытался сделать кеширование по наличию-отсутствию некоторых типичных кук (member_id pass_hash session_id) для гостей форума на IPB 2.3 (Invision Power Board). Вроде всё работало как надо - кешировалось только гостям, файлы в папке кеша появлялись и удалялись как надо. Но появились серьёзные проблемы - чужие страницы, сессии, хотя кеширование было настроено именно по отсутствию всех ключевых куков - идентификатор пользователя, хеш пароля, идентификатор сессии. На всякий случай включил эти куки в ключ объекта, но там было пусто или нули, т.е. при наличии хотя бы одного из них ответ не кешировался. Включал эти переменные в логи - есть. Включал в логи переменную upstream_cache_status, ничего аномального не заметил. Толи какие-то особенности работы движка, толи я что-то накосячил в конфиге. Вот конфиг в части, касающейся кеширования: http { ... proxy_cache_path /var/nginx/proxy_temp levels= keys_zone=dguests:100m inactive=3m max_size=100m; server { ... proxy_cache_key "$host$request_uri|$request_method|$cookie_member_id|$cookie_pass_hash"; proxy_cache_bypass $cookie_pass_hash $cookie_member_id $cookie_session_id; proxy_no_cache $cookie_pass_hash $cookie_member_id $cookie_session_id; proxy_ignore_headers Expires Cache-Control Set-Cookie; proxy_cache off; location ~ \.php$ { proxy_pass http://127.0.0.1:8080; proxy_set_header X-Real-IP $remote_addr; proxy_cache dguests; proxy_cache_valid 30s; } } } Пришлось включить Set-Cookie в proxy_ignore_headers, т.к. движок выдаёт её гостям и страницы не кешировались вовсе. Пробовал добавлять "proxy_hide_header "Set-Cookie";", но тогда не проходит авторизация. Вообще же задача в снижении нагрузки и, в идеале, повышение устройчивости к ДДоС-атакам, за счёт кеширования страниц для гостей, а их у меня больше чем пользователей, например, прямо сейчас онлайн 2700 гостей и 1600 пользователей. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234824,234824#msg-234824 From nginx-forum at nginx.us Wed Jan 9 07:27:59 2013 From: nginx-forum at nginx.us (aaaa5) Date: Wed, 09 Jan 2013 02:27:59 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: <20130108234424.GI73378@mdounin.ru> References: <20130108234424.GI73378@mdounin.ru> Message-ID: <511a561a805d8c7603d6d90bb5efcdc0.NginxMailingListRussian@forum.nginx.org> хорошо, ладно, согласен. Вы мне объясните, почему http://127.0.0.1 не работает, а http://test.ru работает и тогда я пойму Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234825#msg-234825 From nginx-forum at nginx.us Wed Jan 9 07:30:11 2013 From: nginx-forum at nginx.us (bioargonaft) Date: Wed, 09 Jan 2013 02:30:11 -0500 Subject: =?UTF-8?B?UmU6INC60LXRiNC40YDQvtCy0LDQvdC40LUg0Y3Qu9C10LzQtdC90YLQvtCyINC0?= =?UTF-8?B?0LjQt9Cw0LnQvdCw?= In-Reply-To: References: Message-ID: Михаил Панфилов Wrote: ------------------------------------------------------- > Действительно можно. > Возникнут вопросы: > 1. Как долго держать файлы в кеше и как их обновлять. > 2. Если будет несколько бекендов/фронтендов и аплоад картинок - как > это > дело синхронизировать. > > Вопросы решаемы, но они возникнут :) Задача скорее всего сведентся к одному фронтенду и одному бэкенду. Возможно позже возникнет необходимость обслуживать несколько бэкендов. Кеш держать можно сутки, либо неделю. В первую очередь задача кешировать элементы дизайна, стандартные и не очень js'сы и т.д. Такое решение обусловлено необходимостью повысить производительность domino-сервера в части отдачи web'а. И поскольку содержимое находится в доминошной базе *.nsf , то выкладывать статику на хосте с nginx'ом в виде лотусовой базы совсем никак. А если и выкладывать статику, то усложнится обслуживание при регулярном обновлении web'овских приложений. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234478,234826#msg-234826 From nginx-forum at nginx.us Wed Jan 9 07:32:45 2013 From: nginx-forum at nginx.us (aaaa5) Date: Wed, 09 Jan 2013 02:32:45 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: <511a561a805d8c7603d6d90bb5efcdc0.NginxMailingListRussian@forum.nginx.org> References: <20130108234424.GI73378@mdounin.ru> <511a561a805d8c7603d6d90bb5efcdc0.NginxMailingListRussian@forum.nginx.org> Message-ID: <4f56fa391965806eace0842c5125f338.NginxMailingListRussian@forum.nginx.org> всё, кажется разобрался. Всем спасибо Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234827#msg-234827 From nginx-forum at nginx.us Wed Jan 9 07:35:39 2013 From: nginx-forum at nginx.us (aaaa5) Date: Wed, 09 Jan 2013 02:35:39 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: <511a561a805d8c7603d6d90bb5efcdc0.NginxMailingListRussian@forum.nginx.org> References: <20130108234424.GI73378@mdounin.ru> <511a561a805d8c7603d6d90bb5efcdc0.NginxMailingListRussian@forum.nginx.org> Message-ID: <42e8c3c6814a6e390b8fe6796399a75b.NginxMailingListRussian@forum.nginx.org> если запускать скрипт из http://test.ru то редиректы работают только на http://test.ru. Если из http://127.0.0.1, то соответственно только на http://127.0.0.1. same origin policy Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234828#msg-234828 From nginx-forum at nginx.us Wed Jan 9 08:51:39 2013 From: nginx-forum at nginx.us (bioargonaft) Date: Wed, 09 Jan 2013 03:51:39 -0500 Subject: =?UTF-8?B?UmU6INC60LXRiNC40YDQvtCy0LDQvdC40LUg0Y3Qu9C10LzQtdC90YLQvtCyINC0?= =?UTF-8?B?0LjQt9Cw0LnQvdCw?= In-Reply-To: References: <7bc86e6055b603af263d743c90cff354.NginxMailingListRussian@forum.nginx.org> Message-ID: И еще хотел спросить нужно ли задать условие, что если в кеше нет нужных файлов, то их брать с бэкенда? (Конфиги в 5-м посте). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234478,234830#msg-234830 From nginx-forum at nginx.us Wed Jan 9 08:58:12 2013 From: nginx-forum at nginx.us (aaaa5) Date: Wed, 09 Jan 2013 03:58:12 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: References: Message-ID: Сорри, а в Russian Mailing list нельзя создавать сообщения как Anonymous User, чтобы не придумывать аккаунты как aaaa5? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234801,234831#msg-234831 From mdounin at mdounin.ru Wed Jan 9 09:49:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 9 Jan 2013 13:49:33 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZXdyaXRlLdC80L7QtNGD0LvRjA==?= In-Reply-To: References: Message-ID: <20130109094933.GB80623@mdounin.ru> Hello! On Wed, Jan 09, 2013 at 03:58:12AM -0500, aaaa5 wrote: > Сорри, а в Russian Mailing list нельзя создавать сообщения как Anonymous > User, чтобы не придумывать аккаунты как aaaa5? Нет. Можно подписаться на список рассылки тут: http://mailman.nginx.org/mailman/listinfo Тогда ничего придумывать будет не надо. -- Maxim Dounin http://nginx.com/support.html From oleg.malaphey at gmail.com Wed Jan 9 11:26:36 2013 From: oleg.malaphey at gmail.com (Oleg Malaphey) Date: Wed, 9 Jan 2013 14:26:36 +0300 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4g0YDQsNCx0L7RgtC1IGVycm9yX3BhZ2Ug0YHQvtCy?= =?UTF-8?B?0LzQtdGB0YLQvdC+INGBIGlmINC4IHJldHVybi4=?= Message-ID: Добрый день! Подскажите пожалуйста, должна ли работать кастомная страница error_page для return 40x в блоке if? Если нет, то почему? Например следующая конфигурация будет отдавать стандартную страницу ошибки nginx 403 : error_page 403 /m/403.html; if ( $request_uri ~* /.svn/) { return 403; } А вот конфигурация с использованием location уже отдаст кастомную страницу ошибки (/m/403.html): error_page 403 /m/403.html; location ~* /.svn/ { return 403; } nginx -V nginx version: nginx/1.2.6 -- Best Wishes, Oleg Malaphey -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Jan 9 12:36:46 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 9 Jan 2013 16:36:46 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGA0LDQsdC+0YLQtSBlcnJvcl9wYWdlINGB?= =?UTF-8?B?0L7QstC80LXRgdGC0L3QviDRgSBpZiDQuCByZXR1cm4u?= In-Reply-To: References: Message-ID: <20130109123646.GC80623@mdounin.ru> Hello! On Wed, Jan 09, 2013 at 02:26:36PM +0300, Oleg Malaphey wrote: > Добрый день! > > Подскажите пожалуйста, должна ли работать кастомная страница error_page для > return 40x в блоке if? Если нет, то почему? > > Например следующая конфигурация будет отдавать стандартную страницу ошибки > nginx 403 : > > error_page 403 /m/403.html; > > if ( $request_uri ~* /.svn/) { > return 403; > } После первого возврата 403 - nginx, в соответствии с error_page, выполняет внутреннее перенаправление на /m/403.html. Однако при обработке запроса к /m/403.html снова случается 403 (потому что опять срабатывает тот же if, ибо $request_uri - это uri исходного запроса), и возвращается стандартная ошибка (ибо одна попытка перейти по error_page уже была). Так что - всё работает, как и должно. Просто происходит то, что написано, а не то, что имелось в виду. > А вот конфигурация с использованием location уже отдаст кастомную страницу > ошибки (/m/403.html): > > error_page 403 /m/403.html; > > location ~* /.svn/ { > return 403; > } Так и имеет смысл делать. Это заодно решит проблему в проверке выше - она тривиально обходится с помощью %XX. -- Maxim Dounin http://nginx.com/support.html From oleg.malaphey at gmail.com Wed Jan 9 13:09:42 2013 From: oleg.malaphey at gmail.com (Oleg Malaphey) Date: Wed, 9 Jan 2013 16:09:42 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGA0LDQsdC+0YLQtSBlcnJvcl9wYWdlINGB?= =?UTF-8?B?0L7QstC80LXRgdGC0L3QviDRgSBpZiDQuCByZXR1cm4u?= In-Reply-To: <20130109123646.GC80623@mdounin.ru> References: <20130109123646.GC80623@mdounin.ru> Message-ID: Максим, спасибо за разъяснение! 9 января 2013 г., 15:36 пользователь Maxim Dounin написал: > Hello! > > On Wed, Jan 09, 2013 at 02:26:36PM +0300, Oleg Malaphey wrote: > > > Добрый день! > > > > Подскажите пожалуйста, должна ли работать кастомная страница error_page > для > > return 40x в блоке if? Если нет, то почему? > > > > Например следующая конфигурация будет отдавать стандартную страницу > ошибки > > nginx 403 : > > > > error_page 403 /m/403.html; > > > > if ( $request_uri ~* /.svn/) { > > return 403; > > } > > После первого возврата 403 - nginx, в соответствии с error_page, > выполняет внутреннее перенаправление на /m/403.html. Однако при > обработке запроса к /m/403.html снова случается 403 (потому что > опять срабатывает тот же if, ибо $request_uri - это uri исходного > запроса), и возвращается стандартная ошибка (ибо одна попытка > перейти по error_page уже была). > > Так что - всё работает, как и должно. Просто происходит то, что > написано, а не то, что имелось в виду. > > > А вот конфигурация с использованием location уже отдаст кастомную > страницу > > ошибки (/m/403.html): > > > > error_page 403 /m/403.html; > > > > location ~* /.svn/ { > > return 403; > > } > > Так и имеет смысл делать. Это заодно решит проблему в проверке > выше - она тривиально обходится с помощью %XX. > > > -- > Maxim Dounin > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best Wishes, Oleg Malaphey -------------- next part -------------- An HTML attachment was scrubbed... URL: From samarinaleksandr at gmail.com Wed Jan 9 16:31:54 2013 From: samarinaleksandr at gmail.com (=?KOI8-R?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Wed, 9 Jan 2013 18:31:54 +0200 Subject: nginx reload Message-ID: Добрый день! Подскажите, в чем может быть проблема. Есть сервер на centos 6.3. Установлен nginx version: nginx/1.2.5. Проблема появляется после <>. Сразу после релоада, начинает расти нагрузка на сервер.Коннекты не обрываются До релоада 55.0 74180 - nginx: worker process 53.5 74712 - nginx: worker process 54.4 75500 - nginx: worker process 53.9 74312 - nginx: worker process 54.3 74972 - nginx: worker process 54.3 74180 - nginx: worker process 53.4 74048 - nginx: worker process 53.8 75104 ep_pol nginx: worker process после 55.3 74576 - nginx: worker process is shutting down 54.7 75504 - nginx: worker process is shutting down 55.1 75500 - nginx: worker process is shutting down 55.1 74840 - nginx: worker process is shutting down 55.4 75632 - nginx: worker process is shutting down 55.2 74708 - nginx: worker process is shutting down 54.9 74576 - nginx: worker process is shutting down 55.2 75896 - nginx: worker process is shutting down 17.9 57524 - nginx: worker process is shutting down 19.6 57524 ep_pol nginx: worker process is shutting down 20.0 57524 ep_pol nginx: worker process is shutting down 17.6 57524 - nginx: worker process is shutting down 18.7 57524 - nginx: worker process is shutting down 14.6 57524 ep_pol nginx: worker process is shutting down 18.1 57524 - nginx: worker process is shutting down 19.0 57524 - nginx: worker process is shutting down 18.2 58200 - nginx: worker process 17.5 58332 ep_pol nginx: worker process 17.0 58332 - nginx: worker process 17.6 58464 - nginx: worker process 18.9 58332 - nginx: worker process 18.8 58332 - nginx: worker process 17.4 58728 - nginx: worker process 17.7 58200 - nginx: worker process И нагрузка продолжает расти top, сразу после релоада 1 user, load average: 40.41, 14.03, 11.82 Tasks: 192 total, 17 running, 175 sleeping, 0 stopped, 0 zombie Cpu(s): 38.9%us, 30.7%sy, 0.0%ni, 2.4%id, 0.0%wa, 0.0%hi, 27.9%si, 0.0%st Mem: 1922060k total, 1327168k used, 594892k free, 112960k buffers Swap: 2097144k total, 0k used, 2097144k free, 327068k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3962 nginx 20 0 75500 31m 896 R 33.8 1.7 185:16.38 nginx 3963 nginx 20 0 74840 31m 896 R 33.5 1.7 185:13.82 nginx 3964 nginx 20 0 75632 31m 896 S 33.5 1.7 186:09.56 nginx 3960 nginx 20 0 74576 30m 896 R 32.8 1.6 185:41.08 nginx 3966 nginx 20 0 74708 30m 896 R 32.8 1.6 185:36.28 nginx 3961 nginx 20 0 75504 31m 896 R 32.5 1.7 183:44.90 nginx 3968 nginx 20 0 75896 32m 896 R 32.5 1.7 185:20.11 nginx 3967 nginx 20 0 74576 30m 896 S 31.2 1.6 184:28.75 nginx 5173 nginx 20 0 60576 17m 880 R 26.6 0.9 2:52.41 nginx 5174 nginx 20 0 60972 17m 880 R 24.9 0.9 2:48.93 nginx 5172 nginx 20 0 60712 17m 880 R 24.6 0.9 2:55.61 nginx Active connections ~ 10 тысяч [image: Встроенное изображение 2] С уважением, Александр Самарин! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 8011 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: load_average.png Type: image/png Size: 7739 bytes Desc: not available URL: From mdounin at mdounin.ru Wed Jan 9 17:16:44 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 9 Jan 2013 21:16:44 +0400 Subject: nginx reload In-Reply-To: References: Message-ID: <20130109171644.GE80623@mdounin.ru> Hello! On Wed, Jan 09, 2013 at 06:31:54PM +0200, Александр Самарин wrote: > Добрый день! Подскажите, в чем может быть проблема. Есть сервер на centos > 6.3. Установлен nginx version: nginx/1.2.5. > > Проблема появляется после <>. Сразу после релоада, > начинает расти нагрузка на сервер.Коннекты не обрываются > > > > До релоада > > 55.0 74180 - nginx: worker process > 53.5 74712 - nginx: worker process > 54.4 75500 - nginx: worker process > 53.9 74312 - nginx: worker process > 54.3 74972 - nginx: worker process > 54.3 74180 - nginx: worker process > 53.4 74048 - nginx: worker process > 53.8 75104 ep_pol nginx: worker process > > > после > > 55.3 74576 - nginx: worker process is shutting down > 54.7 75504 - nginx: worker process is shutting down > 55.1 75500 - nginx: worker process is shutting down > 55.1 74840 - nginx: worker process is shutting down > 55.4 75632 - nginx: worker process is shutting down > 55.2 74708 - nginx: worker process is shutting down > 54.9 74576 - nginx: worker process is shutting down > 55.2 75896 - nginx: worker process is shutting down > 17.9 57524 - nginx: worker process is shutting down > 19.6 57524 ep_pol nginx: worker process is shutting down > 20.0 57524 ep_pol nginx: worker process is shutting down > 17.6 57524 - nginx: worker process is shutting down > 18.7 57524 - nginx: worker process is shutting down > 14.6 57524 ep_pol nginx: worker process is shutting down > 18.1 57524 - nginx: worker process is shutting down > 19.0 57524 - nginx: worker process is shutting down > 18.2 58200 - nginx: worker process > 17.5 58332 ep_pol nginx: worker process > 17.0 58332 - nginx: worker process > 17.6 58464 - nginx: worker process > 18.9 58332 - nginx: worker process > 18.8 58332 - nginx: worker process > 17.4 58728 - nginx: worker process > 17.7 58200 - nginx: worker process Судя по количеству процессов в стостоянии "shutting down", вы сделали reload дважды. Вообще reload - это операция, которая ожидаемо увеличивает нагрузку, т.к. запускаются новые рабочие процессы, при этом старые - продолжают работать, пока не закончат обслуживание ранее стартовавших запросов. В зависимости от характера нагрузки для конкретного сервера - это может быть долго. Если есть основания полагать, что наблюдаемое увеличение нагрузки - не объясняется вышеприведёнными причинами, то желательно их привести в явной форме. В приведённых на текущий момент данных я ничего необычного не вижу, всё вполне объяснимо двумя reload'ами и наличием долгих запросов на сервере. Подробно про reload можно почитать тут: http://nginx.org/ru/docs/control.html#reconfiguration -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Wed Jan 9 17:24:37 2013 From: nginx-forum at nginx.us (rashik) Date: Wed, 09 Jan 2013 12:24:37 -0500 Subject: =?UTF-8?B?0KHQstGP0LfQutCwIE5naW54ICsgSUJNIEhUVFBTZXJ2ZXIgK1dlYlNwaGVyZSBQ?= =?UTF-8?B?b3J0YWwuINCf0YDQsNCy0LjQu9GM0L3QsNGPINC+0LHRgNCw0LHQvtGC0Lo=?= =?UTF-8?B?0LAg0L7RiNC40LHQutC4INC/0YDQuCDQt9Cw0LPRgNGD0LfQutC1INGE0LA=?= =?UTF-8?B?0LnQu9CwINGBINC+0LPRgNCw0L3QuNGH0LXQvdC40Y/QvNC4INC/0L4g0YA=?= =?UTF-8?B?0LDQt9C80LXRgNGDLg==?= Message-ID: Имеется следующая конфигурация: 1. nginx - лоад-балансер; 2. IBM HTTP Server - http-сервер; 3. WebSphere Portal - апплет загрузки файлов. Проблема: Нужно уметь ограничивать размер загружаемого файла(например лимит в 10m). Имеется возможность установить лимит на стороне портала, но в таком случае файл загружается в темповую директорию nginx целиком и только потом отдается приложению и в этот момент приложение ругается на его размер, а размер файла может быть большим(например 1G). Такой вариант не подходит пользователь ничего не подозревая ждет загрузки файла и только после загрузки целиком узнает о лимите. В случае установки лимита в конфигах nginx получаем ошибку 413, что не очень подходит для данной задачи. Хотелось бы "прокинуть" ошибку до апплета. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234851,234851#msg-234851 From eugene.toropov at gmail.com Wed Jan 9 18:24:44 2013 From: eugene.toropov at gmail.com (Eugene Toropov) Date: Wed, 9 Jan 2013 22:24:44 +0400 Subject: source IP for private host Message-ID: Добрый вечер, Допустим на сервере есть два внешних интерфейса A и B и еще один внутренний C. Nginx слушает везде. На внутреннем сидит домен, проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? Евгений eugene.toropov at gmail.com From samarinaleksandr at gmail.com Wed Jan 9 18:44:23 2013 From: samarinaleksandr at gmail.com (=?koi8-r?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Wed, 9 Jan 2013 20:44:23 +0200 Subject: nginx reload In-Reply-To: <20130109171644.GE80623@mdounin.ru> References: <20130109171644.GE80623@mdounin.ru> Message-ID: <00e101cdee99$593dc600$0bb95200$@gmail.com> Максим, спасибо за скорый ответ! Reload действительно делался дважды, но в промежутке в несколько часов > Если есть основания полагать, что наблюдаемое увеличение нагрузки - не объясняется вышеприведёнными причинами, то желательно их привести в явной форме Пока ничего толком сказать не могу. Написал в рассылку в надежде, что кто-то подтолкнет к способу выявления проблемы. Ради експеримента сделал релоад - 1 час спустя количество процессов в стостоянии " shutting down" не уменьшилось >Вообще reload - это операция, которая ожидаемо увеличивает нагрузку Ожидаемо увеличиваемая нагрузка - это да, но не на 300%+ С уважением, Александр Самарин! -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Maxim Dounin Sent: Wednesday, January 9, 2013 7:17 PM To: nginx-ru at nginx.org Subject: Re: nginx reload Hello! Судя по количеству процессов в стостоянии "shutting down", вы сделали reload дважды. Вообще reload - это операция, которая ожидаемо увеличивает нагрузку, т.к. запускаются новые рабочие процессы, при этом старые - продолжают работать, пока не закончат обслуживание ранее стартовавших запросов. В зависимости от характера нагрузки для конкретного сервера - это может быть долго. Если есть основания полагать, что наблюдаемое увеличение нагрузки - не объясняется вышеприведёнными причинами, то желательно их привести в явной форме. В приведённых на текущий момент данных я ничего необычного не вижу, всё вполне объяснимо двумя reload'ами и наличием долгих запросов на сервере. Подробно про reload можно почитать тут: http://nginx.org/ru/docs/control.html#reconfiguration -- Maxim Dounin http://nginx.com/support.html _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru From samarinaleksandr at gmail.com Wed Jan 9 18:49:17 2013 From: samarinaleksandr at gmail.com (=?koi8-r?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Wed, 9 Jan 2013 20:49:17 +0200 Subject: source IP for private host In-Reply-To: References: Message-ID: <00e301cdee9a$081dfe10$1859fa30$@gmail.com> Они пойдут по default gw, если иное не оговорено в таблице маршрутизации С уважением, Александр Самарин! -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Eugene Toropov Sent: Wednesday, January 9, 2013 8:25 PM To: nginx-ru at nginx.org Subject: source IP for private host Добрый вечер, Допустим на сервере есть два внешних интерфейса A и B и еще один внутренний C. Nginx слушает везде. На внутреннем сидит домен, проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? Евгений eugene.toropov at gmail.com _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-ru at sadok.spb.ru Wed Jan 9 18:50:07 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 9 Jan 2013 22:50:07 +0400 Subject: source IP for private host In-Reply-To: References: Message-ID: <1499437581.20130109225007@sadok.spb.ru> Здравствуйте, Eugene. Вы писали 9 января 2013 г., 22:24:44: > Добрый вечер, > Допустим на сервере есть два внешних интерфейса A и B и еще один > внутренний C. Nginx слушает везде. На внутреннем сидит домен, > проксирующий запросы наружу. Через > какой из внешних интерфейсов они пойдут? Добрый. man route -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From andrey at kopeyko.ru Wed Jan 9 19:35:45 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Wed, 09 Jan 2013 23:35:45 +0400 Subject: source IP for private host In-Reply-To: References: Message-ID: <50EDC691.4080502@kopeyko.ru> 09.01.2013 22:24, Eugene Toropov пишет: > Добрый вечер, Добрый вечер, Евгений! > Допустим на сервере есть два внешних интерфейса A и B и еще один > внутренний C. Nginx слушает везде. На внутреннем сидит домен, > проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? В обшем случае - пойдут так, как указано в таблице маршрутизации вашего сервера. Если вас это не устраивает - можете подправить директивой proxy_bind http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind -- Best regards, Andrey Kopeyko From andrey at kopeyko.ru Wed Jan 9 19:43:35 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Wed, 09 Jan 2013 23:43:35 +0400 Subject: =?UTF-8?B?UmU6INCh0LLRj9C30LrQsCBOZ2lueCArIElCTSBIVFRQU2VydmVyICtXZWJTcGhl?= =?UTF-8?B?cmUgUG9ydGFsLiDQn9GA0LDQstC40LvRjNC90LDRjyDQvtCx0YDQsNCx0L4=?= =?UTF-8?B?0YLQutCwINC+0YjQuNCx0LrQuCDQv9GA0Lgg0LfQsNCz0YDRg9C30LrQtSA=?= =?UTF-8?B?0YTQsNC50LvQsCDRgSDQvtCz0YDQsNC90LjRh9C10L3QuNGP0LzQuCDQv9C+?= =?UTF-8?B?INGA0LDQt9C80LXRgNGDLg==?= In-Reply-To: References: Message-ID: <50EDC867.7050703@kopeyko.ru> 09.01.2013 21:24, rashik пишет: > Добрый вечер, rashik! > Проблема: > Нужно уметь ограничивать размер загружаемого файла(например лимит в 10m). > Имеется возможность установить лимит на стороне портала, но в таком случае > файл загружается в темповую директорию nginx целиком и только потом отдается > приложению и в этот момент приложение ругается на его размер, а размер файла > может быть большим(например 1G). Такой вариант не подходит пользователь > ничего не подозревая ждет загрузки файла и только после загрузки целиком > узнает о лимите. "Почему невозможно корректно ограничить размер закачиваемого файла" http://sysoev.ru/web/upload.html > В случае установки лимита в конфигах nginx получаем ошибку 413, что не очень > подходит для данной задачи. Хотелось бы "прокинуть" ошибку до апплета. Прокинуть до апплета - наверное, таки возможно: определив в nginx.conf обработчик ошибки-413, и проксируя этот локейшен на бэкенд. А там уже разбираться. -- Best regards, Andrey Kopeyko From chipitsine at gmail.com Thu Jan 10 01:53:59 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 10 Jan 2013 06:53:59 +0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/QviDQutGD0LrQsNC8INC00Ls=?= =?UTF-8?B?0Y8g0LPQvtGB0YLQtdC5INGE0L7RgNGD0LzQsCDQvdCwIElQQiAoSW52aXNp?= =?UTF-8?B?b24gUG93ZXIgQm9hcmQp?= In-Reply-To: References: Message-ID: посмотрите в сторону APC (http://pecl.php.net/package/APC). за счет кеширования статики вы много не выиграете (если вообще что-то выиграете), а эффективность от php-кешей в подобных случаях обычно лучше, чем лепить костыли на nginx-е. 9 января 2013 г., 13:15 пользователь daitepiva написал: > Приветствую. > Пытался сделать кеширование по наличию-отсутствию некоторых типичных кук > (member_id pass_hash session_id) для гостей форума на IPB 2.3 (Invision > Power Board). Вроде всё работало как надо - кешировалось только гостям, > файлы в папке кеша появлялись и удалялись как надо. Но появились серьёзные > проблемы - чужие страницы, сессии, хотя кеширование было настроено именно > по > отсутствию всех ключевых куков - идентификатор пользователя, хеш пароля, > идентификатор сессии. На всякий случай включил эти куки в ключ объекта, но > там было пусто или нули, т.е. при наличии хотя бы одного из них ответ не > кешировался. > Включал эти переменные в логи - есть. Включал в логи переменную > upstream_cache_status, ничего аномального не заметил. > > Толи какие-то особенности работы движка, толи я что-то накосячил в конфиге. > Вот конфиг в части, касающейся кеширования: > http { > ... > proxy_cache_path /var/nginx/proxy_temp levels= keys_zone=dguests:100m > inactive=3m max_size=100m; > server { > ... > proxy_cache_key > "$host$request_uri|$request_method|$cookie_member_id|$cookie_pass_hash"; > proxy_cache_bypass $cookie_pass_hash $cookie_member_id > $cookie_session_id; > proxy_no_cache $cookie_pass_hash $cookie_member_id $cookie_session_id; > proxy_ignore_headers Expires Cache-Control Set-Cookie; > proxy_cache off; > location ~ \.php$ { > proxy_pass http://127.0.0.1:8080; > proxy_set_header X-Real-IP $remote_addr; > proxy_cache dguests; > proxy_cache_valid 30s; > } > } > } > > Пришлось включить Set-Cookie в proxy_ignore_headers, т.к. движок выдаёт её > гостям и страницы не кешировались вовсе. > Пробовал добавлять "proxy_hide_header "Set-Cookie";", но тогда не проходит > авторизация. > > Вообще же задача в снижении нагрузки и, в идеале, повышение устройчивости к > ДДоС-атакам, за счёт кеширования страниц для гостей, а их у меня больше чем > пользователей, например, прямо сейчас онлайн 2700 гостей и 1600 > пользователей. > > Спасибо. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,234824,234824#msg-234824 > > _______________________________________________ > 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 chipitsine at gmail.com Thu Jan 10 01:57:45 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 10 Jan 2013 06:57:45 +0500 Subject: =?UTF-8?B?UmU6IE5naW54INC90LUg0YXQvtGH0LXRgiDRgNCw0LHQvtGC0LDRgtGMINGH0LU=?= =?UTF-8?B?0YDQtdC3IHVuaXggc29ja2V0INGBIHBocC1mcG0=?= In-Reply-To: <9b15c6c11c29f91d28dc3bb6af8fd594.NginxMailingListRussian@forum.nginx.org> References: <4c11341f05f0dc9b4d72bfb63c4425e6.NginxMailingListRussian@forum.nginx.org> <9b15c6c11c29f91d28dc3bb6af8fd594.NginxMailingListRussian@forum.nginx.org> Message-ID: strace ради любопытства покажите ? 7 января 2013 г., 18:28 пользователь Voenniy написал: > Здравствуйте! > Такая же проблема. Вам удалось как-то её победить? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,117453,234770#msg-234770 > > _______________________________________________ > 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 hell-for-yahoo at umail.ru Thu Jan 10 02:40:33 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Thu, 10 Jan 2013 06:40:33 +0400 Subject: nginx reload In-Reply-To: <00e101cdee99$593dc600$0bb95200$@gmail.com> References: <20130109171644.GE80623@mdounin.ru> <00e101cdee99$593dc600$0bb95200$@gmail.com> Message-ID: <1688815467.20130110064033@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Александр Самарин! АС> Максим, спасибо за скорый ответ! АС> Reload действительно делался дважды, но в промежутке в несколько часов >> Если есть основания полагать, что наблюдаемое увеличение нагрузки - не >> объясняется вышеприведёнными причинами, то желательно их привести в явной >> форме АС> Пока ничего толком сказать не могу. Написал в рассылку в надежде, что кто-то АС> подтолкнет к способу выявления проблемы. Ради експеримента сделал релоад - 1 АС> час спустя количество процессов в стостоянии " shutting down" не уменьшилось >>Вообще reload - это операция, которая ожидаемо увеличивает нагрузку АС> Ожидаемо увеличиваемая нагрузка - это да, но не на 300%+ А это сильно зависит от характера контента... Тем более, после двух перезагрузок... >> Подробно про reload можно почитать тут: >> http://nginx.org/ru/docs/control.html#reconfiguration -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) четверг, 10.01.2013, <06:39> From pavel2000 at ngs.ru Thu Jan 10 04:47:36 2013 From: pavel2000 at ngs.ru (Pavel V.) Date: Thu, 10 Jan 2013 11:47:36 +0700 Subject: source IP for private host In-Reply-To: <50EDC691.4080502@kopeyko.ru> References: <50EDC691.4080502@kopeyko.ru> Message-ID: <944692986.20130110114736@ngs.ru> Здравствуйте. >> Допустим на сервере есть два внешних интерфейса A и B и еще один >> внутренний C. Nginx слушает везде. На внутреннем сидит домен, >> проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? > В обшем случае - пойдут так, как указано в таблице маршрутизации вашего > сервера. > Если вас это не устраивает - можете подправить директивой proxy_bind > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind Одной только директивы proxy_bind обычно недостаточно - работать всё будет по таблице маршрутизации. Если на хосте есть два внешних интерфейса, то обычно начинается тема "линукс и два провайдера" с использованием команды ip (в линуксе) (ip rule show, ip route show table main, ip ro sh table default и т д) и т п. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From nginx-forum at nginx.us Thu Jan 10 05:37:16 2013 From: nginx-forum at nginx.us (daitepiva) Date: Thu, 10 Jan 2013 00:37:16 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/QviDQutGD0LrQsNC8INC00Ls=?= =?UTF-8?B?0Y8g0LPQvtGB0YLQtdC5INGE0L7RgNGD0LzQsCDQvdCwIElQQiAoSW52aXNp?= =?UTF-8?B?b24gUG93ZXIgQm9hcmQp?= In-Reply-To: References: Message-ID: Илья Шипицин Wrote: ------------------------------------------------------- > посмотрите в сторону APC (http://pecl.php.net/package/APC). за счет > кеширования статики вы много не выиграете (если вообще что-то > выиграете), а > эффективность от php-кешей в подобных случаях обычно лучше, чем лепить > костыли на nginx-е. > Статика (картинки) выдаются nginx-ом напрямую, не с бэк-енда. APC стоит, его поддержка в движке включена. Хитов 100%. Но он кеширует не то, что мне нужно в данном случае. Мне нужно кеширование динамического контента, чтобы разгрузить бэк-енд. Иногда случаются выплески количества гостей (в том числе и ДДоС-атаки) и это приводит к большому количеству запросов в БД и отказу от обслуживания. Логично было бы отделить гостей от пользователей и выдать им закешированную страницу, что намного облегчит жизнь бэк-енда и БД в случае наплыва гостей. Меня больше интересует правильность моей настройки кеширования с точки зрения nginx-а, если всё правильно, то значит есть какие-то непонятые мной тонкости в работе движка, ну или протокола http. Размышляю я просто - если в запросе клиента нет (или равны нулю) куки, которые отличают пользователя от гостя, то ответ от бэк-енда закешировать (на 1 минуту) и выдавать его из кеша всем другим гостям. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234824,234871#msg-234871 From vadim.lazovskiy at gmail.com Thu Jan 10 06:01:36 2013 From: vadim.lazovskiy at gmail.com (=?KOI8-R?B?98HEyc0g7MHaz9fTy8nK?=) Date: Thu, 10 Jan 2013 10:01:36 +0400 Subject: nginx reload In-Reply-To: References: Message-ID: Здравствуйте. Судя по вашему графику и top-у - сервер не справляется. У вас средний idle по всем ядрам 2.4%. Строго говоря load average не зависит от количества процессов, если эти процессы спят. У вас изначально запущено 8 воркеров, которые не могут создать la > 8, но при этом занимают все ресурсы процессора и голодают. Запуская новые воркеры и распределяя на них новые соединения вы заставляете претендовать на ресурсы большее количество процессов. Соответственно растет и la. Если у сервера имеется запас производительности, даже 10 релодов не вызовут сколь-либо заметного повышения load average ведь, фактически, нагрузка (соединения, трафик) не изменятся. Добавятся только расходы на переключение контекстов процессов. 9 января 2013 г., 20:31 пользователь Александр Самарин < samarinaleksandr at gmail.com> написал: > Добрый день! Подскажите, в чем может быть проблема. Есть сервер на centos > 6.3. Установлен nginx version: nginx/1.2.5. > > Проблема появляется после <>. Сразу после релоада, > начинает расти нагрузка на сервер.Коннекты не обрываются > > > > До релоада > > 55.0 74180 - nginx: worker process > > 53.5 74712 - nginx: worker process > > 54.4 75500 - nginx: worker process > > 53.9 74312 - nginx: worker process > > 54.3 74972 - nginx: worker process > > 54.3 74180 - nginx: worker process > > 53.4 74048 - nginx: worker process > > 53.8 75104 ep_pol nginx: worker process > > > > после > > 55.3 74576 - nginx: worker process is shutting down > > 54.7 75504 - nginx: worker process is shutting down > > 55.1 75500 - nginx: worker process is shutting down > > 55.1 74840 - nginx: worker process is shutting down > > 55.4 75632 - nginx: worker process is shutting down > > 55.2 74708 - nginx: worker process is shutting down > > 54.9 74576 - nginx: worker process is shutting down > > 55.2 75896 - nginx: worker process is shutting down > > 17.9 57524 - nginx: worker process is shutting down > > 19.6 57524 ep_pol nginx: worker process is shutting down > > 20.0 57524 ep_pol nginx: worker process is shutting down > > 17.6 57524 - nginx: worker process is shutting down > > 18.7 57524 - nginx: worker process is shutting down > > 14.6 57524 ep_pol nginx: worker process is shutting down > > 18.1 57524 - nginx: worker process is shutting down > > 19.0 57524 - nginx: worker process is shutting down > > 18.2 58200 - nginx: worker process > > 17.5 58332 ep_pol nginx: worker process > > 17.0 58332 - nginx: worker process > > 17.6 58464 - nginx: worker process > > 18.9 58332 - nginx: worker process > > 18.8 58332 - nginx: worker process > > 17.4 58728 - nginx: worker process > > 17.7 58200 - nginx: worker process > > > И нагрузка продолжает расти > > top, сразу после релоада > > 1 user, load average: 40.41, 14.03, 11.82 > > Tasks: 192 total, 17 running, 175 sleeping, 0 stopped, 0 zombie > > Cpu(s): 38.9%us, 30.7%sy, 0.0%ni, 2.4%id, 0.0%wa, 0.0%hi, 27.9%si, > 0.0%st > > Mem: 1922060k total, 1327168k used, 594892k free, 112960k buffers > > Swap: 2097144k total, 0k used, 2097144k free, 327068k cached > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 3962 nginx 20 0 75500 31m 896 R 33.8 1.7 185:16.38 nginx > > 3963 nginx 20 0 74840 31m 896 R 33.5 1.7 185:13.82 nginx > > 3964 nginx 20 0 75632 31m 896 S 33.5 1.7 186:09.56 nginx > > 3960 nginx 20 0 74576 30m 896 R 32.8 1.6 185:41.08 nginx > > 3966 nginx 20 0 74708 30m 896 R 32.8 1.6 185:36.28 nginx > > 3961 nginx 20 0 75504 31m 896 R 32.5 1.7 183:44.90 nginx > > 3968 nginx 20 0 75896 32m 896 R 32.5 1.7 185:20.11 nginx > > 3967 nginx 20 0 74576 30m 896 S 31.2 1.6 184:28.75 nginx > > 5173 nginx 20 0 60576 17m 880 R 26.6 0.9 2:52.41 nginx > > 5174 nginx 20 0 60972 17m 880 R 24.9 0.9 2:48.93 nginx > > 5172 nginx 20 0 60712 17m 880 R 24.6 0.9 2:55.61 nginx > > > > Active connections ~ 10 тысяч > > [image: Встроенное изображение 2] > > > > С уважением, > > Александр Самарин! > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey at kopeyko.ru Thu Jan 10 07:48:51 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Thu, 10 Jan 2013 11:48:51 +0400 Subject: source IP for private host In-Reply-To: <944692986.20130110114736@ngs.ru> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> Message-ID: <50EE7263.6000407@kopeyko.ru> 10.01.2013 08:47, Pavel V. пишет: > Здравствуйте. > >>> Допустим на сервере есть два внешних интерфейса A и B и еще один >>> внутренний C. Nginx слушает везде. На внутреннем сидит домен, >>> проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? > >> В обшем случае - пойдут так, как указано в таблице маршрутизации вашего >> сервера. > >> Если вас это не устраивает - можете подправить директивой proxy_bind >> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind > > Одной только директивы proxy_bind обычно недостаточно - работать всё будет по таблице > маршрутизации. > > Если на хосте есть два внешних интерфейса, то обычно начинается тема "линукс и два провайдера" с > использованием команды ip (в линуксе) (ip rule show, ip route show table main, ip ro sh table > default и т д) и т п. Да, Вы правы : если внешние интерфейсы от разных провайдеров, или хотя бы из разных сетей - разруливать надо policy-routing'ом. Я, видимо, недостаточно внимательно прочитал письмо, и вообразил более привычную для colocation ситуацию - когда 2 внешних интерфейса из одной подсети -, и предложил решение для неё. -- Best regards, Andrey Kopeyko From kav at karagodov.name Thu Jan 10 08:01:22 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 10 Jan 2013 12:01:22 +0400 Subject: source IP for private host In-Reply-To: <50EE7263.6000407@kopeyko.ru> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> Message-ID: <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> в аттаче решение для пингвинов есть ещё для бзди, если интересно для венды - не ведаю, возможно-ли для мака и солярки тоже не в курсе в случае с пингвинёй надо изменить исходящий интерфейс (кажется это смахивает на PBR, не уверен :) ) в случае с бздунами надо создавать правило (речь идёт исключительно о PF) следуя которому ответы уйдут через тот-же интерфейс, через который пришли запросы (собственно stateful firewall) или, ответы уйдут тем же путём, каким пришли запросы на juniper это работает "искаропки" (можно выключить), на цисках нужно городить PBR (тупая и мерзкая штука) всё это описано на разных языках в разных позах, поиск таки даёт результаты On 10.01.2013, at 11:48, Andrey Kopeyko wrote: > 10.01.2013 08:47, Pavel V. пишет: >> Здравствуйте. >> >>>> Допустим на сервере есть два внешних интерфейса A и B и еще один >>>> внутренний C. Nginx слушает везде. На внутреннем сидит домен, >>>> проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? >> >>> В обшем случае - пойдут так, как указано в таблице маршрутизации вашего >>> сервера. >> >>> Если вас это не устраивает - можете подправить директивой proxy_bind >>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind >> >> Одной только директивы proxy_bind обычно недостаточно - работать всё будет по таблице >> маршрутизации. >> >> Если на хосте есть два внешних интерфейса, то обычно начинается тема "линукс и два провайдера" с >> использованием команды ip (в линуксе) (ip rule show, ip route show table main, ip ro sh table >> default и т д) и т п. > > Да, Вы правы : если внешние интерфейсы от разных провайдеров, или хотя бы из разных сетей - разруливать надо policy-routing'ом. > > Я, видимо, недостаточно внимательно прочитал письмо, и вообразил более привычную для colocation ситуацию - когда 2 внешних интерфейса из одной подсети -, и предложил решение для неё. > > > -- > Best regards, > Andrey Kopeyko > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- A non-text attachment was scrubbed... Name: untitled text 72 Type: application/octet-stream Size: 2389 bytes Desc: not available URL: From andrew at nginx.com Thu Jan 10 08:03:12 2013 From: andrew at nginx.com (Andrew Alexeev) Date: Thu, 10 Jan 2013 12:03:12 +0400 Subject: source IP for private host In-Reply-To: <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> Message-ID: <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> On Jan 10, 2013, at 12:01 PM, Alexey V. Karagodov wrote: > в аттаче решение для пингвинов > есть ещё для бзди, если интересно > для венды - не ведаю, возможно-ли > для мака и солярки тоже не в курсе > > в случае с пингвинёй надо изменить исходящий интерфейс (кажется это смахивает на PBR, не уверен :) ) > в случае с бздунами надо создавать правило (речь идёт исключительно о PF) следуя которому ответы уйдут через тот-же интерфейс, через который пришли запросы (собственно stateful firewall) > или, ответы уйдут тем же путём, каким пришли запросы Еще можно посмотреть на setfib http://nginx.org/en/docs/http/ngx_http_core_module.html#listen > на juniper это работает "искаропки" (можно выключить), на цисках нужно городить PBR (тупая и мерзкая штука) > > всё это описано на разных языках в разных позах, поиск таки даёт результаты > > > On 10.01.2013, at 11:48, Andrey Kopeyko wrote: > >> 10.01.2013 08:47, Pavel V. пишет: >>> Здравствуйте. >>> >>>>> Допустим на сервере есть два внешних интерфейса A и B и еще один >>>>> внутренний C. Nginx слушает везде. На внутреннем сидит домен, >>>>> проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? >>> >>>> В обшем случае - пойдут так, как указано в таблице маршрутизации вашего >>>> сервера. >>> >>>> Если вас это не устраивает - можете подправить директивой proxy_bind >>>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind >>> >>> Одной только директивы proxy_bind обычно недостаточно - работать всё будет по таблице >>> маршрутизации. >>> >>> Если на хосте есть два внешних интерфейса, то обычно начинается тема "линукс и два провайдера" с >>> использованием команды ip (в линуксе) (ip rule show, ip route show table main, ip ro sh table >>> default и т д) и т п. >> >> Да, Вы правы : если внешние интерфейсы от разных провайдеров, или хотя бы из разных сетей - разруливать надо policy-routing'ом. >> >> Я, видимо, недостаточно внимательно прочитал письмо, и вообразил более привычную для colocation ситуацию - когда 2 внешних интерфейса из одной подсети -, и предложил решение для неё. >> >> >> -- >> Best regards, >> Andrey Kopeyko >> >> _______________________________________________ >> 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 eugene.toropov at gmail.com Thu Jan 10 08:09:45 2013 From: eugene.toropov at gmail.com (Eugene Toropov) Date: Thu, 10 Jan 2013 12:09:45 +0400 Subject: source IP for private host In-Reply-To: <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> Message-ID: <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> Доброе утро, У меня просто забилась 100 мегабитная карта, поэтому ставлю вторую, подсетка и провайдер те же, так что proxy_bind выглядит правильным решением. Всем спасибо. Евгений On Jan 10, 2013, at 12:03 PM, Andrew Alexeev wrote: > On Jan 10, 2013, at 12:01 PM, Alexey V. Karagodov wrote: > >> в аттаче решение для пингвинов >> есть ещё для бзди, если интересно >> для венды - не ведаю, возможно-ли >> для мака и солярки тоже не в курсе >> >> в случае с пингвинёй надо изменить исходящий интерфейс (кажется это смахивает на PBR, не уверен :) ) >> в случае с бздунами надо создавать правило (речь идёт исключительно о PF) следуя которому ответы уйдут через тот-же интерфейс, через который пришли запросы (собственно stateful firewall) >> или, ответы уйдут тем же путём, каким пришли запросы > > Еще можно посмотреть на setfib > http://nginx.org/en/docs/http/ngx_http_core_module.html#listen > >> на juniper это работает "искаропки" (можно выключить), на цисках нужно городить PBR (тупая и мерзкая штука) >> >> всё это описано на разных языках в разных позах, поиск таки даёт результаты >> >> >> On 10.01.2013, at 11:48, Andrey Kopeyko wrote: >> >>> 10.01.2013 08:47, Pavel V. пишет: >>>> Здравствуйте. >>>> >>>>>> Допустим на сервере есть два внешних интерфейса A и B и еще один >>>>>> внутренний C. Nginx слушает везде. На внутреннем сидит домен, >>>>>> проксирующий запросы наружу. Через какой из внешних интерфейсов они пойдут? >>>> >>>>> В обшем случае - пойдут так, как указано в таблице маршрутизации вашего >>>>> сервера. >>>> >>>>> Если вас это не устраивает - можете подправить директивой proxy_bind >>>>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind >>>> >>>> Одной только директивы proxy_bind обычно недостаточно - работать всё будет по таблице >>>> маршрутизации. >>>> >>>> Если на хосте есть два внешних интерфейса, то обычно начинается тема "линукс и два провайдера" с >>>> использованием команды ip (в линуксе) (ip rule show, ip route show table main, ip ro sh table >>>> default и т д) и т п. >>> >>> Да, Вы правы : если внешние интерфейсы от разных провайдеров, или хотя бы из разных сетей - разруливать надо policy-routing'ом. >>> >>> Я, видимо, недостаточно внимательно прочитал письмо, и вообразил более привычную для colocation ситуацию - когда 2 внешних интерфейса из одной подсети -, и предложил решение для неё. >>> >>> >>> -- >>> Best regards, >>> Andrey Kopeyko >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From samarinaleksandr at gmail.com Thu Jan 10 08:15:58 2013 From: samarinaleksandr at gmail.com (=?koi8-r?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Thu, 10 Jan 2013 10:15:58 +0200 Subject: source IP for private host In-Reply-To: <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> Message-ID: <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> >У меня просто забилась 100 мегабитная карта В таком случае правильным решением будет объединение двух сетевых интерфейсов(bonding) С уважением, Александр Самарин! -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Eugene Toropov Sent: Thursday, January 10, 2013 10:10 AM To: nginx-ru at nginx.org Subject: Re: source IP for private host Доброе утро, У меня просто забилась 100 мегабитная карта, поэтому ставлю вторую, подсетка и провайдер те же, так что proxy_bind выглядит правильным решением. Всем спасибо. Евгений From kav at karagodov.name Thu Jan 10 08:19:22 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 10 Jan 2013 12:19:22 +0400 Subject: source IP for private host In-Reply-To: <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> Message-ID: работает хреново, т.е. нет там нормального распределения нагрузки (по факту) нужно что то вроде etherchannel (циска), с этим etherchannel дружит vmware правильнее карточку гигабитную поставить On 10.01.2013, at 12:15, Александр Самарин wrote: >> У меня просто забилась 100 мегабитная карта > В таком случае правильным решением будет объединение двух сетевых > интерфейсов(bonding) > > С уважением, > Александр Самарин! > > -----Original Message----- > From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On > Behalf Of Eugene Toropov > Sent: Thursday, January 10, 2013 10:10 AM > To: nginx-ru at nginx.org > Subject: Re: source IP for private host > > Доброе утро, > > У меня просто забилась 100 мегабитная карта, поэтому ставлю вторую, подсетка > и провайдер те же, так что proxy_bind выглядит правильным решением. > > Всем спасибо. > > Евгений > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From samarinaleksandr at gmail.com Thu Jan 10 08:25:26 2013 From: samarinaleksandr at gmail.com (=?koi8-r?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Thu, 10 Jan 2013 10:25:26 +0200 Subject: source IP for private host In-Reply-To: References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> Message-ID: <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> > работает хреново, т.е. нет там нормального распределения нагрузки (по факту) IEEE 802.3ad показывал себя в свое время с хорошей стороны, пока не была поставлена 10gb карта >правильнее карточку гигабитную поставить Тут полностью согласен -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Alexey V. Karagodov Sent: Thursday, January 10, 2013 10:19 AM To: nginx-ru at nginx.org Subject: Re: source IP for private host работает хреново, т.е. нет там нормального распределения нагрузки (по факту) нужно что то вроде etherchannel (циска), с этим etherchannel дружит vmware правильнее карточку гигабитную поставить On 10.01.2013, at 12:15, Александр Самарин wrote: >> У меня просто забилась 100 мегабитная карта > В таком случае правильным решением будет объединение двух сетевых > интерфейсов(bonding) > > С уважением, > Александр Самарин! > > -----Original Message----- > From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On > Behalf Of Eugene Toropov > Sent: Thursday, January 10, 2013 10:10 AM > To: nginx-ru at nginx.org > Subject: Re: source IP for private host > > Доброе утро, > > У меня просто забилась 100 мегабитная карта, поэтому ставлю вторую, подсетка > и провайдер те же, так что proxy_bind выглядит правильным решением. > > Всем спасибо. > > Евгений > > _______________________________________________ > 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 eugene.toropov at gmail.com Thu Jan 10 08:32:11 2013 From: eugene.toropov at gmail.com (Eugene Toropov) Date: Thu, 10 Jan 2013 12:32:11 +0400 Subject: source IP for private host In-Reply-To: <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> Message-ID: Карточку можно поменять в горячем режиме? On Jan 10, 2013, at 12:25 PM, Александр Самарин wrote: >> работает хреново, т.е. нет там нормального распределения нагрузки (по > факту) > IEEE 802.3ad показывал себя в свое время с хорошей стороны, пока не была > поставлена 10gb карта >> правильнее карточку гигабитную поставить > Тут полностью согласен > > -----Original Message----- > From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On > Behalf Of Alexey V. Karagodov > Sent: Thursday, January 10, 2013 10:19 AM > To: nginx-ru at nginx.org > Subject: Re: source IP for private host > > работает хреново, т.е. нет там нормального распределения нагрузки (по факту) > > > нужно что то вроде etherchannel (циска), с этим etherchannel дружит vmware > правильнее карточку гигабитную поставить > > > On 10.01.2013, at 12:15, Александр Самарин > wrote: > >>> У меня просто забилась 100 мегабитная карта >> В таком случае правильным решением будет объединение двух сетевых >> интерфейсов(bonding) >> >> С уважением, >> Александр Самарин! >> >> -----Original Message----- >> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On >> Behalf Of Eugene Toropov >> Sent: Thursday, January 10, 2013 10:10 AM >> To: nginx-ru at nginx.org >> Subject: Re: source IP for private host >> >> Доброе утро, >> >> У меня просто забилась 100 мегабитная карта, поэтому ставлю вторую, > подсетка >> и провайдер те же, так что proxy_bind выглядит правильным решением. >> >> Всем спасибо. >> >> Евгений >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From kav at karagodov.name Thu Jan 10 08:35:39 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 10 Jan 2013 12:35:39 +0400 Subject: source IP for private host In-Reply-To: References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> Message-ID: On 10.01.2013, at 12:32, Eugene Toropov wrote: > Карточку можно поменять в горячем режиме? а вторую поставить? если там всё такое "горячее", уже делайте нормально, ферма серверов (ну хотя бы парочка серверов), хранилище и т.д. > > On Jan 10, 2013, at 12:25 PM, Александр Самарин wrote: > >>> работает хреново, т.е. нет там нормального распределения нагрузки (по >> факту) >> IEEE 802.3ad показывал себя в свое время с хорошей стороны, пока не была >> поставлена 10gb карта >>> правильнее карточку гигабитную поставить >> Тут полностью согласен >> >> -----Original Message----- >> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On >> Behalf Of Alexey V. Karagodov >> Sent: Thursday, January 10, 2013 10:19 AM >> To: nginx-ru at nginx.org >> Subject: Re: source IP for private host >> >> работает хреново, т.е. нет там нормального распределения нагрузки (по факту) >> >> >> нужно что то вроде etherchannel (циска), с этим etherchannel дружит vmware >> правильнее карточку гигабитную поставить >> >> >> On 10.01.2013, at 12:15, Александр Самарин >> wrote: >> >>>> У меня просто забилась 100 мегабитная карта >>> В таком случае правильным решением будет объединение двух сетевых >>> интерфейсов(bonding) >>> >>> С уважением, >>> Александр Самарин! >>> >>> -----Original Message----- >>> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On >>> Behalf Of Eugene Toropov >>> Sent: Thursday, January 10, 2013 10:10 AM >>> To: nginx-ru at nginx.org >>> Subject: Re: source IP for private host >>> >>> Доброе утро, >>> >>> У меня просто забилась 100 мегабитная карта, поэтому ставлю вторую, >> подсетка >>> и провайдер те же, так что proxy_bind выглядит правильным решением. >>> >>> Всем спасибо. >>> >>> Евгений >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From eugene.toropov at gmail.com Thu Jan 10 08:45:54 2013 From: eugene.toropov at gmail.com (Eugene Toropov) Date: Thu, 10 Jan 2013 12:45:54 +0400 Subject: source IP for private host In-Reply-To: References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> Message-ID: <6B7647E7-7552-49E5-AD29-863DBB01F373@gmail.com> Хорошо, спасибо On Jan 10, 2013, at 12:35 PM, Alexey V. Karagodov wrote: > > On 10.01.2013, at 12:32, Eugene Toropov wrote: > >> Карточку можно поменять в горячем режиме? > а вторую поставить? > > если там всё такое "горячее", уже делайте нормально, ферма серверов (ну хотя бы парочка серверов), хранилище и т.д. > >> >> On Jan 10, 2013, at 12:25 PM, Александр Самарин wrote: >> >>>> работает хреново, т.е. нет там нормального распределения нагрузки (по >>> факту) >>> IEEE 802.3ad показывал себя в свое время с хорошей стороны, пока не была >>> поставлена 10gb карта >>>> правильнее карточку гигабитную поставить >>> Тут полностью согласен >>> >>> -----Original Message----- >>> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On >>> Behalf Of Alexey V. Karagodov >>> Sent: Thursday, January 10, 2013 10:19 AM >>> To: nginx-ru at nginx.org >>> Subject: Re: source IP for private host >>> >>> работает хреново, т.е. нет там нормального распределения нагрузки (по факту) >>> >>> >>> нужно что то вроде etherchannel (циска), с этим etherchannel дружит vmware >>> правильнее карточку гигабитную поставить >>> >>> >>> On 10.01.2013, at 12:15, Александр Самарин >>> wrote: >>> >>>>> У меня просто забилась 100 мегабитная карта >>>> В таком случае правильным решением будет объединение двух сетевых >>>> интерфейсов(bonding) >>>> >>>> С уважением, >>>> Александр Самарин! >>>> >>>> -----Original Message----- >>>> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On >>>> Behalf Of Eugene Toropov >>>> Sent: Thursday, January 10, 2013 10:10 AM >>>> To: nginx-ru at nginx.org >>>> Subject: Re: source IP for private host >>>> >>>> Доброе утро, >>>> >>>> У меня просто забилась 100 мегабитная карта, поэтому ставлю вторую, >>> подсетка >>>> и провайдер те же, так что proxy_bind выглядит правильным решением. >>>> >>>> Всем спасибо. >>>> >>>> Евгений >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru at nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> 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 samarinaleksandr at gmail.com Thu Jan 10 08:46:18 2013 From: samarinaleksandr at gmail.com (=?koi8-r?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Thu, 10 Jan 2013 10:46:18 +0200 Subject: source IP for private host In-Reply-To: References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> Message-ID: <01cf01cdef0e$f59cb180$e0d61480$@gmail.com> В спецификации PCI Express есть описание горячей замены/подключения. Но лучше(на мой взгляд) временно объединить сетевые и запланировать время смены оборудования -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Alexey V. Karagodov Sent: Thursday, January 10, 2013 10:36 AM To: nginx-ru at nginx.org Subject: Re: source IP for private host On 10.01.2013, at 12:32, Eugene Toropov wrote: > Карточку можно поменять в горячем режиме? а вторую поставить? если там всё такое "горячее", уже делайте нормально, ферма серверов (ну хотя бы парочка серверов), хранилище и т.д. From kav at karagodov.name Thu Jan 10 08:47:34 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 10 Jan 2013 12:47:34 +0400 Subject: source IP for private host In-Reply-To: <01cf01cdef0e$f59cb180$e0d61480$@gmail.com> References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> <01cf01cdef0e$f59cb180$e0d61480$@gmail.com> Message-ID: на своём сервере пробовали? :) On 10.01.2013, at 12:46, Александр Самарин wrote: > В спецификации PCI Express есть описание горячей замены/подключения. > Но лучше(на мой взгляд) временно объединить сетевые и запланировать время > смены оборудования > > -----Original Message----- > From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On > Behalf Of Alexey V. Karagodov > Sent: Thursday, January 10, 2013 10:36 AM > To: nginx-ru at nginx.org > Subject: Re: source IP for private host > > > On 10.01.2013, at 12:32, Eugene Toropov wrote: > >> Карточку можно поменять в горячем режиме? > а вторую поставить? > > если там всё такое "горячее", уже делайте нормально, ферма серверов (ну хотя > бы парочка серверов), хранилище и т.д. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From samarinaleksandr at gmail.com Thu Jan 10 09:45:26 2013 From: samarinaleksandr at gmail.com (=?koi8-r?B?4czFy9PBzsTSIPPBzcHSyc4=?=) Date: Thu, 10 Jan 2013 11:45:26 +0200 Subject: source IP for private host In-Reply-To: References: <50EDC691.4080502@kopeyko.ru> <944692986.20130110114736@ngs.ru> <50EE7263.6000407@kopeyko.ru> <145CD1F9-ABE6-42D0-BAC5-787BFD133B94@karagodov.name> <2C2EF569-3165-42F3-93B4-292300E92F04@nginx.com> <524FA99E-1764-4113-BB3A-02A923892B7E@gmail.com> <01cb01cdef0a$b8d990f0$2a8cb2d0$@gmail.com> <01cd01cdef0c$0b8a6e40$229f4ac0$@gmail.com> <01cf01cdef0e$f59cb180$e0d61480$@gmail.com> Message-ID: <01e601cdef17$38e68490$aab38db0$@gmail.com> Настолько "горячих" сервисов нет. Но я это и не советовал > Но лучше(на мой взгляд) временно объединить сетевые и запланировать > время смены оборудования -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Alexey V. Karagodov Sent: Thursday, January 10, 2013 10:48 AM To: nginx-ru at nginx.org Subject: Re: source IP for private host на своём сервере пробовали? :) From mdounin at mdounin.ru Thu Jan 10 13:37:18 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 10 Jan 2013 17:37:18 +0400 Subject: nginx-1.3.11 Message-ID: <20130110133718.GL80623@mdounin.ru> Изменения в nginx 1.3.11 10.01.2013 *) Исправление: при записи в лог мог происходить segmentation fault; ошибка появилась в 1.3.10. *) Исправление: директива proxy_pass не работала с IP-адресами без явного указания порта; ошибка появилась в 1.3.10. *) Исправление: на старте или во время переконфигурации происходил segmentation fault, если директива keepalive была указана несколько раз в одном блоке upstream. *) Исправление: параметр default директивы geo не определял значение по умолчанию для IPv6-адресов. -- Maxim Dounin http://nginx.com/support.html From alexandr at tverdikov.ru Fri Jan 11 02:52:49 2013 From: alexandr at tverdikov.ru (=?UTF-8?B?0KLQstC10YDQtNC40LrQvtCyINCQ0LvQtdC60YHQsNC90LTRgA==?=) Date: Fri, 11 Jan 2013 09:52:49 +0700 Subject: =?UTF-8?B?0LDQstGC0L7RgNC40LfQsNGG0LjRjyDQtNC70Y8gd2ViZGF2?= Message-ID: <50EF7E81.8020908@tverdikov.ru> Добрый день! Настроил webdav на nginx 1.2 Но вот как сделать доступ по паролю? -- ------------------------------ С уважением, Александр. Мои контакты: icq : 271715650 jabber: atverdikov at jabber.ru skype : ATverdikov ------------------------------ From arun.tewatia at raftaar.in Fri Jan 11 04:25:38 2013 From: arun.tewatia at raftaar.in (Arun Tewatia) Date: Fri, 11 Jan 2013 09:55:38 +0530 Subject: text/vnd.wap.wml error Message-ID: <50EF9442.8070102@raftaar.in> Hi all, I am using Nginx as reverse proxy in production with Windows based web servers ( IIS7 ) for my search engine website. I am frequently facing an issue that my html web pages start getting downloaded instead of opening in browser. I tried settings*more_set_headers* in Nginx but still the error isn't resolved. The page works fine if I bypass the Nginx proxy. The Nginx header works fine for explicit wml pages but still I receive "text/vnd.wap.wml" as content type for some of my html pages. I am using nginx/1.2.4 with following line added under http block. more_set_headers -t 'text/vnd.wap.wml' 'Content-Type: text/html'; What could be going wrong ? Am I missing something ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Jan 11 07:02:11 2013 From: nginx-forum at nginx.us (vadox) Date: Fri, 11 Jan 2013 02:02:11 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0YwgMzAxINGA0LXQtNC40YDQtdC6?= =?UTF-8?B?0YI=?= In-Reply-To: <29B5C13D-99F7-46F8-A947-7E7FE0C15E97@sysoev.ru> References: <29B5C13D-99F7-46F8-A947-7E7FE0C15E97@sysoev.ru> Message-ID: <42948cfcd986d6f3c82a8716c297942d.NginxMailingListRussian@forum.nginx.org> Спасибо! Вы мне очень помогли! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234404,234924#msg-234924 From kav at karagodov.name Fri Jan 11 07:12:20 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Fri, 11 Jan 2013 11:12:20 +0400 Subject: =?UTF-8?B?UmU6INCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0LTQu9GPIHdlYmRhdg==?= In-Reply-To: <50EF7E81.8020908@tverdikov.ru> References: <50EF7E81.8020908@tverdikov.ru> Message-ID: так же http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html On 11.01.2013, at 6:52, Твердиков Александр wrote: > Добрый день! > Настроил webdav на nginx 1.2 > Но вот как сделать доступ по паролю? > > -- > ------------------------------ > С уважением, Александр. > Мои контакты: > icq : 271715650 > jabber: atverdikov at jabber.ru > skype : ATverdikov > ------------------------------ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Jan 11 07:44:26 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 02:44:26 -0500 Subject: =?UTF-8?B?0LTQstCwINC/0YDQsNCy0LjQu9CwINGA0LDQsdC+0YLQsNGO0YIg0L/QviDQvtGC?= =?UTF-8?B?0LTQtdC70L3QvtGB0YLQuCDQvdC+INC90LUg0LLQvNC10YHRgtC1?= Message-ID: Здравствуйте коллеги, в кратце. nginx + apache 1. правило отрезает www из $host поскольау /var/www/www.site.ru естественно нет, а делать дополнительный линк глупо 2. при отсутствие /lalala.html фактичеки в папке перенаправляется на движок index.php все правила работают и стабильно НО Вместе когда www.site.ru/lalala.html они уже не отрабатывают ;( nginx отдает 404 Проверив весь конфиг на это влияет толко две строчки подскажите пожалуйста чего я не учитывю html|htm вынесены в отдельный локейшен посколкьу многие сеошники в свое время любили делать сайты на движках со статьями /lalala.html и теперь приходится это расхлебывать. location ~* ^.+\.(htm|html)$ { # данная директива при отсутствие файла try_files $uri /index.php; # пусть до файлов по умолчанию root /var/www/$host/web; # если в $host содержится ввв то он его удаляет в противном случае пусть будет /var/www/www.site.ru if ($host ~* ^(www\.)(.+)) { set $HBW $2; root /var/www/$HBW/web; } access_log off; expires 30d; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234927#msg-234927 From kav at karagodov.name Fri Jan 11 07:55:16 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Fri, 11 Jan 2013 11:55:16 +0400 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <6CD16929-7283-48CF-9258-3C6C8CF04FC4@karagodov.name> On 11.01.2013, at 11:44, "shambler81" wrote: > Здравствуйте коллеги, в кратце. nginx + apache > 1. правило отрезает www из $host поскольау /var/www/www.site.ru естественно > нет, а делать дополнительный линк глупо > 2. при отсутствие /lalala.html фактичеки в папке перенаправляется на движок > index.php > все правила работают и стабильно > НО > Вместе > когда www.site.ru/lalala.html они уже не отрабатывают ;( nginx отдает 404 > Проверив весь конфиг на это влияет толко две строчки подскажите пожалуйста > чего я не учитывю > html|htm вынесены в отдельный локейшен посколкьу многие сеошники в свое > время любили делать сайты на движках со статьями /lalala.html > и теперь приходится это расхлебывать. > > > location ~* ^.+\.(htm|html)$ { > # данная директива при отсутствие файла > try_files $uri /index.php; > > > # пусть до файлов по умолчанию > root /var/www/$host/web; > # если в $host содержится ввв то он его удаляет в противном случае пусть > будет /var/www/www.site.ru > if ($host ~* ^(www\.)(.+)) { опять этот бред ? правильно это делать через server {} > set $HBW $2; > root /var/www/$HBW/web; > } > access_log off; > expires 30d; > } > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234927#msg-234927 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vovansystems at gmail.com Fri Jan 11 08:06:44 2013 From: vovansystems at gmail.com (VovansystemS) Date: Fri, 11 Jan 2013 11:06:44 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: Алексей имеет в виду, что надо сделать отдельный server для домена с www. Это правильный метод: server { server_name www.site.ru; return 301 $scheme://site.ru$request_uri$is_args$args; } server { server_name site.ru; location ~* ^.+\.(htm|html)$ { try_files $uri /index.php; } } Почитайте внимательно http://wiki.nginx.org/Pitfalls и http://wiki.nginx.org/IfIsEvil From nginx-forum at nginx.us Fri Jan 11 08:14:19 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 03:14:19 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: По части неправильности я понимаю, трудно перейти с apache на nginx старые замашки тянут за собой. Однако server у меня один поскольку веб панель прикрученая с серверу не позволяет работать с apache+nginx А следовательно все сайты ходят через default конфиг ;( server { listen 80 default; server_name _; server_name_in_redirect off; resolver 127.0.0.1; access_log /var/log/ispconfig/httpd/$host/access.log; location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|flv|mp3)$ { # пусть до файлов по умолчанию root /var/www/$host/web; # если в $host содержится ввв то он его удаляет в противном случае пусть будет /var/www/www.site.ru #----------------------------------- if ($host ~* ^(www\.)(.+)) { set $HBW $2; root /var/www/$HBW/web; } #----------------------------------- access_log off; expires 30d; } #------------------------------------ location ~* ^.+\.(htm|html)$ { # данная директива при отсутствие файла try_files $uri /index.php; # пусть до файлов по умолчанию root /var/www/$host/web; # если в $host содержится ввв то он его удаляет в противном случае пусть будет /var/www/www.site.ru if ($host ~* ^(www\.)(.+)) { set $HBW $2; root /var/www/$HBW/web; } ################################################### access_log off; expires 30d; } ##------------------------------------ location / { #if (!-e $request_filename){ # rewrite ^/(.+) /index.php/$1 break; # } ################################################### # пусть до файлов по умолчанию root /var/www/$host/web; # если в $host содержится ввв то он его удаляет if ($host ~* ^(www\.)(.+)) { set $HBW $2; root /var/www/$HBW/web; } ################################################### index index.html index.htm index.php; access_log off; proxy_pass http://$host:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } #################################################### # Настройки для phpmyadmin location /phpmyadmin { root /usr/share/; index index.php index.html index.htm; location ~ ^/phpmyadmin/(.+\.php)$ { try_files $uri =404; root /usr/share/; proxy_pass http://$host:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /usr/share/; } } location /phpMyAdmin { rewrite ^/* /phpmyadmin last; } #Конец phpmyadmin ##################################################### # Настройки для WEBMAIL location /webmail { root /var/www/; index index.php index.html index.htm; location ~ ^/webmail/(.+\.php)$ { try_files $uri =404; root /war/www/webmail; proxy_pass http://127.0.0.1:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host 127.0.0.1:82/webmail; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* ^/webmail/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /var/www/webmail/webmail; } } location /WebMail { rewrite ^/* $host:82/webmail last; } #Конец webmail ##################################################### #---------------AWSTATS location ^~ /awstats-icon { alias /usr/share/awstats/icon/; access_log off; } location ^~ /awstatscss { alias /usr/share/doc/awstats/examples/css/; access_log off; } location ^~ /awstatsclasses { alias /usr/share/doc/awstats/examples/classes/; access_log off; } #---------------AVSTATS-END } # Закрывает server !!! Так что правило должно работать так же для обсалютно всех доменов ;( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234931#msg-234931 From nginx-forum at nginx.us Fri Jan 11 08:17:23 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 03:17:23 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <3fbbb09df3807c8538d93f6eb6f00d70.NginxMailingListRussian@forum.nginx.org> VovansystemS в предложенном вами варианте насколко я понимаю в просто отрезаете www это не покатит! Сайт проиндексирвоанный с ним нельзя изменить он и должен быть всегда с ним иначе это совершенно другой сайт а следовательно раскрутка его заново. Требуется подменять только путь до root сам сайт должен оставаться c www или без него в зависимости оттого как его собрали изначально. А главное это правило работает как я повтарил для обсалютно всех сайтов посколькуо админка не умеет править сразу и апач и энджинкс конфиги. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234932#msg-234932 From vovansystems at gmail.com Fri Jan 11 08:39:36 2013 From: vovansystems at gmail.com (VovansystemS) Date: Fri, 11 Jan 2013 11:39:36 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: <3fbbb09df3807c8538d93f6eb6f00d70.NginxMailingListRussian@forum.nginx.org> References: <3fbbb09df3807c8538d93f6eb6f00d70.NginxMailingListRussian@forum.nginx.org> Message-ID: >VovansystemS в предложенном вами варианте насколко я понимаю в просто > отрезаете www это не покатит! >Сайт проиндексирвоанный с ним нельзя изменить он и должен быть всегда с ним я предлагаю делать перенаправление с www.site.ru/blabla.html на site.ru/blabla.html всегда. Для поисковой оптимизации важно на самом деле определиться с тем, будут ли все Ваши с www. или без оного и от этого создавать конфигурационные файлы. Кстати, тот же Яндекс позволяет легко подведить права на домен с www. и на домен без www. и "склеить" их как один сайт, указав ему какой вариант имени является глявным. В вебмастере гугла есть подобные иснтрументы. Поэтому я всё-таки рекоммендую принять (если это возможно) один стандарт относительно названия сайта и следовать ему. > if ($host ~* ^(www\.)(.+)) { > set $HBW $2; > root /var/www/$HBW/web; > } в nginx есть замечательная возможность давать выделениям имена (примеры тут http://nginx.org/ru/docs/http/ngx_http_core_module.html#server_name) поэтому то, что написано выше можно переписать проще: if ($host ~* ^(?:www\.)(?.+)) { root /var/www/$HBW/web; } ? - создаёт переменную $HBW ?: - указывает, что содержимое выделения не следует сохранять в $1. (хотя на самом деле там вообще можно не создавать выделения просто убрав скобки - раз оно нигде не используется) теперь непосредственно сам вопрос: создайте отдельный сервер для обработки всех доменов с www. server { server_name ~^www\.(?.+)$; return 301 $scheme://$servername$request_uri$is_args$args; } а дальше оставьте сущетвующую конфигурацию без if-блока. Если домен содежит www. вначале, то nginx сработает вышеуказанный сервер, а если не содержит, то сервер по-умолчанию. это, на мой взгляд, правильный ибо унифицированный подход.если все сайты должны быть с www., тогда просто поменяйте содежимое блоков (кроме server-name) местами. тогда все сайты без www. будут перенаправлятся на домен с www. Если же Вы всё-таки имеете дело с сайтами, унифицировать которые не представляется возможным (каждый сам себе вебместер), тогда я бы создал сервер, где в server_name разбирается на части и использовал уже их в конфиге далее. К сожалению, сходу не могу написать такой regexp, который будет выделять имя сайта в одну переменную, а поддомен www. (при его наличии) в другую. From mdounin at mdounin.ru Fri Jan 11 09:25:27 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 11 Jan 2013 13:25:27 +0400 Subject: text/vnd.wap.wml error In-Reply-To: <50EF9442.8070102@raftaar.in> References: <50EF9442.8070102@raftaar.in> Message-ID: <20130111092526.GU80623@mdounin.ru> Hello! On Fri, Jan 11, 2013 at 09:55:38AM +0530, Arun Tewatia wrote: > Hi all, > > I am using Nginx as reverse proxy in production with Windows based web servers ( IIS7 ) for my search engine website. > I am frequently facing an issue that my html web pages start getting downloaded instead of opening in browser. > I tried settings*more_set_headers* in Nginx but still the error isn't resolved. > The page works fine if I bypass the Nginx proxy. > The Nginx header works fine for explicit wml pages but still I receive "text/vnd.wap.wml" as content type for some of my html pages. > > I am using nginx/1.2.4 with following line added under http block. > > more_set_headers -t 'text/vnd.wap.wml' 'Content-Type: text/html'; > > What could be going wrong ? Am I missing something ? The root question is "why text/vnd.wap.wml is returned"? I would recommend you to focus on this instead of trying to "fix" this in nginx by changing headers returned. -- Maxim Dounin http://nginx.com/support.html From vovansystems at gmail.com Fri Jan 11 09:52:42 2013 From: vovansystems at gmail.com (VovansystemS) Date: Fri, 11 Jan 2013 12:52:42 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: Не поленился, написал regex и протестировал кусками :) Как-то так должно работать, как Вы и хотели изначально. server_name ~(?:www\.)*(?.+); выделит в переменную $HBW всё доменное имя полностью, кроме поддомена www. Например если: Host: www.subdomain.site.ru то $HBW будет содержать 'subdomain.site.ru' если Host: site.ru то $HBW будет содержать 'site.ru' таким образом везде далее в конфиге используйте эту переменную без всяких if-блоков. server { listen 80 default; server_name ~(?:www\.)*(?.+); server_name_in_redirect off; resolver 127.0.0.1; access_log /var/log/ispconfig/httpd/$host/access.log; location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|flv|mp3)$ { # пусть до файлов по умолчанию root /var/www/$HBW/web; access_log off; expires 30d; } #------------------------------------ location ~* ^.+\.(htm|html)$ { # данная директива при отсутствие файла try_files $uri /index.php; # пусть до файлов по умолчанию root /var/www/$HBW/web; ################################################### access_log off; expires 30d; } ##------------------------------------ location / { #if (!-e $request_filename){ # rewrite ^/(.+) /index.php/$1 break; # } ################################################### # пусть до файлов по умолчанию root /var/www/$HBW/web; ################################################### index index.html index.htm index.php; access_log off; proxy_pass http://$host:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } #################################################### # Настройки для phpmyadmin location /phpmyadmin { root /usr/share/; index index.php index.html index.htm; location ~ ^/phpmyadmin/(.+\.php)$ { try_files $uri =404; root /usr/share/; proxy_pass http://$host:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /usr/share/; } } location /phpMyAdmin { rewrite ^/* /phpmyadmin last; } #Конец phpmyadmin ##################################################### # Настройки для WEBMAIL location /webmail { root /var/www/; index index.php index.html index.htm; location ~ ^/webmail/(.+\.php)$ { try_files $uri =404; root /war/www/webmail; proxy_pass http://127.0.0.1:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host 127.0.0.1:82/webmail; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* ^/webmail/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /var/www/webmail/webmail; } } location /WebMail { rewrite ^/* $host:82/webmail last; } #Конец webmail ##################################################### #---------------AWSTATS location ^~ /awstats-icon { alias /usr/share/awstats/icon/; access_log off; } location ^~ /awstatscss { alias /usr/share/doc/awstats/examples/css/; access_log off; } location ^~ /awstatsclasses { alias /usr/share/doc/awstats/examples/classes/; access_log off; } #---------------AVSTATS-END } # Закрывает server !!! From nginx-forum at nginx.us Fri Jan 11 11:03:00 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 06:03:00 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <4e13d4343c427ec2a147dd25e4f798f6.NginxMailingListRussian@forum.nginx.org> VovansystemS проблема в том что оно и работает и стабильно но не два правила вместе, и я не могу понять причину этого Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234943#msg-234943 From vovansystems at gmail.com Fri Jan 11 11:09:13 2013 From: vovansystems at gmail.com (VovansystemS) Date: Fri, 11 Jan 2013 14:09:13 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: <4e13d4343c427ec2a147dd25e4f798f6.NginxMailingListRussian@forum.nginx.org> References: <4e13d4343c427ec2a147dd25e4f798f6.NginxMailingListRussian@forum.nginx.org> Message-ID: > VovansystemS проблема в том что оно и работает и стабильно > но не два правила вместе, и я не могу понять причину этого не совсем понял в чём сейчас проблема. тот вариант, который я предложил в конце делает чтото не так? опишите, пожалйства, подробнее что именно. т.е. по какому адресу открывается не то, что Вы ожидаете, а по какому то, что надо. интересуют примеры ссылок. From nginx-forum at nginx.us Fri Jan 11 11:20:26 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 06:20:26 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <3927c51cb6a420f27f8e27cf9365d26f.NginxMailingListRussian@forum.nginx.org> сейчас, для этого нужно сэмулировать ситуацию поскольку сайт естественно для выяснения пришлось вернуть на старый хост. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234945#msg-234945 From nginx-forum at nginx.us Fri Jan 11 11:34:46 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 06:34:46 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: <3927c51cb6a420f27f8e27cf9365d26f.NginxMailingListRussian@forum.nginx.org> References: <3927c51cb6a420f27f8e27cf9365d26f.NginxMailingListRussian@forum.nginx.org> Message-ID: joomla 1.5 скейка зеркал отключена http://www.okna-iventus.ru/calculation-of-the-windows.html http://okna-iventus.ru/calculation-of-the-windows.html f-the-windows.html HTTP/1.1", host: "www.okna-iventus.ru" 2013/01/11 15:34:17 [error] 14409#0: *153533 open() "/var/www/okna-iventus.ru/web/calculation-of-the -windows.html" failed (2: No such file or directory), client: 217.21.214.50, server: _, request: "GE T /calculation-of-the-windows.html HTTP/1.1", host: "www.okna-iventus.ru" 2013/01/11 15:34:18 [error] 14409#0: *153534 open() "/var/www/okna-iventus.ru/web/calculation-of-the -windows.html" failed (2: No such file or directory), client: 217.21.214.50, server: _, request: "GE T /calculation-of-the-windows.html HTTP/1.1", host: "www.okna-iventus.ru" 2013/01/11 15:34:18 [error] 14409#0: *153533 open() "/var/www/okna-iventus.ru/web/calculation-of-the -windows.html" failed (2: No such file or directory), client: 217.21.214.50, server: _, request: "GE T /calculation-of-the-windows.html HTTP/1.1", host: "www.okna-iventus.ru" 2013/01/11 15:34:23 [error] 14412#0: *153734 testing "/usr/local/nginx/html" existence failed (2: No such file or directory) while logging request, client: 78.25.62.148, server: _ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234947#msg-234947 From vovansystems at gmail.com Fri Jan 11 12:08:24 2013 From: vovansystems at gmail.com (VovansystemS) Date: Fri, 11 Jan 2013 15:08:24 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: <3927c51cb6a420f27f8e27cf9365d26f.NginxMailingListRussian@forum.nginx.org> Message-ID: > server: _ вот что меня смущает. попробуйте конфигурацию, которую я выложил здесь http://pastebin.com/2CujAryP сегодня уже не будет времени протестировать полностью (т.к. на продакшне не хочется, а тестовой машины под рукой нет), но мне кажется, дожно работать и так (у меня try_files обрабатыает всё как положено). Кстати, какая версия nginx у вас? From nginx-forum at nginx.us Fri Jan 11 12:32:58 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 07:32:58 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <96d00fbacf657540707758cc533c7397.NginxMailingListRussian@forum.nginx.org> могу для простоты дать ssh Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234951#msg-234951 From nginx-forum at nginx.us Fri Jan 11 12:39:23 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 07:39:23 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <393986f2a60ade615034c455c117b493.NginxMailingListRussian@forum.nginx.org> Попробовал ошибка в 3 строчк server { listen 80 default_server; server_name ~^(?:www\.)*(?.+) после изменения на default ошибка вылезла естественно в HBW ;( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234952#msg-234952 From nginx-forum at nginx.us Fri Jan 11 12:41:00 2013 From: nginx-forum at nginx.us (shambler81) Date: Fri, 11 Jan 2013 07:41:00 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: <393986f2a60ade615034c455c117b493.NginxMailingListRussian@forum.nginx.org> References: <393986f2a60ade615034c455c117b493.NginxMailingListRussian@forum.nginx.org> Message-ID: try_files и у меня отрабатывает не отрабатывает когда отрабатывает именно когда есть www ;) ;) nginx version: nginx/0.7.67 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,234953#msg-234953 From admin at sysadmins.el.kg Fri Jan 11 19:10:39 2013 From: admin at sysadmins.el.kg (admin at sysadmins.el.kg) Date: Sat, 12 Jan 2013 01:10:39 +0600 (KGT) Subject: No subject Message-ID: <64614.5.57.15.71.1357931439.squirrel@176.126.165.28> Доброго времени суток! Имеется nginx 1.3.10 следующего содержания: user nobody nobody; worker_processes 16; worker_rlimit_nofile 20480; worker_priority -5; timer_resolution 100ms; error_log /var/log/nginx/error.log info; events { worker_connections 2048; use epoll; } http { access_log off; server_name_in_redirect off; server_names_hash_max_size 10240; server_names_hash_bucket_size 1024; include mime.types; default_type application/octet-stream; server_tokens off; sendfile on; sendfile_max_chunk 128k; tcp_nopush on; tcp_nodelay on; keepalive_requests 100; keepalive_timeout 50s 35; keepalive_disable msie6; ignore_invalid_headers on; client_header_timeout 3m; client_body_timeout 3m; send_timeout 3m; reset_timedout_connection on; connection_pool_size 256; client_header_buffer_size 256k; large_client_header_buffers 4 256k; client_max_body_size 200M; client_body_buffer_size 128k; request_pool_size 32k; output_buffers 4 32k; postpone_output 1460; client_body_in_file_only on; log_format bytes_log "$msec $bytes_sent ."; underscores_in_headers on; lingering_time 30; lingering_timeout 10; proxy_temp_path /tmp/nginx/nginx_proxy/; proxy_cache_path /tmp/nginx/proxy_temp levels=2 keys_zone=pagecache:5m inactive=10m max_size=50m; proxy_cache pagecache; proxy_headers_hash_bucket_size 6400; proxy_headers_hash_max_size 51200; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 320; proxy_buffer_size 64k; proxy_buffers 16 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; proxy_redirect off; proxy_hide_header Vary; proxy_set_header Accept-Encoding ''; proxy_ignore_headers Cache-Control Expires; proxy_ignore_client_abort off; proxy_intercept_errors off; proxy_set_header Referer $http_referer; proxy_set_header Host $host; proxy_set_header Range ""; proxy_set_header Request-Range ""; proxy_set_header Cookie $http_cookie; gzip on; gzip_vary on; gzip_disable "MSIE [1-6]\."; gzip_proxied any; gzip_http_version 1.1; gzip_min_length 1000; gzip_comp_level 6; gzip_buffers 16 8k; gzip_types text/plain text/xml text/css application/x-javascript application/xml application/xml+rss text/javascript application/atom+xml; # Основной домен - java-приложение на бекенде server { listen ип:80 rcvbuf=8192 sndbuf=16384 backlog=32000; server_name хост www.хост; access_log /usr/local/apache/domlogs/хост-bytes_log bytes_log; access_log /usr/local/apache/domlogs/хост.com combined; location / { proxy_pass http://127.0.0.1:8081; proxy_redirect http://127.0.0.1:8081/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } } server { listen ип:80; server_name wiki.хост www.wiki.хост; access_log /usr/local/apache/domlogs/wiki.хост-bytes_log bytes_log; access_log /usr/local/apache/domlogs/wiki.хост combined; location ~* ^.+\.(3gp|gif|jpg|jpeg|png|ico|wmv|avi|asf|asx|mpg|mpeg|mp4|pls|mp3|mid|wav|swf|flv|html|htm|txt|js|css|exe|zip|tar|rar|gz|tgz|bz2|uha|7z|doc|docx|xls|xlsx|pdf|iso)$ { root /home/wiki/www; expires 1d; error_log /var/log/nginx/vhost-error_log warn; try_files $uri $uri/ @fallback; } location / { proxy_pass http://ип:8090; proxy_redirect http://ип:8090/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } location @fallback { proxy_pass http://ип:8081; add_header X-Cache "Jump to backend"; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } location ~ /\.ht { deny all; } } include "/etc/nginx/vhosts/*"; } На пыхающем бэкенде - апач с suphp. Работало все это отлично пока не перенес на боевой хост. А там началось... Не проходят данные из форм отправляемые POST-запросом - валится все в 500-ю ошибку вот с такими нерадостными вещами: Handler for (null) returned invalid result code 70014 Handler for (null) returned invalid result code 70007 Что я не так напорол с конфигом? From vovansystems at gmail.com Sat Jan 12 08:59:30 2013 From: vovansystems at gmail.com (VovansystemS) Date: Sat, 12 Jan 2013 11:59:30 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: <393986f2a60ade615034c455c117b493.NginxMailingListRussian@forum.nginx.org> Message-ID: > nginx version: nginx/0.7.67 У Вас очень старый nginx ;) Он ещё не знает что такое именованные выделения. "Именованные выделения в регулярном выражении создают переменные (0.8.25), которые могут затем использоваться в других директивах:" Я очень настоятельно рекомендую обновиться до версии 1.2.х, если есть возможность. Репозитории со свежими версиями можно подключить для разных ОС как это описано тут http://wiki.nginx.org/Install#Official_Debian.2FUbuntu_packages Если обновится, по каким-либо причинам, не представляется возможность, то можно попробовать переписать конфиг для старого nginx, который сейчас установлен, но проверить у правильность синтаксиса у меня нет возможности :) Попробуйте такой конфиг http://pastebin.com/Ur4HMs46 From vovansystems at gmail.com Sat Jan 12 09:32:05 2013 From: vovansystems at gmail.com (VovansystemS) Date: Sat, 12 Jan 2013 12:32:05 +0300 Subject: =?UTF-8?B?0LrQstCw0L3RgtC40YTQuNC60LDRhtC40Y8g0LPRgNGD0L/Qv9GL?= Message-ID: Здравствуйте! Требуется создать один server, который будет обрабатывать все запросы по единому шаблону. Поскольку некоторые сайты могут иметь поддомен www., а папки с сайтами имеют название без www. то я написал такой server_name server_name ~^(?:www\.)*(?.+)$; И данный конфиг работает, но не совсем так, как требуется. Из-за того что я применил квантификатор * (ноль или более раз), что соотвествует {0,}, то некоторые сайты будут обрабатываться неправильно. Например Host: www.www.example.com в переменную $domain попадёт только example.com, а должен был бы попасть www.example.com На самом деле это не очень важный момент, но когда я попытался исправить это поведение, оказалось что я не понимаю как работает квантификация для группы через фигурные скобки в nginx. Вариант, который все запросы должен обрабатывать правильно: server_name ~^(?:www\.)\{0,1}(?.+)$; почему-то не работает. возможно, я не там экранирую фигурные скобки или не совсем понимаю синтаксис. как правильно квантифицировать группу в nginx? From peter at vereshagin.org Sat Jan 12 09:37:31 2013 From: peter at vereshagin.org (Peter Vereshagin) Date: Sat, 12 Jan 2013 13:37:31 +0400 Subject: =?UTF-8?B?UmU6INC60LLQsNC90YLQuNGE0LjQutCw0YbQuNGPINCz0YDRg9C/0L/Riw==?= In-Reply-To: References: Message-ID: <20130112093731.GB5325@external.screwed.box> Hello. 2013/01/12 12:32:05 +0300 VovansystemS => To nginx-ru at nginx.org : V> Требуется создать один server, который будет обрабатывать все запросы V> по единому шаблону. Поскольку некоторые сайты могут иметь поддомен V> www., а папки с сайтами имеют название без www. то я написал такой V> server_name V> V> server_name ~^(?:www\.)*(?.+)$; V> V> И данный конфиг работает, но не совсем так, как требуется. Из-за того V> что я применил квантификатор * (ноль или более раз), что соотвествует V> {0,}, то некоторые сайты будут обрабатываться неправильно. Например V> Host: www.www.example.com V> в переменную $domain попадёт только example.com, а должен был бы V> попасть www.example.com V> V> На самом деле это не очень важный момент, но когда я попытался V> исправить это поведение, оказалось что я не понимаю как работает V> квантификация для группы через фигурные скобки в nginx. V> V> Вариант, который все запросы должен обрабатывать правильно: V> server_name ~^(?:www\.)\{0,1}(?.+)$; V> почему-то не работает. возможно, я не там экранирую фигурные скобки V> или не совсем понимаю синтаксис. как правильно квантифицировать группу V> в nginx? Зачем квантификатор '*' или {0,1} ? Есть квантификатор '?'. Я здесь спрашивал было дело насчёт '{n.m} quantifier в regexp' и мне было отвечено 'экранируйте {} в ""'. Thank you. -- Peter Vereshagin (http://vereshagin.org) pgp: 1754B9C1 From postmaster at softsearch.ru Sat Jan 12 09:42:12 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 12 Jan 2013 13:42:12 +0400 Subject: =?UTF-8?B?UmU6INC60LLQsNC90YLQuNGE0LjQutCw0YbQuNGPINCz0YDRg9C/0L/Riw==?= In-Reply-To: References: Message-ID: <146329463.20130112134212@softsearch.ru> Здравствуйте, VovansystemS. > Требуется создать один server, который будет обрабатывать все > запросы по единому шаблону. Поскольку некоторые сайты могут иметь > поддомен www., а папки с сайтами имеют название без www. то я > написал такой server_name > server_name ~^(?:www\.)*(?.+)$; А Вы совсем не знаете список возможных хостов? Потому что, если знаете, то правильнее просто перечислить их всех с www. и без . Работать будет быстрее. А вообще никто не мешает в Вашем регэкспе нагородить ещё одну именованную переменную, которая будет включать в себя хост с возможным www. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vovansystems at gmail.com Sat Jan 12 10:01:25 2013 From: vovansystems at gmail.com (VovansystemS) Date: Sat, 12 Jan 2013 13:01:25 +0300 Subject: =?UTF-8?B?UmU6INC60LLQsNC90YLQuNGE0LjQutCw0YbQuNGPINCz0YDRg9C/0L/Riw==?= In-Reply-To: <20130112093731.GB5325@external.screwed.box> References: <20130112093731.GB5325@external.screwed.box> Message-ID: > Зачем квантификатор '*' или {0,1} ? Есть квантификатор '?'. действительно! вылетел из головы :) server_name ~^(?:www\.)?(?.+)$; так работает > Я здесь спрашивал было дело насчёт '{n.m} quantifier в regexp' и мне было отвечено 'экранируйте {} в ""'. действительно "Если в регулярном выражении встречаются символы "}" или ";", то всё выражение следует заключить в одинарные или двойные кавычки." Поэтому так будет работать: server_name '~^(?:www\.){0,1}(?.+)$'; server_name "~^(?:www\.){0,1}(?.+)$"; Peter Vereshagin, спасибо большое за разъяснения! В будущем постараюсь гуглить внимательнее. > А Вы совсем не знаете список возможных хостов? Потому что, если > знаете, то правильнее просто перечислить их всех с www. и без . > Работать будет быстрее. если список хостов довольно большой, то наверное это не совсем удобно, хотя.. да, ничто не мешает вынести server_name в include блок вида server_name www.exapmle.com example.com www.exapmle.org example.org .. www.exapmle.net example.net ; и добавлять/удалять скриптом. это будет работать быстрее всего. > А вообще никто не мешает в Вашем регэкспе нагородить ещё одну > именованную переменную, которая будет включать в себя хост с возможным > www. это некрасиво и непроизводительно :) From mdounin at mdounin.ru Sat Jan 12 18:39:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 12 Jan 2013 22:39:33 +0400 Subject: your mail In-Reply-To: <64614.5.57.15.71.1357931439.squirrel@176.126.165.28> References: <64614.5.57.15.71.1357931439.squirrel@176.126.165.28> Message-ID: <20130112183932.GC14602@mdounin.ru> Hello! On Sat, Jan 12, 2013 at 01:10:39AM +0600, admin at sysadmins.el.kg wrote: > Доброго времени суток! Имеется nginx 1.3.10 следующего содержания: Для начала - обновить до 1.3.11. [...] -- Maxim Dounin http://nginx.com/support.html From scroitor at gmail.com Sat Jan 12 19:10:00 2013 From: scroitor at gmail.com (Sergey Croitor) Date: Sat, 12 Jan 2013 21:10:00 +0200 Subject: =?UTF-8?B?bG9jYXRpb24gdXJpINGBINCw0YDQs9GD0LzQtdC90YLQsNC80Lgg0LLQutC70Y4=?= =?UTF-8?B?0YfQuNGC0LXQu9GM0L3Qvg==?= Message-ID: Доброго времени суток всем! Пытаюсь организовать кэширование страниц с uri начинающегося со следующих символов: /index.php?main_page=nocachedajax&q=savelocation Надо сделать это только для роботов Поначалу была мысль сделать так: location /index.php?main_page=nocachedajax&q=savelocation { proxy_pass http://backend; proxy_cache cache; proxy_cache_valid 200 302 304 1800m; proxy_cache_valid any 1s; proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|savelocation"; proxy_hide_header "Set-Cookie"; proxy_ignore_headers "Cache-Control" "Expires"; add_header Cache-Control private; expires 1800m; include /etc/nginx/proxy.conf; if ($http_user_agent !~* (spider|bot|crawler)) { # для нероботов не кэшируем и шлем далее на бэкенд # роботоопределение грубое, но для нашего случая достаточное return 412; } error_page 412 = @fallback; } или как вариант задания location location ^~ /index.php?main_page=nocachedajax&q=savelocation { ... } Но в документации наткнулся на следующее: Note that locations of all types test only a URI part of request line without arguments. This is done because arguments in the query string may be given in several ways То есть все, что после "?", будет проигнорировано и совпадения с указанной строкой не будет никогда. Кто-то может поделиться идеей как обойти это ограничение и как правильно указать правило для location в этом случае? Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scroitor at gmail.com Sat Jan 12 22:06:25 2013 From: scroitor at gmail.com (Sergey Croitor) Date: Sun, 13 Jan 2013 00:06:25 +0200 Subject: test Message-ID: just a test, please ignore -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Sun Jan 13 00:55:16 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 04:55:16 +0400 Subject: =?UTF-8?B?0KLQvtGA0LzQvtC20LXQvdC40LUg0LHQvtGC0L7QsiDRh9C10YDQtdC3IGxpbWl0?= =?UTF-8?B?X3JlcQ==?= Message-ID: <1034894495.20130113045516@softsearch.ru> Здравствуйте. Захотелось тут ограничить количество запросов, приходящих от ботов. Написал вот так: map $http_user_agent $rpm { default 999999; ~bot 1; } limit_req_zone $binary_remote_addr zone=one:10m rate=$rpm r/s; Но оказалось: invalid number of arguments in "limit_req_zone" directive Ошибку осознал. Переписал вот так: map $http_user_agent $ua_zone { default notbot; ~bot bot; } limit_req_zone $http_user_agent zone=bot:10m rate=1r/s; limit_req_zone $http_user_agent zone=notbot:10m rate=999999r/s; limit_req zone=$ua_zone burst=120; Выдало:unknown limit_req_zone "$ua_zone" Пришлось пока применить старый, но не совсем мне подходящий способ: if ($http_user_agent ~ "bot"){ set $limit_rate 1000; } Подскажите пожалуйста, как ограничить количество запросов через limit_req для юзерагентов, для которых матчится регэксп? -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Sun Jan 13 01:04:47 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 13 Jan 2013 05:04:47 +0400 Subject: =?UTF-8?B?UmU6INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LXQtyBs?= =?UTF-8?B?aW1pdF9yZXE=?= In-Reply-To: <1034894495.20130113045516@softsearch.ru> References: <1034894495.20130113045516@softsearch.ru> Message-ID: <201301130504.47702.vbart@nginx.com> On Sunday 13 January 2013 04:55:16 Михаил Монашёв wrote: > Здравствуйте. > > Захотелось тут ограничить количество запросов, приходящих от ботов. > Написал вот так: > > map $http_user_agent $rpm { > default 999999; > ~bot 1; > } > > limit_req_zone $binary_remote_addr zone=one:10m rate=$rpm r/s; > > Но оказалось: invalid number of arguments in "limit_req_zone" directive > > Ошибку осознал. Переписал вот так: > > map $http_user_agent $ua_zone { > default notbot; > ~bot bot; > } > > limit_req_zone $http_user_agent zone=bot:10m rate=1r/s; > limit_req_zone $http_user_agent zone=notbot:10m rate=999999r/s; > limit_req zone=$ua_zone burst=120; Это называется - перемудрить. =) > > Выдало:unknown limit_req_zone "$ua_zone" > > Пришлось пока применить старый, но не совсем мне подходящий способ: > if ($http_user_agent ~ "bot"){ > set $limit_rate 1000; > } > > Подскажите пожалуйста, как ограничить количество запросов через > limit_req для юзерагентов, для которых матчится регэксп? map $http_user_agent $bot_ua { ~bot bot; } limit_req_zone $bot_ua zone=bot:10m rate=1r/s; limit_req zone=bot burst=120; -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Sun Jan 13 08:07:37 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 12:07:37 +0400 Subject: =?UTF-8?B?UmVbMl06INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LU=?= =?UTF-8?B?0LcgbGltaXRfcmVx?= In-Reply-To: <201301130504.47702.vbart@nginx.com> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> Message-ID: <1132552658.20130113120737@softsearch.ru> Здравствуйте, Валентин. >> Подскажите пожалуйста, как ограничить количество запросов через >> limit_req для юзерагентов, для которых матчится регэксп? > map $http_user_agent $bot_ua { > ~bot bot; > } > limit_req_zone $bot_ua zone=bot:10m rate=1r/s; > limit_req zone=bot burst=120; Спасибо большое! Линия партии, как я теперь понимаю, такая: если в аргументах пустая строка, то директива отключается. Так? -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sun Jan 13 09:02:26 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 13:02:26 +0400 Subject: =?UTF-8?B?UmVbMl06INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LU=?= =?UTF-8?B?0LcgbGltaXRfcmVx?= In-Reply-To: <201301130504.47702.vbart@nginx.com> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> Message-ID: <364202695.20130113130226@softsearch.ru> Здравствуйте, Валентин. >> Подскажите пожалуйста, как ограничить количество запросов через >> limit_req для юзерагентов, для которых матчится регэксп? > map $http_user_agent $bot_ua { > ~bot bot; > } > limit_req_zone $bot_ua zone=bot:10m rate=1r/s; > limit_req zone=bot burst=120; А можно сюда как-то приделать, чтобы ограничение работало для запросов от ботов, которые проксируются? Заметил в http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html неточность: "Избыточные запросы задерживаются до тех пор, пока их число не превысит заданное число всплесков." Видимо имеется ввиду не число всплесков, а число запросов в всплеске. А сам всплеск один. limit_req, как я понял, работает так: все запросы ниже скорости rate=1r/s обслуживаются нормально, от rate=1r/s, но не более burst=120 в очереди, тормозятся. А если очередь превышается, то выдаётся 503. Я правильно понял? -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sun Jan 13 09:49:48 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 13:49:48 +0400 Subject: =?UTF-8?B?UmVbMl06INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LU=?= =?UTF-8?B?0LcgbGltaXRfcmVx?= In-Reply-To: <201301130504.47702.vbart@nginx.com> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> Message-ID: <137224525.20130113134948@softsearch.ru> Здравствуйте, Валентин. А как в логе увидеть флаг того , что запрос был приторможен? Понятно, что есть реквет-тайм, но может он большой по каким-то другим причинам. -- С уважением, Михаил mailto:postmaster at softsearch.ru From admin at sysadmins.el.kg Sun Jan 13 13:55:53 2013 From: admin at sysadmins.el.kg (admin at sysadmins.el.kg) Date: Sun, 13 Jan 2013 19:55:53 +0600 (KGT) Subject: Handler for (null) returned invalid result code In-Reply-To: <20130112183932.GC14602@mdounin.ru> References: <64614.5.57.15.71.1357931439.squirrel@176.126.165.28> <20130112183932.GC14602@mdounin.ru> Message-ID: <58331.212.42.123.223.1358085353.squirrel@176.126.165.28> Причина - бага в версии? P.S. Прошу прощения перед участниками рассылки - клацнул "отправить" не добавив заголовок. > Hello! > > On Sat, Jan 12, 2013 at 01:10:39AM +0600, admin at sysadmins.el.kg wrote: > >> Доброго времени суток! Имеется nginx 1.3.10 следующего содержания: > > Для начала - обновить до 1.3.11. > > [...] > > -- > Maxim Dounin > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sun Jan 13 14:05:49 2013 From: nginx-forum at nginx.us (memento) Date: Sun, 13 Jan 2013 09:05:49 -0500 Subject: =?UTF-8?B?0JrQvtC90YTQuNCz0YPRgNCw0YbQuNGPIG5naW54INC90YPQttC90LAg0L/QvtC8?= =?UTF-8?B?0L7RidGM?= Message-ID: Добрый день! Помогите разобраться с настройкой nginx, задача такая: Есть domain1.ru и domain2.ru ...... domain100.ru Для domain1.ru конфиг nginx вглядит вот так: server { listen ip address:80; server_name www.domain1.ru; rewrite ^ http://domain1.ru$request_uri? permanent; #301 redirect } server { listen ip address:80; server_name .domain1.ru; Если в браузере набрать например subdomain.domain1.ru ....... subdomain100.domain.ru url в браузере не изменяется, но отдается контент главной страницы domain1.ru Возможно ли сделать также и для доменов domain2.ru ...... domain100.ru? То есть при заходе на domain100.ru (который припаркован к ip адресу сервера) nginx отдавал главную страницу domain1.ru, не редиректя на domain1.ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234973,234973#msg-234973 From vbart at nginx.com Sun Jan 13 14:35:23 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 13 Jan 2013 18:35:23 +0400 Subject: =?UTF-8?B?UmU6INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LXQtyBs?= =?UTF-8?B?aW1pdF9yZXE=?= In-Reply-To: <1132552658.20130113120737@softsearch.ru> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> <1132552658.20130113120737@softsearch.ru> Message-ID: <201301131835.23694.vbart@nginx.com> On Sunday 13 January 2013 12:07:37 Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> Подскажите пожалуйста, как ограничить количество запросов через > >> limit_req для юзерагентов, для которых матчится регэксп? > >> > > map $http_user_agent $bot_ua { > > > > ~bot bot; > > > > } > > > > limit_req_zone $bot_ua zone=bot:10m rate=1r/s; > > > > limit_req zone=bot burst=120; > > Спасибо большое! > Линия партии, как я теперь понимаю, такая: если в аргументах пустая > строка, то директива отключается. Так? Да. Так всегда было. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Sun Jan 13 14:37:53 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 18:37:53 +0400 Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCwINC/?= =?UTF-8?B?0L7QvNC+0YnRjA==?= In-Reply-To: References: Message-ID: <75108179.20130113183753@softsearch.ru> Здравствуйте, memento. Вы писали 13 января 2013 г., 18:05:49: > Добрый день! > Помогите разобраться с настройкой nginx, задача такая: > Есть domain1.ru и domain2.ru ...... domain100.ru > Для domain1.ru конфиг nginx вглядит вот так: > server { > listen ip address:80; > server_name www.domain1.ru; > rewrite ^ http://domain1.ru$request_uri? permanent; #301 redirect > } > server { > listen ip address:80; > server_name .domain1.ru; > Если в браузере набрать например subdomain.domain1.ru ....... > subdomain100.domain.ru url в браузере не изменяется, но отдается контент > главной страницы domain1.ru > Возможно ли сделать также и для доменов domain2.ru ...... domain100.ru? > То есть при заходе на domain100.ru (который припаркован к ip адресу сервера) > nginx отдавал главную страницу domain1.ru, не редиректя на domain1.ru - server_name .domain1.ru; + server_name *; -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Sun Jan 13 14:39:11 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 13 Jan 2013 18:39:11 +0400 Subject: =?UTF-8?B?UmU6INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LXQtyBs?= =?UTF-8?B?aW1pdF9yZXE=?= In-Reply-To: <137224525.20130113134948@softsearch.ru> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> <137224525.20130113134948@softsearch.ru> Message-ID: <201301131839.11182.vbart@nginx.com> On Sunday 13 January 2013 13:49:48 Михаил Монашёв wrote: > Здравствуйте, Валентин. > > А как в логе увидеть флаг того , что запрос был приторможен? Понятно, > что есть реквет-тайм, но может он большой по каким-то другим причинам. http://nginx.org/r/limit_req_log_level/ru -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Sun Jan 13 14:52:14 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 18:52:14 +0400 Subject: =?UTF-8?B?UmVbMl06INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LU=?= =?UTF-8?B?0LcgbGltaXRfcmVx?= In-Reply-To: <201301131839.11182.vbart@nginx.com> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> <137224525.20130113134948@softsearch.ru> <201301131839.11182.vbart@nginx.com> Message-ID: <1834135291.20130113185214@softsearch.ru> Здравствуйте, Валентин. >> А как в логе увидеть флаг того , что запрос был приторможен? Понятно, >> что есть реквест-тайм, но может он большой по каким-то другим причинам. > http://nginx.org/r/limit_req_log_level/ru Я про access-лог говорил конечно же. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Sun Jan 13 15:09:59 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 13 Jan 2013 19:09:59 +0400 Subject: =?UTF-8?B?UmU6INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LXQtyBs?= =?UTF-8?B?aW1pdF9yZXE=?= In-Reply-To: <364202695.20130113130226@softsearch.ru> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> <364202695.20130113130226@softsearch.ru> Message-ID: <201301131909.59670.vbart@nginx.com> On Sunday 13 January 2013 13:02:26 Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> Подскажите пожалуйста, как ограничить количество запросов через > >> limit_req для юзерагентов, для которых матчится регэксп? > >> > > map $http_user_agent $bot_ua { > > > > ~bot bot; > > > > } > > > > limit_req_zone $bot_ua zone=bot:10m rate=1r/s; > > > > limit_req zone=bot burst=120; > > А можно сюда как-то приделать, чтобы ограничение работало для запросов > от ботов, которые проксируются? > Указать limit_req в location с proxy_pass. Но надо учитывать, что proxy-модуль работает уже после, поэтому если запрос будет отдан из кэша, то об этом становится известно уже только после того, как отработал limit_req. [...] > > limit_req, как я понял, работает так: все запросы ниже скорости > rate=1r/s обслуживаются нормально, от rate=1r/s, но не более burst=120 > в очереди, тормозятся. А если очередь превышается, то выдаётся 503. Я > правильно понял? Приблизительно. Точное описание алгоритма есть на википедии: http://en.wikipedia.org/wiki/Leaky_bucket -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From vbart at nginx.com Sun Jan 13 15:15:01 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 13 Jan 2013 19:15:01 +0400 Subject: =?UTF-8?B?UmU6INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LXQtyBs?= =?UTF-8?B?aW1pdF9yZXE=?= In-Reply-To: <1834135291.20130113185214@softsearch.ru> References: <1034894495.20130113045516@softsearch.ru> <201301131839.11182.vbart@nginx.com> <1834135291.20130113185214@softsearch.ru> Message-ID: <201301131915.02126.vbart@nginx.com> On Sunday 13 January 2013 18:52:14 Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> А как в логе увидеть флаг того , что запрос был приторможен? Понятно, > >> что есть реквест-тайм, но может он большой по каким-то другим причинам. > > > > http://nginx.org/r/limit_req_log_level/ru > > Я про access-лог говорил конечно же. Тогда ответом будет: сейчас никак. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From admin at sysadmins.el.kg Sun Jan 13 16:01:46 2013 From: admin at sysadmins.el.kg (admin at sysadmins.el.kg) Date: Sun, 13 Jan 2013 22:01:46 +0600 (KGT) Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCwINC/?= =?UTF-8?B?0L7QvNC+0YnRjA==?= In-Reply-To: References: Message-ID: <5265.212.42.123.223.1358092906.squirrel@176.126.165.28> Вам алиас повесить нужно? Тогда в директиве listen допишите ваши домены через пробел. > Добрый день! > > Помогите разобраться с настройкой nginx, задача такая: > > Есть domain1.ru и domain2.ru ...... domain100.ru > > Для domain1.ru конфиг nginx вглядит вот так: > > server { > listen ip address:80; > server_name www.domain1.ru; > rewrite ^ http://domain1.ru$request_uri? permanent; #301 redirect > } > > server { > listen ip address:80; > server_name .domain1.ru; > > > Если в браузере набрать например subdomain.domain1.ru ....... > subdomain100.domain.ru url в браузере не изменяется, но отдается контент > главной страницы domain1.ru > > Возможно ли сделать также и для доменов domain2.ru ...... domain100.ru? > > То есть при заходе на domain100.ru (который припаркован к ip адресу > сервера) > nginx отдавал главную страницу domain1.ru, не редиректя на domain1.ru > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,234973,234973#msg-234973 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mva at mva.name Sun Jan 13 17:45:31 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 14 Jan 2013 00:45:31 +0700 Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCwINC/?= =?UTF-8?B?0L7QvNC+0YnRjA==?= In-Reply-To: <75108179.20130113183753@softsearch.ru> References: <75108179.20130113183753@softsearch.ru> Message-ID: <50F2F2BB.5080807@mva.name> 13.01.2013 21:37, Михаил Монашёв пишет: > > - server_name .domain1.ru; > + server_name *; > А почему не _ ? :P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From nginx-forum at nginx.us Sun Jan 13 17:57:14 2013 From: nginx-forum at nginx.us (memento) Date: Sun, 13 Jan 2013 12:57:14 -0500 Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCwINC/?= =?UTF-8?B?0L7QvNC+0YnRjA==?= In-Reply-To: <50F2F2BB.5080807@mva.name> References: <50F2F2BB.5080807@mva.name> Message-ID: <75b884d63d5605a26c6be45989a98c95.NginxMailingListRussian@forum.nginx.org> Видимо я не правильно объяснил что мне было нужно. Надо было добиться того, чтобы nginx обрабатывал все домены которые припаркованы к ip сервера, чтобы в дальнейшем скриптами подгружать в зависимости от домена контент. Решил вопрос так, в панели управления доменным именем добавил алиас *.domainname.ru В конфиге nginx дописал default_server server { listen ip_adress:80 default_server; server_name .domainname.ru; } Теперь все заработало. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234973,235014#msg-235014 From postmaster at softsearch.ru Sun Jan 13 18:59:03 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 22:59:03 +0400 Subject: =?UTF-8?B?0JHQsNCz0LAg0LIgcHJveHlfbWV0aG9k?= Message-ID: <11810138060.20130113225903@softsearch.ru> Здравствуйте. Включил на проксирующем nginx-е директиву proxy_method GET; и он стал слать кривые запросы вида: GET/94/82/38294/5/4858305/789797.gif HTTP/1.0 Т.е. после GET пробел пропал. nginx -V nginx version: nginx/1.3.11 configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module --with-http_stub_status_module --with-pcre -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sun Jan 13 19:02:28 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 13 Jan 2013 23:02:28 +0400 Subject: =?UTF-8?B?UmVbMl06INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCw?= =?UTF-8?B?INC/0L7QvNC+0YnRjA==?= In-Reply-To: <75108179.20130113183753@softsearch.ru> References: <75108179.20130113183753@softsearch.ru> Message-ID: <1018704543.20130113230228@softsearch.ru> Здравствуйте, Михаил. > - server_name .domain1.ru; > + server_name *; Судя по http://nginx.org/ru/docs/http/server_names.html я неправильно написал. default_server - правильное решение. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mva at mva.name Sun Jan 13 19:45:43 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 14 Jan 2013 02:45:43 +0700 Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCwINC/?= =?UTF-8?B?0L7QvNC+0YnRjA==?= In-Reply-To: <75b884d63d5605a26c6be45989a98c95.NginxMailingListRussian@forum.nginx.org> References: <50F2F2BB.5080807@mva.name> <75b884d63d5605a26c6be45989a98c95.NginxMailingListRussian@forum.nginx.org> Message-ID: <50F30EE7.4020401@mva.name> 14.01.2013 00:57, memento пишет: > чтобы nginx обрабатывал все домены которые припаркованы к ip сервер Именно для этого и подсказали server_name * и server_name _. Это заставит nginx ловить в этот сервер _ВСЕ_ обращения какому бы то ни было домену :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From vbart at nginx.com Sun Jan 13 20:50:48 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 14 Jan 2013 00:50:48 +0400 Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCwINC/?= =?UTF-8?B?0L7QvNC+0YnRjA==?= In-Reply-To: <50F30EE7.4020401@mva.name> References: <50F2F2BB.5080807@mva.name> <75b884d63d5605a26c6be45989a98c95.NginxMailingListRussian@forum.nginx.org> <50F30EE7.4020401@mva.name> Message-ID: <201301140050.48573.vbart@nginx.com> On Sunday 13 January 2013 23:45:43 Vadim A. Misbakh-Soloviov wrote: > 14.01.2013 00:57, memento пишет: > > чтобы nginx обрабатывал все домены которые припаркованы к ip сервер > > Именно для этого и подсказали server_name * и server_name _. > Это заставит nginx ловить в этот сервер _ВСЕ_ обращения какому бы то ни > было домену :) Нет. Откуда берутся эти мифы? "_" - просто не существующий домен, а с server_name * получите ошибку конфигурации и nginx не запустится. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Sun Jan 13 22:13:47 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 14 Jan 2013 02:13:47 +0400 Subject: =?UTF-8?B?UmVbMl06INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCw?= =?UTF-8?B?INC/0L7QvNC+0YnRjA==?= In-Reply-To: <201301140050.48573.vbart@nginx.com> References: <50F2F2BB.5080807@mva.name> <75b884d63d5605a26c6be45989a98c95.NginxMailingListRussian@forum.nginx.org> <50F30EE7.4020401@mva.name> <201301140050.48573.vbart@nginx.com> Message-ID: <167258508.20130114021347@softsearch.ru> Здравствуйте, Валентин. >> Именно для этого и подсказали server_name * и server_name _. >> Это заставит nginx ловить в этот сервер _ВСЕ_ обращения какому бы >> то ни было домену :) > Нет. Откуда берутся эти мифы? Звёздочка получается логически. У меня во всяком случае так получилось. :-) Про подчёркивание я не понял, удивился, начал читать доку (с фантазией туго) и наткнулся на то, как надо в соответствии с линией партии. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Mon Jan 14 00:07:15 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 14 Jan 2013 04:07:15 +0400 Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBuZ2lueCDQvdGD0LbQvdCwINC/?= =?UTF-8?B?0L7QvNC+0YnRjA==?= In-Reply-To: <167258508.20130114021347@softsearch.ru> References: <50F2F2BB.5080807@mva.name> <201301140050.48573.vbart@nginx.com> <167258508.20130114021347@softsearch.ru> Message-ID: <201301140407.16194.vbart@nginx.com> On Monday 14 January 2013 02:13:47 Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> Именно для этого и подсказали server_name * и server_name _. > >> Это заставит nginx ловить в этот сервер _ВСЕ_ обращения какому бы > >> то ни было домену :) > > > > Нет. Откуда берутся эти мифы? > > Звёздочка получается логически. У меня во всяком случае так > получилось. :-) Про подчёркивание я не понял, удивился, начал читать > доку (с фантазией туго) и наткнулся на то, как надо в соответствии с > линией партии. С помощью "_" просто перекрывают значение этой директивы по-умолчанию "", когда оно по каким-то причинам не устраивает. Звёздочке даже специально был посвящен отдельный абзац: Версии nginx вплоть до 0.6.25 поддерживали специальное имя ?*?, которое многими неверно воспринималось как имя сервера для обработки всех запросов. Оно никогда так не работало, и не работало как имя с маской. Это имя действовало так же, как сейчас действует директива server_name_in_redirect. Специальное имя ?*? объявлено устаревшим, а вместо него следует использовать директиву server_name_in_redirect. Заметьте, что с помощью директивы server_name нельзя задать ни имя сервера для обработки всех запросов, ни сервер по умолчанию. Это является свойством директивы listen, а не server_name. @ http://nginx.org/ru/docs/http/server_names.html -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From mdounin at mdounin.ru Mon Jan 14 02:38:15 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 06:38:15 +0400 Subject: Handler for (null) returned invalid result code In-Reply-To: <58331.212.42.123.223.1358085353.squirrel@176.126.165.28> References: <64614.5.57.15.71.1357931439.squirrel@176.126.165.28> <20130112183932.GC14602@mdounin.ru> <58331.212.42.123.223.1358085353.squirrel@176.126.165.28> Message-ID: <20130114023814.GD25043@mdounin.ru> Hello! On Sun, Jan 13, 2013 at 07:55:53PM +0600, admin at sysadmins.el.kg wrote: > Причина - бага в версии? В 1.3.10 была достаточно серьёзная ошибка, которая могла приводить к случайным segmentation fault'ам в рабочих процессах, см. [1]. Это, в свою очередь, могло приводить ко всяким загадочным эффектам, если смотреть на проблему со стороны приложения, и не заглядывать в error log. Является ли эта конкретная ошибка причиной наблюдаемых у вас проблем - неизвестно, но в любом случае перед тем, как продолжать их изучение, - следует подобную возможность ислючить. Если после обновления проблема не воспроизведётся - можете с чистой совестью считать, что причиной была та самая ошибка. (Можно ещё заглянуть в error log и посмотреть что там. Но обновиться - всё равно надо.) [1] http://nginx.org/ru/CHANGES.ru -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Mon Jan 14 02:54:01 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 06:54:01 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <11810138060.20130113225903@softsearch.ru> References: <11810138060.20130113225903@softsearch.ru> Message-ID: <20130114025401.GF25043@mdounin.ru> Hello! On Sun, Jan 13, 2013 at 10:59:03PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Включил на проксирующем nginx-е директиву > proxy_method GET; > и он стал слать кривые запросы вида: > GET/94/82/38294/5/4858305/789797.gif HTTP/1.0 > > Т.е. после GET пробел пропал. Это фича, надо писать proxy_method "GET "; -- Maxim Dounin http://nginx.com/support.html From hell-for-yahoo at umail.ru Mon Jan 14 07:34:12 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 14 Jan 2013 11:34:12 +0400 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHVyaSDRgSDQsNGA0LPRg9C80LXQvdGC0LDQvNC4INCy0Lo=?= =?UTF-8?B?0LvRjtGH0LjRgtC10LvRjNC90L4=?= In-Reply-To: References: Message-ID: <1291628882.20130114113412@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Sergey Croitor! SC> Пытаюсь организовать кэширование страниц с uri начинающегося со следующих SC> символов: SC> /index.php?main_page=nocachedajax&q=savelocation Боюсь вас разочаровать, но для URL'ов в таком виде многие роботы частенько переставляют параметры запроса, как им угодно, так что на выполнение условия "начинается с" я бы на вашем месте надеяться не стал. SC> Надо сделать это только для роботов SC> Поначалу была мысль сделать так: SC> location /index.php?main_page=nocachedajax&q=savelocation { SC> proxy_pass http://backend; SC> proxy_cache cache; SC> proxy_cache_valid 200 302 304 1800m; SC> proxy_cache_valid any 1s; SC> proxy_cache_key SC> "$request_method|$http_if_modified_since|$http_if_none_match|$host|savelocation"; SC> proxy_hide_header "Set-Cookie"; SC> proxy_ignore_headers "Cache-Control" "Expires"; SC> add_header Cache-Control private; SC> expires 1800m; SC> include /etc/nginx/proxy.conf; SC> if ($http_user_agent !~* (spider|bot|crawler)) { SC> # для нероботов не кэшируем и шлем далее на бэкенд SC> # роботоопределение грубое, но для нашего случая SC> достаточное SC> return 412; SC> } SC> error_page 412 = @fallback; SC> } SC> или как вариант задания location SC> location ^~ /index.php?main_page=nocachedajax&q=savelocation { SC> ... SC> } SC> Но в документации наткнулся на следующее: SC> Note that locations of all types test only a URI part of request line SC> without arguments. This is done because arguments in the query string may SC> be given in several ways SC> То есть все, что после "?", будет проигнорировано и совпадения с указанной SC> строкой не будет никогда. SC> Кто-то может поделиться идеей как обойти это ограничение и как правильно SC> указать правило для location в этом случае? SC> Спасибо. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 14.01.2013, <11:32> From postmaster at softsearch.ru Mon Jan 14 09:43:43 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 14 Jan 2013 13:43:43 +0400 Subject: =?UTF-8?B?UmVbMl06INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114025401.GF25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> Message-ID: <332296434.20130114134343@softsearch.ru> Здравствуйте, Maxim. >> Включил на проксирующем nginx-е директиву >> proxy_method GET; >> и он стал слать кривые запросы вида: >> GET/94/82/38294/5/4858305/789797.gif HTTP/1.0 >> >> Т.е. после GET пробел пропал. > Это фича, надо писать > proxy_method "GET "; Ясно. А я уж настроился ждать багфикса :-) Фича тут http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_method совсем не описана, однако. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Mon Jan 14 11:04:45 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 15:04:45 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <332296434.20130114134343@softsearch.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> Message-ID: <20130114110445.GM25043@mdounin.ru> Hello! On Mon, Jan 14, 2013 at 01:43:43PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> Включил на проксирующем nginx-е директиву > >> proxy_method GET; > >> и он стал слать кривые запросы вида: > >> GET/94/82/38294/5/4858305/789797.gif HTTP/1.0 > >> > >> Т.е. после GET пробел пропал. > > > Это фича, надо писать > > > proxy_method "GET "; > > Ясно. А я уж настроился ждать багфикса :-) > > Фича тут > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_method > совсем не описана, однако. Надо описать, да. Это баг во документации. :) -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Mon Jan 14 11:23:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 15:23:07 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114110445.GM25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> Message-ID: <20130114112306.GP25043@mdounin.ru> Hello! On Mon, Jan 14, 2013 at 03:04:45PM +0400, Maxim Dounin wrote: > Hello! > > On Mon, Jan 14, 2013 at 01:43:43PM +0400, Михаил Монашёв wrote: > > > Здравствуйте, Maxim. > > > > >> Включил на проксирующем nginx-е директиву > > >> proxy_method GET; > > >> и он стал слать кривые запросы вида: > > >> GET/94/82/38294/5/4858305/789797.gif HTTP/1.0 > > >> > > >> Т.е. после GET пробел пропал. > > > > > Это фича, надо писать > > > > > proxy_method "GET "; > > > > Ясно. А я уж настроился ждать багфикса :-) > > > > Фича тут > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_method > > совсем не описана, однако. > > Надо описать, да. Это баг во документации. :) А, нет, вру, должно быть всё нормально и без пробела, это действительно бага. У тебя proxy_method задан на уровне http{}, да? -- Maxim Dounin http://nginx.com/support.html From postmaster at softsearch.ru Mon Jan 14 11:28:32 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 14 Jan 2013 15:28:32 +0400 Subject: =?UTF-8?B?UmVbMl06INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114112306.GP25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> Message-ID: <801495053.20130114152832@softsearch.ru> Здравствуйте, Maxim. > А, нет, вру, должно быть всё нормально и без пробела, это > действительно бага. > У тебя proxy_method задан на уровне http{}, да? Да, на уровне http{}. -- С уважением, Михаил mailto:postmaster at softsearch.ru From chipitsine at gmail.com Mon Jan 14 12:41:16 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 14 Jan 2013 17:41:16 +0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/QviDQutGD0LrQsNC8INC00Ls=?= =?UTF-8?B?0Y8g0LPQvtGB0YLQtdC5INGE0L7RgNGD0LzQsCDQvdCwIElQQiAoSW52aXNp?= =?UTF-8?B?b24gUG93ZXIgQm9hcmQp?= In-Reply-To: References: Message-ID: поисковые роботы игнорируют куки, хотите попасть в поисковики в виде в таком виде )) ? 10 января 2013 г., 11:37 пользователь daitepiva написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > посмотрите в сторону APC (http://pecl.php.net/package/APC). за счет > > кеширования статики вы много не выиграете (если вообще что-то > > выиграете), а > > эффективность от php-кешей в подобных случаях обычно лучше, чем лепить > > костыли на nginx-е. > > > > Статика (картинки) выдаются nginx-ом напрямую, не с бэк-енда. > APC стоит, его поддержка в движке включена. Хитов 100%. Но он кеширует не > то, что мне нужно в данном случае. Мне нужно кеширование динамического > контента, чтобы разгрузить бэк-енд. Иногда случаются выплески количества > гостей (в том числе и ДДоС-атаки) и это приводит к большому количеству > запросов в БД и отказу от обслуживания. Логично было бы отделить гостей от > пользователей и выдать им закешированную страницу, что намного облегчит > жизнь бэк-енда и БД в случае наплыва гостей. > > Меня больше интересует правильность моей настройки кеширования с точки > зрения nginx-а, если всё правильно, то значит есть какие-то непонятые мной > тонкости в работе движка, ну или протокола http. Размышляю я просто - если > в > запросе клиента нет (или равны нулю) куки, которые отличают пользователя от > гостя, то ответ от бэк-енда закешировать (на 1 минуту) и выдавать его из > кеша всем другим гостям. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,234824,234871#msg-234871 > > _______________________________________________ > 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 14 12:46:17 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 16:46:17 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <801495053.20130114152832@softsearch.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> Message-ID: <20130114124616.GS25043@mdounin.ru> Hello! On Mon, Jan 14, 2013 at 03:28:32PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > А, нет, вру, должно быть всё нормально и без пробела, это > > действительно бага. > > > У тебя proxy_method задан на уровне http{}, да? > > Да, на уровне http{}. Патч. # HG changeset patch # User Maxim Dounin # Date 1358167486 -14400 # Node ID d94906442d522529b6daf9c955cdb9a264755979 # Parent 13c4c155f26f772b0bc1074a05298088d6499218 Proxy: fixed proxy_method to always add space. Before the patch if proxy_method was specified at http{} level the code to add trailing space wasn't executed, resulting in incorrect requests to upstream. diff --git a/src/http/modules/ngx_http_proxy_module.c b/src/http/modules/ngx_http_proxy_module.c --- a/src/http/modules/ngx_http_proxy_module.c +++ b/src/http/modules/ngx_http_proxy_module.c @@ -2353,7 +2353,7 @@ ngx_http_proxy_create_loc_conf(ngx_conf_ * conf->upstream.store_lengths = NULL; * conf->upstream.store_values = NULL; * - * conf->method = NULL; + * conf->method = { 0, NULL }; * conf->headers_source = NULL; * conf->headers_set_len = NULL; * conf->headers_set = NULL; @@ -2652,10 +2652,11 @@ ngx_http_proxy_merge_loc_conf(ngx_conf_t #endif - if (conf->method.len == 0) { - conf->method = prev->method; - - } else { + ngx_conf_merge_str_value(conf->method, prev->method, ""); + + if (conf->method.len + && conf->method.data[conf->method.len - 1] != ' ') + { conf->method.data[conf->method.len] = ' '; conf->method.len++; } -- Maxim Dounin http://nginx.com/support.html From scroitor at gmail.com Mon Jan 14 12:58:11 2013 From: scroitor at gmail.com (Sergey Croitor) Date: Mon, 14 Jan 2013 14:58:11 +0200 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHVyaSDRgSDQsNGA0LPRg9C80LXQvdGC0LDQvNC4INCy0Lo=?= =?UTF-8?B?0LvRjtGH0LjRgtC10LvRjNC90L4=?= In-Reply-To: <1291628882.20130114113412@mtu-net.ru> References: <1291628882.20130114113412@mtu-net.ru> Message-ID: Прежде чем надеяться, я плотно мониторил логи в течение месяца где-то. В данном конкретном случае роботы не балуют и используют именно этот паттерн ничего не переставляя. То есть, буде такая возможность для location, то оно решило бы проблему. И по моему опыту, роботы если и переставляют/добавляют к урлу параметры, то только от кривого кода в html или комбинируя всякие чекбоксы и селект боксы. Ну а если какой лихой робот и переставил бы, то и фиг с ним(в моем случае). 99% этих бесполезных запросов nginx бы отдал из кэша и одному из PHP и этим бы решил проблему. Но видимо не судьба. Насколько я понял, это решаемо только путем предварительного вычисления условий с помощью perl_set внутри общего location. Пока отщелкиваю подобные запросы от ботов на бэкенде, как это не прискорбно. 2013/1/14 Andrey Repin > SC> Пытаюсь организовать кэширование страниц с uri начинающегося со > следующих > SC> символов: > SC> /index.php?main_page=nocachedajax&q=savelocation > > Боюсь вас разочаровать, но для URL'ов в таком виде многие роботы частенько > переставляют параметры запроса, как им угодно, так что на выполнение > условия > "начинается с" я бы на вашем месте надеяться не стал. > > SC> Надо сделать это только для роботов > > SC> Поначалу была мысль сделать так: > > SC> location /index.php?main_page=nocachedajax&q=savelocation { > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hell-for-yahoo at umail.ru Mon Jan 14 13:59:54 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 14 Jan 2013 17:59:54 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114124616.GS25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> Message-ID: <109559121.20130114175954@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! >> Здравствуйте, Maxim. >> >> > А, нет, вру, должно быть всё нормально и без пробела, это >> > действительно бага. >> >> > У тебя proxy_method задан на уровне http{}, да? >> >> Да, на уровне http{}. MD> Патч. Неправильный патч. Правильно будет делать trim() и добавлять пробел всегда. MD> # HG changeset patch MD> # User Maxim Dounin MD> # Date 1358167486 -14400 MD> # Node ID d94906442d522529b6daf9c955cdb9a264755979 MD> # Parent 13c4c155f26f772b0bc1074a05298088d6499218 MD> Proxy: fixed proxy_method to always add space. MD> Before the patch if proxy_method was specified at http{} level the code MD> to add trailing space wasn't executed, resulting in incorrect requests MD> to upstream. MD> diff --git a/src/http/modules/ngx_http_proxy_module.c b/src/http/modules/ngx_http_proxy_module.c MD> --- a/src/http/modules/ngx_http_proxy_module.c MD> +++ b/src/http/modules/ngx_http_proxy_module.c MD> @@ -2353,7 +2353,7 @@ ngx_http_proxy_create_loc_conf(ngx_conf_ MD> * conf->upstream.store_lengths = NULL; MD> * conf->upstream.store_values = NULL; MD> * - * conf->>method = NULL; + * conf->>method = { 0, NULL }; MD> * conf->headers_source = NULL; MD> * conf->headers_set_len = NULL; MD> * conf->headers_set = NULL; MD> @@ -2652,10 +2652,11 @@ ngx_http_proxy_merge_loc_conf(ngx_conf_t MD> #endif - if (conf->>method.len == 0) { - conf->>method = prev->method; MD> - MD> - } else { MD> + ngx_conf_merge_str_value(conf->method, prev->method, ""); MD> + + if (conf->>method.len + && conf->>method.data[conf->method.len - 1] != ' ') MD> + { MD> conf->method.data[conf->method.len] = ' '; MD> conf->method.len++; MD> } -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 14.01.2013, <17:59> From vadim.lazovskiy at gmail.com Mon Jan 14 14:11:41 2013 From: vadim.lazovskiy at gmail.com (=?KOI8-R?B?98HEyc0g7MHaz9fTy8nK?=) Date: Mon, 14 Jan 2013 18:11:41 +0400 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHVyaSDRgSDQsNGA0LPRg9C80LXQvdGC0LDQvNC4INCy0Lo=?= =?UTF-8?B?0LvRjtGH0LjRgtC10LvRjNC90L4=?= In-Reply-To: References: <1291628882.20130114113412@mtu-net.ru> Message-ID: Здравствуйте. Должен ли кэшироваться ответ от index.php c другими аргументами? Если да, то по какому ключу? 14 января 2013 г., 16:58 пользователь Sergey Croitor написал: > Прежде чем надеяться, я плотно мониторил логи в течение месяца где-то. > В данном конкретном случае роботы не балуют и используют именно этот > паттерн ничего не переставляя. > То есть, буде такая возможность для location, то оно решило бы проблему. > И по моему опыту, роботы если и переставляют/добавляют к урлу параметры, > то только от кривого кода в html или комбинируя всякие чекбоксы и селект > боксы. > Ну а если какой лихой робот и переставил бы, то и фиг с ним(в моем > случае). > 99% этих бесполезных запросов nginx бы отдал из кэша и одному из PHP и > этим бы решил проблему. > Но видимо не судьба. > Насколько я понял, это решаемо только путем предварительного вычисления > условий с помощью perl_set внутри общего location. > Пока отщелкиваю подобные запросы от ботов на бэкенде, как это не > прискорбно. > > 2013/1/14 Andrey Repin > >> SC> Пытаюсь организовать кэширование страниц с uri начинающегося со >> следующих >> SC> символов: >> SC> /index.php?main_page=nocachedajax&q=savelocation >> >> Боюсь вас разочаровать, но для URL'ов в таком виде многие роботы частенько >> переставляют параметры запроса, как им угодно, так что на выполнение >> условия >> "начинается с" я бы на вашем месте надеяться не стал. >> >> SC> Надо сделать это только для роботов >> >> SC> Поначалу была мысль сделать так: >> >> SC> location /index.php?main_page=nocachedajax&q=savelocation { >> > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Jan 14 14:24:27 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 18:24:27 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <109559121.20130114175954@mtu-net.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> Message-ID: <20130114142427.GZ25043@mdounin.ru> Hello! On Mon, Jan 14, 2013 at 05:59:54PM +0400, Andrey Repin wrote: > Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! > > >> Здравствуйте, Maxim. > >> > >> > А, нет, вру, должно быть всё нормально и без пробела, это > >> > действительно бага. > >> > >> > У тебя proxy_method задан на уровне http{}, да? > >> > >> Да, на уровне http{}. > > MD> Патч. > > Неправильный патч. > Правильно будет делать trim() и добавлять пробел всегда. А не по^Wвсё ли равно? Цель схлопнуть несколько пробелов в один, если их там вдруг больше одного, мне представляется старнной и малоосмысленной. Пробел - разделитель, сколько их там будет, если пользователь написал в конфиге метод с пробелами - неважно. -- Maxim Dounin http://nginx.com/support.html From gmm at csdoc.com Mon Jan 14 14:50:52 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 14 Jan 2013 16:50:52 +0200 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114142427.GZ25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> <20130114142427.GZ25043@mdounin.ru> Message-ID: <50F41B4C.5040006@csdoc.com> On 14.01.2013 16:24, Maxim Dounin wrote: >>>>> А, нет, вру, должно быть всё нормально и без пробела, это >>>>> действительно бага. >>>> >>>>> У тебя proxy_method задан на уровне http{}, да? >>>> >>>> Да, на уровне http{}. >> >> MD> Патч. >> >> Неправильный патч. >> Правильно будет делать trim() и добавлять пробел всегда. > А не по^Wвсё ли равно? Цель схлопнуть несколько пробелов в один, > если их там вдруг больше одного, мне представляется старнной и > малоосмысленной. Пробел - разделитель, сколько их там будет, если > пользователь написал в конфиге метод с пробелами - неважно. никто не может гарантировать, что все http backend`ы будут правильно работать, если вместо ожидаемого ими одного пробела придет несколько. да и просто - некрасиво, что в этом месте nginx будет нарушать RFC. http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1 Request-Line = Method SP Request-URI SP HTTP-Version CRLF SP = P.S. кроме того, http://en.wikipedia.org/wiki/Robustness_principle -- Best regards, Gena From nginx-forum at nginx.us Mon Jan 14 07:51:06 2013 From: nginx-forum at nginx.us (shambler81) Date: Mon, 14 Jan 2013 02:51:06 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <587304c630b7882dcbf375e49eadaee8.NginxMailingListRussian@forum.nginx.org> ок спасибо попробуем Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,235029#msg-235029 From nginx-forum at nginx.us Mon Jan 14 08:05:27 2013 From: nginx-forum at nginx.us (shambler81) Date: Mon, 14 Jan 2013 03:05:27 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: <666775f9afc15c681c8edd56c3179d16.NginxMailingListRussian@forum.nginx.org> Подскажите пожалуйста будет ли работать мой старый конфиг? Поскольку сейчас на сервере ужп более 100 сайтов и перекину еще около 50 Проблема с обновлением смущяет толькоо в этом. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,235030#msg-235030 From postmaster at softsearch.ru Mon Jan 14 15:04:27 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 14 Jan 2013 19:04:27 +0400 Subject: =?UTF-8?B?UmVbMl06INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114142427.GZ25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> <20130114142427.GZ25043@mdounin.ru> Message-ID: <569705687.20130114190427@softsearch.ru> Здравствуйте, Maxim. >> >> > А, нет, вру, должно быть всё нормально и без пробела, это >> >> > действительно бага. >> >> >> >> > У тебя proxy_method задан на уровне http{}, да? >> >> >> >> Да, на уровне http{}. >> >> MD> Патч. >> >> Неправильный патч. >> Правильно будет делать trim() и добавлять пробел всегда. > А не по^Wвсё ли равно? Цель схлопнуть несколько пробелов в один, > если их там вдруг больше одного, мне представляется старнной и > малоосмысленной. Пробел - разделитель, сколько их там будет, если > пользователь написал в конфиге метод с пробелами - неважно. Мне подсознательно казалось, что писать proxy_method GET; правильно А писать proxy_method "GET "; или proxy_method OLOLO; не правильно. Т.е. должна быть проверка, что указан метод из RFC без каких либо дополнительных символов, а не произвольная строка. Хотя, конечно, произвольная строка - это большая гибкость. -- С уважением, Михаил mailto:postmaster at softsearch.ru From scroitor at gmail.com Mon Jan 14 15:05:48 2013 From: scroitor at gmail.com (Sergey Croitor) Date: Mon, 14 Jan 2013 17:05:48 +0200 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHVyaSDRgSDQsNGA0LPRg9C80LXQvdGC0LDQvNC4INCy0Lo=?= =?UTF-8?B?0LvRjtGH0LjRgtC10LvRjNC90L4=?= In-Reply-To: References: <1291628882.20130114113412@mtu-net.ru> Message-ID: Здравствуйте Вадим, да, должен. В основном все кэшируется, кроме исключений. Вот урезанная location секция из текущего nginx конфига: location / { proxy_pass http://backend; proxy_cache cache; proxy_cache_valid 200 302 304 180m; proxy_cache_valid any 1s; proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; proxy_hide_header "Set-Cookie"; proxy_ignore_headers "Cache-Control" "Expires"; add_header Cache-Control private; expires 180m; include /etc/nginx/proxy.conf; if ($request_uri = /index.php?main_page=accountbox) { return 412; } # еще штук 20 подобных ($request_uri = /index.php?...) отсылок на на бэкенд if ($arg_main_page = nocachedajax) { return 412; } # еще штук 10 подобных ($arg_xxx = /yyy) отсылок на на бэкенд if ($request_method = POST ) { return 412; } error_page 412 = @fallback; error_page 413 = @longcache; } location @fallback { proxy_cache off; proxy_pass http://backend; include /etc/nginx/proxy.conf; expires off; } то есть кэшируется все, за рядом исключений. Строка для создания ключа включает в себя не нормализованный $request_uri Еще раз повторю, что надо: есть ряд запросов, которые НЕ надо кэшировать для обычных пользователей и наоборот надо для роботов. Например: 1) имя пользователя/статус shopping cart вверху страницы не надо кэшировать для пользователей и надо для роботов (пусть хоть пустой ответ им идет - им по барабану) 2) запрос "/index.php?main_page=nocachedajax&q=savelocation" пишет в сессию урл последней странички и отдает пустую строку. для пользователя его НЕ надо кэшировать, а для роботов нужно(поскольку не нужно для них хранить последний урл в сессии). 2013/1/14 Вадим Лазовский > Здравствуйте. > > Должен ли кэшироваться ответ от index.php c другими аргументами? Если да, > то по какому ключу? > > > 14 января 2013 г., 16:58 пользователь Sergey Croitor написал: > >> Прежде чем надеяться, я плотно мониторил логи в течение месяца где-то. >> В данном конкретном случае роботы не балуют и используют именно этот >> паттерн ничего не переставляя. >> То есть, буде такая возможность для location, то оно решило бы проблему. >> И по моему опыту, роботы если и переставляют/добавляют к урлу параметры, >> то только от кривого кода в html или комбинируя всякие чекбоксы и селект >> боксы. >> Ну а если какой лихой робот и переставил бы, то и фиг с ним(в моем >> случае). >> 99% этих бесполезных запросов nginx бы отдал из кэша и одному из PHP и >> этим бы решил проблему. >> Но видимо не судьба. >> Насколько я понял, это решаемо только путем предварительного вычисления >> условий с помощью perl_set внутри общего location. >> Пока отщелкиваю подобные запросы от ботов на бэкенде, как это не >> прискорбно. >> >> 2013/1/14 Andrey Repin >> >>> SC> Пытаюсь организовать кэширование страниц с uri начинающегося со >>> следующих >>> SC> символов: >>> SC> /index.php?main_page=nocachedajax&q=savelocation >>> >>> Боюсь вас разочаровать, но для URL'ов в таком виде многие роботы >>> частенько >>> переставляют параметры запроса, как им угодно, так что на выполнение >>> условия >>> "начинается с" я бы на вашем месте надеяться не стал. >>> >>> SC> Надо сделать это только для роботов >>> >>> SC> Поначалу была мысль сделать так: >>> >>> SC> location /index.php?main_page=nocachedajax&q=savelocation { >>> >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > Best Regards, > Vadim Lazovskiy > > _______________________________________________ > 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 14 15:07:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 19:07:33 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <50F41B4C.5040006@csdoc.com> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> <20130114142427.GZ25043@mdounin.ru> <50F41B4C.5040006@csdoc.com> Message-ID: <20130114150733.GA25043@mdounin.ru> Hello! On Mon, Jan 14, 2013 at 04:50:52PM +0200, Gena Makhomed wrote: > On 14.01.2013 16:24, Maxim Dounin wrote: > > >>>>>А, нет, вру, должно быть всё нормально и без пробела, это > >>>>>действительно бага. > >>>> > >>>>>У тебя proxy_method задан на уровне http{}, да? > >>>> > >>>>Да, на уровне http{}. > >> > >>MD> Патч. > >> > >>Неправильный патч. > >>Правильно будет делать trim() и добавлять пробел всегда. > > >А не по^Wвсё ли равно? Цель схлопнуть несколько пробелов в один, > >если их там вдруг больше одного, мне представляется старнной и > >малоосмысленной. Пробел - разделитель, сколько их там будет, если > >пользователь написал в конфиге метод с пробелами - неважно. > > никто не может гарантировать, что все http backend`ы будут правильно > работать, если вместо ожидаемого ими одного пробела придет > несколько. Для этого надо явно написать более одного пробела в конфиге, что как бы позволяет предположить, что пользователь этого действительно хотел. > да и просто - некрасиво, что в этом месте nginx будет нарушать RFC. > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1 > > Request-Line = Method SP Request-URI SP HTTP-Version CRLF > > SP = > > P.S. кроме того, http://en.wikipedia.org/wiki/Robustness_principle Читать про "implied *LWS" там тут: http://tools.ietf.org/html/rfc2616#section-2.1 Несколько пробелов - это допустимо. -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Mon Jan 14 15:12:11 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2013 19:12:11 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <569705687.20130114190427@softsearch.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> <20130114142427.GZ25043@mdounin.ru> <569705687.20130114190427@softsearch.ru> Message-ID: <20130114151211.GB25043@mdounin.ru> Hello! On Mon, Jan 14, 2013 at 07:04:27PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> >> > А, нет, вру, должно быть всё нормально и без пробела, это > >> >> > действительно бага. > >> >> > >> >> > У тебя proxy_method задан на уровне http{}, да? > >> >> > >> >> Да, на уровне http{}. > >> > >> MD> Патч. > >> > >> Неправильный патч. > >> Правильно будет делать trim() и добавлять пробел всегда. > > > А не по^Wвсё ли равно? Цель схлопнуть несколько пробелов в один, > > если их там вдруг больше одного, мне представляется старнной и > > малоосмысленной. Пробел - разделитель, сколько их там будет, если > > пользователь написал в конфиге метод с пробелами - неважно. > > Мне подсознательно казалось, что писать > proxy_method GET; > правильно > > А писать > proxy_method "GET "; > или > proxy_method OLOLO; > не правильно. Т.е. должна быть проверка, что указан метод из RFC без > каких либо дополнительных символов, а не произвольная строка. Хотя, > конечно, произвольная строка - это большая гибкость. Нет, разрешать методы только из RFC - это однозначно плохая идея, т.к. зарежет всё, чего сейчас в RFC нет, а по факту - есть (или завтра появится). -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Mon Jan 14 15:14:27 2013 From: nginx-forum at nginx.us (scroitor) Date: Mon, 14 Jan 2013 10:14:27 -0500 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHVyaSDRgSDQsNGA0LPRg9C80LXQvdGC0LDQvNC4INCy0Lo=?= =?UTF-8?B?0LvRjtGH0LjRgtC10LvRjNC90L4=?= In-Reply-To: References: Message-ID: <9b24a08abd60643f3fb34bca75e67130.NginxMailingListRussian@forum.nginx.org> Забыл еще раз уточнить: особенность кэширования подобных запросов в том, чтобы отдавать одну и ту же закэшированную страницу. Поэтому я и хотел в ключе для подобных запросов использовать не |$request_uri, а |_page_type_ чтобы не плодить кучу одинаковых ответов в кэше Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234977,235056#msg-235056 From vovansystems at gmail.com Mon Jan 14 16:32:36 2013 From: vovansystems at gmail.com (VovansystemS) Date: Mon, 14 Jan 2013 19:32:36 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: <666775f9afc15c681c8edd56c3179d16.NginxMailingListRussian@forum.nginx.org> References: <666775f9afc15c681c8edd56c3179d16.NginxMailingListRussian@forum.nginx.org> Message-ID: > Подскажите пожалуйста будет ли работать мой старый конфиг? нет, сразу не будет, но если сделать nginx -t то можно будет почитать что надо исправить, а такого там не очень много. Навскидку могу сказать, что в старом конфиге нужно будет писать listen 80 default_server; вместо listen 80 default; остальное, не должно вызвать проблем. можете установить новый nginx себе на компьютер и протестировать со старым конфигом, чтобы заранее определить какие исправления внести. http://nginx.org/ru/download.html здесь можно скачать nginx даже под windows! главное чтобы "новый! конфиг работал так, как это нужно Вам :) From nginx-forum at nginx.us Mon Jan 14 17:01:09 2013 From: nginx-forum at nginx.us (shambler81) Date: Mon, 14 Jan 2013 12:01:09 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: Отличаня идеяю протестирую на старом сервере ;) Подскажите еще пожалуйста один вопрос не могу к ниму никак подобраться 1. Алиасы, как быть с ними в nginx он веддь не пропустит их из apache он же начнет их искать как сайты. А главное в этом нет алгоритма и если с потеряными файлами все еще понятно то кака автоматически выхватывать алиасы ;( ? может прийдет что на ум. У меня только грепать все файлы конфига апача искать в каком конфиге подставлять его имя и тд. Может есть что то попроще ? 2. Если у сайта явно указан ip естественно они как правило толко для тестов сайтов еще не имеющих имен фактически технические имена. Они очень удобно даются в админке и очень удобно пользоваться. Опять же могут быть присвоены любому сайту. Если можно хотябы в кратце есть ли смысл где то искать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,235062#msg-235062 From nginx-forum at nginx.us Mon Jan 14 17:51:00 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 12:51:00 -0500 Subject: =?UTF-8?B?bGltaXQgcmF0ZSDQtNC70Y8gdXBzdHJlYW0=?= Message-ID: <413308ab6f6d61e7e6c7e6ef6c4de6a3.NginxMailingListRussian@forum.nginx.org> А есть ли / будет ли аналог limit_rate для апстримов? А то логично делать широкие каналы на "последней миле" и узкие - на внутренних коммуникациях, потому как при нормальном кешировании оконечные узлы отдают во много раз больше чем забирают от вышестоящих. Но при этом сейчас какой-то из "внешних" серверов может запросто забить канал к апстриму запросом жирного файла и у остальных при этом начнуться проблемы. При том что среднее потребление канала все равно останется минимальным. PS. В моем случае еще не было вариантов, чтоб скорость "внешний сервер"-клиент составляла хотябы 1/3 от скорости "внешний сервер"-апстрим. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235064,235064#msg-235064 From nginx-forum at nginx.us Mon Jan 14 17:54:21 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 12:54:21 -0500 Subject: =?UTF-8?B?cHJveHkgY2FjaGUg0L3QtSDRgNCw0LHQvtGC0LDQtdGCINC/0YDQuCBwcm94eSBi?= =?UTF-8?B?dWZmZXJpbmc9b2Zm?= Message-ID: <4a248357c2f8bdb0ba626e3ba12e2fa7.NginxMailingListRussian@forum.nginx.org> Кеширование не работает при отключении proxy_buffering. Это так и должно быть или я что-то не понимаю? nginx version: nginx/1.2.6 built by gcc 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) TLS SNI support enabled configure arguments: --prefix=/usr/ --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/lib/nginx/tmp/ --http-proxy-temp-path=/var/lib/nginx/proxy/ --http-fastcgi-temp-path=/var/lib/nginx/fastcgi/ --http-uwsgi-temp-path=/var/lib/nginx/uwsgi/ --http-scgi-temp-path=/var/lib/nginx/scgi/ --user=nginx --group=nginx --with-rtsig_module --with-select_module --with-poll_module --with-ipv6 --with-file-aio --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_perl_module --with-perl=/usr/bin/perl --with-mail --with-mail_ssl_module --with-pcre --with-pcre-jit --with-libatomic --with-md5=/usr --with-sha1=/usr --with-cc-opt='-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fstack-protector' (сборка своя, по мотивам OpenSUSE) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235065,235065#msg-235065 From nginx-forum at nginx.us Mon Jan 14 17:59:49 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 12:59:49 -0500 Subject: =?UTF-8?B?0KfRgtC+LdGC0L4g0YLQuNC/0LAgY2FjaGUgZGIg0L/Qu9Cw0L3QuNGA0YPQtdGC?= =?UTF-8?B?0YHRjz8=?= Message-ID: <3864fdba29483134b4ff4cf0dc155116.NginxMailingListRussian@forum.nginx.org> Будет ли возможность передавать между серверами список закешированных объектов, для оптимального выбора upstream. А еще лучше тоже самое для sibling, если их существование планируется (для оперативного обмена информацией о кешированных объектах на одном уровне). И еще. Существует ли какая-то защита от закольцевания запросов при сложной топологии серверов? (Вроде cache_peer_access в squid) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235066,235066#msg-235066 From vbart at nginx.com Mon Jan 14 18:21:04 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 14 Jan 2013 22:21:04 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlICDQvdC1INGA0LDQsdC+0YLQsNC10YIg0L/RgNC4IHBy?= =?UTF-8?B?b3h5IGJ1ZmZlcmluZz1vZmY=?= In-Reply-To: <4a248357c2f8bdb0ba626e3ba12e2fa7.NginxMailingListRussian@forum.nginx.org> References: <4a248357c2f8bdb0ba626e3ba12e2fa7.NginxMailingListRussian@forum.nginx.org> Message-ID: <201301142221.04539.vbart@nginx.com> On Monday 14 January 2013 21:54:21 Trurl wrote: > Кеширование не работает при отключении proxy_buffering. > Это так и должно быть или я что-то не понимаю? > Так и должно быть. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html > > nginx version: nginx/1.2.6 > built by gcc 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) > TLS SNI support enabled > configure arguments: --prefix=/usr/ --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/lib/nginx/tmp/ > --http-proxy-temp-path=/var/lib/nginx/proxy/ > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi/ > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi/ > --http-scgi-temp-path=/var/lib/nginx/scgi/ --user=nginx --group=nginx > --with-rtsig_module --with-select_module --with-poll_module --with-ipv6 > --with-file-aio --with-http_ssl_module --with-http_realip_module > --with-http_addition_module --with-http_xslt_module > --with-http_image_filter_module --with-http_geoip_module > --with-http_flv_module --with-http_mp4_module > --with-http_gzip_static_module --with-http_random_index_module > --with-http_secure_link_module > --with-http_stub_status_module --with-http_perl_module > --with-perl=/usr/bin/perl --with-mail --with-mail_ssl_module --with-pcre > --with-pcre-jit --with-libatomic --with-md5=/usr --with-sha1=/usr > --with-cc-opt='-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables > -fstack-protector' > (сборка своя, по мотивам OpenSUSE) > From vovansystems at gmail.com Mon Jan 14 18:32:05 2013 From: vovansystems at gmail.com (VovansystemS) Date: Mon, 14 Jan 2013 21:32:05 +0300 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: > 1. Алиасы, как быть с ними в nginx он веддь не пропустит их из apache он же > начнет их искать как сайты. > А главное в этом нет алгоритма и если с потеряными файлами все еще понятно > то кака автоматически выхватывать алиасы ;( ? может прийдет что на ум. У > меня только грепать все файлы конфига апача искать в каком конфиге > подставлять его имя и тд. Может есть что то попроще ? да, с таким конфигам как выше данный блок server будет обрабатывать только сайты вида foldername.com и www.foldername.com. Напомню, что изначально вопрос про элиасы не ставился :) А подробнее.. Ну на всех моих проектах и проектах клиентов элиасы являются всего-лишь редиректами на основной домен. Если это так и в Вашем случае, то если сайтов с элиасами мало, можно для каждого из них создать отдельный сервер вида: server { server_name www2.site.ru www3.site.ru mysupersiteco.uk; return 301 $scheme://site.ru$request_uri$is_args$args; } Если же таких сайтов много, то надо воспользоваться модулем map и создать общий сервер для элиасов. > 2. Если у сайта явно указан ip естественно они как правило толко для тестов > сайтов еще не имеющих имен фактически технические имена. > Они очень удобно даются в админке и очень удобно пользоваться. Опять же > могут быть присвоены любому сайту. не совсем понял что требуется ) Если вопрос: как сделать так, чтобы сайт открывался, когда в адресную строку вводишь ip адрес сервера, то ответ простой. Нужно указать в server_name ip адрес. http://nginx.org/ru/docs/http/server_names.html#miscellaneous_names From vadim.lazovskiy at gmail.com Mon Jan 14 18:41:32 2013 From: vadim.lazovskiy at gmail.com (=?KOI8-R?B?98HEyc0g7MHaz9fTy8nK?=) Date: Mon, 14 Jan 2013 22:41:32 +0400 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHVyaSDRgSDQsNGA0LPRg9C80LXQvdGC0LDQvNC4INCy0Lo=?= =?UTF-8?B?0LvRjtGH0LjRgtC10LvRjNC90L4=?= In-Reply-To: References: <1291628882.20130114113412@mtu-net.ru> Message-ID: Попробовал смапить аргументы в $cache_key - не получилось, похоже map не умеет в качестве результата использовать более одной переменной. Как вариант перенаправлять запросы в именованный location по мапу: map $arg_main_page$arg_q $alternate_cache { nocachedajaxsavelocation 1; default 0; } в данном случае положения аргументов могут менятся на радость ботам - результат будет тот же. И: location / { ... error_page 418 = @alternate_cache; if ($alternate_cache) { return 418; } ... } location @alternate_cache { proxy_cache_key ...; } Также, рекомендую, по возможности, сгруппировать if-ы в map-ы. Благо они теперь и регулярные выражения и переменные в ключе и результате умеют. -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Mon Jan 14 19:57:10 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 14 Jan 2013 23:57:10 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUg0LTQu9GPIHVwc3RyZWFt?= In-Reply-To: <413308ab6f6d61e7e6c7e6ef6c4de6a3.NginxMailingListRussian@forum.nginx.org> References: <413308ab6f6d61e7e6c7e6ef6c4de6a3.NginxMailingListRussian@forum.nginx.org> Message-ID: <508449965.20130114235710@softsearch.ru> Здравствуйте, Trurl. > А есть ли / будет ли аналог limit_rate для апстримов? Сейчас можно на самом апстриме limit_rate включить. Или firewall использовать. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Mon Jan 14 20:10:17 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 00:10:17 +0400 Subject: =?UTF-8?B?UmU6INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90LjRgNGD?= =?UTF-8?B?0LXRgtGB0Y8/?= In-Reply-To: <3864fdba29483134b4ff4cf0dc155116.NginxMailingListRussian@forum.nginx.org> References: <3864fdba29483134b4ff4cf0dc155116.NginxMailingListRussian@forum.nginx.org> Message-ID: <12901108.20130115001017@softsearch.ru> Здравствуйте, Trurl. > Будет ли возможность передавать между серверами список закешированных > объектов, для оптимального выбора upstream. У меня этот список на одном сервере 2 гига размером, например. Не могу понять описываемую Вами схему. Если у Вас один фронтэнд и за ним несколько кэширующих серверов, то можно переделать так, чтобы субдомены, например, определяли сервер, кэширующий (и хранящий тоже) файл. Тогда в dns-е прописываете ip-шки этик субдоменов, указывающие на разные кэширующие сервера и всё. Если схему менять не хочется, то храните кэширующий сервер в куках или части урла, и если не вышло по ним определить, то обходите все кэширующие сервера. > А еще лучше тоже самое для sibling, если их существование планируется (для > оперативного обмена информацией о кешированных объектах на одном уровне). > И еще. Существует ли какая-то защита от закольцевания запросов при сложной > топологии серверов? (Вроде cache_peer_access в squid) Ну можно свои http-заголовки добавлять, менять урл, куки, есть встроенный перл для хитрых проверок... В комплексе с прямыми руками (не обязательно своими http://nginx.com/support.html ) всё это позволяет добиться ошеломляющих результатов. :-) P.S. Переходите от теории к практике. :-) -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Mon Jan 14 21:35:25 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 16:35:25 -0500 Subject: =?UTF-8?B?UmU6INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90LjRgNGD?= =?UTF-8?B?0LXRgtGB0Y8/?= In-Reply-To: <12901108.20130115001017@softsearch.ru> References: <12901108.20130115001017@softsearch.ru> Message-ID: <62eb90c58ff906fff85314ffa21982a9.NginxMailingListRussian@forum.nginx.org> У меня вообще одна голая практика... ферма (много апачей и не только их) живет в штатах, а узлы CDN раскиданы по Европе и все это под контролем ДНС с геобалансингом (+мониторинг состояния с отключением упавших узлов). Например две точки в Москве (на разных провайдерах) - между ними перекинуть видео весом в 2ГБ куда выгоднее чем тащить со штатов, учитывая что "внешний" траффик зачастую лимитируется, в отличии от проброса по М9/М10. Даже с Киевского узла его перегнать - и то на порядок выгоднее. > Ну можно свои http-заголовки добавлять, менять урл, куки, есть > встроенный перл для хитрых проверок... В комплексе с прямыми руками > (не обязательно своими http://nginx.com/support.html ) всё это > позволяет добиться ошеломляющих результатов. :-) Это все будет жрать ресурсы и тормозить... Когда на узел приходится до 20к запросов в минуту - это больно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235074,235077#msg-235077 From nginx-forum at nginx.us Mon Jan 14 21:39:44 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 16:39:44 -0500 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUg0LTQu9GPIHVwc3RyZWFt?= In-Reply-To: <508449965.20130114235710@softsearch.ru> References: <508449965.20130114235710@softsearch.ru> Message-ID: <89da07816ba450f8dc96820db78222fc.NginxMailingListRussian@forum.nginx.org> > Сейчас можно на самом апстриме limit_rate включить. Или firewall > использовать. ну у меня апстримом может быть и сквид и апач и даже lighttpd. да и если 7 апстримов (ферма) на одном узком канале - как лимитировать суммарный траффик? Делать bottleneck с раздачей с одного сервера не хочется почему-то. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235073,235078#msg-235078 From nginx-forum at nginx.us Mon Jan 14 21:46:22 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 16:46:22 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINC90LUg0YDQsNCx0L7RgtCw0LXRgiDQv9GA0LggcHJv?= =?UTF-8?B?eHkgYnVmZmVyaW5nPW9mZg==?= In-Reply-To: <201301142221.04539.vbart@nginx.com> References: <201301142221.04539.vbart@nginx.com> Message-ID: <32e769b1ffbd8fdc2ea49f4be1a29de3.NginxMailingListRussian@forum.nginx.org> > > Кеширование не работает при отключении proxy_buffering. > > Это так и должно быть или я что-то не понимаю? > > > > Так и должно быть. а как, в этом случае, ограничить общий размер proxy_temp_path ? например при proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=main_cache:1024m inactive=172800 max_size=4096m; proxy_temp_path /var/lib/nginx/proxy 1 2; proxy_temp_file_write_size 32k; proxy_max_temp_file_size 5m; папка /var/cache/nginx 3.0G а папка /var/lib/nginx/proxy - 28G (обе папки на одном диске, если что) и все это за сутки с чистого листа (контента на серверах вообще террабайты и половина его динамическая, но далеко не все эти террабайты популярны) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235068,235079#msg-235079 From vbart at nginx.com Mon Jan 14 22:11:07 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 15 Jan 2013 02:11:07 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlICDQvdC1INGA0LDQsdC+0YLQsNC10YIg0L/RgNC4IHBy?= =?UTF-8?B?b3h5IGJ1ZmZlcmluZz1vZmY=?= In-Reply-To: <32e769b1ffbd8fdc2ea49f4be1a29de3.NginxMailingListRussian@forum.nginx.org> References: <201301142221.04539.vbart@nginx.com> <32e769b1ffbd8fdc2ea49f4be1a29de3.NginxMailingListRussian@forum.nginx.org> Message-ID: <201301150211.07835.vbart@nginx.com> On Tuesday 15 January 2013 01:46:22 Trurl wrote: > > > Кеширование не работает при отключении proxy_buffering. > > > Это так и должно быть или я что-то не понимаю? > > > > Так и должно быть. > > а как, в этом случае, ограничить общий размер proxy_temp_path ? > proxy_buffering к этому не имеет никакого отношения. Этим занимается директива proxy_max_temp_file_size: http://nginx.org/r/proxy_max_temp_file_size/ru > например при > > proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=main_cache:1024m > inactive=172800 max_size=4096m; > proxy_temp_path /var/lib/nginx/proxy 1 2; > proxy_temp_file_write_size 32k; > proxy_max_temp_file_size 5m; > > папка /var/cache/nginx 3.0G > а папка /var/lib/nginx/proxy - 28G > (обе папки на одном диске, если что) > и все это за сутки с чистого листа > (контента на серверах вообще террабайты и половина его динамическая, но > далеко не все эти террабайты популярны) > 28Гб? Это не ошибка? Сколько у вас RPS к прокси и какой средний объем ответов? 28*1024/5 дает ~6000 одновременно обрабатываемых ответов объемом от 5Мб. Если у вас гораздо меньше, то явно что-то не в порядке. В error_log всё чисто? -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From maybe at arjlover.net Mon Jan 14 22:12:39 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 05:12:39 +0700 Subject: =?UTF-8?B?bWVtY2FjaGVkX3Bhc3Mg0L3QtSDQvNC+0LbQtdGCINCx0YvRgtGMIHVuaXggc29j?= =?UTF-8?B?a2V0Pw==?= Message-ID: Как-то неожиданно. Особенно с учетом того что мемкеш работает или или - не может слушать и порт и unix socket. При высоких оборотах что не делай, а tcp-сокеты забиваются, пришлось на unix socket переехать... -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maybe at arjlover.net Mon Jan 14 22:17:55 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 05:17:55 +0700 Subject: =?UTF-8?B?UmU6INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90LjRgNGD?= =?UTF-8?B?0LXRgtGB0Y8/?= In-Reply-To: <62eb90c58ff906fff85314ffa21982a9.NginxMailingListRussian@forum.nginx.org> References: <12901108.20130115001017@softsearch.ru> <62eb90c58ff906fff85314ffa21982a9.NginxMailingListRussian@forum.nginx.org> Message-ID: А Вы попробуйте - оно работает. 1м в час запросов - ничего фантастического. > Ну можно свои http-заголовки добавлять, менять урл, куки, есть > > встроенный перл для хитрых проверок... В комплексе с прямыми руками > > (не обязательно своими http://nginx.com/support.html ) всё это > > позволяет добиться ошеломляющих результатов. :-) > > Это все будет жрать ресурсы и тормозить... Когда на узел приходится до 20к > запросов в минуту - это больно. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Mon Jan 14 22:18:10 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 15 Jan 2013 02:18:10 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlICDQvdC1INGA0LDQsdC+0YLQsNC10YIg0L/RgNC4IHBy?= =?UTF-8?B?b3h5IGJ1ZmZlcmluZz1vZmY=?= In-Reply-To: <32e769b1ffbd8fdc2ea49f4be1a29de3.NginxMailingListRussian@forum.nginx.org> References: <201301142221.04539.vbart@nginx.com> <32e769b1ffbd8fdc2ea49f4be1a29de3.NginxMailingListRussian@forum.nginx.org> Message-ID: <201301150218.10123.vbart@nginx.com> On Tuesday 15 January 2013 01:46:22 Trurl wrote: > > > Кеширование не работает при отключении proxy_buffering. > > > Это так и должно быть или я что-то не понимаю? > > > > Так и должно быть. > > а как, в этом случае, ограничить общий размер proxy_temp_path ? > > например при > > proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=main_cache:1024m > inactive=172800 max_size=4096m; > proxy_temp_path /var/lib/nginx/proxy 1 2; > proxy_temp_file_write_size 32k; > proxy_max_temp_file_size 5m; > > папка /var/cache/nginx 3.0G > а папка /var/lib/nginx/proxy - 28G > (обе папки на одном диске, если что) > и все это за сутки с чистого листа > (контента на серверах вообще террабайты и половина его динамическая, но > далеко не все эти террабайты популярны) > Если у вас средний объем ответа значительно больше proxy_max_temp_file_size, то и смысла в нём нет, тогда стоит ставить proxy_max_temp_file_size 0; Я подозреваю, что именно это вы хотели, пытаясь выключить proxy_buffering. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From hell-for-yahoo at umail.ru Mon Jan 14 22:17:23 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Tue, 15 Jan 2013 02:17:23 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <569705687.20130114190427@softsearch.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> <20130114142427.GZ25043@mdounin.ru> <569705687.20130114190427@softsearch.ru> Message-ID: <632161139.20130115021723@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Михаил Монашёв! ММ> proxy_method OLOLO; ММ> не правильно. Т.е. должна быть проверка, что указан метод из RFC без ММ> каких либо дополнительных символов, а не произвольная строка. Хотя, ММ> конечно, произвольная строка - это большая гибкость. Не факт, что бэкэнд работает на каком-то известном nginx диалекте протокола. HTTP описан, как расширяемый протокол, и расширяемый в широких пределах смысла слова "расширение". Я так понимаю, что директива proxy_method как раз и предназначена для передачи бэкэнду запроса специальным методом, который не обязательно известен проксирующему серверу, но о деталях которого ему знать не обязательно. Достаточно, что формат сообщения соответствует основным правилам HHTP. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) вторник, 15.01.2013, <02:13> From hell-for-yahoo at umail.ru Mon Jan 14 22:12:47 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Tue, 15 Jan 2013 02:12:47 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114142427.GZ25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> <20130114142427.GZ25043@mdounin.ru> Message-ID: <1873254546.20130115021247@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! >> >> > А, нет, вру, должно быть всё нормально и без пробела, это >> >> > действительно бага. >> >> >> >> > У тебя proxy_method задан на уровне http{}, да? >> >> >> >> Да, на уровне http{}. >> >> MD> Патч. >> >> Неправильный патч. >> Правильно будет делать trim() и добавлять пробел всегда. MD> А не по^Wвсё ли равно? Не всё. Есть стандарты. Чем точнее ты им следуешь, тем меньше мест трубуется перепроверять. Я, например, с трудом продрался через код вашего патча, и мне помогло только то, что я знал, с чего всё началось. Это уже говорит о том, что "что-то здесь не так". MD> Цель схлопнуть несколько пробелов в один, MD> если их там вдруг больше одного, мне представляется старнной и MD> малоосмысленной. Пробел - разделитель, сколько их там будет, если MD> пользователь написал в конфиге метод с пробелами - неважно. В стандарте указан один пробел. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) вторник, 15.01.2013, <02:10> From panfilov at sports.ru Mon Jan 14 22:25:11 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Tue, 15 Jan 2013 02:25:11 +0400 Subject: =?UTF-8?B?UmU6INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90LjRgNGD?= =?UTF-8?B?0LXRgtGB0Y8/?= In-Reply-To: References: <12901108.20130115001017@softsearch.ru> <62eb90c58ff906fff85314ffa21982a9.NginxMailingListRussian@forum.nginx.org> Message-ID: В качестве костыльного решения похожей задачи я начал обдумывать upstream в haproxy. А в haproxy уже раскидывать запросы с опциональным выбором бекендов исходя из различных условий (заголовков или ещё чего, что выставит nginx). 15 января 2013 г., 2:17 пользователь Anton Kuznetsov написал: > А Вы попробуйте - оно работает. 1м в час запросов - ничего фантастического. > > > > Ну можно свои http-заголовки добавлять, менять урл, куки, есть >> > встроенный перл для хитрых проверок... В комплексе с прямыми руками >> > (не обязательно своими http://nginx.com/support.html ) всё это >> > позволяет добиться ошеломляющих результатов. :-) >> >> Это все будет жрать ресурсы и тормозить... Когда на узел приходится до 20к >> запросов в минуту - это больно. > > > _______________________________________________ > 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 vbart at nginx.com Mon Jan 14 22:38:13 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 15 Jan 2013 02:38:13 +0400 Subject: =?UTF-8?B?UmU6IG1lbWNhY2hlZF9wYXNzICDQvdC1INC80L7QttC10YIg0LHRi9GC0YwgdW5p?= =?UTF-8?B?eCBzb2NrZXQ/?= In-Reply-To: References: Message-ID: <201301150238.14102.vbart@nginx.com> On Tuesday 15 January 2013 02:12:39 Anton Kuznetsov wrote: > memcached_pass не может быть unix socket? Может. Но вообще, какой смысл в memcached на той же машине? Не проще ли кэш nginx-а использовать? -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From maybe at arjlover.net Mon Jan 14 22:44:17 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 05:44:17 +0700 Subject: =?UTF-8?B?UmU6IG1lbWNhY2hlZF9wYXNzINC90LUg0LzQvtC20LXRgiDQsdGL0YLRjCB1bml4?= =?UTF-8?B?IHNvY2tldD8=?= In-Reply-To: <201301150238.14102.vbart@nginx.com> References: <201301150238.14102.vbart@nginx.com> Message-ID: http://www.nginx.org/ru/docs/http/ngx_http_memcached_module.html#memcached_pass Пробел в документации? В других местах возможность использования unix socket всегда особо описана. Ну я раздумываю сделать что-то вроде set $memcached_key "ban_$remote_addr"; и привет.. Получится? Или это не самый простой способ сделать динамический бан с ограниченным временем жизни? -- Best regards, Anton Kuznetsov. 2013/1/15 Валентин Бартенев > On Tuesday 15 January 2013 02:12:39 Anton Kuznetsov wrote: > > memcached_pass не может быть unix socket? > > Может. Но вообще, какой смысл в memcached на той же машине? > Не проще ли кэш nginx-а использовать? > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Mon Jan 14 22:57:55 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 15 Jan 2013 02:57:55 +0400 Subject: =?UTF-8?B?UmU6IG1lbWNhY2hlZF9wYXNzICDQvdC1INC80L7QttC10YIg0LHRi9GC0YwgdW5p?= =?UTF-8?B?eCBzb2NrZXQ/?= In-Reply-To: References: <201301150238.14102.vbart@nginx.com> Message-ID: <201301150257.55544.vbart@nginx.com> On Tuesday 15 January 2013 02:44:17 Anton Kuznetsov wrote: > http://www.nginx.org/ru/docs/http/ngx_http_memcached_module.html#memcached_ > pass > > Пробел в документации? В других местах возможность использования unix > socket всегда особо описана. > Работа над документацией идет постоянно: http://trac.nginx.org/nginx/timeline?repo-nginx_org=on Ещё год назад она была совсем в плачевном состоянии, пока не добрались до этого места. Патчи в документацию и тикеты о пробелах в ней - приветствуются. > Ну я раздумываю сделать что-то вроде > > set $memcached_key "ban_$remote_addr"; > > и привет.. Получится? Или это не самый простой способ сделать динамический > бан с ограниченным временем жизни? > Если бан только по ip, то это не на 7-ом уровне решать нужно. А так, должно бы получиться. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Mon Jan 14 23:02:37 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 03:02:37 +0400 Subject: =?UTF-8?B?UmVbMl06INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90Lg=?= =?UTF-8?B?0YDRg9C10YLRgdGPPw==?= In-Reply-To: References: <12901108.20130115001017@softsearch.ru> <62eb90c58ff906fff85314ffa21982a9.NginxMailingListRussian@forum.nginx.org> Message-ID: <41907497.20130115030237@softsearch.ru> Здравствуйте, Михаил. > В качестве костыльного решения похожей задачи я начал обдумывать > upstream в haproxy. А в haproxy уже раскидывать запросы с > опциональным выбором бекендов исходя из различных условий > (заголовков или ещё чего, что выставит nginx). Человеку не нужны заголовки. Ему надо, чтобы всё было автоматически. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Tue Jan 15 00:57:36 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 19:57:36 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINC90LUg0YDQsNCx0L7RgtCw0LXRgiDQv9GA0LggcHJv?= =?UTF-8?B?eHkgYnVmZmVyaW5nPW9mZg==?= In-Reply-To: <201301150218.10123.vbart@nginx.com> References: <201301150218.10123.vbart@nginx.com> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > On Tuesday 15 January 2013 01:46:22 Trurl wrote: > > > > Кеширование не работает при отключении proxy_buffering. > > > > Это так и должно быть или я что-то не понимаю? > > > > > > Так и должно быть. > > > > а как, в этом случае, ограничить общий размер proxy_temp_path ? > > > > например при > > > > proxy_cache_path /var/cache/nginx levels=1:2 > keys_zone=main_cache:1024m > > inactive=172800 max_size=4096m; > > proxy_temp_path /var/lib/nginx/proxy 1 2; > > proxy_temp_file_write_size 32k; > > proxy_max_temp_file_size 5m; > > > > папка /var/cache/nginx 3.0G > > а папка /var/lib/nginx/proxy - 28G > > (обе папки на одном диске, если что) > > и все это за сутки с чистого листа > > (контента на серверах вообще террабайты и половина его динамическая, > но > > далеко не все эти террабайты популярны) > > > > Если у вас средний объем ответа значительно больше > proxy_max_temp_file_size, то > и смысла в нём нет, тогда стоит ставить proxy_max_temp_file_size 0; вообще-то средний как раз значительно меньше, но максимальный может за 2GB быть... Спасибо, попробую. > Я подозреваю, что именно это вы хотели, пытаясь выключить > proxy_buffering. нет, я пытался хоть как-то ограничить размеры папки proxy_temp_path Неужели это невозможно? > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235068,235102#msg-235102 From nginx-forum at nginx.us Tue Jan 15 01:08:45 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 14 Jan 2013 20:08:45 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINC90LUg0YDQsNCx0L7RgtCw0LXRgiDQv9GA0LggcHJv?= =?UTF-8?B?eHkgYnVmZmVyaW5nPW9mZg==?= In-Reply-To: References: <201301150218.10123.vbart@nginx.com> Message-ID: <9b35d3f1d3b46a73154845ae2c5c70e6.NginxMailingListRussian@forum.nginx.org> > > Если у вас средний объем ответа значительно больше > > proxy_max_temp_file_size, то > > и смысла в нём нет, тогда стоит ставить proxy_max_temp_file_size 0; > вообще-то средний как раз значительно меньше, но максимальный может за > 2GB быть... > Спасибо, попробую. > несколько непонятно как оно работает... в общем при "proxy_max_temp_file_size 0;" файлы там таки все равно создаются :) Но тут же исчезают (я так понимаю - перекочевывают в папку кеша) Что, в целом, вполне отлично. Еще раз спасибо Осталось только понять логику их вообще там существования при наличии кеша и proxy_max_temp_file_size отличном от нуля... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235068,235103#msg-235103 From postmaster at softsearch.ru Tue Jan 15 04:54:33 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 08:54:33 +0400 Subject: =?UTF-8?B?UmVbMl06INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90Lg=?= =?UTF-8?B?0YDRg9C10YLRgdGPPw==?= In-Reply-To: <62eb90c58ff906fff85314ffa21982a9.NginxMailingListRussian@forum.nginx.org> References: <12901108.20130115001017@softsearch.ru> <62eb90c58ff906fff85314ffa21982a9.NginxMailingListRussian@forum.nginx.org> Message-ID: <192913180.20130115085433@softsearch.ru> Здравствуйте, Trurl. > У меня вообще одна голая практика... ферма (много апачей и не только > их) живет в штатах, а узлы CDN раскиданы по Европе и все это под > контролем ДНС с геобалансингом (+мониторинг состояния с отключением > упавших узлов). Например две точки в Москве (на разных провайдерах) > - между ними перекинуть видео весом в 2ГБ куда выгоднее чем тащить > со штатов, учитывая что "внешний" траффик зачастую лимитируется, в > отличии от проброса по М9/М10. Даже с Киевского узла его перегнать - > и то на порядок выгоднее. Вопрос не в том, чтобы перекинуть, а в том, чтобы потом эти данные как-то использовать. Чтобы использовать быстро, их хорошо бы в оперативке держать. Если такие данные приходят от нескольких серверов, то они съедят много оперативки и их хорошо бы не дублировать в разных местах. У Вас, как я понимаю, 2 параметра, по которым можно производить оптимизацию: время и стоимость доставки контента. Если говорить про время, то отдавать контент надо с ближайшего кэша по геобалансингу (а лучше не по географии, а по rtt до подсети, из которой браузер сделал запрос), а проксировать запрос до ближайшего хранилища и параллельно до ближайших кэшей (если они ближе хранилища, работают и недогружены) и использовать того, кто первый ответит, а остальные соединения дропать. Или по таймауту как-нить останавливать передачу данных, а tcp-соединение оставлять для следующих запросов. Или tcp-соединения до возможных бэкендов заранее открывать в достаточном количестве и поддерживать их. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Tue Jan 15 04:58:13 2013 From: nginx-forum at nginx.us (daitepiva) Date: Mon, 14 Jan 2013 23:58:13 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/QviDQutGD0LrQsNC8INC00Ls=?= =?UTF-8?B?0Y8g0LPQvtGB0YLQtdC5INGE0L7RgNGD0LzQsCDQvdCwIElQQiAoSW52aXNp?= =?UTF-8?B?b24gUG93ZXIgQm9hcmQp?= In-Reply-To: References: Message-ID: <5670fefb7d9daa357f6e16cecd78feca.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > поисковые роботы игнорируют куки, хотите попасть в поисковики в виде в > таком виде )) ? В каком "таком"? С задержкой в одну минуту? Даже для живых людей, которые не захотели залогиниться, не видно в этом ничего плохого, а уж поисковики тем более переживут ) Меня интересовала именно правильность реализации моей идеи с точки зрения nginx-а. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234824,235111#msg-235111 From nginx-forum at nginx.us Tue Jan 15 05:07:53 2013 From: nginx-forum at nginx.us (Trurl) Date: Tue, 15 Jan 2013 00:07:53 -0500 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQp9GC0L4t0YLQviDRgtC40L/QsCBjYWNoZSBkYiDQv9C70LA=?= =?UTF-8?B?0L3QuNGA0YPQtdGC0YHRjz8=?= In-Reply-To: <41907497.20130115030237@softsearch.ru> References: <41907497.20130115030237@softsearch.ru> Message-ID: Михаил Монашёв Wrote: ------------------------------------------------------- > Здравствуйте, Михаил. > > > В качестве костыльного решения похожей задачи я начал обдумывать > > upstream в haproxy. А в haproxy уже раскидывать запросы с > > опциональным выбором бекендов исходя из различных условий > > (заголовков или ещё чего, что выставит nginx). > > Человеку не нужны заголовки. Ему надо, чтобы всё было автоматически. И кто этот человек? ) Сейчас-то у меня именно на заголовках, но жалко ресурсы на это тратить. благо у меня только 2 уровня, простой запрет юзать второй уровень если есть заголовок о пройденном втором уровне помогает. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235074,235101#msg-235101 From postmaster at softsearch.ru Tue Jan 15 05:21:21 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 09:21:21 +0400 Subject: =?UTF-8?B?UmVbNF06INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90Lg=?= =?UTF-8?B?0YDRg9C10YLRgdGPPw==?= In-Reply-To: References: <41907497.20130115030237@softsearch.ru> Message-ID: <657307634.20130115092121@softsearch.ru> Здравствуйте, Trurl. > Сейчас-то у меня именно на заголовках, но жалко ресурсы на это > тратить. благо у меня только 2 уровня, простой запрет юзать второй > уровень если есть заголовок о пройденном втором уровне помогает. А какие по-Вашему на http-заголовки тратятся ресурсы? -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Tue Jan 15 06:39:49 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 10:39:49 +0400 Subject: =?UTF-8?B?UmVbMl06IGxpbWl0IHJhdGUg0LTQu9GPIHVwc3RyZWFt?= In-Reply-To: <89da07816ba450f8dc96820db78222fc.NginxMailingListRussian@forum.nginx.org> References: <508449965.20130114235710@softsearch.ru> <89da07816ba450f8dc96820db78222fc.NginxMailingListRussian@forum.nginx.org> Message-ID: <1185193180.20130115103949@softsearch.ru> Здравствуйте, Trurl. >> Сейчас можно на самом апстриме limit_rate включить. Или firewall >> использовать. > ну у меня апстримом может быть и сквид и апач и даже lighttpd. > да и если 7 апстримов (ферма) на одном узком канале - как лимитировать > суммарный траффик? firewall-ом можно попробовать. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Tue Jan 15 06:42:39 2013 From: nginx-forum at nginx.us (shambler81) Date: Tue, 15 Jan 2013 01:42:39 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: Большое спасибо за подробну информацию по поводоу алиасов дело не в их количестве и не в 3 строчках конфига. Веб парель попросту не умеет писатьи в nginx и в apach одновременно посему прийдется ручками добавлять. Прийдется делать допил ispconfig3 дабы она могла работать полноценно вот и сижу думаю как подойти к этому вопросу. Скорее всего прийдется подключать svn и допиливать взаимодействие с nginx, дабы германцы с легкостью пустили вебстудию в свой svn. Но это время а главное не сразу появится в стабилной сборке. проблему с сайтами www.site.ru/lalala.html решилась отдельными серверами руками , дабы таких сайтов пока толко 5, криво конечно но покаработает как перенесу весь сервер и закрою старый сделаю уже все красиво. Пока вот так: Добавлением в Default конфиг непосредственно сервера для данного домена. Почемму то так все работает. Хотя с виду ничегоне поменялось server { server_name www.okna-iventus.ru; access_log /var/log/ispconfig/httpd/$host/access.log; location / { index index.php index.html index.htm; root /var/www/okna-iventus.ru/web/; proxy_pass http://www.okna-iventus.ru:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* ^.+\.(htm|html)$ { root /var/www/okna-iventus.ru/web; try_files $uri /index.php; access_log off; expires 30d; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,235116#msg-235116 From kav at karagodov.name Tue Jan 15 06:51:52 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Tue, 15 Jan 2013 10:51:52 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUg0LTQu9GPIHVwc3RyZWFt?= In-Reply-To: <1185193180.20130115103949@softsearch.ru> References: <508449965.20130114235710@softsearch.ru> <89da07816ba450f8dc96820db78222fc.NginxMailingListRussian@forum.nginx.org> <1185193180.20130115103949@softsearch.ru> Message-ID: маленький комментарий: может быть я ошибаюсь, но решение блочить или не блочить принимается на L7, а вот уже где и как блочить, вопрос извращённости сознания для удобства и простоты - на L7, а по правилам хорошего тона на L3, но требует интеграции L7-сервсиса с L3-фаерволлом On 15.01.2013, at 10:39, Михаил Монашёв wrote: > Здравствуйте, Trurl. > >>> Сейчас можно на самом апстриме limit_rate включить. Или firewall >>> использовать. > >> ну у меня апстримом может быть и сквид и апач и даже lighttpd. >> да и если 7 апстримов (ферма) на одном узком канале - как лимитировать >> суммарный траффик? > > firewall-ом можно попробовать. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From maybe at arjlover.net Tue Jan 15 07:14:54 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 14:14:54 +0700 Subject: =?UTF-8?B?UmU6IG1lbWNhY2hlZF9wYXNzINC90LUg0LzQvtC20LXRgiDQsdGL0YLRjCB1bml4?= =?UTF-8?B?IHNvY2tldD8=?= In-Reply-To: <201301150257.55544.vbart@nginx.com> References: <201301150238.14102.vbart@nginx.com> <201301150257.55544.vbart@nginx.com> Message-ID: > > Работа над документацией идет постоянно: > http://trac.nginx.org/nginx/timeline?repo-nginx_org=on > Немного стыдно, но не осилил. Точнее побоялся лезть. ( Пользуясь случаем хочу попросить умелого и неравнодушного поправить. > > Если бан только по ip, то это не на 7-ом уровне решать нужно. А так, > должно бы > получиться. > > Ну знаете, на третьем они все белые ) и пушистые, дружно бегают и не дерутся, а вот на 7ом бывают гаденыши. Причем хочется все же им не черную дыру показать, а внятно предупредить, и нжинкс это позволяет сделать и не особо затратнее чем на третьем уровне. А может даже и легче, так как из-за пары террористов гонять миллионы через рамку - не факт что легче. -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maybe at arjlover.net Tue Jan 15 07:19:48 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 14:19:48 +0700 Subject: =?UTF-8?B?a2VlcCBhbGl2ZSDQsdGD0LTQtdGCINGA0LDQsdC+0YLQsNGC0Ywg0L3QsCDRgNCw?= =?UTF-8?B?0LfQvdGL0LUg0LTQvtC80LXQvdGLPw==?= Message-ID: Если у меня на сервере на одном айпи висят: example.com static.example.com example.com - отдает только одну страницу и ничего больше, для чистоты вопроса допустим, что эта страница содержит только один элемент с домена static.example.com - есть смысл в кофиге нжинкса включать keep alive - поймут ли браузеры, что за статикой на другой домен можно сбегать в том же коннекте? -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maybe at arjlover.net Tue Jan 15 07:39:00 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 14:39:00 +0700 Subject: =?UTF-8?B?MjEg0LLQtdC6IC0g0LLQtdC6INC80L7QsdC40LvRjNC90L7Qs9C+INC40L3RgtC1?= =?UTF-8?B?0YDQvdC10YLQsCwg0LAgbmdpbngg0LPQtNC1Pw==?= Message-ID: Добрый день! А что мы здесь имеем сегодня, когда гугль активирует по 1,5 миллиона зоопарка андроидов в день, да и все остальные тоже стараются? Лично я имею сайт на котором не могу закэшировать ровно ничего, т.к. сайт давно заимел мобильную версию на том же example.com и на m.example.com его уже не передвинуть, а качественно отделить мобильники от немобильников никак не получается. Я тут несколько раз поднимал этот вопрос - накостылить чего-то можно, но я веду к тому, что в стратегическом смысле хотелось бы увидеть в nginx-е качественное решение в будущем. Из того что можно сейчас прикрутить к нжинксу - http://detectmobilebrowsers.com/ - еле живое и не особо актуальное. http://code.google.com/p/php-mobile-detect/ - класс который приходится использовать, но уже за нжинксом. Обновляется практически каждый день, а то и два раза в день - и это верно отражает происходящее на фронте мобильных девайсов. Вот его бы, да на нжинкс... -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Tue Jan 15 08:28:44 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 12:28:44 +0400 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: Message-ID: <144586940.20130115122844@softsearch.ru> Здравствуйте, Anton. CSS3, которые поддерживается всеми мобильными браузерами, создан в том числе и для адаптации под мобильный интернет. Почитайте про Responsive Web Design. Не надо делать мобильную версию ибо одна и та же страничка одинаково хорошо выглядит и на мелких и на больших экранах. Пример: http://mattkersley.com/responsive/ . Мы так попробовали и получилось очень малой кровью сделать на основе обычного сайта адаптирующийся под маленькие экраны. Отдельная проблема - Опера-Мини. Но она легко детектится и всё её забабахи также можно победить. P.S. "век мобильного интернета" - это мем гугла, который хочет любой ценой проникнуть на устройства пользователей, ибо сдвинуть винду с ноутов и обычных компов у него не выходит менее эффективно. И соответственно ему нужно, чтобы веб адаптировался под браузинг на мелких экранах. -- С уважением, Михаил mailto:postmaster at softsearch.ru From citrin at citrin.ru Tue Jan 15 08:35:16 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 15 Jan 2013 08:35:16 +0000 Subject: =?UTF-8?B?UmU6IGtlZXAgYWxpdmUg0LHRg9C00LXRgiDRgNCw0LHQvtGC0LDRgtGMINC90LAg?= =?UTF-8?B?0YDQsNC30L3Ri9C1INC00L7QvNC10L3Riz8=?= In-Reply-To: References: Message-ID: <50F514C4.8020402@citrin.ru> 1/15/13 7:19 AM, Anton Kuznetsov пишет: > Если у меня на сервере на одном айпи висят: > example.com > static.example.com > > example.com - отдает только одну страницу и ничего > больше, для чистоты вопроса допустим, что эта страница содержит только > один элемент с домена static.example.com - > есть смысл в кофиге нжинкса включать keep alive - поймут ли браузеры, > что за статикой на другой домен можно сбегать в том же коннекте? Скорее всего в разных браузерах по разному, но проще включить keep alive для всех доменов. Выключать keep alive стоит разве что для экономии памяти, когда это не ухудшит качество обслуживания клиентов. Если памяти будет не хватать и у вас будут десятки тысяч одновременных коннекци, то можно будет попробовать отключить keep alive для example.com - если кол-во коннекци уменьшится, а кол-во accepted connection (в секунду) не увеличится, значит keep alive на example.com не нужен и можно его не включить (и сэкономить на этом немножко памяти). From citrin at citrin.ru Tue Jan 15 08:40:21 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 15 Jan 2013 08:40:21 +0000 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: Message-ID: <50F515F5.7010304@citrin.ru> 1/15/13 7:39 AM, Anton Kuznetsov пишет: > качественно отделить мобильники от немобильников никак не получается. Я > тут несколько раз поднимал этот вопрос - накостылить чего-то можно, но я > веду к тому, что в стратегическом смысле хотелось бы увидеть в nginx-е > качественное решение в будущем. Качественно отделить и не получится. Более того на одном и том же устройстве удобно смотреть мобильную версию для сайтов где функциональность мобильной версии не сильно урезана и десктопную версию, там где функциональности мобильной версии не хватает. Автодетект должен определять что показывать по умолчанию, а дальше надо давать пользователю выбор (который запоминать в куке, например). И это уже логика специфичная для приложения, и реализовывать её лучше в приложении, а не в web-сервере. From postmaster at softsearch.ru Tue Jan 15 08:40:22 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 12:40:22 +0400 Subject: =?UTF-8?B?UmVbMl06IG1lbWNhY2hlZF9wYXNzINC90LUg0LzQvtC20LXRgiDQsdGL0YLRjCB1?= =?UTF-8?B?bml4IHNvY2tldD8=?= In-Reply-To: References: <201301150238.14102.vbart@nginx.com> Message-ID: <142383731.20130115124022@softsearch.ru> Здравствуйте, Anton. > Ну я раздумываю сделать что-то вроде > > set $memcached_key "ban_$remote_addr"; > > и привет.. Получится? Или это не самый простой способ сделать динамический бан с ограниченным временем жизни? в ipfw есть таблицы (table) . это список подсетей или ip-шек с временем, когда они из этой таблицы пропадут. Пишется примерно такое правило: deny ip from table(1) to any in via em0 блокировать все входящие ip-пакеты, идущие через em0 Добавление в таблицу делается вот так: /sbin/ipfw table 1 add 1.2.3.4 1358239012 где 1358239012 - время, когда ip 1.2.3.4 удалится из первой таблицы удаление срока - вот так: /sbin/ipfw table 1 delete 1.2.3.4 очистка всей таблицы вот так: /sbin/ipfw table 1 flush Всё это работает очень быстро. -- С уважением, Михаил mailto:postmaster at softsearch.ru From maybe at arjlover.net Tue Jan 15 08:54:33 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 15:54:33 +0700 Subject: =?UTF-8?B?UmU6IFJlWzJdOiBtZW1jYWNoZWRfcGFzcyDQvdC1INC80L7QttC10YIg0LHRi9GC?= =?UTF-8?B?0YwgdW5peCBzb2NrZXQ/?= In-Reply-To: <142383731.20130115124022@softsearch.ru> References: <201301150238.14102.vbart@nginx.com> <142383731.20130115124022@softsearch.ru> Message-ID: спасибо, я знаю что такое ipfw, ) но как я уже писал, из-за 5 чудаков, а) не хочется фильтровать сотню мегабит через 5 правил б) хочется им внять дать по башке и сказать за что в) хочется чтобы правило само отсохло через N времени и не заморачиваться еще и на удаление бана. Спасибо, нжинксу и мемкешу - можно сделать блокировку со всеми этими бонусами. Антон. 2013/1/15 Михаил Монашёв > Здравствуйте, Anton. > > > Ну я раздумываю сделать что-то вроде > > > > set $memcached_key "ban_$remote_addr"; > > > > и привет.. Получится? Или это не самый простой способ сделать > динамический бан с ограниченным временем жизни? > > в ipfw есть таблицы (table) . это список подсетей или ip-шек с > временем, когда они из этой таблицы пропадут. Пишется примерно такое > правило: > deny ip from table(1) to any in via em0 > блокировать все входящие ip-пакеты, идущие через em0 > > Добавление в таблицу делается вот так: > /sbin/ipfw table 1 add 1.2.3.4 1358239012 > где 1358239012 - время, когда ip 1.2.3.4 удалится из первой таблицы > > удаление срока - вот так: > /sbin/ipfw table 1 delete 1.2.3.4 > > очистка всей таблицы вот так: > /sbin/ipfw table 1 flush > > Всё это работает очень быстро. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From panfilov at sports.ru Tue Jan 15 08:58:13 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Tue, 15 Jan 2013 12:58:13 +0400 Subject: =?UTF-8?B?UmU6IG1lbWNhY2hlZF9wYXNzINC90LUg0LzQvtC20LXRgiDQsdGL0YLRjCB1bml4?= =?UTF-8?B?IHNvY2tldD8=?= In-Reply-To: <201301150238.14102.vbart@nginx.com> References: <201301150238.14102.vbart@nginx.com> Message-ID: В качестве оффтопика: 15 января 2013 г., 2:38 пользователь Валентин Бартенев написал: > > Может. Но вообще, какой смысл в memcached на той же машине? > Не проще ли кэш nginx-а использовать? > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > _______________________________________________ > А если данные хочется в кеше редактировать или удалять? Приходиться memcache использовать :( -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From maybe at arjlover.net Tue Jan 15 09:36:24 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Tue, 15 Jan 2013 16:36:24 +0700 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: <50F515F5.7010304@citrin.ru> References: <50F515F5.7010304@citrin.ru> Message-ID: Все это здорово читать и как пользователям выбор давать и как CSS3 юзать. И да - айфон нормально срендерит любой сайт и покажет как на ПК, дальше зумь его и тыкай. Все можно. Но зачем? Когда можно создать качественное мобильное вебприложение с удобными элементами именно для мобильников? А еще мне лично прислали пару ссылок на коммерческие продукты по детекту - стоимость зашкаливает. Тысячи долларов и это начальный уровень по АПИ с лимитом запросов. Анлим энтрепрайз в виде модуля нжинкса у обоих таки есть - но ценой публично предпочитают не пугать. ) Мне это говорит о наличии высокого спроса у тех кто хоть раз задумывался сделать настоящую версию для мобильников. -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From panfilov at sports.ru Tue Jan 15 09:49:12 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Tue, 15 Jan 2013 13:49:12 +0400 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: <50F515F5.7010304@citrin.ru> Message-ID: http://detectmobilebrowsers.com/ наслаждайтесь 15 января 2013 г., 13:36 пользователь Anton Kuznetsov написал: > Все это здорово читать и как пользователям выбор давать и как CSS3 юзать. > И да - айфон нормально срендерит любой сайт и покажет как на ПК, дальше > зумь его и тыкай. Все можно. Но зачем? Когда можно создать качественное > мобильное вебприложение с удобными элементами именно для мобильников? > А еще мне лично прислали пару ссылок на коммерческие продукты по детекту - > стоимость зашкаливает. Тысячи долларов и это начальный уровень по АПИ с > лимитом запросов. Анлим энтрепрайз в виде модуля нжинкса у обоих таки есть > - но ценой публично предпочитают не пугать. ) Мне это говорит о наличии > высокого спроса у тех кто хоть раз задумывался сделать настоящую версию для > мобильников. > > > -- > Best regards, > Anton Kuznetsov. > > _______________________________________________ > 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 imaliy.filsh at gmail.com Tue Jan 15 10:10:55 2013 From: imaliy.filsh at gmail.com (Igor Maliy) Date: Tue, 15 Jan 2013 12:10:55 +0200 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: <144586940.20130115122844@softsearch.ru> References: <144586940.20130115122844@softsearch.ru> Message-ID: <50F52B2F.1020307@gmail.com> CSS3 не создавался для мобильных устройств, это просто логическое развитие веба. Есть два принципиальных мнения о том как создавать мобильные сайты, делать адаптивную верстку или полностью мобильный сайт... я предпочитаю мобильный сайт, в поддержке гораздо легче, то ли копаться в горах кода и бояться что то поломать на вебе, то ли изначально затачивать под маленькие экраны, разница есть. Советую посмотреть сюда http://wurfl.sourceforge.net/ это серверная библиотека, развивается уже долгое время и регулярно обновляется, можно положить в базу, можно в кеш, ... есть устройства которые не распознает, но это проблема во всех либах. 15.01.2013 10:28, Михаил Монашёв пишет: > Здравствуйте, Anton. > > CSS3, которые поддерживается всеми мобильными браузерами, создан в том > числе и для адаптации под мобильный интернет. Почитайте про Responsive > Web Design. Не надо делать мобильную версию ибо одна и та же страничка > одинаково хорошо выглядит и на мелких и на больших экранах. Пример: > http://mattkersley.com/responsive/ . > > Мы так попробовали и получилось очень малой кровью сделать на основе > обычного сайта адаптирующийся под маленькие экраны. > > Отдельная проблема - Опера-Мини. Но она легко детектится и всё её > забабахи также можно победить. > > P.S. > "век мобильного интернета" - это мем гугла, который хочет любой ценой > проникнуть на устройства пользователей, ибо сдвинуть винду с ноутов и > обычных компов у него не выходит менее эффективно. И соответственно > ему нужно, чтобы веб адаптировался под браузинг на мелких экранах. > From nginx-forum at nginx.us Tue Jan 15 10:57:34 2013 From: nginx-forum at nginx.us (scroitor) Date: Tue, 15 Jan 2013 05:57:34 -0500 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHVyaSDRgSDQsNGA0LPRg9C80LXQvdGC0LDQvNC4INCy0Lo=?= =?UTF-8?B?0LvRjtGH0LjRgtC10LvRjNC90L4=?= In-Reply-To: References: Message-ID: <4faf4f3060d1408ef2e682a126079777.NginxMailingListRussian@forum.nginx.org> О, спасибо за путеуказание! :) Посмотрю в сторону мапов и именованных локаций Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234977,235136#msg-235136 From vbart at nginx.com Tue Jan 15 11:07:08 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 15 Jan 2013 15:07:08 +0400 Subject: =?UTF-8?B?UmU6IDIxICDQstC10LogLSDQstC10Log0LzQvtCx0LjQu9GM0L3QvtCz0L4g0Lg=?= =?UTF-8?B?0L3RgtC10YDQvdC10YLQsCwgINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: Message-ID: <201301151507.08361.vbart@nginx.com> On Tuesday 15 January 2013 11:39:00 Anton Kuznetsov wrote: > Добрый день! > > А что мы здесь имеем сегодня, когда гугль активирует по 1,5 миллиона > зоопарка андроидов в день, да и все остальные тоже стараются? Лично я имею > сайт на котором не могу закэшировать ровно ничего, т.к. сайт давно заимел > мобильную версию на том же example.com и на m.example.com его уже не > передвинуть, а качественно отделить мобильники от немобильников никак не > получается. Я тут несколько раз поднимал этот вопрос - накостылить чего-то > можно, но я веду к тому, что в стратегическом смысле хотелось бы увидеть в > nginx-е качественное решение в будущем. "Накостылить" - это написать пару регэкспов в директиву map по $http_user_agent. > Из того что можно сейчас прикрутить к нжинксу - > http://detectmobilebrowsers.com/ - еле живое и не особо актуальное. > http://code.google.com/p/php-mobile-detect/ - класс который приходится > использовать, но уже за нжинксом. Обновляется практически каждый день, а то > и два раза в день - и это верно отражает происходящее на фронте мобильных > девайсов. Вот его бы, да на нжинкс... https://github.com/serbanghita/Mobile-Detect/blob/master/Mobile_Detect.php Те же самые регэкспы как бы в map, только предполагается, что пишите их не вы, а кто-то со стороны. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Jan 15 12:03:09 2013 From: nginx-forum at nginx.us (Mamtesh Kumar) Date: Tue, 15 Jan 2013 07:03:09 -0500 Subject: text/vnd.wap.wml error In-Reply-To: <20130111092526.GU80623@mdounin.ru> References: <20130111092526.GU80623@mdounin.ru> Message-ID: <25ca7c40dc00cd1c23974ef56051e758.NginxMailingListRussian@forum.nginx.org> Hi Maxim, I also have same problem. What could be the reason of that?. Then we can focus into that. Pleas suggest. Thanks Mamtesh Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234921,235140#msg-235140 From nginx-forum at nginx.us Tue Jan 15 13:37:56 2013 From: nginx-forum at nginx.us (bioargonaft) Date: Tue, 15 Jan 2013 08:37:56 -0500 Subject: =?UTF-8?B?UmU6INC60LXRiNC40YDQvtCy0LDQvdC40LUg0Y3Qu9C10LzQtdC90YLQvtCyINC0?= =?UTF-8?B?0LjQt9Cw0LnQvdCw?= In-Reply-To: References: Message-ID: <5b8c78c2892f1a92ff86eb9bdea479e0.NginxMailingListRussian@forum.nginx.org> Реализовал задачу. Вот такие конфиги получились: #===========> nginx.conf <============================================= user nginx; worker_processes 4; error_log /var/log/nginx/error.log warn; #debug; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; proxy_cache_path /var/cache/nginx/proxy_cache levels=1:2 keys_zone=static:32m inactive=15h max_size=64m; proxy_temp_path /var/cache/nginx/proxy_temp 1 2; proxy_ignore_headers Expires Cache-Control; proxy_cache_bypass $cookie_session; proxy_no_cache $cookie_session; sendfile on; tcp_nopush on; keepalive_timeout 65; gzip on; gzip_static on; gzip_proxied any; gzip_min_length 1100; gzip_http_version 1.1; gzip_buffers 4 8k; gzip_comp_level 5; gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json; include /etc/nginx/conf.d/*.conf; } #===========> nginx.conf <============================================= #===========> default.conf <============================================= server { listen 80; server_name localhost; if ( $scheme = "http" ) { rewrite ^/(.*)$ https://$host/$1 permanent; } } #===========> default.conf <============================================= #===========> ssl.conf <============================================= # HTTPS server server { listen 443; server_name localhost; ssl on; ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/cert.key; ssl_session_timeout 5m; ssl_protocols SSLv2 SSLv3 TLSv1; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location ~^/domjs/ { root /var/www/; } location ~^/.*\.(css|js|gif|jpg|png)$ { proxy_pass http://192.168.1.250:8080; proxy_set_header Host $host; proxy_cache static; proxy_cache_valid 60m; #proxy_cache_valid 404 1m; expires 5d; } location / { proxy_pass http://192.168.1.250:8080; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; proxy_ignore_client_abort on; } } #===========> ssl.conf <============================================= Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234478,235142#msg-235142 From maybe at arjlover.net Tue Jan 15 18:08:12 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Wed, 16 Jan 2013 01:08:12 +0700 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: <201301151507.08361.vbart@nginx.com> References: <201301151507.08361.vbart@nginx.com> Message-ID: > > "Накостылить" - это написать пару регэкспов в директиву map по > $http_user_agent. > > На том в последний раз и сошлись в этой рассылке. Будет работать в 98% для обратной задачи, т.е. определения писишной винды. https://github.com/serbanghita/Mobile-Detect/blob/master/Mobile_Detect.php > > Те же самые регэкспы как бы в map, только предполагается, что пишите их не > вы, > а кто-то со стороны. > Да, регэкспы конечно, не о чем другом тут и не может идти речь. Нам дан только UA, никакого другого параметра стандартами не предусмотрено (а жаль). Но только этих рэгэкспов в этом классе столько - что речь уже идет не о "накостылисть", а о маленьком стартапе. Вон у других ровно тоже продается за тысячи долларов. То есть как обычно, на пробелы крупного проекта начинают заполняться со стороны. Жалко что за нереальные деньги, за задачу несравнимую со сложностью многих стандартных плагинов. -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Tue Jan 15 18:20:23 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 15 Jan 2013 22:20:23 +0400 Subject: =?UTF-8?B?UmU6IDIxICDQstC10LogLSDQstC10Log0LzQvtCx0LjQu9GM0L3QvtCz0L4g0Lg=?= =?UTF-8?B?0L3RgtC10YDQvdC10YLQsCwgINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: <201301151507.08361.vbart@nginx.com> Message-ID: <201301152220.23672.vbart@nginx.com> On Tuesday 15 January 2013 22:08:12 Anton Kuznetsov wrote: [...] > Да, регэкспы конечно, не о чем другом тут и не может идти речь. Нам дан > только UA, никакого другого параметра стандартами не предусмотрено (а > жаль). Но только этих рэгэкспов в этом классе столько - что речь уже идет > не о "накостылисть", а о маленьком стартапе. И вам обязательно все сразу нужны? Типичная задача - распознать андройд, айфон, и ещё что-нибудь. > Вон у других ровно тоже продается за тысячи долларов. Уверены, что продается? =) > То есть как обычно, на пробелы крупного проекта начинают заполняться со > стороны. Жалко что за нереальные деньги, за задачу несравнимую со сложностью > многих стандартных плагинов. Всегда открыты для любых коммерческих предложений: nginx-inquiries at nginx.com -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Tue Jan 15 18:20:25 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 22:20:25 +0400 Subject: =?UTF-8?B?UmVbMl06IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviA=?= =?UTF-8?B?0LjQvdGC0LXRgNC90LXRgtCwLCDQsCBuZ2lueCDQs9C00LU/?= In-Reply-To: References: <201301151507.08361.vbart@nginx.com> Message-ID: <1754543974.20130115222025@softsearch.ru> Здравствуйте, Anton. > Вон у других ровно тоже продается за тысячи долларов. Не так. Это они продают. А продаётся или нет, нам не известно. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Tue Jan 15 18:22:52 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 15 Jan 2013 22:22:52 +0400 Subject: =?UTF-8?B?UmVbMl06IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviA=?= =?UTF-8?B?0LjQvdGC0LXRgNC90LXRgtCwLCDQsCBuZ2lueCDQs9C00LU/?= In-Reply-To: References: <201301151507.08361.vbart@nginx.com> Message-ID: <647839616.20130115222252@softsearch.ru> Здравствуйте, Anton. Вот, качайте по крону, и используйте: http://detectmobilebrowsers.com/download/nginx Конечно тоже надо немного допилить скаченное, но ведь можно же. И бесплатно. -- С уважением, Михаил mailto:postmaster at softsearch.ru From hell-for-yahoo at umail.ru Tue Jan 15 19:20:03 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Tue, 15 Jan 2013 23:20:03 +0400 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: Message-ID: <131179912.20130115232003@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Anton Kuznetsov! AK> А что мы здесь имеем сегодня, когда гугль активирует по 1,5 миллиона AK> зоопарка андроидов в день, да и все остальные тоже стараются? Лично я имею AK> сайт на котором не могу закэшировать ровно ничего, т.к. сайт давно заимел AK> мобильную версию на том же example.com и на m.example.com его уже не AK> передвинуть, а качественно отделить мобильники от немобильников никак не AK> получается. Я тут несколько раз поднимал этот вопрос - накостылить чего-то AK> можно, но я веду к тому, что в стратегическом смысле хотелось бы увидеть в AK> nginx-е качественное решение в будущем. AK> Из того что можно сейчас прикрутить к нжинксу - AK> http://detectmobilebrowsers.com/ - еле живое и не особо актуальное. AK> http://code.google.com/p/php-mobile-detect/ - класс который приходится AK> использовать, но уже за нжинксом. Обновляется практически каждый день, а то AK> и два раза в день - и это верно отражает происходящее на фронте мобильных AK> девайсов. Вот его бы, да на нжинкс... Проблема не в nginx, а как раз в изготовителях мобильных браузеров. Пока они не подберут мозги с пола и не выработают прямой и недвусмысленный способ заявления о том, что "мы мобильные, нас не нагружать" - придётся импользовать озвученные вами костыли. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) вторник, 15.01.2013, <23:18> From nginx-forum at nginx.us Wed Jan 16 00:04:06 2013 From: nginx-forum at nginx.us (Trurl) Date: Tue, 15 Jan 2013 19:04:06 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINC90LUg0YDQsNCx0L7RgtCw0LXRgiDQv9GA0LggcHJv?= =?UTF-8?B?eHkgYnVmZmVyaW5nPW9mZg==?= In-Reply-To: <9b35d3f1d3b46a73154845ae2c5c70e6.NginxMailingListRussian@forum.nginx.org> References: <201301150218.10123.vbart@nginx.com> <9b35d3f1d3b46a73154845ae2c5c70e6.NginxMailingListRussian@forum.nginx.org> Message-ID: <8955b40235c65805ea6c0924c921be01.NginxMailingListRussian@forum.nginx.org> Trurl Wrote: ------------------------------------------------------- > > > Если у вас средний объем ответа значительно больше > > > proxy_max_temp_file_size, то > > > и смысла в нём нет, тогда стоит ставить proxy_max_temp_file_size > 0; > > вообще-то средний как раз значительно меньше, но максимальный может > за > > 2GB быть... > > Спасибо, попробую. > > > несколько непонятно как оно работает... в общем при > "proxy_max_temp_file_size 0;" файлы там таки все равно создаются :) > Но тут же исчезают (я так понимаю - перекочевывают в папку кеша) > Что, в целом, вполне отлично. Еще раз спасибо > > Осталось только понять логику их вообще там существования при наличии > кеша и proxy_max_temp_file_size отличном от нуля... Фиг-вам... видимо перестало удалять и размер папки proxy_temp_path превысил 50 гигов при proxy_max_temp_file_size 0; в логах кроме "proxy_buffer_size 4096 is not enough for cache key, it should increased at least to 5120," ничего интересного при этом нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235068,235161#msg-235161 From nginx-forum at nginx.us Wed Jan 16 00:32:56 2013 From: nginx-forum at nginx.us (Trurl) Date: Tue, 15 Jan 2013 19:32:56 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINC90LUg0YDQsNCx0L7RgtCw0LXRgiDQv9GA0LggcHJv?= =?UTF-8?B?eHkgYnVmZmVyaW5nPW9mZg==?= In-Reply-To: <201301150211.07835.vbart@nginx.com> References: <201301150211.07835.vbart@nginx.com> Message-ID: <76cf0d48e22be52d277b627b19a12dd4.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Tuesday 15 January 2013 01:46:22 Trurl wrote: > > > > Кеширование не работает при отключении proxy_buffering. > > > > Это так и должно быть или я что-то не понимаю? > > > > > > Так и должно быть. > > > > а как, в этом случае, ограничить общий размер proxy_temp_path ? > > > > proxy_buffering к этому не имеет никакого отношения. > > Этим занимается директива proxy_max_temp_file_size: > http://nginx.org/r/proxy_max_temp_file_size/ru > > > например при > > > > proxy_cache_path /var/cache/nginx levels=1:2 > keys_zone=main_cache:1024m > > inactive=172800 max_size=4096m; > > proxy_temp_path /var/lib/nginx/proxy 1 2; > > proxy_temp_file_write_size 32k; > > proxy_max_temp_file_size 5m; > > > > папка /var/cache/nginx 3.0G > > а папка /var/lib/nginx/proxy - 28G > > (обе папки на одном диске, если что) > > и все это за сутки с чистого листа > > (контента на серверах вообще террабайты и половина его динамическая, > но > > далеко не все эти террабайты популярны) > > > > 28Гб? Это не ошибка? Сколько у вас RPS к прокси и какой средний объем > ответов? > > 28*1024/5 дает ~6000 одновременно обрабатываемых ответов объемом от > 5Мб. > Если у вас гораздо меньше, то явно что-то не в порядке. В error_log > всё чисто? за последие 12 часов 2950138 запросов, из них 2369385 хитов... Средний размер ответа - 50к (максимальный за это время - гигабайт, но почти все такие жирные запросы были в кеше) 550 ошибок типа "upstream timed out (110: Connection timed out) while reading upstream" средний исходящий траффик - 22.15Мbit/s (5минут усредненный) - то что отдается клиентам - плавная горка до 50Мbit/s и обратно средний входящий - 33.49Мbit/s (!!!) - то что забрано с апстрима - несколько пиков до 600Мbit/s То есть совершенно убыточный узел получается. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235068,235162#msg-235162 From nginx-forum at nginx.us Wed Jan 16 09:32:41 2013 From: nginx-forum at nginx.us (Trurl) Date: Wed, 16 Jan 2013 04:32:41 -0500 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQp9GC0L4t0YLQviDRgtC40L/QsCBjYWNoZSBkYiDQv9C70LA=?= =?UTF-8?B?0L3QuNGA0YPQtdGC0YHRjz8=?= In-Reply-To: <192913180.20130115085433@softsearch.ru> References: <192913180.20130115085433@softsearch.ru> Message-ID: <812dd06bda69a93bc966fe5e59bd744d.NginxMailingListRussian@forum.nginx.org> Михаил Монашёв Wrote: ------------------------------------------------------- > Здравствуйте, Trurl. > > > У меня вообще одна голая практика... ферма (много апачей и не только > > их) живет в штатах, а узлы CDN раскиданы по Европе и все это под > > контролем ДНС с геобалансингом (+мониторинг состояния с отключением > > упавших узлов). Например две точки в Москве (на разных провайдерах) > > - между ними перекинуть видео весом в 2ГБ куда выгоднее чем тащить > > со штатов, учитывая что "внешний" траффик зачастую лимитируется, в > > отличии от проброса по М9/М10. Даже с Киевского узла его перегнать - > > и то на порядок выгоднее. > > Вопрос не в том, чтобы перекинуть, а в том, чтобы потом эти данные > как-то использовать. Чтобы использовать быстро, их хорошо бы в > оперативке держать. Если такие данные приходят от нескольких серверов, > то они съедят много оперативки и их хорошо бы не дублировать в разных > местах. > > У Вас, как я понимаю, 2 параметра, по которым можно производить > оптимизацию: время и стоимость доставки контента. Стоимость доставки включает в себя и внутреннюю доставку между узлами. > > Если говорить про время, то отдавать контент надо с ближайшего кэша по > геобалансингу (а лучше не по географии, а по rtt до подсети, из > которой браузер сделал запрос), а проксировать запрос до ближайшего > хранилища и параллельно до ближайших кэшей (если они ближе хранилища, > работают и недогружены) и использовать того, кто первый ответит, а > остальные соединения дропать. Или по таймауту как-нить останавливать > передачу данных, а tcp-соединение оставлять для следующих запросов. > Или tcp-соединения до возможных бэкендов заранее открывать в > достаточном количестве и поддерживать их. Ну у меня сейчас геобалансинг и есть, на основе IP запрашивающего ДНС (для гугля пришлось делать EDNS subclient и с ними договариваться). Точность не ахти, но достаточная. Понятия хранилищ нету, весь контент работает по стандартам кеширования и разницы между страничкой сайта, сгенеренной на 2 минуты для всех, странички форума - для одного на 10 сек, или статики видео - на месяц как бы нет, в любом объекте написано как и на сколько его кешировать. Сквиды на узлах у меня сейчас обмениваются базами и по UDP шлют запросы всем соседям и апстримам на предмет "у кого есть данный объект". Само собой что соседи, если у них есть в кеше такой объект, ответят быстрее. Если нет - пытаюсь запросить апстримы (их много, но все в одном месте), если они не доступны (пингуются постоянно + проверка ответов) - пытаюсь получить объект через соседа. Сосед при этом уже не имеет права спрашивать другого соседа - только апстримы. Этот "загиб" в России весьма востребован, ибо узлы у меня на разных внешних провайдерах сидят и это сильно спасает. nginx у меня сейчас только использует один оконечных узлов (на соседнем компе с прямым линком) в качестве апстрима (+бекапом другой узел, тоже в Москве). Такой изврат после того как nginx 2 заза полностью забил канал апстримов (со сквидами такого не было никогда, видать они тормознутые в этом плане ;). А вообще за nginx взялся только потому, что в сквиды под сильной нагрузкой частенько валятся по совершенно идиотским поводам и вообще странно глючат (например, как-то теряют название протокола и получается что-то типа (null)://www... ). Nginx под такой же нагрузкой нарягает только меня своими приколами, а не юзеров. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235074,235145#msg-235145 From ru at nginx.com Wed Jan 16 10:35:46 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Wed, 16 Jan 2013 14:35:46 +0400 Subject: =?UTF-8?B?UmU6IG1lbWNhY2hlZF9wYXNzINC90LUg0LzQvtC20LXRgiDQsdGL0YLRjCB1bml4?= =?UTF-8?B?IHNvY2tldD8=?= In-Reply-To: References: <201301150238.14102.vbart@nginx.com> Message-ID: <20130116103546.GB78022@lo0.su> On Tue, Jan 15, 2013 at 05:44:17AM +0700, Anton Kuznetsov wrote: > http://www.nginx.org/ru/docs/http/ngx_http_memcached_module.html#memcached_pass > > Пробел в документации? В других местах возможность использования unix > socket всегда особо описана. Добавил. http://hg.nginx.org/nginx.org/rev/f46a132af596 From ru at nginx.com Wed Jan 16 10:39:00 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Wed, 16 Jan 2013 14:39:00 +0400 Subject: =?UTF-8?B?UmU6INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LXQtyBs?= =?UTF-8?B?aW1pdF9yZXE=?= In-Reply-To: <364202695.20130113130226@softsearch.ru> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> <364202695.20130113130226@softsearch.ru> Message-ID: <20130116103900.GC78022@lo0.su> On Sun, Jan 13, 2013 at 01:02:26PM +0400, Михаил Монашёв wrote: [...] > Заметил в http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html > неточность: "Избыточные запросы задерживаются до тех пор, пока их > число не превысит заданное число всплесков." Видимо имеется ввиду не > число всплесков, а число запросов в всплеске. А сам всплеск один. Неточность устранили: http://hg.nginx.org/nginx.org/rev/c711c50bdcf4 From bondarets at gmail.com Wed Jan 16 10:57:45 2013 From: bondarets at gmail.com (Ivan Bondarets) Date: Wed, 16 Jan 2013 14:57:45 +0400 Subject: =?UTF-8?B?0L/QsNGA0YHQtdGAINC00LvRjyBlcnJvci5sb2c=?= Message-ID: Добрый день! Пытаюсь разработать парсер для дефолтного error.log (описан в секции main, далее просто наследуется), но нигде не могу найти описание формата лога. менять его нельзя, насколько я понял, но хотя бы узнать, в каком формате он пишет можно? Где-нибудь есть описание? Без описания формата довольно трудно сделать нормальный парсер. Иван. -------------- next part -------------- An HTML attachment was scrubbed... URL: From unlexx at gmail.com Wed Jan 16 11:48:00 2013 From: unlexx at gmail.com (Un Lexx) Date: Wed, 16 Jan 2013 16:48:00 +0500 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: References: Message-ID: http://www.nginx.org/ru/docs/http/ngx_http_log_module.html 16 января 2013 г., 16:57 пользователь Ivan Bondarets написал: > Добрый день! > Пытаюсь разработать парсер для дефолтного error.log (описан в секции main, > далее просто наследуется), но нигде не могу найти описание формата лога. > менять его нельзя, насколько я понял, но хотя бы узнать, в каком формате он > пишет можно? Где-нибудь есть описание? > Без описания формата довольно трудно сделать нормальный парсер. > > Иван. > > _______________________________________________ > 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 unlexx at gmail.com Wed Jan 16 11:50:09 2013 From: unlexx at gmail.com (Un Lexx) Date: Wed, 16 Jan 2013 16:50:09 +0500 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: References: Message-ID: проше прощения не заметил что речь про error.log 16 января 2013 г., 17:48 пользователь Un Lexx написал: > http://www.nginx.org/ru/docs/http/ngx_http_log_module.html > > > 16 января 2013 г., 16:57 пользователь Ivan Bondarets написал: > >> Добрый день! >> Пытаюсь разработать парсер для дефолтного error.log (описан в секции >> main, далее просто наследуется), но нигде не могу найти описание формата >> лога. менять его нельзя, насколько я понял, но хотя бы узнать, в каком >> формате он пишет можно? Где-нибудь есть описание? >> Без описания формата довольно трудно сделать нормальный парсер. >> >> Иван. >> >> _______________________________________________ >> 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 public-mail at alekciy.ru Wed Jan 16 12:06:10 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Wed, 16 Jan 2013 16:06:10 +0400 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: Message-ID: 15 января 2013 г., 11:39 пользователь Anton Kuznetsov написал: > Добрый день! > > Лично я имею сайт на котором не могу закэшировать ровно ничего, т.к. сайт давно заимел > мобильную версию на том же example.com и на m.example.com его уже не > передвинуть, а качественно отделить мобильники от немобильников никак не > получается. Почему ни чего? Что мешает определить клиента тем же php-mobile-detect (или там browscap) из php, поместить результат в memcached и при следующих запросах его уже брать nginx-ом? From postmaster at softsearch.ru Wed Jan 16 12:44:45 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 16 Jan 2013 16:44:45 +0400 Subject: =?UTF-8?B?UmVbMl06INCi0L7RgNC80L7QttC10L3QuNC1INCx0L7RgtC+0LIg0YfQtdGA0LU=?= =?UTF-8?B?0LcgbGltaXRfcmVx?= In-Reply-To: <20130116103900.GC78022@lo0.su> References: <1034894495.20130113045516@softsearch.ru> <201301130504.47702.vbart@nginx.com> <364202695.20130113130226@softsearch.ru> <20130116103900.GC78022@lo0.su> Message-ID: <1877551408.20130116164445@softsearch.ru> Здравствуйте, Ruslan. >> Заметил в >> http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html >> неточность: "Избыточные запросы задерживаются до тех пор, пока их >> число не превысит заданное число всплесков." Видимо имеется ввиду не >> число всплесков, а число запросов в всплеске. А сам всплеск один. > Неточность устранили: > http://hg.nginx.org/nginx.org/rev/c711c50bdcf4 Спасибо большое! -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Wed Jan 16 12:57:06 2013 From: nginx-forum at nginx.us (ant) Date: Wed, 16 Jan 2013 07:57:06 -0500 Subject: =?UTF-8?B?0LTQuNC90LDQvNC40YfQtdGB0LrQvtC1INGA0LDRgdC/0YDQtdC00LXQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCw0LPRgNGD0LfQutC4?= Message-ID: Здравствуйте, Хотелось бы спросить рекомендаций в вопросе администрирования nginx. Есть массив серверов для хранения медиафайлов. Последние реплицируются на части серверов, но не на всех. Требуется на front-end nginx реализовать перенаправление запросов данным серверам. Есть ли возможность, имея сервис, принимаюий source url (идентификатор медиафайла) и возвращающий destination url, записать его вывод в переменную конфигурации nginx, которую затем использовать в директиве proxy_pass? Если данное решение идет вразрез со всем канонами веб-разработки, посоветуйте, пожалуйста, возможные альтернативы. p.s. Есть еще вариант формировать destination url на самой странице (например, средствами php), но не хотелось бы давать пользователю прямые ссылки на контент. Спасибо заранее. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235180,235180#msg-235180 From postmaster at softsearch.ru Wed Jan 16 13:04:45 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 16 Jan 2013 17:04:45 +0400 Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60L7QtSDRgNCw0YHQv9GA0LXQtNC10Ls=?= =?UTF-8?B?0LXQvdC40LUg0L3QsNCz0YDRg9C30LrQuA==?= In-Reply-To: References: Message-ID: <782175804.20130116170445@softsearch.ru> Здравствуйте, ant. > Хотелось бы спросить рекомендаций в вопросе администрирования nginx. Есть > массив серверов для хранения медиафайлов. Последние реплицируются на части > серверов, но не на всех. Требуется на front-end nginx реализовать > перенаправление запросов данным серверам. Есть ли возможность, имея сервис, > принимаюий source url (идентификатор медиафайла) и возвращающий destination > url, записать его вывод в переменную конфигурации nginx, которую затем > использовать в директиве proxy_pass? Да, через внутренний редирект. Нужно ответить nginx-у задать специальный заголовок X-Accel-Redirect и он сходит в другой локейшн, где может быть ещё один proxy_pass: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers http://nginx.org/ru/docs/http/ngx_http_core_module.html#internal -- С уважением, Михаил mailto:postmaster at softsearch.ru From citrin at citrin.ru Wed Jan 16 13:05:56 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Wed, 16 Jan 2013 17:05:56 +0400 Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60L7QtSDRgNCw0YHQv9GA0LXQtNC10Ls=?= =?UTF-8?B?0LXQvdC40LUg0L3QsNCz0YDRg9C30LrQuA==?= In-Reply-To: References: Message-ID: <50F6A5B4.5030301@citrin.ru> On 01/16/13 16:57, ant wrote: > Хотелось бы спросить рекомендаций в вопросе администрирования nginx. Есть > массив серверов для хранения медиафайлов. Последние реплицируются на части > серверов, но не на всех. Требуется на front-end nginx реализовать > перенаправление запросов данным серверам. Есть ли возможность, имея сервис, > принимаюий source url (идентификатор медиафайла) и возвращающий destination > url, записать его вывод в переменную конфигурации nginx, которую затем > использовать в директиве proxy_pass? Это можно сделать отдавая заголовок X-Accel-Redirect (в котором будет location, который проксируется на нужный сервер). -- Anton Yuzhaninov From pavel2000 at ngs.ru Wed Jan 16 13:06:03 2013 From: pavel2000 at ngs.ru (Pavel V.) Date: Wed, 16 Jan 2013 20:06:03 +0700 Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60L7QtSDRgNCw0YHQv9GA0LXQtNC10Ls=?= =?UTF-8?B?0LXQvdC40LUg0L3QsNCz0YDRg9C30LrQuA==?= In-Reply-To: References: Message-ID: <15710131072.20130116200603@ngs.ru> Здравствуйте, ant. Вы писали 16 января 2013 г., 19:57:06: > Здравствуйте, > Хотелось бы спросить рекомендаций в вопросе администрирования nginx. Есть > массив серверов для хранения медиафайлов. Последние реплицируются на части > серверов, но не на всех. Требуется на front-end nginx реализовать > перенаправление запросов данным серверам. Есть ли возможность, имея сервис, > принимаюий source url (идентификатор медиафайла) и возвращающий destination > url, записать его вывод в переменную конфигурации nginx, которую затем > использовать в директиве proxy_pass? > Если данное решение идет вразрез со всем канонами веб-разработки, > посоветуйте, пожалуйста, возможные альтернативы. В общем случае, вы спрашиваете про X-Accel-Redirect. Загуглите фразу "X-Accel-Redirect nginx". > p.s. Есть еще вариант формировать destination url на самой странице > (например, средствами php), но не хотелось бы давать пользователю прямые > ссылки на контент. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From vbart at nginx.com Wed Jan 16 14:30:45 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 16 Jan 2013 18:30:45 +0400 Subject: =?UTF-8?B?UmU6IGtlZXAgYWxpdmUg0LHRg9C00LXRgiDRgNCw0LHQvtGC0LDRgtGMINC90LAg?= =?UTF-8?B?0YDQsNC30L3Ri9C1INC00L7QvNC10L3Riz8=?= In-Reply-To: <50F514C4.8020402@citrin.ru> References: <50F514C4.8020402@citrin.ru> Message-ID: <201301161830.45397.vbart@nginx.com> On Tuesday 15 January 2013 12:35:16 Anton Yuzhaninov wrote: > 1/15/13 7:19 AM, Anton Kuznetsov пишет: > > Если у меня на сервере на одном айпи висят: > > example.com > > static.example.com > > > > example.com - отдает только одну страницу и ничего > > больше, для чистоты вопроса допустим, что эта страница содержит только > > один элемент с домена static.example.com - > > есть смысл в кофиге нжинкса включать keep alive - поймут ли браузеры, > > что за статикой на другой домен можно сбегать в том же коннекте? > > Скорее всего в разных браузерах по разному, но проще включить keep alive > для всех доменов. > > Выключать keep alive стоит разве что для экономии памяти, когда это не > ухудшит качество обслуживания клиентов. > > Если памяти будет не хватать и у вас будут десятки тысяч одновременных > коннекци, то можно будет попробовать отключить keep alive для > example.com - если кол-во коннекци уменьшится, а кол-во accepted > connection (в секунду) не увеличится, значит keep alive на example.com > не нужен и можно его не включить (и сэкономить на этом немножко памяти). > Количество соединений не будет больше, чем значение директивы worker_connections [1] умноженное на количество рабочих процессов (директива worker_processes [2]). При этом, если лимит соединений исчерпывается, то keep-alive соединения и так будут закрываться по мере необходимости. [1] http://nginx.org/r/worker_connections/ru [2] http://nginx.org/r/worker_processes/ru -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From maybe at arjlover.net Wed Jan 16 18:11:30 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Thu, 17 Jan 2013 01:11:30 +0700 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: References: Message-ID: Долго пытался понять как Вы так сами себя обманули? :) мемкеш попутал? Его из этого уравнения лучше вообще удалить, т.к. он ничего не меняет. Проблема остается в том же точке где и была - нжинкс ни при первом ни при втором обращении не знает кто к нему пришел, поэтому невозможно добавить этот признак в ключ кэширования и разделить кэш на мобильный и немобильный. > Почему ни чего? Что мешает определить клиента тем же php-mobile-detect > (или там browscap) из php, поместить результат в memcached и при > следующих запросах его уже брать nginx-ом? > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Wed Jan 16 18:19:54 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 16 Jan 2013 22:19:54 +0400 Subject: =?UTF-8?B?UmVbMl06IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviA=?= =?UTF-8?B?0LjQvdGC0LXRgNC90LXRgtCwLCDQsCBuZ2lueCDQs9C00LU/?= In-Reply-To: References: Message-ID: <1519954945.20130116221954@softsearch.ru> Здравствуйте, Anton. > Долго пытался понять как Вы так сами себя обманули? :) мемкеш > попутал? Его из этого уравнения лучше вообще удалить, т.к. он ничего > не меняет. Проблема остается в том же точке где и была - нжинкс ни > при первом ни при втором обращении не знает кто к нему пришел, > поэтому невозможно добавить этот признак в ключ кэширования и > разделить кэш на мобильный и немобильный. Почему это нельзя? Очень даже можно. Из конфига есть доступ к кукам. Можно регэкспы использовать, которые Вам почему-то не нравится использовать. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Wed Jan 16 20:43:00 2013 From: nginx-forum at nginx.us (ant) Date: Wed, 16 Jan 2013 15:43:00 -0500 Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60L7QtSDRgNCw0YHQv9GA0LXQtNC10Ls=?= =?UTF-8?B?0LXQvdC40LUg0L3QsNCz0YDRg9C30LrQuA==?= In-Reply-To: References: Message-ID: Спасибо большое за ответы! X-Accel-Redirect действительно делает требуемый редирект. А я было уже замахнулся писать кастомный модуль:) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235180,235188#msg-235188 From maybe at arjlover.net Thu Jan 17 04:54:33 2013 From: maybe at arjlover.net (Anton Kuznetsov) Date: Thu, 17 Jan 2013 11:54:33 +0700 Subject: =?UTF-8?B?UmU6IFJlWzJdOiAyMSDQstC10LogLSDQstC10Log0LzQvtCx0LjQu9GM0L3QvtCz?= =?UTF-8?B?0L4g0LjQvdGC0LXRgNC90LXRgtCwLCDQsCBuZ2lueCDQs9C00LU/?= In-Reply-To: <1519954945.20130116221954@softsearch.ru> References: <1519954945.20130116221954@softsearch.ru> Message-ID: У меня такое впечатление, что в этой ветке мою мысль совсем не поняли. 1) куки глючат весьма массово и даже если на них опираться, то получится что кэш обслужит только тех у кого они есть, а их нет как минимум в первый раз. 2) ключевой момент по regexp описан в первом письме, перечитайте. То, что есть под нжинкс - убого, использовать можно только для самообмана, а то, что нормально поддерживается - вагон regexp под php. А хочется-то модуль! Я по прежнему не вижу способа на нжинксе с 99% определить мобильного посетителя. А хочется-то вообще 4 или 5 девяток, а не две... :( P.S. А вообще попробовать с кукой можно, в ключ ее - понятно, но как можно всех без куки направлять на бэкенд не заглядывая в кэш? 2013/1/17 Михаил Монашёв > Здравствуйте, Anton. > > > Долго пытался понять как Вы так сами себя обманули? :) мемкеш > > попутал? Его из этого уравнения лучше вообще удалить, т.к. он ничего > > не меняет. Проблема остается в том же точке где и была - нжинкс ни > > при первом ни при втором обращении не знает кто к нему пришел, > > поэтому невозможно добавить этот признак в ключ кэширования и > > разделить кэш на мобильный и немобильный. > > Почему это нельзя? Очень даже можно. Из конфига есть доступ к кукам. > Можно регэкспы использовать, которые Вам почему-то не нравится > использовать. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From public-mail at alekciy.ru Thu Jan 17 05:49:52 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Thu, 17 Jan 2013 09:49:52 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiAyMSDQstC10LogLSDQstC10Log0LzQvtCx0LjQu9GM0L3QvtCz?= =?UTF-8?B?0L4g0LjQvdGC0LXRgNC90LXRgtCwLCDQsCBuZ2lueCDQs9C00LU/?= In-Reply-To: References: <1519954945.20130116221954@softsearch.ru> Message-ID: 1) Куки глючат? А User-Agent не глючит? В чем проблема дернуть php первый раз и записать куку, потом отдавать из memcached? 2) Убого или не работает? Большое похоже на проблему шашечек или ехать. 4 или 5 девяток обеспечиваются не абстрактным nginx-ом или другим ПО в вакууме, а конкретной инфраструктурой. 17 января 2013 г., 8:54 пользователь Anton Kuznetsov написал: > У меня такое впечатление, что в этой ветке мою мысль совсем не поняли. > > 1) куки глючат весьма массово и даже если на них опираться, то получится что > кэш обслужит только тех у кого они есть, а их нет как минимум в первый раз. > 2) ключевой момент по regexp описан в первом письме, перечитайте. То, что > есть под нжинкс - убого, использовать можно только для самообмана, а то, что > нормально поддерживается - вагон regexp под php. А хочется-то модуль! > > Я по прежнему не вижу способа на нжинксе с 99% определить мобильного > посетителя. А хочется-то вообще 4 или 5 девяток, а не две... :( > > P.S. А вообще попробовать с кукой можно, в ключ ее - понятно, но как можно > всех без куки направлять на бэкенд не заглядывая в кэш? > > > 2013/1/17 Михаил Монашёв >> >> Здравствуйте, Anton. >> >> > Долго пытался понять как Вы так сами себя обманули? :) мемкеш >> > попутал? Его из этого уравнения лучше вообще удалить, т.к. он ничего >> > не меняет. Проблема остается в том же точке где и была - нжинкс ни >> > при первом ни при втором обращении не знает кто к нему пришел, >> > поэтому невозможно добавить этот признак в ключ кэширования и >> > разделить кэш на мобильный и немобильный. >> >> Почему это нельзя? Очень даже можно. Из конфига есть доступ к кукам. >> Можно регэкспы использовать, которые Вам почему-то не нравится >> использовать. >> >> -- >> С уважением, >> Михаил mailto:postmaster at softsearch.ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Best regards, > Anton Kuznetsov. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Thu Jan 17 06:19:49 2013 From: nginx-forum at nginx.us (softshape) Date: Thu, 17 Jan 2013 01:19:49 -0500 Subject: =?UTF-8?B?0J3QtdGB0LrQvtC70YzQutC+IGFsaWFz?= Message-ID: <10d72dd5cbb1a20f658bf79e20567096.NginxMailingListRussian@forum.nginx.org> Всем привет, хотим сделать так, чтобы для одного location можно было задать несколько alias в порядке приоритета, условно так - location ^~ /css/ { alias /www/project1/css/; expires 1d; alias /www/default/css/; expires 1d; } Если приходит запрос на /css/logo.png, чтобы сначала nginx искал его в project1/css/, а если не нашел, то в default/css/. Есть похожая по смыслу директива try_files, но из документации не очень понятно, как она сочетается с alias. Как сделать правильно? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235194,235194#msg-235194 From hell-for-yahoo at umail.ru Thu Jan 17 06:45:50 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Thu, 17 Jan 2013 10:45:50 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBhbGlhcw==?= In-Reply-To: <10d72dd5cbb1a20f658bf79e20567096.NginxMailingListRussian@forum.nginx.org> References: <10d72dd5cbb1a20f658bf79e20567096.NginxMailingListRussian@forum.nginx.org> Message-ID: <1921680358.20130117104550@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) softshape! s> хотим сделать так, чтобы для одного location можно было задать несколько s> alias в порядке приоритета, условно так - s> location ^~ /css/ { s> alias /www/project1/css/; expires 1d; s> alias /www/default/css/; expires 1d; s> } s> Если приходит запрос на /css/logo.png, чтобы сначала nginx искал его в s> project1/css/, а если не нашел, то в default/css/. Есть похожая по смыслу s> директива try_files, но из документации не очень понятно, как она сочетается s> с alias. s> Как сделать правильно? Скорее, не как, а зачем. Если у вас стоит задача перекрывать отдельные части сайта по мере работы, накапливая изменения в стажировочной области - вам к try_files. Она будет работать именно так, как вы хотите. "Если тута нету, ищем тама". Если вам нужно что-то иное - нормально поставьте задачу. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) четверг, 17.01.2013, <10:43> From postmaster at softsearch.ru Thu Jan 17 08:41:19 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 17 Jan 2013 12:41:19 +0400 Subject: =?UTF-8?B?UmVbNF06IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviA=?= =?UTF-8?B?0LjQvdGC0LXRgNC90LXRgtCwLCDQsCBuZ2lueCDQs9C00LU/?= In-Reply-To: References: <1519954945.20130116221954@softsearch.ru> Message-ID: <118369209.20130117124119@softsearch.ru> Здравствуйте, Anton. > куки глючат весьма массово и даже если на них опираться, то > получится что кэш обслужит только тех у кого они есть, а их нет как > минимум в первый раз. Куки не глючат. На куках делается авторизация на 99% сайтов. Первую куку можно выдавать через внутренний редирект и если её нет, то вы всёравно с первого раза покроете все запросы. > то, что нормально поддерживается - вагон regexp под php. А хочется-то модуль! А что мешает скопировать этот регэксп в nginx. Регэкспы одинаковые и там и там. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Thu Jan 17 08:44:05 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 17 Jan 2013 12:44:05 +0400 Subject: =?UTF-8?B?UmVbNF06IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviA=?= =?UTF-8?B?0LjQvdGC0LXRgNC90LXRgtCwLCDQsCBuZ2lueCDQs9C00LU/?= In-Reply-To: References: <1519954945.20130116221954@softsearch.ru> Message-ID: <171794805.20130117124405@softsearch.ru> Здравствуйте, Anton. > Я по прежнему не вижу способа на нжинксе с 99% определить мобильного > посетителя. А хочется-то вообще 4 или 5 девяток, а не две... :( А зачем нужна такая точность? И ещё важный вопрос: чем именно Ваша мобильная версия отличается от обычной, кроме размера страничек? -- С уважением, Михаил mailto:postmaster at softsearch.ru From kav at karagodov.name Thu Jan 17 08:55:11 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 17 Jan 2013 12:55:11 +0400 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: <171794805.20130117124405@softsearch.ru> References: <1519954945.20130116221954@softsearch.ru> <171794805.20130117124405@softsearch.ru> Message-ID: <89484FC4-B5D2-4D7F-B381-5F94DA16D3A1@karagodov.name> On 17.01.2013, at 12:44, Михаил Монашёв wrote: > Здравствуйте, Anton. > >> Я по прежнему не вижу способа на нжинксе с 99% определить мобильного >> посетителя. А хочется-то вообще 4 или 5 девяток, а не две... :( > > А зачем нужна такая точность? > И ещё важный вопрос: чем именно Ваша мобильная версия отличается от > обычной, кроме размера страничек? ну как бы разница есть, но это дорого стоит в плане дизайна просто либо отдавать клиентосу с монитором 1600х1200 кучу хлама либо отдавать мобильнику 320х240 разница вроде есть это ещё если не учитывать кол-во точек на дюйм, 800х600 можно впихнуть и на 11 дюймов и на 9 и т.д. все клиенты любят индивидуальный подход и поголовно все забивают (мне так кажется) на персональный размер шрифта пользователя. вдруг он к примеру плохо видит > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From kred at gmx.net Thu Jan 17 09:13:46 2013 From: kred at gmx.net (Konstantin Gerasimenko) Date: Thu, 17 Jan 2013 10:13:46 +0100 Subject: =?UTF-8?B?UmU6INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90LjRgNGD?= =?UTF-8?B?0LXRgtGB0Y8/?= In-Reply-To: <3864fdba29483134b4ff4cf0dc155116.NginxMailingListRussian@forum.nginx.org> References: <3864fdba29483134b4ff4cf0dc155116.NginxMailingListRussian@forum.nginx.org> Message-ID: <50F7C0CA.3070202@gmx.net> Привет Trurl, хотел бы с тобой пообщатся на тему балансировки, а так как это не тема данной рассылки прошу найти меня в FB (http://www.facebook.com/kred.gmx.net) или скинь мне на емаил как тебя можно найти. ЗЫ сори за оффтоп ))) Спасибо. From onokonem at gmail.com Thu Jan 17 09:22:04 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 17 Jan 2013 12:22:04 +0300 Subject: =?UTF-8?B?UmU6INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90LjRgNGD?= =?UTF-8?B?0LXRgtGB0Y8/?= In-Reply-To: <50F7C0CA.3070202@gmx.net> References: <3864fdba29483134b4ff4cf0dc155116.NginxMailingListRussian@forum.nginx.org> <50F7C0CA.3070202@gmx.net> Message-ID: > а так как это не тема данной рассылки прошу найти меня в FB > (http://www.facebook.com/kred.gmx.net) У человека есть e-mail, который ему нужен, но он пишет в РАССЫЛКУ и просит найти его в ФЕЙСБУКЕ... язабан, однозначно... PS извините за оффтопик. From nginx-forum at nginx.us Thu Jan 17 09:33:34 2013 From: nginx-forum at nginx.us (softshape) Date: Thu, 17 Jan 2013 04:33:34 -0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBhbGlhcw==?= In-Reply-To: <1921680358.20130117104550@mtu-net.ru> References: <1921680358.20130117104550@mtu-net.ru> Message-ID: <08a711b0a19589effc68a7c8e4493128.NginxMailingListRussian@forum.nginx.org> Ну что ж, поставим нормально :) Есть тестовый сервер, на котором лежат два проекта. У них общий код и много общей статики. Общая для проектов статика лежит, например, в папке /www/statics/default, а индивидуальная статика проектов лежит в папках /www/statics/project1 и /www/statics/project2 соответственно. Задача следующая: при получении запроса вида http://test.project1.ru/css/main.css сначала проверяется наличие файла /www/statics/project1/css/main.css, если его там нет, то /www/statics/default/css/main.css, если и там нет, то уже 404. Аналогично для второго проекта: по запросу http://test.project2.ru/css/main.css сначала проверяется наличие файла /www/statics/project2/css/main.css, если его там нет, то /www/statics/default/css/main.css или 404. Сейчас соответствующая часть конфига для первого проекта выглядит вот так: location ^~ /css/ { try_files /www/statics/project1$uri /www/statics/default$uri; expires 1d; } location = /favicon.ico { #alias /www/statics/default/favicon.ico; try_files /www/statics/project1$uri /www/statics/default$uri; expires 30d; } location / { proxy_pass http://127.0.0.1:8081/; } Проблема в том, что на запрос http://test.project1.ru/css/main.css мы не получаем файл /www/statics/default/css/main.css, а получаем запрос на прокси: http://127.0.0.1:8081/www/statics/default/css/main.css. При запросе фавикона та же песня: http://test.project1.ru/favicon.ico дает запрос на прокси http://127.0.0.1:8081/www/statics/default/favicon.ico, вместо того, чтобы вернуть файл /www/statics/default/favicon.ico, который раньше прекрасно отдавался через alias (я его тут привел закомментированный). Подозреваю, что мы не умеем готовить try_files или где-то недопонимаем синтаксис. Что мы делаем не так, и как именно нужно, чтобы так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235194,235205#msg-235205 From slava.kokorin at gmail.com Thu Jan 17 10:23:13 2013 From: slava.kokorin at gmail.com (Slava Kokorin) Date: Thu, 17 Jan 2013 14:23:13 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBhbGlhcw==?= In-Reply-To: <08a711b0a19589effc68a7c8e4493128.NginxMailingListRussian@forum.nginx.org> References: <1921680358.20130117104550@mtu-net.ru> <08a711b0a19589effc68a7c8e4493128.NginxMailingListRussian@forum.nginx.org> Message-ID: 17 января 2013 г., 13:33 пользователь softshape написал: > Ну что ж, поставим нормально :) > > Есть тестовый сервер, на котором лежат два проекта. У них общий код и много > общей статики. Общая для проектов статика лежит, например, в папке > /www/statics/default, а индивидуальная статика проектов лежит в папках > /www/statics/project1 и /www/statics/project2 соответственно. > > Задача следующая: при получении запроса вида > http://test.project1.ru/css/main.css сначала проверяется наличие файла > /www/statics/project1/css/main.css, если его там нет, то > /www/statics/default/css/main.css, если и там нет, то уже 404. > Аналогично для второго проекта: по запросу > http://test.project2.ru/css/main.css сначала проверяется наличие файла > /www/statics/project2/css/main.css, если его там нет, то > /www/statics/default/css/main.css или 404. > > Сейчас соответствующая часть конфига для первого проекта выглядит вот так: > > location ^~ /css/ { > try_files /www/statics/project1$uri /www/statics/default$uri; > expires 1d; > } > > location = /favicon.ico { > #alias /www/statics/default/favicon.ico; > try_files /www/statics/project1$uri /www/statics/default$uri; > expires 30d; > } > > location / { > proxy_pass http://127.0.0.1:8081/; > } > > Проблема в том, что на запрос http://test.project1.ru/css/main.css мы не > получаем файл /www/statics/default/css/main.css, а получаем запрос на > прокси: http://127.0.0.1:8081/www/statics/default/css/main.css. > При запросе фавикона та же песня: http://test.project1.ru/favicon.ico дает > запрос на прокси http://127.0.0.1:8081/www/statics/default/favicon.ico, > вместо того, чтобы вернуть файл /www/statics/default/favicon.ico, который > раньше прекрасно отдавался через alias (я его тут привел > закомментированный). Судя по http://nginx.org/ru/docs/http/ngx_http_core_module.html#try_files в try_files последним аргументом должен быть либо uri либо код И ещё, "В случае, если ни один файл не найден, то делается внутреннее перенаправление на uri, заданный последним параметром" > > Подозреваю, что мы не умеем готовить try_files или где-то недопонимаем > синтаксис. > > Что мы делаем не так, и как именно нужно, чтобы так? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235194,235205#msg-235205 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Slava From nginx-forum at nginx.us Thu Jan 17 10:52:52 2013 From: nginx-forum at nginx.us (softshape) Date: Thu, 17 Jan 2013 05:52:52 -0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBhbGlhcw==?= In-Reply-To: References: Message-ID: <639fa2d44c134d7c79560cb3b542650f.NginxMailingListRussian@forum.nginx.org> Slava Kokorin Wrote: ------------------------------------------------------- > Судя по > http://nginx.org/ru/docs/http/ngx_http_core_module.html#try_files > в try_files последним аргументом должен быть либо uri либо код > > И ещё, "В случае, если ни один файл не найден, то делается внутреннее > перенаправление на uri, заданный последним параметром" > Да, мы эту документацию по try_files прочитали несколько раз и внимательно. Если в конце ставить код, то оно нам прекрасно возвратит стандартную страницу ошибки nginx. Но вопрос-то в том, что все эти перенаправления и ошибки должны возвращаться только если файла нет. Но файлы-то есть! Вот в чем проблема. Что мы написали в конфиге не так, что nginx не находит эти файлы, хотя раньше с alias'ом находил нормально? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235194,235210#msg-235210 From yura at emict.com Thu Jan 17 11:09:31 2013 From: yura at emict.com (Yuriy Kashirin) Date: Thu, 17 Jan 2013 13:09:31 +0200 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBhbGlhcw==?= In-Reply-To: <639fa2d44c134d7c79560cb3b542650f.NginxMailingListRussian@forum.nginx.org> References: <639fa2d44c134d7c79560cb3b542650f.NginxMailingListRussian@forum.nginx.org> Message-ID: <3066408.9ZLfWOiJ4X@uka-hp.localdomain> On 17 января 2013 05:52:52 softshape wrote: > Slava Kokorin Wrote: > ------------------------------------------------------- > > > location ^~ css { > > try_files /www/statics/project1$uri /www/statics/default$uri; > > expires 1d; > > } > > > > location = /favicon.ico { > > #alias /www/statics/default/favicon.ico; > > try_files /www/statics/project1$uri /www/statics/default$uri; > > expires 30d; > > } > > Да, мы эту документацию по try_files прочитали несколько раз и > внимательно. Нет, не внимательно: "Путь к файлу строится из параметра файл в соответствии с директивами root и alias" А вы указываете имя файла на файловой системе. При проверке файла к указанному вами добавится $document_root. То есть в вашем случае надо как-то так: location ^~ /css/ { root /www/statics; try_files /project1$uri /default$uri =404; expires 1d; } location = /favicon.ico { #alias /www/statics/default/favicon.ico; root /www/statics; try_files /project1/favicon.ico /default/favicon.ico =404; expires 30d; } -- Best regards Yuriy Kashirin From nginx-forum at nginx.us Thu Jan 17 11:25:59 2013 From: nginx-forum at nginx.us (Trurl) Date: Thu, 17 Jan 2013 06:25:59 -0500 Subject: =?UTF-8?B?UmU6INCn0YLQvi3RgtC+INGC0LjQv9CwIGNhY2hlIGRiINC/0LvQsNC90LjRgNGD?= =?UTF-8?B?0LXRgtGB0Y8/?= In-Reply-To: References: Message-ID: Daniel Podolsky Wrote: ------------------------------------------------------- > > а так как это не тема данной рассылки прошу найти меня в FB > > (http://www.facebook.com/kred.gmx.net) > У человека есть e-mail, который ему нужен, но он пишет в РАССЫЛКУ и > просит найти его в ФЕЙСБУКЕ... > язабан, однозначно... > > PS > извините за оффтопик. Это вирусное... PS извините за оффтопик. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235203,235212#msg-235212 From xasima at gmail.com Thu Jan 17 11:27:02 2013 From: xasima at gmail.com (Xasima) Date: Thu, 17 Jan 2013 14:27:02 +0300 Subject: =?UTF-8?B?UmU6IDIxINCy0LXQuiAtINCy0LXQuiDQvNC+0LHQuNC70YzQvdC+0LPQviDQuNC9?= =?UTF-8?B?0YLQtdGA0L3QtdGC0LAsINCwIG5naW54INCz0LTQtT8=?= In-Reply-To: <89484FC4-B5D2-4D7F-B381-5F94DA16D3A1@karagodov.name> References: <1519954945.20130116221954@softsearch.ru> <171794805.20130117124405@softsearch.ru> <89484FC4-B5D2-4D7F-B381-5F94DA16D3A1@karagodov.name> Message-ID: 2013/1/17 Alexey V. Karagodov > > On 17.01.2013, at 12:44, Михаил Монашёв wrote: > > > И ещё важный вопрос: чем именно Ваша мобильная версия отличается от > > обычной, кроме размера страничек? > ну как бы разница есть, но это дорого стоит в плане дизайна просто > либо отдавать клиентосу с монитором 1600х1200 кучу хлама либо отдавать > мобильнику 320х240 > разница вроде есть > это ещё если не учитывать кол-во точек на дюйм, 800х600 можно впихнуть и > на 11 дюймов и на 9 и т.д. > все клиенты любят индивидуальный подход > > и поголовно все забивают (мне так кажется) на персональный размер шрифта > пользователя. вдруг он к примеру плохо видит > Если текстовое содержимое страниц более-менее одинаковое, то через CSS3 media-queries можно подключить совершенно разные файлы стилей, каждый из которых будет срабатывать на своем наборе параметров: width and height of the browser window, device width and height, orientation (landscape /portrait), resolution. Таким же образом можно подтягивать разные разрешения картинок. И, да, использование em-юнитов вместо px в CSS вроде как раз и учитывает персональный размер шрифта, в том числе под мобильными устройствами. Если текстовое содержимое для мобильной и полной версии сильно отличаются (а "прятать" блок текста нельзя), при этом часть текстов заполняются на странице с помощью ajax, тогда и на уровне js можно зацепиться за те же media-queries параметры и отдавать разные наборы текстов в зависимости от параметров устройства (и/или настройках пользователя). Остается, конечно, вариант, когда для мобильного и обычного пользователя - разные наборы "тяжелого" js приложения (аналог "разных" вариантов gmail). Но, в таком случае js уж точно включен и лишнее определение на клиенте вряд ли сыграет определяющую роль. Выгрыш "правильного nginx модуля определения мобильности" в 1) скорости (media-queries требует времени исполнения на клиенте и часто дополнительных запросов к серверу) 2) надежной поддержки старых браузеров (вместо нативного CSS3 в таких случаях нужно использовать обходные маневры типа js-эмуляции) или браузеров с отключенными возможностями (запрещен js) 3) легкости использования слишком специфического для конкретного браузера кода (например, какие-нибудь "большие блоки" HTML5-возможностей, неодинаково реализуемые на разных движках и, соответственно, требующие совершенно разных наборов js кода, может быть трудоемко поддерживать и "менять" на клиентской стороне). 2013/1/17 Михаил Монашёв > то, что нормально поддерживается - вагон regexp под php. А хочется-то модуль! > А что мешает скопировать этот регэксп в nginx. Регэкспы одинаковые и > там и там. > Скопировать (прямо в конфиг или специализированный файл) в любом случае придется. С другой стороны, если кто-то станет писать модуль, то, вероятно, лучше вместо "цикла" проверок (что, вроде бы (?) и делается в serbanghita/Mobile_detect), использовать что-то другое поверх этих регэкспов ( http://bytes.com/topic/python/answers/390189-speeding-up-multiple-regex-matches), если оно будет хорошо вести себя под нагрузкой с т.з. потребляемых ресурсов. > Здравствуйте, Anton. > >> Я по прежнему не вижу способа на нжинксе с 99% определить мобильного >> посетителя. А хочется-то вообще 4 или 5 девяток, а не две... :( Мне кажется, что вопрос скорее смещен в сторону (конечной) скорости определения, чем точности. > > А зачем нужна такая точность? > > > > > -- > > С уважением, > > Михаил mailto:postmaster at softsearch.ru > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, ~ Xasima ~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From scukonick at gmail.com Thu Jan 17 12:08:06 2013 From: scukonick at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzQsNC70L7Qsg==?=) Date: Thu, 17 Jan 2013 16:08:06 +0400 Subject: =?UTF-8?B?0J3QtdGCINC+0YLQstC10YLQsCDQvtGCINGB0LXRgNCy0LXRgNCwIGMgbmdpbngg?= =?UTF-8?B?0L3QsCDQvdC10LrQvtGC0L7RgNGL0LUgc3lu?= Message-ID: Добрый день. Столкнулся со следующей ситуацией. Есть сервер с Debian Squeeze, на нём установлен nginx 0.7.67 (из репозитория). В принципе, всё работает без проблем, но заметили, что иногда не получается приконнектиться к порту. SYN приходит, ответа нет. Пробовал включить syncookies, это несколько помогло (в логах вылезли ошибки про ?possible SYN flooding on port 80. Sending cookies.?). Но всё равно были проблемы с коннектом. Синфлуда при этом нет, это просто много легального трафика. После этого, увеличил следующие параметры: net.core.somaxconn = 128000 net.core.netdev_max_backlog = 10000 net.ipv4.tcp_max_syn_backlog = 128000 ' У нжинкса увеличил listen backlog до 65536. Сообщения про ?possible SYN flooding? исчезли, однако всё равно периодически не приконнектиться к серверу. Проверял простеньким скриптом, который поднимает 20 тредов и открывает и закрывает сокеты к 80-му порту в каждом треде. Из 1000 попыток открыть сокет около 30-50 отваливаются по таймауту (2 секунды), остальные при этом коннектятся практически мгновенно. При всём этом в dmesg пусто, в error.log нжинкса тоже пусто. Кусок конфига нжинкса: user www-data; worker_processes 2; worker_rlimit_nofile 65535; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 65535; use epoll; } server { listen 80 default backlog=65536; ..... } На сервере 2 ядра, LoadAverage держится меньше единицы. В netstat'e примерно такая картина: # netstat -ant | grep tcp | tr -s ' ' ' ' | awk '{print $6}' | sort | uniq -c 22 CLOSING 3729 ESTABLISHED 815 FIN_WAIT1 3807 FIN_WAIT2 138 LAST_ACK 5 LISTEN 167 SYN_RECV 37 SYN_SENT 1104 TIME_WAIT В stub_status'e нжинкса: Active connections: 5985 server accepts handled requests 35200 35200 34437 Reading: 341 Writing: 223 Waiting: 5421 На всякий случай ? SYNы до сервера точно доходят, снимал tcpdump, в нём они видны. Подскажите, пожалуйста, что смотреть, куда копать, кто сталкивался? (у меня есть большие подозрения, что проблема не в самом nginx, но где-то в настройках системы, поэтому заранее прошу прощения за возможный оффтоп). P.s. Задавал этот вопрос на хабре и рассылке debian-ru, извините, если кому-то намозолил глаза. Но ответа пока не нашёл. -- Alexey Malov -------------- next part -------------- An HTML attachment was scrubbed... URL: From panfilov at sports.ru Thu Jan 17 12:28:34 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Thu, 17 Jan 2013 16:28:34 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgiDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC10YDQsCBjIG5n?= =?UTF-8?B?aW54INC90LAg0L3QtdC60L7RgtC+0YDRi9C1IHN5bg==?= In-Reply-To: References: Message-ID: Можно покопать тут: 17 января 2013 г., 16:08 пользователь Алексей Малов написал: > worker_rlimit_nofile 65535; Этот параметр отвечает за количество как входящих, так и исходящих соединений. Если имеется с достаточной нагрузкой proxy_pass, fastcgi_pass и т.д. и т.п. - то, может быть дело в этом. Сколько процессорных ядер на машине? Если больше двух - можно увеличить параметр worker_processes 2; Если два - то увеличить сам worker_rlimit_nofile 65535; -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From panfilov at sports.ru Thu Jan 17 12:33:29 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Thu, 17 Jan 2013 16:33:29 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgiDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC10YDQsCBjIG5n?= =?UTF-8?B?aW54INC90LAg0L3QtdC60L7RgtC+0YDRi9C1IHN5bg==?= In-Reply-To: References: Message-ID: и ещё посмотреть на *worker_connections* *число* http://nginx.org/ru/docs/ngx_core_module.html#worker_connections 17 января 2013 г., 16:28 пользователь Михаил Панфилов написал: > Можно покопать тут: > > > 17 января 2013 г., 16:08 пользователь Алексей Малов написал: > >> worker_rlimit_nofile 65535; > > > Этот параметр отвечает за количество как входящих, так и исходящих > соединений. > Если имеется с достаточной нагрузкой proxy_pass, fastcgi_pass и т.д. и > т.п. - то, может быть дело в этом. > > Сколько процессорных ядер на машине? Если больше двух - можно > увеличить параметр > worker_processes 2; > > Если два - то увеличить сам > > worker_rlimit_nofile 65535; > > > > -- > Панфилов Михаил > > -- Панфилов Михаил Старший системный администратор www.sports.ru + 7 903 578 4067 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scukonick at gmail.com Thu Jan 17 12:42:05 2013 From: scukonick at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzQsNC70L7Qsg==?=) Date: Thu, 17 Jan 2013 16:42:05 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgiDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC10YDQsCBjIG5n?= =?UTF-8?B?aW54INC90LAg0L3QtdC60L7RgtC+0YDRi9C1IHN5bg==?= In-Reply-To: References: Message-ID: 17 января 2013 г., 16:28 пользователь Михаил Панфилов написал: > Можно покопать тут: > > > 17 января 2013 г., 16:08 пользователь Алексей Малов написал: > >> worker_rlimit_nofile 65535; > > > Этот параметр отвечает за количество как входящих, так и исходящих > соединений. > Если имеется с достаточной нагрузкой proxy_pass, fastcgi_pass и т.д. и > т.п. - то, может быть дело в этом. > Попробовал увеличить до 100000, но не помогло. Да и нагрузуки явно нет такой, чтобы были такие числа (в стартовом письме приводил stub_status). > > Сколько процессорных ядер на машине? Если больше двух - можно > увеличить параметр > worker_processes 2; > > Если два - то увеличить сам > > worker_rlimit_nofile 65535; > Да, 2 ядра. И увеличение worker_connections тоже не помогло (сейчас 65 000, а коннектов к серверу на порядок меньше). > > > > > -- > Панфилов Михаил > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Alexey Malov -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Thu Jan 17 13:58:47 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 17 Jan 2013 17:58:47 +0400 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7RgdGC0Lgg0YEg0YDQtdCz0Y3QutGB0L/QsNC80Lgg0LIg?= =?UTF-8?B?0LvQvtC60LXQudGI0L3QtQ==?= Message-ID: <1873019559.20130117175847@softsearch.ru> Здравствуйте. nginx version: nginx/1.3.11 configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module --with-http_stub_status_module --with-pcre Вот такой конфиг location ~* "^/([a-z0-9\-\.]+)/(.*)" { proxy_pass http://$1:80/$2; proxy_set_header Host $1; proxy_set_header Referer "http://$1/"; proxy_set_header X-Real-IP ""; proxy_set_header Cookie ""; proxy_ignore_headers X-Accel-Redirect X-Accel-Expires X-Accel-Limit-Rate X-Accel-Buffering X-Accel-Charset Expires Cache-Control Set-Cookie; proxy_hide_header Location; proxy_hide_header Set-Cookie; proxy_hide_header WWW-Authenticate; proxy_intercept_errors on; error_page 301 302 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 449 500 501 502 503 504 505 506 507 509 510 = @zero; proxy_temp_path /optcache3/proxy-tmp; proxy_cache_key "$1/$2"; proxy_cache optcache3; image_filter test; image_filter_buffer 10M; } location / { return 403; } location @zero { return 204; } приводит в ошибкам: 2013/01/17 17:47:08 [error] 1380#0: *1290729 no host in upstream ":80/", client: 65.55.215.62, server: i99.beon.ru, request: "GET /images5.fanpop.com/image/photos/31100000/Sunggyu-infinite-EC-9D-B8-ED-94-BC-EB-8B-88-ED-8A-B8-31133110-245-182.gif HTTP/1.1", host: "i99.beon.ru" т.е. в $1 почему-то хост теряется. Есть выше в конфиге ещё один локейшн с регэкспами, но он ведь выше и потому должен срабатывать раньше. Причём, если я запрос повторяю, то картинка открывается нормально. Переписал регэксп через именованные переменные: location ~* "^/(?[a-z0-9\-\.]+)/(?.*)" { proxy_pass http://$phost:80/$puri; proxy_set_header Host $1; proxy_set_header Referer "http://$phost/"; proxy_set_header X-Real-IP ""; proxy_set_header Cookie ""; proxy_ignore_headers X-Accel-Redirect X-Accel-Expires X-Accel-Limit-Rate X-Accel-Buffering X-Accel-Charset Expires Cache-Control Set-Cookie; proxy_hide_header Location; proxy_hide_header Set-Cookie; proxy_hide_header WWW-Authenticate; proxy_intercept_errors on; error_page 301 302 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 449 500 501 502 503 504 505 506 507 509 510 = @zero; proxy_temp_path /optcache3/proxy-tmp; proxy_cache_key "$phost/$puri"; proxy_cache optcache3; image_filter test; image_filter_buffer 10M; } location / { return 403; } location @zero { return 204; } Проблема пропала. На более ранних версиях nginx-а проблемы вроде не было, хотя не уверен. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Thu Jan 17 14:21:38 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 17 Jan 2013 18:21:38 +0400 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4g0YLQtdC60YHRgtGDINC+0YjQuNCx0LrQuA==?= Message-ID: <1194802840.20130117182138@softsearch.ru> Здравствуйте. Имеется вот такой конфиг: location ~* "^/(?[a-z0-9\-\.]+)/(?.*)" { proxy_pass http://$phost:80/$puri; proxy_set_header Host $1; proxy_set_header Referer "http://$phost/"; proxy_set_header X-Real-IP ""; proxy_set_header Cookie ""; proxy_ignore_headers X-Accel-Redirect X-Accel-Expires X-Accel-Limit-Rate X-Accel-Buffering X-Accel-Charset Expires Cache-Control Set-Cookie; proxy_hide_header Location; proxy_hide_header Set-Cookie; proxy_hide_header WWW-Authenticate; proxy_intercept_errors on; error_page 301 302 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 449 500 501 502 503 504 505 506 507 509 510 = @zero; proxy_temp_path /optcache3/proxy-tmp; proxy_cache_key "$phost/$puri"; proxy_cache optcache3; image_filter test; image_filter_buffer 10M; } location / { return 403; } location @zero { return 204; } А в логе вот такая ошибка: 2013/01/17 17:47:58 [error] 3963#0: *8162 kevent() reported that connect() failed (60: Operation timed out) while connecting to upstream, client: 80.239.243.119, server: i99.beon.ru, request: "GET /ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg HTTP/1.1", upstream: "http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg", host: "i99.beon.ru", referrer: "http://tanitakokyto.beon.ru/24898-872-tema-dlja-raznyh-anket.zhtml" По идее nginx должен был отрезолвить ishop.top-kniga.ru , соединится с полученным ip и запросить http://ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg Текст ошибки меня удивил. Его я его понял так: не удалось соединиться с ip, в который отрезолвился ishop.top-kniga.ru. Но при это показываются странные данные про апстрим: upstream: "http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg" Хотя мне видится, что он должен быть таким: http://ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg , ведь в конфиге написано: proxy_pass http://$phost:80/$puri; , где $phost - это домен, а не ip. Как получилось http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg понятно. Вопрос в том, правильно ли это? nginx version: nginx/1.3.11 configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module --with-http_stub_status_module --with-pcre -- С уважением, Михаил mailto:postmaster at softsearch.ru From panfilov at sports.ru Thu Jan 17 14:32:47 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Thu, 17 Jan 2013 18:32:47 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGC0LXQutGB0YLRgyDQvtGI0LjQsdC60Lg=?= In-Reply-To: <1194802840.20130117182138@softsearch.ru> References: <1194802840.20130117182138@softsearch.ru> Message-ID: Михаил, обратите внимание: request: "GET */*ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg Кажется, регулярка не сработала правильно, как то задумывалось. 17 января 2013 г., 18:21 пользователь Михаил Монашёв < postmaster at softsearch.ru> написал: > Здравствуйте. > > Имеется вот такой конфиг: > > location ~* "^/(?[a-z0-9\-\.]+)/(?.*)" { > proxy_pass http://$phost:80/$puri; > proxy_set_header Host $1; > proxy_set_header Referer "http://$phost/"; > proxy_set_header X-Real-IP ""; > proxy_set_header Cookie ""; > proxy_ignore_headers X-Accel-Redirect > X-Accel-Expires X-Accel-Limit-Rate X-Accel-Buffering X-Accel-Charset > Expires Cache-Control Set-Cookie; > > proxy_hide_header Location; > proxy_hide_header Set-Cookie; > proxy_hide_header WWW-Authenticate; > > proxy_intercept_errors on; > error_page 301 302 400 401 402 403 > 404 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 > 449 500 501 502 503 504 505 506 507 509 510 = @zero; > > proxy_temp_path /optcache3/proxy-tmp; > proxy_cache_key "$phost/$puri"; > proxy_cache optcache3; > > image_filter test; > image_filter_buffer 10M; > > } > > location / { > return 403; > } > > location @zero { > return 204; > } > > А в логе вот такая ошибка: > 2013/01/17 17:47:58 [error] 3963#0: *8162 kevent() reported that connect() > failed (60: Operation timed out) while connecting to upstream, client: > 80.239.243.119, server: i99.beon.ru, request: "GET / > ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg HTTP/1.1", upstream: " > http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg", host: "i99.beon.ru", > referrer: " > http://tanitakokyto.beon.ru/24898-872-tema-dlja-raznyh-anket.zhtml" > > По идее nginx должен был отрезолвить ishop.top-kniga.ru , соединится > с полученным ip и запросить > http://ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg > > Текст ошибки меня удивил. Его я его понял так: не удалось соединиться > с ip, в который отрезолвился ishop.top-kniga.ru. Но при это > показываются странные данные про апстрим: > upstream: "http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg" > Хотя мне видится, что он должен быть таким: > http://ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg , ведь в > конфиге написано: > proxy_pass http://$phost:80/$puri; > , где $phost - это домен, а не ip. > > Как получилось http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg > понятно. Вопрос в том, правильно ли это? > > > nginx version: nginx/1.3.11 > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx-error.log --user=www --group=www > --with-debug --with-file-aio > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module > --with-http_stub_status_module --with-pcre > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Thu Jan 17 14:37:12 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 17 Jan 2013 18:37:12 +0400 Subject: =?UTF-8?B?UmVbMl06INCS0L7Qv9GA0L7RgSDQv9C+INGC0LXQutGB0YLRgyDQvtGI0LjQsdC6?= =?UTF-8?B?0Lg=?= In-Reply-To: References: <1194802840.20130117182138@softsearch.ru> Message-ID: <251993442.20130117183712@softsearch.ru> Здравствуйте, Михаил. > обратите внимание: > request: "GET /ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg Это исходный запрос так выглядит: http://i99.beon.ru/ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg -- С уважением, Михаил mailto:postmaster at softsearch.ru From panfilov at sports.ru Thu Jan 17 14:41:08 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Thu, 17 Jan 2013 18:41:08 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQktC+0L/RgNC+0YEg0L/QviDRgtC10LrRgdGC0YMg0L7RiNC4?= =?UTF-8?B?0LHQutC4?= In-Reply-To: <251993442.20130117183712@softsearch.ru> References: <1194802840.20130117182138@softsearch.ru> <251993442.20130117183712@softsearch.ru> Message-ID: тогда, пожалуй, надо посмотреть сюда: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_http_version 17 января 2013 г., 18:37 пользователь Михаил Монашёв < postmaster at softsearch.ru> написал: > Здравствуйте, Михаил. > > > обратите внимание: > > > request: "GET /ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg > > Это исходный запрос так выглядит: > http://i99.beon.ru/ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg > > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Thu Jan 17 14:45:55 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 17 Jan 2013 18:45:55 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0YHRgtC4INGBINGA0LXQs9GN0LrRgdC/0LDQvNC4?= =?UTF-8?B?INCyINC70L7QutC10LnRiNC90LU=?= In-Reply-To: <1873019559.20130117175847@softsearch.ru> References: <1873019559.20130117175847@softsearch.ru> Message-ID: <201301171845.56015.vbart@nginx.com> On Thursday 17 January 2013 17:58:47 Михаил Монашёв wrote: > Здравствуйте. > > nginx version: nginx/1.3.11 > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx-error.log --user=www --group=www > --with-debug --with-file-aio > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module > --with-http_stub_status_module --with-pcre > > Вот такой конфиг > > location ~* "^/([a-z0-9\-\.]+)/(.*)" { > proxy_pass http://$1:80/$2; > proxy_set_header Host $1; > proxy_set_header Referer "http://$1/"; > proxy_set_header X-Real-IP ""; > proxy_set_header Cookie ""; > proxy_ignore_headers X-Accel-Redirect > X-Accel-Expires X-Accel-Limit-Rate X-Accel-Buffering X-Accel-Charset > Expires Cache-Control Set-Cookie; > > proxy_hide_header Location; > proxy_hide_header Set-Cookie; > proxy_hide_header WWW-Authenticate; > > proxy_intercept_errors on; > error_page 301 302 400 401 402 403 404 > 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 > 449 500 501 502 503 504 505 506 507 509 510 = @zero; > > proxy_temp_path /optcache3/proxy-tmp; > proxy_cache_key "$1/$2"; > proxy_cache optcache3; > > image_filter test; > image_filter_buffer 10M; > > } > > location / { > return 403; > } > > location @zero { > return 204; > } > > приводит в ошибкам: > 2013/01/17 17:47:08 [error] 1380#0: *1290729 no host in upstream ":80/", > client: 65.55.215.62, server: i99.beon.ru, request: "GET > /images5.fanpop.com/image/photos/31100000/Sunggyu-infinite-EC-9D-B8-ED-94- > BC-EB-8B-88-ED-8A-B8-31133110-245-182.gif HTTP/1.1", host: "i99.beon.ru" > > т.е. в $1 почему-то хост теряется. Есть выше в конфиге ещё один > локейшн с регэкспами, но он ведь выше и потому должен срабатывать > раньше. > > Причём, если я запрос повторяю, то картинка открывается нормально. > [...] Вероятно в конфигурации есть ещё какая-нибудь директива с регулярным выражением, которая наследуется с уровня выше и тоже отрабатывает в этом location-е. Подозреваю valid_referers ? -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From vbart at nginx.com Thu Jan 17 14:48:14 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 17 Jan 2013 18:48:14 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0YHRgtC4INGBINGA0LXQs9GN0LrRgdC/0LDQvNC4?= =?UTF-8?B?INCyINC70L7QutC10LnRiNC90LU=?= In-Reply-To: <201301171845.56015.vbart@nginx.com> References: <1873019559.20130117175847@softsearch.ru> <201301171845.56015.vbart@nginx.com> Message-ID: <201301171848.14292.vbart@nginx.com> On Thursday 17 January 2013 18:45:55 Валентин Бартенев wrote: > On Thursday 17 January 2013 17:58:47 Михаил Монашёв wrote: > > Здравствуйте. > > > > nginx version: nginx/1.3.11 > > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > > --conf-path=/usr/local/etc/nginx/nginx.conf > > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > > --error-log-path=/var/log/nginx-error.log --user=www --group=www > > --with-debug --with-file-aio > > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > > --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module > > --with-http_stub_status_module --with-pcre > > > > Вот такой конфиг > > > > location ~* "^/([a-z0-9\-\.]+)/(.*)" { > > > > proxy_pass http://$1:80/$2; > > proxy_set_header Host $1; > > proxy_set_header Referer "http://$1/"; > > proxy_set_header X-Real-IP ""; > > proxy_set_header Cookie ""; > > proxy_ignore_headers X-Accel-Redirect > > > > X-Accel-Expires X-Accel-Limit-Rate X-Accel-Buffering X-Accel-Charset > > Expires Cache-Control Set-Cookie; > > > > proxy_hide_header Location; > > proxy_hide_header Set-Cookie; > > proxy_hide_header WWW-Authenticate; > > > > proxy_intercept_errors on; > > error_page 301 302 400 401 402 403 > > 404 > > > > 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 > > 449 500 501 502 503 504 505 506 507 509 510 = @zero; > > > > proxy_temp_path /optcache3/proxy-tmp; > > proxy_cache_key "$1/$2"; > > proxy_cache optcache3; > > > > image_filter test; > > image_filter_buffer 10M; > > > > } > > > > location / { > > > > return 403; > > > > } > > > > location @zero { > > > > return 204; > > > > } > > > > приводит в ошибкам: > > 2013/01/17 17:47:08 [error] 1380#0: *1290729 no host in upstream ":80/", > > client: 65.55.215.62, server: i99.beon.ru, request: "GET > > /images5.fanpop.com/image/photos/31100000/Sunggyu-infinite-EC-9D-B8-ED-94 > > - BC-EB-8B-88-ED-8A-B8-31133110-245-182.gif HTTP/1.1", host: > > "i99.beon.ru" > > > > т.е. в $1 почему-то хост теряется. Есть выше в конфиге ещё один > > локейшн с регэкспами, но он ведь выше и потому должен срабатывать > > раньше. > > > > Причём, если я запрос повторяю, то картинка открывается нормально. > > [...] > > Вероятно в конфигурации есть ещё какая-нибудь директива с регулярным > выражением, которая наследуется с уровня выше и тоже отрабатывает в этом > location-е. > > Подозреваю valid_referers ? > А нет, valid_referers тут скорее не причем. Значит что-то ещё. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From onokonem at gmail.com Thu Jan 17 15:04:16 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 17 Jan 2013 18:04:16 +0300 Subject: ssi include, how to get original request uri Message-ID: День добрый! Имею html, в нем - include virtual. include показывает на location, проксируемый на другой сервер. Все прекрасно работает. Но - я хочу знать на том, другом сервере URI того документа, в котором прописан include virtual. Как это лучше всего организовать? Спасибо. С уважением, Даниил Подольский. PS В гугл я глядел, но то ли тема не очень популярная, то ли я вопрос правильно сформулировать не сумел. Нашел один безответный вопрос, идентичный моему, и все. From postmaster at softsearch.ru Thu Jan 17 16:11:59 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 17 Jan 2013 20:11:59 +0400 Subject: =?UTF-8?B?UmVbMl06INCh0YLRgNCw0L3QvdC+0YHRgtC4INGBINGA0LXQs9GN0LrRgdC/0LA=?= =?UTF-8?B?0LzQuCDQsiDQu9C+0LrQtdC50YjQvdC1?= In-Reply-To: <201301171845.56015.vbart@nginx.com> References: <1873019559.20130117175847@softsearch.ru> <201301171845.56015.vbart@nginx.com> Message-ID: <1381372416.20130117201159@softsearch.ru> Здравствуйте, Валентин. > Вероятно в конфигурации есть ещё какая-нибудь директива с регулярным выражением, > которая наследуется с уровня выше и тоже отрабатывает в этом location-е. > Подозреваю valid_referers ? Да, она есть. Видимо она и стирает $1; -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Thu Jan 17 16:13:37 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 17 Jan 2013 20:13:37 +0400 Subject: =?UTF-8?B?UmVbMl06INCh0YLRgNCw0L3QvdC+0YHRgtC4INGBINGA0LXQs9GN0LrRgdC/0LA=?= =?UTF-8?B?0LzQuCDQsiDQu9C+0LrQtdC50YjQvdC1?= In-Reply-To: <201301171848.14292.vbart@nginx.com> References: <1873019559.20130117175847@softsearch.ru> <201301171845.56015.vbart@nginx.com> <201301171848.14292.vbart@nginx.com> Message-ID: <5410521751.20130117201337@softsearch.ru> Здравствуйте, Валентин. >> Вероятно в конфигурации есть ещё какая-нибудь директива с регулярным >> выражением, которая наследуется с уровня выше и тоже отрабатывает в этом >> location-е. >> >> Подозреваю valid_referers ? >> > А нет, valid_referers тут скорее не причем. Значит что-то ещё. Вот это может? map $http_user_agent $bot_ua { default ""; ~bot bot; } -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Thu Jan 17 16:19:18 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 17 Jan 2013 20:19:18 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0YHRgtC4INGBINGA0LXQs9GN0LrRgdC/0LDQvNC4?= =?UTF-8?B?INCyINC70L7QutC10LnRiNC90LU=?= In-Reply-To: <5410521751.20130117201337@softsearch.ru> References: <1873019559.20130117175847@softsearch.ru> <201301171848.14292.vbart@nginx.com> <5410521751.20130117201337@softsearch.ru> Message-ID: <201301172019.18974.vbart@nginx.com> On Thursday 17 January 2013 20:13:37 Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> Вероятно в конфигурации есть ещё какая-нибудь директива с регулярным > >> выражением, которая наследуется с уровня выше и тоже отрабатывает в этом > >> location-е. > >> > >> Подозреваю valid_referers ? > > > > А нет, valid_referers тут скорее не причем. Значит что-то ещё. > > Вот это может? > map $http_user_agent $bot_ua { > default ""; > ~bot bot; > } Я не вижу переменную $bot_ua в обсуждаемом блоке location. По той же причине я отказался от своего предположения про valid_referers, поскольку и переменной $invalid_referer в нём тоже нет. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From gmm at csdoc.com Thu Jan 17 16:46:57 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 17 Jan 2013 18:46:57 +0200 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGC0LXQutGB0YLRgyDQvtGI0LjQsdC60Lg=?= In-Reply-To: <1194802840.20130117182138@softsearch.ru> References: <1194802840.20130117182138@softsearch.ru> Message-ID: <50F82B01.1010907@csdoc.com> On 17.01.2013 16:21, Михаил Монашёв wrote: > location ~* "^/(?[a-z0-9\-\.]+)/(?.*)" { > proxy_pass http://$phost:80/$puri; > proxy_set_header Host $1; > proxy_set_header Referer "http://$phost/"; > в логе вот такая ошибка: > 2013/01/17 17:47:58 [error] 3963#0: *8162 kevent() reported that connect() failed (60: Operation timed out) while connecting to upstream, client: 80.239.243.119, server: i99.beon.ru, request: "GET /ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg HTTP/1.1", upstream: "http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg", host: "i99.beon.ru", referrer: "http://tanitakokyto.beon.ru/24898-872-tema-dlja-raznyh-anket.zhtml" > > По идее nginx должен был отрезолвить ishop.top-kniga.ru , соединится > с полученным ip и запросить http://ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg > Текст ошибки меня удивил. Его я его понял так: не удалось соединиться > с ip, в который отрезолвился ishop.top-kniga.ru. Но при это > показываются странные данные про апстрим: > upstream: "http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg" > Хотя мне видится, что он должен быть таким: > http://ishop.top-kniga.ru/data/m_ishc/1084/1084845.jpg , ведь в > конфиге написано: > proxy_pass http://$phost:80/$puri; > , где $phost - это домен, а не ip. > > Как получилось http://91.206.106.43:80/data/m_ishc/1084/1084845.jpg > понятно. Вопрос в том, правильно ли это? судя по описанию http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_pass - да, так и должно быть. ведь доменное имя ishop.top-kniga.ru в общем случае может ресолвиться в несколько разных IP, и если скрывать адрес апстрима, с которым не удалось соединиться - толку от такого декоративного лога будет мало. особенно, если апстрим будет задан отдельным блоком upstream { ... } ==================================================================== Имя сервера, его порт и передаваемый URI можно также полностью задать с помощью переменных: proxy_pass http://$host$uri; или даже так: proxy_pass $request; В этом случае имя сервера ищется среди описанных групп серверов и если не найдено, то определяется с помощью resolver?а. ==================================================================== -- Best regards, Gena From postmaster at softsearch.ru Thu Jan 17 17:13:52 2013 From: postmaster at softsearch.ru (=?Windows-1251?B?zOj14OjrIMzu7eD4uOI=?=) Date: Thu, 17 Jan 2013 21:13:52 +0400 Subject: =?UTF-8?B?UmVbMl06INCS0L7Qv9GA0L7RgSDQv9C+INGC0LXQutGB0YLRgyDQvtGI0LjQsdC6?= =?UTF-8?B?0Lg=?= In-Reply-To: <50F82B01.1010907@csdoc.com> References: <1194802840.20130117182138@softsearch.ru> <50F82B01.1010907@csdoc.com> Message-ID: <1007976511.20130117211352@softsearch.ru> Здравствуйте, Gena. > ==================================================================== > Имя сервера, его порт и передаваемый URI можно также полностью задать с > помощью переменных: > proxy_pass http://$host$uri; > или даже так: > proxy_pass $request; > В этом случае имя сервера ищется среди описанных групп серверов и если > не найдено, то определяется с помощью resolver?а. > ==================================================================== Заметил тут небольшое поле для микрооптимизации: сначала мы склеиваем из нескольких частей хост и ури, а потом nginx их парсит, выделяет из них хост и ури. Логично было бы дать возможность задавать хост и ури отдельно, дабы сэкономить процессор. -- С уважением, Михаил mailto:postmaster at softsearch.ru From bondarets at gmail.com Thu Jan 17 19:47:26 2013 From: bondarets at gmail.com (Ivan Bondarets) Date: Thu, 17 Jan 2013 23:47:26 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: References: Message-ID: Никто не знает? Или вопрос обсосан уже давно? Я гуглил (в том числе и по архиву рассылки), но не нашел ничего похожего. Неужели кроме как лопатить сорцы или пробовать угадать формат по кускам лога нет вариантов? Какой-то ведь должен быть цивилизованный способ. 16 января 2013 г., 15:50 пользователь Un Lexx написал: > проше прощения не заметил что речь про error.log > > > 16 января 2013 г., 17:48 пользователь Un Lexx написал: > > http://www.nginx.org/ru/docs/http/ngx_http_log_module.html >> >> >> 16 января 2013 г., 16:57 пользователь Ivan Bondarets > > написал: >> >>> Добрый день! >>> Пытаюсь разработать парсер для дефолтного error.log (описан в секции >>> main, далее просто наследуется), но нигде не могу найти описание формата >>> лога. менять его нельзя, насколько я понял, но хотя бы узнать, в каком >>> формате он пишет можно? Где-нибудь есть описание? >>> Без описания формата довольно трудно сделать нормальный парсер. >>> >>> Иван. >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Thu Jan 17 20:24:14 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 00:24:14 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: References: Message-ID: <1037688526.20130118002414@softsearch.ru> Здравствуйте, Ivan. Формат там разнообразный. Фиксированы похоже только первые 3 столбца, а далее идёт текст ошибки. Если в парсере заменять все числа, строки в кавычках и строки, идущие от двоеточия до запятой и не содержащие пробелов на ХХХ, то получится свернуть всё разнообразие сообщение в несколько шаблонных фраз. Ну и ради примера приводить одну несвёрнутую ошибку ещё можно. Полезная тулза, кстати получится. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Thu Jan 17 20:26:59 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 00:26:59 +0400 Subject: =?UTF-8?B?UmVbMl06INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: <1037688526.20130118002414@softsearch.ru> References: <1037688526.20130118002414@softsearch.ru> Message-ID: <831400174.20130118002659@softsearch.ru> Здравствуйте. Вдогонку... http://www.retards.org/projects/mysql/ - вот скрипт, который делает подобную свёртку для mysql slow logs. -- С уважением, Михаил mailto:postmaster at softsearch.ru From voron at amhost.net Thu Jan 17 20:35:29 2013 From: voron at amhost.net (Alex Vorona) Date: Thu, 17 Jan 2013 22:35:29 +0200 Subject: =?UTF-8?B?UmU6INCd0LXRgiDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC10YDQsCBjIG5n?= =?UTF-8?B?aW54INC90LAg0L3QtdC60L7RgtC+0YDRi9C1IHN5bg==?= In-Reply-To: References: Message-ID: <50F86091.8050402@amhost.net> 17.01.2013 14:08, Алексей Малов wrote: [...] > Из 1000 попыток открыть сокет около 30-50 отваливаются по таймауту (2 > секунды), остальные при этом коннектятся практически мгновенно. А что делают воркеры nginx? Не с диска отдают случайно данные, блокируясь при этом? From bdfy at mail.ru Thu Jan 17 21:30:45 2013 From: bdfy at mail.ru (=?UTF-8?B?SXZhbg==?=) Date: Fri, 18 Jan 2013 01:30:45 +0400 Subject: =?UTF-8?B?0JrQsNC6INGB0LvQvtC20LjRgtGMIDIg0L/QtdGA0LXQvNC10L3QvdGL0YUgPw==?= Message-ID: <1358458245.800633747@f328.mail.ru>   location ~ ^/test {    set $a 1;    set $b 1;    set $c $a+$b;     return 200 $c; результат 1+1. А как показать сумму 2 переменных ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Thu Jan 17 22:01:00 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 02:01:00 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC70L7QttC40YLRjCAyINC/0LXRgNC10LzQtdC90L3Ri9GF?= =?UTF-8?B?ID8=?= In-Reply-To: <1358458245.800633747@f328.mail.ru> References: <1358458245.800633747@f328.mail.ru> Message-ID: <1473072638.20130118020100@softsearch.ru> Здравствуйте, Ivan. Встроенным перлом: http://nginx.org/ru/docs/http/ngx_http_perl_module.html -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Jan 18 03:22:08 2013 From: nginx-forum at nginx.us (softshape) Date: Thu, 17 Jan 2013 22:22:08 -0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBhbGlhcw==?= In-Reply-To: <3066408.9ZLfWOiJ4X@uka-hp.localdomain> References: <3066408.9ZLfWOiJ4X@uka-hp.localdomain> Message-ID: <9e68b31e7e2f5298203cb668f8587824.NginxMailingListRussian@forum.nginx.org> Yuriy Kashirin Wrote: ------------------------------------------------------- > On 17 января 2013 05:52:52 softshape wrote: > > Slava Kokorin Wrote: > > ------------------------------------------------------- > > > > > > location ^~ css { > > > try_files /www/statics/project1$uri /www/statics/default$uri; > > > expires 1d; > > > } > > > > > > location = /favicon.ico { > > > #alias /www/statics/default/favicon.ico; > > > try_files /www/statics/project1$uri /www/statics/default$uri; > > > expires 30d; > > > } > > > > > > Да, мы эту документацию по try_files прочитали несколько раз и > > внимательно. > > Нет, не внимательно: > > "Путь к файлу строится из параметра файл в соответствии с директивами > root и alias" > > А вы указываете имя файла на файловой системе. При проверке файла к > указанному вами добавится $document_root. > > То есть в вашем случае надо как-то так: > > location ^~ /css/ { > root /www/statics; > try_files /project1$uri /default$uri =404; > expires 1d; > } > > location = /favicon.ico { > #alias /www/statics/default/favicon.ico; > root /www/statics; > try_files /project1/favicon.ico /default/favicon.ico =404; > expires 30d; > } Ваш рецепт действует ровно так же, как и указание полных путей, только в прокси теперь уходит http://127.0.0.1:8081/default/css/main.css, что никак не решает вопрос. PS. Пардон, не заметил, что у нас нет =404 в конце; перепроверил еще раз: да, это решает вопрос. Но почему с =404 мы получаем то, что нужно, а без него ? то, что описано выше? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235194,235251#msg-235251 From voron at amhost.net Fri Jan 18 06:58:06 2013 From: voron at amhost.net (Alex Vorona) Date: Fri, 18 Jan 2013 08:58:06 +0200 Subject: ssi include, how to get original request uri In-Reply-To: References: Message-ID: <50F8F27E.9030601@amhost.net> 17.01.2013 17:04, Daniel Podolsky wrote: > День добрый! > > Имею html, в нем - include virtual. > > include показывает на location, проксируемый на другой сервер. > > Все прекрасно работает. Но - я хочу знать на том, другом сервере URI > того документа, в котором прописан include virtual. > > Как это лучше всего организовать? в location c проксированием proxy_set_header X-URI $request_uri; From voron at amhost.net Fri Jan 18 07:08:35 2013 From: voron at amhost.net (Alex Vorona) Date: Fri, 18 Jan 2013 09:08:35 +0200 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBhbGlhcw==?= In-Reply-To: <9e68b31e7e2f5298203cb668f8587824.NginxMailingListRussian@forum.nginx.org> References: <3066408.9ZLfWOiJ4X@uka-hp.localdomain> <9e68b31e7e2f5298203cb668f8587824.NginxMailingListRussian@forum.nginx.org> Message-ID: <50F8F4F3.7070304@amhost.net> 18.01.2013 05:22, softshape wrote: > PS. Пардон, не заметил, что у нас нет =404 в конце; перепроверил еще раз: > да, это решает вопрос. Но почему с =404 мы получаем то, что нужно, а без > него ? то, что описано выше? Потому что без =404 "делается внутреннее перенаправление на uri, заданный последним параметром", которым у вас является файл, а не uri. Обратите внимание на синтаксис директивы. From onokonem at gmail.com Fri Jan 18 07:15:39 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 18 Jan 2013 10:15:39 +0300 Subject: ssi include, how to get original request uri In-Reply-To: <50F8F27E.9030601@amhost.net> References: <50F8F27E.9030601@amhost.net> Message-ID: > в location c проксированием > proxy_set_header X-URI $request_uri; И правда: $request_uri This variable is equal to the *original* request URI as received from the client including the args. It cannot be modified. Look at $uri for the post-rewrite/altered URI. Does not include host name. Спасибо! From ufaweb at gmail.com Fri Jan 18 08:48:32 2013 From: ufaweb at gmail.com (=?UTF-8?B?0KDRg9GB0LvQsNC9INCo0LDRgNC40L/QvtCy?=) Date: Fri, 18 Jan 2013 14:48:32 +0600 Subject: =?UTF-8?B?0JrQtdGI0LjRgNC+0LLQsNC90LjQtSDQvtGC0LLQtdGC0L7QsiDQtNC70Y8g0L0=?= =?UTF-8?B?0LUg0LDQstGC0L7RgNC40LfQvtCy0LDQvdC90YvRhSDQv9C+0LvRjNC30L4=?= =?UTF-8?B?0LLQsNGC0LXQu9C10Lk=?= Message-ID: День добрый. Задача: отдавать ответ из кеша для всех запросов без определенной куки (sessionid), т.е. чтобы неавторизованные пользователи не стучались к апачу (точнее стучались реже, раз в 10 минут). Использую следующий конфиг: log_format cache "Code: $status Session: $cookie_sessionid Cache: $upstream_cache_status Response time: $upstream_response_time Uri: $uri"; proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=cache:10m max_size=1000m; server { include includes/listen.conf; server_name domain; client_max_body_size 100m; location / { access_log /var/log/nginx/domain.ru.access.log cache; error_log /var/log/nginx/domain.ru.error.log debug; proxy_ignore_headers Expires Cache-Control; proxy_cache_bypass $cookie_sessionid; proxy_no_cache $cookie_sessionid; proxy_cache cache; proxy_cache_lock on; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504; proxy_cache_valid 200 10m; proxy_cache_methods GET HEAD; proxy_pass http://127.0.0.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; } } Далее посылаю шесть запросов, три без куки sessionid, три с кукой, в логе вижу следующее: root at test:/etc/nginx/sites-enabled# tail -f /var/log/nginx/domain.ru.access.log Code: 200 Session: - Cache: MISS Response time: 0.007 Uri: / Code: 200 Session: - Cache: MISS Response time: 0.007 Uri: / Code: 200 Session: - Cache: MISS Response time: 0.006 Uri: / Code: 200 Session: f889bfe0e2577b848418f512fd7e8df5 Cache: BYPASS Response time: 0.008 Uri: / Code: 200 Session: f889bfe0e2577b848418f512fd7e8df5 Cache: BYPASS Response time: 0.009 Uri: / Code: 200 Session: f889bfe0e2577b848418f512fd7e8df5 Cache: BYPASS Response time: 0.010 Uri: / все шесть запросов ушли к апачу, хотя я ожидал, что из первых трех уйдет только первый (чтобы сформировать содержимое кеша), а последующие два к апачу уходить не будут. подскажите пожалуйста, что я делаю не так и как мне решить мою задачу? спасибо. p.s. root at test:/etc/nginx/sites-enabled# nginx -V nginx version: nginx/1.2.1 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module p.s. в логе переменная $cookie_sessionid в случае отсутствия куки sesionid почему-то помещает не пустую строку, а символ "-", я сначала подумал что дело в это (согласно документации директив proxy_cache_bypass и proxy_no_cache для того чтобы ответ взялся из кеша указанная переменная должна содержать пустую строку (или 0), поэтому я добавил map {} блок, который превращал "-" в ""), но это ничего не изменило, поэтому я предполагаю что проблема в чем-то ином. -- С уважением, Шарипов Руслан. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at vereshagin.org Fri Jan 18 09:24:36 2013 From: peter at vereshagin.org (Peter Vereshagin) Date: Fri, 18 Jan 2013 13:24:36 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0YHRgtC4INGBINGA0LXQs9GN0LrRgdC/0LDQvNC4?= =?UTF-8?B?INCyINC70L7QutC10LnRiNC90LU=?= In-Reply-To: <1381372416.20130117201159@softsearch.ru> References: <1873019559.20130117175847@softsearch.ru> <201301171845.56015.vbart@nginx.com> <1381372416.20130117201159@softsearch.ru> Message-ID: <20130118092436.GB31552@external.screwed.box> Hello. 2013/01/17 20:11:59 +0400 Михаил Монашёв => To Валентин Бартенев : > Да, она есть. Видимо она и стирает $1; Не порверял, но интересно, раболтает ли в nginx.conf named capture, которое может с этим помочь: You can dispense with numbers altogether and create named capture groups. The notation is "(?...)" to declare and "\g{name}" to reference. You can refer to them by absolute number (using "$1" instead of "\g1", etc); or by name via the "%+" hash, using "$+{name}". (perlre) Thank you. -- Peter Vereshagin (http://vereshagin.org) pgp: 1754B9C1 From postmaster at softsearch.ru Fri Jan 18 09:28:44 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 13:28:44 +0400 Subject: =?UTF-8?B?UmVbMl06INCh0YLRgNCw0L3QvdC+0YHRgtC4INGBINGA0LXQs9GN0LrRgdC/0LA=?= =?UTF-8?B?0LzQuCDQsiDQu9C+0LrQtdC50YjQvdC1?= In-Reply-To: <20130118092436.GB31552@external.screwed.box> References: <1873019559.20130117175847@softsearch.ru> <201301171845.56015.vbart@nginx.com> <1381372416.20130117201159@softsearch.ru> <20130118092436.GB31552@external.screwed.box> Message-ID: <1173397318.20130118132844@softsearch.ru> Здравствуйте, Peter. >> Да, она есть. Видимо она и стирает $1; > Не порверял, но интересно, раболтает ли в nginx.conf named capture, > которое может с этим помочь: Вы до конца моё исходное письмо прочтите. Я с их помощью и исправил ситуацию. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Jan 18 09:36:16 2013 From: nginx-forum at nginx.us (somebi) Date: Fri, 18 Jan 2013 04:36:16 -0500 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0LjQt9C+0LHRgNCw0LbQtdC90Lg=?= =?UTF-8?B?0Lkg0YfQtdGA0LXQtyBOZ2lueCDQsiBGbGFzaC4=?= Message-ID: <36e27d319b7b63a9735b78180200ec63.NginxMailingListRussian@forum.nginx.org> Все работает, когда я пытаюсь открыть картинку напрямую в браузере. Оно так же работает в флеше, но только на маленьких картинках, типа этой: /?url=http://thumbs.wallbase.cc/rozne/thumb-415891.jpg И не работает, когда я пытаюсь загрузить картинку побольше, возвращая стандартную страницу для 503 заголовока ответа: /?url=http://ns223506.ovh.net/rozne/77ffb14e20ba1899bec2fb29c9cda391/wallpaper-415891.jpg Я собрал последнюю версию nginx-1.3.11 на Ubuntu. Код код и конфиг: Actionscript: // Download image and emit when it's downloaded public function download(url:String,proxy:Boolean=false):*{ var listener:Object = new Emitter(); var req:URLRequest=new URLRequest(); if(proxy && settings.proxy) { req.url=settings.proxy; req.data=url; } else { req.url=url; } var loader:Loader=new Loader(); // For http://example.com/crossdomain.xml check // var loaderContext:LoaderContext = new LoaderContext(true); loader.contentLoaderInfo.addEventListener(Event.COMPLETE,function():void{ listener.emit('downloaded',null,loader); }); loader.load(req); // ,loaderContext return listener; } Nginx: worker_processes 1; error_log logs/error.log debug; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { server_name petslv.cloudapp.net; listen 8000; location = /favicon.ico { return 204; access_log off; log_not_found off; break; } location / { resolver 8.8.8.8; proxy_buffering on; proxy_buffer_size 8k; proxy_buffers 2048 8k; proxy_pass $arg_url; } } } Я пересобрал nginx с --with-debug и вот лог: 2013/01/18 09:32:40 [debug] 12882#0: epoll: fd:6 ev:0001 d:00007F37530CC010 2013/01/18 09:32:40 [debug] 12882#0: accept on 0.0.0.0:8000, ready: 0 2013/01/18 09:32:40 [debug] 12882#0: posix_memalign: 0000000001671350:256 @16 2013/01/18 09:32:40 [debug] 12882#0: *1 accept: 89.254.130.254 fd:4 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer add: 4: 60000:1358501620864 2013/01/18 09:32:40 [debug] 12882#0: *1 epoll add event: fd:4 op:1 ev:80000001 2013/01/18 09:32:40 [debug] 12882#0: timer delta: 67080 2013/01/18 09:32:40 [debug] 12882#0: posted events 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: worker cycle 2013/01/18 09:32:40 [debug] 12882#0: epoll timer: 60000 2013/01/18 09:32:40 [debug] 12882#0: epoll: fd:4 ev:0001 d:00007F37530CC180 2013/01/18 09:32:40 [debug] 12882#0: *1 malloc: 000000000167C6D0:1272 2013/01/18 09:32:40 [debug] 12882#0: *1 posix_memalign: 000000000167CBD0:256 @16 2013/01/18 09:32:40 [debug] 12882#0: *1 malloc: 0000000001685450:1024 2013/01/18 09:32:40 [debug] 12882#0: *1 posix_memalign: 0000000001675EA0:4096 @16 2013/01/18 09:32:40 [debug] 12882#0: *1 http process request line 2013/01/18 09:32:40 [debug] 12882#0: *1 recv: fd:4 584 of 1024 2013/01/18 09:32:40 [debug] 12882#0: *1 http request line: "GET /?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg HTTP/1.1" 2013/01/18 09:32:40 [debug] 12882#0: *1 http uri: "/" 2013/01/18 09:32:40 [debug] 12882#0: *1 http args: "url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http exten: "" 2013/01/18 09:32:40 [debug] 12882#0: *1 http process request header line 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Host: mydomain.com:8000" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Connection: keep-alive" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Accept: */*" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Referer: http://mydomain.com/admin/add" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Accept-Encoding: gzip,deflate,sdch" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header: "Cookie: rememberme=37ddd82d8fc5ab229f9e1dc49986b65d; ssid=bfdfa23167988f6cff0a49489d5efbf1751cc32e" 2013/01/18 09:32:40 [debug] 12882#0: *1 http header done 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer del: 4: 1358501620864 2013/01/18 09:32:40 [debug] 12882#0: *1 rewrite phase: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 test location: "/" 2013/01/18 09:32:40 [debug] 12882#0: *1 using configuration "/" 2013/01/18 09:32:40 [debug] 12882#0: *1 http cl:-1 max:1048576 2013/01/18 09:32:40 [debug] 12882#0: *1 rewrite phase: 2 2013/01/18 09:32:40 [debug] 12882#0: *1 post rewrite phase: 3 2013/01/18 09:32:40 [debug] 12882#0: *1 generic phase: 4 2013/01/18 09:32:40 [debug] 12882#0: *1 generic phase: 5 2013/01/18 09:32:40 [debug] 12882#0: *1 access phase: 6 2013/01/18 09:32:40 [debug] 12882#0: *1 access phase: 7 2013/01/18 09:32:40 [debug] 12882#0: *1 post access phase: 8 2013/01/18 09:32:40 [debug] 12882#0: *1 http script var: "http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http init upstream, client timer: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 epoll add event: fd:4 op:3 ev:80000005 2013/01/18 09:32:40 [debug] 12882#0: *1 posix_memalign: 0000000001676EB0:4096 @16 2013/01/18 09:32:40 [debug] 12882#0: *1 http script copy: "Host: " 2013/01/18 09:32:40 [debug] 12882#0: *1 http script var: "ns223506.ovh.net" 2013/01/18 09:32:40 [debug] 12882#0: *1 http script copy: " " 2013/01/18 09:32:40 [debug] 12882#0: *1 http script copy: "Connection: close " 2013/01/18 09:32:40 [debug] 12882#0: *1 http script copy: "" 2013/01/18 09:32:40 [debug] 12882#0: *1 http script copy: "" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Accept: */*" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Referer: http://mydomain.com/admin/add" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Accept-Encoding: gzip,deflate,sdch" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Cookie: rememberme=37ddd82d8fc5ab229f9e1dc49986b65d; ssid=bfdfa23167988f6cff0a49489d5efbf1751cc32e" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "GET /rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg HTTP/1.0 Host: ns223506.ovh.net Connection: close User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17 Accept: */* Referer: http://mydomain.com/admin/add Accept-Encoding: gzip,deflate,sdch Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3 Cookie: rememberme=37ddd82d8fc5ab229f9e1dc49986b65d; ssid=bfdfa23167988f6cff0a49489d5efbf1751cc32e " 2013/01/18 09:32:40 [debug] 12882#0: *1 http cleanup add: 0000000001677188 2013/01/18 09:32:40 [debug] 12882#0: malloc: 000000000167CCE0:136 2013/01/18 09:32:40 [debug] 12882#0: resolve: "ns223506.ovh.net" 2013/01/18 09:32:40 [debug] 12882#0: malloc: 00000000016716E0:120 2013/01/18 09:32:40 [debug] 12882#0: malloc: 000000000167CD70:16 2013/01/18 09:32:40 [debug] 12882#0: malloc: 000000000167CD90:34 2013/01/18 09:32:40 [debug] 12882#0: resolve: "ns223506.ovh.net" 11426 2013/01/18 09:32:40 [debug] 12882#0: UDP socket 5 2013/01/18 09:32:40 [debug] 12882#0: connect to 8.8.8.8:53, fd:5 #2 2013/01/18 09:32:40 [debug] 12882#0: epoll add event: fd:5 op:1 ev:80000001 2013/01/18 09:32:40 [debug] 12882#0: send: fd:5 34 of 34 2013/01/18 09:32:40 [debug] 12882#0: malloc: 000000000167CDC0:104 2013/01/18 09:32:40 [debug] 12882#0: event timer add: -1: 30000:1358501590872 2013/01/18 09:32:40 [debug] 12882#0: event timer add: -1: 5000:1358501565872 2013/01/18 09:32:40 [debug] 12882#0: *1 http finalize request: -4, "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" a:1, c:2 2013/01/18 09:32:40 [debug] 12882#0: *1 http request count:2 blk:0 2013/01/18 09:32:40 [debug] 12882#0: timer delta: 8 2013/01/18 09:32:40 [debug] 12882#0: posted events 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: worker cycle 2013/01/18 09:32:40 [debug] 12882#0: epoll timer: 5000 2013/01/18 09:32:40 [debug] 12882#0: epoll: fd:4 ev:0004 d:00007F37530CC180 2013/01/18 09:32:40 [debug] 12882#0: *1 http run request: "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream check client, write event:1, "/" 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream recv(): -1 (11: Resource temporarily unavailable) 2013/01/18 09:32:40 [debug] 12882#0: timer delta: 0 2013/01/18 09:32:40 [debug] 12882#0: posted events 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: worker cycle 2013/01/18 09:32:40 [debug] 12882#0: epoll timer: 5000 2013/01/18 09:32:40 [debug] 12882#0: epoll: fd:5 ev:0001 d:00007F37530CC238 2013/01/18 09:32:40 [debug] 12882#0: recv: fd:5 50 of 4096 2013/01/18 09:32:40 [debug] 12882#0: resolver DNS response 11426 fl:8180 1/1/0/0 2013/01/18 09:32:40 [debug] 12882#0: resolver DNS response qt:1 cl:1 2013/01/18 09:32:40 [debug] 12882#0: malloc: 000000000167CE30:16 2013/01/18 09:32:40 [debug] 12882#0: resolver qs:ns223506.ovh.net 2013/01/18 09:32:40 [debug] 12882#0: resolver naddrs:1 cname:0000000000000000 ttl:8109 2013/01/18 09:32:40 [debug] 12882#0: *1 name was resolved to 46.105.113.99 2013/01/18 09:32:40 [debug] 12882#0: resolve name done: 0 2013/01/18 09:32:40 [debug] 12882#0: event timer del: -1: 1358501590872 2013/01/18 09:32:40 [debug] 12882#0: resolver expire 2013/01/18 09:32:40 [debug] 12882#0: *1 get rr peer, try: 1 2013/01/18 09:32:40 [debug] 12882#0: *1 socket 7 2013/01/18 09:32:40 [debug] 12882#0: *1 epoll add connection: fd:7 ev:80000005 2013/01/18 09:32:40 [debug] 12882#0: *1 connect to 46.105.113.99:80, fd:7 #3 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream connect: -2 2013/01/18 09:32:40 [debug] 12882#0: *1 posix_memalign: 000000000167CCE0:128 @16 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer add: 7: 60000:1358501620885 2013/01/18 09:32:40 [debug] 12882#0: recv: fd:5 -1 of 4096 2013/01/18 09:32:40 [debug] 12882#0: recv() not ready (11: Resource temporarily unavailable) 2013/01/18 09:32:40 [debug] 12882#0: timer delta: 13 2013/01/18 09:32:40 [debug] 12882#0: posted events 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: worker cycle 2013/01/18 09:32:40 [debug] 12882#0: epoll timer: 4987 2013/01/18 09:32:40 [debug] 12882#0: epoll: fd:7 ev:0004 d:00007F37530CC2F0 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream request: "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream send request handler 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream send request 2013/01/18 09:32:40 [debug] 12882#0: *1 chain writer buf fl:1 s:542 2013/01/18 09:32:40 [debug] 12882#0: *1 chain writer in: 0000000001677288 2013/01/18 09:32:40 [debug] 12882#0: *1 writev: 542 2013/01/18 09:32:40 [debug] 12882#0: *1 chain writer out: 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer del: 7: 1358501620885 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer add: 7: 60000:1358501620906 2013/01/18 09:32:40 [debug] 12882#0: timer delta: 21 2013/01/18 09:32:40 [debug] 12882#0: posted events 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: worker cycle 2013/01/18 09:32:40 [debug] 12882#0: epoll timer: 4966 2013/01/18 09:32:40 [debug] 12882#0: epoll: fd:7 ev:0005 d:00007F37530CC2F0 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream request: "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream process header 2013/01/18 09:32:40 [debug] 12882#0: *1 malloc: 00000000016903A0:8192 2013/01/18 09:32:40 [debug] 12882#0: *1 recv: fd:7 785 of 8192 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy status 503 "503 Service Temporarily Unavailable" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Server: nginx/1.1.1" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Date: Fri, 18 Jan 2013 09:32:40 GMT" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Content-Type: text/html" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Content-Length: 614" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header: "Connection: close" 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy header done 2013/01/18 09:32:40 [debug] 12882#0: *1 HTTP/1.1 503 Service Temporarily Unavailable Server: nginx/1.3.11 Date: Fri, 18 Jan 2013 09:32:40 GMT Content-Type: text/html Content-Length: 614 Connection: keep-alive 2013/01/18 09:32:40 [debug] 12882#0: *1 write new buf t:1 f:0 0000000001677540, pos 0000000001677540, size: 177 file: 0, size: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 http write filter: l:0 f:0 s:177 2013/01/18 09:32:40 [debug] 12882#0: *1 http cacheable: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 http proxy filter init s:503 h:0 c:0 l:614 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream process upstream 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe read upstream: 1 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe preread: 614 2013/01/18 09:32:40 [debug] 12882#0: *1 readv: 1:7407 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe recv chain: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe buf free s:0 t:1 f:0 00000000016903A0, pos 000000000169044B, size: 614 file: 0, size: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe length: 614 2013/01/18 09:32:40 [debug] 12882#0: *1 input buf #0 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe write downstream: 1 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe write downstream flush in 2013/01/18 09:32:40 [debug] 12882#0: *1 http output filter "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http copy filter: "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http postpone filter "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 0000000001677770 2013/01/18 09:32:40 [debug] 12882#0: *1 write old buf t:1 f:0 0000000001677540, pos 0000000001677540, size: 177 file: 0, size: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 write new buf t:1 f:0 00000000016903A0, pos 000000000169044B, size: 614 file: 0, size: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 http write filter: l:0 f:0 s:791 2013/01/18 09:32:40 [debug] 12882#0: *1 http copy filter: 0 "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 pipe write downstream done 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer: 7, old: 1358501620906, new: 1358501620928 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream exit: 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: *1 finalize http upstream request: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 finalize http proxy request 2013/01/18 09:32:40 [debug] 12882#0: *1 free rr peer 1 0 2013/01/18 09:32:40 [debug] 12882#0: *1 close http upstream connection: 7 2013/01/18 09:32:40 [debug] 12882#0: *1 free: 000000000167CCE0, unused: 48 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer del: 7: 1358501620906 2013/01/18 09:32:40 [debug] 12882#0: *1 reusable connection: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 http upstream temp fd: -1 2013/01/18 09:32:40 [debug] 12882#0: *1 http output filter "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http copy filter: "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http postpone filter "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 00007FFF81023A40 2013/01/18 09:32:40 [debug] 12882#0: *1 write old buf t:1 f:0 0000000001677540, pos 0000000001677540, size: 177 file: 0, size: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 write old buf t:1 f:0 00000000016903A0, pos 000000000169044B, size: 614 file: 0, size: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 write new buf t:0 f:0 0000000000000000, pos 0000000000000000, size: 0 file: 0, size: 0 2013/01/18 09:32:40 [debug] 12882#0: *1 http write filter: l:1 f:0 s:791 2013/01/18 09:32:40 [debug] 12882#0: *1 http write filter limit 0 2013/01/18 09:32:40 [debug] 12882#0: *1 writev: 791 2013/01/18 09:32:40 [debug] 12882#0: *1 http write filter 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: *1 http copy filter: 0 "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" 2013/01/18 09:32:40 [debug] 12882#0: *1 http finalize request: 0, "/?url=http://ns223506.ovh.net/rozne/835940e0853aa19923cac649ad3e2a0f/wallpaper-192686.jpg" a:1, c:1 2013/01/18 09:32:40 [debug] 12882#0: *1 set http keepalive handler 2013/01/18 09:32:40 [debug] 12882#0: *1 http close request 2013/01/18 09:32:40 [debug] 12882#0: *1 http log handler 2013/01/18 09:32:40 [debug] 12882#0: *1 free: 00000000016903A0 2013/01/18 09:32:40 [debug] 12882#0: *1 free: 0000000001675EA0, unused: 8 2013/01/18 09:32:40 [debug] 12882#0: *1 free: 0000000001676EB0, unused: 1295 2013/01/18 09:32:40 [debug] 12882#0: *1 event timer add: 4: 65000:1358501625928 2013/01/18 09:32:40 [debug] 12882#0: *1 free: 000000000167C6D0 2013/01/18 09:32:40 [debug] 12882#0: *1 free: 0000000001685450 2013/01/18 09:32:40 [debug] 12882#0: *1 hc free: 0000000000000000 0 2013/01/18 09:32:40 [debug] 12882#0: *1 hc busy: 0000000000000000 0 2013/01/18 09:32:40 [debug] 12882#0: *1 tcp_nodelay 2013/01/18 09:32:40 [debug] 12882#0: *1 reusable connection: 1 2013/01/18 09:32:40 [debug] 12882#0: *1 post event 0000000001699240 2013/01/18 09:32:40 [debug] 12882#0: timer delta: 22 2013/01/18 09:32:40 [debug] 12882#0: posted events 0000000001699240 2013/01/18 09:32:40 [debug] 12882#0: posted event 0000000001699240 2013/01/18 09:32:40 [debug] 12882#0: *1 delete posted event 0000000001699240 2013/01/18 09:32:40 [debug] 12882#0: *1 http keepalive handler 2013/01/18 09:32:40 [debug] 12882#0: *1 malloc: 000000000167C6D0:1024 2013/01/18 09:32:40 [debug] 12882#0: *1 recv: fd:4 -1 of 1024 2013/01/18 09:32:40 [debug] 12882#0: *1 recv() not ready (11: Resource temporarily unavailable) 2013/01/18 09:32:40 [debug] 12882#0: *1 free: 000000000167C6D0 2013/01/18 09:32:40 [debug] 12882#0: posted event 0000000000000000 2013/01/18 09:32:40 [debug] 12882#0: worker cycle 2013/01/18 09:32:40 [debug] 12882#0: epoll timer: 4944 2013/01/18 09:32:45 [debug] 12882#0: timer delta: 4950 2013/01/18 09:32:45 [debug] 12882#0: event timer del: -1: 1358501565872 2013/01/18 09:32:45 [debug] 12882#0: resolver resend handler 2013/01/18 09:32:45 [debug] 12882#0: posted events 0000000000000000 2013/01/18 09:32:45 [debug] 12882#0: worker cycle 2013/01/18 09:32:45 [debug] 12882#0: epoll timer: 60050 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235263,235263#msg-235263 From andrey at kopeyko.ru Fri Jan 18 12:02:24 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Fri, 18 Jan 2013 16:02:24 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L7RgtCy0LXRgtC+0LIg0LTQu9GP?= =?UTF-8?B?INC90LUg0LDQstGC0L7RgNC40LfQvtCy0LDQvdC90YvRhSDQv9C+0LvRjNC3?= =?UTF-8?B?0L7QstCw0YLQtdC70LXQuQ==?= In-Reply-To: References: Message-ID: <50F939D0.1010707@kopeyko.ru> 18.01.2013 12:48, Руслан Шарипов пишет: > День добрый. Добрый день, Руслан! ... > все шесть запросов ушли к апачу, хотя я ожидал, что из первых трех уйдет > только первый (чтобы сформировать содержимое кеша), а последующие два к > апачу уходить не будут. > > подскажите пожалуйста, что я делаю не так и как мне решить мою задачу? Добавьте директиву http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock -- Best regards, Andrey Kopeyko From citrin at citrin.ru Fri Jan 18 12:13:59 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Fri, 18 Jan 2013 16:13:59 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: References: Message-ID: <50F93C87.8050308@citrin.ru> On 01/16/13 14:57, Ivan Bondarets wrote: > Пытаюсь разработать парсер для дефолтного error.log (описан в секции main, далее > просто наследуется), но нигде не могу найти описание формата лога. менять его > нельзя, насколько я понял, но хотя бы узнать, в каком формате он пишет можно? > Где-нибудь есть описание? > Без описания формата довольно трудно сделать нормальный парсер. Фиксированы только первые несколько полей, дальше идет произвольный текст ошибки. Что касается первых полей, то там все просто: 2013/01/16 17:00:05 [info] 21386#0: *9 kevent() reported that client 10.11.22.44 closed keepalive connection 2013/01/16 17:00:05 - дата и время. [info] - уровень, может быть debug info notice warn error crit alert emerg 21386 - PID процесса 0 - thread id, поскольку тредов в текущей реализации нет - всегда 0 9 - id запроса - позволяет группировать ошибки которые произошли в одном запросе дальше идет текст ошибки. -- Anton Yuzhaninov From citrin at citrin.ru Fri Jan 18 12:19:04 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Fri, 18 Jan 2013 16:19:04 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: <1037688526.20130118002414@softsearch.ru> References: <1037688526.20130118002414@softsearch.ru> Message-ID: <50F93DB8.4070002@citrin.ru> On 01/18/13 00:24, Михаил Монашёв wrote: > Если в парсере заменять все числа, строки в > кавычках и строки, идущие от двоеточия до запятой и не содержащие > пробелов на ХХХ, то получится свернуть всё разнообразие сообщение в > несколько шаблонных фраз. Ну и ради примера приводить одну несвёрнутую > ошибку ещё можно. Полезная тулза, кстати получится. Для суммарной статистики по числу ошибок разного типа сейчас использую такой скрипт: sed -E 's/.* (.*) [0-9]*#0: /\1 /' < $ERROR_LOG \ | sed 's/ \*[0-9]* / /; s/, client: .*//; s/"[^"]*"/"..."/g;' \ | sort | uniq -c | sort -rn -- Anton Yuzhaninov From bondarets at gmail.com Fri Jan 18 12:41:34 2013 From: bondarets at gmail.com (Ivan Bondarets) Date: Fri, 18 Jan 2013 16:41:34 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: <50F93DB8.4070002@citrin.ru> References: <1037688526.20130118002414@softsearch.ru> <50F93DB8.4070002@citrin.ru> Message-ID: Понятно, спасибо. А вот эти вот "тексты ошибки" никак не формализованы? Хотя бы некоторые типы, например те, которые вылезают на ошибки аутентификации или в ответ на директиву deny? 18 января 2013 г., 16:19 пользователь Anton Yuzhaninov написал: > On 01/18/13 00:24, Михаил Монашёв wrote: > >> Если в парсере заменять все числа, строки в >> кавычках и строки, идущие от двоеточия до запятой и не содержащие >> пробелов на ХХХ, то получится свернуть всё разнообразие сообщение в >> несколько шаблонных фраз. Ну и ради примера приводить одну несвёрнутую >> ошибку ещё можно. Полезная тулза, кстати получится. >> > > Для суммарной статистики по числу ошибок разного типа сейчас использую > такой скрипт: > > sed -E 's/.* (.*) [0-9]*#0: /\1 /' < $ERROR_LOG \ > | sed 's/ \*[0-9]* / /; s/, client: .*//; s/"[^"]*"/"..."/g;' \ > | sort | uniq -c | sort -rn > > -- > Anton Yuzhaninov > > > ______________________________**_________________ > 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 bondarets at gmail.com Fri Jan 18 13:03:23 2013 From: bondarets at gmail.com (Ivan Bondarets) Date: Fri, 18 Jan 2013 17:03:23 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: <50F93DB8.4070002@citrin.ru> References: <1037688526.20130118002414@softsearch.ru> <50F93DB8.4070002@citrin.ru> Message-ID: мне не для суммарной статистики по типу ошибок. Мне надо анализировать логи с точки зрения событий, которые имеют хоть какое-то отношение к информационной безопасности (события передатся в SIEM для дальнейшей корреляции и анализа). Для основного лога я уже написал парсер (используется нестандартный формат лога), а вот для error как-то не выходит, потому что я не могу точно понять, как разделены поля (и разделены ли вообще), фиксировано ли количество полей или нет, что некоторые из них обозначают и т.п. 18 января 2013 г., 16:19 пользователь Anton Yuzhaninov написал: > On 01/18/13 00:24, Михаил Монашёв wrote: > >> Если в парсере заменять все числа, строки в >> кавычках и строки, идущие от двоеточия до запятой и не содержащие >> пробелов на ХХХ, то получится свернуть всё разнообразие сообщение в >> несколько шаблонных фраз. Ну и ради примера приводить одну несвёрнутую >> ошибку ещё можно. Полезная тулза, кстати получится. >> > > Для суммарной статистики по числу ошибок разного типа сейчас использую > такой скрипт: > > sed -E 's/.* (.*) [0-9]*#0: /\1 /' < $ERROR_LOG \ > | sed 's/ \*[0-9]* / /; s/, client: .*//; s/"[^"]*"/"..."/g;' \ > | sort | uniq -c | sort -rn > > -- > Anton Yuzhaninov > > > ______________________________**_________________ > 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 gmm at csdoc.com Fri Jan 18 13:08:31 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 18 Jan 2013 15:08:31 +0200 Subject: =?UTF-8?B?0YPQvNC+0LvRh9Cw0L3QuNC1OiAicHJveHlfY2FjaGVfbG9jayBvZmY7IiDQuCAi?= =?UTF-8?B?cHJveHlfY2FjaGVfdXNlX3N0YWxlIG9mZjsi?= In-Reply-To: <50F939D0.1010707@kopeyko.ru> References: <50F939D0.1010707@kopeyko.ru> Message-ID: <50F9494F.3060701@csdoc.com> On 18.01.2013 14:02, Andrey Kopeyko wrote: >> все шесть запросов ушли к апачу, хотя я ожидал, что из первых трех уйдет >> только первый (чтобы сформировать содержимое кеша), а последующие два к >> апачу уходить не будут. >> >> подскажите пожалуйста, что я делаю не так и как мне решить мою задачу? > > Добавьте директиву > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock кстати, а почему по умолчанию эти две директивы отключены - "proxy_cache_lock off;" и "proxy_cache_use_stale off;" ? разве не было бы более удобным там поставить какие-то разумные умолчания, которые подходят большинству пользователей nginx ? например, proxy_cache_lock по умолчанию включить и proxy_cache_use_stale поставить так, как это обычно рекомендуется сделать в этой рассылке в ответ на вопросы пользователей "а почему оно работает не так как ожидалось?". по крайней мере, не могу придумать ни одного варианта, когда proxy_cache_use_stale on; создаст какие-то проблемы. -- Best regards, Gena From vbart at nginx.com Fri Jan 18 13:30:28 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 18 Jan 2013 17:30:28 +0400 Subject: =?UTF-8?B?UmU6ICDQndC10YIg0L7RgtCy0LXRgtCwINC+0YIg0YHQtdGA0LLQtdGA0LAgYyBu?= =?UTF-8?B?Z2lueCDQvdCwINC90LXQutC+0YLQvtGA0YvQtSBzeW4=?= In-Reply-To: <50F86091.8050402@amhost.net> References: <50F86091.8050402@amhost.net> Message-ID: <201301181730.28560.vbart@nginx.com> On Friday 18 January 2013 00:35:29 Alex Vorona wrote: > 17.01.2013 14:08, Алексей Малов wrote: > [...] > > > Из 1000 попыток открыть сокет около 30-50 отваливаются по таймауту (2 > > секунды), остальные при этом коннектятся практически мгновенно. > > А что делают воркеры nginx? Не с диска отдают случайно данные, блокируясь > при этом? > Одна из частых причина блокировки рабочих процессов - сторонние модули, многие из которых написаны без учета асинхронной природы nginx. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From vbart at nginx.com Fri Jan 18 13:46:16 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 18 Jan 2013 17:46:16 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: <50F93C87.8050308@citrin.ru> References: <50F93C87.8050308@citrin.ru> Message-ID: <201301181746.16365.vbart@nginx.com> On Friday 18 January 2013 16:13:59 Anton Yuzhaninov wrote: > On 01/16/13 14:57, Ivan Bondarets wrote: > > Пытаюсь разработать парсер для дефолтного error.log (описан в секции > > main, далее просто наследуется), но нигде не могу найти описание формата > > лога. менять его нельзя, насколько я понял, но хотя бы узнать, в каком > > формате он пишет можно? Где-нибудь есть описание? > > Без описания формата довольно трудно сделать нормальный парсер. > > Фиксированы только первые несколько полей, дальше идет произвольный текст > ошибки. > > Что касается первых полей, то там все просто: > > 2013/01/16 17:00:05 [info] 21386#0: *9 kevent() reported that client > 10.11.22.44 closed keepalive connection > > 2013/01/16 17:00:05 - дата и время. > > [info] - уровень, может быть debug info notice warn error crit alert emerg > > 21386 - PID процесса > > 0 - thread id, поскольку тредов в текущей реализации нет - всегда 0 > > 9 - id запроса - позволяет группировать ошибки которые произошли в одном > запросе > Нет. Это id соединения. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html > дальше идет текст ошибки. From nginx-forum at nginx.us Fri Jan 18 15:50:40 2013 From: nginx-forum at nginx.us (Serafim) Date: Fri, 18 Jan 2013 10:50:40 -0500 Subject: =?UTF-8?B?0JfQsNC/0YDQvtGB0Ysg0L/RgNC+0YXQvtC00Y/RgiDQvNC40LzQviDQutC10Yg=?= =?UTF-8?B?0LA=?= Message-ID: Добрый день. Задача: отдавать ответ из кеша для всех запросов без определенной куки (sessionid). Используются следующих конфиг: log_format cache "Code: $status Cache key: $cache Cache: $upstream_cache_status Response time: $upstream_response_time Uri: $uri"; proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mainForNonAuth:10m inactive=10m max_size=1000m; map $cookie_sessionid $cache { default "noncache"; "" ""; "-" ""; } server { include includes/listen.conf; server_name domain.ru; client_max_body_size 100m; location / { access_log /var/log/nginx/test.school.lo.ufanet.ru.access.log cache; error_log /var/log/nginx/test.school.lo.ufanet.ru.error.log debug; ### CACHE::begin proxy_cache_bypass $cache; proxy_no_cache $cache; proxy_cache mainForNonAuth; proxy_cache_use_stale updating; proxy_cache_valid 200 10m; proxy_cache_methods GET HEAD; ### CACHE::end proxy_pass http://127.0.0.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; } } Далее выполняем запросы (без куки session), в логах видим следующее: root at test:/etc/nginx/sites-enabled# tail -f /var/log/nginx/test.school.lo.ufanet.ru.access.log Code: 200 Cache key: Cache: MISS Response time: 0.953 Uri: / Code: 200 Cache key: Cache: MISS Response time: 0.009 Uri: / Code: 200 Cache key: Cache: MISS Response time: 0.007 Uri: / Code: 200 Cache key: Cache: MISS Response time: 0.008 Uri: / т.е. как видим в логе значение переменной $cache равно пустой строке, из документации следует, что в данному случае (согласно работе директив proxy_cache_bypass и proxy_no_cache) ответ должен браться из кеша, но тем нее менее запрос уходит на бэк-енд и ответ береться из него. если же отправить запросы содержащие куку sessionid, но в логе видим следующее: Code: 302 Cache key: Cache: - Response time: 1.434 Uri: /journal/try-login Code: 301 Cache key: noncache Cache: BYPASS Response time: 0.003 Uri: / Code: 200 Cache key: noncache Cache: BYPASS Response time: 0.709 Uri: / Code: 200 Cache key: noncache Cache: BYPASS Response time: 0.013 Uri: / 302 редирект как я полагаю по умолчанию не кешируется вообще, поэтому статус кеша равен "-", а вот остальные запросы работают правильно, т.е. срабатывает правило BYPASS. поясню причины использования конструкции map {}, в документации к proxy_cache_bypass и proxy_no_cache сказано, что ответ берется из кеша только в том случае, если переменная указанная в данных директивах равно пустой строке (или нулю), но использовать переменную $cookie_sessionid нелья, т.к. nginx (по непонятным для меня причинам) случае отсутствия куки возвращает не пустую строку, а символ "-". пожалуйста подскажите что я делаю не так, и как можно решить мою задачу. спасибо. p.s. nginx version: nginx/1.2.1 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235256,235256#msg-235256 From postmaster at softsearch.ru Fri Jan 18 15:54:35 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 19:54:35 +0400 Subject: =?UTF-8?B?UmU6INGD0LzQvtC70YfQsNC90LjQtTogInByb3h5X2NhY2hlX2xvY2sgb2ZmOyIg?= =?UTF-8?B?0LggInByb3h5X2NhY2hlX3VzZV9zdGFsZSBvZmY7Ig==?= In-Reply-To: <50F9494F.3060701@csdoc.com> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> Message-ID: <798185497.20130118195435@softsearch.ru> Здравствуйте, Gena. Вы писали 18 января 2013 г., 17:08:31: > On 18.01.2013 14:02, Andrey Kopeyko wrote: >>> все шесть запросов ушли к апачу, хотя я ожидал, что из первых трех уйдет >>> только первый (чтобы сформировать содержимое кеша), а последующие два к >>> апачу уходить не будут. >>> >>> подскажите пожалуйста, что я делаю не так и как мне решить мою задачу? >> >> Добавьте директиву >> >> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock > кстати, а почему по умолчанию эти две директивы отключены > - "proxy_cache_lock off;" и "proxy_cache_use_stale off;" ? > разве не было бы более удобным там поставить какие-то разумные > умолчания, которые подходят большинству пользователей nginx ? > например, proxy_cache_lock по умолчанию включить > и proxy_cache_use_stale поставить так, как это обычно > рекомендуется сделать в этой рассылке в ответ на вопросы > пользователей "а почему оно работает не так как ожидалось?". > по крайней мере, не могу придумать ни одного варианта, > когда proxy_cache_use_stale on; создаст какие-то проблемы. Придумать-то можно. :-) Подозреваю, что основная причина невключения - изменение старого поведения. Сейчас выходит так: поставил nginx, он пашет 2-3 года, потом зашёл на страницу документации, глянул в конфиг и видишь, что куча новых полезных фич не включено и их прописываешь. Осознанно. Но совсем не факт, что все подряд директивы надо включать. Возможно стоит сделать что-то вроде онлайн-сервиса по улучшению конфига: человек закачивает свой конфиг, выбирает свою операционку, параметры железа, настройки ОС и получает в ответ: здесь proxy_cache_lock on; можно прописать и сократить нагрузку на бэкенд, тут if хорошо бы через map переписать, тут backlog можно увеличить, чтобы всплески нагрузки лучше обслуживать и т.д. Такой сервис с одной стороны привлёк бы к nginx.com много вебмастеров, особенно неаглоязычных и нерусскоязычных, т.е. не имеющих сложившихся сообществ, с другой - конвертировал бы их в клиентов . У Петра Зайцева есть похожая тулза по генерации размеров буферов для mysql-я. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Fri Jan 18 16:02:41 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 20:02:41 +0400 Subject: =?UTF-8?B?UmVbMl06INC/0LDRgNGB0LXRgCDQtNC70Y8gZXJyb3IubG9n?= In-Reply-To: <50F93DB8.4070002@citrin.ru> References: <1037688526.20130118002414@softsearch.ru> <50F93DB8.4070002@citrin.ru> Message-ID: <1562199047.20130118200241@softsearch.ru> Здравствуйте, Anton. >> Если в парсере заменять все числа, строки в >> кавычках и строки, идущие от двоеточия до запятой и не содержащие >> пробелов на ХХХ, то получится свернуть всё разнообразие сообщение в >> несколько шаблонных фраз. Ну и ради примера приводить одну несвёрнутую >> ошибку ещё можно. Полезная тулза, кстати получится. > Для суммарной статистики по числу ошибок разного типа сейчас использую такой скрипт: > sed -E 's/.* (.*) [0-9]*#0: /\1 /' < $ERROR_LOG \ > | sed 's/ \*[0-9]* / /; s/, client: .*//; s/"[^"]*"/"..."/g;' \ > | sort | uniq -c | sort -rn 217 [error] kevent() reported about an closed connection (54: Connection reset by peer) while reading response header from upstream 159 [error] b.readmanga.ru could not be resolved (3: Host not found) 125 [error] g.readmanga.ru could not be resolved (3: Host not found) 108 [error] img1.gelz.net could not be resolved (2: Server failure) 76 [error] myphotos.ya1.ru could not be resolved (3: Host not found) 72 [error] upstream prematurely closed connection while reading response header from upstream 72 [error] jarmorka.ru could not be resolved (3: Host not found) ... 2 [error] image filter: too big response: 17993058 while reading response header from upstream 2 [error] image filter: too big response: 15226607 while reading response header from upstream 2 [error] image filter: too big response: 14589082 while reading response header from upstream 2 [error] image filter: too big response: 14204255 while reading response header from upstream 2 [error] image filter: too big response: 14101173 while reading response header from upstream 2 [error] image filter: too big response: 12871436 while reading response header from upstream 2 [error] image filter: too big response: 12702013 while reading response header from upstream 2 [error] image filter: too big response: 12650307 while reading response header from upstream 2 [error] image filter: too big response: 12415575 while reading response header from upstream Хосты без кавычек и цифры не сворачиваются :-( Цифры ещё можно победить, а вот для "... could not be resolved" нужно писать отдельное условие. -- С уважением, Михаил mailto:postmaster at softsearch.ru From danila at shtan.ru Fri Jan 18 16:17:02 2013 From: danila at shtan.ru (Danila Shtan) Date: Fri, 18 Jan 2013 22:17:02 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0L7RgdGLINC/0YDQvtGF0L7QtNGP0YIg0LzQuNC80L4g0Lo=?= =?UTF-8?B?0LXRiNCw?= In-Reply-To: References: Message-ID: У нас подобная схема реализованна именно через proxy_cache_bypass $cookie_session; proxy_no_cache $cookie_session; Я, правда, в содержимое переменной не заглядывал ? не уверен, что именно там должно быть. Работает как планировалось ? при наличии куки не кэширует, при отсутствии (анонимные пользователи) ? кэширует. Д. 2013/1/18 Serafim > Добрый день. > > Задача: отдавать ответ из кеша для всех запросов без определенной куки > (sessionid). > > Используются следующих конфиг: > > log_format cache "Code: $status Cache key: $cache Cache: > $upstream_cache_status Response time: $upstream_response_time Uri: $uri"; > proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mainForNonAuth:10m > inactive=10m max_size=1000m; > > map $cookie_sessionid $cache { > default "noncache"; > "" ""; > "-" ""; > } > > server { > include includes/listen.conf; > server_name domain.ru; > client_max_body_size 100m; > location / { > access_log /var/log/nginx/test.school.lo.ufanet.ru.access.log cache; > error_log /var/log/nginx/test.school.lo.ufanet.ru.error.log debug; > ### CACHE::begin > proxy_cache_bypass $cache; > proxy_no_cache $cache; > proxy_cache mainForNonAuth; > proxy_cache_use_stale updating; > proxy_cache_valid 200 10m; > proxy_cache_methods GET HEAD; > ### CACHE::end > proxy_pass http://127.0.0.1; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $remote_addr; > } > } > > Далее выполняем запросы (без куки session), в логах видим следующее: > > root at test:/etc/nginx/sites-enabled# tail -f > /var/log/nginx/test.school.lo.ufanet.ru.access.log > Code: 200 Cache key: Cache: MISS Response time: 0.953 Uri: / > Code: 200 Cache key: Cache: MISS Response time: 0.009 Uri: / > Code: 200 Cache key: Cache: MISS Response time: 0.007 Uri: / > Code: 200 Cache key: Cache: MISS Response time: 0.008 Uri: / > > т.е. как видим в логе значение переменной $cache равно пустой строке, из > документации следует, что в данному случае (согласно работе директив > proxy_cache_bypass и proxy_no_cache) ответ должен браться из кеша, но тем > нее менее запрос уходит на бэк-енд и ответ береться из него. > > если же отправить запросы содержащие куку sessionid, но в логе видим > следующее: > > Code: 302 Cache key: Cache: - Response time: 1.434 Uri: /journal/try-login > Code: 301 Cache key: noncache Cache: BYPASS Response time: 0.003 Uri: / > Code: 200 Cache key: noncache Cache: BYPASS Response time: 0.709 Uri: / > Code: 200 Cache key: noncache Cache: BYPASS Response time: 0.013 Uri: / > > 302 редирект как я полагаю по умолчанию не кешируется вообще, поэтому > статус > кеша равен "-", а вот остальные запросы работают правильно, т.е. > срабатывает > правило BYPASS. > > поясню причины использования конструкции map {}, в документации к > proxy_cache_bypass и proxy_no_cache сказано, что ответ берется из кеша > только в том случае, если переменная указанная в данных директивах равно > пустой строке (или нулю), но использовать переменную $cookie_sessionid > нелья, т.к. nginx (по непонятным для меня причинам) случае отсутствия куки > возвращает не пустую строку, а символ "-". > > пожалуйста подскажите что я делаю не так, и как можно решить мою задачу. > > спасибо. > > p.s. > > nginx version: nginx/1.2.1 > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-client-body-temp-path=/var/lib/nginx/body > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > --http-log-path=/var/log/nginx/access.log > --http-proxy-temp-path=/var/lib/nginx/proxy > --http-scgi-temp-path=/var/lib/nginx/scgi > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi > --lock-path=/var/lock/nginx.lock > --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug > --with-http_addition_module --with-http_dav_module --with-http_geoip_module > --with-http_gzip_static_module --with-http_image_filter_module > --with-http_realip_module --with-http_stub_status_module > --with-http_ssl_module --with-http_sub_module --with-http_xslt_module > --with-ipv6 --with-sha1=/usr/include/openssl > --with-md5=/usr/include/openssl > --with-mail --with-mail_ssl_module > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235256,235256#msg-235256 > > _______________________________________________ > 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 gmm at csdoc.com Fri Jan 18 18:07:21 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 18 Jan 2013 20:07:21 +0200 Subject: =?UTF-8?B?UmU6INGD0LzQvtC70YfQsNC90LjQtTogInByb3h5X2NhY2hlX2xvY2sgb2ZmOyIg?= =?UTF-8?B?0LggInByb3h5X2NhY2hlX3VzZV9zdGFsZSBvZmY7Ig==?= In-Reply-To: <798185497.20130118195435@softsearch.ru> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> <798185497.20130118195435@softsearch.ru> Message-ID: <50F98F59.9020003@csdoc.com> On 18.01.2013 17:54, Михаил Монашёв wrote: >>>> все шесть запросов ушли к апачу, хотя я ожидал, что из первых трех уйдет >>>> только первый (чтобы сформировать содержимое кеша), а последующие два к >>>> апачу уходить не будут. >>>> >>>> подскажите пожалуйста, что я делаю не так и как мне решить мою задачу? >>> >>> Добавьте директиву >>> >>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock > >> кстати, а почему по умолчанию эти две директивы отключены >> - "proxy_cache_lock off;" и "proxy_cache_use_stale off;" ? > >> разве не было бы более удобным там поставить какие-то разумные >> умолчания, которые подходят большинству пользователей nginx ? > >> например, proxy_cache_lock по умолчанию включить >> и proxy_cache_use_stale поставить так, как это обычно >> рекомендуется сделать в этой рассылке в ответ на вопросы >> пользователей "а почему оно работает не так как ожидалось?". > >> по крайней мере, не могу придумать ни одного варианта, >> когда proxy_cache_use_stale on; создаст какие-то проблемы. опечатка, подразумевалось "proxy_cache_lock on;" > Придумать-то можно. :-) например? у меня не получилось. это же "killer feature" и она выключена. > Подозреваю, что основная причина невключения - изменение старого поведения. даже если когда оно изменится в лучшую сторону во всех 100% случаев? > Сейчас выходит так: поставил nginx, он пашет 2-3 года, потом зашёл на > страницу документации, глянул в конфиг и видишь, что куча новых > полезных фич не включено и их прописываешь. Осознанно. Но совсем не > факт, что все подряд директивы надо включать. а в каких случаях не надо включать "proxy_cache_lock on;" ? > Возможно стоит сделать что-то вроде онлайн-сервиса по улучшению > конфига: человек закачивает свой конфиг, выбирает свою операционку, > параметры железа, настройки ОС и получает в ответ: здесь > proxy_cache_lock on; можно прописать и сократить нагрузку на бэкенд, > тут if хорошо бы через map переписать, тут backlog можно увеличить, > чтобы всплески нагрузки лучше обслуживать и т.д. закачивать конфиги на какой-то левый сайт вряд ли кто-то станет... > Такой сервис с одной стороны привлёк бы к nginx.com много вебмастеров, > особенно неаглоязычных и нерусскоязычных, т.е. не имеющих сложившихся > сообществ, с другой - конвертировал бы их в клиентов . вообще-то, такой веб-сервис уже есть, http://forum.nginx.org/ > У Петра Зайцева есть похожая тулза по генерации размеров буферов для > mysql-я. это не на сайте, это отдельные скрипты: http://mysqltuner.com/ https://launchpad.net/mysql-tuning-primer плюс похожая функциональность встроена в http://www.phpmyadmin.net/ -- Best regards, Gena From postmaster at softsearch.ru Fri Jan 18 18:33:09 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 22:33:09 +0400 Subject: =?UTF-8?B?UmVbMl06INGD0LzQvtC70YfQsNC90LjQtTogInByb3h5X2NhY2hlX2xvY2sgb2Zm?= =?UTF-8?B?OyIg0LggInByb3h5X2NhY2hlX3VzZV9zdGFsZSBvZmY7Ig==?= In-Reply-To: <50F98F59.9020003@csdoc.com> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> <798185497.20130118195435@softsearch.ru> <50F98F59.9020003@csdoc.com> Message-ID: <1996943759.20130118223309@softsearch.ru> Здравствуйте, Gena. >>> по крайней мере, не могу придумать ни одного варианта, >>> когда proxy_cache_use_stale on; создаст какие-то проблемы. > опечатка, подразумевалось "proxy_cache_lock on;" >> Придумать-то можно. :-) > например? у меня не получилось. это же "killer feature" и она выключена. Я "например" писал не зная, что Вы опечатались. :-) Про proxy_cache_lock on пример следующий: много зазеркаленных бэкендов с одинаковым контентом и поэтому нет смысла ждать ответа от одного перегруженного бэкенда, когда можно получить ответ быстрее с недогруженного. Конечно пример натянутый и описанная задача решается иначе, но мы ведь знаем по этому листу, как высок бывает полёт фантазии человеческой. :-) Я на самом деле с Вами в чём-то солидарен. Но есть и другая сторона. Мне меньше всего хочется после каждого обновления nginx-а лазить в логи или тестировать на несломанность все реализованные ранее через него возможности сайта. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Fri Jan 18 18:43:33 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 18 Jan 2013 22:43:33 +0400 Subject: =?UTF-8?B?UmU6INGD0LzQvtC70YfQsNC90LjQtTogInByb3h5X2NhY2hlX2xvY2sgb2ZmOyIg?= =?UTF-8?B?INC4ICJwcm94eV9jYWNoZV91c2Vfc3RhbGUgb2ZmOyI=?= In-Reply-To: <50F9494F.3060701@csdoc.com> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> Message-ID: <201301182243.33503.vbart@nginx.com> On Friday 18 January 2013 17:08:31 Gena Makhomed wrote: > On 18.01.2013 14:02, Andrey Kopeyko wrote: > >> все шесть запросов ушли к апачу, хотя я ожидал, что из первых трех уйдет > >> только первый (чтобы сформировать содержимое кеша), а последующие два к > >> апачу уходить не будут. > >> > >> подскажите пожалуйста, что я делаю не так и как мне решить мою задачу? > > > > Добавьте директиву > > > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock > > кстати, а почему по умолчанию эти две директивы отключены > - "proxy_cache_lock off;" и "proxy_cache_use_stale off;" ? > > разве не было бы более удобным там поставить какие-то разумные > умолчания, которые подходят большинству пользователей nginx ? > Они и стоят: off и off. > например, proxy_cache_lock по умолчанию включить А потом поставит кто-нибудь новую версию, и обратит внимание, что появились какие-то странные задержки вплоть до 500мс, а в иных случаях и 5 секунд, и начнут спрашивать, почему такие нехорошие разработчики им всё сломали. > и proxy_cache_use_stale поставить так, как это обычно > рекомендуется сделать в этой рассылке в ответ на вопросы Как рекомендуют? > пользователей "а почему оно работает не так как ожидалось?". > > по крайней мере, не могу придумать ни одного варианта, > когда proxy_cache_use_stale on; создаст какие-то проблемы. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From gmm at csdoc.com Fri Jan 18 19:11:13 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 18 Jan 2013 21:11:13 +0200 Subject: =?UTF-8?B?UmU6INGD0LzQvtC70YfQsNC90LjQtTogInByb3h5X2NhY2hlX2xvY2sgb2ZmOyIg?= =?UTF-8?B?INC4ICJwcm94eV9jYWNoZV91c2Vfc3RhbGUgb2ZmOyI=?= In-Reply-To: <201301182243.33503.vbart@nginx.com> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> <201301182243.33503.vbart@nginx.com> Message-ID: <50F99E51.30502@csdoc.com> On 18.01.2013 20:43, Валентин Бартенев wrote: >> например, proxy_cache_lock по умолчанию включить > > А потом поставит кто-нибудь новую версию, и обратит внимание, что появились > какие-то странные задержки вплоть до 500мс, а в иных случаях и 5 секунд, и > начнут спрашивать, почему такие нехорошие разработчики им всё сломали. даже если в CHANGELOG`е об этом будет написано? и изменение произойдет при переходе от 1.2 к 1.4? >> и proxy_cache_use_stale поставить так, как это обычно >> рекомендуется сделать в этой рассылке в ответ на вопросы > > Как рекомендуют? примерно так: http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049353.html P.S. я не настаиваю, нет - так нет. -- Best regards, Gena From postmaster at softsearch.ru Fri Jan 18 19:12:18 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 23:12:18 +0400 Subject: =?UTF-8?B?UmVbMl06INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <20130114124616.GS25043@mdounin.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> Message-ID: <8010040080.20130118231218@softsearch.ru> Здравствуйте, Maxim. >> > А, нет, вру, должно быть всё нормально и без пробела, это >> > действительно бага. >> >> > У тебя proxy_method задан на уровне http{}, да? >> >> Да, на уровне http{}. > Патч. > # HG changeset patch > # User Maxim Dounin > # Date 1358167486 -14400 > # Node ID d94906442d522529b6daf9c955cdb9a264755979 > # Parent 13c4c155f26f772b0bc1074a05298088d6499218 > Proxy: fixed proxy_method to always add space. > Before the patch if proxy_method was specified at http{} level the code > to add trailing space wasn't executed, resulting in incorrect requests > to upstream. > diff --git a/src/http/modules/ngx_http_proxy_module.c > b/src/http/modules/ngx_http_proxy_module.c > --- a/src/http/modules/ngx_http_proxy_module.c > +++ b/src/http/modules/ngx_http_proxy_module.c > @@ -2353,7 +2353,7 @@ ngx_http_proxy_create_loc_conf(ngx_conf_ > * conf->upstream.store_lengths = NULL; > * conf->upstream.store_values = NULL; > * - * conf->>method = NULL; + * conf->>method = { 0, NULL }; > * conf->headers_source = NULL; > * conf->headers_set_len = NULL; > * conf->headers_set = NULL; > @@ -2652,10 +2652,11 @@ ngx_http_proxy_merge_loc_conf(ngx_conf_t > #endif - if (conf->>method.len == 0) { - conf->>method = prev->method; > - > - } else { > + ngx_conf_merge_str_value(conf->method, prev->method, ""); > + + if (conf->>method.len + && conf->>method.data[conf->method.len - 1] != ' ') > + { > conf->method.data[conf->method.len] = ' '; > conf->method.len++; > } Патч наложил. Написал в конфиге: proxy_method GET; На бэкенд шлёт нормальные запросы. А как правильно писать: proxy_method GET; или proxy_method "GET "; ? Т.е. пробел после названия метода обязателен или нет? -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Fri Jan 18 19:12:49 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 18 Jan 2013 23:12:49 +0400 Subject: =?UTF-8?B?UmU6ICDQn9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtSDQuNC30L7QsdGA0LDQttC1?= =?UTF-8?B?0L3QuNC5INGH0LXRgNC10LcgTmdpbngg0LIgRmxhc2gu?= In-Reply-To: <36e27d319b7b63a9735b78180200ec63.NginxMailingListRussian@forum.nginx.org> References: <36e27d319b7b63a9735b78180200ec63.NginxMailingListRussian@forum.nginx.org> Message-ID: <201301182312.50018.vbart@nginx.com> On Friday 18 January 2013 13:36:16 somebi wrote: > Все работает, когда я пытаюсь открыть картинку напрямую в браузере. > > Оно так же работает в флеше, но только на маленьких картинках, типа этой: > > /?url=http://thumbs.wallbase.cc/rozne/thumb-415891.jpg > > И не работает, когда я пытаюсь загрузить картинку побольше, возвращая > стандартную страницу для 503 заголовока ответа: [...] > > Я пересобрал nginx с --with-debug и вот лог: [...] Из лога видно, что 503 приходит от бэкенда. Сам nginx 503 может вернуть только в случае срабатывания limit_req или limit_conn. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From vbart at nginx.com Fri Jan 18 19:36:54 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 18 Jan 2013 23:36:54 +0400 Subject: =?UTF-8?B?UmU6INGD0LzQvtC70YfQsNC90LjQtTogInByb3h5X2NhY2hlX2xvY2sgb2ZmOyIg?= =?UTF-8?B?INC4ICJwcm94eV9jYWNoZV91c2Vfc3RhbGUgb2ZmOyI=?= In-Reply-To: <50F99E51.30502@csdoc.com> References: <201301182243.33503.vbart@nginx.com> <50F99E51.30502@csdoc.com> Message-ID: <201301182336.54979.vbart@nginx.com> On Friday 18 January 2013 23:11:13 Gena Makhomed wrote: > On 18.01.2013 20:43, Валентин Бартенев wrote: > >> например, proxy_cache_lock по умолчанию включить > > > > А потом поставит кто-нибудь новую версию, и обратит внимание, что > > появились какие-то странные задержки вплоть до 500мс, а в иных случаях и > > 5 секунд, и начнут спрашивать, почему такие нехорошие разработчики им > > всё сломали. > > даже если в CHANGELOG`е об этом будет написано? Много людей их читает? А главное всегда понимает, что там написано, и какие эффекты может дать то или иное изменение? > и изменение произойдет при переходе от 1.2 к 1.4? > Речь идет о том, что proxy_cache_lock - это не обязательно благо. Кому-то включение противопоказано. И предлагается "нанести" добро некоторому количеству неосведомленных пользователей, которые об этом не просили, при этом нанеся вред кому-то, кто уж точно об этом не просил. > >> и proxy_cache_use_stale поставить так, как это обычно > >> рекомендуется сделать в этой рассылке в ответ на вопросы > > > > Как рекомендуют? > > примерно так: > > http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049353.html > Зависит от задачи. > P.S. я не настаиваю, нет - так нет. По-умолчанию nginx старается работать самым простым образом и с наименьшим количеством сайд-эффектов. Принцип - не навреди. Включить дополнительную плюшку всегда можно, если хочется, и это будет явно, осознанно. Разбираться же, что произошло постфактум, что вызвало странные глюки, можно долго, причем не всегда даже будет понятно кто виноват, и что вот такая запись в CHANGELOG`е nginx-а и есть причина наблюдаемого, особенно когда человек просто обновил свою любимую убунту до следующей LTS версии. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Fri Jan 18 19:51:40 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 18 Jan 2013 23:51:40 +0400 Subject: =?UTF-8?B?0JHQvtC70YzRiNC+0LUg0LLRgNC10LzRjyDQsiAkcmVxdWVzdF90aW1l?= Message-ID: <1246062472.20130118235140@softsearch.ru> Здравствуйте. Лог имеет вот такой формат: log_format main '$time_local $status "$upstream_status" $request_time "$upstream_response_time" "$upstream_addr" $remote_addr $bytes_sent $upstream_cache_status $host "$request" "$http_referer" "$http_user_agent" "$http_cookie" "$http_accept" "$http_accept_language" "$http_accept_encoding" "$http_connection"'; Часто вижу огромное время в $request_time , хотя отдаётся с ненагруженного локального SSD диска, проца достаточно, сети тоже: 18/Jan/2013:23:27:40 +0400 200 "-" 29.096 "-" "-" 178.216.123.62 752929 HIT i88.beon.ru "GET /77/21/892177/1407/avatars/31.gif HTTP/1.1" "http://lenka597032.beon.ru/35121-823-stolik-zakazov.zhtml" "Opera/9.80 (Windows NT 5.1; MRA 5.7 (build 03780)) Presto/2.12.388 Version/12.11" "utmcct=/0-1-privet-ja-noven-kaja-u-menja-est.zhtml" "text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1" "ru-RU,ru;q=0.9,en;q=0.8" "gzip, deflate" "Keep-Alive" timer_resolution выключен. limit_req тоже выключил. В доке написано: $request_time время обработки запроса в секундах с точностью до миллисекунд (1.3.9, 1.2.6); время, прошедшее с момента чтения первых байт от клиента. Что значит "от клиента"? Может "клиентом"? Тогда это объясняет большое время. Или "от клиента" относится к слову "запрос"? Какая-то многозначная и не очень понятная фраза получается. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Fri Jan 18 20:09:28 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 19 Jan 2013 00:09:28 +0400 Subject: =?UTF-8?B?UmVbMl06INGD0LzQvtC70YfQsNC90LjQtTogInByb3h5X2NhY2hlX2xvY2sgb2Zm?= =?UTF-8?B?OyIg0LggInByb3h5X2NhY2hlX3VzZV9zdGFsZSBvZmY7Ig==?= In-Reply-To: <50F98F59.9020003@csdoc.com> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> <798185497.20130118195435@softsearch.ru> <50F98F59.9020003@csdoc.com> Message-ID: <137844373.20130119000928@softsearch.ru> Здравствуйте, Gena. >> Возможно стоит сделать что-то вроде онлайн-сервиса по улучшению >> конфига: человек закачивает свой конфиг, выбирает свою операционку, >> параметры железа, настройки ОС и получает в ответ: здесь >> proxy_cache_lock on; можно прописать и сократить нагрузку на >> бэкенд, тут if хорошо бы через map переписать, тут backlog можно >> увеличить, чтобы всплески нагрузки лучше обслуживать и т.д. > закачивать конфиги на какой-то левый сайт вряд ли кто-то станет... Так я и предлагаю сие на nginx.com сделать, как альтернативу твоим вполне обоснованным предложениям. Тем более, если сам вебсервер не посчитали левым, то и его сайт тоже таким не посчитают. Т.е. юзер закачивает конфиг, отвечает на разные вопросы, потом ему предлагают где чего и зачем можно в конфиге добавить/изменить, он осознанно добавляет/изменяет и получает новый конфиг, который обязуется сохранить старый конфиг на всякий случай и хорошенько протестировать новый перед работой. >> Такой сервис с одной стороны привлёк бы к nginx.com много >> вебмастеров, особенно неаглоязычных и нерусскоязычных, т.е. не >> имеющих сложившихся сообществ, с другой - конвертировал бы их в >> клиентов . > вообще-то, такой веб-сервис уже есть, http://forum.nginx.org/ Вы предлагаете всё перечитывать или постить публично свой конфиг с вопросом: "Что тут можно улучшить?" >> У Петра Зайцева есть похожая тулза по генерации размеров буферов для >> mysql-я. > это не на сайте, это отдельные скрипты: > http://mysqltuner.com/ > https://launchpad.net/mysql-tuning-primer > плюс похожая функциональность встроена в http://www.phpmyadmin.net/ Разнообразие предлагаемого сервиса косвенно говорит о востребованности такого оптимизатора конфига и для nginx-а. Тем более в мускуле шибко не натюнишь, там параметров десятка два всего в самом сложном случае. А в nginx-е есть огромное непаханное поле. P.S. Заметил, что проверялка конфига не выводит варнинг, если описана какая-то переменная, но она нигде не используется. Такая проверка немного спасала бы от опечаток и ошибок, вызванных копипастой. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Fri Jan 18 20:30:36 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 19 Jan 2013 00:30:36 +0400 Subject: =?UTF-8?B?0J7Qs9GA0LDQvdC40YfQtdC90LjQtSDQvdCwINGA0LDQt9C80LXRgCDQv9GA0L4=?= =?UTF-8?B?0LrRgdC40YDRg9C10LzQvtCz0L4g0YTQsNC50LvQsA==?= Message-ID: <514260059.20130119003036@softsearch.ru> Здравствуйте. Есть ли возможность сбрасывать соединение с бэкендом, если тот отдаёт ответ больше максимально допустимого? Если в ответе бэкенда указан Content-length и он превышает лимит, то обрывать соединение с бэкендом сразу, генеря соответствующую ошибку, на которую можно было бы повесить, например return 204; Иначе скачивать ответ, пока он не превысит лимит, и тогда сбрасывать соединение и с бэкендом и с браузером, если последнему уже отдался заголовок или часть тела ответа. В доках нашёл про http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size Но это вроде про другое... -- С уважением, Михаил mailto:postmaster at softsearch.ru From ru at nginx.com Fri Jan 18 20:31:15 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Sat, 19 Jan 2013 00:31:15 +0400 Subject: =?UTF-8?B?UmU6INCR0L7Qu9GM0YjQvtC1INCy0YDQtdC80Y8g0LIgJHJlcXVlc3RfdGltZQ==?= In-Reply-To: <1246062472.20130118235140@softsearch.ru> References: <1246062472.20130118235140@softsearch.ru> Message-ID: <20130118203115.GA45325@lo0.su> On Fri, Jan 18, 2013 at 11:51:40PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Лог имеет вот такой формат: > log_format main '$time_local $status "$upstream_status" $request_time "$upstream_response_time" "$upstream_addr" $remote_addr $bytes_sent $upstream_cache_status $host "$request" "$http_referer" "$http_user_agent" "$http_cookie" "$http_accept" "$http_accept_language" "$http_accept_encoding" "$http_connection"'; > > Часто вижу огромное время в $request_time , хотя отдаётся с > ненагруженного локального SSD диска, проца достаточно, сети тоже: > 18/Jan/2013:23:27:40 +0400 200 "-" 29.096 "-" "-" 178.216.123.62 752929 HIT i88.beon.ru "GET /77/21/892177/1407/avatars/31.gif HTTP/1.1" "http://lenka597032.beon.ru/35121-823-stolik-zakazov.zhtml" "Opera/9.80 (Windows NT 5.1; MRA 5.7 (build 03780)) Presto/2.12.388 Version/12.11" "utmcct=/0-1-privet-ja-noven-kaja-u-menja-est.zhtml" "text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1" "ru-RU,ru;q=0.9,en;q=0.8" "gzip, deflate" "Keep-Alive" > > timer_resolution выключен. limit_req тоже выключил. > > В доке написано: > $request_time > время обработки запроса в секундах с точностью до миллисекунд > (1.3.9, 1.2.6); время, прошедшее с момента чтения первых байт от > клиента. > > Что значит "от клиента"? Может "клиентом"? Тогда это объясняет большое > время. Или "от клиента" относится к слову "запрос"? Какая-то > многозначная и не очень понятная фраза получается. "От клиента" значит "от клиента", т.е. с момента, когда первые байты данных от клиента дошли до nginx. Другими словами, http { server { location / { return 200 "$request_time\n"; } } } : $ ( echo 'GET / HTTP/1.1' ; echo 'Host: example.com' ; sleep 13; echo ) | nc localhost 8000 : HTTP/1.1 200 OK : Server: nginx/1.3.12 : Date: Fri, 18 Jan 2013 20:30:39 GMT : Content-Type: text/plain : Content-Length: 7 : Connection: keep-alive : : 13.000 From gmm at csdoc.com Fri Jan 18 21:24:37 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 18 Jan 2013 23:24:37 +0200 Subject: =?UTF-8?B?0L7Qv9GC0LjQvNC40LfQsNGC0L7RgCDQutC+0L3RhNC40LPQsCDQtNC70Y8gbmdp?= =?UTF-8?B?bng=?= In-Reply-To: <137844373.20130119000928@softsearch.ru> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> <798185497.20130118195435@softsearch.ru> <50F98F59.9020003@csdoc.com> <137844373.20130119000928@softsearch.ru> Message-ID: <50F9BD95.1050205@csdoc.com> On 18.01.2013 22:09, Михаил Монашёв wrote: >>> Возможно стоит сделать что-то вроде онлайн-сервиса по улучшению >>> конфига: человек закачивает свой конфиг, выбирает свою операционку, >>> параметры железа, настройки ОС и получает в ответ: здесь >>> proxy_cache_lock on; можно прописать и сократить нагрузку на >>> бэкенд, тут if хорошо бы через map переписать, тут backlog можно >>> увеличить, чтобы всплески нагрузки лучше обслуживать и т.д. >> закачивать конфиги на какой-то левый сайт вряд ли кто-то станет... > Так я и предлагаю сие на nginx.com сделать, как альтернативу твоим > вполне обоснованным предложениям. Тем более, если сам вебсервер не > посчитали левым, то и его сайт тоже таким не посчитают. Т.е. юзер > закачивает конфиг, отвечает на разные вопросы, потом ему предлагают > где чего и зачем можно в конфиге добавить/изменить, он осознанно > добавляет/изменяет и получает новый конфиг, который обязуется > сохранить старый конфиг на всякий случай и хорошенько протестировать > новый перед работой. обычно у пользователей на машинах "конфиг nginx" - это понятие растяжимое на десятки и сотни файлов. основной конфиг - nginx.conf в который потом включаются файлы с фрагментами для отдельных сайтов закачивать это вручную через формы на сайт - занятие утомительное, даже если перед тем вручную сделать архив каталога со всеми конфигами. обычно скрипты запускаемые на локальной машине удобнее. хотя бы потому что им не надо будет вручную рассказывать какая конфигурация машины и какой тип нагрузки (это можно взять из логов) и как потом монетизировать этот сервис - обвешать его баннерами? >>> Такой сервис с одной стороны привлёк бы к nginx.com много >>> вебмастеров, особенно неаглоязычных и нерусскоязычных, т.е. не >>> имеющих сложившихся сообществ, с другой - конвертировал бы их в >>> клиентов . >> вообще-то, такой веб-сервис уже есть, http://forum.nginx.org/ > Вы предлагаете всё перечитывать или постить публично свой конфиг с > вопросом: "Что тут можно улучшить?" я не предлагаю, но видел такое неоднократно. возможно причина этого в не совсем понятной и неидеальной документации. >>> У Петра Зайцева есть похожая тулза по генерации размеров буферов для >>> mysql-я. >> это не на сайте, это отдельные скрипты: >> http://mysqltuner.com/ >> https://launchpad.net/mysql-tuning-primer >> плюс похожая функциональность встроена в http://www.phpmyadmin.net/ > Разнообразие предлагаемого сервиса косвенно говорит о востребованности > такого оптимизатора конфига и для nginx-а. Тем более в мускуле шибко > не натюнишь, там параметров десятка два всего в самом сложном случае. временами они влияют один на другой очень нетривиальным способом. тем более, что часто надо тюнить не сервер, а клиентские приложения. > А в nginx-е есть огромное непаханное поле. параметров больше, но они разнесени по модулям и почти ортогональны. основные проблемы с IfIsEvil и нигде не документированным порядком отработки модулей - какой на какой фазе, и какой раньше другого - это все определяется часто экспериментально или вопросами в рассылке. хотя, для наиболее часто используемых вариантов - могут быть просто примеры документации, которые можно использовать как best practices. пока что единственное исключение из этого правила - это описание директивы try_files: location / { try_files /system/maintenance.html $uri $uri/index.html $uri.html @mongrel; } - на самом деле, это пример, как делать ни в коем случае нельзя. потому что при наличии файла /system/maintenance.html он будет отдаваться клиентам и поисковым машинам с кодом 200, чем будут введены в заблуждение все поисковые машины - они это проиндексируют вместо содержимого сайта и сайт фактически пропадет из поисковиков. -- Best regards, Gena From postmaster at softsearch.ru Fri Jan 18 21:59:53 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 19 Jan 2013 01:59:53 +0400 Subject: =?UTF-8?B?UmVbMl06INCR0L7Qu9GM0YjQvtC1INCy0YDQtdC80Y8g0LIgJHJlcXVlc3RfdGlt?= =?UTF-8?B?ZQ==?= In-Reply-To: <20130118203115.GA45325@lo0.su> References: <1246062472.20130118235140@softsearch.ru> <20130118203115.GA45325@lo0.su> Message-ID: <71301219.20130119015953@softsearch.ru> Здравствуйте, Ruslan. >> В доке написано: >> $request_time >> время обработки запроса в секундах с точностью до миллисекунд >> (1.3.9, 1.2.6); время, прошедшее с момента чтения первых байт от >> клиента. >> >> Что значит "от клиента"? Может "клиентом"? Тогда это объясняет большое >> время. Или "от клиента" относится к слову "запрос"? Какая-то >> многозначная и не очень понятная фраза получается. > "От клиента" значит "от клиента", т.е. с момента, когда первые > байты данных от клиента дошли до nginx. > Другими словами, > http { > server { > location / { > return 200 "$request_time\n"; > } > } > } > : $ ( echo 'GET / HTTP/1.1' ; echo 'Host: example.com' ; sleep 13; echo ) | nc localhost 8000 > : HTTP/1.1 200 OK > : Server: nginx/1.3.12 > : Date: Fri, 18 Jan 2013 20:30:39 GMT > : Content-Type: text/plain > : Content-Length: 7 > : Connection: keep-alive > : > : 13.000 Ага, теперь понятно. Перед "от клиента" можно вставить "полученных" для ясности ИМХО. И понятно от какого момента ведётся отсчёт, но не сказано, до какого момента. Например, до записи последнего байта отправленного клиенту (или до чего там на самом деле оно измеряется). Т.е. чтение и запись - это сугубо программистские термины, выросшие из имён функций read() и write(). ИМХО, понятнее получать и отправлять данные. Хотя наверное сам вечером торможу и к чужим словам начинаю придираться :-) -- С уважением, Михаил mailto:postmaster at softsearch.ru From ru at nginx.com Sat Jan 19 06:52:19 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Sat, 19 Jan 2013 10:52:19 +0400 Subject: =?UTF-8?B?UmU6INCR0L7Qu9GM0YjQvtC1INCy0YDQtdC80Y8g0LIgJHJlcXVlc3RfdGltZQ==?= In-Reply-To: <71301219.20130119015953@softsearch.ru> References: <1246062472.20130118235140@softsearch.ru> <20130118203115.GA45325@lo0.su> <71301219.20130119015953@softsearch.ru> Message-ID: <20130119065219.GA44210@lo0.su> On Sat, Jan 19, 2013 at 01:59:53AM +0400, Михаил Монашёв wrote: > Здравствуйте, Ruslan. > > >> В доке написано: > >> $request_time > >> время обработки запроса в секундах с точностью до миллисекунд > >> (1.3.9, 1.2.6); время, прошедшее с момента чтения первых байт от > >> клиента. > >> > >> Что значит "от клиента"? Может "клиентом"? Тогда это объясняет большое > >> время. Или "от клиента" относится к слову "запрос"? Какая-то > >> многозначная и не очень понятная фраза получается. > > > "От клиента" значит "от клиента", т.е. с момента, когда первые > > байты данных от клиента дошли до nginx. > > > Другими словами, > > > http { > > server { > > location / { > > return 200 "$request_time\n"; > > } > > } > > } > > > : $ ( echo 'GET / HTTP/1.1' ; echo 'Host: example.com' ; sleep 13; echo ) | nc localhost 8000 > > : HTTP/1.1 200 OK > > : Server: nginx/1.3.12 > > : Date: Fri, 18 Jan 2013 20:30:39 GMT > > : Content-Type: text/plain > > : Content-Length: 7 > > : Connection: keep-alive > > : > > : 13.000 > > Ага, теперь понятно. Перед "от клиента" можно вставить "полученных" > для ясности ИМХО. "чтение" как бы подразумевает "получение", не? > И понятно от какого момента ведётся отсчёт, но не > сказано, до какого момента. Например, до записи последнего байта > отправленного клиенту (или до чего там на самом деле оно измеряется). Как и для всех переменных, до момента вычисления значения переменной. В общем случае зависит от кэшируемости переменной (не освещено в документации) и от знания, в какой момент времени это значение вычисляется. Но как правило интуитивно понятно. Например, в момент формирования заголовка ответа, или в момент записи в access_log. И в зависимости от, $request_time будет означать разные вещи. > Т.е. чтение и запись - это сугубо программистские термины, выросшие из > имён функций read() и write(). ИМХО, понятнее получать и отправлять > данные. Можно ещё сказать "время, прошедшее с момента получения сервером первых байт запроса" > Хотя наверное сам вечером торможу и к чужим словам начинаю придираться > :-) Нет, просто $request_time вне контекста access_log это и вправду трудно поддающаяся словесному описанию сущность, т.к. "момент до" неизвестен. При переделке $request_time в обычную переменную это породило достаточно длинную внутреннюю дискуссию по формулировке её описания. Замечу, что описание $request_time в модуле ngx_http_log_module осталось прежним; там "момент до" описан более конкретно, т.к. он известен. From postmaster at softsearch.ru Sat Jan 19 08:46:40 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 19 Jan 2013 12:46:40 +0400 Subject: =?UTF-8?B?UmU6INC+0L/RgtC40LzQuNC30LDRgtC+0YAg0LrQvtC90YTQuNCz0LAg0LTQu9GP?= =?UTF-8?B?IG5naW54?= In-Reply-To: <50F9BD95.1050205@csdoc.com> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> <798185497.20130118195435@softsearch.ru> <50F98F59.9020003@csdoc.com> <137844373.20130119000928@softsearch.ru> <50F9BD95.1050205@csdoc.com> Message-ID: <180828139.20130119124640@softsearch.ru> Здравствуйте, Gena. > обычно у пользователей на машинах "конфиг nginx" - это понятие > растяжимое на десятки и сотни файлов. основной конфиг - nginx.conf в > который потом включаются файлы с фрагментами для отдельных сайтов > закачивать это вручную через формы на сайт - занятие утомительное, > даже если перед тем вручную сделать архив каталога со всеми > конфигами. Если по одному выбирать, то да. Но браузеры и HTML позволяют выбирать несколько файлов в одном тэге http://htmlbook.ru/html/input/multiple . Т.е. много файлов выбрать так же легко, как и один. У меня, кстати, на некоторых серверах один большой генерённый конфиг, на некоторых рукописный составной с инклюдами из 3-5 файлов. > обычно скрипты запускаемые на локальной машине удобнее. хотя бы > потому что им не надо будет вручную рассказывать какая конфигурация > машины и какой тип нагрузки (это можно взять из логов) Согласен. Но есть и минусы: они лишены удобства интерфейса, который даёт браузер. > и как потом монетизировать этот сервис - обвешать его баннерами? nginx.com монетезировал бы их в своих клиентов. А Адсенс можно уже сейчас можно на форуме повесить, если уж очень нужно. Хотя я б не стал, если денег хватает. Но там будет 100-200$ в месяц в лучшем случае. >>>> Такой сервис с одной стороны привлёк бы к nginx.com много >>>> вебмастеров, особенно неаглоязычных и нерусскоязычных, т.е. не >>>> имеющих сложившихся сообществ, с другой - конвертировал бы их в >>>> клиентов . >>> вообще-то, такой веб-сервис уже есть, http://forum.nginx.org/ >> Вы предлагаете всё перечитывать или постить публично свой конфиг с >> вопросом: "Что тут можно улучшить?" > я не предлагаю, но видел такое неоднократно. Ещё одно доказательство востребованности сервиса оптимизации конфига nginx-а. :-) -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Sat Jan 19 09:30:30 2013 From: nginx-forum at nginx.us (scroitor) Date: Sat, 19 Jan 2013 04:30:30 -0500 Subject: =?UTF-8?B?UmU6INCR0L7Qu9GM0YjQvtC1INCy0YDQtdC80Y8g0LIgJHJlcXVlc3QgdGltZQ==?= In-Reply-To: <20130119065219.GA44210@lo0.su> References: <20130119065219.GA44210@lo0.su> Message-ID: <230b5f2d8b8aa0b591991561f65f4ee5.NginxMailingListRussian@forum.nginx.org> в документации следущее: $request_time время обработки запроса в секундах с точностью до миллисекунд; время, прошедшее с момента чтения первых байт от клиента до момента записи в лог после отправки последних байт клиенту Жаль, что нет никакого флага, определяющего "момент до". По умолчанию можно и "момент отправки последних байт клиенту". Но в большинстве случаев интерес представляет быстрота, с какой nginx/backend справляется чисто со своей работой, а не тормознутость последней шага "отдачи клиенту", на которую nginx никак повлиять не может. Возможность "до момента отправки первого байта ответа клиенту" или "до момента полного получения ответа из кэша или от бэкенда и готовности отдать клиенту" приветствовалась бы многими. Отдельный вопрос с отдачей стримов, но там request_time как мерило проворности и здоровья сервера вообще теряет смысл. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235287,235301#msg-235301 From postmaster at softsearch.ru Sat Jan 19 09:57:54 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 19 Jan 2013 13:57:54 +0400 Subject: =?UTF-8?B?UmVbMl06INCR0L7Qu9GM0YjQvtC1INCy0YDQtdC80Y8g0LIgJHJlcXVlc3QgdGlt?= =?UTF-8?B?ZQ==?= In-Reply-To: <230b5f2d8b8aa0b591991561f65f4ee5.NginxMailingListRussian@forum.nginx.org> References: <20130119065219.GA44210@lo0.su> <230b5f2d8b8aa0b591991561f65f4ee5.NginxMailingListRussian@forum.nginx.org> Message-ID: <1713945546.20130119135754@softsearch.ru> Здравствуйте, scroitor. > Жаль, что нет никакого флага, определяющего "момент до". По умолчанию можно > и "момент отправки последних байт клиенту". > Но в большинстве случаев интерес представляет быстрота, с какой > nginx/backend справляется чисто со своей работой, а не тормознутость > последней шага "отдачи клиенту", на которую nginx никак повлиять не может. На самом деле не только. Я б хотел иметь возможность как-то пометить клиентов, качающих медленее, чем Х байт в секунду. Для них потом можно было картинки сильнее сжимать. Для jpeg-ов это может быть большая разница в размерах. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sat Jan 19 10:09:22 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 19 Jan 2013 14:09:22 +0400 Subject: =?UTF-8?B?aW5jcWxlbiDQv9C+0YfRgtC4INGA0LDQstC90LAgbWF4cWxlbg==?= Message-ID: <27756096.20130119140922@softsearch.ru> Здравствуйте. Увидел вот такую картину на порту, который слушает nginx: netstat -Lan Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/3940/4096 хх.хх.хх.хх.80 После прочтения http://sysoev.ru/freebsd/netstat.html остался вопрос. Что происходит с очередью incqlen, если она доходит до maxqlen? При этом используется accept_filter=httpready и net.inet.tcp.syncookies: 1 Не будут ли нормальные соединения дропаться из-за того, что очередь incqlen забита в своём большинстве скорее всего мёртвыми соединениями? -- С уважением, Михаил mailto:postmaster at softsearch.ru From pavel2000 at ngs.ru Sat Jan 19 11:18:40 2013 From: pavel2000 at ngs.ru (Pavel V.) Date: Sat, 19 Jan 2013 18:18:40 +0700 Subject: =?UTF-8?B?UmU6INCR0L7Qu9GM0YjQvtC1INCy0YDQtdC80Y8g0LIgJHJlcXVlc3QgdGltZQ==?= In-Reply-To: <230b5f2d8b8aa0b591991561f65f4ee5.NginxMailingListRussian@forum.nginx.org> References: <20130119065219.GA44210@lo0.su> <230b5f2d8b8aa0b591991561f65f4ee5.NginxMailingListRussian@forum.nginx.org> Message-ID: <926475843.20130119181840@ngs.ru> Здравствуйте, scroitor. > Жаль, что нет никакого флага, определяющего "момент до". По умолчанию можно > и "момент отправки последних байт клиенту". > Но в большинстве случаев интерес представляет быстрота, с какой > nginx/backend справляется чисто со своей работой, а не тормознутость > последней шага "отдачи клиенту", на которую nginx никак повлиять не может. > Возможность "до момента отправки первого байта ответа клиенту" или "до > момента полного получения ответа из кэша или от бэкенда и готовности отдать > клиенту" приветствовалась бы многими. Отдельный вопрос с отдачей стримов, но > там request_time как мерило проворности и здоровья сервера вообще теряет > смысл. http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables Нужно использовать переменную $upstream_response_time . IMHO, она доступна даже если не описывать группы серверов используя upstream {}, а просто использовать proxy_pass. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From bdfy at mail.ru Sat Jan 19 11:46:32 2013 From: bdfy at mail.ru (=?UTF-8?B?SXZhbg==?=) Date: Sat, 19 Jan 2013 15:46:32 +0400 Subject: =?UTF-8?Q?Opera_Turbo_=D0=B8_remote=5Faddr?= Message-ID: <1358595992.229357203@f294.mail.ru> Вопрос скорее не к nginx, а к Opera Turbo, но может кто знает :). Я попытался использовать в  nginx проверку на remote_addr. Это работает пока юзер не включает в Opera функцию Opera Turbo. Соотв входящие и исходящие запросы идут с разных адресов. Эту проблему можно как-то решить ? ( может быть  "правильные" прокси сервера в каких-то заголовках передают "реальный"  адрес ) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Jan 19 12:02:01 2013 From: nginx-forum at nginx.us (somebi) Date: Sat, 19 Jan 2013 07:02:01 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC40LfQvtCx0YDQsNC20LU=?= =?UTF-8?B?0L3QuNC5INGH0LXRgNC10LcgTmdpbngg0LIgRmxhc2gu?= In-Reply-To: <201301182312.50018.vbart@nginx.com> References: <201301182312.50018.vbart@nginx.com> Message-ID: Как вы тогда объясните то, что через google chrome, без флеша картинки проксируются без проблем? В общем я плюнул на эту затею и написал свой прокси сервер. Теперь все отлично работает. Так что разбирайтесь там, а то теряете доверие... Мне сидеть и разбираться по 5 часов, в чем же причина как-то еще раз не хочеться... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235263,235306#msg-235306 From kav at karagodov.name Sat Jan 19 12:18:07 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Sat, 19 Jan 2013 16:18:07 +0400 Subject: =?UTF-8?Q?Re=3A_=5BSPAM=5DOpera_Turbo_=D0=B8_remote=5Faddr?= In-Reply-To: <1358595992.229357203@f294.mail.ru> References: <1358595992.229357203@f294.mail.ru> Message-ID: <694BE3A7-45C8-4CD2-A5FA-E9C6765F744A@karagodov.name> вроде как передают но зависит от прокси (настроек прокси-сервера) сразу вычёркиваем анонимизирующие прокси остальное гуглим ;-) там куча заголовков передаётся, на самом деле, надо просто поглазеть, почитать On 19.01.2013, at 15:46, Ivan wrote: > Вопрос скорее не к nginx, а к Opera Turbo, но может кто знает :). > Я попытался использовать в nginx проверку на remote_addr. Это работает пока юзер не включает в Opera функцию Opera Turbo. Соотв входящие и исходящие запросы идут с разных адресов. Эту проблему можно как-то решить ? ( может быть "правильные" прокси сервера в каких-то заголовках передают "реальный" адрес ) ? > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Sat Jan 19 12:37:11 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 19 Jan 2013 16:37:11 +0400 Subject: =?UTF-8?Q?Re=3A_Opera_Turbo_=D0=B8_remote=5Faddr?= In-Reply-To: <1358595992.229357203@f294.mail.ru> References: <1358595992.229357203@f294.mail.ru> Message-ID: <1079961833.20130119163711@softsearch.ru> Здравствуйте, Ivan. Пропиши в конфиге set_real_ip_from 59.151.106.227; set_real_ip_from 59.151.106.228/30; set_real_ip_from 59.151.106.232/29; set_real_ip_from 59.151.106.240/29; set_real_ip_from 59.151.106.248/30; set_real_ip_from 59.151.106.252; set_real_ip_from 64.255.164.0/24; set_real_ip_from 64.255.180.0/24; set_real_ip_from 80.232.117.0/24; set_real_ip_from 80.239.242.0/23; set_real_ip_from 82.145.208.0/20; set_real_ip_from 91.203.96.0/22; set_real_ip_from 195.189.142.0/23; set_real_ip_from 141.0.8.0/21; set_real_ip_from 217.212.230.0/23; real_ip_header X-Forwarded-For; И вместо серверов Оперы будут видны реальные ip-шки. -- С уважением, Михаил mailto:postmaster at softsearch.ru From citrin at citrin.ru Sat Jan 19 13:28:58 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Sat, 19 Jan 2013 17:28:58 +0400 Subject: =?UTF-8?Q?Re=3A_Opera_Turbo_=D0=B8_remote=5Faddr?= In-Reply-To: <1358595992.229357203@f294.mail.ru> References: <1358595992.229357203@f294.mail.ru> Message-ID: <50FA9F9A.8060309@citrin.ru> 19.01.2013 15:46, Ivan пишет: > Я попытался использовать в nginx проверку на remote_addr. Это работает > пока юзер не включает в Opera функцию Opera Turbo. Соотв входящие и > исходящие запросы идут с разных адресов. Эту проблему можно как-то > решить ? ( может быть "правильные" прокси сервера в каких-то заголовках > передают "реальный" адрес ) ? Некоторые прокси сервера передают реальный адрес клиента в заголовке X-Forwarded-For и прокси сервера Оперы это делают. В случае если проверка remote_addr делается средствами модуля ngx_http_geo_module можно использовать директиву proxy geo $country { ... proxy 80.84.1.18/31; proxy 80.84.1.20/31; proxy 80.232.117.0/24; proxy 80.239.242.0/23; proxy 82.145.208.0/21; proxy 82.145.216.0/23; proxy 91.203.96.0/24; proxy 94.246.126.0/23; proxy 141.0.8.0/22; proxy 195.189.142.0/23; proxy 217.212.230.0/23; ... } Подробнее смотрите в http://nginx.org/r/geo From gmm at csdoc.com Sat Jan 19 18:26:53 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 19 Jan 2013 20:26:53 +0200 Subject: =?UTF-8?B?UmU6INC+0L/RgtC40LzQuNC30LDRgtC+0YAg0LrQvtC90YTQuNCz0LAg0LTQu9GP?= =?UTF-8?B?IG5naW54?= In-Reply-To: <180828139.20130119124640@softsearch.ru> References: <50F939D0.1010707@kopeyko.ru> <50F9494F.3060701@csdoc.com> <798185497.20130118195435@softsearch.ru> <50F98F59.9020003@csdoc.com> <137844373.20130119000928@softsearch.ru> <50F9BD95.1050205@csdoc.com> <180828139.20130119124640@softsearch.ru> Message-ID: <50FAE56D.3050801@csdoc.com> On 19.01.2013 10:46, Михаил Монашёв wrote: >> и как потом монетизировать этот сервис - обвешать его баннерами? > nginx.com монетезировал бы их в своих клиентов. nginx и так самый быстрорастущий сервер по всем категориям на сегодня http://news.netcraft.com/archives/2013/01/07/january-2013-web-server-survey-2.html >>> Вы предлагаете всё перечитывать или постить публично свой конфиг с >>> вопросом: "Что тут можно улучшить?" >> я не предлагаю, но видел такое неоднократно. > Ещё одно доказательство востребованности сервиса оптимизации конфига > nginx-а. > :-) вообще-то, я неоднократно видел такие конфиги nginx, прочитав которые даже Igor Sysoev не мог понять что автор конфига хотел этим сказать. сомневаюсь что в этом случае правильно распознать логику работы программы сможет скрипт, тем более, что в зависимости от версии nginx и опций configure разные директивы ведут себя по разному. а ведь чтобы оптимизировать конфиг nginx нужно некоторое количество времени и желания - внимательно прочитать доку и понять что там написано. тем более, что в сложных случаях можно посмотреть отладочный лог / исходники и все станет очевидным. а вариант http://button.dekel.ru/ бывает только в сказке. или на странице http://nginx.com/support.html -- Best regards, Gena From nginx-forum at nginx.us Sat Jan 19 21:34:31 2013 From: nginx-forum at nginx.us (Trurl) Date: Sat, 19 Jan 2013 16:34:31 -0500 Subject: nginx + nfs Message-ID: Добрый вечер. Собираюсь ставить nginx для отдачи статики, контент на 99% с файлера через nfs. Точнее заменять lighttpd на nginx (у lighttpd достали приколы с кривизной mod_expire) Таких серверов 7 штук пока, основная нагрузка у них - апач-пхп и, в основном (99.9%), _не_ на nfs. На данный момент работа lighttpd там вообще не заметна, максимум 2 десятка запросов одновременно. Если какие-то особенности при работе с nfs? Нагрузка в целом не большая, ибо далее идут кеширующие сервера, которые принимают на себя до 80% запросов. Часть файлов довольно большая (видео до 2ГБ и более, такие же жирные архивы и тп). Остальное - очень много картинок (0.5-5МБ). Много - это значит на сервера с nginx это количество никак не влезет, то есть кешировать этот контент на этом уровне смысла нет. Интересуют тонкости типа настроек sendfile и тому подобного. ЗЫ. В крайнем случае могу поставить nginx прямо на файлере, но оченно не желательно, ибо выхода в инет у него нет (то есть только в качестве апстрима), и эта статика для него не единственная задача. ЗЗЫ. каждый nginx в перспективе должен под себя подмять апачи, которые будет работать апстримом (все для каждого, легкий лоадбалансинг), там уже и кеширование немного будет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235317,235317#msg-235317 From postmaster at softsearch.ru Sat Jan 19 21:48:32 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 20 Jan 2013 01:48:32 +0400 Subject: nginx + nfs In-Reply-To: References: Message-ID: <1619358747.20130120014832@softsearch.ru> Здравствуйте, Trurl. > В крайнем случае могу поставить nginx прямо на файлере, но оченно не > желательно, ибо выхода в инет у него нет (то есть только в качестве > апстрима), и эта статика для него не единственная задача. Это самый лучший вариант. nginx каши просить не будет вообще, а возсможные глюки, связанные с nfs, совсем не проявятся. P.S. Выкиньте Вы ваши сквиды и nfs из головы. Это прошлый век. nginx заменяет и одно и второе. http://nginx.org/ru/docs/http/ngx_http_dav_module.html -- С уважением, Михаил mailto:postmaster at softsearch.ru From trurl at mcbyte.net Sat Jan 19 22:01:11 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Sun, 20 Jan 2013 00:01:11 +0200 Subject: nginx + nfs In-Reply-To: <1619358747.20130120014832@softsearch.ru> References: <1619358747.20130120014832@softsearch.ru> Message-ID: ладно, буду пытаться ставить на файлере. PS. Ну пока я на практике вижу что ничуть не заменяет. Сквид в качестве удаленного акселератора при геолоадбалансинге сотен разнообразных сайтов оказывается в разы эффективнее. Не лучше, а именно эффективнее по соотношению "входящий-исходящий траффик". Я понимаю что частично он этого добивается за счет "stale entry", работы с Vary (которую я частично эмулирую на nginx) и тормознутости работы с аплинками, но в результате разница уж слишком заметная. Там где на сервере со squid входящий трафик - 2-10Мбитс, на nginx достигает - 200Мбитс. То есть недостатки сквида в данном случае тоже работают как достоинства. 19 января 2013 г., 23:48 пользователь Михаил Монашёв < postmaster at softsearch.ru> написал: > Здравствуйте, Trurl. > > > В крайнем случае могу поставить nginx прямо на файлере, но оченно не > > желательно, ибо выхода в инет у него нет (то есть только в качестве > > апстрима), и эта статика для него не единственная задача. > > Это самый лучший вариант. nginx каши просить не будет вообще, а > возсможные глюки, связанные с nfs, совсем не проявятся. > > P.S. > Выкиньте Вы ваши сквиды и nfs из головы. Это прошлый век. nginx > заменяет и одно и второе. > http://nginx.org/ru/docs/http/ngx_http_dav_module.html > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Sat Jan 19 22:13:12 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 20 Jan 2013 02:13:12 +0400 Subject: =?UTF-8?B?0JjQtNC10Lgg0L/RgNC+IHByb3h5X2NhY2hlX21pbl91c2VzLg==?= Message-ID: <908559217.20130120021312@softsearch.ru> Здравствуйте. Есть прекрасная директива proxy_cache_min_uses . Она позволяет сильно экономить на дисковой нагрузке, которую создают записывающиеся в кэш файлы, к которым делается всего один запрос и которые потом вымываются из кэша . Было бы здорово развить идею и сэкономить ещё. Например, proxy_cache_min_uses=2. Приходит запрос к кэшу, в кэше файла нет, и это первое обращение к файлу. Т.е. мы должны сначала скачать файл с хранилища, а потом только отдать его в инет. И при этом сам файл в кэш не положится. Т.е. кэширующий сервер просто ненужный посредник между браузером и хранилищем файлов. Было бы возможно оптимальнее кэширующему серверу выдать вместо файла, взятого из хранилища, временный редирект на хранилище. Т.е. отдавать файл напрямую с хранилища, если он не будет класться в кэш. При этом экономится и трафик и ресурсы кэширующего сервера. Возможно подобное можно сделать уже сейчас, только я не знаю как. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sat Jan 19 22:18:40 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 20 Jan 2013 02:18:40 +0400 Subject: nginx + nfs In-Reply-To: References: <1619358747.20130120014832@softsearch.ru> Message-ID: <979111629.20130120021840@softsearch.ru> Здравствуйте, Trurl. Вам просто нужно чуть глубже изучить nginx и продумать, как можно нужную Вам логику постепенно перенести в него. На том же встроенном перле можно можно писать сложную логику с учётом стоимости трафика и т.п. А все необходимые для перла данные получать из nginx-а . Встроенный перл шустрый, если там простыми if-ами и арифметическими функциями что-то делать. -- С уважением, Михаил mailto:postmaster at softsearch.ru From trurl at mcbyte.net Sat Jan 19 22:44:58 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Sun, 20 Jan 2013 00:44:58 +0200 Subject: nginx + nfs In-Reply-To: <979111629.20130120021840@softsearch.ru> References: <1619358747.20130120014832@softsearch.ru> <979111629.20130120021840@softsearch.ru> Message-ID: Это хорошо для стартапа, а не для уже существующих сотен сайтов с разной архитектурой, написанных разными программистами. Слава богу хоть почти у всех нормальная работа с кеш-контрол. И в данном случае сквид почти идеален. Вот только крашится он частенько при большой нагрузке, что раздражает. Поэтому и сижу над nginx... PS. Например я пока на вижу в nginx возможности что-то делать с запросом в зависимости от размеров ответа до того как выбрано у кого, собственно, его спрашивать. ngx_http_forecasting никто не видел? Да и про ограничение канала к апстриму и работу с сиблингами я уже спрашивал... 20 января 2013 г., 0:18 пользователь Михаил Монашёв < postmaster at softsearch.ru> написал: > Здравствуйте, Trurl. > > Вам просто нужно чуть глубже изучить nginx и продумать, как можно > нужную Вам логику постепенно перенести в него. На том же встроенном > перле можно можно писать сложную логику с учётом стоимости трафика и > т.п. А все необходимые для перла данные получать из nginx-а . > Встроенный перл шустрый, если там простыми if-ами и арифметическими > функциями что-то делать. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Sat Jan 19 23:09:01 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 20 Jan 2013 03:09:01 +0400 Subject: =?UTF-8?B?UmU6ICDQn9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtSDQuNC30L7QsdGA0LDQttC1?= =?UTF-8?B?0L3QuNC5INGH0LXRgNC10LcgTmdpbngg0LIgRmxhc2gu?= In-Reply-To: References: <201301182312.50018.vbart@nginx.com> Message-ID: <201301200309.01866.vbart@nginx.com> On Saturday 19 January 2013 16:02:01 somebi wrote: > Как вы тогда объясните то, что через google chrome, без флеша картинки > проксируются без проблем? В HTTP/1.x запросе помимо строки запроса и тела бывают ещё заголовки. Об этом вы можете узнать, например, из RFC 2616 ( http://tools.ietf.org/html/rfc2616 ). В частности, когда вы открываете картинку в хроме напрямую, то такой заголовок как "Referer" он обычно не посылает. Именно на этот заголовок указанный в логе сервер (на который вы проксируете запрос) реагирует таким вот образом (отдает 503 вместо картинки), в чем не трудно убедиться. Простой запрос: % telnet ns223506.ovh.net 80 Trying 46.105.113.99... Connected to ns223506.ovh.net. Escape character is '^]'. GET /rozne/001017635f42c3ca1bac9f0e7e2d4ac7/wallpaper-2584886.jpg HTTP/1.0 Host: ns223506.ovh.net HTTP/1.1 200 OK Server: nginx/1.1.1 Date: Sat, 19 Jan 2013 22:18:32 GMT Content-Type: image/jpeg Content-Length: 782444 Last-Modified: Sat, 12 Jan 2013 15:34:54 GMT Connection: close Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Accept-Ranges: bytes [...] И с "Referer" в запросе: % telnet ns223506.ovh.net 80 Trying 46.105.113.99... Connected to ns223506.ovh.net. Escape character is '^]'. GET /rozne/001017635f42c3ca1bac9f0e7e2d4ac7/wallpaper-2584886.jpg HTTP/1.0 Host: ns223506.ovh.net Referer: http://example.com/ HTTP/1.1 503 Service Temporarily Unavailable Server: nginx/1.1.1 Date: Sat, 19 Jan 2013 22:18:57 GMT Content-Type: text/html Content-Length: 212 Connection: close 503 Service Temporarily Unavailable

503 Service Temporarily Unavailable


nginx/1.1.1
Connection closed by foreign host. Возможно, что не на любое значение "Referer" такая реакция. Не исключено, что такую защиту сделали специально. В приведенном же вами логе видно, что на nginx пришел запрос с заголовком "Referer", который nginx честно передал дальше и получил 503 в ответ. Указание nginx не передавать заголовок "Referer": proxy_set_header referer ""; решило бы вашу проблему. Документация: http://nginx.org/r/proxy_set_header/ru > > В общем я плюнул на эту затею и написал свой прокси сервер. Теперь все > отлично работает. Так что разбирайтесь там, а то теряете доверие... Мне > сидеть и разбираться по 5 часов, в чем же причина как-то еще раз не > хочеться... > -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From nginx-forum at nginx.us Sun Jan 20 00:39:21 2013 From: nginx-forum at nginx.us (Trurl) Date: Sat, 19 Jan 2013 19:39:21 -0500 Subject: =?UTF-8?B?0L/QvtCy0LXQtNC10L3QuNC1IGV4cGlyZXMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= Message-ID: <46a625ddc5ad8a3b9c4b6ac0916bc3c9.NginxMailingListRussian@forum.nginx.org> тут такая ситуация - сервер выставляет "add_header Cache-Control public" и свой expires, например получается "Cache-Control: max-age=6048000, public" другой сервер у него таскает данные (proxy_pass) и в некоторых случаях выставляет другой expires, и при этом теряется "public" - "Cache-Control: max-age=180" Это так и задумано или все-таки баг? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235325,235325#msg-235325 From mdounin at mdounin.ru Sun Jan 20 02:33:20 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 20 Jan 2013 06:33:20 +0400 Subject: =?UTF-8?B?UmU6IGluY3FsZW4g0L/QvtGH0YLQuCDRgNCw0LLQvdCwIG1heHFsZW4=?= In-Reply-To: <27756096.20130119140922@softsearch.ru> References: <27756096.20130119140922@softsearch.ru> Message-ID: <20130120023320.GF61185@mdounin.ru> Hello! On Sat, Jan 19, 2013 at 02:09:22PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Увидел вот такую картину на порту, который слушает nginx: > netstat -Lan > Current listen queue sizes (qlen/incqlen/maxqlen) > Proto Listen Local Address > tcp4 0/3940/4096 хх.хх.хх.хх.80 > > После прочтения http://sysoev.ru/freebsd/netstat.html остался вопрос. > Что происходит с очередью incqlen, если она доходит до maxqlen? > При этом используется accept_filter=httpready и net.inet.tcp.syncookies: 1 > > Не будут ли нормальные соединения дропаться из-за того, что очередь > incqlen забита в своём большинстве скорее всего мёртвыми соединениями? Из incqlen при переполнении выкидываются самые старые соединения, так что ничего плохого - быть не должно. -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Sun Jan 20 02:48:58 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 20 Jan 2013 06:48:58 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <1873254546.20130115021247@mtu-net.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <109559121.20130114175954@mtu-net.ru> <20130114142427.GZ25043@mdounin.ru> <1873254546.20130115021247@mtu-net.ru> Message-ID: <20130120024858.GG61185@mdounin.ru> Hello! On Tue, Jan 15, 2013 at 02:12:47AM +0400, Andrey Repin wrote: > Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! > >> >> > А, нет, вру, должно быть всё нормально и без пробела, это > >> >> > действительно бага. > >> >> > >> >> > У тебя proxy_method задан на уровне http{}, да? > >> >> > >> >> Да, на уровне http{}. > >> > >> MD> Патч. > >> > >> Неправильный патч. > >> Правильно будет делать trim() и добавлять пробел всегда. > > MD> А не по^Wвсё ли равно? > > Не всё. Есть стандарты. Чем точнее ты им следуешь, тем меньше мест трубуется > перепроверять. Я, например, с трудом продрался через код вашего патча, и мне > помогло только то, что я знал, с чего всё началось. Это уже говорит о том, что > "что-то здесь не так". > > MD> Цель схлопнуть несколько пробелов в один, > MD> если их там вдруг больше одного, мне представляется старнной и > MD> малоосмысленной. Пробел - разделитель, сколько их там будет, если > MD> пользователь написал в конфиге метод с пробелами - неважно. > > В стандарте указан один пробел. Это, к сожалению, неправда. Ссылку я уже в этом треде приводил, но таки мне не жалко и второй раз её же дать. Читать про "implied *LWS" тут: http://tools.ietf.org/html/rfc2616#section-2.1 -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Sun Jan 20 02:49:57 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 20 Jan 2013 06:49:57 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQs9CwINCyIHByb3h5X21ldGhvZA==?= In-Reply-To: <8010040080.20130118231218@softsearch.ru> References: <11810138060.20130113225903@softsearch.ru> <20130114025401.GF25043@mdounin.ru> <332296434.20130114134343@softsearch.ru> <20130114110445.GM25043@mdounin.ru> <20130114112306.GP25043@mdounin.ru> <801495053.20130114152832@softsearch.ru> <20130114124616.GS25043@mdounin.ru> <8010040080.20130118231218@softsearch.ru> Message-ID: <20130120024956.GH61185@mdounin.ru> Hello! On Fri, Jan 18, 2013 at 11:12:18PM +0400, Михаил Монашёв wrote: [...] > Патч наложил. Написал в конфиге: > proxy_method GET; > > На бэкенд шлёт нормальные запросы. А как правильно писать: > proxy_method GET; > или > proxy_method "GET "; > ? > > Т.е. пробел после названия метода обязателен или нет? Нет, пробел не нужен. -- Maxim Dounin http://nginx.com/support.html From pavel2000 at ngs.ru Sun Jan 20 08:02:40 2013 From: pavel2000 at ngs.ru (Pavel V.) Date: Sun, 20 Jan 2013 15:02:40 +0700 Subject: =?UTF-8?B?UmU6INCY0LTQtdC4INC/0YDQviBwcm94eV9jYWNoZV9taW5fdXNlcy4=?= In-Reply-To: <908559217.20130120021312@softsearch.ru> References: <908559217.20130120021312@softsearch.ru> Message-ID: <817941926.20130120150240@ngs.ru> Здравствуйте, Михаил. Вы писали 20 января 2013 г., 5:13:12: > Здравствуйте. > Есть прекрасная директива proxy_cache_min_uses . Она позволяет сильно > экономить на дисковой нагрузке, которую создают записывающиеся в кэш > файлы, к которым делается всего один запрос и которые потом вымываются > из кэша . > Было бы здорово развить идею и сэкономить ещё. > Например, proxy_cache_min_uses=2. Приходит запрос к кэшу, в кэше файла > нет, и это первое обращение к файлу. Т.е. мы должны сначала скачать > файл с хранилища, а потом только отдать его в инет. И при этом сам > файл в кэш не положится. Т.е. кэширующий сервер просто ненужный > посредник между браузером и хранилищем файлов. Было бы возможно > оптимальнее кэширующему серверу выдать вместо файла, взятого из > хранилища, временный редирект на хранилище. Т.е. отдавать файл > напрямую с хранилища, если он не будет класться в кэш. При этом > экономится и трафик и ресурсы кэширующего сервера. > Возможно подобное можно сделать уже сейчас, только я не знаю как. На мой взгляд, это возможно сделать уже сейчас как-то так (Idea only): Запрос приходит в локейшн, где уже прописано кеширование. Если в кеше есть ответ на запрос, то отдается ответ. Но проксирование запроса в этом локейшне настроено не на хранилище, а на "маршрутизирующий скрипт", и если в кеше ответа нет, то запрос улетает на "маршрутизирующий скрипт", который обсчитывает количество обращений, знает на каком хранилище лежит требуемый файл и тд В скрипте делаем проверки. Если количество обращений не достигло порога - отдаем временный редирект. Если достигло - отдаем X-Accel-Redirect на проксирование запроса на хранилище. Единственное, что потребуется - описать в локейшне, на который отправит X-Accel-Redirect, те же самые настройки кеширования, что и в основном локейшне, чтобы при повторном запросе данные отдались из кеша Nginx. Возможно это же можно реализовать на встроенном perl.. Всё это только теоретическая идея по возможной реализации, ничего не проверялось. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From danila at shtan.ru Sun Jan 20 09:59:08 2013 From: danila at shtan.ru (Danila Shtan) Date: Sun, 20 Jan 2013 15:59:08 +0600 Subject: =?UTF-8?B?UmU6INCY0LTQtdC4INC/0YDQviBwcm94eV9jYWNoZV9taW5fdXNlcy4=?= In-Reply-To: <817941926.20130120150240@ngs.ru> References: <908559217.20130120021312@softsearch.ru> <817941926.20130120150240@ngs.ru> Message-ID: Приветствую. воскресенье, 20 января 2013 г. пользователь Pavel V. писал: > Здравствуйте, Михаил. > > Вы писали 20 января 2013 г., 5:13:12: > > > Здравствуйте. > > > Есть прекрасная директива proxy_cache_min_uses . Она позволяет сильно > > экономить на дисковой нагрузке, которую создают записывающиеся в кэш > > файлы, к которым делается всего один запрос и которые потом вымываются > > из кэша . > > > Было бы здорово развить идею и сэкономить ещё. > > > Например, proxy_cache_min_uses=2. Приходит запрос к кэшу, в кэше файла > > нет, и это первое обращение к файлу. Т.е. мы должны сначала скачать > > файл с хранилища, а потом только отдать его в инет. И при этом сам > > файл в кэш не положится. Т.е. кэширующий сервер просто ненужный > > посредник между браузером и хранилищем файлов. Было бы возможно > > оптимальнее кэширующему серверу выдать вместо файла, взятого из > > хранилища, временный редирект на хранилище. Т.е. отдавать файл > > напрямую с хранилища, если он не будет класться в кэш. При этом > > экономится и трафик и ресурсы кэширующего сервера. > > > Возможно подобное можно сделать уже сейчас, только я не знаю как. > > На мой взгляд, это возможно сделать уже сейчас как-то так (Idea only): > > Запрос приходит в локейшн, где уже прописано кеширование. > Если в кеше есть ответ на запрос, то отдается ответ. > > Но проксирование запроса в этом локейшне настроено не на хранилище, а на > "маршрутизирующий скрипт", > и если в кеше ответа нет, то запрос улетает на "маршрутизирующий скрипт", > который обсчитывает > количество обращений, знает на каком хранилище лежит требуемый файл и тд > > В скрипте делаем проверки. Если количество обращений не достигло порога - > отдаем временный редирект. > Если достигло - отдаем X-Accel-Redirect на проксирование запроса на > хранилище. > Единственное, что потребуется - описать в локейшне, на который отправит > X-Accel-Redirect, те же самые настройки кеширования, что и в основном > локейшне, чтобы при повторном > запросе данные отдались из кеша Nginx. X-Accel-Redirect ничем не отличается от существующего поведения самого nginx, только. > > Возможно это же можно реализовать на встроенном perl.. > > Всё это только теоретическая идея по возможной реализации, ничего не > проверялось. > > -- > С уважением, > Pavel mailto:pavel2000 at ngs.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Sun Jan 20 16:11:50 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Sun, 20 Jan 2013 18:11:50 +0200 Subject: =?UTF-8?B?0J3QtdC00L7QutGD0LzQtdC90YLQuNGA0L7QstCw0L3QvdGL0LUg0LLQvtC30Lw=?= =?UTF-8?B?0L7QttC90L7RgdGC0Lggc2VjdXJlX2xpbms=?= Message-ID: <50FC1746.9070507@csdoc.com> Здравствуйте! в интернете обнаружилась статья: http://habrahabr.ru/post/120907/ Недокументированные возможности secure_link - в документации эти возможности действительно никак не отображены. это просто потому что забыли/не успели актуализировать документацию, или тут есть какие-то нюансы и это было сознательно не документировано? у недокументированных возможностей ведь могут быть нюансы, например как у директивы "post_action", может быть и тут что-то аналогичное? -- Best regards, Gena From alexander.moskalenko at gmail.com Sun Jan 20 18:18:36 2013 From: alexander.moskalenko at gmail.com (Alexander Moskalenko) Date: Sun, 20 Jan 2013 20:18:36 +0200 Subject: =?UTF-8?B?UmU6INCd0LXQtNC+0LrRg9C80LXQvdGC0LjRgNC+0LLQsNC90L3Ri9C1INCy0L4=?= =?UTF-8?B?0LfQvNC+0LbQvdC+0YHRgtC4IHNlY3VyZV9saW5r?= In-Reply-To: <50FC1746.9070507@csdoc.com> References: <50FC1746.9070507@csdoc.com> Message-ID: 2 года назад делали по официальной документации то что написано по ссылке 2013/1/20 Gena Makhomed : > Здравствуйте! > > в интернете обнаружилась статья: > > http://habrahabr.ru/post/120907/ > Недокументированные возможности secure_link > > - в документации эти возможности действительно никак не отображены. > > это просто потому что забыли/не успели актуализировать документацию, > или тут есть какие-то нюансы и это было сознательно не документировано? > > у недокументированных возможностей ведь могут быть нюансы, например > как у директивы "post_action", может быть и тут что-то аналогичное? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From bdfy at mail.ru Sun Jan 20 18:46:17 2013 From: bdfy at mail.ru (=?UTF-8?B?SXZhbg==?=) Date: Sun, 20 Jan 2013 22:46:17 +0400 Subject: =?UTF-8?B?UmVbMl06INCd0LXQtNC+0LrRg9C80LXQvdGC0LjRgNC+0LLQsNC90L3Ri9C1INCy?= =?UTF-8?B?0L7Qt9C80L7QttC90L7RgdGC0Lggc2VjdXJlX2xpbms=?= In-Reply-To: References: <50FC1746.9070507@csdoc.com> Message-ID: <1358707577.879022609@f267.mail.ru> смотря что считать официальной. По ссылке http://nginx.org/ru/docs/http/ngx_http_secure_link_module.html почти ничего нет, хотя вот тут все написано: http://wiki.nginx.org/HttpSecureLinkModule Воскресенье, 20 января 2013, 20:18 +02:00 от Alexander Moskalenko : >2 года назад делали по официальной документации то что написано по ссылке > > >2013/1/20 Gena Makhomed < gmm at csdoc.com >: >> Здравствуйте! >> >> в интернете обнаружилась статья: >> >> http://habrahabr.ru/post/120907/ >> Недокументированные возможности secure_link >> >> - в документации эти возможности действительно никак не отображены. >> >> это просто потому что забыли/не успели актуализировать документацию, >> или тут есть какие-то нюансы и это было сознательно не документировано? >> >> у недокументированных возможностей ведь могут быть нюансы, например >> как у директивы "post_action", может быть и тут что-то аналогичное? >> >> -- >> Best regards, >> Gena >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >_______________________________________________ >nginx-ru mailing list >nginx-ru at nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Sun Jan 20 19:10:06 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 20 Jan 2013 23:10:06 +0400 Subject: rewrite or internal redirection cycle Message-ID: <923476862.20130120231006@softsearch.ru> Здравствуйте. Увидел ошибку: 2013/01/18 22:30:21 [error] 10601#0: *43370718 rewrite or internal redirection cycle while internally redirecting to "/zero", client: 46.158.147.140, server: f.beon.ru, request: "GET /beon.ru HTTP/1.1", host: "f.beon.ru", referrer: "http://colesnik-2011.ya.ru/" Судя по конфигу всё нормально. И фавиконка верно отдаётся: http://f.beon.ru/beon.ru Не могу придумать как там что зацикливается. В каких случаях возникает такая ошибка? -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Sun Jan 20 21:11:17 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 21 Jan 2013 01:11:17 +0400 Subject: rewrite or internal redirection cycle In-Reply-To: <923476862.20130120231006@softsearch.ru> References: <923476862.20130120231006@softsearch.ru> Message-ID: <201301210111.17364.vbart@nginx.com> On Sunday 20 January 2013 23:10:06 Михаил Монашёв wrote: > Здравствуйте. > > Увидел ошибку: > > 2013/01/18 22:30:21 [error] 10601#0: *43370718 rewrite or internal > redirection cycle while internally redirecting to "/zero", client: > 46.158.147.140, server: f.beon.ru, request: "GET /beon.ru HTTP/1.1", host: > "f.beon.ru", referrer: "http://colesnik-2011.ya.ru/" > > Судя по конфигу всё нормально. И фавиконка верно отдаётся: > http://f.beon.ru/beon.ru Не могу придумать как там что зацикливается. В > каких случаях возникает такая ошибка? Когда делается более 10 внутренних перенаправлений. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From gmm at csdoc.com Sun Jan 20 21:16:01 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Sun, 20 Jan 2013 23:16:01 +0200 Subject: =?UTF-8?B?UmU6INCd0LXQtNC+0LrRg9C80LXQvdGC0LjRgNC+0LLQsNC90L3Ri9C1INCy0L4=?= =?UTF-8?B?0LfQvNC+0LbQvdC+0YHRgtC4IHNlY3VyZV9saW5r?= In-Reply-To: <1358707577.879022609@f267.mail.ru> References: <50FC1746.9070507@csdoc.com> <1358707577.879022609@f267.mail.ru> Message-ID: <50FC5E91.20502@csdoc.com> On 20.01.2013 20:46, Ivan wrote: > смотря что считать официальной. По ссылке > http://nginx.org/ru/docs/http/ngx_http_secure_link_module.html > > почти ничего нет, официальная документация - это http://nginx.org/ru/docs/ и http://nginx.org/en/docs/ > хотя вот тут все написано: > http://wiki.nginx.org/HttpSecureLinkModule а это просто wiki, там может быть много ошибок и устаревшей информации, потому что текст редактировать на wiki.nginx.org может кто угодно... -- Best regards, Gena From mdounin at mdounin.ru Sun Jan 20 23:03:10 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 21 Jan 2013 03:03:10 +0400 Subject: text/vnd.wap.wml error In-Reply-To: <25ca7c40dc00cd1c23974ef56051e758.NginxMailingListRussian@forum.nginx.org> References: <20130111092526.GU80623@mdounin.ru> <25ca7c40dc00cd1c23974ef56051e758.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130120230310.GF99404@mdounin.ru> Hello! On Tue, Jan 15, 2013 at 07:03:09AM -0500, Mamtesh Kumar wrote: > Hi Maxim, > > I also have same problem. What could be the reason of that?. Then we can > focus into that. Sorry, but I have no idea why your backend returns "text/html" instead of "text/vnd.wap.wml" (if you indeed have the same problem). It's up to your backend, and you should examine your backend's code to find out the reason. -- Maxim Dounin http://nginx.com/support.html From ru at nginx.com Mon Jan 21 08:55:46 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Mon, 21 Jan 2013 12:55:46 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQtNC+0LrRg9C80LXQvdGC0LjRgNC+0LLQsNC90L3Ri9C1INCy0L4=?= =?UTF-8?B?0LfQvNC+0LbQvdC+0YHRgtC4IHNlY3VyZV9saW5r?= In-Reply-To: <50FC5E91.20502@csdoc.com> References: <50FC1746.9070507@csdoc.com> <1358707577.879022609@f267.mail.ru> <50FC5E91.20502@csdoc.com> Message-ID: <20130121085546.GB69613@lo0.su> On Sun, Jan 20, 2013 at 11:16:01PM +0200, Gena Makhomed wrote: > On 20.01.2013 20:46, Ivan wrote: > > > смотря что считать официальной. По ссылке > > http://nginx.org/ru/docs/http/ngx_http_secure_link_module.html > > > > почти ничего нет, > > официальная документация - это http://nginx.org/ru/docs/ и > http://nginx.org/en/docs/ > > > хотя вот тут все написано: > > http://wiki.nginx.org/HttpSecureLinkModule > > а это просто wiki, там может быть много ошибок и устаревшей информации, > потому что текст редактировать на wiki.nginx.org может кто угодно... Да, на wiki есть неточности, в т.ч. и в описании этого модуля. Речь ниже только про официальную документацию. Модуль secure_link умеет работать в двух режимах, старом и новом. Старый режим полностью документирован. Новый режим сейчас никак не документирован, но патч, исправляющий это, уже находится в процессе review. From scukonick at gmail.com Mon Jan 21 09:40:00 2013 From: scukonick at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzQsNC70L7Qsg==?=) Date: Mon, 21 Jan 2013 13:40:00 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgiDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC10YDQsCBjIG5n?= =?UTF-8?B?aW54INC90LAg0L3QtdC60L7RgtC+0YDRi9C1IHN5bg==?= In-Reply-To: <201301181730.28560.vbart@nginx.com> References: <50F86091.8050402@amhost.net> <201301181730.28560.vbart@nginx.com> Message-ID: Нет, в диск не упиралось, и сторонних модулей тоже не было. В итоге помогло, похоже, выключение syn_cookies. Ниже конфигурация, при которой всё работает: net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_syncookies = 0 net.core.somaxconn = 262144 nginx.conf: user www-data; worker_processes 2; worker_rlimit_nofile 100000; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 65535; use epoll; } ... server { listen 80 default backlog=65000; ... } 18 января 2013 г., 17:30 пользователь Валентин Бартенев написал: > On Friday 18 January 2013 00:35:29 Alex Vorona wrote: > > 17.01.2013 14:08, Алексей Малов wrote: > > [...] > > > > > Из 1000 попыток открыть сокет около 30-50 отваливаются по таймауту (2 > > > секунды), остальные при этом коннектятся практически мгновенно. > > > > А что делают воркеры nginx? Не с диска отдают случайно данные, блокируясь > > при этом? > > > > Одна из частых причина блокировки рабочих процессов - сторонние модули, > многие > из которых написаны без учета асинхронной природы nginx. > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Alexey Malov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ufaweb at gmail.com Mon Jan 21 10:26:30 2013 From: ufaweb at gmail.com (=?UTF-8?B?0KDRg9GB0LvQsNC9INCo0LDRgNC40L/QvtCy?=) Date: Mon, 21 Jan 2013 16:26:30 +0600 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L7RgtCy0LXRgtC+0LIg0LTQu9GP?= =?UTF-8?B?INC90LUg0LDQstGC0L7RgNC40LfQvtCy0LDQvdC90YvRhSDQv9C+0LvRjNC3?= =?UTF-8?B?0L7QstCw0YLQtdC70LXQuQ==?= In-Reply-To: <50F939D0.1010707@kopeyko.ru> References: <50F939D0.1010707@kopeyko.ru> Message-ID: 18 января 2013 г., 18:02 пользователь Andrey Kopeyko написал: > > Добавьте директиву > > http://nginx.org/ru/docs/http/**ngx_http_proxy_module.html#** > proxy_cache_lock > > В приведенном мною конфиге данная директива добавлена, но тем не менее запросы уходят на apache. -- С уважением, Шарипов Руслан. Руководитель отдела разработки и сопровождения программного обеспечения ОАО "Уфанет". Контактная информация: google+: http://gplus.to/ruslan jid: serafim at jabber.ufanet.ru wave: ufaweb at googlewave.com skype: ufaweb phone: +7(917)4775460 vkontakte: http://vkontakte.ru/ufaweb myspace: http://www.myspace.com/ufaweb facebook: http://facebook.com/sharipov linkedin: http://www.linkedin.com/in/ufaweb twitter: http://twitter.com/ufaweb -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Mon Jan 21 10:46:08 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 21 Jan 2013 14:46:08 +0400 Subject: =?UTF-8?B?UmU6ICDQmtC10YjQuNGA0L7QstCw0L3QuNC1INC+0YLQstC10YLQvtCyINC00Ls=?= =?UTF-8?B?0Y8g0L3QtSDQsNCy0YLQvtGA0LjQt9C+0LLQsNC90L3Ri9GFINC/0L7Qu9GM?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5?= In-Reply-To: References: <50F939D0.1010707@kopeyko.ru> Message-ID: <201301211446.08500.vbart@nginx.com> On Monday 21 January 2013 14:26:30 Руслан Шарипов wrote: > 18 января 2013 г., 18:02 пользователь Andrey Kopeyko написал: > > Добавьте директиву > > > > http://nginx.org/ru/docs/http/**ngx_http_proxy_module.html#** > > proxy_cache_lock > #proxy_cache_lock> > > В приведенном мною конфиге данная директива добавлена, но тем не менее > запросы уходят на apache. Сколько у вас рабочих процессов и какой интервал между запросами? Не выдает ли бэкенд куку на каждый запрос или Cache-Control, Expires? -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon Jan 21 18:14:46 2013 From: nginx-forum at nginx.us (somebi) Date: Mon, 21 Jan 2013 13:14:46 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC40LfQvtCx0YDQsNC20LU=?= =?UTF-8?B?0L3QuNC5INGH0LXRgNC10LcgTmdpbngg0LIgRmxhc2gu?= In-Reply-To: <201301200309.01866.vbart@nginx.com> References: <201301200309.01866.vbart@nginx.com> Message-ID: Спасибо за конструктивный ответ. Был очень занят на днях. Ну да, по сути все так и должно работать, точнее прокси сервер и должен передавать referer в обычных условиях. Видимо поэтому мой самописный сервер сразу стал работать, так как он по сути он скачивает от своего лица, а дальше уже я сам вручную указал отдавать ждущему соединению. Спасибо, извиняюсь за свою не компетентность. :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235263,235383#msg-235383 From nginx-forum at nginx.us Mon Jan 21 18:17:52 2013 From: nginx-forum at nginx.us (somebi) Date: Mon, 21 Jan 2013 13:17:52 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC40LfQvtCx0YDQsNC20LU=?= =?UTF-8?B?0L3QuNC5INGH0LXRgNC10LcgTmdpbngg0LIgRmxhc2gu?= In-Reply-To: References: <201301200309.01866.vbart@nginx.com> Message-ID: <8cabfcd1770cb3efce6d399f7db806a8.NginxMailingListRussian@forum.nginx.org> Просто меня смутило то, что мелкие картинки без проблем проксировались. Видимо для экономии трафика владельцы портала релиши сделать подобную защиту. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235263,235384#msg-235384 From danila at shtan.ru Mon Jan 21 20:38:53 2013 From: danila at shtan.ru (Danila Shtan) Date: Tue, 22 Jan 2013 02:38:53 +0600 Subject: =?UTF-8?B?cHJveHlfY2FjaGUg0LggcmFuZ2Ug0LfQsNC/0YDQvtGB0Ys=?= Message-ID: Приветствую. 1) Для proxy_cache и range есть небольшой патч от Maxim Dounin ( http://forum.nginx.org/read.php?2,225815,225826#msg-225826) который насколько я понимаю не внесен в основную ветку разработки (из-за проблем при max_ranges >1), но в случае применения его решает проблему получения 200 OK при первом запросе к бэкенду и заполнении кэша. Может быть имеет смысл включить такое поведение по умолчанию при max_ranges 1;? Многие современные браузеры в части воспроизведения HTML5 видео сурово завязаны на 206 и правильный Range в ответ на свои запросы, мне кажется, что было бы неплохо учесть существующие реалии. 2) nginx ни за что не отдаст 206 ответ при запросе c Range к закэшированному файлу, если в оригинальном ответе бэкенда не было заголовка Accept-Ranges. Поведение мягко говоря не очевидное, стоило мне нескольких часов попыток понять, что происходит. RFC говорит, что заголовок совершенно опциональный, более того, если nginx уже получил полное тело файла, имеет Content-Length ответа и пр. ? еще более непонятно, что мешает ему отдавать ожидаемые клиентом 206. Данила. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hell-for-yahoo at umail.ru Tue Jan 22 09:22:55 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Tue, 22 Jan 2013 13:22:55 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QstC10LTQtdC90LjQtSBleHBpcmVzINC/0YDQuCDQv9GA0L7QutGB?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: <46a625ddc5ad8a3b9c4b6ac0916bc3c9.NginxMailingListRussian@forum.nginx.org> References: <46a625ddc5ad8a3b9c4b6ac0916bc3c9.NginxMailingListRussian@forum.nginx.org> Message-ID: <487433850.20130122132255@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Trurl! T> тут такая ситуация - сервер выставляет "add_header Cache-Control public" и T> свой expires, T> например получается "Cache-Control: max-age=6048000, public" T> другой сервер Какой "другой сервер"? T> у него таскает данные (proxy_pass) и в некоторых случаях T> выставляет другой expires, и при этом теряется "public" - "Cache-Control: T> max-age=180" T> Это так и задумано или все-таки баг? Либо баг, либо особенность воплощения этого самого другого сервера, что он не воспринимает большие max-age. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) вторник, 22.01.2013, <13:21> From mdounin at mdounin.ru Tue Jan 22 12:06:35 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 22 Jan 2013 16:06:35 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5X2NhY2hlINC4IHJhbmdlINC30LDQv9GA0L7RgdGL?= In-Reply-To: References: Message-ID: <20130122120635.GC9787@mdounin.ru> Hello! On Tue, Jan 22, 2013 at 02:38:53AM +0600, Danila Shtan wrote: > Приветствую. > > 1) Для proxy_cache и range есть небольшой патч от Maxim Dounin ( > http://forum.nginx.org/read.php?2,225815,225826#msg-225826) который > насколько я понимаю не внесен в основную ветку разработки (из-за проблем > при max_ranges >1), но в случае применения его решает проблему получения > 200 OK при первом запросе к бэкенду и заполнении кэша. Может быть имеет > смысл включить такое поведение по умолчанию при max_ranges 1;? Многие > современные браузеры в части воспроизведения HTML5 видео сурово завязаны на > 206 и правильный Range в ответ на свои запросы, мне кажется, что было бы > неплохо учесть существующие реалии. Может быть. Опыт использования патча в production имеется? Если да - хотелось бы услышать отзывы. > 2) nginx ни за что не отдаст 206 ответ при запросе c Range к > закэшированному файлу, если в оригинальном ответе бэкенда не было заголовка > Accept-Ranges. Поведение мягко говоря не очевидное, стоило мне нескольких > часов попыток понять, что происходит. RFC говорит, что заголовок совершенно > опциональный, более того, если nginx уже получил полное тело файла, имеет > Content-Length ответа и пр. ? еще более непонятно, что мешает ему отдавать > ожидаемые клиентом 206. В самом nginx'е допустимость byte-range-запросов однозначно приводит к появлению заголовка Accept-Ranges (а отсутствие оной поддержки - приводит к его отсутствию), и AFAIK в большинстве других серверов так же. Такое поведение - позволяет максимально полно дублировать поведение исходного сервера, допуская range'и только там, где бекенд их поддерживает. Наверное, теперь, когда есть директива max_ranges, и не желающие поддержки range'ей могут от неё отказаться явно, это поведение стоит пересмотреть. -- Maxim Dounin http://nginx.com/support.html From danila at shtan.ru Tue Jan 22 12:40:24 2013 From: danila at shtan.ru (Danila Shtan) Date: Tue, 22 Jan 2013 18:40:24 +0600 Subject: =?UTF-8?B?UmU6IHByb3h5X2NhY2hlINC4IHJhbmdlINC30LDQv9GA0L7RgdGL?= In-Reply-To: <20130122120635.GC9787@mdounin.ru> References: <20130122120635.GC9787@mdounin.ru> Message-ID: Приветствую. 2013/1/22 Maxim Dounin > Hello! > > On Tue, Jan 22, 2013 at 02:38:53AM +0600, Danila Shtan wrote: > > > Приветствую. > > > > 1) Для proxy_cache и range есть небольшой патч от Maxim Dounin ( > > http://forum.nginx.org/read.php?2,225815,225826#msg-225826) который > > насколько я понимаю не внесен в основную ветку разработки (из-за проблем > > при max_ranges >1), но в случае применения его решает проблему получения > > 200 OK при первом запросе к бэкенду и заполнении кэша. Может быть имеет > > смысл включить такое поведение по умолчанию при max_ranges 1;? Многие > > современные браузеры в части воспроизведения HTML5 видео сурово завязаны > на > > 206 и правильный Range в ответ на свои запросы, мне кажется, что было бы > > неплохо учесть существующие реалии. > > Может быть. > > Опыт использования патча в production имеется? Если да - хотелось > бы услышать отзывы. > По вышепомянутой ссылке человек, кажется, доволен. Мы свою сборку с патчем и 3rd-party модулями выкатываем завтра ? через неделю буду готов поделиться впечатлениями. > > 2) nginx ни за что не отдаст 206 ответ при запросе c Range к > > закэшированному файлу, если в оригинальном ответе бэкенда не было > заголовка > > Accept-Ranges. Поведение мягко говоря не очевидное, стоило мне нескольких > > часов попыток понять, что происходит. RFC говорит, что заголовок > совершенно > > опциональный, более того, если nginx уже получил полное тело файла, имеет > > Content-Length ответа и пр. ? еще более непонятно, что мешает ему > отдавать > > ожидаемые клиентом 206. > > В самом nginx'е допустимость byte-range-запросов однозначно > приводит к появлению заголовка Accept-Ranges (а отсутствие оной > поддержки - приводит к его отсутствию), и AFAIK в большинстве > других серверов так же. Такое поведение - позволяет максимально > полно дублировать поведение исходного сервера, допуская range'и > только там, где бекенд их поддерживает. > Там где бэкенд их не поддерживает ему, вероятно, стоит сказать Accept-Ranges: none Проблема в том, что эта особенность сервера не описана вообще нигде. :) Наверное, теперь, когда есть директива max_ranges, и не желающие > поддержки range'ей могут от неё отказаться явно, это поведение > стоит пересмотреть. > По-моему это хорошая идея. Д. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jan 22 12:43:49 2013 From: nginx-forum at nginx.us (shambler81) Date: Tue, 22 Jan 2013 07:43:49 -0500 Subject: =?UTF-8?B?UmU6INC00LLQsCDQv9GA0LDQstC40LvQsCDRgNCw0LHQvtGC0LDRjtGCINC/0L4g?= =?UTF-8?B?0L7RgtC00LXQu9C90L7RgdGC0Lgg0L3QviDQvdC1INCy0LzQtdGB0YLQtQ==?= In-Reply-To: References: Message-ID: Добрый день, сегодня нашел почему именно не отррабатывают правила но try_file насколько я понял в старом nginx не понимают $ фактически проблема была вот в этом location ~* ^.+\.(htm|html)$ { root /var/www/$host/web; if ($host ~* ^(www\.)(.+)) { set $HBW $2; root /var/www/$HBW/web; } try_files $uri /index.php; access_log off; expires 30d; } А следовательно если файл фактически отсутствует то передать его статически из php а в данном локейшене отдается только статика и php попросту не работает Соответственно если я добавлю сюда index index.php index.html index.htm; root /var/www//web/; proxy_pass http://$host:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; То все работает но html больше всегда отдается через php А Мне нужно только если файла нет то отдавать как php и А если есть то просто отдавать статику как и всегда. следовательно я написал следующее условие что при try_files $poteryan отдавать location $poteryan root /var/www//web/; proxy_pass http://$host:82; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; И по идее насколько я понимаю если файл потерян то отдастся все пойдет напрямую без nginx что вполне устроит. фактически такие сайты будут работать без кеширования html Но почему то $potehyan не работает Подскажите пожалуйста почему ? nginx очень старый. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,234927,235407#msg-235407 From postmaster at softsearch.ru Tue Jan 22 15:21:50 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 22 Jan 2013 19:21:50 +0400 Subject: rewrite or internal redirection cycle In-Reply-To: <201301210111.17364.vbart@nginx.com> References: <923476862.20130120231006@softsearch.ru> <201301210111.17364.vbart@nginx.com> Message-ID: <533129071.20130122192150@softsearch.ru> Здравствуйте, Валентин. >> Увидел ошибку: >> >> 2013/01/18 22:30:21 [error] 10601#0: *43370718 rewrite or internal >> redirection cycle while internally redirecting to "/zero", client: >> 46.158.147.140, server: f.beon.ru, request: "GET /beon.ru HTTP/1.1", host: >> "f.beon.ru", referrer: "http://colesnik-2011.ya.ru/" >> >> Судя по конфигу всё нормально. И фавиконка верно отдаётся: >> http://f.beon.ru/beon.ru Не могу придумать как там что зацикливается. В >> каких случаях возникает такая ошибка? > Когда делается более 10 внутренних перенаправлений. Никак не выходит воспроизвести эту ошибку, чтобы глянуть в дебаг-лог. Вот часть конфига, в которой воспроизводится эта ошибка: proxy_set_header Host $host; proxy_next_upstream error timeout invalid_header http_404 http_500 http_502 http_503 http_504; proxy_intercept_errors on; recursive_error_pages on; server { listen 83.222.4.74:80; server_name f.beon.ru; valid_referers none blocked beon.ru *.beon.ru; if ($invalid_referer) { return 403; } error_page 301 302 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 449 500 501 502 503 504 505 506 507 509 510 = /zero; location / { return 204; } location = /zero { return 204; } # aa.ru location ~ "^/(?[a-z0-9-]{1,50}\.[a-z]{2,22})$" { proxy_set_header Host $phost; proxy_set_header Referer "http://$phost/"; proxy_pass http://$phost/favicon.ico; } } Ошибка вроде пропадает, если написать recursive_error_pages off; Но совсем не понятно, где и почему происходит зацикливание. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vovansystems at gmail.com Tue Jan 22 15:40:06 2013 From: vovansystems at gmail.com (VovansystemS) Date: Tue, 22 Jan 2013 18:40:06 +0300 Subject: rewrite or internal redirection cycle In-Reply-To: <533129071.20130122192150@softsearch.ru> References: <923476862.20130120231006@softsearch.ru> <201301210111.17364.vbart@nginx.com> <533129071.20130122192150@softsearch.ru> Message-ID: Здравствуйте, у меня такое впечатление что директива error_page 301 302 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 422 423 424 425 426 449 500 501 502 503 504 505 506 507 509 510 = /zero; и локейшн location = /zero { return 204; } и приводят к зацикливанию при включённой recursive_error_pages on; т.е. если ошибка 204, осуществялется перенаправление на /zero, который возвращает ошибку 204 и так 10 раз. From mdounin at mdounin.ru Tue Jan 22 15:50:15 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 22 Jan 2013 19:50:15 +0400 Subject: rewrite or internal redirection cycle In-Reply-To: <533129071.20130122192150@softsearch.ru> References: <923476862.20130120231006@softsearch.ru> <201301210111.17364.vbart@nginx.com> <533129071.20130122192150@softsearch.ru> Message-ID: <20130122155015.GL9787@mdounin.ru> Hello! On Tue, Jan 22, 2013 at 07:21:50PM +0400, Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> Увидел ошибку: > >> > >> 2013/01/18 22:30:21 [error] 10601#0: *43370718 rewrite or internal > >> redirection cycle while internally redirecting to "/zero", client: > >> 46.158.147.140, server: f.beon.ru, request: "GET /beon.ru HTTP/1.1", host: > >> "f.beon.ru", referrer: "http://colesnik-2011.ya.ru/" > >> > >> Судя по конфигу всё нормально. И фавиконка верно отдаётся: > >> http://f.beon.ru/beon.ru Не могу придумать как там что зацикливается. В > >> каких случаях возникает такая ошибка? > > > Когда делается более 10 внутренних перенаправлений. > > Никак не выходит воспроизвести эту ошибку, чтобы глянуть в дебаг-лог. > Вот часть конфига, в которой воспроизводится эта ошибка: [...] > recursive_error_pages on; > > server { > listen 83.222.4.74:80; > server_name f.beon.ru; > > valid_referers none blocked beon.ru *.beon.ru; > if ($invalid_referer) { > return 403; > } > > error_page 301 302 400 401 402 403 404 405 > 406 407 408 409 410 411 412 413 414 415 416 417 > 422 423 424 425 426 449 500 501 502 503 504 505 > 506 507 509 510 = /zero; Так у тебя в случае invalid referer - "return 403" в цикле. [...] -- Maxim Dounin http://nginx.com/support.html From postmaster at softsearch.ru Tue Jan 22 15:50:16 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 22 Jan 2013 19:50:16 +0400 Subject: rewrite or internal redirection cycle In-Reply-To: References: <923476862.20130120231006@softsearch.ru> <201301210111.17364.vbart@nginx.com> <533129071.20130122192150@softsearch.ru> Message-ID: <1155992964.20130122195016@softsearch.ru> Здравствуйте, VovansystemS. Вы писали 22 января 2013 г., 19:40:06: > Здравствуйте, > у меня такое впечатление что > директива > error_page 301 302 400 401 402 403 404 405 406 407 408 409 410 > 411 412 413 414 415 416 417 422 423 424 425 426 449 500 501 502 503 > 504 505 506 507 509 510 = /zero; > и локейшн > location = /zero { > return 204; > } > и приводят к зацикливанию при включённой recursive_error_pages on; > т.е. если ошибка 204, осуществялется перенаправление на /zero, который > возвращает ошибку 204 и так 10 раз. 204 - это и не ошибка вовсе, а почти тоже самое, что и 200. и в error_page-е 204 не писано. Почему вдруг error_page на 204 среагировал? Не помню, кстати, можно ли уже в error_page задавать коды меньше 300. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Tue Jan 22 16:00:28 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 22 Jan 2013 20:00:28 +0400 Subject: rewrite or internal redirection cycle In-Reply-To: <20130122155015.GL9787@mdounin.ru> References: <923476862.20130120231006@softsearch.ru> <201301210111.17364.vbart@nginx.com> <533129071.20130122192150@softsearch.ru> <20130122155015.GL9787@mdounin.ru> Message-ID: <1995601337.20130122200028@softsearch.ru> Здравствуйте, Maxim. >> >> Увидел ошибку: >> >> >> >> 2013/01/18 22:30:21 [error] 10601#0: *43370718 rewrite or internal >> >> redirection cycle while internally redirecting to "/zero", client: >> >> 46.158.147.140, server: f.beon.ru, request: "GET /beon.ru HTTP/1.1", host: >> >> "f.beon.ru", referrer: "http://colesnik-2011.ya.ru/" >> >> >> >> Судя по конфигу всё нормально. И фавиконка верно отдаётся: >> >> http://f.beon.ru/beon.ru Не могу придумать как там что зацикливается. В >> >> каких случаях возникает такая ошибка? >> >> > Когда делается более 10 внутренних перенаправлений. >> >> Никак не выходит воспроизвести эту ошибку, чтобы глянуть в дебаг-лог. >> Вот часть конфига, в которой воспроизводится эта ошибка: > [...] >> recursive_error_pages on; >> >> server { >> listen 83.222.4.74:80; >> server_name f.beon.ru; >> >> valid_referers none blocked beon.ru *.beon.ru; >> if ($invalid_referer) { >> return 403; >> } >> >> error_page 301 302 400 401 402 403 404 405 >> 406 407 408 409 410 411 412 413 414 415 416 417 >> 422 423 424 425 426 449 500 501 502 503 504 505 >> 506 507 509 510 = /zero; > Так у тебя в случае invalid referer - "return 403" в цикле. Во как. Я думал, что повторная обработка error_page происходит при проксировании, а он при любом смене локейшна! Спасибо, буду знать. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vovansystems at gmail.com Tue Jan 22 16:08:39 2013 From: vovansystems at gmail.com (VovansystemS) Date: Tue, 22 Jan 2013 19:08:39 +0300 Subject: rewrite or internal redirection cycle In-Reply-To: <1155992964.20130122195016@softsearch.ru> References: <923476862.20130120231006@softsearch.ru> <201301210111.17364.vbart@nginx.com> <533129071.20130122192150@softsearch.ru> <1155992964.20130122195016@softsearch.ru> Message-ID: Прошу прощения - невнимательно прочитал прочитал конфиг. Вечер :) Действительно в error_page можно задавать значения только между 300 и 599. Что касается правильного ответа - то в своё время, когда не было возможности изучить логику работы nginx, то придумывал воркэраунды. Кстати где-то совсем недавно видел разбор похожего примера, но ссылки под рукой нет, да и незачем уже :) From postmaster at softsearch.ru Tue Jan 22 18:48:55 2013 From: postmaster at softsearch.ru (=?Windows-1251?B?zOj14OjrIMzu7eD4uOI=?=) Date: Tue, 22 Jan 2013 22:48:55 +0400 Subject: zero size buf in output Message-ID: <844416158.20130122224855@softsearch.ru> Здравствуйте. В логах выпадает вот такое: 2013/01/22 22:29:32 [alert] 68016#0: *4447793 zero size buf in output t:0 r:0 f:0 00000008EF833000 00000008EF833000-00000008EF849399 0000000000000000 0-0 while sending to client, client: 89.222.164.41, server: i99.beon.ru, request: "GET /data.whicdn.com/images/47763159/tumblr_m37casVk2D1ro4xjio1_500_large.gif HTTP/1.1", upstream: "http://93.184.220.125:80/images/47763159/tumblr_m37casVk2D1ro4xjio1_500_large.gif", host: "i99.beon.ru", referrer: "http://inthefootsteps.beon.ru/tag/Benedict%20Cumberbatch/2.html" 2013/01/22 22:30:53 [alert] 68018#0: *4493362 zero size buf in output t:0 r:0 f:0 00000008F01D2000 00000008F01D2000-00000008F01D2A55 0000000000000000 0-0 while sending to client, client: 88.135.86.195, server: i99.beon.ru, request: "GET /s019.radikal.ru/i604/1209/c0/1655940b7494.gif HTTP/1.1", upstream: "http://81.176.238.31:80/i604/1209/c0/1655940b7494.gif", host: "i99.ltalk.ru", referrer: "http://sculptor.ltalk.ru/8.html" 2013/01/22 22:31:40 [alert] 68029#0: *4530373 zero size buf in output t:0 r:0 f:0 00000008EF844000 00000008EF844000-00000008EF85EBBC 0000000000000000 0-0 while sending to client, client: 95.78.244.123, server: i99.beon.ru, request: "GET /static.comicsia.ru/i/8b/48-35656.jpeg HTTP/1.1", upstream: "http://176.9.35.242:80/i/8b/48-35656.jpeg", host: "i99.beon.ru", referrer: "http://angel04.beon.ru/" 2013/01/22 22:32:36 [alert] 68030#0: *4566100 zero size buf in output t:0 r:0 f:0 00000008EF7CE000 00000008EF7CE000-00000008EF7CF000 0000000000000000 0-0 while sending to client, client: 89.222.164.41, server: i99.beon.ru, request: "GET /25.media.tumblr.com/tumblr_m3b4paYiRx1qzioz2o2_250.png HTTP/1.1", upstream: "http://193.159.160.56:80/tumblr_m3b4paYiRx1qzioz2o2_250.png", host: "i99.beon.ru", referrer: "http://inthefootsteps.beon.ru/tag/Benedict%20Cumberbatch/4.html" 2013/01/22 22:33:07 [alert] 68013#0: *4558338 zero size buf in output t:0 r:0 f:0 00000008EF8CB000 00000008EF8CB000-00000008EF8E4F86 0000000000000000 0-0 while sending to client, client: 176.8.113.114, server: i99.beon.ru, request: "GET /imgdepo.ru/id/i1776313 HTTP/1.1", upstream: "http://46.4.122.242:80/id/i1776313", host: "i99.beon.ru", referrer: "http://kartinkoforyou.beon.ru/2.html" Судя по рассылке, это бага какая-то. nginx -V nginx version: nginx/1.3.11 configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module --with-http_stub_status_module --with-pcre с наложенным патчем Максима про proxy_metod. debug-log попробовал писать для всех ip, но не вышло - не хватает процессора. Выглядело в топе всё вот так: 76562 www 1 76 0 3828M 37752K RUN 0 0:08 22.27% nginx 76590 www 1 76 0 3830M 39500K RUN 3 0:07 22.27% nginx 76589 www 1 76 0 3828M 37568K CPU3 7 0:08 22.17% nginx 76578 www 1 76 0 3828M 37412K RUN 6 0:07 22.17% nginx 76576 www 1 76 0 3828M 37536K RUN 0 0:08 22.07% nginx 76565 www 1 76 0 3828M 38012K ksem 3 0:08 22.07% nginx 76571 www 1 76 0 3830M 38916K RUN 2 0:08 22.07% nginx 76579 www 1 76 0 3828M 37876K RUN 1 0:05 22.07% nginx 76563 www 1 76 0 3828M 37584K RUN 6 0:08 21.97% nginx 76564 www 1 76 0 3830M 38540K CPU2 7 0:08 21.97% nginx 76566 www 1 76 0 3828M 37952K RUN 2 0:08 21.97% nginx 76567 www 1 100 0 3828M 37580K CPU2 2 0:08 21.97% nginx 76586 www 1 76 0 3828M 37060K RUN 0 0:05 21.97% nginx 76577 www 1 76 0 3830M 39312K CPU1 4 0:09 21.88% nginx 76588 www 1 76 0 3830M 38536K CPU7 3 0:08 21.88% nginx 76574 www 1 76 0 3830M 39468K RUN 4 0:08 21.88% nginx 76582 www 1 76 0 3828M 37708K RUN 6 0:08 21.88% nginx -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Tue Jan 22 20:16:17 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 23 Jan 2013 00:16:17 +0400 Subject: zero size buf in output In-Reply-To: <844416158.20130122224855@softsearch.ru> References: <844416158.20130122224855@softsearch.ru> Message-ID: <20130122201617.GP9787@mdounin.ru> Hello! On Tue, Jan 22, 2013 at 10:48:55PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > В логах выпадает вот такое: > 2013/01/22 22:29:32 [alert] 68016#0: *4447793 zero size buf in output t:0 r:0 f:0 00000008EF833000 00000008EF833000-00000008EF849399 0000000000000000 0-0 while sending to client, client: 89.222.164.41, server: i99.beon.ru, request: "GET /data.whicdn.com/images/47763159/tumblr_m37casVk2D1ro4xjio1_500_large.gif HTTP/1.1", upstream: "http://93.184.220.125:80/images/47763159/tumblr_m37casVk2D1ro4xjio1_500_large.gif", host: "i99.beon.ru", referrer: "http://inthefootsteps.beon.ru/tag/Benedict%20Cumberbatch/2.html" > 2013/01/22 22:30:53 [alert] 68018#0: *4493362 zero size buf in output t:0 r:0 f:0 00000008F01D2000 00000008F01D2000-00000008F01D2A55 0000000000000000 0-0 while sending to client, client: 88.135.86.195, server: i99.beon.ru, request: "GET /s019.radikal.ru/i604/1209/c0/1655940b7494.gif HTTP/1.1", upstream: "http://81.176.238.31:80/i604/1209/c0/1655940b7494.gif", host: "i99.ltalk.ru", referrer: "http://sculptor.ltalk.ru/8.html" > 2013/01/22 22:31:40 [alert] 68029#0: *4530373 zero size buf in output t:0 r:0 f:0 00000008EF844000 00000008EF844000-00000008EF85EBBC 0000000000000000 0-0 while sending to client, client: 95.78.244.123, server: i99.beon.ru, request: "GET /static.comicsia.ru/i/8b/48-35656.jpeg HTTP/1.1", upstream: "http://176.9.35.242:80/i/8b/48-35656.jpeg", host: "i99.beon.ru", referrer: "http://angel04.beon.ru/" > 2013/01/22 22:32:36 [alert] 68030#0: *4566100 zero size buf in output t:0 r:0 f:0 00000008EF7CE000 00000008EF7CE000-00000008EF7CF000 0000000000000000 0-0 while sending to client, client: 89.222.164.41, server: i99.beon.ru, request: "GET /25.media.tumblr.com/tumblr_m3b4paYiRx1qzioz2o2_250.png HTTP/1.1", upstream: "http://193.159.160.56:80/tumblr_m3b4paYiRx1qzioz2o2_250.png", host: "i99.beon.ru", referrer: "http://inthefootsteps.beon.ru/tag/Benedict%20Cumberbatch/4.html" > 2013/01/22 22:33:07 [alert] 68013#0: *4558338 zero size buf in output t:0 r:0 f:0 00000008EF8CB000 00000008EF8CB000-00000008EF8E4F86 0000000000000000 0-0 while sending to client, client: 176.8.113.114, server: i99.beon.ru, request: "GET /imgdepo.ru/id/i1776313 HTTP/1.1", upstream: "http://46.4.122.242:80/id/i1776313", host: "i99.beon.ru", referrer: "http://kartinkoforyou.beon.ru/2.html" > > Судя по рассылке, это бага какая-то. > > nginx -V > nginx version: nginx/1.3.11 > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module --with-http_stub_status_module --with-pcre > > с наложенным патчем Максима про proxy_metod. > > debug-log попробовал писать для всех ip, но не вышло - не хватает > процессора. Выглядело в топе всё вот так: > 76562 www 1 76 0 3828M 37752K RUN 0 0:08 22.27% nginx > 76590 www 1 76 0 3830M 39500K RUN 3 0:07 22.27% nginx > 76589 www 1 76 0 3828M 37568K CPU3 7 0:08 22.17% nginx [...] Полный debug log - это может быть дорого при большой нагрузке, поэтому сущетсвует возможность логгировать только то, что нужно (или 1/N часть интернета, где N - достаточно большое число, чтобы сервер справлялся). См. http://nginx.org/r/debug_connection. Что до самой ошибки, то подозреваю, что у тебя вариации на тему вот этого: http://mailman.nginx.org/pipermail/nginx/2012-October/035799.html И ещё вероятно отягчённые каким-нибудь image фильтром. -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Wed Jan 23 07:10:58 2013 From: nginx-forum at nginx.us (billi) Date: Wed, 23 Jan 2013 02:10:58 -0500 Subject: =?UTF-8?B?0L/QvtC80L7RidGMINC/0L4g0LzQvtC00YPQu9GOIG5neCBzZXQgbWlzYw==?= Message-ID: Доброго всем времени. Нужна помощь зала по данному модулю. с nginx столкнулся впервые ,прошу сильно ногами не пинать. Приходит вот такой запрос :" http://muk1.myhost.ru/stream?url=http%3A%2F%2Ffs82.myhost.ru%3A8080%2F107%2F146%2F945042.mp4%3Fsig%3D49bff025d158f87fb40aa62e71c63443%26d%3D12" модуль его расшифровывает до "http://fs82.myhost.ru:8080/104/99/945042.mp4?sig=74585305d846063b6484d492a8c6605a&d=17" как заставить его отрезать все лишнее после mp4 . вот кусок конфига : location /stream { set_unescape_uri $new_uri $arg_url; proxy_pass $new_uri; proxy_cache_key "$new_uri"; proxy_cache stream_cache; proxy_cache_lock on; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235442,235442#msg-235442 From bdfy at mail.ru Wed Jan 23 08:18:37 2013 From: bdfy at mail.ru (=?UTF-8?B?SXZhbg==?=) Date: Wed, 23 Jan 2013 12:18:37 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0YnRjCDQv9C+INC80L7QtNGD0LvRjiBuZ3ggc2V0IG1pc2M=?= In-Reply-To: References: Message-ID: <1358929117.894005455@f285.mail.ru> использовать встроенный перл или lua. Среда, 23 января 2013, 2:10 -05:00 от "billi" : >Доброго всем времени. Нужна помощь зала по данному модулю. с nginx >столкнулся впервые ,прошу сильно ногами не пинать. >Приходит вот такой запрос :" >http://muk1.myhost.ru/stream?url=http%3A%2F%2Ffs82.myhost.ru%3A8080%2F107%2F146%2F945042.mp4%3Fsig%3D49bff025d158f87fb40aa62e71c63443%26d%3D12" > модуль его расшифровывает до >" http://fs82.myhost.ru:8080/104/99/945042.mp4?sig=74585305d846063b6484d492a8c6605a&d=17 " > как заставить его отрезать все лишнее после mp4 . >вот кусок конфига : >        location /stream { >             set_unescape_uri $new_uri $arg_url; >             proxy_pass $new_uri; >             proxy_cache_key "$new_uri"; >             proxy_cache stream_cache; >             proxy_cache_lock on; >        } > >Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235442,235442#msg-235442 > >_______________________________________________ >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 23 08:28:26 2013 From: nginx-forum at nginx.us (billi) Date: Wed, 23 Jan 2013 03:28:26 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0YnRjCDQv9C+INC80L7QtNGD0LvRjiBuZ3ggc2V0IG1pc2M=?= In-Reply-To: <1358929117.894005455@f285.mail.ru> References: <1358929117.894005455@f285.mail.ru> Message-ID: <4241e702885ae6d5dd7fb18cf67e23e7.NginxMailingListRussian@forum.nginx.org> по lua можно подробнее ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235445,235446#msg-235446 From bdfy at mail.ru Wed Jan 23 09:50:23 2013 From: bdfy at mail.ru (=?UTF-8?B?SXZhbg==?=) Date: Wed, 23 Jan 2013 13:50:23 +0400 Subject: =?UTF-8?B?UmVbMl06INC/0L7QvNC+0YnRjCDQv9C+INC80L7QtNGD0LvRjiBuZ3ggc2V0IG1p?= =?UTF-8?B?c2M=?= In-Reply-To: <4241e702885ae6d5dd7fb18cf67e23e7.NginxMailingListRussian@forum.nginx.org> References: <1358929117.894005455@f285.mail.ru> <4241e702885ae6d5dd7fb18cf67e23e7.NginxMailingListRussian@forum.nginx.org> Message-ID: <1358934623.815310497@f378.i.mail.ru> на той же странице где вы и нашли set_misc модуль: http://wiki.nginx.org/3rdPartyModules Среда, 23 января 2013, 3:28 -05:00 от "billi" : >по lua можно подробнее ? > >Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235445,235446#msg-235446 > >_______________________________________________ >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 23 11:06:06 2013 From: nginx-forum at nginx.us (billi) Date: Wed, 23 Jan 2013 06:06:06 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0YnRjCDQv9C+INC80L7QtNGD0LvRjiBuZ3ggc2V0IG1pc2M=?= In-Reply-To: <1358929117.894005455@f285.mail.ru> References: <1358929117.894005455@f285.mail.ru> Message-ID: ок погляжу. и еще небольшой вопрос. приходит запрос " "GET /116/24/947224.mp4?async_server_url=http%3a%..." в логах получаю ошибку " [error] 22732#0: *271 invalid URL prefix in ""," поправил конфиг - set_unescape_uri $new_uri $arg_url; + set_unescape_uri $new_uri $arg_async_server_url; но все равно ошибка валиться. получается что url с подчеркиванием не понимает. нужен чистый url. ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235445,235449#msg-235449 From nginx-forum at nginx.us Thu Jan 24 09:07:53 2013 From: nginx-forum at nginx.us (Shreck) Date: Thu, 24 Jan 2013 04:07:53 -0500 Subject: =?UTF-8?B?0JfQsNC60YDRi9GC0LjQtSDQv9C+IElQINC00LvRjyDRgNCw0LfQvdGL0YUg0YU=?= =?UTF-8?B?0L7RgdGC0L7Qsg==?= Message-ID: Хочу закрыть разные хосты на 1 сервере по ip, хочется сделать это лаконично и красиво, поэтому в голову пришла такая идея: а блок http: geo $geo { 192.168.0.2 example.com; } map $host $deny { default 1; $geo 0; } Ну и уже в location: if ($deny) { return $deny; } Но не работает, не пускает никого, что я делаю не так? Заранее спасибо за помощь! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235527,235527#msg-235527 From slava at auto.ru Thu Jan 24 09:15:40 2013 From: slava at auto.ru (Viatcheslav E. Kouznetsov) Date: Thu, 24 Jan 2013 13:15:40 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0L/QviBJUCDQtNC70Y8g0YDQsNC30L3Ri9GF?= =?UTF-8?B?INGF0L7RgdGC0L7Qsg==?= In-Reply-To: References: Message-ID: <20130124131540.1027259a@darkstar.auto> On Thu, 24 Jan 2013 04:07:53 -0500 "Shreck" wrote: > Хочу закрыть разные хосты на 1 сервере по ip, хочется сделать это > лаконично и красиво, поэтому в голову пришла такая идея: > а блок http: > > geo $geo { > 192.168.0.2 example.com; > } > > map $host $deny { > default 1; > $geo 0; > } > > Ну и уже в location: > if ($deny) { > return $deny; > } > > Но не работает, не пускает никого, что я делаю не так? > Заранее спасибо за помощь! Не совсем понял зачем тут map geo $var_deny { default 0; 192.168.0.2 1; } и в server { if ($var_deny) { return 403; } } > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235527,235527#msg-235527 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Вячеслав Кузнецов ООО "АВТО.РУ Холдинг" тел. +7.499.730.8730 (#456) From nginx-forum at nginx.us Thu Jan 24 09:18:35 2013 From: nginx-forum at nginx.us (Shreck) Date: Thu, 24 Jan 2013 04:18:35 -0500 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0L/QviBJUCDQtNC70Y8g0YDQsNC30L3Ri9GF?= =?UTF-8?B?INGF0L7RgdGC0L7Qsg==?= In-Reply-To: <20130124131540.1027259a@darkstar.auto> References: <20130124131540.1027259a@darkstar.auto> Message-ID: 1 server обрабатывает разные хосты *.example.com и фильтрация по ip нужна для каждого хоста отдельно? хочется разрешения такого вида 192.168.0.1 one.example.com 192.168.0.2 two.example.com Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235527,235529#msg-235529 From postmaster at softsearch.ru Thu Jan 24 17:39:44 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 24 Jan 2013 21:39:44 +0400 Subject: =?UTF-8?B?aW1hZ2VfZmlsdGVyINC4INC/0YPRgdGC0YvQtSDQv9C10YDQtdC80LXQvdC90Ys=?= =?UTF-8?B?0LUu?= Message-ID: <1168508631.20130124213944@softsearch.ru> Здравствуйте. Если сейчас в качестве ширины будет пустая переменная, то image_filter resize ширина "-"; не выдаёт изображений вообще. Хотя вроде бы пустая переменная должна отключать директву, в которой она используется, если я правильно ранее понял линию партии. Воспроизводится вот так: map $arg_width $image_width { 100 100; } location / { image_filter resize $image_width "-"; } Если же добавить в map строчку default "-"; то работает правильно (ресайза не происходит вообще). -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Thu Jan 24 18:11:18 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 24 Jan 2013 22:11:18 +0400 Subject: =?UTF-8?B?UmU6IGltYWdlX2ZpbHRlciDQuCDQv9GD0YHRgtGL0LUg0L/QtdGA0LXQvNC10L0=?= =?UTF-8?B?0L3Ri9C1Lg==?= In-Reply-To: <1168508631.20130124213944@softsearch.ru> References: <1168508631.20130124213944@softsearch.ru> Message-ID: <20130124181118.GB40753@mdounin.ru> Hello! On Thu, Jan 24, 2013 at 09:39:44PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Если сейчас в качестве ширины будет пустая переменная, то > image_filter resize ширина "-"; > не выдаёт изображений вообще. Хотя вроде бы пустая переменная должна > отключать директву, в которой она используется, если я правильно ранее > понял линию партии. Нет, ты неправильно понял. Пустое значение является специальным только там, где оно является специальным. E.g. если ты используешь пустую пременную в строке замены какого-нибудь sub_filter'а - ничего не отключится, будет замена на пустую строку. > Воспроизводится вот так: > map $arg_width $image_width { > 100 100; > } > > location / { > image_filter resize $image_width "-"; > } > > Если же добавить в map строчку > default "-"; > то работает правильно (ресайза не происходит вообще). Директива image_filter через переменные понимает ровно то, что она понимает в качестве параметров без переменных. В остальных случаях возвращается ошибка 415. -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Fri Jan 25 06:44:41 2013 From: nginx-forum at nginx.us (billi) Date: Fri, 25 Jan 2013 01:44:41 -0500 Subject: =?UTF-8?B?0LLQvtC/0YDQvtGBINC/0L4gbWFw?= Message-ID: <7f6881b2affa78c53298317341b3dbf9.NginxMailingListRussian@forum.nginx.org> Всем доброго времени. не могу разобраться почему неверно пишется кеу приходит вот такой запрос : http://myhost.ru/stream?async_server_url=http%3A%2F%2Ffs82.myhost.ru%3A8080%2F107%2F146%2F945042.mp4%3Fsig%3D49bff025d158f87fb40aa62e71c63443%26d%3D12 с помощью "set_unescape_uri $new_uri $arg_async_server_url;" ее расшифровываем до вида "http://fs82.myhost.ru:8080/104/99/945042.mp4?sig=74585305d846063b6484d492a8c6605a&d=17" пропускаем через map " map $new_uri $cache_key { ~ (^[^?]*); } " и все равно в итоге получаем key "http://fs82.myhost.ru:8080/104/99/945042.mp4?sig=74585305d846063b6484d492a8c6605a&d=17" регулярка имхо написано верно. proxy_cache_key "$new_uri"; -прописан в локейшене. подскажите знающие люди почему key пишется без обработки регулярки Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235565,235565#msg-235565 From postmaster at softsearch.ru Fri Jan 25 09:17:40 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 25 Jan 2013 13:17:40 +0400 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQv9C+IG1hcA==?= In-Reply-To: <7f6881b2affa78c53298317341b3dbf9.NginxMailingListRussian@forum.nginx.org> References: <7f6881b2affa78c53298317341b3dbf9.NginxMailingListRussian@forum.nginx.org> Message-ID: <1433873208.20130125131740@softsearch.ru> Здравствуйте, billi. > ~ (^[^?]*); Попробуйте вот так: ~^(?[^?]+) $key; -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sat Jan 26 13:42:10 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 26 Jan 2013 17:42:10 +0400 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC4INCv0L3QtNC10LrRgS3QotGD0YDQsdC+?= Message-ID: <16410348687.20130126174210@softsearch.ru> Здравствуйте. Яндекс-браузер как и Опера-мини использует свои прокси. Рекальный заголовок отправляется так же в X-Forwarded-For . Также отправляется заголовок X-Yandex-Turbo: yes по которому можно в будущем искать новые подсети с их проксями. У себя в логах пока нашёл следующие их ip-шки: 5.45.192.66 trbo02d.trbo.yandex.net. 5.45.192.67 trbo03d.trbo.yandex.net. 5.45.192.68 trbo04d.trbo.yandex.net. 5.45.192.69 trbo05d.trbo.yandex.net. 5.45.192.70 trbo06d.trbo.yandex.net. 5.45.192.71 trbo07d.trbo.yandex.net. 5.45.192.73 trbo09d.trbo.yandex.net. 5.45.192.74 trbo10d.trbo.yandex.net. 5.45.192.75 trbo11d.trbo.yandex.net. 5.45.192.76 trbo12d.trbo.yandex.net. 5.45.192.77 trbo13d.trbo.yandex.net. 5.45.192.78 trbo14d.trbo.yandex.net. 5.45.192.79 trbo15d.trbo.yandex.net. 5.45.192.80 trbo16d.trbo.yandex.net. 5.45.192.81 trbo17d.trbo.yandex.net. 5.45.192.82 trbo18d.trbo.yandex.net. 5.45.192.85 trbo21d.trbo.yandex.net. 5.45.192.86 trbo22d.trbo.yandex.net. 5.45.192.87 trbo23d.trbo.yandex.net. 5.45.192.89 trbo25d.trbo.yandex.net. Видимо можно писать в конфигах set_real_ip_from 5.45.192.64/26; -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sat Jan 26 13:47:50 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 26 Jan 2013 17:47:50 +0400 Subject: =?UTF-8?B?0L/RgNC+0LLQtdGA0LrQsCDQvdCwINC/0YPRgdGC0YPRjiDRgdGC0YDQvtC60YMg?= =?UTF-8?B?0LIgbWFw?= Message-ID: <1758635778.20130126174750@softsearch.ru> Здравствуйте. Как в map проверить, что значение переменной не пустая строка? Только через регэксп map $a $b { default 0; "~." 1; } или есть способы эффективнее? -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Sat Jan 26 15:06:17 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 26 Jan 2013 19:06:17 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCy0LXRgNC60LAg0L3QsCDQv9GD0YHRgtGD0Y4g0YHRgtGA0L4=?= =?UTF-8?B?0LrRgyDQsiBtYXA=?= In-Reply-To: <1758635778.20130126174750@softsearch.ru> References: <1758635778.20130126174750@softsearch.ru> Message-ID: <201301261906.17459.vbart@nginx.com> On Saturday 26 January 2013 17:47:50 Михаил Монашёв wrote: > Здравствуйте. > > Как в map проверить, что значение переменной не пустая строка? Только > через регэксп > > map $a $b { > default 0; > "~." 1; > } > > или есть способы эффективнее? map $a $b { default 1; "" 0; } -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From postmaster at softsearch.ru Sat Jan 26 15:39:34 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 26 Jan 2013 19:39:34 +0400 Subject: =?UTF-8?B?UmVbMl06INC/0YDQvtCy0LXRgNC60LAg0L3QsCDQv9GD0YHRgtGD0Y4g0YHRgtGA?= =?UTF-8?B?0L7QutGDINCyIG1hcA==?= In-Reply-To: <201301261906.17459.vbart@nginx.com> References: <1758635778.20130126174750@softsearch.ru> <201301261906.17459.vbart@nginx.com> Message-ID: <1611012108.20130126193934@softsearch.ru> Здравствуйте, Валентин. >> Как в map проверить, что значение переменной не пустая строка? Только >> через регэксп >> >> map $a $b { >> default 0; >> "~." 1; >> } >> >> или есть способы эффективнее? > map $a $b { > default 1; > "" 0; > } Спасибо. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sat Jan 26 15:54:15 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 26 Jan 2013 19:54:15 +0400 Subject: =?UTF-8?B?UmVbMl06IGltYWdlX2ZpbHRlciDQuCDQv9GD0YHRgtGL0LUg0L/QtdGA0LXQvNC1?= =?UTF-8?B?0L3QvdGL0LUu?= In-Reply-To: <20130124181118.GB40753@mdounin.ru> References: <1168508631.20130124213944@softsearch.ru> <20130124181118.GB40753@mdounin.ru> Message-ID: <352376875.20130126195415@softsearch.ru> Здравствуйте, Maxim. >> Если сейчас в качестве ширины будет пустая переменная, то >> image_filter resize ширина "-"; >> не выдаёт изображений вообще. Хотя вроде бы пустая переменная должна >> отключать директву, в которой она используется, если я правильно ранее >> понял линию партии. > Нет, ты неправильно понял. Пустое значение является специальным > только там, где оно является специальным. > E.g. если ты используешь пустую пременную в строке замены > какого-нибудь sub_filter'а - ничего не отключится, будет замена на > пустую строку. >> Воспроизводится вот так: >> map $arg_width $image_width { >> 100 100; >> } >> >> location / { >> image_filter resize $image_width "-"; >> } >> >> Если же добавить в map строчку >> default "-"; >> то работает правильно (ресайза не происходит вообще). > Директива image_filter через переменные понимает ровно то, что она > понимает в качестве параметров без переменных. В остальных > случаях возвращается ошибка 415. Сейчас директива image_filter resize "-" "-"; приводит к тому, что файл записывается в image_filter_buffer и если его не хватает, то выдаётся 415? Хотя вроде бы вообще ничего не должно происходить, а на практике работает как image_filter test; Можно как-то отключить ресайз в зависимости от значения переменной? А то если в $image_width содержится "-", то директива image_filter resize $image_width "-"; приводит к тому, что имэдж-фильтр всёравно картики через себя пропускает, хотя мог бы напрямую отдавать никак их не касаясь. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Sun Jan 27 07:45:21 2013 From: nginx-forum at nginx.us (teo) Date: Sun, 27 Jan 2013 02:45:21 -0500 Subject: nginx as reverse proxy for weblogic Message-ID: <3eeba435c46c2909543810b9b27f0580.NginxMailingListRussian@forum.nginx.org> Была мысль заменить связку apache+ webllogic-plugin на nginx. Но сколько раз не пробовал - все равно родной плагин работает лучше. Неужели nginx за столько времени не додумался до того, что 10 лет назад сделали в BEA? Сейчас я пробую вот такую конфигурацию upstream web_backend { ip_hash; least_conn; server 192.168.2.11:7001; server 192.168.2.12:7001; server 192.168.2.13:7001; } location / { proxy_pass http://web_backend; proxy_http_version 1.1; proxy_set_header WL-Proxy-Client-IP $remote_addr; proxy_set_header Proxy-Client-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_read_timeout 600; proxy_send_timeout 1; } Результат - да, все работает только до определенного момента (секунд этак 30). Видно что все запросы валятся на один инстанс weblogic, забивают все его очереди и в результате все висит. Т.е. почему нет заявленного round-robin и когда nginx решит переключиться на другой инстанс - не известно. Впрочем я конечно не уверен что все происходит именно так, но факты такие - через некоторое время консоль управления подвисает - это происходит обычно тогда, когда один из инстансов тупо не отвечает ни на какие запросы. Далее nodeManager, видя что его инстанс не отвечает - валит его и запускает вновь. Если консоль все-таки ответила, то видно что кол-во конектов на этих 3х инстансах распределено примерно так 10+1200+10. Почему же этого не происходит при родном плагине? Во 1х плагин постоянно тестирует инстансы, посылая запрос на несуществующую страничку и при этом его цель не получить какой-то конкретный ответ, а просто увидеть что инстанс жив, даже если это ответ 404. И заодно оценить насколько тот занят - если задержка велика - значит надо выбрать другой. А тестировать инстанс пришедшим запросом - а вдруг это поисковый запрос, который требует много ресурсов и ответ будет долгим? Кстати в параметрах настройки плагина нет таймаутов - т.е. если вы будете вытаскивать 20гиговый файл, то вас не срубят на 10й минуте. Во 2х, он добавляет куки в ответ инстанса, с тем, чтобы знать на каком конкретно сервере исполнялся предыдущий запрос. При этом никакие циски с NAT и диапазоном IP адресов уже не страшны (это когда каждый конект идет через другой адрес) - он заботится о том, чтобы инстансу было легче доставать сессию клиента. В 3х плагин поддерживает keep_alive со стороны инстанса. Так может все-таки добавить такие фичи в ngx_http_proxy_module? Или я что-то пропустил и кто-то знает решение с имеющимся функционалом? Версии в которых это пробовал я - 1.0.15 из epel и 1.2.6. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235603,235603#msg-235603 From nginx-forum at nginx.us Sun Jan 27 08:11:15 2013 From: nginx-forum at nginx.us (teo) Date: Sun, 27 Jan 2013 03:11:15 -0500 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0L/QviBJUCDQtNC70Y8g0YDQsNC30L3Ri9GF?= =?UTF-8?B?INGF0L7RgdGC0L7Qsg==?= In-Reply-To: References: <20130124131540.1027259a@darkstar.auto> Message-ID: <07d87f6237c9b6aed69049d01a0e7e5b.NginxMailingListRussian@forum.nginx.org> > 192.168.0.1 one.example.com > 192.168.0.2 two.example.com А что у вас это означает? То, что 192.168.0.1 может ходить только на one.example.com? Ну тогда нужно в location if ( $geo != $host ) { return 403; } Ну или != поменять на = если "не должен ходить" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235527,235605#msg-235605 From chipitsine at gmail.com Sun Jan 27 10:08:19 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sun, 27 Jan 2013 15:08:19 +0500 Subject: nginx as reverse proxy for weblogic In-Reply-To: <3eeba435c46c2909543810b9b27f0580.NginxMailingListRussian@forum.nginx.org> References: <3eeba435c46c2909543810b9b27f0580.NginxMailingListRussian@forum.nginx.org> Message-ID: если apache+weblogic-plugin вас устраивает, используйте его. 27 января 2013 г., 13:45 пользователь teo написал: > Была мысль заменить связку apache+ webllogic-plugin на nginx. Но сколько > раз > не пробовал - все равно родной плагин работает лучше. > Неужели nginx за столько времени не додумался до того, что 10 лет назад > сделали в BEA? > > Сейчас я пробую вот такую конфигурацию > > upstream web_backend { > ip_hash; > least_conn; > server 192.168.2.11:7001; > server 192.168.2.12:7001; > server 192.168.2.13:7001; > } > > location / { > proxy_pass http://web_backend; > proxy_http_version 1.1; > proxy_set_header WL-Proxy-Client-IP $remote_addr; > proxy_set_header Proxy-Client-IP $remote_addr; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_read_timeout 600; > proxy_send_timeout 1; > } > > Результат - да, все работает только до определенного момента (секунд этак > 30). Видно что все запросы валятся на один инстанс weblogic, забивают все > его очереди и в результате все висит. > Т.е. почему нет заявленного round-robin и когда nginx решит переключиться > на > другой инстанс - не известно. > Впрочем я конечно не уверен что все происходит именно так, но факты такие - > через некоторое время консоль управления подвисает - это происходит обычно > тогда, когда один из инстансов тупо не отвечает ни на какие запросы. Далее > nodeManager, видя что его инстанс не отвечает - валит его и запускает > вновь. > Если консоль все-таки ответила, то видно что кол-во конектов на этих 3х > инстансах распределено примерно так 10+1200+10. > > Почему же этого не происходит при родном плагине? > Во 1х плагин постоянно тестирует инстансы, посылая запрос на несуществующую > страничку и при этом его цель не получить какой-то конкретный ответ, а > просто увидеть что инстанс жив, даже если это ответ 404. И заодно оценить > насколько тот занят - если задержка велика - значит надо выбрать другой. > А тестировать инстанс пришедшим запросом - а вдруг это поисковый запрос, > который требует много ресурсов и ответ будет долгим? > Кстати в параметрах настройки плагина нет таймаутов - т.е. если вы будете > вытаскивать 20гиговый файл, то вас не срубят на 10й минуте. > Во 2х, он добавляет куки в ответ инстанса, с тем, чтобы знать на каком > конкретно сервере исполнялся предыдущий запрос. > При этом никакие циски с NAT и диапазоном IP адресов уже не страшны (это > когда каждый конект идет через другой адрес) - он заботится о том, чтобы > инстансу было легче доставать сессию клиента. > В 3х плагин поддерживает keep_alive со стороны инстанса. > > Так может все-таки добавить такие фичи в ngx_http_proxy_module? > Или я что-то пропустил и кто-то знает решение с имеющимся функционалом? > Версии в которых это пробовал я - 1.0.15 из epel и 1.2.6. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235603,235603#msg-235603 > > _______________________________________________ > 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 postmaster at softsearch.ru Sun Jan 27 11:43:08 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 27 Jan 2013 15:43:08 +0400 Subject: =?UTF-8?B?UmVbM106IGltYWdlX2ZpbHRlciDQuCDQv9GD0YHRgtGL0LUg0L/QtdGA0LXQvNC1?= =?UTF-8?B?0L3QvdGL0LUu?= In-Reply-To: <352376875.20130126195415@softsearch.ru> References: <1168508631.20130124213944@softsearch.ru> <20130124181118.GB40753@mdounin.ru> <352376875.20130126195415@softsearch.ru> Message-ID: <1437180687.20130127154308@softsearch.ru> Здравствуйте. Вдогонку... Посмотрел debug-лог. Так и есть. Смотрится, что за формат изображения, вытаскиваются размеры изображения... Как это отключить в зависимости от значения переменной? -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Sun Jan 27 13:38:35 2013 From: nginx-forum at nginx.us (teo) Date: Sun, 27 Jan 2013 08:38:35 -0500 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: Илья Шипицин Wrote: ------------------------------------------------------- > если apache+weblogic-plugin вас устраивает, используйте его. В данном случае у nginx легко настроить блокировку доступа с некоторых ботов. В случае с апачем - думаю мы поимеем проблемы, если будем подсовывать типа SetEnvIf X-Forwarded-For 127.0.0.1 blacklisted=1 SetEnvIf X-Forwarded-For unknown blacklisted=1 SetEnvIf REMOTE_ADDR 137.236.178.63 blacklisted=1 и т.д. RewriteCond %{ENV:blacklisted} ^1$ [NC] Если кол-во правил будет зашкаливать за сотню - nginx же справляется и с большим кол-вом "ограничений" А установка nginx перед апачем - полностью ломает логирование исходного IP клиента. Установка после - непонятно насколько будет надежно определение исходного IP, если клиент решит добавить собственные заголовки, по которому weblogic определяет исходный ip Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235603,235611#msg-235611 From vbart at nginx.com Sun Jan 27 13:58:06 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 27 Jan 2013 17:58:06 +0400 Subject: nginx as reverse proxy for weblogic In-Reply-To: <3eeba435c46c2909543810b9b27f0580.NginxMailingListRussian@forum.nginx.org> References: <3eeba435c46c2909543810b9b27f0580.NginxMailingListRussian@forum.nginx.org> Message-ID: <201301271758.06478.vbart@nginx.com> On Sunday 27 January 2013 11:45:21 teo wrote: > Была мысль заменить связку apache+ webllogic-plugin на nginx. Но сколько > раз не пробовал - все равно родной плагин работает лучше. > Неужели nginx за столько времени не додумался до того, что 10 лет назад > сделали в BEA? > > Сейчас я пробую вот такую конфигурацию > > upstream web_backend { > ip_hash; > least_conn; > server 192.168.2.11:7001; > server 192.168.2.12:7001; > server 192.168.2.13:7001; > } > > location / { > proxy_pass http://web_backend; > proxy_http_version 1.1; > proxy_set_header WL-Proxy-Client-IP $remote_addr; > proxy_set_header Proxy-Client-IP $remote_addr; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_read_timeout 600; > proxy_send_timeout 1; > } > > Результат - да, все работает только до определенного момента (секунд этак > 30). Видно что все запросы валятся на один инстанс weblogic, забивают все > его очереди и в результате все висит. > Т.е. почему нет заявленного round-robin и когда nginx решит переключиться > на другой инстанс - не известно. Вы его выключили указав ip_hash. > Впрочем я конечно не уверен что все происходит именно так, но факты такие - > через некоторое время консоль управления подвисает - это происходит обычно > тогда, когда один из инстансов тупо не отвечает ни на какие запросы. Далее > nodeManager, видя что его инстанс не отвечает - валит его и запускает > вновь. > Если консоль все-таки ответила, то видно что кол-во конектов на этих 3х > инстансах распределено примерно так 10+1200+10. > > Почему же этого не происходит при родном плагине? > Во 1х плагин постоянно тестирует инстансы, посылая запрос на несуществующую > страничку и при этом его цель не получить какой-то конкретный ответ, а > просто увидеть что инстанс жив, даже если это ответ 404. И заодно оценить > насколько тот занят - если задержка велика - значит надо выбрать другой. > А тестировать инстанс пришедшим запросом - а вдруг это поисковый запрос, > который требует много ресурсов и ответ будет долгим? Распространенная ситуация - интервал поступления запросов меньше интервала ответа, в этом случае любые дополнительные запросы "для тестирования" только создают дополнительную нагрузку, не принося никакой пользы. > Кстати в параметрах настройки плагина нет таймаутов - т.е. если вы будете > вытаскивать 20гиговый файл, то вас не срубят на 10й минуте. nginx тоже не срубят, если файл действительно будет "вытаскиваться", а не 10 минут висеть. Обратите внимание, многие таймауты задаются на интервалы между двумя последовательными операциями, а не на весь ответ целиком. > Во 2х, он добавляет куки в ответ инстанса, с тем, чтобы знать на каком > конкретно сервере исполнялся предыдущий запрос. > При этом никакие циски с NAT и диапазоном IP адресов уже не страшны (это > когда каждый конект идет через другой адрес) - он заботится о том, чтобы > инстансу было легче доставать сессию клиента. Это другой метод балансировки, который на данный момент не доступен в бесплатной версии nginx. > В 3х плагин поддерживает keep_alive со стороны инстанса. > Nginx поддерживает keepalive начиная с версии 1.1.4. http://nginx.org/r/keepalive/ru > Так может все-таки добавить такие фичи в ngx_http_proxy_module? > Или я что-то пропустил и кто-то знает решение с имеющимся функционалом? > Версии в которых это пробовал я - 1.0.15 из epel и 1.2.6. > -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From nefer05 at gmail.com Sun Jan 27 14:39:34 2013 From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Sun, 27 Jan 2013 17:39:34 +0300 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: А что мешает блочить фаерволом? Самый легких способ, с точки зрения нагрузки. 2013/1/27 teo > Илья Шипицин Wrote: > ------------------------------------------------------- > > если apache+weblogic-plugin вас устраивает, используйте его. > > В данном случае у nginx легко настроить блокировку доступа с некоторых > ботов. > В случае с апачем - думаю мы поимеем проблемы, если будем подсовывать типа > > SetEnvIf X-Forwarded-For 127.0.0.1 blacklisted=1 > SetEnvIf X-Forwarded-For unknown blacklisted=1 > SetEnvIf REMOTE_ADDR 137.236.178.63 blacklisted=1 > и т.д. > RewriteCond %{ENV:blacklisted} ^1$ [NC] > > Если кол-во правил будет зашкаливать за сотню - nginx же справляется и с > большим кол-вом "ограничений" > А установка nginx перед апачем - полностью ломает логирование исходного IP > клиента. > Установка после - непонятно насколько будет надежно определение исходного > IP, если клиент решит добавить собственные заголовки, по которому weblogic > определяет исходный ip > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235603,235611#msg-235611 > > _______________________________________________ > 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 Sun Jan 27 15:03:53 2013 From: nginx-forum at nginx.us (teo) Date: Sun, 27 Jan 2013 10:03:53 -0500 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: Роман Москвитин Wrote: ------------------------------------------------------- > А что мешает блочить фаерволом? Самый легких способ, с точки зрения > нагрузки. Если кол-во правил не большое - то да. Если их переваливает за 3000, то перед тем как исходный пакет попадет на входящий порт на который вы поставили ACCEPT, он должен пробежать ваши 3000 правил. При этом каждый новый пакет должен сделать тоже самое. В результате вы получаете некоторый трабл с неизвестными корнями - бекенды простаивают, цпу при этом не сказать чтобы нагружен, все кого-то "ждут", входная очередь переполнена. Ну да, есть вообще-то ipset. Но кто сказал при каких кол-вах правил это все еще будет работать? Лучше уж иметь небольшой лаг на обработке одного входящего соединения на 80й порт, пока nginx или ваш фронтенд не пробежится по вашим правилам блокировки. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235603,235615#msg-235615 From vadim.lazovskiy at gmail.com Sun Jan 27 16:29:50 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Sun, 27 Jan 2013 20:29:50 +0400 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: Здравствуйте. Если кол-во правил не большое - то да. > Если их переваливает за 3000, то перед тем как исходный пакет попадет на > входящий порт на который вы поставили ACCEPT, он должен пробежать ваши 3000 > правил. > Stateful firewall > При этом каждый новый пакет должен сделать тоже самое. В результате вы > получаете некоторый трабл с неизвестными корнями - бекенды простаивают, цпу > при этом не сказать чтобы нагружен, все кого-то "ждут", входная очередь > переполнена. > Ну да, есть вообще-то ipset. Но кто сказал при каких кол-вах правил это все > еще будет работать? 100k адресов в ip:hash работает ОК. Дальше не пробовал, но не думаю, что здесь могут возникнуть какие-то проблемы. -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sun Jan 27 17:17:05 2013 From: nginx-forum at nginx.us (teo) Date: Sun, 27 Jan 2013 12:17:05 -0500 Subject: nginx as reverse proxy for weblogic In-Reply-To: <201301271758.06478.vbart@nginx.com> References: <201301271758.06478.vbart@nginx.com> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > > Вы его выключили указав ip_hash. Кто бы мог подумать! Тогда в моем случае получалось, что все 1200 соединений пришло из одной сети класса С. Впрочем спасибо, без этого параметра действительно пока все работает - посмотрим как долго он продержится. > nginx тоже не срубят, если файл действительно будет "вытаскиваться", а > не 10 минут висеть. Обратите внимание, многие таймауты задаются на > интервалы > между двумя последовательными операциями, а не на весь ответ целиком. ну да, вы правы. Чтение документации уточняет этот момент > Распространенная ситуация - интервал поступления запросов меньше > интервала > ответа, в этом случае любые дополнительные запросы "для тестирования" > только > создают дополнительную нагрузку, не принося никакой пользы. Согласен, но это не нужно, если есть "другие" ответы от сервера. Но просто равномерное распределение запросов по бекендам тоже не спасает - никто не гарантирует, что все "тяжелые" запросы не скопятся на одном. Идеально было бы иметь размер "очереди" доступный в любой момент - впрочем это видимо у nginx-а есть, по крайней мере как число собственных соединений. Альтернатива - измерение среднего времени ответа бекенда за последние n-секунд или запросов - следующий отдавать тому, у кого он меньше. Впрочем асинхронная природа weblogic видимо противоречит природе nginx - weblogic легко принимает входящие запросы, укладываясь в отведенные таймауты. Только обработка их откладывается взависимости от наличия свободного обработчика. nginx же думает раз его запросы "приняты", значит можно туда же кидать следующие. Но надо было бы измерять не кол-во отданных запросов, а кол-во полученных ответов. Думается в этом случае помог бы параметр максимального кол-ва соединений, ожидающих ответа в описании бекенда. Если его выставить равное кол-ву обработчиков у бекенда - то проблемы бы не возникло. > Это другой метод балансировки, который на данный момент не доступен в > бесплатной > версии nginx. Платная версия ссылается на доку в бесплатной (вроде), может можете привести ссылку на доку где описаны и такие методы? > Nginx поддерживает keepalive начиная с версии 1.1.4. > > http://nginx.org/r/keepalive/ru > Вот только название не соответствует назначению. Я бы назвал это connection_pool. В моем понимании поддержка keep_alive должна была бы учитывать значения, возвращаемые в ответе бекендом, чтобы не закрывая конект пихнуть в него еще один запрос, если его время еще не истекло. И обычно задается не кол-во соединений, а время, в течении которого клиент еще может пихать запросы. Т.е. сервер соглашается не закрывать на это время свое соединение, если клиент сказал что "он умеет так". Тогда на бекенде ставится самое большое keep_alive, а на посреднике чуть меньшее - с тем, чтобы уложиться в него с учетом своего оверхеда. Можно конечно и сложнее организовать - если клиент не умеет, то это не мешает посреднику самому использовать одно соединение с бекендом для разных клиентов. Или даже если keep_alive бекенда уже истек - то для новых запросов использовать новые/другие соединения с бекендом. Т.е. полностью развязать keep_alive бекенда и свой собственный. А держать открытыми некоторое кол-во соединений? Почему только такое кол-во? Это с учетом того, что бекенд это поддерживает? Или клиент иногда будет получать "ваш запрос не обработан, потому что nginx попытался пихнуть его в открытый конект из этого пула, но бекенд уже решил, что время keep_alive истекло и в ответ закрыл этот конект"? Дока как-то этот момент опускает. И не потому ли она советует не увлекаться и в примерах стоит всего 32? Это притом, что дефолтно в настройках стоит 1024 возможных конекта и один обработчик? Как вы думаете - какой будет middle water mark при этих параметрах? 100? А как будет себя вести сервер, если я сконфигурил 10 обработчиков по 1024 конекта? Т.е. мне надо поставить что-то около 2048 в keepalive? А в случае простоя, каждые 60 сек (keep_alive бекенда) у меня будут открываться и закрываться 2048 соединений? Вообщем-то не велика беда. Только зачем? А на остальных 8192 соединениях - там не будет поддерживаться keep_alive? Вобщем это какой-то стрёмный параметр на мой взгляд. В этом виде. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235603,235618#msg-235618 From chipitsine at gmail.com Sun Jan 27 18:18:24 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sun, 27 Jan 2013 23:18:24 +0500 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: <201301271758.06478.vbart@nginx.com> Message-ID: 27 января 2013 г., 23:17 пользователь teo написал: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > > > Это другой метод балансировки, который на данный момент не доступен в > > бесплатной > > версии nginx. > > Платная версия ссылается на доку в бесплатной (вроде), может можете > привести > ссылку на доку где описаны и такие методы? > мы вот таким пользуемся, если надо привязать пользователя по куке: http://code.google.com/p/nginx-sticky-module/ ну и least_conn, который вы приводили в конфиге - равномерно нагружает (тоже используем, очень хорошо работает). в каждом случае что-то одно из двух используем, не одновременно. > > > Nginx поддерживает keepalive начиная с версии 1.1.4. > > > > http://nginx.org/r/keepalive/ru > > > > Вот только название не соответствует назначению. > Я бы назвал это connection_pool. > В моем понимании поддержка keep_alive должна была бы учитывать значения, > возвращаемые в ответе бекендом, чтобы не закрывая конект пихнуть в него еще > один запрос, если его время еще не истекло. > И обычно задается не кол-во соединений, а время, в течении которого клиент > еще может пихать запросы. Т.е. сервер соглашается не закрывать на это время > свое соединение, если клиент сказал что "он умеет так". Тогда на бекенде > ставится самое большое keep_alive, а на посреднике чуть меньшее - с тем, > чтобы уложиться в него с учетом своего оверхеда. Можно конечно и сложнее > организовать - если клиент не умеет, то это не мешает посреднику самому > использовать одно соединение с бекендом для разных клиентов. Или даже если > keep_alive бекенда уже истек - то для новых запросов использовать > новые/другие соединения с бекендом. Т.е. полностью развязать keep_alive > бекенда и свой собственный. > > А держать открытыми некоторое кол-во соединений? Почему только такое > кол-во? > Это с учетом того, что бекенд это поддерживает? > Или клиент иногда будет получать "ваш запрос не обработан, потому что nginx > попытался пихнуть его в открытый конект из этого пула, но бекенд уже решил, > что время keep_alive истекло и в ответ закрыл этот конект"? > Дока как-то этот момент опускает. > И не потому ли она советует не увлекаться и в примерах стоит всего 32? Это > притом, что дефолтно в настройках стоит 1024 возможных конекта и один > обработчик? Как вы думаете - какой будет middle water mark при этих > параметрах? 100? > А как будет себя вести сервер, если я сконфигурил 10 обработчиков по 1024 > конекта? Т.е. мне надо поставить что-то около 2048 в keepalive? > А в случае простоя, каждые 60 сек (keep_alive бекенда) у меня будут > открываться и закрываться 2048 соединений? Вообщем-то не велика беда. > Только > зачем? > А на остальных 8192 соединениях - там не будет поддерживаться keep_alive? > > Вобщем это какой-то стрёмный параметр на мой взгляд. В этом виде. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235603,235618#msg-235618 > > _______________________________________________ > 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 nefer05 at gmail.com Sun Jan 27 19:16:21 2013 From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Sun, 27 Jan 2013 22:16:21 +0300 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: Во первых уже ответили - stateful firewall. Во вторых таблицы. Очень помогает. 2013/1/27 teo > Роман Москвитин Wrote: > ------------------------------------------------------- > > А что мешает блочить фаерволом? Самый легких способ, с точки зрения > > нагрузки. > > Если кол-во правил не большое - то да. > Если их переваливает за 3000, то перед тем как исходный пакет попадет на > входящий порт на который вы поставили ACCEPT, он должен пробежать ваши 3000 > правил. > При этом каждый новый пакет должен сделать тоже самое. В результате вы > получаете некоторый трабл с неизвестными корнями - бекенды простаивают, цпу > при этом не сказать чтобы нагружен, все кого-то "ждут", входная очередь > переполнена. > Ну да, есть вообще-то ipset. Но кто сказал при каких кол-вах правил это все > еще будет работать? > Лучше уж иметь небольшой лаг на обработке одного входящего соединения на > 80й > порт, пока nginx или ваш фронтенд не пробежится по вашим правилам > блокировки. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235603,235615#msg-235615 > > _______________________________________________ > 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 Sun Jan 27 21:54:39 2013 From: nginx-forum at nginx.us (teo) Date: Sun, 27 Jan 2013 16:54:39 -0500 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: Илья Шипицин Wrote: ------------------------------------------------------- > мы вот таким пользуемся, если надо привязать пользователя по куке: > > http://code.google.com/p/nginx-sticky-module/ > > ну и least_conn, который вы приводили в конфиге - равномерно > нагружает > (тоже используем, очень хорошо работает). > > в каждом случае что-то одно из двух используем, не одновременно. Интересная штучка. А как она себя ведет, когда нужно положить один из бекендов? Все кто был привязан будут долбиться в лежачий? Или прежде чем положить надо его в down добавить? В любом случае спасибо на наводку. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235603,235623#msg-235623 From hell-for-yahoo at umail.ru Mon Jan 28 00:59:52 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 28 Jan 2013 04:59:52 +0400 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: <1807444079.20130128045952@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) teo! t> Интересная штучка. А как она себя ведет, когда нужно положить один из t> бекендов? Если *вам нужно* положить, естественно, бэкенд из пула нужно убрать. t> Все кто был привязан будут долбиться в лежачий? Сложно долбиться в то, чего нет. t> Или прежде чем положить надо его в down добавить? t> В любом случае спасибо на наводку. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 28.01.2013, <04:58> From trurl at mcbyte.net Mon Jan 28 02:36:19 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Mon, 28 Jan 2013 04:36:19 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QstC10LTQtdC90LjQtSBleHBpcmVzINC/0YDQuCDQv9GA0L7QutGB?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: <487433850.20130122132255@mtu-net.ru> References: <46a625ddc5ad8a3b9c4b6ac0916bc3c9.NginxMailingListRussian@forum.nginx.org> <487433850.20130122132255@mtu-net.ru> Message-ID: 22 января 2013 г., 11:22 пользователь Andrey Repin написал: > T> тут такая ситуация - сервер выставляет "add_header Cache-Control > public" и > T> свой expires, > T> например получается "Cache-Control: max-age=6048000, public" > T> другой сервер > > Какой "другой сервер"? > Оба сервера - nginx, один другому служит апстримом > > T> у него таскает данные (proxy_pass) и в некоторых случаях > T> выставляет другой expires, и при этом теряется "public" - > "Cache-Control: > T> max-age=180" > T> Это так и задумано или все-таки баг? > > Либо баг, либо особенность воплощения этого самого другого сервера, что он > не > воспринимает большие max-age. > То есть баг nginx? ломает при location ~ ^/d6/files/(.*)$ { proxy_pass http://filer_backend/drupal_share/files/$1; proxy_set_header Host "www"; expires 10m; } версия старовата - nginx/0.8.53 но переход на новую потребует дофига работы - таких серверов много -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Mon Jan 28 04:15:47 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 28 Jan 2013 09:15:47 +0500 Subject: nginx as reverse proxy for weblogic In-Reply-To: References: Message-ID: в зависимости от настройки no_fallback 28 января 2013 г., 3:54 пользователь teo написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > мы вот таким пользуемся, если надо привязать пользователя по куке: > > > > http://code.google.com/p/nginx-sticky-module/ > > > > ну и least_conn, который вы приводили в конфиге - равномерно > > нагружает > > (тоже используем, очень хорошо работает). > > > > в каждом случае что-то одно из двух используем, не одновременно. > > Интересная штучка. А как она себя ведет, когда нужно положить один из > бекендов? > Все кто был привязан будут долбиться в лежачий? > Или прежде чем положить надо его в down добавить? > В любом случае спасибо на наводку. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235603,235623#msg-235623 > > _______________________________________________ > 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 Mon Jan 28 08:34:00 2013 From: nginx-forum at nginx.us (Trurl) Date: Mon, 28 Jan 2013 03:34:00 -0500 Subject: =?UTF-8?B?0L/QvtC80L7Qs9C40YLQtSDQv9C+0L3Rj9GC0Ywg0LvQvtCz0LjQutGDINC60LU=?= =?UTF-8?B?0YjQuNGA0L7QstCw0L3QuNGPINC4INCx0YPRhNC10YDQuNC30LDRhtC40Lg=?= Message-ID: Не могу ничего понять из документации. Допустим у меня вот такой набор: proxy_temp_path /var/lib/nginx/proxy 1 1; proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 keys_zone=main_cache:256m inactive=42h max_size=5m; proxy_buffer_size 8k; proxy_buffers 32 8k; proxy_busy_buffers_size 64k; proxy_max_temp_file_size 0; # ( рекомендовали тут так для ограничения дискового пространства, используемого nginx - если что в корне не верно - поправте меня) И при таком наборе nginx все равно запихал в кеш файл размером 249M, выкинув всю мелочь и остался доволен. Что я делаю не так? Как ограничить максимальный размер кешируемого файла? Мне даже лучше чтобы в кеш попадали только файлы размером с proxy_busy_buffers_size, а все остальные после заполнения буфферов начинали отдаваться с апстрима, минуя кеш и темп, спокойно и не торопливо. Тем более что у меня все равно, вдобавок, limit_rate_after 10000k; limit_rate 250k; > Специальный процесс ?cache manager? следит за максимальным размером кэша, заданным параметром > max_size, и при превышении его размеров удаляет наименее востребованные данные. Это я вообще не понял. Общий размер кеша, на практике, ничего общего с max_size не имеет, зато подозрительно совпадает с размером, заданным в keys_zone, который, вроде бы должен задавать размер разделяемой памяти. Размер proxy_temp_path вообще не понятно как лимитируется. На практике - достижением 100% забитости диска, после чего все помирает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235634#msg-235634 From mdounin at mdounin.ru Mon Jan 28 09:25:53 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 28 Jan 2013 13:25:53 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: <20130128092553.GM40753@mdounin.ru> Hello! On Mon, Jan 28, 2013 at 03:34:00AM -0500, Trurl wrote: > Не могу ничего понять из документации. > > Допустим у меня вот такой набор: > proxy_temp_path /var/lib/nginx/proxy 1 1; > proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 > keys_zone=main_cache:256m inactive=42h max_size=5m; > proxy_buffer_size 8k; > proxy_buffers 32 8k; > proxy_busy_buffers_size 64k; > proxy_max_temp_file_size 0; > # ( рекомендовали тут так для ограничения дискового пространства, > используемого nginx - если что в корне не верно - поправте меня) > > И при таком наборе nginx все равно запихал в кеш файл размером 249M, выкинув > всю мелочь и остался доволен. > Что я делаю не так? Как ограничить максимальный размер кешируемого файла? Сейчас - никак. Ну то есть с бекенда можно явно запретить кеширование, либо же через proxy_no_cache. Какой-либо директивы "не кешировать файлы более N" - нет. [...] > > Специальный процесс ?cache manager? следит за максимальным размером кэша, > заданным параметром > > max_size, и при превышении его размеров удаляет наименее востребованные > данные. > Это я вообще не понял. Общий размер кеша, на практике, ничего общего с > max_size не имеет, зато подозрительно совпадает с размером, заданным в > keys_zone, который, вроде бы должен задавать размер разделяемой памяти. Размер кеша может превышать установленный максимальный размер (max_size), если cache manger ещё не успел его уменьшить, либо он не может это сделать из-за того, что элементы кеша используются рабочими процессами. При max_size=5m и характерном размере файлов 249m - ничего удивительного, что наблюдаемая реальность мало совпадает с желаемой. > Размер proxy_temp_path вообще не понятно как лимитируется. На практике - > достижением 100% забитости диска, после чего все помирает. Совсем в теории - там может быть максимум worker_processes * worker_connections * proxy_max_temp_file_size в отсутствии кеша, и то же с заменой proxy_max_temp_file_size на максимальный размер ответа, возвращаемого бекендом, если кеш включён. На практике - под proxy_temp_path просто следует отводить достаточно места. -- Maxim Dounin http://nginx.com/support.html From trurl at mcbyte.net Mon Jan 28 11:22:52 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Mon, 28 Jan 2013 13:22:52 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <20130128092553.GM40753@mdounin.ru> References: <20130128092553.GM40753@mdounin.ru> Message-ID: 28 января 2013 г., 11:25 пользователь Maxim Dounin написал: > On Mon, Jan 28, 2013 at 03:34:00AM -0500, Trurl wrote: > > > Не могу ничего понять из документации. > > > > Допустим у меня вот такой набор: > > proxy_temp_path /var/lib/nginx/proxy 1 1; > > proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 > > keys_zone=main_cache:256m inactive=42h max_size=5m; > > proxy_buffer_size 8k; > > proxy_buffers 32 8k; > > proxy_busy_buffers_size 64k; > > proxy_max_temp_file_size 0; > > # ( рекомендовали тут так для ограничения дискового пространства, > > используемого nginx - если что в корне не верно - поправте меня) > > > > И при таком наборе nginx все равно запихал в кеш файл размером 249M, > выкинув > > всю мелочь и остался доволен. > > Что я делаю не так? Как ограничить максимальный размер кешируемого файла? > > Сейчас - никак. Ну то есть с бекенда можно явно запретить > кеширование, либо же через proxy_no_cache. Какой-либо директивы > "не кешировать файлы более N" - нет. > У меня бекендов много разных, там и апачи, и nginx (прочие удалось заменить на nginx), в зависимости от целей. А proxy_no_cache не шибко применишь, если размер файла заранее не известен. > > [...] > > > > Специальный процесс ?cache manager? следит за максимальным размером > кэша, > > заданным параметром > > > max_size, и при превышении его размеров удаляет наименее востребованные > > данные. > > Это я вообще не понял. Общий размер кеша, на практике, ничего общего с > > max_size не имеет, зато подозрительно совпадает с размером, заданным в > > keys_zone, который, вроде бы должен задавать размер разделяемой памяти. > > Размер кеша может превышать установленный максимальный размер > (max_size), если cache manger ещё не успел его уменьшить, > либо он не может это сделать из-за того, что элементы кеша > используются рабочими процессами. > Я это учитываю, разовые превышения не в счет. Я про то что _суммарный_ размер кеша в долгосрочной перспективе и с приличной нагрузкой устаканивается в точно в размер keys_zone (!), хотя в документации об этом вообще ничего нет. При этом max_size вообще ни на что не влияет. > > При max_size=5m и характерном размере файлов 249m - ничего > удивительного, что наблюдаемая реальность мало совпадает с > желаемой. > Не понял про "характерный", на тесте только один такой файл был, при его протаскивании из кеша выкидывается почти все (остается файликов на сумму дополняющую до 256m). Если файл крупнее 256m - то он не кешируется. Невзирая на то, что "Сейчас - никак". Но меня такое ограничение не очень устраивает. > > > Размер proxy_temp_path вообще не понятно как лимитируется. На практике - > > достижением 100% забитости диска, после чего все помирает. > > Совсем в теории - там может быть максимум worker_processes * > worker_connections * proxy_max_temp_file_size в отсутствии кеша, и > то же с заменой proxy_max_temp_file_size на максимальный размер > ответа, возвращаемого бекендом, если кеш включён. > по такой логике при proxy_max_temp_file_size 0; вообще ничего не должно заполняться, а у меня до 50 гигов набегает. > > На практике - под proxy_temp_path просто следует отводить > достаточно места. Вот только суммарный контент у меня измеряется в террабайтах. А кол-во коннектов до 20к на каждый сервер. На тестовом канал 200мбит. Что будет когда я его поставлю на продакшен, где отдельный гигабит на каждый сервер - я себе плохо представляю. Видимо там так и останется сквид, у которого со всем этим проблем нет. Зато у него со стабильностью проблемы... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Jan 28 12:09:12 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 28 Jan 2013 16:09:12 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: <20130128092553.GM40753@mdounin.ru> Message-ID: <20130128120911.GR40753@mdounin.ru> Hello! On Mon, Jan 28, 2013 at 01:22:52PM +0200, Trurl McByte wrote: > 28 января 2013 г., 11:25 пользователь Maxim Dounin написал: > > > On Mon, Jan 28, 2013 at 03:34:00AM -0500, Trurl wrote: > > > > > Не могу ничего понять из документации. > > > > > > Допустим у меня вот такой набор: > > > proxy_temp_path /var/lib/nginx/proxy 1 1; > > > proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 > > > keys_zone=main_cache:256m inactive=42h max_size=5m; > > > proxy_buffer_size 8k; > > > proxy_buffers 32 8k; > > > proxy_busy_buffers_size 64k; > > > proxy_max_temp_file_size 0; > > > # ( рекомендовали тут так для ограничения дискового пространства, > > > используемого nginx - если что в корне не верно - поправте меня) > > > > > > И при таком наборе nginx все равно запихал в кеш файл размером 249M, > > выкинув > > > всю мелочь и остался доволен. > > > Что я делаю не так? Как ограничить максимальный размер кешируемого файла? > > > > Сейчас - никак. Ну то есть с бекенда можно явно запретить > > кеширование, либо же через proxy_no_cache. Какой-либо директивы > > "не кешировать файлы более N" - нет. > > > > У меня бекендов много разных, там и апачи, и nginx (прочие удалось заменить > на nginx), в зависимости от целей. А proxy_no_cache не шибко применишь, > если размер файла заранее не известен. Это всё понятно, потому и было написано, что сейчас - никак. Если бекенд не выдаёт информации, явно запрещающей или позволяющей запретить кеширование, то универсально работающего способа - нет. > > > > Специальный процесс ?cache manager? следит за максимальным размером > > кэша, > > > заданным параметром > > > > max_size, и при превышении его размеров удаляет наименее востребованные > > > данные. > > > Это я вообще не понял. Общий размер кеша, на практике, ничего общего с > > > max_size не имеет, зато подозрительно совпадает с размером, заданным в > > > keys_zone, который, вроде бы должен задавать размер разделяемой памяти. > > > > Размер кеша может превышать установленный максимальный размер > > (max_size), если cache manger ещё не успел его уменьшить, > > либо он не может это сделать из-за того, что элементы кеша > > используются рабочими процессами. > > > > Я это учитываю, разовые превышения не в счет. Я про то что _суммарный_ > размер кеша в долгосрочной перспективе и с приличной нагрузкой > устаканивается в точно в размер keys_zone (!), хотя в документации об этом > вообще ничего нет. При этом max_size вообще ни на что не влияет. Размер keys_zone соотносится с размером кеша только опосредованно (т.к. ограничивает максимальное число элементов, которое может храниться в кеше). Если max_size не учитывается - то скорее всего вы правите не тот конфиг, либо не перезагружаете его. Сразу обращаю внимание: при изменении некоторых параметров кеша (путь, levels) nginx может отказаться перезагружать конфиг на лету, написав об этом в error log. В таком случае нужно либо перезапустить nginx, либо провести процедуру обновления исполняемого файла. > > При max_size=5m и характерном размере файлов 249m - ничего > > удивительного, что наблюдаемая реальность мало совпадает с > > желаемой. > > > > Не понял про "характерный", на тесте только один такой файл был, при его > протаскивании из кеша выкидывается почти все (остается файликов на сумму > дополняющую до 256m). Если файл крупнее 256m - то он не кешируется. > Невзирая на то, что "Сейчас - никак". Но меня такое ограничение не очень > устраивает. Судя по всему, 256m - это то, во что у вас установлен параметр max_size. При превышении max_size - из кеша начинают выкидываться старые ответы, и ответ больше max_size - будет практически сразу выкинут. Но это не то же самое, что "не будет закеширован". > > > Размер proxy_temp_path вообще не понятно как лимитируется. На практике - > > > достижением 100% забитости диска, после чего все помирает. > > > > Совсем в теории - там может быть максимум worker_processes * > > worker_connections * proxy_max_temp_file_size в отсутствии кеша, и > > то же с заменой proxy_max_temp_file_size на максимальный размер > > ответа, возвращаемого бекендом, если кеш включён. > > > > по такой логике при proxy_max_temp_file_size 0; вообще ничего не должно > заполняться, а у меня до 50 гигов набегает. При выключенном кеше - так и есть. При включённом - от proxy_max_temp_file_size ничего не зависит, перечитайте ещё раз написанное выше. > > На практике - под proxy_temp_path просто следует отводить > > достаточно места. > > > Вот только суммарный контент у меня измеряется в террабайтах. А кол-во > коннектов до 20к на каждый сервер. На тестовом канал 200мбит. Что будет > когда я его поставлю на продакшен, где отдельный гигабит на каждый сервер - > я себе плохо представляю. Видимо там так и останется сквид, у которого со > всем этим проблем нет. Зато у него со стабильностью проблемы... Арифметика простая: 20k соединений - это 20k * (максимальный размер кешируемого файла) в proxy_temp_path максимум, в худшем случае. Пытаться кешировать в таких условиях blue ray диски - таки да, некомфортно, согласен. Но это скорее способ отстрелить себе ногу, чем практика. -- Maxim Dounin http://nginx.com/support.html From trurl at mcbyte.net Mon Jan 28 13:36:50 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Mon, 28 Jan 2013 15:36:50 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <20130128120911.GR40753@mdounin.ru> References: <20130128092553.GM40753@mdounin.ru> <20130128120911.GR40753@mdounin.ru> Message-ID: 28 января 2013 г., 14:09 пользователь Maxim Dounin написал: > On Mon, Jan 28, 2013 at 01:22:52PM +0200, Trurl McByte wrote: > > > 28 января 2013 г., 11:25 пользователь Maxim Dounin >написал: > > > > > On Mon, Jan 28, 2013 at 03:34:00AM -0500, Trurl wrote: > > > > > > > Не могу ничего понять из документации. > > > > > > > > Допустим у меня вот такой набор: > > > > proxy_temp_path /var/lib/nginx/proxy 1 1; > > > > proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 > > > > keys_zone=main_cache:256m inactive=42h max_size=5m; > > > > proxy_buffer_size 8k; > > > > proxy_buffers 32 8k; > > > > proxy_busy_buffers_size 64k; > > > > proxy_max_temp_file_size 0; > > > > # ( рекомендовали тут так для ограничения дискового пространства, > > > > используемого nginx - если что в корне не верно - поправте меня) > > > > > > > > И при таком наборе nginx все равно запихал в кеш файл размером 249M, > > > выкинув > > > > всю мелочь и остался доволен. > > > > Что я делаю не так? Как ограничить максимальный размер кешируемого > файла? > > > > > > Сейчас - никак. Ну то есть с бекенда можно явно запретить > > > кеширование, либо же через proxy_no_cache. Какой-либо директивы > > > "не кешировать файлы более N" - нет. > > > > > > > У меня бекендов много разных, там и апачи, и nginx (прочие удалось > заменить > > на nginx), в зависимости от целей. А proxy_no_cache не шибко применишь, > > если размер файла заранее не известен. > > Это всё понятно, потому и было написано, что сейчас - никак. Если > бекенд не выдаёт информации, явно запрещающей или позволяющей > запретить кеширование, то универсально работающего способа - нет. > А на бекэнде (nginx на файлере) есть _дешовый_ способ выставить хидеры в зависимости от размеров файла? Именно дешовый, потому как юзать перл и прочее на файлере - плохая идея. И какие? То ли X-Accel-Buffering (по идее при отключенном буфере кеширования нет, да и 80% такого контента - видео/аудио) То ли X-Accel-Expires (а оно точно не будет все равно кешировать и тут же экспайрить? И в temp пихать не будет?) Ну и X-Accel-Limit-Rate заодно... > > > > > Специальный процесс ?cache manager? следит за максимальным размером > > > кэша, > > > > заданным параметром > > > > > max_size, и при превышении его размеров удаляет наименее > востребованные > > > > данные. > > > > Это я вообще не понял. Общий размер кеша, на практике, ничего общего > с > > > > max_size не имеет, зато подозрительно совпадает с размером, заданным > в > > > > keys_zone, который, вроде бы должен задавать размер разделяемой > памяти. > > > > > > Размер кеша может превышать установленный максимальный размер > > > (max_size), если cache manger ещё не успел его уменьшить, > > > либо он не может это сделать из-за того, что элементы кеша > > > используются рабочими процессами. > > > > > > > Я это учитываю, разовые превышения не в счет. Я про то что _суммарный_ > > размер кеша в долгосрочной перспективе и с приличной нагрузкой > > устаканивается в точно в размер keys_zone (!), хотя в документации об > этом > > вообще ничего нет. При этом max_size вообще ни на что не влияет. > > Размер keys_zone соотносится с размером кеша только опосредованно > (т.к. ограничивает максимальное число элементов, которое может > храниться в кеше). > В том-то и дело что наблюдается совершенно другая зависимость... при proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 keys_zone=main_cache:256m inactive=42h max_size=5m; кеш выглядит так du -bc */*/* | sort -rn | head -15 264365155 total 259844420 5/f/583c124c9e5cac01c97bcb0d9c56b6f5 1968962 d/f/8a473cf7ea9e00771de9cca58b6c8dfd 271317 3/3/b14c4ca7615e5f316b612e6105d72733 202668 2/d/58af6126b8b936f3bc0c1fe861d5c8d2 149240 0/9/2810fe7c50e3bf30847db46fc27fb790 78200 9/2/b21a65e9c49fcd37abeb1f90d56dea29 72009 e/5/34156b0979c7364e57d6dedbd091265e 63667 0/a/908042c8c483a45e5254bfd8559008a0 62044 7/6/040ea3ec37b3a834ad7a80b06e60fd67 54475 0/d/1ecc6a6a03fb044944aeb36abc0658d0 54004 8/d/80a9dbbecacc2fc574f23dd46c8227d8 53300 1/f/dcfbb766776d9d8d29c29b20ab068ef1 51410 2/3/fe6eff5160d14633ab6fa06325230832 48559 5/6/91ccd7a9bc98a1eab14d1322cc735f65 Причем пробег кеш-менеджера в таком состоянии может и вычистить все (совсем, все файлы, не взирая на размер), если нагрузки нет. А может и не тронуть. Пока суммарный размер не превысит keys_zone - в этом случае выкинет лишнее. Или все. В общем как бог на душу положит. Вот keys_zone он строго не дает превышать, проверено на другом, сильно нагруженном сервере и вообще такой странный набор я прописывал по совету кого-то тут. Я и подумал, что это известная недокументированная фитча. > Если max_size не учитывается - то скорее всего вы правите не тот > конфиг, либо не перезагружаете его. > Ну я не настолько заработался еще... > > Сразу обращаю внимание: при изменении некоторых параметров кеша > (путь, levels) nginx может отказаться перезагружать конфиг на > лету, написав об этом в error log. В таком случае нужно либо > перезапустить nginx, либо провести процедуру обновления > исполняемого файла. > я после перехода на systemd вообще стал жутко недоверчивый и в случаях экспериментов с любыми конфигами без полной остановки и ps ax | grep {procname} не обхожусь > > > > При max_size=5m и характерном размере файлов 249m - ничего > > > удивительного, что наблюдаемая реальность мало совпадает с > > > желаемой. > > > > > > > Не понял про "характерный", на тесте только один такой файл был, при его > > протаскивании из кеша выкидывается почти все (остается файликов на сумму > > дополняющую до 256m). Если файл крупнее 256m - то он не кешируется. > > Невзирая на то, что "Сейчас - никак". Но меня такое ограничение не очень > > устраивает. > > Судя по всему, 256m - это то, во что у вас установлен параметр > max_size. При превышении max_size - из кеша начинают выкидываться > старые ответы, и ответ больше max_size - будет практически сразу > выкинут. Но это не то же самое, что "не будет закеширован". > Я же написал - max_size=5m Файл не выкинут в течении получаса. > > > > Размер proxy_temp_path вообще не понятно как лимитируется. На > практике - > > > > достижением 100% забитости диска, после чего все помирает. > > > > > > Совсем в теории - там может быть максимум worker_processes * > > > worker_connections * proxy_max_temp_file_size в отсутствии кеша, и > > > то же с заменой proxy_max_temp_file_size на максимальный размер > > > ответа, возвращаемого бекендом, если кеш включён. > > > > > > > по такой логике при proxy_max_temp_file_size 0; вообще ничего не должно > > заполняться, а у меня до 50 гигов набегает. > > При выключенном кеше - так и есть. При включённом - от > proxy_max_temp_file_size ничего не зависит, перечитайте ещё раз > написанное выше. > > > > На практике - под proxy_temp_path просто следует отводить > > > достаточно места. > > > > > > Вот только суммарный контент у меня измеряется в террабайтах. А кол-во > > коннектов до 20к на каждый сервер. На тестовом канал 200мбит. Что будет > > когда я его поставлю на продакшен, где отдельный гигабит на каждый > сервер - > > я себе плохо представляю. Видимо там так и останется сквид, у которого со > > всем этим проблем нет. Зато у него со стабильностью проблемы... > > Арифметика простая: 20k соединений - это 20k * (максимальный > размер кешируемого файла) в proxy_temp_path максимум, в худшем > случае. > > Пытаться кешировать в таких условиях blue ray диски - таки да, > некомфортно, согласен. Но это скорее способ отстрелить себе ногу, > чем практика. у нас эксклюзивные (то есть свои) видео и аудио. Да и всякие инсталлеры модов тоже жирные бывают. Типа HiRes тесктур для Скайрима (5GB файлик). У сквида есть maximum_object_size_in_memory и maximum_object_size для такого случая. А в nginx вроде бы есть связка proxy_buffer_size+proxy_buffers+proxy_max_temp_file_size для того же, но, почему-то, работает не адекватно. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Jan 28 14:17:15 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 28 Jan 2013 18:17:15 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: <20130128092553.GM40753@mdounin.ru> <20130128120911.GR40753@mdounin.ru> Message-ID: <20130128141715.GT40753@mdounin.ru> Hello! On Mon, Jan 28, 2013 at 03:36:50PM +0200, Trurl McByte wrote: > 28 января 2013 г., 14:09 пользователь Maxim Dounin написал: > > > On Mon, Jan 28, 2013 at 01:22:52PM +0200, Trurl McByte wrote: > > > > > 28 января 2013 г., 11:25 пользователь Maxim Dounin > >написал: > > > > > > > On Mon, Jan 28, 2013 at 03:34:00AM -0500, Trurl wrote: > > > > > > > > > Не могу ничего понять из документации. > > > > > > > > > > Допустим у меня вот такой набор: > > > > > proxy_temp_path /var/lib/nginx/proxy 1 1; > > > > > proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 > > > > > keys_zone=main_cache:256m inactive=42h max_size=5m; > > > > > proxy_buffer_size 8k; > > > > > proxy_buffers 32 8k; > > > > > proxy_busy_buffers_size 64k; > > > > > proxy_max_temp_file_size 0; > > > > > # ( рекомендовали тут так для ограничения дискового пространства, > > > > > используемого nginx - если что в корне не верно - поправте меня) > > > > > > > > > > И при таком наборе nginx все равно запихал в кеш файл размером 249M, > > > > выкинув > > > > > всю мелочь и остался доволен. > > > > > Что я делаю не так? Как ограничить максимальный размер кешируемого > > файла? > > > > > > > > Сейчас - никак. Ну то есть с бекенда можно явно запретить > > > > кеширование, либо же через proxy_no_cache. Какой-либо директивы > > > > "не кешировать файлы более N" - нет. > > > > > > > > > > У меня бекендов много разных, там и апачи, и nginx (прочие удалось > > заменить > > > на nginx), в зависимости от целей. А proxy_no_cache не шибко применишь, > > > если размер файла заранее не известен. > > > > Это всё понятно, потому и было написано, что сейчас - никак. Если > > бекенд не выдаёт информации, явно запрещающей или позволяющей > > запретить кеширование, то универсально работающего способа - нет. > > > > А на бекэнде (nginx на файлере) есть _дешовый_ способ выставить хидеры в > зависимости от размеров файла? Именно дешовый, потому как юзать перл и > прочее на файлере - плохая идея. > И какие? > То ли X-Accel-Buffering (по идее при отключенном буфере кеширования нет, да > и 80% такого контента - видео/аудио) > То ли X-Accel-Expires (а оно точно не будет все равно кешировать и тут же > экспайрить? И в temp пихать не будет?) > Ну и X-Accel-Limit-Rate заодно... Expires в прошлом - выключает кеширование (равно как и X-Accel-Expires, Cache-Control max-age). Что именно использовать - at your option, я бы наверное выключал через X-Accel-Expires. Не перлом - можно попробовать через map $http_content_length $expires { default ""; "~[0-9]{7,}" "0"; } add_header X-Accel-Expires $expires; (untested) Хотя я бы рекомендовал кешируемый и не кешируемый контент просто разнести в разные каталоги, и включать кеш только там, где надо. [...] > > > > Размер кеша может превышать установленный максимальный размер > > > > (max_size), если cache manger ещё не успел его уменьшить, > > > > либо он не может это сделать из-за того, что элементы кеша > > > > используются рабочими процессами. [...] > Причем пробег кеш-менеджера в таком состоянии может и вычистить все > (совсем, все файлы, не взирая на размер), если нагрузки нет. А может и не > тронуть. Если "может вычистить" без нагрузки - то скорее всего дело в том, что под нагрузкой элементы кеша используются рабочими процессами (i.e. соответствующий элемент кеша сейчас обновляется). Выше - цитата из исходного ответа. [...] > у нас эксклюзивные (то есть свои) видео и аудио. Да и всякие инсталлеры > модов тоже жирные бывают. Типа HiRes тесктур для Скайрима (5GB файлик). > > У сквида есть maximum_object_size_in_memory и maximum_object_size для > такого случая. > А в nginx вроде бы есть связка > proxy_buffer_size+proxy_buffers+proxy_max_temp_file_size для того же, но, > почему-то, работает не адекватно. См. выше, в nginx'е - сейчас нет ограничения на максимальный размер кешируемого ответа. -- Maxim Dounin http://nginx.com/support.html From trurl at mcbyte.net Mon Jan 28 14:29:41 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Mon, 28 Jan 2013 16:29:41 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <20130128141715.GT40753@mdounin.ru> References: <20130128092553.GM40753@mdounin.ru> <20130128120911.GR40753@mdounin.ru> <20130128141715.GT40753@mdounin.ru> Message-ID: 28 января 2013 г., 16:17 пользователь Maxim Dounin написал: > > А на бекэнде (nginx на файлере) есть _дешовый_ способ выставить хидеры в > > зависимости от размеров файла? Именно дешовый, потому как юзать перл и > > прочее на файлере - плохая идея. > > И какие? > > То ли X-Accel-Buffering (по идее при отключенном буфере кеширования нет, > да > > и 80% такого контента - видео/аудио) > > То ли X-Accel-Expires (а оно точно не будет все равно кешировать и тут же > > экспайрить? И в temp пихать не будет?) > > Ну и X-Accel-Limit-Rate заодно... > > Expires в прошлом - выключает кеширование (равно как и > X-Accel-Expires, Cache-Control max-age). Что именно использовать - > at your option, я бы наверное выключал через X-Accel-Expires. > > Не перлом - можно попробовать через > > map $http_content_length $expires { > default ""; > "~[0-9]{7,}" "0"; > } > > add_header X-Accel-Expires $expires; > > (untested) > > Хотя я бы рекомендовал кешируемый и не кешируемый контент просто > разнести в разные каталоги, и включать кеш только там, где надо. > Большое спасибо за идею, буду пробовать. А разносить поздно, контент собирался с 2003-го, свалка - это мягко сказано. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Jan 28 19:32:58 2013 From: nginx-forum at nginx.us (Vipper) Date: Mon, 28 Jan 2013 14:32:58 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCDQr9C90LTQtdC60YEt0KLRg9GA0LHQvg==?= In-Reply-To: <16410348687.20130126174210@softsearch.ru> References: <16410348687.20130126174210@softsearch.ru> Message-ID: <1951bc036ef27fb4fbe444ef43e05c81.NginxMailingListRussian@forum.nginx.org> Мало было Оперы, нате Вам новый геморрой от Яндекса :( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235594,235673#msg-235673 From nginx-forum at nginx.us Mon Jan 28 19:34:17 2013 From: nginx-forum at nginx.us (teo) Date: Mon, 28 Jan 2013 14:34:17 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: Trurl Wrote: ------------------------------------------------------- > Не могу ничего понять из документации. > > Допустим у меня вот такой набор: > proxy_temp_path /var/lib/nginx/proxy 1 1; > proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 > keys_zone=main_cache:256m inactive=42h max_size=5m; Давайте я попробую объяснить, хотя на уровень гуру не претендую. max_size=5m задает тот размер, до которого выхотите уменьшить размер своего кеша, если в нем перестанет хватать памяти для новых запросов, или до какого размера он опустится при новом старте, когда запустится фоновый "загрузчик кеша". Т.е. - сколько вы готовы "хранить вечно" proxy_temp_path - задает путь, чтобы облегчить в вашей системе перемещение кешируемых файлов, потому что именно такой метод использован в nginx. И именно поэтому это должно быть на одной файловой системе, если хотите чтобы это происходило мгновенно, а не в виде (copy $1 $2; remove $1); Т.ч. после перемещения файлов ее размер должен быть равен нулю или близко Вот примерно как это выглядит в реальности для proxy_cache_path /var/cache/nginx/media_cache levels=2:2 keys_zone=media:8192m inactive=7d max_size=8000m; proxy_temp_path /var/cache/nginx/proxy_temp 2 2; 4,0K client_temp 4,0K fastcgi_temp 5,2G media_cache --- место под кеш 44M proxy_temp --- место под временные файлы 4,0K scgi_temp 4,0K uwsgi_temp 5,2G итого Как видим в temp_path нет "копии" тех 5 гиг, что теперь лежат в кеше. А чтобы не помещать в кеш какие-то файлы, то для этого есть всего одна опция proxy_no_cache А уж какие значения вы туда подсунете - то и не будет кешироваться. Правда желательно будет указать еще proxy_cache_bypass - с такими же значениями, чтобы nginx не лез за ними в кеш Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235674#msg-235674 From nginx-forum at nginx.us Mon Jan 28 20:00:41 2013 From: nginx-forum at nginx.us (teo) Date: Mon, 28 Jan 2013 15:00:41 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <20130128120911.GR40753@mdounin.ru> References: <20130128120911.GR40753@mdounin.ru> Message-ID: <78361e91c978a3efdafd6ffc2bb0386b.NginxMailingListRussian@forum.nginx.org> proxy_max_temp_file_size вообще не имеет к размеру файлов в кеше никакого значения Цитата: Директива задаёт максимальный размер временного файла для проксированного ответа. "proxy_max_temp_file_size 0" запрещает создание файла. Т.е. определяет может ли nginx писать ответ бекенда на диск перед отдачей клиенту, или ему придется отдавать его на лету. При этом общий объем отдачи клиенту и этот размер никак не коррелируют. Ответ может быть 10Тер, а размер временного файла 1Мег, тогда nginx может каждый пришедший 1Мег записывать на диск и потом отдавать клиенту, и все это в цикле, (пока все не посинеют))) Хотя никто не сказал, что будет если размер ответа известен сразу и превышает - nginx может отказаться писать ответ во временный файл, если сочтет это не эффективным. Полезность его установки в больше нуля только в одном - если надо разгрузить бекенды для новых запросов при неторопливых клиентах (или такого вида атаки) Но если у вас система обрабатывает 100к запросов, и вы поставили размер в 1мег, то это может потребовать 100Гиг диска для временного хранения ответов. И нехилый вобщем disk-io ))) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235677#msg-235677 From trurl at mcbyte.net Mon Jan 28 21:38:14 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Mon, 28 Jan 2013 23:38:14 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <78361e91c978a3efdafd6ffc2bb0386b.NginxMailingListRussian@forum.nginx.org> References: <20130128120911.GR40753@mdounin.ru> <78361e91c978a3efdafd6ffc2bb0386b.NginxMailingListRussian@forum.nginx.org> Message-ID: 28 января 2013 г., 22:00 пользователь teo написал: > proxy_max_temp_file_size вообще не имеет к размеру файлов в кеше никакого > значения > Цитата: > Директива задаёт максимальный размер временного файла для проксированного > ответа. "proxy_max_temp_file_size 0" запрещает создание файла. > > Т.е. определяет может ли nginx писать ответ бекенда на диск перед отдачей > клиенту, или ему придется отдавать его на лету. > В том то и дело что это только в теории и по логике вещей. А на практике, при включенном кешировании, nginx плюет на proxy_max_temp_file_size и пишет, сколько ему нужно. вот например процесс выкачки 67M файлика в середине процесса: -rw------- 1 nginx nginx 43778048 Jan 28 13:32 7/7/0000000077 ... в конце: -rw------- 1 nginx nginx 69885952 Jan 28 13:34 7/7/0000000077 сколько там стоит proxy_max_temp_file_size - по барабану, хоть 0, хоть 8M. > При этом общий объем отдачи клиенту и этот размер никак не коррелируют. > Ответ может быть 10Тер, а размер временного файла 1Мег, тогда nginx может > каждый пришедший 1Мег записывать на диск и потом отдавать клиенту, и все > это > в цикле, (пока все не посинеют))) > Хотя никто не сказал, что будет если размер ответа известен сразу и > превышает - nginx может отказаться писать ответ во временный файл, если > сочтет это не эффективным. > Полезность его установки в больше нуля только в одном - если надо > разгрузить > бекенды для новых запросов при неторопливых клиентах (или такого вида > атаки) > Но если у вас система обрабатывает 100к запросов, и вы поставили размер в > 1мег, то это может потребовать 100Гиг диска для временного хранения > ответов. > И нехилый вобщем disk-io ))) > До 100 гиг не доходило, но до 50 гиг уже не раз. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Jan 28 22:02:11 2013 From: nginx-forum at nginx.us (teo) Date: Mon, 28 Jan 2013 17:02:11 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: <99f4b84f4cfd93ce2e5c6cf21947ae5c.NginxMailingListRussian@forum.nginx.org> > В том то и дело что это только в теории и по логике вещей. А на > практике, > при включенном кешировании, nginx плюет на proxy_max_temp_file_size и > пишет, сколько ему нужно. Вы опять пытаетесь смешать в кучу кеширование и этот параметр! И в качестве доказательства приводите размер файла в кеше! И правильно! В кеше будет лежать весь файл целиком! А как иначе? Откуда он возмет недостающий размер, если вы его "ограничили"? Т.е. чтобы ограничить размер файла в кеше - единственный путь чтобы они туда не попадали! А для этого у вас есть только proxy_no_cache с не пустым значением для случая, когда ответ бекенда будет превышать некоторое ваше значение! Сумеете ли вы инициализировать такую переменную или нет - ваше дело и возможности nginx. Только proxy_max_temp_file_size ну ни каким боком не связан с кешированием и ограчением максимального размера файла в кеше. И если непонятно, то просто прочтите его описание еще раз. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235682#msg-235682 From postmaster at softsearch.ru Mon Jan 28 22:06:03 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 29 Jan 2013 02:06:03 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0YDQvtC60YHQuCDQr9C90LTQtdC60YEt0KLRg9GA0LHQvg==?= In-Reply-To: <1951bc036ef27fb4fbe444ef43e05c81.NginxMailingListRussian@forum.nginx.org> References: <16410348687.20130126174210@softsearch.ru> <1951bc036ef27fb4fbe444ef43e05c81.NginxMailingListRussian@forum.nginx.org> Message-ID: <7510232391.20130129020603@softsearch.ru> Здравствуйте, Vipper. > Мало было Оперы, нате Вам новый геморрой от Яндекса :( А в чём новый геморрой? И почему старый геморрой? -- С уважением, Михаил mailto:postmaster at softsearch.ru From hell-for-yahoo at umail.ru Tue Jan 29 07:44:55 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Tue, 29 Jan 2013 11:44:55 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QstC10LTQtdC90LjQtSBleHBpcmVzINC/0YDQuCDQv9GA0L7QutGB?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: References: <46a625ddc5ad8a3b9c4b6ac0916bc3c9.NginxMailingListRussian@forum.nginx.org> <487433850.20130122132255@mtu-net.ru> Message-ID: <1648575796.20130129114455@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Trurl McByte! >> T> тут такая ситуация - сервер выставляет "add_header Cache-Control >> public" и >> T> свой expires, >> T> например получается "Cache-Control: max-age=6048000, public" >> T> другой сервер >> >> Какой "другой сервер"? >> TM> Оба сервера - nginx, один другому служит апстримом >> >> T> у него таскает данные (proxy_pass) и в некоторых случаях >> T> выставляет другой expires, и при этом теряется "public" - >> "Cache-Control: >> T> max-age=180" >> T> Это так и задумано или все-таки баг? >> >> Либо баг, либо особенность воплощения этого самого другого сервера, что он >> не >> воспринимает большие max-age. >> TM> То есть баг nginx? TM> ломает при TM> location ~ ^/d6/files/(.*)$ { TM> proxy_pass http://filer_backend/drupal_share/files/$1; TM> proxy_set_header Host "www"; TM> expires 10m; TM> } TM> версия старовата - nginx/0.8.53 TM> но переход на новую потребует дофига работы - таких серверов много Это вы говорите, чтобы ничего не делать, или вы всё таки пробовали что-то реально сделать?... -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) вторник, 29.01.2013, <11:44> From citrin at citrin.ru Tue Jan 29 13:04:39 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 29 Jan 2013 17:04:39 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCDQr9C90LTQtdC60YEt0KLRg9GA0LHQvg==?= In-Reply-To: <16410348687.20130126174210@softsearch.ru> References: <16410348687.20130126174210@softsearch.ru> Message-ID: <5107C8E7.3030508@citrin.ru> On 01/26/13 17:42, Михаил Монашёв wrote: > Видимо можно писать в конфигах > set_real_ip_from 5.45.192.64/26; По заголовкам, еще не проверял, но в ДНС есть: trbo01y.trbo.yandex.net 141.8.189.193 trbo02y.trbo.yandex.net 141.8.189.194 trbo03y.trbo.yandex.net 141.8.189.195 trbo04y.trbo.yandex.net 141.8.189.196 trbo05y.trbo.yandex.net 141.8.189.197 trbo06y.trbo.yandex.net 141.8.189.198 trbo07y.trbo.yandex.net 141.8.189.199 trbo08y.trbo.yandex.net 141.8.189.200 trbo09y.trbo.yandex.net 141.8.189.201 trbo10y.trbo.yandex.net 141.8.189.202 Из сотрудников Яндекс кто то читает данную рассылку? Может есть исчерпывающий список из первых рук, чтобы не вычислять по логам? -- Anton Yuzhaninov From postmaster at softsearch.ru Tue Jan 29 14:47:33 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 29 Jan 2013 18:47:33 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0YDQvtC60YHQuCDQr9C90LTQtdC60YEt0KLRg9GA0LHQvg==?= In-Reply-To: <5107C8E7.3030508@citrin.ru> References: <16410348687.20130126174210@softsearch.ru> <5107C8E7.3030508@citrin.ru> Message-ID: <1445081436.20130129184733@softsearch.ru> Здравствуйте, Anton. >> Видимо можно писать в конфигах >> set_real_ip_from 5.45.192.64/26; > По заголовкам, еще не проверял, но в ДНС есть: > trbo01y.trbo.yandex.net 141.8.189.193 > trbo02y.trbo.yandex.net 141.8.189.194 > trbo03y.trbo.yandex.net 141.8.189.195 > trbo04y.trbo.yandex.net 141.8.189.196 > trbo05y.trbo.yandex.net 141.8.189.197 > trbo06y.trbo.yandex.net 141.8.189.198 > trbo07y.trbo.yandex.net 141.8.189.199 > trbo08y.trbo.yandex.net 141.8.189.200 > trbo09y.trbo.yandex.net 141.8.189.201 > trbo10y.trbo.yandex.net 141.8.189.202 Посмотрел сейчас логи. Заголовок X-Yandex-Turbo: yes начал ставится не только из подсетей яндекса: 136.169.229.215 141.8.189.195 trbo03y.trbo.yandex.net. 176.120.176.248 178.44.162.185 188.226.39.251 188.226.39.251-FTTB.planeta.tc. 194.176.111.28 194.176.111.31 212.19.6.14 host.212-19-6-14.broadband.redcom.ru. 213.167.223.125 213-167-223-125.domolink.elcom.ru. 213.87.120.25 213.87.129.206 206.gprs.mts.ru. 213.87.129.45 45.gprs.mts.ru. 213.87.132.237 237.gprs.mts.ru. 213.87.140.107 107.gprs.mts.ru. кстати, как видишь, trbo03y.trbo.yandex.net. уже работает. -- С уважением, Михаил mailto:postmaster at softsearch.ru From melifaro at ipfw.ru Tue Jan 29 15:09:05 2013 From: melifaro at ipfw.ru (Alexander V. Chernikov) Date: Tue, 29 Jan 2013 19:09:05 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCDQr9C90LTQtdC60YEt0KLRg9GA0LHQvg==?= In-Reply-To: <1445081436.20130129184733@softsearch.ru> References: <16410348687.20130126174210@softsearch.ru> <5107C8E7.3030508@citrin.ru> <1445081436.20130129184733@softsearch.ru> Message-ID: <5107E611.8050200@ipfw.ru> On 29.01.2013 18:47, Михаил Монашёв wrote: > Здравствуйте, Anton. Всем привет. > >>> Видимо можно писать в конфигах >>> set_real_ip_from 5.45.192.64/26; На данный момент как-то так: 5.45.192.64/26 5.45.255.64/26 141.8.189.192/27 37.140.189.192/26 В будущем, разумеется, эти диапазоны могут (и будут) меняться. > >> По заголовкам, еще не проверял, но в ДНС есть: >> trbo01y.trbo.yandex.net 141.8.189.193 >> trbo02y.trbo.yandex.net 141.8.189.194 >> trbo03y.trbo.yandex.net 141.8.189.195 >> trbo04y.trbo.yandex.net 141.8.189.196 >> trbo05y.trbo.yandex.net 141.8.189.197 >> trbo06y.trbo.yandex.net 141.8.189.198 >> trbo07y.trbo.yandex.net 141.8.189.199 >> trbo08y.trbo.yandex.net 141.8.189.200 >> trbo09y.trbo.yandex.net 141.8.189.201 >> trbo10y.trbo.yandex.net 141.8.189.202 > > Посмотрел сейчас логи. Заголовок X-Yandex-Turbo: yes начал ставится не > только из подсетей яндекса: > 136.169.229.215 > 141.8.189.195 trbo03y.trbo.yandex.net. > 176.120.176.248 > 178.44.162.185 > 188.226.39.251 188.226.39.251-FTTB.planeta.tc. > 194.176.111.28 > 194.176.111.31 > 212.19.6.14 host.212-19-6-14.broadband.redcom.ru. > 213.167.223.125 213-167-223-125.domolink.elcom.ru. > 213.87.120.25 > 213.87.129.206 206.gprs.mts.ru. > 213.87.129.45 45.gprs.mts.ru. > 213.87.132.237 237.gprs.mts.ru. > 213.87.140.107 107.gprs.mts.ru. > > > кстати, как видишь, trbo03y.trbo.yandex.net. уже работает. > > -- Alexander V. Chernikov melifaro at yandex-team.ru Yandex LLC, NOC department From postmaster at softsearch.ru Tue Jan 29 15:35:01 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 29 Jan 2013 19:35:01 +0400 Subject: =?UTF-8?B?UmVbM106INCf0YDQvtC60YHQuCDQr9C90LTQtdC60YEt0KLRg9GA0LHQvg==?= In-Reply-To: <1445081436.20130129184733@softsearch.ru> References: <16410348687.20130126174210@softsearch.ru> <5107C8E7.3030508@citrin.ru> <1445081436.20130129184733@softsearch.ru> Message-ID: <19210208373.20130129193501@softsearch.ru> Здравствуйте. > Посмотрел сейчас логи. Заголовок X-Yandex-Turbo: yes начал ставится не > только из подсетей яндекса: это я стормозил. в логи писались ip, взятые из X-Forwarded-For :-) -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Tue Jan 29 15:39:16 2013 From: nginx-forum at nginx.us (dizelbox) Date: Tue, 29 Jan 2013 10:39:16 -0500 Subject: =?UTF-8?B?Tmdpbngg0LggbW9kIHppcDog0LfQsNCz0YDRg9C30LrQsCDRhNCw0LnQu9C+0LIg?= =?UTF-8?B?0YEg0LLQvdC10YjQvdC40YUg0YHQtdGA0LLQtdGA0L7QsiDRgSDQuNGB0L8=?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LXQvCDQuNC80LXQvdC4INC00L7QvNC10L0=?= =?UTF-8?B?0LA=?= Message-ID: <4701a84775d4d6294f28e0f88e146e8c.NginxMailingListRussian@forum.nginx.org> Делаю формирование динамического zip-архива с помощью модуля mod_zip. Используется вот такой конфиг для выкачивания файлов с внешних серверов (file-server1.local, file-server2.local ...). Формирование динамического архива осуществляется примерно таким кодом: string(140) "15263b8b 66000 /remote/file-server1.local/files/private/ee4b41adb859ccce6be2fa0c45fc64f0.ini?name=php.ini&s=QNaKDGtKbhi5f1ySB3LwpQ,1359444711 php.ini" [1] => string(170) "bc8706b1 8361107 /remote/file-server1.local/files/private/154eeb7eef9e55ce2da97d9f7cd6fee5.zip?name=nginx-1.2.6-build.zip&s=3VFP4YEG3I5bAuQH0tiYww,1359444711 nginx-1.2.6-build.zip" [2] => string(157) "9e7b9349 917698 /remote/file-server1.local/files/private/597d93a30395e27a1f19f7e226187163.sql?name=tariff_dump.sql&s=U0CdT7Z6n4AoGiZ3K6Qe2Q,1359444711 tariff_dump.sql" [3] => string(145) "e7310915 225234 /remote/file-server1.local/files/private/350679e790a7f702a5d37bee444de9f3.jpg?name=other.jpg&s=Fy4YD6rh5FMgvbSGn9Klzg,1359444711 other.jpg" [4] => string(101) "0a099d44 36459 /remote/file-server1.local/files/public/8b62108713f3e949d7a27cdb4d3f3e18?name=memcache memcache" [5] => string(286) "50208924 466588 /remote/file-server1.local/files/public/9e751852bdfcce582f193a893eb7ad65.jpg?name=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%BE%D0%B5_%D0%BD%D0%B0%D0%B7%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F.jpg russkoe_nazvanie_izobrazheniya.jpg" [6] => string(116) "d67324f8 19 /remote/file-server1.local/files/public/30e64f83b137f0e1e26624bdcbc59912.php?name=test_script.php test_script.php" } Проблема заключается в том, что не удается скачать файл по имени домена. Скачивание получается осуществить только по ip-адресу. Для этого осуществляю преобразование названия домена в ip с помощью функции gethostbyname() и получаю примерно такой массив: array(7) { [0] => string(140) "15263b8b 66000 /remote/127.0.1.1/files/private/ee4b41adb859ccce6be2fa0c45fc64f0.ini?name=php.ini&s=QNaKDGtKbhi5f1ySB3LwpQ,1359444711 php.ini" [1] => string(170) "bc8706b1 8361107 /remote/127.0.1.1/files/private/154eeb7eef9e55ce2da97d9f7cd6fee5.zip?name=nginx-1.2.6-build.zip&s=3VFP4YEG3I5bAuQH0tiYww,1359444711 nginx-1.2.6-build.zip" [2] => string(157) "9e7b9349 917698 /remote/127.0.1.1/files/private/597d93a30395e27a1f19f7e226187163.sql?name=tariff_dump.sql&s=U0CdT7Z6n4AoGiZ3K6Qe2Q,1359444711 tariff_dump.sql" [3] => string(145) "e7310915 225234 /remote/127.0.1.1/files/private/350679e790a7f702a5d37bee444de9f3.jpg?name=other.jpg&s=Fy4YD6rh5FMgvbSGn9Klzg,1359444711 other.jpg" [4] => string(101) "0a099d44 36459 /remote/127.0.1.1/files/public/8b62108713f3e949d7a27cdb4d3f3e18?name=memcache memcache" [5] => string(286) "50208924 466588 /remote/127.0.1.1/files/public/9e751852bdfcce582f193a893eb7ad65.jpg?name=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%BE%D0%B5_%D0%BD%D0%B0%D0%B7%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F.jpg russkoe_nazvanie_izobrazheniya.jpg" [6] => string(116) "d67324f8 19 /remote/127.0.1.1/files/public/30e64f83b137f0e1e26624bdcbc59912.php?name=test_script.php test_script.php" } Конфиг nginx для скачивания файлов с внешних серверов такой: location ~* ^/remote/(.+?)/(.+)$ { internal; proxy_hide_header Content-Type; proxy_pass http://$1/$2$is_args$args; } Вопрос заключается в следующем: можно ли как-то скачивать файлы именно по имени домена, так как не всегда можно организовать такую структуру, чтобы каждый домен был на отдельном ip-адресе? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235692,235692#msg-235692 From vbart at nginx.com Tue Jan 29 16:05:33 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 29 Jan 2013 20:05:33 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICDQuCBtb2QgemlwOiDQt9Cw0LPRgNGD0LfQutCwINGE0LDQudC7?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: <4701a84775d4d6294f28e0f88e146e8c.NginxMailingListRussian@forum.nginx.org> References: <4701a84775d4d6294f28e0f88e146e8c.NginxMailingListRussian@forum.nginx.org> Message-ID: <201301292005.33130.vbart@nginx.com> On Tuesday 29 January 2013 19:39:16 dizelbox wrote: [...] > Конфиг nginx для скачивания файлов с внешних серверов такой: > > location ~* ^/remote/(.+?)/(.+)$ { > internal; > proxy_hide_header Content-Type; > proxy_pass http://$1/$2$is_args$args; > } > > > Вопрос заключается в следующем: можно ли как-то скачивать файлы именно по > имени домена, так как не всегда можно организовать такую структуру, чтобы > каждый домен был на отдельном ip-адресе? > Могу лишь предположить, что вы забыли указать resolver [1] и наблюдаете ошибки "no resolver defined to resolve example.com" в error_log [2], и хотите также передавать заголовок Host с помощью директивы proxy_set_header. [1] http://nginx.org/r/resolver/ru [2] http://nginx.org/r/error_log/ru [3] http://nginx.org/r/proxy_set_header/ru -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Jan 29 16:38:38 2013 From: nginx-forum at nginx.us (dizelbox) Date: Tue, 29 Jan 2013 11:38:38 -0500 Subject: =?UTF-8?B?UmU6IE5naW54INC4IG1vZCB6aXA6INC30LDQs9GA0YPQt9C60LAg0YTQsNC50Ls=?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: <201301292005.33130.vbart@nginx.com> References: <201301292005.33130.vbart@nginx.com> Message-ID: Установил bind9, прописал необходимые домены. Так как все сейчас работает локально, домены по бинду смотрят на localhost: nslookup file-server1.local Server: 127.0.1.1 Address: 127.0.1.1#53 ** server can't find file-server1.local: NXDOMAIN В конфиге nginx домена прописал: location ~* ^/remote/(.+?)/(.+)$ { internal; resolver 127.0.1.1; proxy_bind 127.0.1.1; proxy_set_header Host $proxy_host; proxy_set_header Connection close; proxy_hide_header Content-Type; proxy_pass http://$1/$2$is_args$args; } Все-равно не работает. Что я сделал не так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235693,235694#msg-235694 From vbart at nginx.com Tue Jan 29 16:52:03 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 29 Jan 2013 20:52:03 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICDQuCBtb2QgemlwOiDQt9Cw0LPRgNGD0LfQutCwINGE0LDQudC7?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: References: <201301292005.33130.vbart@nginx.com> Message-ID: <201301292052.03307.vbart@nginx.com> On Tuesday 29 January 2013 20:38:38 dizelbox wrote: > Установил bind9, прописал необходимые домены. Так как все сейчас работает > локально, домены по бинду смотрят на localhost: > > nslookup file-server1.local > Server: 127.0.1.1 > Address: 127.0.1.1#53 > > ** server can't find file-server1.local: NXDOMAIN > nslookup как бы говорит, что не находит такой домен NXDOMAIN - Non-eXistent DOMAIN -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html > В конфиге nginx домена прописал: > > location ~* ^/remote/(.+?)/(.+)$ { > internal; > resolver 127.0.1.1; > proxy_bind 127.0.1.1; > proxy_set_header Host $proxy_host; > proxy_set_header Connection close; > proxy_hide_header Content-Type; > proxy_pass http://$1/$2$is_args$args; > } > > Все-равно не работает. Что я сделал не так? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235693,235694#msg-235694 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Jan 29 17:43:47 2013 From: nginx-forum at nginx.us (dizelbox) Date: Tue, 29 Jan 2013 12:43:47 -0500 Subject: =?UTF-8?B?UmU6IE5naW54INC4IG1vZCB6aXA6INC30LDQs9GA0YPQt9C60LAg0YTQsNC50Ls=?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: <201301292052.03307.vbart@nginx.com> References: <201301292052.03307.vbart@nginx.com> Message-ID: Вот у меня вопрос в том и заключается, что мне нужно сделать, чтобы домен находился и nginx слал правильные запросы. Еще раз повторюсь: в bind9 пропсал домен и указал, что он смотрит на 127.0.0.1, в /etc/hosts прописал 127.0.0.1 file-server1.local, даже в /etc/resolv.conf прописал nameserver 127.0.0.1 domain file-server1.local В настройках домена указал опцию resolver 127.0.0.1, которая явно указывает через что необходимо определять ip-адреса по доменам. Nginx и bind9 перезагружал. Но nginx все-равно не может сделать корректные запросы. Что мне нужно поменять в данной схеме, что я делаю не так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235693,235697#msg-235697 From citrin at citrin.ru Tue Jan 29 17:48:23 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 29 Jan 2013 21:48:23 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC4IG1vZCB6aXA6INC30LDQs9GA0YPQt9C60LAg0YTQsNC50Ls=?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: References: <201301292052.03307.vbart@nginx.com> Message-ID: <51080B67.8070309@citrin.ru> On 01/29/13 21:43, dizelbox wrote: > в bind9 пропсал домен и указал, что он смотрит на 127.0.0.1, Раз nslookup отвечает NXDOMAIN, значит прописано не правильно. > в /etc/hosts прописал 127.0.0.1 file-server1.local, > даже в /etc/resolv.conf прописал > nameserver 127.0.0.1 > domain file-server1.local nginx не использует /etc/hosts и /etc/resolv.conf, настраивайте bind -- Anton Yuzhaninov From citrin at citrin.ru Tue Jan 29 17:50:16 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 29 Jan 2013 21:50:16 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC4IG1vZCB6aXA6INC30LDQs9GA0YPQt9C60LAg0YTQsNC50Ls=?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: <51080B67.8070309@citrin.ru> References: <201301292052.03307.vbart@nginx.com> <51080B67.8070309@citrin.ru> Message-ID: <51080BD8.6070000@citrin.ru> On 01/29/13 21:48, Anton Yuzhaninov wrote: >> > > nginx не использует /etc/hosts и /etc/resolv.conf, настраивайте bind Точнее не использует для динамического ресолвинга при использовании proxy_pass с переменными. Использует только в момент переконфигурации, если прописать proxy_pass http://file-server1.local; -- Anton Yuzhaninov From vbart at nginx.com Tue Jan 29 17:58:22 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 29 Jan 2013 21:58:22 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICDQuCBtb2QgemlwOiDQt9Cw0LPRgNGD0LfQutCwINGE0LDQudC7?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: References: <201301292052.03307.vbart@nginx.com> Message-ID: <201301292158.22804.vbart@nginx.com> On Tuesday 29 January 2013 21:43:47 dizelbox wrote: > Вот у меня вопрос в том и заключается, что мне нужно сделать, чтобы домен > находился и nginx слал правильные запросы. Еще раз повторюсь: > в bind9 пропсал домен и указал, что он смотрит на 127.0.0.1, > в /etc/hosts прописал 127.0.0.1 file-server1.local, > даже в /etc/resolv.conf прописал > nameserver 127.0.0.1 > domain file-server1.local > > > В настройках домена указал опцию resolver 127.0.0.1, которая явно указывает > через что необходимо определять ip-адреса по доменам. Nginx и bind9 > перезагружал. Но nginx все-равно не может сделать корректные запросы. > Что мне нужно поменять в данной схеме, что я делаю не так? > Если даже nslookup домен не находит, то видимо неправильно настроили bind9. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From stalker at altlinux.ru Tue Jan 29 19:48:00 2013 From: stalker at altlinux.ru (Anton Gorlov) Date: Tue, 29 Jan 2013 23:48:00 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC4IG1vZCB6aXA6INC30LDQs9GA0YPQt9C60LAg0YTQsNC50Ls=?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: References: <201301292052.03307.vbart@nginx.com> Message-ID: <51082770.7000701@altlinux.ru> 29.01.2013 21:43, dizelbox пишет: > В настройках домена указал опцию resolver 127.0.0.1, которая явно указывает > через что необходимо определять ip-адреса по доменам. Nginx и bind9 > перезагружал. Но nginx все-равно не может сделать корректные запросы. > Что мне нужно поменять в данной схеме, что я делаю не так? настроить ваш сервер dns что бы он вместо ** server can't find file-server1.local: NXDOMAIN Выдавал таки ip адрес для данного домена. Что у вас не верно настроено - не видя конфигов вашего сервера имён трудно сказать. Телепаты уволены в связи с недостаточностью бюджета. Да и не место здесь для обсуждения настроек dns-серверов. From trurl at mcbyte.net Tue Jan 29 19:55:48 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Tue, 29 Jan 2013 21:55:48 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <99f4b84f4cfd93ce2e5c6cf21947ae5c.NginxMailingListRussian@forum.nginx.org> References: <99f4b84f4cfd93ce2e5c6cf21947ae5c.NginxMailingListRussian@forum.nginx.org> Message-ID: 29 января 2013 г., 0:02 пользователь teo написал: > Вы опять пытаетесь смешать в кучу кеширование и этот параметр! > И в качестве доказательства приводите размер файла в кеше! > А если внимательно посмотреть? Я приводил размер файла в temp, по имени это сразу видно, у кешевых имя файла другое (и лежат они в другом месте). > И правильно! В кеше будет лежать весь файл целиком! > А как иначе? Откуда он возмет недостающий размер, если вы его "ограничили"? > Т.е. чтобы ограничить размер файла в кеше - единственный путь чтобы они > туда > не попадали! > А для этого у вас есть только proxy_no_cache с не пустым значением для > случая, когда ответ бекенда будет превышать некоторое ваше значение! > Сумеете > ли вы инициализировать такую переменную или нет - ваше дело и возможности > nginx. > А мне не надо по размеру кеша ограничивать, мне надо по размеру файла ) И этого я уже вполне себе добился. > Только proxy_max_temp_file_size ну ни каким боком не связан с кешированием > и > ограчением максимального размера файла в кеше. > И если непонятно, то просто прочтите его описание еще раз. > Внимательно перечитайте то письмо, из которого Вы выкинули непонятное Вам. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trurl at mcbyte.net Tue Jan 29 20:04:47 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Tue, 29 Jan 2013 22:04:47 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QstC10LTQtdC90LjQtSBleHBpcmVzINC/0YDQuCDQv9GA0L7QutGB?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: <1648575796.20130129114455@mtu-net.ru> References: <46a625ddc5ad8a3b9c4b6ac0916bc3c9.NginxMailingListRussian@forum.nginx.org> <487433850.20130122132255@mtu-net.ru> <1648575796.20130129114455@mtu-net.ru> Message-ID: 29 января 2013 г., 9:44 пользователь Andrey Repin написал: > TM> ломает при > TM> location ~ ^/d6/files/(.*)$ { > TM> proxy_pass http://filer_backend/drupal_share/files/$1; > TM> proxy_set_header Host "www"; > TM> expires 10m; > TM> } > > TM> версия старовата - nginx/0.8.53 > TM> но переход на новую потребует дофига работы - таких серверов много > > Это вы говорите, чтобы ничего не делать, или вы всё таки пробовали что-то > реально сделать?... > реально я в дополнение к expires просто ставлю потерянные хидеры, благо конкретный апстрим отдает только паблик данные. А вот кому-то другому это может вылезти боком. P.S. Хотя, судя по моему опыту, вообще мало кто из программеров в курсе разницы между "Cache-Control: public" и "Cache-Control: private". -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jan 29 21:18:28 2013 From: nginx-forum at nginx.us (teo) Date: Tue, 29 Jan 2013 16:18:28 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: <85733a9f612f23708521ab2a8e8c0878.NginxMailingListRussian@forum.nginx.org> Trurl Wrote: ------------------------------------------------------- > Внимательно перечитайте то письмо, из которого Вы выкинули непонятное > Вам. Я выкинул не непонятное, а то, что не имело отношение к делу. Еще раз перечитал - интересно каким образом можно восстановить какую именно директорию вы там сканируете если пути относительные? Пути во временной директории - ровно такие же, как и в том месте, куда они потом должны попасть - ну может быть сгенерены для другого ключа, хотя врядли. Если файл пишется во временную директорию, указанную при описании кеша - значит решение о помещении его в кеш уже принято, и не важно в данном случае - временная это директория или уже реальная. Хотя да, различие есть т.к. "расти" файл может только во временной директории - так что вы приводили сканирование именно временной директории. Только сути это не меняет. Я честно пытался 2ды объяснить - видимо не судьба. Остается уже спросить - а если вообще при описании локейшена не будет задано никаких кешей? То имеет ли смысл указание этого параметра или без кеша оно не имеет смысла? Можете ответить на этот вопрос сами себе - мне это уже не интересно. По-моему пора прекратить препирательства - я рад что вы нашли способ как побороть nginx в вашем случае. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235707#msg-235707 From trurl at mcbyte.net Wed Jan 30 02:23:19 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Wed, 30 Jan 2013 04:23:19 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <85733a9f612f23708521ab2a8e8c0878.NginxMailingListRussian@forum.nginx.org> References: <85733a9f612f23708521ab2a8e8c0878.NginxMailingListRussian@forum.nginx.org> Message-ID: 29 января 2013 г., 23:18 пользователь teo написал: > Я выкинул не непонятное, а то, что не имело отношение к делу. > Еще раз перечитал - интересно каким образом можно восстановить какую именно > директорию вы там сканируете если пути относительные? > по длине имени самого файла. В temp они короче. > Пути во временной директории - ровно такие же, как и в том месте, куда они > потом должны попасть - ну может быть сгенерены для другого ключа, хотя > врядли. > Если файл пишется во временную директорию, указанную при описании кеша - > значит решение о помещении его в кеш уже принято, и не важно в данном > случае > - временная это директория или уже реальная. Хотя да, различие есть т.к. > "расти" файл может только во временной директории - так что вы приводили > сканирование именно временной директории. Только сути это не меняет. > я всего лишь пытался показать, что параметр proxy_max_temp_file_size никакой роли не играет. Даже в кеш этот файл попасть не должен был, потому как max_size=5m. Но этот параметр тоже работает только задним числом и то не всегда. При скачивании очень больших файлов оные остаются в кеше очень на долго (не взирая на все ограничения), поскольку пока первый запросивший его стянет по своим медленным каналам - к тому времени появится еще один желающий стянуть тот же файл. В результате размер temp+кеша гарантировано больше proxy_max_temp_file_size+max_size, иногда в тысячи раз и до переполнения диска. То есть использование nginx на продакшене на сайтах с геобалансингом и большим количеством крупного контента сопряжено с серьезными рисками. > Я честно пытался 2ды объяснить - видимо не судьба. Остается уже спросить - > а > если вообще при описании локейшена не будет задано никаких кешей? > То имеет ли смысл указание этого параметра или без кеша оно не имеет > смысла? > Если бы он работал как вы описали - то да, имело бы смысл. > Можете ответить на этот вопрос сами себе - мне это уже не интересно. > По-моему пора прекратить препирательства - я рад что вы нашли способ как > побороть nginx в вашем случае. > Нормальный софт не надо бороть. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr at tverdikov.ru Wed Jan 30 04:04:33 2013 From: alexandr at tverdikov.ru (=?UTF-8?B?0KLQstC10YDQtNC40LrQvtCyINCQ0LvQtdC60YHQsNC90LTRgA==?=) Date: Wed, 30 Jan 2013 11:04:33 +0700 Subject: =?UTF-8?B?0J7Qs9GA0LDQvdC40YfQuNGC0Ywg0LTQvtGB0YLRg9C/INGH0LXRgNC10Lcgd2Vi?= =?UTF-8?B?ZGF2?= Message-ID: <51089BD1.7080901@tverdikov.ru> Добрый день! Настроил webdav согласно документации, как можно ограничить доступ по паролю? Конфиг: server { listen x.x.x.x:80; server_name webdav.name.ru; access_log /var/log/nginx/webdav.name.ru-access.log; error_log /var/log/nginx/webdav.name.ru-error.log; location / { root /var/www/webdav.name.ru; client_body_temp_path /var/www/webdav.name.ru/temp; dav_methods PUT DELETE MKCOL COPY MOVE; dav_ext_methods PROPFIND OPTIONS; create_full_put_path on; dav_access group:rw all:r; location ~ /\.ht { deny all; } } } -- ------------------------------ С уважением, Александр. Мои контакты: icq : 271715650 jabber: atverdikov at jabber.ru skype : ATverdikov ------------------------------ From igor at sysoev.ru Wed Jan 30 05:03:05 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 30 Jan 2013 09:03:05 +0400 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LjRgtGMINC00L7RgdGC0YPQvyDRh9C10YDQtdC3?= =?UTF-8?B?IHdlYmRhdg==?= In-Reply-To: <51089BD1.7080901@tverdikov.ru> References: <51089BD1.7080901@tverdikov.ru> Message-ID: On Jan 30, 2013, at 8:04 , Твердиков Александр wrote: > Добрый день! > Настроил webdav согласно документации, как можно ограничить доступ по паролю? > > Конфиг: > server { > listen x.x.x.x:80; > server_name webdav.name.ru; > > access_log /var/log/nginx/webdav.name.ru-access.log; > error_log /var/log/nginx/webdav.name.ru-error.log; > > location / { > root /var/www/webdav.name.ru; > > client_body_temp_path /var/www/webdav.name.ru/temp; > > dav_methods PUT DELETE MKCOL COPY MOVE; > dav_ext_methods PROPFIND OPTIONS; > > create_full_put_path on; > dav_access group:rw all:r; limit_except GET { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; } http://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except > > location ~ /\.ht { > deny all; > } > } > } -- Igor Sysoev http://nginx.com/support.html From hell-for-yahoo at umail.ru Wed Jan 30 06:28:57 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Wed, 30 Jan 2013 10:28:57 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC4IG1vZCB6aXA6INC30LDQs9GA0YPQt9C60LAg0YTQsNC50Ls=?= =?UTF-8?B?0L7QsiDRgSDQstC90LXRiNC90LjRhSDRgdC10YDQstC10YDQvtCyINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg0LjQvNC10L3QuCDQtNC+0Lw=?= =?UTF-8?B?0LXQvdCw?= In-Reply-To: References: <201301292052.03307.vbart@nginx.com> Message-ID: <812581798.20130130102857@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) dizelbox! d> Вот у меня вопрос в том и заключается, что мне нужно сделать, чтобы домен d> находился и nginx слал правильные запросы. Еще раз повторюсь: d> в bind9 пропсал домен и указал, что он смотрит на 127.0.0.1, d> в /etc/hosts прописал 127.0.0.1 file-server1.local, d> даже в /etc/resolv.conf прописал d> nameserver 127.0.0.1 d> domain file-server1.local d> В настройках домена указал опцию resolver 127.0.0.1, которая явно указывает d> через что необходимо определять ip-адреса по доменам. Nginx и bind9 d> перезагружал. Но nginx все-равно не может сделать корректные запросы. d> Что мне нужно поменять в данной схеме, что я делаю не так? Потому что домен .local не может быть обнаружен в DNS в нормально настроенной системе. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) среда, 30.01.2013, <10:28> From alexandr at tverdikov.ru Wed Jan 30 06:40:27 2013 From: alexandr at tverdikov.ru (=?UTF-8?B?0KLQstC10YDQtNC40LrQvtCyINCQ0LvQtdC60YHQsNC90LTRgA==?=) Date: Wed, 30 Jan 2013 13:40:27 +0700 Subject: =?UTF-8?Q?nginx-perl_=D0=B8_SPDY?= Message-ID: <5108C05B.5040408@tverdikov.ru> Добрый день! 1) А какое отличие между проектом https://github.com/zzzcpan/nginx-perl и nginx собранным с опцией |--with-http_perl_module ? 2) Можно ли для |https://github.com/zzzcpan/nginx-perl включить поддержку SPDY ? Может есть патч? -- ------------------------------ С уважением, Александр. Мои контакты: icq : 271715650 jabber: atverdikov at jabber.ru skype : ATverdikov ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Jan 30 09:30:18 2013 From: nginx-forum at nginx.us (teo) Date: Wed, 30 Jan 2013 04:30:18 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: Trurl Wrote: ------------------------------------------------------- > 29 января 2013 г., 23:18 пользователь teo > написал: > > > Я выкинул не непонятное, а то, что не имело отношение к делу. > > Еще раз перечитал - интересно каким образом можно восстановить какую > именно > > директорию вы там сканируете если пути относительные? > > > > по длине имени самого файла. В temp они короче. Не имею таких наблюдений, поэтому ничего сказать не могу. Хотя это косвенно подтверждает что для укладки в темп nginx использует не такой ключ, как для самого кеша - его право. > > Пути во временной директории - ровно такие же, как и в том месте, > куда они > > потом должны попасть - ну может быть сгенерены для другого ключа, > хотя > > врядли. > > Если файл пишется во временную директорию, указанную при описании > кеша - > > значит решение о помещении его в кеш уже принято, и не важно в > данном > > случае > > > - временная это директория или уже реальная. Хотя да, различие есть > т.к. > > "расти" файл может только во временной директории - так что вы > приводили > > сканирование именно временной директории. Только сути это не > меняет. > > > > я всего лишь пытался показать, что параметр proxy_max_temp_file_size > никакой роли не играет. И я о том же. Он вообще не для кеша. >Даже в кеш этот файл попасть не должен был, > потому > как max_size=5m. Цитата: The special process ?cache manager? monitors the maximum cache size set by the max_size parameter; when this size is exceeded it removes the least recently used data. Т.е. вы путаете размер всего кеша и размер конкретного файла в нем. И логика убирания файлов из кеша - не тех, что превышают ваш размер, а тех, кто наиболее редко использовался. И никто не гарантирует в какой момент это станет происходить. Потому что найти файл подлежащий удалению - в момент приема текущего запроса - это слишком накладно. Поэтому есть фоновый процесс, который "медленно спускается с горы и проверяет каждый -файл-". Т.ч. при огромном кеше вообще непонятно за какое время он сделает полный цикл. А у него есть еще ограничения по цпу одной итерации и время паузы. > Но этот параметр тоже работает только задним числом > и то > не всегда. При скачивании очень больших файлов оные остаются в кеше > очень > на долго (не взирая на все ограничения), поскольку пока первый > запросивший > его стянет по своим медленным каналам - к тому времени появится еще > один > желающий стянуть тот же файл. В результате размер temp+кеша > гарантировано > больше proxy_max_temp_file_size+max_size, иногда в тысячи раз и до > переполнения диска. То есть использование nginx на продакшене на > сайтах с > геобалансингом и большим количеством крупного контента сопряжено с > серьезными рисками. И я не знаю почему вы пытаетесь соотносить это с proxy_max_temp_file_size+max_size? Максимальный размер кеша задается в параметре keys_zone. И на моем опыте это еще ни разу не превысило указанный размер. Правда это на последней стабильной версии. > > > > Я честно пытался 2ды объяснить - видимо не судьба. Остается уже > спросить - > > а > > если вообще при описании локейшена не будет задано никаких кешей? > > То имеет ли смысл указание этого параметра или без кеша оно не > имеет > > смысла? > > > > Если бы он работал как вы описали - то да, имело бы смысл. > > > > Можете ответить на этот вопрос сами себе - мне это уже не > интересно. > > По-моему пора прекратить препирательства - я рад что вы нашли способ > как > > побороть nginx в вашем случае. > > > > Нормальный софт не надо бороть. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235723#msg-235723 From trurl at mcbyte.net Wed Jan 30 09:46:43 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Wed, 30 Jan 2013 11:46:43 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: 30 января 2013 г., 11:30 пользователь teo написал: > Trurl Wrote: > ------------------------------------------------------- > > 29 января 2013 г., 23:18 пользователь teo > > написал: > > > > > Я выкинул не непонятное, а то, что не имело отношение к делу. > > > Еще раз перечитал - интересно каким образом можно восстановить какую > > именно > > > директорию вы там сканируете если пути относительные? > > > > > > > по длине имени самого файла. В temp они короче. > > Не имею таких наблюдений, поэтому ничего сказать не могу. Хотя это косвенно > подтверждает что для укладки в темп nginx использует не такой ключ, как для > самого кеша - его право. > Вообще-то это в документации есть. > ... > > > > я всего лишь пытался показать, что параметр proxy_max_temp_file_size > > никакой роли не играет. > > И я о том же. Он вообще не для кеша. > Так и я не про кеш. Я про temp folder. > > >Даже в кеш этот файл попасть не должен был, > > потому > > как max_size=5m. > > Цитата: > The special process ?cache manager? monitors the maximum cache size set by > the max_size parameter; when this size is exceeded it removes the least > recently used data. > > Т.е. вы путаете размер всего кеша и размер конкретного файла в нем. > И логика убирания файлов из кеша - не тех, что превышают ваш размер, а тех, > кто наиболее редко использовался. > И никто не гарантирует в какой момент это станет происходить. Потому что > найти файл подлежащий удалению - в момент приема текущего запроса - это > слишком накладно. Поэтому есть фоновый процесс, который "медленно > спускается > с горы и проверяет каждый -файл-". > Т.ч. при огромном кеше вообще непонятно за какое время он сделает полный > цикл. А у него есть еще ограничения по цпу одной итерации и время паузы. > > Я не путаю. Я просто говорю про общую логику, а не про логику nginx. Согласитесь, что не логично пихать в кеш то, что немедленно оттуда должно быть выкинуто. > > > Но этот параметр тоже работает только задним числом > > и то > > не всегда. При скачивании очень больших файлов оные остаются в кеше > > очень > > на долго (не взирая на все ограничения), поскольку пока первый > > запросивший > > его стянет по своим медленным каналам - к тому времени появится еще > > один > > желающий стянуть тот же файл. В результате размер temp+кеша > > гарантировано > > больше proxy_max_temp_file_size+max_size, иногда в тысячи раз и до > > переполнения диска. То есть использование nginx на продакшене на > > сайтах с > > геобалансингом и большим количеством крупного контента сопряжено с > > серьезными рисками. > > И я не знаю почему вы пытаетесь соотносить это с > proxy_max_temp_file_size+max_size? > Максимальный размер кеша задается в параметре keys_zone. > И на моем опыте это еще ни разу не превысило указанный размер. Правда это > на > последней стабильной версии. > В этом же треде мне недавно доказывали обратное: > Размер keys_zone соотносится с размером кеша только опосредованно > (т.к. ограничивает максимальное число элементов, которое может > храниться в кеше). И в документации: > Кроме того, все активные ключи и информация о данных хранятся в зоне разделяемой памяти, *имя* и *размер* которой задаются параметром keys_zone. Видимо, таки баг где-то. Или в nginx, или в документации. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Jan 30 10:51:25 2013 From: nginx-forum at nginx.us (teo) Date: Wed, 30 Jan 2013 05:51:25 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: <398137f901dcbe95d2ec82edbf49b36b.NginxMailingListRussian@forum.nginx.org> Trurl Wrote: ------------------------------------------------------- > Так и я не про кеш. Я про temp folder. > Я не путаю. Я просто говорю про общую логику, а не про логику nginx. > Согласитесь, что не логично пихать в кеш то, что немедленно оттуда > должно > быть выкинуто. Но при этом вы же про temp folder, а не про кеш?? Не так ли? Но у temp folder двойное назначение! В него будут копироваться все ответы бекендов, если кол-во и размера буферов в ОЗУ нехватит, чтобы удовлетворить какой-то из запросов. Поэтому максимальный размер temp folder будет равен =сумма по всем активным запросам = {текущий запрос * размер ответа} (для всех ответов, которые превысили буфера в ОЗУ) при дефолтном размере proxy_max_temp_file_size = 1024m; и максимальном кол-ве запросов на одном IPv4 в 65536 у вас должно получиться 64Терра в самом худшем случае. Так что если у вас действительно есть вероятность забить HDD по самое небалуйся, то вам следует указать proxy_max_temp_file_size = 0; чтобы заставить nginx отдавать налету, без формирования временных файлов. Да, и нелогично предполагать, что любой файл в temp folder должен впоследствии обязательно попасть в кеш. > В этом же треде мне недавно доказывали обратное: А к чему вы тогда склоняетесь? К тому что написано в документации, или к тому, что кто-то сказал в треде? Я бы игнорировал замечания в треде, если они противоречат документации. И заблуждению что keys_zone ограничивает максимальное кол-во ключей вобщем-то даже объяснимо, т.к. действительно есть другие параметры, где указанный размер косвенное ограничивает число ключей, хотя сначала все равно фактический размер памяти. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235726#msg-235726 From mdounin at mdounin.ru Wed Jan 30 10:55:39 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 30 Jan 2013 14:55:39 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: Message-ID: <20130130105539.GC40753@mdounin.ru> Hello! On Wed, Jan 30, 2013 at 11:46:43AM +0200, Trurl McByte wrote: [...] > > > я всего лишь пытался показать, что параметр proxy_max_temp_file_size > > > никакой роли не играет. > > > > И я о том же. Он вообще не для кеша. > > > > Так и я не про кеш. Я про temp folder. При кешировании все ещё не полностью полученные ответы - сохраняются в proxy_temp_path. И только после того, как ответ полностью получен - соответствующий файл переименовывается в соответствующее место в каталоге кеша. Каталог, задаваемый директивой proxy_temp_path - один и тот же и для кеша, и для proxy_store, и для просто проксирования. Значение proxy_max_temp_file_size - учитывается только при обычном проксировании. Отличить временные файлы для обычного проксирования и временные файлы, которые сохраняются на диск, чтобы попасть в кеш или сохраниться на диск через proxy_store, очень просто: временные файлы, создаваемые при обычном проксировании, сразу удаляются, и в листинге каталога видны не будут. -- Maxim Dounin http://nginx.com/support.html From vbart at nginx.com Wed Jan 30 11:23:13 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 30 Jan 2013 15:23:13 +0400 Subject: =?UTF-8?Q?Re=3A_nginx-perl_=D0=B8_SPDY?= In-Reply-To: <5108C05B.5040408@tverdikov.ru> References: <5108C05B.5040408@tverdikov.ru> Message-ID: <201301301523.13384.vbart@nginx.com> On Wednesday 30 January 2013 10:40:27 Твердиков Александр wrote: > Добрый день! > 1) А какое отличие между проектом https://github.com/zzzcpan/nginx-perl > и nginx собранным с опцией |--with-http_perl_module ? Модуль по ссылке, в отличии от поставляемого с nginx, сторонняя разработка и поддерживается силами его автора. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html > 2) Можно ли для |https://github.com/zzzcpan/nginx-perl включить > поддержку SPDY ? Может есть патч? From alexandr at tverdikov.ru Wed Jan 30 14:14:31 2013 From: alexandr at tverdikov.ru (=?KOI8-R?Q?=F4=D7=C5=D2=C4=C9=CB=CF=D7_=E1=CC=C5=CB=D3=C1=CE=C4=D2?=) Date: Wed, 30 Jan 2013 21:14:31 +0700 Subject: =?UTF-8?Q?Re=3A_nginx-perl_=D0=B8_SPDY?= In-Reply-To: <201301301523.13384.vbart@nginx.com> References: <5108C05B.5040408@tverdikov.ru> <201301301523.13384.vbart@nginx.com> Message-ID: <51092AC7.1000509@tverdikov.ru> Я понимаю, но отличие именно по возможностям есть? В частности встроенный нативный в nginx perl что нибудь из этого не умеет? FEATURES - full official nginx perl API; - asynchronous connections (ngx_connector, ngx_reader, ngx_writer); - timer (ngx_timer); - SSL (ngx_ssl_handshaker); - resolver (ngx_resolver); - access handlers (perl_access); - app handlers (perl_app); - configuration level eval (perl_eval); - init_worker, exit_worker handlers (perl_init_worker, perl_exit_worker); - logging functions (ngx_log_*); - client connection takeover for websockets, etc; ------------------------------ С уважением, Александр. Мои контакты: icq : 271715650 jabber: atverdikov at jabber.ru skype : ATverdikov ------------------------------ 30.01.2013 18:23, Валентин Бартенев пишет: > On Wednesday 30 January 2013 10:40:27 Твердиков Александр wrote: >> Добрый день! >> 1) А какое отличие между проектом https://github.com/zzzcpan/nginx-perl >> и nginx собранным с опцией |--with-http_perl_module ? > Модуль по ссылке, в отличии от поставляемого с nginx, сторонняя разработка и > поддерживается силами его автора. > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > > >> 2) Можно ли для |https://github.com/zzzcpan/nginx-perl включить >> поддержку SPDY ? Может есть патч? > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Wed Jan 30 15:08:10 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 30 Jan 2013 19:08:10 +0400 Subject: =?UTF-8?Q?Re=3A_nginx-perl_=D0=B8_SPDY?= In-Reply-To: <5108C05B.5040408@tverdikov.ru> References: <5108C05B.5040408@tverdikov.ru> Message-ID: <859955508.20130130190810@softsearch.ru> Здравствуйте, Твердиков. > https://github.com/zzzcpan/nginx-perl Он вроде побыстрее за счёт меньшего числа копирований между nginx-ом и перлом. Автор разговаривает на русском и его можно найти с листе moscow-pm at pm.org -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Wed Jan 30 17:30:40 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 30 Jan 2013 21:30:40 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <398137f901dcbe95d2ec82edbf49b36b.NginxMailingListRussian@forum.nginx.org> References: <398137f901dcbe95d2ec82edbf49b36b.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130130173040.GI40753@mdounin.ru> Hello! On Wed, Jan 30, 2013 at 05:51:25AM -0500, teo wrote: [...] > ... и максимальном кол-ве запросов на одном IPv4 в 65536 ... Безотносительно к остальному тексту - вот это вот достаточно частно встречающееся заблуждение, поэтому слегка потопчусь, дабы развеять/прояснить. Нет ограничения в 64k соединений на адрес. Есть ограничение уникальность комбинации src_ip:src_port:dst_ip:dst_port. И из него следует, что при фиксированных dst_ip, dst_port (т.е. ip сервера, и порт 80) - остаётся два свободных параметра, src_ip и src_port. Если мы зафиксируем вдобавок ещё и src_ip - то, действительно, у нас останется для варьирования только src_port, и больше 64k соединенией никак не открыть. Но - это так только при фиксированном src_ip, т.е. от _одного_ клиента. Если же клиентов много (а у типичного веб-сервера их много) - то соединений может быть сколько угодно (до 64k от каждого клиента). Об ограничении в 64k соединений в основном имеет смысл говорить при проксировании между одним фронтендом и одним бекендом. Это как раз тот случай, когда src_ip - фиксирован. Но это - совсем отдельный случай, хотя и важный. И ограничение в 64k соединений в этом случае - легко обходится как добавлением ip-адресов бекенду, так и фронтенду. [...] > > В этом же треде мне недавно доказывали обратное: > > А к чему вы тогда склоняетесь? К тому что написано в документации, или к > тому, что кто-то сказал в треде? > Я бы игнорировал замечания в треде, если они противоречат документации. > И заблуждению что keys_zone ограничивает максимальное кол-во ключей > вобщем-то даже объяснимо, т.к. действительно есть другие параметры, где > указанный размер косвенное ограничивает число ключей, хотя сначала все равно > фактический размер памяти. Самокритично. :) Документации (и реальности) противотиворечит ваше утверждение, что размер кеша на диске ограничивается параметром keys_zone. Параметр keys_zone - не ограничивает размер кеша (на диске), он определяет размер области разделяемой памяти, которая отводится для хранения ключей (и соответственно косвенно определяет максимально возможное число ключей к кеше). http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path -- Maxim Dounin http://nginx.com/support.html From fx25 at mail.ru Wed Jan 30 17:56:43 2013 From: fx25 at mail.ru (=?UTF-8?B?Lg==?=) Date: Wed, 30 Jan 2013 21:56:43 +0400 Subject: nginx perl module Message-ID: <1359568603.42734321@f373.mail.ru> Добрый день, интересует вопрос установки nginx perl модуля. Подскажите как пересобрать perl  на сервере с Debian 6. Я  хочу чтобы все уже имеющийся в системе модули perl были переустановлены при пересборке perl, чтобы всё работало без конфликтов (до этого perl  ставился из пакетов). -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at symbi.org Wed Jan 30 20:48:43 2013 From: konstantin at symbi.org (Konstantin Baryshnikov) Date: Thu, 31 Jan 2013 00:48:43 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCDQr9C90LTQtdC60YEt0KLRg9GA0LHQvg==?= In-Reply-To: <5107E611.8050200@ipfw.ru> References: <16410348687.20130126174210@softsearch.ru> <5107C8E7.3030508@citrin.ru> <1445081436.20130129184733@softsearch.ru> <5107E611.8050200@ipfw.ru> Message-ID: <931546CA-5690-4633-9E19-ED053915DD15@symbi.org> Здравствуйте! On Jan 29, 2013, at 7:09 PM, Alexander V. Chernikov wrote: > На данный момент как-то так: > > 5.45.192.64/26 > 5.45.255.64/26 > 141.8.189.192/27 > 37.140.189.192/26 > > В будущем, разумеется, эти диапазоны могут (и будут) меняться. Спасибо за информацию. Можно ли надеяться, что список подсетей будет когда-нибудь размещен (и поддерживаться в актуальном виде) на официальном сайте? Такую информацию хотелось бы иметь из первых рук. From nginx-forum at nginx.us Wed Jan 30 20:54:32 2013 From: nginx-forum at nginx.us (teo) Date: Wed, 30 Jan 2013 15:54:32 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <20130130173040.GI40753@mdounin.ru> References: <20130130173040.GI40753@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Нет ограничения в 64k соединений на адрес. Есть ограничение > уникальность комбинации src_ip:src_port:dst_ip:dst_port. И из него Да, действительно 4ке, соглашусь. Хотя и бекенд, способный в одиночку отдавать больше 64к запросов одновременно еще надо поискать. > Самокритично. :) Все могут ошибаться ))) Чем я хуже других? )) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235634,235755#msg-235755 From trurl at mcbyte.net Thu Jan 31 02:44:50 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Thu, 31 Jan 2013 04:44:50 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: <20130130173040.GI40753@mdounin.ru> References: <398137f901dcbe95d2ec82edbf49b36b.NginxMailingListRussian@forum.nginx.org> <20130130173040.GI40753@mdounin.ru> Message-ID: 30 января 2013 г., 19:30 пользователь Maxim Dounin написал: > Hello! > > On Wed, Jan 30, 2013 at 05:51:25AM -0500, teo wrote: > > [...] > > > ... и максимальном кол-ве запросов на одном IPv4 в 65536 ... > > Безотносительно к остальному тексту - вот это вот достаточно > частно встречающееся заблуждение, поэтому слегка потопчусь, дабы > развеять/прояснить. > > Нет ограничения в 64k соединений на адрес. Есть ограничение > уникальность комбинации src_ip:src_port:dst_ip:dst_port. И из него > следует, что при фиксированных dst_ip, dst_port (т.е. ip сервера, > и порт 80) - остаётся два свободных параметра, src_ip и src_port. > > Если мы зафиксируем вдобавок ещё и src_ip - то, действительно, у > нас останется для варьирования только src_port, и больше 64k > соединенией никак не открыть. Но - это так только при > фиксированном src_ip, т.е. от _одного_ клиента. > > Если же клиентов много (а у типичного веб-сервера их много) - то > соединений может быть сколько угодно (до 64k от каждого клиента). > > Об ограничении в 64k соединений в основном имеет смысл говорить при > проксировании между одним фронтендом и одним бекендом. Это как раз тот > случай, когда src_ip - фиксирован. Но это - совсем отдельный > случай, хотя и важный. И ограничение в 64k соединений в этом > случае - легко обходится как добавлением ip-адресов бекенду, так и > фронтенду. > у меня 7 бекендов и 4 фронтенда, каждый из 4х связан с каждым из 7ми, 448к получается на каждом ) > [...] > > > > В этом же треде мне недавно доказывали обратное: > > > > А к чему вы тогда склоняетесь? К тому что написано в документации, или к > > тому, что кто-то сказал в треде? > > Я бы игнорировал замечания в треде, если они противоречат документации. > > И заблуждению что keys_zone ограничивает максимальное кол-во ключей > > вобщем-то даже объяснимо, т.к. действительно есть другие параметры, где > > указанный размер косвенное ограничивает число ключей, хотя сначала все > равно > > фактический размер памяти. > > Самокритично. :) > > Документации (и реальности) противотиворечит ваше утверждение, что > размер кеша на диске ограничивается параметром keys_zone. > Весь прикол в том что реальности оно, вроде бы как, не противоречит. Если keys_zone больше max_size - то действительно кеш почему-то держится строго в рамках keys_zone. ) > > Параметр keys_zone - не ограничивает размер кеша (на диске), он > определяет размер области разделяемой памяти, которая отводится > для хранения ключей (и соответственно косвенно определяет > максимально возможное число ключей к кеше). > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path > > -- > Maxim Dounin > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trurl at mcbyte.net Thu Jan 31 02:51:36 2013 From: trurl at mcbyte.net (Trurl McByte) Date: Thu, 31 Jan 2013 04:51:36 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0L/QvtC90Y/RgtGMINC70L7Qs9C40LrRgyA=?= =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNC90LjRjyDQuCDQsdGD0YTQtdGA0LjQt9Cw0YY=?= =?UTF-8?B?0LjQuA==?= In-Reply-To: References: <20130130173040.GI40753@mdounin.ru> Message-ID: 30 января 2013 г., 22:54 пользователь teo написал: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Нет ограничения в 64k соединений на адрес. Есть ограничение > > уникальность комбинации src_ip:src_port:dst_ip:dst_port. И из него > > Да, действительно 4ке, соглашусь. > Хотя и бекенд, способный в одиночку отдавать больше 64к запросов > одновременно еще надо поискать. > Узкозаточенные приложения (например, только определение геоданных по IP или отдача policy) вполне способны на такое. То есть особенно там, где не надо разбирать запрос пользователя :) > > > Самокритично. :) > > Все могут ошибаться ))) Чем я хуже других? )) > Я собственно ради того, чтоб разобраться в этих не понятках и затеял этот топик. Но, как говорится, многие знания - многие печали. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,235634,235755#msg-235755 > > _______________________________________________ > 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 Thu Jan 31 09:29:10 2013 From: nginx-forum at nginx.us (kitius) Date: Thu, 31 Jan 2013 04:29:10 -0500 Subject: =?UTF-8?B?0L3QsNGB0YLRgNC+0LnQutCwINC00L7RgdGC0YPQv9CwINC6INGB0LDQudGC0YMg?= =?UTF-8?B?0L/QviBHZW9JUA==?= Message-ID: <26ba756f3bb2abf2b969c14506b21928.NginxMailingListRussian@forum.nginx.org> Приветствую. Задача: настроить доступ по GeoIP к сайту для отдачи статики (без проксирования) только ессесно для нужных стран. Дано: nginx + apache (back-end), 2 сайта с отдельными конфигами в conf/vhost и отдельный ессесно nginx.conf. Видел вариант настройки через nginx.conf внутри http секции, но это не подходит, т.к. нужно ограничить доступ к определенной папке на одном из сайтов, второй сайт и остальные папки на первом должны быть доступны для всех. Через allow/deny слишком много подсетей писать, не хочется нагружать конфиг. Как быть? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235765,235765#msg-235765 From citrin at citrin.ru Thu Jan 31 09:39:42 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu, 31 Jan 2013 13:39:42 +0400 Subject: =?UTF-8?B?UmU6INC90LDRgdGC0YDQvtC50LrQsCDQtNC+0YHRgtGD0L/QsCDQuiDRgdCw0Lk=?= =?UTF-8?B?0YLRgyDQv9C+IEdlb0lQ?= In-Reply-To: <26ba756f3bb2abf2b969c14506b21928.NginxMailingListRussian@forum.nginx.org> References: <26ba756f3bb2abf2b969c14506b21928.NginxMailingListRussian@forum.nginx.org> Message-ID: <510A3BDE.5020502@citrin.ru> On 01/31/13 13:29, kitius wrote: > Через allow/deny слишком много подсетей писать, не хочется нагружать > конфиг. > Как быть? map $geoip_country_code $bad_country { default 1; RU 0; UA 0; ... } ... location /content/restricted { if ($bad_country) { return 403; } } -- Anton Yuzhaninov From nginx-forum at nginx.us Thu Jan 31 10:08:10 2013 From: nginx-forum at nginx.us (InventOR) Date: Thu, 31 Jan 2013 05:08:10 -0500 Subject: =?UTF-8?B?bmdpbngrc3NpK3JlZGlzIGx1YSDRgdGC0YDQsNC90L3QvtC1INC/0L7QstC10LQ=?= =?UTF-8?B?0LXQvdC40LU=?= Message-ID: <65ef954df3475fd7244138a958ac8c52.NginxMailingListRussian@forum.nginx.org> в конфиге хоста стоит: ssi on; сделан локейшн: [code] location / { index index.php; try_files $uri $uri/ /index.php?$args; } location ~ ^/system/templates/(?