Re: announcing freenginx.org
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 без потерь?
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
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
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 без потерь?
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
Добрый вечер, Максим. Удачи, надеюсь всё получится! Вы писали 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
Добрый вечер, Максим. Удачи, надеюсь всё получится! Вы писали 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
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
Добрый вечер, Максим. Печально всё это слышать... Будет развиваться как очередной форк 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
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 без потерь?
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 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-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 mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
Gena Makhomed Wrote: --- > On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: > > >> какую именно проблему Вы пытаетесь решить с помощью записи логов > >> в unix socket, чтения данных из unix socket`а питоновским > скриптом > >> и потом записи данных этим питоновским скриптом в текстовой файл? > > > Если вы предлагаете писать напрямую с nginx-а в файл -- > > сделайте у себя ротацию файлов с интервалом 30 сек > > при 200-250 тыс подключений/сек... > > > Если у вас уже есть такое рабочее решение - > > поделитесь опытом, буду рад вас выслушать. > > В этом сообщении Вы говорите о том, что Вы пробовали писать логи > "напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд, > при при 200-250 тыс подключений/сек, и у Вас не получилось > создать "рабочее решение". > Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО! Я сказал ровно то, что и хотел сказать. Где вы прочитали про "не получилось" ??? Пожалуйста процитируйте... без своих домыслов и фантазий. > И Вы просите, чтобы я поделился с Вами опытом, как построить > такое рабочее решение и говорите, что будете рады меня выслушать. > > Если настроить ротацию логов через сигнал USR1 > - никаких проблем с самой ротацией не должно быть, > при любом количестве подключений. > > Тем более, что с помощью дополнительных параметров > [buffer=size] [gzip[=level]] [flush=time] директивы > access_log можно настроить и буферизацию записи логов > и компрессию на лету - чтобы еще больше оптимизировать > использование ресурсов процессора и занимаемого логами > места на диске сервера. > > Расскажите, пожалуйста, какие тут у Вас могли возникнуть проблемы, > что не получилось построить рабочее решение, > если "писать напрямую с nginx-а в файл" ? > > Я пока что вижу только всего одну возможную причину, > почему у Вас не получилось создать такое рабочее решение > - для ротации логов Вы использовали сигнал HUP а не сигнал USR1. > > Потому что только в случае ротации логом с помощью сигнала HUP > количество подключений в секунду и интервал ротации в 30 секунд > могут влиять на процесс ротации, потому что при этом происходит > > "changing configuration, keeping up with a changed time zone > (only for FreeBSD and Linux), starting new worker processes > with a new configuration, graceful shutdown of old worker processes". > > Если же делать ротацию логов с помощью сигнала USR1, > тогда не имеет особой разницы, какое количество подключений > в секунду обрабатывают рабочие процессы и и с каким интервалом > происходит ротация лог-файлов, потому что если делать ротацию > с помощью сигнала USR1 - перезапуска рабочих процессов не происходит, > и происходит только лишь "re-opening log files", что является очень > дешевой и очень быстрой операцией, такая ротация происходит > практически мгновенно и не создает дополнительной нагрузки > на систему. Хорошо, вы озвучили ожидаемое, много где (в том числе в документации nginx) описанное, а кое-где по умолчанию прям в дефолтовых конфигах примененное решение. > > Причина, почему у Вас не получилось настроить ротацию лог-файлов > при записи логов "напрямую с nginx-а в файл" может быть в такой > ситуации только одна - для ротации лог-файлов Вы использовали > сигнал HUP а не сигнал USR1 - именно поэтому у Вас не получилось. Вероятно вам не раз приходилось сталкиваться с подобным, и вы автоматически считаете, что так поступают все. Распространенная модель поведения. Еще раз -- единственная новость тут для меня была в том, что у меня не получилось. Все как раз получилось, дальше с этим работать было неудобно. К тупой записи в файл претензий не было. Я по простоте душевной допустил ту же оплошность, что и вы -- решил, что раз пишу логи для дальнейшей обработки данных из них, то и все остальные поступают так же... > > On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: > > >> какую именно проблему Вы пытаетесь решить с помощью записи логов > >> в unix socket, чтения данных из unix socket`а питоновским > скриптом > >> и потом записи данных этим питоновским скриптом в текстовой файл? > > > Если вы предлагаете писать напрямую с nginx-а в файл -- > > сделайте у себя ротацию файлов с интервалом 30 сек > > при 200-250 тыс подключений/сек... > > > Если у вас уже есть такое рабочее решение - > > поделитесь опытом, буду рад вас выслушать. > > Почему Вам не подходит решение > использовать сигнал USR1 для ротации логов? > > Ведь Вы же прямо говорите в этом своем сообщении, что проблема > у Вас именно с тем, что не удается настроить сам процесс ротации > логов с интервалом 30 сек при 200-250 тыс подключений/сек. > > О другой проблеме - нехватки свободного места на диске сервера > для записи логов, или о проблеме низкой пропускной способности > дисковой подсисетмы в своем ответе - Вы ничего не говорите. > > Это же какие у Вас получаются там объемы логов nginx за 30 секунд, > что может не хватать пропускн
