Merge ~alfonsosanchezbeato/network-manager:call-netplan-apply into network-manager:snap-1.10

Proposed by Alfonso Sanchez-Beato
Status: Merged
Approved by: Tony Espy
Approved revision: ffc6a971ca1899188971257f6fa6053087b925e6
Merged at revision: 44d02b501a6fe79537000238f92dd02733305ead
Proposed branch: ~alfonsosanchezbeato/network-manager:call-netplan-apply
Merge into: network-manager:snap-1.10
Diff against target: 36 lines (+8/-3)
2 files modified
snap-common/bin/snap-config.sh (+6/-2)
snap/snapcraft.yaml (+2/-1)
Reviewer Review Type Date Requested Status
Tony Espy Approve
Ian Johnson (community) Approve
System Enablement Bot continuous-integration Approve
Review via email: mp+376568@code.staging.launchpad.net

Commit message

Use DBus netplan interface to re-start network services after setting
NetworkManager as the default renderer.

Description of the change

Use DBus netplan interface to re-start network services after setting
NetworkManager as the default renderer.

To test the change, switch the default renderer on a UC18 system:

   snap set network-manager defaultrenderer=true

'networkctl' should show now that all devices are in "unmanaged" state. This will not work on UC16 systems due to a bug in netplan. See https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1855876.

To post a comment you must log in.
Revision history for this message
System Enablement Bot (system-enablement-ci-bot) wrote :
review: Approve (continuous-integration)
Revision history for this message
Ian Johnson (anonymouse67) wrote :

LGTM!

review: Approve
Revision history for this message
Tony Espy (awe) wrote :

The change look good to me, but for some reason I can't seem to build the snap on an 18.04 system using an lxd build (e.g. snapcraft --use-lxd).

Here's the output:
.
.
.
Removing suid/guid from /root/parts/networkmanager/install/etc/chatscripts
Removing suid/guid from /root/parts/networkmanager/install/etc/ppp/peers
Removing suid/guid from /root/parts/networkmanager/install/usr/sbin/pppd
Pulling networkmanager
Pulling networkmanager-common
Building changelog
Building dnsmasq
error: can't open patch '../../../snap-patch/dnsmasq.patch': No such file or directory
Failed to run 'override-build': Exit code was 128.

Revision history for this message
Tony Espy (awe) wrote :

Note, I first tried to build this branch locally and got the above failure, then I tried to just build the tip of snap-1.10 branch. Both fail with the same error.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

@Tony, try using 'SNAPCRAFT_BUILD_ENVIRONMENT=host snapcraft'. I know it is failing when using --use-lxd, but that has happened always and is not related to this MP. We can propose an MP later to fix that.

Revision history for this message
Tony Espy (awe) wrote :

Can you please file a bug to track this?

Revision history for this message
Tony Espy (awe) wrote :
Revision history for this message
Tony Espy (awe) wrote :

So I used multipass to launch a core18 instance, refreshed the core and kernel snaps (with a reboot after each), installed network-manager, connected all of its interfaces (including network-setup-control), then ran:

ubuntu@venerated-surfperch:~$ sudo snap set network-manager defaultrenderer=true
ubuntu@venerated-surfperch:~$
ubuntu@venerated-surfperch:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 eth0 ether routable configured

2 links listed.

Looks like it doesn't work. A quick peek at the snap logs show an Apparmor denial when network-manager tries the send to netplan. Maybe network-setup-control doesn't cover allow sends to the Netplan DBus interface?

---

2019-12-18T00:55:31Z network-manager.networkmanager[1107]: + printf network:\n renderer: NetworkManager\n
2019-12-18T00:55:31Z network-manager.networkmanager[1107]: + dbus-send --system --type=method_call --print-reply --dest=io.netplan.Netplan /io/netplan/Netplan io.netplan.Netplan.Apply
2019-12-18T00:55:31Z network-manager.networkmanager[1107]: Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.9" (uid=0 pid=1233 comm="dbus-send --system --type=method_call --print-repl" label="snap.network-manager.networkmanager (enforce)") interface="io.netplan.Netplan" member="Apply" error name="(unset)" requested_reply="0" destination="io.netplan.Netplan" (bus)

Revision history for this message
Tony Espy (awe) wrote :

Here's the snaps:

ubuntu@venerated-surfperch:/$ snap list
Name Version Rev Tracking Publisher Notes
core18 20191126 1279 stable canonical✓ base
network-manager 1.10.6-3-dev-20191217+ffc6a971 x1 - - -
pc 18-2 36 18 canonical✓ gadget
pc-kernel 4.15.0-72.81 346 18 canonical✓ kernel
snapd 2.42.5 5754 stable canonical✓ snapd

Revision history for this message
Ian Johnson (anonymouse67) wrote :

@Tony can you add denials from system journal as well?

The snapd policy explicitly supports using the D-Bus API, we have tests in snapd for this. See: https://github.com/snapcore/snapd/tree/master/tests/main/fake-netplan-apply and https://github.com/snapcore/snapd/blob/master/tests/main/ubuntu-core-netplan/task.yaml

Also @Alfonso, upstream netplan has this for the dbus call:

https://github.com/CanonicalLtd/netplan/blob/master/netplan/cli/commands/apply.py#L55-L60

Which uses busctl instead of dbus-send, so perhaps there's some difference between dbus-send and busctl? I remember running into issues with dbus-send defaulting to the session bus and busctl defaulting to the system bus or something like that, but you're explicitly setting the system bus so I'm not sure what the issue is.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

@Tony, did you connect network-setup-control? We have not told the store team to connect it automatically yet, you need to do that manually.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

@Ian, busctl requires more permissions than dbus-send, it peeks for some info in /proc. Besides, dbus-send is part of the core snaps so we do not need to include it in the snap. When I tested all worked successfully.

Revision history for this message
Tony Espy (awe) wrote :

@Ian what's weird was I wasn't seeing the apparmor denial in the system journal, it only showed up in the 'snap log' output. Even weirder, is that it seems to be working now in the same VM I created last night.

I'm going to try from scratch one more time...

Revision history for this message
Tony Espy (awe) wrote :

I just re-ran the scenario with a fresh multipass VM, and it still fails the first time. Here are my steps to reproduce:

$ multipass launch core18
[wait for kernel and core snap refresh/reboots]
$ multipass transfer network-manager*.snap <vm-name>
$ multipass shell <vm-name>
---

$ sudo snap install network-manager_1.10.6-3-dev-20191217+ffc6a971_amd64.snap --dangerous
network-manager 1.10.6-3-dev-20191217+ffc6a971 installed
$ sudo snap connect network-manager:firewall-control
$ sudo snap connect network-manager:hardware-observe
$ sudo snap connect network-manager:network-setup-control
$ sudo snap connect network-manager:network-setup-observe
$ snap connections | grep network-manager
firewall-control network-manager:firewall-control :firewall-control manual
hardware-observe network-manager:hardware-observe :hardware-observe manual
network network-manager:network :network -
network-setup-control network-manager:network-setup-control :network-setup-control manual
network-setup-observe network-manager:network-setup-observe :network-setup-observe manual

$ sudo snap set network-manager defaultrenderer=true
$ sudo networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 eth0 ether routable configured

I still see a single AppArmor denial for the dbus-send call.

Now, if I run the set command and change defaultrenderer=false, and then back to true, everything seems to work OK, so my guess is that this is a bug in the snap-config.sh script.

Revision history for this message
Tony Espy (awe) wrote :

OK, I figured it out...

The set-config.sh is script is run by the networkmanager wrapper, so when the snap is first side-loaded, NM is started, and set-config.sh runs *before* I connected the required snap interfaces. It then must leave some state changed, as my 1st call to 'snap set...defaultrenderer=true' is ignored, so dbus-send isn't called. If I call 'snap set...' twice to toggled the renderer to false, and back to true, the right thing happens.

If you concur @Alfonso with this theory, then I'll go ahead and approve.

Revision history for this message
Tony Espy (awe) wrote :

Approving based on previous comment...

review: Approve

There was an error fetching revisions from git servers. Please try again in a few minutes. If the problem persists, contact Launchpad support.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches