Re: Как запустить nginx на IP, которое выделяется через OpenVPN
Здравствуйте, digger. Вы писали 27 февраля 2018 г., 19:36:49: > Мне нужно запустить nginx на адресе IP, который выделяется клиентом > OpenVPN. > Проблема в том, что этот адрес появляется не сразу после загрузки хоста, а > через некоторое время. Это у вас неправильная конфигурация. Настройте систему, чтобы она автоматически создавала и конфигурировала интерфейс при старте. должно быть аналогичное тому, что сделает пара команд: openvpn --mktun --dev tap0 ifconfig tap0 inet 192.168.1.2/24 маршрутизация... В конфиге OpenVPN: dev tap0 #dev tun0 ifconfig-noexec Но есть нюанс - этот айпи не "выделяется клиентом" а "прибит гвоздями", что, впрочем, не слишком противоречит вашему сообщению, т.к. если бы он был бы неизвестен, то не был бы и указан в конфиге nginx. > Соответственно, nginx видит, что адреса IP, прописанного в конфиге, нет, и > не запускается. > Руками потом запустить можно, но должно запускаться автоматически сразу, как > только IP будет доступен. > Подскажите, пожалуйста, как лучше организовать такой запуск? > Если через crontab, то как проверять, что nginx запущен, и как его > запустить, если он не работает? > Спасибо! -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ 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.
Здравствуйте! > Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > будет глючить на системах, где nginx запускается в виде SysV сервиса. Никогда не возникало желания выполнить команду "/etc/init.d/nginx start ; /etc/init.d/nginx stop" Что я делаю не так, или чего не делаю? > - Доктор, когда я вот-вот-так делаю - у меня болит! :(( > - А вы вот-вот-так - не делайте. :-| -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
Здравствуйте, Andrey. Вы писали 21 октября 2017 г., 0:33:01: > Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но > на нем еще много чего написано и пишется. Было бы интересно. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
Здравствуйте, Maksim. Вы писали 20 октября 2017 г., 20:42:54: > Так в таком случае использование unit еще выгоднее: ему не надо держать > master-процесс для каждой версии php, не говоря о процессе для каждого > пользователя. > Если я ошибаюсь - скиньте, плиз, линку на почту где можно подробнее почитать > об опасности > запуска одного мастер-процесса для разных пользователей. Помнится мне, opcache держит кеш в shared memory, создаваемой родительским процессом, и, соответственно, общей для всех дочерних процессов - для всех пулов. Именно из-за этого мы делаем отдельный fpm instance для каждого _собственного_ проекта. Поправьте меня, если заблуждаюсь... > На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ > php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный > php-fpm процесс со своим userid то и не важно какой версии PHP он будет - > всё-равно его запускать придётся. Так что если используется php-fpm то > никакой экономии ресурсов не будет -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ошибки при установке NGINX
Здравствуйте, Andrey_Bushman. Вы писали 18 августа 2017 г., 17:00:26: > Спасибо, вечером попробую проверить. Я по книжкам изучаю Linux и Nginx. Вот > со вторым столкнулся с попыткой установки, т.к. предполагал, что он не > установлен, в виду того, что команды `which nginx` и` whereis nginx` не > возвращали полного имени файла. У Вас также может быть установлен другой сервис, использующий (слушающий) порт 80, например Apache. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: client_body_temp_path - permissions
Здравствуйте.
> Я уточню чтобы меня понимали.
> Мы используем директиву - client_body_in_file_only clean; для получения
> файлов от клиента при аплодинге, указываем директорию в директиве
> client_body_temp_path, все работает хорошо, только пермишены файлов в этой
> папке 0600.
Да, теперь увидел информацию об этой возможности.
В описании директивы "client_body_temp_path" про такую возможность не сказано ни
слова.
При наличии директивы "client_body_in_file_only" и переменной
"request_body_file" ограничение 0600 конечно излишне жесткое и вот это шаманство
в коде nginx:
if (r->request_body_file_group_access) {
tf->access = 0660;
}
выглядит несколько забавно.
Т.е. директиву client_body_in_file_only и переменную $request_body_file
добавили, а
прав на файлы - добавить забыли.
Т.к. нигде не указано, что этими директивой/переменной можно пользоваться только
при использовании DAV (это единственный случай, когда файл создается с правами
0660), то явно требуется изменение прав по-умолчанию.
На мой взгляд, в имеющейся ситуации нужно безусловно создавать файлы с правами
доступа 0660, без создания дополнительных "рычажков".
> Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
> всегда патчить новые версии Nginx, и потом тестировать...
> Будет очень хорошо если его закомитят и будет работать из коробки.
Конечно это было бы очень хорошо, но и иметь возможность запатчить и
использовать - это лучше чем не иметь такой возможности.
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: client_body_temp_path - permissions
Здравствуйте > Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать > всегда патчить новые версии Nginx, и потом тестировать... > Будет очень хорошо если его закомитят и будет работать из коробки. Как-то не вполне ясно, почему вы считаете, что файл в client_body_temp_path >должен быть обработан в другом процессе Это временный файл процесса nginx, и, насколько я понимаю, никакая обработка в других процессах не предусматривается. В силу этого же права выставлены в 0600 и другого быть не может. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: merge_slashes
Здравствуйте. Вы писали 20 марта 2017 г., 21:41:04: > Можно ли сделать в директиве merge_slashes параметр redirect, > чтобы из урла с несколькими слешами в канонический урл > преобразование происходило путем 301 редиректа? Локейшном с регуляркой ситуация не разыгрывается? -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_cache_purge unknown directive nginx from official repo
Здравствуйте, Василий. > nginx: [emerg] unknown directive "proxy_cache_purge" in > /etc/nginx/nginx.conf:80 > При этом nginx поставлен из официального репозитория nginx (debian jessie). Логично, что этого плагина нет в официальном репозитории, т.к. плагин не официальный: https://github.com/FRiCKLE/ngx_cache_purge Попробуйте поставить дебиановский пакет, вроде бы там этот плагин есть. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не работает map c переменными $status и $upstream status
Здравствуйте, YuriV. Вы писали 3 августа 2016 г., 0:08:13: > Доброго времени суток. > Возникла тут задачка кэшировать на nginx ТОЛЬКО 200-е ответы от апстрима, но > при условии, что поддерживаются заголовки кэширования от бэкэнда. Вы хотите странного - придумали какие-то "заголовки кэширования от бэкенда", но смысла их так и не объяснили. В чем в вашем понимании разница между "бэкэнд" и "апстрим"? Кеш - это кеш. Он предназначен для уменьшения количества запросов на бэкенд. Если бэкэнд отдал ответ, то отдавать ответ из кеша уже не имеет смысла. Ответ бэкенда более актуален, чем то, что находится в кеше, так что надо отдать ответ бэкенда, а кеш надо обновить. Не вполне ясно, чего вы пытаетесь достичь. > Сделал вывод в кустомный лог переменной $do_cache - независимо от статуса, > который приходит с апстрима, она всегда равна дефолту мапы... Мапа вычисляется и сохраняется момент первого обращения к переменной. Оно происходит во время обработки директивы proxy_cache_bypass. В это время $upstream_status не равен 200, т.к. обращения к апстриму не происходило. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
Здравствуйте, Steven3009. Вы писали 5 июня 2016 г., 20:20:32: > Если бы я разбирался в кэшировании, то наверное бы сюда не писал, верно? > Плохо, что далеко не все, кто отвечают, сами в нем разбираются... : Извините, но как вы определяете, кто разбрается, а кто нет, если вы сами не разбираетесь? Вам слишком многое _кажется_. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: geoip и прокси
Здравствуйте, Илья.
Вы писали 4 февраля 2016 г., 2:32:16:
> мы пишем вот такую штуку
> map $http_x_forwarded_for $r_ip {
> '' $remote_addr;
> default $http_x_forwarded_for;
> }
В такой конфигурации вы абсолютно доверяете присланному вам (кем угодно)
заголовку X-Forwarded-For. Атакующий может подставить туда любые данные, в т.ч и
не IP. Использовать полученное таким образом в качестве "настоящего IP
пользователя" категорически нельзя.
> чем в данном случае помогает то, что я знаю ip-адрес серверов оперы или
> яндекса ?
Указав список этих адресов, вы можете принимать заголовок X-Forwarded-For
только от них.
Полученному таким образом значению IP пользователя можно доверять в несколько
большей
степени.
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: geoip и прокси
Здравствуйте, Илья. Вы писали 4 февраля 2016 г., 9:38:13: > а не лучше будет отличать оперу и яндекс по useragent? > который мы знаем с большей степенью достоверности, чем адреса этих проксей. Useragent можно подделывать точно так же, как и X-Forwarded-For. Адреса можно подтвердить по AS num, а также можно собрать статистику по отправляемым ими заголовкам с целью подтверждения/детектирования новых "достоверных проксей". Например, опера турбо отправляет заголовок "X-Content-Opt", по которому её можно определять. Однако, я сейчас провел быстрый тест работы опера турбо и получил неожиданный результат. К моему серверу с 82.145.208.146 пришел следующий запрос: GET /?opera HTTP/1.1 Host: my.host.example.com accept-language: ru-RU,ru;q=0.9,en;q=0.8 Accept-Encoding: gzip, deflate accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 user-agent: Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.17 X-Forwarded-For: 141.0.15.155 X-Content-Opt: Turbo/4.29.5717 Указанный в X-Forwarded-For 141.0.15.15 - это совершенно не мой IP. # host 82.145.208.146 146.208.145.82.in-addr.arpa domain name pointer z10-15.opera-mini.net. # host 141.0.15.155 155.15.0.141.in-addr.arpa domain name pointer z09-04-11.opera-mini.net. Так что не всё там гладко, как хотелось бы. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Улучшение ngx_http_limit_req_module
Здравствуйте, Валентин.
>> Перевод в боевой режим может только уменьшить число запросов, поступающих на
>> учет нетестовые зоны, что является ожидаемым поведением в силу более жесткого
>> ограничения во включаемой зоне.
>>
> [..]
> Да, и это влияние на учет запросов в других зонах может сказаться на
> поведении.
> Скажем вот в такой конфигурации:
> location /one {
> limit_req zone=soft; # rate=100r/s
> limit_req zone=hard; # rate=1r/s
> }
> location /two {
> limit_req zone=soft; # rate=100r/s
> }
> Переключение limit_req zone=hard из режима dry-run в основной по вашей
> схеме может привести к тому, что в location /two начнет попадать существенно
> больше запросов.
> Этот эффект может быть нежелателен.
Такой эффект не зависит от схемы, может произойти и в случае, если в "location
/one" будет добавлена директива "limit_req_dry_run on;", и в случае, если
"limit_req zone=hard;" будет просто добавлена, без тестирования вовсе.
> Переключение .. может привести к тому, что в location /two начнет попадать
> существенно больше запросов.
> ... , а dry-run работающий в рамках одной зоны его просто не покажет.
Эффект заключается в том, что ограничение в location /two сможет _пропускать_
существенно больше запросов. Однако возникает вопрос - откуда они возьмутся,
чтобы его смог показать какой-либо из режимов тестирования?
>> Цель добавления зоны test - увидеть, какое количество запросов будет
>> задержано/отклонено, если мы уменьшим rate с 2r/s до 1r/s в зоне one.
> А вот и не получится увидеть. 1r/s в режиме dry-run может отклонить
> существенно меньше запросов, чем в обычном режиме. Произойти это может
> из-за того, что часть запросов, которые могли бы попасть под ограничение
> в zone=test будут отклонены в зонах one и two.
Да, согласен - при наличии отклонений в зонах one и two количество увидеть не
получится. Часть запросов (по одинаковому ключу) в зоне test не будет учтена,
т.к.
сработает ограничение зоны test, а часть не будет учтена, т.к. сработает
ограничение зоны one.
Чтобы подсчитать количество, необходимо добавлять в limit_req_zone параметр
warn_rate, в limit_req - warn_burst, а затем вести подсчеты превышений
ограничений по этим параметрам параллельно основным подсчетам. Такой вариант
когда-либо рассматривался?
Однако я исхожу из предположения, что мы имеем зону one, которая не ограничивает
никого лишнего, и хотим убедится, что изменение её настроек также никого лишнего
ограничивать не будет. Также предполагаем, что со второй зоной two тоже всё в
порядке и она также никого лишнего не ограничивает.
Для этих целей мы заводим зону test с таким же ключем, как и в зоне one.
Т.е. все манипуляции тестирования нацелены на детектирование факта отсутствия
предупреждений от тестовой зоны, в условиях отсутствия предупреждений от боевых
зон.
В этих условиях отсутствия (критически малого числа) отклонений запросов в зонах
one и two предлагаемый мной подход по оценке применимости настроек зоны test
вполне жизнеспособен и весьма актуален.
> Работа ограничений в зонах one и two изменится при выключении dry-run в
> зоне test.
По задумке, в боевой режим будут переводиться _параметры_, а не зона
test - т.е. по результатам теста будет производиться коррекция параметров зоны
one, а зона test будет удалена.
>> Я думаю, что вполне понятно то, что если в контексте есть ограничение с зоной
>> one с rate=2r/s, то добавление ограничения с тестовой зоной test с rate=3r/s
>> не
>> покажет "количества ограничений", но это и не ожидается и не требуется.
> Зависит от критерия, по которому производится ограничение.
Предполагается, что у тестируемой и боевой зоны одинаковый критерий.
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проблема с HTTPS - много сайтов на одном IP
Здравствуйте, alexandre_frolov. Вы писали 2 февраля 2016 г., 16:22:55: > Вообще HTTP сайтов на этом сервере очень много, а HTTPS - только один. И там > еще стоит панель ISPmanager, которая не должна сломаться от сильно > кастомизированного конфига nginx... > Подскажите, пожалуйста, а как сделать редирект на http версию сайта в таком > конфиге? Никак. Чтобы сделать редирект, клиенту должен быть предоставлен корректный сертификат. Выделяйте для не-HTTPS-ных сайтов отдельный IP на котором не будет никакого HTTPS. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Улучшение ngx_http_limit_req_module
Здравствуйте, Валентин.
> Невозможно добавить или убрать ограничение, не повлияв на работу остальных.
В моей схеме можно добавить дополнительное тестовое ограничение, которое не
сможет приводить к отклонению запроса, а значит не повлияет на подсчет запросов
в остальных зонах.
>> В моей схеме можно добавить новую зону в тестовом режиме в дополнение к уже
>> настроенным ограничениям. Не понимаю, как добавление новой тестовой зоны
>> сможет
>> повлиять на уже настроенные ограничения.
> Если директива приводит к отклонению запроса, то он не будет учтен во всех
> зонах. Если мы сделаем режим таким, что при этом запрос будет учтен, но не
> будет отклонен, то это не даст нам возможности оценить работу директивы,
> поскольку всё будет работать несколько не так, как если бы dry-run был
> выключен
> и не позволит оценить реальное влияние директивы на количество пропущенных
> запросов.
Тестовое ограничение не может приводить к отклонению запроса, значит запрос
может быть отклонен только другой, не тестовой директивой.
Если состояние тестируемой зоны показывает необходимость отклонения
запроса этой зоной, то запрос в этой тестовой зоне не учитывается независимо от
того, будет ли отклонен запрос другими зонами или нет. В остальных зонах запрос
учитывается согласно окончательному решению по отклонению или пропуску запроса,
на которое тестируемая зона не влияет.
Если другие, не тестовые директивы, не отклоняют запросы, то их подсчет в
тестовой зоне ведется и будет соответствовать реальной картине потока запросов.
Если другие, не тестовые директивы, отклоняют запросы, а тестовая зона не
отклоняет - значит тестируемая зона имеет менее жесткие ограничения, что
является для нас метрикой допустимости перевода её в боевой режим.
Перевод в боевой режим может только уменьшить число запросов, поступающих на
учет нетестовые зоны, что является ожидаемым поведением в силу более жесткого
ограничения во включаемой зоне.
> Если мы будем действовать также, как без режима dry-run, но только пропускать
> запрос, то это повлияет на работу сервера парадоксальным образом - более
> жесткое ограничение в режиме dry-run будет приводить к пропусканию сервером
> большего количества запросов, чем при его отсутствии.
Другие, не тестовые директивы, могут отклонить запрос.
Я вижу применение например следующим:
limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s; #perip
limit_req_zone $server_name zone=two:10m rate=10r/s;#perserver
limit_req_zone $binary_remote_addr zone=test:10m rate=1r/s dry-run; #test zone
location / {
limit_req zone=test; # rate = 1 r/s, dry run
limit_req zone=one; # rate = 2 r/s
limit_req zone=two; # rate = 100 r/s
}
Цель добавления зоны test - увидеть, какое количество запросов будет
задержано/отклонено, если мы уменьшим rate с 2r/s до 1r/s в зоне one.
Я думаю, что вполне понятно то, что если в контексте есть ограничение с зоной
one с rate=2r/s, то добавление ограничения с тестовой зоной test с rate=3r/s не
покажет "количества ограничений", но это и не ожидается и не требуется.
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Улучшение ngx_http_limit_req_module
Здравствуйте.
> Это не может быть параметром limit_req или limit_req_zone, поскольку
> ограничения не работают по отдельности. Если в location задано несколько
> директив limit_req, то применяется наиболее жесткое ограничение. При этом,
> если в результате запрос отклоняется, то он не учитывается во всех зонах.
> Переключая режим в только для одной конкретной директивы или зоны, вы тем
> самым нарушаете правило наиболее жесткого ограничения.
Именно это и является целью мероприятия - отключить правило наиболее жесткого
ограничения, если это ограничение идет из тестируемой зоны.
> Приведу пример:
> location / {
> limit_req zone=one; # rate = 1 r/s
> limit_req zone=two; # rate = 100 r/s
> }
> Представьте себе, что вы включили тестовый режим для zone=one, что тогда
> будет? Фактически под это ограничения могут попасть и те запросы, что раньше
> попадали под zone=two, но если раньше они были отклонены, то теперь из-за
> режима работы zone=one они окажутся пропущены.
Всё верно, мы отключили ограничение зоны one и запросы должны быть пропущены,
если их не ограничит зона two.
Предлагаемый мной вариант более гибкий в этом аспекте, им можно добиться того
же поведения, что и директивой уровня location - если нужно, то для zone=two
_тоже можно_ включить тестовый режим.
> Если же мы будем просто игнорировать работу zone=one и продолжать учитывать
> запрос в zone=two, то опять же не получим реальной картины.
Реальная картина зависит от того, как мы отвечаем внешнему миру. Если
включив параметр dry-run мы поменяем свое поведение, то абсолютно реальной
картины мы не получим никак, куда бы мы не вынесли параметр dry-run.
Не менять свое поведение как раз и позволяет вынос параметра dry-run на
уровни limit_req / limit_req_zone.
Нам реальная картина и не нужна, нам нужна оценка.
Цель включения режима dry-run - увидеть, не являются ли тестируемые ограничения
более жесткими, чем уже имеющиеся. Поэтому нам достаточно увидеть факт того,
что запросы (не)подпадают под ограничения зоны one. То, что от этого больше
запросов будет учтено в зоне two - ожидаемое явление.
> Т.е. тестировать по отдельности, без влияния на уже настроенные ограничения,
> не получится в любом случае.
В моей схеме можно добавить новую зону в тестовом режиме в дополнение к уже
настроенным ограничениям. Не понимаю, как добавление новой тестовой зоны сможет
повлиять на уже настроенные ограничения.
> Также хочется обратить внимание, что ограничения чаще всего настраиваются к
> конкретному ресурсу, т.е. под конкретный location, а следовательно и
> тестировать имеет смысл в рамках этого блока location.
Если "ограничения чаще всего настраиваются к конкретному ресурсу, т.е. под
конкретный location", то это значит, что зона выделена именно под конкретный
ресурс, а значит вынос ограничения на уровень limit_req_zone подходит для
решения задачи тестового режима.
Однако зона - штука общая, и может применяться и к разным ресурсам/location.
Например, у нас есть куча разных server {} языковых версий одного сайта и мы
знаем, что один реальный пользователь может одновременно находится на только на
одном из них - т.е. применяем одну зону сразу в большом наборе location всех
этих server {}.
Т.к. запросы одного location будут влиять на другие, то в этом случае я не вижу
целесообразности отключения ограничений на уровне одного location, не отключая
их в других. Вынос ограничения на уровень limit_req_zone подходит под эти
требования как нельзя лучше.
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Улучшение ngx_http_limit_req_module
Здравствуйте, Maxim. Вы писали 2 февраля 2016 г., 0:16:37: >> Судя по всему, это должен быть параметр директивы limit_req_zone. Как он >> зовется >> в вашем TODO? > Скорее, отдельная директива, аналогично limit_req_status / > limit_req_log_level. Приведу свою аргументацию, почему это должен быть именно параметр директивы limit_req_zone. Функция "dry-run" необходима для того, чтобы дать возможность протестировать влияние ограничений на реальные запросы. В реальности в одном контексте будет несколько директив limit_req, и отключать применение ограничений необходимо будет только на части из них. Например, у нас могут быть настроенные ограничения, но мы захотим проверить, как будут применяться более жесткие ограничения или вообще будем вводить другой ключ. Вполне естественно, что имеющиеся ограничения мы отключать при этом не захотим. Гибкости, которую может предоставить отдельная директива уровня контеста, для этих целей явно недостаточно. Чтобы решить данную ситуацию, можно, например, добавить параметр в директиву limit_req. Однако, если возникает необходимость тестировать "как оно будет", то это значит, что неправильна настройка rate всей зоны и мы будем стремиться максимально исключать негативные последствия - т.е. будем выключать применение ограничения везде, где используется указанная зона, либо загрублять настройку rate. В общем случае, наиболее вероятным сценарием использования функции я вижу именно создание дополнительной зоны для тестирования, подключение её в нужные контексты (возможно, параллельно ранее сконфигурированным зонам/ограничениям) и собственно тестирование. Возможность задавать dry-run параметром limit_req для этих целей явно избыточна, поэтому я предлагаю вариант добавления параметра в директиву limit_req_zone. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Улучшение ngx_http_limit_req_module
Здравствуйте.
Насколько сообществу интересна реализация улучшения модуля
ngx_http_limit_req_module, а в частности
расширения синтаксиса директивы limit_req?
Предлагаемый синтаксис:
(1) limit_req zone=название [burst=число] [nodelay] [if=условие] [last];
(2) limit_req off if=условие;
(3) limit_req off;
(4) limit_req last if=условие;
Предлагаемая логика работы:
Синтаксис (1):
Базовый синтаксис дополняется возможностью указания условия if=условие и
параметром last.
Если заданное условие не выполняется, то ключ зоны не вычисляется, директива
пропускается, учет
запроса не происходит. Выполняются остальные директивы limit_req, при их
наличии.
Если заданное условие выполняется или условие не задано, применяются
ограничения зоны обычным
образом. При этом вычисляется ключ зоны, если значение ключа не пустое и указан
параметр last -
остальные директивы limit_req не выполняются.
Синтаксис (2):
Возможность отключения ограничения по заданному в переменной условию.
Директива такого синтаксиса может быть только первой в списке директив
limit_req.
Синтаксис (3):
Возможность безусловного отключения ограничений, наследованных с предыдущего
уровня.
Все директивы, заданные на этом или предыдущем уровне - отключаются.
Синтаксис (4)
Возможность прекратить обработку директив limit_req по заданному в
переменной условию, с
применением ограничений уже обработанных директив.
Отличие от синтаксиса (2): может быть в любом месте в списке директив
limit_req, соответственно
директивы выше по списку директив должны быть обработаны корректно, в остальном
является практически точной копией синтаксиса (2) ("синтаксический сахар").
Для данного улучшения уже почти готов патч (за вычетом синтаксиса 4). Также
можно сделать
аналогичную доработку модуля ngx_http_limit_conn_module.
Из планируемых вещей также есть мысли по поводу добавления параметра "dry-run".
Предлагаю обсудить целесообразность/заинтересованность сообщества в подобного
рода доработках.
Пример использования предлагаемого синтаксиса:
server {
...
limit_req_zone $binary_remote_addr zone=user:10m rate=200r/s;
limit_req_zone $binary_remote_addr zone=spider:10m rate=20r/s;
location / {
limit_req off if=$verytrusted; #last
applied too
limit_req zone=apiburst=2 if=$is_api_host last;
limit_req zone=spider burst=20 if=$is_spider_host$is_spider_re last nodelay;
limit_req zone=user;
}
location /static {
limit_req off;
}
...
};
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Улучшение ngx_http_limit_req_module
Здравствуйте, Максим. > Эта логика предполагает последовательное применение ограничений. > Меж тем, логика работы nginx'а предполагает декларативную > конфигурацию, с отсутствием зависимости от порядка. Не надо > тащить в nginx очередную императивную логику, хватит с нас > rewrite-модуля. Понятно, переосмыслил концепцию с учетом этого замечания. Тогда, конечно, предлагаемый мной параметр last и "условный off" в принципе недопустимы. > Сделать явный отдельный параметр if - можно, но сколько-нибудь > принципиальной разницы нет. В то же время не факт, что мы хотим > тут усложнять синтаксис. Если условия везде одинаковые, то они задаются map-ом, пусть и чуть более громоздким конфигом, чем с параметром if. Принципиальная разница появляется только в том, что в разные директивы limit_req в параметр if можно задать разные условия. В директиве access_log такой синтаксис есть и мне кажется, что это весьма удобное решение. Хотелось бы понять, насколько оно востребованно применительно к limit_req. > Если хочется программировать - стоит подумать о том, чтобы > вытащить результаты ограничений в переменные, и дальше > программировать с помощью директив rewrite-модуля же. Можно увидеть пример конфигурации, как она могла бы быть заданной таким способом? Например, для двух условий: $is_spider и $is_vip. Если $is_vip - ограничений вообще нет, если $is_spider - одна зона (ограничения), иначе вторая (другие ограничения)? >>Возможность безусловного отключения ограничений, наследованных с >> предыдущего уровня. > Это уже записано в TODO, возможность отказаться от унаследованных > ограничений, безусловно, нужна. >> Из планируемых вещей также есть мысли по поводу добавления параметра >> "dry-run". > Да, сделать возможность проверки ограничений без их реального > применения - тоже уже в TODO. Судя по всему, это должен быть параметр директивы limit_req_zone. Как он зовется в вашем TODO? "Patches are welcome"? По этим двум пунктам они достаточно тривиальны. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: $realip_remote_addr выдает айпи прокси а не клиента
Здравствуйте, Андрей. Вы писали 24 января 2016 г., 4:45:36: > В конфиге прописано: > real_ip_header X-Forwarded-For; > real_ip_recursive on; > set_real_ip_from 94.23.0.0/16; > proxy_set_header X-Real-IP$realip_remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > На бэкнде получаю в X_REAL_IP айпи прокси а не клиента: > [HTTP_X_REAL_IP] => 94.23.156.246 > [HTTP_X_FORWARDED_FOR] => 176.104.49.220, 94.23.156.246 > [REMOTE_ADDR] => 94.23.156.246 > Кто виноват и что делать? Всё работает так, как вы указали в конфигурации. Цитирую http://nginx.org/ru/docs/http/ngx_http_realip_module.html : $realip_remote_addr - хранит исходный адрес клиента (1.9.7) В данном случае клиентом является то, что соединилось с nginx, т.е. прокси. Вам следует использовать переменную $remote_addr: proxy_set_header X-Real-IP $remote_addr; Возможно также, что директива "proxy_set_header X-Forwarded-For " совсем не нужна, чаще всего это наследие копипаста. Для получения IP реального клиента достаточно X-Real-IP. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: проксирование стилей
Причём тут локейшн москва? по линку http://megasait.org/moskva/ контент загружается с example.org, стили загружаются с megasait.org а надо с example.org что я делаю не так? Вы не смотрите на конфиг целиком. Вероятно у вас есть другие location, кроме приведенных двух. Прочитайте документацию: http://nginx.org/ru/docs/http/ngx_http_core_module.html#location Обратите внимание на Если у совпавшего префиксного location’а максимальной длины указан модификатор “^~”, то регулярные выражения не проверяются. Теперь еще раз вдумчиво перечитайте описание этой директивы (location). -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx phpmyadmin auth_basic
Здравствуйте, bagas.
Добрый день.
Подскажите пожалуйста, почему если идти по ссылке site.ru/pma/ то
авторизация работает, а вот если идти по ссылке site.ru/pma/index.php то
авторизации нет?
Потому что первый запрос попадает в location /pma где есть авторизация, а
второй попадает в
location ~ ^/pma/(.*\.php)$ где таковой нет.
Используйте вложенные локейшны, это удобнее.
Либо добавьте директивы auth* во второй ваш локейшн.
Вложенные локейшны - это примерно так:
location ^~ /pma/ {
alias /usr/local/www/phpMyAdmin/;
index index.php;
auth_basic closed site;
auth_basic_user_file /usr/local/htpasswd;
location ~ \.php$ {
fastcgi_pass unix:/tmp/rey1.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
}
}
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx phpmyadmin auth_basic
Здравствуйте, bagas. Вы писали 16 июля 2015 г., 17:13:04: Задумался, а не повлияетли такое на безопасность сервера, если несколько локейшенов будут содержать обработку php? Несколько локейшнов и безопасность сервера - связаны почти никак. К примеру я хочу ограничить доступ к пма и админке, я создам в одном конфиге виртуал хсота как бы 3 точки обработки php. С одного виртхоста можно посылать запросы на обработку в php и в разные пулы php-fpm на одной машине и на разные сервера с независимыми php-fpm. Это нормально. Безопасность определяется совсем другими вещами. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Большой POST запрос и мгновенный редирект
Здравствуйте, Михаил. Вы писали 31 марта 2015 г., 3:02:52: Здравствуйте, Viacheslav. Вопрос следующий: есть клиентское приложение (сайт), которое отсылает большие (~50MB) посты мультипартом. Хочется на некоторые отсылать редирект: 302 или 307 √ не имеет значения. Но сразу, а не зачитывая/буферезируя реквест боди на прокси. Можно? Как должны определяться эти самые некоторые ? Могу ошибаться, но по протоколу http 1 ответ отправляется после получения всего запроса. Т.е. нельзя. А 413 (Request Entity Too Large) когда отправляется? Тоже после получения всего запроса? -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [security advisory] http://wiki.nginx.org/Redmine
Здравствуйте, Дмитрий.
вообще-то root должен смотреть в папку public, в вашем случае
/var/www/redmine/public/
Я предполагаю, что человек, который нашел указанные проблемы, не нуждается в
том, чтобы ему
подсказывали, куда должна указывать директива root.
Как вы и сказали, root должен указывать в public/, но в примере, который
изначально был на странице,
он указывает не в public/, а на уровень выше. Т.е. должен, но не указывает.
При этом конфиг остается работоспособным - если try_files $uri не нашло нужный
файл напрямую,
запрос проксируется на бэкенд и на запрос будет выдан ожидаемый результат.
Проблема возникает в тот момент, когда try_files $uri _срабатывает_ на
специально сформированный
запрос, в результате которого возможна утечка приватных данных.
Конфиг, который был на странице до исправлений:
server {
server_name redmine.DOMAIN.TLD;
root /var/www/redmine;
location / {
try_files $uri @ruby;
}
location @ruby {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_read_timeout 300;
proxy_pass http://redmine;
}
}
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Странности с try_files
Здравствуйте, greenh. Вы писали 6 декабря 2014 г., 19:21:40: Похоже проблема в пробельных символах На диске создается путь вида images/torrents%20films, а ищется images/torrents films. И как с этим бороться? Приведите ссылки в соответствие с именами файлов и каталогов на диске, не забывая про экранирование. https://ru.wikipedia.org/wiki/URL#.D0.9A.D0.BE.D0.B4.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_URL -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Странности с try_files
Здравствуйте, greenh. Вы писали 6 декабря 2014 г., 19:54:00: К сожалению изменить ссылки не возможно. Похоже решением будет в proxy_store прописать не $request, а urldecode от request, вот только как это сделать? 1) try_files $uri 2) proxy_store /home/site.com/img.site.com/$request_uri; Ищете файлы по $uri, пишете файлы по $request_uri. Где логика? В примере в документации http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store еще есть отсылка к переменной $original_uri. Успехов. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Странности с try_files
Здравствуйте, greenh. Вы писали 7 декабря 2014 г., 0:37:13: 6 декабря 2014 г., 20:17 пользователь Pavel V. pavel2...@ngs.ru написал: Здравствуйте, greenh. Вы писали 6 декабря 2014 г., 19:54:00: К сожалению изменить ссылки не возможно. Похоже решением будет в proxy_store прописать не $request, а urldecode от request, вот только как это сделать? 1) try_files $uri 2) proxy_store /home/site.com/img.site.com/$request_uri; Ищете файлы по $uri, пишете файлы по $request_uri. Где логика? Спасибо, логично. Хотя, при отсутствии переменных в get запросе и редиректов они будут идентичны. Предполагаю, что в случае наличия в запросе символов, подлежащих экранированию, они будут различны. Можно залогировать эти переменные и посмотреть: http://nginx.org/ru/docs/http/ngx_http_log_module.html#access_log http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_format -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Необходимо исправление в документации
Здравствуйте, Nginx-ru. Просьба исправить в документации http://nginx.org/ru/docs/http/ngx_http_core_module.html#location абзац: Если location задан префиксной строкой со слэшом в конце и запросы обрабатываются при помощи proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass или memcached_pass, а в ответ на запрос с URI равным этой строке, но без завершающего слэша, будет возвращено постоянное перенаправление с кодом 301 на URI с добавленным в конец слэшом. Если такое поведение нежелательно, можно задать точное совпадение URI и location, например: видимо, необходимо убрать а в ..., а в ответ... ну и пунктуацию подправить. Спасибо. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Несколько expire
Здравствуйте, Edrard. Вы писали 16 июля 2014 г., 20:39:10: Здравствуйте. Нужна ваша помощь. Необходимо выставить для одной папки /images expire равный 30d, а для всей остальной статистики 1d Пожалуйста, прочитайте документацию. Она написана по-русски и достаточно внятно. http://nginx.org/ru/docs/http/ngx_http_core_module.html#location Цитирую: Чтобы найти location, соответствующий запросу, вначале проверяются location’ы, заданные префиксными строками (префиксные location’ы). Среди них ищется location с совпадающим префиксом максимальной длины и запоминается. Затем проверяются регулярные выражения, в порядке их следования в конфигурационном файле. Если у совпавшего префиксного location’а максимальной длины указан модификатор “^~”, то регулярные выражения не проверяются. У вас модификатор не указан. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx возвращает 499 при проксировании после нескольких часов работы
Здравствуйте, Andruxa. Вы писали 1 июля 2014 г., 20:16:15: Виталий, спасибо за информацию! Попробуем настроить и понаблюдать. Сейчас только обнаружил, что ошибся и возможно ввел заблуждение насчет счетчиков. Посмотрел показатели не на том адаптере (взял показатели для management адаптера). Вот такие показатели на основном RX packets:612896756 errors:0 dropped:2060993 overruns:0 frame:0 TX packets:631594750 errors:0 dropped:0 overruns:0 carrier:0 Тут соотношение dropped/total значительно ниже. Какое соотношение можно считать допустимым? dropped/total = 0. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: аутентификация по клиентскому сертификату SSL
Здравствуйте, Phil. Вы писали 21 марта 2014 г., 14:23:51: Собственно вопрос не новый, но вдруг что-то изменилось. 1. Есть ли какой-то способ клиенту, который не предоставил сертификат вдруг его подставить и аутентифицироваться им? Что значит вдруг? Вы про HTTP говорите? 2. Возможно ли насильно сбросить соединение с клиентом? Это решало бы не только эту проблему. Грубовато, но часто действенно. http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return код 444 -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx proxy аутентификация
Здравствуйте, komiller. Вы писали 24 февраля 2014 г., 18:55:52: Здравствуйте. Прошу помочь, не давно перешел на нгинх и все бы прекрасно да только проблемка одна. Nginx я использую для балансировки нагрузки между двумя серверами, при входе в сайт есть авторизация и соответсвенно каптча, так вот каптча все время ругается что код не правильный хотя все правильно. Ознакомьтесь с http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#ip_hash -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Авторизация
Здравствуйте, Daniel. Вы писали 24 января 2014 г., 1:41:19: 2014/1/23 Pavel V. pavel2...@ngs.ru: Кто-нибудь может кинуть ссылку на более наглядные объяснения с более человекопонятной схемой, как это ломается? Либо может быть кто-то разъяснит на пальцах, как злоумышленник, имея одну или несколько пар userId + keyedhash сможет сгенерировать пару admin_userId + valid_keyedhash? Полным перебором это ломается. Просто процессоры стали сильно быстрые и многоядерные. SHA1 считается слишком быстро. Почему тогда нет проблемы если использовать HMAC-SHA1 ? Из-за того, что считается sha1 от вычисленного в sha1, что дает сброс внутреннего состояния хеширующей функции? -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отображаются картинки после ресайзинга
Здравствуйте, Miklucho. Вы писали 24 января 2014 г., 14:12:49: Мне кажется, что проблема в том, что php сравнительно медленно ресайзит изображения и из-за этого срабатывают какие-то таймауты, либо в apache, либо в nginx. Не подскажет ли кто куда мне копать? 1) Смотрите в логи 2) Смотрите в ответы сервера например в firebug (в Firefox). -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Адрес отправителя при проксировании
Здравствуйте, misha_shar53. Вы писали 25 января 2014 г., 11:13:29: Есть ли возможность установить Адрес отправителя. Если NGINX используется в качестве прокси сервера? http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
Здравствуйте, Vladimir. Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов. От них сделать каналы до серверов (с каждой впски через каждый из аплинков) Вы имеете в виду VPN ? Как один из вариантов - да. Хотя можно обойтись и прямым проксированием. В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал выбирался нужным образом. если BGP можно реализовать стандартными спсобами linux то я рассмотрю этот вариант. можно. На эти же впски можно выкинуть некий статический контент... Для этих же впсок можно прислюнявить DNS с ненулевым TTL, чтобы исключать впски из схемы в случае их падения.. Я уже если честно запутался во все возможных вариантах. Можете пояснить куда его прислюнявить и зачем ? Зачем еще DNS сервер(ы) не пониманию если честно. Вы не внимательно читаете. Я уже написал, зачем. Попробуйте прочитать снова. Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и необходимость!) этими наворотами заниматься. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
Здравствуйте, Васильев. Вы писали 14 января 2014 г., 19:24:12: Вклинюсь в тред. Если вам нужно организовать надёжность связи с вашими серверами, у которых два аплинка, то да, вам просто нужна ВПС-ка фронтенд. Если вы хотите общую отказоустойчивость, то у вас появляется новая единая точка отказа - внешняя ВПС-ка. Тоже, пожалуй, вклинюсь в тред. Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов. От них сделать каналы до серверов (с каждой впски через каждый из аплинков) В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал выбирался нужным образом. На эти же впски можно выкинуть некий статический контент... Для этих же впсок можно прислюнявить DNS с ненулевым TTL, чтобы исключать впски из схемы в случае их падения.. Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и необходимость!) этими наворотами заниматься. 14.01.2014, 13:58, Vladimir Skubriev vladi...@skubriev.ru: 14.01.2014 13:46, Артем Васильев пишет: При сильном желании сервить свой крутой и ценный проект на локалхосте - покупается AS, ставится роутер, который может, любит, и умеет в bgp, подключается 2-3 провайдера по оптике c нормальным sla. В противном случае можно продолжать есть кактус с подобными вопросами и запросами, либо выбрать более-менее нормальный хостинг/vps (их есть в россии, и немало, даже для параноиков с особо ценными разработками) В вашем предложении для меня сильно много не знакомых слов. Поэтому циски, bgp и провайдеры со sla идут лесом. Это слишком круто. В таком случае Вы за frontend nginx на vps вместо update dns via api and small ttl? -- -- Faithfully yours, Vladimir Skubriev , ___ 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 -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как в nginx получить html код запрашиваемой страницы ?
Здравствуйте, Neutrino_9. Вы писали 13 октября 2013 г., 0:59:33: А что это за модуль который умеет читать ответ от бекенда, можно пример или имя модуля ? Уж прочитать официальную документацию Вы могли бы. Я не вижу смысла для Вас в чьих либо ответах, т.к. вы не умеете (их) читать. В Ваши успехи я больше не верю. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http 500
Здравствуйте, Васильев. Вы писали 15 сентября 2013 г., 6:12:21: Hello everybody! Попиливаю маленький статический сайтик. После сохранения файла первый его запрос возвращает HTTP 500. Второй возвращает обновлённую страницу. Почему так? Надо смотреть логи. Возможно, также потребуется повысить уровень детализации сообщений. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx и url секция в адресной строке
Здравствуйте, bono90. Вы писали 30 мая 2013 г., 15:02:20: Добрый день! Настроил nginx в качестве обратного прокси для доступа к сервису owa (exchange server). Когда набираю в браузере адрес домена, настроенный для использования owa, например: imap.domain.ru - запрос перенаправляется на https://imap.domain.ru/owa/auth/logon.aspx?replaceCurrent=1url=https://exchange-server.domain.local/owa/. Собственно вопрос как добиться того, чтобы секция URL не присутствовала в адресе (url= https://exchange-server.domain.local/owa/). Перенастройте сервис так, чтобы он именовался не exchange-server.domain.local, а imap.domain.ru. Проброс сделайте так: proxy_pass https://192.168.3.4; proxy_set_header Host 'imap.domain.ru'; -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Доступ по ip ИЛИ через клиентский сертификат - возможно ли?
Здравствуйте, itonohito.
Вы писали 15 мая 2013 г., 16:46:22:
Добрый день!
Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к
сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip?
Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с
любого ip, а кроме того - с некоторых ip доступ был для всех и без
сертификата тоже.
Здравствуйте.
Вы можете сконфигурировать отдельный server {} на отдельном порту, разрешающий
доступ по IP без
требования сертификата, и завернуть трафик с некоторых IP на этот порт,
например через
iptables -t nat -I PREROUTING -s 1.2.3.4/25 -d 8.8.7.7 -p tcp --dport 443 -j
DNAT --to-destination=8.8.7.7:444
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Слив трафика
Здравствуйте, gvozd. Вы писали 14 апреля 2013 г., 10:57:41: Здравствуйте! Помогите решить проблему, происходит очень большой слив исходящего трафика, tcpdump'ом удалось выяснить, что nginx получает запрос: HTTP/1.1 302 OK Connection: Keep-Alive Location: http://affiliationpartner.it/tutorial/adesionecampagne.mov?COLLCC=1830002745COLLCC=3039517559; htmlredirect.../html Это не HTTP-запрос, это HTTP-ответ. После чего происходит загрузка этого файла и накрутка трафика. Я так понимаю, что указанный файл отдается не с вашего сервера, соответственно накрутки нет. Разберитесь сами в том, как работает HTTP, либо наймите компетентного специалиста. Из вами вышенаписанного проблемы не видно ни в настройках Nginx, ни в самой описанной ситуации. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 500 read timeout
Здравствуйте, nurdus. Не давно установил nginx и начались проблемы, знаю что из-за кривизны рук, а точнее отсутствие опыта. На сайте вызывается скрипт который может выполняться до 5 минут. Скрипт вызывается через cron, если вызывает через адресную строку в браузере всё отрабатывается нормально. 1) Вот и вызывайте его через крон, напрямую через php интерпретатор, а не через веб-сервера. Наши программисты переучились, переучили скрипты, теперь все счастливы. 2) Вы так и не сказали, что за проблемы начались. Проверьте еще раз, сколько выполняется ваш скрипт. -- С уважением, Pavel mailto:pavel2...@ngs.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Исключение для списка файлов
Здравствуйте, Andrey.
Вы писали 26 февраля 2013 г., 21:59:48:
Здравствуйте, Уважаемый(-ая, -ое) Алексей Бобок!
АБ Приветствую.
АБ Есть средней нагруженности видеосторадж (700мбит/сек)
АБ На нем есть порядка 150 mp4/flv видео, для которых нужно включить
АБ огранчение по гео.
АБ К сожалению, эти файлы можно только перечислить списком типа:
АБ /www/a.video/users/123456/u123456__.mp4
АБ /www/a.video/users/654321/u654321__.flv
АБ Какие будут рекомендации, чтобы решить эту задачу максимально дешево
АБ по ресурсам?
Как уже было сказано, строите карту (map) своих файлов и перекидываете клиента
по результатам.
Для больших, редко изменяющихся списков карты - самый быстрый и дешевый
способ.
А нагенерировать скриптом 150 location = /file/uri/u123_555.ext {} - не лучше?
If-а, опять же, не будет.
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
