XMPP-Server: Unterschied zwischen den Versionen

Aus bytewerk-Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
(42 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 5: Zeile 5:
* [[Benutzer:sqozz|sqozz]]
* [[Benutzer:sqozz|sqozz]]
* [[Benutzer:Cfr34x|cfr34k]]
* [[Benutzer:Cfr34x|cfr34k]]
* [[Benutzer:citronalco|citronalco]]
* [[Benutzer:Geierb|Geierb]]


==Benutzerzugänge==
==Benutzerzugänge==


Informationen für Anwender finden sich hier: [https://xmpp.bytewerk.org/ https://xmpp.bytewerk.org/]
Informationen für Anwender finden sich hier: [https://xmpp.bytewerk.org/ https://xmpp.bytewerk.org/]



=== <Bingo-Benutzername>@bingo-ev.de ===
=== <Bingo-Benutzername>@bingo-ev.de ===
Zeile 22: Zeile 21:
=== <wunschname>@bytewerk.org ===
=== <wunschname>@bytewerk.org ===


Accounts werden auf Zuruf erstellt (siehe oben "Verantwortlich").
Accounts werden auf Zuruf erstellt (siehe oben "Verantwortlich"). Das Passwort kann im XMPP-Client geändert werden.

Zusätzlich kann jeder vorhandene Benutzer '''"Invite"-Codes''' erstellen und diesen anderen Personen zuschicken, die sich dann damit einen @bytewerk.org-Account anlegen können:
# In [https://xmpp.bytewerk.org/conversejs-bytewerk Converse.js] anmelden
# Links oben auf das Zahnrad klicken
# Auf "Befehle" klicken
# Als Instanz "bytewerk.org" eingeben
# "Verfügbare Befehle auflisten" klicken
# Auf "Create new contact invite" klicken
# Die angezeigte Adresse zur "Invite web page" kopieren und der Einzuladenden zukommen lassen. Der Link ist eine Woche lang gültig.

== Chaträume ==
Jeder kann nach Belieben Chaträume anlegen.

Folgende Chaträume werden automatisch angelegt:
* [xmpp:bingo-users@conference.bingo-ev.de bingo-users@conference.bingo-ev.de] [https://conference.bingo-ev.de/muc_badge/bingo-users@conference.bingo-ev.de]
* [xmpp:bytewerk@conference.bytewerk.org bytewerk@conference.bytewerk.org] [https://conference.bytewerk.org/muc_badge/bytewerk@conference.bytewerk.org]

=== Badges ===
Badges für Chaträume können über https://conference.<DOMAIN>/muc_badge/<MUC-JID> abgerufen werden.

Beispiele:
* Das Badge für [xmpp:bytewerk@conference.bytewerk.org bytewerk@conference.bytewerk.org] kann über die URL https://conference.bytewerk.org/muc_badge/bytewerk@conference.bytewerk.org abgerufen werden und sieht so aus: [[Datei:MUC badge bytewerk.png|frameless|caption]]
* Das Badge für [xmpp:bingo-users@conference.bingo-ev.de bingo-users@conference.bingo-ev.de] kann über die URL https://conference.bingo-ev.de/muc_badge/bingo-users@conference.bingo-ev.de abgerufen werden und sieht so aus: [[Datei:MUC badge bingo-users.png|frameless|caption]]



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


== XMPP-Clients ==
== XMPP-Clients ==
Es kann jeder XMPP-Client verwendet werden. Empfehlenswerte Clients für Android, iOS, Linux, Windows und MacOS sind auf https://xmpp.bytewerk.org/ aufgeführt.
=== Empfehlenswerte native Clients ===
* Android: Conversations.im, Quicksy.im
* iOS: Monal.im
* Windows/Linux/BSD: Gajim
* macOS: PSI


=== Webclients ===
=== Webclients ===
Zeile 49: Zeile 67:
* Audio- und Videotelefonie
* Audio- und Videotelefonie
* Ende-zu-Ende-Verschlüsselung
* Ende-zu-Ende-Verschlüsselung
* Dateiup- und Download (wird auch für Fotos, Sprach- und Videonachrichten verwendet) - Dateigröße derzeit limitiert auf 20 MByte.
* Dateiup- und Download (wird auch für Fotos, Sprach- und Videonachrichten verwendet) - Dateigröße derzeit limitiert auf 100 MByte.
* Gleichzeitiges Verwenden mehrerer Clients
* Gleichzeitiges Verwenden mehrerer Clients
Dateien und Chatverläufe werden nach einem Monat vom Server gelöscht.


=== Die Kosten der Freiheit ===
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.
Die oben genannten Funktionen stehen nicht immer zur Verfügung, weil sich die bei der Kommunikation mit einem bestimmten Gesprächspartner zur Verfügung stehenden Funktionen aus der Schnittmenge des Funktionsumfangs der beteiligten XMPP-Server und der XMPP-Clients ergeben :)


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 selbst wenn es der Server unterstützt.
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 selbst wenn es mein XMPP-Client und 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 gerade online ist. Nicht alle XMPP-Clients prüfen beim Wieder-Online-Gehen, ob in der Zwischenzeit Nachrichten eingetroffen sind, die bereits an einem anderen Client zugestellt wurden. Threema, Whatsapp usw. umgehen das, indem sie weder parallele Nutzung noch Fremd-Clients zulassen.
Obacht bei der '''gleichzeitigen Verwendung von mehreren Clients''': 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 gerade online ist. Zwar prüfen die meisten XMPP-Clients beim Wieder-Online-Gehen, ob in der Zwischenzeit Nachrichten eingetroffen sind, aber eben nicht alle.
Ebenso ist undefiniert, was passiert, wenn ein Videoanruf gestartet werden soll, der Gesprächspartner aber mit mehreren Clients online ist, von denen nicht alle Videotelefonie unterstützen.
Threema, Whatsapp usw. umgehen das, indem sie weder parallele Nutzung noch Fremd-Clients zulassen.


== Fortschritt ==
== Fortschritt ==
Zeile 62: Zeile 84:
;2021-02: Implementierung abgeschlossen: Statt 52% jetzt 100% "XMPP Specifications compliance" beim [https://compliance.conversations.im/server/bytewerk.org/ Conversations.im-Compliance-Test], A-Scores beim IM Observatory [https://www.xmpp.net/result.php?domain=bytewerk.org&type=client Client-] und [https://www.xmpp.net/result.php?domain=bytewerk.org&type=server Server]-Test
;2021-02: Implementierung abgeschlossen: Statt 52% jetzt 100% "XMPP Specifications compliance" beim [https://compliance.conversations.im/server/bytewerk.org/ Conversations.im-Compliance-Test], A-Scores beim IM Observatory [https://www.xmpp.net/result.php?domain=bytewerk.org&type=client Client-] und [https://www.xmpp.net/result.php?domain=bytewerk.org&type=server Server]-Test
;2021-02: Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert
;2021-02: Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert
;2021-08: Serverkonfiguration auf Ansible umgestellt, dabei kleine Fehler behoben, neue Funktionen hinzugefügt, Conversejs aktualisiert.


== Implementierung ==
== Implementierung ==

=== Software ===
=== Software ===
Auf der VM '''xmpp.bytewerk.org''' läuft:
Auf der VM '''xmpp.bytewerk.org''' läuft:
Zeile 70: Zeile 94:
* [https://www.postgresql.org PostgreSQL]: Datenbank für Benutzer, Kontakte, Gruppen und Chats
* [https://www.postgresql.org PostgreSQL]: Datenbank für Benutzer, Kontakte, Gruppen und Chats
* [https://github.com/coturn/coturn Coturn]: TURN und STUN (für Jingle/WebRTC benötigt, d.h. Audio-/Videotelefonie sowie Dateiübertragung von Client zu Client)
* [https://github.com/coturn/coturn Coturn]: TURN und STUN (für Jingle/WebRTC benötigt, d.h. Audio-/Videotelefonie sowie Dateiübertragung von Client zu Client)
* [https://github.com/conversejs/converse.js ConverseJS]: XMPP-Webclient
* [https://github.com/conversejs/converse.js ConverseJS]: XMPP-Webclient, mit einigen [https://github.com/conversejs/community-plugins Community-Plugins]
* [https://httpd.apache.org/ Apache2]: HTTPS-Reverse-Proxy für File-Up- und -Downloads, ''.well-known''-URLs, BOSH und Websocket, Bereitstellung von ConverseJS
* [https://httpd.apache.org/ Apache2] mit mod_php: HTTPS-Reverse-Proxy für File-Up- und -Downloads, ''.well-known''-URLs, BOSH und Websocket, Bereitstellung von ConverseJS. PHP wird für das "share_v2.php"-Skript benötigt, das sich um Datei-Up- und Downloads kümmert.
* [https://github.com/DigitaleGesellschaft/Anonip 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''
* [https://github.com/DigitaleGesellschaft/Anonip 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''
* [https://certbot.eff.org Certbot]: Für TLS-Zertifikatsaktualisierung
* [https://certbot.eff.org Certbot]: Für TLS-Zertifikatsaktualisierung
* Crond: Um Certbot wöchentlich aufzurufen und um täglich das Fileupload-Verzeichnis aufzuräumen
* Crond: Um Certbot wöchentlich aufzurufen und um täglich das Fileupload-Verzeichnis aufzuräumen
* [http://etckeeper.branchable.com etckeeper]: Zum Nachverfolgen von Konfigurationsänderungen (git im ''/etc''-Verzeichnis)


=== DNS ===
=== DNS ===
Zeile 85: Zeile 108:
<pre>
<pre>
xmpp.bytewerk.org. 300 IN A 94.142.219.72 # Prosody-Server, Coturn-Server, Apache2
xmpp.bytewerk.org. 300 IN A 94.142.219.72 # Prosody-Server, Coturn-Server, Apache2
xmpp.bytewerk.org. 300 IN AAAA 2a02:868:15:72::1

conference.bytewerk.org. 300 IN A 94.142.219.72 # MUC-Component, Apache2
conference.bytewerk.org. 300 IN A 94.142.219.72 # MUC-Component, Apache2
conference.bytewerk.org. 300 IN AAAA 2a02:868:15:72::1
proxy.bytewerk.org. 300 IN A 94.142.219.72 # Proxy65-Component, Apache2
proxy.bytewerk.org. 300 IN A 94.142.219.72 # Proxy65-Component, Apache2
proxy.bytewerk.org. 300 IN AAAA 2a02:868:15:72::1
upload.bytewerk.org. 300 IN A 94.142.219.72 # HTTP-Fileupload, Apache2
upload.bytewerk.org. 300 IN A 94.142.219.72 # HTTP-Fileupload, Apache2
upload.bytewerk.org. 300 IN AAAA 2a02:868:15:72::1
pubsub.bytewerk.org. 300 IN A 94.142.219.72 # PubSub-Component, Apache2
pubsub.bytewerk.org. 300 IN A 94.142.219.72 # PubSub-Component, Apache2
pubsub.bytewerk.org. 300 IN AAAA 2a02:868:15:72::1


_xmpp-client._tcp.bytewerk.org. 300 IN SRV 0 5 5222 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S
_xmpp-client._tcp.bytewerk.org. 300 IN SRV 0 5 5222 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S
Zeile 105: Zeile 132:
<pre>
<pre>
conference.bingo-ev.de. 300 IN A 94.142.219.72 # MUC-Component, Apache2
conference.bingo-ev.de. 300 IN A 94.142.219.72 # MUC-Component, Apache2
conference.bingo-ev.de. 300 IN AAAA 2a02:868:15:72::1
proxy65.bingo-ev.de. 300 IN A 94.142.219.72 # Proxy65-Component, Apache2 ("proxy.bingo-ev.de" ist bereits belegt)
proxy65.bingo-ev.de. 300 IN A 94.142.219.72 # Proxy65-Component, Apache2 ("proxy.bingo-ev.de" ist bereits belegt)
proxy65.bingo-ev.de. 300 IN AAAA 2a02:868:15:72::1
upload.bingo-ev.de. 300 IN A 94.142.219.72 # HTTP-Fileupload, Apache2
upload.bingo-ev.de. 300 IN A 94.142.219.72 # HTTP-Fileupload, Apache2
upload.bingo-ev.de. 300 IN AAAA 2a02:868:15:72::1
pubsub.bingo-ev.de. 300 IN A 94.142.219.72 # PubSub-Component, Apache2
pubsub.bingo-ev.de. 300 IN A 94.142.219.72 # PubSub-Component, Apache2
pubsub.bingo-ev.de. 300 IN AAAA 2a02:868:15:72::1


_xmpp-client._tcp.bingo-ev.de. 300 IN SRV 0 5 5222 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S
_xmpp-client._tcp.bingo-ev.de. 300 IN SRV 0 5 5222 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S
Zeile 179: Zeile 210:
=== Konfiguration Coturn ===
=== Konfiguration Coturn ===
Kommentierte Konfigurationsdatei "/etc/coturn/turnserver.conf"
Kommentierte Konfigurationsdatei "/etc/coturn/turnserver.conf"



=== Fileupload ===
=== 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).
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.
Um diese Probleme zu umgehen wird das von Prosody empfohlene Modul "mod_http_upload_external" verwendet.
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.
Bei dem Modul funktioniert der Dateiup- und Download über das mitgelieferte PHP-Skript "share_v2.php", das unter dem Apache-vHost "https://upload.bytewerk.org/share_v2.php" (bzw. https://upload.bingo-ev.de/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.
Dateien, die älter als ein Monat sind, werden per täglichem Cronjob von root gelöscht.
Zeile 190: Zeile 220:
=== well-known-URLs ===
=== well-known-URLs ===
Um XEP-0156 ("Discovering Alternative XMPP Connection Methods") zu erfüllen, müssen die Webserver von bytewerk.org und bingo-ev.de per Reverse Proxy folgende URL vom XMPP-Server durchreichen. Es reicht wenn die URLs über HTTPS erreichbar sind:
Um XEP-0156 ("Discovering Alternative XMPP Connection Methods") zu erfüllen, müssen die Webserver von bytewerk.org und bingo-ev.de per Reverse Proxy folgende URL vom XMPP-Server durchreichen. Es reicht wenn die URLs über HTTPS erreichbar sind:
* ''xmpp.bytewerk.org/.well-known/host-meta'':
* ''xmpp.bytewerk.org/.well-known/host-meta'' unter:
** https://bytewerk.org/.well-known/host-meta
** https://bytewerk.org/.well-known/host-meta
** https://bingo-ev.de/.well-known/host-meta
** https://bingo-ev.de/.well-known/host-meta
* ''xmpp.bytewerk.org/.well-known/host-meta.json'':
* ''xmpp.bytewerk.org/.well-known/host-meta.json'' unter:
** https://bytewerk.org/.well-known/host-meta.json
** https://bytewerk.org/.well-known/host-meta.json
** https://bingo-ev.de/.well-known/host-meta.json
** https://bingo-ev.de/.well-known/host-meta.json


Ein einfacher Redirect reicht nicht, da die CORS-Header in Prosody konfiguriert und gesetzt werden.
Ein einfacher Redirect funktioniert nicht, da dieser die von Prosody gesetzten HTTP-CORS-Header zurücksetzt.


==Probleme==
==Probleme/ToDo==
* Plattenplatz auf VM gering
* keine IPv6-Unterstützung: Die Prosody-VM hat zwar eine IPv6-Adresse, diese ist aber nicht öffentlich erreichbar
* <del>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.</del>
* 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 [https://github.com/movim/movim/ Movim] ersetzt werden. Movim ist allerdings Stand 2/2021 noch zu buggy (siehe Issues [https://github.com/movim/movim/issues/964], [https://github.com/movim/movim/issues/972], [https://github.com/movim/movim/issues/974]).


siehe https://git.bingo-ev.de/groups/xmpp/-/issues
==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
* <del>Backup</del>
* <del>Monitoring</del>


==Verwandte Artikel==
=== Routing ===
Stand 02.09.2021 gibt's ohne folgende Änderungen Routingprobleme mit IPv6:


Route Announcements auf dem Interface net-nat ignorieren:
In ''/etc/sysctl.d/ipv6-ignore-ra.conf'':
<pre>
net.ipv6.conf.net-nat.accept_ra=0
net.ipv6.conf.net-nat.autoconf=0
</pre>


In ''/sysconfig/network/routes'' Default-Route für IPv4 setzen:
<pre>
# target via netmask interface
default 94.142.219.94 0.0.0.0 net-public
</pre>

In ''/etc/iproute2/rt_tables'' neue Routingtabelle namens "public" anlegen:
<pre>
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
200 public
</pre>


Verbindungen von der öffentliche IPv6-Adresse über diese Route laufen lassen. Dazu in ''/etc/sysconfig/network/ifrule-net-public'':
<pre>
ipv6 from 2a02:868:15:72::1/64 table public
</pre>


==Files==
==Files==
Das Ansible Playbook und das Inventory befinden sich hier: https://git.bingo-ev.de/xmpp
TBD



[[Category:Projekt]]
[[Category:Projekt]]

Version vom 18. November 2021, 10:18 Uhr

Ziel

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

Verantwortlich

Benutzerzugänge

Informationen für Anwender finden sich hier: https://xmpp.bytewerk.org/

<Bingo-Benutzername>@bingo-ev.de

Jedes Bingo-Mitglied hat automatisch einen Account.

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

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

<wunschname>@bytewerk.org

Accounts werden auf Zuruf erstellt (siehe oben "Verantwortlich"). Das Passwort kann im XMPP-Client geändert werden.

Zusätzlich kann jeder vorhandene Benutzer "Invite"-Codes erstellen und diesen anderen Personen zuschicken, die sich dann damit einen @bytewerk.org-Account anlegen können:

  1. In Converse.js anmelden
  2. Links oben auf das Zahnrad klicken
  3. Auf "Befehle" klicken
  4. Als Instanz "bytewerk.org" eingeben
  5. "Verfügbare Befehle auflisten" klicken
  6. Auf "Create new contact invite" klicken
  7. Die angezeigte Adresse zur "Invite web page" kopieren und der Einzuladenden zukommen lassen. Der Link ist eine Woche lang gültig.

Chaträume

Jeder kann nach Belieben Chaträume anlegen.

Folgende Chaträume werden automatisch angelegt:

Badges

Badges für Chaträume können über https://conference.<DOMAIN>/muc_badge/<MUC-JID> abgerufen werden.

Beispiele:


XMPP-Clients

Es kann jeder XMPP-Client verwendet werden. Empfehlenswerte Clients für Android, iOS, Linux, Windows und MacOS sind auf https://xmpp.bytewerk.org/ aufgeführt.

Webclients

Auf xmpp.bytewerk.org ist Converse.js installiert:

Grundsätzlich kann sich jeder XMPP-Nutzer an jedem XMPP-Webclient anmelden. Je nach URL werden nur ein paar Voreinstellungen passend zur Domain gesetzt um die Benutzung von Converse.js zu erleichtern.

Sonstige

In Thunderbird ist ein sehr einfacher Client (nur Text) integriert ("Konten" -> "Chat-Konto" hinzufügen).

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 Fotos, Sprach- und Videonachrichten verwendet) - Dateigröße derzeit limitiert auf 100 MByte.
  • Gleichzeitiges Verwenden mehrerer Clients

Dateien und Chatverläufe werden nach einem Monat vom Server gelöscht.

Die Kosten der Freiheit

Die oben genannten Funktionen stehen nicht immer zur Verfügung, weil sich die bei der Kommunikation mit einem bestimmten Gesprächspartner zur Verfügung stehenden Funktionen aus der Schnittmenge des Funktionsumfangs der beteiligten XMPP-Server und der XMPP-Clients ergeben :)

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 selbst wenn es mein XMPP-Client und der Server unterstützt.

Obacht bei der gleichzeitigen Verwendung von mehreren Clients: 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 gerade online ist. Zwar prüfen die meisten XMPP-Clients beim Wieder-Online-Gehen, ob in der Zwischenzeit Nachrichten eingetroffen sind, aber eben nicht alle. Ebenso ist undefiniert, was passiert, wenn ein Videoanruf gestartet werden soll, der Gesprächspartner aber mit mehreren Clients online ist, von denen nicht alle Videotelefonie unterstützen. Threema, Whatsapp usw. umgehen das, indem sie weder parallele Nutzung noch Fremd-Clients 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: Statt 52% jetzt 100% "XMPP Specifications compliance" beim Conversations.im-Compliance-Test, A-Scores beim IM Observatory Client- und Server-Test
2021-02
Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert
2021-08
Serverkonfiguration auf Ansible umgestellt, dabei kleine Fehler behoben, neue Funktionen hinzugefügt, Conversejs aktualisiert.

Implementierung

Software

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

  • Prosody: XMPP-Server
  • PostgreSQL: Datenbank für Benutzer, Kontakte, Gruppen und Chats
  • Coturn: TURN und STUN (für Jingle/WebRTC benötigt, d.h. Audio-/Videotelefonie sowie Dateiübertragung von Client zu Client)
  • ConverseJS: XMPP-Webclient, mit einigen Community-Plugins
  • Apache2 mit mod_php: HTTPS-Reverse-Proxy für File-Up- und -Downloads, .well-known-URLs, BOSH und Websocket, Bereitstellung von ConverseJS. PHP wird für das "share_v2.php"-Skript benötigt, das sich um Datei-Up- und Downloads kümmert.
  • 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 um täglich das Fileupload-Verzeichnis aufzuräumen

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
xmpp.bytewerk.org.                              300 IN AAAA 2a02:868:15:72::1
conference.bytewerk.org.                        300 IN A 94.142.219.72          # MUC-Component, Apache2
conference.bytewerk.org.                        300 IN AAAA 2a02:868:15:72::1
proxy.bytewerk.org.                             300 IN A 94.142.219.72          # Proxy65-Component, Apache2
proxy.bytewerk.org.                             300 IN AAAA 2a02:868:15:72::1
upload.bytewerk.org.                            300 IN A 94.142.219.72          # HTTP-Fileupload, Apache2
upload.bytewerk.org.                            300 IN AAAA 2a02:868:15:72::1
pubsub.bytewerk.org.                            300 IN A 94.142.219.72          # PubSub-Component, Apache2
pubsub.bytewerk.org.                            300 IN AAAA 2a02:868:15:72::1

_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
conference.bingo-ev.de.                         300 IN AAAA 2a02:868:15:72::1
proxy65.bingo-ev.de.                            300 IN A 94.142.219.72          # Proxy65-Component, Apache2 ("proxy.bingo-ev.de" ist bereits belegt)
proxy65.bingo-ev.de.                            300 IN AAAA 2a02:868:15:72::1
upload.bingo-ev.de.                             300 IN A 94.142.219.72          # HTTP-Fileupload, Apache2
upload.bingo-ev.de.                             300 IN AAAA 2a02:868:15:72::1
pubsub.bingo-ev.de.                             300 IN A 94.142.219.72          # PubSub-Component, Apache2
pubsub.bingo-ev.de.                             300 IN AAAA 2a02:868:15:72::1

_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-Zertifikate für bytewerk.org und bingo-ev.de

Die Zertifikate für bytewerk.org und bino-ev.de wird nicht auf der VM erstellt sondern müssen auf den XMPP-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-Hook-Skripte in /etc/letsencrypt/renewal-hooks/post/ aus:

  • apache2.sh: Lädt Apache2 neu
  • coturn.sh: Kopiert die Zertifikate nach /etc/coturn/certs/, passt die Rechte an und startet Coturn neu
  • prosody.sh: Kopiert die Zertifikate nach /etc/prosody/certs/, passt die Rechte an und lädt Prosody neu

Konfiguration 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.

Konfiguration Apache2

In /etc/apache2/vhosts.d/01-set-servername.conf: Hostname auf xmpp.bytewerk.org setzen

Diese vHosts wurden in /etc/apache2/vhosts.d/ angelegt:

  • conference.bytewerk.org.conf, conference.bingo-ev.de.conf: Nur Platzhalter für Certbot
  • proxy.bytewerk.org.conf, proxy65.bingo-ev.de.conf: Nur Platzhalter Certbot
  • pubsub.bytewerk.org.conf, pubsub.bingo-ev.de.conf: Nur Platzhalter Certbot
  • upload.bytewerk.org.conf, upload.bingo-ev.de.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.

Konfiguration Coturn

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

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 wird das von Prosody empfohlene Modul "mod_http_upload_external" verwendet. Bei dem Modul funktioniert der Dateiup- und Download über das mitgelieferte PHP-Skript "share_v2.php", das unter dem Apache-vHost "https://upload.bytewerk.org/share_v2.php" (bzw. https://upload.bingo-ev.de/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.

well-known-URLs

Um XEP-0156 ("Discovering Alternative XMPP Connection Methods") zu erfüllen, müssen die Webserver von bytewerk.org und bingo-ev.de per Reverse Proxy folgende URL vom XMPP-Server durchreichen. Es reicht wenn die URLs über HTTPS erreichbar sind:

Ein einfacher Redirect funktioniert nicht, da dieser die von Prosody gesetzten HTTP-CORS-Header zurücksetzt.

Probleme/ToDo

siehe https://git.bingo-ev.de/groups/xmpp/-/issues

Routing

Stand 02.09.2021 gibt's ohne folgende Änderungen Routingprobleme mit IPv6:

Route Announcements auf dem Interface net-nat ignorieren: In /etc/sysctl.d/ipv6-ignore-ra.conf:

net.ipv6.conf.net-nat.accept_ra=0
net.ipv6.conf.net-nat.autoconf=0


In /sysconfig/network/routes Default-Route für IPv4 setzen:

# target     via              netmask       interface
default      94.142.219.94    0.0.0.0       net-public

In /etc/iproute2/rt_tables neue Routingtabelle namens "public" anlegen:

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
200     public


Verbindungen von der öffentliche IPv6-Adresse über diese Route laufen lassen. Dazu in /etc/sysconfig/network/ifrule-net-public:

ipv6 from 2a02:868:15:72::1/64 table public

Files

Das Ansible Playbook und das Inventory befinden sich hier: https://git.bingo-ev.de/xmpp