This fixes a class of errors seen on aarch64 during coredns import where content was seen to be missing ("digest xxx not found") or "failed to get reader from content store" depending on which coredns version was being imported.
With the UMask set to 0023, the
mkdir -p command which creates the webroot
could end up unreadable if the web server
changes, as surfaced by the test suite in #114751
On top of this, the following commands
to chown the webroot + subdirectories was
mostly unnecessary. I stripped it back to
only fix the deepest part of the directory,
resolving #115976, and reintroduced a
human readable error message.
Reverted https://github.com/NixOS/nixpkgs/pull/115228 for kodi to avoid conflict.
It does not look like unzip would be used but not investigating now to speed up merge conflict resolution.
If `openFirewall = true`, but no `firewallFilter` is set, the evaluation
fails with the following error:
The option `services.prometheus.exporters.node.firewallFilter` is defined both null and
not null, in `/home/ma27/Projects/nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix'
and `/home/ma27/Projects/nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix'.
Originally introduced by me in #115185. The problem is that
`mkOptionDefault` has - as its name suggests - the same priority as the
default-value of the option `firewallFilter` and thus it conflicts if
this declaration and the actual default value are set which is the case
if `firewallFilter` isn't specified somewhere else.
In the latest release of mautrix-telegram not all secrets can be set
using environment variables (see https://github.com/tulir/mautrix-telegram/issues/584).
This change allows these secret values to be set without ending up in
the Nix store.
Adding template overrides allows for custom behavior for specific
instances of a template. Previously, it was not possible to provide
bind mounts for systemd-nspawn. This change allows it.
This adds a new internal option, services.slurm.etcSlurm such
that other modules can access slurm's config files. This is
needed, for example, when a service wants to run a slurm command.
This is a major rewrite of the Privoxy module:
- As per RFC0042, remove privoxy.extraConfig and replace it
with a privoxy.settings option, which maps a NixOS freeform
submodule to the Privoxy configuration format.
- Move all top-level options that mirrored a setting to
the real ones in privoxy.settings. This still keeps the
type-checking, default values and examples in places.
- Add two convenience options: userActions and userFilters, which
simplify the operation of creating a file with pkgs.writeText,
converting it to a string and adding it to the actionsfile/
filterfile list.
- Add a privoxy.inspectHttps option to automagically setup TLS
decryption support. I don't know how long have been waiting
for this feature: can't believe it has just happened.
- Also add a privoxy.certsLifetime to control the periodical
cleanup of the temporary certificates generate by Privoxy.
Currently, kernel config options whose value is "yes" always override
options whose value is "no".
This is not always desired.
Generally speaking, if someone defines an option to have the value
"no", presumably they are disabling the option for a reason, so it's
not always OK to silently enable it due to another, probably unrelated
reason.
For example, a user may want to reduce the kernel attack surface and
therefore may want to disable features that are being enabled in
common-config.nix.
In fact, common-config.nix was already silently enabling options that
were intended to be disabled in hardened/config.nix for security
reasons, such as INET_DIAG.
By eliminating the custom merge function, these config options will
now use the default module option merge functions which make sure
that all options with the highest priority have the same value.
A user that wishes to override an option defined in common-config.nix
can currently use mkForce or mkOverride to do so, e.g.:
BINFMT_MISC = mkForce (option no);
That said, this is not going to be necessary in the future, because
the plan is for kernel config options defined in nixpkgs to use a
lower priority by default, like it currently happens for other module
options.
The notification daemon is just one part of XFCE that is, to the best of
my understanding, not particularly related to it being desktop or not —
for instance, not more related than the session manager or the like.
We are running over 6000 tests by now and they take around 5 minutes
on faster machines and tests alot of components that endusers will not
actually be using. It is sufficient if we run them on package upgrades
and in the passthrough test.
This dependency has been added in 65eae4d, when NixOS switched to
systemd, as a substitute for the previous udevtrigger and hasn't been
touched since. It's probably unneeded as the upstream unit[1] doesn't
do it and I haven't found any mention of any problem in NixOS or the
upstream issue trackers.
[1]: https://gitlab.com/libvirt/libvirt/-/blob/master/src/remote/libvirtd.service.in
This will make it easier to track specifically where queries are being
made from (assuming a `log_line_prefix` that includes `%a` in the
postgres configuration).
- Actually run tcsd as tss/tss
- Install a udev rule to set /dev/tpm* permissions
- Remove systemd-udev-settle dependency, use dev-tpm0.device instead
- Use systemd-tmpfiles to set up the state directory
- Add documentation URI to tcsd.service
This module cannot be easily tested with a NixOS test due to the TPM
dependency. Technically, one could be emulated using swtpm[1], but this
is not packaged in Nixpkgs. If you computer has a real TPM you can do a
passthrough in Qemu, but this requires running the VM as root and of
course it's not determinstic:
$ nix build -f nixos vm --arg configuration '
{
virtualisation.qemu.options = [
"-tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/sys/class/tpm/tpm0/cancel"
"-device tpm-tis,tpmdev=tpm0"
];
users.users.root.hashedPassword = "";
services.tcsd.enable = true;
}'
After starting the VM, log in as root, you can check the service has
started with `systemctl status tcsd`.
[1]: https://github.com/stefanberger/swtpm
- Actually use the zfsSupport option
- Add documentation URI to lxd.service
- Add lxd.socket to enable socket activatation
- Add proper dependencies and remove systemd-udev-settle from lxd.service
- Set up /var/lib/lxc/rootfs using systemd.tmpfiles
- Configure safe start and shutdown of lxd.service
- Configure restart on failures of lxd.service
- Use --netlink to avoid systemd-udev-settle[1]
- Run daemon in foreground which is preferred with systemd
- Add unit documentation
- Write ExecStart directly, no need for a script
[1]: 52bbd2b80b
This cropped up, because I have a set-up where my work username is
different to my home desktop username, and I am using a parameterized
config for both, so I have something akin to
config.users.users.default-user = ...;
and using
config.users.users.default-user.{name, home}
in certain places to cope with this. Noticed my home-manager bought in
packages (which use the users.users.<name>.packages hence NixOS issue
not home-manager) weren't present.
The sysfs file /sys/kernel/mm/ksm/run seems to be available as soon as
the kernel has started, so no point in waiting for udev to "settle". If
for some reason it doesn't, we let the unit fail explicitly.
To make it easier to start and stop all GitLab services, introduce
`gitlab.target` which wants all services (meaning they will start with
it) and which all services are part of (meaning they will stop with
it).
Make the config initialization script run in gitlab.service's PreStart
section into two new services, `gitlab-config.service` and
`gitlab-db-config.service`. Other services can then depend on the
config scripts they need instead of unnecessarily depending on
`gitlab.service`. This makes the reason for the configured service
dependencies much clearer and should also reduce the restart time of
the `gitlab` service quite a lot, when triggered manually.
Also, set up stricter service dependencies, using `bindsTo`, to ensure
that if a service fails or is stopped, its dependants are also
stopped. For example, if we're using the `postgresql` service and it's
stopped, `gitlab.service` and `gitlab-sidekiq.service`, which depend on
it to function, should also be stopped.
Launching a container with a private network requires creating a
dedicated networking interface for it; name of that interface is derived
from the container name itself - e.g. a container named `foo` gets
attached to an interface named `ve-foo`.
An interface name can span up to IFNAMSIZ characters, which means that a
container name must contain at most IFNAMSIZ - 3 - 1 = 11 characters;
it's a limit that we validate using a build-time assertion.
This limit has been upgraded with Linux 5.8, as it allows for an
interface to contain a so-called altname, which can be much longer,
while remaining treated as a first-class citizen.
Since altnames have been supported natively by systemd for a while now,
due diligence on our side ends with dropping the name-assertion on newer
kernels.
This commit closes#38509.
systemd/systemd#14467systemd/systemd#17220https://lwn.net/Articles/794289/
The BGRT theme is probably a close as to "FlickerFree" we can
get without https://github.com/NixOS/nixpkgs/pull/74842.
It's more agnostic than the Breeze theme.
We also install all of themes provided by the packages, as it's possible
that one theme needs the ImageDir of another, and they're small files
anyways.
Lastly, how plymouth handles logo and header files is
a total mess, so hopefully when they have an actual release
we won't need to do all this symlinking.
A function is more appropriate for this use. See
http://mywiki.wooledge.org/BashFAQ/050 for reference.
Also, we don't need to run the service as root: since we essentially
run all commands as `services.postgresql.superUser` anyway, the whole
service can just run as that user instead.
Change the default SMTP port to `25`, to better match the default
address `localhost`. This gets rid of some error outputs in the test,
where it fails to connect to localhost:465.
Also, don't enable postfix by default unless it's actually useful to
us.
This removes all the subdirectories in `config` on start.
From one version of GitLab to the next, the files in the `config`
directory changes. Since we're only overwriting the existing files
with ones from the repo, cruft sometimes gets left behind,
occationally causing issues.
Ideally, all configuration put in the `config` directory is declared
by NixOS options and we could just remove the whole directory on
start, but I'm not sure if that's the case. It would also require a
little bit of additional rework and testing. The subdirectories,
however, should seldom contain user configuration and the ones that
frequently does, `initializers`, is already removed on start.
ChangeLog: https://nextcloud.com/changelog/#latest21
* Packaged 21.0.0, test-deployed it to my personal instance and tested
the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file
management).
* Bumped the default version for unstable/21.05 to `nextcloud21`. Since
`nextcloud20` was added after the release of 20.09 (and thus the
default on 20.09 is still `nextcloud19`), it's now needed to upgrade
across two majors.
This is not a problem though since it's possible to upgrade to v20 on
20.09 already and if not, the module will guard the administrator
through the upgrade with eval warnings as it's the case since 20.03.
* Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
This allows Plymouth to show the “NixOS 21.03” label under the logo at
startup like it already does at shutdown.
Fixes#59992.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
It's a dull and boring day, it's cold outside and I'm stuck at home: let
me tell you the story of systemd-vconsole-setup.
In the beginnings of NixOS[1], systemd-vconsole-setup was a powerful
sysinit.target unit, installed and running at boot to set up fonts
keyboard layouts and even colors of the virtual consoles. If needed, the
service would also be restarted after a configuration change, consoles
were happy and everything was good, well, almost.
Since the service had no way to specify the dependency "ttys are ready",
modesetting could sometimes happen *after* systemd-vconsole-setup had
started, leaving the console in a broken state. So abbradar worked
around that by putting a systemd-udev-settle `After=`.
In the meanwhile, probably realizing their mistake, systemd added a
shiny udev rule to start the systemd-udev-settle at the right time[2].
However, the rule bypassed systemd by directly running the binary
`systemd-udev-settle`, and the service - though still installed - fell
into disuse.
Two years would pass before a good samaritan, seeing the poor jobless
systemd-udev-settle service, decided to give it the coup de grâs[3] by
unlisting it from the installed units.
This, combined with another bug, caused quite a commotion[4] in NixOS;
to see why remember the fact that `WantedBy=` in upstream units doesn't
work[5], so it had to be added manually in cc542110, but while systemd
removed it, the NixOS unit continued to install and restart the service,
making a lot of fuss when switching configuration.
After at least thee different tentative fixes, deedrah realised[6] what
the root cause was and fpletz put the final nail[7] in the coffin of
systemd-udev-settle. The service would never see the light of a boot
again, NixOS would not restart it all the time but thanks to udev
consoles would still get their pretty fonts and playful colors.
The En..
..no, wait! You should ask what came of systemd-udev-settle, first.
And why is the service even around if udev is doing all the work?
Udev-settle, like the deceitful snake that he is, laid hidden for years.
He looks innocuous doesn't it? A little hack. Only until it leaves his
den and a poor user[8] drops dead. Obviously, it serves no purpose, as
the service is not part of the boot process anymore, so let's remove it
for good!
About the service, it may not be useful at boot, but it can be started
to pick up changes in vconsole.conf and set the consoles accordingly.
But wait, this doesn't work anymore: the service is never started at
boot (remember f76d2aa6), so switch-to-configuration.pl will not restart
it. Fortunately it can be repaired: here I install a new unit which
does *nothing* on start, but restarts the real service when reloaded.
This perfectly reproduces the original behavior, hopefully without the
original bugs too.
The End?
[1]: cc54211069
[2]: f6ba8671d8 (diff-84849fddcef81458f69725dc18c6614aade5c4f41a032b6908ebcf1ee6740636)
[3]: 8125e8d38e
[4]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470
[5]: https://github.com/NixOS/nixpkgs/issues/81138
[6]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470#issuecomment-330930456
[7]: f76d2aa6e3
[8]: https://github.com/NixOS/nixpkgs/issues/107341
Renaming an interface must be done in stage-1: otherwise udev will
report the interface as ready and network daemons (networkd, dhcpcd,
etc.) will bring it up. Once up the interface can't be changed and the
renaming will fail.
Note: link files are read directly by udev, so they can be used even
without networkd enabled.
Say this 10 times so I don't forget:
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
I'm sorry guys.
It was introduced in c10fe14 but removed in c4f910f.
It remained such that people with older generations in their boot
entries could still boot those. Given that the parameter hasn't had any
use in quite some years, it seems safe to remove now.
Fixes#60184
4255954d97 set the StateDirectory to 0750,
but nginx wasn't in the Mastodon group. This commit also deletes a line,
that probably was intended to serve this purpose, but makes no sense.
Why should the Mastodon user be added as an extraGroup to the nginx
user?
Ensure that the HyperV keyboard driver is available in the early
stages of the boot process. This allows the user to enter a disk
encryption passphrase or repair a boot problem in an interactive
shell.
The `--apis=` command line parameter passed to Jitsi Videobridge is
required to monitor a Jitsi Meet instance for example via the prometheus
exporter [jitsiexporter](https://git.xsfx.dev/prometheus/jitsiexporter).
@thelegy writes:
unitOption is only used inside of attrsOf wich is perfectly capable of
handling the attrsets from mkIf, though the checkUnitConfig test
forbids it.
This commit weakens that restriction to allow the usage of mkIf inside
of systemd.services.<name>.serviceConfig.<something> etc.
While I personally don't like that we can't easily use
pushDownProperties from the module system and need to rely on internals,
we *already* use internals for the mkOverride case, so adding another
case for mkIf doesn't add a hard-to-find indirection.
I'm merging this, since this fixes a valid use case and it shouldn't
make refactoring worse than before.
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
`unitOption` is only used inside of `attrsOf` wich is perfectly capable of
handling the attrsets from `mkIf`, though the checkUnitConfig test
forbids it. This commit weakens that restriction to allow the usage of
`mkIf` inside of `systemd.services.<name>.serviceConfig.<something>`
etc.
Account for the fact that, when creating a lua package without the
"withPackages" helper, we dont get an extra "lua" attribute in the
package.
Therefore we need to distinguish between the "withPackages" case and the
direct ( or "empty" ) lua package.
For example with this nixos config:
```nix
{
services.httpd = {
enable = true;
package = pkgs.apacheHttpd.override {
luaSupport = true;
lua5 = pkgs.lua5_3.withPackages (ps: with ps; [ luafilesystem ] );
};
};
}
```
Here we say that we want to have apache to use a lua, packaged with the
`luafilesystem` module so that we can `require` that in scripts to
render http responses. There, the set that gets assigned to `lua5 ` does
not have a `luaversion` attribute, rather it has a `lua` attribute
wherein lies a `luaversion` attribute. If we dont package additional
modules, then we dont have that `lua` attribute in between and rather
directly have to use `luaversion` directly.
