Hi,
ich versuche einen Jabber-Service aufzusetzen. Dazu nutze ich auf der Serverseite Prosody wie es im Repo der 15.2beta angeboten wird. (Prosody 0.11.5)
Allerdings bekomme ich keine Verbindung von einem XMPP-Client aus. Hier nutze ich Kopete und Thunderbird aus dem openSUSE Leap 15.1 Repo.
Per telnet sehe ich das der Port 5222 oder 5223 offen ist, aber die Verbindung wird lt. Log des Prosody immer wieder sofort geschlossen.
Zuerst dachte ich das etwas mit dem Server nicht stimmt, aber ich habe das gleiche Verhalten der beiden o. g. Clients wenn ich z. B. jabber.org oder andere kontaktieren will. (Auch hier klappt der Test mit telnet.)
Also liegt es wahrscheinlich eher an den Clients als am Server. Aber zwei Programme gleichzeitig mit denselben Symptomen? Eher unwahrscheinlich, solange sie nicht die gleiche Library verwenden.
Hilfreiche Tipps werden gerne gesehen.
Bernd
Hi,
muß es Prosody sein? Ich benutze openfire (https://www.igniterealtime.org/projects/openfire/) und habe damit sehr gute Erfahrungen. Nur leider unterstützt Apple ab OS 10.irgendwas kein XMPP mehr bei dem hauseigenen Client.
Viele Grüße
Thorsten
Am 19.05.20 um 16:40 schrieb Bernd Nachtigall:
Hi,
ich versuche einen Jabber-Service aufzusetzen. Dazu nutze ich auf der Serverseite Prosody wie es im Repo der 15.2beta angeboten wird. (Prosody 0.11.5)
Allerdings bekomme ich keine Verbindung von einem XMPP-Client aus. Hier nutze ich Kopete und Thunderbird aus dem openSUSE Leap 15.1 Repo.
Per telnet sehe ich das der Port 5222 oder 5223 offen ist, aber die Verbindung wird lt. Log des Prosody immer wieder sofort geschlossen.
Zuerst dachte ich das etwas mit dem Server nicht stimmt, aber ich habe das gleiche Verhalten der beiden o. g. Clients wenn ich z. B. jabber.org oder andere kontaktieren will. (Auch hier klappt der Test mit telnet.)
Also liegt es wahrscheinlich eher an den Clients als am Server. Aber zwei Programme gleichzeitig mit denselben Symptomen? Eher unwahrscheinlich, solange sie nicht die gleiche Library verwenden.
Hilfreiche Tipps werden gerne gesehen.
Bernd
...fisch ;-)
Wie während des Schreibens getestet und im Text vermerkt denke ich das es eher an den Clients liegt.
Daher ... kann jemand bitte mal mit einem aktuellen LEAP 15.1 testen ob er mit Kopete einen Account bei jabber.org erstellen kann? Es würde mir schon helfen wenn ich wüsste ob es nur hier harkt oder ob es ein grundsätzliches Problem ist.
Bernd
Am 19.05.20 um 17:28 schrieb Thorsten Marquardt:
Hi,
muß es Prosody sein? Ich benutze openfire (https://www.igniterealtime.org/projects/openfire/) und habe damit sehr gute Erfahrungen. Nur leider unterstützt Apple ab OS 10.irgendwas kein XMPP mehr bei dem hauseigenen Client.
Viele Grüße
Thorsten
Am 19.05.20 um 16:40 schrieb Bernd Nachtigall:
Hi,
ich versuche einen Jabber-Service aufzusetzen. Dazu nutze ich auf der Serverseite Prosody wie es im Repo der 15.2beta angeboten wird. (Prosody 0.11.5)
Allerdings bekomme ich keine Verbindung von einem XMPP-Client aus. Hier nutze ich Kopete und Thunderbird aus dem openSUSE Leap 15.1 Repo.
Per telnet sehe ich das der Port 5222 oder 5223 offen ist, aber die Verbindung wird lt. Log des Prosody immer wieder sofort geschlossen.
Zuerst dachte ich das etwas mit dem Server nicht stimmt, aber ich habe das gleiche Verhalten der beiden o. g. Clients wenn ich z. B. jabber.org oder andere kontaktieren will. (Auch hier klappt der Test mit telnet.)
Also liegt es wahrscheinlich eher an den Clients als am Server. Aber zwei Programme gleichzeitig mit denselben Symptomen? Eher unwahrscheinlich, solange sie nicht die gleiche Library verwenden.
Hilfreiche Tipps werden gerne gesehen.
Bernd
-- Es sprach der Fürst zum Herrn Kaplan: "Halt' Du sie dumm, ich halt sie arm!"
Am Tue, 19 May 2020 17:38:06 +0200 schrieb Bernd Nachtigall bnacht@web.de:
Wie während des Schreibens getestet und im Text vermerkt denke ich das es eher an den Clients liegt.
Daher ... kann jemand bitte mal mit einem aktuellen LEAP 15.1 testen ob er mit Kopete einen Account bei jabber.org erstellen kann? Es würde mir
Zu kopete kann ich nix sagen, aber die Ergebnisse meiner Experimente mit der XMPP-Erweiterung von Thunderbird waren grauslig - instabil und praktisch null Zusatzfunktionalität. Ist über 3 Jahre her und vielleicht ist es besser geworden, aber für TB sprach damals eigentlich nur, dass es als betriebsinterner Standard bereits überall installiert war.
Ansonsten: Wenn man Pidgin zur Verfügung hat, gibt es eigentlich keinen Grund, auf was anderes zu setzen - robust, multiplattform und reichhaltig erweiterbar. Will heißen, wenn Dein Prosody auch mit Pidgin nicht tut, dann liegt es aller Wahrscheinlichkeit am Server. =:)
(ja, auch wir hatten openfire am Start)
Am Tue, 19 May 2020 17:59:16 +0200 schrieb Tobias Crefeld tclx@klekih-petra.de:
Am Tue, 19 May 2020 17:38:06 +0200 schrieb Bernd Nachtigall bnacht@web.de:
Ansonsten: Wenn man Pidgin zur Verfügung hat, gibt es eigentlich keinen Grund, auf was anderes zu setzen - robust, multiplattform und reichhaltig erweiterbar.
(ja, auch wir hatten openfire am Start)
Wir haben die Kombi Openfire/Pidgin ebenfalls seit Jahren am Laufen.
Sollte eigentlich nur für eine Übergangslösung sein. Hat sich dann aber als so solide erwiesen, dass es nie abgelöst wurde ;-)
Gruß, Michael
Mit Gajim bekam ich die Meldung, das dem Zertifikat nicht vertraut wurde (es ist ein wildcard-Zertifikat, noch keins was speziell auf diesen Hostnamen läuft, es war im Vertrag mit drin ...)
Ja das ist abzusehen. Hier ein paar Hilfreiche links: https://prosody.im/doc/letsencrypt https://prosody.im/doc/certificates
On Tue, 19 May 2020 17:59:16 +0200 Tobias Crefeld tclx@klekih-petra.de wrote:
Ansonsten: Wenn man Pidgin zur Verfügung hat, gibt es eigentlich keinen Grund, auf was anderes zu setzen - robust, multiplattform und reichhaltig erweiterbar.
Soweit ich weiss unterstuetzt Pidgin die meisten XEPs die man heutzutage will nicht.
XEP-0138 - Stream Compression: Save network bandwidth XEP-0163 - Personal Eventing Protocol: For many things.. User avatars and OMEMO encryption for example XEP-0198 - Stream Management: Hold your session open for 5 minutes in case you have short network outage XEP-0280 - Message Carbons: Send copies of your sent messages to all your devices XEP-0313 - MAM: Store message history on server XEP-0363 - HTTP File Upload: You can send your partner a file even if he isn’t online
Pidgin und Kopete sind nur fuer altes XMPP gut so meine Erfahrung. Modern sind nur Gajim, Dino, Conversations, Siskin, Profanity.
Hi,
ich versuche einen Jabber-Service aufzusetzen. Dazu nutze ich auf der Serverseite Prosody wie es im Repo der 15.2beta angeboten wird. (Prosody 0.11.5)
Ich hab Prosody 0.11.5 auf meinem Server am laufen.
Allerdings bekomme ich keine Verbindung von einem XMPP-Client aus. Hier nutze ich Kopete und Thunderbird aus dem openSUSE Leap 15.1 Repo.
Was sagt die Prosody log? Was sagt die client log? In Gajim kann man auch XML Console anschalten um die Stanzas zu sehen.
Per telnet sehe ich das der Port 5222 oder 5223 offen ist, aber die Verbindung wird lt. Log des Prosody immer wieder sofort geschlossen.
Vermutlich weil du nicht sendest was Prosody erwartet?
Also liegt es wahrscheinlich eher an den Clients als am Server. Aber zwei Programme gleichzeitig mit denselben Symptomen? Eher unwahrscheinlich, solange sie nicht die gleiche Library verwenden.
Probier mal Gajim.
Best, Michael
Hi,
danke für den Tipp! Mit Gajim bekam ich die Meldung, das dem Zertifikat nicht vertraut wurde (es ist ein wildcard-Zertifikat, noch keins was speziell auf diesen Hostnamen läuft, es war im Vertrag mit drin ...)
Bei Gajim bekam ich diese Meldung und konnte dem Zertifikat dann manuell mein Vertrauen aussprechen. Wie man es auch von Browsern kennt.
Bei Kopete bekam ich nur die nichtssagende Meldung: "Es ist ein Verbindungsfehler aufgetreten. Verbindung abgelehnt." Und ohne Log ist es dann schlecht.
Jetzt weiß ich wenigstens das der Server mal erst läuft, die DNS-Einträge stimmen, ... ... und das ich Kopete aussondern sollte ... oder einen Enhancement request für gescheite Fehlermeldungen aufmachen sollte ...
Bye
Bernd
Am 19.05.20 um 17:58 schrieb Michael Vetter:
Hi,
ich versuche einen Jabber-Service aufzusetzen. Dazu nutze ich auf der Serverseite Prosody wie es im Repo der 15.2beta angeboten wird. (Prosody 0.11.5)
Ich hab Prosody 0.11.5 auf meinem Server am laufen.
Allerdings bekomme ich keine Verbindung von einem XMPP-Client aus. Hier nutze ich Kopete und Thunderbird aus dem openSUSE Leap 15.1 Repo.
Was sagt die Prosody log? Was sagt die client log? In Gajim kann man auch XML Console anschalten um die Stanzas zu sehen.
Per telnet sehe ich das der Port 5222 oder 5223 offen ist, aber die Verbindung wird lt. Log des Prosody immer wieder sofort geschlossen.
Vermutlich weil du nicht sendest was Prosody erwartet?
Also liegt es wahrscheinlich eher an den Clients als am Server. Aber zwei Programme gleichzeitig mit denselben Symptomen? Eher unwahrscheinlich, solange sie nicht die gleiche Library verwenden.
Probier mal Gajim.
Best, Michael
Hallo,
XMPP ist wirklich super - wenn man einen guten Client hat.
Mit _Abstand_ der beste Client auf dem Planeten ist Conversations fuer Android. Er hat so gut wie alles was man sich an Funktion vorstellen kann inkl. Audio-/Videotelefonie.
Das groesste Problem bei Clients hat IOS (Apple IPhone). Es gibt faktisch keinen vernuenftigen Client dafuer. Die meisten Apps sehen aus als ob schon vor langer Zeit jemand die Lust verloren haette daran was zu machen. Halbwegs funktionsfaehig ist ChatSecure, aber der hat ziemliche Schwierigkeiten mit OMEMO Verschluesselung und kann abseits getippter Nachrichten kaum etwas. Schwierig ist auch das Thema Web-Client. Auch hier ist das Problem OMEMO Verschluesselung. Xabber waere schoen, aber der Autor weigert sich jegliche Verschluesselung einzubauen. Movim waere auch schoen, kann aber auch kein OMEMO (will das aber wohl irgendwann unterstuetzen).
An Desktop-Clients gibt es einige, die meisten davon sind jedoch erbaermlich im Hinblick auf die GUIs. Unter Linux der "schoenste" und funktionell ok ist Dino. Gajim gibts auch fuer andere Betriebssysteme, hat aber ein ziemlich abenteuerliches Gebahren bei den Einstellern. Von "OK/Cancel" hat der Autor nie gehoert. Je nach Windowmanager kann es passieren dass man nicht weiss wie man aus einem Fenster wieder herauskommt, oder was ein Einsteller eigentlich einstellt. Herausstechendes Beispiel ist die Passworteingabe bei Konten. Wofuer ein Schiebeschalter bei "Passwort speichern" gut sein soll erschliesst sich einem nicht leicht.
Das Schoene an XMPP ist das Design, dass sehr aehnlich zu EMail ist. Dezentrale Server die die jeweiligen Empfaenger ueber Angaben im DNS der Zieldomain finden. Aus genau diesem Grund haben wir das ins Domainhosting aufgenommen. Jeder kann in seiner Domain beliebig viele XMPP-Adressen haben, ebenso wie bei EMail. Und diese koennen eben auch gleich sein. Eine Adresse fuer EMail, XMPP und damit Audio und Video Telefonie (und nebenbei auch fuer einen Standortdienst per MQTT).
Hallo,
nur mal kurz zum Thema OMEMO weil es hier auch kurz angesprochen wurde. OMEMO in einen Client einzubauen grenzt an Horror (ich mach das gerade für ein Kundenprojekt). Um OMEMO einsetzen zu können, speziell wenn es multi-resource (sprich multi-device) unterstützen soll und diese dann auch noch Mobilgeräte sind, die nicht ständig Netzverbindung haben, dann summieren sich wirklich viele Sachen. XMPP ist ja eigentlich für Clients gedacht, die nahezu dauernd online sind und Nachrichten und Statusmeldungen empfangen können. Eine OMEMO Erweiterung eines bestehenden Client dürfte recht komplex sein, vor allem wenn die Codebasis schon einige Jährchen auf dem Buckel hat.
OMEMO ist ja nur ein recht dünnes Ding und spezifiziert nur das Nachrichtenformat. OMEMO braucht Personal Eventing Protocol (PEP), Carbon Copy, Message Archiving. Nicht jede XMPP Unterstützt das, auch OMEMO Messages werden kaum (oder eben gar nicht) von XMPP Bibliotheken angeboten.
Die eigentliche Verschlüsselung erfolgt dann über das Double-Ratchet Protokoll (früher auch 'Axolotl' genannt). Ein Client, der OMEMO unterstützen will, muss das Protokoll einbauen, entweder mit einer Library, die das schon kann oder selber bauen. Die Nutzerschnittstelle (UI) muss auch erweitert werden, damit die Anwender die notwendingen Prüfungen (Fingerprints) auch machen können.
Naja, viele andere Problem erwarten dann die Entwickler auch noch :-) , das würde aber den Rahmen diese Threads sprengen.
Werner
Am 20.05.20 um 18:36 schrieb Stephan von Krawczynski:
Hallo,
XMPP ist wirklich super - wenn man einen guten Client hat.
Mit _Abstand_ der beste Client auf dem Planeten ist Conversations fuer Android. Er hat so gut wie alles was man sich an Funktion vorstellen kann inkl. Audio-/Videotelefonie.
Das groesste Problem bei Clients hat IOS (Apple IPhone). Es gibt faktisch keinen vernuenftigen Client dafuer. Die meisten Apps sehen aus als ob schon vor langer Zeit jemand die Lust verloren haette daran was zu machen. Halbwegs funktionsfaehig ist ChatSecure, aber der hat ziemliche Schwierigkeiten mit OMEMO Verschluesselung und kann abseits getippter Nachrichten kaum etwas. Schwierig ist auch das Thema Web-Client. Auch hier ist das Problem OMEMO Verschluesselung. Xabber waere schoen, aber der Autor weigert sich jegliche Verschluesselung einzubauen. Movim waere auch schoen, kann aber auch kein OMEMO (will das aber wohl irgendwann unterstuetzen).
An Desktop-Clients gibt es einige, die meisten davon sind jedoch erbaermlich im Hinblick auf die GUIs. Unter Linux der "schoenste" und funktionell ok ist Dino. Gajim gibts auch fuer andere Betriebssysteme, hat aber ein ziemlich abenteuerliches Gebahren bei den Einstellern. Von "OK/Cancel" hat der Autor nie gehoert. Je nach Windowmanager kann es passieren dass man nicht weiss wie man aus einem Fenster wieder herauskommt, oder was ein Einsteller eigentlich einstellt. Herausstechendes Beispiel ist die Passworteingabe bei Konten. Wofuer ein Schiebeschalter bei "Passwort speichern" gut sein soll erschliesst sich einem nicht leicht.
Das Schoene an XMPP ist das Design, dass sehr aehnlich zu EMail ist. Dezentrale Server die die jeweiligen Empfaenger ueber Angaben im DNS der Zieldomain finden. Aus genau diesem Grund haben wir das ins Domainhosting aufgenommen. Jeder kann in seiner Domain beliebig viele XMPP-Adressen haben, ebenso wie bei EMail. Und diese koennen eben auch gleich sein. Eine Adresse fuer EMail, XMPP und damit Audio und Video Telefonie (und nebenbei auch fuer einen Standortdienst per MQTT).
-
Bernd Nachtigall -
Michael Höhne -
Michael Vetter -
Stephan von Krawczynski -
Thorsten Marquardt -
Tobias Crefeld -
Werner Dittmann