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>
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>
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>
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>
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>
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>
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>
- Enforce that an option declaration has a "defaultText" if and only if the
type of the option derives from "package", "packageSet" or "nixpkgsConfig"
and if a "default" attribute is defined.
- Enforce that the value of the "example" attribute is wrapped with "literalExample"
if the type of the option derives from "package", "packageSet" or "nixpkgsConfig".
- Warn if a "defaultText" is defined in an option declaration if the type of
the option does not derive from "package", "packageSet" or "nixpkgsConfig".
- Warn if no "type" is defined in an option declaration.
Updates gitlab to the current stable version and fixes a lot of features that
were broken, at least with the current version and our configuration.
Quite a lot of sweat and tears has gone into testing nearly all features and
reading/patching the Gitlab source as we're about to deploy gitlab for our
whole company.
Things to note:
* The gitlab config is now written as a nix attribute set and will be
converted to JSON. Gitlab uses YAML but JSON is a subset of YAML.
The `extraConfig` opition is also an attribute set that will be merged
with the default config. This way *all* Gitlab options are supported.
* Some paths like uploads and configs are hardcoded in rails (at least
after my study of the Gitlab source). This is why they are linked from
the Gitlab root to /run/gitlab and then linked to the configurable
`statePath`.
* Backup & restore should work out of the box from another Gitlab instance.
* gitlab-git-http-server has been replaced by gitlab-workhorse upstream.
Push & pull over HTTPS works perfectly. Communication to gitlab is done
over unix sockets. An HTTP server is required to proxy requests to
gitlab-workhorse over another unix socket at
`/run/gitlab/gitlab-workhorse.socket`.
* The user & group running gitlab are now configurable. These can even be
changed for live instances.
* The initial email address & password of the root user can be configured.
Fixes#8598.
We don't want to build all those things along with the manual, so that's
what the defaultText attribute is for.
Unfortunately a few of them were missing, so let's add them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts most of 89e983786a, as those references are sanitized now.
Fixes#10039, at least most of it.
The `sane` case wasn't fixed, as it calls a *function* in pkgs to get
the default value.
This is an improved version of original #12357.
For the purpose of generating docs, evaluate options with each derivation
in `pkgs` (recursively) replaced by a fake with path "\${pkgs.attribute.path}".
It isn't perfect, but it seems to cover a vast majority of use cases.
Caveat: even if the package is reached by a different means,
the path above will be shown and not e.g. `${config.services.foo.package}`.
As before, defaults created by `mkDefault` aren't displayed,
but documentation shouldn't (mostly) be a reason to use that anymore.
Note: t wouldn't be enough to just use `lib.mapAttrsRecursive`,
because derivations are also (special) attribute sets.
