If `services.tor.client.enable` is set to false (the default), the `SOCKSPort` option is not added to the torrc file but since Tor defaults to listening on port 9050 when the option is not specified, the tor client is not actually disabled. To fix this, simply set `SOCKSPort` to 0, which disables the client.
Use `mkForce` to prevent potentially two different `SOCKSPort` options in the torrc file, with one of them being 0 as this would cause Tor to fail to start. When `services.tor.client.enable` is set to false, this should always be disabled.
When `services.resolved.enable` is set to true, the file /etc/resolv.conf becomes a symlink to /etc/static/resolv.conf, which is a symlink to /run/systemd/resolve/stub-resolv.conf. Without this commit, tor does not have access to this file thanks to systemd confinement. This results in the following warning when tor starts:
```
[warn] Unable to stat resolver configuration in '/etc/resolv.conf': No such file or directory
[warn] Could not read your DNS config from '/etc/resolv.conf' - please investigate your DNS configuration. This is possibly a problem. Meanwhile, falling back to local DNS at 127.0.0.1.
```
To fix this, simply allow read-only access to the file when resolved is in use.
According to https://github.com/NixOS/nixpkgs/pull/161818#discussion_r824820462, the symlink may also point to /run/systemd/resolve/resolv.conf, so allow that as well.
Tor waits ShutdownWaitLength seconds (30s by default) before actually shutting down. Since the systemd timeout is also set to 30 seconds, this results in a race condition that ends up killing Tor most of the time on my machine during shutdown.
To fix this, add the ShutdownWaitLength setting and tell systemd to wait 30 seconds more than that.
Arch Linux also has `TimeoutSec` set to 60 seconds: 6df716fe19/trunk/tor.service.
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.
most modules can be evaluated for their documentation in a very
restricted environment that doesn't include all of nixpkgs. this
evaluation can then be cached and reused for subsequent builds, merging
only documentation that has changed into the cached set. since nixos
ships with a large number of modules of which only a few are used in any
given config this can save evaluation a huge percentage of nixos
options available in any given config.
in tests of this caching, despite having to copy most of nixos/, saves
about 80% of the time needed to build the system manual, or about two
second on the machine used for testing. build time for a full system
config shrank from 9.4s to 7.4s, while turning documentation off
entirely shortened the build to 7.1s.
When accessing the Audit log, I get an HTTP 502 when the frontend
requests `/audit` and I get the following error in my `nginx`-log:
Dec 20 22:12:48 ldap nginx[336]: 2021/12/20 22:12:48 [error] 336#336: *8421 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.237.0.1, server: _, request: "GET /audit/?action=**&action_detail=**&administrator=**&client=**&date=**&duration=**&info=**&page=1&page_size=10&policies=**&privacyidea_server=**&realm=**&resolver=**&serial=**&sortorder=desc&startdate=**&success=**&tokentype=**&user=** HTTP/1.1", upstream: "uwsgi://unix:/run/privacyidea/socket:", host: "ldap.ist.nicht-so.sexy", referrer: "https://ldap.ist.nicht-so.sexy/"
This is because of an "invalid request block size"-error according to
`journalctl -u privacyidea.service`:
Dec 20 22:12:48 ldap uwsgi[10721]: invalid request block size: 4245 (max 4096)...skip
Increasing the buffer to 8192 fixes the problem for me.
adds defaultText for all options that use `cfg.*` values in their
defaults, but only for interpolations with no extra processing (other
than toString where necessary)
This adds a `wantedBy` clause to the user systemd service for
yubikey-agent, to ensure an enabled agent is started on boot. This
brings the behavior inline with existing documentation.
If the user has selected a graphical pinentry program, then we need to
wait for the graphical environment to exist before starting the
yubikey-agent. I've found that if we start the agent earlier it will
fail when we perform an ssh command later.
Tor attempts to detect what external IP address a machine is using by
listing addresses on all network interfaces on the system. This listing
is done using getifaddrs(3), which relies on netlink in order to get
IPv6 address information.
This change fixes Tor not finding the relay's IPv6 address unless
explicitly configured via either an ORPort directive or via DNS
resolution of the machine hostname.
