The new core18 is quite a bit smaller than core16 was. This is due to it shipping a lot less binaires inside.
While this is a good move towards a leaner Ubuntu Core, it also results in degraded functionality.
Recently vim-tiny was added back since having a usable editor inside an Ubuntu Core install is rather essential for development and a vim snap would only be able to edit files in home or somthing bind-mounted into /media (Ubuntu Core does not allow classic snaps for obvious security reasons)
@abeato brought up that the ping binary is missing. Given that ping is a suid binary you can not easily package it as a snap …
The above shows we are missing quite a bit of things that used to be available in core16, wrapper scripts and configure hooks might depend on some binaries that are not there anymore (i think we should look on a case by case base whether binaries should be re-included in core or if the packager shoud be advised to simply ship the missing pieces in stage-packages (potentially causing a lot duplication).
I started this thread to get us a list of things that are absolutely necessary to still have available but that are not yet included so we can sort these bits before Ubuntu Core 18 goes stable.
pppd, which is not in UC18, used to be part of UC16. The network-manager snap depends on this binary, but it could (and should) be easily included there. But I wonder if others depend on this one being SUID.
the other question about pppd is if the interface then still works … in core16 the ppp interface gives you rw access to /etc/ppp and all related bits … if you ship pppd inside another snap the interface wouldnt work anymore i suppose.
no, snapd has been split out of core for core18, there’s a separate snapd snap for it for core 18 systems, and later at least all classic system will also be migrated to that setup, it should be transparent to snaps tough
@mvo pointed out there are significant differences between stable and edge, so here is another list made from core18 edge (which looks a lot better indeed):
Here’s my take on the some of the binaries already mentioned:
rfkill - This is standard system tool which is used to manipulate the killswitches of any wireless devices present on the system (ie. bluetooth, WiFi, …). It doesn’t feel right to require this to be included in application snaps.
ping - This is one of the first tools anyone turns to when trying to diagnose network problems, so my vote would be to restore it.
console-conf & netplan - AFAIK these are the standard tools used to configure Ubuntu Core systems on first boot, so I agree that these should restored.
pppd - Unless there’s a well-defined/common use case for this besides support of NetworkManager, I think it’s reasonable to leave it out, and include it in the network-manager snap (or other snaps as needed).
I’ll also ask that wpa-supplicant be restored. In addition to NetworkManager’s dependency, simple WiFi connections as supported by netplan also require it. Although there is a Canonical published wpa-supplicant snap, it was only meant to be a temporary solution to support an OEM WoWLAN scenario for UC16.
I pushed two PRs to add ping and rfkill back. console-conf and netplan are in the beta core18 snap already. I agree about pppd, lets see if we can put that into the network-manager snap.
IIRC the reason for shipping pppd from core originally was that it has some hardwired bits in it (/etc/pap-secrets|chap-secrets, various bits in /etc/pppd) that are not configurable for security reasons… if you do not want to ship it from the core snap you will likely need to patch it …
also what about wpa-supplicant that tony mentioned above ?
we can not really force everyone to ship NM just to get a wlan connection (which nplan provides just fine today as long as wpa-supplicant is there) on low end devices.
That’s a bit of a weak argument, in the sense it’s subjective and we can say that about pretty much any application. Ideally the discussion around when/whether to include specific applications would be more pragmatic, and present actual problems of not including it.
I’ve never used rfkill by hand. Who requires it and why? It’s pretty small, so not a big deal, but let’s try to at least pinpoint a better reason to having it in.
That sounds fair. Per the guidelines above, the issue here is that the application actually won’t need it, but people will need it in the base to be able to figure out general connectivity issues.
+1 for this one on that basis.
This one is curious. How do we even have an image if they are not in there? I’m probably missing something, so won’t vote either way.
Agreed: -1 until we have better rationale to evaluate it.
i think tony was just looking at the pastebin from stable, the second pastebin (from the edge core18 snap) i posted above lists both of them, this is a non-issue once edge moves to stable.
i’d expect the same person that uses netplan directly to configure the network to also expect to be able to block/unblock devices … but …
… that said … i just took a look at the network-control interface code and while it provides access to /dev/rfkill and to all possible network tools one could imagine in /sbin and /usr/sbin, the rfkill binary is actually not in that list, so /usr/sbin/rfkill in the core snap could actually never be used from any snap through an interface anyway.
OTOH, if you are logged in via ssh and want to disable bluetooth or wifi from the console, you need the rfkill binary (it might fall into the same category as ping).
