| tgm4883 | Just tried packaging my first app for snappy (well second if you count the hello world app) and when I run it in my snappy vm I'm getting a permission denied error on /tmp/snaps. I didn't see where I'm suppose to declare this permission, is this something I can do or do I need to try to tell the app to use some fake tmp in /var/apps/myapp/? | 00:53 |
|---|---|---|
| tgm4883 | just found this, which I think might be what I need https://developer.ubuntu.com/en/snappy/guides/security-policy/ | 00:55 |
| === erkules_ is now known as erkules | ||
| JamesTait | Good morning all; happy Friday and happy Don’t Fry Day! 😃 | 08:04 |
| asac | mvo: fyi, i did a hard backout of the convenience change you landed in go-example-webserver | 08:21 |
| asac | not sure if you want to bring it back, but if so, please test that the package still works afterwards :P | 08:21 |
| mvo | asac: oh, sorry for that and thanks for fixing | 08:23 |
| asac | mvo: i think it should have been a -n ? | 08:27 |
| asac | mvo: it failed to start with this :) | 08:28 |
| asac | because EOF tries to write a temp file it seems | 08:28 |
| mvo | thats confusing, once I finished my branch here I will checks whats going on, looks ok from a first glace but certainly is not :/ | 08:29 |
| Chipaca | mo'in | 08:29 |
| Chipaca | mvo: we have many bugs around tempdirs | 08:30 |
| mvo | hey Chipaca | 08:31 |
| mvo | Chipaca: meh, more? | 08:31 |
| mvo | Chipaca: or more of the same and we need to land your fix urgently? | 08:32 |
| Chipaca | mvo: well, that "can't create here document" or whatever the error message was is one | 08:32 |
| Chipaca | mvo: my fix is not necessary; merely sufficient (?) | 08:32 |
| Chipaca | (i kid; it's not even that, there's more work to be done to fix it still) | 08:32 |
| Chipaca | mvo: bash creates its tempfiles in TMPDIR | 08:33 |
| mvo | oh, meh | 08:33 |
| Chipaca | mvo: our systemd units are not creating their tempdirs | 08:33 |
| mvo | right, lets land your fix urgently | 08:33 |
| Chipaca | mvo: my fix needs work on other fronts | 08:33 |
| Chipaca | mvo: to be more exact: | 08:33 |
| Chipaca | mvo: a snappy branch to change TE?MPDIR | 08:34 |
| Chipaca | mvo: and a branch to ... apparmor? simpleprof something, to let things write to /tmp/ | 08:34 |
| mvo | hm, if thats the case, is there anything else we can do? something cheap that just creates the dir in the unit? | 08:34 |
| Chipaca | as currently it's only able to write to /tmp/snaps/yadda | 08:34 |
| mvo | right | 08:34 |
| Chipaca | mvo: webdm creates it itself, from its init script | 08:34 |
| Chipaca | mvo: it had a bug, where it wasn't setting it 01777 | 08:35 |
| Chipaca | so other things failed after | 08:35 |
| mvo | yeah, I noticed that, I wonder if we could generalize that until the proper fix is in place | 08:35 |
| Chipaca | mvo: i'm not really sure that'll work for things that aren't as privileged as webdm though | 08:35 |
| Chipaca | i mean, by the time that runs it's already contained, right? | 08:35 |
| Chipaca | even the easy fixes involve either regenerating the unit files, or telling people to do so (by de/reinstalling) | 08:36 |
| mvo | Chipaca: I think we can run pre-start unconfied | 08:36 |
| mvo | re-generating> good point | 08:36 |
| Chipaca | ah, that would work | 08:36 |
| mvo | so proper fix sounds like the right plan of attack | 08:36 |
| Chipaca | so 'tis a bit of a mess | 08:36 |
| Chipaca | the only problem is that, because the "right" fix touches so many packages => lots of SRUs | 08:37 |
| Chipaca | (yay) | 08:37 |
| mvo | well, its not *too* terrible, we could also just create /tmp/snappy/snapname in your branch | 08:37 |
| mvo | I think we actually have to :/ | 08:38 |
| mvo | because we would have to re-generate unit files/exec files otherwise that already set TMPDIR | 08:38 |
| Chipaca | hah, inside the private tmp? | 08:38 |
| mvo | yeah | 08:38 |
| mvo | then its just one SRU (for now) and the other can follow as needed | 08:38 |
| Chipaca | mvo: also the apparmor profiles | 08:38 |
| mvo | well, we still want apparmor of course | 08:38 |
| mvo | to unblock the /tmp hardcorers^Whardcoders | 08:39 |
| Chipaca | so that's the three packages | 08:39 |
| Chipaca | oh, we'd avoid snappy | 08:39 |
| mvo | Chipaca: so plan of attack: add even more private /tmp/snaps/foo to private /tmp | 08:39 |
| mvo | do new image with that and all TMPDIR honoring people are good | 08:39 |
| mvo | then do apparmor to help the hardcoders | 08:40 |
| mvo | sensible? or am I missing something and need more tea? | 08:40 |
| Chipaca | TEMPDIR is not set for systemd | 08:40 |
| Chipaca | only TMPDIR | 08:40 |
| Chipaca | probably a bug in and of itself | 08:41 |
| mvo | aha, meh, ok. indeed | 08:41 |
| Chipaca | hmmmmm | 08:41 |
| mvo | I'm in favor of landing the launcher with the dir creation right away and then tackle the rest, that should already be a huge win | 08:41 |
| Chipaca | so, we'd look at TEMPDIR and create it, from the unprivileged section of the launcher | 08:41 |
| mvo | yep | 08:42 |
| Chipaca | land that, and TEMPDIR people are good, as you say | 08:42 |
| Chipaca | TMPDIR* | 08:42 |
| mvo | unless you have a different opinion, you looked into this way deeper than I did, I may miss something here | 08:42 |
| Chipaca | well, we need to look at either TMPDIR or SNAP_somethingsomehting | 08:42 |
| * mvo nods | 08:42 | |
| Chipaca | i'd say TMPDIR | 08:43 |
| mvo | we just create all of them :) hopefully its just one | 08:43 |
| Chipaca | so we can nuke the SNAP_TEMPDIR or whatever later on | 08:43 |
| mvo | aha, good point | 08:43 |
| mvo | yeah, lets do that and just use TMPDIR | 08:43 |
| mvo | it will be set to SNAP_TEMPDIR anyway IIRC | 08:43 |
| Chipaca | yes | 08:43 |
| Chipaca | and TEMPDIR is set to TMPDIR also, when it's set | 08:43 |
| Chipaca | mvo: if we land https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 does anything break automatically? | 08:44 |
| Chipaca | i mean, is that put onto images directly? | 08:44 |
| mvo | Chipaca: if we upoad it to the PPA it can land directly, or we do the full SRU dance which will take longer | 08:51 |
| Chipaca | mvo: i asked because we don't want it to land automatically until we do the "create /tmp/snaps" thing | 08:51 |
| Chipaca | mvo: which i'd rather was a follow-up branch | 08:51 |
| Chipaca | this one is already starting to mature | 08:51 |
| mvo | Chipaca: ok, we can simply wait with the top-approve | 08:51 |
| Chipaca | good point | 08:52 |
| Chipaca | i've got a recursive mkdir in bzr history, will fish it out and propose the mp in a bit | 08:52 |
| mvo | \o/ | 08:52 |
| === kickinz1|afk is now known as kickinz1 | ||
| Chipaca | i lied, i have _half_ a recursive mkdir of the sort we want | 09:10 |
| Chipaca | anyway, doing it | 09:10 |
| Chipaca | mvo: like so: https://code.launchpad.net/~chipaca/ubuntu-core-launcher/mktmpdir/+merge/259908 | 09:39 |
| mvo | Chipaca: yeah | 09:43 |
| === retrack is now known as Guest87705 | ||
| mvo | Chipaca: I reviewed/merged/uploaded now, once that hits the PPA I will create a test image to verify that it all works | 10:42 |
| mvo | works for real | 10:42 |
| Chipaca | +1 | 10:42 |
| * mvo gets lunch while waiting for the image | 10:44 | |
| * Chipaca -> coffee | 10:44 | |
| mvo | Chipaca: hm, do you happen to have the bugnumber for the tmp issue ? if not I can try to find it | 11:02 |
| Chipaca | mvo: i don't | 11:02 |
| * mvo will find it | 11:03 | |
| Chipaca | mvo: there is one? | 11:03 |
| mvo | Chipaca: *cough* now there is https://bugs.launchpad.net/snappy/+bug/1457839 | 11:04 |
| ubottu | Ubuntu bug 1457839 in Snappy "TMPDIR not availalble for snappy services" [Undecided,New] | 11:04 |
| Chipaca | mvo: \o/ | 11:04 |
| Chipaca | mvo: cmp-test needing a commit message | 11:15 |
| * Chipaca curses at dirs.go | 11:33 | |
| === soee_ is now known as soee | ||
| * Chipaca is stuck | 11:50 | |
| * Chipaca stops for lunch | 11:50 | |
| Chipaca | mvo: you around? | 12:13 |
| mvo | Chipaca: yes | 12:15 |
| Chipaca | mvo: hiya. have you an opinion around the “Part” interface? AIUI the name wasn't well-loved | 12:15 |
| mvo | Chipaca: no strong opinion either way, I don't mind the name but if there is a suggestion for a better one I'm all ears :) | 12:16 |
| Chipaca | mvo: well, it's moving to its own package | 12:17 |
| Chipaca | or to the "pkg" pacakge | 12:17 |
| mvo | aha | 12:17 |
| Chipaca | and am wondering whether to leave it as pkg.Part, pkg.Interface, or something else | 12:17 |
| mvo | both is fine with me | 12:18 |
| mvo | maybe interface is indeed cleaner | 12:18 |
| sergiusens | morning | 12:18 |
| Chipaca | mo'in! | 12:18 |
| sergiusens | mvo: did you get to the bttom of this? "[ 18.214558] FAT-fs (mmcblk0p1): IO charset iso8859-1 not found | 12:19 |
| sergiusens | Chipaca: are we making the interface smaller? | 12:19 |
| mvo | sergiusens: no, not yet :/ | 12:19 |
| Chipaca | sergiusens: the Part interface? | 12:19 |
| sergiusens | mvo: I'm seeing it myself now too, after upgrading | 12:19 |
| Chipaca | sergiusens: wasn't in my plans, no | 12:20 |
| sergiusens | Chipaca: yeah | 12:20 |
| Chipaca | trying to focus on making snappy/* smaller | 12:20 |
| mvo | sergiusens: oh, nice. and you fall into a recovery shell? | 12:20 |
| sergiusens | Chipaca: just move first is all? | 12:20 |
| Chipaca | i get distracted too easily as it is :) | 12:20 |
| Chipaca | sergiusens: yeah | 12:20 |
| sergiusens | Chipaca: should I hold off on moving frameworks to /frameworks? | 12:20 |
| Chipaca | sergiusens: but if you think we should split it, that might make naming it easier | 12:20 |
| Chipaca | sergiusens: how would you split it? | 12:20 |
| sergiusens | Chipaca: let me check the interface | 12:20 |
| Chipaca | sergiusens: having tried again to split click/snappy out and failed (too big a branch), i'm working backwards and moving the interfaces out. that is, repository and part | 12:21 |
| Chipaca | i can just move them without renaming them too :) but where's the fun in that | 12:23 |
| sergiusens | Chipaca: heh, I can't think of any better way | 12:27 |
| sergiusens | Chipaca: except the minor thing of calling Uninstall Remove to match the leangua franca | 12:27 |
| Chipaca | sergiusens: heh | 12:27 |
| sergiusens | Chipaca: I would move out Frameworks though as only apps depend on frameworks | 12:27 |
| sergiusens | so it's too specific | 12:28 |
| Chipaca | ok, so i'll do snappy.Part -> pkg.Part, and snappy.Repository -> repo.Repository | 12:28 |
| sergiusens | Chipaca: and I'd rename SetActive to Activate (used for rollback/kick and switch) | 12:28 |
| Chipaca | let's see how that goes | 12:28 |
| Chipaca | easier to rename after move anyways | 12:29 |
| Chipaca | sergiusens: ack | 12:29 |
| sergiusens | Chipaca: how about s/Part/Package/ ? | 12:29 |
| Chipaca | sergiusens: and then it'd be pkg.Package ? | 12:29 |
| sergiusens | Chipaca: pkg.Interface ? :-P | 12:29 |
| Chipaca | mhmm | 12:29 |
| Chipaca | that was my original question, more or less :) | 12:30 |
| sergiusens | Chipaca: then pkg.Snap | 12:30 |
| Chipaca | on the other hand, pkg.Package would make the docs fun to write | 12:30 |
| Chipaca | sergiusens: there's already *two* other things we're calling snap | 12:30 |
| sergiusens | Chipaca: bummer | 12:30 |
| sergiusens | Chipaca: maybe pkg is the wrong name as well ;-) | 12:30 |
| Chipaca | fo sure | 12:31 |
| Chipaca | i chose it myself; it's got a p=.78 of being wrong | 12:31 |
| sergiusens | Chipaca: and maybe we need to remove other things from snappy and keep this stuff in there | 12:31 |
| Chipaca | sergiusens: yeah, i'm reating this and that as symmetrical | 12:31 |
| Chipaca | ie moving things out of snappy as the same as moving the complement out | 12:31 |
| Chipaca | at some point | 12:32 |
| Chipaca | maybe | 12:32 |
| sergiusens | Chipaca: I'd remove the complement out and use snappy.[Part|Package] | 12:32 |
| sergiusens | Chipaca: and complicate your life with the go pkg names you need to come up with :-P | 12:32 |
| Chipaca | sergiusens: at some point, webdm would be talking to a thing that just knew about interfaces (Part, Repository) and the toplevel install/remove/etc methods | 12:33 |
| sergiusens | Chipaca: even less; the restful api | 12:33 |
| Chipaca | and the nitty gritty would be tucked under pkg/ (or whatever that gets renamed to) | 12:33 |
| Chipaca | sergiusens: ok, so the restful api would be built on * | 12:33 |
| Chipaca | :) | 12:33 |
| sergiusens | Chipaca: hangout to design? | 12:33 |
| Chipaca | this chumminess is mind-splitting | 12:34 |
| Chipaca | sergiusens: https://plus.google.com/hangouts/_/canonical.com/de-sign?authuser=1 | 12:34 |
| sergiusens | Chipaca: http://dave.cheney.net/2015/05/12/introducing-gb https://walledcity.com/supermighty/building-go-projects-with-gb http://getgb.io/ | 12:48 |
| Chipaca | sergiusens: ta muchly | 12:48 |
| mvo | sergiusens: heh :) you keep seeling gb ;) | 12:50 |
| Chipaca | mvo: i'm sold already :) | 12:55 |
| Chipaca | mvo: but i'd lost that last link | 12:55 |
| Chipaca | turns out, living in the uk, searching for "gb" isn't too helpful | 12:56 |
| sergiusens | mvo: have you read about it yet? | 12:56 |
| Chipaca | and wouldn't you know, "go gb" isn't much helpfuler | 12:56 |
| sergiusens | Chipaca: I search for gb cheney ;-) | 12:56 |
| Chipaca | oooh, look at him, with his fancy search terms | 12:57 |
| mvo | sergiusens: yes, well, sort of - if I understand it correctly it means our repo grows by the size of our dependencies? or is there a shorthand way, i.e. gb.txt with link-to-repo,revno pairs? | 12:57 |
| sergiusens | mvo: it all goes in there, yeah | 12:59 |
| sergiusens | mvo: advantage is, you bzr branch lp:snappy; cd snappy; gb build | 13:00 |
| jdstrand | Chipaca, mvo: fyi, I had filed these before: bug #1449625 and bug #1448225 | 13:11 |
| nothal | Bug #1449625: systemd and bin-path exported variables are not in sync <Snappy:Triaged> <http://launchpad.net/bugs/1449625> | 13:11 |
| nothal | Bug #1448225: webdm apparmor denials <Snappy:New> <http://launchpad.net/bugs/1448225> | 13:11 |
| ubottu | bug 1449625 in Snappy "systemd and bin-path exported variables are not in sync" [High,Triaged] https://launchpad.net/bugs/1449625 | 13:11 |
| ubottu | bug 1448225 in Snappy "webdm apparmor denials" [Undecided,New] https://launchpad.net/bugs/1448225 | 13:11 |
| jdstrand | Chipaca, mvo: the second is your services don't have a TMPDIR bug | 13:11 |
| Chipaca | jdstrand: those rules aren't in the policy yet? | 13:12 |
| Chipaca | i missed that | 13:12 |
| jdstrand | so, I discussed this yesterday | 13:13 |
| Chipaca | ruh roh | 13:13 |
| jdstrand | I long time ago when setting up TMPDIR, I said that apparmor will only allow the create of the version part of the TMPDIR | 13:13 |
| jdstrand | everything above it must be created by something else | 13:13 |
| Chipaca | ah, ok | 13:14 |
| Chipaca | that's fine | 13:14 |
| Chipaca | that's in the pipeline :) | 13:14 |
| jdstrand | now, I happened to not agree with having a versioned TMPDIR, but that is beside the point-- that was the decision taken | 13:14 |
| Chipaca | jdstrand: the unshare thing does away with the version, does a mkdtemp and uses that | 13:15 |
| jdstrand | yes | 13:15 |
| Chipaca | jdstrand: although we're creating the versioned one short-term for compat | 13:15 |
| Chipaca | so we don't have to change everything in stable | 13:15 |
| Chipaca | jdstrand: creating it in the unprivileged part of the launcher, that is | 13:16 |
| Chipaca | just before apparmor | 13:16 |
| Chipaca | (so whether it's *actually* unprivileged is arguable; it depends on whether it's called as root or not) | 13:16 |
| jdstrand | fyi, (some of) the discussion of the current implementation happened here: https://bugs.launchpad.net/snappy/+bug/1400320 | 13:17 |
| ubottu | Error: ubuntu bug 1400320 not found | 13:17 |
| Chipaca | jdstrand: 404 for me too :) | 13:17 |
| * jdstrand makes said bug public | 13:17 | |
| mvo | jdstrand: oh, thanks, I knew there was a open one but I didn't find it :/ | 13:18 |
| jdstrand | yeah, it was lumped in with another (that was fixed) and kinda hidden | 13:18 |
| Chipaca | ok | 13:19 |
| Chipaca | i'm assuming the bind sidesteps overlayfs | 13:19 |
| jdstrand | it does | 13:19 |
| jdstrand | so, what is the relationship being 'rolling' and 'devel', if any? | 13:20 |
| jdstrand | https://developer.ubuntu.com/en/snappy/guides/channels/ only discusses 15.04 and rolling | 13:20 |
| jdstrand | $ ubuntu-device-flash query --list-channels --device=generic_amd64 | grep core | 13:22 |
| jdstrand | ubuntu-core/devel | 13:22 |
| jdstrand | ubuntu-core/devel-proposed | 13:22 |
| jdstrand | ubuntu-core/rolling/edge | 13:22 |
| jdstrand | ubuntu-core/15.04/stable | 13:22 |
| jdstrand | ubuntu-core/15.04/edge | 13:22 |
| jdstrand | ubuntu-core/rolling/alpha | 13:22 |
| jdstrand | are devel and devel-proposed just historical and we shouldn't use them? | 13:22 |
| jdstrand | slangasek, mvo: ^ | 13:22 |
| === vrruiz is now known as rvr | ||
| mvo | jdstrand: I think they are historic, but slangasek will confirm | 13:25 |
| jdstrand | ok, yeah, it doesn't have tha edge, alpha, etc bits in there. that makes sense if they are historical | 13:26 |
| jdstrand | mvo: thanks-- I'm trying to put together some docs for the security team for testing and update procedures | 13:31 |
| sergiusens | jdstrand: devel (not what you see in the channel listing) is what may become the name for rolling | 13:34 |
| jdstrand | mvo: fyi, https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#system-image_updates_.28DRAFT.29 | 13:34 |
| jdstrand | sergiusens: can you clarify? | 13:35 |
| jdstrand | rolling is not set in stone yet? | 13:35 |
| ogra_ | in rolling stone :) | 13:35 |
| jdstrand | hehe | 13:35 |
| sergiusens | jdstrand: I think mark wanted to go with devel instead of rolling and we went with rolling as it was already like that in the store | 13:36 |
| mvo | sergiusens: oh? so rolling may get renamed - I knew why I said "maybe" :) | 13:36 |
| jdstrand | hehe | 13:37 |
| sergiusens | jdstrand: btw, did you have a chance to look into my question about $origin? | 13:37 |
| Chipaca | we should rename it to trolling | 13:38 |
| jdstrand | ok, so ubuntu-core/devel and ubuntu-core/devel-proposed may leave, then rolling may be changed to ubuntu-core/devel/edge, ubuntu-core/devel/alpha, etc | 13:38 |
| jdstrand | I'll just keep an eye on it and adjust as necessary | 13:38 |
| sergiusens | jdstrand: as in using the layout of "$pkgtype"s/$pkgname/$origin/$version (where package type is framework, app or oem? | 13:38 |
| sergiusens | jdstrand: correct | 13:38 |
| jdstrand | sergiusens: I didn't-- where was this question? | 13:38 |
| * jdstrand hasn't gotten to his inbox yet) | 13:38 | |
| sergiusens | jdstrand: it was over irc, so maybe no inbox to check :) | 13:39 |
| sergiusens | jdstrand: the question in itself is getting the policies to know about $origin to map the paths in the template I guess | 13:39 |
| jdstrand | I was having connection issues yesterday. I don't see it... | 13:40 |
| jdstrand | sergiusens: can you state the whole question? | 13:40 |
| sergiusens | jdstrand: it was two days ago, but no worries | 13:40 |
| jdstrand | sorry, I missed it | 13:40 |
| jdstrand | I think I see it | 13:41 |
| jdstrand | not the question, but can infer from backscroll | 13:41 |
| jdstrand | (here) | 13:41 |
| jdstrand | so the basic idea is you'd like to split up apps, oem snaps and frameworks | 13:41 |
| sergiusens | jdstrand: I'm going to start storing the origin of packages locally, initially we went with pkgname.origin for everything and slowly close to release we dropped it for frameworks and oem packages | 13:41 |
| jdstrand | ok, so there are two parts | 13:42 |
| sergiusens | jdstrand: the splitting is tangential and I guess it doesn't impact apparmor in any way | 13:42 |
| jdstrand | there is storing stuff in pkgtype | 13:42 |
| jdstrand | and also storing origin in the path | 13:42 |
| jdstrand | the splitting is not tangential and does affect apparmor | 13:42 |
| jdstrand | well, it may be tangential | 13:42 |
| jdstrand | but it does affect apparmor | 13:42 |
| sergiusens | jdstrand: right, there are two problems is what I wanted to say :-) | 13:43 |
| jdstrand | so we'd have to coordinate that change as well | 13:43 |
| jdstrand | that one is not particularly difficult or contentious | 13:43 |
| jdstrand | why are we adding origin back for frameworks? a quality of frameworks is they can't be forked and adding the origin to the path complicates/muddies apparmor policy and makes it difficult for apps depending on the framework to use the right path | 13:45 |
| sergiusens | jdstrand: we don't need it in the path | 13:45 |
| jdstrand | ie, /frameworks/docker.sideload vs /frameworks/docker.canonical | 13:45 |
| sergiusens | jdstrand: but it becomes hard to snappy switch the sideloaded version and the store one | 13:45 |
| jdstrand | what is owncloud supposed to use? | 13:45 |
| jdstrand | I'm confused. you said before you want "$pkgtype"s/$pkgname/$origin/$version" but just now said "we don't need it in the path" | 13:46 |
| sergiusens | jdstrand: sorry I meant the package name | 13:47 |
| sergiusens | jdstrand: the package name would still be docker, the path to the stored data would be different | 13:47 |
| jdstrand | sure | 13:47 |
| ogra_ | hmm | 13:47 |
| jdstrand | but then owncloud still doesn't know | 13:48 |
| jdstrand | /frameworks/docker/sideload vs /frameworks/docker/canonical | 13:48 |
| ogra_ | looking at https://developer.ubuntu.com/en/snappy/guides/config-command/ ... is there no way to do something like: "snappy config ubuntu-core hostname=foo" ? | 13:48 |
| sergiusens | jdstrand: so we need some mechanism like 'current' but for the package path | 13:48 |
| jdstrand | we could fix owncloud easy enough with a symlink | 13:48 |
| jdstrand | right | 13:49 |
| jdstrand | then that means that only framework policy is muddied | 13:49 |
| jdstrand | so, the policy itself could have: | 13:50 |
| jdstrand | /frameworks/docker/*/*/foo r, | 13:50 |
| jdstrand | but then there is still the issue of the framework policy filenames themselves (which are what reverse depends snaps use) | 13:51 |
| jdstrand | ie | 13:51 |
| sergiusens | jdstrand: two *, one for origin and the other for version? | 13:51 |
| jdstrand | ls /var/lib/snappy/apparmor/policygroups | 13:51 |
| jdstrand | docker_client | 13:51 |
| jdstrand | owncloud uses caps: [ docker_client ] | 13:51 |
| jdstrand | sergiusens: re '*', yes | 13:52 |
| jdstrand | sergiusens: we have to do that for testing-- ie, if kick inz1 sideloads the docker snap to test, if if has /frameworks/docker/canonical/ the sideload scenario breaks | 13:53 |
| jdstrand | I guess we could do: | 13:53 |
| jdstrand | /frameworks/docker/{canonical,sideload}/*/foo r, | 13:53 |
| jdstrand | that would be somewhat better | 13:53 |
| jdstrand | but you can see what I mean by things being muddied | 13:53 |
| jdstrand | assuming that was acceptable | 13:54 |
| jdstrand | there is still the filename in /var/lib/snappy/apparmor/policygroups | 13:54 |
| sergiusens | jdstrand: yeah, so the question is which is cleaner, doing this or treating sideloads as coming from the same origin (and if so, we may need to block freely sideloading for frameworks) | 13:54 |
| jdstrand | currently it technically isn't a problem because we aren't allowing multiple forks to be installed | 13:55 |
| jdstrand | but as soon as we have origin in the name, it is super slippery to say why don't we allow forks of frameworks? | 13:55 |
| jdstrand | I don't think we need to block freely sideloading frameworks | 13:56 |
| jdstrand | we are we protecting the user from his/herself? | 13:56 |
| sergiusens | jdstrand: I see your points; I'll give sideloading some more thought, but it's the only reason I see it usable for frameworks | 13:56 |
| jdstrand | s/his/him/ | 13:57 |
| sergiusens | jdstrand: that and something pointed out to me about symmetry directory, but that is not relevant :-) | 13:57 |
| jdstrand | sergiusens: so I'm not saying we *cannot* have origin in the path; I'm saying it's complicated | 13:58 |
| jdstrand | and it would need to be very carefully implemented and coordinated | 13:58 |
| jdstrand | but I've not been able to think of something that is wholly satisfying | 13:59 |
| jdstrand | eg, say we say the path is ok, and we assume that the policy content can be dealt with well enough, then it comes down to the path of the cap | 14:00 |
| sergiusens | jdstrand: sure, but if there is no use for it, I would rather not do it; we need to be able to cleanly update from 15.04 to $next in some way (won't be automatic) and have an upgrader that can translate all the changes that happened during rolling | 14:00 |
| jdstrand | we could install /var/lib/snappy/apparmor/policygroups/docker.canonical_client | 14:00 |
| jdstrand | and then tooling could be smart to know that 'caps: [docker_client]' actually means /var/lib/snappy/apparmor/policygroups/docker.canonical_client | 14:01 |
| jdstrand | but, then there is a disparity between what the user declares and sees on disk, and things get more complicated implementation wise | 14:01 |
| om26er | is there a snap for vim ? | 14:01 |
| ogra_ | om26er, no | 14:01 |
| ogra_ | om26er, i tried to make one once, but the restrictions back then made it rather impossible to use | 14:02 |
| om26er | ogra_, is it doable now ? | 14:02 |
| sergiusens | jdstrand: right, I'll table this for now | 14:02 |
| jdstrand | one thing we *cannot* do (based on all conversations up until now) is have apps say: "caps: [docker.canonical_client]" | 14:03 |
| ogra_ | we might be closer but i think you would setill need to break out of confinement | 14:03 |
| sergiusens | jdstrand: and see if I can play aroun a bit; and I agree, no docker.canonical_client is a hard req | 14:03 |
| jdstrand | that would solve almost everything (except sideloading, cause docker.sideload_client...) | 14:03 |
| sergiusens | *, it is a hard req | 14:03 |
| ogra_ | om26er, http://people.canonical.com/~ogra/snappy/snaps/ ... (not sure it still works though, thats rather old ... ) | 14:03 |
| jdstrand | but it is ugly, bad dev experience, etc, etc) | 14:04 |
| ogra_ | om26er, with that you can only edit files inside the /var/apps/vim.ogra/ dir though | 14:04 |
| jdstrand | sergiusens: ok, that's fine | 14:04 |
| ogra_ | (or /var/lib/apps ...) | 14:04 |
| sergiusens | jdstrand: I do have another topic... | 14:04 |
| jdstrand | sergiusens: I'm here to discuss more if you come up with something | 14:04 |
| sergiusens | jdstrand: do you know why we removed the origin from oem snaps? | 14:04 |
| om26er | ogra_, aah, heh thats pretty useful :p | 14:04 |
| ogra_ | heh | 14:05 |
| jdstrand | sergiusens: otoh, no-- I don't think that came from me. I do remember someone coming to the conclusion that "apps themselves are actually the exception, because they are the only thing that supports forks" | 14:05 |
| ogra_ | om26er, i guess you could add ~/bin to your PATH and just dump a vim into /home/ubuntu/bin for the moment | 14:05 |
| jdstrand | sergiusens: maybe something with config? (wild guess) | 14:06 |
| jdstrand | or hw-assign? | 14:06 |
| jdstrand | I can't recall | 14:06 |
| jdstrand | I think I only had one ear listening at the time cause I was working on 'bus-name' | 14:06 |
| jdstrand | om26er: fyi, there is supposed to be a 'comfy' snap at somepoint that will have all these types of tools | 14:07 |
| ogra_ | at some point :) | 14:07 |
| jdstrand | yes | 14:08 |
| sergiusens | jdstrand: ok, beuno was the one asking why, I'm fine with no switch/forks for oem snaps as they are special as well | 14:09 |
| om26er | jdstrand, that will be a help! | 14:09 |
| jdstrand | sergiusens: /me nods | 14:09 |
| jdstrand | sergiusens: I just don't remember | 14:10 |
| sergiusens | jdstrand: in the end, only "snappy apps" can be forked | 14:11 |
| jdstrand | yeah | 14:11 |
| sergiusens | and we need to figure out some clean way to sideload | 14:11 |
| om26er | ogra_, I'll try that. I am getting started so that eventually I could achieve some type of automation, including home brewed IoT ;) | 14:12 |
| jdstrand | simplest is to not allow a snap to be sideloaded at the same time as the one with the store | 14:12 |
| jdstrand | then do a symlink from pkgname -> pkgname.sideload | 14:12 |
| jdstrand | now, that is simple, but I've not thought it all through of course | 14:12 |
| jdstrand | or maybe the other way | 14:13 |
| jdstrand | yes, the other way is simpler | 14:13 |
| jdstrand | oem and frameworks don't have origin in their name | 14:13 |
| jdstrand | so you sideload, it still doesn't have it in the name, but then you have pkgname.sideload -> pkgname | 14:13 |
| jdstrand | but then, I don't know what we are trying to solve here | 14:14 |
| jdstrand | so best I not try to suggest an implementation :) | 14:14 |
| sergiusens | jdstrand: I have was to store the origin in the works that does not depend on mangling with the path | 14:18 |
| sergiusens | jdstrand: the only change that would affect apparmor in motion is the move of frameworks to their own dir /frameworks | 14:18 |
| jdstrand | sergiusens: perhaps dropping .sideload into the install directory? | 14:18 |
| jdstrand | or somewhere else that you could check | 14:19 |
| sergiusens | jdstrand: I don't want to mangle the install directory as that is the packagers area | 14:19 |
| jdstrand | /var/lib/snappy/sideloads/docker | 14:19 |
| jdstrand | that could even be a symlink to /frameworks/docker | 14:19 |
| jdstrand | these are obviously just otoh | 14:19 |
| sergiusens | jdstrand: jdstrand http://snappy.asac.ws:9001/p/dot.store | 14:19 |
| jdstrand | and yes, I agree not adding to install path | 14:20 |
| sergiusens | om26er: do you still have issues with snappy config? | 14:31 |
| om26er | sergiusens, no? might be someone else. | 14:33 |
| ogra_ | sergiusens, you mean me ? | 14:34 |
| sergiusens | ogra_: yes | 14:39 |
| ogra_ | sergiusens, well, is there any commandline way to use snappy config to set a value for a key ? | 14:39 |
| ogra_ | the doc doesnt show any | 14:40 |
| sergiusens | ogra_: you need to pipe/redirect in | 14:40 |
| ogra_ | bah, really ? | 14:40 |
| elopio | are you sure that I only have to insert the sd card on the beagle and boot to ubuntu? | 14:40 |
| elopio | now I have the serial cable, and it shows me that the board is booting in debian. | 14:40 |
| sergiusens | ogra_: or like this https://gist.github.com/sergiusens/8d4d2b99b2e5d87c7a50 | 14:40 |
| ogra_ | elopio, depends on the board (there are many beaglebones ) | 14:40 |
| ogra_ | elopio, some require you to hold down the S2 button to boot from SD | 14:40 |
| elopio | ogra_: beaglebone black rev C | 14:40 |
| sergiusens | elopio: sometimes you have to press and hold a micro switch (I had to on that model) | 14:41 |
| ogra_ | sergiusens, ugh, why did we make it so ugly | 14:41 |
| sergiusens | ogra_: I didn't design it ;-) | 14:41 |
| sergiusens | ogra_: I do want to improve it and want to talk to mvo about it eventually | 14:42 |
| * ogra_ would have expected something llike "snappy config <package> key=foo" or "snappy config <package> section:key=foo" | 14:42 | |
| ogra_ | or some such | 14:42 |
| sergiusens | ogra_: that's what set is for, but for other things | 14:42 |
| sergiusens | ogra_: everything is a yaml is the mantra | 14:43 |
| ogra_ | yeah, thats awful for plain cmdline use | 14:43 |
| ogra_ | piping and sed'ing HERE docs around ... omg :) | 14:43 |
| sergiusens | ogra_: HERE? | 14:55 |
| ogra_ | http://tldp.org/LDP/abs/html/here-docs.html | 14:56 |
| ogra_ | (it isnt exactlyy one ... since you use a var there) | 14:56 |
| sergiusens | ogra_: you can put that in the oem snap in the config section as well | 14:58 |
| elopio | sergiusens: do you have to press the boot button, and use the 5V power? Pressing the button and inserting the usb cable doesn't light the leds here. | 14:59 |
| ogra_ | sergiusens, yeah, i dont care about the snap ... i care about the admin who wants to change a config setting | 15:03 |
| ogra_ | the yaml makes all sens inside the snap | 15:04 |
| ogra_ | just not as a tool for config adjustments | 15:04 |
| slangasek | jdstrand, mvo_: yes, historical; I can set those up to auto-migrate users to the rolling/edge and rolling/alpha channels but it hasn't been a priority | 15:19 |
| slangasek | jdstrand, mvo_: maybe we should just drop them to avoid confusion, but I'm not sure all the public references to them have gone away yet | 15:20 |
| jdstrand | slangasek: cool, thanks for the confirmation. don't auto-migrate on my account. I'm just trying to document what the security team should use to generate VMs | 15:20 |
| sergiusens | elopio: no 5V, don't do that! | 15:48 |
| elopio | sergiusens: "You should use a 5V external power source, USB power may not work" | 15:48 |
| elopio | not the red cable. | 15:49 |
| ogra_ | yeah | 15:49 |
| ogra_ | either use the micro USB port or a 5V barrel connector | 15:49 |
| tbr | you can remove the need for the boot button by nuking mlo on the emmc | 16:00 |
| ogra_ | does that work eh same on all versions/revisions/bulds of the board ? | 16:01 |
| ogra_ | *the ... | 16:02 |
| tbr | yes | 16:02 |
| tbr | if you want to go alien on it, just dd if=/dev/null of=$emmc bs=1M count=1 | 16:03 |
| tbr | mounting the right partition (IIRC it's FAT16 or FAT32) and removing 'mlo' is somehow more elegant, but if someone decided to put mlo on the emmc in one of the other locations checked by ROMBL... | 16:04 |
| ogra_ | yeah | 16:05 |
| tbr | I'm going to boot this board. see what it has on the emmc (probably an ancient angst-rom) | 16:06 |
| ogra_ | heh, yeah | 16:06 |
| ogra_ | elopio it trying to improve the install doc btw | 16:07 |
| tbr | another option is to reconfigure uboot on the emmc, but then you need to be sure it's recent enough | 16:07 |
| ogra_ | so if you have hits for him that are generic, they are surely welcome | 16:07 |
| ogra_ | yeah, i dont think we are always sure of that | 16:08 |
| tbr | I think nuking mlo is the option where you will at least be reasonably sure you found the right thing and nuked it. the others might be a bit voodoo | 16:08 |
| ogra_ | yeah | 16:09 |
| elopio | now it's booting snappy, without pressing any buttons. | 16:10 |
| elopio | my board is haunted. | 16:10 |
| ogra_ | thats the beagle inside :) | 16:11 |
| elopio | Ubuntu 15.04 localhost.localdomain ttyO0 | 16:11 |
| ogra_ | nice ! | 16:11 |
| ogra_ | congrats | 16:11 |
| elopio | shouldn't that say webdm.local ? | 16:11 |
| ogra_ | no | 16:11 |
| ogra_ | .local is a avahi name ... only usable via the avahi7bonjour protocol | 16:12 |
| ogra_ | *avahi/bonjour | 16:12 |
| tbr | might still be using the emmc uboot though | 16:12 |
| ogra_ | then you wouldnt end up in snappy | 16:12 |
| elopio | ogra_: what I can't do is to ssh ubuntu@webdm.local, as the guide says. | 16:13 |
| ogra_ | the emmc uboot is lacking features | 16:13 |
| ogra_ | elopio, right, because your PC resolves avahi | 16:13 |
| tbr | k | 16:13 |
| ogra_ | elopio, if you try that from your ubuntu phone which doesnt ship an avahi client it wont work (but ssh ubuntu@IP will work) | 16:13 |
| ogra_ | webdm.local is simply something provided by a snap ... not actually something provided by the system itself ... so localhos.localdomain is correct (until you set a hostname) for the system layer | 16:14 |
| tbr | jftr, on this angstrom emmc image it's in /dev/mmcblk0p1 (as seen when booted from emmc!) | 16:22 |
| kyrofa | sergiusens, ping | 16:22 |
| jdstrand | sergiusens: hey, I'm looking at https://developer.ubuntu.com/en/snappy/guides/channels/ | 17:36 |
| jdstrand | sergiusens: I want to create a kvm image with ubuntu-core/15.04/alpha | 17:36 |
| jdstrand | sergiusens: but I can't get the udf invocation right | 17:37 |
| jdstrand | I thought this would do it from reading: sudo ubuntu-device-flash core --channel=ubuntu-core/15.04/alpha --size=8 --enable-ssh --output=15.04-alpha.img | 17:37 |
| jdstrand | but it doesn't (says I need a release) | 17:37 |
| jdstrand | so I try other things and it doesn't work | 17:37 |
| jdstrand | I'm on vivid | 17:37 |
| jdstrand | I thought this might: | 17:38 |
| jdstrand | sudo ubuntu-device-flash core --channel=alpha --size=8 --enable-ssh --output=15.04-alpha.img 15.04 | 17:38 |
| jdstrand | but then got: | 17:38 |
| jdstrand | Channel ubuntu-core/15.04/alpha not found on server https://system-image.ubuntu.com | 17:38 |
| * jdstrand tries other things | 17:38 | |
| jdstrand | maybe I should try edge for now | 17:39 |
| jdstrand | sudo ubuntu-device-flash core --channel=edge --size=8 --enable-ssh --output=15.04-alpha.img 15.04 worked | 17:40 |
| jdstrand | sergiusens: it's weird that I can use --channel=ubuntu-touch/rc-proposed/ubuntu with ubuntu-emulator but not with udf | 17:43 |
| jdstrand | sergiusens: and I appear to be able to use --channel=ubuntu-touch/rc-proposed/ubuntu with udf for touch, but not that style when specifying 'core' | 17:47 |
| * jdstrand files a bug | 17:47 | |
| jdstrand | sergiusens: fyi, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1458006 | 17:53 |
| ubottu | Ubuntu bug 1458006 in goget-ubuntu-touch (Ubuntu) "inconsistent invocation between touch and core" [Undecided,New] | 17:53 |
| tgm4883 | so snappy apps only let me write to two specific directories. Is there any functionality to allow writing to USB drives and/or a way to mount network storage? | 18:12 |
| tgm4883 | I would prefer the network storage route | 18:12 |
| D_Cent | hi - i'm looking for an avahi server on snappy ubuntu core (on a raspberry pi 2). can anyone tell me how to get that running? | 18:17 |
| D_Cent | well, basically i just need some service which makes the raspberry pi discoverable over the network without knowing its IP | 18:29 |
| noise][ | anyone here hacking on GPIO stuff on the beagleboard? | 18:34 |
| noise][ | apparently i need device-tree-compiler to setup 1wire support (for a temp sensor) | 18:35 |
| ash_charles | D_Cent: IIRC, webdm publishes the device name using avahi---that might be a good place to start looking. | 18:36 |
| elopio | D_Cent: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/files/head:/avahi/ | 18:41 |
| D_Cent | thank you, ash_charles and elopio! | 18:43 |
| sergiusens | jdstrand: it's because for core we introduced the new concept of channel and for touch and the emulator we are using the system-image concept of a channel | 19:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!