Конфигурация
Къде Antimatter съхранява настройките си, трите начина за тяхното променяне (Системна конзола, променливи на околната среда, amctl) и къде отиват логовете.
Къде се намират настройките
Всяка настройка на сървъра има име, състоящо се от секция и ключ, например ServiceSettings.SiteURL или EmailSettings.SMTPServer. Заедно те образуват една конфигурация, съхранявана на едно от две места:
- В базата данни. Файлът за композиране на сайта задава
AM_CONFIGна URL за връзка с PostgreSQL, така че конфигурацията е ред в базата данни и контейнерът не съхранява нищо на диска. Няколко сървъра, споделящи една база данни, споделят и конфигурацията си. - В файл. Без
AM_CONFIGсървърът четеconfig/config.jsonдо своята директорияbin/(/antimatter/config/config.jsonв Docker образа). Архивът за разпространение и продуктивните compose файлове на antimatter-docker работят по този начин, както и .deb и .rpm пакетите, чийто файл е/etc/antimatter/config/config.json. Дръжте този файл четим само за потребителя на сървъра: той съдържа пароли и ключове.
AM_CONFIG (или флага --config на командата antimatter) приема или път до файл, или 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 вземат
trueилиfalse; числата са обикновени числа. - Настройките от списък вземат стойности, разделени с интервали, например
AM_SERVICESETTINGS_TRUSTEDPROXYIPHEADER="X-Forwarded-For X-Real-IP". - Настройките, които са обекти, вземат JSON. Единствената такава променлива за приложенията е
AM_PLUGINSETTINGS_PLUGINS, и тя замества настройките на всички приложения едновременно: задавайте настройките на приложенията в Системната конзола или сamctlвместо това (вижте по-долу). - По-стари инсталации на Mattermost използват префикса
MM_, напримерMM_SQLSETTINGS_DATASOURCE. Той все още действа като наследен алиас. Ако са зададени и двете, променливатаAM_има предимство.
Настройка, зададена чрез променлива, е блокирана в Системната конзола с бележка: „Тази настройка е зададена чрез променлива на околната среда. Не може да се променя чрез Системната конзола.“ Тя не се записва в запазената конфигурация: премахнете променливата и запазената стойност отново ще се прилага.
С Docker Compose
Добавете променливи под environment: на услугата antimatter, или в compose.override.yaml до compose.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 ключовете на връзките с модели (вижте ИИ).
Няколко приложения четат собствените си променливи, зададени на услугата antimatter: приложението Calls чете AM_CALLS_* (вижте Обаждания и глас), а приложението GIFs чете AM_GIFS_SERVICE_URL, AM_GIFS_API_KEY и AM_GIFS_UPLOAD_KEY (вижте Вградени приложения).
Системната конзола
Системната конзола е административната зона на уеб приложението, предназначена за системни администратори. За да я отворите, щракнете върху своята снимка в горната част на лентата на приложението и изберете Системна конзола, или отидете на https://chat.example.com/admin_console. В страничната ѝ лента има поле Намерете настройки, което търси във всички страници.

Секциите ѝ са:
- Докладване: статистика и системни дневници.
- Управление на потребители: потребители, групи, общности (изброени като Екипи), канали, права и делегирано администриране.
- Системни атрибути: персонализирани атрибути на профила и достъп на базата на атрибути.
- Обкръжение: уеб сървър, база данни, файлово хранилище, прокси за изображения, SMTP, пуш известия, ограничаване на честотата, журналиране, продължителност на сесии, мониторинг на производителността.
- Конфигурация на сайта: брандиране, потребители и екипи, известия, публикации, споделяне на файлове и други сървърни поведения.
- Удостоверяване: регистрация, вход с имейл и парола, MFA, AD/LDAP, SAML 2.0, OAuth 2.0, OpenID Connect и гостен достъп.
- ИИ: връзки с модели и вградените функции за изкуствен интелект (переписване, обобщения, автоматичен превод, текст в реч). Вижте ИИ.
- Приставка: управление на приложения и настройките на всяко инсталирано приложение.
- Интеграции: webhooks, команди с наклонена черта, ботови акаунти, GIFs, текст в реч, CORS.
- Съгласие: задържане на данни, експорт за съответствие и мониторинг, журнал на одита, персонализирани условия за ползване.
- Експериментално: функции, които могат да се променят.
В това ръководство настройката се записва като пътят ѝ в Системната конзола, след това етикетът ѝ, а след това ключът за конфигурация, например Системна конзола › Конфигурация на сайта › Потребители и екипи › Активиране на игнориране, блокиране и заявки за съобщения (PrivacySettings.EnableUserBlocking).
Повечето промени се прилагат веднага щом щракнете върху Запиши. Няколко (адресът за слушане, някои настройки на базата данни и кеша) изискват рестарт, а страницата го посочва.
Гилдия или работно пространство
Всяка общност има тип, който задава някои от нейните стойности по подразбиране:
- Гилдия, за публична или хоби общност: обажданията в каналите ѝ са изключени (хората разговарят в гласови канали), а каналите се архивират само от администраторите ѝ и от ролите, които управляват каналите.
- Работно пространство, за компания или организация: обажданията в каналите са включени, а каналът се архивира от администраторите му (този, който го е създал, и тези, които той е назначил за администратори).
Системна конзола › Конфигурация на сайта › Потребители и екипи › Вид на новите общности (TeamSettings.DefaultCommunityKind, AM_TEAMSETTINGS_DEFAULTCOMMUNITYKIND) определя вида на общностите, създадени след това: Гилдия (по подразбиране) или Работно пространство; настройката продължава да съхранява и чете по-старите стойности community и workplace. Предварително зададеното оформление при създаване на общност определя нейния собствен вид. Администраторите на всяка общност могат да променят вида ѝ по-късно в Настройки на екипа › Общи. Новите гилдии включват всички във всеки канал (TeamSettings.AllChannelsMembershipForNewTeams) е по подразбиране само за нови гилдии: работните пространства никога не започват по този начин (вижте Всички във всеки канал).
Съобщения, които се изтриват при четене
Потребителите могат да изпращат съобщения, които се изтриват известно време след като всеки получател ги отвори (вижте Съобщения, които се изтриват при четене). Настройките се намират в Системна конзола › Конфигурация на сайта › Съобщения, в раздела Съобщения, които се изтриват при четене:
| Настройка | Ключ и променлива | По подразбиране |
|---|---|---|
| Активиране на съобщения „Изгаря при четене“ | ServiceSettings.EnableBurnOnRead, AM_SERVICESETTINGS_ENABLEBURNONREAD | включено |
| Продължителност на „Изгаря при четене“: колко дълго съобщението остава видимо след отварянето му, ако изпращачът не е избрал продължителност | ServiceSettings.BurnOnReadDurationSeconds, AM_SERVICESETTINGS_BURNONREADDURATIONSECONDS | 600 (10 минути) |
| Най-дългата продължителност, която изпращачите могат да изберат: от 1 час до 7 дни; по-дълъг избор се скъсява до тази стойност | ServiceSettings.BurnOnReadMaximumDurationSeconds, AM_SERVICESETTINGS_BURNONREADMAXIMUMDURATIONSECONDS | 86400 (1 ден) |
| Максимално време за съществуване на съобщенията „Изчезват при четене“: съобщението се изтрива толкова дълго след изпращането си, дори ако не всички са го прочели | ServiceSettings.BurnOnReadMaximumTimeToLiveSeconds, AM_SERVICESETTINGS_BURNONREADMAXIMUMTIMETOLIVESECONDS | 604800 (7 дни) |
Най-дългата продължителност се проверява отново при прочитане на съобщението, така че намаляването ѝ скъсява и вече изпратените съобщения.
Командният инструмент amctl
amctl управлява сървъра от командния ред: потребители, общности, канали, приложения, конфигурация, задачи и много други. Свързва се със сървъра по един от два начина.
Локален режим, на сървъра
Локалният режим позволява на amctl да комуникира със сървъра чрез Unix socket, без да се изисква вход. Той е активиран в Docker образа и в .deb и .rpm пакетите. На сървър, инсталиран от архив, го активирайте чрез ServiceSettings.EnableLocalMode (AM_SERVICESETTINGS_ENABLELOCALMODE=true). По подразбиране socket-ът е /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>, с ключове с малки букви. Например, за да зададете URL-а и ключа за услугата на приложението GIFs от Docker хоста:
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, директорията logs/ до bin/ |
Файловете с дневници се ротират на 100 MB, а старите се компресират.
Композ файла на сайта изключва записването на дневник във файл (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. При архив за разпространение под systemd изходът на конзолата отива в журнала (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.
Когато записването на дневници във файл е включено, системните администратори могат също да четат дневника в Системна конзола › Докладване › Сървърни дневници: цветни баджове за нивото, бързи филтри по ниво, проследяване в реално време и предварително зададени времеви диапазони от 5 минути до 24 часа, или чрез amctl logs.