[QUOTE]Олег Матасов написал:
Я решал проблему так:
из папки / home/bitrix/dehydrated/domains переносим куда-нибудь в другое место текстовые файлы всех доменов, которые уже получили сертификаты.
Далее перезапускаем через меню окружения получение сертификата для нужного сайта. dehydrated отрабатывает только для нужного домена. После получения сертификата таким способом текстовики перенесенных из папки доменов нужно вернуть, чтобы обновление сертификатов проходило штатно.
Причем мне абсолютно непонятно, чем руководствовались разработчики окружения, когда закладывали логику пере получения ВСЕХ сертификатов при запросе сертификата на новый сайт, крайне не оптимально. И ответ администрации в духе "ждать пока спадет лимит, поститься и слушать радио Радонеж" - фееричен. А что делать тем, кому нужно 100 сайтов допустим на новый сервер перенести. Если лимит 5 сертификатов в неделю - простым подсчетом понимаем что перенос будет идти 20 недель!!! И любой клиент при таком сроке скорее выкинет Битрикс в топку чем на такое пойдет. Проконсультировались бы с техническими спецами и предложили бы хотя-бы такой кустарный вариант который я описал в первом абзаце.[/QUOTE]
Когда разрабатывалась данная версия решения certbot собирался из бинарников, и не присутствовал в репозиториях, поскольку не являлся стабильным.
Сейчас он есть в репках и собирать по другому смысла нет.
Хотя все-таки не совсем понятно зачем нужна была кастомка dehydrated , тем более что у certbot есть --dry-run
Так же ошибка действительно есть и она действительно с dehydrated -c --force, реально же это просто забыли после отладки ( ответ сапорта).
Однако что действительно непонятно зачем сливать все это в кучу когда каждый сайт должен проверяться отдельно.
И да при нескольких сотнях сайтов приходится патчить эту проблему.
Могу вам подкинуть еще идею, если у вас несколько сотен сайтов то они бывают уезжают или закрываются в следствие этого проверка сертификата этого сайта будет ошибочной, что приведет опять же к той-же проблеме, сайты вообще перестанут получать сертификат.
Механизма отзыва сертификатов у сайта который не смог пройти проверку в виду отсутствие А записи на этом сервере вообще нет.
Так что мне пришлось писать его самому.
А таких причин больше чем 1
1. сайт уехал, но не удалился с админки.
2. не продлили домен ;)
3. домен 3 уровня типа dev.dev2.site.ru, основной сайт поменял днс сервер и тд, в общем этой записи больше нет.
4. ААА запись в домене
5. Ошибка записи в файл и тд, там вариантов миллион, но они мало вероятны.
6. (тут без коментариев) Битрикс VM не генерирует конфиги по шаблону, а все изменения вносит в уже сгенереный 1 раз конфиг!! то есть если вы внесли кастомку в конфиг то можете получить следующе
а) ничего поскольку парсер нашел место куда вставиться и вставил свой блок, например редирект на https который вы включили.
б) не шашел место и у вас перестали работать правила вообще к этому конфигу ;)
в) нашел вставил убедился что все сломал и откатил что привело опять же к 5 попыткам на все сайты.
Я решал проблему так:
из папки / home/bitrix/dehydrated/domains переносим куда-нибудь в другое место текстовые файлы всех доменов, которые уже получили сертификаты.
Далее перезапускаем через меню окружения получение сертификата для нужного сайта. dehydrated отрабатывает только для нужного домена. После получения сертификата таким способом текстовики перенесенных из папки доменов нужно вернуть, чтобы обновление сертификатов проходило штатно.
Причем мне абсолютно непонятно, чем руководствовались разработчики окружения, когда закладывали логику пере получения ВСЕХ сертификатов при запросе сертификата на новый сайт, крайне не оптимально. И ответ администрации в духе "ждать пока спадет лимит, поститься и слушать радио Радонеж" - фееричен. А что делать тем, кому нужно 100 сайтов допустим на новый сервер перенести. Если лимит 5 сертификатов в неделю - простым подсчетом понимаем что перенос будет идти 20 недель!!! И любой клиент при таком сроке скорее выкинет Битрикс в топку чем на такое пойдет. Проконсультировались бы с техническими спецами и предложили бы хотя-бы такой кустарный вариант который я описал в первом абзаце.[/QUOTE]
Когда разрабатывалась данная версия решения certbot собирался из бинарников, и не присутствовал в репозиториях, поскольку не являлся стабильным.
Сейчас он есть в репках и собирать по другому смысла нет.
Хотя все-таки не совсем понятно зачем нужна была кастомка dehydrated , тем более что у certbot есть --dry-run
Так же ошибка действительно есть и она действительно с dehydrated -c --force, реально же это просто забыли после отладки ( ответ сапорта).
Однако что действительно непонятно зачем сливать все это в кучу когда каждый сайт должен проверяться отдельно.
И да при нескольких сотнях сайтов приходится патчить эту проблему.
Могу вам подкинуть еще идею, если у вас несколько сотен сайтов то они бывают уезжают или закрываются в следствие этого проверка сертификата этого сайта будет ошибочной, что приведет опять же к той-же проблеме, сайты вообще перестанут получать сертификат.
Механизма отзыва сертификатов у сайта который не смог пройти проверку в виду отсутствие А записи на этом сервере вообще нет.
Так что мне пришлось писать его самому.
А таких причин больше чем 1
1. сайт уехал, но не удалился с админки.
2. не продлили домен ;)
3. домен 3 уровня типа dev.dev2.site.ru, основной сайт поменял днс сервер и тд, в общем этой записи больше нет.
4. ААА запись в домене
5. Ошибка записи в файл и тд, там вариантов миллион, но они мало вероятны.
6. (тут без коментариев) Битрикс VM не генерирует конфиги по шаблону, а все изменения вносит в уже сгенереный 1 раз конфиг!! то есть если вы внесли кастомку в конфиг то можете получить следующе
а) ничего поскольку парсер нашел место куда вставиться и вставил свой блок, например редирект на https который вы включили.
б) не шашел место и у вас перестали работать правила вообще к этому конфигу ;)
в) нашел вставил убедился что все сломал и откатил что привело опять же к 5 попыткам на все сайты.