Re: Daemon: dbus examples
On Tue, 2016-12-13 at 09:31 +1000, Michi Henning wrote: > > In snapd 2.20 we are working to have the 'dbus' generic interface > > in place[2]. With it you can specify the bus name (session or > > system), the well-known name to bind to and then use interface > > connections to connect your client to your service. > I take I’ll be able to specify the dbus name dynamically? We need > this for storage service, where the client app doesn’t know a-priori > which exact service it will be talking to. Instead, that’s determined > by the user, who selects which cloud service they want to use (say, > for backup). The providers for the different cloud services each use > a different dbus name, so the actual dbus name an application needs > to use isn’t know until runtime. No, it shouldn't be dynamic. The point of the dbus entry is to provide well-known names for services, it doesn't really make sense for them to be generated. Also, I don't expect us to allow snaps to install in a GUI-way that use that feature. Certainly if someone goes to the command line and explicitly configures an interface, it's their device. But by default we want to ensure that there is no information leakage about what you have installed. We will have preinstalled snaps that have dbus well-known names. Ted signature.asc Description: This is a digitally signed message part -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Daemon: dbus examples
On Tue, 2016-12-13 at 09:31 +1000, Michi Henning wrote: > > > > In snapd 2.20 we are working to have the 'dbus' generic interface in > > place[2]. > > With it you can specify the bus name (session or system), the well-known > > name to > > bind to and then use interface connections to connect your client to your > > service. > Thanks for that Jamie! > > I take I’ll be able to specify the dbus name dynamically? We need this for > storage service, where the client app doesn’t know a-priori which exact > service it will be talking to. Instead, that’s determined by the user, who > selects which cloud service they want to use (say, for backup). The providers > for the different cloud services each use a different dbus name, so the actual > dbus name an application needs to use isn’t know until runtime. > As implemented, the slot implementation picks the well-known name it is known by and then 'snap connect' is used to connect plugging clients to the services. Each provider would claim a well-known name and each client *could* plug and snap connect any or all of them. Then at runtime the client could choose whichever they want to use. Based on your comments though, it sounds like perhaps you would want to have the storage service plug all the known cloud providers, then expose it via its own interface and have clients plug the storage service. Clients talk to the storage service and the storage service mediates communicates with the cloud providers. In this manner, the storage service only has to ever be updated to plug new cloud providers (something it would need to do any way) and the clients never have to be updated. Feel free to schedule a meeting sometime with me, Tyler/Emily and Thomas Voss if desired if you want input on the design or a design review. > > > > In a future version of snapd, service activation will be supported[3] (eg, > > for > > session services) as well as running daemons on the session bus[4]. AIUI the > > Ubuntu Personal folks are working on this and they have a design and the > > implementation should start soon. Thanks! > So, I take that we’ll be able to use this for things such as thumbnailer and > mediascanner? I’m asking because, if so, there is no point in me trying to add > service-specific interfaces for these to snapd. > Maybe. As I see it, there are two main considerations here: 1. the entire DBus API is granted (currently) when using this particular interface. If these service's entire DBus APIs are safe (ie, they don't violate application isolation or grant elevated permissions), then this interface could be appropriate for them. 2. are these services otherwise interesting enough to have their own interface on their own? Gustavo may have other considerations or thoughts on the matter. Do note that the interface as implemented today (ie, without session services or activation) is meant to allow leaf applications (eg, from GNOME or KDE) to work and talk to each other and integrate within the user's session. We'll work with Thomas on the activation and session service bits and then after that see how people want to use the interface and iterate. > Do you have a rough ETA for this? (No, I’m not going to hold you to it :- > ) Just trying to get a feel for where things are at.) > I'm told these are behind the trusty work, that the trusty work is nearing completion and that this dbus work will start after that. I suggest asking the Ubuntu Personal folks directly for when this might start/be completed. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Daemon: dbus examples
El 12/12/16 a las 18:33, Jamie Strandboge escribió: 2. snapcraft doesn't allow you to specify it (which is good since the implementation doesn't work correctly) This is because we agreed to bring it back in 16 with a more integrated/polished design. I believe the code in snapd are just remnants from 15.04. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Daemon: dbus examples
> In snapd 2.20 we are working to have the 'dbus' generic interface in place[2]. > With it you can specify the bus name (session or system), the well-known name > to > bind to and then use interface connections to connect your client to your > service. Thanks for that Jamie! I take I’ll be able to specify the dbus name dynamically? We need this for storage service, where the client app doesn’t know a-priori which exact service it will be talking to. Instead, that’s determined by the user, who selects which cloud service they want to use (say, for backup). The providers for the different cloud services each use a different dbus name, so the actual dbus name an application needs to use isn’t know until runtime. > In a future version of snapd, service activation will be supported[3] (eg, for > session services) as well as running daemons on the session bus[4]. AIUI the > Ubuntu Personal folks are working on this and they have a design and the > implementation should start soon. Thanks! So, I take that we’ll be able to use this for things such as thumbnailer and mediascanner? I’m asking because, if so, there is no point in me trying to add service-specific interfaces for these to snapd. Do you have a rough ETA for this? (No, I’m not going to hold you to it :-) Just trying to get a feel for where things are at.) Thanks, Michi. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Daemon: dbus examples
On Sat, 2016-12-10 at 14:29 +0100, l-snapcr...@znn.info wrote: > Hi Snapcrafter, > > in the documentation about keys in the yaml i saw a mention of "daemon: > dbus" (1), but i could not find an explanation in the documentation of a > real world example how it is used on github. > > Can someone point me to an example snapcraft.yaml where i can see how it > is used? > Or other documentation that gets more into detail. > > Thanks a lot. > > Greetings, > lightonflux > > 1: http://snapcraft.io/docs/snaps/metadata > I looked into this just now to give an overall status. 'daemon: dbus' was part of Ubuntu Core 15.04, it was only for system services and it was removed in series 16 in favor of 'interfaces'. As of now, 1. snapd allows specifying 'daemon: dbus' but when you do it generates an incomplete systemd service file: /usr/lib/snapd/snapd[2329]: task.go:303: DEBUG: 2016-12-12T14:33:18-06:00 ERROR [start snap.test-hello-dbus.test-hello-dbusd-system.service] failed with exit status 1: Failed to start snap.test-hello-dbus.test-hello-dbusd-system.service: Unit snap.test-hello-dbus.test-hello-dbusd-system.service is not loaded properly: Invalid argument.#012See system logs and 'systemctl status snap.test- hello-dbus.test-hello-dbusd-system.service' for details. 2. snapcraft doesn't allow you to specify it (which is good since the implementation doesn't work correctly) 3. http://snapcraft.io/docs/snaps/metadata incorrectly lists it 4. https://github.com/snapcore/snapd/wiki/Snap-format also incorrectly lists it I fixed '4' just now to remove the reference to 'dbus' and I filed a bug: https://bugs.launchpad.net/snappy/+bug/1649399 In terms of what you can do with dbus today: - you can use a named socket and a private bus for processes within your snap to communicate - if you are snapping something that is covered by an existing interface[1], you can use that interface - if you are snapping a service that is useful for more than just your snap, you can develop an interface for snapd In snapd 2.20 we are working to have the 'dbus' generic interface in place[2]. With it you can specify the bus name (session or system), the well-known name to bind to and then use interface connections to connect your client to your service. In a future version of snapd, service activation will be supported[3] (eg, for session services) as well as running daemons on the session bus[4]. AIUI the Ubuntu Personal folks are working on this and they have a design and the implementation should start soon. Thanks! [1]https://github.com/snapcore/snapd/wiki/Interfaces [2]https://bugs.launchpad.net/snappy/+bug/1590679 [3]https://bugs.launchpad.net/snappy/+bug/1648990 [4]https://bugs.launchpad.net/snappy/+bug/1613420 -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Daemon: dbus examples
Le 10/12/2016 à 14:29, l-snapcr...@znn.info a écrit : > Hi Snapcrafter, Hey lightonflux, > in the documentation about keys in the yaml i saw a mention of "daemon: > dbus" (1), but i could not find an explanation in the documentation of a > real world example how it is used on github. > > Can someone point me to an example snapcraft.yaml where i can see how it > is used? > Or other documentation that gets more into detail. We do suport similar keywords than systemd units. in that case, service files which are created by snapd. (man systemd.service for more information). The dbus type specifies there: Behavior of dbus is similar to simple; however, it is expected that the daemon acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified. And this is where i'm surprised, we don't support AFAIK additional names like BusName or such in snap.yaml, and so, the dbus keyword without BusName doesn't make any sense. Michael, can you shed some lights here? Cheers, Didier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Daemon: dbus examples
I tried this too, and the “dbus” key value was rejected. Looks like this might be a moldie oldie? Michi. > On 12 Dec. 2016, at 17:41 , Didier Roche wrote: > > Le 10/12/2016 à 14:29, l-snapcr...@znn.info a écrit : >> Hi Snapcrafter, > > Hey lightonflux >> >> in the documentation about keys in the yaml i saw a mention of "daemon: >> dbus" (1), but i could not find an explanation in the documentation of a >> real world example how it is used on github. >> >> Can someone point me to an example snapcraft.yaml where i can see how it >> is used? >> Or other documentation that gets more into detail. > > We do suport similar keywords than systemd units. in that case, service > files which are created by snapd. (man systemd.service for more > information). The dbus type specifies there: > Behavior of dbus is similar to simple; however, it is expected that > the daemon acquires a name on the D-Bus bus, as configured by > BusName=. systemd will proceed with starting follow-up units after > the D-Bus bus name has been acquired. Service units with this > option configured implicitly gain dependencies on the dbus.socket > unit. This type is the default if BusName= is specified. > > And this is where i'm surprised, we don't support AFAIK additional names > like BusName or such in snap.yaml, and so, the dbus keyword without > BusName doesn't make any sense. Michael, can you shed some lights here? > Cheers, > Didier > > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Daemon: dbus examples
Le 10/12/2016 à 14:29, l-snapcr...@znn.info a écrit : > Hi Snapcrafter, Hey lightonflux > > in the documentation about keys in the yaml i saw a mention of "daemon: > dbus" (1), but i could not find an explanation in the documentation of a > real world example how it is used on github. > > Can someone point me to an example snapcraft.yaml where i can see how it > is used? > Or other documentation that gets more into detail. We do suport similar keywords than systemd units. in that case, service files which are created by snapd. (man systemd.service for more information). The dbus type specifies there: Behavior of dbus is similar to simple; however, it is expected that the daemon acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified. And this is where i'm surprised, we don't support AFAIK additional names like BusName or such in snap.yaml, and so, the dbus keyword without BusName doesn't make any sense. Michael, can you shed some lights here? Cheers, Didier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Daemon: dbus examples
Hi Snapcrafter, in the documentation about keys in the yaml i saw a mention of "daemon: dbus" (1), but i could not find an explanation in the documentation of a real world example how it is used on github. Can someone point me to an example snapcraft.yaml where i can see how it is used? Or other documentation that gets more into detail. Thanks a lot. Greetings, lightonflux 1: http://snapcraft.io/docs/snaps/metadata -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
