xmpp metronome auth Problem

G

gw2345

New Member
Hi Forum,
ich kriege XMPP mit metronome, ISPConfig 3.1 unter Jessie nicht zum laufen.
Der Fehler in /var/log/metronome/metronome.dbg ist:
Unhandled c2s_unauthed stanza: iq; xmlns=jabber:iq:auth

Außerdem erhalte ich in der ISPConfig GUI immer wenn ich unter "XMPP Domain" die Domain bearbeite und auf den Reitern "Modules", "MUC" oder "SSL" irgendwas verändern will die Fehlermeldung "domain_error_empty" in der ISPConfig GUI angezeigt.

Der Server wurde nach "Perfectserver Howto" für Jessie installiert.

Die Datei /etc/metronome/hosts/meinedomain.de.cfg.lua wird korrekt angelegt.

Als Client habe ich es mit Gajim, Pidgin und mit Conversations unter Android probiert. Conversations kommt gar nicht bis zur Authentifizierung sondern sagt gleich "inkompatibler server"

Falls jemand eine Idee hat, woran es liegen könnte wäre ich sehr dankbar.

Gruss, Gerd

Hier nochmal der ungekürzte metronome.dbg eines Verbindungsversuchs mit Gajim:
Jan 08 13:13:26 socket debug accepted incoming client connection from: 178.200.175.xxx 55212 to 5222
Jan 08 13:13:26 c2sebfcd0 info Client connected
Jan 08 13:13:26 c2sebfcd0 debug Client sent opening <stream:stream> to mydomain.de
Jan 08 13:13:26 c2sebfcd0 debug Sent reply <stream:stream> to client
Jan 08 13:13:26 c2sebfcd0 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Jan 08 13:13:26 socket debug try to start ssl at client id: ebfcd0
Jan 08 13:13:26 socket debug ssl session delayed until writebuffer is empty...
Jan 08 13:13:26 c2sebfcd0 debug TLS negotiation started for c2s_unauthed...
Jan 08 13:13:26 socket debug starting ssl handshake after writing
Jan 08 13:13:26 socket debug starting handshake...
Jan 08 13:13:26 socket debug ssl handshake of client with id:table: 0xebfcd0, attempt:1
Jan 08 13:13:27 socket debug ssl handshake of client with id:table: 0xebfcd0, attempt:2
Jan 08 13:13:27 socket debug ssl handshake of client with id:table: 0xebfcd0, attempt:3
Jan 08 13:13:27 socket debug ssl handshake done
Jan 08 13:13:27 c2sebfcd0 debug Client sent opening <stream:stream> to mydomain.de
Jan 08 13:13:27 c2sebfcd0 debug Sent reply <stream:stream> to client
Jan 08 13:13:27 c2sebfcd0 debug Received[c2s_unauthed]: <iq id='7' type='get'>
Jan 08 13:13:27 mod_router debug Stanza of type iq from c2s_unauthed has xmlns: jabber:iq:auth
Jan 08 13:13:27 mod_router debug Unhandled c2s_unauthed stanza: iq; xmlns=jabber:iq:auth
Jan 08 13:13:27 socket debug connection failed in read event: closed
Jan 08 13:13:27 socket debug closing client with id: ebfcd0 closed
Jan 08 13:13:27 c2sebfcd0 info Client disconnected: closed
Jan 08 13:13:27 c2sebfcd0 debug Destroying session for (unknown) ((unknown)@mydomain.de): closed
 
G

gw2345

New Member
Ich habe die Kommunikation zwischen XMPP-Client und dem Metronome Server nochmal von der Client-Seite aus betrachtet.

SENDING: <iq type='get' id='purpledb857591'><query xmlns='jabber:iq:auth'><username>XY</username></query></iq>
RECEIVED: (137): <iq id='purpledb857591' type='error'><error type='cancel'><service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></iq>

Der Client scheint die Liste der Authentifizierungs-Mechanismen abzufragen, der Server gibt diese aber nicht raus.

Gibt es hier irgendwen, der die neue XMPP Funktion in ISPConfig erfolgreich nutzt? Wenn ja wäre ich sehr intressiert daran mit welchem Client.

Beste Grüße aus Gießen

Gerd
 
G

gw2345

New Member
Hi Till,
da fehlen mir wohl Rechte um Ihn auf diesem Weg zu erreichen. Ich hab mal in den Threat im engl. Dev. Forum geposted, vielleicht liest er es ja.
Danke,
Gerd
 
Codem@ster

Codem@ster

New Member
Also, hier mal ein Workaround:
Bearbeite die Datei: /usr/local/ispconfig/interface/web/mail/xmpp_domain_edit.php
Das Problem liegt in Zeile 227. Also da ist noch weitaus mehr Buggy, aber ich habe aktuell zu wenig Zeit, um mich damit intensiv zu beschäftigen.
Code: 
if ($settings['use_domain_module'] == 'y') {
                        if ($_SESSION["s"]["user"]["typ"] == 'admin' || $app->auth->has_clients($_SESSION['s']['user']['userid'])) {
                                $this->dataRecord['client_group_id'] = $app->tools_sites->getClientIdForDomain($this->dataRecord['domain']);
                        }
                        $domain_check = $app->tools_sites->checkDomainModuleDomain($this->dataRecord['domain']);
                        if(!$domain_check) {
                                // invalid domain selected
                                $app->tform->errorMessage .= $app->tform->lng("domain_error_empty")."<br />";
                        } else {
                                $this->dataRecord['domain'] = $domain_check;
                        }
                }
Ab Zeile 227, in der Funktion onSubmit(), die Zeile:
Code: 
if ($settings['use_domain_module'] == 'y') {
gegen Folgende austauschen:
Code: 
if ((isset($this->dataRecord['domain'])) && ($settings['use_domain_module'] == 'y')) {

Damit funktioniert dann auch das Speichern und Erstellen von Zertifikaten wieder.

Wie immer, Nutzung auf eigene Gefahr -> ich übernehme keine Haftung für kaputte Konfigurationen, kaputte Server und atomare Abfälle.
 
Codem@ster

Codem@ster

New Member
Mühsam ernährt sich das....
Mal kurz zu meiner Infrastruktur: das ganze läuft auf einem Debian Stretch Server.
In den Logs bin ich darüber gestolpert, dass auf Stretch LuaSec nicht läuft mit Metronome.
Code: 
portmanager     error   Error while binding encrypted port for https: LuaSec (required for encryption) was not found
Lua ist zwar 5.1, aber LuaSec wird in der Version 0.6 installiert und das ist leider inkompatibel. Um das wieder zum Laufen zu kriegen, habe ich zunächst LuaSec deinstalliert und dann openssl-1.0.2l heruntergeladen und nach /usr/local/ssl installiert, mit:
Code: 
root@stretch /usr/local/src/openssl-1.0.2l # apt-get --purge remove lua-sec
[...]
root@stretch /usr/local/src/openssl-1.0.2l # ./config -fPIC
[...]
root@stretch /usr/local/src/openssl-1.0.2l # make && make install
Danach kann man LuaSec in der Version 0.5.1-1 bauen:
Code: 
root@stretch /usr/local/src/openssl-1.0.2l # luarocks install luasec 0.5.1-1 OPENSSL_DIR=/usr/local/ssl
Nach einem Neustart von Metronome, war schon mal das SSL Problem gelöst, aber nach wie vor kein Login möglich.
 
Codem@ster

Codem@ster

New Member
I love Trial n Error.

Also, das Problem ist offenbar auf den Metronome Code zurückzuführen.

Ich habe vergleichsweise mal den Metronome Dienst deaktiviert und aus dem Repository prosody-0.10 installiert.
Dies bügelt dann auch gleich wieder die lua-sec aufs System.
Danach habe ich die Berechtigung für /etc/metronome geändert und die Module ins prosody Modulverzeichnis kopiert.

Code: 
# apt-get install prosody-0.10
# chown -R prosody.prosody /etc/metronome
# chown -R prosody.prosody /etc/prosody/certs
# cp -a /usr/lib/metronome/isp-modules/* /usr/lib/prosody/modules/

An die /etc/prosody/prosody.cfg.lua dann noch folgendes angefügt:

Code: 
use_libevent = true;
Include "/etc/metronome/hosts/*.lua"
Include "/etc/metronome/status/*.lua"

und anschließend den prosody Dienst neu gestartet (service prosody restart).

Und siehe da! Es funktioniert.

Natürlich ist das jetzt noch keine gangbare Lösung für ISPConfig, aber ganz ehrlich, ich schreibe lieber ein Prosody-Plugin für ISPConfig, als Metronome zu fixen. Ich hatte auch schon überlegt ejabberd an ISPConfig zu pluggen, aber Prosody scheint im Augenblick die einfachste Lösung zu sein. Und da mich jetzt Wut und Elan gepackt haben, werde ich jetzt was bauen, was funktioniert. :)
 
Codem@ster

Codem@ster

New Member
So, hier eine schnelle Lösung für alle mit ner Debian Kiste und dem gleichen Problem. Ich gehe mal davon aus, dass die Box nach dem PerfectServer Howto aufgesetzt wurde und die Prosody Repositories schon in den Apt-Sources hinterlegt sind.

Vorab: Ich übernehme keine Garantie für die Richtigkeit der nachfolgenden Angaben und übernehme keinerlei Haftung für evtl. Schäden. Einsatz und Durchführung der nachfolgenden Anleitung erfolgt auf eigene Gefahr!

SCHRITT 1: BACKUP MACHEN!

SCHRITT 2: NOCH MEHR BACKUP MACHEN!

NÄCHSTE SCHRITTE:
Umbau von Metronome auf Prosody, als root.
Code: 
# service metronome stop
# killall lua5.1
# systemctl disable metronome
# mv /etc/init.d/metronome /etc/metronome/metronome_initscript.old
# apt-get update
# apt-get install prosody-0.10
# service prosody stop
# mkdir /etc/prosody/hosts
# mkdir /etc/prosody/status
# mv /etc/metronome/certs/localhost.key /etc/metronome/localhost.key.old
# cp -a /etc/metronome/certs/* /etc/prosody/certs
# cp -a /etc/metronome/hosts/* /etc/prosody/hosts
# cp -a /etc/metronome/status/* /etc/prosody/status
# cp /etc/metronome/metronome.cfg.lua /etc/prosody/prosody.cfg.lua
# cp /etc/metronome/global.cfg.lua /etc/prosody/global.cfg.lua
# sed -ie "s/metronome/prosody/g" /etc/prosody/prosody.cfg.lua
# cp -a /usr/lib/metronome/isp-modules/* /usr/lib/prosody/modules
# chown -R prosody.prosody /etc/prosody/certs
# wget -O /tmp/ispconfig_prosody_files.tgz --no-check-certificate https://download.schwalmnetz.de/ispconfig_prosody_files.tgz
# cd /usr/local
# tar -czf /root/ispconfig.tgz ispconfig
# cd /usr/local/ispconfig
# tar -xzf /tmp/ispconfig_prosody_files.tgz
# rm -f server/conf/metronome*
Die "cp -a ..." Befehle erzeugen möglicherweise eine Fehlermeldung, wenn die Verzeichnisse leer sind. Also keine Panik, einfach ignorieren.
Meldungen zu Dateien, die Überschrieben werden sollen, bitte mit J oder Y bestätigen.

- Im ISPConfig Panel als Admin anmelden.
- System -> Serverkonfiguration -> den/die XMPP Host(s) öffnen
- Auf XMPP klicken
- Serverwide enabled plugins (one per line): saslauth, tls, dialback, disco, discoitems, version, uptime, time, ping, admin_adhoc, admin_telnet, http, bosh, posix, announce, offline, webpresence, mam, lastactivity
- SPEICHERN! und auf Aktualisierung warten.

ISPConfig sollte nun /etc/prosody/global.cfg.lua neu erstellt haben. Falls nicht, noch einmal eine Änderung an der Konfiguration im ISPConfig durchführen.

Sicherheitshabler prosody noch einmal neu starten:
Code: 
# service prosody stop
# service prosody start
Wenn alles glatt gelaufen ist, sollte XMPP nun mit ISPConfig, über Prosody funktionieren.
Man erkennt das daran, dass im Verzeichnis /var/log/prosody nun die Datei prosody.dbg liegt.
Viel Erfolg - und vielleicht wirft das ja mal jemand ins ISPConfig GIT.

PS: Ich habe mit der Methode jetzt 6 Server erfolgreich umgebaut, also gehe ich davon aus, dass dies ohne große Anpassungen funktionieren sollte.
 

Anhänge

  • ispconfig_prosody_files.zip
    7,1 KB · Aufrufe: 562
E

Esolein

Member
entsprechend bekomme ich folgenden Fehelr:

12.02.2021-12:25 - WARNING - There is already a lockfile set, but no process run ning with this pid (323). Continuing.
vlibTemplate Error: Template (metronome_conf_host.master) file not found.Cannot load the ionCube PHP
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top