easiest way to do this is to move the default expression out and
abstract over what is substituted into it, using a dependent value for
the default and a descriptive value for defaultText
unfortunately we don't have a good way to represent defaults that
reference other values of the current submodule, so we just use the
relative path of the referenced value and assume that the submodule was
declared as `rec`.
instead of keeping a defaultConfig value around, set that value as the
default of the option and explicitly use the option default instead.
this also allows us to write a defaultText that makes sense and is in
proximity to the definition of the default.
some options have default that are best described in prose, such as
defaults that depend on the system stateVersion, defaults that are
derivations specific to the surrounding context, or those where the
expression is much longer and harder to understand than a simple text
snippet.
escape interpolations in descriptions where possible, replace them with
sufficiently descriptive text elsewhere. also expand cfg.* paths in
descriptions.
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)
the kubernetes modules cross-reference their config using an additional shortcut
binding `top = config.services.kubernetes`, expand those to defaultText like
`cfg` previously.
This reverts commit 6af3d13bec.
Reported by @arcnmx
(https://github.com/NixOS/nixpkgs/pull/148179#issuecomment-987197656):
Does this not completely break the service? It doesn't change the
owner to the same as the ddclient server (which is somewhat difficult
due to it being a DynamicUser), so this now makes the service
completely unusable because the config is only readable by its owner,
root:
ddclient[871397]: WARNING: file /run/ddclient/ddclient.conf: Cannot open file '/run/ddclient/ddclient.conf'. (Permission denied)
Given that the RuntimeDirectory was only readable by the ddclient
service, the warning this PR fixes was spurious and not indicative of
an actual information leak. I'm not sure of what a quick fix would be
due to DynamicUser, but would at least request a revert of this so the
service can work again?
This is horrible if you want to debug failures that happened during
system switches but your 30-ish acme clients spam the log with the same
messages over and over again.
Instead of patching the path to /public in Discourse's sources, make
the nginx configuration refer to the symlink in the discourse
package which points to the real path.
When there is a mismatch between the path nginx serves and the path
Discourse thinks it serves, we can run into issues like files not
being served - at least when sendfile requests from the ruby app are
processed by nginx. The issue I ran into most recently is that backup
downloads don't work.
Since Discourse refers to the public directory relative to the Rails
root in many places, it's much easier to just sync this path to the
nginx configuration than trying to patch all occurrences in the
sources. This should hopefully mean less potential for breakage in
future Discourse releases, too.
The first one doesn't make any sense because the directory where the
init binary resides does not contain other tools we need like
systemd-escape.
The second one doesn't make sense either because the errors are already
ignored.
While upgrading my NixOS system I was greeted by this error:
error:
Failed assertions:
- users.users.collectd.group is unset. This used to default to
nogroup, but this is unsafe. For example you can create a group
for this user with:
users.users.collectd.group = "collectd";
users.groups.collectd = {};
Let's fix it.
bcc doesn't really need kernel itself, it just cares about module path.
It's actually better to use /run/booted-system/kernel-modules/lib/modules
for two reasons:
- no need to rebuild bcc for each new kernel
- can use a newer bcc with a booted kernel that doesn't match the current
system
Otherwise, `postfix_up{path="/var/lib/postfix/queue/public/showq"}` will
always be `0` indicating an postfix outage because this is a unix domain
socket that cannot be connected to:
2021/12/03 14:50:46 Failed to scrape showq socket: dial unix /var/lib/postfix/queue/public/showq: socket: address family not supported by protocol
Remove PrivateDevices to silence warning about SnapRAID being
unable to access disk UUIDs.
Add CAP_FOWNER when touch is enabled so file time stamps can be
set.
Also, add support for updating plugins which keep gem versions in
files at the root of the repo (discourse-prometheus) and replace the
`up-plugin.sh` script with a README file pointing to the plugin
packaging documentation.
This commit changes how we deal with the current token, i.e., the token
which may exist from a previous runner registration, and the configured
token, i.e., the path set for the respective NixOS configuration option.
Until now, we copied the configured and the current token (if any) to
the runtime directory to compare them. The path of the current token may
reference a file which is only accessible to specific users (even only
root). Therefore, we ran the copying of credentials with elevated
privileges by prefixing the `ExecStartPre=` script with a `+` (see
systemd.service(5)). In this script, we also changed the owner of the
files to the service user. Apparently, however, the user/group pair
sometimes did not exist because we use `DynamicUser=`.
To address this issue, we no longer change the owner of the file.
Instead, we change the file permissions to 0666 to allow the runner
configuration script (runs with full sandboxing) to read-write the file.
Due to the current permissions of the runtime directory (0755), this
would expose the token. Therefore, we process the tokens in the state
directory, which is only accessible to the service user.
If a new token file exists in the state directory, the configuration
script should trigger a new runner registration. Afterward, it deletes
the new token file. The token is still available using the path of the
current token which is inaccessible within the service's sandbox.
Previously the extraComponents added to an overriden package would not
have been considered in hardening measures enforced by the module.
Home Assistant is warning the user about component definitions having
moved away from YAML, so using an override to include support for a
component might become the better way moving forward.
dhdpcd 9 support privilege separation with a dedicated user and seccomp
filtering. this has been enabled for a while in other distributions as
well.
if the dhcpcd module is not used and the _dhcpcd user/group isn't
definied otherwise dhcpcd will fall back to not using privsep.
by @erictapen:
- Removed note about testing and moved it to passthru.tests
- Removed patch, as it is probably the same as
56b2bb17d2ec67e1f93950944211f6cf8c40e0fb, wich landed in upstream.
other changes:
- changed PIDFile in the module, since dhcpcd 9 changed the location
Add `systemd.network.networks.*.dhcpServerStaticLeaseConfig` to allow
for configuring static DHCP leases through the `[DHCPServerStaticLease]`
section. See systemd.network(5) of systemd 249 for details.
Also adds the NixOS test `systemd-networkd-dhcpserver-static-lease` to
test the assignment of static leases.
ClosesNixOS/nixpkgs#147348
I was able to reproduce this intermittently in the
test suite during the tests for HTTPd. Adding
StartLimitIntervalSec=0 to disable rate limiting
for these services works fine. I added it anywhere
there was a ConditionPathExists.
