Skip to content
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

Jump to bottom

networkd: don't managed interfaces set up by script #48811

Closed
wants to merge 3 commits into from
Closed

networkd: don't managed interfaces set up by script #48811

wants to merge 3 commits into from

Conversation

dguibert
Copy link
Member

@dguibert dguibert commented Oct 22, 2018 •
edited

Motivation for this change

When using networkd, some weird bugs occur (no ip address, interface down). This patch avoids networkd to manage the interfaces configured by the scripted nixos module.

@fpletz @Mic92

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

@mmahut
Copy link
Member

mmahut commented Aug 20, 2019

Are there any updates on this pull request, please?

@dguibert
Copy link
Member Author

Still helpfull on my system where networking.useNetworkd = true otherwise the routes on virbr0 are lost.

@dguibert dguibert force-pushed the dg/networkd-unmanaged-interfaces branch from f99a409 to cb8b2bf Compare August 21, 2019 13:50
flokli
flokli reviewed Aug 21, 2019
View reviewed changes
nixos/modules/services/networking/zerotierone.nix Outdated
@@ -57,6 +57,7 @@ in

# ZeroTier does not issue DHCP leases, but some strangers might...
networking.dhcpcd.denyInterfaces = [ "zt*" ];
networking.notNetworkdManagedInterfaces = "zt*";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how do adresses appear on these interfaces? Is that all managed by the zerotierone daemon, or would there be a usecase where I'd do that with networkd? In that case, maybe add just a mkDefault here…

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, done and rebased with current master to avoid conflicts.

@dguibert dguibert force-pushed the dg/networkd-unmanaged-interfaces branch 2 times, most recently from 24bd90b to 6e84d5b Compare September 18, 2019 07:36
@dguibert dguibert force-pushed the dg/networkd-unmanaged-interfaces branch from 6e84d5b to 66705c6 Compare September 18, 2019 07:37
fpletz
fpletz reviewed Sep 20, 2019
View reviewed changes
Copy link
Member

@fpletz fpletz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. However, I do not think that this is the best fix going forward. You should instead set networking.useDHCP to false and configure only the interfaces you want. We should eventually make networking.useDHCP = true incompatible with networking.useSystemd = true.

What do you think about that?

@dguibert
Copy link
Member Author

When setting networking.useNetworkd = true, and useDHCP = true, it almost works on a new machine. But if one sets some VPNs (like wireguard/zerotierone/...) that manage interface addresses, networkd should be turn off for these interfaces but the matchConfig.Name=* of the 99-main unit does not turn it off.
This PR ensures that networkd will not interfere on these interfaces.

Maybe when networking.useNetworkd = true, and useDHCP = true, only default wired and wireless interfaces (named like en* and wlp*) should be matched in the default unit 99-main.
Anyway useDHCP will continue to set DHCP=true inside each other network unit for each configured interfaces.

@flokli
Copy link
Contributor

flokli commented Sep 23, 2019

I think we all agree the current wildcard match on everything definitely is too obtrusive.

However, after some thinking, I prefer @fpletz's idea - We can't know all network interfaces we explicitly want to ignore upfront - This is even more the case where people dynamically add interfaces, bridges etc.

Only enabling DHCP on interfaces explicitly specified however might be too unflexible, in the case of live installation media for example.

What about [Match] containing Name=en* wlp* eth* wlan* as suggested, or an appropriate Type= section, in case we want to keep supporting a generic networking.useNetworkd option?

@dguibert
Copy link
Member Author

You're right, hard to know which network interfaces to ignore.

A match containing the whitelist interfaces is more appropriate.

@flokli
Copy link
Contributor

flokli commented Sep 25, 2019

Okay, then let's close this here. I believe there's some work around #69302 going on in providing a less invasive matcher.

cc @arianvp @fpletz

@flokli flokli closed this Sep 25, 2019
@fpletz
Copy link
Member

fpletz commented Sep 25, 2019

Another thing to note here: Matching for wlp* or en* is not enough to cover all potential use case unfortunately. For instance there is also ww* for WWAN devices which in some cases also do DHCP. Additionally, matching with Type= is also not particularly useful because even though it is set to "wlan" for wifi devices, normal ethernet cards don't have a type. (You can check with udevadm info /sys/class/net/<IFNAME> and look for the DEVTYPE property.)

This situation is very unfortunate and doesn't leave us with anything useful to match for to replicate the previous behavior or migrate to a more sensible one for networking.useDHCP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@fpletz fpletz fpletz left review comments

@flokli flokli flokli left review comments

@infinisil infinisil Awaiting requested review from infinisil

Assignees
No one assigned
Labels
6.topic: nixos 8.has: module (update) 10.rebuild-darwin: 0 10.rebuild-linux: 0
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@dguibert @mmahut @flokli @fpletz @GrahamcOfBorg