Commit graph

32 commits

Author SHA1 Message Date
1f871af807 s4f-conference: increase MaxUsersPerTeam 2024-05-22 21:25:07 +02:00
4ffedfe532 s4f-conference: allow larger uploads
they should probably be using nextcloud for this, but i can't be
bothered to make them a group there, so here we go 🤷
2024-05-21 17:38:34 +02:00
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
efadc5ada9 monit: increase delay for deployed-commit-on-main
there's little point in having it alert while people are working on the
config & test-deploying things; it's meant to remind later, in case we
forget committing the result.
2024-05-08 14:33:14 +02:00
d933a6ef98 s4f-conference: another mattermost
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.
2024-05-08 14:32:52 +02:00
8c3d3bf6db monitoring: warn if no deploy for 10 days
this is not entirely accurate — the lastModified attribute of a flake's
self-input gives the date of the last commit, not the last deploy. But I
figure it's close enough and less obscure to check than reading in the
last date via nix-env.

inspired by: we did no server updates for two weeks.
2024-05-02 22:33:47 +02:00
27b8ef6784 tracktrain: update
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)
2024-05-02 00:33:39 +02:00
f9005dd4d0 forgejo/openssh: listen on all interfaces
this doesn't help us with anything yet, but it does at least mean that
this openssh now also listens on IPv6, which it didn't before.

(reaching the container from the outside still does not work)
2024-04-27 23:19:20 +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
d20acbfe58 monit: a couple new checks
move the monit config out of mail.nix, and add two checks:
 - has any systemd unit failed?
 - is the currently deployed commit the tip of the main branch of
   haccfiles?
2024-04-07 16:30:57 +02:00
281745d7a6 simplify nat on parsons 2024-04-07 16:25:08 +02:00
1ad0a7751c use networking.firewall instead of nftables.ruleset 2024-04-07 15:57:51 +02:00
e81472cb87 monit: restart onlyoffice if failed
this should hopefully help with our consistent onlyoffice-does-not-work-but-no-one-noticed
problems (yes, monit runs as root and can do that).

"then restart" will still send an alert if it restarted the unit (see monit's man page)
2024-03-26 17:06:36 +01:00
319e5894e0 alps: hopefully fix the startup issue
alps frequently fails to start (e.g. during a system activation script)
since either its configured imap or smtp servers are not reachable
yet (i.e. their process has not yet opened the corresponding port).

This should hopefully fix that behaviour:
 - also set BindsTo, telling systemd to only start alps once the
   required units have entered "active" state (not just after it has
   started them)
 - also require postfix to be present, since that provides smtp
2024-03-05 17:03:09 +01:00
7b9e423999 forgejo: final name changes gitea → forgejo
mostly just replacing strings to avoid confusion later on. Since our
containers are now ephemeral, renaming them is basically a non-issue
(though the files under /persist/containers & the uffd client name had
to be changed manually)
2024-02-25 23:24:07 +01:00
f29830ec93 format nftables.nix 2024-02-25 17:53:54 +01:00
cbc7827cb9 make all nixos containers ephemeral 2024-02-22 21:15:41 +01:00
62917423e3 render nftables's ruleset
This does the same as the last commit did for the nftnat module, but for
the more general nftables module. Note the weird whatspace again.
2024-02-18 13:39:54 +01:00
0f678c5e80 render nftnat's extraConfig
this removes usage of the nftnat module by rendering it into a static
nftables config. It's a no-op (modulo /etc/haccfiles) as far as nix is
concerned, hence the slightly off-putting whitespace of the multi-line
string.

This seems to me to be a better approach than just bundling the module,
since we only use it for two things (giving the containers network
access & forwarding port 22 to forgejo), which to me doesn't press for
using a custom module we can't really maintain on our own.
2024-02-17 00:04:51 +00:00
0140b7a9fb bundle encboot
this does nothing but move the module & rename the hexchen.* options to hacc.*
2024-02-17 00:04:51 +00: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
5dd817796f parsons/gitea.nix → parsons/forgejo.nix
forgot this last time ...
2024-02-01 00:10:00 +01:00
c28a1f6e2e monit: check for onlyoffice status 2024-01-28 22:56:33 +01:00
c681bb413c gitea → forgejo 2024-01-28 16:07:18 +01:00
93cc8b8172 backups: psql dumps for mattermost & nextcloud 2024-01-28 15:48:13 +01:00
816e175b33 restic: move secrets into sops 2024-01-28 15:32:18 +01:00
68dc640257 fix docs.hacc.space
this is a slightly cursed work around; see the comment.

Alternatively, we could pass in the $src attribute of that derivation
via callPackage (passing it through all the way from flake.nix), but tbh
that sounds like too much effort rn.

Have fun with confusingly long paths in the nix store 🙃
2024-01-12 00:31:32 +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