| === tai271828_ is now known as tai271828 | ||
| thefinn93 | how can i get curl onto Ubuntu Snappy? | 00:52 |
|---|---|---|
| thefinn93 | oh, wow, internet sez write a python script to do it | 00:59 |
| thefinn93 | :/ | 00:59 |
| Trevinho | thefinn93: are you using snapcraft? you culd include it as a dependency... | 00:59 |
| thefinn93 | i have no idea what that is | 01:00 |
| thefinn93 | i was given a raspberry pi and told to put something called ubuntu snappy on it and set it up for easy access, which in this case means dynamic DNS. i guess i foolishly assumed curl'ing the DDNS provider would be the way to go about that | 01:01 |
| Trevinho | thefinn93: ah, ok... well you need to install a curl snap then if you want to use curl.... I guess it's not provided yet, but you can easilty build one with snapcraft | 01:01 |
| thefinn93 | okay... i'll just make a ghetto DDNS client in python | 01:03 |
| thefinn93 | from reading rando blog posts that seems like it'll work | 01:03 |
| thefinn93 | could proly give it some basic logic too, like, check if we really need to update | 01:03 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === greyback is now known as greyback|bbiab | ||
| ogra_ | mvo, thanks for the uploads (i totally slept in ... unplanned (hey jetlag)) .... the images boot on pi2 and dragon ... | 10:42 |
| mvo | ogra_: \o/ | 10:42 |
| === JanC is now known as Guest23785 | ||
| === JanC_ is now known as JanC | ||
| kyrofa | Good morning | 12:08 |
| seb128 | hum, what /etc are snaps seeing? | 13:24 |
| seb128 | the host system one? | 13:24 |
| seb128 | or a "merge" of the system + what is in the snap? | 13:25 |
| kyrofa | seb128, talking desktop, I assume? | 13:25 |
| seb128 | yes | 13:25 |
| seb128 | is there a difference there? | 13:26 |
| seb128 | basically doing a snap install hello-world on xenial desktop | 13:27 |
| seb128 | and hello-word.sh | 13:27 |
| seb128 | ls /etc | 13:27 |
| kyrofa | seb128, yeah, there is. In ubuntu core the host system is the OS snap, in which case I can definitely say the /etc seen by a snap is that of the OS snap | 13:27 |
| kyrofa | seb128, but on the desktop, snaps still use the OS snap, but then you have the actual host system | 13:28 |
| seb128 | it's weird | 13:28 |
| kyrofa | seb128, so unless something is bind-mounted somewhere... | 13:28 |
| seb128 | like /etc seems the real system one | 13:28 |
| seb128 | but /usr/lib isn't | 13:28 |
| seb128 | mount doesn't list /etc | 13:28 |
| seb128 | snaps are still magic to me :p | 13:28 |
| seb128 | is there a document somewhere explaining how is the snap install "constructed"? | 13:29 |
| kyrofa | seb128, yeah this is best answered by mvo. I'm not sure what all is bind mounted into the OS snap on the desktop right now | 13:29 |
| seb128 | $ mount | grep usr | 13:29 |
| seb128 | /var/lib/snapd/snaps/ubuntu-core_113.snap on /usr type squashfs (ro,relatime) | 13:29 |
| seb128 | $ mount | grep etc | 13:29 |
| seb128 | $ | 13:29 |
| seb128 | I would expect the /etc to be the one of the snap (or ubuntu-core + snap) but doesn't seem to be the case | 13:30 |
| kyrofa | seb128, you mean if any old snap shipped a `etc` folder within it? I don't believe that's the case | 13:30 |
| seb128 | old snap? | 13:30 |
| kyrofa | seb128, I mean any snap contains apps, not an OS snap | 13:31 |
| seb128 | no, as said, install hello-world, run hellow-world.sh, ls /etc | 13:31 |
| seb128 | what do I see | 13:31 |
| seb128 | ? | 13:31 |
| seb128 | is that the pure host system one unmodified? | 13:31 |
| kyrofa | seb128, either that of the host system or that of the OS snap. Not sure which :) | 13:32 |
| seb128 | kyrofa, is there an OS snap in the context of a xenial desktop install? | 13:34 |
| kyrofa | seb128, indeed, that's what I was trying to say | 13:34 |
| seb128 | things are still confusing to me | 13:35 |
| seb128 | like /etc is the real one | 13:35 |
| seb128 | but /usr is the ubuntu-core one | 13:35 |
| seb128 | it seems | 13:35 |
| kyrofa | seb128, that's why locales don't work-- the folder in which they'd normally exist is not bind-mounted into the OS snap, so snaps don't see them | 13:35 |
| seb128 | right | 13:35 |
| seb128 | I'm just surprised that the real /etc is under /etc | 13:35 |
| seb128 | seems inconsistent | 13:35 |
| seb128 | trying to understand the logic | 13:36 |
| kyrofa | seb128, perhaps a bit of a whack-a-mole-- maybe networking didn't work without /etc bind-mounted? | 13:36 |
| seb128 | could be | 13:36 |
| seb128 | kyrofa, thanks for the replies | 13:38 |
| seb128 | kyrofa, do you know if there is a place where all the architectures choices are explained/described? | 13:38 |
| mvo | seb128: the /etc is from the host, we need quite a bit of data from there, e.g. hostname, timezone and stuff like that | 13:39 |
| kyrofa | seb128, not that I know of | 13:40 |
| seb128 | mvo, isn't that potentially leaking infos like my service configs, users db, etc? | 13:40 |
| mvo | seb128: yes | 13:41 |
| mvo | seb128: it comes down to /etc is a mess that contains a lot of stuff that really should not be there | 13:41 |
| jdstrand | mvo: thanks for the merge of the unity7 PR. There are a few other related ones it looks like you've requested restesting on-- it would be great to have those in 2.0.5-- is that the plan? | 13:41 |
| mvo | seb128: fwiw, a lot of the potential leaking is managed by apparmor | 13:41 |
| seb128 | mvo, I see, thanks | 13:42 |
| mvo | jdstrand: 2.0.5 just went out, unless I need to redo that 2.0.5 is final, but there will be another one next week | 13:42 |
| mvo | seb128: anything specific you are concerned about? | 13:42 |
| jdstrand | I see | 13:42 |
| seb128 | mvo, no, I'm just trying to understand how the snap "view of the world" is made, what comes from the system, what comes for the ubuntu-core snap, what comes from my app | 13:43 |
| seb128 | mvo, is there any document describing the architecture? | 13:43 |
| seb128 | mvo, seems that by default it sees the host but has bits overwriten by squashfs mounts (like /usr mounted from ubuntu-core) + apparmor restrictions? (and the .snap being mounted in its /snaps dir)? | 13:44 |
| mvo | seb128: its the hostfs with /lib,/usr,/bin/,/sbin,/lib64 from ubuntu-core to have clean libs and commands. the host /etc and /media and /var. plus apparmor (of course) to prevent snaps to poke at stuff they should not. no document afaik, I think it would be good to write one. the idea behind it is that its a super thin layer of abstraction/hidding so that hardware tools still work and you can still use the raw network and all that | 13:46 |
| seb128 | mvo, that makes sense, thanks (was just trying to figure out what is available exactly and where) | 13:50 |
| * mvo nods | 13:52 | |
| seb128 | mvo, I'm looking forward having the bind mounts of more specific dirs btw! (learnt earlier this week that's it got on the plan now ;-) | 13:53 |
| seb128 | mvo, I was concerned about how hackish getting things like locales/translations/fonts etc working was before | 13:53 |
| mvo | seb128: yeah, there is a plan to open certain dirs for fonts etc up | 13:53 |
| mvo | seb128: its all still not super nice, its tricky to get right | 13:54 |
| seb128 | right | 13:54 |
| seb128 | well still an improvement | 13:54 |
| mvo | we fight 30years of legacy here :) | 13:54 |
| mvo | indeed! | 13:54 |
| seb128 | some weeks ago ogra said that those had to be shipped in the snap and that it was by design | 13:54 |
| seb128 | so good to see that the line of thinking is changing slightly | 13:55 |
| mvo | seb128: :) | 13:57 |
| mvo | seb128: would be a bit silly of all snaps would ship all fonts | 13:57 |
| seb128 | yeah | 13:57 |
| seb128 | or libc locales definitions | 13:57 |
| mvo | yeah | 13:57 |
| ogra_ | seb128, well, once there will be a fonts snap that provides an interface | 13:59 |
| ogra_ | today there isnt ... so you have to ship what you need | 13:59 |
| ogra_ | (or wait for the interface ... or use --devmode) | 13:59 |
| mvo | yeah, I think thats it, ogra_ is describing the "today" but I think we want to get something better for "tomorrow" | 14:00 |
| seb128 | ogra_, right, that's good ;-) (your responses a few weeks ago was "it's a feature/by design, there is no intention to provide things like locales for you, that would make snaps not independant enough") | 14:00 |
| ogra_ | right | 14:00 |
| seb128 | mvo, right, well that was not his position | 14:00 |
| seb128 | but I'm happy with the current line of thinking ;-) | 14:01 |
| ogra_ | seb128, well, in core there are no plans to add the loaclaes to the image | 14:01 |
| seb128 | right, that's another topic | 14:01 |
| seb128 | core needs to be small/restricted | 14:01 |
| ogra_ | well | 14:05 |
| ogra_ | we want desktops on top of core too at some point | 14:05 |
| seb128 | unsure who would like that | 14:06 |
| ogra_ | well, phones are supposed to be snappy eventually ... | 14:06 |
| seb128 | having every app bundling the world including all existing fonts, locales definitions, etc doesn't seem compeling | 14:06 |
| ogra_ | nah | 14:06 |
| ogra_ | there you will have a desktop snap that provides an interface or some such | 14:07 |
| ogra_ | though these are post-16 things | 14:07 |
| seb128 | right, let's see when we get there | 14:09 |
| seb128 | hum | 14:22 |
| seb128 | did anyone look a providing a XDG_RUNTIME_DIR (/run/user/<uid>) in the snap env? | 14:23 |
| seb128 | mvo, ^ do you know? | 14:24 |
| === chihchun is now known as chihchun_afk | ||
| seb128 | jdstrand, ^ or you? | 14:30 |
| === chihchun_afk is now known as chihchun | ||
| jdstrand | seb128: I did not look at that | 14:38 |
| seb128 | jdstrand, I commented on the gsettings bug saying it's needed for dconf to work | 14:39 |
| seb128 | jdstrand, unsure if we should have a bug specific about that? | 14:40 |
| seb128 | that = /run/user | 14:40 |
| seb128 | I guess so | 14:40 |
| ogra_ | wasnt there a discussion led by ted about having it in the launcher ? | 14:41 |
| seb128 | could be, I was not around/where it was discussed | 14:41 |
| seb128 | tedg, ^? | 14:41 |
| ogra_ | similar to /tmp handling we have today | 14:41 |
| ogra_ | yeah, it was a while ago | 14:41 |
| tedg | It should probably be in the bash file generated for GUI apps. | 14:42 |
| ogra_ | we definitely have open bugs where people worked around it by setting it to SNAP_DATA in their wrapper scripts | 14:42 |
| tedg | I'm not sure there should be a bunch of XDG variables set for apps that don't need them. | 14:42 |
| ogra_ | well, on classic you kind of want to provide them | 14:43 |
| ogra_ | i assume | 14:43 |
| tedg | Not sure you want to for the postgres server :-) | 14:43 |
| tedg | *probably* won't harm things, but eh. | 14:43 |
| ogra_ | why not, as long as it is confined its just a tmpfs | 14:43 |
| ogra_ | you dont want to point it to the real /run ... everything else should be safe | 14:44 |
| tedg | At some point you have no way to reject an environment variable then. If you'll say that you'll set any value for any use-case. What is the case where an env wouldn't be put there? | 14:44 |
| ogra_ | (you could also just hard-map it to /tmp/run/) | 14:45 |
| seb128 | ogra_, tedg, but today we do need some things from the real /run to get things working though | 14:45 |
| ogra_ | that needs urgent fixing i guess :) | 14:46 |
| tedg | seb128: I realize. I'm just saying that we're headed to a "junk drawer" situation of environment variable. I don't think you have a choice other than to include it. | 14:46 |
| tedg | seb128: You might be able to use the bindmounting thing that tyhicks is working on if you only want a few entries from there. | 14:47 |
| seb128 | right | 14:47 |
| ogra_ | well, the current target is --devmode snaps ... and grow the missing bits over timwe | 14:47 |
| tedg | ogra_: Or switch to a desktop that doesn't have all these legacy interfaces not designed for confinement ;-) | 14:47 |
| ogra_ | this should definitely be high on the list ... but we know in advance we cant fulfill all requirements immediately | 14:47 |
| ogra_ | tedg, like wm2 or ion3 ? | 14:48 |
| tedg | ogra_: I'm still running fvwm95 | 14:48 |
| ogra_ | heh | 14:49 |
| ogra_ | already having antialiased fonts ? | 14:49 |
| tedg | I don't waste GPU resources with eye-candy like that. | 14:49 |
| ssweeny | zyga, is there anything left for me to do on the location interface? | 15:02 |
| jdstrand | beuno: hi! I have a ufw snap for series 16. AIUI, people want it uploaded under the canonical account (fine). I have a ufw.jdstrand in 15.04 store. will I be able to create a ufw project under the canonical account and upload it to the store for series 16? | 15:35 |
| beuno | jdstrand, great question! | 15:59 |
| beuno | nessita will know | 15:59 |
| nessita | jdstrand, you should be able1 | 16:00 |
| nessita | let me know if that is not the case | 16:01 |
| jdstrand | ok, let me try | 16:01 |
| jdstrand | whoa | 16:03 |
| jdstrand | the store is a lot prettier all of a sudden :) | 16:03 |
| === chihchun is now known as chihchun_afk | ||
| beuno | sorry | 16:04 |
| beuno | blame beowulf | 16:04 |
| jdstrand | I'm not complaining :) | 16:04 |
| beowulf | YES! FEED ME YOUR PRAISE! | 16:11 |
| kyrofa | beowulf, I second the praise-- it's quite nice ;) | 16:13 |
| beowulf | kyrofa: it's the best i could do in between the beatings from beuno | 16:13 |
| jdstrand | nessita, beuno: it worked! :) | 16:15 |
| qengho | beowulf: that Downloads graph threw me for far too long. Your Y axis direction broke my brain. | 16:22 |
| niemeyer_ | jdstrand: ping | 16:29 |
| mvo | jdstrand, tyhicks: how can I disable environment scrubbing in the apparmor profile of the ubuntu-core-launcher? | 16:47 |
| tyhicks | mvo: it shouldn't be happening | 16:48 |
| mvo | tyhicks: interessting | 16:49 |
| mvo | tyhicks: its my best theory so far :) | 16:49 |
| tyhicks | mvo: there are no exec rules that should trigger env scrubbing of the launched apps in that profile | 16:49 |
| tyhicks | mvo: I have some more investigation to do based on your new findings :) | 16:50 |
| mvo | tyhicks: thanks! | 16:50 |
| mvo | tyhicks: sorry, if the scrubbing is a red-herring, all I know is that with apparmor the LD_LIBRARY_PATH is gone and when I unload the profile around the launcher it works :) | 16:50 |
| tyhicks | mvo: apparmor can request secureexec which will cause env scrubbing | 16:51 |
| tyhicks | mvo: it shouldn't be requesting secureexec based on the launcher's profile | 16:51 |
| mvo | tyhicks: fwiw, with https://code.launchpad.net/~mvo/ubuntu-core-launcher/environment-file/+merge/295237 and bzr-buildpackage; sudo dpkg -i ../build-area/*1.0.29*.deb its easy to test. just install hello-world and add /var/lib/snapd/environment/hello-world.env with LD_LIBRARY_PATH=/something | 16:53 |
| mvo | tyhicks: then hello-world.env|grep LD_ will either show up or not, depending on apparmor. this is what I used to test this | 16:54 |
| mvo | tyhicks: anyway, not urgent, just an interessting puzzle :) I will get some dinner now | 16:54 |
| tyhicks | mvo: ack - thanks | 16:55 |
| niemeyer_ | jdstrand: reping | 17:25 |
| plars | jdstrand: jjohansen: well, I did a fresh build of the tests and they seem to run ok for me. Did that patch land already maybe? | 17:50 |
| jdstrand | niemeyer_: hey, sorry I was out for a little bit | 17:54 |
| qengho | Hi. How should we have apps that can write beneath SNAP_DATA that a service reads? sudo from outside doesn't have snap bin in the PATH, normally. I don't think I can sudo from inside the snap app. | 17:55 |
| jdstrand | you can't sudo from within a snap | 17:56 |
| qengho | Right. | 17:56 |
| jdstrand | /snap/bin not in PATH has an open bug | 17:56 |
| qengho | Ah. | 17:56 |
| qengho | Thanks. | 17:56 |
| jdstrand | sudo /snap/bin/foo works fine | 17:56 |
| qengho | I assumed not in PATH was intentional. | 17:57 |
| jdstrand | plars: I'm quite sure the kernel patch has not landed anywhere | 17:58 |
| === chihchun_afk is now known as chihchun | ||
| klow | So Ubuntu Core is a minimal OS, Snappy is a transactional udpdate system, and snapcraft is sortof a Docker alternative for packaging apps to run on Core, and Core also Supports Docker apps ? Am I understandinf that right? | 18:49 |
| kyrofa | klow, sort of. Snaps aren't quite as fat as docker containers, they're just isolated | 18:56 |
| kyrofa | klow, but yes, one can package docker in a snap | 18:56 |
| niemeyer_ | jdstrand: Are we both here now? :) | 19:04 |
| jdstrand | niemeyer_: I think so :) | 19:05 |
| niemeyer_ | Sweet | 19:05 |
| niemeyer_ | jdstrand: Can we quickly go over the status of these interfaces we have up for review? | 19:05 |
| niemeyer_ | jdstrand: We can start by network-manager.. | 19:05 |
| jdstrand | sure | 19:05 |
| jdstrand | nm is committed last I saw | 19:06 |
| jdstrand | there is a little fine-tuning I want to do, but that isn't hugely important or blocking | 19:06 |
| jdstrand | niemeyer_: ^ | 19:08 |
| niemeyer_ | jdstrand: Hmm | 19:08 |
| niemeyer_ | jdstrand: I'm trying to find the comment where you point out it was very open.. I'm probably mixing up interfaces | 19:08 |
| jdstrand | niemeyer_: that was location service | 19:08 |
| niemeyer_ | jdstrand: Ah, ok | 19:09 |
| niemeyer_ | jdstrand: So how's that one going? | 19:09 |
| jdstrand | niemeyer_: specifically, the bus policy says that all the dbus interfaces can be used. this is in contrast to say, nm which had fine-grained bus policy | 19:09 |
| jdstrand | niemeyer_: I don't consider that blocking. if that is how the api is designed, apparmor will mediate the access. | 19:10 |
| niemeyer_ | jdstrand: What sort of APIs exist under that interface? | 19:10 |
| jdstrand | niemeyer_: the issue with location service was zyga's and my interaction | 19:10 |
| jdstrand | niemeyer_: that's a good question. looking at the apparmor policy there are things to start and stop 'velocity, heading and position updates' (I guess that is to say whether or not you want to get positioning info) and then to receive position, heading and velocity from the service | 19:13 |
| jdstrand | and then Getting and Setting all properties | 19:13 |
| klow | Are snaps more fitting for apps which need persistent storage, example: a Snap containing SOGo (Apache, database + Postifx/Dovecot and persistent mailbox with virtual users from a remote LDAP server) | 19:13 |
| jdstrand | I think we'd need ssweeny to comment on everything that is available | 19:13 |
| klow | vs Docker | 19:13 |
| jdstrand | klow: snaps are designed to support persistent data conveniently | 19:14 |
| niemeyer_ | jdstrand: Anything dangerous you can identify there? | 19:15 |
| ssweeny | jdstrand, niemeyer_ the API is pretty much what's shown in the apparmor rules | 19:15 |
| niemeyer_ | ssweeny: ^ | 19:15 |
| jdstrand | klow: each snap gets an app-specific writable area that it can do whatever it wants with, and upgrades are handled to | 19:16 |
| klow | Is there a full blown book on the snap architecture available yet? So I can really dig in and contrast it with other methods ? | 19:16 |
| klow | I see. That sounds pretty cool . Arbritarily configurable size for the write area I assume? | 19:17 |
| jdstrand | klow: the community team is developing the docs. you might ask on the status when dpm or dholbach are around (both seem offline atm) | 19:17 |
| jdstrand | klow: there are no quotas, so no issues there | 19:17 |
| jdstrand | ssweeny: well, yes but I don't know what is in the Get and Set methods | 19:17 |
| niemeyer_ | jdstrand, ssweeny: Indeed, and who would use them to Set things | 19:19 |
| niemeyer_ | Do we need location-control in addition to location | 19:19 |
| niemeyer_ | ? | 19:19 |
| niemeyer_ | These seem slightly different | 19:19 |
| klow | Is there any UI , Web or otherwise so one can see which versions of snaps are on that particular server, and update them if desired ? I assume server can be configured as to allow only snaps from a private snap repository to be installed ? | 19:19 |
| ssweeny | jdstrand, ah, so the properties available are: " is_online [get/set]\n" | 19:19 |
| ssweeny | " does_satellite_based_positioning [get/set]\n" | 19:19 |
| ssweeny | " does_report_wifi_and_cell_ids [get/set]\n" | 19:19 |
| ssweeny | " visible_space_vehicles [get]", | 19:19 |
| klow | sorry for so many questions I am tasked with going from manual sysadmin to package/container deployment wiz ASAP on a huge crunch :) | 19:20 |
| jdstrand | ssweeny: the non-Set/Get apis seem all related to just setting up a session to obtain positioning info. I wouldn't mind Get as part of that based on what you just listed, but it seems odd to be able to Set some of those if this is just about access to positioning | 19:21 |
| ssweeny | jdstrand, right, as niemeyer_ said it might make more sense to have those in a separate controller interface. There's a command-line client which mostly makes use of those | 19:22 |
| jdstrand | klow: yes. 'snap list/snap refresh' and the webdm snap. as for private snap repo, I'll let others comment | 19:22 |
| niemeyer_ | ssweeny: Can we split that up? | 19:22 |
| jdstrand | niemeyer_: now I wonder if this should be s/location/location-observe/ and then add location-control | 19:22 |
| niemeyer_ | ssweeny: We can start by having that branch in just with the consumer side of things, which is likely the vast majority of cases | 19:23 |
| ssweeny | niemeyer_, sure. Would the dbus rules need to change as well? | 19:23 |
| jdstrand | as written, it was 'all of location' but you make a good point on splitting I think | 19:23 |
| niemeyer_ | jdstrand: Yeah, that sounds nice | 19:24 |
| niemeyer_ | ssweeny: To constrain the set side, I suppose..? | 19:24 |
| jdstrand | ssweeny: in terms of policy, I think just remove Set from location-observe and add it to location-control | 19:24 |
| jdstrand | ssweeny: you'll likely need a couple of org.freedesktop accesses in location-control | 19:25 |
| jdstrand | but I think we are saying that you can observe (plugs location-observe), you can control (plugs location-control) or you can observe and control (plugs location-observe, location-control) | 19:26 |
| jdstrand | which is a long way of saying-- location-control is not all of location-observe + Set, it is pretty much just Set | 19:26 |
| jdstrand | (and whatever is needed to support Set, of course) | 19:27 |
| jdstrand | niemeyer_: beyond that ^, there is this comment which I think needs zyga's input: https://github.com/ubuntu-core/snappy/pull/1118/files#r63869816 | 19:28 |
| ssweeny | jdstrand, ack | 19:29 |
| niemeyer_ | jdstrand: Can I get a quick overview of the problem being covered there in terms of the actual snippets? | 19:30 |
| niemeyer_ | jdstrand: How would the combined snippet look like? | 19:31 |
| jdstrand | niemeyer_: foo and bar want to connect to location, so the Plugs snippet has label={snap.foo.*,snap.bar.*} | 19:31 |
| jdstrand | niemeyer_: that works fine | 19:31 |
| jdstrand | niemeyer_: but the Slots snippet should also have label={snap.foo.*,snap.bar.*} in some rules, but it cannot currently | 19:32 |
| jdstrand | ConnectedSlots to be precise | 19:32 |
| jdstrand | (and I'm taking zyga's work that it cannot currently) | 19:33 |
| niemeyer_ | jdstrand: Would duplicating the same statement not work? | 19:34 |
| niemeyer_ | jdstrand: that is, one with label A, another with label B? | 19:34 |
| jdstrand | niemeyer_: that would be totally fine | 19:34 |
| niemeyer_ | jdstrand: Would it add, or would it replace? | 19:34 |
| jdstrand | it would add | 19:34 |
| niemeyer_ | zyga: Not clear what's the problem then? | 19:34 |
| jdstrand | dbus ... label={foo,bar} is the same as dbus ... label=foo, dbus ... label=bar | 19:35 |
| jdstrand | I'll be honest, I was confused that there was a problem after the comment on (I think it was) the nm PR | 19:36 |
| jdstrand | where I thanked zyga for the clarification | 19:37 |
| klow | Is snappy ubuntu proprietary, are there any restrictions or costs associated with its use commercially ? | 19:37 |
| jdstrand | so yes, I'm curious too | 19:37 |
| jdstrand | klow: just to answer you quickly, it is open source, there are open source reference kernel snaps that can be used and the os snap is open source | 19:38 |
| jdstrand | you can have proprietary stuff on it, and there are certain things that you need to be Ubuntu certified, which can be used in various ways with the store | 19:39 |
| klow | Could my company run our own store for our own apps and have our devices/servers run only apps we have pushed to our private store? | 19:40 |
| jdstrand | but, you may want to ask specific questions of Canonical or others on this list if you are using this commercially (I'm not the authoritative answer on all that) | 19:40 |
| jdstrand | I'm not up to date on that. beuno ^ | 19:41 |
| jdstrand | s/this list/this channel/ | 19:41 |
| jdstrand | niemeyer_: did you have other questions regarding location or other interfaces? | 19:41 |
| niemeyer_ | jdstrand: What else do we have up for review? | 19:42 |
| jdstrand | pulseaudio | 19:42 |
| jdstrand | I have an open question for you on that one | 19:42 |
| jdstrand | regarding shm | 19:42 |
| niemeyer_ | jdstrand: Ah, sure? | 19:42 |
| jdstrand | let me find it | 19:42 |
| jdstrand | actually, there are two things | 19:43 |
| jdstrand | 1. recording | 19:43 |
| niemeyer_ | jdstrand: On network-manager, one question I had was about whether we'd need some sort of separation too | 19:43 |
| jdstrand | I think it is probably fine to not block on that | 19:43 |
| jdstrand | but to SRU morphis' pulseaudio 'snap.' check soonish | 19:43 |
| jdstrand | niemeyer_: you mean something along the lines of network-manager-observe vs network-manager-control? if so, I think probably not. nm isn't really designed that way and its API is vast and libraries (eg, qt) rely on being able to access all of it. I think 'network-manager' with no autoconnect is correct | 19:45 |
| niemeyer_ | jdstrand: It's a slightly trickier one because we have conflicting (?) rules for network-observe and control, but it feels like we need the same sort of "lightweigh" vs "dangerous" case there | 19:45 |
| niemeyer_ | jdstrand: Well, sort of | 19:46 |
| jdstrand | niemeyer_: but then we bring on safe interfaces like connectivity-api | 19:46 |
| niemeyer_ | jdstrand: What's the proper way to find network status? | 19:46 |
| jdstrand | niemeyer_: the proper way is connectivity-api :) that was something the security team recommended the Touch guys write. it is an easy api, has a plugin into qt. it is a service that has a properly designed dbus api. you ask it, it asked nm | 19:47 |
| jdstrand | niemeyer_: but for nm, there isn't really a 'safe' one cause the libs pound scores of API calls to see if you are online, which reveals all kinds of sensitive info | 19:48 |
| niemeyer_ | Hmmm.. interesting | 19:48 |
| jdstrand | niemeyer_: which is also why there is such a complicated bus policy and polkit policy around nm. it unfortunately isn't a well designed api... :\ | 19:49 |
| jdstrand | and the bus policy/polkit stuff assumes a trusted client is connecting | 19:50 |
| jdstrand | sdoc is a weird hybrid though | 19:51 |
| niemeyer_ | jdstrand: Really? Wow | 19:52 |
| jdstrand | on Touch we needed to be locked down. on iot, same thing. sdoc... it might be possible to tease out a few things that are ok, but I fear it isn't going to be very useful | 19:53 |
| jdstrand | for example, in Ubuntu, polkit (probably only if you have a seat), will allow you to add/remove wife connections | 19:53 |
| niemeyer_ | Alright, in the spirit of our priority agreements, I'm happy to move with it too | 19:53 |
| thomi | jdstrand: does kyrofa's answer on https://bugs.launchpad.net/click-reviewers-tools/+bug/1582513 allow us to move forwards fixing this? If not, is there someone other than s3rgiusens we can ask (I believe he's on holiday?) | 19:54 |
| ubottu | Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New] | 19:54 |
| jdstrand | we can always re-assess once people are using it | 19:54 |
| niemeyer_ | jdstrand: So location is blocked on zyga's feedback | 19:54 |
| jdstrand | yes | 19:54 |
| niemeyer_ | jdstrand: and on the split of control vs. observe | 19:54 |
| jdstrand | right | 19:54 |
| jdstrand | pulse is we need to agree on recording and the other question I had | 19:54 |
| niemeyer_ | jdstrand: Anything pending for pulseaudio? | 19:54 |
| jjohansen | plars: sorry, no turns out my fix was no good | 19:54 |
| * jdstrand goes to find that | 19:55 | |
| jdstrand | niemeyer_: did you see my comments on recording, above? | 19:55 |
| niemeyer_ | jdstrand: Unless there's an easy way to control recording vs. not, I think we should move forward | 19:55 |
| jdstrand | niemeyer_: ok, I think you missed what I said | 19:55 |
| kyrofa | thomi, I expect you'll need to wait for sergiusens-- he's currently the only snapcraft dev | 19:55 |
| niemeyer_ | jdstrand: I did.. still looking for it | 19:55 |
| thomi | kyrofa: ok, thanks | 19:56 |
| niemeyer_ | jdstrand: I cannot find the comments, sorry.. can you paste? | 19:57 |
| jdstrand | niemeyer_: morphis has a PoC for pulse that blocks recording if the connecting process' security label starts with 'snap.'. I suggest: we not block the interface on that, but SRU that change in the coming weeks. then, refine that check into a proper interface (perhaps a recording attrib?) | 19:57 |
| niemeyer_ | jdstrand: Sounds great | 19:57 |
| jdstrand | ok, I'll comment on that in the PR | 19:57 |
| niemeyer_ | jdstrand: That's what I was going to suggest as well, despite not knowing a plan was already underway | 19:57 |
| niemeyer_ | jdstrand: we can do pulseaudio-recording too | 19:57 |
| jdstrand | niemeyer_: then there is my other shm question | 19:57 |
| niemeyer_ | or pulseaudio-record, actually | 19:58 |
| jdstrand | niemeyer_: right, we can discuss which is best | 19:58 |
| niemeyer_ | following observe ,control etc | 19:58 |
| * jdstrand nods | 19:58 | |
| niemeyer_ | jdstrand: But you're right, this may be the first case that an attribute might make sense.. let's see | 19:58 |
| jdstrand | niemeyer_: the other comment was really a clarification of: https://github.com/ubuntu-core/snappy/pull/1133#discussion_r63693432 | 19:58 |
| jdstrand | niemeyer_: that is your comment. please see that then read mine | 19:59 |
| niemeyer_ | jdstrand: the dev/shm? What's the question on it? | 19:59 |
| niemeyer_ | Looking | 19:59 |
| niemeyer_ | jdstrand: Yes, I think we're on the same page | 19:59 |
| niemeyer_ | jdstrand: I'm happy for both of them to go in.. the background is this: | 20:00 |
| niemeyer_ | jdstrand: One of them gives a way its own playground without having to ask for interfaces or anything, at the price of changing its shm file name | 20:00 |
| niemeyer_ | jdstrand: The other gives the process a way to communicate with other processes without changing its shm filename, at the price of having an interface well defined | 20:01 |
| niemeyer_ | Both seem good | 20:01 |
| niemeyer_ | I wish there was a way to unify them further, but given the semantics of /dev/shm, I'm not optimistic | 20:01 |
| niemeyer_ | We'll probably need to patch the system more aggressively for anything better than this | 20:02 |
| jdstrand | yeah | 20:02 |
| jdstrand | ok, cool | 20:02 |
| jdstrand | niemeyer_: I'm of the same opinion. I reopened the other PR. it would be great if you could LGTM it (or whatever is appropriate :) | 20:03 |
| jdstrand | niemeyer_: since we're on the topic of shm, I have an unrelated to pulse or that other PR question. this is on bug #1577514 | 20:04 |
| ubottu | bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed] https://launchpad.net/bugs/1577514 | 20:04 |
| jdstrand | ShR3K: I can summarize | 20:04 |
| jdstrand | err | 20:04 |
| jdstrand | ShR3K: nm | 20:04 |
| jdstrand | niemeyer_: I can summarize | 20:04 |
| niemeyer_ | jdstrand: Which one? | 20:04 |
| niemeyer_ | jdstrand: Sorry, I mean.. reopened which one? | 20:05 |
| jdstrand | niemeyer_: the chromium content api has a hardcoded path of /run/shm/.org.chromium.Chromium | 20:05 |
| jdstrand | niemeyer_: lemme get you that | 20:05 |
| jdstrand | oh, hmm | 20:06 |
| jdstrand | gimme a sec | 20:06 |
| * jdstrand can't find it any more | 20:07 | |
| jdstrand | oh, someone committed it | 20:07 |
| jdstrand | heh | 20:07 |
| jdstrand | I didn't see the email | 20:07 |
| jdstrand | niemeyer_: nm! :) | 20:07 |
| niemeyer_ | jdstrand: It's in, isn't it? :) | 20:08 |
| niemeyer_ | jdstrand: Ok, so the chromium case.. what's the trick there? | 20:08 |
| jdstrand | https://github.com/ubuntu-core/snappy/pull/1135 | 20:08 |
| jdstrand | yes, you merged it ^ | 20:08 |
| jdstrand | thanks! | 20:08 |
| * jdstrand will have to check his filters on why he didn't see the email | 20:09 | |
| jdstrand | niemeyer_: ok, on to chromium | 20:09 |
| jdstrand | niemeyer_: so, chromium is hard-coding .org.chromium.Chromium | 20:09 |
| niemeyer_ | Ok, I've read some of the content in the links you provided above | 20:09 |
| jdstrand | that doesn't fit snap.<name>. of course | 20:09 |
| jdstrand | and I'm not sure how to solve that | 20:10 |
| jdstrand | chromium content api is a bear to build | 20:10 |
| jdstrand | so asking people to patch for s/.org.chromium.Chromium/snap.<name>./ seems onerous | 20:11 |
| jdstrand | we could patch our stuff | 20:11 |
| jdstrand | (eg, oxide) | 20:11 |
| jdstrand | but then electron wouldn't be fixed | 20:11 |
| niemeyer_ | jdstrand: The problem I see with adding to existing interfaces is that we'd have to do one of two things: | 20:11 |
| niemeyer_ | 1. Allow anyone access to .org.chromium* | 20:11 |
| niemeyer_ | 2. Allow only a single snap access to it | 20:12 |
| niemeyer_ | Both sound bad | 20:12 |
| niemeyer_ | The first means snaps can read each other, so we're doing much really | 20:12 |
| jdstrand | the only thing I can think of is allowing /run/shm/.org.chromium.Chromium.*, but that is imprecise and is not app-specific | 20:12 |
| niemeyer_ | The second means we have system-wide per snap rules, which is pretty bad | 20:12 |
| niemeyer_ | jdstrand: Where is that path defined, and how is it used? | 20:13 |
| jdstrand | niemeyer_: hard coded in the source | 20:13 |
| niemeyer_ | jdstrand: Of every single app, or of chromium proper only? | 20:13 |
| jdstrand | niemeyer_: I believe it is used to coordinate between the renderer process and the 'chrome' (outer process) | 20:14 |
| niemeyer_ | jdstrand: So it's internal only, rather than a way to share | 20:14 |
| niemeyer_ | (share across snaps) | 20:14 |
| jdstrand | niemeyer_: anything that uses the chromium content api. so, our webview, our webbrowser-app, kde's webcontent thingie, opera, electron apps, etc | 20:15 |
| niemeyer_ | jdstrand: Across them, or internally to them? | 20:15 |
| jdstrand | niemeyer_: it is intended as internal only, yes and chromium is coded such that it uses a tmpfile style (ie, its defensively coded) | 20:15 |
| jdstrand | niemeyer_: internally | 20:15 |
| niemeyer_ | jdstrand: Okay, so I think the easiest is LD_PRELOAD + /dev/shm/snap.$SNAP_NAME.* | 20:16 |
| jdstrand | ie, our webbrowser-app by using chromium content api create /run/shm/.org.chromium.Chromium.XXXXXX | 20:16 |
| jdstrand | wel | 20:16 |
| jdstrand | we could actually | 20:16 |
| jdstrand | but chromium uses open() not shm_open | 20:17 |
| jdstrand | so we'd LD_PRELOAD open(), which we could do, but since we'd be doing a string match on the path (if path starts with .org.chromium.Chromium.* then use snap.<name>) | 20:18 |
| jdstrand | but that feels kinda icky to do with open() | 20:18 |
| jdstrand | I mean, open() is used in just a few places :) | 20:18 |
| niemeyer_ | jdstrand: No strong emotions on my side :) | 20:18 |
| jdstrand | I wonder about the performance impact... | 20:19 |
| jdstrand | but it can be explored | 20:19 |
| niemeyer_ | jdstrand: Very hard to believe | 20:19 |
| niemeyer_ | jdstrand: We're talking about a couple of long jumps that are about to go into a freaking syscall | 20:19 |
| niemeyer_ | jdstrand: The CPU delays are most probably completely irrelevant compared to the cost of the syscall | 20:20 |
| jdstrand | I'm happy to summarize this conversation in the bug and followup with zyga, who I think already has an implementation for shm_open | 20:20 |
| jdstrand | niemeyer_: I think that's it | 20:21 |
| niemeyer_ | jdstrand: Sweet, looks optimistic! :) | 20:22 |
| jdstrand | indeed! | 20:22 |
| ssweeny | jdstrand, niemeyer_ I've pushed up the location-observe rename. I can add the -control interface to this branch tomorrow or to a later merge | 20:22 |
| jdstrand | niemeyer_: you might be interested in https://bugs.launchpad.net/snappy/+bug/1583514/comments/1 | 20:23 |
| ubottu | Launchpad bug 1583514 in Snappy "firewall-control and ip[6]table_filter module loading" [Medium,Confirmed] | 20:23 |
| niemeyer_ | jdstrand: Ah, there's also the cups interface | 20:23 |
| niemeyer_ | ssweeny: Looking | 20:23 |
| jdstrand | oh right | 20:23 |
| jdstrand | the cups one scares me as is | 20:23 |
| niemeyer_ | ssweeny: This was just the rename.. is closing it down to actually only observe quick? | 20:24 |
| niemeyer_ | ssweeny: If so we can probably get it in imminently | 20:25 |
| niemeyer_ | ssweeny: Otherwise I need to leave soon | 20:25 |
| ssweeny | niemeyer_, already removed the properties stanzas | 20:26 |
| ssweeny | they aren't necessary for clients | 20:26 |
| * jdstrand notes that location also needed zyga's comment | 20:27 | |
| niemeyer_ | ssweeny: Hmm.. shold Get be there, though? jdstrand? | 20:27 |
| jdstrand | I think Get is fine. there is nothing sensitive there | 20:28 |
| ssweeny | niemeyer_, clients work without it | 20:28 |
| niemeyer_ | ssweeny: Can we please get Get back? | 20:28 |
| jdstrand | so either way is ok | 20:28 |
| ssweeny | niemeyer_, I can do that | 20:28 |
| niemeyer_ | ssweeny: Thans! | 20:28 |
| niemeyer_ | ks! | 20:28 |
| jdstrand | thomi: that answer means the problem is in snapcraft which I think means either s3rgiusens or kyrofa | 20:29 |
| jdstrand | niemeyer_: did you see my scary comment regarding cups? | 20:30 |
| niemeyer_ | jdstrand: Yeah, I like your idea of having it as cups-control | 20:31 |
| thomi | jdstrand: ok, thanks. | 20:31 |
| jdstrand | niemeyer_: note that it is also possible to do the exact same thing with cups as pulseaudio. the problem would be finding all correct mediation points in software that gets a lot of CVEs... | 20:34 |
| jdstrand | I think cups-control is the fastest option. I can also adjust snappy-debug to mention ipp:localhost:631 if trying to use the socket so developers have the option to update their code | 20:35 |
| jdstrand | the nice thing about pulseaudio it it seems to have a decent hooks interface. cupsd does not | 20:36 |
| jdstrand | anyhoo | 20:36 |
| ssweeny | niemeyer_ pushed with those stanzas back in | 20:38 |
| niemeyer_ | ssweeny: The comment is wrong.. (sorry, but since we're at it) | 20:41 |
| ssweeny | gah | 20:41 |
| ssweeny | niemeyer_ fixed | 20:42 |
| niemeyer_ | ssweeny: I need to step out now anyway, and we need to let those tests run.. I'll have a look again when I'm back and if it's all green, it'll be merged | 20:42 |
| ssweeny | niemeyer_ sounds good. Thanks! | 20:43 |
| niemeyer_ | ssweeny: Thanks a lot for this and for all the great work you've been doing on interfaces. Seriously appreciated. | 20:43 |
| mmstick | Are Rust projects supported by Snappy? | 20:43 |
| zyga | niemeyer_: based on the conversation, since apparmor is additive I think there is no problem anymore | 21:15 |
| * zyga still goes through backlog | 21:18 | |
| qengho | Man, I wish "snap" were more resilient to my control-c's. | 21:34 |
| jdstrand | niemeyer_: please comment if I didn't get the summary right: https://bugs.launchpad.net/snappy/+bug/1577514/comments/2 | 21:47 |
| ubottu | Launchpad bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed] | 21:47 |
| jdstrand | tyhicks: fyi, I think I need to bump up the priority of the review tools 'confinement' check since I'm seeing PRs and landings related to this in other areas | 22:01 |
| * jdstrand bumps it and queues for tomorrow | 22:02 | |
| tyhicks | jdstrand: ack - seems reasonable as the surrounding work is moving fast | 22:02 |
| * jdstrand nods | 22:02 | |
| jdstrand | with weekly snapd SRUs, I'm thinking there isn't the 3 weeks time initially thought | 22:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!