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:
CPU information
Hardware information
Storage information
Network interface information
OS information
Memory 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:
Hardware-observe
Network-observe
System-observe
Shutdown
Mount-observe
Physical-memory-observe
Process-control
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).
moved it to the correct category (store-requests) ⌠the âsnap-requestsâ category is for asking that someone creates a snap of some upstream sowftware âŚ
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.
Our customer will always let their signage devices to run 24 hours in other place across office branches and countries for announcement and marketing purposes.
shutdown: We need to do a daily reboot of the signage device
process-control: We need to spawn a child process to start NodeJS Websocket server and to kill it
physical-memory-observe: We need to query memory usage, free and availability
If you have any questions, further enquiry or in case of missing information - just ping us!
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.
This is unusual for a snap in the public store. Are you using Ubuntu Core as the OS for your signage device? If so, have you considered using gadget.yaml to auto-connect the interfaces?
Our customer needs to extract those information from geographically-distributed signage devices through a centralized server for inventory and monitoring purpose.
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).
@iko.darius thanks for responding - ok, then +1 from me for auto-connect of shutdown and physical-memory-observe too assuming more formal publisher vetting is done by the @advocacy team.
Regarding the timeline for vetting, the @advocacy team should be able to clarify but usually this is pretty quick from what I understand.
Could other @reviewers also please vote for these 2 interfaces?
