From nginx-forum at nginx.us Mon Sep 1 12:54:47 2014 From: nginx-forum at nginx.us (spleenjack) Date: Mon, 01 Sep 2014 08:54:47 -0400 Subject: =?UTF-8?B?0KHQu9C40YjQutC+0Lwg0LLRi9GB0L7QutC40Lkg0YPRgNC+0LLQtdC90Ywg0L4=?= =?UTF-8?B?0YjQuNCx0LrQuCDQsiDQu9C+0LPQtSDQv9GA0Lgg0L3QtdCy0LDQu9C40LQ=?= =?UTF-8?B?0L3QvtC8IGhhbmRzaGFrZSDRgdC+INGB0YLQvtGA0L7QvdGLINC60LvQuNC1?= =?UTF-8?B?0L3RgtCw?= Message-ID: <59b1099a5fdf9693ac98a29abfba1500.NginxMailingListRussian@forum.nginx.org> Пару дней назад в error.log в огромных количествах начали сыпаться вот такие записи (ip клиента заменил): 2014/09/01 12:36:02 [crit] 13175#0: *46423402 SSL_do_handshake() failed (SSL: error:05066066:Diffie-Hellman routines:COMPUTE_KEY:invalid public key error:1408B005:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:DH lib) while SSL handshaking, client: 1.1.1.1, server: 0.0.0.0:443 Подампили трафик. Если я всё правильно понял исходя из собранных пакетов, сервер отправляет клиенту выбранный cipher suite - в нашем случае Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039). И посылает 1024 битный pubkey для DH. Клиент, в ответ на это, присылает свой pubkey, но уже неправильного размера - 2048 бит. Серверу это не нравится и он сбрасывает соединение. Я не настоящий сварщик, но смог раскопать openssl-ный код вот досюда - модуль crypto/dh/dh_check.c, функция DH_check_pub_key: 131 if (BN_cmp(pub_key,q)<=0) 132 *ret|=DH_CHECK_PUBKEY_TOO_SMALL; 135 if (BN_cmp(pub_key,q)>=0) 136 *ret|=DH_CHECK_PUBKEY_TOO_LARGE; Эта функция вызывается из compute_key модуля crypto/dh/dh_key.c. Всё бы хорошо, но nginx в такой ситуации отписывает в error.log о каждом сброшенном соединении с уровнем [crit]. То есть, выставленный уровень фильтрации [error] в nginx.conf не помогает игнорировать такие ошибки и у нас срабатывает мониторинг. Ну ладно, фиг с ним, с мониторингом, но лог начинает сильно пухнуть в размерах. Кажется, что уровень ошибки на самом деле не такой критичный. Иначе, получается, что на сервере с обработкой хендшейка всё хорошо, но если прицельно запулнуть в сервер кривыми пакетами, он может написать в лог много-много гигабайт и сожрать весь диск. Можно понизить уровень этих ошибок до info или вообще debug? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,252989,252989#msg-252989 From nginx-forum at nginx.us Mon Sep 1 15:07:57 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 01 Sep 2014 11:07:57 -0400 Subject: nginx-1.7.3 In-Reply-To: <53C6524A.4020603@nginx.com> References: <53C6524A.4020603@nginx.com> Message-ID: <7eaf4bcfa4aaaf7ead77bd80a1749b45.NginxMailingListRussian@forum.nginx.org> > Пакеты для CentOS 7 доступны. > > http://nginx.org/en/linux_packages.html#mainline После, выхода EPEL репозитория для CentOS 7, наблюдается проблема с обновлением Nginx. http://ftp.tlk-l.net/pub/mirrors/fedora-epel/7/x86_64/repoview/epel-release.html yum update - постоянно пытается обновить установленный с вашего репозитория Nginx 1.7.4, на более старую версию Nginx 1.6.1 из репозитория EPEL. Вот наш nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/ gpgcheck=0 enabled=1 Не подскажите как можно решить эту проблему? Пока что делаем исключения при обновлениях yum --exclude=nginx update Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251548,252994#msg-252994 From gmm at csdoc.com Mon Sep 1 15:36:40 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 01 Sep 2014 18:36:40 +0300 Subject: nginx-1.7.3 In-Reply-To: <7eaf4bcfa4aaaf7ead77bd80a1749b45.NginxMailingListRussian@forum.nginx.org> References: <53C6524A.4020603@nginx.com> <7eaf4bcfa4aaaf7ead77bd80a1749b45.NginxMailingListRussian@forum.nginx.org> Message-ID: <54049288.8080200@csdoc.com> On 01.09.2014 18:07, S.A.N wrote: >> http://nginx.org/en/linux_packages.html#mainline > > После, выхода EPEL репозитория для CentOS 7, наблюдается проблема с > обновлением Nginx. > http://ftp.tlk-l.net/pub/mirrors/fedora-epel/7/x86_64/repoview/epel-release.html > > yum update - постоянно пытается обновить установленный с вашего репозитория > Nginx 1.7.4, на более старую версию Nginx 1.6.1 из репозитория EPEL. Причина в том, что Jamie Nguyen при сборке своего пакета из EPEL прописал в спек "Epoch: 1" из-за чего его пакет считается более новым. см. http://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs > Не подскажите как можно решить эту проблему? > Пока что делаем исключения при обновлениях yum --exclude=nginx update Несколько вариантов: 1. взять исходники из http://nginx.org/packages/mainline/centos/7/SRPMS/ установить там Epoch в более высокое значение и пересобрать пакет. 2. с помощью плагина yum-plugin-priorities настроить приоритеты репозиториев таким образом, чтобы у EPEL был более низкий приоритет. это в любом случае полезно настроить для всех используемых репозиториев 3. попросить мантейреров пакета из nginx.org чтобы они прописали более высокий Epoch чем у пакета из репозитория EPEL, чтобы аналогичные проблемы с перезатиранием nginx не возникали у других пользователей. -- Best regards, Gena From nginx-forum at nginx.us Mon Sep 1 16:47:31 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 01 Sep 2014 12:47:31 -0400 Subject: nginx-1.7.3 In-Reply-To: <54049288.8080200@csdoc.com> References: <54049288.8080200@csdoc.com> Message-ID: > 2. с помощью плагина yum-plugin-priorities настроить приоритеты > репозиториев таким образом, чтобы у EPEL был более низкий приоритет. > это в любом случае полезно настроить для всех используемых > репозиториев Спасибо, так и сделали. > 3. попросить мантейреров пакета из nginx.org чтобы они прописали более > высокий Epoch чем у пакета из репозитория EPEL, чтобы аналогичные > проблемы с перезатиранием nginx не возникали у других пользователей. Да, думаю будет правильным если Nginx из ветке mainline, будет иметь Epoch выше чем у ветки stable. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251548,252996#msg-252996 From annulen at yandex.ru Mon Sep 1 16:51:54 2014 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 01 Sep 2014 20:51:54 +0400 Subject: nginx-1.7.3 In-Reply-To: <54049288.8080200@csdoc.com> References: <53C6524A.4020603@nginx.com> <7eaf4bcfa4aaaf7ead77bd80a1749b45.NginxMailingListRussian@forum.nginx.org> <54049288.8080200@csdoc.com> Message-ID: <4201401409590314@web2m.yandex.ru> 01.09.2014, 19:36, "Gena Makhomed" : > On 01.09.2014 18:07, S.A.N wrote: >>>  http://nginx.org/en/linux_packages.html#mainline >>  После, выхода EPEL репозитория для CentOS 7, наблюдается проблема с >>  обновлением Nginx. >>  http://ftp.tlk-l.net/pub/mirrors/fedora-epel/7/x86_64/repoview/epel-release.html >> >>  yum update - постоянно пытается обновить установленный с вашего репозитория >>  Nginx 1.7.4, на более старую версию Nginx 1.6.1 из репозитория EPEL. > > Причина в том, что Jamie Nguyen при сборке своего пакета из EPEL > прописал в спек "Epoch: 1" из-за чего его пакет считается более новым. > см. http://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs >>  Не подскажите как можно решить эту проблему? >>  Пока что делаем исключения при обновлениях yum --exclude=nginx update > > Несколько вариантов: > > 1. взять исходники из http://nginx.org/packages/mainline/centos/7/SRPMS/ > установить там Epoch в более высокое значение и пересобрать пакет. > > 2. с помощью плагина yum-plugin-priorities настроить приоритеты > репозиториев таким образом, чтобы у EPEL был более низкий приоритет. > это в любом случае полезно настроить для всех используемых репозиториев > > 3. попросить мантейреров пакета из nginx.org чтобы они прописали более > высокий Epoch чем у пакета из репозитория EPEL, чтобы аналогичные > проблемы с перезатиранием nginx не возникали у других пользователей. 4. Добавить в конфиг epel exclude=nginx* -- Regards, Konstantin From gmm at csdoc.com Mon Sep 1 18:20:51 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 01 Sep 2014 21:20:51 +0300 Subject: nginx-1.7.3 In-Reply-To: References: <54049288.8080200@csdoc.com> Message-ID: <5404B903.3070601@csdoc.com> On 01.09.2014 19:47, S.A.N wrote: >> 3. попросить мантейреров пакета из nginx.org чтобы они прописали более >> высокий Epoch чем у пакета из репозитория EPEL, чтобы аналогичные >> проблемы с перезатиранием nginx не возникали у других пользователей. В данном случае - применение Epoch необходимо для того, чтобы сделать все пакеты из repo nginx.org более приоритетными, чем пакеты из EPEL. Потому что у nginx.org-пакетов Epoch: 0, а у EPEL-пакетов "Epoch: 1". > Да, думаю будет правильным если Nginx из ветке mainline, будет иметь Epoch > выше чем у ветки stable. Нет. Epoch не надо применять там, где достаточно будет версии пакета. Если значение Epoch одинаково - rpm тогда смотрит на версию пакета. Делать разный Epoch для nginx mainline и nginx stable нет смысла. -- Best regards, Gena From nginx-forum at nginx.us Mon Sep 1 19:10:31 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 01 Sep 2014 15:10:31 -0400 Subject: nginx-1.7.3 In-Reply-To: <5404B903.3070601@csdoc.com> References: <5404B903.3070601@csdoc.com> Message-ID: > > Да, думаю будет правильным если Nginx из ветке mainline, будет иметь > Epoch > > выше чем у ветки stable. > > Нет. Epoch не надо применять там, где достаточно будет версии пакета. > Если значение Epoch одинаково - rpm тогда смотрит на версию пакета. > Делать разный Epoch для nginx mainline и nginx stable нет смысла. Согласен, я имел виду чтобы stable пакеты не имели выше Epoch чем у mainline пакетов, потому что в этом случаи, mainline версия пакета уже не важна. Я думаю большинство используют репозиторий nginx.org для более оперативного обновления Nginx. Если этого не происходит потому что пакеты от nginx.org имеют меньший Epoch чем у пакетов EPEL, тогда и весь смысл в репозетории nginx.org пропадает. Можно конечно в ручном режиме изменить приоритеты или поставить исключения, но думаю многие это сделают не сразу, а только когда заметят что их Nginx обновился более старой версией из EPEL, так произошло на моем dev сервере ) В общем надо повышать Epoch. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251548,253002#msg-253002 From gmm at csdoc.com Mon Sep 1 19:47:39 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 01 Sep 2014 22:47:39 +0300 Subject: nginx-1.7.3 In-Reply-To: References: <5404B903.3070601@csdoc.com> Message-ID: <5404CD5B.2080204@csdoc.com> On 01.09.2014 22:10, S.A.N wrote: >>> Да, думаю будет правильным если Nginx из ветке mainline, будет иметь >>> Epoch выше чем у ветки stable. >> >> Нет. Epoch не надо применять там, где достаточно будет версии пакета. >> Если значение Epoch одинаково - rpm тогда смотрит на версию пакета. >> Делать разный Epoch для nginx mainline и nginx stable нет смысла. > > Согласен, я имел виду чтобы stable пакеты не имели выше Epoch чем у mainline > пакетов, потому что в этом случаи, mainline версия пакета уже не важна. Сейчас у rpm-пакетов из stable и mainline веток одинаковый Epoch: 0. Проблема не с ветками, проблема с пакетом nginx из репозитория EPEL. > Я думаю большинство используют репозиторий nginx.org для более оперативного > обновления Nginx. На nginx.org находится два разных репозитория: http://nginx.org/en/linux_packages.html#stable http://nginx.org/en/linux_packages.html#mainline Какой репозиторий подключат - такой nginx и будет установлен в систему. Если одновременно подключить оба - будет установлена более новая версия. Поэтому - просто нет смысла делать "если Nginx из ветке mainline, будет иметь Epoch выше чем у ветки stable" - это ничего не изменит. Надо только - чтобы Epoch у пакетов из репозиториев nginx.org был выше чем у пакета nginx из репозитория EPEL и других сторонних репозиториев. Потому что EPEL содержит много полезных пакетов и его очень часто подключают к CentOS - в том числе и вместе с репозиторием от nginx.org -- Best regards, Gena From nginx-forum at nginx.us Mon Sep 1 19:54:35 2014 From: nginx-forum at nginx.us (alexstream) Date: Mon, 01 Sep 2014 15:54:35 -0400 Subject: nginx upstream (minimum download speed) Message-ID: <91041d1238a1eb14d4964cf715f17b9f.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Имеется сервер nginx (1.6.0 - при необходимости можно обновить). Есть настроенный upstream с несколькими серверами-бекендами в нем. С этих серверов бекендов осуществляется передача больших статических файлов через один фронтенд, роль которого выполняет nginx. Время от времени бекенды могут отвечать медленнее или умирать вовсе. Скажите, есть ли возможность средствами nginx настроить переключение на следующий бэкенд в случае, когда скорость передачи данных с текущего бэкенда меньше определенного порогового значения? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253004,253004#msg-253004 From nginx-forum at nginx.us Mon Sep 1 20:09:41 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 01 Sep 2014 16:09:41 -0400 Subject: nginx-1.7.3 In-Reply-To: <5404CD5B.2080204@csdoc.com> References: <5404CD5B.2080204@csdoc.com> Message-ID: <8345f7b7c929e36dd0908b7340f32844.NginxMailingListRussian@forum.nginx.org> > Надо только - чтобы Epoch у пакетов из репозиториев nginx.org был выше > чем у пакета nginx из репозитория EPEL и других сторонних > репозиториев. > > Потому что EPEL содержит много полезных пакетов и его очень часто > подключают к CentOS - в том числе и вместе с репозиторием от nginx.org Согласен. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251548,253005#msg-253005 From mdounin at mdounin.ru Tue Sep 2 11:06:19 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 2 Sep 2014 15:06:19 +0400 Subject: nginx upstream (minimum download speed) In-Reply-To: <91041d1238a1eb14d4964cf715f17b9f.NginxMailingListRussian@forum.nginx.org> References: <91041d1238a1eb14d4964cf715f17b9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140902110619.GF1849@mdounin.ru> Hello! On Mon, Sep 01, 2014 at 03:54:35PM -0400, alexstream wrote: > Здравствуйте! > Имеется сервер nginx (1.6.0 - при необходимости можно обновить). Есть > настроенный upstream с несколькими серверами-бекендами в нем. С этих > серверов бекендов осуществляется передача больших статических файлов через > один фронтенд, роль которого выполняет nginx. Время от времени бекенды могут > отвечать медленнее или умирать вовсе. > Скажите, есть ли возможность средствами nginx настроить переключение на > следующий бэкенд в случае, когда скорость передачи данных с текущего бэкенда > меньше определенного порогового значения? Нет. После того, как началась отправка ответа клиенту - переключение на другой бекенд невозможно. -- Maxim Dounin http://nginx.org/ From andrei.seredenko at gmail.com Tue Sep 2 14:20:00 2014 From: andrei.seredenko at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCh0LXRgNC10LTQtdC90LrQvg==?=) Date: Tue, 2 Sep 2014 17:20:00 +0300 Subject: Transparent file substitution Message-ID: Доброго дня всем! Ребят, подскажите - имеется такой вопрос.. INTRO: Mono. Есть приложение, на которое nginx проксирует запросы. И есть один не-совсем-адекватный клиент, который у этого приложения запрашивает wsdl прежде, чем воспользоваться апишкой.. перед каждым запросом... и делает это с частотой ~200 запросов в минуту (на каждый полезный запрос - вот этот вот сорный запрос wsdl'ки, который впустую напрягает приложение) Возможности повлиять на клиента нет. Время подставлять костыли... WORKAROUND: Раз возможности повлиять на клиента нет, было принято решение обмануть его (нормальная практика, что =) ): вместо постоянной генерации wsdl'ки на стороне приложения - отдавать nginx'ом статический файл, содержащий её контент (если в параметрах запроса имеется ?wsdl, если его нет - то проксировать на приложение). Было сделано что-то вроде следующего: location = /some/app/url/messenger.asmx { if ( $args ~* wsdl ) { return 301 /some/app/url/static/messengerwsdl.xml; } proxy_pass http://server1:8080; } где /some/app/url/static/ - смотрит на папку со статикой, обрабатываемую nginx'ом, а messengerwsdl.xml - тот самый файл с контентом wsdl'ки. работало всё просто замечательно, но.. PROBLEMS: ..оказалось, что клиент, запрашивавший wsdl, не умеет работать с редиректом :( А т.к. повлиять на клиента возможности нет - пришлось чесать затылок. GOALS: Можно ли сделать нечто подобное *без перенаправлений* ? Что пробовалось: положить файл в папку статики по пути, аналогичным location и с тем же именем, и поменять $document_root в блоке if'a, но: из if'a тоже надо как-то выходить - break не годится (обработка пойдет дальше по локейшену и в результате - запрос будет проксирован), return не годится (клиент не понимает редиректов), rewrite... а смысл? все равно в итоге return new location. В этом смысле, наверное, неплохо вписался бы try_files в блоке if'a... но он внутри директивы if запрещён. Может, ещё какие-нибудь варианты? И могут ли они быть в принципе. Если что-то было не ясно в описании - могу на псевдопримерах пояснить. А пока - вот: #$ 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 #$ 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 Спасибо! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Sep 2 14:34:19 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 2 Sep 2014 18:34:19 +0400 Subject: Transparent file substitution In-Reply-To: References: Message-ID: <20140902143418.GN1849@mdounin.ru> Hello! On Tue, Sep 02, 2014 at 05:20:00PM +0300, Андрей Середенко wrote: [...] > Можно ли сделать нечто подобное *без перенаправлений* ? > Что пробовалось: положить файл в папку статики по пути, аналогичным > location и с тем же именем, и поменять $document_root в блоке if'a, но: из > if'a тоже надо как-то выходить - break не годится (обработка пойдет дальше > по локейшену и в результате - запрос будет проксирован), return не годится > (клиент не понимает редиректов), rewrite... а смысл? все равно в итоге > return new location. Вам нужно по условию сделать внутреннее перенаправление, как-то так: location = /some/app/url/messenger.asmx { if (...) { rewrite ^ /some/app/url/static/messengerwsdl.xml last; } proxy_pass ... } location = /some/app/url/static/messengerwsdl.xml { # static file } В результате клиенту на исходный запрос будет возвращён статический файл, обычно доступный по заданному адресу. Подробнее тут: http://nginx.org/r/rewrite [...] > #$ nginx -V > nginx version: nginx/1.0.15 Антиквариат, однако. -- Maxim Dounin http://nginx.org/ From andrei.seredenko at gmail.com Wed Sep 3 12:16:35 2014 From: andrei.seredenko at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCh0LXRgNC10LTQtdC90LrQvg==?=) Date: Wed, 3 Sep 2014 15:16:35 +0300 Subject: nginx-ru Digest, Vol 59, Issue 3 In-Reply-To: References: Message-ID: Спасибо, попробуем! Про внутреннее перенаправление я как-то вообще не задумывался.. сразу, как try_files отвалился как вариант - так и перестал думать.) Антиквариат, однако. > > Помните ту часть, что про " возможности повлиять на клиента нет" ? Вот она и есть виновница этого антиквариата =) 3 сентября 2014 г., 15:00 пользователь написал: > Сообщения, предназначенные для списка рассылки 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. Transparent file substitution (Андрей Середенко) > 2. Re: Transparent file substitution (Maxim Dounin) > > > ---------- Пересылаемое сообщение ---------- > From: "Андрей Середенко" > To: nginx-ru at nginx.org > Cc: > Date: Tue, 2 Sep 2014 17:20:00 +0300 > Subject: Transparent file substitution > Доброго дня всем! > > Ребят, подскажите - имеется такой вопрос.. > > INTRO: > > Mono. Есть приложение, на которое nginx проксирует запросы. И есть один > не-совсем-адекватный клиент, который у этого приложения запрашивает wsdl > прежде, чем воспользоваться апишкой.. перед каждым запросом... и делает это > с частотой ~200 запросов в минуту (на каждый полезный запрос - вот этот вот > сорный запрос wsdl'ки, который впустую напрягает приложение) > > Возможности повлиять на клиента нет. Время подставлять костыли... > > > WORKAROUND: > > Раз возможности повлиять на клиента нет, было принято решение обмануть его > (нормальная практика, что =) ): вместо постоянной генерации wsdl'ки на > стороне приложения - отдавать nginx'ом статический файл, содержащий её > контент (если в параметрах запроса имеется ?wsdl, если его нет - то > проксировать на приложение). Было сделано что-то вроде следующего: > > location = /some/app/url/messenger.asmx { > if ( $args ~* wsdl ) { > return 301 /some/app/url/static/messengerwsdl.xml; > } > > proxy_pass http://server1:8080; > > } > > где /some/app/url/static/ - смотрит на папку со статикой, обрабатываемую > nginx'ом, а messengerwsdl.xml - тот самый файл с контентом wsdl'ки. > работало всё просто замечательно, но.. > > PROBLEMS: > > ..оказалось, что клиент, запрашивавший wsdl, не умеет работать с > редиректом :( > > А т.к. повлиять на клиента возможности нет - пришлось чесать затылок. > > > GOALS: > > Можно ли сделать нечто подобное *без перенаправлений* ? > Что пробовалось: положить файл в папку статики по пути, аналогичным > location и с тем же именем, и поменять $document_root в блоке if'a, но: из > if'a тоже надо как-то выходить - break не годится (обработка пойдет дальше > по локейшену и в результате - запрос будет проксирован), return не годится > (клиент не понимает редиректов), rewrite... а смысл? все равно в итоге > return new location. > > В этом смысле, наверное, неплохо вписался бы try_files в блоке if'a... но > он внутри директивы if запрещён. > > Может, ещё какие-нибудь варианты? И могут ли они быть в принципе. > Если что-то было не ясно в описании - могу на псевдопримерах пояснить. А > пока - вот: > > #$ 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 > > #$ 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 > > > > Спасибо! > > > > ---------- Пересылаемое сообщение ---------- > From: Maxim Dounin > To: nginx-ru at nginx.org > Cc: > Date: Tue, 2 Sep 2014 18:34:19 +0400 > Subject: Re: Transparent file substitution > Hello! > > On Tue, Sep 02, 2014 at 05:20:00PM +0300, Андрей Середенко wrote: > > [...] > > > Можно ли сделать нечто подобное *без перенаправлений* ? > > Что пробовалось: положить файл в папку статики по пути, аналогичным > > location и с тем же именем, и поменять $document_root в блоке if'a, но: > из > > if'a тоже надо как-то выходить - break не годится (обработка пойдет > дальше > > по локейшену и в результате - запрос будет проксирован), return не > годится > > (клиент не понимает редиректов), rewrite... а смысл? все равно в итоге > > return new location. > > Вам нужно по условию сделать внутреннее перенаправление, как-то > так: > > location = /some/app/url/messenger.asmx { > if (...) { > rewrite ^ /some/app/url/static/messengerwsdl.xml last; > } > > proxy_pass ... > } > > location = /some/app/url/static/messengerwsdl.xml { > # static file > } > > В результате клиенту на исходный запрос будет возвращён > статический файл, обычно доступный по заданному адресу. > > Подробнее тут: > > http://nginx.org/r/rewrite > > [...] > > > #$ nginx -V > > nginx version: nginx/1.0.15 > > Антиквариат, однако. > > -- > 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 privettoli at gmail.com Thu Sep 4 16:05:48 2014 From: privettoli at gmail.com (Anatoliy Papenko) Date: Thu, 4 Sep 2014 19:05:48 +0300 Subject: Nginx SSI caching Message-ID: Привет Может сможете помочь, У меня стоит nginx caching на GET-запросы для статических страничек. В одной из них есть ssi-вызов /user/ssi POST-запроса Как мне кэшировать этот запрос для каждого пользователя (уже по новому proxy_cache_key, который будет включать в себя $cookie_token)? Пробую location ^~ /user/ssi { #Caching proxy_cache cache; proxy_cache_key $scheme$proxy_host$uri$is_args$args$cookie_PLAY_LANG$cookie_token; #Ask SSI proxy_pass http://localhost:9000/user/ssi; } location / { #Caching proxy_cache cache; proxy_cache_valid 30m; proxy_cache_methods GET; proxy_cache_key $scheme$proxy_host$uri$is_args$args$cookie_PLAY_LANG; proxy_pass http://127.0.0.1:9000; } Но не получаеться, кэш для SSI не работает Буду крайне признателен за помощь. -- *Мой Skype : spend64* *Тел. +380938575311* *C ув., Анатолий.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Fri Sep 5 06:19:28 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 5 Sep 2014 12:19:28 +0600 Subject: [emerg] duplicate listen options for X.X.X.X:80 in /usr/local/etc/nginx/nginx.conf:9 Message-ID: Добрый день! если делаю вот так server { listen X.X.X.X:80 accept_filter=httpready; server_name 1.local; } server { listen X.X.X.X:80 accept_filter=httpready; server_name 2.local; } то получаю ошибку. также есть забавные ситуации (spdy будет включен в обоих случаях) server { listen X.X.X.X:443 ssl spdy; server_name 1.local; } server { listen X.X.X.X:443 ssl; server_name 2.local; } и (accept_filter будет применяться в обоих случаях) server { listen X.X.X.X:80 accept_filter=httpready; server_name 1.local; } server { listen X.X.X.X:80; server_name 2.local; } есть предложение что-нибудь с этим сделать. Илья Шипицин From wangsamp at gmail.com Fri Sep 5 07:07:47 2014 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Fri, 5 Sep 2014 10:07:47 +0300 (EEST) Subject: [emerg] duplicate listen options for X.X.X.X:80 in /usr/local/etc/nginx/nginx.conf:9 In-Reply-To: References: Message-ID: Today Sep 5, 2014 at 12:19 Илья Шипицин wrote: > если делаю вот так > > server { > listen X.X.X.X:80 accept_filter=httpready; > server_name 1.local; > } > > server { > listen X.X.X.X:80 accept_filter=httpready; > server_name 2.local; > } > > то получаю ошибку. http://nginx.org/r/listen/ru : В директиве listen можно также указать несколько дополнительных параметров, специфичных для связанных с сокетами системных вызовов. Эти параметры можно задать в любой директиве listen, но только один раз для указанной пары адрес:порт. > также есть забавные ситуации > > (spdy будет включен в обоих случаях) > > server { > listen X.X.X.X:443 ssl spdy; > server_name 1.local; > } > > server { > listen X.X.X.X:443 ssl; > server_name 2.local; > } Это свойства сокета, а не виртуального сервера. -- WNGS-RIPE From chipitsine at gmail.com Fri Sep 5 07:56:23 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 5 Sep 2014 13:56:23 +0600 Subject: [emerg] duplicate listen options for X.X.X.X:80 in /usr/local/etc/nginx/nginx.conf:9 In-Reply-To: References: Message-ID: если я 2 раза (или 1 раз) укажу spdy - работать будет всегда в двух случаях и ошибки конфигурации не будет. кажется, что с фильтрами подобная логика была бы уместна. ну и, раз уж оно все равно работает во всех случаях, вероятно, имеет смысл выдавать warning, если указано не во всех (вдруг кто-то будет полагать, что в одном месте у него spdy, а в другом нет). 5 сентября 2014 г., 13:07 пользователь Oleksandr V. Typlyns'kyi написал: > Today Sep 5, 2014 at 12:19 Илья Шипицин wrote: > >> если делаю вот так >> >> server { >> listen X.X.X.X:80 accept_filter=httpready; >> server_name 1.local; >> } >> >> server { >> listen X.X.X.X:80 accept_filter=httpready; >> server_name 2.local; >> } >> >> то получаю ошибку. > > http://nginx.org/r/listen/ru : > В директиве listen можно также указать несколько дополнительных > параметров, специфичных для связанных с сокетами системных вызовов. Эти > параметры можно задать в любой директиве listen, но только один раз для > указанной пары адрес:порт. > >> также есть забавные ситуации >> >> (spdy будет включен в обоих случаях) >> >> server { >> listen X.X.X.X:443 ssl spdy; >> server_name 1.local; >> } >> >> server { >> listen X.X.X.X:443 ssl; >> server_name 2.local; >> } > > Это свойства сокета, а не виртуального сервера. > > -- > WNGS-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Sep 5 09:59:08 2014 From: nginx-forum at nginx.us (kilgur) Date: Fri, 05 Sep 2014 05:59:08 -0400 Subject: =?UTF-8?B?NDAwIEJhZCBSZXF1ZXN0INC/0YDQuCBodHRwOi8vINCyIEhvc3Q=?= Message-ID: Версия nginx: 1.6.1 При запросе вида GET http://somesite.ru/ HTTP/1.1 Host: http://somesite nginx отвечает вышеуказанной ошибкой (400 Bad Request) Строки в поле Host с любым "мусором" успешно игнорируются веб-сервером, но вот имя сайта с указанием протокола приводит к ошибке. В описании протокола есть пункт (5.2), который сообщает "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." Т.е. любое содержимое заголовка Host должно быть проигнорировано... На старом сервере древняя 0.6.30 спокойно воспринимает такой заголовок. Есть какая-либо возможность настроить nginx так, чтобы он не выдавал ошибку 400? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253091,253091#msg-253091 From vbart at nginx.com Fri Sep 5 11:11:28 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 05 Sep 2014 15:11:28 +0400 Subject: =?UTF-8?B?UmU6IDQwMCBCYWQgUmVxdWVzdCDQv9GA0LggaHR0cDovLyDQsiBIb3N0?= In-Reply-To: References: Message-ID: <1417114.OlkfdUBA6B@vbart-workstation> On Friday 05 September 2014 05:59:08 kilgur wrote: > Версия nginx: 1.6.1 > При запросе вида > GET http://somesite.ru/ HTTP/1.1 > Host: http://somesite > nginx отвечает вышеуказанной ошибкой (400 Bad Request) > Строки в поле Host с любым "мусором" успешно игнорируются веб-сервером, но > вот имя сайта с указанием протокола приводит к ошибке. > > В описании протокола есть пункт (5.2), который сообщает > "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." > Т.е. любое содержимое заголовка Host должно быть проигнорировано... Вы цитируете устаревший RFC, да ещё часть про роутинг, а не про корректность. На самом деле: http://tools.ietf.org/html/rfc7230#section-5.4 A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value. > > На старом сервере древняя 0.6.30 спокойно воспринимает такой заголовок. > > Есть какая-либо возможность настроить nginx так, чтобы он не выдавал ошибку > 400? > Нет. -- Валентин Бартенев From nginx-forum at nginx.us Fri Sep 5 11:53:52 2014 From: nginx-forum at nginx.us (kilgur) Date: Fri, 05 Sep 2014 07:53:52 -0400 Subject: =?UTF-8?B?UmU6IDQwMCBCYWQgUmVxdWVzdCDQv9GA0LggaHR0cDovLyDQsiBIb3N0?= In-Reply-To: <1417114.OlkfdUBA6B@vbart-workstation> References: <1417114.OlkfdUBA6B@vbart-workstation> Message-ID: <08d04843d62e77e5ed7df7c26877668e.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > Вы цитируете устаревший RFC, да ещё часть про роутинг, а не про > корректность. > > На самом деле: http://tools.ietf.org/html/rfc7230#section-5.4 > > A server MUST respond with a 400 (Bad Request) status code to any > HTTP/1.1 request message that lacks a Host header field and to any > request message that contains more than one Host header field or a > Host header field with an invalid field-value. А если у меня nginx является фронтэндом к локальному апачу, он считается "прокси"? :) When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request MUST generate a new Host field-value based on the received request-target rather than forward the received Host field-value. > > Есть какая-либо возможность настроить nginx так, чтобы он не выдавал > ошибку > > 400? > > Нет. > Очень негибко... Я уже собрал nginx с поддержкой lua - проверить, передает ли nginx заголовки в header_filter_by_lua ДО отказа клиенту... ан нет, не вышло... Остается только исходники nginx'а править? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253091,253094#msg-253094 From vbart at nginx.com Fri Sep 5 12:27:33 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 05 Sep 2014 16:27:33 +0400 Subject: =?UTF-8?B?UmU6IDQwMCBCYWQgUmVxdWVzdCDQv9GA0LggaHR0cDovLyDQsiBIb3N0?= In-Reply-To: <08d04843d62e77e5ed7df7c26877668e.NginxMailingListRussian@forum.nginx.org> References: <1417114.OlkfdUBA6B@vbart-workstation> <08d04843d62e77e5ed7df7c26877668e.NginxMailingListRussian@forum.nginx.org> Message-ID: <88122960.kvrCVI15d5@vbart-workstation> On Friday 05 September 2014 07:53:52 kilgur wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > Вы цитируете устаревший RFC, да ещё часть про роутинг, а не про > > корректность. > > > > На самом деле: http://tools.ietf.org/html/rfc7230#section-5.4 > > > > A server MUST respond with a 400 (Bad Request) status code to any > > HTTP/1.1 request message that lacks a Host header field and to any > > request message that contains more than one Host header field or a > > Host header field with an invalid field-value. > > А если у меня nginx является фронтэндом к локальному апачу, он считается > "прокси"? :) Не считается. Что такое "proxy" четко определено в том же RFC. A "proxy" is a message-forwarding agent that is selected by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Под прокси в данном случае понимается исключительно forward proxy, который прописывается на клиенте. Nginx не предназначен, и никогда не был, для использования в качестве forward proxy. > > When a proxy receives a request with an absolute-form of > request-target, the proxy MUST ignore the received Host header field > (if any) and instead replace it with the host information of the > request-target. A proxy that forwards such a request MUST generate a > new Host field-value based on the received request-target rather than > forward the received Host field-value. Это относится к роутингу. Ignore тут касается роутинга запроса, а не его валидности. Всё это не отменяет того, что значение в заголовке должно быть при этом валидно с точки зрения заголовка. > > > > > Есть какая-либо возможность настроить nginx так, чтобы он не выдавал > > ошибку > > > 400? > > > > Нет. > > > Очень негибко... > Я уже собрал nginx с поддержкой lua - проверить, передает ли nginx заголовки > в header_filter_by_lua ДО отказа клиенту... ан нет, не вышло... > Остается только исходники nginx'а править? > Правьте исходники клиента. Это будет значительно полезнее, а также не приведет к возможным проблемам с безопасностью. Фильтрация "/" в первую очередь необходима для того, чтобы через Host злоумышленник не имел возможности пробрасывать пути к файлам и директориям. -- Валентин Бартенев From nginx-forum at nginx.us Sat Sep 6 05:35:54 2014 From: nginx-forum at nginx.us (arriah) Date: Sat, 06 Sep 2014 01:35:54 -0400 Subject: =?UTF-8?B?bmdpbngg0L3QtdGB0LrQvtC70YzQutC+IElQ?= Message-ID: Здравствуйте Есть сервер с двумя IP с одним сетевым интерфейсом.. IP прописан альясом nginx слушает на стандартном порту по "дополнительному" IP, а отвечает с "основного" Как настроить nginx, чтобы он отвечал с того же IP, на который приходит запрос? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253107,253107#msg-253107 From wangsamp at gmail.com Sat Sep 6 08:30:52 2014 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sat, 6 Sep 2014 11:30:52 +0300 (EEST) Subject: =?UTF-8?B?UmU6IG5naW54INC90LXRgdC60L7Qu9GM0LrQviBJUA==?= In-Reply-To: References: Message-ID: Today Sep 6, 2014 at 01:35 arriah wrote: > Есть сервер с двумя IP с одним сетевым интерфейсом.. IP прописан альясом > nginx слушает на стандартном порту по "дополнительному" IP, а отвечает с > "основного" > Как настроить nginx, чтобы он отвечал с того же IP, на который приходит > запрос? Без дополнительных манипуляций в виде трансляции адресов сервер будет отвечать именно с того адреса, к которому установлено соединение. -- WNGS-RIPE From nginx-forum at nginx.us Sat Sep 6 08:38:08 2014 From: nginx-forum at nginx.us (arriah) Date: Sat, 06 Sep 2014 04:38:08 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC90LXRgdC60L7Qu9GM0LrQviBJUA==?= In-Reply-To: References: Message-ID: Да. точно. Отвечает с того адреса с которого пришел запрос. Другой вопрос. Форум у меня живет на "дополнительном" адресе. а вот если через форум отправлять письма пользователям, то он соединяется с сервером отправки почты с "основного" адреса. Это конечно не критично, но все же это можно как-нибудь настроить? Наверно придется файрволом делать форвард? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253107,253109#msg-253109 From wangsamp at gmail.com Sat Sep 6 09:30:28 2014 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sat, 6 Sep 2014 12:30:28 +0300 (EEST) Subject: =?UTF-8?B?UmU6IG5naW54INC90LXRgdC60L7Qu9GM0LrQviBJUA==?= In-Reply-To: References: Message-ID: Today Sep 6, 2014 at 04:38 arriah wrote: > Форум у меня живет на "дополнительном" адресе. а вот если через форум > отправлять письма пользователям, то он соединяется с сервером отправки почты > с "основного" адреса. Это конечно не критично, но все же это можно > как-нибудь настроить? Наверно придется файрволом делать форвард? Подумайте, как системе на уровне сетевого стека понять форум это или нет? Нужен приложению определённый адрес - пусть делает bind(2) на него. Например, в PHP для этого есть socket_bind: http://php.net/manual/en/function.socket-bind.php В Postfix есть smtp_bind_address: http://www.postfix.org/postconf.5.html#smtp_bind_address И всё это к nginx уже отношения не имеет. -- WNGS-RIPE From sytar.alex at gmail.com Sat Sep 6 10:03:05 2014 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Sat, 6 Sep 2014 14:03:05 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC90LXRgdC60L7Qu9GM0LrQviBJUA==?= In-Reply-To: References: Message-ID: 6 сентября 2014 г., 12:38 пользователь arriah написал: > Да. точно. Отвечает с того адреса с которого пришел запрос. > Другой вопрос. > Форум у меня живет на "дополнительном" адресе. а вот если через форум > отправлять письма пользователям, то он соединяется с сервером отправки почты > с "основного" адреса. Это конечно не критично, но все же это можно > как-нибудь настроить? Наверно придется файрволом делать форвард? > Не очень понятно при чем здесь веб-сервер, нужно настроить свой МТА From nginx-forum at nginx.us Sat Sep 6 10:35:32 2014 From: nginx-forum at nginx.us (kilgur) Date: Sat, 06 Sep 2014 06:35:32 -0400 Subject: =?UTF-8?B?UmU6IDQwMCBCYWQgUmVxdWVzdCDQv9GA0LggaHR0cDovLyDQsiBIb3N0?= In-Reply-To: <88122960.kvrCVI15d5@vbart-workstation> References: <88122960.kvrCVI15d5@vbart-workstation> Message-ID: <7496d08f6003b5b601903d9502868abb.NginxMailingListRussian@forum.nginx.org> Валентин, спасибо за разъяснения. К сожалению, разработчику клиента понадобится довольно долгое время для исправления ошибки. Так что, в качестве временного решения, придется исправить исходники nginx Еще раз спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253091,253112#msg-253112 From mva at mva.name Sat Sep 6 11:01:52 2014 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 06 Sep 2014 18:01:52 +0700 Subject: [emerg] duplicate listen options for X.X.X.X:80 in /usr/local/etc/nginx/nginx.conf:9 In-Reply-To: References: Message-ID: <2388762.M7gldqdxrr@note> В письме от Пт, 5 сентября 2014 13:56:23 пользователь Илья Шипицин написал: > если я 2 раза (или 1 раз) укажу spdy - работать будет всегда в двух > случаях и ошибки конфигурации не будет. > кажется, что с фильтрами подобная логика была бы уместна. > > > ну и, раз уж оно все равно работает во всех случаях, вероятно, имеет > смысл выдавать warning, если указано не во всех (вдруг кто-то будет > полагать, что в одном месте у него spdy, а в другом нет). > Обычно это делается так: в дефолтном catch-all вхосте указываются все эти уникальные опции (которые указываются один раз), а у остальных ? неуникальные. -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From gmm at csdoc.com Sat Sep 6 13:00:07 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 06 Sep 2014 16:00:07 +0300 Subject: [emerg] duplicate listen options for X.X.X.X:80 in /usr/local/etc/nginx/nginx.conf:9 In-Reply-To: <2388762.M7gldqdxrr@note> References: <2388762.M7gldqdxrr@note> Message-ID: <540B0557.20201@csdoc.com> On 06.09.2014 14:01, Vadim A. Misbakh-Soloviov wrote: >> если я 2 раза (или 1 раз) укажу spdy - работать будет всегда в двух >> случаях и ошибки конфигурации не будет. >> кажется, что с фильтрами подобная логика была бы уместна. >> >> ну и, раз уж оно все равно работает во всех случаях, вероятно, имеет >> смысл выдавать warning, если указано не во всех (вдруг кто-то будет >> полагать, что в одном месте у него spdy, а в другом нет). Да, это было бы вполне логично. Иначе - зачем давать юзеру возможность выборочно не-указывать параметр spdy, если он всеравно применится везде. То же самое относится и к параметру ssl - хотя и "listen 1.2.3.4:443;" в конфиге, но соединения всеравно принимаются только по протоколу https. > Обычно это делается так: > в дефолтном catch-all вхосте указываются все эти уникальные опции (которые > указываются один раз), а у остальных ? неуникальные. Только из документации совсем не понятно, какие из параметров listen являются уникальными для сервера, а какие - общими для всех серверов. Похоже, что только опция default_server является специфичной для сервера, а все остальные - и так общие для всех серверов будут. | В директиве listen можно также указать несколько дополнительных | параметров, специфичных для связанных с сокетами системных вызовов. | Эти параметры можно задать в любой директиве listen, но только один | раз для указанной пары адрес:порт. Что только еще больше добавляет путаницы. Прописали параметр в каком-то одном случайном сервере - а применяется этот параметр потом во всех серверах с такой же комбинацией ip:port в listen. Идеальным вариантом с точки зрения легкости чтения/сопровождения конфига было бы требовать наличия параметра default_server всегда, если в конфиге присутствует более одного сервера на каком-то сокете. И все параметры, которые можно задать только один раз - можно задать только в том единственном сервере, который помечен как default_server, а общие параметры ssl, spdy и proxy_protocol должны быть указаны в каждом сервере или ни в одном из них. Если эти условия не выполняются - тогда пользователю выдается warning. В результате чтобы понять как работает тот или иной сервер - надо будет прочитать в конфиге определения максимум двух серверов. Обратная совместимость не теряется, потому что это только warning, который не блокирует работу сервера со старой версией конфигурации. Сейчас - надо просмотреть определения вообще всех серверов на этом сокете и в случае неочевидной конфигурации - никаких варнингов нет. -- Best regards, Gena From chipitsine at gmail.com Mon Sep 8 03:54:42 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 8 Sep 2014 09:54:42 +0600 Subject: [emerg] duplicate listen options for X.X.X.X:80 in /usr/local/etc/nginx/nginx.conf:9 In-Reply-To: <540B0557.20201@csdoc.com> References: <2388762.M7gldqdxrr@note> <540B0557.20201@csdoc.com> Message-ID: да, идея выдавать WARNING при отсутствии явного default_server хороша. как и идея все уникальные параметры разрешать только для default_server 6 сентября 2014 г., 19:00 пользователь Gena Makhomed написал: > On 06.09.2014 14:01, Vadim A. Misbakh-Soloviov wrote: > >>> если я 2 раза (или 1 раз) укажу spdy - работать будет всегда в двух >>> случаях и ошибки конфигурации не будет. >>> кажется, что с фильтрами подобная логика была бы уместна. >>> >>> ну и, раз уж оно все равно работает во всех случаях, вероятно, имеет >>> смысл выдавать warning, если указано не во всех (вдруг кто-то будет >>> полагать, что в одном месте у него spdy, а в другом нет). > > > Да, это было бы вполне логично. Иначе - зачем давать юзеру возможность > выборочно не-указывать параметр spdy, если он всеравно применится везде. > > То же самое относится и к параметру ssl - хотя и "listen 1.2.3.4:443;" > в конфиге, но соединения всеравно принимаются только по протоколу https. > >> Обычно это делается так: >> в дефолтном catch-all вхосте указываются все эти уникальные опции (которые >> указываются один раз), а у остальных ? неуникальные. > > > Только из документации совсем не понятно, какие из параметров listen > являются уникальными для сервера, а какие - общими для всех серверов. > > Похоже, что только опция default_server является специфичной > для сервера, а все остальные - и так общие для всех серверов будут. > > | В директиве listen можно также указать несколько дополнительных > | параметров, специфичных для связанных с сокетами системных вызовов. > | Эти параметры можно задать в любой директиве listen, но только один > | раз для указанной пары адрес:порт. > > Что только еще больше добавляет путаницы. Прописали параметр > в каком-то одном случайном сервере - а применяется этот параметр > потом во всех серверах с такой же комбинацией ip:port в listen. > > Идеальным вариантом с точки зрения легкости чтения/сопровождения > конфига было бы требовать наличия параметра default_server всегда, > если в конфиге присутствует более одного сервера на каком-то сокете. > > И все параметры, которые можно задать только один раз - можно задать > только в том единственном сервере, который помечен как default_server, > а общие параметры ssl, spdy и proxy_protocol должны быть указаны > в каждом сервере или ни в одном из них. Если эти условия > не выполняются - тогда пользователю выдается warning. > > В результате чтобы понять как работает тот или иной сервер - > надо будет прочитать в конфиге определения максимум двух серверов. > > Обратная совместимость не теряется, потому что это только warning, > который не блокирует работу сервера со старой версией конфигурации. > > Сейчас - надо просмотреть определения вообще всех серверов на этом > сокете и в случае неочевидной конфигурации - никаких варнингов нет. > > -- > Best regards, > Gena > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From swood at fotofor.biz Wed Sep 10 08:14:19 2014 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 10 Sep 2014 12:14:19 +0400 Subject: nginx + cors Message-ID: Здравствуйте. Подскажите, пожалуйста, имеется мистика. Есть вот такой location: location ~ \.jpg$ { expires 1h; proxy_pass http://host:port; add_header Access-Control-Allow-Headers "X-Requested-With"; add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS"; add_header Access-Control-Allow-Origin "*"; } И все вроде бы хорошо, но если размер файла становится хотя бы 91256 байт, то эти заголовки не отдаются. Звучит как фантастика, но может быть и правда отдача заголовков зависит от того, какой объем проксируется. Версия nginx 1.2.4. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From citrin at citrin.ru Wed Sep 10 08:57:08 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Wed, 10 Sep 2014 12:57:08 +0400 Subject: nginx + cors In-Reply-To: References: Message-ID: <54101264.80604@citrin.ru> On 09/10/14 12:14, Anton Kiryushkin wrote: > > Подскажите, пожалуйста, имеется мистика. > Есть вот такой location: > location ~ \.jpg$ { > expires 1h; > proxy_pass http://host:port; > add_header Access-Control-Allow-Headers "X-Requested-With"; > add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS"; > add_header Access-Control-Allow-Origin "*"; > } > > И все вроде бы хорошо, но если размер файла становится хотя бы 91256 байт, то > эти заголовки не отдаются. Звучит как фантастика, но может быть и правда отдача > заголовков зависит от того, какой объем проксируется. Версия nginx 1.2.4. 1. Смотрите debug log, там бывает много полезного. Можно включить debug лог тольок для одного IP: http://nginx.org/r/debug_connection послать с него тестовый запрос на который должен вернуться большой ответ. 2. 1.2.4 это старая версия, лучше обновиться до 1.6.1 From sytar.alex at gmail.com Wed Sep 10 10:17:46 2014 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Wed, 10 Sep 2014 14:17:46 +0400 Subject: nginx + cors In-Reply-To: References: Message-ID: 10 сентября 2014 г., 12:14 пользователь Anton Kiryushkin написал: > Здравствуйте. > > Подскажите, пожалуйста, имеется мистика. > Есть вот такой location: > location ~ \.jpg$ { > expires 1h; > proxy_pass http://host:port; > add_header Access-Control-Allow-Headers "X-Requested-With"; > add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS"; > add_header Access-Control-Allow-Origin "*"; > } > > И все вроде бы хорошо, но если размер файла становится хотя бы 91256 байт, > то эти заголовки не отдаются. Звучит как фантастика, но может быть и правда > отдача заголовков зависит от того, какой объем проксируется. Версия nginx > 1.2.4. А как вы проверяете отдачу/не отдачу заголовков? По хорошему нужно как-то так: curl -I http://domain.com/foo.jpg From swood at fotofor.biz Wed Sep 10 10:30:30 2014 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 10 Sep 2014 14:30:30 +0400 Subject: nginx + cors In-Reply-To: References: Message-ID: Здравствуйте. Делаю curl -i и проверяю, что отдал сервер. 10 сентября 2014 г., 14:17 пользователь Aleksandr Sytar < sytar.alex at gmail.com> написал: > 10 сентября 2014 г., 12:14 пользователь Anton Kiryushkin > написал: > > Здравствуйте. > > > > Подскажите, пожалуйста, имеется мистика. > > Есть вот такой location: > > location ~ \.jpg$ { > > expires 1h; > > proxy_pass http://host:port; > > add_header Access-Control-Allow-Headers "X-Requested-With"; > > add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS"; > > add_header Access-Control-Allow-Origin "*"; > > } > > > > И все вроде бы хорошо, но если размер файла становится хотя бы 91256 > байт, > > то эти заголовки не отдаются. Звучит как фантастика, но может быть и > правда > > отдача заголовков зависит от того, какой объем проксируется. Версия nginx > > 1.2.4. > > А как вы проверяете отдачу/не отдачу заголовков? > > По хорошему нужно как-то так: curl -I http://domain.com/foo.jpg > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva at mva.name Wed Sep 10 19:22:31 2014 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 11 Sep 2014 02:22:31 +0700 Subject: nginx + cors In-Reply-To: <54101264.80604@citrin.ru> References: <54101264.80604@citrin.ru> Message-ID: <5233671.YLLFBB3JDJ@note> В письме от Ср, 10 сентября 2014 12:57:08 пользователь Anton Yuzhaninov написал: > 2. 1.2.4 это старая версия, лучше обновиться до 1.6.1 Ну, лично я не вижу ничего зазорного и в апгрейде до 1.7.4... Как показывает практика, если какой-то факап и обнаруживается, то стейбл-ветка ему тоже подвержена. -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From chipitsine at gmail.com Wed Sep 10 20:02:35 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 11 Sep 2014 02:02:35 +0600 Subject: nginx + cors In-Reply-To: References: Message-ID: add_header не работает, если статус, например, 500. вам правильно советуют, дебаг покажет всё. 10 сентября 2014 г., 14:14 пользователь Anton Kiryushkin написал: > Здравствуйте. > > Подскажите, пожалуйста, имеется мистика. > Есть вот такой location: > location ~ \.jpg$ { > expires 1h; > proxy_pass http://host:port; > add_header Access-Control-Allow-Headers "X-Requested-With"; > add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS"; > add_header Access-Control-Allow-Origin "*"; > } > > И все вроде бы хорошо, но если размер файла становится хотя бы 91256 байт, > то эти заголовки не отдаются. Звучит как фантастика, но может быть и правда > отдача заголовков зависит от того, какой объем проксируется. Версия nginx > 1.2.4. > > -- > Best regards, > Anton Kiryushkin > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From undying-m at yandex.ru Thu Sep 11 15:21:27 2014 From: undying-m at yandex.ru (Den Bozhok) Date: Thu, 11 Sep 2014 19:21:27 +0400 Subject: =?UTF-8?B?0L/RgNC+0LHQu9C10LzRiyDRgSBwcm94eV9jYWNoZS4g0LfQsNCz0L7Qu9C+0LI=?= =?UTF-8?B?0LrQsCBTZXQtQ29va2llINC90LXRgtGDLg==?= Message-ID: <965581410448887@web28o.yandex.ru> An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Sep 11 16:04:53 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 11 Sep 2014 20:04:53 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80Ysg0YEgcHJveHlfY2FjaGUuINC30LDQs9C+0Ls=?= =?UTF-8?B?0L7QstC60LAgU2V0LUNvb2tpZSDQvdC10YLRgy4=?= In-Reply-To: <965581410448887@web28o.yandex.ru> References: <965581410448887@web28o.yandex.ru> Message-ID: <20140911160453.GD59236@mdounin.ru> Hello! On Thu, Sep 11, 2014 at 07:21:27PM +0400, Den Bozhok wrote: > Доброго дня! > > Пытаюсь настроить кеширование картинок но nginx отказывается > кешировать. Не могу понять в чем может быть причина. Никаких лишних > заголовков от бэкенда не приходит,поэтому проблем быть не должно, > однако.. [...] Если каких-либо явных указаний на возможное время кеширования ответа от бекенда не приходит ("Expires", "Cache-Control: max-age=...", "X-Accel-Expires"), то nginx руководствуется значениями, заданными с помощью директивы proxy_cache_valid, см. тут: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid Т.к. в конфиге директивы proxy_cache_valid отстствуют, а заголовков Expires/Cache-Control/X-Accel-Expires в ответе нет, тто соответственно ответ - не кешируется. Чтобы ответы кешировались - нужно добавить в конфиг proxy_cache_valid, либо возвращать Expires/Cache-Control/X-Accel-Expires в ответах бекенда. -- Maxim Dounin http://nginx.org/ From vbart at nginx.com Thu Sep 11 16:05:27 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 11 Sep 2014 20:05:27 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80Ysg0YEgcHJveHlfY2FjaGUuINC30LDQs9C+0Ls=?= =?UTF-8?B?0L7QstC60LAgU2V0LUNvb2tpZSDQvdC10YLRgy4=?= In-Reply-To: <965581410448887@web28o.yandex.ru> References: <965581410448887@web28o.yandex.ru> Message-ID: <1544416.ZxT5UAf1WB@vbart-workstation> On Thursday 11 September 2014 19:21:27 Den Bozhok wrote: > Доброго дня! > Пытаюсь настроить кеширование картинок но nginx отказывается кешировать. Не > могу понять в чем может быть причина. Никаких лишних заголовков от бэкенда > не приходит,поэтому проблем быть не должно, однако.. > > Конфиг: [..] Никаких заголовков, сообщающих о том, что ответ можно кэшировать на такое-то время от бэкенда у вас тоже не приходит. И в конфигурации вы об этом nginx-у не сообщили: http://nginx.org/r/proxy_cache_valid/ru -- Валентин Бартенев From undying-m at yandex.ru Fri Sep 12 06:53:46 2014 From: undying-m at yandex.ru (Den Bozhok) Date: Fri, 12 Sep 2014 10:53:46 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80Ysg0YEgcHJveHlfY2FjaGUuINC30LDQs9C+0Ls=?= =?UTF-8?B?0L7QstC60LAgU2V0LUNvb2tpZSDQvdC10YLRgy4=?= In-Reply-To: <20140911160453.GD59236@mdounin.ru> References: <965581410448887@web28o.yandex.ru> <20140911160453.GD59236@mdounin.ru> Message-ID: <1479781410504826@web8j.yandex.ru> An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Sep 12 08:51:44 2014 From: nginx-forum at nginx.us (Flagman) Date: Fri, 12 Sep 2014 04:51:44 -0400 Subject: =?UTF-8?B?0JrQvtC90YTQuNCz0YPRgNC40YDQvtCy0LDQvdC40LUgKGNvbmZpZ3VyZSkgbmdp?= =?UTF-8?B?bnggMS43LjQg0L3QsCBkZWJpYW4gNg==?= Message-ID: <5cbd9bea01f99392fd1403bc3b8854d4.NginxMailingListRussian@forum.nginx.org> Желаю всем здравия! Прошу помощи. Имеется сервер с Debian 6.0, на нём установлен nginx 1.1.19, хочу установить последлюю версию 1.7.4 но не понимаю откуда берутся модули указанные к предыдущей сборки, такого вот вида: --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-auth-pam --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-echo --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-upstream-fair --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-dav-ext-module помогите, пожалуйста, разобраться. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253209,253209#msg-253209 From sytar.alex at gmail.com Fri Sep 12 09:00:58 2014 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Fri, 12 Sep 2014 13:00:58 +0400 Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQuNGA0L7QstCw0L3QuNC1IChjb25maWd1cmUp?= =?UTF-8?B?IG5naW54IDEuNy40INC90LAgZGViaWFuIDY=?= In-Reply-To: <5cbd9bea01f99392fd1403bc3b8854d4.NginxMailingListRussian@forum.nginx.org> References: <5cbd9bea01f99392fd1403bc3b8854d4.NginxMailingListRussian@forum.nginx.org> Message-ID: 12 сентября 2014 г., 12:51 пользователь Flagman написал: > Желаю всем здравия! > > Прошу помощи. Имеется сервер с Debian 6.0, на нём установлен nginx 1.1.19, > хочу установить последлюю версию 1.7.4 но не понимаю откуда берутся модули > указанные к предыдущей сборки, такого вот вида: > > --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-auth-pam > --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-echo > --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-upstream-fair > --add-module=/build/buildd-nginx_1.1.19-1~bpo60+1-amd64-T0OX_L/nginx-1.1.19/debian/modules/nginx-dav-ext-module > > помогите, пожалуйста, разобраться. > У вас стоит nginx из дефолтного репозитария debian - http://nginx.org/en/linux_packages.html#stable From sergeyk at jfrog.com Fri Sep 12 10:16:42 2014 From: sergeyk at jfrog.com (Sergey Kagansky) Date: Fri, 12 Sep 2014 13:16:42 +0300 Subject: =?UTF-8?B?0JTQvtGB0YLRg9C/INC/0L4gVXNlci1BZ2VudCDQuNC70LggaXA=?= Message-ID: Добрый день. У меня есть такая конфигурация: location /test { include list.ips; proxy_pass http://127.0.0.1; } В файле list.ips содержится список разрешённых IPs в конце файла deny all; И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в дополнение к списку адресов. Пробовал инклюд в if - не работает Пробовал инклюд с переменной - не работает Как то это можно реализовать? Заранее благодарен за советы. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsjcfm at gmail.com Fri Sep 12 10:19:03 2014 From: vsjcfm at gmail.com (Anton Sayetsky) Date: Fri, 12 Sep 2014 13:19:03 +0300 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+IFVzZXItQWdlbnQg0LjQu9C4IGlw?= In-Reply-To: References: Message-ID: http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky написал: > Добрый день. > У меня есть такая конфигурация: > > > > location /test { > include list.ips; > proxy_pass http://127.0.0.1; > } > > В файле list.ips содержится список разрешённых IPs в конце файла deny all; > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в > дополнение к списку адресов. > > Пробовал инклюд в if - не работает > Пробовал инклюд с переменной - не работает > Как то это можно реализовать? > Заранее благодарен за советы. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From wangsamp at gmail.com Fri Sep 12 10:56:27 2014 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Fri, 12 Sep 2014 13:56:27 +0300 (EEST) Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+IFVzZXItQWdlbnQg0LjQu9C4IGlw?= In-Reply-To: References: Message-ID: Today Sep 12, 2014 at 13:19 Anton Sayetsky wrote: > http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy Вредный совет. Нет access модуля для проверки User-Agent. > 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky > написал: > > Добрый день. > > У меня есть такая конфигурация: > > > > location /test { > > include list.ips; > > proxy_pass http://127.0.0.1; > > } > > > > В файле list.ips содержится список разрешённых IPs в конце файла deny all; > > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в > > дополнение к списку адресов. > > > > Пробовал инклюд в if - не работает > > Пробовал инклюд с переменной - не работает > > Как то это можно реализовать? Задавать значение переменной через geo(http://nginx.org/r/geo/ru) и потом использовать её в map(http://nginx.org/r/map/ru) по $http_user_agent: geo $listips { default 1; 127.0.0.1 0; 192.168.1.0/24 0; ... } map $http_user_agent $nottrusted { default $listips; "~Opera Mini" 0; ... } location /test { if ($nottrusted) {return 403;} proxy_pass http://127.0.0.1; } -- WNGS-RIPE From sergeyk at jfrog.com Fri Sep 12 12:10:01 2014 From: sergeyk at jfrog.com (Sergey Kagansky) Date: Fri, 12 Sep 2014 15:10:01 +0300 Subject: nginx-ru Digest, Vol 59, Issue 12 In-Reply-To: References: Message-ID: А можно map хранить в отдельных файлах и подключать через include? 2014-09-12 15:00 GMT+03:00 : > Сообщения, предназначенные для списка рассылки 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: Доступ по User-Agent или ip (Anton Sayetsky) > 2. Re: Доступ по User-Agent или ip (Oleksandr V. Typlyns'kyi) > > > ---------- Forwarded message ---------- > From: Anton Sayetsky > To: nginx-ru at nginx.org > Cc: > Date: Fri, 12 Sep 2014 13:19:03 +0300 > Subject: Re: Доступ по User-Agent или ip > http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy > > 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky > написал: > > Добрый день. > > У меня есть такая конфигурация: > > > > > > > > location /test { > > include list.ips; > > proxy_pass http://127.0.0.1; > > } > > > > В файле list.ips содержится список разрешённых IPs в конце файла deny > all; > > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в > > дополнение к списку адресов. > > > > Пробовал инклюд в if - не работает > > Пробовал инклюд с переменной - не работает > > Как то это можно реализовать? > > Заранее благодарен за советы. > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > ---------- Forwarded message ---------- > From: "Oleksandr V. Typlyns'kyi" > To: nginx-ru at nginx.org > Cc: > Date: Fri, 12 Sep 2014 13:56:27 +0300 (EEST) > Subject: Re: Доступ по User-Agent или ip > Today Sep 12, 2014 at 13:19 Anton Sayetsky wrote: > > > http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy > > Вредный совет. > Нет access модуля для проверки User-Agent. > > > 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky > > написал: > > > Добрый день. > > > У меня есть такая конфигурация: > > > > > > location /test { > > > include list.ips; > > > proxy_pass http://127.0.0.1; > > > } > > > > > > В файле list.ips содержится список разрешённых IPs в конце файла deny > all; > > > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в > > > дополнение к списку адресов. > > > > > > Пробовал инклюд в if - не работает > > > Пробовал инклюд с переменной - не работает > > > Как то это можно реализовать? > > Задавать значение переменной через geo(http://nginx.org/r/geo/ru) и > потом использовать её в map(http://nginx.org/r/map/ru) по > $http_user_agent: > > geo $listips { > default 1; > 127.0.0.1 0; > 192.168.1.0/24 0; > ... > } > > map $http_user_agent $nottrusted { > default $listips; > "~Opera Mini" 0; > ... > } > > location /test { > if ($nottrusted) {return 403;} > proxy_pass http://127.0.0.1; > } > > -- > WNGS-RIPE > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Fri Sep 12 12:19:36 2014 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 12 Sep 2014 16:19:36 +0400 Subject: nginx-ru Digest, Vol 59, Issue 12 In-Reply-To: References: Message-ID: 2014-09-12 16:10 GMT+04:00 Sergey Kagansky : > А можно map хранить в отдельных файлах и подключать через include? да From sergeyk at jfrog.com Sun Sep 14 12:03:41 2014 From: sergeyk at jfrog.com (Sergey Kagansky) Date: Sun, 14 Sep 2014 15:03:41 +0300 Subject: nginx-ru Digest, Vol 59, Issue 13 In-Reply-To: References: Message-ID: Огромное спасибо! 2014-09-13 15:00 GMT+03:00 : > Сообщения, предназначенные для списка рассылки 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: nginx-ru Digest, Vol 59, Issue 12 (Sergey Kagansky) > 2. Re: nginx-ru Digest, Vol 59, Issue 12 (Daniel Podolsky) > > > ---------- Forwarded message ---------- > From: Sergey Kagansky > To: nginx-ru > Cc: > Date: Fri, 12 Sep 2014 15:10:01 +0300 > Subject: Re: nginx-ru Digest, Vol 59, Issue 12 > А можно map хранить в отдельных файлах и подключать через include? > > > 2014-09-12 15:00 GMT+03:00 : > >> Сообщения, предназначенные для списка рассылки 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: Доступ по User-Agent или ip (Anton Sayetsky) >> 2. Re: Доступ по User-Agent или ip (Oleksandr V. Typlyns'kyi) >> >> >> ---------- Forwarded message ---------- >> From: Anton Sayetsky >> To: nginx-ru at nginx.org >> Cc: >> Date: Fri, 12 Sep 2014 13:19:03 +0300 >> Subject: Re: Доступ по User-Agent или ip >> http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy >> >> 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky >> написал: >> > Добрый день. >> > У меня есть такая конфигурация: >> > >> > >> > >> > location /test { >> > include list.ips; >> > proxy_pass http://127.0.0.1; >> > } >> > >> > В файле list.ips содержится список разрешённых IPs в конце файла deny >> all; >> > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в >> > дополнение к списку адресов. >> > >> > Пробовал инклюд в if - не работает >> > Пробовал инклюд с переменной - не работает >> > Как то это можно реализовать? >> > Заранее благодарен за советы. >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> ---------- Forwarded message ---------- >> From: "Oleksandr V. Typlyns'kyi" >> To: nginx-ru at nginx.org >> Cc: >> Date: Fri, 12 Sep 2014 13:56:27 +0300 (EEST) >> Subject: Re: Доступ по User-Agent или ip >> Today Sep 12, 2014 at 13:19 Anton Sayetsky wrote: >> >> > http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy >> >> Вредный совет. >> Нет access модуля для проверки User-Agent. >> >> > 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky >> > написал: >> > > Добрый день. >> > > У меня есть такая конфигурация: >> > > >> > > location /test { >> > > include list.ips; >> > > proxy_pass http://127.0.0.1; >> > > } >> > > >> > > В файле list.ips содержится список разрешённых IPs в конце файла deny >> all; >> > > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в >> > > дополнение к списку адресов. >> > > >> > > Пробовал инклюд в if - не работает >> > > Пробовал инклюд с переменной - не работает >> > > Как то это можно реализовать? >> >> Задавать значение переменной через geo(http://nginx.org/r/geo/ru) и >> потом использовать её в map(http://nginx.org/r/map/ru) по >> $http_user_agent: >> >> geo $listips { >> default 1; >> 127.0.0.1 0; >> 192.168.1.0/24 0; >> ... >> } >> >> map $http_user_agent $nottrusted { >> default $listips; >> "~Opera Mini" 0; >> ... >> } >> >> location /test { >> if ($nottrusted) {return 403;} >> proxy_pass http://127.0.0.1; >> } >> >> -- >> WNGS-RIPE >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > ---------- Forwarded message ---------- > From: Daniel Podolsky > To: nginx-ru > Cc: > Date: Fri, 12 Sep 2014 16:19:36 +0400 > Subject: Re: nginx-ru Digest, Vol 59, Issue 12 > 2014-09-12 16:10 GMT+04:00 Sergey Kagansky : > > А можно map хранить в отдельных файлах и подключать через include? > да > > _______________________________________________ > 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 Sep 15 00:32:29 2014 From: nginx-forum at nginx.us (den68) Date: Sun, 14 Sep 2014 20:32:29 -0400 Subject: =?UTF-8?B?bWFwICsgcmVnZXhwID0g0L/QtdGA0LXQvNC10L3QvdCw0Y8uLg==?= Message-ID: <321c2493228d510d8221d8e26fe22ed8.NginxMailingListRussian@forum.nginx.org> не выходит каменный цветок ... map $geoip_org $as_num { default ""; ~*"^(AS[0-9]+)" $1; ~^"(AS[0-9]+).+?" $1; ~"^(AS[0-9]+)" $1; nginx -s reload nginx: [emerg] unknown "1" variable Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253239,253239#msg-253239 From vbart at nginx.com Mon Sep 15 08:49:52 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 15 Sep 2014 12:49:52 +0400 Subject: =?UTF-8?B?UmU6IG1hcCArIHJlZ2V4cCA9INC/0LXRgNC10LzQtdC90L3QsNGPLi4=?= In-Reply-To: <321c2493228d510d8221d8e26fe22ed8.NginxMailingListRussian@forum.nginx.org> References: <321c2493228d510d8221d8e26fe22ed8.NginxMailingListRussian@forum.nginx.org> Message-ID: <1702581.dYrgNL61Wh@vbart-laptop> On Sunday 14 September 2014 20:32:29 den68 wrote: > не выходит каменный цветок ... > > map $geoip_org $as_num { > default ""; > ~*"^(AS[0-9]+)" $1; > ~^"(AS[0-9]+).+?" $1; > ~"^(AS[0-9]+)" $1; > > nginx -s reload > nginx: [emerg] unknown "1" variable > Директива map не поддерживает позиционных выделений для регулярных выражений. Нужно использовать именованные. ~^(?AS[0-9]+) $n -- Валентин Бартенев From nginx-forum at nginx.us Mon Sep 15 23:27:22 2014 From: nginx-forum at nginx.us (den68) Date: Mon, 15 Sep 2014 19:27:22 -0400 Subject: =?UTF-8?B?UmU6IG1hcCArIHJlZ2V4cCA9INC/0LXRgNC10LzQtdC90L3QsNGPLi4=?= In-Reply-To: <1702581.dYrgNL61Wh@vbart-laptop> References: <1702581.dYrgNL61Wh@vbart-laptop> Message-ID: ооо, однако.. спасибо наверно мануал невнимательно читал, но по-моему там этот вопрос не затрагивается... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253239,253265#msg-253265 From nginx-forum at nginx.us Mon Sep 15 23:34:37 2014 From: nginx-forum at nginx.us (den68) Date: Mon, 15 Sep 2014 19:34:37 -0400 Subject: nginx API module #C Message-ID: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> наверно туплю, но в явной форме не нашел, понятно что разумно листать исходники, но тем не-менее по возможности попрошу ссылку. особенно не очень понятно что должен возвращать модуль в случае размещения его в внутри секции map (и вообще это возможно?), я так понимаю что любое выбранное модулем значение.. или есть иные механизмы обработки в общей секции http ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253266#msg-253266 From nginx-forum at nginx.us Tue Sep 16 05:28:05 2014 From: nginx-forum at nginx.us (Violator43) Date: Tue, 16 Sep 2014 01:28:05 -0400 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90YvQuSAkdXBzdHJlYW0gcmVzcG9uc2UgdGltZSDQsiDQu9C+?= =?UTF-8?B?0LPQsNGF?= Message-ID: Сегодня поимел DDoS. Конфигурация access_log у меня такая: "$request_time","$upstream_response_time","$http_host","$remote_addr","$remote_user","$time_local","$request",$status,$body_bytes_sent,"$http_referer","$http_user_agent","$cookie_PHPSESSID","$geoip_country_code" При дедосе в логе сначала было: "60.001","0.000 : 0.000 : 0.000 : 0.000 : 0.000 : 0.000 : 0.000 : 0.000 : 0.000",мой_IP,IP_клиента,"-","16/Sep/2014:07:55:45 +0400","POST / HTTP/1.1",500,0,"-","-","-","DE" потом стало "412.457","172.118 : 0.006 : 180.328 : 0.000 : 0.001 : 0.001 : 0.001 : 0.000 : 0.001",мой_IP,IP_клиента,"-","16/Sep/2014:08:24:32 +0400","POST / HTTP/1.1",500,0,"-","-","-","DE" Содержимое POST запроса залогировать не успел (после первого бана DDoS прекратился). Глянул в старые логи: в течение полугода было аналогичное при некорректных запросах (к несуществующим сайтам, без UserAgent и т.д.). Вопрос, почему в $upstream_response_time при некорректных запросах иногда пишется 9 значений через двоеточие? Версия nginx была 1.6.0 (сразу обновил до 1.6.1), FreeBSD 9.1, бекэндом апач+php. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253267,253267#msg-253267 From nginx-forum at nginx.us Tue Sep 16 05:35:07 2014 From: nginx-forum at nginx.us (Violator43) Date: Tue, 16 Sep 2014 01:35:07 -0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+IFVzZXItQWdlbnQg0LjQu9C4IGlw?= In-Reply-To: References: Message-ID: <1401c45b2a73d0d361db2234cbf1fb85.NginxMailingListRussian@forum.nginx.org> Почему бы не так? if ( $http_user_agent !~ (Opera|Chrome)) { return 403; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253211,253268#msg-253268 From nginx-forum at nginx.us Tue Sep 16 05:40:10 2014 From: nginx-forum at nginx.us (den68) Date: Tue, 16 Sep 2014 01:40:10 -0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+IFVzZXItQWdlbnQg0LjQu9C4IGlw?= In-Reply-To: References: Message-ID: <068b6c4653a7cff2afc5d25b3888e08c.NginxMailingListRussian@forum.nginx.org> map наверное, или ipset (from iptables) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253211,253269#msg-253269 From nginx-forum at nginx.us Tue Sep 16 05:48:32 2014 From: nginx-forum at nginx.us (Violator43) Date: Tue, 16 Sep 2014 01:48:32 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDRgtGMINC/0LXRgNC10LzQtdC90L3Ri9C1ICRodHRwcyDQuCAkc2NoZW1l?= In-Reply-To: References: Message-ID: <5dcc1f44cb78a4fafd767f9faa0f52cf.NginxMailingListRussian@forum.nginx.org> Я так сделал, нужно было чтобы php генерил абсолютные ссылки с учетом схемы: server { listen 80; location / { proxy_pass ... ; ... } } server { listen 443 ssl; location / { proxy_pass ... ; ... proxy_set_header HTTPS on; ... } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,252918,253270#msg-253270 From maxout.mail at gmail.com Tue Sep 16 06:11:25 2014 From: maxout.mail at gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8?=) Date: Tue, 16 Sep 2014 13:11:25 +0700 Subject: =?UTF-8?B?0JrQsNC6INCyIElGINCy0LXRgNC90YPRgtGMINC+0YLQstC10YIg0YEg0L/RgNC+?= =?UTF-8?B?0LjQt9Cy0L7Qu9GM0L3Ri9C8INC60L7QtNC+0Lwg0LjQtyDRhNCw0LnQu9Cw?= Message-ID: Необходимо по условию в location возвращать определённый html-файл с произвольным кодом ответа (в примере 404). Сделал вот так: location / { ..... if ($something) { root /some/path; error_page 404 /404.html; return 404; } ..... } location = /404.html { internal; root /some/path; } Глядя на это, терзаюсь ощущением, что сделал через задницу. Может кто подскажет более элегантное решение, более близкое к location / { ..... if ($something) { return_file 404 /some/path/404.html; } ..... } -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Tue Sep 16 07:09:01 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 16 Sep 2014 11:09:01 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdGL0LkgJHVwc3RyZWFtIHJlc3BvbnNlIHRpbWUg0LIg?= =?UTF-8?B?0LvQvtCz0LDRhQ==?= In-Reply-To: References: Message-ID: <1849761.TmWu8gSsHL@vbart-laptop> On Tuesday 16 September 2014 01:28:05 Violator43 wrote: > Сегодня поимел DDoS. > Конфигурация access_log у меня такая: > "$request_time","$upstream_response_time","$http_host","$remote_addr","$remote_user","$time_local","$request", $status, $body_bytes_sent,"$http_referer","$http_user_agent","$cookie_PHPSESSID","$geoip_country_code" > > При дедосе в логе сначала было: > > "60.001","0.000 : 0.000 : 0.000 : 0.000 : 0.000 : 0.000 : 0.000 : 0.000 : > 0.000",мой_IP,IP_клиента,"-","16/Sep/2014:07:55:45 +0400","POST / > HTTP/1.1",500,0,"-","-","-","DE" > потом стало > "412.457","172.118 : 0.006 : 180.328 : 0.000 : 0.001 : 0.001 : 0.001 : 0.000 > : 0.001",мой_IP,IP_клиента,"-","16/Sep/2014:08:24:32 +0400","POST / > HTTP/1.1",500,0,"-","-","-","DE" > > Содержимое POST запроса залогировать не успел (после первого бана DDoS > прекратился). Глянул в старые логи: в течение полугода было аналогичное при > некорректных запросах (к несуществующим сайтам, без UserAgent и т.д.). > > Вопрос, почему в $upstream_response_time при некорректных запросах иногда > пишется 9 значений через двоеточие? > Версия nginx была 1.6.0 (сразу обновил до 1.6.1), FreeBSD 9.1, бекэндом > апач+php. http://nginx.org/r/$upstream_response_time/ru -- Валентин Бартенев From k.osipov.msk at gmail.com Tue Sep 16 08:09:18 2014 From: k.osipov.msk at gmail.com (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0J7RgdC40L/QvtCy?=) Date: Tue, 16 Sep 2014 12:09:18 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDRgtGMINC/0LXRgNC10LzQtdC90L3Ri9C1ICRodHRwcyDQuCAkc2NoZW1l?= In-Reply-To: <5dcc1f44cb78a4fafd767f9faa0f52cf.NginxMailingListRussian@forum.nginx.org> References: <5dcc1f44cb78a4fafd767f9faa0f52cf.NginxMailingListRussian@forum.nginx.org> Message-ID: Отлично! Спасибо, "proxy_set_header HTTPS" - это то что доктор прописал! Вот что у меня получилось (такой конфиг немного легче поддерживать): server { listen 80; listen 443 ssl; server_name .site.com; ... location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header HTTPS $https; } } 16 сентября 2014 г., 9:48 пользователь Violator43 написал: > Я так сделал, нужно было чтобы php генерил абсолютные ссылки с учетом > схемы: > server { > listen 80; > location / { > proxy_pass ... ; > ... > } > } > server { > listen 443 ssl; > location / { > proxy_pass ... ; > ... > proxy_set_header HTTPS on; > ... > } > } > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,252918,253270#msg-253270 > > _______________________________________________ > 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 stellito at mail.ru Tue Sep 16 09:19:25 2014 From: stellito at mail.ru (=?UTF-8?B?0J/QvtGB0YLQvtCy0LDRgNC+0LIg0J/QsNCy0LXQuw==?=) Date: Tue, 16 Sep 2014 13:19:25 +0400 Subject: pru_attach() failed Message-ID: <1410859165.767538711@f158.i.mail.ru> Добрый день! Извиняюсь, что возможно не совсем по теме рассылки, но нигде не смог найти инфу.  При большой нагрузке (большой кол-во одновременных соединений) в /var/log/messages валится  Sep 12 21:21:40 pl1 kernel: sonewconn: pcb 0xfffffe008aa88498: pru_attach() failed при этом не проходит accept соединения. $ uname -a FreeBSD pl1 9.2-RELEASE FreeBSD 9.2-RELEASE #0: Tue Oct 8 19:08:20 MSK 2013 root at pl1:/usr/obj/usr/src/sys/admin amd64 С чем это может быть связано, может какой-то sysctl надо подкрутить? -- Павел Постоваров -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Sep 16 09:52:03 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Sep 2014 13:52:03 +0400 Subject: nginx API module #C In-Reply-To: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140916095203.GA59236@mdounin.ru> Hello! On Mon, Sep 15, 2014 at 07:34:37PM -0400, den68 wrote: > наверно туплю, но в явной форме не нашел, понятно что разумно листать > исходники, но тем не-менее по возможности попрошу ссылку. > особенно не очень понятно что должен возвращать модуль в случае размещения > его в внутри секции map (и вообще это возможно?), > я так понимаю что любое выбранное модулем значение.. Директива map и её содержимое - реализуется модулем map, встроить какой-либо модуль в неё - нельзя. > или есть иные механизмы обработки в общей секции http ? Смотрите, например, на тот же модуль map. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Tue Sep 16 12:02:30 2014 From: nginx-forum at nginx.us (Violator43) Date: Tue, 16 Sep 2014 08:02:30 -0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdGL0LkgJHVwc3RyZWFtIHJlc3BvbnNlIHRpbWUg0LIg?= =?UTF-8?B?0LvQvtCz0LDRhQ==?= In-Reply-To: <1849761.TmWu8gSsHL@vbart-laptop> References: <1849761.TmWu8gSsHL@vbart-laptop> Message-ID: <88388964e16b9209bae6f48931cc599a.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > http://nginx.org/r/$upstream_response_time/ru Спасибо. Понял что это не ошибка. Для окончательной ясности прошу объяснить, почему именно 9 значений? Откуда у меня взялась группа серверов? На сервере несколько виртуальных хостов, каждый проксируется на свой виртуальный хост апача. Правильно ли я понял, что был специфический http запрос в котором было указано 9 хостов и соотв. nginx послал каждый такой запрос на 9 бэкэндов? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253267,253282#msg-253282 From mdounin at mdounin.ru Tue Sep 16 12:07:05 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Sep 2014 16:07:05 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdGL0LkgJHVwc3RyZWFtIHJlc3BvbnNlIHRpbWUg0LIg?= =?UTF-8?B?0LvQvtCz0LDRhQ==?= In-Reply-To: <88388964e16b9209bae6f48931cc599a.NginxMailingListRussian@forum.nginx.org> References: <1849761.TmWu8gSsHL@vbart-laptop> <88388964e16b9209bae6f48931cc599a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140916120705.GG59236@mdounin.ru> Hello! On Tue, Sep 16, 2014 at 08:02:30AM -0400, Violator43 wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > > http://nginx.org/r/$upstream_response_time/ru > > Спасибо. Понял что это не ошибка. Для окончательной ясности прошу объяснить, > почему именно 9 значений? Откуда у меня взялась группа серверов? На сервере > несколько виртуальных хостов, каждый проксируется на свой виртуальный хост > апача. Правильно ли я понял, что был специфический http запрос в котором > было указано 9 хостов и соотв. nginx послал каждый такой запрос на 9 > бэкэндов? Двоеточие означает, что между обращениями к upstream'ам было внутреннее перенаправление. Вероятнее всего, у вас включена рекурсивная обработка ошибок, и error_page циклится. Ну и я просто оставлю эту ссылку здесь: http://bash.im/quote/426440 -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Tue Sep 16 14:46:30 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Sep 2014 18:46:30 +0400 Subject: nginx-1.7.5 Message-ID: <20140916144630.GJ59236@mdounin.ru> Изменения в nginx 1.7.5 16.09.2014 *) Безопасность: при использовании общего для нескольких блоков server разделяемого кэша SSL-сессий или общего ключа для шифрования TLS session tickets было возможно повторно использовать SSL-сессию в контексте другого блока server (CVE-2014-3616). Спасибо Antoine Delignat-Lavaud. *) Изменение: директиву stub_status теперь можно указывать без параметров. *) Добавление: параметр always директивы add_header. *) Добавление: директивы proxy_next_upstream_tries, proxy_next_upstream_timeout, fastcgi_next_upstream_tries, fastcgi_next_upstream_timeout, memcached_next_upstream_tries, memcached_next_upstream_timeout, scgi_next_upstream_tries, scgi_next_upstream_timeout, uwsgi_next_upstream_tries и uwsgi_next_upstream_timeout. *) Исправление: в параметре if директивы access_log. *) Исправление: в модуле ngx_http_perl_module. Спасибо Piotr Sikora. *) Исправление: директива listen почтового прокси-сервера не позволяла указать более двух параметров. *) Исправление: директива sub_filter не работала с заменяемой строкой из одного символа. *) Исправление: запросы могли зависать, если использовался resolver и в процессе обращения к DNS-серверу происходил таймаут. *) Исправление: в модуле ngx_http_spdy_module при использовании совместно с AIO. *) Исправление: в рабочем процессе мог произойти segmentation fault, если с помощью директивы set изменялись переменные "$http_...", "$sent_http_..." или "$upstream_http_...". *) Исправление: в обработке ошибок выделения памяти. Спасибо Markus Linnala и Feng Gu. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue Sep 16 14:47:02 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Sep 2014 18:47:02 +0400 Subject: nginx-1.6.2 Message-ID: <20140916144702.GN59236@mdounin.ru> Изменения в nginx 1.6.2 16.09.2014 *) Безопасность: при использовании общего для нескольких блоков server разделяемого кэша SSL-сессий или общего ключа для шифрования TLS session tickets было возможно повторно использовать SSL-сессию в контексте другого блока server (CVE-2014-3616). Спасибо Antoine Delignat-Lavaud. *) Исправление: запросы могли зависать, если использовался resolver и DNS-сервер возвращал некорректный ответ; ошибка появилась в 1.5.8. *) Исправление: запросы могли зависать, если использовался resolver и в процессе обращения к DNS-серверу происходил таймаут. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue Sep 16 14:47:25 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Sep 2014 18:47:25 +0400 Subject: nginx security advisory (CVE-2014-3616) Message-ID: <20140916144725.GR59236@mdounin.ru> Hello! Antoine Delignat-Lavaud обнаружил проблему в кэшировании SSL-сессий в nginx. Было возможно повторно использовать SSL-сессию в контексте другого блока server{}, что позволяло атакующему, контролирующему канал между клиентом и nginx'ом, вызывать обработку запросов в неправильном блоке server{} (CVE-2014-3616). Проблеме подвержен nginx 0.5.6 - 1.7.4, если в нескольких блоках server{} используется один и тот же разделяемый ssl_session_cache и/или ssl_session_ticket_key. Проблема исправлена в nginx 1.7.5, 1.6.2. Более подробную информацию можно найти в статье Antoine Delignat-Lavaud et al., доступной по адресу http://bh.ht.vc/vhost_confusion.pdf. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Sep 17 06:10:57 2014 From: nginx-forum at nginx.us (den68) Date: Wed, 17 Sep 2014 02:10:57 -0400 Subject: nginx API module #C In-Reply-To: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> Message-ID: спасибо, а описания апи я так понимаю нет? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253326#msg-253326 From nginx-forum at nginx.us Wed Sep 17 08:25:08 2014 From: nginx-forum at nginx.us (Nikolay) Date: Wed, 17 Sep 2014 04:25:08 -0400 Subject: map uri fastcgi_pass Message-ID: <478df99d56c6a5cf026ed02f4c9d5049.NginxMailingListRussian@forum.nginx.org> Здравствуйте, есть задача: перенаправить запрос c uri вида /some/path/03_dfsakfa на бекенд server03.domain.tld с номером 03(берется из uri). Все остальные запросы надо отправлять на upstream fpm. OS Debian 7.6 nginx version: nginx/1.2.1 При перезапуске nginx получаю ошибку: Restarting nginx: nginx: [emerg] invalid number of the map parameters in /etc/nginx/nginx.conf Подскажите, что я делаю неправильно, где ошибка? nginx.conf http { ... ... upstream fpm { server 1.1.1.1:9001; server 2.2.2.2:9001; } map $uri $back { default "fpm"; ~*"/some/path/(?^\d{2})$(.+)$" server$key\.domain\.tld; } ... ... server { ... location / { root /some/path; if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?$args last; break; } location ~ \.php$ { include fastcgi_params; root /some/path; fastcgi_pass $back; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253340,253340#msg-253340 From vbart at nginx.com Wed Sep 17 08:47:05 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 17 Sep 2014 12:47:05 +0400 Subject: map uri fastcgi_pass In-Reply-To: <478df99d56c6a5cf026ed02f4c9d5049.NginxMailingListRussian@forum.nginx.org> References: <478df99d56c6a5cf026ed02f4c9d5049.NginxMailingListRussian@forum.nginx.org> Message-ID: <2315858.WhYc17DBEu@vbart-laptop> On Wednesday 17 September 2014 04:25:08 Nikolay wrote: > Здравствуйте, есть задача: перенаправить запрос c uri вида > /some/path/03_dfsakfa на бекенд server03.domain.tld с номером 03(берется из > uri). > Все остальные запросы надо отправлять на upstream fpm. > > OS Debian 7.6 > nginx version: nginx/1.2.1 > > При перезапуске nginx получаю ошибку: > Restarting nginx: nginx: [emerg] invalid number of the map parameters in > /etc/nginx/nginx.conf > > Подскажите, что я делаю неправильно, где ошибка? > > nginx.conf > > http { > ... > ... > upstream fpm { > server 1.1.1.1:9001; > server 2.2.2.2:9001; > } > > map $uri $back { > default "fpm"; > ~*"/some/path/(?^\d{2})$(.+)$" server$key\.domain\.tld; > > } [..] Только в этом месте их сразу три: 1. /some/path/(?^\d{2})$(.+)$ - не похоже на правильное регулярное выражение. Вероятно хотелось этого: ^/some/path/(?\d{2})_.+$ 2. Чтобы экранировать строку с { } - необходимо её всю брать в кавычки: "~*^/some/path/(?\d{2})_.+$" а не только часть. 3. Внутри блока map во второй части может находится только одна переменная, а не строка: server$key\.domain\.tld Читайте http://nginx.org/r/map/ru А самое главное, это чрезвычайно странный способ решения проблемы. Правильнее будет как-то так: location ~* "^/some/path/(?\d{2})_.+$" { fastcgi_pass server$key\.domain\.tld; ... } -- Валентин Бартенев From nginx-forum at nginx.us Wed Sep 17 09:37:54 2014 From: nginx-forum at nginx.us (Nikolay) Date: Wed, 17 Sep 2014 05:37:54 -0400 Subject: map uri fastcgi_pass In-Reply-To: <2315858.WhYc17DBEu@vbart-laptop> References: <2315858.WhYc17DBEu@vbart-laptop> Message-ID: Большое спасибо, вы очень помогли. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253340,253343#msg-253343 From mdounin at mdounin.ru Wed Sep 17 12:19:31 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 17 Sep 2014 16:19:31 +0400 Subject: nginx API module #C In-Reply-To: References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140917121931.GB91749@mdounin.ru> Hello! On Wed, Sep 17, 2014 at 02:10:57AM -0400, den68 wrote: > спасибо, а описания апи я так понимаю нет? Формального - нет. Имеет смысл почитать статьи по ссылкам тут: http://nginx.org/en/links.html -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Sep 17 14:38:49 2014 From: nginx-forum at nginx.us (ole-lukoje) Date: Wed, 17 Sep 2014 10:38:49 -0400 Subject: epoll_wait() reported that client prematurely closed connection Message-ID: <9981f3462a6c0ea963e4012c1a3c2c5c.NginxMailingListRussian@forum.nginx.org> Здравствуйте. При увеличении количества запросов с клиента на nginx в error.log отображаются сообщения: epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too (32: Broken pipe) while reading upstream Передача осуществляется png файлов размером от 120-80000 байт. Основные настройки: worker_processes 8; events { worker_connections 25000; use epoll; } keepalive_timeout 45 45; keepalive_requests 100; proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; client_max_body_size 1m; client_body_buffer_size 128k; client_body_timeout 45; send_timeout 45; Пытался решить установкой параметра proxy_ignore_client_abort on, однако, к моему удивлению, не помогло... Подскажите, пожалуйста, как можно устранить данную проблему. Спасибо. (используется кластер проксируемых серверов, но добавить нету возможности;увеличить timeout со стороны клиентского js-приложения также нельзя). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253351,253351#msg-253351 From vbart at nginx.com Wed Sep 17 15:12:31 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 17 Sep 2014 19:12:31 +0400 Subject: epoll_wait() reported that client prematurely closed connection In-Reply-To: <9981f3462a6c0ea963e4012c1a3c2c5c.NginxMailingListRussian@forum.nginx.org> References: <9981f3462a6c0ea963e4012c1a3c2c5c.NginxMailingListRussian@forum.nginx.org> Message-ID: <1837751.vRkCq1H3CD@vbart-workstation> On Wednesday 17 September 2014 10:38:49 ole-lukoje wrote: > Здравствуйте. > При увеличении количества запросов с клиента на nginx в error.log > отображаются сообщения: > > epoll_wait() reported that client prematurely closed connection, so upstream > connection is closed too while sending request to upstream, > epoll_wait() reported that client prematurely closed connection, so upstream > connection is closed too (32: Broken pipe) while reading upstream > > Передача осуществляется png файлов размером от 120-80000 байт. > > Основные настройки: > > worker_processes 8; > events { > worker_connections 25000; > use epoll; > } > keepalive_timeout 45 45; > keepalive_requests 100; > > proxy_connect_timeout 60s; > proxy_send_timeout 60s; > proxy_read_timeout 60s; > > client_max_body_size 1m; > client_body_buffer_size 128k; > client_body_timeout 45; > send_timeout 45; > > Пытался решить установкой параметра proxy_ignore_client_abort on, однако, к > моему удивлению, не помогло... > > Подскажите, пожалуйста, как можно устранить данную проблему. Спасибо. > (используется кластер проксируемых серверов, но добавить нету > возможности;увеличить timeout со стороны клиентского js-приложения также > нельзя). > В чем заключается проблема? Указанные сообщения сами по себе не являются проблемой. Версия nginx? ОС? Настройки помимо "основных"? -- Валентин Бартенев From nginx-forum at nginx.us Thu Sep 18 05:49:13 2014 From: nginx-forum at nginx.us (ole-lukoje) Date: Thu, 18 Sep 2014 01:49:13 -0400 Subject: epoll_wait() reported that client prematurely closed connection In-Reply-To: <1837751.vRkCq1H3CD@vbart-workstation> References: <1837751.vRkCq1H3CD@vbart-workstation> Message-ID: <5af1f346241d204015d79ca32d301385.NginxMailingListRussian@forum.nginx.org> Проблема в том, что на проксируемом сервере происходят ошибки типа "An exception occured writing the response entity. Broken pipe", их нужно устранить. По всей видимости они возникают из-за того, что nginx рвет соединение с проксируемым сервером, не уверены что это не будет приводить к утечкам памяти в следствии такого типа завершения соединения. CentOS release 6.5 Linux version 2.6.32-431.el6.x86_64 nginx/1.5.8 Содержимое файла конфигурации: user nginx; worker_processes 8; timer_resolution 100ms; worker_rlimit_nofile 50000; worker_priority -5; error_log /var/log/nginx/error.log info; pid /var/run/nginx.pid; events { worker_connections 25000; use epoll; } http { include mime.types; default_type application/x-javascript; log_format main '$remote_addr - $remote_user [$time_local] $request ' '"$status" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; chunked_transfer_encoding off; gzip on; gzip_static on; gzip_min_length 640; gzip_buffers 64 8k; gzip_comp_level 4; gzip_http_version 1.1; gzip_proxied any; gzip_types text/plain application/xml application/x-javascript text/css; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; gzip_vary on; output_buffers 32 512k; sendfile_max_chunk 128k; postpone_output 1460; server_names_hash_bucket_size 64; tcp_nopush on; tcp_nodelay on; client_max_body_size 1m; client_body_buffer_size 128k; client_header_buffer_size 1k; large_client_header_buffers 4 4k; keepalive_timeout 45 45; client_header_timeout 45; client_body_timeout 45; send_timeout 45; reset_timedout_connection on; memcached_connect_timeout 60s; memcached_read_timeout 60s; memcached_send_timeout 60s; charset utf-8; source_charset utf-8; ignore_invalid_headers on; keepalive_requests 100; recursive_error_pages off; server_tokens off; server_name_in_redirect off; sendfile on; open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; ####################################################################### # PUSH_STREAM_MODULE GLOBAL SETTINGS (COMET) ####################################################################### #The size of the memory chunk this module will use to store published messages, #channels and other shared structures. When this memory is full any new request #for publish a message or subscribe a channel will receive an 500 Internal Server Error response. push_stream_shared_memory_size 100M; #Maximum permissible channel id length (number of characters). #Longer ids will receive an 400 Bad Request response. I push_stream_max_channel_id_length 50; #The length of time a subscriber will stay connected before it is considered expired and disconnected. #If you do not want subscribers to be automatically disconnected, just not set this directive. #But, this operation is very important to help Nginx recycle memory consumed to send messages to susbscriber, #allocated at pool request. push_stream_subscriber_connection_ttl 5m; push_stream_longpolling_connection_ttl 5m; push_stream_wildcard_channel_prefix "broadcast_"; proxy_cache_path /var/cache/nginx/ftl levels=1:2 keys_zone=ftl-cache:20m max_size=100m inactive=120m; upstream memcached_cluster { server 127.0.0.1:11211; hash $uri/3.8; hash_again 1000; keepalive 512; } server { listen *:80; server_name_in_redirect off; server_name test.example.com; proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; proxy_buffering on; proxy_buffer_size 64k; proxy_buffers 4 64k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 10m; proxy_headers_hash_bucket_size 256; proxy_set_header Host $host:$server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; access_log /var/log/nginx/nginx.log main; log_not_found off; root /var/spool/nginx/; location /portal-facade-ng/v1/btv/imageMap/ { if ($request_method != GET) { proxy_pass http://127.0.0.1:8080; break; } add_header Cache-Control no-cache; add_header Content-Type image/png; default_type image/png; set $memcached_key "$uri/3.8"; memcached_pass memcached_cluster; } location /portal-facade-ng/v1/btv/epg/current/ { if ($request_method != GET) { proxy_pass http://127.0.0.1:8080; break; } set $memcached_key "$uri/3.8"; memcached_pass memcached_cluster; } location /portal-facade-ng/v1/btv/epgGrid/bar/image/ { if ($request_method != GET) { proxy_pass http://127.0.0.1:8080; break; } add_header Cache-Control no-cache; add_header Content-Type image/png; default_type image/png; set $memcached_key "$uri/3.8"; memcached_pass memcached_cluster; } } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253351,253363#msg-253363 From vadim.lazovskiy at gmail.com Thu Sep 18 06:01:55 2014 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 18 Sep 2014 10:01:55 +0400 Subject: epoll_wait() reported that client prematurely closed connection In-Reply-To: <5af1f346241d204015d79ca32d301385.NginxMailingListRussian@forum.nginx.org> References: <1837751.vRkCq1H3CD@vbart-workstation> <5af1f346241d204015d79ca32d301385.NginxMailingListRussian@forum.nginx.org> Message-ID: Здравствуйте. По умолчанию, если клиент закрывает соединение, то соответствующее соединение к апстриму тоже закрывается. Если очень нужно, можно попробовать proxy_ignore_client_abort on; http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort 2014-09-18 9:49 GMT+04:00 ole-lukoje : > Проблема в том, что на проксируемом сервере происходят ошибки типа "An > exception occured writing the response entity. Broken pipe", их нужно > устранить. > По всей видимости они возникают из-за того, что nginx рвет соединение с > проксируемым сервером, не уверены что это не будет приводить к утечкам > памяти в следствии > такого типа завершения соединения. > > CentOS release 6.5 > Linux version 2.6.32-431.el6.x86_64 > nginx/1.5.8 > > Содержимое файла конфигурации: > > user nginx; > > worker_processes 8; > timer_resolution 100ms; > worker_rlimit_nofile 50000; > worker_priority -5; > > error_log /var/log/nginx/error.log info; > pid /var/run/nginx.pid; > > events { > worker_connections 25000; > use epoll; > } > > http { > > include mime.types; > default_type application/x-javascript; > > log_format main '$remote_addr - $remote_user [$time_local] $request ' > '"$status" $body_bytes_sent "$http_referer" ' > '"$http_user_agent" "$http_x_forwarded_for"'; > > chunked_transfer_encoding off; > > gzip on; > gzip_static on; > gzip_min_length 640; > gzip_buffers 64 8k; > gzip_comp_level 4; > gzip_http_version 1.1; > gzip_proxied any; > gzip_types text/plain application/xml application/x-javascript > text/css; > gzip_disable "MSIE [1-6]\.(?!.*SV1)"; > gzip_vary on; > > output_buffers 32 512k; > sendfile_max_chunk 128k; > postpone_output 1460; > server_names_hash_bucket_size 64; > > tcp_nopush on; > tcp_nodelay on; > > client_max_body_size 1m; > client_body_buffer_size 128k; > client_header_buffer_size 1k; > large_client_header_buffers 4 4k; > > keepalive_timeout 45 45; > client_header_timeout 45; > client_body_timeout 45; > send_timeout 45; > reset_timedout_connection on; > > memcached_connect_timeout 60s; > memcached_read_timeout 60s; > memcached_send_timeout 60s; > > charset utf-8; > source_charset utf-8; > ignore_invalid_headers on; > keepalive_requests 100; > recursive_error_pages off; > server_tokens off; > server_name_in_redirect off; > sendfile on; > > open_file_cache max=1000 inactive=20s; > open_file_cache_valid 30s; > open_file_cache_min_uses 2; > open_file_cache_errors on; > > ####################################################################### > # PUSH_STREAM_MODULE GLOBAL SETTINGS (COMET) > ####################################################################### > > #The size of the memory chunk this module will use to store published > messages, > #channels and other shared structures. When this memory is full any new > request > #for publish a message or subscribe a channel will receive an 500 > Internal Server Error response. > push_stream_shared_memory_size 100M; > > #Maximum permissible channel id length (number of characters). > #Longer ids will receive an 400 Bad Request response. I > push_stream_max_channel_id_length 50; > > #The length of time a subscriber will stay connected before it is > considered expired and disconnected. > #If you do not want subscribers to be automatically disconnected, just > not set this directive. > #But, this operation is very important to help Nginx recycle memory > consumed to send messages to susbscriber, > #allocated at pool request. > push_stream_subscriber_connection_ttl 5m; > push_stream_longpolling_connection_ttl 5m; > > push_stream_wildcard_channel_prefix "broadcast_"; > proxy_cache_path /var/cache/nginx/ftl levels=1:2 > keys_zone=ftl-cache:20m max_size=100m inactive=120m; > > upstream memcached_cluster { > server 127.0.0.1:11211; > hash $uri/3.8; > hash_again 1000; > keepalive 512; > } > > server { > listen *:80; > server_name_in_redirect off; > server_name test.example.com; > > proxy_connect_timeout 60s; > proxy_send_timeout 60s; > proxy_read_timeout 60s; > > proxy_buffering on; > proxy_buffer_size 64k; > proxy_buffers 4 64k; > proxy_busy_buffers_size 128k; > proxy_temp_file_write_size 10m; > proxy_headers_hash_bucket_size 256; > > proxy_set_header Host $host:$server_port; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > access_log /var/log/nginx/nginx.log main; > log_not_found off; > root /var/spool/nginx/; > > location /portal-facade-ng/v1/btv/imageMap/ { > if ($request_method != GET) { > proxy_pass http://127.0.0.1:8080; > break; > } > > add_header Cache-Control no-cache; > add_header Content-Type image/png; > default_type image/png; > set $memcached_key "$uri/3.8"; > memcached_pass memcached_cluster; > } > > > location /portal-facade-ng/v1/btv/epg/current/ { > if ($request_method != GET) { > proxy_pass http://127.0.0.1:8080; > break; > } > set $memcached_key "$uri/3.8"; > memcached_pass memcached_cluster; > } > > location /portal-facade-ng/v1/btv/epgGrid/bar/image/ { > if ($request_method != GET) { > proxy_pass http://127.0.0.1:8080; > break; > } > > add_header Cache-Control no-cache; > add_header Content-Type image/png; > default_type image/png; > set $memcached_key "$uri/3.8"; > memcached_pass memcached_cluster; > } > } > } > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253351,253363#msg-253363 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR, Vadim Lazovskiy From nginx-forum at nginx.us Thu Sep 18 07:03:26 2014 From: nginx-forum at nginx.us (ole-lukoje) Date: Thu, 18 Sep 2014 03:03:26 -0400 Subject: epoll_wait() reported that client prematurely closed connection In-Reply-To: References: Message-ID: Здравствуйте, спасибо, что откликнулись. Я в самом первом посте писал "Пытался решить установкой параметра proxy_ignore_client_abort on, однако, к моему удивлению, не помогло..." :) ставил как на уровень всего сервера так и на уровень отдельных локаций. Не могу понять, что делаю не так, что директива не срабатывает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253351,253365#msg-253365 From vbart at nginx.com Thu Sep 18 08:17:04 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 18 Sep 2014 12:17:04 +0400 Subject: epoll_wait() reported that client prematurely closed connection In-Reply-To: <5af1f346241d204015d79ca32d301385.NginxMailingListRussian@forum.nginx.org> References: <1837751.vRkCq1H3CD@vbart-workstation> <5af1f346241d204015d79ca32d301385.NginxMailingListRussian@forum.nginx.org> Message-ID: <1877988.8FC5CJobgv@vbart-laptop> On Thursday 18 September 2014 01:49:13 ole-lukoje wrote: > Проблема в том, что на проксируемом сервере происходят ошибки типа "An > exception occured writing the response entity. Broken pipe", их нужно > устранить. > По всей видимости они возникают из-за того, что nginx рвет соединение с > проксируемым сервером, не уверены что это не будет приводить к утечкам > памяти в следствии такого типа завершения соединения. Тогда директива proxy_ignore_client_abort вам не поможет. Она лишь контролирует, должен ли nginx отслеживать закрытие соединения клиентом до начала передачи данных. Должно помочь включение proxy_store. > > CentOS release 6.5 > Linux version 2.6.32-431.el6.x86_64 > nginx/1.5.8 > Антиквариат. -- Валентин Бартенев From nginx-forum at nginx.us Thu Sep 18 13:50:59 2014 From: nginx-forum at nginx.us (den68) Date: Thu, 18 Sep 2014 09:50:59 -0400 Subject: nginx API module #C In-Reply-To: <20140917121931.GB91749@mdounin.ru> References: <20140917121931.GB91749@mdounin.ru> Message-ID: еще раз спасибо, если не затруднит, конструкции ngx_string("имя_переменной") - вилкарды понимают? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253388#msg-253388 From mdounin at mdounin.ru Thu Sep 18 14:14:06 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Sep 2014 18:14:06 +0400 Subject: nginx API module #C In-Reply-To: References: <20140917121931.GB91749@mdounin.ru> Message-ID: <20140918141406.GS91749@mdounin.ru> Hello! On Thu, Sep 18, 2014 at 09:50:59AM -0400, den68 wrote: > еще раз спасибо, > если не затруднит, конструкции ngx_string("имя_переменной") - вилкарды > понимают? Конструкция ngx_string("...") задаёт инициализатор для строки типа ngx_str_t, и вообще ничего не понимает. Use the Source, Luke! http://hg.nginx.org/nginx/file/106a8bfa4f42/src/core/ngx_string.h#l40 -- Maxim Dounin http://nginx.org/ From citrin at citrin.ru Fri Sep 19 10:26:20 2014 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Fri, 19 Sep 2014 14:26:20 +0400 Subject: pru_attach() failed In-Reply-To: <1410859165.767538711@f158.i.mail.ru> References: <1410859165.767538711@f158.i.mail.ru> Message-ID: <541C04CC.7010706@citrin.ru> On 09/16/14 13:19, Постоваров Павел wrote: > > Извиняюсь, что возможно не совсем по теме рассылки, но нигде не смог найти инфу. > > При большой нагрузке (большой кол-во одновременных соединений) в > /var/log/messages валится > Sep 12 21:21:40 pl1 kernel: sonewconn: pcb 0xfffffe008aa88498: pru_attach() failed Можно: 1. Почитать исходники. 2. Использовать Dtrace (для начала посмотреть какую ошибку возвращает pru_attach - в случаае tcp это tcp_usr_attach). Но проще всего сделать так, чтобы сообщения с уровнем debug не писались в /var/log/messages :) Если в логах nginx при этом ошибок нет, то это сообщение скорее всего можно игнорировать. From mdounin at mdounin.ru Fri Sep 19 12:35:51 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 19 Sep 2014 16:35:51 +0400 Subject: pru_attach() failed In-Reply-To: <541C04CC.7010706@citrin.ru> References: <1410859165.767538711@f158.i.mail.ru> <541C04CC.7010706@citrin.ru> Message-ID: <20140919123551.GX91749@mdounin.ru> Hello! On Fri, Sep 19, 2014 at 02:26:20PM +0400, Anton Yuzhaninov wrote: > On 09/16/14 13:19, Постоваров Павел wrote: > > > >Извиняюсь, что возможно не совсем по теме рассылки, но нигде не смог найти инфу. > > > >При большой нагрузке (большой кол-во одновременных соединений) в > >/var/log/messages валится > >Sep 12 21:21:40 pl1 kernel: sonewconn: pcb 0xfffffe008aa88498: pru_attach() failed > > Можно: > 1. Почитать исходники. > 2. Использовать Dtrace (для начала посмотреть какую ошибку возвращает > pru_attach - в случаае tcp это tcp_usr_attach). > > Но проще всего сделать так, чтобы сообщения с уровнем debug не писались в > /var/log/messages :) > > Если в логах nginx при этом ошибок нет, то это сообщение скорее всего можно > игнорировать. Ну соединение-то так или иначе померло, даже если и не дошло до nginx'а и лишь тихо посчиталось в каких-нибудь listen queue overflows в "netstat -s". Упираться, там, насколько я понимаю, можно в tcp_inpcb, tcpcb, или в sbsize limit. Первые два - покажет "vmstat -z", а последний - обычно не выставлен. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Fri Sep 19 13:52:53 2014 From: nginx-forum at nginx.us (ole-lukoje) Date: Fri, 19 Sep 2014 09:52:53 -0400 Subject: epoll_wait() reported that client prematurely closed connection In-Reply-To: <1877988.8FC5CJobgv@vbart-laptop> References: <1877988.8FC5CJobgv@vbart-laptop> Message-ID: <889e96f09531c9627abf1861041cb040.NginxMailingListRussian@forum.nginx.org> Валентин, скажите, а почему директива proxy_ignore_client_abort не поможет ? Как я понял, она служит для того, чтобы гарантировать, что nginx не будет разрывать соединение с проксируемым сервером, если клиент по какой-то причине разорвал соединение с nginx. Почему она не помогает ? (и кстати да, при включении создается ощущение, что она никак вообще не влияет на процесс). Я proxy_store не использовал, но она, вроде, позволяет сохранять ответ от прокс. сервера в файле (или если файл получили, то сохранять файл) в кэше. НО тут есть 2 момент, проксируемый сервер выдает картинки (которые он получает от других серверов, делает некоторые манипуляции), и картинка под одним и тем же именем может представлять разные изображения, поэтому, видимо, proxy_store использовать нельзя. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253351,253417#msg-253417 From stellito at mail.ru Fri Sep 19 14:21:10 2014 From: stellito at mail.ru (=?UTF-8?B?0J/QvtGB0YLQvtCy0LDRgNC+0LIg0J/QsNCy0LXQuw==?=) Date: Fri, 19 Sep 2014 18:21:10 +0400 Subject: pru_attach() failed In-Reply-To: <541C04CC.7010706@citrin.ru> References: <1410859165.767538711@f158.i.mail.ru> <541C04CC.7010706@citrin.ru> Message-ID: <1411136470.557726069@f387.i.mail.ru> Когда обнаружил, что pru_attach это указатель, искать чему он равен в данном случае желание пропало:) Спасибо за инфу про tcp_usr_attach. В этом случае соединение сбрасывается с RST флагом, так что отключение логов вряд ли поможет горю :) Fri, 19 Sep 2014 14:26:20 +0400 от Anton Yuzhaninov : >On 09/16/14 13:19, Постоваров Павел wrote: >> >> Извиняюсь, что возможно не совсем по теме рассылки, но нигде не смог найти инфу. >> >> При большой нагрузке (большой кол-во одновременных соединений) в >> /var/log/messages валится >> Sep 12 21:21:40 pl1 kernel: sonewconn: pcb 0xfffffe008aa88498: pru_attach() failed > >Можно: >1. Почитать исходники. >2. Использовать Dtrace (для начала посмотреть какую ошибку возвращает pru_attach >- в случаае tcp это tcp_usr_attach). > >Но проще всего сделать так, чтобы сообщения с уровнем debug не писались в >/var/log/messages :) > >Если в логах 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 vbart at nginx.com Fri Sep 19 14:21:22 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 19 Sep 2014 18:21:22 +0400 Subject: epoll_wait() reported that client prematurely closed connection In-Reply-To: <889e96f09531c9627abf1861041cb040.NginxMailingListRussian@forum.nginx.org> References: <1877988.8FC5CJobgv@vbart-laptop> <889e96f09531c9627abf1861041cb040.NginxMailingListRussian@forum.nginx.org> Message-ID: <1513259.TMtFkWvXjD@vbart-laptop> On Friday 19 September 2014 09:52:53 ole-lukoje wrote: > Валентин, скажите, а почему директива proxy_ignore_client_abort не поможет ? > Как я понял, она служит для того, чтобы гарантировать, что nginx не будет > разрывать соединение с проксируемым сервером, если клиент по какой-то > причине разорвал соединение с nginx. Почему она не помогает ? (и кстати да, > при включении создается ощущение, что она никак вообще не влияет на > процесс). Как уже написал в предыдущем письме, она влияет лишь на отслеживание закрытия соединения до начала передачи ответа. Если клиент закрыл соединения после начала передачи ответа, то соединение с бэкендом будет закрыто также, вне зависимости от значение директивы, за исключением случаев, когда нужно сохранить ответ в кэш или в файл. Директива proxy_ignore_client_abort нужна в одном из следующих случаев: 1. Для совместимости с клиентами, которые делают SHUT_WR на соединении после отправки запроса; 2. Когда бэкенд не отслеживает закрытие соединения во время обработки запроса, а вы используете limit_conn и хотите чтобы модуль продолжал учитывать этот запрос до тех пор, пока бекенд не сформирует ответ и не начнет его отдавать; 3. Когда бэкенд отслеживает закрытие соединения, но, по тем или иным причинам, вы не хотите чтобы это происходило до начала передачи ответа. Как видите, ни один из них не гарантирует того, что nginx не будет закрывать соединение уже после начала передачи ответа. > > Я proxy_store не использовал, но она, вроде, позволяет сохранять ответ от > прокс. сервера в файле (или если файл получили, то сохранять файл) в кэше. > > > НО тут есть 2 момент, > проксируемый сервер выдает картинки (которые он получает от других > серверов, делает некоторые манипуляции), > и картинка под одним и тем же именем может представлять разные > изображения, > поэтому, видимо, proxy_store использовать нельзя. Я не предлагал вам сохранять файл для последующего использования. Сохранять вы его можете хоть в /dev/null, просто nginx в этом случае не будет закрывать соединение с бэкендом, пока не получит ответ целиком. Если вы в самом деле планируете использовать кэш, то и проблемы у вас быть не должно. -- Валентин Бартенев From stellito at mail.ru Fri Sep 19 14:23:24 2014 From: stellito at mail.ru (=?UTF-8?B?0J/QvtGB0YLQvtCy0LDRgNC+0LIg0J/QsNCy0LXQuw==?=) Date: Fri, 19 Sep 2014 18:23:24 +0400 Subject: pru_attach() failed In-Reply-To: <20140919123551.GX91749@mdounin.ru> References: <1410859165.767538711@f158.i.mail.ru> <541C04CC.7010706@citrin.ru> <20140919123551.GX91749@mdounin.ru> Message-ID: <1411136604.540166392@f402.i.mail.ru> Спасибо, уже нашел что действительно уперлись в tcp_inpcb. Fri, 19 Sep 2014 16:35:51 +0400 от Maxim Dounin : >Hello! > >On Fri, Sep 19, 2014 at 02:26:20PM +0400, Anton Yuzhaninov wrote: > >> On 09/16/14 13:19, Постоваров Павел wrote: >> > >> >Извиняюсь, что возможно не совсем по теме рассылки, но нигде не смог найти инфу. >> > >> >При большой нагрузке (большой кол-во одновременных соединений) в >> >/var/log/messages валится >> >Sep 12 21:21:40 pl1 kernel: sonewconn: pcb 0xfffffe008aa88498: pru_attach() failed >> >> Можно: >> 1. Почитать исходники. >> 2. Использовать Dtrace (для начала посмотреть какую ошибку возвращает >> pru_attach - в случаае tcp это tcp_usr_attach). >> >> Но проще всего сделать так, чтобы сообщения с уровнем debug не писались в >> /var/log/messages :) >> >> Если в логах nginx при этом ошибок нет, то это сообщение скорее всего можно >> игнорировать. > >Ну соединение-то так или иначе померло, даже если и не дошло до >nginx'а и лишь тихо посчиталось в каких-нибудь listen queue >overflows в "netstat -s". > >Упираться, там, насколько я понимаю, можно в tcp_inpcb, tcpcb, или >в sbsize limit. Первые два - покажет "vmstat -z", а последний - >обычно не выставлен. > >-- >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 nginx-forum at nginx.us Sat Sep 20 08:13:31 2014 From: nginx-forum at nginx.us (den68) Date: Sat, 20 Sep 2014 04:13:31 -0400 Subject: nginx API module #C In-Reply-To: <20140918141406.GS91749@mdounin.ru> References: <20140918141406.GS91749@mdounin.ru> Message-ID: Спасибо, познавательно. а можно получить доступ к описанным в конфиге бекендам? и бакенд может быть UDP ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253437#msg-253437 From sergeyk at jfrog.com Sun Sep 21 06:18:30 2014 From: sergeyk at jfrog.com (Sergey Kagansky) Date: Sun, 21 Sep 2014 09:18:30 +0300 Subject: nginx-ru Digest, Vol 59, Issue 13 In-Reply-To: References: Message-ID: Как я понимаю, geo может быть использован только в контексте http В моём случае есть сотни виртуальных хостов у каждого свой список разрешённых IP и юзер-агентов. Есть ли решение для такого случая? 2014-09-14 15:03 GMT+03:00 Sergey Kagansky : > Огромное спасибо! > > > 2014-09-13 15:00 GMT+03:00 : > >> Сообщения, предназначенные для списка рассылки 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: nginx-ru Digest, Vol 59, Issue 12 (Sergey Kagansky) >> 2. Re: nginx-ru Digest, Vol 59, Issue 12 (Daniel Podolsky) >> >> >> ---------- Forwarded message ---------- >> From: Sergey Kagansky >> To: nginx-ru >> Cc: >> Date: Fri, 12 Sep 2014 15:10:01 +0300 >> Subject: Re: nginx-ru Digest, Vol 59, Issue 12 >> А можно map хранить в отдельных файлах и подключать через include? >> >> >> 2014-09-12 15:00 GMT+03:00 : >> >>> Сообщения, предназначенные для списка рассылки 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: Доступ по User-Agent или ip (Anton Sayetsky) >>> 2. Re: Доступ по User-Agent или ip (Oleksandr V. Typlyns'kyi) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Anton Sayetsky >>> To: nginx-ru at nginx.org >>> Cc: >>> Date: Fri, 12 Sep 2014 13:19:03 +0300 >>> Subject: Re: Доступ по User-Agent или ip >>> http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy >>> >>> 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky >>> написал: >>> > Добрый день. >>> > У меня есть такая конфигурация: >>> > >>> > >>> > >>> > location /test { >>> > include list.ips; >>> > proxy_pass http://127.0.0.1; >>> > } >>> > >>> > В файле list.ips содержится список разрешённых IPs в конце файла deny >>> all; >>> > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в >>> > дополнение к списку адресов. >>> > >>> > Пробовал инклюд в if - не работает >>> > Пробовал инклюд с переменной - не работает >>> > Как то это можно реализовать? >>> > Заранее благодарен за советы. >>> > >>> > _______________________________________________ >>> > nginx-ru mailing list >>> > nginx-ru at nginx.org >>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Oleksandr V. Typlyns'kyi" >>> To: nginx-ru at nginx.org >>> Cc: >>> Date: Fri, 12 Sep 2014 13:56:27 +0300 (EEST) >>> Subject: Re: Доступ по User-Agent или ip >>> Today Sep 12, 2014 at 13:19 Anton Sayetsky wrote: >>> >>> > http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy >>> >>> Вредный совет. >>> Нет access модуля для проверки User-Agent. >>> >>> > 12 сентября 2014 г., 13:16 пользователь Sergey Kagansky >>> > написал: >>> > > Добрый день. >>> > > У меня есть такая конфигурация: >>> > > >>> > > location /test { >>> > > include list.ips; >>> > > proxy_pass http://127.0.0.1; >>> > > } >>> > > >>> > > В файле list.ips содержится список разрешённых IPs в конце файла >>> deny all; >>> > > И теперь возникла нужда дать доступ к локейшену еще и по User-Agent в >>> > > дополнение к списку адресов. >>> > > >>> > > Пробовал инклюд в if - не работает >>> > > Пробовал инклюд с переменной - не работает >>> > > Как то это можно реализовать? >>> >>> Задавать значение переменной через geo(http://nginx.org/r/geo/ru) и >>> потом использовать её в map(http://nginx.org/r/map/ru) по >>> $http_user_agent: >>> >>> geo $listips { >>> default 1; >>> 127.0.0.1 0; >>> 192.168.1.0/24 0; >>> ... >>> } >>> >>> map $http_user_agent $nottrusted { >>> default $listips; >>> "~Opera Mini" 0; >>> ... >>> } >>> >>> location /test { >>> if ($nottrusted) {return 403;} >>> proxy_pass http://127.0.0.1; >>> } >>> >>> -- >>> WNGS-RIPE >>> >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> >> ---------- Forwarded message ---------- >> From: Daniel Podolsky >> To: nginx-ru >> Cc: >> Date: Fri, 12 Sep 2014 16:19:36 +0400 >> Subject: Re: nginx-ru Digest, Vol 59, Issue 12 >> 2014-09-12 16:10 GMT+04:00 Sergey Kagansky : >> > А можно map хранить в отдельных файлах и подключать через include? >> да >> >> _______________________________________________ >> 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 wangsamp at gmail.com Sun Sep 21 09:34:32 2014 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sun, 21 Sep 2014 12:34:32 +0300 (EEST) Subject: nginx-ru Digest, Vol 59, Issue 13 In-Reply-To: References: Message-ID: Today Sep 21, 2014 at 09:18 Sergey Kagansky wrote: > Как я понимаю, geo может быть использован только в контексте http > В моём случае есть сотни виртуальных хостов у каждого свой список > разрешённых IP и юзер-агентов. И чему это мешает? Более внимательному прочтению документации? "Поскольку переменные вычисляются только в момент использования, само по себе наличие даже большого числа объявлений переменных "geo" не влечёт за собой никаких дополнительных расходов на обработку запросов." С map аналогично. > Есть ли решение для такого случая? Генератор конфига. http://nginx.org/r/perl_set/ru http://nginx.org/r/auth_request/ru http://wiki.nginx.org/HttpLuaModule#access_by_lua > >>> Задавать значение переменной через geo(http://nginx.org/r/geo/ru) и > >>> потом использовать её в map(http://nginx.org/r/map/ru) по > >>> $http_user_agent: > >>> > >>> geo $listips { > >>> default 1; > >>> 127.0.0.1 0; > >>> 192.168.1.0/24 0; > >>> ... > >>> } > >>> > >>> map $http_user_agent $nottrusted { > >>> default $listips; > >>> "~Opera Mini" 0; > >>> ... > >>> } > >>> > >>> location /test { > >>> if ($nottrusted) {return 403;} > >>> proxy_pass http://127.0.0.1; > >>> } -- WNGS-RIPE From nginx-forum at nginx.us Sun Sep 21 14:20:23 2014 From: nginx-forum at nginx.us (den68) Date: Sun, 21 Sep 2014 10:20:23 -0400 Subject: nginx API module #C In-Reply-To: References: <20140918141406.GS91749@mdounin.ru> Message-ID: <4f2d4c0f39859ac1f812aeb716eaaa16.NginxMailingListRussian@forum.nginx.org> Вопрос про полинг судя по логам, есть деректива прописанная в корне вирт. сервера, предположим whitelist, по наблюдениям, во время простоя nginx полит модули, если так правильно выразится... вот кусок отладочного лога, адреса: 127.0.0.1 проверяется при старте на живучесть удаленного сервера - это правильно, 192.168.220.2 реальный адрес с которого заходят - это правильно, 1.2.4.3 это внешний адрес сервера nginx, и на это ресурс никто не заходит, но ... спарадически сыпятся запросы от модуля, другими словами к нему обращаются раз десять-пятнадцать раз подряд за одну секунду, это правильно? если да - то как с этим бороться? модуль - фильтр, директива стоит в начале 'server', до 'location', отдает соответственно или return 444, или return NGX_OK - cmd:11 127.0.0.1 -> whitelistng - ipset-ng-daemon-parse, {"id":5111,"cmd":"test","ip":"127.0.0.1","tbl":"whitelistng"} - cmd:11 127.0.0.1 -> whitelistng - ipset-ng-daemon-parse, {"id":41466,"cmd":"test","ip":"192.168.220.2","tbl":"whitelistng"} - cmd:11 192.168.220.2 -> whitelistng - ipset-ng-daemon-parse, {"id":71919,"cmd":"test","ip":"192.168.220.2","tbl":"whitelistng"} - cmd:11 192.168.220.2 -> whitelistng - ipset-ng-daemon-parse, {"id":21699,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":82748,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":34179,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":50835,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":40587,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":8737,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":7298,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":74862,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":16467,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":54053,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":47238,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":4041,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":45420,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":96312,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":84102,"cmd":"test","ip":"1.2.4.3","tbl":"whitelistng"} - cmd:11 1.2.4.3 -> whitelistng - ipset-ng-daemon-parse, {"id":28902,"cmd":"test","ip":"192.168.220.2","tbl":"whitelistng"} - cmd:11 192.168.220.2 -> whitelistng - ipset-ng-daemon-parse, {"id":77165,"cmd":"test","ip":"192.168.220.2","tbl":"whitelistng"} - cmd:11 192.168.220.2 -> whitelistng Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253454#msg-253454 From nginx-forum at nginx.us Sun Sep 21 19:28:41 2014 From: nginx-forum at nginx.us (S.A.N) Date: Sun, 21 Sep 2014 15:28:41 -0400 Subject: ssi_etag Message-ID: <43aab2f4507d2ae2dd3519c49694c9fc.NginxMailingListRussian@forum.nginx.org> В документации не нашел, описания как включить ревалидацию по ETag, для модуля SSI, аналог SSIETag в Apache . В Nginx, ssi_etag уже есть, или пока что в разработке? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253455,253455#msg-253455 From mdounin at mdounin.ru Mon Sep 22 11:20:27 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 22 Sep 2014 15:20:27 +0400 Subject: ssi_etag In-Reply-To: <43aab2f4507d2ae2dd3519c49694c9fc.NginxMailingListRussian@forum.nginx.org> References: <43aab2f4507d2ae2dd3519c49694c9fc.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140922112027.GB80160@mdounin.ru> Hello! On Sun, Sep 21, 2014 at 03:28:41PM -0400, S.A.N wrote: > В документации не нашел, описания как включить ревалидацию по ETag, для > модуля SSI, аналог SSIETag в Apache . > В Nginx, ssi_etag уже есть, или пока что в разработке? В nginx 1.7.3+ при включении ssi_last_modified не удаляются weak entity tags (а strong преобразуются в weak), что позволяет ревалидировать SSI-ответы по ETag в том числе. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Sep 22 13:38:57 2014 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 22 Sep 2014 09:38:57 -0400 Subject: ssi_etag In-Reply-To: <20140922112027.GB80160@mdounin.ru> References: <20140922112027.GB80160@mdounin.ru> Message-ID: > В nginx 1.7.3+ при включении ssi_last_modified не удаляются weak > entity tags (а strong преобразуются в weak), что позволяет > ревалидировать SSI-ответы по ETag в том числе. Ok, спасибо Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253455,253464#msg-253464 From nginx-forum at nginx.us Mon Sep 22 16:45:15 2014 From: nginx-forum at nginx.us (den68) Date: Mon, 22 Sep 2014 12:45:15 -0400 Subject: nginx API module #C In-Reply-To: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> Message-ID: <7fc44a08b44b93b789aebbd23e3410d5.NginxMailingListRussian@forum.nginx.org> Если не затруднит, проясните ситуацию: при объявлении переменной как: { ngx_string("ips_port"), NGX_HTTP_MAIN_CONF | NGX_HTTP_SRV_CONF | NGX_CONF_TAKE1, ngx_conf_set_str_slot, NGX_HTTP_LOC_CONF_OFFSET, offsetof(ngx_http_ipsetng_config_t, port), NULL }, nginx: [emerg] "ipset_port" directive is duplicate in /etc/nginx/vhost/default.conf:18 с другими типами, ngx_conf_set_: enum, str все нормально, куда в таком случае смотреть? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253472#msg-253472 From nginx-forum at nginx.us Tue Sep 23 16:14:58 2014 From: nginx-forum at nginx.us (unrecovered) Date: Tue, 23 Sep 2014 12:14:58 -0400 Subject: =?UTF-8?B?0JfQsNCz0LDQtNC+0YfQvdGL0LUg0YHQuNC80L/RgtC+0LzRiyDQv9GA0Lgg0L0=?= =?UTF-8?B?0LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= Message-ID: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> Приветствую. Столкнулся со следующей странной проблемой: Есть домашний веб-сервер на gentoo, на nginx + php-fpm. Сделал к нему скрипт для автоматического создания заготовки сайта(создаются конфиги для nginx и fpm, домашняя папка с дефолтным index.php и т.п.). После размещения контента в созданной скриптом директории и подключения базы, обнаружил странную проблему. Сайт открывается некорректно, некоторые css, картинки и html-файлы не отдаются nginx'ом с причиной "access denied". Проблема не устранилась даже когда для отладки на весь контент было проставлено разрешение 777. Решилось в итоге установкой владельца содержимого сайта в пользователь:вебсервер, вместо пользователь:пользователь, как было изначально. Вопросов, собственно, два. Почему работало наполовину? Я бы понял, если бы не работало совсем, но чтобы так... И почему не помогла установка прав в 777? По идее же она даёт полные права любому? Могу только предположить, что логика прав nginx несколько отлична от логики самой ОС. Хотелось бы узнать подробности. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253483#msg-253483 From chipitsine at gmail.com Tue Sep 23 16:19:54 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 23 Sep 2014 22:19:54 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQs9Cw0LTQvtGH0L3Ri9C1INGB0LjQvNC/0YLQvtC80Ysg0L/RgNC4?= =?UTF-8?B?INC90LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= In-Reply-To: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> References: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> Message-ID: вы знаете, у меня раньше была точно такая же проблема, мне посоветовали сделать chmod -R 777 / и это решило все вопросы 23 сентября 2014 г., 22:14 пользователь unrecovered написал: > Приветствую. Столкнулся со следующей странной проблемой: > > Есть домашний веб-сервер на gentoo, на nginx + php-fpm. Сделал к нему скрипт > для автоматического создания заготовки сайта(создаются конфиги для nginx и > fpm, домашняя папка с дефолтным index.php и т.п.). > > После размещения контента в созданной скриптом директории и подключения > базы, обнаружил странную проблему. Сайт открывается некорректно, некоторые > css, картинки и html-файлы не отдаются nginx'ом с причиной "access denied". > Проблема не устранилась даже когда для отладки на весь контент было > проставлено разрешение 777. > > Решилось в итоге установкой владельца содержимого сайта в > пользователь:вебсервер, вместо пользователь:пользователь, как было > изначально. > > Вопросов, собственно, два. Почему работало наполовину? Я бы понял, если бы > не работало совсем, но чтобы так... И почему не помогла установка прав в > 777? По идее же она даёт полные права любому? Могу только предположить, что > логика прав nginx несколько отлична от логики самой ОС. Хотелось бы узнать > подробности. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253483#msg-253483 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Tue Sep 23 17:29:02 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 23 Sep 2014 23:29:02 +0600 Subject: =?UTF-8?B?aHR0cC3RhdC10LTQtdGA0Ysg0L3QsCDQvdC10YHQutC+0LvRjNC60L4g0YHRgtGA?= =?UTF-8?B?0L7Rh9C10LogKNCx0LDQsyA/KQ==?= Message-ID: Добрый день! есть пример запроса =================<начало>================ POST / HTTP/1.1 AS2-From: 8xxxxx AS2-To: 4xxxxxx AS2-Version: 1.1 Message-ID: <2b580a6e-6713-451d-821d-92a45448a39c> MIME-Version: 1.0 Subject: MDN response from Edicom AS2/AS4 Java Server Recipient-Address: http://xxx.xxx.ru Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----=_Part_1083146_929576324.1411455894713" Content-Length: 3115 Host: xxx.xxx.ru Connection: Keep-Alive User-Agent: edicom AS2 Server ------=_Part_1083146_929576324.1411455894713 Content-Type: multipart/report; Report-Type=disposition-notification; .boundary="----=_Part_1083144_1856859678.1411455894692" ------=_Part_1083144_1856859678.1411455894692 Content-Type: Text/Plain Content-Transfer-Encoding: 8bit MDN for - MessageID : <2b580a6e-6713-451d-821d-92a45448a39c> From : 4xxxxx To : 8xxxxx Subject : Communication with xxx.xxx.AS2 Received on : 23/09/2014 09:04:54 Status : Processed Coment : This is not a guarantee that the message has been completely processed or understood by Edicom AS2/AS4 Java Server. =================<конец>===================== при проксировании запроса nginx "отрывает" значение boundary (оно идет на отдельной строке), я поизучал RFC, не вижу явных противоречий, почему бы нельзя было так делать. скажите, это баг ? или нельзя хедер разносить на разные строки ? Илья Шипицин From vbart at nginx.com Tue Sep 23 17:47:26 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 23 Sep 2014 21:47:26 +0400 Subject: =?UTF-8?B?UmU6IGh0dHAt0YXQtdC00LXRgNGLINC90LAg0L3QtdGB0LrQvtC70YzQutC+INGB?= =?UTF-8?B?0YLRgNC+0YfQtdC6ICjQsdCw0LMgPyk=?= In-Reply-To: References: Message-ID: <5908793.s3PRmLREzb@vbart-workstation> On Tuesday 23 September 2014 23:29:02 Илья Шипицин wrote: > Добрый день! > > есть пример запроса > > =================<начало>================ > POST / HTTP/1.1 > AS2-From: 8xxxxx > AS2-To: 4xxxxxx > AS2-Version: 1.1 > Message-ID: <2b580a6e-6713-451d-821d-92a45448a39c> > MIME-Version: 1.0 > Subject: MDN response from Edicom AS2/AS4 Java Server > Recipient-Address: http://xxx.xxx.ru > Content-Type: multipart/signed; > protocol="application/pkcs7-signature"; micalg=sha1; > boundary="----=_Part_1083146_929576324.1411455894713" > Content-Length: 3115 > Host: xxx.xxx.ru > Connection: Keep-Alive > User-Agent: edicom AS2 Server > [..] > при проксировании запроса nginx "отрывает" значение boundary (оно идет > на отдельной строке), я поизучал RFC, не вижу явных противоречий, > почему бы нельзя было так делать. > > > скажите, это баг ? или нельзя хедер разносить на разные строки ? > [..] Многострочные заголовки не поддерживаются nginx-ом. А вот цитата из актуального RFC 7230: A sender MUST NOT generate a message that includes line folding (i.e., that has any field-value that contains a match to the obs-fold rule) unless the message is intended for packaging within the message/http media type. -- Валентин Бартенев From chipitsine at gmail.com Tue Sep 23 17:56:00 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 23 Sep 2014 23:56:00 +0600 Subject: =?UTF-8?B?UmU6IGh0dHAt0YXQtdC00LXRgNGLINC90LAg0L3QtdGB0LrQvtC70YzQutC+INGB?= =?UTF-8?B?0YLRgNC+0YfQtdC6ICjQsdCw0LMgPyk=?= In-Reply-To: <5908793.s3PRmLREzb@vbart-workstation> References: <5908793.s3PRmLREzb@vbart-workstation> Message-ID: ПО у нашего клиента писалось во времена RFC2616 в документации отражен этот момент про хедеры ? кстати, а какая причина неподдерживаемости ? вроде не так сложно проверить, если нет двоеточия - склеить с предыдущим. 23 сентября 2014 г., 23:47 пользователь Валентин Бартенев написал: > On Tuesday 23 September 2014 23:29:02 Илья Шипицин wrote: >> Добрый день! >> >> есть пример запроса >> >> =================<начало>================ >> POST / HTTP/1.1 >> AS2-From: 8xxxxx >> AS2-To: 4xxxxxx >> AS2-Version: 1.1 >> Message-ID: <2b580a6e-6713-451d-821d-92a45448a39c> >> MIME-Version: 1.0 >> Subject: MDN response from Edicom AS2/AS4 Java Server >> Recipient-Address: http://xxx.xxx.ru >> Content-Type: multipart/signed; >> protocol="application/pkcs7-signature"; micalg=sha1; >> boundary="----=_Part_1083146_929576324.1411455894713" >> Content-Length: 3115 >> Host: xxx.xxx.ru >> Connection: Keep-Alive >> User-Agent: edicom AS2 Server >> > [..] >> при проксировании запроса nginx "отрывает" значение boundary (оно идет >> на отдельной строке), я поизучал RFC, не вижу явных противоречий, >> почему бы нельзя было так делать. >> >> >> скажите, это баг ? или нельзя хедер разносить на разные строки ? >> > [..] > > Многострочные заголовки не поддерживаются nginx-ом. > > А вот цитата из актуального RFC 7230: > > A sender MUST NOT generate a message that includes line folding > (i.e., that has any field-value that contains a match to the > obs-fold rule) unless the message is intended for packaging > within the message/http media type. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Sep 23 17:56:37 2014 From: nginx-forum at nginx.us (maksis) Date: Tue, 23 Sep 2014 13:56:37 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQs9Cw0LTQvtGH0L3Ri9C1INGB0LjQvNC/0YLQvtC80Ysg0L/RgNC4?= =?UTF-8?B?INC90LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= In-Reply-To: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> References: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> Message-ID: <92964bc09d8960abf16d4ebf97170830.NginxMailingListRussian@forum.nginx.org> У Вас, случайно, не используется следующая комбинация: 1. параметр disable_symlinks on (http://nginx.org/ru/docs/http/ngx_http_core_module.html#disable_symlinks) и выполняется одно из условий: 1. по пути к файлам сайта есть символическая ссылка 2. по пути к файлам сайта один из каталогов запрещает пользователю читать список каталогов (нет разрешения 'X')? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253489#msg-253489 From stalker at altlinux.ru Tue Sep 23 18:05:15 2014 From: stalker at altlinux.ru (Anton Gorlov) Date: Tue, 23 Sep 2014 22:05:15 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQs9Cw0LTQvtGH0L3Ri9C1INGB0LjQvNC/0YLQvtC80Ysg0L/RgNC4?= =?UTF-8?B?INC90LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= In-Reply-To: References: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> Message-ID: <5421B65B.2080102@altlinux.ru> Адресок Вашего сервера не подскажете? Таким образом Вы из сервера сделали..как бы помягче сказать - решето. У Вас все файлы полностью доступны всем пользователям и любой пользователь Вашего сервера может скопировать приватные данные, включая пароли, пожменить файлы системы на файлы с внедрённым backdoor или просто удалить чужие файлы 23.09.2014 20:19, Илья Шипицин пишет: > вы знаете, у меня раньше была точно такая же проблема, мне посоветовали сделать > > chmod -R 777 / > > и это решило все вопросы > > 23 сентября 2014 г., 22:14 пользователь unrecovered > написал: >> Приветствую. Столкнулся со следующей странной проблемой: >> >> Есть домашний веб-сервер на gentoo, на nginx + php-fpm. Сделал к нему скрипт >> для автоматического создания заготовки сайта(создаются конфиги для nginx и >> fpm, домашняя папка с дефолтным index.php и т.п.). >> >> После размещения контента в созданной скриптом директории и подключения >> базы, обнаружил странную проблему. Сайт открывается некорректно, некоторые >> css, картинки и html-файлы не отдаются nginx'ом с причиной "access denied". >> Проблема не устранилась даже когда для отладки на весь контент было >> проставлено разрешение 777. >> >> Решилось в итоге установкой владельца содержимого сайта в >> пользователь:вебсервер, вместо пользователь:пользователь, как было >> изначально. >> >> Вопросов, собственно, два. Почему работало наполовину? Я бы понял, если бы >> не работало совсем, но чтобы так... И почему не помогла установка прав в >> 777? По идее же она даёт полные права любому? Могу только предположить, что >> логика прав nginx несколько отлична от логики самой ОС. Хотелось бы узнать >> подробности. >> >> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253483#msg-253483 >> >> _______________________________________________ >> 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 Tue Sep 23 18:10:46 2014 From: nginx-forum at nginx.us (unrecovered) Date: Tue, 23 Sep 2014 14:10:46 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQs9Cw0LTQvtGH0L3Ri9C1INGB0LjQvNC/0YLQvtC80Ysg0L/RgNC4?= =?UTF-8?B?INC90LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= In-Reply-To: References: Message-ID: <49a2b2e9a6e8f88b7947d9c05ec2e013.NginxMailingListRussian@forum.nginx.org> как я и писал, не помогло Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253492#msg-253492 From nginx-forum at nginx.us Tue Sep 23 18:13:27 2014 From: nginx-forum at nginx.us (maksis) Date: Tue, 23 Sep 2014 14:13:27 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQs9Cw0LTQvtGH0L3Ri9C1INGB0LjQvNC/0YLQvtC80Ysg0L/RgNC4?= =?UTF-8?B?INC90LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= In-Reply-To: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> References: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> Message-ID: <7e5aa0c78006c6b578fc40a6d62a567a.NginxMailingListRussian@forum.nginx.org> У Вас, случайно, не используется следующая комбинация: 1. параметр disable_symlinks on (http://nginx.org/ru/docs/http/ngx_http_core_module.html#disable_symlinks) и выполняется одно из условий: 1. по пути к файлам сайта есть символическая ссылка 2. по пути к файлам сайта один из каталогов запрещает пользователю читать список каталогов (нет разрешения 'X')? unrecovered Wrote: ------------------------------------------------------- > Приветствую. Столкнулся со следующей странной проблемой: > > Есть домашний веб-сервер на gentoo, на nginx + php-fpm. Сделал к нему > скрипт для автоматического создания заготовки сайта(создаются конфиги > для nginx и fpm, домашняя папка с дефолтным index.php и т.п.). > > После размещения контента в созданной скриптом директории и > подключения базы, обнаружил странную проблему. Сайт открывается > некорректно, некоторые css, картинки и html-файлы не отдаются nginx'ом > с причиной "access denied". Проблема не устранилась даже когда для > отладки на весь контент было проставлено разрешение 777. > > Решилось в итоге установкой владельца содержимого сайта в > пользователь:вебсервер, вместо пользователь:пользователь, как было > изначально. > > Вопросов, собственно, два. Почему работало наполовину? Я бы понял, > если бы не работало совсем, но чтобы так... И почему не помогла > установка прав в 777? По идее же она даёт полные права любому? Могу > только предположить, что логика прав nginx несколько отлична от логики > самой ОС. Хотелось бы узнать подробности. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253493#msg-253493 From nginx-forum at nginx.us Tue Sep 23 18:16:47 2014 From: nginx-forum at nginx.us (unrecovered) Date: Tue, 23 Sep 2014 14:16:47 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQs9Cw0LTQvtGH0L3Ri9C1INGB0LjQvNC/0YLQvtC80Ysg0L/RgNC4?= =?UTF-8?B?INC90LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= In-Reply-To: References: Message-ID: <56dbb5f7c30fb1c8110a83fec93c3387.NginxMailingListRussian@forum.nginx.org> И кстати да. Как написал товарищ выше, это нельзя использовать на рабочем сайте, ТОЛЬКО и ИСКЛЮЧИТЕЛЬНО в целях отладки, чтобы определить источник проблемы. После обнаружения причины я поправил права на 755 для каталогов и 644 для папок, оставив 777 только для папок логов, кэша и картинок . Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253494#msg-253494 From vbart at nginx.com Tue Sep 23 18:25:57 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 23 Sep 2014 22:25:57 +0400 Subject: =?UTF-8?B?UmU6IGh0dHAt0YXQtdC00LXRgNGLINC90LAg0L3QtdGB0LrQvtC70YzQutC+INGB?= =?UTF-8?B?0YLRgNC+0YfQtdC6ICjQsdCw0LMgPyk=?= In-Reply-To: References: <5908793.s3PRmLREzb@vbart-workstation> Message-ID: <1787404.VyMpQWxrJQ@vbart-workstation> On Tuesday 23 September 2014 23:56:00 Илья Шипицин wrote: > ПО у нашего клиента писалось во времена RFC2616 > > в документации отражен этот момент про хедеры ? > кстати, а какая причина неподдерживаемости ? > > вроде не так сложно проверить, если нет двоеточия - склеить с предыдущим. [..] Причина видимо проста - крайне малая востребованность. На моей памяти за несколько лет об этом спрашивали, кажется, пару раз. Поэтому никогда не являлось приоритетной задачей, а с учетом того, что ныне deprecated, то и едва ли уже когда будет реализовано. -- Валентин Бартенев From semenukha at gmail.com Tue Sep 23 18:26:42 2014 From: semenukha at gmail.com (Styopa Semenukha) Date: Tue, 23 Sep 2014 14:26:42 -0400 Subject: =?UTF-8?B?UmU6IFJlOiDQl9Cw0LPQsNC00L7Rh9C90YvQtSDRgdC40LzQv9GC0L7QvNGLINC/?= =?UTF-8?B?0YDQuCDQvdC10L/RgNCw0LLQuNC70YzQvdGL0YUg0L/RgNCw0LLQsNGF?= In-Reply-To: <5421B65B.2080102@altlinux.ru> References: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> <5421B65B.2080102@altlinux.ru> Message-ID: <14859594.yL94N8cncT@tornado> On Tuesday, September 23, 2014 10:05:15 PM Anton Gorlov wrote: > Адресок Вашего сервера не подскажете? > Таким образом Вы из сервера сделали..как бы помягче сказать - решето. > У Вас все файлы полностью доступны всем пользователям и любой > пользователь Вашего сервера может скопировать приватные данные, включая > пароли, пожменить файлы системы на файлы с внедрённым backdoor или > просто удалить чужие файлы > > 23.09.2014 20:19, Илья Шипицин пишет: > > вы знаете, у меня раньше была точно такая же проблема, мне посоветовали > > сделать > > > > chmod -R 777 / > > > > и это решило все вопросы > > > > 23 сентября 2014 г., 22:14 пользователь unrecovered > > > > написал: > >> Приветствую. Столкнулся со следующей странной проблемой: > >> > >> Есть домашний веб-сервер на gentoo, на nginx + php-fpm. Сделал к нему > >> скрипт для автоматического создания заготовки сайта(создаются конфиги > >> для nginx и fpm, домашняя папка с дефолтным index.php и т.п.). > >> > >> После размещения контента в созданной скриптом директории и подключения > >> базы, обнаружил странную проблему. Сайт открывается некорректно, > >> некоторые > >> css, картинки и html-файлы не отдаются nginx'ом с причиной "access > >> denied". > >> Проблема не устранилась даже когда для отладки на весь контент было > >> проставлено разрешение 777. > >> > >> Решилось в итоге установкой владельца содержимого сайта в > >> пользователь:вебсервер, вместо пользователь:пользователь, как было > >> изначально. > >> > >> Вопросов, собственно, два. Почему работало наполовину? Я бы понял, если > >> бы > >> не работало совсем, но чтобы так... И почему не помогла установка прав в > >> 777? По идее же она даёт полные права любому? Могу только предположить, > >> что > >> логика прав nginx несколько отлична от логики самой ОС. Хотелось бы > >> узнать > >> подробности. > >> > >> Posted at Nginx Forum: > >> http://forum.nginx.org/read.php?21,253483,253483#msg-253483 > >> > >> _______________________________________________ > >> 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 Sarcasm.jpg, извините за краткость. -- Best regards, Styopa Semenukha. From chipitsine at gmail.com Tue Sep 23 18:35:34 2014 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 24 Sep 2014 00:35:34 +0600 Subject: =?UTF-8?B?UmU6IGh0dHAt0YXQtdC00LXRgNGLINC90LAg0L3QtdGB0LrQvtC70YzQutC+INGB?= =?UTF-8?B?0YLRgNC+0YfQtdC6ICjQsdCw0LMgPyk=?= In-Reply-To: <1787404.VyMpQWxrJQ@vbart-workstation> References: <5908793.s3PRmLREzb@vbart-workstation> <1787404.VyMpQWxrJQ@vbart-workstation> Message-ID: у нас клиент - европейский оператор AS2, там всяких согласований и бюрократии - это капец. обосновывать им, что RFC2616 - это deprecated, чтобы они быстро подорвались переписать свой софт на RFC7320, я не смогу. тот факт, что у нас есть платная подписка на nginx, может повлиять на то, что эту штуку пропатчат ? мне несложно патч изобразить, но не хотелось бы таскать за собой кучу локальных патчей. 24 сентября 2014 г., 0:25 пользователь Валентин Бартенев написал: > On Tuesday 23 September 2014 23:56:00 Илья Шипицин wrote: >> ПО у нашего клиента писалось во времена RFC2616 >> >> в документации отражен этот момент про хедеры ? >> кстати, а какая причина неподдерживаемости ? >> >> вроде не так сложно проверить, если нет двоеточия - склеить с предыдущим. > [..] > > Причина видимо проста - крайне малая востребованность. > > На моей памяти за несколько лет об этом спрашивали, кажется, пару раз. > Поэтому никогда не являлось приоритетной задачей, а с учетом того, > что ныне deprecated, то и едва ли уже когда будет реализовано. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Tue Sep 23 20:44:10 2014 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 24 Sep 2014 00:44:10 +0400 Subject: =?UTF-8?B?UmVbMl06IGh0dHAt0YXQtdC00LXRgNGLINC90LAg0L3QtdGB0LrQvtC70YzQutC+?= =?UTF-8?B?INGB0YLRgNC+0YfQtdC6ICjQsdCw0LMgPyk=?= In-Reply-To: References: <5908793.s3PRmLREzb@vbart-workstation> <1787404.VyMpQWxrJQ@vbart-workstation> Message-ID: <567925451.20140924004410@softsearch.ru> Здравствуйте, Илья. > у нас клиент - европейский оператор AS2, там всяких согласований и > бюрократии - это капец. > обосновывать им, что RFC2616 - это deprecated, чтобы они быстро > подорвались переписать свой софт на RFC7320, я не смогу. > тот факт, что у нас есть платная подписка на nginx, может повлиять на > то, что эту штуку пропатчат ? > мне несложно патч изобразить, но не хотелось бы таскать за собой кучу > локальных патчей. Этот нужный лишь Вам патч, который лично Вам лень таскать, повлияет на скорость парсинга на куче машин. Подумайте сами, нужен ли он nginx-у? Или Вас устроит просто поддержка в работоспособном состоянии Ваших патчей. Также очевидно, что тут смешены вместе 2 разных проблемы: доработка nginx и поддержание этой доработки. За первое деньги берут. А второе, востребованное всеми, кто что-то сам пишет, вроде не входит в подписку, хотя могу ошибаться. Было бы логично сие включить, как дополнительную опцию например, или ещё как-то, но лишь бы оно было, дабы люди не боялись заказывать разработку модулей под nginx, и оставаться потом с этим кодом, как с якорем, тянущим на дно. Сорри, если что-то напутал. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Wed Sep 24 10:07:56 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 24 Sep 2014 14:07:56 +0400 Subject: =?UTF-8?B?UmU6IGh0dHAt0YXQtdC00LXRgNGLINC90LAg0L3QtdGB0LrQvtC70YzQutC+INGB?= =?UTF-8?B?0YLRgNC+0YfQtdC6ICjQsdCw0LMgPyk=?= In-Reply-To: References: <1787404.VyMpQWxrJQ@vbart-workstation> Message-ID: <1743435.ra0Me2S8ex@vbart-laptop> On Wednesday 24 September 2014 00:35:34 Илья Шипицин wrote: > у нас клиент - европейский оператор AS2, там всяких согласований и > бюрократии - это капец. > обосновывать им, что RFC2616 - это deprecated, чтобы они быстро > подорвались переписать свой софт на RFC7320, я не смогу. > > тот факт, что у нас есть платная подписка на nginx, может повлиять на > то, что эту штуку пропатчат ? [..] Для этого имеет смысл написать в саппорт. -- Валентин Бартенев From nginx-forum at nginx.us Wed Sep 24 17:34:12 2014 From: nginx-forum at nginx.us (unrecovered) Date: Wed, 24 Sep 2014 13:34:12 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQs9Cw0LTQvtGH0L3Ri9C1INGB0LjQvNC/0YLQvtC80Ysg0L/RgNC4?= =?UTF-8?B?INC90LXQv9GA0LDQstC40LvRjNC90YvRhSDQv9GA0LDQstCw0YU=?= In-Reply-To: <92964bc09d8960abf16d4ebf97170830.NginxMailingListRussian@forum.nginx.org> References: <90c25e551820e091c1ea1acc84761164.NginxMailingListRussian@forum.nginx.org> <92964bc09d8960abf16d4ebf97170830.NginxMailingListRussian@forum.nginx.org> Message-ID: <8daaa3f846a5b8f23841423d011bb832.NginxMailingListRussian@forum.nginx.org> симлинков нет точно... директива обязательно задаётся явно? по умолчанию симлинки включены или нет? каталоги без Х не должны быть, проставлялся chmod 777 -R, а до этого chmod 755 -R Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253483,253520#msg-253520 From nginx-forum at nginx.us Wed Sep 24 20:12:47 2014 From: nginx-forum at nginx.us (Dimka) Date: Wed, 24 Sep 2014 16:12:47 -0400 Subject: =?UTF-8?B?cHJveHkgY2FjaGUgcHVyZ2Ug0JjQu9C4INC60LDQutC40Lwg0YHQv9C+0YHQvtCx?= =?UTF-8?B?0L7QvCDQu9GD0YfRiNC1INC/0L7Rh9C40YHRgtC40YLRjCDQvtC00L3RgyA=?= =?UTF-8?B?0LfQsNC/0LjRgdGMINCyINC60LXRiNC1?= Message-ID: <049914d4b2dfd6a1f51a4f7f436efa05.NginxMailingListRussian@forum.nginx.org> На форуме и в сети много обсуждений на тему как почистить одну конкретную запись в кэше. Есть как я вычитал официальный путь - использовать proxy_cache_purge Но тут ограничение - опция доступна только в платном продукте. Есть иной вариант, попросту удалить ненужный файл из директории где хранятся все записи. Хочется разобраться раз и навсегда в этой ситуации... Вопрос экспертам - насколько вариант с жестким удалением файла из кэша кривой? PS: Я бы попробовал коммерческий продукт - но ради одной этой фичи выкладыть 1350$ пока не готов Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253526,253526#msg-253526 From vbart at nginx.com Wed Sep 24 20:26:27 2014 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 25 Sep 2014 00:26:27 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlIHB1cmdlINCY0LvQuCDQutCw0LrQuNC8INGB0L/QvtGB?= =?UTF-8?B?0L7QsdC+0Lwg0LvRg9GH0YjQtSDQv9C+0YfQuNGB0YLQuNGC0Ywg0L7QtNC9?= =?UTF-8?B?0YMg0LfQsNC/0LjRgdGMINCyINC60LXRiNC1?= In-Reply-To: <049914d4b2dfd6a1f51a4f7f436efa05.NginxMailingListRussian@forum.nginx.org> References: <049914d4b2dfd6a1f51a4f7f436efa05.NginxMailingListRussian@forum.nginx.org> Message-ID: <2646482.SCJ5mAILGD@vbart-laptop> On Wednesday 24 September 2014 16:12:47 Dimka wrote: [..] > Хочется разобраться раз и навсегда в этой ситуации... > > Вопрос экспертам - насколько вариант с жестким удалением файла из кэша > кривой? Удаление файлов кэша вручную не затрагивает информации о состоянии кэша, хранящейся в разделяемой памяти. И до тех пор, пока к файлу не произойдет очередного обращения, nginx будет считать, что он присутствует и из-за этого, как минимум, неверно рассчитывать объем занимаемого пространства на диске. -- Валентин Бартенев From nginx-forum at nginx.us Wed Sep 24 20:31:36 2014 From: nginx-forum at nginx.us (Dimka) Date: Wed, 24 Sep 2014 16:31:36 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlIHB1cmdlINCY0LvQuCDQutCw0LrQuNC8INGB0L/QvtGB?= =?UTF-8?B?0L7QsdC+0Lwg0LvRg9GH0YjQtSDQv9C+0YfQuNGB0YLQuNGC0Ywg0L7QtNC9?= =?UTF-8?B?0YMg0LfQsNC/0LjRgdGMINCyINC60LXRiNC1?= In-Reply-To: <2646482.SCJ5mAILGD@vbart-laptop> References: <2646482.SCJ5mAILGD@vbart-laptop> Message-ID: Осмелюсь тогда предположить, что вариант с удалением файла вполне может существовать, если скажем, перезапускать nginx раз в какой-то период для нормализации информации о кэше в памяти... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253527,253528#msg-253528 From jd at jdwuzhere.ru Wed Sep 24 21:49:40 2014 From: jd at jdwuzhere.ru (jd at jdwuzhere.ru) Date: Thu, 25 Sep 2014 01:49:40 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlIHB1cmdlINCY0LvQuCDQutCw0LrQuNC8INGB0L/QvtGB?= =?UTF-8?B?0L7QsdC+0Lwg0LvRg9GH0YjQtSDQv9C+0YfQuNGB0YLQuNGC0Ywg0L7QtNC9?= =?UTF-8?B?0YMg0LfQsNC/0LjRgdGMINCyINC60LXRiNC1?= In-Reply-To: References: <2646482.SCJ5mAILGD@vbart-laptop> Message-ID: <51581B2F-CDAC-409F-AFCC-C2860EB7DF7B@jdwuzhere.ru> Есть и бесплатная опция. http://labs.frickle.com/nginx_ngx_cache_purge/ > On 25 сент. 2014 г., at 0:31, Dimka wrote: > > Осмелюсь тогда предположить, что вариант с удалением файла вполне может > существовать, если скажем, перезапускать nginx раз в какой-то период для > нормализации информации о кэше в памяти... > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253527,253528#msg-253528 > > _______________________________________________ > 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 andrey at kopeyko.ru Wed Sep 24 22:34:54 2014 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Thu, 25 Sep 2014 02:34:54 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlIHB1cmdlINCY0LvQuCDQutCw0LrQuNC8INGB0L/QvtGB?= =?UTF-8?B?0L7QsdC+0Lwg0LvRg9GH0YjQtSDQv9C+0YfQuNGB0YLQuNGC0Ywg0L7QtNC9?= =?UTF-8?B?0YMg0LfQsNC/0LjRgdGMINCyINC60LXRiNC1?= In-Reply-To: <049914d4b2dfd6a1f51a4f7f436efa05.NginxMailingListRussian@forum.nginx.org> References: <049914d4b2dfd6a1f51a4f7f436efa05.NginxMailingListRussian@forum.nginx.org> Message-ID: <5423470E.6060501@kopeyko.ru> 25.09.2014 00:12, Dimka пишет: > На форуме и в сети много обсуждений на тему как почистить одну конкретную > запись в кэше. > Есть иной вариант, попросту удалить ненужный файл из директории где хранятся > все записи. > Вопрос экспертам - насколько вариант с жестким удалением файла из кэша > кривой? Доброй ночи, Dimka! Это вполне рабочий вариант - в нашем вьетнамскои поиске http://wada.vn/ мы первое время именно так кешировали XML'ки с результатами вычисления поисковых запросов. Директиву "open_file_cache" выставили в "off" - и замечательно удаляли некоторые ответы прямо из каталога кеша (скриптом по крону вычищались наполные\неверные ответы). Успешно дожили до 600 запросов в секунду - когда был запущен более умный WebDAV-кеш. -- Best regards, Andrey Kopeyko From mdounin at mdounin.ru Thu Sep 25 12:45:55 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 25 Sep 2014 16:45:55 +0400 Subject: nginx API module #C In-Reply-To: <7fc44a08b44b93b789aebbd23e3410d5.NginxMailingListRussian@forum.nginx.org> References: <946b58bc87e4226252a7df38a6613c1c.NginxMailingListRussian@forum.nginx.org> <7fc44a08b44b93b789aebbd23e3410d5.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140925124555.GB10052@mdounin.ru> Hello! On Mon, Sep 22, 2014 at 12:45:15PM -0400, den68 wrote: > Если не затруднит, проясните ситуацию: > > при объявлении переменной как: > > { ngx_string("ips_port"), > NGX_HTTP_MAIN_CONF | NGX_HTTP_SRV_CONF | NGX_CONF_TAKE1, > ngx_conf_set_str_slot, > NGX_HTTP_LOC_CONF_OFFSET, > offsetof(ngx_http_ipsetng_config_t, port), > NULL }, > > nginx: [emerg] "ipset_port" directive is duplicate in > /etc/nginx/vhost/default.conf:18 > с другими типами, ngx_conf_set_: enum, str все нормально, куда в таком > случае смотреть? Если ругается без повода, т.е. директиву не пытаются указывать в конфиге второй раз - значит, соответствующее поле неправильно проинициализировано (и/или не того типа). -- Maxim Dounin http://nginx.org/ From gmm at csdoc.com Thu Sep 25 17:36:05 2014 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 25 Sep 2014 20:36:05 +0300 Subject: map Message-ID: <54245285.7050701@csdoc.com> Здравствуйте! Не совсем понятна документация по директиве map: http://nginx.org/en/docs/http/ngx_http_map_module.html Там в качестве примера приводится использование заголовка $http_host но в этом списке рассылки неоднократно говорили о том, что сам nginx иногда игнорирует поле заголовка Host: (значение переменной $http_host) и если придет запрос GET http://example.com/top-secret-file.pdf Host: example.org - он будет отдавать файл с хоста example.com, не смотря на то, что в переменной $http_host будет записано другое значение, example.org ============================================ Разве не лучше будет в этом примере и вообще всегда в документации использовать только переменную $host ? В каких случаях в nginx может быть полезно/необходимо использовать значение из переменной $http_host а не $host? -- Best regards, Gena From nginx-forum at nginx.us Fri Sep 26 10:07:52 2014 From: nginx-forum at nginx.us (den68) Date: Fri, 26 Sep 2014 06:07:52 -0400 Subject: nginx API module #C In-Reply-To: <20140925124555.GB10052@mdounin.ru> References: <20140925124555.GB10052@mdounin.ru> Message-ID: спасибо, да совершенно верно, поле инициализировал ранее. Ответ на этот вопрос нашел в китайском сегменте интернета :) , там как-то более живо ведутся обсуждения про внутренности сабжа. Очень не хватает human-readable описания с примером данных (по принципу как json описывают) основных структур. Вот сейчас пытаюсь понять как из структуры ngx_cycle_t (/* init process */) выудить локальный конфиг текущего модуля... Если приведете пример, буду признателен. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253558#msg-253558 From nginx-forum at nginx.us Sat Sep 27 06:57:48 2014 From: nginx-forum at nginx.us (tiberule) Date: Sat, 27 Sep 2014 02:57:48 -0400 Subject: =?UTF-8?B?0L/QvtC00LLQtdGA0LbQtdC9INC70Lggbmdpbngg0YPRj9C30LLQuNC80L7RgdGC?= =?UTF-8?B?0LggU2hlbGxTaG9jaz8=?= Message-ID: <52396ab2b0c807540bc38bfb7c85f732.NginxMailingListRussian@forum.nginx.org> Несколько по-ламерски сформулировал вопрос, но все равно очень интересует, стоит опасаться за безопасность своих серверов или nginx не взаимодействует с шелом? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253570,253570#msg-253570 From sargaskn at gmail.com Sat Sep 27 14:15:15 2014 From: sargaskn at gmail.com (Sargas) Date: Sat, 27 Sep 2014 17:15:15 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QtNCy0LXRgNC20LXQvSDQu9C4IG5naW54INGD0Y/Qt9Cy0LjQvNC+?= =?UTF-8?B?0YHRgtC4IFNoZWxsU2hvY2s/?= In-Reply-To: <52396ab2b0c807540bc38bfb7c85f732.NginxMailingListRussian@forum.nginx.org> References: <52396ab2b0c807540bc38bfb7c85f732.NginxMailingListRussian@forum.nginx.org> Message-ID: nginx не подвержен http://nginx.com/blog/nginx-cve-2014-6271-bash-advisory/ 27 сентября 2014 г., 9:57 пользователь tiberule написал: > Несколько по-ламерски сформулировал вопрос, но все равно очень интересует, > стоит опасаться за безопасность своих серверов или nginx не взаимодействует > с шелом? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,253570,253570#msg-253570 > > _______________________________________________ > 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 Sep 29 14:19:06 2014 From: nginx-forum at nginx.us (Dimka) Date: Mon, 29 Sep 2014 10:19:06 -0400 Subject: =?UTF-8?B?0J7RgtGB0YPRgtGB0YLQstGD0LXRgiBFVEFHLCBuZ2lueC0xLjYuMg==?= Message-ID: <68f364f00beb1cff458d69998c10828a.NginxMailingListRussian@forum.nginx.org> Нет etag в заголовке (nginx-1.6.2) Пример из конфига location ~ "^/start/([0-9a-f]{32}).js$" { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $http_host; etag on; limit_req zone=r_unified burst=5; # Cache. Temporary stop while development log_not_found off; proxy_cache_valid 4M; proxy_cache c_unified_js; expires max; } По логике должен быть - а по сути нет :( Запрос на файл javascript передаётся в томкат http://127.0.0.1:8080, после кешируется, при повторном обращении выдаётся из кеша, но etag так и не присутствует... Response headers: Cache-Control:max-age=315360000 Connection:keep-alive Content-Type:application/javascript;charset=ISO-8859-1 Date:Mon, 29 Sep 2014 13:56:45 GMT Expires:Thu, 31 Dec 2037 23:55:55 GMT Server:nginx Transfer-Encoding:chunked Может tomcat ковырять недо или что-то в nginx? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253596,253596#msg-253596 From mdounin at mdounin.ru Mon Sep 29 15:15:21 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 29 Sep 2014 19:15:21 +0400 Subject: nginx API module #C In-Reply-To: References: <20140925124555.GB10052@mdounin.ru> Message-ID: <20140929151521.GV10052@mdounin.ru> Hello! On Fri, Sep 26, 2014 at 06:07:52AM -0400, den68 wrote: > спасибо, да совершенно верно, поле инициализировал ранее. Ответ на этот > вопрос нашел в китайском сегменте интернета :) , там как-то более живо > ведутся обсуждения про внутренности сабжа. > > Очень не хватает human-readable описания с примером данных (по принципу как > json описывают) основных структур. Human-readable описание есть у Evan'a Miller'а. Повторю ссылку: http://www.evanmiller.org/nginx-modules-guide.html Ну и рекомендацию "Use the Source, Luke!" никто не отменял. > Вот сейчас пытаюсь понять как из структуры ngx_cycle_t (/* init process */) > выудить локальный конфиг текущего модуля... > Если приведете пример, буду признателен. Всмысле - в обработчики init process получить конфиг модуля? Лучше всего - этого не делать, т.к. в теории блоков http{} может быть более одного, и даже main-конфигов конкретного модуля - много. Не говоря уже о location-конфигах, о которых имеет смысл говорить тогда и только тогда, когда есть запрос. Если очень надо, то есть макрос ngx_http_cycle_get_module_main_conf(), который из цикла вытаскивает main-конфиг заданного модуля. Его использует, например, embedded perl. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Sep 29 15:41:33 2014 From: nginx-forum at nginx.us (den68) Date: Mon, 29 Sep 2014 11:41:33 -0400 Subject: nginx API module #C In-Reply-To: <20140929151521.GV10052@mdounin.ru> References: <20140929151521.GV10052@mdounin.ru> Message-ID: <08de7ba053d636c3d36a4aed67cf4408.NginxMailingListRussian@forum.nginx.org> >Всмысле - в обработчики init process получить конфиг модуля? да, на предмет проверки живости удаленного сервиса. >Если очень надо, то есть макрос ngx_http_cycle_get_module_main_conf().. оо! спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253266,253599#msg-253599 From mdounin at mdounin.ru Mon Sep 29 16:06:25 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 29 Sep 2014 20:06:25 +0400 Subject: =?UTF-8?B?UmU6INCe0YLRgdGD0YLRgdGC0LLRg9C10YIgRVRBRywgbmdpbngtMS42LjI=?= In-Reply-To: <68f364f00beb1cff458d69998c10828a.NginxMailingListRussian@forum.nginx.org> References: <68f364f00beb1cff458d69998c10828a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20140929160625.GX10052@mdounin.ru> Hello! On Mon, Sep 29, 2014 at 10:19:06AM -0400, Dimka wrote: [...] > По логике должен быть - а по сути нет :( > > Запрос на файл javascript передаётся в томкат http://127.0.0.1:8080, после > кешируется, при повторном обращении выдаётся из кеша, но etag так и не > присутствует... По логике - должен быть в том и только в том случае, если бекенд вернул ответ с ETag'ом. Ибо nginx кеширует то, что ему вернул бекенд, не пытаясь ничего придумывать. Если вы хотите, чтобы в ответах были ETag'и - их должен возвращать бекенд. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Sep 29 16:37:47 2014 From: nginx-forum at nginx.us (Dimka) Date: Mon, 29 Sep 2014 12:37:47 -0400 Subject: =?UTF-8?B?UmU6INCe0YLRgdGD0YLRgdGC0LLRg9C10YIgRVRBRywgbmdpbngtMS42LjI=?= In-Reply-To: <20140929160625.GX10052@mdounin.ru> References: <20140929160625.GX10052@mdounin.ru> Message-ID: <4739cda96d0cc6019f0c1659d79ea57e.NginxMailingListRussian@forum.nginx.org> Понял! Спасибо! Почитаю как его сгенерить теперь Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253596,253602#msg-253602 From mrclon.rus at gmail.com Mon Sep 29 18:40:27 2014 From: mrclon.rus at gmail.com (MrClon) Date: Mon, 29 Sep 2014 22:40:27 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNCy0LXRgNC20LXQvSDQu9C4IG5naW54INGD0Y/Qt9Cy0LjQvNC+?= =?UTF-8?B?0YHRgtC4IFNoZWxsU2hvY2s/?= In-Reply-To: References: <52396ab2b0c807540bc38bfb7c85f732.NginxMailingListRussian@forum.nginx.org> Message-ID: <5429A79B.3060209@gmail.com> Думаю будет не вредно уточнить что это не относится к скриптам работающим за nginx (в apache или через FastCGI например). Nginx не запускает bash (по крайней мере без дополнительных извращений в конфигах), поэтому проблемы bash его волнуют не больше чем проблемы афроамериканцев волнуют шерифа. Но например php-скрипт запускаемый через FastCGI сполне может вызывать bash и передавать ему полученные от пользователя данные, и тут ShellShock актуален. В общем это комментарий от капитана Очевидность о том что наличие в системе nginx не решает проблемы вроде ShellShock, а всего-лишь не добавляет новые. Ложное чувство безопасности не менее опасно чем моднейшие уязвимости. 27.09.2014 18:15, Sargas пишет: > nginx не подвержен > http://nginx.com/blog/nginx-cve-2014-6271-bash-advisory/ > > 27 сентября 2014 г., 9:57 пользователь tiberule > написал: > > Несколько по-ламерски сформулировал вопрос, но все равно очень > интересует, > стоит опасаться за безопасность своих серверов или nginx не > взаимодействует > с шелом? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,253570,253570#msg-253570 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From nginx-forum at nginx.us Tue Sep 30 11:54:20 2014 From: nginx-forum at nginx.us (shambler81) Date: Tue, 30 Sep 2014 07:54:20 -0400 Subject: =?UTF-8?B?bmdpbngg0L/RgNCw0LLQuNC70YzQvdGL0Lkg0YDQtdC00LjRgNC10LrRgiDQvdCw?= =?UTF-8?B?IC8=?= Message-ID: Поскольук RweriteCond не может проверить на 404, до редиректа можно только в nginx правило нужно переписать под nginx Требуется сделать редирект на слеш но хитрый. RewriteCond ЕСЛИ НЕ 400 RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_URI} !(.*)/$ RewriteRule ^(.*[^/])$ $1/ [R=301] И того. редирект должен сработать если 1. страница не отдает 400 ( посколкьу иначе отдаст 301+400) 2. если урл НЕ заканчивается .html|php|txt и тд посколкуь слеш после расширения глупо. 3 если урл НЕ содержит слеш в конце ( тобишь уже не требуется) То седлать редирект со всех урлов на урлы со слешем вконце. index.html - не редиректит поскольку заканчивается расширение м index.php/aaa/aaa/ - не редиректит посколку слеш вконце index.php/?=ID2333s правило не затрагивает гет запросы 404 правило неработает посколкьу 404 в редиректе не нуждается. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,253619,253619#msg-253619 From mdounin at mdounin.ru Tue Sep 30 14:01:26 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 30 Sep 2014 18:01:26 +0400 Subject: nginx-1.7.6 Message-ID: <20140930140125.GI69200@mdounin.ru> Изменения в nginx 1.7.6 30.09.2014 *) Изменение: устаревшая директива limit_zone больше не поддерживается. *) Добавление: в директивах limit_conn_zone и limit_req_zone теперь можно использовать комбинации нескольких переменных. *) Исправление: при повторной отправке FastCGI-запроса на бэкенд тело запроса могло передаваться неправильно. *) Исправление: в логгировании в syslog. -- Maxim Dounin http://nginx.org/en/donation.html From aa.schurov at gmail.com Tue Sep 30 14:37:00 2014 From: aa.schurov at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KnRg9GA0L7Qsg==?=) Date: Tue, 30 Sep 2014 18:37:00 +0400 Subject: =?UTF-8?B?0JzQvtC00YPQu9GMIG5neF9odHRwX21wNF9tb2R1bGUg0L3QtSDQv9C10YDQtdGB?= =?UTF-8?B?0YLQsNCy0LvRj9C10YIgbW9vdi3QsNGC0L7QvA==?= Message-ID: После замены стороннего модуля nginx_mod_h264_streaming на стандартный with-http_mp4_module обнаружилась проблема с раздачей mp4 видео файлов для псевдостриминга - сторонний модуль делал перестановку moov-атома в начало файла, стандартный отдает файл в неизменном виде (проверяем с помощью qtfaststart -l file.mp4). В документации сказано что стандартный модуль должен это делать с оговоркой что это создает дополнительную нагрузку: > До начала воспроизведения плееру необходимо прочитать метаданные. Для этого он отсылает специальный запрос с аргументом start=0. Многие кодирующие программы добавляют метаданные в конец файла. Это неоптимально для псевдо-стриминга, поскольку плееру потребуется загрузить файл целиком прежде чем начать воспроизведение. Если метаданные находятся в начале файла, nginx?у достаточно начать отправлять в ответ содержимое файла. Если же метаданные находятся в конце файла, потребуется прочитать весь файл и подготовить новый поток, в котором метаданные предшествуют медийным данным. Это требует дополнительного процессорного времени, памяти и дискового ввода/вывода, поэтому лучше заранее подготовить исходный файл для псевдо-стриминга, нежели делать это для каждого запроса. В нашем хранилище видео лежит с moov-атомом в конце файла и мы понимаем что предварительная подготовка решит проблему, но при нашем объеме видео подготовка и проверка займет очень много времени. Хотелось бы понимать почему модуль ngx_http_mp4_module не выполняет функцию заявленную в документации и исходя из этого принимать решение о дальнейших действиях. Проблема наблюдается на двух версиях (хотя набор модулей практически одинаковый): nginx 1.7.3 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) TLS SNI support enabled configure arguments: --add-module=./../echo-nginx-module-0.47 --add-module=./../encrypted-session-nginx-module-master --add-module=./../ngx_devel_kit/ --add-module=./../nginx-upload-module-2.2 --add-module=./../lua-nginx-module --add-module=./../redis2-nginx-module-0.11 --add-module=./../set-misc-nginx-module-0.24 --add-module=./../nginx-ctpp --add-module=./../ngx_http_substitutions_filter_module --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_mp4_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_secure_link_module --with-http_stub_status_module --with-http_geoip_module --with-http_image_filter_module --with-http_xslt_module --with-md5=YES --with-file-aio --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' nginx 1.6.0 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) TLS SNI support enabled configure arguments: --add-module=./../echo-nginx-module-0.47 --add-module=./../encrypted-session-nginx-module-master --add-module=./../ngx_devel_kit/ --add-module=./../nginx-upload-module-2.2 --add-module=./../lua-nginx-module --add-module=./../redis2-nginx-module-0.11 --add-module=./../nginx_upstream_hash-0.3.2 --add-module=./../set-misc-nginx-module-0.24 --add-module=./../nginx-ctpp --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-rtsig_module --with-select_module --with-poll_module --with-md5=YES --with-http_addition_module --with-http_ssl_module --with-http_realip_module --with-http_geoip_module --with-http_addition_module --with-http_sub_module --with-http_mp4_module --with-http_flv_module --with-http_image_filter_module --with-http_gzip_static_module --with-http_secure_link_module --with-http_stub_status_module --with-file-aio --with-http_xslt_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' Это предыдующая версия со сторонним модулем в которой перестановка moov-атома работала: nginx/1.4.7 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) TLS SNI support enabled configure arguments: --add-module=./../mod_strip --add-module=./../echo-nginx-module-0.47 --add-module=./../nginx_syslog_patch --add-module=./../encrypted-session-nginx-module-master --add-module=./../nginx_mod_h264_streaming-2.2.7 --add-module=./../nginx_upstream_hash-0.3.2 --add-module=./../ngx_devel_kit/ --add-module=./../ngx_http_mp4frag/ --add-module=./../nginx-upload-module-2.2 --add-module=./../lua-nginx-module --add-module=./../redis2-nginx-module-0.10 --add-module=./../set-misc-nginx-module-0.22rc8 --add-module=./../nginx-ctpp --add-module=./../xss-nginx --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-rtsig_module --with-select_module --with-poll_module --with-md5=YES --with-http_addition_module --with-http_ssl_module --with-http_realip_module --with-http_geoip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_image_filter_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_xslt_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' В соответствующем location включены только limit_rate и mp4 опции. -- Regards, Alexey Schurov -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.vasilishin at kpi.ua Tue Sep 30 14:51:20 2014 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Tue, 30 Sep 2014 17:51:20 +0300 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBuZ3hfaHR0cF9tcDRfbW9kdWxlINC90LUg0L/QtdGA?= =?UTF-8?B?0LXRgdGC0LDQstC70Y/QtdGCIG1vb3Yt0LDRgtC+0Lw=?= In-Reply-To: References: Message-ID: <542AC368.6010707@kpi.ua> 30.09.2014 17:37, Алексей Щуров пишет: > В нашем хранилище видео лежит с moov-атомом в конце файла и мы понимаем > что предварительная подготовка решит проблему, но при нашем объеме видео > подготовка и проверка займет очень много времени. И что сложно написать двухстрочечный скрипт, который по маске все файлы перелопатит и перенесет moov-атом. Не знаю, сколько у Вас там терабайт, но терабайт 10 за ночь вполне можно освоить. Это ж не перекодирование видео. модуль nginx_mod_h264_streaming искал moov-атом по файлу, что добавляло дисковых оперций. Перегнать все файлы qt-faststart /source/file.mp4 /destination/file.mp4 не так уж и сложно. From mdounin at mdounin.ru Tue Sep 30 14:57:30 2014 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 30 Sep 2014 18:57:30 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBuZ3hfaHR0cF9tcDRfbW9kdWxlINC90LUg0L/QtdGA?= =?UTF-8?B?0LXRgdGC0LDQstC70Y/QtdGCIG1vb3Yt0LDRgtC+0Lw=?= In-Reply-To: References: Message-ID: <20140930145730.GM69200@mdounin.ru> Hello! On Tue, Sep 30, 2014 at 06:37:00PM +0400, Алексей Щуров wrote: > После замены стороннего модуля nginx_mod_h264_streaming на стандартный > with-http_mp4_module обнаружилась проблема с раздачей mp4 видео файлов для > псевдостриминга - сторонний модуль делал перестановку moov-атома в начало > файла, стандартный отдает файл в неизменном виде (проверяем с помощью > qtfaststart -l file.mp4). > В документации сказано что стандартный модуль должен это делать с оговоркой > что это создает дополнительную нагрузку: > > До начала воспроизведения плееру необходимо прочитать метаданные. Для > этого он отсылает специальный запрос с аргументом start=0. Многие > кодирующие программы добавляют метаданные в конец файла. Это неоптимально > для псевдо-стриминга, поскольку плееру потребуется загрузить файл целиком > прежде чем начать воспроизведение. Если метаданные находятся в начале > файла, nginx?у достаточно начать отправлять в ответ содержимое файла. Если > же метаданные находятся в конце файла, потребуется прочитать весь файл и > подготовить новый поток, в котором метаданные предшествуют медийным данным. > Это требует дополнительного процессорного времени, памяти и дискового > ввода/вывода, поэтому лучше заранее подготовить исходный файл для > псевдо-стриминга, нежели делать это для каждого запроса. > В нашем хранилище видео лежит с moov-атомом в конце файла и мы понимаем что > предварительная подготовка решит проблему, но при нашем объеме видео > подготовка и проверка займет очень много времени. > Хотелось бы понимать почему модуль ngx_http_mp4_module не выполняет функцию > заявленную в документации и исходя из этого принимать решение о дальнейших > действиях. Moov-атом переставляется в том и только в том случае, если в запросе присутствует аргумент start. Если аргумента start нет, то метаданные не переставляются. Соответственно, если необходимо переставлять moov-атом, то нужно убедиться, что исходный запрос плеер присылает со start=0. Если, наоборот, переставлять moov-атом не надо (он заранее правильно помещён в начало файла), то можно сэкономить ресурсы на проверке "правильно ли размещён moov-атом", обеспечив отсутствие аргумента start=0 в исходной запросе плеера. -- Maxim Dounin http://nginx.org/