From nginx-forum at nginx.us Thu Aug 1 02:13:34 2013 From: nginx-forum at nginx.us (icecola321) Date: Wed, 31 Jul 2013 22:13:34 -0400 Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBlcnJvciBwYWdlIDQwNQ==?= In-Reply-To: <51ED9D5E.9030003@kpi.ua> References: <51ED9D5E.9030003@kpi.ua> Message-ID: Find a suitable for your stuff will have a sense of accomplishment that can come efox look, there may be something you want Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241125,241431#msg-241431 From admin at sysadmins.el.kg Thu Aug 1 02:41:23 2013 From: admin at sysadmins.el.kg (admin at sysadmins.el.kg) Date: Thu, 01 Aug 2013 08:41:23 +0600 Subject: Nginx and logrotate In-Reply-To: <51F97C94.30303@itcraft.org> References: <51F97C94.30303@itcraft.org> Message-ID: <51F9CAD3.8020104@sysadmins.el.kg> 01.08.2013 03:07, Sergey Kobzar пишет: > Linux 3.8.13-gentoo x86_64 > nginx-1.4.1-r2 > logrotate-3.8.4 > > cat /etc/logrotate.d/nginx: > /var/log/nginx/*.log { > daily > rotate 5 > missingok > nocompress > sharedscripts > postrotate > test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid` > endscript > } > > /etc/logrotate.conf: > weekly > rotate 4 > create > dateext > compress > notifempty > nomail > noolddir > include /etc/logrotate.d > /var/log/wtmp { > monthly > create 0664 root utmp > minsize 1M > rotate 1 > } > /var/log/btmp { > missingok > monthly > create 0600 root utmp > rotate 1 > } > > # ls -alh /var/log/nginx/ | grep access.log > -rw-r--r-- 1 nginx root 0 Jul 30 03:10 access.log > -rw-r--r-- 1 nginx root 4.7G Jul 18 10:09 access.log-20130712 > -rw-r--r-- 1 nginx root 7.6G Jul 29 09:46 access.log-20130719 > -rw-r--r-- 1 nginx root 1.4G Jul 31 22:04 access.log-20130730 > > Т.е. запись в access.log не идет, а растет access.log-20130730. > > kill -USR1 `cat /run/nginx.pid` ситуацию не меняет. > > Что я не так? > > Спасибо. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru У меня (RHEL 6) в качестве postrotate-команды используется эта: /etc/init.d/nginx reload > /dev/null 2>/dev/null || true в скрипте /etc/init.d/nginx в функции отвечающей за reload используется killproc $nginx -HUP Попробуйте сменить -USR1 в вашей команде на -HUP? Вот так это выглядит целиком: /var/log/nginx/*log { missingok compress notifempty sharedscripts postrotate /sbin/service nginx reload > /dev/null 2>/dev/null || true endscript } From sergey.kobzar at itcraft.org Thu Aug 1 07:27:39 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Thu, 01 Aug 2013 10:27:39 +0300 Subject: Nginx and logrotate In-Reply-To: <201308010214.30476.vbart@nginx.com> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> Message-ID: <51FA0DEB.9050908@itcraft.org> Валентин, спасибо On 08/01/13 01:14, Валентин Бартенев wrote: > > https://bugs.gentoo.org/show_bug.cgi?id=473036 > 1. upstream explained it and accepted the bug report, this is now on their todo-list - это действительно так? 2. # la /var/log/ | grep nginx drwxr-x--- 2 root root 12K Aug 1 03:10 nginx Т.е. фикс должен быть вида chown nginx /var/log/nginx? 3. Какой сигнал при ротации все же правильнее слать? From sergey.kobzar at itcraft.org Thu Aug 1 07:34:12 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Thu, 01 Aug 2013 10:34:12 +0300 Subject: Nginx and logrotate In-Reply-To: <51F9CAD3.8020104@sysadmins.el.kg> References: <51F97C94.30303@itcraft.org> <51F9CAD3.8020104@sysadmins.el.kg> Message-ID: <51FA0F74.4030308@itcraft.org> On 08/01/13 05:41, admin at sysadmins.el.kg wrote: > У меня (RHEL 6) в качестве postrotate-команды используется эта: > /etc/init.d/nginx reload > /dev/null 2>/dev/null || true > в скрипте /etc/init.d/nginx в функции отвечающей за reload используется > killproc $nginx -HUP > > Попробуйте сменить -USR1 в вашей команде на -HUP? > Вот так это выглядит целиком: > /var/log/nginx/*log { > missingok > compress > notifempty > sharedscripts > postrotate > /sbin/service nginx reload > /dev/null 2>/dev/null || true > endscript > } Хочется услышать мнение разработчиков, какой сингал правильнее посылать при ротации логов. Перестартовать мастер процесс - как-то не фонтан при high load. From nginx-forum at nginx.us Thu Aug 1 08:13:32 2013 From: nginx-forum at nginx.us (Antohat) Date: Thu, 01 Aug 2013 04:13:32 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?= =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?= In-Reply-To: <20130731105908.GI96850@lo0.su> References: <20130731105908.GI96850@lo0.su> Message-ID: Ruslan Ermilov Wrote: > Что ж бедному nginx, на каждый чих это проверять? Ведь сейчас > может быть не настроен, а через минуту уже настроен. Проксирование на домен (без апстрима) вроде бы работает корректно (по крайней мере ошибки в лог больше не пишутся). Т.е. не такая уж это большая проблема, определять поддержку IPv6. С распространением IPv6 описанная в топике проблема, когда апстрим поддерживает IPv6, а сервер с Nginx'ом нет, будет все более актуальна. Проблема конечно решается самостоятельной сборкой nginx, но это решение не соответствует стратегии более широкого распространения продукта. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241405,241444#msg-241444 From boris at talovikov.ru Thu Aug 1 08:21:21 2013 From: boris at talovikov.ru (boris at talovikov.ru) Date: Thu, 01 Aug 2013 14:21:21 +0600 Subject: Nginx and logrotate In-Reply-To: <51FA0F74.4030308@itcraft.org> References: <51F97C94.30303@itcraft.org> <51F9CAD3.8020104@sysadmins.el.kg> <51FA0F74.4030308@itcraft.org> Message-ID: <646141375345281@web2f.yandex.ru> 01.08.2013, 13:34, "Sergey Kobzar" : > On 08/01/13 05:41, admin at sysadmins.el.kg wrote: > >>  У меня (RHEL 6) в качестве postrotate-команды используется эта: >>  /etc/init.d/nginx reload > /dev/null 2>/dev/null || true >>  в скрипте /etc/init.d/nginx в функции отвечающей за reload используется >>  killproc $nginx -HUP >> >>  Попробуйте сменить -USR1 в вашей команде на -HUP? >>  Вот так это выглядит целиком: >>  /var/log/nginx/*log { >>  missingok >>  compress >>  notifempty >>  sharedscripts >>  postrotate >>       /sbin/service nginx reload > /dev/null 2>/dev/null || true >>  endscript >>  } > > Хочется услышать мнение разработчиков, какой сингал правильнее посылать > при ротации логов. Перестартовать мастер процесс - как-то не фонтан при > high load. мнение разработчиков можно узнать, прочитав nginx(8) nginx -s reopen - переоткроет логи From mdounin at mdounin.ru Thu Aug 1 09:20:22 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 1 Aug 2013 13:20:22 +0400 Subject: Nginx and logrotate In-Reply-To: <51FA0DEB.9050908@itcraft.org> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> Message-ID: <20130801092021.GZ2130@mdounin.ru> Hello! On Thu, Aug 01, 2013 at 10:27:39AM +0300, Sergey Kobzar wrote: > Валентин, спасибо > > On 08/01/13 01:14, Валентин Бартенев wrote: > > > > >https://bugs.gentoo.org/show_bug.cgi?id=473036 > > > > 1. upstream explained it and accepted the bug report, this is now on > their todo-list - это действительно так? Ребята в очередной раз пришли с идеей, что надо не переоткрывать логи рабочими процессами, а посылать им открытый файловый дескриптор из мастера. Это часть посылать была accepted, т.к. в trac'е у нас её до сих пор не было (вопрос обсуждался столько раз, что даже и в голову никому не приходило заводить это в trac'е). Всё остальное - было explained. http://trac.nginx.org/nginx/ticket/376 > 2. # la /var/log/ | grep nginx > > drwxr-x--- 2 root root 12K Aug 1 03:10 nginx > > Т.е. фикс должен быть вида chown nginx /var/log/nginx? Да. > 3. Какой сигнал при ротации все же правильнее слать? USR1 - правильный сигнал, предназначенный специально для ротации логов. -- Maxim Dounin http://nginx.org/en/donation.html From sergey.kobzar at itcraft.org Thu Aug 1 09:22:59 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Thu, 01 Aug 2013 12:22:59 +0300 Subject: Nginx and logrotate In-Reply-To: <20130801092021.GZ2130@mdounin.ru> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> <20130801092021.GZ2130@mdounin.ru> Message-ID: <51FA28F3.9090303@itcraft.org> On 08/01/13 12:20, Maxim Dounin wrote: > Hello! > > On Thu, Aug 01, 2013 at 10:27:39AM +0300, Sergey Kobzar wrote: > >> Валентин, спасибо >> >> On 08/01/13 01:14, Валентин Бартенев wrote: >> >>> >>> https://bugs.gentoo.org/show_bug.cgi?id=473036 >>> >> >> 1. upstream explained it and accepted the bug report, this is now on >> their todo-list - это действительно так? > > Ребята в очередной раз пришли с идеей, что надо не переоткрывать > логи рабочими процессами, а посылать им открытый файловый > дескриптор из мастера. Это часть посылать была accepted, т.к. в > trac'е у нас её до сих пор не было (вопрос обсуждался столько раз, > что даже и в голову никому не приходило заводить это в trac'е). > Всё остальное - было explained. > > http://trac.nginx.org/nginx/ticket/376 > >> 2. # la /var/log/ | grep nginx >> >> drwxr-x--- 2 root root 12K Aug 1 03:10 nginx >> >> Т.е. фикс должен быть вида chown nginx /var/log/nginx? > > Да. > >> 3. Какой сигнал при ротации все же правильнее слать? > > USR1 - правильный сигнал, предназначенный специально для ротации > логов. Максим, спасибо большое за ответ. From ru at nginx.com Thu Aug 1 09:39:31 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Thu, 1 Aug 2013 13:39:31 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?= =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?= In-Reply-To: References: <20130731105908.GI96850@lo0.su> Message-ID: <20130801093931.GS96850@lo0.su> On Thu, Aug 01, 2013 at 04:13:32AM -0400, Antohat wrote: > Ruslan Ermilov Wrote: > > Что ж бедному nginx, на каждый чих это проверять? Ведь сейчас > > может быть не настроен, а через минуту уже настроен. > > Проксирование на домен (без апстрима) вроде бы работает корректно (по > крайней мере ошибки в лог больше не пишутся). Т.е. не такая уж это большая > проблема, определять поддержку IPv6. Вы имеете в виду вариант proxy_pass http://download.exmaple.com ? Если да, та разницы никакой нет. В этом случае все IP-адреса (включая IPv6) будут также определены единожды на этапе чтения конфигурации, после чего все адреса будут использоваться в режиме round-robin, как и документировано [1]: : Если доменному имени соответствует несколько адресов, то : все они будут использоваться по очереди (round-robin). : Кроме того, в качестве адреса можно указать группу серверов. [1] http://nginx.org/r/proxy_pass/ru Вот живой пример: server { location / { proxy_pass http://lo0.su; } } Из error_log'а, запросы раз в секунду: 2013/08/01 11:05:22 [error] 12561#0: *3 connect() to [2a01:4f8:a0:1064::2]:80 failed (101: Network is unreachable) while connecting to upstream, client: 127.0.0.1, server: , request: "HEAD / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:80/", host: "127.0.0.1:8000" 2013/08/01 11:05:35 [error] 12561#0: *30 connect() to [2a01:4f8:a0:1064::2]:80 failed (101: Network is unreachable) while connecting to upstream, client: 127.0.0.1, server: , request: "HEAD / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:80/", host: "127.0.0.1:8000" 2013/08/01 11:05:48 [error] 12561#0: *55 connect() to [2a01:4f8:a0:1064::2]:80 failed (101: Network is unreachable) while connecting to upstream, client: 127.0.0.1, server: , request: "HEAD / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:80/", host: "127.0.0.1:8000" То есть 1-й запрос идёт на IPv4-адрес, 2-й - на IPv6, далее начинает действовать max_fails=1 и fail_timeout=10 для неявных апстримов и IPv6-адрес временно не используется, спустя ~10 секунд снова пробный запрос на IPv6, и т.д. nginx version: nginx/1.4.2 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) configure arguments: --with-debug --with-ipv6 > С распространением IPv6 описанная в топике проблема, когда апстрим > поддерживает IPv6, а сервер с Nginx'ом нет, будет все более актуальна. Проблема, если она и есть, не в nginx. Ваш nginx собран с поддержкой IPv6, значит при резолвинге имён, как и любая другая прикладная программа, он получает и IPv4-, и IPv6-адреса. > Проблема конечно решается самостоятельной сборкой nginx, но это решение не > соответствует стратегии более широкого распространения продукта. Не существует универсального способа узнать, что на системе выключен IPv6. Кроме того, выключенность IPv6 - это не постоянное состояние. Не возвращать IPv6-адреса при резолвинге имён, если в системе не сконфигурирован IPv6, это в общем случае неправильное поведение. С другой стороны, во многих прикладных программах доступны опции командной строки -4 и -6, которые заставляют программу использовать только IPv4- или только IPv6-адреса. Я подумаю в эту сторону. From nginx-forum at nginx.us Thu Aug 1 11:06:26 2013 From: nginx-forum at nginx.us (jm) Date: Thu, 01 Aug 2013 07:06:26 -0400 Subject: =?UTF-8?B?Q9C60LDRh9C40LLQsNGO0YLRgdGPIHBocCDRhNCw0LnQu9GL?= Message-ID: Привет, настроил по этой инструкции - http://forum.ubuntu.ru/index.php?topic=70057.0 домен, и при переходе например по ссылке domain2.com/info.php предлагается сохранить php файл. В access.log пишет 127.0.0.1 - - [31/Jul/2013:23:01:46 +0300] "GET /info.php HTTP/1.1" 200 128 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0" Вот /etc/ngnix/sites-available/domain2.com server { listen 80; server_name www.domain2.com; rewrite ^/(.*) http://domain2.com/$1 permanent; } server { listen 80; server_name domain2.com; access_log /home/jm/public_html/domain2.com/log/access.log; error_log /home/jm/public_html/domain2.com/log/error.log; location / { root /home/jm/public_html/domain2.com/public/; index index.php index.html index.htm; } } localhost/info.php работает нормально, настраивал по этой инструкции - http://www.howtoforge.com/installing-nginx-with-php5-and-php-fpm-and-mysql-support-lemp-on-ubuntu-13.04 В access.log пишет 127.0.0.1 - - [01/Aug/2013:13:29:58 +0300] "GET /info.php?jhjh HTTP/1.1" 200 13436 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0" 127.0.0.1 - - [01/Aug/2013:13:29:58 +0300] "GET /info.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2536 "http://localhost/info.php?jhjh" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0" 127.0.0.1 - - [01/Aug/2013:13:29:58 +0300] "GET /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2158 "http://localhost/info.php?jhjh" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0" 127.0.0.1 - - [01/Aug/2013:13:30:04 +0300] "-" 400 0 "-" "-" Вот /etc/ngnix/sites-available/default server { listen 80; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.php index.html index.htm; server_name _; location / { try_files $uri $uri/ /index.html; } location /doc/ { alias /usr/share/doc/; autoindex on; allow 127.0.0.1; allow ::1; deny all; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; } location ~ /\.ht { deny all; } } помогите найти где ошибка может быть Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241460,241460#msg-241460 From dmitriy at lyalyuev.info Thu Aug 1 11:19:20 2013 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Thu, 01 Aug 2013 14:19:20 +0300 Subject: =?UTF-8?B?UmU6IEPQutCw0YfQuNCy0LDRjtGC0YHRjyBwaHAg0YTQsNC50LvRiw==?= In-Reply-To: References: Message-ID: <51FA4438.10900@lyalyuev.info> В первом случае нет проксирования на обработчик php - fastcgi. Ключевые вещи: fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; 01.08.2013 14:06, jm пишет: > Привет, настроил по этой инструкции - > http://forum.ubuntu.ru/index.php?topic=70057.0 домен, и при переходе > например по ссылке domain2.com/info.php предлагается сохранить php файл. > В access.log пишет 127.0.0.1 - - [31/Jul/2013:23:01:46 +0300] "GET /info.php > HTTP/1.1" 200 128 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0" > > Вот /etc/ngnix/sites-available/domain2.com > > server { > > listen 80; > server_name www.domain2.com; > rewrite ^/(.*) http://domain2.com/$1 permanent; > > } > > > server { > > listen 80; > server_name domain2.com; > > > access_log /home/jm/public_html/domain2.com/log/access.log; > error_log /home/jm/public_html/domain2.com/log/error.log; > > location / { > > root /home/jm/public_html/domain2.com/public/; > index index.php index.html index.htm; > > } > > > } > > > > > > > localhost/info.php работает нормально, настраивал по этой инструкции - > http://www.howtoforge.com/installing-nginx-with-php5-and-php-fpm-and-mysql-support-lemp-on-ubuntu-13.04 > В access.log пишет 127.0.0.1 - - [01/Aug/2013:13:29:58 +0300] "GET > /info.php?jhjh HTTP/1.1" 200 13436 "-" "Mozilla/5.0 (X11; Ubuntu; Linux > x86_64; rv:20.0) Gecko/20100101 Firefox/20.0" > 127.0.0.1 - - [01/Aug/2013:13:29:58 +0300] "GET > /info.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2536 > "http://localhost/info.php?jhjh" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; > rv:20.0) Gecko/20100101 Firefox/20.0" > 127.0.0.1 - - [01/Aug/2013:13:29:58 +0300] "GET > /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2158 > "http://localhost/info.php?jhjh" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; > rv:20.0) Gecko/20100101 Firefox/20.0" > 127.0.0.1 - - [01/Aug/2013:13:30:04 +0300] "-" 400 0 "-" "-" > > > Вот /etc/ngnix/sites-available/default > > > > server { > listen 80; > listen [::]:80 default_server ipv6only=on; > > root /usr/share/nginx/html; > index index.php index.html index.htm; > > server_name _; > > location / { > try_files $uri $uri/ /index.html; > } > > location /doc/ { > alias /usr/share/doc/; > autoindex on; > allow 127.0.0.1; > allow ::1; > deny all; > } > > > error_page 500 502 503 504 /50x.html; > location = /50x.html { > root /usr/share/nginx/html; > } > > location ~ \.php$ { > try_files $uri =404; > fastcgi_split_path_info ^(.+\.php)(/.+)$; > fastcgi_pass unix:/var/run/php5-fpm.sock; > fastcgi_index index.php; > include fastcgi_params; > } > > location ~ /\.ht { > deny all; > } > } > > > помогите найти где ошибка может быть > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241460,241460#msg-241460 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Dmitriy Lyalyuev http://lyalyuev.info -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4255 bytes Desc: п я─п╦п©я┌п╬пЁя─п╟я└п╦я┤п╣я│п╨п╟я▐ п©п╬п╢п©п╦я│я▄ S/MIME URL: From nginx-forum at nginx.us Thu Aug 1 11:27:22 2013 From: nginx-forum at nginx.us (jm) Date: Thu, 01 Aug 2013 07:27:22 -0400 Subject: =?UTF-8?B?UmU6IEPQutCw0YfQuNCy0LDRjtGC0YHRjyBwaHAg0YTQsNC50LvRiw==?= In-Reply-To: <51FA4438.10900@lyalyuev.info> References: <51FA4438.10900@lyalyuev.info> Message-ID: <169d54115f6eb145fa0d5df1a244fc1c.NginxMailingListRussian@forum.nginx.org> Спасибо большое, заработало) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241460,241462#msg-241462 From nginx-forum at nginx.us Fri Aug 2 10:08:02 2013 From: nginx-forum at nginx.us (ks2) Date: Fri, 02 Aug 2013 06:08:02 -0400 Subject: upstream: backup server In-Reply-To: <51E6CE24.6080805@csdoc.com> References: <51E6CE24.6080805@csdoc.com> Message-ID: <74b1768c1a33e370beea0a693d2a2e4a.NginxMailingListRussian@forum.nginx.org> Лучше поздно, чем никогда: Всем спасибо за ответы! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,240957,241472#msg-241472 From nginx-forum at nginx.us Fri Aug 2 10:17:00 2013 From: nginx-forum at nginx.us (ks2) Date: Fri, 02 Aug 2013 06:17:00 -0400 Subject: Change upstreams weights dynamically according to their response times Message-ID: Добрый день, Возможно ли сконфигурировать nginx (или может быть существуют дополнительные модули) так, чтобы он выбирал веса апстримов исходя из времени обработки запроса апстримом (среднего или персентилей за заданный промежуток времени)? Например, если под довольно высокой нагрузкой (несколько тысяч RPS) конкретный апстрим некоторое время отвечает быстро, а затем дольше (такие периоды могут длиться несколько секунд), то разумно отправлять больше запросов на другой, более быстрый апстрим. Потом, когда первому апстриму снова полегчает, можно дать больше нагрузки на него. Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241473,241473#msg-241473 From nginx-forum at nginx.us Fri Aug 2 10:19:37 2013 From: nginx-forum at nginx.us (Dobro) Date: Fri, 02 Aug 2013 06:19:37 -0400 Subject: =?UTF-8?B?0JrQvtC90LLQtdGA0YLQsNGG0LjRjyBNb2QtcmV3cml0ZSDQuNC3IEFwYWNoZQ==?= Message-ID: <099aaaf1845740017ba1760e3d740856.NginxMailingListRussian@forum.nginx.org> Доброго всем времени суток, перенастраивал свой сервер под nginx с апача и столкнулся с проблемой, в htaccess было прописано так: RewriteRule "(^|/)\." - [F] RewriteCond %{HTTP_HOST} ^([^.]+)\.site\.ru RewriteCond %1 !^www$ [NC] RewriteRule ^(.*)$ http://site.ru/users/%1 [L] Работало следующим образом - при наборе name.site.ru переадресовывало на site.ru/users/name конвертер из htacces в nginx предложил такой вариант: # nginx configuration location ~ "(^|/)\." { return 403; } location / { if ($http_host ~ "^([^.]+)\.site\.ru"){ rewrite ^(.*)$ http://site.ru/users/%1 redirect; } } Прописал это в конфигурационный файл, ошибок не нашлось, но почему-то не работает. Что сделал не так? Спасибо заранее Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241474,241474#msg-241474 From mdounin at mdounin.ru Fri Aug 2 10:23:00 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 2 Aug 2013 14:23:00 +0400 Subject: Change upstreams weights dynamically according to their response times In-Reply-To: References: Message-ID: <20130802102300.GT2130@mdounin.ru> Hello! On Fri, Aug 02, 2013 at 06:17:00AM -0400, ks2 wrote: > Добрый день, > > Возможно ли сконфигурировать nginx (или может быть существуют дополнительные > модули) так, чтобы он выбирал веса апстримов исходя из времени обработки > запроса апстримом (среднего или персентилей за заданный промежуток времени)? > > > Например, если под довольно высокой нагрузкой (несколько тысяч RPS) > конкретный апстрим некоторое время отвечает быстро, а затем дольше (такие > периоды могут длиться несколько секунд), то разумно отправлять больше > запросов на другой, более быстрый апстрим. Потом, когда первому апстриму > снова полегчает, можно дать больше нагрузки на него. Для решения этой задачи хорошо подойдёт балансировка по количеству соединений, см. http://nginx.org/r/least_conn. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Fri Aug 2 12:42:46 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 2 Aug 2013 13:42:46 +0100 Subject: upstream: backup server In-Reply-To: <51E6CE24.6080805@csdoc.com> References: <2b6ad4aeca19b074a85092830693981e.NginxMailingListRussian@forum.nginx.org> <20130717163704.GH49108@mdounin.ru> <51E6CE24.6080805@csdoc.com> Message-ID: <489A9B06-F44E-499D-9873-903705BB094A@sonru.com> On Jul 17, 2013, at 6:02 PM, Gena Makhomed wrote: > On 17.07.2013 19:37, Maxim Dounin wrote: > >>> В документации про >>> >>> upstream backend { >>> server foo.com >>> server bar.com backup; >>> } >>> >>> сказано: >>> only uses this server if the non-backup servers are all down or busy. >>> >>> Что конкретно означает "busy" в данном случае? >> >> Вы, судя по всему, зашли в wiki. Узнать, что имели ввиду >> пользователи, пишушие в вики - во многих случаях не представляется >> возможным. Это отчасти компенсируется тем, что написанное одним - >> может легко поправить другой. > > очень мало кто из пользователей догадывается, что wiki.nginx.org > не является "официальным" и **достоверным** источником информации. > ведь этот сайт размещается по "официальному" адресу wiki.nginx.org > и на него есть ссылка со страницы http://nginx.org/en/support.html > > может быть имеет смысл на каждой странице wiki сверху повесить баннер, > что это не является документацией и может содержать ошибки и неточности? > > или хотя бы написать об этом на странице > http://nginx.org/en/support.html > http://nginx.org/ru/support.html > и т.п. Многие, кто хорошо разбирается в Nginx не доверяют этой wiki, так как официальная документация http://nginx.org/en/docs/ исчерпывающая на 100%. Беда только в том, что поисковые системы отдают более высокий приоритет wiki,nginx.org. Анатолий > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Aug 2 18:08:53 2013 From: nginx-forum at nginx.us (ks2) Date: Fri, 02 Aug 2013 14:08:53 -0400 Subject: Change upstreams weights dynamically according to their response times In-Reply-To: <20130802102300.GT2130@mdounin.ru> References: <20130802102300.GT2130@mdounin.ru> Message-ID: Спасибо, Максим, А как число соединений коррелирует со скоростью ответа апстрима? Со стороны клиентов в моем случае нагрузка вида "сервер-сервер", когда клиенты открывают относительно небольшое (в сумме 1000-1500) количество соединений, но посылают через каждое много запросов. Я правильно понимаю, что nginx открывает отдельное соединение на апстрим для каждого соединения с клиента? Подходит ли в таком случае балансировка least_conn? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241473,241486#msg-241486 From mail at knutov.com Fri Aug 2 19:31:03 2013 From: mail at knutov.com (Nick Knutov) Date: Sat, 03 Aug 2013 01:31:03 +0600 Subject: =?UTF-8?B?TW9kU2VjdXJpdHksINC30LDRidC40YLQsCBXUCDQuCDQtNC20YPQvNC70Ysg0L4=?= =?UTF-8?B?0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/0LA=?= =?UTF-8?B?0YDQvtC70Lg=?= Message-ID: <51FC08F7.8020508@knutov.com> Кто-нибудь использует ModSecurity для nginx в продакшене? Как оно сейчас, стабильно ли? Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе и джумле от ботов, перебирающих пароли? У меня, например, не удалось быстро заставить работать naxsi + doci-rules, ищу альтернативы. -- Best Regards, Nick Knutov From bogdar at gmail.com Fri Aug 2 20:37:17 2013 From: bogdar at gmail.com (Bogdan) Date: Fri, 2 Aug 2013 23:37:17 +0300 Subject: Change upstreams weights dynamically according to their response times In-Reply-To: References: <20130802102300.GT2130@mdounin.ru> Message-ID: Если бэкенд отвечает очень быстро - количество активных сессий между балансером и бэкендом стремится к нулю, если бэкенд тормозит - увеличиывается количество активных соединений находящися в ожидании ответа бэкенда. 2013/8/2 ks2 > Спасибо, Максим, > > А как число соединений коррелирует со скоростью ответа апстрима? Со стороны > клиентов в моем случае нагрузка вида "сервер-сервер", когда клиенты > открывают относительно небольшое (в сумме 1000-1500) количество соединений, > но посылают через каждое много запросов. Я правильно понимаю, что nginx > открывает отдельное соединение на апстрим для каждого соединения с клиента? > Подходит ли в таком случае балансировка least_conn? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,241473,241486#msg-241486 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- WBR, Bogdan B. Rudas -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at karimov.ru Fri Aug 2 22:15:49 2013 From: andy at karimov.ru (andy karimov) Date: Sat, 3 Aug 2013 01:15:49 +0300 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FC08F7.8020508@knutov.com> References: <51FC08F7.8020508@knutov.com> Message-ID: <1841522545.20130803011549@karimov.ru> Hello Nick, NK> Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе NK> и джумле от ботов, перебирающих пароли? У меня, например, не удалось NK> быстро заставить работать naxsi + doci-rules, ищу альтернативы. ## -- wp-login brute attack -------------------- SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR} # React if block flag has been set. SecRule user:bf_block "@gt 0" "deny,status:402,log,msg:'ip address blocked for 10 minutes, more than 3 login attempts in 3 minutes.'" # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed. SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180" SecRule ip:bf_counter "@gt 3" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=600,setvar:ip.bf_counter=0" ## -- -- Regards, Andy Karimov From mail at knutov.com Sat Aug 3 00:27:08 2013 From: mail at knutov.com (Nick Knutov) Date: Sat, 03 Aug 2013 06:27:08 +0600 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <1841522545.20130803011549@karimov.ru> References: <51FC08F7.8020508@knutov.com> <1841522545.20130803011549@karimov.ru> Message-ID: <51FC4E5C.5090808@knutov.com> Этот вариант я нагуглил сразу. Но фильтровать мне надо до бекенда, тем более в моем случае там еще апач 1.3 без mpm_event. 03.08.2013 4:15, andy karimov пишет: > Hello Nick, > > NK> Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе > NK> и джумле от ботов, перебирающих пароли? У меня, например, не удалось > NK> быстро заставить работать naxsi + doci-rules, ищу альтернативы. > > ## -- wp-login brute attack -------------------- > SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR} > > # React if block flag has been set. > SecRule user:bf_block "@gt 0" "deny,status:402,log,msg:'ip address blocked for 10 minutes, more than 3 login attempts in 3 minutes.'" > > # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed. > SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0" > SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180" > SecRule ip:bf_counter "@gt 3" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=600,setvar:ip.bf_counter=0" > > ## -- > > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From mdounin at mdounin.ru Sat Aug 3 10:27:16 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 3 Aug 2013 14:27:16 +0400 Subject: Change upstreams weights dynamically according to their response times In-Reply-To: References: <20130802102300.GT2130@mdounin.ru> Message-ID: <20130803102715.GL2130@mdounin.ru> Hello! On Fri, Aug 02, 2013 at 02:08:53PM -0400, ks2 wrote: > Спасибо, Максим, > > А как число соединений коррелирует со скоростью ответа апстрима? Со стороны > клиентов в моем случае нагрузка вида "сервер-сервер", когда клиенты > открывают относительно небольшое (в сумме 1000-1500) количество соединений, > но посылают через каждое много запросов. Я правильно понимаю, что nginx > открывает отдельное соединение на апстрим для каждого соединения с клиента? По умолчанию - да, для каждого запроса открывается новое соединение с бекендом. Можно ещё настроить кеш соединений с бекендами, см. http://nginx.org/r/keepalive. > Подходит ли в таком случае балансировка least_conn? Главное, чтобы суммарное количество параллельно выполняющихся запросов было больше, чем количество бекендов. Понятно, что если бы запросы поступали по одному соединению, и соответственно к началу выполнения следующего запроса предыдущий уже был бы гарантированно завершён - то least_conn бы не работал (точнее, работал бы как обычный round-robin). Но 1000-1500 соединений должно с запасом хватить для нормальной балансировки. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Sat Aug 3 10:31:03 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 3 Aug 2013 14:31:03 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FC08F7.8020508@knutov.com> References: <51FC08F7.8020508@knutov.com> Message-ID: <20130803103103.GM2130@mdounin.ru> Hello! On Sat, Aug 03, 2013 at 01:31:03AM +0600, Nick Knutov wrote: > Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе > и джумле от ботов, перебирающих пароли? У меня, например, не удалось > быстро заставить работать naxsi + doci-rules, ищу альтернативы. [...] Я стесняюсь спросить - а limit_req чем не подходит? http://nginx.org/r/limit_req -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Sat Aug 3 10:37:24 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 3 Aug 2013 14:37:24 +0400 Subject: Change upstreams weights dynamically according to their response times In-Reply-To: References: <20130802102300.GT2130@mdounin.ru> Message-ID: <201308031437.24138.vbart@nginx.com> On Friday 02 August 2013 22:08:53 ks2 wrote: > Спасибо, Максим, > > А как число соединений коррелирует со скоростью ответа апстрима? Со стороны > клиентов в моем случае нагрузка вида "сервер-сервер", когда клиенты > открывают относительно небольшое (в сумме 1000-1500) количество соединений, > но посылают через каждое много запросов. Я правильно понимаю, что nginx > открывает отдельное соединение на апстрим для каждого соединения с клиента? > Подходит ли в таком случае балансировка least_conn? > [...] Нет, nginx не открывает соединение на апстрим для каждого соединения с клиента. Соединения открываются только по мере необходимости, чтобы отправить запрос, и количество соединений коррелирует с количеством запросов, находящихся в обработке у апстрима. Быстрый бэкенд будет быстрее обрабатывать запросы, а соответственно быстрее закрывать соединения и становиться более предпочтительным для балансировщика. keepalive [1] также в эту картину вписывается, с той лишь разницей, что соединения после обработки запроса не закрываются, а попадают в пул свободных соединений. [1] http://nginx.org/r/keepalive/ru -- Валентин Бартенев http://nginx.org/en/donation.html From mail at knutov.com Sat Aug 3 11:13:21 2013 From: mail at knutov.com (Nick Knutov) Date: Sat, 03 Aug 2013 17:13:21 +0600 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <20130803103103.GM2130@mdounin.ru> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> Message-ID: <51FCE5D1.2070407@knutov.com> Тем, что он пропускает запросы на бекэнд. Размер ботнета, перебирающего пароли - примерно 100 000 ип. Он не весь сразу приходит, но в общем случае, или можно использовать простое ограничение вроде с одного ип не чаще 1 запроса в минуту/секунду, но это просто снижает нагрузку до приемлимого уровня, а не решает проблему. Если придумывать что-то сложнее, чем фильтр по $binary_remote_addr, то это надо еще думать, и памяти оно начинает занимать заметно больше. При этом уже существуют хорошо работающие правила для mod_security (и не только на конкретно этот случай) и для naxsi есть doxi-rules (которые я уже даже перестал пытаться понимать) 03.08.2013 16:31, Maxim Dounin пишет: > Hello! > > On Sat, Aug 03, 2013 at 01:31:03AM +0600, Nick Knutov wrote: > >> Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе >> и джумле от ботов, перебирающих пароли? У меня, например, не удалось >> быстро заставить работать naxsi + doci-rules, ищу альтернативы. > > [...] > > Я стесняюсь спросить - а limit_req чем не подходит? > > http://nginx.org/r/limit_req > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From nginx-forum at nginx.us Sat Aug 3 14:39:58 2013 From: nginx-forum at nginx.us (automatix) Date: Sat, 03 Aug 2013 10:39:58 -0400 Subject: =?UTF-8?B?0J7RiNC40LHQutCwIDQwNCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0Lgg0LIg0KPQoNCb0LUg0L3QtdC30LDRjdGB0LrQtdC50L/QtdC90L3Ri9GF?= =?UTF-8?B?INGB0L/QtdGG0YHQuNC80LLQvtC70L7Qsiwg0YLQsNC60LjRhSDQutCw0Log?= =?UTF-8?B?0YHQutC+0LHQutC4INC40LvQuCDRgtC40YDQtQ==?= Message-ID: Доброго времени суток! Даблпостинг не есть гуд. Надеюсь на снисходительность админов/модераторов. Тем более, что оригинал (http://forum.nginx.org/read.php?2,241421) на другом языке. Дело в следующем. Есть сайт с каталогом городов. На странице каждого города есть список линков на виды спорта. (Далее на странице каждого вида спорта есть список курсов по данному виду спорта, предлагаемых в данном городе.) Выглядит это так: page "Cities" (/catalog) Madrid link: website.tld/catalog/Madrid Berlin link: website.tld/catalog/Berlin London link: website.tld/catalog/London page "Sports in London" (/catalog/London) Foo link: website.tld/catalog/London/Foo Bar (Bar) link: website.tld/catalog/London/Bar (Bar) Baz - Baz link: website.tld/catalog/London/Baz - Baz Проблема в УРЛах со спецсимволами. Если они заэскейпены (например, "website.tld/catalog/Berlin/Jeu%20de%20Paume%20%28Real%20Tennis%29"), все работает. Если же нет -- то есть юзер сам вводит адрес (например, "website.tld/catalog/Berlin/Jeu de Paume (Real Tennis)"), то сервер возвращает ошибку 404. Как это исправить? Я хочу добиться поведения сервера ? la Wikipedia, когда неважно, вводит ли юзер "http://en.wikipedia.org/wiki/Signal_%28electrical_engineering%29" или "http://en.wikipedia.org/wiki/Signal_(electrical_engineering)" -- он всегда оказывается на нужной странице. Заранее спасибо! Дополнительная информация: System properties: Zend Framework 2 (дело точно не в раутинге, а в вэб-сервере -- запрос даже не доходит до приложения), Debian 7, nginx 1.2.1, PHP 5.5. nginx.conf: user www-data; worker_processes 4; pid /var/run/nginx.pid; events { worker_connections 768; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } ax-common-vhost: server { listen 80; server_name foo.loc bar.loc baz.loc ; if ($host ~ ^(?.+)\.(?.+)\.loc$) { #set $project $1; # already set #set $area $2; # already set set $folder "$area/$project"; #set $domain "$project.$area.loc"; # equal to $host } access_log /var/log/nginx/$area/$project.access.log; error_log /var/log/nginx/error.log; gzip on; gzip_min_length 1000; gzip_types text/plain text/xml application/xml; client_max_body_size 25m; root /var/www/$folder/public/; try_files $uri $uri/ /index.php?$args; index index.html index.php; location / { index index.html index.php; sendfile off; } location ~ (\.inc\.php|\.tpl|\.sql|\.tpl\.php|\.db)$ { deny all; } location ~ \.htaccess { deny all; } if (!-e $request_filename) { rewrite ^.*$ /index.php last; } location ~ \.php$ { fastcgi_cache off; #fastcgi_pass 127.0.0.1:9001; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_read_timeout 6000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param APPLICATION_ENV development; fastcgi_param HTTPS $https; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241512,241512#msg-241512 From nginx-forum at nginx.us Sat Aug 3 21:27:10 2013 From: nginx-forum at nginx.us (Sferg) Date: Sat, 03 Aug 2013 17:27:10 -0400 Subject: =?UTF-8?B?0JrQsNC6INC00L7QsdCw0LLQuNGC0Ywg0LrQsNGA0YLQuNC90LrRgyDQvdCwINGB?= =?UTF-8?B?0YLRgNCw0L3QuNGG0YMg0L7RiNC40LHQutC4IG5naW54Pw==?= Message-ID: <2bdd47b95cac6d9a22c4866a3f6733b4.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Установлена связка Nginx + PHP-FPM. Подскажите, пожалуйста, как можно сделать вывод картинки в Nginx при, скажем, коде ошибки 50x? В даный момент у меня прописано так: error_page 500 502 503 504 /50x.html location = /50x.html { root errors/; } Пытаюсь добавить строчку в файл /etc/nginx/errors/50x.html: Но картинка почему-то не открывается. В чём может быть дело? С уважением, Геннадий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241516,241516#msg-241516 From dmitriy at lyalyuev.info Sun Aug 4 06:32:08 2013 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Sun, 04 Aug 2013 09:32:08 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQtNC+0LHQsNCy0LjRgtGMINC60LDRgNGC0LjQvdC60YMg0L0=?= =?UTF-8?B?0LAg0YHRgtGA0LDQvdC40YbRgyDQvtGI0LjQsdC60Lggbmdpbng/?= In-Reply-To: <2bdd47b95cac6d9a22c4866a3f6733b4.NginxMailingListRussian@forum.nginx.org> References: <2bdd47b95cac6d9a22c4866a3f6733b4.NginxMailingListRussian@forum.nginx.org> Message-ID: <51FDF568.9070002@lyalyuev.info> Вероятно потому, что root прописан не верно. 04.08.2013 00:27, Sferg пишет: > Здравствуйте. Установлена связка Nginx + PHP-FPM. Подскажите, пожалуйста, > как можно сделать вывод картинки в Nginx при, скажем, коде ошибки 50x? В > даный момент у меня прописано так: > > error_page 500 502 503 504 /50x.html > > location = /50x.html { > root errors/; > } > > Пытаюсь добавить строчку в файл /etc/nginx/errors/50x.html: > > > > Но картинка почему-то не открывается. В чём может быть дело? > > С уважением, Геннадий. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241516,241516#msg-241516 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From denis at webmaster.spb.ru Sun Aug 4 07:16:10 2013 From: denis at webmaster.spb.ru (denis) Date: Sun, 04 Aug 2013 11:16:10 +0400 Subject: =?UTF-8?B?UmU6INCa0L7QvdCy0LXRgNGC0LDRhtC40Y8gTW9kLXJld3JpdGUg0LjQtyBBcGFj?= =?UTF-8?B?aGU=?= In-Reply-To: <099aaaf1845740017ba1760e3d740856.NginxMailingListRussian@forum.nginx.org> References: <099aaaf1845740017ba1760e3d740856.NginxMailingListRussian@forum.nginx.org> Message-ID: <51FDFFBA.7070808@webmaster.spb.ru> 02.08.2013 14:19, Dobro пишет: > location / { > if ($http_host ~ "^([^.]+)\.site\.ru"){ > rewrite ^(.*)$ http://site.ru/users/%1 redirect; > } > } > > Прописал это в конфигурационный файл, ошибок не нашлось, но почему-то не > работает. Что сделал не так? http://wiki.nginx.org/IfIsEvil Описываем отдельную секцию server_name ~^([^.]+)\.site\.ru ; ... return 301 http://site.ru/users/$1$request_uri; как-то так. Использование регэкспов в сервер нейме имеет нюансы, http://dragonflybsd.blogspot.ru/2012/07/nginx-regex-servername.html From nginx-forum at nginx.us Sun Aug 4 09:37:23 2013 From: nginx-forum at nginx.us (Argyn) Date: Sun, 04 Aug 2013 05:37:23 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/QtdGA0LXQvtC/0YDQtdC0?= =?UTF-8?B?0LXQu9C40YLRjCBTRVJWRVIgUE9SVD8=?= In-Reply-To: <4ACC96C4.9070909@mail.ru> References: <4ACC96C4.9070909@mail.ru> Message-ID: <9c4f6c43f17314b7f22be772e8c1e7de.NginxMailingListRussian@forum.nginx.org> 1) Директивы BindAddress и Port более не существуют. Эквивалентная функциональность предоставляется более гибкой директивой Listen. 2) В Apache 1.3 директива Port использовалась, кроме всего прочего, для того чтобы сервер мог формировать правильные ссылки на самого себя. В Apache 2.0 для тех же целей служит новый синтаксис директивы ServerName: он был изменён таким образом, что теперь имя хоста и номер порта можно указывать в одной этой директиве. ServerName domain.ru:80 решает проблему. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,11787,241530#msg-241530 From wangsamp at gmail.com Sun Aug 4 10:21:41 2013 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sun, 4 Aug 2013 13:21:41 +0300 (EEST) Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/QtdGA0LXQvtC/0YDQtdC0?= =?UTF-8?B?0LXQu9C40YLRjCBTRVJWRVIgUE9SVD8=?= In-Reply-To: <9c4f6c43f17314b7f22be772e8c1e7de.NginxMailingListRussian@forum.nginx.org> References: <4ACC96C4.9070909@mail.ru> <9c4f6c43f17314b7f22be772e8c1e7de.NginxMailingListRussian@forum.nginx.org> Message-ID: Today Aug 4, 2013 at 05:37 Argyn wrote: > 1) Директивы BindAddress и Port более не существуют. Эквивалентная > функциональность предоставляется более гибкой директивой Listen. > 2) В Apache 1.3 директива Port использовалась, кроме всего прочего, для того > чтобы сервер мог формировать правильные ссылки на самого себя. В Apache 2.0 > для тех же целей служит новый синтаксис директивы ServerName: он был изменён > таким образом, что теперь имя хоста и номер порта можно указывать в одной > этой директиве. > > ServerName domain.ru:80 решает проблему. Речь идёт о ссылках в редиректах? http://nginx.org/r/proxy_redirect/ru -- WNGS-RIPE From universite at ukr.net Sun Aug 4 11:21:03 2013 From: universite at ukr.net (Vladislav Prodan) Date: Sun, 04 Aug 2013 14:21:03 +0300 Subject: =?UTF-8?B?UmVbMl06IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0Lw=?= =?UTF-8?B?0LvRiyDQvtGCINCx0L7RgtC+0LIsINC/0LXRgNC10LHQuNGA0LDRjtGJ0Lg=?= =?UTF-8?B?0YUg0L/QsNGA0L7Qu9C4?= In-Reply-To: <51FCE5D1.2070407@knutov.com> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> Message-ID: <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> --- Исходное сообщение --- От кого: "Nick Knutov" Дата: 3 августа 2013, 14:13:32 > Тем, что он пропускает запросы на бекэнд. > Размер ботнета, перебирающего пароли - примерно 100 000 ип. > Он не весь сразу приходит, но в общем случае, или можно использовать > простое ограничение вроде с одного ип не чаще 1 запроса в > минуту/секунду, но это просто снижает нагрузку до приемлимого уровня, а > не решает проблему. У меня скрипт каждые 5 минут парсит общий (суточный) лог нгинкса nginx-access.log. И если накапливается 30 запросов на перебор паролей вордпресса/джумлы с 1 IP, то этот IP добавляется в глобальный список deny. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From corochoone at gmail.com Sun Aug 4 11:39:17 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Sun, 4 Aug 2013 15:39:17 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiBNb2RTZWN1cml0eSwg0LfQsNGJ0LjRgtCwIFdQINC4INC00LY=?= =?UTF-8?B?0YPQvNC70Ysg0L7RgiDQsdC+0YLQvtCyLCDQv9C10YDQtdCx0LjRgNCw0Y4=?= =?UTF-8?B?0YnQuNGFINC/0LDRgNC+0LvQuA==?= In-Reply-To: <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> Message-ID: А мне кажется всё это неэффективно. IP адресов прорва и каждый задолбаешься блокировать, а нагрузка прёт. Эффективных вариантов вижу 2: 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и сам владелец сайта зайти не сможет, но для его IP можно сделать исключение. Зато остальные сайты на сервере смогут нормально работать 2. С участием владельца сайта переименовать файл для входа в какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, чтобы данное имя было известно только владельцу сайта. А на /administator/index.php поставить статическую заглушку, которую nginx может отдавать со скоростью пулемёта. 4 августа 2013 г., 15:21 пользователь Vladislav Prodan написал: > > > --- Исходное сообщение --- > От кого: "Nick Knutov" > Дата: 3 августа 2013, 14:13:32 > > > > Тем, что он пропускает запросы на бекэнд. > > Размер ботнета, перебирающего пароли - примерно 100 000 ип. > > Он не весь сразу приходит, но в общем случае, или можно использовать > > простое ограничение вроде с одного ип не чаще 1 запроса в > > минуту/секунду, но это просто снижает нагрузку до приемлимого уровня, а > > не решает проблему. > > У меня скрипт каждые 5 минут парсит общий (суточный) лог нгинкса > nginx-access.log. > И если накапливается 30 запросов на перебор паролей вордпресса/джумлы с 1 > IP, то этот IP добавляется в глобальный список deny. > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > > _______________________________________________ > 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 universite at ukr.net Sun Aug 4 11:59:14 2013 From: universite at ukr.net (Vladislav Prodan) Date: Sun, 04 Aug 2013 14:59:14 +0300 Subject: =?UTF-8?B?UmVbMl06IFJlWzJdOiBNb2RTZWN1cml0eSwg0LfQsNGJ0LjRgtCwIFdQINC4INC0?= =?UTF-8?B?0LbRg9C80LvRiyDQvtGCINCx0L7RgtC+0LIsINC/0LXRgNC10LHQuNGA0LA=?= =?UTF-8?B?0Y7RidC40YUg0L/QsNGA0L7Qu9C4?= In-Reply-To: References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> Message-ID: <1375617201.608414227.asffgsll@fmst-1.ukr.net> --- Исходное сообщение --- От кого: "Виктор Вислобоков" Дата: 4 августа 2013, 14:39:32 > А мне кажется всё это неэффективно. IP адресов прорва и каждый задолбаешься блокировать, а нагрузка прёт. Кто задолбается блокировать? Скрипт? nginx? Для владельца ресурса достаточно трех попыток зайти на свой ресурс. А пороговое значение (у меня) - 30 попыток и есть куда снижать. Скрипт на awk, спокойно парсит гигобайтные логи за несколько (десятков) секунд. > Эффективных вариантов вижу 2: > > 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и сам владелец сайта зайти не сможет, но для его IP можно сделать исключение. Зато остальные сайты на сервере смогут нормально работать > Белые списки само собой существуют. > 2. С участием владельца сайта переименовать файл для входа в какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, чтобы данное имя было известно только владельцу сайта. А на /administator/index.php поставить статическую заглушку, которую nginx может отдавать со скоростью пулемёта. А лучше пароль на директорию повесить. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From sergey.kobzar at itcraft.org Sun Aug 4 13:40:18 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Sun, 04 Aug 2013 16:40:18 +0300 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <1375617201.608414227.asffgsll@fmst-1.ukr.net> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <1375617201.608414227.asffgsll@fmst-1.ukr.net> Message-ID: <51FE59C2.5090600@itcraft.org> On 08/04/13 14:59, Vladislav Prodan wrote: > > > --- Исходное сообщение --- > От кого: "Виктор Вислобоков" > Дата: 4 августа 2013, 14:39:32 > > >> А мне кажется всё это неэффективно. IP адресов прорва и каждый задолбаешься блокировать, а нагрузка прёт. > > Кто задолбается блокировать? Скрипт? nginx? > Для владельца ресурса достаточно трех попыток зайти на свой ресурс. > А пороговое значение (у меня) - 30 попыток и есть куда снижать. > Скрипт на awk, спокойно парсит гигобайтные логи за несколько (десятков) секунд. > >> Эффективных вариантов вижу 2: >> >> 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и сам владелец сайта зайти не сможет, но для его IP можно сделать исключение. Зато остальные сайты на сервере смогут нормально работать >> > Белые списки само собой существуют. > >> 2. С участием владельца сайта переименовать файл для входа в какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, чтобы данное имя было известно только владельцу сайта. А на /administator/index.php поставить статическую заглушку, которую nginx может отдавать со скоростью пулемёта. > > А лучше пароль на директорию повесить. > Joomla пишет в logs/error.php о неуспешных попытках аутентификации. Формат: date time priority clientip category На этот файл можно натравить fail2ban и принимать необходимое решение. From corochoone at gmail.com Sun Aug 4 14:47:28 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Sun, 4 Aug 2013 18:47:28 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FE59C2.5090600@itcraft.org> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <1375617201.608414227.asffgsll@fmst-1.ukr.net> <51FE59C2.5090600@itcraft.org> Message-ID: > На этот файл можно натравить fail2ban и принимать необходимое решение. А если у вас несколько сотен виртуалхостов, ваш fail2ban будет жёско иметь сервер парся логи. А поскольку ботнеты бывают ну очень большими, вы ещё рискуете получить каку от ядра, когда таблица файрвола будет забита десятками тысяч IP адресов. 4 августа 2013 г., 17:40 пользователь Sergey Kobzar < sergey.kobzar at itcraft.org> написал: > On 08/04/13 14:59, Vladislav Prodan wrote: > >> >> >> --- Исходное сообщение --- >> От кого: "Виктор Вислобоков" >> Дата: 4 августа 2013, 14:39:32 >> >> >> А мне кажется всё это неэффективно. IP адресов прорва и каждый >>> задолбаешься блокировать, а нагрузка прёт. >>> >> >> Кто задолбается блокировать? Скрипт? nginx? >> Для владельца ресурса достаточно трех попыток зайти на свой ресурс. >> А пороговое значение (у меня) - 30 попыток и есть куда снижать. >> Скрипт на awk, спокойно парсит гигобайтные логи за несколько (десятков) >> секунд. >> >> Эффективных вариантов вижу 2: >>> >>> 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к >>> отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и >>> /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и >>> сам владелец сайта зайти не сможет, но для его IP можно сделать исключение. >>> Зато остальные сайты на сервере смогут нормально работать >>> >>> Белые списки само собой существуют. >> >> 2. С участием владельца сайта переименовать файл для входа в >>> какое-нибудь трудное имя, например administator/indexHJK28bhy2H.**php, >>> чтобы данное имя было известно только владельцу сайта. А на >>> /administator/index.php поставить статическую заглушку, которую nginx может >>> отдавать со скоростью пулемёта. >>> >> >> А лучше пароль на директорию повесить. >> >> > Joomla пишет в logs/error.php о неуспешных попытках аутентификации. Формат: > > date time priority clientip category > > На этот файл можно натравить fail2ban и принимать необходимое решение. > > > ______________________________**_________________ > 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 mail at knutov.com Sun Aug 4 14:58:49 2013 From: mail at knutov.com (Nick Knutov) Date: Sun, 04 Aug 2013 20:58:49 +0600 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> Message-ID: <51FE6C29.7080500@knutov.com> Меня всегда неимоверно радовали господа, предлагающие что-нибудь глобально запрестить для всех ип и сделать исключение для ип одного человека. Догадайтесь почему :) Остальные сайты (да и атакуемые) и так прекрасно работают при правильном софте/конфигах. 2 - нереалистичная идея. Шаред хостинг например, таких сайтов - тысячи. Да и проблему никак не решает, потому что ссылка на этот логин будет на главной странице, например, потому что там кроме админа могут быть и другие юзеры. 04.08.2013 17:39, Виктор Вислобоков пишет: > А мне кажется всё это неэффективно. IP адресов прорва и каждый > задолбаешься блокировать, а нагрузка прёт. > Эффективных вариантов вижу 2: > 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к > отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и > /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и > сам владелец сайта зайти не сможет, но для его IP можно сделать > исключение. Зато остальные сайты на сервере смогут нормально работать > 2. С участием владельца сайта переименовать файл для входа в > какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, > чтобы данное имя было известно только владельцу сайта. А на > /administator/index.php поставить статическую заглушку, которую nginx > может отдавать со скоростью пулемёта. > > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From corochoone at gmail.com Sun Aug 4 15:56:53 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Sun, 4 Aug 2013 19:56:53 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FE6C29.7080500@knutov.com> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <51FE6C29.7080500@knutov.com> Message-ID: > Остальные сайты (да и атакуемые) и так прекрасно работают при правильном софте/конфигах. Ну-ну, блажен кто верует! При хорошей атаке с большого ботнета, даже циска ложиться, куда уж вам с вашими конфигами. Вас видимо просто ни кто ни разу КОНКРЕТНО не ддосил. 2 - да не очень хорошее решение. Тут предложили пароль ставить на каталог - тоже выход! 4 августа 2013 г., 18:58 пользователь Nick Knutov написал: > Меня всегда неимоверно радовали господа, предлагающие что-нибудь > глобально запрестить для всех ип и сделать исключение для ип одного > человека. Догадайтесь почему :) > > Остальные сайты (да и атакуемые) и так прекрасно работают при правильном > софте/конфигах. > > 2 - нереалистичная идея. Шаред хостинг например, таких сайтов - тысячи. > Да и проблему никак не решает, потому что ссылка на этот логин будет на > главной странице, например, потому что там кроме админа могут быть и > другие юзеры. > > > 04.08.2013 17:39, Виктор Вислобоков пишет: > > А мне кажется всё это неэффективно. IP адресов прорва и каждый > > задолбаешься блокировать, а нагрузка прёт. > > Эффективных вариантов вижу 2: > > 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к > > отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и > > /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и > > сам владелец сайта зайти не сможет, но для его IP можно сделать > > исключение. Зато остальные сайты на сервере смогут нормально работать > > 2. С участием владельца сайта переименовать файл для входа в > > какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, > > чтобы данное имя было известно только владельцу сайта. А на > > /administator/index.php поставить статическую заглушку, которую nginx > > может отдавать со скоростью пулемёта. > > > > > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > > _______________________________________________ > 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 universite at ukr.net Sun Aug 4 16:37:44 2013 From: universite at ukr.net (Vladislav Prodan) Date: Sun, 04 Aug 2013 19:37:44 +0300 Subject: =?UTF-8?B?UmVbMl06IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0Lw=?= =?UTF-8?B?0LvRiyDQvtGCINCx0L7RgtC+0LIsINC/0LXRgNC10LHQuNGA0LDRjtGJ0Lg=?= =?UTF-8?B?0YUg0L/QsNGA0L7Qu9C4?= In-Reply-To: <51FE6C29.7080500@knutov.com> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <51FE6C29.7080500@knutov.com> Message-ID: <1375633921.549591118.bi3exobq@fmst-1.ukr.net> --- Исходное сообщение --- От кого: "Nick Knutov" Дата: 4 августа 2013, 17:59:05 > Меня всегда неимоверно радовали господа, предлагающие что-нибудь > глобально запрестить для всех ип и сделать исключение для ип одного > человека. Догадайтесь почему :) Мне за сутки приходит с 10-к абьюз на моих пользователей. И мне приходится реагировать, чтоб мои сети не попали в черные листы. И в то же время мониторинг подсказывает сотни IP, которые за сутки атаковали меня. Благо, абьюзы генерятся мониторингом автоматом. Если это российские IP, то ответа на абьюзу не дождешься, в особо тяжких случаях, приходится банить сетями. А потом тут удивляются, откуда столько IP в ботнетах? P.S. Вот сейчас ко мне долбится ботнет мощностью 5К IP. Скрипты банят, сайты не страдают. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From denis at webmaster.spb.ru Sun Aug 4 17:56:20 2013 From: denis at webmaster.spb.ru (denis) Date: Sun, 04 Aug 2013 21:56:20 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> Message-ID: <51FE95C4.6000800@webmaster.spb.ru> 04.08.2013 15:39, Виктор Вислобоков пишет: > 2. С участием владельца сайта переименовать файл для входа в > какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, > чтобы данное имя было известно только владельцу сайта. А на > /administator/index.php поставить статическую заглушку, которую nginx > может отдавать со скоростью пулемёта. > до первого обращения на урл через хром. Делали тесты - у чела свой личный самописный сервак на нестандартном посту, только по айпи. После моего захода хромом (фф с того же компа - нет такого) -- к нему прибегает толпа всяких w00t ботов и прочей мерзости.. и как-то одна из страниц в гугле появилась, при том что нигде ссылки на неё не размещались. Авторизация типа бейсик - куда лучше вариант. From mail at knutov.com Sun Aug 4 18:09:02 2013 From: mail at knutov.com (Nick Knutov) Date: Mon, 05 Aug 2013 00:09:02 +0600 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <51FE6C29.7080500@knutov.com> Message-ID: <51FE98BE.5040506@knutov.com> Я - хостер. Я не верую, я это вживую вижу на наших серверах. Но у нас свои сборки софта, которые мы вылизываем, и очень нестандартные конфиги, потому всё это работает. Маленькие ботнеты мы не замечаем, большие фильтруем, с нашей стороны всё обычно работает, если это боты, а не забивка канала. А циска - да, циска может и ложится. А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт. Гарантированно решит проблему. 04.08.2013 21:56, Виктор Вислобоков пишет: >> Остальные сайты (да и атакуемые) и так прекрасно работают при > правильном софте/конфигах. > Ну-ну, блажен кто верует! > При хорошей атаке с большого ботнета, даже циска ложиться, куда уж вам с > вашими конфигами. Вас видимо просто ни кто ни разу КОНКРЕТНО не ддосил. > > 2 - да не очень хорошее решение. Тут предложили пароль ставить на > каталог - тоже выход!\-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From nginx-forum at nginx.us Sun Aug 4 18:26:55 2013 From: nginx-forum at nginx.us (Sferg) Date: Sun, 04 Aug 2013 14:26:55 -0400 Subject: =?UTF-8?B?Tmdpbngg0Lgg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC90LAgaW5k?= =?UTF-8?B?ZXgucGhw?= Message-ID: <1d872a5b88acb7f440d7a3a9cedda14c.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Подскажите, пожалуйста, каким образом можно реализовать перенаправление к index.php в случае, если неверно указан адрес? Причём перенаправление должно быть не к index.php в корне, а к index.php той директории, где в данный момент нахожусь. Например: http://example.com/blahblahblah - должен открываться http://example.com/index.php и http://example.com/blog/blahblahblah - должен открываться http://example.com/blog/index.php, но не http://example.com/index.php С уважением, Геннадий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241545,241545#msg-241545 From corochoone at gmail.com Sun Aug 4 19:24:19 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Sun, 4 Aug 2013 23:24:19 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FE98BE.5040506@knutov.com> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <51FE6C29.7080500@knutov.com> <51FE98BE.5040506@knutov.com> Message-ID: > Я - хостер. Я не верую, я это вживую вижу на наших серверах. Да я как бы тоже не погулять вышел > Но у нас свои сборки софта, которые мы вылизываем А у меня к сожалению не всегда. И Plesk есть, например и даже nginx не везде возможен в силу разных причин. > Маленькие ботнеты мы не замечаем, Аналогыгычно > большие фильтруем Скорее средние Большие ботнеты можно фильтровать только при наличии циски да ещё не абы какой. > А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт. Пароль на сайт не надо, а вот пароль на административную часть сайта - почему нет? 4 августа 2013 г., 22:09 пользователь Nick Knutov написал: > Я - хостер. Я не верую, я это вживую вижу на наших серверах. > Но у нас свои сборки софта, которые мы вылизываем, и очень нестандартные > конфиги, потому всё это работает. Маленькие ботнеты мы не замечаем, > большие фильтруем, с нашей стороны всё обычно работает, если это боты, а > не забивка канала. > > А циска - да, циска может и ложится. > > А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт. > Гарантированно решит проблему. > > > 04.08.2013 21:56, Виктор Вислобоков пишет: > >> Остальные сайты (да и атакуемые) и так прекрасно работают при > > правильном софте/конфигах. > > Ну-ну, блажен кто верует! > > При хорошей атаке с большого ботнета, даже циска ложиться, куда уж вам с > > вашими конфигами. Вас видимо просто ни кто ни разу КОНКРЕТНО не ддосил. > > > > 2 - да не очень хорошее решение. Тут предложили пароль ставить на > > каталог - тоже выход!\-- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > > _______________________________________________ > 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 mail at knutov.com Sun Aug 4 19:32:32 2013 From: mail at knutov.com (Nick Knutov) Date: Mon, 05 Aug 2013 01:32:32 +0600 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <51FE6C29.7080500@knutov.com> <51FE98BE.5040506@knutov.com> Message-ID: <51FEAC50.9030705@knutov.com> Потому что там бывают простые постоянные юзеры, у которых есть аккаунты для комментов, например. 05.08.2013 1:24, Виктор Вислобоков пишет: >> А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт. > Пароль на сайт не надо, а вот пароль на административную часть сайта - > почему нет? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From corochoone at gmail.com Sun Aug 4 19:42:00 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Sun, 4 Aug 2013 23:42:00 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FEAC50.9030705@knutov.com> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <51FE6C29.7080500@knutov.com> <51FE98BE.5040506@knutov.com> <51FEAC50.9030705@knutov.com> Message-ID: Возможно. Я не специалист по Джумле. В Друпале например в /admin/ кроме администраторов никого не бывает. Но если стоит вопрос в том, что сервер лежит и не работают ВСЕ клиенты, или часть клиентов испытывает неудобства зато все могут работать, я выберу последнее. 4 августа 2013 г., 23:32 пользователь Nick Knutov написал: > Потому что там бывают простые постоянные юзеры, у которых есть аккаунты > для комментов, например. > > 05.08.2013 1:24, Виктор Вислобоков пишет: > >> А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт. > > Пароль на сайт не надо, а вот пароль на административную часть сайта - > > почему нет? > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > > _______________________________________________ > 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 Aug 4 19:46:22 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Sun, 04 Aug 2013 22:46:22 +0300 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FC08F7.8020508@knutov.com> References: <51FC08F7.8020508@knutov.com> Message-ID: <51FEAF8E.1080009@csdoc.com> On 02.08.2013 22:31, Nick Knutov wrote: > Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе > и джумле от ботов, перебирающих пароли? У меня, например, не удалось > быстро заставить работать naxsi + doci-rules, ищу альтернативы. сделать вход в админку по https, define('FORCE_SSL_LOGIN', true); define('FORCE_SSL_ADMIN', true); вроде бы https боты не ломятся? возможно даже перенести ее на отдельный адрес, (средствами nginx) если таких сайтов много. например: было: http://www.example.com/wp-admin/ стало: https://admin.example.net/www.example.com/wp-admin/ ============= http://www.example.com/ - сайт клиента на вордпресс https://admin.example.net/ - сайт хостера с https. -- Best regards, Gena From chipitsine at gmail.com Mon Aug 5 03:06:29 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 5 Aug 2013 09:06:29 +0600 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <51FC08F7.8020508@knutov.com> References: <51FC08F7.8020508@knutov.com> Message-ID: ulogin ? суббота, 3 августа 2013 г. пользователь Nick Knutov писал: > Кто-нибудь использует ModSecurity для nginx в продакшене? Как оно > сейчас, стабильно ли? > > Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе > и джумле от ботов, перебирающих пароли? У меня, например, не удалось > быстро заставить работать naxsi + doci-rules, ищу альтернативы. > > -- > Best Regards, > Nick Knutov > > _______________________________________________ > 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 ru at nginx.com Mon Aug 5 07:04:30 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Mon, 5 Aug 2013 11:04:30 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC40YHQv9C+0LvRjNC30YPQtdGCIElQdjYg0LIgcHJveHkgcGFz?= =?UTF-8?B?cywg0LTQsNC20LUg0LXRgdC70Lgg0L7QvSDQvtGC0LrQu9GO0YfQtdC9?= In-Reply-To: <13ff5e25e82398ab0490d0b6ac968657.NginxMailingListRussian@forum.nginx.org> References: <13ff5e25e82398ab0490d0b6ac968657.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130805070430.GD3866@lo0.su> On Wed, Jul 31, 2013 at 04:06:27AM -0400, Antohat wrote: > Добрый день, > > На сервере отключен IPv6. На nginx настроено проксирование на upstream c > поддержкой IPv4 и IPv6. > > Nginx периодически (раз в 5 секунд) пытается отправлять запросы на IPv6 и > соответственно обламывается с ошибками: > > 2013/07/30 00:25:06 [error] 1930#0: *1482670 connect() to > [AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443 failed (101: Network is unreachable) while > connecting to upstream, client: AA.BB.CC.DD, server: example.com, request: > "GET /download/file HTTP/1.0", upstream: > "https://[AAAA:BBBB:C:DDD:E:F:GGG:HHH]:443/download/file", host: > "example.com" > > Как можно отключить IPv6 для proxy_pass? http://hg.nginx.org/nginx/rev/ec8594b9bf11 From serghey.rodin at gmail.com Mon Aug 5 07:08:47 2013 From: serghey.rodin at gmail.com (Serghey Rodin) Date: Mon, 5 Aug 2013 10:08:47 +0300 Subject: =?UTF-8?B?0J7QtNC90LAg0LrRjdGILdC30L7QvdCwLCDQvNC90L7Qs9C+INGB0LDQudGC0L4=?= =?UTF-8?B?0LI=?= Message-ID: Привет! Вчера столкнулся с проблемой при использовании одной кэш-зоны для нескольких сайтов. Спустя несколько минут все сайты показывают тот же контент. На сколько я понял, одна зона может обслуживать несколько сайтов, так как файлы с кэшем формируются на основе md5 от запрошенного браущером url. Но видимо я не до конца понимаю логику работы. В секции http следующие параметры proxy_cache_path /var/cache/nginx levels=2 keys_zone=cache:10m inactive=60m max_size=512m; proxy_temp_path /var/cache/nginx/temp; proxy_ignore_headers Expires Cache-Control; proxy_cache_use_stale error timeout invalid_header http_502; proxy_cache_valid any 3d; Для виртуальных хостов прописан шаблон: proxy_cache cache; proxy_cache_valid 10m; proxy_cache_valid 404 1m; proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; proxy_cache_bypass $cookie_session $http_x_update; Помогите пожалуйста понять причину. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Mon Aug 5 07:11:36 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 5 Aug 2013 13:11:36 +0600 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCA0MDQg0L/RgNC4INC40YHQv9C+0LvRjNC30L7QstCw?= =?UTF-8?B?0L3QuNC4INCyINCj0KDQm9C1INC90LXQt9Cw0Y3RgdC60LXQudC/0LXQvdC9?= =?UTF-8?B?0YvRhSDRgdC/0LXRhtGB0LjQvNCy0L7Qu9C+0LIsINGC0LDQutC40YUg0Lo=?= =?UTF-8?B?0LDQuiDRgdC60L7QsdC60Lgg0LjQu9C4INGC0LjRgNC1?= In-Reply-To: References: Message-ID: вы то как хотите, чтобы хитрый урл разбирался силами ZF уже ? если так, то вполне достаточно настроить nginx на примерно следующий алгоритм: "если есть локальный файл, отдаем его, иначе роутим на ZF" это нормальный подход для большинства CMS/CMF, народ же зачем-то упорно костылит штуки типа if (!-e $request_filename) { rewrite ^.*$ /index.php last; } брр.... try_files рулит, в общем. есть подозрение, что документация по nginx сильно проседает в плане "как мне захостить drupal/joomla/ZF/symphony/Cake...." огромное количество соверешенно нелепых конфигов, по всему интернету. вот работающий конфиг для ZF: server { listen 80; server_name .xxx.ru; root /srv/www/xxx; charset utf-8; access_log /var/log/nginx/xxx_access.log long buffer=32k; location / { try_files $uri $uri/ @zend; index index.php index.html index.htm; add_header Cache-Control max-age=1209600; } location ~ \.php$ { try_files $uri @zend; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; } location @zend { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root/index.php; include fastcgi_params; } location ~ /\. { deny all; } } 3 августа 2013 г., 20:39 пользователь automatix написал: > Доброго времени суток! > > Даблпостинг не есть гуд. Надеюсь на снисходительность админов/модераторов. > Тем более, что оригинал (http://forum.nginx.org/read.php?2,241421) на другом > языке. > > Дело в следующем. Есть сайт с каталогом городов. На странице каждого города > есть список линков на виды спорта. (Далее на странице каждого вида спорта > есть список курсов по данному виду спорта, предлагаемых в данном городе.) > Выглядит это так: > > page "Cities" (/catalog) > Madrid link: website.tld/catalog/Madrid > Berlin link: website.tld/catalog/Berlin > London link: website.tld/catalog/London > > page "Sports in London" (/catalog/London) > Foo link: website.tld/catalog/London/Foo > Bar (Bar) link: website.tld/catalog/London/Bar (Bar) > Baz - Baz link: website.tld/catalog/London/Baz - Baz > > Проблема в УРЛах со спецсимволами. Если они заэскейпены (например, > "website.tld/catalog/Berlin/Jeu%20de%20Paume%20%28Real%20Tennis%29"), все > работает. Если же нет -- то есть юзер сам вводит адрес (например, > "website.tld/catalog/Berlin/Jeu de Paume (Real Tennis)"), то сервер > возвращает ошибку 404. > > Как это исправить? > > Я хочу добиться поведения сервера ? la Wikipedia, когда неважно, вводит ли > юзер "http://en.wikipedia.org/wiki/Signal_%28electrical_engineering%29" или > "http://en.wikipedia.org/wiki/Signal_(electrical_engineering)" -- он всегда > оказывается на нужной странице. > > Заранее спасибо! > > > > Дополнительная информация: > > System properties: > > Zend Framework 2 (дело точно не в раутинге, а в вэб-сервере -- запрос даже > не доходит до приложения), Debian 7, nginx 1.2.1, PHP 5.5. > > nginx.conf: > > user www-data; > worker_processes 4; > pid /var/run/nginx.pid; > > events { > worker_connections 768; > } > > http { > > sendfile on; > tcp_nopush on; > tcp_nodelay on; > keepalive_timeout 65; > types_hash_max_size 2048; > > include /etc/nginx/mime.types; > default_type application/octet-stream; > > access_log /var/log/nginx/access.log; > error_log /var/log/nginx/error.log; > > gzip on; > gzip_disable "msie6"; > > include /etc/nginx/conf.d/*.conf; > include /etc/nginx/sites-enabled/*; > } > > ax-common-vhost: > > server { > listen 80; > server_name > foo.loc > bar.loc > baz.loc > ; > > if ($host ~ ^(?.+)\.(?.+)\.loc$) { > #set $project $1; # already set > #set $area $2; # already set > > set $folder "$area/$project"; > #set $domain "$project.$area.loc"; # equal to $host > } > > access_log /var/log/nginx/$area/$project.access.log; > error_log /var/log/nginx/error.log; > > gzip on; > gzip_min_length 1000; > gzip_types text/plain text/xml application/xml; > > client_max_body_size 25m; > > root /var/www/$folder/public/; > > try_files $uri $uri/ /index.php?$args; > index index.html index.php; > > location / { > index index.html index.php; > sendfile off; > } > > location ~ (\.inc\.php|\.tpl|\.sql|\.tpl\.php|\.db)$ { > deny all; > } > > location ~ \.htaccess { > deny all; > } > > if (!-e $request_filename) { > rewrite ^.*$ /index.php last; > } > > location ~ \.php$ { > fastcgi_cache off; > #fastcgi_pass 127.0.0.1:9001; > fastcgi_pass unix:/var/run/php5-fpm.sock; > fastcgi_read_timeout 6000; > fastcgi_index index.php; > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > fastcgi_param APPLICATION_ENV development; > fastcgi_param HTTPS $https; > } > } > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241512,241512#msg-241512 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Mon Aug 5 07:39:02 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 5 Aug 2013 11:39:02 +0400 Subject: =?UTF-8?B?UmU6INCe0LTQvdCwINC60Y3RiC3Qt9C+0L3QsCwg0LzQvdC+0LPQviDRgdCw0Lk=?= =?UTF-8?B?0YLQvtCy?= In-Reply-To: References: Message-ID: <20130805073902.GR2130@mdounin.ru> Hello! On Mon, Aug 05, 2013 at 10:08:47AM +0300, Serghey Rodin wrote: > Вчера столкнулся с проблемой при использовании одной кэш-зоны для > нескольких сайтов. Спустя несколько минут все сайты показывают тот же > контент. На сколько я понял, одна зона может обслуживать несколько сайтов, > так как файлы с кэшем формируются на основе md5 от запрошенного браущером > url. Но видимо я не до конца понимаю логику работы. Ключ кеширования по умолчанию - $scheme$proxy_host$request_uri. http://nginx.org/r/proxy_cache_key -- Maxim Dounin http://nginx.org/en/donation.html From serghey.rodin at gmail.com Mon Aug 5 10:30:28 2013 From: serghey.rodin at gmail.com (Serghey Rodin) Date: Mon, 5 Aug 2013 13:30:28 +0300 Subject: =?UTF-8?B?UmU6INCe0LTQvdCwINC60Y3RiC3Qt9C+0L3QsCwg0LzQvdC+0LPQviDRgdCw0Lk=?= =?UTF-8?B?0YLQvtCy?= In-Reply-To: <20130805073902.GR2130@mdounin.ru> References: <20130805073902.GR2130@mdounin.ru> Message-ID: Это все объясняет. Спасибо! 2013/8/5 Maxim Dounin > Hello! > > On Mon, Aug 05, 2013 at 10:08:47AM +0300, Serghey Rodin wrote: > > > Вчера столкнулся с проблемой при использовании одной кэш-зоны для > > нескольких сайтов. Спустя несколько минут все сайты показывают тот же > > контент. На сколько я понял, одна зона может обслуживать несколько > сайтов, > > так как файлы с кэшем формируются на основе md5 от запрошенного браущером > > url. Но видимо я не до конца понимаю логику работы. > > Ключ кеширования по умолчанию - $scheme$proxy_host$request_uri. > > http://nginx.org/r/proxy_cache_key > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at knutov.com Mon Aug 5 17:15:21 2013 From: mail at knutov.com (Nick Knutov) Date: Mon, 05 Aug 2013 23:15:21 +0600 Subject: =?UTF-8?B?0J/QtdGA0LXQvNC10L3QvdCw0Y8gJGh0dHBz?= Message-ID: <51FFDDA9.40004@knutov.com> В нгинх - $https ?on? если соединение работает в режиме SSL, либо пустая строка А вот в апаче - HTTPS Will contain the text "on" if the connection is using SSL/TLS, or "off" otherwise. Вопрос - почему в нгинх сделано так, правильно ли это и не стоит ли поменять поведение этой переменной на как в апаче? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From postmaster at softsearch.ru Mon Aug 5 17:26:35 2013 From: postmaster at softsearch.ru (=?Windows-1251?B?zOj14OjrIMzu7eD4uOI=?=) Date: Mon, 5 Aug 2013 21:26:35 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <51FFDDA9.40004@knutov.com> References: <51FFDDA9.40004@knutov.com> Message-ID: <479397056.20130805212635@softsearch.ru> Здравствуйте, Nick. > В нгинх - > $https > ?on? если соединение работает в режиме SSL, либо пустая строка > А вот в апаче - > HTTPS > Will contain the text "on" if the connection is using SSL/TLS, or "off" > otherwise. > Вопрос - почему в нгинх сделано так, правильно ли это и не стоит ли > поменять поведение этой переменной на как в апаче? Вы можете сами поменять поведение, определив через map другую переменную, зависящую от значения $https. Для nginx-а иная практика - пустая строка выключено, непустая - включено. Сделано так потом, что многие директивы, в которых можно использовать переменные, включаются, когда только получают непустое значение, что весьма удобно. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Mon Aug 5 17:52:12 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 5 Aug 2013 21:52:12 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <51FFDDA9.40004@knutov.com> References: <51FFDDA9.40004@knutov.com> Message-ID: <201308052152.12457.vbart@nginx.com> On Monday 05 August 2013 21:15:21 Nick Knutov wrote: > В нгинх - > > $https > ?on? если соединение работает в режиме SSL, либо пустая строка > > А вот в апаче - > > HTTPS > Will contain the text "on" if the connection is using SSL/TLS, or "off" > otherwise. > > Вопрос - почему в нгинх сделано так, правильно ли это и не стоит ли > поменять поведение этой переменной на как в апаче? Предназначение этой переменной - служить конфигурацией по умолчанию для fastcgi, и других *cgi протоколов. Вы же, по-видимому, цитируете документацию по mod_rewrite. Для подобных задач в nginx всегда была переменная $scheme, гораздо более удобная на мой взгляд, чем апачевская HTTPS. Переменная $https появилась не так давно, тогда данный вопрос был тщательно изучен, и была выбрана реализация, совместимая с максимальным количеством приложений. В частности, в документации по PHP написано: 'HTTPS' Set to a non-empty value if the script was queried through the HTTPS protocol. @ http://php.net/manual/en/reserved.variables.server.php и не малое количество PHP кода написано так, что любое непустое значение в $_SERVER['HTTPS'] включая 'off' будет истолковано как положительное. Собственно одной из причин появления этой переменной послужили такие письма: http://mailman.nginx.org/pipermail/nginx/2011-September/029424.html Когда речь заходит о переменной окружения HTTPS (а не переменной HTTPS в модуле mod_rewrite), то Apache в этом месте ведет себя так: Apache + PHP Apache/2.2.21 mod_php 5.3.8 https: HTTPS == "on" http: HTTPS отсутствует Apache + mod_fastcgi + flup (Python) Apache/2.2.21 mod_fastcgi 2.4.7 flup-1.0.2 https: HTTPS == "on" http: HTTPS отсутствует Делайте выводы. -- Валентин Бартенев http://nginx.org/en/donation.html From mail at knutov.com Mon Aug 5 18:15:34 2013 From: mail at knutov.com (Nick Knutov) Date: Tue, 06 Aug 2013 00:15:34 +0600 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <479397056.20130805212635@softsearch.ru> References: <51FFDDA9.40004@knutov.com> <479397056.20130805212635@softsearch.ru> Message-ID: <51FFEBC6.40004@knutov.com> Ок, идею понятна, однако многие юзеры апача в для mod_rewrite в своих .htaccess ожидают другого поведения. Я сделал так: set $https_apache "off"; if ($https = "on") { set $https_apache $https; } [...] proxy_set_header HTTPS $https_apache; Есть причины переписать это на map? map $https $https_apache{ default "off"; "on" "on"; } Так? 05.08.2013 23:26, Михаил Монашёв пишет: >> А вот в апаче - > >> HTTPS >> Will contain the text "on" if the connection is using SSL/TLS, or "off" >> otherwise. > >> Вопрос - почему в нгинх сделано так, правильно ли это и не стоит ли >> поменять поведение этой переменной на как в апаче? > > > Вы можете сами поменять поведение, определив через map другую > переменную, зависящую от значения $https. > > Для nginx-а иная практика - пустая строка выключено, непустая - > включено. Сделано так потом, что многие директивы, в которых можно > использовать переменные, включаются, когда только получают непустое > значение, что весьма удобно. > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From postmaster at softsearch.ru Mon Aug 5 18:29:42 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 5 Aug 2013 22:29:42 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <51FFEBC6.40004@knutov.com> References: <51FFDDA9.40004@knutov.com> <479397056.20130805212635@softsearch.ru> <51FFEBC6.40004@knutov.com> Message-ID: <919414488.20130805222942@softsearch.ru> Здравствуйте, Nick. > Ок, идею понятна, однако многие юзеры апача в для mod_rewrite в своих > .htaccess ожидают другого поведения. > Я сделал так: > set $https_apache "off"; > if ($https = "on") { set $https_apache $https; } > [...] > proxy_set_header HTTPS $https_apache; > Есть причины переписать это на map? > map $https $https_apache{ > default "off"; > "on" "on"; > } > Так? Если if-а можно избежать, то его лучше избегать. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mail at knutov.com Mon Aug 5 18:35:59 2013 From: mail at knutov.com (Nick Knutov) Date: Tue, 06 Aug 2013 00:35:59 +0600 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <201308052152.12457.vbart@nginx.com> References: <51FFDDA9.40004@knutov.com> <201308052152.12457.vbart@nginx.com> Message-ID: <51FFF08F.40002@knutov.com> Я столкнулся с кучей .htaccess с правилами для mod_rewrite, где ожидаются значения off и on. И да, похоже что переменные окружения и mod_rewrite разные сущности, потому что у меня не заработало RewriteCond ${HTTPS} on но заработало RewriteCond ${HTTP:HTTPS} on Вопрос уже скорее про апач, но есть ли возможность добавить ему переменную HTTPS средствами извне при отсутствии mod_ssl (ссл терминируется на нгинх, у апача только хтпп)? И, соответсвенно, так, чтобы у ней были значения on|off, в отличии от переменной среды. 05.08.2013 23:52, Валентин Бартенев пишет: > Вы же, по-видимому, цитируете документацию по mod_rewrite. > [...] > Собственно одной из причин появления этой переменной послужили такие > письма: http://mailman.nginx.org/pipermail/nginx/2011-September/029424.html > [...] > Делайте выводы. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From vbart at nginx.com Mon Aug 5 19:20:59 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 5 Aug 2013 23:20:59 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <51FFF08F.40002@knutov.com> References: <51FFDDA9.40004@knutov.com> <201308052152.12457.vbart@nginx.com> <51FFF08F.40002@knutov.com> Message-ID: <201308052320.59684.vbart@nginx.com> On Monday 05 August 2013 22:35:59 Nick Knutov wrote: > Я столкнулся с кучей .htaccess с правилами для mod_rewrite, где > ожидаются значения off и on. > [...] Так а какое отношение nginx имеет к .htaccess и mod_rewrite? Если вы хотите прокидывать информацию о протоколе на Apache-бэкенд, то де-факто заголовки для таких целей X-Forwarded-*, но никак не HTTPS. > И да, похоже что переменные окружения и mod_rewrite разные сущности, > потому что у меня не заработало > RewriteCond ${HTTPS} on > но заработало > RewriteCond ${HTTP:HTTPS} on > > Вопрос уже скорее про апач, но есть ли возможность добавить ему > переменную HTTPS средствами извне при отсутствии mod_ssl (ссл > терминируется на нгинх, у апача только хтпп)? И, соответсвенно, так, > чтобы у ней были значения on|off, в отличии от переменной среды. > mod_rpaf вам в помощь, есть в большинстве дистрибутивов. -- Валентин Бартенев http://nginx.org/en/donation.html From isk at cupid.com Tue Aug 6 05:56:35 2013 From: isk at cupid.com (Olexander Shtepa) Date: Tue, 6 Aug 2013 08:56:35 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <51FFF08F.40002@knutov.com> References: <51FFDDA9.40004@knutov.com> <201308052152.12457.vbart@nginx.com> <51FFF08F.40002@knutov.com> Message-ID: <20130806085635.43a9e8b3@shtepa.cupidplc.priv> > Вопрос уже скорее про апач, но есть ли возможность добавить ему > переменную HTTPS средствами извне при отсутствии mod_ssl (ссл > терминируется на нгинх, у апача только хтпп)? Я делаю так: На nginx: proxy_set_header X-SCHEME $scheme; В apache: SetEnvIf X-SCHEME "^https$" HTTPS=on > И, соответсвенно, так, > чтобы у ней были значения on|off, в отличии от переменной среды. Если так прям хотите off, до можна добавить: SetEnvIf X-SCHEME "^http$" HTTPS=off From nginx-forum at nginx.us Tue Aug 6 10:30:37 2013 From: nginx-forum at nginx.us (shambler81) Date: Tue, 06 Aug 2013 06:30:37 -0400 Subject: =?UTF-8?B?bmdpbnggZGRvcyDQv9C+0LTQv9GA0LDQstC40YLRjCDQv9GA0LDQstC40LvQvg==?= Message-ID: Добрый день, коллеги, прошу помочь, что то не получается поймать быка за рога. Небольшой ддос доставляет неудобство серверу, прблизительно 10 тысач в минуту. Ширины канала хватает так что фактически меня устроит отдать доброжедателям 404 в запросах есть логика все они содержат ?начало_слово_цифры=цифры_конец нарисовла перенаправлялку на пустую страницу в .htaacess но всеравно не помогло RewriteCond %{QUERY_STRING} ^\w[0-9]{1,6}\=[0-9]{1,6}$ [NC] RewriteRule ^(.*) /404stop.html? [R=301,L] Хотя редирект по идее работет копировал с аксесс запросы, все переходят. решил отбростиь ребят сразу на nginx location / { if ($query_string ~* "^\w[0-9]{1,6}\=[0-9]{1,6}$"){ return 404; } } не срабатывает ;( может кто подскажет варианты решения или что не так ? Снизу привожу пример аксесс лога. 46.70.92.108 - - [06/Aug/2013:12:54:35 +0400] "GET /catalogue/doors/prestizh?vt24104=4104 HTTP/1.0" 503 290 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" 46.70.46.97 - - [06/Aug/2013:12:54:35 +0400] "GET /catalogue/doors/prestizh?vtt23625=3625 HTTP/1.0" 503 290 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0)" 178.72.188.216 - - [06/Aug/2013:12:55:37 +0400] "GET /?vtt8330=8330 HTTP/1.0" 200 8488 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" 178.72.184.136 - - [06/Aug/2013:12:54:35 +0400] "GET /?vtt3761=3761 HTTP/1.0" 503 290 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; MRSPUTNIK 2, 4, 1, 218; MRA 6.1 (build 6673); InfoPath.1; AskTbCLA/5.15.1.22229)" 178.72.190.75 - - [06/Aug/2013:12:54:35 +0400] "GET /catalogue/doors/prestizh?vt22423=2423 HTTP/1.0" 503 290 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; MRSPUTNIK 2, 4, 1, 150; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2)" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241632,241632#msg-241632 From nginx-forum at nginx.us Tue Aug 6 11:13:22 2013 From: nginx-forum at nginx.us (PbIXTOP) Date: Tue, 06 Aug 2013 07:13:22 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IGRkb3Mg0L/QvtC00L/RgNCw0LLQuNGC0Ywg0L/RgNCw0LLQuNC7?= =?UTF-8?B?0L4=?= In-Reply-To: References: Message-ID: <7efb3f49c5958700a6a261aedd765dfb.NginxMailingListRussian@forum.nginx.org> Вроде бы у вас не верное выражение должно быть так чтоб срабатывало if ($query_string ~* "^\w{1,3}[0-9]{1,6}\=[0-9]{1,6}$"){ return 404; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241632,241634#msg-241634 From nginx-forum at nginx.us Tue Aug 6 11:54:43 2013 From: nginx-forum at nginx.us (shambler81) Date: Tue, 06 Aug 2013 07:54:43 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IGRkb3Mg0L/QvtC00L/RgNCw0LLQuNGC0Ywg0L/RgNCw0LLQuNC7?= =?UTF-8?B?0L4=?= In-Reply-To: <7efb3f49c5958700a6a261aedd765dfb.NginxMailingListRussian@forum.nginx.org> References: <7efb3f49c5958700a6a261aedd765dfb.NginxMailingListRussian@forum.nginx.org> Message-ID: Да, большое спасибо, уже нашел. Проблемма была действительно в этом. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241632,241636#msg-241636 From stalker at altlinux.ru Tue Aug 6 13:07:30 2013 From: stalker at altlinux.ru (Anton Gorlov) Date: Tue, 06 Aug 2013 17:07:30 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> Message-ID: <5200F512.8010907@altlinux.ru> Не эффективно как показала практика. Пользователь за сутки может в админу заходить и 100 раз. Самописный костыль на основе fail2ban и ipset за сутки набанил порядка 30к ипов. сутки проходят - бан снимаетсяи ботнет возвращается в обратно. 04.08.2013 15:21, Vladislav Prodan пишет: > > --- Исходное сообщение --- > От кого: "Nick Knutov" > Дата: 3 августа 2013, 14:13:32 > > >> Тем, что он пропускает запросы на бекэнд. >> Размер ботнета, перебирающего пароли - примерно 100 000 ип. >> Он не весь сразу приходит, но в общем случае, или можно использовать >> простое ограничение вроде с одного ип не чаще 1 запроса в >> минуту/секунду, но это просто снижает нагрузку до приемлимого уровня, а >> не решает проблему. > У меня скрипт каждые 5 минут парсит общий (суточный) лог нгинкса nginx-access.log. > И если накапливается 30 запросов на перебор паролей вордпресса/джумлы с 1 IP, то этот IP добавляется в глобальный список deny. > From stalker at altlinux.ru Tue Aug 6 13:08:31 2013 From: stalker at altlinux.ru (Anton Gorlov) Date: Tue, 06 Aug 2013 17:08:31 +0400 Subject: =?UTF-8?B?UmU6IE1vZFNlY3VyaXR5LCDQt9Cw0YnQuNGC0LAgV1Ag0Lgg0LTQttGD0LzQu9GL?= =?UTF-8?B?INC+0YIg0LHQvtGC0L7Qsiwg0L/QtdGA0LXQsdC40YDQsNGO0YnQuNGFINC/?= =?UTF-8?B?0LDRgNC+0LvQuA==?= In-Reply-To: <1375617201.608414227.asffgsll@fmst-1.ukr.net> References: <51FC08F7.8020508@knutov.com> <20130803103103.GM2130@mdounin.ru> <51FCE5D1.2070407@knutov.com> <1375615126.142459272.2x4bgahp@fmst-1.ukr.net> <1375617201.608414227.asffgsll@fmst-1.ukr.net> Message-ID: <5200F54F.7080300@altlinux.ru> 04.08.2013 15:59, Vladislav Prodan пишет: >> >2. С участием владельца сайта переименовать файл для входа в какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, чтобы данное имя было известно только владельцу сайта. А на /administator/index.php поставить статическую заглушку, которую nginx может отдавать со скоростью пулемёта. > А лучше пароль на директорию повесить. В конечном счёте так и пришлось делать. Всё остальное не шибко помогало From mail at knutov.com Tue Aug 6 19:38:08 2013 From: mail at knutov.com (Nick Knutov) Date: Wed, 07 Aug 2013 01:38:08 +0600 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRodHRwcw==?= In-Reply-To: <20130806085635.43a9e8b3@shtepa.cupidplc.priv> References: <51FFDDA9.40004@knutov.com> <201308052152.12457.vbart@nginx.com> <51FFF08F.40002@knutov.com> <20130806085635.43a9e8b3@shtepa.cupidplc.priv> Message-ID: <520150A0.5020802@knutov.com> Спасибо, это полностью решило задачу. 06.08.2013 11:56, Olexander Shtepa пишет: >> Вопрос уже скорее про апач, но есть ли возможность добавить ему >> переменную HTTPS средствами извне при отсутствии mod_ssl (ссл >> терминируется на нгинх, у апача только хтпп)? > > Я делаю так: > На nginx: > proxy_set_header X-SCHEME $scheme; > В apache: > SetEnvIf X-SCHEME "^https$" HTTPS=on > >> И, соответсвенно, так, >> чтобы у ней были значения on|off, в отличии от переменной среды. > > Если так прям хотите off, до можна добавить: > SetEnvIf X-SCHEME "^http$" HTTPS=off -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From mail at knutov.com Tue Aug 6 19:39:06 2013 From: mail at knutov.com (Nick Knutov) Date: Wed, 07 Aug 2013 01:39:06 +0600 Subject: =?UTF-8?B?UmU6IG5naW54IGRkb3Mg0L/QvtC00L/RgNCw0LLQuNGC0Ywg0L/RgNCw0LLQuNC7?= =?UTF-8?B?0L4=?= In-Reply-To: References: <7efb3f49c5958700a6a261aedd765dfb.NginxMailingListRussian@forum.nginx.org> Message-ID: <520150DA.1090604@knutov.com> А еще вы скорее всего хотите отдавать return 444 вместо 404. 06.08.2013 17:54, shambler81 пишет: > Да, большое спасибо, уже нашел. > Проблемма была действительно в этом. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From universite at ukr.net Tue Aug 6 20:43:03 2013 From: universite at ukr.net (Vladislav V. Prodan) Date: Tue, 06 Aug 2013 23:43:03 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IGRkb3Mg0L/QvtC00L/RgNCw0LLQuNGC0Ywg0L/RgNCw0LLQuNC7?= =?UTF-8?B?0L4=?= In-Reply-To: <520150DA.1090604@knutov.com> References: <7efb3f49c5958700a6a261aedd765dfb.NginxMailingListRussian@forum.nginx.org> <520150DA.1090604@knutov.com> Message-ID: <52015FD7.8050009@ukr.net> 06.08.2013 22:39, Nick Knutov пишет: > А еще вы скорее всего хотите отдавать return 444 вместо 404. Очевидно, что "доброжелатели" ожидают 502, 503 или 504. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From sergey.kobzar at itcraft.org Wed Aug 7 17:06:06 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Wed, 07 Aug 2013 20:06:06 +0300 Subject: Nginx and logrotate In-Reply-To: <51FA28F3.9090303@itcraft.org> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> <20130801092021.GZ2130@mdounin.ru> <51FA28F3.9090303@itcraft.org> Message-ID: <52027E7E.3000900@itcraft.org> Продолжение истории: # ls -alh /var/log/nginx/ total 8.8G drwxr-xr-x 2 nginx root 4.0K Aug 7 03:10 . drwxr-xr-x 11 root root 4.0K Aug 7 03:10 .. -rw-r--r-- 1 nginx root 0 Aug 7 03:10 access.log -rw-r--r-- 1 nginx root 1.2G Aug 2 03:10 access.log-20130802 -rw-r--r-- 1 nginx root 1.2G Aug 3 03:10 access.log-20130803 -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 -rw-r--r-- 1 nginx root 2.2G Aug 7 19:59 access.log-20130807 ... Сейчас логи складываются в access.log-20130807. + отсутствует access.log-20130806. cat /etc/logrotate.d/nginx /var/log/nginx/*.log { daily rotate 5 missingok nocompress sharedscripts postrotate test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid` endscript } Сегодня утром получил сообщение от cron'а: gzip: stdin: file size changed while zipping gzip: stdin: file size changed while zipping Но так, как в /etc/logrotate.d/nginx есть nocompress, то есть подозрение, что это общесистемное. Any ideas? From slava.kokorin at gmail.com Wed Aug 7 17:56:22 2013 From: slava.kokorin at gmail.com (=?koi8-r?B?99HexdPMwdcg68/Lz9LJzg==?=) Date: Wed, 7 Aug 2013 21:56:22 +0400 Subject: Nginx and logrotate In-Reply-To: <52027E7E.3000900@itcraft.org> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> <20130801092021.GZ2130@mdounin.ru> <51FA28F3.9090303@itcraft.org> <52027E7E.3000900@itcraft.org> Message-ID: 07.08.2013, в 21:06, Sergey Kobzar написал(а): > Продолжение истории: > > # ls -alh /var/log/nginx/ > total 8.8G > drwxr-xr-x 2 nginx root 4.0K Aug 7 03:10 . > drwxr-xr-x 11 root root 4.0K Aug 7 03:10 .. > -rw-r--r-- 1 nginx root 0 Aug 7 03:10 access.log > -rw-r--r-- 1 nginx root 1.2G Aug 2 03:10 access.log-20130802 > -rw-r--r-- 1 nginx root 1.2G Aug 3 03:10 access.log-20130803 > -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 > -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 > -rw-r--r-- 1 nginx root 2.2G Aug 7 19:59 access.log-20130807 > ... > > Сейчас логи складываются в access.log-20130807. + отсутствует access.log-20130806. > > cat /etc/logrotate.d/nginx > /var/log/nginx/*.log { > daily > rotate 5 > missingok > nocompress > sharedscripts > postrotate > test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid` > endscript > } У вас PID файлы точно в /run ? Обычно это /var/run > > > Сегодня утром получил сообщение от cron'а: > gzip: stdin: file size changed while zipping > gzip: stdin: file size changed while zipping > > Но так, как в /etc/logrotate.d/nginx есть nocompress, то есть подозрение, что это общесистемное. > > Any ideas? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From sergey.kobzar at itcraft.org Wed Aug 7 18:15:42 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Wed, 07 Aug 2013 21:15:42 +0300 Subject: Nginx and logrotate In-Reply-To: References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> <20130801092021.GZ2130@mdounin.ru> <51FA28F3.9090303@itcraft.org> <52027E7E.3000900@itcraft.org> Message-ID: <52028ECE.9070402@itcraft.org> On 08/07/13 20:56, Вячеслав Кокорин wrote: > > 07.08.2013, в 21:06, Sergey Kobzar написал(а): > >> Продолжение истории: >> >> # ls -alh /var/log/nginx/ >> total 8.8G >> drwxr-xr-x 2 nginx root 4.0K Aug 7 03:10 . >> drwxr-xr-x 11 root root 4.0K Aug 7 03:10 .. >> -rw-r--r-- 1 nginx root 0 Aug 7 03:10 access.log >> -rw-r--r-- 1 nginx root 1.2G Aug 2 03:10 access.log-20130802 >> -rw-r--r-- 1 nginx root 1.2G Aug 3 03:10 access.log-20130803 >> -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 >> -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 >> -rw-r--r-- 1 nginx root 2.2G Aug 7 19:59 access.log-20130807 >> ... >> >> Сейчас логи складываются в access.log-20130807. + отсутствует access.log-20130806. >> >> cat /etc/logrotate.d/nginx >> /var/log/nginx/*.log { >> daily >> rotate 5 >> missingok >> nocompress >> sharedscripts >> postrotate >> test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid` >> endscript >> } > > У вас PID файлы точно в /run ? Обычно это /var/run Угу: # la /var/run lrwxrwxrwx 1 root root 4 Jan 23 2013 /var/run -> /run # ps ax | grep nginx 1965 ? Ss 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf 1966 ? S 35:55 nginx: worker process 1967 ? S 35:37 nginx: worker process 1969 ? S 35:08 nginx: worker process 1970 ? S 34:57 nginx: worker process 1971 ? S 34:55 nginx: worker process 1972 ? S 35:12 nginx: worker process 1973 ? S 35:11 nginx: worker process 1974 ? S 36:01 nginx: worker process # cat /run/nginx.pid 1965 >> Сегодня утром получил сообщение от cron'а: >> gzip: stdin: file size changed while zipping >> gzip: stdin: file size changed while zipping >> >> Но так, как в /etc/logrotate.d/nginx есть nocompress, то есть подозрение, что это общесистемное. >> >> Any ideas? From boris at talovikov.ru Thu Aug 8 07:43:08 2013 From: boris at talovikov.ru (Boris Talovikov) Date: Thu, 08 Aug 2013 13:43:08 +0600 Subject: Nginx and logrotate In-Reply-To: <52028ECE.9070402@itcraft.org> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> <20130801092021.GZ2130@mdounin.ru> <51FA28F3.9090303@itcraft.org> <52027E7E.3000900@itcraft.org> <52028ECE.9070402@itcraft.org> Message-ID: <52034C0C.3080904@talovikov.ru> 08.08.2013 00:15, Sergey Kobzar пишет: > On 08/07/13 20:56, Вячеслав Кокорин wrote: > >> >> 07.08.2013, в 21:06, Sergey Kobzar >> написал(а): >> >>> Продолжение истории: >>> >>> # ls -alh /var/log/nginx/ >>> total 8.8G >>> drwxr-xr-x 2 nginx root 4.0K Aug 7 03:10 . >>> drwxr-xr-x 11 root root 4.0K Aug 7 03:10 .. >>> -rw-r--r-- 1 nginx root 0 Aug 7 03:10 access.log >>> -rw-r--r-- 1 nginx root 1.2G Aug 2 03:10 access.log-20130802 >>> -rw-r--r-- 1 nginx root 1.2G Aug 3 03:10 access.log-20130803 >>> -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 >>> -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 >>> -rw-r--r-- 1 nginx root 2.2G Aug 7 19:59 access.log-20130807 >>> ... >>> >>> Сейчас логи складываются в access.log-20130807. + отсутствует >>> access.log-20130806. >>> >>> cat /etc/logrotate.d/nginx >>> /var/log/nginx/*.log { >>> daily >>> rotate 5 >>> missingok >>> nocompress >>> sharedscripts >>> postrotate >>> test -r /run/nginx.pid && kill -USR1 `cat >>> /run/nginx.pid` >>> endscript >>> } >> >> У вас PID файлы точно в /run ? Обычно это /var/run > > Угу: > > # la /var/run > lrwxrwxrwx 1 root root 4 Jan 23 2013 /var/run -> /run > > # ps ax | grep nginx > 1965 ? Ss 0:00 nginx: master process /usr/sbin/nginx -c > /etc/nginx/nginx.conf > 1966 ? S 35:55 nginx: worker process > 1967 ? S 35:37 nginx: worker process > 1969 ? S 35:08 nginx: worker process > 1970 ? S 34:57 nginx: worker process > 1971 ? S 34:55 nginx: worker process > 1972 ? S 35:12 nginx: worker process > 1973 ? S 35:11 nginx: worker process > 1974 ? S 36:01 nginx: worker process > > # cat /run/nginx.pid > 1965 > > >>> Сегодня утром получил сообщение от cron'а: >>> gzip: stdin: file size changed while zipping >>> gzip: stdin: file size changed while zipping >>> >>> Но так, как в /etc/logrotate.d/nginx есть nocompress, то есть >>> подозрение, что это общесистемное. >>> >>> Any ideas? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Здравствуйте, а можно увидеть вывод команды logrotate -d /etc/logrotate.conf ? From sergey.kobzar at itcraft.org Thu Aug 8 08:36:11 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Thu, 08 Aug 2013 11:36:11 +0300 Subject: Nginx and logrotate In-Reply-To: <52034C0C.3080904@talovikov.ru> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> <20130801092021.GZ2130@mdounin.ru> <51FA28F3.9090303@itcraft.org> <52027E7E.3000900@itcraft.org> <52028ECE.9070402@itcraft.org> <52034C0C.3080904@talovikov.ru> Message-ID: <5203587B.8050509@itcraft.org> On 08/08/13 10:43, Boris Talovikov wrote: >>>> cat /etc/logrotate.d/nginx >>>> /var/log/nginx/*.log { >>>> daily >>>> rotate 5 >>>> missingok >>>> nocompress >>>> sharedscripts >>>> postrotate >>>> test -r /run/nginx.pid && kill -USR1 `cat >>>> /run/nginx.pid` >>>> endscript >>>> } >>> >>> У вас PID файлы точно в /run ? Обычно это /var/run >> >> Угу: >> >> # la /var/run >> lrwxrwxrwx 1 root root 4 Jan 23 2013 /var/run -> /run >> >> # ps ax | grep nginx >> 1965 ? Ss 0:00 nginx: master process /usr/sbin/nginx -c >> /etc/nginx/nginx.conf >> 1966 ? S 35:55 nginx: worker process >> 1967 ? S 35:37 nginx: worker process >> 1969 ? S 35:08 nginx: worker process >> 1970 ? S 34:57 nginx: worker process >> 1971 ? S 34:55 nginx: worker process >> 1972 ? S 35:12 nginx: worker process >> 1973 ? S 35:11 nginx: worker process >> 1974 ? S 36:01 nginx: worker process >> >> # cat /run/nginx.pid >> 1965 >> >> >>>> Сегодня утром получил сообщение от cron'а: >>>> gzip: stdin: file size changed while zipping >>>> gzip: stdin: file size changed while zipping >>>> >>>> Но так, как в /etc/logrotate.d/nginx есть nocompress, то есть >>>> подозрение, что это общесистемное. >>>> >>>> Any ideas? >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Здравствуйте, а можно увидеть вывод команды > > logrotate -d /etc/logrotate.conf ? Ну вот сегодня отротировалось все нормально: -rw-r--r-- 1 nginx root 268M Aug 8 11:32 access.log -rw-r--r-- 1 nginx root 1.2G Aug 3 03:10 access.log-20130803 -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 -rw-r--r-- 1 nginx root 2.5G Aug 8 01:31 access.log-20130807 -rw-r--r-- 1 nginx root 20M Aug 8 03:10 access.log-20130808 # logrotate -d /etc/logrotate.conf reading config file /etc/logrotate.conf including /etc/logrotate.d reading config file elog-save-summary reading config file exim reading config file munin reading config file mysql reading config file nginx reading config file openrc reading config file php-fpm reading config file rsyncd reading config file sphinx reading config file syslog-ng Handling 15 logs ... rotating pattern: /var/log/nginx/*.log after 1 days (5 rotations) empty log files are not rotated, old logs are removed considering log /var/log/nginx/default-ssl_access.log log does not need rotating considering log /var/log/nginx/default-ssl_error.log log does not need rotating considering log /var/log/nginx/access.log log does not need rotating considering log /var/log/nginx/error.log log does not need rotating Ротацию логов для других сервисов поскипал. From nginx-forum at nginx.us Thu Aug 8 13:57:53 2013 From: nginx-forum at nginx.us (init0) Date: Thu, 08 Aug 2013 09:57:53 -0400 Subject: =?UTF-8?B?0J/RgNC+0LLQtdGA0LrQsCDQuCDQvtGC0LTQsNGH0LAg0YTQsNC50LvQsA==?= Message-ID: Всем привет! Есть проблема, необходимо проверять наличие кастомного файла robots.txt лежащего НЕ в корне проекта. Если этот файл существует, отдавать его. Если не существует, отдавать стандартный robots.txt который лежит в корне проекта, он там всегда есть. Подможите чем можете! Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241702,241702#msg-241702 From vbart at nginx.com Thu Aug 8 13:59:53 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Aug 2013 17:59:53 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: References: Message-ID: <201308081759.53836.vbart@nginx.com> On Thursday 08 August 2013 17:57:53 init0 wrote: > Всем привет! > > Есть проблема, необходимо проверять наличие кастомного файла robots.txt > лежащего НЕ в корне проекта. > Если этот файл существует, отдавать его. > Если не существует, отдавать стандартный robots.txt который лежит в корне > проекта, он там всегда есть. > [...] http://nginx.org/r/root/ru -- Валентин Бартенев http://nginx.org/en/donation.html From dmitriy at lyalyuev.info Thu Aug 8 14:01:27 2013 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Thu, 08 Aug 2013 17:01:27 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: References: Message-ID: <5203A4B7.10206@lyalyuev.info> Вероятно это поможет: http://nginx.org/ru/docs/http/ngx_http_core_module.html#try_files 08.08.2013 16:57, init0 пишет: > Всем привет! > > Есть проблема, необходимо проверять наличие кастомного файла robots.txt > лежащего НЕ в корне проекта. > Если этот файл существует, отдавать его. > Если не существует, отдавать стандартный robots.txt который лежит в корне > проекта, он там всегда есть. > > > > Подможите чем можете! > Спасибо! > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241702,241702#msg-241702 > > _______________________________________________ > 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 a.vasilishin at kpi.ua Thu Aug 8 13:02:16 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 08 Aug 2013 17:02:16 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: References: Message-ID: <520396D8.6020908@kpi.ua> 08.08.2013 17:57, init0 пишет: > Всем привет! > > Есть проблема, необходимо проверять наличие кастомного файла robots.txt > лежащего НЕ в корне проекта. > Если этот файл существует, отдавать его. > Если не существует, отдавать стандартный robots.txt который лежит в корне > проекта, он там всегда есть. > > > > Подможите чем можете! > Спасибо! > location /robots.txt { try_files /path/to/custom$uri $document_root$uri } From nginx-forum at nginx.us Thu Aug 8 14:09:06 2013 From: nginx-forum at nginx.us (init0) Date: Thu, 08 Aug 2013 10:09:06 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: <520396D8.6020908@kpi.ua> References: <520396D8.6020908@kpi.ua> Message-ID: <5bbe50c297314dcb480ae7d62afd524b.NginxMailingListRussian@forum.nginx.org> Андрей Василишин Wrote: ------------------------------------------------------- > 08.08.2013 17:57, init0 пишет: > > Всем привет! > > > > Есть проблема, необходимо проверять наличие кастомного файла > robots.txt > > лежащего НЕ в корне проекта. > > Если этот файл существует, отдавать его. > > Если не существует, отдавать стандартный robots.txt который лежит в > корне > > проекта, он там всегда есть. > > > > > > > > Подможите чем можете! > > Спасибо! > > > > location /robots.txt { > try_files /path/to/custom$uri $document_root$uri > } > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Я пробовал через true_files Либо получалась рекурсия, либо 404( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241702,241706#msg-241706 From dmitriy at lyalyuev.info Thu Aug 8 14:10:27 2013 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Thu, 08 Aug 2013 17:10:27 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: <5bbe50c297314dcb480ae7d62afd524b.NginxMailingListRussian@forum.nginx.org> References: <520396D8.6020908@kpi.ua> <5bbe50c297314dcb480ae7d62afd524b.NginxMailingListRussian@forum.nginx.org> Message-ID: <5203A6D3.8010300@lyalyuev.info> Вероятно все же стоит попробовать trY_files вместо trUE_files. 08.08.2013 17:09, init0 пишет: > Андрей Василишин Wrote: > ------------------------------------------------------- >> 08.08.2013 17:57, init0 пишет: >>> Всем привет! >>> >>> Есть проблема, необходимо проверять наличие кастомного файла >> robots.txt >>> лежащего НЕ в корне проекта. >>> Если этот файл существует, отдавать его. >>> Если не существует, отдавать стандартный robots.txt который лежит в >> корне >>> проекта, он там всегда есть. >>> >>> >>> >>> Подможите чем можете! >>> Спасибо! >>> >> location /robots.txt { >> try_files /path/to/custom$uri $document_root$uri >> } >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > Я пробовал через true_files > Либо получалась рекурсия, либо 404( > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241702,241706#msg-241706 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Dmitriy Lyalyuev http://lyalyuev.info From nginx-forum at nginx.us Thu Aug 8 15:19:17 2013 From: nginx-forum at nginx.us (Night Romantic) Date: Thu, 08 Aug 2013 11:19:17 -0400 Subject: =?UTF-8?B?bmdpbnggRVNNVFAgLSDQv9GA0L7QsdC70LXQvNCwICg/KQ==?= Message-ID: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> Всем доброго дня! Столкнулся с проблемой, которая *может быть* связана с использованием nginx в качестве ESMTP proxy (не уверен, что дело в nginx). Предыстория: Провайдер почты конторы, где я работаю, судя по всему, использует nginx ESMTP proxy на серверах входящей почты. Письма от одного из заказчиков нам не доставляются, "отлуп" выглядит так: 500 5.5.1 Invalid command. Отлуп получается в ответ на HELO <имя_сервера>. Заказчик использует свой почтовый сервер, работающий на Windows Server. Общение с техподдержкой провайдера никаких результатов не даёт. Симптомы проблемы: Подключаюсь к почтовому серверу провайдера с помощью телнета, пытаюсь "вручную" написать себе письмо, передавая серверу стандартные SMTP команды. Из линукс - всё работает, как и должно, проблем не вижу. Из Винды - с помощью telnet.exe - вижу 500 5.5.1 Invalid command в ответ на любую команду, а также на нажатие клавиши [пробел] и [точка]. T.e. введя [enter] вижу: helo 500 5.5.1 Invalid command mx.500 5.5.1 Invalid command test.500 5.5.1 Invalid command com 500 5.5.1 Invalid command (на [пробел] "отлуп", на каждую точку "отлуп", и на нажатие [enter] -- контрольный в голову, видимо ;-) Делаю то же самое с помощью putty -- ситуация получше, и тестовое письмо отправить удаётся, но всё равно есть странности. Вот я подключился, ввёл "helo" (специально без имени сервера-отправителя), затем ввёл quit: helo 500 5.5.1 Invalid command quit 500 5.5.1 Invalid command Делаю то же из линукс: helo 501 5.5.4 Invalid argument quit 221 2.0.0 Bye Connection closed by foreign host. Почувствуйте разницу, что называется. Предполагаю, что при попытке отправить письмо с почтового сервера заказчика (который живёт на Винде) происходит примерно то же самое, что я наблюдаю в телнет-сессии. Кривизна Винды вообще и telnet.exe тут не при чём, потому как телнет-сессии при помощи telnet.exe с mail.ru, yandex.ru (не знаю, что за ПО они используют), с серверами Postfix и Exim и вообще со всеми, кого я только ни пробовал -- проходят без проблем. Предполагаю, что дело именно в настройках серверов входящей почты (в nginx или нижележащей ОС - не знаю). А вот rambler.ru, по-видимому, использует ту же схему, что и мой хостер -- и с теми же самыми симптомами. Ещё предполагаю, что используемая ОС в обоих случаях -- FreeBSD (точно не знаю). Сервера, на которых можно увидеть вышеописанное поведение: моего хостера: mxs.ht-systems.ru (78.110.50.88, 78.110.50.89) рамблера: imx1.rambler.ru, imx2.rambler.ru (81.19.66.234, 81.19.66.235) Поиск в Интернете по описанной проблеме (с самыми различными вариантами запросов) ответа не дал, зато сложилось впечатление, что использование nginx в качестве ESMTP proxy -- это некая экзотика. Так ли это, уважаемые пользователи nginx? Использует ли кто-то nginx в названном качестве, и если да, воспроизводима ли проблема на вашем сервере? С уважением, Алексей Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241708,241708#msg-241708 From nginx-forum at nginx.us Thu Aug 8 15:22:21 2013 From: nginx-forum at nginx.us (init0) Date: Thu, 08 Aug 2013 11:22:21 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: <5bbe50c297314dcb480ae7d62afd524b.NginxMailingListRussian@forum.nginx.org> References: <520396D8.6020908@kpi.ua> <5bbe50c297314dcb480ae7d62afd524b.NginxMailingListRussian@forum.nginx.org> Message-ID: <70d18d96b1ccdcbbba07621548282810.NginxMailingListRussian@forum.nginx.org> Опечатался, всегда пробовал try_files Все еще отказывается работать Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241702,241709#msg-241709 From nginx-forum at nginx.us Thu Aug 8 15:23:49 2013 From: nginx-forum at nginx.us (init0) Date: Thu, 08 Aug 2013 11:23:49 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: <5203A6D3.8010300@lyalyuev.info> References: <5203A6D3.8010300@lyalyuev.info> Message-ID: <6705f1611e3055b8b85bc4ce87af9b11.NginxMailingListRussian@forum.nginx.org> Опечатка, всегда пробовал try_files Все еще отказывается работать Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241702,241710#msg-241710 From vbart at nginx.com Thu Aug 8 15:52:11 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Aug 2013 19:52:11 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: <6705f1611e3055b8b85bc4ce87af9b11.NginxMailingListRussian@forum.nginx.org> References: <5203A6D3.8010300@lyalyuev.info> <6705f1611e3055b8b85bc4ce87af9b11.NginxMailingListRussian@forum.nginx.org> Message-ID: <201308081952.11204.vbart@nginx.com> On Thursday 08 August 2013 19:23:49 init0 wrote: > Опечатка, всегда пробовал try_files > Все еще отказывается работать > А пробовали прочитать документацию? Если просто пробовать try_files, без понимания того, что последним параметром задается внутреннее перенаправление, а остальные параметры задают URI относительно корня, то ничего путного не получится. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Aug 8 16:27:31 2013 From: nginx-forum at nginx.us (init0) Date: Thu, 08 Aug 2013 12:27:31 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAg0Lgg0L7RgtC00LDRh9CwINGE0LDQudC70LA=?= In-Reply-To: <201308081952.11204.vbart@nginx.com> References: <201308081952.11204.vbart@nginx.com> Message-ID: <34ee84c80eb4b8ea4910f8a1e0696e4c.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Thursday 08 August 2013 19:23:49 init0 wrote: > > Опечатка, всегда пробовал try_files > > Все еще отказывается работать > > > > А пробовали прочитать документацию? Если просто пробовать try_files, > без понимания того, что последним параметром задается внутреннее > перенаправление, а остальные параметры задают URI относительно корня, > то ничего путного не получится. > > -- > Валентин Бартенев > 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,241702,241712#msg-241712 From nefer05 at gmail.com Thu Aug 8 19:08:01 2013 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Thu, 8 Aug 2013 23:08:01 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> References: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> Message-ID: В качестве предложения: а если попробовать использовать EHLO? 2013/8/8 Night Romantic > Всем доброго дня! > > Столкнулся с проблемой, которая *может быть* связана с использованием nginx > в качестве ESMTP proxy (не уверен, что дело в nginx). > > Предыстория: > > Провайдер почты конторы, где я работаю, судя по всему, использует nginx > ESMTP proxy на серверах входящей почты. > Письма от одного из заказчиков нам не доставляются, "отлуп" выглядит так: > 500 5.5.1 Invalid command. Отлуп получается в ответ на HELO <имя_сервера>. > Заказчик использует свой почтовый сервер, работающий на Windows Server. > Общение с техподдержкой провайдера никаких результатов не даёт. > > Симптомы проблемы: > > Подключаюсь к почтовому серверу провайдера с помощью телнета, пытаюсь > "вручную" написать себе письмо, передавая серверу стандартные SMTP команды. > Из линукс - всё работает, как и должно, проблем не вижу. > > Из Винды - с помощью telnet.exe - вижу 500 5.5.1 Invalid command в ответ на > любую команду, а также на нажатие клавиши [пробел] и [точка]. > T.e. введя [enter] вижу: > > helo 500 5.5.1 Invalid command > mx.500 5.5.1 Invalid command > test.500 5.5.1 Invalid command > com > 500 5.5.1 Invalid command > > (на [пробел] "отлуп", на каждую точку "отлуп", и на нажатие [enter] -- > контрольный в голову, видимо ;-) > > > Делаю то же самое с помощью putty -- ситуация получше, и тестовое письмо > отправить удаётся, но всё равно есть странности. > Вот я подключился, ввёл "helo" (специально без имени сервера-отправителя), > затем ввёл quit: > > helo > 500 5.5.1 Invalid command > quit > 500 5.5.1 Invalid command > > Делаю то же из линукс: > > helo > 501 5.5.4 Invalid argument > quit > 221 2.0.0 Bye > Connection closed by foreign host. > > Почувствуйте разницу, что называется. > > > Предполагаю, что при попытке отправить письмо с почтового сервера заказчика > (который живёт на Винде) происходит примерно то же самое, что я наблюдаю в > телнет-сессии. > > Кривизна Винды вообще и telnet.exe тут не при чём, потому как телнет-сессии > при помощи telnet.exe с mail.ru, yandex.ru (не знаю, что за ПО они > используют), с серверами Postfix и Exim и вообще со всеми, кого я только ни > пробовал -- проходят без проблем. Предполагаю, что дело именно в настройках > серверов входящей почты (в nginx или нижележащей ОС - не знаю). > > А вот rambler.ru, по-видимому, использует ту же схему, что и мой хостер > -- и > с теми же самыми симптомами. Ещё предполагаю, что используемая ОС в обоих > случаях -- FreeBSD (точно не знаю). > > Сервера, на которых можно увидеть вышеописанное поведение: > моего хостера: mxs.ht-systems.ru (78.110.50.88, 78.110.50.89) > рамблера: imx1.rambler.ru, imx2.rambler.ru (81.19.66.234, 81.19.66.235) > > > Поиск в Интернете по описанной проблеме (с самыми различными вариантами > запросов) ответа не дал, зато сложилось впечатление, что использование > nginx > в качестве ESMTP proxy -- это некая экзотика. Так ли это, уважаемые > пользователи nginx? Использует ли кто-то nginx в названном качестве, и если > да, воспроизводима ли проблема на вашем сервере? > > > С уважением, > Алексей > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,241708,241708#msg-241708 > > _______________________________________________ > 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 citrin at citrin.ru Thu Aug 8 19:27:12 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu, 08 Aug 2013 23:27:12 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> References: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> Message-ID: <5203F110.7010001@citrin.ru> 8/8/13 7:19 PM, Night Romantic пишет: > Из Винды - с помощью telnet.exe - вижу 500 5.5.1 Invalid command в ответ на > любую команду, а также на нажатие клавиши [пробел] и [точка]. > T.e. введя [enter] вижу: > > helo 500 5.5.1 Invalid command > mx.500 5.5.1 Invalid command > test.500 5.5.1 Invalid command > com > 500 5.5.1 Invalid command 1. Посмотрите для начала с помощью tcpump/wireshark что реально передает по сети этот telnet.exe 2. Есть подозрение, что helo и mx. отправляются в разных ip-пакетах, а данная реализация smtp получив данные из syscall read() сразу пытается их обработать как команду, не дожидаясь CR LF. И вряд ли так делает nginx. From nginx-forum at nginx.us Fri Aug 9 01:03:05 2013 From: nginx-forum at nginx.us (anon) Date: Thu, 08 Aug 2013 21:03:05 -0400 Subject: =?UTF-8?B?0LHQu9C+0LrQuNGA0L7QstC60LAg0LrQu9C40LXQvdGC0L7QsiDQv9C+INC60L4=?= =?UTF-8?B?0LzQsdC40L3QsNGG0LjQuCBJUC3QsNC00YDQtdGB0LAg0LggdXNlciBhZ2Vu?= =?UTF-8?B?dA==?= Message-ID: <850a925a25bc481ff03654c7466f9d5e.NginxMailingListRussian@forum.nginx.org> Какое можете предложить наиболее эффективное решение для блокировки клиентов по паре IP-адрес (в идеале - подсеть) + строка user agent? Для упрощения предположим, что user agent всегда постоянный. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241719,241719#msg-241719 From auskov at neolabs.kz Fri Aug 9 02:51:54 2013 From: auskov at neolabs.kz (Alexander Uskov) Date: Fri, 9 Aug 2013 08:51:54 +0600 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> References: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130809085154.1c76a39b@nlb01lx002.neolabs01.local> В Thu, 08 Aug 2013 11:19:17 -0400 "Night Romantic" пишет: > Провайдер почты конторы, где я работаю, судя по всему, использует > nginx ESMTP proxy на серверах входящей почты. > Письма от одного из заказчиков нам не доставляются, "отлуп" выглядит > так: 500 5.5.1 Invalid command. Отлуп получается в ответ на HELO У меня была очень похожая проблема была при использовании PIX файрвола. Он вмешивался в сессию и резал всё, что хоть немного отличалось, в его понимании, от идеальной smtp сессии. Разобраться смог только дебажа входящий на tcp/25 на сервере. ~~~ wbr, Alexander Uskov From chipitsine at gmail.com Fri Aug 9 04:08:09 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Fri, 9 Aug 2013 10:08:09 +0600 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <20130809085154.1c76a39b@nlb01lx002.neolabs01.local> References: <589242a59c3a7d114b62a8487e6f1049.NginxMailingListRussian@forum.nginx.org> <20130809085154.1c76a39b@nlb01lx002.neolabs01.local> Message-ID: у postfix, кстати, есть специальный PIX-овый хак )) 9 августа 2013 г., 8:51 пользователь Alexander Uskov написал: > В Thu, 08 Aug 2013 11:19:17 -0400 > "Night Romantic" пишет: > >> Провайдер почты конторы, где я работаю, судя по всему, использует >> nginx ESMTP proxy на серверах входящей почты. >> Письма от одного из заказчиков нам не доставляются, "отлуп" выглядит >> так: 500 5.5.1 Invalid command. Отлуп получается в ответ на HELO > У меня была очень похожая проблема была при использовании PIX файрвола. > Он вмешивался в сессию и резал всё, что хоть немного отличалось, в его > понимании, от идеальной smtp сессии. Разобраться смог только дебажа > входящий на tcp/25 на сервере. > > ~~~ > wbr, Alexander Uskov > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Fri Aug 9 05:01:45 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 9 Aug 2013 09:01:45 +0400 Subject: =?UTF-8?B?UmU6INCx0LvQvtC60LjRgNC+0LLQutCwINC60LvQuNC10L3RgtC+0LIg0L/QviA=?= =?UTF-8?B?0LrQvtC80LHQuNC90LDRhtC40LggSVAt0LDQtNGA0LXRgdCwINC4IHVzZXIg?= =?UTF-8?B?YWdlbnQ=?= In-Reply-To: <850a925a25bc481ff03654c7466f9d5e.NginxMailingListRussian@forum.nginx.org> References: <850a925a25bc481ff03654c7466f9d5e.NginxMailingListRussian@forum.nginx.org> Message-ID: <611551389.20130809090145@softsearch.ru> Здравствуйте, anon. > Какое можете предложить наиболее эффективное решение для блокировки > клиентов по паре IP-адрес (в идеале - подсеть) + строка user agent? > Для упрощения предположим, что user agent всегда постоянный. Генерить файлик с map{} и инклудить его в основной конфиг. А раз в минуту или при изменении файлика посылать nginx-у сигнал, чтобы он перечитывал свой конфиг -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Aug 9 06:31:11 2013 From: nginx-forum at nginx.us (Night Romantic) Date: Fri, 09 Aug 2013 02:31:11 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: References: Message-ID: <985e2b9e91346653b49e4f5dffa18226.NginxMailingListRussian@forum.nginx.org> Никакой разницы в поведении с HELO: подключаюсь из Линукс - получаю нормальные ответы, подключаюсь из Винды: вижу в ответ Invalid Command Роман Москвитин Wrote: ------------------------------------------------------- > В качестве предложения: а если попробовать использовать EHLO? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241708,241725#msg-241725 From onokonem at gmail.com Fri Aug 9 06:36:40 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 9 Aug 2013 10:36:40 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <985e2b9e91346653b49e4f5dffa18226.NginxMailingListRussian@forum.nginx.org> References: <985e2b9e91346653b49e4f5dffa18226.NginxMailingListRussian@forum.nginx.org> Message-ID: > Никакой разницы в поведении с HELO: > подключаюсь из Линукс - получаю нормальные ответы, подключаюсь из Винды: > вижу в ответ Invalid Command а поглядите, действительно, на сессию в снифере. наверняка дело в конце строки, винда шлет \r\n, а положено \n. From nginx-forum at nginx.us Fri Aug 9 07:19:40 2013 From: nginx-forum at nginx.us (Night Romantic) Date: Fri, 09 Aug 2013 03:19:40 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: References: Message-ID: И в винде, и в Линукс в конце строки \r\n В wireshark Виндовой сессии бросается в глаза, что каждый пакет от меня имеет неверную контрольную сумму: Header checksum: 0x0000 [incorrect, should be 0x68b3 (may be caused by "IP checksum offload"?)] Daniel Podolsky Wrote: ------------------------------------------------------- > а поглядите, действительно, на сессию в снифере. наверняка дело в > конце строки, винда шлет \r\n, а положено \n. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241708,241727#msg-241727 From nginx-forum at nginx.us Fri Aug 9 07:29:21 2013 From: nginx-forum at nginx.us (Night Romantic) Date: Fri, 09 Aug 2013 03:29:21 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <5203F110.7010001@citrin.ru> References: <5203F110.7010001@citrin.ru> Message-ID: > 1. Посмотрите для начала с помощью tcpump/wireshark что реально > передает > по сети этот telnet.exe Как написал в ответ на другой пост, первое, что бросается в глаза -- большая фрагментация и неправильная контрольная сумма у каждого пакета из Винды: Header checksum: 0x0000 [incorrect, should be 0x68ae (may be caused by "IP checksum offload"?)] Если поделюсь соответствующими кусочками дампов - это поможет? Сам не большой специалист. > 2. Есть подозрение, что helo и mx. отправляются в разных ip-пакетах, а > данная реализация smtp получив данные из syscall read() сразу пытается > их обработать как команду, не дожидаясь CR LF. И вряд ли так делает > nginx. Вот это очень похоже на правду (нажал пробел, точку или цифру - тут же увидел в ответ Invalid Command), ещё до нажатия enter (и генерации cr lf). Насчёт реализации smtp. Если nginx используется в качестве ESMTP - ответы на мои smtp команды я получаю от него -- или от того, что "ниже", так сказать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241708,241728#msg-241728 From onokonem at gmail.com Fri Aug 9 07:51:03 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 9 Aug 2013 11:51:03 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: References: <5203F110.7010001@citrin.ru> Message-ID: > Насчёт реализации smtp. Если nginx используется в качестве ESMTP - ответы на > мои smtp команды я получаю от него -- или от того, что "ниже", так сказать? От nginx. From sergey.kobzar at itcraft.org Fri Aug 9 09:12:17 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 09 Aug 2013 12:12:17 +0300 Subject: Nginx and logrotate In-Reply-To: <5203587B.8050509@itcraft.org> References: <51F97C94.30303@itcraft.org> <201308010214.30476.vbart@nginx.com> <51FA0DEB.9050908@itcraft.org> <20130801092021.GZ2130@mdounin.ru> <51FA28F3.9090303@itcraft.org> <52027E7E.3000900@itcraft.org> <52028ECE.9070402@itcraft.org> <52034C0C.3080904@talovikov.ru> <5203587B.8050509@itcraft.org> Message-ID: <5204B271.4010107@itcraft.org> Продолжение исторрии: # la /var/log/nginx/ | grep access.log -rw-r--r-- 1 nginx root 0 Aug 9 03:10 access.log -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 -rw-r--r-- 1 nginx root 2.5G Aug 8 01:31 access.log-20130807 -rw-r--r-- 1 nginx root 20M Aug 8 03:10 access.log-20130808 -rw-r--r-- 1 nginx root 1.5G Aug 9 12:03 access.log-20130809 Сейчас все пишется в access.log-20130809 На днях после изменения настроек php-fpm полезли ошибки: /var/log/nginx/error.log:2013/08/07 23:49:53 [error] 1973#0: *16067909 FastCGI sent in stderr: "the log buffer is full (1024). The access log request has been truncated" while reading response header from upstream Я добавил: access_log /var/log/nginx/access.log main buffer=2k; Ошибки прекратились, но сегодня после очередной ротации снова вылезло: /var/log/nginx/error.log-20130809:2013/08/09 10:09:35 [error] 23100#0: *479024 FastCGI sent in stderr: "the log buffer is full (1024). The access log request has been truncated" Есть какие=то идеи? Попутный вопрос: В документации по access_log http://nginx.org/ru/docs/http/ngx_http_log_module.html написано: Размер буфера должен быть не больше размера атомарной записи в дисковый файл. Для FreeBSD этот размер неограничен. Я правильно понимаю, что для Linux размер буфера не должен быть больше размера блока FS? # tune2fs -l /dev/sda1 | grep 'Block size' Block size: 4096 From vbart at nginx.com Fri Aug 9 09:49:36 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 9 Aug 2013 13:49:36 +0400 Subject: Nginx and logrotate In-Reply-To: <5204B271.4010107@itcraft.org> References: <51F97C94.30303@itcraft.org> <5203587B.8050509@itcraft.org> <5204B271.4010107@itcraft.org> Message-ID: <201308091349.36450.vbart@nginx.com> On Friday 09 August 2013 13:12:17 Sergey Kobzar wrote: > Продолжение исторрии: > > # la /var/log/nginx/ | grep access.log > -rw-r--r-- 1 nginx root 0 Aug 9 03:10 access.log > -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 > -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 > -rw-r--r-- 1 nginx root 2.5G Aug 8 01:31 access.log-20130807 > -rw-r--r-- 1 nginx root 20M Aug 8 03:10 access.log-20130808 > -rw-r--r-- 1 nginx root 1.5G Aug 9 12:03 access.log-20130809 > > Сейчас все пишется в access.log-20130809 > > На днях после изменения настроек php-fpm полезли ошибки: > /var/log/nginx/error.log:2013/08/07 23:49:53 [error] 1973#0: *16067909 > FastCGI sent in stderr: "the log buffer is full (1024). The access log > request has been truncated" while reading response header from upstream > > Я добавил: > access_log /var/log/nginx/access.log main buffer=2k; > > Ошибки прекратились, но сегодня после очередной ротации снова вылезло: > > /var/log/nginx/error.log-20130809:2013/08/09 10:09:35 [error] 23100#0: > *479024 FastCGI sent in stderr: "the log buffer is full (1024). The > access log request has been truncated" > > Есть какие=то идеи? > Ошибки на стороне php-fpm никакого отношения к access_log на стороне nginx не имеют. Не говоря уж о том, что и в случае access_log в nginx-е, параметр buffer он вообще про другое. > > Попутный вопрос: > В документации по access_log > http://nginx.org/ru/docs/http/ngx_http_log_module.html написано: > > Размер буфера должен быть не больше размера атомарной записи в дисковый > файл. Для FreeBSD этот размер неограничен. > > Я правильно понимаю, что для Linux размер буфера не должен быть больше > размера блока FS? > > # tune2fs -l /dev/sda1 | grep 'Block size' > Block size: 4096 > Там много факторов, начиная от версии ядра и заканчивая типом FS. Будь ответ настолько простым - мы бы указали это в документации. -- Валентин Бартенев http://nginx.org/en/donation.html From sergey.kobzar at itcraft.org Fri Aug 9 10:02:16 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 09 Aug 2013 13:02:16 +0300 Subject: Nginx and logrotate In-Reply-To: <201308091349.36450.vbart@nginx.com> References: <51F97C94.30303@itcraft.org> <5203587B.8050509@itcraft.org> <5204B271.4010107@itcraft.org> <201308091349.36450.vbart@nginx.com> Message-ID: <5204BE28.5030100@itcraft.org> On 08/09/13 12:49, Валентин Бартенев wrote: > On Friday 09 August 2013 13:12:17 Sergey Kobzar wrote: >> Продолжение исторрии: >> >> # la /var/log/nginx/ | grep access.log >> -rw-r--r-- 1 nginx root 0 Aug 9 03:10 access.log >> -rw-r--r-- 1 nginx root 1.1G Aug 4 03:10 access.log-20130804 >> -rw-r--r-- 1 nginx root 2.5G Aug 6 03:10 access.log-20130805 >> -rw-r--r-- 1 nginx root 2.5G Aug 8 01:31 access.log-20130807 >> -rw-r--r-- 1 nginx root 20M Aug 8 03:10 access.log-20130808 >> -rw-r--r-- 1 nginx root 1.5G Aug 9 12:03 access.log-20130809 >> >> Сейчас все пишется в access.log-20130809 >> >> На днях после изменения настроек php-fpm полезли ошибки: >> /var/log/nginx/error.log:2013/08/07 23:49:53 [error] 1973#0: *16067909 >> FastCGI sent in stderr: "the log buffer is full (1024). The access log >> request has been truncated" while reading response header from upstream >> >> Я добавил: >> access_log /var/log/nginx/access.log main buffer=2k; >> >> Ошибки прекратились, но сегодня после очередной ротации снова вылезло: >> >> /var/log/nginx/error.log-20130809:2013/08/09 10:09:35 [error] 23100#0: >> *479024 FastCGI sent in stderr: "the log buffer is full (1024). The >> access log request has been truncated" >> >> Есть какие=то идеи? >> > > Ошибки на стороне php-fpm никакого отношения к access_log на стороне nginx > не имеют. > > Не говоря уж о том, что и в случае access_log в nginx-е, параметр buffer он > вообще про другое. ОК - буду разбираться с php-fpm. Спасибо. >> Попутный вопрос: >> В документации по access_log >> http://nginx.org/ru/docs/http/ngx_http_log_module.html написано: >> >> Размер буфера должен быть не больше размера атомарной записи в дисковый >> файл. Для FreeBSD этот размер неограничен. >> >> Я правильно понимаю, что для Linux размер буфера не должен быть больше >> размера блока FS? >> >> # tune2fs -l /dev/sda1 | grep 'Block size' >> Block size: 4096 >> > > Там много факторов, начиная от версии ядра и заканчивая типом FS. > Будь ответ настолько простым - мы бы указали это в документации. > > -- > Валентин Бартенев > 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 Fri Aug 9 13:31:00 2013 From: nginx-forum at nginx.us (Tiberiy) Date: Fri, 09 Aug 2013 09:31:00 -0400 Subject: =?UTF-8?B?0JfQsNC/0YDQtdGC0LjRgtGMINC00L7RgdGC0YPQvyDQv9C+IElQINCyIFVSTC4g?= =?UTF-8?B?0KHQv9C40YHQvtC6IElQINCyINGE0LDQudC70LUu?= Message-ID: <0a1e58c6e2e46deed6d84e21fed953cd.NginxMailingListRussian@forum.nginx.org> Привет, Алл. Есть задача блокировать определенные HTTP запросы. Исходные данные: 1. В URL есть параметр &ip=xxx.xxx.xxx.xxx 2. Есть файл около 4млн. IP адресов. Необходимо: При совпадении IP в п.1 и п.2 блокировать запрос (реджектить). Помогите... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241735,241735#msg-241735 From nginx-forum at nginx.us Fri Aug 9 13:33:50 2013 From: nginx-forum at nginx.us (Tiberiy) Date: Fri, 09 Aug 2013 09:33:50 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQtNC+0YHRgtGD0L8g0L/QviBJUCDQsiBV?= =?UTF-8?B?UkwuINCh0L/QuNGB0L7QuiBJUCDQsiDRhNCw0LnQu9C1Lg==?= In-Reply-To: <0a1e58c6e2e46deed6d84e21fed953cd.NginxMailingListRussian@forum.nginx.org> References: <0a1e58c6e2e46deed6d84e21fed953cd.NginxMailingListRussian@forum.nginx.org> Message-ID: <926d48aca43ce325b15f239f4512aad4.NginxMailingListRussian@forum.nginx.org> В догонку. Запрос к URL в п.1 идет не с того IP, что в URL. Простой deny по source IP не подходит. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241735,241736#msg-241736 From vbart at nginx.com Fri Aug 9 13:44:44 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 9 Aug 2013 17:44:44 +0400 Subject: =?UTF-8?B?UmU6ICDQl9Cw0L/RgNC10YLQuNGC0Ywg0LTQvtGB0YLRg9C/INC/0L4gSVAg0LIg?= =?UTF-8?B?VVJMLiDQodC/0LjRgdC+0LogSVAg0LIg0YTQsNC50LvQtS4=?= In-Reply-To: <926d48aca43ce325b15f239f4512aad4.NginxMailingListRussian@forum.nginx.org> References: <0a1e58c6e2e46deed6d84e21fed953cd.NginxMailingListRussian@forum.nginx.org> <926d48aca43ce325b15f239f4512aad4.NginxMailingListRussian@forum.nginx.org> Message-ID: <201308091744.44803.vbart@nginx.com> On Friday 09 August 2013 17:33:50 Tiberiy wrote: > В догонку. Запрос к URL в п.1 идет не с того IP, что в URL. Простой deny > по source IP не подходит. > geo-модуль вам в помощь: http://nginx.org/r/geo/ru Преобразуйте ваш файл на 4-млн. в формат, понятный директиве geo, а далее geo $arg_ip $bad_ip { include path/to/ip_list; } и где вам нужно: if ($bad_ip) { return 403; } -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Aug 9 13:47:33 2013 From: nginx-forum at nginx.us (Tiberiy) Date: Fri, 09 Aug 2013 09:47:33 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQtNC+0YHRgtGD0L8g0L/QviBJUCDQsiBV?= =?UTF-8?B?UkwuINCh0L/QuNGB0L7QuiBJUCDQsiDRhNCw0LnQu9C1Lg==?= In-Reply-To: <201308091744.44803.vbart@nginx.com> References: <201308091744.44803.vbart@nginx.com> Message-ID: <569e3b4c2855f78c1cf58853726cfe28.NginxMailingListRussian@forum.nginx.org> спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241735,241738#msg-241738 From postmaster at softsearch.ru Fri Aug 9 18:09:41 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 9 Aug 2013 22:09:41 +0400 Subject: =?UTF-8?B?ZG9zINGH0LXRgNC10Lcg0LLRi9C80YvQstCw0L3QuNC1INC60Y3RiNCw?= Message-ID: <337837088.20130809220941@softsearch.ru> Здравствуйте. Столкнулся с непривычным досом, когда на кэширующий картинки сервер шли запросы, забивающие кэш реально невостребованными картинками. Т.е. намеренно снижали эффективность кэширования, что плохо сказывалось на бэкендах. Этот конкретный дос победил через костыли, рассчитанные именно на него. Но хотелось бы узнать, как вообще можно бороться с атаками, нацеленными на вымывание кэша в nginx-е. -- С уважением, Михаил mailto:postmaster at softsearch.ru From panfilov at sports.ru Fri Aug 9 18:24:43 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Fri, 9 Aug 2013 22:24:43 +0400 Subject: =?UTF-8?B?UmU6IGRvcyDRh9C10YDQtdC3INCy0YvQvNGL0LLQsNC90LjQtSDQutGN0YjQsA==?= In-Reply-To: <337837088.20130809220941@softsearch.ru> References: <337837088.20130809220941@softsearch.ru> Message-ID: Если нет специфически решений под проект, например, отсекая левый трафик по каким-то критериям, то можно посоветовать следующие универсальные средства: 1. Можно держать разные прокси-зоны под разный контент: картинки, динамика, важный кеш etc. (Горизонтальная оптимизация) 2. Разнести кеш на CDN и на фронтендах - не дать портить кеш на уровень ниже (Вертикальная оптимизация). На практике лучше всего помогают эти две вещи в комплексе. 9 августа 2013 г., 22:09 пользователь Михаил Монашёв < postmaster at softsearch.ru> написал: > Здравствуйте. > > Столкнулся с непривычным досом, когда на кэширующий картинки сервер > шли запросы, забивающие кэш реально невостребованными картинками. Т.е. > намеренно снижали эффективность кэширования, что плохо сказывалось на > бэкендах. Этот конкретный дос победил через костыли, рассчитанные > именно на него. Но хотелось бы узнать, как вообще можно бороться с > атаками, нацеленными на вымывание кэша в nginx-е. > > -- > С уважением, > Михаил 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 citrin at citrin.ru Fri Aug 9 19:13:06 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Fri, 09 Aug 2013 23:13:06 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: References: Message-ID: <52053F42.2020502@citrin.ru> 8/9/13 11:19 AM, Night Romantic пишет: > В wireshark Виндовой сессии бросается в глаза, что каждый пакет от меня > имеет неверную контрольную сумму: > Header checksum: 0x0000 [incorrect, should be 0x68b3 (may be caused by "IP > checksum offload"?)] Ответ тут же: may be caused by "IP checksum offload", так что на это можно не обращать внимание. Отличие линуксового телнета от виндового похоже в то, что линуксовый шлет команду через один syscall и как следствие это уходит в одном IP пакете. Но если удаленная сторона не понимает команду пришедшую в нескольких пакетах, то это баг. Может там и правда Cisco PIX или что то аналогичное по функциям. From postmaster at softsearch.ru Sat Aug 10 06:43:08 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 10 Aug 2013 10:43:08 +0400 Subject: =?UTF-8?B?UmVbMl06IGRvcyDRh9C10YDQtdC3INCy0YvQvNGL0LLQsNC90LjQtSDQutGN0Yg=?= =?UTF-8?B?0LA=?= In-Reply-To: References: <337837088.20130809220941@softsearch.ru> Message-ID: <309156877.20130810104308@softsearch.ru> Здравствуйте, Михаил. Было бы ещё здорово иметь возможность логировать название кэш-зоны, чтобы можно было по логам считать эффективность каждой. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sat Aug 10 07:32:06 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 10 Aug 2013 11:32:06 +0400 Subject: =?UTF-8?B?c2V0INC90LAg0YPRgNC+0LLQvdC1IGh0dHA=?= Message-ID: <614301687.20130810113206@softsearch.ru> Здравствуйте. set на уровне http был бы очень удобен порой. Обходить это через map 1 $var { default "value"; } неудобно. -- С уважением, Михаил mailto:postmaster at softsearch.ru From sb at waeme.net Sat Aug 10 08:40:16 2013 From: sb at waeme.net (Sergey Budnevitch) Date: Sat, 10 Aug 2013 12:40:16 +0400 Subject: =?UTF-8?B?UmU6IGRvcyDRh9C10YDQtdC3INCy0YvQvNGL0LLQsNC90LjQtSDQutGN0YjQsA==?= In-Reply-To: <337837088.20130809220941@softsearch.ru> References: <337837088.20130809220941@softsearch.ru> Message-ID: <80BDEB27-8354-4BB3-BAAA-D6F7B1ED09C4@waeme.net> On 9 Aug2013, at 22:09 , Михаил Монашёв wrote: > Здравствуйте. > > Столкнулся с непривычным досом, когда на кэширующий картинки сервер > шли запросы, забивающие кэш реально невостребованными картинками. Т.е. > намеренно снижали эффективность кэширования, что плохо сказывалось на > бэкендах. Этот конкретный дос победил через костыли, рассчитанные > именно на него. Но хотелось бы узнать, как вообще можно бороться с > атаками, нацеленными на вымывание кэша в nginx-е. proxy_cache_min_uses чем не устраивает? From vbart at nginx.com Sat Aug 10 09:01:48 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 10 Aug 2013 13:01:48 +0400 Subject: =?UTF-8?B?UmU6IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <614301687.20130810113206@softsearch.ru> References: <614301687.20130810113206@softsearch.ru> Message-ID: <201308101301.48106.vbart@nginx.com> On Saturday 10 August 2013 11:32:06 Михаил Монашёв wrote: > Здравствуйте. > > set на уровне http был бы очень удобен порой. Обходить это через > map 1 $var { > default "value"; > } > неудобно. http://nginx.org/en/docs/faq/variables_in_config.html -- Валентин Бартенев http://nginx.org/en/donation.html From postmaster at softsearch.ru Sat Aug 10 19:17:39 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 10 Aug 2013 23:17:39 +0400 Subject: =?UTF-8?B?UmVbMl06IGRvcyDRh9C10YDQtdC3INCy0YvQvNGL0LLQsNC90LjQtSDQutGN0Yg=?= =?UTF-8?B?0LA=?= In-Reply-To: <80BDEB27-8354-4BB3-BAAA-D6F7B1ED09C4@waeme.net> References: <337837088.20130809220941@softsearch.ru> <80BDEB27-8354-4BB3-BAAA-D6F7B1ED09C4@waeme.net> Message-ID: <1323466890.20130810231739@softsearch.ru> Здравствуйте, Sergey. >> Столкнулся с непривычным досом, когда на кэширующий картинки сервер >> шли запросы, забивающие кэш реально невостребованными картинками. Т.е. >> намеренно снижали эффективность кэширования, что плохо сказывалось на >> бэкендах. Этот конкретный дос победил через костыли, рассчитанные >> именно на него. Но хотелось бы узнать, как вообще можно бороться с >> атаками, нацеленными на вымывание кэша в nginx-е. > proxy_cache_min_uses чем не устраивает? Без этой директивы кэширование значительно менее эффективно. Там уже более 1 стоит. Хитрый дос делался так, что она не помогала. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sat Aug 10 19:43:31 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 10 Aug 2013 23:43:31 +0400 Subject: =?UTF-8?B?UmVbMl06IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <201308101301.48106.vbart@nginx.com> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> Message-ID: <246767059.20130810234331@softsearch.ru> Здравствуйте, Валентин. >> set на уровне http был бы очень удобен порой. Обходить это через >> map 1 $var { >> default "value"; >> } >> неудобно. > http://nginx.org/en/docs/faq/variables_in_config.html Признаюсь, что не въехал в ответ по ссылке. Все слова знакомые, а собранные вместе смысл никакой в моей голове не приобретают. Тупею, видимо. :-) Опишу задачу. Мне надо было как-то писать в аксес-лог кэш-зону, чтобы потом по логам считать эффективность каждой кэш-зоны. Встроенную переменную я не знаю, поэтому решил создать переменную через set. Там, где запросы проксируются, я присваивал через set соответствующей переменной значение, равное имени кэшзоны. Но не все запросы проксируются и в логе вместо значения переменной пишется пустая строка, что неудобно для парсинга лога. Брать переменную в кавычки тоже неудобно. Для таких запросов я хотел присвоить этой переменной дефолтное значение "-". Писать в каждом блоке server{} set или include посчитал лишним и вставил в http{} вот такие строчки: # set нельзя делать на уровне http, поэтому делаем присваивание через map map 1 $cache_zone_for_logging { default "-"; } Т.е. я хотел использовать set для инициализации переменной, которая потом может меняться. На мой примитивный взгляд кажется нелогичным иметь иерархию блоков конфига, иметь наследование с вышестоящих уровней иерархии и разрешать set-у работать на уровне http{}. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sun Aug 11 08:08:26 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 11 Aug 2013 12:08:26 +0400 Subject: =?UTF-8?B?UmVbMl06IGRvcyDRh9C10YDQtdC3INCy0YvQvNGL0LLQsNC90LjQtSDQutGN0Yg=?= =?UTF-8?B?0LA=?= In-Reply-To: References: <337837088.20130809220941@softsearch.ru> Message-ID: <1036010561.20130811120826@softsearch.ru> Здравствуйте, Михаил. Вы писали 9 августа 2013 г., 22:24:43: > Если нет специфически решений под проект, например, отсекая левый > трафик по каким-то критериям, то можно посоветовать следующие > универсальные средства:  > 1. Можно держать разные прокси-зоны под разный контент: картинки, > динамика, важный кеш etc. (Горизонтальная оптимизация) > 2. Разнести кеш на CDN и на фронтендах - не дать портить кеш на > уровень ниже (Вертикальная оптимизация). > На практике лучше всего помогают эти две вещи в комплексе. Сейчас опять начали досить, но чуть иначе. Выглядит как будто нормальные юзеры использующие обычные браузеры ищут в яндексе один из миллионов субдоменов сайта (на каждом субдомене расположен отдельный блог, у меня блогхостинг), кликают в выдачи на первую ссылку, коей является искомый субдомен, переходят на страницу с главной страницей дневника(обычно заброшенного много лет назад) и грузят в браузер картинки со страницы. Это приводит к тому, что сильно грузится сервер, где хранятся картинки, ибо на него начинает приходить запросов значительно больше, чем обычно. Я могу выделить исходные запросы, где хост совпадает с частью реферера. Там вот такие ip-шки: кол-во запросов, ip 572 195.91.224.113 339 95.221.15.235 335 46.188.34.2 330 79.111.40.252 330 46.73.28.148 327 176.195.182.151 326 176.195.64.153 325 46.73.17.36 324 95.221.99.89 324 46.73.18.66 322 188.232.151.24 322 176.195.226.186 321 176.195.245.1 320 95.220.152.166 315 176.195.234.88 314 176.195.246.146 311 5.164.96.167 309 176.195.238.55 308 95.221.79.186 307 95.221.92.187 306 46.73.63.242 304 46.188.2.233 304 176.195.223.131 303 176.192.175.10 302 46.73.40.104 302 46.188.22.137 300 176.195.190.110 299 176.195.171.178 297 95.220.166.165 297 46.73.17.183 297 46.188.45.253 296 46.188.44.163 295 95.220.143.59 295 46.188.45.252 292 46.73.61.214 289 188.244.47.141 289 176.195.71.33 289 176.195.210.111 287 46.73.11.43 285 46.188.51.128 283 176.195.3.52 282 46.73.58.185 280 95.220.255.195 275 176.192.184.0 274 95.221.15.204 269 188.244.43.159 265 95.25.181.168 265 176.195.162.221 264 95.221.27.210 261 128.69.225.112 260 46.188.17.9 260 176.195.220.21 Но все эти запросы от большого интернет-провайдера NetByNet. Не хотелось бы отрубать много юзеров от инета. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mva at mva.name Sun Aug 11 10:54:40 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 11 Aug 2013 14:54:40 +0400 Subject: =?UTF-8?B?UmU6IGRvcyDRh9C10YDQtdC3INCy0YvQvNGL0LLQsNC90LjQtSDQutGN0YjQsA==?= In-Reply-To: <1036010561.20130811120826@softsearch.ru> References: <337837088.20130809220941@softsearch.ru> <1036010561.20130811120826@softsearch.ru> Message-ID: <52076D70.2050006@mva.name> А что если написать админам нетбайнета в абуз и спросить по поводу пользователей с вышеуказанных IP и пожаловаться, что они DDoS'ят. Иногда админы помогают, например. 11.08.2013 12:08, Михаил Монашёв пишет: > Здравствуйте, Михаил. > > Вы писали 9 августа 2013 г., 22:24:43: > >> Если нет специфически решений под проект, например, отсекая левый >> трафик по каким-то критериям, то можно посоветовать следующие >> универсальные средства: > > >> 1. Можно держать разные прокси-зоны под разный контент: картинки, >> динамика, важный кеш etc. (Горизонтальная оптимизация) >> 2. Разнести кеш на CDN и на фронтендах - не дать портить кеш на >> уровень ниже (Вертикальная оптимизация). > > >> На практике лучше всего помогают эти две вещи в комплексе. > > Сейчас опять начали досить, но чуть иначе. Выглядит как будто > нормальные юзеры использующие обычные браузеры ищут в яндексе один из > миллионов субдоменов сайта (на каждом субдомене расположен отдельный > блог, у меня блогхостинг), кликают в выдачи на первую ссылку, коей > является искомый субдомен, переходят на страницу с главной страницей > дневника(обычно заброшенного много лет назад) и грузят в браузер > картинки со страницы. > > Это приводит к тому, что сильно грузится сервер, где хранятся > картинки, ибо на него начинает приходить запросов значительно больше, > чем обычно. > > Я могу выделить исходные запросы, где хост совпадает с частью > реферера. Там вот такие ip-шки: > кол-во запросов, ip > 572 195.91.224.113 > 339 95.221.15.235 > 335 46.188.34.2 > 330 79.111.40.252 > 330 46.73.28.148 > 327 176.195.182.151 > 326 176.195.64.153 > 325 46.73.17.36 > 324 95.221.99.89 > 324 46.73.18.66 > 322 188.232.151.24 > 322 176.195.226.186 > 321 176.195.245.1 > 320 95.220.152.166 > 315 176.195.234.88 > 314 176.195.246.146 > 311 5.164.96.167 > 309 176.195.238.55 > 308 95.221.79.186 > 307 95.221.92.187 > 306 46.73.63.242 > 304 46.188.2.233 > 304 176.195.223.131 > 303 176.192.175.10 > 302 46.73.40.104 > 302 46.188.22.137 > 300 176.195.190.110 > 299 176.195.171.178 > 297 95.220.166.165 > 297 46.73.17.183 > 297 46.188.45.253 > 296 46.188.44.163 > 295 95.220.143.59 > 295 46.188.45.252 > 292 46.73.61.214 > 289 188.244.47.141 > 289 176.195.71.33 > 289 176.195.210.111 > 287 46.73.11.43 > 285 46.188.51.128 > 283 176.195.3.52 > 282 46.73.58.185 > 280 95.220.255.195 > 275 176.192.184.0 > 274 95.221.15.204 > 269 188.244.43.159 > 265 95.25.181.168 > 265 176.195.162.221 > 264 95.221.27.210 > 261 128.69.225.112 > 260 46.188.17.9 > 260 176.195.220.21 > > Но все эти запросы от большого интернет-провайдера NetByNet. Не > хотелось бы отрубать много юзеров от инета. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From swood at fotofor.biz Sun Aug 11 11:21:19 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 11 Aug 2013 15:21:19 +0400 Subject: =?UTF-8?B?UmU6INCx0LvQvtC60LjRgNC+0LLQutCwINC60LvQuNC10L3RgtC+0LIg0L/QviA=?= =?UTF-8?B?0LrQvtC80LHQuNC90LDRhtC40LggSVAt0LDQtNGA0LXRgdCwINC4IHVzZXIg?= =?UTF-8?B?YWdlbnQ=?= In-Reply-To: <611551389.20130809090145@softsearch.ru> References: <850a925a25bc481ff03654c7466f9d5e.NginxMailingListRussian@forum.nginx.org> <611551389.20130809090145@softsearch.ru> Message-ID: Можете использовать маленький скрипт на lua, в который отправлять IP и user-agent, а в скрипте анализировать, блокировать запрос, или нет. 9 августа 2013 г., 9:01 пользователь Михаил Монашёв < postmaster at softsearch.ru> написал: > Здравствуйте, anon. > > > Какое можете предложить наиболее эффективное решение для блокировки > > клиентов по паре IP-адрес (в идеале - подсеть) + строка user agent? > > Для упрощения предположим, что user agent всегда постоянный. > > Генерить файлик с map{} и инклудить его в основной конфиг. А раз в > минуту или при изменении файлика посылать nginx-у сигнал, чтобы он > перечитывал свой конфиг > > -- > С уважением, > Михаил 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 Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From panfilov at sports.ru Sun Aug 11 18:54:07 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Sun, 11 Aug 2013 22:54:07 +0400 Subject: =?UTF-8?B?UmU6IGRvcyDRh9C10YDQtdC3INCy0YvQvNGL0LLQsNC90LjQtSDQutGN0YjQsA==?= In-Reply-To: <52076D70.2050006@mva.name> References: <337837088.20130809220941@softsearch.ru> <1036010561.20130811120826@softsearch.ru> <52076D70.2050006@mva.name> Message-ID: Админы, конечно, помочь могут, но если это был реальный DDoS, то он сменит место атаки и проблема вновь станет актуальной. Для быстрого решения проблемы я бы начал смотреть в сторону CDN, можно своего собственного. 11 августа 2013 г., 14:54 пользователь Vadim A. Misbakh-Soloviov < mva at mva.name> написал: > А что если написать админам нетбайнета в абуз и спросить по поводу > пользователей с вышеуказанных IP и пожаловаться, что они DDoS'ят. Иногда > админы помогают, например. > > > > 11.08.2013 12:08, Михаил Монашёв пишет: > > Здравствуйте, Михаил. > > > > Вы писали 9 августа 2013 г., 22:24:43: > > > >> Если нет специфически решений под проект, например, отсекая левый > >> трафик по каким-то критериям, то можно посоветовать следующие > >> универсальные средства: > > > > > >> 1. Можно держать разные прокси-зоны под разный контент: картинки, > >> динамика, важный кеш etc. (Горизонтальная оптимизация) > >> 2. Разнести кеш на CDN и на фронтендах - не дать портить кеш на > >> уровень ниже (Вертикальная оптимизация). > > > > > >> На практике лучше всего помогают эти две вещи в комплексе. > > > > Сейчас опять начали досить, но чуть иначе. Выглядит как будто > > нормальные юзеры использующие обычные браузеры ищут в яндексе один из > > миллионов субдоменов сайта (на каждом субдомене расположен отдельный > > блог, у меня блогхостинг), кликают в выдачи на первую ссылку, коей > > является искомый субдомен, переходят на страницу с главной страницей > > дневника(обычно заброшенного много лет назад) и грузят в браузер > > картинки со страницы. > > > > Это приводит к тому, что сильно грузится сервер, где хранятся > > картинки, ибо на него начинает приходить запросов значительно больше, > > чем обычно. > > > > Я могу выделить исходные запросы, где хост совпадает с частью > > реферера. Там вот такие ip-шки: > > кол-во запросов, ip > > 572 195.91.224.113 > > 339 95.221.15.235 > > 335 46.188.34.2 > > 330 79.111.40.252 > > 330 46.73.28.148 > > 327 176.195.182.151 > > 326 176.195.64.153 > > 325 46.73.17.36 > > 324 95.221.99.89 > > 324 46.73.18.66 > > 322 188.232.151.24 > > 322 176.195.226.186 > > 321 176.195.245.1 > > 320 95.220.152.166 > > 315 176.195.234.88 > > 314 176.195.246.146 > > 311 5.164.96.167 > > 309 176.195.238.55 > > 308 95.221.79.186 > > 307 95.221.92.187 > > 306 46.73.63.242 > > 304 46.188.2.233 > > 304 176.195.223.131 > > 303 176.192.175.10 > > 302 46.73.40.104 > > 302 46.188.22.137 > > 300 176.195.190.110 > > 299 176.195.171.178 > > 297 95.220.166.165 > > 297 46.73.17.183 > > 297 46.188.45.253 > > 296 46.188.44.163 > > 295 95.220.143.59 > > 295 46.188.45.252 > > 292 46.73.61.214 > > 289 188.244.47.141 > > 289 176.195.71.33 > > 289 176.195.210.111 > > 287 46.73.11.43 > > 285 46.188.51.128 > > 283 176.195.3.52 > > 282 46.73.58.185 > > 280 95.220.255.195 > > 275 176.192.184.0 > > 274 95.221.15.204 > > 269 188.244.43.159 > > 265 95.25.181.168 > > 265 176.195.162.221 > > 264 95.221.27.210 > > 261 128.69.225.112 > > 260 46.188.17.9 > > 260 176.195.220.21 > > > > Но все эти запросы от большого интернет-провайдера NetByNet. Не > > хотелось бы отрубать много юзеров от инета. > > > > > _______________________________________________ > 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 Aug 12 06:20:22 2013 From: nginx-forum at nginx.us (Night Romantic) Date: Mon, 12 Aug 2013 02:20:22 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <52053F42.2020502@citrin.ru> References: <52053F42.2020502@citrin.ru> Message-ID: <4264cd70e6d174b07d81e57c5df10c91.NginxMailingListRussian@forum.nginx.org> Anton Yuzhaninov Wrote: ------------------------------------------------------- > Отличие линуксового телнета от виндового похоже в то, что линуксовый > шлет команду через один syscall и как следствие это уходит в одном IP > пакете. > Но если удаленная сторона не понимает команду пришедшую в нескольких > пакетах, то это баг. Может там и правда Cisco PIX или что то > аналогичное по функциям. Техподдержка ответила на вопрос о том, какой софт используется. О/с - freebsd 7 MTA - exim 4.69 nginx и в самом деле используется в качестве ESMTP proxy (т. е. описанное поведение *может* оказаться багом именно nginx). Именно PIX они не используют, попросил уточнить про аналоги, ответят - отпишусь. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241708,241771#msg-241771 From nginx-forum at nginx.us Mon Aug 12 06:23:09 2013 From: nginx-forum at nginx.us (Night Romantic) Date: Mon, 12 Aug 2013 02:23:09 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IEVTTVRQIC0g0L/RgNC+0LHQu9C10LzQsCAoPyk=?= In-Reply-To: <20130809085154.1c76a39b@nlb01lx002.neolabs01.local> References: <20130809085154.1c76a39b@nlb01lx002.neolabs01.local> Message-ID: <00e89e3f2bea554b9c369fce17e9baf2.NginxMailingListRussian@forum.nginx.org> Спасибо за идею/информацию. Спросил, именно PIX они не используют, уточню насчёт аналогов. Доступа к дебагу у меня нет, т. к. сервак провайдера, а они не хотят этим заниматься, отписываются, что у них всё хорошо, а проблема на нашей стороне)) kornel Wrote: ------------------------------------------------------- > У меня была очень похожая проблема была при использовании PIX > файрвола. > Он вмешивался в сессию и резал всё, что хоть немного отличалось, в > его > понимании, от идеальной smtp сессии. Разобраться смог только дебажа > входящий на tcp/25 на сервере. > > ~~~ > wbr, Alexander Uskov Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241708,241772#msg-241772 From chipitsine at gmail.com Mon Aug 12 10:59:53 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 12 Aug 2013 16:59:53 +0600 Subject: =?UTF-8?B?0L/RgNC10LTQu9Cw0LPQsNGOINC90LXQvNC90L7Qs9C+INC/0L7QvNC10L3Rj9GC?= =?UTF-8?B?0Ywg0LvQvtCz0LjQutGDIHByb3h5X25leHRfdXBzdHJlYW0=?= Message-ID: Добрый день! мы столкнулись с ситуацией такого характера. есть веб-приложения, которые долго отвечают, в отношении них справедливо, что лучше запрос отправить не более одного раза (например, это может быть разнесения платежа, на 20 фронтов платеж разнесется 20 раз). с другой стороны, хотелось бы отличать "таймаут при отправке данных" от "тайаута при чтении данных". в случае, если мы не можем отправить данные - нормально уйти на следующий хост. если мы уходим в таймаут при чтении - на следующий хост лучше не уходить, может быть массовый "расстрел" (разнесение платежа 20 раз из 20). патч вложил. Илья Шипицин -------------- next part -------------- A non-text attachment was scrubbed... Name: 504.patch Type: application/octet-stream Size: 407 bytes Desc: not available URL: From sergey.kobzar at itcraft.org Mon Aug 12 14:50:49 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 12 Aug 2013 17:50:49 +0300 Subject: =?UTF-8?B?0J/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1?= Message-ID: <5208F649.9010300@itcraft.org> location / { rewrite ^/\?portfolio=hungary /en/europe/hungary last; rewrite_log on; try_files $uri $uri/ /index.php?q=$request_uri; } Запрашиваемый URL: http://site.com/en/?portfolio=hungary В логе: 2013/08/12 17:44:46 [notice] 21714#0: *1 "^/\?portfolio=hungary" does not match "/", client: 1.1.1.1, server: site.com, request: "GET /?portfolio=hungary HTTP/1.1", host: "site.com" Почему не редиректит на /en/europe/hungary? Или решается только через $args + if ? Спасибо. From sergey.kobzar at itcraft.org Mon Aug 12 15:09:58 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 12 Aug 2013 18:09:58 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtQ==?= In-Reply-To: <5208F649.9010300@itcraft.org> References: <5208F649.9010300@itcraft.org> Message-ID: <5208FAC6.9000200@itcraft.org> On 08/12/13 17:50, Sergey Kobzar wrote: > location / { > rewrite ^/\?portfolio=hungary /en/europe/hungary last; > rewrite_log on; > > try_files $uri $uri/ /index.php?q=$request_uri; > } > > > Запрашиваемый URL: > > http://site.com/en/?portfolio=hungary > > В логе: > > 2013/08/12 17:44:46 [notice] 21714#0: *1 "^/\?portfolio=hungary" does > not match "/", client: 1.1.1.1, server: site.com, request: "GET > /?portfolio=hungary HTTP/1.1", host: "site.com" > > Почему не редиректит на /en/europe/hungary? > > Или решается только через $args + if ? > > Спасибо. Фреймворк - Joomla. Может я для нее неправильно try_files расписал, т.к. вне зависимости, что стоит после ? в запросе возвращается home page а не 404. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Mon Aug 12 15:14:01 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Aug 2013 19:14:01 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtQ==?= In-Reply-To: <5208F649.9010300@itcraft.org> References: <5208F649.9010300@itcraft.org> Message-ID: <201308121914.01345.vbart@nginx.com> On Monday 12 August 2013 18:50:49 Sergey Kobzar wrote: > location / { > rewrite ^/\?portfolio=hungary /en/europe/hungary last; > rewrite_log on; > > try_files $uri $uri/ /index.php?q=$request_uri; > } > > > Запрашиваемый URL: > > http://site.com/en/?portfolio=hungary > > В логе: > > 2013/08/12 17:44:46 [notice] 21714#0: *1 "^/\?portfolio=hungary" does > not match "/", client: 1.1.1.1, server: site.com, request: "GET > /?portfolio=hungary HTTP/1.1", host: "site.com" > > Почему не редиректит на /en/europe/hungary? > > Или решается только через $args + if ? > Разумеется параметры не учитываются при сопоставлении URI в rewrite. -- Валентин Бартенев http://nginx.org/en/donation.html From sergey.kobzar at itcraft.org Mon Aug 12 15:22:07 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 12 Aug 2013 18:22:07 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtQ==?= In-Reply-To: <201308121914.01345.vbart@nginx.com> References: <5208F649.9010300@itcraft.org> <201308121914.01345.vbart@nginx.com> Message-ID: <5208FD9F.4070509@itcraft.org> On 08/12/13 18:14, Валентин Бартенев wrote: > On Monday 12 August 2013 18:50:49 Sergey Kobzar wrote: >> location / { >> rewrite ^/\?portfolio=hungary /en/europe/hungary last; >> rewrite_log on; >> >> try_files $uri $uri/ /index.php?q=$request_uri; >> } >> >> >> Запрашиваемый URL: >> >> http://site.com/en/?portfolio=hungary >> >> В логе: >> >> 2013/08/12 17:44:46 [notice] 21714#0: *1 "^/\?portfolio=hungary" does >> not match "/", client: 1.1.1.1, server: site.com, request: "GET >> /?portfolio=hungary HTTP/1.1", host: "site.com" >> >> Почему не редиректит на /en/europe/hungary? >> >> Или решается только через $args + if ? >> > > Разумеется параметры не учитываются при сопоставлении URI в rewrite. Т.е. if + $args? Может есть элегантный способ? В настледство досталось сотни таких URL'ов - нужно безболезненно перейти на новую реализацию... > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From vbart at nginx.com Mon Aug 12 15:32:15 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Aug 2013 19:32:15 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtQ==?= In-Reply-To: <5208FD9F.4070509@itcraft.org> References: <5208F649.9010300@itcraft.org> <201308121914.01345.vbart@nginx.com> <5208FD9F.4070509@itcraft.org> Message-ID: <201308121932.15644.vbart@nginx.com> On Monday 12 August 2013 19:22:07 Sergey Kobzar wrote: > On 08/12/13 18:14, Валентин Бартенев wrote: > > On Monday 12 August 2013 18:50:49 Sergey Kobzar wrote: > >> location / { > >> > >> rewrite ^/\?portfolio=hungary /en/europe/hungary last; > >> rewrite_log on; > >> > >> try_files $uri $uri/ /index.php?q=$request_uri; > >> > >> } > >> > >> > >> Запрашиваемый URL: > >> > >> http://site.com/en/?portfolio=hungary > >> > >> В логе: > >> > >> 2013/08/12 17:44:46 [notice] 21714#0: *1 "^/\?portfolio=hungary" does > >> not match "/", client: 1.1.1.1, server: site.com, request: "GET > >> /?portfolio=hungary HTTP/1.1", host: "site.com" > >> > >> Почему не редиректит на /en/europe/hungary? > >> > >> Или решается только через $args + if ? > > > > Разумеется параметры не учитываются при сопоставлении URI в rewrite. > > Т.е. if + $args? Может есть элегантный способ? В настледство досталось > сотни таких URL'ов - нужно безболезненно перейти на новую реализацию... > $args служит для других целей обычно, и правильно написать регулярку с $args - задача столь же сложная, как если бы они учитывались в rewrite или location. Все почему-то забывают, что параметры запроса могут идти в любой последовательности и среди них могут быть ещё параметры, которые не ожидаются. Правильно: if + $arg_* Для сотен: map + $arg_* -- Валентин Бартенев http://nginx.org/en/donation.html From sergey.kobzar at itcraft.org Mon Aug 12 15:37:24 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 12 Aug 2013 18:37:24 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtQ==?= In-Reply-To: <201308121932.15644.vbart@nginx.com> References: <5208F649.9010300@itcraft.org> <201308121914.01345.vbart@nginx.com> <5208FD9F.4070509@itcraft.org> <201308121932.15644.vbart@nginx.com> Message-ID: <52090134.7020001@itcraft.org> On 08/12/13 18:32, Валентин Бартенев wrote: > On Monday 12 August 2013 19:22:07 Sergey Kobzar wrote: >> On 08/12/13 18:14, Валентин Бартенев wrote: >>> On Monday 12 August 2013 18:50:49 Sergey Kobzar wrote: >>>> location / { >>>> >>>> rewrite ^/\?portfolio=hungary /en/europe/hungary last; >>>> rewrite_log on; >>>> >>>> try_files $uri $uri/ /index.php?q=$request_uri; >>>> >>>> } >>>> >>>> >>>> Запрашиваемый URL: >>>> >>>> http://site.com/en/?portfolio=hungary >>>> >>>> В логе: >>>> >>>> 2013/08/12 17:44:46 [notice] 21714#0: *1 "^/\?portfolio=hungary" does >>>> not match "/", client: 1.1.1.1, server: site.com, request: "GET >>>> /?portfolio=hungary HTTP/1.1", host: "site.com" >>>> >>>> Почему не редиректит на /en/europe/hungary? >>>> >>>> Или решается только через $args + if ? >>> >>> Разумеется параметры не учитываются при сопоставлении URI в rewrite. >> >> Т.е. if + $args? Может есть элегантный способ? В настледство досталось >> сотни таких URL'ов - нужно безболезненно перейти на новую реализацию... >> > > $args служит для других целей обычно, и правильно написать > регулярку с $args - задача столь же сложная, как если бы они > учитывались в rewrite или location. Все почему-то забывают, > что параметры запроса могут идти в любой последовательности > и среди них могут быть ещё параметры, которые не ожидаются. > > Правильно: if + $arg_* > > Для сотен: map + $arg_* У меня число перестановок кончно, т.к. старые URL остались только в поисковиках. Идея понятна. Спасибо. > > -- > Валентин Бартенев > 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 Tue Aug 13 18:29:50 2013 From: nginx-forum at nginx.us (automatix) Date: Tue, 13 Aug 2013 14:29:50 -0400 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCA0MDQg0L/RgNC4INC40YHQv9C+0LvRjNC30L7QstCw?= =?UTF-8?B?0L3QuNC4INCyINCj0KDQm9C1INC90LXQt9Cw0Y3RgdC60LXQudC/0LXQvdC9?= =?UTF-8?B?0YvRhSDRgdC/0LXRhtGB0LjQvNCy0L7Qu9C+0LIsINGC0LDQutC40YUg0Lo=?= =?UTF-8?B?0LDQuiDRgdC60L7QsdC60Lgg0LjQu9C4INGC0LjRgNC1?= In-Reply-To: References: Message-ID: <7f7d32e6948fb06565ab39bfe72022a2.NginxMailingListRussian@forum.nginx.org> Спасибо за Ваш ответ! Относительно того, как я хочу -- да, именно так: чтобы собственно раутингом занимался "хитрый зенд". Когда мне удастся донести до него реквест, он сможет с этим справиться. Настройки. Я изменил свои настройки в соответствии с тем, что Вы написали. Но видимых изменений, к сожалению, нет. Вот актуальный конфиг: server { listen 80; server_name foo.qwer.loc bar.asdf.loc baz.yxcv.loc ; charset utf-8; if ($host ~ ^(?.+)\.(?.+)\.loc$) { #set $project $1; # already set #set $area $2; # already set set $folder "$area/$project"; #set $domain "$project.$area.loc"; # equal to $host } access_log /var/log/nginx/$area/$project.access.log; error_log /var/log/nginx/error.log; # add_header Host $server_name; # add_header X-Server $hostname; gzip on; gzip_min_length 1000; gzip_types text/plain text/xml application/xml; client_max_body_size 25m; root /var/www/$folder/public/; try_files $uri $uri/ /index.php?$args; index index.html index.php; location / { index index.html index.php; sendfile off; try_files $uri $uri/ @zend; index index.php index.html index.htm; add_header Cache-Control max-age=1209600; } # Zugriff auf sensible Dateien verwehren location ~ (\.inc\.php|\.tpl|\.sql|\.tpl\.php|\.db)$ { deny all; } # Die htaccess brauchen wir nicht mehr - und wenn sie noch da is # sollte sie nicht angezeigt werden location ~ \.htaccess { deny all; } # Die eigentliche RewriteRule f?r das Zend Framework if (!-e $request_filename) { rewrite ^.*$ /index.php last; } location ~ \.php$ { fastcgi_cache off; #fastcgi_pass 127.0.0.1:9001; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_read_timeout 6000; fastcgi_index index.php; include fastcgi_params; #fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param APPLICATION_ENV development; fastcgi_param HTTPS $https; try_files $uri @zend; } location @zend { #fastcgi_pass 127.0.0.1:9000; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root/index.php; include fastcgi_params; } location ~ /\. { deny all; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241512,241812#msg-241812 From vbart at nginx.com Tue Aug 13 18:58:56 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 13 Aug 2013 22:58:56 +0400 Subject: =?UTF-8?B?UmU6ICDQntGI0LjQsdC60LAgNDA0INC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDQvdC40Lgg0LIg0KPQoNCb0LUg0L3QtdC30LDRjdGB0LrQtdC50L/QtdC9?= =?UTF-8?B?0L3Ri9GFINGB0L/QtdGG0YHQuNC80LLQvtC70L7QsiwgINGC0LDQutC40YUg?= =?UTF-8?B?0LrQsNC6INGB0LrQvtCx0LrQuCDQuNC70Lgg0YLQuNGA0LU=?= In-Reply-To: <7f7d32e6948fb06565ab39bfe72022a2.NginxMailingListRussian@forum.nginx.org> References: <7f7d32e6948fb06565ab39bfe72022a2.NginxMailingListRussian@forum.nginx.org> Message-ID: <201308132258.56729.vbart@nginx.com> On Tuesday 13 August 2013 22:29:50 automatix wrote: > Спасибо за Ваш ответ! > > Относительно того, как я хочу -- да, именно так: чтобы собственно раутингом > занимался "хитрый зенд". Когда мне удастся донести до него реквест, он > сможет с этим справиться. > > Настройки. Я изменил свои настройки в соответствии с тем, что Вы написали. > Но видимых изменений, к сожалению, нет. [..] Их видимо и не будет, если 404 возвращает ZF. -- Валентин Бартенев http://nginx.org/en/donation.html From chipitsine at gmail.com Tue Aug 13 19:21:29 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 01:21:29 +0600 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCA0MDQg0L/RgNC4INC40YHQv9C+0LvRjNC30L7QstCw?= =?UTF-8?B?0L3QuNC4INCyINCj0KDQm9C1INC90LXQt9Cw0Y3RgdC60LXQudC/0LXQvdC9?= =?UTF-8?B?0YvRhSDRgdC/0LXRhtGB0LjQvNCy0L7Qu9C+0LIsINGC0LDQutC40YUg0Lo=?= =?UTF-8?B?0LDQuiDRgdC60L7QsdC60Lgg0LjQu9C4INGC0LjRgNC1?= In-Reply-To: <7f7d32e6948fb06565ab39bfe72022a2.NginxMailingListRussian@forum.nginx.org> References: <7f7d32e6948fb06565ab39bfe72022a2.NginxMailingListRussian@forum.nginx.org> Message-ID: в чем смысл директивы if (!-e $request_filename) { rewrite ^.*$ /index.php last; } при наличии try_files ? опять же, при правильном использовании try_files не будет отдаваться 404 от nginx, потому что, если он не найдет файл, он будет проксировать дальше, на ZF 14 августа 2013 г., 0:29 пользователь automatix написал: > Спасибо за Ваш ответ! > > Относительно того, как я хочу -- да, именно так: чтобы собственно раутингом > занимался "хитрый зенд". Когда мне удастся донести до него реквест, он > сможет с этим справиться. > > Настройки. Я изменил свои настройки в соответствии с тем, что Вы написали. > Но видимых изменений, к сожалению, нет. > > Вот актуальный конфиг: > > server { > listen 80; > server_name > foo.qwer.loc > bar.asdf.loc > baz.yxcv.loc > ; > > charset utf-8; > > if ($host ~ ^(?.+)\.(?.+)\.loc$) { > #set $project $1; # already set > #set $area $2; # already set > > set $folder "$area/$project"; > #set $domain "$project.$area.loc"; # equal to $host > } > > access_log /var/log/nginx/$area/$project.access.log; > error_log /var/log/nginx/error.log; > > # add_header Host $server_name; > # add_header X-Server $hostname; > > gzip on; > gzip_min_length 1000; > gzip_types text/plain text/xml application/xml; > > client_max_body_size 25m; > > root /var/www/$folder/public/; > > try_files $uri $uri/ /index.php?$args; > index index.html index.php; > > location / { > index index.html index.php; > sendfile off; > > try_files $uri $uri/ @zend; > index index.php index.html index.htm; > add_header Cache-Control max-age=1209600; > } > > # Zugriff auf sensible Dateien verwehren > location ~ (\.inc\.php|\.tpl|\.sql|\.tpl\.php|\.db)$ { > deny all; > } > > # Die htaccess brauchen wir nicht mehr - und wenn sie noch da is > # sollte sie nicht angezeigt werden > location ~ \.htaccess { > deny all; > } > > # Die eigentliche RewriteRule f?r das Zend Framework > if (!-e $request_filename) { > rewrite ^.*$ /index.php last; > } > > location ~ \.php$ { > fastcgi_cache off; > #fastcgi_pass 127.0.0.1:9001; > fastcgi_pass unix:/var/run/php5-fpm.sock; > fastcgi_read_timeout 6000; > fastcgi_index index.php; > include fastcgi_params; > #fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > fastcgi_param APPLICATION_ENV development; > fastcgi_param HTTPS $https; > > try_files $uri @zend; > } > > location @zend { > #fastcgi_pass 127.0.0.1:9000; > fastcgi_pass unix:/var/run/php5-fpm.sock; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME $document_root/index.php; > include fastcgi_params; > } > > location ~ /\. { > deny all; > } > } > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241512,241812#msg-241812 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Wed Aug 14 08:29:10 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 14:29:10 +0600 Subject: =?UTF-8?B?0LHQsNCzIFNQRFk=?= Message-ID: Добрый день! мы налетели на забавную ситуацию, как оказалось, Chrome и nginx по-разному смотрят на стандарты SPDY. Если отправлять пустой хедер, то Chrome считает, что это корректно и отправляет, nginx же считает, что некорректно и режет. для разбора полетов сделали два стенда https://spdy2.skbkontur.ru https://spdy3.skbkontur.ru (тут для сравнения поднят node.js) учитывая долю Chrome среди браузеров, надо что-то с этим делать. Илья Шипицин From public-mail at alekciy.ru Wed Aug 14 08:55:56 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Wed, 14 Aug 2013 12:55:56 +0400 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCA0MDQg0L/RgNC4INC40YHQv9C+0LvRjNC30L7QstCw?= =?UTF-8?B?0L3QuNC4INCyINCj0KDQm9C1INC90LXQt9Cw0Y3RgdC60LXQudC/0LXQvdC9?= =?UTF-8?B?0YvRhSDRgdC/0LXRhtGB0LjQvNCy0L7Qu9C+0LIsINGC0LDQutC40YUg0Lo=?= =?UTF-8?B?0LDQuiDRgdC60L7QsdC60Lgg0LjQu9C4INGC0LjRgNC1?= In-Reply-To: References: Message-ID: 5 августа 2013 г., 11:11 пользователь Илья Шипицин написал: > location ~ \.php$ { > try_files $uri @zend; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > include fastcgi_params; > Кстати, о конфигах из интернетов. В контексте PHP лучше ставить include fastcgi_params выше, чем остальные директивы, т.к. директивы из fastcgi_params "перезапишут" предыдущие значения (не на стороне nginx, такова реализация в PHP). В противном случае админа могут ждать долгие разборки почему же правильной конфиг ожидаемо не работает в PHP приложении. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Wed Aug 14 09:05:42 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 15:05:42 +0600 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCA0MDQg0L/RgNC4INC40YHQv9C+0LvRjNC30L7QstCw?= =?UTF-8?B?0L3QuNC4INCyINCj0KDQm9C1INC90LXQt9Cw0Y3RgdC60LXQudC/0LXQvdC9?= =?UTF-8?B?0YvRhSDRgdC/0LXRhtGB0LjQvNCy0L7Qu9C+0LIsINGC0LDQutC40YUg0Lo=?= =?UTF-8?B?0LDQuiDRgdC60L7QsdC60Lgg0LjQu9C4INGC0LjRgNC1?= In-Reply-To: References: Message-ID: согласен. 14 августа 2013 г., 14:55 пользователь Алексей Сундуков написал: > 5 августа 2013 г., 11:11 пользователь Илья Шипицин > написал: > >> location ~ \.php$ { >> try_files $uri @zend; >> fastcgi_param SCRIPT_FILENAME >> $document_root$fastcgi_script_name; >> fastcgi_pass 127.0.0.1:9000; >> fastcgi_index index.php; >> include fastcgi_params; > > > > Кстати, о конфигах из интернетов. В контексте PHP лучше ставить include > fastcgi_params выше, чем остальные директивы, т.к. директивы из > fastcgi_params "перезапишут" предыдущие значения (не на стороне nginx, > такова реализация в PHP). В противном случае админа могут ждать долгие > разборки почему же правильной конфиг ожидаемо не работает в PHP приложении. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Wed Aug 14 09:32:03 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 14 Aug 2013 13:32:03 +0400 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: References: Message-ID: <201308141332.03806.vbart@nginx.com> On Wednesday 14 August 2013 12:29:10 Илья Шипицин wrote: > Добрый день! > > мы налетели на забавную ситуацию, как оказалось, Chrome и nginx > по-разному смотрят на стандарты SPDY. Если отправлять пустой хедер, то > Chrome считает, что это корректно и отправляет, nginx же считает, что > некорректно и режет. > > для разбора полетов сделали два стенда > > https://spdy2.skbkontur.ru > https://spdy3.skbkontur.ru (тут для сравнения поднят node.js) > > учитывая долю Chrome среди браузеров, надо что-то с этим делать. > Люди из Google сами в протоколе эту ситуацию явно прописали, даже указали, какую ошибку MUST возвращать сервер. The length of each name and value must be greater than zero. A receiver of a zero-length name or value must send a RST_STREAM with code PROTOCOL error. http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-HEADERS Предлагаю сообщить о баге в Chrome. Разработчики Firefox и Opera читали спецификацию и ведут себя корректно. SPDY draft. 3 предписывает то же самое: A recipient of a zero-length name MUST issue a stream error (Section 2.4.2) with the status code PROTOCOL_ERROR for the stream-id. https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 -- Валентин Бартенев http://nginx.org/en/donation.html From chipitsine at gmail.com Wed Aug 14 09:59:34 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 15:59:34 +0600 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: <201308141332.03806.vbart@nginx.com> References: <201308141332.03806.vbart@nginx.com> Message-ID: Валентин, в Google я обязательно сообщу. Для этого в том числе и создавался стенд. слишком много нам крови попортила эта бага, чтобы сейчас отступать. я понимаю вашу реакцию, думаю, в дальнейшем есть шансы на послабление бескомпромиссной позиции WONTFIX. для сравнения тот же "gzip_disable msie6" вполне можно было не делать, а сказать "проблема Майкрософт, браузер же честно говорит Accept-Encoding: gzip, вот мы и отдаем ему gzip". 14 августа 2013 г., 15:32 пользователь Валентин Бартенев написал: > On Wednesday 14 August 2013 12:29:10 Илья Шипицин wrote: >> Добрый день! >> >> мы налетели на забавную ситуацию, как оказалось, Chrome и nginx >> по-разному смотрят на стандарты SPDY. Если отправлять пустой хедер, то >> Chrome считает, что это корректно и отправляет, nginx же считает, что >> некорректно и режет. >> >> для разбора полетов сделали два стенда >> >> https://spdy2.skbkontur.ru >> https://spdy3.skbkontur.ru (тут для сравнения поднят node.js) >> >> учитывая долю Chrome среди браузеров, надо что-то с этим делать. >> > > Люди из Google сами в протоколе эту ситуацию явно прописали, даже указали, какую > ошибку MUST возвращать сервер. > > The length of each name and value must be greater than zero. A receiver of a > zero-length name or value must send a RST_STREAM with code PROTOCOL error. > > http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-HEADERS > > Предлагаю сообщить о баге в Chrome. Разработчики Firefox и Opera читали > спецификацию и ведут себя корректно. > > SPDY draft. 3 предписывает то же самое: > > A recipient of a zero-length name MUST issue a stream error > (Section 2.4.2) with the status code PROTOCOL_ERROR for the > stream-id. > > https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Wed Aug 14 10:22:45 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 14 Aug 2013 14:22:45 +0400 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: References: <201308141332.03806.vbart@nginx.com> Message-ID: <201308141422.45972.vbart@nginx.com> On Wednesday 14 August 2013 13:59:34 Илья Шипицин wrote: > Валентин, в Google я обязательно сообщу. Для этого в том числе и > создавался стенд. > слишком много нам крови попортила эта бага, чтобы сейчас отступать. > > я понимаю вашу реакцию, думаю, в дальнейшем есть шансы на послабление > бескомпромиссной позиции WONTFIX. > для сравнения тот же "gzip_disable msie6" вполне можно было не делать, > а сказать "проблема Майкрософт, браузер же честно говорит > Accept-Encoding: gzip, вот мы и отдаем ему gzip". > [..] Я не писал про WONTFIX. Не вижу больших проблем с пропуском заголовков с пустым значением. -- Валентин Бартенев http://nginx.org/en/donation.html From chipitsine at gmail.com Wed Aug 14 10:31:38 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 16:31:38 +0600 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: <201308141422.45972.vbart@nginx.com> References: <201308141332.03806.vbart@nginx.com> <201308141422.45972.vbart@nginx.com> Message-ID: учитывая ситуацию 1) сколько в мире инсталировано браузеров Chrome 2) отсутствия негативных последствий пропуска пустого хедера (они вообще могут быть ?) наверное, логично просто пропускать пустой хедер. 14 августа 2013 г., 16:22 пользователь Валентин Бартенев написал: > On Wednesday 14 August 2013 13:59:34 Илья Шипицин wrote: >> Валентин, в Google я обязательно сообщу. Для этого в том числе и >> создавался стенд. >> слишком много нам крови попортила эта бага, чтобы сейчас отступать. >> >> я понимаю вашу реакцию, думаю, в дальнейшем есть шансы на послабление >> бескомпромиссной позиции WONTFIX. >> для сравнения тот же "gzip_disable msie6" вполне можно было не делать, >> а сказать "проблема Майкрософт, браузер же честно говорит >> Accept-Encoding: gzip, вот мы и отдаем ему gzip". >> > [..] > > Я не писал про WONTFIX. Не вижу больших проблем с пропуском заголовков > с пустым значением. > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Wed Aug 14 10:42:32 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 14 Aug 2013 14:42:32 +0400 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: References: <201308141422.45972.vbart@nginx.com> Message-ID: <201308141442.32137.vbart@nginx.com> On Wednesday 14 August 2013 14:31:38 Илья Шипицин wrote: > учитывая ситуацию > > 1) сколько в мире инсталировано браузеров Chrome > 2) отсутствия негативных последствий пропуска пустого хедера (они > вообще могут быть ?) > > наверное, логично просто пропускать пустой хедер. [..] Можете опробовать: diff -r 7094bd12c1ff src/http/ngx_http_spdy.c --- a/src/http/ngx_http_spdy.c Tue Aug 06 19:58:40 2013 +0400 +++ b/src/http/ngx_http_spdy.c Wed Aug 14 14:41:13 2013 +0400 @@ -2001,10 +2001,6 @@ ngx_http_spdy_parse_header(ngx_http_requ len = ngx_spdy_frame_parse_uint16(p); - if (!len) { - return NGX_ERROR; - } - p += NGX_SPDY_NV_VLEN_SIZE; r->header_end = p + len; -- Валентин Бартенев http://nginx.org/en/donation.html From mail at knutov.com Wed Aug 14 10:55:46 2013 From: mail at knutov.com (Nick Knutov) Date: Wed, 14 Aug 2013 16:55:46 +0600 Subject: =?UTF-8?B?0YDQtdC70L7QsNC0INC60L7QvdGE0LjQs9Cw?= Message-ID: <520B6232.9040809@knutov.com> В последних нескольких версиях nginx не перечитывает конфиг по сигналу HUP (рестарт при этом приводит к запуску нгинх с новым конфигом). Что-то изменилось, или я что-то делаю не так? # cat /var/run/nginx.pid 31162 # kill -HUP 31162 # ps auxfw | grep nginx root 31162 0.0 1.0 50912 26612 ? Ss Aug11 0:00 nginx: master process /usr/sbin/nginx nobody 31163 0.1 1.0 51756 27440 ? S Aug11 6:50 \_ nginx: worker process nobody 31164 0.1 1.0 52152 27976 ? S Aug11 6:51 \_ nginx: worker process Aug11 осталось как было (а сейчс Aug14), при обращении по хттп видно, что конфиг старый. # nginx -t nginx: [warn] low address bits of ***.***.***.***/27 are meaningless in /etc/nginx/nginx.conf:96 nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From chipitsine at gmail.com Wed Aug 14 10:59:29 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 16:59:29 +0600 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: <201308141442.32137.vbart@nginx.com> References: <201308141422.45972.vbart@nginx.com> <201308141442.32137.vbart@nginx.com> Message-ID: да, с таким патчем все ок. как пожелание - в ngx_http_spdy.c три места, откуда может прилететь NGX_ERROR (после патча - 2 места), никакой отладки в лог не попадает, сходу непонятно, почему порвалось. на стенд патч не накатил, вдруг гугл будет смотреть, а там все работает. 14 августа 2013 г., 16:42 пользователь Валентин Бартенев написал: > On Wednesday 14 August 2013 14:31:38 Илья Шипицин wrote: >> учитывая ситуацию >> >> 1) сколько в мире инсталировано браузеров Chrome >> 2) отсутствия негативных последствий пропуска пустого хедера (они >> вообще могут быть ?) >> >> наверное, логично просто пропускать пустой хедер. > [..] > > Можете опробовать: > > diff -r 7094bd12c1ff src/http/ngx_http_spdy.c > --- a/src/http/ngx_http_spdy.c Tue Aug 06 19:58:40 2013 +0400 > +++ b/src/http/ngx_http_spdy.c Wed Aug 14 14:41:13 2013 +0400 > @@ -2001,10 +2001,6 @@ ngx_http_spdy_parse_header(ngx_http_requ > > len = ngx_spdy_frame_parse_uint16(p); > > - if (!len) { > - return NGX_ERROR; > - } > - > p += NGX_SPDY_NV_VLEN_SIZE; > > r->header_end = p + len; > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mail at knutov.com Wed Aug 14 11:02:18 2013 From: mail at knutov.com (Nick Knutov) Date: Wed, 14 Aug 2013 17:02:18 +0600 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520B6232.9040809@knutov.com> References: <520B6232.9040809@knutov.com> Message-ID: <520B63BA.1080904@knutov.com> # nginx -V nginx version: nginx/1.5.2 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --with-cc-opt='-D FD_SETSIZE=2048' --http-client-body-temp-path=/var/cache/nginx/body_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --lock-path=/var/lock/nginx.lock --with-http_ssl_module --with-http_stub_status_module --with-http_flv_module --with-http_mp4_module --with-http_realip_module --with-http_gzip_static_module --with-http_secure_link_module --with-http_sub_module --with-file-aio --with-pcre=/root/build/deb-build/nginx-1.5.2/../pcre --with-pcre-jit --with-http_geoip_module --add-module=/root/build/deb-build/nginx-1.5.2/debian/modules/ngx-fancyindex Обнаружил, что на другом сервере всё ок: после после kill -HUP /# ps auxfw | grep nginx root 14565 0.0 1.8 62696 47664 ? Ss Aug07 0:00 nginx: master process /usr/sbin/nginx nobody 9406 0.3 1.7 62628 45860 ? S Aug11 13:22 \_ nginx: worker process is shutting down nobody 9407 0.2 1.7 62628 45852 ? S Aug11 13:10 \_ nginx: worker process is shutting down nobody 24697 0.8 1.8 62700 47464 ? S 14:56 0:00 \_ nginx: worker process nobody 24698 0.0 1.8 62700 47444 ? S 14:56 0:00 \_ nginx: worker process Сборка nginx на обоих серверах одинаковая (у нас собственные сборки деб пакетов), на обоих серверах нгинх поставлен из одного деба, оба сервера OpenVZ с одним ядром и одной убунтой # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04.2 LTS Release: 12.04 Codename: precise на которой стоят одинаковые пакеты. Проблема на первом сервере стабильно воспроизводится. 14.08.2013 16:55, Nick Knutov пишет: > В последних нескольких версиях nginx не перечитывает конфиг по сигналу > HUP (рестарт при этом приводит к запуску нгинх с новым конфигом). > > Что-то изменилось, или я что-то делаю не так? > > # cat /var/run/nginx.pid > 31162 > > # kill -HUP 31162 > > # ps auxfw | grep nginx > root 31162 0.0 1.0 50912 26612 ? Ss Aug11 0:00 nginx: > master process /usr/sbin/nginx > nobody 31163 0.1 1.0 51756 27440 ? S Aug11 6:50 \_ > nginx: worker process > nobody 31164 0.1 1.0 52152 27976 ? S Aug11 6:51 \_ > nginx: worker process > > Aug11 осталось как было (а сейчс Aug14), при обращении по хттп видно, > что конфиг старый. > > # nginx -t > nginx: [warn] low address bits of ***.***.***.***/27 are meaningless in > /etc/nginx/nginx.conf:96 > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok > nginx: configuration file /etc/nginx/nginx.conf test is successful > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From onokonem at gmail.com Wed Aug 14 11:07:57 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 14 Aug 2013 15:07:57 +0400 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520B63BA.1080904@knutov.com> References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> Message-ID: > Проблема на первом сервере стабильно воспроизводится. скорее всего - сигнал уходит не тому процессу From mail at knutov.com Wed Aug 14 11:13:09 2013 From: mail at knutov.com (Nick Knutov) Date: Wed, 14 Aug 2013 17:13:09 +0600 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> Message-ID: <520B6645.8050706@knutov.com> Но как??? pid берется из пид файла, именно из того, который прописан в конфиге. Сигнал посылается именно этому пиду. Как он может уйти не туда? # cat /etc/nginx/nginx.conf | grep pid pid /var/run/nginx.pid; Конфиги на обоих серверах однаковые, кроме множества server {}. 14.08.2013 17:07, Daniel Podolsky пишет: >> Проблема на первом сервере стабильно воспроизводится. > скорее всего - сигнал уходит не тому процессу > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From onokonem at gmail.com Wed Aug 14 11:28:57 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 14 Aug 2013 15:28:57 +0400 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520B6645.8050706@knutov.com> References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B6645.8050706@knutov.com> Message-ID: > pid берется из пид файла, именно из того, который прописан в конфиге. > Сигнал посылается именно этому пиду. а вы еще проверьте - действительно ли под этим pid работает ваш nginx ну и killall -HUP nginx никто не отменял From gmm at csdoc.com Wed Aug 14 11:58:49 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 14 Aug 2013 14:58:49 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520B63BA.1080904@knutov.com> References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> Message-ID: <520B70F9.2000801@csdoc.com> On 14.08.2013 14:02, Nick Knutov wrote: > # nginx -V > --with-cc-opt='-DFD_SETSIZE=2048' массив, заданный FD_SETSIZE используется только в том случае, когда для обработки соединений используется select() использовать select() с современными версиями ядер смысла нет. ведь на Linux nginx всеравно будет использовать epoll подробности: http://nginx.org/ru/docs/events.html я даже специально выставляю при сборке nginx --without-select_module --without-poll_module чтобы этот лишний код не компилировался внутрь бинарника. (select и poll нужны на старых ядрах, версий 2.2 и 2.4) более того, на Linux невозможно изменить FD_SETSIZE, система всеравно будет использовать значение по-умолчанию 1024 http://www.moythreads.com/wordpress/2009/12/22/select-system-call-limitation/ /usr/include/sys/select.h - здесь задается битовый массив /usr/include/bits/typesizes.h - здесь задается __FD_SETSIZE в результате: "An fd_set is a fixed size buffer. Executing FD_CLR or FD_SET with a value of fd that is negative or is equal to or larger than FD_SETSIZE will result in undefined behavior." > Проблема на первом сервере стабильно воспроизводится. причину проблем может помочь понять отладочный лог: http://nginx.org/ru/docs/debugging_log.html параметр --with-debug много оверхеда не добавляет, но очень удобен при поиске причин различных проблем. -- Best regards, Gena From lavandas at ya.ru Wed Aug 14 15:25:25 2013 From: lavandas at ya.ru (=?koi8-r?B?8tXTwc7P1yDvzMXH?=) Date: Wed, 14 Aug 2013 19:25:25 +0400 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: References: <201308141422.45972.vbart@nginx.com> <201308141442.32137.vbart@nginx.com> Message-ID: <159861376493925@web5g.yandex.ru> An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Wed Aug 14 17:32:13 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 23:32:13 +0600 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: References: Message-ID: http://trac.nginx.org/nginx/ticket/385 http://code.google.com/p/mod-spdy/issues/detail?id=41 похожие баги. 14 августа 2013 г., 14:29 пользователь Илья Шипицин написал: > Добрый день! > > мы налетели на забавную ситуацию, как оказалось, Chrome и nginx > по-разному смотрят на стандарты SPDY. Если отправлять пустой хедер, то > Chrome считает, что это корректно и отправляет, nginx же считает, что > некорректно и режет. > > для разбора полетов сделали два стенда > > https://spdy2.skbkontur.ru > https://spdy3.skbkontur.ru (тут для сравнения поднят node.js) > > учитывая долю Chrome среди браузеров, надо что-то с этим делать. > > Илья Шипицин From nginx-forum at nginx.us Wed Aug 14 17:43:36 2013 From: nginx-forum at nginx.us (Gurd) Date: Wed, 14 Aug 2013 13:43:36 -0400 Subject: =?UTF-8?B?0JzQvtC00YPQu9GMIG5neCBodHRwIGFjY2VzcyBtb2R1bGU=?= Message-ID: Здравствуйте! Модуль ngx_http_access_module location / { deny 192.168.1.1; allow 192.168.1.0/24; allow 10.1.1.0/16; allow 2001:0db8::/32; deny all; } Подскажите, пожалуйста, можно ли как-то получить флаг или переменную, срабатывания правила, запрещённой сети? Что-то типа: if ($deny_ip) proxy_set_header Allow-Piring '1'; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241859,241859#msg-241859 From chipitsine at gmail.com Wed Aug 14 17:48:11 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 14 Aug 2013 23:48:11 +0600 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBuZ3ggaHR0cCBhY2Nlc3MgbW9kdWxl?= In-Reply-To: References: Message-ID: access_by_lua ? 14 августа 2013 г., 23:43 пользователь Gurd написал: > Здравствуйте! > > Модуль ngx_http_access_module > > location / { > deny 192.168.1.1; > allow 192.168.1.0/24; > allow 10.1.1.0/16; > allow 2001:0db8::/32; > deny all; > } > > Подскажите, пожалуйста, можно ли как-то получить флаг или переменную, > срабатывания правила, запрещённой сети? > > Что-то типа: > > if ($deny_ip) > proxy_set_header Allow-Piring '1'; > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241859,241859#msg-241859 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Wed Aug 14 17:49:09 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 14 Aug 2013 21:49:09 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBuZ3ggaHR0cCBhY2Nlc3MgbW9kdWxl?= In-Reply-To: References: Message-ID: <201308142149.09950.vbart@nginx.com> On Wednesday 14 August 2013 21:43:36 Gurd wrote: > Здравствуйте! > > Модуль ngx_http_access_module > > location / { > deny 192.168.1.1; > allow 192.168.1.0/24; > allow 10.1.1.0/16; > allow 2001:0db8::/32; > deny all; > } > > Подскажите, пожалуйста, можно ли как-то получить флаг или переменную, > срабатывания правила, запрещённой сети? > > Что-то типа: > > if ($deny_ip) > proxy_set_header Allow-Piring '1'; > Использовать geo-модуль. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Aug 14 19:22:59 2013 From: nginx-forum at nginx.us (Gurd) Date: Wed, 14 Aug 2013 15:22:59 -0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBuZ3ggaHR0cCBhY2Nlc3MgbW9kdWxl?= In-Reply-To: <201308142149.09950.vbart@nginx.com> References: <201308142149.09950.vbart@nginx.com> Message-ID: <41e247a598776b140d2b6bbc2127b8d1.NginxMailingListRussian@forum.nginx.org> Благодарю, всё получилось. P.S Прошу прощения, за 3 одинаковые темы, нажимал вреде просто обновить. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241861,241862#msg-241862 From mail at knutov.com Wed Aug 14 23:30:15 2013 From: mail at knutov.com (Nick Knutov) Date: Thu, 15 Aug 2013 05:30:15 +0600 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520B70F9.2000801@csdoc.com> References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B70F9.2000801@csdoc.com> Message-ID: <520C1307.8010509@knutov.com> ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3. Что искать в дебаг логе? Я не вижу там никаких признаков получения сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно работает. 14.08.2013 17:58, Gena Makhomed пишет: > On 14.08.2013 14:02, Nick Knutov wrote: > [...] >> Проблема на первом сервере стабильно воспроизводится. > > причину проблем может помочь понять отладочный лог: > http://nginx.org/ru/docs/debugging_log.html > > параметр --with-debug много оверхеда не добавляет, > но очень удобен при поиске причин различных проблем. > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From vadim.lazovskiy at gmail.com Thu Aug 15 05:10:11 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 15 Aug 2013 09:10:11 +0400 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520C1307.8010509@knutov.com> References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B70F9.2000801@csdoc.com> <520C1307.8010509@knutov.com> Message-ID: Здравствуйте. Попробуйте собрать без --with-file-aio 15 августа 2013 г., 3:30 пользователь Nick Knutov написал: > ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3. > > Что искать в дебаг логе? Я не вижу там никаких признаков получения > сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно > работает. > > 14.08.2013 17:58, Gena Makhomed пишет: > > On 14.08.2013 14:02, Nick Knutov wrote: > > [...] > >> Проблема на первом сервере стабильно воспроизводится. > > > > причину проблем может помочь понять отладочный лог: > > http://nginx.org/ru/docs/debugging_log.html > > > > параметр --with-debug много оверхеда не добавляет, > > но очень удобен при поиске причин различных проблем. > > > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > > _______________________________________________ > 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 nginx-forum at nginx.us Thu Aug 15 07:18:43 2013 From: nginx-forum at nginx.us (lekrus) Date: Thu, 15 Aug 2013 03:18:43 -0400 Subject: =?UTF-8?B?0LLRi9C30L7QsiBtYXAgdmFyaWFibGUg0LTQstCw0LbQtNGL?= Message-ID: Здравствуйте, У меня используется переменная map $v_host $backend { default 1; test 2; test2 3; } Далее идет location / { set $v_host test; proxy_pass $backend #(тут переменная $backend правильно определяется, равна 2) } в процессе, upstream возвращает X-Accel-Redirect который вызывает другой location /int { internal; set $v_host test2; rewrite (.*) $backend } и при таком вызове $backend остается равен 2, должен быть 3. Я правильно понимаю, что в процессе одного вызова, если переменная map хоть раз была вычислена, далее все остальные вызовы используют это значение, независимо от того, меняется ли переменная, по которой определяется значение? Есть ли возможность как-то заставить перевычислить это значение? Спасибо, Алексей Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241868,241868#msg-241868 From ru at nginx.com Thu Aug 15 08:26:29 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Thu, 15 Aug 2013 12:26:29 +0400 Subject: =?UTF-8?B?UmU6INCy0YvQt9C+0LIgbWFwIHZhcmlhYmxlINC00LLQsNC20LTRiw==?= In-Reply-To: References: Message-ID: <20130815082629.GN52681@lo0.su> On Thu, Aug 15, 2013 at 03:18:43AM -0400, lekrus wrote: > Здравствуйте, > > У меня используется переменная > map $v_host $backend { > default 1; > test 2; > test2 3; > } > > Далее идет > > location / { > set $v_host test; > proxy_pass $backend #(тут переменная $backend правильно определяется, равна > 2) > } > > в процессе, upstream возвращает X-Accel-Redirect который вызывает другой > location /int { > internal; > set $v_host test2; > rewrite (.*) $backend > } > > и при таком вызове $backend остается равен 2, должен быть 3. > > Я правильно понимаю, что в процессе одного вызова, если переменная map хоть > раз была вычислена, далее все остальные вызовы используют это значение, > независимо от того, меняется ли переменная, по которой определяется > значение? Правильно понимаете. Определяться кстати она может не только по одной переменной, а по произвольному выражению, содержащему как строки, так и переменные. > Есть ли возможность как-то заставить перевычислить это значение? Можно, но только пропатчив nginx: diff --git a/src/http/modules/ngx_http_map_module.c b/src/http/modules/ngx_http_map_module.c --- a/src/http/modules/ngx_http_map_module.c +++ b/src/http/modules/ngx_http_map_module.c @@ -477,7 +477,7 @@ ngx_http_map(ngx_conf_t *cf, ngx_command } var->valid = 1; - var->no_cacheable = 0; + var->no_cacheable = 1; var->not_found = 0; vp = ngx_array_push(&ctx->values_hash[key]); From andrey at kopeyko.ru Thu Aug 15 08:55:10 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Thu, 15 Aug 2013 12:55:10 +0400 Subject: =?UTF-8?B?UmU6INCy0YvQt9C+0LIgbWFwIHZhcmlhYmxlINC00LLQsNC20LTRiw==?= In-Reply-To: References: Message-ID: <520C976E.6040204@kopeyko.ru> 15.08.2013 11:18, lekrus пишет: > Здравствуйте, > > У меня используется переменная > map $v_host $backend { > default 1; > test 2; > test2 3; > } > > Далее идет > > location / { > set $v_host test; > proxy_pass $backend #(тут переменная $backend правильно определяется, равна > 2) > } > > в процессе, upstream возвращает X-Accel-Redirect который вызывает другой > location /int { > internal; > set $v_host test2; > rewrite (.*) $backend > } > > и при таком вызове $backend остается равен 2, должен быть 3. > > Я правильно понимаю, что в процессе одного вызова, если переменная map хоть > раз была вычислена, далее все остальные вызовы используют это значение, > независимо от того, меняется ли переменная, по которой определяется > значение? > > Есть ли возможность как-то заставить перевычислить это значение? Я бы посоветовал пользовать две мапы вместо одной. Что содержимое у них будет одинаковое - так генератору конфига это без разницы. -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Thu Aug 15 09:05:03 2013 From: nginx-forum at nginx.us (lekrus) Date: Thu, 15 Aug 2013 05:05:03 -0400 Subject: =?UTF-8?B?UmU6INCy0YvQt9C+0LIgbWFwIHZhcmlhYmxlINC00LLQsNC20LTRiw==?= In-Reply-To: <520C976E.6040204@kopeyko.ru> References: <520C976E.6040204@kopeyko.ru> Message-ID: Спасибо, Андрей, Я в результате так и делаю, просто хотел уточнить, что это так и задумано и нет возможности перевычислить переменную второй раз. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241868,241871#msg-241871 From nginx-forum at nginx.us Thu Aug 15 09:07:33 2013 From: nginx-forum at nginx.us (lekrus) Date: Thu, 15 Aug 2013 05:07:33 -0400 Subject: =?UTF-8?B?UmU6INCy0YvQt9C+0LIgbWFwIHZhcmlhYmxlINC00LLQsNC20LTRiw==?= In-Reply-To: <20130815082629.GN52681@lo0.su> References: <20130815082629.GN52681@lo0.su> Message-ID: <77db17f66503d7137668347e336d5c57.NginxMailingListRussian@forum.nginx.org> Спасибо, Руслан! А в момент выполнения пока никаких вариантов нет, чтобы сбросить значение и заставить перевычислить значение? (в других случаях такое кеширование было бы уместным) Алексей Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241868,241872#msg-241872 From gmm at csdoc.com Thu Aug 15 09:11:25 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 15 Aug 2013 12:11:25 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520C1307.8010509@knutov.com> References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B70F9.2000801@csdoc.com> <520C1307.8010509@knutov.com> Message-ID: <520C9B3D.5010501@csdoc.com> On 15.08.2013 2:30, Nick Knutov wrote: > ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3. > Что искать в дебаг логе? Я не вижу там никаких признаков получения > сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно > работает. если включить отладочный лог - в нем видно получение сигналов и что nginx делает дальше, после получения сигнала: [notice] 2602#0: signal 1 (SIGHUP) received, reconfiguring [notice] 2602#0: signal 15 (SIGTERM) received, exiting [notice] 9580#0: signal 3 (SIGQUIT) received, shutting down отладочный лог включается так: error_log /var/log/nginx/error.log debug; если в логе и правда нет ничего о том, что nginx получил сигнал SIGHUP - скорее всего это означает, что он его действительно не получал. такого эффекта можно добиться, например, запуская программу через враппер nohup (подробнее - см. man nohup) -- Best regards, Gena From vbart at nginx.com Thu Aug 15 10:09:25 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 15 Aug 2013 14:09:25 +0400 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520C9B3D.5010501@csdoc.com> References: <520B6232.9040809@knutov.com> <520C1307.8010509@knutov.com> <520C9B3D.5010501@csdoc.com> Message-ID: <201308151409.25367.vbart@nginx.com> On Thursday 15 August 2013 13:11:25 Gena Makhomed wrote: > On 15.08.2013 2:30, Nick Knutov wrote: > > ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3. > > > > Что искать в дебаг логе? Я не вижу там никаких признаков получения > > сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно > > работает. > > если включить отладочный лог - в нем видно получение сигналов > и что nginx делает дальше, после получения сигнала: > > [notice] 2602#0: signal 1 (SIGHUP) received, reconfiguring > [notice] 2602#0: signal 15 (SIGTERM) received, exiting > [notice] 9580#0: signal 3 (SIGQUIT) received, shutting down [..] Ради этих сообщений и не нужно включать отладочный лог. Достаточно уровня логгирования notice или info. -- Валентин Бартенев http://nginx.org/en/donation.html From gmm at csdoc.com Thu Aug 15 11:17:24 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 15 Aug 2013 14:17:24 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <201308151409.25367.vbart@nginx.com> References: <520B6232.9040809@knutov.com> <520C1307.8010509@knutov.com> <520C9B3D.5010501@csdoc.com> <201308151409.25367.vbart@nginx.com> Message-ID: <520CB8C4.8050403@csdoc.com> On 15.08.2013 13:09, Валентин Бартенев wrote: >>> Что искать в дебаг логе? Я не вижу там никаких признаков получения >>> сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно >>> работает. >> >> если включить отладочный лог - в нем видно получение сигналов >> и что nginx делает дальше, после получения сигнала: >> >> [notice] 2602#0: signal 1 (SIGHUP) received, reconfiguring >> [notice] 2602#0: signal 15 (SIGTERM) received, exiting >> [notice] 9580#0: signal 3 (SIGQUIT) received, shutting down > Ради этих сообщений и не нужно включать отладочный лог. Достаточно уровня > логгирования notice или info. ради этих - да. но у топикстартера были обоснованные подозрения, что nginx сигнал HUP получает, но потом почему-то правильным образом на него не реагирует. debug нужен для "...что nginx делает дальше, после получения сигнала" -- Best regards, Gena From vadim.lazovskiy at gmail.com Thu Aug 15 11:58:18 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 15 Aug 2013 15:58:18 +0400 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: <520C1307.8010509@knutov.com> References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B70F9.2000801@csdoc.com> <520C1307.8010509@knutov.com> Message-ID: А нет ли где в логах "too many open files"? 15 августа 2013 г., 3:30 пользователь Nick Knutov написал: > ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3. > > Что искать в дебаг логе? Я не вижу там никаких признаков получения > сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно > работает. > > 14.08.2013 17:58, Gena Makhomed пишет: > > On 14.08.2013 14:02, Nick Knutov wrote: > > [...] > >> Проблема на первом сервере стабильно воспроизводится. > > > > причину проблем может помочь понять отладочный лог: > > http://nginx.org/ru/docs/debugging_log.html > > > > параметр --with-debug много оверхеда не добавляет, > > но очень удобен при поиске причин различных проблем. > > > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > > _______________________________________________ > 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 mail at knutov.com Thu Aug 15 12:42:26 2013 From: mail at knutov.com (Nick Knutov) Date: Thu, 15 Aug 2013 18:42:26 +0600 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B70F9.2000801@csdoc.com> <520C1307.8010509@knutov.com> Message-ID: <520CCCB2.4050406@knutov.com> Ничего не изменилось. Заодним, обновил ноду до последнего стабильного OpenVZ ядра, тоже никак не повлияло. 15.08.2013 11:10, Vadim Lazovskiy пишет: > Здравствуйте. > > Попробуйте собрать без > --with-file-aio -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From mail at knutov.com Thu Aug 15 12:43:03 2013 From: mail at knutov.com (Nick Knutov) Date: Thu, 15 Aug 2013 18:43:03 +0600 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B70F9.2000801@csdoc.com> <520C1307.8010509@knutov.com> Message-ID: <520CCCD7.9020602@knutov.com> Нет 15.08.2013 17:58, Vadim Lazovskiy пишет: > А нет ли где в логах "too many open files"? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From mail at knutov.com Thu Aug 15 13:01:24 2013 From: mail at knutov.com (Nick Knutov) Date: Thu, 15 Aug 2013 19:01:24 +0600 Subject: =?UTF-8?B?UmU6INGA0LXQu9C+0LDQtCDQutC+0L3RhNC40LPQsA==?= In-Reply-To: References: <520B6232.9040809@knutov.com> <520B63BA.1080904@knutov.com> <520B70F9.2000801@csdoc.com> <520C1307.8010509@knutov.com> Message-ID: <520CD124.7000505@knutov.com> о! Я, оказывается, включал дебаг лог на уровне http {}, а не выше. Действительно есть "too many open files", увеличение worker_rlimit_nofile решило проблему, спасибо. 15.08.2013 17:58, Vadim Lazovskiy пишет: > А нет ли где в логах "too many open files"? > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From xdebian6 at gmail.com Thu Aug 15 17:04:19 2013 From: xdebian6 at gmail.com (xServer) Date: Thu, 15 Aug 2013 21:04:19 +0400 Subject: No subject Message-ID: добрый день! Имею следующую проблему: Не срабатывает директива error_page при связке Nginx + php-fpm. Использую директиву limit_conn для лимитирования одновременных соединений с одного IP, при превышении лимита выдаётся ошибка 503, я создал свою страницу для этой ошибки (50x.shtml) но я не вижу эту свою страницу, вместо неё выдаётся дефолтная встроенная страница для ошибки 503. При связке Nginx + Apache моя страница для ошибки 503 отображалась нормально, дефолтная встроенная страница не беспокоила. Настройки те же: error_page 500 502 503 504 /50x.shtml; location = /50x.shtml { allow all; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Thu Aug 15 19:11:27 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 15 Aug 2013 23:11:27 +0400 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: References: Message-ID: <201308152311.27740.vbart@nginx.com> On Wednesday 14 August 2013 21:32:13 Илья Шипицин wrote: > http://trac.nginx.org/nginx/ticket/385 Никакого отношения к проблеме не имеет. P.S. Патч закоммичен. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Aug 16 08:10:32 2013 From: nginx-forum at nginx.us (Meison) Date: Fri, 16 Aug 2013 04:10:32 -0400 Subject: =?UTF-8?B?Sm9vbWxhICgrUGhvY2EgR2FsbGVyeSkgKyBuZ2lueCArIHBocC1mcG06INCf0YA=?= =?UTF-8?B?0L7QsdC70LXQvNCwINC/0YDQuCDQs9C10L3QtdGA0LDRhtC40Lgg0LrQsNGA?= =?UTF-8?B?0YLQuNC90L7Qug==?= Message-ID: Привет! Есть проблема: При генерации миниатюр для Phoca Gallery, скрипт генерирует парочку картинок и все - белый экран, нечего не происходит. Помогает только рестарт nginx сервера. Мои конфиги nginx: location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/tmp/wwwpool.sock; fastcgi_cache one; fastcgi_cache_min_uses 3; fastcgi_cache_valid 200 301 302 304 5m; fastcgi_cache_key "$request_method|$host|$request_uri"; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_ignore_client_abort off; } index index.html index.php; location / { try_files $uri $uri/ /index.php?q=$uri&$args; } location ~ /\.ht { deny all; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|asp|sh|cgi)$ { return 403; error_page 403 /403_error.html; } # caching of files location ~* \.(ico|pdf|flv)$ { expires 1y; } location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ { expires 14d; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241914,241914#msg-241914 From nginx-forum at nginx.us Fri Aug 16 10:48:20 2013 From: nginx-forum at nginx.us (skeletor) Date: Fri, 16 Aug 2013 06:48:20 -0400 Subject: =?UTF-8?B?0LjRgdC60LvRjtGH0LXQvdC40LUg0LIgYXV0aCBiYXNpYw==?= Message-ID: <2ac20730563ee1e52a01aacddc5bb959.NginxMailingListRussian@forum.nginx.org> Возможно ли сделать исключение в auth_basic, например такое: отключить auth_basic для определённых IP юзеров? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241923,241923#msg-241923 From sargaskn at gmail.com Fri Aug 16 11:05:19 2013 From: sargaskn at gmail.com (Sargas) Date: Fri, 16 Aug 2013 14:05:19 +0300 Subject: =?UTF-8?B?UmU6INC40YHQutC70Y7Rh9C10L3QuNC1INCyIGF1dGggYmFzaWM=?= In-Reply-To: <2ac20730563ee1e52a01aacddc5bb959.NginxMailingListRussian@forum.nginx.org> References: <2ac20730563ee1e52a01aacddc5bb959.NginxMailingListRussian@forum.nginx.org> Message-ID: http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy 16 августа 2013 г., 13:48 пользователь skeletor написал: > Возможно ли сделать исключение в auth_basic, например такое: отключить > auth_basic для определённых IP юзеров? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,241923,241923#msg-241923 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Aug 16 11:06:06 2013 From: nginx-forum at nginx.us (Sargas) Date: Fri, 16 Aug 2013 07:06:06 -0400 Subject: =?UTF-8?B?UmU6INC40YHQutC70Y7Rh9C10L3QuNC1INCyIGF1dGggYmFzaWM=?= In-Reply-To: <2ac20730563ee1e52a01aacddc5bb959.NginxMailingListRussian@forum.nginx.org> References: <2ac20730563ee1e52a01aacddc5bb959.NginxMailingListRussian@forum.nginx.org> Message-ID: <402cd5944fac2352744ced1b99c1f99c.NginxMailingListRussian@forum.nginx.org> http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241923,241926#msg-241926 From nginx-forum at nginx.us Fri Aug 16 11:33:07 2013 From: nginx-forum at nginx.us (skeletor) Date: Fri, 16 Aug 2013 07:33:07 -0400 Subject: =?UTF-8?B?UmU6INC40YHQutC70Y7Rh9C10L3QuNC1INCyIGF1dGggYmFzaWM=?= In-Reply-To: <402cd5944fac2352744ced1b99c1f99c.NginxMailingListRussian@forum.nginx.org> References: <2ac20730563ee1e52a01aacddc5bb959.NginxMailingListRussian@forum.nginx.org> <402cd5944fac2352744ced1b99c1f99c.NginxMailingListRussian@forum.nginx.org> Message-ID: Спасибо, похоже то, что нужно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241923,241931#msg-241931 From nginx-forum at nginx.us Fri Aug 16 12:30:50 2013 From: nginx-forum at nginx.us (Meison) Date: Fri, 16 Aug 2013 08:30:50 -0400 Subject: =?UTF-8?B?UmU6IEpvb21sYSAoK1Bob2NhIEdhbGxlcnkpICsgbmdpbnggKyBwaHAtZnBtOiA=?= =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDQv9GA0Lgg0LPQtdC90LXRgNCw0YbQuNC4INC6?= =?UTF-8?B?0LDRgNGC0LjQvdC+0Lo=?= In-Reply-To: References: Message-ID: <0f826dc63a0f891c0b067a31c58ad990.NginxMailingListRussian@forum.nginx.org> Совсем забыл! Конфиг nginx.conf: user user; worker_processes 1; pid /var/run/nginx.pid; events { worker_connections 1024; use epoll; } http { fastcgi_cache_path /tmp/fcgi-cache/ levels=1:2 keys_zone=one:10m; sendfile on; sendfile_max_chunk 128k; postpone_output 1460; server_names_hash_bucket_size 64; client_max_body_size 15m; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; proxy_read_timeout 120; proxy_connect_timeout 120; server_tokens off; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; ssi on; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241914,241933#msg-241933 From mdounin at mdounin.ru Sat Aug 17 01:31:14 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 17 Aug 2013 05:31:14 +0400 Subject: your mail In-Reply-To: References: Message-ID: <20130817013114.GW2130@mdounin.ru> Hello! On Thu, Aug 15, 2013 at 09:04:19PM +0400, xServer wrote: > добрый день! > Имею следующую проблему: > > Не срабатывает директива error_page при связке Nginx + php-fpm. > Использую директиву limit_conn для лимитирования одновременных соединений с > одного IP, при превышении лимита выдаётся ошибка 503, я создал свою > страницу для этой ошибки (50x.shtml) но я не вижу эту свою страницу, вместо > неё выдаётся дефолтная встроенная страница для ошибки 503. > При связке Nginx + Apache моя страница для ошибки 503 отображалась > нормально, дефолтная встроенная страница не беспокоила. > > Настройки те же: > error_page 500 502 503 504 /50x.shtml; > location = /50x.shtml { > allow all; > } Встроенная страница об ошибке возвращается, если ошибка случается при обработке другой ошибки, см. http://nginx.org/r/recursive_error_pages. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Sat Aug 17 02:54:13 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 17 Aug 2013 06:54:13 +0400 Subject: =?UTF-8?B?UmU6IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <246767059.20130810234331@softsearch.ru> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> <246767059.20130810234331@softsearch.ru> Message-ID: <20130817025412.GA2130@mdounin.ru> Hello! On Sat, Aug 10, 2013 at 11:43:31PM +0400, Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> set на уровне http был бы очень удобен порой. Обходить это через > >> map 1 $var { > >> default "value"; > >> } > >> неудобно. > > > http://nginx.org/en/docs/faq/variables_in_config.html > > Признаюсь, что не въехал в ответ по ссылке. Все слова знакомые, а > собранные вместе смысл никакой в моей голове не приобретают. Тупею, > видимо. :-) > > Опишу задачу. Мне надо было как-то писать в аксес-лог кэш-зону, чтобы > потом по логам считать эффективность каждой кэш-зоны. Встроенную > переменную я не знаю, поэтому решил создать переменную через set. Там, > где запросы проксируются, я присваивал через set соответствующей > переменной значение, равное имени кэшзоны. Но не все запросы > проксируются и в логе вместо значения переменной пишется пустая > строка, что неудобно для парсинга лога. Брать переменную в кавычки > тоже неудобно. > > Для таких запросов я хотел присвоить этой переменной дефолтное > значение "-". Писать в каждом блоке server{} set или include посчитал > лишним и вставил в http{} вот такие строчки: > > # set нельзя делать на уровне http, поэтому делаем присваивание через map > map 1 $cache_zone_for_logging { > default "-"; > } > > Т.е. я хотел использовать set для инициализации переменной, которая > потом может меняться. > > На мой примитивный взгляд кажется нелогичным иметь иерархию блоков > конфига, иметь наследование с вышестоящих уровней иерархии и разрешать > set-у работать на уровне http{}. Всмысле - _не_ разрешать? Проблема состоит в том, что set - это директива модуля rewrite, которая не наследуется, выполняется вместе с остальными директивами в rewrite-фазе и т.п. Вводить директиву set на уровне http с совершенно другой семантикой - это не очень хорошая идея. -- Maxim Dounin http://nginx.org/en/donation.html From uncleandyv at gmail.com Sat Aug 17 15:18:48 2013 From: uncleandyv at gmail.com (Andrey Velikoredchanin) Date: Sat, 17 Aug 2013 19:18:48 +0400 Subject: [no subject] In-Reply-To: References: Message-ID: Думаю, вам нужно использовать proxy_intercept_errors on; 15 августа 2013 г., 21:04 пользователь xServer написал: > добрый день! > Имею следующую проблему: > > Не срабатывает директива error_page при связке Nginx + php-fpm. > Использую директиву limit_conn для лимитирования одновременных соединений > с одного IP, при превышении лимита выдаётся ошибка 503, я создал свою > страницу для этой ошибки (50x.shtml) но я не вижу эту свою страницу, вместо > неё выдаётся дефолтная встроенная страница для ошибки 503. > При связке Nginx + Apache моя страница для ошибки 503 отображалась > нормально, дефолтная встроенная страница не беспокоила. > > Настройки те же: > error_page 500 502 503 504 /50x.shtml; > location = /50x.shtml { > allow all; > } > > _______________________________________________ > 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 uncleandyv at gmail.com Sat Aug 17 15:21:27 2013 From: uncleandyv at gmail.com (Andrey Velikoredchanin) Date: Sat, 17 Aug 2013 19:21:27 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQtdC00LvQsNCz0LDRjiDQvdC10LzQvdC+0LPQviDQv9C+0LzQtdC9?= =?UTF-8?B?0Y/RgtGMINC70L7Qs9C40LrRgyBwcm94eV9uZXh0X3Vwc3RyZWFt?= In-Reply-To: References: Message-ID: А что происходит если идет сбой по чтению в вашем случае? Ожидание до бесконечности? 12 августа 2013 г., 14:59 пользователь Илья Шипицин написал: > Добрый день! > > мы столкнулись с ситуацией такого характера. > есть веб-приложения, которые долго отвечают, в отношении них > справедливо, что лучше запрос отправить не более одного раза > (например, это может быть разнесения платежа, на 20 фронтов платеж > разнесется 20 раз). > > с другой стороны, хотелось бы отличать "таймаут при отправке данных" > от "тайаута при чтении данных". > > в случае, если мы не можем отправить данные - нормально уйти на > следующий хост. если мы уходим в таймаут при чтении - на следующий > хост лучше не уходить, может быть массовый "расстрел" (разнесение > платежа 20 раз из 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 unera at uvw.ru Sat Aug 17 19:54:06 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Sat, 17 Aug 2013 23:54:06 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130727215440.GA7614@vdsl.uvw.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> Message-ID: <20130817195406.GA9817@vdsl.uvw.ru> > продолжаю играться с кешированием > на тестах (в том числе конкурентных, ab) все было хорошо - попробовали > под нагрузкой. > nginx 1.2.1 да видимо есть бага какая-то. причем похоже бага с обработкой 'X-Accel-Expires' прорывает кеш периодически и на бакенд идет толпища запросов. убрал в nginx возможность управлять кешом со стороны бакенда proxy_ignore_headers 'X-Accel-Expires'; и стало работать нормально: на бакенд проходит 1 запрос в секунду на nginx - 500-600. а когда управляли кешированием с бакенда, всегда выдавая X-Accel-Expires: 30 то периодически на бакенд прорывается один и тот же запрос с частотой 200-300 в секунду (при 500-600 на фронтенде) -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From lavandas at ya.ru Sun Aug 18 06:29:58 2013 From: lavandas at ya.ru (=?koi8-r?B?8tXTwc7P1yDvzMXH?=) Date: Sun, 18 Aug 2013 10:29:58 +0400 Subject: =?UTF-8?B?0JfQsNGJ0LjRgtCwINC+0YIg0YjQtdC70L7Qsg==?= Message-ID: <131871376807398@web13f.yandex.ru> An HTML attachment was scrubbed... URL: From lavandas at ya.ru Sun Aug 18 06:39:17 2013 From: lavandas at ya.ru (=?koi8-r?B?8tXTwc7P1yDvzMXH?=) Date: Sun, 18 Aug 2013 10:39:17 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <131871376807398@web13f.yandex.ru> References: <131871376807398@web13f.yandex.ru> Message-ID: <133381376807957@web13f.yandex.ru> An HTML attachment was scrubbed... URL: From corochoone at gmail.com Sun Aug 18 06:45:35 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Sun, 18 Aug 2013 10:45:35 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <131871376807398@web13f.yandex.ru> References: <131871376807398@web13f.yandex.ru> Message-ID: Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы. Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php. 18 августа 2013 г., 10:29 пользователь Русанов Олег написал: > Здравствуйте. Есть ли способ предотвратить просматривать шелом другие > сайты на виртуальном хосте? > В конфиге сайта рут - папка где index.php, а шелл показывает, что root - > это папка где все сайты находятся. > Может быть в этом дело? > > > -- > С уважением, > Олег Русанов. > > _______________________________________________ > 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 lavandas at ya.ru Sun Aug 18 06:58:13 2013 From: lavandas at ya.ru (=?koi8-r?B?8tXTwc7P1yDvzMXH?=) Date: Sun, 18 Aug 2013 10:58:13 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: References: <131871376807398@web13f.yandex.ru> Message-ID: <137111376809093@web13f.yandex.ru> An HTML attachment was scrubbed... URL: From artem.vasiliev at gmail.com Sun Aug 18 07:02:51 2013 From: artem.vasiliev at gmail.com (Artem Vasiliev) Date: Sun, 18 Aug 2013 00:02:51 -0700 (PDT) Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <137111376809093@web13f.yandex.ru> References: <137111376809093@web13f.yandex.ru> Message-ID: <1376809370852.805c5034@Nodemailer> Сменить хостинг ???? WBR Artem V. Vasiliev Sent from Mailbox for iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From lavandas at ya.ru Sun Aug 18 07:19:50 2013 From: lavandas at ya.ru (=?koi8-r?B?8tXTwc7P1yDvzMXH?=) Date: Sun, 18 Aug 2013 11:19:50 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <1376809370852.805c5034@Nodemailer> References: <137111376809093@web13f.yandex.ru> <1376809370852.805c5034@Nodemailer> Message-ID: <400591376810390@web24d.yandex.ru> An HTML attachment was scrubbed... URL: From lego12239 at yandex.ru Sun Aug 18 07:32:51 2013 From: lego12239 at yandex.ru (Oleg) Date: Sun, 18 Aug 2013 11:32:51 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <137111376809093@web13f.yandex.ru> References: <131871376807398@web13f.yandex.ru> <137111376809093@web13f.yandex.ru> Message-ID: <20130818073251.GA29247@localhost> Да, отруби ты уже этот html. Глаза сломать можно. On Sun, Aug 18, 2013 at 10:58:13AM +0400, Русанов Олег wrote: >
Это слишком сложно, как я это сделаю на хостинге Ру-Центра? 
 
В конфиг Апача не помогает:
<Directory /home/идентификатор/домен/docs>
php_admin_value open_basedir /home/идентификатор/домен/docs
php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp
</Directory>
может это надо как-то в конфиг Энджиникса прописать?
 
18.08.2013, 10:45, "Виктор Вислобоков" <corochoone at gmail.com>:
Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы.
Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php.


18 августа 2013 г., 10:29 пользователь Русанов Олег <lavandas at ya.ru> написал:
Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте?
В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся.
Может быть в этом дело?
 
 
--
С уважением,
Олег Русанов.

_______________________________________________
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 lavandas at ya.ru Sun Aug 18 08:44:41 2013 From: lavandas at ya.ru (=?koi8-r?B?8tXTwc7P1yDvzMXH?=) Date: Sun, 18 Aug 2013 12:44:41 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <400591376810390@web24d.yandex.ru> References: <137111376809093@web13f.yandex.ru> <1376809370852.805c5034@Nodemailer> <400591376810390@web24d.yandex.ru> Message-ID: <15801376815481@web24f.yandex.ru> На счет прав не знаю теперь, это у меня из кэша шелл грузился. оказывается, а так выше папки сайта не может выйти, если в в /home/user/etc/httpd.conf прописать. В общем работает и удобнее всего, наверное, это: в .htaccess добавить: php_value open_basedir "/home/user/1.ru/docs" 18.08.2013, 11:19, "Русанов Олег" : > > php_admin_value open_basedir /home/идентификатор/домен/docs > php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp > > > Вот это работает все-таки, только если прописывать не в /home/user/d.ru/conf/virtual.conf.manual, > а в /home/user/etc/httpd.conf > И права должны быть выключены "для других". > > а Ру-Центр неплохой хостинг, у них еще в Амстердаме площадка открылась, > так что по-моему они - лучший вариант. > > 18.08.2013, 11:03, "Artem Vasiliev" : >> Сменить хостинг >> ???? >> WBR >> Artem V. Vasiliev >> Sent from Mailbox for iPhone >> >> On Sun, Aug 18, 2013 at 10:58 AM, Русанов Олег wrote: >>> Это слишком сложно, как я это сделаю на хостинге Ру-Центра? >>> >>> В конфиг Апача не помогает: >>> >>> php_admin_value open_basedir /home/идентификатор/домен/docs >>> php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp >>> >>> может это надо как-то в конфиг Энджиникса прописать? >>> >>> 18.08.2013, 10:45, "Виктор Вислобоков" : >>>> Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы. >>>> Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php. >>>> >>>> 18 августа 2013 г., 10:29 пользователь Русанов Олег написал: >>>>> Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте? >>>>> В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся. >>>>> Может быть в этом дело? >>>>> >>>>> -- >>>>> С уважением, >>>>> Олег Русанов. >>>>> >>>>> _______________________________________________ >>>>> 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 lavandas at ya.ru Sun Aug 18 08:54:33 2013 From: lavandas at ya.ru (=?koi8-r?B?8tXTwc7P1yDvzMXH?=) Date: Sun, 18 Aug 2013 12:54:33 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <15801376815481@web24f.yandex.ru> References: <137111376809093@web13f.yandex.ru> <1376809370852.805c5034@Nodemailer> <400591376810390@web24d.yandex.ru> <15801376815481@web24f.yandex.ru> Message-ID: <548521376816073@web22h.yandex.ru> теперь, кстати, любым способом стало работать, наверное, поддержка что-то подправила. 18.08.2013, 12:44, "Русанов Олег" : > На счет прав не знаю теперь, это у меня из кэша шелл грузился. оказывается, а так выше папки сайта не может выйти, если в в /home/user/etc/httpd.conf прописать. > > В общем работает и удобнее всего, наверное, это: > в .htaccess добавить: > php_value open_basedir "/home/user/1.ru/docs" > > 18.08.2013, 11:19, "Русанов Олег" : > >>   >>  php_admin_value open_basedir /home/идентификатор/домен/docs >>  php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp >>   >> >>  Вот это работает все-таки, только если прописывать не в /home/user/d.ru/conf/virtual.conf.manual, >>  а в /home/user/etc/httpd.conf >>  И права должны быть выключены "для других". >> >>  а Ру-Центр неплохой хостинг, у них еще в Амстердаме площадка открылась, >>  так что по-моему они - лучший вариант. >> >>  18.08.2013, 11:03, "Artem Vasiliev" : >>>  Сменить хостинг >>>  ???? >>>  WBR >>>  Artem V. Vasiliev >>>  Sent from Mailbox for iPhone >>> >>>  On Sun, Aug 18, 2013 at 10:58 AM, Русанов Олег wrote: >>>>  Это слишком сложно, как я это сделаю на хостинге Ру-Центра? >>>> >>>>  В конфиг Апача не помогает: >>>>   >>>>  php_admin_value open_basedir /home/идентификатор/домен/docs >>>>  php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp >>>>   >>>>  может это надо как-то в конфиг Энджиникса прописать? >>>> >>>>  18.08.2013, 10:45, "Виктор Вислобоков" : >>>>>  Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы. >>>>>  Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php. >>>>> >>>>>  18 августа 2013 г., 10:29 пользователь Русанов Олег написал: >>>>>>  Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте? >>>>>>  В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся. >>>>>>  Может быть в этом дело? >>>>>> >>>>>>  -- >>>>>>  С уважением, >>>>>>  Олег Русанов. >>>>>> >>>>>>  _______________________________________________ >>>>>>  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 > > -- > С уважением, > Олег Русанов. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Олег Русанов. From vlad.shabanov at gmail.com Sun Aug 18 09:34:03 2013 From: vlad.shabanov at gmail.com (Vladislav Shabanov) Date: Sun, 18 Aug 2013 13:34:03 +0400 Subject: =?UTF-8?B?0L7QtNC90L7RgNCw0LfQvtCy0YvQtSDQv9Cw0YDQvtC70Lgg0LIgYmFzaWMgYXV0?= =?UTF-8?B?aGVudGljYXRpb24=?= Message-ID: <7107B311-2567-4AD7-BACA-3D39EA73310B@gmail.com> Добрый день. Подскажите, пож-ста, есть ли какое-нибудь готовое решение для аутентификации одноразовыми паролями в nginX. Предполагается использовать что-то наподобие вот этого: http://www.aladdin-rd.ru/catalog/etoken/pass/ Есть готовое решение для Apache (mod_authn_otp), но переходить на Apache 2.x не хочется. Встраивать проверку непосредственно в приложения совсем не хочется, т.к. их несколько на разных языках. Варианты, которые рассматривал: 1. готовый модуль nginX: не нашёл 2. модуль для PAM: нашёл, но непонятно как кэшировать пароль на сервере так, чтобы при загрузке каждой страницы он заново не требовал нового одноразового пароля. 3. модуль для Radius: вроде как есть такой зверь где-то, но опять непонятно, может ли Radius или модуль к nginX кэшировать одноразовый пароль + IP с которого была успешная аутентификация в течение заданный интервала времени. Есть у кого-нибудь работающее решение этой задачи? С уважением, Владислав Шабанов From unera at uvw.ru Sun Aug 18 19:42:24 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Sun, 18 Aug 2013 23:42:24 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130817195406.GA9817@vdsl.uvw.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> Message-ID: <20130818194224.GC11364@vdsl.uvw.ru> >> продолжаю играться с кешированием >> на тестах (в том числе конкурентных, ab) все было хорошо - попробовали >> под нагрузкой. >> nginx 1.2.1 > да видимо есть бага какая-то. > причем похоже бага с обработкой 'X-Accel-Expires' > прорывает кеш периодически и на бакенд идет толпища запросов. > убрал в nginx возможность управлять кешом со стороны бакенда > proxy_ignore_headers 'X-Accel-Expires'; > и стало работать нормально: на бакенд проходит 1 запрос в секунду > на nginx - 500-600. > а когда управляли кешированием с бакенда, всегда выдавая > X-Accel-Expires: 30 > то периодически на бакенд прорывается один и тот же запрос с частотой > 200-300 в секунду (при 500-600 на фронтенде) да, в 1.2.1 прорывается кеш и в случае использования Accel-Expires тега и в случае его неиспользования. сапгрейдил nginx до 1.4. смотрим, ждем. видимо надо свое кеширование писать, раз даже в nginx не могут его запилить чтобы работало :( -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From postmaster at softsearch.ru Sun Aug 18 20:49:28 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 19 Aug 2013 00:49:28 +0400 Subject: =?UTF-8?B?UmVbMl06IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <20130817025412.GA2130@mdounin.ru> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> <246767059.20130810234331@softsearch.ru> <20130817025412.GA2130@mdounin.ru> Message-ID: <1416126954.20130819004928@softsearch.ru> Здравствуйте, Maxim. >> >> set на уровне http был бы очень удобен порой. Обходить это через >> >> map 1 $var { >> >> default "value"; >> >> } >> >> неудобно. >> >> > http://nginx.org/en/docs/faq/variables_in_config.html >> >> Признаюсь, что не въехал в ответ по ссылке. Все слова знакомые, а >> собранные вместе смысл никакой в моей голове не приобретают. Тупею, >> видимо. :-) >> >> Опишу задачу. Мне надо было как-то писать в аксес-лог кэш-зону, чтобы >> потом по логам считать эффективность каждой кэш-зоны. Встроенную >> переменную я не знаю, поэтому решил создать переменную через set. Там, >> где запросы проксируются, я присваивал через set соответствующей >> переменной значение, равное имени кэшзоны. Но не все запросы >> проксируются и в логе вместо значения переменной пишется пустая >> строка, что неудобно для парсинга лога. Брать переменную в кавычки >> тоже неудобно. >> >> Для таких запросов я хотел присвоить этой переменной дефолтное >> значение "-". Писать в каждом блоке server{} set или include посчитал >> лишним и вставил в http{} вот такие строчки: >> >> # set нельзя делать на уровне http, поэтому делаем присваивание через map >> map 1 $cache_zone_for_logging { >> default "-"; >> } >> >> Т.е. я хотел использовать set для инициализации переменной, которая >> потом может меняться. >> >> На мой примитивный взгляд кажется нелогичным иметь иерархию блоков >> конфига, иметь наследование с вышестоящих уровней иерархии и разрешать >> set-у работать на уровне http{}. > Всмысле - _не_ разрешать? Да. Ошибся. > Проблема состоит в том, что set - это директива модуля rewrite, > которая не наследуется, выполняется вместе с остальными директивами > в rewrite-фазе и т.п. Это всё тонкости реализации не ясные 99% процентам пользователей nginx-а. Ну вынесите её в отдельный модуль mod_set или ещё как-то проблему наверняка можно исправить. > Вводить директиву set на уровне http с совершенно другой семантикой > - это не очень хорошая идея. Зачем другая семантика. Оставить всё как есть, только дать возможность писать в конфиге set на уровне http{}. Это удобно, логично, упрощает конфиг, избавляет от копипасты. Во всяком случае мне так видится. Хотя судя по активности в треде это больше никому не надо. Так что можете забить, если реально много писать, тестировать и многое поломается. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Sun Aug 18 20:59:46 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 19 Aug 2013 00:59:46 +0400 Subject: =?UTF-8?B?UmU6INC+0LTQvdC+0YDQsNC30L7QstGL0LUg0L/QsNGA0L7Qu9C4INCyIGJhc2lj?= =?UTF-8?B?IGF1dGhlbnRpY2F0aW9u?= In-Reply-To: <7107B311-2567-4AD7-BACA-3D39EA73310B@gmail.com> References: <7107B311-2567-4AD7-BACA-3D39EA73310B@gmail.com> Message-ID: <20130818205945.GD76786@mdounin.ru> Hello! On Sun, Aug 18, 2013 at 01:34:03PM +0400, Vladislav Shabanov wrote: > Добрый день. > > Подскажите, пож-ста, есть ли какое-нибудь готовое решение для аутентификации одноразовыми > паролями в nginX. Предполагается использовать что-то наподобие вот этого: > http://www.aladdin-rd.ru/catalog/etoken/pass/ > > Есть готовое решение для Apache (mod_authn_otp), но переходить на Apache 2.x не хочется. > Встраивать проверку непосредственно в приложения совсем не хочется, т.к. их несколько на > разных языках. > > Варианты, которые рассматривал: > > 1. готовый модуль nginX: не нашёл > > 2. модуль для PAM: нашёл, но непонятно как кэшировать пароль на сервере так, чтобы > при загрузке каждой страницы он заново не требовал нового одноразового пароля. > > 3. модуль для Radius: вроде как есть такой зверь где-то, но опять непонятно, может ли > Radius или модуль к nginX кэшировать одноразовый пароль + IP с которого была успешная > аутентификация в течение заданный интервала времени. > > Есть у кого-нибудь работающее решение этой задачи? Из банальных решений - взять auth request[1], и написать бекенд и/или использовать Apache с нужными модулями в роли такового. [1] http://mdounin.ru/hg/ngx_http_auth_request_module -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Sun Aug 18 21:10:19 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 19 Aug 2013 01:10:19 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130818194224.GC11364@vdsl.uvw.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> Message-ID: <20130818211019.GE76786@mdounin.ru> Hello! On Sun, Aug 18, 2013 at 11:42:24PM +0400, Dmitry E. Oboukhov wrote: > >> продолжаю играться с кешированием > >> на тестах (в том числе конкурентных, ab) все было хорошо - попробовали > >> под нагрузкой. > > >> nginx 1.2.1 > > > да видимо есть бага какая-то. > > причем похоже бага с обработкой 'X-Accel-Expires' > > > прорывает кеш периодически и на бакенд идет толпища запросов. > > > убрал в nginx возможность управлять кешом со стороны бакенда > > > proxy_ignore_headers 'X-Accel-Expires'; > > > и стало работать нормально: на бакенд проходит 1 запрос в секунду > > на nginx - 500-600. > > > а когда управляли кешированием с бакенда, всегда выдавая > > X-Accel-Expires: 30 > > > то периодически на бакенд прорывается один и тот же запрос с частотой > > 200-300 в секунду (при 500-600 на фронтенде) > > да, в 1.2.1 прорывается кеш и в случае использования Accel-Expires > тега и в случае его неиспользования. > > сапгрейдил nginx до 1.4. смотрим, ждем. > > видимо надо свое кеширование писать, раз даже в nginx не могут его > запилить чтобы работало :( Сторонние модули выпилили, или как в прошлый раз? Ждать, что кеширование будет работать, если в логах вполне однозначно написано, что из-за стороннего модуля cache manger умер - несколько наивно. -- Maxim Dounin http://nginx.org/en/donation.html From corochoone at gmail.com Mon Aug 19 05:48:17 2013 From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Mon, 19 Aug 2013 09:48:17 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRidC40YLQsCDQvtGCINGI0LXQu9C+0LI=?= In-Reply-To: <15801376815481@web24f.yandex.ru> References: <137111376809093@web13f.yandex.ru> <1376809370852.805c5034@Nodemailer> <400591376810390@web24d.yandex.ru> <15801376815481@web24f.yandex.ru> Message-ID: > php_value open_basedir "/home/user/1.ru/docs" такое спасает только от PHP. Но если запустить perl или ещё чего - проблема остаётся, потому что на них ограничения PHP не распространяются. Так что правильное решение - это разделение прав доступа по сайтам - всё остальное лишь полумеры 18 августа 2013 г., 12:44 пользователь Русанов Олег написал: > На счет прав не знаю теперь, это у меня из кэша шелл грузился. > оказывается, а так выше папки сайта не может выйти, если в > в /home/user/etc/httpd.conf прописать. > > В общем работает и удобнее всего, наверное, это: > в .htaccess добавить: > php_value open_basedir "/home/user/1.ru/docs" > > > > 18.08.2013, 11:19, "Русанов Олег" : > > > > php_admin_value open_basedir /home/идентификатор/домен/docs > > php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp > > > > > > Вот это работает все-таки, только если прописывать не в /home/user/ > d.ru/conf/virtual.conf.manual, > > а в /home/user/etc/httpd.conf > > И права должны быть выключены "для других". > > > > а Ру-Центр неплохой хостинг, у них еще в Амстердаме площадка открылась, > > так что по-моему они - лучший вариант. > > > > 18.08.2013, 11:03, "Artem Vasiliev" : > >> Сменить хостинг > >> -------- > >> WBR > >> Artem V. Vasiliev > >> Sent from Mailbox for iPhone > >> > >> On Sun, Aug 18, 2013 at 10:58 AM, Русанов Олег wrote: > >>> Это слишком сложно, как я это сделаю на хостинге Ру-Центра? > >>> > >>> В конфиг Апача не помогает: > >>> > >>> php_admin_value open_basedir /home/идентификатор/домен/docs > >>> php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp > >>> > >>> может это надо как-то в конфиг Энджиникса прописать? > >>> > >>> 18.08.2013, 10:45, "Виктор Вислобоков" : > >>>> Вам нужно добиться, чтобы php-скрипты запускались с правами > пользователя, которому принадлежит сайт. На остальные сайты соответственно > поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы > они могли читать файлы. > >>>> Как добиться? Разные способы есть. Например использование вместо > mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к > апачу типа mod_suid, mod_ruid которые работают совместно с mod_php. > >>>> > >>>> 18 августа 2013 г., 10:29 пользователь Русанов Олег > написал: > >>>>> Здравствуйте. Есть ли способ предотвратить просматривать шелом > другие сайты на виртуальном хосте? > >>>>> В конфиге сайта рут - папка где index.php, а шелл показывает, что > root - это папка где все сайты находятся. > >>>>> Может быть в этом дело? > >>>>> > >>>>> -- > >>>>> С уважением, > >>>>> Олег Русанов. > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > > > -- > С уважением, > Олег Русанов. > > _______________________________________________ > 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 unera at uvw.ru Mon Aug 19 06:44:24 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Mon, 19 Aug 2013 10:44:24 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130818211019.GE76786@mdounin.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> Message-ID: <20130819064424.GB12343@vdsl.uvw.ru> >> >> да, в 1.2.1 прорывается кеш и в случае использования Accel-Expires >> тега и в случае его неиспользования. >> >> сапгрейдил nginx до 1.4. смотрим, ждем. >> >> видимо надо свое кеширование писать, раз даже в nginx не могут его >> запилить чтобы работало :( > Сторонние модули выпилили, или как в прошлый раз? > Ждать, что кеширование будет работать, если в логах вполне > однозначно написано, что из-за стороннего модуля cache manger > умер - несколько наивно. я писал же: когда поставил nginx-лайт 1.2.1 (тот который без сторонних модулей), то ситуация улучшилась настолько что мне даже показалось что проблема решена. кешменеджер запустился, НИ ОДНОЙ ошибки в логах nginx нет. все хорошо. потом... бац! на хосте нагрузка ~15-20. смотрим в чем дело - апач все поел. смотрим на чем - на закешированных запросах: GET /cached/бла/1234 рестартуем nginx - нагрузка падает. потом в самый наплыв пользователей опять... бац: кеш прорвало. благо что с нагрузкой на хосте 15-20 апач справляется и без кеша. сайт тупит конечно, но работает. а когда кеш живой, то нагрузка 0.8-1. сейчас поставил nginx-лайт 1.4 (Debian/wheezy).. вчерашний пик пользователей пережили вроде без прорыва кеша. но правда и 1.2.1 его прорывал тоже не каждый раз. и самое интересное что когда прорывает кеш в логе ну ни записи. просто пришла 1000 запросов. и апач бы должен был выполнить один, а ему достается 600 из этой тысячи. -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From gmm at csdoc.com Mon Aug 19 09:21:37 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 19 Aug 2013 12:21:37 +0300 Subject: =?UTF-8?B?UmU6INC+0LTQvdC+0YDQsNC30L7QstGL0LUg0L/QsNGA0L7Qu9C4INCyIGJhc2lj?= =?UTF-8?B?IGF1dGhlbnRpY2F0aW9u?= In-Reply-To: <20130818205945.GD76786@mdounin.ru> References: <7107B311-2567-4AD7-BACA-3D39EA73310B@gmail.com> <20130818205945.GD76786@mdounin.ru> Message-ID: <5211E3A1.4020809@csdoc.com> On 18.08.2013 23:59, Maxim Dounin wrote: > Из банальных решений - взять auth request[1] > > [1] http://mdounin.ru/hg/ngx_http_auth_request_module если качество этого модуля высокое, там несколько лет ничего не менялось и все отлично работает - может быть имеет смысл внести этот модуль в состав nginx open core? потому что сейчас - это "сторонний модуль", со всеми вытекающими отсюда последствиями: On 19.08.2013 0:10, Maxim Dounin wrote: > Сторонние модули выпилили, или как в прошлый раз? -- Best regards, Gena From gmm at csdoc.com Mon Aug 19 09:44:41 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 19 Aug 2013 12:44:41 +0300 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130819064424.GB12343@vdsl.uvw.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> Message-ID: <5211E909.2030702@csdoc.com> On 19.08.2013 9:44, Dmitry E. Oboukhov wrote: > кешменеджер запустился, НИ ОДНОЙ ошибки в логах nginx нет. все хорошо. > потом... бац! на хосте нагрузка ~15-20. > смотрим в чем дело - апач все поел. > смотрим на чем - на закешированных запросах: GET /cached/бла/1234 > > рестартуем nginx - нагрузка падает. потом в самый наплыв пользователей > опять... бац: кеш прорвало. > > благо что с нагрузкой на хосте 15-20 апач справляется и без кеша. > сайт тупит конечно, но работает. > > а когда кеш живой, то нагрузка 0.8-1. > > сейчас поставил nginx-лайт 1.4 (Debian/wheezy).. вчерашний пик > пользователей пережили вроде без прорыва кеша. > но правда и 1.2.1 его прорывал тоже не каждый раз. > > и самое интересное что когда прорывает кеш в логе ну ни записи. > просто пришла 1000 запросов. и апач бы должен был выполнить один, а > ему достается 600 из этой тысячи. кроме proxy_cache_lock on; proxy_cache_use_stale updating; есть еще директива proxy_cache_lock_timeout и по умолчанию там: proxy_cache_lock_timeout 5s; не может быть такой ситуации, что когда "самый наплыв пользователей" backend не успевает ответить за 5 секунд? в документации совсем не написано как себя в такой ситуации поведет nginx, возможно он тогда отпускает все клиентские запросы backend ? P.S. если взять nginx с сайта http://nginx.org/en/download.html - этот глюк воспроизводится? если нет - проблема очевидно где. -- Best regards, Gena From gmm at csdoc.com Mon Aug 19 10:15:44 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 19 Aug 2013 13:15:44 +0300 Subject: =?UTF-8?B?UmU6IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <1416126954.20130819004928@softsearch.ru> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> <246767059.20130810234331@softsearch.ru> <20130817025412.GA2130@mdounin.ru> <1416126954.20130819004928@softsearch.ru> Message-ID: <5211F050.7060501@csdoc.com> On 18.08.2013 23:49, Михаил Монашёв wrote: >>> Опишу задачу. Мне надо было как-то писать в аксес-лог кэш-зону, чтобы >>> потом по логам считать эффективность каждой кэш-зоны. Встроенную >>> переменную я не знаю, поэтому решил создать переменную через set. Там, >>> где запросы проксируются, я присваивал через set соответствующей >>> переменной значение, равное имени кэшзоны. Но не все запросы >>> проксируются и в логе вместо значения переменной пишется пустая >>> строка, что неудобно для парсинга лога. Брать переменную в кавычки >>> тоже неудобно. для этих целей - проще всего было бы создать встроенную переменную с дефолтовым значением "-". или, если значение какой-то (любой) переменной не определено - писать в лог ее значение в виде "". >>> Для таких запросов я хотел присвоить этой переменной дефолтное >>> значение "-". Писать в каждом блоке server{} set или include посчитал >>> лишним и вставил в http{} вот такие строчки: >>> >>> # set нельзя делать на уровне http, поэтому делаем присваивание через map >>> map 1 $cache_zone_for_logging { >>> default "-"; >>> } >>> >>> Т.е. я хотел использовать set для инициализации переменной, которая >>> потом может меняться. >>> >>> На мой примитивный взгляд кажется нелогичным иметь иерархию блоков >>> конфига, иметь наследование с вышестоящих уровней иерархии и разрешать >>> set-у работать на уровне http{}. если "присваивание через map" работает - то это нормальный workaround. то есть, сейчас это ситуация "нельзя, но если очень хочется, то можно". >> Вводить директиву set на уровне http с совершенно другой семантикой >> - это не очень хорошая идея. > Зачем другая семантика. Оставить всё как есть, только дать возможность > писать в конфиге set на уровне http{}. Это удобно, логично, упрощает > конфиг, избавляет от копипасты. если будут включены set на уровне http - их активно начнут использовать "...as macros for making parts of configuration work as templates". -- Best regards, Gena From mdounin at mdounin.ru Mon Aug 19 10:52:35 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 19 Aug 2013 14:52:35 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <5211E909.2030702@csdoc.com> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> Message-ID: <20130819105235.GB705@mdounin.ru> Hello! On Mon, Aug 19, 2013 at 12:44:41PM +0300, Gena Makhomed wrote: > On 19.08.2013 9:44, Dmitry E. Oboukhov wrote: > > >кешменеджер запустился, НИ ОДНОЙ ошибки в логах nginx нет. все хорошо. > >потом... бац! на хосте нагрузка ~15-20. > >смотрим в чем дело - апач все поел. > >смотрим на чем - на закешированных запросах: GET /cached/бла/1234 > > > >рестартуем nginx - нагрузка падает. потом в самый наплыв пользователей > >опять... бац: кеш прорвало. > > > >благо что с нагрузкой на хосте 15-20 апач справляется и без кеша. > >сайт тупит конечно, но работает. > > > >а когда кеш живой, то нагрузка 0.8-1. > > > >сейчас поставил nginx-лайт 1.4 (Debian/wheezy).. вчерашний пик > >пользователей пережили вроде без прорыва кеша. > >но правда и 1.2.1 его прорывал тоже не каждый раз. > > > >и самое интересное что когда прорывает кеш в логе ну ни записи. > >просто пришла 1000 запросов. и апач бы должен был выполнить один, а > >ему достается 600 из этой тысячи. > > кроме > > proxy_cache_lock on; > proxy_cache_use_stale updating; > > есть еще директива proxy_cache_lock_timeout и по умолчанию там: > > proxy_cache_lock_timeout 5s; > > не может быть такой ситуации, что когда "самый наплыв пользователей" > backend не успевает ответить за 5 секунд? +1 Это штатный вариант, когда запросы к одному и тому же ресурсу могут попасть на бекенд в больших количествах при используемых настройках. > в документации совсем не написано как себя в такой ситуации поведет > nginx, возможно он тогда отпускает все клиентские запросы backend ? Поведение документировано в описании proxy_cache_lock (http://nginx.org/r/proxy_cache_lock): : Other requests of the same cache element will either wait for a : response to appear in the cache or the cache lock for this element : to be released, up to the time set by the proxy_cache_lock_timeout : directive. После истечения времени, заданного директивой proxy_cache_lock_timeout, запросы, очевидно, перестанут ожидать cache lock'а. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Mon Aug 19 11:03:44 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 19 Aug 2013 15:03:44 +0400 Subject: =?UTF-8?B?UmU6INC+0LTQvdC+0YDQsNC30L7QstGL0LUg0L/QsNGA0L7Qu9C4INCyIGJhc2lj?= =?UTF-8?B?IGF1dGhlbnRpY2F0aW9u?= In-Reply-To: <5211E3A1.4020809@csdoc.com> References: <7107B311-2567-4AD7-BACA-3D39EA73310B@gmail.com> <20130818205945.GD76786@mdounin.ru> <5211E3A1.4020809@csdoc.com> Message-ID: <20130819110344.GD705@mdounin.ru> Hello! On Mon, Aug 19, 2013 at 12:21:37PM +0300, Gena Makhomed wrote: > On 18.08.2013 23:59, Maxim Dounin wrote: > > >Из банальных решений - взять auth request[1] > > > >[1] http://mdounin.ru/hg/ngx_http_auth_request_module > > если качество этого модуля высокое, там несколько лет > ничего не менялось и все отлично работает - может быть > имеет смысл внести этот модуль в состав nginx open core? Он будет в 1.5.4. -- Maxim Dounin http://nginx.org/en/donation.html From unera at uvw.ru Mon Aug 19 11:31:11 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Mon, 19 Aug 2013 15:31:11 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <5211E909.2030702@csdoc.com> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> Message-ID: <20130819113111.GA28861@vdsl.uvw.ru> >> кешменеджер запустился, НИ ОДНОЙ ошибки в логах nginx нет. все хорошо. >> потом... бац! на хосте нагрузка ~15-20. >> смотрим в чем дело - апач все поел. >> смотрим на чем - на закешированных запросах: GET /cached/бла/1234 >> >> рестартуем nginx - нагрузка падает. потом в самый наплыв пользователей >> опять... бац: кеш прорвало. >> >> благо что с нагрузкой на хосте 15-20 апач справляется и без кеша. >> сайт тупит конечно, но работает. >> >> а когда кеш живой, то нагрузка 0.8-1. >> >> сейчас поставил nginx-лайт 1.4 (Debian/wheezy).. вчерашний пик >> пользователей пережили вроде без прорыва кеша. >> но правда и 1.2.1 его прорывал тоже не каждый раз. >> >> и самое интересное что когда прорывает кеш в логе ну ни записи. >> просто пришла 1000 запросов. и апач бы должен был выполнить один, а >> ему достается 600 из этой тысячи. > кроме > proxy_cache_lock on; > proxy_cache_use_stale updating; > есть еще директива proxy_cache_lock_timeout и по умолчанию там: > proxy_cache_lock_timeout 5s; тут у меня написано 30s. то есть когда впервые с этой ситуацией столкнулся уже стал крутить все ручки с кешом связанные. > не может быть такой ситуации, что когда "самый наплыв пользователей" > backend не успевает ответить за 5 секунд? даже когда происходит "прорыв" кеша апач укладывается в 5 секунд ответа (по логам nginx собственно это и видно). то есть апач вполне держит нагрузку и без кеша (при LA=15-20). где-то 400-500 запросов в секунду на 10 воркеров апача. то есть где-то 50 в секунду на воркер получается. > в документации совсем не написано как себя в такой ситуации поведет > nginx, возможно он тогда отпускает все клиентские запросы backend ? > P.S. > - этот глюк воспроизводится? если нет - проблема очевидно где. да на живом сайте воспроизводится с завидной регулярностью :( -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From unera at uvw.ru Mon Aug 19 11:36:15 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Mon, 19 Aug 2013 15:36:15 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130819105235.GB705@mdounin.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> <20130819105235.GB705@mdounin.ru> Message-ID: <20130819113615.GB28861@vdsl.uvw.ru> >> кроме >> >> proxy_cache_lock on; >> proxy_cache_use_stale updating; >> >> есть еще директива proxy_cache_lock_timeout и по умолчанию там: >> >> proxy_cache_lock_timeout 5s; >> >> не может быть такой ситуации, что когда "самый наплыв пользователей" >> backend не успевает ответить за 5 секунд? > +1 > Это штатный вариант, когда запросы к одному и тому же > ресурсу могут попасть на бекенд в больших количествах при > используемых настройках. а можно об этом в лог запись писать? тогда бы хоть как-то диагностировать можно было. -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mdounin at mdounin.ru Mon Aug 19 13:11:50 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 19 Aug 2013 17:11:50 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130819113615.GB28861@vdsl.uvw.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> <20130819105235.GB705@mdounin.ru> <20130819113615.GB28861@vdsl.uvw.ru> Message-ID: <20130819131149.GL705@mdounin.ru> Hello! On Mon, Aug 19, 2013 at 03:36:15PM +0400, Dmitry E. Oboukhov wrote: > >> кроме > >> > >> proxy_cache_lock on; > >> proxy_cache_use_stale updating; > >> > >> есть еще директива proxy_cache_lock_timeout и по умолчанию там: > >> > >> proxy_cache_lock_timeout 5s; > >> > >> не может быть такой ситуации, что когда "самый наплыв пользователей" > >> backend не успевает ответить за 5 секунд? > > > +1 > > > Это штатный вариант, когда запросы к одному и тому же > > ресурсу могут попасть на бекенд в больших количествах при > > используемых настройках. > > а можно об этом в лог запись писать? тогда бы хоть как-то > диагностировать можно было. Сейчас оно пишется на уровне debug. Возможно имеет смысл повысить где-нибудь до info: diff --git a/src/http/ngx_http_file_cache.c b/src/http/ngx_http_file_cache.c --- a/src/http/ngx_http_file_cache.c +++ b/src/http/ngx_http_file_cache.c @@ -445,8 +445,8 @@ ngx_http_file_cache_lock_wait_handler(ng timer = c->wait_time - ngx_current_msec; if ((ngx_msec_int_t) timer <= 0) { - ngx_log_debug0(NGX_LOG_DEBUG_HTTP, ev->log, 0, - "http file cache lock timeout"); + ngx_log_error(NGX_LOG_INFO, ev->log, 0, + "cache lock timeout"); c->lock = 0; goto wakeup; } -- Maxim Dounin http://nginx.org/en/donation.html From postmaster at softsearch.ru Mon Aug 19 14:54:09 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 19 Aug 2013 18:54:09 +0400 Subject: =?UTF-8?B?UmVbMl06IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <5211F050.7060501@csdoc.com> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> <246767059.20130810234331@softsearch.ru> <20130817025412.GA2130@mdounin.ru> <1416126954.20130819004928@softsearch.ru> <5211F050.7060501@csdoc.com> Message-ID: <845119670.20130819185409@softsearch.ru> Здравствуйте, Gena. > если будут включены set на уровне http - их активно начнут использовать > "...as macros for making parts of configuration work as templates". Мне вот это и не понятно. Как можно какие-то шаблоны в конфиге городить? Может я неверно перевожу на русский слово template, или не понимаю смысла шаблон. Поясните, пожалуйста, как делать эти шаблоны, и чем они плохи? -- С уважением, Михаил mailto:postmaster at softsearch.ru From gmm at csdoc.com Mon Aug 19 18:26:10 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 19 Aug 2013 21:26:10 +0300 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130819113111.GA28861@vdsl.uvw.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> <20130819113111.GA28861@vdsl.uvw.ru> Message-ID: <52126342.2070303@csdoc.com> On 19.08.2013 14:31, Dmitry E. Oboukhov wrote: << если взять nginx с сайта http://nginx.org/en/download.html >> - этот глюк воспроизводится? если нет - проблема очевидно где. > да на живом сайте воспроизводится с завидной регулярностью :( на какой версии воспроизводится BUG, nginx-1.4.2 или nginx-1.5.3 ? что при этом показывает результат выполнения команды nginx -V ? On 19.08.2013 9:44, Dmitry E. Oboukhov wrote: > я писал же: когда поставил nginx-лайт 1.2.1 (тот который без сторонних > модулей), то ситуация улучшилась настолько что мне даже показалось что > проблема решена. тот вариант, который идет в поставке Debian - не подходит. потому что там есть сторонние модули, даже в варианте light: Package: nginx-light THIRD PARTY MODULES: Echo -- Best regards, Gena From gmm at csdoc.com Mon Aug 19 19:23:12 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 19 Aug 2013 22:23:12 +0300 Subject: =?UTF-8?B?UmU6IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <845119670.20130819185409@softsearch.ru> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> <246767059.20130810234331@softsearch.ru> <20130817025412.GA2130@mdounin.ru> <1416126954.20130819004928@softsearch.ru> <5211F050.7060501@csdoc.com> <845119670.20130819185409@softsearch.ru> Message-ID: <521270A0.6020400@csdoc.com> On 19.08.2013 17:54, Михаил Монашёв wrote: >> если будут включены set на уровне http - их активно начнут использовать >> "...as macros for making parts of configuration work as templates". > Мне вот это и не понятно. Как можно какие-то шаблоны в конфиге > городить? Может я неверно перевожу на русский слово template, или не > понимаю смысла шаблон. Поясните, пожалуйста, как делать эти шаблоны, и > чем они плохи? [...] Variables are evaluated in the run-time during the processing of each request, so they are rather costly compared to plain static configuration. Using variables to store static strings is also a bad idea. и вот еще: http://mailman.nginx.org/pipermail/nginx-ru/2011-November/044461.html все-таки, сейчас есть возможность сделать "set на уровне http", просто синтаксис там такой, который изначально оптимизирован для более общего и частоиспользуемого случая "переменные, значения которых зависят от значений других переменных". -- Best regards, Gena From unera at uvw.ru Mon Aug 19 19:37:35 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Mon, 19 Aug 2013 23:37:35 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <52126342.2070303@csdoc.com> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> <20130819113111.GA28861@vdsl.uvw.ru> <52126342.2070303@csdoc.com> Message-ID: <20130819193735.GD28861@vdsl.uvw.ru> > << если взять nginx с сайта http://nginx.org/en/download.html >>> - этот глюк воспроизводится? если нет - проблема очевидно где. >> да на живом сайте воспроизводится с завидной регулярностью :( > на какой версии воспроизводится BUG, nginx-1.4.2 или nginx-1.5.3 ? > что при этом показывает результат выполнения команды nginx -V ? на версии Debian 1.2.1 а ща тоже самое на версии so:[~]$ /usr/sbin/nginx -V nginx version: nginx/1.4.1 TLS SNI support enabled configure arguments: --prefix=/usr/share/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 --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --with-pcre-jit --with-http_gzip_static_module --with-http_ssl_module --with-ipv6 --without-http_browser_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_zone_module --without-http_memcached_module --without-http_referer_module --without-http_scgi_module --without-http_split_clients_module --with-http_stub_status_module --without-http_ssi_module --without-http_userid_module --without-http_uwsgi_module --add-module=/tmp/buildd/nginx-1.4.1/debian/modules/nginx-echo > On 19.08.2013 9:44, Dmitry E. Oboukhov wrote: >> я писал же: когда поставил nginx-лайт 1.2.1 (тот который без сторонних >> модулей), то ситуация улучшилась настолько что мне даже показалось что >> проблема решена. > тот вариант, который идет в поставке Debian - не подходит. > потому что там есть сторонние модули, даже в варианте light: > Package: nginx-light > THIRD PARTY MODULES: Echo этот модуль может влиять на прорыв кеша? я попробую конечно пересобрать... хм -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From unera at uvw.ru Mon Aug 19 19:51:35 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Mon, 19 Aug 2013 23:51:35 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130819131149.GL705@mdounin.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> <20130819105235.GB705@mdounin.ru> <20130819113615.GB28861@vdsl.uvw.ru> <20130819131149.GL705@mdounin.ru> Message-ID: <20130819195135.GE28861@vdsl.uvw.ru> >>>> кроме >>>> >>>> proxy_cache_lock on; >>>> proxy_cache_use_stale updating; >>>> >>>> есть еще директива proxy_cache_lock_timeout и по умолчанию там: >>>> >>>> proxy_cache_lock_timeout 5s; >>>> >>>> не может быть такой ситуации, что когда "самый наплыв пользователей" >>>> backend не успевает ответить за 5 секунд? >> >>> +1 >> >>> Это штатный вариант, когда запросы к одному и тому же >>> ресурсу могут попасть на бекенд в больших количествах при >>> используемых настройках. >> >> а можно об этом в лог запись писать? тогда бы хоть как-то >> диагностировать можно было. > Сейчас оно пишется на уровне debug. > Возможно имеет смысл повысить где-нибудь до info: > diff --git a/src/http/ngx_http_file_cache.c b/src/http/ngx_http_file_cache.c > --- a/src/http/ngx_http_file_cache.c > +++ b/src/http/ngx_http_file_cache.c > @@ -445,8 +445,8 @@ ngx_http_file_cache_lock_wait_handler(ng > timer = c->wait_time - ngx_current_msec; > if ((ngx_msec_int_t) timer <= 0) { > - ngx_log_debug0(NGX_LOG_DEBUG_HTTP, ev->log, 0, > - "http file cache lock timeout"); > + ngx_log_error(NGX_LOG_INFO, ev->log, 0, > + "cache lock timeout"); c->> lock = 0; > goto wakeup; > } я сделал proxy_cache_lock_timeout равным 300 секунд больше времени 504 ошибки в 5 раз. все равно кеш прорывается. причем в момент прорыва кеша сквозь него идут отнюдь не все одинаковые запросы, а запросы с разными ID то есть /cached/order/123 /cached/order/124 /cached/order/123 /cached/order/125 итп то есть прогрепать в nginx /order/125 и в apache тот же урл будет соотношение 2:1. то есть где-то половина проходит сквозь кеш. и прорывается кеш через время работы под нагрузкой меньшее нежели 300 секунд. таким образом проблема не в локтаймауте. ну допустим один запрос бы втупил, ну два. но десятки/сотни разных запросов, при том что апач забрав весь CPU контент отдает (nginx в логах ни одной 504 не показывает) с той скоростью с какой клиенты спрашивают. -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From postmaster at softsearch.ru Tue Aug 20 03:43:21 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 20 Aug 2013 07:43:21 +0400 Subject: =?UTF-8?B?UmVbMl06IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <521270A0.6020400@csdoc.com> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> <246767059.20130810234331@softsearch.ru> <20130817025412.GA2130@mdounin.ru> <1416126954.20130819004928@softsearch.ru> <5211F050.7060501@csdoc.com> <845119670.20130819185409@softsearch.ru> <521270A0.6020400@csdoc.com> Message-ID: <189518160.20130820074321@softsearch.ru> Здравствуйте, Gena. > [...] Variables are evaluated in the run-time during the processing > of each request, so they are rather costly compared to plain static > configuration. Using variables to store static strings > is also a bad idea. Ага, сравнивать строки - это плохо, ибо долго. Но ведь map, с помощью которого приходится выкручиваться, ещё дольше! -- С уважением, Михаил mailto:postmaster at softsearch.ru From chipitsine at gmail.com Tue Aug 20 05:15:46 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 20 Aug 2013 11:15:46 +0600 Subject: =?UTF-8?B?UmU6INCx0LDQsyBTUERZ?= In-Reply-To: <201308152311.27740.vbart@nginx.com> References: <201308152311.27740.vbart@nginx.com> Message-ID: ответили пацаны из САМОГО Гугла! http://code.google.com/p/chromium/issues/detail?id=272734 As said in the nginx bug, headers with empty values are allowed in SPDY/3, but not SPDY/2. Chrome currently lets those through regardless of version -- I don't think it's worth the effort to put in the per-version filtering, especially as SPDY/2 is on its way out. 16 августа 2013 г., 1:11 пользователь Валентин Бартенев написал: > On Wednesday 14 August 2013 21:32:13 Илья Шипицин wrote: >> http://trac.nginx.org/nginx/ticket/385 > > Никакого отношения к проблеме не имеет. > > P.S. Патч закоммичен. > > -- > Валентин Бартенев > 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 Tue Aug 20 05:55:19 2013 From: nginx-forum at nginx.us (daevy) Date: Tue, 20 Aug 2013 01:55:19 -0400 Subject: =?UTF-8?B?0LLRi9Cx0L7RgCDQsdGN0LrQtdC90LTQsCDQsiDQt9Cw0LLQuNGB0LjQvNC+0YE=?= =?UTF-8?B?0YLQuCDQvtGCIEhvc3Q6INC30LDQs9C+0LvQvtCy0LrQsA==?= Message-ID: Всем привет! подскажите как реализовать следующую конфигурацию: есть три upstream: upstream node01 { server 127.0.0.1:5001; } upstream node02 { server 127.0.0.1:5002; } upstream all_servers { server 127.0.0.1:5001; server 127.0.0.1:5002; } хочется настроить 1. при поступлении запросов с $host ~ node01.server.tld отправлять в upstream node01 2. при поступлении запросов с $host ~ node02.server.tld отправлять в upstream node02 3. при поступлении запроса с $host ~ (.*).server.tld отправлять в all_servers алгоритм примерно представляю, но увы не хватает знаний в предметной области. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242040,242040#msg-242040 From nginx-forum at nginx.us Tue Aug 20 06:06:24 2013 From: nginx-forum at nginx.us (daevy) Date: Tue, 20 Aug 2013 02:06:24 -0400 Subject: =?UTF-8?B?UmU6INCy0YvQsdC+0YAg0LHRjdC60LXQvdC00LAg0LIg0LfQsNCy0LjRgdC40Lw=?= =?UTF-8?B?0L7RgdGC0Lgg0L7RgiBIb3N0OiDQt9Cw0LPQvtC70L7QstC60LA=?= In-Reply-To: References: Message-ID: <8a4f96e4ae6f89835319c442984fff88.NginxMailingListRussian@forum.nginx.org> эх поторопился я... решение то простое совсем server { listen 80; server_name node01.server.tld; location / { include /etc/nginx/proxy_headers.conf; proxy_pass http://node01; } } server { listen 80; server_name node02.server.tld; location / { include /etc/nginx/proxy_headers.conf; proxy_pass http://node02; } } server { listen 80; server_name *.server.tld; location / { include /etc/nginx/proxy_headers.conf; proxy_pass http://all_servers; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242040,242041#msg-242041 From mdounin at mdounin.ru Tue Aug 20 10:16:46 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 20 Aug 2013 14:16:46 +0400 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L/RgNC+0LHQu9C10LzQsDog0L8=?= =?UTF-8?B?0LXRgNC10YHRgtCw0LXRgiDQutC10YjQuNGA0L7QstCw0YLRjA==?= In-Reply-To: <20130819195135.GE28861@vdsl.uvw.ru> References: <20130727215440.GA7614@vdsl.uvw.ru> <20130817195406.GA9817@vdsl.uvw.ru> <20130818194224.GC11364@vdsl.uvw.ru> <20130818211019.GE76786@mdounin.ru> <20130819064424.GB12343@vdsl.uvw.ru> <5211E909.2030702@csdoc.com> <20130819105235.GB705@mdounin.ru> <20130819113615.GB28861@vdsl.uvw.ru> <20130819131149.GL705@mdounin.ru> <20130819195135.GE28861@vdsl.uvw.ru> Message-ID: <20130820101646.GA19334@mdounin.ru> Hello! On Mon, Aug 19, 2013 at 11:51:35PM +0400, Dmitry E. Oboukhov wrote: [...] > я сделал proxy_cache_lock_timeout равным 300 секунд > больше времени 504 ошибки в 5 раз. > > все равно кеш прорывается. > причем в момент прорыва кеша сквозь него идут отнюдь не все одинаковые > запросы, а запросы с разными ID > > то есть > /cached/order/123 > /cached/order/124 > /cached/order/123 > /cached/order/125 > итп > > то есть прогрепать в nginx /order/125 и в apache тот же урл будет > соотношение 2:1. то есть где-то половина проходит сквозь кеш. > > > и прорывается кеш через время работы под нагрузкой меньшее нежели 300 > секунд. таким образом проблема не в локтаймауте. > > ну допустим один запрос бы втупил, ну два. > но десятки/сотни разных запросов, при том что апач забрав весь CPU > контент отдает (nginx в логах ни одной 504 не показывает) с той > скоростью с какой клиенты спрашивают. Включите уже логгирование хотя бы $upstream_cache_status + $upstream_addr + $upstream_status + $upstream_response_time + $request_time, и покажите логи. В идеале - ещё и debug log, показывающий хотя бы несколько одинаковых запросов целиком, и всё между ними. Ну в очередной раз напоминаю, свежий nginx без сторонних модулей - крайне рекомендуемый первый шаг любых разбирательств с любыми проблемами. Берут тут: http://nginx.org/ru/download.html -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Aug 20 13:07:51 2013 From: nginx-forum at nginx.us (skeletor) Date: Tue, 20 Aug 2013 09:07:51 -0400 Subject: =?UTF-8?B?UmU6INC40YHQutC70Y7Rh9C10L3QuNC1INCyIGF1dGggYmFzaWM=?= In-Reply-To: <402cd5944fac2352744ced1b99c1f99c.NginxMailingListRussian@forum.nginx.org> References: <2ac20730563ee1e52a01aacddc5bb959.NginxMailingListRussian@forum.nginx.org> <402cd5944fac2352744ced1b99c1f99c.NginxMailingListRussian@forum.nginx.org> Message-ID: <67ccbeeef067557955ebfa78d5dd610e.NginxMailingListRussian@forum.nginx.org> Странно, но не работает. nginx 1.2.0. Вот выдержка из конфига server{ listen *:80; listen *:443 default ssl; server_name domain.com access_log off; ssl on; ssl_certificate /etc/nginx/ssl2011.crt; ssl_certificate_key /etc/nginx/ssl2011.key; root /opt/www; satisfy any; allow 10.10.10.10; allow 127.0.0.1; deny all; auth_basic "closed site"; auth_basic_user_file /usr/local/.htpasswd; ... Захожу с хоста 10.10.10.10 и всё равно выдаёт окно аутентификации. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,241923,242049#msg-242049 From nginx-forum at nginx.us Wed Aug 21 07:46:52 2013 From: nginx-forum at nginx.us (prokhorov.64) Date: Wed, 21 Aug 2013 03:46:52 -0400 Subject: =?UTF-8?B?0JLQu9C40Y/QvdC40LUgbWVtY2FjaGVkINC90LAg0LrRjdGI0LjRgNC+0LLQsNC9?= =?UTF-8?B?0LjQtQ==?= Message-ID: При использовании memcached пользователь получает 200, хотя должно возвращать 304. Как сделать, чтобы пользователь получал 304? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242066,242066#msg-242066 From vadim.lazovskiy at gmail.com Wed Aug 21 08:10:28 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Wed, 21 Aug 2013 12:10:28 +0400 Subject: =?UTF-8?B?UmU6INCS0LvQuNGP0L3QuNC1IG1lbWNhY2hlZCDQvdCwINC60Y3RiNC40YDQvtCy?= =?UTF-8?B?0LDQvdC40LU=?= In-Reply-To: References: Message-ID: Здравствуйте. Из википедии: "304 Not Modified -- сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0." nginx не может знать изменилось ли содержимое в memcached. Видимо, поэтому 200. 21 августа 2013 г., 11:46 пользователь prokhorov.64 написал: > При использовании memcached пользователь получает 200, хотя должно > возвращать 304. Как сделать, чтобы пользователь получал 304? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,242066,242066#msg-242066 > > _______________________________________________ > 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 nginx-forum at nginx.us Wed Aug 21 08:51:04 2013 From: nginx-forum at nginx.us (prokhorov.64) Date: Wed, 21 Aug 2013 04:51:04 -0400 Subject: =?UTF-8?B?UmU6INCS0LvQuNGP0L3QuNC1IG1lbWNhY2hlZCDQvdCwINC60Y3RiNC40YDQvtCy?= =?UTF-8?B?0LDQvdC40LU=?= In-Reply-To: References: Message-ID: Существует ли способ обойти эту проблему, отдавая 304 при использовании memcached? Вот пример конфига: location /design/image.png { expires off; add_header Last-Modified "Mon, 23 Jul 2013 09:37:21 GMT"; access_log off; set $memcached_key $uri; memcached_pass 10.0.0.15:11211; error_page 404 = @fallback_img; fastcgi_cache_valid 200 301 302 304 5m; } location @fallback_img { expires 1w; root /var/www/img; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242066,242069#msg-242069 From nginx-forum at nginx.us Wed Aug 21 11:35:48 2013 From: nginx-forum at nginx.us (pturrr) Date: Wed, 21 Aug 2013 07:35:48 -0400 Subject: =?UTF-8?B?0L/QvtC00YHRh9C10YIg0LrQvtC7LdCy0LAg0L7RiNC40LHQvtC6INC/0YDQuCA=?= =?UTF-8?B?0L7QsdGA0LDRidC10L3QuNC4INC6INCw0L/RgdGC0YDQuNC80YM=?= Message-ID: <5a2f497349268e5cffdfc08b30261b40.NginxMailingListRussian@forum.nginx.org> Добрый день. У нас есть апстрим, у которого установлены достаточно маленькие значения таймаутов. В error.log пишется, что Connection timed out while reading upstream... Это для нас нормальная ситуация. Мы озаботились тем, чтобы считать кол-во ошибок, которые попадают в лог. Берем последнюю минуту, считаем все строки, где есть Сonnection timed out и рисуем график. Когда у нас произошел таймаут к апстриму, мы отдаем пустую страничку и HTTP 200/OK error_page 500 501 502 503 504 = наш локейшен, который отдает 200ок В локейшене, который отдает 200ок у нас есть аксесс лог, в который мы пишем обращения к нему. То есть у нас есть два лога - error.log, и access.log другого локейшена, куда нжинкс перенаправляет в случае ошибки первого. Логично было бы предположить, что кол-во ошибок за секунду было бы равно кол-ву ошибок access лога того локейшена, куды мы редиректим. Но это не так. Кол-во ошибок в error.log намного больше, чем кол-во обращений к локейшену, который отдает HTTP 200. Как такое может быть? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242076,242076#msg-242076 From mdounin at mdounin.ru Wed Aug 21 11:55:37 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 21 Aug 2013 15:55:37 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YfQtdGCINC60L7Quy3QstCwINC+0YjQuNCx0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7QsdGA0LDRidC10L3QuNC4INC6INCw0L/RgdGC0YDQuNC80YM=?= In-Reply-To: <5a2f497349268e5cffdfc08b30261b40.NginxMailingListRussian@forum.nginx.org> References: <5a2f497349268e5cffdfc08b30261b40.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130821115537.GM19334@mdounin.ru> Hello! On Wed, Aug 21, 2013 at 07:35:48AM -0400, pturrr wrote: > Добрый день. > > У нас есть апстрим, у которого установлены достаточно маленькие значения > таймаутов. В error.log пишется, что Connection timed out while reading > upstream... Это для нас нормальная ситуация. Мы озаботились тем, чтобы > считать кол-во ошибок, которые попадают в лог. Берем последнюю минуту, > считаем все строки, где есть Сonnection timed out и рисуем график. > > Когда у нас произошел таймаут к апстриму, мы отдаем пустую страничку и HTTP > 200/OK > error_page 500 501 502 503 504 = наш локейшен, который отдает 200ок > > В локейшене, который отдает 200ок у нас есть аксесс лог, в который мы пишем > обращения к нему. > > То есть у нас есть два лога - error.log, и access.log другого локейшена, > куда нжинкс перенаправляет в случае ошибки первого. Логично было бы > предположить, что кол-во ошибок за секунду было бы равно кол-ву ошибок > access лога того локейшена, куды мы редиректим. Но это не так. Кол-во ошибок > в error.log намного больше, чем кол-во обращений к локейшену, который отдает > HTTP 200. > > Как такое может быть? Если ошибка происходит "while reading upstream", то заголовок и начало ответа уже ушли клиенту, и отдать ему что-то другое уже не представляется возможным. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Aug 21 12:10:12 2013 From: nginx-forum at nginx.us (pturrr) Date: Wed, 21 Aug 2013 08:10:12 -0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YfQtdGCINC60L7Quy3QstCwINC+0YjQuNCx0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7QsdGA0LDRidC10L3QuNC4INC6INCw0L/RgdGC0YDQuNC80YM=?= In-Reply-To: <20130821115537.GM19334@mdounin.ru> References: <20130821115537.GM19334@mdounin.ru> Message-ID: <971ee1358ac6afcc3e552715b8d5f740.NginxMailingListRussian@forum.nginx.org> То есть клиент получит 500ую ошибку? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242076,242080#msg-242080 From onokonem at gmail.com Wed Aug 21 12:16:17 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 21 Aug 2013 16:16:17 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YfQtdGCINC60L7Quy3QstCwINC+0YjQuNCx0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7QsdGA0LDRidC10L3QuNC4INC6INCw0L/RgdGC0YDQuNC80YM=?= In-Reply-To: <971ee1358ac6afcc3e552715b8d5f740.NginxMailingListRussian@forum.nginx.org> References: <20130821115537.GM19334@mdounin.ru> <971ee1358ac6afcc3e552715b8d5f740.NginxMailingListRussian@forum.nginx.org> Message-ID: > То есть клиент получит 500ую ошибку? Клиент УЖЕ получил 200. From nginx-forum at nginx.us Wed Aug 21 13:22:58 2013 From: nginx-forum at nginx.us (pturrr) Date: Wed, 21 Aug 2013 09:22:58 -0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YfQtdGCINC60L7Quy3QstCwINC+0YjQuNCx0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7QsdGA0LDRidC10L3QuNC4INC6INCw0L/RgdGC0YDQuNC80YM=?= In-Reply-To: References: Message-ID: <3eda898fd50e374b25179dc6c665ed2f.NginxMailingListRussian@forum.nginx.org> Не очень понятно. Независимо от результата ответа апстрима, клиент получает 200?? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242076,242082#msg-242082 From onokonem at gmail.com Wed Aug 21 14:23:46 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 21 Aug 2013 18:23:46 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YfQtdGCINC60L7Quy3QstCwINC+0YjQuNCx0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7QsdGA0LDRidC10L3QuNC4INC6INCw0L/RgdGC0YDQuNC80YM=?= In-Reply-To: <3eda898fd50e374b25179dc6c665ed2f.NginxMailingListRussian@forum.nginx.org> References: <3eda898fd50e374b25179dc6c665ed2f.NginxMailingListRussian@forum.nginx.org> Message-ID: > Не очень понятно. Независимо от результата ответа апстрима, клиент получает > 200?? Если облом происходит уже после того, как апстрим отдал заголовок с кодом 200, и, соответственно, этот заголовок уехал к клиенту - информировать клиента об этом обломе невозможно. From undying-m at yandex.ru Wed Aug 21 16:03:00 2013 From: undying-m at yandex.ru (Kron) Date: Wed, 21 Aug 2013 20:03:00 +0400 Subject: nginx + memcached + pecl-memcache compression Message-ID: <134261377100980@web1h.yandex.ru> An HTML attachment was scrubbed... URL: From vbart at nginx.com Wed Aug 21 16:29:15 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 21 Aug 2013 20:29:15 +0400 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: <134261377100980@web1h.yandex.ru> References: <134261377100980@web1h.yandex.ru> Message-ID: <201308212029.16130.vbart@nginx.com> On Wednesday 21 August 2013 20:03:00 Kron wrote: > Доброго дня! > > Быть может кто то сталкивался с похожей проблемой. > > Есть php приложение, которой складывает некоторый контент в memcached с > помощью pecl-memcache. В pecl-memcache с версии 3.0.3 появилась функция > автоматической компрессии при определенных объемах данных. Само php > приложение спокойно складывает контент в memcached и так же спокойно > считывает его, а вот при попытке забрать этот конент с помощью nginx > возникли проблемы. > Когда пытаюсь забрать данные через nginx, то получаю пустой ответ, а в > логах nginx пишется следующее: > 2013/08/21 19:08:18 [alert] 31346#0: *1 inflate() failed: 2, -3 while > sending to client, client: 10.9.105.228, server: , request: "GET > 8cf848795069f9b6df65f2e533ea442f.css HTTP/1.1", upstream: > "memcached://127.0.0.1:11299", host: "memcached:8099" > конфиг nginx: > > server { > listen 8099; > > access_log /var/log/nginx/a.memc.log; > error_log /var/log/nginx/e.memc.log; > > location / { > set $memcached_key $request_uri; > memcached_pass 127.0.0.1:11299; > memcached_gzip_flag 2; > gunzip on; > } > } > pecl-memcache сжимает данные в формате zlib (RFC1950), а nginx ожидает gzip (RFC1952). -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Aug 21 22:41:49 2013 From: nginx-forum at nginx.us (ks2) Date: Wed, 21 Aug 2013 18:41:49 -0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YfQtdGCINC60L7Quy3QstCwINC+0YjQuNCx0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7QsdGA0LDRidC10L3QuNC4INC6INCw0L/RgdGC0YDQuNC80YM=?= In-Reply-To: References: Message-ID: <1cfd551fbeaa17aecec242d008553e30.NginxMailingListRussian@forum.nginx.org> А есть ли какая-либо возможность дождаться и закешировать на стороне nginx *весь* ответ апстрима (если он небольшой, конечно) и отдавать либо целый валидный ответ, либо срабатывать на timeout и отдавать уже то, что прописано в error_page? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242076,242105#msg-242105 From undying-m at yandex.ru Thu Aug 22 05:55:18 2013 From: undying-m at yandex.ru (Kron) Date: Thu, 22 Aug 2013 09:55:18 +0400 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: <201308212029.16130.vbart@nginx.com> References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> Message-ID: <195871377150918@web5h.yandex.ru> Благодарю за ответ! Это конечно жаль. Можно ли ожидать появления в nginx модулем memcached поддержки zlib формата? 21.08.2013, 20:29, "Валентин Бартенев" : > On Wednesday 21 August 2013 20:03:00 Kron wrote: > >>  Доброго дня! >> >>  Быть может кто то сталкивался с похожей проблемой. >> >>  Есть php приложение, которой складывает некоторый контент в memcached с >>  помощью pecl-memcache. В pecl-memcache с версии 3.0.3 появилась функция >>  автоматической компрессии при определенных объемах данных. Само php >>  приложение спокойно складывает контент в memcached и так же спокойно >>  считывает его, а вот при попытке забрать этот конент с помощью nginx >>  возникли проблемы. >>  Когда пытаюсь забрать данные через nginx, то получаю пустой ответ, а в >>  логах nginx пишется следующее: >>  2013/08/21 19:08:18 [alert] 31346#0: *1 inflate() failed: 2, -3 while >>  sending to client, client: 10.9.105.228, server: , request: "GET >>  8cf848795069f9b6df65f2e533ea442f.css HTTP/1.1", upstream: >>  "memcached://127.0.0.1:11299", host: "memcached:8099" >>  конфиг nginx: >> >>  server { >>   listen  8099; >> >>   access_log /var/log/nginx/a.memc.log; >>   error_log /var/log/nginx/e.memc.log; >> >>   location / { >>   set $memcached_key $request_uri; >>   memcached_pass 127.0.0.1:11299; >>   memcached_gzip_flag 2; >>   gunzip on; >>   } >>  } > > pecl-memcache сжимает данные в формате zlib (RFC1950), > а nginx ожидает gzip (RFC1952). > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu Aug 22 10:00:38 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 22 Aug 2013 14:00:38 +0400 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: <195871377150918@web5h.yandex.ru> References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> <195871377150918@web5h.yandex.ru> Message-ID: <20130822100038.GU19334@mdounin.ru> Hello! On Thu, Aug 22, 2013 at 09:55:18AM +0400, Kron wrote: > Можно ли ожидать появления в nginx модулем memcached поддержки zlib формата? Нет. -- Maxim Dounin http://nginx.org/en/donation.html From gmm at csdoc.com Thu Aug 22 10:52:04 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 22 Aug 2013 13:52:04 +0300 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: <20130822100038.GU19334@mdounin.ru> References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> <195871377150918@web5h.yandex.ru> <20130822100038.GU19334@mdounin.ru> Message-ID: <5215ED54.9000407@csdoc.com> On 21.08.2013 19:29, Валентин Бартенев wrote: > pecl-memcache сжимает данные в формате zlib (RFC1950), > а nginx ожидает gzip (RFC1952). On 22.08.2013 13:00, Maxim Dounin wrote: >> Можно ли ожидать появления в nginx модулем memcached поддержки zlib формата? > Нет. тогда у всех остается единственный возможный вариант - сделать так, чтобы pecl-memcache научился сжимать данные в формате gzip (RFC1952). -- Best regards, Gena From nginx-forum at nginx.us Thu Aug 22 12:06:15 2013 From: nginx-forum at nginx.us (aler) Date: Thu, 22 Aug 2013 08:06:15 -0400 Subject: =?UTF-8?B?0JfQsNC60YDRi9GC0LjQtSDRgdC+0LXQtNC40L3QtdC90LjRjzogbmdpbngg0LI=?= =?UTF-8?B?0L7Qt9Cy0YDQsNGJ0LDQtdGCINCyINC30LDQs9C+0LvQvtCy0LrQtSAiQ29u?= =?UTF-8?B?bmVjdGlvbiA6IGNsb3NlIg==?= Message-ID: <80433b77465c4862606e2e77a3877a0a.NginxMailingListRussian@forum.nginx.org> Всем, привет ! Я уже поднимал данную проблему, но решил создать еще один топик с полной информацией. Итак, NGINX: nginx version: nginx/1.4.1 built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54) TLS SNI support disabled 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 --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_gzip_static_module --with-http_stub_status_module --with-http_perl_module --with-http_xslt_module --with-debug --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -m64 -mtune=generic' --with-ipv6 --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-upstream-fair --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-upload-progress-module --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/mod_zip --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx_mod_h264_streaming --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-push-stream-module --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx_upstream_hash --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-memcached-hash-pass --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/echo-nginx-module --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/ngx_http_gunzip_filter_module --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/headers-more-nginx-module Есть back-end (JBOSS) и front-end (NGINX). На nginx настроено проксирование и включен keep-alive: http{ ... keepalive_timeout 45 45; keepalive_requests 1000; ... } ... server{ ... location /our-portal/ { proxy_pass http://127.0.0.1:8080; break; error_page 404 = @404; error_page 502 = @502; error_page 504 = @504; } ... } если дергать нужный мне ресурс напрямую с back-end(JBOSS), то приходит следующий заголовок: Заголовок ответа: --------------------------------------------------------------- Accept-Ranges bytes Cache-Control no-cache Content-Type application/x-javascript; charset=UTF-8 Date Thu, 22 Aug 2013 11:46:04 GMT, Thu, 22 Aug 2013 11:46:04 GMT Server Restlet-Framework/2.0.14 Transfer-Encoding chunked Vary Accept-Charset, Accept-Encoding, Accept-Language, Accept --------------------------------------------------------------- Если делать запрос через front-end, то NGINX возвращает следующее: --------------------------------------------------------------- Cache-Control no-cache Connection close Content-Encoding gzip Content-Type application/x-javascript; charset=UTF-8 Date Thu, 22 Aug 2013 11:45:25 GMT Server nginx Vary Accept-Encoding, Accept-Charset, Accept-Encoding, Accept-Language, Accept --------------------------------------------------------------- Как видно из последнего запроса, nginx шлет ответ клиенту и не позволяет переиспользовать имеющийся коннекшн, присылая "Connection : close". Это касается всех ресурсов, которые запрашивает nginx c back-end. Если ресурс на nginx не пробрасывается на прокси или данные берутся из memcached (подключен соответсвующий модуль), то nginx исправно присылает "Connection : keep-alive". Как побороть данную проблему ? Как заставить nginx возвращать keep-alive соединения клиенту при получении данных с прокси ? Есть предположение, что он это делает, поскольку данные - динамические, и nginx не знает размер данных, отдаваемых клиенту, и для страховки запрещает переиспользовать соединение, по которому передаются данные неизвестного размера. Были мысли, чтобы nginx буферизировал данные с прокси, а потом проставлял размер ответа и возвращал keep-alive (не врядли это возможно). С другой стороны согласно документации Http-1.1 позволяет использовать keep-alive совместно с chunked. Есть какие-то мысли относительно данной проблемы ? Заранее благодарю всех, кто откликнется! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242120,242120#msg-242120 From v.v.biriukov at gmail.com Thu Aug 22 12:10:45 2013 From: v.v.biriukov at gmail.com (Viacheslav Biriukov) Date: Thu, 22 Aug 2013 16:10:45 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0YHQvtC10LTQuNC90LXQvdC40Y86IG5naW54?= =?UTF-8?B?INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCINCyINC30LDQs9C+0LvQvtCy0LrQtSAi?= =?UTF-8?B?Q29ubmVjdGlvbiA6IGNsb3NlIg==?= In-Reply-To: <80433b77465c4862606e2e77a3877a0a.NginxMailingListRussian@forum.nginx.org> References: <80433b77465c4862606e2e77a3877a0a.NginxMailingListRussian@forum.nginx.org> Message-ID: Привет, Покажите заголовки запросов. Спасибо. 22 августа 2013 г., 16:06 пользователь aler написал: > Всем, привет ! > Я уже поднимал данную проблему, но решил создать еще один топик с полной > информацией. > Итак, NGINX: > > nginx version: nginx/1.4.1 > built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54) > TLS SNI support disabled > 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 > --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_gzip_static_module --with-http_stub_status_module > --with-http_perl_module --with-http_xslt_module --with-debug --with-mail > --with-mail_ssl_module --with-cc-opt='-O2 -g -m64 -mtune=generic' > --with-ipv6 > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-upstream-fair > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-upload-progress-module > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/mod_zip > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx_mod_h264_streaming > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-push-stream-module > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx_upstream_hash > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/nginx-memcached-hash-pass > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/echo-nginx-module > > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/ngx_http_gunzip_filter_module > --add-module=/usr/src/redhat/BUILD/nginx-1.4.1/headers-more-nginx-module > > > Есть back-end (JBOSS) и front-end (NGINX). На nginx настроено проксирование > и включен keep-alive: > > http{ > ... > keepalive_timeout 45 45; > keepalive_requests 1000; > ... > } > > ... > > server{ > ... > location /our-portal/ { > proxy_pass http://127.0.0.1:8080; > break; > error_page 404 = @404; > error_page 502 = @502; > error_page 504 = @504; > } > ... > } > > если дергать нужный мне ресурс напрямую с back-end(JBOSS), то приходит > следующий заголовок: > > Заголовок ответа: > --------------------------------------------------------------- > Accept-Ranges bytes > Cache-Control no-cache > Content-Type application/x-javascript; charset=UTF-8 > Date Thu, 22 Aug 2013 11:46:04 GMT, Thu, 22 Aug 2013 > 11:46:04 > GMT > Server Restlet-Framework/2.0.14 > Transfer-Encoding chunked > Vary Accept-Charset, Accept-Encoding, Accept-Language, > Accept > --------------------------------------------------------------- > > Если делать запрос через front-end, то NGINX возвращает следующее: > --------------------------------------------------------------- > Cache-Control no-cache > Connection close > Content-Encoding gzip > Content-Type application/x-javascript; charset=UTF-8 > Date Thu, 22 Aug 2013 11:45:25 GMT > Server nginx > Vary Accept-Encoding, Accept-Charset, Accept-Encoding, > Accept-Language, Accept > --------------------------------------------------------------- > > Как видно из последнего запроса, nginx шлет ответ клиенту и не позволяет > переиспользовать имеющийся коннекшн, присылая "Connection : close". Это > касается всех ресурсов, которые запрашивает nginx c back-end. > Если ресурс на nginx не пробрасывается на прокси или данные берутся из > memcached (подключен соответсвующий модуль), то nginx исправно присылает > "Connection : keep-alive". > Как побороть данную проблему ? Как заставить nginx возвращать keep-alive > соединения клиенту при получении данных с прокси ? > > Есть предположение, что он это делает, поскольку данные - динамические, и > nginx не знает размер данных, отдаваемых клиенту, и для страховки запрещает > переиспользовать соединение, по которому передаются данные неизвестного > размера. Были мысли, чтобы nginx буферизировал данные с прокси, а потом > проставлял размер ответа и возвращал keep-alive (не врядли это возможно). С > другой стороны согласно документации Http-1.1 позволяет использовать > keep-alive совместно с chunked. > > Есть какие-то мысли относительно данной проблемы ? > Заранее благодарю всех, кто откликнется! > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,242120,242120#msg-242120 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Viacheslav Biriukov BR http://biriukov.me -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Aug 22 12:18:30 2013 From: nginx-forum at nginx.us (aler) Date: Thu, 22 Aug 2013 08:18:30 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0YHQvtC10LTQuNC90LXQvdC40Y86IG5naW54?= =?UTF-8?B?INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCINCyINC30LDQs9C+0LvQvtCy0LrQtSAi?= =?UTF-8?B?Q29ubmVjdGlvbiA6IGNsb3NlIg==?= In-Reply-To: References: Message-ID: <0d14ad23d9860e7e3d17804ae1617624.NginxMailingListRussian@forum.nginx.org> Вот заголовок запроса: Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding gzip, deflate Accept-Language ru,en-us;q=0.7,en;q=0.3 Connection keep-alive Cookie JSESSIONID=1bf89bo8v6or21m6lvgze5cbs7 Host 172.16.33.23 Referer http://172.16.33.23/portal-ng/portal.ftl?platform=pc¤tResolution=640x518&theme=NEW.CLASSIC&locale=ru_RU&useoptjs=true&canusethemes=true&speedtest=false User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242120,242122#msg-242122 From mdounin at mdounin.ru Thu Aug 22 12:21:17 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 22 Aug 2013 16:21:17 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0YHQvtC10LTQuNC90LXQvdC40Y86IG5naW54?= =?UTF-8?B?INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCINCyINC30LDQs9C+0LvQvtCy0LrQtSAi?= =?UTF-8?B?Q29ubmVjdGlvbiA6IGNsb3NlIg==?= In-Reply-To: <80433b77465c4862606e2e77a3877a0a.NginxMailingListRussian@forum.nginx.org> References: <80433b77465c4862606e2e77a3877a0a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130822122117.GY19334@mdounin.ru> Hello! On Thu, Aug 22, 2013 at 08:06:15AM -0400, aler wrote: [...] > Как видно из последнего запроса, nginx шлет ответ клиенту и не позволяет > переиспользовать имеющийся коннекшн, присылая "Connection : close". Это > касается всех ресурсов, которые запрашивает nginx c back-end. > Если ресурс на nginx не пробрасывается на прокси или данные берутся из > memcached (подключен соответсвующий модуль), то nginx исправно присылает > "Connection : keep-alive". > Как побороть данную проблему ? Как заставить nginx возвращать keep-alive > соединения клиенту при получении данных с прокси ? > > Есть предположение, что он это делает, поскольку данные - динамические, и > nginx не знает размер данных, отдаваемых клиенту, и для страховки запрещает > переиспользовать соединение, по которому передаются данные неизвестного > размера. Были мысли, чтобы nginx буферизировал данные с прокси, а потом > проставлял размер ответа и возвращал keep-alive (не врядли это возможно). С > другой стороны согласно документации Http-1.1 позволяет использовать > keep-alive совместно с chunked. Есть подозрение, что в конфиге nginx'а где-то затесалось "chunked_transfer_encoding off". http://nginx.org/r/chunked_transfer_encoding -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Aug 22 12:34:48 2013 From: nginx-forum at nginx.us (aler) Date: Thu, 22 Aug 2013 08:34:48 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0YHQvtC10LTQuNC90LXQvdC40Y86IG5naW54?= =?UTF-8?B?INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCINCyINC30LDQs9C+0LvQvtCy0LrQtSAi?= =?UTF-8?B?Q29ubmVjdGlvbiA6IGNsb3NlIg==?= In-Reply-To: <20130822122117.GY19334@mdounin.ru> References: <20130822122117.GY19334@mdounin.ru> Message-ID: Отлично ! Спасибо !!! Действительно, стояло OFF Поставил on , и всё заработало ) nginx теперь возвращает chunked и keep-alive ) Осталось понять, зачем его отключали....%) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242120,242124#msg-242124 From mdounin at mdounin.ru Thu Aug 22 13:08:20 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 22 Aug 2013 17:08:20 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0YHQvtC10LTQuNC90LXQvdC40Y86IG5naW54?= =?UTF-8?B?INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCINCyINC30LDQs9C+0LvQvtCy0LrQtSAi?= =?UTF-8?B?Q29ubmVjdGlvbiA6IGNsb3NlIg==?= In-Reply-To: References: <20130822122117.GY19334@mdounin.ru> Message-ID: <20130822130820.GZ19334@mdounin.ru> Hello! On Thu, Aug 22, 2013 at 08:34:48AM -0400, aler wrote: > Отлично ! Спасибо !!! > Действительно, стояло OFF > Поставил on , и всё заработало ) nginx теперь возвращает chunked и > keep-alive ) > Осталось понять, зачем его отключали....%) Если причина вообще была, то наверное две наиболее вероятные какие-то такие: 1) Кривой клиент, не понимающий chunked (были сигналы, что где-то в районе java-приложений такое водилось). 2) Кривой бекенд, возвращающий chunked на http/1.0 запросы, и попытка с этим жить в старых версиях nginx'а (до 1.1.4). Если причина (2), то в свежих версиях nginx всё должно работать без каких-либо приседаний - nginx теперь понимает chunked от бекендов, и соответствующая кривость бекенда останется незамеченной. Если (1), и соответствующий клиент для вас всё ещё актуален - вы об этом скоро узнаете. :) -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Thu Aug 22 14:01:10 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 22 Aug 2013 18:01:10 +0400 Subject: =?UTF-8?B?TmdpbnggINC90L7QvNC40L3QuNGA0L7QstCw0L0g0L3QsCDQv9GA0LXQvNC40Y4g?= =?UTF-8?B?IiDQodC00LXQu9Cw0L3QviDQsiDQoNC+0YHRgdC40LgiICDQvdCwIFNub2Iu?= =?UTF-8?B?cnU=?= Message-ID: <201308221801.10628.vbart@nginx.com> Все желающие могут нас поддержать в голосовании (регистрации не требуется): http://www.snob.ru/selected/entry/63464 Раздел "Предпринимательство" выбирается вверху страницы, сразу под картинкой, а голосовалка находится внизу. Спасибо! -- Валентин Бартенев http://nginx.org/en/donation.html From kav at karagodov.name Thu Aug 22 14:27:31 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 22 Aug 2013 18:27:31 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC10Lw=?= =?UTF-8?B?0LjRjiAiINCh0LTQtdC70LDQvdC+INCyINCg0L7RgdGB0LjQuCIgINC90LAg?= =?UTF-8?B?U25vYi5ydQ==?= In-Reply-To: <201308221801.10628.vbart@nginx.com> References: <201308221801.10628.vbart@nginx.com> Message-ID: <9BCB8275-8462-4BC6-B6A2-CF82C8F8BBAA@karagodov.name> "это шоу-биз, детка" ? :) On 22.08.2013, at 18:01, Валентин Бартенев wrote: > Все желающие могут нас поддержать в голосовании (регистрации не требуется): > http://www.snob.ru/selected/entry/63464 > > Раздел "Предпринимательство" выбирается вверху страницы, сразу под картинкой, > а голосовалка находится внизу. > > Спасибо! > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Thu Aug 22 20:23:49 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 23 Aug 2013 00:23:49 +0400 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: <5215ED54.9000407@csdoc.com> References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> <195871377150918@web5h.yandex.ru> <20130822100038.GU19334@mdounin.ru> <5215ED54.9000407@csdoc.com> Message-ID: <160391020.20130823002349@softsearch.ru> Здравствуйте, Gena. >> pecl-memcache сжимает данные в формате zlib (RFC1950), >> а nginx ожидает gzip (RFC1952). >>> Можно ли ожидать появления в nginx модулем memcached поддержки >>> zlib формата? >> Нет. > тогда у всех остается единственный возможный вариант - сделать так, > чтобы pecl-memcache научился сжимать данные в формате gzip > (RFC1952). Не у всех. Мне это не нужно, например. А вообще проблема давняя и вроде даже тогда решённая какими-то патчами. Гугл в помощь, короче. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Fri Aug 23 04:41:06 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 23 Aug 2013 08:41:06 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC10Lw=?= =?UTF-8?B?0LjRjiAiINCh0LTQtdC70LDQvdC+INCyINCg0L7RgdGB0LjQuCIgINC90LAg?= =?UTF-8?B?U25vYi5ydQ==?= In-Reply-To: <201308221801.10628.vbart@nginx.com> References: <201308221801.10628.vbart@nginx.com> Message-ID: <1428715244.20130823084106@softsearch.ru> Здравствуйте, Валентин. > Раздел "Предпринимательство" выбирается вверху страницы, сразу под > картинкой, а голосовалка находится внизу. "Предпринимательство"? Вебсервер - да, удачный продукт. А насколько вы успешны в бизнесе - хрен знает. С таким же успехом можно и в разделе "Музыка" участвовать. :-) -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Aug 23 06:34:55 2013 From: nginx-forum at nginx.us (aler) Date: Fri, 23 Aug 2013 02:34:55 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtC40LUg0YHQvtC10LTQuNC90LXQvdC40Y86IG5naW54?= =?UTF-8?B?INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCINCyINC30LDQs9C+0LvQvtCy0LrQtSAi?= =?UTF-8?B?Q29ubmVjdGlvbiA6IGNsb3NlIg==?= In-Reply-To: <20130822130820.GZ19334@mdounin.ru> References: <20130822130820.GZ19334@mdounin.ru> Message-ID: Да, похоже на первое.... JavaScript разработчик говорит, что была одна или две модели IPTV-приставок, на которых браузеры некорректно работали с chunked. Но, как я понял, они уже не используются. А в конфиге так и осталось) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242120,242141#msg-242141 From dovg at dovg.ru Fri Aug 23 07:41:07 2013 From: dovg at dovg.ru (Evgeny Kokovikhin) Date: Fri, 23 Aug 2013 11:41:07 +0400 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: <160391020.20130823002349@softsearch.ru> References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> <195871377150918@web5h.yandex.ru> <20130822100038.GU19334@mdounin.ru> <5215ED54.9000407@csdoc.com> <160391020.20130823002349@softsearch.ru> Message-ID: Порог автоматического сжатия в php-memcache можно повысить: http://www.php.net/manual/en/memcache.ini.php#ini.memcache.compress-threshold http://www.php.net/manual/en/memcache.setcompressthreshold.php Это позволит оперировать с обоих сторон несжатыми данными. 2013/8/23 Михаил Монашёв > Здравствуйте, Gena. > > >> pecl-memcache сжимает данные в формате zlib (RFC1950), > >> а nginx ожидает gzip (RFC1952). > > >>> Можно ли ожидать появления в nginx модулем memcached поддержки > >>> zlib формата? > > >> Нет. > > > тогда у всех остается единственный возможный вариант - сделать так, > > чтобы pecl-memcache научился сжимать данные в формате gzip > > (RFC1952). > > > Не у всех. Мне это не нужно, например. > > А вообще проблема давняя и вроде даже тогда решённая какими-то > патчами. Гугл в помощь, короче. > > -- > С уважением, > Михаил 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 undying-m at yandex.ru Fri Aug 23 08:32:48 2013 From: undying-m at yandex.ru (Kron) Date: Fri, 23 Aug 2013 12:32:48 +0400 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> <195871377150918@web5h.yandex.ru> <20130822100038.GU19334@mdounin.ru> <5215ED54.9000407@csdoc.com> <160391020.20130823002349@softsearch.ru> Message-ID: <344451377246768@web26h.yandex.ru> Выключить сжатие всегда можно, просто удобнее было бы что бы они все-таки сжимались клиентом (модулем memcache) и свободно отдавались nginx`ом через модуль memcached. Сжатие на лету, экономия памяти и отсутствие костылей. 23.08.2013, 11:41, "Evgeny Kokovikhin" : > Порог автоматического сжатия в php-memcache можно повысить: > http://www.php.net/manual/en/memcache.ini.php#ini.memcache.compress-threshold > http://www.php.net/manual/en/memcache.setcompressthreshold.php > > Это позволит оперировать с обоих сторон несжатыми данными. > > 2013/8/23 Михаил Монашёв >> Здравствуйте, Gena. >> >>  >> pecl-memcache сжимает данные в формате zlib (RFC1950), >>  >> а nginx ожидает gzip (RFC1952). >> >>>>> Можно  ли  ожидать  появления  в nginx модулем memcached поддержки >>>>> zlib формата? >> >>>> Нет. >> >>> тогда  у всех остается единственный возможный вариант - сделать так, >>> чтобы   pecl-memcache   научился   сжимать  данные  в  формате  gzip >>> (RFC1952). >> >> Не у всех. Мне это не нужно, например. >> >> А  вообще  проблема  давняя  и  вроде  даже  тогда  решённая какими-то >> патчами. Гугл в помощь, короче. >> >> -- >> С уважением, >>  Михаил                          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 From undying-m at yandex.ru Fri Aug 23 08:38:02 2013 From: undying-m at yandex.ru (Den Bozhok) Date: Fri, 23 Aug 2013 12:38:02 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC10Lw=?= =?UTF-8?B?0LjRjiAiINCh0LTQtdC70LDQvdC+INCyINCg0L7RgdGB0LjQuCIgINC90LAg?= =?UTF-8?B?U25vYi5ydQ==?= In-Reply-To: <1428715244.20130823084106@softsearch.ru> References: <201308221801.10628.vbart@nginx.com> <1428715244.20130823084106@softsearch.ru> Message-ID: <54291377247082@web24f.yandex.ru> Не вижу ничего сложного что бы поддержать ребят, учитывая их труд. Хотя глядя на голоса, Nginx и так впереди :) 23.08.2013, 08:41, "Михаил Монашёв" : > Здравствуйте, Валентин. > >>  Раздел  "Предпринимательство"  выбирается вверху страницы, сразу под >>  картинкой, а голосовалка находится внизу. > > "Предпринимательство"? Вебсервер - да, удачный продукт. А насколько вы > успешны  в  бизнесе - хрен знает. С таким же успехом можно и в разделе > "Музыка" участвовать. :-) > > -- > С уважением, >  Михаил                          mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From gmm at csdoc.com Fri Aug 23 09:03:17 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 23 Aug 2013 12:03:17 +0300 Subject: =?UTF-8?B?UmU6IHNldCDQvdCwINGD0YDQvtCy0L3QtSBodHRw?= In-Reply-To: <189518160.20130820074321@softsearch.ru> References: <614301687.20130810113206@softsearch.ru> <201308101301.48106.vbart@nginx.com> <246767059.20130810234331@softsearch.ru> <20130817025412.GA2130@mdounin.ru> <1416126954.20130819004928@softsearch.ru> <5211F050.7060501@csdoc.com> <845119670.20130819185409@softsearch.ru> <521270A0.6020400@csdoc.com> <189518160.20130820074321@softsearch.ru> Message-ID: <52172555.1000308@csdoc.com> On 20.08.2013 6:43, Михаил Монашёв wrote: >> [...] Variables are evaluated in the run-time during the processing >> of each request, so they are rather costly compared to plain static >> configuration. Using variables to store static strings >> is also a bad idea. > Ага, сравнивать строки - это плохо, ибо долго. Но ведь map, с помощью > которого приходится выкручиваться, ещё дольше! насколько я понимаю, в 99% случаев "set на уровне http" не нужны и можно обойтись "plain static configuration". в той задаче с которой начался тред - наверное лучше всего сделать в nginx встроенную переменную с именем кеш-зоны. и тогда вообще не останется случаев, когда приходится так "выкручиваться"? -- Best regards, Gena From wangsamp at gmail.com Fri Aug 23 09:46:37 2013 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Fri, 23 Aug 2013 12:46:37 +0300 (EEST) Subject: nginx + memcached + pecl-memcache compression In-Reply-To: <344451377246768@web26h.yandex.ru> References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> <195871377150918@web5h.yandex.ru> <20130822100038.GU19334@mdounin.ru> <5215ED54.9000407@csdoc.com> <160391020.20130823002349@softsearch.ru> <344451377246768@web26h.yandex.ru> Message-ID: Today Aug 23, 2013 at 12:32 Kron wrote: > Выключить сжатие всегда можно, просто удобнее было бы что бы они > все-таки сжимались клиентом (модулем memcache) и свободно отдавались > nginx`ом через модуль memcached. Сжатие на лету, экономия памяти и > отсутствие костылей. А кто мешает сжимать в PHP функцией gzencode, записывать в memcached со свои флагом и потом указать его в memcached_gzip_flag? -- WNGS-RIPE From anatoly at sonru.com Fri Aug 23 09:51:22 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 23 Aug 2013 10:51:22 +0100 Subject: =?UTF-8?B?UmU6IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC10Lw=?= =?UTF-8?B?0LjRjiAiINCh0LTQtdC70LDQvdC+INCyINCg0L7RgdGB0LjQuCIgINC90LAg?= =?UTF-8?B?U25vYi5ydQ==?= In-Reply-To: <54291377247082@web24f.yandex.ru> References: <201308221801.10628.vbart@nginx.com> <1428715244.20130823084106@softsearch.ru> <54291377247082@web24f.yandex.ru> Message-ID: <73B973FF-5A67-4C3B-A9DF-384ECF0559F4@sonru.com> On Aug 23, 2013, at 9:38 AM, Den Bozhok wrote: > Не вижу ничего сложного что бы поддержать ребят, учитывая их труд. > Хотя глядя на голоса, Nginx и так впереди :) > > 23.08.2013, 08:41, "Михаил Монашёв" : >> Здравствуйте, Валентин. >> >>> Раздел "Предпринимательство" выбирается вверху страницы, сразу под >>> картинкой, а голосовалка находится внизу. >> >> "Предпринимательство"? Вебсервер - да, удачный продукт. А насколько вы >> успешны в бизнесе - хрен знает. С таким же успехом можно и в разделе >> "Музыка" участвовать. :-) Сомневаюсь, что успешный бизнесмен будет с таким негативом относиться к одному из самых успешных IT-продуктов и команде, которая его создала. Игорь, Максим, Валентин, вы большие молодцы, пошел за вас голосовать! >> >> -- >> С уважением, >> Михаил 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 From undying-m at yandex.ru Fri Aug 23 10:03:21 2013 From: undying-m at yandex.ru (Den Bozhok) Date: Fri, 23 Aug 2013 14:03:21 +0400 Subject: nginx + memcached + pecl-memcache compression In-Reply-To: References: <134261377100980@web1h.yandex.ru> <201308212029.16130.vbart@nginx.com> <195871377150918@web5h.yandex.ru> <20130822100038.GU19334@mdounin.ru> <5215ED54.9000407@csdoc.com> <160391020.20130823002349@softsearch.ru> <344451377246768@web26h.yandex.ru> Message-ID: <46711377252201@web28e.yandex.ru> По сути ничего не мешает и пожалуй это будет следующим шагом, т.к. другие варианты отсутствуют. 23.08.2013, 13:46, "Oleksandr V. Typlyns'kyi" : > Today Aug 23, 2013 at 12:32 Kron wrote: > >>  Выключить сжатие всегда можно, просто удобнее было бы что бы они >>  все-таки сжимались клиентом (модулем memcache) и свободно отдавались >>  nginx`ом через модуль memcached. Сжатие на лету, экономия памяти и >>  отсутствие костылей. > >   А кто мешает сжимать в PHP функцией gzencode, записывать в memcached со >   свои флагом и потом указать его в memcached_gzip_flag? > > -- > WNGS-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From kav at karagodov.name Fri Aug 23 12:26:53 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Fri, 23 Aug 2013 16:26:53 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC10Lw=?= =?UTF-8?B?0LjRjiAiINCh0LTQtdC70LDQvdC+INCyINCg0L7RgdGB0LjQuCIgINC90LAg?= =?UTF-8?B?U25vYi5ydQ==?= In-Reply-To: <73B973FF-5A67-4C3B-A9DF-384ECF0559F4@sonru.com> References: <201308221801.10628.vbart@nginx.com> <1428715244.20130823084106@softsearch.ru> <54291377247082@web24f.yandex.ru> <73B973FF-5A67-4C3B-A9DF-384ECF0559F4@sonru.com> Message-ID: думаю я не единственный, кто проголосовал "за" по сравнению с NGINX, потуги автоТАЗа просто комичны и даже приступны скорей всего большинство, только это и могут вот если бы каждый платил за переданный с помощью NGINX (гига/мега/тера/чего-то-там)байт по некоторой сумме, проект был бы ещё успешнее по типу налогов, только скромнее :) в том же Рамблере накапало уже наверно не на одну статую Игоря из золота а так, спасибы, голоса ну иногда баг-репорты - вся благодарность On 23.08.2013, at 13:51, Anatoly Mikhailov wrote: > > On Aug 23, 2013, at 9:38 AM, Den Bozhok wrote: > >> Не вижу ничего сложного что бы поддержать ребят, учитывая их труд. >> Хотя глядя на голоса, Nginx и так впереди :) >> >> 23.08.2013, 08:41, "Михаил Монашёв" : >>> Здравствуйте, Валентин. >>> >>>> Раздел "Предпринимательство" выбирается вверху страницы, сразу под >>>> картинкой, а голосовалка находится внизу. >>> >>> "Предпринимательство"? Вебсервер - да, удачный продукт. А насколько вы >>> успешны в бизнесе - хрен знает. С таким же успехом можно и в разделе >>> "Музыка" участвовать. :-) > > Сомневаюсь, что успешный бизнесмен будет с таким негативом относиться > к одному из самых успешных IT-продуктов и команде, которая его создала. > Игорь, Максим, Валентин, вы большие молодцы, пошел за вас голосовать! > >>> >>> -- >>> С уважением, >>> Михаил 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 > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From a at gelun.ru Fri Aug 23 17:51:21 2013 From: a at gelun.ru (Gelun, Artem) Date: Fri, 23 Aug 2013 21:51:21 +0400 Subject: =?UTF-8?B?R0VPINC80L7QtNGD0LvRjCDQuCDQutC+0LvQuNGH0LXRgdGC0LLQviDQv9GA0LU=?= =?UTF-8?B?0YTQuNC60YHQvtCy?= Message-ID: Здравствуйте. Подскажите пожалуйста какое максимальное количество префиксов в GEO-модуле допустимо? И ещё: имеет ли значение с т.з. производительности, указываются ли правила в виде префиксов или в виде диапазонов (ranges)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at gelun.ru Fri Aug 23 18:45:43 2013 From: a at gelun.ru (Gelun, Artem) Date: Fri, 23 Aug 2013 22:45:43 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?= =?UTF-8?B?0LXQutCy0LXRgdGC?= In-Reply-To: <20130726170116.GW30025@vdsl.uvw.ru> References: <20130726075333.GQ30025@vdsl.uvw.ru> <20130726130734.GT30025@vdsl.uvw.ru> <20130726170116.GW30025@vdsl.uvw.ru> Message-ID: Тема, конечно, старая, и уже "завяла", но: а как Вы собираетесь инвалидировать кэш если у вас, к примеру, стоит 2 frontend'а и каждый из них кэширует независимо? Вот пришёл, к примеру, один юзер на FE1, страница закэшировалась. Второй - на FE02, страница закэшировалась ещё раз. Потом прошёл какой-то запрос, в ответе на который была инвалидация по заданному ключу. И этот запрос проксируется ведь только одиним FE (например, первым). В итоге, второй FE будет отдавать старые данные и схема будет неработоспособной (если, конечно, не допускать, что при обновлении страницы пользователь может получать разные данные). 26 июля 2013 г., 21:01 пользователь Dmitry E. Oboukhov написал: > >> нет это совсем не то что в фичареквесте. > >> > > ... > >> > >> я хочу получить механизм внутри обработчика сбросить кеш на другом > >> роуте. > >> как вариант - выдать хидер с урлом кеш на котором надо сбросить. > >> > >> а директивы в конфиге = это не программа это набор условий :) > >> > > я раньше решал похожую проблему с помощью модуля ngx_cache_purge ( > > http://wiki.nginx.org/CachePurgeChs ). создавал в nginx специальный > > локейшн (/purge/), при обращении к которому удалялся из кеша указанный > > элемент. Т.е. после изменения в базе, запрос по этому локейшну делает > > само приложение (для wordpress есть специальный плагин). Подробнее (с > > конфигами) можно почитать тут: > > > http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html > > http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html > > > но теперь, я бы попытался реализовать соответствующий функционал без > > стороннего модуля, а только директивой proxy_cache_bypass. > > proxy_cache_bypass ведь не дает того функционала о котором я говорю: > когда один роут сбрасывает кеш на другом роуте. > > > Таким образом, применяя предложенную мной схему, вместо того чтобы > > просто отдать nginx страницу с заголовком X-Cache-Invalid: > > "/users/top/123?all=yes", вам придётся сначала сделать запрос из > > приложения по адресу /purge/users/top/123?all=yes и элемент кеша > > обновится. > > я посмотрю внутрь модуля. сложно его доработать до того функционала > что я говорю? > > -- > > . ''`. Dmitry E. Oboukhov > : :' : email: unera at debian.org jabber://UNera at uvw.ru > `. `~' GPGKey: 1024D / F8E26537 2006-11-21 > `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEAREDAAYFAlHyq1wACgkQq4wAz/jiZTe0JwCePKuBoExhqU/EEzIzqC8xFBpm > MhQAoNBbH8GwYwoba7m0bAd9mZhX41yl > =ArMD > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 unera at uvw.ru Fri Aug 23 19:42:00 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Fri, 23 Aug 2013 23:42:00 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?= =?UTF-8?B?0LXQutCy0LXRgdGC?= In-Reply-To: References: <20130726075333.GQ30025@vdsl.uvw.ru> <20130726130734.GT30025@vdsl.uvw.ru> <20130726170116.GW30025@vdsl.uvw.ru> Message-ID: <20130823194200.GC16410@vdsl.uvw.ru> > Тема, конечно, старая, и уже "завяла", но: > а как Вы собираетесь инвалидировать кэш если у вас, к примеру, стоит 2 > frontend'а и каждый из них кэширует независимо? > Вот пришёл, к примеру, один юзер на FE1, страница закэшировалась. Второй - на > FE02, страница закэшировалась ещё раз. Потом прошёл какой-то запрос, в ответе > на который была инвалидация по заданному ключу. И этот запрос проксируется ведь тут фича, очевидно будет для одного FE. то есть юзер должен понимать что кеш сбросится у того FE который стоит перед данным бакендом -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nginx-forum at nginx.us Sat Aug 24 03:57:41 2013 From: nginx-forum at nginx.us (incubus) Date: Fri, 23 Aug 2013 23:57:41 -0400 Subject: =?UTF-8?Q?upstream_=D0=B8_Host_header?= Message-ID: <52a1b94bd30ebd99892fbe7c6f4cbe2c.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Столкнулся с проблемой передачи Host заголовка серверу из upstream секции. Простая конфигурация: nginx-1.5.3 upstream cdn { server host1; server host2; server host3; } location /test { proxy_pass http://cdn; } При выполнения запроса проксируемому серверу передается Host: cdn вместо Host: host*. Т.е. похоже в $proxy_host попадает название группы, а не сервер из нее. Это нормально? При явном указании proxy_pass http://host1 таких проблем нет. С уважением, Александр Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242169#msg-242169 From chipitsine at gmail.com Sat Aug 24 05:11:37 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 24 Aug 2013 11:11:37 +0600 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: <52a1b94bd30ebd99892fbe7c6f4cbe2c.NginxMailingListRussian@forum.nginx.org> References: <52a1b94bd30ebd99892fbe7c6f4cbe2c.NginxMailingListRussian@forum.nginx.org> Message-ID: это фича 24 августа 2013 г., 9:57 пользователь incubus написал: > Здравствуйте! > > Столкнулся с проблемой передачи Host заголовка серверу из upstream секции. > Простая конфигурация: > > nginx-1.5.3 > > upstream cdn { > server host1; > server host2; > server host3; > } > > location /test { > proxy_pass http://cdn; > } > > > При выполнения запроса проксируемому серверу передается Host: cdn вместо > Host: host*. Т.е. похоже в $proxy_host попадает название группы, а не сервер > из нее. Это нормально? При явном указании proxy_pass http://host1 таких > проблем нет. > > > С уважением, > Александр > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242169#msg-242169 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Sat Aug 24 05:17:42 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 24 Aug 2013 09:17:42 +0400 Subject: =?UTF-8?B?UmVbMl06IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC1?= =?UTF-8?B?0LzQuNGOICIg0KHQtNC10LvQsNC90L4g0LIg0KDQvtGB0YHQuNC4IiAg0L0=?= =?UTF-8?B?0LAgU25vYi5ydQ==?= In-Reply-To: <54291377247082@web24f.yandex.ru> References: <201308221801.10628.vbart@nginx.com> <1428715244.20130823084106@softsearch.ru> <54291377247082@web24f.yandex.ru> Message-ID: <1205558927.20130824091742@softsearch.ru> Здравствуйте, Den. > Не вижу ничего сложного что бы поддержать ребят, учитывая их труд. > Хотя глядя на голоса, Nginx и так впереди :) >>>  Раздел  "Предпринимательство"  выбирается вверху страницы, сразу под >>>  картинкой, а голосовалка находится внизу. >> >> "Предпринимательство"? Вебсервер - да, удачный продукт. А насколько вы >> успешны  в  бизнесе - хрен знает. С таким же успехом можно и в разделе >> "Музыка" участвовать. :-) Естественно поддержал. Просто мне показались странными раздел и сама премия. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Sat Aug 24 05:20:44 2013 From: nginx-forum at nginx.us (incubus) Date: Sat, 24 Aug 2013 01:20:44 -0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: References: Message-ID: <70fe8ac5b12a0a16ba98bf485658531f.NginxMailingListRussian@forum.nginx.org> И обойти никак? Илья Шипицин Wrote: ------------------------------------------------------- > это фича Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242172#msg-242172 From postmaster at softsearch.ru Sat Aug 24 05:36:23 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 24 Aug 2013 09:36:23 +0400 Subject: =?UTF-8?B?UmVbMl06IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC1?= =?UTF-8?B?0LzQuNGOICIg0KHQtNC10LvQsNC90L4g0LIg0KDQvtGB0YHQuNC4IiAg0L0=?= =?UTF-8?B?0LAgU25vYi5ydQ==?= In-Reply-To: <73B973FF-5A67-4C3B-A9DF-384ECF0559F4@sonru.com> References: <201308221801.10628.vbart@nginx.com> <1428715244.20130823084106@softsearch.ru> <54291377247082@web24f.yandex.ru> <73B973FF-5A67-4C3B-A9DF-384ECF0559F4@sonru.com> Message-ID: <263005485.20130824093623@softsearch.ru> Здравствуйте, Anatoly. >>>> Раздел "Предпринимательство" выбирается вверху страницы, сразу >>>> под картинкой, а голосовалка находится внизу. >>> >>> "Предпринимательство"? Вебсервер - да, удачный продукт. А >>> насколько вы успешны в бизнесе - хрен знает. С таким же успехом >>> можно и в разделе "Музыка" участвовать. :-) > Сомневаюсь, что успешный бизнесмен будет с таким негативом > относиться к одному из самых успешных IT-продуктов и команде, > которая его создала. Игорь, Максим, Валентин, вы большие молодцы, > пошел за вас голосовать! Да причём здесь отношения или негатив или позитив. Я ж совсем про другое пишу. Попробую разделить кашу на мух и котлеты. Есть вебсервер. Он популярен. Мы всем им пользуемся. А "предприниматель ≈ это лицо, занимающееся собственным бизнесом, имеющее своё дело в целях получения прибыли или иной выгоды." Т.е. эта премия смешивает и два понятия и подменяет одно другим: популярность и деньги. Но популярность и деньги не всегда идут вместе. И одно из другого автоматически не следует. И голосуют за nginx потому что он популярен, а не потому, что он приносит владельцам много денег. От того и раздел "Предпринимательство" подходит для nginx-а меньше, чем "Музыка", которая в основном nginx-ом в инете и раздаётся, что в отличии от прибыли nginx-а можно самостоятельно проверить, посмотрев http-заголовки "музыкальных" сайтов. -- С уважением, Михаил mailto:postmaster at softsearch.ru From a at gelun.ru Sat Aug 24 05:51:43 2013 From: a at gelun.ru (Artem Gelun) Date: Sat, 24 Aug 2013 09:51:43 +0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: <70fe8ac5b12a0a16ba98bf485658531f.NginxMailingListRussian@forum.nginx.org> References: <70fe8ac5b12a0a16ba98bf485658531f.NginxMailingListRussian@forum.nginx.org> Message-ID: Укажите "руками" заголовок Host. Можете туда вообще произвольные значения слать. -- Artem Gelun 24.08.2013, в 9:20, "incubus" написал(а): > И обойти никак? > > Илья Шипицин Wrote: > ------------------------------------------------------- >> это фича > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242172#msg-242172 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sat Aug 24 05:58:30 2013 From: nginx-forum at nginx.us (incubus) Date: Sat, 24 Aug 2013 01:58:30 -0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: References: Message-ID: <3497e88605b1d5fc1133cc1d4ea9bfd3.NginxMailingListRussian@forum.nginx.org> Я бы с радостью, но мне нужно имя использованного сервера из upstream. Artem Gelun Wrote: ------------------------------------------------------- > Укажите "руками" заголовок Host. Можете туда вообще произвольные > значения слать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242176#msg-242176 From a at gelun.ru Sat Aug 24 06:01:44 2013 From: a at gelun.ru (Artem Gelun) Date: Sat, 24 Aug 2013 10:01:44 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?= =?UTF-8?B?0LXQutCy0LXRgdGC?= In-Reply-To: <20130823194200.GC16410@vdsl.uvw.ru> References: <20130726075333.GQ30025@vdsl.uvw.ru> <20130726130734.GT30025@vdsl.uvw.ru> <20130726170116.GW30025@vdsl.uvw.ru> <20130823194200.GC16410@vdsl.uvw.ru> Message-ID: <73866049-C290-4425-9D93-1BA9850A2330@gelun.ru> Тогда не понимаю смысла в доработке... На ненагруженных проектах, где даже резервированием не "запариваются" инвалидацию можно сделать через bypass (отправив запрос с БЭ на nginx) На нагруженных, где подобный сценарий считают слишком затратным, как правило не шлют все запросы клиента на один FE и метод работать не будет. Или, есть, конечно, другой вариант: реализовать доработку, а ее "кластерный" вариант выпустить в платной версии )) -- Artem Gelun 23.08.2013, в 23:42, "Dmitry E. Oboukhov" написал(а): >> Тема, конечно, старая, и уже "завяла", но: > >> а как Вы собираетесь инвалидировать кэш если у вас, к примеру, стоит 2 >> frontend'а и каждый из них кэширует независимо? >> Вот пришёл, к примеру, один юзер на FE1, страница закэшировалась. Второй - на >> FE02, страница закэшировалась ещё раз. Потом прошёл какой-то запрос, в ответе >> на который была инвалидация по заданному ключу. И этот запрос проксируется ведь > > тут фича, очевидно будет для одного FE. > то есть юзер должен понимать что кеш сбросится у того FE который стоит > перед данным бакендом > -- > > . ''`. Dmitry E. Oboukhov > : :? : email: unera at debian.org jabber://UNera at uvw.ru > `. `~? GPGKey: 1024D / F8E26537 2006-11-21 > `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From a at gelun.ru Sat Aug 24 06:19:02 2013 From: a at gelun.ru (Gelun, Artem) Date: Sat, 24 Aug 2013 10:19:02 +0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: <3497e88605b1d5fc1133cc1d4ea9bfd3.NginxMailingListRussian@forum.nginx.org> References: <3497e88605b1d5fc1133cc1d4ea9bfd3.NginxMailingListRussian@forum.nginx.org> Message-ID: Насколько я понимаю, запрос формируется один раз и отправляется на апстримы уже в неизменном виде. Поэтому слать на каждый апстрим разные данные вряд ли получится. Может решить проблему на стороне самого БЭ? 24 августа 2013 г., 9:58 пользователь incubus написал: > Я бы с радостью, но мне нужно имя использованного сервера из upstream. > > Artem Gelun Wrote: > ------------------------------------------------------- > > Укажите "руками" заголовок Host. Можете туда вообще произвольные > > значения слать. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,242169,242176#msg-242176 > > _______________________________________________ > 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 Sat Aug 24 06:37:29 2013 From: nginx-forum at nginx.us (incubus) Date: Sat, 24 Aug 2013 02:37:29 -0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: References: Message-ID: <23e9c789733437823d144698ee585c07.NginxMailingListRussian@forum.nginx.org> Gelun, Artem Wrote: ------------------------------------------------------- > Насколько я понимаю, запрос формируется один раз и отправляется на > апстримы > уже в неизменном виде. Поэтому слать на каждый апстрим разные данные > вряд > ли получится. Тогда все понятно. Я просто думал, что переменная $proxy_host указывается перед запросом и используется для заголовка Host, если он явно не задан. > Может решить проблему на стороне самого БЭ? Он мне недоступен. :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242179#msg-242179 From chipitsine at gmail.com Sat Aug 24 09:16:09 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 24 Aug 2013 15:16:09 +0600 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: <3497e88605b1d5fc1133cc1d4ea9bfd3.NginxMailingListRussian@forum.nginx.org> References: <3497e88605b1d5fc1133cc1d4ea9bfd3.NginxMailingListRussian@forum.nginx.org> Message-ID: а смысл? 24 августа 2013 г., 11:58 пользователь incubus написал: > Я бы с радостью, но мне нужно имя использованного сервера из upstream. > > Artem Gelun Wrote: > ------------------------------------------------------- >> Укажите "руками" заголовок Host. Можете туда вообще произвольные >> значения слать. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242176#msg-242176 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sat Aug 24 10:29:11 2013 From: nginx-forum at nginx.us (stitrace) Date: Sat, 24 Aug 2013 06:29:11 -0400 Subject: =?UTF-8?B?0JjQt9C80LXQvdC10L3QuNC1INC/0YDQvtGG0LXQtNGD0YDRiyDQvtCx0L3QvtCy?= =?UTF-8?B?0LvQtdC90LjRjyDQutGN0YjQsA==?= Message-ID: Опишу некоторые, особенности работы модуля PURGE nginx, с которыми я столкнулся и которые затрудняют его использование в hi-load: Как известно, механизм purge в nginx призван для управления кэшем, единственным его предназначением является очистка кэша для необходимого урла на сайте. Мы могли бы закэшировать страницу с урлом http:://mysite.ru/main/, к примеру, на сутки и реализовать в форме отправки сообщения нашего сайта инициацию запроса http:://mysite.ru/purge/main/, который, при должной конфигурации, очистит кэш для страницы /main/. На первый взгляд, всё выглядит идеально и придраться не к чему, но если разобраться, то не так всё гладко, когда дело касается hi-load. Дело в том, что nginx производит очистку кэша в таком порядке: a) После выполнения PURGE запроса он удаляет закэшированную копию страницы из хранилища. б) Ждёт сгенерированную, новую страницу от бэкэнда. в) Отдаёт её пользователю и кладёт в кэш, далее продолжая раздавать её пользователям. Всё шикарно, но при выполнении пункта "б" он, если к нему обращается клиент, не находя страницу у себя в кэше, пропускает все запросы к фронтэнду. Теперь допустим сценарий, ваша страница /main/ генерируется на бэкэнде 1 секунду и он настроен таким образом, что максимальное количество клиентов на нём не должно превышать 300. Посещаемость /main/ - 600 запросов в секунду, каждый новый клиент увеличивает время отработки запроса к фронтэнду на 0.3%. Мы видим, что, количество клиентов, которые пройдут на бэкэнд, превышает в два раза разрешённый лимит, а время выполения запроса, в первые полсекунды, будет расти по экспоненте и скрипт, в лучшем случае, завершит работу через несколько секунд, а в худшем, бэкэнд вернёт 502 ошибку, из-за ограничений на время выполнения кода на фронтэнде, то есть, фактически, уронит ваш проект. Точно такая же ситуация будет, если элемента ещё нет в кэше и на него внезапно начинают обращаться пользователи (допустим произошла публикация новой страницы). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242182,242182#msg-242182 From vadim.lazovskiy at gmail.com Sat Aug 24 10:40:20 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Sat, 24 Aug 2013 14:40:20 +0400 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSDQv9GA0L7RhtC10LTRg9GA0Ysg0L7QsdC9?= =?UTF-8?B?0L7QstC70LXQvdC40Y8g0LrRjdGI0LA=?= In-Reply-To: References: Message-ID: Здравствуйте. http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock 24 августа 2013 г., 14:29 пользователь stitrace написал: > Опишу некоторые, особенности работы модуля PURGE nginx, с которыми я > столкнулся и которые затрудняют его использование в hi-load: > > Как известно, механизм purge в nginx призван для управления кэшем, > единственным его предназначением является очистка кэша для необходимого > урла > на сайте. > > Мы могли бы закэшировать страницу с урлом http:://mysite.ru/main/, к > примеру, на сутки и реализовать в форме отправки сообщения нашего сайта > инициацию запроса http:://mysite.ru/purge/main/, который, при должной > конфигурации, очистит кэш для страницы /main/. На первый взгляд, всё > выглядит идеально и придраться не к чему, но если разобраться, то не так > всё > гладко, когда дело касается hi-load. Дело в том, что nginx производит > очистку кэша в таком порядке: > > a) После выполнения PURGE запроса он удаляет закэшированную копию страницы > из хранилища. > б) Ждёт сгенерированную, новую страницу от бэкэнда. > в) Отдаёт её пользователю и кладёт в кэш, далее продолжая раздавать её > пользователям. > > Всё шикарно, но при выполнении пункта "б" он, если к нему обращается > клиент, > не находя страницу у себя в кэше, пропускает все запросы к фронтэнду. > > Теперь допустим сценарий, ваша страница /main/ генерируется на бэкэнде 1 > секунду и он настроен таким образом, что максимальное количество клиентов > на > нём не должно превышать 300. Посещаемость /main/ - 600 запросов в секунду, > каждый новый клиент увеличивает время отработки запроса к фронтэнду на > 0.3%. > Мы видим, что, количество клиентов, которые пройдут на бэкэнд, превышает в > два раза разрешённый лимит, а время выполения запроса, в первые полсекунды, > будет расти по экспоненте и скрипт, в лучшем случае, завершит работу через > несколько секунд, а в худшем, бэкэнд вернёт 502 ошибку, из-за ограничений > на > время выполнения кода на фронтэнде, то есть, фактически, уронит ваш проект. > > Точно такая же ситуация будет, если элемента ещё нет в кэше и на него > внезапно начинают обращаться пользователи (допустим произошла публикация > новой страницы). > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,242182,242182#msg-242182 > > _______________________________________________ > 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 nginx-forum at nginx.us Sat Aug 24 10:54:23 2013 From: nginx-forum at nginx.us (stitrace) Date: Sat, 24 Aug 2013 06:54:23 -0400 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSDQv9GA0L7RhtC10LTRg9GA0Ysg0L7QsdC9?= =?UTF-8?B?0L7QstC70LXQvdC40Y8g0LrRjdGI0LA=?= In-Reply-To: References: Message-ID: <648f8f4d6d6a1f643efa3793e0895bc0.NginxMailingListRussian@forum.nginx.org> Огромное вам спасибо) А мне - 2 за невнимательное чтение доков) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242182,242184#msg-242184 From nginx-forum at nginx.us Sat Aug 24 15:03:25 2013 From: nginx-forum at nginx.us (incubus) Date: Sat, 24 Aug 2013 11:03:25 -0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: References: Message-ID: <4de5a54c6625c07b3ee4fb4930d9cc13.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > а смысл? Бэкэнду нужен правильный Host и, как я уже писал выше, у меня нет к нему доступа. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242185#msg-242185 From onokonem at gmail.com Sat Aug 24 15:16:24 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 24 Aug 2013 19:16:24 +0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: <4de5a54c6625c07b3ee4fb4930d9cc13.NginxMailingListRussian@forum.nginx.org> References: <4de5a54c6625c07b3ee4fb4930d9cc13.NginxMailingListRussian@forum.nginx.org> Message-ID: > Бэкэнду нужен правильный Host и, как я уже писал выше, у меня нет к нему > доступа. вам точо нужно проксирование, а не редирект 302? если точно, то можно сколхозить схему с двойным проксированием upstream cdn { server 127.0.0.1:port1; server 127.0.0.1:port2; server 127.0.0.1:port3; } server { listen 127.0.0.1:port1; location / { proxy_pass http://host1; proxy_set_header Host host1; } } server { listen 127.0.0.1:port2; location / { proxy_pass http://host2; proxy_set_header Host host2; } } server { listen 127.0.0.1:port3; location / { proxy_pass http://host3; proxy_set_header Host host3; } } location /test { proxy_pass http://cdn; } From unera at uvw.ru Sat Aug 24 17:50:22 2013 From: unera at uvw.ru (Dmitry E. Oboukhov) Date: Sat, 24 Aug 2013 21:50:22 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INC60LXRiNC+0LwgLSDRhNC40YfQsNGA?= =?UTF-8?B?0LXQutCy0LXRgdGC?= In-Reply-To: <73866049-C290-4425-9D93-1BA9850A2330@gelun.ru> References: <20130726075333.GQ30025@vdsl.uvw.ru> <20130726130734.GT30025@vdsl.uvw.ru> <20130726170116.GW30025@vdsl.uvw.ru> <20130823194200.GC16410@vdsl.uvw.ru> <73866049-C290-4425-9D93-1BA9850A2330@gelun.ru> Message-ID: <20130824175022.GD16410@vdsl.uvw.ru> > Тогда не понимаю смысла в доработке... > На ненагруженных проектах, где даже резервированием не "запариваются" инвалидацию можно сделать через bypass (отправив запрос с БЭ на nginx) > На нагруженных, где подобный сценарий считают слишком затратным, как правило не шлют все запросы клиента на один FE и метод работать не будет. > Или, есть, конечно, другой вариант: реализовать доработку, а ее "кластерный" вариант выпустить в платной версии )) Эмм... два запроса связанные с одним кешом как правило выполняются одним и тем же бакендом. конечно если система распределенная полностью, то такая фича и не нужна будет. но в распределенных нагруженных системах и nginx уже никто не применяет ни для чего иного кроме как роутинга http-трафика. -- . ''`. Dmitry E. Oboukhov : :? : email: unera at debian.org jabber://UNera at uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nginx-forum at nginx.us Sun Aug 25 01:31:39 2013 From: nginx-forum at nginx.us (ivanko) Date: Sat, 24 Aug 2013 21:31:39 -0400 Subject: =?UTF-8?Q?limit_except_=D0=B8_dav?= Message-ID: Друзья! прошу помочь с RTFM на тему совмещения dav и limit_except - не выходит ограничить доступ ((( Хочется закрыть доступ с любыми методами от одного ip, а все остальные могут путать и постить. nginx]$ date; ./sbin/nginx -V; sed -n "/#start/,/#end/ p" conf/nginx.conf; ./sbin/nginx -p $PWD -s reload; tail logs/error.log -n 1;/sbin/ifconfig |grep 172.16.4.39; ls -l var/www/cert.crl ;curl -T ../cert.crl http://172.16.4.39:8080/ -D -; curl -D - -o /dev/null http://172.16.4.39:8080/cert.crl -s; grep -h 172.16.4.39 logs/*access.log|tail -2; ls -l var/www/cert.crl Sun Aug 25 05:28:00 MSK 2013 nginx version: nginx/1.4.2 built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50) configure arguments: --with-http_dav_module #start server { listen 8080; server_name localhost client_body_temp_path client_body_temp; client_max_body_size 0; location / { limit_except GET { deny 172.16.4.39; allow all; } location ~* \.crl { types { application/x-pkcs7-crl crl; } } root var/www/; dav_methods PUT; create_full_put_path on; dav_access group:r all:r; } } #end 2013/08/25 05:28:00 [notice] 7367#0: signal process started inet addr:172.16.4.39 Bcast:172.16.4.255 Mask:255.255.255.0 ls: var/www/cert.crl: No such file or directory HTTP/1.1 100 Continue HTTP/1.1 201 Created Server: nginx/1.4.2 Date: Sun, 25 Aug 2013 01:28:00 GMT Content-Length: 0 Location: http://172.16.4.39:8080/cert.crl Connection: keep-alive HTTP/1.1 200 OK Server: nginx/1.4.2 Date: Sun, 25 Aug 2013 01:28:00 GMT Content-Type: application/x-pkcs7-crl Content-Length: 145188 Last-Modified: Sun, 25 Aug 2013 01:28:00 GMT Connection: keep-alive ETag: "52195da0-23724" Accept-Ranges: bytes 172.16.4.39 - - [25/Aug/2013:05:26:49 +0400] "PUT /cert%2Ecrl HTTP/1.1" 201 25 "-" "curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5" 172.16.4.39 - - [25/Aug/2013:05:26:49 +0400] "GET /cert.crl HTTP/1.1" 200 145188 "-" "curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5" -rw-r--r-- 1 ivanko users 145188 Aug 25 05:28 var/www/cert.crl nginx]$ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242191,242191#msg-242191 From vbart at nginx.com Sun Aug 25 13:50:00 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 25 Aug 2013 17:50:00 +0400 Subject: =?UTF-8?Q?Re=3A_limit_except_=D0=B8_dav?= In-Reply-To: References: Message-ID: <201308251750.00130.vbart@nginx.com> On Sunday 25 August 2013 05:31:39 ivanko wrote: > Друзья! прошу помочь с RTFM на тему совмещения dav и limit_except - не > выходит ограничить доступ ((( > Хочется закрыть доступ с любыми методами от одного ip, а все остальные > могут путать и постить. > [...] > location ~* \.crl { > types { > application/x-pkcs7-crl crl; > } > } У вас запрос сюда попадает. Смысл данного location'a непонятен, т.е. необходимость создавать его только ради задания types отдельно. -- Валентин Бартенев http://nginx.org/en/donation.html From voron at amhost.net Sun Aug 25 16:23:24 2013 From: voron at amhost.net (Alex Vorona) Date: Sun, 25 Aug 2013 19:23:24 +0300 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: References: <4de5a54c6625c07b3ee4fb4930d9cc13.NginxMailingListRussian@forum.nginx.org> Message-ID: <521A2F7C.8000707@amhost.net> 24.08.2013 18:16, Daniel Podolsky wrote: >> Бэкэнду нужен правильный Host и, как я уже писал выше, у меня нет к нему >> доступа. > вам точо нужно проксирование, а не редирект 302? > > если точно, то можно сколхозить схему с двойным проксированием > > upstream cdn { > server 127.0.0.1:port1; > server 127.0.0.1:port2; > server 127.0.0.1:port3; > } Причем локальное проксирование можно сделать через unix-сокеты. From nginx-forum at nginx.us Sun Aug 25 20:33:23 2013 From: nginx-forum at nginx.us (ivanko) Date: Sun, 25 Aug 2013 16:33:23 -0400 Subject: =?UTF-8?Q?Re=3A_limit_except_=D0=B8_dav?= In-Reply-To: <201308251750.00130.vbart@nginx.com> References: <201308251750.00130.vbart@nginx.com> Message-ID: Спасибо! Глаз совсем замылился и уже перестал понимать к чему это я =) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242197,242199#msg-242199 From nginx-forum at nginx.us Mon Aug 26 00:38:03 2013 From: nginx-forum at nginx.us (incubus) Date: Sun, 25 Aug 2013 20:38:03 -0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: References: Message-ID: Daniel Podolsky Wrote: ------------------------------------------------------- > > Бэкэнду нужен правильный Host и, как я уже писал выше, у меня нет к > нему > > доступа. > вам точо нужно проксирование, а не редирект 302? > > если точно, то можно сколхозить схему с двойным проксированием Спасибо большое, похоже придется делать так. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242201#msg-242201 From citrin at citrin.ru Mon Aug 26 11:18:33 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 26 Aug 2013 15:18:33 +0400 Subject: =?UTF-8?B?UmU6IEdFTyDQvNC+0LTRg9C70Ywg0Lgg0LrQvtC70LjRh9C10YHRgtCy0L4g0L8=?= =?UTF-8?B?0YDQtdGE0LjQutGB0L7Qsg==?= In-Reply-To: References: Message-ID: <521B3989.9050603@citrin.ru> On 08/23/13 21:51, Gelun, Artem wrote: > Подскажите пожалуйста какое максимальное количество префиксов в GEO-модуле > допустимо? Зависит только от объема RAM, но стоит учитывать, что при большом числе префиксов возрастет нагрузка на CPU (и время ответа). Если у вас больше миллиона префиксов, то стоит подумать об уменьшении их числа. From vbart at nginx.com Mon Aug 26 11:41:33 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 26 Aug 2013 15:41:33 +0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: References: Message-ID: <201308261541.33296.vbart@nginx.com> On Monday 26 August 2013 04:38:03 incubus wrote: > Daniel Podolsky Wrote: > ------------------------------------------------------- > > > > Бэкэнду нужен правильный Host и, как я уже писал выше, у меня нет к > > > > нему > > > > > доступа. > > > > вам точо нужно проксирование, а не редирект 302? > > > > если точно, то можно сколхозить схему с двойным проксированием > > Спасибо большое, похоже придется делать так. > Вы бы рассказали, какую задачу решаете. А то окажется, что вам не блок upstream нужен (который предполагает, что это группа серверов отдающих один и тот же ресурс), а split_clients. -- Валентин Бартенев From kiribool at gmail.com Mon Aug 26 13:06:50 2013 From: kiribool at gmail.com (Kirill Bychkov) Date: Mon, 26 Aug 2013 17:06:50 +0400 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC+INGA0LDQt9C00LDRh9C1INGB0YLQsNGC0LjQutC4?= Message-ID: Приветствую, прошу совета. Сейчас сайт работает под управлением IIS 7.5. Статика раздается с этого же сервера, но со специально выделенного URL, типа static.example.com Сам сервер виртуализирован и его данные хранятся на корзине. Сейчас кэширование не включено на IIS. Стали заметны тормоза в загрузке статики из-за увеличения нагрузки на корзину. Будет ли прирост в скорости загрузки, если я перед IIS, на этой же корзине (в этом же storage массиве) поставлю ngnix в качестве кэширующего реверсивного прокси-сервера для раздачи статических файлов? Заранее благодарен. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Mon Aug 26 14:54:23 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 26 Aug 2013 15:54:23 +0100 Subject: =?UTF-8?B?UmU6IE5naW54ICDQvdC+0LzQuNC90LjRgNC+0LLQsNC9INC90LAg0L/RgNC10Lw=?= =?UTF-8?B?0LjRjiAiINCh0LTQtdC70LDQvdC+INCyINCg0L7RgdGB0LjQuCIgINC90LAg?= =?UTF-8?B?U25vYi5ydQ==?= In-Reply-To: <263005485.20130824093623@softsearch.ru> References: <201308221801.10628.vbart@nginx.com> <1428715244.20130823084106@softsearch.ru> <54291377247082@web24f.yandex.ru> <73B973FF-5A67-4C3B-A9DF-384ECF0559F4@sonru.com> <263005485.20130824093623@softsearch.ru> Message-ID: <2C4322B1-5FDE-4BE9-90D2-79694528884C@sonru.com> On Aug 24, 2013, at 6:36 AM, Михаил Монашёв wrote: > Здравствуйте, Anatoly. > >>>>> Раздел "Предпринимательство" выбирается вверху страницы, сразу >>>>> под картинкой, а голосовалка находится внизу. >>>> >>>> "Предпринимательство"? Вебсервер - да, удачный продукт. А >>>> насколько вы успешны в бизнесе - хрен знает. С таким же успехом >>>> можно и в разделе "Музыка" участвовать. :-) > >> Сомневаюсь, что успешный бизнесмен будет с таким негативом >> относиться к одному из самых успешных IT-продуктов и команде, >> которая его создала. Игорь, Максим, Валентин, вы большие молодцы, >> пошел за вас голосовать! > > Да причём здесь отношения или негатив или позитив. Я ж совсем про > другое пишу. Попробую разделить кашу на мух и котлеты. > > Есть вебсервер. Он популярен. Мы всем им пользуемся. А > "предприниматель ≈ это лицо, занимающееся собственным бизнесом, > имеющее своё дело в целях получения прибыли или иной выгоды." Т.е. эта > премия смешивает и два понятия и подменяет одно другим: популярность и > деньги. Талантливый программист (Игорь) написал качественный продукт и, следуя советам, ушел делать свою компанию. Нанял хорошего CEO (Gus Robertson) и продолжает заниматься программированием, техническим менеджментом и остается основателем проекта. По мне, это лучшая success story как программиста и предпринимателя сразу. > > Но популярность и деньги не всегда идут вместе. И одно из другого > автоматически не следует. И голосуют за nginx потому что он популярен, > а не потому, что он приносит владельцам много денег. От того и раздел > "Предпринимательство" подходит для nginx-а меньше, чем "Музыка", > которая в основном nginx-ом в инете и раздаётся, что в отличии от > прибыли nginx-а можно самостоятельно проверить, посмотрев > http-заголовки "музыкальных" сайтов. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Mon Aug 26 16:08:25 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 26 Aug 2013 22:08:25 +0600 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQviDRgNCw0LfQtNCw0YfQtSDRgdGC0LDRgtC40Lo=?= =?UTF-8?B?0Lg=?= In-Reply-To: References: Message-ID: включите кеш на IIS, он неплох. можете посмотреть в сторону ARR. модуль IIS URL Rewrite стоит ? если да, он отключает ядерный кеш (можете посмотреть при помощи Failed request tracing). вообще, есть чудесная книга про всякие IIS-овские штуки: http://www.amazon.com/Ultra-Fast-ASP-NET-4-5-Rick-Kiessig/dp/1430243384 виндовый nginx - скорее исследовательский проект. под высокую нагрузку не приспособленный. 26 августа 2013 г., 19:06 пользователь Kirill Bychkov написал: > Приветствую, > прошу совета. > Сейчас сайт работает под управлением IIS 7.5. Статика раздается с этого же > сервера, но со специально выделенного URL, типа static.example.com > Сам сервер виртуализирован и его данные хранятся на корзине. Сейчас > кэширование не включено на IIS. Стали заметны тормоза в загрузке статики > из-за увеличения нагрузки на корзину. > Будет ли прирост в скорости загрузки, если я перед IIS, на этой же корзине > (в этом же storage массиве) поставлю ngnix в качестве кэширующего > реверсивного прокси-сервера для раздачи статических файлов? > Заранее благодарен. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From kiribool at gmail.com Mon Aug 26 16:18:14 2013 From: kiribool at gmail.com (kiribool) Date: Mon, 26 Aug 2013 20:18:14 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQviDRgNCw0LfQtNCw0YfQtSDRgdGC0LDRgtC40Lo=?= =?UTF-8?B?0Lg=?= In-Reply-To: References: Message-ID: Спасибо за советы. >виндовый nginx - скорее исследовательский проект. под высокую нагрузку >не приспособленный. Как раз тут я имел в виду nginx на linux машине, которую поднять на том же гипервизоре и корзине, что и Windows Server. За книгу отдельное спасибо! 2013/8/26 Илья Шипицин > включите кеш на IIS, он неплох. можете посмотреть в сторону ARR. > модуль IIS URL Rewrite стоит ? если да, он отключает ядерный кеш > (можете посмотреть при помощи Failed request tracing). > > вообще, есть чудесная книга про всякие IIS-овские штуки: > http://www.amazon.com/Ultra-Fast-ASP-NET-4-5-Rick-Kiessig/dp/1430243384 > > виндовый nginx - скорее исследовательский проект. под высокую нагрузку > не приспособленный. > > 26 августа 2013 г., 19:06 пользователь Kirill Bychkov > написал: > > Приветствую, > > прошу совета. > > Сейчас сайт работает под управлением IIS 7.5. Статика раздается с этого > же > > сервера, но со специально выделенного URL, типа static.example.com > > Сам сервер виртуализирован и его данные хранятся на корзине. Сейчас > > кэширование не включено на IIS. Стали заметны тормоза в загрузке статики > > из-за увеличения нагрузки на корзину. > > Будет ли прирост в скорости загрузки, если я перед IIS, на этой же > корзине > > (в этом же storage массиве) поставлю ngnix в качестве кэширующего > > реверсивного прокси-сервера для раздачи статических файлов? > > Заранее благодарен. > > > > _______________________________________________ > > 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 a at gelun.ru Tue Aug 27 07:33:59 2013 From: a at gelun.ru (Gelun, Artem) Date: Tue, 27 Aug 2013 11:33:59 +0400 Subject: =?UTF-8?B?UmU6IEdFTyDQvNC+0LTRg9C70Ywg0Lgg0LrQvtC70LjRh9C10YHRgtCy0L4g0L8=?= =?UTF-8?B?0YDQtdGE0LjQutGB0L7Qsg==?= In-Reply-To: <521B3989.9050603@citrin.ru> References: <521B3989.9050603@citrin.ru> Message-ID: Меньше миллиона )) Интересует как раз при каком кол-ве префиксов начнётся влияние на время ответа. 1000? 10К? 100К? 26 августа 2013 г., 15:18 пользователь Anton Yuzhaninov написал: > On 08/23/13 21:51, Gelun, Artem wrote: > >> Подскажите пожалуйста какое максимальное количество префиксов в GEO-модуле >> допустимо? >> > > Зависит только от объема RAM, но стоит учитывать, что при большом числе > префиксов возрастет нагрузка на CPU (и время ответа). > > Если у вас больше миллиона префиксов, то стоит подумать об уменьшении их > числа. > > ______________________________**_________________ > 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 vadim.lazovskiy at gmail.com Tue Aug 27 08:08:05 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Tue, 27 Aug 2013 12:08:05 +0400 Subject: =?UTF-8?B?UmU6IEdFTyDQvNC+0LTRg9C70Ywg0Lgg0LrQvtC70LjRh9C10YHRgtCy0L4g0L8=?= =?UTF-8?B?0YDQtdGE0LjQutGB0L7Qsg==?= In-Reply-To: References: <521B3989.9050603@citrin.ru> Message-ID: Здравствуйте. У нас 2М (сконверченая geoip база). Памяти жрет много, да, но на скорость ответов практически не влияет. Данные хранятся в radix tree. Поиск по ней не сильно зависит от количества префиксов и имеет прогнозируемое время. Грубо говоря до 32 итераций для адресов /32. 27 августа 2013 г., 11:33 пользователь Gelun, Artem написал: > Меньше миллиона )) > Интересует как раз при каком кол-ве префиксов начнётся влияние на время > ответа. 1000? 10К? 100К? > > > > 26 августа 2013 г., 15:18 пользователь Anton Yuzhaninov написал: > > On 08/23/13 21:51, Gelun, Artem wrote: >> >>> Подскажите пожалуйста какое максимальное количество префиксов в >>> GEO-модуле >>> допустимо? >>> >> >> Зависит только от объема RAM, но стоит учитывать, что при большом числе >> префиксов возрастет нагрузка на CPU (и время ответа). >> >> Если у вас больше миллиона префиксов, то стоит подумать об уменьшении их >> числа. >> >> ______________________________**_________________ >> 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, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at gelun.ru Tue Aug 27 13:19:34 2013 From: a at gelun.ru (Gelun, Artem) Date: Tue, 27 Aug 2013 17:19:34 +0400 Subject: =?UTF-8?B?UmU6IEdFTyDQvNC+0LTRg9C70Ywg0Lgg0LrQvtC70LjRh9C10YHRgtCy0L4g0L8=?= =?UTF-8?B?0YDQtdGE0LjQutGB0L7Qsg==?= In-Reply-To: References: <521B3989.9050603@citrin.ru> Message-ID: Спасибо! 27 августа 2013 г., 12:08 пользователь Vadim Lazovskiy < vadim.lazovskiy at gmail.com> написал: > Здравствуйте. > > У нас 2М (сконверченая geoip база). Памяти жрет много, да, но на скорость > ответов практически не влияет. > Данные хранятся в radix tree. Поиск по ней не сильно зависит от количества > префиксов и имеет прогнозируемое время. > Грубо говоря до 32 итераций для адресов /32. > > > 27 августа 2013 г., 11:33 пользователь Gelun, Artem написал: > > Меньше миллиона )) >> Интересует как раз при каком кол-ве префиксов начнётся влияние на время >> ответа. 1000? 10К? 100К? >> >> >> >> 26 августа 2013 г., 15:18 пользователь Anton Yuzhaninov > > написал: >> >> On 08/23/13 21:51, Gelun, Artem wrote: >>> >>>> Подскажите пожалуйста какое максимальное количество префиксов в >>>> GEO-модуле >>>> допустимо? >>>> >>> >>> Зависит только от объема RAM, но стоит учитывать, что при большом числе >>> префиксов возрастет нагрузка на CPU (и время ответа). >>> >>> Если у вас больше миллиона префиксов, то стоит подумать об уменьшении их >>> числа. >>> >>> ______________________________**_________________ >>> 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, > 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 Tue Aug 27 14:06:19 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 27 Aug 2013 18:06:19 +0400 Subject: nginx-1.5.4 Message-ID: <20130827140618.GY19334@mdounin.ru> Изменения в nginx 1.5.4 27.08.2013 *) Изменение: MIME-тип для расширения js изменён на "application/javascript"; значение по умолчанию директивы charset_types изменено соответственно. *) Изменение: теперь директива image_filter с параметром size возвращает ответ с MIME-типом "application/json". *) Добавление: модуль ngx_http_auth_request_module. *) Исправление: на старте или во время переконфигурации мог произойти segmentation fault, если использовалась директива try_files с пустым параметром. *) Исправление: утечки памяти при использовании в директивах root и auth_basic_user_file относительных путей, заданных с помощью переменных. *) Исправление: директива valid_referers неправильно выполняла регулярные выражения, если заголовок Referer начинался с "https://". Спасибо Liangbin Li. *) Исправление: ответы могли зависать, если использовались подзапросы и при обработке подзапроса происходила ошибка во время SSL handshake с бэкендом. Спасибо Aviram Cohen. *) Исправление: в модуле ngx_http_autoindex_module. *) Исправление: в модуле ngx_http_spdy_module. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Aug 27 14:14:36 2013 From: nginx-forum at nginx.us (incubus) Date: Tue, 27 Aug 2013 10:14:36 -0400 Subject: =?UTF-8?Q?Re=3A_upstream_=D0=B8_Host_header?= In-Reply-To: <201308261541.33296.vbart@nginx.com> References: <201308261541.33296.vbart@nginx.com> Message-ID: <4e4748f29857651753ab780f3065b772.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > Вы бы рассказали, какую задачу решаете. А то окажется, что вам не > блок upstream > нужен (который предполагает, что это группа серверов отдающих один и > тот же > ресурс), а split_clients. Необходимо проксировать доступ к группе серверов, которые отдают статический контент. Серверов около 10 штук, все они отдают одинаковый контент, но каждый требует свой Host. Мне кажется, что upstream прекрасно для этого подходит (особенно в случае проблем с частью серверов), вот еще бы с уникальным Host проблем не было бы. :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242169,242254#msg-242254 From petr at petrovich.kiev.ua Tue Aug 27 14:35:22 2013 From: petr at petrovich.kiev.ua (Serge Negodyuck) Date: Tue, 27 Aug 2013 17:35:22 +0300 Subject: =?UTF-8?B?TmdpbnggcmVsb2FkLCDQstGL0LXQtNCw0LXRgiBDUFU=?= Message-ID: Как только я посылаю nginx сигнал HUP (или nginx -s reload), процессы в состоянии "nginx: worker process is shutting down (nginx)" начинают кушать весь доступный процессор. Если подсоединиться к такому процессу отладчиком: (gdb) bt #0 0x0000000801656d5c in kevent () from /lib/libc.so.7 #1 0x00000000004370c0 in ngx_kqueue_process_events (cycle=0x801cf5050, timer=18446744073709551615, flags=0) at src/event/modules/ngx_kqueue_module.c:537 #2 0x000000000042923c in ngx_process_events_and_timers (cycle=0x801cf5050) at src/event/ngx_event.c:249 #3 0x00000000004342e3 in ngx_worker_process_cycle (cycle=0x801cf5050, data=0x2) at src/os/unix/ngx_process_cycle.c:807 #4 0x0000000000431879 in ngx_spawn_process (cycle=0x801cf5050, proc=0x434180 , data=0x2, name=0x4b7dd3 "worker process", respawn=-3) at src/os/unix/ngx_process.c:198 #5 0x0000000000433576 in ngx_start_worker_processes (cycle=0x801cf5050, n=8, type=-3) at src/os/unix/ngx_process_cycle.c:362 #6 0x0000000000432d79 in ngx_master_process_cycle (cycle=0x801cf5050) at src/os/unix/ngx_process_cycle.c:136 #7 0x0000000000406ac3 in main (argc=1, argv=0x7fffffffdda8) at src/core/nginx.c:412 (gdb) backtrace full #0 0x0000000801656d5c in kevent () from /lib/libc.so.7 No symbol table info available. #1 0x00000000004370c0 in ngx_kqueue_process_events (cycle=0x801cf5050, timer=18446744073709551615, flags=0) at src/event/modules/ngx_kqueue_module.c:537 events = 7227840 n = 0 i = 34426922320 instance = 140737488345392 level = 4370853 err = 0 ev = (ngx_event_t *) 0x804012550 queue = (ngx_event_t **) 0x804012a90 ts = {tv_sec = 35128236032, tv_nsec = 0} tp = (struct timespec *) 0x0 #2 0x000000000042923c in ngx_process_events_and_timers (cycle=0x801cf5050) at src/event/ngx_event.c:249 flags = 0 timer = 18446744073709551615 delta = 1377613229768 #3 0x00000000004342e3 in ngx_worker_process_cycle (cycle=0x801cf5050, data=0x2) at src/os/unix/ngx_process_cycle.c:807 worker = 2 i = 32768 c = (ngx_connection_t *) 0x82d000000 #4 0x0000000000431879 in ngx_spawn_process (cycle=0x801cf5050, proc=0x434180 , data=0x2, name=0x4b7dd3 "worker process", respawn=-3) at src/os/unix/ngx_process.c:198 on = 1 pid = 0 s = 2 #5 0x0000000000433576 in ngx_start_worker_processes (cycle=0x801cf5050, n=8, type=-3) at src/os/unix/ngx_process_cycle.c:362 i = 2 ch = {command = 1, pid = 78739, slot = 1, fd = 49} ---Type to continue, or q to quit--- #6 0x0000000000432d79 in ngx_master_process_cycle (cycle=0x801cf5050) at src/os/unix/ngx_process_cycle.c:136 title = 0x803fb6fac "master process /usr/local/sbin/nginx" p = (u_char *) 0x803fb6fd0 "" size = 37 i = 1 n = 4 sigio = 2 set = {__bits = {0, 0, 0, 0}} itv = {it_interval = {tv_sec = 0, tv_usec = 34367014912}, it_value = {tv_sec = 1, tv_usec = 140737488346448}} live = 34383286796 delay = 6 ls = (ngx_listening_t *) 0x801cf52b0 ccf = (ngx_core_conf_t *) 0x801cf5a50 #7 0x0000000000406ac3 in main (argc=1, argv=0x7fffffffdda8) at src/core/nginx.c:412 i = 53 log = (ngx_log_t *) 0x6e27c0 cycle = (ngx_cycle_t *) 0x801cf5050 init_cycle = {conf_ctx = 0x0, pool = 0x801c07c00, log = 0x6e27c0, new_log = {log_level = 0, file = 0x0, connection = 0, handler = 0, data = 0x0, action = 0x0}, files = 0x0, free_connections = 0x0, free_connection_n = 0, reusable_connections_queue = {prev = 0x0, next = 0x0}, listening = {elts = 0x801c59600, nelts = 3, size = 216, nalloc = 10, pool = 0x801c07c00}, paths = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, open_files = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, shared_memory = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, connection_n = 0, files_n = 0, connections = 0x0, read_events = 0x0, write_events = 0x0, old_cycle = 0x0, conf_file = {len = 31, data = 0x4b4ca0 "/usr/local/etc/nginx/nginx.conf"}, conf_param = {len = 0, data = 0x0}, conf_prefix = {len = 21, data = 0x4b4ca0 "/usr/local/etc/nginx/nginx.conf"}, prefix = {len = 21, data = 0x4b4c88 "/usr/local/etc/nginx/"}, lock_file = {len = 0, data = 0x0}, hostname = {len = 0, data = 0x0}} ccf = (ngx_core_conf_t *) 0x801cf5a50 FreeBSD 9.1-RELEASE-p4 amd64 nginx 1.4.2 Как мне кажется, проблема появилась после включения websockets. proxy_pass http://push; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; keepalive_timeout 1d; proxy_read_timeout 1d; На linux с epoll такая же проблема, (стектрейса пока нету, если надо могу попытаться получить) From mdounin at mdounin.ru Tue Aug 27 15:47:30 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 27 Aug 2013 19:47:30 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: References: Message-ID: <20130827154730.GC19334@mdounin.ru> Hello! On Tue, Aug 27, 2013 at 05:35:22PM +0300, Serge Negodyuck wrote: > Как только я посылаю nginx сигнал HUP (или nginx -s reload), процессы > в состоянии "nginx: worker process is shutting down (nginx)" начинают > кушать весь доступный процессор. > > Если подсоединиться к такому процессу отладчиком: > (gdb) bt > #0 0x0000000801656d5c in kevent () from /lib/libc.so.7 > #1 0x00000000004370c0 in ngx_kqueue_process_events (cycle=0x801cf5050, > timer=18446744073709551615, flags=0) at > src/event/modules/ngx_kqueue_module.c:537 Судя по backtrace'у, nginx честно ждёт новых собитий в ядре. Возможно, "кушать процессор" - это побочный эффект от нехватки ресурсов из-за большого количества завершающихся процессов? Имеет смысл либо походить по коду в gdb, либо посмотреть на картину с помощью ktrace + kdump -T. Ну и на банальный top тоже имеет смысл посмотреть внимательно. Note: рабочие процессы завершаются только тогда, когда закончена обработка всех запросов. Соответственно долгоживующие запросы a la проксирование websocket'ов - могут долго препятствовать завершению рабочих процессов, тем самым приводя к их накоплению. -- Maxim Dounin http://nginx.org/en/donation.html From postmaster at softsearch.ru Tue Aug 27 16:29:21 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 27 Aug 2013 20:29:21 +0400 Subject: nginx-1.5.4 In-Reply-To: <20130827140618.GY19334@mdounin.ru> References: <20130827140618.GY19334@mdounin.ru> Message-ID: <474789980.20130827202921@softsearch.ru> Здравствуйте, Maxim. > *) Изменение: теперь директива image_filter с параметром size > возвращает ответ с MIME-типом "application/json". Не касабельно релиза. А просто вспомнилось. В документации для image_filter для resize написано неверное слово "уменьшает". Если я правильно понимаю, то resize может и увеличивать, если ему передано изображение меньше, чем указано после resize. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Tue Aug 27 16:35:16 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 27 Aug 2013 20:35:16 +0400 Subject: nginx-1.5.4 In-Reply-To: <474789980.20130827202921@softsearch.ru> References: <20130827140618.GY19334@mdounin.ru> <474789980.20130827202921@softsearch.ru> Message-ID: <20130827163515.GG19334@mdounin.ru> Hello! On Tue, Aug 27, 2013 at 08:29:21PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > > *) Изменение: теперь директива image_filter с параметром size > > возвращает ответ с MIME-типом "application/json". > > Не касабельно релиза. А просто вспомнилось. > > В документации для image_filter для resize написано неверное слово > "уменьшает". Если я правильно понимаю, то resize может и увеличивать, > если ему передано изображение меньше, чем указано после resize. Если изобразение меньше, то оно пропускается без изменений. С увеличением размера - гораздо лучше справляются браузеры. -- Maxim Dounin http://nginx.org/en/donation.html From serg at petrovich.kiev.ua Tue Aug 27 17:27:47 2013 From: serg at petrovich.kiev.ua (Serge Negodyuck) Date: Tue, 27 Aug 2013 20:27:47 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: <20130827154730.GC19334@mdounin.ru> References: <20130827154730.GC19334@mdounin.ru> Message-ID: 27 августа 2013 г., 18:47 пользователь Maxim Dounin написал: > Hello! > > > Судя по backtrace'у, nginx честно ждёт новых собитий в ядре. > Возможно, "кушать процессор" - это побочный эффект от нехватки > ресурсов из-за большого количества завершающихся процессов? Штатно, 4 ядра, гипертрединг выключен, 8 процессов nginx. Нагрузка на CPU до 30% (суммарно по всем 8 процессов, т.е до 4% каждый). Как только даешь сигнал HUP, воркеров становится 16. 8 умирающих процессов в течении 10 секунд плавно набирают CPU usage до максимума ресурсов Держатся в таком состоянии столь угодно долго - 3 часа точно могут висеть. Видео для наглядности http://ascii.io/a/5172 > > Имеет смысл либо походить по коду в gdb, либо посмотреть на > картину с помощью ktrace + kdump -T. Ну и на банальный top тоже > имеет смысл посмотреть внимательно. Ок, попробую нарыть больше информации для диагностики. И воспроизвести в минимальной конфигурации. > > Note: рабочие процессы завершаются только тогда, когда закончена > обработка всех запросов. Соответственно долгоживующие запросы a > la проксирование websocket'ов - могут долго препятствовать > завершению рабочих процессов, тем самым приводя к их накоплению. Да, вполне устраивает что старые процессы могут жить еще сутки. Но при этом, по идее, старые воркеры должны со временем потреблять все меньше и меньше процессора. Но, не наоборот. From serg at petrovich.kiev.ua Tue Aug 27 18:45:21 2013 From: serg at petrovich.kiev.ua (Serge Negodyuck) Date: Tue, 27 Aug 2013 21:45:21 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: References: <20130827154730.GC19334@mdounin.ru> Message-ID: >> Имеет смысл либо походить по коду в gdb, либо посмотреть на >> картину с помощью ktrace + kdump -T. Ну и на банальный top тоже >> имеет смысл посмотреть внимательно. > > Ок, попробую нарыть больше информации для диагностики. И воспроизвести > в минимальной конфигурации. Поигравшись с "while true; do gdb66 -ex "backtrace full" --batch -p 41159; done" получилось, что бОльшую часть времени эти процессы проводят в состоянии: " if (c[i].fd != -1 && c[i].idle) {": 0x0000000000434202 in ngx_worker_process_cycle (cycle=0x801cf9050, data=0x3) at src/os/unix/ngx_process_cycle.c:791 791 if (c[i].fd != -1 && c[i].idle) { #0 0x0000000000434202 in ngx_worker_process_cycle (cycle=0x801cf9050, data=0x3) at src/os/unix/ngx_process_cycle.c:791 worker = 3 i = 29890 c = (ngx_connection_t *) 0x82d800000 #1 0x0000000000431879 in ngx_spawn_process (cycle=0x801cf9050, proc=0x434180 , data=0x3, name=0x4b7dd3 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198 on = 1 pid = 0 s = 12 #2 0x0000000000433576 in ngx_start_worker_processes (cycle=0x801cf9050, n=8, type=-4) at src/os/unix/ngx_process_cycle.c:362 i = 3 ch = {command = 1, pid = 41158, slot = 11, fd = 25} #3 0x0000000000433189 in ngx_master_process_cycle (cycle=0x801cf9050) at src/os/unix/ngx_process_cycle.c:249 title = 0x803fb6fac "" p = (u_char *) 0x803fb6fd0 "hP▒\001\b" size = 37 i = 1 n = 4 sigio = 0 set = {__bits = {0, 0, 0, 0}} itv = {it_interval = {tv_sec = 0, tv_usec = 34367014912}, it_value = {tv_sec = 1, tv_usec = 140737488346448}} live = 1 delay = 0 ls = (ngx_listening_t *) 0x801cf52b0 ccf = (ngx_core_conf_t *) 0x801cf9e68 #4 0x0000000000406ac3 in main (argc=1, argv=0x7fffffffdda8) at src/core/nginx.c:412 i = 53 log = (ngx_log_t *) 0x6e27c0 cycle = (ngx_cycle_t *) 0x801cf5050 init_cycle = {conf_ctx = 0x0, pool = 0x801c07c00, log = 0x6e27c0, new_log = {log_level = 0, file = 0x0, connection = 0, handler = 0, data = 0x0, action = 0x0}, files = 0x0, free_connections = 0x0, free_connection_n = 0, reusable_connections_queue = {prev = 0x0, next = 0x0}, listening = {elts = 0x801c59600, nelts = 3, size = 216, nalloc = 10, pool = 0x801c07c00}, paths = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, open_files = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, shared_memory = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, connection_n = 0, files_n = 0, connections = 0x0, read_events = 0x0, write_events = 0x0, old_cycle = 0x0, conf_file = {len = 31, data = 0x4b4ca0 "/usr/local/etc/nginx/nginx.conf"}, conf_param = {len = 0, data = 0x0}, conf_prefix = {len = 21, data = 0x4b4ca0 "/usr/local/etc/nginx/nginx.conf"}, prefix = {len = 21, data = 0x4b4c88 "/usr/local/etc/nginx/"}, lock_file = {len = 0, data = 0x0}, hostname = {len = 0, data = 0x0}} ccf = (ngx_core_conf_t *) 0x801cf5a50 From serg at petrovich.kiev.ua Tue Aug 27 19:59:25 2013 From: serg at petrovich.kiev.ua (Serge Negodyuck) Date: Tue, 27 Aug 2013 22:59:25 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: References: <20130827154730.GC19334@mdounin.ru> Message-ID: 2013/8/27 Serge Negodyuck : >>> Имеет смысл либо походить по коду в gdb, либо посмотреть на >>> картину с помощью ktrace + kdump -T. Ну и на банальный top тоже >>> имеет смысл посмотреть внимательно. >> >> Ок, попробую нарыть больше информации для диагностики. И воспроизвести >> в минимальной конфигурации. > > Поигравшись с "while true; do gdb66 -ex "backtrace full" --batch -p > 41159; done" > получилось, что бОльшую часть времени эти процессы проводят в > состоянии: " if (c[i].fd != -1 && c[i].idle) {": Добавление usleep(1) решило все проблемы: --- ngx_process_cycle.c.orig 2013-08-27 22:42:36.000000000 +0300 +++ ngx_process_cycle.c 2013-08-27 22:42:46.000000000 +0300 @@ -792,6 +792,7 @@ c[i].close = 1; c[i].read->handler(c[i].read); } + usleep(1); } if (ngx_event_timer_rbtree.root == ngx_event_timer_rbtree.sentinel) IMHO, как-то грязновато. Может можно как-то по событиям? Или вынести цикл по дескрипторам соединений в отдельный поток. В любом случаю, надеюсь, авторы nginx подумают над этим куском кода к ближайшему релизу. IMHO, причина: появление вебсокетов, и необходимость увеличения proxy_read_timeout вкупе с увеличением числов конектов. From mdounin at mdounin.ru Tue Aug 27 21:38:22 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 28 Aug 2013 01:38:22 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: References: <20130827154730.GC19334@mdounin.ru> Message-ID: <20130827213822.GA2748@mdounin.ru> Hello! On Tue, Aug 27, 2013 at 10:59:25PM +0300, Serge Negodyuck wrote: > 2013/8/27 Serge Negodyuck : > >>> Имеет смысл либо походить по коду в gdb, либо посмотреть на > >>> картину с помощью ktrace + kdump -T. Ну и на банальный top тоже > >>> имеет смысл посмотреть внимательно. > >> > >> Ок, попробую нарыть больше информации для диагностики. И воспроизвести > >> в минимальной конфигурации. > > > > Поигравшись с "while true; do gdb66 -ex "backtrace full" --batch -p > > 41159; done" > > получилось, что бОльшую часть времени эти процессы проводят в > > состоянии: " if (c[i].fd != -1 && c[i].idle) {": > > Добавление usleep(1) решило все проблемы: > > --- ngx_process_cycle.c.orig 2013-08-27 22:42:36.000000000 +0300 > +++ ngx_process_cycle.c 2013-08-27 22:42:46.000000000 +0300 > @@ -792,6 +792,7 @@ > c[i].close = 1; > c[i].read->handler(c[i].read); > } > + usleep(1); > } > > if (ngx_event_timer_rbtree.root == ngx_event_timer_rbtree.sentinel) > > > IMHO, как-то грязновато. Может можно как-то по событиям? Или вынести > цикл по дескрипторам соединений в отдельный поток. Этот цикл - занимается закрытием idle-соединений, и выполняется только при получении из ядра каких-либо событий (i.e. - редко). Если время теряется в нём - это как бы намекает, что в ядре nginx почему-то не остаётся, а сразу возвращается обратно. В этом и есть настоящая проблема. Было бы интересно посмотреть на nginx -V (интересует, в первую очередь, отсутствие сторонних модулей/патчей), полный конфиг и debug log. Ссылка на всякий случай: http://nginx.org/ru/docs/debugging_log.html > В любом случаю, надеюсь, авторы nginx подумают над этим куском кода к > ближайшему релизу. IMHO, причина: появление вебсокетов, и > необходимость увеличения proxy_read_timeout вкупе с увеличением числов > конектов. Сам по себе этот кусок кода, конечно, можно слегка пооптимизировать, но проблема где-то в другом месте. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Aug 28 00:49:04 2013 From: nginx-forum at nginx.us (shtein) Date: Tue, 27 Aug 2013 20:49:04 -0400 Subject: =?UTF-8?B?TmdpbnggMS40LjIgKyBNb2Qgc2VjdXJpdHkgMi43LjUgKyBBcGFjaGUgMi4yLjIy?= =?UTF-8?B?IC0g0J/RgNC+0LHQu9C10LzRiyDRgSDQutC+0LTQuNGA0L7QstC60L7QuS4=?= Message-ID: Добрый день. Имеем Debian 7, Apache 2.2.22 с mod_perl в качестве бэкэнда, Nginx 1.4.2 в качестве фронтенда. Всё отлично работало, пока в один прекрасный момент не решили поставить modsecurity for nginx. Поставил свежую версию, поставил типовой конфиг modsecurity с сайта modsecurity. И начались переодические проблемы с кодировкой. Кодировка сайта - cp1251. При обновлении одной и той же страницы, один раз из 5 она может начать отображаться кракозябрами. В логах nginx проскакивают сообщения вида: "ModSecurity: Audit log: Failed to lock global mutex: Permission denied", но по времени не совпадают с ошибками кодировки. В modSecurity пытался указывать SecUnicodeCodePage 1251 - толка нет. Не подскажите в какую сторону копать, где искать корни проблемы? Буду рад любой помощи. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242278,242278#msg-242278 From nginx-forum at nginx.us Wed Aug 28 07:20:18 2013 From: nginx-forum at nginx.us (skeletor) Date: Wed, 28 Aug 2013 03:20:18 -0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?= =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?= =?UTF-8?B?0Lku?= In-Reply-To: References: Message-ID: Укажите так же кодировку и в конфиге nginx'а для вашего localtion'a Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242278,242283#msg-242283 From nginx-forum at nginx.us Wed Aug 28 08:01:19 2013 From: nginx-forum at nginx.us (Mas73r) Date: Wed, 28 Aug 2013 04:01:19 -0400 Subject: =?UTF-8?B?Tmdpbngg0LrQsNC6INCw0LrQutGD0LzRg9C70LjRgNGD0Y7RidC40Lkg0L/RgNC+?= =?UTF-8?B?0LrRgdC4?= Message-ID: <09df3da4f4618898022d336d5977481c.NginxMailingListRussian@forum.nginx.org> Добрый день! Интересует факт возможности создания аккумулирующего прокси на базе Nginx. Есть сервер, который периодически виснет. Необходим прокси который принимал запросы и не рвал соединение (с большим таймаутом) и по факту поднятия виснущего сервера выполнял запросы на нем и возвращал результат. Запросы идут от php-скрипта. Смысл данного прокси -- накопление коннектов от скрипта, и обработка запросов от этого скрипта после поднятия сервера. Пробовал сделать каскадную обработку 502 -- зациклить не получается. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242284,242284#msg-242284 From dbmelnikov at gmail.com Wed Aug 28 14:20:28 2013 From: dbmelnikov at gmail.com (Denis Melnikov) Date: Wed, 28 Aug 2013 18:20:28 +0400 Subject: =?UTF-8?B?0JrQsNC6INGA0LDRgdGB0YfQuNGC0LDRgtGMINGA0LDQt9C80LXRgCDQtNC70Y8g?= =?UTF-8?B?bGltaXRfcmVxX3pvbmU/?= Message-ID: Привет! Какой будет размер ключа, если размер переменной 32 байта? Что случится, если хранилище переполнится: 503 или старые ключи вытесняются? Правильно я понимаю, что для limit_conn_zone действуют те же правила? Денис -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Aug 28 14:57:18 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 28 Aug 2013 18:57:18 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHRgdGH0LjRgtCw0YLRjCDRgNCw0LfQvNC10YAg0LQ=?= =?UTF-8?B?0LvRjyBsaW1pdF9yZXFfem9uZT8=?= In-Reply-To: References: Message-ID: <20130828145717.GG8272@mdounin.ru> Hello! On Wed, Aug 28, 2013 at 06:20:28PM +0400, Denis Melnikov wrote: > Привет! > Какой будет размер ключа, если размер переменной 32 байта? На 32-битных платформах - 64 байта (27 байт + размер переменной, и округляем вверх до ближайшей степени двойки), на 64-битных - 128 байт. > Что случится, если хранилище переполнится: 503 или старые ключи вытесняются? > Правильно я понимаю, что для limit_conn_zone действуют те же правила? Для limit_req - старые ключи вытесняются. Для limit_conn - возвращается 503, т.к. "старых" ключей нет, все ключи - относятся к установленным в настоящий момент соединениям. -- Maxim Dounin http://nginx.org/en/donation.html From serg at petrovich.kiev.ua Wed Aug 28 15:16:42 2013 From: serg at petrovich.kiev.ua (Serge Negodyuck) Date: Wed, 28 Aug 2013 18:16:42 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: <20130827213822.GA2748@mdounin.ru> References: <20130827154730.GC19334@mdounin.ru> <20130827213822.GA2748@mdounin.ru> Message-ID: 28 августа 2013 г., 0:38 пользователь Maxim Dounin написал: > Hello! > > On Tue, Aug 27, 2013 at 10:59:25PM +0300, Serge Negodyuck wrote: > > >> > Поигравшись с "while true; do gdb66 -ex "backtrace full" --batch -p >> > 41159; done" >> > получилось, что бОльшую часть времени эти процессы проводят в >> > состоянии: " if (c[i].fd != -1 && c[i].idle) {": >> >> Добавление usleep(1) решило все проблемы: >> >> --- ngx_process_cycle.c.orig 2013-08-27 22:42:36.000000000 +0300 >> +++ ngx_process_cycle.c 2013-08-27 22:42:46.000000000 +0300 >> @@ -792,6 +792,7 @@ >> c[i].close = 1; >> c[i].read->handler(c[i].read); >> } >> + usleep(1); >> } >> >> if (ngx_event_timer_rbtree.root == ngx_event_timer_rbtree.sentinel) >> >> >> IMHO, как-то грязновато. Может можно как-то по событиям? Или вынести >> цикл по дескрипторам соединений в отдельный поток. > > Этот цикл - занимается закрытием idle-соединений, и выполняется > только при получении из ядра каких-либо событий (i.e. - редко). > Если время теряется в нём - это как бы намекает, что в ядре nginx > почему-то не остаётся, а сразу возвращается обратно. В этом и > есть настоящая проблема. > > Было бы интересно посмотреть на nginx -V (интересует, в первую > очередь, отсутствие сторонних модулей/патчей), полный конфиг и > debug log. Ссылка на всякий случай: > > http://nginx.org/ru/docs/debugging_log.html # nginx -V nginx version: nginx/1.4.2 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_dav_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-pcre --add-module=/usr/ports/www/nginx/work/gabor-nginx-x-rid-header-0daa3cc --with-http_ssl_module nginx-x-rid-header вряд ли тут при чем. Он участвует только при новом запросе. Урезаная версия конфига в атаче (Убрана большая часть локейшинов, и виртуальных хостов с похожим конфигом на разных ip адресах около 10.) В дебаг логе ничего - только события от таймера 2013/08/28 16:14:10 [debug] 27687#0: posted events 0000000000000000 2013/08/28 16:14:10 [debug] 27687#0: worker cycle 2013/08/28 16:14:10 [debug] 27687#0: kevent timer: -1, changes: 0 2013/08/28 16:14:10 [debug] 27687#0: kevent events: 1 2013/08/28 16:14:10 [debug] 27687#0: kevent: 0: ft:-7 fl:0020 ff:00000000 d:1 ud:0000000000000000 2013/08/28 16:14:10 [debug] 27687#0: timer delta: 2 2013/08/28 16:14:10 [debug] 27687#0: posted events 0000000000000000 2013/08/28 16:14:10 [debug] 27687#0: worker cycle 2013/08/28 16:14:10 [debug] 27687#0: kevent timer: -1, changes: 0 2013/08/28 16:14:10 [debug] 27687#0: kevent events: 1 2013/08/28 16:14:10 [debug] 27687#0: kevent: 0: ft:-7 fl:0020 ff:00000000 d:1 ud:0000000000000000 2013/08/28 16:14:10 [debug] 27687#0: timer delta: 1 2013/08/28 16:14:10 [debug] 27687#0: posted events 0000000000000000 2013/08/28 16:14:10 [debug] 27687#0: worker cycle 2013/08/28 16:14:10 [debug] 27687#0: kevent timer: -1, changes: 0 2013/08/28 16:14:10 [debug] 27687#0: kevent events: 1 2013/08/28 16:14:10 [debug] 27687#0: kevent: 0: ft:-7 fl:0020 ff:00000000 d:1 ud:0000000000000000 2013/08/28 16:14:10 [debug] 27687#0: timer delta: 2 Cобытий таймера порядка 600-700 в секунду. Я так понимаю, при timer_resolution 1ms их должно быть около 1000. Значит, что-то мешает таймеру выполняться. И я, всё же, думаю что это тот цикл по соединениям. Соединений на воркер у меня 32000, таймер работает 1000 раз в секунду. Т.е. в секунду процессор должен делать 32 миллиона итераций по циклу. Не знаю, много это или мало. Думаю, прилично. -------------- next part -------------- A non-text attachment was scrubbed... Name: nginx.conf Type: application/octet-stream Size: 3377 bytes Desc: not available URL: From mdounin at mdounin.ru Wed Aug 28 15:41:36 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 28 Aug 2013 19:41:36 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: References: <20130827154730.GC19334@mdounin.ru> <20130827213822.GA2748@mdounin.ru> Message-ID: <20130828154136.GI8272@mdounin.ru> Hello! On Wed, Aug 28, 2013 at 06:16:42PM +0300, Serge Negodyuck wrote: > 28 августа 2013 г., 0:38 пользователь Maxim Dounin написал: > > Hello! > > > > On Tue, Aug 27, 2013 at 10:59:25PM +0300, Serge Negodyuck wrote: > > > > >> > Поигравшись с "while true; do gdb66 -ex "backtrace full" --batch -p > >> > 41159; done" > >> > получилось, что бОльшую часть времени эти процессы проводят в > >> > состоянии: " if (c[i].fd != -1 && c[i].idle) {": > >> > >> Добавление usleep(1) решило все проблемы: > >> > >> --- ngx_process_cycle.c.orig 2013-08-27 22:42:36.000000000 +0300 > >> +++ ngx_process_cycle.c 2013-08-27 22:42:46.000000000 +0300 > >> @@ -792,6 +792,7 @@ > >> c[i].close = 1; > >> c[i].read->handler(c[i].read); > >> } > >> + usleep(1); > >> } > >> > >> if (ngx_event_timer_rbtree.root == ngx_event_timer_rbtree.sentinel) > >> > >> > >> IMHO, как-то грязновато. Может можно как-то по событиям? Или вынести > >> цикл по дескрипторам соединений в отдельный поток. > > > > Этот цикл - занимается закрытием idle-соединений, и выполняется > > только при получении из ядра каких-либо событий (i.e. - редко). > > Если время теряется в нём - это как бы намекает, что в ядре nginx > > почему-то не остаётся, а сразу возвращается обратно. В этом и > > есть настоящая проблема. > > > > Было бы интересно посмотреть на nginx -V (интересует, в первую > > очередь, отсутствие сторонних модулей/патчей), полный конфиг и > > debug log. Ссылка на всякий случай: > > > > http://nginx.org/ru/docs/debugging_log.html > > # nginx -V > nginx version: nginx/1.4.2 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx-error.log --user=www --group=www > --with-debug --with-file-aio > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx-access.log --with-http_dav_module > --with-http_gzip_static_module --with-http_realip_module > --with-http_stub_status_module --with-pcre > --add-module=/usr/ports/www/nginx/work/gabor-nginx-x-rid-header-0daa3cc > --with-http_ssl_module > > nginx-x-rid-header вряд ли тут при чем. Он участвует только при новом запросе. > > Урезаная версия конфига в атаче (Убрана большая часть локейшинов, и > виртуальных хостов с похожим конфигом на разных ip адресах около 10.) > > В дебаг логе ничего - только события от таймера > > 2013/08/28 16:14:10 [debug] 27687#0: posted events 0000000000000000 > 2013/08/28 16:14:10 [debug] 27687#0: worker cycle > 2013/08/28 16:14:10 [debug] 27687#0: kevent timer: -1, changes: 0 > 2013/08/28 16:14:10 [debug] 27687#0: kevent events: 1 > 2013/08/28 16:14:10 [debug] 27687#0: kevent: 0: ft:-7 fl:0020 > ff:00000000 d:1 ud:0000000000000000 > 2013/08/28 16:14:10 [debug] 27687#0: timer delta: 2 > 2013/08/28 16:14:10 [debug] 27687#0: posted events 0000000000000000 > 2013/08/28 16:14:10 [debug] 27687#0: worker cycle > 2013/08/28 16:14:10 [debug] 27687#0: kevent timer: -1, changes: 0 > 2013/08/28 16:14:10 [debug] 27687#0: kevent events: 1 > 2013/08/28 16:14:10 [debug] 27687#0: kevent: 0: ft:-7 fl:0020 > ff:00000000 d:1 ud:0000000000000000 > 2013/08/28 16:14:10 [debug] 27687#0: timer delta: 1 > 2013/08/28 16:14:10 [debug] 27687#0: posted events 0000000000000000 > 2013/08/28 16:14:10 [debug] 27687#0: worker cycle > 2013/08/28 16:14:10 [debug] 27687#0: kevent timer: -1, changes: 0 > 2013/08/28 16:14:10 [debug] 27687#0: kevent events: 1 > 2013/08/28 16:14:10 [debug] 27687#0: kevent: 0: ft:-7 fl:0020 > ff:00000000 d:1 ud:0000000000000000 > 2013/08/28 16:14:10 [debug] 27687#0: timer delta: 2 > > Cобытий таймера порядка 600-700 в секунду. Я так понимаю, при > timer_resolution 1ms их должно быть около 1000. Значит, что-то мешает > таймеру выполняться. > > И я, всё же, думаю что это тот цикл по соединениям. > Соединений на воркер у меня 32000, таймер работает 1000 раз в секунду. > Т.е. в секунду процессор должен делать 32 миллиона итераций по циклу. > Не знаю, много это или мало. Думаю, прилично. Ну таки да, timer_resolution 1ms + worker_connections 32000 поведение объясняют. Простейшее решение - выпилить из конфига timer_resolution и/или поднять до каких-нибудь более разумных 100ms. -- Maxim Dounin http://nginx.org/en/donation.html From serg at petrovich.kiev.ua Wed Aug 28 17:39:38 2013 From: serg at petrovich.kiev.ua (Serge Negodyuck) Date: Wed, 28 Aug 2013 20:39:38 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: <20130828154136.GI8272@mdounin.ru> References: <20130827154730.GC19334@mdounin.ru> <20130827213822.GA2748@mdounin.ru> <20130828154136.GI8272@mdounin.ru> Message-ID: 28 августа 2013 г., 18:41 пользователь Maxim Dounin написал: > > Ну таки да, timer_resolution 1ms + worker_connections 32000 > поведение объясняют. Простейшее решение - выпилить из конфига > timer_resolution и/или поднять до каких-нибудь более разумных > 100ms. > Если бы timer_resolution не влиял на $upstream_response_time (который нужен в логах, с довольно большой точностью, чтобы иметь статистику по бекендам), то да. Но, в общем, для меня решение уже видно: патчить цикл по дескрипторам, чтобы он выполнялся не чаще, чем 5 раз в секунду. А, в идеале, частота должна зависеть от worker_connections. Спасибо за помощь! From mdounin at mdounin.ru Wed Aug 28 18:05:08 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 28 Aug 2013 22:05:08 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: References: <20130827154730.GC19334@mdounin.ru> <20130827213822.GA2748@mdounin.ru> <20130828154136.GI8272@mdounin.ru> Message-ID: <20130828180508.GL8272@mdounin.ru> Hello! On Wed, Aug 28, 2013 at 08:39:38PM +0300, Serge Negodyuck wrote: > 28 августа 2013 г., 18:41 пользователь Maxim Dounin > написал: > > > > > Ну таки да, timer_resolution 1ms + worker_connections 32000 > > поведение объясняют. Простейшее решение - выпилить из конфига > > timer_resolution и/или поднять до каких-нибудь более разумных > > 100ms. > > > Если бы timer_resolution не влиял на $upstream_response_time (который > нужен в логах, с довольно большой точностью, чтобы иметь статистику по > бекендам), то да. Таки он и не влияет - timer_resolution предназначен для загрубления точности, а не улучшения. Если нужна высокая точность - просто уберите директиву timer_resolution из конфига (или поставьте в 0, что суть то же самое). > Но, в общем, для меня решение уже видно: патчить цикл по дескрипторам, > чтобы он выполнялся не чаще, чем 5 раз в секунду. А, в идеале, частота > должна зависеть от worker_connections. В идеале - этот цикл должен выполняться единожды при выставлении ngx_exiting, а дальше соединения должны проверять ngx_exiting при переходе в idle. Но это не простейшее решение. -- Maxim Dounin http://nginx.org/en/donation.html From serg at petrovich.kiev.ua Wed Aug 28 18:22:14 2013 From: serg at petrovich.kiev.ua (Serge Negodyuck) Date: Wed, 28 Aug 2013 21:22:14 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: <20130828180508.GL8272@mdounin.ru> References: <20130827154730.GC19334@mdounin.ru> <20130827213822.GA2748@mdounin.ru> <20130828154136.GI8272@mdounin.ru> <20130828180508.GL8272@mdounin.ru> Message-ID: 28 августа 2013 г., 21:05 пользователь Maxim Dounin написал: > Hello! > > On Wed, Aug 28, 2013 at 08:39:38PM +0300, Serge Negodyuck wrote: > >> 28 августа 2013 г., 18:41 пользователь Maxim Dounin >> написал: >> >> > >> > Ну таки да, timer_resolution 1ms + worker_connections 32000 >> > поведение объясняют. Простейшее решение - выпилить из конфига >> > timer_resolution и/или поднять до каких-нибудь более разумных >> > 100ms. >> > >> Если бы timer_resolution не влиял на $upstream_response_time (который >> нужен в логах, с довольно большой точностью, чтобы иметь статистику по >> бекендам), то да. > > Таки он и не влияет - timer_resolution предназначен для > загрубления точности, а не улучшения. > > Если нужна высокая точность - просто уберите директиву > timer_resolution из конфига (или поставьте в 0, что суть то же > самое). Да уж, несколько дней убил, а всё по незнанию того, что можно просто убрать timer_resolution. Зато немного разобрался в том, как nginx обрабатывает запросы. Еще раз, спасибо! P.S. Хотя, несколько тысяч живущих вебсокетов, каждый из которых, раз в секунду обновляет данные (и создает при этом kevent, да?) - вполне возможная ситуация. From mdounin at mdounin.ru Wed Aug 28 18:48:04 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 28 Aug 2013 22:48:04 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IHJlbG9hZCwg0LLRi9C10LTQsNC10YIgQ1BV?= In-Reply-To: References: <20130827154730.GC19334@mdounin.ru> <20130827213822.GA2748@mdounin.ru> <20130828154136.GI8272@mdounin.ru> <20130828180508.GL8272@mdounin.ru> Message-ID: <20130828184804.GM8272@mdounin.ru> Hello! On Wed, Aug 28, 2013 at 09:22:14PM +0300, Serge Negodyuck wrote: > 28 августа 2013 г., 21:05 пользователь Maxim Dounin > написал: > > Hello! > > > > On Wed, Aug 28, 2013 at 08:39:38PM +0300, Serge Negodyuck wrote: > > > >> 28 августа 2013 г., 18:41 пользователь Maxim Dounin > >> написал: > >> > >> > > >> > Ну таки да, timer_resolution 1ms + worker_connections 32000 > >> > поведение объясняют. Простейшее решение - выпилить из конфига > >> > timer_resolution и/или поднять до каких-нибудь более разумных > >> > 100ms. > >> > > >> Если бы timer_resolution не влиял на $upstream_response_time (который > >> нужен в логах, с довольно большой точностью, чтобы иметь статистику по > >> бекендам), то да. > > > > Таки он и не влияет - timer_resolution предназначен для > > загрубления точности, а не улучшения. > > > > Если нужна высокая точность - просто уберите директиву > > timer_resolution из конфига (или поставьте в 0, что суть то же > > самое). > > Да уж, несколько дней убил, а всё по незнанию того, что можно просто > убрать timer_resolution. > Зато немного разобрался в том, как nginx обрабатывает запросы. В первую очередь - не надо было его ставить. В документации как бы явно написано: : Уменьшает разрешение таймеров времени в рабочих процессах, за счёт чего : уменьшается число системных вызовов gettimeofday(). По умолчанию gettimeofday() : вызывается после каждой операции получения событий из ядра. При уменьшении : разрешения gettimeofday() вызывается только один раз за указанный интервал. http://nginx.org/r/timer_resolution/ru > P.S. Хотя, несколько тысяч живущих вебсокетов, каждый из которых, раз > в секунду обновляет данные (и создает при этом kevent, да?) - вполне > возможная ситуация. Возможная, но маловероятная. Кроме того, события от реальных соединений имеют тенденцию склеиваться между собой при увеличении нагрузки, в отличии от таймеров. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Aug 29 01:41:20 2013 From: nginx-forum at nginx.us (shtein) Date: Wed, 28 Aug 2013 21:41:20 -0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?= =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?= =?UTF-8?B?0Lku?= In-Reply-To: References: Message-ID: Если вы про директиву "charset", то попробовал. Указывал: charset windows-1251; override_charset on; и в поле server, и в поле location - без толку. Добавляет головной боли тот факт, что временами nginx выплёвывает данные в cp1252, а временами ромбиками (???????). В основном, такое замечано на страницах, в которых используется Ajax-меню. Ещё одна особенность, что чем меньше правил и настроек в modsecurity.conf, тем чаще эта проблема. Пробовал вплоть до того, что оставлял лишь строки: SecRuleEngine DetectionOnly SecUnicodeCodePage 1251 SecUnicodeMapFile unicode.mapping И даже только SecRuleEngine DetectionOnly В таких случаях данные в нормальном виде выдаются один раз из 3х. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242278,242313#msg-242313 From postmaster at softsearch.ru Thu Aug 29 04:19:05 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 29 Aug 2013 08:19:05 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?= =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?= =?UTF-8?B?0Lku?= In-Reply-To: References: Message-ID: <1798251478.20130829081905@softsearch.ru> Здравствуйте, shtein. А зачем Вам ModSecurity нужен? Какую задачу он решает? Включите дебаг-лог в nginx-е и увидите что там внутри происходит с кодировкой. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Thu Aug 29 09:19:36 2013 From: nginx-forum at nginx.us (soleg) Date: Thu, 29 Aug 2013 05:19:36 -0400 Subject: SSLOptions & SSLCARevocationFile Message-ID: <3c2e04b6e27257c5bc80e48b05a48399.NginxMailingListRussian@forum.nginx.org> Всем привет. Вчера первый раз поставил nginx поверх апаче, и сразу появилась проблема с авторизацией по клиентским сертификатам. Саму авторизацию сделал ssl_certificate /certs/ca.crt; ssl_certificate_key /certs/ca.key; ssl_client_certificate /certs/ca.crt; ssl_verify_client on; ssl_session_timeout 5m; ssl_protocols SSLv2 SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; ssl_prefer_server_ciphers on; keepalive_timeout 70; fastcgi_param SSL_VERIFIED $ssl_client_verify; fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial; fastcgi_param SSL_CLIENT_CERT $ssl_client_cert; fastcgi_param SSL_DN $ssl_client_s_dn; Но теперь нужно получить параметры SSL сертификата, а именно параметр CN, аналог директивы SSLOptions +StdEnvVars +ExportCertData в апаче. А так же аналог директивы в апаче SSLCARevocationFile Для указания списка отзыва сертификатов Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242322,242322#msg-242322 From nginx-forum at nginx.us Thu Aug 29 09:21:57 2013 From: nginx-forum at nginx.us (soleg) Date: Thu, 29 Aug 2013 05:21:57 -0400 Subject: SSLOptions & SSLCARevocationFile In-Reply-To: <3c2e04b6e27257c5bc80e48b05a48399.NginxMailingListRussian@forum.nginx.org> References: <3c2e04b6e27257c5bc80e48b05a48399.NginxMailingListRussian@forum.nginx.org> Message-ID: По всей видимости не в том разделе запостил. Прошу прощения. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242322,242323#msg-242323 From mdounin at mdounin.ru Thu Aug 29 09:32:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 29 Aug 2013 13:32:07 +0400 Subject: SSLOptions & SSLCARevocationFile In-Reply-To: <3c2e04b6e27257c5bc80e48b05a48399.NginxMailingListRussian@forum.nginx.org> References: <3c2e04b6e27257c5bc80e48b05a48399.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130829093207.GA22852@mdounin.ru> Hello! On Thu, Aug 29, 2013 at 05:19:36AM -0400, soleg wrote: > Всем привет. > > Вчера первый раз поставил nginx поверх апаче, и сразу появилась проблема с > авторизацией по клиентским сертификатам. > > Саму авторизацию сделал > > ssl_certificate /certs/ca.crt; > ssl_certificate_key /certs/ca.key; > ssl_client_certificate /certs/ca.crt; > ssl_verify_client on; > ssl_session_timeout 5m; > ssl_protocols SSLv2 SSLv3 TLSv1; > ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; > ssl_prefer_server_ciphers on; > keepalive_timeout 70; > fastcgi_param SSL_VERIFIED $ssl_client_verify; > fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial; > fastcgi_param SSL_CLIENT_CERT $ssl_client_cert; > fastcgi_param SSL_DN $ssl_client_s_dn; > > > Но теперь нужно получить параметры SSL сертификата, а именно параметр CN, > аналог директивы > > SSLOptions +StdEnvVars +ExportCertData > > в апаче. Переменные, которые есть, документированы тут: http://nginx.org/ru/docs/http/ngx_http_ssl_module.html#variables Если зачем-то нужен именно CN - его можно достать из $ssl_client_s_dn. > А так же аналог директивы в апаче > > SSLCARevocationFile > > Для указания списка отзыва сертификатов http://nginx.org/r/ssl_crl -- Maxim Dounin http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Thu Aug 29 11:47:01 2013 From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Thu, 29 Aug 2013 14:47:01 +0300 Subject: =?UTF-8?B?0JHQsNCzIHRyeV9maWxlcyArIHZhbGlkX3JlZmVyZXJz?= Message-ID: <521F34B5.6000501@kpi.ua> location / { index index.php index.htm index.html; root /var/www/site.com; try_files $uri $uri/ /index.php?q=$uri&$args @backend; rewrite "^/([^\/]+/[^\/]+)/((s[\d]+)?(e[\d]+){1}(\-[\d]+)*)$" /$1.html?serie=$2; rewrite ([^\/]+/[^\/]+.html)/$ /$1 permanent; rewrite (tag/[^\/]+)/$ /$1 permanent; valid_referers none server_names ~(yandex|google|yahoo|bing|facebook|fbcdn|mail.ru|rambler|nigma|vk.com); if ($invalid_referer) { access_log /var/log/nginx/site.com.invalid.log main; } if ($a) { access_log /var/log/nginx/a.site.com.access.log main; } } Почему-тоЮ, если приходит запрос с реферером, которого нет в valid_referers, try_files почему-то проверяет только $uri и потом возвращает сразу 404: 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http script var 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http script var: "1" 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http script if 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http script var 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http geo started: 176.104.57.123 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http geo: 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http script var: "" 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http script if 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http script if: false 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 post rewrite phase: 4 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 generic phase: 5 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 generic phase: 6 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 generic phase: 7 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 access phase: 8 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 access phase: 9 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 post access phase: 10 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 try files phase: 11 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 content phase: 12 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 content phase: 13 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 content phase: 14 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http filename: "/var/www/site.com/series/univer-novaya-obschaga-serial.html" 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 add cleanup: 00000000019C3E58 2013/08/29 11:06:34 [error] 7188#0: *1851357643 open() "/var/www/site.com/series/univer-novaya-obschaga-serial.html" failed (2: No such file or directory), client: 176.104.57.123, server: site.com, request: "GET /series/univer-novaya-obschaga-serial.html HTTP/1.1", host: "site.com", referrer: "http://www.top-page.ru/ya/?q=%D0%BD%D0%BE%D0%B2%D0%B0%D1%8F+%D0%BE%D0%B1%D1%89%D0%B0%D0%B3%D0%B0+%D0%BD%D0%BE%D0%B2%D1%8B%D0%B5+%D1%81%D0%B5%D1%80%D0%B8%D0%B8+%D1%81%D0%BC%D0%BE%D1%82%D1%80%D0%B5%D1%82%D1%8C+%D0%BE%D0%BD%D0%BB%D0%B0%D0%B9%D0%BD" 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http finalize request: 404, "/series/univer-novaya-obschaga-serial.html?" a:1, c:1 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 http special response: 404, "/series/univer-novaya-obschaga-serial.html?" 2013/08/29 11:06:34 [debug] 7188#0: *1851357643 internal redirect: "/errors/404.html?" Если закомментировать строки: valid_referers none server_names ~(yandex|google|yahoo|bing|facebook|fbcdn|mail.ru|rambler|nigma|vk.com); if ($invalid_referer) { access_log /var/log/nginx/site.com.invalid.log main; все идет как надо, то есть доходит до /index.php?q=$uri&$args # nginx -V nginx version: nginx/1.2.4 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 --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-file-aio --with-http_flv_module --with-http_geoip_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --without-http_scgi_module --without-http_split_clients_module --without-http_ssi_module --without-http_userid_module --without-http_uwsgi_module Ну, и чтоб два раза не вставать: какой альтернативный способ писать отдельный лог для invalid_referer? From mdounin at mdounin.ru Thu Aug 29 12:00:16 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 29 Aug 2013 16:00:16 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQsyB0cnlfZmlsZXMgKyB2YWxpZF9yZWZlcmVycw==?= In-Reply-To: <521F34B5.6000501@kpi.ua> References: <521F34B5.6000501@kpi.ua> Message-ID: <20130829120015.GF22852@mdounin.ru> Hello! On Thu, Aug 29, 2013 at 02:47:01PM +0300, Андрей Василишин wrote: > location / { > index index.php index.htm index.html; > root /var/www/site.com; > try_files $uri > $uri/ > /index.php?q=$uri&$args > @backend; > rewrite > "^/([^\/]+/[^\/]+)/((s[\d]+)?(e[\d]+){1}(\-[\d]+)*)$" > /$1.html?serie=$2; > rewrite ([^\/]+/[^\/]+.html)/$ /$1 permanent; > rewrite (tag/[^\/]+)/$ /$1 permanent; > valid_referers none server_names ~(yandex|google|yahoo|bing|facebook|fbcdn|mail.ru|rambler|nigma|vk.com); > if ($invalid_referer) { > access_log > /var/log/nginx/site.com.invalid.log main; > } > if ($a) { > access_log > /var/log/nginx/a.site.com.access.log main; > } > > } > > > Почему-тоЮ, если приходит запрос с реферером, которого нет в > valid_referers, try_files почему-то проверяет только $uri и потом > возвращает сразу 404: http://wiki.nginx.org/IfIsEvil Конкретно ваш случай - "try_files wont work due to if". [...] > Ну, и чтоб два раза не вставать: какой альтернативный способ писать > отдельный лог для invalid_referer? Варианты - уйти в другой location и писать отдельный лог там, писать лог с переменными в имени. -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Thu Aug 29 12:50:38 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 29 Aug 2013 16:50:38 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?= =?UTF-8?B?Mi4yMiAtICDQn9GA0L7QsdC70LXQvNGLINGBINC60L7QtNC40YDQvtCy0Lo=?= =?UTF-8?B?0L7QuS4=?= In-Reply-To: References: Message-ID: <201308291650.38905.vbart@nginx.com> On Thursday 29 August 2013 05:41:20 shtein wrote: [..] > В основном, такое замечано на страницах, в которых используется Ajax-меню. А это меню случайно не с помощью JSON-а подгружается? -- Валентин Бартенев http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Thu Aug 29 13:56:39 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 29 Aug 2013 16:56:39 +0300 Subject: =?UTF-8?B?UmU6INCR0LDQsyB0cnlfZmlsZXMgKyB2YWxpZF9yZWZlcmVycw==?= In-Reply-To: <20130829120015.GF22852@mdounin.ru> References: <521F34B5.6000501@kpi.ua> <20130829120015.GF22852@mdounin.ru> Message-ID: <521F5317.2040203@kpi.ua> 29.08.2013 15:00, Maxim Dounin пишет: > Варианты - уйти в другой location и писать отдельный лог там, > писать лог с переменными в имени. > Что-то не могу придумать, как без if это сделать. From wangsamp at gmail.com Thu Aug 29 15:02:24 2013 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Thu, 29 Aug 2013 18:02:24 +0300 (EEST) Subject: =?UTF-8?B?UmU6INCR0LDQsyB0cnlfZmlsZXMgKyB2YWxpZF9yZWZlcmVycw==?= In-Reply-To: <521F5317.2040203@kpi.ua> References: <521F34B5.6000501@kpi.ua> <20130829120015.GF22852@mdounin.ru> <521F5317.2040203@kpi.ua> Message-ID: Today Aug 29, 2013 at 16:56 Андрей Василишин wrote: > 29.08.2013 15:00, Maxim Dounin пишет: > > > Варианты - уйти в другой location и писать отдельный лог там, > > писать лог с переменными в имени. > > Что-то не могу придумать, как без if это сделать. Не без if, а без неявного вложенного location в if. Из if уйти в другой location (error_page+return, rewrite) со своим логом и try_files. -- WNGS-RIPE From mdounin at mdounin.ru Thu Aug 29 15:07:24 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 29 Aug 2013 19:07:24 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQsyB0cnlfZmlsZXMgKyB2YWxpZF9yZWZlcmVycw==?= In-Reply-To: <521F5317.2040203@kpi.ua> References: <521F34B5.6000501@kpi.ua> <20130829120015.GF22852@mdounin.ru> <521F5317.2040203@kpi.ua> Message-ID: <20130829150724.GH22852@mdounin.ru> Hello! On Thu, Aug 29, 2013 at 04:56:39PM +0300, Андрей Василишин wrote: > 29.08.2013 15:00, Maxim Dounin пишет: > > >Варианты - уйти в другой location и писать отдельный лог там, > >писать лог с переменными в имени. > > > > Что-то не могу придумать, как без if это сделать. По приведённой в предыдущем письме ссылке написано, как это сделать, если вы про переход в другой location. Делать это без if - не обязательно, достаточно обеспечить, чтобы обработка запроса при попадании в if уходила в другой location (i.e., использовать if + rewrite ... last или if + return). http://wiki.nginx.org/IfIsEvil -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Aug 29 15:26:38 2013 From: nginx-forum at nginx.us (exodus) Date: Thu, 29 Aug 2013 11:26:38 -0400 Subject: =?UTF-8?B?0LvQvtCz0LjRgNC+0LLQsNC90LjQtSAkcmVxdWVzdCBib2R5?= Message-ID: здравствуйте. правлю /etc/nginx/nginx.conf так, чтобы он логировал еще и пост запросы. для этого добавляю в log_format переменную $request_body. все работает на маленьких запросах (<10kb) - логирует. а на запросах больше 10kb он логирует прочерк "-". не подскажите, как настроить, чтобы запрос любого размера логировал? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242337,242337#msg-242337 From vbart at nginx.com Thu Aug 29 15:38:25 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 29 Aug 2013 19:38:25 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40YDQvtCy0LDQvdC40LUgJHJlcXVlc3QgYm9keQ==?= In-Reply-To: References: Message-ID: <201308291938.25482.vbart@nginx.com> On Thursday 29 August 2013 19:26:38 exodus wrote: > здравствуйте. правлю /etc/nginx/nginx.conf так, чтобы он логировал еще и > пост запросы. > для этого добавляю в log_format переменную $request_body. > все работает на маленьких запросах (<10kb) - логирует. а на запросах больше > 10kb он логирует прочерк "-". не подскажите, как настроить, чтобы запрос > любого размера логировал? > http://nginx.org/r/client_body_buffer_size/ru -- Валентин Бартенев http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Thu Aug 29 17:06:18 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 29 Aug 2013 20:06:18 +0300 Subject: =?UTF-8?B?UmU6INCR0LDQsyB0cnlfZmlsZXMgKyB2YWxpZF9yZWZlcmVycw==?= In-Reply-To: <20130829150724.GH22852@mdounin.ru> References: <521F34B5.6000501@kpi.ua> <20130829120015.GF22852@mdounin.ru> <521F5317.2040203@kpi.ua> <20130829150724.GH22852@mdounin.ru> Message-ID: <521F7F8A.7060409@kpi.ua> 29.08.2013 18:07, Maxim Dounin пишет: > Hello! > > On Thu, Aug 29, 2013 at 04:56:39PM +0300, Андрей Василишин wrote: > >> 29.08.2013 15:00, Maxim Dounin пишет: >> >>> Варианты - уйти в другой location и писать отдельный лог там, >>> писать лог с переменными в имени. >>> >> >> Что-то не могу придумать, как без if это сделать. > > По приведённой в предыдущем письме ссылке написано, как это > сделать, если вы про переход в другой location. > > Делать это без if - не обязательно, достаточно обеспечить, чтобы > обработка запроса при попадании в if уходила в другой location > (i.e., использовать if + rewrite ... last или if + return). > > http://wiki.nginx.org/IfIsEvil > Спасибо всем за ответы, в общем удалось сделать, то что хотел так: error_page 410 = @invalid; error_page 411 = @a; location / { index index.php index.htm index.html; root /var/www/site.com; try_files $uri $uri/ /index.php?q=$uri&$args @backend; rewrite "^/([^\/]+/[^\/]+)/((s[\d]+)?(e[\d]+){1}(\-[\d]+)*)$" /$1.html?serie=$2; rewrite ([^\/]+/[^\/]+.html)/$ /$1 permanent; rewrite (tag/[^\/]+)/$ /$1 permanent; valid_referers none server_names ~(yandex|google|yahoo|bing|facebook|fbcdn|mail.ru|rambler|nigma|vk.com); if ($invalid_referer) { return 410; } if ($a) { return 411; } } location @a { access_log /var/log/nginx/a.site.com.access.log main; root /var/www/site.com; try_files $uri $uri/ /index.php?q=$uri&$args; } location @invalid { access_log /var/log/nginx/site.com.invalid.log main; root /var/www/site.com; try_files $uri $uri/ /index.php?q=$uri&$args; } From nginx-forum at nginx.us Thu Aug 29 17:21:02 2013 From: nginx-forum at nginx.us (sorqnqal) Date: Thu, 29 Aug 2013 13:21:02 -0400 Subject: there are also brand advantages that accrue to these sites. 0546 Message-ID: <487c61f70be4d37f3000157ed2074539.NginxMailingListRussian@forum.nginx.org> This reserve power will get charged when you charge your cell phone next time. You have probably heard of or re . A phone number search will also help out if you happen to be searching for a long lost friend or loved one. I think Stymie makes an excellent point. Original content that appears in only one place has real value. When, as users, we realise that a particular website is the source of unique, relevant, and wellcrafted content then (apart from the SEO benefits outlined by Stymie) there are also brand advantages that accrue to these sites. It's a good idea to save the project, because that will allow you to change the project in case you decide to do something different with future galleries. So click Yes, then enter a name for your project. To select the location of your project, just click the Browse folders button and choose a different location. we will have corresponding departure times also in 1 hour intervals so if some would like to stay longer they can than those who would like to leave earlier. from the cup we will drop off the remained of the crew at the greenest ( or your desired drop off location) and head to red rocks. i think your customers would really appreciate this aspecect seeing as it is a hot show with hard to find transportation to and from. You could argue with my age that it s close to midlife. But I really feel like it s a rebirth. I feel more like myself than I have in 10 years, and more motivated and capable than I have in a long time. However popular is nearly two years RSS, due to the rapid popularization of Blog technologies and Useland, Yahoo and other major suit the company's support, in 2003 RSS had been touted as may be exempted from Spam Alternative interference, a new technology of forming a monopoly. Then Google to break the monopoly, support IBM Software Engineer SamRuby2003 years of research and development of Atom technology, due to the addition of Google, Atom rapid change red. Useland's Dave Werner (Dave Winner) also quickly upgrade RSS to version 2,[url=http://google.com/intl/zh-TW/about.html]GOODLUCK[/url], formed two camps confrontation. Apparently what had happened was he met one of the other Fiercers (our name for each other on the forum) and they had found out. Dranz (the guy) was not so nice. He owned the most well known of all websites on the web for Beyblade and the guy asked for a autograph, which Dranz refuses (could you blame him) but instead of a simple "no" gave a mouthful to the other guy. "I immediately rushed to a mirror to see if I was still there,[url=http://google.com/mgyhp.html]GOODLUCK[/url]," he said, laughing. He added that he was impressed by Le Devoir's quick reaction to the situation and added that no media is really immune from cyber piracy. while technicians tried to restore the site. [url=http://phorum.nostramusic.com/read.php?4,26029]http://phorum.nostramusic.com/read.php?4,26029[/url] [url=http://forums.reprap.org/read.php?54,240985]http://forums.reprap.org/read.php?54,240985[/url] [url=http://forum.nginx.org/read.php?15,242341,242341#msg-242341]http://forum.nginx.org/read.php?15,242341,242341#msg-242341[/url] Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242343,242343#msg-242343 From nginx-forum at nginx.us Thu Aug 29 20:41:49 2013 From: nginx-forum at nginx.us (igor.goncharenko) Date: Thu, 29 Aug 2013 16:41:49 -0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40YDQvtCy0LDQvdC40LUgJHJlcXVlc3QgYm9keQ==?= In-Reply-To: <201308291938.25482.vbart@nginx.com> References: <201308291938.25482.vbart@nginx.com> Message-ID: <61fcbeb3bc3fb86d01615323ab7bd07e.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Thursday 29 August 2013 19:26:38 exodus wrote: > > здравствуйте. правлю /etc/nginx/nginx.conf так, чтобы он логировал > еще и > > пост запросы. > > для этого добавляю в log_format переменную $request_body. > > все работает на маленьких запросах (<10kb) - логирует. а на запросах > больше > > 10kb он логирует прочерк "-". не подскажите, как настроить, чтобы > запрос > > любого размера логировал? > > > > http://nginx.org/r/client_body_buffer_size/ru Кстати, давно хотел спросить, а почему так? Вот, например, я хочу логировать $request_body для всех запросов и в то же время хочу записывать большие запросы во временный файл. Получается так сделать нельзя в принципе? --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242338,242352#msg-242352 From onokonem at gmail.com Thu Aug 29 20:52:52 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 30 Aug 2013 00:52:52 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40YDQvtCy0LDQvdC40LUgJHJlcXVlc3QgYm9keQ==?= In-Reply-To: <61fcbeb3bc3fb86d01615323ab7bd07e.NginxMailingListRussian@forum.nginx.org> References: <201308291938.25482.vbart@nginx.com> <61fcbeb3bc3fb86d01615323ab7bd07e.NginxMailingListRussian@forum.nginx.org> Message-ID: > я хочу логировать > $request_body для всех запросов и в то же время хочу записывать большие > запросы во временный файл. Это очень, очень странная идея. По окончании обработки nginx перекачивает информацию из временного файла в лог? Зачем? From nginx-forum at nginx.us Thu Aug 29 22:53:29 2013 From: nginx-forum at nginx.us (shtein) Date: Thu, 29 Aug 2013 18:53:29 -0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?= =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?= =?UTF-8?B?0Lku?= In-Reply-To: <201308291650.38905.vbart@nginx.com> References: <201308291650.38905.vbart@nginx.com> Message-ID: Ну Json в том модуле точно используется. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242329,242354#msg-242354 From nginx-forum at nginx.us Fri Aug 30 05:01:38 2013 From: nginx-forum at nginx.us (ks2) Date: Fri, 30 Aug 2013 01:01:38 -0400 Subject: fastcgi_read_timeout Message-ID: Добрый день, Прошу разъяснить значение параметра fastcgi_read_timeout. В доке написано, что он задает таймаут между двумя последовательными операциями чтения данных из апстрима. Ок, если я задам скажем "fastcgi_read_timeout 75ms" и мой апстрим вычитает запрос с nginx-а за 3 мс, а потом на 150 мс уйдет в себя, ничего не отдавая nginx-у, таймаут сработает? (в такой ситуации формально ни одной операции чтения nginx-ом не выполнено) Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242356,242356#msg-242356 From titkovdmitry at gmail.com Fri Aug 30 06:06:48 2013 From: titkovdmitry at gmail.com (titkovdmitry at gmail.com) Date: Fri, 30 Aug 2013 10:06:48 +0400 Subject: =?UTF-8?B?0JjQvdC40YbQuNCw0LvQuNC30LDRhtC40Y8g0YHQv9C40YHQutCwIG5neF9wb3N0?= =?UTF-8?B?ZWRfZXZlbnRz?= Message-ID: <52203678.8010503@gmail.com> Здравствуйте! Я разрабатываю модуль к серверу nginx который позволяет формировать некий текстовый ответ на http запрос. Процесс формирования ответа полностью отвязан от nginx и я хотел бы вынести этот процесс в thread pool. Мне кажется я разобрался как это можно сделать но у меня остается один вопрос. Реализовать я бы хотел это следующим образом, когда вызывается обработчик запроса модуля я копирую все необходимые параметры в структуру и передаю её на выполнение в thread pool. Так же я сохраняю этот запрос в списке подобном ngx_posted_events. и устанавливаю атомарный флаг готовности ответа. В nginx в метод ngx_process_events_and_timers добавлю код, который проверит список с запросами и те у которых готов ответ на отправку вызовет соответственно ngx_http_send_header(r) и ngx_http_output_filter(r, out); Дак вот у меня есть непонимание, где в коде nginx обнуляется ngx_posted_events ? Всё перерыл, не могу найти этот момент. Буду благодарен за помощь. From nginx-forum at nginx.us Fri Aug 30 08:17:04 2013 From: nginx-forum at nginx.us (DenisM) Date: Fri, 30 Aug 2013 04:17:04 -0400 Subject: =?UTF-8?B?0J7RgtC60YPQtNCwINCx0LXRgNGR0YLRgdGPINGC0LDQudC80LDRg9GCINC00Ls=?= =?UTF-8?B?0Y8gNTA0Pw==?= Message-ID: Привет! Почему $upstream_response_time для 504 у меня всегда 30 с? Где этот таймаут задаётся? В php.ini установил max_execution_time=24, не помогло. Денис Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242358,242358#msg-242358 From denis at webmaster.spb.ru Fri Aug 30 08:28:23 2013 From: denis at webmaster.spb.ru (denis) Date: Fri, 30 Aug 2013 12:28:23 +0400 Subject: =?UTF-8?B?0JLQu9C+0LbQtdC90L3Ri9C5INCw0L/RgdGC0YDQuNC8?= Message-ID: <522057A7.8070109@webmaster.spb.ru> Добрый день. Есть необходимость сделать конструкцию вида upstream { server 1.2.3.4:8080; server 7.7.7.7 backup; backup { server 8.8.8.8; server 9.9.9.9 backup; }} смысл в том, что бэкап серверов будет более 1, и им нужны приоритеты по подключению. Может кто помочь переписать стандартный апстим/форкнуть его в отдельный модуль? From mdounin at mdounin.ru Fri Aug 30 08:37:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2013 12:37:33 +0400 Subject: fastcgi_read_timeout In-Reply-To: References: Message-ID: <20130830083733.GA29448@mdounin.ru> Hello! On Fri, Aug 30, 2013 at 01:01:38AM -0400, ks2 wrote: > Добрый день, > > Прошу разъяснить значение параметра fastcgi_read_timeout. В доке написано, > что он задает таймаут между двумя последовательными операциями чтения данных > из апстрима. Ок, если я задам скажем "fastcgi_read_timeout 75ms" и мой > апстрим вычитает запрос с nginx-а за 3 мс, а потом на 150 мс уйдет в себя, > ничего не отдавая nginx-у, таймаут сработает? (в такой ситуации формально ни > одной операции чтения nginx-ом не выполнено) Да. Таймаут взводится, когда nginx начинает ждать ответ от бекенда. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Fri Aug 30 08:42:12 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2013 12:42:12 +0400 Subject: =?UTF-8?B?UmU6INCY0L3QuNGG0LjQsNC70LjQt9Cw0YbQuNGPINGB0L/QuNGB0LrQsCBuZ3hf?= =?UTF-8?B?cG9zdGVkX2V2ZW50cw==?= In-Reply-To: <52203678.8010503@gmail.com> References: <52203678.8010503@gmail.com> Message-ID: <20130830084212.GB29448@mdounin.ru> Hello! On Fri, Aug 30, 2013 at 10:06:48AM +0400, titkovdmitry at gmail.com wrote: > Здравствуйте! > Я разрабатываю модуль к серверу nginx который позволяет формировать > некий текстовый ответ на http запрос. > Процесс формирования ответа полностью отвязан от nginx и я хотел бы > вынести этот процесс в thread pool. > Мне кажется я разобрался как это можно сделать но у меня остается > один вопрос. > > Реализовать я бы хотел это следующим образом, когда вызывается > обработчик запроса модуля я копирую все необходимые параметры в > структуру и передаю её на выполнение в thread pool. > Так же я сохраняю этот запрос в списке подобном ngx_posted_events. и > устанавливаю атомарный флаг готовности ответа. > В nginx в метод ngx_process_events_and_timers добавлю код, который > проверит список с запросами и те у которых готов ответ на отправку > вызовет соответственно > ngx_http_send_header(r) и ngx_http_output_filter(r, out); > > Дак вот у меня есть непонимание, где в коде nginx обнуляется > ngx_posted_events ? Всё перерыл, не могу найти этот момент. Буду > благодарен за помощь. Обработкой posted-событий занимается ngx_event_process_posted(), и там же обработанные события из очереди удаляются. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Fri Aug 30 08:46:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2013 12:46:06 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQutGD0LTQsCDQsdC10YDRkdGC0YHRjyDRgtCw0LnQvNCw0YPRgiA=?= =?UTF-8?B?0LTQu9GPIDUwND8=?= In-Reply-To: References: Message-ID: <20130830084606.GC29448@mdounin.ru> Hello! On Fri, Aug 30, 2013 at 04:17:04AM -0400, DenisM wrote: > Привет! > > Почему $upstream_response_time для 504 у меня всегда 30 с? Где этот таймаут > задаётся? > В php.ini установил max_execution_time=24, не помогло. Если proxy: http://nginx.org/r/proxy_connect_timeout http://nginx.org/r/proxy_read_timeout Если fastcgi: http://nginx.org/r/fastcgi_connect_timeout http://nginx.org/r/fastcgi_read_timeout -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Fri Aug 30 08:49:52 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2013 12:49:52 +0400 Subject: =?UTF-8?B?UmU6INCS0LvQvtC20LXQvdC90YvQuSDQsNC/0YHRgtGA0LjQvA==?= In-Reply-To: <522057A7.8070109@webmaster.spb.ru> References: <522057A7.8070109@webmaster.spb.ru> Message-ID: <20130830084952.GD29448@mdounin.ru> Hello! On Fri, Aug 30, 2013 at 12:28:23PM +0400, denis wrote: > Добрый день. > > Есть необходимость сделать конструкцию вида > upstream { > server 1.2.3.4:8080; > server 7.7.7.7 backup; > backup { > server 8.8.8.8; > server 9.9.9.9 backup; > }} > > смысл в том, что бэкап серверов будет более 1, и им нужны приоритеты > по подключению. > > Может кто помочь переписать стандартный апстим/форкнуть его в > отдельный модуль? А какую задачу решаем? В большинстве случаев правильным подходом будет: error_page 502 504 = @fallback; location / { proxy_pass http://normal_upstream; } location @fallback { proxy_pass http://fallback_upstream; } (+ recursive_error_pages по необходимости) -- Maxim Dounin http://nginx.org/en/donation.html From titkovdmitry at gmail.com Fri Aug 30 08:55:01 2013 From: titkovdmitry at gmail.com (titkovdmitry at gmail.com) Date: Fri, 30 Aug 2013 12:55:01 +0400 Subject: =?UTF-8?B?UmU6INCY0L3QuNGG0LjQsNC70LjQt9Cw0YbQuNGPINGB0L/QuNGB0LrQsCBuZ3hf?= =?UTF-8?B?cG9zdGVkX2V2ZW50cw==?= In-Reply-To: <20130830084212.GB29448@mdounin.ru> References: <52203678.8010503@gmail.com> <20130830084212.GB29448@mdounin.ru> Message-ID: <52205DE5.10000@gmail.com> 30.08.2013 12:42, Maxim Dounin пишет: > Hello! > > On Fri, Aug 30, 2013 at 10:06:48AM +0400, titkovdmitry at gmail.com wrote: > >> Здравствуйте! >> Я разрабатываю модуль к серверу nginx который позволяет формировать >> некий текстовый ответ на http запрос. >> Процесс формирования ответа полностью отвязан от nginx и я хотел бы >> вынести этот процесс в thread pool. >> Мне кажется я разобрался как это можно сделать но у меня остается >> один вопрос. >> >> Реализовать я бы хотел это следующим образом, когда вызывается >> обработчик запроса модуля я копирую все необходимые параметры в >> структуру и передаю её на выполнение в thread pool. >> Так же я сохраняю этот запрос в списке подобном ngx_posted_events. и >> устанавливаю атомарный флаг готовности ответа. >> В nginx в метод ngx_process_events_and_timers добавлю код, который >> проверит список с запросами и те у которых готов ответ на отправку >> вызовет соответственно >> ngx_http_send_header(r) и ngx_http_output_filter(r, out); >> >> Дак вот у меня есть непонимание, где в коде nginx обнуляется >> ngx_posted_events ? Всё перерыл, не могу найти этот момент. Буду >> благодарен за помощь. > Обработкой posted-событий занимается ngx_event_process_posted(), > и там же обработанные события из очереди удаляются. > Я нашел где они удаляются. И мне понятен механизм работы с ними. Вопрос состоит в том где эта переменная инициализируется. Это указатель, в методе ngx_locked_post_event мы обращаемся к полям структуры которая должна находится по этому указателю. Дак вот где при старте сервера ей присвается начальное значение ? т.е должен быть код инициализации, типа ngx_posted_events = init_ev; From nginx-forum at nginx.us Fri Aug 30 10:12:24 2013 From: nginx-forum at nginx.us (ks2) Date: Fri, 30 Aug 2013 06:12:24 -0400 Subject: fastcgi_read_timeout In-Reply-To: <20130830083733.GA29448@mdounin.ru> References: <20130830083733.GA29448@mdounin.ru> Message-ID: Максим, спасибо большое! Возможно, стоило бы добавить этот факт в доку, чтобы народ не сомневался. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242356,242372#msg-242372 From mdounin at mdounin.ru Fri Aug 30 10:15:00 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2013 14:15:00 +0400 Subject: =?UTF-8?B?UmU6INCY0L3QuNGG0LjQsNC70LjQt9Cw0YbQuNGPINGB0L/QuNGB0LrQsCBuZ3hf?= =?UTF-8?B?cG9zdGVkX2V2ZW50cw==?= In-Reply-To: <52205DE5.10000@gmail.com> References: <52203678.8010503@gmail.com> <20130830084212.GB29448@mdounin.ru> <52205DE5.10000@gmail.com> Message-ID: <20130830101459.GE29448@mdounin.ru> Hello! On Fri, Aug 30, 2013 at 12:55:01PM +0400, titkovdmitry at gmail.com wrote: > 30.08.2013 12:42, Maxim Dounin пишет: > >Hello! > > > >On Fri, Aug 30, 2013 at 10:06:48AM +0400, titkovdmitry at gmail.com wrote: > > > >>Здравствуйте! > >>Я разрабатываю модуль к серверу nginx который позволяет формировать > >>некий текстовый ответ на http запрос. > >>Процесс формирования ответа полностью отвязан от nginx и я хотел бы > >>вынести этот процесс в thread pool. > >>Мне кажется я разобрался как это можно сделать но у меня остается > >>один вопрос. > >> > >>Реализовать я бы хотел это следующим образом, когда вызывается > >>обработчик запроса модуля я копирую все необходимые параметры в > >>структуру и передаю её на выполнение в thread pool. > >>Так же я сохраняю этот запрос в списке подобном ngx_posted_events. и > >>устанавливаю атомарный флаг готовности ответа. > >>В nginx в метод ngx_process_events_and_timers добавлю код, который > >>проверит список с запросами и те у которых готов ответ на отправку > >>вызовет соответственно > >>ngx_http_send_header(r) и ngx_http_output_filter(r, out); > >> > >>Дак вот у меня есть непонимание, где в коде nginx обнуляется > >>ngx_posted_events ? Всё перерыл, не могу найти этот момент. Буду > >>благодарен за помощь. > >Обработкой posted-событий занимается ngx_event_process_posted(), > >и там же обработанные события из очереди удаляются. > > > Я нашел где они удаляются. И мне понятен механизм работы с ними. > Вопрос состоит в том где эта переменная инициализируется. Это > указатель, в методе ngx_locked_post_event мы обращаемся к полям > структуры которая должна находится по этому указателю. Дак вот где > при старте сервера ей присвается начальное значение ? т.е должен > быть код инициализации, типа ngx_posted_events = init_ev; Это глобальная переменная, так что она устанавливается в NULL автоматически. Подробности в C99, 6.7.8 Initialization, абзац 10: : ... If an object that has static storage duration is : not initialized explicitly, then: : : ? if it has pointer type, it is initialized to a null pointer; -- Maxim Dounin http://nginx.org/en/donation.html From titkovdmitry at gmail.com Fri Aug 30 11:21:01 2013 From: titkovdmitry at gmail.com (titkovdmitry at gmail.com) Date: Fri, 30 Aug 2013 15:21:01 +0400 Subject: =?UTF-8?B?UmU6INCY0L3QuNGG0LjQsNC70LjQt9Cw0YbQuNGPINGB0L/QuNGB0LrQsCBuZ3hf?= =?UTF-8?B?cG9zdGVkX2V2ZW50cw==?= In-Reply-To: <20130830101459.GE29448@mdounin.ru> References: <52203678.8010503@gmail.com> <20130830084212.GB29448@mdounin.ru> <52205DE5.10000@gmail.com> <20130830101459.GE29448@mdounin.ru> Message-ID: <5220801D.8030703@gmail.com> 30.08.2013 14:15, Maxim Dounin пишет: > Hello! > > On Fri, Aug 30, 2013 at 12:55:01PM +0400, titkovdmitry at gmail.com wrote: > >> 30.08.2013 12:42, Maxim Dounin пишет: >>> Hello! >>> >>> On Fri, Aug 30, 2013 at 10:06:48AM +0400, titkovdmitry at gmail.com wrote: >>> >>>> Здравствуйте! >>>> Я разрабатываю модуль к серверу nginx который позволяет формировать >>>> некий текстовый ответ на http запрос. >>>> Процесс формирования ответа полностью отвязан от nginx и я хотел бы >>>> вынести этот процесс в thread pool. >>>> Мне кажется я разобрался как это можно сделать но у меня остается >>>> один вопрос. >>>> >>>> Реализовать я бы хотел это следующим образом, когда вызывается >>>> обработчик запроса модуля я копирую все необходимые параметры в >>>> структуру и передаю её на выполнение в thread pool. >>>> Так же я сохраняю этот запрос в списке подобном ngx_posted_events. и >>>> устанавливаю атомарный флаг готовности ответа. >>>> В nginx в метод ngx_process_events_and_timers добавлю код, который >>>> проверит список с запросами и те у которых готов ответ на отправку >>>> вызовет соответственно >>>> ngx_http_send_header(r) и ngx_http_output_filter(r, out); >>>> >>>> Дак вот у меня есть непонимание, где в коде nginx обнуляется >>>> ngx_posted_events ? Всё перерыл, не могу найти этот момент. Буду >>>> благодарен за помощь. >>> Обработкой posted-событий занимается ngx_event_process_posted(), >>> и там же обработанные события из очереди удаляются. >>> >> Я нашел где они удаляются. И мне понятен механизм работы с ними. >> Вопрос состоит в том где эта переменная инициализируется. Это >> указатель, в методе ngx_locked_post_event мы обращаемся к полям >> структуры которая должна находится по этому указателю. Дак вот где >> при старте сервера ей присвается начальное значение ? т.е должен >> быть код инициализации, типа ngx_posted_events = init_ev; > Это глобальная переменная, так что она устанавливается в NULL > автоматически. Подробности в C99, 6.7.8 Initialization, абзац 10: > > : ... If an object that has static storage duration is > : not initialized explicitly, then: > : > : ? if it has pointer type, it is initialized to a null pointer; > Понял. Спасибо огромное. И извиняюсь за получается глупый вопрос. Сам на C++ пишу и этого не знал. Ещё раз спасибо! From vbart at nginx.com Fri Aug 30 16:05:41 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 30 Aug 2013 20:05:41 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?= =?UTF-8?B?Mi4yMiAtICDQn9GA0L7QsdC70LXQvNGLINGBINC60L7QtNC40YDQvtCy0Lo=?= =?UTF-8?B?0L7QuS4=?= In-Reply-To: References: <201308291650.38905.vbart@nginx.com> Message-ID: <201308302005.41055.vbart@nginx.com> On Friday 30 August 2013 02:53:29 shtein wrote: > Ну Json в том модуле точно используется. JSON по стандарту должен быть в UTF-8, если вы выдаете его в CP1251 то можете столкнуться с проблемами. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Aug 30 22:56:17 2013 From: nginx-forum at nginx.us (shtein) Date: Fri, 30 Aug 2013 18:56:17 -0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?= =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?= =?UTF-8?B?0Lku?= In-Reply-To: <201308302005.41055.vbart@nginx.com> References: <201308302005.41055.vbart@nginx.com> Message-ID: <374480d5f7523e14a1804417e9c0786f.NginxMailingListRussian@forum.nginx.org> Насколько я помню, все данные, что передаются в JSON формате, предварительно перекадируются в UTF-8, а получаемые, перекодируются в cp-1251. Меня смущает то, что связки Nginx+Apache2, Nginx+ (Apache2+Mod_security) - работают. Не работает лишь (Nginx+Mod_security) + Apache2. Может я какие-то директивы при компиляции не указал - не знаю. Попробую отследить всё, связанное с Json, спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242329,242383#msg-242383 From nginx-forum at nginx.us Sat Aug 31 07:38:39 2013 From: nginx-forum at nginx.us (igor.goncharenko) Date: Sat, 31 Aug 2013 03:38:39 -0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40YDQvtCy0LDQvdC40LUgJHJlcXVlc3QgYm9keQ==?= In-Reply-To: References: Message-ID: Daniel Podolsky Wrote: ------------------------------------------------------- > > я хочу логировать > > $request_body для всех запросов и в то же время хочу записывать > большие > > запросы во временный файл. > Это очень, очень странная идея. По окончании обработки nginx > перекачивает информацию из временного файла в лог? Зачем? Это мне нужно иногда видеть тела запросов больших POST. Похоже, client_body_in_file_only подойдет. Спасибо. --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242338,242386#msg-242386 From vladget at gmail.com Sat Aug 31 20:32:16 2013 From: vladget at gmail.com (Vladimir Getmanshchuk) Date: Sat, 31 Aug 2013 23:32:16 +0300 Subject: true 414 status code Message-ID: Здравствуйте! Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414 status code, на запросы, размер которых, превышает large_client_header_ buffers? Постоянно получаю 200 http status code и нижеприведенное в body: 414 Request-URI Too Large

414 Request-URI Too Large


nginx/1.2.9
-- Yours sincerely, Vladimir Getmanshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Aug 31 20:50:28 2013 From: nginx-forum at nginx.us (sofiamay) Date: Sat, 31 Aug 2013 16:50:28 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQv9GA0LDQstC40LvRjNC90YvQtSAo0L7Qs9GA0L7QvNC90YvQtSkg?= =?UTF-8?B?0LfQvdCw0YfQtdC90LjRjyAkcmVxdWVzdCB0aW1lINC00LvRjyBGYXN0Q0dJ?= =?UTF-8?B?LdC30LDQv9GA0L7RgdC+0LI=?= In-Reply-To: <5501669a502645a63199fab569d61e70.NginxMailingListRussian@forum.nginx.org> References: <5501669a502645a63199fab569d61e70.NginxMailingListRussian@forum.nginx.org> Message-ID: <1d54207dc6d79255cd917f2d6c71a08e.NginxMailingListRussian@forum.nginx.org> А что, за год баг так и не исправили? Разрабы даже не удосужились здесь отписаться? Баг хотябы в багтрекере висит? Подтверждаю, у меня тоже $request_time выдаёт бред: 240648971536.2381542 240648971536.2381542 240648971536.2381542 240648971536.2381542 240648971536.2381542 Одно и то же для многих запросов подряд, потом опять на другой бред меняет! Когда это исправят? Зачем в Nginx сделана переменная $request_time если она показывает всякий бред, мне думается её нужно убрать, а через несколько лет, когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше вреда чем пользы. P.S. Использую Windows и PHP как FastCGI. Понятно что под Windows есть ограничения, они описаны в справке, но когда базовые возможности работают от балды, это уже фэйспалм. Помнится я отправлял баг о невозможности запуска по Windows более 5000 тыс сайтов, так баг до сих пор и висит. С таким успехом и с такими темпами развития Nginx проект Apache будет 1000 раз оптимизирован и развит за многие годы и станет жрать минимум памяти и ресурсов.... а Nginx к тому времени станет не нужен. P.P.S. Для топикстартера: проблема в том, что разработчики тупо забили на Windows, уже много лет подряд в этом направлении ничего не делается, так что и эта проблема имеет место быть, и куча других. Просто не используйте Nginx под Windows. Apache 2.4 сейчас куда более актуален. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,216150,242393#msg-242393 From ne at vbart.ru Sat Aug 31 20:57:12 2013 From: ne at vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 1 Sep 2013 00:57:12 +0400 Subject: true 414 status code In-Reply-To: References: Message-ID: <201309010057.12473.ne@vbart.ru> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote: > Здравствуйте! > > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414 > status code, на запросы, размер которых, превышает large_client_header_ > buffers? > > Постоянно получаю 200 http status code и нижеприведенное в body: > > > 414 Request-URI Too Large > >

414 Request-URI Too Large

>
nginx/1.2.9
> > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой. -- Валентин Бартенев http://nginx.org/en/donation.html From onokonem at gmail.com Sat Aug 31 21:33:59 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 1 Sep 2013 01:33:59 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQv9GA0LDQstC40LvRjNC90YvQtSAo0L7Qs9GA0L7QvNC90YvQtSkg?= =?UTF-8?B?0LfQvdCw0YfQtdC90LjRjyAkcmVxdWVzdCB0aW1lINC00LvRjyBGYXN0Q0dJ?= =?UTF-8?B?LdC30LDQv9GA0L7RgdC+0LI=?= In-Reply-To: <1d54207dc6d79255cd917f2d6c71a08e.NginxMailingListRussian@forum.nginx.org> References: <5501669a502645a63199fab569d61e70.NginxMailingListRussian@forum.nginx.org> <1d54207dc6d79255cd917f2d6c71a08e.NginxMailingListRussian@forum.nginx.org> Message-ID: > Просто не используйте Nginx > под Windows. Apache 2.4 сейчас куда более актуален. Под Windows актуален IIS. Он там работает лучше всех.