Re: Issues using dbus in strict

2017-04-03 Thread Sergey Borovkov
So once the interfaces are connected the following happens:

1. In websocket service (the one that just calls methods over dbus) I can
get system bus without any issues.
2. In the second service, the one that exposes dbus interface I get
following exception when running this code:

try:
bus = SystemBus()
bus.publish("com.screenly.playlist", playlist_service)
except:
log = logging.getLogger('screenly.PlaylistService')
log.exception("Unable to register on system bus: ")

Apr 03 19:53:49 localhost.localdomain python3[1246]: screenly.PlaylistService
Unable to register on system bus:
Traceback (most recent
call last):
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/bus.py", line
43, in dbus
return self._dbus
AttributeError: 'Bus'
object has no attribute '_dbus'

During handling of the
above exception, another exception occurred:

Traceback (most recent
call last):
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/screenly/client/playlist.py",
line 605, in main

bus.publish("com.screenly.playlist",
playlist_service)
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/publication.py",
line 42, in publish
return
Publication(self, bus_name, *objects)
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/publication.py",
line 35, in __init__

self._at_exit(bus.request_name(bus_name,
allow_replacement=allow_replacement, replace=replace).__exit__)
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/request_name.py",
line 29, in request_name
return
NameOwner(self, name, allow_replacement, replace)
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/request_name.py",
line 8, in __init__
res =
bus.dbus.RequestName(name, flags)
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/bus.py", line
45, in dbus
self._dbus =
self.get(".DBus")[""]
  File
"/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/proxy.py",
line 47, in get
0,
timeout_to_glib(timeout), None)
GLib.GError:
g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An
AppArmor policy prevents this sender from sending this message to this
recipient; type="
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: Issues using dbus in strict

2017-04-03 Thread Sergey Borovkov
Hi, I manually connected interfaces. But the issue is that it can't even
connect to system bus? Before trying to call any methods.

root@localhost:/home/pi# snap interfaces
Slot  Plug
:account-control  -
:alsa -
:autopilot-introspection  -
:bluetooth-control-
:browser-support  screenly-client:browser-support-plug
:camera   -
:classic-support  -
:core-support core
:dcdbas-control   -
:docker-support   -
:firewall-control -
:framebuffer  screenly-client
:fuse-support -
:hardware-observe -
:home -
:io-ports-control -
:kernel-module-control-
:locale-control   -
:log-observe  screenly-client
:lxd-support  -
:mount-observe-
:network  screenly-client,screenly-pi3
:network-bind core,screenly-client
:network-control  -
:network-observe  -
:network-setup-control-
:network-setup-observe-
:opengl   screenly-client
:openvswitch-support  -
:physical-memory-control  -
:physical-memory-observe  -
:ppp  -
:process-control  -
:raw-usb  -
:removable-media  -
:shutdown -
:snapd-control-
:system-observe   -
:system-trace -
:time-control -
:timeserver-control   -
:timezone-control -
:tpm  -
:uhid -
screenly-client:playlist-dbus-server  screenly-client:playlist-dbus-client
screenly-pi3:bcm-gpio-0   -
screenly-pi3:bcm-gpio-1   -
screenly-pi3:bcm-gpio-10  -
screenly-pi3:bcm-gpio-11  -
screenly-pi3:bcm-gpio-12  -
screenly-pi3:bcm-gpio-13  -
screenly-pi3:bcm-gpio-14  -
screenly-pi3:bcm-gpio-15  -
screenly-pi3:bcm-gpio-16  -
screenly-pi3:bcm-gpio-17  -
screenly-pi3:bcm-gpio-18  -
screenly-pi3:bcm-gpio-19  -
screenly-pi3:bcm-gpio-2   -
screenly-pi3:bcm-gpio-20  -
screenly-pi3:bcm-gpio-21  -
screenly-pi3:bcm-gpio-22  -
screenly-pi3:bcm-gpio-23  -
screenly-pi3:bcm-gpio-24  -
screenly-pi3:bcm-gpio-25  -
screenly-pi3:bcm-gpio-26  -
screenly-pi3:bcm-gpio-3   -
screenly-pi3:bcm-gpio-4   -
screenly-pi3:bcm-gpio-5   -
screenly-pi3:bcm-gpio-6   -
screenly-pi3:bcm-gpio-7   -
screenly-pi3:bcm-gpio-8   -
screenly-pi3:bcm-gpio-9   -
- screenly-pi3:snapd-control


On 3 April 2017 at 16:58, Jamie Strandboge <ja...@canonical.com> wrote:

> On Fri, 2017-03-31 at 17:55 +0300, Sergey Borovkov wrote:
>
> ...
>
> > Mar 31 12:44:02 localhost.localdomain kernel: audit: type=1400
> > audit(1490964242.523:72): apparmor="DENIED" operation="connect" profile=
> > "snap.screenly-client.websocket" name="/run/dbus/system_bus_socket"
> > pid=1466 comm="python3" req
> > Mar 31 12:44:02 localhost.localdomain audit[1466]: AVC apparmor="DENIED"
> > operation="connect" profile="snap.screenly-client.websocket" name="/
> > run/dbus/system_bus_socket" pid=1466 comm="python3" requested_mask="wr"
> > denied_mask="wr"
> >
> > I am not sure if I need to use some additional interfaces - to get it
> > working under devmode I've used the following code (And I can't find
> > anything relevant in wiki):
> >
> >   playlist:
> > command: usr/bin/playlist-service.sh
> > daemon: simple
> > plugs: [network-bind, network]
> > slots: [playlist-dbus-server]
> >
> >   websocket:
> > command: usr/bin/websocket-service.sh
> > daemon: simple
> > plugs: [network-bind, network, playlist-dbus-client]
> >
> > slots:
> >   playlist-dbus-server:
> > interface: dbus
> > name: com.screenly.playlist
> > bus: system
> >
> > plugs:
> >   playlist-dbus-client:
> > interface: dbus
> >

Issues using dbus in strict

2017-03-31 Thread Sergey Borovkov
Hi. I am running a couple of daemons (daemon: simple) and they interact
between each other using dbus. Unfortunately I've ran into the issue when
porting them from devmode to strict, I am getting this backtrace just
trying to obtain SystemBus in python:

Mar 31 12:44:02 localhost.localdomain snap[1466]: GLib.Error:
g-io-error-quark: Could not connect: Permission denied (14)
Mar 31 12:44:02 localhost.localdomain snap[1466]: return Gio.bus_get_sync(type,
None).pydbus
Mar 31 12:44:02 localhost.localdomain snap[1466]: File "/snap/screenly-
client/165/lib/python3.5/site-packages/pydbus/bus.py", line 19, in bus_get
Mar 31 12:44:02 localhost.localdomain snap[1466]: return bus_get(Bus.Type.
SYSTEM)
Mar 31 12:44:02 localhost.localdomain snap[1466]: File "/snap/screenly-
client/165/lib/python3.5/site-packages/pydbus/bus.py", line 57, in SystemBus
Mar 31 12:44:02 localhost.localdomain snap[1466]: self.bus = SystemBus()
Mar 31 12:44:02 localhost.localdomain kernel: audit: type=1400
audit(1490964242.523:72): apparmor="DENIED" operation="connect" profile=
"snap.screenly-client.websocket" name="/run/dbus/system_bus_socket"
pid=1466 comm="python3" req
Mar 31 12:44:02 localhost.localdomain audit[1466]: AVC apparmor="DENIED"
operation="connect" profile="snap.screenly-client.websocket" name="/
run/dbus/system_bus_socket" pid=1466 comm="python3" requested_mask="wr"
denied_mask="wr"

I am not sure if I need to use some additional interfaces - to get it
working under devmode I've used the following code (And I can't find
anything relevant in wiki):

  playlist:
command: usr/bin/playlist-service.sh
daemon: simple
plugs: [network-bind, network]
slots: [playlist-dbus-server]

  websocket:
command: usr/bin/websocket-service.sh
daemon: simple
plugs: [network-bind, network, playlist-dbus-client]

slots:
  playlist-dbus-server:
interface: dbus
name: com.screenly.playlist
bus: system

plugs:
  playlist-dbus-client:
interface: dbus
name: com.screenly.playlist
bus: system
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: Simple daemon settings

2017-03-16 Thread Sergey Borovkov
Thanks, just what I needed.

On 16 March 2017 at 12:00, Roberto Mier Escandón  <
roberto.escan...@canonical.com> wrote:

>
> You can find all the restart conditions here [1]
>
> Basically it says:
>
> # Condition to restart the daemon under. Defaults to on-failure.
> # See the systemd.service manual on Restart for details.
> restart-condition: \
>  on-failure | on-success | on-abnormal | on-abort | always | never
>
> Cheers.
>
> [1] https://snapcraft.io/docs/snaps/metadata
>
> On 16/03/17 09:41, Ara Pulido wrote:
> > On Thu, Mar 16, 2017 at 9:32 AM, Sergey Borovkov <
> serge.borov...@gmail.com>
> > wrote:
> >
> >> Hello,
> >> I am running service using daemon: simple in snapcraft. Is there any way
> >> to configure how systemd handles restarting in the snapcraft.yaml?
> Current
> >> behavior is that it restarts the service when it exits with non zero
> exit
> >> code. But it does not get restarted otherwise. Can this be tweaked?
> >>
> >
> > I believe you can add:
> >
> > daemon: simple
> > restart-condition: always
> >
> > Regards,
> > Ara.
> >
>
> --
> --
> . Roberto Mier Escandón.
> . Software Engineer
> .
> . Canonical - Solutions Engineering
> --
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Simple daemon settings

2017-03-16 Thread Sergey Borovkov
Hello,
I am running service using daemon: simple in snapcraft. Is there any way to
configure how systemd handles restarting in the snapcraft.yaml? Current
behavior is that it restarts the service when it exits with non zero exit
code. But it does not get restarted otherwise. Can this be tweaked?
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: Exposing dbus interface and using it inside the same snap

2017-02-14 Thread Sergey Borovkov
Nvm guys, I figured it out.

On 14 February 2017 at 09:44, Sergey Borovkov <serge.borov...@gmail.com>
wrote:

> Hi, I am using this code:
>
> apps:
>   playlist:
> command: usr/bin/playlist-service.sh
> daemon: simple
> plugs: [network-bind, network]
> slots: [playlist-dbus-server]
>
>   websocket:
> command: usr/bin/websocket-service.sh
> daemon: simple
> plugs: [network-bind, network, playlist-dbus-client]
>
> slots:
>   playlist-dbus-server:
> interface: dbus
> name: com.screenly.playlist
> bus: system
>
> plugs:
>   playlist-dbus-client:
> interface: dbus
> name: com.screenly.playlist
> bus: system
>
> After doing snap installl --devmode screenly.snap snapd prints out this
> error:
> 2017-02-13T21:48:28Z INFO snap "screenly-client" has bad plugs or slots:
> dbus (cannot find attribute 'bus')
>
> All of this happens with snapd from the proposed repository:
>
> root@ubuntu:/home/ubuntu# snap --version
> snap 2.22.2
> snapd 2.22.2
>
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Exposing dbus interface and using it inside the same snap

2017-02-10 Thread Sergey Borovkov
Hi, I've been struggling with getting dbus interface exposed. I am getting
this error during runtime:
GLib.Error: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.AccessDenied:
Connection ":1.1160" is not allowed to own the service
"com.screenly.playlist" due to security policies in the configuration file
(9)

jdstrand helped me on IRC, and told me I need to have a slot and a plug in
my snap. I am doing something wrong though, can someone help out with how
it's correctly supposed to be used?

apps:
  playlist:
command: usr/bin/playlist-service.sh
daemon: simple
plugs: [network-bind, network, playlist-dbus]

  websocket:
command: usr/bin/websocket-service.sh
daemon: simple
plugs: [network-bind, network, dbus]
slots: [websocket-dbus]

slots:
  playlist-dbus:
interface: dbus
name: com.screenly
bus: system

plugs:
  websocket-dbus:
interface: dbus
name: com.screenly
bus: system
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: Classic image not working after upgrade on RPI 3

2016-12-21 Thread Sergey Borovkov
Ok, so I enabled xenial proposed.

Got following versions:
Setting up linux-firmware-raspi2 (1.20161020-0ubuntu1~0.1) ...
Setting up linux-raspi2-headers-4.4.0-1038 (4.4.0-1038.45) ...
Setting up linux-headers-4.4.0-1038-raspi2 (4.4.0-1038.45) ...
Setting up linux-image-raspi2 (4.4.0.1038.37) ...
Setting up linux-headers-raspi2 (4.4.0.1038.37) ...
Setting up linux-raspi2 (4.4.0.1038.37) ...
Setting up python3-cryptography (1.2.3-1ubuntu0.1) ...
Setting up python3-software-properties (0.96.20.5) ...
Setting up software-properties-common (0.96.20.5) ...


And again image does not boot after restart. Stuck in "starting kernel".

On 21 December 2016 at 19:20, Chris Wayne <chris.wa...@canonical.com> wrote:

> Hi Sergey,
>
> Which image are you using?  Is it possible this is the same as this bug:
> https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1636838
> (which should now be fixed).  Perhaps you could try the PPA listed in that
> bug? (Note that this is technically a bug for rpi2, but I *believe* they
> may share the same kernel)
>
> Thanks
> Chris
>
> On Wed, Dec 21, 2016 at 9:57 AM, Sergey Borovkov <serge.borov...@gmail.com
> > wrote:
>
>> Hi. After I did apt upgrade on classic image I can't boot my RPI anymore.
>> It's stuck on 'Starting kernel...'.
>> Tried different SD cards (on the second one I flashed out new classic
>> image and did upgrade as well) with the same result.
>>
>> --
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/snapcraft
>>
>>
>
> --
> 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