hacc/haccfiles
8
0
Fork 1
Code Issues 1 Pull requests Projects Releases Wiki Activity
haccfiles/hosts/hainich/services/mattermost.nix

212 lines
7.3 KiB
Nix
Raw Normal View History

init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
{config, pkgs, lib, ...}:
{
containers.mattermost = {
autoStart = true;
privateNetwork = true;
Mattermost: Enable networking for the container. Otherwise, the login via keycloak will fail, as mattermost cannot verify the associated token. Since networking.nat only appears to work for ipv4 and I have no idea how to do it with ipv6, this unfortunately implies downgrading the container's networking to ipv4 only ...
2021-03-16 22:59:32 +00:00
hostAddress = "192.168.100.30";
localAddress = "192.168.100.31";
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
Patch mattermost module to allow secrets outside the nix store This adds a custom mattermost module (`services.mattermost-patched`) which is identical to the one in nixpkgs except that it also has an option `secretConfig`, which should point to a file containing all secret parts of the mattermost config (e.g. mailserver password), and which is merged with the config genereated from the module at startup time. This allows us to have a (almost) immutable config without having secrets in the nix store. Before deploying this, add a secrets file at /var/lib/mattermost/screts.json (on the host — there is a bind mount in place so we won't have to enter the container each time to change something).
2021-03-15 16:04:27 +00:00
bindMounts."/secrets" = {
hostPath = "/var/lib/mattermost/";
isReadOnly = true;
};
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
config = {pkgs, config, ...}: {
Patch mattermost module to allow secrets outside the nix store This adds a custom mattermost module (`services.mattermost-patched`) which is identical to the one in nixpkgs except that it also has an option `secretConfig`, which should point to a file containing all secret parts of the mattermost config (e.g. mailserver password), and which is merged with the config genereated from the module at startup time. This allows us to have a (almost) immutable config without having secrets in the nix store. Before deploying this, add a secrets file at /var/lib/mattermost/screts.json (on the host — there is a bind mount in place so we won't have to enter the container each time to change something).
2021-03-15 16:04:27 +00:00
# have to import these here, since container's dont
# inherit imports of their environment.
imports = [ ../../../modules/mattermost.nix ];
# couldn't figure out how to actually overwrite modules, so now
# there's two mattermost modules ...
services.mattermost-patched = {
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
enable = true;
mattermost: change url to mattermost-beta.infra4future.de I propose we deploy this sometime and see how it goes (as soon as someone sets up DNS for this).
2021-03-15 16:11:38 +00:00
siteUrl = "https://mattermost-beta.infra4future.de";
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
siteName = "Mattermost - Blabla for Future";
Mattermost: Enable networking for the container. Otherwise, the login via keycloak will fail, as mattermost cannot verify the associated token. Since networking.nat only appears to work for ipv4 and I have no idea how to do it with ipv6, this unfortunately implies downgrading the container's networking to ipv4 only ...
2021-03-16 22:59:32 +00:00
listenAddress = "0.0.0.0:3000";
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
mutableConfig = false;
Patch mattermost module to allow secrets outside the nix store This adds a custom mattermost module (`services.mattermost-patched`) which is identical to the one in nixpkgs except that it also has an option `secretConfig`, which should point to a file containing all secret parts of the mattermost config (e.g. mailserver password), and which is merged with the config genereated from the module at startup time. This allows us to have a (almost) immutable config without having secrets in the nix store. Before deploying this, add a secrets file at /var/lib/mattermost/screts.json (on the host — there is a bind mount in place so we won't have to enter the container each time to change something).
2021-03-15 16:04:27 +00:00
secretConfig = "/secrets/secrets.json";
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
extraConfig = {
ServiceSettings = {
TrustedProxyIPHeader = [ "X-Forwarded-For" "X-Real-Ip" ];
ReadTimeout = 300;
WriteTimeout = 600;
IdleTimeout = 60;
MaximumLoginAttempts = 10;
AllowCorsFrom = "*.infra4future.de/*";
WebserverMode = "gzip";
EnableCustomEmoji = true;
EnableEmojiPicker = true;
EnableGifPicker = false;
RestrictCustomEmojiCreation = "all";
RestrictPostDelete = "all";
AllowEditPost = "always";
PostEditTimeout = -1;
EnableTutorial = false;
ExperimentalChannelSidebarOrganization = "default_on";
ExperimentalChannelOrganization = true;
ExperimentalDataPrefetch = true;
EnableEmailInvitations = true;
DisableLegacyMFA = true;
EnableSVGs = true;
EnableLaTeX = true;
ThreadAutoFollow = true;
};
TeamSettings = {
EnableTeamCreation = true;
EnableUserCreation = true;
EnableOpenServer = false;
EnableUserDeactivation = true;
ExperimentalViewArchivedChannels = true;
ExperimentalEnableAutomaticReplies = true;
};
LogSettings = {
EnableConsole = true;
ConsoleLevel = "ERROR";
};
NotificationLogSettings = {
EnableConsole = true;
ConsoleLevel = "INFO";
};
PasswordSettings = {
MinimumLength = 10;
# turn of all the bullshit requirements
Lowercase = false;
Number = false;
Uppercase = false;
Symbol = false;
};
FileSettings = {
EnableFileAttachments = true;
MaxFileSize = 52428800;
DriverName = "local";
Mattermost: Enable networking for the container. Otherwise, the login via keycloak will fail, as mattermost cannot verify the associated token. Since networking.nat only appears to work for ipv4 and I have no idea how to do it with ipv6, this unfortunately implies downgrading the container's networking to ipv4 only ...
2021-03-16 22:59:32 +00:00
Directory = "/var/lib/mattermost/uploads-storage";
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
EnablePublicLink = true;
PublicLinkSalt = "3k7p3yxdhz6798b3b9openfr9rn3ymwu";
};
EmailSettings = {
EnableSignUpWithEmail = false;
EnableSignInWithEmail = false;
EnableSignInWithUsername = false;
SendEmailNotifications = true;
FeedbackName = "mattermost";
FeedbackEmail = "mattermost@infra4future.de";
ReplyToAddress = "mattermost@infra4future.de";
FeedbackOrganization = "∆infra4future.de";
EnableSMTPAuth = true;
SMTPUsername = "noreply@infra4future.de";
SMTPServer = "mail.hacc.space";
};
RateLimitSettings.Enable = false;
PrivacySettings = {
ShowEmailAddress = false;
ShowFullName = true;
};
SupportSettings = {
TermsOfServiceLink = "https://infra4future.de/nutzungsbedingungen.html";
PrivacyPolicyLink = "https://infra4future.de/nutzungsbedingungen.html";
AboutLink = "https://infra4future.de";
SupportEmail = "info@infra4future.de";
CustomTermsOfServiceEnabled = false;
EnableAskCommunityLink = true;
};
AnnouncementSettings.EnableBanner = false;
GitLabSettings = {
Enable = true;
Mattermost: Enable networking for the container. Otherwise, the login via keycloak will fail, as mattermost cannot verify the associated token. Since networking.nat only appears to work for ipv4 and I have no idea how to do it with ipv6, this unfortunately implies downgrading the container's networking to ipv4 only ...
2021-03-16 22:59:32 +00:00
Id = "mattermost-beta";
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
Scope = "";
AuthEndpoint = "https://auth.infra4future.de/auth/realms/forfuture/protocol/openid-connect/auth";
TokenEndpoint = "https://auth.infra4future.de/auth/realms/forfuture/protocol/openid-connect/token";
UserApiEndpoint = "https://auth.infra4future.de/auth/realms/forfuture/protocol/openid-connect/userinfo";
};
# for some reason, these don't appear to be working; the startup
# process complaines and sets these back to en
LocalizationSettings = {
DefaultServerLocale = "de";
DefaultClientLocale = "de";
AvailableLocales = "de,en";
};
MessageExportSettings.EnableExport = false;
# plugins appear to have trouble with the read-only filesystem; it may
# be necessary to manually change their paths etc.
PluginSettings = {
Enable = true;
EnableUploads = true;
Plugins = {
bigbluebutton = {
adminonly = false;
base_url = "https://bbb.infra4future.de/bigbluebutton/api";
salt = "zKCsNeaEniC115ynHOsZopgA4iTiJjzgeiPNoCEc";
};
"com.github.matterpoll.matterpoll" = {
experimentalui = true;
trigger = "poll";
};
};
PluginStates = {
bigbluebutton.Enable = true;
"com.github.matterpoll.matterpoll".Enable = true;
};
};
ComplianceSettings.Enable = false;
ClusterSettings.Enable = false;
MetricsSettings.Enable = false;
GuestAccountsSettings.Enable = false;
};
# turn of the weirder parts of this module (which insist on passwords
# in nix files, instead of just using socket-based authentication)
#
# It will still attempt to use its default password, but postgres will
# just let it in regardless of that.
localDatabaseCreate = false;
};
services.postgresql = {
enable = lib.mkForce true; # mattermost sets this to false. wtf.
ensureDatabases = [ "mattermost" ];
ensureUsers = [ {
name = "mattermost";
ensurePermissions = { "DATABASE mattermost" = "ALL PRIVILEGES"; };
} ];
authentication = lib.mkForce ''
# Generated file; do not edit!
local all all trust
host mattermost mattermost ::1/128 trust
'';
};
networking.firewall.allowedTCPPorts = [ 3000 ];
services.coredns = {
enable = true;
config = ''
.:53 {
Mattermost: Enable networking for the container. Otherwise, the login via keycloak will fail, as mattermost cannot verify the associated token. Since networking.nat only appears to work for ipv4 and I have no idea how to do it with ipv6, this unfortunately implies downgrading the container's networking to ipv4 only ...
2021-03-16 22:59:32 +00:00
forward . 1.1.1.1
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
}
'';
};
};
};
mattermost: change url to mattermost-beta.infra4future.de I propose we deploy this sometime and see how it goes (as soon as someone sets up DNS for this).
2021-03-15 16:11:38 +00:00
services.nginx.virtualHosts."mattermost-beta.infra4future.de" = {
Mattermost: Enable networking for the container. Otherwise, the login via keycloak will fail, as mattermost cannot verify the associated token. Since networking.nat only appears to work for ipv4 and I have no idea how to do it with ipv6, this unfortunately implies downgrading the container's networking to ipv4 only ...
2021-03-16 22:59:32 +00:00
locations."/" = {
proxyPass = "http://${config.containers.mattermost.localAddress}:3000";
proxyWebsockets = true;
};
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
forceSSL = true;
enableACME = true;
};
Mattermost: Enable networking for the container. Otherwise, the login via keycloak will fail, as mattermost cannot verify the associated token. Since networking.nat only appears to work for ipv4 and I have no idea how to do it with ipv6, this unfortunately implies downgrading the container's networking to ipv4 only ...
2021-03-16 22:59:32 +00:00
networking.nat = {
enable = true;
internalInterfaces = [ "ve-mattermost" ];
externalInterface = "enp6s0";
};
init mattermost on hainich. This is an initial test config for mattermost on NixOS; the intention is to perhaps deploy this as soon as it looks reasonable, then have it running as a "beta instance" in parallel with the current instance on libocedrus for a while to see if any issues come up before we can make a permament switch here. The mattermost module has a somewhat weird approach to database configuration (per default, it generates an entire postgres config, and if told not to do that, it generates a /disabled/ postgrs config ...), which I have for the most part worked around. Mattermost provides extensive configuration options, which are usually changed using its web UI. I have instead set the more important ones using Nix, and made the config immutable --- however, the config of our current instance is rather long and full of default values; it may well be that I missed some important settings. Open questions which we may want to answer before deploying this: - is there a reason why we use mysql for our current instance? At least during my tests, mattermost appears to work just fine with postgres - to access the noreply@infra4future.de mail address, mattermost needs a password, which --- as it looks right now --- must be set in the nix store. Can we work around that or should we fork / override the module? - plugins are apparently broken right now - locales are broken as well, for whatever reason — the german locale is definitively present, but setting it as the default will break and then reverted by mattermost on startup - for now, I have set `mutableConfig` to `false`, i.e. any changes done in the mattermost web UI will be overwritten on next startup. This is great for reproducability, but less so for ease of use (and perhaps for secrets as well) --- do we want to keep it this way? - as it is right now, using this instead of our current instance would represent a version DOWNGRADE (from 5.30.6. to 5.25.3); this may break the database schema. We may have to package a more recent version of mattermost and use that instead. Things I was unable to test locally (in a nixos container): - authentication using "gitlab" / keycloak - mail notifications (including coredns forwarding) - more advanced stuff like notifications, anything to do with "true" multi-user interaction
2021-03-13 15:49:22 +00:00
}
Reference in a new issue Copy permalink