| 12 Oct 2022 |
 @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 |
|  Kanashi Mia changed their display name from Nirahv Kanashi Mia to Kanashi Mia. | 19:14:18 |
| 17 Oct 2022 |
| @elvishjerricco:matrix.org | How does this look for automatically configuring interfaces? https://github.com/NixOS/nixpkgs/pull/169116/commits/22a7e62a99961c75849f81d8e14328b638440286 | 00:01:03 |
| @elvishjerricco:matrix.org | * How does this look for automatically configuring interfaces? https://github.com/NixOS/nixpkgs/pull/169116/commits/48295a255a11aa29a8d1efe46b07c69b5967044d | 00:28:30 |
| @elvishjerricco:matrix.org | * How does this look for automatically configuring interfaces? https://github.com/NixOS/nixpkgs/pull/169116/commits/2d0fc0feeccc5d18da2a04cc844f68b210b556ef | 00:32:09 |
| 20 Oct 2022 |
| colemickens | So that will use networking.interfaces to auto-configure stage-1 networking? But it doesn't seem to hoist my manually configured systemd networks into the initrd config? It feels like a bit of a mismatch to me (or maybe I've misunderstood some detail and ma getting the wrong impression from building my systems) | 07:18:55 |
| @elvishjerricco:matrix.org | colemickens: well the point of configuring networking.interfaces in stage 1 for compatibility with scripted initrd's networking implementation, and because it's just very convenient. We can't rely on hoisting stage 2 systemd-networkd configs into stage 1 because A) not everyone using initrd networking is using systemd-networkd, and B) not everything you would configure in stage 2 should be configured in stage 1, e.g. wireguard | 07:23:17 |
| @elvishjerricco:matrix.org | * colemickens: well the point of configuring networking.interfaces in stage 1 for compatibility with scripted initrd's networking implementation, and because it's just very convenient. We can't rely on hoisting stage 2 systemd-networkd configs into stage 1 because A) not everyone using initrd networking is using systemd-networkd, and B) not everything you would configure in stage 2 with systemd-networkd should be configured in stage 1, e.g. wireguard | 07:24:03 |
| @elvishjerricco:matrix.org | * colemickens: well the point of configuring networking.interfaces in stage 1 is for compatibility with scripted initrd's networking implementation, and because it's just very convenient. We can't rely on hoisting stage 2 systemd-networkd configs into stage 1 because A) not everyone using initrd networking is using systemd-networkd, and B) not everything you would configure in stage 2 with systemd-networkd should be configured in stage 1, e.g. wireguard | 07:24:15 |
| @elvishjerricco:matrix.org | I suppose it should probably only work that way when boot.initrd.network.enable = true;. i.e. if you just want to manually configure it, you should be able to set boot.initrd.systemd.network.enable = true; and configure it like stage 2, potentially even doing boot.initrd.systemd.network = config.systemd.network; | 07:32:26 |
