Previously we allocated subuids automatically for all normal users.
Make this explicitly configurable, so that one can use this for system
users too (or explicitly disable for normal users). Also don't allocate
automatically by default if a user already has ranges specified statically.
When startWhenNeeded is enabled, a brute force attack on sshd will cause
systemd to shut down the socket, locking out all SSH access to the machine.
Setting TriggerLimitIntervalSec to 0 disables this behavior.
a few things should've used buildPackages/nativeBuildInputs to not not require
the host architecture for building docs. tested by building aarch64-linux docs
on x86_64-linux, and the result looks good.
In https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/153
the user target names for GSD components has been renamed for example
from `gsd-a11y-settings.target` to `org.gnome.SettingsDaemon.A11ySettings.target`,
and nowadays `gsd-*.target` are just symbolic links of `/dev/null` and will be
removed in the future.
At the same time, as mentioned in d27212d466,
we are adding `systemd.user.targets.<name>.wants` stuff here only because
systemd.packages doesn't pick the .wants directories. Nowadays those GSD components
are managed in `/etc/systemd/user/gnome-session@gnome.target.d/gnome.session.conf`
so it should be safe to remove them.
In this commit we also try to pick up those new .wants directories, see also
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/41.0/plugins/meson.build#L57
Result of `cd /nix/store/iqzy2a6wn9bq9hqx7pqx0a153s5xlnwp-gnome-settings-daemon-41.0; find | grep wants`:
```
./share/systemd/user/gnome-session-x11-services-ready.target.wants
./share/systemd/user/gnome-session-x11-services-ready.target.wants/org.gnome.SettingsDaemon.XSettings.service
./share/systemd/user/gnome-session-x11-services.target.wants
./share/systemd/user/gnome-session-x11-services.target.wants/org.gnome.SettingsDaemon.XSettings.service
```
Result of `cd /nix/store/armzljlnsvc1gn0nq0bncb9lf8fy32zy-gnome-settings-daemon-3.34.0; find | grep wants`:
```
./lib/systemd/user/gnome-session-initialized.target.wants
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-a11y-settings.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-color.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-datetime.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-power.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-housekeeping.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-keyboard.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-media-keys.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-screensaver-proxy.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-sharing.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-sound.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-smartcard.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-wacom.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-print-notifications.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-rfkill.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-wwan.target
./lib/systemd/user/gnome-session-x11-services.target.wants
./lib/systemd/user/gnome-session-x11-services.target.wants/gsd-xsettings.target
```
This never configured where SNI should log to, as it's up to the user to
provide the full sniproxy config (which can be configured to log to a
file).
This option only produced a ExecStartPre script that created the folder.
Let's use LogsDirectory to create it. In case users want to use another
directory for logs, they can override LogsDirectory or set their own
ExecStartPre script.
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.
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.
