SSD Nodes Learn 🎉 VPS $5.50/மாதம் முதல்
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-16

VPS-ல் Matrix Synapse-ஐ நிறுவி பராமரிப்பது எப்படி?

VPS-ல் Matrix Synapse homeserver-ஐ வெற்றிகரமாக இயக்க தேவையான Postgres அமைப்பு, media retention, registration பாதுகாப்பு மற்றும் முறையான backup முறைகளை இந்த வழிகாட்டி விளக்குகிறது.

Matrix Synapse homeserver-ஐ பராமரிப்பதற்கான தேவைகள்

Matrix Synapse-ஐ நிறுவுவது எளிது, ஆனால் அதைப் பராமரிக்காமல் விடுவதும் எளிது. இதன் நிறுவல் என்பது ஒரு apt repository, ஒரு config file, ஒரு reverse proxy block மற்றும் ஒரு DNS record ஆகியவற்றை உள்ளடக்கியது. ஒரு வருடத்திற்கு homeserver-ஐ ஆரோக்கியமாக வைத்திருப்பது வேறுபட்ட பணியாகும்: முறையான database, அவ்வப்போது சுத்தம் செய்யப்படும் media store, அந்நியர்கள் பயன்படுத்த முடியாதவாறு தடுக்கப்பட்ட registration, மற்றும் server-ன் இரண்டு பகுதிகளையும் உள்ளடக்கிய backup ஆகியவை அவசியம்.

இந்த வழிகாட்டி Ubuntu 24.04 LTS-ஐ அடிப்படையாகக் கொண்டது. இது matrix.org apt repository-லிருந்து Synapse-ஐ நிறுவுகிறது; இதுவே Debian மற்றும் Ubuntu-விற்காக Synapse திட்டத்தால் பராமரிக்கப்படும் package source ஆகும். Package பதிப்புகள் சில வாரங்களுக்கு ஒருமுறை மாறுவதால், இங்கே எந்த பதிப்பு எண்ணும் குறிப்பிடப்படவில்லை. கீழே உள்ள ஒவ்வொரு path மற்றும் option-ம் தற்போதைய Synapse ஆவணங்களிலிருந்து பெறப்பட்டவை.

அளவு நிர்ணயம்: 1 vCPU மற்றும் 2 GB RAM உண்மையில் எதை வழங்குகிறது

ஆகஸ்ட் 2026 நிலவரப்படி, வெளியிடப்பட்ட அளவு நிர்ணயப் பக்கங்கள் பொதுவாக ஒரு Synapse homeserver-க்கு 1 vCPU மற்றும் 2 GB RAM-ஐப் பரிந்துரைக்கின்றன. ஒரு தனிப்பட்ட server, சில பயனர்கள், சிறிய அறைகள் மற்றும் பரபரப்பான பொது அறைகள் இல்லாத சூழலுக்கு இது உண்மையானது. மற்ற சூழல்களைப் பொறுத்தவரை Synapse ஆவணங்கள் நேரடியாகவே கூறுகின்றன. "#matrix:matrix.org போன்ற பெரிய பொது அறைகளில் இணைய விரும்பினால், குறைந்தது 1GB இலவச RAM தேவை" என்று அது குறிப்பிடுகிறது. Python, Postgres மற்றும் kernel-க்கு மேலதிகமாக இந்த இலவச RAM தேவைப்படுகிறது.

ஒரு அறையில் இணைவது எப்படிச் செயல்படுகிறது என்பதன் காரணமாக, ஒரு அறை உங்கள் server-ன் அளவுத் தேவையை மாற்றக்கூடும். ஒரு local பயனர் ஒரு அறையில் இணையும்போது, உங்கள் homeserver அந்த அறையின் முழுப் பங்கேற்பாளராக மாறுகிறது. அந்த அறையில் உள்ள மற்ற அனைத்து server-களிலிருந்தும் ஒவ்வொரு நிகழ்வையும் (event) அது பெறுகிறது, ஒவ்வொன்றின் கையொப்பத்தையும் (signature) சரிபார்க்கிறது, மேலும் அந்த அறையின் நிலையை (state) உள்ளூரில் சேமிக்கிறது. ஒரு பெரிய பொது அறையில் நூற்றுக்கணக்கான server-களில் பரவியுள்ள ஆயிரக்கணக்கான உறுப்பினர்கள் இருப்பார்கள், எனவே உங்கள் பயனர் அந்த அறையை மீண்டும் திறக்கிறாரோ இல்லையோ, உங்கள் server அந்த வேலையைத் தொடர்ந்து செய்துகொண்டே இருக்கும். அறையை விட்டு வெளியேறுவது, நீங்கள் ஏற்கனவே சேமித்து வைத்திருக்கும் வரலாற்றை நீக்காது.

Synapse-ன் பெரும்பாலான RAM cache-களுக்குச் செல்கிறது. caches பகுதியில் அனைத்து cache-களையும் ஒரே நேரத்தில் அளவிடக்கூடிய ஒரு global_factor உள்ளது, மேலும் SYNAPSE_CACHE_FACTOR environment variable-ம் இதையே செய்கிறது. இதை அதிகரிப்பது database queries-ஐத் தவிர்க்க RAM-ஐப் பயன்படுத்தும். இதைக் குறைப்பது RAM-ஐச் சேமிக்க CPU மற்றும் Postgres நேரத்தைப் பயன்படுத்தும். Postgres-க்குத் தனியாக நினைவகம் தேவை, எனவே 2 GB கொண்ட ஒரு server-ல் இவை இரண்டும் ஒரே மெகாபைட்டுகளுக்காகப் போட்டியிடுகின்றன.

சிறிய திட்டத்திற்கு இரண்டு நடைமுறை விதிகள் உள்ளன. Swap-ஐச் சேர்க்கவும்: swap, Synapse-ஐ வேகமாக்காது, ஆனால் ஒரு பெரிய இணைப்பின் போது kernel அந்தச் செயல்முறையை (process) நிறுத்துவதைத் தடுக்கும். பின்னர் முதல் வாரத்திலிருந்தே disk-ஐக் கவனிக்கவும், ஏனெனில் media store மற்றும் room state tables ஆகிய இரண்டும் வரம்பின்றி வளரக்கூடியவை, இவை இரண்டுமே disk-ல் தான் சேமிக்கப்படுகின்றன.

Postgres ஏன் தேவை, SQLite ஏன் போதுமானதாக இருக்காது

Debian package ஆரம்பத்தில் SQLite-ஐப் பயன்படுத்துகிறது. இது முதல்முறை தொடங்குவதற்குச் சரியாக இருக்கும், ஆனால் பிற பயனர்கள் பயன்படுத்தும் server-க்கு இது உகந்ததல்ல. SQLite ஒரே நேரத்தில் ஒரு எழுதும் செயலை (writer) மட்டுமே அனுமதிக்கும். Federation traffic மற்றும் client கோரிக்கைகள் ஒரே நேரத்தில் எழுத முயலும்போது, ஒரு மெதுவான கோரிக்கைக்காக மற்ற கோரிக்கைகள் காத்திருக்க வேண்டியிருக்கும். இதனால், பயன்பாடு அவ்வப்போது சில நொடிகள் முடங்கியது போன்ற உணர்வை பயனர்கள் பெறுவார்கள்.

இரண்டாவது காரணம் கட்டமைப்பு சார்ந்தது. Synapse-ன் worker processes மட்டுமே ஒன்றுக்கும் மேற்பட்ட CPU core-களைப் பயன்படுத்த அனுமதிக்கப்பட்ட வழியாகும், இதற்கு Postgres அவசியம். SQLite-லேயே தொடர்வது செயல்திறனைப் பாதிப்பதோடு, எதிர்கால மேம்பாட்டு வாய்ப்புகளையும் (upgrade path) இழக்கச் செய்யும்.

பிற்காலத்தில் இடம்பெயர்வு (migration) செய்ய முடியும் என்றாலும், அதற்கு downtime தேவைப்படும். எனவே, பயனர்கள் சேரும் முன்பே இதைச் செய்வது நல்லது. Synapse synapse_port_db-ஐ வழங்குகிறது, இது SQLite database-ஐ ஏற்கனவே தயார் செய்யப்பட்ட Postgres database-க்கு நகலெடுக்கும்:

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

நீங்கள் database-ஐ Synapse-க்கு அருகில் ஒரு container-ல் இயக்க விரும்பினால், அதன் சாதக பாதகங்களை Docker-ல் அல்லது host-ல் database-ஐ இயக்குதல் பகுதியில் காணலாம்.

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 திட்டக்குழு இதைத் தவிர்க்குமாறு அறிவுறுத்துகிறது, ஏனெனில் அந்தப் பதிப்புகள் அதன் releases-ஐ விடப் பின்தங்கியுள்ளன மற்றும் அவற்றில் அறியப்பட்ட security bugs உள்ளன.

நிறுவி (installer) உங்களிடம் server name-ஐக் கேட்கும், அது உங்கள் பதிலை /etc/matrix-synapse/conf.d/server_name.yaml கோப்பில் எழுதும். கவனமாகப் பதிலளிக்கவும். server_name என்பது ஒவ்வொரு user ID-யிலும் (@alice:example.com) கோலனுக்குப் பிறகு வரும் பகுதியாகும், மேலும் இது உங்கள் server உருவாக்கும் ஒவ்வொரு room-லும் உட்பொதிக்கப்பட்டிருக்கும். இதைத் தள்ளி மாற்றினால் எதையும் நகர்த்த முடியாது: அது ஒரு புதிய homeserver-ஐ உருவாக்கும். Synapse-ஐ matrix.example.com-ல் இயக்கினாலும், உங்கள் bare domain-ஆன example.com-ஐப் பயன்படுத்தவும். Delegation மூலம் இரண்டையும் இணைக்கலாம், அது அடுத்த பகுதியில் விளக்கப்பட்டுள்ளது.

இந்தத் தொகுப்பு Synapse-ஐ matrix-synapse user-ஆக இயக்குகிறது, அதன் தரவுகளை /var/lib/matrix-synapse-ல் வைத்திருக்கிறது, மேலும் /etc/matrix-synapse/homeserver.yaml கோப்பையும், அதைத் தொடர்ந்து /etc/matrix-synapse/conf.d/-ல் உள்ள அனைத்துக் கோப்புகளையும் படிக்கிறது. உங்கள் சொந்த அமைப்புகளை conf.d-ல் சிறிய கோப்புகளாகச் சேமிக்கவும். தொகுப்பு மேம்படுத்தல்களின் (package upgrades) போது இவை மாற்றப்படாது.

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

சரியான தொடக்கம் listeners-ஐ இயக்கிவிட்டு அமைதியாகிவிடும். ஏதேனும் ஒரு exit-க்குப் பிறகு, systemd unit சில வினாடிகளில் service-ஐ மீண்டும் தொடங்கும். எனவே, Synapse நிராகரிக்கும் ஒரு configuration இருந்தால், அந்த unit தொடங்கி உடனே நின்றுவிடும் சுழற்சி (loop) ஏற்படும். journal-ன் கடைசி வரிகள் அது நிராகரித்த key-ஐக் குறிப்பிடும்.

Postgres-ஐ Synapse உடன் இணைத்தல்

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 என்பது வெறும் அலங்காரமானது அல்ல. வெவ்வேறு COLLATE மற்றும் CTYPE மதிப்புகளைக் கொண்டு உருவாக்கப்பட்ட database-ல் Synapse தொடங்க மறுக்கும். நீங்கள் database configuration-ல் allow_unsafe_locale-ஐ அமைக்கவில்லை என்றால், இதைச் சரிசெய்ய database-ஐ dump செய்து, சரியாக உருவாக்கப்பட்ட புதிய database-ல் reload செய்ய வேண்டியிருக்கும். எனவே, முதல் முறையே சரியாக உருவாக்கவும்.

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

உங்கள் அனைத்து configuration கோப்புகளிலும் ஒரே ஒரு database: key-ஐ மட்டும் வைத்திருக்கவும். conf.d-ன் கீழ் இரண்டாவது நகலைச் சேர்ப்பதற்குப் பதிலாக, homeserver.yaml-க்குள் உள்ள SQLite தொகுதியை மாற்றவும். இதன் மூலம், எந்த configuration செயல்பாட்டில் உள்ளது என்பதில் குழப்பம் ஏற்படாது. Restart செய்த பிறகு, Synapse உண்மையில் Postgres-ல் இயங்குகிறதா என்பதை உறுதிப்படுத்தவும்:

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

ஒரு எண் கிடைத்தால், Synapse இந்த database-ல் தனது schema-வை உருவாக்கியுள்ளது என்று அர்த்தம். ஒரு relation காணவில்லை என்ற பிழை வந்தால், அது இன்னும் SQLite கோப்பிலேயே எழுதுகிறது என்று பொருள். எனவே, நீங்கள் திருத்திய configuration கோப்பு பயன்பாட்டில் இல்லை.

Reverse proxy, TLS மற்றும் .well-known கோப்புகளின் கூட்டமைப்புத் தேவைகள்

Synapse ஆனது localhost-ல் port 8008-ல் plain HTTP மூலம் இயங்குகிறது. TLS மற்றும் பொதுவான port ஆகியவை அதற்கு முன்னால் உள்ள 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 என்பது proxy அமைக்கும் X-Forwarded-For header-ஐ Synapse நம்ப வேண்டும் என்று கூறுகிறது. இது இல்லையெனில், அனைத்து client-களும் 127.0.0.1-லிருந்து வருவது போலத் தோன்றும். இதனால் rate limiting ஒரு பிஸியான local user-ஆகக் கருதி அனைவரையும் ஒரே நேரத்தில் கட்டுப்படுத்தும்.

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

இந்த block குறித்து Synapse ஆவணங்கள் ஒரு எச்சரிக்கையை வழங்குகின்றன, இது பலருக்கு நாட்களை வீணாக்குகிறது. proxy_pass-ல் உள்ள port-க்கு பிறகு எந்தவொரு path-ஐயும், ஒரு /-ஐக் கூட சேர்க்க வேண்டாம். அவ்வாறு செய்தால், nginx அந்த URI-ஐ canonicalise செய்யும். இது அனுப்பும் server கையொப்பமிட்ட bytes-ஐ மாற்றிவிடும், இதனால் federation கோரிக்கைகள் signature சரிபார்ப்பில் தோல்வியடையும், அதே சமயம் சாதாரண client கோரிக்கைகள் தொடர்ந்து செயல்படும்.

client_max_body_size ஆனது Synapse-ன் max_upload_size-க்கு இணையாகவோ அல்லது பெரியதாகவோ இருக்க வேண்டும். nginx-ல் சிறிய எண் இருந்தால், அதைவிட அதிகமான அளவுள்ள பதிவேற்றங்களை nginx 413 Request Entity Too Large மூலம் நிராகரித்துவிடும். Synapse-க்கு அந்த கோரிக்கைகள் வராததால், தோல்விக்கான காரணத்தை விளக்கும் log வரி எதுவும் Synapse-ல் இருக்காது.

Certificate-க்கு, Certbot and Let's Encrypt on Ubuntu 24.04 என்பதைப் பின்பற்றவும். proxy-ஐத் தேர்ந்தெடுப்பதில் குழப்பம் இருந்தால், reverse proxy comparison எந்த proxy உங்களுக்கு TLS பணிகளைச் செய்யும் என்பதை விளக்கும்.

Synapse matrix.example.com-ல் இயங்கும்போது, server_name-ஐ example.com-ஆக வைத்திருக்க உதவுவதுதான் delegation. bare domain-லிருந்து இரண்டு கோப்புகளை வழங்கவும்:

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

server கோப்பு, federation traffic-ஐ எங்கு அனுப்ப வேண்டும் என்று மற்ற homeserver-களுக்குத் தெரிவிக்கிறது. இதன் மூலமே federation இயல்பான port 8448-க்கு பதிலாக 443-ல் இயங்குகிறது. client கோப்பு, Matrix client-களுக்கு @alice:example.com-க்கு பின்னால் எந்த URL உள்ளது என்று தெரிவிக்கிறது. client கோப்பில் Access-Control-Allow-Origin header முக்கியமானது, ஏனெனில் browser-அடிப்படையிலான client-கள் இதை cross-origin மூலம் பெறுகின்றன. இந்த header இல்லையெனில், browser பதிலை block செய்துவிடும், மேலும் உங்கள் homeserver-ஐக் கண்டறிய முடியவில்லை என்று client தெரிவிக்கும்.

இரண்டு கோப்புகளும் example.com-லிருந்து செல்லுபடியாகும் TLS மூலம் வழங்கப்பட வேண்டும். அவற்றைச் சரிபார்த்து, வெளி உலகம் எதைப் பார்க்கிறது என்பதை உறுதிப்படுத்தவும்:

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

முதல் கட்டளை நீங்கள் எழுதிய JSON-ஐத் திருப்பித் தரும். இரண்டாவது கட்டளை server-ன் விவரம் மற்றும் அதன் version-ஐக் கொண்ட JSON object-ஐத் தரும். இது proxy-ஆனது federation path வழியாக Synapse-ஐ அடைகிறது என்பதை உறுதிப்படுத்துகிறது. இறுதியாக, https://federationtester.matrix.org-ல் உள்ள Matrix federation tester மூலம் உங்கள் domain-ஐச் சரிபார்க்கவும். இது ஒரு உண்மையான remote server பின்பற்றும் அதே பாதையைப் பின்பற்றும்.

Federation-ஐ செயல்படுத்துவதா வேண்டாமா: திட்டமிட்டு முடிவெடுங்கள்

Matrix-ன் முக்கிய நோக்கமே Federation தான், ஆனால் இதுவே அதிக செலவுக்கும் காரணமாகிறது. ஒரு Federation homeserver, உங்களுக்குத் தெரியாத பிற server-களிலிருந்து வரும் இணைப்புகளை ஏற்றுக்கொள்கிறது, அவற்றின் events-ஐப் பெறுகிறது, media-வை cache செய்கிறது, மேலும் உங்கள் பயனர்கள் இணையும் ஒவ்வொரு room-ன் state-ஐயும் சேமிக்கிறது. இது ஒரு இயல்பான அம்சம் அல்ல, மாறாக இது ஒரு threat model சார்ந்த முடிவாகும்.

உங்கள் பயனர்கள் பிற homeserver-களில் உள்ளவர்களைத் தொடர்பு கொள்ள வேண்டியிருக்கும்போதோ அல்லது ஒரு portable identity-க்காக நீங்கள் Matrix-ஐத் தேர்ந்தெடுத்திருந்தாலோ Federation-ஐச் செயல்படுத்துங்கள். ஒரு குறிப்பிட்ட குழுவிற்காக மட்டும் server இயங்குகிறது மற்றும் அதில் உள்ள அனைத்து account-களும் உங்களுடையது என்றால், Federation-ஐத் தவிர்க்கவும். ஒரு closed server குறைந்த தரவையே சேமிக்கிறது, குறைந்த தரவையே பெறுகிறது, மேலும் அதைத் தவறாகப் பயன்படுத்துவதற்கான வாய்ப்பும் மிகக் குறைவு.

முழுமையாக முடக்குவதற்குப் பதிலாகக் கட்டுப்படுத்த, Synapse ஒரு allow list-ஐப் பயன்படுத்துகிறது:

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

Federation listener-க்கு firewall அமைப்பதையும் ஆவணங்கள் பரிந்துரைக்கின்றன, இதன் மூலம் தேவையற்ற traffic Python-க்குள் நுழையும் முன்பே network மட்டத்திலேயே தடுக்கப்படும். Federation-ஐ முழுமையாக நிறுத்த, listener resources பட்டியலிலிருந்து federation-ஐ நீக்கவும், /.well-known/matrix/server-ஐ publish செய்ய வேண்டாம், மேலும் port 8448-ஐ மூடி வைக்கவும்.

Matrix-ஐப் பயன்படுத்தியதன் நோக்கம் ஒரு தனிப்பட்ட குழு உரையாடல் (private team chat) மட்டுமே என்றால், Federation அதில் ஒரு பகுதியாக இல்லை என்றால், Synapse-ல் உறுதியாக முடிவெடுக்கும் முன், பிற self-hosted Slack மாற்றுகளுடன் அதன் செயல்பாட்டுச் செலவை ஒப்பிட்டுப் பாருங்கள். Rocket.Chat on Docker Compose, பிற நிறுவனங்களின் room state-ஐச் சேமிக்க வேண்டிய அவசியம் இல்லாததால், சிறிய machine-களிலேயே குழு உரையாடல்களைச் சிறப்பாகக் கையாளும்.

மீடியா களஞ்சியம் (media repository) வட்டை நிரப்பும் விதம்

உங்கள் பயனர்கள் பதிவேற்றும் கோப்புகள் உங்கள் வட்டில் நிரந்தரமாகத் தங்கிவிடும். பிற homeserver-களில் உள்ள பயனர்கள் பதிவிடும் கோப்புகள், உங்கள் client-களில் ஏதேனும் ஒன்று அவற்றைக் காட்டியவுடன் உங்கள் வட்டில் பதிவிறக்கம் செய்யப்பட்டு cache செய்யப்படும். மேலும், Synapse படங்களுக்கான thumbnails-ஐ உருவாக்குவதால், ஒரு புகைப்படம் பல கோப்புகளாக மாறுகிறது. இயல்பாக, இதில் எதற்கும் காலாவதி காலம் (expiry) கிடையாது.

களஞ்சியத்தைக் கண்டறிந்து அதன் அளவைச் சரிபார்க்கவும்:

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

உங்கள் config கோப்பில் குறிப்பிடப்பட்டுள்ள பாதையை அளவிடவும். Debian தொகுப்பு Synapse-ன் தரவுகளை /var/lib/matrix-synapse-ல் வைத்திருக்கும், எனவே களஞ்சியம் பொதுவாக அங்கேயே இருக்கும். பின் conf.d-ல் retention policy-ஐ அமைக்கவும்:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

அந்த இரண்டு வரிகளையும் கவனமாகப் படிக்கவும், ஏனெனில் அவை ஒரே மாதிரியான அமைப்புகள் அல்ல. remote_media_lifetime ஒரு cache-ஐ காலாவதியாக்குகிறது, அது நீக்கும் எதையும் கோப்பின் உரிமையாளராக உள்ள server-லிருந்து மீண்டும் பெற்றுக்கொள்ள முடியும். local_media_lifetime உங்கள் பயனர்களின் பதிவேற்றங்களை ஒரு குறிப்பிட்ட காலத்திற்குப் பிறகு நிரந்தரமாக நீக்கிவிடும். அரட்டையில் ஆவணங்களைப் பகிர்ந்து, அடுத்த ஆண்டு அவற்றைப் பார்க்கலாம் என்று எதிர்பார்க்கும் குழுவினர் அவற்றை இழக்க நேரிடும். பல server-கள் remote மதிப்பினை மட்டுமே அமைக்கின்றன.

ஒருமுறை மட்டும் சுத்தம் செய்ய (one-off cleanup), admin 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 அந்த timestamp-க்கு முன்பு கடைசியாக அணுகப்பட்ட remote media cache-ஐ நீக்குகிறது. POST /_synapse/admin/v1/media/delete?before_ts=<ms> அதே விதியின்படி local media-வை நீக்குகிறது. முதலில் remote purge-ஐ இயக்கிவிட்டு மீண்டும் அளவிடவும், ஏனெனில் federating server-ல் remote cache பொதுவாக அதிக இடத்தை ஆக்கிரமித்திருக்கும்.

இரண்டு அமைப்புகள் ஒரே வட்டைப் பயன்படுத்துகின்றன. max_upload_size ஒரு பதிவேற்றத்தின் அளவைக் கட்டுப்படுத்துகிறது, இது nginx-ல் உள்ள client_max_body_size-உடன் ஒத்துப்போக வேண்டும். url_preview_enabled: true உங்கள் server-ஐ remote பக்கங்களைப் பதிவிறக்கச் செய்கிறது, இதனால் clients link previews-ஐக் காட்ட முடியும். இது bandwidth-ஐப் பயன்படுத்துவதோடு, யாரும் உங்களுக்குப் பதிவேற்றாத உள்ளடக்கத்தின் thumbnails-ஐயும் சேமிக்கிறது.

உங்கள் homeserver-ஐ யாராவது கண்டறிவதற்கு முன்பே பதிவுகளை மூடிவிடுங்கள்

திறந்த நிலையில் உள்ள homeserver-களை ஸ்கேனர்கள் சில நாட்களிலேயே கண்டறிந்துவிடும். கணக்குகளை யார் வேண்டுமானாலும் உருவாக்கும்படி இருந்தால், உங்கள் server அது இணைக்கப்பட்டுள்ள அனைத்து அறைகளிலும் spam பரப்பும் இடமாக மாறிவிடும்; இதனால் மற்ற server-களின் நிர்வாகிகள் உங்கள் முழு domain-ஐயும் block செய்துவிடுவார்கள். அந்த block பட்டியல்கள் மனிதர்களால் நிர்வகிக்கப்படுவதால், நீங்கள் spam-ஐ நீக்கினாலும் அந்த பாதிப்பு நீண்ட காலம் நீடிக்கும்.

Synapse இயல்பாகவே மூடப்பட்ட நிலையில் (closed) வெளிவருகிறது. enable_registration என்பது false என்றும், registration_requires_token என்பது false என்றும் இயல்பாக அமைக்கப்பட்டுள்ளன. மேலும், enable_registration_without_verification: true-ஐ அமைக்காமல், சரிபார்ப்பு முறை (verification step) ஏதுமின்றி பதிவுகளைத் திறந்தால் Synapse தொடங்க மறுக்கும். இந்த மறுப்பு வேண்டுமென்றே செய்யப்பட்டுள்ளது, எனவே startup பிழையைத் தவிர்க்க அதை மாற்ற வேண்டாம்.

உங்களுக்குத் தேவையான கணக்குகளை நீங்களே கைமுறையாக உருவாக்குங்கள்:

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

இது பயனர் பெயர், கடவுச்சொல் மற்றும் அந்த கணக்கு server admin-ஆ என்பதை வினவும். இது நீங்கள் -c மூலம் வழங்கும் config-லிருந்து registration_shared_secret-ஐ வாசிக்கும். எனவே, shared secret-ஐக் கண்டறிய முடியவில்லை என்று பிழை காட்டினால், அதை வைத்திருக்கும் கோப்பை -c மூலம் சுட்டிக்காட்டவும்.

கணக்குகளை கைமுறையாக உருவாக்குவது கடினமாகும்போது, registration tokens-ஐப் பயன்படுத்தலாம். ஒரு புதிய பயனர் signup செய்யும்போது சமர்ப்பிக்க வேண்டிய குறியீடே token ஆகும். ஒவ்வொரு token-க்கும் அது எத்தனை முறை பயன்படுத்தப்படலாம் என்ற வரம்பை அமைக்கலாம்:

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-ஐ body-ல் குறிப்பிடாமல் விட்டால், Synapse ஒரு token-ஐ உருவாக்கித் தரும். GET /_synapse/admin/v1/registration_tokens தற்போது செயல்பாட்டில் உள்ள token-களின் பட்டியலைக் காட்டும். இந்த இரண்டு செயல்பாடுகளுக்கும் server admin கணக்கின் access token தேவைப்படும். மேலே நீங்கள் உருவாக்கிய admin பயனராக login செய்வதன் மூலம் அந்த token-ஐப் பெறலாம்.

ஏற்கனவே பிற இடங்களில் கணக்குகளை நிர்வகிக்கும் ஒரு நிறுவனம், local கடவுச்சொற்களைத் தவிர்க்கலாம். ஏனெனில் Synapse-ன் login செயல்பாட்டை OIDC (OpenID Connect) provider-க்கு மாற்ற முடியும். உதாரணமாக, Authentik-ஐ self-hosted SSO provider-ஆகப் பயன்படுத்துதல். இதன் மூலம் புதிய பயனர்களைச் சேர்ப்பதும், நீக்குவதும் ஒரே இடத்தில் கையாளப்படும்.

server-ஐ மீண்டும் கட்டமைக்கக்கூடிய ஒரு backup

Synapse backup-ல் மூன்று பகுதிகள் உள்ளன. இதில் ஏதேனும் ஒன்று விடுபட்டாலும், அந்த backup-ஐக் கொண்டு பயன்பாட்டுக்கு உகந்த ஒரு server-ஐ உருவாக்க முடியாது.

  • Postgres database: இது அனைத்து events, accounts மற்றும் rooms-ஐயும் கொண்டிருக்கும்.
  • media store directory: இது பதிவேற்றப்பட்ட அனைத்து கோப்புகளையும் கொண்டிருக்கும்.
  • /etc/matrix-synapse: இது உங்கள் config மற்றும் server-ன் signing key-ஐக் கொண்டிருக்கும்.

signing key என்பது பலரும் மறக்கும் ஒரு பகுதியாகும். இது உங்கள் homeserver நிகழ்வுகளை (events) கையொப்பமிடப் பயன்படுத்தும் private key ஆகும். தொலைதூர server-கள் இந்த நிகழ்வுகளைச் சரிபார்க்க, அதனுடன் தொடர்புடைய public key-ஐப் பயன்படுத்தும். உங்கள் key எங்குள்ளது என்பதை அறிய grep signing_key_path /etc/matrix-synapse/homeserver.yaml-ஐ இயக்கவும். இதை நீங்கள் தொலைத்துவிட்டால், உங்கள் rooms-க்கு ஏற்கனவே தெரிந்த அதே server தான் இது என்பதை நிரூபிக்க முடியாத ஒரு server-ஐயே உங்களால் மீட்டெடுக்க முடியும்.

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

முதலில் database-ஐ dump செய்யவும், அதன் பிறகு media store-ஐ நகலெடுக்கவும். Media கோப்புகள் ஒருமுறை மட்டுமே எழுதப்பட்டு, ID மூலம் குறிக்கப்படுகின்றன. எனவே, dump செய்த பிறகு எடுக்கப்படும் media நகலில் கூடுதல் கோப்புகள் மட்டுமே இருக்க முடியும், விடுபட்ட கோப்புகள் இருக்க வாய்ப்பில்லை. இதற்கு மாறான வரிசையில் செய்தால், உங்கள் backup-ல் இல்லாத ஒரு கோப்பை restored database தேடும் நிலை ஏற்படும்.

இந்த மூன்று பகுதிகளையும் VPS-க்கு வெளியே அனுப்பவும். restic with off-site snapshots இதற்குச் சரியாகப் பொருந்தும். ஏனெனில், media store என்பது பெரிய அளவிலான தரவுகளைக் கொண்டது மற்றும் அது அடிக்கடி மாறாது. எனவே, deduplication மூலம் ஒவ்வொரு snapshot-ம் சிறிய அளவில் இருக்கும்.

அதன்பிறகு, restore செய்வதைப் பயிற்சி செய்யவும். ஏனெனில், நீங்கள் ஒருமுறை கூட restore செய்யாத backup என்பது வெறும் அனுமானம் மட்டுமே. இரண்டாவது VPS ஒன்றை உருவாக்கி, அதே package-ஐ நிறுவி, config-ஐ restore செய்யவும். அதே encoding மற்றும் locale-உடன் database-ஐ உருவாக்கி, pg_restore மூலம் dump-ஐ அதில் ஏற்றவும். Media store-ஐ மீண்டும் நகலெடுத்து, login செய்யவும். இதற்கு எவ்வளவு நேரம் ஆனது என்பதைக் குறித்துக்கொள்ளவும். அந்த நேரமே உங்கள் உண்மையான recovery time ஆகும்.

State tables வளரும்போது: compaction

Synapse, room state-ஐ state groups-ஆகச் சேமிக்கிறது. ஒரு federating server-ல் state_groups_state பெரும்பாலும் database-ல் உள்ள மிகப்பெரிய object-ஆக மாறுகிறது. எதையும் மாற்றும் முன் அளவீடு செய்யவும்:

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

அந்த ஒரு table தான் உங்கள் database-ன் பெரும்பகுதியாக இருந்தால், அதற்காக project ஒரு compressor-ஐ வழங்குகிறது. அதுதான் rust-synapse-compress-state. இது எந்தவொரு room-ன் state பொருளையும் மாற்றாமல், state group hierarchy-ஐக் குறைவான rows-ஆக மாற்றியமைக்கிறது. இது 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 என்பது ஒரே நேரத்தில் எத்தனை state groups-ஐ இது கையாளும் என்பதையும், -n என்பது இந்த run எத்தனை chunks-ஐச் செயலாக்கும் என்பதையும் குறிக்கிறது. Auto compressor தான் எவ்வளவு தூரம் முடித்துள்ளது என்பதைப் பதிவு செய்துகொள்ளும், எனவே அடுத்த run அங்கிருந்து தொடரும். இதனால்தான் இதைத் திட்டமிடுவது பாதுகாப்பானது. இதன் ஆவணங்கள் குறிப்பிடுவது போல, மாற்றங்கள் append-only tables-க்கு எதிராக transactions மூலம் செய்யப்படுகின்றன, எனவே Synapse இயங்கிக்கொண்டிருக்கும்போதே இதை இயக்கலாம். முதல்முறை இயக்கும் முன், எதற்கும் ஒரு database backup எடுத்துக்கொள்ளவும்.

Postgres-ல் ஒரு நுணுக்கம் பலரை ஆச்சரியப்படுத்தும். Rows-ஐ நீக்கும்போது அந்த இடம் Postgres-க்கு மறுபயன்பாட்டிற்காகத் திரும்பக் கிடைக்குமே தவிர, file system-க்குத் திரும்பக் கிடைக்காது. எனவே, பெரிய compaction-க்கு பிறகும் df அளவு குறையாமல் இருக்கலாம். VACUUM FULL அதைத் திரும்பப் பெறும். இது table-ன் மீது exclusive lock-ஐ எடுக்கும் மற்றும் table-ன் அளவிற்கு இணையான free disk இடம் தேவைப்படும். எனவே, இதைத் தன்னிச்சையாக இயக்காமல், பராமரிப்புப் பணியாகத் திட்டமிட்டுச் செய்யவும்.

server ஆரோக்கியமாக இருப்பதை உறுதி செய்யும் சோதனைகள்

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

server ஆரோக்கியமாக உள்ளது என்றால், unit active நிலையில் இருக்க வேண்டும் மற்றும் அது மீண்டும் மீண்டும் restart ஆகக்கூடாது. delegation கோப்பு உங்கள் m.server மதிப்பைத் திருப்பித் தர வேண்டும், federation version endpoint ஒரு JSON-ஐத் தர வேண்டும், மேலும் இரண்டு அளவு எண்களை முந்தைய மாதத்தின் தரவுகளுடன் ஒப்பிட வேண்டும். பலரும் இந்த அளவு சோதனைகளைத் தவிர்த்துவிடுவார்கள். ஆனால், disk நிரம்பிவிடுவது Synapse server-ஐ எந்த எச்சரிக்கையும் இன்றி முடக்கிவிடும்: volume முழுமையாக நிரம்பினால் Postgres-ஆல் தரவுகளை எழுத முடியாது, அதன் பிறகு database-ஐ அணுகும் ஒவ்வொரு கோரிக்கையையும் Synapse நிராகரித்துவிடும்.

FAQ

Matrix Synapse server-க்கு எவ்வளவு RAM தேவை?

குறைந்த பயனர்கள், சிறிய அறைகள் மற்றும் பெரிய பொது அறைகள் இல்லாத ஒரு தனிப்பட்ட homeserver-க்கு 2 GB போதுமானது. ஆகஸ்ட் 2026 நிலவரப்படி, பெரும்பாலான அளவு நிர்ணய வழிகாட்டிகள் இதையே பரிந்துரைக்கின்றன. உங்கள் பயனர்கள் #matrix:matrix.org போன்ற பெரிய பொது அறைகளில் இணைந்தால், Synapse ஆவணங்கள் கூடுதலாக குறைந்தபட்சம் 1 GB RAM-ஐப் பரிந்துரைக்கின்றன. ஏனெனில், உங்கள் server அந்த அறையின் நிலையைச் சேமித்து, அதன் traffic-ஐத் தொடர்ந்து கையாள வேண்டியிருக்கும். 2 GB திட்டத்தைப் பயன்படுத்தினால், ஒரு பெரிய இணைப்பால் kernel அந்த process-ஐக் கொல்லாமல் இருக்க swap-ஐச் சேர்க்கவும்.

நான் SQLite-க்கு பதிலாக PostgreSQL-ஐப் பயன்படுத்த வேண்டுமா?

சில பயனர்களுக்கு மேல் இருந்தால், ஆம். SQLite ஒரே நேரத்தில் ஒரு எழுத்தாளரை (writer) மட்டுமே அனுமதிக்கும். இதனால், அதிக சுமை இருக்கும்போது federation traffic மற்றும் client கோரிக்கைகள் ஒன்றையொன்று தடுத்து, கோரிக்கைகள் பல நொடிகள் தாமதமாகும். ஒன்றுக்கும் மேற்பட்ட CPU core-களைப் பயன்படுத்தும் Synapse-ன் worker processes-க்கு Postgres அவசியம். பிற்காலத்தில் synapse_port_db மூலம் இடம்பெயரலாம், ஆனால் அதற்கு downtime தேவைப்படும். எனவே, பயனர்களைச் சேர்ப்பதற்கு முன்பே --encoding=UTF8 --locale=C --template=template0 மூலம் database-ஐ உருவாக்கவும்.

Synapse disk பயன்பாடு ஏன் தொடர்ந்து அதிகரிக்கிறது?

இதற்கு ஒரு directory மற்றும் ஒரு table காரணம். உங்கள் server இருக்கும் அறைகளில் பதிவேற்றப்படும் ஒவ்வொரு கோப்பையும் media store சேமிக்கும்; இதில் தொலைதூரப் பயனர்களின் media-வின் cached பிரதிகள் மற்றும் உருவாக்கப்பட்ட thumbnails-ம் அடங்கும். நீங்கள் media_retention-ஐ அமைக்கும் வரை எதுவும் நீக்கப்படாது. federating server-ல் state_groups_state table அறையின் நிலையுடன் வளர்கிறது, அதை 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 மூலம் உருவாக்கப்பட்ட tokens-ஐ வழங்கவும். Synapse தொடங்கும் போது காட்டும் பிழையைத் தவிர்க்க மட்டும் enable_registration_without_verification: true-ஐ அமைக்க வேண்டாம். ஏனெனில், திறந்த நிலையில் உள்ள homeserver spam-க்கான ஆதாரமாக மாறிவிடும்; மற்ற நிர்வாகிகள் உங்கள் domain முழுவதையும் block செய்துவிடுவார்கள்.

எனது homeserver federation செய்ய வேண்டுமா?

Federation என்பது ஒரு விருப்பத்தேர்வு, அது இயல்புநிலை அல்ல. உங்கள் பயனர்கள் பிற homeserver-களில் உள்ளவர்களைத் தொடர்பு கொள்ள வேண்டும் என்றால் federation-ஐச் செயல்படுத்தவும். ஒரு குழுவிற்கு மட்டும் server பயன்படும் என்றால், அதை அணைத்து வைக்கவும். ஏனெனில், federation இல்லாத server குறைந்த தரவையே சேமிக்கும், குறைவான traffic-ஐப் பெறும் மற்றும் குறைவான அச்சுறுத்தல்களையே சந்திக்கும். இடையில் உள்ள நிலைக்கு, federation_domain_whitelist மூலம் குறிப்பிட்ட partner domains-க்கு மட்டும் federation-ஐக் கட்டுப்படுத்தலாம். அந்த application-layer சோதனையை மட்டும் நம்பியிருக்காமல், federation listener-ஐ firewall செய்யவும் Synapse ஆவணங்கள் பரிந்துரைக்கின்றன.

#matrix#synapse#self-hosting#postgresql#federation