The restic repository cache location defaults to ~/.cache/restic when
not overwritten either by the --cache-dir command line parameter or the
universal RESTIC_CACHE_DIR environment variable.
Currently, the --cache-dir variable is set to only some restic commands,
but, e.g., not to the unit's preStart command for the module's
initialize option. This results in two distinct cache locations, one at
~/.cache/restic for the initialize commands and one at the configured
--cache-dir location for the restic backup command.
By explicitly setting RESTIC_CACHE_DIR for the unit, only one cache at
the correct location will be used.
https://restic.readthedocs.io/en/v0.15.1/manual_rest.html#caching
Hydra Eval has been throwing these eval errors for the past four
months, which makes the yellow "Eval Errors" bubble pretty useless:
https://hydra.nixos.org/eval/1790611#tabs-errors
```
in job ‘nixos.tests.installer.separateBoot.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
in job ‘nixos.tests.installer.simple.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
in job ‘nixos.tests.installer.lvm.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
```
This PR moves the failure for the `!isEfi &&
!pkgs.stdenv.hostPlatform.isx86` case from eval-time to runtime, so
the failure gets categorized under the test that produced it, rather
than just being lumped in to the catch-all Eval Errors pile
which... apparently nobody cares about.
Some of the stuff used to be needed for a project, for others I found
alternatives that suited better my needs. Anyways, I don't intend to
spend time maintaining these, so no need to keep that.
`/api/v1/signing-key.gpg` spawns a `gpg` process,
which is great to test if `gpg` is available
and can be invoked from in the unit.
Which is somewhat relevant, since `gpg` was
missing from the unit's `$PATH` until recently.
And even after adding `gpg` to the unit's `$PATH`,
configuring commit signing for a instance
resulted in http/500s nonetheless.
That's due to `@memlock` being present in
`SystemCallFilter=~` and `gpg` trying to
use `mlock` (probably to prevent secrets
in the memory to swap), resulting in an
immediate `SIGKILL` of any spawned `gpg` processes.
The defaults conflicts with the defaults of `services.httpd`:
```
error: The option `nodes.machine.services.logrotate.enable' has conflicting definition values:
- In `/home/thomas/Workspace/Packaging/nixpkgs/nixos/modules/profiles/minimal.nix': false
- In `/home/thomas/Workspace/Packaging/nixpkgs/nixos/modules/services/web-servers/apache-httpd/default.nix': true
Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.
(use '--show-trace' to show detailed location information)
```
`nixos/profile/minimal` is not used in the majority of the tests and it does not
seem to have a specific reason to use it for the HAProxy test.
It looks like the systemd-initrd variant of the systemd-shutdown test
(systemd-initrd-shutdown) did not actually enable the systemd-initrd and
so was just evaluating to the same store path before this change.
The test was failing because it was timing out. Turns out it was waiting
for `foo.kdbx`, which couldn't be "seen" even if it actually existed
(probably some contrast issues with the theme and OCR couldn't find it).
Fixed it by delegating the check to the next screen, where the full path
to the file is displayed in a bigger size. The test seems to pass.
Prepare the tests for a change in dependency handling, by not relying on
bespoke files dropped into the package output.
Instead we now check the journal log for whether a configured component
was setup, once for the initial specialisation another time for the one
introducing esphome configuration.
Also improve abstractions for getting journal data relative to a cursor
and generally make a few things more concise.
using readFile instead of fileContents (or using indented strings) can
leave a trailing newline that causes build errors in systemd units and
has previously caused runtime errors in wireguard scripts. use
singleLineStr to strip a trailing newline if it exists, and to fail if
more than one is present.
...but still allow for setting `dataDir` to a custom path. This gets
rid of the use of the deprecated option PermissionsStartOnly. Also, add
the ability to customize user and group, since that could be useful
with a custom `dataDir`.
Since https://github.com/NixOS/nixpkgs/issues/213943 got fixed, only the main k3s derivation is tested.
Here I changed the tests a bit to make them test all provided k3s derivations
@moduon MT-1718
By default, pgadmin4 uses SERVER_MODE = True. This requires
access to system directories (e.g. /var/lib/pgadmin). There is
no easy way to change this mode during runtime. One has to change
or add config files withing pgadmin's directory structure to change it
or add a system-wide config file under `/etc/pgadmin`[1].
This isn't always easy to achive or may not be possible at all. For
those usecases this implements a switch in the pgadmin4 derivation and
adds a new top-level package `pgadmin4-desktopmode`. This builds in
DESKTOP MODE and allows the usage of pgadmin4 without the nixOS module
and without access to system-wide directories.
pgadmin4 module saves the configuration to /etc/pgadmin/config_system.py
pgadmin4-desktopmode tries to read that as well. This normally fails with
a PermissionError, as the config file is owned by the user of the pgadmin module.
With the check-system-config-dir.patch this will just throw a warning
but will continue and not read the file.
If we run pgadmin4-desktopmode as root
(something one really shouldn't do), it can read the config file and fail,
because of the wrong config for desktopmode.
[1]https://www.pgadmin.org/docs/pgadmin4/latest/config_py.html
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
We test pgadmin in nixosTests, because it needs a running postgresql instance.
This is now unnecessary since we can do so in the package itself.
This reduces the complexity of pgadmin and removes the need for the extra
nixosTests.
Also setting SERVER_MODE in `pkg/pip/setup_pip.py` does not have any effect
on the final package, so we remove it.
In NixOS, we use the module, which expects SERVER_MODE to be true (which it defaults to).
In non-NixOS installations, we will need the directory /var/lib/pgadmin and /var/log/pgadmin
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
If our (fake) metadata server provides a 404 instead of a JSON document,
the NSS module segfaults, and as we do NSS lookups through ns(n)cd,
not only crashes the application doing the NSS lookup, but our ns(n)cd.
This has been causing segfaults of nscd all along, but since our switch
from glibc-nscd to nsncd, caused the test to fail entirely.
In any case, by handling /computeMetadata/v1/oslogin/groups we get the
NSS lookup to not cause any segfaults, and to succeed the test again.
bpftrace 0.17 added module BTF support, check this works.
On bpftrace 0.16, this failed with the following error:
> ERROR: kfunc:nft_trans_alloc_gfp: no BTF data for the function
As announced in the NixOS 22.11 release notes, 23.05 will switch NixOS
to using nsncd (a non-caching reimplementation in Rust) as NSS lookup
dispatcher, instead of the buggy and deprecated glibc-provided nscd.
If you need to switch back, set `services.nscd.enableNsncd = false`, but
please open an issue in nixpkgs so your issue can be fixed.
...for explicitly named network interfaces
This reverts commit 6ae3e7695e.
(and evaluation fixups 08d26bbb727aed90a969)
Some of the tests fail or time out after the merge.
Because nextcloud ships their prerelease versions on a different url, we
are not parsing the version string to detect which path to use. We also
enabled and validated this change via nixos module testing.
EOLed by upstream, doesn't receive any patches anymore, so let's drop
it.
Currently depends on #211886 which bumps the latest compatible ZFS
version to 6.1.
Also, clean up some old aliases.
Adds a new option to the virtualisation modules that enables specifying
explicitly named network interfaces in QEMU VMs. The existing
`virtualisation.vlans` is still supported for cases where the name of
the network interface is irrelevant.
Previously, secrets were named according to the initrd they were
associated with. This created a problem: If secrets were changed whilst
the initrd remained the same, there were two versions of the secrets
with one initrd. The result was that only one version of the secrets would
by recorded into the /boot partition and get used. AFAICT this would
only be the oldest version of the secrets for the given initrd version.
This manifests as #114594, which I found frustrating while trying to use
initrd secrets for the first time. While developing the secrets I found
I could not get new versions of the secrets to take effect.
Additionally, it's a nasty issue to run into if you had cause to change
the initrd secrets for credential rotation, etc, if you change them and
discover you cannot, or alternatively that you can't roll back as you
would expect.
Additional changes in this patch.
* Add a regression test that switching to another grub configuration
with the alternate secrets works. This test relies on the fact that it
is not changing the initrd. I have checked that the test fails if I
undo my change.
* Persist the useBootLoader disk state, similarly to other boot state.
* I had to do this, otherwise I could not find a route to testing the
alternate boot configuration. I did attempt a few different ways of
testing this, including directly running install-grub.pl, but what
I've settled on is most like what a user would do and avoids
depending on lots of internal details.
* Making tests that test the boot are a bit tricky (see hibernate.nix
and installer.nix for inspiration), I found that in addition to
having to copy quite a bit of code I still couldn't get things to
work as desired since the bootloader state was being clobbered.
My change to persist the useBootLoader state could break things,
conceptually. I need some help here discovering if that is the case,
possibly by letting this run through a staging CI if there is one.
Fix#114594.
cc potential reviewers:
@lopsided98 (original implementer) @joachifm (original reviewer),
@wkennington (numerous fixes to grub-install.pl), @lheckemann (wrote
original secrets test).
The cups-pdf vm test previously waited for the
activation of `cups.service` before testing anything.
This method fails since
47d9e7d3d7
as cups auto-stops if it is not used,
causing the test framework to complain
that `cups.service` will never start.
The commit at hand alters the test so it
simply waits for `multi-user.target`.
We could also switch to `cups.socket`,
but `multi-user.target` seems to be more robust
concerning future changes in the cups mechanisms.
This reverts commit a768871934.
This is too fragile, it breaks at least on:
* ssl dh params
* hostnames in proxypass and upstreams are resolved in the sandbox
The update test patches the systemd-boot binary to report a known
version then tests that this is the version updated from. The previous
patch would also search the kernel and initrd binaries, which would
cause sed to write out a temporary file that might cause the disk
to run out of space and the test to fail.
Only attempt to patch binaries which contain systemd-boot (usually
`BOOT<arch>.EFI` and `systemd-boot<arch>.efi` to avoid this problem.
As a bonus, this reduces test time by 20-30%.
At some point many months ago, the systemd-boot update script stopped
outputting parentheses around the version being upgraded from, causing
the test to fail. Remove the parentheses from the expected message to
fix the test.
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
This provides an easy way to specify exclude patterns in config. It was
already possible via extraBackupOptions; this change creates a simpler,
similar to other backup services, way to specify them.
This commit also moves the indicator files out of the directory that's
being backed up, so that the directory remains static throughout the
backup operation.
Added the RFC42-style added the posibility to use
`services.dokuwiki.sites.<name>.settings' instead of passing a plain
string to `<name>.extraConfig`. ´<name>.pluginsConfig` now also accepts
structured configuration.
Also added two "quality of life" tests to ensure customisations to the
dokuiwki package are not being discarded and both webserver
configurations handle rewriting correctly.
As a follow up to f9d1f80045, we should
add the ability to test explicit versions of the wordpress derivation.
Since we are currently only supporting wordpress6_1 in unstable, this
change is a noop.
Updates #209051
The nixOS test failed sporadically with a timeout.
This is due to a race condition in the startup of
the scheduler vs the task-queue.
The scheduler runs the migration scripts in "pre-start" and
celery isn't available, yet. The celery worker (paperless-task-queue)
was already started by systemd but was unable to connect
(as the migration scripts from "pre-start" still ran).
This fix adds the necessary "after" condition in the systemd
worker unit and adds a test to "paperless"
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
It's better to utilize the boot process and systemd mechanisms to test
these zfs features, rather than manually simulating the same behavior
with testScript.
When test-input-reader runs, it's standard input exists and will
be buffered, so by the time the file exists, the standard input
can already be written to.
I have no reason to believe that a terminal emulator would start
accepting input _after_ launching the command.
I've tested this for hours in a loop without a single failure or
timeout.
This commit upgrades headscale to the newest version, 0.17.0 and updates
the module with the current breaking config changes.
In addition, the module is rewritten to conform with RFC0042 to try to
prevent some drift between the module and the upstream.
A new maintainer, Misterio77, is added as maintainer.
Signed-off-by: Kristoffer Dalby <kristoffer@tailscale.com>
Co-authored-by: Gabriel Fontes <hi@m7.rs>
Co-authored-by: Geoffrey Huntley <ghuntley@ghuntley.com>
On x86_64-linux only because bootspec is for NixOS (for the moment?),
and NixOS is really only a Linux concept (for the moment?).
Not on aarch64-linux because it fails for whatever reason 🤷
Nginx breaks at runtime when duplicate modules are added. To detect
this, add a `name` key to all modules.
Also remove the outdated modsecurity v2 module and unify `modsecurity`
and `modsecurity-nginx`.
We can't actually get metrics for a virtual disk drive so the exporter
fails to start with 0.9.x.
Instead let's just make sure it said that /dev/vda was unavailable.
This splits the tests into two: one where cups.socket is started
normally, the order with socket activation.
Why? It's almost impossible to follow the test with 4 different
machines printing at the same time. It should also be more efficient
because only two VMs at a time were needed anyway.
Adds a new option for backup jobs `inhibitsSleep` which prevents
the system from going to sleep while a backup is in progress.
Uses `systemd-inhibit`, which holds a "lock" that prevents the
system from sleeping while the process it invokes is running.
This did require wrapping the existing backup script using
`writeShellScript` so that it could be run by `systemd-inhibit`.
Changes sgx-psw to append `aesm` to `LD_LIBRARY_PATH`:
- Append instead of prepend to allow for overriding in service config
- As we already add a wrapper to add `aesm` to `LD_LIBRARY_PATH` it is
not necessary to also set in `LD_LIBRARY_PATH` of the systemd service.
Co-authored-by: Vincent Haupert <mail@vincent-haupert.de>
- The default cipher is BF-CBC, which openvpn refuses to use by default.
Switched to AES-256-CBC.
- openvpn does not require an external "ip" executable anymore, and does
not support the "ipconfig" option by default, so remove that option.
This is a follow up to #200815 and #184634.
The PCRE2 JIT SEAlloc does not support the `fork()` as announced in
their README [0]:
> If you are enabling JIT under SELinux environment you may also want to add
> --enable-jit-sealloc, which enables the use of an executable memory allocator
> that is compatible with SELinux. Warning: this allocator is experimental!
> It does not support fork() operation and may crash when no disk space is
> available. This option has no effect if JIT is disabled.
As a result using it in PHP can break apps and tools, it can only be
enabled under very specific context where you have a full picture of
what the PHP code is doing.
This contribution disables again the PCRE2 JIT SEAlloc and extends the
existing PHP/PCRE2 tests to make sure we do not enable it again by
mistake.
[0] https://www.pcre.org/readme.txt
remove trailing whitespace
switch docs to markdown
use mdDoc
remove trailing whitespace
get rid of double space
add tests and update options to use submodule
remove whitespace
remove whitespace
use mdDoc
remove whitespace
make default a no-op
make ALTER ROLE a single sql statement
document null case
The tests TLS setup was bogus: the xmpp-send-message script was trying
to connect to the server through a bogus domain name. Injecting the
right one.
I'm a bit confused about that one. I know for sure this NixOS test
succeeded last time I checked it, but the TLS conf is bogus for sure.
I assume the slixmpp SNI validation was a bit too loose and was
tightened at some point.
The xmpp-sendmessage the slixmpp-powered python script tend to timeout
and block the nixos channels.
Adding a signal-based timeout making sure that whatever happens, the
script won't run for more than 2 minutes. That should be pleinty
enough time to finish regardless of the runner specs. As a data point,
it runs in about 10 secs on my desktop machine.
The hack with `either` had the side-effect that the sub-options of the
submodule didn't appear in the manual. I decided to remove this because
the "migration" isn't that hard, you just need to fix some module
declarations.
However, `mkRenamedOptionModule` wouldn't work here because it'd create
a "virtual" option for the deprecated path (i.e.
`services.grafana.provision.{datasources,dashboards}`), but that's the
already a new option, i.e. the submodule for the new stuff.
To make sure that you still get errors, I implemented a small hack using
`coercedTo` which throws an error if a list is specified (as it would be
done on 22.05) which explains what to do instead to make the migration
easier.
Also, I linkified the options in the manual now to make it easier to
navigate between those.
This commit fixes broken non-declarative configs by
making the assertions more relaxed.
It also allows to remove the forced configuration merge by making
`settings` `null`able (now the default).
Both cases (trivial non-declarative config and `null`able config) are
verified with additional tests.
Fixes#198665
fscrypt can automatically unlock directories with the user's login
password. To do this it ships a PAM module which reads the user's
password and loads the respective keys into the user's kernel keyring.
Significant inspiration was taken from the ecryptfs implementation.
Upon testing the change itself I realized that it doesn't build properly
because
* the `pname` of a php extension is `php-<name>`, not `<name>`.
* calling the extension `openssl-legacy` resulted in PHP trying to compile
`ext/openssl-legacy` which broke since it doesn't exist:
source root is php-8.1.12
setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c
patching sources
cdToExtensionRootPhase
/nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory
I didn't encounter that one before because I was mostly interested in
having a sane behavior for everyone not using this "feature" and the
documentation around this. My findings about the behavior with turning
openssl1.1 on/off are still valid because I tested this on `master` with
manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`.
To work around the issue I had to slightly modify the extension
build-system for PHP:
* The attribute `extensionName` is now relevant to determine the output
paths (e.g. `lib/openssl.so`). This is not a behavioral change for
existing extensions because then `extensionName==name`.
However when specifying `extName` in `php-packages.nix` this value is
overridden and it is made sure that the extension called `extName` NOT
`name` (i.e. `openssl` vs `openssl-legacy`) is built and installed.
The `name` still has to be kept to keep the legacy openssl available
as `php.extensions.openssl-legacy`.
Additionally I implemented a small VM test to check the behavior with
server-side encryption:
* For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix`
it's checked that OpenSSL 3 is used). With that the "default"
behavior of the module is checked.
* It is ensured that the PHP interpreter for Nextcloud's php-fpm
actually loads the correct openssl extension.
* It is tested that (encrypted) files remain usable when (temporarily)
installing OpenSSL3 (of course then they're not decryptable, but on a
rollback that should still be possible).
Finally, a few more documentation changes:
* I also mentioned the issue in `nextcloud.xml` to make sure the issue
is at least mentioned in the manual section about Nextcloud. Not too
much detail here, but the relevant option `enableBrokenCiphersForSSE`
is referenced.
* I fixed a few minor wording issues to also give the full context
(we're talking about Nextcloud; we're talking about the PHP extension
**only**; please check if you really need this even though it's
enabled by default).
This is because I felt that sometimes it might be hard to understand
what's going on when e.g. an eval-warning appears without telling where
exactly it comes from.
Previously we did socket-activation but this breaks the autostart
feature since upstream expects libvirtd to be started unconditionally on
boot.
Fixes#171623.
* s/NextCloud/Nextcloud/g
* `enableBrokenCiphersForSSE` should be enabled by default for any NixOS
installation from before 22.11 to make sure existing installations
don't run into the issue. Not the other way round.
* Update release notes to reflect on that.
* Improve wording of the warning a bit: explain which option to change
to get rid of it.
* Ensure that basic tests w/o `enableBrokenCiphersForSSE` run with
OpenSSL 3.
I need to fix copying the chrome://gpu content to the clipboard (Ctrl+a doesn't
work anymore so we have to click the button) but we can at least test the font
rendering for now.
This is a small smoke test of each piece (setuid, setgid, caps) of
wrappers' functionality. It doesn't try to check for combinations of
functionalities or anything more complicated.
