Commit graph

10 commits

Author SHA1 Message Date
285a8e6a8e mattermost: switch to postgresql
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
2024-05-19 23:26:53 +02:00
ed667e15e9 mattermost: packages required for migration 2024-05-19 23:24:26 +02:00
679df4d856 mattermost: remove outdated comment
this is misleading and incorrect, the option does work, and is not also
set in the secrets env file.
2024-05-08 14:33:14 +02:00
05af3ac4f8 mattermost: don't pretend we use postgresql
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.
2024-05-08 14:33:14 +02:00
f654b33a56 modules/containers: a hacc-specific containers module
this started with emily pointing out to me that it's possible to
generate IP addresses for containers in Nix (hence no need to worry
about ever having collisions, as we had before), but then I thought,
hey, while I'm at it, I can also write a little container module so we
have a little less repetition in our configs in general (and a more
reasonable place for our custom evalConfig than just keeping it around
in flake.nix).

See the option descriptions in modules/containers.nix for further
details.

Apart from giving all containers a new IP address (and also shiny new
IPv6 addresses), this should be a no-op for the actual built system.
2024-04-19 19:15:22 +02:00
cbc7827cb9 make all nixos containers ephemeral 2024-02-22 21:15:41 +01:00
39531f1c48 bundle hexchen's nopersist & bindmount moduls
the bind mount module has been tweaked in a couple ways:
 - rename hexchen.* to hacc.*
 - rename bindmount to bindMount to make it consistent with usage in
   the nixpkgs container module
 - add a hacc.bindToPersist option as shorthand for prepending /perist
   to a path via bind mount

the nopersist module has been shortened a little by moving
service-specific things which are used once out into the individual
service files, and removing those which we don't need at all (this also
means we get to loose a mkForce or two in case of mismatches between
hexchen's and our current config).
2024-02-17 00:04:51 +00:00
7427df5167 mattermost: firewall.allowedTCPPorts redundant
our containers profile already sets networking.firewall = false, so this
does exactly nothing except cause confusion.
2024-02-12 21:07:53 +01:00
93cc8b8172 backups: psql dumps for mattermost & nextcloud 2024-01-28 15:48:13 +01:00
41d82ae436 meta: new structure
we decided to:
 - get rid of unused packages
 - simpify the directory layout since we only have one host anyways
 - move our docs (such as they are) in-tree
2024-01-11 23:49:26 +01:00
Renamed from services/mattermost.nix (Browse further)