Two issues:
1. We need a subjectAltName on the TLS cert. Stolen from the akkoma
test. <3 illdefined
2. There's a bug in the current toot release wrt. date parsing. It's
been fixed upstream but it's not been released yet. Using the
current toot master for this VM test to work around this.
Note: I warned upstream we'd need a new toot release.
Fixes https://github.com/NixOS/nixpkgs/issues/264951
This changes
* the plausible HTTP web server
to be listening on localhost only, explicitly.
This makes Plausible have an explicit safe default configuration,
like all other networked services in NixOS.
For background discussion, see: https://github.com/NixOS/nixpkgs/issues/130244
As per my upstream Plausible contribution
(https://github.com/plausible/analytics/pull/1190)
Plausible >= 1.5 also defaults to listening to localhost only;
nevertheless, this default should be stated explicitly in nixpkgs
for easier review and independence from upstream changes, and
a NixOS user must be able to configure the
`listenAddress`, as there are valid use cases for that.
Also, disable
* the Erlang Beam VM inter-node RPC port
* the Erlang EPMD port
because Plausible does not use them (see added comment).
This is done by setting `RELEASE_DISTRIBUTION=none`.
Thus, this commit also removes the NixOS setting `releaseCookiePath`,
because it now has no effect.
This fixes the case where users enable harmonia but also have allowed-users set.
Having extra-allowed-users is a no-op when nix.settings.allowed-users is set to "*" (the default)
Docker CE 20.10 seems to stop receiving security updates and bug fixes
after December 10, 2023[1].
1. https://github.com/moby/moby/discussions/45104
There is public commitment for longer maintenance and then it seems
risky to default to it during 23.11 life-cycle.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
As it is technically a breaking change, we should at least make a strong deprecation
of `ensurePermissions` and leave it in the broken state it is, for out of tree users.
We give them a 6 months notice to migrate away by doing so, which is honest.
In the meantime, we forbid usage of `ensurePermissions` inside of nixpkgs.
Closes#216989
First of all, a bit of context: in PostgreSQL, newly created users don't
have the CREATE privilege on the public schema of a database even with
`ALL PRIVILEGES` granted via `ensurePermissions` which is how most of
the DB users are currently set up "declaratively"[1]. This means e.g. a
freshly deployed Nextcloud service will break early because Nextcloud
itself cannot CREATE any tables in the public schema anymore.
The other issue here is that `ensurePermissions` is a mere hack. It's
effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how
a value is substituted in a query. You'd have to parse a subset of SQL
to actually know which object are permissions granted to for a user).
After analyzing the existing modules I realized that in every case with
a single exception[2] the UNIX system user is equal to the db user is
equal to the db name and I don't see a compelling reason why people
would change that in 99% of the cases. In fact, some modules would even
break if you'd change that because the declarations of the system user &
the db user are mixed up[3].
So I decided to go with something new which restricts the ways to use
`ensure*` options rather than expanding those[4]. Effectively this means
that
* The DB user _must_ be equal to the DB name.
* Permissions are granted via `ensureDBOwnerhip` for an attribute-set in
`ensureUsers`. That way, the user is actually the owner and can
perform `CREATE`.
* For such a postgres user, a database must be declared in
`ensureDatabases`.
For anything else, a custom state management should be implemented. This
can either be `initialScript`, doing it manual, outside of the module or
by implementing proper state management for postgresql[5], but the
current state of `ensure*` isn't even declarative, but a convergent tool
which is what Nix actually claims to _not_ do.
Regarding existing setups: there are effectively two options:
* Leave everything as-is (assuming that system user == db user == db
name): then the DB user will automatically become the DB owner and
everything else stays the same.
* Drop the `createDatabase = true;` declarations: nothing will change
because a removal of `ensure*` statements is ignored, so it doesn't
matter at all whether this option is kept after the first deploy (and
later on you'd usually restore from backups anyways).
The DB user isn't the owner of the DB then, but for an existing setup
this is irrelevant because CREATE on the public schema isn't revoked
from existing users (only not granted for new users).
[1] not really declarative though because removals of these statements
are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467
[2] `services.invidious`: I removed the `ensure*` part temporarily
because it IMHO falls into the category "manage the state on your
own" (see the commit message). See also
https://github.com/NixOS/nixpkgs/pull/265857
[3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";`
[4] As opposed to other changes that are considered a potential fix, but
also add more things like collation for DBs or passwords that are
_never_ touched again when changing those.
[5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
In #256226, `backdoor.service` was changed to be part of
`sysinit.target` instead of having default dependencies. This broke
several tests that relied on `backdoor.service` starting after default
targets. For example, `systemd-boot.update` expects `/boot` to be
mounted as soon as the backdoor is running.
These tests really ought to be declaring their dependencies properly
with things like `machine.wait_for_unit("local-fs.target")`, because
it's useful for the backdoor to start as early as possible. But for
now, let's just order it the way it was before in stage 2, and use the
earlier ordering in the new stage 1 context.
This fixes the case where users enable nix-serve but also have allowed-users set.
Having extra-allowed-users is a no-op when nix.settings.allowed-users is set to "*" (the default)
8f2babd032 was partially reverted by mistake. Original message below
---
On some systems, EFI variables are not supported or otherwise wonky.
bootctl attempting to access them causes failures during bootloader
installations and updates. For such systems, NixOS provides the options
`boot.loader.efi.canTouchEfiVariables` and
`boot.loader.systemd-boot.graceful` which pass flags to bootctl that
change whether and how EFI variables are accessed.
Previously, these flags were only passed to bootctl during an install
operation. However, they also apply during an update operation, which
can cause the same sorts of errors. This change passes the flags during
update operations as well to prevent those errors.
Fixes https://github.com/NixOS/nixpkgs/issues/151336
In my earlier commit
manual: Don't suggest exposing VM port to local network.
I made a side change titled
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
Unfortunately, that was wrong:
QEMU inside the VM always communicates via the virtualised
Ethernet interface, not via the VM's loopback interface.
So trying to connect to `127.0.0.1` on the VM's side cannot work.
Newer version of the gitsrht-api service call setrlimit() on startup,
thus allow it in the `SystemCallFilter` definition for the service.
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
I changed my nickname from Ninjatrappeur to Picnoir. My github id is
stable, it shouldn't break too much stuff.
I took advantage of this handle change to remove myself from the
hostapd maintainers: I don't use NixOS as a router anymore.
The setting
QEMU_NET_OPTS="hostfwd=tcp::2222-:22"
caused the VM's port 2222 to be advertised on the host as
`0.0.0.0:2222`, thus anybody in the local network of the host
could SSH into the VM.
Instead, port-forward to localhost only.
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
See e.g. https://github.com/NixOS/nixpkgs/issues/100192
for more info why localhost listening is the best default.
Allows passing custom component packages, that get installed into
home-assistant's state directory.
Python depedencies, that are propagated from the custom component
get passed into `extraPackages`, so they are available to
home-assistant at runtime.
This is implemented in a way, that allows coexistence with custom
components not managed through the NixOS module.
Was introduced in dde6a4f397532bbd01b346466ea751e7c3cd9d06
but it doesn't work on my machine:
fwupdmgr[439074]: Failed to connect to daemon: The connection is closed
Creating a persistent user does work however
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
waagent's extension `Microsoft.OSTCExtensions.VMAccessForLinux` requires Python, otherwise it would be failed to install with the following error message in `/var/log/waagent.log`:
```
No Python interpreter found on the box
```
waagent's extension `Microsoft.CPlat.Core.RunCommandLinux` needs lsof, otherwise it would produce the following error message in `/var/log/waagent.log`:
```
/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.10/bin/custom-script-shim: line 60: lsof: command not found
```
I no longer contribute to this test nor do I plan to do so in the
future.
My contributions moved to nixosTests.forgejo, after we (nixpkgs) decided
to split the gitea and forgejo nixpkgs modules.
While this can be added via `services.journald.extraConfig`, this option
provides proper type-checking and other modules can determine
where journal data is stored. This is relevant when using e.g. promtail
to send logs to Loki and it should read from `/run/log/journal` if
volatile storage is used.
If username is set, then unbound will try to become that user using
`setusercontext`. But this is pointless since we are already instructing
systemd to launch unbound with that user.
So force username to be empty, which disables this behaviour in unbound.
This allows us to remove the capability granted, and also tighten the
syscall filter.
Adds a postResumeCommands option to the initramfs to allow inserting
code to execute after the device has attempted to resume, and before
filesystems are mounted. This allows to inject code for operations like
wiping the rootfs on boot; if those were instead put in
postDeviceCommands, on a hibernated device, they would execute before
the device resumes from hibernation.
`environment.variables` gets sourced by shells & the x11 wrapper
through bash's `/etc/profile`, but not by systemd services, dbus
services, wayland sessions...
`environment.sessionVariables` sets these variables with PAM early in
the login process so it gets applied in all contexts.
I ran into a similar issue before in #109060.
upstream is in the process of renaming to `hickory-dns`.
a consequence of this is that the main binary has been renamed from
`trust-dns` to `hickory-dns` and the repository has been moved (though
for the time being the old repo is still usable on account that it
redirects to the new one).
see: <https://bluejekyll.github.io/blog/posts/announcing-hickory-dns/>
Modules built in to the kernel can attempt to load firmware before
init is started. To guarantee the firmware is accessible to them
where they expect, /lib has to exist in the initramfs — it can't be
created later by init, because by that point the module may already
have tried and given up.
The virtualisation.directBoot.initrd option was added for netboot
images, but the assertion to check directBoot enabled if it was used
caused an infinite recursion if it was. Minimal reproduction:
import nixos/tests/make-test-python.nix ({ pkgs, ... }: {
name = "";
nodes = {
machine = { config, ...}: {
imports = [ nixos/modules/installer/netboot/netboot-minimal.nix ];
virtualisation.directBoot = {
enable = true;
initrd = "${config.system.build.netbootRamdisk}/${config.system.boot.loader.initrdFile}";
};
};
};
testScript = "";
}) {}
The fix is to swap the two conditions, so that cfg.directBoot.enable
is checked first, and the initrd comparision will be short circuited.
This wasn't noticed during review because in earlier versions of the
virtualisation.directBoot patch, the assertion was accidentally in the
conditional above, so wasn't evaluated unless port forwarding was in
use.
Aliases exist for a reason. Sure it is nice to make sure that
some aliases aren't used within Nixpkgs, but this creates two problems
which are far worse than your failing to meet your neatness compulsions.
- Users encounter missing attributes, https://github.com/NixOS/nixpkgs/issues/264577
wasting their time, stalling their progress, and even occupying others
time that would be better spent on fixing *real* issues.
- Hydra doesn't treat evaluation errors seriously enough, with the
effect that actual relevant test failures are masked by evaluation
failures such as those caused by this no aliases business.
- We don't even have the infrastructure to get rid of aliases, because
all warnings in package attributes are disallowed by Nixpkgs CI
tooling, last I checked.
Before re-disabling this, make sure that
- An actually helpful deprecation process is in place.
- Aliases are still allowed when `nixos-lib.runTests` and
`pkgs.testers.runNixOSTest` are invoked by external projects.
For instance, `all-tests.nix` could provide such an
override (e.g. with `newScope`).
It hasn't expected the prefix for a long time (possibly ever). Other
documentation and patches within nixpkgs itself (such as the crashdump
module) do not have the prefix.
This changes the syscall filter to match that of upstream. Note that
SystemCallFilter=~foo bar
is completely different from
SystemCallFilter=~foo
SystemCallFilter=bar
The former one means that foo and bar are forbidden, and the latter
one means foo is forbidden and bar is granted!
The PAM service `greetd` creates now autostarts GNOME Keyring when it is
enabled via `services.gnome.gnome-keyring.enable`.
Should cause a lot fewer headaches for people like me who didn't know
why GNOME Keyring was complaining that it was never supplied with login details.
Fixes#246197
In https://github.com/NixOS/nixpkgs/pull/254071, a mismatch between usage of
the Nix language and the NixOS module system was introduced. By merging the
kwin_wayland wrapper attrset into the mkIf representation, the former was
effectively ignored.
As a result, the capability wrapper for kwin_wayland stopped being installed,
leading to realtime scheduling being disabled. The issue was not detected
because the behavioral change is very subtle.
By consistently using language-level constructs, this mismatch is resolved.
The capability wrapper is thus installed again and realtime scheduling is
restored.
