* It's IMHO a slight overkill to deploy an additional container even if
it's never supposed to be running. Also, the currently suggested
approach wouldn't use the default state-directory for the new version.
* Explain the structure of the state-directories and where the
version-numbers are actually coming from.
* Mention `./analyze_new_cluster.sh` & `./delete_old_cluster.sh`.
by default a ps/2 keyboard input is used which seems to cause issues
on aarch64-linux when the machine is used high load, causing the keymap
qwertz test to always fail and azerty to sometimes fail
See https://github.com/NixOS/nixpkgs/issues/147294
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.
