Plucs: Fehlerhafte Nachrichtenzustellung

Apps & App Center
#1

Hallo,

leider habe ich Probleme mit plucs. Da es nicht sehr häufig gebraucht wird, weiß ich auch nicht wie lange das Problem schon besteht. Auf der eine Seite hatte ich KDE Telepathy, auf der anderen Jitsi und Xabber unter Andorid. Unter UCS 3.2 funktionierte dies noch ohne Probleme.

Auffälligkeiten konnte ich in den Logs nicht finden. Mit Psi statt KDE Telepathy konnte ich es nun vorläufig zum laufen kriegen. Überall muß ich dabei neuerdings den Server explizit angeben. Vorher ging es auch so. Anscheinend scheint der Service Record zu fehlen:

# host -t SRV _xmpp-client._tcp.top2.top1
Host _xmpp-client._tcp.top2.top1 not found: 3(NXDOMAIN)

Sollte der nicht automatisch angelegt worden sein? Wie kann es passieren, daß der nun weg ist?

#2

Hallo,

der/die Service-Records wird nicht durch die PLUCS-Integration angelegt bzw. verwaltet.
Die PLUCS-Doku verweist hier auf die UCS-Dokumentation (und selbst die kann in manchen Konstellationen nicht zutreffend sein).

Für die Fehlersuche können die Protokolle in /var/log/ejabberd/ hilfreich sein.

Viele Grüße,
Dirk Ahrnke

#3

Danke, dann wunderts mich schon, daß es mal ohne Angabe des Servers funktioniert hat. Ich hab nämlich keinen Service-Record erstellt gehabt. Wenn ich einen über die UMC anlegen will, gibt es das Feld Extension als Pflichtfeld. Was geb ich denn da an?

Für die Fehlersuche hatte ich erfolglos genau in /var/log/ejabberd/ geguckt.

#4

Es geht bei den meisten Clients auch ohne SRV-Records, nur muß dann m.E. Hostname und “Domain” der Jabber-ID identisch sein.
Oder man muß halt den Server manuell angeben.

Zum Thema Extension: [bug]39882[/bug]

Ansonsten würde ich dann erstmal nachsehen, ob auf dem xmpp-client Port (5222) etwas lauscht.
Zu prüfen wäre, ob ejabberd init script not deactivated zutrifft. Wenn beide Initskripte losrennen wird einer verlieren.

#5

Also da es momentan mit Psi funktioniert, wird wohl auch ein Dienst auf dem Port laufen.

Von dem Bug scheine ich auch betroffen zu sein:

# ls -l /etc/init.d/ejabberd 
-rwxr-xr-x 1 root root 2696 Apr 15  2014 /etc/init.d/ejabberd
# ls -l /etc/rc4.d/|grep ej
lrwxrwxrwx 1 root root  18 Nov 28 11:13 S20ejabberd -> ../init.d/ejabberd
#6

Muß ich ich zum Deaktivieren die Links entfernen oder gibt es sonst noch was zu beachten?

#7

“update-rc.d ejabberd remove” wäre wohl der saubere Weg, aber den Link zu Löschen müsste auch funktionieren.

Den Verweis auf den laufenden Psi (im Gegensatz zu den anderen Clients) hatte ich übrigens übersehen. Zu diesen Clients kann ich selbst wenig sagen. Ein Kollege arbeitet mit Jitsi, aber wir haben SRV-Records, wobei die betroffene Zone nicht in UCS verwaltet wird.

#8 
# update-rc.d ejabberd remove
update-rc.d: /etc/init.d/ejabberd exists during rc.d purge (use -f to force)
# update-rc.d -f ejabberd remove
 Removing any system startup links for /etc/init.d/ejabberd ...
   /etc/rc0.d/K20ejabberd
   /etc/rc1.d/K20ejabberd
   /etc/rc2.d/S20ejabberd
   /etc/rc3.d/S20ejabberd
   /etc/rc4.d/S20ejabberd
   /etc/rc5.d/S20ejabberd
   /etc/rc6.d/K20ejabberd

Danke jetzt scheint es wieder zu gehen (also auch mit KDE Telepathy) :slight_smile:

Mastodon