Re: geo2nginx.pl

2016-02-02 Пенетрантность Ekaterina Kukushkina 
Здравствуйте, Михаил. 

Боже, это скрипт 10-ти летней давности, для того, чтобы впихнуть MaxMind 
в geo модуль.

Давно уже есть geoip модуль, который и надо использовать для таких целей
http://nginx.org/en/docs/http/ngx_http_geoip_module.html

Он полностью совместим с Legacy форматом MaxMind.

> On 02 Feb 2016, at 22:03, Михаил Монашёв  wrote:
> 
> Не встречали, а он есть! :-)
> https://trac.nginx.org/nginx/browser/nginx/contrib/geo2nginx.pl
> 

--
Ekaterina Kukushkina
NGINX, Inc.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: добавить uri к проскипасу

2016-02-02 Пенетрантность Paul Sin 
Вы не поверите, но:
*proxy_pass  http://$backend$uri?$args*

29 января 2016 г., 19:35 пользователь Михаил Монашёв <
postmas...@softsearch.ru> написал:

> Здравствуйте, erosio.
>
> > как можно добавить uri условно '/newpage' к proxy_pass http://$backend;
> ?
> > backend задан через set и если туда сразу uri пихать то работать
> > отказывается.
> > пробовал rewrite но тоже безуспешно
>
> debug log включите и станет понятно, как оно там внутри работает и
> почему не работает.
>
> А добавить вроде можно так:
>  proxy_pass http://$backend/newpage;
>
> --
> С уважением,
>  Михаил  mailto:postmas...@softsearch.ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 

best reguards
Paul  Sin
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: geo2nginx.pl

2016-02-02 Пенетрантность Paul S. 
Дистрибутив чего именно? не встречал такого скрипта.

1 февраля 2016 г., 22:06 пользователь Михаил Монашёв <
postmas...@softsearch.ru> написал:

> Здравствуйте.
>
> В составе дистрибутива идёт реально не работающий скрипт. Формат базы
> MaxMind-а поменялся.
>
> --
> С уважением,
>  Михаил  mailto:postmas...@softsearch.ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 

best reguards
Paul S. 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: geoip и прокси

2016-02-02 Пенетрантность Илья Шипицин 
а в чем полезность того факта, что мы можем определить, что запрос пришел
через Яндекс или Оперу турбо?



30 января 2016 г., 17:19 пользователь Oleg Motienko 
написал:

> в нашем случае, фидбэк от клиентов и после анализ логов
>
> On Tue, Jan 26, 2016 at 1:45 PM, Илья Шипицин 
> wrote:
>
>> какой-то алгоритм получения этого списка ?
>>
>> 2016-01-26 15:10 GMT+05:00 Oleg Motienko :
>>
>>> есть еще такой список прокси:
>>>
>>> # Yandex
>>> set_real_ip_from  5.45.192.0/24;
>>> set_real_ip_from  141.8.189.0/24;
>>> set_real_ip_from  5.45.255.0/24;
>>> set_real_ip_from  84.201.143.0/24;
>>>
>>> # Opera Turbo proxies
>>> # as39832   http://as.robtex.com/as39832.html#bgp
>>> set_real_ip_from 37.228.104.0/21;
>>> set_real_ip_from 82.145.208.0/20;
>>> set_real_ip_from 91.203.96.0/22;
>>> set_real_ip_from 141.0.8.0/21;
>>> set_real_ip_from 185.26.180.0/22;
>>> set_real_ip_from 195.189.142.0/23;
>>> # AS21837
>>> set_real_ip_from 107.167.96.0/19;
>>> # other opera
>>> set_real_ip_from 94.246.126.0/23;
>>> set_real_ip_from 64.255.180.0/24;
>>> set_real_ip_from 64.255.164.0/24;
>>> set_real_ip_from 80.239.242.0/23;
>>> set_real_ip_from 80.232.117.0/24;
>>> set_real_ip_from 217.212.230.0/23;
>>> #opera china
>>> set_real_ip_from 58.67.157.0/24;
>>> set_real_ip_from 59.151.106.240/28;
>>> #opera end
>>>
>>> #google proxy
>>> set_real_ip_from 66.249.80.0/22;
>>> set_real_ip_from 66.249.84.0/23;
>>> set_real_ip_from 66.249.88.0/22;
>>> set_real_ip_from 66.249.92.0/23;
>>> set_real_ip_from 66.102.9.0/24;
>>> #google proxy end
>>>
>>> real_ip_header   X-Forwarded-For;
>>>
>>>
>>> ___
>>> 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: geoip и прокси

2016-02-02 Пенетрантность Михаил Монашёв 
Здравствуйте, Илья.

> а в чем полезность того факта, что мы можем определить, что запрос
> пришел через Яндекс или Оперу турбо?

Узнаем настоящее ip юзера.

-- 
С уважением,
 Михаил  mailto:postmas...@softsearch.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: geo2nginx.pl

2016-02-02 Пенетрантность Михаил Монашёв 
Здравствуйте, Михаил.

Прошу прощения, база в старом формате лежит тут: 
http://dev.maxmind.com/geoip/legacy/geolite/#Downloads

Не знаю, на сколько она свежая, правда.

> В составе дистрибутива идёт реально не работающий скрипт. Формат базы
> MaxMind-а поменялся.




-- 
С уважением,
 Михаил  mailto:postmas...@softsearch.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Улучшение ngx_http_limit_req_module

2016-02-02 Пенетрантность Валентин Бартенев 
On Wednesday 03 February 2016 00:31:21 Pavel V. wrote:
> Здравствуйте, Валентин.
> 
> >> Перевод в боевой режим может только уменьшить число запросов, поступающих 
> >> на
> >> учет нетестовые зоны, что является ожидаемым поведением в силу более 
> >> жесткого
> >> ограничения во включаемой зоне.
> >> 
> > [..]
> 
> > Да, и это влияние на учет запросов в других зонах может сказаться на
> > поведении.
> 
> > Скажем вот в такой конфигурации:
> 
> >   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 не
> >> покажет "количества ограничений", но это и не ожидается и не требуется.
> 
> > Зависит от критерия, по которому производится ограничение.
> 
> Предполагается, что у тестируемой и боевой зоны одинаковый критерий.
> 

Да идея то вполне понятна, тут вопрос в том, а оправдывает ли цель такие
сложности и будет ли этим кто-то пользоваться, кроме пары человек.

Замечу еще что поведение клиентов может меняться в зависимости от ограничений
и задержки, так что тестирование в этом случае опять же не поможет предсказать
результаты.

Хочется следующего:

 1. Чтобы легко включалось в типичном случае, когда хочется протестировать
ограничения в конкретном location к конкретному ресурсу;

 2. Реализация была простой, не усложняла алгоритмику модуля.

Шанс быть принятым у простого патча гораздо выше.

Предлагаю начать с limit_req off.  По опыту, есть высокая вероятность, что
на этом энтузиазм и закончится.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Улучшение ngx_http_limit_req_module

2016-02-02 Пенетрантность Pavel V. 
Здравствуйте, Валентин.

>> Перевод в боевой режим может только уменьшить число запросов, поступающих на
>> учет нетестовые зоны, что является ожидаемым поведением в силу более жесткого
>> ограничения во включаемой зоне.
>> 
> [..]

> Да, и это влияние на учет запросов в других зонах может сказаться на
> поведении.

> Скажем вот в такой конфигурации:

>   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: server name и динамические поддомены

2016-02-02 Пенетрантность tetramin 
Вообще, возможно ли то, что я хочу, сделать в одной секции server?

> На всякий случай прилагаю полный конфиг.
> Фронтенд: http://pastebin.com/0v1vWSTK
> Бэкенд: http://pastebin.com/FJqGjLnS

> Также, на всякий случай, выкладываю лог: http://pastebin.com/khJJWaEL

> При таких настройках адрес в адресной строке браузера заменяется на
www.example.ru и идёт бесконечный редирект на этот адрес, о чём в итоге
сообщает браузер.

> Откуда берётся этот www? В скриптах сайта нет и не было такого никогда.

> Да, я читал про то, как nginx обрабатывает запросы и об именах сервера...
Но не могу врубиться, что же я делаю не так. Ведь мне кажется, что именно
так у меня и настроено, как там написано...

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264185,264300#msg-264300

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Ограничение скорости отдачи статики клиентам

2016-02-02 Пенетрантность Иван Мишин 
>
> Нельзя ограничить по полосе. Используйте для этого другие инструменты.

Алексей, сможете порекомендовать что-то?

2 февраля 2016 г., 8:02 пользователь Алексей Сундуков <
public-m...@alekciy.ru> написал:

> Нельзя ограничить по полосе. Используйте для этого другие инструменты.
>
> 1 февраля 2016 г., 12:57 пользователь Иван Мишин 
> написал:
>
>> Добрый день коллеги.
>> Подскажите пожалуйста есть ли возможность в nginx реализовать ограничение
>> скорость каким либо способом отличным от ограничения скорости на соединение
>> (ведь клиент может создать много соединений и получит нужную ему скорость),
>> есть варианты?
>> Например ограничение скорости по полосе, можно ли реализовать ?
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность Alex Vorona 

02.02.16 13:26, alexandre_frolov пишет:
[..]

Т.е. правильно ли я понял, что выделение второго IP - абсолютная
необходимость?
Да, все сайты без https на одном IP, все сайты с http и работающим 
https+SNI на втором IP.


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Помогите друзья!!Ubuntu 14-04 ngnix php-fpm

2016-02-02 Пенетрантность Aleksandr Sytar 
2 февраля 2016 г., 15:18 пользователь Alex Domoradov 
написал:

> > Вот может еще у когото будет такая же проблемма!Удачи всем
> за такое надо бить по рукам, сразу. Особенно, если на продакшене
>

Зря вы так, до пятницы еще далеко, авось и починить успеет


>
> 2016-02-02 13:56 GMT+02:00 Konstantin Tokarev :
>
>>
>>
>> 02.02.2016, 13:18, "Alex_Cardo" :
>> > Пропал файлик /var/run/php5-fpm.sock. Как его востановить?
>>
>> Советую на досуге разобраться, что такое Unix Domain Socket и чем он
>> отличается от обычного файла.
>>
>> >
>> > вот мои конфиг php
>> >
>> >  access_log /var/log/nginx/access.log;
>> >error_log /var/log/nginx/error.log;
>> >location ~ \.php$ {
>> > root /var/www/AS_BTI/PHP;
>> > try_files $uri =404;
>> > include fastcgi_params;
>> > fastcgi_split_path_info ^(.+?\.php)(/.*)$;
>> > fastcgi_pass unix:/var/run/php5-fpm.sock;
>> > fastcgi_index index.php;
>> > fastcgi_param SCRIPT_FILENAME
>> > /var/www/AS_BTI/PHP$fastcgi_script_name;
>> >
>> >}
>> >
>> > /var/run/? cдесь он всегда был ,все работало отлично.к обработке php
>> > кода вообще небыло замечаний.А потом я взял и перегрузи компьютер и вот
>> > ошибка сразу error log мой *1 connect() to unix:/var/run/php5-fpm.sock
>> > failed (2: No such file or directory) while connecting to upstream,
>> client:
>> > 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream:
>> > "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost"
>> >
>> > Помогите кто чем может!!спасибо друзья!!
>> >
>> > Posted at Nginx Forum:
>> https://forum.nginx.org/read.php?21,264258,264258#msg-264258
>> >
>> > ___
>> > nginx-ru mailing list
>> > nginx-ru@nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> --
>> 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: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность alexandre_frolov 
Большое спасибо, буду добавлять IP на сервер.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264248,264284#msg-264284

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность Илья Шипицин 
можете получить сертификат на Let's Encrypt с многими значениями в AltDN
(чтобы покрыть все свои домены).
сертификаты бесплатные, но их не любит WinXP (из-за апострофа в имени
удостоверяющего центра)

или можете настроить терминацию на CloudFlare (там есть ssl из коробки),
опять же - на бесплатных тарифах не будет работать с WinXP (из-за SNI)

2 февраля 2016 г., 16:26 пользователь alexandre_frolov <
nginx-fo...@forum.nginx.org> написал:

> Вообще на сайте ssl.domain.ru валидный сертификат, но он ведь не подойдет
> для редиректов с других доменов?
> Т.е. правильно ли я понял, что выделение второго IP - абсолютная
> необходимость?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,264248,264268#msg-264268
>
> ___
> 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 - много сайтов на одном IP

2016-02-02 Пенетрантность kron 
По мне, так лучше завести отдельную server секцию с поддержкой https для
доменов, которые не должны работать по https и сделать там редирект на http
версию сайта

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264248,264257#msg-264257

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Помогите друзья!!Ubuntu 14-04 ngnix php-fpm

2016-02-02 Пенетрантность Alex_Cardo 
Пропал файлик /var/run/php5-fpm.sock. Как его востановить?

вот мои конфиг php 

 access_log /var/log/nginx/access.log;
   error_log /var/log/nginx/error.log;
   location ~ \.php$ {
root /var/www/AS_BTI/PHP;
try_files $uri =404;
include fastcgi_params;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
/var/www/AS_BTI/PHP$fastcgi_script_name;

   }

/var/run/?  cдесь он всегда был ,все работало отлично.к обработке php
кода вообще небыло замечаний.А потом я взял и перегрузи компьютер и вот
ошибка сразу   error log мой *1 connect() to unix:/var/run/php5-fpm.sock
failed (2: No such file or directory) while connecting to upstream, client:
127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream:
"fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost"

Помогите кто чем может!!спасибо друзья!!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264258,264258#msg-264258

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность Pavel V. 
Здравствуйте, 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: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность alexandre_frolov 
Вообще HTTP сайтов на этом сервере очень много, а HTTPS - только один. И там
еще стоит панель ISPmanager, которая не должна сломаться от сильно
кастомизированного конфига nginx...

Подскажите, пожалуйста, а как сделать редирект на http версию сайта в таком
конфиге?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264248,264259#msg-264259

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Улучшение ngx_http_limit_req_module

2016-02-02 Пенетрантность Валентин Бартенев 
On Tuesday 02 February 2016 22:08:37 Pavel V. wrote:
> Здравствуйте, Валентин.
> 
> > Невозможно добавить или убрать ограничение, не повлияв на работу остальных.
> 
> В моей схеме можно добавить дополнительное тестовое ограничение, которое не
> сможет приводить к отклонению запроса, а значит не повлияет на подсчет 
> запросов
> в остальных зонах.
> 
> >> В моей схеме можно добавить новую зону в тестовом режиме в дополнение к уже
> >> настроенным ограничениям. Не понимаю, как добавление новой тестовой зоны 
> >> сможет
> >> повлиять на уже настроенные ограничения.
> 
> > Если директива приводит к отклонению запроса, то он не будет учтен во всех
> > зонах. Если мы сделаем режим таким, что при этом запрос будет учтен, но не
> > будет отклонен, то это не даст нам возможности оценить работу директивы,
> > поскольку всё будет работать несколько не так, как если бы dry-run был 
> > выключен
> > и не позволит оценить реальное влияние директивы на количество пропущенных
> > запросов.
> 
> Тестовое ограничение не может приводить к отклонению запроса, значит запрос
> может быть отклонен только другой, не тестовой директивой.
> 
> Если  состояние тестируемой зоны показывает необходимость отклонения
> запроса этой зоной, то запрос в этой тестовой зоне не учитывается независимо 
> от
> того, будет ли отклонен запрос другими зонами или нет. В остальных зонах 
> запрос
> учитывается согласно окончательному решению по отклонению или пропуску 
> запроса,
> на которое тестируемая зона не влияет.
> 
> Если другие, не тестовые директивы, не отклоняют запросы, то их подсчет в
> тестовой зоне ведется и будет соответствовать реальной картине потока 
> запросов.
> 
> Если другие, не тестовые директивы, отклоняют запросы, а тестовая зона не
> отклоняет - значит тестируемая зона имеет менее жесткие ограничения, что
> является для нас метрикой допустимости перевода её в боевой режим.
> 
> Перевод в боевой режим может только уменьшить число запросов, поступающих на
> учет нетестовые зоны, что является ожидаемым поведением в силу более жесткого
> ограничения во включаемой зоне.
> 
[..]

Да, и это влияние на учет запросов в других зонах может сказаться на
поведении.

Скажем вот в такой конфигурации:

  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 объединены ограничения по различным факторам, спрогнозировать
может быть трудно, а 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.
> 

А вот и не получится увидеть.  1r/s в режиме dry-run может отклонить
существенно меньше запросов, чем в обычном режиме.  Произойти это может
из-за того, что часть запросов, которые могли бы попасть под ограничение
в zone=test будут отклонены в зонах one и two.

Работа ограничений в зонах one и two изменится при выключении dry-run в
зоне test.


> Я думаю, что вполне понятно то, что если в контексте есть ограничение с зоной
> one с rate=2r/s, то добавление ограничения с тестовой зоной test с rate=3r/s 
> не
> покажет "количества ограничений", но это и не ожидается и не требуется.
> 

Зависит от критерия, по которому производится ограничение.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Улучшение ngx_http_limit_req_module

2016-02-02 Пенетрантность Pavel V. 
Здравствуйте, Валентин.

> Невозможно добавить или убрать ограничение, не повлияв на работу остальных.

В моей схеме можно добавить дополнительное тестовое ограничение, которое не
сможет приводить к отклонению запроса, а значит не повлияет на подсчет запросов
в остальных зонах.

>> В моей схеме можно добавить новую зону в тестовом режиме в дополнение к уже
>> настроенным ограничениям. Не понимаю, как добавление новой тестовой зоны 
>> сможет
>> повлиять на уже настроенные ограничения.

> Если директива приводит к отклонению запроса, то он не будет учтен во всех
> зонах. Если мы сделаем режим таким, что при этом запрос будет учтен, но не
> будет отклонен, то это не даст нам возможности оценить работу директивы,
> поскольку всё будет работать несколько не так, как если бы 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

2016-02-02 Пенетрантность Валентин Бартенев 
On Tuesday 02 February 2016 05:45:18 Pavel V. wrote:
> Здравствуйте, 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.


Это не может быть параметром 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 они окажутся пропущены.

Если же мы будем просто игнорировать работу zone=one и продолжать учитывать 
запрос в zone=two, то опять же не получим реальной картины.

Т.е. тестировать по отдельности, без влияния на уже настроенные ограничения,
не получится в любом случае.

Также хочется обратить внимание, что ограничения чаще всего настраиваются к 
конкретному ресурсу, т.е. под конкретный location, а следовательно и 
тестировать имеет смысл в рамках этого блока location.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Помогите друзья!!Ubuntu 14-04 ngnix php-fpm

2016-02-02 Пенетрантность Alex Domoradov 
> Вот может еще у когото будет такая же проблемма!Удачи всем
за такое надо бить по рукам, сразу. Особенно, если на продакшене

2016-02-02 13:56 GMT+02:00 Konstantin Tokarev :

>
>
> 02.02.2016, 13:18, "Alex_Cardo" :
> > Пропал файлик /var/run/php5-fpm.sock. Как его востановить?
>
> Советую на досуге разобраться, что такое Unix Domain Socket и чем он
> отличается от обычного файла.
>
> >
> > вот мои конфиг php
> >
> >  access_log /var/log/nginx/access.log;
> >error_log /var/log/nginx/error.log;
> >location ~ \.php$ {
> > root /var/www/AS_BTI/PHP;
> > try_files $uri =404;
> > include fastcgi_params;
> > fastcgi_split_path_info ^(.+?\.php)(/.*)$;
> > fastcgi_pass unix:/var/run/php5-fpm.sock;
> > fastcgi_index index.php;
> > fastcgi_param SCRIPT_FILENAME
> > /var/www/AS_BTI/PHP$fastcgi_script_name;
> >
> >}
> >
> > /var/run/? cдесь он всегда был ,все работало отлично.к обработке php
> > кода вообще небыло замечаний.А потом я взял и перегрузи компьютер и вот
> > ошибка сразу error log мой *1 connect() to unix:/var/run/php5-fpm.sock
> > failed (2: No such file or directory) while connecting to upstream,
> client:
> > 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream:
> > "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost"
> >
> > Помогите кто чем может!!спасибо друзья!!
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,264258,264258#msg-264258
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> 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

Re: Помогите друзья!!Ubuntu 14-04 ngnix php-fpm

2016-02-02 Пенетрантность Alex Domoradov 
> Пропал файлик /var/run/php5-fpm.sock. Как его востановить?
запустить php-fpm

# service php5-fpm start

2016-02-02 12:18 GMT+02:00 Alex_Cardo :

> Пропал файлик /var/run/php5-fpm.sock. Как его востановить?
>
> вот мои конфиг php
>
>  access_log /var/log/nginx/access.log;
>error_log /var/log/nginx/error.log;
>location ~ \.php$ {
> root /var/www/AS_BTI/PHP;
> try_files $uri =404;
> include fastcgi_params;
> fastcgi_split_path_info ^(.+?\.php)(/.*)$;
> fastcgi_pass unix:/var/run/php5-fpm.sock;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME
> /var/www/AS_BTI/PHP$fastcgi_script_name;
>
>}
>
> /var/run/?  cдесь он всегда был ,все работало отлично.к обработке php
> кода вообще небыло замечаний.А потом я взял и перегрузи компьютер и вот
> ошибка сразу   error log мой *1 connect() to unix:/var/run/php5-fpm.sock
> failed (2: No such file or directory) while connecting to upstream, client:
> 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream:
> "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost"
>
> Помогите кто чем может!!спасибо друзья!!
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,264258,264258#msg-264258
>
> ___
> 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: Помогите друзья!!Ubuntu 14-04 ngnix php-fpm

2016-02-02 Пенетрантность Konstantin Tokarev 


02.02.2016, 13:18, "Alex_Cardo" :
> Пропал файлик /var/run/php5-fpm.sock. Как его востановить?

Советую на досуге разобраться, что такое Unix Domain Socket и чем он отличается 
от обычного файла.

>
> вот мои конфиг php
>
>  access_log /var/log/nginx/access.log;
>    error_log /var/log/nginx/error.log;
>    location ~ \.php$ {
> root /var/www/AS_BTI/PHP;
> try_files $uri =404;
> include fastcgi_params;
> fastcgi_split_path_info ^(.+?\.php)(/.*)$;
> fastcgi_pass unix:/var/run/php5-fpm.sock;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME
> /var/www/AS_BTI/PHP$fastcgi_script_name;
>
>    }
>
> /var/run/? cдесь он всегда был ,все работало отлично.к обработке php
> кода вообще небыло замечаний.А потом я взял и перегрузи компьютер и вот
> ошибка сразу error log мой *1 connect() to unix:/var/run/php5-fpm.sock
> failed (2: No such file or directory) while connecting to upstream, client:
> 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream:
> "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost"
>
> Помогите кто чем может!!спасибо друзья!!
>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,264258,264258#msg-264258
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Regards,
Konstantin

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность alexandre_frolov 
Вообще на сайте ssl.domain.ru валидный сертификат, но он ведь не подойдет
для редиректов с других доменов?
Т.е. правильно ли я понял, что выделение второго IP - абсолютная
необходимость?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264248,264268#msg-264268

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Помогите друзья!!Ubuntu 14-04 ngnix php-fpm

2016-02-02 Пенетрантность Alex_Cardo 
Спасибо всем!Проблемма решена!!  


sudo apt-get remove --purge php5-fpm
sudo apt-get update
sudo apt-get install php5-fpm

Вот может еще у когото будет такая же проблемма!Удачи всем

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264258,264269#msg-264269

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Улучшение ngx_http_limit_req_module

2016-02-02 Пенетрантность Pavel V. 
Здравствуйте.

> Это не может быть параметром 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: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность kron 
Это абсолютная необходимость, если у вас сертификат подписан на один домен и
не валиден для всех адресов которые настроены на nginx, если же у вас
wildcard и все домены под него подпадают, то в этом нет необходимости.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264248,264275#msg-264275

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с HTTPS - много сайтов на одном IP

2016-02-02 Пенетрантность kron 
server {
  listen 443 ssl default;

  ssl_certificate /path/to/cert;
  ssl_certificate_key /path/to/key;

  location / {
return 301 http://$host$request_uri;
  }
}

server {
  server_name ssl_site.ru www.ssl.site.ru;
  ...
}

http://pastebin.com/Q52XQYFq

но как верно заметили, в верхней секции сертификат должен подходить для
доменов, которые вы хостите.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,264248,264276#msg-264276

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Улучшение ngx_http_limit_req_module

2016-02-02 Пенетрантность Валентин Бартенев 
On Tuesday 02 February 2016 19:23:19 Pavel V. wrote:
> Здравствуйте.
> 
> > Это не может быть параметром 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 - ожидаемое явление.
> 

Ограничения не работают по отдельности, они не работают последовательно, они
работают вместе и одновременно.  Когда указано несколько директив limit_req,
то результатом будет кумулятивное решение о том, следует ли отклонять запрос
или нет, и если запрос будет отклонен, то он не будет посчитан во всех зонах.
Если же запрос отклонять не следует, то вычисляется наибольшая задержка.

Невозможно добавить или убрать ограничение, не повлияв на работу остальных.


> > Т.е. тестировать по отдельности, без влияния на уже настроенные ограничения,
> > не получится в любом случае.
> 
> В моей схеме можно добавить новую зону в тестовом режиме в дополнение к уже
> настроенным ограничениям. Не понимаю, как добавление новой тестовой зоны 
> сможет
> повлиять на уже настроенные ограничения.

Если директива приводит к отклонению запроса, то он не будет учтен во всех
зонах.  Если мы сделаем режим таким, что при этом запрос будет учтен, но не
будет отклонен, то это не даст нам возможности оценить работу директивы,
поскольку всё будет работать несколько не так, как если бы dry-run был выключен
и не позволит оценить реальное влияние директивы на количество пропущенных
запросов.

Если мы будем действовать также, как без режима dry-run, но только пропускать
запрос, то это повлияет на работу сервера парадоксальным образом - более
жесткое ограничение в режиме dry-run будет приводить к пропусканию сервером
большего количества запросов, чем при его отсутствии.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru