| mup | PR snapd#7832 closed: snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7832> | 01:07 |
|---|---|---|
| mborzecki | morning | 06:14 |
| mborzecki | nfs-support failed on 19.10 https://paste.ubuntu.com/p/JvGPJxMxZx/ | 06:29 |
| sdhd-sascha | good morning | 06:34 |
| sdhd-sascha | morzecki: how can i run this single test ? go test -check.f ... ? | 06:45 |
| sdhd-sascha | mborzecki: | 06:45 |
| mborzecki | sdhd-sascha: go test -check.f <testname> in the corresponding package or jsut passing the pacakge name eg. github.com/snapcore/snapd/cmd/snap | 06:46 |
| mborzecki | sdhd-sascha: writing import paths is tedious, so i just cd into the directory of the package | 06:47 |
| sdhd-sascha | i tried: | 06:48 |
| sdhd-sascha | $ go test -check.f github.com/osutil/nfs_linux_test.go | 06:48 |
| mborzecki | sdhd-sascha: when in snapd tree, cd osutil ; go test -check.f nfsSuite | 06:51 |
| mborzecki | sdhd-sascha: nfsSuite because it's the test suite defined in nfs_linux_test.go file | 06:52 |
| sdhd-sascha | mborzecki: thank you - it works | 06:53 |
| sdhd-sascha | but on my 19.10 it works | 06:54 |
| sdhd-sascha | go test -check.f nfsSuite | 06:54 |
| sdhd-sascha | OK: 1 passed | 06:54 |
| sdhd-sascha | PASS | 06:54 |
| sdhd-sascha | ok github.com/snapcore/snapd/osutil 0.005s | 06:54 |
| sdhd-sascha | I have there a nfs-mount. | 06:54 |
| sdhd-sascha | mborzecki: Or, is this a different nfs test in the paste from you? Error executing google:ubuntu-19.10-64:tests/main/nfs-support : | 06:56 |
| sdhd-sascha | mborzecki: you mean the "spread" tests. sorry | 06:58 |
| zyga | good morning | 07:13 |
| zyga | mborzecki: I have a question | 07:13 |
| zyga | mborzecki: I was fighting snap security tag mess spread around the code and I think that's a separate cleanup | 07:15 |
| mborzecki | zyga: hey | 07:15 |
| zyga | mborzecki: do you think it would be ok to do just a regexp based validation on the supposed security tag | 07:15 |
| zyga | mborzecki: and do nothing more in the sandbox/cgroup package for now? | 07:16 |
| mborzecki | zyga: let me take a look at the pr | 07:17 |
| zyga | mborzecki: I didn't push anything since yesterday | 07:18 |
| zyga | mborzecki: because trying to make sense of how security tags are used and validated brings one headache | 07:18 |
| mborzecki | zyga: heh, indeed it does | 07:18 |
| zyga | mborzecki: the best I can think of | 07:21 |
| zyga | mborzecki: for now | 07:21 |
| zyga | mborzecki: is that security tag becomes an interface that is implemented by a number of things | 07:21 |
| zyga | mborzecki: pluse a few special cases that wrap a string | 07:21 |
| mborzecki | zyga: hm looks like the only code validating security tags is in s-c now | 07:21 |
| zyga | yeah | 07:21 |
| mborzecki | zyga: and it's a regex, so i guess it's fine | 07:23 |
| zyga | yeag | 07:24 |
| zyga | yeah | 07:24 |
| zyga | it's a regex that says snap.$(snap name regex)(.hook)?.$(app name regex) | 07:25 |
| zyga | and one more weird variant, IIRC | 07:25 |
| zyga | on top of this I'd like to craft something that unifies all knowledge of security tags, documents it and puts validation functions that everything uses | 07:27 |
| zyga | we mostly always generate tags, not read them | 07:27 |
| zyga | so we didn't need much validation before | 07:27 |
| zyga | (in go, at least) | 07:27 |
| sdhd-sascha | good morning | 07:29 |
| mborzecki | zyga: sandbox/tags? or stuff that in snap/naming? | 07:30 |
| zyga | hey, good morning sdhd-sascha | 07:30 |
| zyga | mborzecki: I started snap/naming/sectag.go but not married to it | 07:31 |
| zyga | I think it's silly because of how we must be careful not to get import cycles | 07:31 |
| zyga | so eventual placement is really more related to where it compiles | 07:31 |
| zyga | hey mvo | 07:39 |
| mvo | hey zyga | 07:39 |
| mborzecki | mvo: hey | 07:44 |
| mvo | hey mborzecki | 07:45 |
| mvo | what did I miss this morning so far :) ? | 07:45 |
| mvo | how are tests looking? | 07:45 |
| zyga | I don't think you've missed much | 07:45 |
| zyga | tests are green | 07:46 |
| zyga | some red but probably branch related | 07:46 |
| zyga | mvo: schedule question, when do you cut | 07:49 |
| zyga | mvo: and if you cut now, do you anticipate another cut before release or is that it? | 07:49 |
| mvo | zyga: probably today | 07:53 |
| mvo | zyga: and no worries, we can always cherry pick | 07:53 |
| zyga | ok | 07:53 |
| mvo | zyga: but once branched there will be no merge from master anymore | 07:54 |
| mvo | zyga: like a full-one | 07:54 |
| zyga | that's fine | 07:54 |
| zyga | just wondering if everything you wanted in 2.43 is in master now | 07:54 |
| zyga | or is it likely we'll add more because there's known missing bits | 07:54 |
| sdhd-sascha | zyga: didn't found the time these days to get thing working. Is difficult to explain, if you do it for free | 07:57 |
| sdhd-sascha | zyga: Now i had another question | 07:57 |
| sdhd-sascha | i just modified and build snap & snapd | 07:57 |
| sdhd-sascha | And i don't want to replace the original | 07:58 |
| sdhd-sascha | How do you test the new installation on the same machine ? | 07:58 |
| sdhd-sascha | Or, do you use a vm ? I think about a user-systemd-service | 07:59 |
| zyga | sdhd-sascha: it varies | 08:01 |
| zyga | sdhd-sascha: it depends on what I changed | 08:01 |
| sdhd-sascha | zyga: wait, i build a .deb package. | 08:01 |
| zyga | sdhd-sascha: snapd vs snap-confine or other programs | 08:01 |
| sdhd-sascha | i have enougt machines. and can replace it | 08:02 |
| zyga | sdhd-sascha: I never build a distro package for that | 08:02 |
| zyga | sdhd-sascha: most often than not I use "make hack" or I build snapd and run it manually | 08:02 |
| sdhd-sascha | I want to replace the snap cmdline and snapd | 08:02 |
| zyga | sdhd-sascha: (just stop snapd.socket and snapd.service before) | 08:02 |
| zyga | sdhd-sascha: for snap command you can just run it from the tree (go build ./cmd/snap and run it) | 08:02 |
| pstolowski | morning | 08:03 |
| sdhd-sascha | zyga: until now i never wrote "go" before. So i just copied "strace", remove the timings and add "ltrace" into osutils/ltrace | 08:05 |
| zyga | sdhd-sascha: that's fine, go is easy to get into | 08:06 |
| zyga | sdhd-sascha: there are remarkably few quirks | 08:06 |
| sdhd-sascha | zyga: the unittests runs. | 08:06 |
| zyga | sdhd-sascha: perhaps open a draft PR, it will be easier to give advice this way | 08:07 |
| sdhd-sascha | zyga: if go had "tail-call optimization, then i would have started learning it earlier. | 08:09 |
| zyga | sdhd-sascha: if it mattered, it would be there ;) | 08:10 |
| sdhd-sascha | zyga: yes, i read about it. the solved anything by iteration. But the parser's api looks good at the first look ;-) | 08:11 |
| mup | PR snapd#7842 closed: tests: cache snaps also for ubuntu core and add new snaps to cache <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7842> | 08:12 |
| zyga | hmm | 08:15 |
| zyga | can a snap have an app that is just called "hook"? | 08:15 |
| pedronis | zyga: I don't think we have anything that would block that atm | 08:16 |
| zyga | right | 08:16 |
| zyga | just writing unit tests and got surprised | 08:16 |
| zyga | good morning pedronis :-) | 08:17 |
| zyga | wow | 08:18 |
| zyga | found a bug already | 08:18 |
| zyga | ValidateApp allows uppercase apps | 08:18 |
| zyga | but we don't allow that, do we? | 08:18 |
| zyga | at least, it was not allowed in the specs | 08:18 |
| * zyga checks other implementations | 08:19 | |
| mup | PR snapd#7775 closed: seed: support extra snaps on top of Core 20 dangerous models <UC20> <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7775> | 08:20 |
| zyga | mm | 08:21 |
| zyga | can app names have upper-cache characters? | 08:21 |
| mvo | \o/ another uc20 merged! | 08:21 |
| zyga | regexps say they do | 08:21 |
| * mvo hugs mborzecki | 08:21 | |
| zyga | my memory says they don't | 08:21 |
| pedronis | zyga: no | 08:22 |
| zyga | pedronis: we don't allow them? | 08:22 |
| pedronis | we don't | 08:22 |
| zyga | pedronis: then we need to fix a bunch of things first | 08:22 |
| zyga | pedronis: I'll part my branch and address that first | 08:22 |
| mborzecki | we have ValidApp = regexp.MustCompile("^[a-zA-Z0-9](?:-?[a-zA-Z0-9])*$") | 08:23 |
| pedronis | zyga: you can look at snap/naming/validate.go | 08:23 |
| zyga | yeah, I was there just now | 08:23 |
| zyga | writing tests and noticed one didn't fail as expected | 08:23 |
| pedronis | ah, sorry, we do | 08:23 |
| pedronis | I was confused | 08:23 |
| pedronis | I read snap name | 08:24 |
| pedronis | no, we allow them | 08:24 |
| pedronis | what we don't allow is . | 08:24 |
| zyga | pedronis: so name like package.FOO is okay? | 08:24 |
| zyga | (for an snap+app name)? | 08:25 |
| pedronis | seems so | 08:25 |
| zyga | ok then | 08:25 |
| zyga | back to my branch | 08:25 |
| zyga | :) | 08:25 |
| pedronis | mborzecki: hi, what's the status of #7570 ? | 08:31 |
| mup | PR #7570: [RFC] snap-mount-dir: add mount unit for snap-mount-dir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7570> | 08:31 |
| mborzecki | pedronis: i need to figure out the selinux errors that popped up there | 08:32 |
| mborzecki | #7840 is long but simple and could land easily | 08:37 |
| mup | PR #7840: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7840> | 08:37 |
| pedronis | mborzecki: could you push your suggestions to #7555 when you have a slice of time | 08:50 |
| mup | PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555> | 08:50 |
| mborzecki | pedronis: sure, can do | 09:01 |
| pedronis | mborzecki: thx | 09:01 |
| zyga | mborzecki: pushed updates to https://github.com/snapcore/snapd/pull/7825 | 09:08 |
| mup | PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825> | 09:08 |
| zyga | mborzecki: have a look when you can, most of your comments can be resolved now, I think | 09:11 |
| zyga | I need to break for 30 minutes | 09:11 |
| ackk | mvo, hi, so I've been testing a bit more with the maas snap, I do still see snapfuse using 100%cpu | 09:22 |
| ackk | mvo, I see maas-related processes keep being restarted, and I'm not sure if this is because they're responding too slowly because of the snapfuse issue or if it's unrelated | 09:23 |
| pedronis | ackk: do you know if data in the snap is getting accessed all the time? naively I would expect the snapfuse cpu usage to match access, and I would expect less access once things are running. maybe it's really a bug in snapfuse not just a perf issue | 09:27 |
| pedronis | though | 09:27 |
| ackk | pedronis, yeah there's a lot of I/O | 09:27 |
| pedronis | that sounds strange in itself | 09:28 |
| ackk | pedronis, I'm going to compare with the same snap unpacked and installed with try | 09:28 |
| mborzecki | pedronis: left a note under 7555, the snippet i proposed doesn't work on arch after all, guess it's the socket mediation that's still missing from the mainline | 09:31 |
| mborzecki | quick errand, back in 30 | 09:33 |
| pedronis | mborzecki: sounds like we should merge it as is then | 09:35 |
| pedronis | mvo: is #7817 ready for re-review? | 09:36 |
| mup | PR #7817: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7817> | 09:36 |
| ackk | pedronis, yeah so same snap downloaded and unpacked works fine | 09:39 |
| zyga | ackk: when you say there is lots of IO, can you explain what kind of data is maas reading after startup? | 09:40 |
| zyga | (from $SNAP) | 09:40 |
| ackk | zyga, there's a lot happening at maas startup, including reading a lot python files. I'm not sure if that's the cause, but what I see is that supervisord spawns the different processes (named dhcpd squid ...), no error in logs, then after a few seconds they get killed and respawned | 09:41 |
| ackk | that doesn't happen if I unpack the snap | 09:41 |
| mup | PR snapd#7844 opened: ignore visual studio code directory <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7844> | 09:42 |
| zyga | ackk: ah | 09:42 |
| zyga | so it's essentially perpetual startup | 09:42 |
| ackk | zyga, correct | 09:42 |
| zyga | I was trying to understand if there's, normally, lots of IO after startup | 09:42 |
| ackk | zyga, no | 09:42 |
| zyga | why do they crash? | 09:42 |
| ackk | zyga, I mean, there is if your're synching imagaes | 09:42 |
| ackk | zyga, no idea, nothing in logs | 09:43 |
| zyga | can you see them via systemctl status | 09:43 |
| mup | PR snapd#7845 opened: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7845> | 09:43 |
| zyga | I guess no, because supervisord | 09:43 |
| ackk | zyga, correct | 09:43 |
| zyga | well, that's something to debug then | 09:43 |
| ackk | I'm going to try in a fresh container | 09:44 |
| mup | PR snapd#7837 closed: devicestate: implement creating partitions in "install" mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7837> | 09:46 |
| mvo | pedronis: yes, I updated it this morning | 09:47 |
| mvo | pedronis: once that is in I have a simple followup that adds this call to the install handler in devicestate | 09:47 |
| ackk | pedronis, zyga not sure if my message got through before the split | 10:01 |
| === igordhossegor is now known as 07EABDLLI | ||
| mup | PR snapd#7846 opened: devicestate: add missing test for failing task setup-run-system <Simple ๐> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7846> | 10:11 |
| zyga | ackk: I didn't see it | 10:12 |
| pstolowski | Chipaca: ping | 10:23 |
| Chipaca | pstolowski: pong | 10:24 |
| pstolowski | Chipaca: i've updated/tweaked your check-skeleton PR but for some reason coudn't push to your PR; mind merging my changes from https://github.com/stolowski/snapd/tree/check-skeleton-check-interfaces if you're ok with them? | 10:25 |
| Chipaca | sure | 10:26 |
| Chipaca | you should be able to just push tho | 10:26 |
| Chipaca | pstolowski: what error does it give you? | 10:26 |
| pstolowski | Chipaca: nvm! i had your remote with https:// ; worked with ssh:// | 10:29 |
| Chipaca | pstolowski: :-D yeah happens | 10:29 |
| pedronis | pstolowski: thanks, I put it in my queue for re-review | 10:30 |
| pstolowski | pedronis: there is one remaining remark from you about moving ParseMountEntry to shared. no strong opinion about that, can do | 10:31 |
| pedronis | pstolowski: I'll look again, is not a blocker either way | 10:31 |
| mborzecki | re | 10:37 |
| pedronis | pstolowski: btw, I'm doing a pass again on some of your pre-seeding PRs | 10:37 |
| pstolowski | pedronis: ty, just saw your comments | 10:37 |
| pstolowski | mborzecki: do you have a moment to finish the review of https://github.com/snapcore/snapd/pull/7697 ? | 10:38 |
| mup | PR #7697: interfaces/apparmor: handle pre-seeding mode <Preseeding ๐> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7697> | 10:38 |
| mborzecki | pstolowski: sure, will do | 10:39 |
| mup | PR snapd#7697 closed: interfaces/apparmor: handle pre-seeding mode <Preseeding ๐> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7697> | 10:55 |
| mborzecki | pretty annoying how github doesn't let you know the PR you're commenting on has been updated | 11:02 |
| pedronis | pstolowski: question in #7320 | 11:08 |
| mup | PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320> | 11:08 |
| pedronis | pstolowski: thx | 11:18 |
| mup | PR snapd#7847 opened: Parse seed if either kernel or base are not mounted <Created by xnox> <https://github.com/snapcore/snapd/pull/7847> | 11:19 |
| mborzecki | snap run --strace hanging on 16.04 too: https://paste.ubuntu.com/p/FGK8JysymF/ | 11:22 |
| mup | PR snapd#7848 opened: Mount ubuntu-data tmpfs, in one go with kernel & base <Created by xnox> <https://github.com/snapcore/snapd/pull/7848> | 11:23 |
| * Chipaca gets coffee | 11:27 | |
| mborzecki | has anyone noticed that when there's a change in progress, and it's currently downlaoding a snap, runnig snap change in a separate terminal takes really long to show anything? | 11:39 |
| zyga | yeah | 11:44 |
| zyga | lock contention | 11:45 |
| zyga | we update the status a lot | 11:45 |
| mborzecki | wonder if that's beacuse of re-refresh taking state lock too often | 11:45 |
| zyga | perhaps that's that, though I didn't debug it that deep | 11:45 |
| zyga | re-refresh? | 11:45 |
| mborzecki | since it basically tries to run all the time | 11:45 |
| zyga | oh | 11:45 |
| zyga | perhaps | 11:45 |
| zyga | we could use read locks | 11:45 |
| zyga | and write locks | 11:45 |
| zyga | perhaps that would help reading the status | 11:46 |
| zyga | (or, you know, a real database) | 11:46 |
| mborzecki | or use the tracing endpoints and find out whihc lock is hit most often :P | 11:46 |
| pedronis | it runs every 100ms, I wouldn't call it all the time | 11:47 |
| pedronis | but could be | 11:47 |
| pedronis | mborzecki: if there's a download going, there is the progress updates and polling as well | 11:48 |
| mborzecki | iirc there were also some patches from mvo to make download updates more coarse | 11:48 |
| pedronis | mborzecki: anyway my point is that before fixing we need to know what is happening exactly, I wouldn't make changes based on speculation | 11:50 |
| mborzecki | yup | 11:51 |
| zyga | 100ms is a bit excessive | 11:51 |
| mvo | zyga: do you think you could check 7823 again? I fixed the bits you raised there | 11:52 |
| zyga | yup | 11:52 |
| mvo | mborzecki: yeah, it was really crazy in the past, it would update the progress for every packet basicly but that got fixed | 11:53 |
| zyga | mvo: done | 11:54 |
| mvo | thank you zyga ! | 11:54 |
| mup | PR snapd#7823 closed: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7823> | 11:54 |
| mup | PR snapd#7844 closed: gitignore: ignore visual studio code directory <Created by sd-hd> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7844> | 12:00 |
| mborzecki | pedronis: thanks for the feedback in #7821, applied it | 12:07 |
| mup | PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821> | 12:07 |
| mborzecki | oh and it needs a 2nd review | 12:07 |
| pedronis | mvo: did you see my question whether 7817 can be re-reviewed ? | 12:08 |
| Chipaca | zyga: why is cmd/snaplock a thing? why isn't it in osutil? | 12:10 |
| Chipaca | we've put some random stuff in cmd but only when it was used from daemon and client and there wasn't a clear place for it | 12:11 |
| zyga | Chipaca: it was placed there after code review | 12:11 |
| Chipaca | and the imports were wrong for *util | 12:11 |
| pedronis | Chipaca: it uses dirs, it not a util | 12:12 |
| Chipaca | here the imports are simple, and it's used from cmd/foo but also from overlord/snapstate | 12:12 |
| pedronis | it's very specific | 12:12 |
| Chipaca | pedronis: we already use dirs from osutil | 12:12 |
| pedronis | we don't | 12:12 |
| Chipaca | do so | 12:12 |
| Chipaca | osutil/strace/ | 12:12 |
| pedronis | strace then is also wrongly placed | 12:13 |
| Chipaca | putting libraries under cmd/ is not a nice thing | 12:13 |
| pedronis | Chipaca: putting things in util that are very snap layout specific is worse | 12:14 |
| Chipaca | maybe we should set aside an afternoon at a sprint or something and do an on-paper reorg | 12:14 |
| pedronis | anyway strace is misplaced as is | 12:14 |
| pedronis | Chipaca: snaplock is also there because the lock is also implemented in C similary for snap-confine | 12:15 |
| pedronis | Chipaca: notice that we have C libraries in cmd | 12:15 |
| Chipaca | myeah | 12:15 |
| pedronis | Chipaca: so basically as I see your point but it's more complicated, bleeding non utility things into *util is still worse in my book | 12:16 |
| pedronis | it means you cannot expect them to be isolated | 12:17 |
| pedronis | which as util they should | 12:17 |
| zyga | pedronis: for the record | 12:17 |
| zyga | pedronis: they are in cmd because there was aversion to a makefile in top level | 12:17 |
| zyga | pedronis: otherwise they could be anywhere | 12:18 |
| pedronis | well we could have a different directory and some more Makefile fun | 12:18 |
| pedronis | I'm personally not very offended either way | 12:18 |
| pedronis | I mean by libraries under cmd vs not | 12:18 |
| zyga | I think we could use a top-level makefile that cleans up various per-directory makefile things | 12:19 |
| zyga | (separate of the library discussion) | 12:19 |
| zyga | it would allow us to reuse bits and not define the same things over inconsistently (e.g. libexecdir) | 12:19 |
| zyga | brb | 12:21 |
| mup | PR snapd#7849 opened: osutil: cmd: add ltrace <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7849> | 12:22 |
| zyga | 15 minute break, kids home | 12:22 |
| sdhd-sascha | zyga: just created PR for "ltrace" | 12:22 |
| zyga | sdhd-sascha: cool, I'll check it out in a while | 12:23 |
| sdhd-sascha | zyga: hope, i didn't make mistakes ... i really need to learn go first ;-) | 12:23 |
| pedronis | mborzecki: thansk for the changes, they were not blockers, I made a follow up nitpick remark though | 12:25 |
| pedronis | Chipaca: but yes I agree we need to reorg our code, there is too much things at top-level and some less than clean bits. OTOH can only be done when the open PRs are under control given the churn | 12:27 |
| mborzecki | hm we still have fwupd-refresh.service starting in debian-sid images | 12:29 |
| mborzecki | cachio: ^^ wasn't that explicitly disabled/removed at somep oint? | 12:29 |
| cachio | mborzecki, yes, the script has been updated | 12:31 |
| cachio | but the image is autogenerated on monday | 12:31 |
| cachio | I can manuallly trigger the update now if it makes sense | 12:31 |
| cachio | I just tested the script is it is disabling correctly the service | 12:31 |
| cachio | on debian 9 and sid | 12:32 |
| mborzecki | cachio: please do, the tests/main/degraded test keeps failing on sid | 12:32 |
| mborzecki | randomly | 12:32 |
| cachio | mborzecki, ok, I'll do it | 12:32 |
| mborzecki | cachio: thanks! | 12:32 |
| cachio | mborzecki, np | 12:33 |
| cachio | running | 12:33 |
| mup | PR snapcraft#2831 closed: appstream extractor: add support for code <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2831> | 12:40 |
| zyga | re | 12:43 |
| zyga | back with hot tea | 12:43 |
| zyga | sdhd-sascha: is sudo required there? | 12:43 |
| sdhd-sascha | not sure, on my test machine i runs without sudo | 12:44 |
| zyga | sdhd-sascha: ok, I _suspect_ it may not be required, unlike strace | 12:44 |
| sdhd-sascha | zyga: you mean "sudo snap run --ltrace ..." ? | 12:44 |
| zyga | no, I mean, internally can it not use sudo and still work | 12:44 |
| sdhd-sascha | zyga: most of the code is adapted from strace . And the commands are very similar | 12:45 |
| zyga | yeah but the reason is different | 12:45 |
| zyga | strace uses ptrace | 12:45 |
| sdhd-sascha | but there is no static ltrace and no timings | 12:45 |
| zyga | ltrace seems to only use it in a debug code | 12:45 |
| zyga | it would be good to check if it's really required | 12:45 |
| zyga | one more thing | 12:45 |
| zyga | can you look at tests/main/snap-run | 12:45 |
| zyga | and there at task.yaml | 12:45 |
| zyga | it exercises snap run --strace | 12:46 |
| zyga | it would be good to extend that to ltrace | 12:46 |
| zyga | I can tell you how to run those tests | 12:46 |
| sdhd-sascha | zyga: HACKING.md: "### Running spread tests" ?? | 12:47 |
| zyga | yes | 12:48 |
| zyga | not sure how correct that is | 12:48 |
| zyga | I guess you will find out | 12:48 |
| sdhd-sascha | zyga: sure -- it's little bit cold here ... good time to start some vm's on the server ;-) :-D | 12:49 |
| pedronis | zyga: where does snap-update-ns output finishes here: https://github.com/snapcore/snapd/pull/7728/files#diff-e4c8d0c72c7b412376e0a04e6ad4db41 ? | 12:57 |
| mup | PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728> | 12:57 |
| zyga | pedronis: because that example doesn't use a mount profile | 12:57 |
| zyga | pedronis: there should be a [snap-confine (returning)] section or something like that | 12:58 |
| zyga | I'm looking at that no | 12:58 |
| zyga | just adding headers via << >> first | 12:58 |
| pedronis | well I wanted to play with << >> first | 12:58 |
| pedronis | not sure they are better | 12:58 |
| zyga | pedronis: yeah, I added Header() so it's easy to change :) | 12:58 |
| pedronis | I wanted to give you a changed .in | 12:59 |
| zyga | ok | 12:59 |
| zyga | go ahead, I'll integrate it | 12:59 |
| zyga | I think we need to expand the test though, it doesn't handle enough of explain cases yet | 12:59 |
| zyga | but it's a good first start for now | 12:59 |
| * Chipaca wonders what the area under a patch is, to integrate it | 13:01 | |
| zyga | Chipaca: it's just len(bytes) :D | 13:02 |
| sdhd-sascha | zyga: this line in HACKING.md is scary: "curl https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz | tar -xz -C $GOPATH/bin" | 13:02 |
| sdhd-sascha | i will build this from repo. | 13:02 |
| zyga | you can build it | 13:02 |
| Chipaca | sdhd-sascha: or snap install spread | 13:03 |
| Chipaca | although that one's a little old | 13:03 |
| * Chipaca promised to update it and has only found 1h to work on it so far | 13:03 | |
| sdhd-sascha | Chipaca: +1 | 13:03 |
| mborzecki | ijohnson: quite puzzled that SNAP_CONTEXT is not triggered when running run-checks | 13:04 |
| pedronis | zyga: my question was where would that snap-confine returning be placed ? After the whole Configuring mount namespace according to mount profile section? | 13:04 |
| mborzecki | ijohnson: can you bash -x run-check --unit maybe? | 13:04 |
| ijohnson | mborzecki: sure after I finish breakfast :-) | 13:06 |
| mborzecki | ijohnson: hah sure ;) enjoy your breakfast | 13:06 |
| sdhd-sascha | Chipaca: What's need to be updated there ? | 13:06 |
| cmatsuoka | mvo: with #7837 landed, can #7762 be closed? | 13:06 |
| mup | PR #7837: devicestate: implement creating partitions in "install" mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7837> | 13:06 |
| mup | PR #7762: devicestate: core 20 install mode handling <UC20> <โ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7762> | 13:06 |
| Chipaca | sdhd-sascha: the snap package has a few issues, that i'm wanting to fix | 13:07 |
| Chipaca | sdhd-sascha: like not being able to access ~/.spread for example :) | 13:07 |
| Chipaca | sdhd-sascha: and not having a runnable kvm in it either | 13:08 |
| sdhd-sascha | Chipaca: ah, ok - i will try it ;-) | 13:09 |
| zyga | pedronis: the returning message is in snap-confine | 13:10 |
| zyga | pedronis: I added Header now but I'll wait for your call to change it to << >> or whatever else | 13:11 |
| mvo | cmatsuoka: can be useful for reference, but it's fine to close it | 13:11 |
| pedronis | zyga: I'm trying with <<, not super happy though, mostly because they don't take up vertical space | 13:12 |
| pedronis | also pastebin doesn't like my paste atm | 13:13 |
| cmatsuoka | mvo: ok. I'll add a comment listing the split PRs | 13:13 |
| zyga | oh? | 13:13 |
| zyga | ah, pastebin doesn't like <> | 13:14 |
| zyga | evil html javascript hackers | 13:14 |
| Chipaca | use kannada | 13:14 |
| mvo | cmatsuoka: thank you | 13:15 |
| pedronis | zyga: not sure, seems to have problems | 13:15 |
| pedronis | zyga: anyway I tried this: https://gist.github.com/pedronis/93703067a720d6ddce49cf6351f44ca5 | 13:16 |
| zyga | looking | 13:16 |
| pedronis | notice that << is one change, the others are indentation and I reformulated one thing | 13:16 |
| zyga | ok | 13:16 |
| zyga | let me compare | 13:16 |
| Chipaca | fwiw i meant แธแณ instead of <> but was mostly joking (as is https://github.com/vasilevp/aboriginal ) | 13:18 |
| pedronis | zyga: btw, do you remember why you picked [ ] initially ? they make me think of .ini files tbh | 13:19 |
| zyga | pedronis: we just tried things until it looked good enough | 13:20 |
| mup | PR snapd#7762 closed: devicestate: core 20 install mode handling <UC20> <โ Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7762> | 13:20 |
| pedronis | zyga: anyway as I said, not super happy with << either | 13:20 |
| pedronis | need to think a bit | 13:20 |
| pstolowski | pedronis:, Chipaca #7320 is green, ok to land? | 13:23 |
| mup | PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320> | 13:23 |
| Chipaca | pstolowski: thank you | 13:24 |
| pedronis | mborzecki: another comment in 7821, sorry | 13:25 |
| mborzecki | pedronis: haha i should get another coffee | 13:25 |
| mup | PR snapd#7320 closed: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7320> | 13:25 |
| === ricab is now known as ricab|lunch | ||
| zyga | pedronis: applied, double checking if it passes and if I missed anything | 13:35 |
| zyga | pedronis: I'll push when ready | 13:35 |
| zyga | pedronis: as for headers, perhaps for explain we could use terminal features (colors, bold, etc)? | 13:36 |
| pedronis | zyga: possibly yes, maybe Chipaca has input on that | 13:39 |
| Chipaca | maybe :) | 13:41 |
| Chipaca | zyga: what headers? | 13:41 |
| zyga | Chipaca: please look at https://gist.github.com/pedronis/93703067a720d6ddce49cf6351f44ca5 | 13:41 |
| zyga | Chipaca: headers are << foo >> lines | 13:41 |
| Chipaca | ah | 13:42 |
| Chipaca | nice | 13:42 |
| Chipaca | hm | 13:42 |
| Chipaca | do we want this to be parseable in any way? | 13:43 |
| Chipaca | i don't know if the first line is a message to the user or a feature or a complaint :-) | 13:43 |
| pedronis | no, I don't think parseable is a requirement | 13:44 |
| pedronis | we likely would do something very different if it was meant for machine consumption | 13:45 |
| Chipaca | ok | 13:47 |
| sdhd-sascha | Should we remove *.deb packages ? because on master it isn't buildable | 13:47 |
| Chipaca | sdhd-sascha: ? | 13:47 |
| Chipaca | sdhd-sascha: master should be buildable to a .deb (and an .rpm) | 13:48 |
| Chipaca | sdhd-sascha: in fact we build it to a deb every spread run | 13:48 |
| Chipaca | and i think we also build an rpm every test run but am not 100% sure | 13:48 |
| sdhd-sascha | Chipaca: on thought it was on my local machine, but then i tested it on https://launchpad.net/~sdhd/+archive/ubuntu/snapcore/+build/18206983 | 13:50 |
| sdhd-sascha | it's master plus my small patches | 13:50 |
| sdhd-sascha | Chipaca: i will look later, maybe something wrong with the recipe ?... | 13:52 |
| ijohnson | mborzecki: so when I run with run-checks, it seems that all of the packages are listed in the cmdline to `go test ...` but if I just do `go test ./...` in the root of the git repo I hit that test failure every time | 13:52 |
| mvo | pedronis: a (maybe high-level?) review of 7817 would be great | 13:52 |
| jdstrand | mborzecki: hey, fyi https://github.com/snapcore/snapd/pull/7555#discussion_r354323376 | 13:52 |
| mup | PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555> | 13:52 |
| mborzecki | jdstrand: thanks for the comment, let me check that again, but there was no denial related to the session agent socket | 13:55 |
| jdstrand | mborzecki: there would not be if you went to forced devmode. check the profile | 13:56 |
| mborzecki | jdstrand: there was one related to dac override when i executed part of the test that runs curl as root | 13:56 |
| mborzecki | jdstrand: ok, let me start the test again | 13:57 |
| ijohnson | mborzecki: actually it's that run-checks will sneakily find go 1.10 to run my tests with, even though I have go 1.13 installed and that specific test fails on go 1.13 but works on go 1.10 | 13:57 |
| jdstrand | mborzecki: you may also want: sudo sysctl -w kernel.printk_ratelimit=0 | 13:57 |
| pedronis | mvo: ok | 13:58 |
| jdstrand | mborzecki: to avoid kernel rate limiting. also, if you are ever thinking that the kernel is rate limiting, reload the profile and try again (even with the above sysctl, this is still needed with, for example, capability denials) | 13:59 |
| niemeyer | > i will build this from repo. | 14:01 |
| niemeyer | sdhd-sascha: Make sure you read the source.. :) | 14:02 |
| sdhd-sascha | niemeyer: :-D | 14:02 |
| jdstrand | mborzecki: not sure what your local test was, but keep in mind, test -S won't trigger the denial. | 14:02 |
| mborzecki | jdstrand: the test is what's done in 7555 | 14:03 |
| jdstrand | mborzecki: ok, so if you ran spread, then look at test-snapd-curl.curl's profile to see if it is the classic template. if not, see if there are any matching rules | 14:05 |
| mup | Bug #1617302 changed: Specifying a nonexistent plug does cause any errors <Snapcraft:Triaged> <snapd:Fix Committed by chipaca> <https://launchpad.net/bugs/1617302> | 14:09 |
| mborzecki | ijohnson: your go 1.13 is from a snap right? so SNAP_CONTEXT would be set when you run `go test ./...` | 14:11 |
| ijohnson | mborzecki: yes | 14:11 |
| ijohnson | mborzecki: it fails with go 1.10 as a snap too, so that's all it is | 14:13 |
| mborzecki | ijohnson: ok, easy to check, https://play.golang.org/p/_MvNzO2qf3i should print the actual context | 14:13 |
| mborzecki | ijohnson: if you go run it with 1.13 | 14:13 |
| jdstrand | mborzecki: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/lsm_hooks.h#n763 | 14:15 |
| jdstrand | "Whereas binding and connecting to sockets in the file name space is mediated by the typical file permissions (and caught by the mknod and permission hooks in inode_security_ops), ..." | 14:15 |
| ijohnson | mborzecki: yes you're right it's just any go version from a snap will fail that test, I left a comment in the PR | 14:16 |
| mborzecki | jdstrand: nice, thanks for the link! | 14:16 |
| jdstrand | np | 14:16 |
| Wouter0100 | Hey guys! I've spend my time today figuring out Ubuntu Core a bit, and seems awesome. Although, I have another question (the first one I asked on the forums, which got answered quickly, thanks for that! <3): how is the update from Ubuntu Core 16 to 18 planned for devices in the wild, and maybe later from 18 to 20? Will this also in a transactional | 14:18 |
| Wouter0100 | manner? Or is this something that isn't going to be automated? | 14:18 |
| Wouter0100 | I've seen a core16 and a core18 snap, and someone nearly succeeded in just upgrading this snap - but will there be some official procedure? | 14:18 |
| ogra | 16 to 18 is kind of -> send someone out with USB key :) | 14:32 |
| ogra | core20 will have a new cool feature called re-modeling that will exactly cover switching to a new version ... but at the same time core20 will also come with a completely new partitioning scheme out of the box ... not sure if that will be covered ... | 14:33 |
| ogra | pedronis, ^^^ do you know ? | 14:34 |
| Wouter0100 | Oeh, that's fancy! Any release schema for core20? Because we are also still developing the Ubuntu Core setup, and when it'll be released in beginning of 2020, we should be able to wait for that just fine :). | 14:37 |
| pedronis | ogra: remodeling is not core20 only | 14:37 |
| Wouter0100 | And I think that the migration to Ubuntu Core will happen with sending someone out with a USB stick :P | 14:37 |
| ogra | sure, but if you can keep the frequency low i bet thats better :) | 14:38 |
| === ricab|lunch is now known as ricab | ||
| ogra | pedronis, ah, so core18 will get it too ? | 14:38 |
| pedronis | yes | 14:38 |
| ogra | then i take back the USB statement :) | 14:39 |
| ogra | the beauty of rolling releases :) | 14:39 |
| Wouter0100 | Indeed, the company I'm developing this software for does not really like the fact that they've to send an engineer throughout NL :-P. Luckily it's a small country, but still | 14:39 |
| Wouter0100 | Oh, thats awesome! So then I'm just able to continue with core18 and when remodeling is released I will be able to upgrade to core20?! ๐ | 14:40 |
| ogra | technically yes ... practically there is that new partitioning scheme .... not sure how that will be handled during re-model | 14:40 |
| Wouter0100 | I see | 14:41 |
| ogra | i know mborzecki did an awesome job doing gadget upgrades (which holds the partitioning info) but i dont know if that will be integrateable with re-modeling | 14:41 |
| mborzecki | ogra: we do upgrade gadget during remodel, but the scheme must be compatible (the same to be exact) | 14:42 |
| ogra | yeah, thats what i feared | 14:42 |
| ogra | so 18 to 20 might be tricky | 14:42 |
| ogra | unless we start soon with providing core18 images with the same partitioning scheme that core20 will have | 14:43 |
| ogra | (or at least example gadgets for customers to base on) | 14:44 |
| mvo | Wouter0100: we plan to support 16->18 via the network, there shouldn't be any need for a usb stick here. it's a special case of the "remodel" feature that got recently added | 14:44 |
| mvo | 18->20 is a bit more fuzzy at this point but I'm pretty sure we will support it, it may just be that you won't get some of the advanced features like recovery/encryption because the partition layout of 16/18 is not flexible enough for this | 14:44 |
| pedronis | ogra: we are recommending/considering that for some of the recent core 18 projects, to start with a more compartible layout, at least to have the space | 14:45 |
| ogra | pedronis, yeah, we should start pointing people to the example gadget.yaml so they know what partitions are needed | 14:46 |
| pedronis | don't think we have plans to do that for the references images though | 14:46 |
| ogra | yep, understood | 14:46 |
| * zyga is in a car now | 14:47 | |
| zyga | pedronis: please have a look at https://github.com/snapcore/snapd/pull/7728 again, | 14:47 |
| mup | PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728> | 14:47 |
| zyga | I think the expected.in file is now what you specified | 14:47 |
| mup | PR snapd#7850 opened: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7850> | 14:48 |
| Wouter0100 | I see, awesome. Then i'll have a look if I'm able to use the new partition layout for 18. And encryption? Is that something coming in 20? As I've discussed that with my customer that I'm developing this for, and at first said it wasn't possible - but if that would be possible in 20 - some additional leverage to get Ubuntu Core through :) | 14:49 |
| mvo | Wouter0100: it will come with UC20 (encryption) | 14:51 |
| Chipaca | but later in 20, right? | 14:52 |
| mup | PR snapd#7851 opened: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7851> | 14:52 |
| Wouter0100 | mvo that's awesome | 14:55 |
| mvo | Chipaca: well, potentially later, we aim still to release with it but it will be a challenge :/ | 14:56 |
| Wouter0100 | When will UC20 release then? :O | 14:56 |
| Wouter0100 | Or no ETA planned? | 14:57 |
| * cachio lunch | 14:57 | |
| zyga | Wouter0100: 20.04 AFAIR | 14:57 |
| mvo | Wouter0100: roughly at the same time as 20.04 is what we aim for. no exact date set yet though. and we want to have the encryption ready by that date but it's a complex feature that we need to get right so this part *might* slip | 14:58 |
| mvo | but we *really* want to have it as part of the first uc20 release and work very hard to make this happen | 14:59 |
| pedronis | 20.04 is for amd64 | 15:01 |
| mvo | pedronis: indeed | 15:02 |
| mvo | sorry, did I miss some context and this was about non amd64? the non-amd64 will come a bit later, not april 2020 | 15:02 |
| mborzecki | jdstrand: this is weird https://paste.ubuntu.com/p/8FWf5S8rcv/ | 15:03 |
| pedronis | mvo: I'm not sure, just making clear that 20.04 is not for all archs | 15:03 |
| mvo | +1 | 15:03 |
| jdstrand | mborzecki: is the curl command actually talking to the right thing? you can snap run --shell and try the head and the curl | 15:07 |
| jdstrand | mborzecki: fyi, for hpage_pmd_size: https://github.com/snapcore/snapd/pull/7850 | 15:08 |
| mup | PR #7850: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Simple ๐> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7850> | 15:08 |
| mborzecki | jdstrand: this is even more interesting https://paste.ubuntu.com/p/Wk4GHjfQKJ/ | 15:08 |
| mborzecki | jdstrand: and it's using the same path | 15:10 |
| jdstrand | mborzecki: hmm. so, seems like there is something fishy going on in the snap run/snap-confine areas | 15:10 |
| jdstrand | I think an strace is in order to see how snaap-confine is being invoked | 15:11 |
| mborzecki | jdstrand: but the last paste is without s-c, just system curl vs head under the same profile, curl works, but head is blocked | 15:11 |
| Wouter0100 | mvo i see, thanks! | 15:11 |
| jdstrand | mborzecki: oh, I misread that. need to strace that first one | 15:12 |
| mborzecki | jdstrand: it's doing connect https://paste.ubuntu.com/p/nZvBJjJtW3/ maybe that isn't mediated as per file hooks? | 15:13 |
| pedronis | pstolowski: it's not hookstate importing ifacestate, it's hookstate/ctlcmd right? | 15:16 |
| Wouter0100 | Is there any way for a snap to postpone a refresh by a couple of minutes or houes? The snap I develop sometimes requires to be not interrupted. I could schedule | 15:17 |
| Wouter0100 | I could schedule the refreshes for in the night, but can't guarantee that it'll be possible then. I've also seen a feature for network manager to postpone a refresh when on metered connection, but no hook or other ability to integrate this in my snap | 15:18 |
| pedronis | Wouter0100: not yet, but is a planned feature | 15:18 |
| ijohnson | hmm is there not a "AsDesigned" status for lp bugs? I seem to remember there was but perhaps that was another old bug tracker | 15:18 |
| ijohnson | WontFix seems the closest to this | 15:19 |
| Chipaca | ijohnson: nope, no asdesigned on launchpad | 15:19 |
| pedronis | yea, it needs to be WontFix | 15:19 |
| ijohnson | yeah must have been another bug tracker I'm thinking of | 15:19 |
| Chipaca | ijohnson: no LolNo either :-( | 15:19 |
| ijohnson | Chipaca: what about OMFGYASSS ? | 15:19 |
| Wouter0100 | pedronis awesome! Do you know the issue for that? Can't seem to find it. I might try to contribute such thing myself - if that's allowed. | 15:20 |
| mborzecki | jdstrand: ok, using the same code for both scenarios and path is used explicitly, https://paste.ubuntu.com/p/GKTxkfH2GY/ | 15:20 |
| ogra | Wouter0100, just work with the various channels ... leave your install on stable (or beta) and do all your work in edge ... only push it up to the next channel when you think it is ready | 15:21 |
| Chipaca | ijohnson: is that a Status, or an Importance? | 15:21 |
| ijohnson | both imho | 15:21 |
| Chipaca | :) | 15:21 |
| * ijohnson stops distracting people | 15:21 | |
| * ijohnson for now | 15:21 | |
| pedronis | Wouter0100: no issue yet, it needs to interact with permissioning because we dont want to allow arbitrary delays. Also usually a snap needs to stop refreshes of more than itself | 15:22 |
| Wouter0100 | Yeah, that's correct.. also for some networking snaps possibly. And I see, a more complicated matter. | 15:23 |
| pstolowski | pedronis: yes yes | 15:24 |
| pedronis | pstolowski: that's totally fine | 15:24 |
| pedronis | ctclmd is slightly oddly placed itself but that's different matter | 15:25 |
| pedronis | pstolowski: ifacestate imports hookstate so that import would not have worked | 15:25 |
| mup | PR snapd#7852 opened: devicestate: call boot.MakeRunnable() in devicestate <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7852> | 15:26 |
| pstolowski | pedronis: right | 15:29 |
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| zyga | jdstrand, mborzecki: what's going on? | 15:29 |
| pedronis | pstolowski: +1 with two comments, one is really for a follow up at this point | 15:30 |
| mborzecki | zyga: see my last paste, there's a /run/user/12345/snapd-session-agent.socket, the test in #7555 checks that the snap cannot access it, the check fails on arch | 15:30 |
| mup | PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555> | 15:30 |
| zyga | mborzecki: do you have denials? | 15:31 |
| zyga | what's the permission on the socket? | 15:31 |
| zyga | mborzecki: did we rule out DAC? | 15:31 |
| jdstrand | zyga: it is failing open | 15:31 |
| zyga | mborzecki: ah, wait, so the test fails because you *can* access it? | 15:32 |
| zyga | jdstrand: right | 15:32 |
| mborzecki | zyga: connecting using python (no s-c or snaps involved), while running with the profile, can access it as the user (unexpected), but not as root (expected) | 15:32 |
| zyga | mborzecki: can you pastebin the apparmor profile for the snap please | 15:32 |
| zyga | I'm in a car but I can look | 15:32 |
| zyga | (not driving) | 15:32 |
| jdstrand | mborzecki: I'm in two different conversations and will circle back to this in a few minutes | 15:33 |
| mborzecki | jdstrand: sure | 15:33 |
| zyga | jdstrand: hey, can you try to review snap-explain patches, just the snap-confine C changes | 15:33 |
| zyga | jdstrand: there are two printing functions there, some getenv | 15:33 |
| zyga | jdstrand: but you need to look if we hope of having it for 2.43 | 15:33 |
| mborzecki | zyga: https://paste.ubuntu.com/p/N2r2n5T26b/ | 15:34 |
| mborzecki | zyga: oh, and it's on arch | 15:34 |
| jdstrand | zyga: it is on the list. there are a pile of store reviews I need to tend to though first | 15:34 |
| zyga | thx | 15:34 |
| zyga | jdstrand: ack, no rush, it's not a priority item, just a nice-to-have | 15:34 |
| jdstrand | zyga: I'll try later today/tomorrow | 15:34 |
| zyga | thanks | 15:34 |
| zyga | mborzecki: what's the owner of the socket? | 15:35 |
| mborzecki | zyga: the test user, it's a session service | 15:35 |
| pstolowski | pedronis: thanks | 15:35 |
| zyga | mborzecki: owned by 12345? | 15:35 |
| mborzecki | zyga: yup | 15:36 |
| zyga | mborzecki: can you try to run apparmor parser | 15:36 |
| zyga | mborzecki: and get a pre-processed profile | 15:36 |
| zyga | mborzecki: with all includes resolved | 15:36 |
| zyga | mborzecki: it could be an arch bug in the include statements | 15:36 |
| zyga | mborzecki: (in the things that get included) | 15:36 |
| zyga | I'd tell you the command but I'm on fedora now | 15:36 |
| zyga | mborzecki: if you get that please pastebin the result | 15:37 |
| mborzecki | zyga: this shoudl be it https://paste.ubuntu.com/p/yNTxCKq5Wh/ | 15:38 |
| zyga | k | 15:39 |
| zyga | mborzecki: nothing, it's good :/ | 15:39 |
| zyga | well | 15:39 |
| zyga | magic | 15:39 |
| mborzecki | it's 5.4.1 kernel, in case that matters | 15:39 |
| pedronis | mvo: I did a pass on 7817 | 15:47 |
| zyga | mborzecki: is this a regression? | 15:48 |
| mborzecki | hmmm, good question, there's isn't much of an older kernel in arch to try out ;) | 15:59 |
| mvo | pedronis: THANK YOU | 15:59 |
| mvo | pedronis: :) | 15:59 |
| mvo | pedronis: in a meeting now, but will jump to it right after | 15:59 |
| zyga | mborzecki: is this a new test? | 16:00 |
| mborzecki | zyga: yes, #7555 | 16:01 |
| mup | PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555> | 16:01 |
| zyga | Aha | 16:01 |
| zyga | Does it pass on tumbleweed? | 16:02 |
| mborzecki | zyga: it's supposed to run on ssytems with strict confinement, i recommended looking at specific features, jdstrand pointed me to relevant part of kernel where unix socket connect should be mediated as file operations, but it's failing (?) | 16:02 |
| mborzecki | zyga: i think we degrade the apparmor profile on TW | 16:02 |
| zyga | We do not | 16:04 |
| pedronis | mvo: I don't understand why we need MakeRunnable now that we pass options to MakeBootable | 16:04 |
| pedronis | well, we don't but we could/should | 16:09 |
| ijohnson | pstolowski: mborzecki: does this PR description look ok now? https://github.com/snapcore/snapd/pull/7843#issue-349074423 | 16:12 |
| mup | PR #7843: tests/cmd/snapctl: unset SNAP_CONTEXT for the suite <Simple ๐> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7843> | 16:12 |
| pstolowski | ijohnson: yes | 16:14 |
| mborzecki | ijohnson: yeah, land it | 16:15 |
| pedronis | zyga: what is the purpose of decode-mounts-opts ? I don't see it invoked anywhere | 16:18 |
| ijohnson | done | 16:18 |
| mup | PR snapd#7843 closed: tests/cmd/snapctl: unset SNAP_CONTEXT for the suite <Simple ๐> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7843> | 16:18 |
| mborzecki | pedronis: iirc the pr using that is still on review | 16:19 |
| mvo | pedronis: I'm happy to change it so that we can use MakeBootable() for that we need a way to say if it's from PrepareImageTime or from install time. I could add something to "BootsWith" or I could add "opts *bootloader.Options" to MakeBootable (but then we would import bootloader in higher level code :/ | 16:20 |
| mvo | pedronis: anyway, open for suggestions | 16:20 |
| mvo | pedronis: also I should probably reply in the PR instead of here - let me do that - sorry | 16:21 |
| mborzecki | zyga: jdstrand: behaves the same on tumbleweed with 5.3 kernel | 16:21 |
| jdstrand | mborzecki: ack, I'm looking at this now. I'm going to distill this down and then talk to jj about it when he comes online | 16:22 |
| pedronis | mvo: I'm confused because the other PRs has TODOs like: I don't understand why we need MakeRunnable now that we pass options to MakeBootable | 16:22 |
| pedronis | mvo: oops | 16:22 |
| pedronis | mvo: TODOs like: // XXX: allow to override this | 16:23 |
| jdstrand | mborzecki: I suggest moving on for the time being until I circle back | 16:23 |
| mborzecki | jdstrand: ack, need to take my son to the swimming pool, so eod'ing anyway | 16:23 |
| mvo | pedronis: my original idea was to (re)use MakeBootable but I'm not sure it's the best fit anymore. But happy to chnage the PR accordingly. we just need to decide how the options are passed | 16:24 |
| mborzecki | jdstrand: the preprocessed apparmor profile from arch https://paste.ubuntu.com/p/yNTxCKq5Wh/ | 16:25 |
| pedronis | mvo: I'm also not sure I understand why we need to pass RecoverySystem | 16:25 |
| pedronis | mvo: yes, we need to agree on what we want | 16:26 |
| mvo | pedronis: I can leave this out for now, it will become clearer late, we will need to write the "modeenv" file on the real run | 16:26 |
| mvo | pedronis: the modeenv will contain the recovery_system because when the "run" system boots it will also seed itself and it needs to know what to seed (or am I missing something?) | 16:27 |
| pedronis | mvo: ok | 16:27 |
| mvo | pedronis: sorry, maybe I'm slicing it too much :/ I can make a bigger PR that includes more maybe? | 16:28 |
| pedronis | mvo: I think I'm confused because we have two many half done things in this area | 16:28 |
| pedronis | and they start not to match | 16:28 |
| mvo | pedronis: yeah, maybe it's better to create a big(ger) PR? | 16:28 |
| pedronis | mvo: or try to go step by step | 16:28 |
| mvo | pedronis: that implements most of the MakeBootable/MakeRunnable | 16:29 |
| pedronis | instead of rush ahead | 16:29 |
| pedronis | we haven't even set up the install system full correctly or not? | 16:29 |
| mvo | pedronis: you mean, wait until e.g. 7817 is merged before opening the next one? | 16:29 |
| pedronis | mvo: do we have the boot until install fully working? | 16:29 |
| pedronis | there is quite a few XXX in 7817 | 16:30 |
| pedronis | mvo: how do we find the kernel? | 16:30 |
| mvo | pedronis: I think with 7817 we should have a working boot into install mode | 16:30 |
| pedronis | there | 16:30 |
| mvo | pedronis: kernel is found via grub.cfg from the recovery | 16:31 |
| mvo | pedronis: it will scan the disk and pick the kernel it finds | 16:31 |
| pedronis | maybe the issue is also that the grub cfg are still in the gadget | 16:31 |
| pedronis | and I haven't looked at them in a bit | 16:31 |
| pedronis | mvo: anyway meeting time | 16:31 |
| mvo | pedronis: indeed | 16:32 |
| pstolowski | hmmm travis is taking ages.. | 17:12 |
| pedronis | 7768 needs a 2nd review | 17:44 |
| pstolowski | travis is spinning on 'job received', and not progressing | 17:48 |
| ijohnson | pstolowski: I've seen that before it for some reason always seems to happen after EOD for EU timezones :-/ my working guess is that the nightly jobs are configured to run after EOD for someone in EU and so PR's submitted during that time have to wait for those nightly jobs | 17:52 |
| ijohnson | cachio: do you know when the nightly spread-cron tasks are configured to run ? | 17:52 |
| ijohnson | pedronis: I can do a review of #7768 in my PM I think | 17:53 |
| cachio | which task ? | 17:53 |
| pedronis | ijohnson: great | 17:53 |
| mup | PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768> | 17:53 |
| pstolowski | cachio: https://github.com/snapcore/snapd/pull/7771 | 17:53 |
| ijohnson | cachio: any of them? | 17:53 |
| mup | PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771> | 17:53 |
| cachio | ijohnson, this is the main project | 17:53 |
| cachio | https://github.com/snapcore/spread-cron | 17:53 |
| cachio | then in any branch there is a task | 17:53 |
| ijohnson | cachio: right but when do the tasks run? | 17:53 |
| cachio | ijohnson, it is defined in a file, this is an ecxample https://github.com/snapcore/spread-cron/blob/gce-update-centos-7/options | 17:54 |
| pstolowski | ijohnson, cachio may i ask either of you to retry https://github.com/snapcore/snapd/pull/7771 some time later and land if it's green? | 17:54 |
| mup | PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771> | 17:54 |
| cachio | ijohnson, this is another example https://github.com/snapcore/spread-cron/blob/snapd-trusty-sru/options | 17:54 |
| ijohnson | pstolowski: sure | 17:55 |
| pstolowski | ijohnson: thanks. i'm eod'ing\ | 17:55 |
| cachio | pstolowski, sure | 17:55 |
| pstolowski | ty | 17:55 |
| pstolowski | cu | 17:55 |
| ijohnson | cachio: so that first one you posted has `$(date +%H%M) \< "1100"` is that evaluated on travis ? | 17:55 |
| cachio | ijohnson, no | 17:56 |
| cachio | this is evaluated in a vm in an internal env | 17:56 |
| cachio | ijohnson, it evaluates every 10 minutes aprox any branch | 17:56 |
| cachio | and executes the run-checks fiel | 17:56 |
| cachio | file | 17:56 |
| ijohnson | cachio: any idea what TZ that internal VM is on? | 17:57 |
| cachio | ijohnson, no | 17:58 |
| cachio | I can check | 17:58 |
| cachio | give me 2 minutes | 17:58 |
| ogra | a virtual one perhaps | 17:58 |
| cachio | ijohnson, https://paste.ubuntu.com/p/NVSdkZJyk8/ | 18:00 |
| ijohnson | cachio: thanks, so it seems that if some of the tests are generally written to run after EOD on that machine they will run right around now | 18:03 |
| cachio | ijohnson, nightly suite is configured like pattern_extractor="if [ $(date +%H%M) \< "0200" ]; then echo ""; else date +%Y%m%d; fi" | 18:04 |
| cachio | the rest of the branches which run tests are configured based on other triggers | 18:05 |
| cachio | for example | 18:05 |
| cachio | the core snap was promoted to candidate | 18:05 |
| cachio | so tests run using the new core snap | 18:05 |
| ijohnson | cachio: sorry was at lunch, but so does that pattern mean that the job only runs when it is later than 0200 UTC? or it only runs when it is before 0200 UTC? | 19:17 |
| cachio | ijohnson, it prints the date and it is executed when [ $(date +%H%M) \< "0200" ] is not true | 19:20 |
| cachio | so it runs after 2am | 19:20 |
| cachio | after 2am it prints the date | 19:20 |
| ijohnson | so anytime later than 0200 is when the test gets executed? | 19:20 |
| cachio | and it is compared with the previous date non empry | 19:20 |
| cachio | and if it is different then the job is executed | 19:21 |
| cachio | first try after 2am it will be executed | 19:21 |
| ijohnson | but what controls when this check is performed then? | 19:22 |
| cachio | ijohnson, the code where this is controlled is https://github.com/snapcore/spread-cron/blob/master/cron.sh | 19:23 |
| cachio | we have a snap which runs this constantly | 19:24 |
| ijohnson | I see, so it's not really deterministic when these jobs actually run, the pattern there really just defines when this agent shouldn't run the job | 19:25 |
| cachio | ijohnson, it runs at some poing after 2am | 19:26 |
| cachio | usually before 0230 | 19:26 |
| cachio | when the scirpt processs that branch | 19:27 |
| ijohnson | cachio: ok thanks for explaining | 19:27 |
| ijohnson | is that the only job that has a time of the day trigger? all other jobs are event based? | 19:27 |
| cachio | ijohnson, why? | 19:27 |
| cachio | do you need any change? | 19:27 |
| ijohnson | cachio: I'm wondering because it seems somewhat frequently that we have the issue Pawel has this morning where Travis is stuck in the "job received" state sometimes for a couple hours | 19:29 |
| ijohnson | I was thinking this was causing that somehow | 19:29 |
| === ricab_ is now known as ricab | ||
| roadmr | jdstrand: hi there! is there any way to constrain kernel-module-control to only be able to load one specific module? | 19:32 |
| cachio | all the jobs we use for update images are time base | 19:32 |
| cachio | base are triggered on monday | 19:32 |
| cachio | ijohnson, you can see here when the jobs ran https://travis-ci.org/snapcore/spread-cron/branches | 19:32 |
| cachio | ijohnson, I jsut retrigger debian 9 | 19:34 |
| ijohnson | thanks for that cachio, it seems a bit like that isn't the cause of the "job received" issue | 19:34 |
| cachio | ijohnson, perhaps it is caused because too many jobs running for the same project | 19:35 |
| cachio | perhaps there is a limit | 19:35 |
| cachio | not sure | 19:35 |
| jdstrand | roadmr: no. but we have the kmod backend that is meant to load modules on behalf of the snap. what module? | 19:39 |
| ijohnson | cachio: could be, anyways it seems Pawel's PR failed on Ubuntu due to mount ns changes, the cgroup mount now seems to be ro instead of rw as expected? was there recently an ubuntu 16.04 image change recently? | 19:40 |
| roadmr | jdstrand: I don't know, but I can ask. The snap in question is domotzpro-agent-publicstore. I can point them to examples of using kmod to load the module they need, if you point me to some, in turn :) | 19:40 |
| jdstrand | roadmr: well, it doesn't work quite like that. if we know the module, we can consider adding it to a new or existing interface | 19:41 |
| jdstrand | roadmr: but it would be hardcoded in snapd, not something that they declare | 19:41 |
| roadmr | right... I see | 19:41 |
| jdstrand | roadmr: typically a brand store will do this via their kernel. there may be a way to do it via the gadget, but idk otoh | 19:42 |
| roadmr | jdstrand: right, this is intended to be in the public store :/ so that's the boggle here | 19:43 |
| roadmr | they said they'd look at options on their side including making do without the module loading capability, but were asking if we had something else to use | 19:43 |
| pedronis | roadmr: we really need to understand a bit more what they are trying to do if they want to target the public store | 19:43 |
| roadmr | jdstrand: fwiw this is a customer (domotz/fingbox) and they do have a brand store, but because reasons, they want this particular snap to be on the global store | 19:44 |
| jdstrand | roadmr: it is hard to recommend something without knowing the module in question | 19:44 |
| pedronis | just saying we need to load modules is too vague for that space | 19:44 |
| roadmr | jdstrand, pedronis : ok, let me ask them for more details and get back to you | 19:44 |
| jdstrand | pedronis: it is possible for use to have a generic interface that lists the modules to load as attributes and shove that into the kmod backend. not suggesting that, but this conversation made me think of that | 19:45 |
| jdstrand | us* | 19:45 |
| jdstrand | we protect those attributes via snap decl like with personal-files/system-files | 19:45 |
| jdstrand | s/those attributes/that attribute/ | 19:46 |
| pedronis | jdstrand: yes, that's an approach, but we would still like to know whether a more specific or an addition to an existing interface would make more sense I think | 19:46 |
| jdstrand | anyway, putting it out there for background thought | 19:46 |
| pedronis | anyway even for that case we know the list of modules | 19:46 |
| pedronis | *we need to know | 19:46 |
| jdstrand | for sure. need to know the modules :) | 19:46 |
| roadmr | I've asked, will wait for a reply from them folks :) | 19:47 |
| jdstrand | roadmr: you might not suggest my otoh comment there at the end. I don't know if we want to go there | 19:48 |
| jdstrand | I was more just mentioning that to pedronis as food for thought | 19:48 |
| roadmr | jdstrand: I haven't offered anything concrete until I know more, just told them to get us more info so we can give them options that suit their use case | 19:50 |
| ijohnson | jdstrand: quick question, do you think layouts should be allowed for new top-level directories in "/" ? I tried creating one and it failed because snap-update-ns isn't allowed to create a mimic on top of "/" and I'm not sure if this is intentional or a bug | 19:53 |
| ijohnson | jdstrand: denial looks like type=1400 audit(1575575534.977:339): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.my-snap-name" name="/tmp/.snap/" pid=39112 comm="7" srcname="/" flags="rw, rbind" | 19:53 |
| pedronis | ijohnson: it's a limitation of the current implementation | 19:58 |
| ijohnson | pedronis: ah ok | 19:58 |
| pedronis | in principle we could allow some subsets of layout at that level carefully | 19:58 |
| pedronis | but needs implementation changes | 19:58 |
| ijohnson | so it could work someday and is kind of a bug that it doesn't work today | 19:58 |
| pedronis | it's kind of a bug, but given is top-level and doesn't work we haven't decided the exact policy | 19:59 |
| pedronis | I mean in general is a limitation, specific instances might still not work | 19:59 |
| ijohnson | oh actually if I had read the docs the doc does say that you can't do that | 19:59 |
| pedronis | because of security/policy reasons once implemented | 19:59 |
| ijohnson | perhaps what we should do is add a warning or fail during install/validation of a snap.yaml declaring those | 19:59 |
| ijohnson | until the implementation could support it | 20:00 |
| pedronis | ijohnson: yes, it is known not to work, so not surprised it is documented as such | 20:00 |
| ijohnson | yes my fault for not reading docs closely enough :-) | 20:00 |
| pedronis | ijohnson: saw your comment, did we hit another instance of the baseline of the mountspace checks changing behind our backs? | 20:01 |
| ijohnson | pedronis: yes I think so | 20:03 |
| pedronis | this is getting a bit tedious | 20:03 |
| pedronis | maybe we should rethink how we compute the baseline | 20:03 |
| ijohnson | pedronis: unless somehow snapctl is remounting cgroups /o\ | 20:10 |
| pedronis | I hope not | 20:10 |
| pedronis | ijohnson: it's the kernel again | 20:11 |
| pedronis | we decide to stick with the old one | 20:11 |
| pedronis | but didn't | 20:11 |
| pedronis | or something like that | 20:12 |
| pedronis | cachio: did we re-build new images with the wrong kernel ^ ? | 20:12 |
| cachio | pedronis, in bionic? | 20:15 |
| cachio | pedronis, we should be using 4.15 | 20:16 |
| pedronis | cachio: seems xenial now | 20:16 |
| cachio | pedronis, ah, I just updated bionic | 20:16 |
| cachio | pedronis, I can update xenial as well | 20:16 |
| pedronis | cachio: let me point to the failing PR | 20:17 |
| cachio | I'll make the change | 20:17 |
| pedronis | cachio: the issue is here: https://github.com/snapcore/snapd/pull/7771#issuecomment-562283907 | 20:17 |
| mup | PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771> | 20:17 |
| cachio | pedronis, thanks | 20:19 |
| cachio | I'll take a look to the image and I'll make the change to see if that fixes the issue | 20:19 |
| cachio | pedronis, it is pretty similar to the issue we saw in bionib | 20:19 |
| cachio | bionic | 20:19 |
| pedronis | cachio: yes, that's why I asked about the kernel, it seems similar | 20:20 |
| cachio | pedronis, xenial has 4.15.0 | 20:26 |
| cachio | the problem could be something else | 20:26 |
| cachio | ijohnson, the problem in bionic was caused by the kernel v5.0 | 20:28 |
| cachio | in this case in xenial the kernel is 4.15 | 20:28 |
| cachio | so I am not sure if the problem could be different | 20:28 |
| cachio | both mount-ns tests failed? or just 1? | 20:28 |
| mup | PR snapcraft#2832 opened: appstream extractor: take xml comments into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2832> | 20:29 |
| NickZ | Is there a way to get a snapcraft package to stage packages from a third-party repo? | 20:30 |
| ijohnson | cachio: sorry multiple tests failed I don't remember all of the test names | 20:31 |
| cachio | ijohnson, np, lets wait for the results again | 20:32 |
| ijohnson | k | 20:32 |
| cachio | ijohnson, 2019-12-05 20:28:10 Aborted tasks: 0 | 20:46 |
| cachio | 2019-12-05 20:28:10 Failed tasks: 1 | 20:46 |
| cachio | - google:ubuntu-16.04-64:tests/main/mount-ns:inherit | 20:46 |
| cachio | just one failed | 20:46 |
| cachio | the other passed | 20:46 |
| cachio | I think this is something new | 20:46 |
| cachio | ijohnson, the images was updated 4 days ago | 20:47 |
| cachio | so this is some new package or a change in the code | 20:47 |
| ijohnson | hmm this does seem different from the bionic issue | 20:47 |
| cachio | ijohnson, my PR also failed on that test | 20:54 |
| ijohnson | well something updated it just seems a question of what updated | 20:55 |
| mup | PR snapd#7853 opened: [RFC] boot,bootlaoder: setup the snapd_recovery_kernel grubenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7853> | 21:02 |
| ijohnson | well after looking into it some more it seems like /sys/fs/cgroup _should_ be mounted ro, I'm not sure why our tests have it as being mounted rw | 21:04 |
| ijohnson | I can submit a PR in a little bit updating the tests I think to unbreak master at least | 21:04 |
| ijohnson | would be good to understand why it was measured as being mounted rw however | 21:05 |
| cachio | ijohnson, perhaps we could review it with zyga tomorrow | 21:08 |
| cachio | it is weird | 21:08 |
| zyga | o/ | 21:28 |
| zyga | I'm back but too sleepy to work | 21:29 |
| zyga | see you tomorrow | 21:29 |
| zyga | ijohnson: I saw the failure | 21:29 |
| stgraber | so recent core (snapd) now prevents installing lxd inside a lxd container, breaking our daily CI and probably a bunch of systems out there | 22:26 |
| stgraber | jdstrand: as the only snap person who may still be awake, any idea of what changed in that last core (and snapd) update that could cause issues? | 22:27 |
| roadmr | inception ๐คฏ | 22:27 |
| stgraber | as far as I can tell, it only affects the LXD snap and it may be apparmor related though I'm not getting any record denials | 22:28 |
| stgraber | the culprit is snap-confine getting spawned and being told no by the kernel (looks like) | 22:28 |
| stgraber | 2686 execve("/snap/core/8213/usr/lib/snapd/snap-confine", ["/snap/core/8213/usr/lib/snapd/sn"..., "snap.lxd.activate", "/usr/lib/snapd/snap-exec", "lxd.activate"], 0xc4203272c0 /* 19 vars */ <unfinished ...> | 22:28 |
| stgraber | 2676 pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <unfinished ...> | 22:28 |
| ijohnson | stgraber: I'm afk for a little bit but I'll be around a little later to discuss more | 22:28 |
| stgraber | 2686 <... execve resumed> ) = -1 EACCES (Permission denied) | 22:28 |
| ijohnson | stgraber: man page says that could also be due to the filesystem being mounted noexec, is that possible? | 22:34 |
| stgraber | no | 22:34 |
| ijohnson | stgraber: Could you post a full strace log? | 22:35 |
| stgraber | pastebin rejects it, too large | 22:36 |
| ijohnson | How large is the log? Could you email it? | 22:39 |
| roadmr | aiee folks use one of the shared servers! | 22:39 |
| roadmr | you both have access :) | 22:40 |
| stgraber | ijohnson: http://paste.ubuntu.com/p/rDRxqrdXn9/ | 22:40 |
| stgraber | ijohnson: un-b64 and un-gz to get the original | 22:40 |
| roadmr | clever solution :) | 22:40 |
| stgraber | roadmr: pretty used to having to extract crap from random user systems behind a bunch of firewalls and such :) | 22:41 |
| roadmr | haha | 22:41 |
| ijohnson | stgraber: thanks I'll let you know if I figure anything else out, and make sure that the rest of the Snapd folks take a look in their morning | 22:44 |
| stgraber | ijohnson: do you know what version of snapd used to be in core? | 22:45 |
| stgraber | would make a local bisect a bit faster :) | 22:45 |
| ijohnson | stgraber: when? | 22:46 |
| stgraber | latest core updated snapd to 2.42.4, I'd like to know what the snapd version was prior to that in core, if it was 2.42.3 that'd make the diff pretty short | 22:46 |
| mup | PR snapd#7854 opened: snap-confine: raise egid before calling setup_private_mount() <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7854> | 22:47 |
| stgraber | looks like it was 2.42.1 looking at the previous version of the core snap on disk | 22:48 |
| stgraber | that's unfortunate | 22:48 |
| mup | PR snapd#7835 closed: gadget: add missing test for duplicate detection of roles <Simple ๐> <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7835> | 22:48 |
| roadmr | stgraber: confirmed, 16-2.42.1 was the previous on stable (e.g. revision 8039 for amd64) | 22:48 |
| roadmr | stgraber: I looked at my release history for stable | 22:48 |
| roadmr | current rev is 8213 | 22:49 |
| ijohnson | Sorry looks like roadmr beat me to it | 22:51 |
| roadmr | ijohnson: stgraber beat us both to it :) | 22:51 |
| stgraber | snap-confine apparmor change introduces a "deny unix," which may cause silent denials, not sure why it would trip on an execve though | 22:51 |
| stgraber | but that's the main suspicious thing I'm seeing, so lets try reverting that first | 22:52 |
| stgraber | root@c1:~# snap install lxd | 22:54 |
| stgraber | lxd 3.18 from Canonicalโ installed | 22:54 |
| stgraber | bingo | 22:54 |
| ijohnson | Hmm that's odd | 22:54 |
| ijohnson | Also odd that our tests didn't catch this we have lxd inside lxd tests | 22:54 |
| ijohnson | (that supposedly work) | 22:55 |
| stgraber | going to re-introduce that line to confirm that it fails again if I do so, just to make sure I didn't disable too much of apparmor by accident | 22:55 |
| stgraber | nope, that's clearly the issue, re-introducing that line keeping everything the same causes the failure | 22:56 |
| stgraber | it could be an apparmor parser bug, a kernel bug, ... but "deny unix," is clearly denying too much somehow | 22:57 |
| jdstrand | stgraber: that explicit deny rule in snap-confine was always denied. that shouldn't change anything | 22:58 |
| stgraber | jdstrand: it sure does somehow, and only in containers, so likely causing something interesting to happen in the kernel | 22:59 |
| jdstrand | ie, it isn't a new thing being denied. it is just a new thing not being logged | 22:59 |
| jdstrand | that is very surprising | 22:59 |
| jdstrand | snap-confine had no unix rules to begin with | 22:59 |
| jdstrand | apparmor_parser -p /var/lib/snapd/apparmor/profiles/snap-confine.core.8213 |grep unix | 23:00 |
| jdstrand | deny unix, | 23:00 |
| jdstrand | stgraber: can you change that to an 'audit deny unix,'? or 'audit unix,'? | 23:01 |
| stgraber | jdstrand: "lxc launch ubuntu:18.04 c1 -c security.nesting=true" and then "lxc exec c1 -- snap install lxd" will reproduce it | 23:02 |
| stgraber | jdstrand: sure, I was actually looking for the syntax for that | 23:02 |
| stgraber | jdstrand: really smells like a kernel bug, "audit deny unix," doesn't log anything but things now behave | 23:04 |
| stgraber | I only see profile_load STATUS messages, no sign of anything else in there | 23:04 |
| stgraber | removing the audit prefix and back to it failing | 23:05 |
| NickZ | for the record, to stage packages from a third-party repository, do this: https://gist.github.com/NickZ/828be7ad23cd9d9c88b9ab0b3624bf44 | 23:06 |
| ijohnson | stgraber: so interesting thing I don't think our tests test snaps inside lxd inside lxd, we only test lxd inside lxd. I will make sure we have a regression test for this | 23:07 |
| ijohnson | (well also snaps inside lxd directly) | 23:07 |
| jdstrand | stgraber: where are you adjusting the rule, int he container? | 23:08 |
| NickZ | i've heard that snaps have been broken on bionic lxd for a while now | 23:11 |
| jdstrand | stgraber: basically, I can see things are broken, but can't fix it cause when I snap install in the container, the snap-confine profile is overritten and my changes are undone | 23:11 |
| jdstrand | stgraber: fixing it on the host has no effect. what did you do? | 23:13 |
| stgraber | ijohnson: the problem is installing lxd inside a lxd container, so in theory your test is already doing that | 23:14 |
| stgraber | jdstrand: it's the profile in the container you need to fix | 23:14 |
| jdstrand | right, and as soon as I do snap install, the fix is reverted | 23:14 |
| ijohnson | stgraber: this is the test https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml | 23:14 |
| stgraber | jdstrand: I did: "cp /snap/core/8213/etc/apparmor.d/usr.lib.snapd.snap-confine.real ." then "vim" and finally "mount -o bind usr.lib.snapd.snap-confine.real /snap/core/8213/etc/apparmor.d/usr.lib.snapd.snap-confine.real", followed by a teardown to force a reload of the profiles | 23:14 |
| stgraber | ijohnson: the problem I suspect is that you're testing the new snapd on the host | 23:15 |
| stgraber | ijohnson: the issue happens when you run the new snapd in the container | 23:15 |
| stgraber | hmm, no, you're installing the new snapd in there | 23:15 |
| jdstrand | that's... weird. I wouldn't expect .real to have anything to do with it, but you gave me an idea. I can just copy /var/lib/snapd/apparmor/profiles/snap-confine... aside, modify it and load it | 23:16 |
| stgraber | ijohnson: ah, the problem is that you're never actually installing lxd in lxd | 23:17 |
| stgraber | ijohnson: your test creates a lxd container, updates snapd inside it and then installs test-snapd-sh | 23:17 |
| stgraber | ijohnson: if you were to snap install lxd instead of test-snapd-sh on line 100, you'd have gotten the failure | 23:17 |
| stgraber | jdstrand: I went with a naive "grep -r deny.*unix /snap/core", found the file that has the offending string and over-mounted it with a version which doesn't :) | 23:18 |
| jdstrand | stgraber: what host are you on? | 23:18 |
| stgraber | 18.04 LXD VM | 23:19 |
| jdstrand | on an eoan host, it isn't working at all | 23:21 |
| stgraber | Oh? As in broken on the host too? | 23:24 |
| jdstrand | stgraber: no, it is fine on the host, but I can't get the nesting to work | 23:25 |
| jdstrand | I'm trying in a vm | 23:25 |
| * jdstrand tried with his lxd that was already configured | 23:25 | |
| NickZ | just curious, has anyone here ever successfully got mono to run in containment? | 23:30 |
| jdstrand | stgraber: what is the output of aa-status in the container? | 23:40 |
| jdstrand | ok, finally | 23:42 |
| jdstrand | ijohnson: I downgrading to 8159 (2.42.2) and it does not have the unix rule. I then added to /var/lib/snapd/apparmor/snap-confine/foo 'deny unix,', the did apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine* then tried to install lxd and it failed | 23:44 |
| jdstrand | ijohnson: we should revert that rule. I'll need to investigate to see why it is failing | 23:44 |
| jdstrand | ijohnson: this indeed is a kernel bug | 23:45 |
| stgraber | jdstrand: how fast can we get a that line reverted in the stable snap? | 23:47 |
| jdstrand | stgraber: that's an mvo question | 23:47 |
| stgraber | Ok, I'll email mvo to make sure he's aware when he starts the day | 23:48 |
| jdstrand | stgraber: please cc me and feel free to paste my comments above about downgrading and that I confirmed this is a kernel bug | 23:49 |
| jdstrand | stgraber: you might cc jj as well | 23:49 |
| stgraber | Will do, thanks | 23:50 |
| jdstrand | it could be a parser bug too... | 23:50 |
| jdstrand | anyhoo, thanks | 23:50 |
| ijohnson | stgraber: jdstrand: I'll make sure mvo is aware | 23:52 |
| jdstrand | stgraber: fyi, this is a more specific rule (ie, to address the thing that prompted the PR in the first place): deny unix (receive, send) type=stream addr=none peer=(addr=none), and it also causes lxd to fail | 23:53 |
| jdstrand | stgraber: I can pass that to jj if you already sent the email or don't want to integrate that detail | 23:54 |
| stgraber | Having dinner will send email after and include that in | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!