| 15 Jun 2025 |
 Luke | I have asked the Moonraker and Fluidd devs if they see a security issue with this pattern - I'll see what they have to say regarding how much of a bad idea this is 😆
If they think it is a bad pattern to support then I will close the PR (and possibly make a flake for my own purposes), otherwise I will respond with more info on the PR | 20:22:27 |
| 16 Jun 2025 |
| Luke | The other thing that is a bit odd is the fact that the Moonraker websocket is currently configured with nginx in the Fluidd service (as well as Mainsail)… that doesn’t quite seem like the right pattern? | 00:40:31 |
| Luke | The websocket and regex parts of this nginx configuration probably belong in the moonraker service? | 00:42:06 |
 hexa | I was today years old when I found out that systemd.network.enable also enables resolved | 03:48:25 |
| hexa | I kinda get that this is required for the DNS-related settings in networkd to work | 03:48:52 |
| hexa | but when you have a proper resolver enabled and they keep fighting over resolv.conf … | 03:49:13 |
| hexa | I wish we could do better, but I fear there is no clear way out | 03:49:29 |
 Zhaofeng Li |
proper resolver
oof
| 03:50:57 |
| Zhaofeng Li | I want to love systemd, but a lot of the non-init pieces are too half-baked. Went all in with the declarative networkd configs but kept running into paper cuts | 03:52:30 |
| hexa | by proper resolver I mean a recursor | 03:53:05 |
| hexa | * by proper resolver I mean a recursor as opposed to a stub | 03:53:11 |
| hexa | one that can actually validate dnssec for dane | 03:53:22 |
| hexa | * one that can actually validate dnssec, e.g. for dane | 03:53:26 |
 emily | resolved can talk to your resolver | 04:20:31 |
| emily | (and provides services like mDNS on top) | 04:20:37 |
| hexa | not interesting for my server | 04:20:58 |
| hexa | * not interesting for my servers | 04:21:03 |
| emily | it's pretty much the supported configuration for better or worse. like, it also provides the D-Bus resolved API etc. and works with the NSS stuff | 04:21:24 |
| hexa | https://github.com/NixOS/infra/commit/67eb34a7534e9caeda495fbbfea50767a23fb8a0 | 04:21:40 |
| emily | you set services.resolved.fallbackDns and ensure UseDNS=no for networks | 04:21:49 |
| hexa | you could also just set services.resolved.enable = false and services.{unbound,kresd,pdns-recursor}.enable instead | 04:22:32 |
| emily | sure | 04:22:39 |
| hexa | they already set networking.dns.useLocalResolver | 04:22:54 |
| hexa | its just not helpful that resolved will fight useLocalResolver | 04:23:15 |
| emily | but I suspect the dependencies on nss-resolve(8) and org.freedesktop.resolve1(5) will likely increase over time, that's all | 04:23:20 |
| emily | path of least resistance and most functionality is to let resolved be the API frontend for your underlying recursive resolver, for better or worse | 04:23:53 |
| hexa | hell no | 04:24:07 |
| hexa | resolved does not perform at all | 04:24:13 |
| emily | part of the problem is that getaddrinfo(3)/gethostbyname(3) are useless APIs that are even more anaemic than other OS's native DNS APIs | 04:24:58 |
| hexa | we have systems at work that will put resolved at 100% cpu with queries and it will not keep up | 04:25:14 |
