From nginx-forum at nginx.us Wed Jan 1 19:14:58 2014 From: nginx-forum at nginx.us (Sergey Korzhevsky) Date: Wed, 01 Jan 2014 14:14:58 -0500 Subject: image_filter+proxy_pass and 301 (moved permanently) on backend In-Reply-To: <90055df89e0abed5ea9adb0dfb0ed018.NginxMailingListRussian@forum.nginx.org> References: <90055df89e0abed5ea9adb0dfb0ed018.NginxMailingListRussian@forum.nginx.org> Message-ID: <01b9b2b9c6c9c1b6d6059fa04b7621ba.NginxMailingListRussian@forum.nginx.org> Отвечу сам себе. Верный конфиг следующий: proxy_intercept_errors on; location ~* "^/photos/(.*)$" { error_page 301 302 307 =200 @redir; #любой ДНС resolver 8.8.8.8 image_filter resize 50 -; proxy_pass http://$1; proxy_redirect off; } location @redir { resolver 8.8.8.8 set $newh $upstream_http_location; image_filter resize 50 -; proxy_pass $newh; } Причем, строка "set $newh $upstream_http_location;" необходима. Если сразу написать proxy_pass $upstream_http_location; то, почему-то, не работает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245867,245948#msg-245948 From nginx-forum at nginx.us Thu Jan 2 03:37:09 2014 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 01 Jan 2014 22:37:09 -0500 Subject: =?UTF-8?Q?Bug_=E2=80=93__304_status_-_Cache-Control?= Message-ID: Заметили очень неприятный баг, в результате которого, клиенты получали пустую страницу. Конфиг кеширования: fastcgi_cache_path cache levels=1:2 keys_zone=cache:256m inactive=1d; fastcgi_cache cache; fastcgi_cache_lock on; fastcgi_cache_revalidate on; fastcgi_cache_methods GET HEAD; fastcgi_cache_valid 200 301 302 0s; fastcgi_cache_key "$host$uri$is_args$args"; fastcgi_cache_use_stale error updating http_503; Воспроизводится баг следующим образом, бекенд при ревалидации отвечает статусом 304 и в соответсвии с HTTP спецификации, повторно высылает хедеры: Last-Modified и Cache-Control: max-age=1. В данном статусе бекенд отдает только хедеры без body. Nginx реагирует на хедер Cache-Control, в котором значения max-age больше нуля и сохраняет данный ответ в свой файл кеша, при условии что файла в кеше Nginx ещё или уже нет, в нашем случаи это было по причине устаревания кеша по директиве inactive, На последующие запросы по этому uri, если бекенд отвечает статусом 304, Nginx клиенту отдает результат из своего кеш файла, в котором нет body, если в браузере есть свой локал кеш, тогда все ок, но если это запрос от клиента у которого нет в локал кеше браузера данной страницы, он увидит пустую страницу и в этом заключается баг. Пока что временно, мы перестали отдавать хедер Cache-Control в статусе 304, но это не правильно и некоторые браузеры, перестают отправлять хедер If-Modified-Since. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245951#msg-245951 From mdounin at mdounin.ru Fri Jan 3 01:08:38 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 3 Jan 2014 05:08:38 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93__304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <20140103010837.GC95113@mdounin.ru> Hello! On Wed, Jan 01, 2014 at 10:37:09PM -0500, S.A.N wrote: > Заметили очень неприятный баг, в результате которого, клиенты получали > пустую страницу. > > Конфиг кеширования: > > fastcgi_cache_path cache levels=1:2 keys_zone=cache:256m inactive=1d; > > fastcgi_cache cache; > fastcgi_cache_lock on; > fastcgi_cache_revalidate on; > fastcgi_cache_methods GET HEAD; > fastcgi_cache_valid 200 301 302 0s; > fastcgi_cache_key "$host$uri$is_args$args"; > fastcgi_cache_use_stale error updating http_503; > > Воспроизводится баг следующим образом, бекенд при ревалидации отвечает > статусом 304 и в соответсвии с HTTP спецификации, повторно высылает хедеры: > > Last-Modified и Cache-Control: max-age=1. > В данном статусе бекенд отдает только хедеры без body. > Nginx реагирует на хедер Cache-Control, в котором значения max-age больше > нуля и сохраняет данный ответ в свой файл кеша, при условии что файла в кеше > Nginx ещё или уже нет, в нашем случаи это было по причине устаревания кеша > по директиве inactive, Если файла в кеше нет - то откуда взялся ответ 304? -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Fri Jan 3 07:31:28 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 03 Jan 2014 02:31:28 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <20140103010837.GC95113@mdounin.ru> References: <20140103010837.GC95113@mdounin.ru> Message-ID: > Если файла в кеше нет - то откуда взялся ответ 304? Ответ 304 появился, потому что клиент прислал HTTP_IF_NONE_MATCH, т.е ревалидация была произведена по Etag, в нашем конфиге Nginx есть строка fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; она нам нужна, потому что во многих местах используем только клиент (private) кеширования на ETag. Я понял в чем проблема, Nginx при отсутствии своего файл кеша, удаляет хедеры If-Modified-Since и If-None-Match Мы в конфиге востонавливаем клиенский хедер If-None-Match и по нему происходит ревалидации не в зависимости от наличия или отсутствия файла кеша в Nginx, из-за это и проблемы. Ок, как нам правильно поступить, клиенские хедеры If-None-Match нам нужны, потому что по нему происходит ревалидация клиентского приватного кеша, если его отключить тогда мы не сможем ревалидировать клиенский кеш по If-None-Match. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245967#msg-245967 From nginx-forum at nginx.us Fri Jan 3 07:41:03 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 03 Jan 2014 02:41:03 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <20140103010837.GC95113@mdounin.ru> References: <20140103010837.GC95113@mdounin.ru> Message-ID: <6a250e184ff70b50833d93b36a8c085d.NginxMailingListRussian@forum.nginx.org> В принципе можно сделать чтобы бекенд на публичный кеш (public) не отдавал ETag, на приватный кеш (private) отдавать хедер ETag, чтобы можно было по нему ревалидировать. По идеи это временное решения, когда Nginx сделает поддержку ETag можно будет снова его в включить в публичный кеш. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245968#msg-245968 From public-mail at alekciy.ru Fri Jan 3 08:49:26 2014 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Fri, 3 Jan 2014 12:49:26 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvQuCDQv9C+INGD0LzQvtC70YfQsNC90LjRjg==?= In-Reply-To: <13614202.GARY9gDUlL@vbart-laptop> References: <13614202.GARY9gDUlL@vbart-laptop> Message-ID: Ну это то, что находится в официальном репозитории debian 7-ой версии. 2013/12/29 Валентин Бартенев > On Sunday 29 December 2013 12:30:39 Алексей Сундуков wrote: > > [~]# uname -a > > Linux ww-realty.ru 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 > > GNU/Linux > > [~]# nginx -v > > nginx version: nginx/1.2.1 > > [~]# nginx -V > > nginx version: nginx/1.2.1 > > TLS SNI support enabled > > configure arguments: --prefix=/etc/nginx > --conf-path=/etc/nginx/nginx.conf > > --error-log-path=/var/log/nginx/error.log > > --http-client-body-temp-path=/var/lib/nginx/body > > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > > --http-log-path=/var/log/nginx/access.log > > --http-proxy-temp-path=/var/lib/nginx/proxy > > --http-scgi-temp-path=/var/lib/nginx/scgi > > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi > > --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid > > --with-pcre-jit --with-debug --with-http_addition_module > > --with-http_dav_module --with-http_geoip_module > > --with-http_gzip_static_module --with-http_image_filter_module > > --with-http_realip_module --with-http_stub_status_module > > --with-http_ssl_module --with-http_sub_module --with-http_xslt_module > > --with-ipv6 --with-sha1=/usr/include/openssl > > --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module > > > > На всякий случай прокомментирую. > > Это пакет из неофициального репозитория и к тому же устаревшей версии. > Правильно nginx ставить отсюда: http://nginx.org/ru/linux_packages.html > > -- > Валентин Бартенев > http://nginx.com/ > _______________________________________________ > 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 anatoly at sonru.com Fri Jan 3 11:16:33 2014 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 3 Jan 2014 11:16:33 +0000 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <6a250e184ff70b50833d93b36a8c085d.NginxMailingListRussian@forum.nginx.org> References: <20140103010837.GC95113@mdounin.ru> <6a250e184ff70b50833d93b36a8c085d.NginxMailingListRussian@forum.nginx.org> Message-ID: поддержка E-Tag в Nginx была всегда, как минимум в виде трансляции заголовка с бэк-енда. С версии 1.3.3 Nginx научился ее включать/выключать http://nginx.org/en/docs/http/ngx_http_core_module.html#etag Не забывайте, что еще есть разница между weak/strong E-Tag, согласно RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3) Nginx откусывает E-Tag при некоторых условиях, например, при включенном gzip, когда body (и следовательно, E-Tag) передается модифицированным. С другой стороны, Last-Modified не изменяется gzip-сжатием и вы можете использовать его для реализации Conditional-Get. Анатолий On 03 Jan 2014, at 07:41, S.A.N wrote: > В принципе можно сделать чтобы бекенд на публичный кеш (public) не отдавал > ETag, на приватный кеш (private) отдавать хедер ETag, чтобы можно было по > нему ревалидировать. > По идеи это временное решения, когда Nginx сделает поддержку ETag можно > будет снова его в включить в публичный кеш. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245968#msg-245968 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Fri Jan 3 13:56:55 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 3 Jan 2014 17:56:55 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <20140103010837.GC95113@mdounin.ru> Message-ID: <20140103135655.GK95113@mdounin.ru> Hello! On Fri, Jan 03, 2014 at 02:31:28AM -0500, S.A.N wrote: > > Если файла в кеше нет - то откуда взялся ответ 304? > > Ответ 304 появился, потому что клиент прислал HTTP_IF_NONE_MATCH, т.е > ревалидация была произведена по Etag, в нашем конфиге Nginx есть строка > fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; > она нам нужна, потому что во многих местах используем только клиент > (private) кеширования на ETag. > > Я понял в чем проблема, Nginx при отсутствии своего файл кеша, удаляет > хедеры > If-Modified-Since и If-None-Match > Мы в конфиге востонавливаем клиенский хедер If-None-Match и по нему > происходит ревалидации не в зависимости от наличия или отсутствия файла кеша > в Nginx, из-за это и проблемы. > > Ок, как нам правильно поступить, клиенские хедеры If-None-Match нам нужны, > потому что по нему происходит ревалидация клиентского приватного кеша, если > его отключить тогда мы не сможем ревалидировать клиенский кеш по > If-None-Match. Если вы хотите, чтобы оно работало так, то надо включить в ключ кеширования заголовок If-None-Match - т.к. от него зависит ответ бекенда. -- Maxim Dounin http://nginx.org/ From xinu at list.ru Fri Jan 3 16:13:43 2014 From: xinu at list.ru (=?UTF-8?B?eGludQ==?=) Date: Fri, 03 Jan 2014 20:13:43 +0400 Subject: /usr/bin/ld: cannot find -lperl Message-ID: <1388765622.315074047@f257.i.mail.ru> день добрый, компилировал сегодня на новой машине и встретил (наверное редко тако бывает) : /usr/bin/ld: cannot find -lperl лечится "apt-get   install    libperl-dev" - ubuntu , но хотелось бы что бы ето мне configure  сначала сказал, а то он все принял а  make'y вот не понравилось: +++++ checking for PCRE library ... found checking for PCRE JIT support ... found checking for OpenSSL library ... found checking for zlib library ... found checking for libxslt ... found checking for libexslt ... found checking for GD library ... found checking for perl  + perl version: This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi  + perl interpreter multiplicity found checking for GeoIP library ... found creating objs/Makefile Configuration summary   + using system PCRE library   + using system OpenSSL library   + md5: using OpenSSL library   + sha1: using OpenSSL library   + using system zlib library $ make ....         objs/src/http/modules/ngx_http_upstream_least_conn_module.o \         objs/src/http/modules/ngx_http_upstream_keepalive_module.o \         objs/src/http/modules/ngx_http_stub_status_module.o \         objs/ngx_modules.o \         -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lxml2 -lxslt -lexslt -lgd -lGeoIP \         -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.14/CORE -lperl -ldl -lm -lpthread -lc -lcrypt /usr/bin/ld: cannot find -lperl collect2: error: ld returned 1 exit status make[1]: *** [objs/nginx] Error 1 make[1]: Leaving directory `/home/yyyy/yyy/nginx-1.5.8' make: *** [build] Error 2 +++++ после инстялляции libperl-dev (ubuntu)  все ок +++++ checking for PCRE library ... found checking for PCRE JIT support ... found checking for OpenSSL library ... found checking for zlib library ... found checking for libxslt ... found checking for libexslt ... found checking for GD library ... found checking for perl  + perl version: This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi  + perl interpreter multiplicity found checking for GeoIP library ... found creating objs/Makefile Configuration summary   + using system PCRE library   + using system OpenSSL library   + md5: using OpenSSL library   + sha1: using OpenSSL library   + using system zlib library $ make ....     objs/src/http/modules/ngx_http_upstream_keepalive_module.o \         objs/src/http/modules/ngx_http_stub_status_module.o \         objs/ngx_modules.o \         -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lxml2 -lxslt -lexslt -lgd -lGeoIP \         -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.14/CORE -lperl -ldl -lm -lpthread -lc -lcrypt make[1]: Leaving directory `/home/yyyy/yyy/nginx-1.5.8' make -f objs/Makefile manpage make[1]: Entering directory `/home/yyyy/yyy/nginx-1.5.8' sed -e "s|%%PREFIX%%|/srv/nginx-1.5.8|" \                 -e "s|%%PID_PATH%%|/srv/nginx-1.5.8/logs/nginx.pid|" \                 -e "s|%%CONF_PATH%%|/srv/nginx-1.5.8/conf/nginx.conf|" \                 -e "s|%%ERROR_LOG_PATH%%|/srv/nginx-1.5.8/logs/error.log|" \                 < man/nginx.8 > objs/nginx.8 make[1]: Leaving directory `/home/yyyy/yyy/nginx-1.5.8' +++++ подправьте пожалуйста  configure / make спасибо. с ув. Сергей -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Jan 3 21:04:03 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 03 Jan 2014 16:04:03 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <6634d1ca90d52c6a1eb4bffdcb2fc66d.NginxMailingListRussian@forum.nginx.org> > поддержка E-Tag в Nginx была всегда, как минимум в виде трансляции > заголовка с бэк-енда. С версии 1.3.3 Nginx научился ее > включать/выключать > http://nginx.org/en/docs/http/ngx_http_core_module.html#etag > > Не забывайте, что еще есть разница между weak/strong E-Tag, > согласно RFC > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3) > Nginx откусывает E-Tag при некоторых условиях, например, при > включенном gzip, > когда body (и следовательно, E-Tag) передается модифицированным. > > С другой стороны, Last-Modified не изменяется gzip-сжатием > и вы можете использовать его для реализации Conditional-Get. Да, я знаю, но речь шла про отсутствия возможности ревалидации Nginx кеша по If-None-Match (ETag) Последняя версия Nginx 1.5.8, деректива fastcgi_cache_revalidate on, включает ревалидацию только по If-Modified-Since (Last-Modified), в будущих версиях обещают добавить возможность ревалидации по If-None-Match (ETag) Насчет weak ETag, наш бекенд отдает уже сжатый ответ, в конфиге Nginx есть директива gunzip on, которая отдает не сжатый ответ для клиентов которые не поддерживают сжатые ответы. Так же этот модуль удаляет хедер ETag, пробовали использовать weak ETag (например - W/"?."), результат тот же, Nginx удаляет ETag, возможно сейчас что-то поменялось, надо будет проверить на новых версиях Nginx. Насчет ревалидации кеша по If-Modified-Since (Last-Modified), это не просто если на сайте миллионы страниц, потому что придется хранить для каждой страницы последнюю дату модификации чтобы сравнивать с датой, которая пришла от клиент в хедере If-Modified-Since, проблема даже не в кол-ве записей Memcache это выдержит, проблема в том что эти записи надо как-то обновлять, т.е после операций UPDATE, DELETE, INSERT в СУБД, надо обновить все Last-Modified страниц которые были изменены этими запросами. Это означает, что ещё надо хранить связи между страницами и рекурсивно обновлять эти даты для всех страниц, так как Memcache не подтерживает множественных апдейтов, на каждое изменения надо будет отдельный запрос в Memcache, в общем выходит очень не эффективная работа, с ETag все намного красивей и проще, если будет интересно могу рассказать подробней. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245988#msg-245988 From nginx-forum at nginx.us Fri Jan 3 22:37:53 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 03 Jan 2014 17:37:53 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <20140103135655.GK95113@mdounin.ru> References: <20140103135655.GK95113@mdounin.ru> Message-ID: <25c2a9756a3d5d6e74f11057c4fd6475.NginxMailingListRussian@forum.nginx.org> > Если вы хотите, чтобы оно работало так, то надо включить в ключ > кеширования заголовок If-None-Match - т.к. от него зависит ответ > бекенда. Нет, так делать не надо, потому что на один uri может быть только один актуальный ETag, новые значения ETag означают обязательную инвалидацию всех предыдущих значений ETag для этого uri, т.е если мы ETag добавим в ключ кеша, только один ключ будет актуальным все остальные ключи по этому uri, будут лежать как мусор потому что они не могут быть актуальными и их нельзя отдавать клиенту, значит и смысла их хранить в кеше нет. Проблему с кешированием 304 статуса, мы решили ещё проще ? бекенд теперь проверяет значения If-Modified-Since, если оно пустое, ревалидация не проводится, страница будет генерироватся полностью со статусом 200, даже если хедер If-None-Match не пустой и является актуальным. Это корректное условия для ревалидации клиентского кеширования и для кеширования Nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245989#msg-245989 From mdounin at mdounin.ru Sat Jan 4 00:30:18 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 4 Jan 2014 04:30:18 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <25c2a9756a3d5d6e74f11057c4fd6475.NginxMailingListRussian@forum.nginx.org> References: <20140103135655.GK95113@mdounin.ru> <25c2a9756a3d5d6e74f11057c4fd6475.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140104003018.GM95113@mdounin.ru> Hello! On Fri, Jan 03, 2014 at 05:37:53PM -0500, S.A.N wrote: > > Если вы хотите, чтобы оно работало так, то надо включить в ключ > > кеширования заголовок If-None-Match - т.к. от него зависит ответ > > бекенда. > > Нет, так делать не надо, потому что на один uri может быть только один > актуальный ETag, новые значения ETag означают обязательную инвалидацию всех > предыдущих значений ETag для этого uri, т.е если мы ETag добавим в ключ > кеша, только один ключ будет актуальным все остальные ключи по этому uri, > будут лежать как мусор потому что они не могут быть актуальными и их нельзя > отдавать клиенту, значит и смысла их хранить в кеше нет. Если от заголовка If-None-Match зависит ответ бекенда, то он должен быть в ключе кеширования - либо явно, либо неявно (e.g. через запрет кеширования ответов на запросы, где этот заголовок присутствует). Что до сопутствующих накладных расходов - то они есть повод задуматься о том, нужна ли вам такая схема работы. > Проблему с кешированием 304 статуса, мы решили ещё проще ? бекенд теперь > проверяет значения If-Modified-Since, если оно пустое, ревалидация не > проводится, страница будет генерироватся полностью со статусом 200, даже > если хедер If-None-Match не пустой и является актуальным. > Это корректное условия для ревалидации клиентского кеширования и для > кеширования Nginx. Если значение If-Modified-Since не пустое из-за fastcgi_cache_revalidate - то заголовок If-None-Match у вас не имеет никакого отношения к тому, что, собственно, ревалидируется. И если отдать 304 на основании значения If-None-Match, то в кеше nginx'а будет оставлен потенциально устаревший ответ. Т.е. If-None-Match нужно просто убрать из рассмотрения при генерации ответа на бекенде, иначе корректной работы не добиться. Возвращаемся всё к тому же: либо добавлять в ключ кеширования, либо ответ бекенда не должн зависеть от If-None-Match. Собственно, последнее и происходит по умолчанию при использовании кеширования - заголовок If-None-Match из запроса к бекенду убирается. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Sat Jan 4 01:07:41 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 03 Jan 2014 20:07:41 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <20140104003018.GM95113@mdounin.ru> References: <20140104003018.GM95113@mdounin.ru> Message-ID: <3a587c6ead777866f58de23ae01f78df.NginxMailingListRussian@forum.nginx.org> > И если отдать 304 на основании значения If-None-Match, то в кеше > nginx'а будет оставлен потенциально устаревший ответ. Т.е. > If-None-Match нужно просто убрать из рассмотрения при генерации > ответа на бекенде, иначе корректной работы не добиться. Дело в том, что изначально кеширования на бекенде, разрабатывалось для клиентского кеширования (в браузере), как уже писал не однократно, ревалидация происходит по If-None-Match, ревалидировать по заголовоку If-Modified-Since будет очень накладно, для больших сайтов, по этому мы сейчас используем Nginx кеширования на временной интервал. А там где контент завязан на пользователя, используется только клиентское (private) кеширования браузера. Бекенд, не знает и не должен знать, какой тип кеша ему нужно ревалидировать, клиентский или кеш Nginx, по хорошему в первом и во втором случаи, механизм должен быть полностью одинаковым. По этому чтобы иметь возможность использовать клиент кеширования, мы в конфиге прописали fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty Без этого работать с клиенским кешем невозможно, по причине удаления этих заголовком при включении fastcgi_cache_revalidate в Nginx. Наша ошибка была в том, что бекенд приложения игнорировало отсутствия If-Modified-Since, но проводило ревалидацию при наличии If-None-Match и отвечало статусом 304 если ETag актуальный. Мы это исправили добавив проверку на наличия If-Modified-Since. Теперь все работает правильно, при клиент кешировании, мы в заголовок Cache-Control пишем дерективу private, это запретит Nginx кешировать данный ответ и таким образом он не попадет в кеш не при 200 статусе и так же ответ в 304 статусе в кеш не попадет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245996#msg-245996 From nginx-forum at nginx.us Sat Jan 4 04:25:38 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 03 Jan 2014 23:25:38 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <3a587c6ead777866f58de23ae01f78df.NginxMailingListRussian@forum.nginx.org> References: <20140104003018.GM95113@mdounin.ru> <3a587c6ead777866f58de23ae01f78df.NginxMailingListRussian@forum.nginx.org> Message-ID: > Теперь все работает правильно, при клиент кешировании, мы в заголовок > Cache-Control пишем дерективу private, это запретит Nginx кешировать > данный ответ и таким образом он не попадет в кеш не при 200 статусе и > так же ответ в 304 статусе в кеш не попадет. Я поспешил с выводами, что проблема решена. Для клиент (private) кеширования приходится в конфиге писать fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; И в результате выходят те же грабли, бекенд отвечает 304 статсом, если в кеше Nginx нет файлов, он сохраняет этот ответ в файл кеша. Вопрос остаётся открытым, как сделать клиенское (private) кеширования в браузере, но при этом не давать кешить 304 статус? Как вариант, можно при 304 ответе отправлять хедер X-Accel-Expires: 0, чтобы ответ не попал в кеш. Есть более красивые решения этой проблемы? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246004#msg-246004 From chipitsine at gmail.com Sat Jan 4 08:10:44 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 4 Jan 2014 14:10:44 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <20140104003018.GM95113@mdounin.ru> <3a587c6ead777866f58de23ae01f78df.NginxMailingListRussian@forum.nginx.org> Message-ID: а расскажите, о каких ресурсах идет речь ? если это js/css/картинка, ее всегда можно переименовать с хешем и добавить Cache-Control: max-age=очень-много и никаких 304-х (браузер делает If-none-match/if-modified-since только в случае, если в ответе не было max-age или Expire) 4 января 2014 г., 10:25 пользователь S.A.N написал: >> Теперь все работает правильно, при клиент кешировании, мы в заголовок >> Cache-Control пишем дерективу private, это запретит Nginx кешировать >> данный ответ и таким образом он не попадет в кеш не при 200 статусе и >> так же ответ в 304 статусе в кеш не попадет. > > Я поспешил с выводами, что проблема решена. > Для клиент (private) кеширования приходится в конфиге писать > fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; > fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; > > И в результате выходят те же грабли, бекенд отвечает 304 статсом, если в > кеше Nginx нет файлов, он сохраняет этот ответ в файл кеша. > > Вопрос остаётся открытым, как сделать клиенское (private) кеширования в > браузере, но при этом не давать кешить 304 статус? > > Как вариант, можно при 304 ответе отправлять хедер X-Accel-Expires: 0, чтобы > ответ не попал в кеш. > > Есть более красивые решения этой проблемы? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246004#msg-246004 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sat Jan 4 08:48:16 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 04 Jan 2014 03:48:16 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <13082dc3378735b7b66ff16b1591a351.NginxMailingListRussian@forum.nginx.org> > а расскажите, о каких ресурсах идет речь ? > если это js/css/картинка, ее всегда можно переименовать с хешем и > добавить Cache-Control: max-age=очень-много Речь идет, о динамическом контенте, бекенд на РНР. Насчёт статичного контента, я с вами согласен, данный способ самый эффективный, мы так же делаем. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246007#msg-246007 From onokonem at gmail.com Sat Jan 4 09:10:30 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 4 Jan 2014 13:10:30 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <20140104003018.GM95113@mdounin.ru> <3a587c6ead777866f58de23ae01f78df.NginxMailingListRussian@forum.nginx.org> Message-ID: > Есть более красивые решения этой проблемы? А в чем, собственно, состоит проблема? Я вот даже не могу понять - если вы все равно пропускаете все запросы на бекенд для ревалидации по e-tag - зачем у вас включено кеширование на nginx? From nginx-forum at nginx.us Sat Jan 4 10:13:55 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 04 Jan 2014 05:13:55 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: > > Есть более красивые решения этой проблемы? > А в чем, собственно, состоит проблема? > > Я вот даже не могу понять - если вы все равно пропускаете все запросы > на бекенд для ревалидации по e-tag - зачем у вас включено кеширование > на nginx? Не все запросы всегда идут на бекенд, многие из них кешируются на определенный интервал времени, от 1 до 10000 секунд, всё зависит от функционала конкретного скрипта. Есть скрипты которые генерят, страницы под сесию юзера, такие страницы удобно кешить на стороне клиента т.е. в браузере. По этому и возникает проблема, в Nginx все гладко если бекенд использует только Nginx кеширования, или только клиент кеширования при выключенном Nginx кешировании. Наша задача, в рамках одного server{} добится корректной работы клиентского и серверного кеширования. Немного статистики, чтобы показать что это эффективно, ниже цифры выполнения запросов без учета времени на конект 2 ms - Nginx отдает ответ из своего кеша 7 ms - Nginx отправляет запрос на бекенд для ревалидации, бекенду достаточно 5 ms, чтобы отдать 304 статус 60 ms - 800 ms, необходимо РНР для генерации страницы, все зависит от сложности логики срипта и наличии SQL кеша в Memcache. Как видите, разница в скорости в десятки раз отличается, главный плюс ревалидации в том что скорость её выполнения практически не зависит от сложности скрипта который создал эту страницу, потому что алгоритмы ревалидации очень просты и эффективны. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246010#msg-246010 From chipitsine at gmail.com Sat Jan 4 10:21:22 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 4 Jan 2014 16:21:22 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <13082dc3378735b7b66ff16b1591a351.NginxMailingListRussian@forum.nginx.org> References: <13082dc3378735b7b66ff16b1591a351.NginxMailingListRussian@forum.nginx.org> Message-ID: А какого рода динамический контент, можете привести пример? Желательно с примером, когда помогает ревалидация. суббота, 4 января 2014 г. пользователь S.A.N писал: > > а расскажите, о каких ресурсах идет речь ? > > если это js/css/картинка, ее всегда можно переименовать с хешем и > > добавить Cache-Control: max-age=очень-много > > Речь идет, о динамическом контенте, бекенд на РНР. > Насчёт статичного контента, я с вами согласен, данный способ самый > эффективный, мы так же делаем. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245951,246007#msg-246007 > > _______________________________________________ > 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 Jan 4 10:21:36 2014 From: nginx-forum at nginx.us (pferforkersve1986) Date: Sat, 04 Jan 2014 05:21:36 -0500 Subject: she admitted to a australian cardstock Message-ID: <0352ad081148cb1f22c57849cd1f3379.NginxMailingListRussian@forum.nginx.org> Brown held going all the way up until your dog was in Spooner's experience, right in front on the Wizards' bench. Virtually. One is the actual charge so that you can reintroduce guidelines to reduce medical malpractice claims and cut the costs of defensive medicine a move clearly opposed simply by trial lawyers, a key constituency with regard to Democrats. I became young, plus stupid. Clarksdale is starting to look just like Greenville, MS.If you can not like it, and then don't stay there. The corneas, muscle tissue, cuboid and beautiful, unwrinkled pores and skin will increase the quality of lifestyle for numerous others. Etc. I think it breaks up the bright field and also makes the unvarying look uneven. But still, I enjoy Nice color of aqua, mixed in with a little burgundy red on the edges. "In law enforcement, you should protect your mates and your friends as well.In. Comfortable, lovely and multipurpose, this gown is a musthave for your wardrobe. (Obtain). Coutts says a bonspiel's future is definitely ultimately going to need to be formed by the being different clubs as well as their memberships. And i like an idea of Supporting they by doing a Recognition to the Teams of New Orleans because Hornets is the Only workforce in New Orleans that actually have knowledge of how to gain and could be the one Professional Series in Brand new Orleans to give it it is really first ever Great.. Perhaps, proposes Albert, we might be interested in some sort of paragliding adventure?. Also, he caught Eighteen passes regarding 312 yards and 3 touchdowns. Since the 1920s the event sport regarding professional soccer has had its hands strongly on the United states heartstrings and has become the second eldest of American group sports just yielding its age to specialist baseball. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246011,246011#msg-246011 From chipitsine at gmail.com Sat Jan 4 10:30:45 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 4 Jan 2014 16:30:45 +0600 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvQuCDQv9C+INGD0LzQvtC70YfQsNC90LjRjg==?= In-Reply-To: <13614202.GARY9gDUlL@vbart-laptop> References: <13614202.GARY9gDUlL@vbart-laptop> Message-ID: Добрый день! А не пробовали связываться с разработчика ми основных дистрибутивов, чтобы прямо в дистрибутиве был правильный nginx с правильными модулями. Мысль первая - когда патчил nginx до версии 1.4.4 (по причине выхода обновления безопасности), на одном из серверов Ubuntu обновил через родной убунтовский aptitude, прилетело 1.1.9, кажется. Мысль вторая - в рассылке довольно частая ситуация, когда nginx падает в core, начинается расследование, оказывается, что он собран с кучей не пойми каких модулей, а у пользователя он оказался .... из стандартного репозитория воскресенье, 29 декабря 2013 г. пользователь Валентин Бартенев писал: > On Sunday 29 December 2013 12:30:39 Алексей Сундуков wrote: > > [~]# uname -a > > Linux ww-realty.ru 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 > > GNU/Linux > > [~]# nginx -v > > nginx version: nginx/1.2.1 > > [~]# nginx -V > > nginx version: nginx/1.2.1 > > TLS SNI support enabled > > configure arguments: --prefix=/etc/nginx > --conf-path=/etc/nginx/nginx.conf > > --error-log-path=/var/log/nginx/error.log > > --http-client-body-temp-path=/var/lib/nginx/body > > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > > --http-log-path=/var/log/nginx/access.log > > --http-proxy-temp-path=/var/lib/nginx/proxy > > --http-scgi-temp-path=/var/lib/nginx/scgi > > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi > > --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid > > --with-pcre-jit --with-debug --with-http_addition_module > > --with-http_dav_module --with-http_geoip_module > > --with-http_gzip_static_module --with-http_image_filter_module > > --with-http_realip_module --with-http_stub_status_module > > --with-http_ssl_module --with-http_sub_module --with-http_xslt_module > > --with-ipv6 --with-sha1=/usr/include/openssl > > --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair > > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module > > > > На всякий случай прокомментирую. > > Это пакет из неофициального репозитория и к тому же устаревшей версии. > Правильно nginx ставить отсюда: http://nginx.org/ru/linux_packages.html > > -- > Валентин Бартенев > http://nginx.com/ > _______________________________________________ > 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 Jan 4 11:21:13 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 04 Jan 2014 06:21:13 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <1648470526ab0e1e28d82f30797ee8e5.NginxMailingListRussian@forum.nginx.org> > А какого рода динамический контент, можете привести пример? Желательно > с > примером, когда помогает ревалидация. Например, блоги наших клиентов, есть открытые публичные блоги есть закрытые приватные, в каждом блоге возможны комментарии посетителей. Спрогнозировать динамику изменений блога или новых комментариев сложно. По этому самое оптимальное решения, кешировать и динамические ревалидировать. Для анонимных гостей мы используем public, max-age=120, для залогиненых юзеров мы используем private, max-age=0, это означает кешить только в браузере и каждый запрос отправлять на сервер для ревалидации, кстати github.com делает так же private, max-age=0 и 304 статус если ETag актуальный. Статистика показывает что залогиненые пользователи делают много повторных запросов на один uri, т.е там будет использоваться кеш браузера, для анонимных пользователей будет использоваться общий кеш Nginx который ревалидируется раз в две минуты. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246014#msg-246014 From onokonem at gmail.com Sat Jan 4 11:29:21 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 4 Jan 2014 15:29:21 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <1648470526ab0e1e28d82f30797ee8e5.NginxMailingListRussian@forum.nginx.org> References: <1648470526ab0e1e28d82f30797ee8e5.NginxMailingListRussian@forum.nginx.org> Message-ID: > Статистика показывает что залогиненые пользователи делают много повторных > запросов на один uri, т.е там будет использоваться кеш браузера, для > анонимных пользователей будет использоваться общий кеш Nginx который > ревалидируется раз в две минуты. Тогда возвращаемся к ответу Максима. Все - то есть, абсолютно - параметры, от которых зависит или может зависеть ответ бекенда, должны быть включены в ключ кеша. Не включать какие-либо из них в ключ - это стрелять себе в ногу (и ваш пример в этом смысле - хрестоматийный). From chipitsine at gmail.com Sat Jan 4 11:50:31 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 4 Jan 2014 17:50:31 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <1648470526ab0e1e28d82f30797ee8e5.NginxMailingListRussian@forum.nginx.org> References: <1648470526ab0e1e28d82f30797ee8e5.NginxMailingListRussian@forum.nginx.org> Message-ID: блоги на каком движке написаны? суббота, 4 января 2014 г. пользователь S.A.N писал: > > А какого рода динамический контент, можете привести пример? Желательно > > с > > примером, когда помогает ревалидация. > > Например, блоги наших клиентов, есть открытые публичные блоги есть закрытые > приватные, в каждом блоге возможны комментарии посетителей. Спрогнозировать > динамику изменений блога или новых комментариев сложно. По этому самое > оптимальное решения, кешировать и динамические ревалидировать. Для > анонимных > гостей мы используем public, max-age=120, для залогиненых юзеров мы > используем private, max-age=0, это означает кешить только в браузере и > каждый запрос отправлять на сервер для ревалидации, кстати github.comделает > так же private, max-age=0 и 304 статус если ETag актуальный. > Статистика показывает что залогиненые пользователи делают много повторных > запросов на один uri, т.е там будет использоваться кеш браузера, для > анонимных пользователей будет использоваться общий кеш Nginx который > ревалидируется раз в две минуты. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245951,246014#msg-246014 > > _______________________________________________ > 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 ksyblast at gmail.com Sat Jan 4 12:01:16 2014 From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=) Date: Sat, 4 Jan 2014 15:01:16 +0300 Subject: ngx_http_geo_module range overlaps Message-ID: Добрый день. Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести пересекающиеся диапазоны адресов. В документации: A value of the most specific match is used. For example, for the 127.0.0.1 address the value "RU" will be chosen, not "US". Example with ranges: geo $country { ranges; default ZZ; 127.0.0.0-127.0.0.0 US; 127.0.0.1-127.0.0.1 RU; 127.0.0.1-127.0.0.255 US; 10.1.0.0-10.1.255.255 RU; 192.168.1.0-192.168.1.255 UK; } Пытаюсь воспроизвести этот пример: /etc/init.d/nginx reload * Checking nginx' configuration ... nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" in /etc/nginx/sites/test-geo.conf:6 nginx: configuration file /etc/nginx/nginx.conf test failed nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" in /etc/nginx/sites/test-geo.conf:6 nginx: configuration file /etc/nginx/nginx.conf test failed /etc/nginx/sites/test-geo.conf: geo $country { ranges; default ZZ; 127.0.0.0-127.0.0.0 US; 127.0.0.1-127.0.0.1 RU; 127.0.0.1-127.0.0.255 US; 10.1.0.0-10.1.255.255 RU; 192.168.1.0-192.168.1.255 UK; } nginx -V nginx version: nginx/1.4.4 configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error_log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib --http-log-path=/var/log/nginx/access_log --http-client-body-temp-path=//var/lib/nginx/tmp/client --http-proxy-temp-path=//var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=//var/lib/nginx/tmp/fastcgi --http-scgi-temp-path=//var/lib/nginx/tmp/scgi --http-uwsgi-temp-path=//var/lib/nginx/tmp/uwsgi --with-file-aio --with-aio_module --with-pcre --with-pcre-jit --without-http_empty_gif_module --without-http_fastcgi_module --without-http_map_module --without-http_memcached_module --without-http_scgi_module --without-http_split_clients_module --without-http_uwsgi_module --with-http_addition_module --with-http_image_filter_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --add-module=/var/tmp/portage/www-servers/nginx-1.4.4/work/headers-more-nginx-module-0.22 --add-module=/var/tmp/portage/www-servers/nginx-1.4.4/work/ngx-fancyindex-0.3.2 --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --user=nginx --group=nginx Gentoo Base System release 2.2 uname -a Linux 3.0.78 #1 SMP Mon May 20 15:17:58 FET 2013 x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux В чем может быть дело? Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Jan 4 12:23:26 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 04 Jan 2014 07:23:26 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <780e7538e3f4eeafe199b953563ba8ee.NginxMailingListRussian@forum.nginx.org> > Тогда возвращаемся к ответу Максима. Все - то есть, абсолютно - > параметры, от которых зависит или может зависеть ответ бекенда, > должны быть включены в ключ кеша. Я не понимаю, как добавления в ключ кеша хедера if_none_match, может решить проблему, автоматического удаления из запроса к бекенду клиент хедеров if_none_match и if_modified_since, вы же понимаете чтобы работать с клиентским кешем бекенду нужны клиентские заголовки if_none_match и if_modified_since, но Nginx их удаляет, если в папке Nginx Кеша нет файла по этому ключу, данного файла там никогда не будет, потому что этот uri всегда генерируется с Cache-Control: private. Да мы можем в конфиге прописать fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; но тогда мы получим кеширования страницы в 304 статусе, если в момент запроса в папке кеша Nginx не будет файлов кеша по этому ключу, но браузер выслал правильные и актуальные заголовки и получил от бекенда статус 304, Nginx благополучно положит этот ответ в свой файл кеш. Вот в чем дело и ключ Кеша здесь не причем. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246021#msg-246021 From onokonem at gmail.com Sat Jan 4 12:40:01 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 4 Jan 2014 16:40:01 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <780e7538e3f4eeafe199b953563ba8ee.NginxMailingListRussian@forum.nginx.org> References: <780e7538e3f4eeafe199b953563ba8ee.NginxMailingListRussian@forum.nginx.org> Message-ID: 2014/1/4 S.A.N : > Я не понимаю, как добавления в ключ кеша хедера if_none_match, может решить > проблему, Зато я, наконец, понял, о какой проблеме речь :) О рассинхронизации клиентского кеша и кеша nginx. У клиентов файл в кеше, в nginx кеше его нет - и мы имеем 304 закешированным (потому, что специально разрешили кешировать 304). А как ведет себя fastcgi_cache_valid 304 0; ? From nginx-forum at nginx.us Sat Jan 4 13:00:54 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 04 Jan 2014 08:00:54 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: > О рассинхронизации клиентского кеша и кеша nginx. У клиентов файл в > кеше, в nginx кеше его нет - и мы имеем 304 закешированным (потому, > что специально разрешили кешировать 304). > > А как ведет себя fastcgi_cache_valid 0s Вот кофиг fastcgi_cache cache; fastcgi_cache_lock on; fastcgi_cache_revalidate on; fastcgi_cache_methods GET HEAD; fastcgi_cache_valid 200 301 302 0s; fastcgi_cache_key "$host$uri$is_args$args"; fastcgi_cache_use_stale error updating http_503; Деректива, fastcgi_cache_valid, не влияет если бекенд отдает заголовки Cache-Control, потому что данные заголовки приоритетней деректив из конфига. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246024#msg-246024 From nginx-forum at nginx.us Sat Jan 4 13:11:39 2014 From: nginx-forum at nginx.us (agstorenut1989) Date: Sat, 04 Jan 2014 08:11:39 -0500 Subject: toronto boss john gibbons states that Message-ID: <752907a7e85b8e3b30ea417779d72541.NginxMailingListRussian@forum.nginx.org> But if not really him the particular Fins really need to get one of the additional 3 men.. Yet Adrienne claims she seasoned little difficulties "becoming Canadian.In She had assist where the idea mattered most in a classroom, at home. Eric Chavez click two homers and Nick Swisher along with Russell Martin connected once each one next day Curtis Granderson hit about three of the Yankees four homers within a 76 wow the Minnesota Twins what 100 years following Red Sox conquer the New york yankees forerunner, the latest York Highlanders, Seventy-six in Eleven innings. Now, with regards to the Cleveland Indians. The political election of Bob Bullock last year will be the third phrase in a row by which Democrats get held the actual governorship.. In a rounded about means, he shared with his players to look at this flag, endure at attention and admire your region and the those who do so very much for it.. Installed Memories works by using over 50,500 sq. Walt disney is producing several projects specifically for the girl. The sizing chart may be used creating the customized reversible nhl jerseys for the soccer team. He / she loved the tight stop since her days from Florida, as well as friends told him to discover what he / she could get for these people on craigslist and ebay after listening to that quite a few jerseys had been going for lots of money. The face mask on the lid was glowing blue from 1974 through 1986 before changing to be able to white. That will get you a full, as brand-new rebuilt equipment, looking plus performing identically to after they first mailed that machine out of the manufacturing unit.. Fisk won the AL Silver Glove at Catcher and the AL Rookie of the Year awards which year. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246025,246025#msg-246025 From nginx-forum at nginx.us Sat Jan 4 13:14:47 2014 From: nginx-forum at nginx.us (soaversrasom1977) Date: Sat, 04 Jan 2014 08:14:47 -0500 Subject: a ex - bike courier service from lake oswego Message-ID: <0e04d60afc8694562fd31c5b1cd79b7e.NginxMailingListRussian@forum.nginx.org> By Seven o'clock, urbanites giddy within the sight regarding ripe tomato vegetables are crowding and ready to obtain. Union Rectangle Greenmarket is the main farmers market in the location. At this junction of several subway lines are colorful simple guidelines of out of the way bounty: red-colored peppers, violet eggplants, and older squash. Frostblue Rapport grapes project their scent. You must be registered to opinion (your brief review will be saved for you while you register). It can be quick (it takes about 30 seconds) and then we only require your email as well as name. Feedback that include almost any offensive materials are restricted. By using our site you accept our comparison to its use. This North western city, featuring a landscape, the culture, its people and it is pitfalls, is a living, breathing character with AMC's "Breaking Bad.In . When the remaining eight instances of "Breaking Bad' get ongoing Aug. 12, many followers will experience a painful withdrawal at a drama that is become evermore hard to kick since the 2008 first appearance. Of course, a town is only just as real as what's inside their borders. Here's six accounts behind reallife spots of "Breaking Bad." Full Story If walking the boardwalk gets weary, hire a rolling chair reminiscent of your rickshaw and sent by a man or woman. As long lasting as the moving chair history is the stage to which you're going to be hassled to hire a single: you'll be neared nonstop to help takes tours, no matter where that you are on the boardwalk. Rates vary from a few bucks to well over $20 depending on the yardage and the retailer. However that you are getting around, solid a inquiring glance at the Nadine Boggs Father Pavilion, between New york city and Ky Avenues: is it doesn't site of the future Atlantic Town Boardwalk Holocaust Memorial, the actual winning model for which will likely be selected in late September. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246026,246026#msg-246026 From nginx-forum at nginx.us Sat Jan 4 13:47:59 2014 From: nginx-forum at nginx.us (petquasatro1982) Date: Sat, 04 Jan 2014 08:47:59 -0500 Subject: mister toad udo kier and magpie dreary delisle Message-ID: There was some good news yesterday besides a big day via Cory Sullivan as the Mets reported they are cutting ticket charges for some game titles the rest of the yr. I guess perhaps the Wilpons feel bad receiving their true customers $180 for any close look in Anderson Hernandez and Angel Berroa. However, at $90 money a place, I fairly stay home and enjoy the guy tear my kitchen aside. Sorry Hidden, but our guy is putting in some sort of blue and also orange counter top. By the 1920's, the showiest cities, Atlantic Metropolis and Asbury Recreation area, had become real citieswith casinos, leisure palaces, and grand hotelswhose living depended on this flow of tourist website traffic. The story of the Banks in the second half of the twentieth century can be of its slow climb back to prosperity: first from the problem of the Depressive disorders, and then from the rise with cheap commercial air travel within the postwar period. Nager, Thirty-eight, faced different options. He may ask the limited weasel to move outside, or he may possibly do something about their 250pound frame. He or she opted for tranquility and a new waistline. (Dish replacement beverages not to suit your needs? Pick up a duplicate of Take in This, Not too! for various other ways to lose weight together with liquids.) Most people totalled 560 points for that '70s, any narrow triumph of three percent over the subsequent closest ten years of the 1990s, followed by your 1980s, 2000s, and 1950s (that is only 15% reduce). Unique as well as original styles have been introduced by every single carmaker through the decades, along with the scores for each and every tenyear period have been relatively close. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246027,246027#msg-246027 From nginx-forum at nginx.us Sat Jan 4 13:50:21 2014 From: nginx-forum at nginx.us (petquasatro1982) Date: Sat, 04 Jan 2014 08:50:21 -0500 Subject: there had not been mistaking the swing Message-ID: <433243fbf5b744516dfd1ccf29d7b119.NginxMailingListRussian@forum.nginx.org> The following junior womens one make (right) hat is made of polyester and spandex mesh stretch materials with internal lining. Virtually all letters, statistics and art logos are sewnon, figures are triplestitched the same as on cycling jerseys players work with during a game. A tiny strap may be used over remaining shoulder with regard to secure suit. Junior Girls sizing you need to look at proportions chart for correct fit. Almost all of real oregonians provide fish out. trout absolutely no. you can't keep a native simply a planter. keep your dish. It was an exquisite area to mature in, since we never had to be able to lock our homes or cars, and youngsters were harmless to go just about anywhere at anytime. Each and every summer, i'd have to deal with many of the tourist targeted traffic and the moving California Quit. In the drop, the Mexicians would likely arrive to figure the fresh fruit, but by means of December, merely the locals always been. More than half (Fifty four percent) of those planning to dress up this year express they will sometimes combine brand-new and used items or make its costume manually ,. and Canada and the biggest selection of new and used costumes, accessories, makeup and residential decor associated with a retailer, Savers is the best retail store destination for lastminute fancy dress costumes. A Halloween night "store within a store" at intervals of Savers place features new costumes starting at $9.98, wigs starting up at $5.Ninety nine and brand new seasonal add-ons as low as $1.Ninety nine. Combined with shelves of delicately worn gifts at a portion of the primary price, purchasers are able to be ingenious and inventive in creating a exclusive costume that fits within just about any budget even though standing out in the crowd. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246028,246028#msg-246028 From nginx-forum at nginx.us Sat Jan 4 13:56:00 2014 From: nginx-forum at nginx.us (flusondini1984) Date: Sat, 04 Jan 2014 08:56:00 -0500 Subject: but it is a excellent notion to check out what is out there regionally since nicely Message-ID: <4077855be509f2643f92f33158bcb9a1.NginxMailingListRussian@forum.nginx.org> For those OK with the mainstream, Whitened River Woodland welcomes above 10 million readers a year, which makes it the mostvisited excitement forest in the nation. But don't don't like it to be beautiful; it has substance, very. The natrual enviroment boasts Seven wilderness spots, 2,400 miles connected with trail, 1,900 distance of turning service method roads, and also 12 snowboard resorts (should your snow shredders fit the spine space). Throughout 1974, this standing bison logo seemed to be replaced by the blue charging you one with a red slanting stripe surging from its horn. Back in 1984, the helmet's track record color seemed to be changed by white for you to red, supposedly in part to distinguish them far more readily via three of their total division competitors at that time, the particular Indianapolis Colts, the particular Miami Fish, and the New England Patriots, who just about all also was wearing white headwear at that point. In that case in 2008, a richer shade connected with blue as well as nickel were being introduced, along with red and white conduit trimming on the Buffalo Bills jerseys and pants. The original shades connected with red and blue, on the other hand, were contained as striping colorations. They are also even now used on their logos. A Panthers players want it. The followers like it.Now there absolutely no way that it's a better homogeneous than a lot of the NFL most triedandtrue combos, however, like the types Pittsburgh, Green Bay, Dallas, Oregon and Contra costa wear, as an example. Those blackonblack outfits just getaway been through sufficient wars.At the same time, though, consider this a request for more blackonblack for your Panthers. Even if the Monitor gets his or her way they usually don earn... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246029,246029#msg-246029 From vbart at nginx.com Sat Jan 4 14:12:25 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 04 Jan 2014 18:12:25 +0400 Subject: ngx_http_geo_module range overlaps In-Reply-To: References: Message-ID: <14955485.co9pbvDmNh@vbart-laptop> On Saturday 04 January 2014 15:01:16 Ксения Юрьевна Блащук wrote: > Добрый день. > Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести > пересекающиеся диапазоны адресов. В документации: > > A value of the most specific match is used. For example, for the 127.0.0.1 > address the value "RU" will be chosen, not "US". > > Example with ranges: > > geo $country { > ranges; > default ZZ; > 127.0.0.0-127.0.0.0 US; > 127.0.0.1-127.0.0.1 RU; > 127.0.0.1-127.0.0.255 US; > 10.1.0.0-10.1.255.255 RU; > 192.168.1.0-192.168.1.255 UK; > } > > Пытаюсь воспроизвести этот пример: > > /etc/init.d/nginx reload > * Checking nginx' configuration ... > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" > in /etc/nginx/sites/test-geo.conf:6 > nginx: configuration file /etc/nginx/nginx.conf test failed > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" > in /etc/nginx/sites/test-geo.conf:6 > nginx: configuration file /etc/nginx/nginx.conf test failed > [..] > > В чем может быть дело? > Спасибо. Это баг в проверке конфигурации. Чтобы его обойти можете поменять местами так чтобы вначале шел больший диапазон: 127.0.0.1-127.0.0.255 US; 127.0.0.1-127.0.0.1 RU; -- Валентин Бартенев From nginx-forum at nginx.us Sat Jan 4 14:59:21 2014 From: nginx-forum at nginx.us (tevechoter1974) Date: Sat, 04 Jan 2014 09:59:21 -0500 Subject: he has been named the most north american patient of the 20th century by espn Message-ID: <29a6087cb952bffb76097b64c26dfb68.NginxMailingListRussian@forum.nginx.org> Charles Ka'upu is best known as the Traditional chanter in the downloads of the favorite musical duo HAPA. But in his / her home in Hawaii, Ka'upu has become a revered expert of the oli (chant) and the hula. His or her family sources come from Molokai as well as Big Island regarding Hawaii. Blessed on Oahu, he migrated in 1993 to Hawaii, where he / she taught heritage, culture and religion from Maui Vocational school and put a radio method on KPOA. To be able to his audience members, he was the charismatic "Bushman." He / she helped identified the total annual Celebration in the Arts Festival in Kapalua. : , Kidada Disney Aladdin Magic Carpeting Charm 14K Gold Plated59. : , Bissell ProHeat 2X Limit and Insert for Drinking water Tank. Fits10. : , Bubba Models 04234 Bubba Keg Travel Coffee mug 34 Oz, Assorted64. : , Purple Lively Pony Equine Watch68. : , Ultimate Biceps Gear Focused Military Stealth Black31. The Bank with England features a novel policy for surviving the present economy: Revealing to female staff members to stop getting dressed like attractive prostitutes. (Refer to it a not any stimulus strategy.) The bank hired on an photograph consultancy organization to train it is lady bankers in a seminar on how to for success. Lucky for us, an organization memo about the workshop was lost to WWD: "Being this University connected with Nike, essentially, we receive a lot of trendy stuff. Plenty of new stuff all the time. Its a prospecting tool,Inch Oregon individual Jeff Maehl stated. "When I was arising on a recruiting trip, these people showed me the various jerseys and also told me about the 100 different uniform a combination." Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246030,246030#msg-246030 From nginx-forum at nginx.us Sat Jan 4 16:28:22 2014 From: nginx-forum at nginx.us (tracresmexo1987) Date: Sat, 04 Jan 2014 11:28:22 -0500 Subject: there was no mistaking the swing Message-ID: <944816357e969b430b7f90bd641ab112.NginxMailingListRussian@forum.nginx.org> Calendar year changes include gray slacks, and a metal silver/gray helmet, much like those utilized by the Ohio State Buckeyes, as well as grey accents around letters, quantities and piping along the back and torso portions of the particular jerseys. Elevated as an American in Virginia Beach. The group was presented singing for hits by means of Will Jackson ("Wild Wid West" from Smith's film of the same title), Foxy Brown (Awful Mama Jamma, which will interpolated Carl Carlton's sonamed hit on the early Eighties era), and Mariah Carey ("The Wonderful Ones", a rebuilding of Prince's hit from 1984's Violet Rain). Very, bad for farmville that they really don't wear the helmet while using TriCorn emblem since they did their own first year.. They may have looked much stronger, and they are rolling over.. Also you can get no cost latitude and longitude coordinates in the topographical map and hang up your Gps unit. Recently, she teamed up together with "Project Runway" designer Kenley Collins to produce a gift established featuring a chiffon headband and a complementing scarlet lipstick. That explains precisely why Notre Dame routinely former pupils 100% and almost that same quantity go on to universities and colleges.I think, not any I know, that most the pessimism expressed below and other areas about Notre Dame will be rooted with jealousy in addition to guilt. Demonstrate the kid some respect. That isn't what this is certainly about, due to the fact I'm likewise offended esthetically, I'm talking about by the "Indians" program on the chest of the typical home jerseys. Email via Kara(ph): I am going to fondly try to remember Tom Keith, your longtime sound clips man with regard to Minnesota Open Radio's "A Prairie Home Associate." They gave many people the gift associated with laughter every week. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246031,246031#msg-246031 From nginx-forum at nginx.us Sat Jan 4 16:51:03 2014 From: nginx-forum at nginx.us (tituasidhigh1978) Date: Sat, 04 Jan 2014 11:51:03 -0500 Subject: the lattercareer group many people formed by using gerald levert Message-ID: Millfield, the thorn within Det. Olivia Benson's (Mariska Hargitay) side, in Tuesday's episode connected with "Law Order: Special Victims Unit" and what an episode it is actually. "It's one of the two shows these are submitting for the Emmy nomination for the show themselves, and the producers also submitted me for any nomination for Visitor Star inside it," reviews the former "NYPD Blue" regular, who received three Emmy nominations and a win to the show.Delaney who personalities with Catherine Bell plus Sally Pressman around Lifetime's June 3 debuting "Army Wives" first showed up for "L in The month of february sweeps, when "Mariska's character came to the site New Jersey to investigate something and then she really need not have been on my personal character's turf. Irrespective of is the creature or the constructure, whatever everywhere will be the inspiration cause of Air Jordan manufacturer which thanks to the multielement feature to help every single version. A breaktought Air Jordan One particular, the permanently classic, Low-priced air jordans 14, the great masterpiece Air Jordan 10, the long term classic, Air Jordan SOME, underneath every model belonging to the Jordans series, an account will always powering, under each and every version of Jordans sequence, the modern and sophisticated technology will certainly forever added into program, less than each version of Nike air jordans sequence, a innovative style and design element will always being intruduced inside. For most people, a budget Air Jordans boots and shoes is not only only a pair of boots with specific workmanship, revolutionary design, sophisticated element, but the story powering it shifted them considerably. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246032,246032#msg-246032 From andrey at kopeyko.ru Sat Jan 4 18:02:00 2014 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Sat, 04 Jan 2014 22:02:00 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93__304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <52C84C98.7030802@kopeyko.ru> 02.01.2014 07:37, S.A.N пишет: > Заметили очень неприятный баг, в результате которого, клиенты получали > пустую страницу. Добрый день! > fastcgi_cache_key "$host$uri$is_args$args"; Это ни разу ни баг - это вы недонастроили. Добавьте в ключ кеширования параметр $http_if_modified_since и наступит вам счастье. Для понимания происходящего рекомендую прочитать http://dklab.ru/chicken/nablas/56.html -- Best regards, Andrey Kopeyko From mdounin at mdounin.ru Sat Jan 4 18:09:29 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 4 Jan 2014 22:09:29 +0400 Subject: ngx_http_geo_module range overlaps In-Reply-To: <14955485.co9pbvDmNh@vbart-laptop> References: <14955485.co9pbvDmNh@vbart-laptop> Message-ID: <20140104180929.GN95113@mdounin.ru> Hello! On Sat, Jan 04, 2014 at 06:12:25PM +0400, Валентин Бартенев wrote: > On Saturday 04 January 2014 15:01:16 Ксения Юрьевна Блащук wrote: > > Добрый день. > > Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести > > пересекающиеся диапазоны адресов. В документации: > > > > A value of the most specific match is used. For example, for the 127.0.0.1 > > address the value "RU" will be chosen, not "US". > > > > Example with ranges: > > > > geo $country { > > ranges; > > default ZZ; > > 127.0.0.0-127.0.0.0 US; > > 127.0.0.1-127.0.0.1 RU; > > 127.0.0.1-127.0.0.255 US; > > 10.1.0.0-10.1.255.255 RU; > > 192.168.1.0-192.168.1.255 UK; > > } > > > > Пытаюсь воспроизвести этот пример: > > > > /etc/init.d/nginx reload > > * Checking nginx' configuration ... > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" > > in /etc/nginx/sites/test-geo.conf:6 > > nginx: configuration file /etc/nginx/nginx.conf test failed > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" > > in /etc/nginx/sites/test-geo.conf:6 > > nginx: configuration file /etc/nginx/nginx.conf test failed > > > [..] > > > > В чем может быть дело? > > Спасибо. > > Это баг в проверке конфигурации. > > Чтобы его обойти можете поменять местами так чтобы вначале шел больший > диапазон: > > 127.0.0.1-127.0.0.255 US; > 127.0.0.1-127.0.0.1 RU; Это не баг, это фича. Код не умеет обрабатывать добавления диапазонов, перекрывающих уже существующие диапазоны, и честно об этом сообщает. При использовании range'ей последующими строками можно переопределить часть ранее заданного диапазона адресов. Задать диапазон, который бы включал в себя ранее заданные диапазоны - нельзя. -- Maxim Dounin http://nginx.org/ From ksyblast at gmail.com Sat Jan 4 18:17:00 2014 From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=) Date: Sat, 4 Jan 2014 21:17:00 +0300 Subject: ngx_http_geo_module range overlaps In-Reply-To: <20140104180929.GN95113@mdounin.ru> References: <14955485.co9pbvDmNh@vbart-laptop> <20140104180929.GN95113@mdounin.ru> Message-ID: Да, спасибо, все так, но очень смутил пример в документации по модулю. Hello! On Sat, Jan 04, 2014 at 06:12:25PM +0400, Валентин Бартенев wrote: > On Saturday 04 January 2014 15:01:16 Ксения Юрьевна Блащук wrote: > > Добрый день. > > Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести > > пересекающиеся диапазоны адресов. В документации: > > > > A value of the most specific match is used. For example, for the 127.0.0.1 > > address the value "RU" will be chosen, not "US". > > > > Example with ranges: > > > > geo $country { > > ranges; > > default ZZ; > > 127.0.0.0-127.0.0.0 US; > > 127.0.0.1-127.0.0.1 RU; > > 127.0.0.1-127.0.0.255 US; > > 10.1.0.0-10.1.255.255 RU; > > 192.168.1.0-192.168.1.255 UK; > > } > > > > Пытаюсь воспроизвести этот пример: > > > > /etc/init.d/nginx reload > > * Checking nginx' configuration ... > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" > > in /etc/nginx/sites/test-geo.conf:6 > > nginx: configuration file /etc/nginx/nginx.conf test failed > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps "127.0.0.1-127.0.0.1" > > in /etc/nginx/sites/test-geo.conf:6 > > nginx: configuration file /etc/nginx/nginx.conf test failed > > > [..] > > > > В чем может быть дело? > > Спасибо. > > Это баг в проверке конфигурации. > > Чтобы его обойти можете поменять местами так чтобы вначале шел больший > диапазон: > > 127.0.0.1-127.0.0.255 US; > 127.0.0.1-127.0.0.1 RU; Это не баг, это фича. Код не умеет обрабатывать добавления диапазонов, перекрывающих уже существующие диапазоны, и честно об этом сообщает. При использовании range'ей последующими строками можно переопределить часть ранее заданного диапазона адресов. Задать диапазон, который бы включал в себя ранее заданные диапазоны - нельзя. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Sat Jan 4 18:26:38 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 4 Jan 2014 22:26:38 +0400 Subject: ngx_http_geo_module range overlaps In-Reply-To: References: <14955485.co9pbvDmNh@vbart-laptop> <20140104180929.GN95113@mdounin.ru> Message-ID: <20140104182638.GP95113@mdounin.ru> Hello! On Sat, Jan 04, 2014 at 09:17:00PM +0300, Ксения Юрьевна Блащук wrote: > Да, спасибо, все так, но очень смутил пример в документации по модулю. Ну он неправильный, так иногда бывает. :) Правильный, кстати, есть тут: http://nginx.org/ru/docs/http/ngx_http_geo_module.html#geo -- Maxim Dounin http://nginx.org/ From vbart at nginx.com Sat Jan 4 19:03:04 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 04 Jan 2014 23:03:04 +0400 Subject: ngx_http_geo_module range overlaps In-Reply-To: <20140104180929.GN95113@mdounin.ru> References: <14955485.co9pbvDmNh@vbart-laptop> <20140104180929.GN95113@mdounin.ru> Message-ID: <1433116.eSNSJX1VXa@vbart-laptop> On Saturday 04 January 2014 22:09:29 Maxim Dounin wrote: > Hello! > > On Sat, Jan 04, 2014 at 06:12:25PM +0400, Валентин Бартенев wrote: > > On Saturday 04 January 2014 15:01:16 Ксения Юрьевна Блащук wrote: > > > Добрый день. > > > Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести > > > пересекающиеся диапазоны адресов. В документации: > > > > > > A value of the most specific match is used. For example, for the > > > 127.0.0.1 > > > address the value "RU" will be chosen, not "US". > > > > > > Example with ranges: > > > > > > geo $country { > > > > > > ranges; > > > default ZZ; > > > 127.0.0.0-127.0.0.0 US; > > > 127.0.0.1-127.0.0.1 RU; > > > 127.0.0.1-127.0.0.255 US; > > > 10.1.0.0-10.1.255.255 RU; > > > 192.168.1.0-192.168.1.255 UK; > > > > > > } > > > > > > Пытаюсь воспроизвести этот пример: > > > > > > /etc/init.d/nginx reload > > > > > > * Checking nginx' configuration ... > > > > > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps > > > "127.0.0.1-127.0.0.1" > > > in /etc/nginx/sites/test-geo.conf:6 > > > nginx: configuration file /etc/nginx/nginx.conf test failed > > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps > > > "127.0.0.1-127.0.0.1" > > > in /etc/nginx/sites/test-geo.conf:6 > > > nginx: configuration file /etc/nginx/nginx.conf test failed > > > > [..] > > > > > В чем может быть дело? > > > Спасибо. > > > > Это баг в проверке конфигурации. > > > > Чтобы его обойти можете поменять местами так чтобы вначале шел больший > > > > диапазон: > > 127.0.0.1-127.0.0.255 US; > > 127.0.0.1-127.0.0.1 RU; > > Это не баг, это фича. Код не умеет обрабатывать добавления > диапазонов, перекрывающих уже существующие диапазоны, и честно об > этом сообщает. > > При использовании range'ей последующими строками можно > переопределить часть ранее заданного диапазона адресов. Задать > диапазон, который бы включал в себя ранее заданные диапазоны - > нельзя. Фича, как известно, это задокументированная бага, а в данном же случае было не так. =) Можно и научить: diff -r b1db6dda3f83 src/http/modules/ngx_http_geo_module.c --- a/src/http/modules/ngx_http_geo_module.c Sat Jan 04 18:48:25 2014 +0400 +++ b/src/http/modules/ngx_http_geo_module.c Sat Jan 04 22:48:11 2014 +0400 @@ -798,10 +798,22 @@ ngx_http_geo_add_range(ngx_conf_t *cf, n i--; + if (s < (ngx_uint_t) range[i].start + && e == (ngx_uint_t) range[i].end) + { + e = range[i].start - 1; + } + if (e < (ngx_uint_t) range[i].start) { continue; } + if (s == (ngx_uint_t) range[i].start + && e > (ngx_uint_t) range[i].end) + { + s = range[i].end + 1; + } + if (s > (ngx_uint_t) range[i].end) { /* add after the range */ @@ -835,6 +847,30 @@ ngx_http_geo_add_range(ngx_conf_t *cf, n goto next; } + if (s < (ngx_uint_t) range[i].start + && e > (ngx_uint_t) range[i].end) + { + /* split the new range and insert a fragment after */ + + range = ngx_array_push(a); + if (range == NULL) { + return NGX_CONF_ERROR; + } + + range = a->elts; + + ngx_memmove(&range[i + 2], &range[i + 1], + (a->nelts - 2 - i) * sizeof(ngx_http_geo_range_t)); + + range[i + 1].start = range[i].end + 1; + range[i + 1].end = (u_short) e; + range[i + 1].value = ctx->value; + + e = range[i].start - 1; + + continue; + } + if (s > (ngx_uint_t) range[i].start && e < (ngx_uint_t) range[i].end) { Хотя проще видимо задокументировать. -- Валентин Бартенев From igor at sysoev.ru Sat Jan 4 19:25:27 2014 From: igor at sysoev.ru (Igor Sysoev) Date: Sat, 4 Jan 2014 23:25:27 +0400 Subject: ngx_http_geo_module range overlaps In-Reply-To: <1433116.eSNSJX1VXa@vbart-laptop> References: <14955485.co9pbvDmNh@vbart-laptop> <20140104180929.GN95113@mdounin.ru> <1433116.eSNSJX1VXa@vbart-laptop> Message-ID: 04.01.2014, в 23:03, Валентин Бартенев написал(а): > On Saturday 04 January 2014 22:09:29 Maxim Dounin wrote: >> Hello! >> >> On Sat, Jan 04, 2014 at 06:12:25PM +0400, Валентин Бартенев wrote: >>> On Saturday 04 January 2014 15:01:16 Ксения Юрьевна Блащук wrote: >>>> Добрый день. >>>> Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести >>>> пересекающиеся диапазоны адресов. В документации: >>>> >>>> A value of the most specific match is used. For example, for the >>>> 127.0.0.1 >>>> address the value "RU" will be chosen, not "US". >>>> >>>> Example with ranges: >>>> >>>> geo $country { >>>> >>>> ranges; >>>> default ZZ; >>>> 127.0.0.0-127.0.0.0 US; >>>> 127.0.0.1-127.0.0.1 RU; >>>> 127.0.0.1-127.0.0.255 US; >>>> 10.1.0.0-10.1.255.255 RU; >>>> 192.168.1.0-192.168.1.255 UK; >>>> >>>> } >>>> >>>> Пытаюсь воспроизвести этот пример: >>>> >>>> /etc/init.d/nginx reload >>>> >>>> * Checking nginx' configuration ... >>>> >>>> nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps >>>> "127.0.0.1-127.0.0.1" >>>> in /etc/nginx/sites/test-geo.conf:6 >>>> nginx: configuration file /etc/nginx/nginx.conf test failed >>>> nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps >>>> "127.0.0.1-127.0.0.1" >>>> in /etc/nginx/sites/test-geo.conf:6 >>>> nginx: configuration file /etc/nginx/nginx.conf test failed >>> >>> [..] >>> >>>> В чем может быть дело? >>>> Спасибо. >>> >>> Это баг в проверке конфигурации. >>> >>> Чтобы его обойти можете поменять местами так чтобы вначале шел больший >>> >>> диапазон: >>> 127.0.0.1-127.0.0.255 US; >>> 127.0.0.1-127.0.0.1 RU; >> >> Это не баг, это фича. Код не умеет обрабатывать добавления >> диапазонов, перекрывающих уже существующие диапазоны, и честно об >> этом сообщает. >> >> При использовании range'ей последующими строками можно >> переопределить часть ранее заданного диапазона адресов. Задать >> диапазон, который бы включал в себя ранее заданные диапазоны - >> нельзя. > > Фича, как известно, это задокументированная бага, а в данном же случае > было не так. =) > > Можно и научить: Нет, учить не надо. Изначально предполагался контроль данных с возможностью последующего оверрайда некоторых диапазонов. -- Igor Sysoev From nginx-forum at nginx.us Sat Jan 4 19:49:19 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 04 Jan 2014 14:49:19 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <2fc76d227da1353ebeaf31c1e5c48815.NginxMailingListRussian@forum.nginx.org> > блоги на каком движке написаны? Блоги - это один из модулей, нашего самописного фреймворка. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246034#msg-246034 From mdounin at mdounin.ru Sat Jan 4 21:50:55 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 5 Jan 2014 01:50:55 +0400 Subject: ngx_http_geo_module range overlaps In-Reply-To: <1433116.eSNSJX1VXa@vbart-laptop> References: <14955485.co9pbvDmNh@vbart-laptop> <20140104180929.GN95113@mdounin.ru> <1433116.eSNSJX1VXa@vbart-laptop> Message-ID: <20140104215055.GQ95113@mdounin.ru> Hello! On Sat, Jan 04, 2014 at 11:03:04PM +0400, Валентин Бартенев wrote: > On Saturday 04 January 2014 22:09:29 Maxim Dounin wrote: > > Hello! > > > > On Sat, Jan 04, 2014 at 06:12:25PM +0400, Валентин Бартенев wrote: > > > On Saturday 04 January 2014 15:01:16 Ксения Юрьевна Блащук wrote: > > > > Добрый день. > > > > Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести > > > > пересекающиеся диапазоны адресов. В документации: > > > > > > > > A value of the most specific match is used. For example, for the > > > > 127.0.0.1 > > > > address the value "RU" will be chosen, not "US". > > > > > > > > Example with ranges: > > > > > > > > geo $country { > > > > > > > > ranges; > > > > default ZZ; > > > > 127.0.0.0-127.0.0.0 US; > > > > 127.0.0.1-127.0.0.1 RU; > > > > 127.0.0.1-127.0.0.255 US; > > > > 10.1.0.0-10.1.255.255 RU; > > > > 192.168.1.0-192.168.1.255 UK; > > > > > > > > } > > > > > > > > Пытаюсь воспроизвести этот пример: > > > > > > > > /etc/init.d/nginx reload > > > > > > > > * Checking nginx' configuration ... > > > > > > > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps > > > > "127.0.0.1-127.0.0.1" > > > > in /etc/nginx/sites/test-geo.conf:6 > > > > nginx: configuration file /etc/nginx/nginx.conf test failed > > > > nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps > > > > "127.0.0.1-127.0.0.1" > > > > in /etc/nginx/sites/test-geo.conf:6 > > > > nginx: configuration file /etc/nginx/nginx.conf test failed > > > > > > [..] > > > > > > > В чем может быть дело? > > > > Спасибо. > > > > > > Это баг в проверке конфигурации. > > > > > > Чтобы его обойти можете поменять местами так чтобы вначале шел больший > > > > > > диапазон: > > > 127.0.0.1-127.0.0.255 US; > > > 127.0.0.1-127.0.0.1 RU; > > > > Это не баг, это фича. Код не умеет обрабатывать добавления > > диапазонов, перекрывающих уже существующие диапазоны, и честно об > > этом сообщает. > > > > При использовании range'ей последующими строками можно > > переопределить часть ранее заданного диапазона адресов. Задать > > диапазон, который бы включал в себя ранее заданные диапазоны - > > нельзя. > > Фича, как известно, это задокументированная бага, а в данном же случае > было не так. =) В данном случае это не бага, да. :) > Можно и научить: [...] Так - будет неправильно, т.к. в результате ты не знаешь, какой диапазон более специфичен. Пример: 127.0.0.1-127.0.0.2 US; 127.0.0.1-127.0.0.3 RU; 127.0.0.3-127.0.0.4 UA; Для 127.0.0.3 должен быть результат UA (т.к. диапазон 127.0.0.3-127.0.0.4 наиболее специфичен), с твоим же патчем получается RU. Ну и в целом по вопросу Игорь уже высказался. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Sat Jan 4 21:55:08 2014 From: nginx-forum at nginx.us (mishatatinets) Date: Sat, 04 Jan 2014 16:55:08 -0500 Subject: =?UTF-8?B?U1NMINCe0YjQuNCx0LrQsA==?= Message-ID: Я пытаюсь установить сертификат, но мне при тестировании выкидывает следующую ошибку. nginx: [emerg] BIO_new_file("/etc/nginx/certificates/domain.crt") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/certificates/domain.crt','r') error:2006D080:BIO routines:BIO_new_file:no such file) nginx: configuration file /etc/nginx/nginx.conf test failed Что может быть с этим и как это поправить? Надеюсь кто нибудь знает что с этим делать, а то я нигде немогу найти ответа. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246036,246036#msg-246036 From sytar.alex at gmail.com Sat Jan 4 21:58:43 2014 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Sun, 5 Jan 2014 01:58:43 +0400 Subject: =?UTF-8?B?UmU6IFNTTCDQntGI0LjQsdC60LA=?= In-Reply-To: References: Message-ID: 5 января 2014 г., 1:55 пользователь mishatatinets написал: > Я пытаюсь установить сертификат, но мне при тестировании выкидывает > следующую ошибку. > > nginx: [emerg] BIO_new_file("/etc/nginx/certificates/domain.crt") failed > (SSL: error:02001002:system library:fopen:No such file or > directory:fopen('/etc/nginx/certificates/domain.crt','r') > error:2006D080:BIO > routines:BIO_new_file:no such file) > > ^^^^^^^^^^^^^ Очевидно же: либо нет файла по указанному пути, либо nginx не имеет прав его читать. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Jan 6 08:35:26 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 06 Jan 2014 03:35:26 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52C84C98.7030802@kopeyko.ru> References: <52C84C98.7030802@kopeyko.ru> Message-ID: <39c9d8b9e2dc8af745e6ac690ba4f95c.NginxMailingListRussian@forum.nginx.org> > > fastcgi_cache_key "$host$uri$is_args$args"; > > Это ни разу ни баг - это вы недонастроили. > > Добавьте в ключ кеширования параметр > $http_if_modified_since > и наступит вам счастье. Я наверно не доступно объяснию суть проблемы. Попробую объяснить на пальцах :) Есть uri /user/bar Отдает контент с заголовками Cache-Control: private, max-age=0 Это клиенское кеширования, с постояной ревалидацией на бекенде. Даные заголовки запрещают Nginx кешировать страницу, никаких файл кеша в Nginx не создаётся её кеширует только браузер, нам это и нужно на данном uri. По этому в нашем конфиге прописана передача от клиента к бекенду заголовков кеширования, чтобы бекенд мог ревалидировать кеш клиента. Вот эти строки fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; Это работает отлично, но дело в том что эти строчки конфига ломают Nginx кеширования, из-за них появляется баг с кешированием 304 статуса. Отключить Nginx кеширования тоже не можем потому что на других uri мы используем Nginx кеширования, например uri /news/list Отдает контент с заголовками Cache-Control: public, max-age=1 Эта страница должна попадать в кеш Nginx. Имино с этой страницей и будут проблемы, если в папке кеша Nginx удалится файл кеша, и прийдет запрос от браузера с актуальным заголовками If-Modified-Since и If-None-Match, на этот запрос бекенд ответит 304 статусом и вернет заговок Cache-Control: public, max-age=1, в результате чего 304 ответ попадет в кеш Nginx. Добавлять в ключ кеша заголовки If-Modified-Since и If-None-Match бесмыслено, потому что это не решит проблему просто создаст разные файлы кеша с той же проблемой, если кто-то не верит пусть проверит. Что имеем в итоге, директивы fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; ломают кеширования Nginx но дают возможность работы с клиент кешированием, если убрать эти дерективы тогда нормально работает Nginx кеширования, но пропадает возможность работы с клиент кешированиям. Нам надо что бы клиент и Nginx кеширования и клиент работали в рамках одного server{}, это возможно сделать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246054#msg-246054 From gmm at csdoc.com Mon Jan 6 10:04:08 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 06 Jan 2014 12:04:08 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <39c9d8b9e2dc8af745e6ac690ba4f95c.NginxMailingListRussian@forum.nginx.org> References: <52C84C98.7030802@kopeyko.ru> <39c9d8b9e2dc8af745e6ac690ba4f95c.NginxMailingListRussian@forum.nginx.org> Message-ID: <52CA7F98.8060503@csdoc.com> On 06.01.2014 10:35, S.A.N wrote: > Есть uri > /user/bar > Отдает контент с заголовками > Cache-Control: private, max-age=0 > Это клиенское кеширования, с постояной ревалидацией на бекенде. > Даные заголовки запрещают Nginx кешировать страницу, никаких файл кеша в > Nginx не создаётся её кеширует только браузер, нам это и нужно на данном > uri. > По этому в нашем конфиге прописана передача от клиента к бекенду заголовков > кеширования, чтобы бекенд мог ревалидировать кеш клиента. > Вот эти строки > fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; > fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; > Это работает отлично, но дело в том что эти строчки конфига ломают Nginx > кеширования, из-за них появляется баг с кешированием 304 статуса. > > Отключить Nginx кеширования тоже не можем потому что на других uri мы > используем Nginx кеширования, например uri > /news/list > Отдает контент с заголовками > Cache-Control: public, max-age=1 > Эта страница должна попадать в кеш Nginx. там где нужен кеш - его можно включить. там где кеш не нужен - его можно выключить. в том числе и в контексте отдельных location`ов. http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache syntax: fastcgi_cache zone | off; default: fastcgi_cache off; context: http, server, location Defines a shared memory zone used for caching. The same zone can be used in several places. The off parameter disables caching inherited from the previous configuration level. > Нам надо что бы клиент и Nginx кеширования и клиент работали в рамках одного > server{}, это возможно сделать? да. передавать на backend заголовки If-Modified-Since и If-None-Match или нет - это тоже можно настроить по разному для разных location`ов. -- Best regards, Gena From nginx-forum at nginx.us Mon Jan 6 10:41:43 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 06 Jan 2014 05:41:43 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CA7F98.8060503@csdoc.com> References: <52CA7F98.8060503@csdoc.com> Message-ID: > передавать на backend заголовки If-Modified-Since и If-None-Match > или нет - это тоже можно настроить по разному для разных location`ов. Да, согласен, но этот вариант очень не хочется реализовывать, довольно большой перечень location придется указывать в конфиге Nginx, это уже жесткий хардкор, со временем он станет тяжелый в сапорте. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246059#msg-246059 From gmm at csdoc.com Mon Jan 6 14:53:33 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 06 Jan 2014 16:53:33 +0200 Subject: =?UTF-8?Q?auth=5Frequest_=D0=B8_named_location?= Message-ID: <52CAC36D.2020401@csdoc.com> в документации есть пример использования auth_request. сейчас приходится писать location = /auth { internal; fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi_pass_request_body off; } а можно было бы проще: location @auth { fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi_pass_request_body off; } но вариант auth_request через named location почему-то не работает. в варианте с location @auth основной плюс в том, что uri /auth можно использовать для целей сайта. да и в конфиге тогда писать на одну строчку меньше. или auth_request через named location в nginx реализовать невозможно? -- Best regards, Gena From chipitsine at gmail.com Mon Jan 6 18:32:09 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 7 Jan 2014 00:32:09 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CA7F98.8060503@csdoc.com> References: <52C84C98.7030802@kopeyko.ru> <39c9d8b9e2dc8af745e6ac690ba4f95c.NginxMailingListRussian@forum.nginx.org> <52CA7F98.8060503@csdoc.com> Message-ID: 6 января 2014 г., 16:04 пользователь Gena Makhomed написал: > On 06.01.2014 10:35, S.A.N wrote: > >> Есть uri >> /user/bar >> Отдает контент с заголовками >> Cache-Control: private, max-age=0 если было бы "Cache-Control: private", вроде как было бы то же самое, нет ? на 10 символов короче. >> Это клиенское кеширования, с постояной ревалидацией на бекенде. >> Даные заголовки запрещают Nginx кешировать страницу, никаких файл кеша в >> Nginx не создаётся её кеширует только браузер, нам это и нужно на данном >> uri. >> По этому в нашем конфиге прописана передача от клиента к бекенду >> заголовков >> кеширования, чтобы бекенд мог ревалидировать кеш клиента. >> Вот эти строки >> fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; >> fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; >> Это работает отлично, но дело в том что эти строчки конфига ломают Nginx >> кеширования, из-за них появляется баг с кешированием 304 статуса. >> >> Отключить Nginx кеширования тоже не можем потому что на других uri мы >> используем Nginx кеширования, например uri >> /news/list >> Отдает контент с заголовками >> Cache-Control: public, max-age=1 >> Эта страница должна попадать в кеш Nginx. > > > там где нужен кеш - его можно включить. > там где кеш не нужен - его можно выключить. > в том числе и в контексте отдельных location`ов. > > http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache > > syntax: fastcgi_cache zone | off; > default: fastcgi_cache off; > context: http, server, location > > Defines a shared memory zone used for caching. The same zone can be used in > several places. The off parameter disables caching inherited from the > previous configuration level. > > >> Нам надо что бы клиент и Nginx кеширования и клиент работали в рамках >> одного >> server{}, это возможно сделать? > > > да. > > передавать на backend заголовки If-Modified-Since и If-None-Match > или нет - это тоже можно настроить по разному для разных location`ов. перечитал RFC, к числу hop-by-hop хедеров они не относятся, получается, их надо всегда передавать на бекенд? ну и такой вопрос, раз движок php, используете ли вы средства типа APC и xdebug ? а миллисекунды у вас неплохие. > > -- > 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 Mon Jan 6 21:05:16 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 06 Jan 2014 16:05:16 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: > перечитал RFC, к числу hop-by-hop хедеров они не относятся, > получается, их надо всегда передавать на бекенд? Да, эти заголовков при прозрачном проксировании передаются без изменений, к сожалению Nginx самостоятельно удаляет эти заговолки при включенном Nginx кешировании, я понимаю почему он это делает, таким образом он форсирует наполнения своего кеша и защищает себя от проблемы с кешированием 304 статуса, но при этом исключает работу бекенда с клиентским кешем. > ну и такой вопрос, раз движок php, используете ли вы средства типа > APC > и xdebug ? > а миллисекунды у вас неплохие. Мы используем РНР 5.5 с включеным OPcache, данная версия РНР работает шустро потребляет меньше памяти, потребности в АРС нет, разве что в АРС есть возможность кешить переменые значения но это не актуально если используется больше одного сервер приложения, для кеширования переменых значений мы используем Memcache, между Nginx и PHP-FPM, keep-alive конект это тоже экономит время. Основная причина высокой скорости ревалидации, это то что для её выполнения достаточно 200 строк кода РНР, в этих строках нет медленных операций, самое медленное что там есть это запрос к Memcache он так же на персистен конект, в общем при разогретом кеше могут быть даже чуть лучше результаты чем я написал, по этому для нас вопросы кеширования так важны. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246073#msg-246073 From mdounin at mdounin.ru Tue Jan 7 01:47:18 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 7 Jan 2014 05:47:18 +0400 Subject: =?UTF-8?Q?Re=3A_auth=5Frequest_=D0=B8_named_location?= In-Reply-To: <52CAC36D.2020401@csdoc.com> References: <52CAC36D.2020401@csdoc.com> Message-ID: <20140107014718.GS95113@mdounin.ru> Hello! On Mon, Jan 06, 2014 at 04:53:33PM +0200, Gena Makhomed wrote: > > в документации есть пример использования auth_request. > > сейчас приходится писать > > location = /auth { > internal; > fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; > include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH > fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; > fastcgi_pass_request_body off; > } > > а можно было бы проще: > > location @auth { > fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; > include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH > fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; > fastcgi_pass_request_body off; > } > > но вариант auth_request через named location почему-то не работает. > > в варианте с location @auth основной плюс в том, > что uri /auth можно использовать для целей сайта. > да и в конфиге тогда писать на одну строчку меньше. > > или auth_request через named location в nginx реализовать невозможно? Именованные location'ы имеют сильно ограниченную область применимости - они предназначены для того, чтобы перенаправлять в них запросы без изменения URI. Создавать подзапросы в именованный location - нельзя. -- Maxim Dounin http://nginx.org/ From vbart at nginx.com Tue Jan 7 01:57:01 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 07 Jan 2014 05:57:01 +0400 Subject: =?UTF-8?Q?Re=3A_auth=5Frequest_=D0=B8_named_location?= In-Reply-To: <20140107014718.GS95113@mdounin.ru> References: <52CAC36D.2020401@csdoc.com> <20140107014718.GS95113@mdounin.ru> Message-ID: <1393385.XP43Fo7Woa@vbart-laptop> On Tuesday 07 January 2014 05:47:18 Maxim Dounin wrote: > Hello! > > On Mon, Jan 06, 2014 at 04:53:33PM +0200, Gena Makhomed wrote: > > в документации есть пример использования auth_request. > > > > сейчас приходится писать > > > > location = /auth { > > > > internal; > > fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; > > include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH > > fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; > > fastcgi_pass_request_body off; > > > > } > > > > а можно было бы проще: > > > > location @auth { > > > > fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; > > include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH > > fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; > > fastcgi_pass_request_body off; > > > > } > > > > но вариант auth_request через named location почему-то не работает. > > > > в варианте с location @auth основной плюс в том, > > что uri /auth можно использовать для целей сайта. > > да и в конфиге тогда писать на одну строчку меньше. > > > > или auth_request через named location в nginx реализовать невозможно? > > Именованные location'ы имеют сильно ограниченную область > применимости - они предназначены для того, чтобы перенаправлять в > них запросы без изменения URI. Создавать подзапросы в именованный > location - нельзя. Подозреваю, что было бы удобно и логично, если URI при подзапросе в именованный location брался из родительского запроса. -- Валентин Бартенев From mdounin at mdounin.ru Tue Jan 7 02:14:28 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 7 Jan 2014 06:14:28 +0400 Subject: =?UTF-8?Q?Re=3A_auth=5Frequest_=D0=B8_named_location?= In-Reply-To: <1393385.XP43Fo7Woa@vbart-laptop> References: <52CAC36D.2020401@csdoc.com> <20140107014718.GS95113@mdounin.ru> <1393385.XP43Fo7Woa@vbart-laptop> Message-ID: <20140107021428.GU95113@mdounin.ru> Hello! On Tue, Jan 07, 2014 at 05:57:01AM +0400, Валентин Бартенев wrote: > On Tuesday 07 January 2014 05:47:18 Maxim Dounin wrote: > > Hello! > > > > On Mon, Jan 06, 2014 at 04:53:33PM +0200, Gena Makhomed wrote: > > > в документации есть пример использования auth_request. > > > > > > сейчас приходится писать > > > > > > location = /auth { > > > > > > internal; > > > fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; > > > include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH > > > fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; > > > fastcgi_pass_request_body off; > > > > > > } > > > > > > а можно было бы проще: > > > > > > location @auth { > > > > > > fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/auth.php; > > > include /etc/nginx/fastcgi_params.auth; # без CONTENT_LENGTH > > > fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; > > > fastcgi_pass_request_body off; > > > > > > } > > > > > > но вариант auth_request через named location почему-то не работает. > > > > > > в варианте с location @auth основной плюс в том, > > > что uri /auth можно использовать для целей сайта. > > > да и в конфиге тогда писать на одну строчку меньше. > > > > > > или auth_request через named location в nginx реализовать невозможно? > > > > Именованные location'ы имеют сильно ограниченную область > > применимости - они предназначены для того, чтобы перенаправлять в > > них запросы без изменения URI. Создавать подзапросы в именованный > > location - нельзя. > > Подозреваю, что было бы удобно и логично, если URI при подзапросе в > именованный location брался из родительского запроса. Если делать - то наверное делать так, да. Но сейчас этого нет, и я совершенно не уверен, что это нужно делать - скорее, я придерживаюсь противоположного мнения. -- Maxim Dounin http://nginx.org/ From gmm at csdoc.com Tue Jan 7 10:34:50 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 12:34:50 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <52CA7F98.8060503@csdoc.com> Message-ID: <52CBD84A.1070405@csdoc.com> On 06.01.2014 12:41, S.A.N wrote: >> передавать на backend заголовки If-Modified-Since и If-None-Match >> или нет - это тоже можно настроить по разному для разных location`ов. > Да, согласен, но этот вариант очень не хочется реализовывать, довольно > большой перечень location придется указывать в конфиге Nginx, это уже > жесткий хардкор, со временем он станет тяжелый в сапорте. не обязательно конфиг nginx писать вручную. его можно создавать с помощью генератора конфига, который будет учитывать структуру сайта, для каких location`ов какой тип кеширования надо включать. кроме того, если надо сделать так, чтобы nginx не кешировал 304 ответы от backend`а - это ведь можно легко сделать, с помощью X-Accel-Expires: The ?X-Accel-Expires? header field sets caching time of a response in seconds. The zero value disables caching for a response. X-Accel-Expires - управление кешем nginx Cache-Control - управление кешем браузера fastcgi_cache_valid - значение по умолчанию, если в ответе backend`а нет ни X-Accel-Expires, ни Cache-Control. On 04.01.2014 3:07, S.A.N wrote: > Бекенд, не знает и не должен знать, какой тип кеша > ему нужно ревалидировать, клиентский или кеш Nginx, > по хорошему в первом и во втором случаи, механизм > должен быть полностью одинаковым. каким же образом тогда nginx может узнать, какие ответы от backend`а ему следует сохранять в своем кеше, а какие нет? On 04.01.2014 6:25, S.A.N wrote: > Вопрос остаётся открытым, как сделать клиенское (private) > кеширования в браузере, но при этом не давать кешить 304 статус? > > Как вариант, можно при 304 ответе отправлять хедер > X-Accel-Expires: 0, чтобы ответ не попал в кеш. > > Есть более красивые решения этой проблемы? "X-Accel-Expires: 0" - это отличное решение. "более красивых" решений тут даже теоретически существовать не может. On 06.01.2014 10:35, S.A.N wrote: > Отключить Nginx кеширования тоже не можем потому что на других uri мы > используем Nginx кеширования, например uri > /news/list > Отдает контент с заголовками > Cache-Control: public, max-age=1 > Эта страница должна попадать в кеш Nginx. > Имино с этой страницей и будут проблемы, > если в папке кеша Nginx удалится файл кеша, > и прийдет запрос от браузера с актуальным заголовками > If-Modified-Since и If-None-Match, на этот запрос бекенд ответит 304 > статусом и вернет заговок Cache-Control: public, max-age=1, > в результате чего 304 ответ попадет в кеш Nginx. 304 ответ попадет в кеш nginx потому что Вы сами же включили кеш nginx и сами же разрешили nginx кешировать этот ответ, вернув заголовок Cache-Control: public, max-age=1 который управляет одновеменно и клиентским кешем и кешем nginx. Добавьте к 304 ответам backend`а еще один заголовок X-Accel-Expires: 0 который будет запрещать nginx кешировать такие ответы и будет вам счастье. Ваш backend обязан знать о том, что есть два различных кеша, если Вы хотите управлять ими по-разному. Иначе не получится. ========================================================================= On 29.12.2013 8:04, S.A.N wrote: > И советую не читать статьи, типа - Подводные камни при использовании > кэширования в nginx http://habrahabr.ru/post/72539/ > К сожалению, в статье больше глупостей чем разумных вещей, если будите > читать документацию и пользоваться логикой, > подводных камней в кэшировании не будет и конфиг станет короче > и управляемость кешем станет прозрачной а главное > само кэширования станет эффективней. Во-первых, кроме статьи Дмитрия Котерова на тему кеширования в nginx в интеретах читать-то по сути больше и нечего. Во-вторых, не ошибается только тот, кто ничего не делает, а критика должна быть конструктивной, с указанием явных ошибок, если они есть, что и как можно улучшить в статье, как ее дополнить. Идеальный вариант - написать с нуля свой собственный вариант статьи на хабре, или в собственном блоге или на http://wiki.nginx.org/, которая будет лучше, чем статья Дмитрия Котерова. С учетом своего богатого жизненного опыта и т.п. Критиковать ведь всегда легче, чем что-то делать. В-третьих, не смотря на то, что не все рекомендации из этой статьи подходят всем, там есть и достаточно ценные советы и рекомендации, на которые следовало бы обратить внимание. Например: : Особого внимания заслуживает значение в директиве fastcgi_cache_key. : Я привел минимальное рабочее значение этой директивы. Шаг вправо, : шаг влево, и вы начнете в ряде случаев получать ?неправильные? данные : из кэша. Итак: : Зависимость от $request_method нам нужна, т.к. HEAD-запросы : в Интернете довольно часты. Ответ на HEAD-запрос никогда : не содержит тела. Если убрать зависимость от $request_method, : то может так совпасть, что кто-то до вас запросил главную страницу : HEAD-методом, а вам потом по GET отдастся пустой контент. так что Ваш вариант fastcgi_cache_methods GET HEAD; fastcgi_cache_key "$host$uri$is_args$args"; не оптимален, включает $uri$is_args$args вместо $request_uri и даже ошибочен, потому что не включает в себя $request_method. P.S. да, эта статья и рекомендации неоднозначные, http://habrahabr.ru/post/72539/#comment_2082092 но ведь думать своей головой никто не запрещал. -- Best regards, Gena From chipitsine at gmail.com Tue Jan 7 10:59:40 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 7 Jan 2014 16:59:40 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CBD84A.1070405@csdoc.com> References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> Message-ID: 7 января 2014 г., 16:34 пользователь Gena Makhomed написал: > On 06.01.2014 12:41, S.A.N wrote: > >>> передавать на backend заголовки If-Modified-Since и If-None-Match >>> или нет - это тоже можно настроить по разному для разных location`ов. > > >> Да, согласен, но этот вариант очень не хочется реализовывать, довольно >> большой перечень location придется указывать в конфиге Nginx, это уже >> жесткий хардкор, со временем он станет тяжелый в сапорте. > > > не обязательно конфиг nginx писать вручную. его можно создавать > с помощью генератора конфига, который будет учитывать структуру > сайта, для каких location`ов какой тип кеширования надо включать. > > кроме того, если надо сделать так, чтобы nginx не кешировал 304 ответы > от backend`а - это ведь можно легко сделать, с помощью X-Accel-Expires: > > The "X-Accel-Expires" header field sets caching time of a response > in seconds. The zero value disables caching for a response. > > X-Accel-Expires - управление кешем nginx > Cache-Control - управление кешем браузера > > fastcgi_cache_valid - значение по умолчанию, > если в ответе backend`а нет ни X-Accel-Expires, ни Cache-Control. > > > On 04.01.2014 3:07, S.A.N wrote: > >> Бекенд, не знает и не должен знать, какой тип кеша >> ему нужно ревалидировать, клиентский или кеш Nginx, >> по хорошему в первом и во втором случаи, механизм >> должен быть полностью одинаковым. > > каким же образом тогда nginx может узнать, какие ответы от > backend`а ему следует сохранять в своем кеше, а какие нет? каким образом - в треде это явно предлагалось, путем 1) кеширования контента, у которого выставлен max-age=0 (или остутствует) 2) прокидывания клиентских if-none-match/if-not-modified-since до бекенда по личному опыту, 304-е ответы, субсекундные кеши и инвалидация кеша на прокси - это какая-то темная сторона, на которой может происходить все, что угодно. > > > On 04.01.2014 6:25, S.A.N wrote: > >> Вопрос остаётся открытым, как сделать клиенское (private) >> кеширования в браузере, но при этом не давать кешить 304 статус? >> >> Как вариант, можно при 304 ответе отправлять хедер >> X-Accel-Expires: 0, чтобы ответ не попал в кеш. >> >> Есть более красивые решения этой проблемы? > > "X-Accel-Expires: 0" - это отличное решение. > > "более красивых" решений тут даже теоретически существовать не может. > > > On 06.01.2014 10:35, S.A.N wrote: > >> Отключить Nginx кеширования тоже не можем потому что на других uri мы >> используем Nginx кеширования, например uri >> /news/list >> Отдает контент с заголовками >> Cache-Control: public, max-age=1 >> Эта страница должна попадать в кеш Nginx. >> Имино с этой страницей и будут проблемы, >> если в папке кеша Nginx удалится файл кеша, >> и прийдет запрос от браузера с актуальным заголовками >> If-Modified-Since и If-None-Match, на этот запрос бекенд ответит 304 >> статусом и вернет заговок Cache-Control: public, max-age=1, >> в результате чего 304 ответ попадет в кеш Nginx. > > 304 ответ попадет в кеш nginx потому что Вы сами же включили > кеш nginx и сами же разрешили nginx кешировать этот ответ, > вернув заголовок Cache-Control: public, max-age=1 > который управляет одновеменно и клиентским кешем и кешем nginx. > > Добавьте к 304 ответам backend`а еще один заголовок X-Accel-Expires: 0 > который будет запрещать nginx кешировать такие ответы и будет вам счастье. > > Ваш backend обязан знать о том, что есть два различных кеша, > если Вы хотите управлять ими по-разному. Иначе не получится. > > ========================================================================= > > On 29.12.2013 8:04, S.A.N wrote: > >> И советую не читать статьи, типа - Подводные камни при использовании >> кэширования в nginx http://habrahabr.ru/post/72539/ >> К сожалению, в статье больше глупостей чем разумных вещей, если будите >> читать документацию и пользоваться логикой, >> подводных камней в кэшировании не будет и конфиг станет короче >> и управляемость кешем станет прозрачной а главное >> само кэширования станет эффективней. > > Во-первых, кроме статьи Дмитрия Котерова на тему кеширования в nginx > в интеретах читать-то по сути больше и нечего. > > Во-вторых, не ошибается только тот, кто ничего не делает, > а критика должна быть конструктивной, с указанием явных ошибок, > если они есть, что и как можно улучшить в статье, как ее дополнить. > > Идеальный вариант - написать с нуля свой собственный вариант статьи > на хабре, или в собственном блоге или на http://wiki.nginx.org/, которая > будет лучше, чем статья Дмитрия Котерова. > С учетом своего богатого жизненного опыта и т.п. > Критиковать ведь всегда легче, чем что-то делать. > > В-третьих, не смотря на то, что не все рекомендации из этой статьи > подходят всем, там есть и достаточно ценные советы и рекомендации, > на которые следовало бы обратить внимание. Например: > > : Особого внимания заслуживает значение в директиве fastcgi_cache_key. > : Я привел минимальное рабочее значение этой директивы. Шаг вправо, > : шаг влево, и вы начнете в ряде случаев получать <<неправильные>> данные > : из кэша. Итак: > : Зависимость от $request_method нам нужна, т.к. HEAD-запросы > : в Интернете довольно часты. Ответ на HEAD-запрос никогда > : не содержит тела. Если убрать зависимость от $request_method, > : то может так совпасть, что кто-то до вас запросил главную страницу > : HEAD-методом, а вам потом по GET отдастся пустой контент. > > так что Ваш вариант > > fastcgi_cache_methods GET HEAD; > fastcgi_cache_key "$host$uri$is_args$args"; > > не оптимален, включает $uri$is_args$args вместо $request_uri > и даже ошибочен, потому что не включает в себя $request_method. > > P.S. да, эта статья и рекомендации неоднозначные, > http://habrahabr.ru/post/72539/#comment_2082092 > но ведь думать своей головой никто не запрещал. > > -- > Best regards, > Gena > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From gmm at csdoc.com Tue Jan 7 11:13:53 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 13:13:53 +0200 Subject: =?UTF-8?Q?proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= Message-ID: <52CBE171.9070000@csdoc.com> почитал доку по директивам proxy_cache_key и fastcgi_cache_key, появилось много вопросов. для директив proxy_cache_methods и fastcgi_cache_methods значение по-умолчанию GET HEAD; - то есть будут кешироваться как ответы на GET, так и ответы на HEAD запросы от клиентов. вместе с тем, в документации во всех примерах использования директив proxy_cache_key и fastcgi_cache_key нигде не указано зависимости от $request_method, следовательно будет этот глюк: http://habrahabr.ru/post/72539/ : Особого внимания заслуживает значение в директиве fastcgi_cache_key. : Я привел минимальное рабочее значение этой директивы. Шаг вправо, : шаг влево, и вы начнете в ряде случаев получать ?неправильные? данные : из кэша. Итак: : Зависимость от $request_method нам нужна, т.к. HEAD-запросы : в Интернете довольно часты. Ответ на HEAD-запрос никогда : не содержит тела. Если убрать зависимость от $request_method, : то может так совпасть, что кто-то до вас запросил главную страницу : HEAD-методом, а вам потом по GET отдастся пустой контент. может быть имеет смысл поправить все примеры в документации, чтобы proxy_cache_key и fastcgi_cache_key включали в себя зависимость от $request_method ? второй вопрос - по поводу дефолтовых значений proxy_cache_key и fastcgi_cache_key, они почему-то разные. syntax: fastcgi_cache_key string; default: ? syntax: proxy_cache_key string; default: proxy_cache_key $scheme$proxy_host$request_uri; может быть имеет смысл их сделать одинаковыми, и тоже включить в них зависимость от $request_method ? только наверное вместо $proxy_host лучше использовать переменную $host. потому что запросы с разными заголовками Host: могут проксироваться на один и тот же backend с одинаковым значением $proxy_host и тогда, при *дефолтовом* значении proxy_cache_key - nginx будет отдавать клиентам ошибочные страницы из своего кеша, от совсем другого сайта. -- Best regards, Gena From nginx-forum at nginx.us Tue Jan 7 11:16:53 2014 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 07 Jan 2014 06:16:53 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CBD84A.1070405@csdoc.com> References: <52CBD84A.1070405@csdoc.com> Message-ID: <5fd7ca56a9c00430e5fd4700094897f2.NginxMailingListRussian@forum.nginx.org> > так что Ваш вариант > > fastcgi_cache_methods GET HEAD; > fastcgi_cache_key "$host$uri$is_args$args"; > > не оптимален, включает $uri$is_args$args вместо $request_uri > и даже ошибочен, потому что не включает в себя $request_method. HEAD кэширует ответ с телом, отдаёт - без. Не хотел обидеть автора статьи, я думаю он ещё в 2010 году понял что написал что-то не то, после критики статьи Игорем Сысуевым http://mailman.nginx.org/pipermail/nginx-ru/2010-June/034696.html Насчет написать мне свою статью, Вы правы на русском языке очень мало достойного материала про Nginx. Я не считаю себя хорошим писателем, но когда Nginx реализует ревалидацию по ETag, после её внедрения я бы мог написать статью посвященную вопросам ревалидации кеша в Nginx. Но это далекое будущее, сейчас меня больше интересует почему тот же Squid прокси не удаляет клиенские заголовки кеширования и сам не кешит ответ в 304 статусе и это все без спец конфига под каждый сайт :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246087#msg-246087 From nginx-forum at nginx.us Tue Jan 7 12:10:24 2014 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 07 Jan 2014 07:10:24 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <1ee2a7e49afba63eff631460e1a37fd4.NginxMailingListRussian@forum.nginx.org> > >> Отдает контент с заголовками > >> Cache-Control: private, max-age=0 > > если было бы "Cache-Control: private", вроде как было бы то же самое, > нет ? на 10 символов короче. Можно не указывать max-age=0, по спецификации если не указан max-age он равен нулю, но есть такие клиенты как Opera, у неё значения max-age по умолчанию не равно нулю, в общем я бы не рисковал и все таки указывал явно max-age=0. Если хочется сократить заголовки можно не указывать дерективу public, по умолчанию кеш всегда считается public если не указано обратное, на продакшене можно не писать public там где кеш публичный. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246090#msg-246090 From gmm at csdoc.com Tue Jan 7 13:05:11 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 15:05:11 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <5fd7ca56a9c00430e5fd4700094897f2.NginxMailingListRussian@forum.nginx.org> References: <52CBD84A.1070405@csdoc.com> <5fd7ca56a9c00430e5fd4700094897f2.NginxMailingListRussian@forum.nginx.org> Message-ID: <52CBFB87.8070502@csdoc.com> On 07.01.2014 13:16, S.A.N wrote: >> так что Ваш вариант >> >> fastcgi_cache_methods GET HEAD; >> fastcgi_cache_key "$host$uri$is_args$args"; >> >> не оптимален, включает $uri$is_args$args вместо $request_uri >> и даже ошибочен, потому что не включает в себя $request_method. > > HEAD кэширует ответ с телом, отдаёт - без. только что проверил, да, действительно. на клиенте делаю запрос HEAD, nginx "на лету" преобразовывает его в запрос GET и отправляет на backend запрос GET, ответ на который потом и попадает в кеш nginx, а клиенту nginx отправляет ответ на запрос HEAD, без тела. если выключить кеширование на стороне nginx, тогда эта "магия" пропадает и на backend уходит запрос HEAD без преобразования. а вот для протокола WebDAV до сих пор приходится вручную workaround`ы делать: set $fixed_destination $http_destination; if ( $http_destination ~* ^https(.*)$ ) { set $fixed_destination http$1; } proxy_set_header Destination $fixed_destination; > Не хотел обидеть автора статьи, я думаю он ещё в 2010 году понял что написал > что-то не то, после критики статьи Игорем Сысуевым > http://mailman.nginx.org/pipermail/nginx-ru/2010-June/034696.html *) Bugfix: the "If-Modified-Since", "If-Range", etc. client request header lines were passed to FastCGI-server while caching. появился в nginx 0.8.40 аж 07 Jun 2010, а статья написана в 2009 году. наверное поэтому "где она оправдано применяется в FastCGI", то есть других вариантов бороться с отдачей 304 пустых страниц при связи с бекендом по протоколу FastCGI тогда просто не было. Да, та статья 2009 года сейчас уже достаточно сильно морально устарела и требует основательного обновления. Но других статей, о том как настроить кеширование в nginx - просто нет. > Насчет написать мне свою статью, Вы правы на русском языке очень мало > достойного материала про Nginx. > Я не считаю себя хорошим писателем, но когда Nginx реализует ревалидацию по > ETag, после её внедрения я бы мог написать статью посвященную вопросам > ревалидации кеша в Nginx. Торг здесь не уместен. Можно написать статью и без ревалидации по ETag. Как реализовать ревалидацию по ETag, если его просто не будет у части клиентов. В кеше ведь всегда находится только один вариант контента - или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем случае встречаются оба этих варианта. Делать ревалидацию по If-None-Match потом будет только та половина клиентов, которой больше повезло. > Но это далекое будущее, сейчас меня больше интересует почему тот же Squid > прокси не удаляет клиенские заголовки кеширования и сам не кешит ответ в 304 > статусе и это все без спец конфига под каждый сайт :) squid - это forward proxy, а nginx - web server. что ж тут не ясного... -- Best regards, Gena From gmm at csdoc.com Tue Jan 7 13:22:24 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 15:22:24 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> Message-ID: <52CBFF90.8030001@csdoc.com> On 07.01.2014 12:59, Илья Шипицин wrote: >> On 04.01.2014 3:07, S.A.N wrote: >>> Бекенд, не знает и не должен знать, какой тип кеша >>> ему нужно ревалидировать, клиентский или кеш Nginx, >>> по хорошему в первом и во втором случаи, механизм >>> должен быть полностью одинаковым. >> каким же образом тогда nginx может узнать, какие ответы от >> backend`а ему следует сохранять в своем кеше, а какие нет? > каким образом - в треде это явно предлагалось, путем > 1) кеширования контента, у которого выставлен max-age=0 (или остутствует) каким образом это поможет бороться с кешированием пустых 304 ответов, которые приходят с backend`а с "Cache-Control: public, max-age=1" ? > 2) прокидывания клиентских if-none-match/if-not-modified-since до бекенда только это как раз будет способ создать проблему, а не решить ее. backend ответит 304 статусом и пустая страница попадет в кеш nginx. >> On 06.01.2014 10:35, S.A.N wrote: >>> Отключить Nginx кеширования тоже не можем потому что на других uri мы >>> используем Nginx кеширования, например uri >>> /news/list >>> Отдает контент с заголовками >>> Cache-Control: public, max-age=1 >>> Эта страница должна попадать в кеш Nginx. >>> Имино с этой страницей и будут проблемы, >>> если в папке кеша Nginx удалится файл кеша, >>> и прийдет запрос от браузера с актуальным заголовками >>> If-Modified-Since и If-None-Match, на этот запрос бекенд ответит 304 >>> статусом и вернет заговок Cache-Control: public, max-age=1, >>> в результате чего 304 ответ попадет в кеш Nginx. >> 304 ответ попадет в кеш nginx потому что Вы сами же включили >> кеш nginx и сами же разрешили nginx кешировать этот ответ, >> вернув заголовок Cache-Control: public, max-age=1 >> который управляет одновеменно и клиентским кешем и кешем nginx. >> >> Добавьте к 304 ответам backend`а еще один заголовок X-Accel-Expires: 0 >> который будет запрещать nginx кешировать такие ответы и будет вам счастье. >> >> Ваш backend обязан знать о том, что есть два различных кеша, >> если Вы хотите управлять ими по-разному. Иначе не получится. -- Best regards, Gena From chipitsine at gmail.com Tue Jan 7 13:30:11 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 7 Jan 2014 19:30:11 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <1ee2a7e49afba63eff631460e1a37fd4.NginxMailingListRussian@forum.nginx.org> References: <1ee2a7e49afba63eff631460e1a37fd4.NginxMailingListRussian@forum.nginx.org> Message-ID: вторник, 7 января 2014 г. пользователь S.A.N писал: > > >> Отдает контент с заголовками > > >> Cache-Control: private, max-age=0 > > > > если было бы "Cache-Control: private", вроде как было бы то же самое, > > нет ? на 10 символов короче. > > Можно не указывать max-age=0, по спецификации если не указан max-age он > равен нулю, но есть такие клиенты как Opera, у неё значения max-age по > умолчанию не равно нулю, в общем я бы не рисковал и все таки указывал явно > max-age=0. RFC 2616 говорит про особый случай "max-age=0", но, насколько я понял, это касается request headers, а не response headers. где упоминается max-age=0 в применении к заголовкам ответа, не подскажете? мы сталкивались с тем, что MSIE 6 не умеет if-not-modified/if-none-match, про оперу не слышал, что с ней не так ? в чем риск? > Если хочется сократить заголовки можно не указывать дерективу public, по > умолчанию кеш всегда считается public если не указано обратное, на мы обжигались с public-ом, сценарий был примерно такой, сайт отдает content-disposition: attachement, filename=blah-blah-blah, все браузеры нормально, а MSIE такие документы не отображал вообще. ну и у нас в основном https, поэтому public с тех пор не любим > продакшене можно не писать public там где кеш публичный. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245951,246090#msg-246090 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Tue Jan 7 13:41:19 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 7 Jan 2014 19:41:19 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CBFF90.8030001@csdoc.com> References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> <52CBFF90.8030001@csdoc.com> Message-ID: вторник, 7 января 2014 г. пользователь Gena Makhomed писал: > On 07.01.2014 12:59, Илья Шипицин wrote: > > On 04.01.2014 3:07, S.A.N wrote: >>> >> > Бекенд, не знает и не должен знать, какой тип кеша >>>> ему нужно ревалидировать, клиентский или кеш Nginx, >>>> по хорошему в первом и во втором случаи, механизм >>>> должен быть полностью одинаковым. >>>> >>> > каким же образом тогда nginx может узнать, какие ответы от >>> backend`а ему следует сохранять в своем кеше, а какие нет? >>> >> > каким образом - в треде это явно предлагалось, путем >> > > 1) кеширования контента, у которого выставлен max-age=0 (или остутствует) >> > > каким образом это поможет бороться с кешированием пустых 304 ответов, > которые приходят с backend`а с "Cache-Control: public, max-age=1" ? кеширование 304 может быть только с пустым телом. такова природа этого ответа. > > 2) прокидывания клиентских if-none-match/if-not-modified-since до бекенда >> > > только это как раз будет способ создать проблему, а не решить ее. > backend ответит 304 статусом и пустая страница попадет в кеш nginx. если бекенд ответит 304, то nginx тоже ответит 304. да, в этом случае тело ответа не нужно. если бекенд понял, что контент поменялся, то ответ будет 200 и будет тело. соответственно, когда тело нужно, оно есть. и наоборот. в чем проблема ? я вижу проблему в сильном усложнении логики. без бутылки будет не разобраться. прежде чем выпускать таких демонов, надо сто раз подумать. > > On 06.01.2014 10:35, S.A.N wrote: >>> >> > Отключить Nginx кеширования тоже не можем потому что на других uri мы >>>> используем Nginx кеширования, например uri >>>> /news/list >>>> Отдает контент с заголовками >>>> Cache-Control: public, max-age=1 >>>> Эта страница должна попадать в кеш Nginx. >>>> Имино с этой страницей и будут проблемы, >>>> если в папке кеша Nginx удалится файл кеша, >>>> и прийдет запрос от браузера с актуальным заголовками >>>> If-Modified-Since и If-None-Match, на этот запрос бекенд ответит 304 >>>> статусом и вернет заговок Cache-Control: public, max-age=1, >>>> в результате чего 304 ответ попадет в кеш Nginx. >>>> >>> > 304 ответ попадет в кеш nginx потому что Вы сами же включили >>> кеш nginx и сами же разрешили nginx кешировать этот ответ, >>> вернув заголовок Cache-Control: public, max-age=1 >>> который управляет одновеменно и клиентским кешем и кешем nginx. >>> >>> Добавьте к 304 ответам backend`а еще один заголовок X-Accel-Expires: 0 >>> который будет запрещать nginx кешировать такие ответы и будет вам >>> счастье. >>> >>> Ваш backend обязан знать о том, что есть два различных кеша, >>> если Вы хотите управлять ими по-разному. Иначе не получится. >>> >> > -- > Best regards, > Gena > > _______________________________________________ > 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 Tue Jan 7 14:35:44 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 16:35:44 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> <52CBFF90.8030001@csdoc.com> Message-ID: <52CC10C0.8030206@csdoc.com> On 07.01.2014 15:41, Илья Шипицин wrote: >>> 2) прокидывания клиентских if-none-match/if-not-modified-__since >>> до бекенда >> только это как раз будет способ создать проблему, а не решить ее. >> backend ответит 304 статусом и пустая страница попадет в кеш nginx. > если бекенд ответит 304, то nginx тоже ответит 304. да, в этом случае > тело ответа не нужно. > > если бекенд понял, что контент поменялся, то ответ будет 200 и будет тело. > > соответственно, когда тело нужно, оно есть. и наоборот. в чем проблема ? fastcgi_cache_key "$host$uri$is_args$args"; от backend`а приходит 304 ответ, который говорит nginx`у, чтобы тот положил ответ в свой кеш на 1 секунду, что nginx и делает. и все последующие GET запросы от других клиентов по этому cache_key будут получать пустую страницу, от закешированного ранее 304 ответа. ибо "Cache-Control: public, max-age=1" - backend части последующих запросов от клиентов просто не увидит, их будет обрабатывать nginx. поэтому надо или включать $http_if_modified_since и $http_if_none_match в *_cache_key (но это плохо) или запретить nginx кешировать 304 ответы. соответственно, если хочется и кеш на клиенте включить и кеш nginx выключить - то управлять этими двумя разными кешами надо backend`у. > On 06.01.2014 10:35, S.A.N wrote: > > Отключить Nginx кеширования тоже не можем потому что на > других uri мы > используем Nginx кеширования, например uri > /news/list > Отдает контент с заголовками > Cache-Control: public, max-age=1 > Эта страница должна попадать в кеш Nginx. > Имино с этой страницей и будут проблемы, > если в папке кеша Nginx удалится файл кеша, > и прийдет запрос от браузера с актуальным заголовками > If-Modified-Since и If-None-Match, на этот запрос бекенд > ответит 304 > статусом и вернет заговок Cache-Control: public, max-age=1, > в результате чего 304 ответ попадет в кеш Nginx. -- Best regards, Gena From chipitsine at gmail.com Tue Jan 7 15:00:35 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 7 Jan 2014 21:00:35 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CC10C0.8030206@csdoc.com> References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> <52CBFF90.8030001@csdoc.com> <52CC10C0.8030206@csdoc.com> Message-ID: вторник, 7 января 2014 г. пользователь Gena Makhomed писал: > On 07.01.2014 15:41, Илья Шипицин wrote: > > 2) прокидывания клиентских if-none-match/if-not-modified-__since >>>> до бекенда >>>> >>> > только это как раз будет способ создать проблему, а не решить ее. >>> backend ответит 304 статусом и пустая страница попадет в кеш nginx. >>> >> > если бекенд ответит 304, то nginx тоже ответит 304. да, в этом случае >> тело ответа не нужно. >> >> если бекенд понял, что контент поменялся, то ответ будет 200 и будет тело. >> >> соответственно, когда тело нужно, оно есть. и наоборот. в чем проблема ? >> > > fastcgi_cache_key "$host$uri$is_args$args"; > > от backend`а приходит 304 ответ, который говорит nginx`у, > чтобы тот положил ответ в свой кеш на 1 секунду, что nginx и делает. > > и все последующие GET запросы от других клиентов по этому cache_key > будут получать пустую страницу, от закешированного ранее 304 ответа. естественно, что нельзя отдавать пустые ответы на get-запросы, которые подразумевают непустое тело. именно в этом и заключается существнное усложнение логики. нет ничего страшного, что 304 ответы кешатся с пустым телом. проблема в том, что не всегда этот кеш можно использовать (если это ответ, на котрый мы отвечаем 304 - можно). и, честно, не очень понятно, в целом это будет хорошо или плохо. > > ибо "Cache-Control: public, max-age=1" - backend части последующих > запросов от клиентов просто не увидит, их будет обрабатывать nginx. > > поэтому надо или включать $http_if_modified_since и $http_if_none_match > в *_cache_key (но это плохо) или запретить nginx кешировать 304 ответы. > соответственно, если хочется и кеш на клиенте включить и кеш nginx > выключить - то управлять этими двумя разными кешами надо backend`у. > > On 06.01.2014 10:35, S.A.N wrote: >> >> Отключить Nginx кеширования тоже не можем потому что на >> других uri мы >> используем Nginx кеширования, например uri >> /news/list >> Отдает контент с заголовками >> Cache-Control: public, max-age=1 >> Эта страница должна попадать в кеш Nginx. >> Имино с этой страницей и будут проблемы, >> если в папке кеша Nginx удалится файл кеша, >> и прийдет запрос от браузера с актуальным заголовками >> If-Modified-Since и If-None-Match, на этот запрос бекенд >> ответит 304 >> статусом и вернет заговок Cache-Control: public, max-age=1, >> в результате чего 304 ответ попадет в кеш Nginx. >> > > -- > Best regards, > Gena > > _______________________________________________ > 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 Tue Jan 7 15:13:28 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 17:13:28 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> <52CBFF90.8030001@csdoc.com> <52CC10C0.8030206@csdoc.com> Message-ID: <52CC1998.1080209@csdoc.com> On 07.01.2014 17:00, Илья Шипицин wrote: > нет ничего страшного, что 304 ответы кешатся с пустым телом. On 04.01.2014 2:30, Maxim Dounin wrote: > Если от заголовка If-None-Match зависит ответ бекенда, то он > должен быть в ключе кеширования - либо явно, либо неявно (e.g. > через запрет кеширования ответов на запросы, где этот заголовок > присутствует). -- Best regards, Gena From chipitsine at gmail.com Tue Jan 7 15:52:10 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 7 Jan 2014 21:52:10 +0600 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CC1998.1080209@csdoc.com> References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> <52CBFF90.8030001@csdoc.com> <52CC10C0.8030206@csdoc.com> <52CC1998.1080209@csdoc.com> Message-ID: а это как посмотреть. с одной стороны, если бекенд видит ETag и отвечает "304 нет, не поменялся", то вроде как ответ не зависит от If-None-Match. с другой стороны, по факту тело ответа пустое, в этом смысле зависит. 7 января 2014 г., 21:13 пользователь Gena Makhomed написал: > On 07.01.2014 17:00, Илья Шипицин wrote: > >> нет ничего страшного, что 304 ответы кешатся с пустым телом. > > > On 04.01.2014 2:30, Maxim Dounin wrote: > >> Если от заголовка If-None-Match зависит ответ бекенда, то он >> должен быть в ключе кеширования - либо явно, либо неявно (e.g. >> через запрет кеширования ответов на запросы, где этот заголовок >> присутствует). > > -- > 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 Tue Jan 7 16:08:46 2014 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 07 Jan 2014 11:08:46 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CBFB87.8070502@csdoc.com> References: <52CBFB87.8070502@csdoc.com> Message-ID: > Торг здесь не уместен. Можно написать статью и без ревалидации по > ETag. > > Как реализовать ревалидацию по ETag, если его просто не будет у части > клиентов. В кеше ведь всегда находится только один вариант контента - > или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем > случае > встречаются оба этих варианта. Делать ревалидацию по If-None-Match > потом будет только та половина клиентов, которой больше повезло. Я не планировал торговаться, дело в том что я программист не администратор и хотел бы написать статью в первую очередь для программистов, в статье раскрыть проблемы создания эффективных валидаторов кеша, на данный момент самый эфективный валидатор это ETag, мы его используем не только как валидатор, но как прелоадер ключей к Memcache, но это разговор на целую статью. Без ETag статья про кеширования будет просто не интересна, писать шпаргалки для амдинов на тему как настроить кеширования Nginx на временной интервал, с последующей ревалидацией по IF-Modified-Since, как-то совсем грустно потому что на дворе уже 2014 г. > > Но это далекое будущее, сейчас меня больше интересует почему тот же > Squid > > прокси не удаляет клиенские заголовки кеширования и сам не кешит > ответ в 304 > > статусе и это все без спец конфига под каждый сайт :) > > squid - это forward proxy, а nginx - web server. что ж тут не > ясного... Для меня как для разработчика, важен момент прозрачной работы всех звений между приложением и клиентом, когда одно звено (Nginx) начинает удалять клиентские заголовки кеширования, это уже не прозрачное проксирования, это уже магия хаков, возможно оправданных, потому что таким образом Nginx форсирует наполнения своего кеша и защищает себя от проблемы кеширования 304 статуса, но то что это исключает возможность бекенда работать с клиенским кешированиям во внимания никто не брал, наверно дело в том что не многие одновременно на одном server{} используют Nginx кеширования и клиентское кеширования. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246102#msg-246102 From gmm at csdoc.com Tue Jan 7 17:26:33 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 19:26:33 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> <52CBFF90.8030001@csdoc.com> <52CC10C0.8030206@csdoc.com> <52CC1998.1080209@csdoc.com> Message-ID: <52CC38C9.7010406@csdoc.com> On 07.01.2014 17:52, Илья Шипицин wrote: > а это как посмотреть. с одной стороны, если бекенд видит ETag и > отвечает "304 нет, не поменялся", то вроде как ответ не зависит от > If-None-Match. с другой стороны, по факту тело ответа пустое, в этом > смысле зависит. Если в запросе есть If-None-Match - сервер ответи 304 без content`а. Если в запросе нет If-None-Match - сервер ответит 200 с content`ом. Чтобы не было проблем backend MUST отвечать 304 с X-Accel-Expires: 0 >>> Если от заголовка If-None-Match зависит ответ бекенда, то он >>> должен быть в ключе кеширования - либо явно, либо неявно (e.g. >>> через запрет кеширования ответов на запросы, где этот заголовок >>> присутствует). -- Best regards, Gena From gmm at csdoc.com Tue Jan 7 19:53:34 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 07 Jan 2014 21:53:34 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <52CBFB87.8070502@csdoc.com> Message-ID: <52CC5B3E.5050504@csdoc.com> On 07.01.2014 18:08, S.A.N wrote: >> Торг здесь не уместен. Можно написать статью и без ревалидации по >> ETag. ... > Я не планировал торговаться, дело в том что я программист не администратор и > хотел бы написать статью в первую очередь для программистов, в статье > раскрыть проблемы создания эффективных валидаторов кеша, на данный момент > самый эфективный валидатор это ETag, мы его используем не только как > валидатор, но как прелоадер ключей к Memcache, но это разговор на целую > статью. Было бы очень интересно почитать и о том, как это все сейчас делается на backend`е, без участия nginx. Потому что я пока что не могу понять что в этом php-скрипте на 200 строк. > Без ETag статья про кеширования будет просто не интересна, писать шпаргалки > для амдинов на тему как настроить кеширования Nginx на временной интервал, с > последующей ревалидацией по IF-Modified-Since, как-то совсем грустно потому > что на дворе уже 2014 г. Понятно. Но ведь валидацию по ETag в любом случае делает backend, потому что тот php-скрипт на 200 строк в любом случае не сможет выполняться внутри nginx. Модуль mod_perl - экспериментальный, лучше не включать его на production без крайней необходимости. А mod_lua судя по всему еще более экспериментальный чем mod_perl. Да и блокировать это будет nginx worker запросами к memcached, даже если бы модули mod_perl и mod_lua работали бы без глюков. Общая производительность системы от этого упадет а не вырастет. Теоретически, есть вариант - удалять из кеша nginx устаревшие записи с помощью fastcgi_cache_purge, но "This functionality is available as part of our commercial subscription only". Хотя судя по документации, fastcgi_cache_bypass будет делать почти то же самое, обновляя кеш nginx ответом на запрос клиента. >>> Но это далекое будущее, сейчас меня больше интересует почему тот же >> Squid >>> прокси не удаляет клиенские заголовки кеширования и сам не кешит >> ответ в 304 >>> статусе и это все без спец конфига под каждый сайт :) >> >> squid - это forward proxy, а nginx - web server. что ж тут не >> ясного... > > Для меня как для разработчика, важен момент прозрачной работы всех звений > между приложением и клиентом, когда одно звено (Nginx) начинает удалять > клиентские заголовки кеширования, это уже не прозрачное проксирования, это > уже магия хаков, возможно оправданных, потому что таким образом Nginx > форсирует наполнения своего кеша и защищает себя от проблемы кеширования 304 > статуса, но то что это исключает возможность бекенда работать с клиенским > кешированиям во внимания никто не брал, наверно дело в том что не многие > одновременно на одном server{} используют Nginx кеширования и клиентское > кеширования. Кстати, похоже, что есть вариант еще проще, используя директиву fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match и выставляя в ответе заголовок X-Accel-Expires: 0 если статус ответа backend`а будет 304. А если статус ответа 200 - то этот же ответ на запрос If-Modified-Since/If-None-Match будет автоматически обновлять и кеш nginx, на время X-Accel-Expires или max-age из Cache-Control. А если backend вдруг понимает, что ответ в кеше nginx устарел - тогда он может сам и сгенерировать запрос, который благодаря директиве fastcgi_cache_bypass уйдет на backend и обновит кеш. Управлять одновременно и кешем на стороне клиента/браузера и кешем nginx средствами backend`а можно, было бы желание. -- Best regards, Gena From nginx-forum at nginx.us Tue Jan 7 22:20:24 2014 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 07 Jan 2014 17:20:24 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CC5B3E.5050504@csdoc.com> References: <52CC5B3E.5050504@csdoc.com> Message-ID: <25cdd91fc6663cc76733e8b9751e723f.NginxMailingListRussian@forum.nginx.org> > Кстати, похоже, что есть вариант еще проще, используя директиву > fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match > и выставляя в ответе заголовок X-Accel-Expires: 0 > если статус ответа backend`а будет 304. Да, у меня крутился в голове вариант, использовать куки для fastcgi_no_cache. Схема следующая, скрипт который отдает приватный кеш, будет отдавать куку с path=$self_path, данная кука будет приходит только на данный uri, таким образом её можно использовать для условия в fastcgi_no_cache для выключения Nginx кеширования, осталось только проверить, удаляет Nginx клиентские заголовки если выполняется условия fastcgi_no_cache, если не удаляет, тогда этот вариант выглядит лучше чем прописывать location в конфиге Nginx. Насчет запрета кеширования 304 статуса, я начал склонятся к мысли что бекенд не должен клиенту повторно отдавать заголовки Cache-Control. Если бекенд не будет отдавать эти заголовки, Nginx не будет сохранять данный ответ в своем кеше, потому что в конфиге прописано fastcgi_cache_valid 200 301 302 0s; В последних наших тестах выяснилось что все современные браузеры, нормально реагируют на отсутствия заголовков Cache-Control в ответе с 304 статусом, хотя спецификации HTTP требует наличия этого заголовка. Вопрос к сообществу, какие проблемы могут возникнуть, если в 304 статусе не будет заголовка Cache-Control? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246111#msg-246111 From gmm at csdoc.com Wed Jan 8 16:36:30 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 08 Jan 2014 18:36:30 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CBD84A.1070405@csdoc.com> References: <52CA7F98.8060503@csdoc.com> <52CBD84A.1070405@csdoc.com> Message-ID: <52CD7E8E.4070607@csdoc.com> On 07.01.2014 12:34, Gena Makhomed wrote: > Ваш вариант > > fastcgi_cache_methods GET HEAD; > fastcgi_cache_key "$host$uri$is_args$args"; > > не оптимален, включает $uri$is_args$args вместо $request_uri тут я тоже был неправ: ================================================================= http://mailman.nginx.org/pipermail/nginx-ru/2010-June/034701.html From: Igor Sysoev $request_uri я бы не рекомендовал использовать, лучше уже нормализованный вариант "$uri?$args". ================================================================= P.S. но в таком случае не понятно, почему $request_uri в default: ================================================================= http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_key syntax: proxy_cache_key string; default: proxy_cache_key $scheme$proxy_host$request_uri; ================================================================= -- Best regards, Gena From mdounin at mdounin.ru Thu Jan 9 12:10:31 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 9 Jan 2014 16:10:31 +0400 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <52CBE171.9070000@csdoc.com> References: <52CBE171.9070000@csdoc.com> Message-ID: <20140109121031.GC1835@mdounin.ru> Hello! On Tue, Jan 07, 2014 at 01:13:53PM +0200, Gena Makhomed wrote: > > почитал доку по директивам proxy_cache_key и fastcgi_cache_key, > появилось много вопросов. > > для директив proxy_cache_methods и fastcgi_cache_methods > значение по-умолчанию GET HEAD; - то есть будут кешироваться > как ответы на GET, так и ответы на HEAD запросы от клиентов. > > вместе с тем, в документации во всех примерах использования > директив proxy_cache_key и fastcgi_cache_key нигде не указано > зависимости от $request_method, следовательно будет этот глюк: > > http://habrahabr.ru/post/72539/ > > : Особого внимания заслуживает значение в директиве fastcgi_cache_key. > : Я привел минимальное рабочее значение этой директивы. Шаг вправо, > : шаг влево, и вы начнете в ряде случаев получать ?неправильные? данные > : из кэша. Итак: > : Зависимость от $request_method нам нужна, т.к. HEAD-запросы > : в Интернете довольно часты. Ответ на HEAD-запрос никогда > : не содержит тела. Если убрать зависимость от $request_method, > : то может так совпасть, что кто-то до вас запросил главную страницу > : HEAD-методом, а вам потом по GET отдастся пустой контент. > > может быть имеет смысл поправить все примеры в документации, > чтобы proxy_cache_key и fastcgi_cache_key включали в себя > зависимость от $request_method ? Нет, при использовании кеширования HEAD-запросы передаются на бекенд с изменением метода на GET. > второй вопрос - по поводу дефолтовых значений > proxy_cache_key и fastcgi_cache_key, они почему-то разные. > > syntax: fastcgi_cache_key string; > default: ? > > syntax: proxy_cache_key string; > default: proxy_cache_key $scheme$proxy_host$request_uri; > > может быть имеет смысл их сделать одинаковыми, > и тоже включить в них зависимость от $request_method ? > > только наверное вместо $proxy_host лучше использовать переменную $host. > потому что запросы с разными заголовками Host: могут проксироваться > на один и тот же backend с одинаковым значением $proxy_host и тогда, > при *дефолтовом* значении proxy_cache_key - nginx будет отдавать > клиентам ошибочные страницы из своего кеша, от совсем другого сайта. Смысл значения по умолчанию для proxy_cache_key состоит в том, что идентифицируется тот ресурс, куда осуществялется проксирование. Тем самым, если в разных виртуальных серверах проксирование осуществляется в одно и то же место - будет использован один и тот же элемент кеша. -- Maxim Dounin http://nginx.org/ From gmm at csdoc.com Thu Jan 9 13:57:19 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 09 Jan 2014 15:57:19 +0200 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <20140109121031.GC1835@mdounin.ru> References: <52CBE171.9070000@csdoc.com> <20140109121031.GC1835@mdounin.ru> Message-ID: <52CEAABF.6030504@csdoc.com> On 09.01.2014 14:10, Maxim Dounin wrote: >> второй вопрос - по поводу дефолтовых значений >> proxy_cache_key и fastcgi_cache_key, они почему-то разные. >> >> syntax: fastcgi_cache_key string; >> default: ? >> >> syntax: proxy_cache_key string; >> default: proxy_cache_key $scheme$proxy_host$request_uri; ... > Смысл значения по умолчанию для proxy_cache_key состоит в том, что > идентифицируется тот ресурс, куда осуществялется проксирование. > Тем самым, если в разных виртуальных серверах проксирование > осуществляется в одно и то же место - будет использован один и тот > же элемент кеша. так ведь именно в этом и состоит суть проблемы. в разных виртуальных серверах проксирование обычно осуществляется на один и тот же backend/upstream, и для *разных* виртуальных серверов будет использован один и тот же элемент кеша $scheme$XXX$request_uri. при proxy_pass http://127.0.0.1:80/ в $proxy_host окажется 127.0.0.1 аналогично, и в случае fastcgi_cache_key localhost:9000$request_uri; - запросы к разным virtual host`ам будут попадать в один и тот же элемент кеша, и nginx не будет различать *разные* virtual host`ы. возможно имеет смысл дефолтовые настройки сделать такими, чтобы они были безопасными по-умолчанию для всех пользователей? т.е. $host вместо $proxy_host ? дополнительный плюс: в этом случае можно будет сделать дефолтовые значения fastcgi_cache_key и proxy_cache_key идентичными, это будет симметрия и это не будет вызывать лишних вопросов у пользователей. =================================================================== кстати, аналогичный вопрос касается и дефолтового значнеия proxy_set_header - http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header syntax: proxy_set_header field value; default: proxy_set_header Host $proxy_host; proxy_set_header Connection close; хотя ниже идет рекомендация делать proxy_set_header Host $host; почему бы не сделать $host значением по-умолчанию? в fastcgi_params: fastcgi_param SERVER_NAME $server_name - разве здесь не будет лучше передавать значение $host ? если пользователь пишет в конфиге server_name example.com example.net example.org; fastcgi_pass ... ; - на backend придет example.com даже в том случае, если исходный запрос был к example.org или к example.net почему бы здесь тоже не передавать $host ? тогда fastcgi_* и proxy_* будут максимально похожи между собой, что облегчит пользователям миграцию между разными типами backend`ов. ведь нигде в спецификации fastcgi не требуется передавать другое имя хоста в SERVER_NAME, вместо того, на которое пришел исходный запрос. тем более, что CGI спецификация, на которой основана FastCGI спецификация писалась еще в то время, когда никаких виртуальных хостов еше даже в проекте не было. Там имеется ввиду все-таки $host P.S. решить проблему дублирования кеша для разных имен www.example.com и example.com очень просто - выключить кеш на example.com и сделать редирект на www.example.com - это и с точки зрения SEO полезно будет. а кому надо дублирование контента на двух разных доменах в интернете - могут явно прописать www.example.com или $server_name в *_cache_key вместо дефолтового значения $host. -- Best regards, Gena From mdounin at mdounin.ru Thu Jan 9 14:33:25 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 9 Jan 2014 18:33:25 +0400 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <52CEAABF.6030504@csdoc.com> References: <52CBE171.9070000@csdoc.com> <20140109121031.GC1835@mdounin.ru> <52CEAABF.6030504@csdoc.com> Message-ID: <20140109143325.GJ1835@mdounin.ru> Hello! On Thu, Jan 09, 2014 at 03:57:19PM +0200, Gena Makhomed wrote: > On 09.01.2014 14:10, Maxim Dounin wrote: [...] > >Смысл значения по умолчанию для proxy_cache_key состоит в том, что > >идентифицируется тот ресурс, куда осуществялется проксирование. > > >Тем самым, если в разных виртуальных серверах проксирование > >осуществляется в одно и то же место - будет использован один и тот > >же элемент кеша. > > так ведь именно в этом и состоит суть проблемы. в разных виртуальных > серверах проксирование обычно осуществляется на один и тот же > backend/upstream, и для *разных* виртуальных серверов будет > использован один и тот же элемент кеша $scheme$XXX$request_uri. > > при proxy_pass http://127.0.0.1:80/ в $proxy_host окажется 127.0.0.1 > аналогично, и в случае fastcgi_cache_key localhost:9000$request_uri; > > - запросы к разным virtual host`ам будут попадать в один и тот же > элемент кеша, и nginx не будет различать *разные* virtual host`ы. > > возможно имеет смысл дефолтовые настройки сделать такими, > чтобы они были безопасными по-умолчанию для всех пользователей? > т.е. $host вместо $proxy_host ? В запросах на бекенд по умолчанию в заголовке Host передаётся именно $proxy_host, и значение proxy_cache_key соответсвует тому, что происходит по умолчанию. Т.е. по умолчанию - всё безопасно. Если же говорить о том, что может быть достугнуто с помощью худождественного выпиливания по конфигу без понимания происходящего - то вывод "Мы все умрём" никто не отменял. [...] > кстати, аналогичный вопрос касается и дефолтового значнеия proxy_set_header > - http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header > > syntax: proxy_set_header field value; > default: proxy_set_header Host $proxy_host; > proxy_set_header Connection close; > > хотя ниже идет рекомендация делать proxy_set_header Host $host; > почему бы не сделать $host значением по-умолчанию? Ниже говорится о том, что если хочется передать на бекенд значение Host'а из запроса, то этом можно сделать с помощью $http_host, но лучше - с помощью $host (и объясняется, почему). [...] -- Maxim Dounin http://nginx.org/ From andrei.seredenko at gmail.com Thu Jan 9 14:55:57 2014 From: andrei.seredenko at gmail.com (=?KOI8-R?B?4c7E0sXKIPPF0sXExc7Lzw==?=) Date: Thu, 9 Jan 2014 17:55:57 +0300 Subject: =?UTF-8?B?MzAxIHJlZGlyZWN0INC90LAgVVJJINCx0LXQtyDRgdC70Y3RiNCwINC90LAg0Lo=?= =?UTF-8?B?0L7QvdGG0LU=?= Message-ID: Здравия, друзья! Всех с прошедшими праздниками! В процессе приведения конфигурации своих веб-серверов в более лицеприятный столкнулся с таким моментом: автоматическое добавление слэша не происходит после отрабатывания директивы try_files. Было неожиданно. Немного примеров, чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и "после"): location /webapp/ { proxy_pass http://app_upstream; include my-site/proxy_pass_params.conf; } Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать и без того кривое приложение:) В итоге, location принял следующий облик: location /webapp/ { root /var/www/webapps/nginx-static; try_files $uri @application-handle; } location @application-handle { proxy_pass http://app_upstream; include my-site/proxy_pass_params.conf; } В результате, в принципе, получил то, что хотел: запрашиваемые файлы сначала ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, - проксируем на приложение. Но - перестали обрабатываться запросы вида http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со слэшем на конце) обрабатываются корректно. Оно то, в общем-то, и правильно: в документации сказано: Если location задан префиксной строкой со слэшом в конце и запросы > обрабатываются при помощи proxy_pass > , fastcgi_pass > , scgi_pass > , uwsgi_pass > или memcached_pass, > а в ответ на запрос с URI равным этой строке, но без завершающего слэша, > будет возвращено постоянное перенаправление с кодом 301 на URI с > добавленным в конец слэшом. Если такое поведение нежелательно, можно задать > точное совпадение URI и location, например: > > location /user/ { > proxy_pass http://user.example.com; > } > > location = /user { > proxy_pass http://login.example.com; > } > > > Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как вернуть прежнее поведение? можно ли сделать это "красиво"? или придется городить магию с реврайтами? а если писать реврайты - куда их пихать.. в общем, как-то так. Как-то сходу не получилось самому ответить на эти вопросы, решил поделиться с сообществом. Буду признателен за любые предложения выхода из ситуации. Немного информации, которая может быть полезной: [ root at app1 ~]# nginx -V > nginx version: nginx/1.0.15 > built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) > TLS SNI support enabled > configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx > --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log > --http-client-body-temp-path=/var/lib/nginx/tmp/client_body > --http-proxy-temp-path=/var/lib/nginx/tmp/proxy > --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi > --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi > --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid > --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx > --with-file-aio --with-ipv6 --with-http_ssl_module > --with-http_realip_module --with-http_addition_module > --with-http_xslt_module --with-http_image_filter_module > --with-http_geoip_module --with-http_sub_module --with-http_dav_module > --with-http_flv_module --with-http_mp4_module > --with-http_gzip_static_module --with-http_random_index_module > --with-http_secure_link_module --with-http_degradation_module > --with-http_stub_status_module --with-http_perl_module --with-mail > --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ld-opt=-Wl,-E > > [ root at app1 ~]# lsb_release -a > LSB Version: > :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch > Distributor ID: CentOS > Description: CentOS release 6.2 (Final) > Release: 6.2 > Codename: Final > > [ root at app1 ~]# uname -a > Linux app1 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012 > x86_64 x86_64 x86_64 GNU/Linux > Содержимое my-site/proxy_pass_params.conf (роли наверняка не играет, но для полноты картины - надо): proxy_redirect off; > > proxy_set_header Host $host; > proxy_set_header Remote-Addr $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Public-Url http://$host$request_uri; > > client_max_body_size 40m; > client_body_buffer_size 128k; > > proxy_connect_timeout 90; > proxy_send_timeout 90; > proxy_read_timeout 2600; > > proxy_buffer_size 4k; > proxy_buffers 4 32k; > proxy_busy_buffers_size 64k; > proxy_temp_file_write_size 64k; > awaiting.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Thu Jan 9 15:09:55 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 09 Jan 2014 19:09:55 +0400 Subject: =?UTF-8?B?UmU6IDMwMSByZWRpcmVjdCDQvdCwIFVSSSDQsdC10Lcg0YHQu9GN0YjQsCDQvdCw?= =?UTF-8?B?INC60L7QvdGG0LU=?= In-Reply-To: References: Message-ID: <14941915.DxqLoJrPjY@vbart-laptop> On Thursday 09 January 2014 17:55:57 Андрей Середенко wrote: > Здравия, друзья! Всех с прошедшими праздниками! > > В процессе приведения конфигурации своих веб-серверов в более лицеприятный > столкнулся с таким моментом: автоматическое добавление слэша не происходит > после отрабатывания директивы try_files. Было неожиданно. Немного примеров, > чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и > "после"): > > location /webapp/ { > proxy_pass http://app_upstream; > include my-site/proxy_pass_params.conf; > } > > Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать > и без того кривое приложение:) В итоге, location принял следующий облик: > > location /webapp/ { > root /var/www/webapps/nginx-static; > try_files $uri @application-handle; > } > > location @application-handle { > proxy_pass http://app_upstream; > include my-site/proxy_pass_params.conf; > } > > В результате, в принципе, получил то, что хотел: запрашиваемые файлы > сначала ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, - > проксируем на приложение. Но - перестали обрабатываться запросы вида > http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со > слэшем на конце) обрабатываются корректно. > Оно то, в общем-то, и правильно: в документации сказано: > > Если location задан префиксной строкой со слэшом в конце и запросы > > > обрабатываются при помощи > > proxy_pass > _pass> , > > fastcgi_pass > astcgi_pass> , > > scgi_pass > ss> , > > uwsgi_pass > _pass>> > > или > > memcached_pass > tml#memcached_pass>, > > > а в ответ на запрос с URI равным этой строке, но без завершающего слэша, > > будет возвращено постоянное перенаправление с кодом 301 на URI с > > добавленным в конец слэшом. Если такое поведение нежелательно, можно > > задать точное совпадение URI и location, например: > > > > > > > > location /user/ { > > > > proxy_pass http://user.example.com; > > > > } > > > > > > > > location = /user { > > > > proxy_pass http://login.example.com; > > > > } > > > > > > > > > > Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как > > вернуть прежнее поведение? можно ли сделать это "красиво"? или придется > городить магию с реврайтами? а если писать реврайты - куда их пихать.. в > общем, как-то так. Как-то сходу не получилось самому ответить на эти > вопросы, решил поделиться с сообществом. Буду признателен за любые > предложения выхода из ситуации. > [...] Вся магия сводится к добавлению: location = /webapp { return 301 /webapp/; } -- Валентин Бартенев From chipitsine at gmail.com Thu Jan 9 15:41:05 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 9 Jan 2014 21:41:05 +0600 Subject: =?UTF-8?B?UmU6IDMwMSByZWRpcmVjdCDQvdCwIFVSSSDQsdC10Lcg0YHQu9GN0YjQsCDQvdCw?= =?UTF-8?B?INC60L7QvdGG0LU=?= In-Reply-To: References: Message-ID: мы вот так делаем root /var/www/webapps/nginx-static; location /webapp/ { try_files $uri $uri/ @application-handle; } location @application-handle { include my-site/proxy_pass_params.conf; proxy_pass http://app_upstream; } 1) в try_files пишем $uri и $uri/ 2) root-у нечего делать в location-е 3) include лучше делать в самую первую очередь, чтобы переопределенные параметры (если они будут) не перетерлись include-овыми 9 января 2014 г., 20:55 пользователь Андрей Середенко написал: > Здравия, друзья! Всех с прошедшими праздниками! > > В процессе приведения конфигурации своих веб-серверов в более лицеприятный > столкнулся с таким моментом: автоматическое добавление слэша не происходит > после отрабатывания директивы try_files. Было неожиданно. Немного примеров, > чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и > "после"): > > location /webapp/ { > proxy_pass http://app_upstream; > include my-site/proxy_pass_params.conf; > } > > Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать и > без того кривое приложение:) В итоге, location принял следующий облик: > > location /webapp/ { > root /var/www/webapps/nginx-static; > try_files $uri @application-handle; > } > > location @application-handle { > proxy_pass http://app_upstream; > include my-site/proxy_pass_params.conf; > } > > В результате, в принципе, получил то, что хотел: запрашиваемые файлы сначала > ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, - > проксируем на приложение. Но - перестали обрабатываться запросы вида > http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со > слэшем на конце) обрабатываются корректно. > Оно то, в общем-то, и правильно: в документации сказано: > >> Если location задан префиксной строкой со слэшом в конце и запросы >> обрабатываются при помощи proxy_pass, fastcgi_pass, scgi_pass, uwsgi_pass >> или memcached_pass, а в ответ на запрос с URI равным этой строке, но без >> завершающего слэша, будет возвращено постоянное перенаправление с кодом 301 >> на URI с добавленным в конец слэшом. Если такое поведение нежелательно, >> можно задать точное совпадение URI и location, например: >> >> location /user/ { >> proxy_pass http://user.example.com; >> } >> >> location = /user { >> proxy_pass http://login.example.com; >> } >> >> > Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как > вернуть прежнее поведение? можно ли сделать это "красиво"? или придется > городить магию с реврайтами? а если писать реврайты - куда их пихать.. в > общем, как-то так. Как-то сходу не получилось самому ответить на эти > вопросы, решил поделиться с сообществом. Буду признателен за любые > предложения выхода из ситуации. > > Немного информации, которая может быть полезной: > >> [ root at app1 ~]# nginx -V >> nginx version: nginx/1.0.15 >> built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) >> TLS SNI support enabled >> configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx >> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log >> --http-log-path=/var/log/nginx/access.log >> --http-client-body-temp-path=/var/lib/nginx/tmp/client_body >> --http-proxy-temp-path=/var/lib/nginx/tmp/proxy >> --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi >> --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi >> --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid >> --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx >> --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_realip_module >> --with-http_addition_module --with-http_xslt_module >> --with-http_image_filter_module --with-http_geoip_module >> --with-http_sub_module --with-http_dav_module --with-http_flv_module >> --with-http_mp4_module --with-http_gzip_static_module >> --with-http_random_index_module --with-http_secure_link_module >> --with-http_degradation_module --with-http_stub_status_module >> --with-http_perl_module --with-mail --with-mail_ssl_module >> --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' >> --with-ld-opt=-Wl,-E >> >> [ root at app1 ~]# lsb_release -a >> LSB Version: >> :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch >> Distributor ID: CentOS >> Description: CentOS release 6.2 (Final) >> Release: 6.2 >> Codename: Final >> >> [ root at app1 ~]# uname -a >> Linux app1 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012 >> x86_64 x86_64 x86_64 GNU/Linux > > > Содержимое my-site/proxy_pass_params.conf (роли наверняка не играет, но для > полноты картины - надо): > >> proxy_redirect off; >> >> proxy_set_header Host $host; >> proxy_set_header Remote-Addr $remote_addr; >> proxy_set_header X-Real-IP $remote_addr; >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> proxy_set_header X-Public-Url http://$host$request_uri; >> >> client_max_body_size 40m; >> client_body_buffer_size 128k; >> >> proxy_connect_timeout 90; >> proxy_send_timeout 90; >> proxy_read_timeout 2600; >> >> proxy_buffer_size 4k; >> proxy_buffers 4 32k; >> proxy_busy_buffers_size 64k; >> proxy_temp_file_write_size 64k; > > > awaiting.. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ilya at pirogov.me Thu Jan 9 15:43:42 2014 From: ilya at pirogov.me (Ilya Pirogov) Date: Thu, 9 Jan 2014 19:43:42 +0400 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <25cdd91fc6663cc76733e8b9751e723f.NginxMailingListRussian@forum.nginx.org> References: <52CC5B3E.5050504@csdoc.com> <25cdd91fc6663cc76733e8b9751e723f.NginxMailingListRussian@forum.nginx.org> Message-ID: 2014/1/8 S.A.N > > Кстати, похоже, что есть вариант еще проще, используя директиву > > fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match > > и выставляя в ответе заголовок X-Accel-Expires: 0 > > если статус ответа backend`а будет 304. > > Да, у меня крутился в голове вариант, использовать куки для > fastcgi_no_cache. > А зачем использовать куку? Почему нельзя просто прописать: fastcgi_no_cache $upstream_http_etag; fastcgi_cache_bypass $http_if_none_match; Ведь для public кеша, насколько я понял, ETag не отдается. -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Thu Jan 9 17:28:49 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 9 Jan 2014 21:28:49 +0400 Subject: Slowloris attack Message-ID: <1509675675.20140109212849@softsearch.ru> Здравствуйте. Хотел спросить, а как с Slowloris attack справляется nginx? Он просто тупо держит все соединения и старается при этом выделять минимум памяти? Или ещё что-то делается? -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Thu Jan 9 18:15:34 2014 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 09 Jan 2014 13:15:34 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: Message-ID: <6d93e7b542e80f369472360e13ed8bd7.NginxMailingListRussian@forum.nginx.org> > А зачем использовать куку? Почему нельзя просто прописать: > > fastcgi_no_cache $upstream_http_etag; > fastcgi_cache_bypass $http_if_none_match; > > Ведь для public кеша, насколько я понял, ETag не отдается. Для public кеш, ETag отдается. Это сделано на перспективу, в будущем Nginx будет поддерживать ревалидацию своего кеша по If-None-Match (ETag) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246192#msg-246192 From hunter at comsys.com.ua Thu Jan 9 18:35:13 2014 From: hunter at comsys.com.ua (Sergey Smitienko) Date: Thu, 09 Jan 2014 20:35:13 +0200 Subject: Slowloris attack In-Reply-To: <1509675675.20140109212849@softsearch.ru> References: <1509675675.20140109212849@softsearch.ru> Message-ID: <52CEEBE1.5040200@comsys.com.ua> Здравствуйте. Поставьте маленьки******й client_header_timeout, client_body_timeout и лимит на число подключений с одного IP. Теоретически частично во FreeBSD может помочь httpready accept filter, но сам не пробовал. В последний раз у меня было открыто порядка 30K подключений, особо жить не мешало. А дальше по логу строился firewall и весь ботнет посылается в /dev/null. Кстати, была бы интересна возможность повесить свой perl обработчик на различные ошибки, чтобы банить IP прямо из nginx'a ??? 1/9/14 7:28 PM, Михаил Монашёв пишет: > Здравствуйте. > > Хотел спросить, а как с Slowloris attack справляется nginx? Он просто > тупо держит все соединения и старается при этом выделять минимум > памяти? Или ещё что-то делается? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Thu Jan 9 18:49:59 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 09 Jan 2014 20:49:59 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <25cdd91fc6663cc76733e8b9751e723f.NginxMailingListRussian@forum.nginx.org> References: <52CC5B3E.5050504@csdoc.com> <25cdd91fc6663cc76733e8b9751e723f.NginxMailingListRussian@forum.nginx.org> Message-ID: <52CEEF57.3070400@csdoc.com> On 08.01.2014 0:20, S.A.N wrote: >> Кстати, похоже, что есть вариант еще проще, используя директиву >> fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match >> и выставляя в ответе заголовок X-Accel-Expires: 0 >> если статус ответа backend`а будет 304. > Да, у меня крутился в голове вариант, использовать куки для fastcgi_no_cache. > Схема следующая, скрипт который отдает приватный кеш, будет отдавать куку с > path=$self_path, данная кука будет приходит только на данный uri, таким > образом её можно использовать для условия в fastcgi_no_cache для выключения > Nginx кеширования, Директива fastcgi_no_cache не смотрит на куки клиентского запроса, она смотрит на ответ backend`а и по этому ответу решает, помещать его в кеш nginx или нет. А если надо чтобы клиентский запрос уходил мимо кеша nginx прямо на backend для этого есть совсем другая диркетива, fastcgi_cache_bypass. Это же в документации все написано. Очень трудно придумать ситуацию, когда этих двух директив может оказаться не достаточно для настройки кеширования. > осталось только проверить, удаляет Nginx клиентские > заголовки если выполняется условия fastcgi_no_cache, если не удаляет, тогда > этот вариант выглядит лучше чем прописывать location в конфиге Nginx. Для тех страниц, которые не надо сохранять в кеше nginx - возвращать в ответе backend`а заголовок X-Accel-Expires: 0 и такой ответ не будет попадать в кеш nginx, вне зависимости от того, что записано во всех остальных заголовках этого ответа. В том числе и в заголовке ответа Cache-Control. Чем такой простой и удобный вариант Вам не подходит, я не понимаю. -- Best regards, Gena From gmm at csdoc.com Thu Jan 9 18:59:08 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 09 Jan 2014 20:59:08 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CEEF57.3070400@csdoc.com> References: <52CC5B3E.5050504@csdoc.com> <25cdd91fc6663cc76733e8b9751e723f.NginxMailingListRussian@forum.nginx.org> <52CEEF57.3070400@csdoc.com> Message-ID: <52CEF17C.3010502@csdoc.com> On 09.01.2014 20:49, Gena Makhomed wrote: > Директива fastcgi_no_cache не смотрит на куки клиентского запроса, > она смотрит на ответ backend`а и по этому ответу решает, > помещать его в кеш nginx или нет. sorry, я тут ошибся. смотрит и на запрос и на ответ тоже. -- Best regards, Gena From nginx-forum at nginx.us Thu Jan 9 19:03:32 2014 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 09 Jan 2014 14:03:32 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <52CEAABF.6030504@csdoc.com> References: <52CEAABF.6030504@csdoc.com> Message-ID: Gena Makhomed Wrote: ------------------------------------------------------- > возможно имеет смысл дефолтовые настройки сделать такими, > чтобы они были безопасными по-умолчанию для всех пользователей? > т.е. $host вместо $proxy_host ? Поддержу данную мысль, это добавило бы безопасности дефолтного конфига Nginx. Вот наглядный пример: fastcgi_param HTTP_HOST1 $http_host; fastcgi_param HTTP_HOST2 $host; fastcgi_param HTTP_HOST3 $server_name; Делаем, запрос GET http://site3.dev/ HTTP/1.1 Host:~%#$^&*()<>?@\!."'{}[]=+| На выходе получим _SERVER["HTTP_HOST1"]: ~%#$^&*()<>?@\!."'{}[]=+| _SERVER["HTTP_HOST2"]: site3.dev _SERVER["HTTP_HOST3"]: site2.dev Кому интересно почитать, подробней вот ссылка. http://habrahabr.ru/post/166855/ Как видите, корректное значения имеют только переменные $host и $server_name, все что основывается на $http_host имеет потенциал уязвимость, если бекенд доверяет этой переменой, лично я знаю несколько популярных РНР фрейморков которые используют эту переменную без проверки и без экранирования в SQL запросах. Для вирт хостов $server_name нельзя использовать как HTTP_HOST, вот переменную $host можно и считаю нужно использовать как HTTP_HOST. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,246198#msg-246198 From vbart at nginx.com Thu Jan 9 19:07:32 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 09 Jan 2014 23:07:32 +0400 Subject: =?UTF-8?B?UmU6IDMwMSByZWRpcmVjdCDQvdCwIFVSSSDQsdC10Lcg0YHQu9GN0YjQsCDQvdCw?= =?UTF-8?B?INC60L7QvdGG0LU=?= In-Reply-To: References: Message-ID: <1521773.cdsOfPhFOc@vbart-laptop> On Thursday 09 January 2014 21:41:05 Илья Шипицин wrote: > мы вот так делаем > > > root /var/www/webapps/nginx-static; > > location /webapp/ { > try_files $uri $uri/ @application-handle; > } > > location @application-handle { > include my-site/proxy_pass_params.conf; > proxy_pass http://app_upstream; > } > > > 1) в try_files пишем $uri и $uri/ > 2) root-у нечего делать в location-е > 3) include лучше делать в самую первую очередь, чтобы переопределенные > параметры (если они будут) не перетерлись include-овыми > [..] Только обращаю внимание, что с точки зрения обработки запроса "/webapp", о котором спрашивает автор темы, ваша конфигурация ничем не отличается. -- Валентин Бартенев From nginx-forum at nginx.us Thu Jan 9 19:16:10 2014 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 09 Jan 2014 14:16:10 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CEEF57.3070400@csdoc.com> References: <52CEEF57.3070400@csdoc.com> Message-ID: > Чем такой простой и удобный вариант Вам не подходит, я не понимаю. Дело в том что я ленивый перфекционист, не люблю писать лишний код :) X-Accel-Expires рабочий вариант и он подходит, просто я не уверен что это идеал вариант, по этому не спешу реализовывать такие идеи, пока не найду идею код которой будет приближается к нулю строчек кода :) Потому что бекенд все делает правильно и не хочется добавлять в него костыли для решения проблем с Nginx. Но вам спасибо за качественные идеи, думаю что данную тему можно закрывать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246201#msg-246201 From andrei.seredenko at gmail.com Thu Jan 9 19:27:20 2014 From: andrei.seredenko at gmail.com (=?KOI8-U?B?4c7E0sXKIPPF0sXExc7Lzw==?=) Date: Thu, 9 Jan 2014 22:27:20 +0300 Subject: nginx-ru Digest, Vol 51, Issue 18 In-Reply-To: References: Message-ID: > > Вся магия сводится к добавлению: > > location = /webapp { > return 301 /webapp/; > } Спасибо, Валентин! Чет как-то об этой "магии" я не подумал.) Обязательно попробуем. мы вот так делаем root /var/www/webapps/nginx-static; > > location /webapp/ { > try_files $uri $uri/ @application-handle; > } > > location @application-handle { > include my-site/proxy_pass_params.conf; > proxy_pass http://app_upstream; > } > > > 1) в try_files пишем $uri и $uri/ > 2) root-у нечего делать в location-е > 3) include лучше делать в самую первую очередь, чтобы переопределенные > параметры (если они будут) не перетерлись include-овыми и Вам, Илья, Спасибо. Но - увы: если в try_files указать $uri и $uri/, то на запрос /webapp/ будет прилетать 403. Пробовали.. По поводу root'a в location'е - тоже не тот случай: локейшн не один, равно как и приложение не единственное, и прописывать рут на уровне server'a нет возможности. А делать отдельную секцию server'a для каждого приложения.. ну не знаю, не знаю - что-то меня тут коробит:) Что же касается инклюдов - учту, спасибо. Хотя у меня есть некоторые сомнения, что эти параметры унаследуются при проксировании, если определить их до.. впрочем, это легко проверить. Всем спасибо за помощь! 9 января 2014 г., 21:35 пользователь написал: > Сообщения, предназначенные для списка рассылки nginx-ru, необходимо > отправлять по адресу > nginx-ru at nginx.org > > Для изменения параметров подписки вы можеже использовать веб-страницу > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Для получения информации о том, как пользовать почтовым интерфейсом, > отправьте письмо, в теле или теме которого будет слово 'help', по > адресу: > nginx-ru-request at nginx.org > > Адрес человека, ответственного за этот список рассылки: > nginx-ru-owner at nginx.org > > При ответе, пожалуйста, измение тему письма так, чтобы она была более > содержательной чем "Re: Содержание дайджеста списка рассылки > nginx-ru..." > > Today's Topics: > > 1. Re: 301 redirect на URI без слэша на конце (Валентин Бартенев) > 2. Re: 301 redirect на URI без слэша на конце (Илья Шипицин) > 3. Re: Bug ? 304 status - Cache-Control (Ilya Pirogov) > 4. Slowloris attack (Михаил Монашёв) > 5. Re: Bug ? 304 status - Cache-Control (S.A.N) > 6. Re: Slowloris attack (Sergey Smitienko) > > > ---------- Пересылаемое сообщение ---------- > From: "Валентин Бартенев" > To: nginx-ru at nginx.org > Cc: > Date: Thu, 09 Jan 2014 19:09:55 +0400 > Subject: Re: 301 redirect на URI без слэша на конце > On Thursday 09 January 2014 17:55:57 Андрей Середенко wrote: > > Здравия, друзья! Всех с прошедшими праздниками! > > > > В процессе приведения конфигурации своих веб-серверов в более > лицеприятный > > столкнулся с таким моментом: автоматическое добавление слэша не > происходит > > после отрабатывания директивы try_files. Было неожиданно. Немного > примеров, > > чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и > > "после"): > > > > location /webapp/ { > > proxy_pass http://app_upstream; > > include my-site/proxy_pass_params.conf; > > } > > > > Подумалось, что правильнее отдавать статику силами nginx'а, а не > напрягать > > и без того кривое приложение:) В итоге, location принял следующий облик: > > > > location /webapp/ { > > root /var/www/webapps/nginx-static; > > try_files $uri @application-handle; > > } > > > > location @application-handle { > > proxy_pass http://app_upstream; > > include my-site/proxy_pass_params.conf; > > } > > > > В результате, в принципе, получил то, что хотел: запрашиваемые файлы > > сначала ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, > - > > проксируем на приложение. Но - перестали обрабатываться запросы вида > > http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со > > слэшем на конце) обрабатываются корректно. > > Оно то, в общем-то, и правильно: в документации сказано: > > > > Если location задан префиксной строкой со слэшом в конце и запросы > > > > > обрабатываются при помощи > > > proxy_pass< > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy > > > _pass> > , > > > fastcgi_pass< > http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#f > > > astcgi_pass> , > > > scgi_pass< > http://nginx.org/ru/docs/http/ngx_http_scgi_module.html#scgi_pa > > > ss> , > > > uwsgi_pass< > http://nginx.org/ru/docs/http/ngx_http_uwsgi_module.html#uwsgi > > > _pass>> > > > или > > > memcached_pass< > http://nginx.org/ru/docs/http/ngx_http_memcached_module.h > > > tml#memcached_pass>, > > > > > а в ответ на запрос с URI равным этой строке, но без завершающего > слэша, > > > будет возвращено постоянное перенаправление с кодом 301 на URI с > > > добавленным в конец слэшом. Если такое поведение нежелательно, можно > > > задать точное совпадение URI и location, например: > > > > > > > > > > > > location /user/ { > > > > > > proxy_pass http://user.example.com; > > > > > > } > > > > > > > > > > > > location = /user { > > > > > > proxy_pass http://login.example.com; > > > > > > } > > > > > > > > > > > > > > > Про try_files тут не сказано ни слова.) Но возник законный вопрос: а > как > > > > вернуть прежнее поведение? можно ли сделать это "красиво"? или придется > > городить магию с реврайтами? а если писать реврайты - куда их пихать.. в > > общем, как-то так. Как-то сходу не получилось самому ответить на эти > > вопросы, решил поделиться с сообществом. Буду признателен за любые > > предложения выхода из ситуации. > > > [...] > > Вся магия сводится к добавлению: > > location = /webapp { > return 301 /webapp/; > } > > -- > Валентин Бартенев > > > ---------- Пересылаемое сообщение ---------- > From: "Илья Шипицин" > To: "nginx-ru at nginx.org" > Cc: > Date: Thu, 9 Jan 2014 21:41:05 +0600 > Subject: Re: 301 redirect на URI без слэша на конце > мы вот так делаем > > > root /var/www/webapps/nginx-static; > > location /webapp/ { > try_files $uri $uri/ @application-handle; > } > > location @application-handle { > include my-site/proxy_pass_params.conf; > proxy_pass http://app_upstream; > } > > > 1) в try_files пишем $uri и $uri/ > 2) root-у нечего делать в location-е > 3) include лучше делать в самую первую очередь, чтобы переопределенные > параметры (если они будут) не перетерлись include-овыми > > > 9 января 2014 г., 20:55 пользователь Андрей Середенко > написал: > > Здравия, друзья! Всех с прошедшими праздниками! > > > > В процессе приведения конфигурации своих веб-серверов в более > лицеприятный > > столкнулся с таким моментом: автоматическое добавление слэша не > происходит > > после отрабатывания директивы try_files. Было неожиданно. Немного > примеров, > > чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и > > "после"): > > > > location /webapp/ { > > proxy_pass http://app_upstream; > > include my-site/proxy_pass_params.conf; > > } > > > > Подумалось, что правильнее отдавать статику силами nginx'а, а не > напрягать и > > без того кривое приложение:) В итоге, location принял следующий облик: > > > > location /webapp/ { > > root /var/www/webapps/nginx-static; > > try_files $uri @application-handle; > > } > > > > location @application-handle { > > proxy_pass http://app_upstream; > > include my-site/proxy_pass_params.conf; > > } > > > > В результате, в принципе, получил то, что хотел: запрашиваемые файлы > сначала > > ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, - > > проксируем на приложение. Но - перестали обрабатываться запросы вида > > http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со > > слэшем на конце) обрабатываются корректно. > > Оно то, в общем-то, и правильно: в документации сказано: > > > >> Если location задан префиксной строкой со слэшом в конце и запросы > >> обрабатываются при помощи proxy_pass, fastcgi_pass, scgi_pass, > uwsgi_pass > >> или memcached_pass, а в ответ на запрос с URI равным этой строке, но без > >> завершающего слэша, будет возвращено постоянное перенаправление с кодом > 301 > >> на URI с добавленным в конец слэшом. Если такое поведение нежелательно, > >> можно задать точное совпадение URI и location, например: > >> > >> location /user/ { > >> proxy_pass http://user.example.com; > >> } > >> > >> location = /user { > >> proxy_pass http://login.example.com; > >> } > >> > >> > > Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как > > вернуть прежнее поведение? можно ли сделать это "красиво"? или придется > > городить магию с реврайтами? а если писать реврайты - куда их пихать.. в > > общем, как-то так. Как-то сходу не получилось самому ответить на эти > > вопросы, решил поделиться с сообществом. Буду признателен за любые > > предложения выхода из ситуации. > > > > Немного информации, которая может быть полезной: > > > >> [ root at app1 ~]# nginx -V > >> nginx version: nginx/1.0.15 > >> built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) > >> TLS SNI support enabled > >> configure arguments: --prefix=/usr/share/nginx > --sbin-path=/usr/sbin/nginx > >> --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > >> --http-log-path=/var/log/nginx/access.log > >> --http-client-body-temp-path=/var/lib/nginx/tmp/client_body > >> --http-proxy-temp-path=/var/lib/nginx/tmp/proxy > >> --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi > >> --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi > >> --http-scgi-temp-path=/var/lib/nginx/tmp/scgi > --pid-path=/var/run/nginx.pid > >> --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx > >> --with-file-aio --with-ipv6 --with-http_ssl_module > --with-http_realip_module > >> --with-http_addition_module --with-http_xslt_module > >> --with-http_image_filter_module --with-http_geoip_module > >> --with-http_sub_module --with-http_dav_module --with-http_flv_module > >> --with-http_mp4_module --with-http_gzip_static_module > >> --with-http_random_index_module --with-http_secure_link_module > >> --with-http_degradation_module --with-http_stub_status_module > >> --with-http_perl_module --with-mail --with-mail_ssl_module > >> --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > >> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' > >> --with-ld-opt=-Wl,-E > >> > >> [ root at app1 ~]# lsb_release -a > >> LSB Version: > >> > :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch > >> Distributor ID: CentOS > >> Description: CentOS release 6.2 (Final) > >> Release: 6.2 > >> Codename: Final > >> > >> [ root at app1 ~]# uname -a > >> Linux app1 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST > 2012 > >> x86_64 x86_64 x86_64 GNU/Linux > > > > > > Содержимое my-site/proxy_pass_params.conf (роли наверняка не играет, но > для > > полноты картины - надо): > > > >> proxy_redirect off; > >> > >> proxy_set_header Host $host; > >> proxy_set_header Remote-Addr $remote_addr; > >> proxy_set_header X-Real-IP $remote_addr; > >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > >> proxy_set_header X-Public-Url http://$host$request_uri; > >> > >> client_max_body_size 40m; > >> client_body_buffer_size 128k; > >> > >> proxy_connect_timeout 90; > >> proxy_send_timeout 90; > >> proxy_read_timeout 2600; > >> > >> proxy_buffer_size 4k; > >> proxy_buffers 4 32k; > >> proxy_busy_buffers_size 64k; > >> proxy_temp_file_write_size 64k; > > > > > > awaiting.. > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > ---------- Пересылаемое сообщение ---------- > From: Ilya Pirogov > To: nginx-ru at nginx.org > Cc: > Date: Thu, 9 Jan 2014 19:43:42 +0400 > Subject: Re: Bug - 304 status - Cache-Control > 2014/1/8 S.A.N > >> > Кстати, похоже, что есть вариант еще проще, используя директиву >> > fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match >> > и выставляя в ответе заголовок X-Accel-Expires: 0 >> > если статус ответа backend`а будет 304. >> >> Да, у меня крутился в голове вариант, использовать куки для >> fastcgi_no_cache. >> > > А зачем использовать куку? Почему нельзя просто прописать: > > fastcgi_no_cache $upstream_http_etag; > fastcgi_cache_bypass $http_if_none_match; > > Ведь для public кеша, насколько я понял, ETag не отдается. > > > ---------- Пересылаемое сообщение ---------- > From: "Михаил Монашёв" > To: nginx-ru at nginx.org > Cc: > Date: Thu, 9 Jan 2014 21:28:49 +0400 > Subject: Slowloris attack > Здравствуйте. > > Хотел спросить, а как с Slowloris attack справляется nginx? Он просто > тупо держит все соединения и старается при этом выделять минимум > памяти? Или ещё что-то делается? > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > > > > ---------- Пересылаемое сообщение ---------- > From: "S.A.N" > To: nginx-ru at nginx.org > Cc: > Date: Thu, 09 Jan 2014 13:15:34 -0500 > Subject: Re: Bug - 304 status - Cache-Control > > А зачем использовать куку? Почему нельзя просто прописать: > > > > fastcgi_no_cache $upstream_http_etag; > > fastcgi_cache_bypass $http_if_none_match; > > > > Ведь для public кеша, насколько я понял, ETag не отдается. > > Для public кеш, ETag отдается. > Это сделано на перспективу, в будущем Nginx будет поддерживать ревалидацию > своего кеша по If-None-Match (ETag) > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245951,246192#msg-246192 > > > > > ---------- Пересылаемое сообщение ---------- > From: Sergey Smitienko > To: nginx-ru at nginx.org > Cc: > Date: Thu, 09 Jan 2014 20:35:13 +0200 > Subject: Re: Slowloris attack > > Здравствуйте. > > Поставьте маленький client_header_timeout, client_body_timeout и лимит на > число > подключений с одного IP. > > Теоретически частично во FreeBSD может помочь httpready accept filter, но > сам не пробовал. > > В последний раз у меня было открыто порядка 30K подключений, особо жить не > мешало. > А дальше по логу строился firewall и весь ботнет посылается в /dev/null. > > Кстати, была бы интересна возможность повесить свой perl обработчик на > различные ошибки, > чтобы банить IP прямо из nginx'a ??? > > > 1/9/14 7:28 PM, Михаил Монашёв пишет: > > Здравствуйте. > > Хотел спросить, а как с Slowloris attack справляется nginx? Он просто > тупо держит все соединения и старается при этом выделять минимум > памяти? Или ещё что-то делается? > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Thu Jan 9 21:15:12 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 09 Jan 2014 23:15:12 +0200 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: References: <52CEEF57.3070400@csdoc.com> Message-ID: <52CF1160.7050502@csdoc.com> On 09.01.2014 21:16, S.A.N wrote: >> Чем такой простой и удобный вариант Вам не подходит, я не понимаю. > Дело в том что я ленивый перфекционист, не люблю писать лишний код :) если "отдавать куку с path=$self_path" - ее не будет в первом запросе от клиента и поэтому ответ backend`а на такой запрос уйдет в кеш nginx. кроме того, в браузерах есть лимиты по количетву cookies: If you want to support most browsers, then do not exceed 50 cookies per domain, and 4093 bytes per domain. That is, the size of all cookies should not exceed 4093 bytes. > X-Accel-Expires рабочий вариант и он подходит, просто я не уверен что это > идеал вариант, по этому не спешу реализовывать такие идеи, пока не найду > идею код которой будет приближается к нулю строчек кода :) 0 строчек кода - это невозможно. > Потому что бекенд все делает правильно > и не хочется добавлять в него костыли > для решения проблем с Nginx. у nginx нет проблем, это backend кривой и его надо фиксить. > Но вам спасибо за качественные идеи, думаю что данную тему можно закрывать. nginx-ru - это не форум, а список: http://nginx.org/ru/support.html кстати, читать его через почтовый клиент гораздо удобнее. -- Best regards, Gena From gmm at csdoc.com Thu Jan 9 22:57:16 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2014 00:57:16 +0200 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: References: <52CEAABF.6030504@csdoc.com> Message-ID: <52CF294C.2050501@csdoc.com> On 09.01.2014 21:03, S.A.N wrote: > Вот наглядный пример: > fastcgi_param HTTP_HOST1 $http_host; > fastcgi_param HTTP_HOST2 $host; > fastcgi_param HTTP_HOST3 $server_name; > > Делаем, запрос > GET http://site3.dev/ HTTP/1.1 > Host:~%#$^&*()<>?@\!."'{}[]=+| > > На выходе получим > _SERVER["HTTP_HOST1"]: ~%#$^&*()<>?@\!."'{}[]=+| > _SERVER["HTTP_HOST2"]: site3.dev > _SERVER["HTTP_HOST3"]: site2.dev > > Кому интересно почитать, подробней вот ссылка. > http://habrahabr.ru/post/166855/ > > Как видите, корректное значения имеют только переменные $host и > $server_name, все что основывается на $http_host имеет потенциал уязвимость, > если бекенд доверяет этой переменой, лично я знаю несколько популярных РНР > фрейморков которые используют эту переменную без проверки и без > экранирования в SQL запросах. и пофиксить эту проблему можно в исходниках nginx таким образом, что если вдруг в переменных $host и $http_host оказываются разные значения, чтобы nginx в $http_host записывал значение из $host. тогда после установки следующего обновления nginx эта уязвимость в backend`ах автоматически пофиксится у всех пользователей nginx. причем без какой-либо необходимости пользователям править файлы fastcgi.conf / fastcgi_params и все производные от них. -- Best regards, Gena From nginx-forum at nginx.us Fri Jan 10 04:57:05 2014 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 09 Jan 2014 23:57:05 -0500 Subject: =?UTF-8?Q?Re=3A_Bug_=E2=80=93_304_status_-_Cache-Control?= In-Reply-To: <52CF1160.7050502@csdoc.com> References: <52CF1160.7050502@csdoc.com> Message-ID: <07834054cdedef17acd066e57571e444.NginxMailingListRussian@forum.nginx.org> > 0 строчек кода - это невозможно. Все возможно, я выше писал, как я решил эту проблему. В конфиге по прежнему для работы с клиент кешем, установлена передача все нужных заголовком. fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; Чтобы не было проблем с кешированием 304 статуса, мы решили не отдавать хедер Cache-Control, таким образом Nginx не будет сохранять данный ответ в своем кеше, потому как в конфиге прописано fastcgi_cache_valid 200 301 302 0s Как видите, строк кода даже уменьшилось, теперь бекенд отдает ещё меньше хедеров в 304 статусе. По тестам все современные браузеры, нормально реагируют на отсутствия заголовков Cache-Control в ответе с 304 статусом, хотя спецификации HTTP требует наличия этого заголовка. Вопрос к сообществу, какие проблемы могут возникнуть, если в 304 статусе не будет заголовка Cache-Control? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246218#msg-246218 From gmm at csdoc.com Fri Jan 10 09:54:22 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2014 11:54:22 +0200 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <20140109143325.GJ1835@mdounin.ru> References: <52CBE171.9070000@csdoc.com> <20140109121031.GC1835@mdounin.ru> <52CEAABF.6030504@csdoc.com> <20140109143325.GJ1835@mdounin.ru> Message-ID: <52CFC34E.10508@csdoc.com> On 09.01.2014 16:33, Maxim Dounin wrote: >>> Смысл значения по умолчанию для proxy_cache_key состоит в том, что >>> идентифицируется тот ресурс, куда осуществялется проксирование. >> >>> Тем самым, если в разных виртуальных серверах проксирование >>> осуществляется в одно и то же место - будет использован >>> один и тот же элемент кеша. Ситуация, когда все размещенные на одном сервере виртуальные хосты имеют 100% идентичный контент и разные домены практически невозможна. Такая настройка nginx сейчас может появиться только в результате ошибки. Еще дефолтовая настройка nginx на $proxy_host может быть полезной тем, кто "грабит корованы", то есть показыват на своем сайте контент, который был получен с других сайтов путем проксирования с кешированием. Остальным же 99.999% пользователей nginx будет удобно, если дефолтовым значением сделать proxy_set_header Host $host; ибо с другими вариантами настройки nginx просто не будет нормально работать с virtual хостами. Насколько я понимаю суть и смысл default значения настройки - это значение следует выбирать таким, чтобы оно было удобным максимально большему числу пользователей nginx. Нет разве ? По крайней мере, раньше дефолтовым значением server_name было $hostname; вплоть до версии 0.8.48, а сейчас уже "". Смысла оставлять дефолт $proxy_host после этого почти нет. >> возможно имеет смысл дефолтовые настройки сделать такими, >> чтобы они были безопасными по-умолчанию для всех пользователей? >> т.е. $host вместо $proxy_host ? > В запросах на бекенд по умолчанию в заголовке Host > передаётся именно $proxy_host, и значение proxy_cache_key > соответсвует тому, что происходит по умолчанию. > Т.е. по умолчанию - всё безопасно. Если поменять одну настройку и забыть поменять другую, тогда все ломается и перестает нормально работать. Для протокола FastCGI пример из документации сейчас является "broken by default", потому что в переменной HTTP_HOST на бекенд уходит значение $http_host из запроса, а в fastcgi_cache_key рекомендуется localhost:9000$request_uri; Два варианта: 1. По дефолту стоит $proxy_host и рекомендуется localhost:9000 В худшем случае - контент с разных сайтов перемешивается в выдаче, пользователи сайтов в шоке, администраторы nginx, которые включили кеш - тоже. В результате портится рейтинг сайтов в выдаче поисковых систем. И как результат этого - портится рейтинг nginx среди пользователей. Разве надо это кому-то? 2. По дефолту $scheme$host$request_uri; - В худшем случае, если пользователь криво настроил nginx, так что один и тот же контент отображается на разных доменных именах, например, www.example.com и example.com - будет просто не оптимальная настройка nginx, когда будет использоваться в два раза больше диска/памяти для дублирования ключей/значений кеша nginx, без каких-либо деструктивных последствий для сайтов и пользователей. Сейчас - по дефолту выбран и рекомендуется в примерах вариант 1. Чтобы сделать nginx "Secure by default" предлагаю реализовать вариант 2. Почему "нет" ? > Если же говорить о том, что может быть достугнуто с помощью > худождественного выпиливания по конфигу без понимания > происходящего - то вывод "Мы все умрём" никто не отменял. По-умолчанию у пользователей nginx высокий уровень доверия к советам и рекомендациям разработчиков nginx, и если вдруг они (пользователи) не совсем понимают как работает та или иная директива, то оставляют директиву в дефолтовом значении, или же настраивают так, как рекомендуется настраивать в примерах из документации nginx. Если же эти "ловушки" там были разложены специально, чтобы пользователи в них попадали и "учились" на своих ошибках - то это совсем не способствует популярности nginx, так делать не надо. Например, если смотреть January 2014 Web Server Survey, то видно что доля nginx уменьшилась и в Market share of all sites и в Market share of active sites, при этом растут Apache и Microsoft. Доля nginx выросла в Market share of the top million busiest sites, но там практически всегда тонкая настройка и хорошее понимание того, как работает nginx, возможно даже коммерческие контракты на поддержку, они от дефолтовых значений тех или иных директив nginx почти не зависят. Побочный эффект "опасных" дефолтовых значений директив nginx еще и в том, что один раз получив глюки в работе nginx используя дефолтовое/рекомендуемое в примере значение той или иной директивы - они начинают вручную в конфиге выписывать значения всех директив, меняя их по своему усмотрению и больше не доверяя дефолтовым значениям. Я например, уже неоднократно видет такие конфиги в этом списке рассылки. >> кстати, аналогичный вопрос касается и дефолтового значнеия proxy_set_header >> - http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header >> >> syntax: proxy_set_header field value; >> default: proxy_set_header Host $proxy_host; >> proxy_set_header Connection close; >> >> хотя ниже идет рекомендация делать proxy_set_header Host $host; >> почему бы не сделать $host значением по-умолчанию? > > Ниже говорится о том, что если хочется передать на бекенд значение > Host'а из запроса, то этом можно сделать с помощью $http_host, но > лучше - с помощью $host (и объясняется, почему). У 99.999% пользователей nginx вот именно такое желание и есть, "передать на бекенд $host в заголовке Host" через proxy/fastcgi. Сейчас - на backend уходит $proxy_host и $http_host соответственно вместо желаемого и ожидаемого клиентами значения $host "Secure by default" - это ведь совсем не сложно. Тем более, что nginx включили в состав OpenBSD. -- Best regards, Gena From vbart at nginx.com Fri Jan 10 10:24:47 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Jan 2014 14:24:47 +0400 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <52CF294C.2050501@csdoc.com> References: <52CEAABF.6030504@csdoc.com> <52CF294C.2050501@csdoc.com> Message-ID: <3218886.BekFLRDj5N@vbart-laptop> On Friday 10 January 2014 00:57:16 Gena Makhomed wrote: > On 09.01.2014 21:03, S.A.N wrote: > > Вот наглядный пример: > > fastcgi_param HTTP_HOST1 $http_host; > > fastcgi_param HTTP_HOST2 $host; > > fastcgi_param HTTP_HOST3 $server_name; > > > > Делаем, запрос > > GET http://site3.dev/ HTTP/1.1 > > Host:~%#$^&*()<>?@\!."'{}[]=+| > > > > На выходе получим > > _SERVER["HTTP_HOST1"]: ~%#$^&*()<>?@\!."'{}[]=+| > > _SERVER["HTTP_HOST2"]: site3.dev > > _SERVER["HTTP_HOST3"]: site2.dev > > > > Кому интересно почитать, подробней вот ссылка. > > http://habrahabr.ru/post/166855/ > > > > Как видите, корректное значения имеют только переменные $host и > > $server_name, все что основывается на $http_host имеет потенциал > > уязвимость, если бекенд доверяет этой переменой, лично я знаю несколько > > популярных РНР фрейморков которые используют эту переменную без проверки > > и без > > экранирования в SQL запросах. > > и пофиксить эту проблему можно в исходниках nginx таким образом, > что если вдруг в переменных $host и $http_host оказываются разные > значения, чтобы nginx в $http_host записывал значение из $host. > > тогда после установки следующего обновления nginx эта уязвимость > в backend`ах автоматически пофиксится у всех пользователей nginx. > > причем без какой-либо необходимости пользователям править > файлы fastcgi.conf / fastcgi_params и все производные от них. Так, между делом, хочу напомнить, что на CGI есть спецификация, описывающая все переменные окружения, которые сервер должен передавать приложению. И в ней вполне черным по белому сказано, что все переменные HTTP_* это protocol specific переменные полученные из заголовков переданных клиентом. И есть безопасная и специфицированная переменная SERVER_NAME. Если кто-то в приложении использует данные полученные от клиента без надлежащей проверки, когда в любой книжке "web-programming for dummies" написано по 5 раз, что не следует доверять этим данным, то что я могу предложить? Расстрел. -- Валентин Бартенев From gmm at csdoc.com Fri Jan 10 11:45:27 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2014 13:45:27 +0200 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <3218886.BekFLRDj5N@vbart-laptop> References: <52CEAABF.6030504@csdoc.com> <52CF294C.2050501@csdoc.com> <3218886.BekFLRDj5N@vbart-laptop> Message-ID: <52CFDD57.5040502@csdoc.com> On 10.01.2014 12:24, Валентин Бартенев wrote: >>> Кому интересно почитать, подробней вот ссылка. >>> http://habrahabr.ru/post/166855/ >>> >>> Как видите, корректное значения имеют только переменные $host и >>> $server_name, все что основывается на $http_host имеет потенциал >>> уязвимость, если бекенд доверяет этой переменой, лично я знаю несколько >>> популярных РНР фрейморков которые используют эту переменную без проверки >>> и без экранирования в SQL запросах. >> и пофиксить эту проблему можно в исходниках nginx таким образом, >> что если вдруг в переменных $host и $http_host оказываются разные >> значения, чтобы nginx в $http_host записывал значение из $host. >> >> тогда после установки следующего обновления nginx эта уязвимость >> в backend`ах автоматически пофиксится у всех пользователей nginx. >> >> причем без какой-либо необходимости пользователям править >> файлы fastcgi.conf / fastcgi_params и все производные от них. > Так, между делом, хочу напомнить, что на CGI есть спецификация, описывающая > все переменные окружения, которые сервер должен передавать приложению. > И в ней вполне черным по белому сказано, что все переменные HTTP_* это > protocol specific переменные полученные из заголовков переданных клиентом. fastcgi_param HTTP_HOST1 $http_host; fastcgi_param HTTP_HOST2 $host; fastcgi_param HTTP_HOST3 $server_name; Делаем запрос: GET http://site3.dev/phpinfo.php HTTP/1.1 Host:~%#$^&*()<>?@\!."'{}[]=+| На выходе получим _SERVER["HTTP_HOST1"]: ~%#$^&*()<>?@\!."'{}[]=+| _SERVER["HTTP_HOST2"]: site3.dev _SERVER["HTTP_HOST3"]: site2.dev В переменной $host правильное значение, в переменной $http_host все что угодно. А ведь именно на основании значения переменной $host nginx и принимает решение в какой server направить запрос на обработку. Но к FastCGI уходит не $host, с которым работал nginx принимая решение, а fake-значение из $http_host Они то protocol specific, но раз запрос клиента попал в server где в server_name прописано site3.dev - клиент искренне полагает, что надлежащую проверку уже провел nginx, ведь в конфиге пользователь прописал: server { listen 80 default_server; return 444; } B значит все другие значения HTTP_HOST, которые не соответствуют нормальным значениям server_name должны попадать в этот server-заглушку. Поэтому валидировать еще раз то, что и так уже провалидировал nginx никакого смысла нет. С точки зрения обычных пользователей, коих 99.999%. Я и сам так считал до недавнего времени, доверяя документации nginx: http://nginx.org/en/docs/http/request_processing.html http://nginx.org/en/docs/http/server_names.html http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name > И есть безопасная и специфицированная переменная SERVER_NAME. она есть такая только для FastCGI, а для proxy_pass на апач - все не так просто, если погуглить server_name http_host site:bugs.php.net тем более, что в SERVER_NAME со стороны веб-сервера будет приезжать каноническое имя сервера, а это обычно hostname. и для всех виртуальных хостов будет одинаковое значение SERVER_NAME. путаницы с этим хватает: https://stackoverflow.com/questions/1459739/ Поэтому те кто пишут на php не могут доверять значению SERVER_NAME, и у них остается единственный вариант - только переменная HTTP_HOST. > Если кто-то в приложении использует данные полученные от клиента без > надлежащей проверки, когда в любой книжке "web-programming for dummies" > написано по 5 раз, что не следует доверять этим данным, то что я могу > предложить? Расстрел. Они проверяют и валидируют значение HTTP_HOST средствами nginx, так как это прописано в документации к nginx, и рекомендовано разработчиками nginx. Зачем два раза проверять одно и то же? Как будто мало разработчикам проблем с самим php и его глюками, например, cgi.fix_pathinfo 1 по умолчанию: http://habrahabr.ru/post/100961/#comment_3125990 Так теперь еще и с nginx при использовании php-fpm эти глюки. А ведь php-fpm это наверное основной уже способ как использовать php и nginx. Попробую иначе спросить: что может поломать предложенный мной выше fix, который будет закрывать эту уязвимость в backend`ах, которые доверяют значению переменной HTTP_HOST полученной от nginx? "Самый эффективный способ защиты ? явно определить HTTP_HOST на стороне веб сервера." - цитата из статьи http://habrahabr.ru/post/166855/ Сейчас же nginx по-умолчанию отправляет на backend значения $proxy_host и $http_host вместо ожидаемого там $host. Если глюк с $proxy_host очевиден, то глюк с $http_host совсем нет. Способы решения проблемы: 1. Расстрелять всех, кто пишет кривой код. - Нереально. 2. Исправить все глюки и весь кривой код. - Нереально. 3. Всем вручную добавить fix в fastcgi_param HTTP_HOST $host; 4. Добавить этот fix в дефолтовые конфиги nginx. 5. Исправить это один раз в коде nginx и забыть про проблему. Способ ?5 самый простой в реализации и 100% эффективный метод защиты. Почему "нет" ? P.S. Например, вот сколько "магии" наворотили в модуле кеширования, и незаметное (недокументированное) трансформирование HEAD в GET, и незаметное (недокументированное) вырезание заголовков If-Modified-Since и If-None-Match и выключение кеширования, если в ответе присутствует заголовко Set-Cookie и т.д. и т.п. А такую мелочь с передачей на backend валидного значения $host, которая никому не будет мешать и только принесет max. пользу... -- Best regards, Gena From gmm at csdoc.com Fri Jan 10 12:06:43 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2014 14:06:43 +0200 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <52CFDD57.5040502@csdoc.com> References: <52CEAABF.6030504@csdoc.com> <52CF294C.2050501@csdoc.com> <3218886.BekFLRDj5N@vbart-laptop> <52CFDD57.5040502@csdoc.com> Message-ID: <52CFE253.8020801@csdoc.com> On 10.01.2014 13:45, Gena Makhomed wrote: >>>> Кому интересно почитать, подробней вот ссылка. >>>> http://habrahabr.ru/post/166855/ Хотя, есть и более простой вариант, как на стороне nginx закрыть эту уязвимость с $http_host. $host in this order of precedence: host name from the request line, or host name from the ?Host? request header field, or the server name matching a request Eсли в request line оказывается одно значение $host, а в ?Host? request header field оказывается другое значение, тогда просто возвращать 400 Bad Request, поскольку от нормального клиента (браузера и т.п.) такой запрос никакогда придти не может. Это формально правильный способ, но менее удобный для разработчиков, потому что вполне может быть такой вариант, что это default server и запрос придет вообще без заголовка Host: - тогда в HTTP_HOST будет пусто и backend скорее всего нормально не отработает. Поэтому мне больше нравится вариант в случае несоответствия значений переменных $host и $http_host - в $http_host писать значение $host. Тем более, что в случае запроса по ип-адресу тогда в HTTP_HOST на backend уйдет значение из $server_name. И любой современный код отработает на такой запрос нормально. Это максимально надежный и максимально безглючный вариант. А если backend - apache, в его SERVER_NAME может быть другое значение, отличное от правильного значения $server_name из nginx. И тут будут аналогичные проблемы, что и сейчас с $host и $http_host. P.S. Или сделать это поведение конфигурируемым, возвращать 400 ошибку, или писать в $http_host значение из $host. По дефолту может быть например, перезапись $http_host значением из $host, кому это не подходит - могут настроить возврат 400 ошибки или даже полностью выключить какую-либо реакцию на эти попытки взлома веб-сервера и пропускать их as is на backend, пусть он попробует защититься. Есть такое мнение, что это вообще идеальный вариант решения проблемы. Не могу даже придумать кому и почему может не понравиться такой вариант. -- Best regards, Gena From vbart at nginx.com Fri Jan 10 12:53:26 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Jan 2014 16:53:26 +0400 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <52CFDD57.5040502@csdoc.com> References: <52CEAABF.6030504@csdoc.com> <3218886.BekFLRDj5N@vbart-laptop> <52CFDD57.5040502@csdoc.com> Message-ID: <2258243.kZVRnG2y6t@vbart-laptop> On Friday 10 January 2014 13:45:27 Gena Makhomed wrote: > On 10.01.2014 12:24, Валентин Бартенев wrote: > >>> Кому интересно почитать, подробней вот ссылка. > >>> http://habrahabr.ru/post/166855/ > >>> > >>> Как видите, корректное значения имеют только переменные $host и > >>> $server_name, все что основывается на $http_host имеет потенциал > >>> уязвимость, если бекенд доверяет этой переменой, лично я знаю несколько > >>> популярных РНР фрейморков которые используют эту переменную без проверки > >>> и без экранирования в SQL запросах. > >> > >> и пофиксить эту проблему можно в исходниках nginx таким образом, > >> что если вдруг в переменных $host и $http_host оказываются разные > >> значения, чтобы nginx в $http_host записывал значение из $host. > >> > >> тогда после установки следующего обновления nginx эта уязвимость > >> в backend`ах автоматически пофиксится у всех пользователей nginx. > >> > >> причем без какой-либо необходимости пользователям править > >> файлы fastcgi.conf / fastcgi_params и все производные от них. > > > > Так, между делом, хочу напомнить, что на CGI есть спецификация, > > описывающая > > все переменные окружения, которые сервер должен передавать приложению. > > И в ней вполне черным по белому сказано, что все переменные HTTP_* это > > protocol specific переменные полученные из заголовков переданных клиентом. > > fastcgi_param HTTP_HOST1 $http_host; > fastcgi_param HTTP_HOST2 $host; > fastcgi_param HTTP_HOST3 $server_name; > > Делаем запрос: > GET http://site3.dev/phpinfo.php HTTP/1.1 > Host:~%#$^&*()<>?@\!."'{}[]=+| > > На выходе получим > _SERVER["HTTP_HOST1"]: ~%#$^&*()<>?@\!."'{}[]=+| > _SERVER["HTTP_HOST2"]: site3.dev > _SERVER["HTTP_HOST3"]: site2.dev > > В переменной $host правильное значение, > в переменной $http_host все что угодно. Что значит "правильное"? С точки зрения спецификации, правильное значение HTTP_HOST1 - это значение из заголовка Host1 (с учетом оговоренных преобразований) и никак иначе не надо трактовать переменные HTTP_* они имеют вполне специфическое назначение - а именно получить raw-данные из запроса. И если обратить внимание, то в конфигурации вообще нигде не указывается fastcgi_param HTTP_HOST $http_host; nginx, как и положено, автоматически преобразует заголовки в HTTP_* переменные. Если заголовка Host в запросе вообще не будет, то и переменной HTTP_HOST быть также не должно. > А ведь именно на основании значения переменной $host > nginx и принимает решение в какой server направить запрос > на обработку. Но к FastCGI уходит не $host, с которым > работал nginx принимая решение, а fake-значение из $http_host Если мы говорим про переменную HTTP_HOST, так и должно быть. > Они то protocol specific, но раз запрос клиента попал в server > где в server_name прописано site3.dev - клиент искренне полагает, Клиент? > что надлежащую проверку уже провел nginx, ведь в конфиге пользователь > прописал: > > server { > listen 80 default_server; > return 444; > } > > B значит все другие значения HTTP_HOST, которые не соответствуют > нормальным значениям server_name должны попадать в этот server-заглушку. Значит из чего? Из того, что кто-то так полагает? Неправильно полагает. > Поэтому валидировать еще раз то, что и так уже провалидировал nginx > никакого смысла нет. С точки зрения обычных пользователей, коих 99.999%. Обычных пользователей? Может быть, но приложения пишут, минуточку, не обычные пользователи, а программисты, что предполагает наличие каких-то профессиональных навыков, нет? Если программист использует какую-то переменную не понимая её назначения, то едва ли ему можно чем-то помочь, проблемы у него возникнут не только с HTTP_HOST, а и в 1000 других мест. > Я и сам так считал до недавнего времени, доверяя документации nginx: > > http://nginx.org/en/docs/http/request_processing.html > > http://nginx.org/en/docs/http/server_names.html > > http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name Где в документации что-то написано о: > B значит все другие значения HTTP_HOST, которые не соответствуют > нормальным значениям server_name должны попадать в этот server-заглушку ? > > > И есть безопасная и специфицированная переменная SERVER_NAME. > > она есть такая только для FastCGI, Она есть такая во всех CGI-подобных протоколах. > а для proxy_pass на апач - все не так просто, если погуглить > server_name http_host site:bugs.php.net Поэтому умолчания для proxy_* и fastcgi_* отличаются. > тем более, что в SERVER_NAME со стороны веб-сервера > будет приезжать каноническое имя сервера, а это обычно hostname. > и для всех виртуальных хостов будет одинаковое значение SERVER_NAME. Виртуальный хост с точки зрения конфигурации nginx - это одна секция блока server. Если пользователь руководствуется другой идеологией, то должен соответствующим образом исправить конфигурацию. > путаницы с этим хватает: https://stackoverflow.com/questions/1459739/ > > Поэтому те кто пишут на php не могут доверять значению SERVER_NAME, > и у них остается единственный вариант - только переменная HTTP_HOST. И если они используют переменную HTTP_HOST, то они её должны соответствующим образом проверять. Почему те, кто пишут на других языках, это понимают, а "те кто пишут на php" - это такая особая категория, им нужно особое снисхождение и сочувствие? > > Если кто-то в приложении использует данные полученные от клиента без > > надлежащей проверки, когда в любой книжке "web-programming for dummies" > > написано по 5 раз, что не следует доверять этим данным, то что я могу > > предложить? Расстрел. > > Они проверяют и валидируют значение HTTP_HOST средствами nginx, > так как это прописано в документации к nginx, и рекомендовано > разработчиками nginx. Зачем два раза проверять одно и то же? Где? Цитату из документации, где прописано, что HTTP_HOST валидируется? > Как будто мало разработчикам проблем с самим php > и его глюками, например, cgi.fix_pathinfo 1 по умолчанию: > http://habrahabr.ru/post/100961/#comment_3125990 > > Так теперь еще и с nginx при использовании php-fpm > эти глюки. А ведь php-fpm это наверное основной уже > способ как использовать php и nginx. Следование спецификации это сейчас глюком называется? Чем в этом отношении отличается любой другой сервер? Вы хотите сказать, что в случае того же mod_fastcgi в HTTP_HOST будет что-то другое? Даже в документации по PHP написано: http://www.php.net/manual/en/reserved.variables.server.php 'HTTP_HOST' Contents of the Host: header from the current request, if there is one. Где тут что-то про валидацию сервером? > Попробую иначе спросить: что может поломать предложенный > мной выше fix, который будет закрывать эту уязвимость в backend`ах, > которые доверяют значению переменной HTTP_HOST полученной от nginx? Все нормальные приложения, которые рассчитывают получить в HTTP_HOST сырое значение из заголовка и далее использовать его соответствующим образом. Допустим ваше приложение занимается выявлением распространенных атак и превентивно блокирует злоумышленников. Или задача вашего приложения выводить или логгировать заголовки клиента. Пример одного из самых распространенных приложений: phpinfo.php - начинает отображать _неверное_ значение HTTP_HOST. > "Самый эффективный способ защиты ? явно определить HTTP_HOST на стороне > веб сервера." - цитата из статьи http://habrahabr.ru/post/166855/ Защиты от чего? От кривых рук и дилетантов защиты не существует в принципе. > Сейчас же nginx по-умолчанию отправляет на backend > значения $proxy_host и $http_host вместо ожидаемого там $host. > > Если глюк с $proxy_host очевиден, то глюк с $http_host совсем нет. > > Способы решения проблемы: > > 1. Расстрелять всех, кто пишет кривой код. - Нереально. > > 2. Исправить все глюки и весь кривой код. - Нереально. > > 3. Всем вручную добавить fix в fastcgi_param HTTP_HOST $host; > > 4. Добавить этот fix в дефолтовые конфиги nginx. > > 5. Исправить это один раз в коде nginx и забыть про проблему. И создать другую, на мой взгляд ещё большую проблему на века. Оригинальная проблема не исправляется "фиксом" в конфигурацию. Ибо оригинальная проблема, как было выше указано - кривой код, который сломается сразу в другой конфигурации и/или на другом сервере. Предлагать исправить переменную HTTP_HOST, это то же самое, что предлагать сразу исправить переменную $http_host на основании того, что кто-то там что-то полагает. Да, кстати, а почему действительно предложение исправить HTTP_HOST, а не $http_host? Уверен, найдется не одна конфигурация, где люди используют значение $http_host в директиве alias например. Может и их нужно защитить? Чем они хуже особой категории "те кто пишут на php"? -- Валентин Бартенев From sakutylev at mitht.ru Fri Jan 10 13:05:49 2014 From: sakutylev at mitht.ru (=?UTF-8?B?0JrRg9GC0YvQu9C10LIsINCh0LXRgNCz0LXQuQ==?=) Date: Fri, 10 Jan 2014 17:05:49 +0400 Subject: iplist+s/mime Message-ID: Можно ли как-то реализовать данную схему в nginx? if iplist allow ifelse s/mime allow else deny 403 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Fri Jan 10 13:07:57 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Jan 2014 17:07:57 +0400 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <52CFE253.8020801@csdoc.com> References: <52CEAABF.6030504@csdoc.com> <52CFDD57.5040502@csdoc.com> <52CFE253.8020801@csdoc.com> Message-ID: <2310697.ov1uODaMRR@vbart-laptop> On Friday 10 January 2014 14:06:43 Gena Makhomed wrote: > On 10.01.2014 13:45, Gena Makhomed wrote: > >>>> Кому интересно почитать, подробней вот ссылка. > >>>> http://habrahabr.ru/post/166855/ > > Хотя, есть и более простой вариант, > как на стороне nginx закрыть эту уязвимость с $http_host. > > $host > in this order of precedence: host name from the request line, or host > name from the ?Host? request header field, or the server name matching a > request > > Eсли в request line оказывается одно значение $host, > а в ?Host? request header field оказывается другое значение, > тогда просто возвращать 400 Bad Request, поскольку от нормального > клиента (браузера и т.п.) такой запрос никакогда придти не может. > > Это формально правильный способ, но менее удобный для разработчиков, > потому что вполне может быть такой вариант, что это default server > и запрос придет вообще без заголовка Host: - тогда в HTTP_HOST > будет пусто и backend скорее всего нормально не отработает. [..] Единственный правильный способ: пойти в IETF с предложением исправить соответствующие RFC, которые в том числе оговаривают, что следует делать при получении нескольких заголовков Host, ну а потом уже сюда. -- Валентин Бартенев From mdounin at mdounin.ru Fri Jan 10 15:42:18 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 10 Jan 2014 19:42:18 +0400 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <52CFC34E.10508@csdoc.com> References: <52CBE171.9070000@csdoc.com> <20140109121031.GC1835@mdounin.ru> <52CEAABF.6030504@csdoc.com> <20140109143325.GJ1835@mdounin.ru> <52CFC34E.10508@csdoc.com> Message-ID: <20140110154218.GQ1835@mdounin.ru> Hello! On Fri, Jan 10, 2014 at 11:54:22AM +0200, Gena Makhomed wrote: > On 09.01.2014 16:33, Maxim Dounin wrote: > > >>>Смысл значения по умолчанию для proxy_cache_key состоит в том, что > >>>идентифицируется тот ресурс, куда осуществялется проксирование. > >> > >>>Тем самым, если в разных виртуальных серверах проксирование > >>>осуществляется в одно и то же место - будет использован > >>>один и тот же элемент кеша. > > Ситуация, когда все размещенные на одном сервере виртуальные хосты > имеют 100% идентичный контент и разные домены практически невозможна. > Такая настройка nginx сейчас может появиться только в результате ошибки. > > Еще дефолтовая настройка nginx на $proxy_host может быть полезной > тем, кто "грабит корованы", то есть показыват на своем сайте контент, > который был получен с других сайтов путем проксирования с кешированием. Например, это может быть отдельный location под общие элементы и/или ssi-инклуды. Именно под такие задачи оно исходно и программировалось, и именно потому и стоят такие значения по умолчанию - запрашиваем с бекенда то, что указано в proxy_pass, и кешируем то, что запрашивали. Просто следует понимать, что задач - больше одной. И хорошее решение для одной задачи - может оказаться плохим для другой. Проблема, на самом деле, в том, что прописанное в конфиге "proxy_set_header Host $host" существенно меняет суть запроса к бекенду, а значение по умолчанию proxy_cache_key об этом изменении не знает, его надо обучать этому вручную. Возможно, именно с этой стороны и следует подойти к этому вопросу. [...] -- Maxim Dounin http://nginx.org/ From vbart at nginx.com Fri Jan 10 17:57:21 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Jan 2014 21:57:21 +0400 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <20140110154218.GQ1835@mdounin.ru> References: <52CBE171.9070000@csdoc.com> <52CFC34E.10508@csdoc.com> <20140110154218.GQ1835@mdounin.ru> Message-ID: <1705428.JC99OxMjHr@vbart-laptop> On Friday 10 January 2014 19:42:18 Maxim Dounin wrote: > Hello! > > On Fri, Jan 10, 2014 at 11:54:22AM +0200, Gena Makhomed wrote: > > > On 09.01.2014 16:33, Maxim Dounin wrote: > > > > >>>Смысл значения по умолчанию для proxy_cache_key состоит в том, что > > >>>идентифицируется тот ресурс, куда осуществялется проксирование. > > >> > > >>>Тем самым, если в разных виртуальных серверах проксирование > > >>>осуществляется в одно и то же место - будет использован > > >>>один и тот же элемент кеша. > > > > Ситуация, когда все размещенные на одном сервере виртуальные хосты > > имеют 100% идентичный контент и разные домены практически невозможна. > > Такая настройка nginx сейчас может появиться только в результате ошибки. > > > > Еще дефолтовая настройка nginx на $proxy_host может быть полезной > > тем, кто "грабит корованы", то есть показыват на своем сайте контент, > > который был получен с других сайтов путем проксирования с кешированием. > > Например, это может быть отдельный location под общие элементы > и/или ssi-инклуды. Именно под такие задачи оно исходно и > программировалось, и именно потому и стоят такие значения по > умолчанию - запрашиваем с бекенда то, что указано в proxy_pass, и > кешируем то, что запрашивали. > > Просто следует понимать, что задач - больше одной. И хорошее > решение для одной задачи - может оказаться плохим для другой. > > Проблема, на самом деле, в том, что прописанное в конфиге > "proxy_set_header Host $host" существенно меняет суть запроса к > бекенду, а значение по умолчанию proxy_cache_key об этом изменении > не знает, его надо обучать этому вручную. Возможно, именно с этой > стороны и следует подойти к этому вопросу. > [..] Лично мне нравится идея привести значение proxy_cache_key по умолчанию к таковому fastcgi_cache_key, т.е. отсутствует и требуется задавать явно. ИМХО это полезно, как с точки зрения понятности конфига, так и с точки зрения унификации между различными upstream-модулями. А также избавляет нас от странной формулировки в документации: "By default, the directive?s value is close to the string" и упрощает код в нескольких местах. Понятно, что такое изменение нарушает совместимость конфигурации и потребует явного вмешательства при обновлении. Но если что-то менять в этом отношении, то я за такой вариант. -- Валентин Бартенев From nginx-forum at nginx.us Fri Jan 10 18:27:34 2014 From: nginx-forum at nginx.us (vladimircape) Date: Fri, 10 Jan 2014 13:27:34 -0500 Subject: Nginx cache Message-ID: <0752567e36b7019edc0561a8ae512618.NginxMailingListRussian@forum.nginx.org> Сайт написан на php фреймворке yii, т.е. все запросы проходят через index.php У меня установлена связка Fedora 16(nginx php5-fpm) настройл кэширование, но некорректно работает с авторизованными пользователями. Некоторые пишут что вообще почти не реально это настройть. Вот часть настройки set $no_cache 0; if ($request_method = POST) { set $no_cache 1; } #Don't cache if the URL contains a query string if ($query_string != "") { set $no_cache 1; } #Don't cache the following URLs if ($request_uri ~* "/(api/|login|logout|corporate/login|corporate/logout)") { set $no_cache 1; } #Don't cache if there is a cookie called PHPSESSID if ($http_cookie = "PHPSESSID") { set $no_cache 1; } location ~ \.php$ { fastcgi_cache_bypass $no_cache; fastcgi_no_cache $no_cache; fastcgi_pass php-fpm; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /srv/www/site/index.php; include fastcgi_params; try_files $fastcgi_script_name =404; fastcgi_cache nginx_webpy_cache; fastcgi_cache_valid 200 301 302 304 2m; fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_login_id"; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; fastcgi_hide_header "Set-Cookie"; } location ~* \.(ico|js|txt|jpg|jpeg|png|css|pdf)$ { root /srv/www/site; access_log off; expires 1h; add_header Pragma public; add_header Cache-Control "public"; } Авторизованным пользователем выхожу через logout , а потом если просто ввести адресс заходит под тем же логином, PHPSESSID 9ef4fjlop3udf37kghooi040d7 и 6e8789174e281f8ed80a55570a092d9d b64cbbf745b4e05f7fb188e...i:2;i:86400;i:3;a:0:{}} кука типа не удаляется при кэшировании. 6e8789174e281f8ed80a55570a092d9d Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246251,246251#msg-246251 From maks.invisible at gmail.com Fri Jan 10 18:40:14 2014 From: maks.invisible at gmail.com (maks) Date: Fri, 10 Jan 2014 20:40:14 +0200 Subject: =?UTF-8?B?bmdpbngg0LIg0LrQsNGH0LXRgdGC0LLQtSAgc210cCDQv9GA0L7QutGB0Lgg0Log?= =?UTF-8?B?0L3QtdGB0LrQvtC70YzQutC40Lwg0LHRjdC60LXQvdC00LDQvC4=?= Message-ID: <52D03E8E.4000709@gmail.com> Всем доброго времени суток. Решил, наконец, ближе познакомиться с nginx. Встречал информацию о том, что возможно его настроить как реверс-прокси для smtp с несколькими бэкендами, но толком нигде не описано как. Для одного бэкенда настроено. Буду благодарен за любую ссылку, которая прольёт свет на этот вопрос. From gmm at csdoc.com Fri Jan 10 20:33:24 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2014 22:33:24 +0200 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <1705428.JC99OxMjHr@vbart-laptop> References: <52CBE171.9070000@csdoc.com> <52CFC34E.10508@csdoc.com> <20140110154218.GQ1835@mdounin.ru> <1705428.JC99OxMjHr@vbart-laptop> Message-ID: <52D05914.5010500@csdoc.com> On 10.01.2014 19:57, Валентин Бартенев wrote: >>>>>> Смысл значения по умолчанию для proxy_cache_key состоит в том, что >>>>>> идентифицируется тот ресурс, куда осуществялется проксирование. >>>>> >>>>>> Тем самым, если в разных виртуальных серверах проксирование >>>>>> осуществляется в одно и то же место - будет использован >>>>>> один и тот же элемент кеша. >>> >>> Ситуация, когда все размещенные на одном сервере виртуальные хосты >>> имеют 100% идентичный контент и разные домены практически невозможна. >>> Такая настройка nginx сейчас может появиться только в результате ошибки. >>> >>> Еще дефолтовая настройка nginx на $proxy_host может быть полезной >>> тем, кто "грабит корованы", то есть показыват на своем сайте контент, >>> который был получен с других сайтов путем проксирования с кешированием. >> >> Например, это может быть отдельный location под общие элементы >> и/или ssi-инклуды. Именно под такие задачи оно исходно и >> программировалось, и именно потому и стоят такие значения по >> умолчанию - запрашиваем с бекенда то, что указано в proxy_pass, и >> кешируем то, что запрашивали. >> >> Просто следует понимать, что задач - больше одной. И хорошее >> решение для одной задачи - может оказаться плохим для другой. Да, теперь понятно, спасибо. Но всеравно, дефолтовое значение директивы proxy_cache_key очень странное, такой ключ применим возможно в 0.0001% конфигураций nginx в мире, а тут - default >> Проблема, на самом деле, в том, что прописанное в конфиге >> "proxy_set_header Host $host" существенно меняет суть запроса к >> бекенду, а значение по умолчанию proxy_cache_key об этом изменении >> не знает, его надо обучать этому вручную. Возможно, именно с этой >> стороны и следует подойти к этому вопросу. Да, очень странное значение proxy_cache_key по умолчанию и не менее странный пример настройки fastcgi_cache_key, который приведен в документации. Были ведь такие случаи, и подозреваю, что неоднократно, когда люди копируют себе в конфиг fastcgi_cache_key, а потом они в шоке от того, что происходит с их сайтами и рейтингами в поисковиках. > Лично мне нравится идея привести значение proxy_cache_key по умолчанию > к таковому fastcgi_cache_key, т.е. отсутствует и требуется задавать явно. > > ИМХО это полезно, как с точки зрения понятности конфига, так и с точки > зрения унификации между различными upstream-модулями. > > А также избавляет нас от странной формулировки в документации: > > "By default, the directive?s value is close to the string" > > и упрощает код в нескольких местах. Мне тоже нравится, только пожалуйста актуализируйте документацию на сайте по этим директивам proxy_cache_key и fastcgi_cache_key, чтобы внимательно прочитав ее, можно было понять что туда писать. > Понятно, что такое изменение нарушает совместимость конфигурации и > потребует явного вмешательства при обновлении. Но если что-то менять > в этом отношении, то я за такой вариант. Разве много ли таких конфигураций, которые полагались на дефолтовое значение директивы proxy_cache_key ? По крайней мере, можно добавить deprecation warning, если proxy_cache_key явно не задан, а через некоторое время - менять дефолт, и это почти никого не затронет. -- Best regards, Gena From vbart at nginx.com Fri Jan 10 20:48:07 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 11 Jan 2014 00:48:07 +0400 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <52D05914.5010500@csdoc.com> References: <52CBE171.9070000@csdoc.com> <1705428.JC99OxMjHr@vbart-laptop> <52D05914.5010500@csdoc.com> Message-ID: <19851145.3LVPOkosVM@vbart-laptop> On Friday 10 January 2014 22:33:24 Gena Makhomed wrote: [..] > Разве много ли таких конфигураций, которые полагались > на дефолтовое значение директивы proxy_cache_key ? [..] Полагаю не мало людей используют кэш для одного хоста и ключ по умолчанию у них нормально работает, а после изменения перестанет. -- Валентин Бартенев From gmm at csdoc.com Fri Jan 10 20:51:17 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2014 22:51:17 +0200 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <2310697.ov1uODaMRR@vbart-laptop> References: <52CEAABF.6030504@csdoc.com> <52CFDD57.5040502@csdoc.com> <52CFE253.8020801@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop> Message-ID: <52D05D45.10802@csdoc.com> On 10.01.2014 15:07, Валентин Бартенев wrote: >>>>>> Кому интересно почитать, подробней вот ссылка. >>>>>> http://habrahabr.ru/post/166855/ ... >> $host >> in this order of precedence: host name from the request line, or host >> name from the ?Host? request header field, or the server name matching a >> request ... > Единственный правильный способ: пойти в IETF с предложением исправить > соответствующие RFC, которые в том числе оговаривают, что следует делать > при получении нескольких заголовков Host, ну а потом уже сюда. с RFC то как раз все в порядке: "network location of the URI (authority) MUST be transmitted in a Host header field", только вот nginx не соответствует этим требованиям... http://tools.ietf.org/search/rfc2616#section-5.1.2 ... GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 ... The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root). ... -- Best regards, Gena From gmm at csdoc.com Fri Jan 10 21:10:17 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2014 23:10:17 +0200 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <19851145.3LVPOkosVM@vbart-laptop> References: <52CBE171.9070000@csdoc.com> <1705428.JC99OxMjHr@vbart-laptop> <52D05914.5010500@csdoc.com> <19851145.3LVPOkosVM@vbart-laptop> Message-ID: <52D061B9.5060805@csdoc.com> On 10.01.2014 22:48, Валентин Бартенев wrote: >> Разве много ли таких конфигураций, которые полагались >> на дефолтовое значение директивы proxy_cache_key ? > Полагаю не мало людей используют кэш для одного хоста > и ключ по умолчанию у них нормально работает, а после > изменения перестанет. Ok, но ведь при парсинге конфига nginx может посчитать количество хостов в конфиге, и если там всего один хост и явно не задан в конфиге proxy_cache_key - выдавать warning но продолжать работать со старым дефолтовым значением, а если хостов больше одного - то переключать на новый дефолт и выдавать fatal error, если proxy_cache_key не определен - всеравно в такой конфигурации от proxy_cache_key $scheme$proxy_host$request_uri; будет больше вреда, чем пользы из-за перемешивания в кеше контента от разных virtual host`ов. А если это highload, и это был отдельный location под общие элементы и/или ssi-инклуды - его админы в любом случае внимательно читают CHANGES и все варнинги от nginx. В таком варианте ведь ничего не сломается? -- Best regards, Gena From nginx-forum at nginx.us Fri Jan 10 21:28:33 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 10 Jan 2014 16:28:33 -0500 Subject: Nginx cache In-Reply-To: <0752567e36b7019edc0561a8ae512618.NginxMailingListRussian@forum.nginx.org> References: <0752567e36b7019edc0561a8ae512618.NginxMailingListRussian@forum.nginx.org> Message-ID: http://forum.nginx.org/read.php?21,245843,245896#msg-245896 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246251,246261#msg-246261 From vbart at nginx.com Fri Jan 10 22:17:11 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 11 Jan 2014 02:17:11 +0400 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <52D05D45.10802@csdoc.com> References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop> <52D05D45.10802@csdoc.com> Message-ID: <2025921.4jlt7fzs4I@vbart-laptop> On Friday 10 January 2014 22:51:17 Gena Makhomed wrote: > On 10.01.2014 15:07, Валентин Бартенев wrote: > > >>>>>> Кому интересно почитать, подробней вот ссылка. > >>>>>> http://habrahabr.ru/post/166855/ > ... > >> $host > >> in this order of precedence: host name from the request line, or host > >> name from the ?Host? request header field, or the server name matching a > >> request > ... > > Единственный правильный способ: пойти в IETF с предложением исправить > > соответствующие RFC, которые в том числе оговаривают, что следует делать > > при получении нескольких заголовков Host, ну а потом уже сюда. > > с RFC то как раз все в порядке: "network location of the URI > (authority) MUST be transmitted in a Host header field", > только вот nginx не соответствует этим требованиям... > > http://tools.ietf.org/search/rfc2616#section-5.1.2 [..] Если почитать внимательнее, то приведенные требования относятся к клиенту. Понятно, что сервер в принципе не может влиять на то, что transmitted в запросе. Что касается сервера, написано буквально секцией ниже: http://tools.ietf.org/search/rfc2616#section-5.2 5.2 The Resource Identified by a Request The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field. An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see section 19.6.1.1 for other requirements on Host support in HTTP/1.1.) An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request: 1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored. 2. If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host header field value. 3. If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message. Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested. Ровным счетом так nginx и поступает, если передан absoluteURI, то виртуальный сервер определяется по нему, а заголовок Host игнорируется. -- Валентин Бартенев From gmm at csdoc.com Fri Jan 10 23:06:00 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 11 Jan 2014 01:06:00 +0200 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <2025921.4jlt7fzs4I@vbart-laptop> References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop> <52D05D45.10802@csdoc.com> <2025921.4jlt7fzs4I@vbart-laptop> Message-ID: <52D07CD8.7080503@csdoc.com> On 11.01.2014 0:17, Валентин Бартенев wrote: >>>>>>>> Кому интересно почитать, подробней вот ссылка. >>>>>>>> http://habrahabr.ru/post/166855/ >> ... >>>> $host >>>> in this order of precedence: host name from the request line, or host >>>> name from the ?Host? request header field, or the server name matching a >>>> request >> ... >>> Единственный правильный способ: пойти в IETF с предложением исправить >>> соответствующие RFC, которые в том числе оговаривают, что следует делать >>> при получении нескольких заголовков Host, ну а потом уже сюда. >> >> с RFC то как раз все в порядке: "network location of the URI >> (authority) MUST be transmitted in a Host header field", >> только вот nginx не соответствует этим требованиям... >> >> http://tools.ietf.org/search/rfc2616#section-5.1.2 ... > Если почитать внимательнее, то приведенные требования относятся к клиенту. > Понятно, что сервер в принципе не может влиять на то, что transmitted в > запросе. nginx выступает в роли сервера только в том случае, когда он самостоятельно обслуживает клиентский запос. В тот момент, когда nginx делает http запрос к удаленному серверу он выступает в роли клиента. поэтому я и цитировал 5.1.2 а дальше, получив ответ от удаленного сервера он с этим ответом делает разные интересные вещи, например, сканирует его на предмет ssi-директив, или пропускает через свои sub/addition/и т.п. модули. и то, что получится в результате - складывает в файл кеша на диске, и после дополнительной цепочки преобразований - отправляет то, что получилось в результате как ответ на запрос своего клиента. например, если исходный запрос от клиента к nginx был GET http://good-site.com/pub/WWW/TheProject.html HTTP/1.1 Host: bad-site.com содержимое заголовка Host: согласно 5.2.1 должно игнорироваться, адрес хоста в этом случае: good-site.com а согласно требований 5.1.2 - network location of the URI (authority) MUST be transmitted in a Host header field, то есть исходящий запрос должен быть GET /pub/WWW/TheProject.html HTTP/1.1 Host: good-site.com nginx же в настройке по-умолчанию не соответсвует RFC, и вместо требуемого значения пишет в заголовок Host: значение переменной $proxy_host Теперь рассмотрим вариант связи с backend`ом по протоколу FastCGI, но поскольку у нас большой и сложный сайт сделаем два фронтенда: 1) основной nginx frontend 2) nginx frontend на хосте backend`а 3) backend, работающий по протоколу FastCGI. запрос от клиента проходит цепочку (1)->(2)->(3). поскольку между (1) и (2) используется протокол http, то согласно требований 5.1.2 и 5.2.1 на (2) запрос приходит в виде GET /pub/WWW/TheProject.html HTTP/1.1 Host: good-site.com не смотря на то, что в исходном запросе от клиента был игнорируемый заголовок Host: bad-site.com а дальше - все просто. В соответствии с требованиями спецификации протокола FastCGI - nginx записывает в переменную HTTP_HOST значение good-site.com. точнее, он ДОЛЖЕН так делать, согласно требований HTTP протокола прямо из коробки, без какой-либо дополнительной настройки. Эта схема работает одинаково вне зависимости от количества промежуточных серверов между nginx frontend и backend. точнее, ДОЛЖНА работать одинаково, вне зависимости от количества промежуточных серверов. если в случае отсутствия промежуточных серверов nginx ведет себя не так, - то это BUG, ибо в случае, когда на nginx frontend приходит запрос в виде absoluteURI, - тогда "Any Host header field value in the request MUST be ignored". nginx этого по каким-то причинам не делает. хотя согласно требований RFC - обе эти формы записи: GET http://good-site.com/pub/WWW/TheProject.html HTTP/1.1 и GET /pub/WWW/TheProject.html HTTP/1.1 Host: good-site.com полностью эквивалентны между собой. и nginx имеет полное право и даже обязанность трансформировать запрос с absoluteURI в запрос с relativeURI и network location of the URI (authority) MUST be transmitted in a Host header field. ============================================================= > Что касается сервера, написано буквально секцией ниже: > http://tools.ietf.org/search/rfc2616#section-5.2 > > 5.2 The Resource Identified by a Request > > The exact resource identified by an Internet request is determined by > examining both the Request-URI and the Host header field. > > An origin server that does not allow resources to differ by the > requested host MAY ignore the Host header field value when > determining the resource identified by an HTTP/1.1 request. (But see > section 19.6.1.1 for other requirements on Host support in HTTP/1.1.) > > An origin server that does differentiate resources based on the host > requested (sometimes referred to as virtual hosts or vanity host > names) MUST use the following rules for determining the requested > resource on an HTTP/1.1 request: > > 1. If Request-URI is an absoluteURI, the host is part of the > Request-URI. Any Host header field value in the request MUST be > ignored. > > 2. If the Request-URI is not an absoluteURI, and the request includes > a Host header field, the host is determined by the Host header > field value. > > 3. If the host as determined by rule 1 or 2 is not a valid host on > the server, the response MUST be a 400 (Bad Request) error message. > > Recipients of an HTTP/1.0 request that lacks a Host header field MAY > attempt to use heuristics (e.g., examination of the URI path for > something unique to a particular host) in order to determine what > exact resource is being requested. > > Ровным счетом так nginx и поступает, если передан absoluteURI, то виртуальный > сервер определяется по нему, а заголовок Host игнорируется. Та часть nginx, которая работает в режиме сервера определяет Host правильно. И правильно сохранет его в свою переменную $host. Но дальше в нарушение RFC вместо $host зачем-то используется $http_host не смотря на прямой запрет: Any Host header field value in the request MUST be ignored. А несоответствие требованиям RFC 2616 - это ведь BUG, верно? -- Best regards, Gena From vbart at nginx.com Fri Jan 10 23:17:22 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 11 Jan 2014 03:17:22 +0400 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <52D061B9.5060805@csdoc.com> References: <52CBE171.9070000@csdoc.com> <19851145.3LVPOkosVM@vbart-laptop> <52D061B9.5060805@csdoc.com> Message-ID: <1478459.2pApImaZVn@vbart-laptop> On Friday 10 January 2014 23:10:17 Gena Makhomed wrote: > On 10.01.2014 22:48, Валентин Бартенев wrote: > > >> Разве много ли таких конфигураций, которые полагались > >> на дефолтовое значение директивы proxy_cache_key ? > > > Полагаю не мало людей используют кэш для одного хоста > > и ключ по умолчанию у них нормально работает, а после > > изменения перестанет. > > Ok, но ведь при парсинге конфига nginx может посчитать Это не так просто и ведет к довольно сильному layering violation. Следует учесть, что в nginx: 1. Директивы из разных модулей обычно ничего не знают о существовании друг-друга, а равно и значениях; 2. Могут встречаться в конфиге в произвольном порядке, а директива server_name вообще несколько раз. Такая конфигурация валидна: server { server_name example.org; location { proxy_pass backend; } server_name example.org; } 3. Директива proxy_cache_key может быть задана также на уровнях http, server, и location-ах любой степени вложенности. 4. Как отсутствие, так и наличие директивы proxy_cache_key, не означает, что кэш вообще включен и используется. Для этого должно совпасть ещё минимум два условия: а) Наличие директивы proxy_pass в данном location-не, или на уровне server (неявный location-ой); б) Наличие директивы proxy_cache со значением отличным от off в этом же location, или унаследование такового с уровня выше. > количество хостов в конфиге, и если там всего один хост > и явно не задан в конфиге proxy_cache_key - выдавать warning > но продолжать работать со старым дефолтовым значением, > а если хостов больше одного - то переключать на новый > дефолт и выдавать fatal error, Типичный конфиг: server_name example.com www.example.com; > если proxy_cache_key > не определен - всеравно в такой конфигурации от > proxy_cache_key $scheme$proxy_host$request_uri; > будет больше вреда, чем пользы из-за перемешивания > в кеше контента от разных virtual host`ов. > > А если это highload, и это был отдельный location > под общие элементы и/или ssi-инклуды - > его админы в любом случае внимательно > читают CHANGES и все варнинги от nginx. > > В таком варианте ведь ничего не сломается? Почему ни warning, ни error сделать не представляется разумным - пояснил в самом начале. Опять же, ИМХО если что-то предпринимать в этом отношении, то лучше поступить следующим образом: 1. Добавить второй параметр, задающий ключ, в директивы proxy_cache, fastcgi_cache, scgi_cache, uwsgi_cache; 2. Отказаться от отдельных директив *_cache_key. Причем возможно сделать с промежуточным этапом: параметр опционален и warning при его отсутствии или наличии *_cache_key директив в конфиге. Либо разом: второй параметр обязателен когда значение первого отлично от off, и соответствующие ошибки - не запускаемся пока не поправят конфиг. Очевидные плюсы: 1. Упрощается конфигурация, поскольку ИМХО от раздельного задания ключа и зоны никакой практической пользы, зато какое-то сложное условие включения кэша в location-е. 2. Изменения потребуют явного вмешательства и принятия мер со стороны администратора, а не пройдут незамеченными в виде тихо переставшего работать кэша. И очевидный минус: затронет всех, кто использует кэш. -- Валентин Бартенев From vbart at nginx.com Fri Jan 10 23:51:15 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 11 Jan 2014 03:51:15 +0400 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <52D07CD8.7080503@csdoc.com> References: <52CEAABF.6030504@csdoc.com> <2025921.4jlt7fzs4I@vbart-laptop> <52D07CD8.7080503@csdoc.com> Message-ID: <5629281.JiPcg7myOX@vbart-laptop> On Saturday 11 January 2014 01:06:00 Gena Makhomed wrote: [..] > >> с RFC то как раз все в порядке: "network location of the URI > >> (authority) MUST be transmitted in a Host header field", > >> только вот nginx не соответствует этим требованиям... > >> > >> http://tools.ietf.org/search/rfc2616#section-5.1.2 > ... > > Если почитать внимательнее, то приведенные требования относятся к клиенту. > > Понятно, что сервер в принципе не может влиять на то, что transmitted в > > запросе. > > nginx выступает в роли сервера только в том случае, > когда он самостоятельно обслуживает клиентский запос. > > В тот момент, когда nginx делает http запрос к удаленному > серверу он выступает в роли клиента. поэтому я и цитировал 5.1.2 С точки зрения удаленного сервера да. И при этом поступает совершенно корректно, а именно передает "network location of the URI (authority)" в заголовки Host. Представим себе строчку из конфигурации: proxy_pass http://127.0.0.1:8181/some/path; думаю очевидно, что в из заданного URI "http://127.0.0.1:8181/some/path" является authority. > > а дальше, получив ответ от удаленного сервера он с этим ответом > делает разные интересные вещи, например, сканирует его на предмет > ssi-директив, или пропускает через свои sub/addition/и т.п. модули. > и то, что получится в результате - складывает в файл кеша на диске, > и после дополнительной цепочки преобразований - отправляет то, > что получилось в результате как ответ на запрос своего клиента. > > например, если исходный запрос от клиента к nginx был > > GET http://good-site.com/pub/WWW/TheProject.html HTTP/1.1 > Host: bad-site.com > > содержимое заголовка Host: согласно 5.2.1 должно игнорироваться, > адрес хоста в этом случае: good-site.com > > а согласно требований 5.1.2 - network location of the URI (authority) > MUST be transmitted in a Host header field, то есть исходящий запрос > должен быть > > GET /pub/WWW/TheProject.html HTTP/1.1 > Host: good-site.com > > nginx же в настройке по-умолчанию не соответсвует RFC, > и вместо требуемого значения пишет в заголовок Host: > значение переменной $proxy_host Поздравляю. Это самое необычное толкование RFC 2616, которое я когда либо встречал. К счастью оно разбивается об определение терминов client и server из него же: client A program that establishes connections for the purpose of sending requests. server An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. ключевой момент тут: "refers only to the role being performed by the program for a particular connection". Соединение между клиент->nginx и соединение nginx->upstream - это два разных соединения, и в каждом из них nginx играет исключительно одну единственную роль, применимую только к конкретному соединению. В соединении "клиент->nginx" не играет роль клиента и клиентские требования RFC 2616 в данном соединении к нему не применимы. > Теперь рассмотрим вариант связи с backend`ом по протоколу FastCGI, > но поскольку у нас большой и сложный сайт сделаем два фронтенда: > > 1) основной nginx frontend > 2) nginx frontend на хосте backend`а > 3) backend, работающий по протоколу FastCGI. > > запрос от клиента проходит цепочку (1)->(2)->(3). > поскольку между (1) и (2) используется протокол http, > то согласно требований 5.1.2 и 5.2.1 на (2) запрос приходит > в виде > > GET /pub/WWW/TheProject.html HTTP/1.1 > Host: good-site.com > > не смотря на то, что в исходном запросе > от клиента был игнорируемый заголовок Host: bad-site.com > > а дальше - все просто. В соответствии с требованиями > спецификации протокола FastCGI - nginx записывает в переменную > HTTP_HOST значение good-site.com. > > точнее, он ДОЛЖЕН так делать, согласно требований HTTP протокола > прямо из коробки, без какой-либо дополнительной настройки. В спецификации нет требования, согласно котором сервер из коробки должен быть клиентом и отправлять запросы куда-то дальше. Так что дополнительная настройка все равно потребуется, и я так понимаю, исходя из описания, она была какой-то такой: location { proxy_pass http://good-site.com; } > > Эта схема работает одинаково вне зависимости от количества > промежуточных серверов между nginx frontend и backend. > > точнее, ДОЛЖНА работать одинаково, > вне зависимости от количества промежуточных серверов. Она работает, настройку см. выше. > если в случае отсутствия промежуточных серверов nginx ведет себя > не так, - то это BUG, ибо в случае, когда на nginx frontend > приходит запрос в виде absoluteURI, - тогда "Any Host header > field value in the request MUST be ignored". > nginx этого по каким-то причинам не делает. Почему не делает? Процитированная фраза относится к rules из фразы которые находятся по общим заголовком из: An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request: именно таким правилом и пользуется nginx _при выборе_ виртуального хоста. > > хотя согласно требований RFC - обе эти формы записи: > > GET http://good-site.com/pub/WWW/TheProject.html HTTP/1.1 > > и > > GET /pub/WWW/TheProject.html HTTP/1.1 > Host: good-site.com > > полностью эквивалентны между собой. и nginx имеет > полное право и даже обязанность трансформировать > > запрос с absoluteURI в запрос с relativeURI > и network location of the URI (authority) > MUST be transmitted in a Host header field. Как сервер он такой обязанности не имеет, а в данном конкретном соединении, как я уже пояснил вначале, он выступает в роли сервера и никакой другой. Сервер вообще не обязан делать запросы и что-то куда-то transmitted. [..] > > Та часть nginx, которая работает в режиме сервера определяет Host > правильно. И правильно сохранет его в свою переменную $host. > > Но дальше в нарушение RFC вместо $host зачем-то используется $http_host > не смотря на прямой запрет: Any Host header field value in the request > MUST be ignored. > > А несоответствие требованиям RFC 2616 - это ведь BUG, верно? Поскольку мысль повторена по меньшей мере 3 раза, то и в третий раз, на всякий случай: на ту часть nginx, которая работает в режиме сервера, не распространяется клиентских требований RFC 2616, что в самом же RFC 2616 прописано, а именно роли клиента и сервера взаимоисключающие, и закреплены для каждого индивидуального соединения. -- Валентин Бартенев From vbart at nginx.com Sat Jan 11 00:17:48 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 11 Jan 2014 04:17:48 +0400 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <5629281.JiPcg7myOX@vbart-laptop> References: <52CEAABF.6030504@csdoc.com> <52D07CD8.7080503@csdoc.com> <5629281.JiPcg7myOX@vbart-laptop> Message-ID: <19852752.KMkQKQoruv@vbart-laptop> On Saturday 11 January 2014 03:51:15 Валентин Бартенев wrote: [..] Нда, сорри, уже плохо согласовываю слова в предложениях - явно пора спать. Подводя итог, не надо вырывать отдельные фразы из RFC и пытаться их интерпретировать в свою пользу. Когда nginx выступает в роли клиента, он пытается соблюдать соответствующие требования спецификации и делает это неплохо. Аналогично в роли сервера. Что происходит между - зависит от настроек. Спецификация на протокол HTTP, очевидно, не специфицирует настоек nginx'а, и попытки её за уши к этому притянуть - бесполезны. -- Валентин Бартенев From nginx-forum at nginx.us Sat Jan 11 00:40:07 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 10 Jan 2014 19:40:07 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <2025921.4jlt7fzs4I@vbart-laptop> References: <2025921.4jlt7fzs4I@vbart-laptop> Message-ID: <61d5fb7b070b6da836e3c3f51a67263a.NginxMailingListRussian@forum.nginx.org> > Ровным счетом так nginx и поступает, если передан absoluteURI, то > виртуальный > сервер определяется по нему, а заголовок Host игнорируется. Ровным счетом так же должен поступать и бекенд, игнорировать заголовок Host, если передан absoluteURI. Но дело в том что бекенд не получает, raw запрос с absoluteURI, именно по этой причине бекенду необходимо передать, то значения HTTP_HOST, которое использовал Nginx для определения вирт хоста. В противном случаи возможны коллизии, приведу примеры. На одном хостинге, хостятся два конкурирующих электронных магазина, например: apple-shop.com и samsung-shop.com, в котором используется Nginx кеширования. Для каждого вирт хоста прописан proxy_cache_key $proxy_host$request_uri. Теперь делаем запрос GET http://apple-shop.com/ HTTP/1.1 Host: samsung-shop.com В результате чего, ответ бекенда сохранится в кеше Nginx с ключом " samsung-shop.com/" но содержать внутри будет страницу apple-shop.com/. На все последующие запросы samsung-shop.com будет отдаваться страница с товарами Apple, так как внутри кеш файла с ключом "samsung-shop.com/" будет страница хоста apple-shop.com. И так будут работать бекенды на любом языке программирования не только на РНР, те самые правильные программисты которых не расстреляли, будут в недоумения, что они сделали не так, вить все же сделано в точности как написано в официал документации Nginx :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,246271#msg-246271 From vbart at nginx.com Sat Jan 11 01:06:20 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 11 Jan 2014 05:06:20 +0400 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <61d5fb7b070b6da836e3c3f51a67263a.NginxMailingListRussian@forum.nginx.org> References: <2025921.4jlt7fzs4I@vbart-laptop> <61d5fb7b070b6da836e3c3f51a67263a.NginxMailingListRussian@forum.nginx.org> Message-ID: <4730047.RmmcqWb8En@vbart-laptop> On Friday 10 January 2014 19:40:07 S.A.N wrote: > > Ровным счетом так nginx и поступает, если передан absoluteURI, то > > виртуальный > > сервер определяется по нему, а заголовок Host игнорируется. > > Ровным счетом так же должен поступать и бекенд, игнорировать заголовок Host, > если передан absoluteURI. > Но дело в том что бекенд не получает, raw запрос с absoluteURI, именно по > этой причине бекенду необходимо передать, то значения HTTP_HOST, которое > использовал Nginx для определения вирт хоста. Значение HTTP_HOST относится к FastCGI и определяется другим RFC, в котором сказано: Meta-variables with names beginning with "HTTP_" contain values read from the client request header fields, if the protocol used is HTTP. The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with "_" and has "HTTP_" prepended to give the meta-variable name. The header data can be presented as sent by the client, or can be rewritten in ways which do not change its semantics. так что начиная уже с этой фразы и далее - вы не правы. > В противном случаи возможны коллизии, приведу примеры. Коллизии возможны только в одном случае: программист не проверяет данные, получаемые от клиента, и такому программисту никаким костылями не поможешь. > > На одном хостинге, хостятся два конкурирующих электронных магазина, > например: apple-shop.com и samsung-shop.com, в котором используется Nginx > кеширования. > Для каждого вирт хоста прописан proxy_cache_key $proxy_host$request_uri. > > Теперь делаем запрос > GET http://apple-shop.com/ HTTP/1.1 > Host: samsung-shop.com > > В результате чего, ответ бекенда сохранится в кеше Nginx с ключом " > samsung-shop.com/" но содержать внутри будет страницу apple-shop.com/. > На все последующие запросы samsung-shop.com будет отдаваться страница с > товарами Apple, так как внутри кеш файла с ключом "samsung-shop.com/" будет > страница хоста apple-shop.com. Не будет, если только в обоих случаях не указано: proxy_pass http://samsung-shop.com; а если именно так и указано, то получаете ровно такое поведение, какое было сконфигурировано, что же в этом странного? Что настроили - то и получили. Вы настраиваете HTTP сервер, что предполагает от вас хотя бы минимальных знаний предмета и умения читать документацию. Вы хотите пожаловаться на кольт 45-го калибра, что он позволят вам выстрелить себе в ногу, да ещё разными способами? > И так будут работать бекенды на любом языке программирования не только на > РНР, те самые правильные программисты которых не расстреляли, будут в > недоумения, что они сделали не так, вить все же сделано в точности как > написано в официал документации Nginx :) 1. В каком месте документации написано, что надо настраивать так, как было указано вами выше? 2. Как вообще всё вышеописанное вами относится к обсуждаемой в данной подветке теме про http://habrahabr.ru/post/166855/ (которая вообще не относится к кэшу и директивам proxy_cache_key/fastcgi_cache_key, но уж так вышло, что была затронута)? -- Валентин Бартенев From nginx-forum at nginx.us Sat Jan 11 03:08:00 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 10 Jan 2014 22:08:00 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <4730047.RmmcqWb8En@vbart-laptop> References: <4730047.RmmcqWb8En@vbart-laptop> Message-ID: <6b15ebe4507f1421a83ab34ff6c4dc78.NginxMailingListRussian@forum.nginx.org> > Коллизии возможны только в одном случае: программист не проверяет > данные, > получаемые от клиента, и такому программисту никаким костылями не > поможешь. Проверять на бекенде значения Host не рационально, если в конфигурации server указан только один домен. Если следовать вашей логике тогда, бекенд должен проверять не только Host, но и IP коннекта чтобы убедится что это коннект от Nginx, так тоже никто не делает потому что это не рационально, более эффективный способ настроить фаирвол который закрывает извне доступ к портам бекенда. Тоже самое с заголовком Host, в том же Apache директива UseCanonicalName On, во многих дистрибутивах установлена по умолчанию или администраторы её устанавливают самостоятельно. Но если вы по прежнему считаете что проверка Host на бекенде, решает все проблемы вы ошибаетесь, приведу пример. Есть проект, в котором сайт имеет множество подоменов, каждый подомен настроен в отдельном server{}. Бекенд при получении запросов проверяет HTTP_HOST и в соответствии с его значениям, выполняет разную логику и генерит разные страницы. Каждый подомен настроен в отдельном server{} индивидуально и оптимизирован под функционал каждого подомена. Пример: server { server_name example.com ? fastcgi_cache use_cache; ?. } server { server_name auth.example.com ? } Как видите в первом вирт хосте есть Nginx кеширования, во втором его нет. Теперь делаем запрос GET http://auth.example.com/ HTTP/1.1 Host: example.com Nginx, определяет вирт хост как auth.example.com в котором нет кешировании и передает бекенду HTTP_HOST = example.com, бекенд проверяет HTTP_HOST и генерит страницу для example.com. Это позволяет устроить Ддос атаку на домен example.com потому что Nginx будет пропускать все запросы к бекенду без кеширования, бекенд будет генерить страницу для example.com, тратить свои ресурсы в расчете на то что страница попадет в кеш Nginx, но этого не случится потому что Nginx выполнил директивы из одного вирт хоста, но в бекенд передал другое значения Host и проверка этого значения прошла на бекенде успешно что и требовалось хакерам для Ддос атаки. > > Для каждого вирт хоста прописан proxy_cache_key > $proxy_host$request_uri. > > > > Теперь делаем запрос > > GET http://apple-shop.com/ HTTP/1.1 > > Host: samsung-shop.com > > > > В результате чего, ответ бекенда сохранится в кеше Nginx с ключом " > > samsung-shop.com/" но содержать внутри будет страницу > apple-shop.com/. > > На все последующие запросы samsung-shop.com будет отдаваться > страница с > > товарами Apple, так как внутри кеш файла с ключом > "samsung-shop.com/" будет > > страница хоста apple-shop.com. > > Не будет, если только в обоих случаях не указано: Т.е вы утверждаете, что значения переменой $proxy_host в данном запросе будет = apple-shop.com, а не samsung-shop.com? Сейчас проверить самостоятельно не могу, потому что везде у нас FastCGI. Но если $proxy_host != $http_host, тогда я не вижу причин не сделать тоже самое для FastCGI. > 1. В каком месте документации написано, что надо настраивать так, как > было > указано вами выше? Вот ссылка на документацию. http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_key По умолчанию значение директивы близко к строке proxy_cache_key $scheme$proxy_host$uri$is_args$args; > 2. Как вообще всё вышеописанное вами относится к обсуждаемой в данной > подветке теме про http://habrahabr.ru/post/166855/ (которая вообще > не относится к кэшу и директивам > proxy_cache_key/fastcgi_cache_key, > но уж так вышло, что была затронута)? В данном примере, я пытался привести ситуацию где используется proxy_cache_key (тема нашего треда) и так же запрос с absoluteURI чтобы показать проблемы описаны в http://habrahabr.ru/post/166855/ В итого хочется сказать, что отсутствия в Nginx аналога UseCanonicalName On, который есть в Apache, на руку только злоумышленникам, которые будут делать запросы с absoluteURI и заголовком Host одновременно, в расчете на то что Nginx выполнит директивы из одного вирт хоста, а бекенд будет выполнять данный запрос в соответсвии с заголовком Host, который Nginx проигнорировал в этом и заключается коллизия. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,246274#msg-246274 From nginx-forum at nginx.us Sat Jan 11 03:30:51 2014 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 10 Jan 2014 22:30:51 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <6b15ebe4507f1421a83ab34ff6c4dc78.NginxMailingListRussian@forum.nginx.org> References: <4730047.RmmcqWb8En@vbart-laptop> <6b15ebe4507f1421a83ab34ff6c4dc78.NginxMailingListRussian@forum.nginx.org> Message-ID: Хочу уточнить, я не предлагаю полную аналогию с UseCanonicalName, я имел виду использовать значения переменной $host, при условии что host из absoluteURI отличается от значения клиентского заголовка Host. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,246275#msg-246275 From nginx-forum at nginx.us Sat Jan 11 08:12:29 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 11 Jan 2014 03:12:29 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <6b15ebe4507f1421a83ab34ff6c4dc78.NginxMailingListRussian@forum.nginx.org> References: <4730047.RmmcqWb8En@vbart-laptop> <6b15ebe4507f1421a83ab34ff6c4dc78.NginxMailingListRussian@forum.nginx.org> Message-ID: <714fa843d6c8b2c155db46b3acf6775b.NginxMailingListRussian@forum.nginx.org> > Т.е вы утверждаете, что значения переменой $proxy_host в данном > запросе будет = apple-shop.com, а не samsung-shop.com? > Сейчас проверить самостоятельно не могу, потому что везде у нас > FastCGI. Вы правы, $proxy_host = proxy_pass, я со своим FastCGI уже совсем забыл про правила проксирования, sorry. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,246277#msg-246277 From gmm at csdoc.com Sat Jan 11 10:34:35 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 11 Jan 2014 12:34:35 +0200 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <5629281.JiPcg7myOX@vbart-laptop> References: <52CEAABF.6030504@csdoc.com> <2025921.4jlt7fzs4I@vbart-laptop> <52D07CD8.7080503@csdoc.com> <5629281.JiPcg7myOX@vbart-laptop> Message-ID: <52D11E3B.5020700@csdoc.com> On 11.01.2014 1:51, Валентин Бартенев wrote: >>>> с RFC то как раз все в порядке: "network location of the URI >>>> (authority) MUST be transmitted in a Host header field", >>>> только вот nginx не соответствует этим требованиям... >>>> >>>> http://tools.ietf.org/search/rfc2616#section-5.1.2 >> > >>> Если почитать внимательнее, то приведенные требования относятся к клиенту. >>> Понятно, что сервер в принципе не может влиять на то, что transmitted в >>> запросе. >> >> nginx выступает в роли сервера только в том случае, >> когда он самостоятельно обслуживает клиентский запос. >> >> В тот момент, когда nginx делает http запрос к удаленному >> серверу он выступает в роли клиента. поэтому я и цитировал 5.1.2 > > С точки зрения удаленного сервера да. И при этом поступает совершенно > корректно, а именно передает "network location of the URI (authority)" > в заголовки Host. В том-то и дело, что в настройке по-умолчанию он этого не делает: server { server_name example.com; proxy_pass http://127.0.0.1/; } Хотя nginx и определил, что имя хоста example.com, на backend в заголовке Host: запроса он отправляет совсем другое значение, в данном случае: 127.0.0.1 Очень наивно отправлять в заголовке Host: 127.0.0.1 клиентского запроса к своему upstream`у и ожидиать, что в ответ придет контент для хоста example.com То же самое касается и работы по протоколу FastCGI. nginx верно определил, что имя виртуального хоста good-site.com но на backend отправил в запросе совсем другу инфу bad-site.com >> например, если исходный запрос от клиента к nginx был >> >> GET http://good-site.com/pub/WWW/TheProject.html HTTP/1.1 >> Host: bad-site.com >> >> содержимое заголовка Host: согласно 5.2.1 должно игнорироваться, >> адрес хоста в этом случае: good-site.com >> >> а согласно требований 5.1.2 - network location of the URI (authority) >> MUST be transmitted in a Host header field, то есть исходящий запрос >> должен быть >> >> GET /pub/WWW/TheProject.html HTTP/1.1 >> Host: good-site.com >> >> nginx же в настройке по-умолчанию не соответсвует RFC, >> и вместо требуемого значения пишет в заголовок Host: >> значение переменной $proxy_host > > Поздравляю. Это самое необычное толкование RFC 2616, которое я когда либо > встречал. > > К счастью оно разбивается об определение терминов client и server из него же: > > client > A program that establishes connections for the purpose of sending > requests. > > server > An application program that accepts connections in order to > service requests by sending back responses. Any given program may > be capable of being both a client and a server; our use of these > terms refers only to the role being performed by the program for a > particular connection, rather than to the program's capabilities > in general. Likewise, any server may act as an origin server, > proxy, gateway, or tunnel, switching behavior based on the nature > of each request. > > ключевой момент тут: "refers only to the role being performed by the program > for a particular connection". > Соединение между клиент->nginx и соединение nginx->upstream - это два > разных соединения, и в каждом из них nginx играет исключительно одну > единственную роль, применимую только к конкретному соединению. Все верно. В particular connection между браузером и nginx - nginx выступает в роли сервера, и поэтому там требования из 5.2 а в particular connection между nginx и backend`ом - nginx выступает в роли клиента и поэтому здесь он обязан выполнять требования 5.1.2 > В соединении "клиент->nginx" не играет роль клиента и клиентские требования > RFC 2616 в данном соединении к нему не применимы. Клиентские требования из п.5.1.2 RFC 2616 применимы к nginx в своединении nginx->upstream Внутри какого-то server { ... } - nginx определил, имя виртуального хоста (authority) соответственно именно это имя виртуального хоста он MUST передать в заголовке Host: при запросе к upstream серверу. Только таким способом, с помощью заголовка Host: upstream сможет отличить один виртуальный сервер от другого и дать своему клиенту верный ответ. Это же очевидно, если кто-то хочет получить в ответ страницу с сайта гугла, то в заголовке Host: своего запроса он обязан отправить именно "google.com". А если отправить там "microsoft.com" - то ничего работать не будет и так делать нельзя, см. 5.1.2 Тут у нас точно такая же ситуация, только в роли клиента выступает nginx. >> Теперь рассмотрим вариант связи с backend`ом по протоколу FastCGI, >> но поскольку у нас большой и сложный сайт сделаем два фронтенда: >> >> 1) основной nginx frontend >> 2) nginx frontend на хосте backend`а >> 3) backend, работающий по протоколу FastCGI. >> >> запрос от клиента проходит цепочку (1)->(2)->(3). >> поскольку между (1) и (2) используется протокол http, >> то согласно требований 5.1.2 и 5.2.1 на (2) запрос приходит >> в виде >> >> GET /pub/WWW/TheProject.html HTTP/1.1 >> Host: good-site.com >> >> не смотря на то, что в исходном запросе >> от клиента был игнорируемый заголовок Host: bad-site.com >> >> а дальше - все просто. В соответствии с требованиями >> спецификации протокола FastCGI - nginx записывает в переменную >> HTTP_HOST значение good-site.com. >> >> точнее, он ДОЛЖЕН так делать, согласно требований HTTP протокола >> прямо из коробки, без какой-либо дополнительной настройки. > В спецификации нет требования, согласно котором сервер из коробки > должен быть клиентом и отправлять запросы куда-то дальше. Такого требования действительно нет. И запросы клиентов к статике никуда дальше nginx не уходят, он их обрабатывает самостоятельно. Кстати, именно по этой причине nginx и называется веб-сервером. Но в том случае, когда nginx, как http клиент делает запросы к своему upstream серверу по протоколу HTTP/1.1 - он обязан выполнять требования RFC 2616 в частности http://tools.ietf.org/search/rfc2616#section-5.1.2 > Так что дополнительная настройка все равно потребуется, и я так > понимаю, исходя из описания, она была какой-то такой: > > location { > proxy_pass http://good-site.com; > } Что именно и как именно писать в конфигах nginx - это его личное дело, требования к оформлению конфигов изложены только в документации к nginx. Мы сейчас о другом аспекте говорим. О том, как работает протокол HTTP. Если nginx хочет получит от backend`а ответ для виртуального хоста good-site.com - тогда он обязан в заголовке Host отправить именно good-site.com и он не имеет права отправлять там 127.0.0.1 и т.п. Это то, что касается работы name-based virtual host`ов. Если же upstream у nginx не name-based virtual host, а IP-based virtual host - тогда можно и не отправлять заголовок Host: или писать там все что угодно, backend всеравно проигнорирует этот заголовок и даст ответ для good-site.com даже если в заголовке Host: запроса было 127.0.0.1 >> если в случае отсутствия промежуточных серверов nginx ведет себя >> не так, - то это BUG, ибо в случае, когда на nginx frontend >> приходит запрос в виде absoluteURI, - тогда "Any Host header >> field value in the request MUST be ignored". >> nginx этого по каким-то причинам не делает. > > Почему не делает? Процитированная фраза относится к rules из > фразы которые находятся по общим заголовком из: > > An origin server that does differentiate resources based on the host > requested (sometimes referred to as virtual hosts or vanity host > names) MUST use the following rules for determining the requested > resource on an HTTP/1.1 request: > > именно таким правилом и пользуется nginx _при выборе_ виртуального хоста. Если nginx _выбрал_ виртуальный хост good-site.com зачем после выбора он резко меняет свое мнение и начинает делать запросы к backend`у на виртуальный хост bad-site.com ? Каким образом это согласуется со здравым смыслом? Если пользователь nginx написал в конфиге nginx: server { server_name good-site.com; // ... } И nginx выбрал этот name-based виртуальный хост, с какой радости тогда на backend уходит запрос для виртуального хоста bad-site.com ? В конфиге рядом есть отдельный server { server_name bad-site.com; // ... } И пользователь nginx хочет, чтобы все запросы к bad-site.com nginx обрабатывал именно в этом блоке server. Сейчас же - вполне возможна такая ситуация, что запрос клиента nginx со своей стороны будет обрабатывать как виртуальный хост good-site.com, но на backend он отправит запрос к bad-site.com и наоборот. Это - BUG. Workaround: proxy_set_header Host $host; Действительно, в RFC 2616 про это ничего не написано, но разве здравый смысл не подсказывает, что все запросы к name-based виртуальному хосту good-site.com backend`а должны происходить исключительно из блока server который соответствует server_name good-site.com ? И если nginx ведет себя не так, то разве не очевидно, что это BUG ? Например, запрос клиента попал в блок server { server_name good-site.com; // ... } при этом в переменную $host записано значение good-site.com. Если вдруг внутри этого server`а nginx начнет отдавать статику от совсем другого виртуального хоста, например, от bad-site.com - это ведь будет BUG, верно? Аналогично это BUG и в случае с динамикой. >> хотя согласно требований RFC - обе эти формы записи: >> >> GET http://good-site.com/pub/WWW/TheProject.html HTTP/1.1 >> >> и >> >> GET /pub/WWW/TheProject.html HTTP/1.1 >> Host: good-site.com >> >> полностью эквивалентны между собой. и nginx имеет >> полное право и даже обязанность трансформировать >> >> запрос с absoluteURI в запрос с relativeURI >> и network location of the URI (authority) >> MUST be transmitted in a Host header field. > Как сервер он такой обязанности не имеет, а в данном конкретном соединении, > как я уже пояснил вначале, он выступает в роли сервера и никакой другой. nginx выступает и в роли сервера и в роли клиента, в зависимости от particular connection. Такую обязанность он имеет как http клиент при совершении запросов к upstream. > Сервер вообще не обязан делать запросы и что-то куда-то transmitted. http клиент обязан выполнять требования RFC 2616 - http://tools.ietf.org/search/rfc2616#section-5.1.2 >> Та часть nginx, которая работает в режиме сервера определяет Host >> правильно. И правильно сохранет его в свою переменную $host. >> >> Но дальше в нарушение RFC вместо $host зачем-то используется $http_host >> не смотря на прямой запрет: Any Host header field value in the request >> MUST be ignored. >> >> А несоответствие требованиям RFC 2616 - это ведь BUG, верно? > > Поскольку мысль повторена по меньшей мере 3 раза, то и в третий раз, > на всякий случай: на ту часть nginx, которая работает в режиме сервера, > не распространяется клиентских требований RFC 2616, что в самом же RFC 2616 > прописано, а именно роли клиента и сервера взаимоисключающие, и закреплены > для каждого индивидуального соединения. Роли клиента и сервера взаимоисключающие только for a particular connection. При запросе клиент->nginx - он сервер, а при запросе nginx->upsteam - он клиент. Если nginx знает что это name-based virtual host с именем good-site.com он MUST NOT обманывать upstream server и говорить, что это bad-site.com -- Best regards, Gena From gmm at csdoc.com Sat Jan 11 11:18:13 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 11 Jan 2014 13:18:13 +0200 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <19852752.KMkQKQoruv@vbart-laptop> References: <52CEAABF.6030504@csdoc.com> <52D07CD8.7080503@csdoc.com> <5629281.JiPcg7myOX@vbart-laptop> <19852752.KMkQKQoruv@vbart-laptop> Message-ID: <52D12875.4050209@csdoc.com> On 11.01.2014 2:17, Валентин Бартенев wrote: > Подводя итог, не надо вырывать отдельные фразы из RFC и пытаться их > интерпретировать в свою пользу. > > Когда nginx выступает в роли клиента, он пытается соблюдать соответствующие > требования спецификации и делает это неплохо. Аналогично в роли сервера. > > Что происходит между - зависит от настроек. > > Спецификация на протокол HTTP, очевидно, не специфицирует настоек nginx'а, > и попытки её за уши к этому притянуть - бесполезны. http://tools.ietf.org/search/rfc2616#section-5.2 5.2 The Resource Identified by a Request ... An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request: 1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored. ================================ Это требование RFC 2616 не выполняется. Вместо того чтобы игнорировать Host header field value nginx передает его на backend в качестве имени хоста. Вместо требуемого RFC "host is part of the Request-URI" и вот еще: http://tools.ietf.org/search/rfc3875#section-3.1 3.1. Server Responsibilities The server acts as an application gateway. It receives the request from the client, selects a CGI script to handle the request, converts the client request to a CGI request, executes the script and converts the CGI response into a response for the client. Вот это требование RFC 3875 не выполняется. Вместо того, чтобы корректно сконвертировать запрос от клиента в CGI запрос - nginx использует при формировании запроса к клиенту то значение из заголовка Host:, которое согласно требований RFC 2616 он MUST проигнорировать и вместо него MUST использовать host part of the absolute Request-URI. дополнительная информация: http://tools.ietf.org/search/rfc2616#section-19.6.1.1 -- Best regards, Gena From postmaster at softsearch.ru Sun Jan 12 19:55:31 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 12 Jan 2014 23:55:31 +0400 Subject: freebsd network tuning Message-ID: <1845599893.20140112235531@softsearch.ru> Здравствуйте. С того момента, когда Игорь рассказывал про тюнинг FreeBSD изменилось и добавилось немного интересного. Вот нашёл статью: https://calomel.org/freebsd_network_tuning.html Признаюсь, что не заметил каких-то ощутимых ускорений от этого тюнинга, но вдруг кому-то надо 10 гигабит раздавать... -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Mon Jan 13 02:20:57 2014 From: nginx-forum at nginx.us (wsl5shuai) Date: Sun, 12 Jan 2014 21:20:57 -0500 Subject: e ratio with that longterm rate of growth Message-ID: <2977577b139ed2b2a1709e6157146533.NginxMailingListRussian@forum.nginx.org> When it comes to acquiring menswear, a great NFL basketball jersey is definitely the way to go. These include some of the most popular items currently available, and the demand only becomes higher during football time of year. In fact, postSuper Pan sales upon football jerseys are the highest men's clothing sales of this year.. Population: Fifty nine,500. , Nation City, and also West Nyc West Nyc, town (2001 pop. 1898. A number of do not recognize gray curly hair and some will not accept wild hair that has been tinted or otherwise chemically processed. Donated hair that's not suitable or needed to help make wigs for people with medical diseases is often distributed to help protect other business costs. It shouldn't be used as an alternative to professional medical tips, diagnosis or perhaps treatment. The iPhone is surely an amazing, world wide web connected hiburan enhanced sensible cell phone that is designed and dispersed simply by Apple Integrated. In some shops, it is possible to purchase a wholesale apple iphone for a reduced price. The original form of an iPhone has got smallest appliance in order to make the device to be much more condensed as well as manageable.. NHL, Baseball, NBA in addition to NHL are a number of ball online games in U . s .. You can also cheap jerseys of other video games on USA Top Tops. Champion staff jerseys such as Chicago Blackhawks Nhl jerseys, Los Angeles Los angeles lakers Jerseys, Bay area Giants Nhl jerseys, Or The stars jerseys Kobe tops, James nhl jerseys, Sidney Crosby jerseys and so on. Modern consumers are full of personas. In order to exhibit their individualities, the wear unusual clothes, talk the so called fashion phrases, express their unique ideas and the like. The basketball fans endeavor their minds to produce up fresh way to aid their favorite crew. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246298,246298#msg-246298 From nginx-forum at nginx.us Mon Jan 13 02:22:11 2014 From: nginx-forum at nginx.us (wsl5shuai) Date: Sun, 12 Jan 2014 21:22:11 -0500 Subject: it due to the federal drug administration fda Message-ID: So long as the new year 2010 playoffs may be using, these days utilized in a person's is definitely the period to say in your certain dedication in your preferred Country wide field hockey acquaintance celebration. 20092010 nfl calendar year will be an incredible period for the season along side usually the moment lovers extreme caution probably the most for each signifying advisable to their aid and also enable by means of wearing class Shane Doan Jersey, border, tshirts plus types of Across the country field tennis acquaintance products. Even when you are generally Rockets, Hardi and also Boston celtics, you'll be able to however cheer this dedication getting around method with genuine NBA hammering a nail surfaces, information nba nfl jerseys or perhaps swingman nhl jerseys to get males, adult females plus newborns. Does one like athletics? are you your NFL enthusiasts? NFL jerseys whole! Isn just like to know nearly anything aspects with regards to NFL. Every one of us is certainly, hope put their favorite things receives them for recollection, the high-quality thing, we all want to keep. But some things basically be a memory, experienced had, for instance a fantastic performances, any fierce video game. Asked by way of reporters in the problem, artest easy, says the plan in the UK the Cheshire jet fleet. "As a team, we have not managed to retain Brian shaw, NFL football jerseys this is a dissatisfied. You can ungrateful, can forget whom brought everyone this, because of this level will inform, Brian shaw has to be praised. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246299,246299#msg-246299 From nginx-forum at nginx.us Mon Jan 13 05:31:19 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 13 Jan 2014 00:31:19 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_cache_key_=D0=B8_fastcgi_cache_key?= In-Reply-To: <6b15ebe4507f1421a83ab34ff6c4dc78.NginxMailingListRussian@forum.nginx.org> References: <4730047.RmmcqWb8En@vbart-laptop> <6b15ebe4507f1421a83ab34ff6c4dc78.NginxMailingListRussian@forum.nginx.org> Message-ID: Для убедительности, приведу ещё такой пример. Есть бекенд приложения, которое обслуживает множество хостов, всех этих хостах fastcgi_pass одинаковы, роутинг внутри приложения осуществляется по HTTP_HOST, дело в том, что использовать для роутинга SERVER_NAME, часто невозможно по ряду причин. Nginx, конфиг: server { server_name example.com { location /private/ { internal; auth_basic "Private "; auth_basic_user_file conf/htpasswd; ... } fastcgi_pass 127.0.0.1:9000; } } server { server_name other.com { ? fastcgi_pass 127.0.0.1:9000; } } Теперь делаем запрос GET http://other.com/private/ HTTP/1.1 Host: example.com Nginx, определяет вирт хост как other.com в котором нет директив для location /private/ {internal; auth_basic}, но при этом Nginx передает бекенду HTTP_HOST = example.com, бекенд проверяет HTTP_HOST и отдает контент для example.com/private/. Если вы не считаете это багом Nginx, тогда объясните мне, зачем указывать в location директивы internal; auth_basic, если любой студент сможет их обойти. Данная уязвимость открыта для всех бекендов которые для роутинга использует HTTP_HOST, а как правило это именно так, одна из основных причин, бекенду нужно работать и в default_server. Можно конечно сделать на бекенде, мапинг server_name и хостов, всегда на каждом запросе проверять isset($map[SERVER_NAME][ HTTP_HOST]) Но зачем все это, если в конфиге Nginx и так уже созданы все эти связи и Nginx на каждом запросе их и так всегда проверяет. По этому я считаю, что эту уязвимость нужно закрыть на уровне Nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,246301#msg-246301 From citrin at citrin.ru Mon Jan 13 09:12:50 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 13 Jan 2014 13:12:50 +0400 Subject: freebsd network tuning In-Reply-To: <1845599893.20140112235531@softsearch.ru> References: <1845599893.20140112235531@softsearch.ru> Message-ID: <52D3AE12.2020907@citrin.ru> On 01/12/14 23:55, Михаил Монашёв wrote: > Признаюсь, что не заметил каких-то ощутимых ускорений от этого > тюнинга, Большая часть тюнинга не для ускорения, а для того, чтобы при достижении определённой нагрузки X сервер не превратился в тыкву, несмотря на то что свободная память ещё есть, а CPU загружен не на 100%. Соответственно нужно использовать утилиты для создания большой нагрузки и смотреть какую максимальную нагрузку сервер может выдержать с тюнингом и без. From citrin at citrin.ru Mon Jan 13 09:21:12 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 13 Jan 2014 13:21:12 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INCyINC60LDRh9C10YHRgtCy0LUgIHNtdHAg0L/RgNC+0LrRgdC4?= =?UTF-8?B?INC6INC90LXRgdC60L7Qu9GM0LrQuNC8INCx0Y3QutC10L3QtNCw0Lwu?= In-Reply-To: <52D03E8E.4000709@gmail.com> References: <52D03E8E.4000709@gmail.com> Message-ID: <52D3B008.6000209@citrin.ru> On 01/10/14 22:40, maks wrote: > Решил, наконец, ближе познакомиться с nginx. > Встречал информацию о том, что возможно его настроить как реверс-прокси для smtp > с несколькими бэкендами, но толком нигде не описано как. Для одного бэкенда > настроено. В случае почтового прокси балансировку между бэкендами выполняет не сам nginx, а http-сервер к которому nginx делает запросы: http://nginx.org/en/docs/mail/ngx_mail_auth_http_module.html Несмотря на название auth_http данный сервер можно использовать и для smtp без авторизации. Пример такого сервера: https://bitbucket.org/vstakhov/nginx-smtp-policy (документации к сожалению нет и для использования с современными версиями nginx возможно потребуется доработка). From koticka at mail.ru Mon Jan 13 10:16:54 2014 From: koticka at mail.ru (Kostya Alexandrov) Date: Mon, 13 Jan 2014 14:16:54 +0400 Subject: =?UTF-8?B?0KHQsdC+0YDQutCwIG5naW54INGBINC60LDRgdGC0L7QvNC90YvQvCBvcGVuc3Ns?= Message-ID: <52D3BD16.3080408@mail.ru> Господа, а нельзя ли добавить в докуметацию вариант сборки с кастомным openssl, как например http://erny-rev.blogspot.ru/2012/11/compile-nginx-with-custom-openssl-in.html на nginx.org не нашел даже --with-openssl Тема очень актуальна для владельцев линуксов типа CentOS 5 и т.п. From postmaster at softsearch.ru Mon Jan 13 10:41:54 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 13 Jan 2014 14:41:54 +0400 Subject: freebsd network tuning In-Reply-To: <52D3AE12.2020907@citrin.ru> References: <1845599893.20140112235531@softsearch.ru> <52D3AE12.2020907@citrin.ru> Message-ID: <1469339200.20140113144154@softsearch.ru> Здравствуйте, Anton. >> Признаюсь, что не заметил каких-то ощутимых ускорений от этого >> тюнинга, > Большая часть тюнинга не для ускорения, а для того, чтобы при > достижении определённой нагрузки X сервер не превратился в тыкву, > несмотря на то что свободная память ещё есть, а CPU загружен не на > 100%. > Соответственно нужно использовать утилиты для создания большой > нагрузки и смотреть какую максимальную нагрузку сервер может > выдержать с тюнингом и без. Ну сервер и так 600 мегабит отдаёт с настройками, которые Игорь тогда на конфе озвучивал. Думал, что, например, смена Congestion Control Algorithm, как описано тут http://dadv.livejournal.com/176159.html сильно поможет, но даже при больших буферах ничего не меняется. Как я понял, есть два основных вида тюнинга: для быстрой работы сервера и для безопасной работы. Т.е. работаешь с быстрой настройкой, а как начинают досить, переключаешься на безопасную. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Mon Jan 13 11:02:50 2014 From: nginx-forum at nginx.us (Sferg) Date: Mon, 13 Jan 2014 06:02:50 -0500 Subject: =?UTF-8?B?0JHQu9C+0LrQuNGA0L7QstC60LAg0LHQvtGC0L7Qsiwg0LfQsNGF0L7QtNGP0Yk=?= =?UTF-8?B?0LjRhSDQvdCwINGB0YLRgNCw0L3QuNGG0YMg0L/QviBJUC3QsNC00YDQtdGB?= =?UTF-8?B?0YMuINCS0L7Qt9C80L7QttC90L4g0LvQuD8=?= Message-ID: Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а видно, что периодически на страничку заходят боты не по доменному имени, а по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке по IP-адресу - чтоб только по доменному имени заходили, а по IP блокировались файрволом. С уважением, Геннадий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246311,246311#msg-246311 From chipitsine at gmail.com Mon Jan 13 11:25:05 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 13 Jan 2014 17:25:05 +0600 Subject: freebsd network tuning In-Reply-To: <1469339200.20140113144154@softsearch.ru> References: <1845599893.20140112235531@softsearch.ru> <52D3AE12.2020907@citrin.ru> <1469339200.20140113144154@softsearch.ru> Message-ID: настройка на 10Gb может быть единственным способом. берем, нагружаем 10Gb, смотрим, где узкое место и исправляем (без кунфу по части jmeter/gprof и подобных штук не обойтись) итерируем до достижения нужного эффекта. сайт calomel.org изобилует непонятно на чем основанными рекомендациями, порой такое чувство, что "лишь бы побольше накрутить". типичный пример (в стиле calomel.org) : http://habrahabr.ru/post/56497/ взяли, поставили epoll, зачем ? по дефолту был бы epoll и далее по списку без вникания, open_file_cache - это же почти наверняка способ отстрелить себе ногу. хоть одно упоминание о побочных последствиях ? а ведь народ яростно плюсует, копипастит и драгндропит настройки. без мониторинга и профилирования что-то настраивать - это пальцем в небо. 13 января 2014 г., 16:41 пользователь Михаил Монашёв написал: > Здравствуйте, Anton. > >>> Признаюсь, что не заметил каких-то ощутимых ускорений от этого >>> тюнинга, > >> Большая часть тюнинга не для ускорения, а для того, чтобы при >> достижении определённой нагрузки X сервер не превратился в тыкву, >> несмотря на то что свободная память ещё есть, а CPU загружен не на >> 100%. > >> Соответственно нужно использовать утилиты для создания большой >> нагрузки и смотреть какую максимальную нагрузку сервер может >> выдержать с тюнингом и без. > > Ну сервер и так 600 мегабит отдаёт с настройками, которые Игорь тогда > на конфе озвучивал. Думал, что, например, смена Congestion Control > Algorithm, как описано тут http://dadv.livejournal.com/176159.html > сильно поможет, но даже при больших буферах ничего не меняется. > > Как я понял, есть два основных вида тюнинга: для быстрой работы > сервера и для безопасной работы. Т.е. работаешь с быстрой настройкой, > а как начинают досить, переключаешься на безопасную. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From aa.vasilenko at gmail.com Mon Jan 13 11:39:42 2014 From: aa.vasilenko at gmail.com (Alex Vasilenko) Date: Mon, 13 Jan 2014 13:39:42 +0200 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQutCwINCx0L7RgtC+0LIsINC30LDRhdC+0LQ=?= =?UTF-8?B?0Y/RidC40YUg0L3QsCDRgdGC0YDQsNC90LjRhtGDINC/0L4gSVAt0LDQtNGA?= =?UTF-8?B?0LXRgdGDLiDQktC+0LfQvNC+0LbQvdC+INC70Lg/?= In-Reply-To: References: Message-ID: 13 января 2014 г., 13:02 пользователь Sferg написал: > Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а > видно, что периодически на страничку заходят боты не по доменному имени, а > по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке > по IP-адресу - чтоб только по доменному имени заходили, а по IP > блокировались файрволом. > > С уважением, Геннадий. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246311,246311#msg-246311 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Что iptables знает про внутренности http запроса? Ни-че-го. Можно сделать на уровне nginx. Catch-all для всех некорректных запросов (без хоста или с неизвестным хостом): server { listen 80 default_server; server_name _; return 444; } Документация - http://nginx.org/en/docs/http/server_names.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.hha at gmail.com Mon Jan 13 11:42:07 2014 From: alex.hha at gmail.com (Alex Domoradov) Date: Mon, 13 Jan 2014 13:42:07 +0200 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQutCwINCx0L7RgtC+0LIsINC30LDRhdC+0LQ=?= =?UTF-8?B?0Y/RidC40YUg0L3QsCDRgdGC0YDQsNC90LjRhtGDINC/0L4gSVAt0LDQtNGA?= =?UTF-8?B?0LXRgdGDLiDQktC+0LfQvNC+0LbQvdC+INC70Lg/?= In-Reply-To: References: Message-ID: Можно попробовать через string # iptables -I INPUT 1 -p tcp --dport 80 -m string --string "xxx.xxx.xxx.xxx" --algo kmp -j DROP Более подробно https://wiztelsys.com/blog/?p=16 На виртуалке по крайней мере работает 2014/1/13 Sferg : > Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а > видно, что периодически на страничку заходят боты не по доменному имени, а > по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке > по IP-адресу - чтоб только по доменному имени заходили, а по IP > блокировались файрволом. > > С уважением, Геннадий. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246311,246311#msg-246311 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From dmitriy at lyalyuev.info Mon Jan 13 11:43:21 2014 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Mon, 13 Jan 2014 13:43:21 +0200 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQutCwINCx0L7RgtC+0LIsINC30LDRhdC+0LQ=?= =?UTF-8?B?0Y/RidC40YUg0L3QsCDRgdGC0YDQsNC90LjRhtGDINC/0L4gSVAt0LDQtNGA?= =?UTF-8?B?0LXRgdGDLiDQktC+0LfQvNC+0LbQvdC+INC70Lg/?= In-Reply-To: References: Message-ID: <52D3D159.6070906@lyalyuev.info> Добрый день. Всегда интересовал вопрос наличия server_name в указанной конфигурации. В любом случае, если хост будет не указан или не относится к данному серверу он попадет в дефолт. Или я чего-то не верно понимаю и server_name таки тут обязательно должен присутствовать? 13.01.2014 13:39, Alex Vasilenko пишет: > 13 января 2014 г., 13:02 пользователь Sferg > написал: > > Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log > Nginx'а > видно, что периодически на страничку заходят боты не по доменному > имени, а > по IP-адресу. Возможно ли с помощью iptables ограничить доступ к > страничке > по IP-адресу - чтоб только по доменному имени заходили, а по IP > блокировались файрволом. > > С уважением, Геннадий. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246311,246311#msg-246311 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Что iptables знает про внутренности http запроса? Ни-че-го. > Можно сделать на уровне nginx. Catch-all для всех некорректных > запросов (без хоста или с неизвестным хостом): > server { > listen 80 default_server; > server_name _; > return 444; > } > Документация - http://nginx.org/en/docs/http/server_names.html > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Dmitriy Lyalyuev http://lyalyuev.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa.vasilenko at gmail.com Mon Jan 13 12:01:09 2014 From: aa.vasilenko at gmail.com (Alex Vasilenko) Date: Mon, 13 Jan 2014 14:01:09 +0200 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQutCwINCx0L7RgtC+0LIsINC30LDRhdC+0LQ=?= =?UTF-8?B?0Y/RidC40YUg0L3QsCDRgdGC0YDQsNC90LjRhtGDINC/0L4gSVAt0LDQtNGA?= =?UTF-8?B?0LXRgdGDLiDQktC+0LfQvNC+0LbQvdC+INC70Lg/?= In-Reply-To: <52D3D159.6070906@lyalyuev.info> References: <52D3D159.6070906@lyalyuev.info> Message-ID: 13 января 2014 г., 13:43 пользователь Dmitriy Lyalyuev < dmitriy at lyalyuev.info> написал: > Добрый день. > > Всегда интересовал вопрос наличия server_name в указанной конфигурации. В > любом случае, если хост будет не указан или не относится к данному серверу > он попадет в дефолт. Или я чего-то не верно понимаю и server_name таки тут > обязательно должен присутствовать? > server_name обязателен только для версий ниже 0.8.21. Выше - он необязателен и значение по умолчанию "". > 13.01.2014 13:39, Alex Vasilenko пишет: > > 13 января 2014 г., 13:02 пользователь Sferg написал: > >> Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а >> видно, что периодически на страничку заходят боты не по доменному имени, а >> по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке >> по IP-адресу - чтоб только по доменному имени заходили, а по IP >> блокировались файрволом. >> >> С уважением, Геннадий. >> >> Posted at Nginx Forum: >> http://forum.nginx.org/read.php?21,246311,246311#msg-246311 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Что iptables знает про внутренности http запроса? Ни-че-го. > Можно сделать на уровне nginx. Catch-all для всех некорректных запросов > (без хоста или с неизвестным хостом): > > server { > listen 80 default_server; > server_name _; > return 444; > } > > Документация - http://nginx.org/en/docs/http/server_names.html > > > _______________________________________________ > nginx-ru mailing listnginx-ru at nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Dmitriy Lyalyuevhttp://lyalyuev.info > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Jan 13 12:22:21 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 13 Jan 2014 16:22:21 +0400 Subject: =?UTF-8?Q?Re=3A_proxy=5Fcache=5Fkey_=D0=B8_fastcgi=5Fcache=5Fkey?= In-Reply-To: <1705428.JC99OxMjHr@vbart-laptop> References: <52CBE171.9070000@csdoc.com> <52CFC34E.10508@csdoc.com> <20140110154218.GQ1835@mdounin.ru> <1705428.JC99OxMjHr@vbart-laptop> Message-ID: <20140113122221.GS1835@mdounin.ru> Hello! On Fri, Jan 10, 2014 at 09:57:21PM +0400, Валентин Бартенев wrote: > On Friday 10 January 2014 19:42:18 Maxim Dounin wrote: > > Hello! > > > > On Fri, Jan 10, 2014 at 11:54:22AM +0200, Gena Makhomed wrote: > > > > > On 09.01.2014 16:33, Maxim Dounin wrote: > > > > > > >>>Смысл значения по умолчанию для proxy_cache_key состоит в том, что > > > >>>идентифицируется тот ресурс, куда осуществялется проксирование. > > > >> > > > >>>Тем самым, если в разных виртуальных серверах проксирование > > > >>>осуществляется в одно и то же место - будет использован > > > >>>один и тот же элемент кеша. > > > > > > Ситуация, когда все размещенные на одном сервере виртуальные хосты > > > имеют 100% идентичный контент и разные домены практически невозможна. > > > Такая настройка nginx сейчас может появиться только в результате ошибки. > > > > > > Еще дефолтовая настройка nginx на $proxy_host может быть полезной > > > тем, кто "грабит корованы", то есть показыват на своем сайте контент, > > > который был получен с других сайтов путем проксирования с кешированием. > > > > Например, это может быть отдельный location под общие элементы > > и/или ssi-инклуды. Именно под такие задачи оно исходно и > > программировалось, и именно потому и стоят такие значения по > > умолчанию - запрашиваем с бекенда то, что указано в proxy_pass, и > > кешируем то, что запрашивали. > > > > Просто следует понимать, что задач - больше одной. И хорошее > > решение для одной задачи - может оказаться плохим для другой. > > > > Проблема, на самом деле, в том, что прописанное в конфиге > > "proxy_set_header Host $host" существенно меняет суть запроса к > > бекенду, а значение по умолчанию proxy_cache_key об этом изменении > > не знает, его надо обучать этому вручную. Возможно, именно с этой > > стороны и следует подойти к этому вопросу. > > > [..] > > Лично мне нравится идея привести значение proxy_cache_key по умолчанию > к таковому fastcgi_cache_key, т.е. отсутствует и требуется задавать явно. > > ИМХО это полезно, как с точки зрения понятности конфига, так и с точки > зрения унификации между различными upstream-модулями. Нет, я против. В http кешируемость определена достаточно хорошо, и идентификация запрашиваемого документа - это хороший, годный метод кеширования. Заставлять пользователя самостоятельно изобретать ключ кеширования - это негодный с точки зрения удобства использования вариант. -- Maxim Dounin http://nginx.org/ From alex.hha at gmail.com Mon Jan 13 13:15:50 2014 From: alex.hha at gmail.com (Alex Domoradov) Date: Mon, 13 Jan 2014 15:15:50 +0200 Subject: freebsd network tuning In-Reply-To: References: <1845599893.20140112235531@softsearch.ru> <52D3AE12.2020907@citrin.ru> <1469339200.20140113144154@softsearch.ru> Message-ID: Вот сколько раз встерчал такое - да там фигня в статье, кто так делает, надо так и так, это же очевидно. Вот нет бы, потратить 2 часа своего времени, взять и написать "правильную" статью с объяснением что и зачем. Нет же, все будут кусаться, колоться, но ... 2014/1/13 Илья Шипицин : > настройка на 10Gb может быть единственным способом. > берем, нагружаем 10Gb, смотрим, где узкое место и исправляем (без > кунфу по части jmeter/gprof и подобных штук не обойтись) > итерируем до достижения нужного эффекта. > > сайт calomel.org изобилует непонятно на чем основанными > рекомендациями, порой такое чувство, что "лишь бы побольше накрутить". > > типичный пример (в стиле calomel.org) : http://habrahabr.ru/post/56497/ > взяли, поставили epoll, зачем ? по дефолту был бы epoll > и далее по списку без вникания, open_file_cache - это же почти > наверняка способ отстрелить себе ногу. хоть одно упоминание о побочных > последствиях ? > а ведь народ яростно плюсует, копипастит и драгндропит настройки. > > > без мониторинга и профилирования что-то настраивать - это пальцем в небо. > > > 13 января 2014 г., 16:41 пользователь Михаил Монашёв > написал: >> Здравствуйте, Anton. >> >>>> Признаюсь, что не заметил каких-то ощутимых ускорений от этого >>>> тюнинга, >> >>> Большая часть тюнинга не для ускорения, а для того, чтобы при >>> достижении определённой нагрузки X сервер не превратился в тыкву, >>> несмотря на то что свободная память ещё есть, а CPU загружен не на >>> 100%. >> >>> Соответственно нужно использовать утилиты для создания большой >>> нагрузки и смотреть какую максимальную нагрузку сервер может >>> выдержать с тюнингом и без. >> >> Ну сервер и так 600 мегабит отдаёт с настройками, которые Игорь тогда >> на конфе озвучивал. Думал, что, например, смена Congestion Control >> Algorithm, как описано тут http://dadv.livejournal.com/176159.html >> сильно поможет, но даже при больших буферах ничего не меняется. >> >> Как я понял, есть два основных вида тюнинга: для быстрой работы >> сервера и для безопасной работы. Т.е. работаешь с быстрой настройкой, >> а как начинают досить, переключаешься на безопасную. >> >> -- >> С уважением, >> Михаил 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 alex.hha at gmail.com Mon Jan 13 14:11:26 2014 From: alex.hha at gmail.com (Alex Domoradov) Date: Mon, 13 Jan 2014 16:11:26 +0200 Subject: =?UTF-8?B?UmU6INCh0LHQvtGA0LrQsCBuZ2lueCDRgSDQutCw0YHRgtC+0LzQvdGL0Lwgb3Bl?= =?UTF-8?B?bnNzbA==?= In-Reply-To: <52D3BD16.3080408@mail.ru> References: <52D3BD16.3080408@mail.ru> Message-ID: в 1.0.15 точно есть # ./configure --help | grep openssl --with-openssl=DIR set path to OpenSSL library sources --with-openssl-opt=OPTIONS set additional build options for OpenSSL 2014/1/13 Kostya Alexandrov : > Господа, а нельзя ли добавить в докуметацию вариант сборки с кастомным > openssl, как например > http://erny-rev.blogspot.ru/2012/11/compile-nginx-with-custom-openssl-in.html > на nginx.org не нашел даже --with-openssl Тема очень актуальна для > владельцев линуксов типа CentOS 5 и т.п. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vladimir at skubriev.ru Mon Jan 13 15:22:30 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Mon, 13 Jan 2014 19:22:30 +0400 Subject: =?UTF-8?B?0LTQstC1INCQINC30LDQv9C40YHQuCDQsiBETlMgLSDQsdGD0LTQtdGCINC70Lgg?= =?UTF-8?B?0YLQvtGA0LzQvtC30LjRgtGMLCDQtdGB0LvQuCDQvtC00LjQvSDQuNC3INC/?= =?UTF-8?B?0YDQvtCy0LDQudC00LXRgNC+0LIg0L7RgtCy0LDQu9C40YLRgdGPID8=?= Message-ID: <52D404B6.40809@skubriev.ru> Добрый день Есть сервер с двумя подключенными провайдерами. На данный момент он может работать только с одним из подключений. Т.е. iproute2 не используется. И для переключения между провайдерами меняется шлюз по умолчанию и перезапускаются правила NAT. Сейчас для узла website.example.com в DNS прописан только IP первого и основного провайдера. Вопрос: Если сделать еще одну запись А на IP второго провайдера, но при этом этот второй провайдер будет отключен как будет работать соединение с веб сервером и севером вообще? Как вообще клиенты будут работать нормально или же если не предсказуемо ? Спасибо. -- -- Faithfully yours, Vladimir Skubriev From chipitsine at gmail.com Mon Jan 13 15:39:47 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 13 Jan 2014 21:39:47 +0600 Subject: freebsd network tuning In-Reply-To: References: <1845599893.20140112235531@softsearch.ru> <52D3AE12.2020907@citrin.ru> <1469339200.20140113144154@softsearch.ru> Message-ID: ок :-) договорились 13 января 2014 г., 19:15 пользователь Alex Domoradov написал: > Вот сколько раз встерчал такое - да там фигня в статье, кто так > делает, надо так и так, это же очевидно. Вот нет бы, потратить 2 часа > своего времени, взять и написать "правильную" статью с объяснением что > и зачем. Нет же, все будут кусаться, колоться, но ... > > 2014/1/13 Илья Шипицин : >> настройка на 10Gb может быть единственным способом. >> берем, нагружаем 10Gb, смотрим, где узкое место и исправляем (без >> кунфу по части jmeter/gprof и подобных штук не обойтись) >> итерируем до достижения нужного эффекта. >> >> сайт calomel.org изобилует непонятно на чем основанными >> рекомендациями, порой такое чувство, что "лишь бы побольше накрутить". >> >> типичный пример (в стиле calomel.org) : http://habrahabr.ru/post/56497/ >> взяли, поставили epoll, зачем ? по дефолту был бы epoll >> и далее по списку без вникания, open_file_cache - это же почти >> наверняка способ отстрелить себе ногу. хоть одно упоминание о побочных >> последствиях ? >> а ведь народ яростно плюсует, копипастит и драгндропит настройки. >> >> >> без мониторинга и профилирования что-то настраивать - это пальцем в небо. >> >> >> 13 января 2014 г., 16:41 пользователь Михаил Монашёв >> написал: >>> Здравствуйте, Anton. >>> >>>>> Признаюсь, что не заметил каких-то ощутимых ускорений от этого >>>>> тюнинга, >>> >>>> Большая часть тюнинга не для ускорения, а для того, чтобы при >>>> достижении определённой нагрузки X сервер не превратился в тыкву, >>>> несмотря на то что свободная память ещё есть, а CPU загружен не на >>>> 100%. >>> >>>> Соответственно нужно использовать утилиты для создания большой >>>> нагрузки и смотреть какую максимальную нагрузку сервер может >>>> выдержать с тюнингом и без. >>> >>> Ну сервер и так 600 мегабит отдаёт с настройками, которые Игорь тогда >>> на конфе озвучивал. Думал, что, например, смена Congestion Control >>> Algorithm, как описано тут http://dadv.livejournal.com/176159.html >>> сильно поможет, но даже при больших буферах ничего не меняется. >>> >>> Как я понял, есть два основных вида тюнинга: для быстрой работы >>> сервера и для безопасной работы. Т.е. работаешь с быстрой настройкой, >>> а как начинают досить, переключаешься на безопасную. >>> >>> -- >>> С уважением, >>> Михаил 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 From onokonem at gmail.com Mon Jan 13 16:41:41 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 13 Jan 2014 20:41:41 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D404B6.40809@skubriev.ru> References: <52D404B6.40809@skubriev.ru> Message-ID: > Если сделать еще одну запись А на IP второго провайдера, но при этом этот > второй провайдер будет отключен как будет работать соединение с веб сервером > и севером вообще? > Как вообще клиенты будут работать нормально или же если не предсказуемо ? Половина попыток подключиться будет обламываться по таймауту. From vladimir at skubriev.ru Mon Jan 13 16:45:19 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Mon, 13 Jan 2014 20:45:19 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> Message-ID: <52D4181F.3050608@skubriev.ru> 13.01.2014 20:41, Daniel Podolsky пишет: >> Если сделать еще одну запись А на IP второго провайдера, но при этом этот >> второй провайдер будет отключен как будет работать соединение с веб сервером >> и севером вообще? >> Как вообще клиенты будут работать нормально или же если не предсказуемо ? > Половина попыток подключиться будет обламываться по таймауту. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru т.е. это не дело для продакшена ? в итоге клиенты будут не довольны ? -- -- Faithfully yours, Vladimir Skubriev From onokonem at gmail.com Mon Jan 13 17:45:15 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 13 Jan 2014 21:45:15 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D4181F.3050608@skubriev.ru> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> Message-ID: > т.е. это не дело для продакшена ? > в итоге клиенты будут не довольны ? да и да. From alex.hha at gmail.com Mon Jan 13 17:45:18 2014 From: alex.hha at gmail.com (Alex Domoradov) Date: Mon, 13 Jan 2014 19:45:18 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D4181F.3050608@skubriev.ru> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> Message-ID: Какждый второй приход в магазин он будет закрыт в рабочее время. Вас это устроит? После какого раза вы прекратите ходить в него? 2014/1/13 Vladimir Skubriev : > 13.01.2014 20:41, Daniel Podolsky пишет: > >>> Если сделать еще одну запись А на IP второго провайдера, но при этом этот >>> второй провайдер будет отключен как будет работать соединение с веб >>> сервером >>> и севером вообще? >>> Как вообще клиенты будут работать нормально или же если не предсказуемо ? >> >> Половина попыток подключиться будет обламываться по таймауту. >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > т.е. это не дело для продакшена ? > > в итоге клиенты будут не довольны ? > > > -- > -- > Faithfully yours, > > Vladimir Skubriev > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vovansystems at gmail.com Mon Jan 13 17:46:46 2014 From: vovansystems at gmail.com (VovansystemS) Date: Mon, 13 Jan 2014 20:46:46 +0300 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D4181F.3050608@skubriev.ru> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> Message-ID: >> Половина попыток подключиться будет обламываться по таймауту. > в итоге клиенты будут не довольны ? да. я уже много лет с нетерпением жду того момента, когда браузеры научатся понимать SRV записи типа а они имеют вид: _service._proto.name. TTL class SRV priority weight port target. т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с mx записями - задавать вес для айпишников так: _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. тогда будет счастье и отказоустойчивость без ботлнеков.. From sergey.kobzar at itcraft.org Mon Jan 13 18:17:34 2014 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 13 Jan 2014 20:17:34 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> Message-ID: <52D42DBE.3070409@itcraft.org> On 01/13/14 19:46, VovansystemS wrote: >>> Половина попыток подключиться будет обламываться по таймауту. >> в итоге клиенты будут не довольны ? > > да. я уже много лет с нетерпением жду того момента, когда браузеры > научатся понимать SRV записи типа а они имеют вид: > > _service._proto.name. TTL class SRV priority weight port target. > т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с > mx записями - задавать вес для айпишников так: > > _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. > _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. > > тогда будет счастье и отказоустойчивость без ботлнеков.. Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. Естественно NS сервер должен быть где-то в ДЦ. Кстати, готовые решения есть? А то постоянно приходиться самому че-то сочинять. From vbart at nginx.com Mon Jan 13 18:22:44 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 13 Jan 2014 22:22:44 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D42DBE.3070409@itcraft.org> References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> Message-ID: <1967078.pRY3lv2aJc@vbart-laptop> On Monday 13 January 2014 20:17:34 Sergey Kobzar wrote: > On 01/13/14 19:46, VovansystemS wrote: > >>> Половина попыток подключиться будет обламываться по таймауту. > >> в итоге клиенты будут не довольны ? > > > > да. я уже много лет с нетерпением жду того момента, когда браузеры > > научатся понимать SRV записи типа а они имеют вид: > > > > _service._proto.name. TTL class SRV priority weight port target. > > т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с > > mx записями - задавать вес для айпишников так: > > > > _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. > > _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. > > > > тогда будет счастье и отказоустойчивость без ботлнеков.. > > Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. > Естественно NS сервер должен быть где-то в ДЦ. [..] Едва ли это можно назвать "фэловер" при ненулевом TTL. -- Валентин Бартенев From vovansystems at gmail.com Mon Jan 13 18:30:27 2014 From: vovansystems at gmail.com (VovansystemS) Date: Mon, 13 Jan 2014 21:30:27 +0300 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D42DBE.3070409@itcraft.org> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> Message-ID: > Кстати, готовые решения есть? А то постоянно приходиться самому че-то > сочинять. есть route 53 амазона, он умеет проверять на доступность и изменять днс записи по соответствующим правилам. > Едва ли это можно назвать "фэловер" при ненулевом TTL. да :( From sergey.kobzar at itcraft.org Mon Jan 13 18:55:54 2014 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 13 Jan 2014 20:55:54 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <1967078.pRY3lv2aJc@vbart-laptop> References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> Message-ID: <52D436BA.2070302@itcraft.org> On 01/13/14 20:22, Валентин Бартенев wrote: > On Monday 13 January 2014 20:17:34 Sergey Kobzar wrote: >> On 01/13/14 19:46, VovansystemS wrote: >>>>> Половина попыток подключиться будет обламываться по таймауту. >>>> в итоге клиенты будут не довольны ? >>> >>> да. я уже много лет с нетерпением жду того момента, когда браузеры >>> научатся понимать SRV записи типа а они имеют вид: >>> >>> _service._proto.name. TTL class SRV priority weight port target. >>> т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с >>> mx записями - задавать вес для айпишников так: >>> >>> _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. >>> _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. >>> >>> тогда будет счастье и отказоустойчивость без ботлнеков.. >> >> Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. >> Естественно NS сервер должен быть где-то в ДЦ. > [..] > > Едва ли это можно назвать "фэловер" при ненулевом TTL. Данное решение все-же лучше, чем ничего. Рад выслушать альтернативные решения, которые работают вне пределов одного датацентра. From sergey.kobzar at itcraft.org Mon Jan 13 18:57:10 2014 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 13 Jan 2014 20:57:10 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> Message-ID: <52D43706.30605@itcraft.org> On 01/13/14 20:30, VovansystemS wrote: >> Кстати, готовые решения есть? А то постоянно приходиться самому че-то >> сочинять. > есть route 53 амазона, он умеет проверять на доступность и изменять > днс записи по соответствующим правилам. Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще не столько много зарабатываем ;). > >> Едва ли это можно назвать "фэловер" при ненулевом TTL. > да :( > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From koticka at mail.ru Mon Jan 13 21:17:25 2014 From: koticka at mail.ru (Kostya Alexandrov) Date: Tue, 14 Jan 2014 01:17:25 +0400 Subject: =?UTF-8?B?UmU6INCh0LHQvtGA0LrQsCBuZ2lueCDRgSDQutCw0YHRgtC+0LzQvdGL0Lwgb3Bl?= =?UTF-8?B?bnNzbA==?= In-Reply-To: References: <52D3BD16.3080408@mail.ru> Message-ID: <52D457E5.8050200@mail.ru> Про --help незнал, каюсь, однако же без хака # edit auto/lib/openssl/conf manually or use sed sed -i -e 's|\.openssl/||' auto/lib/openssl/conf собрать у меня не удалось On 13.01.14, 18:11, Alex Domoradov wrote: > в 1.0.15 точно есть > # ./configure --help | grep openssl > --with-openssl=DIR set path to OpenSSL library sources > --with-openssl-opt=OPTIONS set additional build options for OpenSSL > > 2014/1/13 Kostya Alexandrov : >> Господа, а нельзя ли добавить в докуметацию вариант сборки с кастомным >> openssl, как например >> http://erny-rev.blogspot.ru/2012/11/compile-nginx-with-custom-openssl-in.html >> на nginx.org не нашел даже --with-openssl Тема очень актуальна для >> владельцев линуксов типа CentOS 5 и т.п. >> >> _______________________________________________ >> 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 vsjcfm at gmail.com Mon Jan 13 21:17:54 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Mon, 13 Jan 2014 23:17:54 +0200 Subject: =?UTF-8?B?0J7RgtC00LDRh9CwINCx0L7Qu9GM0YjQuNGFINGE0LDQudC70L7Qsg==?= Message-ID: Приветствую! Собственно, планируется сабж в ближайшем будущем. Размеры файлов - от 1 до 8-10 ГиБ, 400-500 сессий до 2-3 коннектов на сессию, траф - 4-5 ГБит/сек. Последние два параметра в перспективе могут вырасти ориентировочно до двух раз. Ось - FreeBSD, ФС - ZFS. Есть ли общие рекомендации настройки nginx для подобных конфигураций? Размер/кол-во буферов, метод отдачи файлов и т.п. From postmaster at softsearch.ru Mon Jan 13 21:36:13 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 Jan 2014 01:36:13 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: References: Message-ID: <865058976.20140114013613@softsearch.ru> Здравствуйте, Anton. > Собственно, планируется сабж в ближайшем будущем. > Размеры файлов - от 1 до 8-10 ГиБ, 400-500 сессий до 2-3 коннектов на > сессию, траф - 4-5 ГБит/сек. Последние два параметра в перспективе > могут вырасти ориентировочно до двух раз. Ось - FreeBSD, ФС - ZFS. > Есть ли общие рекомендации настройки nginx для подобных конфигураций? > Размер/кол-во буферов, метод отдачи файлов и т.п. Вот тут об этом хорошо и подробно написано: http://goo.gl/Szvbiy -- С уважением, Михаил mailto:postmaster at softsearch.ru From vsjcfm at gmail.com Mon Jan 13 21:39:23 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Mon, 13 Jan 2014 23:39:23 +0200 Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: <865058976.20140114013613@softsearch.ru> References: <865058976.20140114013613@softsearch.ru> Message-ID: 13 января 2014 г., 23:36 пользователь Михаил Монашёв написал: > Вот тут об этом хорошо и подробно написано: http://goo.gl/Szvbiy Очень остроумно. Кстати, Вы забыли указать в запросе ещё два слова - ОС и ФС. Но боюсь, что меня больше интересует практический опыт людей, присутствующих в данной рассылке, именно поэтому письмо и было написано (что нисколько не отменяет поисковых запросов). From vsjcfm at gmail.com Mon Jan 13 21:41:35 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Mon, 13 Jan 2014 23:41:35 +0200 Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: References: <865058976.20140114013613@softsearch.ru> Message-ID: 13 января 2014 г., 23:39 пользователь Anton Sayetsky написал: > 13 января 2014 г., 23:36 пользователь Михаил Монашёв > написал: >> Вот тут об этом хорошо и подробно написано: http://goo.gl/Szvbiy > Очень остроумно. Кстати, Вы забыли указать в запросе ещё два слова - ОС и ФС. > Но боюсь, что меня больше интересует практический опыт людей, > присутствующих в данной рассылке, именно поэтому письмо и было > написано (что нисколько не отменяет поисковых запросов). Да, КС site: я вижу. Забыл уточнить, что интересует более новый опыт, нежели 2009-го года, коих результатов больше всего. ;) From postmaster at softsearch.ru Mon Jan 13 21:46:02 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 Jan 2014 01:46:02 +0400 Subject: =?UTF-8?B?UmVbMl06INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: References: <865058976.20140114013613@softsearch.ru> Message-ID: <1936200573.20140114014602@softsearch.ru> Здравствуйте, Anton. >> Вот тут об этом хорошо и подробно написано: http://goo.gl/Szvbiy > Очень остроумно. За 4 минуты 6 переходов, однако! :-) > Кстати, Вы забыли указать в запросе ещё два слова - ОС и ФС. Но > боюсь, что меня больше интересует практический опыт людей, > присутствующих в данной рассылке, именно поэтому письмо и было > написано (что нисколько не отменяет поисковых запросов). А все, кто писал ранее, - теоретики, не стоящие Вашего внимания. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Mon Jan 13 21:48:10 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 Jan 2014 01:48:10 +0400 Subject: =?UTF-8?B?UmVbMl06INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: References: <865058976.20140114013613@softsearch.ru> Message-ID: <1508832332.20140114014810@softsearch.ru> Здравствуйте, Anton. > Да, КС site: я вижу. Забыл уточнить, что интересует более новый опыт, > нежели 2009-го года, коих результатов больше всего. ;) Всё с точностью до наоборот. Раньше и зима была больше на зиму похожа. И девки краше. Особенно в 2009-ом. А сейчас уже всё не то, что раньше. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vsjcfm at gmail.com Mon Jan 13 21:54:46 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Mon, 13 Jan 2014 23:54:46 +0200 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQntGC0LTQsNGH0LAg0LHQvtC70YzRiNC40YUg0YTQsNC50Ls=?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <1936200573.20140114014602@softsearch.ru> References: <865058976.20140114013613@softsearch.ru> <1936200573.20140114014602@softsearch.ru> Message-ID: 13 января 2014 г., 23:46 пользователь Михаил Монашёв написал: > А все, кто писал ранее, - теоретики, не стоящие Вашего внимания. За 5 лет разве ничего не изменилось ни во FreeBSD, ни в nginx? Кстати, если по указанной ссылке добавить дату "с 01.01.2013", то релевантных результатов как-то и нет... Впрочем, это лишь переливание из. Писать текст в строку поиска я умею и так, а нового опыта (хотя бы за прошедший год) Вами не предложено. From vbart at nginx.com Mon Jan 13 22:51:40 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 14 Jan 2014 02:51:40 +0400 Subject: =?UTF-8?B?UmU6INCh0LHQvtGA0LrQsCBuZ2lueCDRgSDQutCw0YHRgtC+0LzQvdGL0Lwgb3Bl?= =?UTF-8?B?bnNzbA==?= In-Reply-To: <52D457E5.8050200@mail.ru> References: <52D3BD16.3080408@mail.ru> <52D457E5.8050200@mail.ru> Message-ID: <2326624.njZLtf11n7@vbart-laptop> On Tuesday 14 January 2014 01:17:25 Kostya Alexandrov wrote: > Про --help незнал, каюсь, однако же без хака > # edit auto/lib/openssl/conf manually or use sed > sed -i -e 's|\.openssl/||' auto/lib/openssl/conf > > собрать у меня не удалось [..] А не нужно было следовать приведенному руководству и собирать OpenSSL самостоятельно. Всё, что было нужно - это скачать архив с исходниками OpenSSL, распаковать, и просто указать в --with-openssl=DIR вместо DIR путь к исходникам. -- Валентин Бартенев From koticka at mail.ru Mon Jan 13 23:06:13 2014 From: koticka at mail.ru (Kostya Alexandrov) Date: Tue, 14 Jan 2014 03:06:13 +0400 Subject: =?UTF-8?B?UmU6INCh0LHQvtGA0LrQsCBuZ2lueCDRgSDQutCw0YHRgtC+0LzQvdGL0Lwgb3Bl?= =?UTF-8?B?bnNzbA==?= In-Reply-To: <2326624.njZLtf11n7@vbart-laptop> References: <52D3BD16.3080408@mail.ru> <52D457E5.8050200@mail.ru> <2326624.njZLtf11n7@vbart-laptop> Message-ID: <52D47165.6070506@mail.ru> Валентин, возможно я не прав, но вот если бы я это увидел в доке к ssl модулю, то флейма и дурных вопросов не задавал бы, заодно бы час-другой сэкономил бы себе, думаю человек, написавший то руководство так же как и я бодался с тем чтоб собрать nginx с кастомным openssl. Скажем так, для себя я проблему решил, и мне кажется, что "будущим покалениям" было бы неплохо получить эти сокральные знания без гугла и десятка дурных и вредных советов, типа ставит пакеты от centos 6.5 с нодепс и тп. Решайте сами стоит ли добавить пару строк доки или нет. On 14.01.14, 2:51, Валентин Бартенев wrote: > On Tuesday 14 January 2014 01:17:25 Kostya Alexandrov wrote: >> Про --help незнал, каюсь, однако же без хака >> # edit auto/lib/openssl/conf manually or use sed >> sed -i -e 's|\.openssl/||' auto/lib/openssl/conf >> >> собрать у меня не удалось > [..] > > А не нужно было следовать приведенному руководству и собирать OpenSSL > самостоятельно. > > Всё, что было нужно - это скачать архив с исходниками OpenSSL, распаковать, > и просто указать в --with-openssl=DIR вместо DIR путь к исходникам. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vsjcfm at gmail.com Mon Jan 13 23:35:02 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Tue, 14 Jan 2014 01:35:02 +0200 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQntGC0LTQsNGH0LAg0LHQvtC70YzRiNC40YUg0YTQsNC50Ls=?= =?UTF-8?B?0L7Qsg==?= Message-ID: 14 января 2014 г., 1:27 пользователь Oleksandr V. Typlyns'kyi > Тут вопрос скорее для рассылки FreeBSD. Ну, думаю, что скорее для обоих рассылок. В текущую для начала написал, поскольку прежде всего интересует настройка nginx, а не оси. > Особенно если смотреть со словом Netflix: > http://people.freebsd.org/~scottl/Netflix-BSDCan-20130515.pdf А вот за это благодарю! Похоже, что это весьма интересный документ для меня. From gmm at csdoc.com Tue Jan 14 00:42:44 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 14 Jan 2014 02:42:44 +0200 Subject: =?UTF-8?Q?nginx_=D0=B8_RFC?= In-Reply-To: <2258243.kZVRnG2y6t@vbart-laptop> References: <52CEAABF.6030504@csdoc.com> <3218886.BekFLRDj5N@vbart-laptop> <52CFDD57.5040502@csdoc.com> <2258243.kZVRnG2y6t@vbart-laptop> Message-ID: <52D48804.6050807@csdoc.com> On 10.01.2014 14:53, Валентин Бартенев wrote: >>> Так, между делом, хочу напомнить, что на CGI есть спецификация, >>> описывающая все переменные окружения, которые сервер должен передавать >>> приложению. И в ней вполне черным по белому сказано, что все переменные >>> HTTP_* это protocol specific переменные полученные >>> из заголовков переданных клиентом. Проблема со спецификацией CGI/1.1 в том, что она была создана в тот момент, когда существовал только протокол HTTP/1.0 А в протоколе HTTP/1.0 единственным источником имени хоста является заголовок Host:, такого понятия как "absolute URI" в протоколе HTTP/1.0 вообще не существует. Потому так и написано. Когда спецификацию CGI/1.1 публиковали в виде RFC - эту ошибку/неточность исправить забыли. Что и стало причиной путаницы и этих недоразумений, поскольку спецификация CGI/1.1 предполагает, что все запросы от клиентов приходят на сервер только по протоколу HTTP/1.0, а они оказывается теперь могут приходить и по протоколу HTTP/1.1, где правила определения имени виртуального хоста уже стали несколько другими. В HTTP/1.0 переменная HTTP_HOST работала всегда нормально, а в HTTP/1.1 этот механизм работает не всегда как ожидалось. Вот все отличия между версиями HTTP/1.0 и HTTP/1.1: http://tools.ietf.org/search/rfc2616#section-19.6.1 Кстати, там есть интересные требования: - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header. - Servers MUST accept absolute URIs. ================================================================ Можно ли nginx исправить так, чтобы он передавал на backend по FastCGI в переменной HTTP_HOST имя хоста, к которому клиент сделал свой запрос вне зависимости от того, где оно было задано в исходном запросе, - в заголовке Host: (протокол HTTP/1.0) или в виде host part of the Request-URI (протокол HTTP/1.1) ? Или для этого надо сначала исправить спецификацию CGI/1.1 и только потом можно будет этот BUG исправить и в nginx ? ================================================================ > Если заголовка Host в запросе вообще не будет, то и переменной HTTP_HOST > быть также не должно. Каким образом это согласуется с RFC 2616 ? Там ведь в section-19.6.1 черным по белому написано, что тогда сервер MUST возвращать 400 ошибку. В 5.2 также требуется, что если пришел запрос и это is not a valid host on the server, the response MUST be a 400 (Bad Request) error message. Вот уже на ровном месте два случая, где nginx нарушает требования RFC. Это как, нормально? -- Best regards, Gena From kostenl at gmail.com Tue Jan 14 04:17:37 2014 From: kostenl at gmail.com (=?koi8-r?B?7MHQz97Lyc4g68/O09TBztTJzg==?=) Date: Tue, 14 Jan 2014 10:17:37 +0600 Subject: =?UTF-8?B?UkU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D43706.30605@itcraft.org> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> Message-ID: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> Можно организовать схему, когда живость сайта будет проверять сам ДНС. Описание http://habrahabr.ru/post/177145/ -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Sergey Kobzar Sent: Tuesday, January 14, 2014 12:57 AM To: nginx-ru at nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? On 01/13/14 20:30, VovansystemS wrote: >> Кстати, готовые решения есть? А то постоянно приходиться самому >> че-то сочинять. > есть route 53 амазона, он умеет проверять на доступность и изменять > днс записи по соответствующим правилам. Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще не столько много зарабатываем ;). > >> Едва ли это можно назвать "фэловер" при ненулевом TTL. > да :( > _______________________________________________ > 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 vladimir at skubriev.ru Tue Jan 14 04:39:33 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 08:39:33 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> Message-ID: <52D4BF85.5000603@skubriev.ru> 13.01.2014 21:46, VovansystemS пишет: >>> Половина попыток подключиться будет обламываться по таймауту. >> в итоге клиенты будут не довольны ? > да. я уже много лет с нетерпением жду того момента, когда браузеры > научатся понимать SRV записи типа а они имеют вид: > > _service._proto.name. TTL class SRV priority weight port target. > т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с > mx записями - задавать вес для айпишников так: > > _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. > _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. > > тогда будет счастье и отказоустойчивость без ботлнеков.. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Странно что уже много лет. Видимо это кому то нужно ( Всмысле существования и процветания бот нет сетей. Если я конечно правильно понимаю этот вопрос. -- -- Faithfully yours, Vladimir Skubriev From vladimir at skubriev.ru Tue Jan 14 04:40:23 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 08:40:23 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <1967078.pRY3lv2aJc@vbart-laptop> References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> Message-ID: <52D4BFB7.9050809@skubriev.ru> 13.01.2014 22:22, Валентин Бартенев пишет: > On Monday 13 January 2014 20:17:34 Sergey Kobzar wrote: >> On 01/13/14 19:46, VovansystemS wrote: >>>>> Половина попыток подключиться будет обламываться по таймауту. >>>> в итоге клиенты будут не довольны ? >>> да. я уже много лет с нетерпением жду того момента, когда браузеры >>> научатся понимать SRV записи типа а они имеют вид: >>> >>> _service._proto.name. TTL class SRV priority weight port target. >>> т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с >>> mx записями - задавать вес для айпишников так: >>> >>> _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. >>> _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. >>> >>> тогда будет счастье и отказоустойчивость без ботлнеков.. >> Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. >> Естественно NS сервер должен быть где-то в ДЦ. > [..] > > Едва ли это можно назвать "фэловер" при ненулевом TTL. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru А нулевой TTL используется? -- -- Faithfully yours, Vladimir Skubriev From vladimir at skubriev.ru Tue Jan 14 04:43:07 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 08:43:07 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> Message-ID: <52D4C05B.8050903@skubriev.ru> 14.01.2014 08:17, Лапочкин Константин пишет: > Можно организовать схему, когда живость сайта будет проверять сам ДНС. > Описание http://habrahabr.ru/post/177145/ > > -----Original Message----- > From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On > Behalf Of Sergey Kobzar > Sent: Tuesday, January 14, 2014 12:57 AM > To: nginx-ru at nginx.org > Subject: Re: две А записи в DNS - будет ли тормозить, если один из > провайдеров отвалится ? > > On 01/13/14 20:30, VovansystemS wrote: >>> Кстати, готовые решения есть? А то постоянно приходиться самому >>> че-то сочинять. >> есть route 53 амазона, он умеет проверять на доступность и изменять >> днс записи по соответствующим правилам. > Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще не > столько много зарабатываем ;). > >>> Едва ли это можно назвать "фэловер" при ненулевом TTL. >> да :( >> _______________________________________________ >> 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 Спасибо. Очень хорошая подсказка. Только вопрос: Ведь здесь описывается несколько дата центров. В моем варианте - это не вариант. У меня просто двай провайдера и серверная в одном здании. В таком случае как лучше организовать доступ к сайту компании, при наличии двух провайдеров? -- -- Faithfully yours, Vladimir Skubriev From kostenl at gmail.com Tue Jan 14 05:11:30 2014 From: kostenl at gmail.com (=?koi8-r?B?7MHQz97Lyc4g68/O09TBztTJzg==?=) Date: Tue, 14 Jan 2014 11:11:30 +0600 Subject: =?UTF-8?B?UkU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D4C05B.8050903@skubriev.ru> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> Message-ID: <005301cf10e7$167b1a90$43714fb0$@gmail.com> У вас даже всё проще. В случае с 2-я датацентрами, вам надо организовывать репликацию. В вашем случае - нет. Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns сервер и на запрос site.com отдавал свой белый ип. Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. Остальное по статье. Если днс провайдера видит, что dns сервер на x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут на y.y.y.y. -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Vladimir Skubriev Sent: Tuesday, January 14, 2014 10:43 AM To: nginx-ru at nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? 14.01.2014 08:17, Лапочкин Константин пишет: > Можно организовать схему, когда живость сайта будет проверять сам ДНС. > Описание http://habrahabr.ru/post/177145/ > > -----Original Message----- > From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] > On Behalf Of Sergey Kobzar > Sent: Tuesday, January 14, 2014 12:57 AM > To: nginx-ru at nginx.org > Subject: Re: две А записи в DNS - будет ли тормозить, если один из > провайдеров отвалится ? > > On 01/13/14 20:30, VovansystemS wrote: >>> Кстати, готовые решения есть? А то постоянно приходиться самому >>> че-то сочинять. >> есть route 53 амазона, он умеет проверять на доступность и изменять >> днс записи по соответствующим правилам. > Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще > не столько много зарабатываем ;). > >>> Едва ли это можно назвать "фэловер" при ненулевом TTL. >> да :( >> _______________________________________________ >> 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 Спасибо. Очень хорошая подсказка. Только вопрос: Ведь здесь описывается несколько дата центров. В моем варианте - это не вариант. У меня просто двай провайдера и серверная в одном здании. В таком случае как лучше организовать доступ к сайту компании, при наличии двух провайдеров? -- -- Faithfully yours, Vladimir Skubriev _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru From vladimir at skubriev.ru Tue Jan 14 05:21:26 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 09:21:26 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <005301cf10e7$167b1a90$43714fb0$@gmail.com> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> Message-ID: <52D4C956.1090107@skubriev.ru> 14.01.2014 09:11, Лапочкин Константин пишет: > У вас даже всё проще. В случае с 2-я датацентрами, вам надо организовывать > репликацию. В вашем случае - нет. > > Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns > сервер и на запрос site.com отдавал свой белый ип. > > Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс спросить у > x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если через днс спросить у > y.y.y.y адрес сайта site.com он ответит y.y.y.y. Остальное по статье. Если > днс провайдера видит, что dns сервер на x.x.x.x не отвечает, он спросит > адрес у второго сервера и клиенты пойдут на y.y.y.y. > Все оказывается так просто - но не в моей ситуации (Увы)! За раскладку большое спасибо. Все по полочкам. Большая благодарность. Только можно еще один вопрос. Дело в том, что моё начальство программисты и угодить им - практически не возможно. По крайней мере сколько я себя знаю. На данное предложение - они обязательно скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и этот вариант скорее всего отметут. Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер в текущий момент работал - работал сайт. Т.е. требования одновременной работы нет. Хотя бы через одного провайдера бы работал - и этого достаточно. За самодеятельсность - серьезная вздрючка. Поэтому возникает вопрос какие еще могут быть альтернативные решения в такой ситуации. Я с таким еще не сталкивался. -- -- Faithfully yours, Vladimir Skubriev From kostenl at gmail.com Tue Jan 14 05:46:18 2014 From: kostenl at gmail.com (=?koi8-r?B?7MHQz97Lyc4g68/O09TBztTJzg==?=) Date: Tue, 14 Jan 2014 11:46:18 +0600 Subject: =?UTF-8?B?UkU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D4C956.1090107@skubriev.ru> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> Message-ID: <005501cf10eb$f317dca0$d94795e0$@gmail.com> Да, появляется ещё один сервис, ДНС, от которого зависит работоспособность сайта. В вашем случае, если уже есть скрипт, который осуществляет переключение провайдера, допилить его на изменение А записи на удалённом (не вашем) dns сервере. С условием выставления минимального ttl для этой записи что-то может получиться. Однако, в этом случае ещё одной точкой отказа станет ваш скрипт. Ну, про Amazon Route 53 уже сказали. -----Original Message----- From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Vladimir Skubriev Sent: Tuesday, January 14, 2014 11:21 AM To: nginx-ru at nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? 14.01.2014 09:11, Лапочкин Константин пишет: > У вас даже всё проще. В случае с 2-я датацентрами, вам надо > организовывать репликацию. В вашем случае - нет. > > Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns > сервер и на запрос site.com отдавал свой белый ип. > > Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс > спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если > через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. > Остальное по статье. Если днс провайдера видит, что dns сервер на > x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут на y.y.y.y. > Все оказывается так просто - но не в моей ситуации (Увы)! За раскладку большое спасибо. Все по полочкам. Большая благодарность. Только можно еще один вопрос. Дело в том, что моё начальство программисты и угодить им - практически не возможно. По крайней мере сколько я себя знаю. На данное предложение - они обязательно скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и этот вариант скорее всего отметут. Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер в текущий момент работал - работал сайт. Т.е. требования одновременной работы нет. Хотя бы через одного провайдера бы работал - и этого достаточно. За самодеятельсность - серьезная вздрючка. Поэтому возникает вопрос какие еще могут быть альтернативные решения в такой ситуации. Я с таким еще не сталкивался. -- -- Faithfully yours, Vladimir Skubriev _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru From artem.vasiliev at gmail.com Tue Jan 14 07:12:59 2014 From: artem.vasiliev at gmail.com (=?UTF-8?B?0JDRgNGC0LXQvCDQktCw0YHQuNC70YzQtdCy?=) Date: Tue, 14 Jan 2014 11:12:59 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <005501cf10eb$f317dca0$d94795e0$@gmail.com> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> Message-ID: На что только не идут люди, лишь бы не покупать себе впс для хостинга 14 января 2014 г., 9:46 пользователь Лапочкин Константин написал: > Да, появляется ещё один сервис, ДНС, от которого зависит работоспособность > сайта. > > В вашем случае, если уже есть скрипт, который осуществляет переключение > провайдера, допилить его на изменение А записи на удалённом (не вашем) dns > сервере. С условием выставления минимального ttl для этой записи что-то > может получиться. Однако, в этом случае ещё одной точкой отказа станет ваш > скрипт. > > Ну, про Amazon Route 53 уже сказали. > > -----Original Message----- > From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On > Behalf Of Vladimir Skubriev > Sent: Tuesday, January 14, 2014 11:21 AM > To: nginx-ru at nginx.org > Subject: Re: две А записи в DNS - будет ли тормозить, если один из > провайдеров отвалится ? > > 14.01.2014 09:11, Лапочкин Константин пишет: > > У вас даже всё проще. В случае с 2-я датацентрами, вам надо > > организовывать репликацию. В вашем случае - нет. > > > > Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns > > сервер и на запрос site.com отдавал свой белый ип. > > > > Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс > > спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если > > через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. > > Остальное по статье. Если днс провайдера видит, что dns сервер на > > x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут > на y.y.y.y. > > > Все оказывается так просто - но не в моей ситуации (Увы)! > > За раскладку большое спасибо. Все по полочкам. Большая благодарность. > > Только можно еще один вопрос. > > Дело в том, что моё начальство программисты и угодить им - практически не > возможно. > > По крайней мере сколько я себя знаю. На данное предложение - они > обязательно > скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и > этот вариант скорее всего отметут. > > Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер > в > текущий момент работал - работал сайт. > > Т.е. требования одновременной работы нет. Хотя бы через одного провайдера > бы > работал - и этого достаточно. > > За самодеятельсность - серьезная вздрючка. > > Поэтому возникает вопрос какие еще могут быть альтернативные решения в > такой > ситуации. > > Я с таким еще не сталкивался. > > -- > -- > Faithfully yours, > > Vladimir Skubriev > > _______________________________________________ > 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 > -- WBR Artem V. Vasiliev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.hha at gmail.com Tue Jan 14 07:17:22 2014 From: alex.hha at gmail.com (Alex Domoradov) Date: Tue, 14 Jan 2014 09:17:22 +0200 Subject: =?UTF-8?B?UmU6INCh0LHQvtGA0LrQsCBuZ2lueCDRgSDQutCw0YHRgtC+0LzQvdGL0Lwgb3Bl?= =?UTF-8?B?bnNzbA==?= In-Reply-To: <52D47165.6070506@mail.ru> References: <52D3BD16.3080408@mail.ru> <52D457E5.8050200@mail.ru> <2326624.njZLtf11n7@vbart-laptop> <52D47165.6070506@mail.ru> Message-ID: > Про --help незнал, каюсь очень странно, просто когда человек начинает собирать из исходников с кастомными ключами, то он, как правило, четко знает - что он делает, для чего и что он хочет получить в итоге :) 2014/1/14 Kostya Alexandrov : > Валентин, возможно я не прав, но вот если бы я это увидел в доке к ssl > модулю, то флейма и дурных вопросов не задавал бы, заодно бы час-другой > сэкономил бы себе, думаю человек, написавший то руководство так же как и я > бодался с тем чтоб собрать nginx с кастомным openssl. Скажем так, для себя я > проблему решил, и мне кажется, что "будущим покалениям" было бы неплохо > получить эти сокральные знания без гугла и десятка дурных и вредных советов, > типа ставит пакеты от centos 6.5 с нодепс и тп. Решайте сами стоит ли > добавить пару строк доки или нет. > > > On 14.01.14, 2:51, Валентин Бартенев wrote: >> >> On Tuesday 14 January 2014 01:17:25 Kostya Alexandrov wrote: >>> >>> Про --help незнал, каюсь, однако же без хака >>> # edit auto/lib/openssl/conf manually or use sed >>> sed -i -e 's|\.openssl/||' auto/lib/openssl/conf >>> >>> собрать у меня не удалось >> >> [..] >> >> А не нужно было следовать приведенному руководству и собирать OpenSSL >> самостоятельно. >> >> Всё, что было нужно - это скачать архив с исходниками OpenSSL, >> распаковать, >> и просто указать в --with-openssl=DIR вместо DIR путь к исходникам. >> >> -- >> Валентин Бартенев >> _______________________________________________ >> 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 alex.hha at gmail.com Tue Jan 14 07:21:12 2014 From: alex.hha at gmail.com (Alex Domoradov) Date: Tue, 14 Jan 2014 09:21:12 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> Message-ID: Ну вообще то ни один ДЦ/Хостинг не гарантирует вам 100% Uptime, хотя многие и пишут, но это маркетинг. 2014/1/14 Артем Васильев : > На что только не идут люди, лишь бы не покупать себе впс для хостинга > > > 14 января 2014 г., 9:46 пользователь Лапочкин Константин > написал: > >> Да, появляется ещё один сервис, ДНС, от которого зависит работоспособность >> сайта. >> >> В вашем случае, если уже есть скрипт, который осуществляет переключение >> провайдера, допилить его на изменение А записи на удалённом (не вашем) >> dns >> сервере. С условием выставления минимального ttl для этой записи что-то >> может получиться. Однако, в этом случае ещё одной точкой отказа станет >> ваш >> скрипт. >> >> Ну, про Amazon Route 53 уже сказали. >> >> -----Original Message----- >> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On >> Behalf Of Vladimir Skubriev >> Sent: Tuesday, January 14, 2014 11:21 AM >> To: nginx-ru at nginx.org >> Subject: Re: две А записи в DNS - будет ли тормозить, если один из >> провайдеров отвалится ? >> >> 14.01.2014 09:11, Лапочкин Константин пишет: >> > У вас даже всё проще. В случае с 2-я датацентрами, вам надо >> > организовывать репликацию. В вашем случае - нет. >> > >> > Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns >> > сервер и на запрос site.com отдавал свой белый ип. >> > >> > Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс >> > спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если >> > через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. >> > Остальное по статье. Если днс провайдера видит, что dns сервер на >> > x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут >> на y.y.y.y. >> > >> Все оказывается так просто - но не в моей ситуации (Увы)! >> >> За раскладку большое спасибо. Все по полочкам. Большая благодарность. >> >> Только можно еще один вопрос. >> >> Дело в том, что моё начальство программисты и угодить им - практически не >> возможно. >> >> По крайней мере сколько я себя знаю. На данное предложение - они >> обязательно >> скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и >> этот вариант скорее всего отметут. >> >> Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер >> в >> текущий момент работал - работал сайт. >> >> Т.е. требования одновременной работы нет. Хотя бы через одного провайдера >> бы >> работал - и этого достаточно. >> >> За самодеятельсность - серьезная вздрючка. >> >> Поэтому возникает вопрос какие еще могут быть альтернативные решения в >> такой >> ситуации. >> >> Я с таким еще не сталкивался. >> >> -- >> -- >> Faithfully yours, >> >> Vladimir Skubriev >> >> _______________________________________________ >> 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 > > > > > -- > WBR > Artem V. Vasiliev > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From artem.vasiliev at gmail.com Tue Jan 14 07:25:39 2014 From: artem.vasiliev at gmail.com (=?UTF-8?B?0JDRgNGC0LXQvCDQktCw0YHQuNC70YzQtdCy?=) Date: Tue, 14 Jan 2014 11:25:39 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> Message-ID: Любой ДЦ/хостинг априори надежнее чем такое HA-решение на основе местных пионер-телекомов. И избавляет от подобных вопросов и прочей ненужной головной боли. 14 января 2014 г., 11:21 пользователь Alex Domoradov написал: > Ну вообще то ни один ДЦ/Хостинг не гарантирует вам 100% Uptime, хотя > многие и пишут, но это маркетинг. > > 2014/1/14 Артем Васильев : > > На что только не идут люди, лишь бы не покупать себе впс для хостинга > > > > > > 14 января 2014 г., 9:46 пользователь Лапочкин Константин < > kostenl at gmail.com> > > написал: > > > >> Да, появляется ещё один сервис, ДНС, от которого зависит > работоспособность > >> сайта. > >> > >> В вашем случае, если уже есть скрипт, который осуществляет переключение > >> провайдера, допилить его на изменение А записи на удалённом (не вашем) > >> dns > >> сервере. С условием выставления минимального ttl для этой записи что-то > >> может получиться. Однако, в этом случае ещё одной точкой отказа станет > >> ваш > >> скрипт. > >> > >> Ну, про Amazon Route 53 уже сказали. > >> > >> -----Original Message----- > >> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On > >> Behalf Of Vladimir Skubriev > >> Sent: Tuesday, January 14, 2014 11:21 AM > >> To: nginx-ru at nginx.org > >> Subject: Re: две А записи в DNS - будет ли тормозить, если один из > >> провайдеров отвалится ? > >> > >> 14.01.2014 09:11, Лапочкин Константин пишет: > >> > У вас даже всё проще. В случае с 2-я датацентрами, вам надо > >> > организовывать репликацию. В вашем случае - нет. > >> > > >> > Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns > >> > сервер и на запрос site.com отдавал свой белый ип. > >> > > >> > Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс > >> > спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если > >> > через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. > >> > Остальное по статье. Если днс провайдера видит, что dns сервер на > >> > x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты > пойдут > >> на y.y.y.y. > >> > > >> Все оказывается так просто - но не в моей ситуации (Увы)! > >> > >> За раскладку большое спасибо. Все по полочкам. Большая благодарность. > >> > >> Только можно еще один вопрос. > >> > >> Дело в том, что моё начальство программисты и угодить им - практически > не > >> возможно. > >> > >> По крайней мере сколько я себя знаю. На данное предложение - они > >> обязательно > >> скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и > >> этот вариант скорее всего отметут. > >> > >> Дело вот в чем, они хотят, чтобы в не зависимости от того, какой > провайдер > >> в > >> текущий момент работал - работал сайт. > >> > >> Т.е. требования одновременной работы нет. Хотя бы через одного > провайдера > >> бы > >> работал - и этого достаточно. > >> > >> За самодеятельсность - серьезная вздрючка. > >> > >> Поэтому возникает вопрос какие еще могут быть альтернативные решения в > >> такой > >> ситуации. > >> > >> Я с таким еще не сталкивался. > >> > >> -- > >> -- > >> Faithfully yours, > >> > >> Vladimir Skubriev > >> > >> _______________________________________________ > >> 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 > > > > > > > > > > -- > > WBR > > Artem V. Vasiliev > > > > _______________________________________________ > > 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 > -- WBR Artem V. Vasiliev -------------- next part -------------- An HTML attachment was scrubbed... URL: From s at bykov.odessa.ua Tue Jan 14 08:24:59 2014 From: s at bykov.odessa.ua (s at bykov.odessa.ua) Date: Tue, 14 Jan 2014 10:24:59 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> Message-ID: <52D4F45B.2050900@bykov.odessa.ua> Зачем вам вообще эти хостинги-шмостинги, сервера асинхронные, днс-ы непонятные. Ящетаю так - захотелось купить молочка - сходи на рынок, пообщайся с людьми, поторгуйся в конце концов Нормальные люди днем уголь разгружают или лес рубят, а вечером с друзьями в баре пиво сидят пьют. А эти компьютерщики уткнулись в свои мониторы, тыкают непонятные букофки по кнопочкам. Сидят что-то выискивают в своих интернетах. Что вы там выискиваете? Коль вздумалось что-то найти - выйди ты, не поленись, на крыльцо, послушай, о чем бабки сплетничают, впитай народную мудрость как береста. А если по кнопочкам охота потыкать - возьми гармошку, выйди в честной народ, спой колядки и получи благодарственный калач (а может и окорок зажиточный крестьянин в мешок покладет). Тем более Новый год сегодня! С праздником! > Любой ДЦ/хостинг априори надежнее чем такое HA-решение на основе > местных пионер-телекомов. > И избавляет от подобных вопросов и прочей ненужной головной боли. > > > 14 января 2014 г., 11:21 пользователь Alex Domoradov > > написал: > > Ну вообще то ни один ДЦ/Хостинг не гарантирует вам 100% Uptime, хотя > многие и пишут, но это маркетинг. > > 2014/1/14 Артем Васильев >: > > На что только не идут люди, лишь бы не покупать себе впс для > хостинга > > > > > > 14 января 2014 г., 9:46 пользователь Лапочкин Константин > > > > написал: > > > >> Да, появляется ещё один сервис, ДНС, от которого зависит > работоспособность > >> сайта. > >> > >> В вашем случае, если уже есть скрипт, который осуществляет > переключение > >> провайдера, допилить его на изменение А записи на удалённом > (не вашем) > >> dns > >> сервере. С условием выставления минимального ttl для этой > записи что-то > >> может получиться. Однако, в этом случае ещё одной точкой > отказа станет > >> ваш > >> скрипт. > >> > >> Ну, про Amazon Route 53 уже сказали. > >> > >> -----Original Message----- > >> From: nginx-ru-bounces at nginx.org > > [mailto:nginx-ru-bounces at nginx.org > ] On > >> Behalf Of Vladimir Skubriev > >> Sent: Tuesday, January 14, 2014 11:21 AM > >> To: nginx-ru at nginx.org > >> Subject: Re: две А записи в DNS - будет ли тормозить, если один из > >> провайдеров отвалится ? > >> > >> 14.01.2014 09:11, Лапочкин Константин пишет: > >> > У вас даже всё проще. В случае с 2-я датацентрами, вам надо > >> > организовывать репликацию. В вашем случае - нет. > >> > > >> > Вам надо организовать, что бы на каждом входящем интерфейсе > слушал dns > >> > сервер и на запрос site.com отдавал свой > белый ип. > >> > > >> > Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс > >> > спросить у x.x.x.x адрес сайта site.com он > ответит x.x.x.x. Если > >> > через днс спросить у y.y.y.y адрес сайта site.com > он ответит y.y.y.y. > >> > Остальное по статье. Если днс провайдера видит, что dns сервер на > >> > x.x.x.x не отвечает, он спросит адрес у второго сервера и > клиенты пойдут > >> на y.y.y.y. > >> > > >> Все оказывается так просто - но не в моей ситуации (Увы)! > >> > >> За раскладку большое спасибо. Все по полочкам. Большая > благодарность. > >> > >> Только можно еще один вопрос. > >> > >> Дело в том, что моё начальство программисты и угодить им - > практически не > >> возможно. > >> > >> По крайней мере сколько я себя знаю. На данное предложение - они > >> обязательно > >> скажут, что держать свой DNS сервер для зоны нашего сайта - не > надежно и > >> этот вариант скорее всего отметут. > >> > >> Дело вот в чем, они хотят, чтобы в не зависимости от того, > какой провайдер > >> в > >> текущий момент работал - работал сайт. > >> > >> Т.е. требования одновременной работы нет. Хотя бы через одного > провайдера > >> бы > >> работал - и этого достаточно. > >> > >> За самодеятельсность - серьезная вздрючка. > >> > >> Поэтому возникает вопрос какие еще могут быть альтернативные > решения в > >> такой > >> ситуации. > >> > >> Я с таким еще не сталкивался. > >> > >> -- > >> -- > >> Faithfully yours, > >> > >> Vladimir Skubriev > >> > >> _______________________________________________ > >> 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 > > > > > > > > > > -- > > WBR > > Artem V. Vasiliev > > > > _______________________________________________ > > 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 > > > > > -- > WBR > Artem V. Vasiliev > > > _______________________________________________ > 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 zmey1992 at ya.ru Tue Jan 14 08:31:04 2014 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Tue, 14 Jan 2014 12:31:04 +0400 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQutCwINCx0L7RgtC+0LIsINC30LDRhdC+0LQ=?= =?UTF-8?B?0Y/RidC40YUg0L3QsCDRgdGC0YDQsNC90LjRhtGDINC/0L4gSVAt0LDQtNGA?= =?UTF-8?B?0LXRgdGDLiDQktC+0LfQvNC+0LbQvdC+INC70Lg/?= In-Reply-To: References: Message-ID: <96821389688264@web10g.yandex.ru> server { listen 80; # или что там у вас server_name 12.34.56.78; # IP, на который заходят return 444; # или 403 } Плюс - не засирается дефолтный сервер и мы чётко ловим заходящих по IP. Минус - если IPшников ОЧЕНЬ много, тогда неудобно. Все их надо будет прописывать в server_name. 13.01.2014, 15:03, "Sferg" : > Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а > видно, что периодически на страничку заходят боты не по доменному имени, а > по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке > по IP-адресу - чтоб только по доменному имени заходили, а по IP > блокировались файрволом. > > С уважением, Геннадий. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246311,246311#msg-246311 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From kostenl at gmail.com Tue Jan 14 08:45:50 2014 From: kostenl at gmail.com (=?UTF-8?B?0JvQsNC/0L7Rh9C60LjQvSDQmtC+0L3RgdGC0LDQvdGC0LjQvQ==?=) Date: Tue, 14 Jan 2014 14:45:50 +0600 Subject: =?UTF-8?B?UkU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> Message-ID: <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> Далеко не всегда можно выносить информацию на сторонние ресурсы. Скорости или latency до германии могут не устроить для некоторых задач. Да и падают датацентры, никто простой в пару часов вам возмещать в ценах Ваших убытков не будет. From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Артем Васильев Sent: Tuesday, January 14, 2014 1:26 PM To: nginx-ru at nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? Любой ДЦ/хостинг априори надежнее чем такое HA-решение на основе местных пионер-телекомов. И избавляет от подобных вопросов и прочей ненужной головной боли. 14 января 2014 г., 11:21 пользователь Alex Domoradov написал: Ну вообще то ни один ДЦ/Хостинг не гарантирует вам 100% Uptime, хотя многие и пишут, но это маркетинг. 2014/1/14 Артем Васильев : > На что только не идут люди, лишь бы не покупать себе впс для хостинга > > > 14 января 2014 г., 9:46 пользователь Лапочкин Константин > написал: > >> Да, появляется ещё один сервис, ДНС, от которого зависит работоспособность >> сайта. >> >> В вашем случае, если уже есть скрипт, который осуществляет переключение >> провайдера, допилить его на изменение А записи на удалённом (не вашем) >> dns >> сервере. С условием выставления минимального ttl для этой записи что-то >> может получиться. Однако, в этом случае ещё одной точкой отказа станет >> ваш >> скрипт. >> >> Ну, про Amazon Route 53 уже сказали. >> >> -----Original Message----- >> From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On >> Behalf Of Vladimir Skubriev >> Sent: Tuesday, January 14, 2014 11:21 AM >> To: nginx-ru at nginx.org >> Subject: Re: две А записи в DNS - будет ли тормозить, если один из >> провайдеров отвалится ? >> >> 14.01.2014 09:11, Лапочкин Константин пишет: >> > У вас даже всё проще. В случае с 2-я датацентрами, вам надо >> > организовывать репликацию. В вашем случае - нет. >> > >> > Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns >> > сервер и на запрос site.com отдавал свой белый ип. >> > >> > Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс >> > спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если >> > через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. >> > Остальное по статье. Если днс провайдера видит, что dns сервер на >> > x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут >> на y.y.y.y. >> > >> Все оказывается так просто - но не в моей ситуации (Увы)! >> >> За раскладку большое спасибо. Все по полочкам. Большая благодарность. >> >> Только можно еще один вопрос. >> >> Дело в том, что моё начальство программисты и угодить им - практически не >> возможно. >> >> По крайней мере сколько я себя знаю. На данное предложение - они >> обязательно >> скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и >> этот вариант скорее всего отметут. >> >> Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер >> в >> текущий момент работал - работал сайт. >> >> Т.е. требования одновременной работы нет. Хотя бы через одного провайдера >> бы >> работал - и этого достаточно. >> >> За самодеятельсность - серьезная вздрючка. >> >> Поэтому возникает вопрос какие еще могут быть альтернативные решения в >> такой >> ситуации. >> >> Я с таким еще не сталкивался. >> >> -- >> -- >> Faithfully yours, >> >> Vladimir Skubriev >> >> _______________________________________________ >> 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 > > > > > -- > WBR > Artem V. Vasiliev > > _______________________________________________ > 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 -- WBR Artem V. Vasiliev -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at skubriev.ru Tue Jan 14 09:13:18 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 13:13:18 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> Message-ID: <52D4FFAE.6030902@skubriev.ru> 14.01.2014 11:12, Артем Васильев пишет: > На что только не идут люди, лишь бы не покупать себе впс для хостинга > Надеюсь это очень мудрый совет и я даже частично с ним согласен. Увы отдаленность от столицы сказывается не в лучшую сторону. ) Хотя скорее это было лирическое отступление нежели призыв к действию ? -- -- Faithfully yours, Vladimir Skubriev From vladimir at skubriev.ru Tue Jan 14 09:19:40 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 13:19:40 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D4F45B.2050900@bykov.odessa.ua> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <52D4F45B.2050900@bykov.odessa.ua> Message-ID: <52D5012C.3020000@skubriev.ru> 14.01.2014 12:24, s at bykov.odessa.ua пишет: > Зачем вам вообще эти хостинги-шмостинги, сервера асинхронные, днс-ы > непонятные. Ящетаю так - захотелось купить молочка - сходи на рынок, > пообщайся с людьми, поторгуйся в конце концов > > Нормальные люди днем уголь разгружают или лес рубят, а вечером с > друзьями в баре пиво сидят пьют. А эти компьютерщики уткнулись в свои > мониторы, тыкают непонятные букофки по кнопочкам. Сидят что-то > выискивают в своих интернетах. > > Что вы там выискиваете? Коль вздумалось что-то найти - выйди ты, не > поленись, на крыльцо, послушай, о чем бабки сплетничают, впитай > народную мудрость как береста. > Вы это серьезно ? Хотелось бы тогда услышать ваше мнение по поводу всех этих хостингов и иже с ними. Ну так для общего развития - не помешает. > А если по кнопочкам охота потыкать - возьми гармошку, выйди в честной > народ, спой колядки и получи благодарственный калач (а может и окорок > зажиточный крестьянин в мешок покладет). > > Тем более Новый год сегодня! > С праздником! > Да такие комментарии только под новый год и увидишь. Спасибо. Рассмеялся от души. А можно на заметку взять ? Это вы сейчас все выдумали или заготовочка была ? -- -- Faithfully yours, Vladimir Skubriev -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Tue Jan 14 09:20:36 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 14 Jan 2014 13:20:36 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D4BFB7.9050809@skubriev.ru> References: <52D404B6.40809@skubriev.ru> <1967078.pRY3lv2aJc@vbart-laptop> <52D4BFB7.9050809@skubriev.ru> Message-ID: <6683964.blIa2uQVJU@vbart-laptop> On Tuesday 14 January 2014 08:40:23 Vladimir Skubriev wrote: > 13.01.2014 22:22, Валентин Бартенев пишет: > > On Monday 13 January 2014 20:17:34 Sergey Kobzar wrote: > >> On 01/13/14 19:46, VovansystemS wrote: > >>>>> Половина попыток подключиться будет обламываться по таймауту. > >>>> в итоге клиенты будут не довольны ? > >>> да. я уже много лет с нетерпением жду того момента, когда браузеры > >>> научатся понимать SRV записи типа а они имеют вид: > >>> > >>> _service._proto.name. TTL class SRV priority weight port target. > >>> т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с > >>> mx записями - задавать вес для айпишников так: > >>> > >>> _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. > >>> _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. > >>> > >>> тогда будет счастье и отказоустойчивость без ботлнеков.. > >> Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. > >> Естественно NS сервер должен быть где-то в ДЦ. > > [..] > > > > Едва ли это можно назвать "фэловер" при ненулевом TTL. > > > А нулевой TTL используется? > Локально вполне может использоваться. Глобально могут быть проблемы, начиная от возникновения дополнительных задержек и заканчивая разной интерпретацией zero ttl со стороны софта и dns-серверов. -- Валентин Бартенев From vladimir at skubriev.ru Tue Jan 14 09:20:56 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 13:20:56 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> References: <52D404B6.40809@skubriev.ru> <52D4181F.3050608@skubriev.ru> <52D42DBE.3070409@itcraft.org> <52D43706.30605@itcraft.org> <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> Message-ID: <52D50178.30306@skubriev.ru> 14.01.2014 12:45, Лапочкин Константин пишет: > > Далеко не всегда можно выносить информацию на сторонние ресурсы. > Кстати у меня как раз такой случай. Слижком уж ценна разработка. > Скорости или latencyдо германии могут не устроить для некоторых задач. > > Да и падают датацентры, никто простой в пару часов вам возмещать в > ценах Ваших убытков не будет. > > Во всем есть свои плюсы и минусы. -- -- Faithfully yours, Vladimir Skubriev -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at skubriev.ru Tue Jan 14 09:23:29 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 13:23:29 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <6683964.blIa2uQVJU@vbart-laptop> References: <52D404B6.40809@skubriev.ru> <1967078.pRY3lv2aJc@vbart-laptop> <52D4BFB7.9050809@skubriev.ru> <6683964.blIa2uQVJU@vbart-laptop> Message-ID: <52D50211.7040003@skubriev.ru> 14.01.2014 13:20, Валентин Бартенев пишет: > On Tuesday 14 January 2014 08:40:23 Vladimir Skubriev wrote: >> 13.01.2014 22:22, Валентин Бартенев пишет: >>> On Monday 13 January 2014 20:17:34 Sergey Kobzar wrote: >>>> On 01/13/14 19:46, VovansystemS wrote: >>>>>>> Половина попыток подключиться будет обламываться по таймауту. >>>>>> в итоге клиенты будут не довольны ? >>>>> да. я уже много лет с нетерпением жду того момента, когда браузеры >>>>> научатся понимать SRV записи типа а они имеют вид: >>>>> >>>>> _service._proto.name. TTL class SRV priority weight port target. >>>>> т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с >>>>> mx записями - задавать вес для айпишников так: >>>>> >>>>> _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. >>>>> _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. >>>>> >>>>> тогда будет счастье и отказоустойчивость без ботлнеков.. >>>> Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. >>>> Естественно NS сервер должен быть где-то в ДЦ. >>> [..] >>> >>> Едва ли это можно назвать "фэловер" при ненулевом TTL. >>> >> А нулевой TTL используется? >> > Локально вполне может использоваться. Глобально могут быть проблемы, начиная > от возникновения дополнительных задержек и заканчивая разной интерпретацией > zero ttl со стороны софта и dns-серверов. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Куда ни плюнь везде свои ньюансы. Так а что после ваших слов посоветуете делать? Или так: "На что обратить внимание?" Просто я уже даже настроился на TTL а 1 минуту. А тут на тебе очередная уточка. -- -- Faithfully yours, Vladimir Skubriev From citrin at citrin.ru Tue Jan 14 09:28:40 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 14 Jan 2014 13:28:40 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: References: Message-ID: <52D50348.5060809@citrin.ru> On 01/14/14 01:17, Anton Sayetsky wrote: > Собственно, планируется сабж в ближайшем будущем. > Размеры файлов - от 1 до 8-10 ГиБ, 400-500 сессий до 2-3 коннектов на > сессию, траф - 4-5 ГБит/сек. Последние два параметра в перспективе > могут вырасти ориентировочно до двух раз. Ось - FreeBSD, ФС - ZFS. > Есть ли общие рекомендации настройки nginx для подобных конфигураций? > Размер/кол-во буферов, метод отдачи файлов и т.п. 1. Собрать ядро с увеличенным до 1 Мб MAXPHYS options MAXPHYS=(1024*1024) 2. Подобрать оптимальное значение для sysct kern.ipc.sendfile.readahead измеряется в блоках по MAXBSIZE (по умолчанию 64к) больше MAXPHYS/MAXBSIZE ставить смысла нет. т. е. при MAXPHYS 1 Мб можно попробовать kern.ipc.sendfile.readahead=16 Ну и собственно в конфиге nginx - sendfile on; 3. Про тюнинг ZFS написано много, в первую стоит посмотреть на размер ARC - по умолчанию ZFS пытается съесть почти всю память и запущенным приложениям остаётся мало, иногда аппетиты ZFS приходится ограничивать: vfs.zfs.arc_max="16G" vfs.zfs.prefetch_disable="1" # это стоит проверять на тестах, но я несколько раз сталкивался с тем, что отключение ZFS prefetch ускоряет работу. From vbart at nginx.com Tue Jan 14 09:30:11 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 14 Jan 2014 13:30:11 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D50211.7040003@skubriev.ru> References: <52D404B6.40809@skubriev.ru> <6683964.blIa2uQVJU@vbart-laptop> <52D50211.7040003@skubriev.ru> Message-ID: <2827333.YEKDsRLlEW@vbart-laptop> On Tuesday 14 January 2014 13:23:29 Vladimir Skubriev wrote: [..] > Куда ни плюнь везде свои ньюансы. > > Так а что после ваших слов посоветуете делать? > > Или так: "На что обратить внимание?" > > Просто я уже даже настроился на TTL а 1 минуту. > > А тут на тебе очередная уточка. > Я, как уже тут прозвучало, посоветовал бы взять нормальный хостинг, полагаю хороший датацентр будет всяко лучше, чем свой велосипед. И если уже боитесь весь проект выносить на него, то можно хотя бы поставить nginx и настроить проксирование с кэшированием. -- Валентин Бартенев From boco at ufanet.ru Tue Jan 14 09:31:43 2014 From: boco at ufanet.ru (damir bikmuhametov) Date: Tue, 14 Jan 2014 15:31:43 +0600 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D50178.30306@skubriev.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> Message-ID: <20140114093142.GM13849@ufanet.ru> On Tue, Jan 14, 2014 at 01:20:56PM +0400, Vladimir Skubriev wrote: > >Далеко не всегда можно выносить информацию на сторонние ресурсы. > > > Кстати у меня как раз такой случай. Слижком уж ценна разработка. поставьте в vps nginx и настройте на нем проксирование на два бакенда + кеширование статики. -- boco From artem.vasiliev at gmail.com Tue Jan 14 09:46:09 2014 From: artem.vasiliev at gmail.com (=?UTF-8?B?0JDRgNGC0LXQvCDQktCw0YHQuNC70YzQtdCy?=) Date: Tue, 14 Jan 2014 13:46:09 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <20140114093142.GM13849@ufanet.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> Message-ID: При сильном желании сервить свой крутой и ценный проект на локалхосте - покупается AS, ставится роутер, который может, любит, и умеет в bgp, подключается 2-3 провайдера по оптике c нормальным sla. В противном случае можно продолжать есть кактус с подобными вопросами и запросами, либо выбрать более-менее нормальный хостинг/vps (их есть в россии, и немало, даже для параноиков с *особо ценными разработками*) 14 января 2014 г., 13:31 пользователь damir bikmuhametov написал: > On Tue, Jan 14, 2014 at 01:20:56PM +0400, Vladimir Skubriev wrote: > > >Далеко не всегда можно выносить информацию на сторонние ресурсы. > > > > > Кстати у меня как раз такой случай. Слижком уж ценна разработка. > > поставьте в vps nginx и настройте на нем проксирование на два бакенда + > кеширование статики. > > -- > boco > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- WBR Artem V. Vasiliev -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at skubriev.ru Tue Jan 14 09:52:40 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 13:52:40 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <2827333.YEKDsRLlEW@vbart-laptop> References: <52D404B6.40809@skubriev.ru> <6683964.blIa2uQVJU@vbart-laptop> <52D50211.7040003@skubriev.ru> <2827333.YEKDsRLlEW@vbart-laptop> Message-ID: <52D508E8.2060104@skubriev.ru> 14.01.2014 13:30, Валентин Бартенев пишет: > On Tuesday 14 January 2014 13:23:29 Vladimir Skubriev wrote: > [..] >> Куда ни плюнь везде свои ньюансы. >> >> Так а что после ваших слов посоветуете делать? >> >> Или так: "На что обратить внимание?" >> >> Просто я уже даже настроился на TTL а 1 минуту. >> >> А тут на тебе очередная уточка. >> > Я, как уже тут прозвучало, посоветовал бы взять нормальный хостинг, > полагаю хороший датацентр будет всяко лучше, чем свой велосипед. > И если уже боитесь весь проект выносить на него, то можно хотя бы > поставить nginx и настроить проксирование с кэшированием. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо за еще один совет. У нас используется redmine и много репозиториев. Возникает вопрос что кэшировать ? Основная масса - это репозитории, которые нельзя выносить наружу. Сам redmine - не могу сказать. Т.к. совсем не знаком с темой кэширования. Шеф сказал Eat you dog ... Че то там. Типа нам не нужен Atlassin или что то еще т.к. он не доверяет им вплане - а вдруг украдут идеи. Есть такое подозрение, что как раз купить хостинг для frontend в бэкэнды держать у себя. Но тогда вопрос: на сколько это будет тормозить ? Если каналы у нас 10 и 25 мегабит оптика. Не очень сведую в этом вопросе. Хотя и пожалуй стоит рассмотреть данный вариант. Так как он по сути тоже интересен и совсем не сложен в реализации в отличии от танцов c DNS, TTL и т.д. Если честно я даже о таком подумать не мог. Даже и в мыслях такого не было. Хотя что в этом такого поидее. -- -- Faithfully yours, Vladimir Skubriev From vladimir at skubriev.ru Tue Jan 14 09:53:34 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 13:53:34 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <20140114093142.GM13849@ufanet.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> Message-ID: <52D5091E.50607@skubriev.ru> 14.01.2014 13:31, damir bikmuhametov пишет: > On Tue, Jan 14, 2014 at 01:20:56PM +0400, Vladimir Skubriev wrote: >>> Далеко не всегда можно выносить информацию на сторонние ресурсы. >>> >> Кстати у меня как раз такой случай. Слижком уж ценна разработка. > поставьте в vps nginx и настройте на нем проксирование на два бакенда + > кеширование статики. > Спасибо 1+1=2 за vps с nginx . Буду рассматривать. -- -- Faithfully yours, Vladimir Skubriev From vladimir at skubriev.ru Tue Jan 14 09:58:18 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 13:58:18 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> Message-ID: <52D50A3A.60707@skubriev.ru> 14.01.2014 13:46, Артем Васильев пишет: > При сильном желании сервить свой крутой и ценный проект на локалхосте > - покупается AS, ставится роутер, который может, любит, и умеет в bgp, > подключается 2-3 провайдера по оптике c нормальным sla. В противном > случае можно продолжать есть кактус с подобными вопросами и запросами, > либо выбрать более-менее нормальный хостинг/vps (их есть в россии, и > немало, даже для параноиков с /особо ценными разработками/) > В вашем предложении для меня сильно много "не знакомых слов". Поэтому циски, bgp и провайдеры со sla идут лесом. Это слишком круто. В таком случае Вы за frontend nginx на vps вместо update dns via api and small ttl? -- -- Faithfully yours, Vladimir Skubriev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jan 14 10:42:48 2014 From: nginx-forum at nginx.us (vladimircape) Date: Tue, 14 Jan 2014 05:42:48 -0500 Subject: Nginx cache In-Reply-To: References: <0752567e36b7019edc0561a8ae512618.NginxMailingListRussian@forum.nginx.org> Message-ID: <572bee3b738ed9a58a66c092dbd2ecef.NginxMailingListRussian@forum.nginx.org> Только вот инструкция fastcgi_cache_revalidate on; для 1.5 версии, который нету для Cent6,(у меня Fedora16). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246251,246393#msg-246393 From mdounin at mdounin.ru Tue Jan 14 10:44:16 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 14 Jan 2014 14:44:16 +0400 Subject: Nginx cache In-Reply-To: <572bee3b738ed9a58a66c092dbd2ecef.NginxMailingListRussian@forum.nginx.org> References: <0752567e36b7019edc0561a8ae512618.NginxMailingListRussian@forum.nginx.org> <572bee3b738ed9a58a66c092dbd2ecef.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140114104416.GG1835@mdounin.ru> Hello! On Tue, Jan 14, 2014 at 05:42:48AM -0500, vladimircape wrote: > Только вот инструкция fastcgi_cache_revalidate on; для 1.5 версии, который > нету для Cent6,(у меня Fedora16). http://nginx.org/en/linux_packages.html#mainline -- Maxim Dounin http://nginx.org/ From vsjcfm at gmail.com Tue Jan 14 10:57:53 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Tue, 14 Jan 2014 12:57:53 +0200 Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: <52D50348.5060809@citrin.ru> References: <52D50348.5060809@citrin.ru> Message-ID: 14 января 2014 г., 11:28 пользователь Anton Yuzhaninov написал: > 1. Собрать ядро с увеличенным до 1 Мб MAXPHYS > > options MAXPHYS=(1024*1024) Поискал - как-то мало информации по этому поводу. А та, что есть - в основном очень старая. Впрочем, внимания всё равно стоит. Интересно, почему это не default, если действительно помогает. > 2. Подобрать оптимальное значение для > sysct kern.ipc.sendfile.readahead Хм... root at jnb:~# uname -srm FreeBSD 9.2-RELEASE-p2 amd64 root at jnb:~# sysctl -a | grep sendfile | wc -l 0 root at jnb:~# jason at pxe:~$ uname -srm FreeBSD 9.1-RELEASE-p4 amd64 jason at pxe:~$ sysctl -a | grep sendfile | wc -l 0 jason at pxe:~$ jason at jason-freebsd:~$ uname -srm FreeBSD 8.3-RELEASE-p4 amd64 jason at jason-freebsd:~$ sysctl -a | grep sendfile | wc -l 0 jason at jason-freebsd:~$ На последних двух системах установлен nginx со включенным sendfile. При каких условиях должен появиться данный OID? А вот это есть: jason at jnb:~$ sysctl vfs.read_max vfs.zfs.zfetch.array_rd_sz vfs.read_max: 32 vfs.zfs.zfetch.array_rd_sz: 1048576 ЕМНИП для UFS (ext2fs, vfat, etc) - это кол-во кластеров, а для ZFS, видимо - кол-во байт. > измеряется в блоках по MAXBSIZE (по умолчанию 64к) > больше MAXPHYS/MAXBSIZE ставить смысла нет. > т. е. при MAXPHYS 1 Мб можно попробовать kern.ipc.sendfile.readahead=16 Таки да, для UFS это - кол-во кластеров. jason at jnb:~$ man tuning | col -b | grep -A 10 read_max The vfs.read_max sysctl governs VFS read-ahead and is expressed as the number of blocks to pre-read if the heuristics algorithm decides that the reads are issued sequentially. It is used by the UFS, ext2fs and msdosfs file systems. With the default UFS block size of 16 KiB, a setting of 32 will allow speculatively reading up to 512 KiB. This setting may be increased to get around disk I/O latencies, especially where these laten? cies are large such as in virtual machine emulated environments. It may be tuned down in specific cases where the I/O load is such that read- ahead adversely affects performance or where system memory is really low. The vfs.ncsizefactor sysctl defines how large VFS namecache may grow. jason at jnb:~$ > Ну и собственно в конфиге nginx - sendfile on; Странно, ибо в ранее прочитанных мануалах (втч и в этой рассылке) для отдачи с ZFS всегда рекомендовали sendfile выключать, НЯП для избежания double-buffering. > 3. Про тюнинг ZFS написано много, в первую стоит посмотреть на размер ARC - > по умолчанию ZFS пытается съесть почти всю память и запущенным приложениям > остаётся мало, иногда аппетиты ZFS приходится ограничивать: > vfs.zfs.arc_max="16G" Вот тут не соглашусь. "Съест почти всю память" абсолютно любая ФС, имеющая кэш. Более того, любая такая ФС _обязана_ использовать всю память, не занятую приложениями. И проблема ранее была только в том, что ZFS слишком медленно освобождала память, что вызывало использование свопа. В общем-то, если бы данная проблема и существовала до сих пор - ничего страшного для сервера с 128-256 Г памяти, на котором не запущено ничего, кроме базовой системы, nginx, sshd и ntpd. ;) > vfs.zfs.prefetch_disable="1" # это стоит проверять на тестах, но я несколько > раз сталкивался с тем, что отключение ZFS prefetch ускоряет работу. А тут соглашусь. При отключенном prefetch чтение становится по сути однопоточным. Заметил это некоторое время назад случайно, во время теста ZFS over GELI. При отключенном GELI жрёт одно ядро, при включенном - больше одного. Из этого можно сделать вывод, что при большом кол-ве независимых операций отключение prefetch действительно может дать эффект: теоретически один клиент получит чуть меньше, но все клиенты вместе - больше. From nginx-forum at nginx.us Tue Jan 14 11:01:42 2014 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 14 Jan 2014 06:01:42 -0500 Subject: Nginx cache In-Reply-To: <572bee3b738ed9a58a66c092dbd2ecef.NginxMailingListRussian@forum.nginx.org> References: <0752567e36b7019edc0561a8ae512618.NginxMailingListRussian@forum.nginx.org> <572bee3b738ed9a58a66c092dbd2ecef.NginxMailingListRussian@forum.nginx.org> Message-ID: <8d5a34bf353f79b59349a0385033117f.NginxMailingListRussian@forum.nginx.org> vladimircape Wrote: ------------------------------------------------------- > Только вот инструкция fastcgi_cache_revalidate on; для 1.5 версии, > который нету для Cent6,(у меня Fedora16). У нас тоже CentOS, но мы не используем их репозитории для установки Nginx, причин для этого более чем достаточно - очень старые версии, сборки с костыльными настройками. По этому очень рекомендую, ставить Nginx, из оригинал пакета, вот ссылка http://nginx.org/en/linux_packages.html Вам необходимо выбрать ветку - Mainline version (1.5.x) Не волнуйтесь насчет стабильности, новые версии более стабильны и безопасны. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246251,246397#msg-246397 From citrin at citrin.ru Tue Jan 14 12:16:16 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 14 Jan 2014 16:16:16 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0YfQsCDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LI=?= In-Reply-To: References: <52D50348.5060809@citrin.ru> Message-ID: <52D52A90.8090608@citrin.ru> On 01/14/14 14:57, Anton Sayetsky wrote: > 14 января 2014 г., 11:28 пользователь Anton Yuzhaninov > написал: >> 1. Собрать ядро с увеличенным до 1 Мб MAXPHYS >> >> options MAXPHYS=(1024*1024) > Поискал - как-то мало информации по этому поводу. А та, что есть - в > основном очень старая. Впрочем, внимания всё равно стоит. Интересно, > почему это не default, если действительно помогает. 1. Есть небольшая вероятность, что существуют драйвера для SCSI/ATA-контроллеров неявно (т. е. из кода это не очевидно) предполагающие, что к ним не может придти запроса больше 128 Кб (текущий MAXPHYS). Но проблем в этом месте стоит ожидать разве что со старым и экзотическим железом. 2. Большой MAXPHYS может быть плох для систем с очень маленьким объемом памяти т. к. на эту константу завязаны размеры некоторых буферов в ядре. И для 32-х битных систем, т. к. резервируется KVA, которого на 32-х битных системах мало. 3. На популярных синтетических тестах прирост от увеличения MAXPHYS небольшой. Подробнее об этом можно почитать в этом треде: http://lists.freebsd.org/pipermail/freebsd-arch/2010-March/009974.html Но для раздачи больших файлов эффект от увеличения MAXPHYS может быть вполне ощутимым: http://mailman.nginx.org/pipermail/nginx-ru/2009-February/022197.html > >> 2. Подобрать оптимальное значение для >> sysct kern.ipc.sendfile.readahead > Хм... > root at jnb:~# uname -srm > FreeBSD 9.2-RELEASE-p2 amd64 > root at jnb:~# sysctl -a | grep sendfile | wc -l > 0 > root at jnb:~# :~> uname -srm FreeBSD 10.0-PRERELEASE amd64 :~> sysctl -d kern.ipc.sendfile.readahead kern.ipc.sendfile.readahead: Number of sendfile(2) read-ahead MAXBSIZE blocks А MFC в 9-ку похоже не сделали... Впрочем это не актуально учитывая что sendfile на ZFS не так полезен как на UFS. > А вот это есть: > jason at jnb:~$ sysctl vfs.read_max vfs.zfs.zfetch.array_rd_sz > vfs.read_max: 32 > vfs.zfs.zfetch.array_rd_sz: 1048576 > ЕМНИП для UFS (ext2fs, vfat, etc) - это кол-во кластеров, а для ZFS, > видимо - кол-во байт. vfs.read_max нужен для обычного чтения файлов и да, его стоит увеличивать. Но влияет ли это на sendfile не знаю, надо смотреть. Вполне возможно что без его увеличения sendfile readahead работать не будет. С ZFS работал мало и про vfs.zfs.zfetch.array_rd_sz ничего не скажу. > для отдачи с ZFS всегда рекомендовали sendfile выключать, НЯП для > избежания double-buffering. Да, похоже что senfile на ZFS использовать не стоит. Без sendfile можно попробовать output_buffers 1 1M; плюс можно попробовать aio и directio (вместе и по отдельности). From zmey1992 at ya.ru Tue Jan 14 12:24:12 2014 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Tue, 14 Jan 2014 16:24:12 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D50A3A.60707@skubriev.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> Message-ID: <59771389702252@web1g.yandex.ru> Вклинюсь в тред. Если вам нужно организовать надёжность связи с вашими серверами, у которых два аплинка, то да, вам просто нужна ВПС-ка фронтенд. Если вы хотите общую отказоустойчивость, то у вас появляется новая единая точка отказа - внешняя ВПС-ка. 14.01.2014, 13:58, "Vladimir Skubriev" : > 14.01.2014 13:46, Артем Васильев пишет: > >> При сильном желании сервить свой крутой и ценный проект на локалхосте - покупается AS, ставится роутер, который может, любит, и умеет в bgp, подключается 2-3 провайдера по оптике c нормальным sla. В противном случае можно продолжать есть кактус с подобными вопросами и запросами, либо выбрать более-менее нормальный хостинг/vps (их есть в россии, и немало, даже для параноиков с особо ценными разработками) > В вашем предложении для меня сильно много "не знакомых слов". Поэтому циски, bgp и провайдеры со sla идут лесом. Это слишком круто. > > В таком случае Вы за frontend nginx на vps вместо update dns via api and small ttl? > > -- -- Faithfully yours, Vladimir Skubriev > , > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vladimir at skubriev.ru Tue Jan 14 12:41:48 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Tue, 14 Jan 2014 16:41:48 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <59771389702252@web1g.yandex.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> Message-ID: <52D5308C.5080107@skubriev.ru> 14.01.2014 16:24, Васильев "Zmey!" Олег пишет: > Вклинюсь в тред. Если вам нужно организовать надёжность связи с вашими серверами, у которых два аплинка, то да, вам просто нужна ВПС-ка фронтенд. Если вы хотите общую отказоустойчивость, то у вас появляется новая единая точка отказа - внешняя ВПС-ка. > Спасибо. Мне достаточно того, чтобы изнутри локальной сети можно было работать в Интернет и снаружи был виден сайт ) Все намного проще ) Соответсвенно ВПС-ка и фронтенд. -- -- Faithfully yours, Vladimir Skubriev From gpskomsa at mail.ru Tue Jan 14 13:54:52 2014 From: gpskomsa at mail.ru (=?UTF-8?B?0J/QtdGC0YAg0JPRg9C30LDQvdC+0LI=?=) Date: Tue, 14 Jan 2014 17:54:52 +0400 Subject: High periodic disk I/O Message-ID: <1389707692.455114261@f30.i.mail.ru> Добрый день! Имеется сервер freebsd 9.2 amd64, 16gb ram, gmirror 2.7Tb x 2, nginx 1.4.2 За Nginx стоит php-fpm на котором работает сайт, средне нагруженный(1-10 запрос/сек). Кроме того, nginx через проксирование другого хоста отдает статику, которая таким образом, представляет собой динамически накопляемый кеш. Т.е. приходит запрос, nginx смотрит наличие статики в кеше, если нет получает ее с другого хоста, отдает ответ. В данный момент в таком кеше порядка 700к файлов, все они размером примерно от 10кб до 100кб, общий размер данных в кеше 10gb. Проблема в том, что периодически, раз в 10-20 секунд nginx подгружает диск записью на 2-5 секунды, изза этого случается лаг и например ответ от веб сервера можно ждать несколько секунд. Отчет gstat:  L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name     0     55      8    120   2689     47    903   4952   91.4| ada0    12     36      4     68   2652     32    659   5418   96.4| ada1    12     51     12    188   2676     39    855   5410  108.2| mirror/gm Если отключить в nginx работу со статикой через такое проксирование и отдавать ее мимо nginx, то такое поведение пропадает - диск никто периодически не насилует. Вот конфиг: user  web; worker_processes  8; events {     worker_connections  1024; } http {     include       mime.types;     default_type  application/octet-stream;     sendfile        on;     tcp_nopush     on;     keepalive_timeout  65;     gzip  on;     gzip_disable "msie6";     proxy_cache_path  /var/www/cache/static levels=2:2 keys_zone=cachearea:3000m max_size=1000000m inactive=1y;     proxy_temp_path /var/www/cache/tmp;     include /usr/local/etc/nginx/conf.d/*.conf; } server {     listen 80;     server_name www.domain.com;     root /var/www/domain/public;     access_log /var/log/domain-access_log;     error_log /var/log/domain-error_log warn;     sendfile off;     aio on;     client_max_body_size       100m;     client_body_buffer_size    128k;     location / {         index index.html index.php;         try_files $uri $uri/ /index.php$is_args$args;     }     location ~* /static/(?.*)$ {         expires max;         resolver 8.8.8.8;         proxy_pass http://proxydomain.com/$chosturi?$query_string;         proxy_cache cachearea;         proxy_cache_key $chosturi;         proxy_cache_valid 404 301 302 500 502 503 1h;         proxy_cache_valid 200 204 10y;     }     location ~ /index\.php$ {         include fastcgi_params;         fastcgi_pass   127.0.0.1:9000;         fastcgi_index  index.php;         fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;     } } Собственно вопрос в том как избавится от таких периодических нагрузок на диск. Спасибо. -- Петр -------------- next part -------------- An HTML attachment was scrubbed... URL: From public-mail at alekciy.ru Tue Jan 14 14:09:39 2014 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Tue, 14 Jan 2014 18:09:39 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D436BA.2070302@itcraft.org> References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> <52D436BA.2070302@itcraft.org> Message-ID: >Данное решение все-же лучше, чем ничего. Рад выслушать альтернативные решения, >которые работают вне пределов одного датацентра. DNS сервер на той же машине, что и веб сервер + А запись на саму себя. Т.е. на host1 крутиться DNS который для домена отдает только одну А запись, причем она ведет на IP адрес host1. А на host2 тоже самое, но только ведет на IP адрес host2. Ну а в NS-ах конечно же указаны оба IP адреса. К сожалению это решает вопрос только с первичным резолвингом и для клиентов которые уже запись откэшили сайт окажется недоступным. Поэтому "проблема недулевого TTL" остается для вернувшихся на сайте посетителей. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Tue Jan 14 16:10:43 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 14 Jan 2014 22:10:43 +0600 Subject: High periodic disk I/O In-Reply-To: <1389707692.455114261@f30.i.mail.ru> References: <1389707692.455114261@f30.i.mail.ru> Message-ID: в вашем случае будут две папки, куда будут падать файлы, проксированные по http (статика) и fastcgi (динамика), посмотрите, куда падает больше и крутите, соответственно fastcgi_buffers или proxy_buffers 14 января 2014 г., 19:54 пользователь Петр Гузанов написал: > Добрый день! > > Имеется сервер freebsd 9.2 amd64, 16gb ram, gmirror 2.7Tb x 2, nginx 1.4.2 > > За Nginx стоит php-fpm на котором работает сайт, средне нагруженный(1-10 > запрос/сек). Кроме того, nginx через проксирование другого хоста отдает > статику, которая таким образом, представляет собой динамически накопляемый > кеш. Т.е. приходит запрос, nginx смотрит наличие статики в кеше, если нет > получает ее с другого хоста, отдает ответ. > > В данный момент в таком кеше порядка 700к файлов, все они размером примерно > от 10кб до 100кб, общий размер данных в кеше 10gb. > Проблема в том, что периодически, раз в 10-20 секунд nginx подгружает диск > записью на 2-5 секунды, изза этого случается лаг и например ответ от веб > сервера можно ждать несколько секунд. Отчет gstat: > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 55 8 120 2689 47 903 4952 91.4| ada0 > 12 36 4 68 2652 32 659 5418 96.4| ada1 > 12 51 12 188 2676 39 855 5410 108.2| mirror/gm > > Если отключить в nginx работу со статикой через такое проксирование и > отдавать ее мимо nginx, то такое поведение пропадает - диск никто > периодически не насилует. > Вот конфиг: > > user web; > worker_processes 8; > > events { > worker_connections 1024; > } > > http { > include mime.types; > default_type application/octet-stream; > sendfile on; > tcp_nopush on; > keepalive_timeout 65; > gzip on; > gzip_disable "msie6"; > > proxy_cache_path /var/www/cache/static levels=2:2 > keys_zone=cachearea:3000m max_size=1000000m inactive=1y; > proxy_temp_path /var/www/cache/tmp; > include /usr/local/etc/nginx/conf.d/*.conf; > } > > server { > listen 80; > > server_name www.domain.com; > root /var/www/domain/public; > > access_log /var/log/domain-access_log; > error_log /var/log/domain-error_log warn; > > sendfile off; > aio on; > > client_max_body_size 100m; > client_body_buffer_size 128k; > > location / { > index index.html index.php; > try_files $uri $uri/ /index.php$is_args$args; > } > > location ~* /static/(?.*)$ { > expires max; > > resolver 8.8.8.8; > proxy_pass http://proxydomain.com/$chosturi?$query_string; > proxy_cache cachearea; > proxy_cache_key $chosturi; > proxy_cache_valid 404 301 302 500 502 503 1h; > proxy_cache_valid 200 204 10y; > } > > location ~ /index\.php$ { > include fastcgi_params; > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > } > } > > Собственно вопрос в том как избавится от таких периодических нагрузок на > диск. > Спасибо. > > -- > Петр > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Jan 14 17:09:21 2014 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 14 Jan 2014 12:09:21 -0500 Subject: High periodic disk I/O In-Reply-To: <1389707692.455114261@f30.i.mail.ru> References: <1389707692.455114261@f30.i.mail.ru> Message-ID: <3e3c7f720341cea4442939c79a8e89a0.NginxMailingListRussian@forum.nginx.org> > Проблема в том, что периодически, раз в 10-20 секунд nginx подгружает > диск записью на 2-5 секунды, изза этого случается лаг и например ответ > от веб сервера можно ждать несколько секунд. Возможно это результат процесса ?cache manager? и/или "cache loader" Почитать можно здесь http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_path Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246429,246438#msg-246438 From hunter at comsys.com.ua Tue Jan 14 17:13:40 2014 From: hunter at comsys.com.ua (Sergey Smitienko) Date: Tue, 14 Jan 2014 19:13:40 +0200 Subject: High periodic disk I/O In-Reply-To: <1389707692.455114261@f30.i.mail.ru> References: <1389707692.455114261@f30.i.mail.ru> Message-ID: <52D57044.3060002@comsys.com.ua> Добрый день. 1/14/14 3:54 PM, Петр Гузанов пишет: > Если отключить в nginx работу со статикой через такое проксирование и > отдавать ее мимо nginx, то такое поведение пропадает - диск никто > периодически не насилует. 1. Попробуйте выключить access и error логи. 2. Файловая система с noatime смонтирована ??? -- Sergey Smitienko From postmaster at softsearch.ru Tue Jan 14 17:33:22 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 Jan 2014 21:33:22 +0400 Subject: [PATCH] implemented hardlink option in DAV module In-Reply-To: <20121016174821.GA40452@mdounin.ru> References: <1350301244-27123-1-git-send-email-arut@qip.ru> <20121015153350.GH40452@mdounin.ru> <991838356.20121015233055@softsearch.ru> <507C6A98.9090903@csdoc.com> <1044505139.20121016001438@softsearch.ru> <20121016101653.GP40452@mdounin.ru> <20121016171051.GX40452@mdounin.ru> <1042482698.20121016213113@softsearch.ru> <20121016174821.GA40452@mdounin.ru> Message-ID: <661787979.20140114213322@softsearch.ru> Здравствуйте, Maxim. > Это cut-n-paste ошибка в виндовой части кода, которую я поленился > проверить и недоправил. Там должно быть date, исправленный патч > прилагается. Затестировали сейчас патч, добавляющий метод TOUCH. Лучше поздно, чем никогда. :-) Он работает, но похоже не использует aio. 30 процессов nginx висит в состоянии biord, а при этом запущено всего пяток aiodХХ из сотни возможных. Хотя второе объяснение подобному - это большая вложенность директорий. А третье - aio не умеет работать с директориями. Не знаю, какое верное. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Tue Jan 14 17:35:58 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 Jan 2014 21:35:58 +0400 Subject: High periodic disk I/O In-Reply-To: <1389707692.455114261@f30.i.mail.ru> References: <1389707692.455114261@f30.i.mail.ru> Message-ID: <1036988728.20140114213558@softsearch.ru> Здравствуйте, Петр. Возможно у домена proxydomain.com маленький ttl и поэтому его приходится постоянно резолвить. От этого и возникают скачки нагрузки. -- С уважением, Михаил mailto:postmaster at softsearch.ru From gpskomsa at mail.ru Tue Jan 14 23:30:57 2014 From: gpskomsa at mail.ru (=?UTF-8?B?0J/QtdGC0YAg0JPRg9C30LDQvdC+0LI=?=) Date: Wed, 15 Jan 2014 03:30:57 +0400 Subject: High periodic disk I/O In-Reply-To: <52D57044.3060002@comsys.com.ua> References: <1389707692.455114261@f30.i.mail.ru> <52D57044.3060002@comsys.com.ua> Message-ID: <1389742257.949317137@f358.i.mail.ru> Добрый день, да именно noatime, его не было, как только включил все прошло. Большое спасибо Сергей! Всем спасибо за ответы. Вторник, 14 января 2014, 19:13 +02:00 от Sergey Smitienko : >Добрый день. > >1/14/14 3:54 PM, Петр Гузанов пишет: >> Если отключить в nginx работу со статикой через такое проксирование и >> отдавать ее мимо nginx, то такое поведение пропадает - диск никто >> периодически не насилует. >1. Попробуйте выключить access и error логи. >2. Файловая система с noatime смонтирована ??? > >-- >Sergey Smitienko > >_______________________________________________ >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 kostenl at gmail.com Wed Jan 15 03:42:09 2014 From: kostenl at gmail.com (=?UTF-8?B?0JvQsNC/0L7Rh9C60LjQvSDQmtC+0L3RgdGC0LDQvdGC0LjQvQ==?=) Date: Wed, 15 Jan 2014 09:42:09 +0600 Subject: =?UTF-8?B?UkU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> <52D436BA.2070302@itcraft.org> Message-ID: <016e01cf11a3$c55d9620$5018c260$@gmail.com> Можете пояснить, что за ?проблема недулевого TTL?? Что мешает выставить ttl для ns и А записей нулевым? Кроме роста нагрузки на сеть, естественно. From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Алексей Сундуков Sent: Tuesday, January 14, 2014 8:10 PM To: nginx-ru at nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? >Данное решение все-же лучше, чем ничего. Рад выслушать альтернативные решения, >которые работают вне пределов одного датацентра. DNS сервер на той же машине, что и веб сервер + А запись на саму себя. Т.е. на host1 крутиться DNS который для домена отдает только одну А запись, причем она ведет на IP адрес host1. А на host2 тоже самое, но только ведет на IP адрес host2. Ну а в NS-ах конечно же указаны оба IP адреса. К сожалению это решает вопрос только с первичным резолвингом и для клиентов которые уже запись откэшили сайт окажется недоступным. Поэтому "проблема недулевого TTL" остается для вернувшихся на сайте посетителей. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel2000 at ngs.ru Wed Jan 15 07:46:11 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Wed, 15 Jan 2014 14:46:11 +0700 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <59771389702252@web1g.yandex.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> Message-ID: <114997541.20140115144611@ngs.ru> Здравствуйте, Васильев. Вы писали 14 января 2014 г., 19:24:12: > Вклинюсь в тред. Если вам нужно организовать надёжность связи с вашими серверами, у которых два > аплинка, то да, вам просто нужна ВПС-ка фронтенд. Если вы хотите общую отказоустойчивость, то у > вас появляется новая единая точка отказа - внешняя ВПС-ка. Тоже, пожалуй, вклинюсь в тред. Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов. От них сделать каналы до серверов (с каждой впски через каждый из аплинков) В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал выбирался нужным образом. На эти же впски можно выкинуть некий статический контент... Для этих же впсок можно прислюнявить DNS "с ненулевым TTL", чтобы исключать впски из схемы в случае их падения.. Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и необходимость!) этими наворотами заниматься. > 14.01.2014, 13:58, "Vladimir Skubriev" : >> 14.01.2014 13:46, Артем Васильев пишет: >> >>> При сильном желании сервить свой крутой и ценный проект на локалхосте - покупается AS, ставится роутер, который может, любит, и умеет в bgp, подключается 2-3 провайдера по оптике c нормальным sla. В противном случае можно продолжать есть кактус с подобными вопросами и запросами, либо выбрать более-менее нормальный хостинг/vps (их есть в россии, и немало, даже для параноиков с особо ценными разработками) >> В вашем предложении для меня сильно много "не знакомых слов". Поэтому циски, bgp и провайдеры со sla идут лесом. Это слишком круто. >> >> В таком случае Вы за frontend nginx на vps вместо update dns via api and small ttl? >> >> -- -- Faithfully yours, Vladimir Skubriev >> , >> _______________________________________________ >> 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 -- С уважением, Pavel mailto:pavel2000 at ngs.ru From public-mail at alekciy.ru Wed Jan 15 08:14:37 2014 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Wed, 15 Jan 2014 12:14:37 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <016e01cf11a3$c55d9620$5018c260$@gmail.com> References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> <52D436BA.2070302@itcraft.org> <016e01cf11a3$c55d9620$5018c260$@gmail.com> Message-ID: > Можете пояснить, что за ?проблема недулевого TTL?? > Что мешает выставить ttl для ns и А записей нулевым? Кроме роста нагрузки на сеть, естественно. Ни чего не мешает. Только на практике между нашим DNS и браузером посетителя ХХ кэширующих DNS провайдера. Который может указанные нулевые TTL игнорировать в лучшем случае. В худшем быть вообще криво настроенным (грешат обычно мелкие провайдеры уровня район/населенный_пункт). -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsjcfm at gmail.com Wed Jan 15 08:24:41 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Wed, 15 Jan 2014 10:24:41 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> <52D436BA.2070302@itcraft.org> <016e01cf11a3$c55d9620$5018c260$@gmail.com> Message-ID: 15 января 2014 г., 10:14 пользователь Алексей Сундуков написал: > Ни чего не мешает. Только на практике между нашим DNS и браузером посетителя > ХХ кэширующих DNS провайдера. Который может указанные нулевые TTL > игнорировать в лучшем случае. Серьёзно? А можно пример настройки игнорировния TTL для bind9? > В худшем быть вообще криво настроенным (грешат > обычно мелкие провайдеры уровня район/населенный_пункт). From public-mail at alekciy.ru Wed Jan 15 08:27:55 2014 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Wed, 15 Jan 2014 12:27:55 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> <52D436BA.2070302@itcraft.org> <016e01cf11a3$c55d9620$5018c260$@gmail.com> Message-ID: > Серьёзно? А можно пример настройки игнорировния TTL для bind9? Серьезно. А я разве говорил о bind-е? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsjcfm at gmail.com Wed Jan 15 08:30:33 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Wed, 15 Jan 2014 10:30:33 +0200 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> <52D42DBE.3070409@itcraft.org> <1967078.pRY3lv2aJc@vbart-laptop> <52D436BA.2070302@itcraft.org> <016e01cf11a3$c55d9620$5018c260$@gmail.com> Message-ID: 15 января 2014 г., 10:27 пользователь Алексей Сундуков написал: >> Серьёзно? А можно пример настройки игнорировния TTL для bind9? > Серьезно. А я разве говорил о bind-е? Так покажите же, что это за чудный DNS-сервер и как в нём это настроить. Ради такого дела даже поставлю где-нибудь. From vbart at nginx.com Wed Jan 15 08:37:40 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 15 Jan 2014 12:37:40 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <52D404B6.40809@skubriev.ru> Message-ID: <1858270.JtGaG7WL9B@vbart-laptop> On Wednesday 15 January 2014 10:30:33 Anton Sayetsky wrote: > 15 января 2014 г., 10:27 пользователь Алексей Сундуков > написал: > >> Серьёзно? А можно пример настройки игнорировния TTL для bind9? > > Серьезно. А я разве говорил о bind-е? > Так покажите же, что это за чудный DNS-сервер и как в нём это > настроить. Ради такого дела даже поставлю где-нибудь. http://mark.lindsey.name/2009/03/never-use-dns-ttl-of-zero-0.html https://00f.net/2011/11/17/how-long-does-a-dns-ttl-last/ -- Валентин Бартенев From vladimir at skubriev.ru Wed Jan 15 09:09:52 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Wed, 15 Jan 2014 13:09:52 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <114997541.20140115144611@ngs.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> <114997541.20140115144611@ngs.ru> Message-ID: <52D65060.8040702@skubriev.ru> 15.01.2014 11:46, Pavel V. пишет: > Тоже, пожалуй, вклинюсь в тред. > > Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов. > От них сделать каналы до серверов (с каждой впски через каждый из аплинков) Вы имеете в виду VPN ? > В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал выбирался нужным > образом. если BGP можно реализовать стандартными спсобами linux то я рассмотрю этот вариант. > На эти же впски можно выкинуть некий статический контент... > Для этих же впсок можно прислюнявить DNS "с ненулевым TTL", чтобы исключать впски из схемы в случае их > падения.. Я уже если честно запутался во все возможных вариантах. Можете пояснить куда его прислюнявить и зачем ? Если положим есть у нас fronend с nginx на который ссылается A запись www.example.com и example.com. Есть Бэкенд, который доступен только для frontend по IP адресу. Зачем еще DNS сервер(ы) не пониманию если честно. > Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и необходимость!) этими наворотами > заниматься. > > -- -- Faithfully yours, Vladimir Skubriev From pavel2000 at ngs.ru Wed Jan 15 09:47:26 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Wed, 15 Jan 2014 16:47:26 +0700 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D65060.8040702@skubriev.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> <114997541.20140115144611@ngs.ru> <52D65060.8040702@skubriev.ru> Message-ID: <1873052422.20140115164726@ngs.ru> Здравствуйте, Vladimir. >> Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов. >> От них сделать каналы до серверов (с каждой впски через каждый из аплинков) > Вы имеете в виду VPN ? Как один из вариантов - да. Хотя можно обойтись и прямым проксированием. >> В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал выбирался нужным >> образом. > если BGP можно реализовать стандартными спсобами linux то я рассмотрю > этот вариант. можно. >> На эти же впски можно выкинуть некий статический контент... >> Для этих же впсок можно прислюнявить DNS "с ненулевым TTL", чтобы исключать впски из схемы в случае их >> падения.. > Я уже если честно запутался во все возможных вариантах. Можете пояснить > куда его прислюнявить и зачем ? > Зачем еще DNS сервер(ы) не пониманию если честно. Вы не внимательно читаете. Я уже написал, зачем. Попробуйте прочитать снова. >> Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и необходимость!) этими наворотами >> заниматься. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From mdounin at mdounin.ru Wed Jan 15 16:39:44 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 15 Jan 2014 20:39:44 +0400 Subject: [PATCH] implemented hardlink option in DAV module In-Reply-To: <661787979.20140114213322@softsearch.ru> References: <1350301244-27123-1-git-send-email-arut@qip.ru> <20121015153350.GH40452@mdounin.ru> <991838356.20121015233055@softsearch.ru> <507C6A98.9090903@csdoc.com> <1044505139.20121016001438@softsearch.ru> <20121016101653.GP40452@mdounin.ru> <20121016171051.GX40452@mdounin.ru> <1042482698.20121016213113@softsearch.ru> <20121016174821.GA40452@mdounin.ru> <661787979.20140114213322@softsearch.ru> Message-ID: <20140115163944.GX1835@mdounin.ru> Hello! On Tue, Jan 14, 2014 at 09:33:22PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > Это cut-n-paste ошибка в виндовой части кода, которую я поленился > > проверить и недоправил. Там должно быть date, исправленный патч > > прилагается. > > Затестировали сейчас патч, добавляющий метод TOUCH. Лучше поздно, чем > никогда. :-) > > Он работает, но похоже не использует aio. 30 процессов nginx висит в > состоянии biord, а при этом запущено всего пяток aiodХХ из сотни > возможных. Хотя второе объяснение подобному - это большая вложенность > директорий. А третье - aio не умеет работать с директориями. Не знаю, > какое верное. К сожалению, aio-операций для создания/открытия файлов - не существует. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html -- Maxim Dounin http://nginx.org/ From postmaster at softsearch.ru Wed Jan 15 18:17:20 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 15 Jan 2014 22:17:20 +0400 Subject: [PATCH] implemented hardlink option in DAV module In-Reply-To: <20140115163944.GX1835@mdounin.ru> References: <1350301244-27123-1-git-send-email-arut@qip.ru> <20121015153350.GH40452@mdounin.ru> <991838356.20121015233055@softsearch.ru> <507C6A98.9090903@csdoc.com> <1044505139.20121016001438@softsearch.ru> <20121016101653.GP40452@mdounin.ru> <20121016171051.GX40452@mdounin.ru> <1042482698.20121016213113@softsearch.ru> <20121016174821.GA40452@mdounin.ru> <661787979.20140114213322@softsearch.ru> <20140115163944.GX1835@mdounin.ru> Message-ID: <1604452099.20140115221720@softsearch.ru> Здравствуйте, Maxim. >> > Это cut-n-paste ошибка в виндовой части кода, которую я поленился >> > проверить и недоправил. Там должно быть date, исправленный патч >> > прилагается. >> >> Затестировали сейчас патч, добавляющий метод TOUCH. Лучше поздно, чем >> никогда. :-) >> >> Он работает, но похоже не использует aio. 30 процессов nginx висит в >> состоянии biord, а при этом запущено всего пяток aiodХХ из сотни >> возможных. Хотя второе объяснение подобному - это большая вложенность >> директорий. А третье - aio не умеет работать с директориями. Не знаю, >> какое верное. > К сожалению, aio-операций для создания/открытия файлов - не > существует. > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html В libuv , поверх которой Node.JS, все файловые операции, включая открытие файла, асинхронные: http://nodejs.org/api/fs.html#fs_fs_open_path_flags_mode_callback . Не знаю, правда, как они там внутри это сделали... -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Wed Jan 15 19:10:58 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 15 Jan 2014 23:10:58 +0400 Subject: [PATCH] implemented hardlink option in DAV module In-Reply-To: <1604452099.20140115221720@softsearch.ru> References: <1350301244-27123-1-git-send-email-arut@qip.ru> <20140115163944.GX1835@mdounin.ru> <1604452099.20140115221720@softsearch.ru> Message-ID: <1836263.ZhTYjEQrIJ@vbart-laptop> On Wednesday 15 January 2014 22:17:20 Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> > Это cut-n-paste ошибка в виндовой части кода, которую я поленился > >> > проверить и недоправил. Там должно быть date, исправленный патч > >> > прилагается. > >> > >> Затестировали сейчас патч, добавляющий метод TOUCH. Лучше поздно, чем > >> никогда. :-) > >> > >> Он работает, но похоже не использует aio. 30 процессов nginx висит в > >> состоянии biord, а при этом запущено всего пяток aiodХХ из сотни > >> возможных. Хотя второе объяснение подобному - это большая вложенность > >> директорий. А третье - aio не умеет работать с директориями. Не знаю, > >> какое верное. > > > К сожалению, aio-операций для создания/открытия файлов - не > > существует. > > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html > > В libuv , поверх которой Node.JS, все файловые операции, включая > открытие файла, асинхронные: > http://nodejs.org/api/fs.html#fs_fs_open_path_flags_mode_callback . > Не знаю, правда, как они там внутри это сделали... > Внутри там thread pool. -- Валентин Бартенев From zmey1992 at ya.ru Fri Jan 17 08:09:08 2014 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Fri, 17 Jan 2014 12:09:08 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <114997541.20140115144611@ngs.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> <114997541.20140115144611@ngs.ru> Message-ID: <148271389946148@web4h.yandex.ru> В таком случае мы усложняем схему и у нас половина клиентов может потеряться не на умершем канале в офис, а на упавшей ВПСке. Тогда нужен полноценный failover и всё такое. Но автор топика уже пояснил свои цели и намерения, так что схемы с одной VPS-frontend хватит, полагаю. 15.01.2014, 11:46, "Pavel V." : > Здравствуйте, Васильев. > > Вы писали 14 января 2014 г., 19:24:12: > >>  Вклинюсь в тред. Если вам нужно организовать надёжность связи с вашими серверами, у которых два >>  аплинка, то да, вам просто нужна ВПС-ка фронтенд. Если вы хотите общую отказоустойчивость, то у >>  вас появляется новая единая точка отказа - внешняя ВПС-ка. > > Тоже, пожалуй, вклинюсь в тред. > > Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов. > От них сделать каналы до серверов (с каждой впски через каждый из аплинков) > В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал выбирался нужным > образом. > На эти же впски можно выкинуть некий статический контент... > Для этих же впсок можно прислюнявить DNS "с ненулевым TTL", чтобы исключать впски из схемы в случае их > падения.. > > Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и необходимость!) этими наворотами > заниматься. > >>  14.01.2014, 13:58, "Vladimir Skubriev" : >>>  14.01.2014 13:46, Артем Васильев пишет: >>>>  При сильном желании сервить свой крутой и ценный проект на локалхосте - покупается AS, ставится роутер, который может, любит, и умеет в bgp, подключается 2-3 провайдера по оптике c нормальным sla. В противном случае можно продолжать есть кактус с подобными вопросами и запросами, либо выбрать более-менее нормальный хостинг/vps (их есть в россии, и немало, даже для параноиков с особо ценными разработками) >>>  В вашем предложении для меня сильно много "не знакомых слов". Поэтому циски, bgp и провайдеры со sla идут лесом. Это слишком круто. >>> >>>  В таком случае Вы за frontend nginx на vps вместо update dns via api and small ttl? >>> >>>  -- -- Faithfully yours, Vladimir Skubriev >>>  , >>>  _______________________________________________ >>>  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 > > -- > С уважением, >  Pavel                          mailto:pavel2000 at ngs.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vladimir at skubriev.ru Fri Jan 17 08:21:40 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Fri, 17 Jan 2014 12:21:40 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <148271389946148@web4h.yandex.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> <114997541.20140115144611@ngs.ru> <148271389946148@web4h.yandex.ru> Message-ID: <52D8E814.7080202@skubriev.ru> 17.01.2014 12:09, Васильев "Zmey!" Олег пишет: > В таком случае мы усложняем схему и у нас половина клиентов может потеряться не на умершем канале в офис, а на упавшей ВПСке. Тогда нужен полноценный failover и всё такое. Но автор топика уже пояснил свои цели и намерения, так что схемы с одной VPS-frontend хватит, полагаю. > Так сказать, чтобы подтвердить то, как я понял что мне лушче сделать - отвечу Вам. Если умрет одна ВПС-ка - то это равнозначно тому, что в городе не будет Интернет. Что в принципе не очень критично, т.к. такое бывает редко. День без сайта мы потертим. А более дня я считаю со сторону хостера не приемлево в принципе. -- -- Faithfully yours, Vladimir Skubriev From onokonem at gmail.com Fri Jan 17 08:26:01 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 17 Jan 2014 12:26:01 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: <52D8E814.7080202@skubriev.ru> References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> <114997541.20140115144611@ngs.ru> <148271389946148@web4h.yandex.ru> <52D8E814.7080202@skubriev.ru> Message-ID: 2014/1/17 Vladimir Skubriev : > День без сайта мы потертим. А более дня я считаю со сторону хостера не > приемлево в принципе. Перекинуть DNS на другого хостера можно значительно быстрее, чем за день. Можно поднять резервный прокси в амазоне. Вернее - подготовить AMI. Он, когда выключен, денег не ест. Трафик там, правда, довольно дорогой... From vladimir at skubriev.ru Fri Jan 17 08:50:12 2014 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Fri, 17 Jan 2014 12:50:12 +0400 Subject: =?UTF-8?B?UmU6INC00LLQtSDQkCDQt9Cw0L/QuNGB0Lgg0LIgRE5TIC0g0LHRg9C00LXRgiA=?= =?UTF-8?B?0LvQuCDRgtC+0YDQvNC+0LfQuNGC0YwsINC10YHQu9C4INC+0LTQuNC9INC4?= =?UTF-8?B?0Lcg0L/RgNC+0LLQsNC50LTQtdGA0L7QsiDQvtGC0LLQsNC70LjRgtGB0Y8g?= =?UTF-8?B?Pw==?= In-Reply-To: References: <005101cf10df$8faf5e60$af0e1b20$@gmail.com> <52D4C05B.8050903@skubriev.ru> <005301cf10e7$167b1a90$43714fb0$@gmail.com> <52D4C956.1090107@skubriev.ru> <005501cf10eb$f317dca0$d94795e0$@gmail.com> <00a201cf1105$0a0dd0e0$1e2972a0$@gmail.com> <52D50178.30306@skubriev.ru> <20140114093142.GM13849@ufanet.ru> <52D50A3A.60707@skubriev.ru> <59771389702252@web1g.yandex.ru> <114997541.20140115144611@ngs.ru> <148271389946148@web4h.yandex.ru> <52D8E814.7080202@skubriev.ru> Message-ID: <52D8EEC4.8090405@skubriev.ru> 17.01.2014 12:26, Daniel Podolsky пишет: > 2014/1/17 Vladimir Skubriev : >> День без сайта мы потертим. А более дня я считаю со сторону хостера не >> приемлево в принципе. > Перекинуть DNS на другого хостера можно значительно быстрее, чем за день. > > Можно поднять резервный прокси в амазоне. Вернее - подготовить AMI. > Он, когда выключен, денег не ест. Трафик там, правда, довольно > дорогой... Спасибо я обязательно обращу на этот совет внимание руководства. Тем более что они положительно относятся к амазону. -- -- Faithfully yours, Vladimir Skubriev From nginx-forum at nginx.us Fri Jan 17 14:53:57 2014 From: nginx-forum at nginx.us (izlom) Date: Fri, 17 Jan 2014 09:53:57 -0500 Subject: Nginx maps Message-ID: Имеется некий конфиг - суть раскидать мапы по принцыпу: "каждому ипу - своя карта". Кусок конифига: include /etc/nginx/nginx_maps/x.x.x.x; server { listen x.x.x.x:80 default deferred; server_name _; include /etc/nginx/nginx_maps.conf; } include /etc/nginx/nginx_maps/y.y.y.y; server { listen y.y.y.y:80 default deferred; listen [0xipv6]:80 default deferred; server_name _; include /etc/nginx/nginx_maps.conf; } include /etc/nginx/nginx_maps/xy.xy.xy.xy; server { listen xy.xy.xy.xy:80 default deferred; listen [1xipv6]:80 default deferred; listen [2xipv6]:80 default deferred; server_name _; include /etc/nginx/nginx_maps.conf; } Все было бы хорошо, если бы не использовались только карты из последнего инклуда. В прежних версиях это работало. Версия Nginx 1.4.4 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246561,246561#msg-246561 From postmaster at softsearch.ru Sun Jan 19 09:19:32 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 19 Jan 2014 13:19:32 +0400 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzRiyDRgSDQutGN0YjQtdC8?= Message-ID: <955964865.20140119131932@softsearch.ru> Здравствуйте. Есть 3 кэша на разных разделах. Вдруг один из них начал очень быстро расти и кончилось свободное место на разделе, а два других начали так же резко уменьшаться в размерах. При этом nginx иногда был недоступен. А после его рестарта, если смотреть top, то дисковая активность периодически полностью пропадает на несколько секунд и потом снова появлялась. Такое ощущение, что вся ОС блокируется где-то на одной операции чтения с диска. Сам рестарт помог. Место, занятое кэшем освободилось. Чтобы это могло быть? -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Sun Jan 19 21:28:45 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 20 Jan 2014 01:28:45 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEg0LrRjdGI0LXQvA==?= In-Reply-To: <955964865.20140119131932@softsearch.ru> References: <955964865.20140119131932@softsearch.ru> Message-ID: <104699830.20140120012845@softsearch.ru> Здравствуйте. Вдогонку... nginx version: nginx/1.5.7 configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_image_filter_module --with-http_stub_status_module --with-pcre Тот факт, что один кэш, описанный в конфиге первым начал терять файлы, а другой, описанный в конфиге третьим, начал их накапливать ИМХО, говорит о какой-то ошибке в коде nginx-а. Сначала думал, что у меня проблемы с дисками, но в логах полная тишина, SMART тоже ничего не кажет. -- С уважением, Михаил mailto:postmaster at softsearch.ru From anatoly at sonru.com Mon Jan 20 00:30:09 2014 From: anatoly at sonru.com (Anatoly Mikhaylov) Date: Mon, 20 Jan 2014 00:30:09 +0000 Subject: =?UTF-8?B?0JrRjdGI0LjRgNC+0LLQsNC90LjQtSDRgdGC0LDRgtC40LrQuCwg0LrQvtGC0L4=?= =?UTF-8?B?0YDRg9GOINCz0LXQvdC10YDQuNGA0YPQtdGCINCx0Y3QutGN0L3QtA==?= Message-ID: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> Добрый день, Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? Анатолий From chipitsine at gmail.com Mon Jan 20 05:05:27 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 20 Jan 2014 11:05:27 +0600 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> Message-ID: teamcity очень мало статики отдает. для jira лучше настроить keepalive до бекенда а stash - это что именно ? 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov написал: > Добрый день, > > Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. > > Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? > > Анатолий > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Mon Jan 20 08:30:50 2014 From: anatoly at sonru.com (Anatoly Mikhaylov) Date: Mon, 20 Jan 2014 08:30:50 +0000 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> Message-ID: Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http запросы за ее получением через Catalina. Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка прикрыть глупость организации отдачи контента, который, во многих случаях, не меняется никогда. Одно дело - все эти украшения для статики, которую отдает Nginx напрямую с диска, но в данном случае все это отдается через бэкэнд. Так и остается загадкой зачем было сделанно именно так. Суть задачи не меняется, кэшировать статику (в случае с jira: location /s/) после первого обращения к ней. Proxy pass cache - копать в эту сторону? Анатолий > On Jan 20, 2014, at 5:05 AM, Илья Шипицин wrote: > > teamcity очень мало статики отдает. > для jira лучше настроить keepalive до бекенда > а stash - это что именно ? > > 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov > написал: >> Добрый день, >> >> Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. >> >> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? >> >> Анатолий >> _______________________________________________ >> 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 nginx-forum at nginx.us Mon Jan 20 09:04:50 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 20 Jan 2014 04:04:50 -0500 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: References: Message-ID: <8cdc39306ce5c65e71a1ff2f2e076b40.NginxMailingListRussian@forum.nginx.org> > >> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не > препятствовало основному проксированию ответа http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246604,246613#msg-246613 From anatoly at sonru.com Mon Jan 20 09:57:22 2014 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 20 Jan 2014 09:57:22 +0000 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: <8cdc39306ce5c65e71a1ff2f2e076b40.NginxMailingListRussian@forum.nginx.org> References: <8cdc39306ce5c65e71a1ff2f2e076b40.NginxMailingListRussian@forum.nginx.org> Message-ID: <522B38F8-9378-492E-9C74-8C4D4CB876D7@sonru.com> On 20 Jan 2014, at 09:04, S.A.N wrote: >>>> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не >> препятствовало основному проксированию ответа > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache гуглить умею, администрировать тоже, интересует кто и как решал такую задачу, так как мои попытки настроить пока безуспешны Анатолий > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246604,246613#msg-246613 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Mon Jan 20 10:35:18 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 20 Jan 2014 16:35:18 +0600 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> Message-ID: у jira, teamcity узкое место - само приложение. оно начинает загибаться гораздо раньше, чем становятся заметны проблемы с отдачей статики. оптимизировать именно статику в данном случае - предпосылка непонятная 20 января 2014 г., 14:30 пользователь Anatoly Mikhaylov написал: > Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http запросы за ее получением через Catalina. > > Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка прикрыть глупость организации отдачи контента, который, во многих случаях, не меняется никогда. Одно дело - все эти украшения для статики, которую отдает Nginx напрямую с диска, но в данном случае все это отдается через бэкэнд. Так и остается загадкой зачем было сделанно именно так. > > Суть задачи не меняется, кэшировать статику (в случае с jira: location /s/) после первого обращения к ней. Proxy pass cache - копать в эту сторону? > > Анатолий > >> On Jan 20, 2014, at 5:05 AM, Илья Шипицин wrote: >> >> teamcity очень мало статики отдает. >> для jira лучше настроить keepalive до бекенда >> а stash - это что именно ? >> >> 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov >> написал: >>> Добрый день, >>> >>> Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. >>> >>> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? >>> >>> Анатолий >>> _______________________________________________ >>> 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 anatoly at sonru.com Mon Jan 20 10:52:43 2014 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 20 Jan 2014 10:52:43 +0000 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> Message-ID: <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com> в нашем случае - локально настроенная Jira с 10 пользователями, сомневаюсь, что приложение загнется при такой нагрузке. и все же, кто как кэширует статику, сгенерированную налету? Анатолий On 20 Jan 2014, at 10:35, Илья Шипицин wrote: > у jira, teamcity узкое место - само приложение. оно начинает > загибаться гораздо раньше, чем становятся заметны проблемы с отдачей > статики. > оптимизировать именно статику в данном случае - предпосылка непонятная > > 20 января 2014 г., 14:30 пользователь Anatoly Mikhaylov > написал: >> Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http запросы за ее получением через Catalina. >> >> Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка прикрыть глупость организации отдачи контента, который, во многих случаях, не меняется никогда. Одно дело - все эти украшения для статики, которую отдает Nginx напрямую с диска, но в данном случае все это отдается через бэкэнд. Так и остается загадкой зачем было сделанно именно так. >> >> Суть задачи не меняется, кэшировать статику (в случае с jira: location /s/) после первого обращения к ней. Proxy pass cache - копать в эту сторону? >> >> Анатолий >> >>> On Jan 20, 2014, at 5:05 AM, Илья Шипицин wrote: >>> >>> teamcity очень мало статики отдает. >>> для jira лучше настроить keepalive до бекенда >>> а stash - это что именно ? >>> >>> 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov >>> написал: >>>> Добрый день, >>>> >>>> Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. >>>> >>>> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? >>>> >>>> Анатолий >>>> _______________________________________________ >>>> 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 chipitsine at gmail.com Mon Jan 20 11:00:46 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 20 Jan 2014 17:00:46 +0600 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com> References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com> Message-ID: https://jira.XXXX.ru/s/ru_RUsu9vq5-1988229788/6097/5/e1f48b4b2dac40253e06ee982f4b3682/_/download/contextbatch/css/atl.general,jira.global/batch.css - прилетает с хедерами, позволяющими кеш если вы включите обычный кеш на nginx - будет кешироваться если не включите, будет кешить сам браузер, что примерно одно и то же. но какого-то заметного профита в случае кеширования jira не будет по моему опыту, у нее статика не составляет существенной нагрузки. 20 января 2014 г., 16:52 пользователь Anatoly Mikhailov написал: > в нашем случае - локально настроенная Jira с 10 пользователями, > сомневаюсь, что приложение загнется при такой нагрузке. > > и все же, кто как кэширует статику, сгенерированную налету? > > Анатолий > > On 20 Jan 2014, at 10:35, Илья Шипицин wrote: > >> у jira, teamcity узкое место - само приложение. оно начинает >> загибаться гораздо раньше, чем становятся заметны проблемы с отдачей >> статики. >> оптимизировать именно статику в данном случае - предпосылка непонятная >> >> 20 января 2014 г., 14:30 пользователь Anatoly Mikhaylov >> написал: >>> Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http запросы за ее получением через Catalina. >>> >>> Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка прикрыть глупость организации отдачи контента, который, во многих случаях, не меняется никогда. Одно дело - все эти украшения для статики, которую отдает Nginx напрямую с диска, но в данном случае все это отдается через бэкэнд. Так и остается загадкой зачем было сделанно именно так. >>> >>> Суть задачи не меняется, кэшировать статику (в случае с jira: location /s/) после первого обращения к ней. Proxy pass cache - копать в эту сторону? >>> >>> Анатолий >>> >>>> On Jan 20, 2014, at 5:05 AM, Илья Шипицин wrote: >>>> >>>> teamcity очень мало статики отдает. >>>> для jira лучше настроить keepalive до бекенда >>>> а stash - это что именно ? >>>> >>>> 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov >>>> написал: >>>>> Добрый день, >>>>> >>>>> Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. >>>>> >>>>> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? >>>>> >>>>> Анатолий >>>>> _______________________________________________ >>>>> 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 igor at sysoev.ru Mon Jan 20 11:02:22 2014 From: igor at sysoev.ru (Igor Sysoev) Date: Mon, 20 Jan 2014 15:02:22 +0400 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com> References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com> Message-ID: <914BE6DF-0EEA-4420-9ACA-E6F2D5D769BC@sysoev.ru> On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote: > в нашем случае - локально настроенная Jira с 10 пользователями, > сомневаюсь, что приложение загнется при такой нагрузке. > > и все же, кто как кэширует статику, сгенерированную налету? http { proxy_cache_path /path/to/cache keys_zone=CACHE:20M; proxy_temp_path /path/to/temp; server { location /static/ { proxy_pass http://backend; proxy_cache CACHE; proxy_cache_valid 1h; } } } -- Igor Sysoev > Анатолий > > On 20 Jan 2014, at 10:35, Илья Шипицин wrote: > >> у jira, teamcity узкое место - само приложение. оно начинает >> загибаться гораздо раньше, чем становятся заметны проблемы с отдачей >> статики. >> оптимизировать именно статику в данном случае - предпосылка непонятная >> >> 20 января 2014 г., 14:30 пользователь Anatoly Mikhaylov >> написал: >>> Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http запросы за ее получением через Catalina. >>> >>> Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка прикрыть глупость организации отдачи контента, который, во многих случаях, не меняется никогда. Одно дело - все эти украшения для статики, которую отдает Nginx напрямую с диска, но в данном случае все это отдается через бэкэнд. Так и остается загадкой зачем было сделанно именно так. >>> >>> Суть задачи не меняется, кэшировать статику (в случае с jira: location /s/) после первого обращения к ней. Proxy pass cache - копать в эту сторону? >>> >>> Анатолий >>> >>>> On Jan 20, 2014, at 5:05 AM, Илья Шипицин wrote: >>>> >>>> teamcity очень мало статики отдает. >>>> для jira лучше настроить keepalive до бекенда >>>> а stash - это что именно ? >>>> >>>> 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov >>>> написал: >>>>> Добрый день, >>>>> >>>>> Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. >>>>> >>>>> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? >>>>> >>>>> Анатолий >>>>> _______________________________________________ >>>>> 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 anatoly at sonru.com Mon Jan 20 11:27:05 2014 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 20 Jan 2014 11:27:05 +0000 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: <914BE6DF-0EEA-4420-9ACA-E6F2D5D769BC@sysoev.ru> References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com> <914BE6DF-0EEA-4420-9ACA-E6F2D5D769BC@sysoev.ru> Message-ID: On 20 Jan 2014, at 11:02, Igor Sysoev wrote: > On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote: > >> в нашем случае - локально настроенная Jira с 10 пользователями, >> сомневаюсь, что приложение загнется при такой нагрузке. >> >> и все же, кто как кэширует статику, сгенерированную налету? > > http { > proxy_cache_path /path/to/cache keys_zone=CACHE:20M; > proxy_temp_path /path/to/temp; > > server { > location /static/ { > proxy_pass http://backend; > proxy_cache CACHE; > proxy_cache_valid 1h; > } > } > } Игорь, спасибо, проблема решена, но возможно не оптимальным образом: proxy_cache_path /.../nginx/cache levels=1:2 keys_zone=STATIC:20M; proxy_temp_path /.../nginx/tmp; server { listen 8000; location /jira { proxy_pass http://jira_upstream/jira; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-for $remote_addr; proxy_redirect off; proxy_connect_timeout 120; proxy_send_timeout 120; proxy_read_timeout 180; } location /jira/s/ { proxy_pass http://jira_upstream/jira/s/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-for $remote_addr; proxy_redirect off; proxy_connect_timeout 120; proxy_send_timeout 120; proxy_read_timeout 180; proxy_ignore_headers "Set-Cookie"; proxy_cache STATIC; proxy_cache_valid 60m; } Анатолий > > > -- > Igor Sysoev > >> Анатолий >> >> On 20 Jan 2014, at 10:35, Илья Шипицин wrote: >> >>> у jira, teamcity узкое место - само приложение. оно начинает >>> загибаться гораздо раньше, чем становятся заметны проблемы с отдачей >>> статики. >>> оптимизировать именно статику в данном случае - предпосылка непонятная >>> >>> 20 января 2014 г., 14:30 пользователь Anatoly Mikhaylov >>> написал: >>>> Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http запросы за ее получением через Catalina. >>>> >>>> Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка прикрыть глупость организации отдачи контента, который, во многих случаях, не меняется никогда. Одно дело - все эти украшения для статики, которую отдает Nginx напрямую с диска, но в данном случае все это отдается через бэкэнд. Так и остается загадкой зачем было сделанно именно так. >>>> >>>> Суть задачи не меняется, кэшировать статику (в случае с jira: location /s/) после первого обращения к ней. Proxy pass cache - копать в эту сторону? >>>> >>>> Анатолий >>>> >>>>> On Jan 20, 2014, at 5:05 AM, Илья Шипицин wrote: >>>>> >>>>> teamcity очень мало статики отдает. >>>>> для jira лучше настроить keepalive до бекенда >>>>> а stash - это что именно ? >>>>> >>>>> 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov >>>>> написал: >>>>>> Добрый день, >>>>>> >>>>>> Есть несколько java-приложений (stash, jira, teamcity), в которых статика генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас организовано элементарное проксирование proxy_pass и все работает, но медленно. >>>>>> >>>>>> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа бэкэнда? >>>>>> >>>>>> Анатолий >>>>>> _______________________________________________ >>>>>> 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 igor at sysoev.ru Mon Jan 20 11:41:22 2014 From: igor at sysoev.ru (Igor Sysoev) Date: Mon, 20 Jan 2014 15:41:22 +0400 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?= =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?= In-Reply-To: References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com> <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com> <914BE6DF-0EEA-4420-9ACA-E6F2D5D769BC@sysoev.ru> Message-ID: On Jan 20, 2014, at 15:27 , Anatoly Mikhailov wrote: > > On 20 Jan 2014, at 11:02, Igor Sysoev wrote: > >> On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote: >> >>> в нашем случае - локально настроенная Jira с 10 пользователями, >>> сомневаюсь, что приложение загнется при такой нагрузке. >>> >>> и все же, кто как кэширует статику, сгенерированную налету? >> >> http { >> proxy_cache_path /path/to/cache keys_zone=CACHE:20M; >> proxy_temp_path /path/to/temp; >> >> server { >> location /static/ { >> proxy_pass http://backend; >> proxy_cache CACHE; >> proxy_cache_valid 1h; >> } >> } >> } > > Игорь, спасибо, проблема решена, но возможно не оптимальным образом: > > proxy_cache_path /.../nginx/cache levels=1:2 keys_zone=STATIC:20M; > proxy_temp_path /.../nginx/tmp; > > server { > listen 8000; > > location /jira { > proxy_pass http://jira_upstream/jira; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-for $remote_addr; > proxy_redirect off; > proxy_connect_timeout 120; > proxy_send_timeout 120; > proxy_read_timeout 180; > } > > location /jira/s/ { > proxy_pass http://jira_upstream/jira/s/; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-for $remote_addr; > proxy_redirect off; > proxy_connect_timeout 120; > proxy_send_timeout 120; > proxy_read_timeout 180; > > proxy_ignore_headers "Set-Cookie"; Ещё нужно proxy_hide_header Set-Cookie; иначе клиенты будут получать чужие куки. -- Igor Sysoev http://nginx.com > proxy_cache STATIC; > proxy_cache_valid 60m; > } > > > Анатолий -------------- next part -------------- An HTML attachment was scrubbed... URL: From swood at fotofor.biz Mon Jan 20 16:03:12 2014 From: swood at fotofor.biz (Anton Kiryushkin) Date: Mon, 20 Jan 2014 20:03:12 +0400 Subject: proxy_pass https Message-ID: Всем доброго времени суток. Скажите, пожалуйста, правда ли, что если использовать proxy_pass https://, где этот самый proxy_pass слушает такой же nginx, то второму nginx никак не получить client_ip ? Первичный вывод сделан на основе прописывания на втором nginx в конфиге хоста опций: set_real_ip_from real_ip_header и лога, где видно осталось только айпи-адрес первого nginx. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From citrin at citrin.ru Mon Jan 20 16:10:04 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 20 Jan 2014 20:10:04 +0400 Subject: proxy_pass https In-Reply-To: References: Message-ID: <52DD4A5C.2040804@citrin.ru> On 01/20/14 20:03, Anton Kiryushkin wrote: > Первичный вывод сделан на основе прописывания на втором nginx в конфиге хоста опций: > > set_real_ip_from > > real_ip_header > Еще на 1-м nginx нужно proxy_set_header $remote_addr; From swood at fotofor.biz Mon Jan 20 16:28:01 2014 From: swood at fotofor.biz (Anton Kiryushkin) Date: Mon, 20 Jan 2014 20:28:01 +0400 Subject: proxy_pass https In-Reply-To: <52DD4A5C.2040804@citrin.ru> References: <52DD4A5C.2040804@citrin.ru> Message-ID: Да, это само собой. На 1-м у меня сейчас так: proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 20 января 2014 г., 20:10 пользователь Anton Yuzhaninov написал: > On 01/20/14 20:03, Anton Kiryushkin wrote: > >> Первичный вывод сделан на основе прописывания на втором nginx в конфиге >> хоста опций: >> >> set_real_ip_from >> >> real_ip_header >> >> > Еще на 1-м nginx нужно > > proxy_set_header $remote_addr; > > _______________________________________________ > 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 citrin at citrin.ru Mon Jan 20 16:38:35 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 20 Jan 2014 20:38:35 +0400 Subject: proxy_pass https In-Reply-To: References: <52DD4A5C.2040804@citrin.ru> Message-ID: <52DD510B.7020504@citrin.ru> On 01/20/14 20:28, Anton Kiryushkin wrote: > Да, это само собой. На 1-м у меня сейчас так: > > proxy_set_header X-Real-IP $remote_addr; > Ну тогда нужно смотреть debug log на 2-м nginx. From nginx-forum at nginx.us Mon Jan 20 18:48:49 2014 From: nginx-forum at nginx.us (oklas) Date: Mon, 20 Jan 2014 13:48:49 -0500 Subject: =?UTF-8?B?0JDQstGC0L7RgNC40LfQsNGG0LjRjw==?= Message-ID: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> Всем Доброго дня! Давно здесь видел тему не могу найти. Там обсуждались способы авторизации пользователя, использование redis для привязки куки и пользователя и прочее. Был предложен метод при котором redis/memcached и т.п. не используются а пользователь и пароль шифруются и засовываются в куки и отдаются назад а далее уже из куки определяем кто пользователь. Ключевое в предложении было использование AES (вроде бы) для шифрования Хотелось бы услышать мнения по данному методу, особенно вопросы безопасности хранения пароля в конфиге nginx. Хотелось бы найти этот топик, так как точно не помню какие там были слова что бы задать запрос в поиске, (может топик удалили уже). Всем спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246636,246636#msg-246636 From andrey at kopeyko.ru Mon Jan 20 18:49:50 2014 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Mon, 20 Jan 2014 22:49:50 +0400 Subject: proxy_pass https In-Reply-To: References: <52DD4A5C.2040804@citrin.ru> Message-ID: <52DD6FCE.9040107@kopeyko.ru> 20.01.2014 20:28, Anton Kiryushkin пишет: > Да, это само собой. На 1-м у меня сейчас так: > > proxy_set_header X-Real-IP $remote_addr; Тогда на втором сервере должно быть set_real_ip_from ; real_ip_header X-Real-IP; И смотрите что в логи пишется. -- Best regards, Andrey Kopeyko From postmaster at softsearch.ru Mon Jan 20 20:40:26 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 21 Jan 2014 00:40:26 +0400 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> Message-ID: <1149969710.20140121004026@softsearch.ru> Здравствуйте, oklas. Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А на стороне сервера считаешь хэш от логина, пароля, подсети и salt и смотришь, равен ли он тому, что пришёл в куках. Можно ещё юзерагента добавить по желанию. Такая авторизация привязывает юзера к его провайдеру и если кто-то сворует куки, они скорее всего не сработают. Ну и для смены мыла и пароля всегда требуешь явно ввести текущий пароль. Хэш-функцию вроде md5 использовать не надо. :-) -- С уважением, Михаил mailto:postmaster at softsearch.ru From citrin at citrin.ru Mon Jan 20 20:54:47 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 21 Jan 2014 00:54:47 +0400 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <1149969710.20140121004026@softsearch.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> Message-ID: <52DD8D17.5060706@citrin.ru> On 21.01.2014 00:40, Михаил Монашёв wrote: > Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А > на стороне сервера считаешь хэш от логина, пароля, подсети и salt и > смотришь, равен ли он тому, что пришёл в куках. Я не специалист по криптографии, но насколько понимаю просто хэша тут недостаточно, нужен HMAC. В инете на эту тему за 5 минут нашел только такую статью: http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ Но встречал и более наглядные объяснения, почему нельзя в куке для авторизации хранить просто хэш и нужен именно HMAC. From gmm at csdoc.com Mon Jan 20 21:24:06 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 20 Jan 2014 23:24:06 +0200 Subject: =?UTF-8?B?TXV0dWFsIGF1dGhlbnRpY2F0aW9uINGB0YDQtdC00YHRgtCy0LDQvNC4IG5naW54?= Message-ID: <52DD93F6.9030204@csdoc.com> Здравствуйте, All! Как сделать Mutual authentication между двумя сервисами с помощью nginx? На двух разных серверах nginx слушает на порту 443 и проксирует клиентские запросы на порт 80 backend`а. "На вход" проверка клиентского сертификата работает отлично. А когда backend делает клиентский запрос на 127.0.0.1:8080 - nginx проксирует этот запрос на 443 порт удаленного сервера по https. Но как сделать так, чтобы при proxy_pass nginx еще и предьявлял клиентский сертификат удаленному сервису? Или какой софт можно использовать здесь вместо nginx, если nginx это делать не умеет и такая функциональность в нем никогда не будет реализована по каким-то причинам? Хотя, это наверное была бы killer feature, полезная многим. Если только принимать https-запросы на уровне nginx, а отправлять https-запросы через само приложение - тогда будет layering violation и клиентскому приложению придется давать доступ к файлу ключа. Может быть кто-то уже решал такую или похожую задачу? -- Best regards, Gena From onokonem at gmail.com Mon Jan 20 21:50:29 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 21 Jan 2014 01:50:29 +0400 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <52DD8D17.5060706@citrin.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> Message-ID: >> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А >> на стороне сервера считаешь хэш от логина, пароля, подсети и salt и >> смотришь, равен ли он тому, что пришёл в куках. Суёшь в авторизационную куку логин пользователя, время жизни авторизации, salt, и хэш от логина, пароля, подсети, времени жизни, salt и секретного ключа. В учебнике так пишут :) При известной усидчивости можно даже скользящий ключ реализовать (два ключа, ротация, проверяются оба, для генерации очередной куки используется более новый). > Я не специалист по криптографии, но насколько понимаю просто хэша тут > недостаточно, нужен HMAC. Со всей очевидностью - да. From nginx-forum at nginx.us Tue Jan 21 08:26:04 2014 From: nginx-forum at nginx.us (CSRedRat) Date: Tue, 21 Jan 2014 03:26:04 -0500 Subject: NGINX + SCTP In-Reply-To: <1425B488-725A-4074-9409-47B756A46921@catap.ru> References: <1425B488-725A-4074-9409-47B756A46921@catap.ru> Message-ID: <3becfc102f49dbba35e22bebfad69672.NginxMailingListRussian@forum.nginx.org> А на чём там всё остановилось? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,224953,246647#msg-246647 From nginx-forum at nginx.us Tue Jan 21 09:53:54 2014 From: nginx-forum at nginx.us (oklas) Date: Tue, 21 Jan 2014 04:53:54 -0500 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: References: Message-ID: <91ee85fb2c196ba0e173d46da9367bf1.NginxMailingListRussian@forum.nginx.org> > Суёшь в авторизационную куку логин пользователя, время жизни > авторизации, salt, и хэш от логина, пароля, подсети, времени жизни, > salt и секретного ключа. А salt - это что за криптоприправа? Скользящий ключ была сразу мысль сделать. Первое что пришло в голову перегенерить периодически конфиг, или какой нибудь редис или вспомогательный сервис для управления этого сделать, но задача то как раз к тому чтоб уйти от вспомогательного сервиса. Интересно есть ли что готовое для всего этого? Если нет на сколько актуально и востребовано было бы, если бы заморочится все это делать в виде самостоятельного модуля? Было бы это интересно для существующих cms ? В cms все это есть, но вопервых унификация, во вторых cms и сред может работат совместно несколько (например cms+форум+маг+и.т.д). Много ли кто бы мог быть заинтересован в такой системе? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246636,246649#msg-246649 From onokonem at gmail.com Tue Jan 21 10:28:30 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 21 Jan 2014 14:28:30 +0400 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <91ee85fb2c196ba0e173d46da9367bf1.NginxMailingListRussian@forum.nginx.org> References: <91ee85fb2c196ba0e173d46da9367bf1.NginxMailingListRussian@forum.nginx.org> Message-ID: > А salt - это что за криптоприправа? Просто случайная строка. Если хеш считать без нее - он будет одинаковый для одинакового набора параметров, и атаку по словарю можно будет проводить сравнением строк. Если же добавить соль - даже одинаковые пароли дают разные хеши. И для атаки по словарю приходится пересчитывать хеши, что сильно замедляет процесс. From nginx-forum at nginx.us Tue Jan 21 10:56:10 2014 From: nginx-forum at nginx.us (oklas) Date: Tue, 21 Jan 2014 05:56:10 -0500 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: References: Message-ID: А, разумеется, я еще к этому хотел бы добавить, что для поточных шифров еще хорошо, даже обязательно распологать соль в самом начале потока данных чтобы по стандартным заголовкам не был угадан был ключ шифра. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246636,246653#msg-246653 From nginx-forum at nginx.us Tue Jan 21 14:34:02 2014 From: nginx-forum at nginx.us (Dimka) Date: Tue, 21 Jan 2014 09:34:02 -0500 Subject: =?UTF-8?B?TkdJTlggU1NMIFdlYlNvY2tldCDQv9GA0L7QsdGA0L7RgSDQsiBUb21jYXQ=?= Message-ID: Всем привет! Настроил HTTPS и WebSocket в томкат. Конфиг map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen *ВНЕШНИЙ АДРЕС*:443 ssl; ssl_certificate /opt/keystore/cert2/server.crt; ssl_certificate_key /opt/keystore/cert2/server.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; keepalive_timeout 70; server_name сайт.cc; access_log logs/https.access.log main; error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } # proxy to Tomcat listening on 127.0.0.1:8080 # location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarfed-For $proxy_add_x_forwarded_for; } location ~ ^/(css|js|img) { root /opt/tomcat/my_app/ROOT; expires max; } location /websocket { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; proxy_redirect off; proxy_buffers 8 32k; proxy_buffer_size 64k; } } Схема работает в chrome, ff, кроме safari По HTTPS загружается страница с javascript ом и пытается установить связь с вебсокетом, затыкается на подключении SSL соединения, в javascripte срабатывает после подключения onClose с кодом 1006. Wireshark ом смотрел, до Томката пакеты с запросом страницы проходят, отдаётся страница, а пакеты вебсокета не долетают, затыкается на соединении с NGINX. В логах NGINX ошибок нет. Кто-нибудь сталкивался? Или может у кого есть идеи что поковырять. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246662,246662#msg-246662 From nginx-forum at nginx.us Tue Jan 21 14:38:59 2014 From: nginx-forum at nginx.us (Dimka) Date: Tue, 21 Jan 2014 09:38:59 -0500 Subject: =?UTF-8?B?UmU6IE5HSU5YIFNTTCBXZWJTb2NrZXQg0L/RgNC+0LHRgNC+0YEg0LIgVG9tY2F0?= In-Reply-To: References: Message-ID: Забыл написать. Если соединение из safari сразу в томкат, без проксирования через NGINX - то работает! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246662,246663#msg-246663 From mdounin at mdounin.ru Tue Jan 21 14:55:55 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 21 Jan 2014 18:55:55 +0400 Subject: =?UTF-8?B?UmU6IE5HSU5YIFNTTCBXZWJTb2NrZXQg0L/RgNC+0LHRgNC+0YEg0LIgVG9tY2F0?= In-Reply-To: References: Message-ID: <20140121145555.GY1835@mdounin.ru> Hello! On Tue, Jan 21, 2014 at 09:34:02AM -0500, Dimka wrote: > Всем привет! > > Настроил HTTPS и WebSocket в томкат. > > Конфиг > map $http_upgrade $connection_upgrade { > default upgrade; > '' close; > } > server { > listen *ВНЕШНИЙ АДРЕС*:443 ssl; > ssl_certificate /opt/keystore/cert2/server.crt; > ssl_certificate_key /opt/keystore/cert2/server.key; > ssl_session_timeout 5m; > ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; > ssl_ciphers HIGH:!aNULL:!MD5; > ssl_prefer_server_ciphers on; > keepalive_timeout 70; > > server_name сайт.cc; [...] > Схема работает в chrome, ff, кроме safari > > По HTTPS загружается страница с javascript ом и пытается установить связь с > вебсокетом, затыкается на подключении SSL соединения, в javascripte > срабатывает после подключения onClose с кодом 1006. > > Wireshark ом смотрел, до Томката пакеты с запросом страницы проходят, > отдаётся страница, а пакеты вебсокета не долетают, затыкается на соединении > с NGINX. > > В логах NGINX ошибок нет. > > Кто-нибудь сталкивался? > > Или может у кого есть идеи что поковырять. Я бы в первую очередь убедился, что к ssl-сертификату у браузера никаких вопросов нет. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Tue Jan 21 16:01:01 2014 From: nginx-forum at nginx.us (mvs) Date: Tue, 21 Jan 2014 11:01:01 -0500 Subject: =?UTF-8?B?0JLRi9C00LXQu9C10L3QuNC1INC/0LXRgNCy0L7QuSDRh9Cw0YHRgtC4IHNlcnZl?= =?UTF-8?B?ciBuYW1lINC/0YDQuCDQv9C+0LzQvtGJ0LggcmVnZXg=?= Message-ID: <8d483464dd82acb28de1a4082f9f5b5c.NginxMailingListRussian@forum.nginx.org> Прошу помощи в моей задаче: необходимо обрабатывать адреса вида .project.dev.example.com отфильтровав их от всевозможных поддоменов blablabla..project.dev.example.com; вариантов более 50 и они изредка меняются, поэтому перечислить их в списке невозможно. Сейчас используется вариант server_name project.dev.example.com *.project.dev.example.com; но он пропускает blablabla..project.dev.example.com Пробовал варианты server_name ~^[a-z]+\.project\.dev\.example\.com$; server_name ~^(\w.+)\.project\.dev\.example\.com$; server_name ~^([^.]+)\.project\.dev\.example\.com$; но в них открывается дефолтный сервер server_name .dev.example.com; nginx version: nginx/1.4.4 TLS SNI support enabled configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error_log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib --http-log-path=/var/log/nginx/access_log --http-client-body-temp-path=//var/lib/nginx/tmp/client --http-proxy-temp-path=//var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=//var/lib/nginx/tmp/fastcgi --http-scgi-temp-path=//var/lib/nginx/tmp/scgi --http-uwsgi-temp-path=//var/lib/nginx/tmp/uwsgi --with-pcre --with-pcre-jit --without-http_auth_basic_module --without-http_autoindex_module --without-http_browser_module --without-http_empty_gif_module --without-http_fastcgi_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_conn_module --without-http_map_module --without-http_memcached_module --without-http_referer_module --without-http_scgi_module --without-http_ssi_module --without-http_split_clients_module --without-http_upstream_ip_hash_module --without-http_userid_module --without-http_uwsgi_module --with-http_ssl_module --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --user=nginx --group=nginx Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246665,246665#msg-246665 From vbart at nginx.com Tue Jan 21 16:30:13 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 21 Jan 2014 20:30:13 +0400 Subject: =?UTF-8?B?UmU6INCS0YvQtNC10LvQtdC90LjQtSDQv9C10YDQstC+0Lkg0YfQsNGB0YLQuCBz?= =?UTF-8?B?ZXJ2ZXIgbmFtZSDQv9GA0Lgg0L/QvtC80L7RidC4IHJlZ2V4?= In-Reply-To: <8d483464dd82acb28de1a4082f9f5b5c.NginxMailingListRussian@forum.nginx.org> References: <8d483464dd82acb28de1a4082f9f5b5c.NginxMailingListRussian@forum.nginx.org> Message-ID: <1454727.UdGk6oO6lB@vbart-laptop> On Tuesday 21 January 2014 11:01:01 mvs wrote: > Прошу помощи в моей задаче: необходимо обрабатывать адреса вида > .project.dev.example.com отфильтровав их от всевозможных поддоменов > blablabla..project.dev.example.com; вариантов более 50 и они > изредка меняются, поэтому перечислить их в списке невозможно. Если они меняются "изредка", то что мешает их перечислить в списке и изредка менять этот список? > > Сейчас используется вариант > server_name project.dev.example.com *.project.dev.example.com; > но он пропускает blablabla..project.dev.example.com > > Пробовал варианты > server_name ~^[a-z]+\.project\.dev\.example\.com$; > server_name ~^(\w.+)\.project\.dev\.example\.com$; > server_name ~^([^.]+)\.project\.dev\.example\.com$; > но в них открывается дефолтный сервер > server_name .dev.example.com; [..] Разумеется. Это хорошо описано в документации: http://nginx.org/r/server_name/ru (со слов "При поиске виртуального сервера ...") -- Валентин Бартенев From postmaster at softsearch.ru Tue Jan 21 17:49:45 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 21 Jan 2014 21:49:45 +0400 Subject: =?UTF-8?B?UmVbMl06INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <52DD8D17.5060706@citrin.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> Message-ID: <1062023187.20140121214945@softsearch.ru> Здравствуйте, Anton. >> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. >> А на стороне сервера считаешь хэш от логина, пароля, подсети и salt >> и смотришь, равен ли он тому, что пришёл в куках. > Я не специалист по криптографии, но насколько понимаю просто хэша тут > недостаточно, нужен HMAC. > В инете на эту тему за 5 минут нашел только такую статью: > http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ > Но встречал и более наглядные объяснения, почему нельзя в куке для > авторизации хранить просто хэш и нужен именно HMAC. Огромное спасибо. Я тоже не специалист в криптоанализе и не знал про такие атаки на хэши. И один раз нас так ломали, а я всё думал, как хацкеры SHA256 ломают так быстро. Буквально минуты проходили... Удалось их победить только применив редко используемую хэш-функцию. Но похоже это спасает только от глупых хацкеров, ломающих готовой утилитой и не понимающих её работы. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Tue Jan 21 18:42:37 2014 From: nginx-forum at nginx.us (Dimka) Date: Tue, 21 Jan 2014 13:42:37 -0500 Subject: =?UTF-8?B?UmU6IE5HSU5YIFNTTCBXZWJTb2NrZXQg0L/RgNC+0LHRgNC+0YEg0LIgVG9tY2F0?= In-Reply-To: <20140121145555.GY1835@mdounin.ru> References: <20140121145555.GY1835@mdounin.ru> Message-ID: <99df82f663790d6815b7ddfaeadc318d.NginxMailingListRussian@forum.nginx.org> Сертификат само подписаный. Я считаю что сертификат устраивает браузер так как при первом открытии запрашивает разрешение на работу с ним, предупреждая что он "самодельный", и далее, по HTTPS получает страницу, на которой расположен JS c кодом что обращается к тому же хосту уже по WebSocket соединению. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246662,246669#msg-246669 From mdounin at mdounin.ru Tue Jan 21 19:02:34 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 21 Jan 2014 23:02:34 +0400 Subject: =?UTF-8?B?UmU6IE5HSU5YIFNTTCBXZWJTb2NrZXQg0L/RgNC+0LHRgNC+0YEg0LIgVG9tY2F0?= In-Reply-To: <99df82f663790d6815b7ddfaeadc318d.NginxMailingListRussian@forum.nginx.org> References: <20140121145555.GY1835@mdounin.ru> <99df82f663790d6815b7ddfaeadc318d.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140121190234.GB1835@mdounin.ru> Hello! On Tue, Jan 21, 2014 at 01:42:37PM -0500, Dimka wrote: > Сертификат само подписаный. > > Я считаю что сертификат устраивает браузер так как при первом открытии > запрашивает разрешение на работу с ним, предупреждая что он "самодельный", и > далее, по HTTPS получает страницу, на которой расположен JS c кодом что > обращается к тому же хосту уже по WebSocket соединению. Проблема в том, что то, что мы считаем - далеко не всегда совпадают с тем, что есть на самом деле. В данном конкретном случае - тот факт, что браузер показал предупреждение и после этого успокоился - совершенно не означает, что он распространит это "успокоился" на дальнейшую деятельность по открытию соединений по другому протоколу (i.e., wss:// вместо https://). Возьмите честный сертификат от какого-нибудь startssl.com, благо бесплатно, должно заработать. -- Maxim Dounin http://nginx.org/ From postmaster at softsearch.ru Wed Jan 22 08:40:41 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 22 Jan 2014 12:40:41 +0400 Subject: =?UTF-8?B?UmVbMl06INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <52DD8D17.5060706@citrin.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> Message-ID: <17382798.20140122124041@softsearch.ru> Здравствуйте, Anton. >> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А >> на стороне сервера считаешь хэш от логина, пароля, подсети и salt и >> смотришь, равен ли он тому, что пришёл в куках. > Я не специалист по криптографии, но насколько понимаю просто хэша тут > недостаточно, нужен HMAC. > В инете на эту тему за 5 минут нашел только такую статью: > http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ > Но встречал и более наглядные объяснения, почему нельзя в куке для > авторизации хранить просто хэш и нужен именно HMAC. Для HMAC требуется 2 параметра: key и data. В нашем случае авторизации по куке key - это salt, а data - это сконкатенированные логин, пароль, подсеть и юзерагент? Или как? -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Wed Jan 22 08:45:23 2014 From: nginx-forum at nginx.us (akashihi) Date: Wed, 22 Jan 2014 03:45:23 -0500 Subject: =?UTF-8?B?0J/QvtC00LTQtdGA0LbQutCwIFJhbmdlINCyIHN1YnJlcXVlc3Q=?= Message-ID: Добрый день. Разбирался с одной проблемой производительности и обнаружил, что nginx не умеет читать части файлов (то есть не поддерживает range) в subrequest'ах. Например, если запрашивать файл напрямую, то читается только запрошенный участок файла: curl --header "Range: bytes=20000-21000" http://localhost:8081/largefile.txt open("/home/...../largefile.txt", O_RDONLY|O_NONBLOCK) = 13 fstat(13, {st_mode=S_IFREG|0644, st_size=10485760, ...}) = 0 pread(13, "G\2220cT+>\214r\0056\321#\202k\6\215\36\214\32\34X\267\350\302r\242\275\311\6\203f"..., 1001, 20000) = 1001 Но, если я обращаюсь к файлу из модуля с помощью subrequest, то читается всегда весь файл: curl --header "Range: bytes=20000-21000" http://localhost:8081/subrequest.txt open("/home/.../largefile.txt", O_RDONLY|O_NONBLOCK) = 13 fstat(13, {st_mode=S_IFREG|0644, st_size=10485760, ...}) = 0 pread(13, "\210\336\212k3\355g\nOH\"0\20\3152\265\v4\25\253\21\2U/\234!\257\331Uh\350\245"..., 32768, 0) = 32768 pread(13, "\32\310\270>\245K\21\271\230\235\230\345\35]=\266 at q\373}\204\367.\352\355i\224\215d\200\322\37"..., 32768, 32768) итд В коде ngx_http_range_filter_module есть явная проверка, не subrequest ли обрабатывается и если да, то передаётся следующему фильтру: if (r->http_version < NGX_HTTP_VERSION_10 || r->headers_out.status != NGX_HTTP_OK || r != r->main || r->headers_out.content_length_n == -1 || !r->allow_ranges) { return ngx_http_next_header_filter(r); } То есть это не баг, а осознанное решение. Но вот чем оно вызвано? Беглое чтение кода не прояснило ничего. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246681,246681#msg-246681 From igor at sysoev.ru Wed Jan 22 08:55:41 2014 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 22 Jan 2014 12:55:41 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBSYW5nZSDQsiBzdWJyZXF1ZXN0?= In-Reply-To: References: Message-ID: <0F41ECE1-24D5-453C-881E-3EC27951DD1D@sysoev.ru> On Jan 22, 2014, at 12:45 , akashihi wrote: > Добрый день. > > > > Разбирался с одной проблемой производительности и обнаружил, что nginx не > умеет читать части файлов (то есть не поддерживает range) в subrequest'ах. > > Например, если запрашивать файл напрямую, то читается только запрошенный > участок файла: > curl --header "Range: bytes=20000-21000" > http://localhost:8081/largefile.txt > open("/home/...../largefile.txt", O_RDONLY|O_NONBLOCK) = 13 > fstat(13, {st_mode=S_IFREG|0644, st_size=10485760, ...}) = 0 > pread(13, > "G\2220cT+>\214r\0056\321#\202k\6\215\36\214\32\34X\267\350\302r\242\275\311\6\203f"..., > 1001, 20000) = 1001 > > Но, если я обращаюсь к файлу из модуля с помощью subrequest, то читается > всегда весь файл: > curl --header "Range: bytes=20000-21000" > http://localhost:8081/subrequest.txt > open("/home/.../largefile.txt", O_RDONLY|O_NONBLOCK) = 13 > fstat(13, {st_mode=S_IFREG|0644, st_size=10485760, ...}) = 0 > pread(13, > "\210\336\212k3\355g\nOH\"0\20\3152\265\v4\25\253\21\2U/\234!\257\331Uh\350\245"..., > 32768, 0) = 32768 > pread(13, > "\32\310\270>\245K\21\271\230\235\230\345\35]=\266 at q\373}\204\367.\352\355i\224\215d\200\322\37"..., > 32768, 32768) > итд > > > В коде ngx_http_range_filter_module есть явная проверка, не subrequest ли > обрабатывается и если да, то передаётся следующему фильтру: > if (r->http_version < NGX_HTTP_VERSION_10 > || r->headers_out.status != NGX_HTTP_OK > || r != r->main > || r->headers_out.content_length_n == -1 > || !r->allow_ranges) > { > return ngx_http_next_header_filter(r); > } > > > То есть это не баг, а осознанное решение. Но вот чем оно вызвано? Беглое > чтение кода не прояснило ничего. Подзапросы делались прежде всего для включений SSI, к которым ranges не применимы. -- Igor Sysoev http://nginx.com From onokonem at gmail.com Wed Jan 22 09:04:17 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 22 Jan 2014 13:04:17 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQkNCy0YLQvtGA0LjQt9Cw0YbQuNGP?= In-Reply-To: <17382798.20140122124041@softsearch.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <17382798.20140122124041@softsearch.ru> Message-ID: 2014/1/22 Михаил Монашёв : > Для HMAC требуется 2 параметра: key и data. В нашем случае авторизации > по куке key - это salt, а data - это сконкатенированные логин, пароль, > подсеть и юзерагент? Или как? у нас есть данные и подпись, в куке. подпись (хеш) сгенерирована с добавлением секретного ключа. берем данные, секретный ключ, генерируем хеш заново. если совпало - данные считаются достоверными. к собственно проверке пароля это отношения не имеет. From postmaster at softsearch.ru Wed Jan 22 09:19:48 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 22 Jan 2014 13:19:48 +0400 Subject: =?UTF-8?B?UmVbNF06INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <17382798.20140122124041@softsearch.ru> Message-ID: <9110377121.20140122131948@softsearch.ru> Здравствуйте, Daniel. >> Для HMAC требуется 2 параметра: key и data. В нашем случае авторизации >> по куке key - это salt, а data - это сконкатенированные логин, пароль, >> подсеть и юзерагент? Или как? > у нас есть данные и подпись, в куке. подпись (хеш) сгенерирована с > добавлением секретного ключа. > берем данные, секретный ключ, генерируем хеш заново. если совпало - > данные считаются достоверными. > к собственно проверке пароля это отношения не имеет. Ну значит у Вас тоже проблемы с безопасностью. :-) -- С уважением, Михаил mailto:postmaster at softsearch.ru From onokonem at gmail.com Wed Jan 22 09:30:18 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 22 Jan 2014 13:30:18 +0400 Subject: =?UTF-8?B?UmU6IFJlWzRdOiDQkNCy0YLQvtGA0LjQt9Cw0YbQuNGP?= In-Reply-To: <9110377121.20140122131948@softsearch.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <17382798.20140122124041@softsearch.ru> <9110377121.20140122131948@softsearch.ru> Message-ID: 2014/1/22 Михаил Монашёв : > Ну значит у Вас тоже проблемы с безопасностью. :-) и у всего остального интернета тоже :) это же "стандарт", SSHA1. Очень широко распространен. но я лично проблемы не вижу. секрет у нас не словарный, только полным перебором. пока перебор закончится - у нас ключ сменится, он же скользящий. From postmaster at softsearch.ru Wed Jan 22 09:39:09 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 22 Jan 2014 13:39:09 +0400 Subject: =?UTF-8?B?UmVbNl06INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <17382798.20140122124041@softsearch.ru> <9110377121.20140122131948@softsearch.ru> Message-ID: <1588021043.20140122133909@softsearch.ru> Здравствуйте, Daniel. >> Ну значит у Вас тоже проблемы с безопасностью. :-) > и у всего остального интернета тоже :) > это же "стандарт", SSHA1. Очень широко распространен. Не слышал про такой. Дайте ссылочку почитать. > но я лично проблемы не вижу. секрет у нас не словарный, только полным > перебором. пока перебор закончится - у нас ключ сменится, он же > скользящий. Вы прочтите то, что Антон Южанинов написал. Возможно Ваш секретный ключ подбирается за минуты. Точнее его редуциронанная сущность, дающая такие же хэши, что и Вас секретный ключ. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Wed Jan 22 09:41:58 2014 From: nginx-forum at nginx.us (akashihi) Date: Wed, 22 Jan 2014 04:41:58 -0500 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBSYW5nZSDQsiBzdWJyZXF1ZXN0?= In-Reply-To: <0F41ECE1-24D5-453C-881E-3EC27951DD1D@sysoev.ru> References: <0F41ECE1-24D5-453C-881E-3EC27951DD1D@sysoev.ru> Message-ID: <5c2041bf60e0f40e4720a39b1ef19ebf.NginxMailingListRussian@forum.nginx.org> Добрый день. > > То есть это не баг, а осознанное решение. Но вот чем оно вызвано? > Беглое > > чтение кода не прояснило ничего. > > Подзапросы делались прежде всего для включений SSI, к которым ranges > не применимы. Получается что фундаментальных ограничений нет и можно, вообщем-то, взять да и приделать ranges? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246681,246688#msg-246688 From mdounin at mdounin.ru Wed Jan 22 11:26:30 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 22 Jan 2014 15:26:30 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBSYW5nZSDQsiBzdWJyZXF1ZXN0?= In-Reply-To: <5c2041bf60e0f40e4720a39b1ef19ebf.NginxMailingListRussian@forum.nginx.org> References: <0F41ECE1-24D5-453C-881E-3EC27951DD1D@sysoev.ru> <5c2041bf60e0f40e4720a39b1ef19ebf.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140122112630.GH1835@mdounin.ru> Hello! On Wed, Jan 22, 2014 at 04:41:58AM -0500, akashihi wrote: > Добрый день. > > > > То есть это не баг, а осознанное решение. Но вот чем оно вызвано? > > Беглое > > > чтение кода не прояснило ничего. > > > > Подзапросы делались прежде всего для включений SSI, к которым ranges > > не применимы. > > Получается что фундаментальных ограничений нет и можно, вообщем-то, взять да > и приделать ranges? Я даже когда-то приделывал, репозиторий где-то тут: http://mdounin.ru/hg/nginx-ranges/ Делалось для вот этого фильтра, который складывает вместе несколько подзапросов, соответственно для результата работают range-запросы: http://mdounin.ru/hg/ngx_http_compose_filter_module/ -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Jan 22 11:44:26 2014 From: nginx-forum at nginx.us (Dimka) Date: Wed, 22 Jan 2014 06:44:26 -0500 Subject: =?UTF-8?B?UmU6IE5HSU5YIFNTTCBXZWJTb2NrZXQg0L/RgNC+0LHRgNC+0YEg0LIgVG9tY2F0?= In-Reply-To: <20140121190234.GB1835@mdounin.ru> References: <20140121190234.GB1835@mdounin.ru> Message-ID: Больщущее спасибо! Действительно не нравился сертификат. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246662,246691#msg-246691 From onokonem at gmail.com Wed Jan 22 13:25:39 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 22 Jan 2014 17:25:39 +0400 Subject: =?UTF-8?B?UmU6IFJlWzZdOiDQkNCy0YLQvtGA0LjQt9Cw0YbQuNGP?= In-Reply-To: <1588021043.20140122133909@softsearch.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <17382798.20140122124041@softsearch.ru> <9110377121.20140122131948@softsearch.ru> <1588021043.20140122133909@softsearch.ru> Message-ID: >> это же "стандарт", SSHA1. Очень широко распространен. > Не слышал про такой. Дайте ссылочку почитать. Я читал вот тут: www.openldap.org/faq/data/cache/347.html. Но мне сейчас он не отвечает. Мне он понадобился для генерации файла basic auth для nginx в хранимой процедуре mysql. > Вы прочтите то, что Антон Южанинов написал. Возможно Ваш секретный > ключ подбирается за минуты. Точнее его редуциронанная сущность, дающая > такие же хэши, что и Вас секретный ключ. Насколько я знаю - речь, все-таки, идет о часах, даже на GPU. Скользящий ключ снимает остроту проблемы. Но ссылка от Антона Южанинова - правильная, сегодня для подписи куки надо использовать HMAC. From mdounin at mdounin.ru Wed Jan 22 14:02:25 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 22 Jan 2014 18:02:25 +0400 Subject: nginx-1.5.9 Message-ID: <20140122140225.GM1835@mdounin.ru> Изменения в nginx 1.5.9 22.01.2014 *) Изменение: теперь в заголовке X-Accel-Redirect nginx ожидает закодированный URI. *) Добавление: директива ssl_buffer_size. *) Добавление: директиву limit_rate теперь можно использовать для ограничения скорости передачи ответов клиенту в SPDY-соединениях. *) Добавление: директива spdy_chunk_size. *) Добавление: директива ssl_session_tickets. Спасибо Dirkjan Bussink. *) Исправление: переменная $ssl_session_id содержала всю сессию в сериализованном виде вместо её идентификатора. Спасибо Ivan Risti?. *) Исправление: nginx неправильно обрабатывал закодированный символ "?" в команде SSI include. *) Исправление: модуль ngx_http_dav_module не раскодировал целевой URI при обработке методов COPY и MOVE. *) Исправление: resolver не понимал доменные имена с точкой в конце. Спасибо Yichun Zhang. *) Исправление: при проксировании в логах могли появляться сообщения "zero size buf in output"; ошибка появилась в 1.3.9. *) Исправление: в рабочем процессе мог произойти segmentation fault, если использовался модуль ngx_http_spdy_module. *) Исправление: при использовании методов обработки соединений select, poll и /dev/poll проксируемые WebSocket-соединения могли зависать сразу после открытия. *) Исправление: директива xclient почтового прокси-сервера некорректно передавала IPv6-адреса. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Jan 22 14:05:22 2014 From: nginx-forum at nginx.us (Dimka) Date: Wed, 22 Jan 2014 09:05:22 -0500 Subject: =?UTF-8?B?0JHQvtC10LLQsNGPINC60L7QvdGE0LjQs9GD0YDQsNGG0LjRjw==?= Message-ID: <075b60f246e77246cea74684c4ec8a04.NginxMailingListRussian@forum.nginx.org> Всем привет! Я использую NGINX для проброса части cgi трафика Апаче, часть в Томкат и часть кешируется nginx ом. Так же поднят SSL. Подскажите, есть какие-то особенности для боевой конфигурации NGINX ? Например ограничения по рейту, выключение ненужных модулей и т.п. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246702,246702#msg-246702 From chipitsine at gmail.com Wed Jan 22 14:18:02 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 22 Jan 2014 20:18:02 +0600 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52DD93F6.9030204@csdoc.com> References: <52DD93F6.9030204@csdoc.com> Message-ID: очевидно, если пользователь предъявляет вам сертификат, то у него есть закрытый ключ. чтобы nginx смог дальше предъявить этот же сертификат, получается надо дубликаты всех пользовательских закрытых ключей держать на nginx ? или вы какой-то другой сценарий имели в виду ? 21 января 2014 г., 3:24 пользователь Gena Makhomed написал: > Здравствуйте, All! > > Как сделать Mutual authentication > между двумя сервисами с помощью nginx? > > На двух разных серверах nginx слушает на порту 443 > и проксирует клиентские запросы на порт 80 backend`а. > > "На вход" проверка клиентского сертификата работает отлично. > А когда backend делает клиентский запрос на 127.0.0.1:8080 - > nginx проксирует этот запрос на 443 порт удаленного сервера > по https. Но как сделать так, чтобы при proxy_pass nginx > еще и предьявлял клиентский сертификат удаленному сервису? > > Или какой софт можно использовать здесь вместо nginx, > если nginx это делать не умеет и такая функциональность > в нем никогда не будет реализована по каким-то причинам? > Хотя, это наверное была бы killer feature, полезная многим. > > Если только принимать https-запросы на уровне nginx, > а отправлять https-запросы через само приложение > - тогда будет layering violation и клиентскому > приложению придется давать доступ к файлу ключа. > > Может быть кто-то уже решал такую или похожую задачу? > > -- > 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 Wed Jan 22 14:32:19 2014 From: nginx-forum at nginx.us (DenisM) Date: Wed, 22 Jan 2014 09:32:19 -0500 Subject: =?UTF-8?B?c3ViIGZpbHRlciwg0LrQsNC6INC/0YDQsNCy0LjQu9GM0L3Qvj8=?= Message-ID: Привет! Сайт на php-cgi (fastcgi). nginx 1.4.4. Нужно заменить ссылки www.domain на www1.domain. Куда следует поместить sub_filter: в server, "location /", "location ~ .php$",..? sub_filter www.domain www1.domain; sub_filter_types *; Всюду пробовал, нигде не работает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246704,246704#msg-246704 From alexey.bobok at gmail.com Wed Jan 22 15:07:40 2014 From: alexey.bobok at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtCx0L7Qug==?=) Date: Wed, 22 Jan 2014 17:07:40 +0200 Subject: =?UTF-8?B?UmU6INCR0L7QtdCy0LDRjyDQutC+0L3RhNC40LPRg9GA0LDRhtC40Y8=?= In-Reply-To: <075b60f246e77246cea74684c4ec8a04.NginxMailingListRussian@forum.nginx.org> References: <075b60f246e77246cea74684c4ec8a04.NginxMailingListRussian@forum.nginx.org> Message-ID: Вовремя подвозите патроны. Best regards, Alexey Bobok 22 янв. 2014 16:05 пользователь "Dimka" написал: > Всем привет! > > Я использую NGINX для проброса части cgi трафика Апаче, часть в Томкат и > часть кешируется nginx ом. > > Так же поднят SSL. > > Подскажите, есть какие-то особенности для боевой конфигурации NGINX ? > > Например ограничения по рейту, выключение ненужных модулей и т.п. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246702,246702#msg-246702 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Wed Jan 22 15:14:43 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 22 Jan 2014 19:14:43 +0400 Subject: =?UTF-8?B?UmU6IHN1YiBmaWx0ZXIsINC60LDQuiDQv9GA0LDQstC40LvRjNC90L4/?= In-Reply-To: References: Message-ID: <3435859.pcGJBjMcVb@vbart-laptop> On Wednesday 22 January 2014 09:32:19 DenisM wrote: > Привет! > Сайт на php-cgi (fastcgi). nginx 1.4.4. > Нужно заменить ссылки www.domain на www1.domain. > Куда следует поместить sub_filter: в server, "location /", "location ~ > .php$",..? Лучше всего это поместить на бекэнд, поиск и замена в теле ответа далеко не самая легкая процедура. А так, помещайте туда, где и нужно чтобы модуль работал. > > sub_filter www.domain www1.domain; > sub_filter_types *; Стоит учесть, что распознавать и заменять текст в растровых изображениях модуль не умеет. > > Всюду пробовал, нигде не работает. Попробуйте выключить gzip-сжатие на бекэнде. -- Валентин Бартенев From gmm at csdoc.com Wed Jan 22 20:49:21 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 22 Jan 2014 22:49:21 +0200 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: References: <52DD93F6.9030204@csdoc.com> Message-ID: <52E02ED1.3090300@csdoc.com> On 22.01.2014 16:18, Илья Шипицин wrote: > очевидно, если пользователь предъявляет вам сертификат, > то у него есть закрытый ключ. > > чтобы nginx смог дальше предъявить этот же сертификат, получается надо > дубликаты всех пользовательских закрытых ключей держать на nginx ? > > или вы какой-то другой сценарий имели в виду ? Другой сценарий. Есть два сервера. На каждом из этих двух серверов работает веб-сервис, который отвечает на запросы пользователей по протоколу http и https. Кроме того, этим двум сервисам надо время от времени обмениваться между собой информацией. Причем канал связи между ними надо сделать максимально защищенным, так чтобы никто посторонний не мог отправлять пакеты одному сервису от имени другого сервиса. Самый надежный вариант, что я смог придумать - это сделать свой собственный Certificate authority (с помощью easy-rsa) создать в нем сертификаты для каждого сервера и каждого клиента, и настроить проверку всех клиентских и серверных сертификатов на уровне nginx. Каждый из этих двух веб-сервисов выступает одновременно и в роли клиента и в роли сервера при связи друг с другом. Все что связано с сертификатами и TLS/SSL хотелось бы оставить на уровне nginx, чтобы веб-сервисам приходил plain http, и разработчикам этих веб-сервисов не приходилось бы потом заморачиваться с https-запросами и клиентскими сертификатами. Если веб-приложение работает как сервер - ему запрос приходит на http://127.0.0.1:80/ а если веб-приложение работает как клиент и хочет связаться с другим веб-сервисом - то оно просто отправляет plain http запрос на http://127.0.0.1:8080/ - здесь слушает nginx и проксирует этот запрос через https с mutual auth на удаленный сервер. Если nginx работает в роли сервера - тогда без проблем можно настроить проверку валидности клиентского сертификата. Приблизительно вот так: server { listen 11.22.33.44:555 ssl; ... ssl_client_certificate /etc/tls/api.example.com/ca.crt; ssl_verify_client on; # allow connection only for client with certificate with serial "01" if ($ssl_client_serial != "01") { return 403; } Но если nginx работает в роли клиента и проксирует запросы от сервиса к другому серверу через proxy_pass https:// - тут не получается настроить его, чтобы он предъявлял свой клиентский сертификат и чтобы проверял валидность серверного сертификата. Скорее всего - такой функциональности сейчас в nginx таки нет. Только не понятно - ее "еще нет" или же "вообще нет и не будет". Подозреваю, что такая функциональность в nginx будет полезной не только мне, но и большому количеству других пользователей. И возможно это даже будет killer feature, которая позволит еще больше увеличить % использование nginx в современном web 2.0 и будущем web 3.0. Если это кому-то интересно. Альтернативные варианты - это разве что OpenVPN. Но nginx надежнее и удобнее в эксплуатации. Тем более, что в общем случае может быть больше чем два таких веб-сервиса, которые взаимодействуют между собой. Может быть я ошибаюсь, но с моей точки зрения идеальным вариантом решения этой и многих других подобных задач - было бы научить nginx работать в таком proxy_pass режиме. Самому писать такой патч - я полгода наверное буду вспоминать все нюансы работы С/С++ и разбираться с устройством OpenSSL. Тем более, что еще не факт, что его примут в основную ветку. Если бы существовала в природе Nginx Foundation и можно было бы пожертвовать некоторое количество денег, обозначив свой интерес в том чтобы в nginx появилась такая feature - я бы не задумываясь часть своей зарплаты потратил бы на то, чтобы "проголосовать" за нее. Возможно, если это надо не только мне, но и другим людям - тогда эта задача поднялась бы повыше в списке приоритетов на разработку. Могу даже попробовать пойти к начальству и предложить вариант чтобы компания единолично спонсировала появление такой feature в nginx, которая была бы полезной для реализации этой задачи. Но прежде чем куда-то идти и о чем-то просить - вот сначала попытался узнать в списке рассылки - может быть я какой-то неправильный вариант решения для этой задачи придумал и ее все обычно решают другим, более простым способом? Или же по каким-то техническим или идеологическим причинам такая feature никогда не может быть добавлена в nginx, и поэтому мне надо искать какие-то другие варианты решения для этой нашей задачи? >> Как сделать Mutual authentication >> между двумя сервисами с помощью nginx? >> >> На двух разных серверах nginx слушает на порту 443 >> и проксирует клиентские запросы на порт 80 backend`а. >> >> "На вход" проверка клиентского сертификата работает отлично. >> А когда backend делает клиентский запрос на 127.0.0.1:8080 - >> nginx проксирует этот запрос на 443 порт удаленного сервера >> по https. Но как сделать так, чтобы при proxy_pass nginx >> еще и предьявлял клиентский сертификат удаленному сервису? >> >> Или какой софт можно использовать здесь вместо nginx, >> если nginx это делать не умеет и такая функциональность >> в нем никогда не будет реализована по каким-то причинам? >> Хотя, это наверное была бы killer feature, полезная многим. >> >> Если только принимать https-запросы на уровне nginx, >> а отправлять https-запросы через само приложение >> - тогда будет layering violation и клиентскому >> приложению придется давать доступ к файлу ключа. >> >> Может быть кто-то уже решал такую или похожую задачу? -- Best regards, Gena From koticka at mail.ru Wed Jan 22 21:03:32 2014 From: koticka at mail.ru (Kostya Alexandrov) Date: Thu, 23 Jan 2014 01:03:32 +0400 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52E02ED1.3090300@csdoc.com> References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> Message-ID: <52E03224.5050205@mail.ru> При наличии возможности я бы использовал тут VPN с удаленным сервисом. Если такой возможности нет, то stunnel, кофигурируется просто https://www.stunnel.org/pipermail/stunnel-users/2013-March/004122.html. VPN при большом количестве соединений будет быстрее чем https. On 23.01.14, 0:49, Gena Makhomed wrote: > On 22.01.2014 16:18, Илья Шипицин wrote: > >> очевидно, если пользователь предъявляет вам сертификат, >> то у него есть закрытый ключ. > > >> чтобы nginx смог дальше предъявить этот же сертификат, получается надо >> дубликаты всех пользовательских закрытых ключей держать на nginx ? >> >> или вы какой-то другой сценарий имели в виду ? > > Другой сценарий. > > Есть два сервера. На каждом из этих двух серверов работает > веб-сервис, который отвечает на запросы пользователей по протоколу > http и https. Кроме того, этим двум сервисам надо время от времени > обмениваться между собой информацией. Причем канал связи между ними > надо сделать максимально защищенным, так чтобы никто посторонний > не мог отправлять пакеты одному сервису от имени другого сервиса. > > Самый надежный вариант, что я смог придумать - это сделать > свой собственный Certificate authority (с помощью easy-rsa) > создать в нем сертификаты для каждого сервера и каждого клиента, > и настроить проверку всех клиентских и серверных сертификатов > на уровне nginx. > > Каждый из этих двух веб-сервисов выступает одновременно > и в роли клиента и в роли сервера при связи друг с другом. > > Все что связано с сертификатами и TLS/SSL хотелось бы оставить > на уровне nginx, чтобы веб-сервисам приходил plain http, > и разработчикам этих веб-сервисов не приходилось бы потом > заморачиваться с https-запросами и клиентскими сертификатами. > > Если веб-приложение работает как сервер - ему запрос приходит > на http://127.0.0.1:80/ а если веб-приложение работает как клиент > и хочет связаться с другим веб-сервисом - то оно просто отправляет > plain http запрос на http://127.0.0.1:8080/ - здесь слушает nginx > и проксирует этот запрос через https с mutual auth на удаленный сервер. > > Если nginx работает в роли сервера - тогда без проблем можно > настроить проверку валидности клиентского сертификата. > Приблизительно вот так: > > server { > listen 11.22.33.44:555 ssl; > ... > ssl_client_certificate /etc/tls/api.example.com/ca.crt; > ssl_verify_client on; > > # allow connection only for client with certificate with serial "01" > if ($ssl_client_serial != "01") { return 403; } > > Но если nginx работает в роли клиента и проксирует запросы от сервиса > к другому серверу через proxy_pass https:// - тут не получается > настроить его, чтобы он предъявлял свой клиентский сертификат > и чтобы проверял валидность серверного сертификата. > > Скорее всего - такой функциональности сейчас в nginx таки нет. > Только не понятно - ее "еще нет" или же "вообще нет и не будет". > > Подозреваю, что такая функциональность в nginx будет полезной > не только мне, но и большому количеству других пользователей. > > И возможно это даже будет killer feature, которая позволит > еще больше увеличить % использование nginx в современном > web 2.0 и будущем web 3.0. Если это кому-то интересно. > > Альтернативные варианты - это разве что OpenVPN. > Но nginx надежнее и удобнее в эксплуатации. > > Тем более, что в общем случае может быть больше чем два > таких веб-сервиса, которые взаимодействуют между собой. > > Может быть я ошибаюсь, но с моей точки зрения идеальным > вариантом решения этой и многих других подобных задач - > было бы научить nginx работать в таком proxy_pass режиме. > > Самому писать такой патч - я полгода наверное буду вспоминать > все нюансы работы С/С++ и разбираться с устройством OpenSSL. > Тем более, что еще не факт, что его примут в основную ветку. > > Если бы существовала в природе Nginx Foundation и можно было > бы пожертвовать некоторое количество денег, обозначив свой интерес > в том чтобы в nginx появилась такая feature - я бы не задумываясь > часть своей зарплаты потратил бы на то, чтобы "проголосовать" за нее. > Возможно, если это надо не только мне, но и другим людям - тогда > эта задача поднялась бы повыше в списке приоритетов на разработку. > > Могу даже попробовать пойти к начальству и предложить вариант > чтобы компания единолично спонсировала появление такой feature > в nginx, которая была бы полезной для реализации этой задачи. > > Но прежде чем куда-то идти и о чем-то просить - вот сначала > попытался узнать в списке рассылки - может быть я какой-то > неправильный вариант решения для этой задачи придумал > и ее все обычно решают другим, более простым способом? > > Или же по каким-то техническим или идеологическим причинам > такая feature никогда не может быть добавлена в nginx, > и поэтому мне надо искать какие-то другие варианты > решения для этой нашей задачи? > > > >>> Как сделать Mutual authentication >>> между двумя сервисами с помощью nginx? >>> >>> На двух разных серверах nginx слушает на порту 443 >>> и проксирует клиентские запросы на порт 80 backend`а. >>> >>> "На вход" проверка клиентского сертификата работает отлично. >>> А когда backend делает клиентский запрос на 127.0.0.1:8080 - >>> nginx проксирует этот запрос на 443 порт удаленного сервера >>> по https. Но как сделать так, чтобы при proxy_pass nginx >>> еще и предьявлял клиентский сертификат удаленному сервису? >>> >>> Или какой софт можно использовать здесь вместо nginx, >>> если nginx это делать не умеет и такая функциональность >>> в нем никогда не будет реализована по каким-то причинам? >>> Хотя, это наверное была бы killer feature, полезная многим. >>> >>> Если только принимать https-запросы на уровне nginx, >>> а отправлять https-запросы через само приложение >>> - тогда будет layering violation и клиентскому >>> приложению придется давать доступ к файлу ключа. >>> >>> Может быть кто-то уже решал такую или похожую задачу? > From gmm at csdoc.com Thu Jan 23 00:08:36 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 23 Jan 2014 02:08:36 +0200 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52E03224.5050205@mail.ru> References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> <52E03224.5050205@mail.ru> Message-ID: <52E05D84.3090403@csdoc.com> On 22.01.2014 23:03, Kostya Alexandrov wrote: > При наличии возможности я бы использовал тут VPN с удаленным сервисом. > Если такой возможности нет, то stunnel, кофигурируется просто > https://www.stunnel.org/pipermail/stunnel-users/2013-March/004122.html. > VPN при большом количестве соединений будет быстрее чем https. Это я все говорил про Micro Service Architecture. VPN между серверами не всегда возможно будет сделать, да и при нескольких десятках микро-сервисов - это будет столько же ip-адресов и интерфейсов на каждом сервере. stunnel - да, как вариант, спасибо! Из всех возможных на сегодня - это наверное будет самый лучший вариант. Но тут добавляется еще одна точка отказа, еще один сервис который надо мониторить и без которого ничего нормально не работает. Идеальным вариантом было бы все-таки делать Mutual authentication только средствами nginx - новых точек отказа нет, конфигурировать и сопровождать такую систему было бы намного проще. Эх, мечты... -- Best regards, Gena From chipitsine at gmail.com Thu Jan 23 06:40:17 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 23 Jan 2014 12:40:17 +0600 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52E02ED1.3090300@csdoc.com> References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> Message-ID: 23 января 2014 г., 2:49 пользователь Gena Makhomed написал: > On 22.01.2014 16:18, Илья Шипицин wrote: > >> очевидно, если пользователь предъявляет вам сертификат, >> то у него есть закрытый ключ. > >> >> >> чтобы nginx смог дальше предъявить этот же сертификат, получается надо >> дубликаты всех пользовательских закрытых ключей держать на nginx ? >> >> или вы какой-то другой сценарий имели в виду ? > > > Другой сценарий. > > Есть два сервера. На каждом из этих двух серверов работает > веб-сервис, который отвечает на запросы пользователей по протоколу > http и https. Кроме того, этим двум сервисам надо время от времени > обмениваться между собой информацией. Причем канал связи между ними > надо сделать максимально защищенным, так чтобы никто посторонний > не мог отправлять пакеты одному сервису от имени другого сервиса. > > Самый надежный вариант, что я смог придумать - это сделать > свой собственный Certificate authority (с помощью easy-rsa) > создать в нем сертификаты для каждого сервера и каждого клиента, > и настроить проверку всех клиентских и серверных сертификатов > на уровне nginx. > > Каждый из этих двух веб-сервисов выступает одновременно > и в роли клиента и в роли сервера при связи друг с другом. > > Все что связано с сертификатами и TLS/SSL хотелось бы оставить > на уровне nginx, чтобы веб-сервисам приходил plain http, > и разработчикам этих веб-сервисов не приходилось бы потом > заморачиваться с https-запросами и клиентскими сертификатами. это чревато тем, что для приложения вся ваша магия выльется в "еще одну точку отказа", как вы выразились. как приложение отреагирует, если магия сломается ? а сломаться она может легко, например, нет доступа к CRL-ке и сервер не принял сертификат, который ему предъявил nginx > > Если веб-приложение работает как сервер - ему запрос приходит > на http://127.0.0.1:80/ а если веб-приложение работает как клиент > и хочет связаться с другим веб-сервисом - то оно просто отправляет > plain http запрос на http://127.0.0.1:8080/ - здесь слушает nginx > и проксирует этот запрос через https с mutual auth на удаленный сервер. необязательно на C/C++, можно на nginx-lua за полдня набросать то, что вы хотите. > > Если nginx работает в роли сервера - тогда без проблем можно > настроить проверку валидности клиентского сертификата. > Приблизительно вот так: > > server { > listen 11.22.33.44:555 ssl; > ... > ssl_client_certificate /etc/tls/api.example.com/ca.crt; > ssl_verify_client on; > > # allow connection only for client with certificate with serial "01" > if ($ssl_client_serial != "01") { return 403; } > > Но если nginx работает в роли клиента и проксирует запросы от сервиса > к другому серверу через proxy_pass https:// - тут не получается > настроить его, чтобы он предъявлял свой клиентский сертификат > и чтобы проверял валидность серверного сертификата. > > Скорее всего - такой функциональности сейчас в nginx таки нет. > Только не понятно - ее "еще нет" или же "вообще нет и не будет". > > Подозреваю, что такая функциональность в nginx будет полезной > не только мне, но и большому количеству других пользователей. очень легко уйти в холивар насчет "полезно ли большому количеству пользователей" > > И возможно это даже будет killer feature, которая позволит > еще больше увеличить % использование nginx в современном > web 2.0 и будущем web 3.0. Если это кому-то интересно. > > Альтернативные варианты - это разве что OpenVPN. > Но nginx надежнее и удобнее в эксплуатации. > > Тем более, что в общем случае может быть больше чем два > таких веб-сервиса, которые взаимодействуют между собой. сейчас немного другой тренд. скажем так, OAuth но там вся логика строится на приложении, не на транспорте. Майкрософт эту тему двигает, у него она называется "Claim based access control" (раньше любимая тема была RBAC = role based access control) > > Может быть я ошибаюсь, но с моей точки зрения идеальным > вариантом решения этой и многих других подобных задач - > было бы научить nginx работать в таком proxy_pass режиме. > > Самому писать такой патч - я полгода наверное буду вспоминать > все нюансы работы С/С++ и разбираться с устройством OpenSSL. > Тем более, что еще не факт, что его примут в основную ветку. > > Если бы существовала в природе Nginx Foundation и можно было > бы пожертвовать некоторое количество денег, обозначив свой интерес > в том чтобы в nginx появилась такая feature - я бы не задумываясь > часть своей зарплаты потратил бы на то, чтобы "проголосовать" за нее. > Возможно, если это надо не только мне, но и другим людям - тогда > эта задача поднялась бы повыше в списке приоритетов на разработку. > > Могу даже попробовать пойти к начальству и предложить вариант > чтобы компания единолично спонсировала появление такой feature > в nginx, которая была бы полезной для реализации этой задачи. > > Но прежде чем куда-то идти и о чем-то просить - вот сначала > попытался узнать в списке рассылки - может быть я какой-то > неправильный вариант решения для этой задачи придумал > и ее все обычно решают другим, более простым способом? вариант как вариант. сейчас модно креативить :-) > > Или же по каким-то техническим или идеологическим причинам > такая feature никогда не может быть добавлена в nginx, > и поэтому мне надо искать какие-то другие варианты > решения для этой нашей задачи? > > > > >>> Как сделать Mutual authentication >>> между двумя сервисами с помощью nginx? >>> >>> На двух разных серверах nginx слушает на порту 443 >>> и проксирует клиентские запросы на порт 80 backend`а. >>> >>> "На вход" проверка клиентского сертификата работает отлично. >>> А когда backend делает клиентский запрос на 127.0.0.1:8080 - >>> nginx проксирует этот запрос на 443 порт удаленного сервера >>> по https. Но как сделать так, чтобы при proxy_pass nginx >>> еще и предьявлял клиентский сертификат удаленному сервису? >>> >>> Или какой софт можно использовать здесь вместо nginx, >>> если nginx это делать не умеет и такая функциональность >>> в нем никогда не будет реализована по каким-то причинам? >>> Хотя, это наверное была бы killer feature, полезная многим. >>> >>> Если только принимать https-запросы на уровне nginx, >>> а отправлять https-запросы через само приложение >>> - тогда будет layering violation и клиентскому >>> приложению придется давать доступ к файлу ключа. >>> >>> Может быть кто-то уже решал такую или похожую задачу? > > > -- > 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 Thu Jan 23 06:50:46 2014 From: nginx-forum at nginx.us (DenisM) Date: Thu, 23 Jan 2014 01:50:46 -0500 Subject: =?UTF-8?B?UmU6IHN1YiBmaWx0ZXIsINC60LDQuiDQv9GA0LDQstC40LvRjNC90L4/?= In-Reply-To: <3435859.pcGJBjMcVb@vbart-laptop> References: <3435859.pcGJBjMcVb@vbart-laptop> Message-ID: <9b5c5c13e86c743041b5e079fae1e3f5.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Wednesday 22 January 2014 09:32:19 DenisM wrote: > > Привет! > > Сайт на php-cgi (fastcgi). nginx 1.4.4. > > Нужно заменить ссылки www.domain на www1.domain. > > Куда следует поместить sub_filter: в server, "location /", "location ~ .php$",..? > > Лучше всего это поместить на бекэнд, поиск и замена в теле > ответа далеко не самая легкая процедура. Т.е. не пользоваться этой возможностью nginx? Бэкендом у меня php, куда там это помещать? > А так, помещайте туда, где и нужно чтобы модуль работал. > > > > > > sub_filter www.domain www1.domain; > > sub_filter_types *; > > Стоит учесть, что распознавать и заменять текст в растровых > изображениях модуль не умеет. Это понятно. Написал "*", чтобы уж наверняка. > > Всюду пробовал, нигде не работает. > > Попробуйте выключить gzip-сжатие на бекэнде. На бэкенде нет сжатия. > -- > Валентин Бартенев Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246704,246735#msg-246735 From nginx-forum at nginx.us Thu Jan 23 06:59:55 2014 From: nginx-forum at nginx.us (Dimka) Date: Thu, 23 Jan 2014 01:59:55 -0500 Subject: =?UTF-8?B?UmU6INCR0L7QtdCy0LDRjyDQutC+0L3RhNC40LPRg9GA0LDRhtC40Y8=?= In-Reply-To: References: Message-ID: <489f0b659c3d1d674c6379b290a9e1e4.NginxMailingListRussian@forum.nginx.org> :) это разумеется, а кроме, если серьезно? В продакшен использовании... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246702,246737#msg-246737 From pavel2000 at ngs.ru Thu Jan 23 08:21:19 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Thu, 23 Jan 2014 15:21:19 +0700 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <52DD8D17.5060706@citrin.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> Message-ID: <437911983.20140123152119@ngs.ru> Здравствуйте!. > On 21.01.2014 00:40, Михаил Монашёв wrote: >> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А >> на стороне сервера считаешь хэш от логина, пароля, подсети и salt и >> смотришь, равен ли он тому, что пришёл в куках. > Я не специалист по криптографии, но насколько понимаю просто хэша тут > недостаточно, нужен HMAC. > В инете на эту тему за 5 минут нашел только такую статью: > http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ > Но встречал и более наглядные объяснения, почему нельзя в куке для > авторизации хранить просто хэш и нужен именно HMAC. Кто-нибудь может кинуть ссылку на более наглядные объяснения с более человекопонятной схемой, как это ломается? Либо может быть кто-то разъяснит "на пальцах", как злоумышленник, имея одну или несколько пар "userId + keyedhash" сможет сгенерировать пару "admin_userId + valid_keyedhash"? Спасибо. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From postmaster at softsearch.ru Thu Jan 23 08:35:37 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 23 Jan 2014 12:35:37 +0400 Subject: =?UTF-8?B?UmVbMl06INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <437911983.20140123152119@ngs.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> Message-ID: <1346445317.20140123123537@softsearch.ru> Здравствуйте, Pavel. >>> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. >>> А на стороне сервера считаешь хэш от логина, пароля, подсети и >>> salt и смотришь, равен ли он тому, что пришёл в куках. >> Я не специалист по криптографии, но насколько понимаю просто хэша >> тут недостаточно, нужен HMAC. >> В инете на эту тему за 5 минут нашел только такую статью: >> http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ >> Но встречал и более наглядные объяснения, почему нельзя в куке для >> авторизации хранить просто хэш и нужен именно HMAC. > Кто-нибудь может кинуть ссылку на более наглядные объяснения с более > человекопонятной схемой, как это ломается? Либо может быть кто-то > разъяснит "на пальцах", как злоумышленник, имея одну или несколько > пар "userId + keyedhash" сможет сгенерировать пару "admin_userId + > valid_keyedhash"? Как ломается, сам пока не разобрался. Но атака ведётся на поиск константной строки, которая конкатенируется к данным (в Вашем случае к userId ). Когда она или её замена найдены, то берётся админский userID, найденная строка и получается подпись для админа. Далее она суётся в куку вместе с id админа и у юзера права админа. -- С уважением, Михаил mailto:postmaster at softsearch.ru From alexey.bobok at gmail.com Thu Jan 23 09:34:37 2014 From: alexey.bobok at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtCx0L7Qug==?=) Date: Thu, 23 Jan 2014 11:34:37 +0200 Subject: =?UTF-8?B?UmU6INCR0L7QtdCy0LDRjyDQutC+0L3RhNC40LPRg9GA0LDRhtC40Y8=?= In-Reply-To: <489f0b659c3d1d674c6379b290a9e1e4.NginxMailingListRussian@forum.nginx.org> References: <489f0b659c3d1d674c6379b290a9e1e4.NginxMailingListRussian@forum.nginx.org> Message-ID: А если серьезно, то конфиги, схемы, вывод о вкомпилированных модулях, описание логики работы. Тогда будет предмет для обсуждения. Best regards, Alexey Bobok 23 янв. 2014 09:00 пользователь "Dimka" написал: > :) это разумеется, а кроме, если серьезно? В продакшен использовании... > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246702,246737#msg-246737 > > _______________________________________________ > 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 sasha181 at rufox.ru Thu Jan 23 09:49:09 2014 From: sasha181 at rufox.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0YPQvdC40Yc=?=) Date: Thu, 23 Jan 2014 13:49:09 +0400 Subject: =?UTF-8?B?0J/QviDQutCw0LrQvtC5LdGC0L4g0L/RgNC40YfQuNC90LUgbmdpbngg0LTQsNGR?= =?UTF-8?B?0YIg0LfQsNC00LXRgNC20LrRgyDQv9GA0Lgg0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDQvdC40Lg=?= Message-ID: <52E0E595.3020708@rufox.ru> система debian 7 (контейнер openvz) хост машина на базе proxmox ve стоит ispmanager Заметил такую особенность, если обращаться к apache напрямую по порту 8080 php скрипты отрабатывают на 20-40 милисекунд быстрее это нормальные накладные расходы для tcp проксирования или всё же с этим можно что-то сделать? Вот основные параметры из конфига nginx user www-data; worker_processes 8; worker_rlimit_nofile 10240; events { use epoll; worker_connections 10240; accept_mutex off; } http { include /etc/nginx/mime.types; access_log off; sendfile on; tcp_nopush on; tcp_nodelay on; client_max_body_size 100m; client_body_buffer_size 4m; proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300; proxy_buffer_size 64k; proxy_buffers 8 256k; proxy_busy_buffers_size 256k; proxy_temp_file_write_size 10m; proxy_http_version 1.1; gzip on; gzip_proxied any; gzip_static on; gzip_http_version 1.0; gzip_types application/x-javascript text/css; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; server_names_hash_bucket_size 128; server_names_hash_max_size 2048; В apache keepalive тоже включён. Пробовал и с выключенным. Эффект тот же. Пробовал на этой же машине поднять с аналогичными лимитами openvz для сравнения виртуальную машину битрикс. В ней разницы нет при обращении к apache напрямую или через nginx. Может причина в сборке nginx ? Попробовать пересобрать самостоятельно с минимумом модулей? Подскажите пожалуйста, в каких направлениях искать причину проблемы. From pavel2000 at ngs.ru Thu Jan 23 10:28:20 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Thu, 23 Jan 2014 17:28:20 +0700 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <1346445317.20140123123537@softsearch.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> <1346445317.20140123123537@softsearch.ru> Message-ID: <25605526.20140123172820@ngs.ru> Здравствуйте, Михаил. Вы писали 23 января 2014 г., 15:35:37: > Здравствуйте, Pavel. >>>> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. >>>> А на стороне сервера считаешь хэш от логина, пароля, подсети и >>>> salt и смотришь, равен ли он тому, что пришёл в куках. >>> Я не специалист по криптографии, но насколько понимаю просто хэша >>> тут недостаточно, нужен HMAC. >>> В инете на эту тему за 5 минут нашел только такую статью: >>> http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ >>> Но встречал и более наглядные объяснения, почему нельзя в куке для >>> авторизации хранить просто хэш и нужен именно HMAC. >> Кто-нибудь может кинуть ссылку на более наглядные объяснения с более >> человекопонятной схемой, как это ломается? Либо может быть кто-то >> разъяснит "на пальцах", как злоумышленник, имея одну или несколько >> пар "userId + keyedhash" сможет сгенерировать пару "admin_userId + >> valid_keyedhash"? > Как ломается, сам пока не разобрался. Но атака ведётся на поиск > константной строки, которая конкатенируется к данным (в Вашем случае к > userId ). Когда она или её замена найдены, то берётся админский > userID, найденная строка и получается подпись для админа. Далее она > суётся в куку вместе с id админа и у юзера права админа. Хорошо. Т.е. если на сервере проверка при этом делается по схеме - Получили из куки userId - Получили некий зависимый от userId идентификатор, например номер телефона - вычислили HashFunction( userId, StaticOrRollingKey, GetSomeUserData(userId)) - сравнили хеш из куки и и вычисленный то такая схема "более безопасна" и относительно стойка к вышеприведенной атаке? Но из-за наличия функции GetSomeUserData(), обращающейся к некоему центральному хранилищу, хеширование можно заменить на "rand()" и с тем же успехом начать хранить в хранилище непосредственно значение этой авторизационной куки. Правда получится разница из-за наличия некоторого объема записи в хранилище сессий. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From gmm at csdoc.com Thu Jan 23 11:08:29 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 23 Jan 2014 13:08:29 +0200 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> Message-ID: <52E0F82D.3060101@csdoc.com> On 23.01.2014 8:40, Илья Шипицин wrote: >> Все что связано с сертификатами и TLS/SSL хотелось бы оставить >> на уровне nginx, чтобы веб-сервисам приходил plain http, >> и разработчикам этих веб-сервисов не приходилось бы потом >> заморачиваться с https-запросами и клиентскими сертификатами. > > это чревато тем, что для приложения вся ваша магия выльется в "еще > одну точку отказа", как вы выразились. > как приложение отреагирует, если магия сломается ? а сломаться она > может легко, например, нет доступа к CRL-ке и сервер не принял > сертификат, который ему предъявил nginx Еще одной точки отказа тут нет, nginx в любом случае используется. nginx стартует с рутовыми правами и доступ к сертификатам у него есть. Если сервер не принял сертификат - значит у этого клиента доступа нет. Если вся логика работы с TLS/SSL будет только на уровне nginx - это нормально, а если часть там, часть там - то это layering violation. >> Если веб-приложение работает как сервер - ему запрос приходит >> на http://127.0.0.1:80/ а если веб-приложение работает как клиент >> и хочет связаться с другим веб-сервисом - то оно просто отправляет >> plain http запрос на http://127.0.0.1:8080/ - здесь слушает nginx >> и проксирует этот запрос через https с mutual auth на удаленный сервер. > > необязательно на C/C++, можно на nginx-lua за полдня набросать то, что > вы хотите. Каким образом, разве nginx-lua сможет добавить к proxy_pass ту функциональность, которой там сейчас нет, в частности, передачу на удаленный сервер клиентского сертификата и проверку серверного? >> Скорее всего - такой функциональности сейчас в nginx таки нет. >> Только не понятно - ее "еще нет" или же "вообще нет и не будет". >> >> Подозреваю, что такая функциональность в nginx будет полезной >> не только мне, но и большому количеству других пользователей. > > очень легко уйти в холивар насчет "полезно ли большому количеству пользователей" Можно и не уходить в холивар. Micro Service Architecture сейчас набирает популярность для создания приложений, вот например, про это написали даже в анонсе про выход Spring Framework 4.0 GA Release: http://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release Логично же делать максимальный уровень защиты через Mutual authentication между сервисами. В любом случае, наличие такой feature никому не помешало бы. Кому не надо - просто не включают и не пользуются. Вот, как например, мне совершенно не мешает наличие модуля image_filter или empty_gif или geoip и т.п. >> И возможно это даже будет killer feature, которая позволит >> еще больше увеличить % использование nginx в современном >> web 2.0 и будущем web 3.0. Если это кому-то интересно. > > сейчас немного другой тренд. > скажем так, OAuth > но там вся логика строится на приложении, не на транспорте. > > Майкрософт эту тему двигает, у него она называется "Claim based access > control" (раньше любимая тема была RBAC = role based access control) Это если разные сервисы разных производителей взаимодействуют между собой, то там да, OAuth. А если - это один сервис, который решает одну задачу, просто он сам построен не в виде одного большого монолитного приложения. Этот тренд - Micro Service Architecture набирает популярность. По крайней мере, раньше такого не было. >> Но прежде чем куда-то идти и о чем-то просить - вот сначала >> попытался узнать в списке рассылки - может быть я какой-то >> неправильный вариант решения для этой задачи придумал >> и ее все обычно решают другим, более простым способом? > > вариант как вариант. > сейчас модно креативить :-) А как иначе это можно сделать? Вот например, реальная задача. Есть небольшой хостинг - несколько десятков сайтов, которые созданы под заказ. Вместо того, чтобы для каждого сайта создавать свою админку, цеплять к ней SSL-сертификат, - проще и удобнее сделать всего одну админку, куда будут заходить пользователи по https, и там они смогут управлять своими сайтами. А сами сайты: www.example.com - сюда ходят пользователи сайта api.example.com - сюда ходит админка с Mutual authentication Сейчас - сайтов десятки, потом может быть сотни и тысячи. И что делать, настраивать и поддерживать в живом состоянии сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный порт на стороне контейнера с админкой? Это будет nightmare. Практически это нереальный вариант. Наверное придется таки идти на layering violation и обучать админку делать https- запросы с предъявлением клиентского сертификата через curl. ========================================================== Вторая задача - это большой веб-сервис, который построен с использованием Micro Service Architecture, физически размещен на нескольких серверах с горизонтальным масштабированием наиболее высоконагруженных подсистем. Причем все эти микросервисы могут "на ходу" добавляться/убираться/перестраиваться, здесь тоже идеально подходит вариант когда Mutual authentication делает сам nginx, а между nginx и tomcat`ами будет только plain http: tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2 Разве в будущем создание серверных систем пойдет не в этом направлении? У nginx сейчас вот есть возможность создать и возглавить такой тренд... -- Best regards, Gena From koticka at mail.ru Thu Jan 23 11:50:15 2014 From: koticka at mail.ru (Kostya Alexandrov) Date: Thu, 23 Jan 2014 15:50:15 +0400 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52E0F82D.3060101@csdoc.com> References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> <52E0F82D.3060101@csdoc.com> Message-ID: <52E101F7.9010903@mail.ru> Если сертификат один для всех, то stunnel конфиг будет один, если разные то опять же один stunnel и адских размеров конфиг. Если для каждого сайта свой сертификат, он должен быть пописан в конфиге nginx. Т.е. в любом случае все превращается в ночной кошмар. "Научить админку" - верный вариант, никакого layering violation нет. Здравый смысл violation решать вебсервером не свойственные ему задачи. Плюс, подумайте о ресурсах. Если админка научится ходить по https - то это одно соединение, если ходит через nginx то как минимум два. Если через nginx - то как минимум nginx должен держать все ваши сотни сертификатов впамяти, или грузить их по необходимости, зная какой где и зачем. Это полный overkill. Самый врный вариант работы с удалнными сервисами с защитой соединения это VPN, Вы подумайте сами во что превращается каждый вызов по https в Вашем случае, один хендшейк будет стоит как сотни плейн вызовов. ЗЫ Сорри за оффтоп. On 23.01.14, 15:08, Gena Makhomed wrote: > Вместо того, чтобы для каждого сайта создавать свою админку, > цеплять к ней SSL-сертификат, - проще и удобнее сделать всего > одну админку, куда будут заходить пользователи по https, > и там они смогут управлять своими сайтами. А сами сайты: > > www.example.com - сюда ходят пользователи сайта > api.example.com - сюда ходит админка с Mutual authentication > > Сейчас - сайтов десятки, потом может быть сотни и тысячи. > И что делать, настраивать и поддерживать в живом состоянии > сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный > порт на стороне контейнера с админкой? Это будет nightmare. > Практически это нереальный вариант. Наверное придется таки > идти на layering violation и обучать админку делать https- > запросы с предъявлением клиентского сертификата через curl. From chipitsine at gmail.com Thu Jan 23 11:53:15 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 23 Jan 2014 17:53:15 +0600 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52E0F82D.3060101@csdoc.com> References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> <52E0F82D.3060101@csdoc.com> Message-ID: четверг, 23 января 2014 г. пользователь Gena Makhomed написал: > On 23.01.2014 8:40, Илья Шипицин wrote: > > Все что связано с сертификатами и TLS/SSL хотелось бы оставить >>> на уровне nginx, чтобы веб-сервисам приходил plain http, >>> и разработчикам этих веб-сервисов не приходилось бы потом >>> заморачиваться с https-запросами и клиентскими сертификатами. >>> >> >> это чревато тем, что для приложения вся ваша магия выльется в "еще >> одну точку отказа", как вы выразились. >> как приложение отреагирует, если магия сломается ? а сломаться она >> может легко, например, нет доступа к CRL-ке и сервер не принял >> сертификат, который ему предъявил nginx >> > > Еще одной точки отказа тут нет, nginx в любом случае используется. > nginx стартует с рутовыми правами и доступ к сертификатам у него есть. > Если сервер не принял сертификат - значит у этого клиента доступа нет. еще одна точка отказа тут есть. nginx предъявляет свой сертификат серверу, сервер может отказать либо потому что у пользователя нет доступа, либо в силу того, что сервер не смог скачать CRL надо либо в одном случае возвращать "temp fail", в другом "perm fail", либо что-то еще, но логику отработки ошибок надо как-то реализовывать на стороне приложения > > Если вся логика работы с TLS/SSL будет только на уровне nginx - это > нормально, а если часть там, часть там - то это layering violation. если вся логика с ssl на стороне nginx, это точка отказа > > Если веб-приложение работает как сервер - ему запрос приходит >>> на http://127.0.0.1:80/ а если веб-приложение работает как клиент >>> и хочет связаться с другим веб-сервисом - то оно просто отправляет >>> plain http запрос на http://127.0.0.1:8080/ - здесь слушает nginx >>> и проксирует этот запрос через https с mutual auth на удаленный сервер. >>> >> >> необязательно на C/C++, можно на nginx-lua за полдня набросать то, что >> вы хотите. >> > > Каким образом, разве nginx-lua сможет добавить к proxy_pass > ту функциональность, которой там сейчас нет, в частности, передачу > на удаленный сервер клиентского сертификата и проверку серверного? content_by_lua и любой креатив в ваших силах ценой, возможно, большого оверхеда > > Скорее всего - такой функциональности сейчас в nginx таки нет. >>> Только не понятно - ее "еще нет" или же "вообще нет и не будет". >>> >>> Подозреваю, что такая функциональность в nginx будет полезной >>> не только мне, но и большому количеству других пользователей. >>> >> >> очень легко уйти в холивар насчет "полезно ли большому количеству >> пользователей" >> > > Можно и не уходить в холивар. Micro Service Architecture сейчас набирает > популярность для создания приложений, вот например, про это написали > даже в анонсе про выход Spring Framework 4.0 GA Release: > http://spring.io/blog/2013/12/12/announcing-spring- > framework-4-0-ga-release > > Логично же делать максимальный уровень защиты > через Mutual authentication между сервисами. у нас одна из любимых ошибок - "неидемпотентность сервиса", то есть, к примеру есть несколько экземпляров одного сервиса. мы обращаемся к сервису, делаем запрос "поменяй то-то и то-то", запрос уходит в таймаут, что делать ? идеальной была бы ситуация, когда многократно выполенный запрос не приводил бы к многократному изменению данных (это ведь, по сути, один и тот же запрос). такие типы сервисов называются "идемпотентными". если сервис таким свойством не обладает, в каких-то случаях лучше зафейлиться, чем уходить на следующую реплику а теперь представьте, что вы "прячете" топологию сервисов за nginx, все становится еще сложнее, у nginx в коде события "tcp connect timeout" (когда запрос не ушел и безопасно его еще раз повторить) и "http response timeout" (когда надо быть максимально аккуратным) выглядят одинаково кстати, надо будет патч на эту тему сделать )) > > В любом случае, наличие такой feature никому не помешало бы. > Кому не надо - просто не включают и не пользуются. > > Вот, как например, мне совершенно не мешает наличие > модуля image_filter или empty_gif или geoip и т.п. > > И возможно это даже будет killer feature, которая позволит >>> еще больше увеличить % использование nginx в современном >>> web 2.0 и будущем web 3.0. Если это кому-то интересно. >>> >> >> сейчас немного другой тренд. >> скажем так, OAuth >> но там вся логика строится на приложении, не на транспорте. >> >> Майкрософт эту тему двигает, у него она называется "Claim based access >> control" (раньше любимая тема была RBAC = role based access control) >> > > Это если разные сервисы разных производителей взаимодействуют > между собой, то там да, OAuth. А если - это один сервис, который > решает одну задачу, просто он сам построен не в виде одного большого > монолитного приложения. Этот тренд - Micro Service Architecture > набирает популярность. По крайней мере, раньше такого не было. тренд бесспорно интересный > > Но прежде чем куда-то идти и о чем-то просить - вот сначала >>> попытался узнать в списке рассылки - может быть я какой-то >>> неправильный вариант решения для этой задачи придумал >>> и ее все обычно решают другим, более простым способом? >>> >> >> вариант как вариант. >> сейчас модно креативить :-) >> > > А как иначе это можно сделать? > > Вот например, реальная задача. Есть небольшой хостинг - > несколько десятков сайтов, которые созданы под заказ. > > Вместо того, чтобы для каждого сайта создавать свою админку, > цеплять к ней SSL-сертификат, - проще и удобнее сделать всего > одну админку, куда будут заходить пользователи по https, > и там они смогут управлять своими сайтами. А сами сайты: > > www.example.com - сюда ходят пользователи сайта > api.example.com - сюда ходит админка с Mutual authentication > > Сейчас - сайтов десятки, потом может быть сотни и тысячи. > И что делать, настраивать и поддерживать в живом состоянии > сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный > порт на стороне контейнера с админкой? Это будет nightmare. > Практически это нереальный вариант. Наверное придется таки > идти на layering violation и обучать админку делать https- > запросы с предъявлением клиентского сертификата через curl. реальна задача- это замечательно, но я не понял, в каком месте возникает профит от mutual authentication, вероятно, надо больше деталей если вы хотите проверять серты на nginx и сообщать приложению, это делается через переменные nginx, у нас такой сценарий используется, могу конфиги помочь составить > > ========================================================== > > Вторая задача - это большой веб-сервис, который построен > с использованием Micro Service Architecture, физически > размещен на нескольких серверах с горизонтальным масштабированием nginx ломает идею горизонтального масштабирования, или вы планируете горизонтально плодить много экземпляров nginx? > наиболее высоконагруженных подсистем. Причем все эти микросервисы > могут "на ходу" добавляться/убираться/перестраиваться, > здесь тоже идеально подходит вариант когда Mutual authentication > делает сам nginx, а между nginx и tomcat`ами будет только plain http: > > tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2 > > Разве в будущем создание серверных систем пойдет не в этом направлении? > У nginx сейчас вот есть возможность создать и возглавить такой тренд... тренд прикольный > > -- > Best regards, > Gena > > _______________________________________________ > 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 Jan 23 11:54:31 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu, 23 Jan 2014 15:54:31 +0400 Subject: =?UTF-8?B?UmU6INCR0L7QtdCy0LDRjyDQutC+0L3RhNC40LPRg9GA0LDRhtC40Y8=?= In-Reply-To: <075b60f246e77246cea74684c4ec8a04.NginxMailingListRussian@forum.nginx.org> References: <075b60f246e77246cea74684c4ec8a04.NginxMailingListRussian@forum.nginx.org> Message-ID: <52E102F7.3090301@citrin.ru> On 01/22/14 18:05, Dimka wrote: > Подскажите, есть какие-то особенности для боевой конфигурации NGINX ? > Например ограничения по рейту, Сильно зависит от того, какой у вас бэкенд и есть ли запас его производительности. Какая ширина канал и хватает ли его. Универсального совета дать нельзя. Начать стоит с настройки мониторинга работы сайта и дальше смотреть что работает медленно или какого ресурса сервера не хватает. > выключение ненужных модулей и т.п. Модули с которыми скомпилирован nginx (официальные) очень мало влияют на производительность (а некоторые не влияют совсем). Так что специально прилагать усилия для сборки nginx с отключением всех ненужных модулей не стоит - проще использовать готовые бинарные пакеты: http://nginx.org/ru/linux_packages.html С 3d-party модулями по-другому - они могут иметь очень разное качество и использовать их стоит только если: 1. функциональность модуля действительно очень нужна. 2. вы знаете, что модуль имеет правильную архитектуру и достаточно высокое качество кода. From gmm at csdoc.com Thu Jan 23 13:11:35 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 23 Jan 2014 15:11:35 +0200 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52E101F7.9010903@mail.ru> References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> <52E0F82D.3060101@csdoc.com> <52E101F7.9010903@mail.ru> Message-ID: <52E11507.4080909@csdoc.com> On 23.01.2014 13:50, Kostya Alexandrov wrote: > Если сертификат один для всех, то stunnel конфиг будет один, > если разные то опять же один stunnel и адских размеров конфиг. Если есть 1000 клиентских сайтов, к которым надо будет подключаться из контейнера админки - это означает, что надо будет в этом контейнере держать 1000 открытых портов, где stunnel слушает входящие соединения. Плюс еще stunnel в каждом клиентском контейнере, для каждого сайта. > Если для каждого сайта свой сертификат, он должен быть пописан > в конфиге nginx. Т.е. в любом случае все превращается в ночной кошмар. А в чем проблема? nginx умеет работать с TLS SNI на стороне сервера. Прописать один раз сертификат в конфиг сайта - это очень легко и просто. > "Научить админку" - верный вариант, никакого layering violation нет. > Здравый смысл violation решать вебсервером не свойственные ему задачи. layer nginx - работает с MUTUAL AUTH TLS/SSL, маршрутизирует запросы layer backend - общается только со своим nginx по протоколу http. перенос логики создания исходящих HTTPS-соединений на уровень backend`а - это как раз и будет нарушение исходной схемы разделения логики на слои Потому что тут же надо будет вручную делать и логику модуля upstream, балансировки нагрузки и прочих прелестей. Т.е. переписывать часть nginx на backend`е. Разве это не является явным признаком layering violation ? > Плюс, подумайте о ресурсах. Если админка научится ходить по https - то > это одно соединение, если ходит через nginx то как минимум два. С таким же успехом можно агитировать убрать nginx из схемы nginx+apache или nginx+tomcat, "чтобы использовалось меньшее количество соединений". > Если через nginx - то как минимум nginx должен держать все ваши сотни > сертификатов впамяти, или грузить их по необходимости, зная какой где и > зачем. Это полный overkill. Размер SSL сертификата, грубо говоря, два килобайта. Если админка делает исходящие соединения - она предъявляет свой сертификат. А он всего один. Если на хостинговой машине в одном контейнере несколько сайтов - то да, каждый сайт предъявляет свой собственный сертификат. Но в чем проблема? > Самый врный вариант работы с удалнными сервисами с защитой соединения > это VPN, Вы подумайте сами во что превращается каждый вызов по https > в Вашем случае, один хендшейк будет стоит как сотни плейн вызовов. с OpenVPN есть нюансы при их настройке внутри OpenVZ контейнеров. Кроме того, OpenVPN для доступа к одному HTTPS-порту - это overkill. Тем более, что OpenVPN уже используется для создания VPN, а сайты под управлением админки могут быть как внутри "локальной сети", так и снаружи - на других (не на моих) серверах в интернете. Делать для админки OpenVPN over OpenVPN - это будет слишком. > Сорри за оффтоп. Вроде ж не оффтоп, мы же тут обсуждаем как это лучше сделать с помощью nginx и почему все остальные варианты намного хуже. -- Best regards, Gena From gmm at csdoc.com Thu Jan 23 14:45:19 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 23 Jan 2014 16:45:19 +0200 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> <52E0F82D.3060101@csdoc.com> Message-ID: <52E12AFF.3080805@csdoc.com> On 23.01.2014 13:53, Илья Шипицин wrote: >> Еще одной точки отказа тут нет, nginx в любом случае используется. >> nginx стартует с рутовыми правами и доступ к сертификатам у него есть. >> Если сервер не принял сертификат - значит у этого клиента доступа нет. > > еще одна точка отказа тут есть. > nginx предъявляет свой сертификат серверу, сервер может отказать либо > потому что у пользователя нет доступа, либо в силу того, что сервер не > смог скачать CRL Какая разница, кто делает исходящий https-запрос - nginx или backend ? Тем более, что CRL скачивать не надо - это локальный файл. Экзотические варианты "сломалась файловая система" и т.п. предлагаю не рассматривать. > надо либо в одном случае возвращать "temp fail", в другом "perm fail", > либо что-то еще, но логику отработки ошибок надо как-то реализовывать на > стороне приложения Почему надо возвращать "temp fail", если у пользователя нет доступа? Доступа нет, а потом он появляется? Так бывает только в анекдотах: Китайцы взломали сервер Пентагона, вот как это было: 1. Каждый китаец попробовал один пароль. 2. Каждый второй пароль был "Мао Цзедун" 3. На 74357181-й попытке- сервер согласился, что у него пароль "Мао Цзедун" >> Если вся логика работы с TLS/SSL будет только на уровне nginx - это >> нормально, а если часть там, часть там - то это layering violation. > > если вся логика с ssl на стороне nginx, это точка отказа Если используется только nginx - новых точек отказа не добавляется. Если использовать еще дополнительно stunnel или OpenVPN - тогда в системе появляются новые точки отказа, которых до того не было. >> необязательно на C/C++, можно на nginx-lua за полдня набросать >> то, что вы хотите. > > Каким образом, разве nginx-lua сможет добавить к proxy_pass > ту функциональность, которой там сейчас нет, в частности, передачу > на удаленный сервер клиентского сертификата и проверку серверного? > > content_by_lua и любой креатив в ваших силах > ценой, возможно, большого оверхеда http://wiki.nginx.org/HttpLuaModule#content_by_lua Acts as a "content handler" and executes Lua code string specified in for every request. The Lua code may make API calls and is executed as a new spawned coroutine in an independent global environment (i.e. a sandbox). Чем поможет "make API calls", если в nginx этой функциональности нет? >> Логично же делать максимальный уровень защиты >> через Mutual authentication между сервисами. > > у нас одна из любимых ошибок - "неидемпотентность сервиса", то есть, к > примеру есть несколько экземпляров одного сервиса. мы обращаемся к > сервису, делаем запрос "поменяй то-то и то-то", запрос уходит в таймаут, > что делать ? > > идеальной была бы ситуация, когда многократно выполенный запрос не > приводил бы к многократному изменению данных (это ведь, по сути, один и > тот же запрос). такие типы сервисов называются "идемпотентными". > > если сервис таким свойством не обладает, в каких-то случаях лучше > зафейлиться, чем уходить на следующую реплику > > а теперь представьте, что вы "прячете" топологию сервисов за nginx, все > становится еще сложнее, у nginx в коде события "tcp connect timeout" > (когда запрос не ушел и безопасно его еще раз повторить) и "http > response timeout" (когда надо быть максимально аккуратным) выглядят > одинаково > > кстати, надо будет патч на эту тему сделать )) Прятать топологию сервисов за nginx - это имхо общепринятая практика. Если один backend не смог ответить на запрос - он направляется на обработку другому. Да, сервисы желательно делать идемпотентными. Это понятно. Но к вопросу создания Mutual authentication между сервисами средствами nginx вопросы идемпотентности какое имеют отношение? Грубо говоря, Mutual authentication с помощью "магии" превращает незащищенное http соединение в высокозащищенное HTTPS соединение. А софт на backend`е об этом не должен знать, точно так же как он не должен знать про особенности работы TCP протокола или про нюансы маршрутизации IP пакетов в сетях Ethernet. Вот потому и говорю, что по моим ощущениям, переносить логику работы с Mutual authentication на backend - это есть 100% layering violation. > Вот например, реальная задача. Есть небольшой хостинг - > несколько десятков сайтов, которые созданы под заказ. > > Вместо того, чтобы для каждого сайта создавать свою админку, > цеплять к ней SSL-сертификат, - проще и удобнее сделать всего > одну админку, куда будут заходить пользователи по https, > и там они смогут управлять своими сайтами. А сами сайты: > > www.example.com - сюда ходят пользователи сайта > api.example.com - сюда ходит админка с > Mutual authentication > > Сейчас - сайтов десятки, потом может быть сотни и тысячи. > И что делать, настраивать и поддерживать в живом состоянии > сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный > порт на стороне контейнера с админкой? Это будет nightmare. > Практически это нереальный вариант. Наверное придется таки > идти на layering violation и обучать админку делать https- > запросы с предъявлением клиентского сертификата через curl. > > реальна задача- это замечательно, но я не понял, в каком месте возникает > профит от mutual authentication, вероятно, надо больше деталей Клиентские сайты могут быть размещены как на серверах компании, которая занималась созданием этих сайтов, так и на собственных серверах клиента. Управлять желательно и теми и теми одинаковым образом из одной админки, чтобы не было "вагонов двух типов" - про которые говорил Дейкстра в своей знаменитой притче: http://www.vspu.ac.ru/~chul/dijkstra/pritcha/pritcha.htm > если вы хотите проверять серты на nginx и сообщать приложению, это > делается через переменные nginx, у нас такой сценарий используется, могу > конфиги помочь составить Серверную часть " ... =(HTTPS)=> nginx2 =(http)=> tomcat2" я уже настроил и здесь все работает просто отлично. Кстати, сообщать приложению о том, что кто-то пытается подключиться к api.example.com с невалидным сертификатом не надо, смысла в этом никакого нет. Проблемы осталась пока что только с настройкой вот этой части: "tomcat1 =(http)=> nginx1 =(HTTPS)=> ..." Не получается сделать так, чтобы nginx1 предъявлял удаленному сервису свой клиентский сертификат и проверял сертификат удаленного сервиса. > ==============================__============================ > > Вторая задача - это большой веб-сервис, который построен > с использованием Micro Service Architecture, физически > размещен на нескольких серверах с горизонтальным масштабированием > > nginx ломает идею горизонтального масштабирования, или вы планируете > горизонтально плодить много экземпляров nginx? Если есть 25 экземпляров tomcat`а - и каждый из них делает исходящие запросы через свой nginx на 127.0.0.1:8080 - то понятно, что экземпляров nginx тоже будет много, как минимум по количеству серверов/контейнеров. И да, для простоты администрирования системы, 1 приложение == 1 tomcat. > tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2 -- Best regards, Gena From chipitsine at gmail.com Thu Jan 23 15:32:18 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 23 Jan 2014 21:32:18 +0600 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: <52E12AFF.3080805@csdoc.com> References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> <52E0F82D.3060101@csdoc.com> <52E12AFF.3080805@csdoc.com> Message-ID: четверг, 23 января 2014 г. пользователь Gena Makhomed написал: > On 23.01.2014 13:53, Илья Шипицин wrote: > > Еще одной точки отказа тут нет, nginx в любом случае используется. >>> nginx стартует с рутовыми правами и доступ к сертификатам у него есть. >>> Если сервер не принял сертификат - значит у этого клиента доступа нет. >>> >> >> еще одна точка отказа тут есть. >> nginx предъявляет свой сертификат серверу, сервер может отказать либо >> потому что у пользователя нет доступа, либо в силу того, что сервер не >> смог скачать CRL >> > > Какая разница, кто делает исходящий https-запрос - nginx или backend ? > Тем более, что CRL скачивать не надо - это локальный файл. Экзотические > варианты "сломалась файловая система" и т.п. предлагаю не рассматривать. CRL это свойство удостоверяющего центра, выпустившего сертификат клиента. в этом свойстве публикуется URL, по которому можно скачать актуальный список отозванных сертификатов. или не скачать, если по каким-то причинам адрес недоступен. посмотрите какой-нибудь корневой сертификат, там есть параметр CDP (CRL distribution point), о нем речь CRL в файлике - да, так делают, но это не общий случай. как файлик узнает, что удостоверяющий центр отозвал очередной сертификат? > > надо либо в одном случае возвращать "temp fail", в другом "perm fail", >> либо что-то еще, но логику отработки ошибок надо как-то реализовывать на >> стороне приложения >> > > Почему надо возвращать "temp fail", если у пользователя нет доступа? > Доступа нет, а потом он появляется? Так бывает только в анекдотах: именно так. доступа нет по причинам не зависящим напрямую от клиента и сервера кроме магии с CRL очень легко налететь на. ситуацию "протухший сертификат" (истек срок действия) > > Китайцы взломали сервер Пентагона, вот как это было: > 1. Каждый китаец попробовал один пароль. > 2. Каждый второй пароль был "Мао Цзедун" > 3. На 74357181-й попытке- сервер согласился, что у него пароль "Мао Цзедун" > > Если вся логика работы с TLS/SSL будет только на уровне nginx - это >>> нормально, а если часть там, часть там - то это layering violation. >>> >> >> если вся логика с ssl на стороне nginx, это точка отказа >> > > Если используется только nginx - новых точек отказа не добавляется. > Если использовать еще дополнительно stunnel или OpenVPN - тогда > в системе появляются новые точки отказа, которых до того не было. > > необязательно на C/C++, можно на nginx-lua за полдня набросать >>> то, что вы хотите. >>> >> >> Каким образом, разве nginx-lua сможет добавить к proxy_pass >> ту функциональность, которой там сейчас нет, в частности, передачу >> на удаленный сервер клиентского сертификата и проверку серверного? >> >> content_by_lua и любой креатив в ваших силах >> ценой, возможно, большого оверхеда >> > > http://wiki.nginx.org/HttpLuaModule#content_by_lua > > Acts as a "content handler" and executes Lua code string specified in > for every request. The Lua code may make API calls and is > executed as a new spawned coroutine in an independent global environment > (i.e. a sandbox). > > Чем поможет "make API calls", если в nginx этой функциональности нет? в content_by_lua можно запилить любой код на Lua и вернуть ответ в терминах nginx > > Логично же делать максимальный уровень защиты >>> через Mutual authentication между сервисами. >>> >> >> у нас одна из любимых ошибок - "неидемпотентность сервиса", то есть, к >> примеру есть несколько экземпляров одного сервиса. мы обращаемся к >> сервису, делаем запрос "поменяй то-то и то-то", запрос уходит в таймаут, >> что делать ? >> >> идеальной была бы ситуация, когда многократно выполенный запрос не >> приводил бы к многократному изменению данных (это ведь, по сути, один и >> тот же запрос). такие типы сервисов называются "идемпотентными". >> >> если сервис таким свойством не обладает, в каких-то случаях лучше >> зафейлиться, чем уходить на следующую реплику >> >> а теперь представьте, что вы "прячете" топологию сервисов за nginx, все >> становится еще сложнее, у nginx в коде события "tcp connect timeout" >> (когда запрос не ушел и безопасно его еще раз повторить) и "http >> response timeout" (когда надо быть максимально аккуратным) выглядят >> одинаково >> >> кстати, надо будет патч на эту тему сделать )) >> > > Прятать топологию сервисов за nginx - это имхо общепринятая практика. > Если один backend не смог ответить на запрос - он направляется > на обработку другому. > > Да, сервисы желательно делать идемпотентными. Это понятно. > Но к вопросу создания Mutual authentication между сервисами > средствами nginx вопросы идемпотентности какое имеют отношение? nginx к этому имеет ровно то отношение, что у него срабатывает proxy_next_upstream, то есть кроме шифрования он делает перебор реплик > > Грубо говоря, Mutual authentication с помощью "магии" > превращает незащищенное http соединение в высокозащищенное > HTTPS соединение. А софт на backend`е об этом не должен знать, > точно так же как он не должен знать про особенности работы TCP > протокола или про нюансы маршрутизации IP пакетов в сетях Ethernet. ох уж эти затейники "приложение не должно знать про маршрутизацию IP", вот смотрите, приложение пишет в tcp сокет 1 байт и не хочет ничего знать про пакеты. что должна делать операционка ? добавить 40 байт хедера и отправить пакет, в котором будет 1 байт данных на 40 байт хедера ? подождать, может будут еще данные ? а если их долго не будет ? обычно прятание технических подробностей за несколькими уровнями абстракции приводит к запутанным ситуациям. не надо так делать > > Вот потому и говорю, что по моим ощущениям, переносить логику работы > с Mutual authentication на backend - это есть 100% layering violation. а вы никому не говорите про violation )) никто и не заметит > > Вот например, реальная задача. Есть небольшой хостинг - >> несколько десятков сайтов, которые созданы под заказ. >> >> Вместо того, чтобы для каждого сайта создавать свою админку, >> цеплять к ней SSL-сертификат, - проще и удобнее сделать всего >> одну админку, куда будут заходить пользователи по https, >> и там они смогут управлять своими сайтами. А сами сайты: >> >> www.example.com - сюда ходят пользователи >> сайта >> api.example.com - сюда ходит админка с >> Mutual authentication >> >> Сейчас - сайтов десятки, потом может быть сотни и тысячи. >> И что делать, настраивать и поддерживать в живом состоянии >> сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный >> порт на стороне контейнера с админкой? Это будет nightmare. >> Практически это нереальный вариант. Наверное придется таки >> идти на layering violation и обучать админку делать https- >> запросы с предъявлением клиентского сертификата через curl. >> >> реальна задача- это замечательно, но я не понял, в каком месте возникает >> профит от mutual authentication, вероятно, надо больше деталей >> > > Клиентские сайты могут быть размещены как на серверах компании, > которая занималась созданием этих сайтов, так и на собственных > серверах клиента. Управлять желательно и теми и теми одинаковым > образом из одной админки, чтобы не было "вагонов двух типов" - админка это свойство сайта, нехай бы и жила там же где сайт. если вы захотите внедрить доработку на конкретный сайт, за что остальные должны страдать? > про которые говорил Дейкстра в своей знаменитой притче: > http://www.vspu.ac.ru/~chul/dijkstra/pritcha/pritcha.htm > > если вы хотите проверять серты на nginx и сообщать приложению, это >> делается через переменные nginx, у нас такой сценарий используется, могу >> конфиги помочь составить >> > > Серверную часть " ... =(HTTPS)=> nginx2 =(http)=> tomcat2" > я уже настроил и здесь все работает просто отлично. > > Кстати, сообщать приложению о том, что кто-то пытается > подключиться к api.example.com с невалидным сертификатом > не надо, смысла в этом никакого нет. есть ситуации, когда это работает. пример, есть домен с приложением, ssl используется для транспорта, пользователи ходят без сертификатов, на этом же домене по оптеделенному адресу, скажем /api/ работает сервис, который авторизует по сертификатам. поэтому сертификат мы не требуем, но если есть - передаем в приложение и пусть оно само разбирается, кто это пришел > > Проблемы осталась пока что только с настройкой > вот этой части: "tomcat1 =(http)=> nginx1 =(HTTPS)=> ..." > Не получается сделать так, чтобы nginx1 предъявлял удаленному > сервису свой клиентский сертификат и проверял сертификат > удаленного сервиса. > > ==============================__============================ >> >> Вторая задача - это большой веб-сервис, который построен >> с использованием Micro Service Architecture, физически >> размещен на нескольких серверах с горизонтальным масштабированием >> >> nginx ломает идею горизонтального масштабирования, или вы планируете >> горизонтально плодить много экземпляров nginx? >> > > Если есть 25 экземпляров tomcat`а - и каждый из них делает исходящие > запросы через свой nginx на 127.0.0.1:8080 - то понятно, что экземпляров > nginx тоже будет много, как минимум по количеству серверов/контейнеров. > И да, для простоты администрирования системы, 1 приложение == 1 tomcat. а tomcat будет ходить только на свой nginx ? > > tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2 >> > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Thu Jan 23 16:01:48 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 23 Jan 2014 20:01:48 +0400 Subject: =?UTF-8?B?UmU6IHN1YiBmaWx0ZXIsINC60LDQuiDQv9GA0LDQstC40LvRjNC90L4/?= In-Reply-To: <9b5c5c13e86c743041b5e079fae1e3f5.NginxMailingListRussian@forum.nginx.org> References: <3435859.pcGJBjMcVb@vbart-laptop> <9b5c5c13e86c743041b5e079fae1e3f5.NginxMailingListRussian@forum.nginx.org> Message-ID: <5772477.52n2ySx7Ax@vbart-laptop> On Thursday 23 January 2014 01:50:46 DenisM wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Wednesday 22 January 2014 09:32:19 DenisM wrote: > > > Привет! > > > Сайт на php-cgi (fastcgi). nginx 1.4.4. > > > Нужно заменить ссылки www.domain на www1.domain. > > > Куда следует поместить sub_filter: в server, "location /", > > > location ~ .php$",..? > > > > Лучше всего это поместить на бекэнд, поиск и замена в теле > > ответа далеко не самая легкая процедура. > > Т.е. не пользоваться этой возможностью nginx? > Бэкендом у меня php, куда там это помещать? Научить ваши php-бекэнды генерировать правильные ссылки сразу, без необходимости потом сканировать каждый ответ целиком на тему поиска и замены. Эта функция нужна главным образом в случаях, когда доступа не бекенд нет, либо когда необходимо реализовать какую-нибудь простейшую шаблонизацию на стороне nginx. [..] > > > Всюду пробовал, нигде не работает. > > > > Попробуйте выключить gzip-сжатие на бекэнде. > > На бэкенде нет сжатия. > У меня других идей нет. -- Валентин Бартенев From onokonem at gmail.com Thu Jan 23 18:41:19 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 23 Jan 2014 22:41:19 +0400 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <437911983.20140123152119@ngs.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> Message-ID: 2014/1/23 Pavel V. : > Кто-нибудь может кинуть ссылку на более наглядные объяснения с более человекопонятной схемой, > как это ломается? Либо может быть кто-то разъяснит "на пальцах", как злоумышленник, имея одну или > несколько пар "userId + keyedhash" сможет сгенерировать пару "admin_userId + valid_keyedhash"? Полным перебором это ломается. Просто процессоры стали сильно быстрые и многоядерные. SHA1 считается слишком быстро. From gmm at csdoc.com Thu Jan 23 18:55:21 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 23 Jan 2014 20:55:21 +0200 Subject: =?UTF-8?B?UmU6IE11dHVhbCBhdXRoZW50aWNhdGlvbiDRgdGA0LXQtNGB0YLQstCw0LzQuCBu?= =?UTF-8?B?Z2lueA==?= In-Reply-To: References: <52DD93F6.9030204@csdoc.com> <52E02ED1.3090300@csdoc.com> <52E0F82D.3060101@csdoc.com> <52E12AFF.3080805@csdoc.com> Message-ID: <52E16599.8090507@csdoc.com> On 23.01.2014 17:32, Илья Шипицин wrote: > CRL это свойство удостоверяющего центра, выпустившего сертификат > клиента. в этом свойстве публикуется URL, по которому можно скачать > актуальный список отозванных сертификатов. или не скачать, если по > каким-то причинам адрес недоступен. посмотрите какой-нибудь корневой > сертификат, там есть параметр CDP (CRL distribution point), о нем речь > > CRL в файлике - да, так делают, но это не общий случай. как файлик > узнает, что удостоверяющий центр отозвал очередной сертификат? Спасибо, я знаю что такое CRL. Удостоверяющий центр мой собственный. Если мы говорим про nginx - там есть директива ssl_crl для задания CRL. [...] >> Грубо говоря, Mutual authentication с помощью "магии" >> превращает незащищенное http соединение в высокозащищенное >> HTTPS соединение. А софт на backend`е об этом не должен знать, >> точно так же как он не должен знать про особенности работы TCP >> протокола или про нюансы маршрутизации IP пакетов в сетях Ethernet. > > ох уж эти затейники "приложение не должно знать про маршрутизацию IP", Приложение и не знает ничего про маршрутизацию IP. Маршрутизация IP - это не его layer и не его задача. > обычно прятание технических подробностей за несколькими уровнями > абстракции приводит к запутанным ситуациям. не надо так делать Про это надо говорить разработчикам TCP/IP, - там TCP - это именно что абстракция, которая скрывает все подробности работы нижних уровней (IP). [...] -- Best regards, Gena From nginx-forum at nginx.us Fri Jan 24 04:21:35 2014 From: nginx-forum at nginx.us (misha_shar53) Date: Thu, 23 Jan 2014 23:21:35 -0500 Subject: =?UTF-8?B?0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0L3QsCBVbml4INGB0L7QutC10YI=?= Message-ID: Попытка перенаправить запрос на Unix сокет не удалась. Почему ? Хотя на SCGI естественно прошла. location /exo { proxy_pass unix:/home/misha/nginx/scgi.socket; # scgi_pass unix:/home/misha/nginx/scgi.socket; # include scgi_params; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246768,246768#msg-246768 From nginx-forum at nginx.us Fri Jan 24 07:12:49 2014 From: nginx-forum at nginx.us (Miklucho) Date: Fri, 24 Jan 2014 02:12:49 -0500 Subject: =?UTF-8?B?0J3QtSDQvtGC0L7QsdGA0LDQttCw0Y7RgtGB0Y8g0LrQsNGA0YLQuNC90LrQuCA=?= =?UTF-8?B?0L/QvtGB0LvQtSDRgNC10YHQsNC50LfQuNC90LPQsA==?= Message-ID: <03412b1e9588b1e1f6bf8f7da2b6628b.NginxMailingListRussian@forum.nginx.org> Имеются nginx+apache+php на CentOS Потребовалось сделать ресайз картинок на лету по ссылкам типа: http://www.sitename.ru/thumb/350x250xin/images_path/image_name.jpg Реализовал следующим образом 1. В nginx проверяем существование картинки, если не существует перенаправляем на Апач. location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js)$ { root /home/www/sitename.ru/www/; try_files $uri @fallback; } location @fallback { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_connect_timeout 120; proxy_send_timeout 120; proxy_read_timeout 180; } 2. На бекэнде в .htaccess свое перенаправление: RewriteRule ^thumb/(.*) /thumb.php?req=$1 3. Скрипт thumb.php выполняет ресайз, сохраняет картинку для кеша и отдает ее в браузер. Схема работает, но есть такая проблема. На странице одновременно выводится до 10 таких картинок, так вот при первом заходе на страницу отображается только 1-2 изображения из десяти. Для остальных браузер рисует стандартную иконку отсутствующей картинки. Причем если посмотреть на FTP - отресайзенные картинки существуют! При обновлении страницы уже все картинки отображаются корректно. Мне кажется, что проблема в том, что php сравнительно медленно ресайзит изображения и из-за этого срабатывают какие-то таймауты, либо в apache, либо в nginx. Не подскажет ли кто куда мне копать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246772,246772#msg-246772 From pavel2000 at ngs.ru Fri Jan 24 08:08:07 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Fri, 24 Jan 2014 15:08:07 +0700 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> Message-ID: <1157052269.20140124150807@ngs.ru> Здравствуйте, Daniel. Вы писали 24 января 2014 г., 1:41:19: > 2014/1/23 Pavel V. : >> Кто-нибудь может кинуть ссылку на более наглядные объяснения с более человекопонятной схемой, >> как это ломается? Либо может быть кто-то разъяснит "на пальцах", как злоумышленник, имея одну или >> несколько пар "userId + keyedhash" сможет сгенерировать пару "admin_userId + valid_keyedhash"? > Полным перебором это ломается. Просто процессоры стали сильно быстрые > и многоядерные. SHA1 считается слишком быстро. Почему тогда нет проблемы если использовать HMAC-SHA1 ? Из-за того, что считается sha1 от вычисленного в sha1, что дает "сброс внутреннего состояния" хеширующей функции? -- С уважением, Pavel mailto:pavel2000 at ngs.ru From pavel2000 at ngs.ru Fri Jan 24 08:09:53 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Fri, 24 Jan 2014 15:09:53 +0700 Subject: =?UTF-8?B?UmU6INCd0LUg0L7RgtC+0LHRgNCw0LbQsNGO0YLRgdGPINC60LDRgNGC0LjQvdC6?= =?UTF-8?B?0Lgg0L/QvtGB0LvQtSDRgNC10YHQsNC50LfQuNC90LPQsA==?= In-Reply-To: <03412b1e9588b1e1f6bf8f7da2b6628b.NginxMailingListRussian@forum.nginx.org> References: <03412b1e9588b1e1f6bf8f7da2b6628b.NginxMailingListRussian@forum.nginx.org> Message-ID: <728177077.20140124150953@ngs.ru> Здравствуйте, Miklucho. Вы писали 24 января 2014 г., 14:12:49: > Мне кажется, что проблема в том, что php сравнительно медленно ресайзит > изображения и из-за этого срабатывают какие-то таймауты, либо в apache, либо > в nginx. > Не подскажет ли кто куда мне копать? 1) Смотрите в логи 2) Смотрите в ответы сервера например в firebug (в Firefox). -- С уважением, Pavel mailto:pavel2000 at ngs.ru From nginx-forum at nginx.us Fri Jan 24 08:20:27 2014 From: nginx-forum at nginx.us (misha_shar53) Date: Fri, 24 Jan 2014 03:20:27 -0500 Subject: =?UTF-8?B?0LbRg9GA0L3QsNC7INC40YHRhdC+0LTRj9GJ0LjRhSDQuCDQstGF0L7QtNGP0Yk=?= =?UTF-8?B?0LjRhSDRgdC+0LXQtNC40L3QtdC90LjQuQ==?= Message-ID: <4b5bbc609ba4eb9a4021f34ffb797355.NginxMailingListRussian@forum.nginx.org> Есть ли в NGINX журнал входящих и исходящих соединений. Если есть то как его подключить и где посмотреть? access_log /home/misha/Devel/wrk/nginx/access.log; access_log on; Это ничего не дало. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246775,246775#msg-246775 From nginx-forum at nginx.us Fri Jan 24 08:30:55 2014 From: nginx-forum at nginx.us (paulstrong) Date: Fri, 24 Jan 2014 03:30:55 -0500 Subject: =?UTF-8?B?Tmdpbngg0Lgg0LTQtdGB0Y/RgtC60Lgg0YLRi9GB0Y/RhyDQstC40YDRgtGD0LA=?= =?UTF-8?B?0LvRjNC90YvRhSDRhdC+0YHRgtC+0LI=?= Message-ID: <4c585e065b1d4110226addf94d4f7ba8.NginxMailingListRussian@forum.nginx.org> Добрый день, коллеги! У нас возник вопрос, связанный с использованием десятков тысяч виртуальных хостов (мы рассматриваем это как одно из решений нашей задачи). Скажем, как себя теоретически может повести nginx, если у него будет, например, 10 конфигов, в каждом из них будет по 20к различных server_name? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246776,246776#msg-246776 From postmaster at softsearch.ru Fri Jan 24 08:36:43 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 24 Jan 2014 12:36:43 +0400 Subject: =?UTF-8?B?UmVbMl06INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <1157052269.20140124150807@ngs.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> <1157052269.20140124150807@ngs.ru> Message-ID: <1665907832.20140124123643@softsearch.ru> Здравствуйте, Pavel. >>> Кто-нибудь может кинуть ссылку на более наглядные объяснения с >>> более человекопонятной схемой, как это ломается? Либо может быть >>> кто-то разъяснит "на пальцах", как злоумышленник, имея одну или >>> несколько пар "userId + keyedhash" сможет сгенерировать пару >>> "admin_userId + valid_keyedhash"? >> Полным перебором это ломается. Просто процессоры стали сильно быстрые >> и многоядерные. SHA1 считается слишком быстро. > Почему тогда нет проблемы если использовать HMAC-SHA1 ? > Из-за того, что считается sha1 от вычисленного в sha1, > что дает "сброс внутреннего состояния" хеширующей функции? Нет. Вместо конкатенации данных и секретного ключа HMAC размазывает и перемешивает биты ключа по всему хэшу. Двойной sha1 видимо так же ломается. Иначе применяли бы его, а не изобретали HMAC. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Jan 24 08:48:02 2014 From: nginx-forum at nginx.us (paulstrong) Date: Fri, 24 Jan 2014 03:48:02 -0500 Subject: =?UTF-8?B?UmU6IE5naW54INC4INC00LXRgdGP0YLQutC4INGC0YvRgdGP0Ycg0LLQuNGA0YI=?= =?UTF-8?B?0YPQsNC70YzQvdGL0YUg0YXQvtGB0YLQvtCy?= In-Reply-To: <4c585e065b1d4110226addf94d4f7ba8.NginxMailingListRussian@forum.nginx.org> References: <4c585e065b1d4110226addf94d4f7ba8.NginxMailingListRussian@forum.nginx.org> Message-ID: paulstrong Wrote: ------------------------------------------------------- > Добрый день, коллеги! > У нас возник вопрос, связанный с использованием десятков тысяч > виртуальных хостов (мы рассматриваем это как одно из решений нашей > задачи). > Скажем, как себя теоретически может повести nginx, если у него будет, > например, 10 конфигов, в каждом из них будет по 20к различных > server_name? нагрузки, естественно, не маленькие, до бекендов около 100RPS, если брать во внимание статику, то возможны и все 1000RPS. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246776,246778#msg-246778 From igor at sysoev.ru Fri Jan 24 09:38:09 2014 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 24 Jan 2014 13:38:09 +0400 Subject: =?UTF-8?B?UmU6INC20YPRgNC90LDQuyDQuNGB0YXQvtC00Y/RidC40YUg0Lgg0LLRhdC+0LQ=?= =?UTF-8?B?0Y/RidC40YUg0YHQvtC10LTQuNC90LXQvdC40Lk=?= In-Reply-To: <4b5bbc609ba4eb9a4021f34ffb797355.NginxMailingListRussian@forum.nginx.org> References: <4b5bbc609ba4eb9a4021f34ffb797355.NginxMailingListRussian@forum.nginx.org> Message-ID: <307041EB-7C66-45B8-8BF5-FD550DCD6B3F@sysoev.ru> On Jan 24, 2014, at 12:20 , misha_shar53 wrote: > Есть ли в NGINX журнал входящих и исходящих соединений. Если есть то как его > подключить и где посмотреть? > access_log /home/misha/Devel/wrk/nginx/access.log; > access_log on; "access_log on" создал дополнительный лог-файл "on": http://nginx.org/ru/docs/http/ngx_http_log_module.html#access_log > Это ничего не дало. В access.log должны быть запросы клиентов, можно туда добавать переменных, связанных с исходящими соединениями: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables Настаривается это с помощью log_format: http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_format -- Igor Sysoev http://nginx.com From nginx-forum at nginx.us Fri Jan 24 09:40:27 2014 From: nginx-forum at nginx.us (Dimka) Date: Fri, 24 Jan 2014 04:40:27 -0500 Subject: =?UTF-8?B?UmU6INCR0L7QtdCy0LDRjyDQutC+0L3RhNC40LPRg9GA0LDRhtC40Y8=?= In-Reply-To: <52E102F7.3090301@citrin.ru> References: <52E102F7.3090301@citrin.ru> Message-ID: <368a2bfd754989997dbefaf70143561f.NginxMailingListRussian@forum.nginx.org> Спасибо! Понял! Это и хотел услышать. По ходу дела буду мониторить и при необходимости - править узкие места! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246702,246781#msg-246781 From pavel2000 at ngs.ru Fri Jan 24 10:19:23 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Fri, 24 Jan 2014 17:19:23 +0700 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <1665907832.20140124123643@softsearch.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> <1157052269.20140124150807@ngs.ru> <1665907832.20140124123643@softsearch.ru> Message-ID: <1354569765.20140124171923@ngs.ru> Здравствуйте, Михаил. >>> Полным перебором это ломается. Просто процессоры стали сильно быстрые >>> и многоядерные. SHA1 считается слишком быстро. >> Почему тогда нет проблемы если использовать HMAC-SHA1 ? >> Из-за того, что считается sha1 от вычисленного в sha1, >> что дает "сброс внутреннего состояния" хеширующей функции? > Нет. Вместо конкатенации данных и секретного ключа HMAC размазывает и > перемешивает биты ключа по всему хэшу. > Двойной sha1 видимо так же ломается. Иначе применяли бы его, а не > изобретали HMAC. Я смотрел, как работает HMAC, и конечно же не имел ввиду чистую sha1(sha1(key||message)). Фактически HMAC-SHA1 это sha1(key_pad1 || sha1 (key_pad2 || message)) что не сильно далеко ушло от sha1(sha1(key||message)). В вычислениях HMAC key_pad1 и key_pad2 это сугубо статические значения, зависящие от ключа. Не совсем понятно, как происходит это размазывание и почему нельзя выбрать два _произвольных_ key_pad1 и key_pad2. Фактически блочный XOR ключа (приведенного до нужной длинны) на значения $36 и $5C дает произвольные значения, разве нет? В общем, тема интересная, читать можно много, были бы где "наглядные объяснения" ) А может оно и лучше, что "наглядных объяснений" не так много, а то переломали бы половину интернета. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From mdounin at mdounin.ru Fri Jan 24 11:51:45 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 24 Jan 2014 15:51:45 +0400 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <1354569765.20140124171923@ngs.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> <1157052269.20140124150807@ngs.ru> <1665907832.20140124123643@softsearch.ru> <1354569765.20140124171923@ngs.ru> Message-ID: <20140124115144.GG1835@mdounin.ru> Hello! On Fri, Jan 24, 2014 at 05:19:23PM +0700, Pavel V. wrote: > Здравствуйте, Михаил. > > >>> Полным перебором это ломается. Просто процессоры стали сильно быстрые > >>> и многоядерные. SHA1 считается слишком быстро. > > >> Почему тогда нет проблемы если использовать HMAC-SHA1 ? > > >> Из-за того, что считается sha1 от вычисленного в sha1, > >> что дает "сброс внутреннего состояния" хеширующей функции? > > > Нет. Вместо конкатенации данных и секретного ключа HMAC размазывает и > > перемешивает биты ключа по всему хэшу. > > > Двойной sha1 видимо так же ломается. Иначе применяли бы его, а не > > изобретали HMAC. > > Я смотрел, как работает HMAC, и конечно же не имел ввиду чистую sha1(sha1(key||message)). > > Фактически HMAC-SHA1 это sha1(key_pad1 || sha1 (key_pad2 || message)) что не сильно далеко ушло > от sha1(sha1(key||message)). В вычислениях HMAC key_pad1 и key_pad2 это сугубо статические значения, > зависящие от ключа. > > Не совсем понятно, как происходит это размазывание и почему нельзя выбрать два _произвольных_ > key_pad1 и key_pad2. Фактически блочный XOR ключа (приведенного до нужной длинны) на значения > $36 и $5C дает произвольные значения, разве нет? > > В общем, тема интересная, читать можно много, были бы где "наглядные объяснения" ) > А может оно и лучше, что "наглядных объяснений" не так много, а то переломали бы половину интернета. Наиболее наглядное объяснение про собственные MAC'и - это length extension attack на конструкции вида hash(secret || message) (aka "secret prefix"). http://en.wikipedia.org/wiki/Length_extension_attack Проблема, IMHO, не в том, что sha1(sha1(key||message)) - ломается (AFAIK, иначе как грубой силой - не ломается), проблема - в том, что когда люди изобретают на коленке - они зачастую ходят по давно известным и элементарным граблям. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Fri Jan 24 12:47:06 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 24 Jan 2014 16:47:06 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgVW5peCDRgdC+0Lo=?= =?UTF-8?B?0LXRgg==?= In-Reply-To: References: Message-ID: <20140124124706.GJ1835@mdounin.ru> Hello! On Thu, Jan 23, 2014 at 11:21:35PM -0500, misha_shar53 wrote: > Попытка перенаправить запрос на Unix сокет не удалась. Почему ? Хотя на SCGI > естественно прошла. > location /exo { > proxy_pass unix:/home/misha/nginx/scgi.socket; > # scgi_pass unix:/home/misha/nginx/scgi.socket; > # include scgi_params; > } Правильно так: proxy_pass http://unix:/home/misha/nginx/backend.socket; Должен быть указан протокол, "http://". Ну и backend.socket - должен слушаться приложением, ожидающим HTTP (а не scgi, как можно предположить из процитированного выше конфига с "scgi.socket"). Подробности тут: http://nginx.org/r/proxy_pass/ru -- Maxim Dounin http://nginx.org/ From postmaster at softsearch.ru Fri Jan 24 12:47:59 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 24 Jan 2014 16:47:59 +0400 Subject: =?UTF-8?B?UmVbMl06INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8=?= In-Reply-To: <20140124115144.GG1835@mdounin.ru> References: <88eec546842d3bee9a82e83857dccd78.NginxMailingListRussian@forum.nginx.org> <1149969710.20140121004026@softsearch.ru> <52DD8D17.5060706@citrin.ru> <437911983.20140123152119@ngs.ru> <1157052269.20140124150807@ngs.ru> <1665907832.20140124123643@softsearch.ru> <1354569765.20140124171923@ngs.ru> <20140124115144.GG1835@mdounin.ru> Message-ID: <1263143125.20140124164759@softsearch.ru> Здравствуйте, Maxim. > Наиболее наглядное объяснение про собственные MAC'и - это length > extension attack на конструкции вида hash(secret || message) (aka > "secret prefix"). > http://en.wikipedia.org/wiki/Length_extension_attack Там написано: "The SHA-3 algorithm is not susceptible to this attack." Но как всегда, наверное, есть какие-то другие подводные камни... -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Jan 24 13:00:20 2014 From: nginx-forum at nginx.us (misha_shar53) Date: Fri, 24 Jan 2014 08:00:20 -0500 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgVW5peCDRgdC+0Lo=?= =?UTF-8?B?0LXRgg==?= In-Reply-To: <20140124124706.GJ1835@mdounin.ru> References: <20140124124706.GJ1835@mdounin.ru> Message-ID: <89e3c8be498c781ae123678a1d4c9ef4.NginxMailingListRussian@forum.nginx.org> Спасибо понял. Документация великая вещь. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246768,246789#msg-246789 From mdounin at mdounin.ru Fri Jan 24 13:22:12 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 24 Jan 2014 17:22:12 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC4INC00LXRgdGP0YLQutC4INGC0YvRgdGP0Ycg0LLQuNGA0YI=?= =?UTF-8?B?0YPQsNC70YzQvdGL0YUg0YXQvtGB0YLQvtCy?= In-Reply-To: <4c585e065b1d4110226addf94d4f7ba8.NginxMailingListRussian@forum.nginx.org> References: <4c585e065b1d4110226addf94d4f7ba8.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140124132212.GK1835@mdounin.ru> Hello! On Fri, Jan 24, 2014 at 03:30:55AM -0500, paulstrong wrote: > Добрый день, коллеги! > У нас возник вопрос, связанный с использованием десятков тысяч виртуальных > хостов (мы рассматриваем это как одно из решений нашей задачи). > Скажем, как себя теоретически может повести nginx, если у него будет, > например, 10 конфигов, в каждом из них будет по 20к различных server_name? server_name != вируальный хост Если речь о идёт именно о большом количестве блоков server{}, то на таких количествах следует учитывать, что каждый блок server{} потребляет небольшое количество памяти под свои конфиги (когда я последний раз смотрел, получалось что-то около 20 килобайт на server{}, но эта цифра сильно зависит от сложности конфига сервера и модулей, с которыми собран nginx). Т.е. 200 тысяч блоков server{} - это где-то 4 гигабайта памяти. Если же речь именно о server_name'ах в рамках небольшого количества блоков server{} - то 200 тысяч это не много. Ну в любом случае потребуется тюнинг server_names_hash_bucket_size и server_names_hash_max_size, документация тут: http://nginx.org/r/server_names_hash_bucket_size/ru http://nginx.org/r/server_names_hash_max_size/ru -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Sat Jan 25 04:13:29 2014 From: nginx-forum at nginx.us (misha_shar53) Date: Fri, 24 Jan 2014 23:13:29 -0500 Subject: =?UTF-8?B?0JDQtNGA0LXRgSDQvtGC0L/RgNCw0LLQuNGC0LXQu9GPINC/0YDQuCDQv9GA0L4=?= =?UTF-8?B?0LrRgdC40YDQvtCy0LDQvdC40Lg=?= Message-ID: Есть ли возможность установить Адрес отправителя. Если NGINX используется в качестве прокси сервера? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246811,246811#msg-246811 From pavel2000 at ngs.ru Sat Jan 25 05:27:29 2014 From: pavel2000 at ngs.ru (Pavel V.) Date: Sat, 25 Jan 2014 12:27:29 +0700 Subject: =?UTF-8?B?UmU6INCQ0LTRgNC10YEg0L7RgtC/0YDQsNCy0LjRgtC10LvRjyDQv9GA0Lgg0L8=?= =?UTF-8?B?0YDQvtC60YHQuNGA0L7QstCw0L3QuNC4?= In-Reply-To: References: Message-ID: <941742525.20140125122729@ngs.ru> Здравствуйте, misha_shar53. Вы писали 25 января 2014 г., 11:13:29: > Есть ли возможность установить Адрес отправителя. Если NGINX используется в > качестве прокси сервера? http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind -- С уважением, Pavel mailto:pavel2000 at ngs.ru From mva at mva.name Sun Jan 26 05:55:55 2014 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 26 Jan 2014 12:55:55 +0700 Subject: =?UTF-8?B?UmU6INCf0L4g0LrQsNC60L7QuS3RgtC+INC/0YDQuNGH0LjQvdC1IG5naW54INC0?= =?UTF-8?B?0LDRkdGCINC30LDQtNC10YDQttC60YMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: <52E0E595.3020708@rufox.ru> References: <52E0E595.3020708@rufox.ru> Message-ID: <4724358.RgZrbWYdTE@note> > Подскажите пожалуйста, в каких направлениях искать причину проблемы. На сколько могу судить я, не будучи разработчиком NginX, никакой проблемы здесь нет. Если тестировать ТОЛЬКО выполнение PHP-скриптов с проксированием и без, то логически очевидно, что дополнительный слой типа проксирования будет вносить лишь дополнительный задержки. Задача NginX обычно состоит слегка в другом. // Вчера в IRC-канале NginX в RusNet пробегала ссылка[1]. Мне не нравится ни стиль написания автора, ни называние NginX "нгинксом", но саму суть он (как раз для вашего случая) изложил верно. [1] http://slonik-v-domene.livejournal.com/142305.html -- Best regsrds, mva From onokonem at gmail.com Sun Jan 26 08:35:35 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 26 Jan 2014 12:35:35 +0400 Subject: =?UTF-8?B?UmU6INCf0L4g0LrQsNC60L7QuS3RgtC+INC/0YDQuNGH0LjQvdC1IG5naW54INC0?= =?UTF-8?B?0LDRkdGCINC30LDQtNC10YDQttC60YMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: <4724358.RgZrbWYdTE@note> References: <52E0E595.3020708@rufox.ru> <4724358.RgZrbWYdTE@note> Message-ID: > Мне не нравится ... называние NginX "нгинксом" выбор невелик - или постоянно переключать раскладку, или писать "энджиникс", или писать "нгинкс". я лично переключаю раскладку, но это задалбывает. а статья хорошая, годная статья. From mva at mva.name Sun Jan 26 14:02:57 2014 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 26 Jan 2014 21:02:57 +0700 Subject: =?UTF-8?B?UmU6INCf0L4g0LrQsNC60L7QuS3RgtC+INC/0YDQuNGH0LjQvdC1IG5naW54INC0?= =?UTF-8?B?0LDRkdGCINC30LDQtNC10YDQttC60YMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: References: <52E0E595.3020708@rufox.ru> <4724358.RgZrbWYdTE@note> Message-ID: <1561032.Y72e08sIbc@note> > выбор невелик - или постоянно переключать раскладку, или писать > "энджиникс", или писать "нгинкс". Да хоть бы уж "нжинкс"[1] тогда, чтоли... Всяко не так по ушам режет, как "нгинкс" :) [1] правда, есть упоротые люди, которые его "нженикс" зовут (имея в виду именно NginX)... -- Best regsrds, mva From exelib at googlemail.com Sun Jan 26 15:03:17 2014 From: exelib at googlemail.com (Anton Bessonov) Date: Sun, 26 Jan 2014 16:03:17 +0100 Subject: =?UTF-8?B?UmU6INCd0LUg0L7RgtC+0LHRgNCw0LbQsNGO0YLRgdGPINC60LDRgNGC0LjQvdC6?= =?UTF-8?B?0Lgg0L/QvtGB0LvQtSDRgNC10YHQsNC50LfQuNC90LPQsA==?= In-Reply-To: <03412b1e9588b1e1f6bf8f7da2b6628b.NginxMailingListRussian@forum.nginx.org> References: <03412b1e9588b1e1f6bf8f7da2b6628b.NginxMailingListRussian@forum.nginx.org> Message-ID: <52E523B5.5080500@googlemail.com> Думаю, где-то таймаут срабатывает. А что, если ресайсить энжином? On 24.01.2014 08:12, Miklucho wrote: > Имеются nginx+apache+php на CentOS > Потребовалось сделать ресайз картинок на лету по ссылкам типа: > http://www.sitename.ru/thumb/350x250xin/images_path/image_name.jpg > Реализовал следующим образом > > 1. В nginx проверяем существование картинки, если не существует > перенаправляем на Апач. > location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js)$ { > root /home/www/sitename.ru/www/; > try_files $uri @fallback; > } > location @fallback { > proxy_pass http://backend; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_connect_timeout 120; > proxy_send_timeout 120; > proxy_read_timeout 180; > } > > 2. На бекэнде в .htaccess свое перенаправление: > RewriteRule ^thumb/(.*) /thumb.php?req=$1 > > 3. Скрипт thumb.php выполняет ресайз, сохраняет картинку для кеша и отдает > ее в браузер. > > Схема работает, но есть такая проблема. На странице одновременно выводится > до 10 таких картинок, так вот при первом заходе на страницу отображается > только 1-2 изображения из десяти. Для остальных браузер рисует стандартную > иконку отсутствующей картинки. Причем если посмотреть на FTP - отресайзенные > картинки существуют! > При обновлении страницы уже все картинки отображаются корректно. > > Мне кажется, что проблема в том, что php сравнительно медленно ресайзит > изображения и из-за этого срабатывают какие-то таймауты, либо в apache, либо > в nginx. > Не подскажет ли кто куда мне копать? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246772,246772#msg-246772 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Certified Prince2:2009 Project Manager Professional Scrum Master I & II Oracle Certified Expert, Enterprise JavaBeans Developer Oracle Certified Professional, Java SE 6 Programmer Now that's a test of the character of an organization. Of the organizations that are attempting to implement Scrum probably, 30% - 35% will successfully implement it. - Ken Schwaber From nginx-forum at nginx.us Mon Jan 27 07:17:27 2014 From: nginx-forum at nginx.us (paulstrong) Date: Mon, 27 Jan 2014 02:17:27 -0500 Subject: =?UTF-8?B?UmU6IE5naW54INC4INC00LXRgdGP0YLQutC4INGC0YvRgdGP0Ycg0LLQuNGA0YI=?= =?UTF-8?B?0YPQsNC70YzQvdGL0YUg0YXQvtGB0YLQvtCy?= In-Reply-To: <20140124132212.GK1835@mdounin.ru> References: <20140124132212.GK1835@mdounin.ru> Message-ID: <39cb99fe0d31e4007f94950eea5e5098.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ! Если есть возможность, ответьте тогда, исходя из вашего опыта. Встречались ли вам подобные решения? Получается, при добавлении нового server_name, необходимо делать reload? Как себя поведет nginx под нагрузкой в таком случае? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246776,246846#msg-246846 From nginx-forum at nginx.us Mon Jan 27 07:21:18 2014 From: nginx-forum at nginx.us (muirdok) Date: Mon, 27 Jan 2014 02:21:18 -0500 Subject: =?UTF-8?B?0JDQstGC0L7RgNC40LfQsNGG0LjRjy4g0J7QtNC40L0g0LDQstGC0L7RgNC40Lc=?= =?UTF-8?B?0L7QstCw0L3QvdGL0Lkg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GMLg==?= Message-ID: <36961ed8f6b048d4637a621dd4e0ca0f.NginxMailingListRussian@forum.nginx.org> Доброе время суток. Подскажите пжста есть ли у auch_bacis или у любого другого модуля возможность авторизовать только одного пользователя в один момент времени. Я имею ввиду что если пользователь уже авторизовался, то под этими "кредами" не смог авторизоваться другой пользователь. Часовое гугление не дало мне ответа на этот вопрос. Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246847,246847#msg-246847 From nginx-forum at nginx.us Mon Jan 27 08:09:26 2014 From: nginx-forum at nginx.us (Miklucho) Date: Mon, 27 Jan 2014 03:09:26 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0L7RgtC+0LHRgNCw0LbQsNGO0YLRgdGPINC60LDRgNGC0LjQvdC6?= =?UTF-8?B?0Lgg0L/QvtGB0LvQtSDRgNC10YHQsNC50LfQuNC90LPQsA==?= In-Reply-To: <03412b1e9588b1e1f6bf8f7da2b6628b.NginxMailingListRussian@forum.nginx.org> References: <03412b1e9588b1e1f6bf8f7da2b6628b.NginxMailingListRussian@forum.nginx.org> Message-ID: <601b65a801863702aa8c380daaaea236.NginxMailingListRussian@forum.nginx.org> Хотя нет, написал не разобравшись. На каждую картинку в логе два ответа - 301-й это как раз перенаправление из htaccess, а 200-й - выдача php-скрипта. В общем я разобрался с проблемой, которая оказалась банальной до отчаяния ошибкой в php-коде - функция mkdir пыталась повторно создать папку, которая уже была создана при запросе первой картинки, в итоге сервер выдавал несколько warning'ов со всеми вытекающими последствиями. Извините за беспокойство. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246772,246848#msg-246848 From nginx-forum at nginx.us Mon Jan 27 08:31:39 2014 From: nginx-forum at nginx.us (foboss) Date: Mon, 27 Jan 2014 03:31:39 -0500 Subject: =?UTF-8?B?0J3QtSDQvNC+0LPRgyDQt9Cw0YHRgtCw0LLQuNGC0YwgcmVnZXhwINGA0LXQsNCz?= =?UTF-8?B?0LjRgNC+0LLQsNGC0Ywg0L3QsCDRgdC40LzQstC+0LsgIj8i?= Message-ID: <3abe3a0a1bb7e1c95b038424f31142b7.NginxMailingListRussian@forum.nginx.org> Добрый день! Пытаюсь запустить правило: rewrite ^([^.\?]*[^/])$ $1/ permanent; Оно должно добавлять "/" в конец запроса в случае, если в нем не содержится "." или "?" и оно не оканчивается на "/" Nginx отрабатывает только "." и "/": * qwerty -> qwerty/ * qwe.rty -> qwe.rty * qwe?rty -> qwe/?rty !!! В https://www.debuggex.com/ условие "^([^.\?]*[^/])$" работает как ожидается: * qwerty - найден * qwe.rty - не найден * qwe?rty - не найден Подскажите, как составить regexp правильно? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246849,246849#msg-246849 From nefer05 at gmail.com Mon Jan 27 08:36:13 2014 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Mon, 27 Jan 2014 12:36:13 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0LzQvtCz0YMg0LfQsNGB0YLQsNCy0LjRgtGMIHJlZ2V4cCDRgNC1?= =?UTF-8?B?0LDQs9C40YDQvtCy0LDRgtGMINC90LAg0YHQuNC80LLQvtC7ICI/Ig==?= In-Reply-To: <3abe3a0a1bb7e1c95b038424f31142b7.NginxMailingListRussian@forum.nginx.org> References: <3abe3a0a1bb7e1c95b038424f31142b7.NginxMailingListRussian@forum.nginx.org> Message-ID: Все верно оно делает. В запросе НЕТ знаков вопроса. Ибо это разделитель между строкой запроса и аргументами. 2014-01-27 foboss > Добрый день! > > Пытаюсь запустить правило: > rewrite ^([^.\?]*[^/])$ $1/ permanent; > > Оно должно добавлять "/" в конец запроса в случае, если в нем не содержится > "." или "?" и оно не оканчивается на "/" > > Nginx отрабатывает только "." и "/": > * qwerty -> qwerty/ > * qwe.rty -> qwe.rty > * qwe?rty -> qwe/?rty !!! > > В https://www.debuggex.com/ условие "^([^.\?]*[^/])$" работает как > ожидается: > * qwerty - найден > * qwe.rty - не найден > * qwe?rty - не найден > > Подскажите, как составить regexp правильно? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246849,246849#msg-246849 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Jan 27 08:36:30 2014 From: nginx-forum at nginx.us (misha_shar53) Date: Mon, 27 Jan 2014 03:36:30 -0500 Subject: =?UTF-8?B?0J7RgtCy0LXRgiDQv9GA0L7QutGB0Lgg0YHQtdGA0LLQtdGA0LA=?= Message-ID: <93f38b914d1a26b05736b902b05dcfc6.NginxMailingListRussian@forum.nginx.org> Не могу переслать ответ браузеру. NGINX настроен на передачу сообщений в прокси программу. server { listen 4330; location / {root html; index index.html index.htm;} location /exo { proxy_pass http://localhost:4340; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } error_page 500 502 503 504 /50x.html; location = /50x.html {root html;} } Сообщение в прокси программе я принимаю. Пытаюсь ответить сообщением: *buf="HTTP/1.0 200 OK\r\n\r\n"; Сообщение до браузера не доходит. Наверно нужны какие то обязательные заголовки в ответе? В спецификации на HTTP 1.0 написано что этого достаточно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246850,246850#msg-246850 From nginx-forum at nginx.us Mon Jan 27 08:48:29 2014 From: nginx-forum at nginx.us (foboss) Date: Mon, 27 Jan 2014 03:48:29 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0LzQvtCz0YMg0LfQsNGB0YLQsNCy0LjRgtGMIHJlZ2V4cCDRgNC1?= =?UTF-8?B?0LDQs9C40YDQvtCy0LDRgtGMINC90LAg0YHQuNC80LLQvtC7ICI/Ig==?= In-Reply-To: References: Message-ID: Спасибо! Подскажите, как правильно поступить в данном случае? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246849,246852#msg-246852 From nefer05 at gmail.com Mon Jan 27 08:54:53 2014 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Mon, 27 Jan 2014 12:54:53 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0LzQvtCz0YMg0LfQsNGB0YLQsNCy0LjRgtGMIHJlZ2V4cCDRgNC1?= =?UTF-8?B?0LDQs9C40YDQvtCy0LDRgtGMINC90LAg0YHQuNC80LLQvtC7ICI/Ig==?= In-Reply-To: References: Message-ID: Есть переменная $is_args. Но как это правильнее к вашей задаче прикрутить... Я бы в лоб сделал - через if. 2014-01-27 foboss > Спасибо! > > Подскажите, как правильно поступить в данном случае? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246849,246852#msg-246852 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Mon Jan 27 09:03:24 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 27 Jan 2014 13:03:24 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0YDQvtCx0LvQtdC80Ysg0YEg0LrRjdGI0LXQvA==?= In-Reply-To: <104699830.20140120012845@softsearch.ru> References: <955964865.20140119131932@softsearch.ru> <104699830.20140120012845@softsearch.ru> Message-ID: <595918866.20140127130324@softsearch.ru> Здравствуйте, Михаил. UP -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Mon Jan 27 09:23:38 2014 From: nginx-forum at nginx.us (foboss) Date: Mon, 27 Jan 2014 04:23:38 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0LzQvtCz0YMg0LfQsNGB0YLQsNCy0LjRgtGMIHJlZ2V4cCDRgNC1?= =?UTF-8?B?0LDQs9C40YDQvtCy0LDRgtGMINC90LAg0YHQuNC80LLQvtC7ICI/Ig==?= In-Reply-To: References: Message-ID: Да, все получилось. Итог таков: if ($is_args = "") { rewrite ^([^.]*[^/])$ $1/ permanent; } Спасибо еще раз! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246849,246855#msg-246855 From nginx-forum at nginx.us Mon Jan 27 09:54:39 2014 From: nginx-forum at nginx.us (skeletor) Date: Mon, 27 Jan 2014 04:54:39 -0500 Subject: "recv() failed (71: Protocol error) while keepalive" Message-ID: <8e28e6566a9f0833cbad07c1a385ec45.NginxMailingListRussian@forum.nginx.org> Вот такое редко проскакивает в логах. Что это может значить? Нашёл на одном ресурсе описание ошибки 71. Привожу цитату: Очень частый случай это когда веб-сервер вместо ответа просто посылает FIN, потому что на его стороне воркер упал или что еще нехорошее Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246857,246857#msg-246857 From mdounin at mdounin.ru Mon Jan 27 13:13:36 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Jan 2014 17:13:36 +0400 Subject: "recv() failed (71: Protocol error) while keepalive" In-Reply-To: <8e28e6566a9f0833cbad07c1a385ec45.NginxMailingListRussian@forum.nginx.org> References: <8e28e6566a9f0833cbad07c1a385ec45.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140127131336.GS1835@mdounin.ru> Hello! On Mon, Jan 27, 2014 at 04:54:39AM -0500, skeletor wrote: > Вот такое редко проскакивает в логах. Что это может значить? Нашёл на одном > ресурсе описание ошибки 71. Привожу цитату: > > Очень частый случай это когда веб-сервер вместо ответа просто посылает FIN, > потому что на его стороне воркер упал или что еще нехорошее Цитата очевидно неправильная, т.к. FIN вместо ответа - это вполне штатный способ закрыть соединение. Судя по коду ядра Linux'а (судя по коду ошибки, операционная система - Linux?) - такое может быть при получении ICMP Parameter Problem. Почему оно у вас возникает - отдельный интересный вопрос. Вообще POSIX не предполагает возврат EPROTO из recv(), см. тут: http://pubs.opengroup.org/onlinepubs/9699919799/functions/recv.html -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Jan 27 13:20:03 2014 From: nginx-forum at nginx.us (skeletor) Date: Mon, 27 Jan 2014 08:20:03 -0500 Subject: "recv() failed (71: Protocol error) while keepalive" In-Reply-To: <20140127131336.GS1835@mdounin.ru> References: <20140127131336.GS1835@mdounin.ru> Message-ID: <6230eced248d31e04fefc85095b45161.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ, Максим. ОС - Solaris 11 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246857,246865#msg-246865 From mdounin at mdounin.ru Mon Jan 27 13:44:38 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Jan 2014 17:44:38 +0400 Subject: "recv() failed (71: Protocol error) while keepalive" In-Reply-To: <6230eced248d31e04fefc85095b45161.NginxMailingListRussian@forum.nginx.org> References: <20140127131336.GS1835@mdounin.ru> <6230eced248d31e04fefc85095b45161.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140127134438.GT1835@mdounin.ru> Hello! On Mon, Jan 27, 2014 at 08:20:03AM -0500, skeletor wrote: > Спасибо за ответ, Максим. ОС - Solaris 11 О, операционная система для сильных духом. Узнаете, почему Solaris делает так - расскажете. :) -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Mon Jan 27 14:12:52 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Jan 2014 18:12:52 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEg0LrRjdGI0LXQvA==?= In-Reply-To: <595918866.20140127130324@softsearch.ru> References: <955964865.20140119131932@softsearch.ru> <104699830.20140120012845@softsearch.ru> <595918866.20140127130324@softsearch.ru> Message-ID: <20140127141252.GU1835@mdounin.ru> Hello! On Mon, Jan 27, 2014 at 01:03:24PM +0400, Михаил Монашёв wrote: > Здравствуйте, Михаил. > > UP Миша, проблемы вида "у меня в подполе раздаётся подземный стук" - они малопригодны для анализа. Умозрительно - скорее всего в тех кешах, что начали уменьшаться, по каким-то причинам оказалось много неактивных элементов, и cache manager был занят их чисткой (и посему не следил за размером того кеша, что начал в результате расти). Такого можно добиться, e.g., загрузив кеши с сильно раскаченными параметрами загрузки (loader_files/loader_threshold), и потом не используя часть кешей. Или сильно подвинуть время на машине - эффект будет похожий. -- Maxim Dounin http://nginx.org/ From postmaster at softsearch.ru Mon Jan 27 15:49:30 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 27 Jan 2014 19:49:30 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0YDQvtCx0LvQtdC80Ysg0YEg0LrRjdGI0LXQvA==?= In-Reply-To: <20140127141252.GU1835@mdounin.ru> References: <955964865.20140119131932@softsearch.ru> <104699830.20140120012845@softsearch.ru> <595918866.20140127130324@softsearch.ru> <20140127141252.GU1835@mdounin.ru> Message-ID: <574312157.20140127194930@softsearch.ru> Здравствуйте, Maxim. > Умозрительно - скорее всего в тех кешах, что начали уменьшаться, по > каким-то причинам оказалось много неактивных элементов, и cache > manager был занят их чисткой (и посему не следил за размером того > кеша, что начал в результате расти). Такого можно добиться, e.g., > загрузив кеши с сильно раскаченными параметрами загрузки > (loader_files/loader_threshold), и потом не используя часть кешей. > Или сильно подвинуть время на машине - эффект будет похожий. Возможно произошло именно это. Неожиданно то, что параметры, относящиеся к кэш-лоадеру, оказывается влияют и на кэш-менеджер. Кэш тем эффективнее, чем больше в нём элементов. Т.е. если на разделе быстрого SSD-диска есть 500 гигов, то хорошо бы под кэш отвести 499 и один оставить под всякие временные директории и подобное. И раз в пол года нужно перезапустить nginx, да так, чтобы он за время перезапуска не занял растущим без кэш-менеджера кэшем оставшееся доступное место. И если даже раз в пол года кэш будет тормозить 5 минут - это ерунда по сравнению с тем, насколько больше файлов в него влезет. Поэтому я стараюсь максимально ускорить загрузку кэша описанными выше параметрами. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Mon Jan 27 15:58:30 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Jan 2014 19:58:30 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQstC10YIg0L/RgNC+0LrRgdC4INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <93f38b914d1a26b05736b902b05dcfc6.NginxMailingListRussian@forum.nginx.org> References: <93f38b914d1a26b05736b902b05dcfc6.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140127155830.GX1835@mdounin.ru> Hello! On Mon, Jan 27, 2014 at 03:36:30AM -0500, misha_shar53 wrote: > Не могу переслать ответ браузеру. > NGINX настроен на передачу сообщений в прокси программу. > server { > listen 4330; > location / {root html; index index.html index.htm;} > location /exo { > proxy_pass http://localhost:4340; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > } > error_page 500 502 503 504 /50x.html; > location = /50x.html {root html;} > } > Сообщение в прокси программе я принимаю. > Пытаюсь ответить сообщением: > *buf="HTTP/1.0 200 OK\r\n\r\n"; > Сообщение до браузера не доходит. > Наверно нужны какие то обязательные заголовки в ответе? > В спецификации на HTTP 1.0 написано что этого достаточно. В соответствии со спецификацией HTTP/1.0 - надо ещё как минимум закрыть соединение. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Jan 27 15:58:31 2014 From: nginx-forum at nginx.us (nginx_problem) Date: Mon, 27 Jan 2014 10:58:31 -0500 Subject: =?UTF-8?B?cHJveHkgcmVhZCB0aW1lb3V0INC30LDQutGA0YvQstCw0LXRgiDRgdC+0LXQtNC4?= =?UTF-8?B?0L3QtdC90LjQtSwg0L3QtSDQv9C+0LvRg9GH0LjQsiDQvtGC0LLQtdGC?= Message-ID: <754f458ea6f915364e71bb2757cee164.NginxMailingListRussian@forum.nginx.org> Добрый день. Столкнулся с проблемой, когда срабатывает proxy_read_timeout еще до получения какого-либо ответа от бакэнда. Ситуация такая: есть скрипт, который отправляет POST данные на локальный nginx, который проксирует запрос на upstream backend и получает ответ. Сначала причиной таймаута оказался HTTP/100 Continue. По советам перевел запрос в HTTP/1.0: в курл добавил опцию curl_setopt($Curl, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_0), в nginx добавил proxy_http_version 1.0; При этом apache backend все равно отвечал HTTP/1.1 с предварительным HTTP/100 Continue. Конфиг апача стандартный. Пришлось ставить загрушку в виде force-response-1.0 downgrade-1.0 для апача, в итоге перестал получать HTTP/100 Continue, но проблема с таймаутом не пропала. часть конфигурации nginx: location / { proxy_pass http://backend/; proxy_next_upstream error timeout http_500 http_502 http_503 http_504; proxy_redirect off; proxy_buffering off; proxy_intercept_errors off; reset_timedout_connection on; error_page 502 503 504 =403 @error_backend; send_timeout 8s; proxy_connect_timeout 5s; proxy_send_timeout 10s; proxy_read_timeout 12s; client_body_timeout 20s; proxy_http_version 1.0; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; add_header X-Upstream $upstream_addr; } location @error_backend { return 403 $upstream_addr; } для воспроизведения ошибки без посторонних факторов на бакэнде сделал скрипт отправил 450 байт данных через POST и записал пакеты через tcpdump. вот что получилось (ip1 - nginx, ip2 - apache backend): 1 0.000000 ip1 ip2 TCP 17433 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 WS=7 2 0.097472 ip2 ip1 TCP http > 17433 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=7 3 0.097577 ip1 ip2 TCP 17433 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 4 0.097655 ip1 ip2 HTTP POST /script.php HTTP/1.0 (application/x-www-form-urlencoded) 5 0.195452 ip2 ip1 TCP http > 17433 [ACK] Seq=1 Ack=685 Win=7296 Len=0 6 12.067504 ip1 ip2 TCP 17433 > http [FIN, ACK] Seq=685 Ack=1 Win=14720 Len=0 7 12.206336 ip2 ip1 TCP http > 17433 [ACK] Seq=1 Ack=686 Win=7296 Len=0 8 20.196969 ip2 ip1 HTTP HTTP/1.0 200 OK (text/html) 9 20.197196 ip2 ip1 TCP http > 17433 [FIN, ACK] Seq=194 Ack=686 Win=7296 Len=0 10 23.195793 ip2 ip1 HTTP [TCP Retransmission] HTTP/1.0 200 OK (text/html) 11 29.195275 ip2 ip1 HTTP [TCP Retransmission] HTTP/1.0 200 OK (text/html) апач после того, как принял POST, ответил нормальным ACK, и nginx судя по всему с этого момента начинает отсчет proxy_read_timeout, но ведь никаких данных от бакэнда принято еще не было. Подскажите, нормальная ли это работа proxy_read_timeout и он действительно включается даже после TCP флагов от бакэнда, либо это какой-то глюк? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246872,246872#msg-246872 From mdounin at mdounin.ru Mon Jan 27 16:11:53 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Jan 2014 20:11:53 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlYWQgdGltZW91dCDQt9Cw0LrRgNGL0LLQsNC10YIg0YHQvtC1?= =?UTF-8?B?0LTQuNC90LXQvdC40LUsINC90LUg0L/QvtC70YPRh9C40LIg0L7RgtCy0LU=?= =?UTF-8?B?0YI=?= In-Reply-To: <754f458ea6f915364e71bb2757cee164.NginxMailingListRussian@forum.nginx.org> References: <754f458ea6f915364e71bb2757cee164.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140127161153.GB1835@mdounin.ru> Hello! On Mon, Jan 27, 2014 at 10:58:31AM -0500, nginx_problem wrote: > Добрый день. Столкнулся с проблемой, когда срабатывает proxy_read_timeout > еще до получения какого-либо ответа от бакэнда. [...] > Подскажите, нормальная ли это работа proxy_read_timeout и он действительно > включается даже после TCP флагов от бакэнда, либо это какой-то глюк? Таймаут, заданный proxy_read_timeout, начинает отсчитываться сразу после того, как бекенду отправлен запрос. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Mon Jan 27 16:16:32 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Jan 2014 20:16:32 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEg0LrRjdGI0LXQvA==?= In-Reply-To: <574312157.20140127194930@softsearch.ru> References: <955964865.20140119131932@softsearch.ru> <104699830.20140120012845@softsearch.ru> <595918866.20140127130324@softsearch.ru> <20140127141252.GU1835@mdounin.ru> <574312157.20140127194930@softsearch.ru> Message-ID: <20140127161631.GC1835@mdounin.ru> Hello! On Mon, Jan 27, 2014 at 07:49:30PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > Умозрительно - скорее всего в тех кешах, что начали уменьшаться, по > > каким-то причинам оказалось много неактивных элементов, и cache > > manager был занят их чисткой (и посему не следил за размером того > > кеша, что начал в результате расти). Такого можно добиться, e.g., > > загрузив кеши с сильно раскаченными параметрами загрузки > > (loader_files/loader_threshold), и потом не используя часть кешей. > > Или сильно подвинуть время на машине - эффект будет похожий. > > Возможно произошло именно это. > > Неожиданно то, что параметры, относящиеся к кэш-лоадеру, оказывается > влияют и на кэш-менеджер. Они влияют на то, что в результате будет в кеше, а уже это, в свою очередь, влияет на cache manager. > Кэш тем эффективнее, чем больше в нём элементов. Т.е. если на разделе > быстрого SSD-диска есть 500 гигов, то хорошо бы под кэш отвести 499 и > один оставить под всякие временные директории и подобное. И раз в пол > года нужно перезапустить nginx, да так, чтобы он за время перезапуска > не занял растущим без кэш-менеджера кэшем оставшееся доступное место. > И если даже раз в пол года кэш будет тормозить 5 минут - это ерунда по > сравнению с тем, насколько больше файлов в него влезет. Поэтому я > стараюсь максимально ускорить загрузку кэша описанными выше > параметрами. IMHO, вместо этих извращений - надо обучить cache manager контролировать свободное место на диске. Должно стать существенно удобнее и проще. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Jan 27 17:05:13 2014 From: nginx-forum at nginx.us (nginx_problem) Date: Mon, 27 Jan 2014 12:05:13 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlYWQgdGltZW91dCDQt9Cw0LrRgNGL0LLQsNC10YIg0YHQvtC1?= =?UTF-8?B?0LTQuNC90LXQvdC40LUsINC90LUg0L/QvtC70YPRh9C40LIg0L7RgtCy0LU=?= =?UTF-8?B?0YI=?= In-Reply-To: <20140127161153.GB1835@mdounin.ru> References: <20140127161153.GB1835@mdounin.ru> Message-ID: В таком случае proxy_read_timeout нужно устанавливать по максимальному времени выполнения задачи на бекенде? Дело в том, что мы столкнулись с проблемой, когда один из бекендов принимал соединение, но не выполнял задачу (или выполнял ее неверно) и никогда не отвечал обратно, в итоге часть задач висела и ждала пока эти соединения не завершатся по одному из таймаутов. Небольшой процент запросов требует большого (от 5 до 10 минут) времени выполнения задачи на бекенде, поэтому, выставляя proxy_read_timeout по минимуму, чтобы отсеять соединения с нерабочим бекендом, мы потеряем часть легитимных соединений. Что Вы можете посоветовать, как отсеять выполняющиеся на бекенде соединения от подвисших? Есть ли у nginx на этот случай какой-то встроенный механизм? Например, если работающий бекенд будет посылать какие-то промежуточные ответы, чтобы nginx знал, что соединение живое и работает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246874,246878#msg-246878 From vbart at nginx.com Mon Jan 27 17:21:19 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 27 Jan 2014 21:21:19 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlYWQgdGltZW91dCDQt9Cw0LrRgNGL0LLQsNC10YIg0YHQvtC1?= =?UTF-8?B?0LTQuNC90LXQvdC40LUsINC90LUg0L/QvtC70YPRh9C40LIg0L7RgtCy0LU=?= =?UTF-8?B?0YI=?= In-Reply-To: References: <20140127161153.GB1835@mdounin.ru> Message-ID: <10619856.bb6cCGxjaa@vbart-laptop> On Monday 27 January 2014 12:05:13 nginx_problem wrote: [..] > Небольшой процент запросов требует большого (от 5 до 10 минут) времени > выполнения задачи на бекенде, поэтому, выставляя proxy_read_timeout по > минимуму, чтобы отсеять соединения с нерабочим бекендом, мы потеряем часть > легитимных соединений. [..] Такие задачи никто не выполняет в реальном времени, держа соединение в подвешенном состоянии. Складывайте задачи в очередь, возвращайте ответ, сообщающий об этом, и обрабатывайте в фоне сколько потребуется. -- Валентин Бартенев From mdounin at mdounin.ru Mon Jan 27 17:37:11 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Jan 2014 21:37:11 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC4INC00LXRgdGP0YLQutC4INGC0YvRgdGP0Ycg0LLQuNGA0YI=?= =?UTF-8?B?0YPQsNC70YzQvdGL0YUg0YXQvtGB0YLQvtCy?= In-Reply-To: <39cb99fe0d31e4007f94950eea5e5098.NginxMailingListRussian@forum.nginx.org> References: <20140124132212.GK1835@mdounin.ru> <39cb99fe0d31e4007f94950eea5e5098.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140127173711.GJ1835@mdounin.ru> Hello! On Mon, Jan 27, 2014 at 02:17:27AM -0500, paulstrong wrote: > Спасибо за ответ! Если есть возможность, ответьте тогда, исходя из вашего > опыта. Встречались ли вам подобные решения? Получается, при добавлении > нового server_name, необходимо делать reload? Как себя поведет nginx под > нагрузкой в таком случае? Делать reload необходимо при любом изменении конфига, без этого изменения конфигурации не применяются. В то же время, reload - это штатная процедура, и под нагрузкой выполняется без проблем. При проектировании, однако, следует учитывать, что в процессе reload'а на некоторое время становится больше рабочих процессов, и соответственно требуется несколько больше памяти, чем при обычной работе. -- Maxim Dounin http://nginx.org/ From sasha181 at rufox.ru Tue Jan 28 03:23:46 2014 From: sasha181 at rufox.ru (=?KOI8-R?Q?=E1=CC=C5=CB=D3=C1=CE=C4=D2_=EB=D5=CE=C9=DE?=) Date: Tue, 28 Jan 2014 07:23:46 +0400 Subject: =?UTF-8?B?UmU6INCf0L4g0LrQsNC60L7QuS3RgtC+INC/0YDQuNGH0LjQvdC1IG5naW54INC0?= =?UTF-8?B?0LDRkdGCINC30LDQtNC10YDQttC60YMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: <4724358.RgZrbWYdTE@note> References: <52E0E595.3020708@rufox.ru> <4724358.RgZrbWYdTE@note> Message-ID: <52E722C2.8070106@rufox.ru> 26.01.2014 9:55, Vadim A. Misbakh-Soloviov пишет: >> Подскажите пожалуйста, в каких направлениях искать причину проблемы. > На сколько могу судить я, не будучи разработчиком NginX, никакой проблемы > здесь нет. Если тестировать ТОЛЬКО выполнение PHP-скриптов с проксированием и > без, то логически очевидно, что дополнительный слой типа проксирования будет > вносить лишь дополнительный задержки. Задача NginX обычно состоит слегка в > другом. > // Вчера в IRC-канале NginX в RusNet пробегала ссылка[1]. Мне не нравится ни > стиль написания автора, ни называние NginX "нгинксом", но саму суть он (как > раз для вашего случая) изложил верно. > > [1] http://slonik-v-domene.livejournal.com/142305.html > Так ведь на шаблоне vps битрикса нет таких накладных расходов на проксирование. Да и просто как бы логически 20-40 милисекунд накладных расходов на проксирование к бэкенду это как-то много. Разве нет? From nginx-forum at nginx.us Tue Jan 28 07:32:07 2014 From: nginx-forum at nginx.us (mnsold) Date: Tue, 28 Jan 2014 02:32:07 -0500 Subject: =?UTF-8?B?0J3QtdCy0LXRgNC90L7QtSDQv9C10YDQtdC90LDQv9GA0LDQstC70LXQvdC40LUg?= =?UTF-8?B?0L3QsCDRgdGC0YDQsNC90LjRhtC1?= Message-ID: Подскажите как организовать проксирование. nginx version: nginx/1.5.8 На бэкэенде стоит JBoss-4.2.3.GA. При открытии страницы на фронтенде http://wolf/SASWebReportStudio сразу же перебрасывает на бэкенд http://alys:8180/SASWebReportStudio/defaultHandler.jsp. Заголовки: $ curl -I http://wolf/SASWebReportStudio/ HTTP/1.1 302 Moved Temporarily Server: nginx/1.5.8 Date: Tue, 28 Jan 2014 05:53:41 GMT Content-Length: 0 Connection: keep-alive X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0 Location: http://alys:8180/SASWebReportStudio/defaultHandler.jsp Конифиг ниже, только без директории proxy_redirect. Добавил в конфиг строчку (других изменений в location не делал): proxy_redirect http://alys:8180/ http://$http_host/; С таким конфигом получаю ошибку В браузере ошибка отображается как: Неверное перенаправление на странице Firefox определил, что сервер перенаправляет запрос на этот адрес таким образом, что он никогда не завершится. access.log пишет около 20 раз подряд: 192.168.42.16 - - [28/Jan/2014:09:18:49 +0400] "GET /SASWebReportStudio/defaultHandler.jsp HTTP/1.1" 302 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" "-" Сам конфиг: --------------------------------------- location ^~ /SASWebReportStudio { return 301 /SASWebReportStudio/; } location ^~ /SASWebReportStudio/ { proxy_pass http://alys:8180; proxy_redirect http://alys:8180/ http://$http_host/; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } --------------------------------------- Заголовки (с директорией в конфиге proxy_redirect) $ curl -I http://analitica.iac.uts/SASWebReportStudio/ HTTP/1.1 302 Moved Temporarily Server: nginx/1.5.8 Date: Tue, 28 Jan 2014 07:25:55 GMT Content-Length: 0 Connection: keep-alive X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0 Location: http://analitica.iac.uts/SASWebReportStudio/defaultHandler.jsp Подскажите, что нужно править в location, куда копать дальше. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246899,246899#msg-246899 From mdounin at mdounin.ru Tue Jan 28 11:08:50 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 28 Jan 2014 15:08:50 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: References: Message-ID: <20140128110850.GW1835@mdounin.ru> Hello! On Tue, Jan 28, 2014 at 02:32:07AM -0500, mnsold wrote: > Подскажите как организовать проксирование. > nginx version: nginx/1.5.8 > На бэкэенде стоит JBoss-4.2.3.GA. > > При открытии страницы на фронтенде http://wolf/SASWebReportStudio сразу же > перебрасывает на бэкенд > http://alys:8180/SASWebReportStudio/defaultHandler.jsp. > > Заголовки: > $ curl -I http://wolf/SASWebReportStudio/ > HTTP/1.1 302 Moved Temporarily > Server: nginx/1.5.8 > Date: Tue, 28 Jan 2014 05:53:41 GMT > Content-Length: 0 > Connection: keep-alive > X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA > date=200807181417)/JBossWeb-2.0 > Location: http://alys:8180/SASWebReportStudio/defaultHandler.jsp > Конифиг ниже, только без директории proxy_redirect. > > > Добавил в конфиг строчку (других изменений в location не делал): > proxy_redirect http://alys:8180/ http://$http_host/; Должно быть достаточно proxy_redirect http://alys:8180/ /; или proxy_redirect default; или вообще ничего не указывать. Эффект должен быть тот же. > С таким конфигом получаю ошибку > В браузере ошибка отображается как: > Неверное перенаправление на странице > Firefox определил, что сервер перенаправляет запрос на этот адрес таким > образом, что он никогда не завершится. > > access.log пишет около 20 раз подряд: > 192.168.42.16 - - [28/Jan/2014:09:18:49 +0400] "GET > /SASWebReportStudio/defaultHandler.jsp HTTP/1.1" 302 0 "-" "Mozilla/5.0 > (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" "-" Проблема в том, что на запрос к "/SASWebReportStudio/defaultHandler.jsp" ваш бекенд тоже возвращает перенаправление. Надо смотреть, почему он это делает. -- Maxim Dounin http://nginx.org/ From picklockster at gmail.com Tue Jan 28 12:37:49 2014 From: picklockster at gmail.com (Oleg Kashtanov) Date: Tue, 28 Jan 2014 16:37:49 +0400 Subject: =?UTF-8?B?0JjRgdC60LvRjtGH0LXQvdC40LUg0LfQsNC/0LjRgdC10Lkg0LjQtyBhY2Nlc3Mu?= =?UTF-8?B?bG9n?= Message-ID: Всем привет! Не подскажите, можно ли исключать запись в access.log строк, содержащих определенную подстроку? Например, не логировать запрос с определенным юзер-агентом? -- С уважением, Олег -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jan 28 12:48:26 2014 From: nginx-forum at nginx.us (Dimka) Date: Tue, 28 Jan 2014 07:48:26 -0500 Subject: =?UTF-8?B?0JzQvtC20L3QviDQu9C4INC00L7QsdCw0LLQuNGC0Ywg0LfQsNCz0L7Qu9C+0LI=?= =?UTF-8?B?0L7QuiDRgSBTU0wg0LjQvdGE0L7RgNC80LDRhtC40LXQuT8=?= Message-ID: <3134f6235dea4f2c2751acb0bbdbd8d4.NginxMailingListRussian@forum.nginx.org> Всем привет! Такая задача, можно ли как-то передать бекенд серверу (apache) информацию о SSL соединении? Хотябы такую SSL_PROTOCOL - The SSL protocol version (SSLv3, TLSv1, TLSv1.1, TLSv1.2) SSL_CIPHER - The cipher specification name SSL_CIPHER_USEKEYSIZE - Number of cipher bits (actually used) Конфиг такой: location / { proxy_pass http://127.0.0.1:80; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarfed-For $proxy_add_x_forwarded_for; # Вот сюдабы ещё добавить доп. инфы о соединении... } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246913,246913#msg-246913 From postmaster at softsearch.ru Tue Jan 28 13:10:53 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 28 Jan 2014 17:10:53 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQtNC+0LHQsNCy0LjRgtGMINC30LDQs9C+0Ls=?= =?UTF-8?B?0L7QstC+0Log0YEgU1NMINC40L3RhNC+0YDQvNCw0YbQuNC10Lk/?= In-Reply-To: <3134f6235dea4f2c2751acb0bbdbd8d4.NginxMailingListRussian@forum.nginx.org> References: <3134f6235dea4f2c2751acb0bbdbd8d4.NginxMailingListRussian@forum.nginx.org> Message-ID: <483655550.20140128171053@softsearch.ru> Здравствуйте, Dimka. > Такая задача, можно ли как-то передать бекенд серверу (apache) информацию о > SSL соединении? > Хотябы такую > SSL_PROTOCOL - The SSL protocol version (SSLv3, TLSv1, TLSv1.1, TLSv1.2) > SSL_CIPHER - The cipher specification name > SSL_CIPHER_USEKEYSIZE - Number of cipher bits (actually used) http://nginx.org/ru/docs/http/ngx_http_ssl_module.html#variables -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Tue Jan 28 13:13:09 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 28 Jan 2014 17:13:09 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQutC70Y7Rh9C10L3QuNC1INC30LDQv9C40YHQtdC5INC40LcgYWNj?= =?UTF-8?B?ZXNzLmxvZw==?= In-Reply-To: References: Message-ID: <765100475.20140128171309@softsearch.ru> Здравствуйте, Oleg. Вы писали 28 января 2014 г., 16:37:49: > Всем привет! > Не подскажите, можно ли исключать запись в access.log строк, > содержащих определенную подстроку? Например, не логировать запрос с > определенным юзер-агентом? if ($http_user_agent ~ MSIE) { access_log off; } http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if http://nginx.org/ru/docs/http/ngx_http_log_module.html#access_log -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Tue Jan 28 13:22:43 2014 From: nginx-forum at nginx.us (mnsold) Date: Tue, 28 Jan 2014 08:22:43 -0500 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <20140128110850.GW1835@mdounin.ru> References: <20140128110850.GW1835@mdounin.ru> Message-ID: <4ae192b8b08db3eabf15158c4617e845.NginxMailingListRussian@forum.nginx.org> Если пишу так: proxy_redirect http://alys:8180/ /; или proxy_redirect default; то перебрасывает на http://alys:8180/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& SASLogon у меня прописан следом за SASWebReportStudio ----------------- location ^~ /SASLogon { return 301 /SASLogon/; } location ^~ /SASLogon/ { proxy_pass http://alys:8180; proxy_redirect http://alys:8180/ http://$http_host/; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } ----------------- причем если зайти на http://analitica.iac.uts/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& то ссылку открывает нормально, никуда не перебрасывает, могу ввести логин/пароль как только ввожу логин/пароль иавторизуюсь, меня бросает на http://alys.lan.iac.spb.ru:8180/SASWebReportStudio/logonFromPortalWRS.do?saspfs_sessionid=...и дальше параметры > Проблема в том, что на запрос к > "/SASWebReportStudio/defaultHandler.jsp" ваш бекенд тоже > возвращает перенаправление. Надо смотреть, почему он это делает. Не подскажите, можно ли как-то подсмотреть. Исходных кодов конечно же нет, софт комерческий, не сами разрабатываем, но доступ к операционке есть. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246899,246916#msg-246916 From nginx-forum at nginx.us Tue Jan 28 13:31:04 2014 From: nginx-forum at nginx.us (Dimka) Date: Tue, 28 Jan 2014 08:31:04 -0500 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQtNC+0LHQsNCy0LjRgtGMINC30LDQs9C+0Ls=?= =?UTF-8?B?0L7QstC+0Log0YEgU1NMINC40L3RhNC+0YDQvNCw0YbQuNC10Lk/?= In-Reply-To: <483655550.20140128171053@softsearch.ru> References: <483655550.20140128171053@softsearch.ru> Message-ID: Спасибо! Просмотрел все выражения, а в модуле не догодался :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246913,246917#msg-246917 From mdounin at mdounin.ru Tue Jan 28 13:44:02 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 28 Jan 2014 17:44:02 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <4ae192b8b08db3eabf15158c4617e845.NginxMailingListRussian@forum.nginx.org> References: <20140128110850.GW1835@mdounin.ru> <4ae192b8b08db3eabf15158c4617e845.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140128134402.GZ1835@mdounin.ru> Hello! On Tue, Jan 28, 2014 at 08:22:43AM -0500, mnsold wrote: > Если пишу так: > proxy_redirect http://alys:8180/ /; > или > proxy_redirect default; > то перебрасывает на > http://alys:8180/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& Что позволяет предположить, что server_name и/или server_name_in_redirect стоит неправильно. И это вам скорее всего ещё аукнится в других местах. [...] > причем если зайти на > http://analitica.iac.uts/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& > то ссылку открывает нормально, никуда не перебрасывает, могу ввести > логин/пароль > как только ввожу логин/пароль иавторизуюсь, меня бросает на > http://alys.lan.iac.spb.ru:8180/SASWebReportStudio/logonFromPortalWRS.do?saspfs_sessionid=...и > дальше параметры Судя по всему, проблемы ваши - связаны как раз с разнообразием используемых имён. > > Проблема в том, что на запрос к > > "/SASWebReportStudio/defaultHandler.jsp" ваш бекенд тоже > > возвращает перенаправление. Надо смотреть, почему он это делает. > Не подскажите, можно ли как-то подсмотреть. > Исходных кодов конечно же нет, софт комерческий, не сами разрабатываем, но > доступ к операционке есть. Я бы рекомендовал начать с простого - зафиксировать имя, по которому вы хотите обращаться к серверу. -- Maxim Dounin http://nginx.org/ From chipitsine at gmail.com Tue Jan 28 15:05:42 2014 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 28 Jan 2014 21:05:42 +0600 Subject: =?UTF-8?B?UmU6INCf0L4g0LrQsNC60L7QuS3RgtC+INC/0YDQuNGH0LjQvdC1IG5naW54INC0?= =?UTF-8?B?0LDRkdGCINC30LDQtNC10YDQttC60YMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: <52E722C2.8070106@rufox.ru> References: <52E0E595.3020708@rufox.ru> <4724358.RgZrbWYdTE@note> <52E722C2.8070106@rufox.ru> Message-ID: 2 секунды - таймаут ресолвера 200 миллисекунд - таймаут алгортима Nagle 20-40 миллисекунд непонятно откуда берутся, надо профилировать вторник, 28 января 2014 г. пользователь Александр Кунич написал: > 26.01.2014 9:55, Vadim A. Misbakh-Soloviov пишет: > >> Подскажите пожалуйста, в каких направлениях искать причину проблемы. >>> >> На сколько могу судить я, не будучи разработчиком NginX, никакой проблемы >> здесь нет. Если тестировать ТОЛЬКО выполнение PHP-скриптов с >> проксированием и >> без, то логически очевидно, что дополнительный слой типа проксирования >> будет >> вносить лишь дополнительный задержки. Задача NginX обычно состоит слегка в >> другом. >> // Вчера в IRC-канале NginX в RusNet пробегала ссылка[1]. Мне не нравится >> ни >> стиль написания автора, ни называние NginX "нгинксом", но саму суть он >> (как >> раз для вашего случая) изложил верно. >> >> [1] http://slonik-v-domene.livejournal.com/142305.html >> >> Так ведь на шаблоне vps битрикса нет таких накладных расходов на > проксирование. Да и просто как бы логически 20-40 милисекунд накладных > расходов на проксирование к бэкенду это как-то много. Разве нет? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jan 28 15:23:26 2014 From: nginx-forum at nginx.us (cilrill) Date: Tue, 28 Jan 2014 10:23:26 -0500 Subject: =?UTF-8?B?0L7RgiBuZ2lueCA1MDQg0L7RgtC00LDRjtGJ0LXQs9C+INGB0YLQsNGC0LjQutGD?= =?UTF-8?B?INGBINGE0LDQudC70L7QstC+0Lkg0YHQuNGB0YLQtdC80Ys=?= Message-ID: Добрый день. Есть nginx отдающий статику с файловой системы на виртуальном хосте debian 6 x64, nginx/1.4.4 из репозитория nginx Периодически у посетителей сайта сидящих за nat (порядка 50 человек), возникает проблема с загрузкой картинок c этого сайта. Согласно дебаг тулзам chromium запросы картинок висят в состоянии waiting (иногда по 20 секунд), потом все рывком догружается. Возможно у других посетителей сайта тоже есть проблемы, но они мне не могут пожаловаться ) При этом другие сайты открываются нормально (даже в момент когда загрузка картинок висит в состоянии ожидания) Роутер не перегружен (проц загружен на 20 процентов) пинги бегают стабильно в момент проблем. В один момент поймал ситуацию когда ожидание ответа 5 картинок от сервера составило 20 секунд (4 из них получили 304) и пятая - 504. Вот тут у меня закралась мысль о собственном непонимании ситуации. Как nginx отдающий статику может вернуть 504? При этом в логах на тему 504 ошибки - ничего нет. Что может служить проблемой при отдаче статики, чтобы заставить nginx вернуть 504 и не записать об этом сообщение в лог? Картинок - порядка 80к (7gb) большая часть - 50-100кб Среднестатическое колво посетителей на сайте - 100-120 cat /etc/nginx/nginx.conf user www-data; worker_processes 4; error_log /var/log/nginx/error.log notice; pid /var/run/nginx.pid; worker_rlimit_nofile 20000; events { worker_connections 2048; } http { log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent $gzip_ratio ' '"$http_referer" "$http_user_agent" "$request_time" "$connection_requests"'; include /etc/nginx/mime.types; default_type application/octet-stream; # server_names_hash_bucket_size 64; # access_log /var/log/nginx/access.log; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 5; tcp_nodelay on; client_max_body_size 50m; gzip on; gzip_proxied any; gzip_min_length 1100; gzip_http_version 1.0; gzip_buffers 4 8k; gzip_comp_level 5; gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } конфиг vhost который отдает картинки server { listen 80; server_name img.manni.ru img2.manni.ru img3.manni.ru; access_log /var/log/nginx/img.am.access.log main buffer=32k; error_log /var/log/nginx/img.am.error.log warn; location ~* \.(jpg|jpeg|gif|png)$ { root /home/virtwww/w_manni_a4fce797/http/; open_file_cache max=1024 inactive=30s; open_file_cache_valid 60s; open_file_cache_min_uses 2; open_file_cache_errors on; add_header Pragma "public"; add_header Cache-Control "max-age=2592000, public, must-revalidate, proxy-revalidate"; } location ~* \.(css|zip|tgz|gz|rar|bz2|xls|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|docx|xlsx|js)$ { root /home/virtwww/w_manni_a4fce797/http/; add_header Cache-Control "public, max-age=2592000"; } location ~ /\.ht { deny all; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246922,246922#msg-246922 From vbart at nginx.com Tue Jan 28 17:05:23 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 28 Jan 2014 21:05:23 +0400 Subject: =?UTF-8?B?UmU6INCf0L4g0LrQsNC60L7QuS3RgtC+INC/0YDQuNGH0LjQvdC1IG5naW54INC0?= =?UTF-8?B?0LDRkdGCINC30LDQtNC10YDQttC60YMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: <52E0E595.3020708@rufox.ru> References: <52E0E595.3020708@rufox.ru> Message-ID: <3898918.DLEoz0BJ5B@vbart-laptop> On Thursday 23 January 2014 13:49:09 Александр Кунич wrote: > система debian 7 (контейнер openvz) > хост машина на базе proxmox ve > стоит ispmanager > Заметил такую особенность, если обращаться к apache напрямую по порту > 8080 php скрипты отрабатывают на 20-40 милисекунд быстрее > это нормальные накладные расходы для tcp проксирования или всё же с этим > можно что-то сделать? > > Вот основные параметры из конфига nginx > [..] > > В apache keepalive тоже включён. Пробовал и с выключенным. Эффект тот же. Из приведенного конфига не видно, что keepalive между nginx и apache включен. -- Валентин Бартенев From nginx-forum at nginx.us Tue Jan 28 17:41:22 2014 From: nginx-forum at nginx.us (mnsold) Date: Tue, 28 Jan 2014 12:41:22 -0500 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <20140128134402.GZ1835@mdounin.ru> References: <20140128134402.GZ1835@mdounin.ru> Message-ID: <12d490cdda80a8f17e1af00902522c62.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Tue, Jan 28, 2014 at 08:22:43AM -0500, mnsold wrote: > > > Если пишу так: > > proxy_redirect http://alys:8180/ /; > > или > > proxy_redirect default; > > то перебрасывает на > > http://alys:8180/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& > > Что позволяет предположить, что server_name и/или > server_name_in_redirect стоит неправильно. И это вам скорее всего > ещё аукнится в других местах. тогда даю само описание блока server server_name_in_redirect нигде не прописано ---------------------------------------------- server { listen *:80; listen *:443 ssl; server_name analitica.iac.uts wolf; #SSL ssl_certificate .../server.crt; ssl_certificate_key .../server.key; ssl_protocols SSLv2 SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; ssl_verify_client off; proxy_ssl_protocols SSLv3; include conf.d/asaswebreportstudio.loc; #есть еще несколько include, но с ними все в порядке error_log /var/log/nginx/error.log debug; access_log /var/log/nginx/access.log main; ---------------------------------------------- > > причем если зайти на > > > http://analitica.iac.uts/SASLogon/index.jsp?_sasapp=Web+Report+Studio+ > 4.3& > > то ссылку открывает нормально, никуда не перебрасывает, могу ввести > > логин/пароль > > как только ввожу логин/пароль иавторизуюсь, меня бросает на > > > http://alys.lan.iac.spb.ru:8180/SASWebReportStudio/logonFromPortalWRS. > do?saspfs_sessionid=...и > > дальше параметры > > Судя по всему, проблемы ваши - связаны как раз с разнообразием > используемых имён. Имен действительно несколько. где alys - локальное имя срвера, стаким же именем зарегистрировано в dns wolf - локальное имя сервера на котором установлен nginx, стаким же именем зарегистрировано в dns в локальной сети analitica.iac.uts - этот тот же wolf, но с другим именем и другим сетевым интерфейсом, именно к нему имеют доступ все внешние пользователи, это же имя зарегистрировано в dns в "межкорпоративной" сети будет еще одно, для сети интернет, но пока нужно настроить это (или потренироваться на уже 2х написанных именах сервера) в тестах, использовал только analitica.iac.uts (wolf использовал только один раз, это же имя могли видеть в первом посте) > > > Проблема в том, что на запрос к > > > "/SASWebReportStudio/defaultHandler.jsp" ваш бекенд тоже > > > возвращает перенаправление. Надо смотреть, почему он это делает. > > Не подскажите, можно ли как-то подсмотреть. > > Исходных кодов конечно же нет, софт комерческий, не сами > разрабатываем, но > > доступ к операционке есть. > > Я бы рекомендовал начать с простого - зафиксировать имя, по > которому вы хотите обращаться к серверу. тут не совсем понимаю, предполагается использовать 2 имени из 2х разных сетей возможно плохо то, что сети разные, для каждой сети свой IP и свое имя, из одной сети никак не попасть в другую например 10.10.1.11 analitica.iac.uts 217.17.1.11 analitica.ru порекомендуете что нибудь? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246899,246925#msg-246925 From nginx-forum at nginx.us Tue Jan 28 22:05:59 2014 From: nginx-forum at nginx.us (spbsprut) Date: Tue, 28 Jan 2014 17:05:59 -0500 Subject: Nginx + Apache Message-ID: Не получается запустить nginx на продуктиве. Главное сначала тестировал на другом серваке - все идеально сразу заработало, а на продуктиве при попытке restart пишет Restarting nginx: nginx: [emerg] unknown directive "<------>proxy_pass" in /etc/nginx/sites-enabled/*сайт*:9 nginx: configuration file /etc/nginx/nginx.conf test failed Гугление не помогло. Вот конфиги nginx default: # Неизвестные соединения останавливаются nginx-ом c 403 error server { listen *:80 default_server; return 403; } *сайт*: server { listen *:80; server_name *сайт*; location / { <------>proxy_pass http://127.0.0.1:81/; } location ~* \.(jpg|jpeg|gif|png|ico|css|js|txt|doc|docx|xls|xlsx|ppt|pptx)$ { <------>root /var/www/vhosts/*сайт*/www; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246929,246929#msg-246929 From vbart at nginx.com Tue Jan 28 22:34:15 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 29 Jan 2014 02:34:15 +0400 Subject: =?UTF-8?B?UmU6INC+0YIgbmdpbnggNTA0INC+0YLQtNCw0Y7RidC10LPQviDRgdGC0LDRgtC4?= =?UTF-8?B?0LrRgyDRgSDRhNCw0LnQu9C+0LLQvtC5INGB0LjRgdGC0LXQvNGL?= In-Reply-To: References: Message-ID: <10620696.bJIMQ8dTrx@vbart-laptop> On Tuesday 28 January 2014 10:23:26 cilrill wrote: > Добрый день. > > Есть nginx отдающий статику с файловой системы на виртуальном хосте > > debian 6 x64, nginx/1.4.4 из репозитория nginx > > > Периодически у посетителей сайта сидящих за nat (порядка 50 человек), > возникает проблема с загрузкой картинок c этого сайта. Согласно дебаг тулзам > chromium запросы картинок висят в состоянии waiting (иногда по 20 секунд), > потом все рывком догружается. Возможно у других посетителей сайта тоже есть > проблемы, но они мне не могут пожаловаться ) > > При этом другие сайты открываются нормально (даже в момент когда загрузка > картинок висит в состоянии ожидания) > Роутер не перегружен (проц загружен на 20 процентов) пинги бегают стабильно > в момент проблем. > > В один момент поймал ситуацию когда ожидание ответа 5 картинок от сервера > составило 20 секунд (4 из них получили 304) и пятая - 504. > > Вот тут у меня закралась мысль о собственном непонимании ситуации. > Как nginx отдающий статику может вернуть 504? > При этом в логах на тему 504 ошибки - ничего нет. > > Что может служить проблемой при отдаче статики, чтобы заставить nginx > вернуть 504 и не записать об этом сообщение в лог? [..] nginx без сторонних модулей не умеет отдавать 504 на статику, этого просто сам алгоритм не предусматривает, если только код ответа не был переопределен с помощью директивы error_page. Поэтому вариантов остается не так много, можете сами оценить вероятность того или иного: 1. Ваш запрос обрабатывает и отдает на него 504 на самом деле не nginx, или не тот nginx о котором вы думаете, или не с тем конфигом, что был продемонстрирован; 2. Эффект от использования сторонних модулей и патчей; 3. Ваш экземпляр nginx'а, от долгой и упорной работы, осознал себя как личность и перепрограммировался. -- Валентин Бартенев From dreik.da at gmail.com Tue Jan 28 22:35:50 2014 From: dreik.da at gmail.com (Sergey 'dreik' Kolesnik) Date: Wed, 29 Jan 2014 02:35:50 +0400 Subject: Nginx + Apache In-Reply-To: References: Message-ID: ASCII-арт уберите из конфига. WBR, Sergey 'dreik' Kolesnik Skype: dreik.lc Cell: +7 (921) 943-5237 2014-01-29 spbsprut > Не получается запустить nginx на продуктиве. > > Главное сначала тестировал на другом серваке - все идеально сразу > заработало, а на продуктиве при попытке restart пишет > > Restarting nginx: nginx: [emerg] unknown directive "<------>proxy_pass" in > /etc/nginx/sites-enabled/*сайт*:9 > nginx: configuration file /etc/nginx/nginx.conf test failed > > Гугление не помогло. > > Вот конфиги nginx > > default: > > # Неизвестные соединения останавливаются nginx-ом c 403 error > server { > listen *:80 default_server; > return 403; > } > > *сайт*: > > server { > listen *:80; > server_name *сайт*; > location / { > <------>proxy_pass http://127.0.0.1:81/; > } > location ~* > \.(jpg|jpeg|gif|png|ico|css|js|txt|doc|docx|xls|xlsx|ppt|pptx)$ { > <------>root /var/www/vhosts/*сайт*/www; > } > } > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246929,246929#msg-246929 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Tue Jan 28 22:37:03 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 29 Jan 2014 02:37:03 +0400 Subject: Nginx + Apache In-Reply-To: References: Message-ID: <12763765.xzWFNQ6kvp@vbart-laptop> On Tuesday 28 January 2014 17:05:59 spbsprut wrote: > Не получается запустить nginx на продуктиве. > > Главное сначала тестировал на другом серваке - все идеально сразу > заработало, а на продуктиве при попытке restart пишет > > Restarting nginx: nginx: [emerg] unknown directive "<------>proxy_pass" in > /etc/nginx/sites-enabled/*сайт*:9 > nginx: configuration file /etc/nginx/nginx.conf test failed > > Гугление не помогло. > > Вот конфиги nginx > > default: > > # Неизвестные соединения останавливаются nginx-ом c 403 error > server { > listen *:80 default_server; > return 403; > } > > *сайт*: > > server { > listen *:80; > server_name *сайт*; > location / { > <------>proxy_pass http://127.0.0.1:81/; [..] Так всё верно пишет, есть директива proxy_pass, а директивы <------>proxy_pass не существует. -- Валентин Бартенев From mdounin at mdounin.ru Wed Jan 29 01:30:20 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 29 Jan 2014 05:30:20 +0400 Subject: =?UTF-8?B?UmU6INCf0L4g0LrQsNC60L7QuS3RgtC+INC/0YDQuNGH0LjQvdC1IG5naW54INC0?= =?UTF-8?B?0LDRkdGCINC30LDQtNC10YDQttC60YMg0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: <3898918.DLEoz0BJ5B@vbart-laptop> References: <52E0E595.3020708@rufox.ru> <3898918.DLEoz0BJ5B@vbart-laptop> Message-ID: <20140129013019.GD1835@mdounin.ru> Hello! On Tue, Jan 28, 2014 at 09:05:23PM +0400, Валентин Бартенев wrote: > On Thursday 23 January 2014 13:49:09 Александр Кунич wrote: > > система debian 7 (контейнер openvz) > > хост машина на базе proxmox ve > > стоит ispmanager > > Заметил такую особенность, если обращаться к apache напрямую по порту > > 8080 php скрипты отрабатывают на 20-40 милисекунд быстрее > > это нормальные накладные расходы для tcp проксирования или всё же с этим > > можно что-то сделать? > > > > Вот основные параметры из конфига nginx > > > [..] > > > > В apache keepalive тоже включён. Пробовал и с выключенным. Эффект тот же. > > Из приведенного конфига не видно, что keepalive между nginx и apache включен. 20-40 миллисекунд оверхеда - это так или иначе много. Локальный keepalive в нормальных условиях может дать от силы 1 миллисекунду выигрыша. Если речь идёт о больших задержках - то отсутствие keepalive'а не может быть причиной проблем (хотя его включение в некоторых случаях может помочь проблемы скрыть). -- Maxim Dounin http://nginx.org/ From tetsio.nainn at gmail.com Wed Jan 29 01:46:16 2014 From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=) Date: Wed, 29 Jan 2014 11:46:16 +1000 Subject: =?UTF-8?B?UmU6INC+0YIgbmdpbnggNTA0INC+0YLQtNCw0Y7RidC10LPQviDRgdGC0LDRgtC4?= =?UTF-8?B?0LrRgyDRgSDRhNCw0LnQu9C+0LLQvtC5INGB0LjRgdGC0LXQvNGL?= In-Reply-To: <10620696.bJIMQ8dTrx@vbart-laptop> References: <10620696.bJIMQ8dTrx@vbart-laptop> Message-ID: А точно ваши пользователи сидят только через NAT? Точно ли нету какого-нибудь intercept proxy? 29 января 2014 г., 8:34 пользователь Валентин Бартенев написал: > On Tuesday 28 January 2014 10:23:26 cilrill wrote: > > Добрый день. > > > > Есть nginx отдающий статику с файловой системы на виртуальном хосте > > > > debian 6 x64, nginx/1.4.4 из репозитория nginx > > > > > > Периодически у посетителей сайта сидящих за nat (порядка 50 человек), > > возникает проблема с загрузкой картинок c этого сайта. Согласно дебаг > тулзам > > chromium запросы картинок висят в состоянии waiting (иногда по 20 > секунд), > > потом все рывком догружается. Возможно у других посетителей сайта тоже > есть > > проблемы, но они мне не могут пожаловаться ) > > > > При этом другие сайты открываются нормально (даже в момент когда загрузка > > картинок висит в состоянии ожидания) > > Роутер не перегружен (проц загружен на 20 процентов) пинги бегают > стабильно > > в момент проблем. > > > > В один момент поймал ситуацию когда ожидание ответа 5 картинок от сервера > > составило 20 секунд (4 из них получили 304) и пятая - 504. > > > > Вот тут у меня закралась мысль о собственном непонимании ситуации. > > Как nginx отдающий статику может вернуть 504? > > При этом в логах на тему 504 ошибки - ничего нет. > > > > Что может служить проблемой при отдаче статики, чтобы заставить nginx > > вернуть 504 и не записать об этом сообщение в лог? > [..] > > nginx без сторонних модулей не умеет отдавать 504 на статику, > этого просто сам алгоритм не предусматривает, если только > код ответа не был переопределен с помощью директивы error_page. > > Поэтому вариантов остается не так много, можете сами оценить > вероятность того или иного: > > 1. Ваш запрос обрабатывает и отдает на него 504 на самом > деле не nginx, или не тот nginx о котором вы думаете, > или не с тем конфигом, что был продемонстрирован; > > 2. Эффект от использования сторонних модулей и патчей; > > 3. Ваш экземпляр nginx'а, от долгой и упорной работы, > осознал себя как личность и перепрограммировался. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С ув. М.А. Мохначевский Отдел системного администрирования ООО "Компания "СахаИнтернет НТ" к.т. (4112)219711 доб. 927 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Jan 29 02:02:34 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 29 Jan 2014 06:02:34 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <12d490cdda80a8f17e1af00902522c62.NginxMailingListRussian@forum.nginx.org> References: <20140128134402.GZ1835@mdounin.ru> <12d490cdda80a8f17e1af00902522c62.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140129020234.GE1835@mdounin.ru> Hello! On Tue, Jan 28, 2014 at 12:41:22PM -0500, mnsold wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > On Tue, Jan 28, 2014 at 08:22:43AM -0500, mnsold wrote: > > > > > Если пишу так: > > > proxy_redirect http://alys:8180/ /; > > > или > > > proxy_redirect default; > > > то перебрасывает на > > > http://alys:8180/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& > > > > Что позволяет предположить, что server_name и/или > > server_name_in_redirect стоит неправильно. И это вам скорее всего > > ещё аукнится в других местах. > > тогда даю само описание блока server > server_name_in_redirect нигде не прописано Либо вы неправильно пишите, куда возвращается redirect, либо что-то недосмотрели в конфиге. Совет: сделайте nginx.conf, содержащий минимум необходимых настроек и никаких include'ов (кроме разве что стандартных mime.types) и попробуйте воспроизвести проблему с ним. Художественное выпиливание конфигов из кусочков - верный способ запутаться. Ну и debug log тоже неплохо помогает смотреть, что же на самом деле происходит. Я просто оставлю эту ссылку здесь: http://wiki.nginx.org/Debugging [...] > > > причем если зайти на > > > > > http://analitica.iac.uts/SASLogon/index.jsp?_sasapp=Web+Report+Studio+ > > 4.3& > > > то ссылку открывает нормально, никуда не перебрасывает, могу ввести > > > логин/пароль > > > как только ввожу логин/пароль иавторизуюсь, меня бросает на > > > > > http://alys.lan.iac.spb.ru:8180/SASWebReportStudio/logonFromPortalWRS. > > do?saspfs_sessionid=...и > > > дальше параметры > > > > Судя по всему, проблемы ваши - связаны как раз с разнообразием > > используемых имён. > > Имен действительно несколько. > где > alys - локальное имя срвера, стаким же именем зарегистрировано в dns > wolf - локальное имя сервера на котором установлен nginx, стаким же именем > зарегистрировано в dns в локальной сети > analitica.iac.uts - этот тот же wolf, но с другим именем и другим сетевым > интерфейсом, именно к нему имеют доступ все внешние пользователи, это же имя > зарегистрировано в dns в "межкорпоративной" сети > будет еще одно, для сети интернет, но пока нужно настроить это (или > потренироваться на уже 2х написанных именах сервера) > > в тестах, использовал только analitica.iac.uts (wolf использовал только один > раз, это же имя могли видеть в первом посте) Ну и как минимум ещё в цитате выше встречается "alys.lan.iac.spb.ru", что вероятно является полным именем от "alys" и по каким-то причинам считается бекендом правильным именем. > > > > Проблема в том, что на запрос к > > > > "/SASWebReportStudio/defaultHandler.jsp" ваш бекенд тоже > > > > возвращает перенаправление. Надо смотреть, почему он это делает. > > > Не подскажите, можно ли как-то подсмотреть. > > > Исходных кодов конечно же нет, софт комерческий, не сами > > разрабатываем, но > > > доступ к операционке есть. > > > > Я бы рекомендовал начать с простого - зафиксировать имя, по > > которому вы хотите обращаться к серверу. > > тут не совсем понимаю, предполагается использовать 2 имени из 2х разных > сетей > возможно плохо то, что сети разные, для каждой сети свой IP и свое имя, из > одной сети никак не попасть в другую > например > 10.10.1.11 analitica.iac.uts > 217.17.1.11 analitica.ru > > порекомендуете что нибудь? Всё тоже - зафиксируйте одно имя, и добейтесь работы по этому одному имени. Когда заработает - можно начинать думать о дополнительных именах, но не надо пытаться это делать раньше. Сейчас у вас в схеме 6 разных доменных имён, и вы в них, судя по всему, уже успели запутаться. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Jan 29 07:28:08 2014 From: nginx-forum at nginx.us (mnsold) Date: Wed, 29 Jan 2014 02:28:08 -0500 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <20140129020234.GE1835@mdounin.ru> References: <20140129020234.GE1835@mdounin.ru> Message-ID: <73536c65df087969fdfa8ad6cbf68599.NginxMailingListRussian@forum.nginx.org> > Либо вы неправильно пишите, куда возвращается redirect, либо > что-то недосмотрели в конфиге. > > Совет: сделайте nginx.conf, содержащий минимум необходимых > настроек и никаких include'ов (кроме разве что стандартных > mime.types) и попробуйте воспроизвести проблему с ним. > Художественное выпиливание конфигов из кусочков - верный способ > запутаться. > > Ну и debug log тоже неплохо помогает смотреть, что же на самом > деле происходит. Я просто оставлю эту ссылку здесь: > > http://wiki.nginx.org/Debugging дебаг я с удовольствеим посмотрел бы, директива error_log выставлена в debug но ничего не пишет у меня: error_log /var/log/nginx/error.log debug; не вижу опции --with-debug /usr/sbin/nginx -V nginx version: nginx/1.5.8 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-cc-opt='-g -O2 -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt=-Wl,--as-needed --with-ipv6 устанавливал из репозитория отсюда deb http://nginx.org/packages/mainline/debian/ squeeze nginx deb-src http://nginx.org/packages/mainline/debian/ squeeze nginx Сделать nginx.conf, содержащий минимум необходимых настроек можно, правда у меня и так их минимум, работаю всего в 2х файлах, так скорее даже проще, они оба маленькие, без художеств, все лишее потер: 1й файл - содержит блок server и нужный include (приводил выше) 2й файл - тот самый include с location'ами которые нужно спроксировать с сервера alys. Никакие другие файлы на этот сервер не ссылаются. (приводил выше) оба этих файлов лежат в conf.d. ну и есть конечно nginx.conf, но я его не трогал. > Ну и как минимум ещё в цитате выше встречается > "alys.lan.iac.spb.ru", что вероятно является полным именем от > "alys" и по каким-то причинам считается бекендом правильным именем. ... > Всё тоже - зафиксируйте одно имя, и добейтесь работы по этому > одному имени. Когда заработает - можно начинать думать о > дополнительных именах, но не надо пытаться это делать раньше. > > Сейчас у вас в схеме 6 разных доменных имён, и вы в них, судя по > всему, уже успели запутаться. Должен извинится, тут скорее я ввел вас в заблуждение т.к. мои посты с небольшой редакцией, а именно тру не нужные комменты, и вместо полных названии хостов указал короткие, других изменений не вношу. С именами на самом деле все просто, их всего 2: бэкенд - alys.lan.iac.spb.ru, только одно имя сервера, именно это, сервер коротких имен не возвращает (имя alys которое я указывал выше, фактически это alys.lan.iac.spb.ru). фронтенд - analitica.iac.uts, тоже только одно имя Но путаница и скороткими и длинными именами все же имела место, а именно в этих директивах конфига я указал короткие имена: proxy_pass http://alys:8180; proxy_redirect http://alys:8180/ /; Сейчас исправил все имена на полные имена, убрал лишние комменты для лучшей читаемости, вот к чему это привело: - ранее я писал, что если пишу так как Вы и советовали, то : proxy_redirect http://alys:8180/ /; или proxy_redirect default; то перебрасывает на http://alys:8180/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& - теперь поведение стало единообразным, как в первом посте, т.е. если указать proxy_redirect http://alys.lan.iac.spb.ru:8180/ /; или proxy_redirect default; то получаю: "Неверное перенаправление на странице" ну и в access логе много раз подряд ""GET /SASWebReportStudio/defaultHandler.jsp HTTP/1.1" 302 0 "-" " после всех изменений в location, конфиг в них стал такой ------------------------------------------------------- location ^~ /SASWebReportStudio { return 301 /SASWebReportStudio/; } location ^~ /SASWebReportStudio/ { proxy_pass http://alys.lan.iac.spb.ru:8180; proxy_redirect default; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ^~ /SASLogon { return 301 /SASLogon/; } location ^~ /SASLogon/ { proxy_pass http://alys.lan.iac.spb.ru:8180; proxy_redirect default; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } ------------------------------------------------------- Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246899,246948#msg-246948 From vbart at nginx.com Wed Jan 29 08:13:22 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 29 Jan 2014 12:13:22 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <73536c65df087969fdfa8ad6cbf68599.NginxMailingListRussian@forum.nginx.org> References: <20140129020234.GE1835@mdounin.ru> <73536c65df087969fdfa8ad6cbf68599.NginxMailingListRussian@forum.nginx.org> Message-ID: <2740962.mRhujV2x77@vbart-laptop> On Wednesday 29 January 2014 02:28:08 mnsold wrote: > > Либо вы неправильно пишите, куда возвращается redirect, либо > > что-то недосмотрели в конфиге. > > > > Совет: сделайте nginx.conf, содержащий минимум необходимых > > настроек и никаких include'ов (кроме разве что стандартных > > mime.types) и попробуйте воспроизвести проблему с ним. > > Художественное выпиливание конфигов из кусочков - верный способ > > запутаться. > > > > Ну и debug log тоже неплохо помогает смотреть, что же на самом > > деле происходит. Я просто оставлю эту ссылку здесь: > > > > http://wiki.nginx.org/Debugging > > дебаг я с удовольствеим посмотрел бы, директива error_log выставлена в debug > но ничего не пишет у меня: > error_log /var/log/nginx/error.log debug; > > не вижу опции --with-debug [...] Пакет с этой опцией называется nginx-debug. -- Валентин Бартенев From nginx-ru at sadok.spb.ru Wed Jan 29 08:25:49 2014 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 29 Jan 2014 12:25:49 +0400 Subject: Nginx + Apache In-Reply-To: References: Message-ID: <855465606.20140129122549@sadok.spb.ru> Здравствуйте, spbsprut. Вы писали 29 января 2014 г., 2:05:59: > Не получается запустить nginx на продуктиве. mcedit - зло -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From mdounin at mdounin.ru Wed Jan 29 09:13:59 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 29 Jan 2014 13:13:59 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <73536c65df087969fdfa8ad6cbf68599.NginxMailingListRussian@forum.nginx.org> References: <20140129020234.GE1835@mdounin.ru> <73536c65df087969fdfa8ad6cbf68599.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140129091359.GF1835@mdounin.ru> Hello! On Wed, Jan 29, 2014 at 02:28:08AM -0500, mnsold wrote: > > Либо вы неправильно пишите, куда возвращается redirect, либо > > что-то недосмотрели в конфиге. > > > > Совет: сделайте nginx.conf, содержащий минимум необходимых > > настроек и никаких include'ов (кроме разве что стандартных > > mime.types) и попробуйте воспроизвести проблему с ним. > > Художественное выпиливание конфигов из кусочков - верный способ > > запутаться. > > > > Ну и debug log тоже неплохо помогает смотреть, что же на самом > > деле происходит. Я просто оставлю эту ссылку здесь: > > > > http://wiki.nginx.org/Debugging > > дебаг я с удовольствеим посмотрел бы, директива error_log выставлена в debug > но ничего не пишет у меня: > error_log /var/log/nginx/error.log debug; > > не вижу опции --with-debug [...] > устанавливал из репозитория отсюда > deb http://nginx.org/packages/mainline/debian/ squeeze nginx > deb-src http://nginx.org/packages/mainline/debian/ squeeze nginx Там же есть пакет nginx-debug, в котором тот же nginx, но собранный с --with-debug. [...] > Сейчас исправил все имена на полные имена, убрал лишние комменты для лучшей > читаемости, вот к чему это привело: > - ранее я писал, что если пишу так как Вы и советовали, то : > proxy_redirect http://alys:8180/ /; > или > proxy_redirect default; > то перебрасывает на > http://alys:8180/SASLogon/index.jsp?_sasapp=Web+Report+Studio+4.3& > > - теперь поведение стало единообразным, как в первом посте, т.е. если > указать > proxy_redirect http://alys.lan.iac.spb.ru:8180/ /; > или > proxy_redirect default; > то получаю: "Неверное перенаправление на странице" ну и в access логе много > раз подряд ""GET /SASWebReportStudio/defaultHandler.jsp HTTP/1.1" 302 0 "-" > " Ок, с одной проблемой разобрались. Теперь осталось понять, почему бекенду не нравится запрос к "/SASWebReportStudio/defaultHandler.jsp" и почему он возвращает перенаправление снова и снова. Обычно это бывает, когда бекенду не нравится имя, по которому к нему обратились. Возможные направления решения: 1) Убрать из конфига proxy_set_header Host, т.е. обращаться к бекенду по его собственному имени, alys.lan.iac.spb.ru:8180. Обычно так всё работает, но может привести к некорректным ссылкам в возвращаемых бекендом страницах. 2) Убедить бекенд, что он должен отзываться на то имя, к которому обращаются пользователи. Обычно это делается где-то в настройках бекенда. -- Maxim Dounin http://nginx.org/ From postmaster at softsearch.ru Wed Jan 29 09:39:11 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 29 Jan 2014 13:39:11 +0400 Subject: =?UTF-8?B?UmVbMl06INC+0YIgbmdpbnggNTA0INC+0YLQtNCw0Y7RidC10LPQviDRgdGC0LA=?= =?UTF-8?B?0YLQuNC60YMg0YEg0YTQsNC50LvQvtCy0L7QuSDRgdC40YHRgtC10LzRiw==?= In-Reply-To: <10620696.bJIMQ8dTrx@vbart-laptop> References: <10620696.bJIMQ8dTrx@vbart-laptop> Message-ID: <114567203.20140129133911@softsearch.ru> Здравствуйте, Валентин. > Поэтому вариантов остается не так много, можете сами оценить > вероятность того или иного: > 1. Ваш запрос обрабатывает и отдает на него 504 на самом > деле не nginx, или не тот nginx о котором вы думаете, > или не с тем конфигом, что был продемонстрирован; > 2. Эффект от использования сторонних модулей и патчей; > 3. Ваш экземпляр nginx'а, от долгой и упорной работы, > осознал себя как личность и перепрограммировался. Ещё четвёртый вариант возможен: есть http-прокся между nginx-ом и браузером. -- С уважением, Михаил mailto:postmaster at softsearch.ru From onokonem at gmail.com Wed Jan 29 09:46:05 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 29 Jan 2014 13:46:05 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQvtGCIG5naW54IDUwNCDQvtGC0LTQsNGO0YnQtdCz0L4g0YE=?= =?UTF-8?B?0YLQsNGC0LjQutGDINGBINGE0LDQudC70L7QstC+0Lkg0YHQuNGB0YLQtdC8?= =?UTF-8?B?0Ys=?= In-Reply-To: <114567203.20140129133911@softsearch.ru> References: <10620696.bJIMQ8dTrx@vbart-laptop> <114567203.20140129133911@softsearch.ru> Message-ID: 2014-01-29 Михаил Монашёв : > Ещё четвёртый вариант возможен: есть http-прокся между nginx-ом и > браузером. это 1. From postmaster at softsearch.ru Wed Jan 29 10:03:48 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 29 Jan 2014 14:03:48 +0400 Subject: =?UTF-8?B?UmVbNF06INC+0YIgbmdpbnggNTA0INC+0YLQtNCw0Y7RidC10LPQviDRgdGC0LA=?= =?UTF-8?B?0YLQuNC60YMg0YEg0YTQsNC50LvQvtCy0L7QuSDRgdC40YHRgtC10LzRiw==?= In-Reply-To: References: <10620696.bJIMQ8dTrx@vbart-laptop> <114567203.20140129133911@softsearch.ru> Message-ID: <306153370.20140129140348@softsearch.ru> Здравствуйте, Daniel. >> Ещё четвёртый вариант возможен: есть http-прокся между nginx-ом и >> браузером. > это 1. Да, ты прав. Невнимательно 1 пункт прочитал. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Wed Jan 29 10:07:45 2014 From: nginx-forum at nginx.us (cilrill) Date: Wed, 29 Jan 2014 05:07:45 -0500 Subject: =?UTF-8?B?UmU6INC+0YIgbmdpbnggNTA0INC+0YLQtNCw0Y7RidC10LPQviDRgdGC0LDRgtC4?= =?UTF-8?B?0LrRgyDRgSDRhNCw0LnQu9C+0LLQvtC5INGB0LjRgdGC0LXQvNGL?= In-Reply-To: References: Message-ID: <901d7cb744938bf84b9bc52179325601.NginxMailingListRussian@forum.nginx.org> похоже там какие то проблемы с upload. поставил client_header_timeout 10 и полетели 408 в лог. осталось только найти кто отдал 504. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246922,246960#msg-246960 From nginx-forum at nginx.us Wed Jan 29 10:40:21 2014 From: nginx-forum at nginx.us (mnsold) Date: Wed, 29 Jan 2014 05:40:21 -0500 Subject: =?UTF-8?B?UmU6INCd0LXQstC10YDQvdC+0LUg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L0=?= =?UTF-8?B?0LjQtSDQvdCwINGB0YLRgNCw0L3QuNGG0LU=?= In-Reply-To: <20140129091359.GF1835@mdounin.ru> References: <20140129091359.GF1835@mdounin.ru> Message-ID: > 1) Убрать из конфига proxy_set_header Host, т.е. обращаться к > бекенду по его собственному имени, alys.lan.iac.spb.ru:8180. > Обычно так всё работает, но может привести к некорректным ссылкам > в возвращаемых бекендом страницах. закоментировал строчки в обоих location # proxy_set_header Host $http_host; в итоге: - могу залогинится в /SASLogon/ - затем перебрасывает на страницу http://analitica.iac.uts/SASWebReportStudio/logonFromPortalWRS.do?saspfs_sessionid= .. далее параметры при этом: 1. на странице /SASWebReportStudio/defaultHandler.jsp ошибок не возникает, и перебрасывает как раз на /SASWebReportStudio/logonFromPortalWRS.do?... 2. все ссылки на этой странице ссылаются на alys.lan.iac.spb.ru:8180/SASWebReportStudio/... 3. javascript, если срабатывает, то перебрасывает тоже alys.lan.iac.spb.ru:8180/SASWebReportStudio/... 4. javascript, который открывает всплывающие окна, не отрабатывает (всплывающие окна разрешены) > 2) Убедить бекенд, что он должен отзываться на то имя, к которому > обращаются пользователи. Обычно это делается где-то в настройках > бекенда. Ух, там с этим возможно будут проблемы. Вся настройка из юзерфрендли интерфейса, по результатам которой генерируется куча xml файлов, создаются множетсво исполняемых файлов. Даже когда перезапускаешь jboss, он все приложения заного их распаковывает, что то делает и деплоит обратно, на 16ядрах с 24гб на все уходит минут 7. Но попытаюсь выяснить этот вопрос у поддержки, про nginx они сказали, что у них нет такой информации и ничем помось не могут. Вам огромное спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246899,246961#msg-246961 From nginx-forum at nginx.us Wed Jan 29 10:56:43 2014 From: nginx-forum at nginx.us (Ve0) Date: Wed, 29 Jan 2014 05:56:43 -0500 Subject: =?UTF-8?B?TmdpbnggKyBQSFA1LUZQTSA9PiDQvdC1INGA0LDQsdC+0YLQsNC10YIgamF2YXNj?= =?UTF-8?B?cmlwdC4uLiAoKCg=?= Message-ID: nginx version: nginx/1.4.4 PHP 5.3.10-1ubuntu3.9 (fpm-fcgi) (built: Dec 12 2013 04:31:25) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH Конфиг: root at http:/var/log# cat /etc/nginx/nginx.conf user www-data; worker_processes 2; timer_resolution 100ms; worker_rlimit_nofile 8192; worker_priority -5; pid /var/run/nginx.pid; events { worker_connections 2048; # default: 768 use epoll; } http { reset_timedout_connection on; sendfile off; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; server_tokens off; map_hash_bucket_size 64; server_names_hash_bucket_size 64; server_name_in_redirect 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; fastcgi_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=one:10m; gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 64 8k; gzip_http_version 1.1; gzip_min_length 1100; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } Конфиг сайта: server { listen 80; server_name stat.***.ru; access_log /var/log/nginx/***.ru/stat_access.log; error_log /var/log/nginx/***.ru/stat_error.log; if ($request_method !~ ^(GET|HEAD|POST)$ ) { return 444; } root /var/www/***/stat/; index index.php index.html; location = /favicon.ico { try_files /favicon.ico =204; } location / { location ~* ^.+\.(?:css|js|jpg|png|gif|jpeg|swf)$ { valid_referers none blocked *.dazab.ru; if ($invalid_referer) { return 444; } expires max; tcp_nodelay off; open_file_cache max=500 inactive=120s; open_file_cache_valid 45s; open_file_cache_min_uses 2; open_file_cache_errors off; break; } location ~* (?:DESIGN|(?:gpl|README|LICENSE)[^.]*|LEGALNOTICE)(?:\.txt)*$ { return 404; } location ~* \.(?:bat|html?|git|ini|sh|svn[^.]*|txt|tpl|xml)$ { return 404; } try_files $uri /index.php; } location ~* ^/(?:index|piwik)\.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; } location ~* ^.+\.php$ { return 404; } location = /robots.txt { return 200 "User-agent: *\nDisallow: /\n"; } } Это стандартный конфиг Piwik взятый с сайта nginx.org. Но не хочет нормально работать ява скрипт. Не работает статистика, ошибок нигде нету... На сайте все что связано с аяксом не работает. Куда рыть, подскажите плиз! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246962,246962#msg-246962 From zmey1992 at ya.ru Wed Jan 29 12:24:38 2014 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 29 Jan 2014 16:24:38 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICsgUEhQNS1GUE0gPT4g0L3QtSDRgNCw0LHQvtGC0LDQtdGCIGph?= =?UTF-8?B?dmFzY3JpcHQuLi4gKCgo?= In-Reply-To: References: Message-ID: <236771390998278@web25m.yandex.ru> Во-первых, откройте инструменты разработчика в браузере и посмотрите, какой код ответа приходит для JS файлов. 29.01.2014, 14:57, "Ve0" : > nginx version: nginx/1.4.4 > PHP 5.3.10-1ubuntu3.9 (fpm-fcgi) (built: Dec 12 2013 04:31:25) > Copyright (c) 1997-2009 The PHP Group > Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies >     with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH > > Конфиг: > root at http:/var/log# cat /etc/nginx/nginx.conf > user www-data; > worker_processes 2; > timer_resolution 100ms; > worker_rlimit_nofile 8192; > worker_priority -5; > > pid /var/run/nginx.pid; > > events { >         worker_connections 2048; # default: 768 >         use epoll; > } > > http { >         reset_timedout_connection on; >         sendfile off; >         tcp_nopush on; >         tcp_nodelay on; >         keepalive_timeout 65; >         types_hash_max_size 2048; >         server_tokens off; > >         map_hash_bucket_size 64; >         server_names_hash_bucket_size 64; >         server_name_in_redirect 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; > >         fastcgi_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=one:10m; > >         gzip on; >         gzip_disable "msie6"; > >         gzip_vary on; >         gzip_proxied any; >         gzip_comp_level 6; >         gzip_buffers 64 8k; >         gzip_http_version 1.1; >         gzip_min_length 1100; >         gzip_types text/plain text/css application/json application/x-javascript > text/xml application/xml application/xml+rss text/javascript; > >         include /etc/nginx/conf.d/*.conf; >         include /etc/nginx/sites-enabled/*; > } > > Конфиг сайта: > > server { >     listen      80; >     server_name stat.***.ru; > >     access_log  /var/log/nginx/***.ru/stat_access.log; >     error_log   /var/log/nginx/***.ru/stat_error.log; > >     if ($request_method !~ ^(GET|HEAD|POST)$ ) { >         return 444; >     } > >     root /var/www/***/stat/; >     index index.php index.html; > >     location = /favicon.ico { >         try_files /favicon.ico =204; >     } > >     location / { > >         location ~* ^.+\.(?:css|js|jpg|png|gif|jpeg|swf)$ { >             valid_referers none blocked *.dazab.ru; >             if ($invalid_referer)  { >                 return 444; >             } >             expires max; >             tcp_nodelay off; >             open_file_cache max=500 inactive=120s; >             open_file_cache_valid 45s; >             open_file_cache_min_uses 2; >             open_file_cache_errors off; >             break; >         } > >         location ~* > (?:DESIGN|(?:gpl|README|LICENSE)[^.]*|LEGALNOTICE)(?:\.txt)*$ { >             return 404; >         } > >         location ~* \.(?:bat|html?|git|ini|sh|svn[^.]*|txt|tpl|xml)$ { >             return 404; >         } > >         try_files $uri /index.php; >     } > >     location ~* ^/(?:index|piwik)\.php$ { >         fastcgi_pass 127.0.0.1:9000; >         fastcgi_index index.php; >         include fastcgi_params; >     } > >     location ~* ^.+\.php$ { >         return 404; >     } > >     location = /robots.txt { >         return 200 "User-agent: *\nDisallow: /\n"; >     } > } > > Это стандартный конфиг Piwik взятый с сайта nginx.org. Но не хочет нормально > работать ява скрипт. Не работает статистика, ошибок нигде нету... На сайте > все что связано с аяксом не работает. Куда рыть, подскажите плиз! > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246962,246962#msg-246962 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Thu Jan 30 08:57:25 2014 From: nginx-forum at nginx.us (spbsprut) Date: Thu, 30 Jan 2014 03:57:25 -0500 Subject: Nginx + Apache In-Reply-To: References: Message-ID: <224d43cd08e1b6e78f59038e431b7069.NginxMailingListRussian@forum.nginx.org> Да, тупанул)) Я почему то был уверен что это табуляция))) Копировал через шифт)) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246929,246984#msg-246984 From nginx-forum at nginx.us Thu Jan 30 08:57:36 2014 From: nginx-forum at nginx.us (spbsprut) Date: Thu, 30 Jan 2014 03:57:36 -0500 Subject: Nginx + Apache In-Reply-To: <224d43cd08e1b6e78f59038e431b7069.NginxMailingListRussian@forum.nginx.org> References: <224d43cd08e1b6e78f59038e431b7069.NginxMailingListRussian@forum.nginx.org> Message-ID: <85d29b3126b0cc157039c3656464fb3f.NginxMailingListRussian@forum.nginx.org> Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246929,246985#msg-246985 From nginx-forum at nginx.us Thu Jan 30 10:06:46 2014 From: nginx-forum at nginx.us (gerasape) Date: Thu, 30 Jan 2014 05:06:46 -0500 Subject: =?UTF-8?B?UmU6IE5naW54INC4INC00LXRgdGP0YLQutC4INGC0YvRgdGP0Ycg0LLQuNGA0YI=?= =?UTF-8?B?0YPQsNC70YzQvdGL0YUg0YXQvtGB0YLQvtCy?= In-Reply-To: <20140127173711.GJ1835@mdounin.ru> References: <20140127173711.GJ1835@mdounin.ru> Message-ID: <3a08a025e93159f08da1fcc8e200980e.NginxMailingListRussian@forum.nginx.org> Работаю с 12 000 виртуалхостов. Сразу столкнулся с лимитом на открытие файлов ulimit open files по умолчанию у меня было 1024. Рашил проблему редактированием файла /etc/default/nginx При 12000 reload происходит чуть медленнее чем обычно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246776,246989#msg-246989 From nginx-forum at nginx.us Thu Jan 30 10:18:30 2014 From: nginx-forum at nginx.us (gerasape) Date: Thu, 30 Jan 2014 05:18:30 -0500 Subject: =?UTF-8?B?Tmdpbngg0LrQsNC6INCw0L3QvtC90LjQvNC90YvQuSBodHRwINC4IGh0dHBzINC/?= =?UTF-8?B?0YDQvtC60YHQuCDRgdC10YDQstC10YA=?= Message-ID: <77c3b185e8b3df2232f15d63f9865299.NginxMailingListRussian@forum.nginx.org> Стоит задача поднять на nginx анонимный прокси сервер server { listen 10.0.0.1:8080; location / { proxy_pass http://192.1.1.1:8085; proxy_set_header Host $host; proxy_redirect off; } } Http трафик проксируется, а весь https трафик нет. Подскажите, пожалуйсто, как проксировать и http и https трафик? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246991,246991#msg-246991 From mdounin at mdounin.ru Thu Jan 30 11:48:47 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 30 Jan 2014 15:48:47 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC60LDQuiDQsNC90L7QvdC40LzQvdGL0LkgaHR0cCDQuCBodHRw?= =?UTF-8?B?cyDQv9GA0L7QutGB0Lgg0YHQtdGA0LLQtdGA?= In-Reply-To: <77c3b185e8b3df2232f15d63f9865299.NginxMailingListRussian@forum.nginx.org> References: <77c3b185e8b3df2232f15d63f9865299.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140130114847.GU1835@mdounin.ru> Hello! On Thu, Jan 30, 2014 at 05:18:30AM -0500, gerasape wrote: > Стоит задача поднять на nginx анонимный прокси сервер > > server { > listen 10.0.0.1:8080; > > location / { > > proxy_pass http://192.1.1.1:8085; > proxy_set_header Host $host; > proxy_redirect off; > } > } > > Http трафик проксируется, а весь https трафик нет. > > Подскажите, пожалуйсто, как проксировать и http и https трафик? Никак. Как уже говорилось и писалось неоднократно, nginx - не forward proxy, не надо его пытаться так использовать. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Thu Jan 30 12:06:52 2014 From: nginx-forum at nginx.us (gerasape) Date: Thu, 30 Jan 2014 07:06:52 -0500 Subject: =?UTF-8?B?UmU6IE5naW54INC60LDQuiDQsNC90L7QvdC40LzQvdGL0LkgaHR0cCDQuCBodHRw?= =?UTF-8?B?cyDQv9GA0L7QutGB0Lgg0YHQtdGA0LLQtdGA?= In-Reply-To: <20140130114847.GU1835@mdounin.ru> References: <20140130114847.GU1835@mdounin.ru> Message-ID: Это не вариант. Он отлично кэшит и выполняет огромное количество реврайтов. Нужно его научить пропускать https трафик... Почему на апач его проксируют, а вот на другой хост никак (? Нужен совет, а не пессимистический взгляд ( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246991,246998#msg-246998 From alex.barut at gmail.com Fri Jan 31 06:14:15 2014 From: alex.barut at gmail.com (Alex Belyansky) Date: Fri, 31 Jan 2014 10:14:15 +0400 Subject: =?UTF-8?B?UmU6IE5naW54INC60LDQuiDQsNC90L7QvdC40LzQvdGL0LkgaHR0cCDQuCBodHRw?= =?UTF-8?B?cyDQv9GA0L7QutGB0Lgg0YHQtdGA0LLQtdGA?= In-Reply-To: References: <20140130114847.GU1835@mdounin.ru> Message-ID: <52EB3F37.3090808@gmail.com> Добрый день! On 30.01.2014 16:06, gerasape wrote: > Это не вариант. Он отлично кэшит и выполняет огромное количество реврайтов. > Нужно его научить пропускать https трафик... > > Почему на апач его проксируют, а вот на другой хост никак (? > > Нужен совет, а не пессимистический взгляд ( > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246991,246998#msg-246998 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Обратите внимание лучше на squid. From nginx-forum at nginx.us Fri Jan 31 06:57:46 2014 From: nginx-forum at nginx.us (Ve0) Date: Fri, 31 Jan 2014 01:57:46 -0500 Subject: =?UTF-8?B?UmU6IE5naW54ICsgUEhQNS1GUE0gPT4g0L3QtSDRgNCw0LHQvtGC0LDQtdGCIGph?= =?UTF-8?B?dmFzY3JpcHQuLi4gKCgo?= In-Reply-To: <236771390998278@web25m.yandex.ru> References: <236771390998278@web25m.yandex.ru> Message-ID: <183e9540453a08325ed042099d958f65.NginxMailingListRussian@forum.nginx.org> Да самое то прикольное что все открывается вроде. Вот пример: bubuntu.spb.ru (один из моих сайтов) ваще весело отображается... но при этом сурсы странички норм, все показывает, ошибок нет. Васильев "Zmey!" Олег Wrote: ------------------------------------------------------- > Во-первых, откройте инструменты разработчика в браузере и посмотрите, > какой код ответа приходит для JS файлов. > > > _______________________________________________ > 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,246962,247045#msg-247045 From funvit at gmail.com Fri Jan 31 07:40:05 2014 From: funvit at gmail.com (=?KOI8-R?B?98nUwczJyiDmLg==?=) Date: Fri, 31 Jan 2014 11:40:05 +0400 Subject: =?UTF-8?B?UmU6IE5naW54ICsgUEhQNS1GUE0gPT4g0L3QtSDRgNCw0LHQvtGC0LDQtdGCIGph?= =?UTF-8?B?dmFzY3JpcHQuLi4gKCgo?= In-Reply-To: <183e9540453a08325ed042099d958f65.NginxMailingListRussian@forum.nginx.org> References: <236771390998278@web25m.yandex.ru> <183e9540453a08325ed042099d958f65.NginxMailingListRussian@forum.nginx.org> Message-ID: ошибка в jquery.js на строке 45 - уберите "*/". nginx тут не причем. 31 января 2014 г., 10:57 пользователь Ve0 написал: > Да самое то прикольное что все открывается вроде. Вот пример: > bubuntu.spb.ru > (один из моих сайтов) ваще весело отображается... но при этом сурсы > странички норм, все показывает, ошибок нет. > > Васильев "Zmey!" Олег Wrote: > ------------------------------------------------------- > > Во-первых, откройте инструменты разработчика в браузере и посмотрите, > > какой код ответа приходит для JS файлов. > > > > > > _______________________________________________ > > 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,246962,247045#msg-247045 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Фунтиков Виталий Викторович веб-разработчик -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Jan 31 11:33:03 2014 From: nginx-forum at nginx.us (DenisM) Date: Fri, 31 Jan 2014 06:33:03 -0500 Subject: =?UTF-8?B?0KPQsdGA0LDRgtGMINC00YPQsdC70LjRgNC+0LLQsNC90L3Ri9C1INC30LDQs9C+?= =?UTF-8?B?0LvQvtCy0LrQuA==?= Message-ID: <4ec66ff5a3a2fa574b1ceb1fb83720cf.NginxMailingListRussian@forum.nginx.org> Добрый день! Nginx в режиме fastcgi к php. Php благодаря разработчикам дублирует куки PHPSESSID и т.п. Можно ли заставить nginx удалять лишние копии кук из заголовка, или только править сырцы? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,247050,247050#msg-247050 From postmaster at softsearch.ru Fri Jan 31 16:01:21 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 31 Jan 2014 20:01:21 +0400 Subject: =?UTF-8?B?UmU6INCj0LHRgNCw0YLRjCDQtNGD0LHQu9C40YDQvtCy0LDQvdC90YvQtSDQt9Cw?= =?UTF-8?B?0LPQvtC70L7QstC60Lg=?= In-Reply-To: <4ec66ff5a3a2fa574b1ceb1fb83720cf.NginxMailingListRussian@forum.nginx.org> References: <4ec66ff5a3a2fa574b1ceb1fb83720cf.NginxMailingListRussian@forum.nginx.org> Message-ID: <86909331.20140131200121@softsearch.ru> Здравствуйте, DenisM. > Добрый день! > Nginx в режиме fastcgi к php. Php благодаря разработчикам дублирует куки > PHPSESSID и т.п. > Можно ли заставить nginx удалять лишние копии кук из заголовка, или только > править сырцы? Можно попробовать сначала их удалить, а потом заново выставить. Возможно удаление удалит дубли. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Jan 31 16:31:24 2014 From: nginx-forum at nginx.us (siroco) Date: Fri, 31 Jan 2014 11:31:24 -0500 Subject: Custom 400 error for client-certificate-authenticated site Message-ID: Всем привет! Возникла у меня проблема один в один как у товарища, вопрос которого в форуме так и остался без ответа - http://forum.nginx.org/read.php?11,240460,240460 Возникло предположение, что дело в том, что я пытаюсь показать ошибку на httpS, а ведь доступ к нему невозможен без клиентского сертификата. Однако и перенаправление error_page на внешний http тоже не помогает. "error_page 400 http://site.domain/my_errors/ssl_error.html;" Есть какие-то варианты подсунуть свой error_page для oшибки 400? ("400 Bad Request No required SSL certificate was sent") nginx version: nginx/1.2.6 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,247057,247057#msg-247057 From mdounin at mdounin.ru Fri Jan 31 17:15:42 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 31 Jan 2014 21:15:42 +0400 Subject: Custom 400 error for client-certificate-authenticated site In-Reply-To: References: Message-ID: <20140131171542.GX1835@mdounin.ru> Hello! On Fri, Jan 31, 2014 at 11:31:24AM -0500, siroco wrote: > Всем привет! > > Возникла у меня проблема один в один как у товарища, вопрос которого в > форуме так и остался без ответа - > http://forum.nginx.org/read.php?11,240460,240460 Это всё от того, что жизнь - в рассылке, а не в форуме. :) > Возникло предположение, что дело в том, что я пытаюсь показать ошибку на > httpS, а ведь доступ к нему невозможен без клиентского сертификата. Однако и > перенаправление error_page на внешний http тоже не помогает. > > "error_page 400 http://site.domain/my_errors/ssl_error.html;" > > Есть какие-то варианты подсунуть свой error_page для oшибки 400? > ("400 Bad Request > No required SSL certificate was sent") Ошибка "No required SSL certificate was sent" имеет специальный код 496, и именно его надо перехватывать директивой error_page. Подробности тут: http://nginx.org/ru/docs/http/ngx_http_ssl_module.html#errors -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Fri Jan 31 20:46:05 2014 From: nginx-forum at nginx.us (Ve0) Date: Fri, 31 Jan 2014 15:46:05 -0500 Subject: =?UTF-8?B?UmU6IE5naW54ICsgUEhQNS1GUE0gPT4g0L3QtSDRgNCw0LHQvtGC0LDQtdGCIGph?= =?UTF-8?B?dmFzY3JpcHQuLi4gKCgo?= In-Reply-To: References: Message-ID: <932b34c1f4191db57550ab4f40e36906.NginxMailingListRussian@forum.nginx.org> как вы это опредили? у меня на всех сайтах проблема((( как ее диагностировать? и грешил на нджинкс потому что апача это хаволо((( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246962,247063#msg-247063 From denis at webmaster.spb.ru Fri Jan 31 22:13:45 2014 From: denis at webmaster.spb.ru (denis) Date: Sat, 01 Feb 2014 02:13:45 +0400 Subject: =?UTF-8?B?cHJveHlfY2FjaGU6INC90LUg0YDQsNCx0L7RgtCw0LXRgiDRgdC+0LfQtNCw0L0=?= =?UTF-8?B?0LjQtSDRhNCw0LnQu9C+0LI=?= Message-ID: <52EC2019.700@webmaster.spb.ru> Трям. Надо срочно закэшировать один битрикс-сайт, заголовки Set-Cookie: PHPSESSID=jp5v1glv71mgr9ibpi5h13b2e1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache мешают кэшировать. Конфиги в http{ #mkdir -p /var/lib/nginx/{cache,proxy} #chown -R www-data /var/lib/nginx/ #chmod 0700 /var/lib/nginx/cache proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=cache:30m max_size=1G; proxy_cache_key "$host$request_uri"; proxy_temp_path /var/lib/nginx/proxy 1 2; proxy_ignore_headers "Expires" "Cache-Control" "Set-Cookie" "Pragma"; proxy_cache_use_stale error timeout invalid_header http_502; proxy_cache_lock on; proxy_cache_methods GET HEAD; proxy_cache_min_uses 3; ... дальше описан сервер, там location / { proxy_pass ...; proxy_cache cache; } Права на /var/lib/nginx выставлены 777 рекурсивно. Каталоги создаются как надо, но они все внутри пустые. From denis at webmaster.spb.ru Fri Jan 31 22:57:03 2014 From: denis at webmaster.spb.ru (denis) Date: Sat, 01 Feb 2014 02:57:03 +0400 Subject: =?UTF-8?B?0LDQvdCw0LvQuNC3INCw0YDQs9GD0LzQtdC90YLQvtCyINCyIGFyZyo=?= Message-ID: <52EC2A3F.9080405@webmaster.spb.ru> Потребовалось сделать редирект на базе одного из ряда аргументов, логично было бы так if ($arg_SID=110) { А заработало так if ($args ~ SID=110) { Что с $arg_SID не так? Вариант с if ($arg_SID~110) { также не заработал. И почему с args заработало вообще. вызов типа ?SID=11&PID=200 From semenukha at gmail.com Fri Jan 31 22:58:31 2014 From: semenukha at gmail.com (Styopa Semenukha) Date: Fri, 31 Jan 2014 17:58:31 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5X2NhY2hlOiDQvdC1INGA0LDQsdC+0YLQsNC10YIg0YHQvtC30LQ=?= =?UTF-8?B?0LDQvdC40LUg0YTQsNC50LvQvtCy?= In-Reply-To: <52EC2019.700@webmaster.spb.ru> References: <52EC2019.700@webmaster.spb.ru> Message-ID: <1466754.RGyYXRXgo0@tornado> Трям. Вам поможет http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers > Права на /var/lib/nginx выставлены 777 рекурсивно. Это очень зря. On Saturday, February 01, 2014 02:13:45 AM denis wrote: > Трям. > > Надо срочно закэшировать один битрикс-сайт, заголовки > Set-Cookie: PHPSESSID=jp5v1glv71mgr9ibpi5h13b2e1; path=/ > Expires: Thu, 19 Nov 1981 08:52:00 GMT > Cache-Control: no-store, no-cache, must-revalidate, post-check=0, > pre-check=0 > Pragma: no-cache > > мешают кэшировать. > > Конфиги > в http{ > #mkdir -p /var/lib/nginx/{cache,proxy} > #chown -R www-data /var/lib/nginx/ > #chmod 0700 /var/lib/nginx/cache > proxy_cache_path /var/lib/nginx/cache levels=1:2 > keys_zone=cache:30m max_size=1G; > proxy_cache_key "$host$request_uri"; > proxy_temp_path /var/lib/nginx/proxy 1 2; > proxy_ignore_headers "Expires" "Cache-Control" "Set-Cookie" "Pragma"; > proxy_cache_use_stale error timeout invalid_header http_502; > proxy_cache_lock on; > proxy_cache_methods GET HEAD; > proxy_cache_min_uses 3; > ... > > дальше описан сервер, там > location / { > proxy_pass ...; > proxy_cache cache; > } > > Права на /var/lib/nginx выставлены 777 рекурсивно. Каталоги создаются > как надо, но они все внутри пустые. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Styopa Semenukha.