Re: Константа rand() mod perl
On 01/22/17 00:39, ozz wrote:
> Можно ли и как данную инструкцию вызвать один раз при запуске/перезапуске
> рабочего процесса?
> perl_set $c 'sub { return int(rand(99));}';
Можно (но в каждом рабочем процессе будет свое значение).
Создаем модуль, напимер test.pm
etc/nginx/perl_lib/test.pm
package test;
use warnings;
use strict;
use v5.10;
sub get_number {
state $number = int rand(99);
return $number;
}
1;
В nginx.conf пишем:
perl_modules perl_lib;
perl_require test.pm;
perl_set $number test::get_number;
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
[offtop] was: HACK NGINX+DAV
On 12/03/16 05:03, itcod wrote: Буду благодарен если сообщество подскажет где для этих тестов взять бесплатную временную виртуалку с федорой. Без заморочек с инсталяциями оси и излишней настройкой, а то как обычно времени на админскую рутину нет совсем:) У Amazon AWS есть Free Tair - для тестов хватит (ec2 micro instance с ограничением часов). Но если нет опыта использования AWS, то вместо установки ОС время будет потрачено на то чтобы разобраться в запутанном интерфейсе AWS и многочисленных аббривиатурах. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx не отвечает на запросы
On 2016-09-13 04:00, Mikanoshi wrote: FreeBSD 11.0-RC2 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Стабильно пару раз в сутки Nginx перестаёт отвечать на запросы, а все поступающие запросы висят бесконечно, в итоге копятся тысячи подключений. Нагрузки на сервер при этом почти нет. Когда зависнет посмотрите procstat -k PID для зависших процессов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: javascript in nginx
On 09/23/15 21:53, Igor Sysoev wrote: Интересно ваше мнение об JS-интерфейсе к внутренностям nginx’а. Полезно было бы в JS-интерфейсе к nginx иметь возможность: 1. прочитать произвольный локальный файл (аналог sysread в перле) 2. ngx_http_map_uri_to_path() - в ngx_http_perl_module это $r->filename 3. отдать кусочек заданного файла текущим сконфигурированным методом (например через sendfile если в данном location действует директива senfile on). ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Хочу написать патч
On 08/25/15 17:37, paperroot wrote: Хочу написать патч, который будет отдавать контент предварительно setuid'ившись в системного пользователя указанного в конфиге virtual_host'a, для того чтобы обезопасить большое кол-во независимых проектов от разных пользователей, работающих на одном мощном сервере. Лучше посмотреть в сторону POSIX ACL (setfacl) чтобы пользователю nginx можно было выдать права на чтение всех пользовательских файлов, при этом чтобы сами пользователи не могли читать файлы друг-друга. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по производительности.
On 06/11/15 17:41, BieZax wrote: В логах никаких проблем не наблюдается по умолчанию error_log пишется на уровне error, лучше увеличить до notice или warn Голый nginx упирается в ~3rps, если использовать перенаправление на себя же через localhost, то это значение падает до 13000rps 1. показывает ли top 100% загрузку CPU во время теста? 2. общие советы по поводу sysctl: kern.ipc.soacceptqueue=5000 (или больше) net.inet.ip.portrange.randomized=0 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.tcp.fast_finwait2_recycle=1 Число воркеров можно для начала поставить в два раза меньше числа ядер и посмотреть как будет расти результаты при увеличении числа воркреров. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: geoip
On 02/19/15 08:30, slyab wrote: Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается? Вопрос в следующем, некоторые сервисы, в частностиwww.2ip.ru используют этот адрес (по крайней мере мне они сказали туда писать) для геоопределения ip-адресов. Но вот беда - писал в почту, на форму на сайте, и cюда http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю. Данные обновляются (возможно в автоматическом режиме) - diff файлов скачанных в разное время не нулевой. С обратной связью у них хуже, можно разве что поискать людей лично знакомых с сотрудниками nic.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: странность с ssl_session_cache off
On 02/13/15 19:13, Maxim Dounin wrote: Почитай для начала dump трафика. Если мне не изменяет память, Session-ID, который показывает openssl s_client в случае запрета кеша, тщательно придуман локально для эмуляции наличия сессии в случае наличия тикета. Да, так и оно и есть. В дампе session-id нет. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: странность с ssl_session_cache off
On 02/13/15 18:22, Anton Yuzhaninov wrote: ssl_session_cache off; при этом в логах пишется $ssl_session_reused=r openssl s_client показвыет Session-ID: 4A2293CB если добавить ssl_session_tickets off; То Session-ID не выдаётся. Надо почитать rfc5077, я раньше думал, что tickets без session-id работают... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
poodle and broken ssl alerts
После обновления openssl с 1.0.1g до 1.0.1j В логи стали в большом количестве сыпаться сообщения вида: [crit] 767#0: *44215130 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: 192.0.0.225, server: 0.0.0.0:443 В то, что кто то пытается делать downgrade в таком масштабе я поверить не готов. Скорее всего это несовместимость изменений в openssl с какими то клиентами. Кто нибудь разбирался с этой проблемой? Возможно есть какой то workaround чтобы не терять этих клиентов? Хорошая поддержка клиентов в моем случае важнее безопасности. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx + cors
On 09/10/14 12:14, Anton Kiryushkin wrote:
Подскажите, пожалуйста, имеется мистика.
Есть вот такой location:
location ~ \.jpg$ {
expires 1h;
proxy_pass http://host:port;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET, HEAD, OPTIONS;
add_header Access-Control-Allow-Origin *;
}
И все вроде бы хорошо, но если размер файла становится хотя бы 91256 байт, то
эти заголовки не отдаются. Звучит как фантастика, но может быть и правда отдача
заголовков зависит от того, какой объем проксируется. Версия nginx 1.2.4.
1. Смотрите debug log, там бывает много полезного. Можно включить debug лог
тольок для одного IP:
http://nginx.org/r/debug_connection
послать с него тестовый запрос на который должен вернуться большой ответ.
2. 1.2.4 это старая версия, лучше обновиться до 1.6.1
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос про heartbleed
On 04/09/14 13:41, Vladislav Shabanov wrote: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Если очень хочется знать о безуспешных аттаках, то лучше использовать что то типа SNORT. И про heartbleed он должен знать. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Директивы сжатия дублированы?
On 03/14/14 13:22, Заярный Сергей wrote: Встречный вопрос - есть ли внятные статисследования какие контент типы сжимать опасно? В IE6 иногда наблюдались проблемы со сжатым css (ссылки на подробные описания у меня не сохранились). В современных браузерах проблем не должно быть со сжатием любых текстовых данных. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Процессная модель
On 02/26/14 03:17, AlexyFrost wrote: Как известно, форк наследует кучу мусора из родительского процесса: обработчики сигналов, дескрипторы файлов\сокетов, переменные и т.п., словом, память стека и кучи. Мусора в том, что наследуется нет. listen socket нужен. других сокетов, открытых в мастере не должно быть. Обработчики сигналов AFAIK переопределяются, если нужно. То что worker-ы используют память мастера (через COW) очень даже полезно - большая геобаза загруженная мастером будет использоваться всеми процессами и не надо будет загружать её N раз в каждый worker отдельно. В адресное пространство воркеров попадает часть кода и данных, не нужных worker-ом, но ничего плохого в этом нет. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
tab в конце http заголовков
В RFC на HTTP пишут, что пробельные символы в конце и в начале не являются частью значения заголовка: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 The field-content does not include any leading or trailing LWS ... Пробелы nginx отрезает как в начале так и в конце, а вот символы табуляции не трогоает (и при зиписи в лог они превращаются в \x09). Почему такая дискриминация? Проблемы и tab-ы в данном случае должны быть равнозначны: LWS= [CRLF] 1*( SP | HT ) Не могу сказать, что это сильно мешает жить, но в логах изредка встречается такой User-Agent: Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.16\x09 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Что такое: 2 физических / 2 логических ядра?
On 02/05/14 10:10, tfox wrote: Выделенный сервер с процессором Intel Atom D525. В описании к серверу сказано: это двухъядерный процессор ... но благодаря технологии HyperThreading, способен обработать четыре потока за один раз. Как это понять? Вообщем моя проблема в том, что я не знаю какое значение установить для директивы worker_processes в конфигурационном файле nginx.conf Оптимальное число worker_processes зависит от множества параметров: - задач выполняемых nginx - объема свободной памяти - загрузки процессора другими задачами (не nginx). Если на сервере ничего кроме nginx нагрузку не создает, то ставьте 4. Если память/CPU нужны кому то ещё - ставьте 2. Если nginx активно раздаёт контент с дисков и часто блокируется на запросах к диску - worker_processes лучше поставить значительно больше 4, конкретное значение лучше определить экспериментально. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Боевая конфигурация
On 01/22/14 18:05, Dimka wrote: Подскажите, есть какие-то особенности для боевой конфигурации NGINX ? Например ограничения по рейту, Сильно зависит от того, какой у вас бэкенд и есть ли запас его производительности. Какая ширина канал и хватает ли его. Универсального совета дать нельзя. Начать стоит с настройки мониторинга работы сайта и дальше смотреть что работает медленно или какого ресурса сервера не хватает. выключение ненужных модулей и т.п. Модули с которыми скомпилирован nginx (официальные) очень мало влияют на производительность (а некоторые не влияют совсем). Так что специально прилагать усилия для сборки nginx с отключением всех ненужных модулей не стоит - проще использовать готовые бинарные пакеты: http://nginx.org/ru/linux_packages.html С 3d-party модулями по-другому - они могут иметь очень разное качество и использовать их стоит только если: 1. функциональность модуля действительно очень нужна. 2. вы знаете, что модуль имеет правильную архитектуру и достаточно высокое качество кода. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_pass https
On 01/20/14 20:03, Anton Kiryushkin wrote: Первичный вывод сделан на основе прописывания на втором nginx в конфиге хоста опций: set_real_ip_from real_ip_header Еще на 1-м nginx нужно proxy_set_header $remote_addr; ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_pass https
On 01/20/14 20:28, Anton Kiryushkin wrote: Да, это само собой. На 1-м у меня сейчас так: proxy_set_header X-Real-IP $remote_addr; Ну тогда нужно смотреть debug log на 2-м nginx. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Авторизация
On 21.01.2014 00:40, Михаил Монашёв wrote: Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А на стороне сервера считаешь хэш от логина, пароля, подсети и salt и смотришь, равен ли он тому, что пришёл в куках. Я не специалист по криптографии, но насколько понимаю просто хэша тут недостаточно, нужен HMAC. В инете на эту тему за 5 минут нашел только такую статью: http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ Но встречал и более наглядные объяснения, почему нельзя в куке для авторизации хранить просто хэш и нужен именно HMAC. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Отдача больших файлов
On 01/14/14 14:57, Anton Sayetsky wrote: 14 января 2014 г., 11:28 пользователь Anton Yuzhaninov cit...@citrin.ru написал: 1. Собрать ядро с увеличенным до 1 Мб MAXPHYS options MAXPHYS=(1024*1024) Поискал - как-то мало информации по этому поводу. А та, что есть - в основном очень старая. Впрочем, внимания всё равно стоит. Интересно, почему это не default, если действительно помогает. 1. Есть небольшая вероятность, что существуют драйвера для SCSI/ATA-контроллеров неявно (т. е. из кода это не очевидно) предполагающие, что к ним не может придти запроса больше 128 Кб (текущий MAXPHYS). Но проблем в этом месте стоит ожидать разве что со старым и экзотическим железом. 2. Большой MAXPHYS может быть плох для систем с очень маленьким объемом памяти т. к. на эту константу завязаны размеры некоторых буферов в ядре. И для 32-х битных систем, т. к. резервируется KVA, которого на 32-х битных системах мало. 3. На популярных синтетических тестах прирост от увеличения MAXPHYS небольшой. Подробнее об этом можно почитать в этом треде: http://lists.freebsd.org/pipermail/freebsd-arch/2010-March/009974.html Но для раздачи больших файлов эффект от увеличения MAXPHYS может быть вполне ощутимым: http://mailman.nginx.org/pipermail/nginx-ru/2009-February/022197.html 2. Подобрать оптимальное значение для sysct kern.ipc.sendfile.readahead Хм... root@jnb:~# uname -srm FreeBSD 9.2-RELEASE-p2 amd64 root@jnb:~# sysctl -a | grep sendfile | wc -l 0 root@jnb:~# :~ uname -srm FreeBSD 10.0-PRERELEASE amd64 :~ sysctl -d kern.ipc.sendfile.readahead kern.ipc.sendfile.readahead: Number of sendfile(2) read-ahead MAXBSIZE blocks А MFC в 9-ку похоже не сделали... Впрочем это не актуально учитывая что sendfile на ZFS не так полезен как на UFS. А вот это есть: jason@jnb:~$ sysctl vfs.read_max vfs.zfs.zfetch.array_rd_sz vfs.read_max: 32 vfs.zfs.zfetch.array_rd_sz: 1048576 ЕМНИП для UFS (ext2fs, vfat, etc) - это кол-во кластеров, а для ZFS, видимо - кол-во байт. vfs.read_max нужен для обычного чтения файлов и да, его стоит увеличивать. Но влияет ли это на sendfile не знаю, надо смотреть. Вполне возможно что без его увеличения sendfile readahead работать не будет. С ZFS работал мало и про vfs.zfs.zfetch.array_rd_sz ничего не скажу. для отдачи с ZFS всегда рекомендовали sendfile выключать, НЯП для избежания double-buffering. Да, похоже что senfile на ZFS использовать не стоит. Без sendfile можно попробовать output_buffers 1 1M; плюс можно попробовать aio и directio (вместе и по отдельности). ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: freebsd network tuning
On 01/12/14 23:55, Михаил Монашёв wrote: Признаюсь, что не заметил каких-то ощутимых ускорений от этого тюнинга, Большая часть тюнинга не для ускорения, а для того, чтобы при достижении определённой нагрузки X сервер не превратился в тыкву, несмотря на то что свободная память ещё есть, а CPU загружен не на 100%. Соответственно нужно использовать утилиты для создания большой нагрузки и смотреть какую максимальную нагрузку сервер может выдержать с тюнингом и без. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.5.8
On 12/17/13 18:40, Михаил Монашёв wrote: Что делает этот параметр. В документации пока ничего про него нет. http://en.wikipedia.org/wiki/TCP_Fast_Open Позволяет сэкономить на повторной установке соединений. Имеет смысл в том случае, если на то чтобы держать keep alive ресурсов не хватает. Но поддержка клиентами пока не очень широкая, чтобы это имело заметный эффект. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Системные сбои в виртуалке VMware FreeBSD+Nginx+proxy cache+tmpfs
On 12/16/13 12:28, Dmitriy_K wrote: Имеется виртуалка VMware vSphere, в которой работает реверс-прокси FreeBSD 9.2 +Nginx+proxy_cache+tmpfs Вряд ли это связано с nginx или tmpfs. Дисковый массив быстрый, оперативки и процессорной мощности с избытком. Настроен и прекрасно работает ntpd (stratum 1). В случае VMware, ntpd лучше запускать только на голом железе, а в виртуалках его отключать и получать время через VMware Tools: https://support.ntp.org/bin/view/Support/VMWareNTP С непредсказуемой периодичностью от недели до трёх месяцев происходит системный сбой, при котором в системе останавливается системный таймер (то, что обеспечивает выдачу времени программам и командам типа date). На этом же физическом сервере есть другие виртуалки? Если другие виртуалки есть и с ними не возникает, то можно предположить что проблема не из за железа, и копать нужно в сторону взаимодействия VMware и гостевой OS. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проблема с загрузкой изображений при использовании limit req. Как побороть?
On 11/28/13 23:47, Sferg wrote:
location ~ ^.+\.php(?:/.*)?$ {
limit_req zone=reqPerSec1 burst=5 nodelay;
include conf.d/php.conf;
}
В результате получается, что при загрузке html-странички, css и картинки
грузятся исправно, даже если часто понажимать F5, а вот при вызове phpinfo,
логотипы пропадают после первого же обновления странички.
Потому что логотипы для phpinfo генерятся тем же самым php.
Не поленитесь посмотреть через Firebug или аналогичные инструменты других
бразуеров.
Ну и логи nginx смотреть то же бывает полезно.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
On 11/06/13 15:53, Eugene Mychlo wrote: 2. Есть ли возможность в основном запросе получить, в виде переменных, заголовки возвращаемые auth-подзапросом? Просто есть желание заменить X-Accel-Redirect, и проксировать на разные бэкенды в зависимости от того, что вернул auth-бэкенд. есть: http://nginx.org/r/auth_request_set ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: почему при запросе на 443 порт я попадаю не на прописанный в конфиге бэкэнд
On 10/16/13 16:53, Vladimir Skubriev wrote: 2. Почему браузер после ввода запроса https://redmine.examplelab.com открывает страницу без https, т.е. http://redmine.examplelab.com и соответсвенно я вижу страницу backendredmine Возможно бэкенд выдает редирект на версию без http, посмотрите все запросы от браузера через firebug или аналогичные инструменты. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
allow/deny and return
В такой конфигурации:
location /closed {
allow 10.1.1.1;
deny all;
return 200 secret\n;
}
allow/deny ни на что не влияют.
IMHO стоит написать об этом в документации, момент не очевидный с первого
взгляда.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ошибки SSL при отдаче файлов.
On 09/06/13 13:32, gatesat wrote: При отдаче файлов без использования SSL все ОК, при отдаче файлов с использованием SSL файлы отдаются, но в логах я вижу много записей SSL_get_error: 3 ... 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_get_error: 3 То что сообщение выводится на уровне debug намекает на то, что на него можно не обращать внимание. Особенно если все работает. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GEO модуль и количество префиксов
On 08/23/13 21:51, Gelun, Artem wrote: Подскажите пожалуйста какое максимальное количество префиксов в GEO-модуле допустимо? Зависит только от объема RAM, но стоит учитывать, что при большом числе префиксов возрастет нагрузка на CPU (и время ответа). Если у вас больше миллиона префиксов, то стоит подумать об уменьшении их числа. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: freebsd - Can't locate nginx.pm
On 07/08/13 17:05, denis wrote: То есть это особенность системы портов, приводящая к таким вот багам... Баг, это установка модулей в major.minor.patchlevel (как было раньше) и наконец то это исправили. Лучше поздно, чем никогда... Между 5.10 и 5.12 не так много отличий, так что все таки рекомендую обновиться. понятно, спасибо. Какой файл поправить, чтобы вернуть major.minor.patchlevel cd /usr/ports svn diff -c 320679 Mk/bsd.perl.mk ~/patch-r320679 patch -R ~/patch-r320679 после этого пересобрать nginx ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[offtopic] perl (was Re: freebsd - Can't locate nginx.pm)
On 07/08/13 17:34, denis wrote: а что делать тем, у кого в продакшене именно на 5.8 привязка? Переходить на центос 5, где эта версия прибита гвоздями и исключает какую-либо замену в принципе кроме насильственной компиляции поверх? У нас были проблемы с ухода с 5.8, и требовали переписывания примерно 20 своих модулей. Не полностью конечно, но работы было достаточно. Что мешало оставить эти версии не трогая, кроме ЧСВ? Поддержка большого числа версий perl-а, требует дополнительных усилий от тех, кто поддерживает порты perl-а и Mk/* (а поддержка нужна, потому что инфраструктура портов развивается и иногда требует изменений в портах). Поддерживать 5.10 который вышел в 2009-м и сейчас EoL желающих нет. А вообще текущая стабильная версия perl-а уже 5.18.0 (но в портах пока нет). Если у вас много perl-ового кода, который сложно изменить для работы с новыми версиями perl, то проще сделать так: 1. nginx и весь остальной перловый софт разнести по разным jail-ам (или вирт. машинам, если они есть). 2. В джайле с nginx использовать современный perl В джайле с perl-овым софтом ставить нужный perl не из портов, а через App::perlbrew, а модули ставить через Carton (и не обновлять, потому что рано или поздно столкнетесь с тем, что модулю нужна более свежая версия перла, чем есть). Я поддерживаю некоторый (не очень маленький) объем perl-ового кода и после 5.10 переход на последующие версии требовал простых изменений максимум нескольких строчек кода (с конструкциями, давно объявленными устаревшими типа if (defined(@array)) ). Из того, что я помню - сложным был только переход 5.6 - 5.8, когда сильно поменялась работа с unicode. Ну и полезно иметь тесты. Возможность прогнать make test на новой версии перла экономит время (хотя, конечно не гарантирует отсутствие багов) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: freebsd - Can't locate nginx.pm
On 07/08/13 18:28, denis wrote: root@cs3990:/usr/ports/lang/perl5.16# perl-after-upgrade perl-after-upgrade: Command not found. root@cs3990:/usr/ports/lang/perl5.16# locate perl-after-upgrade /usr/local/bin/perl-after-upgrade /usr/local/man/man1/perl-after-upgrade.1.gz root@cs3990:/usr/ports/lang/perl5.16# /usr/local/bin/perl-after-upgrade /usr/local/bin/perl-after-upgrade: Command not found. и как теперь это делается? Теперь perl-after-upgrade не нужен. Раньше после обновления с 5.x.y на 5.x.(y+1) нужно было запускать perl-after-upgrade Теперь после обновления с 5.16.3 на 5.16.4 (когда он выйдет) ничего делать не нужно будет. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Переопределение заголовка Connection
On 07/02/13 14:07, Александр Бабин wrote: more_set_headers 'connection: keep-alive'; break; error_page 404 = @404; error_page 502 = @502; error_page 504 = @504; } но в этом случае в браузер приходит Connection : close, keep-alive, и здесь, согласно документации, должно приходить только одно значение. Так что , как будут вести себя разные типы браузеров - неясно. Как быть в этом случае ? как заставить отдавать Connection: keep-alive ? если это возможно.. Для начала попробуйте воспроизвести проблему без сторонних модулей. Еще полезно указывать версию nginx (а лучше вывод nginx -V). ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: lua модуль
On 06/04/13 20:14, Gena Makhomed wrote: есть какие-то вещи, которые нельзя сделать с помощью встроенного perl-модуля, но можно сделать с помощью этого стороннего lua-модуля? Есть. Используя встроенный perl можно выполнять операции, которые не блокируются и имеет очень ограниченный доступ к функциям nginx (см. http://nginx.org/en/docs/http/ngx_http_perl_module.html#methods) LUA модуль позволяет делать многое из того, что можно сделать написав модуль к nginx на C. Например он позволяет делать подзапросы. Обратная сторона такой гибкости - сложность самого LUA-модуля и как следствие баги в нём. учитывая, что у lua более простой синтаксис, чем у perl может быть имеет смысл из коробки встроить lua в nginx? (по крайней мере, в ядра netbsd и linux этот язык уже встроили - про linux: http://www.opennet.ru/opennews/art.shtml?num=36991) тогда уж точно можно будет программировать на конфигах nginx. и модуль rewrite тогда можно будет реализовать используя lua. Программировать на конфигах nginx в общем случае не очень хорошая идея и в большинстве случаев приводит к запутанным и плохо работающим конфигах, в которых кроме их писателя никто не разберется. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Задержки при proxy_cache + HLS
On 05/27/13 14:16, Андрей Василишин wrote: Ситуация такая, нгинкс с proxy_cache стоит перед FMS, и все хорошо, когда размер фрагмента больше 1Мб, кусок сразу отдается пользователю, когда размер меньше 1Мб, почему-то идет задержка 1с. Добавьте $upstream_response_time в лог, чтобы видеть где задержка - между клиентом и nginx или между nginx и бэкендом. Ну и далее стоит поизучать tcpdump для такого медленного запроса. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: $scheme ~* htt(p|ps)
On 05/27/13 19:00, Рома Слєпчик wrote:
Это понятно, ну а как тогда сделать правильно переадресанию с
https://my.site.com https://my.site.com/manager на https://my.site.com/manager
server {
server_name my.site.com;
listen 80;
return 301 https://my.site.com/manager;
}
server {
server_name my.site.com;
listen 443;
ssl on;
location = / {
return 301 https://my.site.com/manager;
}
location /manager {
...
}
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ограничения по количеству записей в map
On 04/09/13 18:10, Oleg Motienko wrote: Существуют ли ограничения по количеству записей в map ? Требуется поместить в map список соответствия hostname/url внутреннему идентификатору и передавать идентификатор на backend в заголовках. Количество в 20-30 тыс записей не будет проблемой? 20-30 тыс записей это не много, но может на этапе конфигураци выдать ошибку, тогда нужно будет увеличить map_hash_max_size (и в некоторых случаях map_hash_bucket_size) подробнее см. в http://nginx.org/ru/docs/hash.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
