/srv/irclogs.ubuntu.com/2016/03/04/#snappy.txt

=== robert_ancell_ is now known as robert_ancell
zygagood morning08:40
didrockshey zyga08:42
noizergood morning!08:49
zygahey :)08:57
zygahow are you doing08:57
zyga(zero days since the last terminology change ;)08:57
dholbachput that in the topic :)08:58
ogra_capaskillfaces !09:01
zygaogra_: now you have to read that backwards09:01
ogra_heh09:01
ogra_security imlpementation du jour: "interfaces with reversed plugs, 9,90€ ... kids plate, 6,50€"09:02
zygaogra_: uk plugs or us plugs?09:03
* zyga falls screaming into the abyss09:03
ogra_doesnt matter as long as they are reversed :)09:03
* ogra_ wishes we would actually care for some stability inseatd09:03
zygaogra_: nah, this doesn't affect stability in any way09:04
zygaogra_: I'm glad we changed it, it was backwards09:04
ogra_zyga, it occupies dev rtecources09:04
ogra_*ressources09:04
zygaogra_: and saves user resources later on09:05
ogra_i still cant use classic on arm64 ... i still can install all gadget snaps from froreign arches09:05
ogra_(on a running system)09:05
zygaogra_: well, different resources09:05
ogra_webdm doesnt really work09:05
ogra_etc etc09:05
zygaogra_: webdm has tons of love lately09:05
ogra_there are tonms of things that need fixing before release09:05
zygaogra_: yeah, I know09:05
ogra_but we are changing terminology of core features instead09:06
zygaogra_: we're all working towards getting there09:06
ogra_zyga, by 16.10 ?09:06
zygaogra_: 16.04!09:06
ogra_what we have today isnt release worthy yet and still needs liots of work on all levels ...09:06
zygaogra_: in reality renames only affected my work09:06
ogra_zyga, and everyone who has snaps in the store09:08
ogra_(or who wants to have them in the store for release)09:08
zygaogra_: they didn't use interfaces yet, they will but nothing in the store uses them now09:08
ogra_all my (three yet, because i gave up packaging when there was the announcement) snaps use them with migration-skill09:09
zygammmm, okay, I give you that09: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 not09:10
sergiusensogra_, 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
noizerHow can i make from my app a service so I can start and stop it with the rest api?09:21
noizerzyga09:26
zyganoizer: 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
zyganoizer: a bit busy now, perhaps it's not all ready yet but that's the idea09:26
noizerhmmm09:28
zyganoizer: you want snappy services but I'm not sure if that's on the rest api today09:29
noizerzyga https://developer.ubuntu.com/en/snappy/guides/rest/09:30
zyganoizer: always look at docs/rest.md09:34
zyganoizer: that's the current version09:34
zyganoizer: this one is probably a few days old09:34
noizerits the same and there i can see /2.0/snaps/name/services09:35
noizerhttps://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#20snapsnameservicesname zyga09:35
ogra_sergiusens, did you set the dip switch to SD boot at the bottom of the board ?09:36
sergiusensogra_, no, I searched the manuals/internet for some sort of information about that09:37
ogra_well, make sure that one switch is set to "on"09:37
ogra_else it wont even try the Sd09:37
sergiusensogra_, oh, now that I turn it upside down it is obvious :-P09:37
sergiusensogra_, thanks09:39
ogra_works ?09:39
sergiusensogra_, yeah; well I don't see SElinux anymore and cloud-init instead ;-)09:40
ogra_good09:40
ogra_tell me if the upgrade works .... there are newer kernel and os snaps in the store for it09:41
sergiusenssure, let me setup wifi first09:41
ogra_yeah09: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 soon09:42
ogra_(no idea if/when i can return)09:42
sergiusensk09:42
sergiusensgood luck with that09:42
ogra_yeah09:43
* ogra_ hopes for the best ... seems she can still stand up 09:44
sergiusensogra_, oh, that bad09:44
ogra_yeah09:44
ogra_i guess a dog or racoon09:44
noizerogra_ do you know how that i can my apps to services. So i can start and stop my services with the REST api09:51
ogra_i saw the mail discussion09:52
noizerzyga about the python api does i need to take a fork of ubuntu-core/snappy?10:00
zyganoizer: no, please start with an empty repo10:06
zyganoizer: that will make it easier to work with on pypi later10:06
zyganoizer: for releases / qa10:06
zyganoizer: 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
zyganoizer: 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
ysionneaumorning10:08
zygao/10:08
ysionneaustupid question: how would one put a binary (actually a shell script wrapper) in the snap package?10:09
ysionneauI mean by having this script at the same level as the snapcraft.yaml10:09
ysionneauand not cloned as a remote part10:09
ysionneaus/cloned/fetched/10:09
zygaysionneau: use a part with source: .10:10
zygaysionneau: I use that all the time10:10
noizerzyga oooh ok. an other question about Services. when is an app a service?10:10
ysionneauright, I knew this had a simple solution, thanks!!10:10
zygaysionneau: e.g. https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml10:10
zyganoizer: there are no services, the terminology for that is "all things are apps/applications"10:11
zyganoizer: some applications run in the background10:11
ysionneauah so I should do a Makefile which will cp my wrapper in $(DESTDIR) ?10:11
zyganoizer: 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 background10:11
ogra_ysionneau, you can use the copy plugin10:11
ogra_ysionneau, http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml10:11
zygaysionneau: 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 again10:11
ogra_ysionneau, (see what it does with the README)10:12
ysionneauawesome, you guyz rock10:12
zygaysionneau: but a trivial makefile with the right targets is more scalable if you don't want to remember :)10:12
zygathanks ogra_ :)10:12
ogra_makfile will indeed work as well :)10:12
zyganothing like good old make10:12
ysionneauyes10:12
* ysionneau likes makefiles10:12
zygahttps://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile10:13
zygasergiusens: https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile#L310:13
ysionneauyep I wa son it10:13
ysionneauwas on*10:13
zygasergiusens: small thing I found, snapcraft ignores /usr/local and if your executables are there, it crashes10:13
noizerzyga why is there then in de REST api some things about services10:13
zyganoizer: probably legacy10:14
zyganoizer: we may rename the API10:14
zyganoizer: for now you can call it a service but most places call it background application already10:14
noizerzyga oooh ok so if i add something like deamon: simple it will be a background app10:17
zyganoizer: yes10:20
noizerzyga ok10:20
zyganoizer: (we plan to consolidate that naming so expect some changes later today/next week) but yes10:20
noizerzyga thats no problem it was just confusing xD10:21
zyganoizer: yep10:23
renatHi all! It's Renat from Screenly=)10:34
renatkyrofa, hi!10:35
renatI commented in snapcraft's copy plugin pull request.10:35
renatI think - that if file is absolute symlink - we should copy it as a symlink.10:36
dholbachrenat, might take a bit longer until kyrofa is up10:36
renatdholbach, thanks. I will visit later today.10:38
zygarenat: hey10:59
renatzyga, hi!10:59
noizerzyga can I uses ports within apps because snapcraft says it was unexpected11:01
zyganoizer: nope, ports was removed11:02
zyganoizer: it never really did anything11:02
noizerheheeh xD11:02
zyganoizer: so it was either removed now (I didn't check) or it's in the queue for removal11:02
zyganoizer: just don't use it, nothing changes11:03
noizerzyga ok how can i say to my background app that he may uses some sockets because there i got a permission error?11:03
zyganoizer: which socket?11:04
noizertcp/ip11:04
noizerzyga11:04
zyganoizer: do you want to use the network or create a network service?11:05
zyganoizer: (do you want to be like apache or connect to apache) in less technical terms11:05
noizeri needed both11:05
zyganoizer: ok, you need to use two interfaces for that:11:06
* zyga looks11:06
zyganoizer: 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
zyganoizer: 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 one11:07
sergiusenszyga, of all todays, today I can't do irc; prepping for travel here; so a bug or tlaking to kyrofa would be best11:07
ogra_"network" sounds like "globally all network features"11:07
noizerzyga does i need to use then slots and ect11:07
zyganoizer: I'll land a lot of interfaces today, but you still need to use the old-security with the images that are out there11:07
zygaogra_: "you want to connect to the network" was the rationale11:08
ogra_zyga, sure, but the other options all have suffixes11:08
ogra_so it sounds pretyt global to me11:08
zyganoizer: you have to use the "slot" but next week that becomes "plug" (you plug old security into your application)11:08
zyganoizer: https://github.com/ubuntu-core/snappy/pull/58011:09
ogra_(me shuts up bfore anyone changes any names again)11:09
zyganoizer: virtues of a development release11:09
zygaogra_: I shall name you argo11:09
zyga;D11:09
zygaogra_: most don't11:09
zygaogra_: all the old security bits were modelled after capabilities11:09
zygaogra_: and now that each connection has two sides, we can discard half of those in most cases11:10
noizerdam it is very confusing with all these versions11:10
zygaogra_: e.g. mir is just one interface, no mir-client, mir-server11:10
zygaogra_: same with docker11:10
zyganoizer: just wait till monday please11:10
zyganoizer: it's settling11:10
ogra_zyga, lol11:10
ogra_high hopes11:10
zyganoizer: we'll make the docs all up to date11:10
zygaogra_: I actually like this change a lot, much better than having mir-server being provider by ubuntu-core or kernel snaps11:11
zygaogra_: it's just one interface, mir11:11
ogra_(my lol was rather about the "it's settling" )11:11
zygaogra_: you have an app that offers mir slot and many apps that plug into that11:11
zygaogra_: (oh, it is, really)11:11
ogra_i belive it when i see it11:11
zygaogra_: (we had a three hour meeting yesterday and it was very productive)11:11
zygaogra_: very well :)11:11
noizerzyga will it for now be enough to use this? http://pastebin.com/7sHfGU3Z11:15
zygano, "old-security" rather than "migration-skill"11:16
zygaand also do "network-client"11:16
zyga(second cap)11:16
zygabecause you need both11:16
zygaby default snaps are offline11:16
noizerzyga pfft  {'caps': ['network-listener', 'network-client'], 'type': 'old-security'} is not valid under any of the given schemas11:24
didrocksnoizer: using snapcraft master?11:26
noizeri think so11:26
noizerdidrocks11:26
didrockss/type/interface/11:26
didrocks(since yesterday late ;))11:26
zyganoizer: "interface", not "type"11:26
zygathanks didrocks :)11:27
* zyga works on adding about a dozen new interfaces to snappy11: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_hmm11:37
ogra_i guess webdm needs updating :)11:37
ogra_though this is funny since webdm loads the unconfined profile first11:40
noizerdidrocks zyga uses:11:41
noizer  listener:11:41
noizer    interface: old-security11:41
noizer    caps: [network-listener, network-client]11:41
noizerlike that?11:41
sergiusenszyga, did the plug<->slot thing make it into edge?11:41
* sergiusens wonders about releasing a supporting snapcraft11:41
zygasergiusens: https://trello.com/c/nUsc10Ra/43-swap-plugs-and-slots-around11:42
zygasergiusens: https://github.com/ubuntu-core/snappy/pull/58011:42
zygasergiusens: needs review, then needs release (I have no idea how that works yet though)11:42
zygasergiusens: let's work together on coordinating this today11:42
zygasergiusens: I'd like to end the week in a stable state11:42
zyganoizer: looking11:43
zyganoizer: yep11:43
zyganoizer: and refer to "listener" from slots in your snap, tomorrow this just changes to "plugs"11:43
noizerzyga what will be the syntax?11:44
zyganoizer: look at existing examples11:45
zyganoizer: https://github.com/ubuntu-core/snapcraft/blob/master/examples/webchat/snapcraft.yaml11:45
zyganoizer: tomorrow we just swap slots/plugs around11:45
zyganoizer: and next week, old-security can be somewhat replaced by native interfaces: [network, network-bind]11:46
zyganoizer: I'll announce it when it can be used11:47
stevebiscuitogra_: this should solve that: ttps://code.launchpad.net/~stevenwilkin/webdm/skill-to-interface-snap-yaml/+merge/28776011:47
zyganoizer: snapcraft examples are the best way to learn :)11:47
stevebiscuits/ttps/https/11:47
ogra_stevebiscuit, ah, cool11:47
ogra_i'll just wait11:47
ogra_oh, crap11:48
ogra_the generic initrds are gzip compressed11:48
noizerzyga ok i still got an error but i am using snapcraft 2.3.2 is that not update to date?11:49
zyganoizer: I'm not sure11:49
zyganoizer: what did you exactly do and what the error was?11:50
noizerzyga Issues while validating snapcraft.yaml: Additional properties are not allowed ('slots' was unexpected)11:50
zyganoizer: o_O not sure, ask sergiusens, maybe your snapcraft is out of date11:54
zyganoizer: check if you can build the example I linked to11:54
* zyga -> back to hacking11:54
ogra_oh crap !12:01
ogra_pitti, so my initrd now ends up with a /lib64 dir12:01
ogra_with the linker in it12:01
ogra_which results in non executable binaries12:01
ogra_yeah, moving the linker to /lib fixes it :(12:05
ogra_argh12: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 directory12:06
ogra_wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory12:06
ogra_damned12:06
sergiusenszyga, we never landed that12:07
sergiusenszyga, we are going to land 7 breaking changes in a row, sorry12:07
zygasergiusens: 7?12:08
ysionneauI'm not the only one to fight against dynamic linker issues12:08
ogra_ysionneau, well, i'm rather fighting fakechroot here12:10
ogra_bug 155311012:10
ubottubug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/155311012:10
ysionneauah ok12:10
pittiogra_: /lib64/*ld.so* should/could just be a symlink to /lib12:11
pittiogra_: that's at least how it is on amd6412: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 now12:11
ogra_pitti, for the linker there is a hack in mkinitramfs for armhf already that we likely need to copy for arm6412:12
sergiusenszyga, I was being sarcastic; I was about to release yesterday but with this change cancelled the release completely12:12
ogra_it had a similar prob12:12
sergiusensit makes no sense to promote something that is going to be inverted12:12
ogra_but that doesnt explain the missing libudev12:12
sergiusensI'd just tell people to use ubuntu-core/stable12:13
sergiusensogra_, I am almost there with the logic for this :-)12:13
ogra_sergiusens, i guess all but arm64 should work12:13
ogra_pitti, see line 337 ff in /usr/sbin/mkinitramfs12:14
ogra_not actually lib64 ... but the same issue12:14
sergiusensogra_, oh I did see a lib64 in amd64's generic initrd and jumped to conclusions12:14
sergiusenswith an ld symlink too12:15
ogra_symlink ?12:15
pittiogra_: so I guess it'd be best to actually fix fakechroot instead of adding further hacks12:15
ogra_there shouldnt be one12:15
ogra_pitti, hmpf12:15
sergiusensogra_, $ ls -l lib64/12:15
sergiusenstotal 012:15
sergiusenslrwxrwxrwx 1 sergiusens sergiusens 34 mar  4 06:46 ld-linux-x86-64.so.2 -> ../lib/x86_64-linux-gnu/ld-2.21.so12:15
pittiamd64 *should* and even *must* have a /lib6412:15
pittiamd64 vs. arm64 confusion? :-)12:15
ogra_pitti, i thought colin said it shouldnt12:15
pittino, he said we shouldn't proliferate that to other arches like arm6412:16
sergiusenspitti, nah; I was going by ogra's symptoms, not saying anything is wrong or right12:16
ogra_pitti, well, not even debootstrap creates lib64 on arm64 atm12:17
pittiright12:17
pittiI thought you just created it as workaround for that fakechroot thingy12:17
ogra_yeah12:17
ogra_and that works fine ... for everything but wait-for-root12:17
pittiso maybe create the /lib64 symlink, do the fakechroot bootstrap, and remove it again before building the image?12:18
pittis/image/initrd/12:18
ogra_you mean hacking up update-initramfs ?12:18
pittithe place where you added it doesn't have code which runs after the initrd build?12:18
zygarpi3 arrived12:18
zygahmmm12:18
ogra_no12:18
ogra_well, it doesnt have code that runs "inside" the initrd12:19
ogra_thats all left up initramfs-tools hook scripts12:19
ogra_i'm just modifying the build chroot to have the dir12:19
pittiogra_: perhaps try wiht a /lib64 -> /lib symlink?12:20
pittiinstead of a symlink or even a copy *in* /lib64/ ?12:20
ogra_pitti, will do, but i doubt that will fix the missing libudev12:23
ogra_i can indeed forcefully copy it in place with a hack-hook or some such12:23
ogra_still ... not cool :(12:24
noizerzyga I need to upgrade my snapcraft what is the best way to do that?12:26
zyganoizer: 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 spread12:28
noizerok so i need to do nothing today on that?12:29
zyganoizer: soon you should have all the bits in master but we need to release them to make sense12:29
noizerzyga: ok how long does I need to wait for that?12:30
zyganoizer: most likely on monday, we'll decide12:30
zygaand announce this12:30
noizerOK12:31
kyrofaGood morning12:39
ogra_pitti, hmm, isnt libudev also a thing that udevd should pull into the initrd12: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, wow12:56
ogra_ogra@anubis:~/datengrab/dragonboard/all-snaps$ ldd $(which udevd)|grep udev12:56
ogra_ogra@anubis:~/datengrab/dragonboard/all-snaps$12:56
ogra_so it isnt linked against the lib at all ... interesting12:57
ogra_WTF !13:05
ogra_so libudev isnt in any of the initrds13:05
* ogra_ wonders whats going on here 13:06
torbitHi folks13:10
torbit I am currently trying to ensure that I am working on porting snappy core to a new board.13:12
torbitI am trying to get it to give me output via the serial console on booting up13:12
torbitanyone know where I can do that from as I can not see a grub.cfg file in boot->grub13:12
pittiogra_: right, udevd isn't meant to link against libudev, it uses an internal (richer, but unstable/non-public) API13:20
ogra_yeah13:20
ogra_i still dont get why the lib isnt in any of the inirds13:20
pittiogra_: I suppose the only thing that needs libudev in the initrd nomrally is wait-for-root13:21
ogra_on all arches13:21
ogra_yeah13:21
pitti$ lsinitramfs /initrd.img |grep libudev13:21
pittilib/x86_64-linux-gnu/libudev.so.1.6.413:21
ogra_right13:21
ogra_it isnt in any that my script built13:21
pittiogra_: 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 process13:22
ogra_i just uploaded a test version with libfakeroot and libfakechroot in the build chroot ... lets see if that changes anything13:23
ogra_(they will end up inside the initrd though ... which i was wanting to avoid)13:23
pittiogra_: uploaded? I thought you have access to an arm64 instance to do local test builds13:23
pitti(I can give you one if you need)13:24
ogra_i do, but uploading is faster :)13:24
pittiwell..13:24
torbit1erm…lost connection..did anyone say anything with regards to my last post13:25
ogra_ok, adding the t6wo libs didnt change a thing13: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 it13: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_aha13:33
ogra_ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/sbin/mkinitramfs13:33
ogra_copy_exec /usr/lib/initramfs-tools/bin/wait-for-root /sbin13:33
* ogra_ bets if he adds that to some hook it will actually DTRT13:34
pittiogra_: I don't think it's in a hook, it should be copied by the i-t core code13:34
pittiogra_: right, that13:34
ogra_yeah, it is hardcoded in /usr/sbin/mkinitramfs13:34
ogra_let me try making it a hook, just for fun :)13:35
kyrofabeuno, 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
beunokyrofa, hi!13:37
beunoyes, interfaces!13:37
kyrofabeuno, ahh, okay13:37
beunoyour kernel would expose interfaces for those special modules13: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 snaps13:39
* ogra_ tried that already13:39
ogra_"a snap of this name is already installed"13:39
ogra_;)13:39
kyrofaogra_, interesting, okay13: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 I13:42
ogra_(i mean, beyond the obvious .... accessing devices under /dev)13:42
kyrofaogra_, 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
beunoogra_, you expose an interface the exposes a funcionality you don't have otherwise13:43
beunoright13:43
beunoso you can filter on it, etc13:43
kyrofaYeah that makes sense. Even if the interface provided nothing other than the filter13:44
kyrofaThanks beuno , ogra_ :)13:44
ogra_beuno, right, but the module would load regardless, it is only the device access you block13:44
ogra_(so my in-kernel-keylogger.ko would still work ;) )13:45
beunocorrect13:45
kyrofaogra_, right, I was really only wondering if it was possible to upload a snap to the store that requires a custom kernel snap to run13:45
kyrofaThat didn't break for everyone else13:45
beunokyrofa, does it sound like a good answer to your problem?13:49
kyrofabeuno, indeed it does, thank you!13:49
beunow00t13:49
ogra_hmm, nope ... moving wait-for-root to an actual hook doesnt change anything13:58
ogra_sigh... this is so painful13:58
ogra_pitti, any idea what to look for in fakechroot to make it actually work ?13:59
pittiogra_: not off-hand -- I'd start with stracing "fakechroot ldd" call (with -e trace=file) and see where things go haywire14:00
ogra_hmm, k14:01
* ogra_ will have to prepare for the vet now ... i'll try that later 14:01
ysionneauzyga 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 installdir14:07
ysionneaunow it does not crash anymore o/14:07
ogra_yay14:07
ysionneauI should push my alchemy plugin someday when it's a bit cleaner on my github14:07
ysionneauso that people could experiment doing cross compilation of snaps14:07
zygaysionneau: oh, I wasn't aware of what you were doing14:15
zygaysionneau: I think this will open a lot of very nice use cases14:15
zygaysionneau: so you're working on what exactly? generic cross compiler support?14:17
ysionneauI'm adding a plugin for snapcraft to support "alchemy" build system (which is some kind of buildroot/Android-build-system on steroid)14:19
ysionneauinstead of Android.mk it uses atom.mk14:19
ysionneauhttps://github.com/parrot-developers/alchemy14:19
zygaysionneau: is parrot-developers there referring to perl6 parror vm?14:20
* zyga wonders how that's all interconnected14:20
zygaparrot*14:20
ysionneauthe interesting fact for snapcraft is that it would allow to generate arm32/64 snaps from your amd64 machine (cross compilation)14:20
ysionneaunop it's referring to Parrot SA14:20
zygaah14:20
ysionneaua French company14:20
zygajust ENOGOODFREENAMES14:20
ysionneau;)14:20
ogra_drones !14:20
ysionneauyep drones :)14:20
ogra_:D14:21
ysionneauI'm experimenting with Ubuntu snappy, to see if it would be interesting for us (Parrot) to use it on our drones14:21
* ogra_ would so love to see that14:21
ogra_i really like your HW14:22
ysionneauthe 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 everything14:22
ysionneauso it's basically our entry point for anything14:22
dpmsergiusens, 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
ysionneauanything 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 system14:22
dpmsergiusens, was the snapcraft version that supports interface not yet uploaded?14:23
zygadpm: yeah, I think so14:23
zygadpm: we'll wait for monday to release a compatible set14:23
zygadpm: (snapcraft, snappy, ubuntu-core snap)14:24
ysionneau15:22 < ogra_> i really like your HW  < thanks :))14:24
dpmzyga, ok, thanks. Any reason why the set was not released in sync? If I understood it correctly the ubuntu-core snap was already updated yesterday14:25
kyrofasergiusens, no standup today? I know you're trying to get outta here14:35
* ysionneau received his rpi214:37
zygadpm: slot and plugs got swapped14:39
dpmah, ok14:39
jdstrandzyga: yw14:42
zygajdstrand: hey14:53
zygajdstrand: I asked some question on the telegram, have a look please14:53
zygajdstrand: I'm about to start converting over all the interfaces we talked about to native14:53
jdstrandzyga: ack-- give me a few minutes15:04
zygajdstrand: OK15:05
zygajdstrand: I'll have the static security snippet support next15:20
zygajdstrand: then moving to native interfaces15:20
jdstrandok15:22
* jdstrand is looking at tg now15:22
zygatg?15:24
zygasabdfl: o/15:24
sabdflhey zyga15:25
jdstrandzyga: 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
zygajdstrand: okay, let's keep that and correct the variable names to accurately reflect that15:25
zygajdstrand: is my patch sensible? i can propose it on launchpad15:25
jdstrandzyga: 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 launcher15:26
jdstrandto me it seems sensible to do per-snap assignment15:26
zygajdstrand: ok, let's correct the name with my patch then15:27
zygajdstrand: I'd rather have it land quickly so next week we can release a working bundle15:27
jdstrandzyga: your patch is fine in the context of of snappy, but ubuntu-core-launcher needs a corresponding change15:27
zygajdstrand: hmm? but my patch was for ubuntu-core-launcher15:28
zygajdstrand: I pastebinned a patch for that15:28
* zyga goes to commit and push it for real15:28
jdstrandoh, heh, I was to tunnel-visioned :)15:28
jdstrandok, I think then that snappy needs a corresponding change :)15:28
jdstrandlet me check15:28
zygayep15:29
zygaboth need to happen15:29
jdstrandright, yes15:29
jdstrandso, ack from me if both sides are done15:29
zygajdstrand: https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/28811615:30
zygajdstrand: I'll follow up with snappy change15:30
zygaperhaps /snappy-app-dev could be renamed to something more accurate too but I don't have a good candiate in my head15:31
qenghoHi 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
zygaqengho: why do you have your own seccomp profile?15:34
zygaqengho: 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 work15:34
qenghozyga: I do not, but the upstream software does.15:34
zygaqengho: for the moment you can use the "old-security" interface and you can use any custom security policy inside15:35
jdstrandqengho: chromium is going to be interesting here15:35
qengho:(  "interesting"15:35
zygacan you explain more how that works?15:35
wesleymasonSoooooo, 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 the15:35
wesleymasonshell...any ideas?15:35
zygacan an process constrain itself more while under existing seccomp confinement?15:35
zygawesleymason: ls /snaps/bin15:36
zygawesleymason: and we only support 16.04 here really given that this is the focus of development15:36
jdstrandcause 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
zygawesleymason: so make sure you use a recent 16.04 image15:36
zygajdstrand: mmm15:36
ogra_phew15:36
zygajdstrand: well, I'll leave that to you :)15:36
* ogra_ returns from vet .... 15:36
ogra_no broken bones \o/15:37
wesleymasonzyga: aha, good call, I had followed an out of date doc and grabbed a 15.04 image15:37
ysionneausomething 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 image15:37
zygawesleymason: yeah, do use 16.04 and latest snapcraft from xenial please15:37
ysionneauand also [FAILED] Failed to start Run snappy grub-migration.15:37
ogra_ysionneau, yeah, thats on arm64 too15:38
ysionneauok15:38
qenghojdstrand: I could neuter the internal chromium seccomp sandbox, but that doesn't seem better.15:38
zygawesleymason: you can get 16.04 image from https://github.com/zyga/devtools/blob/master/ubuntu-image15:38
ysionneauI just wanted to be sure you were aware of that :)15:38
jdstrandqengho: for this second, use something like http://paste.ubuntu.com/15281301/15:38
jdstrandqengho: but soonish, we'll do what zyga said where you work with us on some interfaces to make that better15:39
qenghojdstrand: Can I help pull Chromium's weird profile into snappy as a first-class option?15:39
qenghoCool.15:39
zygajdstrand: let's closes https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/28811615:40
jdstrandyes, but I'm not sure what that option is otoh15:40
zygajdstrand: I'll make the other change15:40
jdstrandin theory with seccomp you can keep going more and more restricted15:40
ogra_ysionneau, well, filing a bug might still make sense15:40
jdstrandbut we don't allow changing the seccomp policy at all. perhaps we can have an interface that allows changing the seccomp sandbox15:41
jdstrandhave it be restricted to apps we trust, etc15:41
jdstrandnot sure. have to think about that15:41
jdstrandbut chromium isn't alone in this regard. I think vsftpd also would need something like this15:41
jdstrandalternatively, compile chromium without either sandbox15:42
jdstrandI'm not sure that is an option15:42
qenghoI'll check.15:42
jdstrandwhat's somewhat weird about that is that our sandbox is actually making someone else's sandbox less secure15: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
qenghojdstrand: 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
kyrofajdstrand, huh... yeah that is interesting15:43
jdstrandqengho: that is what I was getting at with a possible interface15:44
kyrofajdstrand, 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
jdstrandallow adjusting the sandbox to be more strict15:44
jdstrandkyrofa: well, sure, but that isn't how the chromium sandbox works15:44
jdstrandkyrofa: it has a hardcoded list of syscalls in its code (so would say, vsftpd)15:45
qenghoyaml: also-restrict: [ sigblahblah, obscureotherthing, llamas ]15:45
jdstrandand it only goes into the seccomp sandbox when handling untrusted input15:45
kyrofaAh I see15:45
jdstrandit's an interesting problem. I don't think it is insurmountable15:46
jdstrandthe 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 bugs15:47
jdstrandwe'll see. want to think more15:47
qenghojdstrand: oh, that yaml is for snap meta/package.yaml, yes?15:49
jdstrandqengho: is this for 15.04 or 16.04?15:50
qenghojdstrand: 16.0415:50
jdstrandmeta/snap.yaml15:50
* zyga catches up15:50
jdstrandit would work with snapcraft too, but we are reversing the order of slots and plugs15:50
zygajdstrand: check out https://github.com/ubuntu-core/snappy/pull/58315:51
zygajdstrand: this will let us have nice native interfaces15:51
jdstrandso this time next week, that'll need to be s/slots/plugs/15:51
* jdstrand assumes the changes will land by then15:51
ogra_unless someone changes his mind :P15:51
qenghojdstrand: 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 :P15:52
ogra_skillcapfaces ....15:53
jdstrandqengho: do this:15:53
jdstrandsnapcraft snap (without the slots stuff)15:53
jdstrandthen go in snap/meta/snap.yaml15:53
jdstrandadd the slots stuff15:53
qenghoHah.15:53
jdstrandthen do snapcraft snap15:53
qenghoThanks, jdstrand.15:54
jdstrandthis is only for a few days15:54
zygajdstrand: that's landed already15:54
zygajdstrand: it's merged :)15:54
jdstrandzyga: snapcraft has interfaces in the new reversed order?15:54
zygajdstrand: I _think_ sergiusens did this already, I was talking about snappy here15:54
jdstrandah15:55
jdstrandqengho: ok, then do s/slots/plugs/ in the yaml snippet I gave15:55
jdstrandqengho: try it with snapcraft. if it barfs, use the method I suggested15:55
* jdstrand needs to update the review tools now15:55
jdstrandzyga: regarding the pr, nice explanation15:56
jdstrandis 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 foofs15:57
zygajdstrand: yes15:57
zygajdstrand: you can see both:15:57
jdstrandqengho: hehe15:57
zygajdstrand: e.g.: https://github.com/ubuntu-core/snappy/pull/578/files15:57
zygajdstrand: vs https://github.com/ubuntu-core/snappy/pull/578/commits15:57
zygajdstrand: or just use a remote and git locally ;)15:58
jdstrandI see15:58
jdstrandthanks15:58
zygajdstrand: github has a nice any-to-any diff but I cannot remember how to find it15:59
jdstrandzyga: what is meta/hooks/plug?16:03
zygajdstrand: just a random example16:06
zygajdstrand: was supposed to be the plug-side notification hook16:06
zygajdstrand: when you plug the plug into a slot, the plug gets to know this16:07
jdstrandzyga: ok, so that is/will be a documented and supported hook for apps to use16:07
jdstrand(that's fine)16:07
zygajdstrand: yeah, we'll get there, that's the only hook we plan to have for 16.04 AFAIR16:08
zygajdstrand: I'll implement it as soon as we're done with working interfaces (in general)16:08
zygajdstrand: hook should be easy, pedronis` is working on support for running hooks in the state engine16:08
zygajdstrand: so I just plan to wait for that to bake or bake it myself when other tasks run out16:08
jdstrandonly hook wrt interfaces or do you mean config is going away?16:09
zygajdstrand: wrt interfaces16:09
zygajdstrand: I think config will just hop on the same bandwagon (state engine)16:09
jdstrandzyga: the waiting, etc is fine. mostly I just wanted to know what it was (remembering the .click/ design flaw)16:10
zygajdstrand: since many state engine bits just landed I will have 80% of interface functionality in the next day or so16:11
zygajdstrand: as I can just plug it in16:11
jdstrandzyga: nice!16:11
zygajdstrand: I still want to see the ensure loop and at least one complete example but perhaps I'll just have to try it out16:11
zygajdstrand: it'd be naive but if we can have interfaces with real security support in the next image I'd be golden :)16:12
jdstrandyeah, that would be really nice16:12
* zyga -> food16:20
ysionneauone 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
ysionneauno nethack :(17:39
ogra_ysionneau, yeah, sorry, the plain nethack works only on arm64 and the ones with -$arch are both for 15.0417:48
ogra_once the security du jour changes are done (interfaces etc) i'll push all my snaps to the store for all arches17:49
netphreakHi, guys!17:59
kyrofanetphreak, hey there18:00
netphreakBeen researching using Ubuntu and Snappy to deploy multiple IOT devices...18:01
kyrofaOh yeah?18:01
netphreakHow do i best deploy to a fleet of devices - not knowing their IP's18:01
ogra_you mean an initial install ?18:02
netphreakboth initial and updates18:02
qenghonetphreak: For initial, you have to have it "in your hands", probably.18:05
qenghonetphreak: It's hard to know, without you saying a lot more.18:05
netphreakCan one use snappy to pull a snap from a url and install?18:06
netphreakI'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
netphreakwould 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 automatically18:11
ogra_so once you deployed the devices will update themselves automatically18:11
ogra_you need to do the initial factory flash directly though as qengho said18:12
netphreakDoes the store support private repos?18:13
ogra_it allows a sub store bound to you, yes18:13
ogra_(for details talk to beuno )18:13
qenghonetphreak: you mean, for software that is secret to you, or do you want to preserve the namespace?18:14
netphreakjust software that is secret to me..18:14
ogra_but note that snaps are namespaced anyway, you dont need to actually have a "private" one18:14
netphreakIt's very device specific18:15
netphreakAny 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 them18:17
netphreakok.. 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 pulled18:17
ogra_by default it would always be the latest ... with the option to roll back to the last if something fails18:18
ogra_not sure we have something in place to tell a device to hold back a version18:18
ogra_(i doubt it)18:19
netphreakok..18:19
netphreakcurrently my admin part keeps a profile of each device - detailing location and which version..18:19
ogra_are the devices identical ?18:19
netphreakwould like to only provision updates to eg. device located in a specific city at a time.18:20
netphreakyes, hardware wise they are..18:20
ogra_well, you could indeed produce different images and different snaps18:20
ogra_i.e. the devices in city foople all install use the foople.netphreak image that has  bar-foople.netphreak preinstalled18:21
ogra_one image per city ...18:21
ogra_one package per city18:21
ogra_that way you would be able to control them via the store18:21
netphreakproblem is these devices will be installed in over 200 cities..18:21
netphreakCompany expects to be able to sell atlas 10000  year.18:22
netphreakatleast18: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 name18:23
netphreakyes.. -> pretty inconvenient18:24
ogra_well, not more or less inconvenient than having to push them to the devices and maitain tables with lists of versions18:25
ogra_i really think the store people could help you here ... but beuno seems to be off atm18:25
netphreakall devices when booted sends their profile info to the admin server - where i can do version/location filtering etc.18:27
netphreakand send configuration changes to a group of devices or one specific.18:27
ogra_hmm, and they cant send their IP ?18:29
netphreakmost of them will be behind a firewall.18:30
ogra_ah18:30
ogra_well, so the polling model is surely the better one18:30
ogra_and if you can send config changes you also can send commands i guess18:31
ogra_and trigger the poll ...18:31
netphreakexactly.18:32
qenghonetphreak: 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
netphreakhmm...18:36
netphreakso you're telling me it's possible from my device application to instruct snappy to start pulling a snap?18:36
ogra_definitely18:38
ogra_snappy has a REST api that you should be able to use to manage snaps18:38
netphreaknow we're talking ;)18:39
netphreakwould it require to install the webdm part?18:39
ogra_i think the API itself is independent ...18:39
ogra_Chipaca would know18:40
ogra_afaik webdm just starts using it actually18:40
netphreakok..18:41
netphreakhow is it exposed on the device?18:41
ogra_throoug a socket afaik (i never used it)18:41
ogra_*through18:41
zygare18:42
ogra_zyga, !18:42
ogra_you know about the REST api, right ?18:42
zygaogra_: yep18:42
zygaogra_: how can I help you?18:42
ogra_netphreak, zyga is your man then :)18:42
zyganetphreak: tell me18:42
netphreaki suppose this rest api is not exposed externally on the device?18:43
zyganetphreak: it's currently exposed over a unix socket18:43
zyganetphreak: but AFAIR the plain is to expose it over tcp/ip as well18:43
zyganetphreak: right no we just rely on local peer credentials for authentication18:44
zyganetphreak: you can develop an app that talks to current snappy REST api and work with us to expose it on the network18:45
zyganetphreak: what specifically do you need?18:45
netphreakCurrently my admin server can communicate securely with the device - receive device profile (application version, location etc).18:47
netphreakAnd can instruct it to download an update from say AWS S3 repo - as a jar..18:47
netphreakWhat i was after was the transactional updates and security of Snaps..18:47
netphreakSo actually my java app on the device could call either the rest api or a snappy command directly18:48
zyganetphreak: snappy maanges device updates, what you are describing actually happens on the server side18:48
zyganetphreak: so I believe it is possible as a service you get from canonical18:48
zyganetphreak: on a given snappy device you can switch between channels like "beta" or "stable"18:49
netphreakyes.. but i need to control which devices (according to location) are updated when.18:49
netphreakmy admin server handles all received profiles, and can manage and filter (by location and version etc.) which devices to update18:49
zyganetphreak: I believe this is supported but you'd have to get in touch with someone from product management to discuss details18:50
zyganetphreak: you can control a device but it's not exactly what you think or are describing18:50
zyganetphreak: as in, control which versions go where18:50
zyganetphreak: but that's all server side18:50
zyganetphreak: 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 works18:51
qenghonetphreak: You want to defer updates of snap packages based on criteria the device knows about.18:51
qenghoThat was a question.18:51
netphreakThe 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.z18:53
netphreakEg middleware platform tells device x - go fetch update snap xyz version x.y.z18:55
zyganetphreak: 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
zyganetphreak: what we designed may not be what you immediately think about but it's a very powerful system18:57
netphreakhmm..18:57
zyganetphreak: 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 model18:57
zyganetphreak: e.g. if I install your app, can I still override your decision18:58
netphreakWell. no need for that part - as the software is for a very specific IOT device..18:58
zyganetphreak: right, what I'm saying that we designed something that can handle various cases, not just the one you described18:58
netphreakSounds interesting..18:59
zyganetphreak: but perhaps the manner in which that is acheived is not the same as what you described18:59
netphreakwhat's the timeframe for 16.04?18:59
ogra_04 2016 ;)18:59
zyganetphreak: 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 docs18:59
zyganetphreak: 16.04 :D18:59
ogra_(april )18:59
zyganetphreak: it's nice to have nice date-based releases18:59
netphreakhehe..18:59
netphreakI'll get a hold of canonical and get some more info :)19:00
netphreakAnd see if it'll fit our schedule..19:01
netphreakare there any previews available to get a feeling of how it it would work?19:01
zyganetphreak: 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 product19:01
zyganetphreak: it's all in the open19:02
zyganetphreak: 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
zyganetphreak: you can check snappy activity on github.com/ubuntu-core/snappy19:03
zyganetphreak: and we're all here so it's all in the open19:03
ogra_yeah19:03
netphreakok.. will have a look..19:03
ogra_netphreak, what CPU arch are your devices ?19:03
netphreakarm19:03
zyganetphreak: armv7+ or earlier?19:03
ogra_v7 ?19:03
netphreakv719:04
ogra_cool19:04
netphreakmaybe a Cortex A53 - if needed19:05
ogra_yeah, that should both be fine19:09
netphreakThanks for your time, guys! :)19:10
ogra_np, if you have more questions, just come around19:10
ogra_:)19:11
netphreakwill do :)19:12
jdstrandpindonga: 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 it19:18
jdstrandpindonga: 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 on19:19
pindongajdstrand, sure19:19
pindongalet me know and I'll do the pull next week19:19
jdstrandok19:19
zygajdstrand: ok, 4-way security snippet support has landed19:21
zygajdstrand: is there something I could try to convert over as the first thing?19:21
jdstrandzyga: yes, let me push something19:26
jdstrandzyga: https://code.launchpad.net/~jdstrand/+junk/snappy-interfaces-security19:34
jdstrandzyga: look in snap.unpacked19:34
jdstrandsince snapcraft doesn't do interfaces yet, I unpacked a snap that used 'uses', then converted the snap.yaml and moved some things around19:35
jdstrandzyga: it is not tested to work, but it should give you the idea19:35
zygajdstrand: looking19:38
zygajdstrand: thanks19:38
zygajdstrand: https://trello.com/c/qm0XzFfl/44-switch-udev-security-to-app-level-granularity FYI19:38
zygahmm19:39
zygajdstrand: I was under the impression that 'network' and 'network-bind' would just become real top-level interfaces, not under old-security19:39
jdstrandzyga: yes19:40
zygajdstrand: ok19:40
jdstrandzyga: you asked for me to give you something to convert :)19:40
zygajdstrand: yeah, like "network"19:40
jdstrandconvert away! :)19:40
* zyga reads19:40
jdstrandnetwork-client -> network19:40
jdstrandnetwork-listener -> network-bind19:40
zygajdstrand: right I know19:40
zygajdstrand: hmm, I was hoping to get the network.go at the end of this exercise19:41
jdstrandthese are different static perms19:41
zygajdstrand: that implements "network"19:41
jdstrandsure19:41
zygajdstrand: and after the basics are set up, iterate and convert all of those over19:41
jdstrandzyga: I gave you a snap that had stuff in that used old-security. what precisely do you want and I'll give it to you19:42
zygajdstrand: so to be clear, I don't want to implement old-security now19:42
jdstrandno, of course not19:42
jdstrandyou used the word 'convert'19:42
zygajdstrand: (I can but it's more complex)19:42
zygajdstrand: ah, sorry19:42
jdstrandso I gave you the old system so you could convert19:42
zygajdstrand: I'd like to see the bits that go into making "network" tick19:42
zygajdstrand: so I can quickly create NetworkInterface{} type that has the same semantics19:42
jdstrandwe want old-security/caps to go away19:42
zygajdstrand: we can look at how that looks next week and decide how to proceed with other interfaces19:43
jdstrandzyga: tell me exactly what you want now and I will give it to you19:43
zygajdstrand: ok, one se19:43
zygasec*19:43
zygajdstrand: given those four methods: https://github.com/ubuntu-core/snappy/blob/master/interfaces/core.go#L8119:44
zygajdstrand: (consecutive)19:44
zygajdstrand: I'd like to know what security snippets to put inside for "network"19:44
jdstrandoh19:44
jdstrandzyga: did you look in the ppa?19:44
zygajdstrand: I suspect that it translates to a few syscalls and maybe some AA19:44
zygajdstrand: no, which ppa, sorry, maybe I missed a link19:44
jdstrandI sent it via email yesterday. don't worry, let me point you at a branch19:45
zygaoh, sorry, I'm not great with catching up on email; thanks19:45
jdstrandzyga: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/files/head:/data/19:45
jdstrandzyga: drill down into {apparmor,seccomp}/policygroups/ubuntu-core/16.04/network19:46
zygajdstrand: that's exactly what I needed, thank you19:46
zyga:)19:46
zygawoot19:46
jdstrandnp, sorry for the confustion19:46
zygahehe, sorry, this was a looong day (yesterday too)19:47
jdstrandzyga: 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
jdstrandbut I suspect the branch is enough19:47
zygajdstrand: yeah, the branch is enough19:48
zygajdstrand: 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 side19:48
jdstrandzyga: correct19:48
zygagreat19:48
zygaone moment :)19:48
kyrofajdstrand, are the read/write paths new to 16.04? Or did they exist in 15.04 as well?20:10
kyrofaLooks like the docs have been replaced on developer.ubuntu.com, now I can't remember :P20:10
zyga(almost done, writing tests)20:15
jdstrandkyrofa: 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 yaml20:15
kyrofajdstrand, I don't suppose you know of any examples?20:16
jdstrandkyrofa: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.0420:20
kyrofajdstrand, ah ha!20:21
kyrofajdstrand, is the policy_group in the override of that example redundant due to the cap of the service?20:23
jdstrandyes20:23
kyrofaOr do they need to match up?20:23
kyrofaOkay20:23
jdstrandoh wait20:23
jdstrandI thought you were asking a different question20:23
jdstrandkyrofa: security-override can only be used by itself on 15.0420:24
kyrofaOh wow, I totally missed that there were two services20:24
kyrofaAhem20:24
jdstrandkyrofa: so, any 'caps' you had in your yaml, but in the policy_groups of the json20:24
jdstrandthen remove the caps from the yaml20:24
kyrofaGotcha, okay. Yeah, I like 16.04 better, too ;)20:24
jdstrandyes20:24
kyrofaThanks for the pointer!20:25
jdstrandnp20:25
jdstrandhistorically, this is because of the click compat stuff and it not getting all moved by 15.0420:25
jdstrandI did say it was horrible to use :)20:25
kyrofaYeah that makes total sense20:26
zygajdstrand: ok20:33
zygajdstrand: ready?20:33
zygajdstrand: https://github.com/ubuntu-core/snappy/pull/58720:33
zygajdstrand: note that this is the no-shortcuts taken version20:34
zygajdstrand: with 2nd one I'll itroduce a simple "base class" like support so all the grotty details will go away20:34
zygajdstrand: and 99% of the code will be copy-paste from your bzr branch20:34
kyrofajdstrand, FYI typo on that page, overrides has no s20:34
zygaogra_: ^^ it's happening20:37
zygajdstrand: tell me what you think20:38
zygajdstrand: I have to leave in 7 minutes20:38
jdstrandzyga: 7 minutes is not a lot of time. I looked at it and see how it works20:49
jdstrandzyga: I look forward to the 99% case next week :)20:49
zygajdstrand: cool20:52
zygajdstrand: I'm getting off then20:52
zygajdstrand: have a nice weekend20:52
zygajdstrand: I'll simplify this and send a dozen pull requests your way20:53
jdstrandzyga: you too! thanks! :)20:53
=== retrack is now known as Guest3881
wililupyquestion: Has anyone seen the error: ubuntu-core-launcher unalbe to make /tmp/ private. errmsg: Invalid argument?21:20
wililupymy snaps that are system services are failing to start and going into a failed state.21:21
ysionneau18: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!