There are different ways to implement this and it is true that we cannot gives snaps access to systemctl without giving them device ownership, but I interpreted @ondra’s request as: allow snaps the ability to restart their own daemons, and this could be exposed via snap/snapctl which will talk to the out-of-process snapd. snapd is then in a position to mediate the requested action against the security label of the process running snapctl/snap (ie, via libapparmor) rather than just passing the options straight through to systemctl.
This idea would work well on all systems that have partial or full apparmor support, but not on systems with no apparmor support (however, on those systems, snaps can simply use systemctl directly, so no practical difference in terms of security today).
We already have service management in “snap” and since snapctl will only operate inside hooks proxied through “snap set/get” i dont see why snapctl itself needs full systemctl capabilities beyond automatically restarting a service if a config option changes via get/set.
Instead of requiring the developer to explicitly add “snapctl stop … process variable change … snapctl start” in the hook it would be way cooler if the service restart happens automagically if the var changes without having the developer to explicitly add such stop start commands.
I agree with @jdstrand here, my understanding of @ondra’s request was the same, i.e. give snaps the ability to control (restart) own services only.
The idea of making this automated based on some mappings may look tempting, but I think it would only work for simple cases and not for more sophisticated scenarios where restarts need to actually be guarded by some logic; therefore I think “manual” control via snapctl is more useful.
@ondra That’s planned and in fact most of the work has landed already with the implementation of snap start/stop/restart.
@pstolowski Do you want to push forward the implementation of the snapctl side? Should be relatively quick since most of the internal details have been nailed already.
@niemeyer I’m happy to take it, but from the conversations we had on IRC earlier this morning it seemed that @chipaca is going to implement exactly this for snapctl side. John, can you clarify?
@pstolowski Right, exactly. As I said above it was already planned and most of the work has landed. @chipaca has quite a few things on his plate, so the point was that if you want to push it forward sooner, that sounds reasonable too.
Naturally, talk to him so we don’t have the same thing done twice.
I believe that “snaps” have a promising future as a clear and easy way of packaging. Unfortunately, at my workstation (Ubuntu 16.04) few snaps work because my user belongs to Active Directory and snaps are unable to communicate with the SSSD service.
After more testing with this, I realise to take full advantage of this feature, can we add also enable and disable options?
I’ve came across snap, with optional service, which should be run based on configuration.
Rather that start stop it from service based on settings, configure hook would be ablate to enable/disable it based on settings?
Also can I even call snapctl stop from service itself, or this is only permitted from configure hook? As with this restriction I’d not be even able to stop service in easy way. Unless calling snapctl set stopme=now and stopping service from configure hook
@ondra The service-related commands in snapctl work from any place inside the snap, not just the configure hook. You can also enable/disable by using the options –enable and –disable for the start and stop commands, respectively.
@niemeyer sweet, that should should address the use case.
I will look more into –enable and –disable for the start and stop commands. it definitely looks like something I want to use more
thanks
Dunno what you mean by “by the daemon” but best way is to control services from configure hook
Here is one example wekan
If you want to control this from another service, you can call snapctl set = which will trigger configure hook where you can start/stop/restart/enable/disable daemons…
@ondra I presume when you say ‘from another service’ it means another service from with in the same snap right ? If that is the case , if there a way to control the start/stop/restart of a service of one snap from another snap ? Thanks.
So you will need to use content interface to create connection between snaps here so snapctl is executed in context of snap running those services. It’d break confinement if one can control services of different snap.
Of course ideal solution here would be interface allowing one snap altering configuration settings of another snap
Sort of light content share… restricted only to configuration settings/
Then you can just implement configure hook in receiving snap and snapctl set in client snap
@pstolowski do you know is there is something like this in works or in backlog?
