LINUX.ORG.RU
ФорумAdmin

А есть ли человеческий ACME (Let's Encrypt)-клиент?

 ,


1

3

Привет, ЛОР.

Посоветуй клиент для Let’s Encrypt.

Есть монструозный Certbot, который делает всё, но плохо и медленно; есть аскетичный dehydrated, который делает ничего и быстро.

А есть что-то посередине, чтобы не нужно было притаскивать в систему 15 мегабайт питонокода (и потом всё равно обкладывать его костылями), но и при этом не писать руками заново всякие адаптеры для DNS-хостингов, которые уже написаны 100500 раз до меня?

Сейчас у меня dehydrated, обложенный километром скриптоты для сброса привилегий и чуть более эргономичного написания хуков (а также самих хуков, включая самописный интерфейс к Google Cloud DNS). Я бы хотел избавиться от этой скриптоты, т. к. она объективно не решает никаких новых или уникальных задач.


P.S.: ничего не имею против питона как такового, моя неприязнь распространяется исключительно на медленный неповоротливый софт, не имеющий быть таковым никаких оснований.

★★★★★

Последнее исправление: intelfx (всего исправлений: 3)

Посмотри клиенты на Bash с набором плагинов для DNS-хостеров. Правда у тех, что я разглядывал, качество кода было такое, что я предпочел свой написать на Bash - занимает всего 120К с DNS-плагинами, которые добавлял по ходу переезда на другие облачные платформы (1Cloud, AWS, Azure). Так оно чуть сложнее, но надежнее получилось. Ну и я все это оформил не в виде автономно запускаемого приложения, а в виде библиотеки функций, которую можно подключать к произвольному скрипту на Bash.

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 2)

На медленном и/или глупом окружении я пользуюсь acme.sh. Довольно удобный для моих задач.

На правах оффтопика.
Что плохого в 15 мегабайтах питонокода и зачем софту, запускаемому раз в 30 дней работать быстро?

BOOBLIK ★★★★
()
Последнее исправление: BOOBLIK (всего исправлений: 1)
Ответ на: комментарий от BOOBLIK

Что плохого в 15 мегабайтах питонокода и зачем софту, запускаемому раз в 30 дней работать быстро?

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

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Что плохого в 15 мегабайтах питонокода и зачем софту, запускаемому раз в 30 дней работать быстро?

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

А что там обкастыливать? Запихать всех кого нужно в групу которая может читать сертификаты из /etc/letsencrypt/archive/domain-name и сделать пару скриптов в /etc/letsencrypt/renewal-hooks/ для перезагрузки сервисов после обновления и остановки апача, или еще чего там на 80-м порту, на время обновления.
Вроде все.
ps: единственное, что я его несколько лет назад руками ставил на Ubuntu 22.04 в /opt и уже не помню как...

hbars ★★★★★
()
Последнее исправление: hbars (всего исправлений: 3)
Ответ на: комментарий от intelfx

… эти 15 мегабайт всё равно приходится обкостыливать хуками и врапперами, потому что оно тупорылое и не особо расширяемое.

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

vinvlad ★★
()
Ответ на: комментарий от intelfx

А есть какой-то смысл тащить в Kubernetes самописные скрипты вместо того же cert-manager? Оно ведь гибче не бывает.

Ну вот есть у вас в кубе Deployment Nginx (несколько реплик), в котором автоматом надо обновлять сертификаты (в каждой реплике) размещая их в Secret-объектах. Причем, стопроцентно надежно посредством кубового CronJob-объекта, и с использованием любого DNS-провайдера, в том числе и такого, для которого просто нет поддержки в cert-manager (как было изначально в моем случае)… Мне, чтобы жить спокойно, оказалось проще свой написать взяв протокольную логику из других Bash-проектов (именно логику).

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

vinvlad ★★
()
Ответ на: комментарий от intelfx

А есть какой-то смысл тащить в Kubernetes самописные скрипты вместо того же cert-manager? Оно ведь гибче не бывает.

… могу еще дополнить, что у меня админ-поддержка приложений, работающих в среде Kubernetes, осуществляется с использованием тоже «самописного» админ-приложения - wrapper-обертки вокруг kubectl и конкретных CLI-утилит облачных провайдеров. Свое пришлось сделать, чтобы конфигурация прикладного кластера была максимально переносима в любую облачную платформу и не зависела от 100500 поделок третьих лиц. Ничего реально подходящего в этом плане из уже имеющихся я просто не нашел. Получился этакий аналог «/etc» директории, размещаемый в среде админовского компа или виртуальной машины, поддерживающий полный цикл администрирования кластера (включая формирование всех docker-образов, CI & CD), хранимый для надежности и сопровождения в git. В качестве языка wrapper-обертки был выбран вполне подходящий для этого и максимально стабильный язык - Bash:) Ну а поскольку обновление сертификатов является принципиально важной частью админ-поддержки кластера, то и поддержку Letsencrypt я тоже включил в это самописное wrapper-приложение. При смене облачной платформы просто дописывал плагины работы с конкретными репозиториями docker-образов и DNS-провайдерами. Последующий спокойный и незаметный для программистов перезд GCP->AWS->Azure полностью оправдал такое на первый взгляд усложненное решение.

vinvlad ★★
()