2015-05-07 17:49:01 +02:00
|
|
|
{ config, lib, pkgs, ... }:
|
|
|
|
|
|
|
|
with lib;
|
|
|
|
|
|
|
|
let
|
|
|
|
cfg = config.services.taskserver;
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
|
|
|
taskd = "${pkgs.taskserver}/bin/taskd";
|
|
|
|
|
2016-04-12 04:14:33 +02:00
|
|
|
mkManualPkiOption = desc: mkOption {
|
2016-04-11 12:58:29 +02:00
|
|
|
type = types.nullOr types.path;
|
|
|
|
default = null;
|
|
|
|
description = desc + ''
|
|
|
|
<note><para>
|
|
|
|
Setting this option will prevent automatic CA creation and handling.
|
|
|
|
</para></note>
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2016-04-12 04:14:33 +02:00
|
|
|
manualPkiOptions = {
|
|
|
|
ca.cert = mkManualPkiOption ''
|
2016-04-11 13:33:48 +02:00
|
|
|
Fully qualified path to the CA certificate.
|
2016-04-11 12:58:29 +02:00
|
|
|
'';
|
|
|
|
|
2016-04-12 04:14:33 +02:00
|
|
|
server.cert = mkManualPkiOption ''
|
2016-04-11 13:33:48 +02:00
|
|
|
Fully qualified path to the server certificate.
|
2016-04-11 12:58:29 +02:00
|
|
|
'';
|
|
|
|
|
2016-04-12 04:14:33 +02:00
|
|
|
server.crl = mkManualPkiOption ''
|
2016-04-11 12:58:29 +02:00
|
|
|
Fully qualified path to the server certificate revocation list.
|
|
|
|
'';
|
|
|
|
|
2016-04-12 04:14:33 +02:00
|
|
|
server.key = mkManualPkiOption ''
|
2016-04-11 12:58:29 +02:00
|
|
|
Fully qualified path to the server key.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2016-04-12 04:14:33 +02:00
|
|
|
mkAutoDesc = preamble: ''
|
|
|
|
${preamble}
|
|
|
|
|
|
|
|
<note><para>
|
|
|
|
This option is for the automatically handled CA and will be ignored if any
|
|
|
|
of the <option>services.taskserver.pki.manual.*</option> options are set.
|
|
|
|
</para></note>
|
|
|
|
'';
|
|
|
|
|
|
|
|
mkExpireOption = desc: mkOption {
|
|
|
|
type = types.nullOr types.int;
|
|
|
|
default = null;
|
|
|
|
example = 365;
|
2019-04-24 05:48:22 +02:00
|
|
|
apply = val: if val == null then -1 else val;
|
2016-04-12 04:14:33 +02:00
|
|
|
description = mkAutoDesc ''
|
|
|
|
The expiration time of ${desc} in days or <literal>null</literal> for no
|
|
|
|
expiration time.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
autoPkiOptions = {
|
|
|
|
bits = mkOption {
|
|
|
|
type = types.int;
|
|
|
|
default = 4096;
|
|
|
|
example = 2048;
|
|
|
|
description = mkAutoDesc "The bit size for generated keys.";
|
|
|
|
};
|
|
|
|
|
|
|
|
expiration = {
|
|
|
|
ca = mkExpireOption "the CA certificate";
|
|
|
|
server = mkExpireOption "the server certificate";
|
|
|
|
client = mkExpireOption "client certificates";
|
|
|
|
crl = mkExpireOption "the certificate revocation list (CRL)";
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2016-04-11 13:33:48 +02:00
|
|
|
needToCreateCA = let
|
|
|
|
notFound = path: let
|
|
|
|
dotted = concatStringsSep "." path;
|
|
|
|
in throw "Can't find option definitions for path `${dotted}'.";
|
|
|
|
findPkiDefinitions = path: attrs: let
|
|
|
|
mkSublist = key: val: let
|
|
|
|
newPath = path ++ singleton key;
|
|
|
|
in if isOption val
|
2016-04-12 04:14:33 +02:00
|
|
|
then attrByPath newPath (notFound newPath) cfg.pki.manual
|
2016-04-11 13:33:48 +02:00
|
|
|
else findPkiDefinitions newPath val;
|
|
|
|
in flatten (mapAttrsToList mkSublist attrs);
|
2019-04-24 05:48:22 +02:00
|
|
|
in all (x: x == null) (findPkiDefinitions [] manualPkiOptions);
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2018-07-20 22:56:59 +02:00
|
|
|
orgOptions = { ... }: {
|
2016-04-05 17:27:58 +02:00
|
|
|
options.users = mkOption {
|
|
|
|
type = types.uniq (types.listOf types.str);
|
|
|
|
default = [];
|
|
|
|
example = [ "alice" "bob" ];
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-05 17:27:58 +02:00
|
|
|
A list of user names that belong to the organization.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
options.groups = mkOption {
|
|
|
|
type = types.listOf types.str;
|
|
|
|
default = [];
|
|
|
|
example = [ "workers" "slackers" ];
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-05 17:27:58 +02:00
|
|
|
A list of group names that belong to the organization.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2016-04-15 00:28:57 +02:00
|
|
|
certtool = "${pkgs.gnutls.bin}/bin/certtool";
|
2016-04-12 02:16:35 +02:00
|
|
|
|
2022-02-11 03:04:34 +01:00
|
|
|
nixos-taskserver = with pkgs.python3.pkgs; buildPythonApplication {
|
2016-04-11 11:52:02 +02:00
|
|
|
name = "nixos-taskserver";
|
|
|
|
|
2018-11-08 11:59:03 +01:00
|
|
|
src = pkgs.runCommand "nixos-taskserver-src" { preferLocalBuild = true; } ''
|
2016-04-11 11:52:02 +02:00
|
|
|
mkdir -p "$out"
|
|
|
|
cat "${pkgs.substituteAll {
|
|
|
|
src = ./helper-tool.py;
|
2016-04-12 02:16:35 +02:00
|
|
|
inherit taskd certtool;
|
2016-04-11 12:42:20 +02:00
|
|
|
inherit (cfg) dataDir user group fqdn;
|
2016-04-12 04:14:33 +02:00
|
|
|
certBits = cfg.pki.auto.bits;
|
|
|
|
clientExpiration = cfg.pki.auto.expiration.client;
|
|
|
|
crlExpiration = cfg.pki.auto.expiration.crl;
|
2017-05-06 19:50:02 +02:00
|
|
|
isAutoConfig = if needToCreateCA then "True" else "False";
|
2016-04-11 11:52:02 +02:00
|
|
|
}}" > "$out/main.py"
|
|
|
|
cat > "$out/setup.py" <<EOF
|
|
|
|
from setuptools import setup
|
|
|
|
setup(name="nixos-taskserver",
|
|
|
|
py_modules=["main"],
|
|
|
|
install_requires=["Click"],
|
|
|
|
entry_points="[console_scripts]\\nnixos-taskserver=main:cli")
|
|
|
|
EOF
|
|
|
|
'';
|
|
|
|
|
2022-01-26 21:55:25 +01:00
|
|
|
propagatedBuildInputs = [ click ];
|
nixos/taskserver: Add a nixos-taskdctl command
It's a helper for NixOS systems to make it easier to handle CA
certificate signing, similar to what taskd provides but comes preseeded
with the values from the system configuration.
The tool is very limited at the moment and only allows to *add*
organisations, users and groups. Deletion and suspension however is much
simpler to implement, because we don't need to handle certificate
signing.
Another limitation is that we don't take into account whether
certificates and keys are already set in the system configuration and if
they're set it will fail spectacularly.
For passing the commands to the taskd command, we're using a small C
program which does setuid() and setgid() to the Taskserver user and
group, because runuser(1) needs PAM (quite pointless if you're already
root) and su(1) doesn't allow for setting the group and setgid()s to the
default group of the user, so it even doesn't work in conjunction with
sg(1).
In summary, we now have a shiny nixos-taskdctl command, which lets us do
things like:
nixos-taskdctl add-org NixOS
nixos-taskdctl add-user NixOS alice
nixos-taskdctl export-user NixOS alice
The last command writes a series of shell commands to stdout, which then
can be imported on the client by piping it into a shell as well as doing
it for example via SSH:
ssh root@server nixos-taskdctl export-user NixOS alice | sh
Of course, in terms of security we need to improve this even further so
that we generate the private key on the client and just send a CSR to
the server so that we don't need to push any secrets over the wire.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 17:31:58 +02:00
|
|
|
};
|
|
|
|
|
2015-05-07 17:49:01 +02:00
|
|
|
in {
|
|
|
|
options = {
|
|
|
|
services.taskserver = {
|
2016-04-11 18:45:09 +02:00
|
|
|
enable = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = false;
|
2022-01-26 21:55:25 +01:00
|
|
|
description = let
|
|
|
|
url = "https://nixos.org/manual/nixos/stable/index.html#module-services-taskserver";
|
|
|
|
in ''
|
2016-04-11 18:45:09 +02:00
|
|
|
Whether to enable the Taskwarrior server.
|
|
|
|
|
|
|
|
More instructions about NixOS in conjuction with Taskserver can be
|
2022-01-26 21:55:25 +01:00
|
|
|
found <link xlink:href="${url}">in the NixOS manual</link>.
|
2016-04-11 18:45:09 +02:00
|
|
|
'';
|
|
|
|
};
|
2015-05-07 17:49:01 +02:00
|
|
|
|
|
|
|
user = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.str;
|
2015-05-07 17:49:01 +02:00
|
|
|
default = "taskd";
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc "User for Taskserver.";
|
2015-05-07 17:49:01 +02:00
|
|
|
};
|
|
|
|
|
2015-09-27 15:35:42 +02:00
|
|
|
group = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.str;
|
2015-09-27 15:35:42 +02:00
|
|
|
default = "taskd";
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc "Group for Taskserver.";
|
2015-09-27 15:35:42 +02:00
|
|
|
};
|
|
|
|
|
2015-05-07 17:49:01 +02:00
|
|
|
dataDir = mkOption {
|
|
|
|
type = types.path;
|
2015-09-27 19:30:02 +02:00
|
|
|
default = "/var/lib/taskserver";
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc "Data directory for Taskserver.";
|
2015-05-07 17:49:01 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
ciphers = mkOption {
|
2016-04-07 12:55:39 +02:00
|
|
|
type = types.nullOr (types.separatedString ":");
|
2015-09-27 19:30:02 +02:00
|
|
|
default = null;
|
2016-04-07 12:55:39 +02:00
|
|
|
example = "NORMAL:-VERS-SSL3.0";
|
|
|
|
description = let
|
|
|
|
url = "https://gnutls.org/manual/html_node/Priority-Strings.html";
|
|
|
|
in ''
|
|
|
|
List of GnuTLS ciphers to use. See the GnuTLS documentation about
|
|
|
|
priority strings at <link xlink:href="${url}"/> for full details.
|
2015-05-07 17:49:01 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2016-04-05 17:27:58 +02:00
|
|
|
organisations = mkOption {
|
|
|
|
type = types.attrsOf (types.submodule orgOptions);
|
|
|
|
default = {};
|
|
|
|
example.myShinyOrganisation.users = [ "alice" "bob" ];
|
|
|
|
example.myShinyOrganisation.groups = [ "staff" "outsiders" ];
|
|
|
|
example.yetAnotherOrganisation.users = [ "foo" "bar" ];
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-05 17:27:58 +02:00
|
|
|
An attribute set where the keys name the organisation and the values
|
2022-07-28 23:19:15 +02:00
|
|
|
are a set of lists of {option}`users` and
|
|
|
|
{option}`groups`.
|
2016-04-05 17:27:58 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2015-05-07 17:49:01 +02:00
|
|
|
confirmation = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.bool;
|
2015-05-07 17:49:01 +02:00
|
|
|
default = true;
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2015-05-07 17:49:01 +02:00
|
|
|
Determines whether certain commands are confirmed.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
debug = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.bool;
|
2015-05-07 17:49:01 +02:00
|
|
|
default = false;
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2015-05-07 17:49:01 +02:00
|
|
|
Logs debugging information.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
extensions = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.nullOr types.path;
|
|
|
|
default = null;
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2015-09-27 19:30:02 +02:00
|
|
|
Fully qualified path of the Taskserver extension scripts.
|
|
|
|
Currently there are none.
|
2015-05-07 17:49:01 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
ipLog = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.bool;
|
|
|
|
default = false;
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2015-05-07 17:49:01 +02:00
|
|
|
Logs the IP addresses of incoming requests.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
queueSize = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.int;
|
2015-05-07 17:49:01 +02:00
|
|
|
default = 10;
|
2022-08-05 19:39:00 +02:00
|
|
|
description = lib.mdDoc ''
|
|
|
|
Size of the connection backlog, see {manpage}`listen(2)`.
|
2015-05-07 17:49:01 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
requestLimit = mkOption {
|
2015-09-27 19:30:02 +02:00
|
|
|
type = types.int;
|
2015-05-07 17:49:01 +02:00
|
|
|
default = 1048576;
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2015-05-07 17:49:01 +02:00
|
|
|
Size limit of incoming requests, in bytes.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2016-04-07 13:20:20 +02:00
|
|
|
allowedClientIDs = mkOption {
|
2016-11-04 05:33:59 +01:00
|
|
|
type = with types; either str (listOf str);
|
2016-04-07 13:20:20 +02:00
|
|
|
default = [];
|
|
|
|
example = [ "[Tt]ask [2-9]+" ];
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-07 13:20:20 +02:00
|
|
|
A list of regular expressions that are matched against the reported
|
2022-07-28 23:19:15 +02:00
|
|
|
client id (such as `task 2.3.0`).
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2022-07-28 23:19:15 +02:00
|
|
|
The values `all` or `none` have
|
2016-04-07 13:20:20 +02:00
|
|
|
special meaning. Overidden by any entry in the option
|
2022-07-28 23:19:15 +02:00
|
|
|
{option}`services.taskserver.disallowedClientIDs`.
|
2016-04-07 13:20:20 +02:00
|
|
|
'';
|
|
|
|
};
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2016-04-07 13:20:20 +02:00
|
|
|
disallowedClientIDs = mkOption {
|
2016-11-04 05:33:59 +01:00
|
|
|
type = with types; either str (listOf str);
|
2016-04-07 13:20:20 +02:00
|
|
|
default = [];
|
|
|
|
example = [ "[Tt]ask [2-9]+" ];
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-07 13:20:20 +02:00
|
|
|
A list of regular expressions that are matched against the reported
|
2022-07-28 23:19:15 +02:00
|
|
|
client id (such as `task 2.3.0`).
|
2015-09-27 19:30:02 +02:00
|
|
|
|
2022-07-28 23:19:15 +02:00
|
|
|
The values `all` or `none` have
|
2016-04-12 07:03:19 +02:00
|
|
|
special meaning. Any entry here overrides those in
|
2022-07-28 23:19:15 +02:00
|
|
|
{option}`services.taskserver.allowedClientIDs`.
|
2016-04-07 13:20:20 +02:00
|
|
|
'';
|
|
|
|
};
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2016-04-11 12:26:34 +02:00
|
|
|
listenHost = mkOption {
|
|
|
|
type = types.str;
|
|
|
|
default = "localhost";
|
2016-04-12 05:13:04 +02:00
|
|
|
example = "::";
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-11 12:26:34 +02:00
|
|
|
The address (IPv4, IPv6 or DNS) to listen on.
|
|
|
|
'';
|
|
|
|
};
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2016-04-11 12:26:34 +02:00
|
|
|
listenPort = mkOption {
|
|
|
|
type = types.int;
|
|
|
|
default = 53589;
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-11 12:26:34 +02:00
|
|
|
Port number of the Taskserver.
|
|
|
|
'';
|
|
|
|
};
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2022-02-11 02:30:44 +01:00
|
|
|
openFirewall = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = false;
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2022-02-11 02:30:44 +01:00
|
|
|
Whether to open the firewall for the specified Taskserver port.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2016-04-11 12:42:20 +02:00
|
|
|
fqdn = mkOption {
|
|
|
|
type = types.str;
|
|
|
|
default = "localhost";
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-11 12:42:20 +02:00
|
|
|
The fully qualified domain name of this server, which is also used
|
|
|
|
as the common name in the certificates.
|
|
|
|
'';
|
|
|
|
};
|
2016-04-05 16:16:14 +02:00
|
|
|
|
2016-04-11 12:47:39 +02:00
|
|
|
trust = mkOption {
|
|
|
|
type = types.enum [ "allow all" "strict" ];
|
|
|
|
default = "strict";
|
2022-07-28 23:19:15 +02:00
|
|
|
description = lib.mdDoc ''
|
2016-04-11 12:47:39 +02:00
|
|
|
Determines how client certificates are validated.
|
|
|
|
|
2022-07-28 23:19:15 +02:00
|
|
|
The value `allow all` performs no client
|
2016-04-11 12:47:39 +02:00
|
|
|
certificate validation. This is not recommended. The value
|
2022-07-28 23:19:15 +02:00
|
|
|
`strict` causes the client certificate to be
|
2016-04-11 12:47:39 +02:00
|
|
|
validated against a CA.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2016-04-12 04:14:33 +02:00
|
|
|
pki.manual = manualPkiOptions;
|
|
|
|
pki.auto = autoPkiOptions;
|
2016-04-12 04:21:55 +02:00
|
|
|
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
config = mkOption {
|
|
|
|
type = types.attrs;
|
|
|
|
example.client.cert = "/tmp/debugging.cert";
|
2022-08-05 19:39:00 +02:00
|
|
|
description = lib.mdDoc ''
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
Configuration options to pass to Taskserver.
|
|
|
|
|
2022-08-02 03:39:32 +02:00
|
|
|
The options here are the same as described in
|
2022-08-05 19:39:00 +02:00
|
|
|
{manpage}`taskdrc(5)`, but with one difference:
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
|
2022-08-05 19:39:00 +02:00
|
|
|
The `server` option is
|
|
|
|
`server.listen` here, because the
|
|
|
|
`server` option would collide with other options
|
|
|
|
like `server.cert` and we would run in a type error
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
(attribute set versus string).
|
|
|
|
|
|
|
|
Nix types like integers or booleans are automatically converted to
|
|
|
|
the right values Taskserver would expect.
|
2016-04-12 04:21:55 +02:00
|
|
|
'';
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
apply = let
|
|
|
|
mkKey = path: if path == ["server" "listen"] then "server"
|
|
|
|
else concatStringsSep "." path;
|
|
|
|
recurse = path: attrs: let
|
|
|
|
mapper = name: val: let
|
|
|
|
newPath = path ++ [ name ];
|
|
|
|
scalar = if val == true then "true"
|
|
|
|
else if val == false then "false"
|
|
|
|
else toString val;
|
|
|
|
in if isAttrs val then recurse newPath val
|
|
|
|
else [ "${mkKey newPath}=${scalar}" ];
|
|
|
|
in concatLists (mapAttrsToList mapper attrs);
|
|
|
|
in recurse [];
|
2016-04-12 04:21:55 +02:00
|
|
|
};
|
2015-05-07 17:49:01 +02:00
|
|
|
};
|
|
|
|
};
|
|
|
|
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
imports = [
|
|
|
|
(mkRemovedOptionModule ["services" "taskserver" "extraConfig"] ''
|
|
|
|
This option was removed in favor of `services.taskserver.config` with
|
|
|
|
different semantics (it's now a list of attributes instead of lines).
|
|
|
|
|
|
|
|
Please look up the documentation of `services.taskserver.config' to get
|
|
|
|
more information about the new way to pass additional configuration
|
|
|
|
options.
|
|
|
|
'')
|
|
|
|
];
|
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
config = mkMerge [
|
|
|
|
(mkIf cfg.enable {
|
2017-02-17 19:36:57 +01:00
|
|
|
environment.systemPackages = [ nixos-taskserver ];
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2019-09-14 19:51:29 +02:00
|
|
|
users.users = optionalAttrs (cfg.user == "taskd") {
|
|
|
|
taskd = {
|
|
|
|
uid = config.ids.uids.taskd;
|
|
|
|
description = "Taskserver user";
|
|
|
|
group = cfg.group;
|
|
|
|
};
|
2016-04-12 05:07:52 +02:00
|
|
|
};
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2019-09-14 19:51:29 +02:00
|
|
|
users.groups = optionalAttrs (cfg.group == "taskd") {
|
|
|
|
taskd.gid = config.ids.gids.taskd;
|
2016-04-12 05:07:52 +02:00
|
|
|
};
|
2015-09-27 15:35:42 +02:00
|
|
|
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
services.taskserver.config = {
|
|
|
|
# systemd related
|
|
|
|
daemon = false;
|
|
|
|
log = "-";
|
|
|
|
|
|
|
|
# logging
|
|
|
|
debug = cfg.debug;
|
|
|
|
ip.log = cfg.ipLog;
|
|
|
|
|
|
|
|
# general
|
|
|
|
ciphers = cfg.ciphers;
|
|
|
|
confirmation = cfg.confirmation;
|
|
|
|
extensions = cfg.extensions;
|
|
|
|
queue.size = cfg.queueSize;
|
|
|
|
request.limit = cfg.requestLimit;
|
|
|
|
|
|
|
|
# client
|
|
|
|
client.allow = cfg.allowedClientIDs;
|
|
|
|
client.deny = cfg.disallowedClientIDs;
|
|
|
|
|
|
|
|
# server
|
|
|
|
trust = cfg.trust;
|
|
|
|
server = {
|
|
|
|
listen = "${cfg.listenHost}:${toString cfg.listenPort}";
|
|
|
|
} // (if needToCreateCA then {
|
|
|
|
cert = "${cfg.dataDir}/keys/server.cert";
|
|
|
|
key = "${cfg.dataDir}/keys/server.key";
|
|
|
|
crl = "${cfg.dataDir}/keys/server.crl";
|
|
|
|
} else {
|
|
|
|
cert = "${cfg.pki.manual.server.cert}";
|
|
|
|
key = "${cfg.pki.manual.server.key}";
|
2019-07-27 20:53:24 +02:00
|
|
|
${mapNullable (_: "crl") cfg.pki.manual.server.crl} = "${cfg.pki.manual.server.crl}";
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
});
|
|
|
|
|
|
|
|
ca.cert = if needToCreateCA then "${cfg.dataDir}/keys/ca.cert"
|
|
|
|
else "${cfg.pki.manual.ca.cert}";
|
|
|
|
};
|
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
systemd.services.taskserver-init = {
|
2016-04-12 06:33:04 +02:00
|
|
|
wantedBy = [ "taskserver.service" ];
|
|
|
|
before = [ "taskserver.service" ];
|
2016-04-12 05:07:52 +02:00
|
|
|
description = "Initialize Taskserver Data Directory";
|
2015-09-27 15:35:42 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
preStart = ''
|
|
|
|
mkdir -m 0770 -p "${cfg.dataDir}"
|
|
|
|
chown "${cfg.user}:${cfg.group}" "${cfg.dataDir}"
|
|
|
|
'';
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
script = ''
|
|
|
|
${taskd} init
|
|
|
|
touch "${cfg.dataDir}/.is_initialized"
|
|
|
|
'';
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
environment.TASKDDATA = cfg.dataDir;
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
unitConfig.ConditionPathExists = "!${cfg.dataDir}/.is_initialized";
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
serviceConfig.Type = "oneshot";
|
|
|
|
serviceConfig.User = cfg.user;
|
|
|
|
serviceConfig.Group = cfg.group;
|
|
|
|
serviceConfig.PermissionsStartOnly = true;
|
2016-04-12 06:26:39 +02:00
|
|
|
serviceConfig.PrivateNetwork = true;
|
|
|
|
serviceConfig.PrivateDevices = true;
|
|
|
|
serviceConfig.PrivateTmp = true;
|
2016-04-12 05:07:52 +02:00
|
|
|
};
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
systemd.services.taskserver = {
|
|
|
|
description = "Taskwarrior Server";
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
wantedBy = [ "multi-user.target" ];
|
|
|
|
after = [ "network.target" ];
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
environment.TASKDDATA = cfg.dataDir;
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
preStart = let
|
|
|
|
jsonOrgs = builtins.toJSON cfg.organisations;
|
|
|
|
jsonFile = pkgs.writeText "orgs.json" jsonOrgs;
|
|
|
|
helperTool = "${nixos-taskserver}/bin/nixos-taskserver";
|
|
|
|
in "${helperTool} process-json '${jsonFile}'";
|
|
|
|
|
|
|
|
serviceConfig = {
|
taskserver: Pass configuration via command line
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
2017-02-17 19:18:04 +01:00
|
|
|
ExecStart = let
|
|
|
|
mkCfgFlag = flag: escapeShellArg "--${flag}";
|
|
|
|
cfgFlags = concatMapStringsSep " " mkCfgFlag cfg.config;
|
|
|
|
in "@${taskd} taskd server ${cfgFlags}";
|
2016-04-12 05:07:52 +02:00
|
|
|
ExecReload = "${pkgs.coreutils}/bin/kill -USR1 $MAINPID";
|
2016-04-12 06:43:21 +02:00
|
|
|
Restart = "on-failure";
|
2016-04-12 05:07:52 +02:00
|
|
|
PermissionsStartOnly = true;
|
2016-04-12 06:26:39 +02:00
|
|
|
PrivateTmp = true;
|
|
|
|
PrivateDevices = true;
|
2016-04-12 05:07:52 +02:00
|
|
|
User = cfg.user;
|
|
|
|
Group = cfg.group;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
})
|
2016-04-28 00:14:17 +02:00
|
|
|
(mkIf (cfg.enable && needToCreateCA) {
|
2016-04-12 05:07:52 +02:00
|
|
|
systemd.services.taskserver-ca = {
|
2016-04-12 06:33:04 +02:00
|
|
|
wantedBy = [ "taskserver.service" ];
|
2016-04-12 05:07:52 +02:00
|
|
|
after = [ "taskserver-init.service" ];
|
|
|
|
before = [ "taskserver.service" ];
|
|
|
|
description = "Initialize CA for TaskServer";
|
|
|
|
serviceConfig.Type = "oneshot";
|
|
|
|
serviceConfig.UMask = "0077";
|
2016-04-12 06:26:39 +02:00
|
|
|
serviceConfig.PrivateNetwork = true;
|
|
|
|
serviceConfig.PrivateTmp = true;
|
2016-04-12 05:07:52 +02:00
|
|
|
|
|
|
|
script = ''
|
|
|
|
silent_certtool() {
|
|
|
|
if ! output="$("${certtool}" "$@" 2>&1)"; then
|
|
|
|
echo "GNUTLS certtool invocation failed with output:" >&2
|
|
|
|
echo "$output" >&2
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
mkdir -m 0700 -p "${cfg.dataDir}/keys"
|
|
|
|
chown root:root "${cfg.dataDir}/keys"
|
|
|
|
|
|
|
|
if [ ! -e "${cfg.dataDir}/keys/ca.key" ]; then
|
|
|
|
silent_certtool -p \
|
|
|
|
--bits ${toString cfg.pki.auto.bits} \
|
|
|
|
--outfile "${cfg.dataDir}/keys/ca.key"
|
|
|
|
silent_certtool -s \
|
|
|
|
--template "${pkgs.writeText "taskserver-ca.template" ''
|
|
|
|
cn = ${cfg.fqdn}
|
|
|
|
expiration_days = ${toString cfg.pki.auto.expiration.ca}
|
|
|
|
cert_signing_key
|
|
|
|
ca
|
|
|
|
''}" \
|
|
|
|
--load-privkey "${cfg.dataDir}/keys/ca.key" \
|
|
|
|
--outfile "${cfg.dataDir}/keys/ca.cert"
|
|
|
|
|
|
|
|
chgrp "${cfg.group}" "${cfg.dataDir}/keys/ca.cert"
|
|
|
|
chmod g+r "${cfg.dataDir}/keys/ca.cert"
|
|
|
|
fi
|
nixos/taskserver: Refactor module for CA creation
Now the service starts up if only the services.taskserver.enable option
is set to true.
We now also have three systemd services (started in this order):
* taskserver-init: For creating the necessary data directory and also
includes a refecence to the configuration file in
the Nix store.
* taskserver-ca: Only enabled if none of the server.key, server.cert,
server.crl and caCert options are set, so we can
allow for certificates that are issued by another
CA.
This service creates a new CA key+certificate and a
server key+certificate and signs the latter using
the CA key.
The permissions of these keys/certs are set quite
strictly to allow only the root user to sign
certificates.
* taskserver: The main Taskserver service which just starts taskd.
We now also log to stdout and thus to the journal.
Of course, there are still a few problems left to solve, for instance:
* The CA currently only signs the server certificates, so it's
only usable for clients if the server doesn't validate client certs
(which is kinda pointless).
* Using "taskd <command>" is currently still a bit awkward to use, so
we need to properly wrap it in environment.systemPackages to set the
dataDir by default.
* There are still a few configuration options left to include, for
example the "trust" option.
* We might want to introduce an extraConfig option.
* It might be useful to allow for declarative configuration of
organisations and users, especially when it comes to creating client
certificates.
* The right signal has to be sent for the taskserver service to reload
properly.
* Currently the CA and server certificates are created using
server.host as the common name and doesn't set additional certificate
information. This could be improved by adding options that explicitly
set that information.
As for the config file, we might need to patch taskd to allow for
setting not only --data but also a --cfgfile, which then omits the
${dataDir}/config file. We can still use the "include" directive from
the file specified using --cfgfile in order to chainload
${dataDir}/config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2015-09-27 21:52:55 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
if [ ! -e "${cfg.dataDir}/keys/server.key" ]; then
|
|
|
|
silent_certtool -p \
|
|
|
|
--bits ${toString cfg.pki.auto.bits} \
|
|
|
|
--outfile "${cfg.dataDir}/keys/server.key"
|
|
|
|
|
|
|
|
silent_certtool -c \
|
|
|
|
--template "${pkgs.writeText "taskserver-cert.template" ''
|
|
|
|
cn = ${cfg.fqdn}
|
|
|
|
expiration_days = ${toString cfg.pki.auto.expiration.server}
|
|
|
|
tls_www_server
|
|
|
|
encryption_key
|
|
|
|
signing_key
|
|
|
|
''}" \
|
|
|
|
--load-ca-privkey "${cfg.dataDir}/keys/ca.key" \
|
|
|
|
--load-ca-certificate "${cfg.dataDir}/keys/ca.cert" \
|
|
|
|
--load-privkey "${cfg.dataDir}/keys/server.key" \
|
|
|
|
--outfile "${cfg.dataDir}/keys/server.cert"
|
|
|
|
|
|
|
|
chgrp "${cfg.group}" \
|
|
|
|
"${cfg.dataDir}/keys/server.key" \
|
|
|
|
"${cfg.dataDir}/keys/server.cert"
|
|
|
|
|
|
|
|
chmod g+r \
|
|
|
|
"${cfg.dataDir}/keys/server.key" \
|
|
|
|
"${cfg.dataDir}/keys/server.cert"
|
|
|
|
fi
|
2015-05-07 17:49:01 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
if [ ! -e "${cfg.dataDir}/keys/server.crl" ]; then
|
|
|
|
silent_certtool --generate-crl \
|
|
|
|
--template "${pkgs.writeText "taskserver-crl.template" ''
|
|
|
|
expiration_days = ${toString cfg.pki.auto.expiration.crl}
|
|
|
|
''}" \
|
|
|
|
--load-ca-privkey "${cfg.dataDir}/keys/ca.key" \
|
|
|
|
--load-ca-certificate "${cfg.dataDir}/keys/ca.cert" \
|
|
|
|
--outfile "${cfg.dataDir}/keys/server.crl"
|
|
|
|
|
|
|
|
chgrp "${cfg.group}" "${cfg.dataDir}/keys/server.crl"
|
|
|
|
chmod g+r "${cfg.dataDir}/keys/server.crl"
|
|
|
|
fi
|
2016-04-05 17:47:27 +02:00
|
|
|
|
2016-04-12 05:07:52 +02:00
|
|
|
chmod go+x "${cfg.dataDir}/keys"
|
|
|
|
'';
|
2015-05-07 17:49:01 +02:00
|
|
|
};
|
2016-04-12 05:07:52 +02:00
|
|
|
})
|
2022-02-11 02:30:44 +01:00
|
|
|
(mkIf (cfg.enable && cfg.openFirewall) {
|
2016-04-12 05:13:04 +02:00
|
|
|
networking.firewall.allowedTCPPorts = [ cfg.listenPort ];
|
|
|
|
})
|
2016-04-12 05:07:52 +02:00
|
|
|
];
|
2016-05-09 07:53:27 +02:00
|
|
|
|
|
|
|
meta.doc = ./doc.xml;
|
2015-05-07 17:49:01 +02:00
|
|
|
}
|