Konfigurasyon

Kung saan nag-iimbak ng Antimatter ang mga setting, ang tatlong paraan upang baguhin ang mga ito (System Console, environment variable, amctl), at kung saan pumupunta ang mga log.

Kung saan nasa mga setting

Bawat setting ng server ay may pangalan na binubuo ng isang section at isang key, tulad ng ServiceSettings.SiteURL o EmailSettings.SMTPServer. Kasama ang isa't isa, bumubuo sila ng isang konfigurasyon na nakatago sa isa sa dalawang lugar:

• Sa database. Ang compose file ng site ay nagse-set ng AM_CONFIG sa connection URL ng PostgreSQL, kaya ang konfigurasyon ay isang row sa database at hindi nag-iimbak ng anumang bagay sa disk ang container. Ang mga server na nagbabahagi ng iisang database ay nagbabahagi rin ng kanilang konfigurasyon.
• Sa isang file. Kung walang AM_CONFIG, binabasa ng server ang config/config.json na nasa tabi ng bin/ directory nito (/antimatter/config/config.json sa Docker image). Ganito ang ginagawa ng release archive at ng mga production compose file ng antimatter-docker, gayunpaman ang mga .deb at .rpm package, na ang file ay /etc/antimatter/config/config.json. Panatilihing mababasa lamang ng user ng server ang file na ito: naglalaman ito ng mga password at key.

Ang AM_CONFIG (o ang --config flag ng antimatter command) ay tumatanggap ng file path o postgres:// URL. Ang mga setting na hindi isasama ay tumatanggap ng kanilang default value.

Upang ilipat ang umiiral na konfigurasyon mula sa file patungo sa database, patakbuhin ito sa server, tapos patakbuhin ang server na may AM_CONFIG na nakaset sa parehong URL:

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

Mga environment variable

Ang anumang setting ay maaari ring bigyan bilang environment variable. Ang mga variable ang nananalo sa nakatagong konfigurasyon, kaya angkop sila para sa mga bagay na kailangan ng deployment: ang database, ang site URL, ang file storage, ang mga port.

Patakaran sa pagpangalan

Isulat ang AM_, tapos ang section, tapos ang key, sa malalaking letra at hiwalay-hiwalay ng underscore. Ang mga salita sa loob ng pangalan ng section o key ay hindi hiwalay-hiwalay:

• Ang mga setting na true at false ay tumatanggap ng true o false; ang mga numero ay simpleng numero.
• Ang mga setting na list ay tumatanggap ng mga value na hiwalay-hiwalay ng puwang, halimbawa AM_SERVICESETTINGS_TRUSTEDPROXYIPHEADER="X-Forwarded-For X-Real-IP".
• Ang mga setting na object ay tumatanggap ng JSON. Ang tanging ganitong variable para sa mga app ay AM_PLUGINSETTINGS_PLUGINS, at pinapalit nito ang mga setting ng bawat app nang sabay-sabay: itaguyod ang mga setting ng app sa System Console o gamit ang amctl sa halip (tingnan sa ibaba).
• Ginagamit ng mga lumang setup ng Mattermost ang MM_ prefix, halimbawa ang MM_SQLSETTINGS_DATASOURCE. Patuloy itong gumagana bilang legacy alias. Kapare ang dalawa ay naka-set, ang AM_ variable ang mananalo.

Naka-lock sa System Console ang setting na ibinigay ng variable, na may tala na "This setting has been set through an environment variable. It cannot be changed through the System Console." Hindi ito isinusulat sa na-store na configuration: alisin ang variable at muli ang naaapply ang na-store na value.

Gamit ang Docker Compose

Magdagdag ng mga variable sa ilalim ng environment: ng antimatter service, o sa compose.override.yaml na nasa tabi ng compose.yaml (awtomatikong binabasa ito ng Compose, at natatag sa mga update ng downloaded na file):

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

I-apply ang mga pagbabago gamit ang docker compose up -d, na nagre-recreate ng container.

Mga variable na binabasa ng mga app

May ilang variable na hindi setting at walang field sa System Console: AM_CONFIG (kung saan nakalagay ang configuration), at AM_AI_ENCRYPTION_KEY at AM_AI_ENCRYPTION_PREVIOUS_KEYS, ang key na nag-e-encrypt ng mga API key ng mga koneksyon sa model (tingnan ang AI).

May ilang app na binabasa ang sarili nilang variable, na naka-set sa antimatter service: binabasa ng Calls app ang AM_CALLS_* (tingnan ang Calls and voice), at binabasa ng GIFs app ang AM_GIFS_SERVICE_URL, AM_GIFS_API_KEY at AM_GIFS_UPLOAD_KEY (tingnan ang Bundled apps).

Ang System Console

Ang System Console ang lugar ng administrasyon ng web app, para sa mga system administrator. Upang buksan ito, i-click ang iyong larawan sa itaas ng app rail at piliin ang System Console, o pumunta sa https://chat.example.com/admin_console. Ang sidebar nito ay may Hanapin ang mga setting na kahon na naghahanap sa bawat pahina.

Ang mga seksyon nito ay:

• Reporting: estadistika at mga log ng server.
• Pamamahala ng Mga User: mga user, grupo, komunidad (tinatawag na Teams), mga channel, mga pahintulot, at delegated administration.
• Mga Attributo ng Sistema: mga custom na profile attribute at access batay sa attribute.
• Environment: web server, database, file storage, image proxy, SMTP, push notifications, rate limiting, logging, haba ng session, at performance monitoring.
• Konfigurasyon ng Site: branding, mga user at team, mga notisikasyon, mga post, pagbabahagi ng file, at iba pang server-wide na pag-uugali.
• Pagpapatunay: sign-up, sign-in gamit ang email at password, MFA, AD/LDAP, SAML 2.0, OAuth 2.0, OpenID Connect, at access ng bisita.
• AI: mga koneksyon ng modelo at mga built-in na feature ng AI (rewrite, recap, auto-translation, text to speech). Tingnan ang AI.
• Mga Plugin: pamamahala ng app at mga setting ng bawat naka-install na app.
• Mga Integration: mga webhook, slash command, mga bot account, GIF, text to speech, at CORS.
• Pagkakaunawa: retention ng data, compliance export at monitoring, audit logging, at custom na terms of service.
• Pang-eksperimento: mga feature na maaaring magbago.

Sa gabay na ito, isinusulat ang bawat setting bilang ang kanyang path sa System Console, pagkatapos ang kanyang label, at pagkatapos ang kanyang configuration key, halimbawa System Console › Konfigurasyon ng Site › Mga User at Team › Paganahin ang pag-i-ignore, pag-block, at mga message request (PrivacySettings.EnableUserBlocking).

Karamihan sa mga pagbabago ay agad na epektibo kapag in-click ang I-save. Ilang bagay (tulad ng listen address, ilang database at cache settings) ay nangangailangan ng restart, at sinasabi nito ang pahina.

Guild o workspace

Bawat komunidad ay may uri, na nagtatakda ng ilang default nito:

• Guild, para sa isang pampubliko o hobby community: ang mga tawag ay naka-off sa mga channel nito (nag-uusap ang mga tao sa mga voice channel), at ang mga admin nito lamang, at ang mga role na namamahala sa mga channel, ang makakapag-archive ng mga channel.
• Workspace, para sa isang kumpanya o organisasyon: ang mga tawag ay nasa loob ng mga channel nito, at ang mga admin ng channel (ang gumawa nito, at ang mga ginawang admin nila) ang maaari ring i-archive ito.

System Console › Konfigurasyon ng Site › Mga User at Team › Uri ng mga bagong community (TeamSettings.DefaultCommunityKind, AM_TEAMSETTINGS_DEFAULTCOMMUNITYKIND) ang uri ng mga community na gagawin mula ngayon: Guild (default) o Workspace; ang setting ay patuloy na nag-iimbak at nagbabasa ng mga lumang halaga na community at workplace. Ang layout preset na pinili kapag gumagawa ng community ay nagtatakda ng sarili nitong uri. Maaaring baguhin ng mga admin ng bawat community ang uri nito pagkatapos, sa Mga setting ng team › General. Ang Ilagay ang lahat sa bawat channel para sa mga bagong guild (TeamSettings.AllChannelsMembershipForNewTeams) ay ang default lamang para sa mga bagong guild: hindi kailanman nagsisimula ang mga workspace sa ganitong paraan (tingnan ang Lahat sa bawat channel).

Mga burn-on-read na mensahe

Makapagpapadala ang mga tao ng mga mensahe na buburahin pagkatapos ng ilang sandali pagkatapos buksan ng bawat mambabasa (tingnan ang Mga burn-on-read na mensahe). Ang mga setting ay nasa System Console › Konfigurasyon ng Site › Mga Post, sa ilalim ng Mga burn-on-read na mensahe:

Ang pinakamahabang tagal ay muling sinusuri kapag nabasa ang mensahe, kaya ang pagpapababa nito ay nagpapamaikli rin sa mga mensaheng naipadala na.

Ang command-line tool na amctl

Pinangangasiwaan ng amctl ang server mula sa command line: mga user, community, channel, app, configuration, job, at iba pa. Nagkukonekta ito sa server sa isa sa dalawang paraan.

Local mode, sa server

Pahintulutan ng local mode ang amctl na makipag-usap sa server sa pamamagitan ng Unix socket, nang hindi nagse-sign in. Ito ay naka-on sa Docker image at sa mga .deb at .rpm package. Sa isang server na na-install mula sa archive, i-on ito gamit ang ServiceSettings.EnableLocalMode (AM_SERVICESETTINGS_ENABLELOCALMODE=true). Ang socket ay /var/tmp/antimatter_local.socket bilang default (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

Remote, gamit ang account

Mula sa anumang makina, mag-sign in gamit ang system administrator account (o personal access token), tapos mag-run ng mga command para sa server na iyon:

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

Mga command para sa configuration

Nakapaloob ang mga app settings sa ilalim ng PluginSettings.Plugins.<app id>, na may mga key na nasa lower case. Halimbawa, upang i-set ang service URL at key ng GIFs app mula sa Docker host:

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

Iba pang makapangyarihang command: amctl user create, amctl user deactivate, amctl team create, amctl plugin list, amctl plugin enable, amctl system supportpacket at amctl logs. I-run ang amctl help <command> para sa mga opsyon ng bawat isa.

Mga Log

Isinusulat ng server ang log nito sa dalawang lugar, bawat isa ay may sariling antas (DEBUG, INFO, WARN o ERROR), na nakatakda sa System Console › Environment › Logging:

Ang mga log file ay pinapa-rotate sa 100 MB at pinipig-compress ang lumang mga ito.

Ang compose file ng site ay pumipig-off ng file logging (AM_LOGSETTINGS_ENABLEFILE=false), kaya ang mga log ay nasa output ng container lamang:

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

Ang antas ng console ay default na nakatakda sa DEBUG, na napakatalikod. Sa isang abalang server, itakda ang AM_LOGSETTINGS_CONSOLELEVEL=INFO. Ang config.json ng release archive at ng mga package ay nakatakda na ito sa INFO. Sa isang release archive sa ilalim ng systemd, ang output ng console ay napupunta sa journal (journalctl -u antimatter) at ang file ay napupunta sa /opt/antimatter/logs/antimatter.log. Pinaputol ng mga package ang pag-log sa file, kaya ang kanilang mga log ay nasa journal lamang.

Ang mga log at audit file ay dapat manatili sa loob ng logging root: AM_LOG_PATH (ang mas lumang MM_LOG_PATH ay gumagana pa rin) kung ito ay nakatakda, kung hindi, ang logs folder. Ito ay ipinatupad bilang default: ang isang File Log Directory, advanced logging target, o audit log path na nasa labas ng root ay hihinto sa server sa startup, at itatanggi kapag ini-save mo ang configuration. Patayin ang pagpapatupad gamit ang AM_FEATUREFLAGS_ENFORCELOGPATHROOT=false. Kapag nakatakda ang AM_LOG_PATH at iniwanang blangko ang File Log Directory, ang mga log ay napupunta sa AM_LOG_PATH.

Kapag bukas ang pag-log sa file, maaari ring basahin ng mga system administrator ang log sa System Console › Reporting › Mga Server Log: mga badge ng antas na may kulay, mabilisang filter ayon sa antas, live tail, at mga preset ng saklaw ng oras mula 5 minuto hanggang 24 oras, o gamit ang amctl logs.