Да

Да?

Бля. Ну так это чьё-то наколенное решение а не популярные сервера типа родного

нишо не понял. протокол есть, клиент есть, клиент умеет в хуки.

раз в X времени пускаем обработку всех известных сертификатов, узнаем записи, добавлям в днс, пинаем LE, чтобы они порезолвили, получаем новые сертификаты, деплоим.

нишо не понял. протокол есть, клиент есть, клиент умеет в хуки.

Какой блять клиент? У меня perkele тоже умеет. Кто о нём знает? Кто об этом вжопузадирищенском клиенте знает?

Какой блять клиент? У меня perkele тоже умеет. Кто о нём знает? Кто об этом вжопузадирищенском клиенте знает?

а какая разница, какой клиент? или вам нужно (с), (ТМ) и (R)? certbot мб кстати тоже научился в DNS-верификацию, но тут сказать не могу.

нишо не понял. протокол есть, клиент есть, клиент умеет в хуки.

Ну т.е. челвоек молодец - сделал клиент с хуками. Но это немного не то, что предлагали выше

а какая разница, какой клиент? или вам нужно (с), (ТМ) и (R)? certbot мб кстати тоже научился в DNS-верификацию, но тут сказать не могу.

Я даже знать об этом не хочу уже :)))

Короче, это всё не отменяет, что проект гавно. Два годя блять подгонять хуки - это пиздец

Ну т.е. челвоек молодец - сделал клиент с хуками. Но это немного не то, что предлагали выше

да у меня поинт простой. вместо пляски с HTTP-верификацией (которую кстати вполне можно победить на большом масштабе) можно использовать DNS-верификацию, которая медленнее, но не требует активности на http вообще

Короче, это всё не отменяет, что проект гавно. Два годя блять подгонять хуки - это пиздец

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

да у меня поинт простой. вместо пляски с HTTP-верификацией (которую кстати вполне можно победить на большом масштабе) можно использовать DNS-верификацию, которая медленнее, но не требует активности на http вообще

В случаи шаред хостинга может не быть контроля над днс клиента

да у меня поинт простой. вместо пляски с HTTP-верификацией (которую кстати вполне можно победить на большом масштабе) можно использовать DNS-верификацию, которая медленнее, но не требует активности на http вообще

Ну это понятно. И правильно. Я тоже так думал. Но есть проблема - я или не NS для домена, или домен на момих NS, но у меня нет API :)))

В случаи шаред хостинга может не быть контроля над днс клиента

В случае любого хостинга

В случаи шаред хостинга может не быть контроля над днс клиента

в случае шареда непонятны проблемы с http-верификацией вообще.

Ну это понятно. И правильно. Я тоже так думал. Но есть проблема - я или не NS для домена, или домен на момих NS, но у меня нет API :)))

всем бывает тяжело. :)

в случае шареда непонятны проблемы с http-верификацией вообще.

Ну не осилили люди, бывает

в случае шареда непонятны проблемы с http-верификацией вообще.

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

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

Один из контролей - это кстати деплоймент токена на бэкенд

а зачем контроллировать шаги? эта система - чёрный ящик) тут или есть хороший результат или результата нет

если результата нет - попробуем запустить ещё пару раз

вдруг получится

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

эти точки отказа по идее вполне решены, если шаред норм. отказоустойчивый фронтенд есть. hot-standby бэкенд, который отвечает на LE-запросы - есть. этот бэкенд имеет право прилечь на единицы секунд без всяких проблем. в конце концов мы сертификаты выпускаем, а не транзакции делаем. distributed-lock + active-passive пачка бэкендов, плюс система деплоя сертификатов (у вас же уже есть она, правда?). не вижу проблем, которые в шареде не должны были быть уже решены.

а зачем контроллировать шаги? эта система - чёрный ящик) тут или есть хороший результат или результата нет

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

лан, забей, видимо, я просто не понимаю твою задачу

эти точки отказа по идее вполне решены, если шаред норм. отказоустойчивый фронтенд есть. hot-standby бэкенд, который отвечает на LE-запросы - есть. этот бэкенд имеет право прилечь на единицы секунд без всяких проблем. в конце концов мы сертификаты выпускаем, а не транзакции делаем. distributed-lock + active-passive пачка бэкендов, плюс система деплоя сертификатов (у вас же уже есть она, правда?). не вижу проблем, которые в шареде не должны были быть уже решены.

Ничего не понял. Ну? Как в эту схему вписывается звездолет по имени certbot?

Ничего не понял. Ну? Как в эту схему вписывается звездолет по имени certbot?

а кто сказал сертбот? я не говорил. если очень хочется сертбот, то вы пущаете сертбот на том самом бэкенде, который в текущий момент active. запросы от LE проксируете со всех фронтендов на этот бэкенд. сертбот и не подозревает обо всей этой ебанистике. естественно, он должен работать в режиме cert-only и просто складывать сертификат вместо попыток переписать конфиги веб-серверов. вы подхватываете сертификат и пихаете в систему деплоя сертификатов.

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

а кто сказал сертбот? я не говорил. если очень хочется сертбот, то вы пущаете сертбот на том самом бэкенде, который в текущий момент active. запросы от LE проксируете со всех фронтендов на этот бэкенд. сертбот и не подозревает обо всей этой ебанистике. естественно, он должен работать в режиме cert-only и просто складывать сертификат вместо попыток переписать конфиги веб-серверов. вы подхватываете сертификат и пихаете в систему деплоя сертификатов.

Чо? Какй в жопу active? Они все active

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

мб. но альтернатив нет и оно работает.

мб. но альтернатив нет и оно работает.

Хуево работает. Вон те же IDN - анонсировали в октябре, не работает по сей день

Чо? Какй в жопу active? Они все active

это у вас в голове они active, а для того чтобы ванильный сертбот работал на некластерной fs нужен active-passive.

Хуево работает. Вон те же IDN - анонсировали в октябре, не работает по сей день

альтернативы-то есть?

Чуваки. Я вот прочитал весь срач. Думал пойму в чем конкретно проблема. Но нет. Столько эмоций по типу "Ааааа ничего не работает". Фил, вот без "блять", "хуево" и т.д. ты можешь описать, что не так с LE конкретно в твоем случае? Потому что у он настроен на 146% автоматически обновлять сертификаты на хостинге картинок. А там у меня 3 TL-домена и у каждого из них есть и 2го, 3го уровня и 4го уровня поддомены. На всех серты LE.

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

с LE стало удобнее, чем было раньше и сейчас можно бесплатно на все сайты сделать сертификаты, а раньше приходилось платить

альтернативы-то есть?

нет. это понятно

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

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

ну, просто стоит помнить, что LE делает всё бесплатно, возможно, сейчас технологии у них не самые совершенные, но раньше нужно было платить пусть $9 за Comodo, а сейчас $0, это как обижаться на то, что бесплатный хостинг недостаточно надёжный и там плохой uptime...

Чуваки. Я вот прочитал весь срач. Думал пойму в чем конкретно проблема. Но нет. Столько эмоций по типу "Ааааа ничего не работает". Фил, вот без "блять", "хуево" и т.д. ты можешь описать, что не так с LE конкретно в твоем случае? Потому что у он настроен на 146% автоматически обновлять сертификаты на хостинге картинок. А там у меня 3 TL-домена и у каждого из них есть и 2го, 3го уровня и 4го уровня поддомены. На всех серты LE.

1. Неоправданно громоздкий протокол. В нем много лишнего и нет простых вещей. Например нельзя проверить, когда протухает валидация домена. Оазбираться в нем не один час. 2. Стандартная библиотека написана с ООП головного мозга бездумно. С дичайшими костылями, рассказывающими нам об истории развития протокола. Использовать стандартную библиотеку в своих утилитах сложно. Мне например не удалось адекватно разорвать запрос на токен и запрос на проверку токена. 3. Стандартные решения автоматизации реализованы как чорный ящик. Хорошо если нашлепнуты хуки. 4. Боевой сервер кривоватый. Например неработа IDN из-за рукожопия архитектуры сервера

ну, просто стоит помнить, что LE делает всё бесплатно, возможно, сейчас технологии у них не самые совершенные, но раньше нужно было платить пусть $9 за Comodo, а сейчас $0, это как обижаться на то, что бесплатный хостинг недостаточно надёжный и там плохой uptime...

ты их бюджет видел? я его хочу

1. Неоправданно громоздкий протокол. В нем много лишнего и нет простых вещей. Например нельзя проверить, когда протухает валидация домена. Оазбираться в нем не один час. 2. Стандартная библиотека написана с ООП головного мозга бездумно. С дичайшими костылями, рассказывающими нам об истории развития протокола. Использовать стандартную библиотеку в своих утилитах сложно. Мне например не удалось адекватно разорвать запрос на токен и запрос на проверку токена. 3. Стандартные решения автоматизации реализованы как чорный ящик. Хорошо если нашлепнуты хуки. 4. Боевой сервер кривоватый. Например неработа IDN из-за рукожопия архитектуры сервера

1. Что мешает через openssl посмотреть дату экспайра?

а кто сказал сертбот? я не говорил. если очень хочется сертбот, то вы пущаете сертбот на том самом бэкенде, который в текущий момент active. запросы от LE проксируете со всех фронтендов на этот бэкенд. сертбот и не подозревает обо всей этой ебанистике. естественно, он должен работать в режиме cert-only и просто складывать сертификат вместо попыток переписать конфиги веб-серверов. вы подхватываете сертификат и пихаете в систему деплоя сертификатов.

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

1. Что мешает через openssl посмотреть дату экспайра?

валижации домена? что смотреть? )

Что за вилидация. Я так понял тебе надо узнать когда протухнет серт

Что за вилидация. Я так понял тебе надо узнать когда протухнет серт

нет. мне иногда хочется узнать, протухла ли валидация домена.

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

емнип certbot делает это все синхронно. но сварщик не настоящий.

емнип certbot делает это все синхронно. но сварщик не настоящий.

это не важно. важно, что мне в ПУ надо от него получить "моя сделать"

Посмотрите perkele - там сделано тяп ляп, но понятно, чего я хотел добитьсч

https://github.com/perkele/Perkele/blob/master/README ?

https://github.com/schors/perkele

> там сделано тяп ляп, но понятно, чего я хотел добитьсч Вот так open-source проекты и остаются в таком виде. А потом приходит новый "Фил" и говорит: бля тут какой то кал сделали эти мудаки... ?

> там сделано тяп ляп, но понятно, чего я хотел добитьсч Вот так open-source проекты и остаются в таком виде. А потом приходит новый "Фил" и говорит: бля тут какой то кал сделали эти мудаки... ?

не буду оправдываться. тут ты прав

> там сделано тяп ляп, но понятно, чего я хотел добитьсч Вот так open-source проекты и остаются в таком виде. А потом приходит новый "Фил" и говорит: бля тут какой то кал сделали эти мудаки... ?

нет, всетаки буду. у меня нет такого бюджета с неба, как у LE

Собственно perkele у меня на хостинге в хвост и гриву.

не буду оправдываться. тут ты прав

ты форкнул это как отдельный проект) было бы лучше отправить пулл реквест оригинальному автору

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

ты форкнул это как отдельный проект) было бы лучше отправить пулл реквест оригинальному автору

у него иной воркфлоу

но наверное надо ему кинуть как тулсет

уболтать его раздраконить одну функцию

Одна точка это вполне может быть ecmp поверх сотни серверов

Хорошо, ECMP, мы же все равно не знаем, на какую машину придет запрос? Чего я тут не понимаю?

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

@openfbtd смотри, первый шаг - мы на ближайшей возможной точке ловим локейшн

второй шаг - проксируем эти запросы в отдельный пул машинок

ты всегда можешь сделать 2 nginx'а, второй backup'ом

как первое приближение

как второе приближение ты можешь сделать относительно отказоустойчивый допустим MySQL (раз хостинг у тебя. то он уже должен быть)

и на nginx lua налабать за вечер скрипт который будет нужную информацию писать туда

ERROR: S client not available

и тогда уже делать полноценный round robin и пр.

вообще можно еще проанализировать ходит ли LE всегда с одного и того же айпишника на все запросы, если да, то все проще и у тебя делается sticky session на базе source ip и все просто работает

затем действительно развозишь сертификат по всем своим фронтэндам

но это придется делать так и так, даже без LE

Ага. И вот ты только что сам продемонстрировал, что не так уж и прям как два пальца запилить для хостинга LE :)

А то тут пишут что прям ОЛОЛО ЧО СЛОЖНОГО ТО

Подобную схему мы обсуждали. Как и еще пару вариантов

Ага. И вот ты только что сам продемонстрировал, что не так уж и прям как два пальца запилить для хостинга LE :)

а это не как два пальца?

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

кажется что схема 1 с nginx + backup nginx делается за час студентом-стажером

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

Нюансы, нюансы! В вакууме да, в уже существующей инфраструктуре любые подобные штуки *затягиваются*

Нюансы, нюансы! В вакууме да, в уже существующей инфраструктуре любые подобные штуки *затягиваются*

Честно я не понимаю почему. Возникла необходиомсть - взял и запилил за тот же вечер

дал поревьюить коллегам, на следующий день выкатил

в чем проблема?

можешь дать повариться в тестинге недельку-другую

или выкатить на часть инфры

У тебя идеальный мир какой-то. А интеграция с биллингом? А мониторинг? А потестировать?

А получить аппрув руководства? :F

У тебя идеальный мир какой-то. А интеграция с биллингом? А мониторинг? А потестировать?

а с биллингом это зачем интегрировать?

Типа не проплатил - нет тебе бесплатного серта?

ну тогда да, конечно, но это жлобство какое-то

Да нет же

Я прям в шаге от нарушения NDA, к сожалению.

мониторинг - ну да, нужен, но уже включен в заложенное время.

потестировать - неделю на тестинге повариться

Но так, в общем — нюансов до-ху-и-ща

апрув от руководства - ну как-то бюрократизация это, нафига надо?

В каждой инфраструктуре и в каждой компании эти нюансы свои

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

кажется, что бюрократические процессы никак не связаны с LE

Я конкретные примеры без нарушения NDA привести вряд ли смогу, поэтому можно закрыть тему.