Classic Confinement for wtfutil

[jdstrand]

Thank you for the additional details!

@FelicianoTech

expand on “pulls in data from various APIs as well as local commands”

I mean that it calls various APIs (typically via curl) and runs many local commands/binaries. As of right now, the command list for Linux consist of:

• git rev-parse --abbrev-ref
• git status --porcelain
• hg branch <a path>
• hg status <a path>

This could be handled by home and removable-media (and possibly personal-files depending on the use of $HOME wrt .git and .hg). You would stage-package git and mercurial.

@FelicianoTech

• who -us

This would need a new interface or an adjustment to an existing one, perhaps system-observe.

@FelicianoTech

• lsb_release -a

You might want to parse /etc/lsb-release directly, though you might be able to get away with staging lsb-release.

@FelicianoTech

• nmcli -t -f in-use,security dev wifi
• nmcli device show

You can stage network-manager and plugs the network-manager interface.

@FelicianoTech

• ufw status

You can stage ufw and plugs the firewall-control interface.

@FelicianoTech

• upower -e
• upower -i target

You stage upower and plugs upower-observe.

@FelicianoTech

• pmset -g ps

I’m unfamiliar with this command and command-not-found isn’t helping me. You would need to ship this in your snap but googling suggests it is OS X specific.

@FelicianoTech

Can we find interfaces for all of these? Manually added by the user?

My two concerns here is that

1. The number of interfaces needed, if they need to be manually added, is very cumbersome for the user.
2. If you take a look at the repository, wtf is a very active repository that’s constantly getting new PRs and new contributors. This list of binaries and commands can rapidly change via additionals, removals, etc. How well is that going to play with interfaces once a strict snap is published with a set of interfaces that will change a few times a year? Last I remember it’s not easy to add onto the snap later.

A great example of this is that there’s a PR open right now that’s attempting to change the commands being used by the WiFi module.

The snap developer declares what interfaces should be used by the snap, not the user. Some interfaces are manually connected, some auto-connected. We have a process for requesting auto-connection such that when granted your users need only ‘snap install wtfutil’ and everything works.

@FelicianoTech

Does the dashboard run as root or use sudo?

Both. By default it’s going to run as your own user. Since some of the modules contain commands that need root access ( ufw status for example), they provide instructions on how to run as root as well.

You would need to change things a little bit since snaps aren’t allowed to call sudo directly. Users could either invoke wtfutil with sudo, or you can create a daemon in your snap that listens on a socket which can run these commands. wtfutil then talks to this daemon over the socket instead of calling ufw/etc directly. You would want to put some mechanisms in place in the daemon to perhaps verify the connecting process’ uid, lookup the supplementary groups and verify it is in an approved list so as not to allow arbitrary processes to talk to your snap and run the commands. Other options are possible.

In summary, snapd supports everything you listed (except who, which I’ve taken a todo to add to snapd 2.43 (the next release)). It will take a bit of work to convert it over, but each of the commands you gave is something other snap developers have done (again, except who).

When developing your strict mode snap, you might be interested in snappy-debug. It will provide suggestions for things to plug as your snap is running. Good luck and feel free to ask questions in the snapcraft category.