Homeserver Matrix, którego federacja naprawdę działa

Co to buduje

Serwer domowy na example.com, działający na matrix.example.com, prawidłowo federujący z innymi. Postgres pod spodem, nginx z przodu, delegacja obsługiwana przez dwa małe pliki JSON, a rejestracja zamknięta, aby Twój serwer nie stał się czyjąś darmową przekaźnikową w ciągu tygodnia.

Federacja to miejsce, gdzie te instalacje zwykle zawodzą, i prawie nigdy z powodu Synapse. Serwer działa, lokalne wiadomości działają, a potem nic z zewnątrz nie przychodzi. W praktyce przyczyną jest prawie zawsze delegacja: tożsamość serwera i adres, pod którym on żyje, to dwie różne rzeczy, a mechanizm łączący je jest łatwy do subtelnego zepsucia.

Zanim zaczniesz

• R-4 wystarczy dla kilkudziesięciu użytkowników. Synapse jest raczej pamięciożerny niż CPU-żerny, a dołączanie do dużych sfederowanych pokoi to jedyna rzecz, która go zmęczy.
• Dwie nazwy w DNS: example.com, która jest tożsamością Twojego serwera i pojawia się w każdym ID użytkownika, oraz matrix.example.com, gdzie oprogramowanie faktycznie nasłuchuje.
• Certyfikaty dla obu. Pierwszy potrzebny jest tylko do obsługi dwóch statycznych plików.

1. Baza danych z odpowiednim sortowaniem

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;"

Sortowanie nie jest szczegółem. Synapse odmawia uruchomienia na bazie utworzonej z sortowaniem innym niż C, a błąd, który wypisuje, gdy to zepsujesz, pojawia się po zaimportowaniu danych. Zrób to teraz, poprawnie, raz.

2. Konfiguracja homeservera

Pakiet Debiana pyta o nazwę serwera podczas instalacji; odpowiedz example.com, nie hostname maszyny. Ta odpowiedź staje się częścią każdego ID użytkownika i pokoju na serwerze i nie można jej później zmienić bez porzucenia serwera.

Następnie edytuj /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

Dwa z tych ustawień oszczędzą Ci dysku i zmartwień. Retencja zdalnych mediów odrzuca zapisane kopie plików z innych serwerów po miesiącu, a bez tego Twój magazyn multimediów rośnie w nieskończoność z treścią, o którą nie prosiłeś. Podglądy URL są wyłączone, ponieważ powodują, że Twój serwer pobiera arbitralne adresy w imieniu każdego, kto może opublikować link, co jest silnikiem fałszowania żądań z podpiętym interfejsem czatu.

x_forwarded: true też ma znaczenie: bez niego Synapse ogranicza prędkość każdego użytkownika na świecie tak, jakby był jednym klientem, ponieważ każde żądanie wygląda na pochodzące z nginx.

3. Delegacja

Twoja tożsamość to example.com, a Twój serwer jest pod matrix.example.com. Dwa pliki łączą tę lukę. Serwuj je z example.com, przez HTTPS, z odpowiednim typem treści.

/.well-known/matrix/server:

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

/.well-known/matrix/client:

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

Port w pierwszym pliku jest obowiązkowy. Pomiń go, a inne serwery wrócą do portu 8448, nie znajdą nic nasłuchującego i po cichu się poddadzą; Twoi użytkownicy będą potem zgłaszać, że federacja jest zepsuta, podczas gdy każdy log na Twojej maszynie wygląda na zdrowy.

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;
  }
}

Nagłówek Access-Control-Allow-Origin w lokalizacji well-known jest wymagany przez klienty webowe i zapominany przez prawie wszystkich. Bez niego klienty desktopowe działają, a przeglądarkowe nie mogą znaleźć Twojego serwera wcale.

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

4. Użytkownik

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

Odpowiedz na monity, ustaw pierwsze konto jako administratora i pozostaw otwartą rejestrację wyłączoną. Homeserver z otwartą rejestracją staje się źródłem spamu w ciągu dni, a inne serwery zaczną odrzucać Twój ruch na długo zanim to zauważysz.

Zweryfikuj to

Pracuj od wewnątrz. Najpierw, czy oprogramowanie w ogóle odpowiada:

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

Potem, czy delegacja jest serwowana poprawnie, z portem obecnym i typem treści właściwym:

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

Potem, czy Twój klucz podpisujący rozwiązuje się. Inne serwery pobierają go, zanim w ogóle zaczną z Tobą rozmawiać:

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

Na koniec jedyny test, który się liczy. Zaloguj się klientem, dołącz do publicznego pokoju hostowanego na homeserverze, który nie jest Twój, i wyślij wiadomość. Następnie odczytaj stan federacji z API administracyjnego, używając tokena dostępu, który Twój klient pokazuje w ustawieniach:

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

Każdy cel powinien pokazywać ostatnią udaną transakcję i brak interwału ponawiania. Cele z rosnącym retry_interval to serwery, których nie możesz osiągnąć; jeśli każdy cel tak wygląda, problemem jest delegacja, a nie sieć, i tam należy szukać w kroku trzecim.

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

Potem

Dołączenie do bardzo dużego pokoju za pierwszym razem przypnie rdzeń na kilka minut i ściągnie dużo stanu. To normalne, zdarza się raz na pokój i to główny powód, dla którego ludzie dochodzą do wniosku, że Synapse jest wolny. Głos i wideo potrzebują obok tego serwera TURN; coturn na tej samej instancji obsłuży małą społeczność, choć chce własnego zakresu portów UDP w firewallu. Federacja jest rozmowna w obu kierunkach, o czym warto pamiętać przy wyborze lokalizacji: nasz indeks lokalizacji wymienia czasy rundy mierzone przez nas samych.