Свой сервер: подробное руководство по установке Prosody: различия между версиями

Материал из Мир Jabber
Перейти к навигацииПерейти к поиску
(Новая страница: «В этой статье приводится пример настройки Prosody с поддержкой актуальных и популярных функций. В качестве основы взята конфигурация для сервера версии 0.12.4, а в качестве сертификатов используется Let's Encrypt - и все это установлено на Debian GNU/Linux. Рассмотрим ос...»)
 
(Продолжаем)
Строка 1: Строка 1:
В этой статье приводится пример настройки Prosody с поддержкой актуальных и популярных функций. В качестве основы взята конфигурация для сервера версии 0.12.4, а в качестве сертификатов используется Let's Encrypt - и все это установлено на Debian GNU/Linux.
В этой статье приводится пример настройки [[Prosody]] - одного из самых популярных и легковесных jabber-серверов. Для сервера написано просто-таки огромное число модулей на все случаи жизни, поэтому в руководстве, основанном на версии 0.12.4, будет показано подключение актуальных и популярных функций. В качестве сертификатов будем использовать Let's Encrypt - и все это на Debian GNU/Linux.


Рассмотрим особенности данной конфигурации.
Рассмотрим особенности данной конфигурации.
Строка 12: Строка 12:


# Для удобства, чтобы в случае миграции сервера с одного IP на другой не приходилось переписывать все записи, стоит завести для него субдомен, который будет ссылаться на нужный IP с помощью А-записи (или 2 таких субдомена в случае использования IPv4+IPv6 - один с A-записью, а второй с AAAA), а все остальные записи сделать CNAME-алиасами для него. Например, для данного сервера ('''jabberworld.info''') сделаны 2 субдомена '''xmpp.jabberworld.info''', ссылающиеся на IPv4 и IPv6-адреса.
# Для удобства, чтобы в случае миграции сервера с одного IP на другой не приходилось переписывать все записи, стоит завести для него субдомен, который будет ссылаться на нужный IP с помощью А-записи (или 2 таких субдомена в случае использования IPv4+IPv6 - один с A-записью, а второй с AAAA), а все остальные записи сделать CNAME-алиасами для него. Например, для данного сервера ('''jabberworld.info''') сделаны 2 субдомена '''xmpp.jabberworld.info''', ссылающиеся на IPv4 и IPv6-адреса.
# Создаем субдомены для необходимых сервисов сервера - '''conference''' (для [[Конференции|конференций]]), '''proxy''' (прокси для прямой [[Передача файлов|передачи файлов]]), '''pubsub''' (сервисы типа "Публикация/подписка", где может сохраняться самая разная информация) и '''upload''' (сервис для [[Передача файлов|передачи файлов]] через HTTP Upload). Все эти записи создаем как CNAME на наш субдомен из 1-го пункта.
# Создаем субдомены для необходимых сервисов сервера<ref>Да, если планируется использовать, например, конференции исключительно локально, то можно обойтись и без DNS-записей - сервер и так знает, куда ему подключаться, так как он этот сервис и предоставляет. Но если хочется полноценный сервис, с которым смогут взаимодействовать и другие сервера - то все же потребуются указанные записи в DNS.</ref> - '''conference''' (для [[Конференции|конференций]]), '''proxy''' (прокси для прямой [[Передача файлов|передачи файлов]]), '''pubsub''' (сервисы типа "Публикация/подписка", где может сохраняться самая разная информация) и '''upload''' (сервис для [[Передача файлов|передачи файлов]] через HTTP Upload). Все эти записи создаем как CNAME на наш субдомен из 1-го пункта.
# Создаем ряд SRV-записей для нашего основного домена - они показывают, где именно какой сервис находится. Конечно, если у вас все на одном адресе, то будет работать и так, но мы ведь решили все делать правильно, верно? Итак, нужны такие SRV-записи:
# Создаем ряд SRV-записей для нашего основного домена - они показывают, где именно какой сервис находится. Конечно, если у вас все на одном адресе, то будет работать и так, но мы ведь решили все делать правильно, верно? Итак, нужны такие SRV-записи:


Строка 45: Строка 45:


== Сертификаты ==
== Сертификаты ==


В современном мире стандартной практикой является шифрование соединений, а для этого, в свою очередь, требуются [[ru_wikipedia:Цифровой сертификат|сертификаты]] от доверенных центров сертификации. Можно, конечно, использовать самоподписанный сертификат, но, во-первых, не все серверы будут их принимать - а значит, к ним не получится подключиться и общаться с их пользователями, а во-вторых, в подключающихся клиентах будут появляться сообщения о недоверенном сертификате, что тоже будет доставлять определенные неудобства. Поэтому стоит воспользоваться услугами одного из популярных бесплатных центров сертификации - [https://letsencrypt.org Let's Encrypt].
В современном мире стандартной практикой является шифрование соединений, а для этого, в свою очередь, требуются [[ru_wikipedia:Цифровой сертификат|сертификаты]] от доверенных центров сертификации. Можно, конечно, использовать самоподписанный сертификат, но, во-первых, не все серверы будут их принимать - а значит, к ним не получится подключиться и общаться с их пользователями, а во-вторых, в подключающихся клиентах будут появляться сообщения о недоверенном сертификате, что тоже будет доставлять определенные неудобства. Поэтому стоит воспользоваться услугами одного из популярных бесплатных центров сертификации - [https://letsencrypt.org Let's Encrypt].
Строка 91: Строка 92:
В каталогах сервера не обязательно должен быть какой-то контент, хотя, например, на основном домене можно разместить какую-то страничку, посвященную jabber-серверу, а на поддомене '''conference''' разместить чат-логи [[Конференции|конференций]]. Субдомен '''upload''' можно приспособить под загружаемые через HTTP Upload файлы, чтобы в дальнейшем их раздавал веб-сервер<ref name="http_upload">В таком случае ему нужно обеспечить доступ к каталогу '''/var/lib/prosody/http_upload/''' - а лучше указать опцию '''http_upload_path''' с путем за пределами домашнего каталога Prosody, плюс обеспечить нужные права веб-серверу, чтобы он мог читать файлы, загруженные через jabber-сервер. Такое решение имеет еще одно преимущество: разнообразные клиенты (не только Jabber) будут гораздо охотнее показывать превью для обычных HTTP/HTTPS-ссылок (т.е., на 80 или 443-м порту), а не тех, где контент отдается на "необычном" порту - вроде 5281 в данном примере.</ref>.
В каталогах сервера не обязательно должен быть какой-то контент, хотя, например, на основном домене можно разместить какую-то страничку, посвященную jabber-серверу, а на поддомене '''conference''' разместить чат-логи [[Конференции|конференций]]. Субдомен '''upload''' можно приспособить под загружаемые через HTTP Upload файлы, чтобы в дальнейшем их раздавал веб-сервер<ref name="http_upload">В таком случае ему нужно обеспечить доступ к каталогу '''/var/lib/prosody/http_upload/''' - а лучше указать опцию '''http_upload_path''' с путем за пределами домашнего каталога Prosody, плюс обеспечить нужные права веб-серверу, чтобы он мог читать файлы, загруженные через jabber-сервер. Такое решение имеет еще одно преимущество: разнообразные клиенты (не только Jabber) будут гораздо охотнее показывать превью для обычных HTTP/HTTPS-ссылок (т.е., на 80 или 443-м порту), а не тех, где контент отдается на "необычном" порту - вроде 5281 в данном примере.</ref>.


После всех приготовлений создайте все необходимые сертификаты. Для этого воспользуйтесь следующими командами (выполнять надо от пользователя '''root'''):
После всех приготовлений<ref>Более подробно можно почитать тут: [[Свой сервер: подготовка веб-сервера и сертификатов]]</ref> создайте все необходимые сертификаты. Для этого воспользуйтесь следующими командами (выполнять надо от пользователя '''root'''):


  certbot certonly --webroot --webroot-path /var/www/EXAMPLE.COM/htdocs/ -d EXAMPLE.COM
  certbot certonly --webroot --webroot-path /var/www/EXAMPLE.COM/htdocs/ -d EXAMPLE.COM --rsa-key-size 4096
  certbot certonly --webroot --webroot-path /var/www/conference.EXAMPLE.COM/htdocs/ -d conference.EXAMPLE.COM
  certbot certonly --webroot --webroot-path /var/www/conference.EXAMPLE.COM/htdocs/ -d conference.EXAMPLE.COM --rsa-key-size 4096
  certbot certonly --webroot --webroot-path /var/www/upload.EXAMPLE.COM/htdocs/ -d upload.EXAMPLE.COM
  certbot certonly --webroot --webroot-path /var/www/upload.EXAMPLE.COM/htdocs/ -d upload.EXAMPLE.COM --rsa-key-size 4096
  certbot certonly --webroot --webroot-path /var/www/pubsub.EXAMPLE.COM/htdocs/ -d pubsub.EXAMPLE.COM
  certbot certonly --webroot --webroot-path /var/www/pubsub.EXAMPLE.COM/htdocs/ -d pubsub.EXAMPLE.COM --rsa-key-size 4096
  certbot certonly --webroot --webroot-path /var/www/proxy.EXAMPLE.COM/htdocs/ -d proxy.EXAMPLE.COM
  certbot certonly --webroot --webroot-path /var/www/proxy.EXAMPLE.COM/htdocs/ -d proxy.EXAMPLE.COM --rsa-key-size 4096


В параметрах после '''--webroot-path''' указывается каталог веб-сервера для данного домена, а после '''-d''' - сам домен.
В параметрах после '''--webroot-path''' указывается каталог веб-сервера для данного домена, а после '''-d''' - сам домен.

Версия 12:07, 1 ноября 2023

В этой статье приводится пример настройки Prosody - одного из самых популярных и легковесных jabber-серверов. Для сервера написано просто-таки огромное число модулей на все случаи жизни, поэтому в руководстве, основанном на версии 0.12.4, будет показано подключение актуальных и популярных функций. В качестве сертификатов будем использовать Let's Encrypt - и все это на Debian GNU/Linux.

Рассмотрим особенности данной конфигурации.

DNS-записи

Хотя для базового варианта своего jabber-сервера вполне достаточно бесплатного DynDNS-домена, для полноценной конфигурации все же нужно обзавестись собственным доменом, где можно будет добавить все необходимые DNS-записи и сделать субдомены для сервисов. Выбор регистратора и покупка домена остается за рамками данной статьи, тут только приводятся шаги, которые надо сделать после покупки домена в его админке.

Всего понадобится около 15 записей в DNS:

  1. Для удобства, чтобы в случае миграции сервера с одного IP на другой не приходилось переписывать все записи, стоит завести для него субдомен, который будет ссылаться на нужный IP с помощью А-записи (или 2 таких субдомена в случае использования IPv4+IPv6 - один с A-записью, а второй с AAAA), а все остальные записи сделать CNAME-алиасами для него. Например, для данного сервера (jabberworld.info) сделаны 2 субдомена xmpp.jabberworld.info, ссылающиеся на IPv4 и IPv6-адреса.
  2. Создаем субдомены для необходимых сервисов сервера[1] - conference (для конференций), proxy (прокси для прямой передачи файлов), pubsub (сервисы типа "Публикация/подписка", где может сохраняться самая разная информация) и upload (сервис для передачи файлов через HTTP Upload). Все эти записи создаем как CNAME на наш субдомен из 1-го пункта.
  3. Создаем ряд SRV-записей для нашего основного домена - они показывают, где именно какой сервис находится. Конечно, если у вас все на одном адресе, то будет работать и так, но мы ведь решили все делать правильно, верно? Итак, нужны такие SRV-записи:
_xmpp-client._tcp.EXAMPLE.COM (порт 5222) - чтобы указать, куда подключаться jabber-клиенту
_xmpps-client._tcp.EXAMPLE.COM (порт 5223) - аналогичная запись для TLS-подключений клиентов
_xmpp-server._tcp.EXAMPLE.COM (порт 5269) - чтобы указать, куда подключаться jabber-серверу
_xmpps-server._tcp.EXAMPLE.COM (порт 5270) - аналогичная запись для TLS-подключений серверов.
Записи ниже служат для работы сервиса аудио/видеозвонков через jabber[2]. Для максимальной совместимости будем использовать как STUN, так и TURN - все возможные варианты:
_stun._tcp.EXAMPLE.COM (порт 3478) - STUN через TCP
_stun._udp.EXAMPLE.COM (порт 3478) - STUN через UDP
_stuns._tcp.EXAMPLE.COM (порт 5349) - шифрованный STUN через TCP
_turn._tcp.EXAMPLE.COM (порт 3478) - TURN через TCP
_turn._udp.EXAMPLE.COM (порт 3478) - TURN через UDP
_turns._tcp.EXAMPLE.COM (порт 5349) - шифрованный TURN через TCP
Во всех случаях target'ом для записей служит наш алиас из первого пункта.
Для продвинутых
Самый полный вариант подразумевает в том числе создание SRV-записей для каждого из сервисов-субдоменов - тех, к которым будут подключаться сторонние серверы. Например, для конференций это может выглядеть так:
_xmpp-server._tcp.conference.EXAMPLE.COM (порт 5269)
_xmpps-server._tcp.conference.EXAMPLE.COM (порт 5270 для TLS)
Но, как уже говорилось выше, это для совсем уж необычных конфигураций - когда сам домен указывает на один адрес (например, там может работать веб-сервер, предоставляющий чат-логи на сайте https://conference.example.com), а сам jabber-сервер при этом находится совершенно на другом.

Вот как выглядят записи для данного сервера в админке бесплатного DNS-провайдера Hurricane Electric:

Jabber srv.png

Сертификаты

В современном мире стандартной практикой является шифрование соединений, а для этого, в свою очередь, требуются сертификаты от доверенных центров сертификации. Можно, конечно, использовать самоподписанный сертификат, но, во-первых, не все серверы будут их принимать - а значит, к ним не получится подключиться и общаться с их пользователями, а во-вторых, в подключающихся клиентах будут появляться сообщения о недоверенном сертификате, что тоже будет доставлять определенные неудобства. Поэтому стоит воспользоваться услугами одного из популярных бесплатных центров сертификации - Let's Encrypt.

Для работы с сертификатами от Let's Encrypt в Debian есть специальный пакет - certbot, поэтому установите его следующей командой:

sudo apt-get install certbot

Сертификаты от Let's Encrypt выдаются сроком на 3 месяца, поэтому в конце этого срока их нужно обновлять. Для подтверждения владения доменом, а также для автоматизации обновления сертификатов в дальнейшем со стороны Let's Encrypt делается запрос на веб-сервер для указанного домена, поэтому для полноценной работы стоит установить какой-нибудь популярный вариант и прописать там виртуальные хосты для нашего jabber-сервера, а также сервисов на нем (сертификаты будут делаться в том числе для сервисов). Пример конфигурации веб-сервера Apache для данного сервера:

apache_to_jabber_service_domains.conf
<VirtualHost 185.161.208.229:80 [2a07:c801:0:5::]:80>
        ServerAdmin     webmaster@jabberworld.info
        DocumentRoot    /var/www/jabberworld.info/htdocs
        ServerName      jabberworld.info
</VirtualHost>

<VirtualHost 185.161.208.229:80 [2a07:c801:0:5::]:80>
        ServerAdmin     webmaster@upload.jabberworld.info
        DocumentRoot    /var/www/upload.jabberworld.info/htdocs
        ServerName      upload.jabberworld.info
</VirtualHost>

<VirtualHost 185.161.208.229:80 [2a07:c801:0:5::]:80>
        ServerAdmin     webmaster@pubsub.jabberworld.info
        DocumentRoot    /var/www/pubsub.jabberworld.info/htdocs
        ServerName      pubsub.jabberworld.info
</VirtualHost>

<VirtualHost 185.161.208.229:80 [2a07:c801:0:5::]:80>
        ServerAdmin     webmaster@conference.jabberworld.info
        DocumentRoot    /var/www/conference.jabberworld.info/htdocs
        ServerName      conference.jabberworld.info
</VirtualHost>

<VirtualHost 185.161.208.229:80 [2a07:c801:0:5::]:80>
        ServerAdmin     webmaster@proxy.jabberworld.info
        DocumentRoot    /var/www/proxy.jabberworld.info/htdocs
        ServerName      proxy.jabberworld.info
</VirtualHost>

В каталогах сервера не обязательно должен быть какой-то контент, хотя, например, на основном домене можно разместить какую-то страничку, посвященную jabber-серверу, а на поддомене conference разместить чат-логи конференций. Субдомен upload можно приспособить под загружаемые через HTTP Upload файлы, чтобы в дальнейшем их раздавал веб-сервер[3].

После всех приготовлений[4] создайте все необходимые сертификаты. Для этого воспользуйтесь следующими командами (выполнять надо от пользователя root):

certbot certonly --webroot --webroot-path /var/www/EXAMPLE.COM/htdocs/ -d EXAMPLE.COM --rsa-key-size 4096
certbot certonly --webroot --webroot-path /var/www/conference.EXAMPLE.COM/htdocs/ -d conference.EXAMPLE.COM --rsa-key-size 4096
certbot certonly --webroot --webroot-path /var/www/upload.EXAMPLE.COM/htdocs/ -d upload.EXAMPLE.COM --rsa-key-size 4096
certbot certonly --webroot --webroot-path /var/www/pubsub.EXAMPLE.COM/htdocs/ -d pubsub.EXAMPLE.COM --rsa-key-size 4096
certbot certonly --webroot --webroot-path /var/www/proxy.EXAMPLE.COM/htdocs/ -d proxy.EXAMPLE.COM --rsa-key-size 4096

В параметрах после --webroot-path указывается каталог веб-сервера для данного домена, а после -d - сам домен.

После успешного выполнения команд будет выдана информация о созданном сертификате, в том числе 2 файла - цепочка ключей и приватный ключ - сохраните эти пути для дальнейшего использования, они нам еще пригодятся. Всего получится 10 файлов. certbot обновляет сертификаты автоматически, если срок их истечения составляет менее 30 дней - т.е., обновление происходит раз в 2 месяца.

Так как Prosody работает от своего пользователя и не имеет доступа к сертификатам, созданным certbot от рута, то надо каким-то образом предоставить доступ ejabberd'у к сертификатам. Самым простым и корректным вариантом на сейчас является выполнение следующей команды от рута[5]:

prosodyctl --root cert import /etc/letsencrypt/live

В дальнейшем эту команду можно использовать после каждого обновления сертификатов - например, указав ее в качестве deploy hook для certbot.

Установка и настройка Prosody

ToDo: Доделать

Сноски

  1. Да, если планируется использовать, например, конференции исключительно локально, то можно обойтись и без DNS-записей - сервер и так знает, куда ему подключаться, так как он этот сервис и предоставляет. Но если хочется полноценный сервис, с которым смогут взаимодействовать и другие сервера - то все же потребуются указанные записи в DNS.
  2. https://prosody.im/doc/turn
  3. В таком случае ему нужно обеспечить доступ к каталогу /var/lib/prosody/http_upload/ - а лучше указать опцию http_upload_path с путем за пределами домашнего каталога Prosody, плюс обеспечить нужные права веб-серверу, чтобы он мог читать файлы, загруженные через jabber-сервер. Такое решение имеет еще одно преимущество: разнообразные клиенты (не только Jabber) будут гораздо охотнее показывать превью для обычных HTTP/HTTPS-ссылок (т.е., на 80 или 443-м порту), а не тех, где контент отдается на "необычном" порту - вроде 5281 в данном примере.
  4. Более подробно можно почитать тут: Свой сервер: подготовка веб-сервера и сертификатов
  5. https://prosody.im/doc/letsencrypt

Ссылки