| === c74d is now known as Guest62930 | ||
| rsalveti | sergiusens: what is the current process to release a new webdm version? | 02:09 |
|---|---|---|
| === c74d3 is now known as c74d | ||
| rsalveti | beuno: is the store fully back already? | 02:11 |
| pitti | ogra_: to avoid confusion, are you looking into fixing mountall to create a symlink instead of writing mtab? | 04:59 |
| === c74d3 is now known as c74d | ||
| mvo | lool: re serial port support for grub - could we simply enable this why default? or is there a (security) risk here? | 06:02 |
| mvo | pitti: one issue I noticed while writing upgrade/failover tests is that systemd will drop me into a emergency shell sometimes. I would prefer it to log and reboot, can I simply provide my own "emergency.service" unit that will override the default one (sorry if thats a silly question)? | 06:11 |
| tbr | mvo: what would make serial different from a screen and keyboard in terms of security? If you have physical access to a system, security is toast. | 06:47 |
| * tbr was unhappy that he had to screw around with grub configs and uefi to get snappy working on real embedded intel hardware | 06:47 | |
| mvo | tbr: I agreee but wanted to double check if there is something I might have missed | 06:48 |
| mvo | if there is no risk I'm much in favor of just enalbing it by default | 06:48 |
| pitti | mvo: yes, that should work fine; i. e. adding an /etc/systemd/system/emergency.service -> /lib/systemd/system/systemd-reboot.service ought to work | 06:49 |
| mvo | pitti: sweet, thanks | 06:50 |
| pitti | mvo: (warning, haven't tested -- but I see no reason why it shouldn't work) | 06:50 |
| mvo | thats fine, I will test, just wanted to double check if its a valid assumption or not | 06:50 |
| pitti | mvo: oh, for testing you probably want to put it into /run/, not /etc ? | 06:50 |
| pitti | mvo: or is that something which should be done in snappy in general, not just for testing? | 06:51 |
| mvo | pitti: in general | 06:51 |
| pitti | mvo: if so, it shoudl be done differently to avoid /etc/ | 06:51 |
| pitti | mvo: ah ok, then I misunderstood you | 06:51 |
| mvo | pitti: the idea is that it should auto-reboot if its in "try" mode at least so that it can fallback to the "good" partition | 06:51 |
| pitti | mvo: so then snappy.deb could ship a /lib/systemd/system/emergency.service.d/snappy.conf with something like | 06:52 |
| pitti | [Service] | 06:52 |
| mvo | pitti: aha, nice | 06:52 |
| pitti | ExecStartPre= | 06:52 |
| pitti | ExecStart= | 06:52 |
| pitti | ExecStart=/bin/systemctl --force reboot | 06:52 |
| pitti | Type=oneshot | 06:52 |
| pitti | mvo: i. e. rip out the parts from emergency.service which you don't want (reset the ExecStart* commands), and then call what you do want (from systemd-reboot.service) | 06:53 |
| pitti | mvo: that can be shipped in a deb, statically, without having to touch /etc/ | 06:53 |
| mvo | pitti: cool | 06:54 |
| mvo | pitti: I will do that then | 06:54 |
| pitti | mvo: foo.service.d/something.conf is like upstart's *.override files | 06:54 |
| mvo | (add it to the relevant bugreport for now and later to it to be precise :) | 06:54 |
| pitti | mvo: see man systemd.unit, grep for foo.service.d/ | 06:54 |
| mvo | thanks | 06:54 |
| === erkules_ is now known as erkules | ||
| dholbach | good morning | 07:23 |
| lool | mvo: so I suspect the serial port name might differ (e.g. ttyS0 and ttyS1) and that people might want to disable that if they actually need the serial port for something else | 07:43 |
| lool | mvo: it kind of feel like a deployment option to me: headless servers where you want to use an existing serial port, but some platforms wont have it; perhaps there's a smart way to detect it though, like "press space now to enable serial console" during grub startup? | 07:44 |
| beowulf | morning | 08:01 |
| Chipaca | mo'in | 08:04 |
| davidcalle | dholbach, morning, just a heads up that the doc diff I was hoping for in my script is not possible, django cms is doing way too many annoying things when publishing. Well, it's possible of course, but at this point, that would just be a waste of time :) | 08:26 |
| dholbach | ok... let's have a chat in a bit :) | 08:29 |
| JamesTait | Good morning all; happy Friday, and happy Learn About Composting Day! 😃 | 08:40 |
| Chipaca | mvo: you around? | 08:54 |
| mvo | Chipaca: yes | 08:56 |
| mvo | Chipaca: working on a fix for -lp1449032- | 08:56 |
| mvo | Chipaca: what can I do for you? | 08:56 |
| Chipaca | mvo: silly question: any reason why we're using “setActive/unsetActive” instead of “activate”/“deactivate” ? | 08:57 |
| mvo | Chipaca: none really, go for the new name | 08:57 |
| Chipaca | k | 08:57 |
| Chipaca | regen is basically unsetactive/setactive, hence why i'm in that code | 08:58 |
| Chipaca | it's painfully obvious i haven't looked into this bit of code before :) | 08:58 |
| mvo | heh :) is it that simple? thats very cool | 08:58 |
| mvo | Chipaca: meh, I hope its not too terrible :/ | 08:59 |
| Chipaca | that thing about us not parsing yaml twice? all lies as soon as we look at these | 08:59 |
| Chipaca | what's mroe | 08:59 |
| Chipaca | we parse the yaml inside (un)setActive | 08:59 |
| Chipaca | and then parse the click manifest | 08:59 |
| Chipaca | to get the package type | 08:59 |
| Chipaca | which is in the yaml | 08:59 |
| mvo | ohh | 08:59 |
| mvo | uff | 08:59 |
| Chipaca | we win some kind of award for that | 08:59 |
| Chipaca | not sure it's a good award :) | 08:59 |
| Chipaca | but at least we're consistent :) | 08:59 |
| * mvo hands Chipaca a broom stick and a janitor award | 09:00 | |
| mvo | Chipaca: lol@consistent | 09:00 |
| mvo | Chipaca: well, time to kill that click compat stuff entirely, oh well | 09:00 |
| mvo | Chipaca: thanks a lot for going into these stables of augean | 09:00 |
| Chipaca | heh. 's not that bad :) | 09:01 |
| beowulf | should i label "webdm front end stuff" as webdm or webdm client? | 09:25 |
| * beowulf thinks 'webdm' | 09:26 | |
| === fgimenez_ is now known as fgimenez | ||
| Chipaca | augh! bad branch | 09:48 |
| * Chipaca aborts it | 09:48 | |
| Chipaca | mvo: Alas! Needs fixing. Inline. | 10:03 |
| zyga | hi, I'm following https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/, I installed the hello-world snap but when I execute it I get: | 10:06 |
| zyga | (BeagleBoneBlack)ubuntu@localhost:~$ hello-world.echo | 10:06 |
| zyga | mkdir: cannot create directory ‘/tmp/snaps/hello-world.sideload’: Permission denied | 10:06 |
| zyga | any ideas? | 10:06 |
| Chipaca | zyga: yes | 10:06 |
| Chipaca | zyga: there's a bug :) | 10:06 |
| Chipaca | zyga: or :-/ depending on your lookout | 10:07 |
| Chipaca | zyga: easy to workaround | 10:07 |
| zyga | Chipaca: thanks, what should I do? | 10:07 |
| Chipaca | zyga: sudo chmod 01777 /tmp/snaps | 10:07 |
| zyga | thanks | 10:07 |
| zyga | Chipaca: any chance for the update to the core snap? | 10:07 |
| Chipaca | zyga: and, if you want, edit snappyd in /apps/webdm/current/snappyd and add -m01777 to the mkdir | 10:08 |
| zyga | Chipaca: oh, I removed webdm | 10:08 |
| Chipaca | zyga: 15.04.1 is in progress | 10:08 |
| Chipaca | zyga: ah, ok :) | 10:08 |
| * zyga just rebooted | 10:08 | |
| zyga | let's see how that works | 10:08 |
| Chipaca | zyga: then the error should go away on its own in a bit | 10:08 |
| Chipaca | heh, ok | 10:09 |
| Chipaca | zyga: let me know how it goes | 10:09 |
| Chipaca | zyga: there might be other bits still making that directory with the wrong permissions | 10:09 |
| Chipaca | zyga: in rolling the whole thing is avoided because you have private tmps | 10:09 |
| zyga | thanks | 10:09 |
| Chipaca | zyga: but that's still WIP a bit | 10:09 |
| zyga | while we're talking, how reliable is deb2snap in practice? I read the code so I kind of know how it works, I want to try taking a big/complex set of debian packages and making them available in a snap | 10:10 |
| Chipaca | zyga: thank you! and if anything seems wrong or inconvenient please do let us know | 10:10 |
| zyga | Chipaca: (works after reboot, so that's good) | 10:10 |
| Chipaca | zyga: I have not looked at at deb2snap, tbh | 10:10 |
| zyga | Chipaca: thanks, I'll let you know after I try :) | 10:10 |
| Chipaca | zyga: mterry is your guy for that, but he's not around right now | 10:11 |
| Chipaca | zyga: or vanvugt | 10:11 |
| Chipaca | zyga: (look at "top contributors" on https://launchpad.net/deb2snap ) | 10:12 |
| zyga | yep, I'll stay in touch | 10:12 |
| beuno | rsalveti, downloads yes, uploads are working but I need to check if they are autonatically scanned | 10:39 |
| === Guest53 is now known as clurrrr | ||
| === leandrosansilva_ is now known as leandrosansilva2 | ||
| sergiusens | beowulf: around? | 12:11 |
| sergiusens | beowulf: what am I to expect from https://code.launchpad.net/~stephen-stewart/webdm/repent-harlequin-said-the-ticktockman/+merge/260120 ? | 12:12 |
| beowulf | sergiusens: magic | 12:12 |
| sergiusens | beowulf: because I don't see the description, download_size or installed_size anywhere | 12:13 |
| ogra_ | sergiusens, isnt that clear from the url ? | 12:13 |
| ogra_ | s/url/branch name/ | 12:13 |
| sergiusens | ogra_: yeah, but it doesn't do that ;-) | 12:13 |
| beowulf | sergiusens: one sec, context switch | 12:13 |
| sergiusens | beowulf: ok | 12:14 |
| * sergiusens notices that at least a second has already pass | 12:14 | |
| Chipaca | asac: ogra_: the problem is that services don't have something mkdir'ing /tmp/snaps for them, and so some of them do it themselves, and they don't all set the right permissions to then allow other apps to create subdirs of /tmp/snaps | 12:14 |
| beowulf | sergiusens: so you are the ticktockman! | 12:14 |
| Chipaca | asac: ogra_: for webdm, it's fixed on trunk i think, but not released yet | 12:15 |
| Chipaca | asac: ogra_: snappy itself fixes it in a better way, again on trunk | 12:15 |
| ogra_ | Chipaca, yeah | 12:15 |
| sergiusens | Chipaca: was going to release yesterday, but hell came | 12:15 |
| sergiusens | releasing today would hide the issue for people using webdm at least | 12:15 |
| Chipaca | sergiusens: we call him "beuno" when he's in the room | 12:15 |
| * beuno lols but opts-in Chipaca into "experimental" features | 12:16 | |
| * Chipaca hugs beuno | 12:16 | |
| beowulf | sergiusens: updated the mp, it gives snap icons a label if they aren't 'app' types and adds the download size to the descriptions | 12:19 |
| beowulf | sergiusens: the next branch allows you to then sort by download size | 12:19 |
| sergiusens | beowulf: problem is, I don't see a description or any other text | 12:21 |
| beowulf | sergiusens: do you mean on lp, or in webdm? | 12:21 |
| sergiusens | beowulf: there, browser was caching the css it seems | 12:22 |
| beowulf | sergiusens: yeah, i will add some cache busting tokens to the js and css urls | 12:23 |
| sergiusens | beowulf: the ubuntu-core installed size is whack, maybe it should be hidden? | 12:23 |
| sergiusens | beowulf: for now at least | 12:23 |
| beowulf | sergiusens: yeah, i can hide it or make it "n/a" or something (which i'd prefer to do for symmetry) | 12:23 |
| beowulf | sergiusens: but i wanted you to see and fix it :) | 12:24 |
| sergiusens | beowulf: n/a is fine | 12:24 |
| beowulf | sergiusens: i think if we're showing ubuntu-core as an installed snap it should have the same info (and it would be useful to see that, imo) | 12:24 |
| sergiusens | beowulf: I already said that I agreed! :-) | 12:27 |
| beowulf | fix it fix it fix it | 12:28 |
| sergiusens | beowulf: also, in the column view I see the installed sizes but not the download_size, but what irks me is the column alignment or lack of ;-) | 12:29 |
| beowulf | sergiusens: i think i fix that in the next branch | 12:30 |
| sergiusens | beowulf: ah, k | 12:30 |
| beowulf | sergiusens: fwiw, i'm not using download size at all until i get some time to think a bit more about how the store should look and work | 12:32 |
| kyrofa | Hey sergiusens, what is your websocket vision for webdm? | 12:33 |
| rsalveti | morning | 12:33 |
| sergiusens | kyrofa: that is a broad question! | 12:34 |
| sergiusens | kyrofa: not sure if I want to do something restful over a websocket or use it as a complimentary data channel for the http/rest stuff | 12:35 |
| dholbach | jdstrand, davidcalle just made lp:~ubuntudeveloperportal-editors/+junk/snappy-docs available which should help us keep the site up to date | 12:35 |
| sergiusens | kyrofa: I need to discuss with beowulf as well | 12:35 |
| Chipaca | mvo: more bad news :( | 12:35 |
| dholbach | jdstrand, I'm looking at meta.md right now - it's where you said yesterday: | 12:35 |
| dholbach | <jdstrand> for example: 'security-template' should be a subpoint of 'caps' | 12:35 |
| jdstrand | dholbach: yeah, that was the one to forget :) | 12:36 |
| dholbach | ok | 12:36 |
| jdstrand | I was being silling on security-template and caps | 12:36 |
| sergiusens | beowulf: it is in Details though | 12:36 |
| jdstrand | dholbach: but notice that services doesn't have subpoints | 12:36 |
| beowulf | sergiusens: ah | 12:36 |
| sergiusens | beowulf: can I add one more critique, can the snappy package type be left aligned? | 12:36 |
| dholbach | jdstrand, ok cool - looking | 12:37 |
| kyrofa | sergiusens, Haha, I can be less broad! We have a specific use-case I wanted to discuss | 12:37 |
| jdstrand | dholbach: same with binaries | 12:37 |
| davidcalle | jdstrand, and binaries as well | 12:37 |
| beowulf | sergiusens: in grid style? | 12:37 |
| jdstrand | dholbach: I haven't reviewed all of it, but those two for sure | 12:37 |
| sergiusens | kyrofa: want to set something up for later today? | 12:37 |
| sergiusens | beowulf: in row style | 12:37 |
| kyrofa | Sure! What time works best? | 12:38 |
| sergiusens | kyrofa: 1:30 PM ART? | 12:38 |
| beowulf | sergiusens: yes, the row isn't in good shape and i want to tidy it up, these mps are mostly about grid style though | 12:38 |
| davidcalle | jdstrand, dholbach, I'm trying to figure out why | 12:38 |
| zyga | ogra_: nice | 12:38 |
| kyrofa | sergiusens, sounds great! I'll make an invite | 12:39 |
| jdstrand | davidcalle: I thought I saw some django things mentioned in lp:snappy for the docs. does snappy/15.04 need similar changes? | 12:39 |
| beowulf | kyrofa: sergiusens: webdm client would probably benefit more from server sent events that websockets | 12:39 |
| jdstrand | something about spacing the indents right | 12:39 |
| kyrofa | beowulf... how do you do that without something like websockets? | 12:40 |
| davidcalle | jdstrand, hmm... | 12:40 |
| * davidcalle is afk for a moment, brb | 12:40 | |
| jdstrand | if that is needed, then I imagine everything in docs/* should be looked at in both snappy and snappy/15.04 | 12:40 |
| kyrofa | beowulf, do you maintain the web interface then? | 12:40 |
| beowulf | jdstrand: that might have been me? django vrs githubmarkdown flavours? | 12:41 |
| mvo | Chipaca: heh, thanks! looks like its not my day today | 12:41 |
| beowulf | kyrofa: i do yes, with sergiusens and others here | 12:41 |
| kyrofa | beowulf, want to be included in our HO? | 12:42 |
| sergiusens | kyrofa: yeah, add him if the time works | 12:42 |
| Chipaca | mvo: it isn't often i suggest more tests in an MP. I feel dirty. | 12:42 |
| jdstrand | beowulf: maybe? this is developer.ubuntu.com/snappy vs docs/* | 12:42 |
| beowulf | jdstrand: yeah, i tried to fix some issues with list indentation which i think were caused by people using github markdown, whereas developer.u.c uses django which uses a different flavour | 12:43 |
| jdstrand | davidcalle: also another data point-- the services/binaries thing in meta.md on the website is the same sort of issue that security.md on the website had: subpoints weren't being indented correctly. you fixed the latter on your end iirc | 12:44 |
| jdstrand | ah | 12:44 |
| sergiusens | Chipaca: pretty please https://code.launchpad.net/~sergiusens/webdm/metaupdate/+merge/260579 | 12:44 |
| jdstrand | davidcalle: see what beowulf said ^ | 12:44 |
| jdstrand | we should probably document that and have a linter for docs/* | 12:44 |
| Chipaca | sergiusens: s/Ubuntu Core Snappy/Snappy Ubuntu Core/ I guess? | 12:45 |
| * sergiusens wants to kill readme.md and add a description entry in package.yaml | 12:45 | |
| Chipaca | also, an end to the name/title/description nonsense | 12:45 |
| sergiusens | Chipaca: hmm, I think not, I conciously wrote it like that Ubuntu Core uses Snappy and this allow device management | 12:45 |
| Chipaca | sergiusens: +1'ed, then | 12:46 |
| sergiusens | Chipaca: thanks | 12:46 |
| beowulf | kyrofa: not sure what your HO is about, but sure, why not :) | 12:46 |
| Chipaca | sergiusens: ma che grazie, go do some reviews yourself now :) | 12:47 |
| sergiusens | beowulf: websockets and the rest of the snappy vision | 12:47 |
| * sergiusens tries to find inspiration and write something up before then | 12:47 | |
| kyrofa | beowulf, might be at the tail end of your day, so no pressure. | 12:48 |
| kyrofa | beowulf, I'm writing the Unity8 scope for installing/uninstalling/launching snaps | 12:48 |
| kyrofa | beowulf, like... the local version of the webdm web interface | 12:48 |
| dholbach | davidcalle, looks like it works with the markdown command | 12:49 |
| beowulf | kyrofa: have you looked at sse's? | 12:49 |
| dholbach | davidcalle, at least for the type: app / oem / framework case | 12:50 |
| kyrofa | beowulf, no I didn't know someone else was working on this | 12:50 |
| beowulf | kyrofa: i looked briefly a while back, websockets might be a bit overkill and are reportedly a pain to work with | 12:51 |
| kyrofa | beowulf, oh haha-- I thought you were saying someone named sse was making a unity8 scope, but you're talking about server-sent events... sorry | 12:53 |
| beowulf | for webdm, it's mostly responding to events, what it sends to the server is occasional and regular xhr is fine for that | 12:53 |
| D_Cent | hi, i've built a snappy ubuntu image for the raspberry pi 2 with the image by lool and for some reason, it only shows 128 MB RAM available although there should be 1 GB - how can i adjust that? | 12:53 |
| kyrofa | beowulf, still early in the morning for me :P | 12:53 |
| beowulf | kyrofa: haha | 12:53 |
| ogra_ | D_Cent, that seems to be an issue with the bootloader files used on that image ... | 12:53 |
| kyrofa | beowulf, I've not actually looked into SSEs. Let me read a little | 12:54 |
| beowulf | kyrofa: so for install, you're mainly listening for progress or success events, but you only send one 'install' event | 12:54 |
| kyrofa | beowulf, see, this is good! You and I need to talk more often | 12:54 |
| beowulf | kyrofa: try this too http://chimera.labs.oreilly.com/books/1230000000545/ch16.html#EVENTSOURCE_API | 12:54 |
| beowulf | kyrofa: downside (for me, not you, i think) is sse's are not available on IE | 12:55 |
| D_Cent | ogra_: is there a quick way to fix it myself? | 12:55 |
| * beowulf breaks for lunch | 12:55 | |
| kyrofa | beowulf, not to mention I'm interacting with the API from Go. DOM manipulation may not help us there | 12:55 |
| ogra_ | D_Cent, not that i know of ... there were suspicions that it works if you replace start.elf with one from an official RPi2 image | 12:56 |
| ogra_ | D_Cent, i'm tasked to look into that but wont manage to do so before monday i fear | 12:56 |
| kyrofa | sergiusens, I sent the invite-- did I get the time right? | 12:57 |
| D_Cent | ogra_: okay thank you :) then i'll check back on monday | 12:57 |
| sergiusens | kyrofa: yes, it could be 1h earlier if it help beowulf | 13:00 |
| kyrofa | beowulf, ah, but behind the scenes it just keeps the SSEs just keep the TCP socket open, huh? I can probably work with that | 13:01 |
| kyrofa | sergiusens, alright, I'll wait to hear what beowulf thinks after his lunch and modify if necessary | 13:01 |
| lool | D_Cent: that's a known bug; ogra is looking into it; Paolo's image doesn't have this issue; we'll soon have this fixed | 13:11 |
| ogra_ | yeah, i'll merge paolos stuff in | 13:12 |
| davidcalle | jdstrand, beowulf, django isn't involved in the current issue, the cms only takes html and docs are converted locally before uploading | 13:22 |
| Chipaca | mvo: sergiusens: when regenerating systemd and binary wrappers and such, i should only look at frameworks and apps, not other types of packages, yes? | 13:27 |
| sergiusens | Chipaca: seems correct | 13:27 |
| ogra_ | do we have other types ? | 13:28 |
| ogra_ | (yet) | 13:28 |
| sergiusens | ogra_: gadget, os and kernel | 13:28 |
| sergiusens | ogra_: as part of yet, we have oem | 13:28 |
| ogra_ | ah, i thought they dont exist yet | 13:28 |
| ogra_ | ah, right | 13:28 |
| davidcalle | jdstrand, you were right, snappy trunk is fine, snappy 15.04 is not (https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md VS http://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/meta.md) | 13:31 |
| davidcalle | Indentation issue in 15.04 markdown | 13:32 |
| jdstrand | interesting | 13:32 |
| jdstrand | I just use the 'markdown' command to see if there are errors. clearly it is not enough | 13:32 |
| jdstrand | or at least in the way that I invoke it | 13:33 |
| * jdstrand notes he did not write meta.md, but imagines others are doing something similar) | 13:33 | |
| beowulf | davidcalle: i made those changes, fwiw | 13:33 |
| davidcalle | jdstrand, for the moment, are you aware of any changes between trunk and 15.04 for this file? | 13:33 |
| davidcalle | beowulf, the bad ones or good ones ? ;) | 13:34 |
| beowulf | davidcalle: https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md is me | 13:34 |
| jdstrand | davidcalle: when I merged my 1 char MP yesterday, there was a conflict | 13:34 |
| davidcalle | beowulf, ok, thanks to you we have found the issue then | 13:35 |
| jdstrand | I can't comment on the rest of the doc (I don't really modify too often) | 13:35 |
| beowulf | davidcalle: without the correct indentation the list wasn't appearing in the guides, which made it hard to understand | 13:35 |
| davidcalle | beowulf, indeed | 13:36 |
| beowulf | davidcalle: i thought it was because the markdown in django needs 4 spaces not 2 | 13:36 |
| jdstrand | beowulf: is there a tool you use to make sure it will display well in django? | 13:36 |
| beowulf | jdstrand: i don't know of one | 13:36 |
| * davidcalle replaces current guide with one from trunk, text is identical | 13:37 | |
| beowulf | kyrofa: sergiusens: if you could move the ho an hour forward I would be grateful :) | 13:38 |
| kyrofa | beowulf, done! | 13:39 |
| kyrofa | beowulf, by the way, looks like libs exist to polyfill SSEs into IE. I'm sure you're aware? | 13:39 |
| beowulf | kyrofa: yeah, my first thought was if we had everything working in webdm with hr polling, we'd add sse support as a conditional | 13:40 |
| beowulf | s/hr/xhr | 13:40 |
| beowulf | don't want to poll hr | 13:40 |
| kyrofa | beowulf, hr may not give you what you're looking for | 13:41 |
| beowulf | kyrofa: true | 13:41 |
| D_Cent | lool: thank you for letting me know! | 13:45 |
| beowulf | kyrofa: have you seen the latest webdm, it has install/uninstall progress (more correctly, it's download progress in the install phase) | 13:46 |
| kyrofa | I think so, via polling yes? | 13:46 |
| beowulf | kyrofa: yes | 13:46 |
| beowulf | kyrofa: is polling not a option for a scope, or not a good option? | 13:47 |
| kyrofa | beowulf, sort of. It's a bit of a long-winded discussion, perhaps best saved for the HO :) | 13:49 |
| beowulf | kyrofa: np | 13:49 |
| kyrofa | beowulf, thanks for coming, it'll be a good conversation! I'm looking forward to hearing another "client"s view | 13:51 |
| beowulf | sergiusens: hey, i created a snap with no icon, sideloaded it, and the packages api has a value for the icon attribute (name + sideloaded + version) | 14:09 |
| beowulf | sergiusens: this means that the browser shows a broken image, rather than, if it were empty, a default image | 14:09 |
| Chipaca | pitti: you around perchance? | 14:10 |
| beowulf | sergiusens: i can look for a file extension in the client, but maybe this is something to fix in the api results? | 14:10 |
| pitti | hello Chipaca | 14:10 |
| Chipaca | pitti: hello hello! i've got systemd questions, i think | 14:10 |
| sergiusens | beowulf: I'll fix that, care to log a bug or task? | 14:11 |
| beowulf | sergiusens: happy to, any preference? | 14:11 |
| sergiusens | beowulf: non at all | 14:11 |
| Chipaca | pitti: I'm wanting to have a thing (unit?) that runs on boot that regenerates the service unit files (for frameworks and apps) | 14:11 |
| beowulf | sergiusens: bug it is | 14:12 |
| Chipaca | pitti: the code i have, with no extra work, will try to start the unit after creating the unit file | 14:12 |
| Chipaca | pitti: so I'm thinking that maybe there's a way to tell systemd not to try to start things itself, given i'll be doing so manually | 14:12 |
| beowulf | sergiusens: https://bugs.launchpad.net/webdm/+bug/1460085 | 14:13 |
| ubottu | Ubuntu bug 1460085 in webdm "snaps with no icon should not have a value for the icon attribute in the api" [Undecided,New] | 14:13 |
| pitti | Chipaca: "things" that synthesize unit files during boot from configuration are called "generators" | 14:13 |
| Chipaca | pitti: ok :) | 14:13 |
| Chipaca | pitti: i have generators! woo | 14:13 |
| * Chipaca feels all sophisticated now | 14:13 | |
| pitti | Chipaca: see http://www.freedesktop.org/wiki/Software/systemd/Generators/ ; we have a few, look at some shell ones how they work: /lib/systemd/system-generators/openvpn-generator | 14:13 |
| pitti | Chipaca: or the one from postgresql-common | 14:13 |
| * Chipaca reads systemd.generator | 14:14 | |
| pitti | Chipaca: essentially, they create units in /run/systemd/generator.. somewhere, which systemd will then pick up | 14:14 |
| pitti | Chipaca: they go well together with template units (but they don't necessarily have to use them) | 14:14 |
| Chipaca | hmmm | 14:14 |
| Chipaca | making snappy use these will take more work | 14:15 |
| pitti | Chipaca: yes, whether or not, or when/how to start units is entirely up to you | 14:15 |
| pitti | Chipaca: by default, a unit never gets started -- you have to make it a requires/wants of another unit; that's part of what the generator has to do | 14:15 |
| Chipaca | pitti: will systemd then keep it running if i manually start it? | 14:16 |
| pitti | Chipaca: sure | 14:16 |
| Chipaca | that is: | 14:16 |
| elopio | ping fgimenez: I've been playing with rewriting the tests in go, like http://paste.ubuntu.com/11433366/ | 14:16 |
| elopio | now I'm not sure if we should rewrite all of them, or leave them alone and work in tests with a controlled and deterministic environment. | 14:16 |
| elopio | like: instead of matching edge|stable, run the tests once for edge and once for stable. | 14:16 |
| pitti | Chipaca: it's nothing too magic -- it's just an unit which is in /run (thus doesn't survive a reboot), which happesn to be generated by a program called early at boot | 14:16 |
| elopio | what do you think? | 14:16 |
| Chipaca | pitti: ok | 14:17 |
| Chipaca | pitti: but i should leave the requires bits in place so if a user manually restarts a framework, apps will restart appropriately | 14:17 |
| pitti | Chipaca: ^ I don't understand what that has to do with generators? | 14:18 |
| Chipaca | pitti: I think I *don't* want generators | 14:19 |
| Chipaca | pitti: because if I use generators, unless i'm misunderstanding | 14:19 |
| pitti | Chipaca: restarting dependencies when you restart a unit is done with PartOf= | 14:19 |
| jdstrand | beuno: interesting: https://public.apps.ubuntu.com/download/com.ubuntu.snappy/docker/com.ubuntu.snappy.docker_1.5.0.002_all.snap - I thought all the old snaps were removed? | 14:19 |
| Chipaca | pitti: a daemon-reload regenerates them | 14:19 |
| pitti | Chipaca: correct | 14:19 |
| Chipaca | pitti: which would cause snappy to restart everything | 14:19 |
| jdstrand | beuno: https://public.apps.ubuntu.com/download/com.ubuntu.snappy/go-example-webserver/com.ubuntu.snappy.go-example-webserver_1.0.4_multi.snap too | 14:19 |
| pitti | Chipaca: err, no, why? | 14:19 |
| Chipaca | and then systemd will try to start them, and snappy will have started them | 14:20 |
| Chipaca | and everything will get in a fight | 14:20 |
| pitti | Chipaca: is snappy inotifying /run/systemd/generators/ or something such and restart stuff on file changes? | 14:20 |
| Chipaca | pitti: so, as I said perhaps too succinctly, i'd have to do more work to do this with generators | 14:20 |
| beuno | jdstrand, not removed, but filtered out because they don't have a release. I can remove them if needed | 14:20 |
| pitti | (that would be crazy -- don't do that!) | 14:20 |
| Chipaca | pitti: no! no, it's that | 14:20 |
| Chipaca | pitti: the generation of the unit files | 14:21 |
| Chipaca | pitti: is done by snappy | 14:21 |
| Chipaca | pitti: and the easy way to do them | 14:21 |
| Chipaca | pitti: is to just deactivate and then reactivate the snap | 14:21 |
| pitti | Chipaca: a generator should *never ever* start stuff by its own -- perhaps that's the confusion? | 14:21 |
| Chipaca | pitti: and that causes the services to be (re)started | 14:21 |
| Chipaca | pitti: i get that | 14:21 |
| jdstrand | beuno: I see. I don't think they have to be removed on my account (I am just fetching everything and can fix the script here), but it feels a little odd that they are in there | 14:21 |
| jdstrand | beuno: so, up to you :) | 14:22 |
| Chipaca | pitti: that's why i say, if i wanted to use generators i'd have to do more work | 14:22 |
| pitti | Chipaca: hm, the only "generated" unit files that I saw were in /etc/, i. e. the units which get build as a "transformation" of the yaml | 14:22 |
| fgimenez | elopio, i'd prefer to run the tests for each environment, with the state as controlled as possible and with concrete regex's | 14:22 |
| pitti | Chipaca: I still think we misunderstand each other in a major way | 14:22 |
| Chipaca | pitti: perhaps :) | 14:22 |
| Chipaca | pitti: let me start from the top | 14:22 |
| pitti | Chipaca: daemon-reload will not restart units | 14:22 |
| pitti | generators don't stop/start units | 14:22 |
| Chipaca | pitti: wait | 14:23 |
| Chipaca | pitti: let me start over | 14:23 |
| pitti | ack | 14:23 |
| Chipaca | pitti: snappy has this idea of "activating" and "deactivating" snaps | 14:23 |
| Chipaca | pitti: when it activates a snap, it creates a bunch of files, including the unit files | 14:23 |
| Chipaca | pitti: and then the services are started | 14:23 |
| Chipaca | pitti: this is done as part of an install, for example | 14:24 |
| pitti | ack; but that happens in /etc/systemd, right? | 14:24 |
| Chipaca | pitti: the old version is deactivated, the new version is activated | 14:24 |
| Chipaca | pitti: correct | 14:24 |
| Chipaca | pitti: that is as things are right now, and it works just fine | 14:24 |
| Chipaca | pitti: now | 14:24 |
| elopio | fgimenez: so, I propose to write one simple test that installs a package and confirms it works. 04_test_install_hello sounds like a good candidate for a controlled environment. | 14:24 |
| elopio | maybe we can have two versions, one that installs it from a snap we keep in our branch, and one that installs it from the store. | 14:24 |
| Chipaca | pitti: we're wanting to regenerate those unit files on boot (or on os update, which is essentially the same thing) | 14:24 |
| pitti | Chipaca: oh, that'd be a rather major difference design-wise | 14:25 |
| Chipaca | pitti: the *easiest* way to do that, is to grab a list of all "active" snaps | 14:25 |
| Chipaca | pitti: deactivate them | 14:25 |
| Chipaca | pitti: and then reactivate them | 14:25 |
| pitti | Chipaca: (I mentioned the possibility of building them at boot time in Austin, using a generator and /run -- that would avoid having to write into /etc/ entirely) | 14:25 |
| Chipaca | evereything would get generated, services started, all fine | 14:25 |
| pitti | Chipaca: but ok, let's follow along with the /etc/ approach for now | 14:25 |
| pitti | Chipaca: ok, understood | 14:26 |
| fgimenez | elopio, sounds great, the one that installs the local version could run in ci too, should we check for internet access at the first stages? | 14:27 |
| Chipaca | pitti: so, to make this work, i *think* all i've got to do is remove the bits that makes systemd start the services automatically | 14:27 |
| beowulf | ogra_: hi, i'm trying to debug a nodejs snap, where does log output go? | 14:28 |
| Chipaca | pitti: is that right? | 14:28 |
| ogra_ | beowulf, nowhere by default ... you can hack the start script and put some env var in place | 14:28 |
| * ogra_ checks the var name | 14:28 | |
| pitti | Chipaca: i. e. the "systemctl start" after you install a snap, generate the unit? :-) | 14:28 |
| pitti | Chipaca: sure; you can rewrite units in /etc/ all the time, that won't affect running ones | 14:28 |
| elopio | fgimenez: not sure how to handle that. For the experiments we did with the click store, we passed an environment variable, like: CLICK_STORE_URL=fake | 14:29 |
| elopio | it defaulted to being not set, which would use the real store. | 14:29 |
| Chipaca | pitti: no, i mean the requires or whatever it was in the unit files that causes them to be started on boot | 14:29 |
| pitti | Chipaca: if you want to do this rewriting at runtime | 14:29 |
| Chipaca | pitti: (because snappy would be starting them as part of the 'activate' dance) | 14:29 |
| elopio | fgimenez: maybe we can make it smarter. It will default to fake if there is no internet connection. But we should still be able to specify if we want to run the tests with or without the real store. | 14:29 |
| Chipaca | pitti: what does "at runtime" mean? | 14:29 |
| Chipaca | pitti: just to be clear :) | 14:30 |
| pitti | Chipaca: right; as I said, unit changes will only become active at boot in general; you can "force" the stopping/starting of new/old units with "systemd default", but that's a rare (and not widely known) operation | 14:30 |
| pitti | Chipaca: well, not at early boot time or image build time; i. e. "while the system is running" | 14:30 |
| Chipaca | pitti: not early boot; this would be a snappy command run from an ad-hoc systemd .. unit? target?, once "everything else" is up (ie, i want it to run more or less where ubuntu-snappy.frameworks-pre.target is today) | 14:31 |
| ogra_ | beowulf, i think it is just DEBUG=* ... or alternatively call node with the --debug option ... then logging should go to syslog | 14:31 |
| elopio | fgimenez: actually, we can start even more simple. We need a test to check that a snap can be installed from the .snap file. Lets write that, package it, put it to run on CI. And then we figure out how to solve the one from the store. | 14:32 |
| pitti | Chipaca: terminology: everything is a "unit", a target (or a service) is a particular type of unit | 14:32 |
| pitti | Chipaca: right | 14:32 |
| Chipaca | pitti: services stick around, targets come and go? | 14:32 |
| pitti | Chipaca: so if I got your question right: systemd by itself will not stop/start stuff automatically when you change unit files on disk; you have to manually do that | 14:32 |
| beowulf | ogra_: thanks, will try | 14:32 |
| Chipaca | pitti: but nothing breaks if i create unit files from a unit file | 14:33 |
| ogra_ | backjlack, ah, found it ... NODE_DEBUG=* | 14:33 |
| pitti | Chipaca: no; services start processes, targets are a kind of "meta-service" to provide synchronization points for services or group related services; but a target doesn't start processes by itself | 14:33 |
| ogra_ | http://www.juliengilli.com/2013/05/26/Using-Node.js-NODE_DEBUG-for-fun-and-profit/ | 14:33 |
| elopio | fgimenez: do you know about debian packaging for go? | 14:33 |
| pitti | Chipaca: in sysvinit terms: service == init.d script, target == runlevel | 14:33 |
| fgimenez | elopio, ok | 14:33 |
| Chipaca | pitti: gotcha | 14:33 |
| pitti | Chipaca: right; dynamically createing unit files from an unit file is unusual and brittle, but as long as you only expect them to become active at the next boot, it's all fine | 14:34 |
| pitti | Chipaca: brittle in the sense of "it might not do what you think it does" | 14:34 |
| Chipaca | i'll need to test it then :) | 14:35 |
| fgimenez | elopio, not used it before, i've seen that dh-golang manages it | 14:35 |
| Chipaca | pitti: the proper way in any case seems to be with generators | 14:35 |
| Chipaca | pitti: i'll try to move things around first, and then look at generators | 14:35 |
| Chipaca | otherwise it'll be two big changes in a single branch :) | 14:35 |
| pitti | Chipaca: right, don't mingle them | 14:36 |
| elopio | fgimenez: yes, seems simple. But I'm missing some details, like how to overwrite the build so the tests binary gets generated too. | 14:36 |
| elopio | we need to add go test -c somewhere in the rules. | 14:36 |
| pitti | Chipaca: from a behavioural POV at runtime systemd-generator units in /run and snappy-written units in /etc are pretty much identical | 14:36 |
| pitti | Chipaca: /etc is harder to upgrade, as you have to deal with possibly admin-modified files; i. e. whenever you change the YAML → unit translation, you have a lot of work | 14:37 |
| jdstrand | beuno: weird, check this out: http://paste.ubuntu.com/11433759/ | 14:37 |
| pitti | Chipaca: units in /run are nicer in the sense that you don't have to worry about upgrade issues, they are rebuilt at every boot and you don't need to have anything in /etc/ | 14:38 |
| jdstrand | beuno: the 'name' in the json is com.ubuntu.developer.zacharyigielman.piano, but the constructed download is com.ubuntu.developer.zacharyigielman.piano.upiano_2.0_all.click | 14:38 |
| pitti | Chipaca: but of course generators need to run at boot, and thus they slow down boot (if you do trivial operations it doesn't matter, but if you have to do expensive stuff it might) | 14:38 |
| jdstrand | beuno: (ie, 'upiano' is in the filename but not in the json) | 14:38 |
| pitti | Chipaca: i. e. what snappy does now to build an /etc/systemd/foo.service is by and large a generator and coudl also run at boot to output to /etc/ | 14:39 |
| fgimenez | elopio, yes, probably override_dh_auto_build will do | 14:39 |
| jdstrand | beuno: this is the only one I've seen like this | 14:39 |
| pitti | Chipaca: so it's a "boot speed" vs. "upgrade maintenance" tradeoff, not more, not less | 14:39 |
| beuno | jdstrand, interesting. nessita ^^^ | 14:39 |
| Chipaca | pitti: this work is exactly to regenerate unit files because we're changing them on upgrade | 14:39 |
| pitti | Chipaca: stopping/starting etc. is exactly theh same | 14:39 |
| Chipaca | pitti: so yeah, /run would be a better match | 14:39 |
| jdstrand | beuno: should I be pestering nessita with all this stuff? (I feel like I am being a bother) | 14:39 |
| beuno | jdstrand, you are not being a bother! | 14:39 |
| jdstrand | I don't want to bother nessita either though... | 14:40 |
| jdstrand | hehe | 14:40 |
| ogra_ | jdstrand, you are, but we pay you for that :P | 14:40 |
| jdstrand | haha | 14:40 |
| beuno | jdstrand, she's an expert botheree | 14:40 |
| jdstrand | ogra_: nice one :) | 14:40 |
| ogra_ | :) | 14:40 |
| beuno | jdstrand, file names don't mean anything to the system | 14:42 |
| beuno | so we might have played fast and loose during a data migration | 14:42 |
| nessita | reading backlog | 14:43 |
| jdstrand | beuno: yeah, it isn't a huge deal-- it is just the one. I do a cheap check in this store-fetch script to see if it is on disk and that one kept getting downloaded over and over again | 14:43 |
| jdstrand | just the one so far | 14:44 |
| beowulf | ogra_: just checking, i meant where would console.log stuff go; is it not logged in snappy without NODE_DEBUG? | 14:44 |
| ogra_ | node doesnt actually write anything to stdout by default | 14:45 |
| nessita | beuno, jdstrand we have 3 or 4 apps in sca that have an badly formatted package name, I reported these a while ago in the onlineservices list | 14:45 |
| ogra_ | so yeah, prefix your node call in your service start script with the var and you get its output in syslog | 14:45 |
| nessita | beuno, this is ont of them, the developer will not be able to upload a new version for the same package, he needs to upload a new package with a name without a dot in it | 14:46 |
| ogra_ | or if you manually run it (which you shouldnt, since the environment will differ) prefix your command line with it | 14:46 |
| beowulf | ogra_: but console.log is process.stdout.write, maybe i misunderstand | 14:47 |
| beowulf | ogra_: yeah, i couldn't run it manually without setting env vars | 14:47 |
| nessita | beuno, in summary somehow we allowed (no longer allowed) the upload of a package with a dot in the short name, which breaks all assumptions about the dot being namespace-short name splitter | 14:48 |
| beowulf | fwiw, it's confusing to get a perl error :) | 14:48 |
| beowulf | heartwarming, but confusing | 14:48 |
| jdstrand | beuno, nessita: fyi, I am not at all blocked. adjust the script: WARNING:store-fetch:Skipping 'com.ubuntu.developer.zacharyigielman.piano.upiano_2.0_all.click' (already present (v2)) | 14:49 |
| jdstrand | adjusted* | 14:49 |
| jdstrand | so I have a very cheap check and a less cheap check for existence | 14:50 |
| zyga | I have a conceptual snappy question, can I write (where I mean can I it means "should I, from snappy POV") a snap that gives you a test/benchmark tool and then another snap that knows how to use the first one _iff_ it is present? | 15:19 |
| zyga | or should that other snap be a framework that knows how to run tests? | 15:20 |
| zyga | and each test can still be a snap | 15:20 |
| zyga | or should I build a very fat snap that has everything I can think of | 15:20 |
| zyga | and about sandboxing | 15:20 |
| asac | zyga: snaps can talk to each other through REST right now | 15:21 |
| zyga | do I understand right that sandboxing is applied by ubuntu-core-launcher? | 15:21 |
| asac | but maybe just bundle everything together | 15:21 |
| asac | yes thats the launcher that puts the processes in the right realm | 15:21 |
| zyga | asac: can snaps see each other as installed in the FS? | 15:21 |
| asac | of compsec/cgroup/apparmor | 15:21 |
| ogra_ | yeah, i would just ship everything in one snap | 15:21 |
| asac | zyga: i think they cannot right now... | 15:21 |
| asac | but try :) | 15:21 |
| zyga | yeah, I'm about to | 15:21 |
| zyga | trying to wrap my head around this | 15:22 |
| zyga | I want to take three example tests (something for storage, stomething for network, something for cpu) | 15:22 |
| zyga | and bundle them with plainbox in a snap to run | 15:22 |
| asac | right. if those are plugins to y our benchmark tool just bundle them all in one | 15:22 |
| zyga | plainbox is mostly easy (apart from some .so files I currently bundle that I need to get from the archive) | 15:22 |
| asac | try deb2snap i would say if its from the archive | 15:23 |
| zyga | but all the tests are defined as thin wrappers (just metadata needed to run it) and a reference to a 3rd party tool which is typically just shipped straight from debian | 15:23 |
| ogra_ | you wont see much of the system though ... | 15:23 |
| zyga | yeah, I already use it | 15:23 |
| ogra_ | in your snap env | 15:23 |
| zyga | ogra_: can I get a shell somehow with all the constraints applied (for learning?) | 15:23 |
| asac | zyga: so hello-world.env is a script | 15:24 |
| zyga | asac: I played with that | 15:24 |
| asac | you could make a hello-world.bash maybe | 15:24 |
| zyga | asac: ah :D | 15:24 |
| zyga | good idea | 15:24 |
| zyga | thanks | 15:24 |
| asac | maybe could work | 15:24 |
| asac | guess a script that just starts bash or busybox-sh | 15:24 |
| asac | might be interesting to put in hello-world in general | 15:24 |
| ogra_ | that wont realyl ive you the info how it looks *inside* the snap i guess | 15:24 |
| zyga | asac: is python defined to be a part of the os snap for 15.04? | 15:24 |
| asac | ogra_: it should | 15:24 |
| ogra_ | sadly | 15:24 |
| zyga | ogra_: why not? should it not limit everything? | 15:24 |
| zyga | ogra_: for that process | 15:24 |
| asac | zyga: yes python is on the image | 15:24 |
| asac | it should work zyga ... give it a try | 15:25 |
| zyga | asac: +1 thanks for that! (we bundle python for .click but this saves a lot of effort) | 15:25 |
| zyga | yep, will do | 15:25 |
| ogra_ | asac, well, it will give you env output ... but if you try to read /proc/cpuinfo from commandline, will it actually block ? | 15:25 |
| ogra_ | (which it should if run as a service) | 15:25 |
| asac | yeah it will behave like it will behave for a normal snap app | 15:25 |
| asac | not sure if its block | 15:25 |
| ogra_ | ah, cool | 15:25 |
| asac | or just no permission | 15:25 |
| ogra_ | right, you cant read most of 7proc | 15:26 |
| ogra_ | */proc | 15:26 |
| asac | binaries should see the world like 99.99% same as a service | 15:26 |
| zyga | ogra_: is version important for local dev (do I need to increment it) or can I just keep changing and reinstalling without any changes to metadata | 15:26 |
| ogra_ | version is important fgor regenerating apparmor profiles | 15:26 |
| ogra_ | if your apparmor setup never changes you dont need to bump the version | 15:27 |
| zyga | ok, thanks | 15:27 |
| ogra_ | (i personally usually edit my snaps in /apps/<snap name>/current ... ) | 15:27 |
| ogra_ | way faster turnaround time than re-packing all the time ;) | 15:27 |
| zyga | ogra_: so just hack on the device? | 15:28 |
| ogra_ | thats what i do | 15:28 |
| zyga | yeah, works for non-compiled code, good point | 15:28 |
| asac | jdstrand: [ 2678.082648] audit: type=1326 audit(1432913282.515:15): auid=1000 uid=1000 gid=1000 ses=7 pid=1197 comm="sh" exe="/bin/dash" sig=31 arch=c000003e syscall=109 compat=0 ip=0x7fbc7b91bd47 code=0x0 | 15:28 |
| asac | i cannot run sh | 15:28 |
| ogra_ | once i'm done, i tar up the whole dir and dump it back into my snap dir on the PC | 15:28 |
| zyga | ogra_: do you have something for cross compilation? | 15:28 |
| ogra_ | (there are hidden subdirs you should remove before snapping it up then) | 15:28 |
| ogra_ | zyga, nope, not yet | 15:29 |
| ogra_ | i only did nodejs, shell and perl on snappy yet | 15:29 |
| zyga | ogra_: I love pex and it works great but one thing it does do is that it builds everything locally | 15:29 |
| zyga | ogra_: and that means .so files inside | 15:29 |
| ogra_ | yeah | 15:29 |
| zyga | ogra_: I'll focus on python and whatever-tests-need | 15:29 |
| ogra_ | you could look at node-snapper ... | 15:30 |
| zyga | yeah, I got bad-system-call | 15:30 |
| * zyga needs to read a bit about the security stuff | 15:30 | |
| ogra_ | it rolls a chroot, installs nodejs and then compiles the npm modules ... | 15:30 |
| asac | jdstrand: i cannot run busybox sh either | 15:30 |
| zyga | ogra_: oh, cute | 15:30 |
| ogra_ | zyga, on what host system ? | 15:30 |
| asac | jdstrand: also 106 | 15:30 |
| asac | oh its different :( | 15:30 |
| ogra_ | i see bad-system-call on utopic ... but not on trusty | 15:31 |
| asac | 109 and 106 | 15:31 |
| zyga | ogra_: I installed it to my snappy beagle | 15:31 |
| asac | not sure what the diff iss | 15:31 |
| zyga | ogra_: I did the /bin/bash snap | 15:31 |
| * asac tries to remember how to locally hack it to see what problems come next | 15:31 | |
| ogra_ | ah | 15:31 |
| asac | hmm how to find which syscall it is? | 15:31 |
| asac | tyhicks: what is 106 and 109? | 15:31 |
| jdstrand | asac: what is the output of 'sudo sc-logresolve /var/log/syslog' | 15:31 |
| asac | ahhh | 15:32 |
| asac | May 29 15:28:02 localhost kernel: [ 2678.082648] audit: type=1326 audit(1432913282.515:15): auid=1000 uid=1000 gid=1000 ses=7 pid=1197 comm="sh" exe="/bin/dash" sig=31 arch=c000003e syscall=109(setpgid) compat=0 ip=0x7fbc7b91bd47 code=0x0 | 15:32 |
| asac | May 29 15:30:25 localhost kernel: [ 2820.891522] audit: type=1326 audit(1432913425.322:16): auid=1000 uid=1000 gid=1000 ses=7 pid=1237 comm="busybox" exe="/apps/hello-world.sideload/1.0.16/bin/busybox" sig=31 arch=c000003e syscall=106(setgid) compat=0 ip=0x7f974f849c03 code=0x0 | 15:32 |
| jdstrand | scmp_sys_resolver 106 would also do it | 15:32 |
| asac | so setgid and setpgid | 15:32 |
| asac | is that not good? | 15:32 |
| zyga | ogra_: snapy could use a generic environment variable to detect snapy stuff is in effect, I love SNAP_xxx but something like XDG_$appropriate=snappy would be useful for libraries | 15:32 |
| asac | now setuid | 15:32 |
| jdstrand | we aren't allowing them because there is nothing for them to setgid to that we can control | 15:32 |
| asac | and now it works :) | 15:32 |
| asac | (amd64)ubuntu@localhost:~$ hello-world.shell | 15:33 |
| asac | BusyBox v1.22.1 (Ubuntu 1:1.22.0-9ubuntu1) built-in shell (ash) | 15:33 |
| asac | Enter 'help' for a list of built-in commands. | 15:33 |
| asac | $ | 15:33 |
| zyga | asac: how do you tweak policy ? | 15:33 |
| zyga | asac: I don't have experience with that | 15:33 |
| asac | zyga: soi just did it the hardway: | 15:33 |
| asac | sudo vi /var/lib/snappy/seccomp/profiles/hello-world.sideload_shell_1.0.16~ | 15:33 |
| asac | and then i added those names at the end | 15:33 |
| asac | e.g. setgid | 15:33 |
| asac | setpgid | 15:33 |
| asac | etc. | 15:33 |
| asac | until it worked | 15:33 |
| asac | but thats just for quick hacking | 15:33 |
| zyga | ahh | 15:33 |
| zyga | but that's generated, right? | 15:34 |
| asac | for each binary/service there should be such profile file | 15:34 |
| asac | yeah gets generated on install/update | 15:34 |
| asac | from templates etc. | 15:34 |
| jdstrand | zyga: you likely want to look at https://developer.ubuntu.com/en/snappy/guides/security-policy/ | 15:34 |
| ogra_ | this is why you need to bump the version if somethin there changed | 15:34 |
| zyga | jdstrand: I already have that open, I need to read/understand it | 15:35 |
| zyga | I know how seccomp works | 15:35 |
| jdstrand | ogra_: you don't need to do that for seccomp changes | 15:35 |
| zyga | but I'm green on apparmor | 15:35 |
| ogra_ | jdstrand, no, for apparmor | 15:35 |
| jdstrand | what are we talking aboug, seccomp or apparmor? | 15:35 |
| ogra_ | both ? | 15:35 |
| zyga | yeah, effective, I think | 15:35 |
| asac | for busybox sh | 15:36 |
| asac | it was just seccomp | 15:36 |
| jdstrand | zyga: that guide also links to https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement if you want to go deep | 15:36 |
| asac | zyga: to answer your question: | 15:37 |
| asac | $ ls /apps | 15:37 |
| asac | ls: can't open '/apps': Permission denied | 15:37 |
| asac | :P | 15:37 |
| asac | i love the hello-world shell | 15:37 |
| ogra_ | yeah | 15:37 |
| zyga | asac: thanks | 15:37 |
| asac | jdstrand: you say you dont like thhe idea to have setuid etc. in seccomp profile? | 15:37 |
| jdstrand | asac: so, regarding setuid and friends | 15:37 |
| asac | shouldn a process be able to setuid itself? | 15:38 |
| ogra_ | setuid has friends ? | 15:38 |
| asac | like start as root, daemonize | 15:38 |
| jdstrand | asac: what is it setuiding to? | 15:38 |
| asac | change to unpriviliged user? | 15:38 |
| jdstrand | daemonize to what? | 15:38 |
| jdstrand | right | 15:38 |
| jdstrand | so, 'yes' | 15:38 |
| zyga | jdstrand: so (haven't read anything yet) in one sentence, how does apparmor interact with seccomp? can it grant extra rights? (eg allow via seccomp but filter in apparmor?) | 15:38 |
| asac | jdstrand: http://paste.ubuntu.com/11434660/ | 15:38 |
| asac | jdstrand: i dont know what busybox sh does | 15:38 |
| jdstrand | but snappy doesn't create a user for the app to drop to | 15:38 |
| asac | seems something similar like bash does on start :) | 15:38 |
| mvo | jdstrand: can you help me debugging a apparmor issue? I have the following in dmesg http://paste.ubuntu.com/11434557/ for the ubuntu-core-launcher. but the /etc/apparmor.d/usr.bin.ubuntu-core-launcher has http://paste.ubuntu.com/11434609/ which should be ok, no? apparmor_parse -d -r /etc/apparmor.d/usr.bin..ubuntu-core-launcher also tells me its loaded | 15:38 |
| asac | jdstrand: try it ... let me give you the .snap | 15:39 |
| zyga | mvo: o/ | 15:39 |
| jdstrand | jeez too many parallel conversations | 15:39 |
| mvo | hey zyga | 15:39 |
| jdstrand | why am I so popular in this instant :) | 15:39 |
| asac | jdstrand: http://people.canonical.com/~asac/tmp/hello-world_1.0.16_all.snap | 15:39 |
| jdstrand | ok, one thing at a time | 15:39 |
| asac | jdstrand: it has a hello-world.shell | 15:39 |
| asac | that calls bash | 15:40 |
| jdstrand | asac: right, I get that | 15:40 |
| asac | or rather dash | 15:40 |
| asac | jdstrand: i dont know how to find out ... strace on my desktop maybe? | 15:40 |
| jdstrand | so the problem is that dash is setuid to something, but we don't know what. we could allow setuid in general but we didn't yet because apps don't know what to setuid to as it is | 15:41 |
| jdstrand | eg | 15:41 |
| jdstrand | apache on Ubuntu drops to www-data | 15:41 |
| asac | jdstrand: so seems dash only does setpgid | 15:41 |
| jdstrand | if apache were packaged as a snap, we would want to create a user for apache | 15:41 |
| asac | busybox also setuid | 15:41 |
| asac | jdstrand: setpgid(0, 25652) | 15:41 |
| jdstrand | that's fine. let me get to those in a moment | 15:41 |
| asac | getpgrp() = 25647 | 15:42 |
| jdstrand | I'm trying to describe the situation | 15:42 |
| asac | http://paste.ubuntu.com/11434743/ | 15:42 |
| jdstrand | there is a trello card for creating users | 15:42 |
| jdstrand | and there is a trello card to add seccomp arg filtering | 15:42 |
| jdstrand | in this manner, snappy would create the user and the generate policy that allows setuid/etc only to that user | 15:43 |
| zyga | asac: how can I follow high-level snappy developmet plans (like that thing with creating users for snappy packages) | 15:43 |
| jdstrand | but, since we don't have the user and the seccomp arg filtering and apps don't have a way to know what to go to, we disallow setuid and friends for now | 15:43 |
| jdstrand | ok, that is the situation | 15:43 |
| jdstrand | asac: what group is 25652? | 15:44 |
| asac | jdstrand: so busybox sh runus setgid and setuid to my user | 15:44 |
| asac | so just resets to my user | 15:44 |
| asac | not sure why | 15:44 |
| asac | setgid(1000) = 0 | 15:44 |
| asac | setuid(1000) = 0 | 15:44 |
| asac | thats me | 15:44 |
| jdstrand | right | 15:44 |
| jdstrand | that is odd | 15:44 |
| asac | let me look at the dash one | 15:44 |
| jdstrand | or maybe it isn't-- I don't know historically why an app would do that | 15:45 |
| jdstrand | sarnold, tyhicks: can you comment on the conversation from the last minute or two? | 15:45 |
| asac | jdstrand: the group it sets (25652) isnt one that i have | 15:45 |
| asac | in /etc/gropup etc. | 15:46 |
| asac | just something random it seems | 15:46 |
| jdstrand | right | 15:46 |
| asac | setpgid | 15:46 |
| asac | whats that? | 15:46 |
| tyhicks | jdstrand: the 25652 that is passed to setpgid() is not a group id - it is a pid | 15:46 |
| jdstrand | setpgid is for the process group | 15:46 |
| jdstrand | right | 15:46 |
| asac | oh | 15:46 |
| jdstrand | tyhicks: I'm thinking we are going to need to allow those since there is no way to arg filter it | 15:47 |
| asac | so then i dont know what setpgid does | 15:47 |
| asac | seems to take two pids as input | 15:47 |
| jdstrand | tyhicks: unless it is unsafe and the app needs to simply not do it (or we allow them to make an exception) | 15:47 |
| asac | maybe setpgid is safe? | 15:48 |
| asac | let me see if dash works with just that one | 15:48 |
| jdstrand | that is what we are thinking about | 15:48 |
| asac | yeah seems to be enough | 15:48 |
| asac | for dash | 15:48 |
| asac | busybox seems to do fun stuff | 15:48 |
| asac | i prefer busybox, but dash is fine to start i guess :P | 15:48 |
| asac | i dont see why setgid and setuid would be safe either though | 15:49 |
| jdstrand | tyhicks: I'm thinking setpgid and setpgrp we might allow | 15:49 |
| asac | think its standard unix practices to use those to drop privileges, no? | 15:49 |
| * zyga loves old system calls, with lots of magic values and special cases | 15:49 | |
| jdstrand | tyhicks: if they are safe | 15:49 |
| tyhicks | jdstrand: I'm thinking about those two atm | 15:49 |
| tyhicks | asac: regarding setuid/setgid, there is no defined user and/or group to drop privileges to | 15:51 |
| jdstrand | when the trello cards are implemented, we can do it. however, I don't think that will fix busybox | 15:52 |
| tyhicks | asac: we need to provide guidance to snappy developers about what users/groups they can use when they need to drop privileges | 15:52 |
| jdstrand | because busybox is changing to the current user (ie, 1000) and that won't be what is added to the policy | 15:52 |
| tyhicks | jdstrand: agreed | 15:52 |
| jdstrand | tyhicks: so, they could drop to something that already exists, like 'daemon' today | 15:53 |
| jdstrand | tyhicks: but that makes me uneasy | 15:53 |
| jdstrand | tyhicks: for the same reasons as the nobody user-- it doesn't actually mean 'totaly unprivileged' | 15:54 |
| jdstrand | also, if everyone drops to the same user, then the isolation isn't as great | 15:54 |
| tyhicks | that's my biggest issue with it | 15:54 |
| jdstrand | although, we have no DAC isolation now with root | 15:54 |
| jdstrand | so maybe it is a stepping stone | 15:55 |
| asac | jdstrand: so if i run the shell as root maybe it works? | 15:55 |
| asac | hmm. guess not | 15:55 |
| === om26er is now known as om26er|dinner | ||
| asac | so i am sure it setuid to something tht exists | 15:55 |
| asac | isnt a snappy root process allowed to just go to any uid? | 15:56 |
| asac | why wouldnt it? | 15:56 |
| tyhicks | jdstrand: should the launcher define env variables for the uid and gid that the process is allowed to drop to? | 15:56 |
| jdstrand | ie, today we create snappy-unprivileged uid/gid, then add seccomp arg filtering then we say you can change to 'snappy-unprivileged' or in the future the uid/gid we create for you | 15:56 |
| jdstrand | tyhicks: probably | 15:56 |
| tyhicks | by creating env variables, we can change those later on without the app caring | 15:56 |
| jdstrand | the uid/priv dropping/seccomp arg filtering needs to be prioritized and specced out | 15:56 |
| tyhicks | and we can also dynamically generate the appropriate seccomp filter from the launcher | 15:57 |
| jdstrand | asac: a snappy root process is not currently allowed to go to any uid, because we disallow setuid :) | 15:57 |
| asac | i know, but cant see why we would get so much into the way of standard unix procedure... like apache surely wants to do that etc. | 15:58 |
| jdstrand | asac: once snappy devs define how this is supposed to work, we can let apps do stuff in a controlled manner | 15:58 |
| asac | through setuid syscall? | 15:58 |
| jdstrand | asac: we don't want to be in the way of unix procedure, we want to allow this | 15:58 |
| jdstrand | it just isn't implemented yet | 15:58 |
| asac | hmmmmmmm | 15:59 |
| * Chipaca going AFK for a few hours. Let's call this EOW \o/ | 15:59 | |
| jdstrand | yes, through setuid syscall | 15:59 |
| asac | ah ok | 15:59 |
| jdstrand | there are trello cards for it | 15:59 |
| asac | i wouldnt like to see another function etc. | 15:59 |
| asac | we should just hook into the real thing and do the right thing | 15:59 |
| asac | ok call now | 15:59 |
| jdstrand | the thing is, today, apache isn't going to work right because there is no postinstall that creates the user it expects | 15:59 |
| asac | yes we need to spec out how to do per-app-users | 16:00 |
| jdstrand | (though, with apache we happen to have www-data predefined in /etc/passwd and /etc/group, but that is beside the point) | 16:00 |
| asac | yeah thats awful and we shouldnt rest because of that | 16:00 |
| jdstrand | no | 16:00 |
| jdstrand | asac: this sounds like something for our architect group to discuss and bring on board. I think it would be them, mvo, me and tyhicks at a minimum | 16:01 |
| jdstrand | for getting the design going | 16:01 |
| jdstrand | but maybe they are busy now | 16:02 |
| asac | sounds like something that fits into the developer experience epic | 16:03 |
| fgimenez | elopio, will you begin with the 04_test_install_hello changes? | 16:03 |
| zyga | asac: could I join some calls (just as an observer to track snappy development direction better?) | 16:03 |
| jdstrand | so the problem and need are all understood (hence trello), it is just the experience and implementation are not specced out | 16:03 |
| jdstrand | asac: oh, but there is a mechanism for allowing extra syscalls via 'security-override' | 16:04 |
| elopio | fgimenez: yes, I'm on that. I'll send you an email when I EOD with what I could finish. | 16:04 |
| fgimenez | elopio, ok thx | 16:05 |
| jdstrand | that said, we might just allow setpgid and setpgrp | 16:05 |
| jdstrand | tyhicks: let's not forget that ^ | 16:05 |
| mvo | fgimenez, elopio: do you already have a board or anything where you capture ideas? I would like to put "ensure services keep runing after a upgrade" on it :) (i.e. extend the current upgrade test to check that a intalled webserver is still listening) | 16:06 |
| tyhicks | jdstrand: apps could attempt to do devious things with setpgid()/setpgrp(), such as placing themselves in a process group of a different app | 16:06 |
| mvo | jdstrand: did you see my apparmor question from earlier? not rushing you, I noticed that you are busy, just wanted to ask if I should re-post the pastebins :) | 16:06 |
| jdstrand | mvo: oh sorry, I did, then was trying to deal with one conversation at a time | 16:06 |
| mvo | jdstrand: yeah, totaly fine, just ping me when you have a moment :) | 16:07 |
| tyhicks | jdstrand: that could result in some unexpected behavior such as waitpid(0, ...) returning when unexecpted processes exit | 16:07 |
| fgimenez | mvo, not yet afaik, it would be nice :) | 16:08 |
| tyhicks | jdstrand: that might be solveable by having the launcher call setsid(2) before exec'ing a snap executable but I'd have to look into it more (would be best if someone that works on init systems told us what we need to do) | 16:09 |
| jdstrand | mvo: the rules are ok. are you sure they are in effect? | 16:09 |
| jdstrand | mvo: ie, did you run 'sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher' ? | 16:10 |
| jdstrand | tyhicks: the init systems question kinda went by me-- perhaps ask slangasek? | 16:11 |
| mvo | jdstrand: I did, is there some sort of caching or anything? I can run apparmor_parser -r -d for you to double check | 16:12 |
| jdstrand | mvo: there is caching, but -r will ignore it | 16:12 |
| jdstrand | mvo: also, '-d' I don't think actually loads it into the kernel | 16:13 |
| mvo | jdstrand: http://paste.ubuntu.com/11435160 is the debug output from the loading | 16:13 |
| mvo | jdstrand: oh, hold on a sec, let me re-run without -d then | 16:14 |
| mvo | jdstrand: woah, see, I knew why I needed to talk to you, thanks! | 16:14 |
| jdstrand | ah, good! | 16:14 |
| jdstrand | I had to look at the man page for -d and saw it didn't load | 16:15 |
| mvo | jdstrand: how does the caching work? i.e. does it compare files? I have a image here from rick that seems to be broken | 16:15 |
| jdstrand | mvo: the launcher is a system profile, so its cache file is in /etc/apparmor.d/cache | 16:15 |
| mvo | jdstrand: i.e. the apparmor.d/usr.bin.ubuntu-core-launcher looks correct but when I ran it it seems to apply a older config ? I will debug further now that I know about -d | 16:16 |
| mvo | jdstrand: great, thanks a bunch. is there a way to "disassemble" the cache? as a way to compare that with the real file? | 16:16 |
| jdstrand | if you look at rick's image, do stat /etc/apparmor.d/cache/usr.bin.ubuntu-core-launcher /etc/apparmor.d/usr.bin.ubuntu-core-launcher | 16:16 |
| jdstrand | mvo: I don't think so, but will refer you to jjohansen here | 16:17 |
| mvo | jdstrand: thanks, thats very helpful, I dig deeper | 16:17 |
| jdstrand | mvo: so things to keep in mind: if the cache is older than the profile (mtime), then the apparmor boot script will regenerate the cache | 16:19 |
| jdstrand | mvo: apparmor_parser -r does not consult the cache. you can use apparmor_parser -r -B /etc/apparmor.d/cache/usr.bin.ubuntu-core-launcher to load the cache | 16:20 |
| mvo | jdstrand: thanks again | 16:22 |
| jdstrand | jjohansen: actually, does apparmor_parser -r /path/to/profile consult the cache? the man page suggests it but I never thought it did | 16:22 |
| jdstrand | mvo: so, you can use apparmor_parser -r -B /etc/apparmor.d/cache/usr.bin.ubuntu-core-launcher for sure to load the cache, and apparmor_parser -r --skip-cache /etc/apparmor.d/usr.bin.ubuntu-core-launcher to not load from cache for sure | 16:23 |
| mvo | jdstrand: its the cache | 16:24 |
| mvo | jdstrand: --skip-cache makes it work, -r alone is not enough | 16:24 |
| jdstrand | mvo: also something to keep in mind, system image generation tries to precompile the cache so it doesn' | 16:24 |
| jdstrand | t have to be done on first boot | 16:24 |
| mvo | jdstrand: let me try again from a freshly booted rick image just to be sure I'm not running into side-effects | 16:24 |
| jdstrand | at least on touch. I imagine we are doing the same on snappy (rsalveti could possibly confirm) | 16:24 |
| jdstrand | mvo: if the cache file on the disk is newer than the profile but still has the old profile rules, then suggests something is wrong in the image generation process | 16:25 |
| mvo | jdstrand: yes, that or something with the upgrade and the timestamps during the upgrade | 16:26 |
| jdstrand | yes | 16:26 |
| mvo | jdstrand: yep, fresh boot (qemu with --snapshot) pastebinit fails, apparmor_parser --skip-cache -r makes it work. I file a bug. thanks again for your help | 16:29 |
| jdstrand | mvo: ok, 'cool' | 16:30 |
| jdstrand | mvo: note this from touch: http://paste.ubuntu.com/11435517/ | 16:31 |
| mvo | jdstrand: heh :) | 16:31 |
| jdstrand | mvo: just for context on the types of things to be thinking about with timestamps and the cache | 16:31 |
| jdstrand | obviously, the launcher isn't a click | 16:31 |
| jdstrand | and the directories are different | 16:31 |
| jdstrand | but timestamps are pretty darn critical when dealing with cache files | 16:32 |
| mvo | jdstrand: oh absolutely | 16:33 |
| jdstrand | tyhicks: so, I'm conflicted on the setpgid/setpgrp. on the one hand, I totally hear what you're saying. on the other hand, it seems like something pretty common: http://paste.ubuntu.com/11435621/ | 16:38 |
| jdstrand | tyhicks: I'm leaning toward allowing it and then we file a bug to make it safer | 16:39 |
| jdstrand | tyhicks: I'm not sure how we can make it safer... there are LSM hooks for task_setpgid. but clearly, seccomp won't be enough | 16:40 |
| mvo | jjohansen: if you could give me a hint if its possible to get information out of a cache apparmor profile, that would be great! I suspect we have a bug in snappy (upgrade or image creation) when they get out of sync but to gather more data about the problem I need to figure out more about the content of the cached one | 16:42 |
| jdstrand | mvo: that is where you need jjohansen | 16:42 |
| mvo | yeah :) | 16:45 |
| mvo | rickspencer3: here is your bug https://bugs.launchpad.net/snappy/+bug/1460152 - I was wrong about the permissions, I was looking at the wrong place, its really a issue with upgrade or image generation and that results in a stale apparmor cache :/ | 16:46 |
| ubottu | Ubuntu bug 1460152 in Snappy "(sometimes?) becomes confused about apparmor rules for ubuntu-core-launcher" [Undecided,New] | 16:46 |
| tyhicks | jdstrand: they're probably harmless to allow | 16:48 |
| === om26er|dinner is now known as om26er | ||
| jdstrand | tyhicks: ok, then I'll allow them. if you feel more should be done with mediation, let's open a feature bug and add to backlog | 16:48 |
| jdstrand | tyhicks: sound ok? | 16:49 |
| tyhicks | jdstrand: ok - i'll think about if there's anything possible to do | 16:52 |
| jdstrand | great, thanks | 16:52 |
| jdstrand | I guess I should say 'great' | 16:53 |
| jdstrand | asac: ok, uploaded ubuntu-core-security to wily for setpgid/setpgrp, so it should hit rolling/edge later today. 15.04 will get this as part of the SRU | 17:02 |
| asac | jdstrand: ok, when will that hit? | 17:02 |
| asac | the SRU? any news on the updated image schedule from rsalveti ? | 17:03 |
| jdstrand | asac: not beyond what was discussed on wed. this is on the non-critical part currently | 17:03 |
| jdstrand | ie, the stable promotion won't block on this being missing (currently, we can change that) | 17:04 |
| zyga | jdstrand: how does ubuntu snappy core sru work? | 17:06 |
| jdstrand | zyga: the same as the normal SRU process will get the updates into edge. then there is a manual process currently being defined by the snappy core team (ie, rsalveti) for promotion from edge -> beta -> alpha -> stable | 17:08 |
| jdstrand | zyga: you might read this for background: https://developer.ubuntu.com/en/snappy/guides/channels/ | 17:08 |
| jdstrand | oh, I forgot 'rc' in my little ascii flow | 17:09 |
| * rsalveti reads backlog | 17:28 | |
| zyga | jdstrand: thanks, I ask because currently the cert team is involved in the sru process for normal ubuntu | 17:29 |
| zyga | jdstrand: and we're not (at least not yet) doing that for snappy | 17:29 |
| jdstrand | zyga: ah, you might also be interested in this bit I am working on for the security team: https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#system-image_updates_.28DRAFT.29 | 17:32 |
| sarnold | jdstrand: I think you got your answer, but we definitely need to allow setpgid, setpgrp, setsid, if we want shell job control to work | 17:32 |
| jdstrand | sarnold: ack. we already allowed setsid and the other two I just fixed | 17:33 |
| jdstrand | sarnold: thanks! :) | 17:33 |
| sarnold | jdstrand: woot :) | 17:33 |
| === davmor2 is now known as davmor2_hols | ||
| rsalveti | mvo: jdstrand: apparmor cache is actually done as part of livecd-rootfs | 17:44 |
| rsalveti | not in system-image, so let me check if we're actually running a similar script in there | 17:45 |
| rsalveti | I remember we had super weird issues on touch when the rules were bind-mounted from the device tarball | 17:46 |
| rsalveti | as that wasn't causing the cache to be regenerated (even when the timestamp was correct) | 17:47 |
| rsalveti | which is why we now have a package in the archive with the device rules | 17:47 |
| rsalveti | jdstrand: mvo: how we're pre-compiling the cache on touch http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/90-precompile-apparmor-policies.chroot | 17:52 |
| ogra_ | rsalveti, mvo, oh, i meant to ask about this, a big chunk of the hook scripts in the livecd-rootfs tree in core are not executable ... | 17:53 |
| * ogra_ was wondering if that is on purpose to not have them run | 17:54 | |
| rsalveti | ogra_: remember we also have our own version in our ppa | 17:54 |
| rsalveti | https://launchpad.net/~snappy-dev/+archive/ubuntu/image | 17:54 |
| ogra_ | of livecd-rootfs ? | 17:54 |
| rsalveti | yeah | 17:55 |
| ogra_ | how does that work ? | 17:55 |
| rsalveti | this ppa gets used when building the image | 17:55 |
| ogra_ | the buildd doesnt know the PPA when it install that package | 17:55 |
| ogra_ | *installs | 17:55 |
| ogra_ | only later once it created the build chroot ... or did that change | 17:55 |
| rsalveti | asac: jdstrand: right, can you let me know about the bug number for it once you start the SRU process? | 17:56 |
| rsalveti | asac: jdstrand: my goal is to have our first stable update during next week | 17:56 |
| ogra_ | also that feels pretty wrong ... we already have our own hooks dir, why do we need anything else forked from the main livecd-rootfs | 17:56 |
| rsalveti | created a short meeting on monday to make sure we're not missing anything | 17:56 |
| rsalveti | ogra_: mvo should know more | 17:57 |
| ogra_ | k | 17:57 |
| rsalveti | one reason could be because of the freeze | 17:57 |
| ogra_ | ah ... didnt think of that | 17:57 |
| mvo | rsalveti: hm, indeed aparmor.d/cache is a rw mount, I wonder why we have that, I assumed it would all be done on image generation time | 17:58 |
| sergiusens | ogra_: because of system-image (we didn't package fork in time) | 17:58 |
| mvo | ogra_: this sounds like a accident, are they really not run? | 17:59 |
| rsalveti | mvo: right, on touch we create it as part of the image, then we copy it over at a rw path and bind-mount during boot time | 17:59 |
| ogra_ | mvo, i'm not sure, they all have a hashbang though | 17:59 |
| rsalveti | we don't yet support pre-cached content during updates | 17:59 |
| mvo | ok | 17:59 |
| ogra_ | i dont think they are piped into some shell call in live-build, but i might be wrong | 17:59 |
| rsalveti | log should tell | 18:00 |
| rsalveti | build log | 18:00 |
| rsalveti | guess only if printing stuff though | 18:00 |
| ogra_ | yeah, most dont print anythin | 18:00 |
| ogra_ | g | 18:01 |
| mvo | I can reproduce the tempdir issue via stable->edge 15.04 update :/ | 18:02 |
| ogra_ | damn | 18:03 |
| asac | nice | 18:04 |
| asac | mvo: well done | 18:04 |
| asac | its one of those things that is dangerous i tell you | 18:04 |
| rsalveti | yeah | 18:05 |
| rsalveti | if the right apparmor cache is not in place, we can make the device useless | 18:05 |
| * asac super worried | 18:05 | |
| ogra_ | rsalveti, mvo all fine, seems they get executed even without executable bit set | 18:05 |
| asac | that we dont have the upgrade under control fully | 18:05 |
| * ogra_ sees + echo I: Remove unneeded files from /usr/share/doc | 18:05 | |
| ogra_ | I: Remove unneeded files from /usr/share/doc | 18:05 |
| ogra_ | which is non executable in the code | 18:06 |
| elopio | mvo: we are using your document of better tests in the etherpad. | 18:06 |
| ogra_ | asac, we have a similar issue on the phone with /var/log ownership that nobody can explain | 18:08 |
| ogra_ | (being flipped after some upgrades ... not reliably reproducable ... ) | 18:08 |
| rsalveti | at least mvo found a way to reproduce it | 18:08 |
| rsalveti | it seems :-) | 18:08 |
| ogra_ | i wonder if we face some core bug in system-image | 18:08 |
| === devil is now known as Guest16350 | ||
| jdstrand | rsalveti: I'm only putting this out there as an option that you are free to ignore-- there are only 3 system profiles on core. pregenerated them doesn't buy us much on first boot-- about 2.2 seconds on bbb | 18:12 |
| jdstrand | rsalveti: maybe on upgrade hook could simply rm -f /etc/apparmor.d/cache/* | 18:12 |
| rsalveti | yeah, that sounds easy enough | 18:12 |
| ogra_ | wont that result in long boots ? | 18:13 |
| rsalveti | just the first boot after install/upgrade | 18:13 |
| rsalveti | but as it's just 3 system profiles | 18:13 |
| rsalveti | not tons of click packages | 18:13 |
| ogra_ | ah, not apps ... k | 18:13 |
| jdstrand | ogra_: 13:12 < jdstrand> rsalveti: I'm only putting this out there as an option that you are free to ignore-- there are only 3 system profiles on core. pregenerated them doesn't buy us much on first boot-- about 2.2 seconds on bbb | 18:13 |
| jdstrand | right | 18:13 |
| rsalveti | mvo: ^^ | 18:13 |
| ogra_ | 2sec are bearable :) | 18:13 |
| jdstrand | and it is only on boot after upgrade | 18:14 |
| ogra_ | yeah | 18:14 |
| jdstrand | the first boot after upgrade | 18:14 |
| jdstrand | rsalveti: could the a/b partitioning be getting in the way? | 18:14 |
| jdstrand | rsalveti: ie, are the writable bind mounted areas a/b'd as well? | 18:14 |
| rsalveti | that's an interesting question | 18:15 |
| * ogra_ thought not | 18:15 | |
| ogra_ | we only have one writable and a and b | 18:15 |
| jdstrand | rsalveti: eg, if a has old cache and old profile and we reboot into b with new profile, do we get a's old cache file? | 18:15 |
| rsalveti | yeah, are we sharing the same writable path for the cache? | 18:15 |
| rsalveti | if so, then, hmm | 18:15 |
| jdstrand | idk | 18:15 |
| ogra_ | most likely | 18:15 |
| rsalveti | not good | 18:16 |
| ogra_ | since we only have one writable partition | 18:16 |
| rsalveti | ogra_: can you confirm? | 18:16 |
| ogra_ | yeah, i think i can | 18:16 |
| ogra_ | three partitions ... two readonly, one writable ... | 18:17 |
| ogra_ | writable gets mounted in initrd by label, no matter what readonly part is active | 18:18 |
| ogra_ | and /etc/apparmor.d/cache is in /etc/system-image/writable-paths | 18:19 |
| ogra_ | i guess we would want an a/b scheme there | 18:20 |
| ogra_ | in a subdir or some such | 18:20 |
| ogra_ | or via a bind mount that hides the real path | 18:20 |
| jdstrand | ok, so I'm much more convinced that for now, we rm -f /etc/apparmor.d/cache/* | 18:21 |
| jdstrand | cause the alternative would be too risky for sru | 18:21 |
| jdstrand | we need to implement the alternative for touch anyway | 18:22 |
| jdstrand | s/touch/personal/ | 18:22 |
| beowulf | sergiusens: are you waiting for something from me wrt my 2 reviews? i suspect you are but i've forgotten | 18:22 |
| ogra_ | jdstrand, +1 | 18:22 |
| sergiusens | beowulf: I was debugging something, let me grab those MPs now | 18:22 |
| beowulf | sergiusens: sorry, there's no rush, just checking | 18:24 |
| rsalveti | ogra_: jdstrand: yeah, let's just do this | 18:24 |
| rsalveti | sharing same writable path can be indeed dangerous | 18:24 |
| rsalveti | it's usually desirable | 18:24 |
| rsalveti | but we need to be careful | 18:24 |
| ogra_ | yep | 18:24 |
| ogra_ | sounds like quite some research project to find out which other files are bound to the readonly version | 18:25 |
| ogra_ | s/are/should be/ | 18:26 |
| rsalveti | yup, will create a task/story for that in our board, so we don't forget | 18:26 |
| rsalveti | actually, will just add as part of the 15.04.1 one | 18:26 |
| rsalveti | since if there are additional bugs, we need to fix for the next release | 18:27 |
| jdstrand | so, thinking about it-- a's cache timestamp should be older than b's profile in the normal case. but, if the cache somehow got invalidated/regenerated it is possible for it to be newer than what would be in 'b' | 18:27 |
| rsalveti | what is the reference used by fixrtc? | 18:27 |
| ogra_ | last mount time | 18:28 |
| rsalveti | right, but which mount partition? | 18:28 |
| ogra_ | you added another one with a recent patch | 18:28 |
| ogra_ | oh, good question | 18:28 |
| ogra_ | hmm | 18:29 |
| ogra_ | root= or systempart= is what it accepts | 18:29 |
| rsalveti | right | 18:29 |
| === Guest16350 is now known as devil_ | ||
| ogra_ | so root in our case | 18:30 |
| ogra_ | BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=LABEL=system-a ro init=/lib/systemd/systemd console=tty1 console=ttyS0 panic=-1 | 18:30 |
| ogra_ | that is what i see on my kvm image here | 18:30 |
| rsalveti | so in theory it would still be correct | 18:31 |
| ogra_ | ah, and you added "creation date" as fallback | 18:31 |
| rsalveti | unless we have a fallback I guess | 18:31 |
| ogra_ | in case it was never mounted | 18:31 |
| rsalveti | right | 18:31 |
| rsalveti | fallback/rollback | 18:31 |
| ogra_ | well | 18:31 |
| rsalveti | so if you flash b, boot b, regenerate the cache, and then aborts, it will boot a again | 18:31 |
| rsalveti | but the cache will be invalid | 18:31 |
| rsalveti | from the a perspective | 18:31 |
| rsalveti | or better, could be | 18:31 |
| ogra_ | i was just thinking about the clock .... if you switch from a to b but b was never mounted you might go backwards in time | 18:32 |
| rsalveti | so yeah, sharing rw for apparmor is a bad idea | 18:32 |
| rsalveti | ogra_: yup :-) | 18:32 |
| ogra_ | (with fixrtc) | 18:32 |
| ogra_ | oh | 18:32 |
| ogra_ | but you mount b to flash it :) | 18:32 |
| ogra_ | all fine then i guess | 18:32 |
| rsalveti | that's the hope | 18:33 |
| ogra_ | even under the clock thats set for a ... so they shouldnt diverge to much | 18:33 |
| rsalveti | right | 18:33 |
| jdstrand | so, /var/cache/apparmor (the one for apps) is setup the same way | 18:36 |
| rsalveti | alright, updated the bug | 18:36 |
| jdstrand | but, for now I think it will handle things ok | 18:37 |
| jdstrand | well, let me think | 18:37 |
| jdstrand | actually, the mechanism it uses for deciding whether to regenerate the profiles is not taking a/b into account | 18:38 |
| jdstrand | the mechanism it currently uses happens to really be poor and I wouldn't mind it being redone | 18:39 |
| jdstrand | but I was going to replicate the mechanism for the seccomp policy regeneration work that I will be starting soon | 18:40 |
| ogra_ | OOOH ! | 18:41 |
| * ogra_ just hit ctrl-r in webdm | 18:41 | |
| ogra_ | shiny ! | 18:41 |
| rsalveti | :-) | 18:41 |
| rsalveti | sergiusens just uploaded a new version it seems | 18:41 |
| jdstrand | alright, I'll think about it-- I may have questions/ask for help in designing the implementation | 18:41 |
| rsalveti | jdstrand: sounds good | 18:41 |
| sergiusens | rsalveti: ogra_ yes, but the core problem I mentioned isn't solved, but I could easily replicate with 0.6.1 | 18:42 |
| * sergiusens needs to read the core launcher code | 18:42 | |
| rsalveti | sergiusens: why not? | 18:42 |
| sergiusens | rsalveti: it's not a webdm afaik | 18:43 |
| rsalveti | oh, right, isn't this the apparmor issue we're just discussing? | 18:43 |
| rsalveti | https://bugs.launchpad.net/snappy/+bug/1460152 | 18:44 |
| ubottu | Ubuntu bug 1460152 in Snappy 15.04 "(sometimes?) becomes confused about apparmor rules for ubuntu-core-launcher" [Undecided,New] | 18:44 |
| * rsalveti still trying to understand the issues we currently have | 18:44 | |
| sergiusens | rsalveti: I don't see denials; I think it's more of running in namespaces | 18:46 |
| rsalveti | hm, ok | 18:46 |
| sergiusens | rsalveti: I don't get any apparmor denials nor seccomp issues, but the runtime thinks it's on some soft float hw env | 18:47 |
| sergiusens | jdstrand: do you have a bbb, maybe it will pop up easy to you :-) | 18:47 |
| rsalveti | hm, weird | 18:47 |
| ogra_ | snake !! | 18:47 |
| rsalveti | is this only happening on bbb? | 18:48 |
| ogra_ | (in the snap store) | 18:48 |
| rsalveti | hahaha | 18:48 |
| mvo | snake?woah! | 18:48 |
| sergiusens | rsalveti: well !amd64 | 18:48 |
| * mvo needsmorespaces | 18:48 | |
| ogra_ | heh | 18:48 |
| jdstrand | sergiusens: I just installed webdm on my bbb | 18:50 |
| jdstrand | I am rebooting it | 18:50 |
| jdstrand | give me a second to figure out what channel I am on, etc | 18:50 |
| sergiusens | jdstrand: right, so my issue is, with the core launcher, webdm fails in weird ways, running from cli works just fine | 18:50 |
| jdstrand | ubuntu-core/15.04/edge | 18:51 |
| jdstrand | r60 | 18:51 |
| jdstrand | sergiusens: does that have what is needed to reproduce? | 18:51 |
| sergiusens | jdstrand: http://paste.ubuntu.com/11434444/ the last three lines is what I see with no denials whatsoever; just try and install a package | 18:52 |
| sergiusens | I also logged a but about the core launcher taking ver arg[0] | 18:52 |
| ogra_ | uuuh | 18:52 |
| jdstrand | runtime: this CPU has no floating point hardware, so it cannot run | 18:53 |
| jdstrand | this GOARM=6 binary. Recompile using GOARM=5. | 18:53 |
| jdstrand | what is that?? | 18:53 |
| sergiusens | jdstrand: yeah, that only happens when running under the launcher | 18:53 |
| sergiusens | jdstrand: 6, 5 are armv[5,6,7] | 18:53 |
| ogra_ | i guess it nneeds some info from /proc ? | 18:54 |
| jdstrand | is this armhf vs armel? | 18:54 |
| sergiusens | ogra_: right, there are no denials that I see of that make this obvious | 18:54 |
| jdstrand | let me look at the profile | 18:54 |
| sergiusens | jdstrand: https://code.google.com/p/go-wiki/wiki/GoArm | 18:55 |
| mvo | ok, I think the problem with the apparmor is understood now, I updated the description of the bugreport in https://bugs.launchpad.net/snappy/+bug/146015 - I wonder if apparmor_parser could simply set the mtime of the cached file to the mtime of the source that was used to generate the cache, that would make this kind of issue go away | 18:56 |
| ubottu | Ubuntu bug 146015 in Moblin Kernel "NTFS module can't be inserted" [High,Won't fix] | 18:56 |
| rsalveti | maybe GOARM=5 is the default? | 18:56 |
| mvo | eh https://bugs.launchpad.net/snappy/+bug/1460152 | 18:56 |
| ubottu | Ubuntu bug 1460152 in Snappy 15.04 "(sometimes?) becomes confused about apparmor rules for ubuntu-core-launcher" [Undecided,New] | 18:56 |
| jdstrand | sergiusens: http://paste.ubuntu.com/11437590/ | 18:57 |
| sergiusens | jdstrand: are you using u-d-f from beta? | 18:57 |
| jdstrand | sergiusens: I mintioned I am on ubuntu-core/15.04/edge r60 | 18:58 |
| jdstrand | mentioned | 18:58 |
| jdstrand | I just ssh'd in then ran that command | 18:58 |
| ogra_ | sergiusens, hmm, whats the reason we build with GOARM=6 instead of 7 ? | 18:59 |
| sergiusens | jdstrand: yeah, I need to know what u-d-f you used, I bet you have /oem/beagleblack.canonical instead of /oem/beagleblack | 18:59 |
| sergiusens | ogra_: it's using 7 | 18:59 |
| sergiusens | ogra_: the message is completely bogus | 18:59 |
| jdstrand | I have /oem/beagleblack.canonical | 18:59 |
| ogra_ | it says 6 above | 18:59 |
| ogra_ | ah | 18:59 |
| jdstrand | I don't know what udf I used-- I generated the image weeks ago | 19:00 |
| rsalveti | ogra_: I believe it's kind of what you said | 19:00 |
| rsalveti | it needs to query the system for the right support | 19:00 |
| ogra_ | yeah | 19:00 |
| rsalveti | and that might be br0k3n | 19:00 |
| ogra_ | i forgot where exactly that info lives | 19:00 |
| rsalveti | i think it's /proc/cpuinfo | 19:00 |
| rsalveti | isn't i? | 19:00 |
| ogra_ | something with /proc.../axfr | 19:00 |
| rsalveti | right | 19:00 |
| ogra_ | or some such | 19:00 |
| ogra_ | it was some letter combo | 19:01 |
| rsalveti | might be easy to just check go's code | 19:01 |
| sergiusens | jdstrand: so quick hack to get going-> mkdir bak; sudo mv /oem/beagleblack.canonical bak | 19:01 |
| sergiusens | jdstrand: and restart webdm; are you using a prerelease image by any chance? | 19:01 |
| * ogra_ thought it would be easy by just using the right google search terms :P ... but i'm not lucky | 19:01 | |
| jdstrand | sergiusens: prerelease image-- what do you mean? I am on ubuntu-core/15.04/edge r60, just booted into it | 19:03 |
| rsalveti | 206 else ifeq ($(DEB_HOST_ARCH), armhf) | 19:03 |
| rsalveti | 207 GOARM := 6 | 19:03 |
| rsalveti | we're actually building with goarm 6 | 19:03 |
| jdstrand | sergiusens: moving to bak and doing 'sudo systemctl start webdm_snappyd_0.7.service', it started | 19:03 |
| jdstrand | $ ps auxww|grep webdm | 19:04 |
| jdstrand | root 862 1.6 1.4 838992 7120 ? Ssl 19:03 0:00 /apps/webdm/0.7/bin/arm-linux-gnueabihf/snappyd | 19:04 |
| sergiusens | jdstrand: great, there's a bad strain somewhere and I need to find it, you are the second person today that has a bad image | 19:04 |
| jdstrand | I can connect to port 4200 | 19:04 |
| rsalveti | it checks via syscall it seems | 19:05 |
| rsalveti | so it could be seccomp | 19:05 |
| jdstrand | sergiusens: I can say that even though I just rebooted, I am getting told I need to reboot again | 19:05 |
| jdstrand | rsalveti: what syscall? | 19:05 |
| rsalveti | http://paste.ubuntu.com/11437793/ | 19:05 |
| jdstrand | also, we would see a seccomp denial | 19:06 |
| rsalveti | http://paste.ubuntu.com/11437796/ | 19:06 |
| rsalveti | the code the checks for the right arm support | 19:06 |
| sergiusens | there is no seccomp denial though | 19:07 |
| sergiusens | but, it also only fails when running under it | 19:07 |
| jdstrand | seccomp only supports EABI iirc | 19:07 |
| jdstrand | sergiusens: it isn't failing here now | 19:07 |
| sergiusens | jdstrand: you can install from the ui with no failure? | 19:08 |
| rsalveti | // do an EABI syscall | 19:08 |
| rsalveti | MOVW$20, R7 // sys_getpid | 19:08 |
| rsalveti | yeah, that's the eabi syscall it does | 19:09 |
| sergiusens | rsalveti: right, we are using GOARM=7 fwiw | 19:09 |
| jdstrand | I think it is a nice touch that Chipaca's 8nzc1x4iim2xj1g2ul64 is at the top of the list | 19:09 |
| rsalveti | sergiusens: debian/rules is only exporting GOARM=6 | 19:09 |
| sergiusens | rsalveti: and it works without confinement applied | 19:09 |
| sergiusens | rsalveti: webdm is not a deb | 19:09 |
| rsalveti | right, was checking for golang-go itself | 19:10 |
| ogra_ | trapped :P | 19:10 |
| rsalveti | not sure how that would be connected to that | 19:10 |
| jdstrand | sergiusens: no: http://paste.ubuntu.com/11437836/ | 19:10 |
| rsalveti | when building another project that uses go | 19:10 |
| sergiusens | jdstrand: yeah, same error... | 19:10 |
| jdstrand | I still have the old libseccomp2... 2.1.1-1ubuntu1~ppa1 | 19:11 |
| sergiusens | jdstrand: if you stop webdm and go to /apps/webdm/0.7 and run it manually it all works fine | 19:11 |
| jdstrand | sergiusens: what version of libseccomp2 do you have? | 19:11 |
| sergiusens | libseccomp2:armhf | 19:11 |
| sergiusens | same | 19:12 |
| jdstrand | why is this image telling me to reboot and not rebooting into the updated system? | 19:12 |
| sergiusens | jdstrand: snappy list --updates | 19:12 |
| sergiusens | jdstrand: cat /boot/uboot/snappy-system.txt | pastebinit.* | 19:12 |
| mvo | thanks sergiusens | 19:13 |
| jdstrand | sergiusens: right, but autopilot is setting shutdown | 19:13 |
| sergiusens | mvo: I can't know for sure for what! :-) | 19:13 |
| mvo | sergiusens: I'm sure you know plenty of good reasons | 19:13 |
| mvo | sergiusens: but mostly for debugging why its showing that it needs to reboot when it does not | 19:14 |
| mvo | I thought we had this fixed *loooong* ago :/ | 19:14 |
| jdstrand | sergiusens: http://paste.ubuntu.com/11437898/ | 19:14 |
| jdstrand | I'm doing snappy update manually now | 19:14 |
| sergiusens | mvo: me too, but I suspect jdstrand is on some weird image ;-) | 19:14 |
| mvo | we also need uEnv.txt I think | 19:14 |
| sergiusens | mvo: boot logic is all in snappy-system.txt, uEnv.txt is just for enablement | 19:15 |
| mvo | silly me, indeed | 19:15 |
| sergiusens | jdstrand: what about snappy list --updates ? | 19:15 |
| jdstrand | sergiusens: it said I needed to update to 69 | 19:17 |
| jdstrand | I guess I need to reflash it | 19:17 |
| jdstrand | sergiusens: manually upgrading libseccomp didn't help | 19:18 |
| jdstrand | sergiusens: so, webdm isn't running under seccomp: | 19:19 |
| jdstrand | $ cat /var/lib/snappy/seccomp/profiles/webdm_snappyd_0.7 | 19:19 |
| jdstrand | @unrestricted | 19:19 |
| nothal | jdstrand: No such command! | 19:19 |
| ogra_ | lol | 19:19 |
| jdstrand | or at least, it shouldn't be | 19:19 |
| sergiusens | jdstrand: right, so could it be a kernel namespace issue? I'm just throwing out ideas, this isn't my domain at all | 19:21 |
| rsalveti | how could the hwcaps be wrong | 19:21 |
| ogra_ | they arent wrong, you just cant access them | 19:22 |
| rsalveti | right, I mean, wrong from go's perspective | 19:22 |
| sergiusens | rsalveti: ogra_ they aren't wrong as this works fine when launched without the core launcher | 19:23 |
| ogra_ | yeah, i think seccomp just blocks the syscall | 19:23 |
| rsalveti | sure, it's what ogra said, it probably just can't access it | 19:23 |
| jdstrand | sergiusens: we aren't using namespaces to any significant degree yet-- there is the new launcher work that adds the bit for /tmp | 19:23 |
| sergiusens | ogra_: as jdstrand reminded me, it is @unrestricted | 19:24 |
| jdstrand | but that shouldn't be on my image | 19:24 |
| ogra_ | hmm | 19:24 |
| jdstrand | seccomp would kill the process and log a denial if it was it. however, there is no denial and it is @unrestricted | 19:24 |
| ogra_ | and does @unrestricted also actually mean unrestricted ? ... unconfined on the phone doesnt necessarily mean completely unrestricted | 19:24 |
| jdstrand | sergiusens: fyi, I tried adding "GOARM=7" to the service file manually and it didn't make a different | 19:25 |
| jdstrand | difference | 19:25 |
| jdstrand | let me try something else | 19:25 |
| sergiusens | jdstrand: that's a compile time thing | 19:25 |
| sergiusens | jdstrand: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/build.sh#L37 | 19:26 |
| jdstrand | sergiusens: ok, I took the launcher out of it by using: http://paste.ubuntu.com/11438058/ | 19:27 |
| jdstrand | now, I will take AppArmor out of it | 19:27 |
| rsalveti | it finds the hwcaps by using the elf auxiliary vectors | 19:28 |
| rsalveti | http://articles.manugarg.com/aboutelfauxiliaryvectors.html | 19:28 |
| ogra_ | ah | 19:29 |
| ogra_ | it was /proc/$pid/auxv | 19:29 |
| rsalveti | it can still use that | 19:29 |
| rsalveti | http://ffmpeg.org/doxygen/trunk/arm_2cpu_8c_source.html | 19:29 |
| rsalveti | like ffmpeg | 19:29 |
| rsalveti | but you can also just use the elf auxiliary vectors | 19:29 |
| rsalveti | https://wiki.linaro.org/Resources/HowTo/DeterminingCPUFeatures | 19:30 |
| rsalveti | explains it nicely | 19:30 |
| jdstrand | ok, if I use this, it worked: http://paste.ubuntu.com/11438101/ | 19:30 |
| jdstrand | let me try one more thing | 19:30 |
| sergiusens | jdstrand: so no apparmor and no core launcher work | 19:31 |
| sergiusens | jdstrand: leaving apparmor and using your ExecStart also works fine | 19:32 |
| jdstrand | sergiusens: I'm ruling out the launcher now | 19:32 |
| sergiusens | but I guess core launcher attaches the apparmor profile | 19:32 |
| jdstrand | it does | 19:32 |
| jdstrand | I am using some hackery to test with unconfned | 19:32 |
| jdstrand | I can say that there are no explicit deny rules in the webdm profile | 19:33 |
| jdstrand | if this comes done to kernel rate limiting I am going to strangle someone | 19:33 |
| rsalveti | LD_SHOW_AUXV=1 exports the hwcap | 19:33 |
| * jdstrand shakes fist at kernel rate limiting | 19:33 | |
| rsalveti | is there a way to export that when running it and get the output? | 19:33 |
| sergiusens | heh, right, forgot about the rate limiting issues when we started on the phone | 19:33 |
| sergiusens | rsalveti: yeh, in the systemd unit | 19:34 |
| * sergiusens tries | 19:34 | |
| ogra_ | in the environment of the systemd unit | 19:34 |
| jdstrand | sergiusens: fyi, sergiusens unsurprisingly, this worked too: http://paste.ubuntu.com/11438162/ (after I created /var/lib/snappy/seccomp/profiles/unconfined) | 19:36 |
| sergiusens | jdstrand: so unconfined seccomp and no apparmor works fine with the core launcher | 19:38 |
| jdstrand | sergiusens: yes, the launcher is ruled out | 19:43 |
| sergiusens | rsalveti: btw AT_HWCAP: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 | 19:53 |
| sergiusens | rsalveti: this env var breaks the magic bin thing though ;-) | 19:53 |
| rsalveti | sergiusens: yeah, that's correct | 19:55 |
| rsalveti | it's looking for vfpv3 | 19:55 |
| rsalveti | and vfp | 19:55 |
| rsalveti | now why the hell go is not able to find that from the elf auxiliary vectors | 19:56 |
| sergiusens | rsalveti: it is | 19:56 |
| sergiusens | rsalveti: as I said, when running without our confinement it works fine (seccomp/u-c-l/apparmor) | 19:56 |
| sergiusens | although u-c-l and seccomp have been discarded as the problem | 19:57 |
| jdstrand | ok, so I disabled rate limiting | 19:57 |
| jdstrand | sudo sysctl -w kernel.printk_ratelimit=0 | 19:57 |
| sergiusens | ah, that's how it was done! | 19:57 |
| sergiusens | jdstrand: I don't see any denials here still | 19:58 |
| * sergiusens imagine I used proper grammar | 19:59 | |
| sergiusens | meh | 19:59 |
| sergiusens | friday | 19:59 |
| Zwan | Hi | 20:10 |
| Zwan | this seems like a good place to get some info about Snappy. | 20:11 |
| Zwan | Don't worry, I'm not seeking tech support. | 20:11 |
| Zwan | Is Snappy something that's going to completely replace apt-get in future releases or is it just going to be part of a sideproject thing? | 20:12 |
| sergiusens | Zwan: ubuntu core will use snappy to drive it's package management as one of the things it does | 20:12 |
| sergiusens | jdstrand: do you think something in the profile itself it wrong and the parser just let's it through? | 20:13 |
| Zwan | Ah, okay. So average Ubuntu desktop people won't have to worry about losing apt-get... | 20:13 |
| Zwan | Whew. | 20:13 |
| jdstrand | ok, I ruled out systemd | 20:17 |
| jdstrand | sergiusens: unlikely. the parser would bail if it couldn't compile it | 20:17 |
| jdstrand | there could be a parser bug, but let me keep trying some things | 20:17 |
| jdstrand | I found the issue | 20:21 |
| jdstrand | sergiusens: ^ | 20:21 |
| jdstrand | # snappy unpack | 20:21 |
| jdstrand | # /usr/bin/snappy Uxr, | 20:21 |
| jdstrand | /usr/bin/snappy uxr, | 20:21 |
| sergiusens | oh man | 20:22 |
| sergiusens | s/u/U/ | 20:22 |
| sergiusens | jdstrand: right? | 20:22 |
| * sergiusens does a bzr log/blame to figure out when this changed | 20:23 | |
| jdstrand | sergiusens: see man apparmor.d 'ux - Unconfined execute mode' | 20:23 |
| jdstrand | something is getting scrubbed out that snappy needs | 20:24 |
| jdstrand | and ux prevents that from happening | 20:24 |
| sergiusens | jdstrand: hmm, I wonder how this workds on kvm though | 20:24 |
| sergiusens | as in amd64 | 20:24 |
| rsalveti | well, no cpu type check | 20:25 |
| sergiusens | right | 20:25 |
| rsalveti | it wouldn't cause any issue there | 20:25 |
| sergiusens | right as well | 20:25 |
| rsalveti | love typos | 20:25 |
| jdstrand | jjohansen may be able to comment, but the secure exec stuff is used (the same as for setuid binaries) and perhaps there is a difference on arm and amd64 kernels | 20:26 |
| rsalveti | but that was done on purpose I guess | 20:26 |
| sergiusens | rsalveti: it was U on purpose though | 20:26 |
| jjohansen | jdstrand: that will only get logged if debug is enabled, basically you will get a dmesg that the environment is being scrubbed on exec | 20:26 |
| jdstrand | oh, interesting | 20:26 |
| jdstrand | let me try that | 20:26 |
| jdstrand | I hadn't gotten to setting debug=1 yet | 20:26 |
| jjohansen | so secure exec clears out a whole bunch of dangerous environment stuff, that ld uses and can be used to exploit the system | 20:27 |
| rsalveti | right | 20:27 |
| jjohansen | not having those cleared is a BIG red flag | 20:27 |
| rsalveti | that might effect the elf auxiliary vectors? | 20:27 |
| jjohansen | yes | 20:27 |
| jdstrand | it is interesting that this is a go, static executable | 20:27 |
| rsalveti | there you go then | 20:27 |
| jjohansen | rsalveti: apparmor is not in control of what gets cleared, it just sets the flag and then the loader associated with the application actually does the env scrubbing, so normally its a glibc thing but it could be something else depending on the executable | 20:29 |
| jjohansen | jdstrand: even static executables have their startup loader stuff that is linked in | 20:29 |
| rsalveti | right | 20:29 |
| rsalveti | glad we know what is the problem now | 20:30 |
| jdstrand | so, with debug=1, I'm not seeing what is scrubbed, just that stuff is scrubbed | 20:30 |
| jdstrand | May 29 20:29:59 localhost kernel: [ 6004.539676] AppArmor: scrubbing environment variables for /bin/mountpoint profile=unconfined | 20:30 |
| jdstrand | we do know the problem and the shorterm fix | 20:30 |
| rsalveti | great | 20:30 |
| rsalveti | ship it | 20:30 |
| sergiusens | jdstrand: I guess I see it on arm and not amd64 as the binary is cross compiled for arm and locally (arch) compiled for amd64 | 20:30 |
| jdstrand | but I wonder if this is going to bite us again down the line for normal or framework apps | 20:31 |
| jdstrand | granted, we use ix for apps | 20:31 |
| rsalveti | sergiusens: shouldn't make a difference | 20:31 |
| jdstrand | and Ux is a big red flag too | 20:31 |
| rsalveti | it's just that amd64 is not checking for the same thing | 20:31 |
| jdstrand | so we wouldn't normally allow that | 20:31 |
| jdstrand | I can see frameworks (and even webdm) using Cx though | 20:32 |
| sergiusens | jdstrand: this is legacy to what we did in capetown in december though | 20:32 |
| sergiusens | jdstrand: any alternative? I don't mind doing the right thing now | 20:32 |
| jdstrand | sergiusens: I'm not sure what you mean by legacy. webdm is fork/execing /usr/bin/snappy | 20:33 |
| sergiusens | jdstrand: legacy as this profile piece was written when we were in capetown | 20:33 |
| jjohansen | jdstrand: Ux, Cx, Px are the "safe" environment scrubbing variants, its ux, cx, px that don't scrub the env | 20:33 |
| jdstrand | sure, I get that | 20:33 |
| jdstrand | but it is still applicable :) | 20:33 |
| jdstrand | jjohansen: yes | 20:33 |
| jjohansen | so it looks the opposite this is failing because something isn't getting scrubbed out | 20:34 |
| sergiusens | jdstrand: in any case once we move to the rest api being on snappy itself, we only need to worry about connecting to a unix socket | 20:34 |
| jjohansen | (01:21:45 PM) jdstrand: # /usr/bin/snappy Uxr, | 20:34 |
| jjohansen | (01:21:45 PM) jdstrand: /usr/bin/snappy uxr, | 20:34 |
| jdstrand | jjohansen: hmmm? Ux didn't work, ux did | 20:34 |
| jjohansen | that was the change causing the problem? correct? | 20:34 |
| jdstrand | jjohansen: no, that was the 'solution' | 20:34 |
| jjohansen | oh that was the fix, sorry misinterpretted and got very confused | 20:34 |
| jdstrand | sergiusens: when is that api coming? | 20:35 |
| sergiusens | jdstrand: this cycle | 20:35 |
| jdstrand | sergiusens: alright, well let's just let the ux ride then. we can revisit proper confinement at that time | 20:36 |
| sergiusens | jdstrand: I was supposed to be working on that today fwiw | 20:36 |
| jdstrand | I was supposed to be working on things today too :P | 20:36 |
| jdstrand | ah well :) | 20:36 |
| sergiusens | jdstrand: many of these issues will go away; maybe you can easy prof a reserved "device_management" stanza ;) | 20:37 |
| jdstrand | I thought we did that :) | 20:37 |
| jdstrand | hardware assign ftw | 20:37 |
| jdstrand | anyhoo, yeah, always more to think about | 20:37 |
| sergiusens | jdstrand: heh; was thinking more a layer above "device" as in the product/box | 20:38 |
| sergiusens | jdstrand: anyways, thanks, testing now | 20:38 |
| jdstrand | sergiusens: fyi, you should probably try to get seccomp as restricted | 20:41 |
| jdstrand | though, it would need som significant tuning | 20:42 |
| sergiusens | jdstrand: sure, any pointers on how to get started on that side | 20:42 |
| jdstrand | sergiusens: copy the syscalls from hello-world.env from /var/lib/snappy/seccomp/profiles and start there | 20:43 |
| sergiusens | jdstrand: ok, and iterate with sc-log.* ? | 20:43 |
| jdstrand | sergiusens: yes | 20:43 |
| sergiusens | jdstrand: got it; I'll get to it just for the excercise of getting familiar with this | 20:44 |
| sergiusens | I suspect again that moving to this rest api will move most of it away | 20:44 |
| jdstrand | cool | 20:44 |
| jdstrand | sergiusens: what is the design for the rest api? right now I see that the web interface is confined by this profile, and this profile allows a whole-lotta privilege. eg, if an attacker could take control of webdm, he could install a malicious snap with no confinement that provides a remote shell | 20:46 |
| jdstrand | (via side loading) | 20:46 |
| jdstrand | sergiusens: perhaps this is something that you would want to spec out with the security team and architects team? | 20:47 |
| sergiusens | jdstrand: the rest api would look a lot like lxd's but yeah, I have to get the proposal and send out for review | 20:47 |
| sergiusens | jdstrand: I bet you guys will be an integral part of it | 20:47 |
| jdstrand | it might be that there isn't a terribly whole lot we can do here since this is a management interface that is designed to, well, manage. but perhaps we can have some security in depth here | 20:48 |
| jdstrand | sergiusens: ok, cool | 20:48 |
| sergiusens | jdstrand: this is where the macaroons come into place, I think lool has the high level architecture in his head already and waiting for some minion like me to do a brain dump for him :-) | 20:50 |
| jdstrand | ah | 20:50 |
| lool | haha | 20:50 |
| jdstrand | tyhicks, mdeslaur (and jjohansen): we should be looking out for this ^ (see backscroll for 7 minutes) | 20:51 |
| tyhicks | jdstrand: ack | 20:52 |
| lool | (so every time I read minions, of course I try to think of despicable me, but I can't stop thinking about Mignons which was means "cuties" but were also the "favorites" of the prince) | 20:53 |
| lool | (the king would allow them to dress as nicely as him, wear facial powder etc., and at some point it gained an homosexual connotation) | 20:53 |
| jjohansen | jdstrand: ack | 20:53 |
| lool | jdstrand: so my understanding is that secure channel is laptop -> my.ubuntu.com + snappy device -> my.ubuntu.com; either we then do direct connection to snappy device with a cookie with limited powers, or we go over my.u.c to do everything or a mixture of both | 20:56 |
| * sergiusens doesn't want to spread facial powder over his face | 20:56 | |
| lool | but TBH, while I find macaroons and this bootstrap of the security story exciting, I suspect folks in Online Services are better clued at these topics | 20:57 |
| sergiusens | rsalveti: mind taking action? https://code.launchpad.net/~sergiusens/webdm/profileUnconfinedNoScrubSnappy/+merge/260625 | 20:57 |
| lool | sergiusens: you can be my mignon de couchette | 20:58 |
| lool | you would be allowed to sleep in the same room as me | 20:58 |
| lool | http://fr.wikipedia.org/wiki/Mignon_%28histoire%29 for the full story -- yes, this is an actual expression | 20:58 |
| sergiusens | lool: lol | 20:59 |
| * lool now expects an email from HR | 20:59 | |
| sergiusens | lool: lol at that again! | 20:59 |
| sergiusens | jdstrand: or maybe you can https://code.launchpad.net/~sergiusens/webdm/profileUnconfinedNoScrubSnappy/+merge/260625 stamp this? | 21:03 |
| jdstrand | sure | 21:08 |
| rsalveti | sergiusens: jdstrand did already it seems | 21:32 |
| rsalveti | was walking the dog | 21:32 |
| Chipaca | sergiusens: any progress with the mystery of the mysterious disappearing floating point? | 21:51 |
| rsalveti | Chipaca: https://code.launchpad.net/~sergiusens/webdm/profileUnconfinedNoScrubSnappy/+merge/260625 | 22:37 |
| rsalveti | that made go not being able to find out the hwcaps via elf auxiliary vectors | 22:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!