2 заметки с тегом

let’s encrypt

Установка ejabberd на ALT Linux

Заметка, по большей части, для себя.

Решил поделиться своим опытом установки и настройки ejabberd. В процессе встречал много ошибок, которые можно было бы избежать, будь у меня опыт по работе с этим сервером. Но опыт что называется «нулевой».
Первым делом, конечно, установка:

# apt-get install ejabberd

Несмотря на то, что после установки появляется одноименная служба, воспользоваться ей мы пока не сможем. Угум-с... Поэтому начинаем с того, что создаем базу данных в MySQL и пользователя. SQL-скрипт находится по пути /usr/lib/erlang/lib/ejabberd-18.03/priv/sql/mysql.sql.
Теперь регистрируем пользователя:

# ejabberdctl start
WARNING: It is not recommended to run ejabberd as root
# ejabberdctl register admin example.com PaSsWoRd
# ejabberdctl stop

Ответы сервера будут немного отличаться, но основной вопрос возникает при виде строки «WARNING: It is not recommended to run ejabberd as root». Чтобы избавиться от этого предупреждения, нужно запускать ejabberd от имени другого пользователя. Это делает сервис, но он нам пока недоступен. Почти.
После запуска ejabberdctl в папке /var/lib/ejabberd создаются нужные подкаталоги и файлы баз Mnesia. Вот только права у них сейчас root, поэтому сервер не сможет с ними работать. Меняем владельца:

# chown -R ejabberd:ejabberd /var/lib/ejabberd

Не забываем про логи — там то же самое:

# chown -R ejabberd:ejabberd /var/log/ejabberd

Теперь нужно изменить файл конфигурации сервера под себя. Открываем /etc/ejabberd/ejabberd.yml и правим, как минимум, строчку hosts в начале файла. И учтите еще пару моментов.

  1. Если вы планируете дать возможность анонимным пользователям подключаться к вашему серверу в качестве клиентов, то лучше сразу настройте подраздел host_config в разделе AUTHENTICATION. Я лично потерял весь ростер, когда настроил его уже в процессе работы. Хрен знает почему так получилось, но повторов мне не хочется.
  2. Также лучше всего сразу настроить ejabberd на использованием базы MySQL и не использовать встроенную Mnesia. Связано это с ограничением Mnesia на размер БД. Если планируется использовать запись действий.

После всего этого можно пробовать запускать службу:

# systemctl start ejabberd

Итак, служба запустилась, сервер нас слушает.
Какие еще есть нюансы? Ну, например, использование сертификатов от Let’sEncrypt. Я перебрал множество вариантов их подключения, но сервер каждый раз продолжал ругаться или на их отсутствие, или на то, что они подписаны неизвестным CA, или что не может выстроить цепочку сертификатов, чтобы доверять им. Перед настройкой нам нужно провести небольшие подготовительные работы. А именно — экспортировать корневой сертификат DST Root CA X3 в pem-файл. После этого размещаем его, например, в папке сертификатов Let’sEncrypt /etc/letsencrypt и даем права на чтение всем. Подкаталогам live и archive даем права 0755. Самим сертификатам даем права 0644. Вроде бы ничего не забыл. Теперь приступаем к настройке ejabberd.
В разделе Certificates прописываем следующие параметры:

ca_file: "/etc/letsencrypt/DSTRootCAX3.pem"
certfiles:
  - "/etc/letsencrypt/live/kini24.ru/*.pem"

Первый указывает на корневой сертификат, второй — на папку с сертификатами на наш домен. Перезапускаем службу ejabberd и проверяем логи на ошибки. Если все нормально, то никаких сообщений по поводу сертификатов вы не увидите, кроме такой:

[error] <0.306.0>@ejabberd_pkix:validate:543 Failed to list directory /etc/ssl/certs: no such file or directory

Согласен с ejabberd, нет у меня такой папки. Ну и черт с ней! :-)
Все остальные параметры настраиваются достаточно просто, почитать можно здесь: https://docs.ejabberd.im/admin/configuration/. Вот тут всплыл другой нюанс, решение которого я искал достаточно долго. Дело в том, что в файле все регулируется отступами. Примерно так:

listen:
  -
    port: 5222
    ip: "::"
    module: ejabberd_c2s
    starttls: true
    starttls_required: true
    zlib: true

У первой строки отступа нет вообще, потому что она «главная». У второй (тире) в начале два пробела. У следующего параметра, port, уже 4 пробела. Иными словами, каждый параметр отделяется от своего «родителя» двумя пробелами.

Wildcard сертификаты от Let’s Encrypt

За всеми событиями в жизни как-то пропустил момент, когда Let’s Encrypt стали выдавать бесплатные «wildcard» сертификаты. Иными словами, вы можете получить один сертификат на свой основной домен и все его субдомены разом. Больше не нужно беспокоиться о том, что каждый раз при создании субдомена придется создавать и новый сертификат. Нужно будет просто в конфигурационном файле указать текущий.
В отличие от «стандартного» для генерирования сертификата «wildcard» нужно вручную прописать сервер для запросов. Команда будет выглядеть примерно так:

# certbot certonly --server https://acme-v02.api.letsencrypt.org/directory -d kini24.ru -d *.kini24.ru --agree-tos -m admin@kini24.ru --manual --preferred-challenges dns --must-staple --hsts --uir --staple-ocsp

Пройдемся по параметрам, чтобы было понятней:
—server — указывает на сервер, который мы хотим использовать для создания сертификата;
-d — указываем для каких доменов мы будем создавать сертификат. Советую вам первым указывать основной домен, а не его субдомены. Сэкономите немного времени;
—agree-tos — принимаем условия лицензионного соглашения;
-m — указываем свой адрес электронной почты. Он будет использоваться как логин;
—manual — используем «ручной» режим работы. Думаю, что можно было и не указывать, но я хотел проконтролировать процесс;
—preferred-challenges — указываем предпочтительный способ проверки, что именно вы имеете доступ к администрированию домена (являетесь его владельцем);
Остальные параметры не обязательны, можно их не указывать.
После ввода команды вас спросят не хотите ли вы получать новости от Electronic Frontier Foundation (EFF), основателя сервиса Let’s Encrypt. Ради интереса согласился, отписаться можно в любой момент. Затем был вопрос о том хочу ли я использовать указанный email в качестве логина. Соглашаемся. А вот дальше был один нюанс, который я поначалу не понял, но, в итоге, разобрался. Следующим шагом вас просят внести TXT-запись в ресурсные записи домена. Вносим и ждем, процесс занимает некоторое время. Обычно хватает 15 минут. Нажимаем Enter, чтобы скрипт проверил наличие записи. И вот тут он выдает точно такой же запрос на внесение записи TXT, но с другим значением. Это значение нужно также внести в ресурсные записи. Если быть точней, то первую запись нужно заменить на вторую. Этакая двойная проверка. Снова минуты ожидания и жмем Enter. Если проверка прошла, то сертификат будет создан.
Так как у меня также используется технология HPKP, то нужно еще и генерировать новые ключи для сертификата:

# openssl rsa -in /etc/letsencrypt/live/kini24.ru/privkey.pem -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64

Вносим изменения в конфигурационный файл веб-сервера и перезапускаем его:

# systemctl restart httpd2