GNOME Bugzilla – Bug 680909
Manage interface set up outside of NM on user/admin request [danw/disable]
Last modified: 2016-02-15 20:51:48 UTC
Manage interface set up outside of NM on user/admin request This is an extension of . Essentially, this is good for situations when user sets up L1/L2 connection details manually (by creating a bridge or running wpa_supplicant manually for instance) but wants NM to take care of connection on IP level.
Extension of bug 680908.
So we do have some support for this through "Generic" devices, which are ones NM doesn't natively know the L2 details of. These include loopback, GRE, macvlan, macvtap, tun, tap, etc. We want NM to be in a place where it can manage externally created devices but doesn't touch them destructively if they are configured outside NM, but instead picks up these configuration details dynamically.
danw/disable has (old, outdated) patches to make NMDevice:managed be read-write, which basically implements this feature. It would need to be updated for NM_UNMANAGED_FLAGS and probably some other stuff too.
Rebased danw/disable and pushed
This seems more like a 1.0 target if anything, moving there.
Rebased and pushed again. default-unmanaged is a constant source of trickiness, and I think getting rid of it would be a good thing. Also, this feature has now been requested downstream too: https://bugzilla.redhat.com/show_bug.cgi?id=1114685
>> libnm-glib: add nm_device_set_managed() nm_device_set_*() changing the internal state of NMDevice before actually sending the DBUS command. That seems very wrong... anyway. Not related to this patch. >> cli: add "nmcli device manage" and "nmcli device unmanage" could you add bash-completion for this command? rest looks good to me
I keep coming back to the fact that we want NM to be able to manage any device it is capable of managing, but shouldn't be destructive if the user doesn't want. Eventually we should really just get rid of "unmanaged" completely. At least, that's what I'd love to see. I don't think this branch gets us there... What I really want to see from jpirko's use-case is how NM is screwing up whatever he's trying to do outside NM. Then we fix that and make NM not screw that up.
OK, then consider danw/no-default-unmanaged, which drops default-unmanaged, and just lets NMDeviceGeneric be managed instead (which, since we're supposed to be all non-interfering now, should not cause any regressions). The branch ended up involving some random cleanup too so it's worth a review even if we're not ready to drop default-unmanaged right now...
I like the cleanups in danw/no-default-unmanaged a lot. I'd like to do more testing with it next week, but I have no issues with the code in that branch from my review.
(In reply to comment #8) > I keep coming back to the fact that we want NM to be able to manage any device > it is capable of managing, but shouldn't be destructive if the user doesn't > want. Eventually we should really just get rid of "unmanaged" completely. At > least, that's what I'd love to see. I don't think this branch gets us there... > > What I really want to see from jpirko's use-case is how NM is screwing up > whatever he's trying to do outside NM. Then we fix that and make NM not screw > that up. "shouldn't be destructive" is a noble intent at best. As I said in https://bugzilla.redhat.com/show_bug.cgi?id=1114685#c3 : -- NM *does* modify any device it manages. At the very least, it does IFF_UP it, and disable_ipv6. While we might soon get away with leaving disable_ipv6 untouched, NM still will need to up the interface. That alone does qualifies as "interfering". While it might not be an issue for most users, some users want "unmanaged" to really mean "not interfering at all", hence they need this. --
(In reply to comment #11) > "shouldn't be destructive" is a noble intent at best. yeah, and FTR, the current state of danw/no-default-unmanaged breaks "lo". (It ends up losing its IP addresses at some point for some reason; probably on suspend/resume. And then you have to unset disable_ipv6 before you can re-add ::1 on it.) (In reply to comment #10) > I like the cleanups in danw/no-default-unmanaged a lot. Should I go ahead and commit the bits up to "config: drop NMConfigDevice, use NMDevice directly" now?
> config: drop NMConfigDevice, use NMDevice directly such a NMDeviceTest stub seems useful... might be nice to have it in nm-test-utils.h (later). I also think danw/no-default-unmanaged is good.
(In reply to comment #10) > I like the cleanups in danw/no-default-unmanaged a lot. committed the cleanups; the actual no-default-unmanaged changes have issues, as mentioned above
Dan mentioned on IRC to bring this up here but I have found that in my current project (https://github.com/mothran/bunny) as well as other projects: (https://github.com/oblique/create_ap/blob/ec0df440f82e7a0daca10dc1b12a1c85bb47b9d7/create_ap#L242) the ability to grammatically unmanage single devices would be critical for us. Mostly this has to do with wireless interfaces that a application might want to take full control over (ad-hoc, monitor mode, ect). Thanks, -Mothra
*** Bug 743546 has been marked as a duplicate of this bug. ***
Handling of veth devices was refined upstream by bug 731014 (lr/udev-unmanaged-fd731014). Handling of default-unmanaged also gets cleaned up during bug 746566 (lr/default-unmanaged-bgo746566). This renders the remainder of danw/no-default-unmanaged mostly obsolete. I'd say, let's depend this bug to bug 746566, and then close them together.
Created attachment 321311 [details] [review] [patch] danw/no-default-unmanaged Attach the content of danw/no-default-unmanaged branch for history. This branch is obsolete now
with bug 746566 fixed, this bug can be closed as well.
Created attachment 321313 [details] [review] [patch] danw/disable Also attach branch danw/disable here for history