Things to note:
- DO NOT DEPLOY THIS
- use nixos-container for testing instead
I've played around with nextcloud on NixOS, essentially following the
examples given in the NixOS manual and searching through some of the
other options. Nextcloud itself works fine with this setup, as does
its database (postgres), and most of the other basic stuff.
However, the nextcloud module as it currently exists appears to be fairly
limited and incomplete in its capabilities, e.g. lack of options for redis
or multiple php pools; in general, it lacks extraOptions-hooks. For redis
the documentation even explicitely notes (in caching.redis) that redis
requires additional options set in `config.php`, but it appears these cannot
currently be set using nix.
I guess we have as options:
- I missed something and it does in fact work
- we can wait for later versions; looks like 21.03 will add at least *some* more
- we can fork the module and add options ourselves
- we can configure it nextcloud by manually editing `config.php`, as it's not
actually inside the nix store but at /var/lib/nextcloud/config (veto)
See comments for additional notes and todos.
Changes:
- workadventure is now pulled from stuebinm.eu/git via niv, and
should be updated automatically along with the other sources
- the same is true for the default map, which gets pulled directly from
its gitlab sources.
- this setup may potentially break things if I decide to rename an
option upstream, but I don't think that'll happen too often
- made the code a little nicer
- uses workadventure-xce now, since the tabascoeye version is now gone
Open for discussion:
- afaik know, the current version of workadventure-xce now contains
fediventure-specific patches. Do we want that, or should we switch
to the unfederated version?
this is a workaround to be able to use java 11 with the
minecraft-server module
minecraft calls for jre_headless, which is still java 8
newer java version don't ship jre, which now have to be custom built or
the jdk used
note that this ALSO disables the security alert features of mattermost [1],
which would send us alerts in case of security updates for our current
mattermost version. I have disabled it since it would send information
about our instance (including e.g. the current number of active users) to
mattermost every 24 hours.
Since we now essentially maintain our own set of mattermost packages, I
recommend at least some of us subscribe to the mattermost release blog [2],
and manually update the mattermost sources in `/pkgs/mattermost` as required
(I have done so already). The release blog is also available as an rss feed [3].
[1] https://docs.mattermost.com/administration/telemetry.html#security-update-check-feature
[2] https://mattermost.com/blog/category/releases
[3] https://mattermost.com/blog/category/releases/rss
