Previously, the value from stdenv.platform.kernelDTB was used. That
doesn't work well if both kinds (DTB and non-DTB) of generations exist
in the system profile.
The shairport-sync service currently fails to start with the error
shairport avahi_entry_group_new failed
This problem seems to have been introduced by
cdd7310a50
After some trial and error I concluded that the attached commit is a minimal
fix.
Currently NixOS creates the swapfile (with the specified size) only if
it doesn't already exist. Changing the swapfile size afterwards will not
have any effect.
This commit changes that so the swapfile will be recreated whenever
swapDevices.*.size is changed (or more precisely, whenever the actual
file size differs from the configured one), allowing both growing and
shrinking the swapfile.
The service unit has "restartIfChanged = false", so we don't have to
worry about the swapfile being in use at the time this code is run (you
have to reboot for swapfile changes).
fallocate doesn't shrink files, use truncate for that. truncate can also
be used to grow files, but it creates "holes" in the file which doesn't
work with swapfiles.
':' is currently used as separator in /boot/grub/state for the list of
devices GRUB should be installed to. The problem is that ':' itself may
appear in a device path:
/dev/disk/by-id/usb-SanDisk_Cruzer_20043512300546C0B317-0:0
With such a path, NixOS will install GRUB *every* time, because it
thinks the configuration differs from the state file (due to the wrong
list split). Fix it by using ',' as separator.
For existing systems with GRUB installed on multiple devices, this
change means that GRUB will be installed one extra time.
- init gnome-software for gnome3 at 3.18.3
- list gnome-software as an "optional package" for gnome3
- enable packagekit service when gnome3 is enabled
- currently pulled in from Git until the next release of PackageKit
has Nix support
- also: add in a service module to start packagekit properly
- nixos service can be enabled via services.packagekit.enable
- packagekit requires nixunstable to build properly
Fixup regression introduced in commit 1bbcd91b2e
("spacefm: sudo and gksu fixes #15758 and license update").
A missing </filename> end tag caused this:
$ nixos-rebuild build
...
options-db.xml:4402: parser error : Opening and ending tag mismatch: filename line 4401 and para
</para><para><emphasis>Type:</emphasis> boolean</para><para><emphasis>Default:</
^
options-db.xml:4406: parser error : Opening and ending tag mismatch: filename line 4401 and listitem
</filename></member></simplelist></listitem></varlistentry><varliste
^
options-db.xml:4406: parser error : Opening and ending tag mismatch: para line 4401 and varlistentry
</filename></member></simplelist></listitem></varlistentry><varliste
^
options-db.xml:28430: parser error : Opening and ending tag mismatch: listitem line 4401 and variablelist
</filename></member></simplelist></listitem></varlistentry></variablelist
^
options-db.xml:28432: parser error : Premature end of data in tag varlistentry line 4401
- RPi3 successfully gets to U-Boot, but then fails to boot the kernel
due to a missing device tree file. This should get added to the 4.8
kernel release once this patch is merged: https://lkml.org/lkml/2016/6/1/841
- RPi2 is not tested, but it should successfully boot the NixOS image.
Instead of showing this output from "nixos-rebuild switch":
warning: not applying GID change of group ‘munin’
warning: not applying UID change of user ‘ntp’
print this:
warning: not applying GID change of group ‘munin’ (95 -> 102)
warning: not applying UID change of user ‘ntp’ (3 -> 179)
This makes it possible for users to take action and fixup the UIDs/GIDs
that NixOS won't touch.
Fixes issue when upgrading from very old NixOS systems that don't have
systemd-escape in $PATH:
$ sudo nixos-rebuild switch
...
building the system configuration...
updating GRUB 2 menu...
Can't exec "systemd-escape": No such file or directory at /nix/var/nix/profiles/system/bin/switch-to-configuration line 264.
Unable to escape /!
Fixes this (line wrapped):
$ gnome-control-center
[... click on the "Color" item ...]
(gnome-control-center:3977): color-cc-panel-WARNING **: \
The name org.freedesktop.ColorManager was not provided by any .service files
With this patch applied, the above warnings are not printed and the GUI
shows some devices that can be managed (my printer and display). Without
this patch the GUI is empty (non-functional).
(cups will also complain in the journal with a similar message when
doing print jobs, without this patch.)
The docstring for the `services.dbus.packages` configuration option only
mentioned one directory, but the implementation actually looked for DBus
config files in four separate places within the target packages. This
commit updates the docstring to reflect the actual implementation
behaviour.
stripHash uses a global variable to communicate it's computation
results, but it's not necessary. You can just pipe to stdout in a
subshell. A function mostly behaves like just another command.
baseHash() also introduces a suffix-stripping capability since it's
something the users of the function tend to use.
...by adding system-config-printer to services.dbus.packages (if
services.printing.enable is true).
Without this patch, trying to add a printer will result in a little dialog
saying "Failed to add new printer" and gnome-control-center will print this to
the terminal (line wrapped):
(gnome-control-center:3546): printers-cc-panel-WARNING **: \
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: \
The name org.fedoraproject.Config.Printing was not provided by any .service files
system-config-printer supplies the "org.fedoraproject.Config.Printing" dbus
service, thus fixing the problem.
The tests need to expand passed variable and very carefully.
I could see no other easy way than to change single-quoting in
makeWrapper to double-quoting.
The tests now fail with the same problem as on master...
wpa_supplicant fails to start if the wireless interfaces aren't ready yet,
so we need to add a system ordering directive here to start wpa_supplicant
after the interfaces are ready. Note that Requires= is not enough since
it does not imply ordering.
I've failed to figure out what why `paxtest blackhat` hangs the vm, and
have resigned to running individual `paxtest` programs. This provides
limited coverage, but at least verifies that some important features are
in fact working.
Ideas for future work includes a subtest for basic desktop
functionality.
This GID was used to exempt users from Grsecurity's
`/proc` restrictions; we now prefer to rely on
`security.hideProcessInformation`, which uses the `proc` group
for this purpose. That leaves no use for the grsecurity GID.
More generally, having only a single GID to, presumably, serve as the
default for all of grsecurity's GID based exemption/resriction schemes
would be problematic in any event, so if we decide to enable those
grsecurity features in the future, more specific GIDs should be added.
The new module is specifically adapted to the NixOS Grsecurity/PaX
kernel. The module declares the required kernel configurations and
so *should* be somewhat compatible with custom Grsecurity kernels.
The module exposes only a limited number of options, minimising the need
for user intervention beyond enabling the module. For experts,
Grsecurity/PaX behavior may be configured via `boot.kernelParams` and
`boot.kernel.sysctl`.
The module assumes the user knows what she's doing (esp. if she decides
to modify configuration values not directly exposed by the module).
Administration of Grsecurity's role based access control system is yet
to be implemented.
We need to use wrapped modprobe, so that it finds the right
modules. Docker needs modprobe to load overlay kernel module
for example.
This fixes an an error starting docker if the booted system's kernel
version is different from the /run/current-system profile's one.
The update-resolve-conf script from the update-resolv-conf
package is very useful and should work in most of the common
cases, so this adds an option to enable it. The option is
disabled by default for backwards compatibility.
So far the module only allowed for the ccid driver, but there are a lot
of other PCSC driver modules out there, so let's add an option called
"plugins", which boils down to a store path that links together all the
paths specified.
We don't need to create stuff in /var/lib/pcsc anymore, because we
patched pcsclite to allow setting PCSCLITE_HP_DROPDIR.
Another new option is readerConfig, which is especially useful for
non-USB readers that aren't autodetected.
The systemd service now is no longer Type=forking, because we're now
passing the -f (foreground) option to pcscd.
Tested against a YubiKey 4, SCR335 and a REINER SCT USB reader.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @wkennington
This was originally removed in d4d0e449d7.
The intent was not to maintain hydra expression at two places.
Nowadays we have enough devs to maintain this despite copy/pasta.
This should encourage more people to use Hydra, which is a really
great piece of software together with Nix.
Tested a deploy using https://github.com/peti/hydra-tutorial
IceWM is not part of KDE 5 and is now no longer part of the test. KDE 5
applications: Dolphin, System Monitor, and System Settings are started
in this test.
* manual: Mark commands that require root
Mark every command that requires to be run as root by prefixing them
with '#' instead of '$'.
* manual: Add note about commands that require root
Since systemd version 230, it is required to have a machine-id file
prior to the startup of the container. If the file is empty, a transient
machine ID is generated by systemd-nspawn.
See systemd/systemd#3014 for more details on the matter.
This unbreaks all of the containers-* NixOS tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
Closes: #15808
When displaying a warning about a removed Option we should always
include reasoning why it was removed and how to get the same
functionality without it.
Introduces such a description argument and patches occurences (mostly
with an empty string).
startGnuPGAgent: further notes on replacement
The primary motivation here is to get rid of builderDefs, but now the
resulting font directory is also linked into /run/current-system/sw,
which fixes #15194.
VBoxService needs dbus in order to work properly, which failed to start
up so far, because it was searching in /run/current-system/sw for its
configuration files.
We now no longer run with the --system flag but specify the
configuration file directly instead.
This fixes at least the "simple-gui" test and probably the others as
well, which I haven't tested yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We can't use waitForWindow here because it runs xwininfo as user root,
who in turn is not authorized to connect to the X server running as
alice.
So instead, we use xprop from user alice which should fix waiting for
the VirtualBox manager window.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The existence of $root/var/lib/private/host-notify as a socket
prevented a bind mount:
container foo[8083]: Failed to create mount point /var/lib/containers/foo/var/lib/private/host-notify: No such device or address
The VirtualBox tests so far ran the X server as root instead of user
"alice" and it did work, because we had access control turned off by
default.
Fortunately, it was changed in 1541fa351b.
As a side effect, it caused all the VirtualBox tests to fail because
they now can't connect to the X server, which is a good thing because
it's a bug of the VirtualBox tests.
So to fix it, let's just start the X server as user alice.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by d84741a4bf.
The mentioned commit actually is a good thing, because we now get the
output from the X session.
Unfortunately, for the i3wm test, the i3-config-wizard prints out the
raw keyboard symbols directly coming from xcb, so the output isn't
necessarily proper UTF-8.
As the XML::Writer already expects valid UTF-8 input, we assume that
everything that comes into sanitise() will be UTF-8 from the start. So
we just decode() it using FB_DEFAULT as the check argument so that
every invalid character is replaced by the unicode replacement
character:
https://en.wikipedia.org/wiki/Specials_(Unicode_block)#Replacement_character
We simply re-oncode it again afterwards and return it, so we should
always get out valid UTF-8 in the log XML.
For more information about FB_DEFAULT and FB_CROAK, have a look at:
http://search.cpan.org/~dankogai/Encode-2.84/Encode.pm#Handling_Malformed_Data
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This allows setting options for the same LUKS device in different
modules. For example, the auto-generated hardware-configuration.nix
can contain
boot.initrd.luks.devices.crypted.device = "/dev/disk/...";
while configuration.nix can add
boot.initrd.luks.devices.crypted.allowDiscards = true;
Also updated the examples/docs to use /disk/disk/by-uuid instead of
/dev/sda, since we shouldn't promote the use of the latter.
... rather than ~/.xsession-errors. It might make sense to make this
the default, in order to eliminate ad hoc, uncentralised, poorly
discoverable log files.
This ensures that "journalctl -u display-manager" does what you would
expect in 2016. However, the main reason is to ensure that our VM
tests show the output of the X server.
A slight problem is that with KDE user switching, messages from the
various X servers end up in the same place. However, that's an
improvement over the previous situation, where the second X server
would overwrite the /var/log/X.0.log of the first. (This was caused by
the fact that we were passing a hard-coded value for -logfile.)
For now, leave the old implementation under `man-old` attribute.
Small warning: I had a leftover ~/.nix-profile/man from an old package,
which caused man-db's man prefer it and ignore ~/.nix-profile/share/man.
The PATH->MANPATH code just selects the first match for each PATH item.
The motivation is using sudo in chroot nix builds, a somewhat
special edge case I have and pulling system path into chroot
yields to some very nasty bug like
https://github.com/NixOS/nixpkgs/issues/15581
Previously:
$ cat /var/setuid-wrappers/sudo.real
/nix/store/3sm04dzh0994r86xqxy52jjc0lqnkn65-system-path/bin/sudo
After the change:
$ cat /var/setuid-wrappers/sudo.real
/nix/store/4g9sxbzy8maxf1v217ikp69c0c3q12as-sudo-1.8.15/bin/sudo
This reverts commit c25907d072.
I think this commit broke the NixOS service for NetworkManager. At least
with this, and the two previous reverts, everything is back to normal.
(With multiple-outputs split, it would have reduced the closure size by
3 MiB.)
This reverts commit 7ac1ef05fa.
One of a few reverts needed to unbreak networkmanager NixOS service
since the multiple-output split (to save 3 MiB of closure size).
This reverts commit 2875293615.
One of a few reverts needed to unbreak networkmanager NixOS service
since the multiple-output split (to save 3 MiB of closure size).
Move Subsonic state directory from `/var/subsonic` to
`/var/lib/subsonic`, since the general convention is for each
application to put its state directory there.
Also, automatically set the home directory of the `subsonic` user to the
value of `config.services.subsonic.home`, rather than setting it to a
value hardcoded in the module. This keeps the home directory of the
`subsonic` user and the state directory for the Subsonic application in
sync.
leveraging users.users.<user>.createHome instead of a preStart script.
preStart script is still required to ensure proper creation of logging
directory.
This properly implements revert in
0729f60697.
We used to have which='type -P' alias, but really it's best to just
rely on which package, only 88K in size.
cc @edolstra
The chroot caps restriction disallows chroot'ed processes from running
any command that requires `CAP_SYS_ADMIN`, breaking `nixos-rebuild`. See
e.g., https://github.com/NixOS/nixpkgs/issues/15293
This significantly weakens chroot protections, but to break
nixos-rebuild out of the box is too severe.
The list of public proxies is updated now and again and it's probably a
good idea to always work from the most recent list, rather than the one
that is shipped with the release. This can be crucial in case of
resolvers that are revealed to have gone rogue or otherwise have been
compromised.
As @edolstra pointed out that the kernel module might be painful to
maintain. I strongly disagree because it's only a small module and it's
good to have such a canary in the tests no matter how the bootup process
looks like, so I'm going the masochistic route and try to maintain it.
If it *really* becomes too much maintenance burden, we can still drop or
disable kcanary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We don't want to push out a channel update whenever this test fails,
because that might have unexpected and confused side effects and it
*really* means that stage 1 of our boot up is broken.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We already have a small regression test for #15226 within the swraid
installer test. Unfortunately, we only check there whether the md
kthread got signalled but not whether other rampaging processes are
still alive that *should* have been killed.
So in order to do this we provide multiple canary processes which are
checked after the system has booted up:
* canary1: It's a simple forking daemon which just sleeps until it's
going to be killed. Of course we expect this process to not
be alive anymore after boot up.
* canary2: Similar to canary1, but tries to mimick a kthread to make
sure that it's going to be properly killed at the end of
stage 1.
* canary3: Like canary2, but this time using a @ in front of its
command name to actually prevent it from being killed.
* kcanary: This one is a real kthread and it runs until killed, which
shouldn't be the case.
Tested with and without 67223ee and everything works as expected, at
least on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is a regression test for #15226, so that the test will fail once we
accidentally kill one or more of the md kthreads (aka: if safe mode is
enabled).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Unfortunately, pkill doesn't distinguish between kernel and user space
processes, so we need to make sure we don't accidentally kill kernel
threads.
Normally, a kernel thread ignores all signals, but there are a few that
do. A quick grep on the kernel source tree (as of kernel 4.6.0) shows
the following source files which use allow_signal():
drivers/isdn/mISDN/l1oip_core.c
drivers/md/md.c
drivers/misc/mic/cosm/cosm_scif_server.c
drivers/misc/mic/cosm_client/cosm_scif_client.c
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
drivers/staging/rtl8188eu/core/rtw_cmd.c
drivers/staging/rtl8712/rtl8712_cmd.c
drivers/target/iscsi/iscsi_target.c
drivers/target/iscsi/iscsi_target_login.c
drivers/target/iscsi/iscsi_target_nego.c
drivers/usb/atm/usbatm.c
drivers/usb/gadget/function/f_mass_storage.c
fs/jffs2/background.c
fs/lockd/clntlock.c
fs/lockd/svc.c
fs/nfs/nfs4state.c
fs/nfsd/nfssvc.c
While not all of these are necessarily kthreads and some functionality
may still be unimpeded, it's still quite harmful and can cause
unexpected side-effects, especially because some of these kthreads are
storage-related (which we obviously don't want to kill during bootup).
During discussion at #15226, @dezgeg suggested the following
implementation:
for pid in $(pgrep -v -f '@'); do
if [ "$(cat /proc/$pid/cmdline)" != "" ]; then
kill -9 "$pid"
fi
done
This has a few downsides:
* User space processes which use an empty string in their command line
won't be killed.
* It results in errors during bootup because some shell-related
processes are already terminated (maybe it's pgrep itself, haven't
checked).
* The @ is searched within the full command line, not just at the
beginning of the string. Of course, we already had this until now, so
it's not a problem of his implementation.
I posted an alternative implementation which doesn't suffer from the
first point, but even that one wasn't sufficient:
for pid in $(pgrep -v -f '^@'); do
readlink "/proc/$pid/exe" &> /dev/null || continue
echo "$pid"
done | xargs kill -9
This one spawns a subshell, which would be included in the processes to
kill and actually kills itself during the process.
So what we have now is even checking whether the shell process itself is
in the list to kill and avoids killing it just to be sure.
Also, we don't spawn a subshell anymore and use /proc/$pid/exe to
distinguish between user space and kernel processes like in the comments
of the following StackOverflow answer:
http://stackoverflow.com/a/12231039
We don't need to take care of terminating processes, because what we
actually want IS to terminate the processes.
The only point where this (and any previous) approach falls short if we
have processes that act like fork bombs, because they might spawn
additional processes between the pgrep and the killing. We can only
address this with process/control groups and this still won't save us
because the root user can escape from that as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #15226
Instead of using this option, please modify the dovecot package by means of an
override. For example:
nixpkgs.config.packageOverrides = super: {
dovecot = super.dovecot.override { withPgSQL = true; };
};
Closes https://github.com/NixOS/nixpkgs/issues/14097.
Just removing the system argument because it doesn't exist (it's
actually config.nixpkgs.system, which we're already using). We won't get
an error anyway if we're not actually using it, so this is just an
aesthetics fix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Make sure that we always have everything available within the store of
the VM, so let's evaluate/build the test container fully on the host
system and propagate all dependencies to the VM.
This way, even if there are additional default dependencies that come
with containers in the future we should be on the safe side as these
dependencies should now be included for the test as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @kampfschlaefer, @edolstra
This partially reverts f2d24b9840.
Instead of disabling the channels via removing the channel mapping from
the tests themselves, let's just explicitly reference the stable test in
release.nix. That way it's still possible to run the beta and dev tests
via something like "nix-build nixos/tests/chromium.nix -A beta" and
achieve the same effect of not building beta and dev versions on Hydra.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not the job of Nixpkgs to distribute beta versions of upstream
packages. More importantly, building these delays channel updates by
several hours, which is bad for our security fix turnaround time.
* Perform HTTP HEAD request instead of full GET (lighter weight)
* Don't log output of curl to the journal (it's noise/debug)
* Use explicit http:// URL scheme
* Reduce poll interval from 10s to 2s (respond to state changes
quicker). Probably not relevant on boot (lots of services compete for
the CPU), but online service restarts/reloads should be quicker.
* Pass --fail to curl (should be more robust against false positives)
* Use 4 space indent for shell code.
The current postStart code holds Jenkins off the "started" state until
Jenkins becomes idle. But it should be enough to wait until Jenkins
start handling HTTP requests to consider it "started".
More reasons why the current approach is bad and we should remove it,
from @coreyoconnor in
https://github.com/NixOS/nixpkgs/issues/14991#issuecomment-216572571:
1. Repeatedly curling for a specific human-readable string to
determine "Active" is fragile. For instance, what happens when jenkins
is localized?
2. The time jenkins takes to initializes is variable. This (at least
used to) depend on the number of jobs and any plugin upgrades requested.
3. Jenkins can be requested to restart from the UI. Which will not
affect the status of the service. This means that the service being
"active" does not imply jenkins is initialized. Downstream services
cannot assume jenkins is initialized if the service is active. Might
as well accept that and remove the initialized test from service
startup.
Fixes #14991.
Regression introduced by dfe608c8a2.
The commit turns the two arguments into one attrset argument so we need
to adapt that to use the new calling convention.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This allows to use <olink> tags inside NixOS options to reference
sections from the manual. I've originally introduced it in #14476 to
reference the Taskserver specific documentation from the options
reference but as suggested by @nbp, this was done as a separate pull
request to ensure greater visibility rather than being "hidden" in the
Taskserver branch.
The build time for the manual is around 30s on my machine without this
change and 34s with this change, so it shouldn't have a very big impact
on the build time of the manual.
Olinks between the options reference and the manual now will look like
this:
"More instructions about NixOS in conjuction with Taskserver can be
found in the NixOS manual at Chapter 15, Taskserver."
More documentation about olinks can be found here:
http://www.sagehill.net/docbookxsl/Olinking.html
Acked-by: Eelco Dolstra <eelco.dolstra@logicblox.com>
A sane backend for recent brother scanners.
Depends on the presence of etc files generated by the
nixos module of the same name.
Supports network scanner specification through the
nixos module.
The Nix store squashfs is stored inside the initrd instead of separately
(cherry picked from commit 976fd407796877b538c470d3a5253ad3e1f7bc68)
Signed-off-by: Domen Kožar <domen@dev.si>
A user noticed the example for `hosts`, took the `mode` permissions literally, and ended up with surprising behavior on their system. Updating the documentation to not reference a real config file which might have real permissions requirements.
The pre-sleep service exits if any command fails. Unloading facetimehd
without it being loaded blocks subsequent commands from running.
Note: `modprobe -r` works a bit better when unloading unused modules,
and is preferrable to `rmmod`. However, the facetimehd module does not
support suspending. In this case, it seems preferable to forcefully
unload the module. `modprobe` does not support a `--force` flag when
removing, so we are left with `rmmod`.
See:
- https://github.com/NixOS/nixpkgs/pull/14883
- https://github.com/patjak/bcwc_pcie/wiki#known-issues
Basic hardening
- Run as nobody:nogroup with a private /tmp, /home & /run/user
- Create working directory under /run (hoogle insists on writing to cwd
and otherwise returns "something went wrong" to every query)
Option tweaks
- Provide a default for the haskellPackage option
- Set text values for defaults
- Move hoogleEnv to the top-level & simplify it
This command was useful when NixOS was spread across multiple
repositories, but now it's pretty pointless (and obfuscates what
happens, i.e. "git clone git://github.com/NixOS/nixpkgs.git").
Note: I ignored the C++ libraries, but it appears we're not currently
using them. Once we do, we'll probably want to put them in a separate
output as well (to prevent non-C++ users from depending on Boost).
Two fixes:
Not really sure why removing `--fail` from the curl calls is necessary,
but with that option, curl erronously reports 404 (which it shouldn't
per my interactive vm testing).
Fix paths to example files used for the printing test
Toghether, these changes allow the test to run to completion on my machine.
Need to pass `cups.out` to `systemd.packages`, lest we end up with an invalid
generated unit containing only directives set in the service module.
This patch gives us a valid cups.service unit but, vexingly, does not fix the
test failure at NixOS/nixpkgs#14748
`dbus-launch` is executed early in the script, before desktop managers
had a chance to setup the environment. If DBus activation is used,
applications launched by this may therefore lack necessary environment
variables. This patch sends the complete environment to DBus after
launching the desktop manager.
With the merge of the closure-size branch, most packages now have
multiple outputs. One of these packages is gnutls, so previously
everything that we needed was to reference "${gnutls}/bin/..." and now
we need to use "${gnutls.bin}/bin/...".
So it's not a very big issue to fix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This adds a Taskserver module along with documentation and a small
helper tool which eases managing a custom CA along with Taskserver
organisations, users and groups.
Taskserver is the server component of Taskwarrior, a TODO list
application for the command line.
The work has been started by @matthiasbeyer back in mid 2015 and I have
continued to work on it recently, so this merge contains commits from
both of us.
Thanks particularly to @nbp and @matthiasbeyer for reviewing and
suggesting improvements.
I've tested this with the new test (nixos/tests/taskserver.nix) this
branch adds and it fails because of the changes introduced by the
closure-size branch, so we need to do additional work on base of this.
This reverts commit 1d77dcaed3.
It will be reintroduced along with #14700 as a separate branch, as
suggested by @nbp.
I added this to this branch because I thought it was a necessary
dependency, but it turns out that the build of the manual/manpages still
succeeds and merely prints a warning like this:
warning: failed to load external entity "olinkdb.xml"
Olink error: could not open target database 'olinkdb.xml'.
Error: unresolved olink: targetdoc/targetptr = 'manual/module-taskserver'.
The olink itself will be replaced by "???", so users looking at the
description of the option in question will still see the reference to
the NixOS manual, like this:
More instructions about NixOS in conjuction with Taskserver can be found
in the NixOS manual at ???.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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
Suggested by @nbp:
"Choose a better organization name in this example, such that it is less
confusing. Maybe something like my-company"
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It was failing with a `Read-only filesystem` failure due to the systemd
service option `ReadWriteDirectories` not being correctly configured.
Fixes #14132
Continuation of 79c3c16dcb. Systemd 229
sets the default RLIMIT_CORE to infinity, causing systems to be
littered with core dumps when systemd.coredump.enable is disabled.
This restores the 15.09 soft limit of 0 and hard limit of infinity.
This module adds support for defining a flexget service.
Due to flexget insisting on being able to write all over where it finds
its configuration file, we use a ExecStartPre hook to copy the generated
configuration file into place under the user's home. It's fairly ugly
and I'm very open to suggestions
Coreutils is multi-output and the `info` output doesn't seem to be
included on the install disk, failing like this (because now nix-env
wants to build coreutils):
````
machine# these derivations will be built:
machine# /nix/store/0jk4wzg11sa6cqyw8g7w5lb35axji969-bison-3.0.4.tar.gz.drv
...
machine# /nix/store/ybjgqwxx63l8cj1s7b8axx09wz06kxbv-coreutils-8.25.drv
machine# building path(s) ‘/nix/store/4xvdi5740vq8vlsi48lik3saz0v5jsx0-coreutils-8.25.tar.xz’
machine# downloading ‘http://ftpmirror.gnu.org/coreutils/coreutils-8.25.tar.xz’...
machine# error: unable to download ‘http://ftpmirror.gnu.org/coreutils/coreutils-8.25.tar.xz’: Couldn't resolve host name (6)
machine# builder for ‘/nix/store/5j3bc5sjr6271fnjh9gk9hrid8kgbpx3-coreutils-8.25.tar.xz.drv’ failed with exit code 1
machine# cannot build derivation ‘/nix/store/ybjgqwxx63l8cj1s7b8axx09wz06kxbv-coreutils-8.25.drv’: 1 dependencies couldn't be built
machine# error: build of ‘/nix/store/ybjgqwxx63l8cj1s7b8axx09wz06kxbv-coreutils-8.25.drv’ failed
````
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>
The options client.allow and client.deny are gone since the commit
8b793d1916, so let's fix that.
No feature changes, only fixes the descriptions of allowedClientIDs and
disallowedClientIDs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is the recommended way for long-running services and ensures that
Taskserver will keep running until it has been stopped manually.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
Commit 98d9bba introduced this option as a nullOr type and it actually
checks whether null has been set and only appends -dpi if that's the
case. So let's actually set the default to null instead of 0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This module adds an option `security.hideProcessInformation` that, when
enabled, restricts access to process information such as command-line
arguments to the process owner. The module adds a static group "proc"
whose members are exempt from process information hiding.
Ideally, this feature would be implemented by simply adding the
appropriate mount options to `fileSystems."/proc".fsOptions`, but this
was found to not work in vmtests. To ensure that process information
hiding is enforced, we use a systemd service unit that remounts `/proc`
after `systemd-remount-fs.service` has completed.
To verify the correctness of the feature, simple tests were added to
nixos/tests/misc: the test ensures that unprivileged users cannot see
process information owned by another user, while members of "proc" CAN.
Thanks to @abbradar for feedback and suggestions.
At some point we probably want to replace this with a curated list
of configurations or even an upstreamed repository of examples, but
for now this is just noise.
Fixes NixOS/nixpkgs#14522
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>
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>
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>
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>
The option authzldapauthoritative had been removed in 2.4
I pushed this into 16.03 instead of master first. My fault.
(cherry picked from commit 516f47efef)
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>
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>
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>
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>
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>
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>
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>
