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>
I'm renaming the attribute name for uid, because the user name is called
"taskd" so we should really use the same name for it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Most of the desktop environments will spawn pulseaudio, but we can instead simply run it as a systemd service instead.
This patch also makes the system wide service run in foreground as recommended by the systemd projects and allows it to use sd_notify to signal ready instead of reading a pid written to a file. It is now also restarted on failure.
The user version has been tested with KDE and works fine there.
The system-wide version runs, but I haven't actually used it and upstream does not recommend running in this mode.
This patch makes dbus launch with any user session instead of
leaving it up to the desktop environment launch script to run it.
It has been tested with KDE, which simply uses the running daemon
instead of launching its own.
This is upstream's recommended way to run dbus.
This reverts commit 45c218f893.
Busybox's modprobe causes numerous "Unknown symbol" errors in the
kernel log, even though the modules do appear to load correctly.
NixOps has infrequent releases, so it's not the best place for keeping
the list of current AMIs. Putting them in Nixpkgs means that AMI
updates will be delivered as part of the NixOS channels.
We now generate a qcow2 image to prevent hitting Hydra's output size
limit. Also updated /root/user-data -> /etc/ec2-metadata/user-data.
http://hydra.nixos.org/build/33843133
This basic module allows you to specify the tmux configuration.
As great as tmux is, some of the defaults are pretty awful, so having a
way to specify the config really helps.
Systemd 229 sets kernel.core_pattern to "|/bin/false" by default,
unless systemd-coredump is enabled. Revert back to the default of
writing "core" in the current directory.
This reverts commit e8e8164f348a0e8655e1d50a7a404bdc62055f4e. I
misread the original commit as adding the "which" package, but it only
adds it to base.nix. So then the original motivation (making it work
in subshells) doesn't hold. Note that we already have some convenience
aliases that don't work in subshells either (such as "ll").
Previously, the cisco resolver was used on the theory that it would
provide the best user experience regardless of location. The downsides
of cisco are 1) logging; 2) missing supoprt for DNS security extensions.
The new upstream resolver is located in Holland, supports DNS security,
and *claims* to not log activity. For users outside of Europe, this will
mean reduced performance, but I believe it's a worthy tradeoff.
