The problem appeared when there are several vhosts,
the first vhost uses SQL for persistent data (and RAM for volatile),
and another vhost wants to use Mnesia
Example config to trigger the problem:
hosts:
- mysql.localhost
- localhost
host_config:
mysql.localhost:
default_db: sql
In that case, ejabberd crashed at start with an error like:
[critical] Internal error of module mod_muc has occurred during start:
...
** exception exit: {aborted,
{no_exists,
[muc_room,
[{{muc_room,{'_',<<"conference.localhost">>},'_'},
[],
['$_']}]]}}
The CI workflow uses ubuntu-24.04 and setup-beam action,
so it can test only Erlang/OTP 24 and higher.
To ensure Dialyzer is also ran with older Erlang versions,
let's add Dialyzer testing to the Runtime workflow,
which uses the erlang container, and that allows
to run Erlang/OTP 20 in ubuntu-24.04.
STUN via UDP can easily be abused for reflection/amplification DDoS
attacks. Suggest a non-standard port to make it harder for attackers to
discover the service.
Modern XMPP clients discover the port via XEP-0215, so there's no
advantage in sticking to the standard port.
Some users reported ejabberd being restarted by systemd due to missing
watchdog pings despite the actual service operating just fine. So far,
we weren't able to track down the issue, so we'll no longer enable the
watchdog in our example service unit.
Closes#4054.
New check_register_user hook in ejabberd_auth.erl
to allow blocking account registration when a tombstone exists.
Modified room_destroyed hook in mod_muc_room.erl
Until now the hook passed as arguments: LServer, Room, Host.
Now it passes: LServer, Room, Host, Persistent
That new Persistent argument passes the room persistent option,
required by mod_tombstones because only persistent rooms should generate
a tombstone, temporary ones should not.
And the persistent option should not be completely overwritten, as we must
still known its real value even when room is being destroyed.
mod_tombstones is available in experimental mode in ejabberd-contrib git.
Initial feature request: #2546
These days, TURN authentication is usually performed using ephemeral
credentials handed out by mod_stun_disco. In that case, the TURN realm
is irrelevant. Therefore, omit the misleading log message that warned
about a missing realm configuration.
(Commit 6eb2f07274 reduced the log level
of that message already.)
