/srv/irclogs.ubuntu.com/2019/12/03/#snappy.txt

mupPR snapcraft#2828 opened: Appstream <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2828>01:18
mupPR 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
mborzeckimorning06:30
sdhd-saschagood morning07:14
pstolowskimorning08:04
mborzeckipstolowski: mvo: morning guys08:14
mvohey mborzecki and pstolowski ! good morning08:15
mvomborzecki: how are you? and what did I miss :) ?08:16
mborzeckimvo: nothing special, fri/mon were rather slow08:17
mvomborzecki: *nod* are tests ok ? or do they need investigation?08:17
mborzeckimvo: got 2 prs green this morning, so things seem ok08:18
mvomborzecki: \o/08:19
mvomborzecki: great! anything I can help with right away? otherwise I will just do the usual mail+check prs08:20
mborzeckimvo: 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 bootstrapping08:20
mupPR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>08:20
* mvo looks08:21
mvomborzecki: woah, nice find in 782408:22
mvomborzecki: 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
zygagood morning08:23
mvomborzecki: anyway not super important, just an idle thought08:23
mvozyga: good morning!08:23
zyga:)08:24
zygamvo: yeah, thinks seem calm, just reviews and iteration08:24
mborzeckizyga: hey08:24
mvozyga: how are you? jetlag better?08:24
mborzeckimvo: didn't check08:24
* mvo was super tired this morning but otherwise feeling good08:25
zygamvo: yeah :-) It's all over finally :)08:25
* mvo just gets more tea and everything will be back to normal :)08:25
mvozyga: yay!08:25
zygamvo: I tried to record my first ubuntu core video08:25
mvozyga: I read somewhere it take ~1day per hour timezone difference08:25
zygamvo: more attempts today, it's a lot of work :D08:25
mvozyga: that's so cool!08:25
mvomborzecki: also - holly cow - 7821!08:29
mvomborzecki: pretty impressive numbers08:29
mupPR 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
mupPR 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
pedronismvo: hi, a post-merge remark on #782008:40
mupPR #7820: boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7820>08:40
mvopedronis: thank you, on it08:45
mvopedronis: uh, sorry, indeed, will fix right away08:45
mvopedronis: I added a comment to 7823 (which is also shorter now that bits from master are merged)08:56
pedronismvo: ok,  what should I review next?09:01
pedronisI mean for UC2009:01
mvopedronis: 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-bootstrap09:02
mvopedronis: and then I want to update 7817 based on your feedback09:02
mvopedronis: I hope this sounds sensible09:02
=== Girtablulu_ is now known as Girtablulu
pedronismvo: fwiw I had the same wondering at some point, about the partition finding09:12
mvopedronis: in 7762 ?09:20
pedronisyes09:21
* mvo nods and will have a look09:26
mborzeckihm master unit tests broken?09:33
zygamborzecki: oh?09:35
mborzeckimust be the devicemgr PR that landed09:35
mborzeckihttps://paste.ubuntu.com/p/sdjF7VJbfC/09:35
zygaindeed09:35
zygamborzecki: are you pushing or shall I?09:36
zygaor better yet09:36
zygamvo:  can you push a trivial directly to master/09:36
zygahttps://www.irccloud.com/pastebin/PZj3DJ9C/09:36
zygamvo: will save us an hour09:37
mborzeckihahah09:37
zygaI'll open a PR just in case09:39
zygaall this CI09:40
zyga...09:40
mvozyga: can do09:40
zygamvo: thanks09:40
mvozyga: should be fine now09:43
* zyga thanks :)09:44
mborzeckipedronis: hi, i've updated #782109:49
mupPR #7821: [RFC] interfaces/seccomp: parallelize seccomp backend setup <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>09:50
pedronismborzecki: thanks, queued09:53
* zyga has some food poisoning this morning09:57
mborzeckipedronis: cool, thanks09:57
zygaif I'm not responsive, that's why :/09:57
mupPR 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
mupPR snapd#7830 opened: Include hooks in plug/slot apparmor label <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>10:06
niemeyerHellos10:57
niemeyermvo: ping10:57
mvohey niemeyer11:06
niemeyermvo: Heya11:06
niemeyermvo: Do you have a moment for a call?11:06
niemeyermvo: 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 minutes11:07
mvoniemeyer: yes, sure!11:07
niemeyermvo: Nice, let me grab a cup of coffee quickly and will drop you a link11:07
pstolowskimborzecki: i think Sergio addressed your comments to https://github.com/snapcore/snapd/pull/7815 ; can we land it?11:08
mupPR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815>11:08
mupPR 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
pstolowskity!11:10
zygamborzecki: hey11:11
zygamborzecki: I moved the code we talked about to sandbox/cgroup11:11
zygamborzecki: shall I push that to https://github.com/snapcore/snapd/pull/7825 ?11:11
mupPR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>11:11
pstolowskiChipaca: hey, question to you on https://bugs.launchpad.net/snapd/+bug/183878611:17
mupBug #1838786: Categories not returned in /v2/find results <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1838786>11:18
Chipacapstolowski: yep, tks11:18
pstolowskiChipaca: i might have asked about it during my last triage duty ;)11:18
pstolowskiif you update it, i'll stop asking ;)11:19
Chipacapstolowski: i mean, there isn't a status for "started, will be completed, but not being worked on right now"11:19
pstolowskitrue, np, just comment on it11:19
zygamborzecki: updated11:22
* zyga returns to garden next branch in a moment11:23
zygare11:30
zyga15C in the office11:31
zygano wonder I have a cold11:31
mborzeckizyga: you should really get a heater or sth11:33
mborzeckiquick errand, back in 2011:33
xnoxzyga:  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 created11:33
zygaxnox: aha11:41
zygaxnox: do you know what's the relationship between devtmpfs and in-kerenl kobj events11:41
zygaxnox: I can point you to specific lines in the kerenl11:42
zygaxnox: for instance when the block device layer drops and re-creates partitions11:42
zygaxnox: is that automatically reflected in devtmpfs?11:42
zygamborzecki: the heater is on now11:42
xnoxzyga:  no, and why should it be?11:44
zygapstolowski: small suggestion for the label expr branch11:44
zygaxnox: I'm not yet sure about "should" vs "not should" - just trying to piece together my undersstanding11:45
zygaxnox: when the ioctl to rescan partition table is issued11:45
xnoxkernel needs to be told to reload the partitions...... i.e. using kpartx, blockdev, etc.11:45
zygaxnox: the kernel removes and re-creates partition nodes11:45
zygaxnox: when this happens the kernel side is updated11:45
zygaxnox: but what about the filesystem?11:45
zygaxnox: I'm trying to understand what updates /dev/ itself11:45
zygaxnox: is that some minimal udev running in initrd or is that directly done by the kernel11:46
xnoxkernel udev events are emitted, which udev processes, and does changes to.11:46
xnoxnot minimal, but full-fat udevd.11:46
zygaah, so there is real udev there?11:46
zygaah11:46
xnoxin all of our initrds.....11:46
zygaok, that explains everything I was wondering about11:46
zygacool, thank you11:46
xnoxbut it may have different set of udev rules & helpers (i.e. raid/lvm/cryptsetup/dm-setup might be missing)11:46
zygaxnox: if you are interested in the backstory11:46
xnoxor even versions11:46
zygaxnox: there was some discussion about this specific part:11:46
xnoxfor example, old initrd may have older systemd, and thus initrd symlinks/names might be different to the "booted" system.11:47
zygahttps://github.com/snapcore/snapd/pull/774311:47
mupPR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>11:47
zygaxnox: that's interesting11:47
zygaxnox: (when I say interesting, I mean, how are we going to handle that)11:47
zygapstolowski: your patch looks good, I suspect the failure shows something that is broken but was dormant before11:52
pstolowskizyga: i don't know, it's super weird.. opening { is missing, closing } is there. i don't see how this is possible11:53
zygapstolowski: can you paste the line please11:54
mborzeckire11:56
zygamborzecki: 18C now11:56
zygamborzecki: +4 outside11:56
mborzeckizyga: showing 2C outside here, though it's sunny yay12:00
ppd1990Hi. 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
pstolowskizyga: peer=(label="snap.core.}"),12:02
zygaha12:05
zygaI ... know12:05
zygapstolowski: do you see it?12:05
zygahttps://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR6612:05
mupPR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>12:06
zygait must only truncate if len(names) > 012:06
zygapstolowski: add a test for that please12:06
zygapstolowski: in addition https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR45 may need to be dropped12:07
zygaand instead the name collection may have to move earlier12:07
mupPR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>12:07
zygapstolowski: so that the same if one {  } else if zero else { } flow can remain12:07
pstolowskizyga: ha, thanks for spotting12:09
pstolowskiok, i think i got it simplified, running the tests.. short break, going to collect my usb hub from post office12:17
zygapstolowski: cool, good luck!12:17
zygamborzecki: can you look at https://github.com/snapcore/snapd/pull/7825 again12:22
mupPR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>12:22
zygamborzecki: I'll find those tests I wrote for some of the TODOs there12:22
mborzeckiok12:22
zygamborzecki: but I did some structural changes you asked for12:22
=== pedronis_ is now known as pedronis
pedronismvo: #7823 looks fine afaict12:58
mupPR #7823: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7823>12:58
pstolowskizyga: is label="snap.core." same as label="snap.core.*" ?13:38
zygapstolowski: no, it is not13:38
pstolowskizyga: is "snap.core." matching anything?13:40
zygaonly the label "snap.core."13:41
zygawhich nothing in our system will have13:41
pstolowskizyga: good13:43
pstolowskizyga: one more twist in that PR13:43
pstolowski(not pushed yet)13:43
mupPR 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
jdstrandpedronis: hey, amurray asked you to respond to https://forum.snapcraft.io/t/system-files-under-mozilla-native-messaging-hosts14:20
jdstrandpedronis: but per our conversation in Vancouver, I will14:21
pedronisjdstrand: thx14:22
pedronisjdstrand: #7768 needs a unit test fix14:23
mupPR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>14:23
jdstrandpedronis: yep, hoping to get to that today. thanks14:24
pedroniszyga: jdstrand asked you to (re)review #722814:24
zygaack, will do14:24
mupPR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>14:24
mborzeckicmatsuoka: you broke github ;) just got an email with '@cmatsuoka pushed 0 commits.'14:29
roadmrhmm... push --overwrite with an unchanged branch?14:31
roadmrer --force (sorry, too much bzr)14:31
pedronispstolowski: let me know if we should have a chat about services tomorrow or later in the week14:31
cmatsuokaI'm pushing 0 commits all the time14:31
zygabrb, lunch14:31
cmatsuokaBut yeah, I don't know what happened there, I'll check14:32
mupPR snapd#7831 opened: [RFC] gadget: extract and export new DiskFromPartition() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/7831>14:32
pstolowskipedronis: ok, thanks, will think a bit more and maybe tomorrow14:33
mupPR 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
pedronismvo: what's the relation of 7831 and 7832, does one need the other or are they exclusive?14:53
mvopedronis: I think we want something like 7831 in any case, i.e. have just a single way to find a parent-disk from a partition14:54
pedronisok14:54
mvopedronis: with 7832 it goes one step further and move the business of finding that disk from devicemanager into the low-level of snap-boostrrap14:55
mvopedronis: 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 question14:56
mborzeckicmatsuoka: mvo: for uc20, is the ubuntu-seed partition encrypted?15:01
pedronismborzecki: no15:03
pedronisonly -data and -save will be15:04
mborzeckipedronis: thx15:06
mupPR snapcraft#2817 closed: snapcraft/plugins: Add gomod plugin <Created by mhilton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2817>15:07
mupPR 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
ijohnsondegville: when you get a chance could you quick take a look at ^15:18
ijohnsonalso 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 have15:19
degvilleijohnson: will do - thank you!15:19
cachiomborzecki, hey, when you have few minutes could you please give a second round to #782615:24
mupPR #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 lunch15:25
pedronismvo: the approach in #7832 looks reasonable15:34
mupPR #7832: [RFC] snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>15:34
mvopedronis: \o/15:34
mvopedronis: thanks for the feedback15:34
pedronisChipaca: #7771 will need a re-review15:35
mupPR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>15:35
pedronisbut I asked for some changes15:35
Chipacayep yep15:35
pedronisstill15:35
Chipacathis thing might be interesting for a few of us: http://www.brendangregg.com/blog/2019-12-02/bpf-a-new-type-of-software.html15:35
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Son_Goku
zygaback from lunch16:07
zygabut need to take a break now16:07
zygaback in 2 hours to wrap up the day16:07
zygaChipaca: I looked at that16:07
zygaChipaca: it's really true in many ways16:07
zygachanges what needs to be done as a kernel patch16:08
* Chipaca afk16:54
mupPR 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
zygare17:49
* zyga was sleeping 17:49
zygaback to work17:49
zygawith some tea to help17:49
=== heather is now known as hellsworth
* Chipaca soft-EODs 17:54
cmatsuokasignal(SIGEOD, SIG_IGN)17:55
=== ijohnson is now known as ijohnson|lunch
* Chipaca feels ignored, now18:26
* Chipaca might get used to this18:27
=== ijohnson|lunch is now known as ijohnson
* zyga hugs Chipaca 19:10
zygaI just discovered mold behind a whiteboard19:10
zyga"yay"19:11
mupPR snapcraft#2829 opened: store cli: push title and license on push-metadata <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2829>19:14
jdstrandnoise][: hey, who would I talk to these days about the snap-store-proxy?20:02
jdstrandnoise][: I see bloodearnest uploaded it last20:04
jdstrandbloodearnest: 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
roadmrjdstrand: we just haven't built for other arches because who would want to host a store-proxy on a raspberry pi :)20:12
roadmrjdstrand: (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
jdstrandroadmr: 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 do20: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 again20:16
roadmrjdstrand: well it does need a postgres database20:16
jdstrandroadmr: 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, etc20:16
jdstrandroadmr: it is already installed :)20:16
roadmrjdstrand: 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
jdstrandroadmr: snap install postgresql1020:17
roadmr\o/20:17
jdstrandroadmr: it is literally begging to be used right now :)20:17
roadmrhehe20:17
* cachio afk20:17
jdstrandI guess I am begging for it to be used too...20:17
jdstrand:)20:17
jdstrandroadmr: 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
jdstrandanyhoo, curious on the outcome of that20:22
roadmrjdstrand: I'll check with twom and bloodearnest tomorrow to see what the reason was20:22
jdstrandroadmr: thanks!20:23
mupPR 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
bloodearnestjdstrand: 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
bloodearnesteverything else is python and archive packages20:28
jdstrandbloodearnest: 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 setgroups21:00
jdstrandbloodearnest: as documented in https://forum.snapcraft.io/t/system-usernames/1338621:01
jdstrandbloodearnest: so, if this is something that you're interested in, you have a tester and a user :)21:01
bloodearnestjdstrand: thanks. I don't have an armhf device handy, but I'll add a trello card for it21:02
jdstrandbloodearnest: 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 to21:03
jdstrandbloodearnest: I think that is what the maas snap is doing (though I'm not sure)21:03
jdstrandbloodearnest: anyhoo, thanks!21:03
bloodearnestjdstrand: 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
bloodearnestUnless running as non-uid-zero users in a service are now a thing, and I missed that?21:05
jdstrandbloodearnest: it is now a thing: https://forum.snapcraft.io/t/system-usernames/1338621:05
bloodearnestjdstrand: well, hello there, that is nice. Ok, we might add that now :)21:06
jdstrandbloodearnest: you don't have the nicety of User=/Group= in the systemd unit yet, but you can solve that with a wrapper21:06
bloodearnestjdstrand: so the wrapper needs to su?21:07
jdstrandbloodearnest: 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
bloodearnestjdstrand: 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
bloodearnestI'll add some bugs to track these I think.21:09
jdstrandbloodearnest: I was thinking a C wrapper. su is allowed in the policy currently. runuser might work. let me try real quick21:10
bloodearnestwe already wrap our servcies in a bash exec launcher, for various reasons, so su would be simpler21:11
jdstrandbloodearnest: setgroups still needs to use '0, NULL' as mentioned in the forum, but setgid and setuid and the whole family (setreuid, setresuid, etc) all work21:11
jdstranderr, su isn't* allowed in the policy currently. that won't work come to think of it cause of pam21:11
bloodearnestah, yeah21:12
bloodearnesthmm21:12
jdstrandbut let me try something with runuser21:12
* jdstrand plays for a minute21:12
jdstrandbloodearnest: 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
jdstrandbloodearnest: 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 there21:44
bloodearnestjdstrand: thanks. That is more complex than I'd like - is User=/Group= support in systemd unit file on the roadmap?21:45
jdstrandbloodearnest: 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 branch21:45
bloodearnestjdstrand: right, we're just using the LD_PRELOAD for nginx, we run about 6 python services and a golang one too.21:47
jdstrandbloodearnest: isn't on the 'committed to do it for 20.04' roadmap, but it is queued in trello for whenever I can squeeze it in21:47
bloodearnestjdstrand: ack, thanks21:47
jdstrandbloodearnest: since you are doing it for nginx, you could set 'environment' in the snapcraft.yaml for anything that uses initgroups21:48
jdstrandI could write a 'runas' binary in that tree21:49
ijohnsonbloodearnest, I made a postgres snap with snap_daemon21:49
jdstrandijohnson: what did you do to drop?21:50
jdstrandijohnson: and what is the name of that snap? I'd like to use yours instead of the one I have21:50
jdstrand:)21:50
ijohnsonbloodearnest: jdstrand: https://github.com/anonymouse64/postgres-snap21:50
bloodearnest jdstrand: re environment in snapcraft.yaml, can they now expand $SNAP{_DATA,_COMMON} and such in their value?21:50
ijohnsonI used https://github.com/tianon/gosu.git to drop privileges21:50
ijohnsonjdstrand: ^21:50
bloodearnestijohnson: oh, nice, will take a look21:51
ijohnsonjdstrand: 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 upstream21:51
ijohnsonbloodearnest: 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 user21:52
jdstrandoh, setpriv21:52
* jdstrand looks at that21:52
ijohnsona full example of using postgres as a service with something else that actually uses postgres is my kong snap: https://github.com/anonymouse64/kong-snap21:53
bloodearnestijohnson: this is all useful info, looks like you've solved some tough problems there, which we can reuse - thanks!21:54
ijohnsonbloodearnest: happy to see my work used :-)21:54
bloodearnestijohnson:  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
ijohnsonbloodearnest: 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 data21:58
ijohnsonif 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 safely21:59
* ijohnson steps out for a minute21:59
jdstrandbloodearnest: 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 30022:01
bloodearnestijohnson: 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
bloodearnestjdstrand: oh, that's much nicer22:01
jdstrandbloodearnest: --clear-groups uses setgroups in the portable manner, not the snapd required manner, hence the preload22:02
jdstrandbloodearnest: you can use --keep-groups and forego the preload, but, well, you have 0 in your list22:02
* jdstrand documents setpriv in the forum22:03
jdstrandbloodearnest: ok, maybe between snap_daemon I did last cycle and the exploration, that is enough to consider the armhf build ;)22:05
jdstrandbloodearnest: 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 cycle22:05
ijohnsonjdstrand: any thoughts on putting that wraplib.so inside snapcraft-preload?22:07
bloodearnestsjdstrand: 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
bloodearnestjdstrand: I'll try see if we can schedule this,  but snap-proxy work is fairly low in the the list for next cycle22:07
jdstrandbloodearnest: sure, I understand22:08
jdstrandijohnson: have had thoughts on that22:08
jdstrand:)22:08
jdstrandijohnson: https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/snapcraft.yaml does show how to do this rather easily as well22: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
bloodearnestjdstrand: FYI https://bugs.launchpad.net/snapstore-snap/+bug/1855005, https://bugs.launchpad.net/snapstore-snap/+bug/1855007, https://bugs.launchpad.net/snapstore-snap/+bug/185500822:19
ijohnsonjdstrand: 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 build22:37
jdstrandbloodearnest: thanks!22:40
jdstrandijohnson: yeah. I think serguisens mentioned he was going to make it easier to contribute to22:41
jdstrand(snapcraft-preload)22:41
ijohnsongreat, that would be cool :-)22:53
jdstrandijohnson: oh, I meant to say, really nice caching forum topic23:13

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