Можно, конечно, воспользоваться сторонними библиотеками, но я не любитель ставить что-то стороннее, если можно обойтись своими силами. Поэтому пришлось потратить время на написание и тестирование bash-скрипта с именем authenticator.sh:<\/p>\n
#!\/bin\/bash\n\n#Основные параметры\ndomain="kini24.ru"\nusername="graywolf"\npassword="********"\n# Этот параметр менять не нужно\nsubdomain=""\n\n# Корректно задаем судбдомен\n# Если обрабатывается основной домен, то субдомен будет _acme-challenge\n# Если обрабатывается субдомен, то строка будет вида _acme-challenge.subdomain\nif [[ $CERTBOT_DOMAIN = $domain ]]\nthen\n subdomain="_acme-challenge"\nelse\n subdomain="_acme-challenge.${CERTBOT_DOMAIN%.$domain}"\nfi\n\n# Чисто для информации\n\/usr\/bin\/echo "Requesting $CERTBOT_DOMAIN"\n\n# Запрос на удаления текущих записей\ntxt_delete="input_format=json&input_data={\\"username\\":\\"$username\\",\\"password\\":\\"$password\\",\\"domains\\":[{\\"dname\\":\\"$domain\\"}],\\"subdomain\\":\\"$subdomain\\",\\"record_type\\":\\"TXT\\",\\"output_content_type\\":\\"plain\\"}"\n\n# Запрос на добавления записи\ntxt_add="input_format=json&input_data={\\"username\\":\\"$username\\",\\"password\\":\\"$password\\",\\"domains\\":[{\\"dname\\":\\"$domain\\"}],\\"subdomain\\":\\"$subdomain\\",\\"text\\":\\"$CERTBOT_VALIDATION\\",\\"output_content_type\\":\\"plain\\"}"\n\n#Можно проверить при желении\n#\/usr\/bin\/echo "Certbot parameters:"\n#\/usr\/bin\/echo "Current domain: $CERTBOT_DOMAIN"\n\/usr\/bin\/echo "Validation string: $CERTBOT_VALIDATION"\n#\/usr\/bin\/echo "Delete request: $txt_delete"\n#\/usr\/bin\/echo "Add request: $txt_add"\n\n# Запрос на удаление ВСЕХ TXT записей\nif [[ $CERTBOT_DOMAIN != $domain ]]\nthen\n #\/usr\/bin\/echo "Remove all TXT records"\n \/usr\/bin\/curl --silent --data "$txt_delete" "https:\/\/api.reg.ru\/api\/regru2\/zone\/remove_record"\nfi\n\n# Запрос на создание TXT записи\n#\/usr\/bin\/echo "Add new TXT record"\n\/usr\/bin\/curl --silent --data "$txt_add" "https:\/\/api.reg.ru\/api\/regru2\/zone\/add_txt"\n\n# Проверяем что нужная TXT запись появилась. Иначе ждем пока данные обновятся\n#answer=""\n#while [[ $answer != $CERTBOT_VALIDATION ]]\n#do\n# \/usr\/bin\/echo "Requesting DNS record"\n# answer=$(\/usr\/bin\/dig @77.88.8.8 $CERTBOT_DOMAIN txt +short | \/usr\/bin\/tr -d \\" | \/usr\/bin\/egrep $CERTBOT_VALIDATION)\n# \/usr\/bin\/sleep 60\n#done\n\nif [[ $CERTBOT_REMAINING_CHALLENGES -eq 0 ]]\nthen\n sleep 15m\nfi\n\n# Выводим количество доменов, которые осталось обработать\n\/usr\/bin\/echo "Remaining challenges: $CERTBOT_REMAINING_CHALLENGES"<\/code><\/pre>Логика скрипта следующая. В начале задаются основной домен, имя пользователя и пароль от личного кабинета reg.ru. Параметр subdomain<\/i> менять не нужно, он «вычисляется» по ходу выполнения скрипта. Далее если обрабатывается основной домен, то поддомен становится равным _acme-challenge<\/i>, иначе в конец еще добавляется поддомен. Формируется строка для удаления всех (!) текущих записей типа TXT, если обрабатыается поддомен. Записи для основного домена просто добавляются (тут да, небольшой косяк, нужно немного дописать скрипт).
\nЗатем, после добавления DNS-записи скрипт должен был запрашивать все записи TXT и, после появлении нужной, продолжать выполнение, но тут скрипт уходил в бесконечный цикл, поэтому я его закомментировал полностью. Сможете исправить — буду благодарен.
\nНа последнем шаге скрипт, если доменов для регистрации не осталось, ждет 15 минут (время обновления записей у reg.ru от 15 минут до 1 часа) и возвращает управление команде certbot.<\/p>\n
Вызывается скрипт примерной такой командой:<\/p>\n
certbot certonly --manual --agree-tos --manual-public-ip-logging-ok --email admin@kini24.ru --preferred-challenges dns --server https:\/\/acme-v02.api.letsencrypt.org\/directory --domain *.jabber.kini24.ru --domain *.meet.kini24.ru --domain *.kini24.ru --domain kini24.ru --rsa-key-size 2048 --key-type ecdsa --elliptic-curve secp256r1 --redirect --uir --staple-ocsp --must-staple --hsts --manual-auth-hook \/root\/authenticator.sh<\/code><\/pre>В этой команде следующие параметры:
\ncertonly<\/i> — только получение сертификата;
\nagree-tos<\/i> — принимаем пользовательское соглашение;
\nmanual-public-ip-logging-ok<\/i> — соглашаемся на публикацию нашего IP-адреса;
\nemail<\/i> — указываем свою электронную почту для уведомлений;
\npreferred-challenges<\/i> — выбираем тип проверки. Для wildcard-сертификатов это только DNS;
\nserver<\/i> — указываем сервер сертификации;
\ndomain<\/i> — перечисляем свои (суб-)домены;
\nrsa-key-size<\/i> — указываем «размер» ключа. Значение 2048 по умолчанию, оставил на всякий случай;
\nkey-type<\/i> — тип ключа. Снова указано значение по умолчанию;
\nelliptic-curve<\/i> — «кривые». Тут тоже значение по умолчанию;
\nredirect<\/i> — перенаправлять с http на https$
\nuir<\/i> — добавляет в ответ заголовок Content-Security-Policy<\/i> со значением upgrade-insecure-requests<\/i>;
\nstaple-ocsp<\/i> — «сшивание» сертификатов;
\nmust-staple<\/i> — обязательное «сшивание»;
\nhsts<\/i> — принудительная активация защищенного режима, т. е. https;
\nmanual-auth-hook<\/i> — запуск своего скрипта.<\/p>\n",
"date_published": "2023-12-16T16:16:55+07:00",
"date_modified": "2023-12-16T16:16:15+07:00",
"tags": [
"reg.ru",
"wildcard",
"автоматическое",
"обновление",
"рег.ру",
"сертификат",
"скрипт"
],
"_date_published_rfc2822": "Sat, 16 Dec 2023 16:16:55 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "271",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "214",
"url": "https:\/\/kini24.ru\/all\/ustanovka-ejabberd-na-alt-linux\/",
"title": "Установка ejabberd на ALT Linux",
"content_html": "Заметка, по большей части, для себя.<\/h3>\n
Решил поделиться своим опытом установки и настройки ejabberd. В процессе встречал много ошибок, которые можно было бы избежать, будь у меня опыт по работе с этим сервером. Но опыт что называется «нулевой».
\nПервым делом, конечно, установка:<\/p>\n
# apt-get install ejabberd<\/code><\/pre>Несмотря на то, что после установки появляется одноименная служба, воспользоваться ей мы пока не сможем. Угум-с... Поэтому начинаем с того, что создаем базу данных в MySQL и пользователя. SQL-скрипт находится по пути \/usr\/lib\/erlang\/lib\/ejabberd-18.03\/priv\/sql\/mysql.sql<\/i>.
\nТеперь регистрируем пользователя:<\/p>\n# ejabberdctl start\nWARNING: It is not recommended to run ejabberd as root\n# ejabberdctl register admin example.com PaSsWoRd\n# ejabberdctl stop<\/code><\/pre>Ответы сервера будут немного отличаться, но основной вопрос возникает при виде строки «WARNING: It is not recommended to run ejabberd as root<\/i>». Чтобы избавиться от этого предупреждения, нужно запускать ejabberd от имени другого пользователя. Это делает сервис, но он нам пока недоступен. Почти.
\nПосле запуска ejabberdctl в папке \/var\/lib\/ejabberd<\/i> создаются нужные подкаталоги и файлы баз Mnesia. Вот только права у них сейчас root, поэтому сервер не сможет с ними работать. Меняем владельца:<\/p>\n# chown -R ejabberd:ejabberd \/var\/lib\/ejabberd<\/code><\/pre>Не забываем про логи — там то же самое:<\/p>\n
# chown -R ejabberd:ejabberd \/var\/log\/ejabberd<\/code><\/pre>Теперь нужно изменить файл конфигурации сервера под себя. Открываем \/etc\/ejabberd\/ejabberd.yml<\/i> и правим, как минимум, строчку hosts<\/i> в начале файла. И учтите еще пару моментов.<\/p>\n\n- Если вы планируете дать возможность анонимным пользователям подключаться к вашему серверу в качестве клиентов, то лучше сразу настройте подраздел host_config<\/i> в разделе AUTHENTICATION<\/i>. Я лично потерял весь ростер, когда настроил его уже в процессе работы. Хрен знает почему так получилось, но повторов мне не хочется.<\/li>\n
- Также лучше всего сразу настроить ejabberd на использованием базы MySQL и не использовать встроенную Mnesia. Связано это с ограничением Mnesia на размер БД. Если планируется использовать запись действий.<\/li>\n<\/ol>\n
После всего этого можно пробовать запускать службу:<\/p>\n
# systemctl start ejabberd<\/code><\/pre>Итак, служба запустилась, сервер нас слушает.
\nКакие еще есть нюансы? Ну, например, использование сертификатов от Let’sEncrypt. Я перебрал множество вариантов их подключения, но сервер каждый раз продолжал ругаться или на их отсутствие, или на то, что они подписаны неизвестным CA, или что не может выстроить цепочку сертификатов, чтобы доверять им. Перед настройкой нам нужно провести небольшие подготовительные работы. А именно — экспортировать корневой сертификат DST Root CA X3 в pem-файл. После этого размещаем его, например, в папке сертификатов Let’sEncrypt \/etc\/letsencrypt<\/i> и даем права на чтение всем. Подкаталогам live<\/i> и archive<\/i> даем права 0755. Самим сертификатам даем права 0644. Вроде бы ничего не забыл. Теперь приступаем к настройке ejabberd.
\nВ разделе Certificates<\/i> прописываем следующие параметры:<\/p>\nca_file: "\/etc\/letsencrypt\/DSTRootCAX3.pem"\ncertfiles:\n - "\/etc\/letsencrypt\/live\/kini24.ru\/*.pem"<\/code><\/pre>Первый указывает на корневой сертификат, второй — на папку с сертификатами на наш домен. Перезапускаем службу ejabberd и проверяем логи на ошибки. Если все нормально, то никаких сообщений по поводу сертификатов вы не увидите, кроме такой:<\/p>\n
[error] <0.306.0>@ejabberd_pkix:validate:543 Failed to list directory \/etc\/ssl\/certs: no such file or directory<\/code><\/pre>