subject:""

Изменения в nginx 1.26.1  29.05.2024

   *) Безопасность: при использовании HTTP/3 обработка специально созданной
  QUIC-сессии могла приводить к падению рабочего процесса, отправке
  клиенту содержимого памяти рабочего процесса на системах с MTU больше
  4096 байт, а также потенциально могла иметь другие последствия
  (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161).
  Спасибо Nils Bars из CISPA.

   *) Исправление: уменьшено потребление памяти для долгоживущих запросов,
  если используются директивы gzip, gunzip, ssi, sub_filter или
  grpc_pass.

   *) Исправление: nginx не собирался gcc 14, если использовался параметр
  --with-atomic.
  Спасибо Edgar Bonet.

   *) Исправление: в HTTP/3.


-- 
Sergey Kandaurov

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

[nginx-ru-announce] nginx security advisory (CVE-2024-31079, CVE-2024-32760, CVE-2024-34161, CVE-2024-35200)

Hello!

В реализации HTTP/3 в nginx были обнаружены четыре проблемы, которые
позволяют атакующему с помощью специально созданной QUIC-сессии вызвать
падение рабочего процесса (CVE-2024-31079, CVE-2024-32760, CVE-2024-35200),
отправку клиенту части содержимого памяти рабочего процесса на системах
с MTU больше 4096 байт (CVE-2024-34161), а также потенциально могут иметь
другие последствия (CVE-2024-31079, CVE-2024-32760).

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

Проблемам подвержен nginx 1.25.0-1.25.5, 1.26.0.
Проблемы исправлены в nginx 1.27.0, 1.26.1.

Спасибо Nils Bars из CISPA.


-- 
Sergey Kandaurov

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

[nginx-ru-announce] nginx-1.27.0

Изменения в nginx 1.27.0  29.05.2024

   *) Безопасность: при использовании HTTP/3 обработка специально созданной
  QUIC-сессии могла приводить к падению рабочего процесса, отправке
  клиенту содержимого памяти рабочего процесса на системах с MTU больше
  4096 байт, а также потенциально могла иметь другие последствия
  (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161).
  Спасибо Nils Bars из CISPA.

   *) Добавление: директивы proxy_limit_rate, fastcgi_limit_rate,
  scgi_limit_rate и uwsgi_limit_rate поддерживают переменные.

   *) Исправление: уменьшено потребление памяти для долгоживущих запросов,
  если используются директивы gzip, gunzip, ssi, sub_filter или
  grpc_pass.

   *) Исправление: nginx не собирался gcc 14, если использовался параметр
  --with-atomic.
  Спасибо Edgar Bonet.

   *) Исправления в HTTP/3.


-- 
Sergey Kandaurov

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

nginx security advisory (CVE-2024-31079, CVE-2024-32760, CVE-2024-34161, CVE-2024-35200)

Hello!

В реализации HTTP/3 в nginx были обнаружены четыре проблемы, которые
позволяют атакующему с помощью специально созданной QUIC-сессии вызвать
падение рабочего процесса (CVE-2024-31079, CVE-2024-32760, CVE-2024-35200),
отправку клиенту части содержимого памяти рабочего процесса на системах
с MTU больше 4096 байт (CVE-2024-34161), а также потенциально могут иметь
другие последствия (CVE-2024-31079, CVE-2024-32760).

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

Проблемам подвержен nginx 1.25.0-1.25.5, 1.26.0.
Проблемы исправлены в nginx 1.27.0, 1.26.1.

Спасибо Nils Bars из CISPA.


-- 
Sergey Kandaurov

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

nginx-1.26.1

Изменения в nginx 1.26.1  29.05.2024

   *) Безопасность: при использовании HTTP/3 обработка специально созданной
  QUIC-сессии могла приводить к падению рабочего процесса, отправке
  клиенту содержимого памяти рабочего процесса на системах с MTU больше
  4096 байт, а также потенциально могла иметь другие последствия
  (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161).
  Спасибо Nils Bars из CISPA.

   *) Исправление: уменьшено потребление памяти для долгоживущих запросов,
  если используются директивы gzip, gunzip, ssi, sub_filter или
  grpc_pass.

   *) Исправление: nginx не собирался gcc 14, если использовался параметр
  --with-atomic.
  Спасибо Edgar Bonet.

   *) Исправление: в HTTP/3.


-- 
Sergey Kandaurov

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

nginx-1.27.0

2024-04-24 Пенетрантность Roman Arutyunyan

Изменения в nginx 1.27.0  29.05.2024

   *) Безопасность: при использовании HTTP/3 обработка специально созданной
  QUIC-сессии могла приводить к падению рабочего процесса, отправке
  клиенту содержимого памяти рабочего процесса на системах с MTU больше
  4096 байт, а также потенциально могла иметь другие последствия
  (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161).
  Спасибо Nils Bars из CISPA.

   *) Добавление: директивы proxy_limit_rate, fastcgi_limit_rate,
  scgi_limit_rate и uwsgi_limit_rate поддерживают переменные.

   *) Исправление: уменьшено потребление памяти для долгоживущих запросов,
  если используются директивы gzip, gunzip, ssi, sub_filter или
  grpc_pass.

   *) Исправление: nginx не собирался gcc 14, если использовался параметр
  --with-atomic.
  Спасибо Edgar Bonet.

   *) Исправления в HTTP/3.


-- 
Sergey Kandaurov

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

Re: merge_slashes

Добрый день,

> On 16 Apr 2024, at 11:41 PM, Vladimir Sopot  wrote:
> 
> Здравствуйте!
> 
> Есть примерно такой упрощённый конфиг и при обращении к 
> some.localsome.html merge_slashes не работает. Если в первом сервере 
> убрать merge_slashes off, то всё работает нормально и во втором сервере. 
> Почему так? nginx version: nginx/1.25.3

На момент парсинга строки запроса, nginx еще не знает о том, какой виртуальный 
сервер будет выбран и использует настройки дефолтного.

Если вы включите ssl, то ситуация будет другой.

> 
> http {
>   merge_slashes on;
>   }
> 
> server {
>   listen 127.0.0.1:80 default_server; 
>   server_name 127.0.0.1 _ "";
> 
>   merge_slashes off;
>   allow 127.0.0.1;
>   deny all;
> 
>   location /nginx_status {
>   stub_status on;
>   }
> 
> …. много location
> 
>   }
> 
> server {
>   listen *:80;
>   server_name  some.local;
> 
> …. много location
> 
>   }
> 
> Best, VS
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru


Roman Arutyunyan
a...@nginx.com




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

[nginx-ru-announce] nginx-1.26.0

2024-04-23 Пенетрантность Roman Arutyunyan

Изменения в nginx 1.26.0  23.04.2024

*) Стабильная ветка 1.26.x.



Roman Arutyunyan
a...@nginx.com
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.26.0

2024-04-23 Пенетрантность Roman Arutyunyan

Изменения в nginx 1.26.0  23.04.2024

*) Стабильная ветка 1.26.x.



Roman Arutyunyan
a...@nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

merge_slashes

2024-04-16 Пенетрантность Vladimir Sopot

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

Есть примерно такой упрощённый конфиг и при обращении к 
some.localsome.html merge_slashes не работает. Если в первом сервере 
убрать merge_slashes off, то всё работает нормально и во втором сервере. 
Почему так? nginx version: nginx/1.25.3

http {
merge_slashes on;
}

server {
listen 127.0.0.1:80 default_server; 
server_name 127.0.0.1 _ "";

merge_slashes off;
allow 127.0.0.1;
deny all;

   location /nginx_status {
   stub_status on;
   }

…. много location

}

server {
   listen *:80;
   server_name  some.local;

…. много location

}

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

[nginx-ru-announce] nginx-1.25.5

2024-04-16 Пенетрантность Roman Arutyunyan

Изменения в nginx 1.25.5  16.04.2024

*) Добавление: виртуальные сервера в модуле stream.

*) Добавление: модуль ngx_stream_pass_module.

*) Добавление: параметры deferred, accept_filter и setfib директивы
   listen в модуле stream.

*) Добавление: определение размера строки кеша процессора для некоторых
   архитектур.
   Спасибо Piotr Sikora.

*) Добавление: поддержка Homebrew на Apple Silicon.
   Спасибо Piotr Sikora.

*) Исправление: улучшения и исправления кросс-компиляции для Windows.
   Спасибо Piotr Sikora.

*) Исправление: неожиданное закрытие соединения при использовании 0-RTT
   в QUIC.
   Спасибо Владимиру Хомутову.



Roman Arutyunyan
a...@nginx.com




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

nginx-1.25.5

2024-04-16 Пенетрантность Roman Arutyunyan

Изменения в nginx 1.25.5  16.04.2024

*) Добавление: виртуальные сервера в модуле stream.

*) Добавление: модуль ngx_stream_pass_module.

*) Добавление: параметры deferred, accept_filter и setfib директивы
   listen в модуле stream.

*) Добавление: определение размера строки кеша процессора для некоторых
   архитектур.
   Спасибо Piotr Sikora.

*) Добавление: поддержка Homebrew на Apple Silicon.
   Спасибо Piotr Sikora.

*) Исправление: улучшения и исправления кросс-компиляции для Windows.
   Спасибо Piotr Sikora.

*) Исправление: неожиданное закрытие соединения при использовании 0-RTT
   в QUIC.
   Спасибо Владимиру Хомутову.



Roman Arutyunyan
a...@nginx.com




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

Re: Проверка связки сертификат+ключ

2024-03-27 Пенетрантность Илья Шипицин

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

ср, 27 мар. 2024 г. в 14:27, Иван Григорьев :

> Здравствуйте.
>
> Обнаружил необычное (на мой взгяд поведение) - если "смешать"
> криптографические алгоритмы (сертификат ECDSA, ключ RSA или наоборот) то
> nginx не ругается при релоаде и применяет конфигурацию (при выполнении
> nginx -t тоже нет ошибок).
>
> (абсурдность самой ситуации можно не обсуждать, но к сожалению бывает и
> такое)
>
> Это ожидаемое поведение или похоже на баг?
>
> Проверял на разных версиях и ОС, но на всякий случай прикладываю:
>
>
>
>
>
> *snake@carbon:~$ nginx -Vnginx version: nginx/1.24.0built by gcc 10.2.1
> 20210110 (Debian 10.2.1-6) built with OpenSSL 1.1.1n  15 Mar 2022 (running
> with OpenSSL 1.1.1f  31 Mar 2020)TLS SNI support enabledconfigure
> arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/var/log/nginx/error.log
> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
> --lock-path=/var/run/nginx.lock
> --http-client-body-temp-path=/var/cache/nginx/client_temp
> --http-proxy-temp-path=/var/cache/nginx/proxy_temp
> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
> --with-compat --with-file-aio --with-threads --with-http_addition_module
> --with-http_auth_request_module --with-http_dav_module
> --with-http_flv_module --with-http_gunzip_module
> --with-http_gzip_static_module --with-http_mp4_module
> --with-http_random_index_module --with-http_realip_module
> --with-http_secure_link_module --with-http_slice_module
> --with-http_ssl_module --with-http_stub_status_module
> --with-http_sub_module --with-http_v2_module --with-mail
> --with-mail_ssl_module --with-stream --with-stream_realip_module
> --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g
> -O2
> -ffile-prefix-map=/data/builder/debuild/nginx-1.24.0/debian/debuild-base/nginx-1.24.0=.
> -fstack-protector-strong -Wformat -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now
> -Wl,--as-needed -pie'*
> ___
> 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

Fwd: Проверка связки сертификат+ключ

2024-03-27 Пенетрантность Иван Григорьев

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

Обнаружил необычное (на мой взгяд поведение) - если "смешать"
криптографические алгоритмы (сертификат ECDSA, ключ RSA или наоборот) то
nginx не ругается при релоаде и применяет конфигурацию (при выполнении
nginx -t тоже нет ошибок).

(абсурдность самой ситуации можно не обсуждать, но к сожалению бывает и
такое)

Это ожидаемое поведение или похоже на баг?

Проверял на разных версиях и ОС, но на всякий случай прикладываю:





*snake@carbon:~$ nginx -Vnginx version: nginx/1.24.0built by gcc 10.2.1
20210110 (Debian 10.2.1-6) built with OpenSSL 1.1.1n  15 Mar 2022 (running
with OpenSSL 1.1.1f  31 Mar 2020)TLS SNI support enabledconfigure
arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
--with-compat --with-file-aio --with-threads --with-http_addition_module
--with-http_auth_request_module --with-http_dav_module
--with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module
--with-http_sub_module --with-http_v2_module --with-mail
--with-mail_ssl_module --with-stream --with-stream_realip_module
--with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g
-O2
-ffile-prefix-map=/data/builder/debuild/nginx-1.24.0/debian/debuild-base/nginx-1.24.0=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed -pie'*
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: lock in nginx/njs

2024-03-19 Пенетрантность Andrey Oktyabrskiy


On 13.03.2024 09:00, Eugene Prokopiev wrote:

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

Скажите, нет ли чего-нибудь похожего на
https://github.com/openresty/lua-resty-lock/ в nginx/njs?
Или может есть другой способ разрешить выполнять запросы с одинаковым
$uri строго по очереди (один выполняется, остальные ждут)?

Без шансов. Я задавал этот вопос несколько лет назад. Единственный 
способ выполнять подзапросы последовательно - вложенные подзапросы.


Очень серьёзное ограничение, не позволяющее использовать njs везде, где 
хотелось бы.

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

Re: lock in nginx/njs

2024-03-13 Пенетрантность kvt

  Нужная вам функциональность есть в mod_accel. Но придётся через промежуточный apache проксировать.Ого, ну при таком раскладе проще взять openresty (тем более, что уменя запросы, которые нужно блокировать, не совсем идентичные)Еще вариант в самом приложении выстраивать очередь входящих запросов или использовать блокировки, пока выполняется обработка запроса, но тут могут быть проблемы с 502/504 ошибками nginx.___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: lock in nginx/njs

2024-03-13 Пенетрантность Eugene Prokopiev

ср, 13 мар. 2024 г. в 11:02, Andrey A. Kopeyko :
>
> Нужная вам функциональность есть в mod_accel.
>
> Но придётся через промежуточный apache проксировать.

Ого, ну при таком раскладе проще взять openresty (тем более, что у
меня запросы, которые нужно блокировать, не совсем идентичные)

-- 
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: lock in nginx/njs

2024-03-13 Пенетрантность Andrey A. Kopeyko

Нужная вам функциональность есть в mod_accel.

Но придётся через промежуточный apache проксировать.

13 марта 2024 г. 10:07:43 GMT+03:00, Eugene Prokopiev 
 пишет:
>ср, 13 мар. 2024 г. в 09:11, Dmitry Volyntsev :
>
>> А чем вас
>> https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock
>> не устраивает?
>> Или более подробно опишите свою задачу
>
>Мне не нужно кэшировать результаты запросов
>
>Но если запросы POST /one/0.txt и POST /two/1.txt можно выполнять
>параллельно, то запросы POST /one/0.txt и POST /one/1.txt нужно
>ставить в очередь (на основании "каталога" в $uri) и выполнять один за
>другим, т.к. бакенд за proxy_pass не может корректно выполнять их
>одновременно
>
>-- 
>WBR,
>Eugene Prokopiev
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Re: lock in nginx/njs

2024-03-13 Пенетрантность Eugene Prokopiev

ср, 13 мар. 2024 г. в 09:11, Dmitry Volyntsev :

> А чем вас
> https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock
> не устраивает?
> Или более подробно опишите свою задачу

Мне не нужно кэшировать результаты запросов

Но если запросы POST /one/0.txt и POST /two/1.txt можно выполнять
параллельно, то запросы POST /one/0.txt и POST /one/1.txt нужно
ставить в очередь (на основании "каталога" в $uri) и выполнять один за
другим, т.к. бакенд за proxy_pass не может корректно выполнять их
одновременно

-- 
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: lock in nginx/njs

2024-03-13 Пенетрантность Dmitry Volyntsev



On 12.03.2024 23:00, Eugene Prokopiev wrote:

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

Скажите, нет ли чего-нибудь похожего на
https://github.com/openresty/lua-resty-lock/ в nginx/njs?
Или может есть другой способ разрешить выполнять запросы с одинаковым
$uri строго по очереди (один выполняется, остальные ждут)?

А чем вас 
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock 
не устраивает?

Или более подробно опишите свою задачу
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

lock in nginx/njs

2024-03-13 Пенетрантность Eugene Prokopiev

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

Скажите, нет ли чего-нибудь похожего на
https://github.com/openresty/lua-resty-lock/ в nginx/njs?
Или может есть другой способ разрешить выполнять запросы с одинаковым
$uri строго по очереди (один выполняется, остальные ждут)?

-- 
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NGINX as a WebSocket Proxy

2024-03-06 Пенетрантность Илья Шипицин

это очень странная статья. скажем так, между строк ПОДРАЗУМЕВАЕТСЯ, что '
 '' close;' по причине того, что мы наверняка не знаем, есть ли keepalive в
описании бекенде.

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

мы по этим же граблям прошлись в свое время

чт, 29 февр. 2024 г. в 20:30, Gena Makhomed :

> Здравствуйте, All!
>
> В статье https://www.nginx.com/blog/websocket-nginx/
> рекомендуется такой код:
>
> http {
>  map $http_upgrade $connection_upgrade {
>  default upgrade;
>  '' close;
>  }
>
>  upstream websocket {
>  server 192.168.100.10:8010;
>  }
>
>  server {
>  listen 8020;
>  location / {
>  proxy_pass http://websocket;
>  proxy_http_version 1.1;
>  proxy_set_header Upgrade $http_upgrade;
>  proxy_set_header Connection $connection_upgrade;
>  proxy_set_header Host $host;
>  }
>  }
> }
>
> При этом в других статьях - для включения keep-alive
> рекомендуется такой код:
>
> proxy_http_version 1.1;
> proxy_set_header Connection "";
>
> для того, чтобы режим Keep-alive работал между nginx и backend.
>
> Keep-alive connections are enabled by default in HTTP/1.1 while not in
> HTTP/1.0. HTTP/1.0 was designed to close the connection after every
> request between client and server.
>
> может быть в статье на сайте рекомендуется не самая оптимальная
> настройка и лучше было бы сделать так:
>
> # cat /etc/nginx/nginx.conf
>
> http {
>
>  map $http_upgrade $connection_upgrade {
>  default Upgrade;
>  '' '';
>  }
>
>  proxy_http_version 1.1;
>  proxy_set_header Upgrade $http_upgrade;
>  proxy_set_header Connection $connection_upgrade;
>  proxy_set_header Host $host;
> }
>
>
> в таком случае и вебсокеты смогут работать по любому урлу
> и при этом keep-alive подключения к backend тоже будут работать.
>
> upstream node {
>  server 127.0.0.1:3000;
>  keepalive 64;
> }
>
>
> ведь нет же никаких причин разрешать вебсокеты только
> по какому-то явно прописанному в конфиге урлу,
> а по всем остальным урлам - запрещать?
>
> --
> Best regards,
>   Gena
> ___
> 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 as a WebSocket Proxy

2024-02-29 Пенетрантность Gena Makhomed


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

В статье https://www.nginx.com/blog/websocket-nginx/
рекомендуется такой код:

http {
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}

upstream websocket {
server 192.168.100.10:8010;
}

server {
listen 8020;
location / {
proxy_pass http://websocket;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
}
}
}

При этом в других статьях - для включения keep-alive
рекомендуется такой код:

proxy_http_version 1.1;
proxy_set_header Connection "";

для того, чтобы режим Keep-alive работал между nginx и backend.

Keep-alive connections are enabled by default in HTTP/1.1 while not in 
HTTP/1.0. HTTP/1.0 was designed to close the connection after every 
request between client and server.


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

# cat /etc/nginx/nginx.conf

http {

map $http_upgrade $connection_upgrade {
default Upgrade;
'' '';
}

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
}


в таком случае и вебсокеты смогут работать по любому урлу
и при этом keep-alive подключения к backend тоже будут работать.

upstream node {
server 127.0.0.1:3000;
keepalive 64;
}


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

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

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-21 Пенетрантность Gena Makhomed


On 21.02.2024 14:54, Anatoliy Melnik via nginx-ru wrote:


Если вы предлагаете писать напрямую с nginx-а в файл --
сделайте у себя ротацию файлов с интервалом 30 сек
при 200-250 тыс подключений/сек...

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


Я намеренно ввел вас в заблуждение путем публикации сообщения,
допускающее двойное толкование в ту или иную сторону по желанию
сторон.


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


Кстати от вас я так и не увидел ни одной ссылки на конкретные значения из 
вашего личного опыта.
Лично мой опыт показывает, что при значениях более 500тыс/сек и примерно 1млн "живых" tcp 
сессий "падает" уже сама ось.
Если у вас есть конкретный пример, что на таком-то железе, такой-то оси вы 
"перевариваете" 1млн/сек -- отлично.
Если нет... Ну на нет и суда нет.


Из моего личного опыта - ротация логов через SIGUSR1 возможна при любом
количестве подключений, и любом разумном интервале - проблем не будет.

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

--
Best regards,
 Gena

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

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-21 Пенетрантность Anatoliy Melnik via nginx-ru

Gena Makhomed Wrote: 
--- 
> On 19.02.2024 16:01, Anatoliy Melnik via nginx-ru wrote: 
> 
>  Если вы предлагаете писать напрямую с nginx-а в файл -- 
>  сделайте у себя ротацию файлов с интервалом 30 сек 
>  при 200-250 тыс подключений/сек... 
>  
>  Если у вас уже есть такое рабочее решение - 
>  поделитесь опытом, буду рад вас выслушать. 
> >>> 
> >>> Я намеренно ввел вас в заблуждение путем публикации сообщения, 
> >>> допускающее двойное толкование в ту или иную сторону по желанию 
> >>> сторон. 
> >> 
> >> Почему / зачем? 
> > 
> > Был шанс увидеть в ответ нестандартное решение. 
> 
(мантры про логи...) 
> 
> Какое именно "нестандартное решение" для вышеобозначенной проблемы 
(мантры) 

Если вам его не видно -- это не значит, что его нет. 
Тот же костыль из юникс-сокета у меня в "альфа" версии на этапе проверки 
возможностей 
показал результат в 400тыс/сек с запасом. 
Кстати от вас я так и не увидел ни одной ссылки на конкретные значения из 
вашего личного опыта. 
Лично мой опыт показывает, что при значениях более 500тыс/сек и примерно 1млн 
"живых" tcp сессий "падает" уже сама ось. 
Если у вас есть конкретный пример, что на таком-то железе, такой-то оси вы 
"перевариваете" 1млн/сек -- отлично. 
Если нет... Ну на нет и суда нет. 


> 
> >> С моей точки зрения более важным является обеспечение более 
> высокой 
> >> надежности работы системы, чтобы логи не терялись в процессе 
> записи, 
> >> чем экономия свободного места на диске и экономия ресурсов NVMe 
> SSD. 
> >> 
> >> Поэтому с моей точки зрения - я не могу признать решение 
> >> через syslog и unix socket более оптимальным, чем вариант 
> >> записи логов напрямую в файлы и ротации логов через SIGUSR1. 
> >> 
> >> а ротацию логов можно делать и чаще, чем раз в 30 секунд, 
> >> например, раз 15, или раз в 10 или даже раз в 5 секунд, 
> >> если хочется уменьшить отставание статистики по времени. 
> >> 
> >> По сути - лог-файл на диске - это можете воспринимать примерно, 
> >> как то же самое, что и unix socket, только с буфером не в памяти, 
> >> а в виде файла на диске и без существенных ограничений по размеру 
> >> такого буфера, что будет лучше сглаживать всплески нагрузки 
> >> и может позволить большую асинхронность между процессом 
> >> записи информации в лог и процессом чтения информации 
> >> из лога. А во всем остальном - никакой существенной 
> >> разницы нет, учитывая только что запись логов в файлы 
> >> меньше грузит процесор и использует немного больше 
> >> свободного места на диске. 
> >> 
> >> Но мне например, лучше чтобы процессор был немного свободнее, 
> >> чем проистаивающее и никак не используемое место на диске. 
> >> 
> >> Но самое главное - что запись логов в файлы не приводит к потере 
> >> данных, а запись логов в unix socket может приводить к потерям 
> >> даных, если читатель будет не успевать забирать данные из unix 
> >> socket. 
> >> 
> >> Более надежное и более простое решение, и более экономно 
> >> расходующее процесор сервера - и будет более оптимальным. 
> 
> > пока я наблюдал скорее проблему "писатель не успевает записывать", 
> > а не "читатель не успевает забирать". 
> 
> видимая Вами проблема "писатель не успевает записывать" 
> вызвана именно тем, что "читатель не успевает забирать". 
> 
> Потому что когда у Вас был всего один читатель - он не успевал 
> читать данные из syslog и поэтому у nginx не было никаких других 
> вариантов, кроме как дропать часть сообщений. После того как вместо 
> одного читателя Вы сделали 10 читателей - они начали успевать читать 
> данные из syslog и проблема с потерей сообщений стала быть Вам не 
> видна. 
> 
Вы, как и всегда, имеете полное право на свое мнение. 


> > Эта же проблема и при файлах присутствует -- NVME не у всех всегда 
> везде. 
> > Система дисковая как ни крути - общий ресурс, и если ее интенсивно 
> нагрузить 
> > чем-то еще логи тоже могут получить проблему читатель-писатель. 
> 
> На frontend-сервере, сеть может быть загружена на 100% передачей 
> данных, 
> и процессор может быть загружен на 100% шифрованием/расшифровской 
> TLS. 
> Дисковая подсистема может использоваться только для записи логов. 
> 
> нагружать дисковую подсистему чем-либо еще, крмое записи логов 
> - нерационально, имеет смысл даже полностью выключить использование 
> диска при проксировании, чтобы не было блокирования nginx на 
> операциях 
> дискового ввода-вывода и чтобы не было увеличения latency, когда 
> этого 
> можно очень просто ибежать: 
> 
> proxy_http_version 1.1; 
> proxy_request_buffering off; 
> proxy_max_temp_file_size 0; 
> 
> По поводу того, что сейчас NVMe есть не у всех и не всегда 
> - это Вы мне сейчас из какого года свое сообщение пишете ? 

Вы, как и всегда, имеете полное право на свое мнение. 
Свой набор критериев оптимальности и эффективности. 


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

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-19 Пенетрантность Gena Makhomed


On 19.02.2024 16:01, Anatoliy Melnik via nginx-ru wrote:


Если вы предлагаете писать напрямую с nginx-а в файл --
сделайте у себя ротацию файлов с интервалом 30 сек
при 200-250 тыс подключений/сек...

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


Я намеренно ввел вас в заблуждение путем публикации сообщения,
допускающее двойное толкование в ту или иную сторону по желанию
сторон.


Почему / зачем?


Был шанс увидеть в ответ нестандартное решение.


Из представленной Вами информации - что Вам не удалось настроить
ротацию логов nginx раз в 30 секунд при 200-250 тыс. подключений
в секунду однозначно следует что Вы использовали для ротации логов
сигнал SIGHUP, делающий полный reload nginx а не сигнал SIGUSR1,
который только переоткрывает лог-файлы, не перезапуская рабочие
процессы. Никакого нестандартного решения в этой ситуации быть
не может, кроме как использовать SIGUSR1 вместо SIGHUP
для ротации логов nginx. И, как я понимаю, из представленной
Вами информации - именно эта изначальная Ваша ошибка и стала
причиной того, что не сумев настроить ротацю логов Вы ударились
во все тяжкие с syslog, unix socket`ами и 11 процессами на Python,
называя этот набор костылей решением вышеназванной Вами проблемы X.

Какое именно "нестандартное решение" для вышеобозначенной проблемы
с невозможностью нормально настроить ротацию логов Вы сами могли бы
предложить, если бы оказались на месте читателя своих же сообщений?

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


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

Поэтому с моей точки зрения - я не могу признать решение
через syslog и unix socket более оптимальным, чем вариант
записи логов напрямую в файлы и ротации логов через SIGUSR1.

а ротацию логов можно делать и чаще, чем раз в 30 секунд,
например, раз 15, или раз в 10 или даже раз в 5 секунд,
если хочется уменьшить отставание статистики по времени.

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

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

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

Более надежное и более простое решение, и более экономно
расходующее процесор сервера - и будет более оптимальным.



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


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

Потому что когда у Вас был всего один читатель - он не успевал
читать данные из syslog и поэтому у nginx не было никаких других
вариантов, кроме как дропать часть сообщений. После того как вместо
одного читателя Вы сделали 10 читателей - они начали успевать читать
данные из syslog и проблема с потерей сообщений стала быть Вам не видна.


Эта же проблема и при файлах присутствует -- NVME не у всех всегда везде.
Система дисковая как ни крути - общий ресурс, и если ее интенсивно нагрузить
чем-то еще логи тоже могут получить проблему читатель-писатель.


На frontend-сервере, сеть может быть загружена на 100% передачей данных,
и процессор может быть загружен на 100% шифрованием/расшифровской TLS.
Дисковая подсистема может использоваться только для записи логов.

нагружать дисковую подсистему чем-либо еще, крмое записи логов
- нерационально, имеет смысл даже полностью выключить использование
диска при проксировании, чтобы не было блокирования nginx на операциях
дискового ввода-вывода и чтобы не было увеличения latency, когда этого
можно очень просто ибежать:

proxy_http_version 1.1;
proxy_request_buffering off;
proxy_max_temp_file_size 0;

По поводу того, что сейчас NVMe есть не у всех и не всегда
- это Вы мне сейчас из какого года свое сообщение пишете ?


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


У Вас очень специфически задачи. Потому что как правило логи нужны.

Потому что если логи не нужны - их просто выключают для 1хх, 2хх
и 3хх статусов и логгируют

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-19 Пенетрантность Anatoliy Melnik via nginx-ru

Gena Makhomed Wrote: 
--- 
> On 15.02.2024 12:49, Anatoliy Melnik via nginx-ru wrote: 
> 
> > Если вы предлагаете писать напрямую с nginx-а в файл -- 
> > сделайте у себя ротацию файлов с интервалом 30 сек 
> > при 200-250 тыс подключений/сек... 
> > 
> > Если у вас уже есть такое рабочее решение - 
> > поделитесь опытом, буду рад вас выслушать. 
> 
> > "Я намеренно ввел вас в заблуждение путем публикации сообщения, 
> допускающее двойное толкование в ту или иную сторону по желанию 
> сторон." 
> 
> Почему / зачем? 

Был шанс увидеть в ответ нестандартное решение. 

> 
> > Дальнейшее перемалывание темы ротации лично для меня интереса не 
> представляет. 
> 
> Тогда прекращаем. 
> 
> >>> Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно 
> >>> решать что мне надо :) 
> 
> Так я и не пытался решать за Вас, как именно будет лучше поступить 
> в Вашей конкретной ситуации - скорее я рассматривал все множество 
> задач сбора статистики и обработки информации из логов - и на всем 
> этом множестве задач старался увидеть наиболее оптимальный способ 
> решения задачи, если абстрагироваться от затрат времени 
> и сил на реализацию решения в виде програмного кода. 
> 
Т.е. насколько я понимаю некоего идеального коня в сферическом вакууме. 
Не получиться "универсальный анализ логов". 
мне нужны средние, кому-то подавай количество больше чем, кому-то нужен разброс 
будет от min до max. 
Например 100 коннектов по 1К и 100 по 1М для кого-то то же самое, что и 200 по 
0.5005М, а для кого-то это суперважно. 
соответственно и обработка разной получится. в 1 проход или в 2. 


> >> Решайте сами, я просто хотел понять Вашу исходную задачу X, 
> >> поэтому и задавал уточняющие вопросы. 
> 
> > Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте 
> теме я уже все решил. 
> 
> С моей точки зрения более важным является обеспечение более высокой 
> надежности работы системы, чтобы логи не терялись в процессе записи, 
> чем экономия свободного места на диске и экономия ресурсов NVMe SSD. 
> 
> Поэтому с моей точки зрения - я не могу признать решение 
> через syslog и unix socket более оптимальным, чем вариант 
> записи логов напрямую в файлы и ротации логов через SIGUSR1. 
> 
> а ротацию логов можно делать и чаще, чем раз в 30 секунд, 
> например, раз 15, или раз в 10 или даже раз в 5 секунд, 
> если хочется уменьшить отставание статистики по времени. 
> 
> По сути - лог-файл на диске - это можете воспринимать примерно, 
> как то же самое, что и unix socket, только с буфером не в памяти, 
> а в виде файла на диске и без существенных ограничений по размеру 
> такого буфера, что будет лучше сглаживать всплески нагрузки 
> и может позволить большую асинхронность между процессом 
> записи информации в лог и процессом чтения информации 
> из лога. А во всем остальном - никакой существенной 
> разницы нет, учитывая только что запись логов в файлы 
> меньше грузит процесор и использует немного больше 
> свободного места на диске. 
> 
> Но мне например, лучше чтобы процессор был немного свободнее, 
> чем проистаивающее и никак не используемое место на диске. 
> 
> Но самое главное - что запись логов в файлы не приводит к потере 
> данных, а запись логов в unix socket может приводить к потерям 
> даных, если читатель будет не успевать забирать данные из unix 
> socket. 
> 
> Более надежное и более простое решение, и более экономно 
> расходующее процесор сервера - и будет более оптимальным. 
> 

1. Т.к. мне практически всегда нужны некоторые усредненные данные, 
то абсолютная полнота статистики не является основным условием. 
Хорошо, если она присутствует, но и если потеряно даже половина данных -- 
на средних значениях это слабо скажется :) 
2. пока я наблюдал скорее проблему "писатель не успевает записывать", 
а не "читатель не успевает забирать". 
Эта же проблема и при файлах присутствует -- NVME не у всех всегда везде. 
Система дисковая как ни крути - общий ресурс, и если ее интенсивно нагрузить 
чем-то еще логи тоже могут получить проблему читатель-писатель. 
Сжатие на лету -- это не только ресурс CPU при сжатии перед записью, это еще и 
ресурс при распаковке для анализа, у меня это происходит со всеми данными. 
Т.е. если nginx потратил ресурс на запаковку, то я в ответ должен потратить 
ресурс на распаковку... 
И где тут экономия CPU?? 
Мое мнение: 
Единственный плюс прямой записи в файл -- это длительное хранение данных, чего 
лично мне вот вообще не требуется. 

При необходимости обработки и анализа полученных данных пока опыт эксплуатации 
показывает преимущества юникс-сокета. 
Об этом чуть ниже. 

> > При желании добраться из пунта А в пункт Б именно на машине и 
> проблеме "машина не едет" 2 концептуальных решения: 
> > 1.Заменить машину. 
> > 2.Устранить причины "не едет" в имеющейся. 
> > Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из 
> строя запчасть. 
> > Если провести параллели, то с моей точки

Re: announcing freenginx.org

2024-02-16 Пенетрантность raven...@megaline.kg

В данной конкретной истори особо доставляет то, что обсуждение форка (и 
будущего этого самого форка) происходит в списке рассылки форкнутого 
продукта 

16.02.2024 19:21, Илья Шипицин пишет:

пт, 16 февр. 2024 г. в 10:25, Evgeniy Berdnikov :

On Thu, Feb 15, 2024 at 10:55:15PM +0200, Gena Makhomed wrote:
> On 15.02.2024 22:06, Evgeniy Berdnikov wrote:
>
> > Вы много чего написали, но не ответили на вопрос, сколько это
будет стоить.
> > Без реального ценника все рассуждения превращаются в схоластику...
>
> Так Вы же не мне этот вопрос задавали, а знатокам.
>
> Не понимаю, почему Вас так сильно интересует
> ответ на вопрос, сколько это будет стоить ?
>
> Вы собираетесь все переводить в деньги и все изменять только
деньгами?

 Так я написал: без ценовой конкретики эти дискуссии становятся
схоластикой.
 Нужно соизмерять свои желания со своими возможностями.
 Регистрация брендов -- занятие, доступное тем, у кого бизнес на
миллионы,
 и есть серьёзная потребность этот бизнес защищать.

 Для открытого проекта намного проще десять раз поменять название, чем
 заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL
 поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим
 сделать не может, а сборщики дистрибутивов стали раздавать пакет
автора,
 а не сборку Оракла. Причём там была похожая ситуация: пришли
манагеры,
 привыкшие к жёсткой иерархии и принципу "начальник всегда прав",
 подключили штатных оракловских разрабов и погнали патчи, которые
открыто
 не обсуждались и потому не всегда даже были понятны старым
разработчикам.
 Итог закономерен.

отдельно доставляет в подобных историях наличие code conduct и 
contribution policy.
по идее, в каждом проекте есть некие разделяемые всеми правила, как 
поступать,

как комитить и так далее.

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

но каждый божий раз эти code of conduct оказываются филькиной грамотой ))
как жить то, одни понятия, никаких законов

-- 
 Eugene Berdnikov

___
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

Re: announcing freenginx.org

2024-02-16 Пенетрантность Илья Шипицин

пт, 16 февр. 2024 г. в 10:25, Evgeniy Berdnikov :

> On Thu, Feb 15, 2024 at 10:55:15PM +0200, Gena Makhomed wrote:
> > On 15.02.2024 22:06, Evgeniy Berdnikov wrote:
> >
> > > Вы много чего написали, но не ответили на вопрос, сколько это будет
> стоить.
> > > Без реального ценника все рассуждения превращаются в схоластику...
> >
> > Так Вы же не мне этот вопрос задавали, а знатокам.
> >
> > Не понимаю, почему Вас так сильно интересует
> > ответ на вопрос, сколько это будет стоить ?
> >
> > Вы собираетесь все переводить в деньги и все изменять только деньгами?
>
>  Так я написал: без ценовой конкретики эти дискуссии становятся
> схоластикой.
>  Нужно соизмерять свои желания со своими возможностями.
>  Регистрация брендов -- занятие, доступное тем, у кого бизнес на миллионы,
>  и есть серьёзная потребность этот бизнес защищать.
>
>  Для открытого проекта намного проще десять раз поменять название, чем
>  заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL
>  поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим
>  сделать не может, а сборщики дистрибутивов стали раздавать пакет автора,
>  а не сборку Оракла. Причём там была похожая ситуация: пришли манагеры,
>  привыкшие к жёсткой иерархии и принципу "начальник всегда прав",
>  подключили штатных оракловских разрабов и погнали патчи, которые открыто
>  не обсуждались и потому не всегда даже были понятны старым разработчикам.
>  Итог закономерен.
>


отдельно доставляет в подобных историях наличие code conduct и contribution
policy.
по идее, в каждом проекте есть некие разделяемые всеми правила, как
поступать,
как комитить и так далее.

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

но каждый божий раз эти code of conduct оказываются филькиной грамотой ))
как жить то, одни понятия, никаких законов


> --
>  Eugene Berdnikov
> ___
> 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

Re: announcing freenginx.org

2024-02-16 Пенетрантность Gena Makhomed

On 15.02.2024 12:18, Maxim Dounin wrote:

> Во-первых, название freenginx - хорошо отражает суть проекта.
> Поэтому оно и было выбрано.

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

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

Такое имя проекта будет лучше всего и с точки зрения
интересов компании F5, потому что они в любой момент
могут воспользоваться законодательством о защите торговых
марок и заблокировать создание бизнеса и продажу коммерческой
версии веб-сервера под именем freenginx-plus или freenginx PRO

А поскольку компания F5 является владельцем торговой
марки NGINX - то они смогут защищать проект freenginx
от любых https://en.wikipedia.org/wiki/Trademark_troll
что будет очень полезно и Максиму и самой компании F5.

On 16.02.2024 1:24, Maxim Dounin wrote:

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

В случае если они начнут угрожать, что отберут домен freenginx.org
или что запретят использование имени freenginx для проекта - тогда
Максим просто переименует проект и они потеряют возможность блокировки
создания коммерческой версии и еще одного конкурента для nginx-plus.

Так что и для Максима и для компании F5 - это есть самый лучший вариант,
что проект Максима называется именно словом freenginx а не как-то иначе.

F5 - не выгодно терять возможность блокировки создания платной
версии, а Максиму не выгодно терять защиту от Trademark trolls.

On 16.02.2024 11:24, Evgeniy Berdnikov wrote:

  Для открытого проекта намного проще десять раз поменять название, чем
  заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL
  поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим
  сделать не может, а сборщики дистрибутивов стали раздавать пакет автора,
  а не сборку Оракла. Причём там была похожая ситуация: пришли манагеры,
  привыкшие к жёсткой иерархии и принципу "начальник всегда прав",
  подключили штатных оракловских разрабов и погнали патчи, которые открыто
  не обсуждались и потому не всегда даже были понятны старым разработчикам.
  Итог закономерен.

Да, теперь я понял.

Как это было с проектом Wireshark, изначально он назывался Ethereal,
но был переименован в Wireshark in May 2006 due to trademark issues.

--
Best regards,
 Gena

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

Re: announcing freenginx.org

2024-02-16 Пенетрантность Maxim Dounin

Hello!

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

> Maxim Dounin писал 2024-02-16 02:24:
> > Hello!
> > 
> > Андрей, я тебе, как и многим другим, всемерно благодарен за
> > поддержку в 2019 и после (эта история, кстати, всё ещё
> > продолжается).  Но, честно говоря, согласен с Геной - какая угодно
> > бумага этих людей бы не остановила.
> 
> Подавателей претензий - может, и не остановила бы, но сильно осложнила бы им
> юридическое оформление претензии.

Записали бы подписавшего бумагу в сообщники, не вижу проблем.  Ты 
же читал иск, который они подали в США?  Там примерно весь Рамблер 
состоял из co-conspirator'ов, и компания смогла обнаружить это 
только в 2019 году.

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

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

[...]

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

Нет, у меня нет, я в Российском деле не фигурировал (к счастью), и 
только отдельно потом давал показания со стороны защиты.

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-16 Пенетрантность Andrey Oktyabrskiy


On 2/15/24 15:15, Andrey Kopeyko wrote:

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.

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



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

Re: announcing freenginx.org

2024-02-16 Пенетрантность Slawa Olhovchenkov

On Fri, Feb 16, 2024 at 01:29:26PM +0300, Andrey Kopeyko wrote:

> Илья Шипицин писал 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, утекшее в 
> РБК в середине дня) писали люди плохо знакомые с историей Рамблера, 
> поэтому изложенных там "фактов" не существовало в природе. И я точно 
> указал где в доказательной базе следствия содержится строгое 
> доказательство отсутствия этих "фактов".

я позанудничаю -- фееричность-то в чем?
в том, что прекращений по такой формулировке предельно мало?
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-16 Пенетрантность Slawa Olhovchenkov

On Fri, Feb 16, 2024 at 10:51:13AM +0100, Илья Шипицин wrote:

> пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov :
> 
> > On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:
> >
> > > Примерно в середине марта 2020 года началось явное, наблюдаемое извне,
> > > отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае
> > > вынесением постановления о закрытии дела с феерической формулировкой
> > > "... в связи с отсутствием факта преступления".
> >
> > а что феерического в данной формулировке?
> >
> 
> ну, первое столкновение с правовой системой вызывают эмоции.
> 
> когда в 10-й раз видишь примерно одни и те же патерны, это приедается.
> возможно, Андрею каждый раз как первый )) или до 2019-го бог его хранил от
> правоохранителей

я ничего не понял в том, что ты хотел сказать
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-16 Пенетрантность 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

2024-02-16 Пенетрантность Илья Шипицин

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

> On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:
>
> > Примерно в середине марта 2020 года началось явное, наблюдаемое извне,
> > отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае
> > вынесением постановления о закрытии дела с феерической формулировкой
> > "... в связи с отсутствием факта преступления".
>
> а что феерического в данной формулировке?
>

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

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

> ___
> 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

Re: announcing freenginx.org

2024-02-16 Пенетрантность Slawa Olhovchenkov

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

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

а что феерического в данной формулировке?
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-16 Пенетрантность Evgeniy Berdnikov

On Thu, Feb 15, 2024 at 10:55:15PM +0200, Gena Makhomed wrote:
> On 15.02.2024 22:06, Evgeniy Berdnikov wrote:
> 
> > Вы много чего написали, но не ответили на вопрос, сколько это будет стоить.
> > Без реального ценника все рассуждения превращаются в схоластику...
> 
> Так Вы же не мне этот вопрос задавали, а знатокам.
> 
> Не понимаю, почему Вас так сильно интересует
> ответ на вопрос, сколько это будет стоить ?
> 
> Вы собираетесь все переводить в деньги и все изменять только деньгами?

 Так я написал: без ценовой конкретики эти дискуссии становятся схоластикой.
 Нужно соизмерять свои желания со своими возможностями.
 Регистрация брендов -- занятие, доступное тем, у кого бизнес на миллионы,
 и есть серьёзная потребность этот бизнес защищать.

 Для открытого проекта намного проще десять раз поменять название, чем
 заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL
 поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим
 сделать не может, а сборщики дистрибутивов стали раздавать пакет автора,
 а не сборку Оракла. Причём там была похожая ситуация: пришли манагеры,
 привыкшие к жёсткой иерархии и принципу "начальник всегда прав",
 подключили штатных оракловских разрабов и погнали патчи, которые открыто
 не обсуждались и потому не всегда даже были понятны старым разработчикам.
 Итог закономерен.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-16 Пенетрантность 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

2024-02-16 Пенетрантность Илья Шипицин

пт, 16 февр. 2024 г. в 00:25, 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 через пару недель.
>

ок, договорились.

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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-16 Пенетрантность Vitaliy Okulov

Зачем запугивать? =)

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


пт, 16 февр. 2024 г. в 10:45, Alex Domoradov :

> > Да ты, однако, оптимист! :))
>
> Был бы человек, а дело всегда найдется ( с )
>
> On Fri, Feb 16, 2024 at 1:25 AM Andrey Kopeyko  wrote:
>
>> Илья Шипицин писал 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
>>
> ___
> 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

Re: announcing freenginx.org

2024-02-15 Пенетрантность Alex Domoradov

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

Был бы человек, а дело всегда найдется ( с )

On Fri, Feb 16, 2024 at 1:25 AM Andrey Kopeyko  wrote:

> Илья Шипицин писал 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-15 Пенетрантность Илья Шипицин

Илья Шипицин писал 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

2024-02-15 Пенетрантность Maxim Dounin

Hello!

On Thu, Feb 15, 2024 at 11:20:07PM +0300, Andrey Kopeyko wrote:

> Gena Makhomed писал 2024-02-15 22:20:
> > 
> > Насколько я понимаю, у Максима расчет на то, что F5 не позволит
> > никому постороннему зарегистрировать торговую марку freenginx,
> > и при этом сама F5 не будет выдвигать никаких претензий проекту
> > freenginx, потому что этот проект является полностью свободным
> > и полностью некоммерческим.
> 
> Это ровно та же ошибка, которую в 2011 году совершил Игорь Сысоев -
> увольняясь из Рамблера,
> он удовлетворился словами рулей что "никаких претензий к нему по поводу
> nginx у них нет"
> (в webarchive есть интервью PR-щика Рамблера помершему уже изданию с этими
> словами, ссылка у меня в ФБ заначена)
> и не удосужился закрепить это отсутствие претензий на бумаге.
> 
> Результат такой беспечности налицо - многие (и из этого листа тоже)
> запомнили 12.12.2019 как день плотного общения со следователями СК.
> 
> Мне лично очень не понравилось, как я провёл тот день.
> Да и последующие 4 месяца оказались для меня излишне дорогими. Но как
> адвокат - Тимофей Мусатов был очень хорош.

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

> Макс,
> 
> на наступай плиз на эти грабли ещё раз.
> 
> Либо получи от F5 письменный "отказ от претензий" (не берусь даже оценить
> насколько это реально...)
> 
> Либо готовься всё время дрожать как осиновый лист.

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

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

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

чт, 15 февр. 2024 г. в 21:20, 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org


On 15.02.2024 22:06, Evgeniy Berdnikov wrote:


Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку
хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия,
плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать
Европу и Китай?



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


Так Вы же не мне этот вопрос задавали, а знатокам.

Не понимаю, почему Вас так сильно интересует
ответ на вопрос, сколько это будет стоить ?

Вы собираетесь все переводить в деньги и все изменять только деньгами?
То есть, если затраты меньше 50 тысяч рублей - тогда регистрируем,
а если затраты больше 50 тысяч рублей - тогда не регистрируем,
потому что это будет не выгодно? Или с какой целью Вы интересуетесь
вопросами цены регистрации торговой марки в различных юрисдикциях ?

Изначально разговор был о защите проекта freenginx от возможных наездов
со стороны владельца торговой марки NIGNX - корпорации F5 Inc.

Не понимаю Вашей логики в этом случае. Вы хотите сказать,
что если стоимость регистрации торговой марки небольшая,
то ее следует регистрировать, а если стоимость регистрации
высокая - то в таком случае не надо регистрировать торговую марку?
И не надо защищать проект freenginx от возможных проблем в будущем?

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

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


Если бы у Максима была торговая марка freenginx - в такой ситуации
он смог бы защитить свой проект, потому что репутационные потери
от действия киберсквоттеров и прочих в РФ могут быть и больше
чем 30-50 тыс.руб одноразово и ~ 25 тыс.руб раз в десять лет.



Вы, наверное, имеете методику оценки репутационных потерь, или даже
табличку конверсии для свободных проектов по текущему курсу.


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

Вы этого не знали?

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

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

Но рано или поздно эта ситуация может измениться, если/когла
Максим перепишет в freenginx большую часть функциональности,
которая есть только в nginx-plus, продукте с закрытым
исходным кодом, который принадлежит корпорации F5 Inc.

Топ-менеджеры F5 могут быть не готовы к такому развитию событий.
И самым простым и очевидным для них вариантом действия и выхода
из этой ситуации может показаться полный запрет проекту freenginx
на использование торговой марки NGINX, захват домена freenginx.org
и установка 301 редиректа на https://www.nginx.com/products/nginx/

--
Best regards,
 Gena

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

Re: announcing freenginx.org


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: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-15 Пенетрантность Evgeniy Berdnikov


On 15.02.2024 12:49, Anatoliy Melnik via nginx-ru wrote:


Если вы предлагаете писать напрямую с nginx-а в файл --
сделайте у себя ротацию файлов с интервалом 30 сек
при 200-250 тыс подключений/сек...

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



"Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное 
толкование в ту или иную сторону по желанию сторон."


Почему / зачем?


Дальнейшее перемалывание темы ротации лично для меня интереса не представляет.


Тогда прекращаем.


Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно
решать что мне надо :)


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


Решайте сами, я просто хотел понять Вашу исходную задачу X,
поэтому и задавал уточняющие вопросы.



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


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

Поэтому с моей точки зрения - я не могу признать решение
через syslog и unix socket более оптимальным, чем вариант
записи логов напрямую в файлы и ротации логов через SIGUSR1.

а ротацию логов можно делать и чаще, чем раз в 30 секунд,
например, раз 15, или раз в 10 или даже раз в 5 секунд,
если хочется уменьшить отставание статистики по времени.

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

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

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

Более надежное и более простое решение, и более экономно
расходующее процесор сервера - и будет более оптимальным.


При желании добраться из пунта А в пункт Б именно на машине и проблеме "машина не 
едет" 2 концептуальных решения:
1.Заменить машину.
2.Устранить причины "не едет" в имеющейся.
Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из строя 
запчасть.
Если провести параллели, то с моей точки зрения мне вполне достаточно запчасти.
Вы предлагаете замену машины.


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

Вот как я уже говорил, задача построения VPN - если взять все множество
таких задач, то в части случаев для построения VPN более оптимальным
вариантом будет использование WireGuard, а в части случаев - OpenVPN.
Именно потому, что WireGuard обладает некоторыми свойствами
и качествами, которые отсутствуют в OpenVPN, и наоборот,
потому что OpenVPN обладает некоторыми свойствами и качествами,
которые отсутствуют в WireGuard. И поэтому в части случаев
оказывается более оптимальным и целесообразным построение
VPN с использованием WireGuard, а в некоторых случаях
- более оптимальнныи и целесообразным оказывается
построение VPN с использованием OpenVPN.


Получить потери можно в случае использования syslog
и unix socket`ов - если читающая сторона не будет
успевать читать данные из сокета - у nginx не останется
иных варантов, кроме как дропать часть записей.

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


О появились доп. условия -- место на разделе...


Так ведь свободное место на разделе есть, с этим же нет проблем.

Если часто делать ротацию логов - его надо будет совсем не много.

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


Хотя бы даже одним только этим свойством запись логов в файлы
намного лучше записи логов в unix socket`ы.



А как же место на разделе? Замена одной проблемы другой. Только и всего.


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

Re: announcing freenginx.org

On Thu, Feb 15, 2024 at 09:20:14PM +0200, Gena Makhomed wrote:
> On 15.02.2024 16:39, Evgeniy Berdnikov wrote:
> 
> > > Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то
> > > имя, которое не является ничьей торговой маркой и для защиты этого
> > > имени - зарегистрировать свою торговую марку,
> > 
> >   Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку
> >   хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия,
> >   плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать
> >   Европу и Китай?
[...]
> См. https://en.wikipedia.org/wiki/Linux_Mark_Institute
> Неужели история учит только тому, что она ничему не учит?

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

> Если бы у Максима была торговая марка freenginx - в такой ситуации
> он смог бы защитить свой проект, потому что репутационные потери
> от действия киберсквоттеров и прочих в РФ могут быть и больше
> чем 30-50 тыс.руб одноразово и ~ 25 тыс.руб раз в десять лет.

 Вы, наверное, имеете методику оценки репутационных потерь, или даже
 табличку конверсии для свободных проектов по текущему курсу.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-15 Пенетрантность Evgeniy Berdnikov


On 15.02.2024 16:39, Evgeniy Berdnikov wrote:


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


  Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку
  хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия,
  плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать
  Европу и Китай?

  В РФ мы хотим регистрироваться? Насколько я понимаю, по российскому
  законодательству регистрация торговой марки (наименования, товарного знака)
  возможна лишь на юрлицо или ИП, а физлицу придётся заключить договор
  с какой-либо компанией, чтобы та оформила права на себя в интересах
  клиента. Какие тут для клиента риски -- отдельный вопрос...
  Регистрация в Роспатенте это где-то 30-50 тыс.руб, процедурно полгода-год,
  продление регистрации раз в 10 лет за ~ 25 тыс.руб (на сегодня).


Я понял ответ Максима, почему он выбрал имя проекта именно freenginx,
потому что именно это имя хорошо отражает суть проекта, он планируется
полностью свободным и полностью некоммерческим, как например, FreeBSD.

Тем более, что https://nginx.org/LICENSE и https://freenginx.org/LICENSE
- это есть практически та же самая BSD 2-Clause "Simplified" License,
что используется в проекте FreeBSD и является там Preferred License
for New Files.

Но: FreeBSD is a registered trademark of The FreeBSD Foundation.
Почему бы в таком случае не зарегистрировать trademark freenginx?

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

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

Вопрос только в том, позволит ли F5 зарегистрировать торговую
марку freenginx самому Максиму или freenginx Foundation, стоящей
за проектом? Может и не позволить, потому что торговые марки,
как правило, используются для ведения бизнеса и продажи
товаров и услуг. И поэтому Максим не хочет их дразнить,
чтобы не провоцировать на запрет использования проектом
freenginx торговой марки NGINX, принадлежащей F5 Inc. ?

Возможно я тут зря развожу панику и у F5 выбор есть только между
плохим и очень плохим вариантами и поэтому они в текущий момент
времени не будут ничем препятствовать работе проекта freenginx.

Но если Максим реализует в freenginx под открытой и свободной
лицензией BSD 2-Clause "Simplified" License все те возможности,
которые сейчас присутствуют в nginx-plus - в F5 такому развитию
событий могут быть совсем не рады, потому что они могут быть
не готовы переходить на ту модель работы, которую использует
компания Percona, когда весь код всех их продуктов доступен
под открытой и своободной лицензией и компания зарабатывает
только лишь на оказании услуг технической поддержки клиентам.

И поскольку цель любой коммерческой компании и корпорации -
это заработать как можно больше денег - деятельность проекта
freenginx будет проитиворечить этим интересам корпорации F5,
и они вполне могут принять решение о защите своей торговой
марки и запрете использования торговой марки NGINX проектом
freenginx. Разумеется, тогда можно будет просто преименовать
проект, и продолжить и дальше делать все то же, что и делали
раньше - если в F5 понимают, что тогда они вообще никак
не смогут влиять на Максима и на проект freenginx,
после переименования проекта, потому что лицензия
на код - та же BSD 2-Clause "Simplified" License,
которая никаких ограничений на Максима не налагает.

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

Не знаю, как тут лучше будет поступить - действительно ли F5
будет по всему миру блокировать регистрацию торговой марки
freenginx и действительно ли F5 всегда будет защищать проект
freenginx, даже в том случае, когда Максим начнет в Open Source
реализовывать ту функциональность, которая сейчас присутствует
только в коммерческой версии с закрытыми исходными текстами nginx-plus.

А в чем тогда будет мотивация у F5 ничем не мешать деятельности проекта
freenginx, если в этой ситуации деятельность проекта freenginx будет
непосредственно уменьшать прибыль корпорации F5? Как долго они будут
это терпеть и ничего не предпринимать, чтобы защитить свою прибыль?

Ведь рано или поздно возникнет ситуация конфликта интересов, когда
Максим начнет в freenginx реализовывать уже тот функционал, который
есть только в nginx-plus, BIG-IP, BIG-IQ и других продуктах F5 Inc.

Томасу Джозефу Даннингу принадлежит широко известное высказывание
о сути капитализма, процитированное Карлом Марксом в «Капитале»
и потому часто ошибочно ему

Re: announcing freenginx.org

On Thu, Feb 15, 2024 at 03:17:04AM +0200, Gena Makhomed wrote:
> Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то
> имя, которое не является ничьей торговой маркой и для защиты этого
> имени - зарегистрировать свою торговую марку,

 Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку
 хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия,
 плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать
 Европу и Китай?

 В РФ мы хотим регистрироваться? Насколько я понимаю, по российскому
 законодательству регистрация торговой марки (наименования, товарного знака)
 возможна лишь на юрлицо или ИП, а физлицу придётся заключить договор
 с какой-либо компанией, чтобы та оформила права на себя в интересах
 клиента. Какие тут для клиента риски -- отдельный вопрос...
 Регистрация в Роспатенте это где-то 30-50 тыс.руб, процедурно полгода-год,
 продление регистрации раз в 10 лет за ~ 25 тыс.руб (на сегодня).
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-15 Пенетрантность Alex Domoradov

> Во-первых, название freenginx - хорошо отражает суть проекта.
Поэтому оно и было выбрано.

> Во-вторых, я, конечно, не юрист, но freenginx и NGINX - это два
разных названия, и вероятность успешных претензий я оцениваю как
небольшую.  Кроме того, неявное разрешение на использование
торговой марки подразумевается лицензией.

JFYI

например тот же форк terraform - назвали opentofu, а не open/free/libre
terraform. Как раз во избежание претензий со стороны Hashicorp

On Thu, Feb 15, 2024 at 2:16 PM Andrey Kopeyko  wrote:

> 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org


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

2024-02-15 Пенетрантность raven...@megaline.kg

On 15.02.2024 12:18, Maxim Dounin wrote:

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

http://freenginx.org/

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

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

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

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

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

Спасибо за ссылки.  Тут есть несколько факторов:

Во-первых, название freenginx - хорошо отражает суть проекта.
Поэтому оно и было выбрано.

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

Да, действительно есть отдельная торговая марка FREEBSD
https://trademarks.justia.com/850/90/freebsd-85090213.html

и когда-то раньше была отдельная торговая марка BSD
https://trademarks.justia.com/741/43/bsd-74143159.html

Если у Вас получится зарегистрировать новую торговую марку
freenginx - тогда да, все нормально и домен у Вас не отберут.

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

А до того момента, пока отдельной торговой марки freenginx нет
- вероятность успешности претензий со стороны F5 очень высокая.

Кроме того, хотя Вас зовут и не Linus Torvalds, но в данном случае
- вполне может произойти аналогичная ситуация, когда кто-то другой
зарегистрирует на себя торговую марку freenginx и будет требовать с Вас
деньги за право использования этой торговой марки, уже его собственности
по аналогии с https://en.wikipedia.org/wiki/Linux_Mark_Institute

Так что риски и угрозы тут есть - не только со стороны F5,
если проект не будет защищен наличием своей торговой марки.

Кроме того, неявное разрешение на использование
торговой марки подразумевается лицензией.

Лицензия https://nginx.org/LICENSE относится только к коду,
она же не дает права на использование чужой торговой марки.

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

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

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

Когда проект freenginx будет строиться только на личные деньги одного
человека - что произойдет с проектом, когда у этого человека закончатся
деньги или когда у него наступит момент End of Life? Что произойдет
с проектом freenginx после того как lifecycle of Maxim Dounin будет
завершен? Ведь даже продлить регистрацию домена freenginx.org тогда как?

Если freenginx - это будет основная ветка, то защита очень желательна.

On 15.02.2024 12:31, Maxim Dounin wrote:

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

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

Gregory Kurtzer защитил проект Rocky Linux от подобных угроз и рисков.

Три торговые марки

Rocky Enterprise Software Foundation™
RESF™
Rocky Linux™

зарегистрированы на Rocky Enterprise Software Foundation,
так что тут есть и защита от Bus Factor и защита домена rockylinux.org
- сделано все очень грамотно. И есть отдельно CIQ коммерческая компания,
CIQ is the official founding support and services partner and sponsor
of Rocky Linux. CIQ’s CEO, Gregory Kurtzer, is the also founder
of Rocky Linux.

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

On 15.02.2024 9:17, Andrey Kopeyko wrote:

> Если хочешь, могу попробовать

Re: announcing freenginx.org


Боюсь, придется с этим смириться и перебороть свою лень)
https://mailman.nginx.org/pipermail/nginx-devel/2024-February/YIFSHIYSKDFBYZ2QRA3WF6SRPGIBDBKI.html

15.02.2024 17:24, izor...@gmail.com пишет:


Добрый день, Raven.


Только вот вполне вероятно, что большинству людей проще работать с 
git. Я как


пытался сделать несколько коммитов mercurial, а потом 
подкорректировать их,


но в итоге не справился :( А дальше было лень разбираться.

Да и в web-интерфейсе mercurial нет возможности создать вопросы и/или 
отправить


PR. Для этого надо писать письмо с вложенным патчем.

Вы писали 15 февраля 2024 г., 13:27:29:


В каком-то из обсуждений Максим упоминал, что не сторонник git и
связанных с ним технологий. Так, что наверное все, что прибито к
git гвоздями здесь не поможет. Discourse да, возможно и взлетит,
но это наверное больше для пользователей, а не для обсуждения
разработки.


--
С уважением,
 Izorkin mailto:izor...@gmail.com 

___
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

Re: announcing freenginx.org

2024-02-15 Пенетрантность izorkin

Добрый день, Raven. 

Только вот вполне вероятно, что большинству людей проще работать с git. Я как
пытался сделать несколько коммитов mercurial, а потом подкорректировать их,
но в итоге не справился :( А дальше было лень разбираться.
Да и в web-интерфейсе mercurial нет возможности создать вопросы и/или отправить
PR. Для этого надо писать письмо с вложенным патчем.
 
 
Вы писали 15 февраля 2024 г., 13:27:29:

> В каком-то из обсуждений Максим упоминал, что не сторонник git и связанных с 
> ним технологий. Так, что наверное все, что прибито к git гвоздями здесь не 
> поможет. Discourse да, возможно и взлетит, но это наверное больше для 
> пользователей, а не для обсуждения разработки.

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-15 Пенетрантность Anatoliy Melnik via nginx-ru

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: Тест nginx -- сколько сообщений в log syslog без потерь?





Gena Makhomed Wrote: 
--- 
> On 14.02.2024 13:30, Anatoliy Melnik via nginx-ru wrote: 
> 
> >>> Если вы предлагаете писать напрямую с nginx-а в файл -- 
> >>> сделайте у себя ротацию файлов с интервалом 30 сек 
> >>> при 200-250 тыс подключений/сек... 
> >>> 
> >>> Если у вас уже есть такое рабочее решение - 
> >>> поделитесь опытом, буду рад вас выслушать. 
> 
> >> В этом сообщении Вы говорите о том, что Вы пробовали писать логи 
> >> "напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд, 
> >> при при 200-250 тыс подключений/сек, и у Вас не получилось 
> >> создать "рабочее решение". 
> 
> > Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО! 
> > Я сказал ровно то, что и хотел сказать. 
> > Где вы прочитали про "не получилось" ??? 
> > Пожалуйста процитируйте... без своих домыслов и фантазий. 
> 
> А Вы помните, на какой именно мой вопрос Вы отвечали? Напомню: 
> https://mailman.nginx.org/pipermail/nginx-ru/2024-February/L3UKQXO2PKI 
> HBFWHHTQRKDQY53XGE5BN.html 
> 
> Я же практически прямым текстом Вам написал, что Ваша попытка 
> выжать максимум производительности из связки nginx-syslog - 
> это есть проблема Y и задал Вам вопрос, какую именно проблему X 
> Вы таким способом пытаетесь решить. И что я слышу в ответ - 
> что Вы не смогли получить работающую систему при 200-250 тысяч 
> подключений в секунду и при ротации логов раз в 30 секунд - именно 
> это и значают Ваши слова "Если у вас уже есть такое рабочее решение 
> - поделитесь опытом, буду рад вас выслушать" - если Вы спрашиваете, 
> как именно построить рабочую систему ротации логов при такой 
> нагрузке, 
> то логично предположить, что Вы попытались это сделать, у Вас это 
> не получилось и Вы тогда пошли другим путем - писать логи 
> через syslog unix socket`ы, потому что там ротации не надо делать. 
> 

Сойдемся на формулировке: 
"Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее 
двойное толкование в ту или иную сторону по желанию сторон." 
Если таковая вас устроит. 

Дальнейшее перемалывание темы ротации лично для меня интереса не представляет. 
Т.к. концептуально является переливанием из пустого в порожнее. 
> 
> Читать из unix socket`а удобно, паралельно в 10 потоков, 
> а читать из одного текстового лог-файла - неудобно? 
> А в чем именно неудобство чтения логов из файла? 
> 
> > Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются 
> запросы. 
> > Обращения жестко делятся на несколько типов, тип определяется 
> значением переменной в запросе, запросы БЕЗ этой переменной 
> игнорируются. 
> > Беки ведут статистику сколько и какого типа запросов они получили, 
> эти данные сливаются в БД и хранятся с дискретностью 20минут. 
> > 
> > Регулярно требуется "нестандартная" статистика, например 
> > "средний размер ($body_bytes_sent) по запросам типа "sc012" за 
> сутки" 
> > "соотношение обращений по http и https ($schema) по запросам типа 
> "q1wr" за час" 
> > "наименьшее/среднее/наибольшее время ($request_time) по запросам 
> типа "sc012" за..." 
> > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) 
> в общем объеме трафика (сумма $body_bytes_sent всех запросов)" 
> > и т.д. 
> > нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в 
> логах реверс-прокси. 
> 
> Если Вам не достаточно тех метрик, которые Angie 
> умеет отдавать напрямую в Prometheus, рассматривали 
> ли Вы как вариант решения своей задачи улититы 
> 
> https://github.com/google/mtail 
> 
> https://github.com/timberio/vector 
> 
> ? 
Нет, не рассматривал. 
На данном этапе не интересно и не вижу необходимости ломать имеющееся. 

> 
> Referer: https://github.com/freeseacher/metrics_ru_faq 
> 
> 
> > как минимум создам дополнительную нагрузку на сетевой стек ОС-и, ибо 
> tcp как ни крути более затратен по сравнению с unixSocket. 
> > Или с высокой вероятностью упрусь в теже ограничения unixSocket если 
> отказаться от tcp со всеми дальше вытекающими. 
> > При размещении на другом сервере решить проблему исчерпания портов 
> для соединения прокси-проски. (а их "в моменте" 350-400 тыс), да, без 
> body их будет меньше, но все-таки довольно много. 
> 
> если использовать keepalive в блоке upstream, то не упретесь, 
> потому что одно и то же соединение к backend`у будет повторно 
> использоваться для отправки на backend большого количества запросов, 
> и не будет такой ситуации, что на каждый запрос открывается новое 
> подлюкчение к backend`у, так что исчерпания портов не произойдет. 
> дефолтовое значение proxy_http_version 1.0 - это плоая идея, потому 
> что в http 1.0 коцен файла - это закрытие соедения, а оно может быть 
> и по причине ошибки, и nginx будет тогда отдавать битые ответы. 
> Если включить proxy_http_version 1.1 - такой проблемы не будет. 
> И заодно - можно будет использовать http keepalive 
> при подключении к backend`у, чтобы по одному tcp 
> соединению передавать большое количество запросов. 
> 
> > Моя проблема "Х": 
> >

Re: announcing freenginx.org

2024-02-15 Пенетрантность Maxim Dounin

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 лет они на этом не одну собачью стаю съели, и по буржуйским
> доменам тоже.

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-15 Пенетрантность raven...@megaline.kg

В каком-то из обсуждений Максим упоминал, что не сторонник git и
связанных с ним технологий. Так, что наверное все, что прибито к git
гвоздями здесь не поможет. Discourse да, возможно и взлетит, но это
наверное больше для пользователей, а не для обсуждения разработки.

15.02.2024 16:20, izor...@gmail.com пишет:

Добрый день, Raven.

Как вариант есть новый формат форумов на базе flarum и discourse.

Ещё можно поднять свой git репозиторий на базе Gitea/Forgejo. К тому

же в Forgejo планируется внедрение протокола ForgeFed, который позволит

создавать запросы и PR между другими git инстансами:

https://forgefed.org

Вы писали 15 февраля 2024 г., 5:41:17:

Форумы давно мертвы как формат общения. Исправно рабатают только
старые площадки, с давно наруленным сообществом, но и они
переживают не лучшие времена. Списки рассылки, кстати,
направляются туда же. Всем теперь issues на github-е подавай :smile:

--
С уважением,
Izorkin mailto:izor...@gmail.com

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

Re: announcing freenginx.org

2024-02-15 Пенетрантность izorkin

Добрый день, Raven.

Как вариант есть новый формат форумов на базе flarum и discourse.
Ещё можно поднять свой git репозиторий на базе Gitea/Forgejo. К тому
же в Forgejo планируется внедрение протокола ForgeFed, который позволит
создавать запросы и PR между другими git инстансами:
https://forgefed.org 
 
 
Вы писали 15 февраля 2024 г., 5:41:17:
> Форумы давно мертвы как формат общения. Исправно рабатают только старые 
> площадки, с давно наруленным сообществом, но и они переживают не лучшие 
> времена. Списки рассылки, кстати, направляются туда же. Всем теперь issues на 
> github-е подавай

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-15 Пенетрантность Maxim Dounin

Hello!

On Thu, Feb 15, 2024 at 03:17:04AM +0200, Gena Makhomed wrote:

> 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. Вам не давала, и скорее всего, что никгда не даст.
> 
> А вот дальнейшее развитие событий предусмотреть совсем не трудно.
> Они будут преследовать Вас в судебном порядке за trademark infringement

Спасибо за ссылки.  Тут есть несколько факторов:

Во-первых, название freenginx - хорошо отражает суть проекта.  
Поэтому оно и было выбрано.

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

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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: announcing freenginx.org

2024-02-14 Пенетрантность 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: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-14 Пенетрантность Gena Makhomed


On 14.02.2024 13:30, Anatoliy Melnik via nginx-ru wrote:


Если вы предлагаете писать напрямую с nginx-а в файл --
сделайте у себя ротацию файлов с интервалом 30 сек
при 200-250 тыс подключений/сек...

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



В этом сообщении Вы говорите о том, что Вы пробовали писать логи
"напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд,
при при 200-250 тыс подключений/сек, и у Вас не получилось
создать "рабочее решение".



Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО!
Я сказал ровно то, что и хотел сказать.
Где вы прочитали про "не получилось" ???
Пожалуйста процитируйте... без своих домыслов и фантазий.


А Вы помните, на какой именно мой вопрос Вы отвечали? Напомню:
https://mailman.nginx.org/pipermail/nginx-ru/2024-February/L3UKQXO2PKIHBFWHHTQRKDQY53XGE5BN.html

Я же практически прямым текстом Вам написал, что Ваша попытка
выжать максимум производительности из связки nginx-syslog -
это есть проблема Y и задал Вам вопрос, какую именно проблему X
Вы таким способом пытаетесь решить. И что я слышу в ответ -
что Вы не смогли получить работающую систему при 200-250 тысяч
подключений в секунду и при ротации логов раз в 30 секунд - именно
это и значают Ваши слова "Если у вас уже есть такое рабочее решение
- поделитесь опытом, буду рад вас выслушать" - если Вы спрашиваете,
как именно построить рабочую систему ротации логов при такой нагрузке,
то логично предположить, что Вы попытались это сделать, у Вас это
не получилось и Вы тогда пошли другим путем - писать логи
через syslog unix socket`ы, потому что там ротации не надо делать.

А невозможность получить "такое рабочее решение" при таких параметрах
нагрузки может быть вызвана только тем, что ротацию логов Вы делали
через SIGHUP а не через SIGUSR1.

То есть, я так и понял Ваш ответ на мой вопрос, что проблемой X,
которую Вам не удалось решить, является проблема ротации логов
nginx раз в 30 секунд при нагрузке в 200-250 тыс подключений/сек.

И поэтому - Вы, вместо того, чтобы искать решение проблемы Х,
начали решать проблему Y - искать способы, как оптимизировать
работу связки nginx-syslog - заведомо более затратный по ресурсам
способом, по сравнению с обработкой и ротацией логов по SIGUSR1.

И если я Вам задаю вопрос о том, в чем именно состоит Ваша проблема X,
которую Вы пытаетесь решить, а в ответ слышу про количество подключений
в секунду и интервал ротации раз в 30 секунд и "Если у вас уже есть
такое рабочее решение - поделитесь опытом, буду рад вас выслушать",
то что еще мне оствалалось подумать в этой ситуации, и каким еще
образом я мог бы понять Ваши слова? Вот попробуйте поставить себя
на мое место и посмотреть на эту ситуацию с моей точки зрения,
когда Вы задаете кому-то такой вопрос и слышие такой ответ.

И все последующее - это уже следствие того, что Вы начали
говорить, что syslog-unix socket-python - это есть решение
проблемы X. А сама проблема X у вас появилась из-за использования
SIGHUP дял ротации логов, вместо SIGUSR1. Понятно, что при таких
парметрах, 200-250 подключений в секунду и интервале ротации раз
в 30 секунд ничего работать не будет. Но при использовании SIGUSR1
- нет проблем, вне зависимости от того, какое там количество подключений
в секунду, 200 тысяч 250 тысяч или какое-либо еще, потому что рабочие
процессы при ротации через SIGUSR1 не перезапускаются, а всего лишь
переоткрывается лог-файл, что происходит практически мгновенно
и это очень дешевая операция, много ресурсов она не занимает.

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

Я и поделился с Вами опытом - используйте SIGUSR1
вместо SIGHUP и тогда Ваша проблема X будет решена
и тогда не надо будет заниматься поиском решения
для проблемы Y - как сделать, чтобы связка nginx-syslog
через unix socket не глючила и не теряла сообщения.

Причина проблемы ведь не в nginx, причина проблемы
в syslog, потому что он читает данные в один поток,
и не успевает их обрабатывать. А когда вы создаете
10 потоков на Python - то вы увеличиваете мощность
"читателя" в 10 и более раз, потому что в такой
ситуации в каждый из unix socket`ов уходит в 10 раз
меньше сообщений и тогда читающая сторона успевает
эти сообщения читать и поэтому у nginx нет причин
чтобы дропать сообщения из-за того, что syslog
не успевает их читать из unix socket`а.


Причина, почему у Вас не получилось настроить ротацию лог-файлов
при записи логов "напрямую с nginx-а в файл" может быть в такой
ситуации только одна - для ротации лог-файлов Вы использовали
сигнал HUP а не сигнал USR1 - именно поэтому у Вас не получилось.



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


Я именно так и понял Ваш ответ:

>>> Если

Re: announcing freenginx.org

2024-02-14 Пенетрантность raven...@megaline.kg


15.02.2024 01:25, izor...@gmail.com пишет:

Некоторым людям удобнее работать с форумом, попробовать можно :)


Форумы давно мертвы как формат общения. Исправно рабатают только старые 
площадки, с давно наруленным сообществом, но и они переживают не лучшие 
времена. Списки рассылки, кстати, направляются туда же. Всем теперь 
issues на github-е подавай :smile:
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-14 Пенетрантность Gena Makhomed


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. Вам не давала, и скорее всего, что никгда не даст.

А вот дальнейшее развитие событий предусмотреть совсем не трудно.
Они будут преследовать Вас в судебном порядке за 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 - тогда
шансов удержать контроль над этим доменом - практически нет,
ведь Вы же здесь без их разрешения используете их торговую марку.

Это примерно то же самое, что кто-то зарегистрирует домен
freewindows.org и попробует создавать там Open Source
конкурента для Microsoft Windows. Не будет это работать.

Например, если компания Microsoft отобрала даже домен MikeRoweSoft.com
у канадского студента Mike Rowe который занимался веб-дизайном,
то и домен freewindows.org она точно так же отберет.
https://en.wikipedia.org/wiki/Microsoft_v._MikeRoweSoft

Да и

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-14 Пенетрантность Anatoliy Melnik via nginx-ru





Evgeniy Berdnikov Wrote: 
--- 
> On Wed, Feb 14, 2024 at 02:30:57PM +0300, Anatoliy Melnik via nginx-ru 
> wrote: 
> > Все как раз получилось, дальше с этим работать было неудобно. 
> > К тупой записи в файл претензий не было. 
> 
> Вы не сообщили, почему "дальше с этим работать было неудобно". 
> Может, поясните? Если посмотреть на озвученный список задач -- 
> 
> > Зачем мне это нужно: 
> [...] 
> > Регулярно требуется "нестандартная" статистика, например 
> > "средний размер ($body_bytes_sent) по запросам типа "sc012" за 
> сутки" 
> > "соотношение обращений по http и https ($schema) по запросам типа 
> "q1wr" 
> > за час" 
> > "наименьшее/среднее/наибольшее время ($request_time) по запросам 
> типа 
> > "sc012" за..." 
> > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких 
> запросов) в 
> > общем объеме трафика (сумма $body_bytes_sent всех запросов)" 
> > и т.д. 
> 
> то вроде трудно придумать что-то проще и эффективней, чем прост 
> парсинг 
> логов. А лог что из файла, что из пайпа, что из сокета читается 
> абсолютно одинаково, одним и тем же read(), и парсится одинаково. 
> 
> Но из файла якобы неудобно! Чем же неудобно, почему? При чём тут 
> вообще 
> какие-то unix-сокеты, если задача в разборе последовательно идущих 
> строк 
> и каких-то элементарных вычислениях? 

1. первоначально логи сливались по сети и централизованно считались.(без записи 
в файлы) 
при высоких нагрузках пошли расхождения. 
2. Хорошо -- пусть каждый прокси сам свое считает: исключаются потери по сети, 
каждый прокси в этом плане становится автономно-независимой единицей. 
При высоких нагрузках -- расхождения в статистике. 
3. Хорошо, запишем в файл прям с nginx-а. файл распарсим-посчитаем. 
3а.простыми методами (типа grep и awk) обработка статистики за 30 секунд 
занимает больше 30 секунд. 
3б.пишем в файл->читаем из файла->удаляем файл в объемах 30-60Мбайт/сек... 
лично мое мнение - файл тут явно лишний. (Ваше мнение может отличатся от моего, 
я абсолютно не настаиваю). 


> 
> > Чисто техничски можно и без access-логов, будете сами 
> реализовывать нечто 
> > подобное -- выберете более близкое вам решение. 
> 
> Вы не назвали альтернативные решения. 
Это сделали за меня: 
Написать свой бекэнд (как вариант на Go) и отзеркалировать туда запросы с 
фронотов 
Не имею ничего против -- реализовуйте! Я не настаиваю на своем варианте. 
Не продвигаю как единственно правильный (или у вас иное мнение?) 

> 
> > Мой вариант также страдает набором недостатков, но поставленные 
> задачи 
> > решает с устраивающей меня эффективностью. 
> 
> Вы не конкретизировали, какие недостатки видите у своего варианта и 
> почему его плюсы по сравнению с другими подходами перевешивают. 
Ну почему же? 
Недостатки: 
Скорее всего более высокая нагрузка на CPU по сравнению с альтернативой 
(замеров и испытаний никто не проводил, это чисто теоретический вывод) 
Предположительно масштабируемость моего решения хуже по сравнению с 
предложенной альтернативой (чисто теоретический вывод) 
Т.к. я не программист -- само качество решения в плане программного кода далеко 
от идеала. 
Жесткое неприятие выбранного мной подхода со стороны некоторых участников 
обсуждения (почему-- для меня до сих пор загадка). 
Плюсы: 
При передаче всего этого хозяйства дальше на обслуживание в моем варианте 
разберется любой начинающий питонист, в предложенной схеме с зеркалированием 
квалификация нужна будет повыше мне кажется. 
Запаса по вычислительной мощности более чем достаточно. 
На существующих мощностях практически гарантированный порог 720тыс/сек. 
прогнозируемый, (исходя из показателей работы системы на 240тыс/сек на одном 
сервере) -- порядка 1.1-1.2 млн./сек. 
Что в 3 (проверенный) и 5 (прогноз) раз превышает имеющийся на данный момент 
уровень. 
Чего хватает на 4-5 лет при росте нагрузки на 22-24% ежегодно. (имеющийся на 
данный момент прогноз оптимистичный оценивается максимум в 14-16% в год) 
Затраты времени на реализацию значительно меньше, чем вариант со своим 
бекэндом. 



> 
> > Свой вариант я могу абсолютно спокойно масштабировать до 
> необходимых мне 
> > значений, и эти значения почти на порядок выше текущих нагрузок. 
> 
> Вы крутейший специалист :)) в своих собственных глазах, конечно. 
Из лабиринтов собственных заблуждений скорее выберется тот, кто готов признать, 
что он заблуждается. 
Лично я этот путь приодолел не единожды. Чего и вам желаю. 
> 
> > Концптуальная ошибка в этом опусе -- вы не обслуживание клиентов. 
> > И "непродуктивность пути" определяете в данной конкретной 
> ситуации не вы. 
> > И конечную реализацию делаете не вы. 
> > И за результаты отвечаете не вы. 
> > Как и ответственность за все выполненное в итоге так же не на 
> вас. 
> 
> И что, это лишает собеседника право высказать своё мнение о 
> правильности 
> постановки задачи? 
Откуда такие выводы? 
Собеседник не единожды высказал свое мнение и даже больше. 
Придумал у меня проблему, которой нет. Привел для нее

Re: announcing freenginx.org

2024-02-14 Пенетрантность izorkin

Добрый вечер, Максим.

Удачи, надеюсь всё получится!

Вы писали 14 февраля 2024 г., 22:06:08:

> С учётом деталей - скорее, форк остался у F5.  Развиваться будет 
> мной и теми, кто решит присоединиться.

Ну с этим вроде как уже помогаю :)
На данный момент у меня висит вопрос с MIME-типами. Хотелось бы уже
решить этот вопрос, актуализировать список и синхронизировать его со
списком в NixOS :)

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

Тут я имел не коммерческое использование, а анонсирование новых версий,
каких-либо новостей, опросов на добавление какой-либо функциональности.
В сети Fediverse сидят много технических специалистов :)
Некоторым людям удобнее работать с форумом, попробовать можно :)
> Нет, и опять же нет.  Продвижение особого смысла не имеет, проект 
> строго некоммерческий и не предполагает каких-либо коммерческих 
> перспектив.  Что до форумов, то это совершенно не мой формат 
> общения.


-- 
С уважением,
 Izorkin  mailto:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-14 Пенетрантность izorkin

Добрый вечер, Максим.

Удачи, надеюсь всё получится!

Вы писали 14 февраля 2024 г., 22:06:08:

> С учётом деталей - скорее, форк остался у F5.  Развиваться будет 
> мной и теми, кто решит присоединиться.

Ну с этим вроде как уже помогаю :)
На данный момент у меня висит вопрос с MIME-типами. Хотелось бы уже
решить этот вопрос, актуализировать список и синхронизировать его со
списком в NixOS :)

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

Тут я имел не коммерческое использование, а анонсирование новых версий,
каких-либо новостей, опросов на добавление какой-либо функциональности.
В сети Fediverse сидят много технических специалистов :)
Некоторым людям удобнее работать с форумом, попробовать можно :)
> Нет, и опять же нет.  Продвижение особого смысла не имеет, проект 
> строго некоммерческий и не предполагает каких-либо коммерческих 
> перспектив.  Что до форумов, то это совершенно не мой формат 
> общения.


-- 
С уважением,
 Izorkin  mailto:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-14 Пенетрантность Maxim Dounin

Hello!

On Wed, Feb 14, 2024 at 09:32:54PM +0300, izor...@gmail.com wrote:

> Добрый вечер, Максим.
> 
> Печально всё это слышать...
> Будет развиваться как очередной форк Nginx или каким-то другим 
> способом будет вестись разработка?

С учётом деталей - скорее, форк остался у F5.  Развиваться будет 
мной и теми, кто решит присоединиться.

[...]

> > Так что, начиная с сегодняшнего дня, я больше не участвую в
> > разработке nginx'а в рамках F5.  Вместо этого я запускаю
> > альтернативный проект, управлять которым будут разработчики, а не
> > корпоративные структуры:
> 
> > http://freenginx.org/
> 
> Какая помощь приветствуется не из области программирования?)

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

> Нет ли желания продвижения в сети Fediverse (микро-блог, аналог
> Twitter)?
> Нет ли в планах поднять какой-нибудь небольшой форум?

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

2024-02-14 Пенетрантность izorkin

Добрый вечер, Максим.

Печально всё это слышать...
Будет развиваться как очередной форк Nginx или каким-то другим 
способом будет вестись разработка?

Вы писали 14 февраля 2024 г., 20:59:51:

> Hello!

> Как вы, вероятно, знаете, компания F5 закрыла офис в Москве в 2022
> году, и с тех пор я не работают в F5.  Однако после закрытия офиса
> мы достигли соглашения, что я сохраняю свою роль в разработке
> nginx'а как волонтёр.  И почти два года я занимался тем, что
> развивал nginx, делая его лучше для всех.

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

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

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

> http://freenginx.org/


Какая помощь приветствуется не из области программирования?)
Нет ли желания продвижения в сети Fediverse (микро-блог, аналог
Twitter)?
Нет ли в планах поднять какой-нибудь небольшой форум?
> Цель проекта - обеспечить разработку nginx'а, свободную от
> произвольного корпоративного вмешательства.  Помощь и участие
> приветствуются.  Надеюсь, проект будет полезен для всех.


-- 
С уважением,
 Izorkin  mailto:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

announcing freenginx.org

2024-02-14 Пенетрантность Maxim Dounin

Hello!

Как вы, вероятно, знаете, компания F5 закрыла офис в Москве в 2022
году, и с тех пор я не работают в F5.  Однако после закрытия офиса
мы достигли соглашения, что я сохраняю свою роль в разработке
nginx'а как волонтёр.  И почти два года я занимался тем, что
развивал nginx, делая его лучше для всех.

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

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

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

http://freenginx.org/

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


-- 
Maxim Dounin
http://freenginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

2024-02-14 Пенетрантность Evgeniy Berdnikov

On Wed, Feb 14, 2024 at 02:30:57PM +0300, Anatoliy Melnik via nginx-ru wrote:
>Все как раз получилось, дальше с этим работать было неудобно.
>К тупой записи в файл претензий не было.

 Вы не сообщили, почему "дальше с этим работать было неудобно".
 Может, поясните? Если посмотреть на озвученный список задач --

>Зачем мне это нужно:
[...]
>Регулярно требуется "нестандартная" статистика, например
>"средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки"
>"соотношение обращений по http и https ($schema) по запросам типа "q1wr"
>за час"
>"наименьшее/среднее/наибольшее время ($request_time) по запросам типа
>"sc012" за..."
>"объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в
>общем объеме трафика (сумма $body_bytes_sent всех запросов)"
>и т.д.

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

 Но из файла якобы неудобно! Чем же неудобно, почему? При чём тут вообще
 какие-то unix-сокеты, если задача в разборе последовательно идущих строк
 и каких-то элементарных вычислениях?

>Чисто техничски можно и без access-логов, будете сами реализовывать нечто
>подобное -- выберете более близкое вам решение.

 Вы не назвали альтернативные решения.

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

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

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

 Вы крутейший специалист :)) в своих собственных глазах, конечно.

>Концптуальная ошибка в этом опусе -- вы не обслуживание клиентов.
>И "непродуктивность пути" определяете в данной конкретной ситуации не вы.
>И конечную реализацию делаете не вы.
>И за результаты отвечаете не вы.
>Как и ответственность за все выполненное в итоге так же не на вас.

 И что, это лишает собеседника право высказать своё мнение о правильности
 постановки задачи? Вы также не сообщили, каковы критерии "продуктивности
 пути", почему выбрана конретная реализация и т.д. Поэтому нет никаких
 оснований даже подозревать, что Вы что-то делаете правильно... :)

>Эффективность реализации весьма эфемерное понятие.
>Эффективность с точки зрения чего?
>Мы с вами эффективность считаем по совершенно разным критериям.
>Это не хорошо и не плохо. Это просто по-разному :)

 Вы не конкретизировали, по каким критериям оцениваете эффективность.

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

 Ненормально то, что один собеседник пытается аргументировать свои мысли,
 а другой всё время отвечает "Не учите меня жить! У меня другая ситуация!"
 А какая именно -- не говорит.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx security advisory (CVE-2024-24989, CVE-2024-24990)

В реализации HTTP/3 в nginx были обнаружены две проблемы, которые
позволяют атакующему с помощью специально созданной QUIC-сессии вызвать
падение рабочего процесса (CVE-2024-24989, CVE-2024-24990), а также
потенциально другие последствия (CVE-2024-24990).

Проблеме подвержен nginx, собранный с модулем ngx_http_v3_module (по
умолчанию не собирается), если в конфигурационном файле используется
параметр quic директивы listen.

Проблеме подвержен nginx 1.25.0 - 1.25.3.
Проблема исправлена в nginx 1.25.4.


-- 
Sergey Kandaurov

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

nginx security advisory (CVE-2024-24989, CVE-2024-24990)

В реализации HTTP/3 в nginx были обнаружены две проблемы, которые
позволяют атакующему с помощью специально созданной QUIC-сессии вызвать
падение рабочего процесса (CVE-2024-24989, CVE-2024-24990), а также
потенциально другие последствия (CVE-2024-24990).

Проблеме подвержен nginx, собранный с модулем ngx_http_v3_module (по
умолчанию не собирается), если в конфигурационном файле используется
параметр quic директивы listen.

Проблеме подвержен nginx 1.25.0 - 1.25.3.
Проблема исправлена в nginx 1.25.4.


-- 
Sergey Kandaurov

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

[nginx-ru-announce] nginx-1.25.4

Изменения в nginx 1.25.4  14.02.2024

*) Безопасность: при использовании HTTP/3 в рабочем процессе мог
   произойти segmentation fault во время обработки специально созданной
   QUIC-сессии (CVE-2024-24989, CVE-2024-24990).

*) Исправление: соединения с незавершенными AIO-операциями могли
   закрываться преждевременно во время плавного завершения старых
   рабочих процессов.

*) Исправление: теперь nginx не пишет в лог сообщения об утечке сокетов,
   если во время плавного завершения старых рабочих процессов было
   запрошено быстрое завершение.

*) Исправление: при использовании AIO в подзапросе могла происходить
   ошибка на сокете, утечка сокетов, либо segmentation fault в рабочем
   процессе (при SSL-проксировании).

*) Исправление: в рабочем процессе мог произойти segmentation fault,
   если использовалось SSL-проксирование и директива image_filter, а
   ошибки с кодом 415 перенаправлялись с помощью директивы error_page.

*) Исправления и улучшения в HTTP/3.


-- 
Sergey Kandaurov

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

nginx-1.25.4