XMPP Service Operators - 2025-04-27

If only there was a way to test server interoperability before release, especially when trying to fix already broken things... alas

> If only there was a way to test server interoperability before release, especially when trying to fix already broken things... alas thats's the way

😂

I can confirm the same error to your server Kris. Have reported it, but don't have debug logs from the ejabberd side

> If only there was a way to test server interoperability before release, especially when trying to fix already broken things... alas That’s what ejabberd community edition is. We are in fact the testing community so paying customer abc is not experiencing those issues.

> I can confirm the same error to your server Kris. Have reported it, but don't have debug logs from the ejabberd side 😓 ↺

https://github.com/processone/ejabberd/issues/4375

Nyx (everypizza.im) : Seems your xmpps is broken. ``` xmpp-dns -t everypizza.im xmpp-client chat.everypizza.im. 5222 Priority: 0 Weight: 5 IP: 2600:1702:4caa:ac10:42ed:ff:feac:27af Test: [OK] IP: 99.10.221.198 Test: [OK] xmpps-client chat.everypizza.im. 5233 Priority: 0 Weight: 5 IP: 2600:1702:4caa:ac10:42ed:ff:feac:27af Test: [Not OK] dial tcp6 [2600:1702:4caa:ac10:42ed:ff:feac:27af]:5233: connect: connection timed out IP: 99.10.221.198 Test: [Not OK] dial tcp4 99.10.221.198:5233: connect: connection timed out xmpp-server chat.everypizza.im. 5269 Priority: 0 Weight: 5 IP: 2600:1702:4caa:ac10:42ed:ff:feac:27af Test: [OK] IP: 99.10.221.198 Test: [OK] xmpps-server chat.everypizza.im. 5270 Priority: 0 Weight: 5 IP: 2600:1702:4caa:ac10:42ed:ff:feac:27af Test: [Not OK] dial tcp6 [2600:1702:4caa:ac10:42ed:ff:feac:27af]:5270: connect: connection refused IP: 99.10.221.198 Test: [Not OK] dial tcp4 99.10.221.198:5270: connect: connection refused ``` ✏

can you try again? this one messed with the firewall and allowed the ports

Still the same.

You can also check using my tool: https://salsa.debian.org/mdosch/xmpp-dns

5233 for xmpps client looks like a typo.

>> If only there was a way to test server interoperability before release, especially when trying to fix already broken things... alas > > That’s what ejabberd community edition is. We are in fact the testing community so paying customer abc is not experiencing those issues. mightyBroccoli: they have CI though, it could trivially be automatically tested on every PR & merge to master & release tag ↺

They already run the XMPP Interop Framework tests, but those don't include server to server tests right now.

right, which is a massive hole, but do any of the servers do automated tests on federation with other servers right now? It's possible none of them really care about federation with other servers much at all and only us here do, so maybe *we* should do something about it

I have such automated tests for xmpp-proxy, where using rootless podman I spin up whole isolated networks with bind9 (DNS), nginx, prosody, ejabberd, xmpp-proxy, and clients that send messages through these to each other to test full c2s/s2s/DNS/host-meta(2) etc workflows all that's missing really is someone who knows ejabberd and can set up configs for different setups, with bidi, without etc. and can figure out how to package it from master and not just releases. I can handle that bit for prosody, any volunteers ?

we could set it up to test prosody master vs ejabberd master in all the variations daily or so to catch all these *before* releases break the public federated network

Now a complication: there is one ejabberd server I can connect to that is version 2504 and has bidi on. So it's 2:1 now. I guess we need debug logs or diffs on what modules are loaded etc.

yep, and so if we had such test cases set up it'd make that easier to find and once found impossible to regress...

https://code.moparisthebest.com/moparisthebest/xmpp-proxy/src/branch/master/integration/27-s2s-prosody-ejabberd is an example that tests prosody <-> ejabberd s2s, each test is just a folder with config files so if you are an ejabberd admin who can write some config files for something like this let me know

I can provide those for Openfire 😇

(no bidi though, as Openfire simply doesn't support that)

I can provide those for Openfire 😇

(no bidi though, as Openfire simply doesn't support that)

yay first volunteer :) and it's already packaged for Arch so trivial to get that in the podman container https://archlinux.org/packages/extra/any/openfire/ do you want to reuse your xmpp:interop@conference.igniterealtime.org?join channel for this or I can set up a new dedicated one

Different one please. That Interop channel isn't intended to be Openfire specific.

This isn't openfire specific either , please join xmpp:s2s-tests@chat.moparisthe.best?join

Hello, I'm here to ask about an issue with Prosody 13, eversince we upgraded we have been having problems where certain users/clients selected at random cannot receive any new events at all except for when they first log on. Is anyone else getting this?

This also includes things like online presence, and seems to trigger at random times ✏