Конфигурация

Къде 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.SiteURLAM_SERVICESETTINGS_SITEURL
SqlSettings.DataSourceAM_SQLSETTINGS_DATASOURCE
EmailSettings.SMTPServerAM_EMAILSETTINGS_SMTPSERVER
PrivacySettings.EnableUserBlockingAM_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. В страничната ѝ лента има поле Намерете настройки, което търси във всички страници.

The System Console, with its sidebar of sections on the left and the SAML 2.0 settings page on the right.
Системната конзола. Страничната лента групира страниците в секции като Докладване, Управление на потребители и Обкръжение.

Секциите ѝ са:

  • Докладване: статистика и системни дневници.
  • Управление на потребители: потребители, групи, общности (изброени като Екипи), канали, права и делегирано администриране.
  • Системни атрибути: персонализирани атрибути на профила и достъп на базата на атрибути.
  • Обкръжение: уеб сървър, база данни, файлово хранилище, прокси за изображения, 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) е по подразбиране само за нови гилдии: работните пространства никога не започват по този начин (вижте Всички във всеки канал).

За компания задайте Работно пространство, преди да създадете първата общност или преди да надградите съществуващ сървър до версия 0.9.0: надграждането придава на всяка съществуваща общност стойността, която настройката има в този момент (вижте Надграждане до 0.9.0).

Съобщения, които се изтриват при четене

Потребителите могат да изпращат съобщения, които се изтриват известно време след като всеки получател ги отвори (вижте Съобщения, които се изтриват при четене). Настройките се намират в Системна конзола › Конфигурация на сайта › Съобщения, в раздела Съобщения, които се изтриват при четене:

НастройкаКлюч и променливаПо подразбиране
Активиране на съобщения „Изгаря при четене“ServiceSettings.EnableBurnOnRead, AM_SERVICESETTINGS_ENABLEBURNONREADвключено
Продължителност на „Изгаря при четене“: колко дълго съобщението остава видимо след отварянето му, ако изпращачът не е избрал продължителностServiceSettings.BurnOnReadDurationSeconds, AM_SERVICESETTINGS_BURNONREADDURATIONSECONDS600 (10 минути)
Най-дългата продължителност, която изпращачите могат да изберат: от 1 час до 7 дни; по-дълъг избор се скъсява до тази стойностServiceSettings.BurnOnReadMaximumDurationSeconds, AM_SERVICESETTINGS_BURNONREADMAXIMUMDURATIONSECONDS86400 (1 ден)
Максимално време за съществуване на съобщенията „Изчезват при четене“: съобщението се изтрива толкова дълго след изпращането си, дори ако не всички са го прочелиServiceSettings.BurnOnReadMaximumTimeToLiveSeconds, AM_SERVICESETTINGS_BURNONREADMAXIMUMTIMETOLIVESECONDS604800 (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
Всеки, който може да използва socket-а или да изпълни 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.