[00:04] we should probably just document how to use the oem config bits and remove hw-assign [00:11] jdstrand: so for me hw-assign is about drafting rules for development [00:11] you do hw-assign app /dev/null [00:11] this creates a rule with path=/dev/null :) [00:12] that was how I saw it too [00:12] yes, that used to work [00:12] now with the cgroups and launcher, it doesn't [00:12] you could also do hw-assign --kernel=ttyS* --with-tag=... [00:12] this will just create the same rules we havae [00:12] just "runtime rules [00:12] :" [00:12] once you are happy you can dumb them and copy them into your oem config :) [00:12] right, we'd need to define the cli experience for that [00:12] jdstrand: sure i am saying this would be mapped into that [00:12] udev engine [00:13] * jdstrand nods [00:13] right, if we didn't remove hw-assign, we would have to integrate it [00:13] the trello card currently says update it for cgroups [00:13] ack [00:14] think that can be SRU'd the advanced CLI is then future [00:14] yeah, that sounds fine [00:14] fine [00:14] heh [00:18] jdstrand: so you say that apps have now zero device nodes? [00:18] no, they have a few [00:18] wasnt there a default set of nodes that we wanted to assign [00:18] where can i find that? [00:18] /dev/null, /dev/full, /dev/zero, etc [00:18] that list :) [00:18] it is hardcoded in the launcher [00:18] let me get the link [00:19] asac: http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/main.c#L57 [00:23] jdstrand: ok, did you upload new -security? [00:24] I am about to [00:24] it will be a few minutes [00:26] hmm [00:26] so the go webserver does not start anymore [00:28] asac: sudo grep DEN /var/log/syslog ; sudo sc-logresolve /var/log/syslog [00:28] I can try here [00:29] Apr 22 00:24:44 localhost kernel: [ 6546.952744] audit: type=1326 audit(1429662284.103:45): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2682 comm="sed" exe="/bin/sed" sig=31 arch=c000003e syscall=137(statfs) compat=0 ip=0x7f9a1d0a4017 code=0x0 [00:29] jdstrand: statfs [00:29] ah we added statvfs earlier [00:30] I'll fix and see if there are any other stat* that we missed [00:30] jdstrand: so python xckd server also has no port open [00:30] root 1244 1 0 00:29 ? 00:00:00 /usr/bin/python3 /apps/xkcd-webserver.canonical/0.4/bin/xkcd-webserver [00:30] it is running though [00:31] or wait [00:31] what does logresolve say about that? [00:31] fyi, the final syscall list hasn't been uploaded yet. tyhicks and I have been reviewing it today [00:31] its fine [00:32] python works [00:32] just didnt have right port forward [00:32] and was to stupid for lsof [00:32] which is what I am preparing now. it changes some things around wrt to the networking bits that could have blocked it, but the new upload won't block it [00:32] ok, good [00:32] its odd [00:32] lsof doesnt have a hit on 80\ [00:32] e.g. no hit on liten [00:32] LISTEN [00:33] oha [00:33] i dont see the LISTEN ports as normal user [00:33] guess thats a feature? [00:33] as root i see it [00:33] that is normal [00:34] http://paste.ubuntu.com/10864024/ [00:34] yeah [00:34] I don't know why otoh, but that is consistent with my experience [00:36] jdstrand: its not on my normal desktop :) [00:36] maybe admin group [00:36] good [00:36] jdstrand: added statfs and fstatfs to seccomp [00:36] and now go is running [00:37] cool [00:38] slangasek: is there a new image supposed to happen now? [00:38] iirc it should be about time :) [00:39] jdstrand: not sure if fstatfs is needed, but saw fstatvfs so thought it makes sense [00:39] asac: next one fires off in 16 minutes [00:39] jk [00:39] k [00:40] asac: it does, there are also statfs64 and fstatfs64 that I am adding [00:40] right [00:41] I'm also downloading the latest linux-libc-dev to see if we are missing anything else [00:44] interesting, a new syscall 'switch_endian' [00:46] heh [00:46] guess docker might want to use that later [00:46] it is something for powerpc [00:46] sure [00:50] jdstrand: so i am lost currently how our mir etc. framework can easily be tested without hw-assign [00:50] asac: it is probably also broken under the launcher [00:51] jdstrand: you mean if you assign the right devnodes it still doesnt work? [00:51] because aiui, it uses a hadn-crafted policy [00:51] jdstrand: well, there are two things... a) policy and b) access to dri devnodes [00:52] do you know what the policy hacks look like? [00:52] hw-assign does nothing with udev atm (hence the trello card). the launcher looks at udev to add devices to the cgroups [00:52] right [00:52] it may not. I have not seen the branch [00:52] but we need some cli so folks can test mir [00:52] without having to put togehter a full appliance [00:52] jdstrand: where do we put the udev rules? [00:53] /lib/udev/rules.d/80-snappy-assign.rules [00:53] but if they use hw-assign, it is broken cause hw-assign and udev don't do anything. if it uses hand-crafted policy, it is broken because nothing tells the launcher to add the devices to the cgroups [00:53] sure i get that [00:53] saying that hw-assign should just add new udev rules :) [00:53] lol [00:53] yes, it should :) [00:54] hence the aforementioned trello card :) [00:54] hehe [00:54] so [00:54] anyway, yeah [00:54] what does a udev rule look like? [00:54] that just matches the path? [00:55] so, that is going to be in snappy somewhere [00:55] I see that http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/snappy-app-dev is a script to add files to the cgroups [00:56] https://code.launchpad.net/~mvo/snappy-hub/snappy-examples-oem-hardware-snap [00:56] hw-access could call out to that [00:56] but, I think that is being removed (no matter, the same functionality could be added to hw-assign [00:57] well hwassign should add the proper rules imo [00:57] if hw-assign is going to be persitent, use, it should add the udev rules [00:57] s/use/yes/ [00:58] it is probably pretty easy to add come to think of it-- all of it is already in snappy [00:58] hmm [00:58] so an oem snap can ship binaries? [00:58] wow [00:59] I was not aware of that either [00:59] * jdstrand jots that down to ask about later [01:00] sergiusens: where are our oem snap sources [01:00] i dont see them in ~snappy-dev [01:11] jdstrand: ok somethign worrying: http://paste.ubuntu.com/10864146/ [01:11] hello-world.jdstrand failed to install: exec: "sc-filtergen": executable file not found in $PATH [01:12] indeed [01:12] that looks similar to the fs issues I keep talking about [01:12] ? [01:12] what does dmesg say? [01:13] jdstrand: thats when running udf [01:13] udf [01:13] dmesg doesnt say much [01:13] [10770.939947] systemd-udevd[10485]: failed to execute '/tmp/test.sh' '/tmp/test.sh': No such file or directory [01:13] :) [01:13] not sure what that is [01:13] I guess you need to have ubuntu-core-security-utils on your host [01:14] I'm not sure where you are seeing that [01:14] on the host or in the guest? [01:14] hmm. thats not in the ppa it seems [01:14] jdstrand: on the host [01:14] when running udf [01:14] ubuntu-core-security-utils is a part of ubuntu-core-security [01:14] to produce an image with stuff preinstalled [01:14] I see [01:15] so, you should be able to install ubuntu-core-security-utils from vivid [01:15] i am on trusty though [01:15] so this has to go into tools ppa's [01:15] for all supported things [01:15] and dependency need adding [01:15] sergiusens: ^ [01:16] do we need to run this stuff? [01:16] I've been a little surprised how much need to be on the host for udf [01:16] i mean those sc-... commands? [01:16] I don't know [01:16] jdstrand: i think udf just runs snappy tool [01:16] I guess it is preinstalling the snap via the host tools [01:16] right [01:16] but the apparmor stuff is done on first boot [01:16] this one should be done similar i gues [01:16] it seems it would be much safer to use the tools in the image [01:16] s?? [01:16] no? [01:16] well [01:16] I agree [01:17] i think its wrong [01:17] but, we don't have the systemd unit file to do that yet [01:17] to do what? [01:17] which was one of the things I mentioned earlier [01:17] i think appamor is run on first boot, no? [01:17] apparmor is run on every boot [01:17] on first boot it will notice that there isn't policy for the snaps [01:18] hmm. i mean the stuff that you run when package gets installled [01:18] okk [01:18] and it will call aa-clickhook and everything is fine. niext time, the policy won't have to be regenerated [01:18] shouldnt sc do all the same? [01:18] i thought we would have same semantics [01:18] seccomp doesn't have that [01:18] click had that nice quality [01:18] so we have to reimplement it for seccomp and then again for apparmor when it moves away from click [01:19] this morning I was talking about updating policy via a unit if the seccomp policy changed [01:19] that unit would solve this problem too [01:20] asac: sc and aa should have the same semantics. aa is still implemented as a hook tool. sc is not. aa will be made to not once we clean it up in 15.10 [01:21] yes, but what i thought you said was that we would follow same approach for sc [01:21] anyway [01:21] so now we have to add unit? [01:21] and figure how to get rid of sc invocation in snappy install? [01:22] what I said was that we would implement the new approach so we only have one thing to migrate when we drop the click methodology [01:22] sc is new approach [01:22] aa is old [01:22] you still need sc invocation on snappy install so that the policy is in place when a service or binary is started prior to reboot [01:23] so now we have two approaches... in future never do two approaches [01:23] always one and then move both over [01:23] so we need unit [01:23] and special case in snappy to not run anything if its on host tool [01:23] not sure how to do that [01:24] sergiusens: any idea? [01:24] asac: well, you say the two approaches thing. the reality is that it would have taken as much time to do the old approach for sc as the new, and it seemed silly to do the old only two weeks later to undo it [01:25] i know, but the new approach makes things more complex [01:25] so we should have done that [01:25] not really [01:25] there is a unit for apparmor [01:25] it is just a different unit [01:25] hmm [01:25] anyway, what needs doing now? [01:25] we need to fix this for sure somehow [01:25] I don't think this two approaches thing is something to worry about [01:26] I will implement the unit as I said I would this morning [01:26] ok [01:26] and how to fix snappy tool? [01:26] I helped with the launcher all day today [01:26] right [01:26] that we need serguisens on [01:26] sergiusens: see above, we need the snappy install not call sc- stuff if run through udf [01:26] e.g. on host [01:26] and defer that to the first boot/unit [01:27] maybe it is as simple as unpacking and not running the tools if doing a preinstall [01:27] right [01:27] i dont think they will like just unpacking [01:27] they were super happy that snappy install was finally able to run on host tool [01:27] cross [01:27] that's fine-- just saying, whatever doesn't need the tools [01:27] i think it does logic [01:27] the sc tools yes [01:28] that didn't come out right [01:28] so we dont want to run the sc- tools if on host [01:28] if cross [01:28] not sure how we do the decision on appamor [01:28] yes, do everything except run these bits. that said, these bits could run on the host-- they are not complicated tools [01:28] but we run them on first boot anyway [01:28] i dont want to add more stuff to tools ppa really [01:29] think that starts to become nasty [01:29] need to be tested and done for trusty etc. [01:29] I was more talking about unblocking you now [01:29] i am not blocked. but tomorrow we have to get things together [01:30] so we should do it right right away [01:30] ok, 15.04.7 uploaded to image ppa and archive [01:30] yep saw that [01:30] go-example-webserver wrks [01:30] thx [01:30] great [01:30] check 1 :) [01:32] I'll work on the unit tomorrow. that will give me insight as to what needs to happen with apparmor when we switch it to the new [01:32] jdstrand: generateSeccompPolicy [01:32] is that the whole function to kill? [01:32] on cross? [01:33] let me check [01:34] is the unit difficult? [01:34] addOneSecurityPolicy() can exit early if run under udf [01:34] it shouldn't be [01:35] addOne [01:35] isnt matching [01:35] that is in snappy/click.go [01:35] in trunk [01:35] ah [01:37] hmm [01:37] no, it's ok [01:37] I thought namespaces might trip me up, but it won't [01:38] jdstrand: is there a script you can give us to run after boot so we can test this in the morning? [01:39] that is what I need to write [01:40] jdstrand: you say we can run those tools on host? [01:40] to shortcut? [01:40] I don't see why not [01:40] I installed several images today with udf [01:40] I have ubuntu-core-security-utils installed [01:41] jdstrand: did you try snaps with built-in? [01:41] normal images work [01:41] I did not [01:41] it just busts if we have built-in stuff [01:41] I don't know how to do that [01:42] jdstrand: run udf with --oem ./... [01:42] and use http://people.canonical.com/~asac/tmp/generic-amd64_1.1_all.snap [01:42] locally [01:42] udf ... --developer-mode ... --oem ./generic-amd64_1.1_all.snap [01:42] that one tries to install hello-world.jdstrand [01:43] sudo ubuntu-device-flash core rolling --developer-mode --channel edge --oem ./oem-hardware-assign_1.0_all.snap --enable-ssh -o outputamd64.img [01:43] jdstrand: that command [01:43] give it a spin [01:45] just grab fyi, I just installed ubuntu-core-security-utils and ubuntu-core-security-seccomp from the image ppa and python3-yaml from the archive in a trusty vm fine [01:45] * jdstrand adjusts the deps for ubuntu-core-security-utils [01:46] curious why ${python3:Depends} didn't do it for me [01:49] ./oem-hardware-assign_1.0_all.snap failed to install: snappy package not found [01:50] I don't know where that is [01:50] jdstrand: sorry wrong name [01:50] uuse the one [01:50] you downloaded [01:50] ./generic-amd64_1.1_all.snap [01:50] not ./oem-hardware-assign_1.0_all.snap [01:50] sudo ubuntu-device-flash core rolling --developer-mode --channel edge --oem ./generic-amd64_1.1_all.snap --enable-ssh -o outputamd64.img [01:50] oh right, duh [01:50] heh [01:54] asac: it failed in some other manner, but it seems like it probably got past sc-filtergen [01:54] http://paste.ubuntu.com/10864267/ [01:54] jdstrand: thats probasbly becauuse your system is busted [01:54] reboot [01:55] jdstrand: wait [01:55] jdstrand: so remember that udf does not use a chroot anymore afaik [01:55] its just run on host with path etc. [01:55] not sure what your tools are doing [01:55] if you are sure your system is still alive [01:55] then reboot :) [01:55] I was running sbuild at the time. it had a problem related to unmounting [01:56] good [01:56] it might've been the systemd shared mount space stuff [01:56] ok how does it look now? [01:56] * jdstrand is trying again [01:57] it reported breaking differently, but still a umount issue [01:57] i would suggest to reboot [01:57] I can reboot, but it will be a minute [01:57] sure, better than giving up :) [01:57] * jdstrand has a lot of context atm [01:58] you could also try installing the tools I mentioned on trusty [01:59] this will mess my system a lot [01:59] but ok [01:59] utils? === c74d3 is now known as c74d [02:00] ubuntu-core-security-utils ubuntu-core-security-seccomp from the ppa [02:00] you will also need python3-yaml [02:00] and seccomp [02:00] that should be it [02:01] yay [02:01] * jdstrand uploads 15.04.8 to add Depends on python3-yaml [02:01] it worked :) [02:01] good! [02:04] too bad [02:04] hw assign is broken anyway [02:05] jdstrand: sent mail [02:06] i drop off [02:06] ok, good night [02:06] jeex it must be late there [02:07] jeez* [02:10] i think autopilot jsut udpated :) [02:10] yay [02:10] it atuomatically rebooted [02:11] nice [02:11] good to end day like that :) [02:11] lol [02:11] cu in a bit [02:12] hehe [02:12] nice :) === timchen1` is now known as timchen119 === kickinz1|afk is now known as kickinz1 [05:12] o/ [07:11] good morning [08:55] dpm, davidcalle will work on refinements for the raspi bits, the channels and the start page - those are going to be most important pieces, later on we might look into importing stuff like you did [08:55] dpm, great work [08:56] dholbach, +1 [08:57] davidcalle, sorry [08:57] I meant to say... [08:57] "davidcalle and I" [08:57] * dholbach needs another coffee :) [08:58] hi, i'm running snappy ubuntu on my raspberry pi 2 (by lool) and for some reason, the system only shows 116 MB of RAM available although it should be 1 GB of RAM. i guess it's a problem with GPU memory split, but i can't find a setting. can anybody help me please? [08:58] dholbach ;) [09:03] Good morning all; happy Earth Day! :-D [09:10] dholbach, ack, thanks! [09:12] davidcalle, I updated https://developer.ubuntu.com/en/snappy/guides/channels/ - do you feel it's clearer in the regard we discussed earlier? [09:13] davidcalle, also... I'm considering extending the image at the bottom to explain the transition from alpha to beta, etc - wdyt? [09:39] dholbach, not sure if the image needs to be extended. The table on top looks good, I still think you should add a wget and a udf examples under it, to make it clear what to do with this channel/release combination. [09:39] dholbach, the page works well for me, especially with the table called a cheatsheet [09:41] davidcalle, ah yes, that's right - I'll add an example, but I'm not sure about wget/udf instructions - wouldn't we have to update the instructions as well whenever thing change again or images get updated? [09:44] dholbach, that's true, I forgot udf was a moving target. But for wget, it would be mostly to show off how the path is composed (http://cdimage.ubuntu.com/ubuntu-core/15.04/edge/ubuntu-15.04-snappy-armhf-bbb.img.xz), to show people they can compose the img path based on what they need. === erkules_ is now known as erkules [09:45] that makes sense [09:46] unfortunately we don't have http://cdimage.ubuntu.com/ubuntu-core/rolling/ yet [09:46] dholbach, implementation detail :p [09:46] all right, I'll figure it out, thanks for the feedback [09:47] dholbach: davidcalle we have finalized u-d-f, it won't be moving again except for bug fixes [09:47] dholbach, I'd like to say something like "if it's documented, it needs to exist ASAP" ;-) [09:48] sergiusens, oh cool :) [09:55] davidcalle, ok, updated - thanks again [10:06] davidcalle, are you working on the start page now? [10:30] davidcalle, I added channel info for the kvm case - does it look all right to you? do you think it helps like that? [10:46] dholbach, I'm starting now. It looks right to me, so these are the final paths? edge at cdimages.ubuntu.com/ubuntu-snappy and stable, beta, rc at releases.ubuntu.com? [10:51] dholbach, also, we talked about this earlier, but I'm not sure we had a definitive answer : are cloud images going to follow the naming scheme for release? (or should we just use the stable image names they provide tomorrow?) [10:52] dholbach, don't mind the lat question, I've found what I'm looking for. [10:52] last* [11:24] Wondering if something is broken in the new Docker 1.6 package? I keep getting "aa-exec: ERROR: profile 'docker_docker_1.6.0.002' does not exist" when invoking Docker. [11:33] davidcalle, I'll ping the cloud guys and point them to the page - AFAIK those are the final paths, yes [11:34] dholbach, thanks [11:34] a review with Steve and Alex later on should let us know if we're on the right track or not :) [11:40] * davidcalle starts getting confused about the naming scheme again. [11:43] ppisati: hey, how is the cape going? [11:46] davidcalle, in the case of OVA, do you think we should explain the URL scheme - or just add the box with the links? [11:46] dholbach, I've done both [11:47] ok... I personally would've thought that the box would be enough, but maybe just leave it in there and we talk about it later on together :) [11:50] dholbach, the scheme of cloud-images is a bit different [11:52] oh! did you find out how it works there? [11:53] asac: i've got the original image to work, but once i compile the TI kernel, it doesn't boot on my board [11:54] yesterday i spent the entire day doing test for the release [11:54] ppisati: why do we need TI kernel? [11:54] if we have it working with our generic one? [11:54] ok have to go for lunch [11:54] bbiab [11:55] asac: because first you get a piece of hw working with the code that supports it [11:55] asac: then you derive a delta from it etc [11:56] dholbach, I think so [12:11] davidcalle, I added a box like this to the bbb docs too [12:11] davidcalle, it gets placed in the wrong area though [12:12] davidcalle, do you have an idea how to fix it? [12:15] dholbach, I'm fixing [12:16] davidcalle, if we ever do a sprint together, you should do a workshop on how to fix stuff like that :-) [12:17] I'd make sure to get a seat in the first row! [12:19] dholbach, why not :) Fixed. I'm confused by the fact that if you download both images (15.04/stable and 15.04/edge), you have no way to differentiate the files by their names. [12:20] davidcalle, we should note this down [12:23] dholbach, I've also left a comment on the card regarding the other tasks. [12:23] thanks [12:24] davidcalle, do you feel we're done with the page now, barring any changes we might need to do after a meeting with Alex and Steve and potentially the cloud guys? [12:24] dholbach, yep [12:24] cool [12:24] * dholbach hugs davidcalle [12:24]