VPS-এ Matrix Synapse সেটআপ ও রক্ষণাবেক্ষণের নিয়ম

একটি Matrix Synapse homeserver সচল রাখার প্রয়োজনীয়তা

Matrix Synapse ইনস্টল করা সহজ, কিন্তু একে অবহেলা করাও সহজ। এর ইনস্টলেশন প্রক্রিয়ায় একটি apt repository, একটি configuration file, একটি reverse proxy block এবং একটি DNS record প্রয়োজন হয়। এক বছর ধরে homeserver-কে সুস্থ রাখা সম্পূর্ণ ভিন্ন একটি কাজ: এর জন্য প্রয়োজন একটি প্রকৃত database, media store যা নিয়মিত পরিষ্কার (prune) করা হয়, এমন registration ব্যবস্থা যা অপরিচিতরা ব্যবহার করতে পারে না, এবং একটি backup যা সার্ভারের উভয় অংশকেই সংরক্ষণ করে।

এই নির্দেশিকাটি Ubuntu 24.04 LTS-এর জন্য তৈরি এবং এটি matrix.org apt repository থেকে Synapse ইনস্টল করে, যা Debian এবং Ubuntu-এর জন্য Synapse প্রজেক্ট কর্তৃক রক্ষণাবেক্ষণ করা প্যাকেজ সোর্স। প্যাকেজ ভার্সন প্রতি কয়েক সপ্তাহ পরপর পরিবর্তিত হয়, তাই এখানে কোনো নির্দিষ্ট ভার্সন নম্বর উল্লেখ করা হয়নি। নিচে উল্লিখিত প্রতিটি path এবং option বর্তমান Synapse documentation থেকে নেওয়া হয়েছে।

Sizing: 1টি vCPU এবং 2 GB RAM আসলে আপনাকে কী দেয়

আগস্ট 2026 পর্যন্ত প্রকাশিত সাইজিং পেজগুলোতে সাধারণত Synapse homeserver-এর জন্য 1টি vCPU এবং 2 GB RAM-এর সুপারিশ করা হয়। এটি একটি নির্দিষ্ট ক্ষেত্রে সঠিক: একটি ব্যক্তিগত সার্ভার, যেখানে ব্যবহারকারী কম, রুমগুলো ছোট এবং কোনো ব্যস্ত পাবলিক রুম নেই। Synapse-এর ডকুমেন্টেশন অন্য ক্ষেত্রটির ব্যাপারে সরাসরি সতর্ক করে। সেখানে বলা হয়েছে, "আপনি যদি #matrix:matrix.org-এর মতো বড় পাবলিক রুমে যোগ দিতে চান, তবে অন্তত 1 GB ফ্রি RAM প্রয়োজন।" এই ফ্রি RAM-এর হিসাবটি Python, Postgres এবং কার্নেলের ব্যবহারের অতিরিক্ত।

একটি রুম আপনার সাইজিংয়ের প্রয়োজনীয়তা বদলে দিতে পারে, কারণ জয়েন করার প্রক্রিয়াটি সেভাবেই কাজ করে। যখন কোনো লোকাল ব্যবহারকারী একটি রুমে যোগ দেন, আপনার homeserver সেই রুমের একজন পূর্ণ অংশগ্রহণকারী হয়ে ওঠে। এটি সেই রুমের প্রতিটি সার্ভার থেকে আসা প্রতিটি ইভেন্ট গ্রহণ করে, প্রতিটির সিগনেচার যাচাই করে এবং রুমের স্টেট লোকালি সংরক্ষণ করে। একটি বড় পাবলিক রুমে শত শত সার্ভার জুড়ে হাজার হাজার সদস্য থাকে, তাই আপনার ব্যবহারকারী রুমটি খুলুন বা না খুলুন, আপনার সার্ভারকে ক্রমাগত এই কাজগুলো করতে হয়। পরবর্তীতে রুম থেকে বেরিয়ে গেলেও আপনার সংরক্ষিত হিস্ট্রি মুছে যায় না।

Synapse-এর RAM-এর বেশিরভাগ অংশ ক্যাশে (caches) ব্যবহৃত হয়। caches সেকশনে একটি global_factor আছে যা একসাথে সব ক্যাশ স্কেল করে এবং SYNAPSE_CACHE_FACTOR এনভায়রনমেন্ট ভেরিয়েবল একই কাজ করে। এটি বাড়ালে RAM খরচ হয় কিন্তু ডাটাবেস কুয়েরি কমে। এটি কমালে CPU এবং Postgres-এর ওপর চাপ বাড়ে কিন্তু RAM বাঁচে। Postgres-এর নিজেরও মেমোরি প্রয়োজন, তাই 2 GB-এর একটি বক্সে এই দুটি একই মেমোরির জন্য প্রতিযোগিতা করে।

ছোট প্ল্যানের জন্য দুটি ব্যবহারিক নিয়ম মেনে চলুন। Swap যোগ করুন: swap Synapse-কে দ্রুত করবে না, কিন্তু বড় কোনো রুমে যোগ দেওয়ার সময় কার্নেল যাতে প্রসেসটিকে কিল (kill) না করে, তা নিশ্চিত করবে। এরপর প্রথম সপ্তাহ থেকেই ডিস্কের দিকে নজর রাখুন, কারণ মিডিয়া স্টোর এবং রুম স্টেট টেবিল—এই দুটি জিনিসই কোনো সীমা ছাড়াই বাড়তে থাকে এবং উভয়ই ডিস্কে জায়গা নেয়।

কেন Postgres ব্যবহার করবেন এবং কেন SQLite আর কার্যকর নয়

Debian প্যাকেজটি ডিফল্টভাবে SQLite দিয়ে শুরু হয়। প্রথমবার বুট করার জন্য এটি ঠিক থাকলেও, অন্য ব্যবহারকারীরা ব্যবহার করেন এমন সার্ভারের জন্য এটি উপযুক্ত নয়। SQLite-এ একবারে কেবল একজন রাইটার (writer) কাজ করতে পারে। ফেডারেশন ট্রাফিক এবং ক্লায়েন্ট রিকোয়েস্ট একই সময়ে ডেটা রাইট করার চেষ্টা করলে, একটি সাধারণ রিকোয়েস্টকে ধীরগতির রিকোয়েস্টের জন্য অপেক্ষা করতে হয়। এর ফলে ব্যবহারকারীরা অভিযোগ করেন যে অ্যাপটি মাঝেমধ্যে কয়েক সেকেন্ডের জন্য হ্যাং হয়ে যাচ্ছে।

দ্বিতীয় কারণটি কাঠামোগত। Synapse-এর ওয়ার্কার প্রসেসগুলো একাধিক CPU কোর ব্যবহারের সমর্থিত উপায়, আর এই ওয়ার্কারগুলোর জন্য Postgres প্রয়োজন। SQLite-এ আটকে থাকলে আপনি পারফরম্যান্সের পাশাপাশি আপগ্রেড করার সুবিধাও হারাবেন।

পরবর্তীতে মাইগ্রেট করার সুযোগ থাকলেও তাতে ডাউনটাইম প্রয়োজন হয়, তাই ব্যবহারকারী আসার আগেই এটি সম্পন্ন করুন। Synapse-এর সাথে synapse_port_db টুলটি থাকে, যা একটি SQLite ডেটাবেসকে প্রস্তুতকৃত Postgres ডেটাবেসে কপি করে:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

আপনি যদি Synapse-এর পাশাপাশি কন্টেইনারে ডেটাবেস চালাতে চান, তবে এর সুবিধা-অসুবিধাগুলো Docker-এ বা হোস্ট মেশিনে ডেটাবেস চালানো অংশে দেখুন।

Ubuntu 24.04-এ Synapse ইনস্টল করা

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Ubuntu 24.04-এ lsb_release -cs কমান্ডটি noble প্রিন্ট করে এবং matrix.org রিপোজিটরি একটি noble স্যুট প্রকাশ করে। Ubuntu-এর নিজস্ব আর্কাইভ থেকে matrix-synapse প্যাকেজটি ব্যবহার করবেন না। Synapse প্রজেক্ট এটি ব্যবহার না করার পরামর্শ দেয়, কারণ সেই বিল্ডগুলো তাদের রিলিজের তুলনায় পিছিয়ে থাকে এবং সেগুলোতে পরিচিত নিরাপত্তা ত্রুটি থাকতে পারে।

ইনস্টলারটি একটি সার্ভার নাম জানতে চাইবে এবং উত্তরটি /etc/matrix-synapse/conf.d/server_name.yaml ফাইলে লিখে রাখবে। সতর্কতার সাথে উত্তর দিন। server_name হলো প্রতিটি ইউজার আইডি (@alice:example.com)-এর কোলনের পরের অংশ এবং এটি আপনার সার্ভারের তৈরি প্রতিটি রুমে এমবেড করা থাকে। পরবর্তীতে এটি পরিবর্তন করলে কোনো কিছু স্থানান্তর হয় না: এটি একটি ভিন্ন হোমসার্ভার তৈরি করে। আপনার মূল ডোমেইন, example.com ব্যবহার করুন, এমনকি যখন Synapse নিজে matrix.example.com-এ চলবে তখনও। ডেলিগেশন এই দুটির মধ্যে সংযোগ স্থাপন করে এবং সেটি পরবর্তী সেকশনে আলোচনা করা হয়েছে।

প্যাকেজটি Synapse-কে matrix-synapse ইউজার হিসেবে চালায়, এর ডেটা /var/lib/matrix-synapse-এর অধীনে রাখে এবং /etc/matrix-synapse/homeserver.yaml ফাইলটি পড়ার পর /etc/matrix-synapse/conf.d/-এর প্রতিটি ফাইল পড়ে। আপনার নিজস্ব সেটিংস conf.d-এর ছোট ছোট ফাইলে রাখুন। প্যাকেজ আপগ্রেড করার সময় এই ফাইলগুলো অপরিবর্তিত থাকে।

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

একটি সফল শুরুর পর লিসেনারগুলো চালু হয় এবং তারপর সিস্টেমটি শান্ত হয়ে যায়। কোনো কারণে সার্ভিসটি বন্ধ হয়ে গেলে systemd ইউনিট কয়েক সেকেন্ডের মধ্যে তা পুনরায় চালু করে, তাই Synapse যে কনফিগারেশন গ্রহণ করে না তা একটি লুপে চালু হতে এবং বন্ধ হতে থাকে। জার্নালের শেষ লাইনগুলোতে সেই কী (key)-এর নাম থাকে যা এটি প্রত্যাখ্যান করেছে।

Synapse-কে Postgres-এর দিকে নির্দেশ করুন

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

Locale কোনো সাজসজ্জার বিষয় নয়। Synapse ভিন্ন COLLATE এবং CTYPE মান দিয়ে তৈরি করা ডাটাবেসের সাথে শুরু হতে অস্বীকার করে, যদি না আপনি ডাটাবেস কনফিগারেশনে allow_unsafe_locale সেট করেন। এর পরবর্তী নথিভুক্ত সমাধান হলো ডাটাবেস ডাম্প করা এবং সঠিকভাবে তৈরি করা নতুন ডাটাবেসে তা পুনরায় লোড করা। তাই প্রথমবারই এটি সঠিকভাবে তৈরি করুন।

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

আপনার সমস্ত কনফিগারেশন ফাইল জুড়ে শুধুমাত্র একটি database: কি (key) রাখুন। conf.d-এর অধীনে দ্বিতীয় কোনো কপি যোগ না করে homeserver.yaml-এর ভেতরের SQLite ব্লকটি প্রতিস্থাপন করুন। এতে কোনটি কার্যকর তা নিয়ে কোনো বিভ্রান্তি থাকবে না। রিস্টার্ট করুন, তারপর নিশ্চিত করুন যে Synapse সত্যিই Postgres ব্যবহার করছে:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

একটি সংখ্যা আসার অর্থ হলো Synapse এই ডাটাবেসে তার স্কিমা তৈরি করেছে। কোনো missing relation সংক্রান্ত ত্রুটি পাওয়ার অর্থ হলো এটি এখনও SQLite ফাইলে লিখছে, যার মানে আপনি যে কনফিগারেশনটি এডিট করেছেন সেটি পড়া হচ্ছে না।

Reverse proxy, TLS এবং .well-known ফাইল ফেডারেশনের প্রয়োজনীয়তা

Synapse লোকালহোস্টে পোর্ট 8008-এ plain HTTP-তে লিসেন করে। TLS এবং পাবলিক পোর্ট এর সামনে থাকা একটি reverse proxy-র দায়িত্ব।

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

x_forwarded: true Synapse-কে নির্দেশ দেয় যেন এটি প্রক্সির সেট করা X-Forwarded-For হেডারটিকে বিশ্বাস করে। এটি ছাড়া প্রতিটি ক্লায়েন্টকে 127.0.0.1 থেকে আসা বলে মনে হয়, ফলে রেট লিমিটিং সব ব্যবহারকারীকে একজন অত্যন্ত ব্যস্ত লোকাল ব্যবহারকারী হিসেবে গণ্য করে এবং সবাইকে একসাথে থ্রটল (throttle) করে।

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

Synapse ডকুমেন্টেশনে এই ব্লকটি নিয়ে একটি সতর্কবার্তা দেওয়া আছে যা অনেকের কয়েক দিনের পরিশ্রম নষ্ট করে। proxy_pass-এ পোর্টের পরে কোনো পাথ, এমনকি একটি /-ও যোগ করবেন না। nginx তখন URI-কে ক্যানোনিকাল (canonicalise) করে ফেলে, যা পাঠানো সার্ভারের স্বাক্ষরিত বাইটগুলোকে পরিবর্তন করে দেয়। ফলে সাধারণ ক্লায়েন্ট রিকোয়েস্ট কাজ করলেও ফেডারেশন রিকোয়েস্টগুলো সিগনেচার ভেরিফিকেশনে ব্যর্থ হয়।

client_max_body_size অবশ্যই Synapse-এর max_upload_size-এর সমান বা তার চেয়ে বড় হতে হবে। যদি nginx-এ ছোট সংখ্যা সেট করা থাকে, তবে তার চেয়ে বড় ফাইল আপলোড nginx দ্বারা 413 Request Entity Too Large এর মাধ্যমে প্রত্যাখ্যাত হবে। Synapse এই রিকোয়েস্ট পাওয়ার আগেই তা আটকে যায়, তাই ব্যর্থতার কারণ ব্যাখ্যা করার মতো কোনো Synapse লগ পাওয়া যায় না।

সার্টিফিকেটের জন্য, Certbot and Let's Encrypt on Ubuntu 24.04 অনুসরণ করুন। যদি প্রক্সি নির্বাচন নিয়ে দ্বিধা থাকে, তবে reverse proxy comparison দেখুন, সেখানে আপনার জন্য কোনটি TLS-এর কাজ করবে তা আলোচনা করা হয়েছে।

ডেলিগেশন হলো সেই প্রক্রিয়া যা server_name-কে example.com হিসেবে বহাল রাখে, যদিও Synapse matrix.example.com-এ চলে। বেয়ার ডোমেইন থেকে দুটি ফাইল সার্ভ করুন:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

সার্ভার ফাইলটি অন্য হোমসার্ভারগুলোকে জানায় ফেডারেশন ট্র্যাফিক কোথায় পাঠাতে হবে, যার মাধ্যমে ফেডারেশন ডিফল্ট পোর্ট 8448-এর পরিবর্তে 443 পোর্টে চলে। ক্লায়েন্ট ফাইলটি Matrix ক্লায়েন্টদের জানায় কোন URL @alice:example.com-কে ব্যাক করে। ক্লায়েন্ট ফাইলে Access-Control-Allow-Origin হেডারটি গুরুত্বপূর্ণ, কারণ ব্রাউজার-ভিত্তিক ক্লায়েন্টরা এটি ক্রস-অরিজিন (cross-origin) হিসেবে ফেচ করে। এই হেডার ছাড়া ব্রাউজার রেসপন্স ব্লক করে দেয় এবং ক্লায়েন্ট রিপোর্ট করে যে এটি আপনার হোমসার্ভার খুঁজে পাচ্ছে না।

উভয় ফাইলই অবশ্যই example.com থেকে বৈধ TLS-এর মাধ্যমে সার্ভ করতে হবে। এগুলো চেক করুন, তারপর বাইরের পৃথিবী কী দেখছে তা যাচাই করুন:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

প্রথমটি আপনার লেখা JSON রিটার্ন করবে। দ্বিতীয়টি সার্ভার ইমপ্লিমেন্টেশন এবং এর ভার্সনের নামসহ একটি JSON অবজেক্ট রিটার্ন করবে, যা প্রমাণ করে যে প্রক্সি ফেডারেশন পাথে Synapse-এর সাথে যোগাযোগ করতে পারছে। এরপর https://federationtester.matrix.org-এ Matrix ফেডারেশন টেস্টার ব্যবহার করে আপনার ডোমেইনটি পরীক্ষা করুন, যা একটি প্রকৃত রিমোট সার্ভার যে রুট অনুসরণ করে ঠিক সেই রুটেই পরীক্ষা চালায়।

ফেডারেট করবেন কি করবেন না: উদ্দেশ্য বুঝে সিদ্ধান্ত নিন

Matrix-এর মূল ভিত্তি হলো ফেডারেশন, আবার এর বেশিরভাগ খরচও এখান থেকেই আসে। একটি ফেডারেটিং homeserver এমন সব সার্ভার থেকে সংযোগ গ্রহণ করে যাদের সম্পর্কে আপনার কোনো ধারণাই নেই, তাদের ইভেন্টগুলো গ্রহণ করে, তাদের মিডিয়া ক্যাশ করে এবং আপনার ব্যবহারকারীরা যে রুমগুলোতে যুক্ত হন তার স্টেট সংরক্ষণ করে। এটি একটি থ্রেট মডেল বা নিরাপত্তা সংক্রান্ত সিদ্ধান্ত, ডিফল্ট কোনো বিষয় নয়।

আপনার ব্যবহারকারীদের যদি অন্য homeserver-এর মানুষের সাথে যোগাযোগ করার প্রয়োজন হয়, অথবা পোর্টেবল আইডেন্টিটি ব্যবহারের উদ্দেশ্যেই যদি আপনি Matrix বেছে নিয়ে থাকেন, তবেই ফেডারেট করুন। যদি সার্ভারটি শুধুমাত্র একটি নির্দিষ্ট টিমের জন্য হয় এবং এর প্রতিটি অ্যাকাউন্ট আপনার নিজের হয়, তবে ফেডারেট করবেন না। একটি ক্লোজড সার্ভারে ডেটা কম জমা হয়, বাইরের ট্রাফিক কম আসে এবং এটি অপব্যবহারের জন্য অনেক কম আকর্ষণীয়।

ফেডারেশন পুরোপুরি বন্ধ না করে সীমাবদ্ধ করতে, Synapse একটি allow list গ্রহণ করে:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

ডকুমেন্টেশনে ফেডারেশন লিসেনারটিকে ফায়ারওয়ালের আওতায় রাখার পরামর্শ দেওয়া হয়, যাতে অবাঞ্ছিত ট্রাফিক Python-এর ভেতরে ঢোকার আগেই নেটওয়ার্ক লেভেলে আটকে যায়। ফেডারেশন পুরোপুরি বন্ধ করতে, লিসেনার resources তালিকা থেকে federation সরিয়ে ফেলুন, /.well-known/matrix/server পাবলিশ করবেন না এবং 8448 পোর্টটি বন্ধ রাখুন।

যদি Matrix চালানোর উদ্দেশ্য শুধুমাত্র ব্যক্তিগত টিম চ্যাট হয় এবং ফেডারেশন এর অংশ না থাকে, তবে Synapse ব্যবহার করার আগে অন্যান্য self-hosted Slack বিকল্পগুলোর সাথে চলমান খরচের তুলনা করে দেখুন। Rocket.Chat on Docker Compose ছোট মেশিনেও টিম চ্যাট পরিচালনা করতে পারে, কারণ এতে অন্য কোনো প্রতিষ্ঠানের রুমের স্টেট সংরক্ষণ করার প্রয়োজন হয় না।

মিডিয়া রিপোজিটরি হলো সেই জায়গা যা নীরবে ডিস্ক পূর্ণ করে

আপনার ব্যবহারকারীদের আপলোড করা ফাইলগুলো স্থায়ীভাবে আপনার ডিস্কে থেকে যায়। অন্য হোমসার্ভারের ব্যবহারকারীদের পোস্ট করা ফাইলগুলো আপনার কোনো ক্লায়েন্ট প্রদর্শন করার সাথে সাথেই ফেচ (fetch) হয়ে ডিস্কে ক্যাশ (cache) হয়। এছাড়া Synapse ছবির জন্য থাম্বনেইল তৈরি করে, ফলে একটি ছবি থেকে একাধিক ফাইল তৈরি হয়। ডিফল্টভাবে এগুলোর কোনোটিরই মেয়াদ শেষ হয় না।

স্টোরটি খুঁজে বের করুন এবং এর আকার পরিমাপ করুন:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

আপনার কনফিগারেশনে যে পাথটি দেওয়া আছে তা পরিমাপ করুন। Debian প্যাকেজে Synapse-এর ডেটা /var/lib/matrix-synapse-এর অধীনে থাকে, তাই স্টোরটি সাধারণত সেখানেই থাকে। এরপর conf.d-এ একটি রিটেনশন পলিসি (retention policy) সেট করুন:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

এই দুটি লাইন মনোযোগ দিয়ে পড়ুন, কারণ এগুলো একই ধরনের সেটিং নয়। remote_media_lifetime একটি ক্যাশের মেয়াদ শেষ করে এবং এটি যা মুছে ফেলে তা ফাইলের মালিক সার্ভার থেকে পুনরায় ফেচ করা সম্ভব। local_media_lifetime আপনার নিজের ব্যবহারকারীদের আপলোড করা ফাইলগুলো নির্দিষ্ট বয়স পার হলে স্থায়ীভাবে মুছে ফেলে। যে টিম চ্যাটে ডকুমেন্ট শেয়ার করে এবং আগামী বছর সেগুলো পাওয়ার আশা করে, তারা সেগুলো হারিয়ে ফেলবে। অনেক সার্ভার শুধুমাত্র রিমোট ভ্যালু সেট করে রাখে।

এককালীন ক্লিনআপের জন্য, অ্যাডমিন API মিলিসেকেন্ডে একটি Unix timestamp গ্রহণ করে:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache সেই টাইমস্ট্যাম্পের আগে শেষবার অ্যাক্সেস করা রিমোট মিডিয়া ক্যাশ মুছে ফেলে। POST /_synapse/admin/v1/media/delete?before_ts=<ms> একই নিয়ম মেনে লোকাল মিডিয়া মুছে ফেলে। প্রথমে রিমোট পার্জ (purge) চালান এবং পুনরায় পরিমাপ করুন, কারণ ফেডারেশন করা সার্ভারে রিমোট ক্যাশ সাধারণত বড় অংশ দখল করে থাকে।

দুটি সেটিং একই ডিস্কের ওপর প্রভাব ফেলে। max_upload_size একটি আপলোডের সর্বোচ্চ সীমা নির্ধারণ করে এবং এটি nginx-এর client_max_body_size-এর সাথে সামঞ্জস্যপূর্ণ হতে হবে। url_preview_enabled: true আপনার সার্ভারকে রিমোট পেজ ফেচ করতে বাধ্য করে যাতে ক্লায়েন্টরা লিঙ্কের প্রিভিউ দেখাতে পারে। এটি ব্যান্ডউইথ খরচ করে এবং এমন সব কন্টেন্টের থাম্বনেইল জমা করে যা কেউ আপনার সার্ভারে আপলোড করেনি।

কেউ আপনার homeserver খুঁজে পাওয়ার আগেই রেজিস্ট্রেশন বন্ধ করুন

স্ক্যানারগুলো কয়েক দিনের মধ্যেই একটি উন্মুক্ত homeserver খুঁজে বের করে। একবার অ্যাকাউন্ট তৈরির সুযোগ উন্মুক্ত হয়ে গেলে, আপনার সার্ভারটি প্রতিটি ফেডারেশন করা রুমে স্প্যামের উৎস হয়ে উঠবে এবং অন্য প্রান্তের অ্যাডমিনিস্ট্রেটররা আপনার পুরো ডোমেইনটিকে ব্লক করে দেবেন। এই খ্যাতির ক্ষতি পরিষ্কার করার পরেও থেকে যায়, কারণ ব্লক লিস্টগুলো হাতে তৈরি করা হয়।

Synapse ডিফল্টভাবে বন্ধ অবস্থায় থাকে। enable_registration ডিফল্টভাবে false এবং registration_requires_token ডিফল্টভাবে false থাকে। এছাড়া, রেজিস্ট্রেশন চালু থাকা অবস্থায় এবং কোনো ভেরিফিকেশন ধাপ না থাকলে Synapse চালু হতে অস্বীকার করে, যদি না আপনি অতিরিক্তভাবে enable_registration_without_verification: true সেট করেন। এই অস্বীকৃতিটি ইচ্ছাকৃত, তাই স্টার্টআপ এরর দূর করার জন্য এটি চালু করবেন না।

আপনার প্রয়োজনীয় অ্যাকাউন্টগুলো হাতে তৈরি করুন:

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

এটি ব্যবহারকারীর নাম, পাসওয়ার্ড এবং অ্যাকাউন্টটি সার্ভার অ্যাডমিন হবে কি না তা জানতে চাইবে। এটি -c দিয়ে পাস করা কনফিগারেশন থেকে registration_shared_secret পড়ে, তাই যদি এটি জানায় যে এটি কোনো shared secret খুঁজে পাচ্ছে না, তবে -c-কে সেই ফাইলটির দিকে নির্দেশ করুন যেখানে এটি সংরক্ষিত আছে।

যখন হাতে অ্যাকাউন্ট তৈরি করা আর কার্যকর থাকে না, তখন রেজিস্ট্রেশন টোকেন হলো এর মধ্যবর্তী সমাধান। টোকেন হলো এমন একটি স্ট্রিং যা একজন নতুন ব্যবহারকারীকে সাইনআপের সময় প্রদান করতে হয় এবং প্রতিটি টোকেনের ক্ষেত্রে এটি কতবার কাজ করবে তার একটি সীমা নির্ধারণ করা যায়:

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

বডি থেকে token বাদ দিন, তাহলে Synapse একটি টোকেন তৈরি করবে এবং সেটি ফেরত দেবে। GET /_synapse/admin/v1/registration_tokens বর্তমানে সক্রিয় টোকেনগুলোর তালিকা দেখায়। উভয় কলের জন্যই একজন সার্ভার অ্যাডমিন অ্যাকাউন্টের access token প্রয়োজন, যা আপনি উপরে তৈরি করা অ্যাডমিন ইউজার হিসেবে লগইন করে পাবেন।

যেসব প্রতিষ্ঠান অন্য কোথাও অ্যাকাউন্ট ম্যানেজ করে, তারা স্থানীয় পাসওয়ার্ডের ব্যবহার পুরোপুরি এড়িয়ে যেতে পারে। কারণ Synapse লগইন প্রক্রিয়াকে একটি OIDC (OpenID Connect) প্রোভাইডারের কাছে অর্পণ করতে পারে, উদাহরণস্বরূপ Authentik as a self-hosted SSO provider। এতে নতুন সদস্য যোগ করা বা বাদ দেওয়ার কাজ এক জায়গা থেকেই করা সম্ভব হয়।

একটি ব্যাকআপ যা দিয়ে সার্ভার পুনরায় তৈরি করা সম্ভব

একটি Synapse ব্যাকআপের তিনটি অংশ থাকে এবং এর কোনো একটি অংশ বাদ পড়লে এমন একটি সার্ভার রিস্টোর হবে যা কেউ ব্যবহার করতে পারবে না।

• Postgres ডাটাবেস, যেখানে প্রতিটি ইভেন্ট, অ্যাকাউন্ট এবং রুম সংরক্ষিত থাকে।
• মিডিয়া স্টোর ডিরেক্টরি, যেখানে প্রতিটি আপলোড করা ফাইল থাকে।
• /etc/matrix-synapse, যেখানে আপনার কনফিগারেশন এবং সার্ভারের সাইনিং কি (signing key) থাকে।

সাইনিং কি-টি হলো সেই অংশ যা মানুষ প্রায়ই ভুলে যায়। এটি সেই প্রাইভেট কি যার মাধ্যমে আপনার হোমসার্ভার ইভেন্টগুলোতে স্বাক্ষর করে এবং রিমোট সার্ভারগুলো সংশ্লিষ্ট পাবলিক কি-এর বিপরীতে সেই ইভেন্টগুলো যাচাই করে। আপনার কি কোথায় আছে তা দেখতে grep signing_key_path /etc/matrix-synapse/homeserver.yaml চালান। এটি হারিয়ে ফেললে আপনি এমন একটি সার্ভার রিস্টোর করবেন যা প্রমাণ করতে পারবে না যে এটি সেই একই সার্ভার যাকে আপনার রুমগুলো আগে থেকেই চেনে।

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

প্রথমে ডাটাবেস ডাম্প করুন, তারপর মিডিয়া স্টোর কপি করুন। মিডিয়া ফাইলগুলো একবারই লেখা হয় এবং আইডি দ্বারা রেফারেন্স করা হয়, তাই ডাম্পের পরে নেওয়া মিডিয়া কপিতে কেবল অতিরিক্ত ফাইল থাকতে পারে, কোনো ফাইল বাদ পড়ার সুযোগ নেই। উল্টো ক্রমে কাজ করলে রিস্টোর করা ডাটাবেস এমন কোনো ফাইলের দিকে নির্দেশ করতে পারে যা আপনার ব্যাকআপে নেই।

তিনটি অংশই VPS থেকে বাইরে পাঠিয়ে দিন। off-site snapshot সহ restic এই কাজের জন্য উপযুক্ত, কারণ মিডিয়া স্টোর হলো বড় অংশ এবং এটি রানগুলোর মাঝে খুব একটা পরিবর্তিত হয় না, তাই ডিডুপ্লিকেশন (deduplication) প্রতিটি স্ন্যাপশটকে ছোট রাখে।

এরপর রিস্টোর করার মহড়া দিন, কারণ যে ব্যাকআপ আপনি কখনো রিস্টোর করেননি তা কেবল একটি অনুমান মাত্র। একটি দ্বিতীয় VPS তৈরি করুন, একই প্যাকেজ ইনস্টল করুন, কনফিগারেশন রিস্টোর করুন, একই এনকোডিং এবং লোকেল (locale) দিয়ে ডাটাবেস তৈরি করুন, pg_restore ব্যবহার করে ডাম্পটি তাতে ইমপোর্ট করুন, মিডিয়া স্টোরটি কপি করে ফিরিয়ে আনুন এবং লগ-ইন করুন। এটি করতে কত সময় লেগেছে তা লিখে রাখুন। সেই সংখ্যাটিই আপনার প্রকৃত রিকভারি টাইম।

যখন স্টেট টেবিলগুলো বড় হয়ে যায়: কমপ্যাকশন

Synapse রুমের স্টেটকে স্টেট গ্রুপ হিসেবে সংরক্ষণ করে এবং একটি ফেডারেশন সার্ভারে state_groups_state প্রায়শই ডাটাবেসের সবচেয়ে বড় অবজেক্টে পরিণত হয়। কোনো কিছু পরিবর্তন করার আগে পরিমাপ করে নিন:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

যদি এই একটি টেবিলই আপনার ডাটাবেসের অধিকাংশ জায়গা দখল করে থাকে, তবে প্রজেক্টটি এর জন্য একটি কম্প্রেসার প্রকাশ করেছে, rust-synapse-compress-state, যা কোনো রুমের স্টেটের অর্থ পরিবর্তন না করেই স্টেট গ্রুপের হায়ারার্কিকে কম সারিতে পুনর্লিখন করে। এটি Rust দিয়ে তৈরি:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c হলো এটি একসাথে কতগুলো স্টেট গ্রুপের ওপর কাজ করবে এবং -n হলো এই রানটি কতগুলো চাঙ্ক প্রসেস করবে। অটো কম্প্রেসারটি কতদূর কাজ করেছে তা রেকর্ড করে রাখে, তাই পরবর্তী রান সেখান থেকেই শুরু হয়, যা এটিকে শিডিউল করার জন্য নিরাপদ করে তোলে। এর ডকুমেন্টেশনে উল্লেখ আছে যে পরিবর্তনগুলো অ্যাপেন্ড-অনলি (append-only) টেবিলের বিপরীতে ট্রানজ্যাকশনে প্রয়োগ করা হয়, তাই Synapse চালু থাকা অবস্থায় এটি চালানো সম্ভব। তবে প্রথমবার চালানোর আগে অবশ্যই ডাটাবেসের ব্যাকআপ নিন।

Postgres-এর একটি বিষয় এখানে মানুষকে অবাক করে। সারি ডিলিট করলে তা Postgres-কে পুনরায় ব্যবহারের জন্য জায়গা ফিরিয়ে দেয়, ফাইল সিস্টেমে নয়, তাই বড় ধরনের কমপ্যাকশনের পরেও df হয়তো কমবে না। VACUUM FULL এটি ফিরিয়ে দেয়, এবং এটি টেবিলের ওপর একটি এক্সক্লুসিভ লক নেয় এবং টেবিলের আকারের সমান ফ্রি ডিস্ক স্পেসের প্রয়োজন হয়, তাই এটিকে হুটহাট না চালিয়ে রক্ষণাবেক্ষণ বা মেইনটেন্যান্স হিসেবে শিডিউল করুন।

সার্ভার সচল আছে কি না তা যাচাই করার পদ্ধতি

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

সার্ভার সচল থাকার অর্থ হলো unit-টি active অবস্থায় আছে এবং বারবার restart হচ্ছে না, delegation file আপনার m.server মান প্রদান করছে, federation version endpoint থেকে JSON রেসপন্স আসছে এবং দুটি size সংখ্যা গত মাসের তথ্যের সাথে তুলনা করা যাচ্ছে। অনেকেই size যাচাই করার ধাপটি এড়িয়ে যান, কিন্তু ডিস্ক পূর্ণ হয়ে যাওয়া এমন একটি সমস্যা যা কোনো সতর্কতা ছাড়াই Synapse সার্ভারকে অচল করে দিতে পারে: volume পূর্ণ হয়ে গেলে Postgres আর কোনো ডেটা লিখতে পারে না, ফলে Synapse তখন ডেটাবেস সংশ্লিষ্ট প্রতিটি অনুরোধ প্রত্যাখ্যান করে।

FAQ

Matrix Synapse সার্ভারের জন্য কতটুকু RAM প্রয়োজন?

কয়েকজন ব্যবহারকারী, ছোট রুম এবং কোনো বড় পাবলিক রুম নেই এমন একটি ব্যক্তিগত homeserver-এর জন্য 2 GB RAM যথেষ্ট। আগস্ট 2026 অনুযায়ী বেশিরভাগ সাইজিং গাইড এই পরিমাণটিই সুপারিশ করে। তবে আপনার ব্যবহারকারীরা যদি #matrix:matrix.org-এর মতো বড় পাবলিক রুমে যোগ দেন, তবে Synapse ডকুমেন্টেশন অনুযায়ী অতিরিক্ত অন্তত 1 GB RAM প্রয়োজন। কারণ সেক্ষেত্রে আপনার সার্ভারকে ওই রুমের স্টেট সংরক্ষণ করতে হয় এবং ক্রমাগত ট্রাফিক প্রসেস করতে হয়। 2 GB RAM-এর প্ল্যানে অবশ্যই swap ব্যবহার করুন, যাতে একটি বড় রুমে যোগ দেওয়ার সময় kernel যেন প্রসেসটিকে kill না করে।

আমার কি SQLite-এর পরিবর্তে PostgreSQL ব্যবহার করা বাধ্যতামূলক?

কয়েকজন ব্যবহারকারীর বেশি হলে হ্যাঁ। SQLite-এ একসাথে কেবল একজন রাইটার কাজ করতে পারে, তাই লোড বাড়লে federation ট্রাফিক এবং ক্লায়েন্টের অনুরোধ একে অপরকে আটকে দেয় এবং অনুরোধগুলো কয়েক সেকেন্ড পর্যন্ত ঝুলে থাকে। Synapse-এর worker প্রসেসগুলো, যা একাধিক CPU কোর ব্যবহারের সমর্থিত উপায়, সেগুলোর জন্য Postgres প্রয়োজন। পরবর্তীতে মাইগ্রেট করা সম্ভব এবং এর জন্য synapse_port_db ব্যবহার করা যায়, তবে এতে downtime হয়। তাই ব্যবহারকারী আসার আগেই --encoding=UTF8 --locale=C --template=template0 দিয়ে ডাটাবেস তৈরি করে নিন।

আমার Synapse-এর ডিস্ক ব্যবহার কেন ক্রমাগত বাড়ছে?

এর কারণ একটি ডিরেক্টরি এবং একটি টেবিল। media store আপনার সার্ভারের রুমগুলোতে আপলোড করা প্রতিটি ফাইল সংরক্ষণ করে, যার মধ্যে রিমোট ব্যবহারকারীদের মিডিয়ার ক্যাশ কপি এবং তৈরি করা থাম্বনেইলও থাকে। আপনি media_retention সেট না করা পর্যন্ত এগুলো ডিলিট হয় না। ফেডারেশন সার্ভারে রুম স্টেটের কারণে state_groups_state টেবিলটি বড় হতে থাকে এবং rust-synapse-compress-state এটি কমাতে সাহায্য করে। কোনটি নিয়ে কাজ করবেন তা ঠিক করার আগে আপনার media_store_path-এ du -sh এবং SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); ব্যবহার করে উভয়ই পরিমাপ করুন।

অপরিচিতদের আমার homeserver-এ রেজিস্ট্রেশন করা কীভাবে বন্ধ করব?

enable_registration-কে এর ডিফল্ট মান false-এ রাখুন এবং register_new_matrix_user ব্যবহার করে অ্যাকাউন্ট তৈরি করুন। যখন এটি আর কার্যকর থাকবে না, তখন enable_registration: true-এর সাথে registration_requires_token: true সেট করুন এবং POST /_synapse/admin/v1/registration_tokens/new-এর মাধ্যমে তৈরি করা টোকেন ব্যবহারকারীদের দিন। শুধুমাত্র Synapse-এর স্টার্টআপ এরর এড়ানোর জন্য enable_registration_without_verification: true সেট করবেন না। কারণ একটি উন্মুক্ত homeserver স্প্যামের উৎস হয়ে উঠতে পারে এবং অন্যান্য অ্যাডমিনিস্ট্রেটররা আপনার পুরো ডোমেইনকে ব্লক করে দিতে পারে।

আমার homeserver কি ফেডারেশন করবে?

ফেডারেশন একটি সচেতন সিদ্ধান্ত, এটি ডিফল্ট কোনো বিষয় নয়। যদি আপনার ব্যবহারকারীদের অন্য homeserver-এর মানুষের সাথে যোগাযোগ করার প্রয়োজন হয়, তবেই ফেডারেশন চালু করুন। যদি সার্ভারটি কেবল একটি নির্দিষ্ট টিমের জন্য হয়, তবে এটি বন্ধ রাখুন। কারণ ফেডারেশন ছাড়া সার্ভারে ডাটা কম জমা হয়, ট্রাফিক কম আসে এবং অপব্যবহারের ঝুঁকি অনেক কম থাকে। মাঝামাঝি কোনো সমাধানের জন্য federation_domain_whitelist ব্যবহার করে নির্দিষ্ট পার্টনার ডোমেইনের সাথে ফেডারেশন সীমাবদ্ধ করা যায়। তবে Synapse ডকুমেন্টেশন অনুযায়ী, শুধুমাত্র অ্যাপ্লিকেশন লেয়ারের চেকের ওপর নির্ভর না করে ফেডারেশন লিসেনারকে firewall-এর মাধ্যমে সুরক্ষিত রাখাই শ্রেয়।