[03:50] <Ark74> hello! great night!
[03:52] <Ark74> I've seen that the network-manager package for Xenial is signed using this key:
[03:52] <Ark74> pub   4096R/F0210224A744BE93 2014-06-16 [revocada: 2016-08-16] | uid    Marc Deslauriers <marcdeslauriers@videotron.ca>
[03:53] <Ark74> but that key has being revoked
[03:56] <Ark74> I get: gpgv: Signature made Fri Nov  2 13:52:40 2018 CST using RSA key ID A744BE93
[03:56] <Ark74> gpgv: Can't check signature: public key not found
[03:57] <Ark74> would this count as a bug?
[04:02] <valorie> xenial?
[04:02] <valorie> is that still supported?
[04:02] <Unit193> For 557 more days.
[04:02] <valorie> if so, I would get so
[04:02] <valorie> guess!
[04:21] <Ark74> So, if it is so, I need to fill a bug, right?
[05:44] <valorie> Ark74: easiest way to file a bug report is in the commandline: ubuntu-bug network-manager
[05:45] <valorie> and then just follow the prompts
[05:45] <valorie> you can mark it security because it is
[05:46] <alkisg> Hi, snapd doesn't run in the new ltsp, with "cannot create lock directory /run/snapd/lock: permission denied". I'm thinking it might be related to the writable overlay root that ltsp uses:
[05:46] <alkisg> 29 0 0:25 / / rw,relatime shared:1 - overlay overlay rw,lowerdir=/root,upperdir=/run/initramfs/ltsp/up,workdir=/run/initramfs/ltsp/work
[05:46] <alkisg> That /root there comes from: nfsroot=server:/srv/ltsp/images mounts the images directory, and ltsp then loop-mounts a squashfs.img file inside it, and applies a  tmpfs overlay over it
[05:46] <alkisg> What can I do in the LTSP code to help snapd detect IsRootWritableOverlay() or whatever else it needs?
[07:06] <infinity> alkisg: /run should be a tmpfs, not just a directory on your root overlay.
[08:32] <cjwatson> Ark74: It's not a bug that source packages uploaded years ago were signed with keys that have since expired.  The security model for fetching packages doesn't depend on developer signatures; rather, developer signatures authenticate uploads to the archive, and then the archive is signed (starting with the signature in the InRelease file) and apt trusts that.
[08:33] <cjwatson> Ark74: We aren't in general going to go round reuploading source packages to old releases of Ubuntu just to provide a new developer signature.
[08:35] <cjwatson> (expired or revoked, either way)
[08:54] <alkisg> infinity: /run is a tmpfs created by initramfs-tools; I'm putting my mount in /run/initramfs as systemd has this path hardcoded and doesn't unmount it on shutdown, as it does for other paths
[08:54] <alkisg> It's supposed to be the correct path for initramfs-tools and dracut to mount their file systems, except for root, of course
[08:56] <alkisg> I don't think the /run path is related though, as the previous ltsp also used /run and didn't have issues with snap; but it was using nbd, not loopback over nfs (we changed to that as it's a lot more stable)
[08:58] <alkisg> Ah btw, I believe /run/snapd is using mount namespaces or something else, and it appears with different permissions for each app or each user (I'm not using snap so I don't know the details)
[08:59] <alkisg> And maybe this has some issues with overlayfs, and maybe IsRootWritableOverlay() function is trying to apply some heuristics to work around those issues, and fails to catch the loopback over nfs case...
[15:38] <Ark74> cjwatson, oh, ok.  I need to study more the apt/gpg trust mechanism, thanks for the clarification.
[18:31] <infinity> alkisg: You misunderstood.  I don't mean the run in the initrd that has your mountpoints, I mean the /run in the running system should be a tmpfs mounted at /run :P
[18:32] <infinity> (Not confusing at all)
[18:32] <alkisg> infinity: the initramfs moves /run to the real file system, so  it's the same thing
[18:33] <infinity> alkisg: Well, overlayfs shouldn't be in play at all then?
[18:35] <alkisg> infinity: initramfs mounts proc, sys, dev, run, and root; the script/init-bottom/ltsp code loop-mounts /root/squashfs.img to /run/initramfs/blah, and creates a tmpfs there for up/work etc, and mounts the result with overlayfs in /root
[18:36] <alkisg> Then control goes back to initramfs-tools, which calls pivot_root to /root
[18:36] <alkisg> It's the same thing that casper does for live CDs, except now it comes from nfs
[18:37] <alkisg> I see that snap has code to special-case some overlayfs file systems, so maybe it would need to add ltsp there, but I don't know the logic so I'm not sure
[18:38] <alkisg> That's why I was looking for some guidance, to avoid spending e.g. a week understanding how snap works and why it special-cases overlayfs rootfs...
[18:38] <infinity> alkisg: Right, what I'm saying is that if your /run is a tmpfs pivoted from the initrd, then overlayfs is irrelevant, at least for the error you were talking about.
[18:38] <alkisg> infinity: the problem is /, not /run
[18:38] <alkisg> Hrm
[18:38] <infinity> "/run/snapd/lock: permission denied"?
[18:39] <alkisg> Or maybe you're right, and I'm looking in an unrelated part
[18:39] <alkisg> But then I've no idea why snapd doesn't like ltsp
[18:39] <alkisg> We're not doing anything more than that overlay
[18:40] <alkisg> The permission denied is probably due to mount namespaces
[18:40] <alkisg> But I don't know how these work, how per-user or per-app namespaces are handled
[18:40] <alkisg> And why they break in ltsp :/