On iki kurulum

Federasyonu gerçekten çalışan bir Matrix sunucusu

Küçük bir Ryzen örneğinde Postgres ile Synapse, SRV kayıtları yerine well-known dosyalarıyla yapılan delegasyon ve diğer sunuculara ulaşan doğrulama.

Bununla ne inşa edilir

example.com üzerinde çalışan, matrix.example.com üzerinde koşan ve herkesle düzgün şekilde federe olan bir ev sunucusu. Altta Postgres, önde nginx, delegasyon iki küçük JSON dosyasıyla halledilir ve kayıt kapatılır, böylece sunucunuz bir hafta içinde birinin parasız rölesi olmaz.

Federasyon, bu kurulumların genellikle başarısız olduğu yerdir ve neredeyse hiçbir zaman Synapse yüzünden olmaz. Sunucu çalışır, yerel mesajlar işe yarar ve sonra dışarıdan hiçbir şey gelmez. Pratikte neden neredeyse her zaman delegasyondur: sunucunun kimliği ile bulunduğu adres iki ayrı şeydir ve bunları bağlayan mekanizmayı küçük bir hatayla bozmak kolaydır.

Başlamadan önce

  • Bir R-4 birkaç düzine kullanıcı için yeterlidir. Synapse CPU'dan çok bellek tüketir ve büyük federe odalara katılmak onu zorlayacak tek şeydir.
  • DNS'te iki ad: example.com, sunucunuzun kimliği ve her kullanıcı kimliğinde görünür; matrix.example.com ise yazılımın gerçekten dinlediği yerdir.
  • Her ikisi için de sertifikalar. İlki yalnızca iki statik dosya sunmak zorundadır.

1. Veritabanı, doğru harmanlama ile

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

Harmanlama bir ayrıntı değildir. Synapse, C dışında herhangi bir harmanlamayla oluşturulmuş bir veritabanında başlamayı reddeder ve bunu yanlış yaptığınızda verdiği hatayı zaten verileri içe aktardıktan sonra alırsınız. Şimdi, doğru şekilde, bir kez yapın.

2. Homeserver yapılandırması

Debian paketi kurulum sırasında sunucu adını sorar; example.com cevabını verin, makinenin ana bilgisayar adını değil. Bu cevap, sunucudaki her kullanıcı kimliğinin ve oda kimliğinin bir parçası olur ve sunucuyu terk etmeden değiştirilemez.

Ardından /etc/matrix-synapse/homeserver.yaml dosyasını düzenleyin:

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

Bu ayarlardan ikisi size disk ve üzüntü kazandırır. Uzak medya saklama süresi, diğer sunucuların dosyalarının önbelleğe alınmış kopyalarını bir ay sonra atar ve bu olmadan medya deponuz hiç istemediğiniz içerikle sonsuza dek büyür. URL önizlemeleri kapalıdır çünkü sunucunuzun, bağlantı gönderebilen herkes adına rastgele adresleri getirmesini sağlar; bu, sohbet arayüzü takılmış bir istek sahteciliği motorudur.

x_forwarded: true de önemlidir: onsuz Synapse dünyadaki her kullanıcıyı tek bir istemci gibi sınırlar, çünkü her istek nginx'ten geliyormuş gibi görünür.

3. Delegasyon

Kimliğiniz example.com ve sunucunuz matrix.example.com adresinde. İki dosya bu boşluğu kapatır. Bunları example.com adresinden, HTTPS üzerinden, doğru içerik türüyle sunun.

/.well-known/matrix/server:

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

/.well-known/matrix/client:

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

İlk dosyadaki bağlantı noktası zorunludur. Onu atlarsanız diğer sunucular 8448 bağlantı noktasına geri düşer, dinleyen bir şey bulamaz ve sessizce vazgeçer; kullanıcılarınız daha sonra federasyonun bozuk olduğunu bildirirken makinenizdeki tüm günlükler sağlıklı görünür.

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

Well-known konumundaki Access-Control-Allow-Origin başlığı web istemcileri tarafından gereklidir ve neredeyse herkes tarafından unutulur. Onsuz, masaüstü istemciler çalışır ve tarayıcı istemcileri sunucunuzu hiç bulamaz.

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

4. Bir kullanıcı

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

İstemleri yanıtlayın, ilk hesabı yönetici yapın ve açık kaydı kapalı bırakın. Açık kayıtlı bir ev sunucusu günler içinde bir spam kaynağı haline gelir ve diğer sunucular siz fark etmeden çok önce trafiğinizi reddetmeye başlar.

Doğrulayın

Dışa doğru çalışın. İlk olarak, yazılım hiç yanıt veriyor mu:

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

Ardından, delegasyon doğru sunuluyor mu, bağlantı noktası mevcut mu ve içerik türü doğru mu:

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

Ardından, imza anahtarınız çözümleniyor mu. Diğer sunucular sizinle konuşmadan önce bunu getirir:

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

Son olarak, tek önemli test. Bir istemciyle giriş yapın, size ait olmayan bir ev sunucusunda barındırılan herkese açık bir odaya katılın ve bir mesaj gönderin. Ardından, istemcinizin ayarlarında gösterdiği erişim belirtecini kullanarak yönetim API'sinden federasyon durumunu okuyun:

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

Her hedef yakın zamanda başarılı bir işlem ve yeniden deneme aralığı olmadığını göstermelidir. Artan retry_interval olan hedefler, ulaşamadığınız sunuculardır; her hedef böyle görünüyorsa, sorun ağ değil delegasyondur ve üçüncü adıma bakmalısınız.

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

Sonrasında

İlk kez çok büyük bir odaya katılmak bir çekirdeği birkaç dakika meşgul eder ve büyük miktarda durum çeker. Bu normaldir, oda başına bir kez olur ve insanların Synapse'ın yavaş olduğu sonucuna varmasının ana nedenidir. Ses ve video için bunun yanında bir TURN sunucusu gerekir; aynı örnekteki coturn küçük bir topluluğu idare eder, ancak güvenlik duvarında kendi UDP bağlantı noktası aralığını ister. Federasyon her iki yönde de konuşkandır; site seçerken bunu hatırlamakta fayda var: konum dizinimiz kendi ölçtüğümüz gidiş-dönüş sürelerini listeler.

Hazır olduğunda

Bir şehir seç. Bir boyut seç. Kripto ile öde.

Kim olduğunuzla ilgili formlar yok, onay için insan bekleme yok, doğrulama için telefon görüşmesi yok. Ödeme onaylanır ve kimlik bilgileri gelen kutunuza düşer.