[06:35] <mup> PR snapd#12153 opened: boot: add factory-reset cases for boot-flags <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/12153>
[06:35] <mup> PR snapd#12154 opened: overlord: run install-device hook during factory reset <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/12154>
[07:20] <eoli3n> Hey mardy 
[07:20] <eoli3n> this week will be the one we fix it :P
[07:20] <eoli3n> i'm full of hope
[07:21] <eoli3n> i think that i need to reread the whole post, and try to make a state post to figure "where we are now" to be able to find "what we could try, or what we miss"
[07:36] <eoli3n> ok, i'm testing
[07:36] <eoli3n> (see my answer on the thread)
[08:10] <eoli3n> thread updated, i'm still searching for a way to trigger permanent nfs-support
[10:15] <mup> PR snapd#12155 opened: DT-576 Check the status of refresh-pending snaps <Created by sergio-costas> <https://github.com/snapcore/snapd/pull/12155>
[11:18] <mardy> eoli3n: hi! Let me read the forums...
[11:18] <eoli3n> (y)
[11:23] <mardy> eoli3n: instead of delaying snapd startup, can't you make the mount of the NFS happen earlier?
[11:24] <eoli3n> no, because there is no nfs at startup
[11:24] <eoli3n> nfs is automounted by autofs when a user log in
[11:24] <eoli3n> mardy: i guess, that there is no way to force nfs support permanently ?
[11:25] <eoli3n> i don't want snapd auto detection
[11:25] <eoli3n> i want to force nfs support permanently, is there a way ?
[11:27] <mardy> eoli3n: don't you have an autofs entry in your fstab?
[11:27] <eoli3n> no
[11:27] <eoli3n> that's not the way autofs work
[11:28] <eoli3n> mardy: you should be a politic guy, you are really good at skipping answers :P
[11:30] <mardy> eoli3n: sorry, I did look up the code and indeed saw that there's no way to force nfs support, but I was looking for workarounds
[11:31] <mardy> eoli3n: if snapd sees a nfs or autofs entry in the fstab, it will enable it. I wonder if there's a way to add an entry there, which is basically a no-op
[11:31] <eoli3n> there is no autofs entries in fstab
[11:32] <eoli3n> AFAIK it doesn't even exist
[11:32] <eoli3n> snapd should test if autofs as mounts in /etc/autofs/auto.master.d
[11:32] <eoli3n> sorry /etc/auto.master.d
[11:34] <eoli3n> if autofs have* mounts
[11:35] <eoli3n> could you explain why there is no way to force nfs-support ?
[11:35] <eoli3n> that's not what /var/lib/snapd/apparmor/snap-confine/nfs-support file does ?
[11:36] <eoli3n> the only problem is to make that file permanent
[11:36] <eoli3n> it seems crazy af to me that that file is "moved" by something
[11:37] <eoli3n> that's like create /etc/something.conf, chattr +i the file and then a daemon fails to start because of the chattr +i
[11:37] <eoli3n> it sounds like a crazy design
[11:37] <mardy> it's snapd removing it
[11:38] <mardy> it removes all files from that directory, that were not created by it
[11:38] <eoli3n> is there any reason ?
[11:38] <eoli3n> i mean, why doing this ?
[11:38] <mardy> let me check if I can dig some info out of the git repo
[11:38] <eoli3n> ok
[11:38] <eoli3n> thanks again for helping
[11:43] <mardy> eoli3n: the logic was added here: https://github.com/snapcore/snapd/commit/8db78ad30cb060ad4aab0de3489e5d5060d8c743
[11:44] <eoli3n> mardy: should I fire a bug somewhere ?
[11:44] <mardy> I think it's clear that we needed to ensure that the file contents were the expected ones, but the EnsureDirState function also removed unrecognized files,
[11:44] <mardy> and this seems was not explicitly requested
[11:45] <eoli3n> so there is two things, 1° fix autofs test, to guess nfs use not only from fstab, but also /etc/auto.master.d
[11:46] <eoli3n> 2° give the ability to trigger nfs-support with a root created file, without removing it
[11:46] <mrec> so snap basically eliminates the global IPC/Shared memory support?
[11:47] <mrec> backward development in my eyes... certainly flagged as "safety"
[11:47] <eoli3n> i could workaround by adding a fake nfs mount, with good systemd options to ignore if fails
[11:53] <mardy> eoli3n: I updated https://bugs.launchpad.net/snapd/+bug/1917348
[11:53] <mup> Bug #1917348: NFS access not permitted for snap's on LDAP autofs system <snapd:In Progress by zyga> <https://launchpad.net/bugs/1917348>
[11:54] <mardy> mrec: no, we do have the shared-memory interface: https://snapcraft.io/docs/shared-memory-interface
[11:56] <ogra> mardy, sadly that doc lacking a description of the "private" attribute which actually allows full /dev/shm access) 
[11:56] <ogra> +is
[12:19] <mrec> mardy: this defines that 2 snap packages can communicate with each other, but how about a native application and a snap package accessing the native application via IPC / shared memory?
[12:20] <eoli3n> mardy: is there a way to setup a cacher serveur for packages ? something like apt-cacher ?
[12:21] <mrec> we just have this situation we have a video server which is providing the data via shm/ipc and regular applications are connecting via the system hooks. Now the snap package disallows all that and won't work.
[12:21] <mrec> that worked for like 1 1/2 decades
[12:22] <ogra> mrec, that is the "private" flag i mentioned above ... it i described in the core that is linked from the doc lage 
[12:22] <ogra> s/lage/page/
[12:22] <mrec> ok and how about sysv-ipc?
[12:22] <ogra> mrec, note though that this will make your snap go into manual review and it will have to undergo inspection by the security team to be allowed into the store
[12:23] <ogra> sysv-ipc ? you mean sockets ? 
[12:23] <mrec> eg. semaphores
[12:23] <mrec> message queues
[12:24] <mardy> eoli3n: not AFAIK
[12:24] <mrec> there should be an easy to set option to give snap packages access to that in order to keep backward compatibility
[12:25] <mrec> stripping off everything that has been there for decades cannot be flagged as "security".. certainly if things are removed they cannot be exploited.
[12:26] <ogra> well, age des nto tell anything about how secure something is ... if you lived without doorlocks in your house for three decades that doesnt mean adding a lock is not adding security 🙂
[12:27] <mrec> let's not use a computer so it cannot be exploited :-)
[12:31] <mrec> that was basically the reason why people preferred linux over windows because linux gave freedom, but now it's going the other way.
[12:31] <mrec> no certainly full ipc and shared memory support has to be supported - and not only by security review but also as an option for the user to set it himself.
[12:31] <ogra> i think semaphores can be handled via the snapcraft-preload wrapper 
[12:33] <ogra> well, this is not how snaps are designed ... security checks happen on upload *before* anything goes into the store ... if something uses a super privileged interface that allows breaking out of the sandbox, it goes into manual review
[12:33] <mrec> we use semaphores eg. to notify the client application that a video frame is ready
[12:33] <ogra> i doubt this will change anyt time soon ...
[12:34] <mrec> it looks more like security is an excuse for an incomplete system, if security is so important put everything into the browser
[12:35] <mrec> destroying sysv ipc is not good
[12:36] <mrec> especially if the underlying system supports it... if someone wants that fool proof system he can remove it from the kernel (it's just an option)
[12:36] <ogra> well, what are the exact erros you did hit with your snap = 
[12:37] <ogra> did you run it throug the snappy-debug tool yet (it will giv interface suggestions)
[12:37] <mrec> the problem is basically that the snap package does not recognize the host server, so we modified the snap package itself and included the server into the snap package as a workaround
[12:37] <mrec> we treat it as a virtual machine (which it is.. due to the sandboxed nature)
[12:38] <ogra> right, but if bot snaps do come from the same publisher you can use the shm interface just fine 
[12:38] <ogra> *both
[12:39] <ogra> (or even work without shm interface at all if you peoperly use a snap-named subdir in /dev/shm)
[12:41] <mrec> well we got it work but it would still be better to restore full sysvipc support in snap packages
[12:41] <mrec> unix domain sockets are also locked no?
[12:42] <ogra> IIRC they work inside a snap for IPC 
[12:42] <mrec> that's so bad...
[12:42] <ogra> either way, if you want changes, better start a thread in the snapd category in forum.snapcraft.io 
[12:42] <mrec> it needs to reach servers outside of the snap package that's what sysv-ipc and domain sockets were introduced for
[12:43] <mrec> ok
[12:56] <mup> PR snapd#12156 opened: tests: fix unbound SPREAD_PATH variable on nested debug session <Simple 😃> <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12156>
[13:16] <mup> PR snapd#11419 closed: gadget: Use systemd-repart to create new partition during install <Precious but later :heart:> <Created by valentindavid> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/11419>
[13:16] <mup> PR snapd#11421 closed: many: Do not use -enc suffix for encrypted parition labels <Precious but later :heart:> <Created by valentindavid> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/11421>
[13:21] <mup> PR snapd#12031 closed: systemd: Do not mount snaps before `ostree-remount.service` <Created by valentindavid> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/12031>
[13:36] <mup> PR snapd#12132 closed: wrappers: use a revision-agnostic paths when rewriting a desktop file <Needs Samuele review> <Precious but later :heart:> <Created by oSoMoN> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/12132>
[15:06] <mup> PR snapcraft#3915 opened: legacy: install unpinned build packages <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3915>
[15:12] <mup> PR snapd#12157 opened: tests: disable quota tests on arm devices using ubuntu core <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12157>
[15:47] <mup> PR snapd#12146 closed: image: update `prepare-image` work with UC20+ style classic  models <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12146>
[16:02] <mup> PR snapd#12158 opened: image,tests: tweak naming and test for classic UC20+ image <Created by mvo5> <https://github.com/snapcore/snapd/pull/12158>
[23:41] <mup> PR snapcraft#3914 closed: build(deps): bump oauthlib from 3.2.0 to 3.2.1 <dependencies> <python> <Created by dependabot[bot]> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3914>