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.
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`).
