| 16 Jun 2025 |
emily | alternatively, lift useLocalResolver outside of networking.resolvconf, have services.resolved.enable either handle it or assert on it | 04:41:09 |
| 17 Jun 2025 |
| jopejoe1 (4094@39c3) changed their display name from jopejoe1 (4094@eh22) to jopejoe1 (4094@GPN23). | 12:06:53 |
Zhaofeng Li | by the way, has anyone tried one of those smart SFP optics? | 15:53:38 |
Zhaofeng Li | not a new thing (might have even mentioned this in this channel), but never really got to give it a try | 15:53:58 |
Zhaofeng Li | * | 15:54:20 |
K900 | Why tho | 15:55:42 |
K900 | Like in most cases they're absolutely evil | 15:55:51 |
K900 | And don't actually do anything your router can't do | 15:55:59 |
K900 | The one exception is PON modems which are just absolutely evil | 15:56:08 |
Zhaofeng Li | well, they are cool and you can probably do some fancy filtering/rewriting even with a dumb switch | 15:57:03 |
emily | 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 | 16:01:11 |
| Autiboy joined the room. | 16:07:47 |
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 | 16:10:55 |
Zhaofeng Li | there are some more ideas: https://blog.benjojo.co.uk/post/smart-sfp-linux-inside | 16:11:08 |
emily | it's an additional point of failure, right? I don't see how it's necessarily more resilient than what you'd run on the switch | 16:16:20 |
Zhaofeng Li | well, not everyone has the luxury of having a Linux-capable (or Linux-accessible) switch | 16:19:32 |
emily | a Linux-capable SFP+ is also its own even rarer luxury, right? :P | 16:20:30 |
Zhaofeng Li | and the power situation is presumably better than a device plugged in separately? | 16:20:33 |
Zhaofeng Li | well, rarer yes, but less expensive and disruptive to the existing infrastructure | 16:21:27 |
raitobezarius | 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 coughs nefarious purposes | 16:35:17 |
Charles | 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/ | 17:07:14 |
raitobezarius | 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/ https://shop.hak5.org/ | 18:02:30 |
Autiboy | Has anyone used NixOS to provision mikrotik routers? | 18:04:09 |
zenware | 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 At best it provides side-band access, out-of-band requires different communication infrastructure. e.g. Wireline/POTS, Radio, ... Such that if your SFP failed, you would still be able to access that system. While, it is kind of cool, by running inside the SFP you're practically more "in-band" than just a cable itself. | 19:39:01 |
| plantfan27 joined the room. | 21:38:05 |
| 18 Jun 2025 |
| @zeromute:matrix.org joined the room. | 00:52:32 |
hexa | 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
| 06:40:23 |
hexa | emily: roast me | 06:40:27 |
hexa | (while I take a nap) | 06:40:32 |
emily | In reply to @hexa:lossy.network emily: roast me do we have precedent for this kind of thing? I feel like it's normal for modules to configure defaults for other modules that might not be enabled (and in general to expect that you can set foo.X harmlessly if !foo.enable). I feel like it would be better for the resolver service modules to either get out of the game of setting the local resolver entirely or to explicitly turn on resolvconf to cause an explicit conflict | 13:43:19 |