Commit graph

80148 commits

Author SHA1 Message Date
aszlig cf46256bbb
nixos/taskserver: Improve service dependencies
Using requiredBy is a bad idea for the initialisation units, because
whenever the Taskserver service is restarted the initialisation units
get restarted as well.

Also, make sure taskserver-init.service will be ordered *before*
taskserver.service.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 06:33:04 +02:00
aszlig bb7a819735
nixos/taskserver: Set up service namespaces
The Taskserver doesn't need access to the full /dev nor does it need a
shared /tmp. In addition, the initialisation services don't need network
access, so let's constrain them to the loopback device.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 06:30:05 +02:00
aszlig dd0d64afea
nixos/taskserver: Finish module documentation
Apart from the options manual, this should cover the basics for setting
up a Taskserver. I am not a native speaker so this can and (probably)
should be improved, especially the wording/grammar.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 06:19:59 +02:00
aszlig e2383b84f8
nixos/taskserver/helper: Improve CLI subcommands
Try to match the subcommands to act more like the subcommands from the
taskd binary and also add a subcommand to list groups.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 05:38:37 +02:00
aszlig ce0954020c
nixos/taskserver: Set allowedTCPPorts accordingly
As suggested by @matthiasbeyer:

"We might add a short note that this port has to be opened in the
firewall, or is this done by the service automatically?"

This commit now adds the listenPort to
networking.firewall.allowedTCPPorts as soon as the listenHost is not
"localhost".

In addition to that, this is now also documented in the listenHost
option declaration and I have removed disabling of the firewall from the
VM test.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 05:16:15 +02:00
aszlig 5be76d0b55
nixos/taskserver: Reorder into one mkMerge
No changes in functionality but rather just restructuring the module
definitions to be one mkMerge, which now uses mkIf from the top-level
scope of the CA initialization service so we can better abstract
additional options we might need there.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 05:07:52 +02:00
aszlig 5062bf1b84
nixos/taskserver/helper: Assert CA existence
We want to make sure that the helper tool won't work if the automatic CA
wasn't properly set up. This not only avoids race conditions if the tool
is started before the actual service is running but it also fails if
something during CA setup has failed so the user can investigate what
went wrong.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 04:57:03 +02:00
aszlig 2ced6fcc75
nixos/taskserver: Setup CA before main service
We need to explicitly make sure the CA is created before we actually
launch the main Taskserver service in order to avoid race conditions
where the preStart phase of the main service could possibly corrupt
certificates if it would be started in parallel.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 04:53:53 +02:00
aszlig 9279ec732b
nixos/taskserver: Introduce an extraConfig option
This is simply to add configuration lines to the generated configuration
file. The reason why I didn't went for an attribute set is that the
taskdrc file format doesn't map very well on Nix attributes, for example
the following can be set in taskdrc:

server = somestring
server.key = anotherstring

In order to use a Nix attribute set for that, it would be way too
complicated, for example if we want to represent the mentioned example
we'd have to do something like this:

{ server._top = somestring;
  server.key = anotherstring;
}

Of course, this would work as well but nothing is more simple than just
appending raw strings.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 04:21:55 +02:00
aszlig 9f1e536948
nixos/taskserver: Allow to specify expiration/bits
At least this should allow for some customisation of how the
certificates and keys are created. We now have two sub-namespaces within
PKI so it should be more clear which options you have to set if you want
to either manage your own CA or let the module create it automatically.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 04:14:33 +02:00
aszlig a41b109bc1
nixos/taskserver: Don't change imperative users
Whenever the nixos-taskserver tool was invoked manually for creating an
organisation/group/user we now add an empty file called .imperative to
the data directory.

During the preStart of the Taskserver service, we use process-json which
in turn now checks whether those .imperative files exist and if so, it
doesn't do anything with it.

This should now ensure that whenever there is a manually created user,
it doesn't get killed off by the declarative configuration in case it
shouldn't exist within that configuration.

In addition, we also add a small subtest to check whether this is
happening or not and fail if the imperatively created user got deleted
by process-json.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 03:42:13 +02:00
aszlig 9586795ef2
nixos/taskserver: Silence certtool everywhere
We only print the output whenever there is an error, otherwise let's
shut it up because it only shows information the user can gather through
other means. For example by invoking certtool manually, or by just
looking at private key files (the whole blurb it's outputting is in
there as well).

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 02:16:35 +02:00
aszlig cfb6ce2abe
nixos/tests/taskserver: Make tests less noisy
We were putting the whole output of "nixos-taskserver export-user" from
the server to the respective client and on every such operation the
whole output was shown again in the test log.

Now we're *only* showing these details whenever a user import fails on
the client.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 01:49:47 +02:00
aszlig 7889fcfa41
nixos/taskserver/helper: Implement deletion
Now we finally can delete organisations, groups and users along with
certificate revocation. The new subtests now make sure that the client
certificate is also revoked (both when removing the whole organisation
and just a single user).

If we use the imperative way to add and delete users, we have to restart
the Taskserver in order for the CRL to be effective.

However, by using the declarative configuration we now get this for
free, because removing a user will also restart the service and thus its
client certificate will end up in the CRL.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 01:41:41 +02:00
aszlig 3008836fee
nixos/taskserver: Add a command to reload service
Unfortunately we don't have a better way to check whether the reload has
been done successfully, but at least we now *can* reload it without
figuring out the exact signal to send to the process.

Note that on reload, Taskserver will not reload the CRL file. For that
to work, a full restart needs to be done.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-12 01:04:34 +02:00
aszlig b6643102d6
nixos/taskserver: Generate a cert revocation list
If we want to revoke client certificates and want the server to actually
notice the revocation, we need to have a valid certificate revocation
list.

Right now the expiration_days is set to 10 years, but that's merely to
actually get certtool to actually generate the CRL without trying to
prompt for user input.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 23:07:58 +02:00
aszlig d0ab617974
nixos/taskserver: Constrain server cert perms
It doesn't do much harm to make the server certificate world readable,
because even though it's not accessible anymore via the file system,
someone can still get it by simply doing a TLS handshake with the
server.

So this is solely for consistency.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 22:59:30 +02:00
aszlig 6e10705754
nixos/taskserver: Handle declarative conf via JSON
We now no longer have the stupid --service-helper option, which silences
messages about already existing organisations, users or groups.

Instead of that option, we now have a new subcommand called
"process-json", which accepts a JSON file directly from the specified
NixOS module options and creates/deletes the users accordingly.

Note that this still has a two issues left to solve in this area:

 * Deletion is not supported yet.
 * If a user is created imperatively, the next run of process-json will
   delete it once deletion is supported.

So we need to implement deletion and a way to mark organisations, users
and groups as "imperatively managed".

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 22:24:58 +02:00
aszlig cf0501600a
nixos/taskserver/helper: Factor out program logic
The Click functions really are for the command line and should be solely
used for that.

What I have in mind is that instead of that crappy --service-helper
argument, we should really have a new subcommand that is expecting JSON
which is directly coming from the services.taskserver.organisations
module option.

That way we can decrease even more boilerplate and we can also ensure
that organisations, users and groups get properly deleted if they're
removed from the NixOS configuration.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 22:19:50 +02:00
aszlig 7875885fb2
nixos/taskserver: Link to manual within .enable
With <olink/> support in place, we can now reference the Taskserver
section within the NixOS manual, so that users reading the manpage of
configuration.nix(5) won't miss this information.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 18:45:09 +02:00
aszlig 1d77dcaed3
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.

Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.

So, that's where we are now:

There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.

The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.

So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.

Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.

However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.

The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 18:38:04 +02:00
aszlig b19fdc9ec9
nixos/taskserver: Set server.crl for automatic CA
Currently, we don't handle this yet, but let's set it so that we cover
all the options.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 13:38:33 +02:00
aszlig 05a7cd17fc
nixos/taskserver: Rename .pki options
We're now using .pki.server.* and .pki.ca.* so that it's entirely clear
what these keys/certificates are for. For example we had just .pki.key
before, which doesn't really tell very much about what it's for except
if you look at the option description.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 13:33:48 +02:00
aszlig 6395c87d07
nixos/taskserver: Improve doc for PKI options
The improvement here is just that we're adding a big <note/> here so
that users of these options are aware that whenever they're setting one
of these the certificates and keys are _not_ created automatically.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 12:58:29 +02:00
aszlig 6df374910f
nixos/taskserver: Move .trust out of .pki
This is clearly a server configuration option and has nothing to do with
certificate creation and signing, so let's move it away from the .pki
namespace.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 12:47:39 +02:00
aszlig 3affead91b
nixos/taskserver: Move .pki.fqdn to .fqdn
It's not necessarily related to the PKI options, because this is also
used for setting the server address on the Taskwarrior client.

So if someone doesn't have his/her own certificates from another CA, all
options that need to be adjusted are in .pki. And if someone doesn't
want to bother with getting certificates from another CA, (s)he just
doesn't set anything in .pki.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 12:42:20 +02:00
aszlig 6de94e7d24
nixos/taskserver: Rename .server options to .pki
After moving out the PKI-unrelated options, let's name this a bit more
appropriate, so we can finally get rid of the taskserver.server thing.

This also moves taskserver.caCert to taskserver.pki.caCert, because that
clearly belongs to the PKI options.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 12:38:16 +02:00
aszlig d6bd457d1f
nixos/taskserver: Rename server.{host,port}
Having an option called services.taskserver.server.host is quite
confusing because we already have "server" in the service name, so let's
first get rid of the listening options before we rename the rest of the
options in that .server attribute.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 12:26:34 +02:00
aszlig 636e0e552d
nixos/tests/taskserver: Test imperative users
As the nixos-taskserver command can also be used to imperatively manage
users, we need to test this as well.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 12:03:16 +02:00
aszlig 2acf8677fa
nixos/taskserver: Rewrite helper-tool in Python
In the comments of the pull request @nbp wrote:

"Why is it implemented in 3 different languages: Nix, Bash and C?"

And he's right, it doesn't make sense, because we were using C as a
runuser replacement and used Nix to generate the shellscript
boilerplates.

Writing this in Python gets rid of all of this and we also don't need
the boilerplate as well, because we're using Click to handle all the
command line stuff.

Note that this currently is a 1:1 implementation of what we had before.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-11 12:02:52 +02:00
aszlig 85832de2e8
nixos/taskserver: Remove client.cert option
The option is solely for debugging purposes (particularly the unit tests
of the project itself) and doesn't make sense to include it in the NixOS
module options.

If people want to use this, we might want to introduce another option so
that we can insert arbitrary configuration lines.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-10 21:37:12 +02:00
aszlig 64e566a49c
nixos/taskserver: Add module documentation
It's not by any means exhaustive, but we're still going to change the
implementation, so let's just use this as a starting point.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-07 14:26:12 +02:00
aszlig 8b793d1916
nixos/taskserver: Rename client.{allow,deny}
These values match against the client IDs only, so let's rename it to
something that actually reflects that. Having client.cert in the same
namespace also could lead to confusion, because the client.cert setting
is for the *debugging* client only.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-07 14:26:11 +02:00
aszlig 04fa5dcdb8
nixos/taskserver: Fix type/description for ciphers
Referring to the GnuTLS documentation isn't very nice if the user has to
use a search engine to find that documentation. So let's directly link
to it.

The type was "str" before, but it's actually a colon-separated string,
so if we set options in multiple modules, the result is one concatenated
string.

I know there is types.envVar, which does the same as separatedString ":"
but I found that it could confuse the reader of the Taskserver module.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-07 14:22:25 +02:00
aszlig 33f948c88b
nixos/taskserver: Fix type for client.{allow,deny}
We already document that we allow special values such as "all" and
"none", but the type doesn't represent that. So let's use an enum in
conjuction with a loeOf type so that this becomes clear.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-07 14:21:42 +02:00
aszlig 2d89617052
nixos/taskserver: Rename nixos-taskdctl
Using nixos-taskserver is more verbose but less cryptic and I think it
fits the purpose better because it can't be confused to be a wrapper
around the taskdctl command from the upstream project as
nixos-taskserver shares no commonalities with it.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 78925e4a90
nixos/taskserver: Factor out nixos-taskdctl
With a cluttered up module source it's really a pain to navigate through
it, so it's a good idea to put it into another file.

No changes in functionality here, just splitting up the files and fixing
references.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 61b8d9ebe0
nixos/tests: Add a test for the Taskserver service
A small test which checks whether tasks can be synced using the
Taskserver.

It doesn't test group functionality because I suspect that they're not
yet implemented upstream. I haven't done an in-depth check on that but I
couldn't find a method of linking groups to users yet so I guess this
will get in with one of the text releases of Taskwarrior/Taskserver.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 0141b4887d
nixos/taskserver: Use nixos-taskdctl in preStart
Finally, this is where we declaratively set up our organisations and
users/groups, which looks like this in the system configuration:

services.taskserver.organisations.NixOS.users = [ "alice" "bob" ];

This automatically sets up "alice" and "bob" for the "NixOS"
organisation, generates the required client keys and signs it via the
CA.

However, we still need to use nixos-taskdctl export-user in order to
import these certificates on the client.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 227229653a
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 18:53:31 +02:00
aszlig 5146f76095
nixos/taskserver: Add an option for organisations
We want to declaratively specify users and organisations, so let's add
another module option "organisations", which allows us to specify users,
groups and of course organisations.

The implementation of this is not yet done and this is just to feed the
boilerplate.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 274fe2a23b
nixos/taskserver: Fix generating server cert
We were generating a self-signed certificate for the server so far,
which we obviously don't want.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 77d7545fac
nixos/taskserver: Introduce a new fqdn option
Using just the host for the common name *and* for listening on the port
is quite a bad idea if you want to listen on something like :: or an
internal IP address which is proxied/tunneled to the outside.

Hence this separates host and fqdn.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig d94ac7a454
nixos/taskserver: Use types.str instead of string
The "string" option type has been deprecated since a long time
(800f9c2), so let's not use it here.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 411c6f77a3
nixos/taskserver: Add trust option to config file
The server starts up without that option anyway, but it complains about
its value not being set. As we probably want to have access to that
configuration value anyway, let's expose this via the NixOS module as
well.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 1f410934f2
nixos/taskserver: Properly indent CA config lines
No change in functionality, but it's easier to read when properly
indented.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 3d820d5ba1
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>
2016-04-05 18:53:31 +02:00
aszlig 6d38a59c2d
nixos/taskserver: Improve module options
The descriptions for the options previously seem to be from the
taskdrc(5) manual page. So in cases where they didn't make sense for us
I changed the wording a bit (for example for client.deny we don't have a
"comma-separated list".

Also, I've reordered things a bit for consistency (type, default,
example and then description) and add missing types, examples and
docbook tags.

Options that are not used by default now have a null value, so that we
can generate a configuration file out of all the options defined for the
module.

The dataDir default value is now /var/lib/taskserver, because it doesn't
make sense to put just yet another empty subdirectory in it and "data"
doesn't quite make sense anyway, because it also contains the
configuration file as well.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 8081c791e9
nixos/taskserver: Remove options for log/pidFile
We're aiming for a proper integration into systemd/journald, so we
really don't want zillions of separate log files flying around in our
system.

Same as with the pidFile. The latter is only needed for taskdctl, which
is a SysV-style initscript and all of its functionality plus a lot more
is handled by systemd already.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00
aszlig 5060ee456c
nixos/taskserver: Unify taskd user and group
The service doesn't start with the "taskd" user being present, so we
really should add it. And while at it, it really makes sense to add a
default group as well.

I'm using a check for the user/group name as well, to allow the
taskserver to be run as an existing user.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2016-04-05 18:53:31 +02:00