Pull to refresh

Comments 31

Далее все как обычно — создаем, настраиваем, прописываем.

Собственно, и перед этим все как обычно.

Да, для людей, знакомых с администрированием Linux, ничего нового здесь нет.
Под «обычно» я имел в виду то, что и локально делается, на машине для разработки.

Не обязательно. Тыщи этих мануалов. Только в вашем заголовке упоминается AWS(кстати, зачем? ничего AWS специфичного в статье не заметил) и это всё отличие.

В принципе да, подойдет для любой системы, если есть Ubuntu и публичный IP. Просто я эти инструкции составил для себя при работе с AWS.
2 статьи, указанные до ката, немного устарели, пришлось кое-что отдельно искать. Вот и решил собрать все в одном месте.
Конец 2017, уже все на полную используют контейнеры, может ещё 2 года назад было б актуально
На продакшене тоже контейнерами оперируете?
У нас как бы HL++ и контейнеры явно лишнее занятие.

Почему бы и нет? Контейнеры очень удобны в production, не в условиях HL, конечно.

… не в условиях HL, конечно.

Ой, да ладно
да в проде на aws контейнеры. у кого HL++ тем подобные статьи наверное не нужны, квалификации им хватает, извините, но давайте смотреть трезво на ситуацию.

Они привносят небольшой оверхед в целом, но, субъективно, для подавляющего большинства применений PHP он не значим.

Обновление сертификата надо добавить в cron для ежедневного запуска.

Везде пишут, что надо прописывать в крон руками.
Два раза ставил certbot, оба раза он сделал это сам. ЧЯДНТ?

Я ставил certbot на Ubuntu, он после установки попросил меня добавить себя в cron.

Не помешало бы осветить добавление второго домена на сервер. Я полагаю, certbot читает не только дефолтный конфиг?

Я с такими не работал, но вроде можно запустить certbot повторно и выбрать другой домен, то есть будет 2 сертификата. Можно один сертификат на 2 имени сделать, но я так делал только для алиасов основного.

Можно запускать повторно, многократно и даже несколько доменов за один раз через пробел.

Но ничего особо страшного в этом нет, он проверяет срок действия сертификата и не дёргает сервер, если ещё достаточно времени осталось.

Просто нет смысла, раз в месяц вполне адекватно

Поэтому я и поставил плюс вашему комментарию, что полностью согласен.

Читаем рекомендацию на сайте Cerbot:
Note:

if you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.
В документации вообще 2 раза в день советуют запускать.
Note:
if you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.
Ваша неправда, касательно наличия DNS записи с A.

У меня основной домен hms.fun, в котором есть только запись CNAME, с маской *.
Сервис проверки DNS говорит, что CNAME hms.fun указывает на запись timonych.mykeenetic.ru типа A. Понятно, что алиасы и поддомены можно по-разному создавать, но изначальная запись A должна где-то быть. Или если у заказчика уже есть mydomain.com с блогом или landing page, то для api.mydomain.com тоже нужна запись A.
Начальная запись однозначно где-то должна быть, чтобы ссылаться на конкретный IP, но в данном случае, у меня белый динамический, и CNAME в данном случае идеальный выход, при условии, что не надо заморачиваться с поддоменами в DNS записях.

CNAME на верхнем уровне сильно не рекомендуется, многие DNS-провайдеры её явно запрещают. AFAIK, это просто не разрешено стандартами, но проверять RFC сейчас лень.

Что вы называете верхним уровнем? Второй?

Причём здесь второй? Может быть любой по уровню, вопрос в наличии soa и ns rr.

Если стоит =404, могут быть проблемы с передачей управления в index.php. Если с ней работает, то убирать необязательно.

Да, `cgi.fix_pathinfo=0` это один из методов решения.
Sign up to leave a comment.

Articles