Comments 22
Советую попробовать haproxy. Как раз для этих целей
Почему не nginx в качестве прокси? Он легче и удобнее апача в этой роли. К тому же, если что-то пойдет не так, сервис не упадет после nginx reload.
Как я понял, на время выпуска сертификата certbot останавливает апач и запускает свой сервис для подтверждения сертификата — не очень удобно. Как быть, если за проксей несколько сайтов, certbot сам для них выпустит сертификаты?
У себя использую сервис продления в отдельном докер контейнере, как в этом примере — http://www.automationlogic.com/using-lets-encrypt-and-docker-for-automatic-ssl/
очень удобно.
Как я понял, на время выпуска сертификата certbot останавливает апач и запускает свой сервис для подтверждения сертификата — не очень удобно. Как быть, если за проксей несколько сайтов, certbot сам для них выпустит сертификаты?
У себя использую сервис продления в отдельном докер контейнере, как в этом примере — http://www.automationlogic.com/using-lets-encrypt-and-docker-for-automatic-ssl/
очень удобно.
certbot --renew перевыпускает (при необходимости) все сертификаты, выданные текущему хосту.
Чтобы не останавливать текущий веб-сервер, можно использовать режим webroot с указанием каталога, который должен обслуживать (по http) веб-сервер самостоятельно.
Так исторически сложилось с Apache.
По поводу certbot Вам ответили ниже.
У меня к счастью, нет высоконагруженных серверов, поэтому можно продлевать не боясь что какой-то сервис упадет, более того, пару не хитрых манипуляций с cron, и задача будет стартовать по ночам, когда нагрузки практически нет. Ну и статья в общем и целом расчитана на не большие нагрузки.
По поводу certbot Вам ответили ниже.
У меня к счастью, нет высоконагруженных серверов, поэтому можно продлевать не боясь что какой-то сервис упадет, более того, пару не хитрых манипуляций с cron, и задача будет стартовать по ночам, когда нагрузки практически нет. Ну и статья в общем и целом расчитана на не большие нагрузки.
cp /root/certbot/certbot /usr/lib/python2.7/dist-packages/
Почему бы тогда не воспользоваться pip install? Обновление пакета certbot перезатрёт ваши локальные изменения
так это ведь хорошо! особенно если в репозитарии появиться новая версия.
проблема в том, что в репо версия 0.10.2, а на гите уже 0.16.0, собственно как обычно
проблема в том, что в репо версия 0.10.2, а на гите уже 0.16.0, собственно как обычно
хммм… а зачем крон пытается запустить обновление сертификатов каждый понедельник в 2:30?)))
я может не туда смотрю, но если необходимо запускать крон каждые 3 месяца, то это
* * * */3 * certbot renew
я может не туда смотрю, но если необходимо запускать крон каждые 3 месяца, то это
* * * */3 * certbot renew
Лучше запускать раз в месяц или чаще, он обновляет только те сертификаты, которые истекают скоро.
Причин запускать его относительно часто две: во-первых на хосте сетификатов может быть больше одного (и получены могут быть они в разное время), во-вторых при очередной попытке обновления может и не получиться обновить (сеть лежит, сервер letsencrypt'а или ещё что).
Я только не понял про certbot. С официального сайта предлагается скачать только 1 питон скрипт, зачем тянуть весь репозиторий?
И сам certbot отвечает только за обновление и запуск скриптов работы с сертификатами.
И сам certbot отвечает только за обновление и запуск скриптов работы с сертификатами.
В статье был упомянут MS TMG — но тема его замены на Apache/Nginx Reverse Proxy не раскрыта.
Если кратко — MS TMG умел и умеет публиковать WEB-сервисы, авторизация в которых родная от Microsoft (Kerberos/NTLMv2 — т.е. Windows Integrated). Это всякие Exchange (с пачкой разных служб), SharePoint, Lync/Skype for Business и т.д. Собственно у многих Заказчиков оно стоит до сих пор, публикуя ресурсы. При этом как правило на TMG один единственный белый IP-адрес.
И основная проблема перехода с TMG на другой Reverse (Apache/Nginx и т.д.) в том, что мало кто умеет Kerberos/NTLM из коробки. Буду очень рад, если кто-то кинет пруфом, если ситуация тут меняется со временем.
Пока единственная адекватная замена именно функции Reverse — это использование MS IIS + компонента ARR (Application Request Routing)… что автоматом требует Windows. Работает, не спорю. Но хочется адекватной альтернативы и других вариантов (причем OpenSource).
Если кратко — MS TMG умел и умеет публиковать WEB-сервисы, авторизация в которых родная от Microsoft (Kerberos/NTLMv2 — т.е. Windows Integrated). Это всякие Exchange (с пачкой разных служб), SharePoint, Lync/Skype for Business и т.д. Собственно у многих Заказчиков оно стоит до сих пор, публикуя ресурсы. При этом как правило на TMG один единственный белый IP-адрес.
И основная проблема перехода с TMG на другой Reverse (Apache/Nginx и т.д.) в том, что мало кто умеет Kerberos/NTLM из коробки. Буду очень рад, если кто-то кинет пруфом, если ситуация тут меняется со временем.
Пока единственная адекватная замена именно функции Reverse — это использование MS IIS + компонента ARR (Application Request Routing)… что автоматом требует Windows. Работает, не спорю. Но хочется адекватной альтернативы и других вариантов (причем OpenSource).
Я с Вами согласен и на одной из площадок под S4b поднимал TMG специально, ибо без Reverse Proxy он вообще не работает, а на IIS мне не нравить.
Ну и вообще, TMG как продукт Microsoft является лучшим решение в работе в сетях Microsoft. Жаль что мелкомягкие сняли с поддержки, ведь за продуктом было большое будущее.
Ну как реализованно на другой инфраструктуре, стоит на границе TMG, на нем публикации Exchange, VPN, и прочее.
Проброс 80,443 до Apache Reverse, на котором публикуются сайты компании и работает certbot.
Я-бы с удовольствием ушел с Apache и остался на TMG, но certbot под windows — это выше моего понимания (бзик такой, ага), вот и приходиться изворачиваться.
Я так и не нашел альтернативы, куда уйти с TMG, либо дорого, либо не подходит.
Ну и вообще, TMG как продукт Microsoft является лучшим решение в работе в сетях Microsoft. Жаль что мелкомягкие сняли с поддержки, ведь за продуктом было большое будущее.
Ну как реализованно на другой инфраструктуре, стоит на границе TMG, на нем публикации Exchange, VPN, и прочее.
Проброс 80,443 до Apache Reverse, на котором публикуются сайты компании и работает certbot.
Я-бы с удовольствием ушел с Apache и остался на TMG, но certbot под windows — это выше моего понимания (бзик такой, ага), вот и приходиться изворачиваться.
Я так и не нашел альтернативы, куда уйти с TMG, либо дорого, либо не подходит.
Слышал что TMG пришлось закрыть потому что все разработчики поувольнялись, а код был слишком плохой и не документированный, так что никто другой не смог в нем разобраться.
Поддерживать проект было некому, по этой причине пришлось выкатить урезаный ISA.
Поддерживать проект было некому, по этой причине пришлось выкатить урезаный ISA.
Sign up to leave a comment.
Настройка Reverse Proxy Apache (Debian 8) с автоматической выдачей Let's Encrypt