| === JanC is now known as Guest15498 | ||
| === JanC_ is now known as JanC | ||
| example6 | My snap is unable to create files inside its directory in /apps despite its directory having access to anyone. Is there some sort of method I should be following to give it its own directory in a more writable space? | 01:13 |
|---|---|---|
| example6 | I changed ownership of it to root, that didn't seem to help. It seems to be root who's running my program | 01:16 |
| example6 | Would this be something to do with apparmor? | 01:33 |
| jdstrand | example6: /apps is readonly. you have to use the writable directory in /var. Since you said /apps, I'm going to assume you are on 15.04, therefore the writable directory is in /var/lib/apps. you can look at $SNAP_APP_DATA_PATH in your environment to see the precise directory to use | 01:41 |
| jdstrand | example6: if you are actually on 16.04, the readonly directory is in /snap and the writable in /var/snap and you use $SNAP_DATA in your environment | 01:42 |
| * jdstrand was just passing through | 01:42 | |
| jdstrand | hope that helps! :) | 01:42 |
| example6 | jdstrand: that helps a ton! Thank you! Do you have any advice on copying my program to /var/lib/apps after installation? it's basically a script that runs a program that creates a few files in the same directory | 01:47 |
| example6 | I noticed some of the demos (which don't properly start as services most likely since I am indeed on 15.04) had things like var, lib, bin, etc in side their snap/ directory | 01:47 |
| jdstrand | example6: you got me before I walked away :) I did something similar in my ufw snap (snappy install ufw.jdstrand). basically, you copy what you need over into /var/lib/apps from /apps. this can be done be a wrapper script that after the copy, runs the real script | 01:49 |
| jdstrand | s/be a/by a/ | 01:50 |
| jdstrand | example6: though it might be easier to adjust that program to take an optional argument to output to $SNAP_APP_DATA_PATH | 01:51 |
| jdstrand | --outdir=$SNAP_APP_DATA_PATH (or similar) | 01:52 |
| jdstrand | ok, really gotta run, good luck! :) | 01:52 |
| example6 | thank you! | 01:52 |
| liuxg | I just tried snappy app calculator on Ubuntu 16.04. However, I cannot find the app in the ubuntu store app. what is the problem for it? https://developer.ubuntu.com/en/desktop/get-started/ | 02:34 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| swami | can someone help me with a question on device tree/dtb/fdt on rpi2? | 06:49 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| liuxg | I have tried to develop a snappy app for my desktop. every time, when the app is installed, a new version is installed. when I remove it, it only removes the recent one. now the directory is full of different version of the snap app. how can I remove the previous versions of the app. it occupies a lot of space. | 07:50 |
| shuduo | kgunn: hi, i'm following the guide https://goo.gl/4nmG93 to build mir demo. but snapcraft-mir-client building output error like "[Errno 2] No such file or directory: '/home/shuduo/work/snappy/mir- | 07:55 |
| shuduo | demo/snapcraft-mir-client/parts/environment/build/snappy-qt5.conf' | 07:55 |
| liuxg | how to delete a snap on ubuntu 16.04? | 09:38 |
| liuxg | I have tried to use "sudo snapp remove app_name". however, it does not remove the previous versions of the snap apps installed on the system. | 09:38 |
| zyga | sergiusens: I would love to have easy access to all debugging symbols | 10:11 |
| zyga | quick break while pulseaudio is building | 10:12 |
| blackout24 | Trying to gain some knowledge on the different commands (snap and snappy). When I download an Snappy Ubuntu Core image and run it in KVM it has the snappy command, which seems to handle more than just the packaging (configures the bootloader). "snappy" has an update command, but on 16.04 there is only the "snap" command and it doesn't look like there is "snap update". | 11:00 |
| blackout24 | What are the roles of these two applications? | 11:00 |
| zyga | blackout24: snappy is the old command that is removed in 16 and 16.04 | 11:02 |
| blackout24 | ahh thanks | 11:03 |
| zyga | blackout24: snap is the replacement that uses the REST api (snappy had everything linked in) | 11:03 |
| zyga | blackout24: update is now called refresh | 11:03 |
| blackout24 | When 16.04 downloads a new ubuntu-core snap will it mess with the bootloader? Because 16.04 isn't a snappy system. | 11:03 |
| zyga | blackout24: no | 11:04 |
| zyga | blackout24: snappy differentiates between core and classic systems | 11:05 |
| blackout24 | I have ported snappy to Arch Linux and everything works, but when it downloads the ubuntu-core image when I try to install the calculator-app it complains that it can't determine the bootloader. How can I tell snap that I'm on a classic system and it should only install it as a framework. | 11:05 |
| zyga | blackout24: ah, in that case you need to patch the source a little, in the past (2.0.2 release) we checked for dpkg status file, now there's a method (I need to check which) that checks this | 11:06 |
| zyga | blackout24: I think it should be easy to tweak that to understand arch as well | 11:06 |
| zyga | blackout24: I can help you out in a moment, just need a second to test something I'm hacking on now | 11:09 |
| zyga | blackout24: look at release/ look for onClassic | 11:10 |
| zyga | blackout24: I'm sure we will gladly take patches to detect arch there | 11:11 |
| blackout24 | Right now I just pull the 2.0.2 snapd deb file from archive.ubuntu.com and "ar p *.deb data.tar.xz | tar -Jxf -C targetdir" the whole thing in a PKGBUILD. I could also let it build the latest Go sources from github and only extract the systemd unit files from snapd deb. | 11:11 |
| zyga | blackout24: no that won't work, you really need to rebuild it with a patch | 11:11 |
| zyga | it behaves differently on classic and on all-snap system | 11:11 |
| blackout24 | ok | 11:11 |
| zyga | blackout24: and get master | 11:11 |
| zyga | blackout24: (no point in using 2.0.2) we SRU regularly so working on latest version is the best way | 11:12 |
| * zyga back to hacking | 11:12 | |
| blackout24 | Great thanks. I also wanted to see if I can tweak snapcraft to use pyalpm to check if the build-tools and dependencys are installed on an Arch system. | 11:14 |
| zyga | blackout24: for that look at sergiusens | 11:15 |
| zyga | blackout24: I can help you out with snappy | 11:16 |
| zyga | jdstrand: hey, I have some good and some bad news | 12:18 |
| jdstrand | zyga: hey | 12:20 |
| jdstrand | and here I was trying to sneak in early to get some stuff done... | 12:20 |
| zyga | hehe | 12:20 |
| zyga | jdstrand: I got pulseaudio on classic to work | 12:20 |
| zyga | jdstrand: but this doesn't solve the bigger shm_open problem | 12:21 |
| jdstrand | what did you do to get pulseaudio on classic to work? | 12:22 |
| zyga | jdstrand: http://paste.ubuntu.com/16236835/ | 12:22 |
| zyga | surprisingly little | 12:22 |
| zyga | no other changes required | 12:22 |
| jdstrand | ok, yeah | 12:22 |
| jdstrand | that is what I figured it would look like | 12:22 |
| zyga | jdstrand: connect is in the base profile I think, I can remove it | 12:22 |
| zyga | jdstrand: now what is interesting is how pulseaudio would work as a snap itself | 12:23 |
| zyga | e.g. would it still be +owner /run/user/*/pulse/native rw, | 12:23 |
| jdstrand | right | 12:23 |
| zyga | (i doubt that) | 12:23 |
| jdstrand | this is where I was talking about the dichotomy of classic vs core | 12:23 |
| zyga | still, I think this is better than nothing, I'll iterate to reject pulseaudio slots for now | 12:23 |
| jdstrand | and the policy being different | 12:23 |
| zyga | and propose this, it unlocks a lot of nice apps today | 12:24 |
| zyga | and we can add slot support later | 12:24 |
| jdstrand | zyga: this is exactly the policy I was thinking should be in either unity7 or unity7-(pulse?)audio, etc | 12:24 |
| zyga | I think it's fine to have a pulseaudio interface | 12:24 |
| zyga | as a dedicated thing | 12:25 |
| jdstrand | I think it is completely fine to have a pulseaudio interface | 12:25 |
| jdstrand | for snaps | 12:25 |
| jdstrand | for snapped pulseaudio | 12:25 |
| zyga | we just need to think if the actual interface is portable, I think the only issues is /run/user socket | 12:25 |
| jdstrand | I'm very less sure about this | 12:25 |
| jdstrand | there's other stuff | 12:25 |
| zyga | if the socket was provided to the client as an attribute | 12:25 |
| zyga | yes? | 12:25 |
| jdstrand | there is a dbus socket iirc, something else | 12:25 |
| jdstrand | I can't recall everything. some are safe some are not | 12:26 |
| zyga | I'd start with one that just hands access to this socket | 12:26 |
| zyga | not to dbus (this app doesn't need dbus, it does sound like 90% of apps do) | 12:26 |
| zyga | I bet pulse has a rich interface but we don't have to support all the bells and whistles (e.g. one that would make the sound indaicator work) | 12:26 |
| zyga | indicator* | 12:26 |
| jdstrand | so this gets back to: are they separate interfaces (pulse for classic and pulse for core) or is it one named interface (pulseaudio) that will output different security policy if on a classic system vs core system | 12:27 |
| zyga | I think that different policy is okayt | 12:27 |
| zyga | different behavior is less okay (not okay) | 12:27 |
| jdstrand | I don't think we know that this will be for 90% of the apps | 12:27 |
| zyga | and this if we take a common subset and enforce that, a single interface is okay | 12:27 |
| zyga | jdstrand: 90% of apps just play sound | 12:27 |
| zyga | 10% also capture sound | 12:27 |
| zyga | 0.1 need to manage pulseaudio internals | 12:27 |
| zyga | ballpark numbers but that's realistic IMHO | 12:28 |
| jdstrand | did you know that 85% of statistics are made up on the spot? | 12:28 |
| zyga | exactly | 12:28 |
| jdstrand | :P | 12:28 |
| zyga | and mine fits | 12:28 |
| jdstrand | does it? | 12:28 |
| jdstrand | :) | 12:28 |
| zyga | look at it from another point of view, all apps on all mobile devices can play sound when they run | 12:28 |
| zyga | supporting that today is very easy and I think that's what we should do | 12:28 |
| zyga | supporting more is an open question that we don't have to solve now | 12:28 |
| jdstrand | we can take an opinionated view that to play sound you must use what is in the interface | 12:29 |
| jdstrand | but every time we take an opinionated view on classic, there is pressure to just allow it | 12:29 |
| zyga | I see what you mean, I think we will need to experiment some more | 12:29 |
| zyga | perhaps the real issue is the interface name | 12:29 |
| jdstrand | zyga: we have an audio policy on Touch that does that safely | 12:29 |
| zyga | perhaps we should require that the plugs have an attribute "basic" | 12:29 |
| zyga | or something like that that lets us do more later | 12:30 |
| zyga | is touch also using pulseaudio? | 12:30 |
| jdstrand | yes | 12:30 |
| zyga | does it differ because of no X, I know pulse uses X for some IPC | 12:30 |
| jdstrand | we call the policy group 'audio', but that is pulseaudio | 12:30 |
| jdstrand | I don't know anything about that | 12:30 |
| zyga | where can I look at the policy? | 12:31 |
| jdstrand | perhaps that is one of the different optional IPC mechanisms (like the dbus one) | 12:31 |
| jdstrand | zyga: http://bazaar.launchpad.net/~ubuntu-security/apparmor-easyprof-ubuntu/1.3-stable-phone-overlay/view/head:/data/policygroups/ubuntu/1.0/audio | 12:32 |
| zyga | thanks! | 12:33 |
| niemeyer | zyga: How does the pulse audio files look like under shm? | 12:35 |
| jdstrand | zyga: so, I don't particularly care if we use one interface name with two different policy or two interfaces names. I only care that the policy is appropriate on the target system. that said, once we make the decision, that's it, which is why I'm being cautious | 12:35 |
| jdstrand | and I don't have actual stats that the cli and dbus-socket (as opposed to native) aren't legitimately used on classic. on Touch we said "sorry, use 'native'". on classic, I worry someone is going to say "you need to make super important app FOO work and it needs 'cli'" | 12:36 |
| jdstrand | but again, if we export two different policies depending on the running system, fine | 12:37 |
| jdstrand | it is just we don't have that device introspection in the interface code today | 12:37 |
| jdstrand | though, one could argue that we are breaking our contract if when using 'pulseaudio' on classic you also get 'cli' where on core you don't | 12:38 |
| sergiusens | blackout24 so you want to use pyalm as build-packages/stage-packages? Look at snapcraft.internal.repo to start out | 12:39 |
| jdstrand | perhaps an attribute could help there... but I'm not sure what that would look like | 12:39 |
| zyga | niemeyer: pulse-shm-$random-number | 12:39 |
| sergiusens | good morning | 12:39 |
| jdstrand | niemeyer: it would be much nicer for a pulse snap to use pulse-shm-snap.foo.$random-number (or similar) | 12:40 |
| jdstrand | then we can have /dev/shm/pulse-shm-snap.@{SNAP}.* rwk, | 12:41 |
| niemeyer | jdstrand: How's that better than /dev/shm/${SNAP}.*? | 12:41 |
| jdstrand | that would work too | 12:42 |
| jdstrand | I think that falls into (or similar) | 12:42 |
| zyga | niemeyer: I think the question we should be asking is if we should expect to patch applications in any way or not | 12:42 |
| zyga | niemeyer: if the answer is yes then we can have a nice policy and sensible values everywhere | 12:42 |
| zyga | niemeyer: if the answer is no, it's complicated | 12:42 |
| jdstrand | I betting the client doesn't need patching | 12:42 |
| jdstrand | I'm | 12:42 |
| jdstrand | because it is a random number | 12:42 |
| niemeyer | jdstrand: Hm? | 12:43 |
| jdstrand | it is probably talking on the native interface and the server says-- here, use this thing (whether by fd or something else) | 12:43 |
| zyga | jdstrand: the server probably passes the filename via the socket | 12:43 |
| jdstrand | and so the client doesn't care what the file name is. I'm am guessing that is how it works | 12:43 |
| zyga | jdstrand: though pulse is complex, I bet there are many options thre | 12:43 |
| jdstrand | zyga: yes, that is what I'm saying | 12:43 |
| jdstrand | so in theory, the pulse snap could be patched | 12:44 |
| zyga | jdstrand: I was just highlighing the filename vs fd | 12:44 |
| zyga | jdstrand: the other thing to note is the socket itself | 12:44 |
| zyga | as in where it is | 12:44 |
| jdstrand | we could even SRU a patch so that classic does the same thing | 12:45 |
| jdstrand | perhaps the SRU would look at the security label of the connecting application and only do it for clients whose label starts with 'snap.' | 12:45 |
| jdstrand | anyhoo | 12:46 |
| zyga | jdstrand: can apparmor/seccomp do something about connections over unix sockets? | 12:46 |
| zyga | jdstrand: e.g. constrain connect | 12:46 |
| jdstrand | zyga: the socket itself is going to need to be known by the clients | 12:46 |
| jdstrand | yes | 12:46 |
| davidcalle | sergiusens: kyrofa: developer.ubuntu.com is now syncing snapcraft docs with github every 2h \o/ | 12:46 |
| jdstrand | we have unix mediation | 12:46 |
| jdstrand | though not for file backed sockets | 12:47 |
| jdstrand | this is a named socket so we only have file rules | 12:47 |
| zyga | ah | 12:47 |
| zyga | I see | 12:47 |
| sergiusens | davidcalle \o/ | 12:47 |
| jdstrand | (we'll get full unix mediation semantics for named sockets with future work) | 12:47 |
| * sergiusens checks | 12:48 | |
| zyga | jdstrand: I was thinking about patching pulse server but then there are other apps, I don't know how the socket is located today, is that hardcoded somewhere or is that passed by IPC we don't see | 12:48 |
| zyga | jdstrand: but perhaps that is not needed | 12:48 |
| jdstrand | zyga: I think this is like mir-- there is a known location and that's ok | 12:48 |
| zyga | jdstrand: on classic the /run/users socket is okay | 12:48 |
| zyga | jdstrand: on snappy we could just make a different policy | 12:48 |
| zyga | jdstrand: on classic pulse runs as the user | 12:49 |
| jdstrand | on core I think we're going to need to let the permanent connected slot to need to use a well-known path | 12:49 |
| zyga | jdstrand: so that's another complication | 12:49 |
| jdstrand | that was a poorly contructed sentence | 12:49 |
| zyga | jdstrand: at the end of the story we should check if a snap like paplay can work on classic and core | 12:49 |
| jdstrand | zyga: on Personal, it will run as the user too | 12:49 |
| zyga | jdstrand: but perhaps not on core | 12:49 |
| zyga | jdstrand: it couldn't today, right? | 12:49 |
| niemeyer | I'm honestly a bit lost on the conversation by now | 12:50 |
| zyga | jdstrand: service == root | 12:50 |
| jdstrand | zyga: Personal is going to need a lot of work. that would be of session services | 12:50 |
| zyga | niemeyer: sorry, we're brainstorming what possiblities exist and what implications they might have now, this is specific to pulse, not to shm_open | 12:50 |
| zyga | is there anyone working on pulseaudio snap for core today? | 12:51 |
| niemeyer | zyga: Understood, but I'm kind of missing the high-level conversation we should have | 12:52 |
| jdstrand | niemeyer: for the record, I'm completely fine with /dev/shm/${SNAP}.* as that keeps things isolated. if we feel this is a good thing generally, I can propse a change | 12:52 |
| niemeyer | zyga: What are the constraints for that design | 12:52 |
| jdstrand | niemeyer: that may not help pulse and chromium, but it provides a general 'do this and it will work' mechanism | 12:52 |
| zyga | I agree with jdstrand's opinion on this | 12:52 |
| zyga | we can always poke holes with specific interfaces, shouldn't stop us from sane defaults | 12:53 |
| zyga | not thet the very subtle path that jdstrand proposed does not have subdirectories under /dev/shm as that would not work | 12:53 |
| jdstrand | zyga: re who is working on it> no, but it is on the list from phonedations, after bluez, nm, location-service and ofono/modemmanager | 12:53 |
| zyga | undrstood | 12:53 |
| jdstrand | according to I believe, morphis | 12:53 |
| zyga | niemeyer: quick question, would you be okay with a pulseaudio interface that works on classic only (like x11,unity7) and allows just plugs (no slots)? | 12:54 |
| niemeyer | jdstrand: So what is pulse audio trying to do that this would not work? | 12:54 |
| jdstrand | zyga: I could allow creation of both a snap-specific file patch and a snap-specific directory in /dev/shm so people are free to use that general mechanism without issues | 12:54 |
| zyga | jdstrand: except that shm_open rejects subdirectories | 12:55 |
| zyga | jdstrand: we could allow it but it would be non-trivial to use | 12:55 |
| jdstrand | niemeyer: pulseaudio server today does not conform to /dev/shm/${SNAP}.* | 12:55 |
| jdstrand | niemeyer: it could be made to do so both in a snap and in SRU | 12:55 |
| niemeyer | jdstrand: Ah, ok.. my underslying question was actually: do we know of cases that want to share those files? | 12:55 |
| jdstrand | zyga: right, which is why we allow *both*. one that is file for shm_open and one that is directory for people that use open() | 12:55 |
| zyga | jdstrand: that would work | 12:56 |
| jdstrand | but both are app-specific | 12:56 |
| niemeyer | jdstrand: app-specific or snap-specific? | 12:56 |
| zyga | 2016 and mksquashfs freezes my desktop session because scheduling sucks :/ | 12:56 |
| jdstrand | niemeyer: honestly, I do not. I was assuming they were client specific (not even session specific) since I see a bunch of them in my session | 12:56 |
| ogra_ | Stop using that hardware from 2004 | 12:57 |
| jdstrand | zyga: hrmm-- I see similar things :\ | 12:57 |
| ogra_ | :) | 12:57 |
| jdstrand | ogra_: I have an xps 13! | 12:57 |
| jdstrand | not the newest one, but still :) | 12:57 |
| ogra_ | The 2004 model ? | 12:58 |
| sergiusens | davidcalle looks good, I have a request already though ;-) Can we enhance the code snippets with pygments? | 12:58 |
| jdstrand | haha | 12:58 |
| * ogra_ grins | 12:58 | |
| jdstrand | no :) | 12:58 |
| jdstrand | 2014 iirc | 12:58 |
| ogra_ | yeah, same device here... | 12:58 |
| davidcalle | sergiusens: only if markdown has a way to specify language for code snippets | 12:58 |
| niemeyer | zyga: What did you find out with pulseaudio? | 12:58 |
| ogra_ | do we use xz for squashfs compression ? | 12:59 |
| niemeyer | zyga: When you allow it to use shm, but not other processes to see those files, what happened? | 12:59 |
| davidcalle | sergiusens: (or we come up with a custom tag, that works too) | 12:59 |
| jdstrand | niemeyer, zyga: ok, so, do we agree that I should modify the default policy to allow /dev/shm/${SNAP}.* for files and directories just because that is the correct way to handle shm_open() and open(), regardless of pulse, chromium, etc? | 12:59 |
| zyga | niemeyer: that pulseaudio on classic can be accomodated with a very simple interface, it needs to access a shared socket (per user) and files named /dev/shm/pulse-shm-* | 12:59 |
| zyga | jdstrand: +1 | 12:59 |
| zyga | jdstrand: pulse would work with a simple interface as described | 13:00 |
| niemeyer | jdstrand, zyga: Let's consider that for a little while before acting, please | 13:00 |
| zyga | jdstrand: chromium, I need to analyze still | 13:00 |
| zyga | standup! | 13:00 |
| jdstrand | niemeyer: all that is doing is saying: "the path we said you could use before (/dev/shm/snap/$SNAP/**) we undesrtand to be broken. here is something that will work for you. Next up, design pulseaudio interface (that may or may not comply with that)" | 13:01 |
| sergiusens | davidcalle the github extension of markdown does fwiw (and we are using it or were) | 13:02 |
| jdstrand | zyga: for pulse, if we are saying "native socket only for both core and classic" and we generate policy for /dev/shm/pulse-shm-* on classic and (perhaps) /dev/shm/$SNAP... on core, then I'm ok with one interface: pulseaudio | 13:03 |
| jdstrand | zyga: if we are going to entertain the dbus or cli pulse sockets, those need to be different interfaces/attributes | 13:04 |
| jdstrand | that way the default is always the native socket, but (if we decide to support it), you can request cli or dbus-socket | 13:04 |
| jdstrand | zyga: oh, and the native socket for the slot is at a well-known path | 13:05 |
| jdstrand | though, I think I prefer /dev/shm/snap.$SNAP... to /dev/shm/$SNAP... for namespacing | 13:06 |
| jdstrand | we could argue that point in the PR | 13:06 |
| kyrofa | Good morning | 13:07 |
| kyrofa | davidcalle, awesome!! | 13:07 |
| davidcalle | sergiusens, ok | 13:09 |
| jdstrand | zyga: in this manner, the contract is always the same for the native socket. we just may (or may not) use a different shm path | 13:09 |
| sergiusens | davidcalle hey, I love the fact that they are being updated though!!! \o/ | 13:10 |
| zyga | jdstrand: hmmm, I'm not sure I understand that correctly, would you mind expresisng that as a plug-side aa policy pseudo code? | 13:11 |
| zyga | jdstrand: I agree on /dev/shm/snap.$SNAP | 13:14 |
| zyga | jdstrand: $SNAP_NAME to be precise | 13:14 |
| jdstrand | zyga: if we say that the 'pulseaudio' interface uses 'native' socket by default, plug side for classic is what you pasted. plug side for core may drop /dev/shm/pulse-... and rely on only the general /dev/shm/snap.$SNAP (I say may cause let's see how things go with that snap). then, if at some future date someone wants the 'cli' or 'dbus-socket' pulseaudio sockets, we introduce an attribute or pulseaudio-{cli,dbus-socket} interfaces | 13:15 |
| zyga | jdstrand: I agree with that | 13:15 |
| jdstrand | zyga: in this manner, the default pulseaudio interface contract is consistent between classic and snap | 13:16 |
| jdstrand | which was my biggest concern | 13:16 |
| zyga | jdstrand: yes, that's very important | 13:16 |
| kgunn | shuduo: ah...thanks for the catch, i forgot to bzr add that file....added now, should work | 13:16 |
| zyga | jdstrand: and later on we can do pulseaudo-control interface or use attributes, depending on how things look like precisely | 13:16 |
| jdstrand | so if we're pressured to allow cli or whatever, we have a way forward that doesn't break apps (new interface or attribute) | 13:16 |
| jdstrand | exactly | 13:16 |
| jdstrand | ok, cool | 13:16 |
| jdstrand | I think we are in agreement on pulseaudio. I'd like to get to agreement on the paths in /dev/shm for the non-pulseaudio general case too though | 13:17 |
| jdstrand | since they are known to be broken | 13:17 |
| jdstrand | then we can look at chromium | 13:17 |
| jdstrand | oh | 13:17 |
| zyga | jdstrand: I think /dev/shm/snap.$SNAP_NAME.* | 13:18 |
| zyga | jdstrand: snap. as that makes it obvious what the culprit is | 13:18 |
| zyga | jdstrand: no .app as shm is an IPC mechanism and shold work within one snap directly | 13:18 |
| zyga | jdstrand: and .* to allow those random names | 13:18 |
| zyga | (to be precise . to termiante $SNAP_NAME * for the random stuff) | 13:19 |
| jdstrand | zyga: we talked a long time ago about the 'home-hidden' interface but I think that morphed into (the idea to have) an interface that allows requesting access to file/directory (eg, ~/.mozilla). that could be used for chromium | 13:19 |
| jdstrand | zyga: snap.> yes and makes sure a crafted snap name doesn't try to use a well-known path in /dev/shm | 13:19 |
| zyga | jdstrand: and we could also marry this with a patch to glibc | 13:20 |
| jdstrand | zyga: the whole time I was thinking snap.$SNAP_NAME.* since I figured apps within a snap might want to use shm however they want | 13:20 |
| zyga | jdstrand: to make shm_open() use $SNAP_NAME prefix transparently if SNAP_NAME is defined | 13:21 |
| zyga | jdstrand: _or_ let people use something like my runtime helper | 13:21 |
| jdstrand | that is a possibility | 13:21 |
| zyga | jdstrand: LD_PRELOAD or linked in | 13:21 |
| jdstrand | or they patch the code | 13:21 |
| jdstrand | yes, there are options for people | 13:21 |
| zyga | my helper is actually a nice bit that you can link in or preload and it just works :) | 13:21 |
| jdstrand | yeha | 13:21 |
| jdstrand | yeah | 13:22 |
| jdstrand | I guess that would be part of snapcraft? | 13:22 |
| jdstrand | you say, "I want snappy compliant paths in /dev/shm' in snapcraft.yaml and you get that? | 13:22 |
| jdstrand | that doesn't help static code, but that's ok. it is handy regardless | 13:23 |
| zyga | jdstrand: we can make that happen by magic with snapcraft | 13:23 |
| zyga | jdstrand: just stick it in | 13:23 |
| zyga | jdstrand: oooor | 13:23 |
| zyga | jdstrand: actually I have a interesting/cool idea | 13:23 |
| zyga | jdstrand: what if we had a magic LD_PRELOAD managed by the core snap itself | 13:24 |
| zyga | jdstrand: where we ship very conservative and non-invasive things like that | 13:24 |
| zyga | jdstrand: so when policy changes, it still works | 13:24 |
| jdstrand | that is an interesting idea. my conservatism says we may want to offer an opt-out though | 13:25 |
| zyga | sure | 13:25 |
| zyga | out is okay | 13:25 |
| zyga | jdstrand: offtopic, are you going to the sprint? | 13:26 |
| jdstrand | zyga: what did you think about the comment on the 'path interface' bit for chromium (which uses open()). is that 'path interface' still a thing? (I thought it was needed for things like ~/.mozilla, etc) | 13:27 |
| jdstrand | zyga: no. tyhicks will be there. I will be on irc though in my normal timezone | 13:27 |
| zyga | the path interface is an interesting idea, it's certainly a sprint topic, I was thinking about it from a different POV, .e.g. where you as a user can create a slice of $HOME, create a new slot, and connect it to some slots (typed home-slice perhaps) | 13:28 |
| zyga | jdstrand: how that might work for non-home directories, I don't know | 13:28 |
| jdstrand | zyga: so the spec for that interface is only for non-home? | 13:29 |
| jdstrand | err | 13:29 |
| jdstrand | only for home? | 13:29 |
| zyga | there's no spec yet, this was just some speculation | 13:29 |
| jdstrand | ok | 13:29 |
| zyga | jdstrand: I'd like to have one | 13:29 |
| zyga | jdstrand: it's a simple idea and would let us see how hooks work (it would have to be hook based) | 13:30 |
| jdstrand | yeah. my understanding is that it is a requirement | 13:30 |
| zyga | jdstrand: ok, let's wrap up shm_open and pulseaudio as agreed | 13:30 |
| zyga | jdstrand: I'll work on pulse now | 13:30 |
| zyga | jdstrand: I have a lovely snap that just work with this interface, I'd love to put it in the store | 13:30 |
| jdstrand | zyga: I can work on the generalized shm | 13:30 |
| zyga | jdstrand: brilliant, thank you | 13:31 |
| jdstrand | zyga: so, I have two simple PRs from yesterday but the intergration tests failed. I don't see how my code could have done that (especially the PR for doc changes :), but I can't see the integration test results to know what is happening | 13:32 |
| zyga | jdstrand: integration tests are broken now I think | 13:33 |
| zyga | fgimenez: ^^ are they? | 13:33 |
| zyga | jdstrand: if you connect to the VPN you can see the results | 13:33 |
| zyga | jdstrand: let's merge the doc changes after they get the second review | 13:34 |
| zyga | jdstrand: as for the other PR, I didn't review any yet | 13:34 |
| jdstrand | ack, thanks | 13:39 |
| jdstrand | zyga: for me at least, this pulseaudio discussion was really good. it solidifies concepts like interfaces contracts, classic vs core vs personal, how attributes might play a part, etc | 13:40 |
| jdstrand | which will inform future interface discussions | 13:40 |
| jdstrand | yes, FileNotFoundError in the jenkins output. seem broken | 13:42 |
| blackout24 | zyga, I changed the release.go code: https://github.com/timjp87/snappy/blob/master/release/release.go#L73 | 13:49 |
| blackout24 | Unfortunately I still get "Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)" | 13:49 |
| zyga | blackout24: you also need to patch ubuntu-core-launcher | 13:49 |
| blackout24 | ahhh | 13:49 |
| zyga | blackout24: though wait, where do you see that error? | 13:49 |
| zyga | blackout24: on snapd start up? snap install? when? | 13:49 |
| blackout24 | snapd install | 13:50 |
| blackout24 | I try to install the calculator | 13:50 |
| blackout24 | and it first fetches ubuntu-core | 13:50 |
| blackout24 | I cleaned my previous installation, which just used the precompiled 2.0.2 binaries from xenial and modified my PKGBUILD so that it pulls the source from github and applies the patch before building snap and snapd. | 13:51 |
| blackout24 | I also rebooted to make sure | 13:51 |
| zyga | blackout24: and the error showed up when? | 13:52 |
| zyga | blackout24: note that snapd also has a few systemd units you need | 13:52 |
| zyga | blackout24: you may want to look at those | 13:52 |
| zyga | blackout24: but I don't know arch really so I cannot help there | 13:52 |
| kgunn | shuduo: so it worked ok for you now? | 13:53 |
| zyga | sergiusens: could snapcraft be very conservative about .debs it downloads so snapcraft clean; snapcraft can reuse them, I still have to do snapcraft clean all the time and downloading debs over and over is the last big slowdown | 13:53 |
| niemeyer | blackout24: Please note we'd be happy to take those patches in | 13:53 |
| niemeyer | blackout24: Assuming you can make it all actually work | 13:54 |
| blackout24 | Thanks. Yes I installed the systemd units from the github.com repo into /usr/lib/systemd/system. Arch has everything in /usr instead of installing stuff to /lib. | 13:54 |
| blackout24 | They are the same that are listed as contents of the snapd package in 16.04 | 13:55 |
| zyga | blackout24: you will also need apparmor and seccomp | 13:55 |
| zyga | blackout24: and ubuntu-core-launcher actually working | 13:55 |
| shuduo | kgunn: i'm verifying on another laptop. will let me you later. maybe after 30 minutes. thanks. :) | 13:55 |
| blackout24 | That's what I wanted to find out if apparmor is a hard dependency | 13:55 |
| kgunn | nw, thanks for trying | 13:55 |
| zyga | blackout24: yes | 13:55 |
| zyga | blackout24: and seccomp as well | 13:55 |
| zyga | but that's hard not to have :) | 13:55 |
| zyga | blackout24: if you build ubuntu-core-launcher you're 90% closer to running snapd | 13:56 |
| blackout24 | zyga: There is an alternative kernel available with the apparmor patches. It's not maintained but should be possible to revive. | 13:56 |
| zyga | blackout24: you may also need kernel patches but I'll delegate that to some other folks | 13:56 |
| kgunn | zyga: you seem busy, but had a chance to try my fork and get the plug to connect? | 13:56 |
| sergiusens | zyga do snapcraft clean --step build | 13:56 |
| zyga | sergiusens: <3 thank you | 13:56 |
| zyga | kgunn: not yet, I'll do it today as I'm not going to be involved in UOS as much | 13:57 |
| kgunn | nw | 13:57 |
| blackout24 | Right now I only have the userland apparmor libraries installed. They are available through the AUR. | 13:57 |
| sergiusens | zyga also, you can most likely get away by using build packages instead of stage-packages in most cases | 13:57 |
| niemeyer | jdstrand: How fast can we ship a new glibc for 16.04? | 13:57 |
| sergiusens | blackout24 the ubuntu security team has some easy instructions to get different kernel versions patched | 13:58 |
| zyga | kgunn: how does mir use shared memory? | 13:59 |
| sergiusens | blackout24 maybe this can kickstart your work https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels | 13:59 |
| sergiusens | zyga heh, the shm question is being raised a lot now. I am happy to see this being brought up :-) | 13:59 |
| zyga | snappy will comb software into looking nice and uniform | 14:00 |
| * zyga does a poor man's job of snap try | 14:01 | |
| blackout24 | sergiusens, thanks | 14:01 |
| zyga | and ... wow, speedup :) | 14:01 |
| jdstrand | niemeyer: the new glibc for shm_open? | 14:01 |
| niemeyer | jdstrand: Yeah | 14:01 |
| zyga | niemeyer: to make shm_open() understand $SNAP_NAME and use it as prefix? | 14:03 |
| jdstrand | well, the hardest part would be convincing infinity, but I'm kinda liking zyga's LD_PRELOAD idea since that would work on any glibc system (eg, non-Ubuntu systems) | 14:04 |
| zyga | jdstrand: I'll refresh my preload library to do that | 14:04 |
| zyga | jdstrand: we can experiment with it while convincing infinity :) | 14:05 |
| jdstrand | zyga: well, but again, if we use your LD_PRELOAD library be default idea, there is no need to convince infinity. snappy can maintain those changes outside of SRUs and those changes propagate to other distros | 14:06 |
| jdstrand | s/be/by/ | 14:06 |
| zyga | hmmm | 14:06 |
| zyga | not needing it would feel nicer but I agree that it is a simplification | 14:06 |
| jdstrand | I can promise you upstream glibc won't take it, so then we have a permanent delta that we ask all other distros to incorporate | 14:06 |
| zyga | iff it is added by default by snapcraft | 14:06 |
| zyga | jdstrand: why won't they take it? | 14:07 |
| jdstrand | snapcraft or your snapd idea of by default | 14:07 |
| zyga | ah, right | 14:07 |
| camako | zyga, @how mir uses shared memory : It uses it for Mesa s/w clients. Mir client requests it, server allocates it, client renders to it, gives it back to the server, and server posts it on the display | 14:07 |
| jdstrand | have you worked with upstream glibc? | 14:07 |
| jdstrand | :) | 14:07 |
| zyga | jdstrand: no :) | 14:07 |
| jdstrand | go ahead, float this by infinity right now in #ubuntu-devel :) | 14:07 |
| zyga | camako: I'd like to know how it allocates shared memory and shares is across processes | 14:08 |
| zyga | jdstrand: isn't that guy who used to be grumpy off glibc maintenance now :) | 14:08 |
| jdstrand | but really, again, regardless of upstream, having this (and perhaps other things) in control of snapd/snapcraft might be better | 14:08 |
| zyga | jdstrand: yes, I agree on that | 14:08 |
| jdstrand | zyga: yes... :) | 14:08 |
| zyga | jdstrand: looking at how shm_open works, it's actually a bit sucky :/ it's easy to hack and change the directory, harder to convince glibc to just take a non-directory prefix... | 14:09 |
| zyga | gimme a sec | 14:09 |
| * sergiusens starts monitoring #ubuntu-devel with a bucket full of popcorn | 14:10 | |
| fgimenez | zyga, integration tests infra seem to be fine now | 14:11 |
| zyga | fgimenez: thank you | 14:11 |
| camako | zyga, it allocates using | 14:13 |
| camako | auto raw_fd = open("/dev/shm", O_TMPFILE | O_RDWR | O_EXCL | O_CLOEXEC, S_IRWXU); | 14:13 |
| camako | it maps using mmap | 14:14 |
| camako | zyga, it requires a kernel that supports O_TMPFILE | 14:15 |
| zyga | camako: thank you | 14:15 |
| camako | yw | 14:15 |
| zyga | jdstrand: ^^ | 14:15 |
| kgunn | camako: is same for android bins ? | 14:15 |
| zyga | jdstrand: that looks like not something glibc can "cure" | 14:15 |
| kgunn | vs mesa | 14:15 |
| camako | kgunn, not today but it could be | 14:16 |
| zyga | kgunn: who's doing the allocation? mir-server or mir-client? | 14:16 |
| camako | used for android in the future as well | 14:16 |
| camako | zyga, mir server does the allocation | 14:16 |
| zyga | camako: ahhh, even more interesting | 14:17 |
| fgimenez | zyga, np :) | 14:17 |
| camako | zyga, though also in the future we could use client allocated buffers as well... not today tho | 14:17 |
| zyga | camako: how does it share this with the client? | 14:17 |
| kgunn | camako: isn't server alloc'd buffs part of our security story tho | 14:17 |
| camako | through an IPC mechanism that dups the fd | 14:17 |
| camako | zyga ^ | 14:17 |
| zyga | camako: so the client side just gets the fd and mmaps it | 14:18 |
| camako | kgunn, yeah there may be issues... that's why it's not done yet | 14:18 |
| zyga | camako: no need for an open on the client side? | 14:18 |
| camako | zyga, correct | 14:18 |
| zyga | thanks | 14:18 |
| zyga | that's good and bad | 14:18 |
| zyga | the O_TMPFILE is something hard for us to support | 14:18 |
| zyga | I need to read how it works | 14:18 |
| camako | zyga, there is nothing magical about it, just that it was introduced in kernel > 3.18 | 14:19 |
| camako | zyga, we also have an alternate path for lesser kernels that uses " raw_fd = mkostemp(template_filename, O_CLOEXEC);" | 14:20 |
| jdstrand | zyga: fyi, there is a list of required kernel patches that ogasawara and others are putting together for snappy kernels | 14:20 |
| zyga | jdstrand, camako: it's not really as much as an old kernel, we just want to ensure snaps cannot create arbitrary names in /dev/shm | 14:21 |
| camako | zyga, but that leaves a temp file that we have to unlink. O_TMPFILE doesnt create anything in the filesystem | 14:21 |
| zyga | we'd prefer if they can be prefixed | 14:21 |
| zyga | oh | 14:21 |
| zyga | so there's no file at all? a | 14:21 |
| zyga | so that might just work (tm) | 14:21 |
| camako | zyga, correct | 14:21 |
| zyga | thanks! | 14:21 |
| zyga | that's much easier to support :) | 14:21 |
| jdstrand | well | 14:21 |
| jdstrand | there is probably an LSM hook for it | 14:21 |
| jdstrand | and that is probably going to be mediated as a file | 14:22 |
| jdstrand | I would ask ty hicks about that, but he is currently working on an emergency | 14:22 |
| jdstrand | maybe there isn't a hook (idk) | 14:23 |
| jdstrand | it's easy to see though | 14:24 |
| jdstrand | if you have a new kernel just try the code and see if it gets blocked | 14:24 |
| zyga | jdstrand: if we cannot confine it, is that a problem? | 14:25 |
| zyga | jdstrand: remember that we still confine the socket that is used to transport the fd | 14:25 |
| swami | can someone help on dtb/fdt/device tree issue on rpi2 with custom u-boot? | 14:25 |
| jdstrand | zyga: if there is no denial and no path then there should be no attack vector since another application shouldn't be able to get at the fd. this would also need ty hicks input | 14:27 |
| zyga | kgunn: I'll look at mir next, wrapping up this work | 14:27 |
| kgunn | sure | 14:28 |
| swami | during u-boot, after loading uboot.env, I m getting this error: "libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting!" | 14:31 |
| swami | but the printenv show fdt addr and file etc., any pointers, anyone please? | 14:31 |
| kgunn | just from another thread and discussion, and sorry if i missed this if already said, but is there a thought to make interfaces have versions? | 14:32 |
| kgunn | or should that be frozen per series at least? | 14:32 |
| kgunn | zyga: niemeyer ^ | 14:32 |
| zyga | kgunn: interface is like a binary protocol | 14:32 |
| zyga | kgunn: if you change it in an incompatible way | 14:32 |
| zyga | kgunn: it should be a new interface | 14:33 |
| kgunn | ok | 14:33 |
| kgunn | pmcgowan: ^ | 14:33 |
| zyga | kgunn: what is the current trend? is it constantly a new wire protocol? | 14:34 |
| pmcgowan | kgunn, so yes ;) | 14:34 |
| zyga | kgunn: another option would be to constrain the interface to a library and have the "mir client" share a .so for the other snap to open | 14:35 |
| zyga | kgunn: then the wire is irrelevant-ish | 14:35 |
| kgunn | zyga: i was wondering only in the context of sdk/uitk actually (brainstorming if interfaces would be used there) | 14:35 |
| pmcgowan | kgunn, I think the big difference vs what we do today is we cannot have one snap provide multiple interfaces | 14:35 |
| pmcgowan | whereas today one pile of bits is many frameworks | 14:36 |
| kgunn | right | 14:36 |
| pmcgowan | which is the potential issue depending on your viewpoint | 14:36 |
| zyga | kgunn: definitely, the only question is how, not if | 14:36 |
| kgunn | ;) | 14:36 |
| niemeyer | kgunn, zyga: Using a library just moves the same problem elsewhere | 14:36 |
| niemeyer | You now have a library ABI and the interface must change if that ABI breaks | 14:37 |
| zyga | niemeyer: yes that is true, just the question of which problem is easier to solve | 14:37 |
| niemeyer | zyga: Different answers for different developers | 14:37 |
| niemeyer | pmcgowan: Why can we not have one snap providing multiple interfaces? | 14:38 |
| pmcgowan | niemeyer, can we? | 14:38 |
| zyga | yes :) | 14:38 |
| niemeyer | pmcgowan: Yeah, multiple plugs, multiple slots | 14:38 |
| pmcgowan | ah then great | 14:39 |
| kgunn | so you can effectively version (meta-like) | 14:39 |
| niemeyer | pmcgowan: With the same interface or different interfaces | 14:39 |
| niemeyer | kgunn: We have unity7 today already | 14:39 |
| niemeyer | kgunn: We just don't have a field named "version" in the interface, and I don't think we should do that | 14:39 |
| kgunn | sure | 14:39 |
| niemeyer | We should try really hard not to break these interfaces, as it means we're breaking real software out there every time we do it | 14:39 |
| pmcgowan | indeed | 14:40 |
| niemeyer | When we do require the breakage, we need a new interface | 14:40 |
| niemeyer | A new interface is simply a new name from the user perspective, with a new definition from snapd's perspective | 14:40 |
| kgunn | right, it's just a reality with SDK...it will need to evolve/grow over time | 14:40 |
| niemeyer | kgunn: Of course, it's a matter of how long we stick to an interface, not whether we should break it or no | 14:40 |
| niemeyer | kgunn: Good software tends to be engineered so that its public runtime APIs do not break often | 14:42 |
| niemeyer | kgunn: The longer they last, the longer software remains working, the better for everybody | 14:42 |
| kgunn | niemeyer: sure, and i think pmcgowan's team doesn't change a crazy amount...but just needs a way to manage the breaks | 14:42 |
| kgunn | and seems like that's a decent answer | 14:42 |
| pmcgowan | kgunn, niemeyer what we do a lot of is add new APIs without breaking old ones | 14:42 |
| niemeyer | I'm not judging anyone.. this is a statement of desire :) | 14:42 |
| pmcgowan | so that sounds like multiple interfaces | 14:43 |
| niemeyer | pmcgowan: Depends.. | 14:43 |
| kgunn | pmcgowan: and even if you do break...you could run through a series with interface-old and interface-new, then drop -old in the next series | 14:43 |
| niemeyer | pmcgowan: Sometimes it's possible to introduce new features without breaking old logic and in a way that is introspectable | 14:45 |
| pmcgowan | true | 14:46 |
| shuduo | kgunn: mir-demo works great now. thanks. | 14:49 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/1133 | 14:50 |
| zyga | jdstrand: also https://myapps.developer.ubuntu.com/dev/click-apps/4989/rev/1/ ;) | 14:51 |
| zyga | jdstrand: if you want to try this out | 14:51 |
| jdstrand | ack | 14:52 |
| zzarr | hello! | 15:26 |
| zzarr | I'm new to snappy | 15:26 |
| zzarr | how does it work? | 15:27 |
| zzarr | I have a dragonboard 410c which I have booted snappy from a sdcard on | 15:27 |
| zzarr | I wish to install it to the emmc on the dragonboard, but I don't know how | 15:28 |
| zyga | re, sorry, system crashed hard when I unpluged an USB device :/ | 15:30 |
| zyga | jdstrand: I read your comment and I fully agree | 15:35 |
| zyga | jdstrand: thanks for teaching me more about apparmor details through the various comments :) | 15:35 |
| zyga | jdstrand: do you think SRU-ing pulseaudio is something we should get started with now (to restrict recording) | 15:35 |
| zyga | jdstrand: so that it can be ready when the next snappy SRU is out | 15:35 |
| jdstrand | zyga: I do, yes | 15:35 |
| jdstrand | zyga: that way they can just use pulseaudio playback and enjoy | 15:36 |
| tyhicks | zyga: did you get all of your answers regarding O_TMPFILE? | 15:36 |
| zyga | tyhicks: no, sorry, I got disconnected | 15:43 |
| tyhicks | zyga: what did you want to know about it? | 15:43 |
| zyga | tyhicks: hi btw :-) | 15:44 |
| tyhicks | zyga: hi :) | 15:44 |
| zyga | tyhicks: I think I just need to check now, I wasn't sure how O_TMPFILE worked, I heard that it doesn't even create an entry in the filesystem, just returns an fd | 15:44 |
| tyhicks | zyga: that's correct | 15:44 |
| zyga | tyhicks: does that mean the path argument is totally ignored? | 15:45 |
| tyhicks | zyga: from userspace's perspective, yes | 15:45 |
| tyhicks | zyga: the kernel uses the path to determine which filesystem's tmpfile() implementation should be used | 15:45 |
| zyga | tyhicks: from the kernel? will you get an apparmor deny if the process cannot write to /dev/shm | 15:45 |
| zyga | ah | 15:46 |
| * zyga intends to experiment with mir next so he'll find out for sure :) | 15:47 | |
| jdstrand | tyhicks: I wasn't sure apparmor would still mediate it as a path and if it didn't, is it possible for another process to get access to that fd? | 15:47 |
| jdstrand | tyhicks: sounds like zyga will blackbox the first question though :) | 15:48 |
| zyga | hehe | 15:48 |
| tyhicks | jdstrand: other processes can't get to that fd (unless the owning process passes the fd to another process) | 15:48 |
| tyhicks | I'll take a quick look to see if AA is going to mediate it | 15:49 |
| tyhicks | zyga: my biggest concerns about its usage are that it is only available in relatively new kernels and that not all filesystems support it | 15:50 |
| zyga | tyhicks: that's upstream problem to solve (mir) but from what I read above there is a fallback to another mechanism as well | 15:51 |
| tyhicks | zyga: aha! I was thinking that you were investigating its use in the launcher or something else internal to ubuntu core | 15:53 |
| jdstrand | tyhicks: right, that was my understanding (barring a kernel vulnerability of course) | 15:55 |
| tyhicks | jdstrand: the owning process can do some trickery in /proc/self/fd/ to link the fd back into the filesystem but AA mediation definitely comes into play at that time | 15:56 |
| jdstrand | tyhicks: so, if the server opened it and passed it to the client, are you saying the client can't pass it again? I thought it could (but that would trigger remediation) | 15:56 |
| jdstrand | revalidation* | 15:56 |
| tyhicks | jdstrand: I didn't intend to say that | 15:57 |
| jdstrand | (and this is just for clarification-- whether it can't pass or can pass with revalidation is fine from an isolation perspective) | 15:57 |
| tyhicks | jdstrand: it is just a regular fd and it can be passed around like any other fd | 15:57 |
| jdstrand | ok | 15:57 |
| jdstrand | the point is, if I have an fd, nothing can access it unless I give it to them | 15:58 |
| tyhicks | correct | 15:58 |
| jdstrand | cool, that is what I thought be wanted to be doubly sure :) | 15:58 |
| plars | elopio: fgimenez: Hi! I have the snap I build with your upstream tests pretty much up and running under checkbox now, but I hit a kernel bug yesterday on one of the tests, have you seen this? http://paste.ubuntu.com/16227643/ | 16:03 |
| zyga | ok, let's look at mir now | 16:05 |
| tyhicks | zyga, jdstrand: I just did a quick test and you do need appropriate permissions in the directory that you pass to open() when using O_TMPFILE | 16:09 |
| zyga | tyhicks: which level of permissions? | 16:09 |
| zyga | tyhicks: apparmor or filesystem | 16:09 |
| tyhicks | zyga: regular fileystem level permissions and apparmor | 16:09 |
| tyhicks | zyga: they're both checked | 16:10 |
| zyga | tyhicks: hmm, that's a bit annoying then, you need write permission for /dev/shm (apparmor) then? | 16:10 |
| tyhicks | zyga: yep | 16:10 |
| zyga | tyhicks: that's interesting/annoying then:) so mir slot will need "/dev/shm w," | 16:11 |
| zyga | right? | 16:11 |
| tyhicks | zyga: that's correct if they're passing O_WRONLY to open() | 16:12 |
| tyhicks | zyga: if they're passing O_RDWR, then "/dev/shm rw," will be needed | 16:12 |
| zyga | tyhicks: I believe the actual call is... | 16:12 |
| fgimenez | hey plars, nope, never saw that before | 16:12 |
| plars | fgimenez: maybe a fluke, but I wanted to capture what I could | 16:12 |
| zyga | tyhicks: camako: auto raw_fd = open("/dev/shm", O_TMPFILE | O_RDWR | O_EXCL | O_CLOEXEC, S_IRWXU); | 16:14 |
| zyga | so /dev/shm rw, | 16:14 |
| fgimenez | plars, yes, that concrete test is passing in the cloud instances with that same kernel snap version http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/2309/consoleFull | 16:14 |
| tyhicks | zyga: actually, looking at the kernel code, only write perms are checked even if O_RDWR is specified | 16:14 |
| tyhicks | that's kind of odd | 16:14 |
| zyga | tyhicks: in which way? | 16:15 |
| tyhicks | zyga: just that they're only checking for write perms in do_tmpfile() | 16:15 |
| zyga | ah | 16:15 |
| zyga | I though you meant the userspace code | 16:15 |
| tyhicks | zyga: anyways, be sure to double check my work and leave those rules out of the interface initially to see if it gets a denial | 16:16 |
| zyga | tyhicks: yep, that's sensible | 16:16 |
| zyga | tyhicks: which work do you refer to? | 16:16 |
| zyga | I only read your seccomp argument filtering patches | 16:16 |
| tyhicks | zyga: I was talking about my investigation into how O_TMPFILE is mediated | 16:17 |
| zyga | ah | 16:17 |
| tyhicks | zyga: double check it by leaving the rule out initially and see if you get a denial that looks like this: | 16:17 |
| zyga | sorry, I'm not parsing stuff correctly today :) | 16:17 |
| tyhicks | apparmor="DENIED" operation="open" profile="test" name="/tmp/#23739838" pid=12721 comm="test" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000 | 16:17 |
| zyga | yep | 16:17 |
| zyga | I'll do that | 16:17 |
| zyga | just setting up the environment now | 16:17 |
| tyhicks | zyga: note the name="/tmp/#23739838" part | 16:17 |
| tyhicks | zyga: I pass "/tmp" to open() | 16:18 |
| zyga | that #123 is not a real name right? | 16:18 |
| tyhicks | right | 16:18 |
| zyga | is that userspace or kernel making that | 16:18 |
| tyhicks | kernel | 16:18 |
| zyga | ok | 16:18 |
| tyhicks | ok, I need to tend to something else | 16:18 |
| tyhicks | let me know if you hit any issues | 16:18 |
| zyga | thanks for your help! | 16:18 |
| zyga | kgunn: ok, focusing on mir now | 16:18 |
| zyga | kgunn: is your pull request up to date? | 16:19 |
| kgunn | zyga: only have a fork, didn't do a pull request...but yes, it was sort of "best state" | 16:19 |
| zyga | kgunn: thanks, I'll take it :) | 16:19 |
| kgunn | i played around with moving from perma slot to connected slot...but still had no joy | 16:20 |
| zyga | kgunn: I think you shared the mir snap but do you have the link handy anywhere? | 16:20 |
| kgunn | i was trying to connect manually like snap connect mir-server:mir ubuntu-core:mir... | 16:20 |
| kgunn | zyga: https://code.launchpad.net/~mir-team/+junk/mir-server-snap | 16:20 |
| kgunn | and a wiki for all the other stuff | 16:21 |
| kgunn | https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ | 16:21 |
| blackout24 | If I use the current Arch Linux Kernel 4.5.1 as a template is it enough to just just flip some Kconfig switches to get apparmor and seccomp? The wiki here https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels mostly seems to be for old kernels. This would make packaging a custom kernel a lot easier. | 16:45 |
| blackout24 | I have the apparmor parser and libs and libseccomp packaged as well as ubuntu-core-launcher. | 16:45 |
| blackout24 | Only the kernel should be missing. | 16:45 |
| zyga | blackout24: try it | 16:54 |
| jdstrand | zyga: fyi, https://github.com/ubuntu-core/snappy/pull/1135 | 17:05 |
| zyga | mmm | 17:05 |
| zyga | just a sanity check, w there lets the snap mkdir /dev/shm/snap.foo.$anything// | 17:06 |
| zyga | ? | 17:06 |
| jdstrand | yep | 17:07 |
| jdstrand | I tested it | 17:07 |
| zyga | fantastic, thank you | 17:08 |
| jdstrand | http://paste.ubuntu.com/16242478/ | 17:08 |
| jdstrand | (that is within hello-world.sh) | 17:08 |
| zyga | hello world is a very useful tool :) | 17:08 |
| jdstrand | it is :) | 17:08 |
| zyga | I'll upload busybox snap ot the store | 17:09 |
| zyga | it's nice too and sometimes more powerful | 17:09 |
| kyrofa | blackout24, yeah it really depends on the current kernel config. The 96boards kernel only needed squashfs enabled: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ | 17:11 |
| kyrofa | zyga, where are we on some sort of hw-assign functionality with interfaces? | 17:14 |
| zyga | kyrofa: it's there but nothing is using it | 17:14 |
| zyga | kyrofa: an interface can hand out snippets of udev rules | 17:14 |
| zyga | kyrofa: note that hw-assign is not coming back | 17:14 |
| zyga | kyrofa: the assignable thing thould be a slot and a proper interface | 17:15 |
| zyga | kyrofa: what do you need to support? | 17:15 |
| kyrofa | zyga, right | 17:15 |
| kyrofa | zyga, the realsense camera | 17:15 |
| zyga | kyrofa: how is that exposed by the kernel? | 17:16 |
| zyga | kyrofa: note that it smells very much like something that won't happen before we have hooks | 17:16 |
| zyga | kyrofa: e.g. run hook to find realsense cameras | 17:16 |
| kyrofa | zyga, uvcvideo | 17:16 |
| zyga | kyrofa: you can prototype with an interface that tags a specific device along with an apparmor rule that lets it through | 17:17 |
| zyga | kyrofa: how does the app find it? | 17:17 |
| zyga | kyrofa: is it hard-coded/ | 17:17 |
| zyga | kyrofa: are you going to the sprint next week? | 17:18 |
| zyga | kyrofa: we could hack this together quickly | 17:18 |
| kyrofa | Yeah I am-- that'd be fun! | 17:21 |
| kyrofa | zyga, no, not hard-coded... it uses the kernel module somehow. Not too familiar with the lib, but I'll do some research | 17:21 |
| zyga | kyrofa: a strace of what it does is a good first step | 17:21 |
| blackout24 | Setting CONFIG_AUDIT and enabling Apparmor Kconfigs worked. apparmor status gives me: "apparmor module is loaded." seccomp support was enabled anyway. Still getting "Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)", though. Might have to do some print debugging to see if it sets the OnClassic variable correctly. | 17:41 |
| blackout24 | ubuntu-core-launcher is installed, too. Compiled it natively against libseccomp and libapparmor, which both also compiled natively and packaged. | 17:41 |
| blackout24 | I also added also the extra files that are present in the ubuntu packages that go to /etc etc. | 17:42 |
| ali1234 | kyrofa: was it you doing the "how to snap" demo yesterday? | 17:45 |
| kyrofa | ali1234, I was one of them, yes | 17:46 |
| ali1234 | the main one? the qt application? | 17:46 |
| kyrofa | ali1234, yeah, the qt app. The bearded one :) | 17:46 |
| ali1234 | answered many of my questions, thanks | 17:46 |
| kyrofa | ali1234, I'm happy to hear that! | 17:47 |
| ali1234 | had to drop out after your bit and missed the others | 17:47 |
| ali1234 | when is a good time to ask some follow up questions? | 17:47 |
| kyrofa | ali1234, now is fine | 17:47 |
| ali1234 | hmm okay... so regarding install rules etc | 17:48 |
| ali1234 | what does the layout inside the snap look like, to the application that is running? | 17:48 |
| ali1234 | like if my file needs /etc/foo.conf, where does that go inside the snap? or how do i adjust the paths in my code? | 17:48 |
| ali1234 | or say, /usr/share/myapp/somedatafile | 17:50 |
| kyrofa | ali1234, the layout of the snap doesn't look any different to an app in the snap than it does to you outside the snap | 17:52 |
| kyrofa | ali1234, i.e. /etc/foo.conf will try to reach out to /etc/foo.conf rather than the one in the snap | 17:52 |
| kyrofa | ali1234, for that particular example, your app should use the $SNAP environment variable to make sure it's grabbing stuff within the snap | 17:53 |
| ali1234 | so... how do i access datafiles that are staged and end up in the snap? | 17:53 |
| kyrofa | ali1234, do you remember when I installed the snap and a script was generated by snappy and placed in /snap/bin/ ? | 17:53 |
| kyrofa | ali1234, that script defines several environment variables that can be used by the application within the snap | 17:54 |
| kyrofa | $SNAP is one of them, which points back to the snap itself | 17:54 |
| ali1234 | and if upstream doesn't use it, then i have to patch it? | 17:54 |
| kyrofa | ali1234, well, that depends | 17:55 |
| kyrofa | ali1234, to give you an example from my experience, I was snapping software from upstream which by default uses /etc/my-configuration-file.conf | 17:55 |
| kyrofa | ali1234, however, that piece of software also had a command-line option for specifying the location of that file | 17:55 |
| ali1234 | ah.. so then the wrapper can handle it | 17:56 |
| kyrofa | ali1234, so all I had to do when snapping it was specify that flag in the `apps` section of my snapcraft.yaml | 17:56 |
| kyrofa | Right | 17:56 |
| ali1234 | neat | 17:56 |
| kyrofa | ali1234, but if your upstream doesn't have that type of functionality, things get more difficult | 17:56 |
| ali1234 | okay next question. you talked about wiki parts... how can i see a list of them all and what they do? | 17:57 |
| kyrofa | ali1234, in that case you either maintain a fork that uses $SNAP and friends, or perhaps try to contribute such a flag upstream | 17:57 |
| kyrofa | Ah, easy! | 17:57 |
| kyrofa | I shared this link during the talk: https://wiki.ubuntu.com/Snappy/Parts | 17:57 |
| kyrofa | You can see how each one is a little snapcraft snippet | 17:57 |
| ali1234 | yeah. | 17:58 |
| ali1234 | there's fewer than i expected :) | 17:58 |
| kyrofa | ali1234, add some! ;) | 17:58 |
| ali1234 | a gstreamer one would be nice | 17:58 |
| ali1234 | ...but | 17:58 |
| ali1234 | what i really need is the broadcom videocore libraries | 17:59 |
| ali1234 | that will probably be harder... they normally live in /opt/vc | 17:59 |
| kyrofa | Yeah I'm afraid I have no experience with those | 17:59 |
| ali1234 | i don't think they are even packaged in a deb anywhere | 18:01 |
| kyrofa | blackout24, I get that error on a livecd session... you're not doing that by any chance? | 18:02 |
| ali1234 | kyrofa: okay another question. i noticed you can specify build dependencies inside parts and also outside parts... why is that? | 18:03 |
| ali1234 | presumably it also works for stage packages? | 18:03 |
| kyrofa | ali1234, honestly I'm not quite sure-- there's really no difference | 18:03 |
| kyrofa | ali1234, no, stage packages are different | 18:03 |
| kyrofa | ali1234, build-packages aren't really part-specific, since they get installed on the host system | 18:04 |
| ali1234 | hmm | 18:04 |
| kyrofa | ali1234, whereas stage-packages become associated with the part in question | 18:04 |
| ali1234 | i thought it would build everything in a chroot or something | 18:04 |
| kyrofa | ali1234, no, unless you use cleanbuild which does it in an lxc | 18:04 |
| ali1234 | ah okay. so i should probably do that to make sure i didn''t forget about any build deps which i already had installed and forgot to add to the yaml? | 18:05 |
| kyrofa | ali1234, indeed, it would certainly catch those | 18:06 |
| blackout24 | kyrofa, no I ported snapd to Arch Linux. The OnClassic boolean is correctly set to true in release/release.go. I patched it to detect Arch and it works when I fmt.Println() it. | 18:06 |
| kyrofa | blackout24, haha, sweet | 18:07 |
| blackout24 | I'm using systemd-boot as bootloader, but I thought that with OnClassic as true it would just skip the bootloader check | 18:07 |
| qengho | "redhat", huh. | 18:07 |
| ali1234 | kyrofa: http://paste.ubuntu.com/16220152/ is what i got before i ran into the lack of vc libs, is there anything obviously wrong with that so far? | 18:07 |
| sergiusens | jdstrand hey, one thing I see about chrome is that it deletes the shm file "code-oss 8001 sergiusens 28u REG 0,21 4198400 46 /dev/shm/.org.chromium.Chromium.XElnLe (deleted)" | 18:07 |
| kyrofa | ali1234, no that looks pretty good actually | 18:08 |
| kyrofa | ali1234, however, once you get this working as you expect note that you might very well be able to do away with those stage packages | 18:08 |
| kyrofa | ali1234, do you remember when I was talking about the automatic library crawling? | 18:08 |
| ali1234 | yes, didn't know about that (i wrote this a couple of weeks ago) | 18:08 |
| kyrofa | ali1234, ah, okay. So that _should_ mean you don't need library-only stage packages | 18:09 |
| kyrofa | ali1234, but it's still fairly new | 18:09 |
| ali1234 | gstreamer does dynamic load plugins at run time... | 18:09 |
| ali1234 | and the camsrc part is actually a gstreamer plugin | 18:09 |
| kyrofa | ali1234, ah, you may need them then | 18:09 |
| kyrofa | Good catch | 18:09 |
| kyrofa | You were listening! | 18:10 |
| ali1234 | as well as the good/bad/ugly | 18:10 |
| ali1234 | okay i think that's all my questions, thanks | 18:11 |
| ali1234 | just need to solve this videocore stuff and i think i can handle the rest | 18:11 |
| kyrofa | ali1234, you know where we are if you have more questions! | 18:12 |
| pedronis | blackout24: no, there's a buglet such that we don't skip some bootloader manipulation on classic | 18:12 |
| jdstrand | sergiusens: yeah, I was aware of that | 18:13 |
| jdstrand | well, I remember that when looking at Touch | 18:13 |
| blackout24 | pedronis, so the problem most likely is that there is no systemd-boot support? | 18:13 |
| pedronis | there isn't indeed | 18:13 |
| pedronis | just grub/uboot | 18:13 |
| pedronis | anyway those bootloader manip on classic | 18:14 |
| blackout24 | I will see if I can work on that. | 18:14 |
| pedronis | shoudl go away | 18:14 |
| pedronis | in the next weeks | 18:14 |
| sergiusens | jdstrand oh shucks, I was wondering if that would lax the security requirements for it a bit :-) | 18:14 |
| jdstrand | sergiusens: well, it isn't so much about well-behaved code like chromium, it is about ill-behaved code that could take advantage of the shared access | 18:15 |
| qengho | "well behaved" | 18:16 |
| jdstrand | heh | 18:16 |
| jdstrand | well-intentioned? | 18:16 |
| qengho | +1 | 18:16 |
| sergiusens | jdstrand so I know where to patch chromium; the problem is having it make its way to all the forks | 18:17 |
| jdstrand | right, I undertand the problem | 18:18 |
| jdstrand | understand | 18:18 |
| jdstrand | sergiusens: but that path does not fit with snaps-- it assumes a differently designed system | 18:19 |
| example6 | Greetings everyone. I'm having trouble with my web server snap starting. When it starts it checks if a specified port is already in-use, and if it is, it quits and tries again. Currently I am able to run it perfectly fine on its own, but when run as a snappy service, it keeps failing, no matter what the port is. | 18:19 |
| jdstrand | sergiusens: I'm not saying we won't get something working for this case, just that it isn't obvious | 18:19 |
| sergiusens | jdstrand yeah, I understand the issue being on both sides | 18:20 |
| example6 | I suspect this could be due to systemd trying it again immediately but I could be wrong | 18:20 |
| example6 | It could also be some strange apparmor permission thing preventing it from taking up a port | 18:20 |
| example6 | I don't really know where to go from here, so any help would be greatly appreciated. | 18:20 |
| jdstrand | sergiusens: note that with the recent shm PR, you can create a file in /dev/shm rather than having to worry about a directory, etc | 18:20 |
| sergiusens | example6 have you plugged network-bind? | 18:20 |
| example6 | sergiusens, I haven't, I'll try that! | 18:21 |
| jdstrand | sergiusens: so the path is /dev/shm/snap.$SNAP_NAME.whatever_you_want | 18:21 |
| sergiusens | jdstrand yup saw the PR | 18:21 |
| jdstrand | that shoudl at least make the patch simpler | 18:21 |
| qengho | example6: And "dmesg" might be helpful next time. | 18:21 |
| jdstrand | but, still working through it. maybe we'll introduce another interface, not sure. I'm actually tasked with something else atm and will be circling back to these things, perhaps late next week | 18:22 |
| example6 | qengho, I did check dmesg but didn't see anything related | 18:22 |
| plars | elopio: ok, that test that hits a kernel bug for me, but seems to work for you - I can make it work, but only if I run it by hand from *outside* the snap. When I try to run it from within the snap, I hit the problem. Maybe there's some permission/isolation issue here? (I did install with --devmode) | 18:23 |
| example6 | Is there any way to plug network-bind from package.yaml inside the actual snap? I haven't been able to get snapcraft.yaml to properly initialize the snap as a service | 18:25 |
| example6 | So i've just been using snappy build . | 18:26 |
| zyga | example6: package.yaml? | 18:26 |
| zyga | example6: are you using 16.04 or 15.04? | 18:26 |
| example6 | 15.04 | 18:26 |
| zyga | example6: there are no interfaces in 15.04 | 18:26 |
| kyrofa | example6, you should be able to make this work from Snapcraft. Can you pastebin the YAML you're trying to use? | 18:27 |
| zyga | kyrofa: ^^ 15.04 | 18:27 |
| kyrofa | zyga, yeah I know. Should still be able to get a service running in 15.04 :) | 18:27 |
| zyga | yep though not with plugs and slots :) | 18:28 |
| kyrofa | Right | 18:28 |
| zyga | blackout24: I think that what you are doing is extremely cool and useful! | 18:30 |
| example6 | I'd prefer not to have to udpate ubuntu-core at this point since some other things are depending on this format but from what it sounds like I might not have a choice... | 18:30 |
| zyga | come to the dark side, we have cookies and plugs and interfaces | 18:30 |
| kyrofa | example6, you don't need to. We're happy to help you with 15.04 stuff, assuming what you're trying to do is possible of course | 18:31 |
| kyrofa | example6, did you refer to examples when building your snapcraft.yaml? Maybe this one: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/shout/snapcraft.yaml ? | 18:31 |
| blackout24 | zyga, thanks. It's also seems like a good way to sharpen my Go skills. I like Go very much. | 18:32 |
| example6 | Yes I did, but I need this to run as a service, and daemon: service wasn't having it start at all | 18:33 |
| kyrofa | example6, can you pastebin your YAML? Happy to help | 18:33 |
| example6 | Sure, one sec | 18:33 |
| kyrofa | example6, you're probably suffering from the fact that most of our public-facing documentation is on Snappy 16, not 15.04 | 18:34 |
| kyrofa | example6, so you need to make sure you're referring to examples compatible with 15.04 | 18:34 |
| example6 | The snapcraft.yaml is _very_ simple, I'm just using the Makefile to copy some scripts and premade executables into place and then a wrapper to start them: http://pastebin.com/ppgSnSSz | 18:36 |
| example6 | But this was pulled from 16.04 documentation I think, and I didn't find anything about using snapcraft that would work with our system | 18:36 |
| kyrofa | example6, indeed, that's a Snapcraft 2.x-compatible YAML | 18:37 |
| kyrofa | example6, try this: | 18:37 |
| example6 | I see now that the example you linked is different | 18:38 |
| kyrofa | example6, http://pastebin.ubuntu.com/16244497/ | 18:38 |
| === josepht` is now known as josepht | ||
| kyrofa | example6, indeed, notice that they're examples from Snapcraft 1.x rather than master | 18:39 |
| example6 | kyrofa: so that did indeed properly start it as a service. However, it's still failing to bind to any specific port | 18:53 |
| example6 | I did add plugs: [network, network-bind] to the service | 18:54 |
| example6 | But since it's 15.04 it doesn't support plugs apparently | 18:54 |
| kyrofa | Right, in 15.04 they're caps | 18:55 |
| kyrofa | example6, so try caps: [network-service] | 18:55 |
| kyrofa | example6, another example (with caps): https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/tomcat-maven-webapp/snapcraft.yaml | 18:57 |
| example6 | kyrofa, even with the caps it doesn't want to bind to 8080 | 19:06 |
| kyrofa | example6, what is the error? Care to pastebin your syslog? | 19:06 |
| example6 | Could this have any relation to my wrapper script copying the executables to /var/lib/apps/.... on the first run? | 19:07 |
| example6 | Sure | 19:07 |
| example6 | http://pastebin.com/XL7J02E5 | 19:08 |
| kyrofa | example6, huh. Have you verified that the specific port ISN'T in use? | 19:10 |
| example6 | Well, I've changed the port to any number of other arbitrary values | 19:11 |
| example6 | It just fails with the same message for the different port | 19:12 |
| sergiusens | zyga you should check for NULL as well https://github.com/zyga/snappy-runtime-helper/blob/master/snappy.c#L27 | 19:17 |
| kyrofa | example6, yeah I don't see any snappy-related issues there... | 19:18 |
| kyrofa | Those messages are coming from the service itself | 19:19 |
| kyrofa | And I don't see any denials or anything | 19:19 |
| sergiusens | dholbach https://github.com/seehuhn/moon-buggy/pull/2 or use my branch for better moon-buggy satisfaction :-0 | 19:20 |
| dholbach | very nice! :) | 19:21 |
| example6 | Hmm, okay. Thank you for all the help kyrofa. | 19:22 |
| sergiusens | dholbach 92kb and saves scores :-) | 19:22 |
| sergiusens | works in cleanbuild too ;-) | 19:23 |
| dholbach | nice | 19:23 |
| dholbach | very nice! :-) | 19:23 |
| example6 | Is it possible to add a service start/stop delay in snapcraft.yaml or should I just put a sleep in my wrappers? | 19:38 |
| example6 | In 15.04 to be exact | 19:38 |
| example6 | I'm having a problem now that my application is looking for a .hidden type folder in /root/ (*since it seems to be run by root) but AppArmor is denying this operation. Is there any cap I can reference to allow this? | 19:43 |
| === chihchun is now known as chihchun_afk | ||
| zyga | sergiusens: thanks! good point | 19:53 |
| === chihchun_afk is now known as chihchun | ||
| jdstrand | davidcalle: hey, I'm looking at https://developer.ubuntu.com/en/snappy/guides/ and the links under 'Snappy Internals' are all 404s | 20:09 |
| example6 | Hmm. well I solved the permission problem but it still doesn't want to bind to port 8080. | 20:14 |
| example6 | If my script is running from /var/lib/apps, does it get denied network access? | 20:14 |
| example6 | it doesn't say so in syslog | 20:15 |
| scherrey | Does snappy use systemd? | 20:33 |
| oparoz | scherrey, yes | 21:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!