После 11 месяцев разработки представлена новая стабильная ветка высокопроизводительного HTTP-сервера и многопротокольного прокси-сервера nginx 1.24.0, которая вобрала в себя изменения, накопленные в основной ветке 1.23.x. В дальнейшем все изменения в стабильной ветке 1.24 будут связаны с устранением серьёзных ошибок и уязвимостей. В скором времени будет сформирована основная ветка nginx 1.25, в которой будет продолжено развитие новых возможностей. Для обычных пользователей, у которых нет задачи обеспечить совместимость со сторонними модулями, рекомендуется использовать основную ветку, на базе которой раз в три месяца формируются выпуски коммерческого продукта Nginx Plus...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58951
"На платформе Windows в модулях ngx_http_autoindex_module и ngx_http_dav_module, а также в директиве include добавлена поддержка не-ASCII символов в именах файлов. В Windows также налажена сборка nginx с OpenSSL 3.0. "лучший веб-сервер с каждым разом все хорошеет. Скоро уже не нужен будет этот ваш линукс совсем и можно станет удалить wsl!
На венде, насколько я помню, используется select() что не предполагает каких либо существенных нагрузок.
Возможно переписали на WSAPoll() - его завезли в венду кажется с висты или семёрки и тогда оно получше.
у венды все в порядке с select, это ж не линукс. Все там хорошо с нагрузками.> Возможно переписали на WSAPoll()
вряд ли.
Но оно по большому счету и лишне.
> у венды все в порядке с select, это ж не линукс. Все там хорошо с нагрузками.и чем он отличается линуксового?
Наверное пора top500 переводить на вантуз. А то, ишь чего, уже полностью на линукс перешли. Это твоя недоработка!
> Наверное пора top500 переводить на вантуз.
> А то, ишь чего, уже полностью > на линукс перешли. Это твоя недоработка!Вообще это скорее 1M top busiest sites, но там почему-то виндов вообще нет. Да даже паркинги с виндов и IIS посваливали. Наверное потому что круто работало и было дешево и эффективно.
> Вообще это скорее 1M top busiest sites, но там почему-то виндов вообще
> нет. Да даже паркинги с виндов и IIS посваливали. Наверное потому
> что круто работало и было дешево и эффективно.А насколько в этой нише сейчас актуальны коммерческие Юниксы? AIX там, Солярка, ЧПУКС?
Кто ж будет выставлять во внешку такую окаменелость? Ломанут же.
> А насколько в этой нише сейчас актуальны коммерческие Юниксы? AIX там, Солярка, ЧПУКС?Без малейшего понятия. ИМХО не очень - за отсутствием современных ФС, продвинутых фич ядер, поддержки современных скоростных железок, да и оверхед там врядли кто жестко оптимизировал. В древние времена соотношения были иные. А когда у вас тут 100GigE, там SSD в pciE и скорости давно уже в гигах в секунду и миллионах иопсов на ядро - а знаете, при этом очень неожиданные сегменты кода будут в топе профайлера.
И линукс прошел очень длинный путь на эту тему. Например они апи рефакторили чтобы не только отдельными страницами оперировать но и сразу подшивками страниц, чтобы меньше вызовов требовалось - оверхед от огромного числа вызовов на вон тех скоростях уже всех напрягает. Или вон io_uring, так то довольно крутая zerocopy штука.
В резльтате виндус апдейту :)) файло грузит извините AKAMAI CDN. С линуксом. По-моему это говорит об успешности и эффективности виндов как сервера больше чем все остальное, вместе взятое. Ведь у майкрософта и датацентры есть, и лицензии они себе могут бесплатно выписать в любом количестве. Но нет, даже так выгоднее стороннюю фирму с Linux оплатить. Выводы напрашиваются.
> В резльтате виндус апдейту :)) файло грузит извините AKAMAI CDN. С линуксом. По-моему это говорит
> об успешности и эффективности виндовговорит. Понадобилась cdn чтоб всем хватило апдейтов - даже встроенный торрент не справился.
Просто ms в отличие от вас, дол6анавтов, совршенно наплевать с чем оно там.
Датацентры у них есть, нет терабитных каналов и cdn по всему миру (ты - дол6онавт потому что не понимаешь разницы), нет громадных стораджей с нулевой надежностью (потому что не нужна) но трансконтинентальной доступностью - и все это не их бизнес - поэтому компетенций в нем тоже нет, и проще платить денег чем самим ввязываться в _чужой_ технологический сектор.
А вот я тебе это пишу - с линуксной виртуалки под... правильно, hyperv. Потому что у этого провайдера оно стабильно и за копейки- а у мэйлрушечки с ее любовью к оп...шва..халяве на kvm и ceph (дико тормозном по сравнению с storage direct) - до сих пор нет live migration да еще и оборудование с помойки - поэтому они уже дважды за последние месяцы мне сделали hard reset патамушта "ой у нас гипервизор заглючил и срочно надо перенести с него всьо".
> Выводы напрашиваются.
выводы в очередной раз напрашиваются о квалификации экспертов опеннета и судьбе страны где других уже не осталось
с select() всё так же плохо, как и в unix. В винде по дефолту он держит максимум 64 сокета, чем разработчики намекают, что если у вас больше, то не стОит. Изменить можно только в compile time.Хорошо с нагрузками на I/O completion ports, на которых работает тот же IIS, но этот too much magic плохо ложится на архитектуру nginx.
Нет, как сказали уже там лимит в 64 сокета.
Вот WSASelect() лучше, но ему надо окошко, хотя бы невидимое, и хз сколько оверхэда это добавляет.
он меняется. Это какая-то константа застрявшая со времен winsock и 95й винды для совместимости с непоймичем.
> wslСомнительная нужность изначально когда есть msys.
Обрати внимание на то что все падают по статистики со временем. Решил узнать: может быть появился новый-модный-молодежный web-сервер, а я не знаю. А в статистике вырос "Other". Это что ж получается - nginx уже не торт пора на суррогат переходить? Какой сейчас в "цене"?
Тоже очень интересует этот вопрос
Модный и молодёжный web-сервер - Caddy
Крутой и навороченный прокси для прода - Envoy.
> Модный и молодёжный web-сервер - Caddy > Крутой и навороченный прокси для прода - Envoy.Рыночную долю делят в основном всякие гуглоамазоны с своими "other". На их кастомном барахле довольно много сайтиков висит.
Cloudflare = Other
В том то и дело, что там есть отдельный пункт Cloudflare и отдельный пункт Other.
в кубернет-инфраструктуре есть свои веб-сервера для лоадбалансинга нод, удобно управляемые без пердолинга текстовых конфигов
https://kubernetes.io/docs/concepts/services-networking/ingr.../почитать можно например тут
Про ingress что-то слышал, но дальше Traefik не пошел (да и то без кубера использовал). Не довелось в продакшене пользоваться. Думал их за чем-то прячут.Не знал что их там такая толпа, спасибо почитаю.
Traefik - далеко не лучший выбор для нагруженного прокси
https://github.com/gaplo917/load-balancer-benchmark
Последний коммит - 4 года назад
Все скрипты в репе лежат, так что всегда можно повторить.
> в кубернет-инфраструктуре есть свои веб-сервера для лоадбалансинга нод, удобно управляемые без пердолинга текстовых конфиговСамый популярный ингресс - внезапно, ingress-nginx, который состоит из собственно Nginx и гошной обертки, которая пердолит ему текстовый конфиг (плюс еще некоторое количество кода на Lua, который рулит апстримами).
Реализациям ингресса на базе Envoy (например, Contour) оно проигрывает как по скорости, так и по потреблению ресурсов, но пипл хавает.
> Самый популярный ингресс - внезапно, ingress-nginx, который состоит из собственно Nginx
> и гошной обертки, которая пердолит ему текстовый конфигВот так вот и оказывается что совершенно случайно есть и нжинкс и текстовый конфиг :)
Да, ингресс на nginx самый вменяемый из всех. А алб самый конченый. Про энвой и говорить не приходится.
Ага, вменяемый. В течение года не могли починить утечку памяти
https://github.com/kubernetes/ingress-nginx/issues/8228
Думаю отчасти тут психология.Когда я входил в тему 2008 году то апач казался с одной стороны очень монструозным и тяжёлым, с другой стороны каким то перегруженным и глючным.
Мне надо было совсем немного и я поставил лайти.
Потом чуть разобравшись и кажется потребности чуть выросли я переполз на nginx.Сейчас nginx имеет огромное колличество плагинов, и я думаю такой список сильно пугает новичков.
Что касается остального, то в плане производительности/ресурсов nginx не расжирел, по крайней мере если там и был какой то рост потребления ресурсов за 15 лет то врядли его кто то заметил, ибо и железо сильно выросло и функционал подрос.
В части архитектуры nginx это всё ещё некоторое ядро-фреймворк для работы с диском и сетью, остальное в основном навешивается плагинами.
На его базе можно вообще нечто совсем иное собрать, не имеющее отношение к вебсерверам.
Что до конкурентов - они есть, но им сложно.
По сути, никто не может выйти и сказать что он во всём лучше nginx, или хотя бы в основном функционале его уделывает. Обычно конкуренты говорят: вот у нас есть кручая фича, корая нужна когда а, б, с, д в остальном у нас примерно такая же производительность и потребление.
По базовому функционалу: раздача статики и ответы на какие то хттп запросы - nginx уделать сложно, потому что он фактически дёргает сисколы с почти нулевым оверхэдом.
Чтобы превзойти nginx нужно уйти от сисколов на dpdk/netmap, иметь свой сетевой стёк, тогда получится срезать немного углов которые спрятаны в ядре ОС.
> Чтобы превзойти nginx нужно уйти от сисколов на dpdk/netmap, иметь свой сетевой
> стёк, тогда получится срезать немного углов которые спрятаны в ядре ОС.на липуксах кстати ему добавили поддержку sendfile2 ?
раньше чисто на фряхе держали статику ради этого
> на липуксах кстати ему добавили поддержку sendfile2 ?
> раньше чисто на фряхе держали статику ради этогоhttps://nginx.org/en/docs/http/ngx_http_core_module.html#sen...
судя по документации это до сих пор фряха онли фича бггг
На линуксе поддержка aio/directio есть уже много лет.
Она просто не потребовала вмешательства разработчиков nginx :)
кстати - а есть ли поддержка aio в фрибсдшной zfs?Ибо на линухе ее как бы есть, но все же нет. Учитывая откуда теперь во фре openzfs и что нетфликсе оно до лампочки...
aio нужно для скорости (быстрой отдачи статики)
zfs - это вообще не про скорость.Нафига выигрывать условные 20% по скорости на aio, если условные 30% потеряются из-за фрагментации?
Вот поэтому нетфликсу и до лампочки проблемы zfs.
zfs вполне себе про скорость (отдачи уж точно) - когда-то у меня получались вполне себе упиравшиеся в сетевуху результаты. Правда это была еще нормальная версия написанная руками.aio нужно чтоб не жрать при этом ресурсы и спокойно заниматься другими потоками пока этот отдает данные.
Но вот работает ли оно у нас - я к сожалению уже не могу проверить.
Нет, там такого не написано.
Здесь изложение истории https://www.nginx.com/blog/nginx-and-netflix-contribute-new-.../tl;dr: sendfile во Фре не поддерживал асинхронный ввод-вывод, и Нетфликс решил, вместо переезда на линукс, переписать этот sendfile.
Для линукса проблема не актуальна, они много лет назад смогли сделать aio/directio без помощи нетфликса.
Он и сейчас его не поддерживает, по ссылке тоже ничего про асинхронность :)Асинхронность есть в венде на CompletionIOPort (WSAOVERLAPPED и вот это всё), и типа AIO на фре и линухе. Но AIO в nginx использовалось типа для подгрузки данных перед вызовом sendfile().
> Для линукса проблема не актуальна, они много лет назад смогли сделать aio/directio
> без помощи нетфликса.man aio
HISTORY
The aio facility appeared as a kernel option in FreeBSD 3.0.
А речь идет не про ядро, а про sendfile.Потому что какой толк, если в ядре фича есть, а в юзерспейсе её использовать нельзя?
aio/directio в линуксе настолько хорошо работает, что в nginx пришлось сделать тредпулы.Справедливости ради, async на io_uring работает действительно хорошо, но он появился совсем недавно, и в nginx его пока не впиливали.
какой в ней сегодня смысл? Если все файлы отдаются через https.а поддержки in-kernel https в нем нет и не будет.
> какой в ней сегодня смысл? Если все файлы отдаются через https.
> а поддержки in-kernel https в нем нет и не будет.ну вот была новость о KTLS в новом релизе.
правда как поддержку этого впилить в нжинкс не особо понятно.
как - довольно понятно, непонятно зачем и главное - кто этим теперь будет заниматься.
Нет разработчиков.Апач вполне вероятно запилит через пару лет (у них все небыстро). А тут - только улучшенная поддержка винды (потому что ее удобно было скопипастить с nginx+)
Нетфликс это давно сделал уже.
Вот апачу и прочим - реально не понятно кто делать будет.
> Нетфликс это давно сделал уже.Что именно?
KTLS в ядро фри а в nginx запилили его поддержку правда я не уверен кто.
jhb впилил. Отлично работает.
>нжинкс не особо понятноТам через openssl ktls прикрутить никак?
>>нжинкс не особо понятно
> Там через openssl ktls прикрутить никак?там про фрю ж речь - а у нее openssl был без его поддержки. Но вон оказывается что в модных-современных уже все перешли на третий и проблема решилась сама собой.
> а у нее openssl был без его поддержки.можно из портов поставить openssl-1.1.1t_2,1, там уже есть поддержка
https://www.freshports.org/security/openssl/
Configuration Options:
===> The following configuration options are available for openssl-1.1.1t_2,1:
KTLS=on: Kernel TLS offloadи нджинксу передать ssl_conf_command Options KTLS;
работать не будет? или обязательно 3 версия должна быть?
хз - проверь. У меня уже нигде нет того на чем можно экспериментировать (увы).
Нжинксу для начала надо объяснить что в твоей библиотеке вообще есть поддержка. Т.е. возможно оно там гвоздем прибито к проверке версии и вручную не подсовывается.
Ставите 13 фрю, идёте собирать nginx из портов, там выбираете KTLS.
И получаете только ускоренный SSL_sendfile()
Опция при сборке порта была помнится для этого, может щас вообще включили по дефолту и опцию убрали - давно не смотрел.
> ну вот была новость о KTLS в новом релизе.Это SSL_sendfile(). Достаточно специфичный случай, когда все упирается в отдачу статики.
Куда интересней SSL-терминирование для проксируемых соединений.
> Это SSL_sendfile(). Достаточно специфичный случай, когда все упирается в отдачу статики.
> Куда интересней SSL-терминирование для проксируемых соединений.неинтересно как раз совсем. Поскольку раз уж мы это стали проксировать и не смогли удержать целиком в оперативной памяти, началась всеми нами любимая нгинксова буферизация на диск - об эффективности можно уже забыть.
А если бы оно уместилось - не было бы нужды ни в каком sendfile.Если ты построил этажерку прокси для _статики_ - поздравляю, шарик, ты балбес.
SSL_sendfile() - нет такого.KTLS это когда хэндшейк идёт в юзерспейсе а дальше когда есть общий ключ он привязывается к сокету и дальше передаваемые по нему данные автоматом ядром шифруются.
И обычный sendfile(), read()/write() / send()/recv() для приложения прозрачно работают.
А всякие TLS специфичные штуки как то отдельно падают в юзерспейс.
Проксируемых - для чего?
Если тебе терминировать крипту - то не уверен что будет разница в сравнении с юзерспейсом, но есть конечно пара трюков чтобы избежать копирования памяти и юзать KTLS.А так то можно распарсить SNI и проксировать без снятия крипты, притом можно извратится и делать это прямо в ядре средствами фаервола, но тут допилинг нужен, я вроде ничего такого готового не видел.
> SSL_sendfile() - нет такого.это опенссл3шная обертка вокруг ktls. Делает ровно как ты хотел в рамках стандартной opensslной сессии.
В линуксах оно давно, а вот во фре с 13й оказывается. И вроде даже по слухам оно работает.
> SSL_sendfile() - нет такого.Есть. И именно этот вызов и подразумевается под ktls в nginx.
Продублирую ссылку: https://www.nginx.com/blog/improving-nginx-performance-with-.../
И как обычно убунта сделала фряху в обоих номинациях. Ня.
Убунты обставили фрю, как обычно :)
https://www.nginx.com/blog/improving-nginx-performance-with-.../
На сайт сходить не пробовал?
Уже больше года как есть.
> Уже больше года как есть.а, в 13й оказывается есть. отстал я от жизни. Впрочем надеюсь что уже и не придется на нее ничего переводить.
> на липуксах кстати ему добавили поддержку sendfile2 ?Так называемая "новая реализация sendfile", про которую было много шума в 2016 - работа разработчиков Nginx по решению конкретной проблемы с асинхронным IO на FreeBSD.
При чём тут линукс? У него такой проблемы нет.
> Чтобы превзойти nginx нужно уйти от сисколов на dpdk/netmap, иметь свой сетевой стёк, тогда получится срезать немного углов которые спрятаны в ядре ОС.То есть то же, что сможет и сам nginx если понадобится?
Tux-web server вроде был, но ушёл вместе с 2.4 ядром.
У nginx нет core разработчика он уже ничего не сможет. нжинкс выдоят и выкинут.
А разве еще нет?
Несколько лет уже только косметические изменения.
Новость как раз про то что ещё додаивают, но все тендеции в новости тоже хорошо указаны на спад использования нжинкс в мире. То что изменения косметические или для платных свистелок это уже даже фанаты нжинкса заметили.Удобно конечно сказать что наш проект идеален и разрабатывать больше не надо, как было например с boltdb. Но и у него по итогу вышел форк bbolt.
https://github.com/webserver-llc/angie - форк Nginx с некоторыми халявными фичами, которые в оригинале платные (DNS SD, нормальные метрики, API).
Хороший распил. Попилено 0 денег.
> Хороший распил. Попилено 0 денег.а лям долларов который им под это выделено куда пошел - на нужные и важные мероприятия по внедрению импортозамещенки?
А вы чего ждёте?
Оно работает, умеет всё что надо 99,9% домохозяек.
Куда там развиватся и расти, и зачем?
В смысле!?
Он же простой и маленький, поддерживать там особо нечего.
Примерно как реализация любогого крипто алгоритма - бери и юзай, чего там супортить?
Смысл nginx в том что он явлется тонкой надстройкой над сисколами.
На dpdk/netmap+IPstack проще совсем другое сразу написать, чем мучатся с переделкой, там довольно сильные различия.
nginx много возится с сокетами и kqueue/epoll, а там не будет сокетов по сути и kqueue/epoll тоже не нужны практически (от них только таймер и может уведомление о данных с адаптера).
Nginx это уже окаменелость, которая не развивается.
Куда там развиватся то?
Всё необходимое реализовано и работает стабильнее некуда.
Всё _необходимое_ реализовано даже в Лайти.
Да, но иногда нужно чуточку больше и потому я на nginx перешёл :)
> Всё _необходимое_ реализовано даже в Лайти.Кроме нормальной буферизации ответа бэкэнда - он пытается буферизовать все. И никогда не отдает это ОС уже. Поэтому может сожрать нетривиальный объем памяти если бэк вернет что-то крупное.
Скончай конпилятор и розвевай, инторнет у тибя есть
всякие envoy и прочее, что модно, стильно, молодёжноТам и хелсчеки, и балансёры, и стата, и плюшки
А есть ли плагин для Nginx, чтобы он сам Lets Encrypt выпускал? Как это делает Caddy и Traefik?
какое-то чудовищное г-но от васянов было.
Впрочем, перечисленные тобой это целиком прокси от васянов с руками из задниц, поэтому в целом - соответствует."все ключи от всего удобно сложены кучкой"
Кстати удивительней то, что у nginx-unit этой фичи нет. Впрочем, про него что-то вообще давно не слышно. Вероятно с уходом Сысоева и возвращением патреотов в родную г08ень стал ненужен никому вовсе.
Конечно есть.
apt install certbot python3-certbot-nginx
В нем есть авто перевыпуск сертификата.
curl | sudo bashвсегда так и делаю.
> curl | sudo bash > всегда так и делаю.Да, скачай у меня клевый скриптик :)
>> curl | sudo bash > всегда так и делаю.
> Да, скачай у меня клевый скриптик :)у тебя карма плохая, никто не скачает. Иди-ка повосхваляй Будду 23 часа в сутки пару лет, потом сдохни (ну при таком подходе само получится) - глядишь и переродишься с хорошей кармой и тебя примут в число тех пацанов клевый скриптик от которых девляпсы радостно запускают совсем даже не морщась.
[...]
Огромную роль в создании буддизма сыграл Фридрих Мюллер, немецкий учёный-филолог, эмигрировавший в Великобританию. Благодаря ему были воссозданы «потерянные» и «уничтоженные» документы буддизма.По официальной легенде буддистских текстов в Китае не осталось после восстания тайпинов, которые их все педантично уничтожили. Тогда в Китае была основана типография Яна Вэньхуэя, напечатавшая более миллиона буддистских книг.
Интересно, что в Японии в это время тоже стали усиленно искать буддистские тексты, которые, ай-ай, потерялись. Япония ведь далёкая провинция, одичали. Поехали в Китай за буддизмом. А в Китае говорят: да, был такой. Только в Нанкине бунтовщики пожар учинили, всё сгорело. Тогда японец Нандзё Бунъю поехал в лучезарный Лондон изучать буддизм. К великому махатме сэру Мюллеру. И конечно изучил. За 8 лет штудий барабанил на санскрите (стал затем основоположником японской санскритологии), изучил только что придуманную англичанами «древнюю индийскую философию». Со всеми делами – индийским Сократом, индийским Платоном, индийским Демокритом и даже Диогеном. В общем, такая детализация сейчас выглядит ненужным юродством, вроде «Сир, я вам привезу Наполеона в клетке! – Я вас об этом не просил». Но следует учитывать, что в 19 веке у всех были проблемы из-за античных гимназий. Иначе они просто не могли врать. Только Сократ, только Диоген.
И вот, что же вы думаете? В оксфордской прихожей Мюллера Нандзё Бунью сталкивается с узкоглазым братом по разуму Яном Вэньхуэем. «Здравствуй, брат Коля!»
- А вы по какому вопросу в Лондоне, товарищ?
- Взыскую Священные Книги, утерянные по попущению.
- Ой, а ведь я как раз имею при себе 300 древних буддистских текстов, фактически Канон.
- Не могли бы вы мне дать, любезный брат Коля, сии книги.
- Ну конечно же, я с удовольствием дам вам эти книги!
[...]
вы прослушали курс альтернативной истории пополам с альтернативной географией.А теперь докладчику нужно в процедурный, ему там галоперидольчик вколют.
P.S. буддистские тексты, дурачок ты наш, надо искать не в Китае, и не в Японии. Сиддхартха Гаутама совсем не там практиковал. (Э... правда занятно то что там где практиковал - традиционно исповедуют все больше индуизм, а учение Будды утекло в сопредельные страны. Но это ни разу не Япония.)
> занятно то что там где практиковал - традиционно исповедуют все больше индуизмвоот.
еще немного, еще чуть-чуть и от "древнейшей традиции" останется примерно ничего и сбоку бантик.ps: а еще там забыли санскрит. напрочь.
> еще немногоеще пара тысяч лет?
Повторяю для бестолковых - в той стране где родился Просветленный - основная религия - индуизм. Была, есть и будет - была до него и будет после нас. Санскрит там в монастырях не забыли, веды старательно переписывают по сей день.
А буддизм - это совсем другие страны. Но ни разу не Китай (за вычетом оккупированного Тибета) и не Япония.
> apt install certbot python3-certbot-nginxИли dnf install certbot на Fedora :) Что характерно, кроме установки и первого выпуска сертификата что на Ubuntu, что на Fedora, больше ничего делать не надо. Certbot уже прописан в планировщике, обновит когда надо сертификаты и сообщит об этом nginx, чтобы тот подтянул новый сертификат.
При том что вместо nginx можно уже начинать использовать нормальные веб-серверы, вы всё ещё в пакеты с пакетами играетесь. Ничего это пройдет.
> При том что вместо nginx можно уже начинать использовать нормальные веб-серверы, вы
> всё ещё в пакеты с пакетами играетесь. Ничего это пройдет.Так расскажи, как нужно. Какой нужно веб-сервер и в чем беда с пакетами?
Т.е. ты сам выбирать не в состоянии ты можешь только ждать когда тебе мессия укажет? Такого не будет, выбирать надо самому, уже есть куча вебсерверов которые и по настройкам и по всему лучше древненжинкса.Выбирай любой HAProxy, Traefik, Caddy.
Как в HAProxy сделать поддержку LetsEncrypt без пердолинга?
Или хотя бы OCSP stapling?
Головой подумай.
Если головой думать - то никак.
Поэтому и спросил - вдруг вы другим местом думаете, и знаете рабочий вариант.
> Выбирай любой HAProxy, Traefik, Caddy.Из них вот именно вебсервер разве что caddy и тот на игогошке тормозной. А проксификаторы все же не есть вебсерверы.
> Конечно есть.
> apt install certbot python3-certbot-nginx
> В нем есть авто перевыпуск сертификата.в бубунте это в снапе бггг
> в бубунте это в снапе бгггмолодцы если так. Хотя бы снапом ограничить область деятельности стремного скрипта с рутовыми правами - вполне разумная идея (особенно если еще и работает а не как с мразилой у них вышло)
> в бубунте это в снапе бгггА сколько снапов и докеров в докере внутри этого снапа?
и, кстати - а как оно из этого шнапса объясняет вне-снаповому nginx что тому пора обновить сертификат? Или как всегда?
> и, кстати - а как оно из этого шнапса объясняет вне-снаповому nginx
> что тому пора обновить сертификат? Или как всегда?хз
я тут чекнул. и в 11 дебилиане оно тоже в снапе
debian@mail:~$ snap list
Name Version Rev Tracking Publisher Notes
certbot 2.5.0 2913 latest/stable certbot-eff✓ classic
core 16-2.58.3 14946 latest/stable canonical✓ core
core18 20230320 2721 latest/stable canonical✓ base
core20 20230308 1852 latest/stable canonical✓ base
debian@mail:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
debian@mail:~$
так шнапс-то один на всех. ты apt search набери - наверняка вылезет обычный безшнапсовый.С каким-то жутким враппером на впихоне3 (сдрасьти!) кажись как раз отвечающим за перезапуски и порчу конфигов.
Причем "документированного" на держись за стул - жабаскрипте. Поэтому прочитать документацию на сервере мне оказалось нечем.А чувак там спрашивал за модуль чтоб прям внутри nginx все автомагично и пыщьпыщь. Я вот уже не помню что в том модуле было, но в общем факт что он от васяна и не принят в мэйнлайн говорил уже сам за себя. А когда я туда заглянул - бежал от него как от чумы.
Ерунду не городи.https://packages.debian.org/bullseye/certbot
https://packages.debian.org/bullseye/all/certbot/filelist
> https://packages.debian.org/bullseye/certbotpython-certbot (1.12.0-2) unstable; urgency=medium
-- Harlan Lieberman-Berg <hlieberman@debian.org> Sat, 13 Feb 2021 13:56:53 -0500уринировал тебе лицо.
> я тут чекнул. и в 11 дебилиане оно тоже в снапеЗачем в дебиане Крап?!
>> я тут чекнул. и в 11 дебилиане оно тоже в снапе
> Зачем в дебиане Крап?!правильно
всем сидеть на дырявом софте 2020-2021 года
Майнтайнеры как раз для того и существуют чтобы дыры патчить в соответствии с полисями. А вот какие полиси в этой помойке - кто его знает? Софт 2021 года если работал в 2021 году то и в 2023 будет работать, ничуть не хуже. А вот внезапный апдейт может сломать мне рабочее окружение. Не всем же арчеводством заниматься, некоторые на компах еще и работы работают и совсем не катит чтобы софт помер когда он нужен был.Можно подумать, в софте за эти 2 года какая-то революция за 2 года случилась которая меня в 10 раз эффективнее сделает. Скорее, я поверю в то что софт стал прожорливее, тормознее, сложнее, глючнее... ну так, по опыту :)
> в бубунте это в снапе бгггТрындёж! Это в инструкциях на сайте certbot предлагают ставить через snap подтянув на свой VPS 1-2 гига хлама для snap. А если ставить через apt, то никакого snap не надо.
То есть сами авторы троянца рекомендуют именно шнапс, но ты ж все лучше них знаешь, и запустишь прям от рута в основной системе. Все правильна, так и нада.
Есть доцкер nginxproxy/nginx-proxy и к нему nginxproxy/acme-companion