XMPP-Server

Ziel

Konkurrenzfähiger, zuverlässiger, selbst betriebener, erweiterbarer Instant Messenger mit allen derzeitig üblichen Funktionen.

Verantwortlich

• sqozz
• cfr34k
• citronalco

Benutzerzugänge

<wunschname>@bytewerk.org

Accounts werden auf Zuruf erstellt (siehe oben "Verantwortlich").

Das Passwort kann direkt im XMPP-Client geändert werden.

XMPP-Webclient

<Bingo-Benutzername>@bingo-ev.de

Jedes Bingo-Mitglied hat automatisch einen Account.

Die JID ist identisch zur E-Mail-Adresse, das Passwort ist das Bingo-E-Mail-Passwort.

Da zur Authentifizierung der Bingo-Mailserver benutzt wird, kann das Passwort nicht im XMPP-Client geändert werden.

XMPP-Webclient

Empfehlenswerte Clients

• Android: Conversations.im, Quicksy.im
• iOS: Monal.im
• Windows/Linux/BSD: Gajim
• macOS: PSI

In Thunderbird ist ein sehr einfacher Client (nur Text) ("Chat-Konto").

Für Nextcloud gibt es mit der ojsxc-App einen sehr gut ausgestatteten webbasierten Client.

Unterstützte Funktionen

• Gruppen
• Audio- und Videotelefonie
• Ende-zu-Ende-Verschlüsselung
• Dateiup- und Download (wird auch für Sprach- und Videonachrichten verwendet) - Dateigröße derzeit limitiert auf 20 MByte.
• Gleichzeitiges Verwenden mehrerer Clients

Die bei der Kommunikation mit einem bestimmten Gesprächspartner zur Verfügung stehenden Funktionen ergeben sich aus der Schnittmenge des Funktionsumfangs der beteiligten XMPP-Server und der XMPP-Clients.

Beispiel: Ist mein Gesprächspartner ein Shellskript, das mir eine Nachricht schickt wenn die Waschmaschine fertig ist, werde ich kein Videotelefonat mit dem Skript führen können auch wenn es der Server unterstützt.

Obacht bei der Verwendung von mehreren Clients gleichzeitig: Eine Nachricht gilt als zugestellt, wenn sie an EINEM Client des Empfängers angekommen ist. Das kann bei wackeliger Internetverbindung dazu führen, dass Nachrichten scheinbar nicht zugestellt wurden - sie landen dann nur bei dem Gerät, dass online war. Nicht alle Clients prüfen beim Wieder-Online-Gehen, ob in der Zwischenzeit Nachrichten für den Benutzer eingetroffen sind, die bereits an einem anderen Client zugestellt wurden. Threema, Whatsapp usw. umgehen das, indem sie keine parallele Nutzung zulassen.

Fortschritt

2021-01

Neukonfiguration des bestehenden XMPP-Servers mit Korrektur der DNS-Einträge und Installation zusätzlicher benötigter Dienste

2021-02

Implementierung abgeschlossen: Bei compliance.conversations.im statt 52% jetzt 100% "XMPP Specifications compliance".

2021-02

Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert

Implementierung

Auf der VM xmpp.bytewerk.org läuft:

• Prosody: XMPP-Server
• PostgreSQL: Datenbank
• Coturn: TURN und STUN (für Jingle/WebRTC benötigt, d.h. Audio-/Videotelefonie sowie Dateiübertragung von Client zu Client)
• ConverseJS: XMPP-Webclient
• Apache2: HTTPS-Reverse-Proxy für File-Up- und -Downloads, .well-known-URLs, BOSH und Websocket, Bereitstellung von ConverseJS
• Anonip: Wird zum Logging in Apache2 benutzt um in den Access-Logs die letzten Stellen der IP-Adressen auf 0 setzen. Liegt unter /usr/local/Anonip.git
• Certbot: Für TLS-Zertifikatsaktualisierung
• Crond: Um Certbot wöchentlich aufzurufen und täglich das Fileupload-Verzeichnis aufzuräumen
• etckeeper: Zum Nachverfolgen von Konfigurationsänderungen (git im /etc-Verzeichnis)

DNS

XMPP-Server und -Clients nutzen SRV-Records, um anhand der JID-Domäne eines Nutzer den Server, die Components und deren Ports zu herauszufinden.

Die A/AAAA-Einträge werden gebraucht, um für die SRV-Records die TLS-Zertifikate zu erstellen.

Auszug aus dem Zonefile von bytewerk.org

xmpp.bytewerk.org.                              300 IN A 94.142.219.72          # Prosody-Server, Coturn-Server, Apache2

conference.bytewerk.org.                        300 IN A 94.142.219.72          # MUC-Component, Apache2
proxy.bytewerk.org.                             300 IN A 94.142.219.72          # Proxy65-Component, Apache2
upload.bytewerk.org.                            300 IN A 94.142.219.72          # HTTP-Fileupload, Apache2
pubsub.bytewerk.org.                            300 IN A 94.142.219.72          # PubSub-Component, Apache2

_xmpp-client._tcp.bytewerk.org.                 300 IN SRV 0 5 5222 xmpp.bytewerk.org.  # VirtualHost XMPP-Server, C2S
_xmpps-client._tcp.bytewerk.org.                300 IN SRV 0 5 5223 xmpp.bytewerk.org.  # VirtualHost XMPP-Server, C2S Legacy SSL auf Port 5223
_xmpp-server._tcp.bytewerk.org.                 300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # VirtualHost XMPP-Server, S2S
_xmpp-server._tcp.conference.bytewerk.org.      300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # MUC-Component, S2S
_xmpp-server._tcp.proxy.bytewerk.org.           300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # Proxy65-Component, S2S
_xmpp-server._tcp.pubsub.bytewerk.org.          300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # PubSub-Component, S2S

_xmppconnect.bytewerk.org.                      300 IN TXT "_xmpp-client-xbosh=https://xmpp.bytewerk.org/http-bind"             # BOSH
_xmppconnect.bytewerk.org.                      300 IN TXT "_xmpp-client-websocket=wss://xmpp.bytewerk.org/xmpp-websocket"      # Websocket

Auszug aus dem Zonefile von bingo-ev.de

conference.bingo-ev.de.                         300 IN A 94.142.219.72          # MUC-Component, Apache2
proxy65.bingo-ev.de.                            300 IN A 94.142.219.72          # Proxy65-Component, Apache2 ("proxy.bingo-ev.de" ist bereits belegt)
upload.bingo-ev.de.                             300 IN A 94.142.219.72          # HTTP-Fileupload, Apache2
pubsub.bingo-ev.de.                             300 IN A 94.142.219.72          # PubSub-Component, Apache2

_xmpp-client._tcp.bingo-ev.de.                  300 IN SRV 0 5 5222 xmpp.bytewerk.org.  # VirtualHost XMPP-Server, C2S
_xmpps-client._tcp.bingo-ev.de.                 300 IN SRV 0 5 5225 xmpp.bytewerk.org.  # VirtualHost XMPP-Server, C2S Legacy SSL auf Port 5225
_xmpp-server._tcp.bingo-ev.de.                  300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # VirtualHost XMPP-Server, S2S
_xmpp-server._tcp.conference.bingo-ev.de.       300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # MUC-Component, S2S
_xmpp-server._tcp.proxy65.bingo-ev.de.          300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # Proxy65-Component, S2S
_xmpp-server._tcp.pubsub.bingo-ev.de.           300 IN SRV 0 5 5269 xmpp.bytewerk.org.  # PubSub-Component, S2S

_xmppconnect.bingo-ev.de.                       300 IN TXT "_xmpp-client-xbosh=https://xmpp.bytewerk.org/http-bind"             # BOSH
_xmppconnect.bingo-ev.de.                       300 IN TXT "_xmpp-client-websocket=wss://xmpp.bytewerk.org/xmpp-websocket"      # Websocket

Zertifikate

Prosody benötigt Zertifikate für ALLE beteiligten Domains, also auch von bytewerk.org und bingo-ev.de. Components ohne Zertifikat funktionieren nicht mit externen Usern. Mit "prosodyct check" kann geprüft werden ob alle Zertikate passend zu den DNS-Einträgen und zu den Components vorhanden sind (Ausnahme: Legacy-SSL). Für Feinheiten lohnt sich ein Blick in "/var/log/prosody/prosody.err", besonders mit eingeschaltetem "debug"-Loglevel.

Coturn benötigt nur das Zertifikat von "xmpp.bytewerk.org"

Apache2 braucht grundsätzlich nur Zertifikate für "xmpp.bytewerk.org", "upload.bytewerk.org" und "upload.bingo-ev.de". Um die Zertifikate, die von Prosody benötigt werden, mit Certbot zu erstellen, gibt's diese vHosts:

• xmpp.bytewerk.org
• conference.bytewerk.org, pubsub.bytewerk.org, proxy.bytewerk.org, upload.bytewerk.org
• conference.bingo-ev.de, pubsub.bingo-ev.de, proxy65.bingo-ev.de, upload.bingo-ev.de

TLS-Zertifikat für bytewerk.org und bingo-ev.de

Das bytewerk.org- und das bino-ev.de-Zertifikat wird nur von Prosody (nicht Apache2, nicht Coturn) benötigt. Bei Änderungen/Aktualisierungen müssen sie manuell auf den Server kopiert und User "prosody" übereignet werden. Danach muss Prosody mit "prosodyctl reload" neu geladen werden.

bytewerk.org

• /etc/prosody/certs/bytewerk.org/privkey.pem
• /etc/prosody/certs/bytewerk.org/fullchain.pem

bingo-ev.de

• /etc/prosody/certs/bingo-ev.de/privkey.pem
• /etc/prosody/certs/bingo-ev.de/fullchain.pem

Alle anderen Zertifikate

Alle Zertifikate außer dem von bytewerk.org und bingo-ev.de werden von LetsEncrypt-Certbot erstellt und liegen unter /etc/letsencrypt. Das Renewal wird per wöchentlichem Cronjob von root mit /usr/bin/certbot renew durchgeführt.

Zertifikate:

• xmpp.bytewerk.org
• conference.bytewerk.org, pubsub.bytewerk.org, proxy.bytewerk.org, upload.bytewerk.org
• conference.bingo-ev.de, pubsub.bingo-ev.de, proxy65.bingo-ev.de, upload.bingo-ev.de

Nach einem erfolgten Renewal führt Certbot die Post-Renewal-Hooks /etc/letsencrypt/renewal-hooks/post/ aus:

• apache2.sh: Apache2 neu laden
• coturn.sh: Zertifikate nach /etc/coturn/certs/ kopieren, Rechte anpassen und Coturn neu starten
• prosody.sh: Zertifikate nach /etc/prosody/certs/ kopieren, Rechte anpassen und Prosody neu laden

Fileupload

Der in Prosody eingebaute HTTP-Server unterstützt nur den Upload von Dateien <= 10 MByte und funktioniert nicht mit einigen iOS-Clients (z.B. Monal, Siskin). Um diese Probleme zu umgehen empfiehlt Prosody, stattdessen das Modul "mod_http_upload_external" zu verwenden. Bei dem Modul wird dazu das PHP-Skript "share_v2.php" benutzt, das unter dem Apache-vHost "https://upload.bytewerk.org/share_v2.php" (bzw. https://upload.bingo-ev.org/share_v2.php) eingebunden ist und hochgeladene Dateien unter "/srv/var/prosody-upload/<DOMAIN>/" abspeichert.

Dateien, die älter als ein Monat sind, werden per täglichem Cronjob von root gelöscht.

XEP-0368: .well-known-URLs

Der Webserver bytewerk.org muss per Reverse Proxy für die URL https://bytewerk.org/.well-known/host-meta(.json) auf http://xmpp.bytewerk.org/.well-known/... verweisen. Ein Redirect reicht nicht, da die CORS-Header in Prosody konfiguriert und gesetzt werden. Gleiches gilt für den bingo-ev.de-Webserver.

Prosody

Kommentierte Konfigurationsdatei "/etc/prosody/prosody.cfg.lua"

Da beim Prosody-Paket von OpenSuse eine Menge benötigter Module fehlen, wurden die Module direkt aus dem Prosody-Mercuriual-Repository nach "/usr/local/lib/prosody-modules/" geklont Zum Aktualisieren einfach "/usr/local/sbin/update-prosody-modules.sh" ausführen und Prosody mit "prosodyctl reload" neu laden.

Apache2

vHosts in "/etc/apache2/vhosts.d/" angelegt, sonst keine Änderungen.

• 01-set-servername.conf: Hostname auf xmpp.bytewerk.org setzen
• conference.bytewerk.org.conf: Nur Platzhalter für Certbot
• proxy.bytewerk.org.conf: Nur Platzhalter Certbot
• pubsub.bytewerk.org.conf: Nur Platzhalter Certbot
• upload.bytewerk.org.conf: Fileupload per mod_http_upload_external + share_v2.php
• xmpp.bytewerk.org.conf: Reverse-Proxy für BOSH, Websocket und für die von mod_http_altconnect erstellte .well-known-URIs

Alle vHosts außer upload.bytewerk.org leiten auf https://jabber.bytwerk.org um.

Für bingo-ev.de gibt es entsprechende vHosts.

Coturn

Kommentierte Konfigurationsdatei "/etc/coturn/turnserver.conf"

Probleme

• Plattenplatz auf VM gering
• keine IPv6-Unterstützung: Die Prosody-VM hat zwar eine IPv6-Adresse, diese ist aber nicht öffentlich erreichbar
• Wenn Coturn als TURN-Server statt "nur" als STUN-Server durch Prosody benutzt wird, funktioniert Audio- und Videotelefonie nur noch mit bytewerk.org-Usern und nicht mehr mit Externen.
• Verbindung mit Websocket funktioniert nicht (und ist darum deaktiviert): Verbindung wird aufgebaut, dann gibt's einen Timeout.
• Conversejs ist stellenweise etwas umständlich zu bedienen. So muss z.B. zum Anlegen eines MUC die komplette Domain des eigenen XMPP-Servers eingegeben werden. Um das zu umgehen gibt es jeweils eine Conversejs-URL für @bingo-ev.de und @bytewerk.org, bei der durch entsprechende Vorkonfiguration das Anlegen von MUCs auch ohne Eintippen des Domainnamens funktioniert. Mittelfristig kann Conversejs eventuell durch Movim ersetzt werden. Movim ist allerdings Stand 2/2021 noch zu buggy (siehe Issues [1], [2], [3]).

ToDo

• Testen! Insbesondere: Funktioniert alle XMPP. Funktionen auch mit Nutzern aus anderen Domänen? Verhalten sich Mobilgeräte wie erwartet? (iOS Pushnachrichten, Stromsparmodus, Verzögerungen,...)
• Mehr Plattenplatz
• Backup
• Monitoring

Files

TBD