[00:02] zyga: if you have a lot of stuff to do, I can probably figure out how to rip out the suse go macros === ubott2 is now known as ubottu [03:15] is there a way to override $SNAP_USER_COMMON? snapd seems to not like my glusterfs mounted home directory [04:31] Good morning [04:31] Doctor_Nick: hey, can you please tell me more [04:31] Do you have any issues with snaps? [04:32] Network file systems may need a special tweak for confinement [04:33] Please share any issues you have and I’ll try to help [04:33] Caelum: I’m progressing and I should have alpha build soon (perhaps today) [05:06] zyga: nice [05:09] School run [05:22] Hey mborzecki [05:22] morning [05:22] 6 am wake up time today [05:22] heh, 630 for me, preping kids to school took a bit longer than anticipated [05:22] I’m on the bus :P [05:23] Memories of commuting [05:23] oh, wow :) [05:23] (Horrors) [05:23] is the bus moving? :) [05:23] Yes [05:23] Barely [05:23] I’ll be operational soon [05:24] I sent some patches to my branch [05:24] Renamed Secure [05:24] there were some stats regarding traffic jams across the eu, polish cities were in the top tier, iirc lodz was even higher than warsaw :/ [05:25] go version go1.11 linux/amd64, finally updated [05:43] re [05:44] mborzecki: in Palamos the only traffic jam was in the alley next to the school when all the parents that drive to school were dropping their kids off [05:44] mborzecki: on 9:00 [05:44] mborzecki: work starts 9:15 [05:45] that's unfair, right? :) === chihchun_afk is now known as chihchun [05:58] zyga: that's exactly it [05:59] Doctor_Nick: hey :-) [05:59] Doctor_Nick: can you please share 'dmesg | grep DENIED\ [05:59] er [05:59] 'dmesg | grep DENIED' [05:59] yeah [05:59] I suspect a small tweak will enroll another network filesystem to the extension we did for NFS [06:00] hmmm [06:01] it's not showing up [06:01] cannot create user data directory: /users/nickz/snap/vapor-master/x1: Read-only file system [06:01] that's the error message that I'm getting [06:01] what is your $HOME set to? [06:02] i created a link from ~/snap to /stuff/snap, which is on the local disk [06:02] /users/nickz [06:02] Doctor_Nick: symlinks won't cut it [06:02] i see [06:02] you must create a bind mount from whatever your home directory is to /home/$LOGNAME [06:02] and /home/$LOGNAME/snap must be a directory or a bind mount there [06:03] sorry, it's a bit complex and symlinks are not transparent to a certain layer [06:03] yeah [06:03] I can show you how to do that if you need to [06:05] zyga: yeah, i'd appreciate that [06:08] Doctor_Nick: we can do a quick test first [06:08] Doctor_Nick: then we can make that happen automatically by editing /etc/fstab [06:08] Doctor_Nick: you will need root access, do you have that? [06:09] yup [06:10] "starbuck:/gv0 /users glusterfs defaults,_netdev,noauto,x-systemd.automount 0 0 [06:10] Doctor_Nick: excellent, do you have /home/$LOGNAME on your machine? [06:10] yeah, I can create it [06:10] Doctor_Nick: please do [06:10] ok [06:10] Doctor_Nick: then try this: sudo mount --rbind /users/$LOGNAME /home/$LOGNAME [06:11] Doctor_Nick: what does HOME expand to? is it /users/$LOGNAME? [06:11] yup [06:11] ok [06:11] I suspect you will need to switch that [06:11] but not sure actually [06:12] I'm curious why /users and not /home - are some users on this machine local and some remote? [06:12] yes, that's it [06:12] once you do that bind mount, please export HOME to the new value in a shell [06:12] and try running a snap from command line [06:12] (any simple snap) [06:12] Doctor_Nick: thanks, I wish we could support this better out of the box [06:13] huh [06:13] it's still using the default home location [06:13] cannot create user data directory: /users/nickz/snap/vapor-master/x1: Read-only file system [06:14] Doctor_Nick: aha, it's probably reading your home directory location from /etc/fstab still [06:14] ok [06:14] Doctor_Nick: can you change that for a quick experiment [06:14] and try again [06:14] (we can change it back if it fails) [06:15] uhm [06:15] if I unmount this thing, my system is going to hardlock [06:15] i've done this before [06:16] https://pastebin.com/ncju0t4L [06:16] that's my whole fstab file [06:17] the setup doesn't jsut mount my home folder, it mounts all the network users who are logged in to /users [06:18] right but we don't need to change that [06:18] ok [06:19] I meant your /etc/passwd (or appropriate, whatever holds your user entry) [06:19] ahhhhh [06:19] on your local system we'd change /etc/fstab to have an extra bind mount [06:19] from memory that would look like this: [06:19] /users/foo /home/foo none bind 0 0 [06:19] hey, there it goes [06:20] its working now [06:20] once the /users vs /home issue is out of the way [06:20] you may run into another issue [06:20] but for that one we have a workaround that was made for NFS [06:20] ok [06:20] and I can extend that to glusterfs easily [06:23] zyga: isn't there away to just override SNAP_USER_COMMON/SNAP_COMMON? [06:24] brb [06:29] re [06:29] Doctor_Nick: so it's not that easy [06:29] it's not about changing it really [06:29] for instance /home is re-mapped inside the application container [06:29] and /users doesn't even exist there [06:29] we have a per-user mount namespace where we might be eventually able to do per-user $HOME remapping [06:30] but that's not ready yet [06:30] the apparmor needs to really really understand where _all_ home directories are [06:30] ah hah, ok [06:30] so even if we allow changing that easily it would not work out of the box [06:31] I think that really the only sane solution is doing the remapping internally in the per-snap, per-user mount namespace [06:31] and that's something I'm working towards enabling [06:31] then you can have any $HOME [06:31] yeah, that's something we'd like [06:31] but at runtime for the snap it would show up as /home/$LOGNAME [06:31] and would really be your $HOME in practice [06:32] I'll make a note about this, it looks doable in a few weeks [06:32] I need to sort out prerequisites first [06:32] Doctor_Nick: try making the bind mount permanent by adding a line to /etc/fstab as I suggested [06:33] and reboot just in case to test that :) [06:33] yeah, i'll give that a shot [06:33] zyga: good morning! how are the tests looking today? [06:33] thank you for sticking with snaps :) [06:33] good morning mvo [06:33] I pushed some things in the morning, let me look now [06:34] last night I saw failures to prepare opensuse [06:34] ok [06:34] some archive skew, it was complaining about package hash [06:34] yeah, we're using them to deploy our server packages [06:35] that's great :) [06:35] are you using private snaps? [06:35] that you build yourself [06:35] or are those public snaps? [06:36] hey sil2100 [06:36] private snaps [06:36] Doctor_Nick: that's awesome! thank you for sharing that [06:36] mvo: my PR is progressing, no failures so far [06:36] mvo: that's both prepare and execute failures [06:36] so fingers crossed :) [06:37] nice! [06:38] we understand that snapcraft.io is going to implement private github support sometime in the future [06:39] Doctor_Nick: I think so but I'm not the best person to ask abou tthat [06:40] zyga: hey! [06:40] * sil2100 is back from the dead more-or-less [06:40] sil2100: are you okay? [06:43] zyga: yeah, just fighting a flu this week, but I feel better today [06:43] sil2100: honey and tea [06:43] (and rum :) [06:43] ;-) [06:50] i'll be pushing a couple of fixes for go 1.11 in a minute [06:51] mborzecki: thank you [06:52] mborzecki: man, tumbleweed doesn't have go 1.11 yet [06:52] https://github.com/snapcore/snapd/pull/5766 [06:52] mvo: any chance of getting this to 2.35? [06:52] mborzecki: I'd say: just propose a 2.35 PR [06:55] wondering if we should run unit tests on arch, or just any other distro but with the latest go release [06:55] mvo: my PR is green now, so maybe we're back to good [06:55] mborzecki: +1 [06:55] I think [06:58] mborzecki: can we do a pass over my PR [06:58] mborzecki: I can take some parts and propose them and keep shrinking the main one [06:58] mborzecki: we could identify some things that could land this way [06:58] zyga: give me half an hour and we can do HO then [06:58] sure, thank you [07:00] damn, gocode stopped working with go1.11 [07:05] morning [07:11] good morning pawel [07:28] mborzecki: I'm looking at snap-failure right now, when it was triggered for your user, did that had any bad consequences [07:28] mborzecki: going over the code it seems we want this to be available in classic as well eventually, once we use the snapd snap there its a nice mechanism to recover from bad snapds which will also work on classic [07:28] mborzecki: Ill head home, I'll call you from there, it's too noisy here [07:30] zyga: ack [07:32] mvo: i'm not sure what systemd did there if OnFailure service failed too, meaning that snapd might have not been restarted at all, i can try it though [07:32] mborzecki: oh, interessting, let me look at this [07:32] mborzecki: it should handle this gracefully but it sounds like there is a bug [07:34] mvo: is it restarted? [07:34] mborzecki: still looking, need to ensure I got the right version :) [07:34] haha ack :) [07:36] mborzecki: yes it did restart, snapd restarted, snap-failure exited cleanly [07:37] mborzecki: would love to learn more if you saw something different [07:37] mvo: the problem the user had is that snap-failure was not shipped by the package, so snapd.failure.service exited with error [07:37] mborzecki: aha, got it [07:37] mborzecki: that makes sense [07:38] mvo: otoh, maybe then i should just ship snap-failure instead of dropping it, but there's no reexec on arch anyway, so chaces of snapd running from the snapd snap are rather low [07:41] mborzecki: yeah, it will only do anything if there is a snapd snap availalbe [07:44] * zyga waits for the bus to leave [07:44] dbus ? [07:45] plbus :) [07:45] haha [07:45] :D [07:45] ztm :P [07:50] indeed [08:18] re [08:25] mborzecki: I'm available but no rush, working on some stuff [08:25] mborzecki: so when you feel like it just ping me [08:26] zyga: ok, just finishing a thing in snapstate [08:26] sure :) [08:33] almost there, left with 2 panics in api tests [08:33] btw. we set "seeded": true in the tests, but seed-time is not set [08:39] Chipaca: thank you for the review on the gcc thing and yeah the original version was bogus [08:39] mvo: i think it worked but was frowned on [08:40] Chipaca: yeah, it did actually, but go vet in 1.10 started complaining so it was not quite the right fix [08:48] Hi everyone. Is there any way to put a symlink in my snap's readonly part (i.e. part directory) that points to the snaps /tmp directory? I guess $TMPDIR would point to the build system's tmp directory, and when I try to create a symlink in my install hook, it aborts with “read-only filesystem”. [08:49] mborzecki: well, very little code cares about seed-time sof ar [08:50] pedronis: heh noticed that, i'll be opening a RFC with snapstate changes soon, will ping you and Chipaca :) [08:50] Morning all [08:50] it was added recently to help with the hold logic [08:52] dot-tobias: That probably won't work.. you can try to make a symlink and pack it inside the snap itself, but I think the reviewing process will flag that as having symlinks pointing outside of the snap [08:52] dot-tobias: You can try it, though.. [08:54] mborzecki: I'll will try to do reviews in the afternoon [08:54] niemeyer Thanks, that's what I feared … My snap is not ready for review yet, but good to know that this would be an additional bump in the road. Root problem is that the framework I'm using for my snapped (web) app has a tmp directory hardcoded at app-root/tmp [08:57] pedronis: thanks [08:59] dot-tobias: Hmm [08:59] dot-tobias: There's a nice solution here: [08:59] dot-tobias: We have an experimental feature, which is soon leaving the experimental status behind, and allows you to control the mountpoints in more detail [08:59] dot-tobias: That means you could even have a tmpfs mounted on your read-only space [09:01] zyga: Do we have good docs for layouts already? [09:01] niemeyer: hey [09:01] dot-tobias: This is the discussion where you can find details of the syntax: [09:01] dot-tobias: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/45 [09:01] niemeyer: we only have the forum post for the layouts we had before; I didn't write anything more [09:01] niemeyer that sounds interesting. Thanks :-) Will look into it [09:02] dot-tobias: The experimental feature is already working on your snapd.. you just need to enable it with "snap set system experimental.layouts=true [09:02] " [09:02] niemeyer: but that page has some extensive discussion and examples that seem like a good starting point [09:02] zyga: We need a doc page for that [09:02] actually [09:02] niemeyer: when're we dropping the experimental flag on it? [09:02] I think we may have one, hold on [09:03] Chipaca: I'm hoping very soon.. I haven't been hearing much about it lately, which is both good and bad [09:03] no, we don't have one [09:03] I'll start it now [09:03] niemeyer: Does enabling experimental features have any impact on releasing my snap (e. g. only on beta/dev)? [09:04] dot-tobias: No.. you can release it.. it may get held back by review, but we can pass it if the feature is in a ready-enough state, which is definitely the case for layouts [09:04] dot-tobias: At installation time, the snap command will warn that this depends on an experimental feature, and won't proceed unless the system acks the support for the feature via the fla [09:04] flag [09:05] niemeyer: Good to hear, thanks! Will try it out and give feedback here / in the forum thread. === chihchun is now known as chihchun_afk [09:05] dot-tobias: That's great, thank you. That's exactly the kind of info we need to get this feature out of experimental [09:06] niemeyer: should we make it so experimental features are always enabled on edge? [09:07] Chipaca: oooh [09:07] that's neat :) [09:07] we could even get fancy and decide which ones get auto-enabled on beta/candidate/...stable [09:11] mborzecki: it took me five re-reads to find the typo you fixed in #5764 [09:11] keep me away from writing stuff today [09:11] or maybe from proofreading stuff [09:11] yeah, the latter [09:11] gccooo :) === chihchun_afk is now known as chihchun [09:16] Chipaca: No, I think we should still ask the *environment* in which the snap is installed to acknowledge the fact they are using an experimental feature [09:17] Chipaca: Part of the point of the flag is to tell people "hey, you are using something that can disappear altogether tomorrow" [09:17] point [09:18] niemeyer: Looks like I'm doing something wrong? snapcraft complains about the layout key in snapcraft.yaml – building with snapd 2.35 on ubuntu server 16.04.05 LTS, snap get system experimental returns experimental.layouts true. Using layout as a top-level construct as zyga documented in https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/2 [09:18] dot-tobias: hold on [09:18] I'm documeting this right now, I already covered that, [09:18] I'll share the page in a sec [09:19] dot-tobias: Not sure about what's the status of snapcraft in that regard.. it should already be accepting it, but apparnetly it isn't? You can get away with that by putting the layouts map inside a "passthrough" map in snapcraft.. that tells it to ignore the syntax and just pass it on to snapd [09:19] zyga great, thanks! Brewing fresh coffee in the meantime :-) [09:19] *envy* :) [09:19] dot-tobias: The passthrough map is literally named "passthrough".. that's probably what zyga is about to document [09:20] yes :) [09:20] zyga: Thanks for that [09:36] dot-tobias: ok [09:36] back? [09:37] zyga: Yes, back and trying out the layout feature with passthrough. Getting the same “cannot create writable mimic” error like https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/64?u=tobias [09:37] one sec [09:37] But I'm probably doing something wrong 😊 [09:42] ok [09:42] ready [09:42] https://forum.snapcraft.io/t/snap-layouts/7207 [09:43] please read that, I'll read the error you got [09:43] dot-tobias: :) [09:45] niemeyer: ^ feedback welocme [09:45] *welcome [09:45] zyga: Error was: “cannot update snap namespace: cannot create writable mimic over "/": permission denied / snap-update-ns failed with code 1” relevant snapcraft.yaml part: passthrough: [09:45] layout: [09:45] /mytmp: [09:45] symlink: $SNAP_DATA/rails_tmp [09:46] dot-tobias: you cannot create a new top-level directory. I'll adjust the error so that it is clear [09:48] ogra, pstolowski: IIRC you made some snaps with layouts, can you have a look at https://forum.snapcraft.io/t/snap-layouts/7207 please? [09:50] niemeyer: I've replied to a few of your comments on #5514, if you could take a look you'd unblock me wholly [09:51] Chipaca: NIce, thanks.. will be on it in a few mintues [09:51] dot-tobias: I assume you don't really need a new directory called /mytmp and that you were just exploring [09:51] zyga: Thanks, will check [09:52] zyga: sure, gladly [09:52] zyga: Yes, “exploring” or “fumbling around” 😄 I actually need a directory in my snap's app directory that's writable [09:52] dot-tobias: that should be doable :) [09:53] zyga, an example for the symlink case would be nice ... otherwise it looks good [09:54] ogra: +1 [09:57] dot-tobias: please let me know if something about layouts is unclear from the documentation or if you are trying to achieve something and it is unclear if layouts help or how they could be used [09:58] zyga: First, thanks for the comprehensive writeup! Makes things much clearer. If I understand the “deeply nested paths” section correctly: If my app contains a folder “myfolder” and within that, I want to have a symlink named ”tmp” pointing to $SNAP_DATA/tmp … I would create a layout mapping “myfolder/tmp” with keyword `symlink` to $SNAP_DATA/tmp? [09:58] dot-tobias: that limitation only applies to read-only spaces [09:58] dot-tobias: inside $SNAP_DATA you can do anything [09:59] if you want a symlink $SNAP_DAT/tmp -> (whatever) you can just do that [09:59] but [09:59] layouts are not usually used to create things in $SNAP_DATA [10:00] (you can always do that in your application code or the configure hook) [10:00] can you give me a concrete exapmle please? [10:00] https://github.com/ogra1/xdmcp-client/blob/master/snap/snapcraft.yaml is an example for symlink [10:01] zyga: It's the other way round: I need a symlink pointing from “tmp” in my app's root directory (which is read-only) to $SNAP_DATA/tmp, so that the app can write stuff at the expected path $app_root/tmp. [10:01] ah [10:01] that's ok [10:01] so layout like: [10:01] $SNAP/tmp: symlink $SNAP_DATA/tmp [10:01] $SNAP/tmp: symlink: $SNAP_DATA/tmp [10:01] note that this will _not_ create $SNAP_DATA/tmp [10:02] symlink targets are NOT created by laytous [10:02] *layouts [10:02] you can always use a bind mount for simplicitly [10:02] $SNAP/tmp: bind: $SNAP_DATA/tmp [10:02] zyga: Ah, that's the missing part. So I would create $SNAP_DATA/tmp in my install hook? Will explore bind mounts right now [10:02] just try the bind layout [10:02] it's easier [10:02] you will not need a hook [10:03] zyga: ok, going through your PR now [10:03] mborzecki: cool, wanna HO? [10:03] zyga: let me go through it first [10:03] +1 [10:08] mup: you ok? [10:08] Apparently the channel is still flagging off messages from unauthenticated people [10:09] mup: now? [10:09] niemeyer: I apologize. I'm a program with a limited vocabulary. [10:09] Yeah [10:10] haha [10:10] zyga: Would the mount be visible when ls -la /snap/my-snap/current/? (it does not, but I'm unsure if that's because of a faulty yaml definition or the bind is only visible within the running snap) [10:10] I love those discussions with mup :) [10:10] dot-tobias: it's only visible from the running snap [10:10] dot-tobias: to see it without any confinement, run your snap (say "foo") and then [10:10] dot-tobias: sudo nsenter -m/run/snapd/ns/foo.mnt [10:11] dot-tobias: you can always run "snap run --shell foo" but this will be fully confined and you won't be able to explore as freely [10:12] zyga: Ok, thanks. That clears things up for me, petty web-developer-turned-snapcrafter :-D [10:17] niemeyer: well, on signing in to freenode it still says “Due to the persistent ongoing spam, all new connections are being set +R (block messages from unidentified users) and will be scanned for vulnerabilities. This will not harm your computer, and vulnerable hosts will be notified.” [10:18] Chipaca: I assume that's for private messages.. the channel has its own setting, which apparently isn't on for ours [10:18] Maybe they just forced it [10:18] ah [10:19] niemeyer: yep, +R is about private messages [10:19] https://freenode.net/kb/answer/usermodes [10:19] niemeyer: as opposed to channel mode +r [10:19] I'll need to improve mup to identify itself properly on reconnections [10:20] It's reasonable anyway [10:20] /msg chanserv info #snappy [10:20] ^ to see what modes #snappy has [10:21] PR snapd#5771 opened: selftest: add test to ensure selftest.checks is up-to-date [10:21] bah, chanserv seems busted [10:21] Yeah, seems off.. I'm assuming they just got tired of all spamming and forced it in code for every channel [10:21] k [10:22] zyga: Please ping degville about the doc as well.. he seems off right now === jkridner|pd is now known as jkridner [10:32] niemeyer: ack [10:32] zyga: the doc for layouts looks fine; question on the "new entries in the / directory" limitation - is this problematic to handle, or simply not implemented yet? i can imagine this could be interesting for some weird/proprietary software [10:33] pstolowski: it's an architectual limitation, it's very hard to pull off and would require some action to happen before we pivot_root [10:33] pstolowski: we _could_ do it with a new filesystem eventually [10:33] but not now [10:33] pstolowski: we could also do it if we had snap-confine make / a tmpfs [10:34] and start with a bind mount farm based on the base snap [10:34] zyga: this doc reminded me i need to play with layouts in my problematic snap again [10:34] _that_ would not require a new filesystem [10:34] pstolowski: thanks, please share more feedback as you get it :) [10:34] pstolowski: and that is something new snap-confine could just do if we choose to implement it [10:34] pstolowski: but I haven't seen any demands for that yet [10:38] Chipaca: Commented on #5514.. I think you're fully unblocked now.. please ping otherwise [10:38] PR #5514: daemon, overlord/state: warnings pipeline [10:38] niemeyer: i replied to your first reply already :-D [10:38] zyga: ack, i see. indeed, i cannot think of any particular app needing it [10:38] Chipaca: I need to type faster... :P [10:39] niemeyer: the problem with having warnings accumulate args is that now we need to think about expiring the args somehow [10:40] niemeyer: unless I key on the format, and forget older args [10:40] that'd work [10:40] Chipaca: I actually had in mind keeping the exact logic you had [10:40] (if I keep older args, how are they presented to the user? etc) [10:40] niemeyer: so not worrying about dupes that much? [10:40] ok [10:40] Chipaca: It's just convenience so we don't need to Sprintf ourselves before cooking the message [10:41] Chipaca: In practice, just Sprintf as first thing, and keep the rest [10:41] Chipaca: (key is composed message) [10:41] ok [10:42] niemeyer: AddWarning -> Warn, and Warnf would be Sprintf version, ok? [10:42] zyga: btw https://github.com/snapcore/snapd/pull/5760/files#diff-6cdce42a784f927f710f0f5241a8c68dR84 such an opportunity lost :) [10:42] PR #5760: cmd/snap-update-ns: don't trespass on host filesystem in /etc and other places [10:42] Chipaca: We do want dupes when the message is indeed different.. e.g. two different broken snaps [10:42] Chipaca: I'd just have Warnf for now [10:42] mborzecki: ? [10:42] niemeyer: ok [10:43] Chipaca: Warnf("usual message") would work fine.. only danger is embedding %s on the message [10:43] * Chipaca nods [10:43] the f should have us remembering [10:43] mborzecki: ass usual I was reasonable ;) [10:43] (problem with daemon error handlers was there was no f to remember that) [10:43] :-) [10:44] anyway, time for a quick break before a meeting [10:44] niemeyer: thanks! [10:44] Chipaca: np! [10:45] niemeyer: actually, given Warnf(format, args...), i could be extra cautious and only sprintf if len(args) > 0 [10:46] that'll dtrt errytime === chihchun is now known as chihchun_afk [10:48] PR snapd#5772 opened: image: fix incorrect error when using local bases