Re: announcing freenginx.org

[Andrey Kopeyko]

Илья Шипицин писал 2024-02-16 12:51:

пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov
:


On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:


Примерно в середине марта 2020 года

началось явное, наблюдаемое извне,

отползание следаков от "дела nginx".

Что закончилось ЕМНИП в мае

вынесением постановления о

закрытии дела с феерической
формулировкой

"... в связи с отсутствием факта

преступления".

а что феерического в данной
формулировке?


Обычно прекращение дела формулируется как "отсутствие состава 
преступления".


Т.е. факт действий был подтверждён, но квалифицировать их по УК не 
получилось.



Здесь же следствие постулировало что "самого факта не нашли".

Что неудивительно - заявление о возбуждении дела (его мотивировочная 
часть полностью вошла в постановление об обыске в офисе nginx, утекшее в 
РБК в середине дня) писали люди плохо знакомые с историей Рамблера, 
поэтому изложенных там "фактов" не существовало в природе. И я точно 
указал где в доказательной базе следствия содержится строгое 
доказательство отсутствия этих "фактов".




ну, первое столкновение с правовой
системой вызывают эмоции.

когда в 10-й раз видишь примерно одни и
те же патерны, это приедается.
возможно, Андрею каждый раз как первый
)) или до 2019-го бог его хранил от
правоохранителей


Нет, это далеко не первое моё столкновение с правоохранителями. Даже не 
первое моё пребывание в статусе свидетеля по уголовному делу.


Но, тьфу-тьфу-тьфу, опыт мой действительно небольшой. И это мне 
нравится.




--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Andrey Kopeyko]

Maxim Dounin писал 2024-02-16 02:24:

Hello!

Андрей, я тебе, как и многим другим, всемерно благодарен за
поддержку в 2019 и после (эта история, кстати, всё ещё
продолжается).  Но, честно говоря, согласен с Геной - какая угодно
бумага этих людей бы не остановила.


Подавателей претензий - может, и не остановила бы, но сильно осложнила 
бы им юридическое оформление претензии.



Я хорошо помню как вздрогнул полковник, старший следственной группы, 
когда уже после завершения допроса, при разъяснении им что же там 
наговорил, я вспомнил и сказал что в 2011 году читал в прессе что 
Рамблер высказывался об отсутствии претензий к Игорю по nginx. "Вот вам 
компьютер с интернет, найдите плиз, это очень важно" - сразу сказал он.


Сходу ничего не нашлось; искомое обнаружил Юрий Синодов примерно через 
неделю; плюс я ещё подтащил, через своего адвоката Тимофея Мусатова, 
любопытных материалов из числа первоисточников, имевшихся у следствия, - 
и до следственной группы, похоже, стало доходить что Рамблер их 
"немножечко попользовал".


Ещё в день допроса, разъясняя мне положения УПК, полковник заявил мне 
что "Дело возбуждено по тяжкой статье, поэтому обязательно кто-то будет 
посажен. Либо виновный, либо следователь, неправомерно возбудивший 
уголовное дело".


Последний вариант его устраивал слабо, хотя времени для исследования 
ситуации у них было предостаточно - между подачей заявления Рамблером и 
решением о возбуждении дела прошло немалое кол-во времени. Мне неведомо 
как и чем они это время провели, но по некоторым наблюдаемым признакам - 
подготовка к проведению допросов и обысков прошла весьма халатно.


Примерно в середине марта 2020 года началось явное, наблюдаемое извне, 
отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае 
вынесением постановления о закрытии дела с феерической формулировкой 
"... в связи с отсутствием факта преступления".


Макс, проверь плиз правильно ли я помню формулировку - у тебя такой 
документ должен быть; мне, увы, такой бумаги не досталось из-за гибели 
Тимофея Мусатова в конце апреля...



Итого: такая бумага остановила бы СК при попытке Рамблера возбудить 
дело.






Макс,

на наступай плиз на эти грабли ещё раз.

Либо получи от F5 письменный "отказ от претензий" (не берусь даже 
оценить

насколько это реально...)

Либо готовься всё время дрожать как осиновый лист.


Если вдруг у компании F5 возникнут претензии к названию - ну, в
крайнем случае переименую проект, не велика беда.  Других рисков
тут не просматривается при всём желании.


Единственное что в этой ситуации лично меня радует - я не вижу никаких
оснований для привлечения своей персоны как свидетеля по возможному 
"делу

freenginx" :-)
Тьфу-тьфу-тьфу.


Да ты, однако, оптимист! :))


Я следую принципу "Fac quod debes et quod futurum est".


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Andrey Kopeyko]

Илья Шипицин писал 2024-02-16 01:00:

чт, 15 февр. 2024 г. в 21:20, Andrey Kopeyko
:


Gena Makhomed писал 2024-02-15 22:20:


Насколько я понимаю, у Максима

расчет на то, что F5 не позволит

никому постороннему

зарегистрировать торговую марку
freenginx,

и при этом сама F5 не будет выдвигать

никаких претензий проекту

freenginx, потому что этот проект

является полностью свободным

и полностью некоммерческим.


Это ровно та же ошибка, которую в 2011
году совершил Игорь Сысоев -
увольняясь из Рамблера,
он удовлетворился словами рулей что
"никаких претензий к нему по поводу
nginx у них нет"
(в webarchive есть интервью PR-щика
Рамблера помершему уже изданию с
этими словами, ссылка у меня в ФБ
заначена)
и не удосужился закрепить это
отсутствие претензий на бумаге.

Результат такой беспечности налицо -
многие (и из этого листа тоже)
запомнили 12.12.2019 как день плотного
общения со следователями СК.


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


Не бойтесь - не взяли.

С удовольствием развиртуализуюсь на DevOpsConf через пару недель.




по сути той истории, у меня есть
непраздный вопрос - допустим у Игоря
была бы бумага, что Рамблер не имеет
претензий.
но насколько я понимаю, претензии
предъявил новый собственник Рамблера,
Сбербанк же ? ну есть у вас бумага от
Рамблера.
а следователи вам говорят - а
претензия от Сбера. и что с этим
счастьем делать ?



А ничего не делать - вместе с покупкой Р. к Сберу переходят не только 
его права, но и обязанности. В частности, перешла бы обязанность "не 
привлекать".


В этом случае дело затухло бы уже на стадии возбуждения.





Мне лично очень не понравилось, как я
провёл тот день.
Да и последующие 4 месяца оказались
для меня излишне дорогими. Но как
адвокат - Тимофей Мусатов был очень
хорош.

Макс,

на наступай плиз на эти грабли ещё
раз.

Либо получи от F5 письменный "отказ от
претензий" (не берусь даже
оценить насколько это реально...)

Либо готовься всё время дрожать как
осиновый лист.

Единственное что в этой ситуации
лично меня радует - я не вижу никаких
оснований для привлечения своей
персоны как свидетеля по возможному
"делу freenginx" :-)
Тьфу-тьфу-тьфу.

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

--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Andrey Kopeyko]

Gena Makhomed писал 2024-02-15 22:20:


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


Это ровно та же ошибка, которую в 2011 году совершил Игорь Сысоев - 
увольняясь из Рамблера,
он удовлетворился словами рулей что "никаких претензий к нему по поводу 
nginx у них нет"
(в webarchive есть интервью PR-щика Рамблера помершему уже изданию с 
этими словами, ссылка у меня в ФБ заначена)

и не удосужился закрепить это отсутствие претензий на бумаге.

Результат такой беспечности налицо - многие (и из этого листа тоже) 
запомнили 12.12.2019 как день плотного общения со следователями СК.


Мне лично очень не понравилось, как я провёл тот день.
Да и последующие 4 месяца оказались для меня излишне дорогими. Но как 
адвокат - Тимофей Мусатов был очень хорош.



Макс,

на наступай плиз на эти грабли ещё раз.

Либо получи от F5 письменный "отказ от претензий" (не берусь даже 
оценить насколько это реально...)


Либо готовься всё время дрожать как осиновый лист.


Единственное что в этой ситуации лично меня радует - я не вижу никаких 
оснований для привлечения своей персоны как свидетеля по возможному 
"делу freenginx" :-)

Тьфу-тьфу-тьфу.

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



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Andrey Kopeyko]

Gena Makhomed писал 2024-02-15 15:00:

On 15.02.2024 12:18, Maxim Dounin wrote:


Ну и в-третьих, если всё-таки компания F5 решит играть в эти игры,
то это хорошо продемонстрирует их отношение к свободному
программному обеспечению.  Я не думаю, что это случиться, скорее
рассчитываю, что компания одумается и будет поддерживать проект,
ибо это в первую очередь в их собственных интересах, но поживём -
увидим.


Отто фон Бисмарк когда-то говорил: «Меня не интересуют их намерения,
меня интересуют их возможности» - это правильный подход, если Вы
заинтересованы в том, чтобы проект freenginx существовал в будущем.


Золотые слова, очень к месту.



Для нормального существования проекта все равно будут нужны деньги,
даже на оплату хостинга или на другие расходы. Не планируете создавать
некоммерческую организацию, которая будет заниматься курированием
этого проекта? По аналогии с FreeBSD Foundation, Linux Foundation ?


Я бы посоветовал \ пожелал воссоединиться коллективу разработчиков nginx 
- чтобы проект freenginx ушёл под крыло ООО "Вебсервер" 
https://angie.software/


Это даст и ресурсы, и помощь в защите, и et cetera.

Но это лишь мой личный совет.


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Andrey Kopeyko]

Maxim Dounin писал 2024-02-15 13:31:

Hello!

On Thu, Feb 15, 2024 at 10:17:57AM +0300, Andrey Kopeyko wrote:


Gena Makhomed писал 2024-02-15 04:17:
> On 14.02.2024 19:59, Maxim Dounin wrote:
>
> > Подобный подход можно понять: они владеют проектом, и могут с ним
> > делать всё, что считают нужным, включая подобные маркетинговые
> > акции.  Это, однако, противоречит нашемоу соглашению.  И, что более
> > важно, я больше не имею возможности как-либо контролировать
> > изменения, которые вносят в nginx в F5, и не могу рассматривать
> > nginx как открытый и свободный проект, разрабатываемый для общего
> > блага.
> >
> > Так что, начиная с сегодняшнего дня, я больше не участвую в
> > разработке nginx'а в рамках F5.  Вместо этого я запускаю
> > альтернативный проект, управлять которым будут разработчики, а не
> > корпоративные структуры:
> >
> > http://freenginx.org/
> >
> > Цель проекта - обеспечить разработку nginx'а, свободную от
> > произвольного корпоративного вмешательства.  Помощь и участие
> > приветствуются.  Надеюсь, проект будет полезен для всех.
>
> Максим, тут есть одна очень большая проблема.
>
> Владельцем торговой марки NGINX является компания F5 NETWORKS, INC.
> https://trademarks.justia.com/853/12/nginx-85312802.html
>
> Своего разрешения на использование своей торговой марки NGINX
> F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст.

Максим,

Геннадий беспокоится обоснованно, и соображения написал все очень 
верные.


Если хочешь, могу попробовать организовать тебе консультацию по 
"доменам,
IP, ТМ и судебном опыте вокруг этого всего" у специалистов Ру-Центра. 
За
последние 25 лет они на этом не одну собачью стаю съели, и по 
буржуйским

доменам тоже.


Спасибо, я пока рассчитываю на отсутствие проблем в этом вопросе,
смотри ответ Геннадию.  Если возникнут - будем решать их по мере
поступления.


Макс,

дело, конечно, исключительно твоё - но такая твоя беспечность меня 
начинает беспокоить.


Именно тем что ты, не юрист, начинаешь делать вывод о грядущих действиях 
противников, которые таки юристы.


Даже неуспешные их действия - способны выпить немало твоей крови, увы.


Рекомендую всё же проконсультироваться с юристами по доменам и IP.
На Highload-е обычно бывает 2-3 таких специализированных конторы, если 
nic.ru тебе не подходит.





--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Andrey Kopeyko]

Gena Makhomed писал 2024-02-15 04:17:

On 14.02.2024 19:59, Maxim Dounin wrote:


Подобный подход можно понять: они владеют проектом, и могут с ним
делать всё, что считают нужным, включая подобные маркетинговые
акции.  Это, однако, противоречит нашемоу соглашению.  И, что более
важно, я больше не имею возможности как-либо контролировать
изменения, которые вносят в nginx в F5, и не могу рассматривать
nginx как открытый и свободный проект, разрабатываемый для общего
блага.

Так что, начиная с сегодняшнего дня, я больше не участвую в
разработке nginx'а в рамках F5.  Вместо этого я запускаю
альтернативный проект, управлять которым будут разработчики, а не
корпоративные структуры:

http://freenginx.org/

Цель проекта - обеспечить разработку nginx'а, свободную от
произвольного корпоративного вмешательства.  Помощь и участие
приветствуются.  Надеюсь, проект будет полезен для всех.


Максим, тут есть одна очень большая проблема.

Владельцем торговой марки NGINX является компания F5 NETWORKS, INC.
https://trademarks.justia.com/853/12/nginx-85312802.html

Своего разрешения на использование своей торговой марки NGINX
F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст.


Максим,

Геннадий беспокоится обоснованно, и соображения написал все очень 
верные.


Если хочешь, могу попробовать организовать тебе консультацию по 
"доменам, IP, ТМ и судебном опыте вокруг этого всего" у специалистов 
Ру-Центра. За последние 25 лет они на этом не одну собачью стаю съели, и 
по буржуйским доменам тоже.





А вот дальнейшее развитие событий предусмотреть совсем не трудно.
Они будут преследовать Вас в судебном порядке за trademark infringement

Сначала - будет UDRP - Uniform Domain Name Dispute Resolution
https://www.icann.org/resources/pages/trademark-infringement-2017-06-20-en
а потом - могут в конечном итоге и вообще отобрать
у Вас домен freenginx.org этот домен станет их собственностью.
Учитывая их доходы - они смогут найти деньги на очень хороших
юристов и адвокатов, так что вопрос утраты контроля над доменом
freenginx.org - это не вопрос "если", это вопрос "когда"
- они это сделают. А если не сделают сейчас - то смогут сделать
в любой момент в будущем, полностью отобрав этот домен и запретив
Вам каким-либо образом использовать торговую марку NGINX. Например,
они могут заняться этим вопросом не сразу, а через некоторое время,
когда Ваш проэкт наберет некоторую популярность и посещаемость сайта
станет высокой. Имеет ли смысл так сильно рисковать основной веткой?
https://www.wipo.int/amc/en/domains/guide/


https://en.wikipedia.org/wiki/Trademark_infringement
- законодательство тут на их стороне и по закону они будут правы.
В https://en.wikipedia.org/wiki/WIPO входят практически все страны мира
и trademark infringement является нарушением закона практически в любой
стране. Даже если они не будут заниматься тем, чтобы отбирать у Вас
права на домен freenginx.org - они это смогут сделать в любой момент
времени в будущем, когда посчитают это целесообразным.
Может быть лучше будет переименовать проект в какое-то другое имя,
в котором вообще не будут упоминаться ничьи торговые марки?

Когда-то проекту CentOS пришлось не только убирать все упоминания
торговой марки Red Hat - они были вынуждены даже убрать все упоминания
Red Hat и заменить их на PNAELV.

PNAELV - это Prominent North American Enterprise Linux Vendor,
это слово не является ничьей торговой маркой и его использование
не запрещено. А вот торговую марку Red Hat без их разрешения
использовать нельзя. Аналогично будет и с торговой маркой NGINX.

Аналогично, например, было и с торговой маркой Apache -
из-за чего все дистрибутивы были вынуждены переименовать
веб-сервер в httpd.

Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то
имя, которое не является ничьей торговой маркой и для защиты этого
имени - зарегистрировать свою торговую марку, чтобы не было потом
ситуации "обратного захвата домена" - это когда вы используете
какое-то доменное имя, например, something.ru, при этом -
something не ялвяется торговой маркой. И потом, через какое-то
время - какой-то совершенно посторонний человек, регистрирует
торговую марку something, подает на Вас в суд и по решению суда
отбирает у Вас контроль над доменом something.ru не смотря на то,
что эта торговая марка не была зарегистрирована в момент регистрации
Вами домена something.ru - это ничего не меняет, суд будет на стороне
владельца торговой марки. Это и называется "обратный захват домена".
Для доменов зарегистрированных в международных TLD - ситуация не такая
однозначная, если домен был зарегистрирован до момента регистрации
соответствующей торговой марки - то еще могут быть варианты. Но если
Вы регистрируете домен freenginx.org в тот момент времени, когда
F5 NETWORKS, INC. является владельцем торговой марки NGINX - тогда
шансов удержать контроль над этим доменом - практически нет,
ведь Вы же здесь без их разрешения используете их торговую марку.

Это примерно то же самое, что кто-то зарегистрирует 

Re: [proposal] SERVER_NAME в fastcgi_params

[Andrey Kopeyko]

On Mon, 6 Mar 2023, Nikolay Shaplov wrote:

В письме от понедельник, 6 марта 2023 г. 23:00:22 MSK пользователь Илья 
Шипицин написал:

> +1
> 
> Мой мысленный эксперимент показал что ничего ни у кого не сломается. См. в

> более ранних письмах.

ну допустим, у кого-то далее по цепочке стоит nginx, который логирует в
access_log параметр server_name от апстрима.
и там всегда был прочерк. и на это значение завязались аналитики.


Так вот, значение переменной $server_name никто менять не предлагает.
Предлагается в дефолтном конфиге fastcgi_params (и его клонах) изменить 
значение переменной окружения SERVER_NAME, передаваемой в cgi-скрипт c 
$server_name на $host. Таким образом будет соблюдена буква RFC, которая в 
текущей момент не соблюдается. 


Приведенный вами пример с аналитикой, будет работать так же как и раньше


ситуация нелепая, но зачем же таким людям делать хорошо против их воли
Ну вот на одной чаши весов нелепая ситуация, а на другой соблюдение RFC. При 
этом несоблюдение этого RFC ведет к потенциальным проблемам и потерям времени 
(я тому пример)


Николай, к потере вашего времени привело не несоблюление RFC (требовать 
соблюдения которого в данном конкрентном случае - не очень правильно; тут 
должно быть многа букв, расскажу голосом...), а Ваше непонимание разницы между 
параметром конфига server_name и переменной запроса $http_host.


Сожалею о Вашем потерянном времени.

Приходите в офис, всё расскажу.


Вот дописать в доку статью "о (вреде и) подводных камнях обработки запроса в 
дефолтном сервере" - наверное, было бы полезным.



--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Andrey Kopeyko]

On Mon, 6 Mar 2023, Nikolay Shaplov wrote:

В письме от понедельник, 6 марта 2023 г. 13:59:30 MSK пользователь Andrey 
Kopeyko написал:

к "нарушению RFC" приводит ваша конкретная конфигурация - когда вы
обрабатываете множество имён в дефолтном сервере, для которого вы _не
задаёте_ server_name.

Вот корень всех бед.

И именно поэтому дефолтное поведение менять не следует.


Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы 
написано:


The SERVER_NAME variable MUST be set to the name of the server host
to which the client request is directed.


Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но раз 
вам так надо и вы понимаете что вы делаете, то пускай.


Обходной хак вам подсказали - использовать $http_host, и быть готовым что там 
тоже может быть пусто.


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



Приходите в офис, обсудим.



...

... where several HTTP virtual hosts share the same IP address.
In that case, the server would use the contents of the request's Host
header field to select the correct virtual host.

MUST как-то обязывает к тому чтобы оно либо было установлено, либо вообще 
отказывалось работать, со страшной руганью, на мой вкус...



Если вы зададите для этого сервера несуществующее имя ("_" как рекомендует
документация, или "fakehost.fakedomain") - переменная SERVER_NAME волшебным
образом появится.

P.S.
Будете в офисе - подходите, обсудим подробнее (ибо голосом будет удобнее).

Буду в городе в начале след. недели. Обсудим, да...



--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Andrey Kopeyko]

On Mon, 6 Mar 2023, Nikolay Shaplov wrote:

В письме от воскресенье, 5 марта 2023 г. 22:04:35 MSK пользователь Илья 
Шипицин написал:

> Но не следует ли заменить $server_name на $host в конфигах *cgi_params  в
> дистрибутиве nginx? Я в первую очередь с этой мыслью сюда пришел...



но, с другой стороны, существующие механизмы позволяют вам использовать
$host и не зависеть от дефолтных конфигов, верно ?
Я в данном вопросе беспокоюсь скорее за других, чем за себя. Я в свое время 
убил очень много времени, пока траблшутил проблему вызванную отсутствием 
корректного значения в SERVER_NAME, и в таких случаях обычно стараюсь сделать 
так, чтобы никому после меня не пришлось бы снова ходть по проделанному мной 
пути. Изменение дефолта в конфигах *cgi_params, решит эту задачу лучше всего



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


В данном случае я бы сказал что это изменение более чем оправдано.

1. Нынешнее положение дел приводит к нарушению RFC. Исправление приведет к 
соблюдению RFC "из коробки". Соблюдать RFC -- не только хорошо, но и очень 
важно.


Николай,

к "нарушению RFC" приводит ваша конкретная конфигурация - когда вы 
обрабатываете множество имён в дефолтном сервере, для которого вы _не задаёте_ 
server_name.


Вот корень всех бед.

И именно поэтому дефолтное поведение менять не следует.


Если вы зададите для этого сервера несуществующее имя ("_" как рекомендует 
документация, или "fakehost.fakedomain") - переменная SERVER_NAME волшебным 
образом появится.



P.S.
Будете в офисе - подходите, обсудим подробнее (ибо голосом будет удобнее).





2. Существующие конфигурации, по моему представлению не будут затронуты этим 
изменением. Я вижу следующие варианты:
2.1. Либо в конфиге указан srever_name и $host будет возвращать то же значение 
что и $server_name
2.2. Значение переменной окружения SERVER_NAME перезаписывается после 
применения дефолтов. Новый дефолт не повлияет на поведение, так как будет 
перезаписан
2.3. cgi-скрипт вообще игнорирует переменную окружения SERVER_NAME. И 
изменения дефолта не страшно.


То есть для существующих инсталляций поведение никак не изменится. Зато очень 
сильно упроститься создание новых инсталляций, для случаев, подобных моему. 



P.S. Мне очень повезло что я настраивал CGI-скрипт написанный на языке который 
я хорошо знаю, и у меня была возможность пройтись по всей глубине его 
выполнения и обнаружить причину проблемы. В случае, если настраивающий этот 
скрипт админ не владел бы языком программирования на котором написан скрипт, 
задача настройки могла оказаться вообще в принципе не решаемой... Совершенно 
не очевидное поведение было в отсутствии значения SERVER_NAME. Этот 
воображаемый админ с большой вероятностью (и не без оснований) обвинил бы во 
все nginx, ведь под apache все работает из коробки. Вот и я бы хотел чтобы и 
под nginx оно тоже работало бы из коробки, я патриот nginx ;-). Я все стараюсь 
поднимать на нем, по мере сил и возможностей.



--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su


--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 400 Bad request (spaces in request)

[Andrey Kopeyko]

sipopo писал 2022-07-22 12:26:

Добрый день, sipopo!


Приветствую, знаю что с версии 1.21.1 nginx пишет ошибку 400, в случае
пробелов в запросе к серверу.
Но есть старые клиенты, которых нужно поддерживать, подскажите, может 
есть

какие-то варианты обойти проблему?


Запросы от старых клиентов принимайте на старом nginx, и проксируйте на 
новый.


При проксировании старый nginx выполнит urlencoding запроса к новому 
nginx, и тот его не отлупит.



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: How to write $upstream_trailer_{name} into access.log

[Andrey Kopeyko]

Andrey Kopeyko писал 2021-05-23 03:57:

Gena Makhomed писал 2021-05-23 01:50:

On 23.05.2021 1:25, Andrey Kopeyko wrote:


Добрый день, Геннадий!


Здравствуйте, Андрей!


Использую nginx/1.19.10 из официального репозитория nginx.org

На бэкенде в секции http прописал такие директивы:

add_trailer X-Response-Time $upstream_response_time always;
add_trailer X-Cache-Status $upstream_cache_status always;

На фронтенде в секции http прописал proxy_http_version 1.1;
Также на фронтенде в директиву log_format добавил переменные:

$upstream_trailer_x_response_time $upstream_trailer_x_cache_status

Ожидается что в лог будут записаны полученные значения этих 
переменных,
но вместо них в лог пишутся символы - - обозначающие пустые 
значения.


Почему так происходит?


Очевидно, потому что бэкенд _не_ возвращал вам заголовков 
"trailer-x-response-time: " - вы их сами выдумали.


trailer fields at the end of the message - это не заголовки.

Бэкенд эти trailers возвращает, я проверял переменные

$sent_trailer_x_response_time $sent_trailer_x_cache_status

на бэкенде они имеют не пустые значения и пишутся в лог бэкенда.


Стало понятнее.

Предположу, что в переменные $upstream_ они не попадают, т.к.
передаются бэкендом _после_ тела ответа, а заголовки nginx ожидает
увидеть _до_ тела.


Наверное, я не прав - судя по документации, они должны "подкладываться" 
к $upstream_ переменным


$upstream_trailer_имя
хранит поля из конца ответа, полученного от сервера группы 
(1.13.10).



https://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables



Похоже на багу, раз "не подкладываются".


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: How to write $upstream_trailer_{name} into access.log

[Andrey Kopeyko]

Gena Makhomed писал 2021-05-23 01:50:

On 23.05.2021 1:25, Andrey Kopeyko wrote:


Добрый день, Геннадий!


Здравствуйте, Андрей!


Использую nginx/1.19.10 из официального репозитория nginx.org

На бэкенде в секции http прописал такие директивы:

add_trailer X-Response-Time $upstream_response_time always;
add_trailer X-Cache-Status $upstream_cache_status always;

На фронтенде в секции http прописал proxy_http_version 1.1;
Также на фронтенде в директиву log_format добавил переменные:

$upstream_trailer_x_response_time $upstream_trailer_x_cache_status

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

но вместо них в лог пишутся символы - - обозначающие пустые значения.

Почему так происходит?


Очевидно, потому что бэкенд _не_ возвращал вам заголовков 
"trailer-x-response-time: " - вы их сами выдумали.


trailer fields at the end of the message - это не заголовки.

Бэкенд эти trailers возвращает, я проверял переменные

$sent_trailer_x_response_time $sent_trailer_x_cache_status

на бэкенде они имеют не пустые значения и пишутся в лог бэкенда.


Стало понятнее.

Предположу, что в переменные $upstream_ они не попадают, т.к. передаются 
бэкендом _после_ тела ответа, а заголовки nginx ожидает увидеть _до_ 
тела.




--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: How to write $upstream_trailer_{name} into access.log

[Andrey Kopeyko]

Gena Makhomed писал 2021-05-23 01:00:

Здравствуйте, All!


Добрый день, Геннадий!


Использую nginx/1.19.10 из официального репозитория nginx.org

На бэкенде в секции http прописал такие директивы:

add_trailer X-Response-Time $upstream_response_time always;
add_trailer X-Cache-Status $upstream_cache_status always;

На фронтенде в секции http прописал proxy_http_version 1.1;
Также на фронтенде в директиву log_format добавил переменные:

$upstream_trailer_x_response_time $upstream_trailer_x_cache_status

Ожидается что в лог будут записаны полученные значения этих переменных,
но вместо них в лог пишутся символы - - обозначающие пустые значения.

Почему так происходит?


Очевидно, потому что бэкенд _не_ возвращал вам заголовков 
"trailer-x-response-time: " - вы их сами выдумали.


А что вам мешает писать в лог значения $upstream_response_time и 
$upstream_cache_status из которых вы свои кастомные заголовки строите?



Это ошибка в nginx или я что-то делаю не так?


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как установить Rapid SSL 2018

[Andrey Kopeyko]

Илья Шипицин писал 2021-05-14 18:11:


контекстность не помешает.
в списке файлов - два промежуточных УЦ.
я затрудняюсь представить детали, но,
было бы логично прямо носом ткнуть
"вот мы выдали замудренный сертик с
двумя промежуточными УЦ, а вот у нас
есть инструкция для этого случая"


А эта инструкция есть на nginx.org - там отдельно расписывается что и 
как делать ровно в таком случае. Даже shell команды приведены ЕМНИП.



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как установить Rapid SSL 2018

[Andrey Kopeyko]

sf2015 писал 2021-05-14 17:38:

Сертификат куплен на домен и поддомены. Покупался на nic.ru.


У Ру-Центра шикарная и подробная документация по настройке SSL - 
смотрите на их сайте.


(сам писал некоторые её части ;-)



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как установить Rapid SSL 2018

[Andrey Kopeyko]

sf2015 писал 2021-05-14 09:38:
Для домена test.ru и всех поддоменов приобретен сеттификат Rapid SSL 
2018


Если ваш сертификат допустимо ставить на несколько серверов одновременно 
(ищите в договоре "server licences" или аналогичные слова), то можете 
просто размножить ключ+серт по нужному кол-ву железок\виртуалок. С 
соответствующими рисками для безопасности.


Если такое вам не разрешено, то
* или раскладывайте ключ+серт на свой страх и риск
* или докупайте опцию "server licences"
* или докупайте нужное кол-во сертификатов для уникальных ключей


Имеется:
 сам сертификат test_ru.crt
 промежуточный intermediate_pem_geotrust_rapidssl_wildcard_1.crt
 промежуточный intermediate_pem_geotrust_rapidssl_wildcard_2.crt
 приватный ключ key.txt
 корневой сертификат root_pem_geotrust_rapidssl_wildcard_1.crt
 сертификат test.ru.ca-bundle

Nginx установлен на Ubuntu 20 с IP 192.168.0.43.

общая задача такая. Есть некий вебсервис (https:// t1.test.ru), который
крутится на серваке в локалке с адресом 192.168.0.230.

Сейчас При вводе адреса https://t1.test.ru клиент проваливается
на192.168.0.230.
Нужна схема с проксированием так, чтобы При вводе адреса 
https://t1.test.ru

клиент проваливается на192.168.0.43, а затем перенаправлялся на
192.168.0.230

В перспективе будут еще https://t2.test.ru, которые пойдут на  
192.168.0.232

и т.п.


-
1. Подскажите какие как быть с сертификатами. Какие из приведённых выше
прописать в файле конфигурации.




server {
#listen 80;
 listen 443 ssl default_server;
 listen [::]:443 ssl default_server;
ssl on;
ssl_certificate /etc/ssl/test.ru/dcli.ru.ca-bundle;
#ssl_certificate_key /etc/ssl/test.ru/key.txt;
#ssl_session_timeout 5m;
#ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#ssl_dhparam /etc/ssl/certs/dhparam.pem;
#ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
#ssl_prefer_server_ciphers on;
#ssl_session_cache shared:SSL:10m;


server_name t1.test.ru;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

location / {
proxy_pass https://192.168.0.230;
}
}

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

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


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Можно ли сгенерировать случайную строку в переменну так как это делает nginx для request id?

[Andrey Kopeyko]

budarin писал 2021-05-13 03:07:
Мне нужно для CSP политики генерировать случайный nonce для каждого 
запроса

и записывать его в заголовок политики и затем этот же none передать в
заголовках апстриму


perl_set $rand 'sub { return int rand 20 }';

И дальше используйте по вкусу.



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как проксировать в nginx поисковый запрос на сайте?

[Andrey Kopeyko]

On Thu, 13 May 2021, maximkherson wrote:


ЗАДАЧА. В адресной строке браузера ввожу proxy.localhost/godzilla
(proxy.localhost мой виртальный хост). Nginx проксирует этот запрос, после
чего в адресной строке дожно остаться proxy.localhost/godzilla но по факту
дожно перейти на
https://rezka.ag/search/?do=search=search=godzilla

Мой код:

server {
<-->listen *:80;
<-->server_name proxy.localhost;
<-->location /(.*) {
<--><-->proxy_pass
https://rezka.ag/search/?do=search=search=$1;
<--><-->proxy_set_header Host rezka.ag;
<-->}
}
Пожалуйста помогите, а то уже всё перепробовал.

P.S. У меня выдаёт 403 ошибку.


Сайт rezka.ag вас заблокировал.


--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Авторизация при проксировании

[Andrey Kopeyko]

fleedstix писал 2020-11-10 12:53:

Добрый день!


Вечер добрый!


подскажите пожалуйста как можно реализовать авторизацию при
проксировании. Есть два сервера(бекенд и фронт). По требованиям 
безопасности

необходимо чтобы было проксирование с фронта на бек по защищенному
соединению с авторизацией.


Если вы уверены в безопасности вашего фронтенда - можно прямо в 
конфигурации добавлять заголовок "Authorization: Basic XYZ" в заголовки 
запроса к бэкенду.




--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Блокирование доступа с custom error page

[Andrey Kopeyko]

Andrey Kopeyko писал 2020-03-11 22:25:

suberjin писал 2020-03-11 20:12:

Здравствуйте.


Добрый вечер!

Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, 
мне бы

хотелось возвращать стилизированную картинку.

я это вижу как-то так:

if ($allowed_country = no) {
   return 403;
   error_page 403 /errors/deny.html;
}

В самом конфиге много location-ов. Я не хотел бы копировать этот код 
во все из них.


Вынесите этот фрагмент в кусочек конфига, и инклудьте его в нужных 
местах.


Другой вариант - генерируйте ваш конфиг с нужными проверками в каждом из 
локейшенов.



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Блокирование доступа с custom error page

[Andrey Kopeyko]

suberjin писал 2020-03-11 20:12:

Здравствуйте.


Добрый вечер!

Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, 
мне бы

хотелось возвращать стилизированную картинку.

я это вижу как-то так:

if ($allowed_country = no) {
   return 403;
   error_page 403 /errors/deny.html;
}

В самом конфиге много location-ов. Я не хотел бы копировать этот код во 
все из них.


Вынесите этот фрагмент в кусочек конфига, и инклудьте его в нужных 
местах.




Подозреваю, что я что-то не так делаю. Прошу помочь. Спасибо!



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: зеркалирование UDP трафика

[Andrey Kopeyko]

Илья Шипицин писал 2020-03-02 10:41:

привет!

хочется странного - продублировать udp
трафик на несколько ендпойтов в
режиме "ответа не предполагается".

придумался костыльный вариант -
проксировать якобы с ожиданием
ответа, и в случае, если ответа не было
(а его не будет), проксировать на
следующий.

некостыльных вариантов нет ?


Пропатчить http://nginx.org/ru/docs/http/ngx_http_mirror_module.html
на предмет работы с UDP ?


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с перезапуском в centos 8

[Andrey Kopeyko]

windos321 писал 2020-02-28 16:07:


Вот же зараза, не помогает создание:
Create the file /etc/systemd/system/nginx.service.d/dependency.conf 
with

After=network-online.target
Requires=network-online.target


Наверное, потому что вы секцию не указали

+[Unit]
 After=network-online.target
 Requires=network-online.target





--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Proxy cache с использованием Slice для MP4 медленно отдается клиенту

[Andrey Kopeyko]

Klark писал 2019-12-04 19:37:

Почему-то upstream time везде возращают значение
uct="-"
urt="-"


Это значит, что хождения к апстриму не было.

Для этих строк смотрите значения
 ' rt=$request_time ucs="$upstream_cache_status"'


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Proxy cache с использованием Slice для MP4 медленно отдается клиенту

[Andrey Kopeyko]

Klark писал 2019-12-03 21:50:

При включении онлайн видео 1мб видео скачивается почти 1.5-2 секунды
соответстено видео обычно начинается секунд через 10-15
перемотка тоже проходит секунды 4-6. Самое что не понятное интернет 
канал
(Интернет канал тоже 1Gb) даже на половину не нагружен, смотрят видео в 
этот

момент около 50-70 человек. Понять не могу почему же так происходит,


Включите на кеш-сервере логирование запросов вот с таким примерно 
форматом


log_format timed'$remote_addr - $remote_user [$time_local]'
' "$request" $status $body_bytes_sent'
' "$http_referer" "$http_user_agent"'
' rt=$request_time ucs="$upstream_cache_status"'
' us="$upstream_status" ua="$upstream_addr"'
' uct="$upstream_connect_time" 
urt="$upstream_response_time"'

;

и наблюдайте за временами upstream_*_time


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проксирование, буфер, лаги

[Andrey Kopeyko]

rihad писал 2019-08-07 17:09:


Меня вот это немного смутило:

"When buffering is disabled, the response is passed to a client
synchronously, immediately as it is received. nginx will not try to 
read the

whole response from the proxied server. "

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering

Получается когда buffering включен, то наоборот, контент читается 
полностью

перед началом отдачи клиенту.


Нет.
Ответ начинает отдаваться клиенту сразу по получении его от бэкенда. 
Зачем ждать конца?


Это 2 независимых процесса, работающих с максимально возможной скоростью
* ответ от бэкенда вычитывается быстро
* полученный от бэкенда ответ - передаётся клиенту по мере готовности 
клиента его принять.



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как декодировать url windows-1251?

[Andrey Kopeyko]

gont писал 2019-06-05 03:27:
Есть программа для скачивания файлов updater.exe она обращается на сайт 
к

файлу patchlist.xml
внутри patchlist.xml ссылки на файлы которые на русском языке, файл
patchlist.xml в кодировке windows-1251,
файлы не скачивает потому как их не находит на сервере, если поменять
кодировку patchlist.xml на utf8 то файлы качает,
но их сохраняет с названиями крякозябры (РЁРёСЂРѕРєР), видел хостинг на
котором работает всё нормально файл patchlist.xml у них в windows-1251 
и

качаются файлы.


Добрый день!

Дабы браузер сохранял файл под нужным вам именем - требуется выдавать 
заголовок "Content-Disposition: ", примерно так


location / {
  root  /path/to/root;
  add_header 'Content-Disposition' 'attachment; 
filename=$filename_utf8';

}

Что бы всё работало надо как то что бы сервер нормально декодировал url 
в

кодировке windows-1251.


"Имя файла в кодировке uft8" -
- вы можете выбирать по пре-геренённой мапе (если файлов небольшое 
количество)
- или перекодировать на лету из имени запрашиваемого файла (используя 
либо встроенные perl, lua, либо получая с бэкенда на любом удобном вам 
языке)



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: .htaccess

[Andrey Kopeyko]

Виктор Вислобоков писал 2019-05-12 10:35:


Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache
и юзать его .htaccess при включении специальной директивы.


Где ваш патч?


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Сложный кеш POST запросов

[Andrey Kopeyko]

On Wed, 17 Apr 2019, Иван Мишин wrote:


* не задали "proxy_cache_path" - прокси пока некуда кешировать
* не включили само кеширование директивой proxy_cache 


Это  задано на уровне http.
Мой вопрос не в том что кеширование не работает, а в том что оно работает
не так как надо, не так как планировал.


Тогда надо включать debug_connection, делать запрос, и читать error.log



вт, 16 апр. 2019 г. в 15:09, Andrey Kopeyko :


Иван Мишин писал 2019-04-16 12:26:

Добрый день, помогите пожалуйста со
следующей проблемой:


Добрый день, Иван!


Есть такой конфиг:

...

Но в моем случае это так не работает.


Потому что вы
* не задали "proxy_cache_path" - прокси пока некуда кешировать
* не включили само кеширование директивой proxy_cache 


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru




--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Сложный кеш POST запросов

[Andrey Kopeyko]

Иван Мишин писал 2019-04-16 12:26:

Добрый день, помогите пожалуйста со
следующей проблемой:


Добрый день, Иван!


Есть такой конфиг:

...

Но в моем случае это так не работает.


Потому что вы
* не задали "proxy_cache_path" - прокси пока некуда кешировать
* не включили само кеширование директивой proxy_cache 


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: виндовый cgi

[Andrey Kopeyko]

Victor Sudakov писал 2019-03-19 07:22:

Andrey Kopeyko wrote:


> Если бы поставили задачу запустить под Linux/FreeBSD виндовое
> приложение, реализованное как CGI-сценарий в виде .exe файла, как бы вы
> подошли?

Уточните - а сколько rps требуется получить?


Для начала требуется просто запустить в лабораторных условиях.



> Данный виндовый exe-шник работает как cgi из-под виндового Apache, и
> вроде как нормально запускается из Wine.

Если требуется rps < 1 - то прямая схема:

   nginx -> Apache -> CGI -> Wine -> exe

не доставит вам сильных проблем.


Не совсем понятно, где в этой схеме водораздел между Unix и Windows.


А нет водораздела - насколько я понимаю из вашего описания exe и его 
работы под wine, всё реализуемо прямо на хосте с Linux.


Возможно, CGI -> Wine придётся поменять местами...


Имеется в виду виндовый Apache под wine, или... Уточните пожалуйста.


Нет, нативный - он же нужен только как реализация CGI интерфейса.

--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: виндовый cgi

[Andrey Kopeyko]

On Mon, 18 Mar 2019, Victor Sudakov wrote:


Коллеги,


Добрый день, Виктор!


Если бы поставили задачу запустить под Linux/FreeBSD виндовое
приложение, реализованное как CGI-сценарий в виде .exe файла, как бы вы
подошли?


Уточните - а сколько rps требуется получить?


Данный виндовый exe-шник работает как cgi из-под виндового Apache, и
вроде как нормально запускается из Wine.


Если требуется rps < 1 - то прямая схема:

  nginx -> Apache -> CGI -> Wine -> exe

не доставит вам сильных проблем.


--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как сделать бессрочный кеш большого объема?

[Andrey Kopeyko]

tolyan писал 2019-03-10 11:41:
Спасибо за наводку на proxy_store. Задача такая: бэкенд обрабатывает 
урлы,

которые нужно кешировать:
"/svg-to-png/small/:id.png"
"/svg-to-png/images/:id.png"

...


Нет ли тут чего-нибудь неправильного, что можно улучшить?


Если внешним клиентам не требуется ходить на

location /svg-to-png/ {

я бы порекомендовал сделать его внутренним локейшеном.


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx rewrite rule

[Andrey Kopeyko]

On Tue, 15 Jan 2019, dmprog08 wrote:

Как настроить рулзы чтобы когда я вводил такой урл 
http://admin.1851.local/assets/814baced/css/style_v1.css  перенаправляло на

http://admin.1851.local/assets/814baced/css/style.css
http://admin.1851.local/assets/814baced/css/style_v2.css  перенаправляло на
http://admin.1851.local/assets/814baced/css/style.css
то есть просто 
style_v1.css  => style.css

style_v2.css  => style.css



Зачем вам "рулзы"? сделайте надёжно

location ^~ ^/(assets/814baced/css/style)_v(1|2).css {
return 301 http://$host/$1.css;
}


--
Best regards,
Andrey Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: request_time

[Andrey Kopeyko]

On Fri, 28 Dec 2018, inkognito0609 wrote:


Существуют ли какие то средства дебага, на котором этапе происходит
деградация?


Запустите nginx с дебаг-логом и сконфигурите debug_connection
  http://nginx.org/ru/docs/debugging_log.html

В логе будет подробнейшим образом расписано как именно обрабатывался ваш 
запрос.



--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

[Spam] Re: systemd instantiated units - обсудим ?

[Andrey Kopeyko]

On Tue, 18 Sep 2018, Seva Kobylin wrote:

Ну и второй вопрос — а зачем? :-) В моей голове не так много реальных 
примеров, которые требуют запуск нескольких инстансов мастер-процессов nginx 
на одной машине.


Но когда нужно - такой параметризированный unit сильно упрощает жизнь.


Что предлагается сделать?


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

Если мэйнтейнеры откажутся доложить приведённый "nginx@.service" в поставку - 
давайте положим его в contribs/




18 сент. 2018 г., в 13:35, Илья Шипицин  написал(а):

примерно так

[root@xxx ~]# cat /lib/systemd/system/nginx@.service
[Unit]
Description=nginx - high performance web server instance %i
Documentation=http://nginx.org/en/docs/ 
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/var/run/nginx-%i.pid
ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p /etc/nginx-%i -g "pid 
/var/run/nginx-%i.pid;"
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID

[Install]
WantedBy=multi-user.target

это позволяет за счет параметра (который подставляется в %i)создавать 
отдельные инстансы.





--
Best regards,
Andrey A. Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Механизм назначения переменной $ssl session id

[Andrey Kopeyko]

On Sat, 4 Aug 2018, Romano wrote:


И как же они это делают? Пробую соединения через консоль openssl, $ssl
session id не регистрируется,


Ну вот же он:

kaa@AKnb6:~$ echo "" |openssl s_client -connect dev.kopeyko.ru:443 2>/dev/null 
|grep -1 Session-ID:

Cipher: ECDHE-RSA-AES256-SHA
Session-ID: 18BB9A4672CFB2C19D64F156BD1ECA3E9EDDBBE558DCAF79F71CF434537770C9
Session-ID-ctx:
kaa@AKnb6:~$



Этот идентификатор может быть передан через HTTP заголовки?


Нет, не может. Это параметр TLS соединения, устанавливаемого _до_ начала 
работы протокола HTTP.



--
Best regards,
Andrey Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Механизм назначения переменной $ssl session id

[Andrey Kopeyko]

Спаммеры получают его при установлении TLS-соединения.

21 июля 2018 г. 12:18:22 GMT+03:00, Romano  пишет:
>Насколько я понял, значение этой переменой доступно для конфигурации
>сервера
>после получения ssl-сессии из кеша, т.е. как минимум после повторного
>захода
>на сайт.
>
>Вопрос, каким образом спамеры "получают" идентификатор с первого захода
>ранее неизвестных адресов?
>
>Posted at Nginx Forum:
>https://forum.nginx.org/read.php?21,280591,280591#msg-280591
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Простите за краткость, создано в K-9 Mail.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Время записи в лог

[Andrey Kopeyko]

BieZax писал 2018-06-22 11:12:

Добрый день.


Добрый день!


[16/Jun/2018:15:41:15 +0300] "GET /123"  request_time=20.483
upstream_response_time=20.483 upstream_addr=10.10.10.10:80" "200"
"nginx/1.10.1/289427"

Тот же  запрос (это точно) на  следующем  nginx:
2018-06-16T15:40:54+03:00  "GET /123"  request_time=0.031
upstream_response_time=0.031 upstream_addr=unix:/tmp/nginx_news.socket"
"200"


А покажите директиву log_format которой вы логи пишете - подозреваю, что 
там у вас простая опечатка, и вместо upstream_response_time вы 
записываете значение request_time.


Если бы логи писались верно - значение upstream_response_time на первом 
nginx совпадало бы со значением request_time на втором nginx.


Потому что временА записи ответов - примерно соответствуют 
происходящему:

- бэкенд быстро сгенерил ответ
- nginx-2 быстро передал ответ nginx-1 (request_time=0.031)
- nginx-1 затратил 20 сек на отдачу ответа клиенту


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не работает proxy cache lock

[Andrey Kopeyko]

ZZZ писал 2018-06-21 17:43:

Доброго утра!


Добрый день!


Я напоролся на проблему с proxy_cache_lock. Ниже минимальный конфиг, на
который я шлю порядка 150 простых запросов в секунду. Каждые пять 
секунд,
когда инвализируется кеш, на апстрим уходит от пяти до двадцати 
запросов, в

зависимости от времени ответа апстрима,


Вероятно, у вас значения proxy_{connect,send,read}_timeout в 5-20 раз 
меньше времени ответа вашего бэкенда. И цикл

- лочим кеш и отправляем запрос на бэкенд
- запрос таймаутится
успевает повториться несколько раз.


Другая версия - срабатывает proxy_cache_lock_age

Посмотрите по логам - эти лишние запросы отправляются на бэкенд 
равномерно в течение времени его неответа? или "пачкой" после первого 
запроса?



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ipv6 и error 400

[Andrey Kopeyko]

Dmitry Ivanov писал 2018-02-26 13:01:

Добрый день, Дмитрий!


Можно  посмотреть  запрос  полностью,  не  через  лог?


Можно, но по-прежнему в логе - 
http://nginx.org/ru/docs/ngx_core_module.html#debug_connection


Однако, нужно знать IP-адрес логируемого, или хотя бы его сеть.


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Исключить из редиректа

[Andrey Kopeyko]

Set писал 2018-02-12 10:03:

Добрый день.


Добрый день, Set!


Настроен редирект с http на https.
server {
server_name example.com example.com;
listen 127.0.0.1:80;
return 301 https://example.com$request_uri;
}
Вопрос, как отменить редкирект для определенного локейшина (не 
редиректить

на https)? Отдавать локеишин по http.


Довольно просто
- вам надо описать этот location
- и не конфигурить в нём редирект.
- если отдавать нужно с локального диска - сконфигурите root



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Объём отданного запроса с учётом SSL- overhead'а

[Andrey Kopeyko]

Александр Николаев писал 2017-12-13 11:15:

Добрый день.


Добрый день, Александр!


Есть задача - сохранять в лог-файл
полный объём ответа на запросы,


Тут дело такое: до того момента как полностью установится TLS-соединение 
- никакого запроса ещё нет. Т.е. измерять пока нечего, и в этом смысле - 
nginx действует правильно.



как минимум с учётом затрат на SSL при HTTPS.

 $_bytes_sent__ _ -  содержит число байт,
переданное клиенту, по HTTP (т.е.
тело+заголовки), но не учитывает
расходы трафик на транспорт (SSL, TCP/IP)


Значит, на транспортном уровне и надо мерять.
Например, считать объём минутного TCP-трафика на порту и вычитать из 
него сумму значений $bytes_sent за ту же минуту.


Правда, в этом случае вы потеряете разблюдовку по IP-адресам и по 
клиентам.




как получить желаемый результат с nginx'ом?


Расскажите, пожалуста, по-подробнее - а для чего такая инфа 
нужна\полезна?
может, эту вашу задачу окажется возможным решить каким-то другим 
способом?




--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Изменить стандартную страницу 400 Bad Request

[Andrey Kopeyko]

Set писал 2017-12-12 15:58:

2. Ошибка вызвана большим размером заголовка Cookie  (Request Header Or
Cookie Too Large).


В этом случае вам надо увеличивать размер буфера (начните с удвоения 
его) директивы "large_client_header_buffers"

http://nginx.org/ru/docs/http/ngx_http_core_module.html#large_client_header_buffers

--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Изменить стандартную страницу 400 Bad Request

[Andrey Kopeyko]

Set писал 2017-12-12 13:07:


Страница из браузера видна. Но при наступлении ошибки. Отдается, почему 
то
стандартная страница 400 Bad Request. Должна отдаваться страница 
которую я

заменил.


1. Включите настоящий debug log
-- недостаточно задать уровень "debug" в директиве "debug_log", нужно 
запускать собранный с поддержкой отладки бинарник - 
http://nginx.org/ru/docs/debugging_log.html

-- задайте директиву debug_connection для отсечения лишнего шума в логе

2. Добейтесь наступления ошибки

3. Читайте в логе как именно шла обработка ошибочного запроса; из лога 
будет понятен контекст, в котором произошла ошибка.


4. Подправьте конфиг.

5. Повторяйте пункты 2-4

6. Выключите debug log


P.S.
Если нужна помощь - обращайтесь в почту.

--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Изменить стандартную страницу 400 Bad Request

[Andrey Kopeyko]

Set писал 2017-12-12 11:58:


В access логах:
127.0.0.1 - [12/Dec/2017:11:24:25 +0300] "GET / HTTP/1.1" 400 644
"http://localhost; "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/ Safari/537.36" "-"

Ссори опечатка. Сама страница из браузера доступна.


Если из браузера видна ровно та страница ошибки, которую вы заменили, - 
разве это не есть решение вашей проблемы?



P.S.
Мне тут интересно другое - как вы _браузером_ ухитрились невалидный 
запрос сделать?
Вероятнее всего, запрос вы делаете скриптом, задавая похожий на истину 
заголовок "User-Agent".




--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Изменить стандартную страницу 400 Bad Request

[Andrey Kopeyko]

On Tue, 12 Dec 2017, Set wrote:


Спасибо за развернутый ответ. Но всё-таки у меня не получается изменить
стандартную страницу.

Пробовал вставлять в сервер по умолчанию и в секцию http (nginx.conf)
страница 400 Bad Request не меняется.


Ровно в этом месте - нужно читать логи. Там будет написано, что таки у вас 
происходит.




Как тест сделал страницу /usr/share/nginx/html./400.html


Вот эта точка в пути - это опечатка, или вы и в самом деле создали каталог 
"html."?



--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Размер исполняемого файла.

[Andrey Kopeyko]

Gena Makhomed писал 2017-10-22 16:31:

On 22.10.2017 16:18, supermicro wrote:


Перекомпилировала с ключом --with-debug, тоже было не сложно :)


Но как мне узнать, какой именно файл был показан?

Эта информация пишется в error.log на уровне debug.

Очень много лишнего туда пишется, для продакшна не очень подходит.
Есть ли другие варианты?


Есть. Например, можно пропатчить файл
src\http\modules\ngx_http_random_index_module.c
чтобы он выводил в лог нужную Вам информацию не на уровне debug.


Это вредный совет.

Правильнее будет -- выделить нужное в отдельный location и включать 
уровень debug только там.


location /test/random/ {
  ...
  error_log /path/to/error.log debug
}


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Proxy_cache

[Andrey Kopeyko]

demolitionman писал 2017-10-07 14:46:
Доброго дня комрады! С Ngnix знаком неделю, сроки горят. Настраиваю 
связку

nginx+gunicorn+memcached+postgresql+Django
Уперся в одну задачу, пол дня ковыряю ни как решение найти не могу.
Задача такая есть два сервера nginx1 nginx2, необходимо что бы первый 
сервер

кэшировал объекты (медиафайлы, картинки) на втором, а второй сервер
кэшировал на первом.
Как создать локальный кэш я разобрался, а как заставить кэшировать на 
другой

машине ни как понять не могу,


А зачем? какую проблемы вы хотите этим решить?

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


Если это двойное вычисление для вас всё-таки дорого - придётся кеш 
усложнить: сервера будут кешировать не у себя, а проксировать на третий 
"центральный" кеш. А на случай его падения - бэкапом иметь свой 
локальный кеш, синхронизируемый rsync-ом с центрального.


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



Есть идея просто при монтировать диру с другого сервера. Но почему то
кажется что в Ngnix это делается по другому. Подскажите личным примером 
либо

статьей из гугла.

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

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


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

ngx_http_mirror_module в стабильной версии

[Andrey Kopeyko]

Добрый день, товарищи!

Вопрос к сотрудникам компании NGINX, Inc - в какие, примерно, сроки 
можно ожидать появления модуля ngx_http_mirror_module в стабильной 
версии nginx? Случится ли это до НГ?


Спрашиваю потому, что функционал этот зело полезен в запускающемся 
проекте, но одновременно есть жёсткое требование "использовать только 
стабильную ветку".


Если до НГ модуль не попадает в стабильную версию - будем искать другие 
варианты...


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Что оставит в логах nginx при потере связи между сервером и клиентом

[Andrey Kopeyko]

Анатолий Кирсанов писал 2017-09-07 00:36:
Удивлен. На уровне server логи прописаны. В location они уже не 
наследуются?


Они наследовались бы, если бы вы не переопределили access_log в location 
@fallback (где обработка запроса и логирование его результатов и 
происходят).




06.09.2017 21:17, Maxim Dounin пишет:



Как такое возможно?

Если говорить про конкретный конфиг, который вы привели в исходном
письме, то в нём отключены access-логи для обращений к бекенду.



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_cache_valid any 0; игнорируется

[Andrey Kopeyko]

Alex Domoradov писал 2017-06-22 15:25:

У вас формат директивы неверный -

последний параметр должен быть иметь
размерность времени, а у вас - просто
число.

а разве в таких случаях не
подразумеваются секунды по дефолту?
Как в случае с тем же proxy_send_timeout 180s ==
proxy_send_timeout 180.


Да, Вы правы - это я подзабыл.

Сам я всегда задаю единицы измерения - вот и обратил внимание на 
"неверность формата" ;-(



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_cache_valid any 0; игнорируется

[Andrey Kopeyko]

Sergey Kagansky писал 2017-06-22 11:20:

Добрый день.


Добрый день, Сергей!


Столкнулся с непонятной ситуацией.
Есть такой конфиг:

proxy_cache_path /data/cache/nginx/cache levels=1:2 keys_zone=all:32m
max_size=1g;

 location / {
   proxy_cache  all;
   proxy_cache_valid 404 5m;
   proxy_cache_valid any 0;
  
 }

Требуется кешировать ТОЛЬКО 404 ответы,
но нгинкс игнорирует строку
proxy_cache_valid any 0;
Что может приводить к этому? Или как это отловить?


У вас формат директивы неверный - последний параметр должен быть иметь 
размерность времени, а у вас - просто число.

Об этом наверняка была ругань в error.log


Не совсем понятно что именно вы хотите этой директивой сказать? если вам 
надо кешировать только 404-е ответы, то достаточно будет одной директивы


proxy_cache_valid 404 5m;


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx как SSL клиент

[Andrey Kopeyko]

Dothris писал 2017-05-01 12:05:

Добрый день!


Добрый день, Dothris!


В логах Nginx

2017/05/01 08:32:06 [error] 27245#0: *7 SSL_do_handshake() failed (SSL:
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:SSL 
alert
number 48) while SSL handshaking to upstream, client: 
ip-backend-server,

server: server-in-inet, request: «POST / HTTP/1.1», upstream:
"https://IP-adres-server-in-inet:443;, host: «server-in-inet»

Почему то upstream: "https://IP-adres-server-in-inet:443; в виде IP 
сервера,

а должен быть в виде Hostname.


Потому что ваше имя "server-in-inet" может разрешаться в несколько 
адресов, и в логе nginx точно указывает к какому именно IP он стучался.



--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Редирект с одного порта на другой

[Andrey Kopeyko]

alexandre_frolov писал 2017-04-18 08:34:
Нужно сделать так, чтобы HTTPS-сайт открывался и через стандартный порт 
443,

и через нестандартный, например, 8082. Подскажите, пожалуйста, можно ли
сделать нужный редирект с помощью nginx, и каким образом?


Добрый день, Александр!

Если вам нужны оба порта - то редирект не понадобится:

server {
listen  443 ssl;
listen  8082 ssl;
server_name www.example.com;
...
}


Если вам надо "собирать" всех на каком-то одном порту - понадобится 
описать 2 сервера:


server {
listen  443 ssl;
server_name www.example.com;
...
}
server {
listen  8082 ssl;
server_name www.example.com;
location / {
rewrite  ^/(.*)$  https://www.example.com/  permanent;
}
}


--
Best regards,
Andrey A. Kopeyko 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Сначала отдать браузеру однопиксельный гиф, а потом подумать

[Andrey Kopeyko]

Привет, Влад!

Возможно, тебе поможет post_action в этом location.


14 марта 2017 г. 23:54:25 GMT+03:00, Vladislav Shabanov 
 пишет:
>Добрый день.
>
>Есть location, на котором сейчас отдаётся empty_gif. 
>
>Мне нужно вызвать в этом месте демона через uwsgi, чтобы демон
>обработал событие и что-то записал в БД. Не хочется заставлять браузер
>ждать окончания всей этой обработки. Как настроить nginx чтобы uwsgi
>вызывался после того, как браузеру будет отправлен однопиксельный гиф?
>Ответ от uwsgi нужно ждать N миллисекунд и выбрасывать, нам всё равно,
>он успешно будет обработан или сломается. 
>
>Можно ли такое сделать штатными средствами?
>
>С уважением,
>   Влад
>
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Простите за краткость, создано в K-9 Mail.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: подстановка переменных в имя апстрима.

[Andrey Kopeyko]

On Wed, 1 Mar 2017, syswipe wrote:


вариант. но в этом случае, если двести виртхостов будут иметь по два
локейшена /moduleN, а один - сотню, то в common придется засунуть 100
сгенерированных локейшенов.


нет в этом проблемы, никакой.


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: подстановка переменных в имя апстрима.

[Andrey Kopeyko]

On Wed, 1 Mar 2017, syswipe wrote:


Добрый день!


Добрый день!


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

...

проблема в том, что количество таких схожих локейшенов может расти и
хотелось бы конфиг свернуть.

...

как это сделать по уму?


Генерите ваш конфиг.

ansible и его шаблоны - годный инструмент для этого.


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Подключение модуля ngx http upstream module

[Andrey Kopeyko]

On Tue, 27 Dec 2016, Vvedensky wrote:


log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for" '
 '$upstream_addr "$upstream_response_time"';

root# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

66.249.93.45 - - [27/Dec/2016:15:52:17 +0500] "GET /products HTTP/1.1" 301
185 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P)
AppleWebKit/537.36 (KHTML, like Gecko; Google Page Speed Insights)
Chrome/27.0.1453 Mobile Safari/537.36" "178.20.235.164" "-"
94.77.88.169 - - [27/Dec/2016:15:54:21 +0500] "GET /products HTTP/1.1" 301
185 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36" "-" - "-"
94.77.115.174 - - [27/Dec/2016:15:54:22 +0500] "GET / HTTP/1.1" 301 185 "-"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/39.0.2171.95 Safari/537.36" "-" - "-"
178.20.235.164 - - [27/Dec/2016:15:54:22 +0500] "GET /robots.txt HTTP/1.1"
301 185 "-" "RookeeBot" "-" - "-"
66.249.93.43 - - [27/Dec/2016:15:54:23 +0500] "GET /products HTTP/1.1" 301
185 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P)
AppleWebKit/537.36 (KHTML, like Gecko; Google Page Speed Insights)
Chrome/27.0.1453 Mobile Safari/537.36" "178.20.235.164" - "-"
163.172.67.180 - - [27/Dec/2016:15:54:34 +0500] "GET / HTTP/1.1" 301 185 "-"
"Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" "-" -
"-"

Вот что получилось. То пишет адрес, то нет. Не понятен результат.


Вы неверно интерпретировали результат - upstream_addr не написан ни одной из 
вышеприведённых строк.


В первой строке - значение адреса в кавычках, а ваш формат лога постулирует 
что $upstream_addr должна быть записана без окружающих кавычек; вероятнее 
всего это значение "$http_x_forwarded_for", залогированное умирающим 
рабочим процессом, работающим ещё со старой конфигурацией, без логирования 
$upstream_addr




--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Что еще можно добавить или исправить с точки зрения настройки SSL

[Andrey Kopeyko]

On Mon, 19 Dec 2016, Maksim Kulik wrote:


10m = 10 мегабайт, а не 10 минут.


;-)

Не проснулся, пойду ещё кофе заварю...


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Что еще можно добавить или исправить с точки зрения настройки SSL

[Andrey Kopeyko]

On Mon, 19 Dec 2016, vitcool wrote:


начинаю разбираться с настрйоками HTTPS под nginx, подскажите пожалуйста,
что тут можно поправить?

...

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 5m;


Зачем вы кешируете SSL-сессию на 10 минут, если валидна она будет только 5?

ИМХО, эти значения должны совпадать.


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: resolver: A vs AAAA

[Andrey Kopeyko]

On Thu, 15 Dec 2016, Dmitry Sivachenko wrote:


Да, я это понял.  Я не предлагаю менять существующее поведение.


Но случай, когда у имени есть ровно два адреса (один A, второй ), не 
предполагает балансировки между ними, это обычно одна и та же машина, 
просто в поддержкой и ipv4, и ipv6.


Друшгими словами? Вы предлагаете внести в nginx зачатки ИИ - чтоб он сам 
угадывал ваши задумки.


Это плохая идея - он не угадает.

И было бы удобно уметь в конфиге указывать, что балансировать нагрузку 
между этими адресами не нужно (и определить, какой именно из двух адресов 
использовать).


Если вам надо предпочитать именно один из адресов хоста - сделайте отдельную 
запись в DNS и проксируйте на неё.


host-v6  IN  A  127.0.0.2


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очередной вопрос nginx+php

[Andrey Kopeyko]

Добрый день, Ivan!

On Fri, 25 Nov 2016, IvanMiller wrote:


Ну хорошо так хорошо, вот толко что делать с теми файлами, что под маску не
попадают, Nginx их начинает тупо выдавать без обработки.


Тут есть 3 варианта
- расширить маску, чтобы и они попадали
- сделать дефолтный location, в котором отвечать 404
- удалить лишнее из DocumentRoot \ с сервера

У каждого - есть и плюсы и минусы.

--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu)

[Andrey Kopeyko]

On Thu, 24 Nov 2016, webne...@gmail.com wrote:


Доброго времени суток.
Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб.
Прописал   client_max_body_size 900m и в server и http и даже в location.
Рестарт nginx пробую загрузить файл и ошибка:
2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too
large body: 174579043 bytes, client: 192.168.10.10, server: localhost,
request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96",
referrer: "http://192.168.11.96/wp-admin/media-new.php;

Что не так делаю, подскажите пожалуйста.


Добрый день!

Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему max 
body size.


Или же заливать видеофайлы по scp\ftp.





--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: HTTPS отдавать 444 в секции default

[Andrey Kopeyko]

On Thu, 28 Jul 2016, Maxim Dounin wrote:


On Thu, Jul 28, 2016 at 01:55:07PM +0300, Andrey Kopeyko wrote:


Как вы хотите - так не бывает.


Бывает.  В принципе в callback'е по SNI можно и просто соединение 
закрыть, но это программировать надо.


Макс, вот это я и подразумевал, говоря "так не бывает" - с существующим 
кодом такого не бывает.



А прямо сейчас можно 
указать "ssl_ciphers aNULL;" в нужном блоке server{}, эффект будет 
тот же.


А вот такого хака я не знал. ;-)


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Валидация кэша на Nginx

[Andrey Kopeyko]

On Sat, 4 Jun 2016, Steven3009 wrote:

Добрый день, Steven!


Но проблема с тем, что статика не обновляется в браузере при загрузке
страниц - остается.
Пример: я изменил СSS, залил на сервер. Естественно, у файла другой
Last_modified и Etag, но сколько я бы не перемещался по сайте, браузер не
хочет обновлять стиль.


Чудес не бывает. Выкладывайте новый стиль под новым именем, и обновляйте 
ссылки на него - и настанет вам счастье.



--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NGiNX в качестве сервера за закачивания файлов

[Andrey Kopeyko]

On Thu, 21 Apr 2016, Dimka wrote:


Всем привет!


Добрый вечер!


Хочу использовать NGiNX для закачивания файлов на сервер.
При этом не хочется использовать сторонние модули или скрипт на бекенд
сервере.


Используйте модуль DAV - 
http://nginx.org/en/docs/http/ngx_http_dav_module.html



проблема что нельзя оставить оригинальное имя файла


Примерно вот так должно сработать:

$ curl -T source.file http://host/path/to/destination.file


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Относительный путь к конфигу и ключ -p

[Andrey Kopeyko]

On Fri, 8 Apr 2016, dmitrz wrote:

у каждого экземпляра nginx одинаковый nginx.conf, но разные 
conf.d/default.conf. Следовательно внеся небольшие изменения в nginx.conf 
придется и для всех остальных это тоже делать


Откройте для себя symlink.


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx fastcgi_cache и Vary headers

[Andrey Kopeyko]

On Wed, 30 Mar 2016, Alex Vasilenko wrote:


Приветствую!


Добрый вечер, Alex!


Есть контент, который кэшируется директивами fastcgi_cache:

...

Цель - кэшировать ответы в зависимости от языка в запросе Accept-Language
Собственно ответ следующего вида:


 ^
Вот тут у вас начинается недопонимание...


Насколько я понял из документации
<http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_valid>
это
должно позволить переопределять и время кэширования и fastcgi_cache_key
будет немного другой и включит в себе хедеры в Vary.


*_cache_key может включать в себя лишь заголовки запроса; вы же хотите 
добавить в него заголовок из ответа бэкенда. Так не получится ;-)




Собственно и Cache-Control и Vary
заголовки игнорируются, кэшируется на минуту с первым попавшим языком.


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


Что я не так делаю?


Вам надо добавить в fastcgi_cache_key заголовок "Accept-Language" из 
запроса, как-то так:


fastcgi_cache_key
"$request_method|$http_if_modified_since|$http_if_none_match|$host|http_accept_language|$request_uri";

Но будьте готовы к разрастанию кеша, потому что запросы к одному URI но с
чуть разными заголовками
  Accept-Language="ru,ru-RU;q=0.7,en;q=0.3"
и
  Accept-Language="ru;q=0.7,en;q=0.3"

создадут 2 разных файла в кеше.


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client timed out & readv() failed

[Andrey Kopeyko]

On Thu, 3 Mar 2016, Vadim Lazovskiy wrote:


Здравствуйте.


Добрый вечер!


Возможно немного не по теме, но возможно кто-то сталкивался.

Есть upstream на nginx раздающий файлы.
Есть frontend на nginx проксирующий и кэширующий их.

Периодически в логах появляются ошибки:

upstream (nginx 1.2.9):
2016/03/03 18:28:57 [info] 16552#0: *190295515 client timed out (110:
Connection timed out) while sending response to client, client: IP, server:
SERVER, request: "GET /URI HTTP/1.0", host: "SERVER", referrer: "REFER"

frontend (nginx 1.9.11):
2016/03/03 18:27:56 [error] 22785#22785: *168191 readv() failed (104:
Connection reset by peer) while reading upstream, client: IP, server:
SERVER, request: "GET /URI HTTP/1.1", subrequest: "/URI", upstream:
"UPSTREAM", host: "SERVER", referrer: "REFER"


ИМХО тут нечего подкручивать - фронтенд ясно говорит, что пользователь 
разорвал соединение в процессе получения ответа. Такое поведение характерно 
для IE и FF при закрытии вкладки. Научить пользователей дожидаться получения 
полного ответа перед закрытием браузера - it's fantastic.



Причем фронтенд рапортует, что ничего не сделать на минуту раньше, нежели
бакенд.

frontend подключен по 10G, примерно 4G исходящего и 2.5G входящего трафика.
backend - port channel из 4 1G линков, недостатка в полосе не имеет.

Кто-нибудь сталкивался с подобными ошибками? С чем может быть связано и что
подкрутить?

Спасибо.




--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вложенный upstream

[Andrey Kopeyko]

On Thu, 26 Nov 2015, Vladimir Stackov wrote:


В моём примере запросы, отправляемые на апстрим-группу "a" не пойдут на "b"
до тех пор, пока "a" не ляжет целиком, а ваш пример подходит лишь в том
случае, если не имеет значения, куда трафик будет проксироваться.


Это дополнительное ограничение, которого не было в вашей исходной задаче ;-)

При таком ограничении - боюсь, вам таки 2 раза проксировать.


P.S.
И, кстати, в вашем конфиге ограничение "сначала А, лишь только затем Б"
будет выполняться только если вы допишете волшебное слово "backup" :

upstream main {
  server 127.0.0.1:8081;
  server 127.0.0.2:8082 backup;
  hash $http_x_key consistent;
}


;-)



26 ноября 2015 г., 0:59 пользователь Andrey Kopeyko <and...@kopeyko.ru>
написал:


On Thu, 26 Nov 2015, Vladimir Stackov wrote:

Есть ли какие-нибудь подходы/патчи, позволяющие nginx'у не проксировать

через себя лишний раз?



Есть. Например, так:

upstream main {
  server 1.1.1.1:8080;
  server 3.3.3.3:8080;
  server 2.2.2.2:8080 backup;
  server 2.2.2.2:8080 backup;
  hash $http_x_key consistent;
}

Что вам мешает перечислить в upstream main все нужные серверы? Судя по
показанной конфигурации, на вирт.серверах на портах 808[12] вы никакой
обработки URI не проводите.



--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru








--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вложенный upstream

[Andrey Kopeyko]

On Thu, 26 Nov 2015, Vladimir Stackov wrote:


Ок, придётся значит чуть-чуть попатчить.

P.S. Вы снова неправильно понял. Апстримы выбираются по http-заголовку
X-Key, а вот внутри вложенного апстрима уже без разницы.


Вы не описали вашу задачу полностью, а приоктрываете кусочки ограничений по 
ходу пьесы; в такой ситуации шанс понять вас правильно - ничтожен.



--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вложенный upstream

[Andrey Kopeyko]

On Thu, 26 Nov 2015, Vladimir Stackov wrote:


Есть ли какие-нибудь подходы/патчи, позволяющие nginx'у не проксировать
через себя лишний раз?


Есть. Например, так:

upstream main {
  server 1.1.1.1:8080;
  server 3.3.3.3:8080;
  server 2.2.2.2:8080 backup;
  server 2.2.2.2:8080 backup;
  hash $http_x_key consistent;
}

Что вам мешает перечислить в upstream main все нужные серверы? Судя по 
показанной конфигурации, на вирт.серверах на портах 808[12] вы никакой 
обработки URI не 
проводите.




--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: запрет фальшивых Googlebot

[Andrey Kopeyko]

On Sat, 10 Oct 2015, Илья Шипицин wrote:


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


Так и есть - большие поисковики регулярно "перепроверяют" проиндексированные 
сайты, заходя из не-своих сетей. Но при этом они строго играют в "тайного 
покупателя" - т.е. полностью отдают все присущие данному UA заголовки и 
никакими специфическими заголовками себя не выдают ;-)




--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: неадекватная работа кеша

[Andrey Kopeyko]

On Fri, 25 Sep 2015, Иван Мишин wrote:

Добрый вечер, Иван!


4.200 3.500 и т.д. это и есть время ответа от бека.

и например вот тут
www.site.ru x.x.x.x - [23/Jul/2015:15:15:14 +0300] "GET /a/b HTTP/1.1"
4.100 " NGINX-CACHE-EXPIRED
www.site.ru x.x.x.x - [23/Jul/2015:15:15:15 +0300] "GET /a/b HTTP/1.1"
0.000 " NGINX-CACHE-HIT

бек обрабатывал 4.100 как видно но следующий запрос уже через 1 сек получил
HIT не смотря на то что по идеи первый запрос еще в кеш не попал


Никакой неадекватности в работе кеша нет - вы просто не учитываете (или 
позабыли) тот факт, что время в лог пишется ровно в момент логирования - 
т.е. _по_окончании_ запроса.


Такое поведение nginx унаследовал от Apache.

В документации этот момент отражён, но вскользь - только при описании 
переменной "$msec"

  http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_format


Поэтому ваши логи показывают, что всё происходит ровно как вами и было 
задумано:

- запрос пришёл в ~ 15:15:09.900
- бэкенд обработал его за 4.100 сек и в 15:15:14 была создана запись в 
логе

- следующий запрос пришёл в 15:15:15 и был отдан из кеша.


P.S.
Наверное, стОит расширить\дополнить описание модуля ngx_http_log, и ещё 
раз явно указать момент логирования при описании переменных

- $time_iso8601
- $time_local

Хуже, по крайней мере, точно не будет.



25 сентября 2015 г., 18:54 пользователь Aleksandr Sytar <
sytar.a...@gmail.com> написал:




25 сентября 2015 г., 17:21 пользователь Иван Мишин <simplebo...@gmail.com>
написал:

Кеш заведен на 20 минут при этом иногда бывает что кеш как-бы не

срабатывает.
Ключи кеша proxy_cache_key $server_name$request_uri
Вот пример из логов адекватной работы:

www.site.ru x.x.x.x - [23/Jul/2015:11:02:32 +0300] "GET /a/b HTTP/1.1"
4.200 " NGINX-CACHE-EXPIRED
www.site.ru x.x.x.x - [23/Jul/2015:11:02:44 +0300] "GET /a/b HTTP/1.1"
0.000 " NGINX-CACHE-HIT

www.site.ru x.x.x.x - [23/Jul/2015:13:11:02 +0300] "GET /a/b HTTP/1.1"
4.200 " NGINX-CACHE-EXPIRED
www.site.ru x.x.x.x - [23/Jul/2015:13:11:02 +0300] "GET /a/b HTTP/1.1"
0.000 " NGINX-CACHE-HIT

www.site.ru x.x.x.x - [23/Jul/2015:15:15:14 +0300] "GET /a/b HTTP/1.1"
4.100 " NGINX-CACHE-EXPIRED
www.site.ru x.x.x.x - [23/Jul/2015:15:15:15 +0300] "GET /a/b HTTP/1.1"
0.000 " NGINX-CACHE-HIT


А вот пример неадекватной работы:

www.site.ru x.x.x.x - [23/Jul/2015:11:15:41 +0300] "GET /a/b HTTP/1.1"
4.000 " NGINX-CACHE-EXPIRED
www.site.ru x.x.x.x - [23/Jul/2015:11:15:46 +0300] "GET /a/b HTTP/1.1"
4.200 " NGINX-CACHE-EXPIRED

www.site.ru x.x.x.x - [23/Jul/2015:12:57:34 +0300] "GET /a/b HTTP/1.1"
3.500 " NGINX-CACHE-EXPIRED
www.site.ru x.x.x.x - [23/Jul/2015:12:57:38 +0300] "GET /a/b HTTP/1.1"
4.100 " NGINX-CACHE-EXPIRED

www.site.ru x.x.x.x - [23/Jul/2015:17:42:33 +0300] "GET /a/b HTTP/1.1"
3.600 " NGINX-CACHE-EXPIRED
www.site.ru x.x.x.x - [23/Jul/2015:17:42:38 +0300] "GET /a/b HTTP/1.1"
4.100 " NGINX-CACHE-EXPIRED



Куда копать?



Добавить логгирование времени ответа бекенеда и понять успевает ли он
ответить за 5 секунд

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





--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Hiring Coder to Make ngx_preload_files

[Andrey Kopeyko]

On Fri, 25 Sep 2015, vbresults wrote:


Send a list of past modules made and a $$$ quote to develop and test this
module.  I will be posting it under my github account for easy access for
myself and anyone else that needs it.  I have a good budget and won't
compromise on the functionality I've requested below.

This module "ngx_preload_files" preloads one or more files on the filesystem
into a single variable.  This can be used for tasks like concatenating
critical css and javascript files and inlining them with a substitution
module, all within Nginx.


Good day, vbresults!

This functionality seems to be already developed by Google.

Please take a look on pagespeed module
  https://developers.google.com/speed/pagespeed/module/config_filters

and study it's documentation on following directives
- combine_css
- combine_javascript
- inline_css
- inline_javascript


--
Best regards,
Andrey Kopeyko <and...@kopeyko.ru>

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

Re: Наследование fastcgi_param

[Andrey Kopeyko]

23.06.2015 19:56, Amanda Sproule пишет:

Здравствуйте.


Добрый вечер!


Имеется такая тестовая конфигураци.

server {
 
 root   /www;
 index  index.html index.php;

 includefastcgi_params;
 fastcgi_index  index.php;

 location /info {
 fastcgi_param SCRIPT_FILENAME /www/info.php;
 fastcgi_pass 127.0.0.1:9000 http://127.0.0.1:9000;
 }
 ..
}

Проблема в том, что в локейшене /info не наследуются fastcgi_param
(все), указанный в контексте server,  если происходит переопределение
одного fastcgi_param параметра внутри локейшена. PHP-FPM возвращает код



В документации описан момент

Директивы наследуются с предыдущего уровня при условии, что на данном
уровне не описаны свои директивы |fastcgi_param|.


выходит если я переопределяю (устанавливаю) какой-либо fastcgi_param
параметр, то наследования fastcgi_params вовсе отменяется?


Ну да.

Сделайте вот так

 server {
  
  includefastcgi_params;
  fastcgi_index  index.php;

  location /info {
  fastcgi_param SCRIPT_FILENAME /www/info.php;
  include   fastcgi_params;
  fastcgi_pass  127.0.0.1:9000 http://127.0.0.1:9000;
  }
  }

и наступит счастье.






--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Proxy без редиректов, скрытая переадресация

[Andrey Kopeyko]

17.05.2015 19:54, billgx пишет:


location /(.*) {
   set $download_url $1;
   error_page 301 302 =200 @redir;
   proxy_pass $download_url;
   proxy_redirect off;
}

   location @redir {
 resolver 8.8.8.8;
 set  $redirect  $upstream_http_location;
 proxy_pass  $redirect;
}


Судя по конфигу, вы хотите построить squid.

Не получится. Потому что nginx совсем для другого предназначен.






--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Location для php скрипта с параметрами

[Andrey Kopeyko]

31.03.2015 09:03, Иван Мишин пишет:

Добрый день!


Добрый день, иван!


Есть сайт где переход по страничкам осуществляется с помощью дерганья
php скрипта с различными параметрами.
Например /index.php?param1=aparam2=bparamN=N
Мне надо повесить auth_basic на определенные странички, то есть на
запуск php скрипта с определенными параметрами. Как это реализовать?
Я так понимаю что надо создать определенный локейшн и на него навесить
авторизацию, но как в этом локейшене описать php скрипт с определенными
параметрами?


Вам надо описать 2 локейшена

- в оном вы обрабатываете *.php
-- и при отпределённых параметрах - делаете внутренний редирект на 
второй локейшен


- второй локейшен помечен internal, и в нём вы требуете аутентификацию 
пользователя.








--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Nginx + Android + ssl = 400

[Andrey Kopeyko]

28.02.2015 12:10, ingtar пишет:

Доброго дня! Столкнулся с непонятной проблемой, не могу даже локализовать.
Настраиваем на фронте доступ к сайту по ssl сертификатам (Публикуем Exchange
и как фронтенд - nginx)
Соответственно доступ с мобильных устройств идет на локейшен
Microsoft-Server-ActiveSync. Сгенерировали CA, клиенский сертификат и
установили его на Андроид и на iPad. На втором работает, на первом дает
ошибку 400 - обращение без сертификата.
Как смог повторил состав ПО на тестовом фронте - работает и на Андройде.
Причем что необычно - запросы от андройда на проблемном фронте падают не в
лог для этого локейшена , а в основной лог для этого сайта (падают в
exchange.example.com_main_access.log, а не в
exchange.example.com_sync_access.log, листинг конфига ниже)


По-видимому, вы не попадаете в описывающую location регулярку - 
смотрите в логе куда именно он ломится, и корректируйте regexp.


...


 location ~* ^/Microsoft-Server-ActiveSync(.*) {
proxy_buffer_size 32k;







--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Nginx + Android + ssl = 400

[Andrey Kopeyko]

28.02.2015 21:27, ingtar пишет:

В error логах - только такая строчка с debug:
2015/02/28 20:49:35 [info] 20623#0: *178128083 client sent no required SSL
certificate while reading client request headers,


Вы внимательно прочитали строчку выше? Что она вам говорит?

Мне она говорит - что надо прекращать копать nginx.
Проблема в настройках или в фичах вашего клиента.


P.S.
Предположу, что конфигурация второго вашего nginx отличается отсутствием 
директивы

ssl_verify_client on;


--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Nginx + Android + ssl = 400

[Andrey Kopeyko]

28.02.2015 17:41, ingtar пишет:


На момент ошибки в логах вот такой запрос:

exchange.example.com 111.111.11.111 - u...@example.com [28/Feb/2015:17:36:19
+0300] OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1 400 246 -
Android/5.0.2-EAS-2.0 - upstream - status:- time: -NONE - -
Смущает то, что на iOS все работает


Смотрите, что шлёт яблочный клиент - предположу, что таки другое.

И гляньте в error_log - там будут подробности про ошибку.


и этот же же конфиг на другом сервере тоже работает.


Включите debug на обоих серверах 
(http://nginx.org/ru/docs/debugging_log.html и 
http://nginx.org/ru/docs/ngx_core_module.html#debug_connection), 
сделайте по 1 запросу, и тщательно изучайте\сравнивайте отладочные логи 
- и разница должна вам открыться.



--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: geoip

[Andrey Kopeyko]

19.02.2015 08:30, slyab пишет:

Приветствую, вопрос не по nginx, но посоветовали сюда обратиться. Поэтому
сразу извиняюсь за оффтоп.

Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается? Вопрос
в следующем, некоторые сервисы, в частности www.2ip.ru используют этот адрес
(по крайней мере мне они сказали туда писать) для геоопределения ip-адресов.
Но вот беда - писал в почту, на форму на сайте, и cюда
http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.


У меня для вас плохие новости ;-(

По агентурным сведениям, весь отдельчик, который занимался в том числе и 
ipgeobase.ru, поувольняли... Т.е. просто некому реагировать на ваши 
обращения.








--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: geoip

[Andrey Kopeyko]

19.02.2015 13:59, Anton Yuzhaninov пишет:

On 02/19/15 08:30, slyab wrote:

Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается?
Вопрос
в следующем, некоторые сервисы, в частностиwww.2ip.ru  используют этот
адрес
(по крайней мере мне они сказали туда писать) для геоопределения
ip-адресов.
Но вот беда - писал в почту, на форму на сайте, и cюда
http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.


Данные обновляются (возможно в автоматическом режиме) - diff файлов
скачанных в разное время не нулевой. С обратной связью у них хуже, можно
разве что поискать людей лично знакомых с сотрудниками nic.ru


Да, напишите на i...@nic.ru или даже позвоните им голосом - думаю, 
отреагируют.


Как бывший сотрудник Ру-Центра, попробую ткнуть в эту проблему кого-либо 
из старых коллег... Но без гарантий.





--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: geoip

[Andrey Kopeyko]

19.02.2015 23:21, Andrey Kopeyko пишет:

19.02.2015 13:59, Anton Yuzhaninov пишет:

On 02/19/15 08:30, slyab wrote:

Кто-нибудь в курсе, сервис ipgeobase.ru кем-то сейчас поддерживается?
Вопрос
в следующем, некоторые сервисы, в частностиwww.2ip.ru  используют этот
адрес
(по крайней мере мне они сказали туда писать) для геоопределения
ip-адресов.
Но вот беда - писал в почту, на форму на сайте, и cюда
http://blog.ipgeobase.ru/?cat=36, никакой реакции. Благодарю.


Данные обновляются (возможно в автоматическом режиме) - diff файлов
скачанных в разное время не нулевой. С обратной связью у них хуже, можно
разве что поискать людей лично знакомых с сотрудниками nic.ru


Да, напишите на i...@nic.ru или даже позвоните им голосом - думаю,
отреагируют.

Как бывший сотрудник Ру-Центра, попробую ткнуть в эту проблему кого-либо
из старых коллег... Но без гарантий.


Коллеги отозвались в ФБ - но не могут идентифицировать ваш запрос. 
Помогите им - 
https://www.facebook.com/andrey.a.kopeyko/posts/543147882491684







--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Передресация с http на https://

[Andrey Kopeyko]

30.12.2014 21:51, hitarcher пишет:

а можете сделать пример на базе конфига который я указал ?


Молодой человек,

вам _подсказали_ как можно решить вашу проблему. Это - всегда бесплатно, 
и с удовольствием. Но - не более того.


Но если вам этого недостаточно, и вы хотите чтобы кто-то _написал_ 
конфиг _за_вас_ - вы так и скажите: есть проблема такая-то, денег за 
решение предлагаю столько-то, желаемый срок решения такой-то. Получите 
несколько предложения на почту, выберете исполнителя, договоритесь и 
получите желаемый результат.


Выклянчивать же _решение_ в рассылке, не читая \ не перечитывая доки по 
получении подсказок, да ещё под Новый Год (когда голова у всех занята 
совсем другим) - малоперспективное занятие, на мой скромный взгляд.







--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Всем: Платная опция и невозможность использования Nginx под Windows

[Andrey Kopeyko]

17.12.2014 22:08, sofiamay пишет:

Maxim Dounin Wrote:
---

Hello!

On Wed, Dec 17, 2014 at 12:31:01PM -0500, sofiamay wrote:

Если же хочется, чтобы было совсем хорошо, т.е. полноценной и
эффективной работы - то, как уже было сказано, имеет смысл
переходить на unix-системы


Вот именно что полноценной. Такой же как и на Linux. В общем налицо ярая
дискриминация Windows пользователей и нежелание разработчиков шевелится в
этом направлении. Я вас услышал и понял.


Молодой человек,

вот тут у вас ошибочка - вы услышали и поняли всего лишь голоса в 
вашей голове.




потому что в Nginx
давно всё есть для полноценной работы в Windows с PHP.


Вот тут у вас логическое противоречие - если давно всё есть для 
полноценной работы, тогда о какой проблеме вы говорите??




Достаточно
разблокировать одну опцию,


Вот здесь вы демонстрируете свой непрофессионализм.


и
она есть, просто заблокирована разработчиками.


Это опенсорс, молодой человек, и у вас есть ровно 2 (два) пути решения 
вашей проблемы:


1) разобраться в потрохах и написать\допатчить самому

2) нанять компанию nginx.com для доработок под ваши нужды.

Но вы упорно выбираете третий путь - нытья о заговоре против Винды. На 
этом пути - решения вашей проблемы точно нет.







--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Каким образом можно заставить nginx возвращать заголовки Last-Modified и If-Modified-Since?

[Andrey Kopeyko]

10.11.2014 00:14, greenh пишет:

Если я все правильно понял, то указанные заголовки возвращаются исходя
из даты изменения файла. Поскольку пхп возвращает динамический контент,
то такой информации у nginx нет и быть не может, и соответственно,
ответственность за заголовки лежит на бекенде


Вечер добрый!

Да, вы всё правильно поняли.

Плюс ко всему, If-Modified-Since: - это заголовок _запроса_, поэтому 
ожидать его от сервера nginx несколько неправильно.




--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: proxy cache purge Или каким способом лучше почистить одну запись в кеше

[Andrey Kopeyko]

25.09.2014 00:12, Dimka пишет:

На форуме и в сети много обсуждений на тему как почистить одну конкретную
запись в кэше.



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



Вопрос экспертам - насколько вариант с жестким удалением файла из кэша
кривой?


Доброй ночи, Dimka!

Это вполне рабочий вариант - в нашем вьетнамскои поиске http://wada.vn/ 
мы первое время именно так кешировали XML'ки с результатами вычисления 
поисковых запросов.


Директиву open_file_cache выставили в off - и замечательно удаляли 
некоторые ответы прямо из каталога кеша (скриптом по крону вычищались 
наполные\неверные ответы).


Успешно дожили до 600 запросов в секунду - когда был запущен более умный 
WebDAV-кеш.




--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: [nginx-ru-announce] nginx-1.7.4

[Andrey Kopeyko]

05.08.2014 17:56, Maxim Dounin пишет:

Изменения в nginx 1.7.4   05.08.2014



Привет, Макс!


 *) Исправление: запросы могли зависать, если использовался resolver и
DNS-сервер возвращал некорректный ответ; ошибка появилась в 1.5.8.


А когда это исправление войдёт в стабильную ветку 1.6 ?

Остальные исправления вошли в 1.6.1, а это - почему-то нет...



--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: не работает балансировщик

[Andrey Kopeyko]

23.05.2014 14:45, neomag пишет:

Добрый день


Добрый день!


имеется следующая конструкция:

proxy_pass http://balancer;

upstream balancer {
server 127.0.0.1:8080 max_fails=10 fail_timeout=20 weight=100 ;
server 192.168.1.15:8080 max_fails=10 fail_timeout=20 weight=100 ;
server 192.168.1.20:8080 max_fails=10 fail_timeout=20 weight=30 ;
ip_hash;
}


в результате трафик идет на 127.0.0.1 и 192.168.1.15,
но совершенно не хочет идти на 3 сервер:  192.168.1.20


А вы пробовали убрать ip_hash? Без него - тоже трафик не идёт?

Пару раз встречался с таким - значения IP-адресов клиентов были такими 
(ну, вот APNIC так им подсуропил), что при имевшемся числе бэкендов 
алгоритм ip_hash игнорировал один из бэкендов ;-) Пришлось для 
несчастливого бэкенда сделать 2 одинаковых записи - лишь тогда трафик на 
него пошёл.








--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: не работает балансировщик

[Andrey Kopeyko]

23.05.2014 15:29, neomag пишет:

ip_hash убрать не могу, к сожалению  -production
да и качели с сессиями пользователей начнутся


попробовал вариант с умножением записей, даже 3x не помогло

вероятно действительно  дело в ip_hash


Добавьте на бэкенд ещё 1 адрес, но из сети 192.168.2/24 (из 192.168.1/24 
- не поможет)







--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Запретить url и вернуть 404 страницу

[Andrey Kopeyko]

03.05.2014 01:03, fantom2067 пишет:

Здраствуйте. Подскажите пожалуйста, как можно запретить страницы архивов в
Wordpress. Выглядят они следующем образом http://site.ru/2014/03/,
http://site.ru/2014/04/, http://site.ru/2014/05/ тоесть нужно запретить
доступ к старницам за все года и месяца и при обращении вернуть 404
страницу.

В robots.txt это делается так /20**/*/, в nginx сколько не бился над этой
проблемой, не получилось заблокировать url.


Добрый день, fantom2067!

А вам от кого надо архивы защитить?

robots.txt - позволит защитить лишь от вежливых роботов;
если вам нужно защититься ото всех - вам надо сконфигурить примерно 
такой локейшен:


location ~ ^/20\d\d/\d\d/ {
   return 404;
}

Подробнее прочитайте на
  http://nginx.org/ru/docs/http/ngx_http_core_module.html#location






--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Проблемы с авторизацией

[Andrey Kopeyko]

11.04.2014 11:58, saVIor4815162342 пишет:

Прошелся Wireshark`ом, оказывается, nginx не пропускает пакет с запросом
HTTP668 GET /PSIA/Custom/SelfExt/userCheck HTTP/1.1 - пакет, отвечающий 
за
авторизацию. Как его пропихнуть через проксю,


Вам нужно и этот локейшен проксировать на ваш прибор:

location /PSIA/ {
proxy_pass http://10.100.0.2:88;
}


и с чем может быть связана
такая проблема?


Таков ваш прибор.

Почаще смотрите и в логи, и в tcpdump - чую, открытий будет ещё немало...






--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: один сервер с несколькими сайтами с/без ssl

[Andrey Kopeyko]

11.03.2014 18:24, vaal пишет:

По этому варианту возник дополнительный вопрос.
Например имеется такой конфиг (без лишней инфы)


...


будет достаточно изменить его на


Да, test.ru перестанет отзываться на SSL.


server {
 listen 1.2.3.4:80;
 listen 1.2.3.4:443 ssl;
 server_name  example.com;
}

server {
 listen 1.2.3.4:80;
 listen 1.2.3.4:443 ssl;
 server_name  example.ru;
}

server {
 listen 1.2.3.5:80;
 server_name  test.ru;
}

или возможно есть какие-то подводные камни?


Будет проблема показа правильного сертификата для example.com и 
example.ru : если неумеющий SNI клиент пойдёт на example.ru - ему 
покажут сертификат для example.com. И клиент от такого может обидеться.


Лечится
- либо обретением третьего IP-адреса и отсаживанием на него example.ru
- либо обретением SSL-сертификата на оба эти имени разом. Присмотритесь 
к True BusinessID или UC/SAN от ГеоТраста:

  http://www.geotrust.com/ssl/ssl-certificates/
  http://www.geotrust.com/ssl/ssl-certificates-san-uc/



--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: Nginx не воспринимает server name

[Andrey Kopeyko]

09.03.2014 14:43, yaushev пишет:

Здравствуйте! Я пытаюсь поднять сервер nginx. Использую связку
nginx+uwsgi+django. Вроде как настроил конфиг для проекта, но проблема в том
что открытие сайта в браузере происходит только если вводить ip адрес, а
доменное имя которое я задал в конфиг.файле он не воспринимает.


Добрый вечер!

Убедитесь, что ваше имя mysite.ru разрешается именно в IP-адрес вашего 
сервера. Судя по описанным вами симптомам, оно разрешается в какой-то 
иной адрес - и поэтому вы можете соединиться с вашим сервером лишь введя 
его IP-адрес напрямую в адресную строку браузера.








--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: один сервер с несколькими сайтами с/без ssl

[Andrey Kopeyko]

06.03.2014 16:57, vaal пишет:

Приветствую!

Ситуация.
Один сервер (с одним ip), на котором работает несколько сайтов и только пара
из них имеет и использует SSL сертификаты.
В тоже время к другим сайтам (без ssl) можно обратить по протоколу https -
что приводит к сообщениям/предупреждения в браузере и т.п..

Какие есть способы решения этой проблемы?


Да, конечно : Вам надо получить второй IP-адрес и перенести на него все 
ваши сайты, которым SSL не требуется.







--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: правильный автозапуск nginx в Windows 8.1

[Andrey Kopeyko]

21.02.2014 19:59, Андрей Рогачёв пишет:

Здравствуйте.


Добрый вечер, Андрей!


Скажите, как правильно прописать nginx в автозагрузку Windows 8.1(W8.1)?


Нужно запускать его как сервис, примерно вот так:
  http://letmegooglethat.com/?q=how+to+run+program+as+service


Я прописал через реестр, но запуск не происходит после перезагрузки
W8.1, в W8.1 сначала разворачивается среда где рабочий стол существует
всего лишь как приложение, соответственно, то что я видел раньше это
мгновенно проскакивающее окошечко запуска nginx, ... ему действительно
негде развернуться получается, пока рабочий стол не запущен. В общем не
буду описывать симптомы, с моей то логикой восприятия пользователя.
Прошу подсказать, как правильно прописать nginx в автозагрузку, что бы
сервер запускался после перезагрузки независимо от действий
пользователя. Спасибо.


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




--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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

Re: proxy_pass https

[Andrey Kopeyko]

20.01.2014 20:28, Anton Kiryushkin пишет:

Да, это само собой. На 1-м у меня сейчас так:

 proxy_set_header X-Real-IP $remote_addr;


Тогда на втором сервере должно быть

  set_real_ip_from srv1_ipaddr;
  real_ip_header X-Real-IP;


И смотрите что в логи пишется.

--
Best regards,
Andrey Kopeyko and...@kopeyko.ru

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