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
Since the delivery of mumble.hacc.space/murmur.hacc.space via gitlab pages
broke (for whatever reason), I've packaged the site into an ad-hoc nix
derivation, which is now delivered locally by nginx instead. This has a
couple benefits (mainly that we no longer depend on gitlab pages), but
also the downside that we can't just update the site via gitlab's CI/CD
pipelines anymore.
this removes the old (unused) config for an angel system used during the
fridays for future camp 2020. Since it was configured "by hand" and not
in a declarative manner, and since there is now an actual module
`services.engelsystem` that we already use for the divoc it seems unlikely
that we will ever need the old config again.
From Nix's point of view, this commit is equivalent to doing nothing.
Seems to work fine, except for the domain — the engelsystem tries
to load its ressources from the IP of the container instead of its
url set in the config.
This is a partial revert, reintroducing hexchen to the project.
As it turns out, I am still quite invested in the project and require
frequent access to the nix-based infrastructure.
I am no longer comfortable with putting resources into this project and
therefore request to be removed from all infrastructure. I am still
happy to help out with software I set up, but I will no longer actively
maintain any services. As far as possible, I will remove myself from all
access groups or other privileged positions related to this project.
Essentially, I'm stepping down as a maintainer. I still reserve the
right to make changes via the established change processes (Merge
Requests as well as Issues in the meta-repositories), but I will no
longer make direct changes to infrastructure without going through those
review processes.
