Initial F31 flatpak runtime and further plans
by Kalev Lember
Hi all,
I've built an initial version of F31 flatpak runtime and SDK, and built
a set of GNOME flatpaks against it. At the same time, I've also updated
them to 3.34.x. I'll build more of the apps against F31 runtime in the
coming days. Right now the set of apps include:
org.gnome.Baobab
org.gnome.Calculator
org.gnome.Calendar
org.gnome.Characters
org.gnome.clocks
org.gnome.Contacts
org.gnome.eog
org.gnome.Evince
org.gnome.font-viewer
org.gnome.gedit
org.gnome.Logs
org.gnome.Maps
org.gnome.Screenshot
org.gnome.Weather
This set was chosen for the initial port because this is what we want to
preinstall on Silverblue.
This should hopefully go stable around the same time as F31 goes live,
so people should be able to install 3.34 flatpaks on F31.
Karma in Bodhi and testing welcome:
https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2019-addc7ab077
Right now they are available in the fedora-testing flatpak repository.
To enable the remote, 'flatpak remote-modify --enable fedora-testing'
or if you don't have the remote for some reasons, then:
'flatpak remote-add fedora-testing
oci+https://registry.fedoraproject.org#testing'
Thanks,
Kalev
4 years
flatpak local storage location
by Chris Murphy
The subject of disk space and flatpaks came up in the most recent
workstation meeting, and I'd like to separately discuss that in this
thread before creating a flatpak issue.
The full log:
https://meetbot.fedoraproject.org/teams/workstation/workstation.2019-10-2...
Excerpts:
13:16:07 <langdon> allocating enough disk if you have your drive
sliced up is tough
13:16:36 <Son_Goku> and yeah, the disk space issue is a huge problem
...
13:16:47 <kalev> "the disk space issue" ?
13:16:58 <otaylor> Son_Goku: why would disk space be an issue?
flatpaks store data in $HOME
...
13:17:19 <langdon> that's the problem.. normally I have a "games disk"
13:17:27 <Son_Goku> likewise
Neither sysroot nor $HOME fits the above use case, where the user
wants to store games on a separate volume entirely. And another use
case is where it's desirable to use the much larger /home volume
storage pool, but permit sharing of apps among users.
Could there be a /home/share/flatpak with the appropriate permissions,
that meets both use case requirements?
Alternatively, Workstation could do what Silverblue does, with
/var/home bind mounted to /home - and therefore system and user
flatpaks go on the same volume. But there should also be a way to set
the default location for flatpak files. Users wanting a games volume
could bind mount it to /var/lib/flatpak, but then they need a way to
set system as the default location instead of users.
--
Chris Murphy
4 years
Re: encrypting user homes by default, meeting summary
by Chris Murphy
(cc: desktop@ list too)
Not sure.
Lennart is out until ~Nov 1 on paternity leave. And then his first
priority is merging all the systemd-homed stuff and a bunch of fix
ups. He says it will be production ready by then.
One thing I got from Lennart that I don't have a complete assessment
on, is to what degree he's replicated fscrypt (userspace tool from
Google) functionality. He's hooking into fscrypt (kernel code)
directly, and doesn't have any of the fancier key management that
Google fscrypt has - i.e. Google fscrypt let's you change the user
master passphrase, which is a wrapped key, separate from the secret
key (let's call it a DEK, even though there is one DEK and then there
are many derived DEK's for each file), so that it's not necessary to
reencrypt everything. Whereas systemd-homed lacks this feature, so it
requires 50% free space to reencrypt everything in case of user
passphrase changes.
I already told Lennart I personally think that's close to a deal
killer, if I'm really understanding this limitation correctly. It's
weird behavior. And such a burden for resources, space and time and
likely would need to be done offline (user is not logged in and can't
be using their home while the reencryption happens), that it would
inhibit users from changing their passphrase when they probably
should, which makes it anti-security, i.e. "I should change my login
passphrase after that work trip; oh crap I have to reencrypt 250G?! No
way. Guess I won't change the passphrase." I think it's unworkable,
and I said so. Casually some people might use it. But I can't
recommend that.
Someone who can read the code needs to look at it and give an
independent assessment: is it really production worthy, is the use
case too narrow or just right, and if too narrow what kind of work
would be needed to broaden it? Etc. I can't really do any of those
things. But for example, to what degree will homed support FreeIPA/AD
domains? Is that a small problem or big problem, is there some other
way to handle those cases? How?
I'm also concerned about performance implications of e.g. GNOME Boxes
in the case where it creates qcow2 file, on top of user home which is
on a file system backed by a loopback mounted encrypted file, which is
on another file system. So that VM is basically pushing writes through
three file systems. I've done quite a lot of brutal testing over years
where I do bat guano crazy things like Btrfs on qcow2, on Btrfs home
on encrypted loop file, on Btrfs, and I'll use the VM and crash the
host and everything survives - that is, the file systems don't break.
There is data loss but that's sorta expected for any file system. But
a consequence of that arrangement is, Btrfs is shit when it comes to
fsync. So if the GNOME Boxes default cache of writeback continues to
be used, which is reasonable, Btrfs performance gets bad with fsync
heavy workloads. Otherwise it performs the same, and occasionally
better, than other file systems.
So yeah - who wants to help dig into the dirty work and actually make
a recommendation? We don't have enough R&D done yet probably to decide
on this but I'm gonna guess it makes a lot more sense to try to use
systemd-homed and convince Lennart, as early adopters, we want it to
be successful and in order to be successful he's gonna have to let it
grow into something that'll actually do what we want and need. But for
that to be convincing, we have to know what we want and need.
Chris
On Tue, Oct 22, 2019 at 1:39 PM Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
>
>
> What should be do to unblock this? Would another meeting be helpful, or
> do we need to do further investigation/research first, or...?
>
>
--
Chris Murphy
4 years, 1 month
