since fc614c37c6 nixos needs access to its
own path (<nixpkgs/nixos>) to evaluate a system with documentation.
since documentation is enabled by default almost all systems need such
access, including the installer tests. nixos-install however does not
ensure that a channel exists in the target store before evaluating the
system in that store, which can lead to `path is not valid` errors.
The systemd syntax is suprising to me, but I suppose it's worth being
compatible as people might be sharing it with other modules.
Our regexp is lenient on IPv6 address part, so this is actually
backwards compatible (i.e. you can put the scope at either place).
tracker looks in its directory tree for executable files
to make available as subcommands. Users expect to find subcommands
from tracker-miners package but that fails as they are in different
tree. We also cannot change the lookup path since tracker-miners
also depends on a library from tracker package.
Until we can break the dependency cycle on package level:
tracker -> tracker-miners -> tracker-sparql (tracker)
we need to work around it. I chose to set an environment
variable that overrides the subcommands lookup to a tree
symlinking files from both packages in GNOME NixOS module.
https://gitlab.gnome.org/GNOME/tracker/-/issues/341
Fixes: https://github.com/NixOS/nixpkgs/issues/153378
When running e.g. `aa-genprof` get error:
> ERROR: Syntax Error: Unknown line found in file /etc/apparmor.d/abstractions/pam line 26:
> r /nix/store/XXXXX.pam,mr /nix/store/XXXXX-linux-pam-1.5.1/lib/security/pam_filter/*,
So add an explicit newline as concatMapStringsSep only adds them
between.
When `privateRepos = true`, the service will not start if the `.htpasswd` does not exist.
Use `systemd-tmpfiles` to autocreate an (empty) file to ensure the service can boot
before actual `htpasswd` contents are registered.
This is safe as restic-rest-server will deny all entry if the file is empty.
One of the subtests in the sudo NixOS test suite was broken: instead of
running the sudo invocation as user 'test2', it was running it as root.
Since root doesn't require a password to use sudo, this was causing
random "broken pipe" errors when trying to pass it a password via stdin.
the docs build should work well even when called from a git checkout of
nixpkgs, but should avoid as much work as possible in all cases.
if pkgs.path is already a store path we can avoid copying parts of it
into the docs build sandbox by wrapping pkgs.path in builtins.storePath
this partially solves the problem of "missing description" warnings of the
options doc build being lost by nix build, at the cost of failing builds that
previously ran. an option to disable this behaviour is provided.
link to search.nixos.org instead of pulling package metadata out of pkgs. this
lets us cache docs of a few more modules and provides easier access to package
info from the HTML manual, but makes the manpage slightly less useful since
package description are no longer rendered.
most modules can be evaluated for their documentation in a very
restricted environment that doesn't include all of nixpkgs. this
evaluation can then be cached and reused for subsequent builds, merging
only documentation that has changed into the cached set. since nixos
ships with a large number of modules of which only a few are used in any
given config this can save evaluation a huge percentage of nixos
options available in any given config.
in tests of this caching, despite having to copy most of nixos/, saves
about 80% of the time needed to build the system manual, or about two
second on the machine used for testing. build time for a full system
config shrank from 9.4s to 7.4s, while turning documentation off
entirely shortened the build to 7.1s.
I had trouble getting programs.firejail.wrappedBinaries to have any effect on my
system (#152852), because I did not realise that "put[ting] the actual
application binary in the global environment" included adding the program
package to environment.systemPackages, and I thought that the package must be
present for this option to take effect. I have added a clarifying parenthetical
statement explicitly mentioning environment.systemPackages in this caveat.
One use case for Mattermost configuration is doing a "mostly
mutable" configuration where NixOS module options take priority
over Mattermost's config JSON.
Add a preferNixConfig option that prefers configured Nix options
over what's configured in Mattermost config if mutableConfig is set.
Remove the reliance on readFile (it's flake incompatible) and use
jq instead.
Merge Mattermost configs together on Mattermost startup, depending
on configured module options.
Write tests for mutable, mostly mutable, and immutable configurations.
Adds a NixOS module which allows using mandoc as the main manual
viewer. It can be used as a drop-in replacement for documentation.man
which relies on GNU's man-db and provides more or less the same
features.
The generateCaches option requires a different implementation for
mandoc, so it is hard to share code between the two modules -- hence it
has been implemented separately. Using both at the same time makes
little sense and wouldn't quite work, so there's an assertion to
prevent it.
To make makewhatis(8) index manual pages which are symlinks to the nix
store, we need to set READ_ALLOWED_PATH to include
`builtins.storeDir`. For background and discussion see:
https://inbox.vuxu.org/mandoc-tech/c9932669-e9d4-1454-8708-7c8e36967e8e@systemli.org/T/
It may be possible to revert the move of `documentation.man.manualPages`
later. The problem is that other man implementations (mandoc) want to
generate their index databases in place, so the approach taken here
doesn't translate super well.
`mktemp` tries to use the `TMPDIR` from `nixos-install` outside of the
`chroot` instead of `/tmp` inside the `chroot` and fails. For some
reason the `TMPDIR` is being passed through the `chroot` call.
I haven't tested if other environment variables are being passed through
that shouldn't be.
Before this fix, if the listenAddress is set to something else than 127.0.0.1,
the service fails to detect that Elasticsearch has properly started and stop.
this set almost certainly shouldn't be touched by users, nor listed in
the manual. make it internal and use it only through the option path to
make clear that this should not be modified.
Other services such as minecraft-server and plex allow configuration of
the dataDir option, allowing the files stored by each service to be in a
custom location.
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
Does not set MemoryDenyWriteExecute as OpenJDK need to mark memory page as
executable. Does not set ProcSubset as /proc/cpuinfo and /proc/meminfo
are needed.
A change in QEMU v6.1.0 has somehow caused QEMU to behave differently
enough to cause this test to fail. This commit forces the test to be ran
with QEMU 6.0.0 from Nixpkgs at revision
e1fc1a80a0, which is the commit prior to
the QEMU 6.1.0 version bump.
Co-authored-by: Julio Sueiras <juliosueiras@gmail.com>
Adds a fully fledged NixOS VM integration test which uses jmtpfs and
gvfs to test the functionality of MTP inside of NixOS. It uses USB
device emulation in QEMU to create MTP device(s) which can be tested
against.
Co-authored-by: nixinator <33lockdown33@protonmail.com>
This commit introduces `services.adguardhome.settings` and
`services.adguardhome.mutableSettings`.
The first option allows declarative configuration of
AdGuard Home, while the second one controls whether changes
made in the web interface are kept between service restarts.
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
It breaks something inside of influxdb2, which results in flurry of errors like these:
> ts=2021-12-21T18:19:35.513910Z lvl=info msg="Write failed" log_id=0YZYwvV0000 service=storage-engine service=write shard=50 error="[shard 50] unlinkat ./L1-00000055.tsi: read-only file system"
I believe this is somehow caused by a mount namespace that systemd creates for
the service, but I didn't investigate this deeper.
Fix a typo in the kea-dhcp-ddns-server unit definition, and add a
KEA_LOCKFILE_DIR environment variable without which kea daemons try to
access a lockfile under /var/run/kea path, which is prevented by
systemd's ProtectSystem (or one of the other Protect*) mechanism.
kea-dhcp-ddns-server doesn't react to updates from dhcp4 server at all
without it.
