Could you please approve the classic confinement for our new release of NiceNode v4.3.0 (snap: nice-node)?
NiceNode is a GUI which installs podman, starts and stops containers for users, allows users to change the volume directory mounts for containers to any file path the user selects in the GUI. Confinement is also needed for users so that if they don’t want to depend on NiceNode to run their containers, then they can copy a run command in the GUI and run containers outside of the app on their own.
thanks @johns Thanks for submitting this request. According to the process for reviewing classic snaps, we require that the request fit into one of the supported categories. Could you please identify if nicenode fits within any of those categories?
Suggestion to use snappy-debug which gives suggestions on required interfaces to work under strict confinement
The category “tools for local, non-root user driven configuration of/switching to development workspaces/environments” applies best as NiceNode installs, configures, and runs containers in a given environment that a user chooses and the user is able to continue using the setup (configuration, running containers, etc.) even if they want to uninstall/remove NiceNode.
I am not sure how this snap actually works, but have you tried docker-support or lxd-support interfaces? and does snappy-debug make any interface suggestions?
Installs Podman - this is similar to installing docker for the user. I can’t find a snap interface that will allow my snap to do this. Podman must be installed at the system level so that users can continue to run their services even if they want to remove/uninstall this snap (no lock-in). From the documentation on docker and lxd interfaces, I do not believe this snaps needs can be achieved.
Gathers detailed system device information - this is used to run detailed requirements checking for the user to see if their system can meet the needs of service that will run in a container. (snappy-debug complains about certain /sys/devices/ and says to adjust program. It provides an interface for some devices like cpu). Examples which snappy-debug says adjust program “/sys/devices/system/cpu/” and “/sys/devices/virtual”.
#1 is my primary concern. Is something like this possible?
Have you tried adding podman as a stage-package ? This way you can ship podman in your snap while staying under strict confinement.
Mmmm this statement is against the snaps confinement model.
There are several hardware and system related interfaces that can give you access to the system info you need. As you mentioned, snappy-debug can help you detect those missing interfaces. So if you plug those and stage podman, you should be able to enjoy the benefits of a stable runtime environment.
Mmmm this statement is against the snaps confinement model.
Yes, I want to prevent “lock-in” for my users and I won’t change my app for this for the time being. I want users to be able to leave or uninstall my app and they can still run their services/containers.
There are several hardware and system related interfaces that can give you access to the system info you need. As you mentioned, snappy-debug can help you detect those missing interfaces. So if you plug those and stage podman, you should be able to enjoy the benefits of a stable runtime environment.
Thank you for recommending this. If the request for #1 gets approved, I can implement the interfaces and ask for any missing ones. However, I don’t want to implement this until I know if #1 is approved. It is hard to invest the time while deb packaging is working well for the time being.
The issue here is that snaps are intended to be fully self-contained. The idea of installing a snap and having it install other programs and leave them behind breaks the confinement model quite fundamentally.
If a user installs nicenode with the goal of running an Ethereum node (which appears to be the primary purpose), we would expect that if they remove the snap, then the node would also be removed.
The only clean way of doing what you want is to either create a podman snap similar to the docker snap that would then provide you an API to spawn containers your nicenode snap could utilize, or switch nicenode to use the existing docker snap (or the lxd snap if that is possible) which already offers such an interface and will keep container instances around even if you remove your snap…
If you would want to actually install podman from your snap as you did envision, keep in mind that snaps have to be installable everywhere, this a a guarantee we give to snap users (which is possible due to the strict confinement rules)…
you would have to actually support installs on gentoo as well as on Slackware, arch, fedora, debian, yocto, you name it… in the end you would have to integrate with every possible package manager in the world, implement error handling for each of them etc, etc … and the podman install code would likely exceed the size of your app code in the end.
Thank you for all the responses and information! Much appreciated.
Apologies, it seems I have mistaken the purpose of snap. Hoping I can support the docker snap interface in the future, but will just keep deb packaging for now.
