in theory this might be ready to deploy. Potential hazards & things to
know when actually doing so:
1. the mysql version used by mattermost was updated (the old uses an
openssl which is marked insecure). Might have to migrate a database
2. lots of settings now use RFC 42-style settings, which might contain
new typos
3. this updates uffd (& changes the patches we apply). Since version
dependencies of uffd are basically "whatever debian has" we have
never bothered to match them, but afaik have also never updated uffd
since the initial deploy some years ago. No guarantee it still
works.
4. tracktrain depends on haskellPackages.conferer-warp, which is
currently marked broken. There is no reason for this (it builds
fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1.
cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a
merge of haskell-updates into 23.05
note: I am author of both the file now under /persist/containers/tracktrain
& the upstream one at ilztalbahn.eu, but don't have direct access to the
wordpress instance running there, and no one who does has yet uploaded
the new file.
this only concerns secrets which are in a raw file. Some of our
services (e.g. nextclouds) keeps secrets in its database; these remain
untouched.
Not yet deployed because of shitty train internet.
this is currently deployed and appears to be working. please everyone
have a look at it & then decide if we want to use this for the other
secrets as well.
apparently the 7.1.x series is now old enough that even though it
does still get security fixes, the mattermost team no longer mentions
this on their blog, so we missed out on a couple. fun!
upsides:
- we will no longer get confused about which state is currently deployed
downsides:
- deploys get slower, since it has to uploads the entire haccfiles each time
today i woke up to the realisation that there's an extremely obvious way
to make these nicer, & then i did exactly that. For some reason I did
not think of this when originally removing the dependency to nix-hexchen's
evalConfig.
unfortunately, this is not /quite/ a no-op. The only actual change is
different whitespace in some of the semantically-equivalent
coredns-configs that got unified.
