On an unrelated note, is there a way to share some negative feedback on systemd projects without incurring significant hit to karma?
systemd still hungry: https://www.youtube.com/watch?v=bdmv2FQRHWg
it's still eating..
On Running systemd-nspawn Containers (2022)
41–50 of 59 posts
Re: On Running systemd-nspawn Containers (2022)
#42It's really one of those little gems not very many people know about or use, but it seems from the responses that is changing. As Brendan Gregg said: "Containers are just processes, cgroups, and namespaces."
Dockerfiles are just a really nice, standard way of specifying them, along with ports, networks and persistent storage.
Re: On Running systemd-nspawn Containers (2022)
#43Earlier quoted context omitted.
If file system level isolation is enough for you, take a loot at schroot ( https://linux.die.net/man/1/schroot ) which allows root-less chroot. You can use something like debootstrap to get a complete userland into a user controlled directory and use schroot to chroot into it without root level access.
EDIT: it seems that for creating a chroot you still require root. I don't have root on that system and so I can't create a chroot , there is fakeroot but it doesn't work since it uses qemu on that locked system. Are there any other alternatives
> it seems that for creating a chroot you still require root.
You actually don't as long as you have user namespaces.
One thing I am working on I use chroot (rather unshare --root=) to minimally sandbox a subprocess. At the beginning of the script I have this little snippet:
if [ "$(id --user)" -ne 0 ]; then
exec unshare --map-root-user --mount -- "$0" "$@"
fi
Re: On Running systemd-nspawn Containers (2022)
#44Earlier quoted context omitted.
all containers require root. docker and the rootless nonsense is just root daemons and suid. ...would never have believed marketing lies would reach linux tools if anyone told me this before 2018.
Linux user namespaces can be used to create containers without having root access, see ex. https://unix.stackexchange.com/questions/66084/simulate-chro... There's also https://github.com/termux/proot-distro which may or may not count as containers depending on how you define the word but I think it does count
you can't detach your username from a process, nor the network ns... etc, etc, etc.
yeah you can do some smaller fakechroot and maybe some bind mounts... if you call that a "container" good for you.
Re: On Running systemd-nspawn Containers (2022)
#45Earlier quoted context omitted.
all containers require root. docker and the rootless nonsense is just root daemons and suid. ...would never have believed marketing lies would reach linux tools if anyone told me this before 2018.
you can theoretically run a virtual machine like libriscv5 which doesn't require root. or qemu doesn't require root as well. But qemu is blocked for my usecase. There is flatpak theoretically as well There is podman but it requires one time root.
qemu is great but it's a VM, not a container.
Re: On Running systemd-nspawn Containers (2022)
#46Earlier quoted context omitted.
hmm this is very interesting. I am wondering though? Is there something like systemd-nspawn that doesn't require root?
It looks like systemd-nspawn is gaining rootless support, see https://github.com/systemd/systemd/issues/30239 Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.
Do note that the current support is limited to signed disk images, while it was recently (still not in a release) gained the ability to use any directory that resides inside a signed disk image (instead of just the entire disk image).
Re: On Running systemd-nspawn Containers (2022)
#47This is very interesting! I only heard about systemd-nspawn last night.
Most systemd-projects have a name which immediately shouts out what it does, so you can easily tell if it is relevant for your needs or not. systemd-nspawn is probably the only project without such a name, so most people don't know about it, nor what it does, and therefore never looks any more into it. And that's a shame really, because it's fantastic technology.
> systemd-nspawn is probably the only project without such a name
Add sd-tmpfiles to the list IMO. While it still create and manages temporary files its more managing almost any type of system file. From creating them to managing their permissions or making symlinks when needed.
I am a strong advocator of renaming it systemd-sysfiles to match the systemd-sysusers which is somewhat related (e.g. tmpfiles using users created from sysusers). But it probably won't happen for a while if at all due to backwards compat.
Re: On Running systemd-nspawn Containers (2022)
#48I used nspawn to get a system running in the most ridiculous way. A debian aarch64 vm on kvm starting a systemd-nspawn for an unpacked raspberry pi 3 iso. It works way too well judging by how ridiculous it was. Still saved me a few days instead of setting things up myself. I actually liked how easy it is to spin up nspawn as a systemd service [Unit] Description=Raspberry Image Machine After=multi-user.target [Service…
Why run the Debian VM? Just use nspawn directly
Re: On Running systemd-nspawn Containers (2022)
#49Earlier quoted context omitted.
OCI is for running prepackaged software in black boxes from the internet, where you have no interest or ownership of the container internals. Most of my containers are not like that. Well, actually none are. systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable), deployed as part of your overall systemd based infrastructure for when the thing you need to manage is "too big"…
This distinction is a more useful one that the article made. I love dockerfiles and immutability, but there are good cases for mutable containers, too.
You can also do some neat things with "--ephemeral" and "--volatile" to basically overlay the image (or a subset) with tmpfs; any changes to those overlays will be lost when the container is brought down. The specific mount points can be controlled in greater detail via "--tmpfs" and "--overlay".
https://0pointer.net/blog/running-an-container-off-the-host-...
I'm not sure how easy that is to customize in Podman.
Re: On Running systemd-nspawn Containers (2022)
#50This is very interesting! I only heard about systemd-nspawn last night.
Most systemd-projects have a name which immediately shouts out what it does, so you can easily tell if it is relevant for your needs or not. systemd-nspawn is probably the only project without such a name, so most people don't know about it, nor what it does, and therefore never looks any more into it. And that's a shame really, because it's fantastic technology.
How so? nspawn means spawn a process in a new namespace, which is... exactly what it does. The problem isn't with systemd-nspawn, the problem is with containers, because the vast majority of devs have no idea that containers are just scripts to set up Linux namespaces.