Re: Exposing dbus interface and using it inside the same snap
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
solution for "only-english UI"
I found solution for only-english UI. https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282 Oliver Grawert (ogra) wrote on 2016-06-09: "help2man ships a little hack (http://paste.ubuntu.com/16923611/) to preload a modified bindtextdomain() over the original one ... while this is ugly, it actually seems to work ... http://paste.ubuntu.com/16925059/"; Thx Oliver! -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Porting Ubuntu-Core
Hi all, As I used new ubuntu-image (0.14+real1) to create my armhf image, I also got the same error as well. In order to try to fit the new spec of gadget.yaml, I modified the gadget.yaml as follows: device-tree: actduino_bubble_gum_sdboot_linux.dtb volumes: roseapple-pi: schema: mbr bootloader: u-boot structure: - name: bootloader size: 4M content: - image: bootloader.bin offset: 2097664 #4097*512 - image: u-boot.bin offset: 3145728 #6144*512 type: bare - name: system-boot type: 0C filesystem: vfat filesystem-label: system-boot offset: 8388608 size: 128M content: - source: boot-assets/ target: / And then this can avoid above the error during image creation. However, the generated image lost the content of bootloader.bin & u-boot.bin at the specific offset. So I think it may not follow the correct spec of gadget.yaml. Can anyone help us to resolve the problem? Thanks. Regards, Woodrow On Wed, Dec 21, 2016 at 11:15 AM, Bo Dong wrote: > Hi Guys, > > We're now porting Ubuntu Core to an ARM64 on-chip computer, Bubblegum-96 > board. (http://www.96boards.org/product/bubblegum-96/) > Here are some issues we got. > > When using ubuntu-image (tag:0.10+real 1 stable), > > *$ sudo /snap/bin/ubuntu-image --channel stable --image-size 2G > --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps > bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model* > > it could make valid image,bubblegum96.img. > > After update ubuntu-image using command *$ sudo snap refresh --beta > --devmode ubuntu-image*, the ubuntu-image will be updated to beta (tag: > 0.12+real 1). We using command > > $ sudo /snap/bin/ubuntu-image --channel beta --image-size 2G --extra-snaps > bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps > bubblegum96-kernel_3.10.0_arm6*4.snap -o bubblegum96.img > bubblegum96.model *again, and it will report failure. It shows "gadget.yaml > parse error: mbr structures cannot be larger than 446 bytes." > > The gadget.yaml file is the same before and after update ubuntu-image. > Here it is: > $ cat gadget.yaml > device-tree: s900-96board.dtb > volumes: > lemaker-guitar: > schema: mbr > bootloader: u-boot > structure: > - name: Bootstrap > type: mbr > size: 8M > content: > - image: bootloader.bin > offset: 2097664 > - image: u-boot.bin > offset: 3145728 > - type: 0C > filesystem: vfat > filesystem-label: system-boot > offset: 8388608 > size: 128M > content: > - source: boot-assets/ > target: / > > If we change the size: 8M directly to size:440, the image we made will be > useless. Actually I don't know how to config offset after change the size. > > If we change the schema: mbr directly to schema: gpt, and change the type: > mbr to type: gpt, it will fail again, and shows "gadget.yaml parse error: > Invalid gadget.yaml @ volumes:lemaker-guitar:structure:0:type" > > I'd appreciate it a lot if there is anyone could help us with this. > > Thanks&&Best Regards > > > > -- > 董波 > uCRobotic > Mobile: +86 15624957162 <+86%20156%202495%207162> > > http://www.ucrobotics.com.cn/ > > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- Woodrow Shen Software Engineer, Canonical ltd. Devices | CE | Delivery, Taipei -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Is there a way to prompt users to connect a non-auto-connect interface during installation?
Is it possible to check which interfaces a snap is connected to from within the snap? Or, would I have to try accessing the resources an interface exposes to know whether or not it had access? I tried calling snap interfaces from within my program, but I got a permissions error. On Feb 13, 2017 1:50 AM, "Alberto Mardegan" wrote: > On 12/02/2017 12:30, Aaron Hampton wrote: > > Hi, > > > > I am working on snapping a desktop application that needs access to > > hardware-observe. Is there a way to prompt the user to connect the > > interface during the installation of the snap? Or is the only way to > > have the user run snap connect? > > While this feature is missing, you could wrap your programs in a shell > script that checks whether the needed permissions are there and, if not, > print a message using zenity to inform the user. > > Ciao, > Alberto > > > -- > 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: vlc mpris
On 14 February 2017 at 08:01, Jamie Strandboge wrote: > On Mon, 2017-02-13 at 15:30 +0800, James Henstridge wrote: >> On 13 February 2017 at 15:02, Vasilisc wrote: >> > >> > How to allow vlc - "org.mpris.MediaPlayer2.vlc.instance*" ??? >> > >> > [0xd5f358] dbus interface error: Error requesting service name >> > org.mpris.MediaPlayer2.vlc.instance3045: Connection ":1.69" is not allowed >> > to own the service "org.mpris.MediaPlayer2.vlc.instance3045" due to >> > AppArmor >> > policy >> > >> > -- >> > I don't see interfaces dbus|mpris >> > >> > # LANG=C apt policy snapd >> > snapd: >> > Installed: 2.21 >> > Candidate: 2.21 >> > Version table: >> > *** 2.21 500 >> > 500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 >> > Packages >> > 100 /var/lib/dpkg/status >> > 2.0.2 500 >> > 500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages >> > >> > # snap interfaces | grep -E "(dbus|mpris)" >> > # >> You should be able to do this by adding a slot to your snap using the >> "mpris" interface. Something like this: >> >> slots: >> mpris: >> interface: mpris >> name: vlc >> >> Then make sure the app inside your snap uses this slot. >> >> This interface looks like it will work okay for the mpris provider, >> and okay for unconfined mpris clients on classic systems. > > Correct > >> It's not >> clear how you'd write a confined client that could act as a remote for >> all installed players without defining many duplicate plugs. If >> you're only interested in use on classic systems though, this should >> be good enough though. > > It works kind of like the dbus interface but is a bit simpler. It is > documented > here: > https://github.com/snapcore/snapd/wiki/Interfaces#mpris > > > Specifically if the providing snap has: > > name: vlc > apps: > vlc: > slots: [mpris] > > then vlc is allowed to bind to the DBus well-known name > 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: > > name: foo-vlc-controller > apps: > foo-vlc-controller: > plugs: [ mpris ] > > then can be connected with: > $ sudo snap connect foo-vlc-controller:mpris vlc:mpris > > > The interface has some flexibility for when you want to use something > different > than the snap's name in the DBus well-known name. Eg, if the providing snap > has: > > name: forked-vlc > slots: > mpris: > interface: mpris # this line not needed since iface name == slot ref > name: vlc > > then forked-vlc is allowed to bind to the DBus well-known name > 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: > > name: foo-vlc-controller > apps: > foo-vlc-controller: > plugs: [ mpris ] > > Then on install they can be connected with: > $ sudo snap connect foo-vlc-controller:mpris forked-vlc:mpris > > > Notice that foo-vlc-controller doesn't care about what is on the other end > (vlc, vs forked-vlc vs rhythmbox vs whatever) and it can be connected to > multiple slot implementations. This is the beauty of interfaces and how they > can be thought of as 'contracts' between slots and plugs. I can see how that works if I want to act as an mpris remote for one player. But what happens when we install a second player app and want to be able to control it as well? As I understand it, a plug can only connect to a single slot, so I'd need to define extra plugs: plugs: mpris1: interface: mpris mpris2: interface: mpris ... If I wanted to be able to act as a control for any running player (as indicator-sound does, for instance), then I'd have to hope I defined enough plugs. And that ignores the headaches of connecting everything up after installation. We're facing a similar problem with storage-framework too, where there can be multiple clients and multiple providers. We'll probably solve it there by adding an intermediary between clients and providers (which hasn't yet been started), but it did stand out as another case of many-to-many communication that doesn't neatly fit into snapd's interface model. James. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Currernt config hook implementation scales very badly
Hi, Today, I just followed the instructions at: https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/reference/core-configuration.md to disable ssh. However, I got the error like: liu-xiao-guo@localhost:~$ sudo snap set core service.ssh.disable=true error: cannot perform the following tasks: - Run configure hook of "core" snap (/snap/core/1177/meta/hooks/configure: 62: /snap/core/1177/meta/hooks/configure: systemctl: Permission denied) Is this a bug? It was tested on Raspberry Pi2 device, and my core system info is like: liu-xiao-guo@localhost:~$ snap version snap2.23~201702101018.git.979009c~ubuntu16.04.1 snapd 2.23~201702101018.git.979009c~ubuntu16.04.1 series 16 liu-xiao-guo@localhost:~$ snap info core name: core summary: "snapd runtime environment" publisher: canonical description: | The core runtime environment for snapd type:core tracking:edge installed: 16.04.1 (1177) 68MB - refreshed: 2017-02-13 04:42:55 + UTC channels: stable:16.04.1 (893) 67MB - candidate: 16.04.1 (1083) 68MB - beta: 16.04.1 (1083) 68MB - edge: 16.04.1 (1177) 68MB - Thanks & best regards, xiaoguo On Wed, Feb 1, 2017 at 6:31 PM, Oliver Grawert wrote: > hi, > > after we recently added a config hook [1] to the core snap it is now > possible to disable ssh if you require [2] ... > > there is a long standing request to do the same for syslog for systems > running from SD card, which is why i looked into trying to extend the > existing configure script for this, which made me notice some issue... > > when you call "snap set core foo=bar", there is no indication at all > for the script which variable changes a value, neither in the shell > environment nor in the argument list. > > the only way to get your value is to call snapctl for every existing > variable [3]. since you dont know what specific variable was requested > to change the only way to reliably write it is to write *all* existing > variables ... > > now, if you package something with a more complex config that you want > completely handled via snap config this gets ugly very fast... imagine > something like postfix with can potentially have 100s of config > options. instead of atomically changing a single option you will > regenerate the full config from scratch. this takes a lot longer, > bringing the risk of a completely broken config in case of a power > loss, beyond resulting an an awful config hook script with a large > block of "snapctl get" calls at the top. > > can we extend the config hook implementation minimally so a "snap set > core foo=bar" would at least have something like "SNAP_OPTION=foo" in > the environment that the generating script or binary could read to > avoid the unnecessary processing or would that break some design > concept ? > > ciao > oli > > [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ > hooks/configure > [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref > erence/core-configuration.md > [3] https://github.com/snapcore/snapd/wiki/hooks > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
ANN: llgo classic snap
Hi folks,
A while ago I snapped llgo, the Go frontend for LLVM. At the time, classic
snaps were not a thing, and so the snap had limited functionality. I've
updated it to use classic confinement, so you can use the compiler
toolchain as you would normally.
$ sudo snap install --classic llgo
$ llgo version
go version go1.5.1 llgo version 5.0.0 (go1.4.2) linux/amd64
$ llgo run ...
The llgo interpreter is still available, but as it is part of the same snap
it is no longer confined:
$ llgo.llgoi
(llgo) import "fmt"
(llgo) fmt.Println("hello, world")
hello, world
13
I have also exposed the llgo compiler as "llgo.compiler", so you can
generate LLVM IR, for example:
$ llgo.compiler -emit-llvm -S -o - main.go
; ModuleID = 'main'
source_filename = "main"
target datalayout ...
Cheers,
Andrew
--
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
Hi Jamie, Can you please point out the error in the below? I believe he is getting an error like this (perhaps truncated): Feb 13 19:33:07 ubuntu snap[3207]: GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.49" is not allowed to own the service "com.screenly.playlist" due to security policies in the c Feb 13 19:33:07 ubuntu snap[3207]: 0, timeout_to_glib(timeout), None).unpack() thanks, kyleN On 02/10/2017 12:35 PM, Sergey Borovkov wrote: 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: vlc mpris
On Mon, 2017-02-13 at 15:30 +0800, James Henstridge wrote: > On 13 February 2017 at 15:02, Vasilisc wrote: > > > > How to allow vlc - "org.mpris.MediaPlayer2.vlc.instance*" ??? > > > > [0xd5f358] dbus interface error: Error requesting service name > > org.mpris.MediaPlayer2.vlc.instance3045: Connection ":1.69" is not allowed > > to own the service "org.mpris.MediaPlayer2.vlc.instance3045" due to AppArmor > > policy > > > > -- > > I don't see interfaces dbus|mpris > > > > # LANG=C apt policy snapd > > snapd: > > Installed: 2.21 > > Candidate: 2.21 > > Version table: > > *** 2.21 500 > > 500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 > > Packages > > 100 /var/lib/dpkg/status > > 2.0.2 500 > > 500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages > > > > # snap interfaces | grep -E "(dbus|mpris)" > > # > You should be able to do this by adding a slot to your snap using the > "mpris" interface. Something like this: > > slots: > mpris: > interface: mpris > name: vlc > > Then make sure the app inside your snap uses this slot. > > This interface looks like it will work okay for the mpris provider, > and okay for unconfined mpris clients on classic systems. Correct > It's not > clear how you'd write a confined client that could act as a remote for > all installed players without defining many duplicate plugs. If > you're only interested in use on classic systems though, this should > be good enough though. It works kind of like the dbus interface but is a bit simpler. It is documented here: https://github.com/snapcore/snapd/wiki/Interfaces#mpris Specifically if the providing snap has: name: vlc apps: vlc: slots: [mpris] then vlc is allowed to bind to the DBus well-known name 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: name: foo-vlc-controller apps: foo-vlc-controller: plugs: [ mpris ] then can be connected with: $ sudo snap connect foo-vlc-controller:mpris vlc:mpris The interface has some flexibility for when you want to use something different than the snap's name in the DBus well-known name. Eg, if the providing snap has: name: forked-vlc slots: mpris: interface: mpris # this line not needed since iface name == slot ref name: vlc then forked-vlc is allowed to bind to the DBus well-known name 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: name: foo-vlc-controller apps: foo-vlc-controller: plugs: [ mpris ] Then on install they can be connected with: $ sudo snap connect foo-vlc-controller:mpris forked-vlc:mpris Notice that foo-vlc-controller doesn't care about what is on the other end (vlc, vs forked-vlc vs rhythmbox vs whatever) and it can be connected to multiple slot implementations. This is the beauty of interfaces and how they can be thought of as 'contracts' between slots and plugs. Hope this helps! -- 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: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04
Le 10/02/2017 à 17:30, Simos Xenitellis a écrit : > On Tue, Feb 7, 2017 at 3:54 PM, Didier Roche wrote: >> Le 07/02/2017 à 14:05, Simos Xenitellis a écrit : >>> On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche wrote: Le 06/02/2017 à 10:56, Simos Xenitellis a écrit : > Hi All, > > I wrote an article about creating a snap for an existing Python > program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu > Store. > > I am looking forward to receiving feedback :-) > > Link: > https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ > > Link to HN submission: https://news.ycombinator.com/item?id=13578034 > > Simos > Excellent work Simos! I think this kind of content would make an excellent official "pratical" tutorials on https://tutorials.ubuntu.com. Are you interested into contributing there? If you want more context on tutorials, the phisolophy and how to contribute, I wrote a blog post some time ago about it: https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/. I'm also available for any help, >>> Thanks Didier! >>> >>> I had a look at https://github.com/ubuntudesign/tutorials.ubuntu.com/issues >>> and the direction that tutorials.ubuntu.com wants to take. It looks good. >>> It requires planning in terms of the writing of the tutorials so that >>> they are gradually incremental, >>> and some basic tutorials can referenced by the more complex ones. It's >>> a lot of dedicated work. >>> >>> I'll give it a go and try to write a couple of tutorials for >>> tutorials.ubuntu.com. We will see how it goes :-) >>> I think I'll start with the baseline tutorial for snapcraft. >> Excellent news! >> You can as well convert some of yours to this format! I give you the >> direct link to the guidelines to have some coherences between the >> tutorials in term of tones and content: >> https://docs.google.com/document/d/1u5qmSNIcE8SjuAg6aKjTxOBGWIjBW0kYf01t4Dfw6-U/edit. >> > I managed to complete the conversion and the tutorial is ready :-). > > Here it is, > https://docs.google.com/document/d/1Nk-kw79lt84YJNEKS_WpnGzVSjrmCUVd1TsAx5aRoOA/ > Feel free to add to tutorials.ubuntu.com or make a copy in order to edit. > > Overall, the experience in converting to the format required by > codelabs was interesting. > I still need more practice before I would be able to write a tutorial > in one go in the codelab style. This really looks awesome! Thanks Simos :) I'll add some very small tweaking, but after a first look, it's very a nice first shot. Well done :) I would be interested in any comment you have about the codelab format and style, and anything you liked/didn't like. I'll keep you posted with a diff so that you can see what small modifications I made to be more coherent with the other ones. If you have any other to do, do not hesitate to keep us posted! Cheers, Didier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: netplan and post-up/pre-down scripts
On Tue, Jan 17, 2017 at 1:02 AM, Mike Pontillo wrote: > On Mon, Jan 16, 2017 at 7:35 AM, Mark Shuttleworth > wrote: > >> Would 'got-link' and 'lost-link' be good names for this? >> > > I'm not certain a new event name is needed for this functionality; it > seems to me that the current definition of 'up' isn't quite correct.[1] > (But all this might be a moot point depending on what is supported in > networkd, and how it behaves.) > > I understand there have been several attempts to address this in the past, > such as the 'allow-hotplug' option, ifplugd, ifupdown-extra, > NetworkManager, and now networkd. IMHO, no solution is complete unless it > properly separates adminStatus from operStatus, and holds off on confirming > "link up" until both are "up". For backward compatibility, a boolean flag > (similar to "allow-hotplug") should indicate whether or not the system is > allowed to continue booting if the interface is down.[2] > I agree booting should continue for any device that is down even if it's configured and marked as fine to still be down. I think rather than trying to skip a long delay that would happen in some other cases, we should revisit whether it makes sense for it to take 5 minutes; or even make this configurable. 5 minutes is a lot; 1 minute is acceptable in many configurations, 30 seconds is ideal in some. All this only makes sense for DHCP-configured interfaces where the link is up but no DHCP response has been received. If the link is down, there is no point in ever waiting. This may need fixed in networkd and NM to allow configuring the DHCP timeout. I do not know that any of the different network management tools were planned to address administrative status of an interface. It may even in fact require kernel work (I haven't looked yet) to allow its state to be set to administratively down. Please file a bug about this. I'll review and look how we can specify this in netplan, and how we can drive it in the various backends... But I expect it will require work in both networkd and NetworkManager before it does work correctly. Servers aren't typically used in such a way, and setting that option seems like it might be quite intrusive (I mean, of course the default wouldn't be for interfaces to be administratively down, but I can see issues coming up from it. One of them is how to do it in the first place, and another is that it would only happen once the renderer (networkd/NM) is up and running, so potentially you've already sent/received packets on the interfaces... ideally, that shouldn't happen, but maybe I'm overthinking it). > > Another subtle detail is that if an interface is administratively down, > there should be an option to cause the NIC to take its physical link down. > That way, whatever is on the other side of the link doesn't assume its peer > is active. (This is standard behavior on a router or a switch, but may be > atypical for a server... so I think the default behavior should continue be > "leave the physical link up".) > Of course. If something is administratively down, we must think of it in terms of *powered down*. Otherwise it's simply not configured. / Matt -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: chroot into a snap
Thanks Jamie, I've reopen one [1] that I marked as invalid when I plugged docker-support. [1] https://bugs.launchpad.net/snappy/+bug/1663175 On 13/02/17 17:04, Jamie Strandboge wrote: > On Mon, 2017-02-13 at 09:40 -0600, Jamie Strandboge wrote: >> On Fri, 2017-02-10 at 14:44 +0100, Roberto Mier Escandón wrote: >>> >>> = Seccomp = >>> Time: Feb 10 12:31:42 >>> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" >>> exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c03e >>> 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 >>> Syscall: chroot >>> >> This may be tricky as the paths >> > Whoops, this got cut off. Basically, just file a bug as I asked later. :) > >>> >>> I've solved that by plugging docker-support and all works fine. But that >>> interface gives a lot of permissions, and the name maybe is not the most >>> accurate for a case like this. >> The docker-support interface should not be used for this. It is a so called >> 'super-privileged' interface and like you said, grants way more than is >> needed. >> >>> >>> Shouldn't we have an interface allowing mknod, chroot and maybe ptrace >>> for snaps creating their own chroot jails?. >> As said, mknod is in progress. Can you file a bug for chroot? >> >> ptrace we could allow with 4.8+ kernels or if we add 'seccomp after ptrace' >> to >> the list of kernel patches for snappy. >> >> -- >> Snapcraft mailing list >> Snapcraft@lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/s >> napcraft >> >> -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Problems using GLib's DBus implementation with dbus interface
On Fri, 2017-02-10 at 15:34 +0800, James Henstridge wrote:
> I was snapping up a D-Bus service I'm responsible for, and had it
> crash with a "Bad System Call" error, and the following in the dmesg
> output:
>
> [2054724.068967] audit: type=1326 audit(1486700103.228:2687):
> auid=1000 uid=1000 gid=1000 ses=2 pid=29311 comm="mediascanner-se"
> exe="/snap/mediascanner2/x1/bin/mediascanner-service-2.0" sig=31
> arch=c03e syscall=45 compat=0 ip=0x7f28d037866d code=0x0
>
> This appears to be the recvfrom system call. The snap was configured
> with a slot using the generic "dbus" interface, but not the "network"
> plug. If I add "network", the problem goes away.
>
> Looking at the seccomp filters for "dbus" interface definition in
> snapd it allows recvmsg and sendmsg, but the D-Bus library this code
> uses (GLib's GDBus) uses recvfrom() (at least it does while
> initialising the connection).
>
> My first thought was that these extra system calls to the dbus
> interface's seccomp filter. But then I took another look at what
> calls were enabled for the base policy, which showed socket(),
> connect(), {get,set}sockopt, and a few others. The only thing
> preventing the default policy from creating IP sockets is the AppArmor
> policy.
>
> Given that the default policy nominally allows communication via unix
> domain sockets within a snap, I wonder if it would make sense to move
> the other socket related syscalls from the network interface to the
> default?
>
> I've created the following bug report to help track this problem:
>
> https://bugs.launchpad.net/snappy/+bug/1663177
FYI, James provided a PR request for this bug (thanks!) and it is committed to
master and will be in snapd 2.23.
--
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: chroot into a snap
On Mon, 2017-02-13 at 09:40 -0600, Jamie Strandboge wrote: > On Fri, 2017-02-10 at 14:44 +0100, Roberto Mier Escandón wrote: > > > > = Seccomp = > > Time: Feb 10 12:31:42 > > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" > > exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c03e > > 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 > > Syscall: chroot > > > This may be tricky as the paths > Whoops, this got cut off. Basically, just file a bug as I asked later. :) > > > > I've solved that by plugging docker-support and all works fine. But that > > interface gives a lot of permissions, and the name maybe is not the most > > accurate for a case like this. > The docker-support interface should not be used for this. It is a so called > 'super-privileged' interface and like you said, grants way more than is > needed. > > > > > Shouldn't we have an interface allowing mknod, chroot and maybe ptrace > > for snaps creating their own chroot jails?. > As said, mknod is in progress. Can you file a bug for chroot? > > ptrace we could allow with 4.8+ kernels or if we add 'seccomp after ptrace' to > the list of kernel patches for snappy. > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/s > napcraft -- 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: interfaces composition
On Mon, 2017-02-13 at 10:56 +0100, Roberto Mier Escandón wrote: > Hey, > > Just an idea. > In my last snap I needed docker-support interface for only having access > to use mknod and chroot. Compared with the big list of permissions that > interface allows and I don't need, I wonder if we could have an internal > kind of structure of interfaces so that there are some of them which are > the composition of others. One snap could plug docker-support not > knowing that is "chroot" interface + "ptrace" interface + whatever. > Other snap can plug chroot interface instead since doesn't need the > other stuff and so on... > In general, the security policy is the composition of interfaces. The default template plus interfaces gives you your security policy. There isn't that much overlap between the interfaces (a few seccomp calls notwithstanding, but there are some cleanups to be had there), but there is some, because interfaces are mostly meant to be standalone. The interfaces system is meant to be developer friendly and 'fine-grained enough' for the functionality that is meant to be exposed. chroot or ptrace interfaces aren't necessarily interesting on their own because we have to ask questions like 'chroot to where?' or 'ptrace what and how?' As such, we look at the desired functionality and go from there. Perhaps there is something that can be added to the template or an existing interface, perhaps it is a new interface. How that is expressed internally in snapd is an internal implementation detail, but what we expose to developers and users is very carefully considered. We did just that for the docker-support interface and it is a very special interface that is transitional and exists to make docker work at all. It's a very specific corner-case interface that allows a lot more than what is advertised. The best course of action is to file bugs and/or discuss on this list the functionality you want then the developers can figure out how to expose it. -- 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: chroot into a snap
On Fri, 2017-02-10 at 14:44 +0100, Roberto Mier Escandón wrote: > That's interesting, Simon. Good idea having available both $SNAP_DATA > and /media. We'll do. > > But now, let's back to original topic: chroot into snap. > After solving the issue Thomas found related with the path of the > document, I see now there are two operations not allowed in strict > confinement: mknod and chroot. Here is what the snappy-debug.security > log shows: > > = Seccomp = > Time: Feb 10 12:31:31 > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=31983 comm="loolkit" > exe="/snap/loolwsd/x16/usr/bin/loolforkit" sig=31 arch=c03e > 133(mknod) compat=0 ip=0x7f6a6d6450fd code=0x0 > Syscall: mknod > This is in progress: https://github.com/snapcore/snapd/pull/2749 > = Seccomp = > Time: Feb 10 12:31:42 > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" > exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c03e > 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 > Syscall: chroot > This may be tricky as the paths > I've solved that by plugging docker-support and all works fine. But that > interface gives a lot of permissions, and the name maybe is not the most > accurate for a case like this. The docker-support interface should not be used for this. It is a so called 'super-privileged' interface and like you said, grants way more than is needed. > Shouldn't we have an interface allowing mknod, chroot and maybe ptrace > for snaps creating their own chroot jails?. As said, mknod is in progress. Can you file a bug for chroot? ptrace we could allow with 4.8+ kernels or if we add 'seccomp after ptrace' to the list of kernel patches for snappy. -- 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: tcpdump armhf
Yes, classic. Thanks for the reminder. --Luca On Mon, Feb 13, 2017 at 12:48 PM, Alan Pope wrote: > Hi Luca, > > On 13 February 2017 at 11:34, Luca Dionisi wrote: >> This tool is not installed in the "core" snap. A run of "snap find >> tcpdump" returns 0 results. >> >> What's my best move? Make a snap on my own and use launchpad >> snap-builders to produce the one for armhf? >> > > One option would be to enable classic [1] on the pi and install it inside > that. > > snap install classic --edge --devmode > sudo classic > sudo apt update > sudo apt install tcpdump > > > [1] https://developer.ubuntu.com/core/get-started/developer-setup > > Cheers, > -- > Alan Pope > Community Manager > > Canonical - Ubuntu Engineering and Services > +44 (0) 7973 620 164 > alan.p...@canonical.com > http://ubuntu.com/ > > -- > 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: tcpdump armhf
Hi Luca, On 13 February 2017 at 11:34, Luca Dionisi wrote: > This tool is not installed in the "core" snap. A run of "snap find > tcpdump" returns 0 results. > > What's my best move? Make a snap on my own and use launchpad > snap-builders to produce the one for armhf? > One option would be to enable classic [1] on the pi and install it inside that. snap install classic --edge --devmode sudo classic sudo apt update sudo apt install tcpdump [1] https://developer.ubuntu.com/core/get-started/developer-setup Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.p...@canonical.com http://ubuntu.com/ -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
tcpdump armhf
For debugging my app, I need to run "tcpdump" on my Ubuntu Core based Raspberry Pi. This tool is not installed in the "core" snap. A run of "snap find tcpdump" returns 0 results. What's my best move? Make a snap on my own and use launchpad snap-builders to produce the one for armhf? --Luca -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
only english UI
If you install vlc in snap package, then see only English interface. # snap find vlc Name Version Developer Notes Summary vlc dailyvideolan - The ultimate media player I try to pack the player-vlc-based and too I fail. Earlier I was helped by these lines, but not now #= export I18NPATH=$SNAP/usr/share/i18n export LOCPATH=$SNAP_USER_COMMON export LC_ALL=$LANG LANG1=$(echo $LANG | cut -f1 -d.) ENC=UTF-8 LOC="$LANG" # generate a locale so we get properly working charsets and graphics if [ ! -e $SNAP_USER_COMMON/$LOC ]; then $SNAP/usr/bin/localedef --prefix=$SNAP_USER_COMMON -f $ENC -i $LANG1 $SNAP_USER_COMMON/$LOC fi #= -- Best regards, vasilisc -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
interfaces composition
Hey, Just an idea. In my last snap I needed docker-support interface for only having access to use mknod and chroot. Compared with the big list of permissions that interface allows and I don't need, I wonder if we could have an internal kind of structure of interfaces so that there are some of them which are the composition of others. One snap could plug docker-support not knowing that is "chroot" interface + "ptrace" interface + whatever. Other snap can plug chroot interface instead since doesn't need the other stuff and so on... BR -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Mesa 13.0.4 snap?
Hi everybody, I have seen that mesa 13.0.4 won't ship on Ubuntu 16.04.2 but that a PPA has been made available for this (e.g. to play with DiRT). I deduct it was a pretty requested update. Would it be technically possible to have a mesa snap for the classical systems? Or a similar approach is restricted only to all snap (like Ubuntu Personal) systems? And, if feasible, what would it require? Cheers, Fabio -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
