Посмотрел, отличное решение, особенно в плане краткости. Мне понравилось. https://github.com/artyom/leproxy реализован заметно проще, чем у меня как за счет более активного использования сторонних компонентов, так и за счет меньшего количества проверок.
Увидел реальное использование golang.org/x/crypto/acme/autocert — как раз интересно было насколько реально работает этот инструмент или он еще совсем в разработке. Смотрел его, когда свой проект писать начинал.
Собственно и сейчас на него посматриваю, чтобы выкинуть значительную часть своего кода и проект упростить. Пока удерживают некоторые нюансы в реализации и сложность работы с гуглом как с автором библиотеки, т.е. несмотря на то что это BSD-лицензия внести туда изменения может быть проблемой. Например они pull-request'ы не принимают и надо отдельно изучать как у них это устроено. Чуть позже буду выделять часть управления сертификатами в отдельный пакет — чтобы его можно было переиспользовать отдельно от прокси, как раз буду ориентироваться на интерфейс autocert.
Сам менеджер еще не очень готов, например у них только запланирована, но еще не сделана поддержка таймаутов при выписке сертификата + еще какие-то мелочи нашел, которые меня в менеджере сертификатов не устроили. Т.е. я бы и поправил с удовольствием, но потом непонятно как свои изменения обратно влить.
По итогам сравнения:
https://github.com/artyom/leproxy
Очень простой для понимания и дополнения кода. Собственно самого кода минимум, все основные компоненты переиспользуются из сторонних библиотек (проксирование, выписка и хранение сертификатов).
Для проксирования используется обработчик, встроенный в язык. Он точно лучше протестирован, чем у меня в lets-proxy.
Работает с заранее заданным списком доменов.
Может проксировать запросы к разным доменам на разные бэкенды, причем не только по tcp, но и через сокеты.
https://github.com/rekby/lets-proxy
Работает с произвольным, заранее неизвестным, изменяющимся во времени набором доменов. Например на сервере хостинга (для этого и делается) — постоянно появляются новые домены, удаляются старые.
В простейшем случае совсем не требует настройки, в т.ч. задания списка серверов.
По команде умеет устанавливаться/работать как служба в windows и демон в linux.
Поддержка не только http, но и tcp-проксирования.
Собственная реализация прокси-сервера более топорная и экономичная по ресурсам, чем встроенный вариант (намного меньше манипуляций, выделений памяти и т.п.). Кроме того встроенный вариант режет поддержку websocket (вырезает заголовок upgrade из запроса).
Посмотрел, nginx вроде нельзя настроить таким образом чтобы при несовпадении заголовков запрос начал бы проксироваться в tcp-режиме на отдельный сервер с сохранением начального запроса, содержащего запрашиваемый домен.
Т.е. сам домен передать не проблема, заголовок передать тоже относительно не проблема — можно просто сделать новый https-запрос к бэкэнду. (вопрос как быть с фейковыми запросами чтобы как проксёй для внешних сервисов не служить — отдельный). Проблема потом передать обратно ответ сервера в неизменном виде, как при обычном tcp-проксировании.
Если есть желание проксировать именно через nginx — можно или отдельно сертификаты выписывать, по спискам или воспользоваться https://github.com/GUI/lua-resty-auto-ssl как Erelecano рекомендовал
отчет чекера можно посмотреть тут https://www.ssllabs.com/ssltest/analyze.html?d=www.f1f2.ru
тесты производительности занимают много времени, пока провести их не готов. Но могу для теста выделить пару виртуальных машин на несколько дней человеку, который знает как это делается и готов провести и опубликовать результаты сравнений.
Собственно ответ чуть выше — перед попыткой выписать сертификат делаются проверки о том что домен действительно работает на этом сервере. Рассчет изнакально как раз для использования на хостинге.
да, cloudflare умеет раздавать сайт по https, но это решение другого плана — это внешний сервис, а внешний сервис это сразу ряд рисков:
1. Домен нужно переделегировать и дальше его работа целиком зависит от cloudflare — как в плане работоспособности, так и в плане ценовой/тарифной политики. Кроме того это может быть сложно (как технически так и административно).
2. http/https трафик будет проходить через чужие серверы, при этом если у вас на конечном сервере https не насртроен то от cloudflare до вас трафик пойдет в открытом виде (будет ли собираться и использоваться зависит уже от везения).
3. Дополнительная точка отказа.
Сама инфраструктура по опыту вполне надёжна, но бывают недоразумения — например с блокировкой IP-адреса из-за нехорошего соседа. CF — иностранная компания и на предупреждения роскомнадзора может внимания не обратить даже если его получит и не выключить провинившегося.
Лично сталкивался с тем что у некоторых клиентов сайт просто не работал при пропускании трафика через CF (еще когда блокировок даже небыло). Разбираться с этим в теории можно через поддержку, но это время (часто — потеря денег) + нужен английский.
4. Это может стать проблемой когда доменов много и/или когда они чужите и свободного управления доменами нет (хостинг, веб-студии).
нет, перед выпиской сертификата производится проверка через локальный dns, dns yandex, dnsgoogle для A и AAAA записей. Если найдётся хоть одна, которая не соответствует одному из IP-адресов сервера — сертификат выписываться не будет.
собственно они и без проверок бы не выписались, но можно было бы упереться в лимиты на висящие авторизации.
1. К сожалению я не нашел его, когда искал.
2. Система нужна универсальная для windows и linux, lua-resty-auto-ssl на работу в windows явно не рассчитан и собрать его если и можно то думаю что нетривиально.
за наводку спасибо, если бы нашел раньше — попробовал бы под винду собрть.
Ну и в любом случае для настройки мой вариант явно проще, так что это скорее альтернатива чем велосипед.
Думаю такое возможно, если заставить для сайта по умолчанию nginx проксировать запросы тоже по https.
Однако тут потребуются дополнительные инструменты:
1. для формирования/обновления конфига nginx, причем при обновлении надо заново проверять все сертификаты которые туда включаются (вдруг файл повредился и nginx из-за битого сертификата перестанет работать).
2. Для перезапуска nginx.
3. Мне кажется что в случаях
4. Потребуется отдельная простукивался, которая будет бегать по выписанным сертификатам, проверять срок их действия и заранее что-то делать (обращаться к выписывалке, переделывать временно конфиг nginx и т.п.) чтобы своевременно обновлять сертификат.
В такой схеме думаю проще будет выписывать сертификаты без такой прокси, просто по списку. Хотя мысль интересная, попробую может ли это в принципе работать.
Однако самих сертификатов может быть много, например на сервере где сейчас программа в пробном режиме работает за сутки выписалось около 500 сертификатов.
т.е. если у вас к одному серверу привязано несколько доменов для каждого из них будет выписан свой сертификат и все они могут работать одновременно.
В ходе изучения выяснилось, что urbackup в режиме файлового бэкапа для linux сохраняет только содержимое файлов, но не сохраняет (или не восстанавливает) их атрибуты: владельца, права доступа.
Так что для частичного ручного восстановления данных оно подойдёт (например слетевшую базу восстановить), а вот для восстановления сервера целиком уже не особо — вручную все права правильно выставить на сервере задача нетривиальная.
Такого требования нет. Есть требование предъявить удостоверение личности (паспорт) прописка в нём не обязательна, если её нет — адрес записывается просто со слов. Уточнял у мегафона и теле2.
Все так, вот только LE поддерживает лишь ограниченное количество подобных доменов. 128 штук, если быть точным. Поэтому в данном вопросе интеграция с Let’s Encrypt не помощник.
Еще точнее — 100 штук в одном сертификате, таких сертификатов можно выписывать 20 в неделю.
https://letsencrypt.org/docs/rate-limits/
Программы просто не компилируются, если не соблюдать ее правила.
Большинство правил форматирования можно спокойно нарушать и программа при этом нормально компилируется.
Но в больших проектах часто делаются автопроверки на соответствие кода стилю и туда не пропускаются коммиты, не соответствющие правилам gofmt — чтобы код выглядел одинакого.
В личных проектах тоже запускаю gofmt, просто потому что это удобно.
Ограничения по изменениям — можно просто административно. Если этого недостаточно — завести отдельный репозиторий из которого будет делаться публикация (и для этого репозитория прописать шаг запуска публикации).
Для этого же спец. репозитория заданы переменные, необходимые для публикации (ключи доступа на сервер например), без которых публикация невозможна.
В этом случае разработчик не сможет путем локальных изменений что-то опубликовать, т.к. доступа к спец. репозиторию не имеет.
У почты РФ всё очень плохо на местах: чтобы посылку получить нужно отстоять огромную очередь. Часто в несколько часов. Для меня как получателя это перекрывает любую надёжность доставки для массового товара.
В подавляющем большинстве случаев мне проще подождать еще пару дней или неделю и получить посылку курьером, в почтамате но только без почты РФ.
https://habrahabr.ru/info/help/rules/
Вот список того, чего на ресурсе делать не следует:
…
Путать «Хабр» с жалобной книгой
…
Я понимаю беспокойство, но тут вроде место для информационных публикаций, т.е. публикация должна нести в себе какой-то опыт, пользу, результаты исследования и т.п.
В этом посте ничего такого не наблюдаю, в отличие от предыдущих постов — там в рассказывали об опыте использования компьютером/интернетом незрячими или плохо видящими людьми — оно интересно, полезно, тоже обращает внимание на проблему и как раз к месту. В отличие от этого.
Увидел реальное использование golang.org/x/crypto/acme/autocert — как раз интересно было насколько реально работает этот инструмент или он еще совсем в разработке. Смотрел его, когда свой проект писать начинал.
Собственно и сейчас на него посматриваю, чтобы выкинуть значительную часть своего кода и проект упростить. Пока удерживают некоторые нюансы в реализации и сложность работы с гуглом как с автором библиотеки, т.е. несмотря на то что это BSD-лицензия внести туда изменения может быть проблемой. Например они pull-request'ы не принимают и надо отдельно изучать как у них это устроено. Чуть позже буду выделять часть управления сертификатами в отдельный пакет — чтобы его можно было переиспользовать отдельно от прокси, как раз буду ориентироваться на интерфейс autocert.
Сам менеджер еще не очень готов, например у них только запланирована, но еще не сделана поддержка таймаутов при выписке сертификата + еще какие-то мелочи нашел, которые меня в менеджере сертификатов не устроили. Т.е. я бы и поправил с удовольствием, но потом непонятно как свои изменения обратно влить.
По итогам сравнения:
https://github.com/artyom/leproxy
Очень простой для понимания и дополнения кода. Собственно самого кода минимум, все основные компоненты переиспользуются из сторонних библиотек (проксирование, выписка и хранение сертификатов).
Для проксирования используется обработчик, встроенный в язык. Он точно лучше протестирован, чем у меня в lets-proxy.
Работает с заранее заданным списком доменов.
Может проксировать запросы к разным доменам на разные бэкенды, причем не только по tcp, но и через сокеты.
https://github.com/rekby/lets-proxy
Работает с произвольным, заранее неизвестным, изменяющимся во времени набором доменов. Например на сервере хостинга (для этого и делается) — постоянно появляются новые домены, удаляются старые.
В простейшем случае совсем не требует настройки, в т.ч. задания списка серверов.
По команде умеет устанавливаться/работать как служба в windows и демон в linux.
Поддержка не только http, но и tcp-проксирования.
Собственная реализация прокси-сервера более топорная и экономичная по ресурсам, чем встроенный вариант (намного меньше манипуляций, выделений памяти и т.п.). Кроме того встроенный вариант режет поддержку websocket (вырезает заголовок upgrade из запроса).
Т.е. сам домен передать не проблема, заголовок передать тоже относительно не проблема — можно просто сделать новый https-запрос к бэкэнду. (вопрос как быть с фейковыми запросами чтобы как проксёй для внешних сервисов не служить — отдельный). Проблема потом передать обратно ответ сервера в неизменном виде, как при обычном tcp-проксировании.
Если есть желание проксировать именно через nginx — можно или отдельно сертификаты выписывать, по спискам или воспользоваться https://github.com/GUI/lua-resty-auto-ssl как Erelecano рекомендовал
тесты производительности занимают много времени, пока провести их не готов. Но могу для теста выделить пару виртуальных машин на несколько дней человеку, который знает как это делается и готов провести и опубликовать результаты сравнений.
1. Домен нужно переделегировать и дальше его работа целиком зависит от cloudflare — как в плане работоспособности, так и в плане ценовой/тарифной политики. Кроме того это может быть сложно (как технически так и административно).
2. http/https трафик будет проходить через чужие серверы, при этом если у вас на конечном сервере https не насртроен то от cloudflare до вас трафик пойдет в открытом виде (будет ли собираться и использоваться зависит уже от везения).
3. Дополнительная точка отказа.
Сама инфраструктура по опыту вполне надёжна, но бывают недоразумения — например с блокировкой IP-адреса из-за нехорошего соседа. CF — иностранная компания и на предупреждения роскомнадзора может внимания не обратить даже если его получит и не выключить провинившегося.
Лично сталкивался с тем что у некоторых клиентов сайт просто не работал при пропускании трафика через CF (еще когда блокировок даже небыло). Разбираться с этим в теории можно через поддержку, но это время (часто — потеря денег) + нужен английский.
4. Это может стать проблемой когда доменов много и/или когда они чужите и свободного управления доменами нет (хостинг, веб-студии).
собственно они и без проверок бы не выписались, но можно было бы упереться в лимиты на висящие авторизации.
Другие варианты тоже еще посмотрю — что у себя мог упустить.
2. Система нужна универсальная для windows и linux, lua-resty-auto-ssl на работу в windows явно не рассчитан и собрать его если и можно то думаю что нетривиально.
за наводку спасибо, если бы нашел раньше — попробовал бы под винду собрть.
Ну и в любом случае для настройки мой вариант явно проще, так что это скорее альтернатива чем велосипед.
Однако тут потребуются дополнительные инструменты:
1. для формирования/обновления конфига nginx, причем при обновлении надо заново проверять все сертификаты которые туда включаются (вдруг файл повредился и nginx из-за битого сертификата перестанет работать).
2. Для перезапуска nginx.
3. Мне кажется что в случаях
4. Потребуется отдельная простукивался, которая будет бегать по выписанным сертификатам, проверять срок их действия и заранее что-то делать (обращаться к выписывалке, переделывать временно конфиг nginx и т.п.) чтобы своевременно обновлять сертификат.
В такой схеме думаю проще будет выписывать сертификаты без такой прокси, просто по списку. Хотя мысль интересная, попробую может ли это в принципе работать.
Однако самих сертификатов может быть много, например на сервере где сейчас программа в пробном режиме работает за сутки выписалось около 500 сертификатов.
т.е. если у вас к одному серверу привязано несколько доменов для каждого из них будет выписан свой сертификат и все они могут работать одновременно.
Так что для частичного ручного восстановления данных оно подойдёт (например слетевшую базу восстановить), а вот для восстановления сервера целиком уже не особо — вручную все права правильно выставить на сервере задача нетривиальная.
Еще точнее — 100 штук в одном сертификате, таких сертификатов можно выписывать 20 в неделю.
https://letsencrypt.org/docs/rate-limits/
Большинство правил форматирования можно спокойно нарушать и программа при этом нормально компилируется.
Но в больших проектах часто делаются автопроверки на соответствие кода стилю и туда не пропускаются коммиты, не соответствющие правилам gofmt — чтобы код выглядел одинакого.
В личных проектах тоже запускаю gofmt, просто потому что это удобно.
Manual actions
возможно это то, что вам нужно.
Ограничения по изменениям — можно просто административно. Если этого недостаточно — завести отдельный репозиторий из которого будет делаться публикация (и для этого репозитория прописать шаг запуска публикации).
Для этого же спец. репозитория заданы переменные, необходимые для публикации (ключи доступа на сервер например), без которых публикация невозможна.
В этом случае разработчик не сможет путем локальных изменений что-то опубликовать, т.к. доступа к спец. репозиторию не имеет.
Вопрос был:
1. почему сейчас можно сказать что ты помогал с блогом
2. какую функцию выполняли безопасники при фильтрации содержимого
А ты ответил на: какая была твоя роль и смогут ли они дальше без тебя работать.
В подавляющем большинстве случаев мне проще подождать еще пару дней или неделю и получить посылку курьером, в почтамате но только без почты РФ.
Вот список того, чего на ресурсе делать не следует:
…
Путать «Хабр» с жалобной книгой
…
Я понимаю беспокойство, но тут вроде место для информационных публикаций, т.е. публикация должна нести в себе какой-то опыт, пользу, результаты исследования и т.п.
В этом посте ничего такого не наблюдаю, в отличие от предыдущих постов — там в рассказывали об опыте использования компьютером/интернетом незрячими или плохо видящими людьми — оно интересно, полезно, тоже обращает внимание на проблему и как раз к месту. В отличие от этого.