For now at least. I expect someone will find a working type later.
It's incorrect and was causing bad issues. Example test case:
nix-instantiate nixos/release.nix -A tests.xfce.x86_64-linux --dry-run
This is a partial revert of commit b2d803c from PR #162271.
Currently it is only possible to add upstream _system_ units. The option
systemd.additionalUpstreamSystemUnits can be used for this.
However, this was not yet possible for systemd.user. In a similar
fashion this was added to systemd-user.nix.
This is intended to have other modules add upstream units.
Add an exception to the `paperless-ng-server` service's
`SystemCallFilter` as the `mbind` syscall is needed when consuming a
document while having a classification model present.
Since b9cfbcafdf, the lack of hexdump in
the closure lead to the generation of empty cookie files. This empty
cookie file is making pleroma to crash at startup now we correctly
read it.
We introduce a migration forcing these empty cookies to be
re-generated to something not empty.
We inject the release cookie path to the pleroma derivation in order
to wrap pleroma_ctl with it. Doing this allows us to remove the
systemd-injected RELEASE_COOKIE path, which was sadly
buggy (RELEASE_COOKIE should point to the *content* of the cookie, not
the file containing it).
We take advantage of this to factor out the cookie path.
Fixes race conditions like this:
> systemd[1]: Started prometheus-kea-exporter.service.
> kea-exporter[927]: Listening on http://0.0.0.0:9547
> kea-exporter[927]: Socket at /run/kea/dhcp4.sock does not exist. Is Kea running?
> systemd[1]: prometheus-kea-exporter.service: Main process exited, code=exited, status=1/FAILURE
It doesn't make sense to have a default value for this that's
incompatible with the default locate implementation. It means that
just doing services.locate.enable = true; generates a warning, even if
you don't care about pruning anything. So only use the default prune
list if the locate implementation supports it (i.e., isn't findutils).
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.
Use a quoted heredoc to inject installBootLoader safely into the script,
and restore the previous invocation of `system` with a single argument so
that shell commands keep working.
Without this fix, evaluating a NixOS configuration with Tomcat enabled and the
default settings results in the following evaluation error:
Failed assertions:
- users.users.tomcat.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.tomcat.group = "tomcat";
users.groups.tomcat = {};
As a novice to using this module, I found the existing description to be
quite misleading. It does not at all disable pulling from the registry,
it just loads some image archive that may or may not be related to the
container you're specifying. I had thought there was extra magic behind
this option, but it's just a `docker load`. You need foreknowledge of
the contents of the archive so that whatever it contained is actually
used to run the container.
I've reworded the description to hopefully make this behavior clearer.
This bug is so obscure and unlikely that I was honestly not able to
properly write a test for it. What happens is that we are calling
handleModifiedUnit() with $unitsToStart=\%unitsToRestart. We do this to
make sure that the unit is stopped before it's started again which is
not possible by regular means because the stop phase is already done
when calling the activation script.
recordUnit() still gets $startListFile, however which is the wrong file.
The bug would be triggered if an activation script requests a service
restart for a service that has `stopIfChanged = true` and
switch-to-configuration is killed before the restart phase was run. If
the script is run again, but the activation script is not requesting
more restarts, the unit would be started instead of restarted.
We spent a whole afternoon debugging this, because upstream has very
bad software quality and the error messages were incredibly
misleading.
So let’s document it for the sanity of other people.
Btw, I think the implementation of our module is pretty brittle,
especially the part about diffing tokens to check whether they
changed. We should rather just request a new builder registration
every time, it’s not that much overhead, and always set `replace` so
it is idempotent.
Some systems should not be rebooted at just any time. If the upgrade process takes too long, for instance because of a
slow internet connection, or if the upgrade service is ran during production hours, we want to allow to define a window
outside of which a reboot will not be performed.
The system will then reboot on the next run of the upgrade service which finishes inside the reboot window.
E.g. we can run the update service twice per week, once during the night and once during the day, but reboots are only
allowed during the night. By doing so, a system that is usually shut down during the night will still receive updates
and systems that are turned on 24/7 can be rebooted outside of production hours.
Co-authored-by: Silvan Mosberger <github@infinisil.com>
zsh-autosuggestions supports having fallback strategies expressed
through the ZSH_AUTOSUGGEST_STRATEGY array. For example,
`ZSH_AUTOSUGGEST_STRATEGY=(history completion)`. We should also support
this.
For systems without internet connections, it doesn't make sense to
require the existence of an /etc/resolv.conf file to disable
resolvconf, so let's expose networking.resolveconf.enable as a public
option that can be set to false.
In issue #157787 @martined wrote:
Trying to use confinement on packages providing their systemd units
with systemd.packages, for example mpd, fails with the following
error:
system-units> ln: failed to create symbolic link
'/nix/store/...-system-units/mpd.service': File exists
This is because systemd-confinement and mpd both provide a mpd.service
file through systemd.packages. (mpd got updated that way recently to
use upstream's service file)
To address this, we now place the unit file containing the bind-mounted
paths of the Nix closure into a drop-in directory instead of using the
name of a unit file directly.
This does come with the implication that the options set in the drop-in
directory won't apply if the main unit file is missing. In practice
however this should not happen for two reasons:
* The systemd-confinement module already sets additional options via
systemd.services and thus we should get a main unit file
* In the unlikely event that we don't get a main unit file regardless
of the previous point, the unit would be a no-op even if the options
of the drop-in directory would apply
Another thing to consider is the order in which those options are
merged, since systemd loads the files from the drop-in directory in
alphabetical order. So given that we have confinement.conf and
overrides.conf, the confinement options are loaded before the NixOS
overrides.
Since we're only setting the BindReadOnlyPaths option, the order isn't
that important since all those paths are merged anyway and we still
don't lose the ability to reset the option since overrides.conf comes
afterwards.
Fixes: https://github.com/NixOS/nixpkgs/issues/157787
Signed-off-by: aszlig <aszlig@nix.build>
This fixes the following issues with the database provisioning script
included in the services.keycloak module:
- It lacked permission to access the DB password file specified in the
module option 'services.keycloak.database.passwordFile'.
- It prevented Keycloak from starting after the second time if the user
chose MySQL for the database.
Update version to 1.4.231.
Build 231 points to a specific commit from the 1.4.x branch adding many
fixes and improvements. Since this version is an unofficial release, add
an unstable prefix to the version string in Nixpkgs.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Signed-off-by: Franz Pletz <fpletz@fnordicwalking.de>
logrotate.timer is enough for rotating logs. Enabling logrotate.service would
make the service start on every configuration switch, leading to tests failure when
logrotate is enabled.
Also update test to make sure the timer is active and runs the service
on date change.
https://github.com/ipfs/fs-repo-migrations/releases/tag/v2.0.2
This is pretty much a complete rewrite of the ipfs-migrator package.
In version 2.0.0 a major change was made to the way the migrator works. Before, there was one binary that contained every migration. Now every migration has its own binary. If fs-repo-migrations can't find a required binary in the PATH, it will download it off the internet. To prevent that, build every migration individually, symlink them all into one package and then wrap fs-repo-migrations so it finds the package with all the migrations.
The change to the IPFS NixOS module and the IPFS package is needed because without explicitly specifying a repo version to migrate to, fs-repo-migrations will query the internet to find the latest version. This fails in the sandbox, for example when testing the ipfs passthru tests.
While it may seem like the repoVersion and IPFS version are in sync and the code could be simplified, this is not the case. See https://github.com/ipfs/fs-repo-migrations#when-should-i-migrate for a table with the IPFS versions and corresponding repo versions.
Go 1.17 breaks the migrations, so use Go 1.16 instead. This is also the Go version used in their CI, see 3dc218e300/.github/workflows/test.yml (L4). See https://github.com/ipfs/fs-repo-migrations/pull/140#issuecomment-982715907 for a previous mention of this issue. The issue manifests itself when doing anything with a migration, for example `fs-repo-11-to-12 --help`:
```
panic: qtls.ClientHelloInfo doesn't match
goroutine 1 [running]:
github.com/marten-seemann/qtls-go1-15.init.0()
github.com/marten-seemann/qtls-go1-15@v0.1.1/unsafe.go:20 +0x132
```
Also add myself as a maintainer for this package.
This fixes the test failure discovered in https://github.com/NixOS/nixpkgs/pull/160914.
See https://github.com/ipfs/fs-repo-migrations/issues/148 to read some of my struggles with updating this package.
The argument parser used by snapserver behaves differntly for optional
arguments with existing defaults. In such cases, the standalone argument
name is a valid input and a following value is interpreted as a
positional argument. Therefore the argument and the value must be
provided as a single argument seperated by equals sign.
