خادم Matrix للمنزلية (homeserver) يعمل اتحاده (federation) فعلاً

ما يبنيه هذا الدليل

خادم منزلي على example.com، يعمل على matrix.example.com، ويتحد بشكل صحيح مع الجميع. بوستغريس في الخلفية، وnginx في المقدمة، والتفويض يتم عبر ملفين صغيرين بصيغة JSON، والتسجيل مغلق حتى لا يصبح خادمك مرحّلًا مجانيًا لشخص آخر خلال أسبوع.

الاتحاد هو المكان الذي تفشل فيه هذه التركيبات عادةً، ولا يكاد يكون السبب أبدًا هو Synapse. يعمل الخادم، وتعمل الرسائل المحلية، ثم لا يصل شيء من الخارج. في الواقع، السبب دائمًا تقريبًا هو التفويض: هوية الخادم والعنوان الذي يعيش عليه شيئان مختلفان، والآلية التي تربط بينهما من السهل أن تكون خاطئة بشكل خفي.

قبل البدء

• يكفي R-4 لعشرات المستخدمين. سينابس شره للذاكرة أكثر منه شره للمعالج، والانضمام إلى غرف اتحادية كبيرة هو الشيء الوحيد الذي يجعله يلهث.
• اسمان في DNS: example.com، وهو هوية الخادم ويظهر في كل معرف مستخدم، وmatrix.example.com، وهو المكان الذي يستمع فيه البرنامج فعليًا.
• شهادات SSL لكل منهما. الأول يحتاج فقط لخدمة ملفين ثابتين.

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

الترتيب ليس تفصيلًا. سينابس يرفض البدء على قاعدة بيانات منشأة بأي ترتيب غير C، والخطأ الذي يطبعه عندما تخطئ في هذا يأتي بعد أن تكون قد استوردت البيانات بالفعل. افعلها الآن، بشكل صحيح، مرة واحدة.

2. إعداد الخادم المنزلي

تسأل حزمة دبيان عن اسم الخادم أثناء التثبيت؛ أجب بـ example.com، وليس اسم المضيف للآلة. يصبح هذا الجواب جزءًا من كل معرف مستخدم ومعرف غرفة في الخادم ولا يمكن تغييره لاحقًا دون التخلي عن الخادم.

ثم حرر /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

اثنان من هذه الإعدادات سيوفران لك مساحة القرص والأسى. الاحتفاظ بالوسائط البعيدة يتجاهل النسخ المخزنة مؤقتًا من ملفات الخوادم الأخرى بعد شهر، وبدونه ينمو مخزن الوسائط لديك إلى الأبد بمحتوى لم تطلبه أبدًا. معاينات الروابط معطلة لأنها تجعل خادمك يجلب عناوين عشوائية نيابة عن أي شخص يمكنه نشر رابط، وهو محرك تزوير طلبات مع واجهة دردشة ملحقة.

x_forwarded: true مهم أيضًا: بدونه، يحد سينابس من معدل طلبات كل مستخدم في العالم كما لو كانوا عميلًا واحدًا، لأن كل طلب يبدو وكأنه قادم من nginx.

3. التفويض

هويتك هي example.com وخادمك على matrix.example.com. ملفان يسدّان الفجوة. قدمهما من example.com، عبر HTTPS، بنوع المحتوى الصحيح.

/.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 مطلوبة من عملاء الويب وينساها الجميع تقريبًا. بدونها، تعمل عملاء سطح المكتب ولا يمكن لعملاء المتصفح العثور على خادمك إطلاقًا.

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

أجب على المطالبات، واجعل الحساب الأول مسؤولًا، واترك التسجيل المفتوح معطلًا. الخادم المنزلي ذو التسجيل المفتوح يصبح مصدرًا للبريد العشوائي خلال أيام، وستبدأ الخوادم الأخرى في رفض حركة المرور الخاصة بك قبل أن تلاحظ.

تحقق من ذلك

اعمل من الداخل إلى الخارج. أولاً، هل يجيب البرنامج على الإطلاق:

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

ثم، هل يتم تقديم التفويض بشكل صحيح، مع وجود المنفذ ونوع المحتوى الصحيح:

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

أخيرًا، الاختبار الوحيد الذي يهم. سجل الدخول باستخدام عميل، وانضم إلى غرفة عامة مستضافة على خادم منزلي ليس خادمك، وأرسل رسالة. ثم اقرأ حالة الاتحاد من واجهة برمجة تطبيقات الإدارة، باستخدام رمز الوصول الذي يعرضه عميلك في إعداداته:

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

بعد ذلك

الانضمام إلى غرفة كبيرة جدًا في المرة الأولى سيثبّت نواة لعدة دقائق ويجلب الكثير من الحالة. هذا طبيعي، يحدث مرة واحدة لكل غرفة، وهو السبب الرئيسي الذي يجعل الناس يستنتجون أن سينابس بطيء. الصوت والفيديو يحتاجان إلى خادم TURN بجانب هذا؛ coturn على نفس المثيل يدير مجتمعًا صغيرًا، على الرغم من أنه يريد نطاق منافذ UDP خاصًا به في جدار الحماية. الاتحادثرثار في كلا الاتجاهين، وهو أمر يستحق التذكر عند اختيار الموقع: فهرس المواقع يسرد أوقات الرحلة ذهابًا وإيابًا التي نقيسها بأنفسنا.