| Summary: | systemd-networkd: net.ipv4.conf.default.forwarding is ignored in 219 | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Alex Crawford <alex.crawford> |
| Component: | general | Assignee: | Tom Gundersen <teg> |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | fdbt-ba, james, matt, mike, radek |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Alex Crawford
2015-03-10 01:46:27 UTC
Yeah this was an underdocumented change in 219: we manage the IP forwarding setting per interfac now. You have to set IPForward=yes in the .network files explicitly now, otherwise you will not get IP forwarding on that interface. (In reply to Lennart Poettering from comment #1) > Yeah this was an underdocumented change in 219: we manage the IP forwarding > setting per interfac now. You have to set IPForward=yes in the .network > files explicitly now, otherwise you will not get IP forwarding on that > interface. Intentional or not from your perspective, from our perspective it is a regression because networkd is now overriding sysctl which up until 219 was the only mechanism for providing those settings. Although distros can update any .network files we ship to update this appropriately there isn't a practical way migrate user provided configs to the new semantics safely. The interaction between net.ipv4.conf.all.* net.ipv4.conf.default.* and net.ipv4.conf.<if>.* can depend on the timing of systemd-sysctl.service, any scripts or other services that may alter those settings, and the discovery of network devices by the kernel. We could probably some up with some script to make an educated guess and run that before the new networkd starts but it is going to be prone to error. Without a safe migration path we simply cannot ship a networkd with this behavior without breaking some subset of our user's systems. I'm open to other ideas but the best scheme I can think of is to turn `IPForwarding` into a trinary value where the default "unset" or "kernel" or whatnot value leaves the setting untouched. (In reply to mike@marineau.org from comment #2) > I'm open to other ideas but the best scheme I can think of is to turn > `IPForwarding` into a trinary value where the default "unset" or "kernel" or > whatnot value leaves the setting untouched. I figure I'd be Ok with such a change. But Tom has to sign off too! (In reply to Lennart Poettering from comment #3) > (In reply to mike@marineau.org from comment #2) > > > I'm open to other ideas but the best scheme I can think of is to turn > > `IPForwarding` into a trinary value where the default "unset" or "kernel" or > > whatnot value leaves the setting untouched. > > I figure I'd be Ok with such a change. But Tom has to sign off too! Nick Owens wrote a patch to implement this but it needs documentation updates: https://github.com/coreos/systemd/commit/930ab8adedbcc64b128d4dd9aaa3c53d79fd9b54 Also, the if check should be inside the link_set_ipv4_forward() call and cause an early exit, instead of link_configure... Either way, Tom really needs to sign off on this. *** Bug 89491 has been marked as a duplicate of this bug. *** > we manage the IP forwarding setting per interfac now. You have to set > IPForward=yes in the .network files explicitly now, otherwise you will > not get IP forwarding on that interface. I would suggest that a less "invasive" approach, more compatible with the traditional sysctl, would be to have systemd-networkd default to _not_ configuring per interface forwarding, and then to _dis_able per interface forwarding by specifying "IPForward=no" in the .network files, when desired. > this was an underdocumented change in 219 For the future, a bit of warning can help avoid "breakage" and unnecessary work. I agree that a 'kernel' option makes sense to handle backwards compatibility, in the ideal future it should not be used though, so I think we should still default to 'no'. Yup, this change should have been mentioned in the release notes, that was an oversight. well, if the "kernel" is not the default value, there's no backwards compatibility. i agree with james that if ipforward is not specified, systemd should just NOT touch the current (default) setting. it should do so only if you specifically select either yes or no. github PR has been merged. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.