See https://blog.prosody.im/prosody-0.12.0-released for more
informations.
We remove the various lua wrappers introduced by
6799a91843 and
16d0b4a69f. It seems like we don't need
them anymore. I'm not brave enough to dig into the Lua machinery to
see what resolved that. Sorry, you'll have to trust me on that one.
We should probably think about the migration from http_upload to
http_file_share for the NixOS module. It's not trivial, we need to
make sure we don't break the already uploaded URLs.
Add extraConfig option for the muc submodule.
Also move the global extraConfig before all components and
virtualhosts, because the manual states:
The configuration is divided into two parts. The first part is known as
the "global" section. All settings here apply to the whole server, and
are the default for all virtual hosts.
The second half of the file is a series of VirtualHost and Component
definitions. Settings under each VirtualHost or Component line apply
only to that host.
Before, if at least one muc was defined, or uploadHttp enabled, the
global extraConfig would end up after "muc" or "http_upload" component
making it apply to that component only and not globally.
We add a Prosody entry to the NixOS manual showing how to setup a
basic XEP-0423 compliant Prosody service. This example also showcase
how to generate the associated ACME certificates.
Note: The <programlisting> body might look poorly indented, but trust
me, it's necessary. If we try to increase their indentation level, the
HTML output will end up containing a lot of unecesseray heading spaces
breaking the formatting...
We are leveraging the systemd sandboxing features to prevent the
service accessing locations it shouldn't do. Most notably, we are here
preventing the prosody service from accessing /home and providing it
with a private /dev and /tmp.
Please consult man systemd.exec for further informations.
Setting up a XMPP chat server is a pretty deep rabbit whole to jump in
when you're not familiar with this whole universe. Your experience
with this environment will greatly depends on whether or not your
server implements the right set of XEPs.
To tackle this problem, the XMPP community came with the idea of
creating a meta-XEP in charge of listing the desirable XEPs to comply
with. This meta-XMP is issued every year under an new XEP number. The
2020 one being XEP-0423[1].
This prosody nixos module refactoring makes complying with XEP-0423
easier. All the necessary extensions are enabled by default. For some
extensions (MUC and HTTP_UPLOAD), we need some input from the user and
cannot provide a sensible default nixpkgs-wide. For those, we guide
the user using a couple of assertions explaining the remaining manual
steps to perform.
We took advantage of this substential refactoring to refresh the
associated nixos test.
Changelog:
- Update the prosody package to provide the necessary community
modules in order to comply with XEP-0423. This is a tradeoff, as
depending on their configuration, the user might end up not using them
and wasting some disk space. That being said, adding those will
allow the XEP-0423 users, which I expect to be the majority of
users, to leverage a bit more the binary cache.
- Add a muc submodule populated with the prosody muc defaults.
- Add a http_upload submodule in charge of setting up a basic http
server handling the user uploads. This submodule is in is
spinning up an HTTP(s) server in charge of receiving and serving the
user's attachments.
- Advertise both the MUCs and the http_upload endpoints using mod disco.
- Use the slixmpp library in place of the now defunct sleekxmpp for
the prosody NixOS test.
- Update the nixos test to setup and test the MUC and http upload
features.
- Add a couple of assertions triggered if the setup is not xep-0423
compliant.
[1] https://xmpp.org/extensions/xep-0423.html
Passwords should not be stored in plain text by default. On existing
installations the next time a users user accounts will automatically
be upgraded from plain to hashed one-by-one as they log in.
Add an ExecReload command to the prosody service, to allow reloading
prosody by sending SIGHUP to the main process, for example to update
certificates without restarting the server. This is exactly how the
`prosodyctl` tool does it.
Note: Currently there is a bug which prevents mod_http from reloading the
certificates properly: https://issues.prosody.im/1216.
