Re: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or directory)
> А откуда для алпайна пакет с юнитом взят? > https://pkgs.alpinelinux.org/packages?name=unit*=edge=x86_64 > Там вероятно неправильно задан --tmp путь (или вообще не задан и смотрит > по умолчанию в "tmp" внутри рабочей директории). Именно так и оказалось :( > Можно переопределить на старте: unitd --tmp=/tmp Именно так и сделали, да. В враппере-запускалке указали вручную --tmp /tmp (без "=", впрочем, но работает и так) > > Оно не задокументировано пока, ибо есть вероятность, > что реализация будет изменяться: Ну, было бы хорошо, если бы не менялась (ну, или по крайней мере, в лучшую сторону, а не в сторону пропадания крутилки) :) Будем иметь в виду, спасибо! :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or directory)
> > Похоже на некорректную настройку client_body_temp_path (несуществующий > > путь): > > https://nginx.org/ru/docs/http/ngx_http_core_module.html#client_body_temp > > _path > В смысле, значение наверняка не задано в конфигурации совсем и тогда > используется заданное при сборке значение, а внутри контейнера нет > соответствующего каталога. Проще всего задать в конфигурации правильный > путь куда-нибудь в /tmp или в /var/tmp, смотря что есть в контейнере. 1) Речь не про сам NginX, а про NginX Unit (отдельный application server). 2) увы, и /tmp и /var/tmp там есть. И доступ у юнита туда, вроде, тоже есть. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or directory)
Здравствуйте, сообщество и уважаемые разработчики! На одном из проектов мы используем Docker-контейнеры с alpine linux, в которых стоит Unit с питоно-модулем, а так же задеплоенное Django-приложение. И вот уже на втором проекте мы сталкиваемся с ошибкой, процитированной в заголовке при сохранении данных из админки джанго. Что интересно, данные сохраняются в базу, и там вообще копеечный объём. Если честно, я не очень понимаю что именно происходит в блоке if (что именно за функция nxt_slow_path и что она делает. Так и не удалось найти её определение): https://github.com/nginx/unit/blob/ 65799c7252e56d287d967bf3f036a10d5764f82c/src/nxt_h1proto.c#L907-L913 поэтому и не имею понятия как бы можно было эту проблему обойти или починить. К сожалению, в alpine нету debug-сборки юнита, а собирать самим - очень не хочется. А если взять "официальный" докероимейдж юнита (на основе дебиана) - всё работает... Но, всё же очень хотелось бы, чтобы alpine'овая сборка тоже работала... Так что не могли бы вы помочь понять суть происходящего и подсказать как вылечить? P.S. как я вижу выше по коду, более глобальной причиной является то, что (body_length > body_buffer_size). Однако, я что-то нигде в документации юнита не могу найти крутилку максимально разрешённого body_buffer_size... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[Unit] настройка формата access_log'а
Дорогие разработчики, подскажите, пожалуйста, а возможно ли изменение формата access_log'а в Юните (на манер того, как это реализовано в самом NgX)? Особенно волнуют именно переменные-плейсхолдеры (например, возможность добавить какой-либо HTTP-заголовок из переданных клиентом. Например, это ОЧЕНЬ актуально для случаев когда Unit стоит за NginX'ом (соответственно, клиентские IP превращаются в тыкву). Ещё больше актуальность возрастает когда оба они в докере (и нет возможности на стороне NgX вести по-хостовые логи). // а общий сетевой сислог для сбора логов пока что не хочется использовать :'( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.10.0
А про новые релизы Unit'а тут не было анонсов потому что для него (юнита) завели свой список рассылки? Или просто забыли? :) // или просто до меня они не дошли и оба осели в спаме? :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[Unit] Миграция с fastcgi и её подводные камни
Здравствуйте! Пытаясь смигрировать очередной проект с 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
Re: NginX крошится с libperl-5.30
Gentoo. Perl из собран из дистрибутивного пакета. Nginx — я в своём репозитории мейтейню отдельный пакет (с поддержкой сборки с дополнительными модулями, и работаю над выносом их в динамические). В соседней ветке я только что опубликовал вывод с дебагом. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: NginX крошится с libperl-5.30
Поправка: оно не падает в таком положении (даже на той машине) ТОЛЬКО если цепляться по -p (без дебага, замечу, падает. Так что странно). Попробовал запустить напрямую под gdb, получил такое: ``` #0 0x7492d0c7 in raise () from /lib64/libc.so.6 #1 0x7492eaf9 in abort () from /lib64/libc.so.6 #2 0x749242a9 in ?? () from /lib64/libc.so.6 #3 0x74924331 in __assert_fail () from /lib64/libc.so.6 #4 0x74e1d28f in S__invlist_len (invlist=0x55ea8078) at invlist_inline.h:49 #5 0x74e48074 in Perl__invlist_intersection_maybe_complement_2nd (my_perl=0x55dd5c60, a=0x55ba4470, b=0x55ea8078, complement_b=true, i=0x7fff7c50) at regcomp.c:9752 #6 0x74e71842 in S_populate_ANYOF_from_invlist (my_perl=0x55dd5c60, node=0x558ee2c8, invlist_ptr=0x7fff7c50) at regcomp.c:14827 #7 0x74e8a3cb in S_regclass (my_perl=0x55dd5c60, pRExC_state=0x7fff8da0, flagp=0x7fff8454, depth=5, stop_at_1=false, allow_mutiple_chars=false, silence_non_portable=false, strict=false, optimizable=true, ret_invlist=0x0) at regcomp.c:19069 #8 0x74e672b7 in S_regatom (my_perl=0x55dd5c60, pRExC_state=0x7fff8da0, flagp=0x7fff8454, depth=4) at regcomp.c:13332 #9 0x74e604a0 in S_regpiece (my_perl=0x55dd5c60, pRExC_state=0x7fff8da0, flagp=0x7fff8570, depth=3) at regcomp.c:12457 #10 0x74e5fcd8 in S_regbranch (my_perl=0x55dd5c60, pRExC_state=0x7fff8da0, flagp=0x7fff8618, first=1, depth=2) at regcomp.c:12377 #11 0x74e5d0d2 in S_reg (my_perl=0x55dd5c60, pRExC_state=0x7fff8da0, paren=0, flagp=0x7fff8ad8, depth=1) at regcomp.c:12088 #12 0x74e3ebf7 in Perl_re_op_compile (my_perl=0x55dd5c60, patternp=0x0, pat_count=1, expr=0x55dee908, eng=0x7532b9a0 , old_re=0x0, is_bare_re=0x0, orig_rx_flags=0, pm_flags=1073741824) at regcomp.c:7705 #13 0x74d43d43 in Perl_pmruntime (my_perl=0x55dd5c60, o=0x55dee948, expr=0x55dee908, repl=0x0, flags=1, floor=0) at op.c: 7130 #14 0x74e0e38f in Perl_yyparse (my_perl=0x55dd5c60, gramtype=258) at perly.y:1234 #15 0x750080ed in S_doeval_compile (my_perl=0x55dd5c60, gimme=2 '\002', outside=0x0, seq=183, hh=0x0) at pp_ctl.c:3502 #16 0x7500f64e in S_require_file (my_perl=0x55dd5c60, sv=0x55b9ce10) at pp_ctl.c:4322 #17 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at pp_ctl.c:4346 #18 0x74eb6c4a in Perl_runops_debug (my_perl=0x55dd5c60) at dump.c:2537 #19 0x74d7e142 in Perl_call_sv (my_perl=0x55dd5c60, sv=0x55b9cde0, flags=13) at perl.c:3043 #20 0x74d89318 in Perl_call_list (my_perl=0x55dd5c60, oldscope=6, paramList=0x55f9e480) at perl.c:5088 #21 0x74d586c0 in S_process_special_blocks (my_perl=0x55dd5c60, floor=171, fullname=0x55f70cd8 "BEGIN", gv=0x55f9e558, cv=0x55b9cde0) at op.c:10471 #22 0x74d57cac in Perl_newATTRSUB_x (my_perl=0x55dd5c60, floor=171, o=0x55ec8150, proto=0x0, attrs=0x0, block=0x55ec8110, o_is_gv=false) at op.c:10397 #23 0x74d458c2 in Perl_utilize (my_perl=0x55dd5c60, aver=1, floor=171, version=0x0, idop=0x55fac968, arg=0x558d5b08) at op.c:7592 #24 0x74e0a061 in Perl_yyparse (my_perl=0x55dd5c60, gramtype=258) at perly.y:335 #25 0x750080ed in S_doeval_compile (my_perl=0x55dd5c60, gimme=2 '\002', outside=0x0, seq=4294967246, hh=0x0) at pp_ctl.c:3502 #26 0x7500f64e in S_require_file (my_perl=0x55dd5c60, sv=0x55e35038) at pp_ctl.c:4322 #27 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at pp_ctl.c:4346 #28 0x74eb6c4a in Perl_runops_debug (my_perl=0x55dd5c60) at dump.c:2537 #29 0x74d7e142 in Perl_call_sv (my_perl=0x55dd5c60, sv=0x55f77f28, flags=13) at perl.c:3043 #30 0x74d89318 in Perl_call_list (my_perl=0x55dd5c60, oldscope=2, paramList=0x55f77fa0) at perl.c:5088 #31 0x74d586c0 in S_process_special_blocks (my_perl=0x55dd5c60, floor=45, fullname=0x55f70cd8 "BEGIN", gv=0x55f77fb8, cv=0x55f77f28) at op.c:10471 #32 0x74d57cac in Perl_newATTRSUB_x (my_perl=0x55dd5c60, floor=45, o=0x55f73970, proto=0x0, attrs=0x0, block=0x55f73930, o_is_gv=false) at op.c:10397 #33 0x74d458c2 in Perl_utilize (my_perl=0x55dd5c60, aver=1, floor=45, version=0x0, idop=0x55f9c978, arg=0x0) at op.c:7592 #34 0x74e0a061 in Perl_yyparse (my_perl=0x55dd5c60, gramtype=258) at perly.y:335 #35 0x74d7b4a3 in S_parse_body (my_perl=0x55dd5c60, env=0x0, xsinit=0x556a3ab6 ) at perl.c:2531 #36 0x74d791f8 in perl_parse (my_perl=0x55dd5c60, xsinit=0x556a3ab6 , argc=4, argv=0x55acf8c8, env=0x0) at perl.c:1822 #37 0x556a4988 in ngx_http_perl_create_interpreter (cf=0x7fffca70, pmcf=0x560b2c68) at
Re: NginX крошится с libperl-5.30
> Нет, регулярные выражения в конфиге nginx'а - nginx обрабатывает > сам. Надо смотреть именно на perl-код. В том числе это может > быть код в используемых perl-модулях. Ну, в явном виде perl-модуль не используется нигде. Ни сайтов на нём нету, ни perl_*-директивы не используются... > Для начала я бы попробовал получить простой способ воспроизведения > проблемы - полный конфиг (включая perl-код) и последовательность действий, > приводящие к падению. Попробую выработать минимальный конфиг... > > Возможно - при использовании чего-нибудь простого вроде junk:true > в malloc.conf (MALLOC_PERTURB_ на линуксе со стандартным аллокатором, > подробности см. в mallopt(3)) оно начнёт падать сразу, и возможно > даже без nginx'а. ну, при простых операциях сам по себе перл, вне NgX не падает с указанной директивой. > А дальше - постараться вычленить, что именно вызывает проблему. > Ну и неплохо бы проверить, не лечится ли всё банальным > downgrade'ом на perl 5.28.x и/или upgrade'ом на 5.31.x. Вообще, если честно, мне с дебагом пересобрать проще, чем обновить/ даунгрейднуть perl (потому что для последнего потребуется переустанавливать всё перлохозяйство, а это целая история с, в том числе, блокировками пакетов). Ну и 5.31 в Gentoo пока не завезли. А на 5.28 я (вроде (но это не точно)) не встречал этого. Более того, на одной из машин я попробовал пересобрать с дебагом и оно перестало падать >_> Сейчас вот собираю перл и NgX с дебагом на той, с которой трейс показывал... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: NginX крошится с libperl-5.30
> Судя по трейсу - Perl падает где-то в компиляции регулярных > выражений. Это, конечно, может быть и какой-то проблемой в > nginx'е, но я бы поставил скорее на проблему в перле, которую > триггерят используемые в коде регулярные выражения. Ну, в коде, вроде как, не используется никаких особо упоротых регулярок. В основном - всякие `location ~* \.php$` и в таком ключе. Так что, по идее, не должно бы... Ну и, я так понимаю, таки нужно пересобирать с дебагом и исходниками, чтобы отсделить что где? :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
NginX крошится с libperl-5.30
Уже в течение некоторого времени замечаю краши NgX при reload. Сегодня дошли руки глянуть в чём дело, и обнаружил что крошится оно в перловой либе. Попробовал подцепиться gdb'ом и получить трейс. Вот что вышло: 0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () from /usr/lib64/libperl.so.5.30 (gdb) bt full #0 0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () from /usr/lib64/libperl.so.5.30 No symbol table info available. #1 0x7f59c0c46784 in ?? () from /usr/lib64/libperl.so.5.30 No symbol table info available. #2 0x7f59c0c567b9 in ?? () from /usr/lib64/libperl.so.5.30 No symbol table info available. #3 0x7f59c0c5c6a7 in ?? () from /usr/lib64/libperl.so.5.30 No symbol table info available. #4 0x7f59c0c610f8 in ?? () from /usr/lib64/libperl.so.5.30 No symbol table info available. #5 0x7f59c0c6156d in ?? () from /usr/lib64/libperl.so.5.30 No symbol table info available. #6 0x7f59c0c6647b in Perl_re_op_compile () from /usr/lib64/libperl.so. 5.30 No symbol table info available. #7 0x7f59c0bfab3c in Perl_pmruntime () from /usr/lib64/libperl.so.5.30 No symbol table info available. #8 0x7f59c0c37851 in Perl_yyparse () from /usr/lib64/libperl.so.5.30 No symbol table info available. #9 0x7f59c0ce1912 in ?? () from /usr/lib64/libperl.so.5.30 No symbol table info available. Если честно, не хочется пересобирать перл с дебагом (чтобы открыть символы от #1 до #5), так что, надеюсь, этого трейса хватит. Но, если нет - скажите. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx + Lua вернуть JSON, как?
как именно пробовали и что именно не получается? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Unit] php-модуль, Ubuntu'шные пакеты
Взяли из PPA http://ppa.launchpad.net/ondrej/php/ubuntu (как и все в
интернетах, кому нужны отличные от апстримовых версии).
Ибо программисты пишут под 7.1 и пока не готовы к апгрейду...
К слову, на соседней-то машине, которая тоже bionic, юнит с 7.1 вполне себе
работает...
Правда, там не lxc-контейнер и ядро поновее...
Да и на соседнем проекте, кстати, используют докерный образ nginx/unit:1.8.0-
php7.0 и доставляют в него в Dockerfile'е php7.2 и всё работает как часы...
Разве что берут они его там с https://packages.sury.org/php/ ибо контейнер
дебиановый.
В общем, похоже, единственным выходом будет пересобирать юнитомодуль и класть
нужные модули в свой PPA... :(
Хотя от понимания почему там работает - я бы не отказался :)
Пока склонен считать, что, как и сказал товарищ, ответивший мимо рассылки,
> Причина была в том, что использовались php плагины, собранные другой версией
php или с другой конфигурацией сборки php. Вам надо будет попробовать
отключить плагины, или пересобрать их с текущей версией php.
Но теория тоже довольно притянутая, т.к. сторонних плагинов не используются а
на текущих двух машинах весрии и состав библиотек идентичны.
Плюс, крошится-то, на этой машине, только когда я через юнит задаю
контролирующие INI-директивы (а без их переопределения не крошится и
работает)...
В письме от пятница, 14 июня 2019 г. 15:32:45 MSK пользователь Валентин
Бартенев написал:
> On Friday, 14 June 2019 14:45:25 MSK Vadim A. Misbakh-Soloviov wrote:
> > Что-то я хоть тресни, но не могу из gdb попасть в процесс php-модуля,
> > чтобы
> > отловить его: либо если я включаю и follow=child и выключаю
> > detach-on-fork, то ухожу не в те форки, что нужно (роутер, контроллер), а
> > знаний как попасть в нужный - не хватает :'(.
> >
> >
> >
> >
> > Тут, кстати, один участник рассылки в обход неё, напрямую отправил письмо
> > о
> > том, что он сталкивался с таким же когда модуль был собран не под ту
> > версию
> > php.
> >
> > Технически-то, так оно и есть: debug-модуль php у юнита собран под 7.0, а
> > "продакшн" под 7.2
> > А использую я 7.1...
>
> [..]
>
> Так работать конечно не будет.
> У libphp нет совместимости по ABI между 7.x версиями.
>
> > Но что-то на убунте-то как-то не хочется пересобирать вручную пакет с
> > модулем php на каждом сервере, куда планируется воткнуть Юнит.
> >
> > Может, тогда имеет смысл вам, как апстриму сделать пакеты
> > "unit-php-{5.6,7-
> > {0,1,2,3}}?
>
> [..]
>
> Мы обычно собираем с тем, что есть в дистрибутиве. Иначе это поддерживать
> невозможно. Вопрос в том, откуда возникло расхождение в 7.x версиях.
>
> И откуда вообще взялся php 7.1 в убунтах?
> Я что-то его не вижу в https://packages.ubuntu.com/ - ни в xenial, ни в
> bionic.
>
> --
> Валентин Бартенев
> ___
> 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] php-модуль, Ubuntu'шные пакеты
Что-то я хоть тресни, но не могу из gdb попасть в процесс php-модуля, чтобы
отловить его: либо если я включаю и follow=child и выключаю detach-on-fork, то
ухожу не в те форки, что нужно (роутер, контроллер), а знаний как попасть в
нужный - не хватает :'(.
Тут, кстати, один участник рассылки в обход неё, напрямую отправил письмо о
том, что он сталкивался с таким же когда модуль был собран не под ту версию
php.
Технически-то, так оно и есть: debug-модуль php у юнита собран под 7.0, а
"продакшн" под 7.2
А использую я 7.1...
Но что-то на убунте-то как-то не хочется пересобирать вручную пакет с модулем
php на каждом сервере, куда планируется воткнуть Юнит.
Может, тогда имеет смысл вам, как апстриму сделать пакеты "unit-php-{5.6,7-
{0,1,2,3}}?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Unit] php-модуль, Ubuntu'шные пакеты
До gdb пока не добрался, но забавное наблюдение:
Если я убираю из конфига секции (внутри "options"):
```
"admin": {
"memory_limit": "256M",
"variables_order": "EGPCS",
"expose_php": "0"
},
"user": {
"display_errors": "0"
}
```
То сегфолтиться перестаёт.
А с ними - сегфолтится (с любым из блоков)...
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Unit] php-модуль, Ubuntu'шные пакеты
> Любого приложения? Даже пустого php-файла? Как ни странно, но нет, c phpinfo-примером, идущим в коробке, не падает. только с конфигом, натравленным на Symfony3, причём, не важно, укажу ли я ему script: app.php, или index: app.php (да и вообще, странно, если написанный под фреймворком PHP-код не крошиться под FPM и крошится под embed SAPI) Плюс, в любом случае странно, что на другом инстансе не смотря на явно выставленный 7.1 в альтернативах, после игр с юнитом, приходится опять и опять его "прекстанавливать", ибо оно там что-то жалуется на сломанность (и после этого кстати, там как раз и перетавало крошиться). > Это из чьих-то пакетов или сборка из исходников? Из http://packages.nginx.org/unit/ubuntu/ // кстати, на bionic сейчас ведёт себя так же, обновление не помогло. В общем, сейчас буду пробовать дебажить... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[Unit] php-модуль, Ubuntu'шные пакеты
Здравствуйте! Подскажите, пожалуйста, никто ли не сталкивался с тем, что на Ubuntu (xenial, bionic) при использовании php-модуля с php7.1 при попытке загрузки приложения оно сегфолтится (юнит сообщает про то, что оно выходит с сигналом 11, что на сколько я помню, является сегфолтом). Контекст выяснить пока не удалось, к сожалению. Плюс, на одном из bionic-инстансов "чинится" переустановкой `update- alternatives --set php/libphp7` заново на 7.1, а вот на xenial не помогло даже вынести все версии кроме 7.1. Сейчас, вот, пробую проапгрейдить до bionic, посмотрю как там себя поведёт... К сожалению, подебажить нормально не получается: debug-версия юнита ничего связанного с сегфолтом модуля (дебаг символы от него тоже стоят) не пишет ни в лог, ни на stdout. А если запустить юнит под gdb, то сегфолт модуля не отлавливается (впрочем, я не такой уж и гуру gdb, если честно). P.S. В то же время на Gentoo, где под каждую версию php собирается отдельный модуль, именуемый соответствующе, а нужный путь до libphp7 прописывается через RUNPATH, такой проблемы с сегфолтами не наблюдается... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.9.0
Ну, видимо, или gcc-9.1.0 более не удовлетворён ими, или, возможно, это произошло из-за рассинхрона версий distcc на хостах (впрочем, 7-то, вроде, тоже уже умел). Попробую проверить при ближайшем ребилде... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.9.0
К слову: src/nxt_string.c: In function ‘nxt_strverscmp’: src/nxt_string.c:414:12: warning: this statement may fall through [-Wimplicit- fallthrough=] src/nxt_string.c:420:5: note: here src/nxt_murmur_hash.c: In function ‘nxt_murmur_hash2’: src/nxt_murmur_hash.c:39:11: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_murmur_hash.c:41:5: note: here src/nxt_murmur_hash.c:42:11: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_murmur_hash.c:44:5: note: here src/nxt_vector.c: In function ‘nxt_vector_destroy’: src/nxt_vector.c:63:9: warning: this statement may fall through [-Wimplicit- fallthrough=] src/nxt_vector.c:67:5: note: here src/nxt_timer.c: In function ‘nxt_timer_changes_commit’: src/nxt_timer.c:191:16: warning: this statement may fall through [-Wimplicit- fallthrough=] src/nxt_timer.c:197:9: note: here src/nxt_http_parse.c: In function ‘nxt_http_parse_request_line’: src/nxt_http_parse.c:365:20: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:369:13: note: here src/nxt_http_parse.c:370:20: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:374:13: note: here src/nxt_http_parse.c:375:20: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:379:13: note: here src/nxt_http_parse.c: In function ‘nxt_http_parse_complex_target’: src/nxt_http_parse.c:902:36: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:904:13: note: here src/nxt_http_parse.c:936:36: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:938:13: note: here src/nxt_http_parse.c:973:36: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:975:13: note: here src/nxt_http_parse.c:1017:36: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:1019:13: note: here src/nxt_http_parse.c: In function ‘nxt_http_lookup_field_end’: src/nxt_http_parse.c:739:78: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:741:5: note: here src/nxt_http_parse.c:742:78: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_parse.c:744:5: note: here src/nxt_conf_validation.c: In function ‘nxt_conf_vldt_match_pattern’: src/nxt_conf_validation.c:800:16: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_conf_validation.c:811:9: note: here src/nxt_http_route.c: In function ‘nxt_http_route_pattern’: src/nxt_http_route.c:1566:21: warning: this statement may fall through [- Wimplicit-fallthrough=] src/nxt_http_route.c:1570:5: note: here ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Unitd + client_addr
Если проксируется сквозь NginX, то, вроде как, вообще никаких проблем положить IP в какой-нибудь X-заголовок и брать оттуда... В письме от пятница, 31 мая 2019 г. 18:51:15 MSK пользователь Anton Kiryushkin написал: > Здравствуйте. > > Не подскажете, какова судьба вот этого тикета: > https://github.com/nginx/unit/issues/132 > > А так же, возможно, есть прямой способ, как получить в php, запускаемом > через unit клиентский айпишник? Сейчас там 127.0.0.1, что очень и очень > плохо и ставит использование unit под жирный вопрос. > > -- > Best regards, > Anton Kiryushkin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.9.0
Вот бы ещё дождаться per-applicaton access и error-логов (с возможностью указания путей)... :D ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: .htaccess
Логичнее было бы NgX+Unit. И реализовывать обработку htaccess в юните. // а ещё лучше - в коде приложения :) В письме от понедельник, 13 мая 2019 г. 09:00:54 MSK пользователь Виктор Вислобоков написал: > >> Зачем, если пользователь может просто установить Apache? > > Читайте начальный пост ТС. Он говорил при наличии php-fpm. > Связка nginx+apache увы, не даёт той производительности, которую даёт > связка nginx+php-fpm. > > > 13.05.2019, Konstantin Tokarev написал(а): > > > > > > > > > 12.05.2019, 10:35, "Виктор Вислобоков" : > > > >> По ответу на вопрос - насколько мне известно - нет. Всё ручками, > >> ручками. Но сама тема давно уже назрела, на мой взгляд. > >> > >> > >> > >> Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache > >> и юзать его .htaccess при включении специальной директивы. > > > > > > > > Зачем, если пользователь может просто установить Apache? > > > > > > > > -- > > Regards, > > Konstantin > > > > > > > > ___ > > 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/1.16.0 ssl
1) если вы решили свои проблемы, то какая разница? 2) давайте начнём с того, что это не форум и здесь нет "тем". Это почтовый список рассылки с веб-мордой в виде форума для тех, кто слишком неосилянт для списков рассылки. И у всех участников рассылки оба треда на месте. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unitd + php5.6
> ./configure: error: no PHP embed SAPI found. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.8.0
> А поддержки opcache в php все еще нет? Она включается на стороне php, а не юнита. При сборка "embed" SAPI. У меня, например, opcache на месте. А если вы говорите про готовые бинарные пакеты для какого-то дисторибутива из реп, предоставляемых девелоперами - уточните, чтоли, о каком дистрибутиве идёт речь... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[Unit] Per-appication acces_log'и
А планируется ли в Unit завезти возможность назначать отдельные access-логи для каждого приложения вместо одного общего?.. И, что-то, я в документации не нахожу информации по поводу error_log'ов :'( Подскажите, пожалуйста, куда тогда смотреть на предмет ошибок (в т.ч. тех, что отдаёт приложение)?.. P.S. error_log'и на уровне приложения тоже хотелось бы мочь задавать :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[Unit] аналог touch $document_root/tmp/restart
Коллеги, и подскажите, пожалуйста, есть ли у Юнита какой-нибудь способ сообщить ему (после деплоя изменений в рабочую директорию проекта) что нужно перезапустить текущее приложение "во прямо сейчас"? А-ля touch tmp/restart.txt у пассажира и всяких рубишных аппликейшн-серверов Что-то, в документации такого не нахожу. То ли совсем плохой стал, то ли такой кейс там не описан. Максимально приближенное что я нашёл в документации - limits.requests, но это, всё же, не совсем то... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.6
> Думаю, что нужно просто добавить туда --unsafe-perm. Ну, тут уж вам там, как апстриму виднее :) Вы только маякните, пожалуйста, когда можно будет манки-патч седовый убирать :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.6
> У меня установка (без опции --local) прошла успешно с таким патчем:
> + ${NXT_NPM} install -g --user=root ${PWD}/${NXT_NODE_TARBALL}
> Либо с таким:
> + ${NXT_NPM} install -g --unsafe-perm ${PWD}/${NXT_NODE_TARBALL}
Ну, вот, у меня тоже она успешно проходит только с `--unsafe`
И да, я, похоже, закоммитив, забыл запушить на гитхаб изменения с добавленным
sed'о'патчем на `--unsafe`, вот и не собирается :)
// а всё потому, что экспериментировал с --local
Собственно, теперь встаёт вопрос о том, что же делать?
Сильно для вас будет проблематично "апстримно" добавить туда что-нибудь типа
> --user=$(whoami)
или как-нибудь так? :)
Ну, чтобы, с одной стороны, в *этом* кейсе оно превращалось в --user=root, а с
другой - не мешало другим юзерам ставить не-под-рутом (если таковые есть)?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.6
Что-то я тут подебажил ещё, и заметил вообще страннейшую вещь: нижеуказанная ошибка вываливается если использовать --local=/usr/lib64 и export USER=root (потому что под ним и происходит install-фаза, просто переменная пуста). > ``` > gyp WARN EACCES user "root" does not have permission to access the dev dir > "/ var/tmp/portage/www-servers/nginx-unit-/homedir/.node-gyp/9.8.0" gyp > cc1plus: error: /var/tmp/portage/www-servers/nginx-unit-/work/nginx- > unit-/src: Permission denied > ``` Однако (!!!) 1) не просто у юзера root есть права доступа в директории, на которые ссылается билдлог, но и прямо даже из секции src_install (откуда потом вызывается `make install`), непосредственно перед этим `make install`'ом я прекрасно могу создать (touch'ем) файлы в указанных директориях... Ну, точнее, первая не существует, но прекрасно создаётся `mkdir -p` (хотя это и не помогает, а приводит к другой ошибке с правами), а вот во второй прекрасно создаютмя любые файлы. А вот gyp почему-то выкабенивается... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.6
> Опция --local устанавливает NXT_NODE_LOCAL.
Хм... Значит текст в node-local-check обманывает :)
> echo "error: to make ${NXT_NODE}-local-install you need **either**";
> either
:)
> ну и судя по тому, что было приведено в предыдущем письме, npm install
> вызывается с флагом -g, а это установка в глобальную директорию npm в
> системе.
Что-то, да, я как-то и не приметил -g, прошу пардону :)
> sandbox скорее всего мешает npm поставить в свою глобальную директорию
> модулей в системе и от этого все приключения.
На самом деле, нет. Если бы мешал sandbox, то вываливались бы сообщения об
access violation от него самого, а их нет (к тому же, в `.../image/...` он
ставить разрешает. Он не разрешает ставить в систему игнорируя DESTDIR. А
установка, когда появляется бесконечный цикл, идёт как раз в директорию с
учётом DESTDIR).
> Подозреваю, что сам npm при этом на DESTDIR не смотрит или делает как-то
> странно.
Судя по всему, таки не игнорирует (или она ему как-то иначе передаётся).
Потому что:
```
gyp WARN EACCES user "undefined" does not have permission to access the dev
dir "/var/tmp/portage/www-servers/nginx-unit-/image/usr/lib64/
node_modules/unit-http/.node-gyp/9.8.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/var/tmp/
portage/www-servers/nginx-unit-/image/usr/lib64/node_modules/unit-
http/.node-gyp"
gyp WARN EACCES user "nobody" does not have permission to access the dev dir
"/var/tmp/portage/www-servers/nginx-unit-/image/usr/lib64/node_modules/
unit-http/.node-gyp/9.8.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/var/tmp/
portage/www-servers/nginx-unit-/image/usr/lib64/node_modules/unit-
http/.node-gyp"
```
При этом, `/var/tmp/portage/www-servers/nginx-unit-/image/` - это как раз
и есть DESTDIR.
> Ok, посмотрю на это повнимательнее.
>
> Последний раз, когда я пытался поставить в Gentoo, то обнаружил
> из коробки сломанный npm:
>
>
> % npm -v
Ну, у меня npm, вроде и рабочий, не смотря на "старую" версию nodejs'а в
системе (9.8.0) и описанные выше проблемы (10+ версии замаскированы из-за
зависимости от openssl-1.1, а 9.х привередничает про icu) :)
К слову, для лучшей воспроизводимости - немного обнаглею и попрошу ставить из
моего оверлея (у меня там более фичастый unit, в отличие от того, что в
главном репозитории, да и там - последний 1.5).
Его можно добавить либо layman'ом, либо eselect-repository (в зависимости от
новизны системы и того, что из них используется для управления репозиториями).
Соответственно,
> layman -a mva
или
> eselect repository enable mva
После чего
> USE="unit_modules_nodejs" sudo emerge -va nginx-unit::mva
Кстати, я сейчас попробовал подобавлять `--local`... Получил такое вот:
```
gyp WARN EACCES user "root" does not have permission to access the dev dir "/
var/tmp/portage/www-servers/nginx-unit-/homedir/.node-gyp/9.8.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/var/tmp/
portage/www-servers/nginx-unit-/image/usr/lib64/node_modules/unit-
http/.node-gyp"
make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
CXX(target) Release/obj.target/unit-http/unit.o
cc1plus: error: /var/tmp/portage/www-servers/nginx-unit-/work/nginx-
unit-/src: Permission denied
make[1]: *** [unit-http.target.mk:96: Release/obj.target/unit-http/unit.o]
Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/lib64/node_modules/npm/
node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack at ChildProcess.emit (events.js:180:13)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/
child_process.js:209:12)
gyp ERR! System Linux 4.18.10
gyp ERR! command "/usr/bin/node" "/usr/lib64/node_modules/npm/node_modules/
node-gyp/bin/node-gyp.js" "configure" "build"
gyp ERR! cwd /var/tmp/portage/www-servers/nginx-unit-/image/usr/lib64/
node_modules/unit-http
gyp ERR! node -v v9.8.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! unit-http@1.0.0 install: `node-gyp configure build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the unit-http@1.0.0 install script.
npm ERR! This is probably not a problem with npm. There is likely additional
logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /var/tmp/portage/www-servers/nginx-unit-/homedir/.npm/_logs/
2018-11-16T05_31_22_466Z-debug.log
make: *** [build/Makefile:1831: node-local-install] Error 1
```
Даже при выключенном fakeroot...
Что-то странное...
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.6
В письме от пятница, 16 ноября 2018 г. 3:32:03 +07 пользователь Валентин
Бартенев написал:
> А make install делается из под рута?
да
Но в sandbox (который пресекает попытки вылезти куда не следует) и, возможно,
с fakeroot (завтра поконкретнее подебажу, используется ли он именно на этой
стадии).
> Если не была задана опция --local,
> то npm будет пытаеться установить модуль в систему глобально, а для этого
> нужны соответсвующие привилегии. Если нужно поместить модуль в отдельную
> директорию, то следует указать опцию --local, либо использовать
> make node-local-install с соответсвующим DESTDIR.
Опция --local задана не была, но была задана переменная DESTDIR, а, согласно
содержимому auto/modules/nodejs этого, вроде как, достаточно для того чтобы
вызывался node-local-install. И, он, собственно, и вызывается. Но потом
случается непонятно что и происходит бесконечный цикл про права доступа, хотя
`id` и возвращает "root". Я даже пробовал объявить в стадии src_install'а
переменную USER (которая и в самом деле пуста), но не помогало. Помог только
--unsafe...
> Или я неправильно понял проблему? Тогда хотелось бы подробностей,
> что за система и с какими опциями зовут ./configure, make и т.д.?
1) Gentoo,
2) как-то вот так:
```
_unit_go_configure() {
./configure go --go-path="$(get_golibdir_gopath)" # multislot?
}
_unit_nodejs_configure() {
./configure nodejs --node-gyp="/usr/$(get_libdir)/node_modules/npm/bin/
node-gyp-bin/node-gyp"
}
_unit_perl_configure() {
./configure perl # multislot?
}
_unit_php_configure() {
for impl in $(php_get_slots); do
./configure php --config="/usr/$(get_libdir)/${impl}/bin/php-config"
--module="${impl/.}" --lib-path="/usr/lib/${impl}/$(get_libdir)"
done
}
_unit_python_configure() {
_unit_python_configure_each() {
./configure python --config="${EPYTHON}-config" --module="$
{EPYTHON/.}"
}
python_foreach_impl _unit_python_configure_each
}
_unit_ruby_configure() {
_ruby_each_implementation_each() {
cd "${WORKDIR}/${MY_P}"
./configure ruby --ruby="${RUBY}" --module="$(basename ${RUBY})"
}
_ruby_each_implementation _ruby_each_implementation_each
}
src_configure() {
./configure \
--cc="${CC}" \
--cc-opt="${CFLAGS}" \
--ld-opt="${LDFLAGS}" \
--bindir="/usr/bin" \
--sbindir="/usr/sbin" \
--prefix="/var/lib/${PN}" \
--modules="/usr/lib/${PN}/modules" \
--state="/var/lib/${PN}" \
--pid="/run/${PN}.pid" \
--log="/var/log/${PN}.log" \
--control="unix:/run/${PN}.sock" \
$(usex ipv6 '' "--no-ipv6") \
$(usex unix-sockets '' "--no-unix-sockets") \
$(usex debug "--debug" "")
for mod in $UNIT_MODULES; do
use "unit_modules_${mod}" && "_unit_${mod}_configure"
done
}
```
> Очень похоже вот на этот баг:
> https://github.com/nodejs/node/issues/22457
Возможно. Но, увы, обновить nodejs пока что никакой возможности (10+
заблокированы дистрибутивом ибо тянут заблокированный openssl-1.1 (который
ломает кучу всего).
Да и 9.х не хочет пересобираться, ибо хочет старый icu, которого уже нету).
Так что приходится жевать то, что было установлено когда-то давно (9.8.0) :)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.6
>*) Изменение: команда "make install" теперь также устанавливает модуль > Node.js, если он был настроен. > >*) Добавление: параметр "--local" в ./configure для локальной установки > модуля Node.js. 1) я пока не смог вычислить, каким именно образом, но в новом релизе сборка nodejs-модуля "по умолчанию" (без патчинга auto/modules/nodejs на добавление --unsafe к вызову npm install) и наличии DESTDIR впадает в бесконечный цикл вот этого вот: https://github.com/nodejs/node-gyp/issues/1236 (собственно, идея про --unsafe и взята оттуда, но это костыль, и там советуют править билдконфиги проекта) 2) такое вот: ``` GOPATH=/var/tmp/portage/www-servers/nginx-unit-/image//usr/lib/go-gentoo go build nginx/unit export UNIT_SRC_PATH=/var/tmp/portage/www-servers/nginx-unit-/work/nginx- unit-/src && export UNIT_LIB_STATIC_PATH=/var/tmp/portage/www-servers/ nginx-unit-/work/nginx-unit-/build/libunit.a && \ npm install --unsafe -g /var/tmp/portage/www-servers/nginx-unit-/work/ nginx-unit-/build/node-unit-http.tar.gz > unit-http@1.0.0 install /var/tmp/portage/www-servers/nginx-unit-/image/ usr/lib64/node_modules/unit-http > node-gyp configure build make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. make[1]: Entering directory '/var/tmp/portage/www-servers/nginx-unit-/ image/usr/lib64/node_modules/unit-http/build' CXX(target) Release/obj.target/unit-http/unit.o CXX(target) Release/obj.target/unit-http/addon.o SOLINK_MODULE(target) Release/obj.target/unit-http.node COPY Release/unit-http.node make[1]: Leaving directory '/var/tmp/portage/www-servers/nginx-unit-/ image/usr/lib64/node_modules/unit-http/build' + unit-http@1.0.0 added 2 packages in 3.962s ``` (в частности, речь про `warning: jobserver unavailable`) Очень похоже на то, что, опять-таки, что-то не так с билд-конфигом gyp'а... Не могли бы вы ещё немного ковырнуть билд-систему, чтобы починить это дело? P.S. если нужно, то я даже готов помочь в тестировании фиксов из какого-нибудь девелоперского git-репозитория (пакетный менеджер ОС предоставляет возможность переопределения git-репозитория откуда качать исходники пакета) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Пролагивание коннектов при проверке синтаксиса
В письме от четверг, 15 ноября 2018 г. 16:42:51 +07 пользователь kpoxa
написал:
> Добрый день.
>
> Не помогает такой вариант:
>
> http {
...
> listen 80;
...
> }
> stream {
> }
А теперь, пожалуйста, вернитесь на пару писем назад по цепочке, и прочитайте
ответ Максима.
http и stream - разные модули.
И вполне логично, что сокеты, объявленные в http{} не имеют отношения к
сокетам, объявленным в stream{}. Как вы думаете?
Вам, практически в явном виде, предлагалось создать вайлдкардный server{} в
stream-модуле.
И да, кстати,
1) можно указать `server_name _;` (нужен любой невалидный, а _ - самый
короткий из них.
2) почему вы, всё же, не хотите в явном виде указать вайлдкард listen'у?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Пролагивание коннектов при проверке синтаксиса
В письме от среда, 14 ноября 2018 г. 21:11:01 +07 пользователь kpoxa написал:
> Я правильно понимаю, что можно сделать один listen 443 в специально
> сделанном сайте,
> который по другому никак не будет использоваться, а во всех остальных
> местах,
> и в HTTP и в стримах оставить listen ip:443 и все будет работать?
Лучше, всё же в "дефолтном" `server {}`-блоке, который будет загружаться самым
первым (т.е. либо дать ему такое имя, чтобы в алфавитном порядке при
разыменовывании вайлдкарда оказался первым, либо в явном виде первым
заинклудить.
Плюс, лучше, всё же, в явном виде
```
listen *:443
listen [::]:443
```
чтобы не надеяться на поведение "по умолчанию"
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Бинарные пакеты под ARM64 для Ubuntu 18.04
> Если не секрет, для чего Вы используете наши пакеты на этой довольно > экзотической архитектуре? Меняете или используете as-is? На самом деле, не такая уж она и экзотическая. У меня, например, более десятка армоборд и иных всевозможных девайсов на данной архитектуре. И практически на всех (самосборный) NgX. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Unit: коммит, ломающий сборку
Здравствуйте! Тут позавчера вечером прилетел вот такой вот коммит: http://hg.nginx.org/unit/diff/e0f0cd7d244a/src/perl/nxt_perl_psgi.c (ссылка на конкретный файл, чтобы понять о чём речь) Теперь в нём (файле) есть такая вот строка: > PerlInterpreter *my_perl; Точнее, таких вхождений там теперь несколько, но нас интересует та, что на данный момент на 804 строке. Потому что она (кроме своей установки) нигде не используется. При этом в билдсистеме используется замечательный флаг > -Werror И вот всё это вместе приводит к: > make -j5 -s -l2 all > src/perl/nxt_perl_psgi.c: In function ‘nxt_perl_psgi_io_read’: > src/perl/nxt_perl_psgi.c:804:30: error: variable ‘my_perl’ set but not used [-Werror=unused-but-set-variable] > PerlInterpreter *my_perl; > ^~~ > cc1: all warnings being treated as errors > make: *** [build/Makefile:1502: build/src/perl/nxt_perl_psgi-perl.o] Error 1 Почините, пожалуйста :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit: 400 ошибка при заголовках, содержащих юникод
А почему бы не разрешить юникод? Ну и, справедливости ради, я был бы не против если бы поддержка (отсутствие запрета, точнее) юникода была не только в *значениях* заголовков, но и в самих именах. Не то, чтобы я это активно испольновал, но не вижу явных причин для запрета... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.15.0
В письме от вторник, 19 июня 2018 г. 16:19:56 MSK пользователь Maxim Konovalov написал: > On 19/06/2018 16:01, Vadim A. Misbakh-Soloviov wrote: > > А про DTLS нет ничего? > > А то патч перестал применяться, и новых обновлений патча нету... > > > > Не связано ли это с тем, что DTLS впилили в апстрим? > > Вы про какой патч, Вадим? Я про http://nginx.org/patches/dtls/ (последний патч - только под 13.9, а под 15.0 уже нету) Цитата из README: == > With the patch, the "listen" directive in the "stream" block now accepts > both "udp" and "ssl" parameters. > The "ssl_protocols" and "proxy_ssl_protocols" directives now accept "DTLSv1" > and "DTLSv1.2" parameters that enable support of corresponding protocols. == > В 1.15.0 появилась вот такая штука: > > *) Feature: now the stream module can handle multiple incoming UDP >datagrams from a client within a single session. > > Она позволяет корректно проксировать DTLS трафик. Работает только на > системах с поддержкой SO_REUSEPORT и с включенным на соответствующем > listen-сокете reuseport, см. nginx.org/r/listen Не уверен, что это то же самое :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.15.0
А про DTLS нет ничего? А то патч перестал применяться, и новых обновлений патча нету... Не связано ли это с тем, что DTLS впилили в апстрим? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Релиз Unit 1.2
> *) Добавление: установка пути к файлу "php.ini". "системному" или "юзерскому" (которые можно в приложении в виде .user.ini совать)? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
пакеты под Ubuntu 18.04 LTS (bionic)
Здравствуйте, товарищи дивелоперы! Подскажите, пожалуйста, есть ли планы по добавлению дистрибутива "bionic" в NginX'овый репозиторий пакетов для Ubuntu (уже как минимум неделю, а то и две, как релизнулось)? А то, что-то, вот, затык на устаноке NginX :'( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Редирект и символ #
> Скажите, пожалуйста, как сделать редирект вида /foobar ->
> /foobar#{arg1:value1} ?
Никак (средствами веб-сервера). Всё, что после # - остаётся в браузере, и,
максимум что его видит - фронтендовые скрипты. Т.о. если вам прямо очень
хочется делать такой редирект (хотя редиректом тут даже не пахнет в силу
специфики вышеозвученного), то делать его можно только на фронтенде.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ipv6 и error 400
А прописали точно и для ssl и для http? И как именно указали? В письме от понедельник, 26 февраля 2018 г. 15:49:34 +07 пользователь Dmytro Lavryk написал: > Доброго всем здоровья! > Недавно прикрутил к нескольким сайтам на сервере ipv6 адреса, прописал в > nginx . В access на этих сайтах периодически по непонятным причинам > проскакивает код ответа 400. При чем ИСКЛЮЧИТЕЛЬНО при обращениях через > ipv6. > > Чтобы могло быть? Как можно подробнее продиагностировать - чего не хватает? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,278759,278759#msg-278759 > > ___ > 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
Возможность проверить успешность auth_basic авторизации
Всем привет. У меня тут возникла необходимость в проверке успешности auth_basic авторизации (каковая, например, есть для client_certificate ($ssl_client_verify)). У меня была идея сделать (средствами NginX) basic-авторизацию (в одном и том же локейшне) необязательной, но принципиально применимой. И в случае предоставления логина-пароля — обрабатывать этот кейс (а точнее - использовать содержимое $remote_user для определённых целей). Логичным решением мне показалось использовать `satisfy any`+`allow all` +`auth_basic`. Однако в данном случае при предоставлении неправильного пароля в $remote_user всё равно оказывается переданное имя пользователя. Что является немного не тем результатом, на который я рассчитывал, но с этим можно было бы смириться (в конце концов, никто и не говорил, что директива содержит имя только в случае успешной авторизации), если бы был способ проверить успешность авторизации. А такового я не нашёл (возможно, плохо искал). В общем, подскажите пожалуйста: 1) есть ли способ узнать, была ли авторизация успешной? Может, я и в самом деле слепой и не вижу в документации того, что там есть? 2) может быть, есть иной способ добиться того, что я хотел кроме `satisfy any` +`allow all`? Заранее спасибо! ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сервер по умолчанию для SSL
1) у вас для ssl'ового listen'а не указано "ssl" в аргументах.
2) вы сами ответили на свой вопрос: вы не можете иметь универсального
сертификата для всех доменов (чтобы подсунуть его для случая, когда кто-то
ломится на домен, который не сконфигурирован в server{}-блоках.
Поэтому вы можете использовать там абсолютно любой. Всё равно с большой долей
вероятности он будет невалиден при попадании запроса в дефолтный vhost.
В письме от понедельник, 5 февраля 2018 г. 16:52:00 +07 пользователь iotch
написал:
> Здравствуйте.
>
> Пытаюсь настроить дефолтный сервер для неописанных хостов:
>
> server {
> listen 10.0.0.2:80 default_server;
> listen 10.0.0.2:443 default_server;
>
> server_name '';
>
> location / {
> return 444;
> }
> }
>
> Проблема возникает при попытке обращения к неописанному хосту по https - "no
> "ssl_certificate" is defined in server listening on SSL port while SSL
> handshaking"
>
> Если в эту конфигурацию добавить ssl_certificate и ssl_certificate_key с
> путями к любому сертификату и ключу, то все работает как ожидается, но это
> выглядит как палеатив - ведь мы не можем получить сертификат на неизвестный
> домен. Как быть в этом случае?
>
> Спасибо!
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,278349,278349#msg-278349
>
> ___
> 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: Как вызвать функцию модуля из другого модуля?
> Есть такой 3rd-party модуль: https://github.com/simpl/ngx_devel_kit > и по меньшей мере 6 других модулей его используют. Вот только когда я попробовал сделать его динамическим и даже грузить до других модулей - всё равно была толпа ошибок об отсутствующих символах :'( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
В письме от пятница, 24 ноября 2017 г. 17:48:41 MSK пользователь Gena Makhomed написал: > nginx ведь соответствует например, спецификации на протокол HTTP, Например, потому что NginX — HTTP-сервер, > почему же он не может соответствовать спецификации из daemon(7)? а SystemD при этом — лишь **одна** из **множества** существующих init-систем на **одной** из **множества** операционных систем, на которых работает NginX. А ещё, потому что NginX соответствует спецификации daemon(3). Которая, в отличие от daemon(7), является релевантной для всех ОС (включая в т.ч. Linux) на которых существует соответствующая man-страница. В то время, как спецификация daemon(7) является релевантной только для systemd и существует только на системах с установленных systemd (потому что сама man- страница является частью systemd). Самим разработчикам NginX не интересно в работающий десятилетиями на множестве ОС воркфлоу вставлять пучок костылей для соответствия требованиям одного- единственного сервис-менеджера из множества. К тому же, особенно мило требование по их вставке выглядит в свете того, что за всё время существования SystemD его авторы до сих пор не хотят сделать возможность хендлить рестарт (а не просто stop+start), о которой говорилось в соседнем треде созданном вами. Т.е. картина такая: разработчики SystemD требуют чтобы под них подстраивались другие, при этом сами ни под чей воркфлоу подстроиться не хотят. Даже не смотря на его повсеместное (кроме systemd) существование десятилетиями. В связи с этим, как вам уже сказали: если **вам** это нужно — сделайте патч или наймите того, кто его сделает. И не просто патч, а соответствующий код-стайлу NginX и вставляющий как можно меньше костылей. И, крайне желательно, с вынесением всего этого в `--with-systemd`/`#ifdef WITH_SYSTEMD` (или типа того). Иначе весь этот тред — переливание из пустого в порожнее, т.к. разработчикам NginX нет ни интереса, ни стимула на ровном месте заниматься подобными непотребствами. И, к слову, как я говорил выше, на том же OpenRC (который, так-то, надстройка над SysV-init) подобных проблем с NginX не наблюдается. Интересно, почему бы это?.. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
В письме от пятница, 24 ноября 2017 г. 14:30:41 MSK пользователь Gena Makhomed написал: > Когда команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > глючит Опять же, данная команда на gentoo (на инстансах без systemd) у меня тоже не глючит. При любом количестве воркеров. И у меня всё тот же вопрос: что же я делаю не так и как мне воспроизвести вашу проблему? // просто мимокрокодил ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
Прошу прощения за то, что вставляю свои пять копеек, но у меня, почему-то, на Gentoo NgX вполне замечательно стартует на SystemD без ругани, на которую жалуется ОП: ``` ноя 24 12:12:24 note systemd[1]: Starting The nginx HTTP and reverse proxy server... ноя 24 12:12:25 note nginx[17684]: nginx: the configuration file /etc/nginx/ nginx.conf syntax is ok ноя 24 12:12:25 note nginx[17684]: nginx: configuration file /etc/nginx/ nginx.conf test is successful ноя 24 12:12:25 note systemd[1]: Started The nginx HTTP and reverse proxy server. ``` Код nginx.service при этом такой: ``` [Unit] Description=The nginx HTTP and reverse proxy server After=network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill -QUIT $MAINPID [Install] WantedBy=multi-user.target ``` В связи с этим у меня возникает вопрос: а что я, собственно, делаю не так? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
В письме от четверг, 9 ноября 2017 г. 20:50:09 +07 пользователь Andrey Oktyabrskiy написал: > Илья Шипицин wrote: > > в момент запуска nginx доступен ресолвер ? > > Вопрос-то не об этом. А о том, почему [warn] истолковывается как > фатальная ошибка. он не истолковывается. Долистайте до конца лога. Фейл происходит из-за того что у ТС nginx слишком долго тестирует конфиг // тут я бы на его месте подумал о том, чтобы найти причину того что nginx так долго шуршит конфигом. Мне кажется, что проблема в том, что NgX по долгу ждёт таймаутов, связанных как раз с недоступностью резолвера. Так что нужно либо правильно настроить зависимости сервисов (чтобы резолвер (или сеть) стартовал(а) раньше NgX), либо уменьшить таймауты (что, вообще, имеет скорее негативный смысл) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx и queue в upstream (Windows)
> А в чем проблема поднять linux/free в виртуалке как раз для php+nginx? Да, впринципе, почти никакой (тем более, что, вроде как, и виртуалка-то не нужна в этой вашей десяточке, вроде: там убунта встроенная). Но только, сдаётся мне, это сродни установки виртуалки с вышеупомянутой для outlook/word/excel и т.п. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx и queue в upstream (Windows)
> что отрезана целая платформа, в данном случае Windows, от нормальный работы > с PHP. От этого страдают Windows разработчики на такой связке. А, и да, я хотел ещё сделать замечание о том, что по задумке Microsoft (и они делают всё что могут для того, чтобы это было именно так) "родным" способм разработки веб-приложений под windows является запуск их под Microsoft IIS. И, как ни странно, он вполне замечательно (насколько это вообще может быть применено к использованию Windows для этих целей) работает. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx и queue в upstream (Windows)
> что отрезана целая платформа, в данном случае Windows, от нормальный работы > с PHP. От этого страдают Windows разработчики на такой связке. > обязательно вам поможем с вашей проблемой на Windows. Вместо этого тишина. > Я надеялся на какой-то вменяемый ответ, но всё сразу же скатилось к деньгам, > а жаль. Что же, всем удачи, всем спасибо, продолжайте в том же духе :-) Про NginX, windows и приоритетность Windows как целевой платформы у NginX уже писан не один десяток тредов. Именно поэтому никто из разработчиков не хочет тут ничего писать. Им не интересно переливать всё по кругу в восьмимиллионный раз. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx и queue в upstream (Windows)
> Видимо да, раз существуют такие ресурсы как GitHub и SourceForge например. > Никогда о них не слышали? 1) количество windows-разработчиков слабо влияет на существование github, например. А sourceforge с их политикой лучше бы и не существовал (но количество windows- разработчиков с лицензионной windows на его существование точно так же не влияет. 2) речь шла не об этом. Вам тонко намекнули, что ваш запрос выглядит как "запилите бесплатно фичу, которую вам нет никакого интереса (и ресурсов) запиливать и тестировать, а мы просто скажем спасибо". Хотя деньги на лицензию Windows вы нашли, а денег на лицензию nginx+ почему-то не хотите найти. Чем разработчики NginX хуже и почему их не надо поддерживать материально, а Microsoft - надо? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
> - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за >счет своей архитектуры. > Я что-то недопонял... Данное утверждение предполагает использование Unit без NginX перед ним?.. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: contrib/vim, contrib/geo2nginx.pl, contrib/unicode2nginx
> В tar.gz дистрибутиве есть каталог contrib/vim - можно ли сделать так, > чтобы содержимое этого каталога при установке пакета ложилось в каталог > /usr/share/vim/vimfiles ? Это было бы очень удобно для пользователей vim 1) есть же ещё как минимум neovim 2) обычно это выносят в отдельный пакет 3) я, если честно, уже запутался, где более актуальный: в тарболле nginx или среди тех, что на гитхабе (там они появились раньше, чем в тарболле) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Очень медленный ответ после нескольких быстрых ответов
1) местами от ваших конфигов возникает чувство что делались по статье "как сделать всё в самых bad practices что только есть", но не буду учить, ладно. 2) попробуйте заменить unix-сокет между NgX и uwsgi на tcp ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Очень медленный ответ после нескольких быстрых ответов
В письме от четверг, 28 сентября 2017 г. 15:19:26 +07 пользователь EugeneNF написал: > Как было рекомендовано я добавил $request_time и $upstream_response_time. > После нескольких запросов и быстрых ответов лог файлы и для nginx и для > uwsgi не показывают ничего. Через время ~1min вываливаются все накопленные > длинные запросы и показывают ожидаемое значения ~1 min для $request_time и > upstream_response_time. Мой вывод - nginx не принимает новых запросов пока Неправильный вывод. Правильный - апстрим (бекенд) ковыряет в носу в течение минуты и только после этого отвечает. > не обработаются старые длительные. Меня это не устраивает. Я хочу отменить, > сделать reset и т.д. для старых запросов при получении новых запросов с > того же самого IP. Вам уже как минимум трижды сказали: делайте это на бекенде и всё будет работать как вы хотите. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
повторная загрузка модуля
Прошу прощения за глупый вопрос, но, что-то, в коде у меня сходу не получилось найти ответ на этот вопрос... Как NginX относится к повторной загрузке динамического модуля (если load_module с тем же самым модулем будет вызван несколько раз)? Особенно, в случае, когда некоторым другим модулям важно чтобы указанный был загружен раньше них (и первый инстанс таки был загружен до них, а потом загружен повторно). Или, наоборот, если модулю важно быть загруженным как можно раньше (mod_security, там, какой-нибудь, naxsi и иже с ними), и он таки был, а потом был "загружен" повторно. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить POST в папку, но разрешить дальше
location = /users {
deny all;
}
location / {
...
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
arut/nginx-python-module и django
Всем привет. Я тут обнаружил довольно интересную штуку, запиленную Ромой Арутюняном: https://github.com/arut/nginx-python-module Впилил её в свой ebuild NginX'а и решил потестировать. Возникла мысль попробовать завести под ним Django (чтобы наконец выкинуть богомерзкий Passenger). И что-то как ни кручу, не могу скрестить ужа с ежом :( Никто доселе не пытался повторить подвиг? // Ну, или если сам Рома будет проходить мимо - я бы и от него ответ был бы рад услышать тоже :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-dav-ext-module
> Может, таки сделаете? В очередной раз приходится собирать nginx из > исходников вместо того, чтобы поставить из пакета... А почему бы не использовать динамический модуль? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Почему в пособии для новичков не описано,какие папки для чего нужны?
В письме от пятница, 7 июля 2017 г. 16:14:41 +07 пользователь Nadya написал: > Прошу прощения, вы же просто создаете папки сами,так? а где ж взять конфиг > для sites-available и что в нем должно быть написано? Из документации. И директории (папки, они, знаете ли, в Windows), могут называться АБСОЛЮТНО как угодно. Изначально NginX читает *только* nginx.conf. Никакие директории его не интересуют. И даже если вы их добавите - ему не будет до них никакого дела. А то, в какие директории NginX смотрит и что из них инклудит в nginx.conf зависит от, собственно того, что указано в nginx.conf в качестве аргумента для директив(ы) include. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Почему в пособии для новичков не описано,какие папки для чего нужны?
> > Кроме того, обычно в директории /etc/nginx содержится две директории > > sites-enabled и sites-available. > это debian-way. в redhat-relatives этих директорий из коробки нет (но > я всегда добавляю, да) А у меня более удобная для автоматизации структура инклудов: access.d/ # ACL-листы по IP auth.d/ # надоры логинов-паролей для auth-модуля clients.d/ # "клиенты" (файлы с инклудами из vhosts.d/*). Чтобы удобнее и быстрее было включать-выключать клиентов целиком, не тратя время на выгребание всех его вхостов frontends.d/ # конфиги http, mail и stream модулей (и прочих 3party) ssl.d/ # dhparams.pem и прочее templates.d/ # "шаблоны" инклудов (для php, для всяких CMS и прочее) upstreams.d/ # конфиги апстримов vhosts.d/ # из названия, думаю, очевидно :) Такая схема очень удобна для скриптования и прочей автоматизации кастомными наколеночными панелями и прочим :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не понимаю в чем причина кода ответа 504 с ошибкой Connection timed out
Возможно просто попадаете на рестарт воркера ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Получить файл в папке
> А если исходим из соображения, что не передаёт.
Вы, конечно, простите, но... Вам просто поговорить захотелось?
Ваш вопрос не имеет ровным счётом ничего общего с NginX и списком рассылки по
нему.
(Да, то, что вы поставили NginX и этот вопрос у вас возник при работе с ним -
не играет никакой роли. Сам вопрос оффтопичен до последнего байта).
Ваш вопрос - самый что ни на есть философский. И ответ на него прсто до БОЛИ
очевиден: да, любой {человек, бот, инопланетянин} СМОЖЕТ подобрать URL, если
ему будет нечем заняться и он начнёт перебирать брутфорсом. Вопрос лишь в
количестве затраченного времени.
Почему это не очевидно лично для вас?
Почему вы думаете, что мы — телепаты-во-времени-и-параллельных-реальностях и
*В ПРИНЦИПЕ* можем знать ответ на вопрос "сможет ли кто-нибудь" как таковой?
Ну и чтобы второй раз не вставать, на будущее (информация для саморазвития):
> x64
Нет такой буквы в этом слове!
Это выдумка маркетологов из M$. Есть архитектура x86_64. Более известная как
amd64 (в честь тех, кто первый выкатил на рынок. И это вовсе не означает amd-
процессор)
> из репозитария
1) репозитория
2) КАКОГО?
Есть дистрибутивные, а есть с сайта nginx'а.
Пакеты там СОВЕРШЕННО разные. Абсолютно. От слова "совсем".
> конфиг по умолчанию
Как правило, среднестатистический участник рассылки вообще не в курсе, какие
там у вас в убунте умолчания.
Куча людей здесь вообще использует FreeBSD. Некоторые - извращаются с Windows.
У меня, вот, более 70 серверов на Hardened Gentoo (тут история умолчит, что у
меня и на ubuntu порядка 30, но они не обязаны были быть, так что не
считается). Ещё куча людей использует всякие красношапки и прочие производные
типа "копеек" и федор.
И никому, поверьте, не хочется просто так (если не сильно интересный вопрос
прямо. Что, впрочем, явно противоречит наличию формулировки "дефолтный конфиг"
внутри него) тратить время на поиск информации, какой же он там, "дефолтный"
конфиг в Ubuntu-то...
И самое главное...
На ваш изначальный вопрос невозможно *однозначно* ответить ВПРИНЦИПЕ.
Потому что в вопросе нет главной информации:
ГДЕ ЖЕ ЭТО ВСЁ ПРОИСХОДИТ?
Если вы это всё делаете на локалхосте, без перманентного доступа к сети, то
шанс, что кто-то подберёт URL — стремится к нулю.
Если на какой-то бездоменной VPS, которой пользуетесь только вы — шанс выше,
но всё равно мизерный.
Если там планирует быть какой-то сайт хотя бы средней посещаемости — шансы ещё
выше, но (тут отсылка к началу письма). Только я очень надеюсь, что этот
вариант — не тот, который планируется быть в реальности.
В общем, вариантов ответа — куча.
Поэтому, научитесь, пожалуйста, задавать вопросы МАКСИМАЛЬНО ПОДРОБНО.
Если вам, конечно, нужен ответ, а не флейм...
// спасибо за внимание
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
[feature] директива ssl для intermediate сертификатов/бандлов
А что уважаемые разработчики думают об имплементации ssl_* директивы для указания в ней intermediate-сертификатов/бандлов (чтобы в certificate можно было указывать только сертификат самого сайта)? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: несколько сертификатов в одном блоке server
В письме от пятница, 12 мая 2017 г. 17:37:36 +07 пользователь Alexander Moskalenko написал: > как уже написали выше - letsencrypt позволяет получать сертификаты до 100 > доменов А ещё ОП мог бы перестать быть привередой с субъективным "неудобно" и объяснить чуть более объективно :) Ну или использовать lua-модуль. Тот - умеет отдавать сертификаты по условиям. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не работает perl_set при использовании perl module
В письме от четверг, 11 мая 2017 г. 4:28:42 +07 пользователь Alex Domoradov написал: > Запустил уже из командной строки > > # RACK_ENV=PROD /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf > > все равно не логирует ничего Зайдём с другой стороны: зачем вам логгировать эту переменную? :) В любом случае она должна быть выставлена через `passenger_app_env` или более специфичные её варианты. А не через те костыли, которыми вы пытаетесь это сделать :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: rewrite в именованный location
> Да, буду использовать include. А ещё в рассылке (вроде бы, в том числе и Игорь) при всяких разных просьбах с добавлением поддержки всякой магии для много-инклудных конфигураций часто рекомендуют использовать вместо этого самописный генератор конвига nginx, который всю магию сделает сам, а уже потом запишет готовую статическую конфигурацию в файл :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Proxy pass изменить ответ
nginx-lua-http(или stream)-module (сторонний) nginx-njs-module (от авторов nginx, не встроенный) nginx-perl-module (встроенный) Выбирайте. Впрочем, про возможность сходить (встроенными функциями) по паре локейшнов, обработать результат и отдать что-то своё я точно знаю в первом из перечисленных. Остальные, как-то, не ковырял. Но, думаю, тоже должно быть можно. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.12.0
В письме от среда, 12 апреля 2017 г. 22:19:37 +07 пользователь Maxim Dounin написал: > Изменения в nginx 1.12.0 12.04.2017 > > *) Стабильная ветка 1.12.x. А когда ждать первый релиз 13? (а то в родмапе написано, что due: год, но это, я так понимаю, до завершения :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как правильно настроить nginx proxypass?
> но после ввода логина и пароля происходит ошибка. Не пойму в чем > проблема и вообще где она К сожалению, у нас ещё меньше (чем у вас) шансов узнать "в чём проблема и вообще где она", так как мы не видим ни текста ошибки, ни логов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [OFFTOP-subthread] Вопрос по TLS и аутентификации
> Насколько я знаю как раз таки школы Школы, как раз, наиболее успешно саботировали. К тому же, особенной "пушкой" было то, что поручили внедрение компании, очень тесно афиллированной с Microsoft Rus. > суды (по крайней мере приставы) В том-то и дело, что только приставы. И запилили свой велосипед. А я говорил о ситуации когда сначала в 2008 Медведев говорил что "переходим на СПО", а в 2009 известная контора по распилу НИИ «Восход» берёт и выкатывает ГАС «Правосудие» (на пару с ГАС «Трибунал»), которые так же, как и у вас завязаны на этот ActiveX по самые гланды. Естесственно, учитывая сколько денег было вбухано на мраморные кабинеты председателей суда переобучение судей и помощником с самописных программ, написанных местными программистами на использование этих ГАСов, что при попытке внедрить СПО это было встречено очень сильным саботажем. > Однако, как заставить кучу бухгалтерского софта, выпиленного под > активХ Ну, как предприниматель, скажу, что вопрос вполне решаемый. Есть куча "облачных" систем документооборота (включая бухгалтерского), которым без разницы, какая ОС на пользовательском компьютере. И среди них даже есть те, которые так же имеют возможность быть установлены локально, в контролируемом окружении. > и ДотНет работать на "нормальных ОС" Ну, если не собирать совсем уж кривожопо (простите мой француский), то под mono всё прекрасно запускается (но для этого, да, необходимо какможно меньше использовать Win-специфичные штуки типа WinAPI и захардкоженных путей). > ? Вайн тут не прет... это не 1С. 1С, кстати, одна из тех самых систем, умеющих в облачность. Как ни странно... Только стоит неоправданно дороже аналогов. > Поэтому приходится для бухов держать окна открытыми Опять же, бухгалтерия - дело десятое. Можно было бы это как-то потерпеть, если бы не было саботажа в других сферах. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по TLS и аутентификации
> до этого я им разработал форму генерации ключей ЭП (ActiveX) :'( Так вот он, оказывается, один из тех самых "исполнителей", из-за которых саботировали внедрение нормальных ОС в судах, школах и прочих госорганах :) P.S.: да, я понимаю, что делали что заказывали. Просто до этого письма думалось что это какие-то эфемерные существа из параллельной вселенной. А тут, оказывается, что они здесь, в той же рассылке :) // хотя, судя по футеру писем, вы даже и не в рассылке, а в веб-морде к ней :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: после yum update остались активны два мастер-процесса nginx
> Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным > образом. В systemd же вполне работает systemctl edit svcname. И так администратор может добавить Environment=VAR=VALUE... > Спасибо! ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Путь поиска динамических модулей по умолчанию
> 3) я бы, вообще, раз у вас WONTFIX, поставил бы prefix в что-то типа > /var/lib/ nginx, но не уверен, что NginX потом из-за этого не выстрелит по > ногам где- нибудь в другом месте :( К слову, по этому поводу, если я сделаю `--prefix=/var/lib/nginx`, а так же укажу вот так: ``` --http-client-body-temp-path="tmp/client" \ --http-proxy-temp-path="tmp/proxy" \ --http-fastcgi-temp-path="tmp/fastcgi" \ --http-scgi-temp-path="tmp/scgi" \ --http-uwsgi-temp-path="tmp/uwsgi" \ --modules-path="modules" \ ``` Он же в рантайме поймёт, что пути тут относительно префикса? или лучше везде указать полные? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Путь поиска динамических модулей по умолчанию
> В конфигурации nginx'а уже существует два типа путей, которые > используют в качестве базы разные префиксы - просто префикс и > "конфигурационный". Добавлять к этому ещё дополнительный префикс > для модулей - нет никакого желания, префиксов и так на один > больше, чем должно быть. Ну, вот "префиксный", в отличие от "конфигурационного", как раз-таки и не то, чтобы особо был нужен, если задуматься :) А вот конфигурационный и модульный - довольно удобны. > Рекомендую посмотреть на пакеты с nginx.org, там --prefix ставится > в /etc/nginx и проблема исчезает. 1) хранить бинарные модули в /etc — нарушение FHS. Да и противоречит дистрибутивной политике многих дистрибутивов. По возможности в гайдлайнах просят такого избегать. 2) ну, да, получается "не как у всех" :) 3) я бы, вообще, раз у вас WONTFIX, поставил бы prefix в что-то типа /var/lib/ nginx, но не уверен, что NginX потом из-за этого не выстрелит по ногам где- нибудь в другом месте :( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Путь поиска динамических модулей по умолчанию
Данный пост, скорее, обращение к Максиму, т.к. именно он закрыл связанный с тем, о чём пойдёт речь, баг: ( https://trac.nginx.org/nginx/ticket/961 ), но я так же приглашаю остальных участников рассылки высказать свои мысли по этому поводу. Суть же моего обращения в том, что в данном вопросе я, всё же, больше солидарен с ожиданиями автора бага, нежели с решением команды разработки, и думаю, что фича в виде установки c `--modules-path` не только пути установки модулей, но и пути, по которому NginX будет их искать - довольно логична. Стандартно, многие linux-системы собирают софт с `--prefix=/usr` и т.п. (в общем, разбивкой служебных путей по разным частям фс). Порой на это даже трудно повлиять, не переделывая билдскрипты. В общем, "среднестатистическая" линуксовая сборка NginX выглядит так: ``` --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/ nginx/error.log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock -- with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib64 --http-log-path=/var/ log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client -- http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/ lib/nginx/tmp/fastcgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --http- uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi ``` При этом подразумевается, что свои модули и прочие "свои" файлы софт будет хранить не в системных директориях, а в своих поддиректориях. В случае же NginX, при обычной сборке, modules_path получается /usr/modules (я так догадываюсь, из-за того, что по умолчанию оно имеет значение $prefix/ modules). В итоге получается крайне не логичный путь, как по мне. Что ещё за /usr/ modules? Тут на помощь приходит `--modules_path`. Но, к сожалению, после установки NginX всё равно будет пытаться искать файлы относительно префикса. И класть там симлинк - тот ещё костыль и равноценен тому, чтобы поставить их туда напрямую (см. довод про нелогичность пути). В случае инклуда конфигов, к слову, nginx вполне логично ищет их в /etc/nginx, а не в prefix (хотя надо уточнить, не дистрибутивный ли патч фиксит это поведение). Так почему бы не сделать такое же по смыслу и для модулей? Чтобы не провоцировать кучу лишней писанины на пустом месте :) Так же, можно было бы на этапе сборки хардкодить расширение динамических библиотек (so, dll, dylib), и так же не заставлять конфигописателя указывать этот суффикс в конфиге, а просто конкатенировать параметр load_module (если он в виде относительного, а не абсолютного пути) с "modules_path" спереди и shared_suffix на конце. Что думаете? // особенно Максим ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.11.11
В письме от вторник, 21 марта 2017 г. 22:19:04 +07 пользователь Maxim Dounin написал: > *) Добавление: улучшения в скриптах подсветки синтаксиса для vim. >Спасибо Wei-Ko Kao. А можно вот про это поподробнее? А то я как раз хотел пожаловаться, что какая-то релиска там придумала делать `iskeyword+=/`, из-за чего пути в соответствующих директивах редактировать не очень удобно :) Если исправили именно это, то это очень даже замечательно :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: merge_slashes
> тема с merge_slashes redirect достаточно популярная, > странно что это до сих пор еще никто не реализовал в nginx. На самом деле это попахивает недопониманием некоторыми "SEO'шниками" реальных алгоритмов работы поисковиков (собственно, а откуда бы им их понимать, если не они их разрабатывали). На сколько я могу судить (может я что-то делал не так), но гугл и яндекс не настолько тупые, чтобы не смочь смерджить слеши при обработке и понять что это одна страница. Ну и отдельный вопрос как вообще ссылки с кучей слешей становятся известны поисковикам. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Чтение метки DoD Security Option (RFC1108)
Почему вы вообще решили это делать на NginX, а не на... Да на чём угодно, что более узкоспецифично, чем веб-сервер :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Будет ли LUA module добавлен в yum репозиторий?
1) https://www.lua.org/about.html#name > Please do not write it as "LUA", which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right! !!! 2) скорее всего нет, т.к. сообщество разработчиков настроено решительно против него в связи с качеством кода ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.11.10
> На практике более гибко и удобно чтобы приоритеты НТТР заголовков были > всегда выше, директив из конфига, есть proxy_ignore_headers если нужно > обратное. 1) я бы предпочёл чтобы это было регулируемым поведением 2) и что, всю толпу заголовков перечислять в ignore, если вдруг хочется чтобы всё происходило ровно так, как описано в конфиге? :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.10.1 -> nginx-1.10.3
> а как делают откат на предыдущую версию? Или отключают подключенный репозиторий и переустанавливают, или явно указывают пакетному менеджеру какую версию и из какого репозитория поставить (тут уж нужно знать специфический синтаксис пакетного менеджера, а Ubuntu тут используют далеко не все, и я, увы, не из числа тех, кто её использует. Вот спроси вы как это сделать на Hardened Gentoo я бы подсказал :) Впрочем, я, как раз, на днях буду на Ubuntu поднимать одно web-приложение и даже закажу у хостера под него виртуалку с ISPManager'ом (я-то сам ненавижу эти веб-панели за то, что они не дают настраивать систему как удобно и заставляют затачивать её под них, но т.к. использовать буду не я, то от него никуда не деться), так что, глядишь, возможно, и отвечу на ваши вопросы :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.10.1 -> nginx-1.10.3
В письме от суббота, 11 февраля 2017 г. 4:25:47 +07 пользователь Vvedensky написал: > Вопрос на сколько критичен параметр > --add-dynamic-module=debian/extra/njs-1c50334fbea6/nginx и можно ли его > безболезненно выкинуть (при запуске конфигурирования выдаёт следующее > сообщение: ./configure: error: no debian/extra/njs-1c50334fbea6/nginx/config > was found) или желательно что-то доустановить? В папке с исходниками, по указанному пути, нет исходников модуля `njs` (встроенный javascript для nginx). Если вы его не используете, то можете выкинуть. Если используете, то можете стянуть исходники с mercurial- репозитория и подправить ревизию. Впрочем, правильнее, имхо, было бы дождаться обновления от мейнтейнеров :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Опять про кеширование
> тяжелым динамическим страницам > чистый html 1) это как? Динамика, всё-таки, или статика? > чистый html > настраиваем кэш 2) Если всё же статика, то не проще было бы просто в tmpfs класть? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: server_name в X-Original-URL
В письме от среда, 4 января 2017 г. 22:37:01 +07 пользователь Dzmitry Stremkouski написал: > приходит server_name = secure.stremki.net Насколько я знаю, приходит не "server_name", а заголовок. либо HTTP_HOST, либо HTTP_SERVER_NAME, либо ещё какой. И в зависимости от того, какой из них вы проверяете, это может быть и just as planned. Я сейчас по памяти не помню, но какой-то заголовок и в самом деле передаёт первый хост из server_name, а какой-то — реальный хост, на который постучался клиент. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ещё один редирект
> Пробовал ваш вариант:
> location = /robots.txt {
> alias /robots1.txt;
> }
> не работает. Говорит "файл не найден".
Нет, мой вариант *не* `alias /robots1.txt`. Мой вариант — `alias /path/to/
robots1.txt`. Разница в том, что путь абсолютный (хотя, возможно, можно
использовать `$document_root/robots1.txt` (если нельзя, то просьба к тем, кто
помнит точнее, поправить этот момент).
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ещё один редирект
> Разобрался, правильно так
> location /robots.txt {
> try_files /robots1.txt @rewrite;
> rewrite /robots1.txt permanent;
> }
Кроме того, что таки неправильно, чем не нравится озвученный мной вариант с
alias? Или озвученный выше вариант с переменными?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ещё один редирект
location = /robots.txt {
alias /path/to/robots1.txt;
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Подключение модуля ngx http upstream module
> 1.11.8, который планируется сегодня А "сегодня" по какому часовому поясу? :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: феншуй по массовой настройке https
В письме от пятница, 16 декабря 2016 г. 12:18:00 +07 пользователь Oleg Motienko написал: > А как поможет lua модуль? У него есть ssl_by_lua_* (или как-то так). И на гитхабе, помнится, был один resty-* проект, который позолял автоматически выпускать (если ещё не выпущен), продлевать (если пора) или выдавать готовый LE-сертификат. > > 2016-12-16 12:00 GMT+03:00 Vadim A. Misbakh-Soloviov <ng...@mva.name>: > > > Вариант с lua-модулем не рассматривается? > > > > > > > > В письме от пятница, 16 декабря 2016 г. 11:55:33 +07 пользователь Oleg > > Motienko написал: > > > >> Добрый день. > >> > >> > >> > >> Есть виртуальный хостинг, где-то 500-700 хостов на один IP адрес с > >> reverse proxy на nginx. Имена сайтов, пути и т.п. заведены в map, т.е. > >> фактически сделана одна секция server. > >> > >> > >> > >> В связи с последними нововведениями в браузерах решили сделать для > >> клиентов let's encrypt. > >> > >> > >> > >> Поделитесь опытом, как лучше настраивать https реверс прокси для такой > >> ситуации? Генерировать конфиг с секцией server на каждого клиента > >> кажется тяжеловатой схемой. Можно ли как-то через map указывать пути к > >> ssl сертификатам? > >> > >> > >> > >> Спасибо! > >> ___ > >> 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 > > > > > -- > Regards, > Oleg > ___ > 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: феншуй по массовой настройке https
Вариант с lua-модулем не рассматривается? В письме от пятница, 16 декабря 2016 г. 11:55:33 +07 пользователь Oleg Motienko написал: > Добрый день. > > Есть виртуальный хостинг, где-то 500-700 хостов на один IP адрес с > reverse proxy на nginx. Имена сайтов, пути и т.п. заведены в map, т.е. > фактически сделана одна секция server. > > В связи с последними нововведениями в браузерах решили сделать для > клиентов let's encrypt. > > Поделитесь опытом, как лучше настраивать https реверс прокси для такой > ситуации? Генерировать конфиг с секцией server на каждого клиента > кажется тяжеловатой схемой. Можно ли как-то через map указывать пути к > ssl сертификатам? > > Спасибо! > ___ > 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 + Windows = Дружба? Время пришло!
А почему бы на Windows не использовать родной для неё IIS, который намного более допилен для работы в Windows (впрочем, только в ней, лол) и имеет хорошую техподдержку? :) В письме от пятница, 16 декабря 2016 г. 2:53:13 +07 пользователь sofiamay написал: > Нет, для Highload как раз Linux вне конкуренции. Я говорю лишь о том, что на > Windows сейчас можно было бы сделать относительно неплохое по > производительности решение для средних обывательских проектов. Чтобы Nginx > мог сравнимо работать под Windows и Linux без прицела на Highload сегмент. А > если такая возможность есть, то почему её не использовать... Под Windows на > данный момент решены практически все существовавшие ранее проблемы в работе > Nginx, кроме этих двух. Давайте решим хоть одну... > > Поэтому и предложил, раз столько лет нет никаких подвижек в написании > IOCP/Multiple-Thread модели, то достаточно будет сделать доступными всего > две опции, с которыми можно будет жить под Windows. Впрочем еще год назад > просил и говорил об этом. Одну опцию два месяца назад сделали доступной в > бесплатной версии Nginx, но только её, без [queue число timeout=время] в > upstream. > > Согласен с вами, что нет примеров массового использования Windows, поэтому > разработчики Nginx и не видят смысла что-то активно делать в этом > направлении и с этим можно согласиться. Но ведь никто с этим и не спорит, я > говорю лишь о том, что было бы неплохо дать Windows сегменту хоть что-то, > что сделает возможным нормальную работу Nginx на этой платформе. Почему > просто не дать людям работать? Достаточно открыть вторую опцию и наконец > можно будет начать использовать Nginx на Windows в связке с FastCGI PHP, > пользователи вздохнут свободно и смогут еще энное количество лет ждать > реализации IOCP/Multiple-Thread модели. > > kemko Wrote: > --- > > > Увидел много слов о том, что теперь на Windows можно Highload, но нн > > увидел > > ни одного слова о том, что на Windows стали делать Highload. Есть > > какие-то > > отчеты, которые показывают, что доля этой ОС на web-серверах начала > > расти и > > ей срочно нужно уделять больше времени? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,271476,271589#msg-271589 > > ___ > 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: proxy_store - HTTP headers
> Нет. > Нет. Что, впрочем, не мешает автору треда взять прокси-модуль, немного изменить код и радоваться жизни :) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: "debug_connection" is ignored в готовых пакетах
В письме от воскресенье, 4 декабря 2016 г. 14:38:15 +07 пользователь Андрей Василишин написал: > Заметил, что в готовых пакетах, взятых отсюда > http://nginx.org/ru/linux_packages.html пакеты почему-то собраны без > --with-debug. С чем связана такая политика? Не то, чтобы я особый пользователь дебианов/шапок и их производных, но разве там не был отдельнй пакет nginx-debug (где бинарь NgX собран с --witi-debug) для этих целей? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: HACK NGINX+DAV
SELinux, AppArmor, ... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx performance problem on linux
> А если серьёзно, у кого есть опыт использования именно LXC, когда я openvz > начал использовать его ещё не было. Смотря для каких целей. Если "для себя" (контейнеризировать сервисы), то у меня есть опыт и того и другого, и, впринципе, с libvirt'ом lxc ничуть не хуже VZ в управлении. Веб-панели я всё равно не люблю (в т.ч. за привередство), так что по ним не подскажу. А вот именно для целей хостинга (продавать клиентам), то, как правило, те, кто берёт VZ/LX-контейнеты не понимаю на что они "подписываются" (и, кстати, вы в курсе, что OVZ хостеры любят только лишь за возможность гипероверселлинга? ☺). Лично я, вот, например, имею пучок VZ-хостов по всему миру (как exit-ноды VPN для личного пользования) только лишь из-за их стоимости в виде 2.5 евро в год (sic!). Но, как можно догадаться, это не у российских хостеров. Они на такие предложения не спобны :) А для хостинга проектов брать VZ (не путать с арендой дедика и VZ'изацией своими руками) — что называется "зашквар". Ну и как я уже сказал выше, если контейнеризировать самому, то LXC уже практически не уступает. // а вот LXD — какой-то уж больно перемудрёный. То — нельзя, это — черезанально, и так далее. Проще "голый" lxc и, если уж сильно надо, libvirt ;) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
