The test has been broken for some time and the test errors are
non-obvious. None of the current maintainers know how to fix it so it is
better to get rid of it then to keep a continously failing test.
I was confused why I couldn't find a mention of udev.log_priority in
systemd-udevd.service(8). It turns out that it was renamed[1] to
udev.log_level. The old name is still accepted, but it'll avoid
further confusion if we use the new name in our documentation.
[1]: 64a3494c3d
The programs.ssh.knownHosts.*.publicKeyFile is broken, because it's
scoped to a set of host names, but to insert those host names on each
line of the file we'd have to parse out blank lines and comments, so
only the first line works. It would be much easier all round if users
just provided known hosts files in the normal format, and we pointed
ssh directly to them. This way, it would be possible to have multiple
keys for a single host (which is extremely common due to multiple
algorithms being commonplace).
We add an option for this instead of relying on extraConfig, because
we need to make sure /etc/ssh/ssh_known_hosts is always included to
ensure programs.ssh.knownHosts keeps working.
/etc/ssh/ssh_known_hosts2 is another OpenSSH default that seems a bit
weird, but there's no real reason to change that so we'll leave it.
The Intel SGX DCAP driver makes the SGX application enclave device and
the SGX provisioning enclave available below the path `/dev/sgx/`. Since
Linux 5.11, a derivation of the DCAP driver is part of the kernel and
available through the X86_SGX config option; NixOS enables this option
by default.
In contrast to the out-of-tree DCAP driver, the in-tree SGX driver uses
a flat hierarchy for the SGX devices resulting in the paths
`/dev/sgx_enclave` for the application enclave device and
`/dev/sgx_provison` for the provisioning enclave device.
As of this commit, even the latest version of the Intel SGX PSW
libraries still tries to open the (legacy) DCAP paths only. This means
that SGX software currently cannot find the required SGX devices even if
the system actually supports SGX through the in-tree driver. Intel wants
to change this behavior in an upcoming release of intel/linux-sgx.
Having said that, SGX software assuming the SGX devices below
`/dev/sgx/` will prevail. Therefore, this commit introduces the NixOS
configuration option `hardware.cpu.intel.sgx.enableDcapCompat` which
creates the necessary symlinks to support existing SGX software. The
option defaults to true as it is currently the only way to support SGX
software. Also, enabling the SGX AESM service enables the option.
The permissions of the devices `/dev/sgx_enclave` and
`/dev/sgx_provison` remain the same, i.e., are not affected regardless
of having the new option enabled or not.
This option makes the complete netdata configuration directory available for
modification. The default configuration is merged with changes
defined in the configDir option.
Co-authored-by: Michael Raitza <spacefrogg-github@meterriblecrew.net>
We take the idris2 projects version of the derivation. Originally,
Idris2 did not maintain their own nix derivation, so we created our
own. Now they maintain their own derivation, so we should try to
keep ours as close to theirs.
This change comes with the following differences:
* support files are in its own output, instead of packaged with idris2
- This makes it necessary to provide --package for contrib and network
!!! This is a breaking change !!!
* IDIRS2_PREFIX is set to ~/.idris2 instead of pointing to nix-store
- This makes --install work as expected for the user
* Properly set IDRIS2_PACKAGE_PATH
* non-linux platform uses chez-racket instead of chez
During working on #150837 I discovered that `google-oslogin` test
started failing, and so did some of my development machines. Turns out
it was because nscd doesn't start by default; rather it's wanted by
NSS lookup targets, which are not always fired up.
To quote from section on systemd.special(7) on `nss-user-lookup.target`:
> All services which provide parts of the user/group database should be
> ordered before this target, and pull it in.
Following this advice and comparing our unit to official `sssd.service`
unit (which is a similar service), we now pull NSS lookup targets from
the service, while starting it with `multi-user.target`.
This renames our `firmwareLinuxNonfree` package to `linux-firmware`.
There is prior art for this in multiple other distros[1][2][3].
Besides making the package more discoverable by those searching for the
usual name, this also brings it in-line with the `kebab-case` we
normally see in `nixpkgs` pnames, and removes the `Nonfree` information
from the name, which I consider redundant given it's present in
`meta.license`.
The corresponding alias has been added, so this shouldn't break
anything.
[1]: https://archlinux.org/packages/core/any/linux-firmware/
[2]: https://src.fedoraproject.org/rpms/linux-firmware
[3]: https://packages.gentoo.org/packages/sys-kernel/linux-firmware
This is a useful utility for monitoring network performance over time
using a combination of MTR and Prometheus. Also adding a service definition.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Previously we allocated subuids automatically for all normal users.
Make this explicitly configurable, so that one can use this for system
users too (or explicitly disable for normal users). Also don't allocate
automatically by default if a user already has ranges specified statically.
When startWhenNeeded is enabled, a brute force attack on sshd will cause
systemd to shut down the socket, locking out all SSH access to the machine.
Setting TriggerLimitIntervalSec to 0 disables this behavior.
a few things should've used buildPackages/nativeBuildInputs to not not require
the host architecture for building docs. tested by building aarch64-linux docs
on x86_64-linux, and the result looks good.
In https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/153
the user target names for GSD components has been renamed for example
from `gsd-a11y-settings.target` to `org.gnome.SettingsDaemon.A11ySettings.target`,
and nowadays `gsd-*.target` are just symbolic links of `/dev/null` and will be
removed in the future.
At the same time, as mentioned in d27212d466,
we are adding `systemd.user.targets.<name>.wants` stuff here only because
systemd.packages doesn't pick the .wants directories. Nowadays those GSD components
are managed in `/etc/systemd/user/gnome-session@gnome.target.d/gnome.session.conf`
so it should be safe to remove them.
In this commit we also try to pick up those new .wants directories, see also
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/41.0/plugins/meson.build#L57
Result of `cd /nix/store/iqzy2a6wn9bq9hqx7pqx0a153s5xlnwp-gnome-settings-daemon-41.0; find | grep wants`:
```
./share/systemd/user/gnome-session-x11-services-ready.target.wants
./share/systemd/user/gnome-session-x11-services-ready.target.wants/org.gnome.SettingsDaemon.XSettings.service
./share/systemd/user/gnome-session-x11-services.target.wants
./share/systemd/user/gnome-session-x11-services.target.wants/org.gnome.SettingsDaemon.XSettings.service
```
Result of `cd /nix/store/armzljlnsvc1gn0nq0bncb9lf8fy32zy-gnome-settings-daemon-3.34.0; find | grep wants`:
```
./lib/systemd/user/gnome-session-initialized.target.wants
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-a11y-settings.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-color.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-datetime.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-power.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-housekeeping.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-keyboard.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-media-keys.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-screensaver-proxy.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-sharing.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-sound.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-smartcard.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-wacom.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-print-notifications.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-rfkill.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-wwan.target
./lib/systemd/user/gnome-session-x11-services.target.wants
./lib/systemd/user/gnome-session-x11-services.target.wants/gsd-xsettings.target
```
This never configured where SNI should log to, as it's up to the user to
provide the full sniproxy config (which can be configured to log to a
file).
This option only produced a ExecStartPre script that created the folder.
Let's use LogsDirectory to create it. In case users want to use another
directory for logs, they can override LogsDirectory or set their own
ExecStartPre script.
This adds a very minimalistic (in terms of functionality and
dependencies) test for wlroots, Wayland, and related packages.
The Sway test covers more functionality and packages (e.g. XWayland) but
this test has tree advantages:
- Less dependencies: Much fewer rebuilds are required when testing core
changes that need to go through staging.
- Testing wlroots updates: The Sway package isn't immediately updated
after a new wlroots version is released and a lot of other packages
depend on wlroots as well.
- Determining whether a bug only affects Sway or wlroots/TinyWL as well.
since fc614c37c6 nixos needs access to its
own path (<nixpkgs/nixos>) to evaluate a system with documentation.
since documentation is enabled by default almost all systems need such
access, including the installer tests. nixos-install however does not
ensure that a channel exists in the target store before evaluating the
system in that store, which can lead to `path is not valid` errors.
The systemd syntax is suprising to me, but I suppose it's worth being
compatible as people might be sharing it with other modules.
Our regexp is lenient on IPv6 address part, so this is actually
backwards compatible (i.e. you can put the scope at either place).
