System-files usage approval needed for internal company utilities package

store-requests privileged-interfaces
1

To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.

  • name: farmsort-utils
  • description: a set of utilities to be used only internally in our company to set up and configure our robots/machines
  • snapcraft: farmsort-utils/snap/snapcraft.yaml at master · Theuns-Botha/farmsort-utils · GitHub
  • upstream: GitHub - Theuns-Botha/farmsort-utils
  • upstream-relation: This is my own repo at the moment, on my own github account, I am doing the research for Schmiede.ONE though, the company where I work where we may want to start using the snapstore actively
  • interfaces:
    • system-files:
      • request-type: installation
      • reasoning: the primary use-case for the package is to help us set up and eventually reconfigure our development and embedded computers as we develop new versions of our network config, udev rules and system services. We are slowly moving towards fully using ubuntu-core, in which case, this config will be built into the gadget snap, but on our way there we want to already gain some experience in wrapping our applications in snaps and using snapstore deployments in our workflows.

NOTE: I am not sure if this is the only interface I am using that needs approval

2

This request has been added to the queue for review by the @reviewers team.

3

Given that this is to be deployed to help manage your internal company machines, +1 (#voteFor) granting manual-connect to the system-files (usb-udev) interface as this fits the purpose of your snaps description.

Whilst we wait on other reviewers to vote, I’d also recommend partitioning your system-files into multiple logical blocks like:

plugs:
  etc-systemd-system-sclan: ...

  etc-systemd-network-sclan: ...

  etc-udev-rules-usb-can: ...

Just to better group them like the example in the system-files webpage

4

Thanks for the feedback, it is appreciated.

5

A quick question, is this the appropriate route to request these permissions, or should one go via “https://dashboard.snapcraft.io/” or “https://snapcraft.io/”, the multiple entry points are a bit confusing.

6

We usually do not allow direct and unmediated access for either of these three locations in the global store (I’m pretty surprised @cav just waved this request through like this).

Normally you would have to use network-setup-control to talk to netplan in a mediated way for network related adjustments instead of directly dumping a potentially harmful systemd-networkd hack into place.

Instead of directly dropping systemd units into /etc/systemd normally an apps: entry with a daemon: stanza must be used so that snapd has control over their generation (you will also not be able at all to enable these units because your snap will not have access to systemctl, so they will just sit unused in the /etc/sytemd/system dir)

And udev rules are usually also not accepted for anything else than gadget snaps (which in turn require a brand store to be uploaded at all), especially not in the global store …

Given this goes into the global store, accessible by everyone, what happens if anyone installs your snap on a normal PC, how would the udev rule behave on i.e. a fedora/redhat install, an OpenSuSE or Arch system ?

I’m not sure if our approval rules changed this drastically recently, but up to now we have not allowed such intrusive use of system-files in the global store yet (this is specifically why we do have brand stores for the device owners)… @cav can you elaborate if anything changed and I’m just stuck in the past here with my expectations ?

7

I would be happy to use the appropriate mechanisms if they exist. I will for instance now go look into network-setup-control since you think this might help.

In general, as a company who wants to try out these technologies, how are we supposed to iterate towards a full brand-store + gadget snap solution without the opportunity to feel our way into it? I cannot seem to create a brand-store to go the gadget snap route, and trying to create a private snap for this purpose also seems like a dead end.

I ask these questions because I am really interested in the answer, I think that Ubuntu-Core + snaps is a very suitable technology for our usecase, but after lots of reading and experimentation, over a period of months, I have been unable to produce a full workflow to demo to my colleagues, due to all sorts of dead-ends that I run into.

8

There is sadly no such thing like a “Test Brand Store” (yet), but you should at any time be able to build your own dangerous image and side-load a local gadget (or any other app snap) into it for tinkering and testing …

While this won’t get you a full end to end testing with the store you should be able to try out the image against your devices that way at least.

Your udev rule could then go into some app (or config) snap and could be copied from an interface hook at connection time (since you will not be able to do any auto-connection without a brand store).

The network settings should be done via a netplan.yaml in /etc/netplan which the interface I mentioned above grants you access to, documentation for this is in https://netplan.readthedocs.io/en/stable/

And as I said above already the systemd units usually are generated by snapd based on the metadata inside your snapcraft.yaml for daemon entries.

9

Thanks, I appreciate the feedback, I have some exprience with getting systemd services running / configured through daemon snaps, as far as I could tell those systemd services could not be templated though, which is a feature that my solution currently relies upon. Do you perhaps know a way around that?

10

@ogra - you are correct here, that is my bad. Got confused with a couple aspects of the snap. Thanks for the catch!

1 Like