mup | PR snapcraft#2828 opened: Appstream <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2828> | 01:18 |
---|---|---|
mup | PR snapd#7827 closed: tests: apply change on permissions to serial port on hotplug test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7827> | 01:42 |
=== arnatious_ is now known as arnatious | ||
mborzecki | morning | 06:30 |
sdhd-sascha | good morning | 07:14 |
pstolowski | morning | 08:04 |
mborzecki | pstolowski: mvo: morning guys | 08:14 |
mvo | hey mborzecki and pstolowski ! good morning | 08:15 |
mvo | mborzecki: how are you? and what did I miss :) ? | 08:16 |
mborzecki | mvo: nothing special, fri/mon were rather slow | 08:17 |
mvo | mborzecki: *nod* are tests ok ? or do they need investigation? | 08:17 |
mborzecki | mvo: got 2 prs green this morning, so things seem ok | 08:18 |
mvo | mborzecki: \o/ | 08:19 |
mvo | mborzecki: great! anything I can help with right away? otherwise I will just do the usual mail+check prs | 08:20 |
mborzecki | mvo: yday there were some concerns about https://github.com/snapcore/snapd/pull/7743 regarding having a partition from the block device mounted at the time of bootstrapping | 08:20 |
mup | PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743> | 08:20 |
* mvo looks | 08:21 | |
mvo | mborzecki: woah, nice find in 7824 | 08:22 |
mvo | mborzecki: do you happen to know if there is an upstream bugreport for mksquashfs? it sounds like worth asking for a "-strict" (or whatever) switch that would actually error in situations like this (it's hard for me to imagine when it's useful to *not* error by default) | 08:23 |
zyga | good morning | 08:23 |
mvo | mborzecki: anyway not super important, just an idle thought | 08:23 |
mvo | zyga: good morning! | 08:23 |
zyga | :) | 08:24 |
zyga | mvo: yeah, thinks seem calm, just reviews and iteration | 08:24 |
mborzecki | zyga: hey | 08:24 |
mvo | zyga: how are you? jetlag better? | 08:24 |
mborzecki | mvo: didn't check | 08:24 |
* mvo was super tired this morning but otherwise feeling good | 08:25 | |
zyga | mvo: yeah :-) It's all over finally :) | 08:25 |
* mvo just gets more tea and everything will be back to normal :) | 08:25 | |
mvo | zyga: yay! | 08:25 |
zyga | mvo: I tried to record my first ubuntu core video | 08:25 |
mvo | zyga: I read somewhere it take ~1day per hour timezone difference | 08:25 |
zyga | mvo: more attempts today, it's a lot of work :D | 08:25 |
mvo | zyga: that's so cool! | 08:25 |
mvo | mborzecki: also - holly cow - 7821! | 08:29 |
mvo | mborzecki: pretty impressive numbers | 08:29 |
mup | PR snapd#7822 closed: devicestate: ensure system installation <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7822> | 08:29 |
* mvo hugs mborzecki | 08:29 | |
mup | PR snapd#7820 closed: boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7820> | 08:30 |
pedronis | mvo: hi, a post-merge remark on #7820 | 08:40 |
mup | PR #7820: boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7820> | 08:40 |
mvo | pedronis: thank you, on it | 08:45 |
mvo | pedronis: uh, sorry, indeed, will fix right away | 08:45 |
mvo | pedronis: I added a comment to 7823 (which is also shorter now that bits from master are merged) | 08:56 |
pedronis | mvo: ok, what should I review next? | 09:01 |
pedronis | I mean for UC20 | 09:01 |
mvo | pedronis: 7823 would be nice, then I want to ponder about 7762, my gut feeling is that some of the partition finding could/should move to snap-bootstrap | 09:02 |
mvo | pedronis: and then I want to update 7817 based on your feedback | 09:02 |
mvo | pedronis: I hope this sounds sensible | 09:02 |
=== Girtablulu_ is now known as Girtablulu | ||
pedronis | mvo: fwiw I had the same wondering at some point, about the partition finding | 09:12 |
mvo | pedronis: in 7762 ? | 09:20 |
pedronis | yes | 09:21 |
* mvo nods and will have a look | 09:26 | |
mborzecki | hm master unit tests broken? | 09:33 |
zyga | mborzecki: oh? | 09:35 |
mborzecki | must be the devicemgr PR that landed | 09:35 |
mborzecki | https://paste.ubuntu.com/p/sdjF7VJbfC/ | 09:35 |
zyga | indeed | 09:35 |
zyga | mborzecki: are you pushing or shall I? | 09:36 |
zyga | or better yet | 09:36 |
zyga | mvo: can you push a trivial directly to master/ | 09:36 |
zyga | https://www.irccloud.com/pastebin/PZj3DJ9C/ | 09:36 |
zyga | mvo: will save us an hour | 09:37 |
mborzecki | hahah | 09:37 |
zyga | I'll open a PR just in case | 09:39 |
zyga | all this CI | 09:40 |
zyga | ... | 09:40 |
mvo | zyga: can do | 09:40 |
zyga | mvo: thanks | 09:40 |
mvo | zyga: should be fine now | 09:43 |
* zyga thanks :) | 09:44 | |
mborzecki | pedronis: hi, i've updated #7821 | 09:49 |
mup | PR #7821: [RFC] interfaces/seccomp: parallelize seccomp backend setup <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821> | 09:50 |
pedronis | mborzecki: thanks, queued | 09:53 |
* zyga has some food poisoning this morning | 09:57 | |
mborzecki | pedronis: cool, thanks | 09:57 |
zyga | if I'm not responsive, that's why :/ | 09:57 |
mup | PR snapd#7824 closed: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7824> | 10:06 |
mup | PR snapd#7830 opened: Include hooks in plug/slot apparmor label <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830> | 10:06 |
niemeyer | Hellos | 10:57 |
niemeyer | mvo: ping | 10:57 |
mvo | hey niemeyer | 11:06 |
niemeyer | mvo: Heya | 11:06 |
niemeyer | mvo: Do you have a moment for a call? | 11:06 |
niemeyer | mvo: I'm setting up mup and was going to ask about it, but actually it would be nice to have a quick sync call if you have a few spare minutes | 11:07 |
mvo | niemeyer: yes, sure! | 11:07 |
niemeyer | mvo: Nice, let me grab a cup of coffee quickly and will drop you a link | 11:07 |
pstolowski | mborzecki: i think Sergio addressed your comments to https://github.com/snapcore/snapd/pull/7815 ; can we land it? | 11:08 |
mup | PR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815> | 11:08 |
mup | PR snapd#7815 closed: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7815> | 11:10 |
pstolowski | ty! | 11:10 |
zyga | mborzecki: hey | 11:11 |
zyga | mborzecki: I moved the code we talked about to sandbox/cgroup | 11:11 |
zyga | mborzecki: shall I push that to https://github.com/snapcore/snapd/pull/7825 ? | 11:11 |
mup | PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825> | 11:11 |
pstolowski | Chipaca: hey, question to you on https://bugs.launchpad.net/snapd/+bug/1838786 | 11:17 |
mup | Bug #1838786: Categories not returned in /v2/find results <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1838786> | 11:18 |
Chipaca | pstolowski: yep, tks | 11:18 |
pstolowski | Chipaca: i might have asked about it during my last triage duty ;) | 11:18 |
pstolowski | if you update it, i'll stop asking ;) | 11:19 |
Chipaca | pstolowski: i mean, there isn't a status for "started, will be completed, but not being worked on right now" | 11:19 |
pstolowski | true, np, just comment on it | 11:19 |
zyga | mborzecki: updated | 11:22 |
* zyga returns to garden next branch in a moment | 11:23 | |
zyga | re | 11:30 |
zyga | 15C in the office | 11:31 |
zyga | no wonder I have a cold | 11:31 |
mborzecki | zyga: you should really get a heater or sth | 11:33 |
mborzecki | quick errand, back in 20 | 11:33 |
xnox | zyga: i was off on monday. Reading backscross with cmatsuoka, in the initrd /dev is populated by multiple things: a) devtmpfs (ie. kernel itself) b) processing /lib/modules/{kver}/modules.devname by systemd-tmpfiles c) anything else statically created | 11:33 |
zyga | xnox: aha | 11:41 |
zyga | xnox: do you know what's the relationship between devtmpfs and in-kerenl kobj events | 11:41 |
zyga | xnox: I can point you to specific lines in the kerenl | 11:42 |
zyga | xnox: for instance when the block device layer drops and re-creates partitions | 11:42 |
zyga | xnox: is that automatically reflected in devtmpfs? | 11:42 |
zyga | mborzecki: the heater is on now | 11:42 |
xnox | zyga: no, and why should it be? | 11:44 |
zyga | pstolowski: small suggestion for the label expr branch | 11:44 |
zyga | xnox: I'm not yet sure about "should" vs "not should" - just trying to piece together my undersstanding | 11:45 |
zyga | xnox: when the ioctl to rescan partition table is issued | 11:45 |
xnox | kernel needs to be told to reload the partitions...... i.e. using kpartx, blockdev, etc. | 11:45 |
zyga | xnox: the kernel removes and re-creates partition nodes | 11:45 |
zyga | xnox: when this happens the kernel side is updated | 11:45 |
zyga | xnox: but what about the filesystem? | 11:45 |
zyga | xnox: I'm trying to understand what updates /dev/ itself | 11:45 |
zyga | xnox: is that some minimal udev running in initrd or is that directly done by the kernel | 11:46 |
xnox | kernel udev events are emitted, which udev processes, and does changes to. | 11:46 |
xnox | not minimal, but full-fat udevd. | 11:46 |
zyga | ah, so there is real udev there? | 11:46 |
zyga | ah | 11:46 |
xnox | in all of our initrds..... | 11:46 |
zyga | ok, that explains everything I was wondering about | 11:46 |
zyga | cool, thank you | 11:46 |
xnox | but it may have different set of udev rules & helpers (i.e. raid/lvm/cryptsetup/dm-setup might be missing) | 11:46 |
zyga | xnox: if you are interested in the backstory | 11:46 |
xnox | or even versions | 11:46 |
zyga | xnox: there was some discussion about this specific part: | 11:46 |
xnox | for example, old initrd may have older systemd, and thus initrd symlinks/names might be different to the "booted" system. | 11:47 |
zyga | https://github.com/snapcore/snapd/pull/7743 | 11:47 |
mup | PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743> | 11:47 |
zyga | xnox: that's interesting | 11:47 |
zyga | xnox: (when I say interesting, I mean, how are we going to handle that) | 11:47 |
zyga | pstolowski: your patch looks good, I suspect the failure shows something that is broken but was dormant before | 11:52 |
pstolowski | zyga: i don't know, it's super weird.. opening { is missing, closing } is there. i don't see how this is possible | 11:53 |
zyga | pstolowski: can you paste the line please | 11:54 |
mborzecki | re | 11:56 |
zyga | mborzecki: 18C now | 11:56 |
zyga | mborzecki: +4 outside | 11:56 |
mborzecki | zyga: showing 2C outside here, though it's sunny yay | 12:00 |
ppd1990 | Hi. Is there anyone here I can poke for a transfer request? My forum request is getting a little stale ;-) (https://forum.snapcraft.io/t/please-transfer-solvespace-to-solvespace-account/14342) | 12:01 |
pstolowski | zyga: peer=(label="snap.core.}"), | 12:02 |
zyga | ha | 12:05 |
zyga | I ... know | 12:05 |
zyga | pstolowski: do you see it? | 12:05 |
zyga | https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR66 | 12:05 |
mup | PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830> | 12:06 |
zyga | it must only truncate if len(names) > 0 | 12:06 |
zyga | pstolowski: add a test for that please | 12:06 |
zyga | pstolowski: in addition https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR45 may need to be dropped | 12:07 |
zyga | and instead the name collection may have to move earlier | 12:07 |
mup | PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830> | 12:07 |
zyga | pstolowski: so that the same if one { } else if zero else { } flow can remain | 12:07 |
pstolowski | zyga: ha, thanks for spotting | 12:09 |
pstolowski | ok, i think i got it simplified, running the tests.. short break, going to collect my usb hub from post office | 12:17 |
zyga | pstolowski: cool, good luck! | 12:17 |
zyga | mborzecki: can you look at https://github.com/snapcore/snapd/pull/7825 again | 12:22 |
mup | PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825> | 12:22 |
zyga | mborzecki: I'll find those tests I wrote for some of the TODOs there | 12:22 |
mborzecki | ok | 12:22 |
zyga | mborzecki: but I did some structural changes you asked for | 12:22 |
=== pedronis_ is now known as pedronis | ||
pedronis | mvo: #7823 looks fine afaict | 12:58 |
mup | PR #7823: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7823> | 12:58 |
pstolowski | zyga: is label="snap.core." same as label="snap.core.*" ? | 13:38 |
zyga | pstolowski: no, it is not | 13:38 |
pstolowski | zyga: is "snap.core." matching anything? | 13:40 |
zyga | only the label "snap.core." | 13:41 |
zyga | which nothing in our system will have | 13:41 |
pstolowski | zyga: good | 13:43 |
pstolowski | zyga: one more twist in that PR | 13:43 |
pstolowski | (not pushed yet) | 13:43 |
mup | PR snapd#7829 closed: tests: fix the channels checks done on nested tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7829> | 14:04 |
=== tinwood_ is now known as tinwood | ||
=== ricab is now known as ricab|lunch | ||
jdstrand | pedronis: hey, amurray asked you to respond to https://forum.snapcraft.io/t/system-files-under-mozilla-native-messaging-hosts | 14:20 |
jdstrand | pedronis: but per our conversation in Vancouver, I will | 14:21 |
pedronis | jdstrand: thx | 14:22 |
pedronis | jdstrand: #7768 needs a unit test fix | 14:23 |
mup | PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768> | 14:23 |
jdstrand | pedronis: yep, hoping to get to that today. thanks | 14:24 |
pedronis | zyga: jdstrand asked you to (re)review #7228 | 14:24 |
zyga | ack, will do | 14:24 |
mup | PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228> | 14:24 |
mborzecki | cmatsuoka: you broke github ;) just got an email with '@cmatsuoka pushed 0 commits.' | 14:29 |
roadmr | hmm... push --overwrite with an unchanged branch? | 14:31 |
roadmr | er --force (sorry, too much bzr) | 14:31 |
pedronis | pstolowski: let me know if we should have a chat about services tomorrow or later in the week | 14:31 |
cmatsuoka | I'm pushing 0 commits all the time | 14:31 |
zyga | brb, lunch | 14:31 |
cmatsuoka | But yeah, I don't know what happened there, I'll check | 14:32 |
mup | PR snapd#7831 opened: [RFC] gadget: extract and export new DiskFromPartition() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/7831> | 14:32 |
pstolowski | pedronis: ok, thanks, will think a bit more and maybe tomorrow | 14:33 |
mup | PR snapd#7832 opened: [RFC] snap-bootstrap: support auto-detect device in create-partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832> | 14:48 |
pedronis | mvo: what's the relation of 7831 and 7832, does one need the other or are they exclusive? | 14:53 |
mvo | pedronis: I think we want something like 7831 in any case, i.e. have just a single way to find a parent-disk from a partition | 14:54 |
pedronis | ok | 14:54 |
mvo | pedronis: with 7832 it goes one step further and move the business of finding that disk from devicemanager into the low-level of snap-boostrrap | 14:55 |
mvo | pedronis: my feeling is that devceimanager is too high level for dealing with the low-level bits that are currently done there in 7762. but I could be wrong and this is why I want a second opinion :) and code seems to be the easiest way to express the question | 14:56 |
mborzecki | cmatsuoka: mvo: for uc20, is the ubuntu-seed partition encrypted? | 15:01 |
pedronis | mborzecki: no | 15:03 |
pedronis | only -data and -save will be | 15:04 |
mborzecki | pedronis: thx | 15:06 |
mup | PR snapcraft#2817 closed: snapcraft/plugins: Add gomod plugin <Created by mhilton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2817> | 15:07 |
mup | PR snapd#7833 opened: HACKING.md: add nvidia options to configure example <Documentation> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7833> | 15:18 |
ijohnson | degville: when you get a chance could you quick take a look at ^ | 15:18 |
ijohnson | also I created a new tag for PR's in snapd called "Documentation", I don't think we'll have many such PR's but seems nice to have | 15:19 |
degville | ijohnson: will do - thank you! | 15:19 |
cachio | mborzecki, hey, when you have few minutes could you please give a second round to #7826 | 15:24 |
mup | PR #7826: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7826> | 15:24 |
=== ricab|lunch is now known as ricab | ||
* cachio lunch | 15:25 | |
pedronis | mvo: the approach in #7832 looks reasonable | 15:34 |
mup | PR #7832: [RFC] snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832> | 15:34 |
mvo | pedronis: \o/ | 15:34 |
mvo | pedronis: thanks for the feedback | 15:34 |
pedronis | Chipaca: #7771 will need a re-review | 15:35 |
mup | PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771> | 15:35 |
pedronis | but I asked for some changes | 15:35 |
Chipaca | yep yep | 15:35 |
pedronis | still | 15:35 |
Chipaca | this thing might be interesting for a few of us: http://www.brendangregg.com/blog/2019-12-02/bpf-a-new-type-of-software.html | 15:35 |
=== Son_Goku is now known as Conan_Kudo | ||
=== Conan_Kudo is now known as Son_Goku | ||
zyga | back from lunch | 16:07 |
zyga | but need to take a break now | 16:07 |
zyga | back in 2 hours to wrap up the day | 16:07 |
zyga | Chipaca: I looked at that | 16:07 |
zyga | Chipaca: it's really true in many ways | 16:07 |
zyga | changes what needs to be done as a kernel patch | 16:08 |
* Chipaca afk | 16:54 | |
mup | PR snapd#7834 opened: tests: move the watchdog timeout to 2s to make the tests work in rpi <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7834> | 17:45 |
zyga | re | 17:49 |
* zyga was sleeping | 17:49 | |
zyga | back to work | 17:49 |
zyga | with some tea to help | 17:49 |
=== heather is now known as hellsworth | ||
* Chipaca soft-EODs | 17:54 | |
cmatsuoka | signal(SIGEOD, SIG_IGN) | 17:55 |
=== ijohnson is now known as ijohnson|lunch | ||
* Chipaca feels ignored, now | 18:26 | |
* Chipaca might get used to this | 18:27 | |
=== ijohnson|lunch is now known as ijohnson | ||
* zyga hugs Chipaca | 19:10 | |
zyga | I just discovered mold behind a whiteboard | 19:10 |
zyga | "yay" | 19:11 |
mup | PR snapcraft#2829 opened: store cli: push title and license on push-metadata <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2829> | 19:14 |
jdstrand | noise][: hey, who would I talk to these days about the snap-store-proxy? | 20:02 |
jdstrand | noise][: I see bloodearnest uploaded it last | 20:04 |
jdstrand | bloodearnest: hey, curious why the snap-store-proxy is only available on amd64. I was going to try to configure it locally for an armhf device but can't... | 20:05 |
roadmr | jdstrand: we just haven't built for other arches because who would want to host a store-proxy on a raspberry pi :) | 20:12 |
roadmr | jdstrand: (I think - there may be a real reason behind it but the truth is the main audience would be enterprises which are more likely to host a beefy org-wide proxy on a big amd64 box) | 20:12 |
jdstrand | roadmr: well, I was literally trying to do that. I wanted to use uc18 on an rpi3 on an hd. I figured the the proxy itself would not be resource intensive and just needs disk, which is easy enough to do | 20:15 |
noise][ | jdstrand: i think there was a reason … maybe one of the components we are using wasn't readily available on arm, but we'd have to have someone go poke at it again | 20:16 |
roadmr | jdstrand: well it does need a postgres database | 20:16 |
jdstrand | roadmr: personally, I do quite a bit of dev with quite a few devices and was getting tired of always reaching out to the store with refreshes, etc, etc | 20:16 |
jdstrand | roadmr: it is already installed :) | 20:16 |
roadmr | jdstrand: the rpi is probably 10x more powerful than the first server I set up a pg database on, so that should be covered, but it does sound odd to have that on a pi :) | 20:16 |
jdstrand | roadmr: snap install postgresql10 | 20:17 |
roadmr | \o/ | 20:17 |
jdstrand | roadmr: it is literally begging to be used right now :) | 20:17 |
roadmr | hehe | 20:17 |
* cachio afk | 20:17 | |
jdstrand | I guess I am begging for it to be used too... | 20:17 |
jdstrand | :) | 20:17 |
jdstrand | roadmr: fyi, loadavg is nearly all 0s with 444M of ram free with pg running... figured this would actually be a nice use of the pi... | 20:21 |
jdstrand | anyhoo, curious on the outcome of that | 20:22 |
roadmr | jdstrand: I'll check with twom and bloodearnest tomorrow to see what the reason was | 20:22 |
jdstrand | roadmr: thanks! | 20:23 |
mup | PR snapd#7828 closed: tests: demand silence from check_journalctl_log <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7828> | 20:27 |
bloodearnest | jdstrand: o/ it's just a matter of doing the work to support it - we have go services built, so if that can build for armhf, we should be able to. There's also a horrible LD_PRELOAD shim (due to https://forum.snapcraft.io/t/seccomp-filtering-for-setgroups/2109/10) that we'd need to build for armhf too, but it should be doable. | 20:27 |
bloodearnest | everything else is python and archive packages | 20:28 |
jdstrand | bloodearnest: well, we build a lot with go on arm, so that is hopefully not a problem. there is https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/lib.c that should work with setgroups | 21:00 |
jdstrand | bloodearnest: as documented in https://forum.snapcraft.io/t/system-usernames/13386 | 21:01 |
jdstrand | bloodearnest: so, if this is something that you're interested in, you have a tester and a user :) | 21:01 |
bloodearnest | jdstrand: thanks. I don't have an armhf device handy, but I'll add a trello card for it | 21:02 |
jdstrand | bloodearnest: while I have you, I was a little surprised that snap-store-proxy didn't ship its own pg. I mean, I understand that snap-store-proxy might want to use an external pg, but also seemed like it might be nice to not be required to | 21:03 |
jdstrand | bloodearnest: I think that is what the maas snap is doing (though I'm not sure) | 21:03 |
jdstrand | bloodearnest: anyhoo, thanks! | 21:03 |
bloodearnest | jdstrand: we want'd do, but postgresql has a hard coded if (uid != 0) { error() } type check. So we'd have to patch it and build our own to run it. | 21:04 |
bloodearnest | Unless running as non-uid-zero users in a service are now a thing, and I missed that? | 21:05 |
jdstrand | bloodearnest: it is now a thing: https://forum.snapcraft.io/t/system-usernames/13386 | 21:05 |
bloodearnest | jdstrand: well, hello there, that is nice. Ok, we might add that now :) | 21:06 |
jdstrand | bloodearnest: you don't have the nicety of User=/Group= in the systemd unit yet, but you can solve that with a wrapper | 21:06 |
bloodearnest | jdstrand: so the wrapper needs to su? | 21:07 |
jdstrand | bloodearnest: I was actually wondering if maybe you wanted to run the proxy as snap_daemon, but didn't want to push my luck since you were so nice with the armhf question :) | 21:07 |
bloodearnest | jdstrand: I totally would prefer to run all the services as snap_daemon, including a bundled pg. Does setgroups for snap_daemons gid work? | 21:09 |
bloodearnest | I'll add some bugs to track these I think. | 21:09 |
jdstrand | bloodearnest: I was thinking a C wrapper. su is allowed in the policy currently. runuser might work. let me try real quick | 21:10 |
bloodearnest | we already wrap our servcies in a bash exec launcher, for various reasons, so su would be simpler | 21:11 |
jdstrand | bloodearnest: setgroups still needs to use '0, NULL' as mentioned in the forum, but setgid and setuid and the whole family (setreuid, setresuid, etc) all work | 21:11 |
jdstrand | err, su isn't* allowed in the policy currently. that won't work come to think of it cause of pam | 21:11 |
bloodearnest | ah, yeah | 21:12 |
bloodearnest | hmm | 21:12 |
jdstrand | but let me try something with runuser | 21:12 |
* jdstrand plays for a minute | 21:12 | |
jdstrand | bloodearnest: ok, so like su, runuser needs pam so no go. however, start-stop-daemon from dpkg can be used with an LD_PRELOAD. so I updated https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/lib.c to also handle initgroups and then can do: LD_PRELOAD=$SNAP_COMMON/wraplib.so ./start-stop-daemon --pidfile /dev/null --start --chuid snap_daemon --group snap_daemon --startas /bin/sh -- -c "sleep 300" | 21:43 |
jdstrand | bloodearnest: that was within 'sudo snap run --shell test-snapd-daemon-user.drop' and cd'd into SNAP_COMMON and copied the wraplib.so and start-stop-daemon there | 21:44 |
bloodearnest | jdstrand: thanks. That is more complex than I'd like - is User=/Group= support in systemd unit file on the roadmap? | 21:45 |
jdstrand | bloodearnest: it isn't 'pretty', but if you are already compiling an LD_PRELOAD (which it sounds like you are), you need only stage-packages dpkg. that said, if you are already compiling an LD_PRELOAD, you could modify drop.c from that same branch | 21:45 |
bloodearnest | jdstrand: right, we're just using the LD_PRELOAD for nginx, we run about 6 python services and a golang one too. | 21:47 |
jdstrand | bloodearnest: isn't on the 'committed to do it for 20.04' roadmap, but it is queued in trello for whenever I can squeeze it in | 21:47 |
bloodearnest | jdstrand: ack, thanks | 21:47 |
jdstrand | bloodearnest: since you are doing it for nginx, you could set 'environment' in the snapcraft.yaml for anything that uses initgroups | 21:48 |
jdstrand | I could write a 'runas' binary in that tree | 21:49 |
ijohnson | bloodearnest, I made a postgres snap with snap_daemon | 21:49 |
jdstrand | ijohnson: what did you do to drop? | 21:50 |
jdstrand | ijohnson: and what is the name of that snap? I'd like to use yours instead of the one I have | 21:50 |
jdstrand | :) | 21:50 |
ijohnson | bloodearnest: jdstrand: https://github.com/anonymouse64/postgres-snap | 21:50 |
bloodearnest | jdstrand: re environment in snapcraft.yaml, can they now expand $SNAP{_DATA,_COMMON} and such in their value? | 21:50 |
ijohnson | I used https://github.com/tianon/gosu.git to drop privileges | 21:50 |
ijohnson | jdstrand: ^ | 21:50 |
bloodearnest | ijohnson: oh, nice, will take a look | 21:51 |
ijohnson | jdstrand: although I don't remember I put it in the store or not, I didn't want to mess with the pre-existing postgres snaps and didn't have the time to engage with upstream | 21:51 |
ijohnson | bloodearnest: the other tricky thing I ran into is auto-setting up a db that the other service used, cause you need to run various commands on install, but you want them to be run as snap_damon user | 21:52 |
jdstrand | oh, setpriv | 21:52 |
* jdstrand looks at that | 21:52 | |
ijohnson | a full example of using postgres as a service with something else that actually uses postgres is my kong snap: https://github.com/anonymouse64/kong-snap | 21:53 |
bloodearnest | ijohnson: this is all useful info, looks like you've solved some tough problems there, which we can reuse - thanks! | 21:54 |
ijohnson | bloodearnest: happy to see my work used :-) | 21:54 |
bloodearnest | ijohnson: what are your thoughts around SNAP_DATA vs SNAP_COMMON for the db files? Having it in SNAP_DATA makes refresh a) slow and b) potentially irreversable w/o dataloss (if data was written to the new revisions $SNAP_DATA) | 21:55 |
ijohnson | bloodearnest: hmm I guess I typically like to keep data in $SNAP_DATA so you can revert safely, I guess I'm not usually concerned with losing data on a revert, since almost all the times I've seen reverts is when something fails right after upgrading and so there's either no data or almost no data | 21:58 |
ijohnson | if keeping all the data all the time is important then you probably need to use $SNAP_COMMON, and make sure you use epochs carefully to ensure that if the version of postgres changes or otherwise your db is incompatible with a future revision that you will step through snap revisions that can migrate back and forth safely | 21:59 |
* ijohnson steps out for a minute | 21:59 | |
jdstrand | bloodearnest: ok, setpriv from util-linux works almost perfectly for this: LD_PRELOAD=$SNAP_COMMON/wraplib.so ./setpriv --clear-groups --reuid snap_daemon --regid snap_daemon -- sleep 300 | 22:01 |
bloodearnest | ijohnson: yep, it's tricky. I'd probably lean towards using tracks and an explicit copy/migrate step, rather than epochs. Firstly, because that's closer to typical production DB upgrades, and b) epochs are really quite hard to reason about. | 22:01 |
bloodearnest | jdstrand: oh, that's much nicer | 22:01 |
jdstrand | bloodearnest: --clear-groups uses setgroups in the portable manner, not the snapd required manner, hence the preload | 22:02 |
jdstrand | bloodearnest: you can use --keep-groups and forego the preload, but, well, you have 0 in your list | 22:02 |
* jdstrand documents setpriv in the forum | 22:03 | |
jdstrand | bloodearnest: ok, maybe between snap_daemon I did last cycle and the exploration, that is enough to consider the armhf build ;) | 22:05 |
jdstrand | bloodearnest: seriously though, lemme know if you have issues with snap_daemon. I'd really like to add User=/Group= this cycle, but it won't be til late in the cycle | 22:05 |
ijohnson | jdstrand: any thoughts on putting that wraplib.so inside snapcraft-preload? | 22:07 |
bloodearnest | sjdstrand: right. FTR, the reason we still need LD_PRELOAD, AIUI, is that glib's initgroups (which is called by nginx) will *always* call setgroups with n>0 and a non-NULL pointer, and thus trip SECOMP up. | 22:07 |
bloodearnest | jdstrand: I'll try see if we can schedule this, but snap-proxy work is fairly low in the the list for next cycle | 22:07 |
jdstrand | bloodearnest: sure, I understand | 22:08 |
jdstrand | ijohnson: have had thoughts on that | 22:08 |
jdstrand | :) | 22:08 |
jdstrand | ijohnson: https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/snapcraft.yaml does show how to do this rather easily as well | 22:09 |
jdstrand | (which is documented in https://forum.snapcraft.io/t/system-usernames/13386, but not a reason for it not to be in snapcraft-preload) | 22:11 |
bloodearnest | jdstrand: FYI https://bugs.launchpad.net/snapstore-snap/+bug/1855005, https://bugs.launchpad.net/snapstore-snap/+bug/1855007, https://bugs.launchpad.net/snapstore-snap/+bug/1855008 | 22:19 |
ijohnson | jdstrand: yes that's simple enough, but we already end up needing to use snapcraft-preload for postgres anyways so having this in snapcraft-preload is one less thing to track and build | 22:37 |
jdstrand | bloodearnest: thanks! | 22:40 |
jdstrand | ijohnson: yeah. I think serguisens mentioned he was going to make it easier to contribute to | 22:41 |
jdstrand | (snapcraft-preload) | 22:41 |
ijohnson | great, that would be cool :-) | 22:53 |
jdstrand | ijohnson: oh, I meant to say, really nice caching forum topic | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!