The test fails because the way the configuration switch was implemented
back then was by using a dummy configuration and simply activating that
dummy configuration from within the test script.
Nowadays, this doesn't work anymore and fails to typecheck because the
dummy "newServer" will inherit the same value for networking.hostName,
which in turn will generate two attributes for "server":
> testScriptWithTypes:43: error: Name "server" already defined on line 43
> [no-redef]
> client1: Machine; client2: Machine; server: Machine; server: Machine;
Fortunately, we don't need to do workarounds like this anymore and there
is the "specialisation" option, which allows to do this in a less ugly
way (and it also works with mypy).
Signed-off-by: aszlig <aszlig@nix.build>
This adds an option `services.taskserver.openFirewall` to allow the user
to choose whether or not the firewall port should be opened for the
service. This is no longer the case by default.
See also https://github.com/NixOS/nixpkgs/issues/19504.
test failed because gnutls-cli does not properly report connection
errors any more, fixed by increasing the debug level for gnutls-cli
Fixes: #84507Closes: #90718
Since IP address options were changed for 18.03, eval has failed with:
"The option `networking.interfaces.eth1.subnetMask' is used but not defined."
although this option is not used at all in nixos anymore.
The misleading error message seems to be generated from evaluating warnings
for `mkRemovedOptionModule ["subnetMask"]` which apparently broke here
when this test inherited network.interfaces from one VM config to another.
Cc: @aszlig
The helper tool had a very early check whether the automatically created
CA key/cert are available and thus it would abort if the key was
unavailable even though we don't need or even want to have the CA key.
Unfortunately our NixOS test didn't catch this, because it was just
switching from a configuration with an automatically created CA to a
manual configuration without deleting the generated keys and certs.
This is done now in the tests and it's also fixed in the helper tool.
Reported-by: @jpotier
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This subtest actually serves two purposes:
1. Test manual PKI configuration
2. Test changing of configuration files
In order to only test manual PKI configuration it would have been enough
to just add another server with a manual config.
But as the switch from automatic PKI config to manual config is probably
one of the most fundamental changes in configuration, so it serves
*very* well to also check whether changes in the NixOS configuration
actually have an impact in the real system.
So instead of adding another server, we now create a dummy "newServer"
machine, which is the new configuration for "server" and use
switch-to-configuration to switch "server" to the config of "newServer".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
