Angespornt durch den großen Erfolg von Tools wie WhatsApp oder Telegram interessieren sich nun doch zunehmend mehr kommerzielle Anwender für Chatdienste als Alternative zur E-Mail für die unternehmensinterne Kommunikation. Dabei locken auch Tools, Bots und Plug-ins, die andere Applikationen direkt in die Chatforen einbinden. Dadurch können beispielsweise Sachbearbeiter nicht nur mit den Kollegen im Teamchat aktuelle Fälle besprechen, sondern auch gleich Informationen zu aktuellen Tickets und deren Bearbeitungsstatus via Bot aus dem Ticketsystem in die Kommunikation integrieren.

Zu den aktuell populärsten Chatdiensten für Unternehmen gehört Slack - unter anderem auch deshalb, weil es für Slack Integrationen mit nahezu allen handelsüblichen Business-Applikationen und -Tools gibt. Doch das hat, wie alle Cloudanwendungen, natürlich wieder einen Haken: Die vertrauliche Unternehmenskommunikation landet irgendwo in der Amazon-Cloud. Zwar können Business-Anwender dabei wählen, in welcher Region sie ihre Daten speichern wollen und in welchem (anderen) Land dann das Backup liegt. Aber grundlegende Organisationsdaten, sowie auch die Benutzerprofile landen auf US-Servern.

Natürlich wissen Sie bereits, was an dieser Stelle als Nächstes kommt: Wer den Komfort und die Funktionalität von Tools wie Slack verwendet, seine Daten aber nicht einer Cloud oder einem US-Unternehmen anvertrauen will (oder darf), der kann natürlich auf selbstgehostete Open-Source-Programme zurückgreifen. Wie kompliziert Setup und Betrieb der populären, quelloffenen Optionen Zulip [1], Mattermost [2] oder Rocket.chat [3] ausfallen und wie sich diese Plattformen mit anderen Applikationen verzahnen, betrachten wir in diesem Artikel aus der Nähe.

Bei der Suche nach einer lokalen Chat-Groupware gibt es eine Reihe von Auswahlkriterien: Existieren Clients für alle benötigten Zielplattformen (Web, Desktop, Mobile) und verfügen sie über Push-Benachrichtigungen? Für welche Zielplattformen gibt es fertige Plug-ins und Bots? Falls keine fertigen Integrationen bestehen, wie aufwendig ist es dann, eigene zu schreiben und auf der Chat- und Applikationsseite zu integrieren? Wie sicher sind Datenhaltung und Backup der Plattform?

Anders als frühere Plattformen wie IRC oder NNTP nutzen moderne Chat-Groupwares keine proprietären Binärprotokolle mehr. Jegliche Kommunikation auch zu den Bots läuft über HTTPS, wobei der Chatserver selbst sich hinter einem SSL-terminierenden Proxy verstecken darf. Somit erfordert eine Chatumgebung auch keine dezidierte IP-Adresse im Internet, sondern läuft auf einem gehosteten System oder in der DMZ des lokalen Rechenzentrums hinter einem Reverse Proxy mit name-based Routing. In Sicherheitsrelevanten Umgebungen (Air Gap) kommen selbstgehostete Chatserver auch ganz ohne Internetanbindung aus. Alle arbeiten dabei mit der üblichen Web-Application-Server-Architektur: Datenbankserver plus Chatapp. Das Ganze lässt sich traditionell in einer VM installieren oder auf einer Container-Plattform wie Docker, Podman oder Kubernetes betreiben. Wir betrachten daher also auch die Vor- und Nachteile des jeweiligen Betriebsmodus und probieren verschiedene Ansätze aus.

Eigentlich existiert der Chatserver Zulip schon länger als Slack. Die Software wurde bereits 2012 vorgestellt. Das Unternehmen Zulip offeriert sowohl eine SaaS-Variante in der Cloud als auch kostenpflichtigen Support für lokale Setups. Für die Community-Version fallen keine Kosten an, aber dafür fehlt auch der Support. Technisch und funktionell besteht bei Zulip kein Unterschied zwischen der kommerziellen und der freien Variante - beide verfügen über den vollen Funktionsumfang.

Zulip fordert eine ganze Reihe von Diensten im Backend. Zum PostgreSQL-Server für die Datenhaltung kommen sowohl Redis als auch Memcached und RabbitMQ hinzu. Memcached sorgt für eine bessere Performance speziell in Umgebungen mit vielen Nutzern. Aber Redis und RabbitMQ bieten ähnliche Funktionalitäten, sodass eigentlich eines der beiden genügen müsste. Die Entwickler beschreiben in der Dokumentation, warum sie jedoch auf die Konsolidierung der beiden Dienste verzichten. Das etwas aufwendigere Setup soll - speziell in größeren Setups - die Last besser auf die Dienste verteilen und die Performance verbessern.

Die Einrichtung kann etwa klassisch in einer virtuellen Maschine erfolgen. Der Hersteller bevorzugt jedoch eine Installation mit Containern und Docker. Für unsere Testumgebung nutzten wir ein LANP-Setup mit Ansible, Nginx und Podman, wie wir es im Artikel "Container-Management mit Ansible" in Ausgabe 03/2023 [4] beschrieben haben. Das Podman-Setup packt alle Komponenten als Container in einen einzigen Pod und gibt nur einen HTTP-Port nach außen frei. Der vorgeschaltete Nginx-Reverse-Proxy sorgt für die SSL-Terminierung. Prinzipiell genügt es, das vom Hersteller beschriebene Docker-Compose-File [5] in ein Ansible-Playbook zu übertragen (was wir aufgrund der schieren Länge hier nicht abdrucken), allerdings mit zwei Abweichungen.

Memcached versucht im laufenden Container, ein temporäres Verzeichnis zu erstellen, was unter Docker mit root-Rechten zwar funktioniert, nicht jedoch mit Podman. Daher braucht der Memcached-Container ein persistentes Volume für das Verzeichnis "/home/memcache", und schon läuft das Tool unter Podman. Damit Zulip mit HTTP hinter einem Reverse-Proxy läuft, muss der Anwender die Konfigurationsdatei anpassen, denn im Basissetup würde die Software gerne selbst das HTTPS-Protokoll steuern und die Zertifikate integrieren. Das Compose-File sieht es aber nicht vor, die Konfigurationsdatei von Zulip in einem persistenten Volume vorzuhalten. Fügen Sie diese Option im Ansible-Playbook hinzu:

können Sie im passenden Unterverzeichnis des Hosts ("/var/pods/zulip/etc") die Konfigurationsdatei"zulip.conf" entsprechend anpassen, die Zeilen

hinzufügen und somit die SSL-Terminierung an Nginx übergeben. Zudem sind dann die Konfigurationsdateien "settings. py" sowie "zulip-secrets.conf" nach Ihren eigenen Wünschen anpassbar. Das ist auch notwendig, um Zulip den Zugang zu einem Mailserver zu verschaffen. Erst wenn die Software via SNMP-Nachrichten versenden kann, lassen sich weitere Benutzer einladen. Erweitern Sie das Mailsetup mit einer IMAP-Konfiguration, ist Zulip zudem in der Lage, über eigene Adressen E-Mails zu empfangen und in Chatforen einzufügen.

Zulip offeriert Clients für alle gängigen Client-Betriebssysteme und mobilen Devices oder läuft im Browser. Im Prinzip sind eigentlich alle Clients nur Wrapper für einen Browser. Die UI der Version 8.4 stellt sich aufgeräumt dar, wirkt allerdings etwas altmodisch mit der Rahmen- und Kastenoptik der 2010er-Jahre. Zulip kennt alle üblichen Funktionen wie Chatforen und Direktnachrichten. Interessant wird es dann bei den Bot- und Plug-in-Funktionen. Benutzer mit den passenden Berechtigungen dürfen einen oder mehrere Bots in Ihrem Profil erstellen. Diese Bots versenden entweder ausgehende Nachrichten an Webhooks oder stellen selbst einen Webhook für eingehende Nachrichten bereit.

Zulip kennt eine Reihe gängiger Json-Formate anderer Dienste wie Github, Gitlab oder Ansible. So kann der Anwender für einen seiner Bots beispielsweise eine "Gitea"-Webhook-Url erstellen. Diese trägt er dann in seinem Gitea-Repository ein. Bei Repository-Events wie einem Commit oder Pull-Request sendet Gitea dann eine Nachricht in das Zulip-Forum oder direkt an den Nutzer. Zudem lässt sich der Account des Bots für externe Zugriffe via Rest-API einsetzen. Outgoing-Bots übermitteln Nachrichten aus den aktiven Foren an Webhook-URLs. Dabei können Anwender festlegen, ob das Format von Slack oder Zulip zum Einsatz kommt. Offerieren externe Tools also einen Incoming-Webhook für Slack, funktionieren diese auch mit Zulip. Wem die simple Webhook- und RestAPI-Funktionalität der Zulip-Bots nicht genügt, kann man auch eigene Bots in Python programmieren. Die Zulip-Dokumentation beschreibt recht ausführlich, wie das funktioniert.

Für das Housekeeping liefert Zulip ein kleines Managementtool mit. Läuft der Server in Containern, lässt sich das Werkzeug jedoch nur mit etwas Aufwand nutzen. Mithilfe dieses Tools setzen Sie Passwörter zurück oder legen Nutzer direkt ohne den Umweg via Invite-Mail an. Theoretisch könnte "manage.py" auch direkt ein Backup Ihrer Zulip-Umgebung erstellen. Allerdings funktioniert das nur in einem traditionellen VM-Setup richtig, bei dem Postgress und Zulip auf demselben System laufen. Im containerisierten Setup hat das Backuptool keinen Zugang zum Datenbankserver, denn der läuft in einem anderen Container. "manage.py backup" funktioniert hier also nur mit der Option "--skip-db" und Sie müssen die Datenbank im PostgreSQL-Container selbst sichern.

Der Zulip-Server arbeitet flott und lässt sich simpel mit Podman aufsetzen. Das flexible Bot-System kommt allen Anwendern entgegen, die die Chatplattform mit anderen Tools integrieren möchten. Die freie Open-Source-Version verfügt über den vollen Funktionsumfang.

Mattermost entstand ursprünglich als proprietäres, hausinternes Kommunikationstool eines Unternehmens aus dem Bereich der Spieleentwicklung. Es wurde 2015 als Open-Source-Projekt ausgelagert und seither von dem eigens hierfür gegründeten Unternehmen Mattermost Inc betreut. Die Firma verkauft Supportverträge für Mattermost-Installationen und zusätzliche Funktionen, die nicht Teil der Open-Source-Version sind.

Für den Betrieb reicht Mattermost eine PostgreSQL-Datenbank und der eigene Serverdienst. Um SSL könnte sich der Server selbst kümmern, bevorzugt aber den Betrieb hinter einem SSL-terminierenden Reverse-Proxy. Somit können Administratoren die Lösung containerisiert auf Docker, Podman oder Kubernetes betreiben. Für unseren Test setzen wir hier eine klassische VM ein. Die Installation auf CentOS-Stream 9 ist sehr einfach und in zwei Schritten - Datenbank-Vorbereitung [6] und Dienstsetup [7] - nach wenigen Minuten erledigt. Das EL-Setup nutzt ein Tarball-Image, was das Upgrade des Servers auf neue Versionen etwas aufwendiger gestaltet. Die Einrichtung auf Debian/Ubuntu lässt sich hierbei einfacher betreuen, da es für diese Plattform ein PPA-Repository gibt und damit die Installation und Updaes einfach via "apt" erfolgen.

Für simple Funktionstests im lokalen LAN verzichten wir auf ein HTTPS-Setup mit Proxy, hier genügt der HTTP-Zugang zum Port 8065 des Servers. Wie auch bei Zulip genügt bereits ein Webbrowser für den Zugriff auf den Chatserver. Zudem gibt es Clients für alle Desktop- und Mobile-Plattformen. Die Mattermost-UI wirkt etwas aufgeräumter und moderner als Zulip. Das führt jedoch im Gegenzug dazu, dass der Anwender einige Funktionen erst aus Untermenüs heraussuchen muss, die er in der Zulip-Benutzerführung schneller findet.

Dem Administrator steht eine Systemkonsole zur Verfügung. Darüber kann er den Server mit seinen Funktionen sowie Teams und Benutzer verwalten. Auf dem Server selbst gibt es überdies ein Admin-CLI-Tool namens "mmctl". In der Systemkonsole finden sich dann auch die Premiumfunktionen, die nur zahlenden Nutzern zur Verfügung stehen. Dazu zählen vor allem die Integration des Mattermost-Servers in ein AD- oder LDAP-Benutzerverzeichnis und die Single-Sign-on-Dienste. Auch den Guest-Access mit eingeschränkten Rechten für Nutzer von außerhalb der Organisation gibt es nicht in der Open-Source-Variante.

Ähnlich wie bei Zulip kennt Mattermost Bots für Incoming- oder Outgoing-Webhooks. Die Bots fungieren hier jedoch nicht als Teil eines Benutzerkontos, sondern als eigenständige User. Gerade bei den eingehenden Hooks fehlt es jedoch an der Flexibilität. Die Formatierung des ankommenden JSON-Arrays ist recht starr und kennt eigentlich nur das Slack-Format. Zulip beherrscht hier bereits eine Vielzahl anders formatierter Nachrichten sowie die Option, angepasste Bots für das JSON-Parsing in Python zu schreiben.

Weitere Funktionalität erhält Mattermost über Apps, die der Benutzer aus einem App-Store installiert oder als Plug-in auf seinen Server hochlädt. Diese liefern wahlweise zusätzliche Chat-Funktionalitäten wie Polls oder eine bessere Integration mit externen Diensten wie Github. Nutzer können eigene Plug-ins schreiben und in die Lösung integrieren.

Neben den Gruppenchats offeriert Mattermost eine Funktion mit dem Namen "Playbook". Hier lassen sich Workflows für Teams modellieren und starten. Mattermost informiert die beteiligten Nutzer dann, wenn sie Tasks als Teil des Playbooks zu erledigen haben. Auch hier bekommen die Nutzer der freien Version nur Teile der Funktionalität. Playbook-Schritte wie beispielsweise ein Fälligkeitsdatum in einer Task-Zuweisung stehen nur zahlenden Kunden zur Verfügung.

Ein integriertes Backupskript bringt die Software nicht mit, beschreibt in der Dokumentation aber genau, welche Dateien und Verzeichnisse der Nutzer zusätzlich zum PostgreSQL-Datenbankdump sichern muss.

Mattermost wartet mit einer etwas moderneren UI auf und arbeitet mit einem simpleren Backend, als es bei Zulip zum Einsatz kommt. Die Funktionalität setzt mehr auf Apps und die Workflow-Funktionen der Playbooks, zeigt sich dabei etwas weniger flexibel bei der Bot- und Webhook-Gestaltung und enthält den Anwendern der freien Version einige Funktionen vor.

Auch der Rocket.Chat-Server kann als Snap oder containerisiert laufen. Im Testsetup setzen wir dafür Docker auf einem CentOS-Streams-9 System ein und starten den Dienst über das bereitgestellte Docker-Compose-File. Rocket setzt dabei zwei Container ein: MongoDB für die Datenhaltung und den eigenen Serverdienst. Letzterer stellt das Webinterface auf dem HTTP-Port 3000 zur Verfügung, sodass der Administrator hier selbst seinen SSL-terminierenden Proxy voranstellen kann.

Bei der Erstinstallation legt der selbst gehostete Server einen Systemadministrator an und möchte im Anschluss online bei Rocket.Chat registriert werden. Das ist bei Testinstallationen im lokalen LAN oder einem isolierten Netzwerk natürlich nicht im Sinne des Verwalters. Einen simplen "Bitte überspringen / Kein Interesse an der Online-Registrierung"-Button weist das Tool dabei leider nicht auf. Erst nach einer längeren Suche in der Dokumentation findet sich im Kleingedruckten der Hinweis auf eine Konfigurationsoption. Entweder fügt der Anwender bei einer lokalen Installation das Schlüsselwort

in die Konfigurationsdatei "Rocker.Chat.Extra.env" ein. In unserem Beispiel mit Docker Compose jedoch muss der Schalter in das compose-File:

Wie bei den anderen Tools auch lässt sich Rocket.Chat via Browser, mobile oder Desktop-App bedienen. Die Web-UI ist sehr stark dem Marktführer Slack nachempfunden. Das Hauptaugenmerk bei Rocket.Chat liegt auf der Chatfunktionalität und der Integration des Chats in weitere Anwendungen.

Die Applikation lässt den Anwender der Community-Edition in jedem zweiten Menü spüren, dass er doch viel lieber mit einer lizenzierten Variante ans Werk gehen und nicht die freie Edition nutzen sollte. Alle erweiterten Tools wie die AD/SAML/ LDAP-Intregration, der App-Marketplace, die Geräteverwaltung oder das Dashboard stehen nur Anwendern der kostenpflichtigen Version zur Verfügung.

Anwender haben aber auch ohne fertige Applikationen aus dem Marketplace die Möglichkeit, ihr Setup zu erweitern. Der Hersteller offeriert ein Toolkit für die Entwicklung eigener Rocket.chat-Anwendungen mit dem Namen "Apps-Engine CLI". Mit diesem Toolkit und den passenden TypeScript-Kenntnissen können User ihre eigenen Plug-ins schreiben und in ihren Chatserver einbauen. Das Ganze hat aber leider einen Haken: Die Apps-Engine-CLI lässt sich nicht in einer mit Docker-Compose aufgesetzten Umgebung installieren. Für die Anwendungsentwicklung muss sich der Anwender also eine zweite, klassische Umgebung in einer VM einrichten.

Unser Setup von Rocket.chat in einer Ubuntu-24.04-VM mithilfe des Snap-Paketmanagers lief problemlos ab. Allerdings setzt Snap dabei nicht die sonst übliche Verzeichnisstruktur von Linux-Servern ein, sondern stopft die komplette Installation samt Mongo-DB in Verzeichnisse irgendwo unter "/var/snap" und legt auch die Konfigurationsdateien dort ab. Den Mongo-DB-Server richtet das Snap-Setup zudem ohne jegliche Sicherheitsmaßnahmen wie Zugangspasswörter ein.

Nach der Installation von Node.js und den benötigten Abhängigkeiten erstellt das "rc-apps"-Kommando die gewünschten Entwicklungsumgebungen für Rocket.Chat-Erweiterungen. Die fertigen Applikationen rollt der Anwender via rc-apps --deploy auf der Plattform aus und weist ihnen dann entsprechende "Slash"-Kommandos zu. Aus dem Chat heraus starten Sie Anwendungen nach dem üblichen Schema "/myapp paramter1 parameter 2 …". In Sachen Bot-Integration via Webhook zieht Rocket.Chat mit Mattermost gleich. Auch hier gibt es simple Hooks, aber nur wenig Optionen, das JSON-Parsing für die Bot-Payload individuell anzupassen.

Mit den drei vorgestellten Diensten setzen Anwender selbst gehostete Chatplattformen für die Unternehmenskommunikation einfach auf. Auch wenn Zulip vielleicht nicht über die hübscheste UI verfügt, stellt es dem Nutzer den größten Funktionsumfang in der Open-Source-Variante zur Verfügung. Zum einen versteckt es keine Tools hinter einer Paywall und zum anderen bietet es simple und offene Anpassungsmöglichkeiten für Bots, den API-Zugriff und angepasste Webhooks.

Die Stärken von Mattermost liegen in den Playbooks. Richtig eingesetzt, lassen sich damit aufwendige Arbeitsabläufe sehr simpel in einem Chattool modellieren und umsetzen. Schade ist allerdings, dass der Anbieter einzelne Module oder sogar ausgewählte Funktionen wie die Terminoption des Playbooks selektiv aus der Open-Source-Variante entfernt.

Die größten Limitierungen der Open-Source-Variante präsentiert auf jeden Fall Rocket.Chat, das sich selbst hauptsächlich als kostenpflichtige Option für Slack-Nutzer sieht. Funktionell versucht die Plattform, mit dem Umfang und der Optik des Vorbilds Slack mitzuhalten, was auch gut gelingt. Die freie Version fühlt sich jedoch funktionell zu stark beschnitten und mehr wie eine Demoversion als eine Community-Lösung an.

Bei den Installationsvarianten lockt das containerisierte Setup mit Docker oder Podman mit dem größten Komfort. Allerdings muss der Administrator hier schon sehr genau prüfen, welche Images er sich da in seine Umgebung zieht. Zudem erschwert der Containerbetrieb die Nutzung von CLI-Tools, sofern die Plattform solche offeriert. Das klassische Setup in einer VM via Paketmanager oder Tarball verschafft mehr Kontrolle über die Konfiguration, Version und Sicherheit der einzelnen Komponenten. Optimal wäre wohl ein Container-Setup, bei dem der Anwender nur geprüfte und verifizierte Komponenten zulässt.