Fedora 36 To Support OSTree Native Containers / CoreOS Layering

[phoronix]

Phoronix: Fedora 36 To Support OSTree Native Containers / CoreOS Layering

Fedora 36 feature work continues building up for what will make another exciting update to this Linux distribution come April. The latest approval is more exciting work on the OSTree / CoreOS front...

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-36-CoreOS-Layering

[middy]

i'm really dumb when it comes to OSTree. i've tried searching about it and can't figure out what it is about. could someone explain it it like i'm five?

[Tjako]

i'm really dumb when it comes to OSTree. i've tried searching about it and can't figure out what it is about. could someone explain it it like i'm five?

It's a bit like containers(podman/docker) but instead of installing the os that runs the containers you boot the container on your system
So you would be running an image that is locked (sha256sum checked at boot) so it's immutable ( all changes are lost at boot)
To keep your data one exception is made which is the /var mountpoint, everything that you modify will be stored beneath /var (/root /home .....)

To add packages to the image you use the rpm-ostree command, which then will add a layer (like you get when you write a Docker file)
There will be a new sha256sum and this is very obvious when booting (grub will clearly display the shasums for each selection)

Updating means adding a new immage to your system.

Returning to the previous version is a matter of selecting the other option in grub during boot.
Which means you can try that new bleeding edge version without worrying about system corruption.
(keep in mind that database contents in /var are not protected since they are not part of the image)

Default fedora keeps the last 2 releases but this can ofcourse be modified (limited only by your local storage capacity)

Adding layered packages is a very slow and timeconsuming process, hence they added flatpak that ordinary non-root users can use to install flatpak apps (containerized packages) in their own namespace (home directory).

I set up a htpc running kinoite (fedora kde ostree distribution) containing the kodi flatpak then added the netflix, disney, prime, youtube and spotify plugins.
After which I only needed to configure kde to autologin the kodi user and then make it automatically run the kodi software.
extremely small effort to get a htpc system up and running, this used to take me a lot more time.

managing an ostree system feels more like working with git than the usual dnf install/remove/update

there are spins for ostree (x86_64/ppc64le/aarch64) (27/28/29/30/31/32/33/34/35/rawhide)
- fedora coreos
- fedora silverblue (gnome)
- fedora kinoite (kde)

and some less official ones for
- mate
- cinnamon

[Setif]

One of the most annoying thing about flatpak packages is that you couldn't extract it and look at its contents, all because of ostree!

[Tjako]

One of the most annoying thing about flatpak packages is that you couldn't extract it and look at its contents, all because of ostree!

yeah, it takes quite some getting used to.

but since it is a containerized package, it's fairly safe to install it since it gets extracted into its own namespace (which is a very restricted area in your local user environment (the flatpak is not allowed any access outside it's own namespace)

you can look at everything in the ~/.var directory then decide if it's worth your time.
Simply remove the flatpak and delete its directory below .var to get rid of it

mind you need to install the flatpak as a user (not as root) if you are really paranoid about it.
(in a vm running on a separate system ofcourse... :-P )

flatpak isn't limited to ostree, it's also available in exactly the same way on fedora workstation.

[middy]

It's a bit like containers(podman/docker) but instead of installing the os that runs the containers you boot the container on your system
So you would be running an image that is locked (sha256sum checked at boot) so it's immutable ( all changes are lost at boot)
To keep your data one exception is made which is the /var mountpoint, everything that you modify will be stored beneath /var (/root /home .....)

To add packages to the image you use the rpm-ostree command, which then will add a layer (like you get when you write a Docker file)
There will be a new sha256sum and this is very obvious when booting (grub will clearly display the shasums for each selection)

Updating means adding a new immage to your system.

Returning to the previous version is a matter of selecting the other option in grub during boot.
Which means you can try that new bleeding edge version without worrying about system corruption.
(keep in mind that database contents in /var are not protected since they are not part of the image)

Default fedora keeps the last 2 releases but this can ofcourse be modified (limited only by your local storage capacity)

Adding layered packages is a very slow and timeconsuming process, hence they added flatpak that ordinary non-root users can use to install flatpak apps (containerized packages) in their own namespace (home directory).

I set up a htpc running kinoite (fedora kde ostree distribution) containing the kodi flatpak then added the netflix, disney, prime, youtube and spotify plugins.
After which I only needed to configure kde to autologin the kodi user and then make it automatically run the kodi software.
extremely small effort to get a htpc system up and running, this used to take me a lot more time.

managing an ostree system feels more like working with git than the usual dnf install/remove/update

there are spins for ostree (x86_64/ppc64le/aarch64) (27/28/29/30/31/32/33/34/35/rawhide)
- fedora coreos
- fedora silverblue (gnome)
- fedora kinoite (kde)

and some less official ones for
- mate
- cinnamon

i thank you very much! this is great. this would really be nice for systems that need to kept lock down, just want strong security, or wanting to try out new things but have a safety net. able to revert to a previous state.

[Tjako]

i thank you very much! this is great. this would really be nice for systems that need to kept lock down, just want strong security, or wanting to try out new things but have a safety net. able to revert to a previous state.

just remember that if you have an app running a LOCAL database that the contents will be in /var and a schema update of the database could still wreck it.
so make sure you got a backup.

[Setif]

yeah, it takes quite some getting used to.

but since it is a containerized package, it's fairly safe to install it since it gets extracted into its own namespace (which is a very restricted area in your local user environment (the flatpak is not allowed any access outside it's own namespace)

you can look at everything in the ~/.var directory then decide if it's worth your time.
Simply remove the flatpak and delete its directory below .var to get rid of it

mind you need to install the flatpak as a user (not as root) if you are really paranoid about it.
(in a vm running on a separate system ofcourse... :-P )

flatpak isn't limited to ostree, it's also available in exactly the same way on fedora workstation.

That's the annoying thing, you have to install, look at it, and then if it doesn't look good uninstall it and retry again. You know this is not a good experience when you try to package your own application in flatpak format, as it needs more steps (add a local repo, ... until you get application.flatpak)

[Tjako]

That's the annoying thing, you have to install, look at it, and then if it doesn't look good uninstall it and retry again. You know this is not a good experience when you try to package your own application in flatpak format, as it needs more steps (add a local repo, ... until you get application.flatpak)

spot-on ...

the only way to ease the pain is to set up a full devops ci/cd infra, then you write a build script once and you can use that again for each flatpak you wish to create.
This really takes some serious getting used to and a very steep learning curve for those who are not familiar with devops.
I found that running a gitlab container eases the pain a lot, since it comes as a prefab container and setting up a ci/cd in gitlab takes only a few steps.

either that or keep doing all the steps manually (maybe you can skip a few with scripts and containers which implies you are already kinda doing ci/cd)

[drake23]

What's the advantage to btrfs snapshots, where I can also go back to a previous state after say a zypper up?