| === robert_ancell_ is now known as robert_ancell | ||
| zyga | good morning | 08:40 |
|---|---|---|
| didrocks | hey zyga | 08:42 |
| noizer | good morning! | 08:49 |
| zyga | hey :) | 08:57 |
| zyga | how are you doing | 08:57 |
| zyga | (zero days since the last terminology change ;) | 08:57 |
| dholbach | put that in the topic :) | 08:58 |
| ogra_ | capaskillfaces ! | 09:01 |
| zyga | ogra_: now you have to read that backwards | 09:01 |
| ogra_ | heh | 09:01 |
| ogra_ | security imlpementation du jour: "interfaces with reversed plugs, 9,90€ ... kids plate, 6,50€" | 09:02 |
| zyga | ogra_: uk plugs or us plugs? | 09:03 |
| * zyga falls screaming into the abyss | 09:03 | |
| ogra_ | doesnt matter as long as they are reversed :) | 09:03 |
| * ogra_ wishes we would actually care for some stability inseatd | 09:03 | |
| zyga | ogra_: nah, this doesn't affect stability in any way | 09:04 |
| zyga | ogra_: I'm glad we changed it, it was backwards | 09:04 |
| ogra_ | zyga, it occupies dev rtecources | 09:04 |
| ogra_ | *ressources | 09:04 |
| zyga | ogra_: and saves user resources later on | 09:05 |
| ogra_ | i still cant use classic on arm64 ... i still can install all gadget snaps from froreign arches | 09:05 |
| ogra_ | (on a running system) | 09:05 |
| zyga | ogra_: well, different resources | 09:05 |
| ogra_ | webdm doesnt really work | 09:05 |
| ogra_ | etc etc | 09:05 |
| zyga | ogra_: webdm has tons of love lately | 09:05 |
| ogra_ | there are tonms of things that need fixing before release | 09:05 |
| zyga | ogra_: yeah, I know | 09:05 |
| ogra_ | but we are changing terminology of core features instead | 09:06 |
| zyga | ogra_: we're all working towards getting there | 09:06 |
| ogra_ | zyga, by 16.10 ? | 09:06 |
| zyga | ogra_: 16.04! | 09:06 |
| ogra_ | what we have today isnt release worthy yet and still needs liots of work on all levels ... | 09:06 |
| zyga | ogra_: in reality renames only affected my work | 09:06 |
| ogra_ | zyga, and everyone who has snaps in the store | 09:08 |
| ogra_ | (or who wants to have them in the store for release) | 09:08 |
| zyga | ogra_: they didn't use interfaces yet, they will but nothing in the store uses them now | 09:08 |
| ogra_ | all my (three yet, because i gave up packaging when there was the announcement) snaps use them with migration-skill | 09:09 |
| zyga | mmmm, okay, I give you that | 09:09 |
| === zenlot6 is now known as zenlot | ||
| ogra_ | and i have a few more that i had to re-do from scratch three times ... | 09:10 |
| ogra_ | for me thats fine, but for people that want their stuff in the store for release it is probably not | 09:10 |
| sergiusens | ogra_, hey, I'm late to the party; my 410c boots android and can't make it boot from the sdcard (using your image on p.c.c); any ideas? | 09:20 |
| noizer | How can i make from my app a service so I can start and stop it with the rest api? | 09:21 |
| noizer | zyga | 09:26 |
| zyga | noizer: you'd have to talk to snapd and use an appropriate request, you'd also need an interface to talk to snapd in the first place (I'm making one) | 09:26 |
| zyga | noizer: a bit busy now, perhaps it's not all ready yet but that's the idea | 09:26 |
| noizer | hmmm | 09:28 |
| zyga | noizer: you want snappy services but I'm not sure if that's on the rest api today | 09:29 |
| noizer | zyga https://developer.ubuntu.com/en/snappy/guides/rest/ | 09:30 |
| zyga | noizer: always look at docs/rest.md | 09:34 |
| zyga | noizer: that's the current version | 09:34 |
| zyga | noizer: this one is probably a few days old | 09:34 |
| noizer | its the same and there i can see /2.0/snaps/name/services | 09:35 |
| noizer | https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#20snapsnameservicesname zyga | 09:35 |
| ogra_ | sergiusens, did you set the dip switch to SD boot at the bottom of the board ? | 09:36 |
| sergiusens | ogra_, no, I searched the manuals/internet for some sort of information about that | 09:37 |
| ogra_ | well, make sure that one switch is set to "on" | 09:37 |
| ogra_ | else it wont even try the Sd | 09:37 |
| sergiusens | ogra_, oh, now that I turn it upside down it is obvious :-P | 09:37 |
| sergiusens | ogra_, thanks | 09:39 |
| ogra_ | works ? | 09:39 |
| sergiusens | ogra_, yeah; well I don't see SElinux anymore and cloud-init instead ;-) | 09:40 |
| ogra_ | good | 09:40 |
| ogra_ | tell me if the upgrade works .... there are newer kernel and os snaps in the store for it | 09:41 |
| sergiusens | sure, let me setup wifi first | 09:41 |
| ogra_ | yeah | 09:41 |
| ogra_ | one of my cats seems to have had some bad fight tonight, she is pretty injured on one leg, i'll need to go to the vet soon | 09:42 |
| ogra_ | (no idea if/when i can return) | 09:42 |
| sergiusens | k | 09:42 |
| sergiusens | good luck with that | 09:42 |
| ogra_ | yeah | 09:43 |
| * ogra_ hopes for the best ... seems she can still stand up | 09:44 | |
| sergiusens | ogra_, oh, that bad | 09:44 |
| ogra_ | yeah | 09:44 |
| ogra_ | i guess a dog or racoon | 09:44 |
| noizer | ogra_ do you know how that i can my apps to services. So i can start and stop my services with the REST api | 09:51 |
| ogra_ | i saw the mail discussion | 09:52 |
| noizer | zyga about the python api does i need to take a fork of ubuntu-core/snappy? | 10:00 |
| zyga | noizer: no, please start with an empty repo | 10:06 |
| zyga | noizer: that will make it easier to work with on pypi later | 10:06 |
| zyga | noizer: for releases / qa | 10:06 |
| zyga | noizer: start with a simple package that has all the public APIs in the client/ package today (use python conventions rather than go conventions for methods though) | 10:07 |
| zyga | noizer: and we can fill in the blanks, most of the stuff is really easy, you just have to define the input and output format (data is almost always json) | 10:07 |
| ysionneau | morning | 10:08 |
| zyga | o/ | 10:08 |
| ysionneau | stupid question: how would one put a binary (actually a shell script wrapper) in the snap package? | 10:09 |
| ysionneau | I mean by having this script at the same level as the snapcraft.yaml | 10:09 |
| ysionneau | and not cloned as a remote part | 10:09 |
| ysionneau | s/cloned/fetched/ | 10:09 |
| zyga | ysionneau: use a part with source: . | 10:10 |
| zyga | ysionneau: I use that all the time | 10:10 |
| noizer | zyga oooh ok. an other question about Services. when is an app a service? | 10:10 |
| ysionneau | right, I knew this had a simple solution, thanks!! | 10:10 |
| zyga | ysionneau: e.g. https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml | 10:10 |
| zyga | noizer: there are no services, the terminology for that is "all things are apps/applications" | 10:11 |
| zyga | noizer: some applications run in the background | 10:11 |
| ysionneau | ah so I should do a Makefile which will cp my wrapper in $(DESTDIR) ? | 10:11 |
| zyga | noizer: an application runs in the background if it has an extra line in the snap.yaml / snapcraft.yaml that says how exactly it runs in the background | 10:11 |
| ogra_ | ysionneau, you can use the copy plugin | 10:11 |
| ogra_ | ysionneau, http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml | 10:11 |
| zyga | ysionneau: you can, there's also some snapcraft plugin for doing just that but I don't remember, would have to refer to snapcraft source code again | 10:11 |
| ogra_ | ysionneau, (see what it does with the README) | 10:12 |
| ysionneau | awesome, you guyz rock | 10:12 |
| zyga | ysionneau: but a trivial makefile with the right targets is more scalable if you don't want to remember :) | 10:12 |
| zyga | thanks ogra_ :) | 10:12 |
| ogra_ | makfile will indeed work as well :) | 10:12 |
| zyga | nothing like good old make | 10:12 |
| ysionneau | yes | 10:12 |
| * ysionneau likes makefiles | 10:12 | |
| zyga | https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile | 10:13 |
| zyga | sergiusens: https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile#L3 | 10:13 |
| ysionneau | yep I wa son it | 10:13 |
| ysionneau | was on* | 10:13 |
| zyga | sergiusens: small thing I found, snapcraft ignores /usr/local and if your executables are there, it crashes | 10:13 |
| noizer | zyga why is there then in de REST api some things about services | 10:13 |
| zyga | noizer: probably legacy | 10:14 |
| zyga | noizer: we may rename the API | 10:14 |
| zyga | noizer: for now you can call it a service but most places call it background application already | 10:14 |
| noizer | zyga oooh ok so if i add something like deamon: simple it will be a background app | 10:17 |
| zyga | noizer: yes | 10:20 |
| noizer | zyga ok | 10:20 |
| zyga | noizer: (we plan to consolidate that naming so expect some changes later today/next week) but yes | 10:20 |
| noizer | zyga thats no problem it was just confusing xD | 10:21 |
| zyga | noizer: yep | 10:23 |
| renat | Hi all! It's Renat from Screenly=) | 10:34 |
| renat | kyrofa, hi! | 10:35 |
| renat | I commented in snapcraft's copy plugin pull request. | 10:35 |
| renat | I think - that if file is absolute symlink - we should copy it as a symlink. | 10:36 |
| dholbach | renat, might take a bit longer until kyrofa is up | 10:36 |
| renat | dholbach, thanks. I will visit later today. | 10:38 |
| zyga | renat: hey | 10:59 |
| renat | zyga, hi! | 10:59 |
| noizer | zyga can I uses ports within apps because snapcraft says it was unexpected | 11:01 |
| zyga | noizer: nope, ports was removed | 11:02 |
| zyga | noizer: it never really did anything | 11:02 |
| noizer | heheeh xD | 11:02 |
| zyga | noizer: so it was either removed now (I didn't check) or it's in the queue for removal | 11:02 |
| zyga | noizer: just don't use it, nothing changes | 11:03 |
| noizer | zyga ok how can i say to my background app that he may uses some sockets because there i got a permission error? | 11:03 |
| zyga | noizer: which socket? | 11:04 |
| noizer | tcp/ip | 11:04 |
| noizer | zyga | 11:04 |
| zyga | noizer: do you want to use the network or create a network service? | 11:05 |
| zyga | noizer: (do you want to be like apache or connect to apache) in less technical terms | 11:05 |
| noizer | i needed both | 11:05 |
| zyga | noizer: ok, you need to use two interfaces for that: | 11:06 |
| * zyga looks | 11:06 | |
| zyga | noizer: the new names for the interfaces are "network" (you can talk to other things on the network) and "network-bind" (they can talk to you, you can bind to ports, etc) | 11:06 |
| zyga | noizer: but I think today the only way to use them is to use old-security interface with the names "network-client" and "network-listener" | 11:07 |
| ogra_ | i found network-client more intuitive for the first one | 11:07 |
| sergiusens | zyga, of all todays, today I can't do irc; prepping for travel here; so a bug or tlaking to kyrofa would be best | 11:07 |
| ogra_ | "network" sounds like "globally all network features" | 11:07 |
| noizer | zyga does i need to use then slots and ect | 11:07 |
| zyga | noizer: I'll land a lot of interfaces today, but you still need to use the old-security with the images that are out there | 11:07 |
| zyga | ogra_: "you want to connect to the network" was the rationale | 11:08 |
| ogra_ | zyga, sure, but the other options all have suffixes | 11:08 |
| ogra_ | so it sounds pretyt global to me | 11:08 |
| zyga | noizer: you have to use the "slot" but next week that becomes "plug" (you plug old security into your application) | 11:08 |
| zyga | noizer: https://github.com/ubuntu-core/snappy/pull/580 | 11:09 |
| ogra_ | (me shuts up bfore anyone changes any names again) | 11:09 |
| zyga | noizer: virtues of a development release | 11:09 |
| zyga | ogra_: I shall name you argo | 11:09 |
| zyga | ;D | 11:09 |
| zyga | ogra_: most don't | 11:09 |
| zyga | ogra_: all the old security bits were modelled after capabilities | 11:09 |
| zyga | ogra_: and now that each connection has two sides, we can discard half of those in most cases | 11:10 |
| noizer | dam it is very confusing with all these versions | 11:10 |
| zyga | ogra_: e.g. mir is just one interface, no mir-client, mir-server | 11:10 |
| zyga | ogra_: same with docker | 11:10 |
| zyga | noizer: just wait till monday please | 11:10 |
| zyga | noizer: it's settling | 11:10 |
| ogra_ | zyga, lol | 11:10 |
| ogra_ | high hopes | 11:10 |
| zyga | noizer: we'll make the docs all up to date | 11:10 |
| zyga | ogra_: I actually like this change a lot, much better than having mir-server being provider by ubuntu-core or kernel snaps | 11:11 |
| zyga | ogra_: it's just one interface, mir | 11:11 |
| ogra_ | (my lol was rather about the "it's settling" ) | 11:11 |
| zyga | ogra_: you have an app that offers mir slot and many apps that plug into that | 11:11 |
| zyga | ogra_: (oh, it is, really) | 11:11 |
| ogra_ | i belive it when i see it | 11:11 |
| zyga | ogra_: (we had a three hour meeting yesterday and it was very productive) | 11:11 |
| zyga | ogra_: very well :) | 11:11 |
| noizer | zyga will it for now be enough to use this? http://pastebin.com/7sHfGU3Z | 11:15 |
| zyga | no, "old-security" rather than "migration-skill" | 11:16 |
| zyga | and also do "network-client" | 11:16 |
| zyga | (second cap) | 11:16 |
| zyga | because you need both | 11:16 |
| zyga | by default snaps are offline | 11:16 |
| noizer | zyga pfft {'caps': ['network-listener', 'network-client'], 'type': 'old-security'} is not valid under any of the given schemas | 11:24 |
| didrocks | noizer: using snapcraft master? | 11:26 |
| noizer | i think so | 11:26 |
| noizer | didrocks | 11:26 |
| didrocks | s/type/interface/ | 11:26 |
| didrocks | (since yesterday late ;)) | 11:26 |
| zyga | noizer: "interface", not "type" | 11:26 |
| zyga | thanks didrocks :) | 11:27 |
| * zyga works on adding about a dozen new interfaces to snappy | 11:27 | |
| ogra_ | Mar 4 11:35:33 localhost kernel: [ 114.926577] audit: type=1400 audit(1457091333.026:13): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=1 capname="dac_override" | 11:37 |
| ogra_ | Mar 4 11:35:33 localhost kernel: [ 114.926680] audit: type=1400 audit(1457091333.036:14): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=2 capname="dac_read_search" | 11:37 |
| ogra_ | hmm | 11:37 |
| ogra_ | i guess webdm needs updating :) | 11:37 |
| ogra_ | though this is funny since webdm loads the unconfined profile first | 11:40 |
| noizer | didrocks zyga uses: | 11:41 |
| noizer | listener: | 11:41 |
| noizer | interface: old-security | 11:41 |
| noizer | caps: [network-listener, network-client] | 11:41 |
| noizer | like that? | 11:41 |
| sergiusens | zyga, did the plug<->slot thing make it into edge? | 11:41 |
| * sergiusens wonders about releasing a supporting snapcraft | 11:41 | |
| zyga | sergiusens: https://trello.com/c/nUsc10Ra/43-swap-plugs-and-slots-around | 11:42 |
| zyga | sergiusens: https://github.com/ubuntu-core/snappy/pull/580 | 11:42 |
| zyga | sergiusens: needs review, then needs release (I have no idea how that works yet though) | 11:42 |
| zyga | sergiusens: let's work together on coordinating this today | 11:42 |
| zyga | sergiusens: I'd like to end the week in a stable state | 11:42 |
| zyga | noizer: looking | 11:43 |
| zyga | noizer: yep | 11:43 |
| zyga | noizer: and refer to "listener" from slots in your snap, tomorrow this just changes to "plugs" | 11:43 |
| noizer | zyga what will be the syntax? | 11:44 |
| zyga | noizer: look at existing examples | 11:45 |
| zyga | noizer: https://github.com/ubuntu-core/snapcraft/blob/master/examples/webchat/snapcraft.yaml | 11:45 |
| zyga | noizer: tomorrow we just swap slots/plugs around | 11:45 |
| zyga | noizer: and next week, old-security can be somewhat replaced by native interfaces: [network, network-bind] | 11:46 |
| zyga | noizer: I'll announce it when it can be used | 11:47 |
| stevebiscuit | ogra_: this should solve that: ttps://code.launchpad.net/~stevenwilkin/webdm/skill-to-interface-snap-yaml/+merge/287760 | 11:47 |
| zyga | noizer: snapcraft examples are the best way to learn :) | 11:47 |
| stevebiscuit | s/ttps/https/ | 11:47 |
| ogra_ | stevebiscuit, ah, cool | 11:47 |
| ogra_ | i'll just wait | 11:47 |
| ogra_ | oh, crap | 11:48 |
| ogra_ | the generic initrds are gzip compressed | 11:48 |
| noizer | zyga ok i still got an error but i am using snapcraft 2.3.2 is that not update to date? | 11:49 |
| zyga | noizer: I'm not sure | 11:49 |
| zyga | noizer: what did you exactly do and what the error was? | 11:50 |
| noizer | zyga Issues while validating snapcraft.yaml: Additional properties are not allowed ('slots' was unexpected) | 11:50 |
| zyga | noizer: o_O not sure, ask sergiusens, maybe your snapcraft is out of date | 11:54 |
| zyga | noizer: check if you can build the example I linked to | 11:54 |
| * zyga -> back to hacking | 11:54 | |
| ogra_ | oh crap ! | 12:01 |
| ogra_ | pitti, so my initrd now ends up with a /lib64 dir | 12:01 |
| ogra_ | with the linker in it | 12:01 |
| ogra_ | which results in non executable binaries | 12:01 |
| ogra_ | yeah, moving the linker to /lib fixes it :( | 12:05 |
| ogra_ | argh | 12:06 |
| ogra_ | except ... | 12:06 |
| ogra_ | Begin: Running /scripts/local-premount ... wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory | 12:06 |
| ogra_ | wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory | 12:06 |
| ogra_ | damned | 12:06 |
| sergiusens | zyga, we never landed that | 12:07 |
| sergiusens | zyga, we are going to land 7 breaking changes in a row, sorry | 12:07 |
| zyga | sergiusens: 7? | 12:08 |
| ysionneau | I'm not the only one to fight against dynamic linker issues | 12:08 |
| ogra_ | ysionneau, well, i'm rather fighting fakechroot here | 12:10 |
| ogra_ | bug 1553110 | 12:10 |
| ubottu | bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110 | 12:10 |
| ysionneau | ah ok | 12:10 |
| pitti | ogra_: /lib64/*ld.so* should/could just be a symlink to /lib | 12:11 |
| pitti | ogra_: that's at least how it is on amd64 | 12:11 |
| ogra_ | pitti, well, indeed it isnt beacuse i hacked the outer script to just have /lib64 ... whats more worrying though is that libudev doesnt end up in the initrd at all now | 12:11 |
| ogra_ | pitti, for the linker there is a hack in mkinitramfs for armhf already that we likely need to copy for arm64 | 12:12 |
| sergiusens | zyga, I was being sarcastic; I was about to release yesterday but with this change cancelled the release completely | 12:12 |
| ogra_ | it had a similar prob | 12:12 |
| sergiusens | it makes no sense to promote something that is going to be inverted | 12:12 |
| ogra_ | but that doesnt explain the missing libudev | 12:12 |
| sergiusens | I'd just tell people to use ubuntu-core/stable | 12:13 |
| sergiusens | ogra_, I am almost there with the logic for this :-) | 12:13 |
| ogra_ | sergiusens, i guess all but arm64 should work | 12:13 |
| ogra_ | pitti, see line 337 ff in /usr/sbin/mkinitramfs | 12:14 |
| ogra_ | not actually lib64 ... but the same issue | 12:14 |
| sergiusens | ogra_, oh I did see a lib64 in amd64's generic initrd and jumped to conclusions | 12:14 |
| sergiusens | with an ld symlink too | 12:15 |
| ogra_ | symlink ? | 12:15 |
| pitti | ogra_: so I guess it'd be best to actually fix fakechroot instead of adding further hacks | 12:15 |
| ogra_ | there shouldnt be one | 12:15 |
| ogra_ | pitti, hmpf | 12:15 |
| sergiusens | ogra_, $ ls -l lib64/ | 12:15 |
| sergiusens | total 0 | 12:15 |
| sergiusens | lrwxrwxrwx 1 sergiusens sergiusens 34 mar 4 06:46 ld-linux-x86-64.so.2 -> ../lib/x86_64-linux-gnu/ld-2.21.so | 12:15 |
| pitti | amd64 *should* and even *must* have a /lib64 | 12:15 |
| pitti | amd64 vs. arm64 confusion? :-) | 12:15 |
| ogra_ | pitti, i thought colin said it shouldnt | 12:15 |
| pitti | no, he said we shouldn't proliferate that to other arches like arm64 | 12:16 |
| sergiusens | pitti, nah; I was going by ogra's symptoms, not saying anything is wrong or right | 12:16 |
| ogra_ | pitti, well, not even debootstrap creates lib64 on arm64 atm | 12:17 |
| pitti | right | 12:17 |
| pitti | I thought you just created it as workaround for that fakechroot thingy | 12:17 |
| ogra_ | yeah | 12:17 |
| ogra_ | and that works fine ... for everything but wait-for-root | 12:17 |
| pitti | so maybe create the /lib64 symlink, do the fakechroot bootstrap, and remove it again before building the image? | 12:18 |
| pitti | s/image/initrd/ | 12:18 |
| ogra_ | you mean hacking up update-initramfs ? | 12:18 |
| pitti | the place where you added it doesn't have code which runs after the initrd build? | 12:18 |
| zyga | rpi3 arrived | 12:18 |
| zyga | hmmm | 12:18 |
| ogra_ | no | 12:18 |
| ogra_ | well, it doesnt have code that runs "inside" the initrd | 12:19 |
| ogra_ | thats all left up initramfs-tools hook scripts | 12:19 |
| ogra_ | i'm just modifying the build chroot to have the dir | 12:19 |
| pitti | ogra_: perhaps try wiht a /lib64 -> /lib symlink? | 12:20 |
| pitti | instead of a symlink or even a copy *in* /lib64/ ? | 12:20 |
| ogra_ | pitti, will do, but i doubt that will fix the missing libudev | 12:23 |
| ogra_ | i can indeed forcefully copy it in place with a hack-hook or some such | 12:23 |
| ogra_ | still ... not cool :( | 12:24 |
| noizer | zyga I need to upgrade my snapcraft what is the best way to do that? | 12:26 |
| zyga | noizer: please wait, we're trying to figure out when to release a compatible set of tools for everyone to use so that no confusions are spread | 12:28 |
| noizer | ok so i need to do nothing today on that? | 12:29 |
| zyga | noizer: soon you should have all the bits in master but we need to release them to make sense | 12:29 |
| noizer | zyga: ok how long does I need to wait for that? | 12:30 |
| zyga | noizer: most likely on monday, we'll decide | 12:30 |
| zyga | and announce this | 12:30 |
| noizer | OK | 12:31 |
| kyrofa | Good morning | 12:39 |
| ogra_ | pitti, hmm, isnt libudev also a thing that udevd should pull into the initrd | 12:55 |
| * ogra_ still doesnt get why it is missing ... copying it in manually makes everything work | 12:55 | |
| ogra_ | (including the udevd that is in the initrd) | 12:56 |
| ogra_ | oh, wow | 12:56 |
| ogra_ | ogra@anubis:~/datengrab/dragonboard/all-snaps$ ldd $(which udevd)|grep udev | 12:56 |
| ogra_ | ogra@anubis:~/datengrab/dragonboard/all-snaps$ | 12:56 |
| ogra_ | so it isnt linked against the lib at all ... interesting | 12:57 |
| ogra_ | WTF ! | 13:05 |
| ogra_ | so libudev isnt in any of the initrds | 13:05 |
| * ogra_ wonders whats going on here | 13:06 | |
| torbit | Hi folks | 13:10 |
| torbit | I am currently trying to ensure that I am working on porting snappy core to a new board. | 13:12 |
| torbit | I am trying to get it to give me output via the serial console on booting up | 13:12 |
| torbit | anyone know where I can do that from as I can not see a grub.cfg file in boot->grub | 13:12 |
| pitti | ogra_: right, udevd isn't meant to link against libudev, it uses an internal (richer, but unstable/non-public) API | 13:20 |
| ogra_ | yeah | 13:20 |
| ogra_ | i still dont get why the lib isnt in any of the inirds | 13:20 |
| pitti | ogra_: I suppose the only thing that needs libudev in the initrd nomrally is wait-for-root | 13:21 |
| ogra_ | on all arches | 13:21 |
| ogra_ | yeah | 13:21 |
| pitti | $ lsinitramfs /initrd.img |grep libudev | 13:21 |
| pitti | lib/x86_64-linux-gnu/libudev.so.1.6.4 | 13:21 |
| ogra_ | right | 13:21 |
| ogra_ | it isnt in any that my script built | 13:21 |
| pitti | ogra_: fakechroot b0rkage? | 13:21 |
| ogra_ | (i'm 100% sure it is in the phone initrds, else they wouldnt boot at akll) | 13:22 |
| ogra_ | the script is the same ... as is the build process | 13:22 |
| ogra_ | i just uploaded a test version with libfakeroot and libfakechroot in the build chroot ... lets see if that changes anything | 13:23 |
| ogra_ | (they will end up inside the initrd though ... which i was wanting to avoid) | 13:23 |
| pitti | ogra_: uploaded? I thought you have access to an arm64 instance to do local test builds | 13:23 |
| pitti | (I can give you one if you need) | 13:24 |
| ogra_ | i do, but uploading is faster :) | 13:24 |
| pitti | well.. | 13:24 |
| torbit1 | erm…lost connection..did anyone say anything with regards to my last post | 13:25 |
| ogra_ | ok, adding the t6wo libs didnt change a thing | 13:31 |
| ogra_ | (apart from quietening the build log) | 13:31 |
| ogra_ | pitti, did we ever find out what actually copies wait-for-root ? | 13:32 |
| ogra_ | i cant find a hook for it | 13:32 |
| ogra_ | ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/share/initramfs-tools/* | 13:33 |
| ogra_ | /usr/share/initramfs-tools/scripts/local:FSTYPE=$(wait-for-root "${ROOT}" ${ROOTDELAY:-$ARCHDELAY}) | 13:33 |
| ogra_ | /usr/share/initramfs-tools/scripts/local-premount/resume:SWAPTYPE=$(wait-for-root "${resume}" ${RESUMEDELAY:-5}) | 13:33 |
| ogra_ | aha | 13:33 |
| ogra_ | ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/sbin/mkinitramfs | 13:33 |
| ogra_ | copy_exec /usr/lib/initramfs-tools/bin/wait-for-root /sbin | 13:33 |
| * ogra_ bets if he adds that to some hook it will actually DTRT | 13:34 | |
| pitti | ogra_: I don't think it's in a hook, it should be copied by the i-t core code | 13:34 |
| pitti | ogra_: right, that | 13:34 |
| ogra_ | yeah, it is hardcoded in /usr/sbin/mkinitramfs | 13:34 |
| ogra_ | let me try making it a hook, just for fun :) | 13:35 |
| kyrofa | beuno, if I want to ship a device with some custom kernel modules, I make a kernel snap (I assume). I make a snap to utilize those new modules, and upload it to the store. Is there anything preventing someone else (who doesn't have my kernel snap) from installing that snap which then breaks for them? | 13:36 |
| beuno | kyrofa, hi! | 13:37 |
| beuno | yes, interfaces! | 13:37 |
| kyrofa | beuno, ahh, okay | 13:37 |
| beuno | your kernel would expose interfaces for those special modules | 13:37 |
| ogra_ | would it ? | 13:37 |
| ogra_ | even if the user simply uses snappy config ubuntu-core and force-loads them ? | 13:38 |
| ogra_ | kyrofa, your user would have to actually create an image using u-d-f ... you can load different kernel snaps | 13:39 |
| * ogra_ tried that already | 13:39 | |
| ogra_ | "a snap of this name is already installed" | 13:39 |
| ogra_ | ;) | 13:39 |
| kyrofa | ogra_, interesting, okay | 13:39 |
| ogra_ | (err: you can *not* load) | 13:40 |
| ogra_ | kyrofa, i dont see where interfaces come into play for modules though, but beuno might know more than I | 13:42 |
| ogra_ | (i mean, beyond the obvious .... accessing devices under /dev) | 13:42 |
| kyrofa | ogra_, I assume it would be more of a "the current kernel doesn't provide a slot for this interface, so I can't plug into it" | 13:43 |
| beuno | ogra_, you expose an interface the exposes a funcionality you don't have otherwise | 13:43 |
| beuno | right | 13:43 |
| beuno | so you can filter on it, etc | 13:43 |
| kyrofa | Yeah that makes sense. Even if the interface provided nothing other than the filter | 13:44 |
| kyrofa | Thanks beuno , ogra_ :) | 13:44 |
| ogra_ | beuno, right, but the module would load regardless, it is only the device access you block | 13:44 |
| ogra_ | (so my in-kernel-keylogger.ko would still work ;) ) | 13:45 |
| beuno | correct | 13:45 |
| kyrofa | ogra_, right, I was really only wondering if it was possible to upload a snap to the store that requires a custom kernel snap to run | 13:45 |
| kyrofa | That didn't break for everyone else | 13:45 |
| beuno | kyrofa, does it sound like a good answer to your problem? | 13:49 |
| kyrofa | beuno, indeed it does, thank you! | 13:49 |
| beuno | w00t | 13:49 |
| ogra_ | hmm, nope ... moving wait-for-root to an actual hook doesnt change anything | 13:58 |
| ogra_ | sigh... this is so painful | 13:58 |
| ogra_ | pitti, any idea what to look for in fakechroot to make it actually work ? | 13:59 |
| pitti | ogra_: not off-hand -- I'd start with stracing "fakechroot ldd" call (with -e trace=file) and see where things go haywire | 14:00 |
| ogra_ | hmm, k | 14:01 |
| * ogra_ will have to prepare for the vet now ... i'll try that later | 14:01 | |
| ysionneau | zyga ogra_ < about my yesterday dynamic linker issue, now it's fixed. I added some post-processing in my alchemy snapcraft plugin so that it creates wrappers for each detected ELF dynamic executables in installdir | 14:07 |
| ysionneau | now it does not crash anymore o/ | 14:07 |
| ogra_ | yay | 14:07 |
| ysionneau | I should push my alchemy plugin someday when it's a bit cleaner on my github | 14:07 |
| ysionneau | so that people could experiment doing cross compilation of snaps | 14:07 |
| zyga | ysionneau: oh, I wasn't aware of what you were doing | 14:15 |
| zyga | ysionneau: I think this will open a lot of very nice use cases | 14:15 |
| zyga | ysionneau: so you're working on what exactly? generic cross compiler support? | 14:17 |
| ysionneau | I'm adding a plugin for snapcraft to support "alchemy" build system (which is some kind of buildroot/Android-build-system on steroid) | 14:19 |
| ysionneau | instead of Android.mk it uses atom.mk | 14:19 |
| ysionneau | https://github.com/parrot-developers/alchemy | 14:19 |
| zyga | ysionneau: is parrot-developers there referring to perl6 parror vm? | 14:20 |
| * zyga wonders how that's all interconnected | 14:20 | |
| zyga | parrot* | 14:20 |
| ysionneau | the interesting fact for snapcraft is that it would allow to generate arm32/64 snaps from your amd64 machine (cross compilation) | 14:20 |
| ysionneau | nop it's referring to Parrot SA | 14:20 |
| zyga | ah | 14:20 |
| ysionneau | a French company | 14:20 |
| zyga | just ENOGOODFREENAMES | 14:20 |
| ysionneau | ;) | 14:20 |
| ogra_ | drones ! | 14:20 |
| ysionneau | yep drones :) | 14:20 |
| ogra_ | :D | 14:21 |
| ysionneau | I'm experimenting with Ubuntu snappy, to see if it would be interesting for us (Parrot) to use it on our drones | 14:21 |
| * ogra_ would so love to see that | 14:21 | |
| ogra_ | i really like your HW | 14:22 |
| ysionneau | the benefit of adding support for alchemy, on our side, is that all our soft/libraries are using this build system. We made the effort of producing atom.mk files for everything | 14:22 |
| ysionneau | so it's basically our entry point for anything | 14:22 |
| dpm | sergiusens, I did the "interfaces" changes to a desktop snap yesterday as instructed by mvo after the ubuntu-core update. Now when running snapcraft to build it, I get "Issues while validating snapcraft.yaml: Additional properties are not allowed ('slot' was unexpected)" | 14:22 |
| ysionneau | anything other than alchemy is a no-go for us as we are not willing to re-do the job of porting all of stuff to a new build system | 14:22 |
| dpm | sergiusens, was the snapcraft version that supports interface not yet uploaded? | 14:23 |
| zyga | dpm: yeah, I think so | 14:23 |
| zyga | dpm: we'll wait for monday to release a compatible set | 14:23 |
| zyga | dpm: (snapcraft, snappy, ubuntu-core snap) | 14:24 |
| ysionneau | 15:22 < ogra_> i really like your HW < thanks :)) | 14:24 |
| dpm | zyga, ok, thanks. Any reason why the set was not released in sync? If I understood it correctly the ubuntu-core snap was already updated yesterday | 14:25 |
| kyrofa | sergiusens, no standup today? I know you're trying to get outta here | 14:35 |
| * ysionneau received his rpi2 | 14:37 | |
| zyga | dpm: slot and plugs got swapped | 14:39 |
| dpm | ah, ok | 14:39 |
| jdstrand | zyga: yw | 14:42 |
| zyga | jdstrand: hey | 14:53 |
| zyga | jdstrand: I asked some question on the telegram, have a look please | 14:53 |
| zyga | jdstrand: I'm about to start converting over all the interfaces we talked about to native | 14:53 |
| jdstrand | zyga: ack-- give me a few minutes | 15:04 |
| zyga | jdstrand: OK | 15:05 |
| zyga | jdstrand: I'll have the static security snippet support next | 15:20 |
| zyga | jdstrand: then moving to native interfaces | 15:20 |
| jdstrand | ok | 15:22 |
| * jdstrand is looking at tg now | 15:22 | |
| zyga | tg? | 15:24 |
| zyga | sabdfl: o/ | 15:24 |
| sabdfl | hey zyga | 15:25 |
| jdstrand | zyga: ok, so while we could support per-app device assignment, the previous agreement was that device assignment is per-snap and that is what the launcher is currently doing (per-snap) | 15:25 |
| zyga | jdstrand: okay, let's keep that and correct the variable names to accurately reflect that | 15:25 |
| zyga | jdstrand: is my patch sensible? i can propose it on launchpad | 15:25 |
| jdstrand | zyga: now, all that is pre-capabilities/skills/interfaces stuff, so if it should be per-app instead of per-snap, we need to change in that part of the code and the launcher | 15:26 |
| jdstrand | to me it seems sensible to do per-snap assignment | 15:26 |
| zyga | jdstrand: ok, let's correct the name with my patch then | 15:27 |
| zyga | jdstrand: I'd rather have it land quickly so next week we can release a working bundle | 15:27 |
| jdstrand | zyga: your patch is fine in the context of of snappy, but ubuntu-core-launcher needs a corresponding change | 15:27 |
| zyga | jdstrand: hmm? but my patch was for ubuntu-core-launcher | 15:28 |
| zyga | jdstrand: I pastebinned a patch for that | 15:28 |
| * zyga goes to commit and push it for real | 15:28 | |
| jdstrand | oh, heh, I was to tunnel-visioned :) | 15:28 |
| jdstrand | ok, I think then that snappy needs a corresponding change :) | 15:28 |
| jdstrand | let me check | 15:28 |
| zyga | yep | 15:29 |
| zyga | both need to happen | 15:29 |
| jdstrand | right, yes | 15:29 |
| jdstrand | so, ack from me if both sides are done | 15:29 |
| zyga | jdstrand: https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/288116 | 15:30 |
| zyga | jdstrand: I'll follow up with snappy change | 15:30 |
| zyga | perhaps /snappy-app-dev could be renamed to something more accurate too but I don't have a good candiate in my head | 15:31 |
| qengho | Hi hi. The package I want to package in a snap has its own internal seccomp profile, and things conflict. What incantation in snapcraft will make a snap with an unconfined profile? | 15:33 |
| zyga | qengho: why do you have your own seccomp profile? | 15:34 |
| zyga | qengho: we're implementing something called "interfaces" if you need non-default security you'll have to work with us to establish an interface that will let your application work | 15:34 |
| qengho | zyga: I do not, but the upstream software does. | 15:34 |
| zyga | qengho: for the moment you can use the "old-security" interface and you can use any custom security policy inside | 15:35 |
| jdstrand | qengho: chromium is going to be interesting here | 15:35 |
| qengho | :( "interesting" | 15:35 |
| zyga | can you explain more how that works? | 15:35 |
| wesleymason | Soooooo, I have a snapcraft.yaml for an existing py2 project, that assembles, using the python2 plugin..and I have an "apps" section that in theory should link up to the usr/bin/<appname> console_scripts entrypoint generated by setuptools...but, on sideloaded install in a snappy VM, nada (it's there in apps/ etc.), but no command available from the | 15:35 |
| wesleymason | shell...any ideas? | 15:35 |
| zyga | can an process constrain itself more while under existing seccomp confinement? | 15:35 |
| zyga | wesleymason: ls /snaps/bin | 15:36 |
| zyga | wesleymason: and we only support 16.04 here really given that this is the focus of development | 15:36 |
| jdstrand | cause they use either a setuid sandbox (which we don't allow setuid in snaps) or a seccomp sandbox (which we disallow changing the seccomp policy in snappy) | 15:36 |
| zyga | wesleymason: so make sure you use a recent 16.04 image | 15:36 |
| zyga | jdstrand: mmm | 15:36 |
| ogra_ | phew | 15:36 |
| zyga | jdstrand: well, I'll leave that to you :) | 15:36 |
| * ogra_ returns from vet .... | 15:36 | |
| ogra_ | no broken bones \o/ | 15:37 |
| wesleymason | zyga: aha, good call, I had followed an out of date doc and grabbed a 15.04 image | 15:37 |
| ysionneau | something I saw in my qemu test but didn't report, but that I also see in my real-hw rpi2 test : [FAILED] Failed to start Create Volatile Files and Directories. | 15:37 |
| * wesleymason grabs a xenial image | 15:37 | |
| zyga | wesleymason: yeah, do use 16.04 and latest snapcraft from xenial please | 15:37 |
| ysionneau | and also [FAILED] Failed to start Run snappy grub-migration. | 15:37 |
| ogra_ | ysionneau, yeah, thats on arm64 too | 15:38 |
| ysionneau | ok | 15:38 |
| qengho | jdstrand: I could neuter the internal chromium seccomp sandbox, but that doesn't seem better. | 15:38 |
| zyga | wesleymason: you can get 16.04 image from https://github.com/zyga/devtools/blob/master/ubuntu-image | 15:38 |
| ysionneau | I just wanted to be sure you were aware of that :) | 15:38 |
| jdstrand | qengho: for this second, use something like http://paste.ubuntu.com/15281301/ | 15:38 |
| jdstrand | qengho: but soonish, we'll do what zyga said where you work with us on some interfaces to make that better | 15:39 |
| qengho | jdstrand: Can I help pull Chromium's weird profile into snappy as a first-class option? | 15:39 |
| qengho | Cool. | 15:39 |
| zyga | jdstrand: let's closes https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/288116 | 15:40 |
| jdstrand | yes, but I'm not sure what that option is otoh | 15:40 |
| zyga | jdstrand: I'll make the other change | 15:40 |
| jdstrand | in theory with seccomp you can keep going more and more restricted | 15:40 |
| ogra_ | ysionneau, well, filing a bug might still make sense | 15:40 |
| jdstrand | but we don't allow changing the seccomp policy at all. perhaps we can have an interface that allows changing the seccomp sandbox | 15:41 |
| jdstrand | have it be restricted to apps we trust, etc | 15:41 |
| jdstrand | not sure. have to think about that | 15:41 |
| jdstrand | but chromium isn't alone in this regard. I think vsftpd also would need something like this | 15:41 |
| jdstrand | alternatively, compile chromium without either sandbox | 15:42 |
| jdstrand | I'm not sure that is an option | 15:42 |
| qengho | I'll check. | 15:42 |
| jdstrand | what's somewhat weird about that is that our sandbox is actually making someone else's sandbox less secure | 15:42 |
| jdstrand | (ie, the chromium seccomp sandbox allows less than we do, cause it is designed for minimal syscalls, whereas we have a bigger syscall interface to handle general purpose apps) | 15:43 |
| qengho | jdstrand: Maybe the chromium seccomp profile could be a strict superset of restrictions of plain. An app perhaps can set the profile, but they are all at least as strict as the base. | 15:43 |
| kyrofa | jdstrand, huh... yeah that is interesting | 15:43 |
| jdstrand | qengho: that is what I was getting at with a possible interface | 15:44 |
| kyrofa | jdstrand, if we allowed for a custom seccomp profile, could the review tools verify that the custom one is a subset of the typical? | 15:44 |
| jdstrand | allow adjusting the sandbox to be more strict | 15:44 |
| jdstrand | kyrofa: well, sure, but that isn't how the chromium sandbox works | 15:44 |
| jdstrand | kyrofa: it has a hardcoded list of syscalls in its code (so would say, vsftpd) | 15:45 |
| qengho | yaml: also-restrict: [ sigblahblah, obscureotherthing, llamas ] | 15:45 |
| jdstrand | and it only goes into the seccomp sandbox when handling untrusted input | 15:45 |
| kyrofa | Ah I see | 15:45 |
| jdstrand | it's an interesting problem. I don't think it is insurmountable | 15:46 |
| jdstrand | the problem with allowing changing the seccomp sandbox by default is that it might open up an avenue of attack of going seccomp unconfined/etc if there are kernel bugs | 15:47 |
| jdstrand | we'll see. want to think more | 15:47 |
| qengho | jdstrand: oh, that yaml is for snap meta/package.yaml, yes? | 15:49 |
| jdstrand | qengho: is this for 15.04 or 16.04? | 15:50 |
| qengho | jdstrand: 16.04 | 15:50 |
| jdstrand | meta/snap.yaml | 15:50 |
| * zyga catches up | 15:50 | |
| jdstrand | it would work with snapcraft too, but we are reversing the order of slots and plugs | 15:50 |
| zyga | jdstrand: check out https://github.com/ubuntu-core/snappy/pull/583 | 15:51 |
| zyga | jdstrand: this will let us have nice native interfaces | 15:51 |
| jdstrand | so this time next week, that'll need to be s/slots/plugs/ | 15:51 |
| * jdstrand assumes the changes will land by then | 15:51 | |
| ogra_ | unless someone changes his mind :P | 15:51 |
| qengho | jdstrand: so, for a snapcraft now, is there a way to get that phrase to the meta/snap.yaml ? | 15:52 |
| * ogra_ lost all trust in naming schemes til rellease day :P | 15:52 | |
| ogra_ | skillcapfaces .... | 15:53 |
| jdstrand | qengho: do this: | 15:53 |
| jdstrand | snapcraft snap (without the slots stuff) | 15:53 |
| jdstrand | then go in snap/meta/snap.yaml | 15:53 |
| jdstrand | add the slots stuff | 15:53 |
| qengho | Hah. | 15:53 |
| jdstrand | then do snapcraft snap | 15:53 |
| qengho | Thanks, jdstrand. | 15:54 |
| jdstrand | this is only for a few days | 15:54 |
| zyga | jdstrand: that's landed already | 15:54 |
| zyga | jdstrand: it's merged :) | 15:54 |
| jdstrand | zyga: snapcraft has interfaces in the new reversed order? | 15:54 |
| zyga | jdstrand: I _think_ sergiusens did this already, I was talking about snappy here | 15:54 |
| jdstrand | ah | 15:55 |
| jdstrand | qengho: ok, then do s/slots/plugs/ in the yaml snippet I gave | 15:55 |
| jdstrand | qengho: try it with snapcraft. if it barfs, use the method I suggested | 15:55 |
| * jdstrand needs to update the review tools now | 15:55 | |
| jdstrand | zyga: regarding the pr, nice explanation | 15:56 |
| jdstrand | is there a way in git hub to see the complete changes in a pr as opposed to individual commits? | 15:56 |
| qengho | "barfs" would be a bad filesystem. | 15:57 |
| ogra_ | the opposite of foofs | 15:57 |
| zyga | jdstrand: yes | 15:57 |
| zyga | jdstrand: you can see both: | 15:57 |
| jdstrand | qengho: hehe | 15:57 |
| zyga | jdstrand: e.g.: https://github.com/ubuntu-core/snappy/pull/578/files | 15:57 |
| zyga | jdstrand: vs https://github.com/ubuntu-core/snappy/pull/578/commits | 15:57 |
| zyga | jdstrand: or just use a remote and git locally ;) | 15:58 |
| jdstrand | I see | 15:58 |
| jdstrand | thanks | 15:58 |
| zyga | jdstrand: github has a nice any-to-any diff but I cannot remember how to find it | 15:59 |
| jdstrand | zyga: what is meta/hooks/plug? | 16:03 |
| zyga | jdstrand: just a random example | 16:06 |
| zyga | jdstrand: was supposed to be the plug-side notification hook | 16:06 |
| zyga | jdstrand: when you plug the plug into a slot, the plug gets to know this | 16:07 |
| jdstrand | zyga: ok, so that is/will be a documented and supported hook for apps to use | 16:07 |
| jdstrand | (that's fine) | 16:07 |
| zyga | jdstrand: yeah, we'll get there, that's the only hook we plan to have for 16.04 AFAIR | 16:08 |
| zyga | jdstrand: I'll implement it as soon as we're done with working interfaces (in general) | 16:08 |
| zyga | jdstrand: hook should be easy, pedronis` is working on support for running hooks in the state engine | 16:08 |
| zyga | jdstrand: so I just plan to wait for that to bake or bake it myself when other tasks run out | 16:08 |
| jdstrand | only hook wrt interfaces or do you mean config is going away? | 16:09 |
| zyga | jdstrand: wrt interfaces | 16:09 |
| zyga | jdstrand: I think config will just hop on the same bandwagon (state engine) | 16:09 |
| jdstrand | zyga: the waiting, etc is fine. mostly I just wanted to know what it was (remembering the .click/ design flaw) | 16:10 |
| zyga | jdstrand: since many state engine bits just landed I will have 80% of interface functionality in the next day or so | 16:11 |
| zyga | jdstrand: as I can just plug it in | 16:11 |
| jdstrand | zyga: nice! | 16:11 |
| zyga | jdstrand: I still want to see the ensure loop and at least one complete example but perhaps I'll just have to try it out | 16:11 |
| zyga | jdstrand: it'd be naive but if we can have interfaces with real security support in the next image I'd be golden :) | 16:12 |
| jdstrand | yeah, that would be really nice | 16:12 |
| * zyga -> food | 16:20 | |
| ysionneau | one of the most annoying fact about 16.04 is that ogra_ 's nethack package is not yet ported to the squashfs type snap :') (at least on armhf userspace) | 17:38 |
| ysionneau | no nethack :( | 17:39 |
| ogra_ | ysionneau, yeah, sorry, the plain nethack works only on arm64 and the ones with -$arch are both for 15.04 | 17:48 |
| ogra_ | once the security du jour changes are done (interfaces etc) i'll push all my snaps to the store for all arches | 17:49 |
| netphreak | Hi, guys! | 17:59 |
| kyrofa | netphreak, hey there | 18:00 |
| netphreak | Been researching using Ubuntu and Snappy to deploy multiple IOT devices... | 18:01 |
| kyrofa | Oh yeah? | 18:01 |
| netphreak | How do i best deploy to a fleet of devices - not knowing their IP's | 18:01 |
| ogra_ | you mean an initial install ? | 18:02 |
| netphreak | both initial and updates | 18:02 |
| qengho | netphreak: For initial, you have to have it "in your hands", probably. | 18:05 |
| qengho | netphreak: It's hard to know, without you saying a lot more. | 18:05 |
| netphreak | Can one use snappy to pull a snap from a url and install? | 18:06 |
| netphreak | I've setup a device that's running a preinstalled version of my software - currently it can download an embedded jar and update itself by being invoked from my control server. | 18:09 |
| netphreak | would like to package a snap with a jdk and deploy this using snappy. | 18:11 |
| ogra_ | snappy has an automatic updater that pulls updates from the store automatically | 18:11 |
| ogra_ | so once you deployed the devices will update themselves automatically | 18:11 |
| ogra_ | you need to do the initial factory flash directly though as qengho said | 18:12 |
| netphreak | Does the store support private repos? | 18:13 |
| ogra_ | it allows a sub store bound to you, yes | 18:13 |
| ogra_ | (for details talk to beuno ) | 18:13 |
| qengho | netphreak: you mean, for software that is secret to you, or do you want to preserve the namespace? | 18:14 |
| netphreak | just software that is secret to me.. | 18:14 |
| ogra_ | but note that snaps are namespaced anyway, you dont need to actually have a "private" one | 18:14 |
| netphreak | It's very device specific | 18:15 |
| netphreak | Any way to control when a device should pull an update? | 18:16 |
| ogra_ | (and snaps are fully binary ... you never upload your source to the store) | 18:16 |
| ogra_ | you can adjust the frequency the system checks for them | 18:17 |
| netphreak | ok.. and any way to control which version, if multiple exist? | 18:17 |
| ogra_ | beyond that, as soon as your new snap exists in the store it will be pulled | 18:17 |
| ogra_ | by default it would always be the latest ... with the option to roll back to the last if something fails | 18:18 |
| ogra_ | not sure we have something in place to tell a device to hold back a version | 18:18 |
| ogra_ | (i doubt it) | 18:19 |
| netphreak | ok.. | 18:19 |
| netphreak | currently my admin part keeps a profile of each device - detailing location and which version.. | 18:19 |
| ogra_ | are the devices identical ? | 18:19 |
| netphreak | would like to only provision updates to eg. device located in a specific city at a time. | 18:20 |
| netphreak | yes, hardware wise they are.. | 18:20 |
| ogra_ | well, you could indeed produce different images and different snaps | 18:20 |
| ogra_ | i.e. the devices in city foople all install use the foople.netphreak image that has bar-foople.netphreak preinstalled | 18:21 |
| ogra_ | one image per city ... | 18:21 |
| ogra_ | one package per city | 18:21 |
| ogra_ | that way you would be able to control them via the store | 18:21 |
| netphreak | problem is these devices will be installed in over 200 cities.. | 18:21 |
| netphreak | Company expects to be able to sell atlas 10000 year. | 18:22 |
| netphreak | atleast | 18:22 |
| ogra_ | well, thats quite a headdache in all cases :) | 18:23 |
| ogra_ | the image you woul ddeploy would be identical apart from the snap name ... and you would have to maintain 200 snaps in your store ... | 18:23 |
| ogra_ | potentially many of them being the same one just with a different name | 18:23 |
| netphreak | yes.. -> pretty inconvenient | 18:24 |
| ogra_ | well, not more or less inconvenient than having to push them to the devices and maitain tables with lists of versions | 18:25 |
| ogra_ | i really think the store people could help you here ... but beuno seems to be off atm | 18:25 |
| netphreak | all devices when booted sends their profile info to the admin server - where i can do version/location filtering etc. | 18:27 |
| netphreak | and send configuration changes to a group of devices or one specific. | 18:27 |
| ogra_ | hmm, and they cant send their IP ? | 18:29 |
| netphreak | most of them will be behind a firewall. | 18:30 |
| ogra_ | ah | 18:30 |
| ogra_ | well, so the polling model is surely the better one | 18:30 |
| ogra_ | and if you can send config changes you also can send commands i guess | 18:31 |
| ogra_ | and trigger the poll ... | 18:31 |
| netphreak | exactly. | 18:32 |
| qengho | netphreak: I think you should keep one grand package and differentiate based on the package config. That is, part of a device deciding which part of the single grand package to use depends on the setting you seeded the device with. | 18:32 |
| netphreak | hmm... | 18:36 |
| netphreak | so you're telling me it's possible from my device application to instruct snappy to start pulling a snap? | 18:36 |
| ogra_ | definitely | 18:38 |
| ogra_ | snappy has a REST api that you should be able to use to manage snaps | 18:38 |
| netphreak | now we're talking ;) | 18:39 |
| netphreak | would it require to install the webdm part? | 18:39 |
| ogra_ | i think the API itself is independent ... | 18:39 |
| ogra_ | Chipaca would know | 18:40 |
| ogra_ | afaik webdm just starts using it actually | 18:40 |
| netphreak | ok.. | 18:41 |
| netphreak | how is it exposed on the device? | 18:41 |
| ogra_ | throoug a socket afaik (i never used it) | 18:41 |
| ogra_ | *through | 18:41 |
| zyga | re | 18:42 |
| ogra_ | zyga, ! | 18:42 |
| ogra_ | you know about the REST api, right ? | 18:42 |
| zyga | ogra_: yep | 18:42 |
| zyga | ogra_: how can I help you? | 18:42 |
| ogra_ | netphreak, zyga is your man then :) | 18:42 |
| zyga | netphreak: tell me | 18:42 |
| netphreak | i suppose this rest api is not exposed externally on the device? | 18:43 |
| zyga | netphreak: it's currently exposed over a unix socket | 18:43 |
| zyga | netphreak: but AFAIR the plain is to expose it over tcp/ip as well | 18:43 |
| zyga | netphreak: right no we just rely on local peer credentials for authentication | 18:44 |
| zyga | netphreak: you can develop an app that talks to current snappy REST api and work with us to expose it on the network | 18:45 |
| zyga | netphreak: what specifically do you need? | 18:45 |
| netphreak | Currently my admin server can communicate securely with the device - receive device profile (application version, location etc). | 18:47 |
| netphreak | And can instruct it to download an update from say AWS S3 repo - as a jar.. | 18:47 |
| netphreak | What i was after was the transactional updates and security of Snaps.. | 18:47 |
| netphreak | So actually my java app on the device could call either the rest api or a snappy command directly | 18:48 |
| zyga | netphreak: snappy maanges device updates, what you are describing actually happens on the server side | 18:48 |
| zyga | netphreak: so I believe it is possible as a service you get from canonical | 18:48 |
| zyga | netphreak: on a given snappy device you can switch between channels like "beta" or "stable" | 18:49 |
| netphreak | yes.. but i need to control which devices (according to location) are updated when. | 18:49 |
| netphreak | my admin server handles all received profiles, and can manage and filter (by location and version etc.) which devices to update | 18:49 |
| zyga | netphreak: I believe this is supported but you'd have to get in touch with someone from product management to discuss details | 18:50 |
| zyga | netphreak: you can control a device but it's not exactly what you think or are describing | 18:50 |
| zyga | netphreak: as in, control which versions go where | 18:50 |
| zyga | netphreak: but that's all server side | 18:50 |
| zyga | netphreak: I'd suggest you to watch development towards 16.04 and get in touch with canonical sales to get a dedicated contact and understand better how server-side management works | 18:51 |
| qengho | netphreak: You want to defer updates of snap packages based on criteria the device knows about. | 18:51 |
| qengho | That was a question. | 18:51 |
| netphreak | The control part is already handled by our middleware software - i just need to tell Snappy on one or more devices to go pull an update with version x.y.z | 18:53 |
| netphreak | Eg middleware platform tells device x - go fetch update snap xyz version x.y.z | 18:55 |
| zyga | netphreak: snappy has specific design on how updates work, who has control over what (os vendor, appX vendor, appY vendor, brand of the device, user) | 18:57 |
| zyga | netphreak: what we designed may not be what you immediately think about but it's a very powerful system | 18:57 |
| netphreak | hmm.. | 18:57 |
| zyga | netphreak: I know we're really moving rapidly and not everything is available or documented but as we progress towards 16.04 it will become clear how you can fit your idea into that model | 18:57 |
| zyga | netphreak: e.g. if I install your app, can I still override your decision | 18:58 |
| netphreak | Well. no need for that part - as the software is for a very specific IOT device.. | 18:58 |
| zyga | netphreak: right, what I'm saying that we designed something that can handle various cases, not just the one you described | 18:58 |
| netphreak | Sounds interesting.. | 18:59 |
| zyga | netphreak: but perhaps the manner in which that is acheived is not the same as what you described | 18:59 |
| netphreak | what's the timeframe for 16.04? | 18:59 |
| ogra_ | 04 2016 ;) | 18:59 |
| zyga | netphreak: so for now I can only suggest to contact canonical professionally and discuss this more and also to wait towards 16.04 as we publish more documentation and design docs | 18:59 |
| zyga | netphreak: 16.04 :D | 18:59 |
| ogra_ | (april ) | 18:59 |
| zyga | netphreak: it's nice to have nice date-based releases | 18:59 |
| netphreak | hehe.. | 18:59 |
| netphreak | I'll get a hold of canonical and get some more info :) | 19:00 |
| netphreak | And see if it'll fit our schedule.. | 19:01 |
| netphreak | are there any previews available to get a feeling of how it it would work? | 19:01 |
| zyga | netphreak: it's an exciting and very busy period, I'd suggest to explore aligning on 16.04 and working towards using ubuntu as the core of your product | 19:01 |
| zyga | netphreak: it's all in the open | 19:02 |
| zyga | netphreak: you can get "edge" images from https://github.com/zyga/devtools/blob/master/ubuntu-image easily (or get pre-built images from links mvo and others send to the snappy-devel mailing list) | 19:02 |
| zyga | netphreak: you can check snappy activity on github.com/ubuntu-core/snappy | 19:03 |
| zyga | netphreak: and we're all here so it's all in the open | 19:03 |
| ogra_ | yeah | 19:03 |
| netphreak | ok.. will have a look.. | 19:03 |
| ogra_ | netphreak, what CPU arch are your devices ? | 19:03 |
| netphreak | arm | 19:03 |
| zyga | netphreak: armv7+ or earlier? | 19:03 |
| ogra_ | v7 ? | 19:03 |
| netphreak | v7 | 19:04 |
| ogra_ | cool | 19:04 |
| netphreak | maybe a Cortex A53 - if needed | 19:05 |
| ogra_ | yeah, that should both be fine | 19:09 |
| netphreak | Thanks for your time, guys! :) | 19:10 |
| ogra_ | np, if you have more questions, just come around | 19:10 |
| ogra_ | :) | 19:11 |
| netphreak | will do :) | 19:12 |
| jdstrand | pindonga: hey, fyi, I just committed change to the review tools for the plugs/slots reversal. this doesn't need to be pulled immediately, but I wanted to alert you to it | 19:18 |
| jdstrand | pindonga: next week I imagine I am going to ask for another pull request for old-security/caps to native interfaces change that zyga is working on | 19:19 |
| pindonga | jdstrand, sure | 19:19 |
| pindonga | let me know and I'll do the pull next week | 19:19 |
| jdstrand | ok | 19:19 |
| zyga | jdstrand: ok, 4-way security snippet support has landed | 19:21 |
| zyga | jdstrand: is there something I could try to convert over as the first thing? | 19:21 |
| jdstrand | zyga: yes, let me push something | 19:26 |
| jdstrand | zyga: https://code.launchpad.net/~jdstrand/+junk/snappy-interfaces-security | 19:34 |
| jdstrand | zyga: look in snap.unpacked | 19:34 |
| jdstrand | since snapcraft doesn't do interfaces yet, I unpacked a snap that used 'uses', then converted the snap.yaml and moved some things around | 19:35 |
| jdstrand | zyga: it is not tested to work, but it should give you the idea | 19:35 |
| zyga | jdstrand: looking | 19:38 |
| zyga | jdstrand: thanks | 19:38 |
| zyga | jdstrand: https://trello.com/c/qm0XzFfl/44-switch-udev-security-to-app-level-granularity FYI | 19:38 |
| zyga | hmm | 19:39 |
| zyga | jdstrand: I was under the impression that 'network' and 'network-bind' would just become real top-level interfaces, not under old-security | 19:39 |
| jdstrand | zyga: yes | 19:40 |
| zyga | jdstrand: ok | 19:40 |
| jdstrand | zyga: you asked for me to give you something to convert :) | 19:40 |
| zyga | jdstrand: yeah, like "network" | 19:40 |
| jdstrand | convert away! :) | 19:40 |
| * zyga reads | 19:40 | |
| jdstrand | network-client -> network | 19:40 |
| jdstrand | network-listener -> network-bind | 19:40 |
| zyga | jdstrand: right I know | 19:40 |
| zyga | jdstrand: hmm, I was hoping to get the network.go at the end of this exercise | 19:41 |
| jdstrand | these are different static perms | 19:41 |
| zyga | jdstrand: that implements "network" | 19:41 |
| jdstrand | sure | 19:41 |
| zyga | jdstrand: and after the basics are set up, iterate and convert all of those over | 19:41 |
| jdstrand | zyga: I gave you a snap that had stuff in that used old-security. what precisely do you want and I'll give it to you | 19:42 |
| zyga | jdstrand: so to be clear, I don't want to implement old-security now | 19:42 |
| jdstrand | no, of course not | 19:42 |
| jdstrand | you used the word 'convert' | 19:42 |
| zyga | jdstrand: (I can but it's more complex) | 19:42 |
| zyga | jdstrand: ah, sorry | 19:42 |
| jdstrand | so I gave you the old system so you could convert | 19:42 |
| zyga | jdstrand: I'd like to see the bits that go into making "network" tick | 19:42 |
| zyga | jdstrand: so I can quickly create NetworkInterface{} type that has the same semantics | 19:42 |
| jdstrand | we want old-security/caps to go away | 19:42 |
| zyga | jdstrand: we can look at how that looks next week and decide how to proceed with other interfaces | 19:43 |
| jdstrand | zyga: tell me exactly what you want now and I will give it to you | 19:43 |
| zyga | jdstrand: ok, one se | 19:43 |
| zyga | sec* | 19:43 |
| zyga | jdstrand: given those four methods: https://github.com/ubuntu-core/snappy/blob/master/interfaces/core.go#L81 | 19:44 |
| zyga | jdstrand: (consecutive) | 19:44 |
| zyga | jdstrand: I'd like to know what security snippets to put inside for "network" | 19:44 |
| jdstrand | oh | 19:44 |
| jdstrand | zyga: did you look in the ppa? | 19:44 |
| zyga | jdstrand: I suspect that it translates to a few syscalls and maybe some AA | 19:44 |
| zyga | jdstrand: no, which ppa, sorry, maybe I missed a link | 19:44 |
| jdstrand | I sent it via email yesterday. don't worry, let me point you at a branch | 19:45 |
| zyga | oh, sorry, I'm not great with catching up on email; thanks | 19:45 |
| jdstrand | zyga: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/files/head:/data/ | 19:45 |
| jdstrand | zyga: drill down into {apparmor,seccomp}/policygroups/ubuntu-core/16.04/network | 19:46 |
| zyga | jdstrand: that's exactly what I needed, thank you | 19:46 |
| zyga | :) | 19:46 |
| zyga | woot | 19:46 |
| jdstrand | np, sorry for the confustion | 19:46 |
| zyga | hehe, sorry, this was a looong day (yesterday too) | 19:47 |
| jdstrand | zyga: if it helps you, there is an ubuntu-core-security in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages that did all the renames from yesterday (ie, what is in that branch) | 19:47 |
| jdstrand | but I suspect the branch is enough | 19:47 |
| zyga | jdstrand: yeah, the branch is enough | 19:48 |
| zyga | jdstrand: and as a sanity check, the "network" interface will have a slot on the ubuntu-core os snap and all the snaps that want to talk to it will have a plug on their side | 19:48 |
| jdstrand | zyga: correct | 19:48 |
| zyga | great | 19:48 |
| zyga | one moment :) | 19:48 |
| kyrofa | jdstrand, are the read/write paths new to 16.04? Or did they exist in 15.04 as well? | 20:10 |
| kyrofa | Looks like the docs have been replaced on developer.ubuntu.com, now I can't remember :P | 20:10 |
| zyga | (almost done, writing tests) | 20:15 |
| jdstrand | kyrofa: security-override/read-paths and write-paths were technically available in 15.04, but in a really hard to use way that is not at all like the 16.04 yaml | 20:15 |
| kyrofa | jdstrand, I don't suppose you know of any examples? | 20:16 |
| jdstrand | kyrofa: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.04 | 20:20 |
| kyrofa | jdstrand, ah ha! | 20:21 |
| kyrofa | jdstrand, is the policy_group in the override of that example redundant due to the cap of the service? | 20:23 |
| jdstrand | yes | 20:23 |
| kyrofa | Or do they need to match up? | 20:23 |
| kyrofa | Okay | 20:23 |
| jdstrand | oh wait | 20:23 |
| jdstrand | I thought you were asking a different question | 20:23 |
| jdstrand | kyrofa: security-override can only be used by itself on 15.04 | 20:24 |
| kyrofa | Oh wow, I totally missed that there were two services | 20:24 |
| kyrofa | Ahem | 20:24 |
| jdstrand | kyrofa: so, any 'caps' you had in your yaml, but in the policy_groups of the json | 20:24 |
| jdstrand | then remove the caps from the yaml | 20:24 |
| kyrofa | Gotcha, okay. Yeah, I like 16.04 better, too ;) | 20:24 |
| jdstrand | yes | 20:24 |
| kyrofa | Thanks for the pointer! | 20:25 |
| jdstrand | np | 20:25 |
| jdstrand | historically, this is because of the click compat stuff and it not getting all moved by 15.04 | 20:25 |
| jdstrand | I did say it was horrible to use :) | 20:25 |
| kyrofa | Yeah that makes total sense | 20:26 |
| zyga | jdstrand: ok | 20:33 |
| zyga | jdstrand: ready? | 20:33 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/587 | 20:33 |
| zyga | jdstrand: note that this is the no-shortcuts taken version | 20:34 |
| zyga | jdstrand: with 2nd one I'll itroduce a simple "base class" like support so all the grotty details will go away | 20:34 |
| zyga | jdstrand: and 99% of the code will be copy-paste from your bzr branch | 20:34 |
| kyrofa | jdstrand, FYI typo on that page, overrides has no s | 20:34 |
| zyga | ogra_: ^^ it's happening | 20:37 |
| zyga | jdstrand: tell me what you think | 20:38 |
| zyga | jdstrand: I have to leave in 7 minutes | 20:38 |
| jdstrand | zyga: 7 minutes is not a lot of time. I looked at it and see how it works | 20:49 |
| jdstrand | zyga: I look forward to the 99% case next week :) | 20:49 |
| zyga | jdstrand: cool | 20:52 |
| zyga | jdstrand: I'm getting off then | 20:52 |
| zyga | jdstrand: have a nice weekend | 20:52 |
| zyga | jdstrand: I'll simplify this and send a dozen pull requests your way | 20:53 |
| jdstrand | zyga: you too! thanks! :) | 20:53 |
| === retrack is now known as Guest3881 | ||
| wililupy | question: Has anyone seen the error: ubuntu-core-launcher unalbe to make /tmp/ private. errmsg: Invalid argument? | 21:20 |
| wililupy | my snaps that are system services are failing to start and going into a failed state. | 21:21 |
| ysionneau | 18:49 < ogra_> once the security du jour changes are done (interfaces etc) i'll push all my snaps to the store for all arches < ahah I know what you mean = | 22:21 |
| ysionneau | =) | 22:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!