nixpkgs/nixos/modules/services/web-apps/coder.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

209 lines
5.8 KiB
Nix
Raw Normal View History

2022-10-24 20:08:00 +00:00
{ config, lib, options, pkgs, ... }:
with lib;
let
cfg = config.services.coder;
name = "coder";
in {
options = {
services.coder = {
enable = mkEnableOption (lib.mdDoc "Coder service");
user = mkOption {
type = types.str;
default = "coder";
description = lib.mdDoc ''
User under which the coder service runs.
::: {.note}
If left as the default value this user will automatically be created
on system activation, otherwise it needs to be configured manually.
:::
'';
};
group = mkOption {
type = types.str;
default = "coder";
description = lib.mdDoc ''
Group under which the coder service runs.
::: {.note}
If left as the default value this group will automatically be created
on system activation, otherwise it needs to be configured manually.
:::
'';
};
package = mkPackageOption pkgs "coder" { };
2022-10-24 20:08:00 +00:00
homeDir = mkOption {
type = types.str;
description = lib.mdDoc ''
Home directory for coder user.
'';
default = "/var/lib/coder";
};
listenAddress = mkOption {
type = types.str;
description = lib.mdDoc ''
Listen address.
'';
default = "127.0.0.1:3000";
};
accessUrl = mkOption {
type = types.nullOr types.str;
description = lib.mdDoc ''
Access URL should be a external IP address or domain with DNS records pointing to Coder.
'';
default = null;
example = "https://coder.example.com";
};
wildcardAccessUrl = mkOption {
type = types.nullOr types.str;
description = lib.mdDoc ''
If you are providing TLS certificates directly to the Coder server, you must use a single certificate for the root and wildcard domains.
'';
default = null;
example = "*.coder.example.com";
};
database = {
createLocally = mkOption {
type = types.bool;
default = true;
description = lib.mdDoc ''
Create the database and database user locally.
'';
};
host = mkOption {
type = types.str;
default = "/run/postgresql";
description = lib.mdDoc ''
Hostname hosting the database.
'';
};
database = mkOption {
type = types.str;
default = "coder";
description = lib.mdDoc ''
Name of database.
'';
};
username = mkOption {
type = types.str;
default = "coder";
description = lib.mdDoc ''
Username for accessing the database.
'';
};
password = mkOption {
type = types.nullOr types.str;
default = null;
description = lib.mdDoc ''
Password for accessing the database.
'';
};
sslmode = mkOption {
type = types.nullOr types.str;
default = "disable";
description = lib.mdDoc ''
Password for accessing the database.
'';
};
};
tlsCert = mkOption {
type = types.nullOr types.path;
description = lib.mdDoc ''
The path to the TLS certificate.
'';
default = null;
};
tlsKey = mkOption {
type = types.nullOr types.path;
description = lib.mdDoc ''
The path to the TLS key.
'';
default = null;
};
};
};
config = mkIf cfg.enable {
assertions = [
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 11:50:09 +00:00
{ assertion = cfg.database.createLocally -> cfg.database.username == name && cfg.database.database == cfg.database.username;
message = "services.coder.database.username must be set to ${name} if services.coder.database.createLocally is set true";
2022-10-24 20:08:00 +00:00
}
];
systemd.services.coder = {
description = "Coder - Self-hosted developer workspaces on your infra";
after = [ "network.target" ];
wantedBy = [ "multi-user.target" ];
environment = {
CODER_ACCESS_URL = cfg.accessUrl;
CODER_WILDCARD_ACCESS_URL = cfg.wildcardAccessUrl;
CODER_PG_CONNECTION_URL = "user=${cfg.database.username} ${optionalString (cfg.database.password != null) "password=${cfg.database.password}"} database=${cfg.database.database} host=${cfg.database.host} ${optionalString (cfg.database.sslmode != null) "sslmode=${cfg.database.sslmode}"}";
CODER_ADDRESS = cfg.listenAddress;
CODER_TLS_ENABLE = optionalString (cfg.tlsCert != null) "1";
CODER_TLS_CERT_FILE = cfg.tlsCert;
CODER_TLS_KEY_FILE = cfg.tlsKey;
};
serviceConfig = {
ProtectSystem = "full";
PrivateTmp = "yes";
PrivateDevices = "yes";
SecureBits = "keep-caps";
AmbientCapabilities = "CAP_IPC_LOCK CAP_NET_BIND_SERVICE";
CacheDirectory = "coder";
CapabilityBoundingSet = "CAP_SYSLOG CAP_IPC_LOCK CAP_NET_BIND_SERVICE";
KillSignal = "SIGINT";
KillMode = "mixed";
NoNewPrivileges = "yes";
Restart = "on-failure";
ExecStart = "${cfg.package}/bin/coder server";
User = cfg.user;
Group = cfg.group;
};
};
services.postgresql = lib.mkIf cfg.database.createLocally {
enable = true;
ensureDatabases = [
cfg.database.database
];
ensureUsers = [{
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 11:50:09 +00:00
name = cfg.user;
ensureDBOwnership = true;
2022-10-24 20:08:00 +00:00
}
];
};
users.groups = optionalAttrs (cfg.group == name) {
"${cfg.group}" = {};
};
users.users = optionalAttrs (cfg.user == name) {
${name} = {
description = "Coder service user";
group = cfg.group;
home = cfg.homeDir;
createHome = true;
isSystemUser = true;
};
};
};
}