=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:25] PR snapd#3344 closed: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env [06:26] mvo: thanks! [06:27] morphis: thank you, that was a really useful fix! [06:27] :-) [06:28] morphis: want a hand with 3307? I can apply the simplifications if you want, otherwise the branch looks good so I'm keen to get it in soon(ish) [06:29] mvo: ah you approved it, was waiting for another review to get this further before I rework this [06:29] mvo: let me do that now [06:29] ta [06:31] mvo: pushed [06:32] mvo: while we're on it, what are we doing now with https://github.com/snapcore/snapd/pull/3308 [06:32] PR snapd#3308: tests/lib: introduce pkgdb helper library [06:32] mvo: I will work on getting it through the tests today but would like to have a final agreement on how we implement this [06:34] good morning [06:36] morphis: looking again [06:36] zyga: morning! [06:37] zyga: I would like to get to an agreement for https://github.com/snapcore/snapd/pull/3308 [06:37] PR snapd#3308: tests/lib: introduce pkgdb helper library [06:38] zyga, mvo: maybe we can quickly discuss anything left here [06:41] morphis: sounds good [06:42] morphis: I think I made my statement, I will respect whatever mvo decides [06:42] and if it doesn't work down the line (whatever we choose), it's just a commit away to change :) [06:42] true :-) [06:42] PR snapd#3346 opened: [WIP] allow access to nm-dispatcher scripts [06:47] zyga: I added another comment, but I agree, I think we just move forward we can always revisit the decision [06:48] ok, let's merge it then [06:49] mvo, zyga: thanks! [06:49] anymore real code-review comments? [06:51] morphis: I just had a look but I think that's all for now [06:51] zyga: ok, then let me see that tests are passing [06:59] mvo, zyga: https://github.com/snapcore/snapd/pull/3337 can have another review too [06:59] PR snapd#3337: errtracker: try multiple paths to read machine-id [07:16] zyga, hi, what is this system-shutdown command for? when is it used? [07:16] abeato: it used internally to ensure everything can be unmounted on shutdown [07:16] abeato: it's used on shutdown of a core system, it exists because systemd cannot by itself untagle the mount situation [07:17] zyga: snap :) [07:17] :D [07:17] zyga, hmm, so it is called by the shutdown/reboot command? [07:18] abeato: not really, it is called by systemd from initrd on shutdown [07:18] abeato: why? [07:19] zyga, I need to do some changes to how we reboot on core/kernel updates. I need to add an argumento to the reboot syscall so nex reboot goes to the recovery partition [07:19] so I¡m trying to understand how the reboot process works [07:20] abeato: aha [07:20] zyga, for instance "reboot -f recovery" does the desired thing, but "shutdown +10 recovery" does not [07:20] abeato: well, I think this is useful [07:21] abeato: well the reboot command above is special as "recovery" is not a term normally parsed [07:22] zyga, it is passed directly to the kernel: https://linux.die.net/man/2/reboot [07:22] abeato: but the good thing is that you can patch system-shutdown to reboot the way you need [07:22] zyga, yep, seems like a feasible hack [07:22] abeato: I know the man page, 'recovery' is not there [07:22] abeato: my point is that the command you quoted is custom [07:22] zyga, that is why I say it goes straight to the kernek [07:23] abeato: right [07:23] yep [07:23] abeato: so if you can express the desired reboot semantics via the system call you can do what you want [07:23] abeato: but note that you cannot pass any argument to system-shutdown [07:25] zyga, so how does it worl when I run "reboot"? first systemd, then initrd is mounted again and then system-shutdown is called? don't really know the details [07:27] abeato: I don't know for certain (read systemd code to know); I believe what happens is that when a special systemd unit is present (we make one) systemd ensures that shutdown is terminated from initrd using this executable [07:28] zyga, ok, I will pull the thread from there, thanks! [07:29] quote of the day for me: [07:29] from LWN [07:29] "and thus Torvalds is not sure if it a mount point can be tested if it is a bind mount or not" [07:29] jdstrand: ^^ :DD [07:29] * zyga has +1000 karma [07:32] zyga, the call to shutdown when there is a core/kernel update happens in daemon.go:Start(), is that right? [07:34] abeato: atm yes [07:34] ok [07:35] I mean, the code is there, it doesn't happen there, that code is setting a callback [07:36] pedronis, yes yes :) [07:37] how hard would it be to have snaps installable as a non-root user, ie: a I could install a snap (without sudo) for myself? [07:45] icey: for yourself, not planned [07:45] icey: without sudo, just "sudo snap login" once ;) [07:45] icey: but the per-user install case is not anywhere on the roadmap [07:45] zyga: I mean that I wish I could fo per-user snaps :-P [07:45] it would be fairly involved [07:45] even into something like $HOME/snap [07:45] would be awesome :) [07:46] add additional user level restrictions on top of the snap security model [07:46] icey: I agree with pedronis, it's not anything trivial [07:46] icey: on many many levels [07:46] mvo: hi, did you see my question in snapd#2592 ... do we need to skip creating /snap/foo links for those ? [07:46] PR snapd#2592: many: add support for session dbus services via snaps [07:47] I get that it's not trivial, but it would be *awesome* [07:47] so, wishlist ;) [07:47] pstolowski: hi, you haven't created that topic in the forum yet about interface hooks , right? [07:47] icey: well, it needs to fit design; right now it's not part of the design, even as a whislist item [07:48] icey: I would recommend to open a forum thread to describe it [07:48] icey: how you envision it might work, including services, confinement and what not [07:48] pedronis, that's right but I didn't forget about it, I'll do today [07:48] zyga: I'll do some thinking about it and post something, I don't really think it'd work with services unless systemd supports per-user services [07:49] rather, services owned by a specific user [07:49] icey: it does but it doesn't mean something can run as that user [07:49] icey: e.g. an "apache" snap [07:49] icey: it's a different beast entirely [07:50] zyga: right, services would be tough to model, which is why I want to think about it some more; I'm considering more from a tool perspective [07:50] icey: and there's ongoing for for user services but only as a part for "regular" snaps [07:50] icey: for tools it might be doable, just not sure why interesting [07:50] zyga: consider a user downloading something like nginx, and running it (on no priv port) as their own user [07:50] could be nice to use a snap instead of just running `nginx -{}` [07:51] icey: it feels like a rat's nest of issues [07:51] zyga: there are a lot of wishlist snaps that are just tools, inkscape, picasa, etc [07:51] icey: would all snaps work well this way? [07:51] icey: do you want them to run as yoursel? [07:51] and it would be very interesting to be to be able to install those without root [07:51] icey: you *can* install *anything* without root [07:51] icey: if you sudo snap login first [07:51] icey: that tells us you managed to be root once [07:52] icey: is the no-root thing some special requirement? [07:52] icey: e.g. on a machine you don't have root on otherwise? [07:52] there's a snap that managed to break apt a bit ago, no idea if it still does since I have removed it, but it would have been unable to if instaleld without root ;-) [07:53] icey: that was classic-confinement snap [07:53] the `snap install $SNAPNAME` for that snap messed around with the global system in unfortunate ways [07:53] icey: so it can do anything [07:53] zyga: now imagine if it didn't have root on install ;) [07:53] icey: and that snap would not work at all then [07:53] icey: "--classic" [07:53] well that snap managed to break because it needed lots of privileges in the first place [07:53] icey: you want impossible things [07:53] it would not have worked anyway [07:53] and it was bad that it made a mess of apt [07:54] pedronis: I'm curious about that, I kind of want to isntall it into a virtualenv and see if it still works ;-) [07:54] pedronis: yeah, made me sad because I like that tool, haven't had it on my computer since then [07:54] icey: virtualenv? what has that to do with anything? [07:54] fortunately, I haven't needed it [07:54] the tool is written in python [07:54] icey: anything that installs with --classic is just like a typical deb/rpm, it has full access to everything on the system [07:54] so I want to actually try using it from source, to see what these functions it "needs" are :) [07:54] agree zyga [07:57] icey: I really encourage you to think about how it should work, it might be possible to create a per-user install of certain kinds of snaps (pure apps, no services), but there are lots of quirks to figure out first [07:57] icey: a forum thread is a way to explore that [07:57] zyga: certainly, I bet that classic snaps could work too, but services would be really hard (and probably not worth it?) [07:57] icey: maybe with the session snapd deamon it might be doable but still many hard things there [07:58] icey: (e.g. imagine encrypted $HOME) [07:58] zyga: yeah, it'd have to be something that was entirely after $USER was logged in fully, I think that services for a user level snap would be not worth it [07:58] but being able to `snap install inkscape` without having root would be cool :) [07:59] pedronis: checking that question now [08:01] pedronis: is the question if wrappers.IsService need to take into account if its a dbus activatable service? [08:03] mvo: yes, which means though that we would not create /snap/svc for those [08:05] pedronis: no /snap/bin/svc ? not doing those is actually desirable [08:05] yes [08:05] sorry [08:05] no /snap/bin/svc [08:06] pedronis: slightly interessting how to organize the code so that we know in wrappers.IsService() if it is a dbus activated service [08:07] icey: well, you only need root once [08:07] (good morning peeps!) [08:07] icey: 'sudo snap login', and then you don't need sudo to snap install stuff [08:07] Chipaca: but snaps installed thereafter would have root access during install yeah? [08:07] yep [08:08] Chipaca: my wish would be to have non-root snaps as well [08:08] hey Chipaca, good morning [08:08] icey: ah [08:08] icey: to the forum! :-) [08:08] Chipaca: I'll thinkabout it and put something on the forum once I've thought it through a bit more :) [08:08] mvo: how's things? [08:08] icey: fair [08:08] Chipaca: good, thank you. how are you? [08:08] mvo: not bad [08:08] i opened my big mouth and promised a patch for go, it seems :-) but that's not necessarily *bad* [08:09] (in https://github.com/golang/go/issues/19546) [08:10] Chipaca: \o/ [08:12] I hadn't noticed IsService [08:12] why is it not a method of AppInfo? [08:13] Chipaca: a good question. it is pretty recent [08:14] Chipaca: so yeah, we should have a look at moving it [08:14] I can do it as part of this service and wrappers shuffle i'm doing [08:14] in fact I can piggy back it into snapd#3342; nobody's reviewed that yet :-) [08:14] PR snapd#3342: many: refactor in preparation for 'snap start' [08:16] Chipaca: because it's not clear snap should have opinions on that, indeed with dbus service the logic gets quite complicated for being in snap [08:17] pedronis: how so? [08:17] Chipaca: have you looked at the dbus activation branch? [08:17] anyway [08:17] pedronis: yeah, I'm actually not super happy about the complexity we have there currently already [08:18] pedronis: snapd#2592? [08:18] PR snapd#2592: many: add support for session dbus services via snaps [08:18] Chipaca: also Services would need to be something else, because now we have services that are not dbus services [08:18] I mean your new method [08:18] pedronis: and I much agree about snaps opinion about dbus etc [08:18] * mvo scratches head [08:18] Chipaca: you should probably look at it [08:19] so, if we need to call them daemons instead of services, fine [08:19] because it has influence at on names of stuff and where wrappers.IsService should go [08:19] Chipaca: unrelatedly, a 2nd review for snapd#3322 would be appreciated :) [08:19] PR snapd#3322: overlord: make config defaults from gadget work also at first boot [08:19] but so far "services" are things that systemd starts [08:20] Chipaca: now we have dbus activated "services", like classic classic classic [08:20] as you see from {Add,Remove,Start,Stop}SnapServices [08:20] and start-snap-services [08:20] etc [08:21] Chipaca: I'm happy not to care, and let you and mvo figure it out ;) [08:22] Chipaca: what pedronis said is true, there is the potential to have dbus services (user session) now and systemd unit that are dbus activated (soon) [08:22] pedronis: hehe [08:23] Chipaca: but maybe for your branch yu can mostly ignore it, the only thing I will need is some way to figure out that its a dbus service so that I don't write a /snap/bin/foo-dbus-activated file that is useless to the user [08:23] mvo: as things stand there's a lot of places where we use "service" to mean something that has a systemd unit [08:23] Chipaca: indeed, so maybe a new term? dubsActivated or somesuch [08:24] having a systemd unit that is dbus-activated instead of socket-activated or type=notify is just a variant, it's the same thing [08:24] but having a service that does not have a unit associated would be strange [08:24] Chipaca: right, the user session will not have a unit [08:24] we *could* split it int SystemdService and DbusService [08:24] OTOH... are you sure the user session will not have a unit? [08:24] Chipaca: I mean, we could implement it via systemd but 16.04 has no systemd user session so things will fall apart there [08:25] i mean, do we support user services on things that don't use systemd for the user session? [08:25] Chipaca: dbus activation works fine without systemd user sessions, its an older concept [08:25] i know [08:25] upstart alos works fine [08:25] the question is whether we want to support it :-) [08:26] Chipaca: heh :) fair enough. if we don't we exclude 14.04 and 16.04 and possilbly 16.10 (have not checked this one) [08:27] Chipaca: or maybe we need to spawn our own systemd user session with snapd [08:27] Chipaca: no idea if that is feasible but if it is it might be nice way out [08:27] mvo: anyway, backpedaling from the "do we want to do this" question, _if_ we do this, we should split service in two [08:27] * mvo nods [08:27] or call them daemons vs servcies [08:27] or daemons and sprites, and confuse everybody [08:27] * Chipaca grins evily [08:28] Chipaca: sounds resonable, I will look into it in a little bit [08:29] mvo: I haven't looked at your branch in detail; is there any place where you need to grab all services, both dbus and systemd? [08:30] looks like you implement a separate isDbusService, and use that [08:31] Chipaca: yeah, I think that will be sufficient for now [08:31] mvo: also you don't do things from start-snap-service and related tasks [08:31] afaict [08:33] so, for now, i'm leaving Services in snap, and moving IsService in there [08:33] and afaict (but tell me if i'm wrong), at most we'll be renaming them to SystemdServices/IsSystemdService, not making them more complex [08:33] (or to Daemons/IsDaemon) [08:33] (or Vegetable/IsVegetable) [08:34] (or ..) [08:34] Chipaca: well, no, we need IsService to return true for the things mvo is working on, that's the matter [08:35] pedronis: those things don't have daemon set [08:35] Chipaca: indeed [08:36] pedronis: and dbus-activated systemd services are services in the current sense [08:36] but we don't want to create /snap/bin/foo for them [08:36] at the moment IsService decides whether the thing should have a /snap/bin entry [08:36] pedronis: right, so the current code in binaries would change from IsService to IsService || IsDbusService (or whatever) [08:36] (and consequently whether to support aliases) [08:36] pedronis: but what I'm wanting is to drop all the _other_ app.Daemon == "" [08:36] Chipaca: there are usages in snapstate too [08:37] in aliasesv2 [08:37] yup [08:37] yes [08:37] it would be saner if they didn't all have to call two helpers [08:37] but that's my 2cts [08:38] we could add wrappers.IsBinary maybe? [08:38] pedronis: so maybe as part of the dbus branch we IsService -> IsSystemdService, have IsDbusService, and have IsService that ||s the two [08:38] mvo: yea, maybe that [08:38] mvo: that would be confusing, at least to me, because I'd expect IsBinary to be !IsService, always [08:39] bah [08:39] hmm [08:39] Chipaca: it would be [08:39] if I understand things [08:39] pedronis: if IsService is the || above, yes [08:40] mvo: why would it be wrappers.IsBinary and not snap.(*AppInfo).IsBinary? [08:41] because the logic for IsDbusService is complicated [08:41] rharper: ping [08:41] and about policies that are 5 layers away from the basics of snaps [08:42] but you can read it both ways [08:42] Chipaca: yeah, what pedronis said, probably in wrapper as its complex(ish) [08:42] I mean the issue is mostly not to have that logic in many places [08:42] +1 on that [08:43] agreed that that's #1 [08:43] Chipaca: completion timeout that doesn't seem related to create-key: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170518_083559_ce30f@/log.gz [08:43] OTOH that you can't tell whether an app is a dbus service from looking at the app, to me is a red flag [08:44] or at least a bright yellow flag :-) [08:44] pedronis: not only, no [08:44] waaait [08:45] that's a different completion [08:45] Chipaca: we could make it more explicit. right now its entirely based on the dbus slot, however we could add something explicit to the app yaml part [08:45] Chipaca: 2592 has an example of the current syntax, maybe we move the "service: true" part up to the app level (and rename it to something sensible or fold it into daemon:) [08:47] pedronis: that timeout makes no sense :-( [08:47] zyga, hey, I think you are the only one missing in https://github.com/snapcore/snapd/pull/3324 :) [08:47] PR snapd#3324: partition,snap: add support for android boot [08:48] mvo: what would one on the system dbus look like? [08:49] mvo: does it running on the system dbus mean it runs as root? [08:49] Chipaca: that is not decided yet, probably exactly the same excep tthat bus: session becomes bus: system [08:49] Chipaca: correct [08:50] mvo: how is a dbus-activated system dbus service different from a bus-activated systemd service [08:51] the manpage points me to /usr/share/dbus-1/system-services/org.example.simple-dbus-service.service which doesn't exist. Hrmph. [08:51] Chipaca: I have not looked into the details for the system dbus services, but I expect that we want to do the systemd unit route here [08:52] Chipaca: i.e. there may be very little for us to do [08:52] so they'd be quite different in that case? [08:52] or would it still need a plug and etc? [08:52] Chipaca: the user session was the most interessitng one to me as there are some gnome apps that use this mechanism and we can not support them ucrrently [08:53] Chipaca: AIUI there is still a plug needed to ensure appamor allows all the dbus things that the dbus activated service wants to do [08:53] (but take it with a grain of salt, I have not looked into the details for dbus in system services) [08:53] hi, how do I remove a snap that's marked as broken,disabled? [08:55] ackk: snap remove snapname? [08:55] ackk: (how did it get into that state?) [08:55] Chipaca, I had installed locally 2 versions of a snap, when I tried to sudo snap remove it hang for several minutes removing one of the versions [08:56] Chipaca, I C-c'd it and after that it was broken [08:56] Chipaca, fwiw it's a snap installed in an LXD container [08:56] zyga: you want to look at this? [08:57] Chipaca, uhm, it seems it eventually deleted itself, I don't see it anymore now :/ [08:58] ackk: 'snap changes [08:58] agh [08:58] ackk: 'snap changes' should be able to shed light on things [08:58] Chipaca, I see a series of "install" and a "remove" at the end [08:59] ackk: snap tasks [08:59] [08:59] 2017-05-18T08:47:55Z ERROR cannot remove snap file "basic-auth-service", will retry in 3 mins: umount: /snap/basic-auth-service/x1: not mounted [08:59] 2017-05-18T08:50:55Z ERROR cannot remove snap file "basic-auth-service", will retry in 3 mins: umount: /snap/basic-auth-service/x1: not mounted [08:59] Chipaca, ^^ [09:01] ackk: where's that from? (and what did 'snap tasks' say?) [09:01] pedronis: I updated the repair capability with a new "running repairs" proposal based on the ideas from gustavo. feedback welcome [09:02] ackk: ('snap tasks' used to be 'snap change', if your snapd is slightly old try that instead) [09:04] zyga, hey, any objections to expose rm_rf_tmp from ns-supoort-tests to utils-test or similiar? I need to cleanup tmp stuff in my new test [09:04] s/expose/expose and move/ [09:04] mvo: I'm not quite sure why we need --probe ? [09:04] that wasn't part of Gustavo proposals [09:06] mvo: also is not clear, but we still need the the latest good in snapd/gadget, otherwise we will download all assertions since forever [09:06] pedronis: thats fine, I can change it. it felt slightly cleaner to make it explicit but I guess its an unneeded extra step [09:06] mvo: well it begs questions about the state after the real run [09:07] pedronis: ok, let me update it [09:07] for when it's unknown [09:08] basically bigger state machine [09:21] pedronis: updated it yet again [09:24] mvo: fixed the when repair section [09:26] mvo: I think with this approach the every 4h seems reasonable, later we could have some approach that do it as well if snapd is down since a while [09:29] pedronis: great [09:33] pstolowski: no, go ahead [09:33] Chipaca: yes, gladly [09:34] * zyga is back, sorry, some unexpected stuff at home [09:34] ackk: ah, LXD [09:34] ok, I might as well explore LXD, this would fit nicely in my mount namespace layout tests [09:34] abeato: looking [09:34] * zyga refrains from reading the rest of the backlog [09:36] Chipaca, it's from snap tasks [09:40] ackk: could you pastebin the whole output of the relevant 'snap tasks'? [09:40] Chipaca, http://paste.ubuntu.com/24597955/ [09:41] Chipaca, fwiw it was eventually removed correctly [09:41] pedronis, https://forum.snapcraft.io/t/interface-hooks-attributes/673 [09:41] abeato: some things are still not documented (golint) [09:41] a bit nitpick but I think it's relatively easy to do [09:42] zyga, I tried golint, but I got no output [09:42] abeato: in that directory? [09:42] zyga, yes [09:43] $ golint *.go [09:43] androidbootenv_test.go is in package androidbootenv_test, not androidbootenv [09:43] zyga, this is the only output I see *^^ [09:44] zyga, thanks [09:44] abeato: commented again [09:44] abeato: let me look, that's still wrong :) probably [09:45] abeato: but check my feedback [09:45] zyga, sure, thanls [09:46] ogra_: is rsyslog already removed in edge? [09:46] morphis: yes [09:47] mvo: hm, so is the journal sync'ed to disk? [09:47] pstolowski: thanks, it seems to capture the discussion points, I added a comment there [09:48] pedronis, yes, saw it, thanks [09:49] woohoo [09:49] I see core edge :) [09:50] * zyga sees the content interface changes work :D [09:50] I'd say woot but that's be self serving [09:50] still [09:50] very happy :) [09:55] morphis: aiui it is not [09:55] morphis: it is only if the /var/log/journal dir exists or something [09:55] hm [09:56] zyga: what content interface chagne is that? [09:58] zyga, answering your comment, I do not care about deterministic order [09:58] zyga, were the test you proposing about that? If that is the case, it is not needed either [10:01] abeato: yes, I think we want that [10:01] abeato: it's almost always desirable IMO [10:01] zyga, not in this case [10:02] zyga, it is a hurdle we do not really care about [10:04] Hi guys, is it now possibile revoke a gpg key on the Store? [10:06] abeato: can you justify that? [10:09] zyga, neither the bootloader or snapd cares about the orde in which env vars are stored [10:09] so no reason to enorce that [10:10] *enfroce [10:10] enfroce [10:47] heh [10:47] make a file called '<' by accident [10:47] then remove it [10:47] fun :) [10:49] zyga: “rm \<” ? [10:56] Chipaca: yes but it took me a second to find that :) [10:56] Chipaca: this is both you vs shell as well as you vs program parsing it :) [10:56] zyga: the program shouldn't be doing parsing of the filename [10:56] unless it were "-foo" or something [10:56] hmm [10:56] (for which "--" exists) [10:57] building something for snapcore via build.snapcraft.io requires additional organization access :/ [10:57] * ogra_ wonders why ... given my GH account already has readonly access to the branches which should be enough to build it [11:00] Chipaca: yep, I tried with -- but that was just my naive idea ;) [11:05] PR snapd#3347 opened: snap-confine: moved rm_rf_tmp to test-utils [11:06] zyga, ^ something for you ;) [11:07] ogra_: BSI needs admin access to the repo in order to install a webhook [11:07]