I'm unable to provide reasonable support for grsecurity on the 16.03 release
branch. Mark as broken to more accurately reflect the current state of
affairs. Also disable the grsecurity test.
If sombody wishes to maintain grsecurity on 16.03, please revert this commit.
Closes https://github.com/NixOS/nixpkgs/issues/17061
ecryptfs: add nixos/tests/ecryptfs.nix
(cherry picked from commit ab6fc29719)
ecryptfs: test bug from #16766
(cherry picked from commit d781bf94c1)
ecryptfs: add test to release (#16910)
Would have caught regression #16766
(cherry picked from commit f76a8fbbac)
ecryptfs: add test to release-combined.nix
(cherry picked from commit de80d0544c)
A disabled systemd service with a "startAt" attribute, like this:
systemd.services.foo-service = {
enable = false;
startAt = "*-*-* 05:15:00";
...
};
will cause the following errors in the system journal:
systemd[1]: foo-service.timer: Refusing to start, unit to trigger not loaded.
systemd[1]: Failed to start foo-service.timer.
Fix it by not generating the corresponding timer unit when the service
is disabled.
(cherry picked from commit 2eb8aab42c)
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.
(cherry picked from commit b30852ed41)
':' 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.
(cherry picked from commit aeb516c741)
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 /!
(cherry picked from commit 9050077cff)
The ddclient daemon requires that the configuration file is only
accessible by the ddclient user. This since it typically contains login
information.
(cherry picked from commit 9f4775dbb5)
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.
(cherry picked from commit 5f3c4bd11e)
This fixed a problem I had when running ElasticSearch in an LXC
container, and it doesn't hurt using a dedicated group instead of
nogroup anyway.
(cherry picked from commit 9facb7078b)
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.
(cherry picked from commit 6e528893a8)
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.)
(cherry picked from commit 66ee7a4c46)
(cherry picked from commit 4e58b33dee)
[Bjørn: Add ./services/x11/colord.nix to module-list.nix, was missing in
the above commit. (It was added as part of 776845bbeb
("xiccd: init at 0.2.2") though.)
]
...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.
(cherry picked from commit a156a8ab1a)
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
(cherry picked from commit b37d6d8996)
This command is racy because it will return a non-zero exit code if
the array is already clean. This caused numerous random failures. It
should be unnecessary anyway. (Maybe in the past we needed this
because of #15226.)
http://hydra.nixos.org/job/nixos/release-16.03/nixos.tests.installer.swraid.i686-linux
(cherry picked from commit 3e7b510281)
Signed-off-by: Domen Kožar <domen@dev.si>
iproute is required for blocking via null routes; without it, rules
based on routes.conf will fail.
Closes#15638
(cherry picked from commit 77028b1e8d)
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
When enableRootTrustAnchor is set to false, there is really no point in
initializing the root key before starting unbound.
Fixes#15605.
(cherry picked from commit bf0e745597)
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.
(cherry picked from commit d4d7bfe07b)
Requirement without ordering implies parallel execution; it is crucial
that sysctl tunables are finalized before the lock is engaged, however.
(cherry picked from commit 60a27781d6)
