Live data from Hacker News

Introduction to Immutable Linux Systems

dataswamp.org

101–110 of 164 posts

Re: Introduction to Immutable Linux Systems

#101
post #61

How would you approach making immutable live-cd like Linux? No persistence at all, just boot it and run some app - think some kind of presentation panel which shows predefined program/URL. Ideally net booted to avoid having storage at all.

Ideally, Kali is meant to be used this way, so you can use it to perform forensics on a potentially compromised system without inadvertently changing anything and destroying evidence. You can really trivially do this with any Live CD by putting it on write-once read many media. You typically need at least /var and /tmp to be writeable, but that can be accomplished via tmpfs so they only write to memory and not disk. You don't really need to do anything to enable this at the distro level, other than maybe make the mounts default, but in practice, live CDs tend to mount the root filesystem as SquashFS, which is also read-only at the filesystem level, and then use OverlayFS for partitions that need to be writeable for software to work, not retaining the writeable layer on shutdown.

If you mean how would you do it yourself, you can use the tooling used by real distros. I'm not sure what tools they all provide, but Archiso (https://wiki.archlinux.org/title/Archiso) is probably the simplest to understand and modify because it's purely shell scripts.

Re: Introduction to Immutable Linux Systems

#102

Earlier quoted context omitted.

Yes, Fedora Silverblue is image-based. We just use extending those stock images as an alternative to layering and easy way of shipping the same system configuration to many people.

Isn’t an OCI image essentially layers + metadata? How is it different from what you call “layering”? Legit question, just trying to understand why you feel it’s an advantage.

An OCI image is pretty simple, yes, so is the sort of image that is in an OSTree repository. The difference is that when using `rpm-ostree` packages installed with `rpm-ostree install` are "layered" on top of the base image, while packages in the "base image" (be it OCI or OSTree) are part of the system and thus not "layered".

Adding packages in an image has the benefit of pseudo-reproducability (have the same image on multiple computers) and the added robustness of your base system being built elsewhere daily. Your computer just pulls the diffs. For example, there have been issues with rpmfusion on Fedora that ublue users completely avoided. Codecs & other essential rpmfusion packages are included in the images, and the rpmfusion repository is removed after they are installed. This way, if something package-related breaks it breaks at the image build stage, and an ordinary user wont even notice it before it is fixed.

The most noticeable benefit IMO, though, is being able to ship the same changes on top of a base image every day for multiple machines. This is not only packages, but for example udev rules, and other QoL things like our `justfile`s, configuration for https://just.systems/ that has some useful scripts for adding the kargs necesarry for Nvidia drivers to work and `just update` for updating the system, flatpaks & distroboxes.

Re: Introduction to Immutable Linux Systems

#103
post #86

What these sort of introductions to immutable always fail to consider is the other side of the coin, image-based. I'm working on https://universal-blue.org/ along with many people much more skilled than me. We build OCI container images on top of vanilla Fedora Silverblue & many other editions with different desktops. Those images can then be booted to (or rather rebased to) using rpm-ostree. This is a more robust wa…

I see that UBlue uses Github actions to rebuild the images regularly to roll in package updates. Who foots the bill? Are the images also served from Github? Does Github charge for egress? What happens when a lot of users want to download the same image?

Github free tier served us well. For a while we had a paid tier for GH orgs to get better builders, but now I think we use https://buildjet.com/. I'm not too familiar with this aspect, though.

I think the bills are paid by Jorge (the kind of "founder" of the project), at least I think so, though some of the other top members with jobs in the Linux/Cloud world might be helping. Donation paths and such have been considered, but the bills aren't too huge so nothing has been rushed in.

For the registry, GHCR serves us entirely for free. No egress costs, no ingress costs, nothing. No plans to change providers, and I don't think they have plans to raise pricing either. We could probably find an alternative host pretty easily, though, through the cloud contacts and knowledge some of the devs here have.

Re: Introduction to Immutable Linux Systems

#104
How does working with Docker work on Immutable systems like Fedora Silverblue. Like e.g. developing an application (in a Devcontainer like e.g. Toolbox to avoid having to install all the devtools on os-tree) and then building and debugging a Docker container from within the devcontainer? Or am I thinking in a wrong way?

Any good blogposts on developer workflows on Silverblue?

Re: Introduction to Immutable Linux Systems

#105

How does working with Docker work on Immutable systems like Fedora Silverblue. Like e.g. developing an application (in a Devcontainer like e.g. Toolbox to avoid having to install all the devtools on os-tree) and then building and debugging a Docker container from within the devcontainer? Or am I thinking in a wrong way? Any good blogposts on developer workflows on Silverblue?

This sounds painful for no reason. Especially the debugging part. Why would you want that? Is it really such a strain to install the tools you need for development on your computer?

I can understand wanting an immutable system for a server, as it will likely cut down on maintenance, but for personal use... that just sends shivers down my spine... As someone having to support other (especially not very savvy) programmers when it comes to tool usage and their environment I hate to imagine having to deal with someone who'd want that kind of setup.

Re: Introduction to Immutable Linux Systems

#107

Relatedly, does anyone know if the security guarantees around distrobox have gotten any stronger? Last I looked, they promised nothing, but curious if there has been any movement there. I would love if there was a seamless way to launch a distrobox os with a separate user home that could not touch my host system. Likely a Real Hard Problem, but even some isolation would probably be an improvement of running everythin…

Distrobox and toolbox are developer tools, they explicitly are there as a convenience wrapper for podman/docker for development.

If you want hard separation you'd need a VM. It'd be awesome if you could just --firecracker on distrobox create and get that. :D

Re: Introduction to Immutable Linux Systems

#108
Off topic, but does anyone know how to find out where mutable data for NixOS modules are stored at (e.g. the data directory for a database) without reading the source? Occasionally, it's mildly annoying, and would be comforting to know with certainty where all my state is.

Re: Introduction to Immutable Linux Systems

#109

How does working with Docker work on Immutable systems like Fedora Silverblue. Like e.g. developing an application (in a Devcontainer like e.g. Toolbox to avoid having to install all the devtools on os-tree) and then building and debugging a Docker container from within the devcontainer? Or am I thinking in a wrong way? Any good blogposts on developer workflows on Silverblue?

VSCode with the devcontainer and docker is great on Silverblue.

I've been prototyping some developer workflows with friends here: https://universal-blue.org/images/bluefin/developer-experien...

So far the major patterns are vscode with distrobox, vscode with devcontainers, vscode with devpod, jetbrains toolbox thing (which just runs everything out of the home directory, the OS doesn't care).

And then devbox/nix and homebrew in ~ is also an option if you're into that.

Re: Introduction to Immutable Linux Systems

#110

Off topic, but does anyone know how to find out where mutable data for NixOS modules are stored at (e.g. the data directory for a database) without reading the source? Occasionally, it's mildly annoying, and would be comforting to know with certainty where all my state is.

Unfortunately, that's not possible. However, as NixOS modules usually are Systemd services, the StateDirectory= of the service is a good starting point (systemctl cat ).
Post reply on HN