Re: pipe to http
Очевидно, но nginx ведь не умеет сам ничего запускать. Попробовал fcgiwrap, но или я что-то делаю неправильно, или когда клиент отваливается - sigpipe до скрипта не доходит. 07.11.2018 12:07, Dmitriy Lyalyuev пишет: X-Accel-Redirect похоже то, что вам нужно. -- With best regards, Dmitriy Lyalyuev dmit...@lyalyuev.info <mailto:dmit...@lyalyuev.info> On Nov 7, 2018, at 02:59, Nick Knutov <mailto:m...@knutov.com>> wrote: Доброго времени суток, подскажите, как лучше реализовать такую задачу: запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), который проверяет авторизацию, и если всё ок, то необходимо запустить какой-то процесс, который отдаст много гигабайт данных в stdout и это надо отдать хттп-клиенту. Причем, важно, если клиент отвалился - процесс нужно убить. Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше перловым скриптом, но он ест неприемлемо много проца и имеет непонятные проблемы с буферизацией и медленными клиентами. Нельзя ли в скрипте ограничиться чем-то вроде внутреннего редиректа и остальную работу сделать на уровне nginx? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ 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 -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
pipe to http
Доброго времени суток, подскажите, как лучше реализовать такую задачу: запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), который проверяет авторизацию, и если всё ок, то необходимо запустить какой-то процесс, который отдаст много гигабайт данных в stdout и это надо отдать хттп-клиенту. Причем, важно, если клиент отвалился - процесс нужно убить. Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше перловым скриптом, но он ест неприемлемо много проца и имеет непонятные проблемы с буферизацией и медленными клиентами. Нельзя ли в скрипте ограничиться чем-то вроде внутреннего редиректа и остальную работу сделать на уровне nginx? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Поддержка idn-доменов
А зачем это всё? Конфиги же генерируются не людьми, комментарии в конфигах никто не запрещал. Мы просто при перегенерации конфигов пишем строчку с комментом и всё удобно (да и остальную информацию для отладки сборки конфигов все равно приходится писать) 16.03.2016 22:30, Vadim A. Misbakh-Soloviov пишет: Вроде бы подобное в листе уже пробегало, но, что-то, я не смог найти в своих архивах. В общем, я хотел бы спросить на счёт того, то товарищи разработчики думают о том, чтобы добавить опциональную директиву при сборке для линковки с libidn (ну, или не добавлять, а реимплементировать своими силами) для того, чтобы получить поддержку idn-доменов в конфиге? А то уж очень задалбывает конвертировать все IDN-домены перед добавлением, а потом ещё конвертировать обратно чтобы вспомнить что это за домен. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
opera + html тег audio
Есть html страница с кодом audio src=...mp3 controls= loop=/audio Файл по ссылке отдается nginx, который проксирует запрос на апач. Оказалось, что файл нормально играется, например, любой последней версией хрома, однако в опере (и 12.* и на движке хрома) при нажатии на иконку проигрывания кнопка становится неактивной. В гугле находится, например, это - http://stackoverflow.com/questions/1995589/html5-audio-safari-live-broadcast-vs-not , но не ясно, какие и как заголовки в nginx и/или апаче мне добавлять, если это статический файл. Кто-нибудь с таким сталкивался? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как прибить специфических ботов средствами Nginx
Это плохой путь. ип адресов может быть очень много. Лучше почитать документацию и на map/if сделать правила на заголовки. 31.05.2014 23:44, Михаил Монашёв пишет: [...] Пиши лог нужные поля, а в цикле с паузой в секунду грепай этой лог по известным значения, вытаскивай ip и бань по нему силами фаервола. Это почти реально время, не ресурсозатратно и весьма гибко. Со временем можно будет дополнять правила, по которым ip надо вытаскивать. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: listen на всех ип кроме 127/8
А с linux/openvz совсем вариантов нет? И даже никакого workaround-да, чтобы попроще, чем переписывать все конфиги? 04.12.2013 11:06, Igor Sysoev пишет: [...] А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, наверное, IPv6:::1) ? Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть именно на 80ом порту, а внешний(ие) ип (на которые должен биндится нгинх) часто меняются (и их количество вообще может быть не известно, отвечать надо на всех). Хочется делать релоад нгинх без переписывания кучи конфигов (виртуалхостов - много, очень много). А что за система и ядро? Многие современные, [ не Линуксы ] IIUC, позволяют одному слушать на *:80 и остальным откусывать у него specific:80 -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: listen на всех ип кроме 127/8
Linux, OpenVZ. 04.12.2013 3:44, Dmitry Morozovsky пишет: On Wed, 4 Dec 2013, Nick Knutov wrote: А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, наверное, IPv6:::1) ? Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть именно на 80ом порту, а внешний(ие) ип (на которые должен биндится нгинх) часто меняются (и их количество вообще может быть не известно, отвечать надо на всех). Хочется делать релоад нгинх без переписывания кучи конфигов (виртуалхостов - много, очень много). А что за система и ядро? Многие современные, IIUC, позволяют одному слушать на *:80 и остальным откусывать у него specific:80 -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
listen на всех ип кроме 127/8
А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, наверное, IPv6:::1) ? Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть именно на 80ом порту, а внешний(ие) ип (на которые должен биндится нгинх) часто меняются (и их количество вообще может быть не известно, отвечать надо на всех). Хочется делать релоад нгинх без переписывания кучи конфигов (виртуалхостов - много, очень много). -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
релоад конфига
В последних нескольких версиях nginx не перечитывает конфиг по сигналу HUP (рестарт при этом приводит к запуску нгинх с новым конфигом). Что-то изменилось, или я что-то делаю не так? # cat /var/run/nginx.pid 31162 # kill -HUP 31162 # ps auxfw | grep nginx root 31162 0.0 1.0 50912 26612 ?Ss Aug11 0:00 nginx: master process /usr/sbin/nginx nobody 31163 0.1 1.0 51756 27440 ?SAug11 6:50 \_ nginx: worker process nobody 31164 0.1 1.0 52152 27976 ?SAug11 6:51 \_ nginx: worker process Aug11 осталось как было (а сейчс Aug14), при обращении по хттп видно, что конфиг старый. # nginx -t nginx: [warn] low address bits of ***.***.***.***/27 are meaningless in /etc/nginx/nginx.conf:96 nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: релоад конфига
# nginx -V nginx version: nginx/1.5.2 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --with-cc-opt='-D FD_SETSIZE=2048' --http-client-body-temp-path=/var/cache/nginx/body_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --lock-path=/var/lock/nginx.lock --with-http_ssl_module --with-http_stub_status_module --with-http_flv_module --with-http_mp4_module --with-http_realip_module --with-http_gzip_static_module --with-http_secure_link_module --with-http_sub_module --with-file-aio --with-pcre=/root/build/deb-build/nginx-1.5.2/../pcre --with-pcre-jit --with-http_geoip_module --add-module=/root/build/deb-build/nginx-1.5.2/debian/modules/ngx-fancyindex Обнаружил, что на другом сервере всё ок: после после kill -HUP /# ps auxfw | grep nginx root 14565 0.0 1.8 62696 47664 ?Ss Aug07 0:00 nginx: master process /usr/sbin/nginx nobody9406 0.3 1.7 62628 45860 ?SAug11 13:22 \_ nginx: worker process is shutting down nobody9407 0.2 1.7 62628 45852 ?SAug11 13:10 \_ nginx: worker process is shutting down nobody 24697 0.8 1.8 62700 47464 ?S14:56 0:00 \_ nginx: worker process nobody 24698 0.0 1.8 62700 47444 ?S14:56 0:00 \_ nginx: worker process Сборка nginx на обоих серверах одинаковая (у нас собственные сборки деб пакетов), на обоих серверах нгинх поставлен из одного деба, оба сервера OpenVZ с одним ядром и одной убунтой # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 12.04.2 LTS Release:12.04 Codename: precise на которой стоят одинаковые пакеты. Проблема на первом сервере стабильно воспроизводится. 14.08.2013 16:55, Nick Knutov пишет: В последних нескольких версиях nginx не перечитывает конфиг по сигналу HUP (рестарт при этом приводит к запуску нгинх с новым конфигом). Что-то изменилось, или я что-то делаю не так? # cat /var/run/nginx.pid 31162 # kill -HUP 31162 # ps auxfw | grep nginx root 31162 0.0 1.0 50912 26612 ?Ss Aug11 0:00 nginx: master process /usr/sbin/nginx nobody 31163 0.1 1.0 51756 27440 ?SAug11 6:50 \_ nginx: worker process nobody 31164 0.1 1.0 52152 27976 ?SAug11 6:51 \_ nginx: worker process Aug11 осталось как было (а сейчс Aug14), при обращении по хттп видно, что конфиг старый. # nginx -t nginx: [warn] low address bits of ***.***.***.***/27 are meaningless in /etc/nginx/nginx.conf:96 nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: релоад конфига
ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3. Что искать в дебаг логе? Я не вижу там никаких признаков получения сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно работает. 14.08.2013 17:58, Gena Makhomed пишет: On 14.08.2013 14:02, Nick Knutov wrote: [...] Проблема на первом сервере стабильно воспроизводится. причину проблем может помочь понять отладочный лог: http://nginx.org/ru/docs/debugging_log.html параметр --with-debug много оверхеда не добавляет, но очень удобен при поиске причин различных проблем. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Переменная $https
Спасибо, это полностью решило задачу. 06.08.2013 11:56, Olexander Shtepa пишет: Вопрос уже скорее про апач, но есть ли возможность добавить ему переменную HTTPS средствами извне при отсутствии mod_ssl (ссл терминируется на нгинх, у апача только хтпп)? Я делаю так: На nginx: proxy_set_header X-SCHEME $scheme; В apache: SetEnvIf X-SCHEME ^https$ HTTPS=on И, соответсвенно, так, чтобы у ней были значения on|off, в отличии от переменной среды. Если так прям хотите off, до можна добавить: SetEnvIf X-SCHEME ^http$ HTTPS=off -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Переменная $https
В нгинх - $https “on” если соединение работает в режиме SSL, либо пустая строка А вот в апаче - HTTPS Will contain the text on if the connection is using SSL/TLS, or off otherwise. Вопрос - почему в нгинх сделано так, правильно ли это и не стоит ли поменять поведение этой переменной на как в апаче? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли
Меня всегда неимоверно радовали господа, предлагающие что-нибудь глобально запрестить для всех ип и сделать исключение для ип одного человека. Догадайтесь почему :) Остальные сайты (да и атакуемые) и так прекрасно работают при правильном софте/конфигах. 2 - нереалистичная идея. Шаред хостинг например, таких сайтов - тысячи. Да и проблему никак не решает, потому что ссылка на этот логин будет на главной странице, например, потому что там кроме админа могут быть и другие юзеры. 04.08.2013 17:39, Виктор Вислобоков пишет: А мне кажется всё это неэффективно. IP адресов прорва и каждый задолбаешься блокировать, а нагрузка прёт. Эффективных вариантов вижу 2: 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и сам владелец сайта зайти не сможет, но для его IP можно сделать исключение. Зато остальные сайты на сервере смогут нормально работать 2. С участием владельца сайта переименовать файл для входа в какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php, чтобы данное имя было известно только владельцу сайта. А на /administator/index.php поставить статическую заглушку, которую nginx может отдавать со скоростью пулемёта. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли
Я - хостер. Я не верую, я это вживую вижу на наших серверах. Но у нас свои сборки софта, которые мы вылизываем, и очень нестандартные конфиги, потому всё это работает. Маленькие ботнеты мы не замечаем, большие фильтруем, с нашей стороны всё обычно работает, если это боты, а не забивка канала. А циска - да, циска может и ложится. А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт. Гарантированно решит проблему. 04.08.2013 21:56, Виктор Вислобоков пишет: Остальные сайты (да и атакуемые) и так прекрасно работают при правильном софте/конфигах. Ну-ну, блажен кто верует! При хорошей атаке с большого ботнета, даже циска ложиться, куда уж вам с вашими конфигами. Вас видимо просто ни кто ни разу КОНКРЕТНО не ддосил. 2 - да не очень хорошее решение. Тут предложили пароль ставить на каталог - тоже выход!\-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли
Тем, что он пропускает запросы на бекэнд. Размер ботнета, перебирающего пароли - примерно 100 000 ип. Он не весь сразу приходит, но в общем случае, или можно использовать простое ограничение вроде с одного ип не чаще 1 запроса в минуту/секунду, но это просто снижает нагрузку до приемлимого уровня, а не решает проблему. Если придумывать что-то сложнее, чем фильтр по $binary_remote_addr, то это надо еще думать, и памяти оно начинает занимать заметно больше. При этом уже существуют хорошо работающие правила для mod_security (и не только на конкретно этот случай) и для naxsi есть doxi-rules (которые я уже даже перестал пытаться понимать) 03.08.2013 16:31, Maxim Dounin пишет: Hello! On Sat, Aug 03, 2013 at 01:31:03AM +0600, Nick Knutov wrote: Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе и джумле от ботов, перебирающих пароли? У меня, например, не удалось быстро заставить работать naxsi + doci-rules, ищу альтернативы. [...] Я стесняюсь спросить - а limit_req чем не подходит? http://nginx.org/r/limit_req -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
ModSecurity, защита WP и джумлы от ботов, перебирающих пароли
Кто-нибудь использует ModSecurity для nginx в продакшене? Как оно сейчас, стабильно ли? Заодним, какие есть хорошие и простые методы защиты сайтов на вордпрессе и джумле от ботов, перебирающих пароли? У меня, например, не удалось быстро заставить работать naxsi + doci-rules, ищу альтернативы. -- Best Regards, Nick Knutov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
