Re: announcing freenginx.org

2024-02-15 Пенетрантность Виктор Вислобоков 
С моей колокольни: вечная проблема Open Source проектов - мало активных
разработчиков, потому что бесплатно - с одной стороны. Коммерциализация и
плохой менеджмент проектов, которые НЕ Open Source.

Можно пачку новых freenginx'ов создать, вопрос - хватит ли сил это
разрабатывать и поддерживать?
Сколько разных форков как появились так и пропали спустя пару лет.

чт, 15 февр. 2024 г. в 10:18, 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

Re: ip_hash и адреса клиентов

2023-05-11 Пенетрантность Виктор Вислобоков 
Почитал по ссылке. Никакого упоминания про ip_hash не нашёл. Использование
данного модуля ТОЧНО повлияет на поведение ip_hash?

С уважением, Виктор

чт, 11 мая 2023 г. в 10:22, Vladimir jdwuzhere :

> https://nginx.org/en/docs/http/ngx_http_realip_module.html
>
> > On 11 May 2023, at 08:28, Виктор Вислобоков 
> wrote:
> >
> > Доброго времени суток, коллеги.
> >
> > Вопрос такой. Как написано в документации: ip_hash Задаёт для группы
> метод балансировки нагрузки, при котором запросы распределяются по серверам
> на основе IP-адресов клиентов. В качестве ключа для хэширования
> используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента
> целиком. Метод гарантирует, что запросы одного и того же клиента будут
> всегда передаваться на один и тот же сервер. Если же этот сервер будет
> считаться недоступным, то запросы этого клиента будут передаваться на
> другой сервер. С большой долей вероятности это также будет один и тот же
> сервер.
> >
> > А каким образом определяется IP адрес клиента? Рискну предположить, что
> из $remote_addr? Дело в том, что всё больше и больше сайтов используют
> предварительную защиту от атак, типа ддос-гард, куратор, касперский и т.д.
> Это означает, что  все запросы приходят с одного и того же IP-адреса (или
> пула адресов) сервера, осуществляющего защиту. Да, при этом, обычно
> выставляется заголовок X-Real-IP содержащий фактический IP, но я не нашёл в
> документации упоминаний о том, каким образом можно настроить ip_hash так,
> чтобы он брал IP-адрес клиента из какого-либо заголовка.
> >
> > Кто знает как это сделать?
> >
> > С уважением, Виктор
> > ___
> > 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

ip_hash и адреса клиентов

2023-05-10 Пенетрантность Виктор Вислобоков 
Доброго времени суток, коллеги.

Вопрос такой. Как написано в документации: ip_hash Задаёт для группы метод
балансировки нагрузки, при котором запросы распределяются по серверам на
основе IP-адресов клиентов. В качестве ключа для хэширования используются
первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод
гарантирует, что запросы одного и того же клиента будут всегда передаваться
на один и тот же сервер. Если же этот сервер будет считаться недоступным,
то запросы этого клиента будут передаваться на другой сервер. С большой
долей вероятности это также будет один и тот же сервер.

А каким образом определяется IP адрес клиента? Рискну предположить, что из
$remote_addr? Дело в том, что всё больше и больше сайтов используют
предварительную защиту от атак, типа ддос-гард, куратор, касперский и т.д.
Это означает, что  все запросы приходят с одного и того же IP-адреса (или
пула адресов) сервера, осуществляющего защиту. Да, при этом, обычно
выставляется заголовок X-Real-IP содержащий фактический IP, но я не нашёл в
документации упоминаний о том, каким образом можно настроить ip_hash так,
чтобы он брал IP-адрес клиента из какого-либо заголовка.

Кто знает как это сделать?

С уважением, Виктор
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: .htaccess

2019-05-13 Пенетрантность Виктор Вислобоков 
Не будет. Проверено.

13.05.2019, Evgeniy Berdnikov написал(а):
> On Mon, May 13, 2019 at 09:00:54AM +0300, Виктор Вислобоков wrote:
>> >> Зачем, если пользователь может просто установить Apache?
>> Читайте начальный пост ТС. Он говорил при наличии php-fpm.
>> Связка nginx+apache увы, не даёт той производительности, которую даёт
>> связка nginx+php-fpm.
>
>  Перетащите всю требуху с .htaccess в nginx, и будет он тормозить
>  так же как Апач. :)
> --
>  Eugene Berdnikov
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: .htaccess

2019-05-13 Пенетрантность Виктор Вислобоков 
>> Зачем, если пользователь может просто установить Apache?
Читайте начальный пост ТС. Он говорил при наличии php-fpm.
Связка nginx+apache увы, не даёт той производительности, которую даёт
связка nginx+php-fpm.


13.05.2019, Konstantin Tokarev написал(а):
>
>
> 12.05.2019, 10:35, "Виктор Вислобоков" :
>> По ответу на вопрос - насколько мне известно - нет. Всё ручками,
>> ручками. Но сама тема давно уже назрела, на мой взгляд.
>>
>> Мне кажется пора бы уже nginx'у научиться эмулировать поведение apache
>> и юзать его .htaccess при включении специальной директивы.
>
> Зачем, если пользователь может просто установить Apache?
>
> --
> Regards,
> Konstantin
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: .htaccess

2019-05-12 Пенетрантность Виктор Вислобоков 
По ответу на вопрос - насколько мне известно - нет. Всё ручками,
ручками. Но сама тема давно уже назрела, на мой взгляд.

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

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

12.05.2019, Victor Sudakov написал(а):
> Коллеги,
>
> Много развелось Web-приложений и сайтов, которые очень сильно полагаются
> на код в .htaccess.  Смотришь - а там и RewriteRule, и "Header set...", и
> установка каких-то переменных, и MIME types переопределяются...
>
> Есть какая-то общая теория и рекомендации, как всё это хозяйство
> переносить под nginx, например под php-fpm ?
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> 2:5005/49@fidonet http://vas.tomsk.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_store периодически сохраняет только часть ответа :(

2018-12-03 Пенетрантность Виктор Вислобоков 
Кажется нашёл.
У меня в настройках стояло так, что если файл кэша есть, то отавать его,
если нет, то создавать. Но было ещё одно условие: если запрос POST то не
отдавать, а создавать. Видимо при одновременном приходе GET и POST запросов
ответ писался в один и тот же файл и возникала проблема. Пустил POST
запросы вообще мимо кэша и файл перестал быть фрагментарным.
Спасибо за участие всем, кто ответил! :)

пн, 3 дек. 2018 г. в 08:52, Виктор Вислобоков :

> >> А чем proxy_cache не устраивает ? прокси стор, это больше для "на
> века", а Вы трете его зачемто постоянно
> Куда и что сохраняет proxy_cache знает только сам proxy_cache. Найти
> что-то сохранённое им на диске очень большая проблема, да и посмотреть что
> там тоже не так просто. А в proxy_store можно задать вполне себе понятный и
> человеко-читаемый путь и содержимое тоже вполне себе понятно.
>
> >> У Вас proxy_temp_path и место куда сторится на одном разделе ?
> На одном.
>
> пн, 3 дек. 2018 г. в 00:15, Alexey via nginx-ru :
>
>> 02.12.2018 23:18, Виктор Вислобоков пишет:
>> > Схема такая: nginx(1) -> nginx(2) -> httpd
>> > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store.
>> > Почти работает, но в произвольный момент времени сохраняет на диск не
>> > всю страницу с ответом, а только её часть! Это именно происходит
>> > периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix
>> > у меня то получает фрагмент и ругается на малый размер страницы, то в
>> > следующий повтор всё получает нормально - стоит чистка файлов,
>> > сохранённых proxy_store каждую минуту).
>> >
>> А чем proxy_cache не устраивает ? прокси стор, это больше для "на века",
>> а Вы трете его зачемто постоянно
>>
>> У Вас proxy_temp_path и место куда сторится на одном разделе ? Если на
>> разных, то, скорее всего, пока файл от одного запроса копируется,
>> успевает прийти другой запрос и видя файл на месте его и отдает, ну
>> сколько успело скопироваться на момент второго запроса столько и отдает.
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_store периодически сохраняет только часть ответа :(

2018-12-02 Пенетрантность Виктор Вислобоков 
>> А чем proxy_cache не устраивает ? прокси стор, это больше для "на века",
а Вы трете его зачемто постоянно
Куда и что сохраняет proxy_cache знает только сам proxy_cache. Найти что-то
сохранённое им на диске очень большая проблема, да и посмотреть что там
тоже не так просто. А в proxy_store можно задать вполне себе понятный и
человеко-читаемый путь и содержимое тоже вполне себе понятно.

>> У Вас proxy_temp_path и место куда сторится на одном разделе ?
На одном.

пн, 3 дек. 2018 г. в 00:15, Alexey via nginx-ru :

> 02.12.2018 23:18, Виктор Вислобоков пишет:
> > Схема такая: nginx(1) -> nginx(2) -> httpd
> > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store.
> > Почти работает, но в произвольный момент времени сохраняет на диск не
> > всю страницу с ответом, а только её часть! Это именно происходит
> > периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix
> > у меня то получает фрагмент и ругается на малый размер страницы, то в
> > следующий повтор всё получает нормально - стоит чистка файлов,
> > сохранённых proxy_store каждую минуту).
> >
> А чем proxy_cache не устраивает ? прокси стор, это больше для "на века",
> а Вы трете его зачемто постоянно
>
> У Вас proxy_temp_path и место куда сторится на одном разделе ? Если на
> разных, то, скорее всего, пока файл от одного запроса копируется,
> успевает прийти другой запрос и видя файл на месте его и отдает, ну
> сколько успело скопироваться на момент второго запроса столько и отдает.
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy_store периодически сохраняет только часть ответа :(

2018-12-02 Пенетрантность Виктор Вислобоков 
Схема такая: nginx(1) -> nginx(2) -> httpd
На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. Почти
работает, но в произвольный момент времени сохраняет на диск не всю
страницу с ответом, а только её часть! Это именно происходит периодически и
не зависит ни от IP адреса ни от клиента (тот же Zabbix у меня то получает
фрагмент и ругается на малый размер страницы, то в следующий повтор всё
получает нормально - стоит чистка файлов, сохранённых proxy_store каждую
минуту).

Всю голову сломал - не могу понять что за ерунда!
Судя по логам nginx(2) всегда отдаёт полный ответ.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> нет. на самом деле все сильно зависит от того, что происходит на каждый
запрос внутри php. вполне возможно, что разницей между mod_php и php-fpm
можно просто пренебречь.
Простите, но я же не голословно говорю.
Пытались мы, не один раз пытались, крутили все ручки, делали что только
можно, но php-fpm делает apache+mod_php в разы.
Попробуйте сами, наберите одинаковую конфигуацию на один сайт с тем и этим
и запустите нагрузочное тестирование

20 октября 2017 г., 22:38 пользователь Slawa Olhovchenkov <s...@zxy.spb.ru>
написал:

> On Fri, Oct 20, 2017 at 07:19:59PM +0300, Виктор Вислобоков wrote:
>
> > >> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но
> > скореепо вине сложности правильной настройки последнего под данный
> > микробенчмарк.
> > Не так. nginx+php-fpm НАМНОГО выигрывает у nginx+apache/mod_php, а вот
> > nginx+apache/fastCGI просто выигрывает у mod_php, хотя и ненамного.
> > И выигрывают они не по вине сложности правильной настройки, а потому что
> > mod_php встраивается в апаче, но вся функциональность apache которая
> > обслуживает весь концерт никуда не девается, а она медленная.
>
> нет. на самом деле все сильно зависит от того, что происходит на
> каждый запрос внутри php. вполне возможно, что разницей между mod_php
> и php-fpm можно просто пренебречь.
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но
скореепо вине сложности правильной настройки последнего под данный
микробенчмарк.
Не так. nginx+php-fpm НАМНОГО выигрывает у nginx+apache/mod_php, а вот
nginx+apache/fastCGI просто выигрывает у mod_php, хотя и ненамного.
И выигрывают они не по вине сложности правильной настройки, а потому что
mod_php встраивается в апаче, но вся функциональность apache которая
обслуживает весь концерт никуда не девается, а она медленная.

>> fastCGI даже теоретически не может обогнать встроенное решение просто
потому, что нужны накладные расходы на пересылку данных.
Теоретически не знаю, а на практике обгоняет. По крайней мере на мультиюзер
окружениях и это тоже понятно: ведь apache надо переключать контекст между
раными userid, а fastCGI запускается отдельно для каждого юзвера.


>>В связке nginx+php-fpm как минимум нужно настраивать сам nginx и конфиг
для него, отдельно настраивать php-fpm, соответственно конфиг для него.
Ну а тут надо будет настраивать Unit и конфиг для него, и от конфига php вы
никуда не денетесь, потому как там тоже надо крутить. Без разницы в общем.

>> Для разных пользователей используется один и тот же модуль.
А кто переключает контект userid? Если Unit то на это будут уходить
доп.ресурсы как у apache

>> Насколько я знаю, перезагрузить добавить новый пул или удалить
существующий, без затрагивания процессов, принадлежащих к другим пулам, в
php-fpm невозможно.
Да. Но там где юзер=инстанс, мы можем обойтись перезапуском инстанса юзверя

>> Верно, об этих приседаниях и идет речь.  И вам нужно об этом
позаботиться, продумать и спланировать весь процесс и нигде не ошибиться.
Для этого и придумали chef, ansible и прочее. Чтобы один раз оттестровать и
не ошибиться.

Дискуссию можно сворачивать, ибо спорить можно долго и наверное
безрезультатно. Тем более пока Unit ещё ранняя бета. Поживём-посмотрим как
будет дальше.

20 октября 2017 г., 18:56 пользователь Валентин Бартенев <vb...@nginx.com>
написал:

> On Friday 20 October 2017 18:21:35 Виктор Вислобоков wrote:
> >> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
> >> счет своей архитектуры.
> > Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php,
> так
> > что не вижу за счёт чего.
> > Хочу увидеть сравнительные тесты.
>
> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но скорее
> по вине сложности правильной настройки последнего под данный микробенчмарк.
>
> fastCGI даже теоретически не может обогнать встроенное решение просто
> потому,
> что нужны накладные расходы на пересылку данных.
>
>
> >
> >> Меньше движущихся частей.  Unit требует меньше настройки и приседаний,
> >> чем связка nginx+php-fpm
> > Опять же спорно. Для nginx + php-fpm требует лишь nginx из дистра и
> php-fpm
> > из дистра, нет необходимости дособирать какие-то доп.модули. А конфиги
> для
> > разных версий PHP всё равно будут разными.
>
> В связке nginx+php-fpm как минимум нужно настраивать сам nginx и конфиг для
> него, отдельно настраивать php-fpm, соответственно конфиг для него.
>
> Вам не нужно собирать модули для Unit-а, если вы не собираетесь собирать
> собственных версий php.  Вы также их ставите из дистрибутива.
>
> # apt-get install unit-php unit-python2.7 unit-python3.5 unit-go
>
> И они обновляются вместе с обновлением php/python в дистрибутиве.
>
>
> >
> >> Если вам требуется запускать на php-fpm несколько приложений от разных
> >> пользователей, то вам либо приходится использовать его pool-ы, либо
> >> запускать отдельные независимые инстансы php-fpm.
> >
> > Верно, так и тут придётся дополнительный модуль к Unit собирать и
> > подгружать.
>
>  1. Для разных пользователей используется один и тот же модуль.
>
>  2. Unit сам подгружает модули самостоятельно, для это не нужно ничего
> делать.
>
>  3. Собирать свой модуль нужно только в случаях, когда вы сами собираете
> свой php.
>
>  4. Не забывайте, что отдельный инстанс php-fpm - это ещё отдельный
> слушающий
> сокет и отдельная настройка в nginx под него.
>
>
> >
> >> В первом случае при добавлении, удалении, изменении
> >> пользователя/приложения приходится перезапускать весь рой процессов,
> даже
> >> если остальная конфигурация не претерпела изменений.  Это может быть
> очень
> >> накладно по ресурсам.
> >
> > Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.
> > php-fpm тоже поддерживает reload хотя и не такой гладкий, да и
> > перезапускать нужно будет только один нужный php-fpm
>
> Насколько я знаю, перезагрузить добавить новый пул или удалить
> существующий,
> без затрагивания процессов, п

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> А вообще есть сайты с тысячами SSL-сертификатов, переконфигурованием раз
в минуту и соединениями, живущими сутками, из-за которых в памяти висят
тысячи воркеров.
Согласен, как и есть проекты, которые выносят функциональность nginx на
уровень ядра Linux :)
Специфика проектов бывает разная, кто бы спорил, но я скорее размышляю на
предмет массовости использования Unit.

20 октября 2017 г., 18:26 пользователь Igor Sysoev <i...@sysoev.ru> написал:

> > On 20 Oct 2017, at 18:21, Виктор Вислобоков <corocho...@gmail.com>
> wrote:
> >
> > Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.
>
> В 2002 году я тоже так думал.
>
> А вообще есть сайты с тысячами SSL-сертификатов, переконфигурованием раз
> в минуту и соединениями, живущими сутками, из-за которых в памяти висят
> тысячи воркеров.
>
>
> --
> Igor Sysoev
> http://nginx.com
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
счет своей архитектуры.
Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php, так
что не вижу за счёт чего.
Хочу увидеть сравнительные тесты.

>> Меньше движущихся частей.  Unit требует меньше настройки и приседаний,
чем связка nginx+php-fpm
Опять же спорно. Для nginx + php-fpm требует лишь nginx из дистра и php-fpm
из дистра, нет необходимости дособирать какие-то доп.модули. А конфиги для
разных версий PHP всё равно будут разными.

>> Если вам требуется запускать на php-fpm несколько приложений от разных
пользователей, то вам либо приходится использовать его pool-ы, либо
запускать отдельные независимые инстансы php-fpm.
Верно, так и тут придётся дополнительный модуль к Unit собирать и
подгружать.

>> В первом случае при добавлении, удалении, изменении
пользователя/приложения приходится перезапускать весь рой процессов, даже
если остальная конфигурация не претерпела изменений.  Это может быть очень
накладно по ресурсам.
Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.
php-fpm тоже поддерживает reload хотя и не такой гладкий, да и
перезапускать нужно будет только один нужный php-fpm

>> Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не
требует отдельного менеджмента, в отличии от нескольких независимых php-fpm;
Пока я этого не увидел. Скорее наоборот - на каждую версию php-fpm нужен
отдельный менеджмент Unit'а чтобы поключить соответствующий модуль.

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

>> Если завтра вам понадобится запустить ещё что-то на python, go, ruby,
your language, у вас будет для этого уже знакомый и понятный инструмент.
Вот! Наконец-то вижу сильный аргумент! Согласен. Но пока нам нужен только
PHP, это неважно.

>> Количество выполняемых функций будет расширяться, так что в дальнейшем
Unit сможет стать не только легковесной заменой для php-fpm, но и ряда
других компонентов, которые сейчас приходится использовать и настраивать в
довесок.
Поживём-увидим! Пока что я каких-то очевидных преимуществ, ради которых бы
стоило переходить на Unit не увидел.


20 октября 2017 г., 18:05 пользователь Валентин Бартенев <vb...@nginx.com>
написал:

> On Friday 20 October 2017 17:27:30 Виктор Вислобоков wrote:
> > >> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
> > также, как были бы изолированы отдельные процессы php-fpm, запущенные
> > независимо друг от друга на одной машине.
> >
> > Тогда я пока не вижу никакой выгоды от unit'а в сравнении со связкой
> > nginx+php-fpm.
> >
> [..]
>
> В произвольном порядке:
>
>  - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
>счет своей архитектуры.
>
>  - Меньше движущихся частей.  Unit требует меньше настройки и приседаний,
> чем
>связка nginx+php-fpm.  Просто потому, что вместо нескольких компонентов
>с разными подходами к конфигурации, которые нужно связывать друг с
> другом
>и как-то затем мониторить, обновлять - получается один.
>
>  - Если вам требуется запускать на php-fpm несколько приложений от разных
>пользователей, то вам либо приходится использовать его pool-ы, либо
>запускать отдельные независимые инстансы php-fpm.
>
>В первом случае при добавлении, удалении, изменении
> пользователя/приложения
>приходится перезапускать весь рой процессов, даже если остальная
> конфигурация
>не претерпела изменений.  Это может быть очень накладно по ресурсам.
>
>Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не
> требует
>отдельного менеджмента, в отличии от нескольких независимых php-fpm;
>
>И во всех случаях требуются дополнительные приседания, чтобы обновить
> сам php
>или настройки приложения без потери запросов и просадки
> производительности.
>
>  - Если завтра вам понадобится запустить ещё что-то на python, go, ruby,
> your
>language, у вас будет для этого уже знакомый и понятный инструмент.
>
>  - Количество выполняемых функций будет расширяться, так что в дальнейшем
> Unit
>сможет стать не только легковесной заменой для php-fpm, но и ряда других
>компонентов, которые сейчас приходится использовать и настраивать в
> довесок.
>
> --
> Валентин Бартенев
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> В unit главный процесс сначала форкается, а потом динамически подгружает
нужный модуль, который слинкован с соответствующей версией php/python.
Поэтому можно одновременно запускать разные версии языков.
Эээ... не совсем понял.
А вот этот "нужный модуль" это часть Unit? Если да, то каким образом
достигается его линковка например с разными версиями PHP одновременно? Или
это целый набор "нужных модулей" каждый под нужную нам версию PHP? Если да,
то получается мы должны собрать каждый такой "нужный модуль" для каждой
версии PHP которую планируем использовать?

20 октября 2017 г., 17:29 пользователь Igor Sysoev <i...@sysoev.ru> написал:

> > On 20 Oct 2017, at 17:21, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> >
> > On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
> >
> >>>> Так в таком случае использование unit еще выгоднее: ему не надо
> держать
> >> master-процесс для каждой версии php, не говоря о процессе для каждого
> >> пользователя.
> >> Не представляю как это будет работать.
> >> Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
> >> безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
> >> случае не получится загрузить в один веб-сервер несколько версий этого
> >> модуля.
> >
> > на самом деле загрузить-то получится (наверное, не проверял), а вот
> > активировать нужный для конкретно URL может быть проблемой.
> >
> > впрочем, возможно проблему решит правка сырцов для замены директив
> > php_* на phpXY_*.
> >
> > в любом случае, nginx unit не решает проблему с pear и pecl, например, в
> > случае php (и я не смотрел как он решает проблему с собственно php
> > разных версий).
>
> В unit главный процесс сначала форкается, а потом динамически подгружает
> нужный модуль, который слинкован с соответствующей версией php/python.
> Поэтому можно одновременно запускать разные версии языков.
>
>
> --
> Igor Sysoev
> http://nginx.com
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
также, как были бы изолированы отдельные процессы php-fpm, запущенные
независимо друг от друга на одной машине.

Тогда я пока не вижу никакой выгоды от unit'а в сравнении со связкой
nginx+php-fpm.

20 октября 2017 г., 17:25 пользователь Валентин Бартенев 
написал:

> On Friday 20 October 2017 16:48:31 Slawa Olhovchenkov wrote:
> > On Fri, Oct 20, 2017 at 04:42:54PM +0300, Maksim Kulik wrote:
> >
> > > Так в таком случае использование unit еще выгоднее: ему не надо держать
> > > master-процесс для каждой версии php, не говоря о процессе для каждого
> > > пользователя.
> > >
> > > P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем
> под
> > > каждого пользователя запускать отдельный master-процесс? Достаточно
> ведь
> > > завести для конкретного пользователя свой pool (работающий от имени
> этого
> > > пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
> > > скиньте, плиз, линку на почту где можно подробнее почитать об опасности
> > > запуска одного мастер-процесса для разных пользователей.
> >
> > Это достаточно самоочевидно для любого, кто немного интересуется
> > безопасностью.
> > Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше
> 20+.
> > В общем когда приходит понимание, что программ без ошибок не бывает.
> > Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> > иметь возможность читать конфиг принадлежащий любому пользователю и
> > перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> > некторая дыра, т.к. он получается должен быть рутовым.
> > В модели отдельного мастера на пользователя он после запуска
> > безвозвратно дропает свои привелегии и эта схема в целом меньше
> > подвержена протечкам.
> [..]
>
> Основной процесс Unit-а, который работает от рута, не читает конфигов
> и не взаимодействует с пользователями и их приложениями.
>
> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
> также,
> как были бы изолированы отдельные процессы php-fpm, запущенные независимо
> друг
> от друга на одной машине.
>
> --
> Валентин Бартенев
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> на самом деле загрузить-то получится (наверное, не проверял),
не получится. ибо даже разные версии PHP используют одно и тоже
пространство имён функций и таблиц символов.

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

20 октября 2017 г., 17:21 пользователь Slawa Olhovchenkov <s...@zxy.spb.ru>
написал:

> On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
>
> > >> Так в таком случае использование unit еще выгоднее: ему не надо
> держать
> > master-процесс для каждой версии php, не говоря о процессе для каждого
> > пользователя.
> > Не представляю как это будет работать.
> > Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
> > безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
> > случае не получится загрузить в один веб-сервер несколько версий этого
> > модуля.
>
> на самом деле загрузить-то получится (наверное, не проверял), а вот
> активировать нужный для конкретно URL может быть проблемой.
>
> впрочем, возможно проблему решит правка сырцов для замены директив
> php_* на phpXY_*.
>
> в любом случае, nginx unit не решает проблему с pear и pecl, например, в
> случае php (и я не смотрел как он решает проблему с собственно php
> разных версий).
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Так в таком случае использование unit еще выгоднее: ему не надо держать
master-процесс для каждой версии php, не говоря о процессе для каждого
пользователя.
Не представляю как это будет работать.
Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
случае не получится загрузить в один веб-сервер несколько версий этого
модуля. Или возьмём php-fpm, который сам по себе и который даёт возможность
тому же nginx'у обращаться к своему сокету или порту, этих может быть до
лешего версий, но тогда каждый из них является по сути самостоятельным
процессом.

>> Проблема слегка преувеличена и, если бы все были настолько
параноидальными в безопасности - мы бы до сих пор не увидели систем
виртуализации
Скорее преуменьшена :)
С виртуализацией несколько по-другому дело обстоит и сравнивать в данном
случае некорректно.

20 октября 2017 г., 16:42 пользователь Maksim Kulik <kulm...@gmail.com>
написал:

> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого
> пользователя.
>
> P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем под
> каждого пользователя запускать отдельный master-процесс? Достаточно ведь
> завести для конкретного пользователя свой pool (работающий от имени этого
> пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
> скиньте, плиз, линку на почту где можно подробнее почитать об опасности
> запуска одного мастер-процесса для разных пользователей.
>
> 20 октября 2017 г., 16:36 пользователь Виктор Вислобоков <
> corocho...@gmail.com> написал:
>
>> >> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
>> установлено 5 версий PHP. Для каждой версии должен быть master-процесс
>> php-fpm, который, как минимум, кушает память, сокет и т.д.
>>
>> На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
>> php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный
>> php-fpm процесс со своим userid то и не важно какой версии PHP он будет -
>> всё-равно его запускать придётся. Так что если используется php-fpm то
>> никакой экономии ресурсов не будет
>>
>>>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
установлено 5 версий PHP. Для каждой версии должен быть master-процесс
php-fpm, который, как минимум, кушает память, сокет и т.д.

На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный
php-fpm процесс со своим userid то и не важно какой версии PHP он будет -
всё-равно его запускать придётся. Так что если используется php-fpm то
никакой экономии ресурсов не будет

20 октября 2017 г., 16:29 пользователь Maksim Kulik 
написал:

> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
> установлено 5 версий PHP. Для каждой версии должен быть master-процесс
> php-fpm, который, как минимум, кушает память, сокет и т.д. В идеале его еще
> и мониторить надо на предмет доступности. Добавим сюда возможность
> изменения конфигурации "на лету" без перезапуска рабочих процессов (на
> случай перевода одного из 500 сайтов на другую версию PHP) - и мы получим
> очень удобную замену нынешним костылям по крайней мере для хостеров.
>
> 20 октября 2017 г., 16:00 пользователь Илья Шипицин 
> написал:
>
>>
>>
>> 20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
>> unclean...@gmail.com> написал:
>>
>>> Очень интересная штука! Обязательно будем пробовать.
>>>
>>
>> можно поподробнее, чем именно интересна ?
>> возможность запускать php или go - есть, всякие там php-fpm, caddy, ...
>>
>> понятно, что, скорее всего на unit тоже будет работать. а в чем
>> преимущество, в двух словах?
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Как правильно совместить limit_req и ограничение по IP?

2015-10-12 Пенетрантность Виктор Вислобоков 
Огромное спасибо, Алексей.
Действительно, всё работает!

С уважением, Виктор

11 октября 2015 г., 23:25 пользователь Alex Vorona <vo...@amhost.net>
написал:

> 11.10.15 00:08, Виктор Вислобоков пишет:
>
>> Есть некий список адресов. Для этого списка необходимо отдавать страницы
>> без ограничений, для всех остальных нужно сделать ограничение limit_req.
>> Непонятно как это правильно сделать с учётом того, что limit_req внутри if
>> не работает.
>>
>> На одном из форумов предлагается такое решение:
>>
>>  geo $nolimit {
>>  default 0;
>>  10.0.0.0/24 1;
>>  192.168.0.0/24 1;
>>  }
>>  limit_req_zone $binary_remote_addr zone=ratezone:10m rate=5r/s;
>>
>
> Попробуйте
>
> geo $nolimit {
> default $binary_remote_addr;
> 10.0.0.0/24 "";
> 192.168.0.0/24 "";
> }
> limit_req_zone $nolimit zone=ratezone:10m rate=5r/s;
>
> Судя по http://nginx.org/r/limit_req_zone/en "Requests with an empty key
> value are not accounted." запросы с пустыми ключами должны работать без
> ограничений.
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Как правильно совместить limit_req и ограничение по IP?

2015-10-10 Пенетрантность Виктор Вислобоков 
Есть некий список адресов. Для этого списка необходимо отдавать страницы
без ограничений, для всех остальных нужно сделать ограничение limit_req.
Непонятно как это правильно сделать с учётом того, что limit_req внутри if
не работает.

На одном из форумов предлагается такое решение:

geo $nolimit {
default 0;
10.0.0.0/24 1;
192.168.0.0/24 1;
}
limit_req_zone $binary_remote_addr zone=ratezone:10m rate=5r/s;

server {
...

location / {
error_page 418 = @nolimit;

if ($limit) {
return 418;
}

limit_req zone=ratezone burst=10 nodelay;

# ...
}

location @nolimit {
# ... no limit_req here
}
}

но насколько это  правильно, делать такое перенаправление? Есть ли какие-то
другие способы?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Директивы сжатия дублированы?

2014-03-14 Пенетрантность Виктор Вислобоков 
Сегодня разбирался с сжатием и открыл для себя, что мало сказать:
gzip on
надо ещё ОБЯЗАТЕЛЬНО перечислить MIME типы для которых будет осуществляться
сжатие.
Тогда возникает вопрос, а зачем тогда вообще нужен gzip on?
По факту-то получается, что сжатие включается именно директивой gzip_types.
Только путаница и дублирование.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Защита от шелов

2013-08-18 Пенетрантность Виктор Вислобоков 
Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя,
которому принадлежит сайт. На остальные сайты соответственно поставите
права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли
читать файлы.

Как добиться? Разные способы есть. Например использование вместо mod_php
для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа
mod_suid, mod_ruid которые работают совместно с mod_php.


18 августа 2013 г., 10:29 пользователь Русанов Олег lavan...@ya.ruнаписал:

 Здравствуйте. Есть ли способ предотвратить просматривать шелом другие
 сайты на виртуальном хосте?
 В конфиге сайта рут - папка где index.php, а шелл показывает, что root -
 это папка где все сайты находятся.
 Может быть в этом дело?


 --
 С уважением,
 Олег Русанов.

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

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

Re: Защита от шелов

2013-08-18 Пенетрантность Виктор Вислобоков 
 php_value open_basedir /home/user/1.ru/docs
такое спасает только от PHP. Но если запустить perl или ещё чего - проблема
остаётся, потому что на них ограничения PHP не распространяются.
Так что правильное решение - это разделение прав доступа по сайтам - всё
остальное лишь полумеры


18 августа 2013 г., 12:44 пользователь Русанов Олег lavan...@ya.ruнаписал:

 На счет прав не знаю теперь, это у меня из кэша шелл грузился.
 оказывается, а так выше папки сайта не может выйти, если в
 в /home/user/etc/httpd.conf прописать.

 В общем работает и удобнее всего, наверное, это:
 в .htaccess добавить:
 php_value open_basedir /home/user/1.ru/docs



 18.08.2013, 11:19, Русанов Олег lavan...@ya.ru:
  Directory /home/идентификатор/домен/docs
  php_admin_value open_basedir /home/идентификатор/домен/docs
  php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp
  /Directory
 
  Вот это работает все-таки, только если прописывать не в /home/user/
 d.ru/conf/virtual.conf.manual,
  а в /home/user/etc/httpd.conf
  И права должны быть выключены для других.
 
  а Ру-Центр неплохой хостинг, у них еще в Амстердаме площадка открылась,
  так что по-моему они - лучший вариант.
 
  18.08.2013, 11:03, Artem Vasiliev artem.vasil...@gmail.com:
  Сменить хостинг
  
  WBR
  Artem V. Vasiliev
  Sent from Mailbox for iPhone
 
  On Sun, Aug 18, 2013 at 10:58 AM, Русанов Олег lavan...@ya.ru wrote:
  Это слишком сложно, как я это сделаю на хостинге Ру-Центра?
 
  В конфиг Апача не помогает:
  Directory /home/идентификатор/домен/docs
  php_admin_value open_basedir /home/идентификатор/домен/docs
  php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp
  /Directory
  может это надо как-то в конфиг Энджиникса прописать?
 
  18.08.2013, 10:45, Виктор Вислобоков corocho...@gmail.com:
  Вам нужно добиться, чтобы php-скрипты запускались с правами
 пользователя, которому принадлежит сайт. На остальные сайты соответственно
 поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы
 они могли читать файлы.
  Как добиться? Разные способы есть. Например использование вместо
 mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к
 апачу типа mod_suid, mod_ruid которые работают совместно с mod_php.
 
  18 августа 2013 г., 10:29 пользователь Русанов Олег lavan...@ya.ru
 написал:
  Здравствуйте. Есть ли способ предотвратить просматривать шелом
 другие сайты на виртуальном хосте?
  В конфиге сайта рут - папка где index.php, а шелл показывает, что
 root - это папка где все сайты находятся.
  Может быть в этом дело?
 
  --
  С уважением,
  Олег Русанов.
 
  ___
  nginx-ru mailing list
  nginx-ru@nginx.org
  http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
  ,
  ___
  nginx-ru mailing list
  nginx-ru@nginx.org
  http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
  --
  С уважением,
  Олег Русанов.
  ___
  nginx-ru mailing list
  nginx-ru@nginx.org
  http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
  ,
  ___
  nginx-ru mailing list
  nginx-ru@nginx.org
  http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
  --
  С уважением,
  Олег Русанов.
  ,
  ___
  nginx-ru mailing list
  nginx-ru@nginx.org
  http://mailman.nginx.org/mailman/listinfo/nginx-ru


 --
 С уважением,
 Олег Русанов.

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

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

Re: Re[2]: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли

2013-08-04 Пенетрантность Виктор Вислобоков 
А мне кажется всё это неэффективно. IP адресов прорва и каждый задолбаешься
блокировать, а нагрузка прёт.
Эффективных вариантов вижу 2:
1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к
отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и
/wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и
сам владелец сайта зайти не сможет, но для его IP можно сделать исключение.
Зато остальные сайты на сервере смогут нормально работать
2. С участием владельца сайта переименовать файл для входа в какое-нибудь
трудное имя, например administator/indexHJK28bhy2H.php, чтобы данное имя
было известно только владельцу сайта. А на /administator/index.php
поставить статическую заглушку, которую nginx может отдавать со скоростью
пулемёта.


4 августа 2013 г., 15:21 пользователь Vladislav Prodan
univers...@ukr.netнаписал:



  --- Исходное сообщение ---
 От кого: Nick Knutov m...@knutov.com
 Дата: 3 августа 2013, 14:13:32


  Тем, что он пропускает запросы на бекэнд.
  Размер ботнета, перебирающего пароли - примерно 100 000 ип.
  Он не весь сразу приходит, но в общем случае, или можно использовать
  простое ограничение вроде с одного ип не чаще 1 запроса в
  минуту/секунду, но это просто снижает нагрузку до приемлимого уровня, а
  не решает проблему.

 У меня скрипт каждые 5 минут парсит общий (суточный) лог нгинкса
 nginx-access.log.
 И если накапливается 30 запросов на перебор паролей вордпресса/джумлы с 1
 IP, то этот IP добавляется в глобальный список deny.

 --
 Vladislav V. Prodan
 System  Network Administrator
 http://support.od.ua
 +380 67 4584408, +380 99 4060508
 VVP88-RIPE

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

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

Re: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли

2013-08-04 Пенетрантность Виктор Вислобоков 
 На этот файл можно натравить fail2ban и принимать необходимое решение.
А если у вас несколько сотен виртуалхостов, ваш fail2ban будет жёско иметь
сервер парся логи.
А поскольку ботнеты бывают ну очень большими, вы ещё рискуете получить каку
от ядра, когда таблица файрвола будет забита десятками тысяч IP адресов.


4 августа 2013 г., 17:40 пользователь Sergey Kobzar 
sergey.kob...@itcraft.org написал:

 On 08/04/13 14:59, Vladislav Prodan wrote:



 --- Исходное сообщение ---
 От кого: Виктор Вислобоков corocho...@gmail.com
 Дата: 4 августа 2013, 14:39:32


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


 Кто задолбается блокировать? Скрипт? nginx?
 Для владельца ресурса достаточно трех попыток зайти на свой ресурс.
 А пороговое значение (у меня) - 30 попыток и есть куда снижать.
 Скрипт на awk, спокойно парсит гигобайтные логи за несколько (десятков)
 секунд.

  Эффективных вариантов вижу 2:

 1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к
 отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и
 /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и
 сам владелец сайта зайти не сможет, но для его IP можно сделать исключение.
 Зато остальные сайты на сервере смогут нормально работать

  Белые списки само собой существуют.

  2. С участием владельца сайта переименовать файл для входа в
 какое-нибудь трудное имя, например administator/indexHJK28bhy2H.**php,
 чтобы данное имя было известно только владельцу сайта. А на
 /administator/index.php поставить статическую заглушку, которую nginx может
 отдавать со скоростью пулемёта.


 А лучше пароль на директорию повесить.


 Joomla пишет в logs/error.php о неуспешных попытках аутентификации. Формат:

 date   timepriorityclientipcategory

 На этот файл можно натравить fail2ban и принимать необходимое решение.


 __**_
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/**mailman/listinfo/nginx-ruhttp://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли

2013-08-04 Пенетрантность Виктор Вислобоков 
 Остальные сайты (да и атакуемые) и так прекрасно работают при правильном
софте/конфигах.
Ну-ну, блажен кто верует!
При хорошей атаке с большого ботнета, даже циска ложиться, куда уж вам с
вашими конфигами. Вас видимо просто ни кто ни разу КОНКРЕТНО не ддосил.

2 - да не очень хорошее решение. Тут предложили пароль ставить на каталог -
тоже выход!


4 августа 2013 г., 18:58 пользователь Nick Knutov m...@knutov.com написал:

 Меня всегда неимоверно радовали господа, предлагающие что-нибудь
 глобально запрестить для всех ип и сделать исключение для ип одного
 человека. Догадайтесь почему :)

 Остальные сайты (да и атакуемые) и так прекрасно работают при правильном
 софте/конфигах.

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


 04.08.2013 17:39, Виктор Вислобоков пишет:
  А мне кажется всё это неэффективно. IP адресов прорва и каждый
  задолбаешься блокировать, а нагрузка прёт.
  Эффективных вариантов вижу 2:
  1. С помощью nginx сделать ограничение ОБЩЕГО количества подключений к
  отвечающему за пароль URL (т.е. /administrator/index.php для Джумлы и
  /wp-login.php для Вордпресса). Поставить скажем штуки 2 и всё. Да, так и
  сам владелец сайта зайти не сможет, но для его IP можно сделать
  исключение. Зато остальные сайты на сервере смогут нормально работать
  2. С участием владельца сайта переименовать файл для входа в
  какое-нибудь трудное имя, например administator/indexHJK28bhy2H.php,
  чтобы данное имя было известно только владельцу сайта. А на
  /administator/index.php поставить статическую заглушку, которую nginx
  может отдавать со скоростью пулемёта.
 
 

 --
 Best Regards,
 Nick Knutov
 http://knutov.com
 ICQ: 272873706
 Voice: +7-904-84-23-130

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

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

Re: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли

2013-08-04 Пенетрантность Виктор Вислобоков 
 Я - хостер. Я не верую, я это вживую вижу на наших серверах.
Да я как бы тоже не погулять вышел

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

 Маленькие ботнеты мы не замечаем,
Аналогыгычно

 большие фильтруем
Скорее средние
Большие ботнеты можно фильтровать только при наличии циски да ещё не абы
какой.

 А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт.
Пароль на сайт не надо, а вот пароль на административную часть сайта -
почему нет?


4 августа 2013 г., 22:09 пользователь Nick Knutov m...@knutov.com написал:

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

 А циска - да, циска может и ложится.

 А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт.
 Гарантированно решит проблему.


 04.08.2013 21:56, Виктор Вислобоков пишет:
  Остальные сайты (да и атакуемые) и так прекрасно работают при
  правильном софте/конфигах.
  Ну-ну, блажен кто верует!
  При хорошей атаке с большого ботнета, даже циска ложиться, куда уж вам с
  вашими конфигами. Вас видимо просто ни кто ни разу КОНКРЕТНО не ддосил.
 
  2 - да не очень хорошее решение. Тут предложили пароль ставить на
  каталог - тоже выход!\--
 Best Regards,
 Nick Knutov
 http://knutov.com
 ICQ: 272873706
 Voice: +7-904-84-23-130

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

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

Re: ModSecurity, защита WP и джумлы от ботов, перебирающих пароли

2013-08-04 Пенетрантность Виктор Вислобоков 
Возможно. Я не специалист по Джумле. В Друпале например в /admin/ кроме
администраторов никого не бывает.
Но если стоит вопрос в том, что сервер лежит и не работают ВСЕ клиенты, или
часть клиентов испытывает неудобства зато все могут работать, я выберу
последнее.


4 августа 2013 г., 23:32 пользователь Nick Knutov m...@knutov.com написал:

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

 05.08.2013 1:24, Виктор Вислобоков пишет:
  А пароль на каталог - это неинтересно. Давайте сразу пароль на сайт.
  Пароль на сайт не надо, а вот пароль на административную часть сайта -
  почему нет?

 --
 Best Regards,
 Nick Knutov
 http://knutov.com
 ICQ: 272873706
 Voice: +7-904-84-23-130

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

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

Отработка лимитов, вопрос

2013-04-15 Пенетрантность Виктор Вислобоков 
Сегодня столкнулся со странной вещью
Стоит nginx 1.2.7
В нём сделаны ограничения по виртуалхостам с помощью limit_conn_zone и
limit_conn
Всё работало идеально до сегодняшнего вечера.
Случилась атака на сайт и смотрю в apache /server-status что куча коннектов
к тому виртуалхосту, к которому их быть не должно согласно limit_conn
больше 5.
Полез разбираться в логи.
В логах я вижу сработавшие limit_conn


2013/04/16 01:52:21 [error] 11652#0: *248356 limiting connections by zone
from_all_limit, client: 196.205.118.51, server: XX.net, request: GET
/ HTTP/1.1, host: XX.net, referrer:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

всё бы классно, но почему тогда столько коннектов висит на апачах?
Посмотрел ещё лог nginx, много 400-х
Тогда возникла мысль, а не происходит ли следующее:

1. Клиент запрашивает у nginx страницу, но не дожидаясь её обрывает
соединение
2. nginx передаёт запрос апачу и ждёт от него ответа, но поскольку клиент
соединение закрыл из limit_conn оно удаляется.
3. вот и получается картина, что у апача есть куча запросов, которые он
обрабатывает, но которые уже не нужны ни nginx'У ни клиенту

Поскольку я не разбираюсь в тонкостях реализации, написал сюда. Я прав, так
всё и просиходит?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru