Matrix-домашний сервер, у которого федерация реально работает

Что здесь создаётся

Домашний сервер на example.com, работающий на matrix.example.com, корректно общающийся со всеми остальными. Postgres в основе, nginx спереди, делегирование через два небольших JSON-файла, регистрация закрыта, чтобы ваш сервер не стал чьей-то бесплатной релейной точкой в течение недели.

Федерация — это то, где такие установки обычно дают сбой, и почти никогда из-за Synapse. Сервер работает, локальные сообщения доставляются, но снаружи ничего не приходит. На практике причина почти всегда в делегировании: идентичность сервера и адрес, по которому он живёт, — это разные вещи, а механизм, связывающий их, легко настроить недостаточно точно.

Перед началом

• R-4 достаточно для нескольких десятков пользователей. Synapse больше требователен к памяти, чем к CPU, и присоединение к большим федеративным комнатам — единственное, что заставит его напрячься.
• Два имени в DNS: example.com — идентичность вашего сервера, фигурирует в каждом пользовательском ID, и matrix.example.com — где программное обеспечение реально слушает.
• Сертификаты для обоих. Первому достаточно обслуживать два статических файла.

1. База данных с правильной сортировкой

apt update && apt install -y postgresql matrix-synapse nginx certbot
sudo -u postgres psql -c "CREATE USER synapse_user WITH PASSWORD '<a long password>';"
sudo -u postgres psql -c "CREATE DATABASE synapse ENCODING 'UTF8' LC_COLLATE='C' LC_CTYPE='C' TEMPLATE=template0 OWNER synapse_user;"

Сортировка — не деталь. Synapse отказывается запускаться на базе, созданной с любой сортировкой, кроме C, и ошибка, которую он выдаёт при неверной настройке, появляется уже после импорта данных. Сделайте это сейчас, правильно, один раз.

2. Конфигурация homeserver

Пакет Debian запрашивает имя сервера во время установки; отвечайте example.com, а не hostname машины. Этот ответ становится частью каждого пользовательского ID и ID комнаты на сервере и не может быть изменён после без отказа от сервера.

Затем отредактируйте /etc/matrix-synapse/homeserver.yaml:

server_name: "example.com"
public_baseurl: "https://matrix.example.com/"
pid_file: /run/matrix-synapse.pid

listeners:
  - port: 8008
    tls: false
    type: http
    x_forwarded: true
    bind_addresses: ['127.0.0.1']
    resources:
      - names: [client, federation]
        compress: false

database:
  name: psycopg2
  args:
    user: synapse_user
    password: "<a long password>"
    database: synapse
    host: 127.0.0.1
    cp_min: 5
    cp_max: 10

enable_registration: false
registration_shared_secret: "<a long random string>"
report_stats: false
suppress_key_server_warning: true
url_preview_enabled: false

media_store_path: /var/lib/matrix-synapse/media
max_upload_size: 100M
media_retention:
  remote_media_lifetime: 30d

rc_message:
  per_second: 0.5
  burst_count: 15

Два из этих параметров сэкономят вам диск и нервы. Удалённое хранение медиа отбрасывает кэшированные копии файлов других серверов через месяц, и без него ваше медиахранилище растёт вечно за счёт контента, который вы не запрашивали. Превью URL отключены, потому что они заставляют ваш сервер загружать произвольные адреса от имени любого, кто может разместить ссылку — это движок подделки запросов с чат-интерфейсом.

x_forwarded: true также важен: без него Synapse ограничивает скорость всех пользователей в мире так, как будто они один клиент, потому что каждый запрос выглядит приходящим от nginx.

3. Делегирование

Ваша идентичность — example.com, а сервер находится по адресу matrix.example.com. Два файла устраняют разрыв. Разместите их на example.com, по HTTPS, с правильным content type.

/.well-known/matrix/server:

{ "m.server": "matrix.example.com:443" }

/.well-known/matrix/client:

{ "m.homeserver": { "base_url": "https://matrix.example.com" } }

Порт в первом файле обязателен. Если его опустить, другие серверы переключаются на порт 8448, не находят ничего слушающего и тихо сдаются; ваши пользователи затем сообщают, что федерация не работает, в то время как все журналы на вашей машине выглядят абсолютно здоровыми.

server {
  listen 443 ssl;
  server_name example.com;
  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  location /.well-known/matrix/ {
    root /var/www/wellknown;
    default_type application/json;
    add_header Access-Control-Allow-Origin *;
  }
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name matrix.example.com;
  ssl_certificate     /etc/letsencrypt/live/matrix.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/matrix.example.com/privkey.pem;
  client_max_body_size 100m;

  location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://127.0.0.1:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
  }
}

Заголовок Access-Control-Allow-Origin на well-known location требуется веб-клиентам и забывается практически всеми. Без него десктопные клиенты работают, а браузерные клиенты вообще не могут найти ваш сервер.

mkdir -p /var/www/wellknown/.well-known/matrix
systemctl restart matrix-synapse nginx

4. Пользователь

register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://127.0.0.1:8008

Ответьте на запросы, сделайте первую учётную запись администратором и оставьте открытую регистрацию выключенной. Homeserver с открытой регистрацией становится источником спама в течение нескольких дней, и другие серверы начнут отклонять ваш трафик задолго до того, как вы это заметите.

Проверка

Двигайтесь изнутри наружу. Сначала — отвечает ли программное обеспечение вообще:

curl -s https://matrix.example.com/_matrix/client/versions | head -c 200
curl -s https://matrix.example.com/_matrix/federation/v1/version

Затем — правильно ли обслуживается делегирование: с портом и правильным content type:

curl -si https://example.com/.well-known/matrix/server | grep -E "content-type|m.server"
curl -s https://example.com/.well-known/matrix/client

Затем — разрешается ли ваш подписывающий ключ. Другие серверы загружают его, прежде чем вообще начнут с вами разговаривать:

curl -s https://matrix.example.com/_matrix/key/v2/server | head -c 300

Наконец, единственный тест, который имеет значение. Войдите через клиент, присоединитесь к публичной комнате, размещённой на homeserver, который не ваш, и отправьте сообщение. Затем прочитайте состояние федерации из admin API, используя токен доступа, который ваш клиент показывает в своих настройках:

curl -s -H "Authorization: Bearer <admin token>" \
  "https://matrix.example.com/_synapse/admin/v1/federation/destinations" | head -c 400

Каждый пункт назначения должен показывать недавнюю успешную транзакцию и отсутствующий интервал повторных попыток. У пунктов назначения с растущим retry_interval — это серверы, до которых вы не можете дотянуться; если каждый пункт назначения выглядит так, проблема в делегировании, а не в сети, и шаг три — это то, что следует проверить.

journalctl -u matrix-synapse --since "10 min ago" | grep -i "federation" | tail -20

После

Первое присоединение к очень большой комнате займёт ядро на несколько минут и подтянет большое количество состояния. Это нормально, это происходит один раз на комнату, и это главная причина, по которой люди делают вывод, что Synapse медленный. Голос и видео требуют TURN-сервера рядом с этим; coturn на том же экземпляре справится с небольшим сообществом, хотя ему нужен свой диапазон UDP-портов в файрволе. Федерация общается в обе стороны, что стоит помнить при выборе площадки: наш индекс расположения перечисляет время кругового пути, которое мы измеряем сами.