Konfiguration

Wo Antimatter seine Einstellungen speichert, die drei Möglichkeiten, sie zu ändern (Systemkonsole, Umgebungsvariablen, amctl), und wo die Protokolle abgelegt werden.

Wo die Einstellungen gespeichert sind

Jede Servereinstellung hat einen Namen, der aus einem Abschnitt und einem Schlüssel besteht, wie z. B. ServiceSettings.SiteURL oder EmailSettings.SMTPServer. Zusammen bilden sie eine Konfiguration, die an einem von zwei Orten gespeichert wird:

• In der Datenbank. Die Compose-Datei der Site setzt AM_CONFIG auf die PostgreSQL-Verbindungs-URL, sodass die Konfiguration eine Zeile in der Datenbank ist und der Container nichts auf der Festplatte speichert. Mehrere Server, die sich eine Datenbank teilen, teilen auch ihre Konfiguration.
• In einer Datei. Ohne AM_CONFIG liest der Server config/config.json neben seinem bin/-Verzeichnis (im Docker-Image /antimatter/config/config.json). Das Release-Archiv und die Produktions-Compose-Dateien von antimatter-docker funktionieren auf diese Weise, ebenso wie die .deb- und .rpm-Pakete, deren Datei /etc/antimatter/config/config.json ist. Halten Sie diese Datei nur für den Benutzer des Servers lesbar: Sie enthält Passwörter und Schlüssel.

AM_CONFIG (oder die --config-Option des antimatter-Befehls) akzeptiert entweder einen Dateipfad oder eine postgres://-URL. Einstellungen, die Sie weglassen, nehmen ihren Standardwert an.

Um eine vorhandene Konfiguration von einer Datei in die Datenbank zu verschieben, führen Sie dies auf dem Server aus und starten Sie den Server anschließend mit AM_CONFIG auf dieselbe URL gesetzt:

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

Umgebungsvariablen

Jede Einstellung kann auch als Umgebungsvariable angegeben werden. Variablen haben Vorrang vor der gespeicherten Konfiguration, was sie gut für das macht, was zur Bereitstellung gehört: die Datenbank, die Site-URL, der Dateispeicher, die Ports.

Namensregel

Schreiben Sie AM_, dann den Abschnitt, dann den Schlüssel, in Großbuchstaben und durch Unterstriche getrennt. Die Wörter innerhalb eines Abschnitts- oder Schlüsselnamens werden nicht getrennt:

• Einstellungen für wahr und falsch nehmen true oder false; Zahlen sind einfache Zahlen.
• Listen-Einstellungen nehmen ihre Werte durch Leerzeichen getrennt an, zum Beispiel AM_SERVICESETTINGS_TRUSTEDPROXYIPHEADER="X-Forwarded-For X-Real-IP".
• Einstellungen, die Objekte sind, nehmen JSON an. Die einzige solche Variable für Apps ist AM_PLUGINSETTINGS_PLUGINS, und sie ersetzt die Einstellungen von jeder App auf einmal: Setzen Sie App-Einstellungen stattdessen in der Systemkonsole oder mit amctl (siehe unten).
• Ältere Mattermost-Installationen verwenden das Präfix MM_, zum Beispiel MM_SQLSETTINGS_DATASOURCE. Dies funktioniert weiterhin als Legacy-Alias. Wenn beide gesetzt sind, hat die AM_-Variable Vorrang.

Eine über eine Variable gesetzte Einstellung ist in der Systemkonsole gesperrt, mit dem Hinweis „Diese Einstellung wurde über eine Umgebungsvariable gesetzt. Sie kann nicht über die Systemkonsole geändert werden.“ Sie wird nicht in der gespeicherten Konfiguration geschrieben: Entfernen Sie die Variable, und der gespeicherte Wert wird wieder angewendet.

Mit Docker Compose

Fügen Sie die Variablen unter environment: des antimatter-Services hinzu oder in eine compose.override.yaml neben compose.yaml (Compose liest sie automatisch ein, und sie bleibt bei Updates der heruntergeladenen Datei erhalten):

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

Wenden Sie Änderungen mit docker compose up -d an, was den Container neu erstellt.

Von den Apps gelesene Variablen

Einige Variablen sind keine Einstellungen und haben kein Feld in der Systemkonsole: AM_CONFIG (wo die Konfiguration liegt) sowie AM_AI_ENCRYPTION_KEY und AM_AI_ENCRYPTION_PREVIOUS_KEYS, der Schlüssel, der die API-Schlüssel der Modellverbindungen verschlüsselt (siehe KI).

Einige Apps lesen ihre eigenen Variablen, die im antimatter-Service gesetzt sind: Die Calls-App liest AM_CALLS_* (siehe Anrufe und Sprache), und die GIFs-App liest AM_GIFS_SERVICE_URL, AM_GIFS_API_KEY und AM_GIFS_UPLOAD_KEY (siehe Mitgelieferte Apps).

Die Systemkonsole

Die Systemkonsole ist der Verwaltungsbereich der Web-App für Systemadministratoren. Um sie zu öffnen, klicken Sie auf Ihr Bild oben in der App-Leiste und wählen Sie Systemkonsole aus, oder gehen Sie zu https://chat.example.com/admin_console. In der Seitenleiste befindet sich ein Feld Einstellungen finden, das alle Seiten durchsucht.

Ihre Abschnitte sind:

• Berichterstattung: Statistiken und Serverprotokolle.
• Benutzerverwaltung: Benutzer, Gruppen, Communities (aufgeführt als Teams), Kanäle, Berechtigungen und delegierte Verwaltung.
• System-Attribute: benutzerdefinierte Profilattribute und attributbasierte Zugriffssteuerung.
• Umgebung: Webserver, Datenbank, Dateispeicher, Bild-Proxy, SMTP, Push-Benachrichtigungen, Ratenbegrenzung, Protokollierung, Sitzungsdauer, Leistungsüberwachung.
• Systemkonfiguration: Branding, Benutzer und Teams, Benachrichtigungen, Beiträge, Dateifreigabe und weitere serverweite Einstellungen.
• Authentifizierung: Registrierung, Anmeldung per E-Mail und Passwort, MFA, AD/LDAP, SAML 2.0, OAuth 2.0, OpenID Connect und Gastzugriff.
• KI: Modellverbindungen und die integrierten KI-Funktionen (Umschreiben, Zusammenfassungen, automatische Übersetzung, Text-to-Speech). Siehe KI.
• Plugins: App-Verwaltung und die Einstellungen jeder installierten App.
• Integrationen: Webhooks, Slash-Befehle, Bot-Konten, GIFs, Text-to-Speech, CORS.
• Compliance: Datenaufbewahrung, Compliance-Export und -Überwachung, Audit-Protokollierung, benutzerdefinierte Nutzungsbedingungen.
• Experimentell: Funktionen, die sich ändern können.

In diesem Leitfaden wird eine Einstellung als ihr Pfad in der Systemkonsole, dann ihr Label und dann ihr Konfigurationsschlüssel angegeben, zum Beispiel Systemkonsole › Systemkonfiguration › Benutzer und Teams › Ignorieren, Blockieren und Nachrichten anfragen aktivieren (PrivacySettings.EnableUserBlocking).

Die meisten Änderungen werden wirksam, sobald Sie auf Speichern klicken. Einige (die Adress, die der Server lauscht, bestimmte Datenbank- und Cache-Einstellungen) erfordern einen Neustart; die Seite weist darauf hin.

Community oder Arbeitsbereich

Jede Community hat einen Typ, der einige ihrer Standardwerte festlegt:

• Community für öffentliche oder Hobby-Communities: In ihren Kanälen sind Anrufe deaktiviert (die Kommunikation erfolgt über Sprachkanäle), und nur ihre Administratoren sowie die Rollen, die Kanäle verwalten, können Kanäle archivieren.
• Arbeitsbereich für Unternehmen oder Organisationen: In ihren Kanälen sind Anrufe aktiviert, und die Administratoren eines Kanals (der Ersteller sowie von ihm ernannte Administratoren) können ihn ebenfalls archivieren.

Systemkonsole › Systemkonfiguration › Benutzer und Teams › Art der neuen Communities (TeamSettings.DefaultCommunityKind, AM_TEAMSETTINGS_DEFAULTCOMMUNITYKIND) bestimmt die Art der künftig erstellten Communities: Community (Standard) oder Arbeitsbereich; die Einstellung speichert und liest weiterhin die älteren Werte community und workplace. Ein beim Erstellen einer Community gewähltes Layout-Preset legt deren eigene Art fest. Die Administratoren jeder Community können die Art später unter Teameinstellungen › Allgemein ändern. Neue Communities setzen alle Mitglieder in jeden Kanal (TeamSettings.AllChannelsMembershipForNewTeams) ist nur der Standard für neue Communities: Arbeitsbereiche starten niemals auf diese Weise (siehe Alle in jedem Kanal).

Nachrichten, die nach dem Lesen gelöscht werden

Benutzer können Nachrichten senden, die eine Weile nach dem Öffnen durch jeden Leser gelöscht werden (siehe Löschen-nach-Lesen-Nachrichten). Die Einstellungen finden Sie in der Systemkonsole › Systemkonfiguration › Beiträge unter Löschen-nach-Lesen Nachrichten:

Die längste Dauer wird beim Lesen einer Nachricht erneut überprüft, sodass eine Herabsetzung auch bereits gesendete Nachrichten verkürzt.

Das amctl-Befehlszeilenwerkzeug

amctl verwaltet einen Server über die Befehlszeile: Benutzer, Communities, Kanäle, Apps, Konfiguration, Jobs und mehr. Es kommuniziert mit dem Server auf eine von zwei Arten.

Lokaler Modus, auf dem Server

Der lokale Modus ermöglicht es amctl, über einen Unix-Socket mit dem Server zu kommunizieren, ohne sich anmelden zu müssen. Er ist im Docker-Image sowie bei den .deb- und .rpm-Paketen aktiviert. Bei einem Server, der aus einem Archiv installiert wurde, aktivieren Sie ihn über ServiceSettings.EnableLocalMode (AM_SERVICESETTINGS_ENABLELOCALMODE=true). Der Socket liegt standardmäßig unter /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

Remote, mit einem Konto

Von jedem Computer aus melden Sie sich mit einem Systemadministrator-Konto (oder einem persönlichen Zugriffstoken) an und führen Sie dann Befehle gegen diesen Server aus:

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

Konfigurationsbefehle

App-Einstellungen befinden sich unter PluginSettings.Plugins.<app id>, mit Schlüsseln in Kleinbuchstaben. Zum Beispiel, um die Service-URL und den Schlüssel der GIFs-App vom Docker-Host aus zu setzen:

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

Weitere nützliche Befehle: amctl user create, amctl user deactivate, amctl team create, amctl plugin list, amctl plugin enable, amctl system supportpacket und amctl logs. Führen Sie amctl help <command> für die Optionen jedes Befehls aus.

Protokolle

Der Server schreibt sein Protokoll an zwei Stellen, jeweils mit eigenem Level (DEBUG, INFO, WARN oder ERROR), eingestellt unter Systemkonsole › Umgebung › Protokollierung:

Protokolldateien werden bei 100 MB rotiert und die älteren Dateien komprimiert.

Die Compose-Datei der Website schaltet das Protokollieren in Dateien ab (AM_LOGSETTINGS_ENABLEFILE=false), sodass die Protokolle nur in der Container-Ausgabe zu finden sind:

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

Die Konsole-Ebene ist standardmäßig auf DEBUG gesetzt, was sehr ausführlich ist. Auf einem stark ausgelasteten Server sollten Sie AM_LOGSETTINGS_CONSOLELEVEL=INFO setzen. Die config.json des Release-Archivs und der Pakete ist bereits auf INFO eingestellt. Bei einem Release-Archiv unter systemd wird die Konsolenausgabe im Journal (journalctl -u antimatter) und die Datei unter /opt/antimatter/logs/antimatter.log gespeichert. Die Pakete deaktivieren die Protokollierung in Dateien, sodass deren Protokolle nur im Journal zu finden sind.

Protokoll- und Auditdateien müssen sich innerhalb des Protokollstammverzeichnisses befinden: AM_LOG_PATH (das ältere MM_LOG_PATH funktioniert weiterhin), sofern festgelegt, andernfalls im Ordner logs. Dies ist standardmäßig aktiviert: Ein Log-Verzeichnis, ein erweitertes Protokollierungsziel oder ein Pfad für das Auditprotokoll außerhalb des Stammverzeichnisses verhindert den Start des Servers und wird beim Speichern der Konfiguration abgelehnt. Schalten Sie die Durchsetzung mit AM_FEATUREFLAGS_ENFORCELOGPATHROOT=false aus. Wenn AM_LOG_PATH festgelegt und das Log-Verzeichnis leer gelassen wird, werden die Protokolle in AM_LOG_PATH geschrieben.

Wenn die Protokollierung in Dateien aktiviert ist, können Systemadministratoren das Protokoll auch in der Systemkonsole › Berichterstattung › Serverprotokoll lesen: farblich gekennzeichnete Level-Badges, schnelle Filter nach Level, ein Live-Tail und Zeitbereichsvorgaben von 5 Minuten bis 24 Stunden, oder mit amctl logs.