This adds a custom mattermost module (`services.mattermost-patched`) which is
identical to the one in nixpkgs except that it also has an option `secretConfig`,
which should point to a file containing all secret parts of the mattermost config
(e.g. mailserver password), and which is merged with the config genereated from
the module at startup time.
This allows us to have a (almost) immutable config without having secrets in the
nix store.
Before deploying this, add a secrets file at /var/lib/mattermost/screts.json
(on the host — there is a bind mount in place so we won't have to enter the
container each time to change something).
This is an initial test config for mattermost on NixOS; the intention is
to perhaps deploy this as soon as it looks reasonable, then have it running
as a "beta instance" in parallel with the current instance on libocedrus
for a while to see if any issues come up before we can make a permament
switch here.
The mattermost module has a somewhat weird approach to database configuration
(per default, it generates an entire postgres config, and if told not to
do that, it generates a /disabled/ postgrs config ...), which I have for
the most part worked around.
Mattermost provides extensive configuration options, which are usually changed
using its web UI. I have instead set the more important ones using Nix, and
made the config immutable --- however, the config of our current instance is
rather long and full of default values; it may well be that I missed some
important settings.
Open questions which we may want to answer before deploying this:
- is there a reason why we use mysql for our current instance? At least
during my tests, mattermost appears to work just fine with postgres
- to access the noreply@infra4future.de mail address, mattermost needs
a password, which --- as it looks right now --- must be set in the nix
store. Can we work around that or should we fork / override the module?
- plugins are apparently broken right now
- locales are broken as well, for whatever reason — the german locale
is definitively present, but setting it as the default will break and
then reverted by mattermost on startup
- for now, I have set `mutableConfig` to `false`, i.e. any changes done
in the mattermost web UI will be overwritten on next startup. This is
great for reproducability, but less so for ease of use (and perhaps for
secrets as well) --- do we want to keep it this way?
- as it is right now, using this instead of our current instance would
represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break
the database schema. We may have to package a more recent version of
mattermost and use that instead.
Things I was unable to test locally (in a nixos container):
- authentication using "gitlab" / keycloak
- mail notifications (including coredns forwarding)
- more advanced stuff like notifications, anything to do
with "true" multi-user interaction
