this depends on a whole lot of imperative nonsense being done at the
same time, which i have done.
of special interest to anyone attempting to understand this is
https://docs.mattermost.com/deploy/postgres-migration.html
for the general shape of incompetence at work,
https://docs.mattermost.com/install/setting-up-socket-based-mattermost-database.html#with-unix-socket
for yet another interesting syntax for database connection strings, and
https://github.com/dimitri/pgloader/issues/782#issuecomment-502323324
for a truly astonishing take on how to do database migrations, which
unfortunately i have followed.
As far as I can tell, everything has kept working. Downtime was mostly
spent understanding connection string syntax and their horribly buggy
parsers.
Note for people with server access:
- i have kept the temporary files (including logs) around in
/persist/migration inside the container should we ever need them
again
- there's a zfs snapshot @pre-postgres with the old state
I have little idea what happened here, but this postgres is entirely
unused. The actual database is in mysql, and always has been — the
postgres does contain a mattermost database with the correct tables, but
these are empty.
this one's not connected to our SSO and intended for short-term use
only, after which it will be deleted again.
I've gone through at least some of mattermost's options to see how many
of these are actually relevant anymore. Some can be left out.
Unlike the other mattermost it also doesn't use any mysql.
This is the initial version for this year's run of absurd train
operations. I won't dare to call it a release for at least another month
or so, so no version number.
Changes done in our nixfiles:
- tracktrain now needs ntfy-sh so people (read: I) can get push
notifications if things break or at least look a little weird
- I removed the grafana instance; seems like somewhere in the last year
they changed how to host it under a sub-path (ours was at /metrics),
so it broke, and I'm not feeling any particular urge to fix it
- last year's database contents have been yoten
- also manually updated the gtfs (though I intend to implement logic
for fetching it in tracktrain, I first need to drag Ilztalbahn into
actually publishing up-to-date versions again first)
This is our script to synchronise groups between uffd and mattermost,
since there seems to be no better way to do that. It has long lived
under /persist/magic/auamost since it contained sensitive data (both
which groups are on our platform & access tokens to both uffd's and
mattermost's API with admin-level permissions).
This splits the script up into a non-sensitive part which lives in Nix,
and a small snippet that just sets all the sensitive stuff into env vars
in sops, so we can manage the entire thing with our usual setup.
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.
stuebinm
Moira