| 12 Oct 2022 |
 colemickens | Does it make sense to say init-networkd is only supported if you also use networkd in stage-2? | 17:40:57 |
| colemickens | and at that point, can you just wholly use the stage-2's networkd config for stage-1, maybe letting the user override it if they wanted to? | 17:41:26 |
 @elvishjerricco:matrix.org | Ehh.... Two problems. 1) We would only want to copy a subset of stage 2 config. For instance we probably can't expect to be able to bring up wireguard netdevs due to a lack of secrets. 2) I'm sure there are people who want to use e.g. NetworkManager in stage 2 but still want to e.g. unlock LUKS remotely in stage 1. | 17:43:02 |
| @elvishjerricco:matrix.org | Aren't NetworkManager and systemd-networkd... a little bit mutually exclusive? | 17:43:21 |
| @elvishjerricco:matrix.org | (I actually do not know) | 17:43:35 |
| colemickens | eh, I think you're right enough either way | 17:44:03 |
| colemickens | on both points | 17:44:11 |
| colemickens | I'll think about it some more, I had forgotten about these things that do seem much more important than special support for openvpn | 17:44:36 |
| @elvishjerricco:matrix.org | I think it'd be great to reuse some subset of stage 2 networkd configuration when possible, but I have no idea what subset we can automatically decide to use | 17:44:39 |
| @elvishjerricco:matrix.org | I mean the obvious answer is "You're the admin; you figure it out" and don't automate it at all, which is kinda the current approach in the PR | 17:45:21 |
| colemickens | "automatically" seems to get hairy the more I think about what that would mean | 17:45:25 |
| colemickens | In reply to @elvishjerricco:matrix.org
I mean the obvious answer is "You're the admin; you figure it out" and don't automate it at all, which is kinda the current approach in the PR are we opposed to that, or that as a starting point? | 17:45:48 |
| colemickens | I didn't find it that unworkable, and I wound up sharing config between stage-1/2 as I found appropriate. It's a bit much, but so is trying to do stage-1 networking imo | 17:46:14 |
| @elvishjerricco:matrix.org | I think there's one bare minimum thing we should probably do: When the user has networking.interfaces.<name>.useDHCP = true, or networking.useDHCP = true, handle it the same way in stage 1 that we do in stage 2, and that's it. | 17:46:50 |
| @elvishjerricco:matrix.org | * I think there's one bare minimum thing we should probably do: When the user has networking.interfaces.<name>.useDHCP = true, or networking.useDHCP = true, handle it the same way in stage 1 that we do in stage 2 for networkd, and that's it. | 17:47:01 |
| @elvishjerricco:matrix.org | Frankly I'm pretty sure that's all we do in scripted stage 1, so that would be feature parity. And it doesn't seem hard | 17:47:19 |
| * colemickens nods | 17:48:31 |
| @elvishjerricco:matrix.org | I could see an argument for wanting to handle boot.initrd.network.flushBeforeStage2 thing, but frankly I'd be perfectly happy with a warning/assertion that says "Yo that's gotta be false now" | 17:49:37 |
 @kranzes:matrix.org | In reply to @flokli:matrix.org
I just pressed the button :-) let's get this in, if it ends up accidentally breaking something, we can always revert. https://nixpk.gs/pr-tracker.html?pr=189676 | 18:53:25 |
 flokli | In reply to @elvishjerricco:matrix.org
I think there's one bare minimum thing we should probably do: When the user has networking.interfaces.<name>.useDHCP = true, or networking.useDHCP = true, handle it the same way in stage 1 that we do in stage 2 for networkd, and that's it. I think the main problem is that we match by name here, not Interface types etc | 18:56:25 |
| flokli | There is semi-sane ways to tell networkd to try to DHCP on real Ethernet links if nothing else is configured | 18:56:57 |
| flokli | You don't need to only match by name. Obviously, doing this on /all/ interfaces no matter what breaks some stuff in odd ways. | 18:57:42 |
| @elvishjerricco:matrix.org | flokli: Right IIRC networking.interfaces.<name>.useDHCP results in a network file that matches the interface name exactly, but networking.useDHCP uses some highly generic glob like en* or something like that | 18:58:39 |
| @elvishjerricco:matrix.org | https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix#L76-L113 | 19:00:16 |
| 14 Oct 2022 |
| @elvishjerricco:matrix.org | Got the auto-interface thing working roughly the same as the old scripted initrd way. It's not super pretty but it's probably good enough. I'll push a commit later after I format the syntax it so I don't look like a lunatic | 08:14:09 |
 Paul Haerle | In reply to @elvishjerricco:matrix.org
I dunno if we want that by default but I could see a configurable option for it I could to a PR against your branch with an option to enable resolved, libnss_dns and cacert certificates and if you want? Or should that be separate options? i.e. boot.initrd.systemd.network.resolvd.enable & boot.initrd.systemd.network.cacertPackage? The later would keep it fairly customizable as in https://github.com/NixOS/nixpkgs/blob/nixos-22.05/nixos/modules/security/ca.nix#L9 | 12:40:15 |
| Paul Haerle | In reply to @elvishjerricco:matrix.org
I dunno if we want that by default but I could see a configurable option for it * I could do a PR against your branch with an option to enable resolved, libnss_dns and cacert certificates and if you want? Or should that be separate options? i.e. boot.initrd.systemd.network.resolvd.enable & boot.initrd.systemd.network.cacertPackage? The later would keep it fairly customizable as in https://github.com/NixOS/nixpkgs/blob/nixos-22.05/nixos/modules/security/ca.nix#L9 | 12:40:23 |
| Paul Haerle | * I could do a PR against your branch with an option to enable resolved, libnss_dns and cacert certificates if you want? Or should that be separate options? i.e. boot.initrd.systemd.network.resolvd.enable & boot.initrd.systemd.network.cacertPackage? The later would keep it fairly customizable as in https://github.com/NixOS/nixpkgs/blob/nixos-22.05/nixos/modules/security/ca.nix#L9 | 12:40:37 |
| 15 Oct 2022 |
|  @tinybronca:sibnsk.net changed their display name from underpantsgnome to underpantsgnome!. | 00:31:24 |
| 16 Oct 2022 |
|  @uep:matrix.org joined the room. | 05:33:25 |
