XMPP Service Operators - 2025-05-17

I hear some blabber about some let's encrypt changes that might affect email and xmpp operators. Anyone having a good source explaining what they're doing and what operators have to do?

Prosody devs said it will likely affect nothing, since the current xmpp implementations already use workarounds to use these kind of certs anyway ✏

(because it was a thing with some CAs in the past already doing this)

Phew, than I only need to check whether postfix and dovecot are affected.

ij: https://squeet.me/display/962c3e10-2068-285b-6dbf-504157779815

Greetings programs! New XMPP server operator here, preparing to launch my system for public use. Popping in to say hi to this slice of the community.

kurisu: https://joinjabber.org/tutorials/service/public/

Oh yes, I've read several pieces on the subject. I believe I have standard enough security measures in place, but will certainly look for ways to improve things as time passes. At this stage I'm really just due to nail down the actual TOS / User Policy / etc on the server before the launch, whatever that launch may actually consist of.

> I hear some blabber about some let's encrypt changes that might affect email and xmpp operators. Anyone having a good source explaining what they're doing and what operators have to do? Martin: https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ it should only affect things that try to use the TLS cert for client auth, sometimes called mutual TLS or MTLS... which is probably only XMPP but servers probably have workarounds already because before letsencrypt this was also a problem, prosody is definitely good, I asked in ejabberd channel and got a "probably good" ↺

What are the different paths for ejabberd upstream package vs Debian package? Debian lags behind quite a bit, so I want to use the upstream package. I tried symlining like this: /etc/ejabberd -> /opt/ejabberd/conf /var/lib/ejabberd -> /opt/ejabberd/database /var/log/ejabberd -> /opt/ejabberd/logs But ejabberd no longer recognises the password. However, it listens on the correct non-standard port I've set (I also have a Prosody on the same machine, I'm running both so I can learn about the difference and so on), so it loads the config file. But it still does not recognise the user accounts. What am I missing?

Couldn't find any guide on migrating between Debian package and upstream package, although that's surely not an uncommon thing to do.

moparisthebest: thx

Trixie RC1 is out 🙂

The latest Arch Linux is also out, always has the latest stable versions, never have to upgrade releases, boring and just works ;)

Menel: Trixie Installer RC1, debian does no RCs for releases itself. moparisthebest: Yeah, always latest versions and you'll never know what will break next. I appreciate to only expect breakages every ~2 years. Had my arch times >15 years ago like every young and wild guy but the time will come when you want it to be more relaxed. :)

Oh no, dist fight.

No, I'm too old for dist fights. That was my last comment to the typical "btw, …" messages. ^^

> What are the different paths for ejabberd upstream package vs Debian package? Debian lags behind quite a bit, so I want to use the upstream package. I tried symlining like this: > > /etc/ejabberd -> /opt/ejabberd/conf > /var/lib/ejabberd -> /opt/ejabberd/database > /var/log/ejabberd -> /opt/ejabberd/logs > > But ejabberd no longer recognises the password. However, it listens on the correct non-standard port I've set (I also have a Prosody on the same machine, I'm running both so I can learn about the difference and so on), so it loads the config file. But it still does not recognise the user accounts. > > What am I missing? which db? ↺

hi kurisu

Hi Trung!

😁

> which db? Mnesia ↺

erebion: Not sure from the top of my head, but isn't there a subdirectory of the form `ejabberd@$host` below `/opt/ejabberd/database`? If so, that would be the directory to map `/var/lib/ejabberd` to.

Otherwise your mappings look correct to me.

I've got ejabberd@localhost, I've symlinked that to /opt/ejabberd/database/ejabberd@localhost, it still does not allow me to log in. It looks like the data isn't there, but the config is..?

So /opt/ejabberd/database/ejabberd@localhost does now contain the old Mnesia files?

Let me double check before I say something wrong and sabotage the help I'm getting :)

And the logs contain no [error]s? Anyway I'm on my phone and not of much help here. Maybe ask in the ejabberd room?

xmpp:ejabberd@conference.process-one.net?join

There's inconsistency with that ejabberd@localhost subdirectory, it's been used on some but not all platforms by default (Docker vs. distro packages, I forgot), and now we're trying to support both variants everywhere. Maybe the ejabberdctl code that tries to locate the Mnesia directory stumbles over things being symlinked (but that's purely a guess).

I've also tried changing the directories in ejabberdctl instead of symlinking and got the same behaviour

s2s and Matrix gateway both communicate to the outside world just fine, log says that, but cannot log in

> And the logs contain no [error]s? > > Anyway I'm on my phone and not of much help here. Maybe ask in the ejabberd room? Yeah, will do. Haven't found one. :) ↺

I'd love a tiny package in the ejabberd repo that would just set up the right symlink automagically when installed, that'd be great.