| 12 Oct 2022 |
 @elvishjerricco:matrix.org | (though I guess that's deprecated isn't it? So we could just not support it with systemd stage 1 networking...) | 17:37:05 |
| @elvishjerricco:matrix.org | Oh there's also boot.initrd.network.flushBeforeStage2, which is true by default with scripted initrd, but systemd-networkd behaves as though it's false right now | 17:38:18 |
| @elvishjerricco:matrix.org |
When systemd-networkd exits, it generally leaves existing network devices and configuration intact. This makes it possible to transition from the initramfs and to restart the service without breaking connectivity. This also means that when configuration is updated and systemd-networkd is restarted, netdev interfaces for which configuration was removed will not be dropped, and may need to be cleaned up manually.
| 17:39:21 |
 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 |
