Сформирован выпуск основной ветки nginx 1.25.5, в рамках которой продолжается развитие новых возможностей. В параллельно поддерживаемой стабильной ветке 1.24.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.25.x будет сформирована стабильная ветка 1.26. Код проекта написан на языке Си и распространяется под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61003
> Выпуск 1.26.0 отмечен как стабильный релиз, вобравший в себя изменения
> и исправления из выпусков mainline-ветки Nginx 1.25Т.е. git pull origin, как и предполагалось.
А сколько пафоса было...
Ждём LibreNginx под GPLv3.
А что OpenNginx уже есть? А то может подсуетиться. Пакеты пересобирать я тоже могу.
Забронирую NetNginx
Они вроде свой httpd из relayd скрафтили, если мне память не изменяет.
А твой open он как открытое пиво или как открытая дверь? Надо уточнить по философии гну https://www.gnu.org/philosophy/free-sw.en.html
Не вздумайте занять FUNginx
И FurryNginx
Open- чаще ассоциируется с пермессивом.
Ну или с Тео: "Для большей безопасности мы реализовали только 5% фич (но дыр от этого меньше не стало)"
Например, OpenSMTPD.
Паллиативная поддержка «более быстрого Апача» для легасных систем скукожилась до минорщины. А вся драма дунинского форка оказалась фарсом, в конце которого дунин просто нажал «Fetch and merge» на гитхабе.
Дунин-Кулаков короче.
Всё уже давно сидят на нормальных вебсерверах. В которых искоропки есть хелсчек для балансировщика, а не как в бесплатной версии нжинкса, где его нет.
nginx обычно ставят перед одним апстримом, так что активный health check не имеет особого смысла.Там, где апстримов больше, лучше использовать специализированные прокси — Envoy, HAProxy.
Конечно не ставят у него же нет хелсчека, он есть в plus версии. А засовывание такого простого функционала в платку уже говорит о пути не туда и деградации. Опять же если бы хелсчек не был нужен его бы ни в какой версии не было.
Тебе ж команда импортозаместителей сп-ла и шва6одно раздает... а, стоп, а вовсе и не шва6одно, это фича pro.> А засовывание такого простого функционала
был бы он такой простой - ты бы его ведь сам за пол-часа написал, написал бы, ГА?!
https://opennet.ru/60722-pingora
Извините, что не в курсе этих "корпоративных дрязг", но что и как мешает людям юзать оригинальный нгынкс? Я вот скачал бинарь для оффтопика - всё работает, денег не просит. Чё не так?
> Я вот скачал бинарь для оффтопика - всё работает, денег не просит. Чё не так?Грант на импортозамещение так не дадут.
Ну у каждого свои тараканы. Кому-то религия не позволяет, кому-то классовая ненависть.
Если не парит, используй что работает.
>>Выпуск 1.26.0 отмечен как стабильный релизИ сразу же
>>в состав FreeNginx 1.26.0 вошли экспериментальная поддержкаПроводим эксперименты и называем это стабильным релизом, ну нормально.
Есть stable (где все более-менее стабилизировано), а есть mainline, который для прода. Всегда так было, в оригинале тоже.
Четные версии - стабильные, нечетные версии - основные. Но вообще да, экспериментальные фичи, наверное, должны быть 1.27
У вас не возникало необходимости из nginx обратиться к redis?У меня появилось необходимость это сделать, что бы прочитать сессионный ключ пользователя из кук, затем обратится к redis, он обрабатывает php-сессии, чтобы получить id пользователя из сессии по этому ключу, если он есть, а затем сравнить его с id из URL и решить можно ли отдавать пользователю это изображение или вернуть 403.
Я собрал модули
http-redis https://build.opensuse.org/package/show/home:13ilya/nginx-mo...
и
redis2 https://build.opensuse.org/package/show/home:13ilya/nginx-mo...,
но они, к сожалению, оказались бесполезными для этой задачи.
http-redis используется только для кеширования и может только получить по ключу данные и целиком их отправить в stdout,
а redis2 может только сохранять, так как при получение каких-либо данных он эти данные вместе с отладочной информацией, аналогичной при работе с redis-cli сразу отправляет в stdout и их не возможно сохранить в переменную и обработать для принятия дальнейшего решения.Я так понял, единственный выход это сделать через OpenResty или модуль lua.
OpenResty, почему-то не собирает ни один дистрибутив, не смотря на совместимую с GPL лицензию, и предлагается подключать сторонние репозитории, в которых даже nginx поставлается свой. Этот вариант мне не очень нравится, но даже так там нет репозитория для OpenSUSE Tumbleweed, только для openSUSE Leap.Попробовал для начала собрать lua модуль сам https://build.opensuse.org/package/show/home:13ilya/nginx-mo...
и запнулся над тем, что ему нужен luajit с поддержкой FFIchecking for Lua language 5.1 ... found
checking for LuaJIT has FFI ... not found
./configure: error: unsupported LuaJIT build; ngx_http_lua_module requires LuaJIT with FFI enabled.При этом в апстиме сказано что поддержка FFI включена по умолчанию,
https://luajit.org/ext_ffi_tutorial.html
и в downstream я не нашёл её отключения.
https://build.opensuse.org/package/show/devel:languages:lua/...На этом пока и запнулся. :-(
Может у вас есть опыт со сборкой OpenResty или тем как решить подобную задачу обращения nginx к redis?
Хм ... вроде Lua нормально к nginx подключается - всё по мануалу.===================== ну типа заметки, надо бы функцию на opennet скрывать под котом :-) ==================
LuaAlternatively, ngx_lua can be manually compiled into Nginx:
LuaJIT can be downloaded from the latest release of OpenResty's LuaJIT fork. The official LuaJIT 2.x releases are also supported, although performance will be significantly lower for reasons elaborated above
$ git clone https://github.com/openresty/luajit2
$ cd luajit2
$ make
$ sudo make install(Возможно будет работать с стандартным libluajit-5.1-dev после apt-get install libluajit-5.1-dev.)
Download the latest version of the ngx_devel_kit (NDK) module HERE (git clone https://github.com/vision5/ngx_devel_kit)
Download the latest version of ngx_lua HERE (git clone https://github.com/openresty/lua-nginx-module)
Download the latest supported version of Nginx HERE (See Nginx Compatibility) nginx-1.19.9.tar.gzРаспаковываем в modules Указываем - куда установлен luajit (в нашем случае /usr/local)
export LUAJIT_LIB=/path/to/luajit/lib
export LUAJIT_INC=/path/to/luajit/include/luajit-2.1Добавляем в configure -
--add-module=modules/ngx_devel_kit \
--add-module=modules/lua-nginx-module \
--add-module=modules/ModSecurity-nginxили
--add-dynamic-module=modules/ngx_devel_kit \
--add-dynamic-module=modules/lua-nginx-module \
--add-dynamic-module=modules/ModSecurity-nginx
Благодарю!
Вся моя проблема была в отсутствии 2-ой строки.export LUAJIT_INC=%{_includedir}/luajit-5_1-2.1
export LUAJIT_LIB=%{_libdir}Видимо если переопределяю LUAJIT_INC то нужно сразу и переопределить LUAJIT_LIB даже если она стандартная.
Луамодуль собрал, буду собирать lua-resty-redis.
P.S. /var/log/nginx/error.log
2024/04/19 11:21:48 [alert] 23985#23985: detected a LuaJIT version which is not OpenResty's; many optimizations will be disabled and performance will be compromised (see https://github.com/openresty/luajit2 for OpenResty's LuaJIT or, even better, consider using the OpenResty releases from https://openresty.org/en/download.html)
2024/04/19 11:21:48 [alert] 23985#23985: failed to load the 'resty.core' module (https://github.com/openresty/lua-resty-core); ensure you are using an OpenResty release from https://openresty.org/en/download.html (reason: module 'resty.core' not found:
no field package.preload['resty.core']
no file './resty/core.lua'
no file '/usr/share/luajit-5_1-2.1/resty/core.lua'
no file '/usr/local/share/lua/5.1/resty/core.lua'
no file '/usr/local/share/lua/5.1/resty/core/init.lua'
no file '/usr/share/lua/5.1/resty/core.lua'
no file '/usr/share/lua/5.1/resty/core/init.lua'
no file './resty/core.so'
no file '/usr/local/lib/lua/5.1/resty/core.so'
no file '/usr/lib64/lua/5.1/resty/core.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
no file './resty.so'
no file '/usr/local/lib/lua/5.1/resty.so'
no file '/usr/lib64/lua/5.1/resty.so'
no file '/usr/local/lib/lua/5.1/loadall.so') in /etc/nginx/nginx.conf:67Ещё и lua-resty-core нужен.
Чуть не забыл -
lua_package_path "/usr/share/nginx/lib/lua/?.lua;;";
в секцию http.
Зачем тащить это всё в event loop сервера?
Если что, исполнение lua там блокирующее, так что если redis отвалится — встанет весь веб-сервер.Лучше сделайте external authz https://docs.nginx.com/nginx/admin-guide/security-controls/c.../
Вы вообще читали изначальную техническую задачу, 2-ой абзац?> Зачем тащить это всё в event loop сервера?
Затем, что в nginx и в его кучи новодельных форках нету простой возможности обратиться к redis и получать от него данные. Мне самому этот луа 300 лет не нужен, но по другому к redis не обратиться, а вешать отдачу статики на php-fpm мне очень не хочется.
> Лучше сделайте external authz https://docs.nginx.com/nginx/admin-guide/security-controls/c.../
И как этот external authz будет обращаться к redis?
Да как угодно. Десять строк кода на golang, например
Ваша задача неплохо решится через X-Accel-Redirect
Моя задача НЕ решается с помощью этого заголовка!
X-Accel-Redirect может лишь более безопасно скрыть реальный путь защищённого статического контента, но обращение к redis за авторизацией он не выполнит.
Скрепно, но мы используем реализацию от cloudflare на хрусте.
> Добавлен новый модуль ngx_stream_pass_module, предназначенный для проброса принятых соединений напрямую в любой слушающий сокет, связанный с такими модулями, как http, stream и mail.В чем предназначение и удобство кроме некоего синтаксического сахара, какой вариант предпочтительного использования?
Может что конфиг самодокументировался и было меньше магии?