In reply to @emilazy:matrix.org
I just don't know why you'd want mystery Linux running on a tiny little metal thing when you can run Linux on the thing it plugs into instead

In reply to @charles:computer.surgery
i'm reminded of this article i just saw like 10 minutes ago https://hackaday.com/2025/06/16/an-open-source-justification-for-usb-cable-paranoia/

In reply to @zhaofeng:zhaofeng.li
so you can add some latency that mysteriously appears every other Saturday at 1am? 😈 apart from that, one actually useful thing I can think of is running tailscale on it to provide resilient OOB access to the switches/server IPMI/etc

diff --git a/nixos/modules/config/resolvconf.nix b/nixos/modules/config/resolvconf.nix
index f9c9d04b3fbe..79d3b2043148 100644
--- a/nixos/modules/config/resolvconf.nix
+++ b/nixos/modules/config/resolvconf.nix
@@ -158,6 +158,10 @@ in
 
   config = lib.mkMerge [
     {
+      warnings = lib.optionals (!cfg.enable && cfg.useLocalResolver) ''
+        The resolvconf module was instructed to configure the local resolver (127.0.0.1, ::1) in /etc/resolv.conf, but resolvconf was disabled.
+      '';
+
       environment.etc."resolvconf.conf".text =
         if !cfg.enable then
           # Force-stop any attempts to use resolvconf

In reply to @hexa:lossy.network
emily: roast me

In reply to @alina:kescher.at
can someone please give me some feedback for how to deal with unbound's broken upstream?
https://github.com/NixOS/nixpkgs/pull/417917

right, I am just not sure if services.foo.enable is the place to make the decision about the local resolver, since there are reasons you could want to run unbound or whatever without using it as the local resolver. (and indeed services.unbound.resolveLocalQueries is its own separate toggle albeit on by default)

but I think that if we want to keep that behaviour, then the modules should set networking.resolvconf.enable = mkDefault true; in addition to the current networking.resolvconf.useLocalResolver = mkDefault true;, and then we should ensure that there's an explicit conflict between networking.resolvconf.enable and services.resolved.enable. then you still have an escape hatch but they explicitly express that they expect to be used with resolvconf and we'd get a proper conflict error without the weirdness of looking at networking.resolvconf.useLocalResolver even when the module is turning itself off.

(TBH, I find the !(config.environment.etc ? "resolv.conf") default for networking.resolvconf.enable questionable in general, it's a bit magical/implicit for my tastes.)

(FWIW I don't think that having systemd-resolved front a local resolver is that weird or bad though, so it seems like it would also be fine to lift it to networking.useLocalResolver and add support to the resolved module. like I grant that systemd-resolved is not necessarily great software, but I don't think "run a local recursive resolver, but I do also want mDNS domains to work and my normal-DNS resolver doesn't handle that" is that weird a use case – that kind of thing is why systemd-resolved runs a stub listener at all. I agree that we don't want situations where people expect systemd-resolved to be disabled but it isn't, though)

I am just not sure if services.foo.enable is the place to make the decision about the local resolver, since there are reasons you could want to run unbound or whatever without using it as the local resolver

Same energy as caddy trying to install the self-signed CA into the local trust store by default if it's enabled - I was surprised and a bit annoyed by the behavior