Dnscrypt-proxy needs some options to be set before it can do anything useful.
Currently, we only apply what the user configured which, by default, is nothing.
This leads to the dnscrypt-proxy2 service failing to start when you only set
`enable = true;` which is not a great user experience.
This patch makes the module take the example config from the upstream repo as a
base on top of which the user-specified settings are applied (it contains sane
defaults).
An option has been added to restore the old behaviour.
`file_exists` also returns `FALSE` if the file is in a directory that
can't be read by the user. This e.g. happens if permissions for
`nixops(1)`-deployment keys aren't configured correctly.
This patch improves the error message for invalid files to avoid
confusion[1].
[1] https://discourse.nixos.org/t/nixops-deploy-secrets-to-nextcloud/10414/4
This patch:
* Removes an invalid/useless classpath element;
* Removes an unnecessary environment variable;
* Creates the required '/version-2' data subdirectory;
* Redirects audit logging to the "console" (systemd) by default.
Unbound throws the following error:
--8<---------------cut here---------------start------------->8---
error: failed to list interfaces: getifaddrs: Address family not supported by protocol
fatal error: could not open ports
--8<---------------cut here---------------end--------------->8---
The solution is pulled from upstream:
https://github.com/NLnetLabs/unbound/pull/351
Unfortunately, I had a use-case where `services.nginx.config` was
necessary quite recently. While working on that config I had to look up
the module's code to understand which options can be used and which
don't.
To slightly improve the situation, I changed the documentation like
this:
* Added `types.str` as type since `config` is not mergeable on purpose.
It must be a string as it's rendered verbatim into `nginx.conf` and if
the type is `unspecified`, it can be confused with RFC42-like options.
* Mention which config options that don't generate config in
`nginx.conf` are NOT mutually exclusive.
There was some issues with the fallback to passive mode on 2.3, but on
2.4 adaptive mode is always enabled upstream and thermald will fallback
to passive if necessary.
a6e68a65b5/data/thermald.service.in (L9)
This simplifies testing changes to the tailscale service on a local
machine. You can use this as such:
```nix
let
tailscale_patched = magic {};
in {
services.tailscale = {
enable = true;
package = tailscale_patched;
};
};
```
Signed-off-by: Christine Dodrill <me@christine.website>
I've also removed PrivateTmp = true because this is implied by dynamic user.
I've left ProtectHome = true because I believe this is stronger than
ProtectHome = "read-only" which DynamicUser implies.
This resolves issue #101963.
When the service is started and no interface is ready yet, wpa_supplicant
is being exec'd with no `-i` flags, thus failing. Once the interfaces
are ready, the udev rule would fire but wouldn't restart the unit because
it wasn't currently running (see systemctl(1) try-restart).
The solution is to exit (with a clear error message) but always restart
wpa_supplicant when the interfaces are modified.
This release replaces the libpulseaudio shim with a pipewire module that acts as a fake pulseaudio server along with a systemd service that loads that module on demand.
The old slapd.conf is deprecated. Replace with slapd.d, and use this
opportunity to write some structured settings.
Incidentally, this fixes the fact that openldap is reported up before
any checks have completed, by using forking mode.
This gets automatically disabled by docker if the docker backend is
used, but the bundled containerd also doesn't seem to support cgroupsv2,
so disable it explicitly here, too.
Whenever I try to scan from another computer it has to establish >2
connections in order to succeed. With the connections being limited to 1
I can not scan any document.
This is also what other distributions ([Debian], [ArchLinux], …) have
done in one way or another.
[Debian]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850649#5
[ArchLinux]: no limit: 99cba454bb/trunk/saned.socket (L4)
This adds a `package` option to allow for easier overriding of the used
CodiMD version and `runCommandLocal` with `nativeBuildInputs` is now
used to pretty print the configuration.
Other units depend on nss-lookup.target and expect the DNS resolution to
work once that target is reached. The previous version
`wants=nss-lookup.target` made this unit require the nss-lookup.target
to be reached before this was started.
Another change that we can probalby do is drop the before relationship
with the nss-lookup.target. That might just be implied with the current
version.
This option allows users to specify a local UNIX control socket to
"remote control" the daemon. System users, that should be permitted to
access the daemon, must be in the `unbound` group in order to access the
socket. When a socket path is configured we are also creating the
required group.
Currently this only supports the UNIX socket mode while unbound actually
supports more advanced types. Users are still able to configure more
complex scenarios via the `extraConfig` attribute.
When this option is set to `null` (the default) it doesn't affect the
system configuration at all. The unbound defaults for control sockets
apply and no additional groups are created.
Previously we just applied a very minimal set of restrictions and
trusted unbound to properly drop root privs and capabilities.
With this change I am (for the most part) just using the upstream
example unit file for unbound. The main difference is that we start
unbound was `unbound` user with the required capabilities instead of
letting unbound do the chroot & uid/gid changes.
The upstream unit configuration this is based on is a lot stricter with
all kinds of permissions then our previous variant. It also came with
the default of having the `Type` set to `notify`, therefore we are also
using the `unbound-with-systemd` package here. Unbound will start up,
read the configuration files and start listening on the configured ports
before systemd will declare the unit "running". This will likely help
with startup order and the occasional race condition during system
activation where the DNS service is started but not yet ready to answer
queries.
Aditionally to the much stricter runtime environmet I removed the
`/dev/urandom` mount lines we previously had in the code (that would
randomly fail during `stop`-phase).
The `preStart` script is now only required if we enabled the trust
anchor updates (which are still enabled by default).
Another beneefit of the refactoring is that we can now issue reloads via
either `pkill -HUP unbound` or `systemctl reload unbound` to reload the
running configuration without taking the daemon offline. A prerequisite
of this was that unbound configuration is available on a well known path
on the file system. I went for /etc/unbound/unbound.conf as that is the
default in the CLI tooling which in turn enables us to use
`unbound-control` without passing a custom configuration location.
