Re: Daemon: dbus examples

[Sergio Schvezov]

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

[Jamie Strandboge]

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: Recommended ways of installing configuration files in SNAP_USER_DATA?

[Michael Hall]

I've used the same wrapper script configuration[1] as you're doing. If
you make pgbouncer a daemon it will be run as root, so the wrapper will
be able to create the config files without a problem. You should use
$SNAP_DATA rather than $SNAP_USER_DATA for this.

Coming soon (in snapd 2.18 I think) you will also be able to use the
'configure' hook, which will be called on install and update of a snap.
But for now the wrapper you have, plus making it a daemon, should do the
trick.

[1] https://github.com/apache/couchdb/blob/master/configure#L199

Michael Hall
mhall...@ubuntu.com

On 12/12/2016 02:27 PM, Ivan Lezhnjov IV wrote:
> Hi,
> 
> I’m working on pgbouncer snap package and as I’m new to snaps I wanted to ask 
> the community what is the current preferred way to install a program’s 
> configuration files that are meant to be edited by users?
> 
> For example, pgbouncer has a couple of files: pgbouncer.ini and userlist.txt. 
> Both normally located under /etc/pgbouncer. 
> 
> As users need to be able to modify various settings in pgbouncer.ini it has 
> to be under $SNAP_USER_DATA/etc/pgbouncer/.
> 
> I use a standalone wrapper script that initializes some filesystem paths, 
> creates empty log files, etc. which is all required by pgbouncer and is never 
> created by the program itself, where I essentially do this:
> 
> [ -e "$CNF_DIR/pgbouncer.ini" ] || cp $SNAP/etc/pgbouncer/pgbouncer.ini 
> $CNF_DIR/pgbouncer.ini
> 
> As you can see I first dump pgbouncer.ini to $SNAP/etc/pgbouncer/ and then 
> attempt to copy it to $CNF_DIR, which expands to 
> $SNAP_USER_DATA/etc/pgbouncer.
> 
> However, this doesn’t work as $SNAP/etc/pgbouncer/pgbouncer.ini is owned by 
> root and when the wrapper script is run as a normal user it cannot read the 
> $SNAP/etc/pgbouncer/pgbouncer.ini file (permission denied). 
> 
> I might be one step close to getting this to work but I was wondering what is 
> the common/recommended practice to do what I’m trying to achieve here?
> 
> Ivan
> 

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cannot install snap apps from store

[mhall119]

I've only seen this a couple times, if it's happening to you frequently it
may be a problem with your network connection. Perhaps we need a store
endpoint in China like we did for the developer portal?

On Dec 8, 2016 8:31 PM, "XiaoGuo Liu"  wrote:

> Hi,
>
> I do not know how many of you have met the issue. When I try to install an
> app from the store, it comes me an error like:
>
> liuxg@ubuntu:~$ sudo snap install tensorflow-demo --devmode --beta
> error: cannot install "tensorflow-demo": Get https://search.apps.ubuntu.
> com/api/v1/snaps/details/tensorflow-demo?channel=beta: net/http: request
> canceled while waiting for connection (Client.Timeout exceeded while
> awaiting headers)
> liuxg@ubuntu:~$ sudo snap install tensorflow-demo --devmode --beta
> error: cannot install "tensorflow-demo": Get https://search.apps.ubuntu.
> com/api/v1/snaps/details/tensorflow-demo?channel=beta: net/http: request
> canceled while waiting for connection (Client.Timeout exceeded while
> awaiting headers)
>
> In fact, I have met this this problem a number of times, and sometimes it
> works fine. Also, my colleague said to me that he gets the same issue
> sometimes. What is the root cause for this?
>
> Thanks  & best regards,
> XiaoGuo
>
> --
> XiaoGuo, Liu
>
> --
> 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

[Didier Roche]

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

[Michi Henning]

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