New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undeprecate networking.useDHCP #75515
Comments
@florianjacob: Why the thumbs down? I'm curious why using networking.useDHCP is suddenly a bad idea. Because of networkd somehow? Please explain. |
About a year ago I banged my head against global
If I remember correctly, one main cause is the fact that systemd-networkd does only apply the first network file that matches and ignores all others, which doesn't harmonize with how the (Thumbs down just because I remember it's a good idea not to have that, thumbs up for documenting and explaining why that decision was made and what the problems were.) |
@florianjacob: Thank you. I read the linked issues and have a better understanding of the problem now. If some interfaces must be excluded from networkd control, and a whitelist is preferred, how about this:
This could be the new default and have low priority so that per interface settings win. This should be machine agnostic AFAICT. |
Well, if the above whitelist works, there is actually no need to change the API: useDHCP must simply change from matching all interfaces to the ones starting with "en*" and "wl*". |
IMO there should be a way to override the whitelist, while the boolean true value will make it use the default whitelist a list could override it Also, some machines have eth0, eth1... renamed interfaces, so just relying on "en*" might not work, it should be "e*" |
I remember now I even have a setup with "wan0" and "lan0" interfaces (via udev rule), so even "e*" is not correct/enough. Is there a way to match real hardware interfaces? |
How is the live CD going to be configured without a global |
@bjornfor wouldn't a "*" work for the live iso? |
I think the point was to not match certain interfaces, like the loopback interface ('lo'). But I didn't pick up all the details of the above linked issues, so I could be wrong. |
So there are two related problems at play here. Networkd wants to configure all interfaces it's configured to manageIf there is no carrier or no DHCP response, the interfaces will stay in the This is not something we want to happen to new users or on NixOS upgrades that might switch to networkd by default. Note that most other distributions I'm familiar with don't do DHCP on all interfaces by default but have their installer generate a sensible networking config by some kind of autodetection and asking the user. We're just using dhcpcd cleverly. I think this behaviour only makes sense on install mediums where one cannot assume anything of the target. But on install mediums, IMHO, we should rather let the the user just use network-manager and Specifically, I think the networking configuration should rather be a conscious decision by the user. Either statically via configuration or dynamically via tools like NetworkManager. Users can still configure dhcpcd or networkd explicitly to run DHCP on whitelisted/blacklisted interfaces they deem useful for the job. I was also thinking of allowing wildcards/globs for There is a way though to exclude interfaces from the After researching for my response here again, I noticed that Also note that this way we have a kind of race condition with both dhcpcd and networkd anyway because acquiring an IP via DHCP on one interface does not necessarily mean we also get a default route that might come from another interface. How to match all "uplink" interfaces?Matching for Furthermore, udev exposes the DEVTYPE property which can be accessed via networkd units for matching via But: Even though we might have a sensible selector that works with predictable interface names enabled, we have not yet solved the first problem. ConclusionIt was more sensible for us to remove @bjornfor Does this explain our rationale in a way that makes sense to you? What do you think? |
Closing, as there has been no further reaction and I think @fpletz comment is an adequate answer to the issue. Feel free to reopen if there are further questions! |
@globin: My lack of response was mostly due to lack of time, not because I think this issue is not relevant anymore. In fact, I don't have a lot of time now either, so sorry for being brief. @fpletz: Thank you for the detailed post. Here is my response, as an end user who doesn't know all the details:
That sounds like a perfectly good reason for why things are like they are with networkd, but IMHO not so much for deprecating The move to networkd feels kind of rushed, ref. this issue and #73595. |
@bjornfor Sorry that I didn't make my point clear enough and that I was stressing the move to networkd too much.
If you still disagree about the removal, please come up with a sensible implementation instead. We can then also use that logic with networkd. |
I only saw bugs / edge cases mentioned for the combination of networkd and networking.useDHCP. For networking.useDHCP alone, what's the problem?
Do you mean the |
I don't see a reason to remove |
When #73595 gets fixed, I guess the plan is to run nixos-generate-config when adding/removing network interfaces? (Well, not my plan, but it seems we're heading that way.) I tried nixos-generate-config on my machine and got this:
So the thinking is that networking.useDHCP should be removed because it has a (hidden) blacklist, whereas without a blacklist you get that behaviour like above? I don't think that's an improvement. |
@fpletz isn't the normal behavior that the system tries to get an IP via DHCP and when it don't get one, assign itself a link local address?
Source: https://serverfault.com/a/118329 So, can we get that behavior with networkd? I'm always for sane defaults. Do what the user expects. So we can implement a blacklist logic for interfaces that are configured automatically by other programs, like docker0, tun0, vboxnet0. Someone can ask systemd if the features we need are supported now, or if they will implement them ever? With that information, we can make an informed decision how to proceed here to finish the release. |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/networking-usenetworkd-and-usedhcp/4352/2 |
…s to bridges by default This is an backward incompatible change from upstream dhcpcd [0], as this could have easily locked me out of my box. As dhcpcd doesn't allow to use only a blacklist (denyinterfaces in dhcpcd.conf) of devices and use all remaining devices, while explicitly allowing some interfaces like bridges, I think the best option would be to not change anything about it and just educate the users here about that edge case and how to solve it. [0] https://roy.marples.name/archives/dhcpcd-discuss/0002621.html (cherry picked from commit eeeb2bf)
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/networking-usenetworkd-and-usedhcp/4352/3 |
@fpletz When you mention network manager, are you saying that the global |
Another possible issue to consider: #109389 (comment) (Using Docker on AWS EC2 breaks EC2 metadata route because of DHCP) |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
There are two problems for me with deprecating (and subsequently removing)
IMO there is no full replacement for
Well I see the point but I don't fully agree – the basic idea behind DHCP is zero-config, so it should be possible to fully opt-in to auto-configuration for all physical interfaces. Then, if I add a new ethernet-card/WiFi-dongle, it should have full auto-configuration (even within AFAIK this does not yet work reliably with |
Looks like this issue is about to be solved: #167327 |
Thank you, @lheckemann! 🎉 |
Describe the bug
Using
networking.useDHCP
is deprecated since e862dd6.But:
It seems like a step back to me, having to list machine specific network interfaces in configuration.nix
instead of being able to say "use DHCP (or not) for any interface you see". Also ref. #73595.
I think/hope
networking.useDHCP = true
can be mapped to networkd with something like this (untested):CC @globin.
The text was updated successfully, but these errors were encountered: