6379
правок
Свой сервер: подробное руководство по установке Prosody: различия между версиями
Материал из Мир Jabber
Перейти к навигацииПерейти к поиску
Свой сервер: подробное руководство по установке Prosody (править)
Версия 12:07, 1 ноября 2023
, 12:07, 1 ноября 2023Продолжаем
Rain (обсуждение | вклад) (Новая страница: «В этой статье приводится пример настройки Prosody с поддержкой актуальных и популярных функций. В качестве основы взята конфигурация для сервера версии 0.12.4, а в качестве сертификатов используется Let's Encrypt - и все это установлено на Debian GNU/Linux. Рассмотрим ос...») |
Rain (обсуждение | вклад) (Продолжаем) |
||
| Строка 1: | Строка 1: | ||
В этой статье приводится пример настройки Prosody | В этой статье приводится пример настройки [[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''' - сам домен. | ||
