More specifically, this removes services.pulseaudio and adds the option
hardware.pulseaudio.systemWide which defaults to false but can be used to turn
on the system-wide PulseAudio server (previously defined in
services.pulseaudio). Since the two PulseAudio modes are mutually exclusive
anyway (maybe not strictly true, but I don't think is a good idea combining
them) its nicer to be able to reuse server and ALSA configuration between them.
Also the system-wide PulseAudio service has been adjusted to systemd, and a few
things has been fixed (there was no alsa.conf before, for example).
The bottomline is that people that was using hardware.pulseaudio before should
be able to keep doing it in exactly the same way, and people that used
services.pulseaudio must switch over to hardware.pulseaudio.systemWide instead.
The smartd used to expect a list of devices to monitor. After this patch, it
expects a list of attribute sets, which may have two attributes:
- device: path to the device (required)
- options: smartd options to apply to this particular device (optional)
A concrete example configuration would be:
services.smartd = {
enable = true;
devices = [ { device = "/dev/sda"; } { device = "/dev/sdb"; options = "-d sat"; } ];
};
Furthermore, the config option 'deviceOpts' can be used to configure options
that are applied to *every* device.
Enable it with
services.transmission.enable = true;
and optionally configure it
services.transmission.settings =
{
download-dir = "/srv/torrents/";
incomplete-dir = "/srv/torrents/.incomplete/";
incomplete-dir-enabled = true;
rpc-whitelist = "127.0.0.1,192.168.*.*";
# for users in group "transmission" to have access to torrents
umask = 2;
};
The above settings are written/merged into settings.json each time the
service is about to start.
Newer kernels (since torvalds/linux@abb139e75c) try to
read firmware directly from the filesystem before falling back to a
userspace helper (udev) if firmware cannot be found (in even newer
kernels, the fallback path can be disabled altogether). By default, only
certain paths in /lib/firmware* are searched, so this was initially not
helpful for NixOS.
Since torvalds/linux@2760284206 (which,
based on the commit message, was implemented just for NixOS, go us!),
though, an extra path can be dynamically prepended to the search path.
So do that, in three ways:
1. Pass a kernel command line option in case the module is built-in
2. Add a line to modprobe.conf in case the module isn't yet loaded by
activation-time
3. Add an activation script to set the option in /sys in case the module
is already loaded by activation-time.
xf86videovmware[1].
Adds "vmware" to list of default options of
services.xerver.videoDrivers.
new default:
[ "ati" "cirrus" "intel" "vesa" "vmware" ]
old default:
[ "ati" "cirrus" "intel" "vesa" ]
[1] Pull request for xf86videovmware found at
https://github.com/NixOS/nixpkgs/pull/338.
The mongodb service runs as user mongodb, and therefore
the preStart-script has no permissions to set up mongodb
directories. This is solved by adding an initialisation
service that runs as root and just sets up the required
directories.
This reverts commit 683100666d.
Seems somebody (systemd? the kernel?) gets confused at power
events and remounts the filesystem containing /nix/store as
read-only.
This is necessary to prevent a race. Udev 197 has a new naming scheme
for network devices, so it will rename (say) eth0 to eno0. This fails
with "error changing net interface name eth0 to eno1: Device or
resource busy" if another process has opened the interface in the
meantime.
This reverts commit 1e741f1572b6793b861e2f9820015475ce339ae0 as it is
unnecessary according to @edolstra, because services.xserver.config from another
module will be merged into the configuration.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is currently only a very simple implementation which just recurses a list
of heads that get chained together to the right of the corresponding previous
item of the list.
If I forgot about something in the already existing configuration options,
please let me know or if this commit is useless or a duplicate, feel free to
revert. But by looking at implementation before this commit, I only see zaphod
and/or quirky xinerama-like configuration options.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is especially useful if you want to supply a default XRandR configuration,
where you need multiple "Monitor" sections in order to set properties for
specific CRTCs (if not running in zaphod mode).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
To be honest, it's more like "be less discriminating against USB tablets".
USB tablets usually get autodetected, device name is not necessary and defaulting to a serial touchscreen is a clear discrimination.
Unconditionally remapping buttons is generally not a good idea either.
Old defaults transformed into examples.
During a configuration switch, changed units are stopped in the old
configuration, then started in the new configuration (i.e. after
running the activation script and running "systemctl daemon-reload").
This ensures that services are stopped using the ExecStop/ExecStopPost
commands from the old configuration.
However, for some services it's undesirable to stop them; in
particular dhcpcd, which deconfigures its network interfaces when it
stops. This is dangerous when doing remote upgrades - usually things
go right (especially because the switch script ignores SIGHUP), but
not always (see 9aa69885f0). Likewise,
sshd should be kept running for as long as possible to prevent a
lock-out if the switch fails.
So the new option ‘stopIfChanged = false’ causes "systemctl restart"
to be used instead of "systemctl stop" followed by "systemctl start".
This is only proper for services that don't have stop commands. (And
it might not handle dependencies properly in some cases, but I'm not
sure.)
Running it from systemd rather than cron has several advantages:
systemd ensures that only one instance runs at a time; the GC can be
manually started/stopped; and logging goes to the journal.
We still need cron to start the service at the right time, but
hopefully soon we can get rid of cron entirely (once systemd supports
starting a unit at a specific time).
