Our App is meant for digital signage, runs 24/7, single-application, and we want to provide easy access for the customer/user to use our App through Snap store.
Here are several functionalities of our App:
Our App needs to be able to do a daily reboot of the device.
Our App needs to view the device information:
Network interface information
It needs to fork a child process and to kill it: This is to invoke a web socket server used for external communications to our App if the user enables it.
Because of that, we need to request auto-connect for these interfaces for our App:
All these interfaces are mandatory to auto-connect for our App, and our customer users don’t have adequate technical knowledge to use CLI at all. Or at least the connection permission should come out as approval to the user during installation (all-or-nothing approach, and if the user rejects any of them, then the App should not be installed at all).
Not directly ties to the auto-connect requests, but might it be easier to use channels on a single snap name rather than three snap names? That is, publish your appspace-app-dev builds as the edge channel of appspace-app, and appspace-app-qa builds as either the beta or candidate channel.
One benefit of this is that if you decide a particular build has passed your QA process, it can be promoted to the stable channel. With different snap names, you would need to rebuild the snap which might invalidate some of the QA work.
We’ll take it into consideration, but currently it does not fit our release process. Because we don’t want to make our App under development to be accessible by public, and our QA has to test before it goes to production public beta and edge channel. The only way we can use it is to make two snaps for our internal QA and dev only. Is it possible to make those Beta and Edge channel to be private that only our internal QA and developer use it?
I’m not sure there is such a feature. Some things that might work:
don’t publish the private builds at all, and install them locally with snap install --dangerous. You would probably need to manually connect interfaces to do this kind of testing.
upload your snaps to the store, but don’t release them to any channels. If you run sudo snap login and provide credentials for a collaborator on the snap, you can use the --revision argument to snap install or snap refresh to install one of these unpublished revisions. Such an install should benefit from store assertions allowing auto-connect.
You souldn’t need process-control to kill other processes that are part of your snap. If you know the server process’s pid, you should be able to kill it without any extra permission.
It’s possible that you’re running into sandbox restrictions if you are trying to use a tool like killall that enumerates all processes on the system and checks their command line. But if you spawned the server, you should know it’s pid.
I tend to agree, but can you provide more details on why they are needed? Eg, you stated “Our App needs to view the device information: CPU information”. Why does your app need to view cpu information? Please do this for each interface.
Thanks for the info - if shutdown and physical-memory-observe are definitely required, these provide quite privileged access and so would likely require publisher vetting (similarly as is done for classic confinement requests).