| === slashd- is now known as slashd | ||
| === mIk3_09 is now known as mIk3_08 | ||
| cpaelzer_ | didrocks: hi I answered on zsys | 11:54 |
|---|---|---|
| cpaelzer_ | lets discuss and get a group ack here later on by the Team that will hopefully be here | 11:55 |
| cpaelzer_ | didrocks: what do you need from me on the Lintian issues? | 11:55 |
| didrocks | cpaelzer_: hey, thanks! On Lintian, I really can't reproduce, (the end of the text should explain more) do you just run lintian on it? | 12:04 |
| didrocks | I gave an example even with --pendatic on eoan, and no copyright issue | 12:05 |
| cpaelzer_ | hmm, I ran on Bionic didrocks | 12:05 |
| cpaelzer_ | if you have a pedantic more or less happy then I'm fine | 12:05 |
| didrocks | cpaelzer_: more than happy, I have 0 warnings :) | 12:06 |
| cpaelzer_ | ok then | 12:07 |
| didrocks | cpaelzer_: see "I'm not seeing those on an up to date eoan machine" on https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/comments/2 | 12:07 |
| ubottu | Launchpad bug 1839271 in zsys (Ubuntu) "[MIR] zsys" [Undecided,New] | 12:07 |
| didrocks | cpaelzer_: /!\ the comments are really long (longer than launchpad will show inline), you need to download it | 12:08 |
| cpaelzer_ | lol | 12:08 |
| cpaelzer_ | yeah that is why I only have read half of it I gues | 12:08 |
| cpaelzer_ | s | 12:08 |
| didrocks | sorry, you will have even more to read :) (and also tell me if the .service change is fine for you) | 12:08 |
| cpaelzer_ | reading now | 12:09 |
| cpaelzer_ | didrocks: ok what remains before our discussion here later on are two things then | 12:13 |
| cpaelzer_ | a) the simple one - the lack of ducomentation | 12:14 |
| cpaelzer_ | you said that it will not have user-visible features | 12:14 |
| cpaelzer_ | I'm torn on this, can't you somehow easily convert the blogs into a md file or so that could ship as a documentation? | 12:14 |
| cpaelzer_ | or a basic summar with rferences to the blog post series | 12:15 |
| cpaelzer_ | that way the series can grow with more details as the project lives and evolves | 12:15 |
| didrocks | cpaelzer_: what about linking them (or copying) in the upstream github wiki page? | 12:15 |
| cpaelzer_ | didrocks: ^^ ? | 12:15 |
| didrocks | (actually, they are already markdown) | 12:15 |
| didrocks | that way, it's easy to get them evolving over time | 12:15 |
| cpaelzer_ | ack | 12:15 |
| cpaelzer_ | not perfect, but there jsut isn't more we could add right now | 12:15 |
| cpaelzer_ | considering you do this lets get to (b) my complains about the usability in a container | 12:16 |
| didrocks | yeah, I'm currently downloading a lxc (trying to find eoan image) | 12:16 |
| didrocks | and see what can be done | 12:16 |
| didrocks | I wonder though how useful this could be in a container | 12:16 |
| cpaelzer_ | I'm not sure what in the postinst breaks | 12:17 |
| didrocks | but that's your server side talking I think ;) | 12:17 |
| cpaelzer_ | if it is just the service it is trivial | 12:17 |
| didrocks | I think it's starting the systemctl service | 12:17 |
| didrocks | if you don't have the zfs module loaded | 12:17 |
| didrocks | or if you have pre-0.8 | 12:17 |
| cpaelzer_ | let me fetch some examples as suggestion | 12:17 |
| didrocks | the generated postinst only has the systemd stuff | 12:18 |
| didrocks | while the image is downloading, let me check if there is an arg to tell "don't fail if the service can't start" | 12:19 |
| didrocks | I implemented it in debian long ago, don't remember if this was merged or not | 12:19 |
| didrocks | (in dh_systemd) | 12:19 |
| cpaelzer_ | didrocks: ConditionVirtualization=!continer | 12:19 |
| cpaelzer_ | as I'd think it never would make sens in a container right? | 12:20 |
| didrocks | ah, directly in the service, preventing it for starting, that makes sense | 12:20 |
| didrocks | because right now, I don't see a use of zsys in the container, indeed | 12:20 |
| didrocks | and it's too dependant on the host kernel module | 12:20 |
| didrocks | ok, let's go that way, adding it | 12:20 |
| didrocks | thanks for the link :) | 12:20 |
| cpaelzer_ | other commonly used options are ConditionCapability= | 12:20 |
| didrocks | on debian/watch, I guess I'm going to remove it (see the ref on the lintian warning) | 12:21 |
| cpaelzer_ | if you strictly depend on some caps to be able to work | 12:21 |
| cpaelzer_ | e.g. ConditionCapability=CAP_SYS_TIME | 12:21 |
| cpaelzer_ | ok for watch | 12:21 |
| didrocks | let me check man capabilities to see if one fits | 12:21 |
| cpaelzer_ | if you want to go hardcore you can even limit it down to known syscallfilters | 12:23 |
| cpaelzer_ | example | 12:23 |
| cpaelzer_ | SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot @swap | 12:23 |
| cpaelzer_ | didrocks: ^^ | 12:23 |
| cpaelzer_ | not required, but while you are at it this is a great way to really limit exploitability | 12:23 |
| didrocks | cpaelzer_: right, I would go wide at first, and restrict little by little, especially once we have the client/service logic | 12:23 |
| didrocks | there, limiting the prividledged service as much as possible will help | 12:24 |
| didrocks | priviledged* | 12:24 |
| cpaelzer_ | yep | 12:24 |
| cpaelzer_ | since everything new is in the focus having it a bit more encapsulated can't hurt | 12:24 |
| didrocks | maybe, let's go with !container at first, and once we are closer to 1.0 with the new model, the second security review, go that way | 12:24 |
| didrocks | yes | 12:24 |
| cpaelzer_ | didrocks: I think we are fine waiting for you to bring it up with the group later then | 12:25 |
| didrocks | sure! | 12:25 |
| didrocks | thanks again for the review cpaelzer_ :) | 12:25 |
| cpaelzer_ | I only want to help, not being a pedantic roadblock | 12:26 |
| cpaelzer_ | although sometimes for MIR reviews that is just what we have to be :-) | 12:26 |
| didrocks | heh, ofc | 12:27 |
| didrocks | cpaelzer_: interesting, so the postinst doesn't fail in the container, you meant it did? the postinst has || true. | 12:48 |
| didrocks | you have the following message though, as the service can't start: | 12:48 |
| didrocks | Job for zsys-commit.service failed because the control process exited with error code. | 12:48 |
| didrocks | See "systemctl status zsys-commit.service" and "journalctl -xe" for details. | 12:48 |
| didrocks | (but RC is 0, and the dpkg transaction isn't broken) | 12:48 |
| didrocks | however, in lxc, "ConditionVirtualization=!container" doesn't work, I'll try on dock | 12:49 |
| didrocks | docker* | 12:49 |
| didrocks | cpaelzer_: FYI, the condition works on docker (not started), so it's still a plus. | 12:53 |
| cpaelzer_ | hmm | 12:56 |
| cpaelzer_ | it should work on lxd | 12:56 |
| cpaelzer_ | is is the same as systemd-detect-virt | 12:57 |
| didrocks | systemd-detect-virt | 12:58 |
| didrocks | lxc | 12:58 |
| didrocks | so, not "container" | 12:58 |
| didrocks | let me launch it on docker | 12:58 |
| cpaelzer_ | no there is a --container or so | 12:58 |
| cpaelzer_ | which summarizes all the containers into one check | 12:58 |
| didrocks | --container (which seems to be what it is, indeed), returns "lxc" as well | 12:59 |
| didrocks | it does return "docker" anyway, even with --container in docker | 12:59 |
| cpaelzer_ | didrocks: it returns true | 13:00 |
| cpaelzer_ | that is the point | 13:00 |
| cpaelzer_ | systemd-detect-virt --container | 13:00 |
| cpaelzer_ | it returns the "type" e.g. lxc | 13:01 |
| cpaelzer_ | print = type | 13:01 |
| cpaelzer_ | RC = 1/0 depending on what it is | 13:01 |
| didrocks | ah, so, it's only the exit code, let me check | 13:01 |
| cpaelzer_ | yep | 13:01 |
| cpaelzer_ | systemd-detect-virt --container is RC=0 in containers | 13:01 |
| cpaelzer_ | and 1 everywhere else | 13:01 |
| cpaelzer_ | and that is what the check in the .service is based on | 13:01 |
| didrocks | yep, wondering why it started on lxc then, let me recheck | 13:02 |
| didrocks | still the same, hum | 13:02 |
| didrocks | and definitively working on docker | 13:02 |
| didrocks | (working as "not starting") | 13:02 |
| didrocks | ah, my fault I guess, one min | 13:03 |
| didrocks | ok good now :) | 13:04 |
| cyphermox | hrm | 13:05 |
| didrocks | should we start the meeting? | 13:05 |
| cpaelzer_ | lets ping the rest | 13:05 |
| cpaelzer_ | cyphermox: is already here | 13:05 |
| cpaelzer_ | doko: jamespage: jdstrand: ping for MIR meeting | 13:05 |
| cpaelzer_ | didrocks: it seems it is just cyphermox me and you | 13:16 |
| didrocks | hum, should we still discuss zsys if doko/jamespage/jdstrand are away? | 13:16 |
| didrocks | yep :) | 13:16 |
| cpaelzer_ | yeah, you need a way to go on | 13:16 |
| cpaelzer_ | and cyphermox is a MIR-pro :-) | 13:16 |
| cyphermox | huh? | 13:16 |
| didrocks | so, for cyphermox, the background is that zsys (a zfs userspace handler that the desktop team is writting) is an experimental feature announced for eoan | 13:17 |
| cpaelzer_ | cyphermox: we were wondering about the MIR on zsys | 13:17 |
| cpaelzer_ | didrocks: will explain | 13:17 |
| didrocks | current version is 0.1 | 13:17 |
| didrocks | it's a go binary (not user-visible, only doing some background work) | 13:17 |
| didrocks | as for ubuntu-report, snapd, juju, it vendors the deps | 13:17 |
| didrocks | for some context, on ubuntu-report, I tried to avoid vendoring | 13:18 |
| cyphermox | yeah. as long as security is okay with the vendored deps... but I thought we were supposed to crack down on that | 13:18 |
| didrocks | which was then reverted to "let's vendor, easier and better for our use-case" | 13:18 |
| cyphermox | I mean, it's definitely not great, but it also looks kinda unavoidable in some cases | 13:18 |
| didrocks | I guess the vendor vs not vendor should be dealt at distro level, but for all binaries vendoring (including snapd, juju, …) | 13:18 |
| didrocks | maybe a goal for a cycle? | 13:19 |
| didrocks | (unsure if LTS cycle would be the best though) | 13:19 |
| cyphermox | maybe | 13:19 |
| didrocks | maybe it will be the time to ask about go module & proxy handling | 13:19 |
| cyphermox | is zsys in the archive now? | 13:19 |
| didrocks | yes | 13:19 |
| didrocks | (universe) | 13:19 |
| cyphermox | well.. the issue is also that go transitions are terrible | 13:19 |
| cyphermox | so ifg you need new deps on a released distro it's teh worst. | 13:19 |
| didrocks | ah, in that sense, well, same than with any other language, if you need a newer version of a lib (or go itself…) | 13:20 |
| cyphermox | okay, so I guess archive admins already complained about zsys vendoring deps, and we're all good on that side? | 13:20 |
| didrocks | didn't complain because we went that road on ubuntu-report (without vendoring, and then, had to go back on vendoring), so they were aware | 13:20 |
| cyphermox | ah ok | 13:21 |
| didrocks | (they == seb FTR) | 13:21 |
| cyphermox | well, as long as the security team is aware, because that imposes some burden on them because of the vendored dependency | 13:21 |
| didrocks | yes, anyway, we are pending on the security review | 13:21 |
| cyphermox | ok | 13:21 |
| cyphermox | well I don't see any issue with the MIR otherwise | 13:22 |
| cpaelzer_ | all that cyphermox is the same I already said(glad about that) - I think the critical point here is the very early 0.1 | 13:22 |
| cpaelzer_ | I mena we don't re-evaluate SW anyway | 13:22 |
| cyphermox | no, but it's written by Canonical | 13:22 |
| cpaelzer_ | so when we ack on v5 of something we silently assume v7 will still be fine | 13:22 |
| didrocks | which is a bigger issue IMHO, I have seen some stuff being MIRed being very different some months/years after | 13:22 |
| didrocks | (starting with unity for instance) | 13:23 |
| cpaelzer_ | cyphermox: yeah that here canonical is the upstream was my argument as well why it might be ok | 13:23 |
| cyphermox | things generally don't regress over time to get less MIR-worthy | 13:23 |
| didrocks | and as said, I'm more on the safe side: once we migrate to the service/client model, I will require a security background check to ensure I didn't open any hole | 13:23 |
| cpaelzer_ | ok, it seems we are fine with your 0.1 then didrocks - under the constraint that security is ok with is as well | 13:23 |
| * didrocks doesn't like things running as root and won't declare himself an expert :) | 13:23 | |
| cyphermox | you MIR the software that makes sense to have in main, that we really need, etc. as long as the quality is acceptable and we can reasonably expect the software not to become trash because we "trust" the maintainers | 13:24 |
| didrocks | indeed | 13:24 |
| === cpaelzer_ is now known as cpaelzer | ||
| cyphermox | well, I don't like it much either... does it really need to run as root? | 13:24 |
| didrocks | cyphermox: it needs to interacts with zfs module kernel | 13:24 |
| cyphermox | ok | 13:24 |
| cyphermox | it's some kind of fuse driver? | 13:25 |
| didrocks | right now, for some of the action, only root is allowed | 13:25 |
| didrocks | no, it's tagging/handling/snapshoting zfs datasets | 13:25 |
| didrocks | snapshotting* | 13:25 |
| cyphermox | ok | 13:25 |
| cpaelzer | didrocks: take a not on the syscall filters and such - that will help you to be a rather safe root process | 13:25 |
| cpaelzer | but I think after our discussion that already is on your lists somewhere | 13:25 |
| didrocks | cpaelzer: definitively note down | 13:25 |
| cyphermox | well, it wouldn't be the first thing anyway. we have other things that do similar work | 13:25 |
| didrocks | yes | 13:25 |
| cyphermox | udisks? | 13:25 |
| didrocks | right | 13:25 |
| cyphermox | also, probably a pretty good example of something in main with horrendous code ;) | 13:26 |
| didrocks | hoping zsys won't go the same way :) at least, it has a big testsuite :p | 13:26 |
| cyphermox | hehe | 13:26 |
| cyphermox | great | 13:26 |
| didrocks | cpaelzer: do you mind giving the official +1 (pending security ofc) on the bug so that I'm not the one writing it? (don't want to be the requester and acker)? (maybe with some of the reasoning and linking this discussion?) | 13:27 |
| cpaelzer | yes | 13:28 |
| cpaelzer | doing so now ... | 13:28 |
| didrocks | thx cpaelzer & cyphermox :) | 13:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!