|
В проекте используется VM:
IP VM:
Установка системных пакетов[править]
sudo apt update
sudo apt install -y git curl wget build-essential postgresql coturn nginx
Для сборки Dendrite также требуется Go.
Установка PostgreSQL[править]
Создаётся пользователь и база данных:
sudo -u postgres createuser dendrite
sudo -u postgres createdb -O dendrite dendrite
sudo -u postgres psql
Внутри psql задаётся пароль:
ALTER USER dendrite WITH PASSWORD 'strong_password';
Сборка Dendrite[править]
cd /opt
sudo git clone https://github.com/matrix-org/dendrite.git
sudo chown -R $USER:$USER /opt/dendrite
cd /opt/dendrite
go build -o bin/dendrite ./cmd/dendrite
go build -o bin/create-account ./cmd/create-account
go build -o bin/generate-config ./cmd/generate-config
go build -o bin/generate-keys ./cmd/generate-keys
Генерация конфигурации Dendrite[править]
cd /opt/dendrite
./bin/generate-keys --private-key matrix_key.pem
./bin/generate-config
--server ramba-art.ru
--db postgresql://dendrite:password@localhost/dendrite?sslmode=disable
--private-key matrix_key.pem \
> dendrite.yaml
>
>
После генерации конфиг редактируется вручную.
Важные параметры:
global:
server_name: ramba-art.ru
media_api:
base_path: media
max_file_size_bytes: 10485760
Systemd-сервис Dendrite[править]
Создаётся файл:
sudo nano /etc/systemd/system/dendrite.service
Пример:
[Unit]
Description=Dendrite Matrix Server
After=network.target postgresql.service
[Service]
Type=simple
WorkingDirectory=/opt/dendrite
ExecStart=/opt/dendrite/dendrite -config /opt/dendrite/dendrite.yaml
Restart=always
RestartSec=5
User=artem
Group=artem
[Install]
WantedBy=multi-user.target
Запуск:
sudo systemctl daemon-reload
sudo systemctl enable --now dendrite
sudo systemctl status dendrite
Настройка Reverse Proxy для Dendrite[править]
На стороне BrainyCP/Nginx создаётся HTTPS-сайт:
Он проксирует запросы на:
Важные заголовки:
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
Настройка .well-known[править]
Для красивых Matrix ID вида:
нужно настроить .well-known на основном домене.
Файл:
https://ramba-art.ru/.well-known/matrix/server
Содержимое:
{
"m.server": "chat.ramba-art.ru:443"
}
Файл:
https://ramba-art.ru/.well-known/matrix/client
Содержимое:
{
"m.homeserver": {
"base_url": "https://chat.ramba-art.ru"
}
}
Установка Element Web[править]
Element Web размещается на отдельном поддомене:
Пример config.json:
{
"default_server_config": {
"m.homeserver": {
"base_url": "https://chat.ramba-art.ru",
"server_name": "ramba-art.ru"
}
},
"disable_custom_urls": true,
"disable_guests": true,
"brand": "RAMBA Chat",
"default_theme": "dark"
}
Плюсы отдельного поддомена для Element:
- проще обслуживать веб-клиент;
- можно независимо обновлять Element;
- можно брендировать интерфейс;
- пользователю не нужно вручную вводить homeserver.
Минусы:
- нужен отдельный SSL-сертификат;
- при проблемах с репутацией домена браузер может блокировать страницу.
Настройка Coturn[править]
Установка:
sudo apt install -y coturn
Включение сервиса:
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
Пример конфигурации:
listening-port=3478
tls-listening-port=5349
listening-ip=192.168.1.50
relay-ip=192.168.1.50
external-ip=195.138.232.82
use-auth-secret
static-auth-secret=SECRET
realm=ramba-art.ru
fingerprint
lt-cred-mech
no-multicast-peers
no-cli
min-port=49152
max-port=49252
Запуск:
sudo systemctl enable --now coturn
sudo systemctl status coturn
Настройка TURN в Dendrite[править]
В dendrite.yaml указывается TURN-сервер:
client_api:
turn:
turn_user_lifetime: "5m"
turn_uris:
- "turn:turn.ramba-art.ru:3478?transport=udp"
- "turn:turn.ramba-art.ru:3478?transport=tcp"
- "turns:turn.ramba-art.ru:5349?transport=tcp"
turn_shared_secret: "SECRET"
Секрет в Dendrite должен совпадать со значением static-auth-secret в Coturn.
Проверка:
curl -s https://chat.ramba-art.ru/_matrix/client/v3/voip/turnServer
Если всё настроено правильно, сервер отдаёт временные TURN-креды.
Проброс портов[править]
На внешнем маршрутизаторе или firewall нужно пробросить на VM ramba-chat:
| Порт
|
Протокол
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Регистрация пользователей[править]
Для корпоративного сервера не рекомендуется открывать публичную регистрацию.
Рекомендуемая схема:
- регистрация закрыта;
- пользователей создаёт администратор;
- после первого входа пользователь меняет временный пароль.
Создание пользователя:
cd /opt/dendrite
./create-account
--config dendrite.yaml
--username username
--password 'temporary_password'
Пример результата:
Плюсы закрытой регистрации:
- нет спама;
- нет случайных пользователей;
- проще управлять безопасностью;
- подходит для корпоративного мессенджера.
Минусы:
- пользователей нужно создавать вручную или через скрипт;
- нужен регламент выдачи доступов;
- нужно продумать удаление или блокировку уволенных сотрудников.
В Dendrite медиа хранятся в каталоге:
В конфигурации:
media_api:
base_path: media
max_file_size_bytes: 10485760
Лимит одного файла:
Если комната зашифрована, Element шифрует вложения на клиенте перед загрузкой. Сервер хранит зашифрованный blob и не имеет ключей расшифровки.
Если комната не зашифрована, сервер хранит обычные медиафайлы.
Рекомендации:
- рабочие комнаты создавать с E2EE;
- каталог media включить в резервное копирование;
- при росте объёма вынести media на отдельное хранилище;
- PostgreSQL не выносить на NFS.
Вариант выноса медиа на NFS/OMV[править]
Для роста системы можно вынести только медиафайлы на OMV NFS.
Рекомендуемая схема:
VM ramba-chat
|-- PostgreSQL локально
|-- Dendrite локально
|-- JetStream локально
|-- /opt/dendrite/media -> NFS OMV
Плюсы:
- медиа не раздувают диск VM;
- проще расширять хранилище;
- удобно делать отдельные бэкапы;
- можно использовать шифрование дисков на OMV.
Минусы:
- появляется зависимость от сети и OMV;
- при недоступности NFS будут проблемы с загрузкой и скачиванием файлов;
- нужна аккуратная настройка прав доступа;
- база данных и JetStream должны оставаться локально.
Резервное копирование[править]
Обязательно резервировать:
PostgreSQL database dendrite
/opt/dendrite
/opt/dendrite/media
/etc/turnserver.conf
/etc/systemd/system/dendrite.service
Element config.json
Nginx/BrainyCP vhost-конфиги
Пример резервного копирования конфигов:
sudo tar czf /root/ramba-matrix-configs-$(date +%F).tar.gz \
/opt/dendrite \
/etc/turnserver.conf \
/etc/systemd/system/dendrite.service
Пример дампа PostgreSQL:
sudo -u postgres pg_dump dendrite > /root/dendrite-$(date +%F).sql
Проверка работоспособности[править]
Проверка .well-known:
curl -s https://ramba-art.ru/.well-known/matrix/server
curl -s https://ramba-art.ru/.well-known/matrix/client
Проверка Matrix API:
curl -s https://chat.ramba-art.ru/_matrix/client/versions
Проверка Dendrite:
sudo systemctl status dendrite --no-pager
sudo journalctl -u dendrite -n 80 --no-pager
Проверка Coturn:
sudo systemctl status coturn --no-pager
sudo ss -tulpn | grep turnserver
Проверка TURN-кредов:
curl -s https://chat.ramba-art.ru/_matrix/client/v3/voip/turnServer
Тестирование звонков[править]
Финальный тест:
- создать двух пользователей;
- войти в Element с двух разных устройств;
- желательно использовать мобильную сеть, а не один Wi-Fi;
- проверить личный чат;
- проверить аудиозвонок;
- проверить видеозвонок.
Успешный звонок через мобильного оператора подтверждает, что работают:
- Dendrite;
- Element;
- WebRTC;
- STUN;
- TURN;
- NAT traversal;
- reverse proxy;
- SSL.
Плюсы выбранной архитектуры[править]
- полный контроль над данными;
- собственные Matrix ID на домене ramba-art.ru;
- независимость от сторонних SaaS-мессенджеров;
- поддержка Android, iOS и Web;
- поддержка аудио- и видеосвязи;
- поддержка E2EE;
- простая архитектура на одной VM;
- PostgreSQL локально для надёжности;
- медиа можно вынести на отдельное хранилище;
- reverse proxy и SSL централизованы через BrainyCP.
Минусы выбранной архитектуры[править]
- требуется администрирование сервера;
- нужно следить за Dendrite, PostgreSQL, Coturn и Element;
- требуется регулярный backup;
- требуется ручное создание пользователей или отдельный скрипт;
- Dendrite менее зрелый, чем Synapse;
- звонки зависят от правильной настройки TURN;
- при проблемах с доменной репутацией браузер может блокировать Element;
- при росте нагрузки может потребоваться отдельное масштабирование.
Рекомендации по эксплуатации[править]
- держать регистрацию закрытой;
- создавать пользователей централизованно;
- использовать E2EE для рабочих комнат;
- регулярно проверять резервные копии;
- не хранить PostgreSQL на NFS;
- следить за размером /opt/dendrite/media;
- обновлять Element Web отдельно от Dendrite;
- фиксировать изменения конфигов в отдельной Wiki-странице;
- после стабильного запуска создать snapshot VM в Proxmox.
Выбранная архитектура подходит для собственного корпоративного мессенджера RAMBA.
Она даёт контроль над пользователями, сообщениями, медиафайлами и доменом, при этом остаётся достаточно простой для сопровождения: одна VM, один Matrix homeserver, PostgreSQL, Coturn и Element Web.
Для текущего этапа архитектура считается рабочей. Дальнейшие улучшения:
- автоматизация создания пользователей;
- настройка регулярного backup;
- вынос media store на OMV/NFS;
- брендирование Element;
- мониторинг сервисов;
- исправление репутации домена в Google Safe Browsing.
|
|