কনফিগারেশন

Antimatter তার সেটিংস কোথায় রাখে, সেগুলো পরিবর্তনের তিনটি উপায় (System Console, এনভাইরনমেন্ট ভেরিয়েবল, amctl), এবং লগ কোথায় যায়।

সেটিংস কোথায় থাকে

প্রতিটি সার্ভার সেটিংসের একটি নাম থাকে যা একটি সেকশন এবং একটি কী দিয়ে গঠিত, যেমন ServiceSettings.SiteURL বা EmailSettings.SMTPServer। একসাথে তারা একটি কনফিগারেশন গঠন করে, যা দুটির একটি জায়গায় সংরক্ষিত থাকে:

ডাটাবেসে। সাইটের কম্পোজ ফাইল AM_CONFIG-কে PostgreSQL কানেকশন URL-এ সেট করে, তাই কনফিগারেশনটি ডাটাবেসের একটি রো এবং কন্টেইনারটি ডিস্কে কিছু সংরক্ষণ করে না। একাধিক সার্ভার একটি ডাটাবেস শেয়ার করলে তারা তাদের কনফিগারেশনও শেয়ার করে।
একটি ফাইলে। AM_CONFIG ছাড়া, সার্ভার তার bin/ ডিরেক্টরির পাশে থাকা config/config.json ফাইলটি পড়ে (Docker ইমেজে এটি /antimatter/config/config.json)। antimatter-docker-এর রিলিজ আর্কাইভ এবং প্রোডাকশন কম্পোজ ফাইলগুলো এভাবেই কাজ করে, এবং .deb ও .rpm প্যাকেজগুলোর ফাইলটি হলো /etc/antimatter/config/config.json। এই ফাইলটি শুধুমাত্র সার্ভারের ব্যবহারকারীর জন্য পড়ার মতো রাখুন: এতে পাসওয়ার্ড এবং কী রয়েছে।

AM_CONFIG (বা antimatter কমান্ডের --config ফ্ল্যাগ) একটি ফাইল পাথ বা postgres:// URL গ্রহণ করে। যেসব সেটিংস আপনি বাদ দেন, তারা তাদের ডিফল্ট মান নেয়।

একটি বিদ্যমান কনফিগারেশন ফাইল থেকে ডাটাবেসে সরানোর জন্য, সার্ভারে এটি চালান, তারপর AM_CONFIG একই URL-এ সেট করে সার্ভার শুরু করুন:

amctl --local config migrate /opt/antimatter/config/config.json \
    "postgres://antimatter:PASSWORD@localhost:5432/antimatter?sslmode=disable&connect_timeout=10"

এনভাইরনমেন্ট ভেরিয়েবল

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

নামকরণ নিয়ম

AM_ লিখুন, তারপর সেকশন, তারপর কী, বড় অক্ষরে এবং আন্ডারস্কোর দিয়ে আলাদা করে। একটি সেকশন বা কী নামের ভেতরের শব্দগুলো আলাদা করা হয় না:

সেটিং	ভেরিয়েবল
`ServiceSettings.SiteURL`	`AM_SERVICESETTINGS_SITEURL`
`SqlSettings.DataSource`	`AM_SQLSETTINGS_DATASOURCE`
`EmailSettings.SMTPServer`	`AM_EMAILSETTINGS_SMTPSERVER`
`PrivacySettings.EnableUserBlocking`	`AM_PRIVACYSETTINGS_ENABLEUSERBLOCKING`

সত্য ও মিথ্যার সেটিংস true বা false নেয়; সংখ্যাগুলো সাধারণ সংখ্যা।
লিস্ট সেটিংস তাদের মানগুলো স্পেস দিয়ে আলাদা করে নেয়, যেমন AM_SERVICESETTINGS_TRUSTEDPROXYIPHEADER="X-Forwarded-For X-Real-IP"।
অবজেক্ট ধরনের সেটিংস JSON গ্রহণ করে। অ্যাপসের জন্য এমন একমাত্র ভ্যারিয়েবল হলো AM_PLUGINSETTINGS_PLUGINS, যা একসাথে সব অ্যাপের সেটিংস প্রতিস্থাপন করে: পরিবর্তে System Console-এ বা amctl ব্যবহার করে অ্যাপ সেটিংস সেট করুন (নিচে দেখুন)।
পুরনো Mattermost সেটআপগুলো MM_ প্রিফিক্স ব্যবহার করে, যেমন MM_SQLSETTINGS_DATASOURCE। এটি এখনও একটি লেগেসি অ্যালিয়াস হিসেবে কাজ করে। যদি উভয়ই সেট করা থাকে, তবে AM_ ভ্যারিয়েবলটি অগ্রাধিকার পায়।

ভ্যারিয়েবল দ্বারা প্রদত্ত কোনো সেটিং System Console-এ লক করা থাকে, সাথে এই নোট থাকে: "এই সেটিংটি একটি এনভায়রনমেন্ট ভ্যারিয়েবলের মাধ্যমে সেট করা হয়েছে। এটি System Console-এর মাধ্যমে পরিবর্তন করা যাবে না।" এটি সংরক্ষিত কনফিগারেশনে লেখা হয় না: ভ্যারিয়েবলটি সরিয়ে দিলে সংরক্ষিত মানটি আবার প্রযোজ্য হবে।

Docker Compose-এর সাথে

antimatter সার্ভিসের environment: অংশের নিচে ভ্যারিয়েবল যোগ করুন, অথবা compose.yaml-এর পাশে compose.override.yaml ফাইলে যোগ করুন (Compose এটি স্বয়ংক্রিয়ভাবে পড়ে, এবং ডাউনলোড করা ফাইলের আপডেটে এটি টিকে থাকে):

services:
  antimatter:
    environment:
      AM_EMAILSETTINGS_SMTPSERVER: smtp.example.com
      AM_EMAILSETTINGS_SMTPPORT: "587"
      AM_LOGSETTINGS_CONSOLELEVEL: INFO

docker compose up -d ব্যবহার করে পরিবর্তন প্রয়োগ করুন, যা কন্টেইনারটি পুনরায় তৈরি করবে।

অ্যাপস দ্বারা পড়া ভ্যারিয়েবলসমূহ

কয়েকটি ভেরিয়েবল সেটিং নয় এবং এগুলোর জন্য কোনো সিস্টেম কনসোল ফিল্ড নেই: AM_CONFIG (কনফিগারেশন যেখানে আছে), এবং AM_AI_ENCRYPTION_KEY ও AM_AI_ENCRYPTION_PREVIOUS_KEYS, যা মডেল সংযোগের API কীগুলো এনক্রিপ্ট করে (দেখুন AI)।

কয়েকটি অ্যাপ antimatter সার্ভিসে সেট করা নিজস্ব ভ্যারিয়েবল পড়ে: Calls অ্যাপটি AM_CALLS_* পড়ে (দেখুন Calls and voice), এবং GIFs অ্যাপটি AM_GIFS_SERVICE_URL, AM_GIFS_API_KEY এবং AM_GIFS_UPLOAD_KEY পড়ে (দেখুন Bundled apps)।

System Console

সিস্টেম কনসোল হলো ওয়েব অ্যাপের প্রশাসনিক অংশ, যা সিস্টেম অ্যাডমিনদের জন্য। এটি খোলার জন্য অ্যাপ রেলের উপরে আপনার ছবিতে ক্লিক করে সিস্টেম কনসোল নির্বাচন করুন, অথবা https://chat.example.com/admin_console-এ যান। এর সাইডবারে একটি সেটিংস খুঁজুন বক্স রয়েছে, যা প্রতিটি পেজে সার্চ করে।

এর সেকশনগুলো হলো:

রিপোর্টিং: পরিসংখ্যান এবং সার্ভার লগ।
ব্যবহারকারী ব্যবস্থাপনা: ব্যবহারকারী, গ্রুপ, কমিউনিটি (টিম হিসেবে তালিকাভুক্ত), চ্যানেলসমূহ, অনুমতি এবং প্রতিনিধিত্বমূলক প্রশাসন।
সিস্টেম অ্যাট্রিবিউট: কাস্টম প্রোফাইল অ্যাট্রিবিউট এবং অ্যাট্রিবিউট-ভিত্তিক অ্যাক্সেস।
এনভাইরনমেন্ট: ওয়েব সার্ভার, ডেটাবেস, ফাইল স্টোরেজ, ইমেজ প্রক্সি, SMTP, পুশ নোটিফিকেশনসমূহ, রেট লিমিটিং, লগিং, সেশন দৈর্ঘ্য এবং পারফরম্যান্স মনিটরিং।
সাইট কনফিগারেশন: ব্র্যান্ডিং, ব্যবহারকারী এবং টিমসমূহ, নোটিফিকেশনসমূহ, পোস্ট, ফাইল শেয়ারিং এবং অন্যান্য সার্ভার-ব্যাপী আচরণ।
প্রমাণীকরণ: সাইন-আপ, ইমেইল এবং পাসওয়ার্ড সাইন-ইন, MFA, AD/LDAP, SAML 2.0, OAuth 2.0, OpenID Connect এবং অতিথি অ্যাক্সেস।
AI: মডেল কানেকশন এবং বিল্ট-ইন AI ফিচার (রিস্রাইট, রিক্যাপ, অটো-ট্রান্সলেশন, টেক্সট টু স্পিচ)। দেখুন AI।
প্লাগইনসমূহ: অ্যাপ ব্যবস্থাপন এবং প্রতিটি ইনস্টল করা অ্যাপের সেটিংস।
ইন্টিগ্রেশনসমূহ: ওয়েবহুক, স্লাশ কমান্ড, বট অ্যাকাউন্ট, GIF, টেক্সট টু স্পিচ, CORS।
Compliance: ডেটা রিটেনশন, কমপ্লায়েন্স এক্সপোর্ট এবং মনিটরিং, অডিট লগিং, কাস্টম টার্মস অব সার্ভিস।
পরীক্ষামূলক: এমন ফিচার যা পরিবর্তিত হতে পারে।

এই গাইডে, একটি সেটিংকে সিস্টেম কনসোলে এর পথ, তারপর এর লেবেল, তারপর এর কনফিগারেশন কী হিসেবে লেখা হয়েছে, যেমন সিস্টেম কনসোল › সাইট কনফিগারেশন › ব্যবহারকারী এবং টিমসমূহ › উপেক্ষা, ব্লক এবং মেসেজ রিকোয়েস্ট চালু করুন (PrivacySettings.EnableUserBlocking)।

আপনি সংরক্ষণ করুন এ ক্লিক করার সাথে সাথেই বেশিরভাগ পরিবর্তন প্রয়োগ হয়। কিছু পরিবর্তনের (লিসেন অ্যাড্রেস, কিছু ডেটাবেস এবং ক্যাশ সেটিংস) জন্য রিস্টার্ট প্রয়োজন, এবং পেজে তা উল্লেখ করা থাকে।

গিল্ড বা ওয়ার্কস্পেস

প্রতিটি কমিউনিটির একটি ধরন (kind) থাকে, যা তার কিছু ডিফল্ট সেটিং নির্ধারণ করে:

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

সিস্টেম কনসোল › সাইট কনফিগারেশন › ব্যবহারকারী এবং টিমসমূহ › নতুন কমিউনিটির ধরন (TeamSettings.DefaultCommunityKind, AM_TEAMSETTINGS_DEFAULTCOMMUNITYKIND) হলো সেই ধরন যা পরবর্তীতে তৈরি হওয়া কমিউনিটিসমূহের জন্য প্রযোজ্য হবে: গিল্ড (ডিফল্ট) অথবা ওয়ার্কস্পেস; সেটিংসটি পুরনো মান community এবং workplace সংরক্ষণ এবং পড়তে অব্যাহত রাখে। একটি কমিউনিটি তৈরির সময় নির্বাচিত লেআউট প্রিসেট তার নিজস্ব ধরন নির্ধারণ করে। প্রতিটি কমিউনিটির অ্যাডমিনরা পরবর্তীতে টিম সেটিংস › জেনারেল থেকে এর ধরন পরিবর্তন করতে পারে। নতুন গিল্ডসমূহ সবাইকে প্রতিটি চ্যানেলে যুক্ত করে (TeamSettings.AllChannelsMembershipForNewTeams) শুধুমাত্র নতুন গিল্ডসমূহের জন্য ডিফল্ট: ওয়ার্কস্পেসসমূহ কখনো এইভাবে শুরু হয় না (দেখুন সবাইকে প্রতিটি চ্যানেলে)।

একটি কোম্পানির জন্য, প্রথম কমিউনিটি তৈরি করার আগে বা বিদ্যমান সার্ভারকে 0.9.0 সংস্করণে আপগ্রেড করার আগে এটি ওয়ার্কস্পেস সেট করুন: আপগ্রেডটি সেই মুহূর্তে সেটিংসের মানটি প্রতিটি বিদ্যমান কমিউনিটিতে প্রদান করে (দেখুন 0.9.0 এ আপগ্রেড করা)।

পড়লেই মুছে যায় এমন মেসেজ

ব্যবহারকারীরা এমন মেসেজ পাঠাতে পারেন যা প্রতিটি পাঠক মেসেজটি খোলার কিছুক্ষণ পরে মুছে যায় (দেখুন Burn-on-read messages)। সেটিংসমূহ সিস্টেম কনসোল › সাইট কনফিগারেশন › Posts-এ, পড়লেই মুছে যাবে এমন ম্যাসেজ বিভাগের অধীনে রয়েছে:

সেটিং	কী এবং ভেরিয়েবল	ডিফল্ট
Burn-on-Read মেসেজ সক্রিয় করুন	`ServiceSettings.EnableBurnOnRead`, `AM_SERVICESETTINGS_ENABLEBURNONREAD`	অন
Burn-on-Read মেসেজের সময়কাল: প্রেরক যদি কোনো সময়কাল নির্বাচন না করেন, তবে মেসেজটি খোলার পর কতক্ষণ স্থায়ী হবে	`ServiceSettings.BurnOnReadDurationSeconds`, `AM_SERVICESETTINGS_BURNONREADDURATIONSECONDS`	600 (10 মিনিট)
প্রেরকরা সর্বোচ্চ যে সময়কাল নির্বাচন করতে পারবেন: 1 ঘণ্টা থেকে 7 দিন পর্যন্ত; এর চেয়ে বেশি সময়কাল নির্বাচন করলে তা স্বয়ংক্রিয়ভাবে এই সীমায় পরিণত হবে	`ServiceSettings.BurnOnReadMaximumDurationSeconds`, `AM_SERVICESETTINGS_BURNONREADMAXIMUMDURATIONSECONDS`	86400 (1 দিন)
বার্ন-অন-রিড (Burn-on-Read) ম্যাসেজের সর্বোচ্চ সময়: মেসেজটি পাঠানোর পর এই সময়ের মধ্যে তা মুছে যাবে, এমনকি যদি সবাই তা নাও পড়ে থাকেন	`ServiceSettings.BurnOnReadMaximumTimeToLiveSeconds`, `AM_SERVICESETTINGS_BURNONREADMAXIMUMTIMETOLIVESECONDS`	604800 (7 দিন)

মেসেজ পড়ার সময় সর্বোচ্চ সময়কাল আবার যাচাই করা হয়, তাই এই মান কমালে আগে পাঠানো মেসেজগুলোর স্থায়িত্বও কমে যাবে।

amctl কমান্ড-লাইন টুল

amctl কমান্ড লাইন থেকে একটি সার্ভার পরিচালনা করে: ইউজার, কমিউনিটি, চ্যানেল, অ্যাপ, কনফিগারেশন, জব এবং আরও অনেক কিছু। এটি সার্ভারের সাথে দুইভাবে যোগাযোগ করে।

লোকাল মোড, সার্ভারে

লোকাল মোড amctl-কে ইউনিক্স সকেটের মাধ্যমে সার্ভারের সাথে যোগাযোগ করতে দেয়, সাইন-ইন ছাড়াই। ডকার ইমেজে এবং .deb ও .rpm প্যাকেজে এটি চালু থাকে। আর্কাইভ থেকে ইনস্টল করা সার্ভারে ServiceSettings.EnableLocalMode (AM_SERVICESETTINGS_ENABLELOCALMODE=true) দিয়ে এটি চালু করুন। ডিফল্টভাবে সকেটটি /var/tmp/antimatter_local.socket (ServiceSettings.LocalModeSocketLocation)।

# with Docker Compose
docker compose exec antimatter amctl --local system status
# with a release archive
sudo -u antimatter /opt/antimatter/bin/amctl --local system status
# with the .deb or .rpm package
sudo -u antimatter amctl --local system status

যে কেউ সকেট ব্যবহার করতে পারে, অথবা হোস্টে docker compose exec চালানো যায়, তার পূর্ণ সিস্টেম অ্যাডমিনিস্ট্রেটর অধিকার থাকে।

রিমোট, একটি অ্যাকাউন্টের মাধ্যমে

যেকোনো মেশিন থেকে, একটি সিস্টেম অ্যাডমিনিস্ট্রেটর অ্যাকাউন্টে (অথবা পার্সোনাল অ্যাক্সেস টোকেনে) সাইন-ইন করে, তারপর সেই সার্ভারের বিরুদ্ধে কমান্ড চালান:

amctl auth login https://chat.example.com --name prod --username admin
amctl system status

কনফিগারেশন কমান্ড

কমান্ড	এটি কী করে
`amctl config get ServiceSettings.SiteURL`	একটি সেটিং প্রিন্ট করে।
`amctl config set TeamSettings.EnableOpenServer false`	একটি সেটিংস পরিবর্তন করে। তালিকা সেটিংস একটি বা একাধিক মান নেয়।
`amctl config patch settings.json`	কনফিগারেশনে একটি JSON ফাইলের সেটিংস মার্জ করে।
`amctl config show`	পুরো কনফিগারেশন JSON হিসেবে প্রিন্ট করে।
`amctl config edit`	আপনার এডিটরে (`$EDITOR`) কনফিগারেশন খোলে।
`amctl config reset`	সেটিংসকে ডিফল্টে রিসেট করে।
`amctl config reload`	সার্ভারের বাইরে থেকে করা পরিবর্তনের পরে, সেটিংসকে যেখান থেকে সেটি সংরক্ষিত থাকে সেখান থেকে রিলোড করে।

অ্যাপ সেটিংস PluginSettings.Plugins.<app id>-এর নিচে থাকে, কীগুলো লোয়ার কেসে থাকে। উদাহরণস্বরূপ, Docker হোস্ট থেকে GIFs অ্যাপের সার্ভিস URL এবং কী সেট করতে:

docker compose exec -T antimatter amctl --local config patch /dev/stdin <<'EOF'
{"PluginSettings": {"Plugins": {"com.antimatterchat.gifs": {
  "serviceurl": "http://gifs:8080/v2",
  "apikey": "the GIFS_API_KEY of your .env"
}}}}
EOF

অন্যান্য উপযোগী কমান্ড: amctl user create, amctl user deactivate, amctl team create, amctl plugin list, amctl plugin enable, amctl system supportpacket এবং amctl logs। প্রতিটির অপশন জানতে amctl help <command> চালান।

লগ

সার্ভার তার লগ দুটি জায়গায় লেখে, প্রতিটির নিজস্ব লেভেল (DEBUG, INFO, WARN বা ERROR) সহ, যা সিস্টেম কনসোল › এনভাইরনমেন্ট › লগিং এ সেট করা হয়:

গন্তব্য	সেটিংস	ডিফল্ট
কনসোল (স্ট্যান্ডার্ড আউটপুট)	কনসোলে লগ আউটপুট করুন (`LogSettings.EnableConsole`), কনসোল লগ লেভেল (`LogSettings.ConsoleLevel`), কনসোল লগ JSON হিসেবে আউটপুট করুন (`LogSettings.ConsoleJson`)	চালু, `DEBUG`, JSON
একটি ফাইল, `antimatter.log`	লগ ফাইলে আউটপুট করুন (`LogSettings.EnableFile`), ফাইল লগ লেভেল (`LogSettings.FileLevel`), ফাইল লগ ডিরেক্টরি (`LogSettings.FileLocation`)	চালু, `INFO`, `bin/`-এর পাশে `logs/` ডিরেক্টরি

লগ ফাইল ১০০ মেগাবাইটে রোটেট হয় এবং পুরনো ফাইলগুলো কমপ্রেস করা হয়।

সাইটের কম্পোজ ফাইল ফাইল লগিং বন্ধ করে রাখে (AM_LOGSETTINGS_ENABLEFILE=false), তাই লগ শুধুমাত্র কন্টেইনারের আউটপুটে থাকে:

docker compose logs -f antimatter
docker compose logs --since 1h antimatter | grep -i error

কনসোল লেভেলের ডিফল্ট মান DEBUG, যা বেশি বিস্তারিত। ব্যস্ত সার্ভারে AM_LOGSETTINGS_CONSOLELEVEL=INFO সেট করুন। রিলিজ আর্কাইভের এবং প্যাকেজগুলোর config.json এটি ইতিমধ্যে INFO-এ সেট করে রাখে। সিস্টেমড-এর নিচে রিলিজ আর্কাইভ ব্যবহার করলে, কনসোল আউটপুট জার্নালে যায় (journalctl -u antimatter) এবং ফাইলটি /opt/antimatter/logs/antimatter.log-এ যায়। প্যাকেজগুলোর ফাইল লগিং বন্ধ থাকে, তাই তাদের লগ শুধুমাত্র জার্নালে থাকে।

লগ এবং অডিট ফাইলসমূহ অবশ্যই লগিং রুটের মধ্যে থাকতে হবে: AM_LOG_PATH (পুরনো MM_LOG_PATH এখনও কাজ করে) যদি সেট করা থাকে, অন্যথায় logs ফোল্ডার। এটি ডিফল্টভাবে বলবৎ করা হয়: একটি ফাইল লগ ডিরেক্টরি, অ্যাডভান্সড লগিং টার্গেট, বা অডিট লগ পাথ রুটের বাইরে থাকলে সার্ভার বুটআপে থেমে যায়, এবং কনফিগারেশন সংরক্ষণ করার সময় তা প্রত্যাখ্যান করা হয়। AM_FEATUREFLAGS_ENFORCELOGPATHROOT=false দিয়ে বলবৎকরণ বন্ধ করুন। AM_LOG_PATH সেট করা থাকলে এবং ফাইল লগ ডিরেক্টরি ফাঁকা রাখলে, লগসমূহ AM_LOG_PATH এ যায়।

যখন ফাইল লগিং চালু থাকে, সিস্টেম অ্যাডমিনরা সিস্টেম কনসোল › রিপোর্টিং › সার্ভার লগ থেকেও লগ পড়তে পারেন: রঙ-কোডেড লেভেল ব্যাজ, লেভেল অনুযায়ী দ্রুত ফিল্টার, একটি লাইভ টেইল, এবং ৫ মিনিট থেকে ২৪ ঘণ্টা পর্যন্ত সময়-পরিসরের প্রিসেট, অথবা amctl logs দিয়ে।