Gefühlt wird in der gesamten Welt geslackt und gewhatsappt. Ich persönlich mag’s aber mehr so Open Source und unter meiner Kontrolle. Nachdem mich ein Freund nun schon zum zweiten Mal auf Rocket.Chat aufmerksam gemacht hat, habe ich es mal eingerichtet. Das scheint mir verdächtig nah an den derzeit hippen Slack heranzukommen und Apps fürs Smartphone gibt es auch. Hier beschreibe ich aber erstmal die Installation.

Installation auf Univention

Mein Univention-Server ist ein Derivat von Debian, so wie Ubuntu auch eines ist. In diversen Blogs fand ich Anleitungen zum Einrichten von Rocket.Chat auf Ubuntu und Debian, letztendlich folgte ich [1]. Die notwendigen Pakete waren zum Glück alle einfach zu installieren. Im ersten Schritt war die Systembasis zu erweitern:

apt-get install git curl build-essential imagemagick

Geschrieben in JavaScript …

Rocket.Chat wird in JavaScript entwickelt und benötigt eine Node.js-Laufzeitumgebung. Diese ist in den Debian-Derivaten bereits enthalten:

apt-get install nodejs npm

Dabei ist npm der „Node.js Package Manager“, mit dem gleich im Anschluss das Paket nave (virtuelle Umgebungen in Node) nachinstalliert und eingerichtet wird. Später benötigen wir auch noch den Service forever, der aus dem JavaScript-Tool Rocket.Chat einen wirklichen Server-Dienst macht:

npm install nave -g
nave usemain 0.10.43
npm install forever -g

MongoDB einrichten

Als Datenbank kommt die NoSQL-Datenbank MongoDB zum Einsatz. Von unseren Entwicklern habe ich mal gelernt, dass man JSON-Queries von JavaScript-Applikationen damit viel besser verarbeiten kann … nehmen wir das mal zur Kenntnis ;-). Wichtig ist: In Ihrer Grundkonfiguration wird die MongoDB ca. 6GB Speicherplatz (unter /var/lib/mongodb) benötigen!

Die Installation erfolgt über:

apt-key adv –keyserver hkp://keyserver.ubuntu.com:80 –recv 7F0CEB10
deb http://repo.mongodb.org/apt/debian wheezy/mongodb-org/3.0 main
apt-get update
apt-get install mongodb-org

Der erste Start der Datenbankkonsole wird es sowieso empfehlen, also kann man auch gleich in der Datei /etc/rc.local ein paar bremsenden Speicherchecks abschalten:

echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo never > /sys/kernel/mm/transparent_hugepage/enabled

In der Konfigurationsdatei der Datenbank selbst (/etc/mongod.conf) sind folgende Einträge vorzunehmen:

replication:
replSetName: „001-rs“

Danach kann die MongoDB per …

service mongod restart
mongo

… neu gestartet werden. Der Aufruf von „mongo“ führt uns direkt in die Konsole der Datenbank. Hier wird die Datenbank mit dem Befehl „rs.initiate()“ initialisiert. Wenn alles gut geht, dann sieht das wie folgt aus:

MongoDB shell version: 3.0.12
connecting to: test
> rs.initiate()
{
„info2“ : „no configuration explicitly specified — making one“,
„me“ : „SERVERNAME:27017“,
„ok“ : 1
}
001-rs:PRIMARY>

Am Prompt kann die Konsole durch Eingabe von „exit“ verlassen werden.

Wenn die Fehlermeldung „No host described in new configuration 1 for replica set 001-rs maps to this node“ auftaucht, dann muss der Ame des Servers noch als Alias von 127.0.0.1 in die Datei /etc/hosts eingetragen werden.

Installation von Rocket.Chat selbst

Es gibt (noch) keine fertigen Pakete für Rocket.Chat. Deswegen habe ich die Installation ins Verzeichnis /opt/ durchgeführt:

curl -L https://rocket.chat/releases/latest/download -o rocket.chat.tgz
tar -xzf rocket.chat.tgz
mv bundle rocket.chat

Im Server-Verzeichnis macht man das Skript dann dem lokalen npm bekannt:

cd rocket.chat/programs/server
npm install

Die vielen Warnungen, die dann angezeigt werden, habe ich ignoriert. Mit drei zu exportierenden Variablen sind dem Rocket.Chat ein paar Rahmendaten mitzugeben und dann … dann geht es los:

export ROOT_URL=http://<SERVER>/
export MONGO_URL=mongodb://localhost:27017/rocketchat
export PORT=3000
node main.js

Nach ungefähr einer Minute zeigte mit ein grünes „SERVER RUNNING“ an, dass ich auf meinen neuen Chat-Service zugreifen kann.

Verwaltungstechnische Maßnahmen

So ein Start von Hand ist natürlich nicht das Wahre. Deswegen habe ich eine unter /etc/default/rocketchat (hier muss der Servername angepasst werden!) abzulegende Konfigurationsdatei und ein unter /etc/init.d/rocketchat zu platzierendes Init-Skript gebaut. Hier habe ich das Wissen einfließen lassen, dass ich mir unter [2] angelesen habe. Entpackt und an die richtige Stelle kopiert aktiviert man das Init-Skript wie folgt:

update-rc.d rocketchat start 91 2 3 4 5 . stop 09 0 1 6 .

Damit startet und endet der Chatserver gleichzeitig mit dem Apache-Dienst. Von nun an startet der Service per „service rocketchat start„, lässt sich ebenso beenden und wird beim Booten automatisch mitgeladen.

Apropos Apache … da scheiden sich ja die Geister. Im worst case könnte man natürlich den TCP-Port 3.000 auf der Firewall öffnen, um mit dem Rocket.Chat zu sprechen. Das würde man wie folgt machen:

ucr set security/packetfilter/tcp/3000/all=ACCEPT
service univention-firewall restart

Aber eigentlich will man das nicht. Viel eleganter ist es doch, über Port 80 oder 443 mit einem transparenten Proxy zu arbeiten. Die Weiterleitung in der Art http://univentionserver/chat auf meinen Chat-Server habe ich nicht hinbekommen – vielleicht geht das auch gar nicht. Letztendlich konnte ich mir einen Proxy auf http://chat.univentionserver/ einrichten. Dazu habe ich die Datei /etc/apache2/sites-available/rocketchat angelegt, diese ins Verzeichnis „sites-enabled“ verlinkt und den Apache2-Dienst neu gestartet.

Sperrt man sich damit von allen anderen Diensten des Univention-Servers aus, so sollte der Eintrag

ServerName univentionserver

(wenn man über http://univentionserver auf das Management-Interface zugreift) in /etc/apache2/sites-available/default hinzugefügt werden.

Ersteinrichtung und LDAP

Der erste Benutzer, den man in Rocket.Chat anlegt, ist immer der Admin-Benutzer. Den Beschreibungen unter [3] folgenden, habe ich über http://chat.univentionserver/admin/LDAP die LDAP-Konsole aufgerufen und folgende Werte angepasst:

LDAP aktivieren: ja
LDAP-Host: localhost
LDAP-Port: 389
Domain Search User: uid=Administrator,cn=users,dc=DOMAIN,dc=TLD
Passwort der Domainsucher: PASSWORT
Domainbasis: cn=users,dc=DOMAIN,dc=TLD
Domain Search User ID: uid
Objektklasse der Domainsuche: kopano-user
Objektkategorie der Domainsuche:
Nutzernamenfeld: gecos
Eindeutige Kennung des Felds: uidNumber
Daten synchronisieren: ja
Nutzerdaten-Feldkarte: {„gecos“:“name“, „mail“:“email“}

Und das war es auch schon ;-). Von jetzt an können sich auf meinem Univention-System all‘ die Benutzer, die auch Kopano-Benutzer sind, an Rocket.Chat anmelden.

Wie weiter?

Jetzt werde ich mich erstmal auf in den Google Play Store machen und mir die Rocket.Chat-App herunterladen. Und dann werden Erfahrungen gesammelt …

[1] https://www.rosehosting.com/blog/install-rocketchat-on-an-ubuntu-14-04-vps/
[2] http://www.slidequest.com/q/70ang
[3] https://rocket.chat/docs/administrator-guides/authentication/ldap/

3 Responses

  1. Sehr cool 🙂

    Btw: Falls du (oder jemand anderes) irgendwann mal in die Verlegenheit kommen sollte und auf dem UCS auch noch Samba AD betreibt, müsste man den LDAP-Port von 389 auf 7389 umstellen, weil OpenLDAP dann nur noch dort lauscht. 7389 für OpenLDAP funktioniert auch ohne Samba AD schon und ist daher die update-sicherere Variante 😉

  2. Sieht ganz interessant aus…

    Die genannten Alternativen unterstützen im UI AFAIK keine Sub-Threads mit entsprechenden Ansichten.

    Wie sieht das bei Rocket.Chat aus?

    • Ich nutze Rocket Chat seit geraumer Zeit schon nicht mehr. Aber soweit ich mich erinnere, kann da so wie auch in Mattermost in und Slack auf Beiträge geantwortet werden. Diese Antworten lassen sich dann als Sub-Thread darstellen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.