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

Решил поделиться своим опытом установки и настройки 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 пробела. Иными словами, каждый параметр отделяется от своего «родителя» двумя пробелами.

Итак, попало ко мне в руки хорошее «железо», что стало неплохим поводом обновить свой сервер. Так как конфигурация слишком сильно отличалась от прежней, то систему тоже пришлось ставить заново. Поначалу не могу понять почему установка проходит нормально, а сама система после этого не грузится. Потом припомнил, что Linux с картами Intel HD Graphics так и не научился нормально работать. Что поделать, пришлось отключать в BIOS встроенную видеокарту и ставить внешнюю. Плохо то, что эта внешняя видеокарта предназначалась для установки в компьютер жены. Старое «железо» из сервера тоже должно было пойти на апгрейд ее компьютера.
Увы, но на работе тоже было много работы, поэтому апгрейд двух систем несколько затянулся. Затем пришлось устранять ошибки в работе веб-сервера, ибо я заодно захотел поменять некоторые настройки. Сейчас его работоспособность почти полностью восстановлена за исключением двух субдоменов: «зеркала» обновлений NOD32 и облака. Последнее из них меня волнует меньше всего, доступ к нужным файлам я могу получить и другими способами. А вот «зеркало»... На него слишком много завязано. Работа над ним пока что ведется. Написал разработчику, описал проблему, пока что жду от него ответа.
Также выяснилось, что dovecot не совсем корректно работает с wildcard-сертификатами. Если быть точней, то мне удалось настроить почти все нужные почтовые клиенты (веб-интерфейс, Outlook на телефоне), кроме Thunderbird, установленного на домашнем компьютере. При попытке просмотреть почту с его помощью dovecot ругается на сертификат. Проблема, как оказалось, не новая, но рабочего решения её пока не нашел.
Установил пока что другую видеокарту в компьютер жены, но она оказалась с «битой» памятью, что приводило к периодическим перезагрузкам. Интересно, сможет сервер работать без видеокарты вообще? Пока что пара моих попыток заставить его работать в таком режиме не увенчались успехом — все время «ругался» спикером. Подозреваю, что придется покупать новую, хоть какую-нибудь. Главное, чтобы присутствовала в системе.

За всеми событиями в жизни как-то пропустил момент, когда 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

Уже не в первый раз сталкиваюсь со странным поведение браузера от Mozilla. Сайт имеет ключи HPKP и указан HSTS, хэши для нового сертификата сгенерированы заново и указаны в файле конфигурации. То есть, по логике, все должно работать. Но увы... При этом все остальные браузеры нормально открывают сайт.
Точно также ведет себя и Thunderbird — просто отказывается подключаться к dovecot по тому же адресу, чтобы принять почту. В логах для обоих высвечивается одна и та же ошибка. Поиск в интернете выдает, что ошибка очень частая, но решений, кроме использования самоподписанных сертификатов, по видимому, нет. А мне лично этого не хотелось бы делать — зачем тогда в системе установлен робот, который следит за актуальностью сертификатов и, при необходимости, обновляет их.
В прошлый раз я обошелся тем, что использовал для этого конкретного сайта созданный ранее сертификат, но его срок действия заканчивается через несколько дней и использовать его дальше бессмысленно. В этот раз даже пока что в голову не приходит что делать. Надо пошевелить мозгами.