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>
The helper tool so far was only intended for use in automatic PKI
handling, but it also is very useful if you have an existing CA.
One of the main advantages is that you don't need to specify the data
directory anymore and the right permissions are also handled as well.
Another advantage is that we now have an uniform management tool for
both automatic and manual config, so the documentation in the NixOS
manual now applies to the manual PKI config as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The error message displays that a specific user doesn't exist in an
organisation, but uses the User object's name attribute to show which
user it was.
This is basically a very stupid chicken and egg problem and easily fixed
by using the user name provided on the command line.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We have already revamped the CLI subcommands in commit
e2383b84f8.
This was just an artifact that was left because of this.
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>
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>
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>
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 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>
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>
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>
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>
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>
