Fwd: Проверка связки сертификат+ключ
Здравствуйте. Обнаружил необычное (на мой взгяд поведение) - если "смешать" криптографические алгоритмы (сертификат ECDSA, ключ RSA или наоборот) то nginx не ругается при релоаде и применяет конфигурацию (при выполнении nginx -t тоже нет ошибок). (абсурдность самой ситуации можно не обсуждать, но к сожалению бывает и такое) Это ожидаемое поведение или похоже на баг? Проверял на разных версиях и ОС, но на всякий случай прикладываю: *snake@carbon:~$ nginx -Vnginx version: nginx/1.24.0built by gcc 10.2.1 20210110 (Debian 10.2.1-6) built with OpenSSL 1.1.1n 15 Mar 2022 (running with OpenSSL 1.1.1f 31 Mar 2020)TLS SNI support enabledconfigure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --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-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -ffile-prefix-map=/data/builder/debuild/nginx-1.24.0/debian/debuild-base/nginx-1.24.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'* ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Зеркало https://hg.nginx.org/pkg-oss на github
Здравствуйте! Нельзя ли добавить на github зеркало сабжевого репа? Используем его для сборки nginx и модулей (отсутствующих в официальной поставке), зеркалируем реп во внутренний гитлаб, хотелось бы убрать костыли типа mercurial 2 git. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Простой способ массового переноса http2 из listen в отдельную директиву
Здравствуйте! Я про nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /etc/nginx/sites-enabled/...:152 Надо http2 из параметра директивы listen перенести в отдельную http2 on; У меня несколько десятков блоков server. В некоторых http2 нужен, в некоторых (listen 80) нет. Есть какие-нибудь идеи как конвертацию сделать массово? С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Nuxt (Node.JS) + nginx-unit
Здравствуйте! Собираемся внедрять в инфраструктуру ПО использующее фреймворк Nuxt (https://nuxt.com/) на Node.JS. На данный момент используем преимущественно unit+PHP . Соответственно не хотели бы отказываться от unit и для Nuxt. Однако разработчики проекта на Nuxt (не самого Nuxt, а ПО для нас) говорят, что с Nuxt доступен только вариант проксирования через unit, так как Nuxt использует unJS Nitro (https://nuxt.com/docs/getting-started/server), что лишает смысла использования unit (для проксирования мы и nginx можем). Вопрос, к местному сообществу: можно ли использовать Nuxt с unit в режиме unit-http (https://unit.nginx.org/howto/samples/#node-js) или nodejs-loader https://unit.nginx.org/configuration/#configuration-nodejs-loader ? С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Что происходит при превышении keys_zone?
Здравствуйте! Что происходит при превышении размера keys_zone, например, в директиве proxy_cache_path ? Пишется ли ошибка в логи и, если да, то на каком уровне логирования? В моей памяти почему-то отложилось, что nginx не должен лимитировать количество файлов в кеше по этому параметру, а при превышении его должен сыпать ошибками в логи. Однако на практике мы сейчас, похоже, наблюдаем, что из-за того, что неверно посчитали keys_zone (указали 100m для кэша с более чем миллионом файлов, кеш не использовался на полную: не заполнялся даже близко к max_size, а в логах тишина. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Максимальная длина ключа proxy_cache_key
Здравствуйте! Спасибо за идею, но не подойдет, там криптострочка: набор рандомных символов. С уважением, Иван. 22.12.2022 15:52, Илья Шипицин пишет: можно map-ой вытаскивать подстроку фикс длины из куки чт, 22 дек. 2022 г. в 19:46, Иван : Здравствуйте! Подскажите, пожалуйста, какая максимальная длина значения ключа *_cache_key ? Хотим сделать proxy_cache_key $cookie_somecookie , где длина somecookie может быть до килобайта. Допустимо ли это и не будет ли каких-то внезапных спецэффектов? С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Максимальная длина ключа proxy_cache_key
Здравствуйте! Подскажите, пожалуйста, какая максимальная длина значения ключа *_cache_key ? Хотим сделать proxy_cache_key $cookie_somecookie , где длина somecookie может быть до килобайта. Допустимо ли это и не будет ли каких-то внезапных спецэффектов? С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Почему записи в access.log могут содержать пустой remote addr ?
Здравствуйте! Сходу, если идея, то IP адреса может не быть, если запрос приходит в nginx через unix-сокет. Проверьте все ваши listen'ы или дайте nginx -T. С уважением, Иван. 25.01.2022 11:21, Ilya Evseev пишет: Дано: nginx 1.18.0-0ubuntu1.2 и access_log по умолчанию. Проблема: некоторые записи в access.log содержат пустой IP клиента. Примеры (обе строки начинаются с пробела, фактические запросы заменил на "..."): - - [25/Jan/2022:07:56:46 +0300] "GET /... HTTP/1.1" 410 198 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36" - - [25/Jan/2022:08:01:14 +0300] "GET /... HTTP/1.1" 101 2 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36" Как такое может быть? remote_addr в настройках не переопределяется, set_real_ip_from не используется. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293434,293434#msg-293434 ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: Разный контент для пользователей разных сетей
Здравствуйте! Запускайте контейнер с nginx c network driver (параметр докера) - host, nginx будет слушать порт непосредственно на хосте, и будет знать реальный IP клиента. Либо запустите отдельный nginx на хосте, который будет ставить заголовок X-Forwarded-For и проксировать запросы к nginx в докер, на котором в свою очередь включите директиву proxy в geo. В принципе проксирующий nginx может быть не обязательно на том же хосте, где докер-контейнер, а где угодно в сети. С уважением, Иван. 31.03.2021 21:53, budarin пишет: Понял в чем проблема (благодаря return 200 $remote_addr) - у меня nginx и сервисы в докере а там своя подсеть10.0.0.0/24 насколько я понимаю все запросы там будут из этой подсети получается я не смогу различить локальная это сеть или интернет- пользователь? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291121#msg-291121 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Разный контент для пользователей разных сетей
Здравствуйте!
Попробуйте
geo $geo {
default global;
192.168.1.0/24 local;
}
server {
location / {
return 200 $geo;
#return 200 $remote_addr;
}
}
и, дёрнуть curl'ом. Увидите что у вас в geo. А, если заменить на
закомментированную строчку, то IP адрес, с которого обращаетесь, чтоб
убедиться, что ничего не путаете.
С уважением, Иван.
31.03.2021 21:30, budarin пишет:
Игорь, спасибо за ответ!
но к сожалению получаю global в локальной сети на машине где стоит nginx и
где тестирую
похоже что не срабатывает geo модуль - как можно проверить?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,291116,291118#msg-291118
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Is if evil with rewrite ... redirect?
Здравствуйте! Вопрос коротко: является ли rewrite ... redirect на 100% безопасным при использовании if внутри location. Подробнее: В https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ The only 100% safe things which may be done inside if in a location context are: * return <https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return> ...; * rewrite <https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite> ... last; то есть единственным вариантов rewrite на 100% безопасным с if в location написан rewrite с last. Учитывая написанное в статье далее и моё понимание nginx предполагаю, что rewrite можно не только с last, но так же с redirect и permanent, так как исключают выполнение других директив в рамках этого локейшена. "Возможно опасными" тут могут быть только break и, вероятно, отсуствие флагов rewrite так как оставляют возможность выполнения других директив не из модуля rewrite. Я прав? С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Непонятна работа limit_rate
При директивах limit_rate_after 15k; #150Mb limit_rate 2048k; proxy_max_temp_file_size 0; Скачивание происходит так как и ожидается, без обрывов и прочего, а так же обрезается скорость правильным образом в соответствии с директивами limit_rate_after и limit_rate. Но вот при такой конфигурации: limit_rate_after 15k; #150Mb limit_rate 2048k; proxy_max_temp_file_size 6144m; Поведение не понятно. При таких параметрах директив работает так - скачивается 150Мб и затем обрыв. Почему? ср, 7 окт. 2020 г. в 18:07, Иван Мишин : > При директивах > > вт, 6 окт. 2020 г. в 17:16, Maxim Dounin : > >> Hello! >> >> On Tue, Oct 06, 2020 at 10:42:47AM +0300, Evgeniy Berdnikov wrote: >> >> > On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote: >> > > День добрый! >> > > >> > > Вы качаете файл, получаемых от прокси апстрима? >> > > >> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size >> > > >> > > Вы упираетесь в 1Гб временного файла. когда качается быстро, он >> > > вообще в темп не пишется, если файл прилетает от апстрима быстрее >> > > чем забираем, то он уже пишется во временный файл. вы успеваете >> > > скачать столько, сколько прилетает до начала записи во временный >> > > файл + макс размер файла. >> > >> > Наличие лимита на размер временного файла это что, повод обрывать >> закачку? >> >> Наличие лимита - ни разу не повод обрывать закачку, nginx её и не >> обрывает. >> >> Другой вопрос, что если буфер забит - nginx'у некуда читать >> дополнительные данные, и в результате бэкенд может закрыть >> соединение по таймауту до того, как содержимое временного файла >> будет отдано клиену и соответственно nginx сможет дальше читать >> что-либо от бэкенда. >> >> При заявленном ограничении скорости в 2 мегабайта в секунду - >> отправка клиенту гигабайта временных данных займёт секунд 500 >> минимум. Если при этом с бэкенда эти данные летят по гигабитному >> каналу со скоростью 100 мегабайт в секунду - прилетят они секунд за >> 10. То есть между nginx'ом и бэкендом 490 секунд ничего не будет >> происходить. Шансов на то, что бэкенд дождётся при настройках по >> умолчанию - никаких. >> >> Соответственно нужно: >> >> - увеличить временный файл, чтобы ответы влезали; >> >> - или уменьшить временный файл, чтобы его содержимое могло >> отправиться до того, как сработает таймаут на бэкенде. >> >> Ну либо настраивать таймауты на бэкенде и/или ограничение >> скорости, чтобы опять же временный файл мог отправиться до того, >> как сработает таймаут на бэкенде. >> >> Вообще, когда речь идёт о том, что проксируются большие файлы - >> одним из лучших решений может быть просто выключенная буферизация >> на диск, "proxy_max_temp_file_size 0;". Это позволяет избежать не >> только проблем с таймаутами на бэкенде, но и траты ресурсов на >> disk i/o, а равно проблем с переполнением диска под временные >> файлы при большом количестве одновременных запросов. >> >> [...] >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Непонятна работа limit_rate
При директивах вт, 6 окт. 2020 г. в 17:16, Maxim Dounin : > Hello! > > On Tue, Oct 06, 2020 at 10:42:47AM +0300, Evgeniy Berdnikov wrote: > > > On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote: > > > День добрый! > > > > > > Вы качаете файл, получаемых от прокси апстрима? > > > > https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size > > > > > > Вы упираетесь в 1Гб временного файла. когда качается быстро, он > > > вообще в темп не пишется, если файл прилетает от апстрима быстрее > > > чем забираем, то он уже пишется во временный файл. вы успеваете > > > скачать столько, сколько прилетает до начала записи во временный > > > файл + макс размер файла. > > > > Наличие лимита на размер временного файла это что, повод обрывать > закачку? > > Наличие лимита - ни разу не повод обрывать закачку, nginx её и не > обрывает. > > Другой вопрос, что если буфер забит - nginx'у некуда читать > дополнительные данные, и в результате бэкенд может закрыть > соединение по таймауту до того, как содержимое временного файла > будет отдано клиену и соответственно nginx сможет дальше читать > что-либо от бэкенда. > > При заявленном ограничении скорости в 2 мегабайта в секунду - > отправка клиенту гигабайта временных данных займёт секунд 500 > минимум. Если при этом с бэкенда эти данные летят по гигабитному > каналу со скоростью 100 мегабайт в секунду - прилетят они секунд за > 10. То есть между nginx'ом и бэкендом 490 секунд ничего не будет > происходить. Шансов на то, что бэкенд дождётся при настройках по > умолчанию - никаких. > > Соответственно нужно: > > - увеличить временный файл, чтобы ответы влезали; > > - или уменьшить временный файл, чтобы его содержимое могло > отправиться до того, как сработает таймаут на бэкенде. > > Ну либо настраивать таймауты на бэкенде и/или ограничение > скорости, чтобы опять же временный файл мог отправиться до того, > как сработает таймаут на бэкенде. > > Вообще, когда речь идёт о том, что проксируются большие файлы - > одним из лучших решений может быть просто выключенная буферизация > на диск, "proxy_max_temp_file_size 0;". Это позволяет избежать не > только проблем с таймаутами на бэкенде, но и траты ресурсов на > disk i/o, а равно проблем с переполнением диска под временные > файлы при большом количестве одновременных запросов. > > [...] > > -- > Maxim Dounin > http://mdounin.ru/ > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Непонятна работа limit_rate
Забыл уточнить, что при обрыве в акцес логах все равно значится 200 код, а в ерор логах пусто. пн, 5 окт. 2020 г. в 19:47, Иван Мишин : > Добрый день! > Есть локейшн с настроенными вот такими директивами: > limit_rate_after 15k; #150Mb > limit_rate 2048k; > > Пробую качать с помощью wget большой файл, и примерно через 7 минут 49-55 > секунд закачка обрывается ну и соответственно объем (1.1Гб) скачанных > данных в зависимости от времени слегка разный. > Как только убирают указанные выше две директивы, так все логично быстро > качается и самое главное без обрыва , качается целиком. > А проблема заключается в том что указанными директивами я лишь хотел > подрезать скорость, но не понятно почему при этом файл не скачивается до > конца! До 1.1Гб файлы скачиваются нормально, а больше уже нет. Хотел было > грешить на таймауты какие-нибудь, но время обрыва хоть и примерно > одинаковое, но все же не постоянное, поэтому идею с таймаутами отбросил. > > Прошу подсказать как решить проблему? > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Непонятна работа limit_rate
Добрый день! Есть локейшн с настроенными вот такими директивами: limit_rate_after 15k; #150Mb limit_rate 2048k; Пробую качать с помощью wget большой файл, и примерно через 7 минут 49-55 секунд закачка обрывается ну и соответственно объем (1.1Гб) скачанных данных в зависимости от времени слегка разный. Как только убирают указанные выше две директивы, так все логично быстро качается и самое главное без обрыва , качается целиком. А проблема заключается в том что указанными директивами я лишь хотел подрезать скорость, но не понятно почему при этом файл не скачивается до конца! До 1.1Гб файлы скачиваются нормально, а больше уже нет. Хотел было грешить на таймауты какие-нибудь, но время обрыва хоть и примерно одинаковое, но все же не постоянное, поэтому идею с таймаутами отбросил. Прошу подсказать как решить проблему? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Проблема с отображением $remote_user
Всем привет. Использую wget с ключами --http-user=USERNAME --http-password=PASSWORD при этом в nginx в переменной $remote_user пусто. Пробовал и --user=USERNAME --password=PASSWORD и wget https:// USERNAME:passw...@example.com, но во всех случаях в логах в переменной $remote_user стоит прочерк. При этом с curl все работает ок. Подскажите в чем проблема? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Дублирование запросов
Добрый день! Подскажите, может ли nginx отправлять один запрос сразу на несколько апстримов, не round-robin, а именно дублирование/зеркалирование. Т.е. например в апстриме три сервера, приходит запрос и nginx его отправлят сразу на три апстрима/сервера. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Падает nginx в случае истечения срока действия сертификата
Добрый день. Есть множество хостов вида:
> server {
> listen 80;
> server_name example.com;
> location / {
> proxy_ssl_session_reuse off;
> proxy_ssl_certificate /etc/nginx/include/client/client.cer;
> proxy_ssl_certificate_key
> 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456';
> proxy_ssl_ciphers
> GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH;
> proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> proxy_pass https://world.cnet;
> proxy_set_header Host world.net;
> proxy_set_header X-Real-IP $remote_addr;
>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> }
> }
В случае если у одного из хостов истекает срок действия сертификата, то
отказывается работать nginx. Т.е. перестают работать абсолютно все вирт
хосты.
В логах ошибка вида:
> [emerg] 2169#2169:
> ENGINE_load_private_key("9867b5ab2b2c88342766gg5e99a6a7c6ddc7e324") failed
> (SSL: error:80015033:lib(128):gng_support_getuserkey:GNG_ERR_LICENSE
> error:26096080:engine routines:ENGINE_load_private_key:failed loading
> private key)
хеши сертов в примерах изменил на ненастоящие.
Как сделать так чтобы nginx не ронял все хосты из-за того что на одном
хосте просрочился серт? Может есть какая-то деректива специальная чтобы
отключить например проверку срока годности сертификатов?
пт, 2 авг. 2019 г. в 18:29, Иван Мишин :
> Добрый день. Есть множество хостов вида:
>
>> server {
>> listen 80;
>> server_name example.com;
>> location / {
>> proxy_ssl_session_reuse off;
>> proxy_ssl_certificate /etc/nginx/include/client/client.cer;
>> proxy_ssl_certificate_key
>> 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456';
>> proxy_ssl_ciphers
>> GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH;
>> proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>> proxy_pass https://world.cnet;
>> proxy_set_header Host world.net;
>> proxy_set_header X-Real-IP $remote_addr;
>>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>> }
>> }
>
>
> В случае если у одного из хостов истекает срок действия сертификата, то
> отказывается работать nginx. Т.е. перестают работать абсолютно все вирт
> хосты.
> В логах ошибка вида:
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Падает nginx в случае истечения срока действия сертификата
Добрый день. Есть множество хостов вида:
> server {
> listen 80;
> server_name example.com;
> location / {
> proxy_ssl_session_reuse off;
> proxy_ssl_certificate /etc/nginx/include/client/client.cer;
> proxy_ssl_certificate_key
> 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456';
> proxy_ssl_ciphers
> GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH;
> proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> proxy_pass https://world.cnet;
> proxy_set_header Host world.net;
> proxy_set_header X-Real-IP $remote_addr;
>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> }
> }
В случае если у одного из хостов истекает срок действия сертификата, то
отказывается работать nginx. Т.е. перестают работать абсолютно все вирт
хосты.
В логах ошибка вида:
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: обработка set_real_ip_from для 400-х статусов
Столкнулся с такой же проблемой. Есть какое-то объяснение этому?
пт, 14 июн. 2019 г. в 20:12, Илья Шипицин :
> привет!
>
> стенд:
>
> nginx-1.17.0 из официального репо.
> конфиг
>
> user root;
> worker_processes 1;
>
> error_log /var/log/nginx/error.log warn;
> pid/var/run/nginx.pid;
>
> events {
> worker_connections 1024;
> }
>
>
> http {
> include /etc/nginx/mime.types;
> default_type application/octet-stream;
>
> log_format custom '$remote_addr\t$http_x_real_ip\t$status\t$uri';
> set_real_ip_from 127.0.0.1;
>
> access_log /var/log/nginx/access.log custom;
>
> server {
> listen 80;
> server_name localhost;
> location / { return 200; }
> }
>
> server {
> listen 80;
> server_name _;
> location / { return 200; }
> }
>
> }
>
>
> =
> делаю два запроса
>
> curl --header "X-Real-IP: 8.9.10.11" - -I -k http://localhost/test
> curl --header "X-Real-IP: 8.9.10.11" - -I -k http://localhost/%
>
> получаю
>
> # cat /var/log/nginx/access.log
> 8.9.10.11 8.9.10.11 200 /test
> 127.0.0.1 - 400
>
>
> почему магия с форматом лога и хедерами работает на 200-х статусах и не
> работает на 400-х ? это такая задумка ? выглядит как баг.
>
> Илья Шипицин
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Unit] Миграция с fastcgi и её подводные камни
Здравствуйте! Кстати, хотел бы присоединиться к вопросу, с давно тут озвученной "хотелкой" - иметь возможность передавать (как вариант транслируя из http_VARNAME) переменные типа $_SERVER['REMOTE_ADDR'] , $_SERVER[' HTTPS'] напрямую в пыху под юнитом, а не загонять сонм готовых приложений в обертки делающие $_SERVER['HTTPS']=$_SERVER['HTTP_X_SPECIALLY_FOR_UNIT_HTTPS']. Прям вот всё еще останавливает от повсеместной интеграции этого замечательного продукта в нашу инфраструктуру. С уважением, Иван. 02.07.2019 10:21, Vadim A. Misbakh-Soloviov пишет: > Здравствуйте! > > Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз > столкнулся с проблемой того, что у fastcgi есть такая полезная штука как > split_path_info, где можно задать какая часть URI является значением > SCRIPT_NAME (да и вообще существует возможность динамического формирования > этого значения при запросе), а какая - идёт в PATH_INFO. > > Сама по себе переменная PATH_INFO (как доступное значение для приложения > внутри массива $_SERVER) - ещё пол беды. Есть, конечно, приложения, которые > рассчитывают на него, но это вторично по отношению к тому, что ну уж > **очень** > не хватает возможности динамически задавать значение "script" (aka > SCRIPT_NAME > в fcgi) для приложения в Юните. > > Т.е. чтобы весь URI как есть передался в сообщённый в заголовках (ну а как > ещё? Не вижу иного способа передать информацию Юниту от NgX) скрипт. > > Без такой возможности приходится городить по 100500 блоков application для > каждого потенциально возможного "script" (хардкодить все значения, в общем). > Что, если честно, делает меня грустной пандой. > > Соответствено, сопровождение большинства приложений, которые из коробки > работают с ЧПУ (а таких нынче большинство) превращается в пытку :'( > А уж если они ещё и о SEO решают заботиться по примеру вордпресса и внаглую > редиректить запросы типа "/scriptname.php?$uri" на "/?$uri" (явно полагаясь > на > то, что SCRIPT_NAME им передаётся и так), всё выходит на новый уровень... > > В общем, подскажите, пожалуйста: > 1) есть ли возможность как-то передавать значения конфигурационных директив > приложения в заголовках запроса? > 2) каковы шансы того, что если п.1 не является осуществимым сейчас, вы это > сделаете по реквесту из списка рассылки? :) > 2а) и каковы шансы того, что это произойдёт в ближайших релизах? :) > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сложный кеш POST запросов
> > * не задали "proxy_cache_path" - прокси пока некуда кешировать > * не включили само кеширование директивой proxy_cache Это задано на уровне http. Мой вопрос не в том что кеширование не работает, а в том что оно работает не так как надо, не так как планировал. вт, 16 апр. 2019 г. в 15:09, Andrey Kopeyko : > Иван Мишин писал 2019-04-16 12:26: > > Добрый день, помогите пожалуйста со > > следующей проблемой: > > Добрый день, Иван! > > > Есть такой конфиг: > ... > > Но в моем случае это так не работает. > > Потому что вы > * не задали "proxy_cache_path" - прокси пока некуда кешировать > * не включили само кеширование директивой proxy_cache > > > -- > Best regards, > Andrey A. Kopeyko > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Сложный кеш POST запросов
Добрый день, помогите пожалуйста со следующей проблемой:
Есть такой конфиг:
server {
server_name www.example.ru;
proxy_cache_methods POST;
proxy_cache_key $remote_addr$request_uri
proxy_cache_valid 200 302 5m;
expires 5m;
location /1test {
proxy_pass http://ololo;
proxy_cache_methods GET;
proxy_cache_key $server_name$request_uri
proxy_cache_valid 200 302 1h;
expires 1h;
}
location /2test {
proxy_pass http://ololo;
}
location /3test {
proxy_pass http://ololo;
proxy_cache_methods GET;
proxy_cache_key $server_name$request_uri
proxy_cache_valid 200 302 3d;
expires 3d;
}
}
Суть конфига в том что при обращении на /*test/* POST запросом должно
должен сработать кеш по ключу $remote_addr$request_uri у которого срок
годности 5m
При get запросе на /1test/* должен сработать кеш по ключу
$server_name$request_uri сроком на 1h
При get запросе на /2test/* кеша быть не должно
При get запросе на /3test/* должен сработать кеш по ключу
$server_name$request_uri сроком на 3d
Но в моем случае это так не работает. И я понимаю почему, потому что
происходит переопределение директив.
Подскажите как решить мне эту задачу?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ограничение доступа к папке по IP
Нет, не так. break и location существуют совершенно параллельно друг другу. break (https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#break) только про директивы модуля rewrite. А логика выбора location описывается полностью тут https://nginx.org/ru/docs/http/ngx_http_core_module.html#location, и про break там ничего. 09.04.2019 19:48, Vvedensky пишет: > читал, что встретив этот оператор > nginx прерывает дальнейшую работу (т.е. не пойдёт проверять следующий > location). Это не так? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,283658,283696#msg-283696 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ограничение доступа к папке по IP
Здравствуйте!
А зачем break в этих локейшенах?
Сходу ответа на Ваш вопрос у меня нет, но попробуйте сначала точно
выяснить куда приходит запрос: для каждого локейшена отдельный лог файл
и\или return 444 по очереди в каждый локейшен. Как точно узнаете, если
всё еще будет не понятно, давайте целый вывод nginx -T .
С уважением, Иван.
07.04.2019 20:16, Vvedensky пишет:
> Здравствуйте.
> Необходимо ограничить доступ к файлам папки /orders-files (в ней содержатся
> файлы с расширением doc) по ip, делаю так:
> location ^~ /orders-files/ {
> allow 123.45.678.90;
> deny all;
> client_max_body_size 32M;
> access_log off;
> break;
> }
> location ~*
> ^.+\.(css|js|svg|jpg|jpeg|gif|png|ico|zip|rar|doc|xls|pdf|exe|wav|bmp|rtf)$
> {
> client_max_body_size 128M;
> access_log off;
> expires 7d;
> break;
> }
>
> Такое впечатление, что нижний location мешает. Не могли бы помочь
> разобраться...
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,283658,283658#msg-283658
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx, fastcgi и деплой на симлинках
Здравствуйте.
Нежелание делать nginx reload (давать пользователю деплоя права
рута\sudo, например), когда можно не делать.
С уважением, Иван Прокудин.
21.03.2019 14:25, Alex Domoradov пишет:
> > а код продолжает работать версии 1.2.9 .
>
> а что мешает во время деплоя сделать nginx reload ?
>
> On Thu, Mar 21, 2019 at 1:21 PM Иван <mailto:ng...@kinetiksoft.com>> wrote:
>
> Здравствуйте!
>
> Есть симлинк
>
> /home/live -> /home/releases/live/1.2.9
>
> при деплое он меняется на
>
> /home/live -> /home/releases/live/1.2.10
>
> а код продолжает работать версии 1.2.9 .
>
>
> Преполагаю, что должен помочь такой патч к конфигу nginx
>
> location /live/ {
>
> + root /home/live;
> include fastcgi_params;
>
> - fastcgi_param SCRIPT_FILENAME
> /home/live/register_user_new.php;
> + fastcgi_param SCRIPT_FILENAME
> $realpath_root/register_user_new.php;
> }
>
> Верно? Короче говоря, непосредственно указать путь в fastcgi_param
> симлинки кешируются, а с realpath_root - всегда актуальны?
>
> С уважением, Иван Прокудин.
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx, fastcgi и деплой на симлинках
Здравствуйте!
Есть симлинк
/home/live -> /home/releases/live/1.2.9
при деплое он меняется на
/home/live -> /home/releases/live/1.2.10
а код продолжает работать версии 1.2.9 .
Преполагаю, что должен помочь такой патч к конфигу nginx
location /live/ {
+ root /home/live;
include fastcgi_params;
- fastcgi_param SCRIPT_FILENAME
/home/live/register_user_new.php;
+ fastcgi_param SCRIPT_FILENAME
$realpath_root/register_user_new.php;
}
Верно? Короче говоря, непосредственно указать путь в fastcgi_param
симлинки кешируются, а с realpath_root - всегда актуальны?
С уважением, Иван Прокудин.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: rewrite some/url в some/url.html
Здравствуйте!
Чтоб не усложнять регэксп, попробуйте как-то так:
server {
location ~ \.html$ {
#обработка запросов ссылок с html
...
}
location ~ /$ {
#обработка запросов заканчивающихся на слэш
...
}
location / {
rewrite ^/(.+)$ /$1.html permanent
}
}
С уважением, Иван.
20.03.2019 20:08, Dzurillo пишет:
> Здравствуйте!
>
> Помогите пожалуйста написать rewrite. Мне нужно все ссылки вида
> http://some/url пробрасывать на http://some/url.html
> Т.е. три условия: request_uri не пустой, в конце урл нет слэша и урл не
> заканчивается на ".html"
> Пока дошел вот до этого:
>
> rewrite ^/(.+[^/])(?!.*\.html)$ $1.html permanent;
>
> Но работает не так как надо.
>
> Спасибо за помощь.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,283447,283447#msg-283447
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Динамический upstream средствами dns в открытой версии nginx
Здравствуйте!
Есть необходимость выбирать апстрим для проксирования на основании
информации из mysql-базы. Есть мысль задействовать для этого DNS-сервер
с поддержкой mysql в бэкэнде (и A\ записи с небольшим, порядка 30-60
секунд TTL), например, powerdns и nginx примерно в такой конфигурации:
Пусть DNS отвечает на 127.0.1.1:53 . У него бэкэнд в мускуле, в котором
сотни A\ записей вида
user1.room1.example.com -> 1.1.1.1
user2.room1.example.com -> 1.10.1.2
user3.room2.example.com -> 1.200.1.100
и т.п.
которые (записи) периодически (раз в несколько часов) обновляет наше ПО.
В nginx на прокси примерно такая конфигурация:
location ~ ^/user/(?\w+)/(?\w+)$ {
resolver 127.0.1.1;
proxy_pass http://$user.$room.example.com;
}
Будет ли в такой конфигурации запрос вида GET /user/room2/user3 к прокси
уходить на 1.200.1.100, а GET /user/room1/user2 к прокси уходить на
1.10.1.2,
Когда я последний раз думал над этой схемой, мне казалось, что тут
что-то доступно только в коммерческой подписке.
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
unit: не работает SMTP в ruby
Здравствуйте! Самосборный unit-ruby для ruby 2.4.5 из rvm. ОС: Debian Stretch. unit 1.8.0-1, сам unit из официальных репов. Я предполагаю, что проблема не непосредственно в unit, но из-под другого сервера приложений проблемы нет, так что попробую спросить тут. Пытаюсь поднять redmine-3.4.9. под управлением unit. Всё работает хорошо, кроме одного странного нюанса: при попытке отправить почту получаю ошибку undefined method `read_nonblock' for # , которая, как говорит гугл (я совсем не программист, тем более на руби) говорит о том, что соединение не установленно на ранней стадии. Я пробовал отключать шифрование или включать - роли не играет. Я специально сделал тестовое ПО, которое просто шлёт почту и ничего больше, с ним та же проблема. В руби для отправки почты используется actionmailer. Не работает отправка по SMTP, вне зависимости от остальных настроек. Даже на 127.0.0.1:25 (postfix без шифрования и авторизации). Отправка с помощью sendmail работает. Подскажите, пожалуйста, может есть в unit какая-то известная проблема\ограничение из-за которого исходящее соединение может обламываться на ранней стадии? Повторить проблему не сложно: попробуйте запустить redmine 3.4.9 под unit и настроить в нем отправку почты по SMTP. Вместо редмайна при желании можно использовать программу пример из этой статьи: https://launchschool.com/blog/handling-emails-in-rails , вот ёё код https://github.com/iprok/sending_emails_with_rails (я допилил чуть-чуть). Я сейчас обойду проблему, используя sendmail, но готов посильно участвовать в решении проблемы с SMTP. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit: документация как собрать модуль из исходников
Второй вопрос снимается, я смог. Но документацию про то, как правильно собирать unit из исходников, получая в итоге deb-пакеты было бы прекрасно получить. То есть для примера, до 1.8.0 я мог собрать deb'ы с моим значением RELEASE , примерно вот так: RELEASE=2 make unit-ruby -j4 А сейчас методом тыка разобрался, что надо править changes.xml. Хотелось бы перестать тыкать и получаться эту информацию из документации, если это ничему не противоречит. 06.03.2019 02:37, Иван пишет: > Здравствуйте! > > Пытаюсь собрать unit-ruby с ruby из rvm, а потом собрать deb unit-ruby с > RELEASE=2 (unit-ruby_1.8.0-2~stretch_amd64.deb), при этом оставив в > качестве зависимости unit-1.8.0-1. > > Это позволит положить только unit-ruby в наш внутренний репозиторий, а > unit использовать из официальных. > > С unit < 1.8.0 у меня это получалось методом тыка, а с 1.8.0 проблемы. > > Подскажите, пожалуйста, есть ли какая-то документация "как собрать > deb-пакет unit из исходников"? > > Возможно ли в скриптах для сборки unit 1.8.0 сделать так как я хочу? > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
unit: документация как собрать модуль из исходников
Здравствуйте! Пытаюсь собрать unit-ruby с ruby из rvm, а потом собрать deb unit-ruby с RELEASE=2 (unit-ruby_1.8.0-2~stretch_amd64.deb), при этом оставив в качестве зависимости unit-1.8.0-1. Это позволит положить только unit-ruby в наш внутренний репозиторий, а unit использовать из официальных. С unit < 1.8.0 у меня это получалось методом тыка, а с 1.8.0 проблемы. Подскажите, пожалуйста, есть ли какая-то документация "как собрать deb-пакет unit из исходников"? Возможно ли в скриптах для сборки unit 1.8.0 сделать так как я хочу? С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GeoIP
Здравствуйте! Про конвертацию в формат доступный для geo прям свежая идея! Не подскажете, "выдюжит" geo-модуль geoip данные по городам? Там будет ~150 000 записей. Быть может у вас есть наработки для конвертации? С уважением, Иван. 11.02.2019 04:05, Maxim Dounin пишет: > Hello! > > On Fri, Feb 08, 2019 at 11:21:24PM +0500, Илья Шипицин wrote: > >> а какое-то развитие родного модуля будет с учетом новостей от MaxMind? > http://mailman.nginx.org/pipermail/nginx-devel/2019-February/011858.html > > [...] > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fcgiwrap не могу запустить
SCRIPT_NAME равен тому, чему его вы приравняете (по умолчанию) fastcgi_params:fastcgi_param SCRIPT_NAME $fastcgi_script_name; которая в свою очередь описана https://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#var_fastcgi_script_name 25.01.2019 12:13, Victor Sudakov пишет: > Иван wrote: >> Ну вообще я же не телепатически эту инфу получил. Всё достаточно понятно >> написано в https://nginx.org/ru/docs/http/ngx_http_core_module.html#root : >> >> "Путь к файлу формируется путём простого добавления URI к значению >> директивы |root|." > Что касается отдачи статики, то понятно что понятно. А в fastcgi > передаются две переменные, DOCUMENT_ROOT и SCRIPT_NAME, и пока я не > осознал, что SCRIPT_NAME равен REQUEST_URI целиком (а не только его > последней компоненте, как я ошибочно полагал), ничего и не работало. > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fcgiwrap не могу запустить
Ну вообще я же не телепатически эту инфу получил. Всё достаточно понятно написано в https://nginx.org/ru/docs/http/ngx_http_core_module.html#root : "Путь к файлу формируется путём простого добавления URI к значению директивы |root|." 24.01.2019 18:31, Victor Sudakov пишет: > Victor Sudakov wrote: 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or SCRIPT_FILENAME) set and is the script executable?" while reading response header from upstream, client: 10.10.10.3, server: , request: "GET /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:", host: "admin.sibptus.ru" > Не поленился изложить для памяти и Гугла: > https://victor-sudakov.dreamwidth.org/463780.html > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
unit: ошибка send
Здравствуйте. Что в предыдущих версиях unit, что в свежей 1.6 практически сразу после запуска в unit.log появилась запись: 2018/12/15 13:58:24 [error] 6403#6452 *1393 send(54, 7F2D3760, 43) failed (32: Broken pipe) Кроме как сама по себе в логах ошибка вроде нигде не проявилась. debian stretch, unit 1.6 из репов с модулем php 7.0.27-0+deb9u1 . php-приложение под очень высоким rps. Мы хотели бы мониторить логи unit на появление ошибок, следовательно любые подобные непонятки смущают. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ошибка сборки deb nginx 1.15.5
Здравствуйте. Причина в том, что Вы не там смотрите. бинарник nginx скорее всего в одной из директорий sbin. Пробуйте искать его из-под рута. Если не найдете внимательно изучите вывод checkinstall он совершенно точно пишет куда какие файлы кладёт. Но для начала, прежде, чем заниматься самосборкой пакетов, рекомендую получше освоится в используемой ОС. В частности с https://wiki.debian.org/BuildingTutorial или аналогичным под ubuntu. 23.10.2018 20:31, analytic пишет: > Я попробовал собрать nginx 1.15.5 checkinstall 1.6.2 в итоге в системе > (ubuntu 16.04.05x64) не видно nginx. > скрин: https://bit.ly/2yus5aE > Ни при выполнении > ./configure \ > --prefix=/usr/share/nginx \ > --conf-path=/etc/nginx/nginx.conf \ > --http-log-path=/var/log/nginx/access.log \ > --error-log-path=/var/log/nginx/error.log \ > --lock-path=/var/lock/nginx.lock \ > --pid-path=/run/nginx.pid \ > --modules-path=/usr/lib/nginx/modules \ > --http-client-body-temp-path=/var/lib/nginx/body \ > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi \ > --http-proxy-temp-path=/var/lib/nginx/proxy \ > --http-scgi-temp-path=/var/lib/nginx/scgi \ > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi \ > --with-debug \ > --with-pcre-jit \ > --with-http_stub_status_module \ > --with-http_realip_module \ > --with-http_auth_request_module \ > --with-http_v2_module \ > --with-http_dav_module \ > --with-http_slice_module \ > --with-threads \ > --with-http_addition_module \ > --with-http_geoip_module=dynamic \ > --with-http_gunzip_module \ > --with-http_gzip_static_module \ > --with-http_sub_module \ > --with-http_xslt_module=dynamic \ > --with-stream=dynamic \ > --with-mail=dynamic > > ни при make ошибок не было обнаружено. > Подскажите, пожалуйста, в чем может быть причина? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281670,281673#msg-281673 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проблема с SSl
если проблема в утилите openssl то почему servicen nignx reload исцеляет
систему?
На том же сервере работает еще и apache (очевидно с тем же openssl) и он
такой проблемы не имеет
пн, 22 окт. 2018 г. в 14:18, Maxim Dounin :
> Hello!
>
> On Fri, Oct 19, 2018 at 05:55:28PM +0300, Иван Мишин wrote:
>
> > Есть такой конфиг:
> >
> > server {
> > > listen 443 ssl;
> > > server_name test.ru;
> > >
> > > ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem;
> > > ssl_certificate_key
> > > 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf';
> > > ssl_verify_client off;
> > > ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> > > ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH;
> > > ssl_prefer_server_ciphers on;
> > > location / {
> > > proxy_set_header X-Real-IP $remote_addr;
> > > proxy_set_header X-Forwarded-For
> > > $proxy_add_x_forwarded_for;
> > > proxy_hide_header Host;
> > > proxy_set_header X-NginX-Proxy true;
> > > proxy_set_header Host test.loc;
> > > proxy_pass http://test.loc;
> > > proxy_redirect off;
> > > client_max_body_size 300M;
> > > sendfile on;
> > > send_timeout 300s;
> > > }
> > > }
> >
> >
> > Со временем сервер либо перестает работать совсем, либо работает через
> раз.
> > при этом в логах вот такая ошибка:
> >
> > > [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL:
> > > error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT
> > > error:1419D093:SSL routines:tls_process_cke_gost:decryption failed)
> while
> > > SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443
> >
> > Просьба помочь с решением проблемы.
>
> Судя по диагностики, ваши проблемы - где-то в GOST engine. Если
> по условиям задачи её можно выкинуть - очевидным решением будет
> выкинуть. Если выкинуть нельзя - попробуйте поиграться с версиями
> OpenSSL'я и GOST engine, а равно попробуйте грузить ключ из файла,
> а не через engine. Если ничего из этого не поможет - стоит
> стучаться непосредственно к ребятам, занимающимся оной GOST
> engine.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проблема с SSl
Не совсем понял вопрос. Но да, тут используется крипто про
пт, 19 окт. 2018 г. в 18:12, Илья Шипицин :
> Это крипто про?
>
> On Fri, Oct 19, 2018, 7:55 PM Иван Мишин wrote:
>
>> Есть такой конфиг:
>>
>> server {
>>> listen 443 ssl;
>>> server_name test.ru;
>>>
>>> ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem;
>>> ssl_certificate_key
>>> 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf';
>>> ssl_verify_client off;
>>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>>> ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH;
>>> ssl_prefer_server_ciphers on;
>>> location / {
>>> proxy_set_header X-Real-IP $remote_addr;
>>> proxy_set_header X-Forwarded-For
>>> $proxy_add_x_forwarded_for;
>>> proxy_hide_header Host;
>>> proxy_set_header X-NginX-Proxy true;
>>> proxy_set_header Host test.loc;
>>> proxy_pass http://test.loc;
>>> proxy_redirect off;
>>> client_max_body_size 300M;
>>> sendfile on;
>>> send_timeout 300s;
>>> }
>>> }
>>
>>
>> Со временем сервер либо перестает работать совсем, либо работает через
>> раз. при этом в логах вот такая ошибка:
>>
>>> [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL:
>>> error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT
>>> error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while
>>> SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443
>>
>>
>> Просьба помочь с решением проблемы.
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Проблема с SSl
Есть такой конфиг:
server {
> listen 443 ssl;
> server_name test.ru;
>
> ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem;
> ssl_certificate_key
> 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf';
> ssl_verify_client off;
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH;
> ssl_prefer_server_ciphers on;
> location / {
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For
> $proxy_add_x_forwarded_for;
> proxy_hide_header Host;
> proxy_set_header X-NginX-Proxy true;
> proxy_set_header Host test.loc;
> proxy_pass http://test.loc;
> proxy_redirect off;
> client_max_body_size 300M;
> sendfile on;
> send_timeout 300s;
> }
> }
Со временем сервер либо перестает работать совсем, либо работает через раз.
при этом в логах вот такая ошибка:
> [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL:
> error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT
> error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while
> SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443
Просьба помочь с решением проблемы.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit: механизм определения адреса клиента типа realip и передача заголовков
Здравствуйте! Кажется, до этого я отправил личное письмо. Исправляю и отвечаю в рассылку. 09.08.2018 10:37, Валентин Бартенев пишет: > On Wednesday, 8 August 2018 22:53:41 MSK Иван wrote: >> Здравствуйте! >> >> Правильно ли я понимаю, что сейчас unit не умеет передавать в >> $_SERVER['REMOTE_ADDR'] ip клиента, а не проксирующего nginx? >> Переделывать весь наш код, чтоб брал IP из другого заголовка будет жестко. > Да, туда в настоящий момент передается информация из сокета. > > Я бы сейчас решил эту задачу маленькой прослойкой в виде небольшого php > скрипта, который заменяет содержимое $_SERVER['REMOTE_ADDR'] из HTTP_ > заголовка, а далее выполняет уже основной скрипт, запрошенный. Так не > потребуется вносить каких-либо изменений в остальной код, а прослойку > в бущуем можно будет просто убрать. Пока что держимся на php-fpm. У нас много мелких микросервисов, везде внедрять эту прослойку - руководство не поймет. >> Планируется ли это исправить? Когда примерно? Сейчас это единственный >> для меня блокирующий недостаток для внедрения unit массово в продакшен. > Насколько я понимаю, некое подобие realip модуля решило бы Вашу задачу? > Конкретно с адресом бы решило. Но это необходимо, но совсем не достаточно. Например, совершенно точно будет нехватать возможности задать $_server[script_(file)name]. Очень многие продукты используют ЧПУ, соотвественно без задания script_(file)name веб-сервером не обойтись. PATH_INFO туда же. Или даже не ЧПУ, у на видеостриминговый сервис. Мы отадаём плейлсты (*.m3u8) через пыху (x-accell-redirect). Как это реализовать, не задавая SCRIPT_FILENAME? >> Так же интересно, когда планируется ввести возможность передавать вы >> пыху любые заголовки массива $_SERVER, а не только HTTP_*. Это >> собственно является решением и предыдущего вопроса. > Сейчас это не очень простая задача. Сама по себе возможность задавать > массив $_SERVER не представляет сложности, но вряд ли будет полезно > указывать там какие-то константы. А что-то более осмысленное требует > уже реализовывать поддержку переменных или какой-то похожий механизм. > Возможно где-то к концу года, в начале следующего мы что-то подобное > сделаем. > Пока что, похоже, без этого unit в прод не зайдет. Может можно "на скорую руку" переменные вида $_SERVER['HTTP_UNIT_VARNAME'] передавать в $_SERVER['VARNAME'] для PHP? Это бы решило вопрос. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
ignore long locked inactive cache entry
Здравствуйте! Регулярно в логах (пару раз за 5 минут) вижу [alert] 17816#17816: ignore long locked inactive cache entry 9100488b2180c1fc582384712a73791d, count:1 Две прокси на один бэкэнд. Бэкэнд - сервер nginx, отдающий статику. Прокси - два одинаковых сервера, в разных странах. Проявляется только на одном Настроена зоне кеширования proxy_cache_path /var/cache/nginx.hdd/archive_video levels=2:2 keys_zone=a_v:10m inactive=2d max_size=145g use_temp_path=off; В локейшене: proxy_buffer_size 128k; proxy_buffers 32 16k; proxy_set_header host backend; proxy_cache_valid 2d; proxy_cache_use_stale updating; proxy_cache_key "$proxy_host$uri$http_origin"; proxy_cache_lock on; С чем может быть связано? Локейшен обрабатывает не вебсокеты, а статические файлы. Раньше вроде не замечал, не помню когда начало появляться. Читал в поиске, что это может быть связано с медленными ответами, но не понял откуда и куда. Между прокси и бэкэндов - гигабит, в логах бэкэнда медленных ответов не увидел. На проксях медленных ответов (больше 5 секунд) сильно больше, чем сабжевых записей в логах, но это понятно, могут быть пользователи с медленными каналами. nginx -V nginx version: nginx/1.14.0 built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) built with OpenSSL 1.1.0f 25 May 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --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-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.14.0/debian/debuild-base/nginx-1.14.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
unit: 400 ошибка при заголовках, содержащих юникод
Здравствуйте! Только я научил бэкэнд получать геоданные из HTTP_* заголовков, так столкнулся со следующей проблемой. Если в заголовке содержаться какие-то юникодные символы, например, кириллица *или *'ü' , то unit возвращает 400 ошибку. Это баг unit или заголовки по стандарту не умеют юникод? Если баг, готов его оформить на гитхабе. Если не баг и так задумано, то я совсем не понимаю как передавать geoip данные от nginx (использую geoip2 модуль) к бэкэнду за unit. Если у меня клиент из немецкого Baden-Württemberg Region или французского Île-de-France, unit на каждый запрос вернет ему 400. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
unit: будет ли поддержка задания переменных _SERVER ?
Здравствуйте! Сегодня попробовал unit в продакшене. Немного отзывов, вопросы через абзац. Переключил на него matomo(piwik), который обслуживает сайт с 30 посетителей ежедневно. В php-fpm мне давно не нравилось, как он использует память в static режиме (он её, собственно, сжирает как не в себя. последняя php ветки 7.0). Так вот unit оказался прекрасным продуктом с точки зрения производительности. Потребление памяти теперь фискированное и упало в разы. Завтра буду пробовать переводить ядро самого сайта. Вопрос:ы В nginx при работе с php-fpm по fastcgi, можно было подделать любой заголовок, чаще всего это делалось с https. Сегодня мне очень не хватало GEOIP_* заголовков. Если заголовки проксировать, то на бэкэнд они приезжают с префиксом HTTP_, и бэкэнд их не видит. Планируется ли как-то решить этот вопрос? Переменные окружения - это не то, это другой массив. Планируется ли поддержка юникс-сокетов в listener'ах? Статистика? Хотя бы аналогичная nginx_stats. Ну и вы, наверное, в курсе, но у вас документация отстаёт от действительности. Не описаны нововведения из unit 1.2. В остальном - спасибо за прекрасный продукт! С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Необъяснимый 503 при limit_conn
sl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.14.0/debian/debuild-base/nginx-1.14.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Доли секунд в логах
> > Берите $msec и в logstash прогоняйте через фильтр date с форматом UNIX_MS > Ошибся, не UNIX_MS, а просто UNIX. Спасибо, помогло! получил миллисекунды как хотел. 18 января 2018 г., 13:05 пользователь Alexey Remizov <ale...@remizov.org> написал: > On 18.01.2018 13:03, Alexey Remizov wrote: > > On 18.01.2018 12:54, Иван Мишин wrote: > > > >> я логи обрабатываю с помощью logstash и складываю в elastic, а затем > >> просматриваю их с помощью kibana. > >> Мне важно получить в кибане юзерфрендли временную метку с миллисекундами > > > > Берите $msec и в logstash прогоняйте через фильтр date с форматом UNIX_MS > > Ошибся, не UNIX_MS, а просто UNIX. > > -- > С уважением. WBR. > Алексей. Alexey. > > mailto:ale...@remizov.org > jabber:remi...@jabber.ru > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Доли секунд в логах
я логи обрабатываю с помощью logstash и складываю в elastic, а затем просматриваю их с помощью kibana. Мне важно получить в кибане юзерфрендли временную метку с миллисекундами (хотя бы, а лучше микро), т.к. виртуальных хостов много и логов тоже много, поэтому в рамках одной секунды очень много записей попадает и какие запросы за какими следуют не понятно. 18 января 2018 г., 12:38 пользователь Илья Шипицин <chipits...@gmail.com> написал: > я работаю с Log Parser: https://habrahabr.ru/post/85758/ > > where по iso8601 оно умеет из коробки > > (было бы круто в документации поменять пример с time_local на time_iso8601) > > 18 января 2018 г., 14:34 пользователь Vadim A. Misbakh-Soloviov < > ng...@mva.name> написал: > > Это смотря как и чем вы работаете. >> И постгрес, и даже скриптовые языки прекрасно умеют конвертировать unix >> timestamp в человекочитаемое время (более того, именно unix timestamp >> наиболее >> удобный для работы (машинной) формат времени. >> >> В письме от четверг, 18 января 2018 г. 12:32:41 MSK пользователь Иван >> Мишин >> написал: >> > $msec выдает в лог вот такого вида время 1516267749.614 >> > Оно не человеческое, крайне не удобно будет работать с таким форматом >> > >> > 18 января 2018 г., 12:25 пользователь Gena Makhomed <g...@csdoc.com> >> > написал: >> >> > >> > > On 18.01.2018 10:15, Иван Мишин wrote: >> > > >> > > >> > > >> > > На данный момент в логах использую $time_local. >> > > >> > >> Хотелось бы фиксировать не только секунды, но и доли секунд. >> Подскажите >> > >> как >> > >> это можно сделать? >> > >> >> > >> >> > > >> > > >> > > >> > > http://nginx.org/en/docs/http/ngx_http_log_module.html#var_msec >> > > >> > > >> > > >> > > Referer: http://nginx.org/en/docs/varindex.html >> > > >> > > >> > > >> > > -- >> > > Best regards, >> > > >> > > Gena >> > > >> > > >> > > >> > > >> > > ___ >> > > nginx-ru mailing list >> > > nginx-ru@nginx.org >> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > >> > > >> >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Доли секунд в логах
> > $time_iso8601 - во всех смыслах более удобная штука. поддерживается любыми > SQL-серверами и LogParser-ом Тем не менее этот формат не мили ни микро секунды не показывает. 18 января 2018 г., 11:22 пользователь Илья Шипицин <chipits...@gmail.com> написал: > > > 18 января 2018 г., 13:15 пользователь Иван Мишин <simplebo...@gmail.com> > написал: > >> На данный момент в логах использую $time_local. >> > > time_local - это очень странный пример, он есть в документации, > подозреваю, оттуда его тиражируют > > >> Хотелось бы фиксировать не только секунды, но и доли секунд. Подскажите >> как это можно сделать? >> > > $time_iso8601 - во всех смыслах более удобная штука. поддерживается любыми > SQL-серверами и LogParser-ом > >> >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Доли секунд в логах
На данный момент в логах использую $time_local. Хотелось бы фиксировать не только секунды, но и доли секунд. Подскажите как это можно сделать? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.3 beta
Здравствуйте! Я не использую systemd и для меня перечисленное - приложения. Если unit - сервер приложений, то, очевидно, он запускает приложения. С уважением, Иван Прокудин. В письме от суббота, 30 декабря 2017 г. 4:43:31 MSK пользователь S.A.N написал: > > Как по вашему, firefox - это сервис или приложение? Можете обосновать > > почему? > > Я же не ради холивара это писал :) > Клиентские GUI приложения сервисами сложно назвать, но для меня: > PHP-FPM - это сервис > Node.js - это сервис > Python WSGI - это сервис > Go Server - это сервис > > Возможно у меня systemd головного мозга, но в вашем конфиге, раздел > "listeners" я понимаю как директивы для systemd.socket и соответственно > "applications" у меня ассоциируется с директивами для systemd.service, мне > так проще унифицировать свои знание и ваше название Unit очень помогает > сделать связь с unit от systemd. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
Прекрасная новость! А пакеты для debian9? А когда планируется релиз? В письме от пятница, 15 декабря 2017 г. 20:37:37 MSK пользователь Валентин Бартенев написал: > On Friday 15 December 2017 17:57:42 Иван wrote: > [..] > > > А интеграция ruby в ближних планах есть? > > В первом квартале 2018 планируем сделать Ruby и Perl. > > -- > Валентин Бартенев > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
Здравствуйте! В письме от пятница, 20 октября 2017 г. 22:58:00 MSK пользователь Igor Sysoev написал: > > С точки зрения юнита, языки делятся на две категории: > 1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют > некий стандартный интерфейс для встраивания в веб-сервер; > 2) встраивание модуля юнита в приложение: Go, Node.js, Java. > > Первое сделать, как правило, проще. Но перл не в ближних планах, поскольку > его популярность падает. > А интеграция ruby в ближних планах есть? С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Юникс-сокет и fastcgi.
Здравствуйте!
Имеет ли смысл включать keepalive для подключения к php-fpm через юникс-сокет?
Попробовал сейчас включить, используя:
upstream e_php {
server unix:/run/php-fpm-e.socket;
keepalive 200;
}
location ~* \.php$ {
fastcgi_pass e_php;
fastcgi_keep_conn on;
}
Смотрю в статус пула php-fpm, там скорость изменения показателя "accepted conn"
за
секунду (в среднем 500 cps) не изменяется по сравнению с конфигурацией
location ~* \.php$ {
fastcgi_pass unix:/run/php-fpm-e.socket;
}
Я что-то неправильно делаю\понимаю?
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx и смена симлинков
Здравствуйте! В письме от вторник, 28 ноября 2017 г. 21:34:02 MSK пользователь Илья Шипицин написал: > > сделайте тут проксирование на апстрим (в котором перечислены несколько > бекендов) > fastcgi_connect_timeout сделайте минимальным > > > достаточно будет запустить тот или иной бекенд > > (не уверен, что с unix-сокетами получится, в крайнем случае можно на tcp > проксировать) > Мне в итоге помог предложенный чуть ранее и дополненный тут: https:// stackoverflow.com/questions/23737627/php-opcache-reset-symlink-style-deployment/ 23904770#23904770 совет сделать fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $realpath_root; Меня теперь волнует не выполняет ли nginx тот самый "тяжелый" (как описано, например, https://habrahabr.ru/post/266909/) realpath при использовании $realpath_root. По непосредственно вашему способу вопрос только один, учитывая исторически багнутый reload в php-fpm не понятно как запускать\останавливать один пул php, не трогая другие. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx и смена симлинков
Здравствуйте!
nginx 1.12.2, debian 8, php-fpm (5.6)
*# *nginx -V
Есть самописное приложение на php. У него есть две версии: stable и current.
Для
быстрой смены используется следующая схема:
/var/www/stable/ - тут лежит stable
/var/www/current/ - тут лежит current
/var/www/html - симлинк на на /var/www/stable или /var/www/current
В nginx пыха сконфигурирована как
root /var/www/html;
location / {
fastcgi_pass unix:/run/php-fpm.socket;
includefastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
Проблема в том. что при переключение stable->current (и наоборот), которая
происходит примерно так:
# /var/www/html указывает на /var/www/stable , переключаемся на current
rm /var/www/html; ln -s /var/www/current/ /var/www/html
до упора используются файлы из старой директории (stable в примере выше). Не
помогает ни очистка opcache, ни рестарт пыхи. Только restart (возможно reload,
не
уверен) nginx.
Хотелось бы
1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк?
2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в принципе
готовы
поменять воркфлоу, но пока не понимаем как.
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: помогите с проксированием
Максим, большое спасибо за развернутый ответ, осбенно за
>
> В наиболее сложном случае абсолютные адреса оказываются зашиты
> не только в возвращаемых html-страницах (которые, при желании,
> можно пытаться править с помощью sub_filter), но и в каких-нибудь
> бинарных/проприетарных swf-файлах. И поставленная задача вообще
> не решается.
Это как раз мой случай оказался, поэтому свою задачу решу лучше через
поддомены.
13 ноября 2017 г., 16:25 пользователь Maxim Dounin <mdou...@mdounin.ru>
написал:
> Hello!
>
> On Mon, Nov 13, 2017 at 12:08:14PM +0300, Иван Мишин wrote:
>
> > Я догадываюсь какие модули нужны, но все мои попытки реализовать задачу
> > провалились.
> > Может ли кто-то подсказать более точнее?
>
> Более точнее так:
>
> - В простейшем случае задача сводится к тому, чтобы сделать
> proxy_pass внутри соответствующего location'а:
>
> location /site1/ {
> proxy_pass http://xyz.com/;
> }
>
> Тут важно обратить внимание на "/" в proxy_pass - он говорит
> nginx'у, что при проксировании следует менять префикс "/site1/" в
> исходном URI запроса на "/".
>
> Так будет работать, если бэкенд использует относительные адреса
> для ресурсов, возвращает предсказуемые перенаправления (см.
> proxy_redirect) и так далее.
>
> - В наиболее сложном случае абсолютные адреса оказываются зашиты
> не только в возвращаемых html-страницах (которые, при желании,
> можно пытаться править с помощью sub_filter), но и в каких-нибудь
> бинарных/проприетарных swf-файлах. И поставленная задача вообще
> не решается.
>
> Где именно между этими крайними положениями находится ваш сайт -
> известно только вам. А если не известно - то и выяснять,
> соответственно, вам. Постепенно дополняя простейшую конфигурацию
> выше различными подпорками для решения возникающих проблем.
>
> Ну и не следует забывать, что в общем случае - задача не решается.
> И где-то в тот момент, когда возникает необходимость менять
> содержимое возвращаемых страниц с помощью sub_filter - имеет смысл
> задуматься о том, чтобы пойти и переделать бэкенд. Или даже не
> переделать, а просто разобраться с ним чуть получше - часто
> бывает, что бэкенд всё умеет, просто его нужно соответствующим
> образом сконфигурировать.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: помогите с проксированием
Я догадываюсь какие модули нужны, но все мои попытки реализовать задачу провалились. Может ли кто-то подсказать более точнее? 12 ноября 2017 г., 22:38 пользователь Alex Domoradov <alex@gmail.com> написал: > По идее должно хватить rewrite + proxy_pass/proxy_redirect, но может > зависеть от того, как криво реализован сам site1. Возможно еще понадобится > http://nginx.org/en/docs/http/ngx_http_sub_module.html > > 2017-11-12 21:11 GMT+02:00 Иван Мишин <simplebo...@gmail.com>: > >> Есть nginx который занимается проксированием на бекенд. >> как сделать так чтобы при запросе >> xyz.com/site1 >> на бекенд ушел запрос вида xyz.com, но при этом в браузере клиент видел >> xyz.com/site1 >> >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
помогите с проксированием
Есть nginx который занимается проксированием на бекенд. как сделать так чтобы при запросе xyz.com/site1 на бекенд ушел запрос вида xyz.com, но при этом в браузере клиент видел xyz.com/site1 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Нелегальное проксирование сайта средствами nginx
На предмет совпадения с ипом вражеского прокси, конечно же. Вычислять ипы вражеского прокси можно, анализируя логи на частоту запросов с IP. Все IP, rps с которых, выше определенного порога - прокси. Вы же не делаете realip на * ? Собственно, как альтернатива, превентивно можно отрубить вражеские прокси просто поставив limit_req с одного IP. В письме от среда, 30 августа 2017 г. 12:20:11 MSK пользователь Alex Domoradov написал: > > Вариант сходу - проверять $remote_addr, Вам не подойдет? > > проверять на предмет чего? > > 2017-08-30 10:50 GMT+03:00 Иван <ng...@kinetiksoft.com>: > > > > Здравствуйте! > > > > > > > > Вариант сходу - проверять $remote_addr, Вам не подойдет? > > > > > > > > С уважением, Иван. > > > > > > > > В письме от среда, 30 августа 2017 г. 10:38:45 MSK пользователь Dmitry > > Simonov написал: > > > > > Коллеги! > > > > > > > > > > > > А есть какой-то более-менее достоверный способ определить, что вот эти > > > и эти клиенты, - это nginx, который проксирует наш сервис куда-то на > > > левый домен. > > > > > > > > > > > > В моём случае оригинал www.setup.ru, а проксированная нелегальная > > > копия - www.britash.top > > > > > > > > > > > > Цель - запретить проксирование. > > > > > > > > > > > > --- > > > Dmitriy V. Simonov > > > ___ > > > nginx-ru mailing list > > > nginx-ru@nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Нелегальное проксирование сайта средствами nginx
Здравствуйте! Вариант сходу - проверять $remote_addr, Вам не подойдет? С уважением, Иван. В письме от среда, 30 августа 2017 г. 10:38:45 MSK пользователь Dmitry Simonov написал: > Коллеги! > > А есть какой-то более-менее достоверный способ определить, что вот эти > и эти клиенты, - это nginx, который проксирует наш сервис куда-то на > левый домен. > > В моём случае оригинал www.setup.ru, а проксированная нелегальная > копия - www.britash.top > > Цель - запретить проксирование. > > --- > Dmitriy V. Simonov > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ошибки при установке NGINX
Здравствуйте! Судя по логу, Вы уже пытались поставить nginx из репозиториев дистрибутива, а теперь пытаетесь поставить nginx из репозиториев разработчиков nginx. Чтоб все прошло хорошо, удалите хвосты от старого: service nginx stop killall nginx apt-get purge nginx-core nginx И после этого ставьте желаемую версию. С уважением, Иван. В письме от 17 августа 2017 16:01:10 пользователь Andrey_Bushman написал: > Доброго времени суток. > > Ubuntu-16.04-x86_64 (сервер) > > Устанавливаю NGINX: > > apt-get install nginx > > Получаю ошибки: > > > > Setting up nginx-core (1.10.3-0ubuntu0.16.04.2) ... > Job for nginx.service failed because the control process exited with error > code. See "systemctl status nginx.service" and "journalctl -xe" for > details. > invoke-rc.d: initscript nginx, action "start" failed. > dpkg: error processing package nginx-core (--configure): > subprocess installed post-installation script returned error exit status 1 > dpkg: dependency problems prevent configuration of nginx: > nginx depends on nginx-core (>= 1.10.3-0ubuntu0.16.04.2) | nginx-full (>= > 1.10.3-0ubuntu0.16.04.2) | nginx-light (>= 1.10.3-0ubuntu0.16.04.2) | > nginx-extras (>= 1.10.3-0ubuntu0.16.04.2); however: > Package nginx-core is not configured yet. > Package nginx-full is not installed. > Package nginx-light is not installed. > Package nginx-extras is not installed. > nginx depends on nginx-core (<< 1.10.3-0ubuntu0.16.04.2.1~) | nginx-full > (<< 1.10.3-0ubuntu0.16.04.2.1~) | nginx-light (<< > 1.10.3-0ubuntu0.16.04.2.1~) | nginx-extras (<< 1.10.3-0ubuntu0.16.04.2.1~); > however: > Package nginx-core is not configured yet. > Package nginx-full is not installed. > Package nginx-light is not installed. > Package nginx-extras is not installed. > > dpkg: error processing package nginx (--configure): > dependency problems - leaving unconfigured > Errors were encountered while processing: > nginx-core > nginx > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > Как установить nginx? > > Спасибо > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,276085,276085#msg-276085 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
уникальность переменной $request_id
В документации как-то мало описания на эту тему. Хочется знать какова повторяемость этой переменной? И какой шанс повторяемости в случае использования пула nginx серверов (например 6 штук), есть ли какие-то факты или предположения о том с какой вероятностью могут сгенериться одинаковые айдишники на разных nginx серверах? В общем просьба раскрыть тему к ого есть достаточные знание об этой переменной. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Зацикливание на редиректе
Здравствуйте! Бесполезная нагрузка на сервер создается не более, чем от множественных запросов к серверу. Проблема не в сервере, а в неправильном понимании Вами стандарта. Уязвимости никакой нет, что Вам и пытались показать. С уважением, Иван. В письме от 8 августа 2017 08:11:32 пользователь CoDDoC написал: > А вот интересно, от ботов тоже будем требовать соблюдения RFC? > Я воспроизвел ситуацию, как создать бесполезную нагрузку на сервер при > бесконечном редиректе. Правильно я делаю запрос или нет - в данном случае > не важно. Важно то, что оно работает, и у сервера нет встроенных средств > для корректной обработки такой ситуации. По большому счету, это называется > уязвимостьвю. Дальше. господа разрабы, решать вам. Закрыть проблему или > оставить все как есть и подождать, пока эту уязвимость начнут > эксплуатировать. > > Засим позволю себе откланяться, поскольку не имею времени продолжать > бессмысленную дискуссию. Спасибо. > > >Понедельник, 7 августа 2017, 16:12 +03:00 от Валентин Бартенев > ><vb...@nginx.com>:> > >On Monday 07 August 2017 15:26:11 CoDDoC wrote: > >> Ну, хорошо. Пусть в моем примере вообще нет хоста. > >> Тогда что такое https://test.com ? Давайте назовем строкой запроса, суть > > > >проблемы от этого не меняется. > > > >В вашем примере это аргумент командной строки, который не участвует в > >запросе. В строке запроса он не передается. > > > >> В документации так: > >> " $host > >> > >> в порядке приоритета: имя хоста из строки запроса, или имя > >> хоста > > > >из поля “Host” заголовка запроса.," > > > >> Объясните мне, пожалуйста, что понимать как "имя хоста из строки запроса" > >> и > > > >"имя хоста из поля “Host” заголовка запроса". > > > >> Желательно с примером для курла, как особо одаренному. > > > >Что такое строка запроса описано в RFC: > >https://tools.ietf.org/html/rfc7230#section-3.1.1 > > > >Пример с curl: > > > >$ curl -ILH 'Host: www.nginx.org ' -x http://nginx.org:80/ > >http://nginx.org/> > >> Далее, Вы приводите пример с netcat. Аналогично можно использовать > >> telnet. > >> Только ведь после получения Location ему нужно следовать. Полученный > > > >Location: http://nginx.org/ куда возвращает? На HEAD http://nginx.org/ > >HTTP/1.1. > > > >Первый пример netcat как раз содержит http://nginx.org/ в строке запроса > >и как вы можете наблюдать - редиректа нет. > > > >Второй пример не содержит в строке запроса хоста, а в заголовке Host > >содержится www.nginx.org и происходит редирект. > > > >> То же самое, только не вводить построчно: > >> > >> curl -ILH 'Host: www.nginx.org ' https://nginx.org/ > >> > >> И точно такое же зацикливание.___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во inode из-за кеша
Произвел полный сброс кеша, теперь все работает как надо. Спасибо Максим! 21 июня 2017 г., 16:40 пользователь Иван Мишин <simplebo...@gmail.com> написал: > В логи заглядывал еще до создания данной темы. > лог настроен следующим образом > >> error_log /var/log/nginx/error.log notice; > > При этом до недавнего времени в логе проскакивали только сообщения > >> [alert] 5092#5092: send() failed (90: Message too long) > > А теперь еще появились > >> [crit] 5093#5093: unlink() "/tmp/ram/1/52/201e725c28498b88055b145ac7253521" >> failed (2: No such file or directory) > > > Те сообщения о которых говорите вы, в моих логах отсутствуют. > Сегодня произведу плановый рестарт сервера, заодно и кеш сбросится. Буду > наблюдать > > 21 июня 2017 г., 15:46 пользователь Maxim Dounin <mdou...@mdounin.ru> > написал: > > Hello! >> >> On Wed, Jun 21, 2017 at 11:09:00AM +0300, Иван Мишин wrote: >> >> > Максим, кеш дира /tmp/ram/ была забита на 100% 28Гб из 28Гб. Сбросил >> часть >> > кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты >> говорил и >> > начальный конфиг (приведенный в первом письме) стал выглядеть вот так: >> > >> > > proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off >> > > keys_zone=level-1:20m max_size=26000m inactive=1440m; >> > > proxy_temp_path /tmp/cache/nginx/proxy_temp; >> > > proxy_cache_key $server_name$request_uri; >> > >> > >> > Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив >> 2Гб >> > запас на отвлечение cache manager. >> > Но по истечении некоторого времени у меня /tmp/ram/ снова забился до >> 28Гб >> > из "28Гб. Почему так произошло? Нужен больший запас для cache manager ? >> >> Во-первых, если в кеше мусор по результатам старых ошибок, то >> cache manager не сможет за ним нормально следить: он ничего не >> знает про мусор, и соответственно не включает его в размер того, >> что занято кешом. Чтобы привести всё к нормальному состоянию - >> стоит очистить кеш полностью. >> >> Во-вторых, cache manager может не иметь возможности удалять файлы >> и по другим причинам, в частности - элементы кеша могут оказаться >> занятыми из-за падений рабочих процессов и/или утечек сокетов. >> При попытке очистки таких элементов по inactive в лог будут >> писаться сообщения "ignore long locked inactive cache entry" на >> уровне alert (в 1.13.1 то же будет происходить и при очистке по >> max_size). >> >> Основное, что бы я рекомендовал сделать в первую очередь - это >> начать таки заглядывать в логи. Все ваши проблемы наверняка были >> обозначены там неоднократно и на критических уровнях логгирования. >> >> -- >> Maxim Dounin >> http://nginx.org/ >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во inode из-за кеша
В логи заглядывал еще до создания данной темы. лог настроен следующим образом > error_log /var/log/nginx/error.log notice; При этом до недавнего времени в логе проскакивали только сообщения > [alert] 5092#5092: send() failed (90: Message too long) А теперь еще появились > [crit] 5093#5093: unlink() > "/tmp/ram/1/52/201e725c28498b88055b145ac7253521" failed (2: No such file or > directory) Те сообщения о которых говорите вы, в моих логах отсутствуют. Сегодня произведу плановый рестарт сервера, заодно и кеш сбросится. Буду наблюдать 21 июня 2017 г., 15:46 пользователь Maxim Dounin <mdou...@mdounin.ru> написал: > Hello! > > On Wed, Jun 21, 2017 at 11:09:00AM +0300, Иван Мишин wrote: > > > Максим, кеш дира /tmp/ram/ была забита на 100% 28Гб из 28Гб. Сбросил > часть > > кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты говорил > и > > начальный конфиг (приведенный в первом письме) стал выглядеть вот так: > > > > > proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off > > > keys_zone=level-1:20m max_size=26000m inactive=1440m; > > > proxy_temp_path /tmp/cache/nginx/proxy_temp; > > > proxy_cache_key $server_name$request_uri; > > > > > > Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб > > запас на отвлечение cache manager. > > Но по истечении некоторого времени у меня /tmp/ram/ снова забился до 28Гб > > из "28Гб. Почему так произошло? Нужен больший запас для cache manager ? > > Во-первых, если в кеше мусор по результатам старых ошибок, то > cache manager не сможет за ним нормально следить: он ничего не > знает про мусор, и соответственно не включает его в размер того, > что занято кешом. Чтобы привести всё к нормальному состоянию - > стоит очистить кеш полностью. > > Во-вторых, cache manager может не иметь возможности удалять файлы > и по другим причинам, в частности - элементы кеша могут оказаться > занятыми из-за падений рабочих процессов и/или утечек сокетов. > При попытке очистки таких элементов по inactive в лог будут > писаться сообщения "ignore long locked inactive cache entry" на > уровне alert (в 1.13.1 то же будет происходить и при очистке по > max_size). > > Основное, что бы я рекомендовал сделать в первую очередь - это > начать таки заглядывать в логи. Все ваши проблемы наверняка были > обозначены там неоднократно и на критических уровнях логгирования. > > -- > Maxim Dounin > http://nginx.org/ > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во inode из-за кеша
> > Вам же порекомендовали не использовать proxy_temp_path на другом разделе Так так и сделал, почитал доку и приписал параметр use_temp_path=off к своему конфигу. Вот цитата из доки. > Поэтому лучше, если кэш будет находиться на той же файловой системе, что и > каталог с временными файлами. Какой из каталогов будет использоваться для > временных файлов определяется параметром use_temp_path(1.7.10). Если > параметр не задан или установлен в значение “on”, то будет использоваться > каталог, задаваемый директивой proxy_temp_path > <http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_temp_path> для > данного location. Если параметр установлен в значение “off”, то временные > файлы будут располагаться непосредственно в каталоге кэша. 21 июня 2017 г., 11:28 пользователь Vasiliy P. Melnik <ba...@vpm.net.ua> написал: > > > 21 июня 2017 г., 11:09 пользователь Иван Мишин <simplebo...@gmail.com> > написал: > >> Максим, кеш дира /tmp/ram/ была забита на 100% 28Гб из 28Гб. Сбросил >> часть кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты >> говорил и начальный конфиг (приведенный в первом письме) стал выглядеть вот >> так: >> >>> proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off >>> keys_zone=level-1:20m max_size=26000m inactive=1440m; >>> proxy_temp_path /tmp/cache/nginx/proxy_temp; >>> >> > Вам же порекомендовали не использовать proxy_temp_path на другом разделе. > Если Вам он очень нужен - переместите го в тот же раздел, что и основной > кеш, например в > proxy_temp_path /tmp/ram/proxy_temp > > > >> proxy_cache_key $server_name$request_uri; >> >> >> Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб >> запас на отвлечение cache manager. >> Но по истечении некоторого времени у меня /tmp/ram/ снова забился до >> 28Гб из "28Гб. Почему так произошло? Нужен больший запас для cache >> manager ? >> > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во inode из-за кеша
Максим, кеш дира /tmp/ram/ была забита на 100% 28Гб из 28Гб. Сбросил часть кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты говорил и начальный конфиг (приведенный в первом письме) стал выглядеть вот так: > proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off > keys_zone=level-1:20m max_size=26000m inactive=1440m; > proxy_temp_path /tmp/cache/nginx/proxy_temp; > proxy_cache_key $server_name$request_uri; Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб запас на отвлечение cache manager. Но по истечении некоторого времени у меня /tmp/ram/ снова забился до 28Гб из "28Гб. Почему так произошло? Нужен больший запас для cache manager ? 19 июня 2017 г., 10:40 пользователь Иван Мишин <simplebo...@gmail.com> написал: > Максим, спасибо за детальное объяснение, на днях буду внедрять изменения и > наблюдать, по происшествии времени отпишусь о результате. > > 16 июня 2017 г., 22:21 пользователь Vasiliy P. Melnik <ba...@vpm.net.ua> > написал: > > Здравствуйте >> >> Раз уж пошла такая пьянка, то может подскажете, есть какие-то >> противопоказания насчет использования use_temp_path=off >> >> >> 16 июня 2017 г., 17:25 пользователь Maxim Dounin <mdou...@mdounin.ru> >> написал: >> >> Hello! >>> >>> On Fri, Jun 16, 2017 at 04:57:04PM +0300, Иван Мишин wrote: >>> >>> > Крахов файловой системы не было, каталог /tmp/ram отдан исключительно >>> под >>> > кеш nginx. За последнюю неделю набежало 5941794 файлов нулевого >>> размера в >>> > кеш каталоге. >>> > В общем эта проблема очень актуальна для меня и преследует уже не >>> первый >>> > месяц, есть у кого-нибудь идеи как я могу отдиагностировать ситуацию? >>> > Максим, можно подробнее про "кончилось место при копировании из >>> каталога со >>> > временными файлами", не совсем понимаю что ты имеешь ввиду? >>> >>> Если proxy_temp_path и proxy_cache_path находятся на разных >>> файловых системах, то просто переместить временный файл в кеш >>> нельзя, приходится его копировать, создав новый файл. Подробнее >>> про это рассказывается в описании директивы proxy_cache_path: >>> >>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro >>> xy_cache_path >>> >>> Если в процессе копирования произойдёт ошибка, например из-за >>> того, что файловая система, на которой располагается кеш, >>> переполнена, то в логе будет ошибка уровня alert, а в кеше >>> останется лежать недописанный файл. >>> >>> Отмечу в скобках, что если вот это: >>> >>> > > > кеш в ramfs на 28Гб со следующими настройками: >>> > > > >>> > > > > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m >>> > > > > max_size=28000m inactive=1440m; >>> >>> и правда озаначает, что размер ramfs - 28 гигабайт, то результат >>> ожидаем. >>> >>> Вы сказали nginx'у, что начинать чистить кеш надо при превышении >>> размера в 28 гигабайт. Если cache manager отвлечётся хоть немного >>> на другие задачи (а он может заниматься другими кешами, если они >>> есть, или просто уйти спать на 10 секунд, почистив всё) - файловая >>> система переполнится, и будут ошибки. Вам надо менять настройки. >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/ >>> ___ >>> nginx-ru mailing list >>> nginx-ru@nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Не срабатывает realip в блоке if
Здравствуйте!
В конструкции
location /login/
set_real_ip_from proxy_IP;
if ($block_agent) {
return 403;
}
}
Всё, что попадает в блок if ($block_agent == 1), в логи пишется с $remote_addr
проксирующего сервера (proxy_IP), то есть set_real_ip_from не отрабатывает.
set_real_ip_from поместить в блок include nginx не дает. Пока что решил
проблему меняя формат логов для в блоке if, но что это, баг\фича? И можно ли
исправить?
# nginx -V
nginx version: nginx/1.12.0
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.1t 3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --
modules-path=/usr/lib/nginx/modules --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-compat --
with-file-aio --with-threads --with-http_addition_module --with-
http_auth_request_module --with-http_dav_module --with-http_flv_module --with-
http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --
with-http_random_index_module --with-http_realip_module --with-
http_secure_link_module --with-http_slice_module --with-http_ssl_module --
with-http_stub_status_module --with-http_sub_module --with-http_v2_module --
with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --
with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2
-fstack-protector-strong -Wformat -Werror=format-security -Wp,-
D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-
needed -pie'
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во inode из-за кеша
Крахов файловой системы не было, каталог /tmp/ram отдан исключительно под кеш nginx. За последнюю неделю набежало 5941794 файлов нулевого размера в кеш каталоге. В общем эта проблема очень актуальна для меня и преследует уже не первый месяц, есть у кого-нибудь идеи как я могу отдиагностировать ситуацию? Максим, можно подробнее про "кончилось место при копировании из каталога со временными файлами", не совсем понимаю что ты имеешь ввиду? 9 июня 2017 г., 18:38 пользователь Maxim Dounin <mdou...@mdounin.ru> написал: > Hello! > > On Fri, Jun 09, 2017 at 04:26:09PM +0300, Иван Мишин wrote: > > > Всем привет. > > Столкнулся со следующей проблемой: > > nginx последней стабильной версии > > ОС CentsOS 6.9 > > кеш в ramfs на 28Гб со следующими настройками: > > > > > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m > > > max_size=28000m inactive=1440m; > > > proxy_temp_path /tmp/cache/nginx/proxy_temp; > > > proxy_cache_key $server_name$request_uri; > > > > > > Довольно активно растет кол-во inode на ramfs. Стал изучать ситуацию, > > оказалось в кеше лежит куча файлов нулевого размера при чем среди них > есть > > и очень старые (месячной давности например). На 28Гб кеша, оказалось > более > > 6млн Inode задействовано, при этом после удаления нулевых файлов осталось > > всего около 200к inode. > > Вопрос зачем nginx хранит до бесконечности нулевые файлы? Как от этого > > избавиться? > > Файлы нулевого размера в кеше - это не nginx, по крайней мере не > его штатная работа, он просто не умеет ничего подобного создавать. > Либо это последствия каких-то ошибок (кончилось место при > копировании из каталога со временными файлами?), либо просто > результат краха файловой системы. > > -- > Maxim Dounin > http://nginx.org/ > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Растет кол-во inode из-за кеша
Всем привет. Столкнулся со следующей проблемой: nginx последней стабильной версии ОС CentsOS 6.9 кеш в ramfs на 28Гб со следующими настройками: > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m > max_size=28000m inactive=1440m; > proxy_temp_path /tmp/cache/nginx/proxy_temp; > proxy_cache_key $server_name$request_uri; Довольно активно растет кол-во inode на ramfs. Стал изучать ситуацию, оказалось в кеше лежит куча файлов нулевого размера при чем среди них есть и очень старые (месячной давности например). На 28Гб кеша, оказалось более 6млн Inode задействовано, при этом после удаления нулевых файлов осталось всего около 200к inode. Вопрос зачем nginx хранит до бесконечности нулевые файлы? Как от этого избавиться? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кто же сильнее Cache-Control или X-Accel-Expires?
Здравствуйте!
Максим,спасибо за быстрый ответ! Может быть это указать в документации? Пока
что процитированная часть документации, как мне кажется, прямо противоречит
этому поведению.
С уважением, Иван.
В письме от 20 апреля 2017 21:08:33 пользователь Maxim Dounin написал:
> Hello!
>
> On Thu, Apr 20, 2017 at 08:17:07PM +0300, Иван wrote:
> > Здравствуйте!
> >
> > Есть конфиг бэкэнда, вот его кусочек:
> >
> > location ~ \.m3u8$ {
> > expires -1;
> > add_header "X-Accel-Expires" "100"
> > }
> >
> > Как следует из русской и английской документации:
> > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid
> > (кстати, как делать красивые короткие ссылки на документацию, которыми
> > оперирует в этом списке рассылки команда nginx?)
> >
> > > Если в заголовке нет поля “X-Accel-Expires”, параметры кэширования
> > > определяются по полям заголовка “Expires” или “Cache-Control”.
> >
> > То есть можно предположить, что приоритет у X-Accel-Expires.
> > Но нет. Как показывает моя практика и, например, этот вопрос:
> > https://serverfault.com/questions/641367/nginx-using-x-accel-expires-with->
> > > cache-control
> >
> > Приоритет имеет Cache-control. То есть в такой конфигурации на фронтэнде:
> >
> > location ^~ /video/ {
> >
> > proxy_buffer_size 16k;
> > proxy_buffers 32 16k;
> >
> > proxy_cache video;
> > proxy_cache_lock on;
> >
> > proxy_cache_use_stale updating;
> > proxy_cache_key "$proxy_host$uri";
> >
> > proxy_pass http://backend;
> >
> > }
> >
> > m3u8 файлы, проходящие через этот локейшен на приведенный выше локейшен
> > бэкэнда кешироваться не будут. Ситуацию спасает только
> > proxy_ignore_headers Expires Cache-Control;
> >
> > Подскажите, пожалуйста, где ошибка: в nginx, документации или моём
> > понимании того или другого?
>
> Текущая реализация такова, что если до заголовка X-Accel-Expires
> встретится заголовок Cache-Control или Expires, запрещающий
> кеширование совсем, то кеширование будет запрещено.
>
> То же самое с Cache-Control vs. Expires: в соответствии со
> стандартом HTTP/1.1 заголовок Cache-Control имеет приоритет, но
> если до него в ответе был заголовок Expires, полностью запрещающий
> кеширование, то кеширование будет запрещено.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Как правильно кешировать запросы от анонимов?
Здравствуйте!
Достаточно популярная, как мне кажется, проблема. Хочу кешировать запросы к
какому-то локейшену, например, к / , но только от анонимных пользователей. То
есть тех, у которых еще нет для нас никаких кук.
Как это правильно сделать в условиях бэкэнда, который, как, например, извините
за выражение, битрикс, ставит куку типа PHP_SESSID при любом запросе?
То есть по факту мой вопрос сводится к тому, как выполнять
fastcgi_ignore_headers Set-Cookie;
или не выполнять в зависимости от каких-то условий, например, от наличия уже
поставленных пользователю кук.
Пока я создал вот такого монстра (он работает, но мне не нравится):
map $http_cookie $main_cache {
default 0;
"" 1;
}
location = / {
if ($main_cache) {
rewrite ^ /_main_cache/ last;
}
fastcgi_pass unix:/run/php-fpm.socket;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param HTTP_GEOCOUNTRY $geoip_country_code;
}
location = /_main_cache/ {
internal;
#Это чтоб в бэкэнд везде приходил правильный адрес, никто не должен знать про
_main_cache
rewrite ^ / break;
fastcgi_cache main;
fastcgi_hide_header "Set-Cookie";
fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie";
fastcgi_cache_valid 200 10s;
fastcgi_cache_key "/";
fastcgi_cache_use_stale updating;
fastcgi_cache_lock on;
#Аноним после первого посещения не аноним, а так как мы игнорируем Set-Cookie
ставим средствами nginx.
add_header "Set-Cookie" "visited=1; path=/";
fastcgi_pass unix:/run/php-fpm.socket;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param HTTP_GEOCOUNTRY $geoip_country_code;
}
Можно как-то изящнее и феншуйнее? Пожалуйста, не предлагайте переделывать
бэкэнд. Это нереально.
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Кто же сильнее Cache-Control или X-Accel-Expires?
Здравствуйте!
Есть конфиг бэкэнда, вот его кусочек:
location ~ \.m3u8$ {
expires -1;
add_header "X-Accel-Expires" "100"
}
Как следует из русской и английской документации:
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid
(кстати, как делать красивые короткие ссылки на документацию, которыми
оперирует в этом списке рассылки команда nginx?)
> Если в заголовке нет поля “X-Accel-Expires”, параметры кэширования
> определяются по полям заголовка “Expires” или “Cache-Control”.
То есть можно предположить, что приоритет у X-Accel-Expires.
Но нет. Как показывает моя практика и, например, этот вопрос:
https://serverfault.com/questions/641367/nginx-using-x-accel-expires-with-cache-control
Приоритет имеет Cache-control. То есть в такой конфигурации на фронтэнде:
location ^~ /video/ {
proxy_buffer_size 16k;
proxy_buffers 32 16k;
proxy_cache video;
proxy_cache_lock on;
proxy_cache_use_stale updating;
proxy_cache_key "$proxy_host$uri";
proxy_pass http://backend;
}
m3u8 файлы, проходящие через этот локейшен на приведенный выше локейшен
бэкэнда кешироваться не будут. Ситуацию спасает только
proxy_ignore_headers Expires Cache-Control;
Подскажите, пожалуйста, где ошибка: в nginx, документации или моём понимании
того или другого?
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: количество open sockets
> > ... open socket #12 left in connection 5 Нет у меня таких записей в логах. 12 января 2017 г., 19:32 пользователь Валентин Бартенев <vb...@nginx.com> написал: > On Wednesday 11 January 2017 10:21:32 Иван Мишин wrote: > > В логах тишина, nginx самый свежий из стабильных nginx/1.10.2. Сторонние > > модули не использую. > > Как проверить что это именно утечка? И найти где эта утечка? Чтобы вы > могли > > это исправить в будущих версиях. > > > > Имеет смысл удостовериться, что проверялся именно основной лог. Об утекших > соединения nginx обычно сообщает в error_log: > > ... open socket #12 left in connection 5 > > при завершении рабочего процесса. > > > -- > Валентин Бартенев > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во открытых udp сокетов
> > А Вам не шлют часом пакетики с zero windows? Разобрался, нет не шлют. 11 января 2017 г., 15:07 пользователь Иван Мишин <simplebo...@gmail.com> написал: > А Вам не шлют часом пакетики с zero windows? > > Поясните пожалуйста что это такое? > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во открытых udp сокетов
> > А Вам не шлют часом пакетики с zero windows? Поясните пожалуйста что это такое? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Растет кол-во открытых udp сокетов
Проблема сама ушла, но сейчас снова вернулась. nginx имеет кучу процессов в состоянии shutting down > nginx 2245 0.1 0.4 277892 170264 ? S<2016 60:12 nginx: > worker process is shutting down > nginx 2246 0.1 0.4 277892 170268 ? S<2016 60:04 nginx: > worker process is shutting down > nginx 2247 0.1 0.4 277892 170264 ? S<2016 53:58 nginx: > worker process is shutting down > nginx 2248 0.1 0.4 277892 170268 ? S<2016 61:46 nginx: > worker process is shutting down > nginx 2249 0.1 0.4 277892 170264 ? S<2016 60:04 nginx: > worker process is shutting down > nginx 2250 0.1 0.4 277892 170264 ? S<2016 61:02 nginx: > worker process is shutting down > root 12463 0.0 0.3 239260 117740 ? Ss2016 0:02 nginx: > master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > nginx12466 0.1 0.3 225684 117204 ? S<2016 63:19 nginx: > worker process is shutting down > nginx12472 0.2 0.3 226236 117596 ? S<2016 68:23 nginx: > worker process is shutting down > nginx12475 0.1 0.3 226204 117592 ? S<2016 65:29 nginx: > worker process is shutting down > root 34155 0.0 0.0 103336 916 pts/1S+ 11:58 0:00 grep nginx > nginx44094 1.0 0.4 280680 171700 ? S<2016 301:38 nginx: > worker process is shutting down > nginx44095 0.9 0.4 280680 171700 ? S<2016 260:05 nginx: > worker process is shutting down > nginx44096 0.9 0.4 280680 171700 ? S<2016 280:09 nginx: > worker process is shutting down > nginx44097 0.9 0.4 280680 171700 ? S<2016 274:12 nginx: > worker process is shutting down > nginx44098 1.0 0.4 280680 171700 ? S<2016 304:19 nginx: > worker process is shutting down > nginx44099 1.0 0.4 280680 171700 ? S<2016 289:29 nginx: > worker process is shutting down > nginx47185 2.0 0.4 280732 170500 ? S< Jan09 59:39 nginx: > worker process > nginx47186 2.0 0.4 280732 170504 ? S< Jan09 58:10 nginx: > worker process > nginx47187 1.7 0.4 280732 170504 ? S< Jan09 51:09 nginx: > worker process > nginx47188 1.7 0.4 280732 170504 ? S< Jan09 50:46 nginx: > worker process > nginx47189 1.8 0.4 280732 170504 ? S< Jan09 53:27 nginx: > worker process > nginx47190 2.0 0.4 280732 170504 ? S< Jan09 59:42 nginx: > worker process > nginx47191 0.0 0.3 239264 128296 ? SJan09 1:04 nginx: > cache manager process > nginx58834 0.0 0.4 277892 170248 ? S<2016 18:34 nginx: > worker process is shutting down > nginx58835 0.0 0.4 277892 170248 ? S<2016 20:34 nginx: > worker process is shutting down > nginx58836 0.0 0.4 277892 170244 ? S<2016 19:48 nginx: > worker process is shutting down При этом netstat -nap | grep выдает например > tcp0 0 x.x.x.x:49810y.y.y.y:80 > ESTABLISHED 2245/nginx отправляюсь на y.y.y.y (там у меня на 80 порту nginx) и делаю service nginx stop и service nginx start. Но возвращаясь на x.x.x.x я снова вижу > При этом netstat -nap | grep выдает > например tcp0 0 x.x.x.x:49810y.y.y.y:80 > ESTABLISHED 2245/nginx Не пойму почему не отваливается соединение? 30 ноября 2015 г., 10:53 пользователь Aleksandr Sytar <sytar.a...@gmail.com> написал: > > > 30 ноября 2015 г., 10:42 пользователь Иван Мишин <simplebo...@gmail.com> > написал: > >> Проблема в том что не отмирают старые процессы по несколько дней ( видел >> те которые 10 дней даже живут), они то и держат "лишние" соединения. >> >> Вот конкретно сейчас есть процессы от 23 числа.: >> nginx46065 1.5 0.3 237188 133192 ? S< Nov23 151:19 nginx: >> worker process is shutting down >> nginx46066 1.5 0.3 237060 133156 ? S< Nov23 144:16 nginx: >> worker process is shutting down >> nginx46069 1.6 0.3 237008 133836 ? S< Nov23 156:25 nginx: >> worker process is shutting down >> >> Почему они за 7 дней до сих пор не умерли? >> > > Потому что к ним еще подключены клиенты. Убейте клиентов и воркеры сам > закроются > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: количество open sockets
В логах тишина, nginx самый свежий из стабильных nginx/1.10.2. Сторонние модули не использую. Как проверить что это именно утечка? И найти где эта утечка? Чтобы вы могли это исправить в будущих версиях. 9 января 2017 г., 16:32 пользователь Валентин Бартенев <vb...@nginx.com> написал: > On Thursday 29 December 2016 09:47:53 Иван Мишин wrote: > > Есть несколько одинаковых nginx, обслуживающих около 100 хостов. На > каждом > > nginx используется кеш ramfs объемом 30Гб на каждый nginx. Последнее > > несколько недель по непонятным причинам постоянно растет количество > > opensockets. Причем даже в ненагруженные дни рост все равно есть. > Пробовал > > рестартовать ngnix, но opnesockets по прежнему растет. В чем может быть > > проблема? На что обратить внимание? > > Обратить внимание на логи, на версию nginx, на используемые сторонние > модули > и конфигурацию. Ошибки, приводящие к утечки сокетов, время от времени > случаются и исправляются. > > -- > Валентин Бартенев > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
количество open sockets
Есть несколько одинаковых nginx, обслуживающих около 100 хостов. На каждом nginx используется кеш ramfs объемом 30Гб на каждый nginx. Последнее несколько недель по непонятным причинам постоянно растет количество opensockets. Причем даже в ненагруженные дни рост все равно есть. Пробовал рестартовать ngnix, но opnesockets по прежнему растет. В чем может быть проблема? На что обратить внимание? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx alternative for Apache mod_proxy_html
Здравствуйте! http://nginx.org/ru/docs/http/ngx_http_sub_module.html ? С уважением, Иван. В письме от 26 декабря 2016 04:42:16 пользователь milex написал: > Добрый день, коллеги! > > Есть ли в Nginx какая-то альтернатива Apache'вскому mod_proxy_html? > Задача - менять адреса ресурсов в index при использовании Nginx как > reverse-proxy для сайта на Wordpress. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,271702,271702#msg-271702 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx socket fastcgi_params
Здравствуйте! Я думаю не ошибусь, если скажу, что в большинстве инсталляций nginx используется unix-сокет и данные параметры точно передаются, например, прям сейчас у меня в продакшене. Опишите подробнее, с чего Вы предположили, что они не передаются, приведите конфиги и nginx -V. В письме от 16 декабря 2016 05:39:59 пользователь skeletor написал: > Всем привет. > Если подключаться к nginx'y через unix-socket то не передаются > fastcgi-параметры. Как минимум эти: > > fastcgi_param REMOTE_USER $remote_user; > fastcgi_param GEOIP_COUNTRY_CODE$geoip_city_country_code; > fastcgi_param GEOIP_COUNTRY_NAME$geoip_city_country_name; > fastcgi_param GEOIP_REGION$geoip_region; > fastcgi_param GEOIP_CITY $geoip_city; > > Проверяю вот так: > > curl http://domain.dev/test.php > curl --unix-socket /var/run/nginx.sock http://domain.dev/test.php > > Это нормально? Если нет, то как можно исправить? > Спасибо. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,271610,271610#msg-271610 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
failed (36: File name too long)
Коллеги, подскажите при загрузки (PUT) файла по webdav получаю 500 код и ошибку в логах failed (36: File name too long). Загружаю файл следующего вида: /2016/66/77/99/qwertqwertyq/кенапргшщолд_План_переплан_2016__тесттестт___на_подббннааа___пятть_для_ололоолололо___22_от_01.12.2016___без_трололо_2.xls_345fgh34kjhgndg457fndhheriifkkke56923kgisl45lfhn56j4kk67ls84hdlr.csv ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Редирект на необходимый урл в том случае если запрос включает параметры и соответствует паттерну
Здравствуйте!
В письме от 5 ноября 2016 10:19:49 пользователь Gena Makhomed написал:
> On 05.11.2016 8:43, sysadm wrote:
> > Спасибо за ответ, Гена. Я думал уже над чем-то подобным, но это означает
> > что сколько редиректов - столько ифов у нас появится. Т.е. будет
> > несколько сотен - будет несколько сотен ифов. А если приедет следующий
> > список на несколько тысяч подобных редиректов? Нормально ли это и
> > насколько это скажется на производительности?
>
> Тогда http://nginx.org/ru/docs/http/ngx_http_map_module.html
>
> http {
>
> map $request_uri $target_uri {
> /example-category?col=name=filter-var1 /target/link;
> # ...
> }
>
Если сотни или много тысяч, я бы использовал
map $request_uri $target_uri {
include manythousandsofinclude.inc;
}
Тогда файл с инклюдами можно генерировать скриптом и по завершению reloadить
nginx.
> server {
>
> if ($target_uri) {
> return 301 $target_uri;
> }
>
> > Помимо этого с такой конструкцией нгинксу не нравится синтаксис:
> > nginx: [emerg] invalid number of arguments in "return" directive in
> > /etc/nginx/redirects/ecommerce.conf:2
> > nginx: configuration file /etc/nginx/nginx.conf test failed
>
> http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return
>
> Синтаксис: return код URL;
Вы в своем первом сообщении rewrite с return просто перепутали и добавили
permanent, чем ввели топикстартера в заблуждение.
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Применение директивы для определенного IP адреса
В письме от 22 октября 2016 10:50:41 пользователь maxpostal написал:
> #map $http_x_forwarded_for $binary_remote_addr {
> # 5.187.78.183 1;
> #}
> #limit_req_zone $binary_remote_addr zone=perserver:10m rate=1r/s;
> #limit_conn_zone $binary_remote_addr zone=perip:10m;
Закомментированный код измените дословно (не надо ни на что заменять $key!)
на:
map $http_x_forwarded_for $key {
5.187.78.183 1;
}
limit_req_zone $key zone=perserver:10m rate=1r/s;
limit_conn_zone $key zone=perip:10m;
Тогда лимиты будут применены для всех с данным значением $key. Чтоб лимиты не
применялись, значение $key должно быть пустым. Прочитайте, пожалуйста,
описание map в документации, тогда станет понятнее.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Применение директивы для определенного IP адреса
В письме от 17 октября 2016 16:24:17 пользователь maxpostal написал: > Иван, здравствуйте. Спасибо за помощь. > > > limit_req_zone $key zone=perserver:10m rate=1r/s; > limit_conn_zone $key zone=perip:10m; > > то лимиты не работают :( > Если их правильно прописать, они точно работают. :) У меня используются в продакшене. Покажите как конкретно Вы до этого map прописали. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: похоже на багу с syslog nginx
> > для начала: > 1) проверьте логи > 2) проверьте tcpdump'ом на той машине, где nginx, чтобы исключить > разного рода проблемы с сетью Это все уже проверял. Вам же ответили в соседнем треде, созданном вами же: по стандарту > больше 1 килобайта нельзя, но у меня есть куча логов на 10-30кб и больше которые проходят без проблем. всё что больше - доходить не обязано > (точнее - обязано не доходить, но nginx не проверяет) то что доходить не обязаны это понятно. Но nginx то обязан их отправлять. А я слушал tcpdump ом и знаю точно что nginx не отправляет. В этом и вопрос, почему nginx не отправляет? (а не почему не доходит) 14 октября 2016 г., 16:58 пользователь Maxim Dounin <mdou...@mdounin.ru> написал: > Hello! > > On Fri, Oct 14, 2016 at 04:33:04PM +0300, Иван Мишин wrote: > > > Не ужели никто не в курсе почему nginx не отправляет access логи в случае > > описанном выше? > > Вам же ответили в соседнем треде, созданном вами же: по стандарту > больше 1 килобайта нельзя, и всё что больше - доходить не обязано > (точнее - обязано не доходить, но nginx не проверяет). Дойдёт или > не дойдёт - зависит от многих факторов, цифра в 9000 - очевидно, > из размера jumbo frames. > > Да и вообще не стоит забывать, что UDP не является средством > гарантированной доставки. Хотите гарантированной доставки - > пишите локальные файлы. Или в локальный же unix-сокет > syslog-демона, и уже из им отправляйте куда надо надёжным > транспортом. > > -- > Maxim Dounin > http://nginx.org/ > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: похоже на багу с syslog nginx
Не ужели никто не в курсе почему nginx не отправляет access логи в случае описанном выше? 7 октября 2016 г., 17:44 пользователь Иван Мишин <simplebo...@gmail.com> написал: > В ходе разбирательства с прошлым моим вопросом >> >> Добрый день коллеги. >> Заметил что длинные веб логи (например POST запросы) >> Не доходят до syslog сервер . Предположительно все что больше 32к не >> проходит. >> Подскажите есть ли какие-либо ограничения по этому поводу? > > > Выяснил следующую вещь. Если отправлять POST запрос на nginx содержащий > латиницу более 9000 символов, то nginx данное сообщение в логи не > отправляет по syslog. Как проверял, отправлял POST содержащий текст вида > "приветмир" длинна запроса 9000 символов, писал слитно без пробелов. На > принимающем syslog сервере слушал tcpdump ом, тишина. > Nginx настройки: > >> access_log syslog:server=x.x.x.x:514,facility=local4,severity=notice >> main; >> log_format main'$http_host $remote_addr $remote_user [$time_local] >> "$request" $status "$sent_http_content_type" $body_bytes_sent >> "$http_referer" "$http_user_agent" "$http_cookie" $request_time >> "$upstream_addr" NGINX-CACHE-$upstream_cache_status "$request_body" '; > > > > > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
похоже на багу с syslog nginx
В ходе разбирательства с прошлым моим вопросом > > Добрый день коллеги. > Заметил что длинные веб логи (например POST запросы) > Не доходят до syslog сервер . Предположительно все что больше 32к не > проходит. > Подскажите есть ли какие-либо ограничения по этому поводу? Выяснил следующую вещь. Если отправлять POST запрос на nginx содержащий латиницу более 9000 символов, то nginx данное сообщение в логи не отправляет по syslog. Как проверял, отправлял POST содержащий текст вида "приветмир" длинна запроса 9000 символов, писал слитно без пробелов. На принимающем syslog сервере слушал tcpdump ом, тишина. Nginx настройки: > access_log syslog:server=x.x.x.x:514,facility=local4,severity=notice main; > log_format main'$http_host $remote_addr $remote_user [$time_local] > "$request" $status "$sent_http_content_type" $body_bytes_sent > "$http_referer" "$http_user_agent" "$http_cookie" $request_time > "$upstream_addr" NGINX-CACHE-$upstream_cache_status "$request_body" '; ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: размер сообщения отправляемого по syslog
попробовал другой контент POST запроса пропихнуть, прошло 39К. Странно... 7 октября 2016 г., 15:12 пользователь Anton Gorlov <stal...@altlinux.ru> написал: > На сколько помню это ограничение самого syslog > размер 1 сообщение не может превышать размер сетевого пакета-хидеры. > > 07.10.2016 15:05, Иван Мишин пишет: > > Добрый день коллеги. > > Заметил что длинные веб логи (например POST запросы) > > Не доходят до syslog сервер . Предположительно все что больше 32к не > > проходит. > > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
размер сообщения отправляемого по syslog
Добрый день коллеги. Заметил что длинные веб логи (например POST запросы) Не доходят до syslog сервер . Предположительно все что больше 32к не проходит. Подскажите есть ли какие-либо ограничения по этому поводу? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Применение директивы для определенного IP адреса
Здравствуйте!
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone
"Запросы с пустым значением ключа не учитываются. "
То есть делайте что-то типа
map $http_x_forwarded_for $key {
10.0.0.1 1;
}
limit_req_zone $key zone=one:10m rate=1r/s;
location /download/ {
limit_req zone=one burst=5;
}
limit_conn аналогично.
С уважением, Иван.
В письме от 3 октября 2016 09:35:20 пользователь maxpostal написал:
> Здравствуйте!
>
> Подскажите можно ли применять директивы для определенного IP адреса, а
> точнее для всех адресов, кроме указанного.
>
> Использую модули ngx_http_limit_req_module и ngx_http_limit_conn_module, так
> вот, можно ли ограничить их действие для определенного IP, указав, что-то
> типа:
>
> if ($http_x_forwarded_for !~ " ?10\.0\.0\.1?$") {
> location /download/ {
> limit_conn addr 1;
> limit_req zone=one burst=5;
> }
> }
>
> ?
>
> Заранее спасибо.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,270039,270039#msg-270039
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 403 Forbidden
Здравствуйте!
У Вас веб-сервер запущен от одного пользователя, например, nginx, а домашние
директории /home/* (/home/dima) практически всегда доступны на чтение только
для их владельца. Вот отсюда ноги и растут. То есть Вам сразу верно сказали:
проблема с правами на файловой системе. Вопрос не к nginx.
С уважением, Иван.
В письме от 20 сентября 2016 11:41:29 пользователь misha_shar53 написал:
> С файлом как раз все в порядке. Все открывается.
> Проблемы возникают когда обращение идет через localhost.
> http://localhost/index.htm
> А в файле конфигурации указан каталог содержащий этот файл.
> location /term.htm { root /home/dima/www/; }
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,119063,269688#msg-269688
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Странные текст и ключи в cache nginx
Здравствуйте! В письме от 8 сентября 2016 12:05:00 пользователь Kira_Belka написал: > включен кэш nginx. > в закэшированом файле присутствует текст до > HTTP/ Он там присутствовал точно с тех пор, как я туда посмотрел первый раз. Где-то после 1.8.0 точно. И это вполне нормально, так работает кеширование nginx. > проблема проявилась недавно. > В следствие этого кэш не работает валютно. > Проблема в чём-то другом. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Увеличивается RPS и CPS при недоступности бэкэнда
Здравствуйте!
У нас цепочка проксей для стриминга видео (плейлисты - m3u8+чанки - ts): эджи
от пользователей проксируют на ориджины,ориджины на источники видео (source).
Почему-то при выпадании (connection timeout) одного из source взлетает rps и
cps на соотвествующие ориджины. При высокой нагрузке настолько, что все вообще
встает колом.
nginx 1.10.1 под debian 8 из репов на nginx.org.
Конфигурация upstream на эджах:
upstream o-place {
server ip4_1:443 fail_timeout=60 max_fails=3 weight=3;
server ip6_1:443 fail_timeout=60 max_fails=3 weight=3;
server ip4_2:443 fail_timeout=60 max_fails=3 weight=1;
server ip6_2:443 fail_timeout=60 max_fails=3 weight=1;
server ip4_3:443 fail_timeout=60 max_fails=3 backup;
server ip6_3:443 fail_timeout=60 max_fails=3 backup;
keepalive 500;
}
Каждый ориджин тут задублирован по ИП4 и ИП6 (ip4_1 и ip6_1 - это один и тот
же сервер, так же как и ip?_2, так же как и ip?_3), так как иногда между
серверами отваливается по отдельности либо IP6, либо IP4.
У ориджинов в апстримах по одному source:
upstream source_place {
server ip4:443;
keepalive 200;
}
На эджах
proxy_next_upstream error timeout invalid_header http_500 http_502 http_504;
На ориджинах значение по умолчанию не менял.
Спасибо за помощь.
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вместо 304 всегда отдавать 200.
Здравствуйте! А бэкэнда и нет. В смысле отдаем статические файлы с файловой системы. В письме от 15 августа 2016 18:21:27 пользователь Валентин Бартенев написал: > On Monday 15 August 2016 18:14:10 Иван wrote: > > Здравствуйте! > > > > Существует ли возможность заставить nginx всегда отдавать целиком ответ > > 200 с соотвестующим содержимым, а не укороченный 304, когда ресурс не > > изменился? > > > > Пробовал по найденому в интернете: > > if_modified_since off; > > add_header Last-Modified ""; > > > > Не помогает - просто ничего не изменилось. > > > > Зачем это нужно? Глючный клиент не понимает 304. Правильный путь: чинить > > клиент - не подходит по временным соображениям. Клиент починят > > когда-нибудь, а результат нужен как можно быстрее. > > [..] > > Раз ничего не изменилось, то 304 видимо прилетает у вас от бэкенда. > Значит его и нужно править, либо запретить проксирование на него > соответствующих заголовков. > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ограничение количества запросов
В письме от 8 августа 2016 06:21:14 пользователь
nNgzlTtv3k5lzmKRvlmS22tSl8sJr68k написал:
> if ($http_user_agent ~*
> spider|bot|crawl|megaindex|yahoo){ set $bot_key $server_name; }
Здравствуйте!
Тут весьма плохо использовать if:
https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ .
Замените на map:
map $http_user_agent $bot_key {
~spider $server_name;
~bot $server_name;
и т.д.
}
С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: некоторые запросы держат соединение до бесконечности
> > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > ожидается ответ"? Я же написал, что по завершению висяка появляется 500 ответ в логе. Nginx то логирует уже после обработки запроса, вот и нет ничего в логах в момент зависания, после того как зависание проходит в лог идет запись. Из того что я заметил пакеты не пропадают. клиент отправил запрос , сервер его получил. а дальше тишина затем через время клиент делает вторую попытку , сервер опять отправляет и тишина, после нескольких попыток, сервер отвечает кодом 500 клиент это принимает и отваливается. 17 июня 2016 г., 11:08 пользователь Evgeniy Berdnikov <b...@protva.ru> написал: > On Fri, Jun 17, 2016 at 10:48:00AM +0300, Иван Мишин wrote: > > > > > > А в логе что? > > > > В логе пусто. По окончанию "виселицы" появлейтся лог запроса с 500 > ответом > > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > ожидается ответ"? > > > > Сравните дампы трафика на стороне клиента и на стороне сервера. > > > > Аномалий на первый взгляд не заметил > > Как можно "не заметить аномалий", если клиент не получает ответ? :) > > Вы не заметили, что пакеты не доходят от клиента к серверу, или что > пакеты от сервера к клиенту пропадают? Отчего происходит таймаут? > -- > Eugene Berdnikov > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: некоторые запросы держат соединение до бесконечности
>
> А в логе что?
В логе пусто. По окончанию "виселицы" появлейтся лог запроса с 500 ответом
> Сравните дампы трафика на стороне клиента и на стороне сервера.
Аномалий на первый взгляд не заметил
16 июня 2016 г., 16:39 пользователь Pavel Mihaduk <le...@nixkid.com>
написал:
> Ой, прошу прощения, перепутал ящики
>
> On 16 июня 2016 г., at 16:32, Pavel Mihaduk <le...@nixkid.com> wrote:
>
> Готово. Только на wgshop почему-то 504 :)
>
> On 16 июня 2016 г., at 16:10, Иван Мишин <simplebo...@gmail.com> wrote:
>
> Нет, файрвола нет. nginx и httpd крутятся на одном сервере.
>
> 16 июня 2016 г., 15:32 пользователь Илья Шипицин <chipits...@gmail.com>
> написал:
>
>> а между nginx и httpd фаирвол ?
>>
>> 16 июня 2016 г., 17:05 пользователь Иван Мишин <simplebo...@gmail.com>
>> написал:
>>
>>> Всем привет.
>>> Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи.
>>> Есть nginx, за ним httpd.
>>>
>>> Делаю wget или curl на www.example.com/test/request (за этим урлом
>>> стоит php процесс)
>>> Обычно все обрабатывается нормально, но в некоторых случаях curl и wget
>>> повисают, после долгой паузы получаю
>>>
>>> Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания
>>>> соединения истекло) в заголовках.
>>>> Повтор.
>>>
>>> После чего происходит автоматически новая попытка. Соединение постоянно
>>> открыто. Может так висеть днями.
>>>
>>> strace nginx процесса на котором весит соединение выдает
>>>
>>>> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0,
>>>> ptr=0x1}} ---
>>>> rt_sigreturn() = -1 EINTR (Interrupted system
>>>> call)
>>>> epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system
>>>> call)
>>>
>>>
>>> strace wget показывает
>>>
>>>> select(4, [3], NULL, NULL, {275, 67022}
>>>
>>>
>>> Помогите разобраться кто виноват в этой связке.
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
некоторые запросы держат соединение до бесконечности
Всем привет.
Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи.
Есть nginx, за ним httpd.
Делаю wget или curl на www.example.com/test/request (за этим урлом стоит
php процесс)
Обычно все обрабатывается нормально, но в некоторых случаях curl и wget
повисают, после долгой паузы получаю
Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания
> соединения истекло) в заголовках.
> Повтор.
После чего происходит автоматически новая попытка. Соединение постоянно
открыто. Может так висеть днями.
strace nginx процесса на котором весит соединение выдает
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0,
> ptr=0x1}} ---
> rt_sigreturn() = -1 EINTR (Interrupted system
> call)
> epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system
> call)
strace wget показывает
> select(4, [3], NULL, NULL, {275, 67022}
Помогите разобраться кто виноват в этой связке.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Firefox повторно исплользует соединение IPv6 на основании IPv4. Как с этим жить?
В письме от 2 июня 2016 00:25:25 пользователь Maxim Dounin написал: > > [...] > > > > > 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот > > > > баг > > > > надо исправлять. Если кто готов отписаться там, я открою обратно этот > > > > баг. > > > > > > См. аргументы выше. На лицо явное нарушение стандарта. > > > > Если б всё было так просто, поверьте, я бы не отнимал Ваше время. > > Зачистую вопрос состоит лишь в том, чтобы ткнуть пальцем в нужное > место стандарта, при этом грамотно и кратко сформулировать > проблему. > Здравствуйте! Будет ли слишком нагло попросить Вас сформулировать проблему грамотно и кратко? Желательно на английском, ну или я сам переведу. В идеале я буду искренне благодарен любым разумным комментаториям в баге по приведенной ранее ссылке. С уважением, Иван Прокудин. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
