mupPR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1043>00:35
mupPR snapcraft#1043 opened: tests: fix the CLA launchpadlib install in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1043>00:38
snappy_ircanybody know the localhost login details for ubuntu snap core ?01:10
snappy_ircI downloaded the ova from here http://cloud-images.ubuntu.com/snappy/devel/core/current/devel-core-amd64-cloud.ova?_ga=1.214375895.1790561723.148416245701:10
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
mupPR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1043>03:23
mupPR snapcraft#1044 opened: tests: use python2 to check the CLA <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1044>03:29
=== chihchun_afk is now known as chihchun
=== JanC is now known as Guest39941
=== JanC_ is now known as JanC
mupBug #1655834 opened: Support factory reset <Snappy:New> <https://launchpad.net/bugs/1655834>06:13
mupPR snapd#2544 closed: interfaces: implement login-control interface <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/2544>07:11
zygahey mvo07:49
mvohey zyga07:50
mupPR snapd#2554 closed: tests: add end-to-end store test for classic confinement <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2554>08:57
mupPR snapd#2605 closed: overlord,overlord/snapstate: have UpdateMany retire/enable auto-aliases even without new revision <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2605>08:57
mupPR snapd#2469 closed: interfaces: upower-observe: refactor to allow snaps to provide a slot <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2469>09:11
mupPR snapd#2616 opened: tests: test classic confinement `snap list` and  `snap info` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/2616>09:14
mupPR snapd#2617 opened: tests: switch more tests to MATCH <Created by zyga> <https://github.com/snapcore/snapd/pull/2617>09:26
sergiusensstokachu https://github.com/snapcore/snapcraft/blob/master/snaps_tests/__init__.py#L18009:38
stokachusergiusens, https://github.com/juju/juju/blob/staging/snapcraft.yaml09:46
mupPR snapcraft#1038 closed: misc: delete bzr ignore <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1038>09:50
sergiusensicey https://bugs.launchpad.net/bugs/165583210:03
mupBug #1655832: App name in snapcraft.yaml must match case of .desktop file <Snapcraft:New> <https://launchpad.net/bugs/1655832>10:03
iceyyeah sergiusens?10:05
mupPR snapd#2618 opened: tests: run all spread tests with SNAP_REEXEC={0,1} <Created by mvo5> <https://github.com/snapcore/snapd/pull/2618>10:47
mupPR snapd#2606 closed: overlord/snapstate: share code between Update and UpdateMany, so that it deals with auto-aliases correctly <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2606>11:30
iceysergiusens: I think I got the linker flags in11:48
mupPR snapcraft#928 closed: Add missing dependencies to install_requires <Created by javacruft> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/928>11:51
zygajdstrand: FYI, snap-alter-ns won't be setuid root, it will just be started by snapd (like snap-discard-ns)12:02
zygajdstrand: we can choose to confine it but I wanted to make sure you know this12:02
mupPR snapd#2567 closed: debian: skip snap-confine unit tests on nocheck <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2567>12:03
mupPR snapd#2619 opened: many: update 14.04 branch to top of master <Created by zyga> <https://github.com/snapcore/snapd/pull/2619>12:04
mupPR snapd#2616 closed: tests: test classic confinement `snap list` and  `snap info` output <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2616>12:05
mupPR snapd#2620 opened: store: export userAgent. daemon: print store.UserAgent() on startup <Created by chipaca> <https://github.com/snapcore/snapd/pull/2620>12:06
stokachuhow do i get into the shell of a snap again?12:25
stokachusnap run --shell conjure-up doesn't seem to do what i need12:25
=== ben_r_ is now known as ben_r
=== hikiko_ is now known as hikiko
Chipacastokachu: `snap run --shell the-snap` should do what you need12:42
Chipacastokachu: how is it not?12:42
Chipacathat is, what do you need, and what are you getting?12:42
stokachuso im building juju inside my snap but I think the problem is hte juju binary isn't getting copied into the snap12:43
stokachustill working that out12:43
Chipacastokachu: that gives me more questions, but doesn't answer mine :-D12:43
stokachuyea sorry still trying to understand what im doing12:44
stokachuChipaca: http://dpaste.com/361CKWW basically trying to expose the juju binary alongside conjure-up12:46
morphismvo: do you know if there is a clear reason why every systemd service unit snapd generates wants the network-online.target?12:47
Chipacastokachu: you did "snap run --shell conjure-up"12:47
stokachuChipaca, yea12:47
Chipacastokachu: what did that do? and what did you expect it to do?12:47
stokachuit brought me into a new shell and i was looking for the juju binary that wasn't there12:47
Chipacastokachu: i'm missing somemething, i fear12:49
stokachuChipaca, sorry, i built my conjure-up snap while pulling in the juju part from the wiki, in the end i want to be able to run both conjure-up and juju binaries from that single snap12:50
Chipacastokachu: "snap run --shell conjure-up" is giving you a shell in the environment that apps in the conjure-up snap would see12:51
Chipacastokachu: (modulo connections)12:51
stokachuChipaca, ok, now im trying to figure out why that juju one isn't showing up in the file list12:51
stokachuChipaca, using --classic12:51
mvomorphis: no clear reason12:51
mvomorphis: if that is a problem we can kill it12:51
Chipacastokachu: when you say "in the file list", you mean in the snap?12:51
stokachuChipaca, yea12:52
stokachushould it be conjure-up.juju as the command name?12:53
stokachuhow can i make it just juju? with an alias?12:53
Chipacastokachu: yes12:53
Chipacastokachu: but: is juju in conjure-up something users are expected to interact with?12:54
stokachuChipaca, yea, juju needs to talk to the agent installed inside that snap12:54
mupPR snapd#2619 closed: many: update 14.04 branch to top of master <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2619>12:54
morphismvo: not a urgent thing to fix but it conflicts with network-manager when I add a Alias=NetworkManager.Service in the generated unit file12:55
morphisas it then has a cycle of dependencies12:55
=== mcphail_ is now known as mcphail
stokachutrying to get this juju binary include but hitting http://dpaste.com/2XNXGRW13:19
stokachuthe part im pulling in is https://github.com/juju/juju/blob/juju-2.0.2/snapcraft.yaml13:20
=== beowulf_ is now known as beowulf
=== hikiko_ is now known as hikiko|ln
morphiszyga: any idea about https://paste.ubuntu.com/23786689/? I am using a 3.4 kernel here so could be something not well supported by that ancient kernel but would like to understand this a bit more13:35
mupPR snapd#2620 closed: store: export userAgent. daemon: print store.UserAgent() on startup <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2620>13:54
zygamorphis: looking14:04
zygamorphis: 3.414:04
zygamorphis: mount namespaces14:04
zygamorphis: do you see /proc/self/ns ?14:05
zygamorphis: if not then 3.4 is too old14:05
zygaI honestly don't expect 3.4 to work14:05
mupPR snapd#2618 closed: tests: run some spread tests with SNAP_REEXEC={0,1} <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2618>14:12
zygamorphis: there's no mnt entry there14:12
zygamorphis: the error is confusing but 3.4 is too old14:12
zygamorphis: and there's no way to solve it easily without a major feature in snap-confine14:12
zyga(I discussed this a while ago but this is 2-3 weeks to do)14:13
zygamorphis: what is the HW if you can disclose this?14:13
morphiszyga: I see14:13
zygamorphis: if I end up writing this I'd like to know if I have it on my desk14:14
=== hikiko|ln is now known as hikiko
morphiszyga: see PM14:20
zygamorphis: got it now14:28
zygamorphis: if we chat on rocket I get better notification14:28
stokachuzyga, snapstore supports delta downloads now right?14:53
mupPR snapd#2617 closed: tests: switch more tests to MATCH <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2617>14:59
morphiszyga: :-)15:00
zygastokachu: yes but the client needs a special variable to enable that15:03
stokachuzyga, when will that get enabled by default?15:04
zygastokachu: I don't know, that's a question to chipaca (not on IRC now) and nessita15:04
stokachuok thanks15:04
Chipacazyga, no, *you're* not on irc15:04
zygatab tab gave me nothing, sorry about that15:04
Chipacawe don't have delta downloads enabled by default15:05
Chipacabecause of the xdelta3 dependency15:05
stokachuChipaca, is that something that is in the works to be done soon?15:05
Chipacastokachu, it's paperwork15:06
Chipacabut afaik it's moving forwards15:06
Chipacaso it'll get done in time15:06
Chipacai mean: the code is there15:06
stokachuChipaca, ah ok awesome15:06
Chipacaand you can even use it if you set the right env var15:06
stokachucool is it documented anywhere?15:07
Chipacadunno. SNAPD_USE_DELTAS_EXPERIMENTAL=1 in snapd's environ will do it15:07
stokachucool thanks15:07
Chipacaand, you need xdelta315:08
zygajdstrand: hey15:10
zygajdstrand: did you read about the new BFP attachments to cgroups?15:12
jdstrandzyga: yes. I assume you are refering to the comment in the 'ip netns' PR. I just commented there15:19
zygajdstrand: actually no, I read the article on LWN15:19
zygajdstrand: I'll check the PR15:19
jdstrandzyga: the pr doesn't mention bpf, but it was talking about network mediation, so I thought you were going there15:21
stokachuhi could i get someone to take a look at https://myapps.developer.ubuntu.com/dev/click-apps/5479/rev/26/?15:24
jdstrandstokachu: I will15:25
stokachujdstrand, ty!15:25
mupPR snapd#2621 opened: osutil.GetenvBool now takes an extra, optional, argument <Created by chipaca> <https://github.com/snapcore/snapd/pull/2621>15:28
jdstrandstokachu: done. you need to press the release button15:29
stokachujdstrand, perfect ty, do i need to worry about getting additional reviews if i need to push a new snap?15:29
jdstrandstokachu: not now (I granted that). check your email15:30
stokachujdstrand, ok great, thank you again15:30
stokachujdstrand,  sudo snap install conjure-up --edge --classic <- am i missing anything here?15:36
stokachusays snap isn't found15:36
stokachuoh isee15:37
stokachurelease button at the bottom15:37
stokachuhmm not sure what im missing now15:38
=== chihchun is now known as chihchun_afk
stokachumaybe there is a delay15:41
stokachuhttp://paste.ubuntu.com/23787291/ snap info does show it in the edge channel as well15:44
pedronisstokachu: some confusion but installing classic snaps from the store doesn't work in 2.20 or before (we are fixing it in 2.21)15:52
stokachupedronis, ah15:53
stokachupedronis, np i can just work with the blob itself for now15:53
pedronisstokachu: the workaround to try it is to use "snap download   snap-name"   "snap ack *.assert" "snap install *.snap"15:55
stokachupedronis, ah perfect, that'll work15:55
pedronissorry for the incovenience15:55
stokachunp i know it's very new15:56
jdstrandstokachu: there is an issue with snapd and the store when using --classic. I don't recall the details. I think sergiusens has a workaround15:59
jdstrandah, I see you already got an answer to that :)16:00
stokachujdstrand, :D16:00
stokachui can still corner sergiusens tomorrow unless he's hiding from me16:00
jdstrandroadmr: hi! can you pull r824 of the tools? this is just updates to data/ for 2.21 interfaces and whitelisting some approved kernel and gadget snaps16:03
roadmrjdstrand: sure thing16:04
jdstrandroadmr: thanks! I *think* this will be it for a while (famous last words)16:04
mupPR snapd#2520 closed: many: fix abbreviated forms of disconnect <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2520>16:05
mupPR snapd#2622 opened: asserts: Improve error message when key is not valid at the given time <Created by mvo5> <https://github.com/snapcore/snapd/pull/2622>16:15
Cust0sLim3nwhen will rhel/centos be supported16:28
mupPR snapd#2621 closed: osutil.GetenvBool now takes an extra, optional, argument <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2621>16:30
ogra_Cust0sLim3n, perhaps SamYaple or zyga know if thats actually planned ... fedora is surely supported (with limitiations in the confinement)16:34
elopiohello Cust0sLim3n: https://github.com/snapcore/snapd/wiki/Distributions16:34
Cust0sLim3nthanks elopio16:36
zygaCust0sLim3n: hey16:39
zygaCust0sLim3n: CentOS needs some packaging work16:39
zygaCust0sLim3n: Fedora has two blocking issues that we've struggled with16:39
zygaCust0sLim3n: both are on the backlog but I expect ~1-2 weeks before I start working on that16:39
Cust0sLim3nzyga, is there some repo with stuff for CentOS / Fedora builds ?16:40
zygaCust0sLim3n: please have a look at http://www.opera.com/pl/computer/neon16:40
zygapaste fail16:40
zygaCust0sLim3n: there was COPR but it is no longer used as development moved to Fedora git16:40
Cust0sLim3nzyga, cool thanks16:41
zygaCust0sLim3n: CentOS should be easier (no selinux on services by default) but it needs separate packaging permissions16:41
zygaCust0sLim3n: if you are interested we could work together to revive copr and build a centos package there16:41
zygaCust0sLim3n: I cannot commit 100% of my time to it this or next week but I will help you out16:41
Cust0sLim3nzyga, don't really have time - really need it for RHEL though - but I think in meantime I will just use software collections on rhel or something - still have to see16:42
Cust0sLim3nzyga, just thought it would be nice to use snappy instead of SCL16:42
zygaCust0sLim3n: what software are you most interested in?16:43
zygaCust0sLim3n: we'll get there, it's just a busy schedule all the time16:43
Cust0sLim3nzyga, its for commercial use with our C/C++ software on linux that I want it16:44
Cust0sLim3nzyga, but its not critical enough for us to dedicate allot of time to it - so it was mainly just if I somehow missed it being available it would have been nice - but otherwise we will just use SCL or package directly16:46
zygaCust0sLim3n: how do software collections help you?16:46
zygajdstrand: hey - new interfaces API: https://github.com/snapcore/snapd/pull/2613/files16:50
mupPR snapd#2613: interfaces: add new interface API <Created by zyga> <https://github.com/snapcore/snapd/pull/2613>16:50
zygajdstrand: with initial review from gustavvo16:51
zygajdstrand: I think it is likely to land soon16:51
zygajdstrand: once it does expect a flag day where all the interfaces and backends are ported to provisional APIs like spec.AddSnippet() (that directly replaces returning a snippet)16:51
jdstrandI'll be looking at that in a little bit16:52
zygajdstrand: and then dedicated changes to backends like mount, kmod, systemd that are well defined and have just a few interfaces16:52
zygajdstrand: then we can discuss apparmor/seccomp16:52
zygajdstrand: I think there's no rush on aa/sc but we can see what we'd like to do by porting one or two interfaces over to more semantic APIs16:52
zygajdstrand: e.g. in seccomp we could do spec.Allow(seccomp.open) rather spec.AddSnippet("open")16:53
zygajdstrand: in apparmor we could do (but in short cases IMHO) spec.Allow("/path/to/file", "r") or even spec.Allow("/path/to/file", apparmor.Read)16:53
zygajdstrand: thanks!16:54
Cust0sLim3nzyga, makes it easier to work with multiple library and application versions and allows us to be less dependent on library versions shipping with OS - so if we want newer boost version for building with than is available on RHEL by default we can package it with SCL16:55
jdstrandzyga: keep in mind, I've not looked at this at all yet, but please, please, please keep in mind that the resulting security policy needs to be auditable. that means policy, structure and comments all need to be in place. I maintain my concerns that this will impede security audits since the review will have to do profile dumps to see what is happening16:56
zygajdstrand: I keep this in mind and keep reminding everyone about it :-)16:56
jdstrandtyhicks: fyi ^16:56
mupPR snapd#2623 opened: tests: add test ensuring manual pages are shipped <Created by zyga> <https://github.com/snapcore/snapd/pull/2623>17:00
jdstrandogra_: hi! I noticed that the bbb kernel is a few versions behind the most recent USNs18:00
jdstrandogra_: is your automated script not working right?18:01
ogra_jdstrand, that one isnt automated ...  i'll kick off a new build18:14
jdstrandogra_: fyi, you can automate it if you want. I just added an exception for it in the review tools (though this upload will need a review, when the store syncs it won't any more)18:16
mupPR snapd#2624 opened: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>18:41
zygatyhicks: good news, I think I know what the kernel bug is about :)18:46
zyga(the one with oops on one thing I did a while ago)18:46
zygawell, fingers crossed18:46
zygaat the very least I can give you a way to reproduce easily18:46
zygajdstrand, jjohansen:  ^^18:47
zyga(oops in apparmor)18:47
zygaon the up side it is *not* Friday yet18:47
kgunnogra_: thanks for the pi image...one question, anyway we could change pi3 console config to not require ethernet cable?18:48
kgunni set up wifi fine, but then it loops back and demands i set up via ethernet18:49
ogra_kgunn, i think there is an old bug open for this ...18:49
* kgunn thot pi2 didn't have wifi chip18:49
kgunnand that was the reason18:49
ogra_you can set it up initially with eth0, then reboot, ssh in and run "sudo console-conf" and disabe eth0 and switch to wlan0 ... that works fine for me18:50
ogra_it is only the very first boot where it fails18:50
davmor2ogra_: out of interest why are we use pi2 kernel on pi3 are there phyiscally no differences between then?18:50
ogra_(but indeed you need network on the very first boot to set up the user)18:50
zygaogra_: you can use the serial console18:51
zygaogra_: on a pi :)18:51
ogra_davmor2, the kernel is identical ... but th ebootloaders are not (namely there is a different u-boot.bin )18:51
jdstrandjjohansen: this is not what we talked about yesterday, but zyga is seeing an oops with https://github.com/snapcore/snapd/pull/2624. I have a feeling many of your concerns about changing the mount namespace would apply to this pr18:51
mupPR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>18:51
ogra_zyga, for what ?18:51
zygaogra_: to do the 1st boot dance18:51
zygajdstrand: that branch is buggy but perhaps this is causing the oops18:51
ogra_zyga, and that magically pulls the login data via serial ?18:51
zygajdstrand: testing again with the fix18:51
zygaogra_: oooooho18:51
zygaogra_: I should have gotten that beer18:52
ogra_you need network to be able to finish console-conf once18:52
zygajdstrand: anything I should know about?18:52
ogra_once it is finished, switching networks is easy18:52
jdstrandzyga: you should wait for jjohansen. he had concerns regarding changing namespaces and open fds and likely some other concerns18:53
zygajdstrand: will he be around today?18:54
jdstrandzyga: this came up in the context of snap-alter-ns, but I think they would apply to this18:55
zygajdstrand: hmm hmm, can you tell me how would snap-alter-ns be affected? we could presumably do all the open() calls after we re-associate18:55
zyga(just worried if I should be worried)18:55
jdstrandzyga: he should be. he has been sick though. not sure when he'll be online18:55
jdstrandzyga: need to wait for jjohansen. we were going to chat today. may as well make it all 3 of us18:56
jdstrand(or maybe tomorrow)18:56
zygajjohansen: I'm sorry to hear that, I hope you get better18:56
zygajdstrand: if he's around can you please PM me on telegram (I get notifications on my phone this way)18:57
zygaI'd like to listen to understnad this problem better18:57
jdstrandzyga: you can listen to irc then?18:57
zygajdstrand: if the converstation is on IRC then that's much easier :)18:59
jdstrandzyga: it will be, yes19:00
zygajdstrand: somewhat offtopic, I think there's a separate bug, kernel doesn't let me bind() the mount namespace FD if I don't run as root despite having all the capabilities; I will need to investigate that in ~10 days. Do you know if this is by design (by any chance)?19:02
jdstrandzyga: I don't, sorry19:04
* zyga will dig through the kernel then19:04
alvarolbhi there! How I can submit a snap package both for armhf and amd64? I have both snaps already built.19:05
zygaalvarolb: just send them to the store19:05
zygaalvarolb: you can use snapcraft for that19:05
zygaalvarolb: or use the web UI19:05
zygaalvarolb: both snaps need to have the same snap name / snap id19:05
zygaalvarolb: and (hopefully) different architecture entries19:05
alvarolbyes, but if I upload the amd6419:06
kyrofaalvarolb, they will both be assigned different revisions and the store will know what arch they are. And snapd won't let a snap for the wrong arch be installed19:06
alvarolbthen it replaces the armhf19:06
zygaalvarolb: it doesn't really replace them19:06
zygaalvarolb: just try it, you will have to publish each one19:06
zygaalvarolb: then you should be able to install them :)19:06
alvarolbOk, so I upload both versions to the same snap package, and it should work19:07
kgunnogra_: re eth, ack...except i don't have eth cable access here at my communal office space :-P19:07
alvarolbit does not show that the snap is available for both platforms19:07
kyrofaalvarolb, then run `snapcraft status <snapname>` and you'll see where each arch has its own channel map19:07
ogra_kgunn, ah, damned19:08
ogra_kgunn, well, we dont have a solution beyond this yet19:09
ogra_you could try a wifi dongle, perhaps that works better19:10
alvarolbok, thanks for the support!19:10
mupPR snapd#2433 closed: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2433>19:15
mhall119jdstrand: can you take a look at this error for me? http://paste.ubuntu.com/23788349/19:36
mhall119I suspect that it's not really a problem with the limits, but rather the snap's inability to check what the limits are, due to confinement19:36
zygamhall119: Jan 12 14:31:59 mhall-thinkpad snap[5671]: /snap/couchbase-server-community/x1/couchbase-server-snap: line 166: exec: erl: not found19:38
zygamhall119: limits seem to be a separate issue19:38
zygamhall119: look at dmesg | DENIED please19:39
zygadmesg | grep DENIED19:39
mhall119zyga: nothing from couchbase there, I have another issue with it not finding the 'erl' binary that I need to fix19:40
stokachuso in a classic snap how would i copy a file to my HOME dir?19:49
zygamhall119: then I'd say it dies on that problem now19:49
stokachunot the home dir of the snap19:49
zygastokachu: classic snap or in the classic confinement of some snap/19:50
stokachuzyga, in the classic confinement19:50
zygastokachu: snaps that have confinement: classic don't get HOME redirection19:50
zygastokachu: HOME is real :)19:50
zygastokachu: try it,19:51
stokachuhmm so if i do a cp file ~/test from the snap it doesn't show up in my HOME dir19:51
zygastokachu: https://github.com/snapcore/snapd/wiki/Environment-Variables#home19:51
zygastokachu: can you use "snap run --shell $SNAP_NAME.appname" and go to $HOME19:51
zygastokachu: or just echo $HOME19:52
zygastokachu: if that's a bug I can (still) fix it19:52
stokachuzyga, hmm ok $HOME shows my user (ubuntu) /home/ubuntu when i do a snap run --shell conjure-up19:53
stokachuneed to check out my code then, because things like os.expanduser in python should work as normal correct?19:53
stokachuyea must be something in my code19:54
* stokachu back to drawing board19:54
AlbertAogra_: this may be a different bug (wifi), I ran console-conf after first boot like you mentioned but19:58
AlbertAwlan0 option dissapears19:58
zygastokachu: I hope so, we don't change anything else20:00
AlbertAogra_: I guess a reboot fixed that :)20:00
stokachuzyga, hah20:00
zygajdstrand: hey, so I made some progress but got stuck; I don't see any apparmor denials (the process is in devmode), I don't see anything in the kernel log but when I open /proc/1/ns/mnt I get EACCES20:05
zygajdstrand: I did an experiment where I just nsenter around and this worked OK20:05
zygajdstrand: I suspect apparmor is causing this20:05
zygajdstrand: can you please have a look at https://github.com/snapcore/snapd/pull/2624/files#diff-5f1642833244a655796f5f4230f68fdbR20720:06
mupPR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>20:06
zygajdstrand: and tell me if I need to adjust the apparmor profile in some special way (in the same pull request)20:06
mupPR snapcraft#1045 opened: Handle parser errors better <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1045>20:06
zygajdstrand: note, I *don't* get a DENIED anywhere :-(20:06
zygajdstrand: (thinking about it now I want to point out that while the process running snap-confine is in devmode, snap-confine itself is obviously confined)20:06
zygajdstrand: perhaps my change is not applied to the snap-confine I'm runnning from the (repackaged) core snap?20:07
zygajdstrand: still thinking aloud, looking at /sys/kernel/security/apparmor/profiles I see20:08
zygajdstrand: should snap confine reset the policy (maybe this should be done in the base apparmor template, running snap confine doesn't inerhit the profile but replaces it with the profile for snap-confine)20:10
zygajdstrand: insight appreciated, I'll check back later20:10
zygajdstrand: I've added some more facts here: https://github.com/snapcore/snapd/pull/2624#issuecomment-27227013020:19
mupPR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>20:19
* zyga EODs20:19
ogra_AlbertA, yeah, wla0 is there and you can even attempt to configure it but it will always fail in the end20:22
ogra_second attempt is stable20:22
roadmrjdstrand: you got lucky and we had a clear store deployment pipeline; tools r824 is now in production20:29
jdstrandroadmr: thanks :)20:30
lazyPowero/ heyo, trying to use snapcraft from MASTER. My tests pass save for some subclass issues (about 7 failures that seem unrelated) - however when attempting to use snapcraft, i get the following message: Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path20:41
kyrofalazyPower, how are you running snapcraft?20:45
lazyPowerkyrofa - i followed the hacking guide to install it (isolated in a lxd container)20:49
lazyPowerkyrofa - after the predep steps, python setup.py install && cd $my-snaps-path && snapcraft20:50
kyrofalazyPower, the hacking guide only discusses dependencies, not snapcraft itself20:50
kyrofalazyPower, when it comes time to run it, simply run bin/snapcraft (or add it to your PATH)20:51
jdstrandmhall119: your system seems to have 'nofile' set somewhere. you can see your limits by typing 'ulimit'. I did just now on classic, in hello-world on classic and hello-world on all snaps and they all say 'unlimited'. see man limits.conf and /etc/security/limits.conf21:21
jdstrandmhall119: are you seeing any security denials?21:21
jdstrandzyga: re https://github.com/snapcore/snapd/pull/2624/file if there is no denial, it shouldn't be apparmor. the kernel might be telling you EACCES for another reason. that said, I think we should ask jjohansen about it21:23
mupPR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>21:23
jdstrandzyga: when you use nsenter, are you doing it from within snap-confine at the point that it is getting the EACCES? ie, nsenter from global namespace to pid 1 namespace is one thing, some snap app running anohter snap app that triggers snap-confine to have it go to pid 1 is another thing21:26
jdstrandjjohansen: ^ that is the summary of the issue21:27
jdstrandjjohansen: let's wait for zyga to respond on that. do you have time to discuss snap-alter-ns? (what we discussed yesterday)21:30
jjohansenwe discusssed it?21:30
jdstrandwe referenced it?21:31
jdstrandthe thing from yesterday :)21:31
jdstrand(which isn't the same thing as the above pr)21:31
jdstrandjjohansen: you have time now?21:31
jjohansensure, I guess21:32
jdstrandjjohansen: ok. so let me give you the problem and a simple description of what the propsed solution is, then the url for the din depth description of the fix21:33
jdstrandjjohansen: today snaps can ship multiple commands. those commands may be daemons or manually started. all commands within a snap share the same mount namespace, so the all see the same /tmp and things that snapd might mount into the namespace21:34
jdstrandjjohansen: this is done by when a snap command is first started, a nsfs magic file is checked. it is isn't magic, the full mount namespace is setup, then the magic file is saved. the next command that runs see the magic file and snap-confine enters that mount namespace instead of generating it anew21:36
jdstrandjjohansen: on top of that, there is an interface called 'content'. this allows a providing snap to 'export' something in its area so that another snap may 'import' it. this is done via a file that maps the export dir to the import dir that snap-confine reads and it will perform a mount of the exported dir into the calling snaps mount namespace21:38
jdstrandjjohansen: iirc, things work fine if the interfaces are connected (ie, snap-confine is supposed to do this mount operation) and the mount namespace is not setup (eg, after a reboot). there have been some issues with if the mount namespace is setup already iirc and adding it after the mount namespace is already setup. (eg, start the command, then connect the interface, etc)21:41
jdstrandjjohansen: so zyga came up the the idea of 'live modification of mount namesapces'21:41
=== smoser` is now known as smoser
jdstrandjjohansen: in essence, that is meant to robustly perform the mount of the imported directory on a namespace that is already setup, and remove mounts that have been disconnected21:42
jdstrandjjohansen: I mentioned that removing mounts will cause problems with daemons most likely-- I think he will counter that they'll lazy umount.21:43
jdstrandjjohansen: the live modification will be done by 'snap-alter-ns', a command that snapd will call when a 'snap connecnt' or 'snap disconnect' is performed. it is meant to mount missing connected imports and unmount ones that are no longer connected21:44
jdstrandjjohansen: here is the larger proposal: https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces21:44
jdstrandjjohansen: <I'm done>21:45
jdstrandjjohansen: well, I have one final thought. revocation aside, I thought that simply adding mounts would not be problematic since that isn't really any different than say plugging in a usb key and having it show up. that said, there are many layers of mounts here and that may be a naive way of looking at it21:47
jjohansenokay, removing mounts can be problematic for any open fd, but it is probably something that isn't a blocker21:48
* zyga watched 2nd episode of 4th season of Sherlock21:48
zygajdstrand: replied on your comment21:48
zygajdstrand: according to my experiment this only happens when apparmor is in the loop, I could have made a mistake, I was tired already21:49
zyga22:26 < jdstrand> zyga: when you use nsenter, are you doing it from within snap-confine at the point that it is getting the EACCES? ie, nsenter from global namespace to pid 121:49
zyga                  namespace is one thing, some snap app running anohter snap app that triggers snap-confine to have it go to pid 1 is another thing21:49
jjohansenadditions at first glance look safer, but have the potential to create aliases and rewrite subtree. If tightly controlled it should be okay, if not it is an attack vector21:49
zygajdstrand: to reply to this: when I use nsenter I was doing it from the mount namespace created by snap-confine21:50
zygaI'm happy to discuss anything21:50
jdstrandzyga: let's pause on 2624 for a moment and get through snap-alter-ns21:51
jjohansenzyga: can you turn on apparmor debug messages21:51
jjohansen  echo 1 > /sys/modules/apparmor/parameters/debug21:51
jjohansenand see if that turns anything up, also turn off printk rate limiting to make sure printk isn't dropping something21:51
jjohansen  echo 0 > /proc/sys/kernel/printk_ratelimit21:51
zygajjohansen: ack, I'll do that21:52
jdstrandjjohansen: wrt aliases and rewrite subtree, how would one trigger that? right now, the snap declares a dir and that is it. is it a malformed dir? a symlink? something in the dir that could trigger it?21:52
jdstrandoh I forgot rate limiting21:52
jjohansenapparmor shouldn't be denying something without logging it, hmmm unless explicitly told not to log it, better turn off quieting as well21:52
jjohansenecho -n noquiet > /sys/module/apparmor/parameters/audit21:52
jdstrandjjohansen: we don't actually explicitly much in the snappy policy (I think there are two rules otoh)21:53
jdstrandbut noquiet never hurts21:53
jjohansenjust trying to make sure all potential reasons not to log are out of the way21:55
zygaok, test in progress21:55
zygalet's talk about snap-alter-ns21:55
jdstrand(fyi, you need sys_admin for entering the namespace and snap-confine has that)21:56
jdstrandjjohansen: did you see my last question?21:56
* zyga finishes reading backlog21:58
jjohansenjdstrand: you mount over an existing dir/tree location that isn't a leaf21:58
jjohansenit just has to be controlled is all21:59
jdstrandjjohansen: like, twp exported dirs mounted onto the same import dir?21:59
zygaI'm fine with limiting this so that we can guarantee no "funny" layouts are possible21:59
jdstrandjjohansen: it is rather tightly controlled right now. I want to make sure we make sure we get all the bits21:59
zygayou should also be aware with one more thing we're trying to introduce that may complicate this21:59
zygathe 'overmount' interface, that within the snap's mount namespace, allows it to almost freely do bind mounts from $SNAP to various places across the fileystem; the use case is shoving stuff into /usr/share so that pre-compiled binaries feel more at home22:00
jdstrandzyga: can you add to your list a check to make sure that you can't mount on an already mounted location? ie, no layering at all22:00
zygajdstrand: so essentially the target directory cannot itself be a mount point22:01
jdstrandzyga: that is how I took jjohansen's comment. let's get his feeback22:01
zygajdstrand: will this restriction cause any issues to users?22:01
jdstrandzyga: I think blocking that is a good thing despite this. it would be weird to have two content exports mounted over each other. which would win? poor user experience22:02
zygaare we considering *any* mount points or just those that interfaces created?22:03
jdstrandjjohansen: ^22:04
zyga/bin/bash: line 44: /sys/modules/apparmor/parameters/debug: No such file or directory22:06
jjohansenjdstrand: well sure that is one, doesn't really matter any non-leaf mount can result in weirdness, as you have a shadowing affect22:06
jjohansenie. alias22:06
zygaah, module vs modules22:06
jdstrandwith the content interface I think this is ok22:07
zygajjohansen: can you give me an example of a mount that would be problematic22:08
jjohansenwhether its good or bad depends on what you are trying to achieve, but it adds to the complexity of what needs to be analyzed and opens the potential for attacks that you don't see. I think you probably okay, the mounts are being done by snapd not the application22:08
zygajjohansen: I'd like to understand what to avoid better22:08
jdstrandwe are mounting into a dir that shouldn't have any mounts (well, could be on a dir in a squashfs)22:08
jdstrandjjohansen: gotcha22:09
jjohansenzyga: that is a good question, and the answer is it depends22:09
jdstrandzyga: I think we are ok cause the content interface is mounting into a very specific place-- either in SNAP, SNAP_COMMON or SNAP_DATA. there shouldn't be anything else in there if we employ the outlined restriction22:10
jjohansensome of it, I just don't know. Aliasing attacks via links etc have been pulled off in the past. I think we largely don't have that problem with snappy22:10
jjohansenthe other thing to worry about the interaction between the different mechanisms providing your policy, which is a combination of namespaces, dac, apparmor, and seccomp22:11
jdstrand(snaps can't mount (excepting a few super restricted interfaces that are only allowed to trusted apps))22:11
zygajdstrand: if the overmount interface lands that comfort will go away, e.g. I can connect overmount and then content and then disconnect overmount, given the right (or evil) interfaces that could do some things we weren't expecting22:11
jdstrandzyga: I have quite a few concerns with the overmount interface22:12
jjohansenthey each have their own set of expectations, I think the interaction between apparmor path mediation and mount namespacs is the most problematic22:12
jjohansenagain its just a matter of making sure your policy is right for the changes22:12
jdstrandbased on what we said here, I think we are good. we can deal with overmount if/when it comes up for review22:13
zygacan you wait 5 more minutes, I will have that debug data22:14
jdstrandit is too difficult to think about the policy ramifications of what it could someday do ("it can do anything!" I can't evaluate the impact on policy for 'anything' :)22:14
zygaI was looking at loaded profiles and I saw that there were "//null" in the profile names, that made me worries somewhat, are those expected? I don't quite understand how profiles stack or what to make of the profile name22:14
zyga(after the reassociation test failure)22:15
jdstrandjjohansen: wrt revocation with snap-alter-ns. today we don't revoke so there isn't an issue. with snap-alter-ns, I suspect that zyga will use a lazy umount. do you see problems there?22:15
jdstrandzyga: //null is normal when you are in complain mode22:15
jjohansenzyga: //null should only ever showup for profiles that are auto-generated during complain mode22:16
jjohansenthey will either be //null-#### where #### is unique, or //null-executable name22:17
zygadmesg http://paste.ubuntu.com/23789099/22:17
zygakern.log http://paste.ubuntu.com/23789105/22:17
jdstrandwe got back to talking about two things at once22:17
zygathis is the same test with the extra debugging22:18
jdstrandwe can finish snap-alter-ns if the revocation question is answered22:18
zygaah, sorry, I'm always too impacient22:18
zyga[  498.595560] apparmor: clearing unsafe personality bits. /usr/lib/snapd/snap-confine label=snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine22:19
jjohansenzyga: so I don't see apparmor directly causing the failure but, it is possible that clearing the unsafe personality bits could lead to an EACCES22:19
zyga[  498.616822] audit: type=1400 audit(1484259403.009:67): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine" name="" pid=25299 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=022:19
zygaisn't this exactly what I saw?22:19
zygaI got errno 1322:20
zygajjohansen: I was reading the log in order, this is the last message22:20
jdstrandcan we put that on hold? I have a question regarding it that will require discussion22:20
jdstrandthere is but one question remainging...22:20
jdstrandjjohansen: wrt revocation with snap-alter-ns. today we don't revoke so there isn't an issue. with snap-alter-ns, I suspect that zyga will use a lazy umount. do you see problems there?22:20
jjohansenoh, hrmmm, if there is an ALLOWED it should be toggling the error to 0, the logging does report the initial error22:21
jjohansenI am not ruling out that there is a bug around complain mode and disconnected paths22:21
jjohansenjdstrand: sure, lazy unmount tringgers disconnected paths22:22
jdstrandzyga: so I'm not sure we can do live revocation well with snap-alter-ns22:22
zygajdstrand: hmm hmm22:23
jdstrandzyga: daemons or anything already running in the mount namespace are going to be unhappy22:23
jjohansenjdstrand: with that said, if the fd label is cached it should be fine22:23
zygajdstrand: we could ignore that and just carry on (to some extent)22:23
zygajdstrand: we could fail the operation and say "gee, cannot disconnect this thing now" (bad UX perhaps, need to re-do some mounts)22:23
jdstrandzyga: I think snap-alter-ns will make connect more robust22:23
jjohansenthe issue would rear its head if new lookups (openat, ...) are done based off of it, or policy is replaced22:23
jdstrandpolicy gets replaced on connect/disconnect22:24
jjohansenjdstrand: well, then we are going to have to spend some time looking at it22:24
jdstrandzyga: I like the idea of trying to umount non-lazy. if it fails, it just doesn't get unmounted. it gets removed from the saved file. eventually it is gone22:24
jjohansenjdstrand: it will depend on several things, and stacking opens up some avenues that might make it not a problem22:25
jdstrandzyga: I think more than that will require tyhicks or ratliff in on the conversation so that scope and priority can be discussed22:25
jdstrandjjohansen: ack22:25
zygajdstrand: we could also consider saying "this doesn't work" and having snapd shutdown all the stuff that runs there22:26
zygajdstrand: so in the nice case it just works22:26
jdstrandI'm ready to move past revocation if you guys are22:26
zygajdstrand: in the non-nice case it just reliably gets closed22:26
zygaI think we need to try it and meet again to discuss what kind of warts remain22:26
zygajjohansen: what do you think?22:26
jdstrandzyga: well-- restarting a daemon wouldn't be too bad, but there is no way to restart a non-daemon command that is running22:26
zygajdstrand: ah, correct22:26
zygajdstrand: I didn't consider this22:27
zygajdstrand: we could use cgroups to do this though22:27
zygafreeze and kill22:27
jdstrandzyga: that said, snap-alter-ns and its way of managing the saved file sounds fine and will make the connect more robust. we can ponder disconnect and defer22:27
jjohansenzyga: yeah, meeting again sounds good22:27
zygajdstrand: sounds good, I think most people will struggle with connect more :)22:27
jdstrandI'd be pretty miffed if I lost all my state22:27
jdstrandzyga: I do too22:28
zygajdstrand: connect is interactive22:28
zygajdstrand: we could do something smart like "are you *really* sure you want this?"22:28
jjohansenzyga: so if you add attach_disconnected to your profile, and test again that should tell us whether the failure is a bug in how apparmor is handling disconnected paths wrt complain mode22:28
zygajjohansen: this is attach_disconnected already I think22:29
zygajjohansen: there are only two profiles at play: (and a hat): snap-confine, base policy all snaps get and the hat in snap-confine22:29
* zyga checks22:29
zygaI have a debug shell so I can experiment if you have ideas22:29
jjohansenzyga: nope, you won't get info="Failed name lookup - disconnected path"22:29
jjohansenwell not unless that is a bug too ...22:30
jdstrandzyga: ok, so now my question-- why is snap-confine calling snap to call snap-confine from within the profile? I think the snap command needs to be the thing that sets everything straight. ie, snap can talk to snapd which can notice if the comamnd is running under confinement, then check if the confinement allows calling the command, then fork/exec to call snap itself22:30
jdstrandyou are focusing on devmode, but I don't know how this is expected to work in strict mode policy-wise22:30
zygajjohansen: snap-confine has that, looking at the generated profile now22:31
jdstrandso snapd is a trusted helper22:31
zygajdstrand: this is a feature for CE, in devmode only they need to be able to run a snap command from another snap command, before mount namespace tricks it use to work so they treat it as a regression22:31
jdstrandI know that has problems with fds, etc, etc, but so does this method22:32
zygajdstrand: this is only expected to work in devmode (for them)22:32
zygajjohansen: I confirmed that all profiles are attach_disconnected22:32
zygaI can pastebin them if you like22:33
zygaqemu:ubuntu-16.04-64 .../tests/regression/lp-1644439# cat /sys/kernel/security/apparmor/profiles |pastebinit22:33
jjohansenzyga: does /sys/kernel/security/apparmor/policy/raw_data/ exist?22:33
jdstrandlooking at line 91 and the lines after, I feel like maybe snap-confine is trying to transition to the hat but can't find it22:34
zygabut empty22:34
zygajdstrand: note that this is _before_ the hat22:34
jjohansengah, never mind. I've got it. The null child profile is not picking up the flags of the parent, so it is not attach_disconnected22:34
zygajdstrand: the reassociation is done before we even attempt to fork22:34
jjohansenzyga: can you open a bug22:35
zygajjohansen: sure, just tell me where22:35
jdstrandthis is a funky denial: apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine" name="" pid=25299 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=022:35
zygajjohansen: I can boot other kernels, test anything, this is easy to reproduce22:35
zygawell, it doesn't know what the name is22:35
jjohansenzyga: drop your failure and log in the bug, open it again linux or apparmor it doesn't really matter22:35
jdstrandzyga: do you have a reproducer for jjohansen that doesn't involve spread?22:35
jjohansenzyga: name="" means that its going to attach to /22:36
zygajdstrand: spread just runs those few shell commands, all you need to do is to build s-c from that branch and then you can do it easily22:36
zygajjohansen: I'll file one shortly22:36
jjohansendisconnected paths don't have a leading / and currently the only connection point is /22:37
zygajdstrand: and this is in qemu,22:37
zyga(pretty easy to set up)22:37
jdstrandzyga: can you make sure that the bug has very clear instructions for reproducing and building s-c?22:37
zygajdstrand: sure22:37
zygajdstrand: I'll try to simplify it if I can22:37
zygabut this is pretty robust, just clone that branch and run spread with a given argument22:37
jdstrandzyga: jjohansen is trying very hard to hit a merge window for upstreaming apparmor and he doesn't hack on snap-confine or snapd :)22:37
zygaand you have shell in the qemu box :)22:37
zygapoint taken22:38
zygabtw, how is that progressing?22:38
jjohansenzyga: I don't need the reproducer, just the bug. I should have a kernel for you in a few hours22:38
jdstrandzyga: yeah, don't expect that to be fast for him :) he doesn't have any of that setup. a shell script or .c file demontrating the problem is way better than bootstrapping the snapd dev environment22:38
zygajjohansen: looking forward to that22:38
jdstrandsounds like jjohansen has it under control and I've said my bits, so I'm out22:39
zygaI'll report the bug now22:39
zygathanks guys, it was good to talk to you again :)22:39
jdstrandjjohansen: thanks for all your time! :)22:40
wililupyQuestion: I have a user that built a custom kernel and they are trying to install it with the snap install command but it fails saying it is not signed. They used the --dangerous and equivilent options to no avail. Is there any other command line flags to use when trying to do this?22:47
zygawililupy: you need to build an image with this but I don't believe this option is supported in ubuntu image yet22:47
kyrofazyga, is there no way to use a custom kernel, then?22:49
wililupyzyga: Thats what I thought. I told them that and sent them instructions on building a custom image but I also told them I would get a difinitive answer on this as well. Thanks.22:49
zygamaybe I'm confusing building an image with devmode snaps and building with a unsigned kernel22:49
* zyga doen't know22:49
kyrofabarry, help?22:50
wililupykyrofa: when I build custom images, I use custom kernels and it works. I never tried snap install kernel.snap but they did and told me what happened.22:51
kyrofawililupy, ah, so ubuntu image _does_ support this?22:51
kyrofawililupy, was the install attempted on classic ubuntu, or in ubuntu core?22:52
wililupykyrofa, yes. in the assertion I use my custom kernel's name value and then use --extra-snaps and the kernel.snap and it builds and runs no problems.22:52
wililupykyrofa: ubuntu-core.22:53
kyrofawililupy, okay good, glad to know that works. barry unping22:53
kyrofawililupy, I kinda feel like you should be able to install --dangerous on core though... otherwise testing a custom kernel is rough, no?22:53
kyrofaI wonder about the reason behind that22:54
wililupykyrofa, thats what I thought as well, but they came back saying it didn't work.22:54
kyrofazyga, can you think of why that wouldn't work?22:54
zygasorry, I'm semi off now23:03
zygakyrofa: you probably cannot install a kernel now, not sure23:03
zygayou may need to build an image with it23:04
zygabut I'm just throwing ideas at 4 minutes past midnigth23:04
* zyga postpones filing the bug till tomorrow23:04
zygajjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/165612123:12
mupBug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:New> <https://launchpad.net/bugs/1656121>23:12
zygaplease tell me if I should provide more data23:12
jjohansenzyga: thanks, I'm just kicking off a kernel build23:13
mupPR snapcraft#1046 opened: godeps plugin: work when GOBIN is set <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1046>23:18

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!