| === FourDollars_ is now known as FourDollars | ||
| === marcoceppi_ is now known as marcoceppi | ||
| === rsalveti_ is now known as rsalveti | ||
| === Ursinha__ is now known as Ursinha_ | ||
| === plars-holiday is now known as plars | ||
| === cprov_ is now known as cprov | ||
| === mariogrip_ is now known as mariogrip | ||
| === mariogrip_ is now known as mariogrip | ||
| === rsalveti_ is now known as rsalveti | ||
| dholbach | good morning | 08:35 |
|---|---|---|
| === john-mca` is now known as john-mcaleely | ||
| === davmor2_ is now known as davmor2 | ||
| === Guest74213 is now known as pixel_ | ||
| === mariogrip_ is now known as mariogrip | ||
| ogra_ | mvo, Chipaca, do you guys know if we expose the package version somewhere in the environment of snap services/binaries (i.e. how would my app know it has just been upgraded) | 10:20 |
| ogra_ | i think we need some mechanism to make the package know when it needs to run any confi migration scripts | 10:21 |
| ogra_ | *config | 10:22 |
| mvo | ogra_: it should be available via SNAP_VERSION | 10:22 |
| ogra_ | ah, thanks ! | 10:22 |
| mvo | ogra_: hm, there was discussion about providing a native hook for this from snappy itself | 10:22 |
| JamesTait | Good morning all; happy Monday, and happy Computer Security Day! 😃 | 10:23 |
| ogra_ | yeah, that would be cool ... but for the moment i can use that var ... (just updating a stamp file and compare on service start) | 10:23 |
| ogra_ | geez, "snappy build" is amazingly slow o armhf :/ | 10:27 |
| ogra_ | *on | 10:27 |
| ogra_ | 11min for a package that takes 2min to build on amd64 | 10:27 |
| longsleep | Is /writable/cache somehow used on boot again? I see some service duplication and the only location where the old service file exits is in /writable/cache/system | 10:30 |
| ogra_ | it should be readonly mounted after boot ... but nothing else | 10:32 |
| ogra_ | /writable/cache/system that is | 10:32 |
| longsleep | ogra_: yes it is mounted ro there, but something seems to copy all the files in there on boot | 10:33 |
| longsleep | ogra_: could that be? | 10:33 |
| ogra_ | i dont think so | 10:33 |
| ogra_ | it is your "other" readonly partition | 10:33 |
| longsleep | right - this is very strange | 10:34 |
| longsleep | i delete a file from /etc/systemd/service and disable the service with systemctl as well, reboot then it is there again | 10:34 |
| ogra_ | probably some generator ? | 10:34 |
| ogra_ | though even that should respect that you disabled it | 10:35 |
| longsleep | the service comes from a snap - snap is still installed as newer version | 10:35 |
| longsleep | the version the service gets generated for is not on the disk - at least i cannot find it | 10:35 |
| longsleep | i see the issue for more than one snap though. It seems like when a builtin snap is updated, the systemd service of the version which is oem is recreated on boot for unknown reason | 10:36 |
| ogra_ | that sounds definitely like a bug | 10:37 |
| longsleep | ogra_: yeah, though i was unable to figure out how that even happens yet | 10:37 |
| longsleep | so, before reboot the service was only in /writable/cache/system/etc/systemd/system, after reboot it is in /etc/systemd/system - so something must copy it | 10:41 |
| ogra_ | longsleep, i guess the issue is that it is in /writable/cache/system/etc/systemd/system at all ... | 10:43 |
| ogra_ | thats a readonly system ... no snap should be able to put anything there ever | 10:43 |
| longsleep | ogra_: true, but those are put there by u-d-f i think | 10:43 |
| longsleep | ogra_: the snaps are preinstalled with the oem snap | 10:44 |
| ogra_ | hmm, sounds wrong to me to put them in the readonly partition | 10:44 |
| longsleep | yeah, they will never go away | 10:45 |
| longsleep | i would be fine with that, but how are they cloned on boot? | 10:45 |
| longsleep | i mean that causes the problem after all | 10:45 |
| longsleep | ogra_: i think it is synced in the initrd | 10:49 |
| ogra_ | longsleep, i wouldnt see how | 10:51 |
| longsleep | ogra_: well, there is some code in the ubuntu-core-rootfs of the initrd which does some copying | 10:51 |
| ogra_ | yes | 10:51 |
| longsleep | ogra_: maybe i use ancient version again | 10:51 |
| ogra_ | one sec | 10:51 |
| ogra_ | bah, i was hoping for a wrong setting in /etc/system-image/writable-paths ... but seems the cache path is actually hardcoded | 10:52 |
| ogra_ | hmm, k ... | 10:53 |
| ogra_ | the initrd doesnt mount it at all | 10:53 |
| ogra_ | if [ -n "$other" ]; then | 10:54 |
| ogra_ | echo "$other /writable/cache/system auto defaults,ro 0 0" >> "$fstab" | 10:54 |
| ogra_ | fi | 10:54 |
| longsleep | right | 10:54 |
| ogra_ | thats all it does ... right before run-init | 10:54 |
| ogra_ | so if there is any syncing thats not happening in the initrd | 10:54 |
| longsleep | maybe it runs into one of the other conditions which do cp -A | 10:54 |
| longsleep | i mean the file ending up in /etc/systemd/system has the same timestamp as the one in /writable/cache/system/etc/systemd/system | 10:55 |
| ogra_ | well, there must be some systemd unit that copies it | 10:56 |
| ogra_ | when processing fstab | 10:56 |
| longsleep | ok let me check if i can find something there | 10:56 |
| === vrruiz_ is now known as rvr | ||
| === chihchun is now known as chihchun_afk | ||
| longsleep | ogra_: well, i could not find it and now i even removed the file from /writable/cache/system/ and it still gets recreated magically in /etc/systemd/system | 11:33 |
| * longsleep has no idea where it comes from | 11:33 | |
| fgimenez | hi Chipaca, have a minute? | 11:39 |
| dholbach | mvo, can you (or somebody else) help with https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218? | 11:55 |
| === verterok` is now known as verterok | ||
| ogra_ | Nov 30 13:44:32 aleph2 systemd[1]: Starting minidlna DLNA server... | 12:46 |
| ogra_ | Nov 30 13:44:32 aleph2 ubuntu-core-launcher[26252]: /apps/upnp-server-amd64.sideload/IGccOWeCMeET/minidlnad: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /apps/upnp-server-amd64.sideload/IGccOWeCMeET/usr/lib/x86_64-linux-gnu/libsnappy.so.1) | 12:46 |
| ogra_ | Nov 30 13:44:32 aleph2 systemd[1]: Reloading. | 12:46 |
| ogra_ | woah | 12:46 |
| Chipaca | jdstrand_: tyhicks: ping about snapd and ACLs | 12:46 |
| Chipaca | well, not ACLs, but permissions on the unix socket and SO_PEERCRED | 12:48 |
| === pixel__ is now known as pi||aw | ||
| mvo | dholbach: I have a look after the meeting, thanks | 12:59 |
| === bigcat_ is now known as bigcat | ||
| longsleep | Chipaca: Hey, maybe you can help me in finding the script which creates snappy systemd services in /etc/systemd/system/ on boot. I have the problem that a service keeps appearing there while that snap version is not installed | 13:00 |
| mvo | longsleep: do you install something that has a service duing your u-d-f run? | 13:01 |
| longsleep | mvo: yes | 13:01 |
| longsleep | mvo: the oem snap has several snaps as built-in | 13:02 |
| mvo | longsleep: I think there is a bug in u-d-f | 13:02 |
| longsleep | mvo: when updating those, the old systemd service gets not removed and recreated on boot | 13:02 |
| longsleep | mvo: yeah that makes sense, though where does u-d-f store the information so the service can actually be recreated | 13:02 |
| dholbach | mvo, cool, thanks | 13:07 |
| ogra_ | jdstrand_, is the chwon blocking really necessary given we cant actually chown anything outside of the writable area of the snap anyway ? i have massive probs with it atm trying to package something that uses two services which both call fchown/fchown32 | 13:21 |
| tyhicks | Chipaca: hey - I need some more context as I don't know if I've heard anything about that yet | 14:39 |
| Chipaca | tyhicks: you probably haven't :) | 14:40 |
| Chipaca | tyhicks: you remember snapd, the snappy daemon that runs as root, that you connect to over a unix socket? | 14:40 |
| tyhicks | Chipaca: yep | 14:40 |
| Chipaca | tyhicks: that socket is 0600 root:root right now | 14:40 |
| Chipaca | tyhicks: wanting to relax that so regular users can connect | 14:41 |
| Chipaca | tyhicks: so, server uses SO_PEERCREDS on the socket to determine uid, deny access to privileged ops to non-privileged users | 14:41 |
| tyhicks | ok | 14:41 |
| Chipaca | tyhicks: would like you or jamie to go over what/how we're doing that before actually lowering the 0600 | 14:42 |
| tyhicks | Chipaca: is there a MP? | 14:42 |
| Chipaca | tyhicks: the code that does SO_PEERCRED is already in master | 14:43 |
| Chipaca | tyhicks: 1 sec and i'll point you at the relevant file itself | 14:43 |
| Chipaca | tyhicks: https://github.com/ubuntu-core/snappy/blob/master/daemon/ucrednet.go | 14:44 |
| tyhicks | Chipaca: ack, I should be able to have a look in a day or two | 14:44 |
| Chipaca | tyhicks: that's the wrapper that knows about SO_PEERCRED and uses it to get the uid for unix connections | 14:44 |
| tyhicks | (maybe today) | 14:44 |
| Chipaca | tyhicks: and then https://github.com/ubuntu-core/snappy/blob/master/daemon/daemon.go#L67 checks things before allowing access | 14:45 |
| tyhicks | ok | 14:46 |
| Chipaca | tyhicks: it's a rather hackish first pass that stuffs the uid in the RemoteAddr of the transfer, but modulo that it seems sane to me | 14:46 |
| Chipaca | transport* | 14:47 |
| Chipaca | tyhicks: yeh, no hurry | 14:47 |
| Chipaca | well, no hurry beyond the usual :-) | 14:47 |
| rickspencer3 | mvo, can you please give me a link to the correct rolling image for rpi2 if I want to install and test 16.04 rolling? | 15:38 |
| * rickspencer3 notes the web site still points (correctly, I think) to 15.04 | 15:38 | |
| mvo | rickspencer3: we don't have a pre-build xenial image right now (unless ogra_ did some for rpi2). you can use ubuntu-device-flash to build an image. maybe it would be a good idea to make a snapshot available for easier testing | 15:39 |
| rickspencer3 | ack | 15:40 |
| === Ursinha_ is now known as Ursinha | ||
| longsleep | so, what other tool on a snappy system can create systemd services for snaps? I still have not found the reason why old services keep appearing on boot. They are not generated by /usr/bin/snappy :/ | 15:57 |
| Chipaca | longsleep: what are the files that won't die? | 16:00 |
| ogra_ | mvo, no, i didnt, i would like us to eventually produce whole images for xenial in an automated way though | 16:00 |
| ogra_ | s/for xenial// | 16:01 |
| longsleep | Chipaca: i have snaps with services installed via oem built-in - when those get updated everything seems fine. But on reboot the service files reappear in /etc/systemd/system/ | 16:01 |
| longsleep | Chipaca: i have looked and looked but seem unable to find out how these files are generated / where they come from :/ | 16:02 |
| Chipaca | longsleep: you mean you have a snap that you include from oem, that in an update removes a service? or is it services for old versions that appear? | 16:03 |
| longsleep | Chipaca: spreedbox-led_ledd_0.0.9-4.service is the new service, spreedbox-led_gnatsd_0.0.6-1.service the old. spreedbox-led_gnatsd_0.0.6-1.service is removed after update. Then reboot and spreedbox-led_gnatsd_0.0.6-1.service is there again | 16:04 |
| longsleep | Chipaca: it is the same problem for all services installed via oem | 16:05 |
| longsleep | Chipaca: on update, the old service gets removed fine. Then reboot and it is back (and fails to start) | 16:05 |
| longsleep | Chipaca: what troubles me is that i seem to be unable to figure out where it comes from | 16:05 |
| === balloons_ is now known as balloons | ||
| Chipaca | longsleep: could i see the output of 'sudo journalctl' on a reboot with these things happening? | 16:06 |
| Chipaca | longsleep: firstboot is the thing that might be doing that, but it shouldn't be running | 16:06 |
| longsleep | Chipaca: sure | 16:07 |
| Chipaca | and ... yeah, it doesn't make sense | 16:07 |
| longsleep | Chipaca: it says started firstboot setup every time | 16:09 |
| longsleep | let me check when i remove the firstboot stamp and run it manually | 16:10 |
| longsleep | Chipaca: no, removing the stamp and running snappy firstboot did not create the service file again | 16:11 |
| Chipaca | phew | 16:11 |
| longsleep | Chipaca: i have a patched version of snappy, which adds a custom X- header to the service file when snappy generates it, for the file which keeps reappearing it does not have that header | 16:12 |
| * Chipaca looks up phone numbers of exorcists | 16:12 | |
| longsleep | Chipaca: it is either copied from some place or created from some other tool | 16:12 |
| Chipaca | longsleep: ooh, nice | 16:12 |
| Chipaca | ogra_: pingu | 16:12 |
| ogra_ | yo yo | 16:12 |
| Chipaca | ogra_: is there anything in initrd/early boot that could be copying a service file? | 16:13 |
| ogra_ | no | 16:13 |
| ogra_ | hmm | 16:13 |
| ogra_ | well | 16:13 |
| longsleep | It also needs to copy it from some place, i have removed all locations below /writable where that file could be found | 16:13 |
| * ogra_ checks something | 16:13 | |
| Chipaca | longsleep: can you mount and see if it's in /etc *under* writable? | 16:14 |
| === jdstrand_ is now known as jdstrand | ||
| longsleep | Chipaca: mount what exactly? | 16:14 |
| Chipaca | longsleep: umm... system-a? partition #3 iirc | 16:14 |
| Chipaca | longsleep: on a brand new image | 16:15 |
| longsleep | Chipaca: sure - hold on | 16:15 |
| Chipaca | longsleep: (or on a booted one, really) | 16:15 |
| longsleep | Chipaca: brand new booted one - without upgrading? | 16:15 |
| Chipaca | longsleep: yep | 16:15 |
| longsleep | Chipaca: flashing now, takes 70 seconds | 16:16 |
| Chipaca | longsleep: ok. just mounting the image locally would also work :-) | 16:16 |
| longsleep | Chipaca: that would not be booted though | 16:16 |
| Chipaca | ah, sorry i meant booting it or not shouldn't make a difference to that partition | 16:17 |
| Chipaca | although, having said that, if it _did_ make a difference that'd be interesting in and of itself | 16:17 |
| ogra_ | Chipaca, so the entry for /etc/systemd/system in /etc/system-image/writable-paths is "synced none none" so yes, content from the readonly fs will be synced on boot | 16:17 |
| longsleep | ah | 16:17 |
| ogra_ | and etc gets processed from initrd | 16:18 |
| ogra_ | (remember, we had to move it because of races) | 16:18 |
| longsleep | finally the mystery solved! | 16:18 |
| ogra_ | well, the bug is that fragments from snaps are on the readonly partition | 16:18 |
| ogra_ | that shouldnt be | 16:19 |
| longsleep | /media/longsleep/system-a/etc/systemd/system/spreedbox-led_gnatsd_0.0.6-1.service | 16:19 |
| longsleep | that is the non booted image | 16:19 |
| ogra_ | right | 16:19 |
| Chipaca | so the bug is that those are getting created by snappy during the u-d-f unpack/install thing | 16:19 |
| ogra_ | yeah | 16:19 |
| ogra_ | they would have to go into the writable space | 16:20 |
| longsleep | i see - so this needs fixing in u-d-f | 16:20 |
| ogra_ | since they are from snaps :) | 16:20 |
| Chipaca | longsleep: in snappy, actually | 16:20 |
| ogra_ | (all of the snaps shuld go into the writable space in fact) | 16:20 |
| longsleep | Chipaca: right | 16:20 |
| Chipaca | (u-d-f calls into snappy) | 16:20 |
| longsleep | Chipaca: so add a flag or something, similar to the existing ones | 16:20 |
| Chipaca | yep | 16:20 |
| Chipaca | flag already exists | 16:21 |
| Chipaca | InhibitHooks | 16:21 |
| ogra_ | Chipaca, but if udf doesnt set up the mounting in a way that the snap bits land in writable places you have lost | 16:21 |
| ogra_ | not necessarily a snappy bug imho | 16:21 |
| Chipaca | ogra_: the service files should not be created at udf time; firstboot creates them | 16:21 |
| longsleep | that would be easy to fix | 16:21 |
| longsleep | so for testing, i could remove the snap services from system-a and then do a boot | 16:22 |
| longsleep | right? | 16:22 |
| Chipaca | longsleep: yep | 16:22 |
| * longsleep gives it a try | 16:23 | |
| ogra_ | Chipaca, aha ... nontheless, snap fragments should not live in the readonly rootfs | 16:23 |
| ogra_ | and i assume there is no "boot" happening when udf assembles the img ... whihc means if you do anything chrooted in the img you wont have the mountpoints set up | 16:24 |
| ogra_ | (i can be wrong indeed ... just guessing) | 16:25 |
| longsleep | well, i removed the service files before firstboot, but firstboot did not create them | 16:25 |
| longsleep | Chipaca: yeah not installing the services in u-d-f is bad as they are not created again and update fails as the service is not loaded | 16:27 |
| Chipaca | :'-( | 16:27 |
| * Chipaca forgot how to emoticon | 16:27 | |
| longsleep | Where do you want to have the bug for this? github snappy or udf on launchpad? | 16:28 |
| Chipaca | sergiusens: mvo: ping | 16:28 |
| Chipaca | longsleep: gimme a sec | 16:28 |
| Chipaca | so the easy way would be to hack udf to set things up properly | 16:29 |
| Chipaca | i think a better way would be to make snappy not activate anything from udf, and instead add that to firstboot (which i thought was one of the things oemconfig was doing anyway) | 16:29 |
| Chipaca | but there might be a reason not to do it this way | 16:29 |
| longsleep | Chipaca: yeah, i guess we can do that and somehow move the things to writable | 16:29 |
| Chipaca | hence me pinging mvo and sergiusens :-) | 16:30 |
| Chipaca | longsleep: writable is there at udf time, just needs bind-mounting properly (or things moved to the right place post hoc, which is tricky because of random cruft in /etc/systemd/system (that shouldn't be there anyway (but I digress))) | 16:30 |
| ogra_ | +1 for firstboot, that is where it belongs | 16:31 |
| longsleep | Chipaca: so the other cruft in there should stay readonly ? | 16:31 |
| longsleep | ogra_: yes, though that is unlikely to happen for 15.04 right? | 16:32 |
| ogra_ | yeah, for that the hack might be a better approach | 16:32 |
| sergiusens | Chipaca, the plan is to move it to firstboot | 16:35 |
| sergiusens | Chipaca, if you care to create the PR for it, great ;-) | 16:35 |
| ogra_ | the PR ? | 16:35 |
| sergiusens | ogra_, pull request | 16:36 |
| ogra_ | event planning ? cheerleaders, free food and flyers ? as in public relations ? | 16:36 |
| ogra_ | aahh ! | 16:36 |
| sergiusens | Chipaca, in any case, I'd prefer if the image creator just dropped the snaps (except kernel and os) into a defined location and firstboot do its thing | 16:36 |
| ogra_ | +1 | 16:37 |
| ogra_ | isnt that what we do on the phone ? | 16:37 |
| ogra_ | (for custom tarballs) | 16:37 |
| ogra_ | jdstrand, i assume you missed my ping from this morning ? | 16:38 |
| sergiusens | ogra_, no; sadly no | 16:38 |
| sergiusens | unless it changed recently | 16:38 |
| ogra_ | oh, i thought we did | 16:39 |
| ogra_ | we really should :) | 16:39 |
| Chipaca | sergiusens: for 15.04 also? | 16:40 |
| mvo | Chipaca: sorry, I was in a meeting - so I think the issue that longsleep is seeing is fixed with something like http://bazaar.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/revision/226 | 16:40 |
| mvo | Chipaca: but I think that your idea of installing them on first boot is better, however this won't work for the OS snap (as it needs to be ready for first-boot) | 16:40 |
| Chipaca | no no | 16:41 |
| mvo | no? | 16:41 |
| Chipaca | my idea was *activating* them on first boot | 16:41 |
| Chipaca | not installing them | 16:41 |
| Chipaca | in squashfs world that might be the same thing tho :-) | 16:41 |
| Chipaca | but in 15.04 having the unpack done at build time, and the activation at first boot, seems sane and should be easily doable | 16:42 |
| Chipaca | but i don't know if we want to, and if there is going to be a release of this | 16:42 |
| Chipaca | hence, calling you | 16:42 |
| ogra_ | well, we didnt stop doing monthlies for 15.04, did we ? | 16:43 |
| ogra_ | to have the images pick up -security and -updates | 16:43 |
| * Chipaca waits for mvo to confirm that | 16:45 | |
| longsleep | Chipaca: to hack it, where exactly do the files need to go on the writable partition? i see a system-data folder there | 16:46 |
| longsleep | Chipaca: create etc/systemd/system in there ? | 16:47 |
| mvo | Chipaca: ups, sorry. indeed, this does make sense. I'm not sure if/when we do a 15.04 release though either, maybe worth bringing up at the next standup? | 16:47 |
| mvo | longsleep, Chipaca: I need to run very soon to play hockey, however I'm happy to discuss this further tonight/tomorrow | 16:48 |
| ogra_ | mvo, we'll need to sit down tomorrow too to talk about allsnaps and the build system | 16:48 |
| Chipaca | i'll look at getting a branch up with this | 16:48 |
| Chipaca | also, we need to get edge working on arm again | 16:48 |
| mvo | ogra_: sure | 16:48 |
| Chipaca | and plan the next monthly 1504 (which i think we've slipped, unless time has done its usually stretchy snappy thing) | 16:49 |
| mvo | Chipaca: yeah, no idea about the test failure right now :/ still need to investigate on a porter machine | 16:49 |
| longsleep | mvo: sure, i think i understood the problem and might figure out a hack for now - but it would be awesome if there would be a fix for 15.04 | 16:49 |
| Chipaca | mvo: blame ogra_, then he'll fix it :-p | 16:49 |
| longsleep | mvo: also this one would be nice on https://github.com/ubuntu-core/snappy/issues/189 - we have patched it locally but i guess others might have the issue as well | 16:50 |
| ogra_ | Chipaca, heh, ask davmor2 ... that only works sometimes | 16:50 |
| Chipaca | longsleep: i can't be sure offhand. easiest way would be to see on upgraded machine what /writable looks like | 16:50 |
| longsleep | Chipaca: good idea thanks | 16:50 |
| mvo | longsleep: aa, nice | 16:50 |
| davmor2 | ogra_: no it works all the time, you just go blame the right person :D | 16:50 |
| longsleep | sync | 16:53 |
| longsleep | ups :) | 16:53 |
| rickspencer3 | ogra_, are there steps I can follow to make a rolling 16.04 rpi2 image today? | 16:55 |
| Chipaca | rickspencer3: u-d-f doesn't work? | 16:58 |
| rickspencer3 | Chipaca, I did not say that, I was looking for documentation | 16:58 |
| rickspencer3 | :) | 16:59 |
| ogra_ | rickspencer3, once sec i can give you a cmdline (the rpi püage needs updating for that) | 16:59 |
| longsleep | Chipaca: ok i got scripting which fixes the problem: http://paste.ubuntu.com/13579233/ | 17:02 |
| longsleep | Chipaca: i think i can add that as a post process step to our image builder | 17:02 |
| ogra_ | rickspencer3, sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical --enable-ssh --device raspi2_armhf --output raspi2-rolling.img | 18:19 |
| ogra_ | (sorry, i had not forotten you :) ) | 18:19 |
| ogra_ | (and ignore the moaning about azure :) ) | 18:19 |
| === JamesTai1 is now known as JamesTait | ||
| jdstrand | Chipaca: hey, fyi, going through old irc (I was on holiday last week). I updated /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/snapd to have /run/snapd.socket in 15.04.12~ppa12 on Nov 13. I looks like stable hasn't been updated since then | 18:55 |
| Chipaca | jdstrand: a'yup | 18:57 |
| Chipaca | jdstrand: welcome back to the world of the living, and all that | 18:57 |
| * rickspencer3 tries | 18:59 | |
| Chipaca | ogra_: unless you've uploaded a pi2 since the channels work, that needs to be pi2.canonical/stable | 19:03 |
| ogra_ | Chipaca, really ? udf cares ? | 19:03 |
| Chipaca | no, it doesn't care, which is why that works :-) | 19:03 |
| ogra_ | ah :) | 19:04 |
| Chipaca | it's just passing that on to the CPI REST API | 19:04 |
| ogra_ | rickspencer3, ^^ | 19:04 |
| Chipaca | and CPI cares. In fact that's all it cares about ;-) | 19:04 |
| Chipaca | sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img | 19:04 |
| Chipaca | ^ seems to work | 19:04 |
| rickspencer3 | oh | 19:04 |
| Chipaca | that /stable is a temporary workaround until we get things into the edge channel itself | 19:05 |
| * rickspencer3 tries again ;) | 19:05 | |
| * rickspencer3 happily kicks off his "azure" image | 19:06 | |
| rickspencer3 | ogra_, Chipaca seemed like it downloaded the parts and built the image quite quickly | 19:08 |
| * rickspencer3 prepares to dd | 19:08 | |
| ogra_ | good | 19:08 |
| rickspencer3 | ogra_, just dd it to sbx as per usual, right? | 19:08 |
| ogra_ | yeah | 19:08 |
| ogra_ | all the same for all images :) | 19:08 |
| * rickspencer3 dds and waits | 19:10 | |
| Chipaca | http://people.canonical.com/~john/wow-so-peercred-much-access-levels.gif btw | 19:28 |
| Chipaca | tyhicks: ^ might be relevant (or not) | 19:29 |
| tyhicks | Chipaca: that's showing that the access checks aren't working as expected? | 19:34 |
| Chipaca | tyhicks: no, it's showing that they are | 19:34 |
| tyhicks | ah, right | 19:35 |
| Chipaca | tyhicks: in retrospect i should have paused before hitting enter on 'sudo !!' | 19:35 |
| Chipaca | assuming that is what tripped you up :) | 19:35 |
| tyhicks | opening up the socket to be world read/write today means that root is still required | 19:36 |
| tyhicks | yes, I think that is what tripped me up | 19:36 |
| Chipaca | tyhicks: root is still required <- for privileged operations you mean? | 19:37 |
| sandGorgon | hey guys... is there a snappy based ISO that I can try out and play with ? I'm looking at http://cdimage.ubuntu.com/daily-live/current/xenial-desktop-amd64.iso but dont know if it is intended with dpkg or snappy | 19:39 |
| Chipaca | sandGorgon: not an ISO. What are you wanting to play _on_? | 19:40 |
| tyhicks | Chipaca: yes - your gif is showing that root is required for privileged operations even though anyone can write to the socket - correct? | 19:40 |
| Chipaca | tyhicks: correct | 19:40 |
| tyhicks | got it | 19:40 |
| sergiusens | elopio, do you feel good about releaseing current master as 0.6? | 19:41 |
| Chipaca | tyhicks: didn't create the gif just for you, but thought it might be useful for you as well | 19:41 |
| Chipaca | sandGorgon: the snaps you can download from https://developer.ubuntu.com/en/snappy/start/ work in kvm, or you can dd them onto a sd card or usb stick and boot off of that | 19:42 |
| sandGorgon | Chipaca, this may sound stupid... but there were all these articles that mentioned that the next version of ubuntu will have a snappy-based flavor . so I was wondering if there were any builds of a desktop version with snappy. | 19:42 |
| Chipaca | sandGorgon: no, it does not sound stupid | 19:43 |
| tyhicks | Chipaca: it will be helpful - thanks! | 19:43 |
| Chipaca | sandGorgon: but things might have been lost in translation / repetition, as as far as I know there isn't a plan to have a snappy desktop version, but to be able to use snappy on the desktop, which is not quite the same | 19:44 |
| Chipaca | sandGorgon: i don't know how far along those plans are, though | 19:45 |
| sandGorgon | Chipaca, "Ubuntu 16.04 LTS will be able to run Snappy packages | 19:48 |
| sandGorgon | Will Cooke, the Ubuntu Desktop lead, announced during a Unity 7 discussion at the Ubuntu Online Summit that they are working to bring Snappy packages to the regular Ubuntu flavor, with Unity 7." | 19:48 |
| sandGorgon | I was wondering if I could start playing with it on the desktop... but maybe I'm jumping in too early. my bad... I can wait ;) | 19:48 |
| lotuspsychje | sandGorgon: install xenial development branch and apt-cache search snappy | 19:49 |
| lotuspsychje | and start fool around | 19:49 |
| Chipaca | sandGorgon: yes, snappy packages, but not a snappy system | 19:49 |
| sandGorgon | lotuspsychje, will do ;) | 19:49 |
| lotuspsychje | sandGorgon: ive also tested unity8 on xenial | 19:55 |
| lotuspsychje | sandGorgon: also early stage now, so it looks pretty much like the phone version | 19:55 |
| sandGorgon | lotuspsychje, oh.. is it usable ? | 19:55 |
| lotuspsychje | sandGorgon: yes, mouse support, browsing | 19:56 |
| sandGorgon | lotuspsychje, ah ok.. i'll survive probably (P.S. im more of a gnome guy) | 19:56 |
| lotuspsychje | sandGorgon: then test the ubuntu-gnome xenial development branch | 19:58 |
| sandGorgon | lotuspsychje, that's what's downloading right now | 19:58 |
| sergiusens | elopio, https://github.com/ubuntu-core/snapcraft/pull/127 | 20:09 |
| jdstrand | sergiusens: catching up on irc backscroll from holiday | 22:03 |
| jdstrand | < sergiusens> Chipaca, 2015/11/24 08:43:59.067839 security.go:205: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=network-status --policy-groups=networking] failed | 22:03 |
| jdstrand | sergiusens: you probably figured this out, but --template=network-status is wrong. the template is 'default' (ie, unspecified) and you should use caps: [ network-client, network-status ] | 22:04 |
| sergiusens | jdstrand, I haven't looked too much into it, it is just related to https://bugs.launchpad.net/snapcraft/+bug/1519251 | 22:07 |
| ubottu | Launchpad bug 1519251 in Snapcraft "Step copying .snap during 'snapcraft run' fails" [Undecided,Incomplete] | 22:07 |
| jdstrand | sergiusens: based on the sc-filtergen denial, the package yaml is using 'security-template: network-status'. It shouldn't do that | 22:13 |
| jdstrand | s/denial/error/ | 22:14 |
| jdstrand | Chipaca: fyi, I see in backscroll you pinged me about snapd and ACLs and that tyhicks responded. I will leave that topic to the two of you them | 22:16 |
| tyhicks | jdstrand: yes, I'm going to review the code | 22:19 |
| tyhicks | (card already created) | 22:19 |
| jdstrand | ogra_: re chown for services-- you mentioned massive problems. what are the problems? what are they chowning to? there is nothing they can legitimately chown to other than root, which is the user | 22:20 |
| jdstrand | ogra_: but to more simply answer your question-- it is a valid point that you need write access to the file to chown it. therefore, it makes some sense to allow these syscalls since apparmor blocks the file access | 22:21 |
| jdstrand | ogra_: however, we did not allow all of chown yet because we didn't understand the scope of issues at first and because, again, nothing valid to chown to | 22:22 |
| jdstrand | ogra_: couple that with seccomp arg filtering that we will hopefully have for 16.04. with that we'll say you can chown to 'root' for example (probably fixing your issue but in a different way), but disallow chown to 'nobody' or 'www-data'. if we decide to allow per-app user ids, we'd allow chown to that too | 22:24 |
| jdstrand | ogra_: but I didn't want to open the floodgates on that just yet, cause apps might hardcode things and do odd stuff, changing ownership to invalid things which might cause unexpected interactions | 22:25 |
| jdstrand | so proceeding with caution there. but as mentioned, the seccomp arg filtering alone will likely fix the obstacle you are facing | 22:26 |
| jdstrand | (with the accompanying policy updates) | 22:26 |
| jdstrand | tyhicks: thanks | 22:26 |
| ogra_ | jdstrand, well, lighttpd and sqlite both only use fchown when they are run as root to chown files to the right UIDs ... | 22:28 |
| ogra_ | and as it happens i'm just assembling something that uses both :) | 22:28 |
| jdstrand | ogra_: yeah, I talked about sqlite in snappy-app-devel-- I think we should probably patch it. lighthttpd is doing the exact same thing or chowning to some other user? | 22:30 |
| ogra_ | ("to the right UIDs" typically to the UIDs defined in the config file) | 22:30 |
| jdstrand | what are you putting in that config file? | 22:30 |
| jdstrand | we don't have per-app user ids yet (see mailing list) | 22:31 |
| ogra_ | well, i'm not really clear what lighttpd does, i cant find any trace of "chown" in the source | 22:31 |
| ogra_ | i indeed dont put a user into that config file ... interesting fact is that lighttpd doesnt complain about fchown on amd64 | 22:32 |
| jdstrand | ogra_: is this a xenial system? | 22:32 |
| ogra_ | amd64 is 15.04 edge ... armhf is xenial edge | 22:32 |
| jdstrand | ogra_: on the xenial system, you can do the security-override method to unblock you while you investigate. eg: | 22:33 |
| jdstrand | services: | 22:33 |
| jdstrand | - name: foo | 22:33 |
| jdstrand | security-override: | 22:33 |
| ogra_ | i use lighttpd's webdav module ... i guess that links in some sqlite stuff or so | 22:33 |
| jdstrand | syscalls: [ fchown32, chown, ... ] | 22:33 |
| jdstrand | perhaps | 22:33 |
| jdstrand | and sqlite is doing the chown to root unconditionally to root | 22:33 |
| ogra_ | yeah, i had that working at some point (and then threw everything away and started to patch the apps :P ) | 22:33 |
| ogra_ | right | 22:34 |
| ogra_ | so it is just a pointless syscall | 22:34 |
| ogra_ | but it is as pointless that we block it imho | 22:34 |
| jdstrand | well, I don't know about that | 22:35 |
| ogra_ | given you cant chown anything outside of your confinement | 22:35 |
| jdstrand | I mentioned interactions | 22:35 |
| ogra_ | jdstrand, btw, one thing that struck me ... how do we protect maintainers/developers from spp vulnerabilities ... i mean ... my https runs as root ... since i need to mangle the config it lives in $SNAP_APP_DATA_PATH ... where also my webroot needs to live ... if there is an issue with the webserver someone can just later my config remotely | 22:37 |
| ogra_ | s/spp/app/ | 22:37 |
| ogra_ | s/later/alter/ | 22:37 |
| ogra_ | i was wondering if there is any way to protect us from such things | 22:38 |
| jdstrand | ogra_: snappy doesn't help with that. if there is a vulnerability in the app itself and it can scribble out to files, it could overwrite its configuaration, db files, etc. I mentioned this in my email on user ids-- this is one reason to support them | 22:39 |
| ogra_ | oh, so you want to do some extrausers magic on a per-snap base ? | 22:40 |
| jdstrand | the easiest thing we can do which everyone already understands is allow for opt-in app ids | 22:40 |
| jdstrand | eg (and this is otoh, not designed or talked about beyond that thread and a couple of conversations): | 22:40 |
| jdstrand | services: | 22:40 |
| jdstrand | wait | 22:40 |
| jdstrand | name: foo | 22:40 |
| jdstrand | services: | 22:40 |
| jdstrand | - name: bar | 22:40 |
| jdstrand | app-user: true | 22:41 |
| jdstrand | then on install, that create the foo_bar user | 22:41 |
| jdstrand | creates | 22:41 |
| ogra_ | hmm | 22:41 |
| jdstrand | that is a sort of 'system' user in that it is passwordless, etc | 22:41 |
| jdstrand | then the seccomp policy allows chowning to that user, etc | 22:41 |
| jdstrand | there are other ways to do that | 22:42 |
| jdstrand | but the basic idea is come up with something that namespaces the users to the package name | 22:42 |
| ogra_ | i wonder if we couldnt teach libnss-extrausers to accept something like a passwd.d/ dir where snaps could drop their snippets | 22:42 |
| jdstrand | s/snaps/snappy install/ :) | 22:42 |
| ogra_ | :) | 22:43 |
| jdstrand | app-user: true might be artificially limiting. perhaps a single service wants more than one app user. perhaps the users shouldn't be tied to the service at all, etc | 22:43 |
| jdstrand | anyway, those are the types of things to work out. I think there are some pretty good reasons for supporting them (see email thread) based on dev input | 22:44 |
| ogra_ | right | 22:44 |
| jdstrand | maybe this is something we can discuss at the upcoming sprint if there is time | 22:46 |
| ogra_ | the feb. one you mean ? yeah | 22:47 |
| jdstrand | no, the one I am going to next week :) | 22:47 |
| ogra_ | ah | 22:47 |
| jdstrand | but sometime this cycle, sure | 22:47 |
| jdstrand | beuno, pindonga: hey, when is the next scheduled store rollout? I have a big merge to the review tools for all snaps that I'd rather get in sooner this week or wait until after next (and continue with manual reviews until then) | 23:06 |
| jdstrand | beuno, pindonga: basically, I don't want it hitting on the weekend or while I am sprinting in case I need to react quickly to something | 23:06 |
| === retrack is now known as Guest23314 | ||
| ogra_ | jdstrand, oh, btw ... if i put the above into my snapcraft.yaml i get | 23:36 |
| ogra_ | Issues while validating snapcraft.yaml: 'apparmor' is a required property | 23:36 |
| ogra_ | seems security-override wants an apparmor line too | 23:36 |
| jdstrand | ogra_: I think snapcraft needs to be updated for the new 16.04 yaml | 23:36 |
| jdstrand | sergiusens: I mentioned this elsewhere, but fyi ^ | 23:37 |
| jdstrand | ogra_: oh, is that click review tools? | 23:37 |
| jdstrand | ogra_: yes, there is an MP about to land for that | 23:37 |
| ogra_ | might be ... i get it on "snapcaft clean" | 23:37 |
| jdstrand | ogra_: can you paste the output? | 23:37 |
| ogra_ | well, that was all output | 23:38 |
| ogra_ | root@localhost:/upnp-server# snapcraft clean | 23:38 |
| ogra_ | Issues while validating snapcraft.yaml: 'apparmor' is a required property | 23:38 |
| ogra_ | root@localhost:/upnp-server# | 23:38 |
| jdstrand | sergiusens: fyi, not sure if snapcraft needs to be updated or not (just fyi) | 23:38 |
| jdstrand | that sounds like it does | 23:38 |
| ogra_ | yeah | 23:39 |
| * ogra_ still doesnt get why lighttpd behaves different on armhf vs amd64 ... there is no fchown32 call on amd64 it seems | 23:40 | |
| jdstrand | yeah, there will be different syscalls between those | 23:40 |
| ogra_ | well, different, sure ... but having the call on one arch and not on the other ? | 23:41 |
| jdstrand | fchown and fchown32 are maybe what you need | 23:41 |
| jdstrand | yeah, that is common | 23:41 |
| jdstrand | or at least, not uncommon | 23:42 |
| ogra_ | really ? | 23:42 |
| ogra_ | wow | 23:42 |
| jdstrand | I didn't know that either til having to look at all these | 23:42 |
| ogra_ | oh man | 23:49 |
| * ogra_ slaps forehead | 23:49 | |
| ogra_ | so i was seeing the syscall issue on armhf but not on amd64 ... because my snapcraft.yaml has a copy plugin that copies libsqlite to usr/lib/x86_64-linux-gnu ... | 23:50 |
| * ogra_ blushes | 23:50 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
