Ausgangssituation der vorhanden XMPP-Chat-Konfiguration
Ich betreibe einen XMPP-Chat-Server (Prosody). Als Clienten verwende ich Gajim und Conversations. Zur Verschlüsselung des Chats kommt OMEMO zum Einsatz. Außerdem verwende ich die Module mod_mam, mod_muc_mam und die Speicherung der Nachrichten in eine MYSQL/MariaDB-Datenbank.
Probleme beim Chat
Ständig hatte ich einen unterschiedlichen Datenstand bei den Nachrichten auf den unterschiedlichen Clients, obwohl diese immer synchron sein müssten. Häufig sind Clients nicht verbunden, wie Gajim auf dem Desktop. Die Synchronisation nach Einschalten des Rechner funktioniert, aber es gab immer fehlende Nachrichten. Durch die XMPP Standards dürfte so etwas nicht passieren. Als Ursache habe ich viele Dinge in Betracht gezogen.
Ursachen für fehlende/unsynchrone Nachrichten
Letztendlich hat sich heraus gestellt, dass als Ursache zu viele instabile Module und ständige Serverneustarts zu den Unsynchronitäten geführt haben. Aufgefallen ist mir zufällig, dass die Schlüssel meiner Clienten bei Serverneustart u. U. nicht wieder aktiviert wurden. Dadurch werden dann Nachrichten nicht mehr angezeigt, weil die Schlüssel inaktiv sind und es kommt zum Nachrichtenverlust beim Chat.
Lösung
Ich habe alle nicht notwendigen Module deaktiviert. Quasi sind nur noch die in Conversations angezeigten XMPP-Server-XEPs aktiv. Außerdem habe ich am Server Änderungen bei der Update-Politik vorgenommen. So starte ich meine Server nicht mehr neu. Dies kann man mit der autom. Installation zum Einen bewerkstelligen. Die notwendigen Neustarts des Systems bei Kernelaktualisierungen lassen sich dann mit dem Verfahren Kernel Live Patching (KLP) unter Ubuntu/Linux zum Anderen verhindern. Somit ist ein Hochverfügbarkeitsbetrieb mit einfachen Mitteln z. B. auch im Heim möglich. Seit dem habe ich eine sehr zuverlässige Funktion meines Prosody-Servers, mit dem alle Beteiligten viel Freude haben.
Weitere Lösung für die XMPP-Standards
Gut wäre infolge dessen, wenn Prosody die Aktivierung der Schlüssel nach Neustart erhalten könnte. Leider ist OMEMO nur Client-seitig implementiert. Wahrscheinlich müssen die XMPP-Clients die Aktivierung der OMEMO-Keys sichern. Somit sollte dann der Betrieb auch bei einem Neustart abgefangen werden (können).
Initial situation of the existing XMPP chat configuration
I am running an XMPP chat server (prosody). As clients I use Gajim and Conversations. OMEMO is used to encrypt the chat. I also use modules mod_mam, mod_muc_mam and storing the messages in a MYSQL / MariaDB database.
Chat problems
I always had a different dataset in the messages on the different clients, although these should always be synchronous. Frequently, clients are not connected, such as Gajim on the desktop. Synchronization after power on works, but there was always missing messages. The XMPP standards should not happen. As a cause I have considered many things.
Causes for missing / unsynchronous messages
In the end, it turned out that too many unstable modules and constant server restartes led to the unsynchronization. It is a coincidence that the keys of my clients might not have been activated again during server reboot. This means that messages are no longer displayed because the keys are inactive and there is a loss of messages during the chat.
Solution
I have disabled all unnecessary modules. Quasi, only the XMPP server XEPs displayed in conversations are active. I also made changes to the update policy on the server. So I do not restart my servers. This can be done with the autom. Installation on the one hand. The necessary reboots of the system during kernel updates can then be prevented with the procedure Kernel Live Patching (KLP) under Ubuntu / Linux on the other. Thus, a high-availability operation is possible with simple means, eg also in the home. Since then I have a very reliable function of my prosody server, with which all involved have a lot of fun.
Another solution for the XMPP standards
Good would be if Prosody could get the key activation after reboot. Unfortunately, OMEMO is only implemented on the client side. It is likely that the XMPP clients must back up the activation of the OMEMO keys. Thus, the operation should be intercepted (also) during a restart.