XMPP-Server: Unterschied zwischen den Versionen
Geierb (Diskussion | Beiträge) |
Geierb (Diskussion | Beiträge) |
||
(43 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
==Ziel== |
==Ziel== |
||
Konkurrenzfähiger, zuverlässiger, selbst betriebener, erweiterbarer Instant |
Konkurrenzfähiger, zuverlässiger, selbst betriebener, erweiterbarer Instant Messenger mit allen derzeitig üblichen Funktionen. |
||
Bingo-Mitglieder sollen automatisch einen Zugang erhalten. |
|||
Für Bytwerk-Mitglieder soll es Accounts mit Wunschnamen geben. Bestehende Bytewerk-Zugänge sollen erhalten bleiben. |
|||
==Verantwortlich== |
==Verantwortlich== |
||
* [[Benutzer:sqozz|sqozz]] |
* [[Benutzer:sqozz|sqozz]] |
||
* [[Benutzer:Cfr34x|cfr34k]] |
* [[Benutzer:Cfr34x|cfr34k]] |
||
* [[Benutzer: |
* [[Benutzer:Geierb|Geierb]] |
||
==Benutzerzugänge== |
|||
==Ansatz== |
|||
XMPP (früher: Jabber) als Protokoll: Weit verbreitet, gute Clients verfügbar, Server ist Freie Software. |
|||
Informationen für Anwender finden sich hier: [https://xmpp.bytewerk.org/ https://xmpp.bytewerk.org/] |
|||
Auf der VM "xmpp.bytewerk.org" läuft bereits Prosody. Dessen Konfiguration wird korrigiert und fehlende Funktionen eingetragen. DNS-Einträge werden geprüft und ergänzt. Für Jingle wird ein TURN-Server installiert. |
|||
=== <Bingo-Benutzername>@bingo-ev.de === |
|||
Jedes Bingo-Mitglied hat automatisch einen Account. |
|||
XMPP wird wie bisher auf der Domain "bytewerk.org" angeboten und zusätzlich auf "bingo-ev.de": |
|||
* Accounts für die '''bytewerk.org'''-Domain werden, wie bisher auch, lokal angelegt und verwaltet. |
|||
Die JID ist identisch zur Bingo-E-Mail-Adresse, das Passwort ist das Bingo-E-Mail-Passwort. |
|||
* Benutzer der '''bingo-ev.de'''-Domain sollen gegen den IMAP-Server "mail.bingo-ev.de" authentifiziert werden: Werden Benutzername und Passwort vom Mailserver bestätigt, so soll der Nutzer auch den XMPP-Server benutzen dürfen. Um es möglichst einfach zu halten soll auch die JID identisch zur E-Mail-Adresse sein. |
|||
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 direkt im XMPP-Client geändert werden. |
|||
== XMPP-Clients == |
|||
=== Empfehlenswerte native Clients === |
|||
* Android: Conversations.im, Quicksy.im |
|||
* iOS: Monal.im |
|||
* Windows/Linux/BSD: Gajim |
|||
* macOS: PSI |
|||
=== Webclients === |
|||
Auf xmpp.bytewerk.org ist Converse.js installiert: |
|||
* [https://xmpp.bytewerk.org/conversejs-bingo XMPP-Webclient für @bingo-ev.de-Nutzer] |
|||
* [https://xmpp.bytewerk.org/conversejs-bytewerk XMPP-Webclient für @bytewerk.org-Nutzer] |
|||
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 [https://apps.nextcloud.com/apps/ojsxc 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 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 selbst 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 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. |
|||
== 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 [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 |
|||
== Implementierung == |
== Implementierung == |
||
=== Software === |
|||
Auf der VM '''xmpp.bytewerk.org''' läuft: |
Auf der VM '''xmpp.bytewerk.org''' läuft: |
||
* [https://prosody.im/ Prosody]: XMPP-Server |
* [https://prosody.im/ Prosody]: XMPP-Server |
||
* [https://www.postgresql.org PostgreSQL]: Datenbank |
* [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]: Webclient |
* [https://github.com/conversejs/converse.js ConverseJS]: XMPP-Webclient |
||
* [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 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) |
* [http://etckeeper.branchable.com etckeeper]: Zum Nachverfolgen von Konfigurationsänderungen (git im ''/etc''-Verzeichnis) |
||
=== DNS === |
=== DNS === |
||
XMPP-Clients nutzen |
XMPP-Server und -Clients nutzen SRV-Records, um anhand der JID-Domäne eines Nutzer den Server, die Components und deren Ports zu herauszufinden. |
||
XMPP-Server nutzen die SRV-Records, um den zu einer Component gehörenden Server samt Ports herauszufinden. |
|||
Die A/AAAA-Einträge werden |
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 ==== |
==== Auszug aus dem Zonefile von bytewerk.org ==== |
||
Zeile 78: | Zeile 119: | ||
</pre> |
</pre> |
||
=== |
=== 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. |
'''''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). |
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. |
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 |
'''''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". |
|||
'''''Apache2''''' betreibt vHosts für folgende Hostnamen und benötigt die entsprechenden Zertifikate: |
|||
Um die Zertifikate, die von Prosody benötigt werden, mit Certbot zu erstellen, gibt's diese vHosts: |
|||
* xmpp.bytewerk.org |
* xmpp.bytewerk.org |
||
* conference.bytewerk.org, pubsub.bytewerk.org, proxy.bytewerk.org, upload.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 |
* 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. |
|||
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. |
Danach muss Prosody mit "prosodyctl reload" neu geladen werden. |
||
* bytewerk.org: |
|||
* /etc/prosody/certs/bytewerk.org/privkey.pem |
** ''/etc/prosody/certs/bytewerk.org/privkey.pem'' |
||
* /etc/prosody/certs/bytewerk.org/fullchain.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/privkey.pem'' |
||
* /etc/prosody/certs/bingo-ev.de/fullchain.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''. |
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. |
Das Renewal wird per wöchentlichem Cronjob von root mit ''/usr/bin/certbot renew'' durchgeführt. |
||
Zeile 112: | Zeile 153: | ||
* conference.bingo-ev.de, pubsub.bingo-ev.de, proxy65.bingo-ev.de, upload.bingo-ev.de |
* 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- |
Nach einem erfolgten Renewal führt Certbot die Post-Renewal-Hook-Skripte in ''/etc/letsencrypt/renewal-hooks/post/'' aus: |
||
* apache2.sh: Apache2 neu |
* ''apache2.sh'': Lädt Apache2 neu |
||
* coturn.sh: Zertifikate nach ''/etc/coturn/certs/'' |
* ''coturn.sh'': Kopiert die Zertifikate nach ''/etc/coturn/certs/'', passt die Rechte an und startet Coturn neu |
||
* prosody.sh: Zertifikate nach ''/etc/prosody/certs/'' |
* ''prosody.sh'': Kopiert die Zertifikate nach ''/etc/prosody/certs/'', passt die Rechte an und lädt Prosody neu |
||
=== Konfiguration Prosody === |
|||
=== 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" |
Kommentierte Konfigurationsdatei "/etc/prosody/prosody.cfg.lua" |
||
Zeile 135: | Zeile 164: | ||
Zum Aktualisieren einfach "/usr/local/sbin/update-prosody-modules.sh" ausführen und Prosody mit "prosodyctl reload" neu laden. |
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: |
|||
=== Apache2 === |
|||
* conference.bytewerk.org.conf, conference.bingo-ev.de.conf: Nur Platzhalter für Certbot |
|||
vHosts in "/etc/apache2/vhosts.d/" angelegt, sonst keine Änderungen. |
|||
* proxy.bytewerk.org.conf, proxy65.bingo-ev.de.conf: Nur Platzhalter Certbot |
|||
* 01-set-servername.conf: Hostname auf xmpp.bytewerk.org setzen |
|||
* |
* 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 |
||
* 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 |
* 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. |
Alle vHosts außer upload.bytewerk.org leiten auf https://jabber.bytwerk.org um. |
||
=== Konfiguration Coturn === |
|||
Für bingo-ev.de gibt es entsprechende vHosts. |
|||
=== Coturn === |
|||
Kommentierte Konfigurationsdatei "/etc/coturn/turnserver.conf" |
Kommentierte Konfigurationsdatei "/etc/coturn/turnserver.conf" |
||
==Benutzerzugänge== |
|||
=== <wunschname>@bytewerk.org === |
|||
=== Fileupload === |
|||
Accounts werden auf Zuruf erstellt. |
|||
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. |
|||
Das Passwort kann direkt im XMPP-Client geändert werden. |
|||
=== well-known-URLs === |
|||
Webclient: https://xmpp.bytewerk.org/conversejs-bytewerk |
|||
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'': |
|||
** https://bytewerk.org/.well-known/host-meta |
|||
** https://bingo-ev.de/.well-known/host-meta |
|||
* ''xmpp.bytewerk.org/.well-known/host-meta.json'': |
|||
** https://bytewerk.org/.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. |
|||
=== <Bingo-Benutzername>@bingo-ev.de === |
|||
Jedes Bingo-Mitglied hat automatisch einen Account. |
|||
Passwort ist das Bingo-E-Mail-Passwort, die JID ist identisch zur E-Mail-Adresse. |
|||
Da zur Authentifizierung der Bingo-Mailserver benutzt wird, kann das Passwort nicht im XMPP-Client geändert werden. |
|||
Webclient: https://xmpp.bytewerk.org/conversejs-bingo |
|||
== Empfehlenswerte Clients == |
|||
* Android: Conversations.im, Quicksy.im |
|||
* iOS: Monal.im |
|||
* Windows/Linux/BSD: Gajim |
|||
* macOS: PSI |
|||
Ein sehr einfacher Client (nur Text, keine Gruppenchats) ist in '''Thunderbird''' eingebaut ("Chat-Konto"). |
|||
Für '''Nextcloud''' gibt es mit der ojsxc-App (https://apps.nextcloud.com/apps/ojsxc) 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 [https://compliance.conversations.im/server/bytewerk.org/ compliance.conversations.im] statt 52% jetzt 100% "XMPP Specifications compliance". |
|||
;2021-02: Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert |
|||
==Probleme== |
==Probleme== |
||
* Plattenplatz |
* Plattenplatz auf VM gering |
||
* keine IPv6-Unterstützung: Die Prosody-VM hat zwar eine IPv6-Adresse, diese ist aber nicht öffentlich erreichbar |
* 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> |
* <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> |
||
Zeile 211: | Zeile 208: | ||
* Testen! Insbesondere: Funktioniert alle XMPP. Funktionen auch mit Nutzern aus anderen Domänen? Verhalten sich Mobilgeräte wie erwartet? (iOS Pushnachrichten, Stromsparmodus, Verzögerungen,...) |
* 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 |
* Mehr Plattenplatz |
||
* Backup |
* <del>Backup</del> |
||
* Monitoring |
* <del>Monitoring</del> |
||
==Verwandte Artikel== |
|||
==Files== |
==Files== |
||
Alle Konfigurationsdateien befinden sich hier: https://git.bingo-ev.de/geierb/bytewerk-xmpp-server |
|||
Version vom 22. Februar 2021, 19:19 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 direkt im XMPP-Client geändert werden.
XMPP-Clients
Empfehlenswerte native Clients
- Android: Conversations.im, Quicksy.im
- iOS: Monal.im
- Windows/Linux/BSD: Gajim
- macOS: PSI
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 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 selbst 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 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.
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
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
- 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
- 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-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 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.
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:
- xmpp.bytewerk.org/.well-known/host-meta:
- xmpp.bytewerk.org/.well-known/host-meta.json:
Ein einfacher Redirect reicht nicht, da die CORS-Header in Prosody konfiguriert und gesetzt werden.
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
BackupMonitoring
Files
Alle Konfigurationsdateien befinden sich hier: https://git.bingo-ev.de/geierb/bytewerk-xmpp-server